Things to be careful about when setting up iptables rules

[alexander]

Ok here's a gocha i just figured out with iptables, iptables does exactly what you tell it to, which is exactly what you want it to do, but sometimes one's understanding of exactly what it is that it will do is wrong :cheer:

 

So here is how a simple misconception of what exactly a rule will do, can totally open your firewall.

 

here is a simple and oftenly used example that is supposed to prevent your firewall from being punded by a syn flood:

# lets say we want a safe config to open up ssh only on a box
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT
# then we want to protect from syn floods
iptables -A INPUT -p tcp --syn -m limit --limit 5/s -j ACCEPT
# we dont want to break connections that are established and whatnot, so we need
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# and lets say the next line would be something like
iptables -A INPUT -j REJECT --reject-with icmp-host-prohibited

 

so ideally this should reject all, but 22, right? so then we run an nmap on the box, and wouldn't you know it, see something like this:

PORT     STATE SERVICE
22/tcp   open  ssh
111/tcp  open  rpcbind
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds

wtf, right?

 

So where did our config go wrong? Well, remember that iptables does exactly what we well it, so our syn flood protection line will allow bursts of syn packets for 5 seconds to all our ports, sure, makes nmap scans take a lot longer, but we have no blocking, because we are allowing through syn to connect to all of our ports, and we are allowing further connections with the next rule for established connections... thus we basically just effectively opened our box right up :(, we start screaming at iptables, iptables is like :doh: "I do what you tell me to", and you are like "Oh no you di'ent", and iptables is like "Wha'eva chicka"

 

Yes, so to remedy the issue, you can either remove the syn flood protection rule, or you can make it only act on "ESTABLISHED" connections, which means only after one successfully creates a connection to a service, does your syn flood rule take effect, preventing all your ports from being seen, until you open them :)

 

hopefully this will save someone some frustration of "WTF I never opened it, why is it shown as open!!!"

[freeztar]

What switches are you using for nmap?

 

I'm actually trying to open up ports 2077-2078 to use webdav for my hosting so I can use webdisk. Using Nautilus, I get an access denied error. So, I went to cl and typed iptables -A INPUT -p tcp -d 0/0 -s 0/0 --dport 5900 -j ACCEPT and it returned me to prompt. Tried connecting in Nautilus again and it's still not working. :phones:

 

Any ideas?

 

I'll have to try your suggestions above for syn flood, but I want to get this squared away first, if possible. Iptables is new to me. ;)

[alexander]

freezy, iptables, like all the other firewalls, reads the rules from the top down, meaning if you have a deny all rule above the one you just added, your rule will never be applied...

 

hence the importance of having a firewall.sh script, so you can edit things, and not have to recreate rules you had before, but just forgot :eek2:

 

usually nmap -sS ip

(if you wanted to scan the first 52 ports, just add -p 0-52)

(if you wanted to do full os detection, a -A)

Oh, be careful, you give it 0-65535, prepare to wait for eternity, lol ;) scan what you need, no -p scans 1000 most used ports and is pretty fast (though with my rule set, it still takes 10 minutes to scan 1000 ports)

[alexander]

iptables -L lists your current rule set, if you care to share, i'll try to tell you where the problem lies :eek2: (if its even there)

 

also, can you reach 5090 that locally?

[freeztar]

  alexander said:

freezy, iptables, like all the other firewalls, reads the rules from the top down, meaning if you have a deny all rule above the one you just added, your rule will never be applied...

 

hence the importance of having a firewall.sh script, so you can edit things, and not have to recreate rules you had before, but just forgot :hihi:

 

usually nmap -sS ip

(if you wanted to scan the first 52 ports, just add -p 0-52)

(if you wanted to do full os detection, a -A)

Oh, be careful, you give it 0-65535, prepare to wait for eternity, lol :) scan what you need, no -p scans 1000 most used ports and is pretty fast (though with my rule set, it still takes 10 minutes to scan 1000 ports)

 

Thanks Alex. :)

 

I need to check into firewall.sh. I certainly want everything in a logical order that is repeatable. And yes, I will back it up. :)

 

Right now I'm running nmap -sS ip -p 0-65535

Now I'm just waiting on eternity. ;)

 

Thanks for the tips. As a virgin, it's always nice to hear the most basic stuff and what to look for. I'm not too fond of guarddog and I'm becoming much more comfortable (and hence biased) with command line. What do you use? Simply rules in firewall.sh?

 

Ok I'll stop now. I need to go read a bunch to catch up. BTW, thanks for the link, in the other thread, about subnet masks. It's one thing to pull the trigger and shoot a gun, and a whole different ball of wax to understand the mechanics behind the firing mechanism and fuel. :) (eg. aha! Those x.x.x.x represents bits!) Now, if I could get my head around the conversion to ipv6 hex representations. :hihi:

 

Hmm...While I'm waiting, I'm puzzled by this first line of output:

 

Warning: Hostname ip resolves to 2 IPs. Using xx.251.179.xx

(xx's used to hide IP)

 

Is this a .conf problem? Why is it resolving 2 IPs?

 

Lots to read and I appreciate how you do not give a direct answer, but expect that those interested will research and find it for themselves. Kudos. But I've got my work cut out for me. :P

[freeztar]

Ok, here's what would help me the most right now. I need to eliminate the possibility that I'm blocking access to webdav. How do I open everything up all the way? :hihi:

 

I've read some bug reports related to the webdav access problems in Nautilus. I want to rule this out, if possible. If I can open everything up, and then try connecting to my host's web disk (rudimentary webdav) and then clamp everything down, that would help me determine if it is a nautilus problem or a network problem.

 

Some say that Ubuntu closes everything by default and only opens ports when requested. In that case, webdav should work, but I want to be completely sure that it is an unresolved Nautilus bug before I waste time trying to work around something that is unworkable.

[alexander]

firewall.sh (this is a constant wip for me, this is version 1.6)

#!/bin/bash

if [ -z "`ps -a | grep screen`" ]; 
then 
   while :
   do
echo "You should really consider running this in screen! Continue? [n]:";
read yn;
case $yn in
    "y" ) break;;
    "Y" ) break;;
    * ) exit 0;;
esac
   done
fi

# firewall.sh v1.6
echo "Flushing previous config"

# Flush rules but keep policies

iptables -F

iptables -X MY-INPUT



echo "Setting up new chain"

## Firstly lets create our own rule set, and forward the default rule sets to it :( ###

iptables -N MY-INPUT

iptables -A INPUT -j MY-INPUT

iptables -A FORWARD -j MY-INPUT



echo "Propagating new rule set"

## Inbound Rule Set

# accept our own traffic

iptables -A MY-INPUT -i lo -s 127.0.0.0/8 -j ACCEPT

## Lets drop traffic we know is BAD

# drop fragmented packets
iptables -A MY-INPUT -f -j DROP
# drop malformed XMAS packets
iptables -A MY-INPUT -p tcp --tcp-flags ALL ALL -j DROP
# drop null packets
iptables -A MY-INPUT -p tcp --tcp-flags ALL NONE -j DROP

## Time to open up ports :)

# accept multicast DNS traffic

iptables -A MY-INPUT -m udp -p udp --dport 5353 -s 224.0.0.251 -j ACCEPT

# SSH, very important

iptables -A MY-INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT

# MySQL

# external server
#iptables -A MY-INPUT -p tcp -m state --state NEW --dport 3306 -j ACCEPT

# HTTP
#iptables -A MY-INPUT -p tcp -m state --state NEW --dport 80 -j ACCEPT

# HTTPS
#iptables -A MY-INPUT -p tcp -m state --state NEW --dport 443 -j ACCEPT

# SIP
#iptables -A MY-INPUT -p udp -m state --state NEW --dport 5060 -j ACCEPT
#iptables -A MY-INPUT -p tcp -m state --state NEW --dport 5060 -j ACCEPT
#iptables -A MY-INPUT -p udp -m state --state NEW --dport 10000:20000 -j ACCEPT

# Samba ports that might need to be opened

# samba server
#iptables -A MY-INPUT -p udp -m state --state NEW -m multiport --dports 137,138 -j ACCEPT
#iptables -A MY-INPUT -p tcp -m state --state NEW -m multiport --dports 137,139,445 -j ACCEPT

# samba client
#iptables -A MY-INPUT -p udp -s 10.0.0.0/8 -m multiport --dports 137,138 -j ACCEPT
#iptables -A MY-INPUT -p tcp -s 10.0.0.0/8 -m multiport --dports 137,139,445 -j ACCEPT
#iptables -A MY-INPUT -p udp -m state --state NEW,ESTABLISHED -m multiport --dports 137,138 -j DROP
#iptables -A MY-INPUT -p tcp -m state --state NEW,ESTABLISHED -m multiport --dports 137,139,445 -j DROP

# Restrict ICMP to ECHO type only, also limit that to no more then 3 packets a second so noone drowns us

iptables -A MY-INPUT -p icmp -m icmp --icmp-type echo-request -m limit --limit 3/s -j ACCEPT

# this closes the possiblity that could disclose the system's internal time which is at the root of most crypto keys

iptables -A MY-INPUT -p icmp -m icmp --icmp-type timestamp-request -j DROP

# lets also procect from syn floods a little bit                               

iptables -A MY-INPUT -p tcp --syn -m state --state ESTABLISHED -m limit --limit 5/s -j ACCEPT

# DNS often goes over established or related states, this is preferable to have                                                                               
iptables -A MY-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Bottom line is reject all

iptables -A MY-INPUT -j REJECT --reject-with icmp-host-prohibited


## Now lets create a set of outbound rules



# Allow our own traffic to ourselves

#iptables -A OUTPUT -d 127.0.0.0/8 -j ACCEPT

# drop icmp timestamp

#iptables -A OUTPUT -p icmp -m icmp --icmp-type timestamp-reply -j DROP

#iptables -A OUTPUT -p icmp -m icmp --icmp-type echo-reply -j ACCEPT

# lets just allow established and related treaffic out

#iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# SSH

#iptables -A OUTPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

# HTTP

#iptables -A OUTPUT -p TCP --dport 80 -m state --state NEW -j ACCEPT

# HTTPS

#iptables -A OUTPUT -p TCP --dport 443 -m state --state NEW -j ACCEPT

# DNS

#iptables -A OUTPUT -p UDP --dport 53 -m state --state NEW -j ACCEPT

# DNS (TCP fallback)

#iptables -A OUTPUT -p TCP --dport 53 -m state --state NEW -j ACCEPT

# FTP

#iptables -A OUTPUT -p TCP --dport 21 -m state --state NEW -j ACCEPT

# NTP

#iptables -A OUTPUT -p udp --dport 123 -m state --state NEW -j ACCEPT

# AD stuff

#iptables -A OUTPUT -p udp -m multiport --dports 137,138 -m state --state NEW -j ACCEPT

#iptables -A OUTPUT -p tcp -m multiport --dports 139,445 -m state --state NEW -j ACCEPT

# Reject the rest

#iptables -A OUTPUT -j REJECT --reject-with icmp-host-prohibited

# This will save your butt, so dont coment it out
echo "Creating and running a save-your-butt-script"
# create and run the recovery script, just in case
echo -e "#!/bin/shnsleep 180niptables -Fn" > save_your_butt.sh
/bin/sh save_your_butt.sh &
echo -e "The rules are properly set up, you should kill the saving scriptnnkillall /bin/sh && rm save_your_butt.sh && killall sleepn"

 

add whatever services you need opened, plenty of examples there...

 

also iptables -F flushes the current rules...

  Quote

Warning: Hostname ip resolves to 2 IPs. Using xx.251.179.xx

means that there are 2 boxes that are named the same thing,.. or that there is a dirty dns record....

[freeztar]

  alexander said:

firewall.sh (this is a constant wip for me, this is version 1.6)

Cool, thanks. So where do I stick that file?

  Quote

means that there are 2 boxes that are named the same thing,.. or that there is a dirty dns record....

 

How can two boxes have the same IP? Wouldn't that prevent one or the other from getting online simultaneously? (which is not the case-only two boxes active right now and both connect and have different IPs assigned by DHCP)

 

How do I check for a dirty DNS record?

[alexander]

different IPs, same DNS record.

 

You can have duplicate IPs if you assigned one manually and it's in the range of your DHCP server, DHCP can give that ip to another box and you have a conflict, or if IP is set statically for both boxes.... (but that's a dns issue, saying that that box's name is present twice with with different IPs on the network)

 

you don't put that file anywhere in particular, it's a bash script that first flushes the firewall rules and then recreates them, you just run the script as root...

 

but UNDERSTAND what it is doing before you run it, please and edit it to suit YOUR needs (like opening webdav port or whatever)

[freeztar]

  alexander said:

different IPs, same DNS record.

 

You can have duplicate IPs if you assigned one manually and it's in the range of your DHCP server, DHCP can give that ip to another box and you have a conflict, or if IP is set statically for both boxes.... (but that's a dns issue, saying that that box's name is present twice with with different IPs on the network)

 

How does that happen? When I got the error, only one machine was powered on?

 

  Quote

you don't put that file anywhere in particular, it's a bash script that first flushes the firewall rules and then recreates them, you just run the script as root...

Oh...hence the .sh :)

 

  Quote

but UNDERSTAND what it is doing before you run it, please and edit it to suit YOUR needs (like opening webdav port or whatever)

 

Right. I understand what it is doing (I think), except for some of the attributes. But that's simply a matter of doing some reading.

 

Quick question: Will guarddog (or similar prog) overwrite or otherwise conflict with the rules this script sets up?

[alexander]

most of the products like guarddog are simply GUI configuration utilities for iptables...

 

Just like firewall builder (great prog btw), kmyfirewall and bitfrost