Here are the notes from our 9/6/07 BLUG meeting
presentation submitted by Jeremiah Gray
for posting to the BLUG list.
IDS & IPS with Snort
Intrusion detection and intrusion prevention have been popular topics of
computer security, and many of those conversations probably involve Snort at
some point or another. Snort is a highly configurable intrusion detection
system, that can work as either a host-based or network-based IDS or IPS.
The key difference between an IPS and an IDS is that an IDS generates
sophisticated logs based on rules regarding attack signatures, but it does
not take action against the attackers. An IPS, on the other hand, can be
used to rewrite firewall rules on the fly to keep out traffic that has been
detected as malicious. Snort is a popular open source application that is
used by over 100,000 businesses worldwide and has portions of its code
embedded into no less than 45 commercially-available appliances.
IDS
An IDS monitors network traffic and will generally work in one of the
following ways:
– Signature detection – where it inspects packets and compares them to a
list of known attack signatures. Because Signature detection systems check
against an existing list of attack signatures, it is more likely that new
and innovative attacks can pass through the IDS undetected. This is called
a false negative.
– Anomaly detection – where the software learns what is “normal” on your
network and alert you to abnormal traffic. Anomaly detection will more
often result in producing false positives, which is to say you will be
alerted about normal activity.
Snort uses Signature detection, with rules available in various locations:
http://snort.org/pub-bin/downloads.cgi – ($, sub, unsub)
http://www.bleedingthreats.net
* Oinkmaster (perl script) recommended for rules management
An IDS will generally be deployed in one of two fashions:
– Host-based IDS
– Monitors incoming packets and compares against rules to determine
response
– Examine system logs for unusual entries such as repeated login
attempts (with statefulness)
– Verifies filesystem integrity
– Network-based IDS
– Monitors all subnet traffic, requiring the NIC to be in promiscuous
mode (achieved with libpcap)
– Generates real-time alerts for attacks
– Writes log files to help with the subsequent exploitation
investigation
– Expects CIDR notation (ie class c ip 192.168.1.0 with subnet
255.255.255.0 becomes 192.168.1.0/24)
Path of a Packet in IDS System:
1. PCAP sends unprocessed data link frame from NIC to Snort
2. Packet Decoder decodes data link, then network, then transport layers
3. Preprocessor plugins operate on network (IP) layer and initially divert
packets away from detection engine – statefulness comes from these
– Preprocessors include:
– Stream4 – TCP stream reassembly & stateful analysis, combats
“stick” and “snot” attack tools
– frag2 – Similar to Stream4 but for protecting against fragmented
IP headers
– SnortSam – plugin that allows sophisticated targeting based on IP
address
4. Detection engine performs the main task which is to determine what gets
marked as what and why
– Snort has the following output modules:
– alert_syslog – writes alert out to /var/log/messages
– alert_fast – writes single lines to a designated file
– alert_full – slow and not recommended for production use
– log_tcpdump – writes to binary file, accessible like other tcpdump
files
– database – logs file to user-configured database
– Snort’s Detection Engine has the following Rules which apply to icmp,
ip, tcp, and udp:
– alert – generates an alert and logs the packet
– log – logs the packet
– activate – alert and then turn on a dynamic rule
– dynamic – like a log rule but only when activated by activate rule
– Snort Rules have the following Options:
– meta-data – provide info about rule but don’t affect detection
– payload – look for data in packet payload
– non-payload – look for non-payload data
– post-detection – rule-specific triggers that happen after rule
runs
– A Snort rule might look like this:
– drop tcp $EXTERNAL_NET 27374 -> $HOME_NET any (msg:”BACKDOOR
subseven 22″; flow:to_server,established;content:”|0D 0A|[RPL]002|0D 0A|”;
reference:arachnids,485; reference:url,www.hackfix.org/subseven/;
classtype:misc-activity; sid:103; rev:7;)
* Note, do not run Snort as root.
** You will need to run Snort as root if you run IPS mode (inline) and
therefore should probably have a dedicated snort box – a dedicated Snort
sensor generally runs ~130 processes total.
=========================
Visual presentation apps: Sguil, ACID
IPS
Snort Inline as Intrusion Prevention System
Snort can also be used in conjunction with libipq instead of libpcap in
order to rewrite iptables rules as needed to divert malicious packets.
Snort Inline used to be a separate app, but is now included as part of
snort. Obviously you have to be careful to not lock yourself out, and
moreover, to patch all of your code because however handy Snort is, once
you’re exploited, it’s working against you. As such, using a preprocessor
like SnortSAM and whitelisting a specific IP you can always reach might not
be a bad idea.
– Need iptables with install-devel which loads libipq and allows QUEUEing in
iptables
– Need LibNet from packetfactory.net
Inline Rules slightly different – as such rules will need to change:
– drop – iptables drops packet, normal snort log
– reject – iptables drops packet, TCP reset sent and if that fails, UDP
reset sent
– sdrop – iptables drops, no log entry
Snort Inline allows for replacing packet payload but the content must of the
same length.
Preprocessor options slightly different. For example, Streatm4 option
“inline_state” drops TCP packets not associated with existing TCP sessions
outright. Also, because we’re dealing with iptables for input, we lose
layer 2 data and are left with network and up.
Snort is a useful part of a security strategy; it does not protect against
exploits in your other apps and it does not detect anomalies. For
information on exploits and patching them, check out:
www.secwatch.org
www.milw0rm.com