#### Host Packet-Filtering: Netfilter/IPtables ####
** Host security through an application firewall is one of the main pillars of security when dealing with linux. Defending against unwanted incoming traffic, as well as outgoing traffic is hugely important, especially if your gateway firewall happens to get breached. Also the logging of questionable traffic in conjunction with the above can give a window into exactly what's happening in many of these scenarios.
** Setting up a host-based firewall [ime] lies on two main principles - vigilance and minimalism. Managed by exception, while being minimalistic in nature. A common principle that I've learned with host-based firewalling is that inbound/outbound access should be the exception, not the rule. You first create a full wall [absolutely no inbound/outbound traffic], then from there you carefully remove the pieces of that wall until the inbound/outbound functionality you want's achieved.
** The above applies to traffic within the network in a couple ways - what that singular host expects incoming and what it expects outgoing within your local network, and what incoming traffic it's expected to recieve from outside the local network [i.e the gateway/internet in this case].
** In this tutorial I'm going to be going over the packet-filtering framework 'netfilter' along with it's front-end interface 'iptables'. Netfilter is linux's long-standing kernel-level packet inspection framework. It operates entirely at the kernel level, which in ways allows it to bypass certain restrictions that userland firewall applications can have. I will not be going over netfilter/iptables network translation or port translation abilities, neither will I be going over it's packet queueing or packet mangling abilities. I'll be solely focused on showing how to construct simple chains and rules within the 'filter' table of iptables.
** The filter table is the table within iptables that does traffic/packet inspection. And like i'd mentioned earlier i won't be going over the remaining tables, as they're out've the scope of this tutorial.
** I will not be covering ip addressing, subnetting or anything related to the structure/operation of tcp/ip traffic. I assume there's a base knowledge when reading this. I will not be talking about network security as a whole neither, that's also out've the scope of this tutorial. This is strictly host-level packet/firewall security.
** The netfilter framework operates by referencing a set of tables. Within these tables are 'chains', then within those 'chains' are 'rules' pertaining to each chain. Each chain within the filter table has a collection of rules. Each chain will have a set of rules pertaining strictly to the function of that specific chain. For example within the filter table, the 'INPUT' chain will handle incoming traffic/packets, the 'OUTPUT' chain will hold rules pertaining to traffic/packets leaving your host, and the 'FORWARD' chain will handle packets being forwarded through your host [though it's unlikely we'll be using the forward chain when setting up a host based firewall].
** Traffic/packets running through the particular chains are compared aginst their respective rules, and from the defined rules a target/action will be taken. When a packet meets a rule, if the criteria for that rule's met, then the desired target/action will be taken. Some of these actions, among several, can be to:
- drop the packet
- accept the packet
- reject the packet
- send the packet to another target/set of rules to be processed further
** Each iptables rule depends on a set of parameters for it to work it's intended usage per the packet. Some of these criteria are:
-s [source ip]
-d [destination ip]
--sport [source port]
--dport [destination port]
** The above 4 parameters can define what's known as a 'socket', a communication endpoint to allow two hosts to communicate [though a socket isn't necessarily always defined this way]. All 4 of these parameters have to be present for the connection to
be started.
** The above 4 parameters are not the only one's iptables uses. There's others such as:
-4 [ipv4]
-6 [ipv6]
-p [protocol]
-i [interface for incoming packets]
-o [interface for outgoing packets]
** Typically on a tcp/ip network there will be 3 communication protocols in use when viewing traffic:
- icmp
- tcp
- udp
** As I'd mentioned earlier, rules are broken down within the filter table in what are
called 'chains', the three chains being 'INPUT', 'OUTPUT' and 'FORWARD'. These three
chains specify the paths that packets can take from/to/through a host. When the netfilter framework comes into contact with a packet, first thing it does is reference one of these three chains.
** Within the filter table of iptables there are also 'policies'. There's a policy defined to each chain. A 'policy' is the default action that that particular chain is
to take if the particular packet coming through that chain doesn't succeed against any of the rules contained within that chain. Same as above, the default policies for a chain can be either 'ACCEPT', 'REJECT', or 'DROP'.
** I'll go over these policies/actions briefly:
-DROP: This discards/drops the packet entirely. To anyone trying to connect, it would
appear like there's no service/system whatsoever.
-REJECT: This discards the packet, then sends an icmp packet back to the source sender stating the rejections occured, commonly a 'connection refused' message is received.
-ACCEPT: This accepts the packet and allows it to pass through the firewall.
### Adding Rules ###
** Each chain's default policy should be set to 'DROP' from the start. This means that before adding any rules to any of the chains that the default action for each chain will be to DROP all packets coming in, going out, and any forwarded packets through the host. Doing this though you will not have any connectivity whatsoever. This was what I'd meant earlier by building the wall, then taking out each piece of that wall individually until you've achieved what youre wanting for your host.
** To add the default policy/action of 'DROP' to each chain, we're going to use the 'iptables' then the '-P' option, followed by the specific chain, followed by the default policy/action:
sudo iptables -P INPUT DROP
sudo iptables -P OUTPUT DROP
sudo iptables -P FORWARD DROP
** When adding default policies/actions through iptables, these are taken into effect immediately. These rules are automatically placed into memory, though once the system's rebooted, these changes are lost. There's a few methods to allow persistence of the rules, I'll cover the primary one a little later.
** For the very first rule we'll write we're going to start with the 'INPUT' chain, we wan't the loopback interface to be able to communicate with itself within the context of 'incoming' packets. This is necessary for the host to function correctly. We're going to use the option '-A' which stands for 'append'. Using the -A option appends the given rule to the end of that particular chain's rules. In this case we have no rules yet within the INPUT chain, so when appending this rule, it'll be the first rule. We use the '-i' option to specify the 'incoming interface' followed by the interface name, which is 'lo'. Then following this we use the '-j' option which stands for 'jump'. All '-j' essentially means is that if all the previous criteria for this rule is met, then then rule will 'jump' to it's specific action:
sudo iptables -A INPUT -i lo -j ACCEPT
** We also want to take care of outbound traffic for the lo interface, so that it's in line/functional with the INPUT chain rule for lo. So we're going to add this outbound rule to the 'OUTPUT' chain using the '-o' option which specifies the 'outbound interface', which is lo:
sudo iptables -A OUTPUT -o lo -j ACCEPT
** The other option to add rules within iptables is '-I', which stands for 'insert', then following the insert option you specify the particular chain, followed by a numerical value in order to tell insert where to place the rule. Controlling to what line you add your rules is important, as netfilter reads the rules within a given chain from top to bottom in succession. The sequence of rules is important. A simplified example: say you had a rule at the beginning of the INPUT chain that allowed all inbound traffic into your host, then you had a rule following that one to restrict inbound traffic into your host - the first rule would be read, allowing the inbound traffic, then the following rule that restricts traffic would be negated.
An easy example of what I'd just mentioned would be something like:
sudo iptables -I INPUT 1 -i eth0 -p tcp -j ACCEPT
sudo iptables -I INPUT 2 -i eth0 -p tcp --dport 22 -j DROP
** The first rule within this example says that for all inbound tcp traffic to the inbound interface 'eth0' would be accepted. The next rule states that the inbound tcp traffic on the inbound interface 'eth0' for the destination port 'ssh' would be dropped. If the criteria for the first rule is met, then the following rule would be negated. So in this case the traffic for the ssh port would 'not' be dropped, due to the first rule being met allowing all inbound tcp traffic. This example shows why the sequence of the rules is important.
!! Make sure your rules per the chain make logical sense. !!
** One more example with inserting rules within a chain:
sudo iptables -L INPUT -n --line-numbers
Chain INPUT (policy DROP)
num target prot opt source destination
1 ACCEPT tcp -- 0.0.0.0/0 192.168.0.1 tcptcpdpt:80
2 ACCEPT tcp -- 0.0.0.0/0 192.168.0.1 dpt:443
** The above example is a display of the INPUT chain with it's rules and given line numbers. Now say for whatever reason, you want to use the insert option to put a rule between rule 1 and rule 2, when going to write a rule to put in between these two rules you would do:
sudo iptables -I INPUT 2 whateverparametersinthisectionhere -j ACCEPT
** The above rule says I'm going to insert this new rule at rule line 2, which when
entered knocks the original rule 2 down a spot, with this new rule going in rule 2's original spot, so now it would look like:
sudo iptables -L INPUT -n --line-numbers
Chain INPUT (policy DROP)
num target prot opt source destination
1 ACCEPT tcp -- 0.0.0.0/0 192.168.0.1 tcptcpdpt:80
2 ACCEPT whateverparametersyouhadsethere
3 ACCEPT tcp -- 0.0.0.0/0 192.168.0.1 dpt:443
** To list all the chains and their rules:
sudo iptables -L
** To list all the chains with their rules and given line numbers:
sudo iptables -L --line-numbers
** To delete a rule, you use the '-D' option followed by the particular chain, then the full set of rule parameters from that rule:
sudo iptables -D INPUT -i eth0 -p tcp --dport 443 -d 192.168.0.16 -j ACCEPT
** An easier/better way to delete specific rules is just to specify the line number of
the rule you're wanting to delete by specifying the '-D' option, the specific chain, then the line number from that chain you want to delete:
sudo iptables -D INPUT 2
** To flush all the rules from a particular chain, specify the '-F' option followed by the chain:
sudo iptables -F INPUT
** To flush all the rules from every chain, just omit the chain:
sudo iptables -F
** So far we've set our default policy of 'DROP' for each chain, then we began by slowly opening up host communication/connectivity by allowing inbound and outbound traffic to pass through the 'lo' loopback interface.
** Next we're going to want the host to be able to make requests to the publicnet/internet, so this will require us to set a few rules for inbound/outbound traffic. There's a great module for this within netfilter/iptables framework, it's called 'state'. The state module allows 'stateful' packet inspection feature. Though netfilter/iptables is inherently s stateful firewall.
** The state module examines each individual packet relative to the stream of packets, whether they be inbound, outbound or forwarded. From here the state module will determine if it's a part of a newly initiated connection, an existing connection, or a related connection. The tags used for this within a rule are 'NEW', 'ESTABLISHED', or 'RELATED'.
-NEW: This means a fresh connection, whether it be specified for inbound or outbound traffic.
-ESTABLISHED: A preexisting connection that's in the process of sending packets back and forth. You need to specify this state in a rule if you want to maintain a connection between two endpoints.
-RELATED: This state's used when an ESTABLISHED connection is formed, though subsequently from this initial connection spawns another connection, seperate, though related.
** You can view the actively tracked connections from the kernel through '/proc/net/nf_conntrack'.
** The state module/conntrack is great for negating packets that aren't directly part
of any of your preexisting connections. Running the state module is key when using a host to connect to the internetand a have a modicum of security behind it.
** The more closely you specify the traffic entering/exiting your host using as many parameters in a rule as possible [port, protocol, ip-range/mask, source, destination, inbound/outbound interface, state] the more you reduce the risk potential of malicious traffic.
### The Conntrack/State Module ###
** Now we'll use the state module within an inbound and outbound rule to allow connectivity to/from the internet:
** First we'll specify a rule for the OUTPUT chain to allow connections going out, with this rule we're going to append it so that it's after our inital loopback rule. WE use the '-m' flag for module, followed by the module we want 'state' then to call state/conntrack officially in this instance we run the '--state' option followed by the specific state/s we want to use, in this case we want to accept newly established connections going outbound:
sudo iptables -A OUTPUT -m state --state NEW,ESTABLISHED -j ACCEPT
** Now we have taken care of the outbound connection, we also want an inbound connection back to our host so that there's a fully established connection between us and the internet. This inbound rule follows similar suit to the outbound one we'd just made, aside from changing the state parameter now to ESTABLISHED. All this means is that netfilter/conntrack is going to look for a pre-established connection that we'd already made outbound, and if netfilter/conntrack sees this pre-established connection through using our ESTABLISHED parameter, then it will allow it:
sudo iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
** There's no reason to specify the protocol as tcp, nor is there any reason to have increased granularity/parameters [i.e port numbers, etc] for these two inbound/outbound rules. Netfilter/conntrack takes care of recognizing this on a moment to moment basis.
### Writing Host-Based DNS Rules ###
** Now that we have our inbound/outbound tcp based connections set, we still need address resolution through dns, or else our requests outbound won't resolve. For this resolution rule we have to 'insert' it prior to our outbound tcp-based rule for NEW,ESTABLISHED connections. We want the dns resolution to occur first, then once that rule's met it will move on to our already present tcp-based rule for NEW,ESTABLISHED connections:
sudo iptables -I OUTPUT 2 -p udp --sport 53 -m state --state NEW,ESTABLISHED
** Then lets allow any 'related' dns resolution packets to come back inbound to the host. This new inbound dns rule will be inserted prior to our tcp-based rule for ESTABLISHED tcp connections:
sudo iptables -I INPUT 4 -p udp --dport 53 -m state --state RELATED,ESTABLISHED
** This takes care now of our outbound/inbound internet access through tcp and our address resolution through udp.
** So currently all our rules so far are:
-P INPUT DROP
-P OUTPUT DROP
-P FORWARD DROP
-A INPUT -i lo -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -m state --state RELATED,ESTABLISHED
-A INPUT -m state --state ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p udp -m udp --sport 53 -m state --state NEW,ESTABLISHED
-A OUTPUT -m state --state NEW,ESTABLISHED -j ACCEPT
** If the criteria for each set of rules for our inbound and outbound aren't met in some way, then these chains will default to DROP [drop all packets] per the default policy set prior to these rules.
### Logging Netfilter Activity ###
** The netfilter/iptables framework also has a logging capability. Within our previous rules you notice after the jump flag '-j' there's a target/action specified, like 'DROP', 'ACCEPT', 'REJECT'. Well there's also another target/action called 'LOG'. With the LOG target you can send a particular rule or set of rules to the LOG target, where /var/log/syslog and /var/log/kern.log will pick up the traffic according to which rules thrown at the LOG target.
** For example:
sudo iptables -A INPUT -p tcp --dport 22 ! -s 192.168.0.1/24 -j LOG --log-prefix "SSH LOG"
** All this rule does is log inbound ssh connection attempts that 'arent' part of my network, logs it to /var/log/syslog, with a prefix 'SSH LOG' that's attached to the specific log entry/ies.
** There's other flags that you can add after the LOG target aside from '--log-prefix'. These are:
--log-level
--log-tcp-sequence
--log-tcp-options
--log-ip-options
** '--log-level' just specifies the log level per the particular rule, levels are 0 through 7 [emerg, alert, crit, err, warn, notice, info, debug]
** '--log-tcp-sequence' specifies the sequence numbers for a tcp transaction, sequence numbers are used within packet transmission to be able to keep track of the order of bytes/packets sent between two points in order for them to be successfully reconstructed.
** '--log-tcp-options' logs any of the various options within a tcp packet header. This option is primarily used for debug.
** '--log-ip-options' logs any of the various options within the ip packet header. Same as above in terms of being primarily used for debug.
** The LOG target is non-terminating, meaning any traffic that's passed to it, after being met, will continue on to the next rule in the chain accordingly. So 'if' you're going to use the LOG target in any of the rules, just remember that if any of your rules within a chain REJECT or DROP traffic, you'll need to put the LOG based rules before these rejection/drop rules, or else the traffic will get dropped prior to the logging.
** The netfilter/iptables default log path [as mentioned earlier] is to one of a few directories: /var/log/syslog or /var/log/kern.log. Though defaulting the logging to one of these few paths isn't the best idea as it'll be in a swath of other log entries, making it more difficult to parse just our iptables logs from all the other logging per these directories, so it's a good idea to open up /etc/rsyslog.conf and write in another path for the iptables logs to take aside from the defaults.
**** In my other tutorial on log correlation, I talked about rsyslog, facilities and whathaveyou. So if you're confused on the next steps here, reference the section of the other tutorial talking about what I'm about to mention. ****
** To be able to log to another log file in /var/log, aside from the defaults, firstly you need to create a blank log file in /var/log/. We'll just use the touch command, specify the path with the new blank log file, set the user:group to root:adm, then chmod the permissions '660' for that file [r/w perms for root, r/w perms for adm] :
sudo touch /var/log/iptables.log
sudo chown root:adm /var/log/iptables.log
sudo chmod 660 /var/log/iptables.log
** Now we'll open up /etc/rsyslog.conf, scroll to the middle section of the file where it lists the various 'facilities.priorities' per each line with their associated path to the right:
sudo nano /etc/rsyslog.conf
** scroll to the middle of thje file til you notice a section like this:
auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
#cron.* /var/log/cron.log
daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
lpr.* -/var/log/lpr.log
mail.* -/var/log/mail.log
user.* -/var/log/user.log
** Now we'll write in our 'facility.priortiy' on the left, followed by the path for that facility.priority to the right. We'll just use the kernel facility 'kern', since netfilter/iptables already is kernel based and default logs to kern.log anyhow. Then we can specify any one of the various priority levels, I'll just use :
kern.warning /var/log/iptables.log
** Now exit and save the edit for /etc/rsyslog.conf
** Since the LOG rule for ssh from earlier only logs inbound attempts from ip's 'outside' of my home network, I can't really test it as such.
** One way though is to do a quick port forwarding setup on the home router, point it to the interal host's ssh port, get the public-facing/routable ip that's assigned to the router, download something like 'juicessh' for the phone, fill in all the required fields in the juicessh app in order to connect to my router > internal host's ssh port, then have iptables log it that way, just for testing [you really shouldnt run forwarded ports on your gateway/router]. You could do it from a laptop also.
** Another rule that can be put in under the inbound chain is to catch invalid packets, in this context these are packets not associated with any currently established connections. Using the INVALID flag, you need to call on the state module, since netfilter/iptables uses conntrack/state to make this distinction. For this rule we're just going to accept the packet as it comes in in order to log it, then we're going to drop the packet right after logging:
sudo iptables -A INPUT -m state --state INVALID -j LOG --log-prefix " INVAL PCKT "
sudo iptables -A INPUT -m state --state INVALID -j DROP
### Creating custom chains ###
** With netfilter/iptables you can also create custom chains to hold a set of rules. Custom chains are nice for when you want to do more in depth processing on a packet/packets, and not have it potentially interfere with any other rules in a particular chain. To write a new chain you use the '-N' flag followed by the name of the custom chain:
sudo iptables -N NEWCHAINNAME
** Once you make a new chain, it will appear at the bottom of your chains/rules. Then to add rules for that chain you use essentially all the same commands n such as above, the only difference being you need to specify the new chain name in place of the default chain names like 'INPUT', 'OUTPUT', 'FORWARD'. An example:
sudo iptables -A NEWCHAINNAME thenwhateverrulesyouwanthere
sudo iptables -A NEWCHAINNAME someotherrulehere
sudo iptables -A NEWCHAINNAME someotherrulehere
** After doing this the rules/rules will be added to the chain. Now with this new chain, it won't doing anything in and of itself. You need to specify that new chain as a target within a seperate rule in one of the 3 default chains. For example, the new chain from above 'NEWCHAINNAME', say that that set of rules is to deal with tcp packets with bad flags, and you wanted to add that new chain within the default 'INPUT' chain, since you wouldn't want these mal-flagged packets inbound. All you do from here is write a simple rules for inbound tcp traffic on the incoming interface 'eth0', then specify the new target NEWCHAINNAME within that rule as a redirect for any mal-flagged tcp packets:
sudo iptables -A INPUT -i eth0 -p tcp -j NEWCHAINNAME
** Now when any potential mal-flagged packets come through they will be picked up by this rule and processed accordingly.
** This is a pretty basic explanation of writing custom chains. Writing custom chains is also nice from a orginazational standpoint. Instead of having to watch what rule goes where in any of your default chains [writing a ton of rules in a default chain can get hairy], you can just write up a custom chain with specific rules and place it in the required default chain and not have a massive clusterf**k of rules if you weren't to do that in the first place. This can save headache later on, especially if you're writing quite alot of rules in a particular chain and not sure if some of those rules are going to interfere with other rules within that chain.
### Allowing Netfilter Rule Persistence ###
** Last thing I'll quickly cover is setting things up so that the netfilter rules persist across reboots. There's a handful of ways I can think of off the top of my head to do this, though they according to some can be hack-y, so we'll just go with the most common way: 'iptables-persistent'. To get the package:
sudo apt-get iptables-persistent
This package by itself doesn't allow any newly stated rules to persist after reboot. It requires you to run an additional command any time you have updated your rules in order for iptables-persistent to do it's magic with your /etc/iptables/rules.v4 file. The command to run whenever you've added/edited rules is 'iptables-save'. The iptables-save command when ran by itself places your updated iptables-rules in memory, then putting them to stdout/terminal to display. With this command you just redirect the output instead to the file '/etc/iptables/rules.v4', rewriting the rules.v4 file, then with the iptables-persistent package recognizing this rewrite, now when you go to reboot, your newly stated rules will be saved:
sudo iptables-save > /etc/iptables/rules.v4
** Now the basic but completed chain/rules list is:
-P INPUT DROP
-P OUTPUT DROP
-P FORWARD DROP
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -p tcp -j NEWCHAINNAME
-A INPUT -p udp -m udp --dport 53 -m state --state RELATED,ESTABLISHED
-A INPUT -m state --state ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j LOG --log-prefix " INVAL PCKT "
-A INPUT -m state --state INVALID -j DROP
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p udp -m udp --sport 53 -m state --state NEW,ESTABLISHED
-A OUTPUT -m state --state NEW,ESTABLISHED -j ACCEPT
-N NEWCHAINNAME
-A NEWCHAINNAME someruleforbadpackets
-A NEWCHAINNAME someotherruleforbadpackets
-A NEWCHAINNAME alsosomeotherruleforbadpackets
** What these sets of rules in this tutorial achieve is to allow us to connect to the internet ONLY IF 'we are the ones establishing the connection from our host', and DROP anything/everything else that doesn't fit that specific goal [defaulted to drop for inbound/outbound/forwarded], so any sort of inbound connection, no matter what, will be dropped. This is a simple set of rules to achieve this. With this plus netfilter/iptables logging capabilities, this is a good first start to get you up n running with a simple packet filtering ruleset.
** The above rules 'are not' the stopping point necessarily with regards to writing better-defined rules in order to have a more in depth approach to filter what comes in and what goes out. This lsit of chains/rules are 'reasonably secure', though there's additions one could add to this list of rules to harden things even moreso. I just wanted to show a base set of rules for people to start from, then learn and adapt their own stuff accordingly. My main focus was to just describe and talk a bit about the basics of setting up chains and rules, which hopefully this tutorial accomplished that.
|