Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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.
# flush tables and create new chain for traffic filtering
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,
Last edited by r3sistance; 02-13-2010 at 01:45 AM.
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.
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.
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.
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:
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 -t nat
$IPT -F -t mangle
$IPT -F -t raw
$IPT -X -t nat
$IPT -X -t mangle
$IPT -X -t raw
$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.