John Crisp wrote on 28/03/18 03:19:
Hi Ralph, and thanks for your reply.
On 26/03/18 13:08, Ralph Ronnquist wrote:
John Crisp wrote on 26/03/18 19:37:
Two questions.
Is it better like this or should I use iptables-persistent ?
I would suggest that this approach has the advantage of raising the
firewall immediately with bringing up the interface. When using
iptables-persistent, it would be brought up with a delay and after IP
assignment, which leaves a small temporal window of no firewall. On the
other hand, that window is only of concern when the system has some
early (earlier) staring services that needs intrusion protection. So in
most cases it's of no difference.
OK - at least I know !
As I checked it out in detail, I discovered that the post-up command is
only done subsequent to DHCP succeeding (in either case), and not before
this. Thus, there's pretty much the same window and concern. It also
means that the iptable rules file is not relevant, but rather what the
rules are before/during the DHCP attempt. Or, you could have it as
pre-up command instead.
Though, the tagging "allow-hotplug eth0" suggests to me that the system
brings up the interface via the hotplug handling (udev), and then
probably during pre-pivot boot stage where "/" is from initrd. That
should all be fine, but it's asynchronous and very early in the boot, so
it does offer a few more spanners to drop into the well.
For example, if initrd doesn't include /etc/iptables.up.rules the
post-up command will fail, and interface setup (ifup) will end up in a
peculiar state; the dhcp might succeed, but the local state says "not
configured". A pre-up command failing is more severe, and would stop
before the DHCP attempt.
Ralph.
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
