RFC: Firewall.txt v1.4

jbauman at adsl-63-193-249-142.dsl.snfc21.pacbell.net jbauman at adsl-63-193-249-142.dsl.snfc21.pacbell.net
Mon Aug 20 21:07:29 PDT 2001

On Sun, Aug 19, 2001 at 04:28:53PM +0200, Henning Rohde wrote:
I've taken a cut at clarifying the text a bit. It's still not perfect, but 
I think it's getting closer to standard English usage with this. You might 
consider taking a diff and accept or discard these changes as you see fit. 
I would also suggest cutting out extraneous stuff, like the reference to 
www.dumbentia.com, etc. -- this is already likely to be one of the longer 
sections in the book.
I haven't touched any of the firewalling code. I hope this is helpful.


TITLE:		Firewall.txt
		Kernel   >= 2.4.4
		iptables >= 1.2.2
AUTHOR:		Henning Rohde	Henning.Rohde at uni-bayreuth.de

	Question:	What's a firewall?
 	Answer:		a fire-resistant wall separating a building into 
			departments, designed to prevent the spread of fire
And on Networks?	A box that restricts the malicious (eg crackers, 
			worms, trojans) out of your intranet.
How Do I build one?	fetch iptables and read the following:

Personally I prefer the following definition:
Answer:		A wall of fire that only the Saints can pass through!
@Networks:	Just a box, that permits only sane packets to pass!

The general purpose of a firewall is to save the labour of securing every
box by securing a single firewall.
This means that the firewall is a single point of failure, but it makes
the admin's life a lot easier.

But please, don't assume that having a firewall makes careful 
configuration redundant!

If you knew every daemon or service on every machine was correctly configured
and trustworthy, and trusted every user accessing 
your services to cause no harm, you wouldn't need to do firewalling!
But if you'd like to choose which services are accessible only from your 
intranet, which machines or applications are allowed to have internet access,
or if you don't trust some of your apps or users, you might benefit by using
a firewall.

When you read the word "firewall" there's more than one way to interpret it:
a) "Personal Firewall":	
	Program sold by e.g., Norton, that is claimed to secure a home/desktop-pc
	with internet access. Quite relevant for users being always online 
	with (flat rate) broadband links.
b) Firewall as it was originally meant: 
	A box placed between the internet and intranet doing, besides routing, 
	nothing but protecting the intranet. This could include the function of masquerading 
	( rewriting IP-headers of the packets it routes from clients with 
	private IP-adresses onto the internet, so that they seem to come 
	from the firewall itself).
c) Firewall offering services:
	Some old box you may have retired and nearly forgotten, 
	doing (B), but offering a bunch	of services, e.g., web-cache, mail, etc.
	This may be very commonly used for home networks, 
	but it severely violates some principles of (B).
d) Firewall with a demilitarized zone (not described here):
	Doing (B), but giving public access to some branch of your intranet,
	that is, because of public IP's and a physically separated structure,
	neither considered to be part of the inter- nor intranet.
	Here those servers are connected that must be easily accessible
	from both the inter- and intranet. The firewall protects them all.
e) Packetfilter / partly accessible net (only partly described here, see (C)):
	Doing (B) but permitting only selected services to be accessible,
	sometimes only by selected internal users or boxes; mostly used in
	highly secure business contexts, sometimes by distrusting employers.
	This was the common configuration of a firewall at the time of the Linux 2.2 kernel.
	It's still possible to configure a firewall this way, but makes the rules quite complex and lengthy.

This document is meant as an introduction to how to setup a firewall. 
I am not, nor do I pretend to be, a security expert.	 ;-)
I am just some guy who still has not read enough and whose computers
still like to play tricks on him if he wants to tweak them. ;-)
Please, I am writing this to help people get acquainted with this subject, 
and I am not ready to stake my life on the accuracy of what is in here.
(Taken from www.linuxdoc.org/HOWTO/Firewall-HOWTO.html, slightly modified)

The scripts quoted here are not at the very least meant to give you 
the one and perfect firewall, being perfect until the universe collapses.
They may not fit into any imaginable configuration and may not prevent 
any imaginable attack.

The purpose of this text is simply to give you a hint on how to get started with firewalling.

Should you feel the need to adapt these scripts further, you'll
have to get more than slightly acquainted with Firewalling!
Have a look at Appendix I. There you'll find a list of URLs that contain quite 
comprehensive information about building your own firewall.

|Getting a firewalling-enabled Kernel|
If you want your Linux-Box to do firewalling you must first ensure that you 
have an appropriate kernel and the appropriate tools:

But, before you do a 'make menuconfig', consider patching your kernel
with the latest iptables enhancements. To do this,
download the latest version of iptables from http://netfilter.samba.org.

Having current kernel sources in /usr/src/linux, 'cd' into subdir 'patch-o-matic'
of iptables and execute './runme', as an user who is allowed to
patch the kernel.
You should not use all patches, but the IRC-patch or masq-dynaddr.patch could 
be useful, depending on your needs. 

If patching is not successful, e.g., due to outdated patches,
don't worry too much. If you skip it, the default kernel is adaequate
for most needs! 
The important thing is that iptables has scanned the kernel for already
accepted / incorporated patches.

Now configure the kernel:
Personally I prefer to have a maximal modularized kernel, but for highest
security you could configure the kernl with this code built in:
    Networking options:
	Network packet filtering	= CONFIG_NETFILTER
	IP: TCP/IP networking		= CONFIG_INET
	IP: advanced router		= CONFIG_IP_ADVANCED_ROUTER
	IP: verbose route monitoring	= CONFIG_IP_ROUTE_VERBOSE
	IP: TCP Explicit Congestion Notification support
	IP: TCP syncookie support	= CONFIG_SYN_COOKIES
	IP: Netfilter Configuration: every option
					= CONFIG_IP_NF_*
		BUT NO ipchains- and ipfwadm-compatibility.

Now compile and install your new kernel, update your bootloader and reboot.

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

|Now we can start to build your Firewall|
A Personal Firewall is supposed to let you access the all 
services offered on the internet, but keep your box secure and
your data private.

Below is a slightly modified version of Rusty Russel's recommendation from his 
firewall guide, 

# Insert connection-tracking modules	(not needed if built into kernel).
modprobe ip_tables
modprobe iptable_filter
modprobe ip_conntrack
modprobe ip_conntrack_ftp
modprobe ipt_state
modprobe ipt_LOG
# free output on any interface to any ip for any service   (equal to -P ACCEPT)
iptables -A OUTPUT					  	-j ACCEPT
# permit answers on already established connections
# and permit new connections related to established ones (eg active-ftp)
iptables -A INPUT	-m state --state ESTABLISHED,RELATED	-j ACCEPT
# Log everything else:	Watch the crackers scanning!
iptables -A INPUT	-j LOG --log-prefix "FIREWALL:INPUT  "
# set a sane policy:	everything not accepted > /dev/nul
iptables -P INPUT       DROP
iptables -P FORWARD     DROP
iptables -P OUTPUT      DROP
# be verbose on dynamic ip-adresses	(not needed in case of static IP)
echo 2 > /proc/sys/net/ipv4/ip_dynaddr
# disable ExplicitCongestionNotification - too many routers are still ignorant
echo 0 > /proc/sys/net/ipv4/tcp_ecn

His script is quite simple, but simply surfing the internet you are unlikely 
to exceed its limits.

Even if you have daemons / services running on your box, these should be
inaccessible everywhere but on your box itself.
The case to be cautious about is misconfigured daemons that could broadcast
to the public to announce their service (e.g., cups, samba).
If you have to be cautious about them, restrict OUTPUT, see (C) and (E).

A true Firewall has two interfaces, one connected to an intranet, in this example, eth0,
and one connected to the internet, here, ppp0.
To provide the maximum security against the box itself being broken into 
by exploiting an offered service, make sure 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:
echo -n	"You're using the example-config "
echo	"for a setup of a firewall "
echo -n	"from the firewalling-hint "
echo	"written for LinuxFromScratch. "
echo -n	"This example is far from being "
echo	"complete, it is only meant "
echo	"to be a reference. "
echo -n	"Firewall security one could rely "
echo	"on is a complex issue, "
echo -n "that exceeds the scope of the "
echo	"quoted configuration rules. "
echo -n "You can find some quite "
echo	"comprehensive information "
echo	"about firewalling at Appendix I of "
echo -n	"http://hints.linuxfromscratch.org/hints/firewall.txt"
echo	"."
echo	"Be cautious!"
modprobe ip_tables
modprobe iptable_filter
modprobe ip_conntrack
modprobe ip_conntrack_ftp
modprobe ipt_state
modprobe iptable_nat
modprobe ip_nat_ftp
modprobe ipt_MASQUERADE
modprobe ipt_LOG
modprobe ipt_REJECT		# needed for (C), example 4
# 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
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 "
# set a sane policy
iptables -P INPUT	DROP
iptables -P FORWARD	DROP
iptables -P OUTPUT	DROP
# be verbose on dynamic ip-adresses (not needed in case of static IP)
echo 2 > /proc/sys/net/ipv4/ip_dynaddr
# disable ExplicitCongestionNotification
echo 0 > /proc/sys/net/ipv4/tcp_ecn
# activate TCPsyncookies
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
# activate Route-Verification = IP-Spoofing_protection
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
	echo 1 > $f
# activate IP-Forwarding 
echo 1 > /proc/sys/net/ipv4/ip_forward

With this script your net should be sufficiently secure against external attacks:
your intranet should be invisible because it's masqueraded or, at least, no one
should be able to setup a new connection to its services, and your firewall 
should be immune because there are no services running that a cracker could attack.

If you are in the need of stronger security (e.g., against DOS, connection highjacking,
spoofing, etc.) see Appendix.1 and start to read a bit!

This scenario is not too different from (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,
e.g., via secureShell.

Be cautious: every service you do offer and have enabled makes your box
less secure. See (B)!

Start with script (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 ensure 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

Third, you might restrict access to your services: e.g., only your intranet
should be allowed to access the proxy on your firewall:
iptables -I INPUT  -i eth+ -s -p tcp --dport 8080  -j ACCEPT
iptables -I OUTPUT -o eth+ -d -p tcp --sport 8080  -j ACCEPT

Fourth, connections to your (non-existent) identd are rejected with a tcp-reset:
(this should prevent ftp-, mail-, irc-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

These are only examples. On my gateway I'm running the following services:
openSSH, Samba, squid, djbDNS, CUPS, LeafNode, POP3/IMAP and Postfix!

If you add any of your offered or accessed services such as the above,
maybe even in FORWARD, and delete the general clauses, 
you get an old fashioned packet filter, not unlike that one mentioned in (E).

To simplify debugging and be fair to anyone who'd like to access a service
you have disabled, purposely or by mistake, you should REJECT those packets 
that are dropped, especially if you offer services for the public.
Obviously this must be done as the very last lines before the packets
are dropped by policy:
iptables -A INPUT  	-j REJECT
iptables -A OUTPUT	-j REJECT

Finally, I'd like to remind you of one fact we must not forget:
The effort spent attacking a system corresponds to the value the cracker
expects to gain from it.
If you are responsible for such valuable assets that you expect great
effort to be made by potential crackers, you hopefully won't be in need 
of this hint!

Be cautious!
		Henning Rohde
	(Henning.Rohde at uni-bayreuth.de)

PS: And always do remember:
	SecureIT is not a matter of a status-quo 
	but one of never stopping to take care!

PPS: If any of these scripts fail, please tell me. I will try to trace
     any faults.
     But, please do not try to sue me. Remember I never gave you any guarantee!
     But do not despair, you'll find help on:
	http://www.dumbentia.com/pdflib/scissors.pdf!	;-)

Nowadays, we must face the threat of denial of service attacks (DoS) even against 
private users (this seems to be quite common if you do online-gaming),
trojans (read on IRC for commands), and worms exploiting the internet as if someone
was doing a blitzkrieg.

There may be ways to protect both your router and your intranet, but any
solution I'm able to give here could become insufficent tomorrow
and would give you a false sense of security.
If you are really concerned, this is not the document to help you out!

But have a look, here's where I'd suggest you start reading:
http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html (IIRC outdated!)
http://www-106.ibm.com/developerworks/security/library/s-fire.html +s-fire2.html
http://www.little-idiot.de/firewall  (German & outdated, but very comprehensive)

(If someone wants a link to be added, please mail!)

If you need to turn firewalling off, this script will do it:

# deactivate IP-Forwarding 
echo 0 > /proc/sys/net/ipv4/ip_forward
iptables -Z
iptables -F
iptables -t nat         -F PREROUTING
iptables -t nat         -F OUTPUT
iptables -t nat         -F POSTROUTING
iptables -t mangle      -F PREROUTING
iptables -t mangle      -F OUTPUT
iptables -X
iptables -P INPUT       ACCEPT
iptables -P FORWARD     ACCEPT
iptables -P OUTPUT      ACCEPT

If you'd like to have a look at the chains your firewall consists of and 
the order in which the rules take effect:

echo "iptables.mangling:"
iptables -t mangle	-v -L -n --line-numbers
echo "iptables.nat:"
iptables -t nat		-v -L -n --line-numbers
echo "iptables.filter:"
iptables		-v -L -n --line-numbers


More information about the blfs-book mailing list