Help with IPTABLES (I'm just learning) to review my firewall and explain my mistakes

ninguno1986 · 01-07-2016, 02:54 PM

Hello, I know I'm asking too much, but ill be very grateful if someone can help me by reviewing my firewall, telling where the mistakes are. Also if can you please explain me when should we define interface, since in tutorials i see sometimes are defined while other times not.
Thank you very much.

Code:

#!/bin/bash
#Remove all rules
iptables -F
 
 
# Policy Drop
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
 
#Allow Apache (80/443)
iptables -A INPUT -m state --state NEW -p tcp  --dport 80 -j ACCEPT
iptables -A INPUT -m state --state NEW -p tcp  --dport 443 -j ACCEPT
#Allow http-proxy
iptables -A INPUT -m state --state NEW -p tcp -i eth0 --dport 8080 -j ACCEPT
#Allow port 8443 (Plesk)
iptables -A INPUT -m state --state NEW -p tcp -i eth0 --dport 8443 -j ACCEPT
#FTP
iptables -A INPUT -m state --state NEW -p tcp -i eth0 --dport 21 -j ACCEPT
####MAILING####
#Allow SMTP
iptables -A INPUT -m state --state NEW -p tcp -i eth0 --dport 25 -j ACCEPT
#Allow IMAP
iptables -A INPUT -m state --state NEW -p tcp -i eth0 --dport 143 -j ACCEPT
#Allow IMAPS
iptables -A INPUT -m state --state NEW -p tcp -i eth0 --dport 993 -j ACCEPT
#Allow SMTPS
iptables -A INPUT -m state --state NEW -p tcp -i eth0 --dport 465 -j ACCEPT
#Allow ESMTPS
iptables -A INPUT -m state --state NEW -p tcp -i eth0 --dport 587 -j ACCEPT
#Allow 110
iptables -A INPUT -m state --state NEW -p tcp  --dport 110 -j ACCEPT
########DATABASE####
#Allow Mysql
iptables -A INPUT -p tcp -i eth0 --dport 3306 -j ACCEPT
#Allow PostgreSQL
iptables -A INPUT -p tcp -i eth0 --dport 5432 -j ACCEPT
#Allow DNS
iptables -A INPUT -m state --state NEW -p udp --dport 53 -j ACCEPT
iptables -A INPUT -m state --state NEW -p tcp --dport 53 -j ACCEPT
########## R1soft CDP System ###############
iptables -A INPUT -p tcp -m tcp -s xx.xx.xx.xx --dport 1167 -j ACCEPT
 
 
 
#Allow Nexpose
iptables -A INPUT -m state --state NEW -p tcp -i eth0 --dport 3780 -j ACCEPT
 
##Redirect SSH to port 50683##
iptables -A PREROUTING -t nat -p tcp -d 127.0.0.1 --dport 22 -j DNAT -to 127.0.0.1 --dport 50683
 
 
#We tell iptables to add (-A) a rule to the incoming (INPUT)- SSH works on port 50683 instead 22.
iptables -A INPUT -p tcp -m tcp --dport 50683 -j ACCEPT
iptables -A INPUT -p tcp -m tcp -s xx.xx.xx.xx --dport 50683 -j ACCEPT
iptables -A INPUT -p tcp -m tcp -s xx.xx.xx.xx --dport 50683 -j ACCEPT
iptables -A INPUT -p tcp -m tcp -s xx.xx.xx.xx --dport 50683 -j ACCEPT
iptables -A INPUT -p tcp --dport 50683 -m conntrack --ctstate NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 50683 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 50683 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
iptables -A INPUT -p tcp --dport 50683 -m conntrack --ctstate NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 50683 -m conntrack --ctstate NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 50683 -m conntrack --ctstate NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 50683 -m conntrack --ctstate NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
 
 
 
 
#iptables -A PREROUTING -t nat -p tcp -d 127.0.0.1 --dport 22 -j DNAT -to 127.0.0.1:50683
 
#Reject
iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
iptables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
 
#flood
iptables -N FLOOD
iptables -A FLOOD -m --limit 2/s --limit-burst 5 -j RETURN
iptables -A FLOOD -j DROP
 
iptables -A INPUT -j FLOOD
iptables -A INPUT -p tcp  --dport 80 -j ACCEPT
#HTTP requests limit to 20
iptables -p tcp --syn --dport 80 -m connlimit --connlimit-above 25 --connlimit-mask 24 -j DROP
 
#ALLOW ALL OUTPUT TRAFFIC
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
 
 
iptables -L -n
iptables-save |  tee /etc/iptables.test.rules
iptables-restore < /etc/iptables.test.rules
#service iptables restart

salasi · 01-08-2016, 06:02 AM

I think you'll have to say a bit more about what the box does (what is its intended function, rather than what it might be misused for!) in order to comment sensibly. In particular, the DNS section looks questionable, but I don't know whether this is supposed to be a DNS (caching) server for your internal network, accessible to the outside world, authoritative for your local network... without that kind of info, it is really difficult to comment without writing a tutorial, and if you want a tutorial, a search of the internet might be better...

Edit:

...and. looking at what you have written, it looks as if you have prioritised 'neatness and clarity' above 'efficiency'; is this a deliberate decision, or just the way things have turned out (and, if deliberate, is it sensible? It may well be, but I'd like to understand your thought process in getting there.)

ninguno1986 · 01-09-2016, 03:43 AM

Quote:

Originally Posted by salasi

I think you'll have to say a bit more about what the box does (what is its intended function, rather than what it might be misused for!) in order to comment sensibly. In particular, the DNS section looks questionable, but I don't know whether this is supposed to be a DNS (caching) server for your internal network, accessible to the outside world, authoritative for your local network... without that kind of info, it is really difficult to comment without writing a tutorial, and if you want a tutorial, a search of the internet might be better...

Edit:

...and. looking at what you have written, it looks as if you have prioritised 'neatness and clarity' above 'efficiency'; is this a deliberate decision, or just the way things have turned out (and, if deliberate, is it sensible? It may well be, but I'd like to understand your thought process in getting there.)

Hi Salasi, first of all thank you for your reply,I posted in many forums and your's is the only answer.

This is for a production server which runs a website (2 websites), it needs apache, ssh (despite I changed the port), mail service, bind, r1soft (cdp system), nginx, nexpose, plesk and the ports you see I tried to add exceptions. I want also to redirect the port 22 to a different one (in case I'm scanned). I tried also to apply some defense against flood and ddos.
Neatness its only because I'm bad at this, and I need to remind myself what I tried to do,it is also a way to learn I think.

Let me tell you where im lost (maybe you'll find I'm lost in more senses):

1) Can I specify the interface always, in every rule or only for forwarding?
2) Can I reject instead dropping in all cases?, to cheat on vulnerability scanners or the "reject" rules I added are enough?
3) What the hell is conntrack?
4) what is the difference between "-mstate --state" and "-m conntrack --ctstate"?
5) "WHITE LIST" gives an error, where should I specify it?
6) I saw many versions of my last rules for outgoing traffic (I want to allow all outgoing traffic), its the mine correct?

I modified the firewall and I managed to reduce the errors a lot but yet I get an error about a duplicated rule I can't identify and also when I apply it my connections hangs, flushing the rules and restarting networking services don't help,I need to restart my computer to get internet back, I asked on #iptables at freenode and they don't know what causes it.

Thank you very much again for your time.

Modified code:

Code:

#!/bin/bash
#Remove all rules
iptables -F


# Policy Drop
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT

#Allow Apache (80/443)
iptables -A INPUT -m state --state NEW -p tcp -i eth0  --dport 80 -j ACCEPT
iptables -A INPUT -m state --state NEW -p tcp -i eth0  --dport 443 -j ACCEPT
#Allow http-proxy
iptables -A INPUT -m state --state NEW -p tcp -i eth0 --dport 8080 -j ACCEPT
#Allow port 8443 (Plesk)
iptables -A INPUT -m state --state NEW -p tcp -i eth0 --dport 8443 -j ACCEPT
#FTP
iptables -A INPUT -m state --state NEW -p tcp -i eth0 --dport 21 -j ACCEPT
####MAILING####
#Allow SMTP
iptables -A INPUT -m state --state NEW -p tcp -i eth0 --dport 25 -j ACCEPT
#Allow IMAP
iptables -A INPUT -m state --state NEW -p tcp -i eth0 --dport 143 -j ACCEPT
#Allow IMAPS
iptables -A INPUT -m state --state NEW -p tcp -i eth0 --dport 993 -j ACCEPT
#Allow SMTPS
iptables -A INPUT -m state --state NEW -p tcp -i eth0 --dport 465 -j ACCEPT
#Allow ESMTPS
iptables -A INPUT -m state --state NEW -p tcp -i eth0 --dport 587 -j ACCEPT
#Allow 110
iptables -A INPUT -m state --state NEW -p tcp  --dport 110 -j ACCEPT
########DATABASE####
#Allow Mysql
iptables -A INPUT -p tcp -i eth0 --dport 3306 -j ACCEPT
#Allow PostgreSQL
iptables -A INPUT -p tcp -i eth0 --dport 5432 -j ACCEPT
#Allow DNS
iptables -A INPUT -m state --state NEW -p udp -i eth0 --dport 53 -j ACCEPT
iptables -A INPUT -m state --state NEW -p tcp -i eth0 --dport 53 -j ACCEPT
########## R1soft CDP System ###############
iptables -I INPUT -p tcp  -i eth0  --dport 1167 -j ACCEPT



#Allow Nexpose
iptables -A INPUT -m state --state NEW -p tcp -i eth0 --dport 3780 -j ACCEPT

##Redirect SSH to port 50683##
#REPARAR##iptables -A PREROUTING -t nat -p tcp -i eth0 -d 127.0.0.1 --dport 22 -j DNAT -to 127.0.0.1 --dport 50683



#We tell iptables to add (-A) a rule to the incoming (INPUT)- SSH works on port 50683 instead 22.
iptables -A INPUT -p tcp -m tcp --dport 50683 -j ACCEPT
iptables -A INPUT -p tcp -m tcp -s 111.111.111.111 --dport 50683 -j ACCEPT
iptables -A INPUT -p tcp -m tcp -s 111.111.111.111 --dport 50683 -j ACCEPT
iptables -A INPUT -p tcp -m tcp -s 111.111.111.111 --dport 50683 -j ACCEPT
iptables -A INPUT -p tcp --dport 50683 -m conntrack --ctstate NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 50683 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 50683 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
iptables -A INPUT -p tcp --dport 50683 -m conntrack --ctstate NEW -m recent --set --name SSH
#iptables -A INPUT -p tcp --dport 50683 -m conntrack --ctstate NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 50683 -m conntrack --ctstate NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 50683 -m conntrack --ctstate NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP




#iptables -A PREROUTING -t nat -p tcp -d 127.0.0.1 --dport 22 -j DNAT -to 127.0.0.1:50683

#Reject
iptables -A INPUT -p tcp -i eth0 -j REJECT --reject-with tcp-reset
iptables -A INPUT -p udp -i eth0 -j REJECT --reject-with icmp-port-unreachable

#flood
iptables -N FLOOD
#REPARAR##iptables -A FLOOD -m --limit 2/s --limit-burst 5 -j RETURN
iptables -A FLOOD -j DROP

iptables -A INPUT -j FLOOD
iptables -A INPUT -p tcp  --dport 80 -j ACCEPT
#HTTP requests limit to 20
iptables -p tcp --syn --dport 80 -m connlimit --connlimit-above 25 --connlimit-mask 24 -j DROP

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


iptables -L -n
iptables-save |  tee /etc/iptables.test.rules
iptables-restore < /etc/iptables.test.rules
#service iptables restart

salasi · 01-09-2016, 07:38 AM

Haven't time to give you a really worthwhile answer right now - I'll try to get back later today or tomorrow - but I'll try to make the high level points now and get back to a bit of detail later, perhaps in the light of your further comments.

More use than most of the things that I am about to say is a manual; the man page is pretty good (...for a man page...), but the thing over at frozentux is the one I'd go for. Manual.tutorial and a good reference source, you don't want to be without (eg, download the pdf version).

Quote:

1) Can I specify the interface always, in every rule or only for forwarding?

Always

Quote:

2) Can I reject instead dropping in all cases?, to cheat on vulnerability scanners or the "reject" rules I added are enough?

Reject or drop is your choice. If you have networking problems, reject can make them easier to debug, but does, potentially, make things easier for the bad guys. Drop isn't really in conformance with the relevant Internet RFQs, but a lot of people feel that it is the lesser of two evils.

At this point, I should step back from the strictly iptables questions, and suggest that you also need to think about how your network is set up. Try Linuxhomenetworking, which is (I think) a bit out of date these days, but does go through this stuff in detail.

In particular, SSH port: don't regard moving the port as an adequate security measure by itself (well, perhaps unless you can block scanning, which may be easy enough, but it isn't really guaranteed to keep working if people improve scanning algoritms, so may be best not to rely on).

If people can port scan you, moving the port is only worth an extra 20 seconds worth of security, which is essentially nothing; it will keep your log files cleaner though, and that might be worth having. There is a page on samhain which goes in to the options. The simplest is probably:

disallow ssh v1 (everyone should be doing that by default)
disallow root log in via ssh
use passwordless, provided that you have a safe and secure way of distributing the keys
(moving the port will keep the log files 'cleaner' and that may have a real value in making attacks stand out)

Quote:

3) What the hell is conntrack?

It is an add-on (module) for iptables to allow more sophisticated connection tracking things.

Quote:

This is for a production server which runs a website (2 websites)...

Would you describe it as 'local' or 'remote'? If remote, there are some mistakes that you really don't want to make, because you'll have to travel to put them right.

Both Apache and Nginx? That seems a bit excessive, but there may be reasons connected with your two different websites that makes this essential.

Quote:

...plesk...

All of these panel things bring certain considerations with them (and plesk may one of the better ones, but still). They are buggy; going on history, and assuming that the past is the same as the future, every so often a bug is discovered that renders your site vulnerable. When that does happen, the important thing is to be able to get the patched version in place as fast as is possible to limit the vulnerability.

I would have expected some mention of a CMS-like thing (eg, Drupal, Wordpress, etc) or something similar. I hope you aren't running a home-brewed equivalent, because those are usually vulnerable in mysterious and unknown ways.

something else you may be able to consider is to limit traffic to and from potentially vulnerable services to traffic that is local to some more trustworthy net range (eg, inside your organisation, whatever that comprises). If, eg, ssh, plesk can only communicate with what are machines local to your administrative area, that reduces the worries a bit.

A more general question is whether it is sensible to have all of this on one machine; it might be ok from a throughput point of view (or, it might not, depends on whether the websites are busy and whether they stay that way) but you might be creating something that is difficult to administer from a security and availability point of view. Imagine, for example, a new version of a database (again two!) is released and this version corrects a potential security issue. How do you ensure that everything works before installing it? Does it (potentially) break both your websites? Is that a risk you can take (if, for example, it was an internal organisation website, it might be tolerable, in some other cases it might not)?

I still didn't see anything about what DNS does.

Quote:

6) I saw many versions of my last rules for outgoing traffic (I want to allow all outgoing traffic), its the mine correct?

I think, no. The rule

Code:

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

doesn't allow any new traffic. Now, it may be that the traffic that you are concerned about is the website traffic, and it actually starts as 'related' (related to some existing connection that someone has already made to a webserver), but I would think not all of it.

One way to proceed would be to log packets that you are dropping and have a look at the logfile to see what you are dropping and whether you really wanted to drop those packets. That's a bit 'trial and error' though, and you are probably better trying to 'design it right' and then just look at logs for conformation.