FirewallSettings

From TrustixWiki

Contents 1 Introduction 2 Firewall Settings 3 Comments and Afterthoughts 3.1 Isn't DROP an antisocial firewall policy?

Introduction

The following example firewall sets up IP forwarding, IP masquerade (NAT) on eth0, and a simple but generally effective firewall that allows all outgoing packets but routes other packets only if they're already established connections or related to existing connections. They are not distribution specific and should be easily adaptable for any system that uses iptables. This example is intended to provide a functional starting point but should by no means be considered "a holy grail". This will give you a base config that I believe is reasonably safe to expose to the Internet while you continue to learn.

"Advanced" topics that I suggest you read about soon would be things like DNAT, and SNAT. "man iptables" is an informative read as-is the "Linux IP Masquerade HOWTO" at tldp.org ( http://www.tldp.org/HOWTO/IP-Masquerade-HOWTO/index.html last I checked. Sections 3.4 "Configuring IP Forwarding Policies" and 6.4. "Stronger firewall rulesets to run after initial testing" contain well-commented firewall examples and I learned a great deal from them.)

Firewall Settings

This example is based on a configuration where the Internet is connected to eth0 and the internal network to eth1. You will need to modify them to match your network if it's different. Only the interfaces lo, eth0, and eth1 are directly referenced in the following rules. Therefore, as-is, other interfaces (if you have them) are treated as untrusted networks -- The only difference being that eth0 will have a rule that enables IP masquerade on outgoing packets while the unspecified interfaces don't. IP masquerade/NAT, if you don't already know, enables multiple devices on one network (those on eth1 in this example) to access the network of another interface (eth0 in this case) using only eth0's IP address. Read, learn, enjoy, and then add/edit rules as you deem appropriate to your setup.

if you have a static external IP, you will want to replace MASQUERADE below with SNAT --to <external IP>

After altering your iptables, always remember to issue service iptables save to save the firewall settings

#make sure iptables has been loaded
service iptables start

#clean up existing rules to ensure a clean slate.
#flush existing rules
iptables -t filter -F
iptables -t nat -F
iptables -t mangle -F

#delete custom chains.
iptables -X

#set default policies.
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

#INPUT rules.

#don't accept packets from private reserved nets from the internet
iptables -A INPUT -i eth0 -s 192.168.0.0/255.255.0.0 -j DROP
iptables -A INPUT -i eth0 -s 172.16.0.0/255.250.0.0 -j DROP
iptables -A INPUT -i eth0 -s 10.0.0.0/255.0.0.0 -j DROP

#accept all icmp packets
iptables -A INPUT -p icmp -j ACCEPT

#drop all invalid incoming packets.
iptables -A INPUT -m state --state INVALID -j DROP

#accept all input from the loopback device.
iptables -A INPUT -i lo -j ACCEPT

#allow only clients on the inside ssh access
iptables -A INPUT -i eth1 -p tcp --dport 22 -j ACCEPT

#allow dns, dhcp client/server and ntp connections 
iptables -A INPUT -p udp -m multiport --dports 53,67,68,123 -j ACCEPT

#allow incoming packets from connections we established
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

#FORWARD rules
#don't forward packets to private reserved networks on the internet
# these packets would have come from eth1, send an icmp error back (which is the correct behaviour for a router)
iptables -A FORWARD -o eth0 -d 192.168.0.0/255.255.0.0 -j REJECT --reject-with icmp-net-unreachable
iptables -A FORWARD -o eth0 -d 172.16.0.0/255.250.0.0 -j REJECT --reject-with icmp-net-unreachable
iptables -A FORWARD -o eth0 -d 10.0.0.0/255.0.0.0 -j REJECT --reject-with icmp-net-unreachable

#drop all invalid forward packets.
iptables -A FORWARD -m state --state INVALID -j DROP

#forward all icmp packets
iptables -A FORWARD -p icmp -j ACCEPT

#forward all from the internal network.
iptables -A FORWARD -i eth1 -j ACCEPT

# accept NATed packets
iptables -A FORWARD -m conntrack --ctstate DNAT,SNAT -j ACCEPT

#OUTPUT rules

#don't send packets to private reserved networks to the internet
iptables -A OUTPUT -o eth0 -d 192.168.0.0/255.255.0.0 -j DROP
iptables -A OUTPUT -o eth0 -d 172.16.0.0/255.250.0.0 -j DROP
iptables -A OUTPUT -o eth0 -d 10.0.0.0/255.0.0.0 -j DROP

#drop all outgoing invalid packets.
iptables -A OUTPUT -m state --state INVALID -j DROP

#allow all icmp packets
iptables -A OUTPUT -p icmp -j ACCEPT

#and loopback traffic
iptables -A OUTPUT -o lo -j ACCEPT

#allow traffic from ssh and http servers
iptables -A OUTPUT -p tcp -m multiport --sports 22,80 -j ACCEPT

#allow dhcp server/client packets 
iptables -A OUTPUT -p udp -m multiport --sports 67,68 -j ACCEPT

#allow packets of established connections
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#port forwarding
#this example would forward port 2317 on the external interface to the internal computer with IP 10.0.0.2
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 2317 -j DNAT --to 10.0.0.2

#enable ip masquerade on Internet interface.
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

#and finally, save the settings
service iptables save

Comments and Afterthoughts

Isn't DROP an antisocial firewall policy?

Do a google search on "iptables REJECT or DROP" and you will see that this a debated point. REJECT is "polite" in that it tells the other end that the service is not available. DROP has no manners whatsoever and simply shreds the packet and leaves the sender in suspense as to what happened to it. After some discussion and reading it's my belief that DROP is preferable from a security perspective. A REJECT policy could leave your firewall more susceptible to source address spoofing which means it could be tricked into sending all those polite REJECT messages to an unintended host -- get enough polite firewalls to do the same thing and you just might find yourself politely participating in what could effectively become a DoS party on that poor host. I'm not saying this is likely, just that it's possible and I haven't seen compelling evidence to demonstrate that it's worth taking the chance. I suggest you only use REJECT in lieu of DROP if you specifically suspect that DROP is causing a problem in your environment. e.g. Delays connecting to certain mail servers that do ident tcp/113 probes on connecting clients -- if your firewall DROPs these packets the probing mail server will wait until the probe times out (usu. 20 - 30 seconds) before (possibly) continuing the connection. You could compensate for this problem specifically, without giving up a DROP policy altogether, by simply adding a rule such as

iptables -I INPUT 2 -p tcp --dport 113 -j REJECT --reject-with tcp-reset