Snort mailing list archives
Re: Snort Behind IPtables, contradicting evidence...
From: Bob Hillegas <bobhillegas () pdq net>
Date: Thu, 27 Sep 2001 21:34:40 -0500 (CDT)
If you're interested in snort versus firewall discussion read on. Otherwise this gets kind of deep. Sorry. The question I'm trying to answer is: Does snort on the same box as a packet filter see all the traffic? I think my analysis says yes. That then begs the question, why don't you see any codered traffic in this configuration? I think the answer is that when you DENY packets, you stop the codered transmission at the first SYN packet. It never receives a SYN-ACK, so you never get back the final ACK or any payload. Someone who has received the full codered transmission can comment more authoritatively than I on that. On Thu, 27 Sep 2001 JSeddon () semtech com wrote:
Message: 4 To: snort-users () lists sourceforge net From: JSeddon () semtech com Date: Thu, 27 Sep 2001 08:53:46 -0700 Subject: [Snort-users] Snort Behind IPtables, contradicting evidence... Honorable Oinkers, I fretted a long time before I sent this because I know it's been discussed many times and we are all very busy. However, I wanted to bring it up because either I am missing or misreading something or the evidence I have seen does not support the consensus reached on this list. I'm running snort on my firewall and have questions about whether snort will see traffic that iptables is configured to block. The question is, "If you run snort on a box with iptables blocking/filtering stuff, will snort see/process all the traffic?". I gleaned over the archives and it seems the consensus of the list was that "yes, snort will see the traffic". One reason given was that the packet capture library takes packets and passes them to snort before the normal tcp stack processing. So, iptables doesn't get a chance to see it. There were also several people who said they were running snort on iptables firewalls and it was working fine. However, I wasn't seeing the waves of Code Red traffic (or nimda for that matter). I thought that perhaps my ISP was filtering the Code Red Traffic. Just for kicks, I flushed my iptables chains. BAM! Snort starting alerting on all kinds of Code Red traffic. Ran rc.firewall again, no snort alerts. Hmmm..I said, maybe a coinky dink....Flushed again, waves of code red alerts....put the rules back in the chains....No alerts...I decided to let it go a day...sure enough, no rules in chains and snort sees the traffic, put the rules back in the chains and snort doesn't. This seems to contradict the conclusion I got from the list archives. It seems that iptables is processing traffic before snort gets a chance to see it. Snort is putting the NIC in promiscuous mode. But it doesn't see traffic iptables is configured to block unless I flush the IPtables rules. Is something misconfigured with snort for me? Did I draw the wrong conclusion from the list? Architecture: x86 OS: RedHat 7.1 Rules: Snort.org standard rules Command Line: snort -c /etc/snort/snort.conf -d -D -h myfirewall.ext.ip/32 -i eth0 Other: It is a ClarkConnect box (www.clarkconnect.org, pretty neat toy actually). Oinker (still a Piglet) James
OK. Here's my two cents worth. I have a one-box-does-it-all server, firewall, sensor connected to internet using external 56K modem. Not the greatest but OK for a home network of three boxen. I receive a different IP address from my ISP on each connection, so I have to refresh my IPChains logic (haven't made the jump to IPtables yet) and snort each time. I'm using on-demand ppp on a RedHat 7.1 box. That means that /sbin/ppp-watch is invoked from /etc/sysconfig/network-scripts/ifup-ppp when the ppp0 interface is brought up. /sbin/ppp-watch daemon detects activity which requiring the modem and executes /etc/ppp/ip-up and subsequently kills the connection on idle time out by executing /etc/ppp/ip-down. The net result is that I use /etc/syscofig/network-scripts/ifup-local and /etc/sysconfig/network-scripts/ifdown-local to start and stop the firewall and snort. ifup-local is listed here: --- snip --- #!/bin/sh logger -t SCRIPT -p local0.info "++++ ($0) ($*) ++++" DEVICE=$1 DEVICETYPE=`echo $DEVICE | sed "s/[0-9]*$//"` if [ "$DEVICETYPE" != "ppp" ]; then exit 0 fi if echo ${DEVICE} | grep -q ':' ; then ISALIAS=yes else ISALIAS=no fi if [ "$ISALIAS" = "yes" ]; then exit 0 fi # -------------------------------------------------------------------- # Invoke ipchains firewall script /etc/sysconfig/network-scripts/fw_ipchains ${DEVICE} # -------------------------------------------------------------------- # Invoke snort using ${DEVICE} # pidfile: /var/lock/snort_${DEVICE}.pid # config: /etc/snort/snort.conf SNORTCONF="/etc/snort/snort.conf" DAEMON="/usr/local/bin/snort" # Source function library. if [ -f /etc/rc.d/init.d/functions ] ; then . /etc/rc.d/init.d/functions # Check that snort.conf exists. if [ -r ${SNORTCONF} -a -x ${DAEMON} ]; then ## daemon $DAEMON -i ${DEVICE} -u snort -g snort -z est -c ${SNORTCONF} -D daemon $DAEMON -i ${DEVICE} -u snort -g snort -z all -c ${SNORTCONF} -Db -l /var/log/snort fi ## end of snort.conf fi ## end of function library # -------------------------------------------------------------------- # Inserted to invoke fetchmail when ppp+ interface goes up. RLH 09/10/00 sleep 5 logger -t SCRIPT -p local0.info "++++ fetchmail invoked by ifup-local ++++" /usr/bin/fetchmail -af /etc/.fetchmailrc exit 0 --- /snip --- ifdown-local is listed here: --- snip --- #!/bin/sh logger -t SCRIPT -p local0.info "++++ ($0) ($*) ++++" PATH=/sbin:/usr/sbin:/bin:/usr/bin . /etc/rc.d/init.d/functions DEVICE=$1 DEVICETYPE=`echo $DEVICE | sed "s/[0-9]*$//"` if echo ${DEVICE} | grep -q ':' ; then ISALIAS=yes else ISALIAS=no fi if [ "$ISALIAS" = "yes" ]; then exit 0 fi if [ "${DEVICETYPE}" = "ppp" -o "${DEVICETYPE}" = "ippp" ]; then /usr/local/bin/packets ##--------------------------------------------------------------- ## Kill snort daemon process when ppp goes down killproc snort_${DEVICE} -USR1 # Output stats from session sleep 3 # Give -USR1 time to complete killproc snort_${DEVICE} -TERM # Terminate snort fi ## end ppp exit 0 --- /snip --- You will from these that I use the function library entries daemon and killproc to start and stop snort. Sorry for all the details. Hope it's worth the read. Here is my snort.conf: --- snip --- var HOME_NET $ppp0_ADDRESS var EXTERNAL_NET any var SMTP $HOME_NET var HTTP_SERVERS $HOME_NET var SQL_SERVERS $HOME_NET var DNS_SERVERS $HOME_NET preprocessor frag2 preprocessor stream4: detect_scans preprocessor stream4_reassemble preprocessor http_decode: 80 -unicode -cginull preprocessor rpc_decode: 111 preprocessor bo: -nobrute preprocessor telnet_decode preprocessor portscan: $HOME_NET 4 3 portscan.log output alert_syslog: LOG_AUTH LOG_ALERT include classification.config log tcp any any -> any any (msg:"Trap all tcp traffic";) log udp any any -> any any (msg:"Trap all udp traffic";) log icmp any any -> any any (msg:"Trap all icmp traffic";) include exploit.rules include scan.rules include finger.rules include ftp.rules include telnet.rules include smtp.rules include rpc.rules include rservices.rules include backdoor.rules include dos.rules include ddos.rules include dns.rules include netbios.rules include web-cgi.rules include web-coldfusion.rules include web-frontpage.rules include web-iis.rules include web-misc.rules include sql.rules include x11.rules include icmp.rules include shellcode.rules include misc.rules include policy.rules include info.rules include icmp-info.rules include virus.rules include local.rules --- /snip --- You can see that I am logging all tcp, udp, and icmp traffic to a binary file. I also initialize my ipchains (Z command) to zero out all packet counts each time I initialize the packet filter. I then can do a /sbin/ipchains --list -v -n in order to see how many packets entered through the ppp0 interface. Between the stats which get writtem to syslog when I kill -USR1 snort.pid, the packet totals accumulated by ipchains, and the stats read off of snort -dev -r /var/log/date.snort.log, I conclude that snort sees all the packets that ipchains sees. I can in fact grep the snort binary file for individual packets which ipchains has logged in syslog as DENY'd and find them. What I rarely get is alerts. I am assuming that the packet filter stops the transmission prior to any recognizable payload from being sent. This is overly log already, so I'll close for now. Comments? BobH -- ------------------------------------------------- Bob Hillegas <bobhillegas () pdq net> 281.546.9311 _______________________________________________ Snort-users mailing list Snort-users () lists sourceforge net Go to this URL to change user options or unsubscribe: https://lists.sourceforge.net/lists/listinfo/snort-users Snort-users list archive: http://www.geocrawler.com/redir-sf.php3?list=snort-users
Current thread:
- Snort Behind IPtables, contradicting evidence... JSeddon (Sep 27)
- Re: Snort Behind IPtables, contradicting evidence... John Sage (Sep 27)
- <Possible follow-ups>
- Re: Snort Behind IPtables, contradicting evidence... Bob Hillegas (Sep 27)
- RE: Re: Snort Behind IPtables, contradicting evidence... John Berkers (Sep 27)
- Re: Re: Snort Behind IPtables, contradicting evidence... John Sage (Sep 27)
- Re: Re: Snort Behind IPtables, contradicting evidence... JSeddon (Sep 27)
- RE: Re: Snort Behind IPtables, contradicting evidence... Martijn Heemels (Sep 28)