[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Iptables at boot, was fail2ban for apache2



On Mon, Dec 02, 2019 at 01:46:22PM +0100, Alessandro Vesely wrote:
> On Mon 02/Dec/2019 10:35:26 +0100 Andrei POPESCU wrote:
> > 
> > You might want to install iptables-persistent, otherwise you'll have to 
> > roll-out your own solution.
> 
> I'm not using iptables-persistent, but just looked at it out of curiosity.
> 
> Its LSB:
> 
> ### BEGIN INIT INFO
> # Provides:          netfilter-persistent
> # Required-Start:    mountkernfs $remote_fs
> # Required-Stop:     $remote_fs
> # Default-Start:     S
> # Default-Stop:      0 1 6
> # Short-Description: Load boot-time netfilter configuration
> # Description:       Loads boot-time netfilter configuration
> ### END INIT INFO
> 
> S also starts in single-user mode, i.e. without network?

And Default-Stop value prevents it from running in single-user.
Besides, unless one does something really stupid (like using hostnames
in netfilter rules) - what's wrong with netfilter rules loaded at
runlevel 1?
You can load a rule that processes packet on non-existent interface, for
instance.


> $remote_fs requires ip links to be already set up?

mountkernfs is more problematic here. Presumably it's for NFS-root
configuration.


> > In the particular case of iptables instead of writing a script you 
> > should probably just reuse your existing rules file and load that with 
> > an 'iptables-restore' from the .service unit.
> 
> 
> That's somewhat questionable in some cases.  I'd recommend to write a script
> with iptables commands rather than interactively issue iptables command until
> you are satisfied with the current setup.  That's natural, since iptables
> doesn't give a visual feedback, so reasoning is your best friend.  IOW, a
> commented script is more readable than an interactive setup.

"-m comment" anyone?


Personally I see little value in this package. There are cases that
require modifying netfilter rules ad-hoc, saving those at system reboot
can lead to undesirable side-effects. My solution to those is the (ab)use
of /etc/network/interfaces:

auto lo
iface lo inet loopback
	up /sbin/iptables-restore < /etc/network/iptables.rules
	up /sbin/ip6tables-restore < /etc/network/ip6tables.rules

Because I have no problem in running "iptables-save >
/etc/network/iptables.rules" then the need arises.

Reco


Reply to: