From: Peter K. L. <sa...@co...> - 2004-08-02 22:21:54
|
I found out a solution, although I have no idea why it works. Since I just couldn't understand what was going on, I started crawling around the packet traversal code specific to snort_inline and found that it's really just a simple abstraction layer to pulling data off of libipq. So I copy & pasted the test code in libipq manpage, compiled and ran in place of snort_inline with all packets set to NF_ACCEPT. Well, it looked like there was nothing wrong with kernel or libipq or iptables since using the same test FORWARD iptables rule, the data packets didn't disappear. After a brief look at the snort_inline portion of snort, it wasn't doing anything too different than the code in the manpage so I started to question snort. I was running snort_inline with -i set to eth0, switching it back and forth between eth0 and eth1 based on which direction I wanted the snort_inline to analyze. But, when I removed that piece altogether, it all began to work. I suppose libipq does not care which interface the target QUEUE comes from, as long as it's in the QUEUE the requestor can get access to it. Perhaps the -i flag has more relevance just for 'snort' when it is running the signature analysis of the data, and somehow sets the status to be 'silently drop' by default when *some* internal state doesn't match up? even if there is NO rule for it to take such action? I have no idea... but w/o it everything seems to be happy. -Peter |