Michael Rash
Mon, 09 Jan 2012 18:43:59 -0800
On Jan 08, 2012, Marianne Schuppe wrote: > Hi > I am reading the fascinating 'Linux Firewalls' by M Rash and I have two > questions. I am using the firewall script presented at the beginning of the > book ( p.22 ) on Linux/Ubuntu. I have modified the script to conform to the > Debian/Ubuntu insserv stance and I add this script 'firewall.sh' to my > configuration like this: > > # insserv -d firewall.sh > > 1) the --no-ipt-sync: when I use this option, more than 70% of the snort > rules get translated to iptable rules. However, when running the resulting > fwsnort.sh along firewall.sh , I get a lot of false alarms like for example > SID 1087 and 1768 which are refering to Windows vulnerabilities and which > get triggered simply by starting up the chrome/google browser. > > If, on the other hand, I omit this option, based on firewall.sh , fwsnort > only translates one applicable rule (sid 183). This does not seem like a > lot , if I consider that firewall.sh contains rules for the most important > services like ssl, http, https, dns etc. > > So the question is: better use --no-ipt-sync and spend a lot of time > weeding out false ( windows related ) alarms or better drop the switch and > have little benefit using fwsnort. ?
Good question. By default fwsnort attempts to match translated Snort rules to the running iptables policy, but this is tough to do well because iptables policies can be complex. And, before fwsnort switched to the iptables-save format for instantiating the policy, a large set of translated rules could take a really long time to make active within the kernel. Finally, many Snort rules restrict themselves to established TCP connections anyway, and if a restrictive policy doesn't allow connections to get into the established state for some port let's say, then there is little harm in having translated Snort rules for this port. Some kernel memory would be wasted (small), but no performance would be lost since packets won't be processed against these rules anyway. Given this argument, I will probably switch the default behavior of fwsnort to not worry about what's allowed by the local policy and what isn't. Now, regarding signatures that are triggering, the Snort rules that are bundled with fwsnort come from two classes - 1) the original GPL rules that were bundled with Snort before VRT rules started, and 2) the Emerging Threats rule set. My recommendation would be to audit the old Snort rules and perhaps disable them altogether in favor of running the Emerging Threats rules (since the later are updated frequently). > 2) What is the best practice for running fwsnort.sh along firewall.sh. > > Currently , in firewall.sh, I have added > > ... > ###### NAT Rules ############# > .... > > > $IPTABLES -t nat -A POSTROUTING -s $INT_NET -o eth0 -j MASQUERAD > ########################### > > */etc/fwsnort/fwsnort.sh* > > ################### forwarding > > That is: at the end of the default policy. Is this the best way to do it ? At the end is the best place just as you have it - fwsnort places itself within the running iptables policy as needed by creating its own chains and jump rules, etc. > Thanks for your help and thanks a lot for psad and fwsnort. Glad you like them, and please let me know if you have any other questions. --Mike ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ Fwsnort-discuss mailing list Fwsnort-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fwsnort-discuss