[Snort-users] Re: Snort Behind IPtables, contradicting evidence...

Bob Hillegas bobhillegas at ...3133...
Thu Sep 27 19:41:03 EDT 2001

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 at ...2969... wrote:

> Message: 4
> To: snort-users at lists.sourceforge.net
> From: JSeddon at ...2969...
> 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 ---
logger -t SCRIPT -p local0.info "++++ ($0) ($*) ++++"

DEVICETYPE=`echo $DEVICE | sed "s/[0-9]*$//"`
if [ "$DEVICETYPE" != "ppp" ]; then
	exit 0
if echo ${DEVICE} | grep -q ':' ; then
if [ "$ISALIAS" = "yes" ]; then
	exit 0

# --------------------------------------------------------------------
# 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


# 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 ---
logger -t SCRIPT -p local0.info "++++ ($0) ($*) ++++"


. /etc/rc.d/init.d/functions


DEVICETYPE=`echo $DEVICE | sed "s/[0-9]*$//"`
if echo ${DEVICE} | grep -q ':' ; then
if [ "$ISALIAS" = "yes" ]; then
	exit 0

if [ "${DEVICETYPE}" = "ppp" -o "${DEVICETYPE}" = "ippp" ]; then
## 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 ---

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

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

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

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?

Bob Hillegas
<bobhillegas at ...3133...>

More information about the Snort-users mailing list