Autor: Daniel Reurich Data: A: dng Assumpte: Re: [DNG] Recommended location for iptables rules
On 06/12/16 21:55, Klaus Ethgen wrote: > Hi folks,
>
> Am Di den 6. Dez 2016 um 0:07 schrieb Daniel Reurich:
>> On 06/12/16 05:50, Lars Noodén wrote:
>>> Where should we be commending the storage of iptables rules in Devuan
>>> Jessie?
>
>> There should not be a default location. It should be left to each
>> firewall application to define. This is particularly important as
>> iptables has a competitor in nftables and likely to be deprecated at
>> some point so we can't guarantee into the future that iptables will
>> always exist.
>
> Well, I think, there should be an advice.
>
> Historical I use /var/lib/iptables. But that is only great when using
> dynamic iptables. Present days I do them manually so /etc/something
> might be better.
Again the problem is that in order for this to work there has to a
service or a hook in /etc/network/if-*.d that consistently loads them
from that location and all firewall tools either must use that location
for placement and management of the iptables rules. This is a clearly
application space and not a core OS requirement. Regardless of the use
of the system, Iptables rules are optional and not required for normal
operation and thus should be setup and managed by an application of the
users choice. This is why I believe there should be no "default"
location for them.
Personally I use a subdirectory in /etc for rules, as they are
configuration data and not state data (the state being kept in the kernel).
FWIW all packages that manage iptables rules should set a Provides and
Replaces to "iptables-management" so that users can't install 2 at the
same time and installing one removes and replaces any other application
that does this. This is same process by which mta's are managed using
the Provides and Replaces "mail-transport-agent" to ensure only one MTA
is installed at any given time.
>
>> Generally a well setup Linux system has no network connectable services
>> running that aren't intended to be, in which case it's relatively
>> resistant to hacking attempts. This means firewall in a well secured
>> network is generally not necessary or desirable. The only instance I'd
>> consider a workstation firewall is a laptop connecting to untrusted
>> networks regularly.
>
> Well, except avahi, cups, samba, ntp, rpcbind and some other bad
> designed tools that default listen on 0.0.0.0 and that are pulled in
> with a common linux desktop installation.
I'd expect in reality these listen to IP address(es) of the host and in
some cases the broadcast address(es). That's expected and reasonable
behaviour for those daemons for service discovery and reasonable
discretion is used in handling the inbound traffic appropriately.