[Snort-users] Unexpected results with reputation preprocessor - solved

Dave Corsello snort-users at ...15598...
Tue May 13 07:50:34 EDT 2014

About 2 months ago, I reported strange results with the reputation 
preprocessor.  Often, when an inbound packet was blocked, an alert was 
also generated for an outbound packet with the addresses from the first 
packet reversed.  It seemed impossible for there to be an outbound 
response if the inbound traffic was blocked.  Testing confirmed that 
SMTP traffic from a known blocked address truly was dropped, adding to 
my confusion.  Joel suggested that the inbound connection, although 
reported as dropped, was not actually dropped, and that the connection 
failed because the outbound response was dropped.  This turned out to be 
the case.  PCAPs showed that during the TCP handshake on an inbound SMTP 
connection, the inbound SYN packet was getting through Snort.  After a 
lot of debugging and help from Hui Cau, I found that the problem was due 
to missing parameters in my snort startup command.  I was trying to 
start snort in inline mode with the following command:

snort --daq nfq -c /etc/snort/snort.conf -Q -D

This seemed to be working fine for quite awhile.  I was using the 
default queue number 0, and bad traffic across the network bridge was 
being dropped. Then I enabled reputation blocking, and started seeing 
problems.  I ended up checking out James Lay's document, "Changing from 
IDS to IPS with NFQueue" at www.snort.org/docs, which showed the command 

snort -Q --daq nfq --daq-var device=br0 --daq-var queue=1 -c 

So, I changed the queue number in my iptables config to 1 (not sure if 
this was necessary), changed my snort command line to the above, adding 
daq vars to specify the device and queue number, and SYN packets from 
reputation-blocked addresses stopped making it through snort.  Problem 

Thanks to Joel and Hui for corresponding with me about this, and to 
James for his document.

More information about the Snort-users mailing list