The Honeynet Project
Scan of the Month 23, September 2002
Analysis by Michael Bel - bel_michael@hotmail.com
First, what is a binary log file? Simply put, it's a record of information stored in binary format. In this particular case it's a binary log file created by Snort in 'Packet Logger Mode' which contains a record of all observed packets during a single run. A command line example for Snort that enables this mode is:
This command line assumes a directory named 'log' exists in the current directory. The '-l' switch specifies the logging directory and the '-b' switch tells Snort to use binary output instead of the standard ASCII output. In this mode the use of switches to specify verbose mode or specify which sections of packets should be logged are not required because the entire packet is logged. The binary file created is in 'tcpdump' format and can be accessed for analysis by software such as 'tcpdump' and 'ethereal'. I used Ethereal while analysing the log supplied for this challenge.
Question 2 asks: What is MD5 and what value does it provide? A quote from rfc 1321 goes a long way to answering this question:
So MD5 (MD stands for Message Digest) provides a way to ensure data integrity by providing a unique 'fingerprint' for any given data. MD5 has practical applications when downloading files from the internet, reading your email, and within intrusion detection systems which monitor data for evidence of tampering.
The third question is probably the easiest to answer. The attackers IP address is shown clearly to be 192.168.0.9 right at the start of the log as it initiates the first scan with a simple ICMP echo request. Although later in the log we see a number of other IP addresses which also appear to be scanning the target address, it's obvious these addresses are decoys. We know this because the 'Media Access Control' or MAC address shown as the source of attacks is always the same. Also the attackers address of 192.168.0.9 is the only address which ever responds by tearing down the connection when a synchronisation request is acknowledged by the destination during a SYN scan. The decoy addresses are listed below:
IP Address MAC Address --------------------------- 192.168.0.199 00:10:a4:c5:7c:38 192.168.0.1 00:10:a4:c5:7c:38 192.168.0.254 00:10:a4:c5:7c:38 192.168.0.99 00:10:a4:c5:7c:38
Question 4, what is the destination IP address? Again, the log is very clear and shows 192.168.0.99 as the destination of all scanning activity. Most of the synchronisation requests from the attacker are to ports which are not open on the destination address so these requests are responded to with a reset and no connection is established. Now is probably a good time to reveal how much of a beginner I really am. When I first installed Ethereal it was simple to open the log from generated by Snort. But to my horror, in the source and destination columns were the names of machines on my home network! Quickly putting aside my paranoia about being dragged into some elaborate practical joke, I disabled hostname and mac address resolution which revealed the actual IP address information contained in each packet.
Identifying the 5 scanning methods used and describing how they work led me to read the documentation available for the port scanning software NMAP. Since I mentioned NMAP already I will answer question 6 which concerns the scanning tool used and how I determined this. I think it must be NMAP. After reading the NMAP documentation and searching the internet for another scanning tool that can equal it's scanning ability I found nothing quite matches it. NMAP's user documentation shows very clearly the various types of scans that can be performed, going into some detail about each one and commenting on advantages and disadvantages. Without another scanning product available that can perform all the scan types shown in the snort log, I am left with NMAP as a logical choice. The 5 different methods are described below, and I will provide information on NMAP command line options you need to perform each one as I go through.
Method 1 - Ping scanning. The first 4 packets in the log are all we see of this scan. It is designed only to show if the destination address is up. The scan is in two parts, first an ICMP echo request which is contained in the first packet of the log. The destination address responds to this request indicating to the scanner that it's target is up. An ICMP echo request (or ping) is sometimes blocked by the destination, so the Ping scan has a second part which sends a TCP packet with the 'Acknowledge' flag set. This packet also gets a response in the form of a TCP packet with the Reset flag set. Method 1 as described is default behaviour of NMAP when using the command line switch '-sP'.
Method 2 - SYN scanning. About ten seconds after scanning the destination to see if it's up using Method 1, we see the start of TCP SYN scanning. This technique is also referred to in some documents as 'half-open' scanning because a full connection is never completed. For closed ports the destination simply sends a TCP RESET packet, but for open ports the destination will send a TCP ACK packet. The scanning source then sends a RESET packet to the destination and this ensures the connection is never completed. Many ports are shown to be scanned using this method in our log. The port numbers are being scanned in a seemingly random order, this is another default behaviour of NMAP (to disable randomisation use the -r switch). The command line switch for SYN scanning with NMAP is '-sS'.
Method 3 - NULL scan. The NULL scan starts at frame number 148011 in our logs. The TCP packets sent by the attacker have all the flags switched off. These packets stick out like a sore thumb in the log because they are quite unnatural (to me). This type of scan works by assuming that for each closed port a TCP RESET is sent back to the attacker. Packets of this type received for open ports must be ignored and are therefore dropped by the destination. Unfortunately this method doesn't work for destinations running Microsoft operating systems because they have implemented things differently and send a RESET packet when they shouldn't according to NMAP documentation other systems that behave this way are CISCO, BSDI, HP/UX, MVS and IRIX. The command line switch for Null scanning with NMAP is '-sN'.
Method 4 - XMAS Tree Scan.XMAS Tree scanning starts at frame number 150759 in our logs. TCP flags Fin, Psh, and Urg are all set on in packets sent to the destination from the attacker. Functionally it works the same as a Null scan (described in Method 3, above) and suffers the same limitations of usefulness when performed against various operating systems. The command line switch used with NMAP for XMAS Tree scanning is '-sX'.
Method 5 - ACK Scanning. This advanced method is usually used to map out firewall rulesets. It can help determine whether a firewall is stateful or just a simple packet filter that blocks incoming SYN packets. This scan type sends an ACK packet (with random looking acknowledgement/sequence numbers) to the ports specified. If a RST comes back, the ports is classified as "unfiltered". If nothing comes back (or if an ICMP unreachable is returned), the port is classified as "filtered".Nmap usually doesn't print "unfiltered" ports, so getting no ports shown in the output is usually a sign that all the probes got through (and returned RSTs). This scan never shows ports in the "open" state.
What is the purpose of port scanning? Port scanning allows someone to examine a network and determine which hosts are up and what services they are offering. This can be useful for a system administrator who wishes to examine and audit their own network. Port scanning is also used in the information gathering stage of an attack on a network or computer system. Port scanners with simple capabilities are available for all platforms and will most likely be found in any security analysts toolkit.
What ports were found open on the honeypot? Using the information contained in the NMAP documentation about how each scan works I was able to determine the kind of activity to search for in the logs which would indicate an open port. I looked for RESET packets coming from the attackers IP address. These RESET packets are sent in order to tear down the connection which has been acknowledged to an open port by the destination address during a SYN scan. Let's look at this in more detail. In frame number 81060 in the log I can see a TCP packet with the SYN flag set on being sent from 192.168.0.9 to 192.168.0.99 using Port 111. In the following frame we see 192.168.0.99 respond to this synchronisation request with a TCP packet that has both the SYN and ACK flags set on. This indicates that a connection to port 111 is possible and will be accepted by 192.168.0.99 on completion of the threeway handshake. Since the attacker does not wish to actually establish a connection a TCP packet is sent from the attacker with only the RESET flag set on in frame number 81066. This stops the connection to port 111 being established but the attacker knows port 111 is open and accepting connections. The list of open ports follows. It also shows the default services offered on those ports:
PORT SERVICE --------------- 80 http 22 ssh 443 https 53 dns 111 sunrpc 32768 unknown