>
> Given that it is a standalone server, do I really need nat and mangle
> tables?
It is good practice to reset tables which you do not use, because you
don't always know the prior state. However you can skip this step if you
can check in /proc/net/ip_tables_names that thoses tables are not active.
>>> # Munin accounting stuff
>>> /sbin/iptables -A INPUT -d $INET_ADDRESS
>>> /sbin/iptables -A OUTPUT -s $INET_ADDRESS
>> If the address is correct, these two rules set the host wide open
>> inbound and outbound, so I do not see how the ruleset could possibly
>> "lock you out".
>
> AFAIK, this is a "dummy" ruleset to be used by a Munin plugin (the
> monitoring tool we use).
Oops, my mistake. I read to fast and imagined that the rules add the
ACCEPT target. But they do have no target and no action.
>>> # FTP Client (Data Port for non-PASV transfers)
>>> $IPT -A tcp_inbound -p TCP -s 0/0 --source-port 20 -j ACCEPT
>> Don't do this. It accept anything from anyone using source port 20.
>
> I was wondering: do I really need all this mumbo jumbo with packet
> states and separate UDP/TCP chains?
Well, IMO connection state tracking is a very nice and useful feature.
> I mean, won't the firewall be enough if I close it all down inbound on
> the public IP and open ports on a need-to basis? (obviously lo and vpn
> would have total IN/OUT access)
You cannot only open some ports inbound. If you want to allow all
outbound connections, you need to accept the inbound return packets.
These packets look totally random, except for the connection state
tracking which can match them with previous outbound packets.
--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/4F3EBD41.5010608@plouf.fr.eu.org
No comments:
Post a Comment