Honeynet Scan of the month,
Scan 23
Analyse numerous port scans against a honeypot.
Leon Ward (nard)
nard@nardware.co.uk
http://www.nardware.co.uk

Overview:

On 27th August 2002, five distinct scans were captured from host 192.168.0.9 aimed at  192.168.0.99.  The purpose of the scans were to gain more information about available on services on the host.

Scan #1  SYN scan
Scan #2  Null scan
Scan #3  TCP Connect Scan
Scan #4  Xmas scan
Scan #5  Xmas using decoys

The attacker learned that the following daemons were running on the target machine.
 

During the Xmas scan, decoys were used to mask the attackers identity, these decoys most likely have no knowledge that they have taken part in this activity.

Decoy Hosts: 192.168.0.1, 192.168.0.254, 192.168.0.199

No attempt to gain unauthorised access was detected.

The Questions.

Question 1) What is a binary log file and how is one created?

The traffic log for this challenge was captured by Snort. Snort is an open source NIDS (Network intrusion detection system) based on libpcap (Promiscuous capture library). Snort has many logging features including a powerful pattern matching rule system. The default logging format is a hierarchical directory structure with the captured packets shown in text, this is a useful format because it can be easily redirected into a database for long term storage and trend analysis. Snort also has the ability to capture all wire traffic and redirect it onto a single file in the tcpdump (libpcap*) binary format.

A binary log can be created from snort by using the following command, where logfilename is the filename of the binary log.

[root@localhost nard]$snort -l /var/log/snort/logfilename -b

There are a number of advantages of using binary log when working with a Honeypots, including:

• An exact copy of every packet that travelled on the sniffed wire is captured.
• It is faster than text mode logging, therefore there it can operate a near wire speeds.
• We can use standard tools like Ethereal* to analyse the log.
• We can run snort against this log in NIDS mode to create ids alert warnings
• It is also useful when testing and refining new IDS rules.
• The ability to extract transferred binaries for further analyses is available.

*See the further reading and references section at the end of this document for more information on libpcap, the emerging standard for packet captures.

Question 2 What is MD5 and what value does it provide?

MD5 is mathematical equation that can be applied to a file to verify it has not been tampered with. When the md5sum binary is passed a file, it will produce a unique 128bit message digest.

The Message digest is a set length digital signature of a file (no matter its size). The purpose of the md5sum is to create a unique fingerprint than can not be reproduced by a similar file. By comparing the md5 of a file and the md5 stated by the distributor, its validity can be guaranteed.
Unfortunately it is possible for two files to have the same MD5 sum, however in reality the chances of this are extremely small and can be considered un-important.

Example: Checking the validity of the snort log file that will be examined.

[nard@localhost sept]$ md5sum ./sotm23.tar.gz
9d28c5ee9ce7b77e3099a07ad303811f ./sotm23.tar.gz
[nard@localhost sept]$

Refer to references for more information on MD5

Question 3) What is the attacker's IP address?
192.168.0.9

Question 4) What is the destination IP address?
192.168.0.99

Question 5) We scanned the honeypot using five different methods. Can you identify the five different scanning methods, and describe how each of the five works?

The art of port scanning is constantly evolving with the aim of becoming totally un-detectable by the host. Over the years these scans have become more resourceful and reliable, however due to the constantly changing pace of technology, even the most ingenious methods of yesterday are becoming easily discovered.

The theory behind a portscan is based upon attempting to open a connection  every TCP / UDP port that could offer a service to a remote client. By examining the reply from the connection attempt,  we have the ability to decide if the service is available (port is open).

    The TCP Three way Handshake

To begin to understand the workings of a port scan, the basics of creating a TCP Connection needs to be known. A Connection is established by a process known as the three way handshake:

• The client machine sends out a TCP packet with the SYN bit set (Synchronise).
• The server responds with a SYN / ACK packet (Synchronise, Acknowledge).
• The client then replies with a ACK packet (Acknowledge).

The TCP connection has then been created.

    The Connect Scan

If a SYN Packet is sent to an closed port, a SYN, ACK response will not be sent. Instead the target will reply with a RST, ACK (Rest, Acknowledge) indicating the port is closed.

Example 1

172.16.1.1 : 1234 -----SYN---> 172.16.1.2 : 80         Client sends a SYN to the server on port 80
172.16.1.2 : 80   ---SYN,ACK-> 172.16.1.1 : 1234     Server replies with a SYN, ACK . This indicates that there is a daemon listening on this port
172.16.1.1 : 1234 ----ACK----> 172.16.1.2 : 80        Client responds with an ACK

172.16.1.1 : 1234 -----SYN---> 172.16.1.2 : 80     Client sends a SYN to the server on port 80
172.16.1.2 : 80   ---RST,ACK-> 172.16.1.1 : 1234    Server replies with a RST, ACK. This indicates there is not a daemon listening on this port.
172.16.1.1 : 1234 ----ACK----> 172.16.1.2 : 80       Client responds with an ACK
 

Example 1 shows the request and responses expected when connecting to a TCP port. These will be logged as connections on the attacked host.

There are many methods of attempting to hide a scan from the target, these are described as stealth scans (where we are using "stealth" to describe some attempt disguise, hide or obfuscate the scan or the scanners identity).

    The SYN (half open) scan.

The concept behind the half open scan is to hide the fact a connection is taking place from the remote operating system, this is accomplished by never completing the 3 way handshake.

Example 2

172.16.1.1 : 1234 -----SYN---> 172.16.1.2 : 80         Client sends a SYN to the server on port 80
172.16.1.2 : 80   ---SYN,ACK-> 172.16.1.1 : 1234     Server replies with a SYN, ACK . This indicates that there is a daemon listening on this port
172.16.1.1 : 1234 ----RST----> 172.16.1.2 : 80        Client responds with an RST to the handshake is not completed.

172.16.1.1 : 1234 -----SYN---> 172.16.1.2 : 80     Client sends a SYN to the server on port 80
172.16.1.2 : 80   ---RST,ACK-> 172.16.1.1 : 1234    Server replies with a RST, ACK. This indicates there is not a daemon listening on this port.

As shown in the above example, the scanner never sends the final ACK, instead it sends a RST to notify the target that the connection should be closed before it is fully open. This is not detectable on some very old operating systems, however any modern OS should pick these up and log them accordingly.

    Non SYN Scans.

Scans that don't send SYN Packets are similar, although they could once be descried stealthy, modern OS's should detect them.
There are down sides to non SYN scans:

• As they rely on only the non-open ports responding, we can end up with one a large amount of false positive's if the ports are filtered.
• They rely on the remote system conforming to RFC standards.

    The Null scan.

The concept behind a Null scan is to send a packet with invalid flags set, in the case of a null scan, setting no flags.
When the target  receives such a packet, it will either be dropped or responded to with a RST, this will obviously be dependent on what state the destination port is currently in (open or closed).

Example 3

172.16.1.1 : 1234 -----------> 172.16.1.2 : 80     Client sends a packet with no flags set to the target on port 80
If no reply is received, the packet has been dropped and therefore the port is considered open.

172.16.1.1 : 1234 -----------> 172.16.1.2 : 80     Client sends a packet with no flags set to the target on port 80
172.16.1.2 : 80   --RST,ACK--> 172.16.1.1 : 1234    Server replies with a RST, ACK. This indicates there is not a daemon listening on this port.
 

    The Xmas Scan

The Xmas scan is similar to the null scan, it is also based on the idea of sending packets with invalid flags set. Where as the null scan sends a packet with no options, the XMAS Scan uses the  URG PSH and FIN (Urgent, Push and Finish) flags. Once again, if the port is closed, a RST will be sent back to the client and if it is open the packet will be dropped.

Example 4

172.16.1.1 : 1234 -URG,PSH,FIN-> 172.16.1.2 : 80     Client sends a packet with invalid flags set to the target on port 80
If no reply is received, the packet has been dropped and therefore the port is considered open.

172.16.1.1 : 1234 -URG,PSH,FIN-> 172.16.1.2 : 80     Client sends a packet with invalid flags set to the target on port 80
172.16.1.2 : 80   ---RST,ACK---> 172.16.1.1 : 1234    Server replies with a RST, ACK. This indicates there is not a daemon listening on this port.

    Decoy Scanning,

Using decoys is one method to attempt to hide your identity from the scanned server. By also sending scan packets to a host with spoofed source address's, the scanned host will respond to all the decoy packets in the same way as the real scanning host. This process makes much harder to identify the real scanning host.

Example

172.16.1.1 : 1234 -URG,PSH,FIN-> 172.16.1.2 : 80    The real scan host sends a packet.
172.16.1.2 : 80   ---RST,ACK---> 172.16.1.1 : 1234   Target responds with RST, ACK, indicating there is no daemon listening 
10.0.0.1   : 1234 -URG,PSH,FIN-> 172.16.1.2 : 80    Packets with a spoofed reply address
10.1.0.34  : 1234 -URG,PSH,FIN-> 172.16.1.2 : 80    are sent so they look like they have 
10.23.44.9 : 1234 -URG,PSH,FIN-> 172.16.1.2 : 80    originated from other hosts.

172.16.1.1 : 1234 -URG,PSH,FIN-> 172.16.1.2 : 80    The real scan host sends a packet.
10.0.0.1   : 1234 -URG,PSH,FIN-> 172.16.1.2 : 80    Packets with a spoofed reply address are sent
10.1.0.34  : 1234 -URG,PSH,FIN-> 172.16.1.2 : 80    so they look like they have been originated
10.23.44.9 : 1234 -URG,PSH,FIN-> 172.16.1.2 : 80    from other hosts

When the port is closed, any RST,ACK replies are directed to the decoy hosts themselves.

Question 6)  Which scanning tool was used to scan our honeypot? How were you able to determine this?

The scanner used in this test is nmap,

When the captured log is run back through snort in IDS mode, an alert file is generated and contains nmap Xmas scan warnings.

[**] [111:10:1] spp_stream4: STEALTH ACTIVITY (nmap XMAS scan) detection [**]
08/27-01:27:32.232874 192.168.0.9:35965 -> 192.168.0.99:80
TCP TTL:38 TOS:0x0 ID:65176 IpLen:20 DgmLen:40
**U*P**F Seq: 0x0 Ack: 0x0 Win: 0xC00 TcpLen: 20 UrgPtr: 0x0
 

The snort rule for this alert (below) is basic, yet functional. If it picks up a packet with the FIN,PSH,URG flags set, this alert will be generated. It is possible for a different tool to produce a packet that matches, so its nmap statement is not always 100% reliable.

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"SCAN nmap XMAS";flags:FPU; reference:arachnids,30; classtype:attempted-recon; sid:1228; rev:1;)

On examination of the log file by hand we can see nmap OS fingerprint tests occurring. Nmap has a very powerful OS detection engine, however it does make a lot of noise when run. The below packets are "tell tale" signs that our attackers tool of choice is nmap.

All OS detection packets have not been listed here, the subject of OS Fingerprinting is beyond the scope of this document. To learn more about fingerprinting please see the references section.
 

7) What is the purpose of port scanning?

Port scanning allows an external host with no access rights on the target machine to gather intelligence about what services are offered on the target. It also allows them to get a good idea of OS version and the box's purpose. By knowing what services are available and OS version, an attacker is able to wade through his/her bag of vulnerabilities and pull one out to fit the occasion.

8) What ports are open on our honeypot.

Stepping through the scans, we see the following interesting replies / non replies.

The SYN Scan.

A SYN,ACK is received from the below ports indicating it is open, a RST is then seen sent by the scanner to stop the handshake completing.

No.    Time        Source      Destination  Protocol        Info
123012 1033.630576 192.168.0.9 192.168.0.99 TCP    52198 > domain [SYN] Seq=68054434 Ack=0 Win=2048 Len=0
123013 1033.630625 192.168.0.99 192.168.0.9 TCP    domain > 52198 [SYN, ACK] Seq=808557020 Ack=68054435 Win=5840 Len=0
123018 1033.630730 192.168.0.9 192.168.0.99 TCP    52198 > domain [RST] Seq=68054435 Ack=0 Win=0 Len=0

98977 840.496083 192.168.0.9 192.168.0.99   TCP    52198 > https [SYN] Seq=68054434 Ack=0 Win=2048 Len=0
98978 840.496128 192.168.0.99 192.168.0.9   TCP    https > 52198 [SYN, ACK] Seq=589914892 Ack=68054435 Win=5840 Len=0
98987 840.496274 192.168.0.9 192.168.0.99   TCP    52198 > https [RST] Seq=68054435 Ack=0 Win=0 Len=0

81060 680.600434 192.168.0.9 192.168.0.99   TCP    52198 > sunrpc [SYN] Seq=68054434 Ack=0 Win=2048 Len=0
81061 680.600481 192.168.0.99 192.168.0.9   TCP    sunrpc > 52198 [SYN, ACK] Seq=432066295 Ack=68054435 Win=5840 Len=0
81066 680.600609 192.168.0.9 192.168.0.99   TCP    52198 > sunrpc [RST] Seq=68054435 Ack=0 Win=0 Len=0

18331 158.125521 192.168.0.9 192.168.0.99   TCP    52198 > ssh [SYN] Seq=68054434 Ack=0 Win=2048 Len=0
18332 158.126037 192.168.0.99 192.168.0.9   TCP    ssh > 52198 [SYN, ACK] Seq=4181067645 Ack=68054435 Win=5840 Len=0
18355 158.126248 192.168.0.9 192.168.0.99   TCP    52198 > ssh [RST] Seq=68054435 Ack=0 Win=0 Len=0

97174 826.065937 192.168.0.9 192.168.0.99   TCP    52199 > http [SYN] Seq=1892475220 Ack=0 Win=2048 Len=0
97175 826.065950 192.168.0.99 192.168.0.9   TCP    http > 52199 [SYN, ACK] Seq=579260414 Ack=1892475221 Win=5840 Len=0
97180 826.066086 192.168.0.9 192.168.0.99   TCP    52199 > http [RST] Seq=1892475221 Ack=0 Win=0 Len=0

85085 716.669132 192.168.0.9 192.168.0.99   TCP    52199 > 32768 [SYN] Seq=1892475220 Ack=0 Win=2048 Len=0
85086 716.669146 192.168.0.99 192.168.0.9   TCP    32768 > 52199 [SYN, ACK] Seq=476996509 Ack=1892475221 Win=5840 Len=0
85089 716.669251 192.168.0.9 192.168.0.99   TCP    52199 > 32768 [RST] Seq=1892475221 Ack=0 Win=0 Len=0

    The Null Scan

The following packets were sent to the target and were dropped, indicating open ports.

No.    Time        Source      Destination  Protocol        Info
148067 1285.232838 192.168.0.9 192.168.0.99 TCP     42294 > http     [] Seq=0 Ack=0 Win=4096 Len=0
148155 1286.162828 192.168.0.9 192.168.0.99 TCP     42294 > domain   [] Seq=0 Ack=0 Win=4096 Len=0
149263 1294.522426 192.168.0.9 192.168.0.99 TCP     42294 > https    [] Seq=0 Ack=0 Win=4096 Len=0
149655 1297.622635 192.168.0.9 192.168.0.99 TCP     42294 > sunrpc   [] Seq=0 Ack=0 Win=4096 Len=0
150406 1304.752097 192.168.0.9 192.168.0.99 TCP     42295 > ssh      [] Seq=0 Ack=0 Win=4096 Len=0
 

    The Xmas scan

The following packets were dropped by the target, indicating an open port.

No.    Time        Source      Destination  Protocol        Info
152336 1432.138513 192.168.0.9 192.168.0.99 TCP     58164 > https [FIN, PSH, URG] Seq=0 Ack=0 Win=1024 Urg=0 Len=0
151186 1420.669258 192.168.0.9 192.168.0.99 TCP     58163 > domain [FIN, PSH, URG] Seq=0 Ack=0 Win=1024 Urg=0 Len=0
151437 1422.530933 192.168.0.9 192.168.0.99 TCP     58163 > sunrpc [FIN, PSH, URG] Seq=0 Ack=0 Win=1024 Urg=0 Len=0
153116 1440.188227 192.168.0.9 192.168.0.99 TCP     58163 > ssh [FIN, PSH, URG] Seq=0 Ack=0 Win=1024 Urg=0 Len=0
153113 1440.188116 192.168.0.9 192.168.0.99 TCP     58164 > http [FIN, PSH, URG] Seq=0 Ack=0 Win=1024 Urg=0 Len=0

    The Connect scan

A completed a handshake on the following ports indicates an open state.

No.    Time        Source      Destination  Protocol        Info
153997 1500.786387 192.168.0.9 192.168.0.99 TCP     34398 > http [SYN] Seq=289631970 Ack=0 Win=5840 Len=0
153998 1500.786401 192.168.0.99 192.168.0.9 TCP     http  > 34398 [SYN, ACK] Seq=1296081604 Ack=289631971 Win=5792 Len=0
153999 1500.786504 192.168.0.9 192.168.0.99 TCP     34398 > http [ACK] Seq=289631971 Ack=1296081605 Win=5840 Len=0
154000 1500.786597 192.168.0.9 192.168.0.99 TCP     34398 > http [RST, ACK] Seq=289631971 Ack=1296081605 Win=5840 Len=0

154805 1502.166760 192.168.0.9 192.168.0.99 TCP     34800 > ssh [SYN] Seq=296212951 Ack=0 Win=5840 Len=0
154806 1502.166794 192.168.0.99 192.168.0.9 TCP     ssh   > 34800 [SYN, ACK] Seq=1296230716 Ack=296212952 Win=5792 Len=0
154811 1502.166916 192.168.0.9 192.168.0.99 TCP     34800 > ssh [ACK] Seq=296212952 Ack=1296230717 Win=5840 Len=0
154818 1502.167242 192.168.0.9 192.168.0.99 TCP     34800 > ssh [RST, ACK] Seq=296212952 Ack=1296230717 Win=5840 Len=0

153605 1500.086480 192.168.0.9 192.168.0.99 TCP     34203 > sunrpc [SYN] Seq=284592566 Ack=0 Win=5840 Len=0
153606 1500.086514 192.168.0.99 192.168.0.9 TCP     sunrpc> 34203 [SYN, ACK] Seq=1288214713 Ack=284592567 Win=5792 Len=0
153609 1500.086630 192.168.0.9 192.168.0.99 TCP     34203 > sunrpc [ACK] Seq=284592567 Ack=1288214714 Win=5840 Len=0
153644 1500.087788 192.168.0.9 192.168.0.99 TCP     34203 > sunrpc [RST, ACK] Seq=284592567 Ack=1288214714 Win=5840 Len=0

155545 1503.346705 192.168.0.9 192.168.0.99 TCP     35169 > domain [SYN] Seq=303023968 Ack=0 Win=5840 Len=0
155546 1503.346737 192.168.0.99 192.168.0.9 TCP     domain> 35169 [SYN, ACK] Seq=1298205504 Ack=303023969 Win=5792 Len=0
155549 1503.346853 192.168.0.9 192.168.0.99 TCP     35169 > domain [ACK] Seq=303023969 Ack=1298205505 Win=5840 Len=0
155564 1503.347396 192.168.0.9 192.168.0.99 TCP     35169 > domain [RST, ACK] Seq=303023969 Ack=1298205505 Win=5840 Len=0

154001 1500.866355 192.168.0.9 192.168.0.99 TCP     34399 > https [SYN] Seq=292770159 Ack=0 Win=5840 Len=0
154002 1500.866396 192.168.0.99 192.168.0.9 TCP     https > 34399 [SYN, ACK] Seq=1296564948 Ack=292770160 Win=5792 Len=0
154003 1500.866495 192.168.0.9 192.168.0.99 TCP     34399 > https [ACK] Seq=292770160 Ack=1296564949 Win=5840 Len=0
154004 1500.866564 192.168.0.9 192.168.0.99 TCP     34399 > https [RST, ACK] Seq=292770160 Ack=1296564949 Win=5840 Len=0

    The Xmas scan using Decoys.

The Following IP's are noted to be used by the scanner as decoys:

192.168.0.1
192.168.0.254
192.168.0.199

The following ports did not respond with a RST,ACK when an Xmas scan packet was sent.

No.    Time        Source          Destination  Protocol        Info
158068 1625.114289 192.168.0.1     192.168.0.99 TCP 35964 > ssh [FIN, PSH, URG] Seq=0 Ack=0 Win=3072 Urg=0 Len=0
158069 1625.114337 192.168.0.254   192.168.0.99 TCP 35964 > ssh [FIN, PSH, URG] Seq=0 Ack=0 Win=3072 Urg=0 Len=0
158070 1625.114367 192.168.0.9     192.168.0.99 TCP 35964 > ssh [FIN, PSH, URG] Seq=0 Ack=0 Win=3072 Urg=0 Len=0
158071 1625.114396 192.168.0.199   192.168.0.99 TCP 35964 > ssh [FIN, PSH, URG] Seq=0 Ack=0 Win=3072 Urg=0 Len=0

160982 1642.777581 192.168.0.1     192.168.0.99 TCP 35964 > http [FIN, PSH, URG] Seq=0 Ack=0 Win=3072 Urg=0 Len=0
160983 1642.777639 192.168.0.254   192.168.0.99 TCP 35964 > http [FIN, PSH, URG] Seq=0 Ack=0 Win=3072 Urg=0 Len=0
160984 1642.777655 192.168.0.9     192.168.0.99 TCP 35964 > http [FIN, PSH, URG] Seq=0 Ack=0 Win=3072 Urg=0 Len=0
160985 1642.777701 192.168.0.199   192.168.0.99 TCP 35964 > http [FIN, PSH, URG] Seq=0 Ack=0 Win=3072 Urg=0 Len=0

160674 1641.223556 192.168.0.1     192.168.0.99 TCP 35964 > https [FIN, PSH, URG] Seq=0 Ack=0 Win=3072 Urg=0 Len=0
160675 1641.223616 192.168.0.254   192.168.0.99 TCP 35964 > https [FIN, PSH, URG] Seq=0 Ack=0 Win=3072 Urg=0 Len=0
160676 1641.223630 192.168.0.9     192.168.0.99 TCP 35964 > https [FIN, PSH, URG] Seq=0 Ack=0 Win=3072 Urg=0 Len=0
160677 1641.223682 192.168.0.199   192.168.0.99 TCP 35964 > https [FIN, PSH, URG] Seq=0 Ack=0 Win=3072 Urg=0 Len=0

161280 1644.942886 192.168.0.1     192.168.0.99 TCP 35964 > sunrpc [FIN, PSH, URG] Seq=0 Ack=0 Win=3072 Urg=0 Len=0
161281 1644.942934 192.168.0.254   192.168.0.99 TCP 35964 > sunrpc [FIN, PSH, URG] Seq=0 Ack=0 Win=3072 Urg=0 Len=0
161282 1644.942968 192.168.0.9     192.168.0.99 TCP 35964 > sunrpc [FIN, PSH, URG] Seq=0 Ack=0 Win=3072 Urg=0 Len=0
161283 1644.942997 192.168.0.199   192.168.0.99 TCP 35964 > sunrpc [FIN, PSH, URG] Seq=0 Ack=0 Win=3072 Urg=0 Len=0

160251 1638.742954 192.168.0.1     192.168.0.99 TCP 35964 > domain [FIN, PSH, URG] Seq=0 Ack=0 Win=3072 Urg=0 Len=0
160252 1638.743002 192.168.0.254   192.168.0.99 TCP 35964 > domain [FIN, PSH, URG] Seq=0 Ack=0 Win=3072 Urg=0 Len=0
160253 1638.743031 192.168.0.9     192.168.0.99 TCP 35964 > domain [FIN, PSH, URG] Seq=0 Ack=0 Win=3072 Urg=0 Len=0
160254 1638.743064 192.168.0.199   192.168.0.99 TCP 35964 > domain [FIN, PSH, URG] Seq=0 Ack=0 Win=3072 Urg=0 Len=0
 

In conclusion, The following ports are open on the target.

* The port 32768 was not detected by any other scans because they were configured only to scan ports that have entries in the scanners /etc/services file. In nmap speak, this is called a "Fast Scan"

9) Bonus question: Due to time restraints, this question was not attempted.

References and further reading

• Snort, and open source NIDS System.
• Ethereal: Open source network protocol analyser. 
• tcpdump / libpcap. 
• nmap : The network mapper.
• nmap : OS Fingerprinting.
• Scan types with nmap.
• RFC Search.
• TCP Port assignments.