LinuxQuestions.org - iptables script

- Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)

- - iptables script (https://www.linuxquestions.org/questions/linux-security-4/iptables-script-788840/)

Hey all,

I have been working on a small script that flushes iptables and replaces it with a brand new rule set, what I want to check is that all the rules I am setting are actually secure.

Code:

# flush tables and create new chain for traffic filtering

iptables -F

iptables -N allowed_traffic

iptables -A INPUT -j allowed_traffic

iptables -A OUTPUT -j allowed_traffic



# open used ports

iptables -A allowed_traffic -p tcp --dport 80 -m state --state new -j ACCEPT

iptables -A allowed_traffic -p tcp --dport 22 -m state --state new -j ACCEPT

iptables -A allowed_traffic -p icmp --icmp-type 8 -j ACCEPT

iptables -A allowed_traffic -p icmp --icmp-type 0 -j ACCEPT

iptables -A allowed_traffic -p tcp --dport 25 -m state --state new -j ACCEPT

iptables -A allowed_traffic -p tcp --dport 110 -m state --state new -j ACCEPT

iptables -A allowed_traffic -p tcp --dport 143 -m state --state new -j ACCEPT

iptables -A allowed_traffic -p tcp --dport 465 -m state --state new -j ACCEPT

iptables -A allowed_traffic -p tcp --dport 995 -m state --state new -j ACCEPT

iptables -A allowed_traffic -p tcp --dport 993 -m state --state new -j ACCEPT

iptables -I allowed_traffic -m state --state RELATED,ESTABLISHED -j ACCEPT

iptables -A allowed_traffic -p all -j REJECT



# Create chain for ssh attacks

iptables -N SSH_CHECK



# ssh rules

iptables -I INPUT -p tcp --dport 22 -m state --state NEW -j SSH_CHECK

iptables -A SSH_CHECK -m recent --set --name SSH

iptables -A SSH_CHECK -m recent --update --seconds 300 --hitcount 5 --name SSH -j DROP



#disable forwardings and save

iptables -A FORWARD -p all -j REJECT

service iptables save



# alternative save method "iptables-save > /etc/sysconfig/iptables"

At the moment this still uses port 22 for SSH but I am planning to change that later on. What I want to know is that everything this is doing seems sane and safe. This is a Web and Mail server for reference.

Thanks in Advance,
R3sistance.

I always thought that the first rule is to drop everything, then open the ports you require.
Otherwise, your rules aren't really doing anything as all ports are open by default.

e.g. http://www.debiantutorials.net/loadi...es-on-startup/

iptables -P INPUT DROP
iptables -P FORWARD DROP

Make sure you do specify some open ports later in the tables though, or you will be locked out !

regards

Alan

Thanks for the advice :),

iptables -A allowed_traffic -p all -j REJECT

will reject anything that does have an associated rule and is similar to the default way RHEL/CentOS handle iptables.

I see what you're saying, but that is at the end of your rule set. It should be at the beginning. You should go from most restrictive > least restrictive in the order they are applied.

regards
Alan

Hi, The Policy is the last thing that is checked when a packet does not match anything, it would come later then a rule that blocks all left over traffic, even if it is applied priorly to the rules. As far as I am aware there is no way anybody can create a type of packet that isn't already dealt with.

Quote:

Originally Posted by smoker (Post 3862428)

I always thought that the first rule is to drop everything, then open the ports you require.....

iptables -P INPUT DROP
iptables -P FORWARD DROP

This is to set a policy for the chain in question. A policy defines what happens, if the packet does not match any of the explicit rules and it falls through to the end.

In that sense, given that all of the explicit rules are tested before the policy comes into effect, the policy is the thing that comes into action last, even though it is the first thing that you specify.

So, it is correct that the policy is the first thing that you specify when setting up the rules for the chain, it is executed, if at all, after everything else in the chain.

To look at things the other way around, if the policy was the first thing was tested, and the policy was set to drop or reject, all of the packets in that chain would be dropped (or rejected). That would be rather secure, but only in the same way that pulling out the network cable would be very secure.

Why are you jumping to the same chain from both INPUT and OUTPUT?

Why aren't you making rules specially-tailored for either INPUT or OUTPUT instead?

The reason for that is that the only type of traffic going outwards from the server should be exactly the same as the traffic going into the server.

Quote:

Originally Posted by r3sistance (Post 3863098)

The reason for that is that the only type of traffic going outwards from the server should be exactly the same as the traffic going into the server.

I'm not sure I follow. Let's take the port 80/TCP rule, for example. Since this box provides Web service, you need to allow inbound connections to port 80/TCP - no problem. Your current setup, however, takes this a step further by also allowing users/applications on this box to start outbound connections to port 80/TCP on other boxes. Unless this is your deliberate intention, then you've got a security issue right there which you must address.

Generally speaking, on servers the amount of rules sending packets in state NEW to ACCEPT on the OUTPUT chain should be much, much less than the INPUT chain. In fact, in many cases, the number of packets in state NEW traversing the server's OUTPUT chain should be equal to zero (that is, there shouldn't be any outbound connections allowed at all). I'm mentioning this because it seems to me like you might believe that every one of those INPUT rules requires a corresponding OUTPUT rule, which isn't the case. An OUTPUT rule to deal with packets in states RELATED and ESTABLISHED should take care of most of your needs, with only a handful of rules required for allowing certain outbound connections - and only if necessary.

It's deliberate for 80 and 22 as this will be running VNC-server via SSH tunnel. However I will take that into account.

Quote:

Originally Posted by r3sistance (Post 3863278)

It's deliberate for 80 and 22 as this will be running VNC-server via SSH tunnel. However I will take that into account.

If that's the only outbound connections you need (Are you sure you don't need 53/UDP to your DNS provider's IP address?) then I'd suggest something like this:

Code:

#!/bin/sh



IPT="/sbin/iptables"



echo "0" > /proc/sys/net/ipv4/ip_forward



$IPT -P INPUT DROP

$IPT -P FORWARD DROP

$IPT -P OUTPUT DROP



$IPT -t nat -P PREROUTING ACCEPT

$IPT -t nat -P POSTROUTING ACCEPT

$IPT -t nat -P OUTPUT ACCEPT



$IPT -t mangle -P PREROUTING ACCEPT

$IPT -t mangle -P INPUT ACCEPT

$IPT -t mangle -P FORWARD ACCEPT

$IPT -t mangle -P OUTPUT ACCEPT

$IPT -t mangle -P POSTROUTING ACCEPT



$IPT -t raw -P PREROUTING ACCEPT

$IPT -t raw -P OUTPUT ACCEPT



$IPT -F

$IPT -F -t nat

$IPT -F -t mangle

$IPT -F -t raw



$IPT -X

$IPT -X -t nat

$IPT -X -t mangle

$IPT -X -t raw



$IPT -Z

$IPT -Z -t nat

$IPT -Z -t mangle

$IPT -Z -t raw



$IPT -N SSH_CHECK

$IPT -A SSH_CHECK -m recent --set --name SSH

$IPT -A SSH_CHECK -m recent --update --seconds 300 --hitcount 5 --name SSH -j DROP



$IPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

$IPT -A INPUT -i lo -j ACCEPT

$IPT -A INPUT -p TCP --dport 22 -m state --state NEW -j SSH_CHECK

$IPT -A INPUT -p TCP -m multiport --dports 22,25,80,110,143,465,993,995 -m state --state NEW -j ACCEPT

$IPT -A INPUT -p ICMP --icmp-type 8 ! --fragment -m state --state NEW -j ACCEPT



$IPT -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

$IPT -A OUTPUT -o lo -j ACCEPT

$IPT -A OUTPUT -p TCP -m multiport --dports 22,80 -m state --state NEW -j ACCEPT

BTW, if you know the user accounts which will be starting the outbound connections, then I would highly recommend making the rules specific to those users. This way if another non-root user account gets cracked, the firewall will still prevent your box from being used to attack other boxes.