Firewall policy too strict?
 

I am new to using iptables so I am unsure whether the firewall rules i have setup are too strict and wondered what others thought.
Basically I have a remote server which I will be using for hosting web sites so i only need the ssh and http ports open.
I guess ill need ftp too so i can upload things too.
As far as i can see every other packet can just be rejected.
There are other services running that i dont yet understand what they are or how to shut them down ( or indeed whether its safe to shut them down at all) so i figured using iptables to prevent access for now would be the safest bet.
My current rules are like this..

iptables -A INPUT -p tcp --destination-port 22 -j ACCEPT
iptables -A INPUT -p tcp --destination-port 80 -j ACCEPT
iptables -A INPUT -p tcp -j REJECT
iptables -A INPUT -p udp -j REJECT
iptables -A INPUT -p icmp -j REJECT

Is this set ok or do you think it could cause problems elsewhere?

It's a start, but you'll need to do more if you want a strict setup. I would say what you have there is actually too relaxed. For starters, you should have your policy set to DROP and get rid of those REJECTs IMHO. It's also important that you take care of the OUTPUT chain too, instead of only focusing on the INPUT, and implementing some logging is always a good idea. There's lots of things you can do to tighten your script up, but basically, the question to be asked here is: What are you aiming for? Once that is clear, it'll be easier for people to give you suggestions. I'll get the ball rolling by suggesting that you use something like this instead of what you posted (it's not a super strict setup either, but it's tighter than what you have right now):I added a rule for the loopback interface, which you seem to have left out.

BTW, I would suggest you avoid FTP if possible - stick to SFTP instead.

Doe sftp use a different port to ssh(22) ?
Well what i am aiming for is to only allow access to services that i know about so its less to worry about.
For instance on the security mailing lists the latest holes get posted and if i only had ssh and http i could maybe concentrate on those and know that services that i am not running or at least have blocked access to i can ignore.
Part of the problem is not knowing which services i actually need and dont need.
Like why would i need to allow my dns server to be accessed externally? As long as i can access it internally surely thats enough?
So basically i just want to use my server to learn web development with the minimum of fuss needed to administrate it.

No.

Well, firewalling is great, but it's not a replacement for stopping unnecessary services. Ideally, you would want to stop all unnecessary services in addition to firewalling them. In reality, many people only go as far as firewalling and do just fine. But it's better to be safe than sorry. Unnecessary services (even if they are firewalled) can be used to further penetrate a box by an attacker who hit one of the non-firewalled services. They also leave your box at much higher risk whenever the firewall is lifted, like for example if you were tweaking the firewall config or something like that.

Well, you are off to a good start by firewalling everything except the two services you know you need.

If you register your domain/subdomain at one of the popular DNS service providers you won't need a DNS server at all.

Keep in mind that working on the firewall is great but it is only one side of making a secure system. You need to make sure you secure both ftp and ssh if you are going to be having users using them.

- Jail the user to their home. Since this is a web host I'm assuming you are using apache and I'm assuming your using the module that has their sites in the public_html folder of the home directory. I would actually jail them to that and not let them in their home but that is a pesonal prefrence.

- Secure your ssh. Make sure you have the following in your sshd_conf file:

• PermitRootLogin No
• Protocol 2
• MaxAuthTries (what ever you feel comfortable with)
• AllowUsers user1 user2 user3 (this allows only select users to use ssh)
• AllowGroups group1 (this allows select groups to use ssh)
• Port 22 (You can easily change this and let your clients know what port to use to help stay off bruteforce attacks)

Also, you want them to be allowed to ssh in. But be weary of them sshing out. They could try to use you as a middle box to throw off the trail of what they are doing.

You can either use pam to disallow them from using the sshclient on the server, or you can setup a group to do the same thing. I can help you with the group and I think win32sux can help you with pam.

For ftp I would turn of anonymous access. Other then that I'm not sure because I don't remember what I did to my server.

I would also install fail2ban.

nomb

I should mention this is my own dedicated machine and have full control of the box.
There is no one else using the machine so I no worries about jailing.
The only restrictions i really want are that hackers cant get in and cause havoc.
I had already secured ssh via the methods you mentioned already but will need to look into the other things.

regarding the new rules you suggested which i pasted below..

iptables -P INPUT DROP
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p TCP -i eth0 --dport 22 -m state --state NEW -j ACCEPT
iptables -A INPUT -p TCP -i eth0 --dport 80 -m state --state NEW -j ACCEPT
iptables -A INPUT -m limit --limit 1/second -j LOG --log-prefix "INPUT DROP: "

I was under the impression the rules were dealt with in the order of the file.
So to me the rules you suggested look like it will drop all packets in the first input rule and then progress no further down the chain.

That is why my order was the reverse of this.
I set the ports i wanted open first then rejected everything else, like this..

ptables -A INPUT -p tcp --destination-port 22 -j ACCEPT
iptables -A INPUT -p tcp --destination-port 80 -j ACCEPT
iptables -A INPUT -p tcp -j REJECT
iptables -A INPUT -p udp -j REJECT
iptables -A INPUT -p icmp -j REJECT

Can you clarify this?
Also whats the benefits of dropping rather than rejecting packets?

I don't know much about iptables altho I have been trying to learn. I did do some research so I could explain this to you because I was curious myself.

iptables -P INPUT DROP - This rule says that if a packet goes through the full INPUT chain and doesn't match any other rule then drop it.

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT - This rule allows incoming connection so long as you are the one who established that connection first.

iptables -A INPUT -i lo -j ACCEPT - This rule allows you to access the loopback address. (127.0.0.1)

iptables -A INPUT -p TCP -i eth0 --dport 22 -m state --state NEW -j ACCEPT - This rule allows packets on eth0 who's destination port is 22.

iptables -A INPUT -p TCP -i eth0 --dport 80 -m state --state NEW -j ACCEPT - This rule allows packets on eth0 woh's destination port is 80.

iptables -A INPUT -m limit --limit 1/second -j LOG --log-prefix "INPUT DROP: " - This rule logs the dropped packets in the log file to a max of one timer per second.

Ok, so you see you don't have any specific drop rules in here. The very first rule is a 'catch-all' for any other packet not matching a rule. I hope this helps.


If you have people using ftp or ssh then you have other people using your machine. 'Jailing' means those users can only stay in one folder like their home folder so they wont have access to others. More so, what ever folder you set them to they see as the server's /. If you are going to provide hosting for other people (I'm assuming you are) you need to set this up.

nomb

P.S. - To answer your question, the order of the rules is very important. The first rule that is matched is the one that is fired.

Yeah, the "-P" line sets the policy for the chain. As said by nomb, it is where packets go when they don't match any rules in the chain. It's also a good idea to make sure your policy is set before you execute any rules. The difference between DROP and REJECT is that REJECT sends back an error message to the packet's sender, while DROP - well - just DROPs the packet. By using DROP you are limiting the amount of information which you give-out, which is a good thing in most situations. REJECT is, IMHO, more suitable for use on friendlier networks, such as your LAN.

BTW, I highly recommend Oskar Andreasson's super-famous iptables tutorial if you wanna read-up on this stuff.

I have a problem.
I wanted to try the new ruleset you guys suggested so first i cleared my existing chain with the flush option.
Applying the first rule locked me out of my own server because it drops packets now while i'm connected to it :)
I can get my host to clear this but my question is how can i apply the new ruleset on a remote server without locking myself out?

First use iptables-save to save ur current rules.
Modify the .save file to include the ruleset that you want.
Then use iptables-restore to apply the new ruleset.

Atleast that is what I did.

nomb

Or put the rules in a shell script, then execute it.

I used scripts on my Debian box and I do like that better. I can give you those scripts a little later when I'm not at work if you'd like.

win32sux when would you use sport vs dport?

nomb

My current save file based on the old ruleset looks like this..

# Generated by iptables-save v1.3.6 on Wed Oct 24 07:29:16 2007
*filter
:INPUT ACCEPT [100:12086]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [219:32205]
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p icmp -j REJECT --reject-with icmp-port-unreachable
COMMIT
# Completed on Wed Oct 24 07:29:16 2007

I can understand the bottom parts as i recognise my own rules but could you explain these parts..

*filter
:INPUT ACCEPT [100:12086]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [219:32205]

I'm guessing it represents the default policies for each chain but what are the numbers after in square brackets?
Also whats the relevance of *filter?

I managed to edit the saved file and restore with the new rules.
I temporarily removed http and tried to access my web site to test this and noticed something.
If the input policy is set to drop the the web site just hangs there saying Loading and eventually times out after a few minutes.
But if i have the input policy said to reject as i had originally it immediately gives the user a message as if the isnt a server there at all.
Im just wondering if what win32sux is correct about the difference between reject and drop.
Surely the behaviour of drop gives the user more of a clue that there is a server behind the firewall because it hangs around for a while whereas the reject just appears as if there is nothing there?

Yes.

In your post your policy is ACCEPT, not REJECT.

But yes, once again, REJECT sends back an error message, and DROP doesn't.

If you would take a moment to read any decent iptables tutorial you would see that this is a topic which is well-covered. Even if you would just take a look at the iptables man page (man iptables) you would put your doubts to rest. The icmp-port-unreachable message which made your browser provide the user a message when using REJECT is nice, but it's a really sucky thing to do on the outside for several reasons. As an example, you'd be tipping-off any scanners that hit your IP on non-listening ports, and you'd provide them with information they can use for further analysis, such as OS fingerprinting.

PS: If there is "nothing there" then the DROP behavior is consistent (nothing is done). You can't send back an error message if there is "nothing there" to send it from. So by using REJECT you are essentially confirming that there is indeed something there.