On Sat, Mar 31, 2012 at 10:09:42PM +0800, Amm Snort wrote: > Hello all, > > I would like to suggest a feature (additional parameter) for NFQUEUE target. > > I am basically trying to use snort with NFQUEUE. > > Basic iptables rule is somewhat like this: > > iptables -A INPUT -i ppp1 -j NFQUEUE > iptables -A INPUT -p tcp --dport 22 -j ACCEPT > iptables -A INPUT -j DROP > > Idea is to pass all packets to snort first and then if snort detects trojan signature then > it can DROP (IPS) the packet (drop rule of snort). If snort detects port scan it can > LOG but still ACCEPT (IDS) (alert rule of snort). If snort ACCEPTs the packet then > continue processing next rule. > > On side note, this idea also reduces load on snort as it does not have to sniff every > packet coming on network card and also we can pass only selected packets to snort. > > > This idea however, DOES NOT work because currently when QUEUE program (snort) > gives verdict as NF_ACCEPT, iptables STOPS processing further rules and > ACCEPTs the packet. > > This actually becomes security risk because default snort rules DO NOT DO port blocking. > and ACCEPTs everything that is not EXPLICITLY dropped. > > And hence NFQUEUE target indirectly becomes ACCEPT target for all packets and > full system gets exposed. > > So my request and suggestion is to add additional parameter to NFQUEUE > say, --treat-accept-as-continue (or rule not matched) > > > which means, if QUEUE program returns NF_ACCEPT then instead of ACCEPTing > the packet, continue processing next rule. (as if rule did not match) > > > I know there is NF_REPEAT, but that will PASS packet through all procesing again > and I will also have to do packet marking etc. Which is more like HACK instead of > sensible approach. > > And to use NF_REPEAT I will need to change whole snort code and rules. Which is > impossible. > > So please consider my suggestion. As it opens up many other possibilities as well. That will not be straight forward to implement. The existing code does not provide a way to resume packet filtering just after the rule that enqueued the packet to user-space. [...] > PS: > We can also extend this suggesion further with one more parameter as > --treat-accept-as-return which becomes equivalent to RETURN target. Same thing with RETURN. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
