LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 10-23-2007, 07:50 PM   #1
Azalar
Member
 
Registered: Jan 2006
Distribution: Ubuntu
Posts: 42

Rep: Reputation: 15
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?
 
Old 10-23-2007, 08:55 PM   #2
win32sux
LQ Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 379Reputation: 379Reputation: 379Reputation: 379
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):
Code:
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 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.

Last edited by win32sux; 10-23-2007 at 09:12 PM.
 
Old 10-24-2007, 03:26 AM   #3
Azalar
Member
 
Registered: Jan 2006
Distribution: Ubuntu
Posts: 42

Original Poster
Rep: Reputation: 15
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.
 
Old 10-24-2007, 03:34 AM   #4
win32sux
LQ Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 379Reputation: 379Reputation: 379Reputation: 379
Quote:
Originally Posted by Azalar View Post
Doe sftp use a different port to ssh(22) ?
No.

Quote:
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.
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.

Quote:
Part of the problem is not knowing which services i actually need and dont need.
Well, you are off to a good start by firewalling everything except the two services you know you need.

Quote:
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.
If you register your domain/subdomain at one of the popular DNS service providers you won't need a DNS server at all.

Last edited by win32sux; 10-24-2007 at 03:43 AM.
 
Old 10-24-2007, 09:25 AM   #5
nomb
Member
 
Registered: Jan 2006
Distribution: Debian Testing
Posts: 675

Rep: Reputation: 58
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
 
Old 10-24-2007, 10:03 AM   #6
Azalar
Member
 
Registered: Jan 2006
Distribution: Ubuntu
Posts: 42

Original Poster
Rep: Reputation: 15
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?
 
Old 10-24-2007, 11:18 AM   #7
nomb
Member
 
Registered: Jan 2006
Distribution: Debian Testing
Posts: 675

Rep: Reputation: 58
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.

Quote:
Originally Posted by Azalar View Post
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: "
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.


Quote:
Originally Posted by Azalar View Post
There is no one else using the machine so I no worries about jailing.
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.

Last edited by nomb; 10-24-2007 at 11:23 AM.
 
Old 10-24-2007, 12:35 PM   #8
win32sux
LQ Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 379Reputation: 379Reputation: 379Reputation: 379
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.
 
Old 10-24-2007, 01:04 PM   #9
Azalar
Member
 
Registered: Jan 2006
Distribution: Ubuntu
Posts: 42

Original Poster
Rep: Reputation: 15
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?
 
Old 10-24-2007, 01:22 PM   #10
nomb
Member
 
Registered: Jan 2006
Distribution: Debian Testing
Posts: 675

Rep: Reputation: 58
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
 
Old 10-24-2007, 01:37 PM   #11
win32sux
LQ Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 379Reputation: 379Reputation: 379Reputation: 379
Or put the rules in a shell script, then execute it.
 
Old 10-24-2007, 01:46 PM   #12
nomb
Member
 
Registered: Jan 2006
Distribution: Debian Testing
Posts: 675

Rep: Reputation: 58
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
 
Old 10-24-2007, 06:24 PM   #13
Azalar
Member
 
Registered: Jan 2006
Distribution: Ubuntu
Posts: 42

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by nomb View Post
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
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?
 
Old 10-24-2007, 06:53 PM   #14
Azalar
Member
 
Registered: Jan 2006
Distribution: Ubuntu
Posts: 42

Original Poster
Rep: Reputation: 15
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?
 
Old 10-25-2007, 12:59 AM   #15
win32sux
LQ Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 379Reputation: 379Reputation: 379Reputation: 379
Quote:
Originally Posted by Azalar View Post
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.
Yes.

Quote:
But if i have the input policy said to reject as i had originally it immediately gives the user a message
In your post your policy is ACCEPT, not REJECT.

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

Quote:
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?
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.

Last edited by win32sux; 10-25-2007 at 02:27 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
How to set the password policy and lockout policy bin_shell Linux - Security 4 03-24-2010 04:30 PM
Samba System Policy, Default User Policy scooter549 Linux - General 2 02-24-2009 03:23 AM
hardware firewall port policy advice needed Chris594 Linux - Security 2 02-15-2007 08:23 AM
Firewall Builder sample firewall policy file ? (.xml) nuwanguy Linux - Networking 0 09-13-2003 01:32 PM
Strict DHCP puzz_1 Linux - Networking 8 06-05-2003 01:20 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 12:29 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration