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 Endian Bugtracker
Endian Issue Tracker





Please see now our new Bugtracker system: JIRA








View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004416Endian FirewallFirewall (iptables)public2012-08-09 10:242012-08-13 21:07
Reporterardit-endian 
Assigned To 
PrioritynormalSeverityblockReproducibilityalways
StatusconfirmedResolutionopen 
PlatformOSOS Version
Product Version2.5 
Target VersionFixed in Version 
Summary0004416: No snort chain created after enabling snort
DescriptionThe 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.

Tagspurple
Attached Files

- Relationships

-  Notes
(0008009)
gracedman (reporter)
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.

- Issue History
Date Modified Username Field Change
2012-08-09 10:24 ardit-endian New Issue
2012-08-09 10:24 ardit-endian Status new => confirmed
2012-08-09 10:25 ardit-endian Tag Attached: purple
2012-08-13 21:07 gracedman Note Added: 0008009

Copyright © 2005-2008 Endian, SRL. All rights reserved.


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker