RFC: firewall-hint_v1.3

jbauman at adsl-63-193-249-142.dsl.snfc21.pacbell.net jbauman at adsl-63-193-249-142.dsl.snfc21.pacbell.net
Fri Aug 10 23:08:16 PDT 2001


On Fri, Aug 10, 2001 at 08:46:58PM +0200, Henning Rohde wrote:
> Content-Description: firewall-hint
> TITLE:		Firewall.txt
> LFS VERSION:	any, but Kernel > 2.4

The INSTALL document in the iptables 1.2.2 tarball claims kernel 2.4.4 or later is required.

<*snip*>

> |Building iptables|
> -------------------
> Before compiling you might want to edit the Makefile to adapt install-dir's.
> Now compile and install iptables and the utilities for saving and restoring
> via 'make && make install experimental install-experimental'.
> 

As with most packages, you can specify the directories you would like to have it installed in on the command line, for example:

	make BINDIR=/usr/bin LIBDIR=/usr/lib MANDIR=/usr/share/man install

If you're seriously configuring this as a working firewall, I would recommend skipping the "experimental" stuff.

<*snip*>

> # disable ExplicitCongestionNotification - too many routers are still ignorant
> echo 0 > /proc/sys/net/ipv4/tcp_ecn

I can't see why you would compile this in and then leave it disabled. Why not just skip it in the compile step? The level of detail that must be attended to here is high already, so why not simplify where possible?

<*snip*>

> (B)
> A true Firewall has got two interfaces, one connected to intranet, eth0,
> one connected to the internet, ppp0.
> To provide the maximum security against the box itself being breaken into, 
> using eg exploits in offered services, it is to be assured that there are
> no servers running on it, especially not X11 et al., and, as a principle,
> that it does not itself access any services:
> 
> #!/bin/sh
> ##/etc/init.d/firewall
> modprobe ip_conntrack
> modprobe ip_conntrack_ftp
> modprobe ip_tables
> modprobe iptable_filter
> modprobe iptable_nat
> modprobe ip_nat_ftp
> # allow local-only connections
> iptables -A INPUT	-i lo					-j ACCEPT
> iptables -A OUTPUT		-o lo				-j ACCEPT
> # allow forwarding
> iptables -A FORWARD -m state --state ESTABLISHED,RELATED 	-j ACCEPT
> iptables -A FORWARD -m state --state NEW	-i ! ppp+	-j ACCEPT
> # do masquerading    (not needed if intranet is not using private ip-adresses)
> iptables -t nat -A POSTROUTING  -o ppp+				-j MASQUERADE
> # Log everything for debugging: must be at the end of all rules

I'm not sure what you mean here. The LOG rule must come before an ACCEPT or DROP rule that matches the packet, otherwise, the packet will not be logged. 

<*snip*>

> (C)
> This scenario in not too different to (B), but you've got some services
> running on your box.
> It gets relevant in the moment when you want to admin your box remotely,
> eg via secureShell.
> 
> Be cautious, every service you offer makes your box less secure, see (B)!
> 
> Take the script as (B), but insert:
> iptables -I INPUT  -p tcp --dport 22				  -j ACCEPT
> iptables -I OUTPUT -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT
> 
> Alternativly, if you want to ping your box to enshure it's still alive:
> iptables -I INPUT  -p icmp -m icmp --icmp-type echo-request	  -j ACCEPT
> iptables -I OUTPUT -p icmp -m icmp --icmp-type echo-reply	  -j ACCEPT
> 

It would be wise to limit echo-requests to addresses you know you will use, if this is possible, rather than making your box visible to the whole world. For instance:

iptables -I INPUT  -p icmp -s 20.20.20.0/24 -m icmp --icmp-type echo-request -j ACCEPT	# only accept pings from the 20.20.20 network.


> Third, you might restrict access to your services: eg only your intranet
> should be allowed to access the proxy on your firewall:
> iptables -I INPUT  -i eth+ -s 192.168.1.0/24 -p tcp --dport 8080  -j ACCEPT
> iptables -I OUTPUT -o eth+ -d 192.168.1.0/24 -p tcp --sport 8080  -j ACCEPT
> 
> Fourth, connections to your (not existing) identd are rejected with a tcp-reset:
> (this prevents ftp-servers to refuse / delay connection)
> iptables -I INPUT  -i ppp+ -p tcp --dport 113 -j REJECT --reject-with tcp-reset
> iptables -I OUTPUT -o ppp+ -p tcp --sport 113 -m state --state RELATED -j ACCEPT
> 

It may be prudent to take some other precautions here, for example, here are a couple ways to block spoofed packets. I recommend using both -- if one fails, the other is there to catch the problem:

# Block spoofed packets
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
  echo 1 > $f
done

# Anything coming from the outside should not have a private address!
iptables -t nat -A PREROUTING -i ppp+ -s 10.0.0.0/8 -j LOG  \
        --log-prefix "Dropping spoofed packet"
iptables -t nat -A PREROUTING -i ppp+ -s 10.0.0.0/8 -j DROP
iptables -t nat -A PREROUTING -i ppp+ -s 192.168.0.0/16 -j LOG  \
        --log-prefix "Dropping spoofed packet"
iptables -t nat -A PREROUTING -i ppp+ -s 192.168.0.0/16 -j DROP
iptables -t nat -A PREROUTING -i ppp+ -s 172.16.0.0/12 -j LOG  \
        --log-prefix "Dropping spoofed packet"
iptables -t nat -A PREROUTING -i ppp+ -s 172.16.0.0/12 -j DROP

There are certain types of packets that you will never want coming in from the Internet. Here are some rules that address this:

# Log and drop malformed packets
iptables -A INPUT -p tcp -m state --state INVALID -j LOG --log-prefix "invalid tcp packet DROP: "
iptables -A INPUT -p tcp -m state --state INVALID -j DROP

# The following packets are used for various types of scans, and nothing legitimate:

# XMAS packets
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j LOG \
        --log-prefix "XMAS packet hit the firewall"
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

# NULL packets
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j LOG \
        --log-prefix "NULL packet hit the firewall"
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP

# Drop FIN packets that don't have ACKs. They are scans.
iptables -A INPUT -p tcp --tcp-flags FIN,ACK FIN -j LOG  \
        --log-prefix "FIN packet hit the firewall"
iptables -A INPUT -p tcp --tcp-flags FIN,ACK FIN -j DROP

These rules should be placed early in the chain, before any ACCEPTs, other than perhaps ESTABLISHED,RELATED connections.

I would also suggest having a look at 
http://boingworld.com/workshops/linux/iptables-tutorial/rc.firewall.txt
While the accompanying explanations are long-winded and poorly written, the information itself is pretty good, and the firewall ruleset has some really nice ideas.

http://www.securityfocus.com has a wealth of good information, including a section dedicated to Linux.

Happy blfs-ing,

Jeff




More information about the blfs-book mailing list