Firewalling revisited...

Henning Rohde Rohde.Henning at gmx.net
Tue Oct 16 08:14:28 PDT 2001


Hi Björn,

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: 
http://hints.linuxfromscratch.org/hints/firewall.txt


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.
> ...
> /etc/init.d/filter:
> ...
> IPTABLES=/usr/sbin/iptables
> 
> EXTDEV=eth1
> INTDEV=eth0
> 
> 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:
$IPTABLES -F

You might 'zero' all counters:
$IPTABLES -Z

and delete all user-defined chains:
$IPTABLES -X

The latter you're actually not using, but when time comes, user-defined 
chains allow some good level of abstraction, usefully for instance for 
logging.

>
> # 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.


> 
> evaluate_retval
> 
> # 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.


> 
> /etc/init.d/route:
> ------------------
> #!/bin/sh
> # iptables configuration for routing
> 
> source /etc/init.d/functions
> 
> IPTABLES=/usr/sbin/iptables
> 
> EXTDEV=eth1
> INTDEV=eth0
> 
> # 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
> address
> $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
> 
> evaluate_retval
> 

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:
http://netfilter.samba.org/unreliable-guides/NAT-HOWTO/NAT-HOWTO.linuxdoc-6.html#ss6.1, 
please take a look at the second paragraph.


OK, that's for now all of my EUR 0.02,

	Henning,
(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.
PPPS:
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 mailing list