Main functions of Linux Netfilter Filter Nat Packet filtering (rejecting, dropping or accepting packets) Network Address Translation including DNAT, SNAT and Masquerading Mangle General packet header modification such as setting the TOS value or marking packets for policy routing and traffic shaping. Close interaction with routing Introduction 1
Basics Rules are divided into tables : Filter (filtering what is allowed standard firewall) Nat (modifying source or destination address) Raw (if access to the raw packet is needed without any processing) Mangle (to modify packets) Tables are divided into chains Input (packets intended to go to the firewall itself, local flows) Output (from the firewall) Prerouting Postrouting Forward (not local) User defined (chains) Introduction 2
Packet processing Introduction 3
Rules Rules can be inserted by the iptables tool from the command line Scripts can be made with multiple iptables calls For some distributions, graphical tools help editing firewall rules There are numerous specific tools for netfilter/iptables rule editing Using graphical tools might make it harder to understand what is done deep inside Introduction 4
Packet processing Consider a rule list: The first rule matches with an appropriate target (ACCEPT,DROP,REJECT, ) stops the processing of the packet and the other rules are not used Drop: do not do anything, drop the packet Reject: send ICMP port unreachable LOG rule makes a log item on the packet, but the processing of the packet goes forward Chain target series of rules in separate chains (see later) At last, the default policy (ACCEPT, DROP) is used Introduction 5
http://hydra.geht.net/tino/howto/linux/net/ netfilter/packet_flow10.png Introduction 6
Introduction 7
http://www.linuxhomenetworking.com/wiki/images/f/f0/iptables.gif Introduction 8
Iptables netfilter initialization Clearing/flushing rules: E.g. iptables -F INPUT iptables -F OUTPUT iptables -F FORWARD iptables -t nat -F INPUT iptables -t nat -F OUTPUT iptables -t nat -F POSTROUTING iptables -t nat -F PREROUTING Cleared tables: root@hbgyak:~# iptables -L -v n Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination As You can see, there are no rules in the chains and the default policy is accept. Introduction 9
Basic Iptables parameters -I, -A : Insert or Add rule. Add puts the rule at the end, I at the beginning of the list of existing rules -D,-R,-L: Delete, Replace, List -t: table selection. Default: filter table Matching rules: -p tcp: protocol match -i eth0, -o eth0: input interface match. Only usable in correspoing chain (e.g. o cannot be used in input chain) --dport 80: destination port match, only usable combined with protocol match -j ACCEPT: target rule. Check the net for more information. Introduction 10
Setting default policy: root@hbgyak:~# iptables -L INPUT -v Chain INPUT (policy ACCEPT 135 packets, 17592 bytes) pkts bytes target prot opt in out source destination root@hbgyak:~# iptables -I INPUT -j ACCEPT root@hbgyak:~# iptables -P INPUT DROP root@hbgyak:~# iptables -L INPUT -v -n Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 291 31532 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Subnet bits The default policy -P is what to do with packets that do not match any other rule Flushing the INPUT table and setting the default policy to DROP can cause problems = cannot connect to the computer anymore Counters show the number of packets and bytes matched by this rule Introduction 11
A very simple firewall root@hbgyak:/root/bin# iptables -L INPUT -v -n Chain INPUT (policy ACCEPT 527K packets, 68M bytes) pkts bytes target prot opt in out source destination 141K 13M ACCEPT tcp tcp dpt:22 -- * * 0.0.0.0/0 1.2.3.151 544 2342K ACCEPT tcp tcp dpt:25 -- lo * 0.0.0.0/0 1.2.3.151 154K 18M ACCEPT tcp tcp dpt:80 -- * * 0.0.0.0/0 1.2.3.151 10 857 ACCEPT tcp tcp dpt:443 -- * * 0.0.0.0/0 1.2.3.151 37 2220 ACCEPT tcp tcp dpt:113 -- * * 1.2.3.151 1.2.3.151 0 0 ACCEPT tcp tcp dpt:113 -- * * 1.2.3.177 1.2.3.151 1 52 REJECT tcp -- * * 0.0.0.0/0 1.2.3.151 tcp dpt:113 reject-with icmp-port-unreachable 0 0 LOG tcp -- * * 0.0.0.0/0 1.2.3.151 tcp dpt:110 LOG flags 0 level 4 60 3158 DROP tcp tcp dpts:1:1024 -- * * 0.0.0.0/0 1.2.3.151 Simple reject: ICMP port unreachable as answer portmap can/should discover it. Another option: -j REJECT --reject-with-tcp-reset Introduction 12
How to Debug netfilter rule sets It is a hard task to figure out what is wrong with a large ruleset Simply put a full accept into the specific chains (INPUT, FORWARD, etc.) and check if it helps If the traffic is going through, the problematic rule is in the specific chain this method makes us vulnerable for a short time, and it is possible to forget such generic accept rules, therefore, it cannot be used in corporate environment Ad-hoc modification of firewall rules cannot is not a good thing Another possibility is to observe/zero packet counters Zero the counters Start test traffic Check rules with non-zero counters: these are the candidates for the error (DROP, REJECT) Rules with 0 counters can also indicate problems (ACCEPT) Rules with 0 packets for a long time might indicate unneeded rules Introduction 13
chains With hundreds of rules it is very hard to understand Especially within a chain (e.g. INPUT) Chains make it easier to understand the ruleset, as a subchain can be understood and analyzed easier Introduction 14
A new chain - web root@hbgyak:~# iptables -N web root@hbgyak:~# iptables -L -v -n Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 8435 1351K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 271 packets, 32550 bytes) pkts bytes target prot opt in out source destination Chain web (0 references) pkts bytes target prot opt in out source destination Introduction 15
Two rules in the new chain root@hbgyak:~# iptables -A web -p tcp --dport 443 -j ACCEPT root@hbgyak:~# iptables -A web -p tcp --dport 80 -j ACCEPT root@hbgyak:~# iptables -L web -v -n Chain web (0 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 Introduction 16
The return rule root@hbgyak:~# iptables -I web -p udp -j RETURN root@hbgyak:~# iptables -L web -v -n Chain web (0 references) pkts bytes target prot opt in out source destination 0 0 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 The return rule makes the processing more complicated to analyze (branch point) But helps debugging, and clear set of policies: e.g. in the upper case the web chain surely not processes udp packets Introduction 17
Finally: use the web chain as a terget root@hbgyak:~# iptables -I INPUT -j web root@hbgyak:~# iptables -L -v -n Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 36 2912 web all -- * * 0.0.0.0/0 0.0.0.0/0 10057 1557K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 770 packets, 83660 bytes) pkts bytes target prot opt in out source destination Chain web (1 references) pkts bytes target prot opt in out source destination 4 384 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT tcp tcp dpt:443 -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT tcp tcp dpt:80 -- * * 0.0.0.0/0 0.0.0.0/0 Introduction 18
Target combined with match root@hbgyak:~# iptables -I INPUT -j web -p tcp In this case the Return rule with UDP is useless Still, Return rules can be helpful in some examples root@hbgyak:~# iptables -L -v -n Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 60 3596 web tcp -- * * 0.0.0.0/0 0.0.0.0/0 88 8256 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 60 packets, 17843 bytes) pkts bytes target prot opt in out source destination Chain web (1 references) pkts bytes target prot opt in out source destination 0 0 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT tcp tcp dpt:443 -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT tcp tcp dpt:80 -- * * 0.0.0.0/0 0.0.0.0/0 Note: Web counters are 0, but the rule in the INPUT chain shows 60 packets. The web chain was used, but no packets matched. Default policy: Return. Introduction 19
Example: Mangling MTU iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j TCPMSS --clamp-mss-to-pmtu This causes netfilter to modify MSS value in TCP handshake to be modified to match to the MTU of the interface (MSS=MTU-40 (generally or always?)) Introduction 20
Other mangle features Strip all IP options Change TOS values Change TTL values Strip ECN values Clamp MSS to PMTU Mark packets within kernel Mark connections within kernel Introduction 21
Connection tracking / basics only Netfilter is a stateful firewall/networking stack Example: stateless forwarding rule: root@hbgyak:~# iptables -A FORWARD -j ACCEPT -s 1.2.3.4 -d 5.5.5.5 -p tcp --dport 80 root@hbgyak:~# iptables -A FORWARD -j ACCEPT -d 1.2.3.4 -s 5.5.5.5 -p tcp --sport 80 root@hbgyak:~# iptables -L FORWARD -v -n Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * * 1.2.3.4 5.5.5.5 tcp dpt:80 0 0 ACCEPT tcp -- * * 5.5.5.5 1.2.3.4 tcp spt:80 Problem: An attacker who owns 5.5.5.5 can connect to any port of 1.2.3.4 by disabling the web server and using port 80 as a source port. Introduction 22
A stateful accept rule root@hbgyak:~# iptables -A FORWARD -j ACCEPT -s 1.2.3.4 -d 5.5.5.5 -p tcp --dport 80 root@hbgyak:~# iptables -A FORWARD -j ACCEPT -s 0/0 -d 0/0 -m state --state ESTABLISHED,RELATED -v ACCEPT all opt -- in * out * 0.0.0.0/0 -> 0.0.0.0/0 state RELATED,ESTABLISHED root@hbgyak:~# iptables -L FORWARD -v -n Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * * 1.2.3.4 5.5.5.5 tcp dpt:80 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED Now: 1.2.3.4 can connect to the web server on 5.5.5.5 and any packet related to valid TCP connections are accepted back in. However, if the attacker, who owns 5.5.5.5 cannot initiate any connection to 1.2.3.4 to any port, unless 1.2.3.4 wants to do so. Introduction 23
Rate limiting example We can set rate limits to avoid DoS attacks root@hbgyak:~# iptables -P INPUT ACCEPT root@hbgyak:~# iptables -F INPUT root@hbgyak:~# iptables -A INPUT -p tcp --dport 25 --syn -m limit - -limit 1/s --limit-burst 3 -j ACCEPT -v ACCEPT tcp opt -- in * out * 0.0.0.0/0 -> 0.0.0.0/0 tcp dpt:25 flags:0x17/0x02 limit: avg 1/sec burst 3 root@hbgyak:~# iptables -L INPUT -v -n Chain INPUT (policy ACCEPT 644 packets, 70669 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 flags:0x17/0x02 limit: avg 1/sec burst 3 But this rule alone is not enough! The limit target matches to 1 packet each second and accepts it The rest is processed through the normal ruleset (possibly also accepted) Introduction 24
Rate limiting #2 Adding the following rule: root@hbgyak:~# iptables -A INPUT -p tcp --dport 25 --syn -j DROP -v DROP tcp opt -- in * out * 0.0.0.0/0 -> 0.0.0.0/0 tcp dpt:25 flags:0x17/0x02 root@hbgyak:~# iptables -L INPUT -v -n Chain INPUT (policy ACCEPT 1052 packets, 129K bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 flags:0x17/0x02 limit: avg 1/sec burst 3 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 flags:0x17/0x02 Now, SYN packets at the rate of 1/sec to the SMTP are accepted, the rest is dropped. Lesson learned: the LIMIT is just a matching rule, it does not processes packets just helps to match the appropriate packets. Hierarchical limits can be done: e.g. 500/hour 60/minute, 3/sec You have to understand how Netfilter works to work efficiently and in a secure fashion! Introduction 25
Interaction with routing Step 1. Define a iproute2 rule in rt_tables: root@hbgyak:~# cat /etc/iproute2/rt_tables # # reserved values # 255 local 254 main 253 default 0 unspec # # local # #1 inr.ruhep 200 proba Introduction 26
FWMARK target Marks packet with a specific ID that can be used in the routing or in netfilter for numerous reasons (routing, QoS, filtering, etc.) E.g.: root@hbgyak:~# iptables -t nat -A PREROUTING -d 1.2.3.4 -j MARK --set-mark 0xace root@hbgyak:~# iptables -t nat -A PREROUTING -d 1.2.3.4 -p tcp -j MARK --set-mark 0xacd root@hbgyak:~# iptables -L PREROUTING -v -n -t nat Chain PREROUTING (policy ACCEPT 4 packets, 688 bytes) pkts bytes target prot opt in out source destination 0 0 MARK all -- * * 0.0.0.0/0 1.2.3.4 MARK xset 0xace/0xffffffff 0 0 MARK tcp -- * * 0.0.0.0/0 1.2.3.4 MARK xset 0xacd/0xffffffff This means, first, every packet to 1.2.3.4 are marked with 0xace. But then, this mark is overwritten for TCP packets with a different mark (0xacd). Only one mark is left on the packet at the end. Introduction 27
Ip rule setting Now, set a rule in the advanced ip rules: root@hbgyak:~# ip rule add fwmark 0xace table proba root@hbgyak:~# ip rule show 0: from all lookup local 32764: from all fwmark 0xace lookup proba 32765: from all lookup main 32767: from all lookup default This means, that whenever a packet has a 0xace mark (see previous slide for what packets are affected), the proba routing table should be used Introduction 28
Proba routing table Finally, set the proba routing table root@hbgyak:~# ip route add 5.4.3.2 via 10.105.1.254 table proba root@hbgyak:~# ip route show table proba 5.4.3.2 via 10.105.1.254 dev eth0 root@hbgyak:~# Now, if a packet matches the appropriate iptables/netfilter rules Then the ip rule puts the routing processing onto the proba table And a different route is going to be selected to that specific packet Introduction 29
Conclusions Netfilter is a very sophisticated tool, handle with care Remote administration is dangerous! (You can disconnect yourself, ) A lot other functions, possibilities and modules exist what is not investigated within this lecture Every need can be fulfilled in numerous ways, it is not easy to choose the easiest It is very hard to understand what somebody other did in netfilter due to the different philosophy Netfilter rule sets can contain security problems! It is very hard to make, maintain a consistent, understandable, simple, secure rule set that really fulfills the needs of the company and complies to the security policy Mostly, security holes of the firewall are not that important Cannot be mapped, figured out Cannot be exploited Most critical errors can be identified by security assessment tools Introduction 30