main functions of linux netfilter - · pdf filemain functions of linux netfilter filter ......

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

Close interaction with routing

Introduction 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 3

Packet processing

Introduction 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 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 6

http://hydra.geht.net/tino/how

to/linux/net/netfilter/packet_flow

10.png

Introduction 7

Introduction 8

http://w

ww

.linuxhomenetw

orking.com/w

iki/images/f/f0/Iptables.gif

Introduction 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)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 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 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) pkts bytes target prot opt in out source destination 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

Counters show the number of packets and bytes matched by this rule

Subnet bits

Introduction 12

A very simple firewall

root@hbgyak:/root/bin# iptables -L INPUT -v -nChain INPUT (policy ACCEPT 527K packets, 68M bytes)pkts bytes target prot opt in out source destination141K 13M ACCEPT tcp -- * * 0.0.0.0/0 1.2.3.151

tcp dpt:22544 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:8010 857 ACCEPT tcp -- * * 0.0.0.0/0 1.2.3.151 tcp dpt:44337 2220 ACCEPT tcp -- * * 1.2.3.151 1.2.3.151 tcp dpt:1130 0 ACCEPT tcp -- * * 1.2.3.177 1.2.3.151 tcp dpt:1131 52 REJECT tcp -- * * 0.0.0.0/0 1.2.3.151 tcp dpt:113 reject-with icmp-port-unreachable0 0 LOG tcp -- * * 0.0.0.0/0 1.2.3.151 tcp dpt:110 LOG flags 0 level 460 3158 DROP tcp -- * * 0.0.0.0/0 1.2.3.151 tcp dpts:1:1024

Simple reject: ICMP port unreachable as answer – portmap can/should discover it.Another option: -j REJECT --reject-with-tcp-reset

Introduction 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 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 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) pkts bytes target prot opt in out source destination

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

But helps debugging, and clear set of policies: e.g. in the upper case the web chain surely not processes udp packets

Introduction 18

Finally: use the web chain as a terget

root@hbgyak:~# iptables -I INPUT -j webroot@hbgyak:~# iptables -L -v -nChain INPUT (policy DROP 0 packets, 0 bytes)pkts bytes target prot opt in out source destination36 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)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 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:4430 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80

Introduction 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 examplesroot@hbgyak:~# iptables -L -v -nChain INPUT (policy DROP 0 packets, 0 bytes)pkts bytes target prot opt in out source destination60 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)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:4430 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80

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 20

Example: Mangling MTU

iptables -t mangle -A POSTROUTING -p tcp --tcp-flagsSYN,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 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 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 80root@hbgyak:~# iptables -A FORWARD -j ACCEPT -d 1.2.3.4 -s 5.5.5.5 -p tcp --sport 80root@hbgyak:~# iptables -L FORWARD -v -nChain 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:800 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 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 80root@hbgyak:~# iptables -A FORWARD -j ACCEPT -s 0/0 -d 0/0 -m state --state

ESTABLISHED,RELATED -vACCEPT all opt -- in * out * 0.0.0.0/0 -> 0.0.0.0/0 state RELATED,ESTABLISHEDroot@hbgyak:~# iptables -L FORWARD -v -nChain 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:800 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 stateRELATED,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 24

Rate limiting example

We can set rate limits to avoid DoS attacks

root@hbgyak:~# iptables -P INPUT ACCEPTroot@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 itThe rest is processed through the normal ruleset (possibly also

accepted)

Introduction 25

Rate limiting #2Adding 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 -nChain INPUT (policy ACCEPT 1052 packets, 129K bytes)pkts bytes target prot opt in out sourcedestination0 0 ACCEPT tcp -- * * 0.0.0.0/0

0.0.0.0/0 tcp dpt:25 flags:0x17/0x02 limit: avg 1/sec burst30 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 26

Interaction with routing

Step 1. Define a iproute2 rule in rt_tables:root@hbgyak:~# cat /etc/iproute2/rt_tables## reserved values#255 local254 main253 default0 unspec## local##1 inr.ruhep200 proba

Introduction 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 0xaceroot@hbgyak:~# iptables -t nat -A PREROUTING -d 1.2.3.4 -p tcp

-j MARK --set-mark 0xacdroot@hbgyak:~# iptables -L PREROUTING -v -n -t natChain PREROUTING (policy ACCEPT 4 packets, 688 bytes)pkts bytes target prot opt in out sourcedestination0 0 MARK all -- * * 0.0.0.0/0

1.2.3.4 MARK xset 0xace/0xffffffff0 0 MARK tcp -- * * 0.0.0.0/0

1.2.3.4 MARK xset 0xacd/0xffffffffThis 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 28

Ip rule setting

Now, set a rule in the advanced ip rules:

root@hbgyak:~# ip rule add fwmark 0xace table probaroot@hbgyak:~# ip rule show0: from all lookup local32764: from all fwmark 0xace lookup proba32765: from all lookup main32767: 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 29

Proba routing table

Finally, set the proba routing tableroot@hbgyak:~# ip route add 5.4.3.2 via 10.105.1.254 table

proba

root@hbgyak:~# ip route show table proba5.4.3.2 via 10.105.1.254 dev eth0root@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 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

main functions of linux netfilter - · pdf filemain functions of linux netfilter filter ......

Documents