Main functions of Linux Netfilter

Transcription

1 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

2 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

3 Packet processing Introduction 3

4 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

5 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

6 netfilter/packet_flow10.png Introduction 6

7 Introduction 7

8 Introduction 8

9 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: 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

10 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

11 Setting default policy: iptables -L INPUT -v Chain INPUT (policy ACCEPT 135 packets, bytes) pkts bytes target prot opt in out source destination iptables -I INPUT -j ACCEPT iptables -P INPUT DROP iptables -L INPUT -v -n Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination ACCEPT all -- * * / /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

12 A very simple firewall 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 -- * * / K ACCEPT tcp tcp dpt:25 -- lo * / K 18M ACCEPT tcp tcp dpt:80 -- * * / ACCEPT tcp tcp dpt: * * / ACCEPT tcp tcp dpt: * * ACCEPT tcp tcp dpt: * * REJECT tcp -- * * / tcp dpt:113 reject-with icmp-port-unreachable 0 0 LOG tcp -- * * / tcp dpt:110 LOG flags 0 level DROP tcp tcp dpts:1: * * / Simple reject: ICMP port unreachable as answer portmap can/should discover it. Another option: -j REJECT --reject-with-tcp-reset Introduction 12

13 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

14 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

15 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 K ACCEPT all -- * * / /0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 271 packets, 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

16 Two rules in the new chain iptables -A web -p tcp --dport 443 -j ACCEPT iptables -A web -p tcp --dport 80 -j ACCEPT iptables -L web -v -n Chain web (0 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * * / /0 tcp dpt: ACCEPT tcp -- * * / /0 tcp dpt:80 Introduction 16

17 The return rule iptables -I web -p udp -j RETURN 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 ACCEPT tcp -- * * / /0 tcp dpt: ACCEPT tcp -- * * / /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

18 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 web all -- * * / / K ACCEPT all -- * * / /0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 770 packets, bytes) pkts bytes target prot opt in out source destination Chain web (1 references) pkts bytes target prot opt in out source destination RETURN udp -- * * / /0 0 0 ACCEPT tcp tcp dpt: * * / /0 0 0 ACCEPT tcp tcp dpt:80 -- * * / /0 Introduction 18

19 Target combined with match 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 iptables -L -v -n Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination web tcp -- * * / / ACCEPT all -- * * / /0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 60 packets, 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 ACCEPT tcp tcp dpt: * * / /0 0 0 ACCEPT tcp tcp dpt:80 -- * * / /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

20 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

21 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

22 Connection tracking / basics only Netfilter is a stateful firewall/networking stack Example: stateless forwarding rule: root@hbgyak:~# iptables -A FORWARD -j ACCEPT -s d p tcp --dport 80 root@hbgyak:~# iptables -A FORWARD -j ACCEPT -d s 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 -- * * tcp dpt: ACCEPT tcp -- * * tcp spt:80 Problem: An attacker who owns can connect to any port of by disabling the web server and using port 80 as a source port. Introduction 22

23 A stateful accept rule iptables -A FORWARD -j ACCEPT -s d p tcp --dport 80 iptables -A FORWARD -j ACCEPT -s 0/0 -d 0/0 -m state --state ESTABLISHED,RELATED -v ACCEPT all opt -- in * out * /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 -- * * tcp dpt: ACCEPT all -- * * / /0 state RELATED,ESTABLISHED Now: can connect to the web server on and any packet related to valid TCP connections are accepted back in. However, if the attacker, who owns cannot initiate any connection to to any port, unless wants to do so. Introduction 23

24 Rate limiting example We can set rate limits to avoid DoS attacks iptables -P INPUT ACCEPT iptables -F INPUT 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 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, bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * * / /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

25 Rate limiting #2 Adding the following rule: iptables -A INPUT -p tcp --dport 25 --syn -j DROP -v DROP tcp opt -- in * out * /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 tcp dpt:25 flags:0x17/0x02 limit: avg 1/sec burst DROP tcp -- * * / /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

26 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

27 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 j MARK --set-mark 0xace root@hbgyak:~# iptables -t nat -A PREROUTING -d 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 -- * * / MARK xset 0xace/0xffffffff 0 0 MARK tcp -- * * / MARK xset 0xacd/0xffffffff This means, first, every packet to 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

28 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

29 Proba routing table Finally, set the proba routing table ip route add via table proba ip route show table proba via dev eth0 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

30 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