SYSTEM WARNING: 'date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.' in '/usr/share/mantis/www/core.php' line 264

0004416: No snort chain created after enabling snort - MantisBT
MantisBT - Endian Firewall
View Issue Details
0004416Endian FirewallFirewall (iptables)public2012-08-09 10:242012-08-13 21:07
ardit-endian 
 
normalblockalways
confirmedopen 
2.5 
 
0004416: No snort chain created after enabling snort
The Snort / iptables rules are to be reviewed entirely, I already tested this on 2 mini's (arm - 2.5 full up-to-date at the moment).

I enabled snort and nothing was added on the iptables chain, than I updated the rules, than changed some rules from detect to drop but again:

root@kyle:~ # iptables -nvL -t mangle | grep -i snort
root@kyle:~ # iptables -nvL -t nat | grep -i snort
root@kyle:~ # iptables -nvL | grep -i snort
root@kyle:~ #

Normally snort chain shows up in Filter table connected with the FORWARD chain.

purple
Issue History
2012-08-09 10:24ardit-endianNew Issue
2012-08-09 10:24ardit-endianStatusnew => confirmed
2012-08-09 10:25ardit-endianTag Attached: purple
2012-08-13 21:07gracedmanNote Added: 0008009

Notes
(0008009)
gracedman   
2012-08-13 21:07   
I believe that was 2.4 behavior. In 2.5, we are seeing a different issue. In 2.5, it looks like the packet processing is that packets are dropped into the ALLOW chain. From there, they are jumped to ALLOW_HOOKS. In ALLOW_HOOKS, anything destined for SNORT is sent to the QUEUEFW chain. In the QUEUEFW chain, there are two RETURN rules - one for lo traffic and the other for GREEN zone traffic. If SNORT is activated, there is a third rule jumping packets to the QUEUE target where SNORT handles them in userspace.

Here is a portion of the bug report we emailed to our Endian SE:

Here's what I see on stock Endian with SNORT disabled when tracing the path of a packet from the world to the 10443 management interface (which I allowed). Packets arrive on INPUT and fall through to INPUTFW. From there, they are jumped to the ALLOW chain. ALLOW jumps them to ALLOW_HOOKS which is empty when SNORT is disabled. It contains a jump to QUEUEFW when SNORT is enabled. So the packet returns to ALLOW where it is jumped to QUEUEFW whether or not SNORT is enabled (thus, when SNORT is enabled, it is sent to QUEUEFW twice - first via ALLOW_HOOKS and then via ALLOW).

QUEUEFW is the interesting and possibly problematic chain. With IDS enabled, it has a rule to return traffic from lo and br0. These rules appear to come from /etc/firewall/queuefw/iptablesqueuefw. I wrote to you earlier asking how that file is populated as I cannot find it. In any event, with IDS disabled, the packet falls through, returns to ALLOW where it meets a ACCEPT all rule. Everything works.

If I enable IDS, we go from INPUTFW to ALLOW to ALLOW_HOOKS to QUEUEFW where it encounters a jump to the QUEUE target (-j QUEUE). This hands it off to userspace for SNORT processing. It never returns to the kernel so, if SNORT is not running, the packet dies. When SNORT is running, it is processed, SNORT allows it, and all is fine.

The problem is, when I disabled SNORT from the web interface, it removes all the rules from ALLOW_HOOKS but it does not remove the jump from ALLOW to QUEUEFW. That would not be a problem except that it also does not remove the -j QUEUE rule from QUEUEFW. Thus, the packet is sent to userspace and, without SNORT running, it dies and all communication fails.

Is that a bug or expected behavior? I could understand someone saying that, if IDS is not running, we want to shut down the box from the outside world. However, not only is this problematic for remote management if the remote manager disabled SNORT but, if one reboots the box, the -j QUEUE rule disappears and one can access from the outside world again. So, it does not seem intentional; it seems like a bug.

Can you confirm this behavior?

If you can tell me how iptablesqueuefw is populated, I'll see if I can patch it.