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

John Berkers berjo at ...827...
Thu Sep 27 20:12:02 EDT 2001


That has been my experience.  We have a sensor behind a firewall (different
box) that has been configured to allow traffic though to a range of
addresses that are in the DMZ.  Not all of these addresses have been used as
yet, therefore the SYN packet gets through for all the ips.

For actual web servers we see the full code red, but for the unallocated
addresses we see only the SYN.

If you have a firewall and snort sensor on the same box, and this is the
same box as, or is a gateway for the web server then you will see only the
SYN packet.  If you have a passive sensor (No IP, completely firewalled)
then you should see all traffic since the firewall is not interfering with
the production traffic you are monitoring.

Hope that clarifies things a bit.

Regards,

John Berkers

-----Original Message-----
From: snort-users-admin at lists.sourceforge.net
[mailto:snort-users-admin at lists.sourceforge.net]On Behalf Of Bob
Hillegas
Sent: Friday, 28 September 2001 12:35
To: snort-users at lists.sourceforge.net
Cc: JSeddon at ...2969...; John Sage
Subject: [Snort-users] Re: Snort Behind IPtables, contradicting
evidence...


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 ---
#!/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 at ...3133...>
281.546.9311






_______________________________________________
Snort-users mailing list
Snort-users at 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





More information about the Snort-users mailing list