Sachin’s Weblog

August 30, 2007

Linux firewall – iptables filtering

Filed under: General, IPtables, Linux, Security, firewall — sachin @ 12:21 pm

So after few basic steps about server security, let’s come to the real action part of the story, IPTABLES.

Iptables is a generic table structure that defines rules and commands as part of the netfilter framework that facilitates Network Address Translation (NAT), packet filtering, and packet mangling in the Linux 2.4 and later operating systems.

NAT is the process of converting an Internet Protocol address (IP address) into another IP address. Packet filtering is the process of passing or blocking packets at a network interface based on source and destination addresses, ports, or protocols. Packet mangling is the ability to alter or modify packets before and/or after routing.

Iptables and netfilter are the successor to ipchains and ipfwadm in earlier versions of Linux. Netfilter and iptables are often combined into the single expression netfilter/iptables, which refers to the Linux 2.4 and later subsystems for NAT, firewalling, and advanced packet processing.

The Internet Protocol (IP) is a data oriented protocol that allows multiple hosts to talk to each other across network connections. Data in an IP network are sent in blocks referred to as packets or datagrams. They typically have a source host, destination host, and source and destination ports associated with the communication.

These are all the terms, we going to use in this section. Assuming you already have basic knowledge of networking and IP Address, we are now going to discuss IPTABLES firewall and security. We will divide, iptables into

Filtering : Iptables is an IP filter, and if you don’t fully understand this, you will get serious problems when designing your firewalls in the future. An IP filter operates mainly in layer 2, of the TCP/IP reference stack. The most common terms used in IP filtering are as follows:

  • Drop/Deny – When a packet is dropped or denied, it is simply deleted, and no reply to tell the host it was dropped, nor is the receiving host of the packet notified in any way. The packet simply disappears.
  • Reject – This is basically the same as a drop or deny target or policy, except that we also send a reply to the host sending the packet that was dropped. The reply may be specified, or automatically calculated to some value.
  • State – A specific state of a packet in comparison to a whole stream of packets. For example, if the packet is the first that the firewall sees or knows about, it is considered new (the SYN packet in a TCP connection), or if it is part of an already established connection that the firewall knows about, it is considered to be established. States are known through the connection tracking system, which keeps track of all the sessions.
  • Chain – A chain contains a ruleset of rules that are applied on packets that traverses the chain. Each chain has a specific purpose (e.g., which table it is connected to, which specifies what this chain is able to do), as well as a specific application area (e.g., only forwarded packets, or only packets destined for this host).
  • Table – Each table has a specific purpose, and in iptables there are 4 tables. The raw, nat, mangle and filter tables. For example, the filter table is specifically designed to filter packets, while the nat table is specifically designed to NAT (Network Address Translation) packets.
  • Match – This word can have two different meanings when it comes to IP filtering. The first meaning would be a single match that tells a rule that this header must contain this and this information. For example, the –source match tells us that the source address must be a specific network range or host address. The second meaning is if a whole rule is a match. If the packet matches the whole rule, the jump or target instructions will be carried out (e.g., the packet will be dropped.)
  • Target – There is generally a target set for each rule in a ruleset. If the rule has matched fully, the target specification tells us what to do with the packet. For example, if we should drop or accept it, or NAT it, etc. There is also something called a jump specification.
  • Rule – A rule is a set of a match or several matches together with a single target in most implementations of IP filters, including the iptables implementation. There are some implementations which let you use several targets/actions per rule.
  • Ruleset – A ruleset is the complete set of rules that are put into a whole IP filter implementation. In the case of iptables, this includes all of the rules set in the filter, nat, raw and mangle tables, and in all of the subsequent chains. Most of the time, they are written down in a configuration file of some sort.
  • Jump – The jump instruction is closely related to a target. A jump instruction is written exactly the same as a target in iptables, with the exception that instead of writing a target name, you write the name of another chain. If the rule matches, the packet will hence be sent to this second chain and be processed as usual in that chain.
  • Connection tracking – A firewall which implements connection tracking is able to track connections/streams simply put. The ability to do so is often done at the impact of lots of processor and memory usage. This is unfortunately true in iptables as well, but much work has been done to work on this. However, the good side is that the firewall will be much more secure with connection tracking properly used by the implementer of the firewall policies.
  • Accept – To accept a packet and to let it through the firewall rules. This is the opposite of the drop or deny targets, as well as the reject target.
  • Policy – There are two kinds of policies that we speak about most of the time when implementing a firewall. First we have the chain policies, which tells the firewall implementation the default behaviour to take on a packet if there was no rule that matched it. The second type of policy is the security policy, security policies are very good documents to have thought through properly and to study properly before starting to actually implement the firewall.

Applying IP Tables Firewall : There are two basic policies that we normally use. Either we drop everything except that which we specify, or we accept everything except that which we specifically drop. Most of the time, we are mostly interested in the drop policy, and then accepting everything that we want to allow specifically. This means that the firewall is more secure per default, but it may also mean that you will have much more work in front of you to simply get the firewall to operate properly.

So Let’s do it now, First we will going to block everything coming to the server and then will allow only specific connection with filtration and with out any filter. Let’s Assume we have a web server which uses port 80 and 443, and you have to administrate it remotely using ssh. Here is what you can do :

  1. Clear all Built-in Chains
    iptables -F INPUT
    iptables -F OUTPUT
    iptables -F FORWARD
  2. Block all ports for input traffic
    iptables -P INPUT DROP
  3. Accept Output Traffic
    iptables -P OUTPUT DROP
  4. Block Forwarding
    iptables -P FORWARD DROP
  5. Allow all traffic to loop back interface
    iptbales -A INPUT -i lo -j ACCEPT
    iptbales -A INPUT -o lo -j ACCEPT
  6. Allow Only incoming connection related to Outgoing connection
    iptables -A INPUT -m state – -state ESTABLISHED, RELATED -j ACCEPT

That’s it, your server (4.5.6.7) is isolated now from rest of the world. Now to open few required port on the server (port 80 and port 443) to rest of the world we need to add few more rules.

  • iptables -I INPUT -p tcp -s 0/0 -d 4.5.6.7 – -sport 513:65535 – -dport 80 -j ACCEPT
  • iptables -I INPUT -p tcp – -dport 443 -j ACCEPT

both of the rules will do the same thing, but in different ways which we will discuss later. Now we going to open port 22 ( ssh port) for specific ip(1.2.3.4 or mac address xx:xx:xx:xx:xx:xx)/ips(1.2.3.0/24) for your server 4.5.6.7.

  • iptables -I INPUT -p tcp -s 1.2.3.4 -d 4.5.6.7 – -sport 513:65535 – -dport 22 -j ACCEPT
  • iptables -I INPUT -p tcp -m mac – -mac-source XX:XX:XX:XX:XX:XX – -sport 513:65535 – -dport 22 -j ACCEPT
  • iptables -I INPUT -p tcp -s 1.2.3.0/24 -d 4.5.6.7 – -sport 513:65535 – -dport 22 -m state – -state NEW, ESTABLISHED -j ACCEPT
  • Disable HTTP DOS/DDOS attack
    iptables -I INPUT -p tcp -s 0/0 -d server ip –dport 80 -i eth0 -m state –state NEW -m recent –set
    iptables -I INPUT -p tcp -s 0/0 -d server ip –dport 80 -i eth0 -m state –state NEW -m recent –update –second 60 –hitcount 4 -j DROPThe above two rules will limit incoming connections to port 80 to no more
    than 3 attemps in a minute – an more than that will be dropped.
    The –state flag takes a comma seperated list of connection states as an argument,
    by using “–state NEW” as we did we make sure that only new connections
    are managed by the module.
    The –set parameter in the first line will make sure that the IP address ofthe host which initiated the connection will be added to the “recent list”, where it can be tested and used again in the future i.e. in our second rule.
    The –update flag tests whether the IP address is in the list of recent onnections, in our case each new connection on port 80 will be in the list because we used the –set flag to add it in the preceeding rule.
    Once that’s done the –seconds flag is used to make sure that the IP address is only going to match if the last connection was within the timeframe given.
    The –hitcount flag works in a similar way – matching only if the given count of connection attempts is greater than or equal to the number given.

Basic idea here was to understand iptables fundamentals and quick security rules. Now we can easily open/close/filter and port of the server, default action here is to restrict everything unless specified.

We will talk more about filtering and iptables, remember security is the major task for any system administrator, so more you can learn better will be the chance for your survival.

No Comments Yet »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a comment

You must be logged in to post a comment.

Blog at WordPress.com.