I am trying to run snort_inline on one of my linux boxes, but I can't seem to get it to stop any traffic. I believe I have iptables configured with queueing support and I have libnet and snort_inline installed and compiled.
Snort_inline will start correctly and seems to be running, but I wrote a very simple rule to test it out:
drop tcp $HONEYNET any -> 169.xxx.xxx.81 80
I then do a wget from one of the honeynet machines to 169.xxx.xxx.81, hoping snort_inline will stop it, but it seems to let it through.
I am using portions of the rc.firewall script found here:
particularly, this section:
### These define the handlers that actually limit outbound connection.
# tcpHandler - The only packets that should make it into these chains are new
# connections, as long as the host has not exceeded their limit.
iptables -A tcpHandler -j LOG --log-prefix "OUTBOUND CONN TCP: "
if test $QUEUE = "yes"
iptables -A tcpHandler -j QUEUE
iptables -A tcpHandler -j ACCEPT
when I do iptables -v --list I see that the packets are being passed to QUEUE, but never to accept, even though they are being allowed out. Is this normal behavior? Are the QUEUE and ACCEPT rules mutually exclusive, as in you either need one or the other? I had the impression that QUEUE would decide whether or not to drop it only, and would simply pass it back if it wasn't dropped which would then cause it to get passed to ACCEPT with the ACCEPT rule:
Chain tcpHandler (2 references)
pkts bytes target prot opt in out source destination
2 120 LOG all -- any any anywhere anywhere LOG level warning prefix `OUTBOUND CONN TCP: '
2 120 QUEUE all -- any any anywhere anywhere
0 0 ACCEPT all -- any any anywhere anywhere
I have uncommented this logging output in snort_inline.conf:
# [Unix flavours should use this format...]
output alert_syslog: LOG_AUTH LOG_ALERT
and also have this logging enabled, which another person in the group told me to use:
output alert_full: snort_inline-full
output alert_fast: snort_inline-fast
Neither one of them seem to generate any type of logs for the packets that are being passed to it however.
Any ideas on how I might go about troubleshooting this or figuring out what is going wrong. Any thoughts would be greatly appreciated. Thanks!
After doing some research I figured out that once something is passed to QUEUE it will have it's verdict decided there and won't have to be passed back to the chain. This was a pretty clear explanation:
After trying out some other test rules, I realized I just made a stupid mistake in the one rule I was trying. I'm sorry to have not tried a little harder on the problem before posting. Thanks for the awesome software!
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.