The next step in our analysis is to figure out what services the machines behind the NAT gateway are offering. We are first interested in how many snort signatures require the destination machine to accept connections in order to fire (i.e., meaning that the service exists on the target system). The flow keyword in snort signatures makes sure that the signature only triggers after a connection to the destination service has been established. In addition, snort signatures have a content keyword, which looks at packet contents. This can, to a certain extent, make sure that snort does not trigger on bogus traffic where no destination service is present. Assuming that TCP SYN packets do not carry any content (this is not always true), we can argue that only after a successful handshake between the attacker and the target service, content can be transmitted over the wire. This would require the target service to be present. Here are some numbers we collected:
The fact that 425 signatures are triggering without making sure that a flow is established, is somewhat disappointing. The 132 signatures which do not check for a flow nor do they check the content, are even worse. Firstly these signatures are very prone to false positives. Even if the destination machine does not offer the service these signatures are still going to trigger. Secondly, when we are going determine what services the destination machines offer, we cannot take these signatures into account. We will continue on the idea of mapping out destination services for machines a little later.
To quickly see whether it makes sense to map the destination services to machines, despite the findings from above, we ran a couple of queries to see what target ports are accessed. The results in Table 2.1 are again very interesting and nicely support our findings from before. The top signatures triggering are those with very simple definitions and only look at the destination port along with some other properties2.14. In some cases source and destination are inverted. Normally a TCP connection is initiated from a source port that is bigger than 1024. In the case of Linux, it's even above 327682.15 and services offered by a machine are typically below 1024. The ports in Table 2.1, however, show some quite anomalous ports. Destination ports above 60000 are very uncommon.
Figure 2.11 shows a few source, destination port combinations after filtering out the most common destination ports. Again, very uncommon port pairs show up. For example, there are many source ports of 80. This probably indicates that there are snort signatures which trigger on Web responses as opposed to Web requests.
Taking the data from Figure 2.11 and adding the count per connection yields Figure 2.12. Some interesting port pairs suddenly show up. After filtering out the most frequent connections, connections from port 6666 to port 62513 are surfacing. There are also connections from port 0 to port 0, as well as connections from port 53 to port 53. Some of the connections from port 0 to port 0 are there because we used a database and the ports show up as zero, if they are not set. These are most likely ICMP packets or IP fragments. We also have 53 packets that are from an FTP data connection (source port of 20). A lot of the connections in Figure 2.12 expose very strange port pairs, which do not make much sense.
|
More interesting packets resulted when we generated a graph of all the communications from a port below 1024 to a port below 1024 (see Figure 2.13. This is not something that normally happens.
|
We now have some understanding of what is going on, but still have no idea what services are running on the machines. To address this problem, we first generated a snort alert file:
snort -c /etc/snort/snort.conf.complete -UDek none -r /tmp/sans -l snortlog
Note that the configuration file we passed to Snort is one that includes all the .rules files. By default this is not the case. We removed all the flow: parameters from the rules. Otherwise only a fraction of all the log entries will generate a snort alert, because snort is expecting a flow to be established. This will never be the case, because the logs only contain the packets immediately triggering the rules. The -U flag in the snort command changes the time format to use UTC. This is used to match the timestamps with the alerts in the database. The database with the packet information was then updated with the additional snort alerts.2.16. In a next step, we flagged all the entries in the database that were generated by rules requiring an established flow2.17. All this helpts to make a statement about what services the machines really offer. Figure 2.14 is a first pass on showing the services available on target machines2.18. As you can see, there are some strange services showing up:
X11 outbound client connection detected have the ports inverted because the snort alert triggers on the response packets.
WEB-CLIENT readme.eml autoload attempt
P2P Napster Client data
Virus - Possible MyRomeo Worm
CHAT AIM receive message
Virus - SnowWhite Trojan Incoming
CHAT IRC message
P2P GNUTella client request packets are associated with varying high ports. These ports cannot be associated with services.
All the information combined results in Figure 2.15, which shows a corrected version of the graph, with the real services exposed by the machines.
|
During the process of identifying the role of machines, we found two of them which need some further investigation. Both machines are running some kind of a server and X11 outbound connections were identified to the machines. It seems that the security policy should prohibit such behavior. We will investigate those two machines (32.245.166.236 and 138.97.18.88) in Section 3.4.
To determine the operating systems running on the machines, we ran the dataset through p0f[26]. The results were both interesting as well as disappointing. p0f heavily relies on analyzing TCP SYN packets. In our logs, however, there are not very many of those and the analysis fails for all the hosts of interest. We already tried to identify the operating systems via the TTLs in the network traffic, which also failed. This pretty much leaves us in the dark with regards to the OSes of the machines.
All this information taken together, we were able to build Table 2.2 that shows the machines in the protected network and their probable roles.