Rohde.Henning at gmx.net
Tue Oct 16 08:14:28 PDT 2001
hey, your scripts look quite nicely, did you write them on a basis of
some document or manual, or did you write them completely from scratch?
You ask why I wonder?
Because you setup masquerading seperately from firewalling and I've
never seen this layout as a principle before, as well as the way you
setup the masquerading of your uplink.
There's plenty of documentation about Firewalling on the 'net, even the
BLFS-project has some hint:
Björn Lindberg wrote:
> Now I have finally set up my new firewall/router. I would very much
> appreciate critique or a discussion around this.
> echo -n "Setting up IP-tables for filtering..."
> # flush filter table
> $IPTABLES -F INPUT
> $IPTABLES -F OUTPUT
> $IPTABLES -F FORWARD
No need for three commends, do it with one for all:
You might 'zero' all counters:
and delete all user-defined chains:
The latter you're actually not using, but when time comes, user-defined
chains allow some good level of abstraction, usefully for instance for
> # set default policy
> $IPTABLES -P INPUT DROP
> $IPTABLES -P FORWARD DROP
OK, these are sane policies, but why not on don't you use one on OUTPUT?
> # INPUT section
> # allow only packets from internal network
> $IPTABLES -A INPUT -i $INTDEV -j ACCEPT
> $IPTABLES -A INPUT -i lo -j ACCEPT
Hmm, what services does your router need to access itself?
Does it log, for instance, onto another machine?
As long as it is a real router, meaning no daemon does serve anything on
it and nobody is using the box for any daily work, there should be no
need to allow any traffic in INPUT on any but the local interface.
For the ease of administration allowing ssh seem acceptable, if possible
only on the internal interface.
> # drop everything else to this machine
> $IPTABLES -A INPUT -j DROP
> # FORWARD section
> # allow packets belonging to already established connections
> $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> # drop packets not belonging to a connection
> $IPTABLES -A FORWARD -m state --state INVALID -j DROP
> # allow forwarding of packets from internal sources
> $IPTABLES -A FORWARD -i $INTDEV -o $EXTDEV -j ACCEPT
OK, not any problem in my eyes.
> # allow SSH connections
> $IPTABLES -A FORWARD -p tcp --dport 22 -j ACCEPT
> # allow ping requests
> $IPTABLES -A FORWARD -p icmp --icmp-type echo-request -m limit --limit
> 1/s -j ACCEPT
Hmm, why do you allow ping and ssh explicitely?
If you want to ssh some machine anywhere on the 'net this would already
be allowed by the general-clauses you've written above.
To state them explicitely makes only sense if you wanted to ssh your
_internal_ machine or your router from somewhere on the internet, but
IMHO this would be impossible with these two lines.
If you wanted to ssh and ping your router from anywhere on the internet, you must place these rules into the INPUT-chain, and enable the corresponding traffic on OUTPUT.
> # activate IP-forwarding
> echo 1 > /proc/sys/net/ipv4/ip_forward
> # do reversed path validation
> echo 1 > /proc/sys/net/ipv4/conf/$EXTDEV/rp_filter
Why do you enable rp_filter only on the external interface? As long as
you don't play with having external IP-adresses on the internal network
it would not harm if you enabled reversed path validation
on any interface.
You may activate tcp_syncoocies, in the same directory as ip_forward,
although they would not affect the security of any router because they
were designed to prevent synflood-attacks against a server.
Besides syncookies I'd like to recommend you to disable Explicit
Congestion Notification in case you enabled it at kernel-compilation by
error. IMHO there are still too many routers that block it because they
are ignorant of this senseful feature.
> # iptables configuration for routing
> source /etc/init.d/functions
> # get IP-information from DHCP client
> source /etc/dhcpc/dhcpcd-$EXTDEV.info
> echo -n "Setting up IP-tables for routing..."
> # flush nat table
> $IPTABLES -t nat -F
> # give all packets coming from the internal LAN the router source
> $IPTABLES -t nat -A POSTROUTING -o $EXTDEV -j SNAT --to $IPADDR
> # route incoming packets to nex
> $IPTABLES -t nat -A PREROUTING -i $EXTDEV -j DNAT --to 192.168.1.1
Am I correct if I assume that you setup masquerading with these two lines?
If I'm correct, why don't you keep it as simple as this:
$IPTABLES -t nat -A POSTROUTING -o $EXTDEV -j MASQUERADE
That's all you need, the reverse direction get's handled automagically:
please take a look at the second paragraph.
OK, that's for now all of my EUR 0.02,
(who incidentally happens to be the author of the firwalling hint)
PS: yes I know, you happy folks won't get affected too soon with the
damn Euro! ;-)
PPS: Further additions: KISS -> Keep it stupid 'n' simple!
Rejecting identd-queries could be sensefull, see my hint.
Log everything for debugging, must be the last of all rules, just before
you DROP/REJECT the unwanted packets:
iptables -A INPUT -j LOG --log-prefix "FIREWALL:INPUT "
iptables -A FORWARD -j LOG --log-prefix "FIREWALL:FORWARD"
iptables -A OUTPUT -j LOG --log-prefix "FIREWALL:OUTPUT "
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-support' in the subject header of the message
More information about the blfs-support