>>>>> Jonathan Yu <[email protected]> writes:
>>>>> Ivan Shmakov <[email protected]> wrote:
>> FWIW, I've ended up using the init.d/ script below. The script is
>> expected to run prior to ifupdown, so assuming the symbolic link to
>> the latter is at /etc/rcS.d/S39ifupdown, this one needs to be
>> symlinked at, say, /etc/rcS.d/S38iptables-is.sh
I wonder, does it make sense filing a wishlist Bug against
iptables, asking for this script to be included?
> I apparently used /etc/network/if-pre-up.d (I can't remember the
> reasoning why, but I guess it's useful to make sure you load the
> rules prior to bringing the interfaces up, which means the rules will
> be there once network connectivity is brought up)
Yes. However, doesn't if-pre-up.d/ get activated every time an
interface is brought up?
Please consider:
>> The script is designed to be run from within the rcS.d sequence,
>> and before ifupdown, so that it won't be:
[...]
>> * run several times at some (possibly random; consider, e. g.,
>> hotplug devices) points of time, ruining the current firewall
>> state along the way -- as it happens when one puts the script
>> into /etc/network/if-up.d/ or /etc/network/if-pre-up.d/.
[...]
> A long time ago I wrote a blog article on the subject
> http://www.debian-administration.org/article/Restoring_iptables_Automatically_On_Boot
Thanks for the pointer!
> Perhaps more interesting than that article is the discussion that
> happened in the comments.
> Hope this helps :-)
jawnsy> Sure, if you save it as root then the file will be owned by
jawnsy> root. But if you accidentally (or someone intentionally)
jawnsy> modifies the permissions of it, or changes the ownership,
jawnsy> iptables-restore will simply load the rules blindly.
jawnsy> It's safer to actually check ownership and permissions before
jawnsy> loading those; otherwise if you accidentally leave the file as
jawnsy> 666 or 777 or otherwise writable by others, then it becomes
jawnsy> vulnerable.
I disagree. If a user has enough power to chown () a file in
/etc/ at will, then it could simply chown () the restoring
script instead, and do anything with it (say, disable the
checks, or the loading of the rules.)
190.55.xx.xx> With restore you are replacing any already loaded rule
190.55.xx.xx> (consider interaction with fail2ban, for example) and the
190.55.xx.xx> iptables-save format is quite unreadable. So I would
190.55.xx.xx> prefer using other options, like ferm or creating a
190.55.xx.xx> iptables script per board.
I don't know much about fail2ban, but if it adds rules to
iptables, they're going to be lost each time an interface is
brought up, if one's using if-pre-up.d/.
OTOH, a script in rcS.d/ will be run precisely once, quite early
in the startup sequence. In certain cases, this will save one
from a conflict with an iptables autostuffer.
[...]
--
FSF associate member #7257
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
