Using Session Data to Scope Events Without Signatures
Critics of intrusion detection systems say signature-based IDSs are too easy to evade, bypass, or fool. This is true when the IDS only provides alert data to analysts. Alerts are the results of judgements made by the IDS developers, as encoded in the IDS' rules and logic. To deal with events that have no signatures, we can turn to other forms of network security monitoring data.
Session data is a record of transactions between parties, typically storing source and destination IP addresses and ports, session start and end times, and counts of packets and bytes of data sent by source and destination. Session data is best captured for connection-oriented TCP traffic, but sessions can be emulated for connectionless protocols like UDP and ICMP in a request-response model.
Session data is immune to encryption, because no payloads are captured. Session data is also not dependent on signatures, because every transaction is recorded. This "neutrality" makes session data an excellent candidate for investigating events for which no signatures exist, albeit in an "after-the-fact" manner.
The recent MyDoom variant represents a case where session data can be used to determine if hosts have been infected. We can ask Sguil to check its session database for evidence of connections to port 1034 TCP, after reading the report by the SANS Internet Storm Center:
This SQL query excerpt says to check for sessions with source or destination ports of 1034 TCP, but to omit sessions with ports 80 or 443 TCP. This is a way to ignore outbound Web browsing records.
Here are partial sample results for 26 July 2004, omitting src_bytes, dst_pckts, and dst_bytes, which are all 0 in this case:
These results show us that host 1.2.3.4 began making outbound connections to port 1034 TCP at 17:37:49. This is a strong indicator that 1.2.3.4 is infected by the latest MyDoom variant. Should any inbound connections to port 1034 TCP on 1.2.3.4 appear, we know someone is making use of this backdoor.
If you're not running Sguil, you can use Argus to collect session data. SANCP by John Curry is another option, one which is included in Sguil. The default session data recording in Sguil uses Snort's stream4 preprocessor keepstats function.
If you'd like to know more about using session data to scope intrusions and other security events, please see chapters 7 and 15 in my Tao of Network Security Monitoring.
Session data is a record of transactions between parties, typically storing source and destination IP addresses and ports, session start and end times, and counts of packets and bytes of data sent by source and destination. Session data is best captured for connection-oriented TCP traffic, but sessions can be emulated for connectionless protocols like UDP and ICMP in a request-response model.
Session data is immune to encryption, because no payloads are captured. Session data is also not dependent on signatures, because every transaction is recorded. This "neutrality" makes session data an excellent candidate for investigating events for which no signatures exist, albeit in an "after-the-fact" manner.
The recent MyDoom variant represents a case where session data can be used to determine if hosts have been infected. We can ask Sguil to check its session database for evidence of connections to port 1034 TCP, after reading the report by the SANS Internet Storm Center:
WHERE sessions.start_time > '2004-07-20' AND
(sessions.src_port = 1034 or sessions.dst_port = 1034)
and sessions.dst_port != 80 and sessions.src_port !=80
and sessions.dst_port != 443 and sessions.src_port != 443
LIMIT 500
This SQL query excerpt says to check for sessions with source or destination ports of 1034 TCP, but to omit sessions with ports 80 or 443 TCP. This is a way to ignore outbound Web browsing records.
Here are partial sample results for 26 July 2004, omitting src_bytes, dst_pckts, and dst_bytes, which are all 0 in this case:
start_time src_ip src_port dst_ip dst_port src_pckts
17:37:49 1.2.3.4 47076 15.136.19.27 1034 6
17:38:10 1.2.3.4 47146 16.138.31.128 1034 6
17:38:31 1.2.3.4 47209 16.190.234.172 1034 6
17:38:52 1.2.3.4 47235 16.49.36.18 1034 6
17:39:13 1.2.3.4 47317 16.133.77.85 1034 6
These results show us that host 1.2.3.4 began making outbound connections to port 1034 TCP at 17:37:49. This is a strong indicator that 1.2.3.4 is infected by the latest MyDoom variant. Should any inbound connections to port 1034 TCP on 1.2.3.4 appear, we know someone is making use of this backdoor.
If you're not running Sguil, you can use Argus to collect session data. SANCP by John Curry is another option, one which is included in Sguil. The default session data recording in Sguil uses Snort's stream4 preprocessor keepstats function.
If you'd like to know more about using session data to scope intrusions and other security events, please see chapters 7 and 15 in my Tao of Network Security Monitoring.
Comments