Iptables Revisited: a Not So Ordinary 'Firewall'
Total Page:16
File Type:pdf, Size:1020Kb
iptables revisited: a not so ordinary ‘firewall' Per Linde, Martynas Pumputis and Guillermo Rodr´ıguez fPer.Linde.3289, Martynas.Pumputis.0695, [email protected] Abstract At the present time, security on the internet, and networks in general have evolved, and become an issue that should not be disregarded. It is well known that many experts recommend Linux as the main operating system for the machines that have to be in charge of security (also for a desktop computer). Linux included a basic firewall tool called ipchains in the series of its kernel until 2.4 version, though after that version it switched to iptables. iptables is known for its efficiency and functionality, but the enormous functionality means a more complex tool to be configured. This paper will overview some mechanisms to do advanced configuration of iptables based on two main scenarios. The different configurations presented will try to prove the remarkable power of iptables as an inde- pendent firewall and also as a tool that can work in conjuntion with other tools usually incorporated when included this one. Contents 1 Introduction 2 2 Matching patterns 3 3 Registering and debugging iptables' actions 3 4 Constraining a connection 3 4.1 Regulating by time . .3 4.2 Regulating by quota . .4 4.3 Limiting resource's abuse . .4 5 Load balancing 4 6 Shaping traffic flows 5 6.1 Scenario . .5 6.2 (Brief) introduction to tc ..........................................5 6.3 Flagging packets with iptables's `mangle' table . .6 6.4 Protection against SYN-floods and ICMP DoS . .7 7 Conclusion 8 8 Appendix 10 1 1 Introduction iptables is a firewall developed by the Netfilter Project1. Presently, this firewall is becoming more and more popular (both among end users and network administrators). The popularity of this firewall it closely related to Linux operating system, because iptables works with Linux kernels 2.4 and 2.6 and almost every major Linux distribution comes with pre-installed iptables firewall. This firewall is also known as a stateful packet filter. It is a main difference between iptables and ipchains (an ancestor of iptables that was used with Linux kernel versions up to 2.4). The firewall supports not only a packet filtering, but it is also able to log, forward packets and it could be used together with such tools as psad, snort, tc. In this paper we will look a bit deeper into more advance iptables configurations, but first of all, we would like to introduce a reader to a basic usage of iptables. The core of the firewall consists of four parts [7]: tables, chains, matches and targets. A system administrator is able to define an iptables policy, i.e. tables of chains, which describe how a kernel should react against different groups of packets. Rules are used to create a chain - collection of rules that is applied to every packet. There are five predefined chains: • INPUT: used for incoming packets before routing. • OUTPUT: used for packets coming into the box itself. • FORWARD: used for packets being routed through the box. • PREROUTING: used for locally-generated packets before routing. • POSTROUTING: used for packets as they about to leave iptables. Every rule should have a set of matches, that helps to filter packets (e.g. -d 10.100.1.1 matches a destination IP 10.100.1.1), and it also has to have a target - an action which should be performed when a rule matches on a packet (e.g. ACCEPT, DROP, LOG...). All the examples presented in this paper (excluding the one used at section 6) will be based on the scenario presented in the figure 1. In the following scenario, WebServer#1 (10.100.1.101 assigned to its `eth0' interface), WebServer#2 (10.100.1.102 assigned to its `eth0' interface) and PC (10.100.1.33 assigned to its `eth0' interface) belong to a local network and every packet that comes from the Internet/LAN is filtered by the firewall (`eth1' interface for LAN's traffic, `eth0' for Internet's traffic). PC (212.59.0.1 assigned to `eth0' interface) is reachable directly through the Internet. Figure 1: Main scenario for iptables's configurations 1http://netfilter.org 2 The listing 1 shows a couple of rules, the first one appends a rule to the end of the INPUT chain and it specifies that every packet from the source with IP address 212.59.0.1 will beDROPed and the second rule logs all outgoing connections from eth1 interface. , iptables -A INPUT -s 212.59.0.1 -j DROP iptables -A OUTPUT -o eth1 -j LOG Listing 1: iptables sample rules 2 Matching patterns Sometimes we want to filter (drop) packets that contain some bad content (for example .exe files, packets with wrong IP headers). In such case \string" extension could be used. It allows to match a string with a packet's payload, as it shown in the listing 2, where the first rule is used to drop a packet that contains a `bad word' string, and the second rule drops a packet that contains an executable file, .exe. , iptables -A INPUT -m string --string 'bad word' --algo bm -j DROP iptables -A INPUT -m string --string '.exe' --algo bm -j DROP Listing 2: Usage of iptables's `string' extension When we are filtering files by extensions, we should beware of a few issues: • Usually files are splited into multiple packets (because of file size which is usually bigger than one packet size) and only one packet, which contains extension string, will be dropped. • Also, some content that containt a string with file extension will be filtered. 3 Registering and debugging iptables' actions In some cases it can be useful to log network events and in these cases the LOG target comes in handy. The LOG target can be used to log information about packets in a logfile, which can be useful for debugging or as evidence for a prohibited network activity. When a firewall script is being tested the administrator can use LOG as target instead of DROP in his rules. Test of the script can then be made fairly easy by observing the log files. The actual logging is handled by the syslogd which log sytem events to the file /var/log/messages, the messages can be read by using the command dmesg. With the LOG argument –log-prefix it is possible to attach a prefix string to every entry, which will make it easier to find all relevant iptables entries (or automate the process by using the command grep). The log entries consist of packet data, like most of the IP-header and other interesting data. [2]. , iptables -P INPUT LOG --log-prefix "INPUT packets" Listing 3: An administrator is testing a new scrip, while testing he uses LOG instead of DROP 4 Constraining a connection 4.1 Regulating by time In many networks there are regular server maintaining hours, this can include actions like backups, system updates and/or system scans. When these actions are being executed it can be necessary to redirect the traffic from the current server to another server. It can also be the case that some types of traffic should only be allowed during certain hours, so employees are able to get internet access only during lunch hours and no access or limited access during office hours. In listing 4, employers are allowed to browse the internet (HTTP(S)) during lunch hours. Note that traffic should be dropped by default. , iptables -A FORWARD -p tcp -m multiport --dport http,https -o eth0 -i eth3 -m time --timestart 12:00 --timestop 13:00 -j ACCEPT Listing 4: Example of regulation by time 3 Listing 5 shows how all TCP/UDP traffic is dropped by default during service hours (between 02:00 and 03:00), that is for maintenance 's tasks which should not be disrupted by incoming traffic. , iptables -A INPUT -p tcp -m time --timestart 02:00 --timestop 03:00 -j DROP iptables -A INPUT -p udp -m time --timestart 02:00 --timestop 03:00 -j DROP Listing 5: Another example of regulation by time 4.2 Regulating by quota In most systems a normal bandwidth usage can easily be calculated, if the bandwidth exceeds this level with some marginal it is possible that the traffic is unauthorized and should be limited. When using the quota rule the administrator can specify an amount of data that is allowed/disallowed or if a specific quota should be handled by one server and all other traffic by another. Listing 6 shows how a a quota of 10 Gb of HTTP traffic is allowed, and once this limit is reached the traffic is redirected to 10.100.1.102 which will return a page with the quota warning. , iptables -A PREROUTING -p tcp --dport http -m quota 10737418240 -j ACCEPT iptables -A PREROUTING -p tcp --dport http -j DNAT --to-destination 10.100.1.102 Listing 6: Example of quota handling One problem with iptables bandwidth monitoring is its counter, which is reset if the iptables service is restarted. Note also that the administrator in the example above have to reset the counter every month. 4.3 Limiting resource's abuse Another possibility to limit traffic thru the router is to use limit and iplimit. Limit specifies how many times per time unit an action are targeted, e.g. preventing SYN flooding. iplimit specifies how many connections from one IP number is targeted, e.g. one IP number should not be allowed to have more than 10 parallel connections to the router.