IPTables rule set

[Anders_W]

Hi!

I am piecing together a rule set for IPTables on my B3, but I would like to have another pair of eyes look at it before I feed it into the Bubba.

Does anyone have experience of setting up IPTables rules? PM me and I'll send you a copy of the draft.

[Gordon]

Just post and anonymize whatever public address is in there that you feel uncomfortable to share.

[Anders_W]

Roger that.

Iptables rule set
Draft 1

Source documents
Gordon's answers on the Excito forum's thread ”Iptables and AFP”
Kjell Enblom ”Brandväggsskydd med iptables” (in Swedish)
The Geek Stuff ”25 Most Frequently Used IPTables Rules Examples”
Tech Reublic (Jack Wallen) ”10 iptables rules to help secure your Linux box”

Purpose of the Bubba:
1. to act as a firewall between the ISP gateway and the home network
2. to act as a WiFi hotspot for the home network
3. to direct all SFTP and Apple File Protocol (AFP) requests to a local file server (a headless Ubuntu box on the LAN)
4. to allow my laptop to access the Bubba and the file server through the same URL no matter if I am at home or somewhere else
5. to function as a web server (HTTP) with forum-, gallery etc. applications (all using http)
6. upcoming: to store incoming and outgoing email traffic for my various accounts
7. upcoming: to function as a proxy, allowing me to do secure web surfing from anywhere in the world

What I have already done, using the Wiki/How-to:
- Redirect all connections over HTTPS. This will have to be remade, so that only calls for the /admin-pages on the Bubba are redirected to HTTPS, while calls to the web server are allowed through as ordinary HTTP. This can wait for now.
- Restrict admin access to LAN
- (And a lot of other stuff that does not effect IPtables)

Before entering new rules, flush the old ones:
/sbin/iptables -F
/sbin/iptables -t nat -F
/sbin/iptables -X


Structure of the rule set
The draft rule set is divided into four parts:
1) Rerouting. Takes care of the ”it should not matter where I am” problem
2) Incoming traffic. Allows specific traffic into the Bubba/LAN
3) Utgoing traffic. Rules for outgoing traffic to the Internet
4) Administrative stuff. Logging, dropping, load balancing, DoS defence etc.

Rule Set Beginning:
===============

#
# PART 1 – REDIRECTING TRAFFIC
#

# Rerouting SSH calls to the Bubba coming from the LAN/WiFi
iptables -t nat -A PREROUTING -d <my_fixed_IP>/32 -i br0 -m tcp -p tcp --dport 22 -j DNAT --to-destination 127.0.0.1/32
# Is the destination correctly defined?

# Rerouting AFP calls coming from the LAN/WiFi
iptables -t nat -A PREROUTING -d <my_fixed_IP>/32 -i br0 -m tcp -p tcp --dport 548 -j DNAT --to-destination <ubuntu_server_IP>

# Rerouting SSH calls to the file server coming from the LAN/WiFi
iptables -t nat -A PREROUTING -d <my_fixed_IP>/32 -i br0 -m tcp -p tcp --dport 2222 -j DNAT --to-destination <ubuntu_server_IP>

# Route incoming AFP from the Internet to the file server (port 548)
iptables -t nat -A PREROUTING -d <my_fixed_IP>/32 -i eth0 -m tcp -p tcp --dport 548 -j DNAT --to-destination <ubuntu_server_IP>
iptables -A FORWARD -d <ubuntu_server_IP>/32 -i eth0 -m tcp -p tcp --dport 548 -j ACCEPT

# Route incoming SSH from the Internet to the file server (Bubba port 2222 → Ubuntu port 22)
iptables -t nat -A PREROUTING -d <my_fixed_IP>/32 -i eth0 -m tcp -p tcp --dport 2222 -j DNAT --to-destination <ubuntu_server_IP>:22
iptables -A FORWARD -d <ubuntu_server_IP>/32 -i eth0 -m tcp -p tcp --dport 22 -j ACCEPT
# See also part 2, rule for port 2222


#
# PART 2 - INCOMING TRAFFIC
#

# Allow incoming SSH to the Bubba itself (port 22)
iptables -A INPUT -m state --state NEW -p tcp --syn --destination-port 22 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -p tcp --destination-port 22 -j ACCEPT

# Allow incoming SSH to the file server (port 2222)
iptables -A INPUT -m state --state NEW -p tcp --syn --destination-port 2222 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -p tcp --destination-port 2222 -j ACCEPT

# Allow incoming AFP calls to the file server (port 548)
iptables -A INPUT -m state --state NEW -p tcp --syn --destination-port 548 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -p tcp --destination-port 548 -j ACCEPT

# Allow SMTP traffic (port 25)
iptables -A INPUT -m state --state NEW -p tcp --syn --destination-port 25 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -p tcp --destination-port 25 -j ACCEPT

# Allow IMAP traffic (port 143)
iptables -A INPUT -i eth0 -p tcp --dport 143 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 143 -m state --state ESTABLISHED -j ACCEPT

# Allow IMAPS traffic (port 993)
iptables -A INPUT -i eth0 -p tcp --dport 993 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 993 -m state --state ESTABLISHED -j ACCEPT

# Allow POP3 traffic (port 110)
iptables -A INPUT -i eth0 -p tcp --dport 110 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 110 -m state --state ESTABLISHED -j ACCEPT

# Allow POP3S traffic (port 995)
iptables -A INPUT -i eth0 -p tcp --dport 995 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 995 -m state --state ESTABLISHED -j ACCEPT

# Allow HTTP traffic to the webserver (port 80)
iptables -A INPUT -m state --state NEW -p tcp --syn --destination-port 80 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -p tcp --destination-port 80 -j ACCEPT

# Allow HTTPS traffic to the Bubba's own /admin webserver (port 443)
iptables -A INPUT -m state --state NEW -p tcp --syn --destination-port 443 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -p tcp --destination-port 443 -j ACCEPT

# Allow incoming answers
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT


#
# PART 3 – OUTGOING TRAFFIC
#

# Allow outgoing SSH
iptables -A OUTPUT -o eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT

# Allow outgoing pings
iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT

# Allow outgoing DNS
iptables -A OUTPUT -p udp -o eth0 --dport 53 -j ACCEPT
iptables -A INPUT -p udp -i eth0 --sport 53 -j ACCEPT

# Allow traffic from the LAN (eth0) to go out on-line (eth1)
# iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
# Is this necessary? If it is, then maybe a similar rule should be used for traffic from the WiFi, but I'm not sure.


#
# PART 4 – ADMINISTRATIVE STUFF
#

# Load balance incoming web traffic
iptables -A PREROUTING -i eth0 -p tcp --dport 80 -m state --state NEW -m nth --counter 0 --every 3 --packet 0 -j DNAT --to-destination 192.168.1.101:80
iptables -A PREROUTING -i eth0 -p tcp --dport 80 -m state --state NEW -m nth --counter 0 --every 3 --packet 1 -j DNAT --to-destination 192.168.1.102:80
iptables -A PREROUTING -i eth0 -p tcp --dport 80 -m state --state NEW -m nth --counter 0 --every 3 --packet 2 -j DNAT --to-destination 192.168.1.103:80

# Prevent DoS attacks against HTTP, HTTPS and mail ports
# HTTP
iptables -A INPUT -p tcp --dport 80 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT
# HTTPS
iptables -A INPUT -p tcp --dport 443 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT
# SMTP
iptables -A INPUT -p tcp --dport 25 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT
# POP3
iptables -A INPUT -p tcp --dport 110 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT
# IMAP
iptables -A INPUT -p tcp --dport 143 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT
# IMAPS
iptables -A INPUT -p tcp --dport 993 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT
# POP3S
iptables -A INPUT -p tcp --dport 995 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT

# Block port scanning
iptables -A port-scan -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -RETURN
iptables -A port-scan -j DROP

# Create a chain for logging and dropping traffic
iptables -N logdrop
iptables -A logdrop -j LOG
iptables -A logdrop -j DROP

# Log and drop new TCP packets that are not SYN packets
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "NEW NOT SYN "
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

# Log and lock out netbus
iptables -A INPUT -p tcp --destination-port 12345 -j logdrop
iptables -A INPUT -p udp --destination-port 12345 -j logdrop

# Locking out particular nets (x.x.x.x). Use when needed.
# iptables -A INPUT --source x.x.x.x/8 -j DROP

# Allow loopback
iptables -A INPUT --in-interface lo --source 127.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --in-interface lo --source $ME --destination $ME -j ACCEPT

# Blocking loopback calls coming from the outside
iptables -A INPUT --in-interface ! lo --source 127.0.0.0/8 -j DROP

# Block everything else that comes in
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT


=============
Rule set End

[Gordon]

Wow! You're really throwing the whole Bubba firewall concept overboard now are you?

A quick glimpse then.

1. That first rule doesn't really make that much sense to me. The object of this type of rules is to be able to route-back, i.e. to access a service that is connected to the same interface that you are connected to yourself but is being accessed through an address that is assigned to a different interface on the firewall. The rule as it stands here would only make sense if the SSH service on the loopback interface is different from the one that is listening on the WAN interface.

2. I'm seeing a load of state related, established lines for independent ports in there, but there's also one that declares the same for all ports. I think you should just stick to that last one - the others seem a bit overkill.

3. In the forward rule to enable computers connected to LAN to access the internet you have interface eth1 while in the prerouting statements on top it states interface br0. You can't have both in here and yes if you do separate the bridge you will need additional rules for the wlan0 interface.

4. There's no masquerade rule


If I can make a suggestion, you should look at Shorewall. Or did you already - that logdrop construct kind of looks familiar? Also, a rule that I find particularly useful is to reject port 25 if that traffic does not include my mailserver (i.e. being source or destination). Let's just say I like to be careful with the Windows operated machines I keep around.

[Anders_W]

Thank You for Your kind comments.

I am afraid that I am a complete newbie at these things - years ago, I went Mac in order not to ever see a command prompt again (being our tools, machines should adapt to people, not the other way around), but unfortunately, the world developed in a different direction. Please excuse my ignorance of technical details.

To answer Your comments:

1. I would like to access the B3 and the file server by typing in <my_fixed_ip> wether in the Terminal, web browser or Mac OS X's "Connect to server" window. But I suppose that I could just write "b3" in the Terminal window when I am at home, so this rule will be dropped.

2. That last rule, "allow all incoming answers" is a bit of a cheapskate solution, since I am not sure which ports client software on my local computers might want to use. I think I will let it be, since it seems not to do much harm, and I can block any one of the listed server ports if needed be by removing its particular rules.

3. Here my ignorance shines through. I do not know what names to use for the different interfaces. (Any suggestions are very welcome.)
I feared that IPTables might see the wire-LAN and the WiFi as separate entities. Does this mean that I have to write duplicate rules for accessing stuff from the WiFi? The though fills me with dread...
(The file server will be attached through the wire-LAN, but the client computers will most likely access it from the WiFi.)

4. Again, my ignorance shines through. I do not even know how to do that; I thought that ordinary NAT was innate in the B3. Can You enlighten me?

5. I actually got the log-drop-chain from one of the home pages listed at the top, but it is quite possible that the author got it from a ShoreWall configuration or manual.
I have looked at the ShoreWall homepage, but it seems to be very complicated - so much so that it might just be easier to write the IPTables rules instead. Also, to get what I want out of the B3 I would have to use the three-interface variant, but that requires the DMZ (non-safe web server in my case) to be a separate computer, whereas I thought I would use the B3 itself with an attached USB-harddrive.

[Gordon]

Well now, where to start....

Lets go with 1: The thing is that a specific service can in fact behave differently on each interface. You may even have a service that attaches itself to a port on a specific interface, and a second service that uses the same port on another interface. By targeting the correct IP address you can in fact access both services as long as you're allowed to reach that IP (forward rule). Now if this is what you want, you do not need to add any type of rule in iptables. The fun starts if you want something different to happen when internal users address a certain port on the external IP of your firewall machine - most commonly to access a (NATted) server that is in the same LAN segment as they are.

2. This is the task of the connection tracker - if your LAN user can't initiate a connection there can be no package that will receive the state established or -related. The object should therefore be to prohibit your LAN user to initiate that connection in the first place, not to flood the internet with requests to which no answer can be received.

3. Logically the B3 is a two interface device, even though if you look at the hardware it has three (provided you have the WiFi version). To get a quick view of the active interfaces and their assigned addresses, type:

Code: Select all

ip -f inet -o addr

4. That would be a misconception. The B3's firewall capabilities as well as NAT functions are based on what iptables provides. If you list the content of /etc/network/firewall.conf, you'll find the masquerading rule(s) in the POSTROUTING chain of the nat table.

5. Building a three interface firewall on a (logical) two interface machine is probably as unsafe as having a single interface firewall (a.k.a. fool's firewall). Since your webserver is actually sitting in your LAN segment - the same segment that holds your clients - there would be hardly any sense to go the distance on this. Of course you could split the bridge to have eth0, eth1, and wlan0, but the safe bet would be to stick with the default and consider the latter once you got the two interface setup hammered.

6. I finally got the stuff in that should replace my business requirements on the B3, giving me room to do some more experimenting on it. First object is to implement Shorewall and I plan to start that with a conversion of the default bubba-firewall rules. I can post the file listings for that if you like.

[Anders_W]

Hmmm... I see.

I will delve into these issues.

Regarding point 6: Please do so. That would be interesting to read.



Edit:

I just ran the ip command. The output looks like this:

1: lo inet 127.0.0.1/8 scope host lo
2: eth0 inet 192.168.1.67/24 brd 192.168.1.255 scope global eth0
5: br0 inet 192.168.10.1/24 brd 192.168.10.255 scope global br0

Running "ip route ls" as root, as ShoreWall's how-to recommends, gives this:

192.168.10.0/24 dev br0 proto kernel scope link src 192.168.10.1
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.67
default via 192.168.1.1 dev eth0

The WAN interface is thus eth0.

I should add that currently, all local computers are connected through the WiFi; the wire-LAN is yet to be physically built.


Edit 2:
Regarding point 4: The post routing part of firewall.conf reads

OSTROUTING ACCEPT [3:460]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT

So I guess I should add this to the "Administrative stuff" section of the draft?