Beefing up IPTables

Support for security such as Firewalls and securing linux
Post Reply
bridgeway04
Posts: 2
Joined: 2012/05/15 16:56:24
Contact:

Beefing up IPTables

Post by bridgeway04 » 2012/05/15 17:19:32

Let me start by saying I am new to CentOS!

I just got all my websites migrated to my new CentOS 6 server and now that the dust has setteled it's time to secure it! I reviewed the Beefing up IPTables "how to" and came up with the ruleset listed below. Please give me your comments and sugestions!

Also does this line (-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT) accept traffic on the usual ports like 80, 53, 443, 25, 21, and 123 or do you have add the rules?

The server main job is to host our numerious corporate websites and acts as our main mailserver, nothing special. I just want to keep the bad guys out and reduce spam!

Thanks

Brad


#Drop anything we aren't explicitly allowing. All outbound traffic is okay
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type echo-reply -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
# Accept Pings
-A RH-Firewall-1-INPUT -p icmp --icmp-type echo-request -j ACCEPT
# Log anything on eth0 claiming it's from a local or non-routable network
# If you're using one of these local networks, remove it from the list below
-A INPUT -i eth0 -s 10.0.0.0/8 -j LOG --log-prefix "IP DROP SPOOF A: "
-A INPUT -i eth0 -s 172.16.0.0/12 -j LOG --log-prefix "IP DROP SPOOF B: "
-A INPUT -i eth0 -s 192.168.0.0/16 -j LOG --log-prefix "IP DROP SPOOF C: "
-A INPUT -i eth0 -s 224.0.0.0/4 -j LOG --log-prefix "IP DROP MULTICAST D: "
-A INPUT -i eth0 -s 240.0.0.0/5 -j LOG --log-prefix "IP DROP SPOOF E: "
-A INPUT -i eth0 -s 169.254.0.0/16 -j LOG --log-prefix "IP DROP MULTICAST "
-A INPUT -i eth0 -s 0.0.0.0/8 -j LOG --log-prefix "IP DROP "
-A INPUT -i eth0 -s 240.0.0.0/4 -j LOG --log-prefix "IP DROP "
-A INPUT -i eth0 -s 255.255.255.255/32 -j LOG --log-prefix "IP DROP "
-A INPUT -i eth0 -s 168.254.0.0/16 -j LOG --log-prefix "IP DROP "
-A INPUT -i eth0 -s 248.0.0.0/5 -j LOG --log-prefix "IP DROP "
# Accept any established connections
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Accept My SSH traffic. Restrict this to known ips if possible.
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 4488 -j ACCEPT
#Log and drop everything else
-A RH-Firewall-1-INPUT -j LOG
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

User avatar
TrevorH
Site Admin
Posts: 33219
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Beefing up IPTables

Post by TrevorH » 2012/05/15 20:06:16

[quote]
Also does this line (-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT) accept traffic on the usual ports like 80, 53, 443, 25, 21, and 123 or do you have add the rules?
[/quote]

This rule says that if a connection is already established by one of the other rules or is related to one then allow it. Those other rules need to be using -m state --state NEW so that it uses connection tracking on them.

You have an abundance of LOG rules there and I'd remove those as they'll only clog up your log files. As it is, you're logging everything twice, once with various log-prefixes and once more just before you reject the packets. You can remove the final rule which rejects everything as you have changed the INPUT policy to DROP. You have only one current rule that accepts traffic and it is this

[code]
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 4488 -j ACCEPT
[/code]

You'll need to duplicate this one and amend the port specification for any other ports you want to open. Some of those, like the one for port 53 will probably need to use udp and not tcp (most DNS traffic is UDP although it can use TCP as well for things like zone transfers).

bridgeway04
Posts: 2
Joined: 2012/05/15 16:56:24
Contact:

Re: Beefing up IPTables

Post by bridgeway04 » 2012/05/15 21:15:00

SO for a web server it would look somthing like this:

#Drop anything we aren't explicitly allowing. All outbound traffic is okay
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type echo-reply -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
# Accept Pings
-A RH-Firewall-1-INPUT -p icmp --icmp-type echo-request -j ACCEPT
# Log anything on eth0 claiming it's from a local or non-routable network
# If you're using one of these local networks, remove it from the list below
-A INPUT -i eth0 -s 10.0.0.0/8 -j LOG --log-prefix "IP DROP SPOOF A: "
-A INPUT -i eth0 -s 172.16.0.0/12 -j LOG --log-prefix "IP DROP SPOOF B: "
-A INPUT -i eth0 -s 192.168.0.0/16 -j LOG --log-prefix "IP DROP SPOOF C: "
-A INPUT -i eth0 -s 224.0.0.0/4 -j LOG --log-prefix "IP DROP MULTICAST D: "
-A INPUT -i eth0 -s 240.0.0.0/5 -j LOG --log-prefix "IP DROP SPOOF E: "
-A INPUT -i eth0 -s 169.254.0.0/16 -j LOG --log-prefix "IP DROP MULTICAST "
-A INPUT -i eth0 -s 0.0.0.0/8 -j LOG --log-prefix "IP DROP "
-A INPUT -i eth0 -s 240.0.0.0/4 -j LOG --log-prefix "IP DROP "
-A INPUT -i eth0 -s 255.255.255.255/32 -j LOG --log-prefix "IP DROP "
-A INPUT -i eth0 -s 168.254.0.0/16 -j LOG --log-prefix "IP DROP "
-A INPUT -i eth0 -s 248.0.0.0/5 -j LOG --log-prefix "IP DROP "
# Accept any established connections
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# To open port 80 (Http server)
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 80 -j ACCEPT
# To open port 53 (DNS Server)
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -m udp -p tcp --dport 53 -j ACCEPT
To open port 443 (Https server)
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 443 -j ACCEPT
To open port 25 (smtp server)
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 25 -j ACCEPT
# Allow Legitimate NTP Clients to Access the Server
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p udp --dport 123 -j ACCEPT
#Open FTP Port 21
-A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 21 -j ACCEPT
# Accept My SSH traffic. Restrict this to known ips if possible.
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 4488 -j ACCEPT
#Log and drop everything else
-A RH-Firewall-1-INPUT -j LOG
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

Did I miss anything and how do I get rid of the double logging?

User avatar
TrevorH
Site Admin
Posts: 33219
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: Beefing up IPTables

Post by TrevorH » 2012/05/16 00:04:43

You're missing -m state --state NEW on all of your new ACCEPT rules.

If you're accepting connections on port 21 for ftp then you probably want to edit /etc/sysconfig/iptables-config and add ip_conntrack_ftp to the list of modules to automatically load.

[code]
-A RH-Firewall-1-INPUT -m udp -p tcp --dport 53 -j ACCEPT
[/code]

is wrong, it wants -p udp instead.

This last rule

[code]
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
[/code]

either means you don't also need a policy of DROP on the INPUT chain or it is redundant. It doesn't hurt to have it unless you're one of those that believe that not responding to packets you would otherwise deny is a good thing.

You second to last rule just does a -j LOG on anything that hasn't been accepted. You then have a bunch of rules under the comment "# Log anything on eth0 claiming it's from a local or non-routable network" that also get logged but you have no DROP or REJECT rule for the same sources so packets from them will drop through those rules, having logged to syslog, go through your other access rules and either be accepted or end up falling off the end of the chain and being dropped/rejected. Also, judging by your accept rule for 192.168.1.0/24, you [u]are[/u] using some of those networks that are in that LOG rule batch.

Edit: I mention ip_conntrack_ftp above based on your rule names of RH-Firewall-1-INPUT which is a CentOS 5 rule name. In CentOS 6 which you say you are using, Redhat replaced that rule and use the default INPUT chain for everything. If you're running CentOS 5 then you're in the wrong forum and if you're running CentOS 6 then the module name is nf_conntrack_ftp not ip_conntrack_ftp.

Post Reply