Main functions of Linux Netfilter

(1)

Main functions of Linux Netfilter

 Filter

– Packet filtering (rejecting, dropping or accepting packets)

 Nat

– 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.

(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

(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

(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

(6)



http://hydra.geht.net/tino/howto/linux/net/

(7)

(8)



http://www.linuxhomenetworking.com/

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

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)

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)

(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.

(11)

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)

 291 31532 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0

 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

(12)

A very simple firewall

root@hbgyak:/root/bin# iptables -L INPUT -v -n

Chain INPUT (policy ACCEPT 527K packets, 68M bytes)

141K 13M ACCEPT tcp -- * * 0.0.0.0/0 1.2.3.151 tcp dpt:22 544 2342K ACCEPT tcp -- lo * 0.0.0.0/0 1.2.3.151 tcp dpt:25 154K 18M ACCEPT tcp -- * * 0.0.0.0/0 1.2.3.151 tcp dpt:80 10 857 ACCEPT tcp -- * * 0.0.0.0/0 1.2.3.151 tcp dpt:443 37 2220 ACCEPT tcp -- * * 1.2.3.151 1.2.3.151 tcp dpt:113 0 0 ACCEPT tcp -- * * 1.2.3.177 1.2.3.151 tcp dpt:113 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 -- * * 0.0.0.0/0 1.2.3.151

tcp dpts:1:1024

(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)

(14)

chains

 With hundreds of rules it is very hard to understand

 Especially within a chain (e.g. INPUT)

(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



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)

(16)

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)

 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443

(17)

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)

(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)

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 web (1 references)

4 384 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

(19)

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)

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 web (1 references)

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

(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

(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

(22)

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

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

(23)

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

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.

(24)

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!

(25)

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)

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

(26)

Interaction with routing

 Step 1. Define a iproute2 rule in rt_tables:

(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 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)

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

(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”

(29)

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:~#

(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