Just figured out, what the problem seems to be in leaving chain's
policies on ACCEPT instead of DROP. It looks like to be a race condition
with the iptable_filter module.
Usually during bootup, the iptable kernel modules are not getting loaded
automatically. The first application which invokes /sbin/iptables causes
that the necessary kernel modules are getting loaded then.
So, if firehol is the first one which invokes iptables, the kernel
modules indeed get loaded, but it seems like some kind of race condition
happens so that chain's policies at the end remain on ACCEPT.
Now, if you put the following
ip_tables
iptable_filter
into /etc/modules, which causes these modules to be loaded much earlier
before firehol starts, firehol will behave correct and at the end the
policies are on DROP after finishing the boot sequence.
In this way it's quiet easy to reproduce on a running machine:
* stop firehol
* unload any iptables-related kernel module (especially ip_tables,
iptable_filter & iptable_nat)
* firehol start
* iptables -L -v -n | grep policy
-> still on ACCEPT
if you now invoke
firehol restart
and since all iptables modules are already loaded, policy will be
correctly set to DROP instead.
So either it should be noted that it's necessary to load the iptables
modules via /etc/modules first, or init.d script should take care of it
and load the modules itself before it first invokes "firehol start".
What do you think?
Cheers,
Andreas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
