From fca59bea770346cf1c1f9b0e00cb48a61b44a8f3 Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Sun, 25 Oct 2015 21:00:20 +0100 Subject: import of old now defunct presentation slides svn repo --- 2002/firewalling-knf-2002/abstract | 48 ++ 2002/firewalling-knf-2002/firewall.mgp | 312 ++++++++++++ 2002/firewalling-knf-2002/toc | 100 ++++ 2002/ipv6-ccc2002/ipv6-ccc2002.mgp | 243 ++++++++++ 2002/ipv6-ccc2002/topics | 114 +++++ 2002/netfilter-bof-ols2002/abstract | 25 + .../netfilter-curdevel-lk2002.mgp | 374 ++++++++++++++ .../netfilter-curdevel-lsm2002.mgp | 374 ++++++++++++++ 2002/netfilter-failover-ols2002/abstract | 31 ++ 2002/netfilter-failover-ols2002/biography | 22 + .../netfilter-failover-ols2002.mgp | 294 +++++++++++ .../netfilter-failover-ols2002.tex | 504 +++++++++++++++++++ 2002/netfilter-failover-ols2002/ols.sty | 56 +++ 2002/netfilter-future-lk2002/abstract | 33 ++ .../netfilter-future-lk2002.mgp | 374 ++++++++++++++ 2002/netfilter-internals-lsm2002/abstract | 49 ++ .../netfilter-internals-lsm2002.mgp | 520 ++++++++++++++++++++ .../netfilter-internals-lsm2002.tex | 537 +++++++++++++++++++++ 2002/netfilter-internals-lt2002/abstract | 49 ++ 2002/netfilter-internals-lt2002/biography | 22 + .../netfilter-internals-lt2002.mgp | 466 ++++++++++++++++++ .../netfilter-internals-lt2002.tex | 537 +++++++++++++++++++++ 2002/netfilter-knf2002/abstract | 50 ++ 2002/netfilter-knf2002/netfilter-knf2002.mgp | 466 ++++++++++++++++++ .../tcp-statetracking-ccc2002.mgp | 201 ++++++++ 2002/tex-introduction-cc2002/tex-einfuehrung | 147 ++++++ 2002/tex-introduction-cc2002/tex-einfuehrung.tex | 430 +++++++++++++++++ 27 files changed, 6378 insertions(+) create mode 100644 2002/firewalling-knf-2002/abstract create mode 100644 2002/firewalling-knf-2002/firewall.mgp create mode 100644 2002/firewalling-knf-2002/toc create mode 100644 2002/ipv6-ccc2002/ipv6-ccc2002.mgp create mode 100644 2002/ipv6-ccc2002/topics create mode 100644 2002/netfilter-bof-ols2002/abstract create mode 100644 2002/netfilter-curdevel-lk2002/netfilter-curdevel-lk2002.mgp create mode 100644 2002/netfilter-curdevel-lsm2002/netfilter-curdevel-lsm2002.mgp create mode 100644 2002/netfilter-failover-ols2002/abstract create mode 100644 2002/netfilter-failover-ols2002/biography create mode 100644 2002/netfilter-failover-ols2002/netfilter-failover-ols2002.mgp create mode 100644 2002/netfilter-failover-ols2002/netfilter-failover-ols2002.tex create mode 100644 2002/netfilter-failover-ols2002/ols.sty create mode 100644 2002/netfilter-future-lk2002/abstract create mode 100644 2002/netfilter-future-lk2002/netfilter-future-lk2002.mgp create mode 100644 2002/netfilter-internals-lsm2002/abstract create mode 100644 2002/netfilter-internals-lsm2002/netfilter-internals-lsm2002.mgp create mode 100644 2002/netfilter-internals-lsm2002/netfilter-internals-lsm2002.tex create mode 100644 2002/netfilter-internals-lt2002/abstract create mode 100644 2002/netfilter-internals-lt2002/biography create mode 100644 2002/netfilter-internals-lt2002/netfilter-internals-lt2002.mgp create mode 100644 2002/netfilter-internals-lt2002/netfilter-internals-lt2002.tex create mode 100644 2002/netfilter-knf2002/abstract create mode 100644 2002/netfilter-knf2002/netfilter-knf2002.mgp create mode 100644 2002/tcp-statetracking-ccc2002/tcp-statetracking-ccc2002.mgp create mode 100644 2002/tex-introduction-cc2002/tex-einfuehrung create mode 100644 2002/tex-introduction-cc2002/tex-einfuehrung.tex (limited to '2002') diff --git a/2002/firewalling-knf-2002/abstract b/2002/firewalling-knf-2002/abstract new file mode 100644 index 0000000..8169aa2 --- /dev/null +++ b/2002/firewalling-knf-2002/abstract @@ -0,0 +1,48 @@ +Grundlagen des Firewallings - Sicherheit in IP-Netzwerken +========================================================= + +Was ist eine Firewall? +Was macht eine Firewall genau? +Was fuer Unterschiede gibt es zwischen Firewalls? +Wo ist der Unterschied zwischen Paketfiltern und Proxies? + +Mit diesen (und anderen) Fragen beschaeftigt sich der KNF-Vortrag ueber die +Grundlagen des Firewallings. + +Ausgehend von einem grundlegenden Wissen ueber TCP/IP Netzwerke und Router +beschreibt dieser Vortrag die dem Firewalling zugrunde liegenden Konzepte +und Strategien, sowie deren Moeglichkeiten. + +In dem Vortrag wird bewusst nicht auf bestimmte Firewall-Produkte oder +Implementationen eingegangen, es sind daher auch keinerlei Vorkenntnisse +in der Anwendung / Administration einer Firewall noetig. + +Gliederung: + +- Kurzer Ueberblick ueber IP-Routing, TCP, UDP, ICMP +- Paketfilter + - Funktionsweise + - traditionelle Paketfilter (ohne state) + - stateful firewalling (connection tracking) + +- Proxies + - Funktionsweise + - 'normale' Proxies + - transparente Proxies + +- Vergleich Paketfilter/Proxy + - daraus abgeleitet + - Moeglichkeiten + - Einsatzbereiche + +- Network Address Translation (NAT) + - static NAT + - static NAPT + - symmetric NAPT + - masquerading + +Ueber den Vortragenden: +Harald Welte ist seit 1995 aktives KNF-Mitglied und der derzeitige +stellvertretende Technische Kontakt des KNF. Er ist der Maintainer des +netfilter/iptables Firewalling-Subsystems im Linux 2.4.x und +2.5.x Kernel und war massgeblich an dessen Entwicklung beteiligt. diff --git a/2002/firewalling-knf-2002/firewall.mgp b/2002/firewalling-knf-2002/firewall.mgp new file mode 100644 index 0000000..d277a35 --- /dev/null +++ b/2002/firewalling-knf-2002/firewall.mgp @@ -0,0 +1,312 @@ +%include "default.mgp" +%default 1 bgrad +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +%nodefault +%back "blue" + +%center +%size 7 + + +TCP/IP Firewalling Basics + +%center +%size 4 +by + +Harald Welte + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Firewalling Basics +Contents + + Introduction + + Networking Basics + + Potential Security Problems + + Solution 1: Packet Filters + + Solution 2: Proxies + + Comparison + + Summary + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Firewalling Basics +Introduction + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Firewalling Basics +Networking Basics + + 7 layer OSI model used to abstract networking protocols + layer 7: application layer: e.g. telnet/ftp + layer 6: presentation layer: + layer 5: session layer: + layer 4: transport layer: e.g. TCP/UDP + layer 3: network layer: e.g. IP + layer 2: data link layer: e.g. Ethernet + layer 1: physical layer: e.g. Wire + Layer 1 + 2 embedded in hardware + Layer 3 + 4 implemented in operating system + Layer 5+ embedded in application program + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Firewalling Basics +Networking Basics + + Layer 2: Ethernet + enables two hosts within same pysical net to exchange packets + unreliable + adressing granularity: host + fixed hardware adresses (MAC adress, 48bit) + + Layer 3: Internet Protocol (IP) + enables two hosts in diferent physical networks to exchange packets + unreliable, best effort + packet reordering + packet loss + adressing granularity: host + logical adresses (IP Adress, 32bit) + checksum protects only IP header + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Firewalling Basics +Networking Basics + + Layer 4: User Datagram Protocol (UDP) + unreliable, best effort + adressing granularity: ports (16bit = 65535) + optional payload checksum + + Layer 4: Transmission Control Protocol (TCP) + provides connection abstraction + reliable + ordering guarantee + retransmissions correct packet loss + flow control + payload checksum protects payload from data corruption + + Layer 4: Internet Control Message Protocol (ICMP) + used internally by TCP/IP protocol suite + error messages (e.g. host unreachable) + diagnostics (e.g. ping/pong) + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Firewalling Basics +Potential Security Problems + + Security issues arise at interconnection of two networks + Traditional Case: IP Router connecting an organization internal network to the Internet + + What Security Problem? + organization-internal services exposed to outside network + spoofed (forged) packets to circumvent 'security by address' + even if all internal services secured by authentication, difficult to guarantee security on all internal hosts + + Why Firewalling? + to restrict which internal services are exposed to the outside + to restrict which outside services are used by internal users + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Firewalling Basics +Solution 1: Packet Filters + + Filter individual packets at network interconnection (Router) + + Filter criteria traditionally include + IP source + destination address + TCP/UDP source + destination port + TCP header flags + + Filtering rules determine if + packet is allowed to transit interconnection + packet is silently dropped + packet is dropped and error message returned to sender + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Firewalling Basics +Solution 1: Packet Filters + + Capabilities + disallow communication between certain IP adresses + disallow communication between certain port numbers + disallow malicious packets, like packets + using source routing IP option + impossible combination of features, like tcp xmas scan + generate log of malicious and/or filtered packets + + Limitations + scope limited to individual packets + no ability to look inside packet payload (HTTP 1.1 virtual hosts) + no abstraction of connection, filtering rules needed for both directions + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Firewalling Basics +Solution 1: Packet Filters + + Extensions + stateful packet filters (connection tracking) + filtering only needed for connection-initiating packets + all other packets within connection are accepted as part of an already established connection + + TCP window tracking + allow filtering not only on source/dest port but also on TCP sequence number + + NAT (Network Address Translation) + manipulation of source / destination address + redirect packets to other hosts + 'share' one ip address at dialup accounts (masquerading) + connect two networks with overlapping addresss ranges + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Firewalling Basics +Solution 2: Proxies + + A proxy operates at layer 5 and above + + Mode of operation + client connects to proxy instead of server + proxy initiates a second, seperate connection to server + + Proxies are just normal programs implementing a server and a client for a particular application protocol (e.g. HTTP) using operating system mechanisms (like sockets API, winsock, ...) + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Firewalling Basics +Solution 2: Proxies + + Capabilities + disallow communication between certain IP adresses + disallow communication between certain ports + disallow communication based on packet payload + e.g. pathnames / filenames within HTTP and FTP + e.g. email-adresses within SMTP + e.g. hostnames within DNS (www.netzzensur.de) + e.g. badwords ('sex' and 'teen' within same file) + manipulation of packet payload + everything possible... + + Limitations + somebody needs to tell client app to connect to proxy instead of server + seperate proxies for all used protocols needed + not possible to filter on packet options, etc. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Firewalling Basics +Solution 2: Proxies + + Extensions + Transparent Proxies + accept connections from client independent of dest IP + make reply packets to the client look like as sent by server + possibly to implement same transparancy towards server + no need to tell clients about proxies anymore! + + SOCKS + application protocol indepentent proxy + one proxy for all application protocols + uses seperate protocol between client and proxy + needs explicit support from client application + integrated username/password authentication + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Firewalling Basics +Comparison + + Packet Filter + pro + total control on lowest per-packet level + very high performance + possible to implement failover / load balancing + NAT as extension solves adress space problem + contra + configuration requires sophisticated knowledge + problems when no state / window tracking used + support for complex protocols (H.323, SIP) difficult to implement + Proxy + pro + no knowledge about layer3/4 protocol needed + configuration very easy + address space automatically seperated + integrates easily with other applications like IDS + easy implementation, just normal application programs + contra + seperate proxies needed for almost every protocol + bad performance + uses lots of ressources (e.g. sockets) on gatway + horribly breaks end-to-end + needs explicit configuration of client apps if not transparent proxy + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Firewalling Basics +Comparison + + Transparent Proxy + uses ideas/methods of packet filtering (NAT) to achieve protocol transparence + horrible violation of layering + + Stateful Packet Filter + uese ideas of proxies (tracking of higher layer state) to achieve better security and easieer configuration + horrible violation of layering + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Firewalling Basics +Conclusion + + Conclusion + proxies work for small installations where number of used protocols is small and administrative staff not very experienced + packet filters without state tracking are difficult to configure correctly + packet filters with state tracking are good solution for most usage scenarios: powerful but yet easy to configure correctly + for highest security, best of both worlds can be combined + imagine a stateful bridging packet filter in front of a proxy :) + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Firewalling Basics +Thanks + + Thanks to + the BBS people, Z-Netz, FIDO, ... + for heavily increasing my computer usage in 1992 + + KNF + for bringing me in touch with the internet as early as 1995 + for providing a playground for technical people + for telling me about the existance of Linux! + + Alan Cox, Alexey Kuznetsov, David Miller, Andi Kleen + for implementing (one of?) the world's best TCP/IP stacks + + Paul 'Rusty' Russell + for starting the netfilter/iptables project + for trusting me to maintain it today + + Linux User Group Nuernberg (ALIGN, LUG-N) + for helping me with my initial Linux problems + diff --git a/2002/firewalling-knf-2002/toc b/2002/firewalling-knf-2002/toc new file mode 100644 index 0000000..8df0451 --- /dev/null +++ b/2002/firewalling-knf-2002/toc @@ -0,0 +1,100 @@ +- Introduction + - since 1995 member of KNF, now 2nd TC, newsmaster + other stuff + - learned lots of stuff while playing with KNF and own networks + - done weird stuff like UUCP-over-SSL HOWTO :) + - now maintainer of linux firewalling code + +- Basics + - Internet as packet switched network + - 7-layer-OSI + - Internetworking using IP + - unreliable, best effort, no ordering guarantees + - Routing within IP + - UDP as stateless protocol + - same characteristics as IP, but + - added ports to multiplex between apps + - optional payload checksum + - TCP as session layer + - providing abstraction of connection + - reliable (payload checksum, retransmissions) + - ordering guarantees + - flow control + - ICMP as helper + - error messages / diagnostics + - absolutely neccessary !! + +- potential security problems + - spoofed packets + - connections to internal, private services + - difficult to guarantee security on all internal hosts + - restrictions the other way around (for outbound connections) + - + +- solution 1: packet filters + - operates on layer 3 + - filter packets based on packet header/content + - alternatively also generate ICMP errors, RST packets + + - extensions / derivates + - stateful firewalling + - transparent firewalls (firewalling bridges) + +- solution 2: proxies + - layer 5+ + - description + - explicit configuration of all clients + + - extensions / derivates + - transparent proxies + - SOCKS + - needs explicit application support + - solves authentication problem + - not used widely + - should be offered in addition to proxies + to give users a chance of running 'weird' prtoocols + without httptunnel. + +- comparison + - proxy + + no knowledge about protocol headers needed + + configuration extremely easy + + address space separated (no need for NAT) + + integrates easily with other applications like IDS + + easy implementation, just normal programs + - seperate proxies needed for almost every protocol + - bad performance + - uses lots of ressources (i.e. sockets) on gateway + - horribly breaks end-to-end + - needs configuration of enduser applications, if not + used as transparent proxies + + - packet filter + + total control on lowest per-packet level + + very high performance + + possible to implement failover / load balancing + + NAT as extension solves address space problem + - configuration requires high knowledge on TCP/IP protocols + - problems when no state/window tracking is done + - support for complex protocols (h.323, SIP, ...) difficult + to implement + + - transparent proxies + - use some ideas of packet filtering / NAT to achieve + transparency + + - stateful packet filters + - use some ideas of proxies (tracking of higher layer state) + to achieve better security and easier configuration + + - summary: + - proxies work for small installations where number of + to-be-supported protocols small and administrative stuff + not very experienced + - packet filters without state tracking difficult to be + configured correctly + - packet filters with state tracking are a good solution for + most usage scenarios: powerful, but yet easy to configure + right :) + - for highest security, they can be combined: imagine a + stateful bridging packet filter in front of proxies :) + diff --git a/2002/ipv6-ccc2002/ipv6-ccc2002.mgp b/2002/ipv6-ccc2002/ipv6-ccc2002.mgp new file mode 100644 index 0000000..b64103e --- /dev/null +++ b/2002/ipv6-ccc2002/ipv6-ccc2002.mgp @@ -0,0 +1,243 @@ +%include "default.mgp" +%default 1 bgrad +%deffont "typewriter" tfont "MONOTYPE.TTF" +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +%nodefault +%back "blue" + +%center +%size 7 + + +IPv6 Introduction + + +%center +%size 4 +by + +Harald Welte + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +IPv6 Introduction +What? Why? + + + What is IPv6? + + Successor of currently used IP Version 4 + Specified 1995 in RFC 2460 + + Why? + + Address space in IPv4 too small + Routing tables too large + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +IPv6 Introduction +Advantages + + + Advantages + + stateless autoconfiguration + multicast obligatory + IPsec obligatory + Mobile IP + + Address renumbering + Multihoming + Multiple address scopes + smaller routing tables through aggregatable allocation + + simplified l3 header + 64bit aligned + no checksum (l4 or l2) + no fragmentation at router + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +IPv6 Introduction +Disadvantages + + Disadvantages + Not widely deployed yet + In most cases access only possible using manual tunnel + OS support not ideal in most cases + W2k: IPv6 available from MSi + Windows XP: IPv6 included + Linux has support, but some flaws (no IPsec, ndisc not fully implemented, ...) + *BSD: full support (KAME) + Solaris: full support + Application support not ideal in most cases + not supported: postfix, current squid, inn, proftpd, + supported: bind8/9, apache, openssh, xinetd, rsync, squid-2.5(CVS), exim, zmailer, sendmail, qmail, inn-2.4(CVS), zebra + + Conclusion: Circular dependencies + no application support without OS support + no good OS support without applications + no wide deployment without applications + no applications without deployment + no deployment without applications + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +IPv6 Introduction +Deployment + + + Experimental (6bone) + Experimental 6bone (3ffe::) has been active since 1995. + Uses slightly different Addressing Architecture (RFC2471) + + Production (2001::) + Initial TLA's and sub-TLA's assigned in Sept 2000 + Mostly used in education+research + Some commercial ISP's in .de are offering production prefixes + + Why isn't IPv6 widely used yet? + No immediate need in Europe / North America + Big deployment cost at ISP's (Training, Routers, ..) + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +IPv6 Introduction +Technical: Address Space + + IP Version 6 Addressing Architecture (RFC2373) + Format prefix, variable length + 001: RFC2374 addresses, 1/8 of address space + 0000 001: Reserved for NSAP (1/128) + 0000 010: Reserved for IPX (1/128) + 1111 1110 10: link-local unicast addresses (1/1024) + 1111 1110 11: site-local unicast addresses (1/1024) + 1111 1111 flgs scop: multicast addresses + flgs (0: well-known, 1:transient) + scop (0: reserved, 1: node-local, 2: link-local, 5: site-local, 8: organization-local, e: global scope, f: reserved) + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +IPv6 Introduction +Technical: Address Space + + Aggregatable Global Unicast Address Format (RFC2374) + 3bit FP (format prefix = 001) + 13bit TLA ID - Top-Level Aggregation ID + 13bit Sub-TLA - Sub-TLA Aggergation ID + 19bit NLA - Next-Level Aggregation ID + 16bit SLA - Site-Level Aggregation ID + 64bit Interface ID - derived from 48bit ethernet MAC + Initial subTLA-Assignments + 2001:0000::/29 - 2001:01f8::/29 IANA + 2001:0200::/29 - 2001:03f8::/29 APNIC + 2001:0400::/29 - 2001:05f8::/29 ARIN + 2001:0600::/29 - 2001:07f8::/29 RIPE + loopback ::1 + unspecified: ::0 + embedded ipv4 + IPv4-compatible address: 0::xxxx:xxxx + IPv4-mapped IPv4 (IPv4 only node): 0::ffff:xxxx:xxxx + anycast + allocated from unicast addresses + only subnet-router anycast address predefined (prefix::0000) + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +IPv6 Introduction +Technical: Header + +%font "typewriter" +%size 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Version| Traffic Class | Flow Label | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Payload Length | Next Header | Hop Limit | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Source Address + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Destination Address + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +%font "standard" + 4bit Version: 6 + 8bit Traffic Class + 20bit Flow Label + 16bit Payload Length (incl. extension hdrs) + 8bit next header (same values like IPv4, RFC1700 et seq.) + 8bit hop limit (TTL) + 128bit source address + 128bit dest address + extension headers: + hop-by-hop options + routing + fragment + destination options + IPsec (AH/ESP) + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +IPv6 Introduction +Technical: Layer 2 <-> Address mapping + + + Ethernet: No more ARP, everything within ICMPv6 + No Broadcast, everything built using multicast. + + all-nodes multicast address ff02::1 + all-routers multicast address ff02::2 + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +IPv6 Introduction +Technical: Address Configuration + + + router discovery + routers periodically send router advertisements + hosts can send router solicitation to explicitly request RADV + + prefix discovery + router includes prefix(es) in ICMPv6 router advertisements + other nodes receive prefix advertisements and derive their final address from prefix + EUI64 of MAC address + + neighbour discovery + machines can discover it's neighbours without advertising router + + +%page +IPv6 Introduction +How to get connected + + In case of static IPv4 address + SIT (ipv6-in-ipv4) tunnel possible + http://www.join.uni-muenster.de/ + + In case of dynamic IPv4 address + ppp (ipv6 over ppp) tunnel (pptp, l2tp) possible + sitctrl (linux <-> linux) + atncp (*NIX), http://www.dhis.org/atncp/ + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +IPv6 Introduction +Further Reading + + http://www.ipv6-net.org/ (deutsches IPv6 forum) + http://www.6bone.net/ (ipv6 testing backbone) + http://www.freenet6.net/ (free tunnel broker) + http://hs247.com/ (list of tunnel brokers) + + http://www.bieringer.de/ (ipv6 for linux) + http://www.linux-ipv6.org/ (improved ipv6 for linux) + http://www.kame.net/ (ipv6 for *BDS) + http://www.join.uni-muenster.de/ (ipv6 at DFN/WiN) + + http://www.gnumonks.org/ (slides of this presentation) + + And of course, all relevant RFC's + diff --git a/2002/ipv6-ccc2002/topics b/2002/ipv6-ccc2002/topics new file mode 100644 index 0000000..da33a44 --- /dev/null +++ b/2002/ipv6-ccc2002/topics @@ -0,0 +1,114 @@ +What is IPv6? + Successor of currently used IP Version 4 + Specified 1995 in RFC? 2460 +Why? + Address space in IPv4 too small + +Advantages? + stateless autoconfiguration + multicast obligatorisch + IPsec obligatorisch + Mobile IP + QoS ? + + Address Renumbering? + Multihoming? + AddressScopes? + smaller routing tables through G + + simplified l3 header + 64bit aligned + no checksum (l4 or l2) + no fragmentation at router + +Disadvantages + Not widely deployed yet + In most cases access only possible using manual tunnel + OS support not ideal in most cases + W2k? + Linux has support, but no IPsec in official tree -> USAGI + *BSD: full support (KAME + Application support not ideal in most cases + not supported: + supported: bind8/9, apache + +Deployment + Experimental 6bone (3ffe::) has been active since 199x. + Uses slightly different Addressing Architecture (RFC2471) + +Why isn't it widely used yet? + No immediate need in Europe / North America + Big deployment cost at ISP's (Training, Routers, ..) + +Technical: Address Space + IP Version 6 Addressing Architecture (RFC2373) + Format prefix, variable length + 001: RFC2374 addresses, 1/8 of address space + 0000 001: Reserved for NSAP (1/128) + 0000 010: Reserved for IPX (1/128) + 1111 1110 10: link-local unicast addresses (1/1024) + 1111 1110 11: site-local unicast addresses (1/1024) + 1111 1111: multicast addresses + 1111 1111 flgs scop + flgs (0: well-known, 1:transient) + scop (0: reserved, 1: node-local, 2: link-local, 5: site-local, 8: organization-local, e: global scope, f: reserved) + Aggregatable Global Unicast Address Format (RFC2374) + 3bit FP (format prefix = 001) + 13bit TLA ID - Top-Level Aggregation ID + 13bit Sub-TLA - Sub-TLA Aggergation ID + 19bit NLA - Next-Level Aggregation ID + 16bit SLA - Site-Level Aggregation ID + 64bit Interface ID - derived from 48bit ethernet MAC + + 2001:0000::/29 - 2001:01f8::/29 IANA + 2001:0200::/29 - 2001:03f8::/29 APNIC + 2001:0400::/29 - 2001:05f8::/29 ARIN + 2001:0600::/29 - 2001:07f8::/29 RIPE + loopback + ::1 + unspecified: + ::0 + embedded ipv4 + IPv4-compatible address: 0::xxxx:xxxx + IPv4-mapped IPv4 (IPv4 only node): 0::ffff:xxxx:xxxx + anycast + allocated from unicast addresses + only subnet-router anycast address predefined (prefix::0000) + + +Technical: Header + + 4bit Version: 6 + 8bit Traffic Class + 20bit Flow Label + 16bit Payload Length (incl. extension hdrs) + 8bit next header (same values like IPv4, RF1700 et seq.) + 8bit hop limit (TTL) + 128bit source address + 128bit dest address + + extension headers: + hop-by-hop options + routing + fragment + destination options + authentication + encapsulating security payload + +Technical: Layer 2 <-> Address mapping + Ethernet: No more ARP, everything within ICMPv6 + No Broadcast, everything built using multicast. + + all-nodes multicast address ff02::1 + all-routers multicast address ff02::2 + + +Technical: Address Configuration + router discovery + routers periodically send router advertisements + hosts can send router solicitation to explicitly request RADV + prefix discovery + router includes prefix(es) in ICMPv6 router advertisements + other nodes receive prefix advertisements and derive their final address from prefix + EUI64 of MAC address + + diff --git a/2002/netfilter-bof-ols2002/abstract b/2002/netfilter-bof-ols2002/abstract new file mode 100644 index 0000000..f70cb6a --- /dev/null +++ b/2002/netfilter-bof-ols2002/abstract @@ -0,0 +1,25 @@ +Future directions of linux firewalling + +Harald Welte, netfilter core team & Astaro AG + +The Linux 2.4.x series provided a fundamental redesign of the packet filtering +and NAT framework, called netfilter/iptables. This flexible and modular +framwork still had it's limitations. This BOF will discuss the recent and +upcoming changes during the 2.4.x kernel series, as well as planned and +partially implemented changes/extensions for the 2.5.x kernel series. + +Topics covered: + +2.4.x stuff: +- The newnat API; supporting connection tracking and NAT for complex protocols + like H.323 +- Accessing connection tracking table entries from userspace: ctnetlink +- Packet filtering and even NAT on a bridge + +2.5.x stuff: +- libiptables: Providing a flexible and extensible API towards all iptables + features +- pkttables: Creating a layer-3-protocol independent layer for rule tables; + unifying iptables, ip6tables and arptables. +- nfnetlink: Move all netfilter/iptables related kernel/userspace communication + towards netlink diff --git a/2002/netfilter-curdevel-lk2002/netfilter-curdevel-lk2002.mgp b/2002/netfilter-curdevel-lk2002/netfilter-curdevel-lk2002.mgp new file mode 100644 index 0000000..987162b --- /dev/null +++ b/2002/netfilter-curdevel-lk2002/netfilter-curdevel-lk2002.mgp @@ -0,0 +1,374 @@ +%include "default.mgp" +%default 1 bgrad +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +%nodefault +%back "blue" + +%center +%size 7 + + +The future of Linux packet filtering +targeted for kernel 2.6 and beyond + + +%center +%size 4 +by + +Harald Welte + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Future of Linux packet filtering +Contents + + + Problems with current 2.4.x netfilter/iptables + Solution to code replication + Solution for dynamic rulesets + Solution for API to GUI's and other management programs + + HA for stateful firewalling + What's special about firewalling HA + Poor man's failover + Real state replication + + Other current work + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Future of Linux packet filtering +Problems with 2.4.x netfilter/iptables + + code replication between iptables/ip6tables/arptables + iptables was never meant for other protocols, but people did copy+paste 'ports' + replication of + core kernel code + layer 3 independent matches (mac, interface, ...) + userspace library (libiptc) + userspace tool (iptables) + userspace plugins (libipt_xxx.so) + + doesn't suit the needs for dynamically changing rulesets + dynamic rulesets becomming more common due (service selection, IDS) + a whole table is created in userspace and sent as blob to kernel + for every ruleset the table needs to be copied to userspace and back + inside kernel consistency checks on whole table, loop detection + + too extensible for writing any forward-compatible GUI + new extensions showing up all the time + a frontend would need to know about the options and use of a new extension + thus frontends are always incomplete and out-of-date + no high-level API other than piping to iptables-restore + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Future of Linux packet filtering +Reducing code replication + + code replication is a real problem: unclean, bugfixes missed + we need layer 3 independent layer for + submitting rules to the kernel + traversing packet-rulesets supporting match/target modules + registering matches/targets + layer 3 specific (like matching ipv4 address) + layer 3 independent (like matching MAC address) + + solution + pkt_tables inside kernel + pkt_tables_ipv4 registers layer 3 handler with pkt_tables + pkt_tables_ipv6 registers layer 3 handler with pkt_tables + everybody registering a pkt_table (like iptable_filter) needs to specify the l3 protocol + libraries in userspace (see later) + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Future of Linux packet filtering +Supporting dynamic rulesets + + atomic table-replacement turned out to be bad idea + need new interface for sending individual rules to kernel + policy routing has the same problem and good solution: rtnetlink + solution: nfnetlink + multicast-netlink based packet-orinented socket between kernel and userspace + has extra benefit that other userspace processes get notified of rule changes [just like routing daemons] + nfnetlink is a low-layer below all kernel/userspace communication + pkttnetlink [aka iptnetlink] + ctnetlink + ulog + ip_queue + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Future of Linux packet filtering +Communication with other programs + +whole set of libraries + libnfnetlink for low-layer communication + libpkttnetlink for rule modifications + will handle all plugins [which are currently part of iptables] + query functions about avaliable matches/targets + query functions about parameters + query functions for help messages about specific match/parameter of a match + generic structure from which rules can be built + conversion functions to parse generic structure into in-kernel structure + conversion functiosn to perse kernel structure into generic structure + functions to convert generic structure in plain text + libipq will stay API-compatible to current version + libipulog will stay API-compatible to current version + libiptc will go away [compatibility layer extremely difficult] + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Introduction + +What is special about firewall failover? + + Nothing, in case of the stateless packet filter + Common IP takeover solutions can be used + VRRP + Hartbeat + + Distribution of packet filtering ruleset no problem + can be done manually + or implemented with simple userspace process + + Problems arise with stateful packet filters + Connection state only on active node + NAT mappings only on active node + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Connection Tracking Subsystem + +Connection tracking... + + implemented seperately from NAT + enables stateful filtering + implementation + hooks into NF_IP_PRE_ROUTING to track packets + hooks into NF_IP_POST_ROUTING and NF_IP_LOCAL_IN to see if packet passed filtering rules + protocol modules (currently TCP/UDP/ICMP) + application helpers currently (FTP,IRC,H.323,talk,SNMP) + divides packets in the following four categories + NEW - would establish new connection + ESTABLISHED - part of already established connection + RELATED - is related to established connection + INVALID - (multicast, errors...) + does _NOT_ filter packets itself + can be utilized by iptables using the 'state' match + is used by NAT Subsystem + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Connection Tracking Subsystem + +Common structures + struct ip_conntrack_tuple, representing unidirectional flow + layer 3 src + dst + layer 4 protocol + layer 4 src + dst + + + connetions represented as struct ip_conntrack + original tuple + reply tuple + timeout + l4 state private data + app helper + app helper private data + expected connections + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Connection Tracking Subsystem + +Flow of events for new packet + packet enters NF_IP_PRE_ROUTING + tuple is derived from packet + lookup conntrack hash table with hash(tuple) -> fails + new ip_conntrack is allocated + fill in original and reply == inverted(original) tuple + initialize timer + assign app helper if applicable + see if we've been expected -> fails + call layer 4 helper 'new' function + + ... + + packet enters NF_IP_POST_ROUTING + do hashtable lookup for packet -> fails + place struct ip_conntrack in hashtable + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Connection Tracking Subsystem + +Flow of events for packet part of existing connection + packet enters NF_IP_PRE_ROUTING + tuple is derived from packet + lookup conntrack hash table with hash(tuple) + assosiate conntrack entry with skb->nfct + call l4 protocol helper 'packet' function + do l4 state tracking + update timeouts as needed [i.e. TCP TIME_WAIT,...] + + ... + + packet enters NF_IP_POST_ROUTING + do hashtable lookup for packet -> succeds + do nothing else + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Poor man's failover + +Poor man's failover + principle + let every node do it's own tracking rather than replicating state + two possible implementations + connect every node to shared media (i.e. real ethernet) + forwarding only turned on on active node + slave nodes use promiscuous mode to sniff packets + copy all traffic to slave nodes + active master needs to copy all traffic to other nodes + disadvantage: high load, sync traffic == payload traffic + IMHO stupid way of solving the problem + advantages + very easy implementation + only addition of sniffing mode to conntrack needed + existing means of address takeover can be used + same load on active master and slave nodes + no additional load on active master + disadvantages + can only be used with real shared media (no switches, ...) + can not be used with NAT + remaining problem + no initial state sync after reboot of slave node! + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Real state replication + +Parts needed + state replication protocol + multicast based + sequence numbers for detection of packet loss + NACK-based retransmission + no security, since private ethernet segment to be used + event interface on active node + calling out to callback function at all state changes + exported interface to manipulate conntrack hash table + kernel thread for sending conntrack state protocol messages + registers with event interface + creates and accumulates state replication packets + sends them via in-kernel sockets api + kernel thread for receiving conntrack state replication messages + receives state replication packets via in-kernel sockets + uses conntrack hashtable manipulation interface + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Real state replication + + Flow of events in chronological order: + on active node, inside the network RX softirq + connection tracking code is analyzing a forwarded packet + connection tracking gathers some new state information + connection tracking updates local connection tracking database + connection tracking sends event message to event API + on active node, inside the conntrack-sync kernel thread + conntrack sync daemon receives event through event API + conntrack sync daemon aggregates multiple event messages into a state replication protocol message, removing possible redundancy + conntrack sync daemon generates state replication protocol message + conntrack sync daemon sends state replication protocol message + on slave node(s), inside network RX softirq + connection tracking code ignores packets coming from the interface attached to the private conntrac sync network + state replication protocol messages is appended to socket receive queue of conntrack-sync kernel thread + on slave node(s), inside conntrack-sync kernel thread + conntrack sync daemon receives state replication message + conntrack sync daemon creates/updates conntrack entry + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Neccessary changes to kernel + +Neccessary changes to current conntrack core + + event generation (callback functions) for all state changes + + conntrack hashtable manipulation API + is needed (and already implemented) for 'ctnetlink' API + + conntrack exemptions + needed to _not_ track conntrack state replication packets + is needed for other cases as well + currently being developed by Jozsef Kadlecsik + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Other current work + + optimizing the conntrack code + hash function optimization + current hash function not good for even hash bucket count + other hash functions in development + hash function evaluation tool [cttest] avaliable + introduce per-system randomness to prevent hash attack + code optimization (locking/timers/...) + + getting our work submitted into the mainstream kernel + turns out to be more difficult + e.g. newnat api now waiting for three months + + discussions about multiple targets/actions per rule + technical implementation easy + however, not everybody convinced that it fits into the concept + + using tc for firewalling + Jamal Hadi Selim uses iptables targets from within TC + leads to discussion of generic classification engine API in kernel + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Future of Linux packet filtering +Thanks + The slides and the an according paper of this presentation are available at http://www.gnumonks.org/ + + The netfilter homepage http://www.netfilter.org/ + + Thanks to + the BBS people, Z-Netz, FIDO, ... + for heavily increasing my computer usage in 1992 + KNF + for bringing me in touch with the internet as early as 1994 + for providing a playground for technical people + for telling me about the existance of Linux! + Alan Cox, Alexey Kuznetsov, David Miller, Andi Kleen + for implementing (one of?) the world's best TCP/IP stacks + Paul 'Rusty' Russell + for starting the netfilter/iptables project + for trusting me to maintain it today + Astaro AG + for sponsoring parts of my netfilter work + diff --git a/2002/netfilter-curdevel-lsm2002/netfilter-curdevel-lsm2002.mgp b/2002/netfilter-curdevel-lsm2002/netfilter-curdevel-lsm2002.mgp new file mode 100644 index 0000000..96e12f5 --- /dev/null +++ b/2002/netfilter-curdevel-lsm2002/netfilter-curdevel-lsm2002.mgp @@ -0,0 +1,374 @@ +%include "default.mgp" +%default 1 bgrad +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +%nodefault +%back "blue" + +%center +%size 7 + + +The future of Linux packet filtering +targeted for kernel 2.6 + + +%center +%size 4 +by + +Harald Welte + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Future of Linux packet filtering +Contents + + + Problems with current 2.4.x netfilter/iptables + Solution to code replication + Solution for dynamic rulesets + Solution for API to GUI's and other management programs + + HA for stateful firewalling + What's special about firewalling HA + Poor man's failover + Real state replication + + Other current work + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Future of Linux packet filtering +Problems with 2.4.x netfilter/iptables + + code replication between iptables/ip6tables/arptables + iptables was never meant for other protocols, but people did copy+paste 'ports' + replication of + core kernel code + layer 3 independent matches (mac, interface, ...) + userspace library (libiptc) + userspace tool (iptables) + userspace plugins (libipt_xxx.so) + + doesn't suit the needs for dynamically changing rulesets + dynamic rulesets becomming more common due (service selection, IDS) + a whole table is created in userspace and sent as blob to kernel + for every ruleset the table needs to be copied to userspace and back + inside kernel consistency checks on whole table, loop detection + + too extensible for writing any forward-compatible GUI + new extensions showing up all the time + a frontend would need to know about the options and use of a new extension + thus frontends are always incomplete and out-of-date + no high-level API other than piping to iptables-restore + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Future of Linux packet filtering +Reducing code replication + + code replication is a real problem: unclean, bugfixes missed + we need layer 3 independent layer for + submitting rules to the kernel + traversing packet-rulesets supporting match/target modules + registering matches/targets + layer 3 specific (like matching ipv4 address) + layer 3 independent (like matching MAC address) + + solution + pkt_tables inside kernel + pkt_tables_ipv4 registers layer 3 handler with pkt_tables + pkt_tables_ipv6 registers layer 3 handler with pkt_tables + everybody registering a pkt_table (like iptable_filter) needs to specify the l3 protocol + libraries in userspace (see later) + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Future of Linux packet filtering +Supporting dynamic rulesets + + atomic table-replacement turned out to be bad idea + need new interface for sending individual rules to kernel + policy routing has the same problem and good solution: rtnetlink + solution: nfnetlink + multicast-netlink based packet-orinented socket between kernel and userspace + has extra benefit that other userspace processes get notified of rule changes [just like routing daemons] + nfnetlink will be low-layer below all kernel/userspace communication + pkttnetlink [aka iptnetlink] + ctnetlink + ulog + ip_queue + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Future of Linux packet filtering +Communication with other programs + +whole set of libraries + libnfnetlink for low-layer communication + libpkttnetlink for rule modifications + will handle all plugins [which are currently part of iptables] + query functions about avaliable matches/targets + query functions about parameters + query functions for help messages about specific match/parameter of a match + generic structure from which rules can be built + conversion functions to parse generic structure into in-kernel structure + conversion functiosn to perse kernel structure into generic structure + functions to convert generic structure in plain text + libipq will stay API-compatible to current version + libipulog will stay API-compatible to current version + libiptc will go away [compatibility layer extremely difficult] + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Introduction + +What is special about firewall failover? + + Nothing, in case of the stateless packet filter + Common IP takeover solutions can be used + VRRP + Hartbeat + + Distribution of packet filtering ruleset no problem + can be done manually + or implemented with simple userspace process + + Problems arise with stateful packet filters + Connection state only on active node + NAT mappings only on active node + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Connection Tracking Subsystem + +Connection tracking... + + implemented seperately from NAT + enables stateful filtering + implementation + hooks into NF_IP_PRE_ROUTING to track packets + hooks into NF_IP_POST_ROUTING and NF_IP_LOCAL_IN to see if packet passed filtering rules + protocol modules (currently TCP/UDP/ICMP) + application helpers currently (FTP,IRC,H.323,talk,SNMP) + divides packets in the following four categories + NEW - would establish new connection + ESTABLISHED - part of already established connection + RELATED - is related to established connection + INVALID - (multicast, errors...) + does _NOT_ filter packets itself + can be utilized by iptables using the 'state' match + is used by NAT Subsystem + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Connection Tracking Subsystem + +Common structures + struct ip_conntrack_tuple, representing unidirectional flow + layer 3 src + dst + layer 4 protocol + layer 4 src + dst + + + connetions represented as struct ip_conntrack + original tuple + reply tuple + timeout + l4 state private data + app helper + app helper private data + expected connections + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Connection Tracking Subsystem + +Flow of events for new packet + packet enters NF_IP_PRE_ROUTING + tuple is derived from packet + lookup conntrack hash table with hash(tuple) -> fails + new ip_conntrack is allocated + fill in original and reply == inverted(original) tuple + initialize timer + assign app helper if applicable + see if we've been expected -> fails + call layer 4 helper 'new' function + + ... + + packet enters NF_IP_POST_ROUTING + do hashtable lookup for packet -> fails + place struct ip_conntrack in hashtable + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Connection Tracking Subsystem + +Flow of events for packet part of existing connection + packet enters NF_IP_PRE_ROUTING + tuple is derived from packet + lookup conntrack hash table with hash(tuple) + assosiate conntrack entry with skb->nfct + call l4 protocol helper 'packet' function + do l4 state tracking + update timeouts as needed [i.e. TCP TIME_WAIT,...] + + ... + + packet enters NF_IP_POST_ROUTING + do hashtable lookup for packet -> succeds + do nothing else + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Poor man's failover + +Poor man's failover + principle + let every node do it's own tracking rather than replicating state + two possible implementations + connect every node to shared media (i.e. real ethernet) + forwarding only turned on on active node + slave nodes use promiscuous mode to sniff packets + copy all traffic to slave nodes + active master needs to copy all traffic to other nodes + disadvantage: high load, sync traffic == payload traffic + IMHO stupid way of solving the problem + advantages + very easy implementation + only addition of sniffing mode to conntrack needed + existing means of address takeover can be used + same load on active master and slave nodes + no additional load on active master + disadvantages + can only be used with real shared media (no switches, ...) + can not be used with NAT + remaining problem + no initial state sync after reboot of slave node! + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Real state replication + +Parts needed + state replication protocol + multicast based + sequence numbers for detection of packet loss + NACK-based retransmission + no security, since private ethernet segment to be used + event interface on active node + calling out to callback function at all state changes + exported interface to manipulate conntrack hash table + kernel thread for sending conntrack state protocol messages + registers with event interface + creates and accumulates state replication packets + sends them via in-kernel sockets api + kernel thread for receiving conntrack state replication messages + receives state replication packets via in-kernel sockets + uses conntrack hashtable manipulation interface + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Real state replication + + Flow of events in chronological order: + on active node, inside the network RX softirq + connection tracking code is analyzing a forwarded packet + connection tracking gathers some new state information + connection tracking updates local connection tracking database + connection tracking sends event message to event API + on active node, inside the conntrack-sync kernel thread + conntrack sync daemon receives event through event API + conntrack sync daemon aggregates multiple event messages into a state replication protocol message, removing possible redundancy + conntrack sync daemon generates state replication protocol message + conntrack sync daemon sends state replication protocol message + on slave node(s), inside network RX softirq + connection tracking code ignores packets coming from the interface attached to the private conntrac sync network + state replication protocol messages is appended to socket receive queue of conntrack-sync kernel thread + on slave node(s), inside conntrack-sync kernel thread + conntrack sync daemon receives state replication message + conntrack sync daemon creates/updates conntrack entry + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Neccessary changes to kernel + +Neccessary changes to current conntrack core + + event generation (callback functions) for all state changes + + conntrack hashtable manipulation API + is needed (and already implemented) for 'ctnetlink' API + + conntrack exemptions + needed to _not_ track conntrack state replication packets + is needed for other cases as well + currently being developed by Jozsef Kadlecsik + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Other current work + + optimizing the conntrack code + hash function optimization + current hash function not good for even hash bucket count + other hash functions in development + hash function evaluation tool [cttest] avaliable + introduce per-system randomness to prevent hash attack + code optimization (locking/timers/...) + + getting our work submitted into the mainstream kernel + turns out to be more difficult + e.g. newnat api now waiting for three months + + discussions about multiple targets/actions per rule + technical implementation easy + however, not everybody convinced that it fits into the concept + + using tc for firewalling + Jamal Hadi Selim uses iptables targets from within TC + leads to discussion of generic classification engine API in kernel + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Future of Linux packet filtering +Thanks + The slides and the an according paper of this presentation are available at http://www.gnumonks.org/ + + The netfilter homepage http://www.netfilter.org/ + + Thanks to + the BBS people, Z-Netz, FIDO, ... + for heavily increasing my computer usage in 1992 + KNF + for bringing me in touch with the internet as early as 1994 + for providing a playground for technical people + for telling me about the existance of Linux! + Alan Cox, Alexey Kuznetsov, David Miller, Andi Kleen + for implementing (one of?) the world's best TCP/IP stacks + Paul 'Rusty' Russell + for starting the netfilter/iptables project + for trusting me to maintain it today + Astaro AG + for sponsoring parts of my netfilter work + diff --git a/2002/netfilter-failover-ols2002/abstract b/2002/netfilter-failover-ols2002/abstract new file mode 100644 index 0000000..9cd4ef3 --- /dev/null +++ b/2002/netfilter-failover-ols2002/abstract @@ -0,0 +1,31 @@ +How to replicate the fire - HA for netfilter based firewalls. + + With traditional, stateless firewalling (such as ipfwadm, ipchains) there is +no need for special HA support in the firewalling subsystem. As long as all +packet filtering rules and routing table entries are configured in exactly the +same way, one can use any available tool for IP-Address takeover to accomplish +the goal of failing over from one node to the other. + + With Linux 2.4.x netfilter/iptables, the Linux firewalling code moves beyond +traditional packet filtering. Netfilter provides a modular connection tracking +susbsystem which can be employed for stateful firewalling. The connection +tracking subsystem gathers information about the state of all current network +flows (connections). Packet filtering decisions and NAT information is +associated with this state information. + + In a high availability scenario, this connection tracking state needs to be +replicated from the currently active firewall node to all standby slave +firewall nodes. Only when all connection tracking state is replicated, the +slave node will have all necessarry state information at the time a failover +event occurs. + + The netfilter/iptables does currently not have any functionality for +replicating connection tracking state accross multiple nodes. However, +the author of this presentation, Harald Welte, has started a project for +connection tracking state replication with netfilter/iptables. + + The presentation will cover the architectural design and implementation +of the connection tracking failover sytem. With respect to the date of +the conference, it is to be expected that the project is still a +work-in-progress at that time. + diff --git a/2002/netfilter-failover-ols2002/biography b/2002/netfilter-failover-ols2002/biography new file mode 100644 index 0000000..27b77bd --- /dev/null +++ b/2002/netfilter-failover-ols2002/biography @@ -0,0 +1,22 @@ + Harald Welte is one +of the five netfilter/iptables core +team members, and the current Linux 2.4.x firewalling maintainer. + + His main interest in computing has always been networking. In the few time +left besides netfilter/iptables related work, he's writing obscure documents +like the UUCP +over SSL HOWTO. Other kernel-related projects he has been contributing are +user mode linux and the international (crypto) kernel patch. + + In the past he has been working as an independent IT Consultant working on +closed-source projecst for various companies ranging from banks to +manufacturers of networking gear. During the year 2001 he was living in +Curitiba (Brazil), where he got sponsored for his Linux related work by +Conectiva Inc.. + + Starting with February 2002, Harald has been contracted part-time by +Astaro AG, who are sponsoring him for his +current netfilter/iptables work. + + Harald is living in Erlangen, Germany. + diff --git a/2002/netfilter-failover-ols2002/netfilter-failover-ols2002.mgp b/2002/netfilter-failover-ols2002/netfilter-failover-ols2002.mgp new file mode 100644 index 0000000..468d974 --- /dev/null +++ b/2002/netfilter-failover-ols2002/netfilter-failover-ols2002.mgp @@ -0,0 +1,294 @@ +%include "default.mgp" +%default 1 bgrad +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +%nodefault +%back "blue" + +%center +%size 7 + + +How to replicate the fire +HA for netfilter-based firewalls + + +%center +%size 4 +by + +Harald Welte + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Contents + + + Introduction + Connection Tracking Subsystem + Packet selection based on IP Tables + The Connection Tracking Subsystem + The NAT Subsystem + Poor man's failover + Real state replication + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Introduction + +What is special about firewall failover? + + Nothing, in case of the stateless packet filter + Common IP takeover solutions can be used + VRRP + Hartbeat + + Distribution of packet filtering ruleset no problem + can be done manually + or implemented with simple userspace process + + Problems arise with stateful packet filters + Connection state only on active node + NAT mappings only on active node + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Connection Tracking Subsystem + +Connection tracking... + + implemented seperately from NAT + enables stateful filtering + implementation + hooks into NF_IP_PRE_ROUTING to track packets + hooks into NF_IP_POST_ROUTING and NF_IP_LOCAL_IN to see if packet passed filtering rules + protocol modules (currently TCP/UDP/ICMP) + application helpers currently (FTP,IRC,H.323,talk,SNMP) + divides packets in the following four categories + NEW - would establish new connection + ESTABLISHED - part of already established connection + RELATED - is related to established connection + INVALID - (multicast, errors...) + does _NOT_ filter packets itself + can be utilized by iptables using the 'state' match + is used by NAT Subsystem + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Connection Tracking Subsystem + +Common structures + struct ip_conntrack_tuple, representing unidirectional flow + layer 3 src + dst + layer 4 protocol + layer 4 src + dst + + + connetions represented as struct ip_conntrack + original tuple + reply tuple + timeout + l4 state private data + app helper + app helper private data + expected connections + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Connection Tracking Subsystem + +Flow of events for new packet + packet enters NF_IP_PRE_ROUTING + tuple is derived from packet + lookup conntrack hash table with hash(tuple) -> fails + new ip_conntrack is allocated + fill in original and reply == inverted(original) tuple + initialize timer + assign app helper if applicable + see if we've been expected -> fails + call layer 4 helper 'new' function + + ... + + packet enters NF_IP_POST_ROUTING + do hashtable lookup for packet -> fails + place struct ip_conntrack in hashtable + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Connection Tracking Subsystem + +Flow of events for packet part of existing connection + packet enters NF_IP_PRE_ROUTING + tuple is derived from packet + lookup conntrack hash table with hash(tuple) + assosiate conntrack entry with skb->nfct + call l4 protocol helper 'packet' function + do l4 state tracking + update timeouts as needed [i.e. TCP TIME_WAIT,...] + + ... + + packet enters NF_IP_POST_ROUTING + do hashtable lookup for packet -> succeds + do nothing else + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Network Address Translation + +Overview + Previous Linux Kernels only implemented one special case of NAT: Masquerading + Linux 2.4.x can do any kind of NAT. + NAT subsystem implemented on top of netfilter, iptables and conntrack + NAT subsystem registers with all five netfilter hooks + 'nat' Table registers chains PREROUTING, POSTROUTING and OUTPUT + Following targets available within 'nat' Table + SNAT changes the packet's source whille passing NF_IP_POST_ROUTING + DNAT changes the packet's destination while passing NF_IP_PRE_ROUTING + MASQUERADE is a special case of SNAT + REDIRECT is a special case of DNAT + NAT bindings determined only for NEW packet and saved in ip_conntrack + Further packets within connection NATed according NAT bindings + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Poor man's failover + +Poor man's failover + principle + let every node do it's own tracking rather than replicating state + two possible implementations + connect every node to shared media (i.e. real ethernet) + forwarding only turned on on active node + slave nodes use promiscuous mode to sniff packets + copy all traffic to slave nodes + active master needs to copy all traffic to other nodes + disadvantage: high load, sync traffic == payload traffic + IMHO stupid way of solving the problem + advantages + very easy implementation + only addition of sniffing mode to conntrack needed + existing means of address takeover can be used + same load on active master and slave nodes + no additional load on active master + disadvantages + can only be used with real shared media (no switches, ...) + can not be used with NAT + remaining problem + no initial state sync after reboot of slave node! + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Real state replication + +Parts needed + state replication protocol + multicast based + sequence numbers for detection of packet loss + NACK-based retransmission + no security, since private ethernet segment to be used + event interface on active node + calling out to callback function at all state changes + exported interface to manipulate conntrack hash table + kernel thread for sending conntrack state protocol messages + registers with event interface + creates and accumulates state replication packets + sends them via in-kernel sockets api + kernel thread for receiving conntrack state replication messages + receives state replication packets via in-kernel sockets + uses conntrack hashtable manipulation interface + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Real state replication + + Flow of events in chronological order: + on active node, inside the network RX softirq + connection tracking code is analyzing a forwarded packet + connection tracking gathers some new state information + connection tracking updates local connection tracking database + connection tracking sends event message to event API + on active node, inside the conntrack-sync kernel thread + conntrack sync daemon receives event through event API + conntrack sync daemon aggregates multiple event messages into a state replication protocol message, removing possible redundancy + conntrack sync daemon generates state replication protocol message + conntrack sync daemon sends state replication protocol message + on slave node(s), inside network RX softirq + connection tracking code ignores packets coming from the interface attached to the private conntrac sync network + state replication protocol messages is appended to socket receive queue of conntrack-sync kernel thread + on slave node(s), inside conntrack-sync kernel thread + conntrack sync daemon receives state replication message + conntrack sync daemon creates/updates conntrack entry + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Neccessary changes to kernel + +Neccessary changes to current conntrack core + + event generation (callback functions) for all state changes + + conntrack hashtable manipulation API + is needed (and already implemented) for 'ctnetlink' API + + conntrack exemptions + needed to _not_ track conntrack state replication packets + is needed for other cases as well + currently being developed by Jozsef Kadlecsik + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Thanks + + Thanks to + the BBS people, Z-Netz, FIDO, ... + for heavily increasing my computer usage in 1992 + + KNF + for bringing me in touch with the internet as early as 1994 + for providing a playground for technical people + for telling me about the existance of Linux! + + Alan Cox, Alexey Kuznetsov, David Miller, Andi Kleen + for implementing (one of?) the world's best TCP/IP stacks + + Paul 'Rusty' Russell + for starting the netfilter/iptables project + for trusting me to maintain it today + + Astaro AG + for sponsoring parts of my netfilter work + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Availability of slides / Links + +The slides and the an according paper of this presentation are available at + http://www.gnumonks.org/ + +The netfilter homepage + http://www.netfilter.org/ + diff --git a/2002/netfilter-failover-ols2002/netfilter-failover-ols2002.tex b/2002/netfilter-failover-ols2002/netfilter-failover-ols2002.tex new file mode 100644 index 0000000..bf8d142 --- /dev/null +++ b/2002/netfilter-failover-ols2002/netfilter-failover-ols2002.tex @@ -0,0 +1,504 @@ +\documentclass[twocolumn]{article} +\usepackage{ols} +\begin{document} + +\date{} + +\title{\Large \bf How to replicate the fire - HA for netfilter based firewalls} + +\author{ +Harald Welte\\ +{\em Netfilter Core Team + Astaro AG}\\ +{\normalsize laforge@gnumonks.org/laforge@astaro.com, http://www.gnumonks.org/} +} + +\maketitle + +\thispagestyle{empty} + +\subsection*{Abstract} + With traditional, stateless firewalling (such as ipfwadm, ipchains) there is +no need for special HA support in the firewalling subsystem. As long as all +packet filtering rules and routing table entries are configured in exactly the +same way, one can use any available tool for IP-Address takeover to accomplish +the goal of failing over from one node to the other. + + With Linux 2.4.x netfilter/iptables, the Linux firewalling code moves beyond +traditional packet filtering. Netfilter provides a modular connection tracking +susbsystem which can be employed for stateful firewalling. The connection +tracking subsystem gathers information about the state of all current network +flows (connections). Packet filtering decisions and NAT information is +associated with this state information. + + In a high availability scenario, this connection tracking state needs to be +replicated from the currently active firewall node to all standby slave +firewall nodes. Only when all connection tracking state is replicated, the +slave node will have all necessarry state information at the time a failover +event occurs. + + The netfilter/iptables does currently not have any functionality for +replicating connection tracking state accross multiple nodes. However, +the author of this presentation, Harald Welte, has started a project for +connection tracking state replication with netfilter/iptables. + + The presentation will cover the architectural design and implementation +of the connection tracking failover sytem. With respect to the date of +the conference, it is to be expected that the project is still a +work-in-progress at that time. + +\section{Failover of stateless firewalls} + +There are no special precautions when installing a highly available +stateless packet filter. Since there is no state kept, all information +needed for filtering is the ruleset and the individual, seperate packets. + +Building a set of highly available stateless packet filters can thus be +achieved by using any traditional means of IP-address takeover, such +as Hartbeat or VRRPd. + +The only remaining issue is to make sure the firewalling ruleset is +exactly the same on both machines. This should be ensured by the firewall +administrator every time he updates the ruleset. + +If this is not applicable, because a very dynamic ruleset is employed, one +can build a very easy solution using iptables-supplied tools iptables-save +and iptables-restore. The output of iptables-save can be piped over ssh +to iptables-restore on a different host. + +Limitations +\begin{itemize} +\item +no state tracking +\item +not possible in combination with NAT +\item +no counter consistency of per-rule packet/byte counters +\end{itemize} + +\section{Failover of stateful firewalls} + +Modern firewalls implement state tracking (aka connection tracking) in order +to keep some state about the currently active sessions. The amount of +per-connection state kept at the firewall depends on the particular +implementation. + +As soon as {\bf any} state is kept at the packet filter, this state information +needs to be replicated to the slave/backup nodes within the failover setup. + +In Linux 2.4.x, all relevant state is kept within the {\it connection tracking +subsystem}. In order to understand how this state could possibly be +replicated, we need to understand the architecture of this conntrack subsystem. + +\subsection{Architecture of the Linux Connection Tracking Subsystem} + +Connection tracking within Linux is implemented as a netfilter module, called +ip\_conntrack.o. + +Before describing the connection tracking subsystem, we need to describe a +couple of definitions and primitives used throughout the conntrack code. + +A connection is represented within the conntrack subsystem using {\it struct +ip\_conntrack}, also called {\it connection tracking entry}. + +Connection tracking is utilizing {\it conntrack tuples}, which are tuples +consisting out of (srcip, srcport, dstip, dstport, l4prot). A connection is +uniquely identified by two tuples: The tuple in the original direction +(IP\_CT\_DIR\_ORIGINAL) and the tuple for the reply direction +(IP\_CT\_DIR\_REPLY). + +Connection tracking itself does not drop packets\footnote{well, in some rare +cases in combination with NAT it needs to drop. But don't tell anyone, this is +secret.} or impose any policy. It just associates every packet with a +connection tracking entry, which in turn has a particular state. All other +kernel code can use this state information\footnote{state information is +internally represented via the {\it struct sk\_buff.nfct} structure member of a +packet.}. + +\subsubsection{Integration of conntrack with netfilter} + +If the ip\_conntrack.o module is registered with netfilter, it attaches to the +NF\_IP\_PRE\_ROUTING, NF\_IP\_POST\_ROUTING, NF\_IP\_LOCAL\_IN and +NF\_IP\_LOCAL\_OUT hooks. + +Because forwarded packets are the most common case on firewalls, I will only +describe how connection tracking works for forwarded packets. The two relevant +hooks for forwarded packets are NF\_IP\_PRE\_ROUTING and NF\_IP\_POST\_ROUTING. + +Every time a packet arrives at the NF\_IP\_PRE\_ROUTING hook, connection +tracking creates a conntrack tuple from the packet. It then compares this +tuple to the original and reply tuples of all already-seen connections +\footnote{Of course this is not implemented as a linear search over all existing connections.} to find out if this just-arrived packet belongs to any existing +connection. If there is no match, a new conntrack table entry (struct +ip\_conntrack) is created. + +Let's assume the case where we have already existing connections but are +starting from scratch. + +The first packet comes in, we derive the tuple from the packet headers, look up +the conntrack hash table, don't find any matching entry. As a result, we +create a new struct ip\_conntrack. This struct ip\_conntrack is filled with +all necessarry data, like the original and reply tuple of the connection. +How do we know the reply tuple? By inverting the source and destination +parts of the original tuple.\footnote{So why do we need two tuples, if they can +be derived from each other? Wait until we discuss NAT.} +Please note that this new struct ip\_conntrack is {\bf not} yet placed +into the conntrack hash table. + +The packet is now passed on to other callback functions which have registered +with a lower priority at NF\_IP\_PRE\_ROUTING. It then continues traversal of +the network stack as usual, including all respective netfilter hooks. + +If the packet survives (i.e. is not dropped by the routing code, network stack, +firewall ruleset, ...), it re-appears at NF\_IP\_POST\_ROUTING. In this case, +we can now safely assume that this packet will be sent off on the outgoing +interface, and thus put the connection tracking entry which we created at +NF\_IP\_PRE\_ROUTING into the conntrack hash table. This process is called +{\it confirming the conntrack}. + +The connection tracking code itself is not monolithic, but consists out of a +couple of seperate modules\footnote{They don't actually have to be seperate +kernel modules; e.g. TCP, UDP and ICMP tracking modules are all part of +the linux kernel module ip\_conntrack.o}. Besides the conntrack core, there +are two important kind of modules: Protocol helpers and application helpers. + +Protocol helpers implement the layer-4-protocol specific parts. They currently +exist for TCP, UDP and ICMP (an experimental helper for GRE exists). + +\subsubsection{TCP connection tracking} + +As TCP is a connection oriented protocol, it is not very difficult to imagine +how conntection tracking for this protocol could work. There are well-defined +state transitions possible, and conntrack can decide which state transitions +are valid within the TCP specification. In reality it's not all that easy, +since we cannot assume that all packets that pass the packet filter actually +arrive at the receiving end, ... + +It is noteworthy that the standard connection tracking code does {\bf not} +do TCP sequence number and window tracking. A well-maintained patch to add +this feature exists almost as long as connection tracking itself. It will +be integrated with the 2.5.x kernel. The problem with window tracking is +it's bad interaction with connection pickup. The TCP conntrack code is able to +pick up already existing connections, e.g. in case your firewall was rebooted. +However, connection pickup is conflicting with TCP window tracking: The TCP +window scaling option is only transferred at connection setup time, and we +don't know about it in case of pickup... + +\subsubsection{ICMP tracking} + +ICMP is not really a connection oriented protocol. So how is it possible to +do connection tracking for ICMP? + +The ICMP protocol can be split in two groups of messages + +\begin{itemize} +\item +ICMP error messages, which sort-of belong to a different connection +ICMP error messages are associated {\it RELATED} to a different connection. +(ICMP\_DEST\_UNREACH, ICMP\_SOURCE\_QUENCH, ICMP\_TIME\_EXCEEDED, +ICMP\_PARAMETERPROB, ICMP\_REDIRECT). +\item +ICMP queries, which have a request->reply character. So what the conntrack +code does, is let the request have a state of {\it NEW}, and the reply +{\it ESTABLISHED}. The reply closes the connection immediately. +(ICMP\_ECHO, ICMP\_TIMESTAMP, ICMP\_INFO\_REQUEST, ICMP\_ADDRESS) +\end{itemize} + +\subsubsection{UDP connection tracking} + +UDP is designed as a connectionless datagram protocol. But most common +protocols using UDP as layer 4 protocol have bi-directional UDP communication. +Imagine a DNS query, where the client sends an UDP frame to port 53 of the +nameserver, and the nameserver sends back a DNS reply packet from it's UDP +port 53 to the client. + +Netfilter trats this as a connection. The first packet (the DNS request) is +assigned a state of {\it NEW}, because the packet is expected to create a new +'connection'. The dns servers' reply packet is marked as {\it ESTABLISHED}. + +\subsubsection{conntrack application helpers} + +More complex application protocols involving multiple connections need special +support by a so-called ``conntrack application helper module''. Modules in +the stock kernel come for FTP and IRC(DCC). Netfilter CVS currently contains +patches for PPTP, H.323, Eggdrop botnet, tftp ald talk. We're still lacking +a lot of protocols (e.g. SIP, SMB/CIFS) - but they are unlikely to appear +until somebody really needs them and either develops them on his own or +funds development. + +\subsubsection{Integration of connection tracking with iptables} + +As stated earlier, conntrack doesn't impose any policy on packets. It just +determines the relation of a packet to already existing connections. To base +packet filtering decision on this sate information, the iptables {\it state} +match can be used. Every packet is within one of the following categories: + +\begin{itemize} +\item +{\bf NEW}: packet would create a new connection, if it survives +\item +{\bf ESTABLISHED}: packet is part of an already established connection +(either direction) +\item +{\bf RELATED}: packet is in some way related to an already established connection, e.g. ICMP errors or FTP data sessions +\item +{\bf INVALID}: conntrack is unable to derive conntrack information from this packet. Please note that all multicast or broadcast packets fall in this category. +\end{itemize} + + +\subsection{Poor man's conntrack failover} + +When thinking about failover of stateful firewalls, one usually thinks about +replication of state. This presumes that the state is gathered at one +firewalling node (the currently active node), and replicated to several other +passive standby nodes. There is, howeve, a very different approach to +replication: concurrent state tracking on all firewalling nodes. + +The basic assumption of this approach is: In a setup where all firewalling +nodes receive exactly the same traffic, all nodes will deduct the same state +information. + +The implementability of this approach is totally dependent on fulfillment of +this assumption. + +\begin{itemize} +\item +{\it All packets need to be seen by all nodes}. This is not always true, but +can be achieved by using shared media like traditional ethernet (no switches!!) +and promiscuous mode on all ethernet interfaces. +\item +{\it All nodes need to be able to process all packets}. This cannot be +universally guaranteed. Even if the hardware (CPU, RAM, Chipset, NIC's) and +software (Linux kernel) are exactly the same, they might behave different, +especially under high load. To avoid those effects, the hardware should be +able to deal with way more traffic than seen during operation. Also, there +should be no userspace processes (like proxes, etc.) running on the firewalling +nodes at all. WARNING: Nobody guarantees this behaviour. However, the poor +man is usually not interested in scientific proof but in usability in his +particular practical setup. +\end{itemize} + +However, even if those conditions are fulfilled, ther are remaining issues: +\begin{itemize} +\item +{\it No resynchronization after reboot}. If a node is rebooted (because of +a hardware fault, software bug, software update, ..) it will loose all state +information until the event of the reboot. This means, the state information +of this node after reboot will not contain any old state, gathered before the +reboot. The effect depend on the traffic. Generally, it is only assured that +state information about all connections initiated after the reboot will be +present. If there are short-lived connections (like http), the state +information on the just rebooted node will approximate the state information of +an older node. Only after all sessions active at the time of reboot have +terminated, state information is guaranteed to be resynchronized. +\item +{\it Only possible with shared medium}. The practical implication is that no +switched ethernet (and thus no full duplex) can be used. +\end{itemize} + +The major advantage of the poor man's approach is implementation simplicity. +No state transfer mechanism needs to be developed. Only very little changes +to the existing conntrack code would be needed in order to be able to +do tracking based on packets received from promiscuous interfaces. The active +node would have packet forwarding turned on, the passive nodes off. + +I'm not proposing this as a real solution to the failover problem. It's +hackish, buggy and likely to break very easily. But considering it can be +implemented in very little programming time, it could be an option for very +small installations with low reliability criteria. + +\subsection{Conntrack state replication} + +The preferred solution to the failover problem is, without any doubt, +replication of the connection tracking state. + +The proposed conntrack state replication soltution consists out of several +parts: +\begin{itemize} +\item +A connection tracking state replication protocol +\item +An event interface generating event messages as soon as state information +changes on the active node +\item +An interface for explicit generation of connection tracking table entries on +the standby slaves +\item +Some code (preferrably a kernel thread) running on the active node, receiving +state updates by the event interface and generating conntrack state replication +protocol messages +\item +Some code (preferrably a kernel thread) running on the slave node(s), receiving +conntrack state replication protocol messages and updating the local conntrack +table accordingly +\end{itemize} + +Flow of events in chronological order: +\begin{itemize} +\item +{\it on active node, inside the network RX softirq} +\begin{itemize} +\item + connection tracking code is analyzing a forwarded packet +\item + connection tracking gathers some new state information +\item + connection tracking updates local connection tracking database +\item + connection tracking sends event message to event API +\end{itemize} +\item +{\it on active node, inside the conntrack-sync kernel thread} + \begin{itemize} + \item + conntrack sync daemon receives event through event API + \item + conntrack sync daemon aggregates multiple event messages into a state replication protocol message, removing possible redundancy + \item + conntrack sync daemon generates state replication protocol message + \item + conntrack sync daemon sends state replication protocol message +(private network between firewall nodes) + \end{itemize} +\item +{\it on slave node(s), inside network RX softirq} + \begin{itemize} + \item + connection tracking code ignores packets coming from the interface attached to the private conntrac sync network + \item + state replication protocol messages is appended to socket receive queue of conntrack-sync kernel thread + \end{itemize} +\item +{\it on slave node(s), inside conntrack-sync kernel thread} + \begin{itemize} + \item + conntrack sync daemon receives state replication message + \item + conntrack sync daemon creates/updates conntrack entry + \end{itemize} +\end{itemize} + + +\subsubsection{Connection tracking state replication protocol} + + + In order to be able to replicate the state between two or more firewalls, a +state replication protocol is needed. This protocol is used over a private +network segment shared by all nodes for state replication. It is designed to +work over IP unicast and IP multicast transport. IP unicast will be used for +direct point-to-point communication between one active firewall and one +standby firewall. IP multicast will be used when the state needs to be +replicated to more than one standby firewall. + + + The principle design criteria of this protocol are: +\begin{itemize} +\item + {\bf reliable against data loss}, as the underlying UDP layer does only + provide checksumming against data corruption, but doesn't employ any + means against data loss +\item + {\bf lightweight}, since generating the state update messages is + already a very expensive process for the sender, eating additional CPU, + memory and IO bandwith. +\item + {\bf easy to parse}, to minimize overhead at the receiver(s) +\end{itemize} + +The protocol does not employ any security mechanism like encryption, +authentication or reliability against spoofing attacks. It is +assumed that the private conntrack sync network is a secure communications +channel, not accessible to any malicious 3rd party. + +To achieve the reliability against data loss, an easy sequence numbering +scheme is used. All protocol messages are prefixed by a seuqence number, +determined by the sender. If the slave detects packet loss by discontinuous +sequence numbers, it can request the retransmission of the missing packets +by stating the missing sequence number(s). Since there is no acknowledgement +for sucessfully received packets, the sender has to keep a reasonably-sized +backlog of recently-sent packets in order to be able to fulfill retransmission +requests. + +The different state replication protocol messages types are: +\begin{itemize} +\item +{\bf NF\_CTSRP\_NEW}: New conntrack entry has been created (and +confirmed\footnote{See the above description of the conntrack code for what is +meant by {\it confirming} a conntrack entry}) +\item +{\bf NF\_CTSRP\_UPDATE}: State information of existing conntrack entry has +changed +\item +{\bf NF\_CTSRP\_EXPIRE}: Existing conntrack entry has been expired +\end{itemize} + +To uniquely identify (and later reference) a conntrack entry, a +{\it conntrack\_id} is assigned to every conntrack entry transferred +using a NF\_CTSRP\_NEW message. This conntrack\_id must be saved at the +receiver(s) together with the conntrack entry, since it is used by the sender +for subsequent NF\_CTSRP\_UPDATE and NF\_CTSRP\_EXPIRE messages. + +The protocol itself does not care about the source of this conntrack\_id, +but since the current netfilter connection tracking implementation does never +change the addres of a conntrack entry, the memory address of the entry can be +used, since it comes for free. + + +\subsubsection{Connection tracking state syncronization sender} + +Maximum care needs to be taken for the implementation of the ctsyncd sender. + +The normal workload of the active firewall node is likely to be already very +high, so generating and sending the conntrack state replication messages needs +to be highly efficient. + +\begin{itemize} +\item + {\bf NF\_CTSRP\_NEW} will be generated at the NF\_IP\_POST\_ROUTING + hook, at the time ip\_conntrack\_confirm() is called. Delaying + this message until conntrack confirmation happens saves us from + replicating otherwise unneeded state information. +\item + {\bf NF\_CTSRP\_UPDATE} need to be created automagically by the + conntrack core. It is not possible to have any failover-specific + code within conntrack protocol and/or application helpers. + The easiest way involving the least changes to the conntrack core + code is to copy parts of the conntrack entry before calling any + helper functions, and then use memcmp() to find out if the helper + has changed any information. +\item + {\bf NF\_CTSRP\_EXPIRE} can be added very easily to the existing + conntrack destroy function. +\end{itemize} + + +\subsubsection{Connection tracking state syncronization receiver} + +Impmentation of the receiver is very straightforward. + +Apart from dealing with lost CTSRP packets, it just needs to call the +respective conntrack add/modify/delete functions offered by the core. + + +\subsubsection{Necessary changes within netfilter conntrack core} + +To be able to implement the described conntrack state replication mechanism, +the following changes to the conntrack core are needed: +\begin{itemize} +\item + Ability to exclude certain packets from being tracked. This is a + long-wanted feature on the TODO list of the netfilter project and will + be implemented by having a ``prestate'' table in combination with a + ``NOTRACK'' target. +\item + Ability to register callback functions to be called every time a new + conntrack entry is created or an existing entry modified. +\item + Export an API to add externally add, modify and remove conntrack + entries. Since the needed ip\_conntrack\_lock is exported, + implementation could even reside outside the conntrack core code. +\end{itemize} + +Since the number of changes is very low, it is very likely that the +modifications will go into the mainstream kernel without any big hazzle. + +\end{document} diff --git a/2002/netfilter-failover-ols2002/ols.sty b/2002/netfilter-failover-ols2002/ols.sty new file mode 100644 index 0000000..5e5fe49 --- /dev/null +++ b/2002/netfilter-failover-ols2002/ols.sty @@ -0,0 +1,56 @@ + +% TEMPLATE for Usenix papers, specifically to meet requirements of +% TCL97 committee. +% originally a template for producing IEEE-format articles using LaTeX. +% written by Matthew Ward, CS Department, Worcester Polytechnic Institute. +% adapted by David Beazley for his excellent SWIG paper in Proceedings, +% Tcl 96 +% turned into a smartass generic template by De Clarke, with thanks to +% both the above pioneers +% use at your own risk. Complaints to /dev/null. +% make it two column with no page numbering, default is 10 point + +% adapted for Ottawa Linux Symposium + +% include following in document. +%\documentclass[twocolumn]{article} +%\usepackage{usits,epsfig} +\pagestyle{empty} + +%set dimensions of columns, gap between columns, and space between paragraphs +%\setlength{\textheight}{8.75in} +\setlength{\textheight}{9.0in} +\setlength{\columnsep}{0.25in} +\setlength{\textwidth}{6.45in} +\setlength{\footskip}{0.0in} +\setlength{\topmargin}{0.0in} +\setlength{\headheight}{0.0in} +\setlength{\headsep}{0.0in} +\setlength{\oddsidemargin}{0in} +%\setlength{\oddsidemargin}{-.065in} +%\setlength{\oddsidemargin}{-.17in} +\setlength{\parindent}{0pc} +\setlength{\parskip}{\baselineskip} + +% started out with art10.sty and modified params to conform to IEEE format +% further mods to conform to Usenix standard + +\makeatletter +%as Latex considers descenders in its calculation of interline spacing, +%to get 12 point spacing for normalsize text, must set it to 10 points +\def\@normalsize{\@setsize\normalsize{12pt}\xpt\@xpt +\abovedisplayskip 10pt plus2pt minus5pt\belowdisplayskip \abovedisplayskip +\abovedisplayshortskip \z@ plus3pt\belowdisplayshortskip 6pt plus3pt +minus3pt\let\@listi\@listI} + +%need a 12 pt font size for subsection and abstract headings +\def\subsize{\@setsize\subsize{12pt}\xipt\@xipt} + +%make section titles bold and 12 point, 2 blank lines before, 1 after +\def\section{\@startsection {section}{1}{\z@}{24pt plus 2pt minus 2pt} +{12pt plus 2pt minus 2pt}{\large\bf}} + +%make subsection titles bold and 11 point, 1 blank line before, 1 after +\def\subsection{\@startsection {subsection}{2}{\z@}{12pt plus 2pt minus 2pt} +{12pt plus 2pt minus 2pt}{\subsize\bf}} +\makeatother diff --git a/2002/netfilter-future-lk2002/abstract b/2002/netfilter-future-lk2002/abstract new file mode 100644 index 0000000..177d436 --- /dev/null +++ b/2002/netfilter-future-lk2002/abstract @@ -0,0 +1,33 @@ +Linux packet filtering in the 2.6.x kernel series + +The Linux 2.4.x provided a complete rewrite of the firewalling subsystem, +called netfilter/iptables. It was a major improvement about the previous +ipchains subsystem. The major advantages are it's modularity and flexibility. + +However, as wity any project, as soon as you are sort-of finished, you become +aware of potential improvements and extensions. + +The firewalling subsystem within the Linux kernel will undergo some fundamental design changes during the 2.5.x development kernel series. + +Some of the changes from 2.4.x are: + +- Have an independent pkt_tables subsystem, as a layer3 independent replacement + for iptables, ip6tables and arptables. This will allow adding support for + other layer 3 protocols very easily +- Move all kernel/userspace communication to netlink sockets. There will be + a generic nfnetlink layer, with pkttnetlink (for managing pkt_tables) and + ctnetlink (for manipulating the connection tracking database from userspace). +- Change the internal data structure of an ip_table to a linked list of chains, + which in turn are a linked lists out of rules, which are linked lists out of + matches + targets. This way it is _way_ more performant in the case of + dynamic firewalling rulesets. +- Provide a generic high-level API to userspace applications for manipulation + of packet filtering rules. This will enable generic GUI's, which need no + changes in case new matches or targets are added. + +Optionally, the netfilter core team is planning to have support for connection +tracking state replication - something necessarry for failover of stateful +firewalls. + +The talk assumes prior knowledge about the netfilter/iptables architecture. + diff --git a/2002/netfilter-future-lk2002/netfilter-future-lk2002.mgp b/2002/netfilter-future-lk2002/netfilter-future-lk2002.mgp new file mode 100644 index 0000000..96e12f5 --- /dev/null +++ b/2002/netfilter-future-lk2002/netfilter-future-lk2002.mgp @@ -0,0 +1,374 @@ +%include "default.mgp" +%default 1 bgrad +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +%nodefault +%back "blue" + +%center +%size 7 + + +The future of Linux packet filtering +targeted for kernel 2.6 + + +%center +%size 4 +by + +Harald Welte + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Future of Linux packet filtering +Contents + + + Problems with current 2.4.x netfilter/iptables + Solution to code replication + Solution for dynamic rulesets + Solution for API to GUI's and other management programs + + HA for stateful firewalling + What's special about firewalling HA + Poor man's failover + Real state replication + + Other current work + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Future of Linux packet filtering +Problems with 2.4.x netfilter/iptables + + code replication between iptables/ip6tables/arptables + iptables was never meant for other protocols, but people did copy+paste 'ports' + replication of + core kernel code + layer 3 independent matches (mac, interface, ...) + userspace library (libiptc) + userspace tool (iptables) + userspace plugins (libipt_xxx.so) + + doesn't suit the needs for dynamically changing rulesets + dynamic rulesets becomming more common due (service selection, IDS) + a whole table is created in userspace and sent as blob to kernel + for every ruleset the table needs to be copied to userspace and back + inside kernel consistency checks on whole table, loop detection + + too extensible for writing any forward-compatible GUI + new extensions showing up all the time + a frontend would need to know about the options and use of a new extension + thus frontends are always incomplete and out-of-date + no high-level API other than piping to iptables-restore + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Future of Linux packet filtering +Reducing code replication + + code replication is a real problem: unclean, bugfixes missed + we need layer 3 independent layer for + submitting rules to the kernel + traversing packet-rulesets supporting match/target modules + registering matches/targets + layer 3 specific (like matching ipv4 address) + layer 3 independent (like matching MAC address) + + solution + pkt_tables inside kernel + pkt_tables_ipv4 registers layer 3 handler with pkt_tables + pkt_tables_ipv6 registers layer 3 handler with pkt_tables + everybody registering a pkt_table (like iptable_filter) needs to specify the l3 protocol + libraries in userspace (see later) + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Future of Linux packet filtering +Supporting dynamic rulesets + + atomic table-replacement turned out to be bad idea + need new interface for sending individual rules to kernel + policy routing has the same problem and good solution: rtnetlink + solution: nfnetlink + multicast-netlink based packet-orinented socket between kernel and userspace + has extra benefit that other userspace processes get notified of rule changes [just like routing daemons] + nfnetlink will be low-layer below all kernel/userspace communication + pkttnetlink [aka iptnetlink] + ctnetlink + ulog + ip_queue + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Future of Linux packet filtering +Communication with other programs + +whole set of libraries + libnfnetlink for low-layer communication + libpkttnetlink for rule modifications + will handle all plugins [which are currently part of iptables] + query functions about avaliable matches/targets + query functions about parameters + query functions for help messages about specific match/parameter of a match + generic structure from which rules can be built + conversion functions to parse generic structure into in-kernel structure + conversion functiosn to perse kernel structure into generic structure + functions to convert generic structure in plain text + libipq will stay API-compatible to current version + libipulog will stay API-compatible to current version + libiptc will go away [compatibility layer extremely difficult] + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Introduction + +What is special about firewall failover? + + Nothing, in case of the stateless packet filter + Common IP takeover solutions can be used + VRRP + Hartbeat + + Distribution of packet filtering ruleset no problem + can be done manually + or implemented with simple userspace process + + Problems arise with stateful packet filters + Connection state only on active node + NAT mappings only on active node + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Connection Tracking Subsystem + +Connection tracking... + + implemented seperately from NAT + enables stateful filtering + implementation + hooks into NF_IP_PRE_ROUTING to track packets + hooks into NF_IP_POST_ROUTING and NF_IP_LOCAL_IN to see if packet passed filtering rules + protocol modules (currently TCP/UDP/ICMP) + application helpers currently (FTP,IRC,H.323,talk,SNMP) + divides packets in the following four categories + NEW - would establish new connection + ESTABLISHED - part of already established connection + RELATED - is related to established connection + INVALID - (multicast, errors...) + does _NOT_ filter packets itself + can be utilized by iptables using the 'state' match + is used by NAT Subsystem + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Connection Tracking Subsystem + +Common structures + struct ip_conntrack_tuple, representing unidirectional flow + layer 3 src + dst + layer 4 protocol + layer 4 src + dst + + + connetions represented as struct ip_conntrack + original tuple + reply tuple + timeout + l4 state private data + app helper + app helper private data + expected connections + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Connection Tracking Subsystem + +Flow of events for new packet + packet enters NF_IP_PRE_ROUTING + tuple is derived from packet + lookup conntrack hash table with hash(tuple) -> fails + new ip_conntrack is allocated + fill in original and reply == inverted(original) tuple + initialize timer + assign app helper if applicable + see if we've been expected -> fails + call layer 4 helper 'new' function + + ... + + packet enters NF_IP_POST_ROUTING + do hashtable lookup for packet -> fails + place struct ip_conntrack in hashtable + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Connection Tracking Subsystem + +Flow of events for packet part of existing connection + packet enters NF_IP_PRE_ROUTING + tuple is derived from packet + lookup conntrack hash table with hash(tuple) + assosiate conntrack entry with skb->nfct + call l4 protocol helper 'packet' function + do l4 state tracking + update timeouts as needed [i.e. TCP TIME_WAIT,...] + + ... + + packet enters NF_IP_POST_ROUTING + do hashtable lookup for packet -> succeds + do nothing else + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Poor man's failover + +Poor man's failover + principle + let every node do it's own tracking rather than replicating state + two possible implementations + connect every node to shared media (i.e. real ethernet) + forwarding only turned on on active node + slave nodes use promiscuous mode to sniff packets + copy all traffic to slave nodes + active master needs to copy all traffic to other nodes + disadvantage: high load, sync traffic == payload traffic + IMHO stupid way of solving the problem + advantages + very easy implementation + only addition of sniffing mode to conntrack needed + existing means of address takeover can be used + same load on active master and slave nodes + no additional load on active master + disadvantages + can only be used with real shared media (no switches, ...) + can not be used with NAT + remaining problem + no initial state sync after reboot of slave node! + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Real state replication + +Parts needed + state replication protocol + multicast based + sequence numbers for detection of packet loss + NACK-based retransmission + no security, since private ethernet segment to be used + event interface on active node + calling out to callback function at all state changes + exported interface to manipulate conntrack hash table + kernel thread for sending conntrack state protocol messages + registers with event interface + creates and accumulates state replication packets + sends them via in-kernel sockets api + kernel thread for receiving conntrack state replication messages + receives state replication packets via in-kernel sockets + uses conntrack hashtable manipulation interface + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Real state replication + + Flow of events in chronological order: + on active node, inside the network RX softirq + connection tracking code is analyzing a forwarded packet + connection tracking gathers some new state information + connection tracking updates local connection tracking database + connection tracking sends event message to event API + on active node, inside the conntrack-sync kernel thread + conntrack sync daemon receives event through event API + conntrack sync daemon aggregates multiple event messages into a state replication protocol message, removing possible redundancy + conntrack sync daemon generates state replication protocol message + conntrack sync daemon sends state replication protocol message + on slave node(s), inside network RX softirq + connection tracking code ignores packets coming from the interface attached to the private conntrac sync network + state replication protocol messages is appended to socket receive queue of conntrack-sync kernel thread + on slave node(s), inside conntrack-sync kernel thread + conntrack sync daemon receives state replication message + conntrack sync daemon creates/updates conntrack entry + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Neccessary changes to kernel + +Neccessary changes to current conntrack core + + event generation (callback functions) for all state changes + + conntrack hashtable manipulation API + is needed (and already implemented) for 'ctnetlink' API + + conntrack exemptions + needed to _not_ track conntrack state replication packets + is needed for other cases as well + currently being developed by Jozsef Kadlecsik + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Other current work + + optimizing the conntrack code + hash function optimization + current hash function not good for even hash bucket count + other hash functions in development + hash function evaluation tool [cttest] avaliable + introduce per-system randomness to prevent hash attack + code optimization (locking/timers/...) + + getting our work submitted into the mainstream kernel + turns out to be more difficult + e.g. newnat api now waiting for three months + + discussions about multiple targets/actions per rule + technical implementation easy + however, not everybody convinced that it fits into the concept + + using tc for firewalling + Jamal Hadi Selim uses iptables targets from within TC + leads to discussion of generic classification engine API in kernel + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Future of Linux packet filtering +Thanks + The slides and the an according paper of this presentation are available at http://www.gnumonks.org/ + + The netfilter homepage http://www.netfilter.org/ + + Thanks to + the BBS people, Z-Netz, FIDO, ... + for heavily increasing my computer usage in 1992 + KNF + for bringing me in touch with the internet as early as 1994 + for providing a playground for technical people + for telling me about the existance of Linux! + Alan Cox, Alexey Kuznetsov, David Miller, Andi Kleen + for implementing (one of?) the world's best TCP/IP stacks + Paul 'Rusty' Russell + for starting the netfilter/iptables project + for trusting me to maintain it today + Astaro AG + for sponsoring parts of my netfilter work + diff --git a/2002/netfilter-internals-lsm2002/abstract b/2002/netfilter-internals-lsm2002/abstract new file mode 100644 index 0000000..1cc18b0 --- /dev/null +++ b/2002/netfilter-internals-lsm2002/abstract @@ -0,0 +1,49 @@ +Linux 2.4.x netfilter/iptables firewalling internals (lt-690870524) + + The Linux 2.4.x kernel series has introduced a totally new kernel firewalling subsystem. It is much more than a plain successor of ipfwadm or ipchains. + + The netfilter/iptables project has a very modular design and it's +sub-projects can be split in several parts: netfilter, iptables, connection +tracking, NAT and packet mangling. + + While most users will already have learned how to use the basic functions +of netfilter/iptables in order to convert their old ipchains firewalls to +iptables, there's more advanced but less used functionality in +netfilter/iptables. + + The presentation covers the design principles behind the netfilter/iptables +implementation. This knowledge enables us to understand how the individual +parts of netfilter/iptables fit together, and for which potential applications +this is useful. + +Topics covered: + +- overview about the internal netfilter/iptables architecture + - the netfilter hooks inside the network protocol stacks + - packet selection with IP tables + - how is connection tracking and NAT integrated into the framework +- the connection tracking system + - how good does it track the TCP state? + - how does it track ICMP and UDP state at all? + - layer 4 protocol helpers (GRE, ...) + - application helpers (ftp, irc, h323, ...) + - restrictions/limitations +- the NAT system + - how does it interact with connection tracking? + - layer 4 protocol helpers + - application helpers (ftp, irc, ...) +- misc + - how far is IPv6 firewalling with ip6tables? + - advances in failover/HA of stateful firewalls + - ivisible firewalls with iptables on a bridge + - userspace packet queueing with QUEUE + - userspace packet logging with ULOG + +Requirements: +- knowledge about the TCP/IP protocol family +- knowledge about general firewalling and packet filtering concepts +- prior experience with linux packet filters + +Audience: +- firewall administrators +- network developers diff --git a/2002/netfilter-internals-lsm2002/netfilter-internals-lsm2002.mgp b/2002/netfilter-internals-lsm2002/netfilter-internals-lsm2002.mgp new file mode 100644 index 0000000..fb8b444 --- /dev/null +++ b/2002/netfilter-internals-lsm2002/netfilter-internals-lsm2002.mgp @@ -0,0 +1,520 @@ +%include "default.mgp" +%default 1 bgrad +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +%nodefault +%back "blue" + +%center +%size 7 + + +Linux 2.4.x netfilter/iptables +firewalling internals + + +%center +%size 4 +by + +Harald Welte + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Contents + + + Introduction + Netfilter hooks in protocol stacks + Packet selection based on IP Tables + The Connection Tracking Subsystem + The NAT Subsystem based on netfilter + iptables + Packet filtering using the 'filter' table + Packet mangling using the 'mangle' table + Advanced netfilter concepts + Current development and Future + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Introduction + +Why did we need netfilter/iptables? +Because ipchains... + + has no infrastructure for passing packets to userspace + makes transparent proxying extremely difficult + has interface address dependent Packet filter rules + has Masquerading implemented as part of packet filtering + code is too complex and intermixed with core ipv4 stack + is neither modular nor extensible + only barely supports one special case of NAT (masquerading) + has only stateless packet filtering + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Introduction + +Who's behind netfilter/iptables + Paul 'Rusty' Russel + co-author of iptables in Linux 2.2 + was paid by Watchguard for about one Year of development + James Morris + userspace queuing (kernel, library and tools) + REJECT target + Marc Boucher + NAT and packet filtering controlled by one command + Mangle table + Harald Welte + Conntrack+NAT helper infrastructure (newnat) + Userspace packet logging (ULOG) + PPTP and IRC conntrack/NAT helpers + Jozsef Kadlecsik + TCP window tracking + H.323 conntrack + NAT helper + Continued newnat development + Non-core team contributors + http://www.netfilter.org/scoreboard/ +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Netfilter Hooks + +What is netfilter? + + System of callback functions within network stack + Callback function to be called for every packet traversing certain point (hook) within network stack + Protocol independent framework + Hooks in layer 3 stacks (IPv4, IPv6, DECnet, ARP) + Multiple kernel modules can register with each of the hooks + Asynchronous packet handling in userspace (ip_queue) + +Traditional packet filtering, NAT, ... is implemented on top of this framework + +Can be used for other stuff interfacing with the core network stack, like DECnet routing daemon. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Netfilter Hooks + +Netfilter architecture in IPv4 +%font "courier" + + --->[1]--->[ROUTE]--->[3]--->[4]---> + | ^ + | | + | [ROUTE] + v | + [2] [5] + | ^ + | | + v | + +%font "standard" +1=NF_IP_PRE_ROUTING +2=NF_IP_LOCAL_IN +3=NF_IP_FORWARD +4=NF_IP_POST_ROUTING +5=NF_IP_LOCAL_OUT +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Netfilter Hooks + +Netfilter Hooks + + Any kernel module may register a callback function at any of the hooks + + The module has to return one of the following constants + + NF_ACCEPT continue traversal as normal + NF_DROP drop the packet, do not continue + NF_STOLEN I've taken over the packet do not continue + NF_QUEUE enqueue packet to userspace + NF_REPEAT call this hook again + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +IP tables + +Packet selection using IP tables + + The kernel provides generic IP tables support + + Each kernel module may create it's own IP table + + The three major parts of 2.4 firewalling subsystem are implemented using IP tables + Packet filtering table 'filter' + NAT table 'nat' + Packet mangling table 'mangle' + + Can potentially be used for other stuff, i.e. IPsec SPDB + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +IP Tables + +Managing chains and tables + + An IP table consists out of multiple chains + A chain consists out of a list of rules + Every single rule in a chain consists out of + match[es] (rule executed if all matches true) + target (what to do if the rule is matched) + +%size 4 +matches and targets can either be builtin or implemented as kernel modules + +%size 6 + The userspace tool iptables is used to control IP tables + handles all different kinds of IP tables + supports a plugin/shlib interface for target/match specific options + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +IP Tables + +Basic iptables commands + + To build a complete iptables command, we must specify + which table to work with + which chain in this table to use + an operation (insert, add, delete, modify) + one or more matches (optional) + a target + +The syntax is +%font "typewriter" +%size 3 +iptables -t table -Operation chain -j target match(es) +%font "standard" +%size 5 + +Example: +%font "typewriter" +%size 3 +iptables -t filter -A INPUT -j ACCEPT -p tcp --dport smtp +%font "standard" +%size 5 + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +IP Tables + +Matches + Basic matches + -p protocol (tcp/udp/icmp/...) + -s source address (ip/mask) + -d destination address (ip/mask) + -i incoming interface + -o outgoing interface + + Match extensions (examples) + tcp/udp TCP/udp source/destination port + icmp ICMP code/type + ah/esp AH/ESP SPID match + mac source MAC address + mark nfmark + length match on length of packet + limit rate limiting (n packets per timeframe) + owner owner uid of the socket sending the packet + tos TOS field of IP header + ttl TTL field of IP header + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +IP Tables + +Targets + very dependent on the particular table. + + Table specific targets will be discussed later + + Generic Targets, always available + ACCEPT accept packet within chain + DROP silently drop packet + QUEUE enqueue packet to userspace + LOG log packet via syslog + ULOG log packet via ulogd + RETURN return to previous (calling) chain + foobar jump to user defined chain + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Packet Filtering + +Overview + + Implemented as 'filter' table + Registers with three netfilter hooks + + NF_IP_LOCAL_IN (packets destined for the local host) + NF_IP_FORWARD (packets forwarded by local host) + NF_IP_LOCAL_OUT (packets from the local host) + +Each of the three hooks has attached one chain (INPUT, FORWARD, OUTPUT) + +Every packet passes exactly one of the three chains. Note that this is very different compared to the old 2.2.x ipchains behaviour. + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Packet Filtering + +Targets available within 'filter' table + + Builtin Targets to be used in filter table + ACCEPT accept the packet + DROP silently drop the packet + QUEUE enqueue packet to userspace + RETURN return to previous (calling) chain + foobar user defined chain + + Targets implemented as loadable modules + REJECT drop the packet but inform sender + MIRROR change source/destination IP and resend + LOG log via syslog + ULOG log via userspace + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Connection Tracking Subsystem + + Connection tracking... + + implemented seperately from NAT + enables stateful filtering + implementation + hooks into NF_IP_PRE_ROUTING to track packets + hooks into NF_IP_POST_ROUTING and NF_IP_LOCAL_IN to see if packet passed filtering rules + protocol modules (currently TCP/UDP/ICMP) + application helpers currently (FTP,IRC,H.323,talk,SNMP) + divides packets in the following four categories + NEW - would establish new connection + ESTABLISHED - part of already established connection + RELATED - is related to established connection + INVALID - (multicast, errors...) + does _NOT_ filter packets itself + can be utilized by iptables using the 'state' match + is used by NAT Subsystem + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Connection Tracking Subsystem + +Common structures + struct ip_conntrack_tuple, representing unidirectional flow + layer 3 src + dst + layer 4 protocol + layer 4 src + dst + + + connetions represented as struct ip_conntrack + original tuple + reply tuple + timeout + l4 state private data + app helper + app helper private data + expected connections + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Connection Tracking Subsystem + +Flow of events for new packet + packet enters NF_IP_PRE_ROUTING + tuple is derived from packet + lookup conntrack hash table with hash(tuple) -> fails + new ip_conntrack is allocated + fill in original and reply == inverted(original) tuple + initialize timer + assign app helper if applicable + see if we've been expected -> fails + call layer 4 helper 'new' function + + ... + + packet enters NF_IP_POST_ROUTING + do hashtable lookup for packet -> fails + place struct ip_conntrack in hashtable + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +HA for netfillter/iptables +Connection Tracking Subsystem + +Flow of events for packet part of existing connection + packet enters NF_IP_PRE_ROUTING + tuple is derived from packet + lookup conntrack hash table with hash(tuple) + assosiate conntrack entry with skb->nfct + call l4 protocol helper 'packet' function + do l4 state tracking + update timeouts as needed [i.e. TCP TIME_WAIT,...] + + ... + + packet enters NF_IP_POST_ROUTING + do hashtable lookup for packet -> succeds + do nothing else + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Network Address Translation + +Overview + + Previous Linux Kernels only implemented one special case of NAT: Masquerading + Linux 2.4.x can do any kind of NAT. + NAT subsystem implemented on top of netfilter, iptables and conntrack + NAT subsystem registers with all five netfilter hooks + 'nat' Table registers chains PREROUTING, POSTROUTING and OUTPUT + Following targets available within 'nat' Table + SNAT changes the packet's source whille passing NF_IP_POST_ROUTING + DNAT changes the packet's destination while passing NF_IP_PRE_ROUTING + MASQUERADE is a special case of SNAT + REDIRECT is a special case of DNAT + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Network Address Translation + + Source NAT + SNAT Example: +%font "typewriter" +%size 3 +iptables -t nat -A POSTROUTING -j SNAT --to-source 1.2.3.4 -s 10.0.0.0/8 +%font "standard" +%size 4 + + MASQUERADE Example: +%font "typewriter" +%size 3 +iptables -t nat -A POSTROUTING -j MASQUERADE -o ppp0 +%font "standard" +%size 5 + + Destination NAT + DNAT example +%font "typewriter" +%size 3 +iptables -t nat -A PREROUTING -j DNAT --to-destination 1.2.3.4:8080 -p tcp --dport 80 -i eth1 +%font "standard" +%size 4 + + REDIRECT example +%font "typewriter" +%size 3 +iptables -t nat -A PREROUTING -j REDIRECT --to-port 3128 -i eth1 -p tcp --dport 80 +%font "standard" +%size 5 + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Packet Mangling + + Purpose of mangle table + packet manipulation except address manipulation + + Integration with netfilter + 'mangle' table hooks in all five netfilter hooks + priority: after conntrack + + Targets specific to the 'mangle' table: + DSCP - manipulate DSCP field + IPV4OPTSSTRIP - strip IPv4 options + MARK - change the nfmark field of the skb + TCPMSS - set TCP MSS option + TOS - manipulate the TOS bits + TTL - set / increase / decrease TTL field + +Simple example: +%font "typewriter" +%size 3 +iptables -t mangle -A PREROUTING -j MARK --set-mark 10 -p tcp --dport 80 + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Advanced Netfilter concepts + +%size 4 + Userspace logging + flexible replacement for old syslog-based logging + packets to userspace via multicast netlink sockets + easy-to-use library (libipulog) + plugin-extensible userspace logging daemon (ulogd) + Can even be used to directly log into MySQL + + Queuing + reliable asynchronous packet handling + packets to userspace via unicast netlink socket + easy-to-use library (libipq) + provides Perl bindings + experimental queue multiplex daemon (ipqmpd) + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Current Development and Future + +Netfilter (although it proved very stable) is still work in progress. + + Areas of current development + infrastructure for conntrack manipulation from userspace + failover of stateful firewalls + making iptables layer3 independent (pkttables) + new userspace library (libiptables) to hide plugins from apps + more matches and targets for advanced functions (pool, hashslot) + more conntrack and NAT modules (RPC, SNMP, SMB, ...) + better IPv6 support (conntrack, more matches / targets) + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +Future of Linux packet filtering +Thanks + The slides and the an according paper of this presentation are available at http://www.gnumonks.org/ + + The netfilter homepage http://www.netfilter.org/ + + Thanks to + the BBS people, Z-Netz, FIDO, ... + for heavily increasing my computer usage in 1992 + KNF + for bringing me in touch with the internet as early as 1994 + for providing a playground for technical people + for telling me about the existance of Linux! + Alan Cox, Alexey Kuznetsov, David Miller, Andi Kleen + for implementing (one of?) the world's best TCP/IP stacks + Paul 'Rusty' Russell + for starting the netfilter/iptables project + for trusting me to maintain it today + Astaro AG + for sponsoring parts of my netfilter work + diff --git a/2002/netfilter-internals-lsm2002/netfilter-internals-lsm2002.tex b/2002/netfilter-internals-lsm2002/netfilter-internals-lsm2002.tex new file mode 100644 index 0000000..c3a28ea --- /dev/null +++ b/2002/netfilter-internals-lsm2002/netfilter-internals-lsm2002.tex @@ -0,0 +1,537 @@ +\documentclass{article} +\usepackage{german} +\usepackage{fancyheadings} +\usepackage{a4} + +\setlength{\oddsidemargin}{0in} +\setlength{\evensidemargin}{0in} +\setlength{\topmargin}{0.0in} +\setlength{\headheight}{0in} +\setlength{\headsep}{0in} +\setlength{\textwidth}{6.5in} +\setlength{\textheight}{9.5in} +\setlength{\parindent}{0in} +\setlength{\parskip}{0.05in} + + +\begin{document} +\title{Linux 2.4.x netfilter/iptables firewalling internals} + +\author{Harald Welte\\ + laforge@gnumonks.org\\ + \copyright{}2002 H. Welte} + +\date{25. April 2002} + +\maketitle + +\setcounter{section}{0} +\setcounter{subsection}{0} +\setcounter{subsubsection}{0} + +\section{Introduction} +The Linux 2.4.x kernel series has introduced a totally new kernel firewalling +subsystem. It is much more than a plain successor of ipfwadm or ipchains. + +The netfilter/iptables project has a very modular design and it's +sub-projects can be split in several parts: netfilter, iptables, connection +tracking, NAT and packet mangling. + +While most users will already have learned how to use the basic functions +of netfilter/iptables in order to convert their old ipchains firewalls to +iptables, there's more advanced but less used functionality in +netfilter/iptables. + +The presentation covers the design principles behind the netfilter/iptables +implementation. This knowledge enables us to understand how the individual +parts of netfilter/iptables fit together, and for which potential applications +this is useful. + +\section{Internal netfilter/iptables architecture} + +\subsection{Netfilter hooks in protocol stacks} + +One of the major motivations behind the redesign of the linux packet +filtering and NAT system during the 2.3.x kernel series was the widespread +firewall specific code parts within the core IPv4 stack. Ideally the core +IPv4 stack (as used by regular hosts and routers) shouldn't contain any +firewalling specific code, resulting in no unwanted interaction and less +code complexity. This desire lead to the invention of {\it netfilter}. + +\subsubsection{Architecture of netfilter} + +Netfilter is basically a system of callback functions within the network +stack. It provides a non-portable API towards in-kernel networking +extensions. + +What we call {\it netfilter hook} is a well-defined call-out point within a +layer three protocol stack, such as IPv4, IPv6 or DECnet. Any layer three +network stack can define an arbitrary number of hooks, usually placed at +strategic points within the packet flow. + +Any other kernel code can now subsequently register callback functions for +any of these hooks. As in most sytems will be more than one callback +function registered for a particular hook, a {\it priority} is specified upon +registration of the callback function. This priority defines the order in +which the individual callback functions at a particular hook are called. + +The return value of any registered callback functions can be: +\begin{itemize} +\item +{\bf NF\_ACCEPT}: continue traversal as usual +\item +{\bf NF\_DROP}: drop the packet; do not continue traversal +\item +{\bf NF\_STOLEN}: callback function has taken over the packet; do not continue +\item +{\bf NF\_QUEUE}: enqueue the packet to userspace +\item +{\bf NF\_REPEAT}: call this hook again +\end{itemize} + +\subsubsection{Netfilter hooks within IPv4} + +The IPv4 stack provides five netfilter hooks, which are placed at the +following peculiar places within the code: + +\begin{verbatim} + --->[1]--->[ROUTE]--->[3]--->[4]---> + | ^ + | | + | [ROUTE] + v | + [2] [5] + | ^ + | | + v | + + local processes +\end{verbatim} + +Packets received on any network interface arrive at the left side of the +diagram. After the verification of the IP header checksum, the +NF\_IP\_PRE\_ROUTING [1] hook is traversed. + +If they ``survive'' (i.e. NF\_ACCEPT is returned), the packet enters the +routing code. Where we continue from here depends on the destintion of the +packet. + +Packets with a local destination (i.e. packets where the destination address is +one of the own IP addresses of the host) traverse the NF\_IP\_LOCAL\_IN [2] +hook. If all callback function return NF\_ACCEPT, the packet is finally passed +to the socket code, which eventually passes the packet to a local process. + +Packets with a remote destination (i.e. packets which are forwarded by the +local machine) traverse the NF\_IP\_FORWARD [3] hook. If they ``survive'', +they finally pass the NF\_IP\_POST\_ROUTING [4] hook and are sent off the +outgoing network interface. + +Locally generated packets first traverse the NF\_IP\_LOCAL\_OUT [5] hook, then +enter the routing code, and finally go through the NF\_IP\_POST\_ROUTING [4] +hook before being sent off the outgoing network interface. + +\subsubsection{Netfilter hooks within IPv6} + +As the IPv4 and IPv6 protocols are very similar, the netfilter hooks within the +IPv6 stack are placed at exactly the same locations as in the IPv4 stack. The +only change are the hook names: NF\_IP6\_PRE\_ROUTING, NF\_IP6\_LOCAL\_IN, +NF\_IP6\_FORWARD, NF\_IP6\_POST\_ROUTING, NF\_IP6\_LOCAL\_OUT. + +\subsubsection{Netfilter hooks within DECnet} + +There are seven decnet hooks. The first five hooks (NF\_DN\_PRE\_ROUTING, +NF\_DN\_LOCAL\_IN, NF\_DN\_FORWARD, NF\_DN\_LOCAL\_OUT, NF\_DN\_POST\_ROUTING) +are prretty much the same as in IPv4. The last two hooks (NF\_DN\_HELLO, +NF\_DN\_ROUTE) are used in conjunction with DECnet Hello and Routing packets. + +\subsubsection{Netfilter hooks within ARP} + +Recent kernels\footnote{IIRC, starting with 2.4.19-pre3} have added support for netfilter hooks within the ARP code. +There are two hooks: NF\_ARP\_IN and NF\_ARP\_OUT, for incoming and outgoing +ARP packets respectively. + +\subsubsection{Netfilter hooks within IPX} + +There have been experimental patches to add netfilter hooks to the IPX code, +but they never got integrated into the kernel source. + +\subsection{Packet selection using IP Tables} + +The IP tables core (ip\_tables.o) provides a generic layer for evaluation +of rulesets. + +An IP table consists out of an arbitrary number of {\it chains}, which in turn +consist out of a linear list of {\it rules}, which again consist out of any +number of {\it matches} and one {\it target}. + +{\it Chains} can further be devided into two classes: Either {\it builtin +chains} or {\it user-defined chains}. Builtin chains are always present, they +are created upon table registration. They are also the entry points for table +iteration. User defined chains are created at runtime upon user interaction. + +{\it Matches} specify the matching criteria, there can be zero or more matches + +{\it Targets} specify the action which is to be executed in case {\bf all} +matches match. There can only be a single target per rule. + +Matches and targets can either be {\it builtin} or {\it linux kernel modules}. + +There are two special targets: +\begin{itemize} +\item +By using a chain name as target, it is possible to jump to the respective chain +in case the matches match. +\item +By using the RETURN target, it is possible to return to the previous (calling) +chain +\end{itemize} + +The IP tables core handles the following functions +\begin{itemize} +\item +Registering and unregistering tables +\item +Registering and unregistering matches and targets (can be implemented as linux kernel modules) +\item +Kernel / userspace interface for manipulation of IP tables +\item +Traversal of IP tables +\end{itemize} + +\subsubsection{Packet filtering unsing the ``filter'' table} + +Traditional packet filtering (i.e. the successor to ipfwadm/ipchains) takes +place in the ``filter'' table. Packet filtering works like a sieve: A packet +is (in the end) either dropped or accepted - but never modified. + +The ``filter'' table is implemented in the {\it iptable\_filter.o} module +and contains three builtin chains: + +\begin{itemize} +\item +{\bf INPUT} attaches to NF\_IP\_LOCAL\_IN +\item +{\bf FORWARD} attaches to NF\_IP\_FORWARD +\item +{\bf OUTPUT} attaches to NF\_IP\_LOCAL\_OUT +\end{itemize} + +The placement of the chains / hooks is done in such way, that evey concievable +packet always traverses only one of the built-in chains. Packets destined for +the local host traverse only INPUT, packets forwarded only FORWARD and +locally-originated packets only OUTPUT. + +\subsubsection{Packet mangling using the ``mangle'' table} + +As stated above, operations which would modify a packet do not belong in the +``filter'' table. The ``mangle'' table is available for all kinds of packet +manipulation - but not manipulation of addresses (which is NAT). + +The mangle table attaches to all five netfilter hooks and provides the +respectiva builtin chains (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING) +\footnote{This has changed through recent 2.4.x kernel series, old kernels may +only support three (PREROUTING, POSTROUTING, OUTPUT) chains.}. + +\subsection{Connection Tracking Subsystem} + +Traditional packet filters can only match on matching criteria within the +currently processed packet, like source/destination IP address, port numbers, +TCP flags, etc. As most applications have a notion of connections or at least +a request/response style protocol, there is a lot of information which can not +be derived from looking at a single packet. + +Thus, modern (stateful) packet filters attempt to track connections (flows) +and their respective protocol states for all traffic through the packet +filter. + +Connection tracking within linux is implemented as a netfilter module, called +ip\_conntrack.o. + +Before describing the connection tracking subsystem, we need to describe a couple of definitions and primitives used throughout the conntrack code. + +A connection is represented within the conntrack subsystem using {\it struct +ip\_conntrack}, also called {\it connection tracking entry}. + +Connection tracking is utilizing {\it conntrack tuples}, which are tuples +consisting out of (srcip, srcport, dstip, dstport, l4prot). A connection is +uniquely identified by two tuples: The tuple in the original direction +(IP\_CT\_DIR\_ORIGINAL) and the tuple for the reply direction +(IP\_CT\_DIR\_REPLY). + +Connection tracking itself does not drop packets\footnote{well, in some rare +cases in combination with NAT it needs to drop. But don't tell anyone, this is +secret.} or impose any policy. It just associates every packet with a +connection tracking entry, which in turn has a particular state. All other +kernel code can use this state information\footnote{state information is +internally represented via the {\it struct sk\_buff.nfct} structure member of a +packet.}. + +\subsubsection{Integration of conntrack with netfilter} + +If the ip\_conntrack.o module is registered with netfilter, it attaches to the +NF\_IP\_PRE\_ROUTING, NF\_IP\_POST\_ROUTING, NF\_IP\_LOCAL\_IN and +NF\_IP\_LOCAL\_OUT hooks. + +Because forwarded packets are the most common case on firewalls, I will only +describe how connection tracking works for forwarded packets. The two relevant +hooks for forwarded packets are NF\_IP\_PRE\_ROUTING and NF\_IP\_POST\_ROUTING. + +Every time a packet arrives at the NF\_IP\_PRE\_ROUTING hook, connection +tracking creates a conntrack tuple from the packet. It then compares this +tuple to the original and reply tuples of all already-seen connections +\footnote{Of course this is not implemented as a linear search over all existing connections.} to find out if this just-arrived packet belongs to any existing +connection. If there is no match, a new conntrack table entry (struct +ip\_conntrack) is created. + +Let's assume the case where we have already existing connections but are +starting from scratch. + +The first packet comes in, we derive the tuple from the packet headers, look up +the conntrack hash table, don't find any matching entry. As a result, we +create a new struct ip\_conntrack. This struct ip\_conntrack is filled with +all necessarry data, like the original and reply tuple of the connection. +How do we know the reply tuple? By inverting the source and destination +parts of the original tuple.\footnote{So why do we need two tuples, if they can +be derived from each other? Wait until we discuss NAT.} +Please note that this new struct ip\_conntrack is {\bf not} yet placed +into the conntrack hash table. + +The packet is now passed on to other callback functions which have registered +with a lower priority at NF\_IP\_PRE\_ROUTING. It then continues traversal of +the network stack as usual, including all respective netfilter hooks. + +If the packet survives (i.e. is not dropped by the routing code, network stack, +firewall ruleset, ...), it re-appears at NF\_IP\_POST\_ROUTING. In this case, +we can now safely assume that this packet will be sent off on the outgoing +interface, and thus put the connection tracking entry which we created at +NF\_IP\_PRE\_ROUTING into the conntrack hash table. This process is called +{\it confirming the conntrack}. + +The connection tracking code itself is not monolithic, but consists out of a +couple of seperate modules\footnote{They don't actually have to be seperate +kernel modules; e.g. TCP, UDP and ICMP tracking modules are all part of +the linux kernel module ip\_conntrack.o}. Besides the conntrack core, there +are two important kind of modules: Protocol helpers and application helpers. + +Protocol helpers implement the layer-4-protocol specific parts. They currently +exist for TCP, UDP and ICMP (an experimental helper for GRE exists). + +\subsubsection{TCP connection tracking} + +As TCP is a connection oriented protocol, it is not very difficult to imagine +how conntection tracking for this protocol could work. There are well-defined +state transitions possible, and conntrack can decide which state transitions +are valid within the TCP specification. In reality it's not all that easy, +since we cannot assume that all packets that pass the packet filter actually +arrive at the receiving end, ... + +It is noteworthy that the standard connection tracking code does {\bf not} +do TCP sequence number and window tracking. A well-maintained patch to add +this feature exists almost as long as connection tracking itself. It will +be integrated with the 2.5.x kernel. The problem with window tracking is +it's bad interaction with connection pickup. The TCP conntrack code is able to +pick up already existing connections, e.g. in case your firewall was rebooted. +However, connection pickup is conflicting with TCP window tracking: The TCP +window scaling option is only transferred at connection setup time, and we +don't know about it in case of pickup... + +\subsubsection{ICMP tracking} + +ICMP is not really a connection oriented protocol. So how is it possible to +do connection tracking for ICMP? + +The ICMP protocol can be split in two groups of messages + +\begin{itemize} +\item +ICMP error messages, which sort-of belong to a different connection +ICMP error messages are associated {\it RELATED} to a different connection. +(ICMP\_DEST\_UNREACH, ICMP\_SOURCE\_QUENCH, ICMP\_TIME\_EXCEEDED, +ICMP\_PARAMETERPROB, ICMP\_REDIRECT). +\item +ICMP queries, which have a request->reply character. So what the conntrack +code does, is let the request have a state of {\it NEW}, and the reply +{\it ESTABLISHED}. The reply closes the connection immediately. +(ICMP\_ECHO, ICMP\_TIMESTAMP, ICMP\_INFO\_REQUEST, ICMP\_ADDRESS) +\end{itemize} + +\subsubsection{UDP connection tracking} + +UDP is designed as a connectionless datagram protocol. But most common +protocols using UDP as layer 4 protocol have bi-directional UDP communication. +Imagine a DNS query, where the client sends an UDP frame to port 53 of the +nameserver, and the nameserver sends back a DNS reply packet from it's UDP +port 53 to the client. + +Netfilter trats this as a connection. The first packet (the DNS request) is +assigned a state of {\it NEW}, because the packet is expected to create a new +'connection'. The dns servers' reply packet is marked as {\it ESTABLISHED}. + +\subsubsection{conntrack application helpers} + +More complex application protocols involving multiple connections need special +support by a so-called ``conntrack application helper module''. Modules in +the stock kernel come for FTP and IRC(DCC). Netfilter CVS currently contains +patches for PPTP, H.323, Eggdrop botnet, tftp ald talk. We're still lacking +a lot of protocols (e.g. SIP, SMB/CIFS) - but they are unlikely to appear +until somebody really needs them and either develops them on his own or +funds development. + +\subsubsection{Integration of connection tracking with iptables} + +As stated earlier, conntrack doesn't impose any policy on packets. It just +determines the relation of a packet to already existing connections. To base +packet filtering decision on this sate information, the iptables {\it state} +match can be used. Every packet is within one of the following categories: + +\begin{itemize} +\item +{\bf NEW}: packet would create a new connection, if it survives +\item +{\bf ESTABLISHED}: packet is part of an already established connection +(either direction) +\item +{\bf RELATED}: packet is in some way related to an already established connection, e.g. ICMP errors or FTP data sessions +\item +{\bf INVALID}: conntrack is unable to derive conntrack information from this packet. Please note that all multicast or broadcast packets fall in this category. +\end{itemize} + +\subsection{NAT Subsystem} + +The NAT (Network Address Translation) subsystem is probably the worst +documented subsystem within the whole framework. This has two reasons: NAT is +nasty and complicated. The Linux 2.4.x NAT implementation is easy to use, so +nobody needs to know the nasty details. + +Nonetheless, as I was traditionally concentrating most on the conntrack and NAT +systems, I will give a short overview. + +NAT uses almost all of the previously described subsystems: +\begin{itemize} +\item +IP tables to specify which packets to NAT in which particular way. NAT +registers a ``nat'' table with PREROUTING, POSTROUTING and OUTPUT chains. +\item +Connection tracking to associate NAT state with the connection. +\item +Netfilter to do the actuall packet manipulation transparent to the rest of the +kernel. NAT registers with NF\_IP\_PRE\_ROUTING, NF\_IP\_POST\_ROUTING, +NF\_IP\_LOCAL\_IN and NF\_IP\_LOCAL\_OUT. +\end{itemize} + +The NAT implementation supports all kinds of different nat; Source NAT, +Destination NAT, NAT to address/port ranges, 1:1 NAT, ... + +This fundamental design principle is still frequently misunderstood:\\ +The information about which NAT mappings apply to a certain connection +is only gathered once - with the first packet of every connection. + +So let's start to look at the life of a poor to-be-nat'ed packet. +For ease of understanding, I have chosen to describe the most frequently +used NAT scenario: Source NAT of a forwarded packet. Let's assume the +packet has an original source address of 1.1.1.1, an original destination +address of 2.2.2.2, and is going to be SNAT'ed to 9.9.9.9. Let's further +ignore the fact that there are port numbers. + +Once upon a time, our poor packet arrives at NF\_IP\_PRE\_ROUTING, where +conntrack has registered with highest priority. This means that a conntrack +entry with the following two tuples is created: +\begin{verbatim} +IP_CT_DIR_ORIGINAL: 1.1.1.1 -> 2.2.2.2 +IP_CT_DIR_REPLY: 2.2.2.2 -> 1.1.1.1 +\end{verbatim} +After conntrack, the packet traverses the PREROUTING chain of the ``nat'' +IP table. Since only destination NAT happens at PREROUTING, no action +occurs. After it's lengthy way through the rest of the network stack, +the packet arrives at the NF\_IP\_POST\_ROUTING hook, where it traverses +the POSTROUTING chain of the ``nat'' table. Here it hits a SNAT rule, +causing the following actions: +\begin{itemize} +\item +Fill in a {\it struct ip\_nat\_manip}, indicating the new source address +and the type of NAT (source NAT at POSTROUTING). This struct is part of the +conntrack entry. +\item +Automatically derive the inverse NAT transormation for the reply packets: +Destination NAT at PREROUTING. Fill in another {\it struct ip\_nat\_manip}. +\item +Alter the REPLY tuple of the conntrack entry to +\begin{verbatim} +IP_CT_DIR_REPLY: 2.2.2.2 -> 9.9.9.9 +\end{verbatim} +\item +Apply the SNAT transformation to the packet +\end{itemize} + +Every other packt within this connection, independent of its direction, +will only execute the last step. Since all NAT information is connected +with the conntrack entry, there is no need to do anything but to apply +the same transormations to all packets witin the same connection. + +\subsection{IPv6 Firewalling with ip6tables} + +Yes, Linux 2.4.x comes with a usable, though incomplete system to secure +your IPv6 network. + +The parts ported to IPv6 are +\begin{itemize} +\item +IP tables (called IP6 tables) +\item +The ``filter'' table +\item +The ``mangle'' table +\item +The userspace library (libip6tc) +\item +The command line tool (ip6tables) +\end{itemize} + +Due to the lack of conntrack and NAT\footnote{for god's sake we don't have NAT +with IPv6}, only traditional, stateless packet filtering is possible. Apart +from the obvious matches/targets, ip6tables can match on +\begin{itemize} +\item +{\it EUI64 checker}; verifies if the MAC address of the sender is the same as in the EUI64 64 least significant bits of the source IPv6 address +\item +{\it frag6 match}, matches on IPv6 fragmentation header +\item +{\it route6 match}, matches on IPv6 routing header +\item +{\it ahesp6 match}, matches on SPIDs within AH or ESP over IPv6 packets +\end{itemize} + +However, the ip6tables code doesn't seem to be used very widely (yet?). +So please expect some potential remaining issues, since it is not tested +as heavily as iptables. + +\subsection{Recent Development} + +Please refer to the spoken word at the presentation. Development at the +time this paper was written can be quite different from development at the +time the presentation is held. + +\section{Thanks} + +I'd like to thank +\begin{itemize} +\item +{\it Linus Torvalds} for starting this interesting UNIX-like kernel +\item +{\it Alan Cox, David Miller, Alexey Kuznetesov, Andi Kleen} for building +(one of?) the world's best TCP/IP stacks. +\item +{\it Paul ``Rusty'' Russell} for starting the netfilter/iptables project +\item +{\it The Netfilter Core Team} for continuing the netfilter/iptables effort +\item +{\it Astaro AG} for partially funding my current netfilter/iptables work +\item +{\it Conectiva Inc.} for partially funding parts of my past netfilter/iptables +work and for inviting me to live in Brazil +\item +{\it samba.org and Kommunikationsnetz Franken e.V.} for hosting the netfilter +homepage, CVS, mailing lists, ... +\end{itemize} + +\end{document} diff --git a/2002/netfilter-internals-lt2002/abstract b/2002/netfilter-internals-lt2002/abstract new file mode 100644 index 0000000..1cc18b0 --- /dev/null +++ b/2002/netfilter-internals-lt2002/abstract @@ -0,0 +1,49 @@ +Linux 2.4.x netfilter/iptables firewalling internals (lt-690870524) + + The Linux 2.4.x kernel series has introduced a totally new kernel firewalling subsystem. It is much more than a plain successor of ipfwadm or ipchains. + + The netfilter/iptables project has a very modular design and it's +sub-projects can be split in several parts: netfilter, iptables, connection +tracking, NAT and packet mangling. + + While most users will already have learned how to use the basic functions +of netfilter/iptables in order to convert their old ipchains firewalls to +iptables, there's more advanced but less used functionality in +netfilter/iptables. + + The presentation covers the design principles behind the netfilter/iptables +implementation. This knowledge enables us to understand how the individual +parts of netfilter/iptables fit together, and for which potential applications +this is useful. + +Topics covered: + +- overview about the internal netfilter/iptables architecture + - the netfilter hooks inside the network protocol stacks + - packet selection with IP tables + - how is connection tracking and NAT integrated into the framework +- the connection tracking system + - how good does it track the TCP state? + - how does it track ICMP and UDP state at all? + - layer 4 protocol helpers (GRE, ...) + - application helpers (ftp, irc, h323, ...) + - restrictions/limitations +- the NAT system + - how does it interact with connection tracking? + - layer 4 protocol helpers + - application helpers (ftp, irc, ...) +- misc + - how far is IPv6 firewalling with ip6tables? + - advances in failover/HA of stateful firewalls + - ivisible firewalls with iptables on a bridge + - userspace packet queueing with QUEUE + - userspace packet logging with ULOG + +Requirements: +- knowledge about the TCP/IP protocol family +- knowledge about general firewalling and packet filtering concepts +- prior experience with linux packet filters + +Audience: +- firewall administrators +- network developers diff --git a/2002/netfilter-internals-lt2002/biography b/2002/netfilter-internals-lt2002/biography new file mode 100644 index 0000000..27b77bd --- /dev/null +++ b/2002/netfilter-internals-lt2002/biography @@ -0,0 +1,22 @@ + Harald Welte is one +of the five netfilter/iptables core +team members, and the current Linux 2.4.x firewalling maintainer. + + His main interest in computing has always been networking. In the few time +left besides netfilter/iptables related work, he's writing obscure documents +like the UUCP +over SSL HOWTO. Other kernel-related projects he has been contributing are +user mode linux and the international (crypto) kernel patch. + + In the past he has been working as an independent IT Consultant working on +closed-source projecst for various companies ranging from banks to +manufacturers of networking gear. During the year 2001 he was living in +Curitiba (Brazil), where he got sponsored for his Linux related work by +Conectiva Inc.. + + Starting with February 2002, Harald has been contracted part-time by +Astaro AG, who are sponsoring him for his +current netfilter/iptables work. + + Harald is living in Erlangen, Germany. + diff --git a/2002/netfilter-internals-lt2002/netfilter-internals-lt2002.mgp b/2002/netfilter-internals-lt2002/netfilter-internals-lt2002.mgp new file mode 100644 index 0000000..9487ff4 --- /dev/null +++ b/2002/netfilter-internals-lt2002/netfilter-internals-lt2002.mgp @@ -0,0 +1,466 @@ +%include "default.mgp" +%default 1 bgrad +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +%nodefault +%back "blue" + +%center +%size 7 + + +Linux 2.4.x netfilter/iptables +firewalling internals + + +%center +%size 4 +by + +Harald Welte + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Contents + + + Introduction + Netfilter hooks in protocol stacks + Packet selection based on IP Tables + The Connection Tracking Subsystem + The NAT Subsystem based on netfilter + iptables + Packet filtering using the 'filter' table + Packet mangling using the 'mangle' table + Advanced netfilter concepts + Current development and Future + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Introduction + +Why did we need netfilter/iptables? +Because ipchains... + + has no infrastructure for passing packets to userspace + makes transparent proxying extremely difficult + has interface address dependent Packet filter rules + has Masquerading implemented as part of packet filtering + code is too complex and intermixed with core ipv4 stack + is neither modular nor extensible + only barely supports one special case of NAT (masquerading) + has only stateless packet filtering + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Introduction + +Who's behind netfilter/iptables + Paul 'Rusty' Russel + co-author of iptables in Linux 2.2 + was paid by Watchguard for about one Year of development + James Morris + userspace queuing (kernel, library and tools) + REJECT target + Marc Boucher + NAT and packet filtering controlled by one command + Mangle table + Harald Welte + Conntrack+NAT helper infrastructure (newnat) + Userspace packet logging (ULOG) + PPTP and IRC conntrack/NAT helpers + Jozsef Kadlecsik + TCP window tracking + H.323 conntrack + NAT helper + Continued newnat development + Non-core team contributors + http://www.netfilter.org/scoreboard/ +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Netfilter Hooks + +What is netfilter? + + System of callback functions within network stack + Callback function to be called for every packet traversing certain point (hook) within network stack + Protocol independent framework + Hooks in layer 3 stacks (IPv4, IPv6, DECnet, ARP) + Multiple kernel modules can register with each of the hooks + Asynchronous packet handling in userspace (ip_queue) + +Traditional packet filtering, NAT, ... is implemented on top of this framework + +Can be used for other stuff interfacing with the core network stack, like DECnet routing daemon. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Netfilter Hooks + +Netfilter architecture in IPv4 +%font "courier" + + --->[1]--->[ROUTE]--->[3]--->[4]---> + | ^ + | | + | [ROUTE] + v | + [2] [5] + | ^ + | | + v | + +%font "standard" +1=NF_IP_PRE_ROUTING +2=NF_IP_LOCAL_IN +3=NF_IP_FORWARD +4=NF_IP_POST_ROUTING +5=NF_IP_LOCAL_OUT +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Netfilter Hooks + +Netfilter Hooks + + Any kernel module may register a callback function at any of the hooks + + The module has to return one of the following constants + + NF_ACCEPT continue traversal as normal + NF_DROP drop the packet, do not continue + NF_STOLEN I've taken over the packet do not continue + NF_QUEUE enqueue packet to userspace + NF_REPEAT call this hook again + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +IP tables + +Packet selection using IP tables + + The kernel provides generic IP tables support + + Each kernel module may create it's own IP table + + The three major parts of 2.4 firewalling subsystem are implemented using IP tables + Packet filtering table 'filter' + NAT table 'nat' + Packet mangling table 'mangle' + + Can potentially be used for other stuff, i.e. IPsec SPDB + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +IP Tables + +Managing chains and tables + + An IP table consists out of multiple chains + A chain consists out of a list of rules + Every single rule in a chain consists out of + match[es] (rule executed if all matches true) + target (what to do if the rule is matched) + +%size 4 +matches and targets can either be builtin or implemented as kernel modules + +%size 6 + The userspace tool iptables is used to control IP tables + handles all different kinds of IP tables + supports a plugin/shlib interface for target/match specific options + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +IP Tables + +Basic iptables commands + + To build a complete iptables command, we must specify + which table to work with + which chain in this table to use + an operation (insert, add, delete, modify) + one or more matches (optional) + a target + +The syntax is +%font "typewriter" +%size 3 +iptables -t table -Operation chain -j target match(es) +%font "standard" +%size 5 + +Example: +%font "typewriter" +%size 3 +iptables -t filter -A INPUT -j ACCEPT -p tcp --dport smtp +%font "standard" +%size 5 + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +IP Tables + +Matches + Basic matches + -p protocol (tcp/udp/icmp/...) + -s source address (ip/mask) + -d destination address (ip/mask) + -i incoming interface + -o outgoing interface + + Match extensions (examples) + tcp/udp TCP/udp source/destination port + icmp ICMP code/type + ah/esp AH/ESP SPID match + mac source MAC address + mark nfmark + length match on length of packet + limit rate limiting (n packets per timeframe) + owner owner uid of the socket sending the packet + tos TOS field of IP header + ttl TTL field of IP header + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +IP Tables + +Targets + very dependent on the particular table. + + Table specific targets will be discussed later + + Generic Targets, always available + ACCEPT accept packet within chain + DROP silently drop packet + QUEUE enqueue packet to userspace + LOG log packet via syslog + ULOG log packet via ulogd + RETURN return to previous (calling) chain + foobar jump to user defined chain + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Packet Filtering + +Overview + + Implemented as 'filter' table + Registers with three netfilter hooks + + NF_IP_LOCAL_IN (packets destined for the local host) + NF_IP_FORWARD (packets forwarded by local host) + NF_IP_LOCAL_OUT (packets from the local host) + +Each of the three hooks has attached one chain (INPUT, FORWARD, OUTPUT) + +Every packet passes exactly one of the three chains. Note that this is very different compared to the old 2.2.x ipchains behaviour. + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Packet Filtering + +Targets available within 'filter' table + + Builtin Targets to be used in filter table + ACCEPT accept the packet + DROP silently drop the packet + QUEUE enqueue packet to userspace + RETURN return to previous (calling) chain + foobar user defined chain + + Targets implemented as loadable modules + REJECT drop the packet but inform sender + MIRROR change source/destination IP and resend + LOG log via syslog + ULOG log via userspace + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Connection Tracking Subsystem + + Connection tracking... + + implemented seperately from NAT + enables stateful filtering + implementation + hooks into NF_IP_PRE_ROUTING to track packets + hooks into NF_IP_POST_ROUTING and NF_IP_LOCAL_IN to see if packet passed filtering rules + protocol modules (currently TCP/UDP/ICMP) + application helpers currently (FTP,IRC,H.323,talk,SNMP) + divides packets in the following four categories + NEW - would establish new connection + ESTABLISHED - part of already established connection + RELATED - is related to established connection + INVALID - (multicast, errors...) + does _NOT_ filter packets itself + can be utilized by iptables using the 'state' match + is used by NAT Subsystem + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Network Address Translation + +Overview + + Previous Linux Kernels only implemented one special case of NAT: Masquerading + Linux 2.4.x can do any kind of NAT. + NAT subsystem implemented on top of netfilter, iptables and conntrack + NAT subsystem registers with all five netfilter hooks + 'nat' Table registers chains PREROUTING, POSTROUTING and OUTPUT + Following targets available within 'nat' Table + SNAT changes the packet's source whille passing NF_IP_POST_ROUTING + DNAT changes the packet's destination while passing NF_IP_PRE_ROUTING + MASQUERADE is a special case of SNAT + REDIRECT is a special case of DNAT + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Network Address Translation + + Source NAT + SNAT Example: +%font "typewriter" +%size 3 +iptables -t nat -A POSTROUTING -j SNAT --to-source 1.2.3.4 -s 10.0.0.0/8 +%font "standard" +%size 4 + + MASQUERADE Example: +%font "typewriter" +%size 3 +iptables -t nat -A POSTROUTING -j MASQUERADE -o ppp0 +%font "standard" +%size 5 + + Destination NAT + DNAT example +%font "typewriter" +%size 3 +iptables -t nat -A PREROUTING -j DNAT --to-destination 1.2.3.4:8080 -p tcp --dport 80 -i eth1 +%font "standard" +%size 4 + + REDIRECT example +%font "typewriter" +%size 3 +iptables -t nat -A PREROUTING -j REDIRECT --to-port 3128 -i eth1 -p tcp --dport 80 +%font "standard" +%size 5 + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Packet Mangling + + Purpose of mangle table + packet manipulation except address manipulation + + Integration with netfilter + 'mangle' table hooks in all five netfilter hooks + priority: after conntrack + + Targets specific to the 'mangle' table: + DSCP - manipulate DSCP field + IPV4OPTSSTRIP - strip IPv4 options + MARK - change the nfmark field of the skb + TCPMSS - set TCP MSS option + TOS - manipulate the TOS bits + TTL - set / increase / decrease TTL field + +Simple example: +%font "typewriter" +%size 3 +iptables -t mangle -A PREROUTING -j MARK --set-mark 10 -p tcp --dport 80 + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Advanced Netfilter concepts + +%size 4 + Userspace logging + flexible replacement for old syslog-based logging + packets to userspace via multicast netlink sockets + easy-to-use library (libipulog) + plugin-extensible userspace logging daemon (ulogd) + Can even be used to directly log into MySQL + + Queuing + reliable asynchronous packet handling + packets to userspace via unicast netlink socket + easy-to-use library (libipq) + provides Perl bindings + experimental queue multiplex daemon (ipqmpd) + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Current Development and Future + +Netfilter (although it proved very stable) is still work in progress. + + Areas of current development + infrastructure for conntrack manipulation from userspace + failover of stateful firewalls + making iptables layer3 independent (pkttables) + new userspace library (libiptables) to hide plugins from apps + more matches and targets for advanced functions (pool, hashslot) + more conntrack and NAT modules (RPC, SNMP, SMB, ...) + better IPv6 support (conntrack, more matches / targets) + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Thanks + + Thanks to + the BBS people, Z-Netz, FIDO, ... + for heavily increasing my computer usage in 1992 + + KNF + for bringing me in touch with the internet as early as 1994 + for providing a playground for technical people + for telling me about the existance of Linux! + + Alan Cox, Alexey Kuznetsov, David Miller, Andi Kleen + for implementing (one of?) the world's best TCP/IP stacks + + Paul 'Rusty' Russell + for starting the netfilter/iptables project + for trusting me to maintain it today + + Astaro AG + for sponsoring parts of my netfilter work + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Availability of slides / Links + +The slides and the an according paper of this presentation are available at + http://www.gnumonks.org/ + +The netfilter homepage + http://www.netfilter.org/ + diff --git a/2002/netfilter-internals-lt2002/netfilter-internals-lt2002.tex b/2002/netfilter-internals-lt2002/netfilter-internals-lt2002.tex new file mode 100644 index 0000000..c3a28ea --- /dev/null +++ b/2002/netfilter-internals-lt2002/netfilter-internals-lt2002.tex @@ -0,0 +1,537 @@ +\documentclass{article} +\usepackage{german} +\usepackage{fancyheadings} +\usepackage{a4} + +\setlength{\oddsidemargin}{0in} +\setlength{\evensidemargin}{0in} +\setlength{\topmargin}{0.0in} +\setlength{\headheight}{0in} +\setlength{\headsep}{0in} +\setlength{\textwidth}{6.5in} +\setlength{\textheight}{9.5in} +\setlength{\parindent}{0in} +\setlength{\parskip}{0.05in} + + +\begin{document} +\title{Linux 2.4.x netfilter/iptables firewalling internals} + +\author{Harald Welte\\ + laforge@gnumonks.org\\ + \copyright{}2002 H. Welte} + +\date{25. April 2002} + +\maketitle + +\setcounter{section}{0} +\setcounter{subsection}{0} +\setcounter{subsubsection}{0} + +\section{Introduction} +The Linux 2.4.x kernel series has introduced a totally new kernel firewalling +subsystem. It is much more than a plain successor of ipfwadm or ipchains. + +The netfilter/iptables project has a very modular design and it's +sub-projects can be split in several parts: netfilter, iptables, connection +tracking, NAT and packet mangling. + +While most users will already have learned how to use the basic functions +of netfilter/iptables in order to convert their old ipchains firewalls to +iptables, there's more advanced but less used functionality in +netfilter/iptables. + +The presentation covers the design principles behind the netfilter/iptables +implementation. This knowledge enables us to understand how the individual +parts of netfilter/iptables fit together, and for which potential applications +this is useful. + +\section{Internal netfilter/iptables architecture} + +\subsection{Netfilter hooks in protocol stacks} + +One of the major motivations behind the redesign of the linux packet +filtering and NAT system during the 2.3.x kernel series was the widespread +firewall specific code parts within the core IPv4 stack. Ideally the core +IPv4 stack (as used by regular hosts and routers) shouldn't contain any +firewalling specific code, resulting in no unwanted interaction and less +code complexity. This desire lead to the invention of {\it netfilter}. + +\subsubsection{Architecture of netfilter} + +Netfilter is basically a system of callback functions within the network +stack. It provides a non-portable API towards in-kernel networking +extensions. + +What we call {\it netfilter hook} is a well-defined call-out point within a +layer three protocol stack, such as IPv4, IPv6 or DECnet. Any layer three +network stack can define an arbitrary number of hooks, usually placed at +strategic points within the packet flow. + +Any other kernel code can now subsequently register callback functions for +any of these hooks. As in most sytems will be more than one callback +function registered for a particular hook, a {\it priority} is specified upon +registration of the callback function. This priority defines the order in +which the individual callback functions at a particular hook are called. + +The return value of any registered callback functions can be: +\begin{itemize} +\item +{\bf NF\_ACCEPT}: continue traversal as usual +\item +{\bf NF\_DROP}: drop the packet; do not continue traversal +\item +{\bf NF\_STOLEN}: callback function has taken over the packet; do not continue +\item +{\bf NF\_QUEUE}: enqueue the packet to userspace +\item +{\bf NF\_REPEAT}: call this hook again +\end{itemize} + +\subsubsection{Netfilter hooks within IPv4} + +The IPv4 stack provides five netfilter hooks, which are placed at the +following peculiar places within the code: + +\begin{verbatim} + --->[1]--->[ROUTE]--->[3]--->[4]---> + | ^ + | | + | [ROUTE] + v | + [2] [5] + | ^ + | | + v | + + local processes +\end{verbatim} + +Packets received on any network interface arrive at the left side of the +diagram. After the verification of the IP header checksum, the +NF\_IP\_PRE\_ROUTING [1] hook is traversed. + +If they ``survive'' (i.e. NF\_ACCEPT is returned), the packet enters the +routing code. Where we continue from here depends on the destintion of the +packet. + +Packets with a local destination (i.e. packets where the destination address is +one of the own IP addresses of the host) traverse the NF\_IP\_LOCAL\_IN [2] +hook. If all callback function return NF\_ACCEPT, the packet is finally passed +to the socket code, which eventually passes the packet to a local process. + +Packets with a remote destination (i.e. packets which are forwarded by the +local machine) traverse the NF\_IP\_FORWARD [3] hook. If they ``survive'', +they finally pass the NF\_IP\_POST\_ROUTING [4] hook and are sent off the +outgoing network interface. + +Locally generated packets first traverse the NF\_IP\_LOCAL\_OUT [5] hook, then +enter the routing code, and finally go through the NF\_IP\_POST\_ROUTING [4] +hook before being sent off the outgoing network interface. + +\subsubsection{Netfilter hooks within IPv6} + +As the IPv4 and IPv6 protocols are very similar, the netfilter hooks within the +IPv6 stack are placed at exactly the same locations as in the IPv4 stack. The +only change are the hook names: NF\_IP6\_PRE\_ROUTING, NF\_IP6\_LOCAL\_IN, +NF\_IP6\_FORWARD, NF\_IP6\_POST\_ROUTING, NF\_IP6\_LOCAL\_OUT. + +\subsubsection{Netfilter hooks within DECnet} + +There are seven decnet hooks. The first five hooks (NF\_DN\_PRE\_ROUTING, +NF\_DN\_LOCAL\_IN, NF\_DN\_FORWARD, NF\_DN\_LOCAL\_OUT, NF\_DN\_POST\_ROUTING) +are prretty much the same as in IPv4. The last two hooks (NF\_DN\_HELLO, +NF\_DN\_ROUTE) are used in conjunction with DECnet Hello and Routing packets. + +\subsubsection{Netfilter hooks within ARP} + +Recent kernels\footnote{IIRC, starting with 2.4.19-pre3} have added support for netfilter hooks within the ARP code. +There are two hooks: NF\_ARP\_IN and NF\_ARP\_OUT, for incoming and outgoing +ARP packets respectively. + +\subsubsection{Netfilter hooks within IPX} + +There have been experimental patches to add netfilter hooks to the IPX code, +but they never got integrated into the kernel source. + +\subsection{Packet selection using IP Tables} + +The IP tables core (ip\_tables.o) provides a generic layer for evaluation +of rulesets. + +An IP table consists out of an arbitrary number of {\it chains}, which in turn +consist out of a linear list of {\it rules}, which again consist out of any +number of {\it matches} and one {\it target}. + +{\it Chains} can further be devided into two classes: Either {\it builtin +chains} or {\it user-defined chains}. Builtin chains are always present, they +are created upon table registration. They are also the entry points for table +iteration. User defined chains are created at runtime upon user interaction. + +{\it Matches} specify the matching criteria, there can be zero or more matches + +{\it Targets} specify the action which is to be executed in case {\bf all} +matches match. There can only be a single target per rule. + +Matches and targets can either be {\it builtin} or {\it linux kernel modules}. + +There are two special targets: +\begin{itemize} +\item +By using a chain name as target, it is possible to jump to the respective chain +in case the matches match. +\item +By using the RETURN target, it is possible to return to the previous (calling) +chain +\end{itemize} + +The IP tables core handles the following functions +\begin{itemize} +\item +Registering and unregistering tables +\item +Registering and unregistering matches and targets (can be implemented as linux kernel modules) +\item +Kernel / userspace interface for manipulation of IP tables +\item +Traversal of IP tables +\end{itemize} + +\subsubsection{Packet filtering unsing the ``filter'' table} + +Traditional packet filtering (i.e. the successor to ipfwadm/ipchains) takes +place in the ``filter'' table. Packet filtering works like a sieve: A packet +is (in the end) either dropped or accepted - but never modified. + +The ``filter'' table is implemented in the {\it iptable\_filter.o} module +and contains three builtin chains: + +\begin{itemize} +\item +{\bf INPUT} attaches to NF\_IP\_LOCAL\_IN +\item +{\bf FORWARD} attaches to NF\_IP\_FORWARD +\item +{\bf OUTPUT} attaches to NF\_IP\_LOCAL\_OUT +\end{itemize} + +The placement of the chains / hooks is done in such way, that evey concievable +packet always traverses only one of the built-in chains. Packets destined for +the local host traverse only INPUT, packets forwarded only FORWARD and +locally-originated packets only OUTPUT. + +\subsubsection{Packet mangling using the ``mangle'' table} + +As stated above, operations which would modify a packet do not belong in the +``filter'' table. The ``mangle'' table is available for all kinds of packet +manipulation - but not manipulation of addresses (which is NAT). + +The mangle table attaches to all five netfilter hooks and provides the +respectiva builtin chains (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING) +\footnote{This has changed through recent 2.4.x kernel series, old kernels may +only support three (PREROUTING, POSTROUTING, OUTPUT) chains.}. + +\subsection{Connection Tracking Subsystem} + +Traditional packet filters can only match on matching criteria within the +currently processed packet, like source/destination IP address, port numbers, +TCP flags, etc. As most applications have a notion of connections or at least +a request/response style protocol, there is a lot of information which can not +be derived from looking at a single packet. + +Thus, modern (stateful) packet filters attempt to track connections (flows) +and their respective protocol states for all traffic through the packet +filter. + +Connection tracking within linux is implemented as a netfilter module, called +ip\_conntrack.o. + +Before describing the connection tracking subsystem, we need to describe a couple of definitions and primitives used throughout the conntrack code. + +A connection is represented within the conntrack subsystem using {\it struct +ip\_conntrack}, also called {\it connection tracking entry}. + +Connection tracking is utilizing {\it conntrack tuples}, which are tuples +consisting out of (srcip, srcport, dstip, dstport, l4prot). A connection is +uniquely identified by two tuples: The tuple in the original direction +(IP\_CT\_DIR\_ORIGINAL) and the tuple for the reply direction +(IP\_CT\_DIR\_REPLY). + +Connection tracking itself does not drop packets\footnote{well, in some rare +cases in combination with NAT it needs to drop. But don't tell anyone, this is +secret.} or impose any policy. It just associates every packet with a +connection tracking entry, which in turn has a particular state. All other +kernel code can use this state information\footnote{state information is +internally represented via the {\it struct sk\_buff.nfct} structure member of a +packet.}. + +\subsubsection{Integration of conntrack with netfilter} + +If the ip\_conntrack.o module is registered with netfilter, it attaches to the +NF\_IP\_PRE\_ROUTING, NF\_IP\_POST\_ROUTING, NF\_IP\_LOCAL\_IN and +NF\_IP\_LOCAL\_OUT hooks. + +Because forwarded packets are the most common case on firewalls, I will only +describe how connection tracking works for forwarded packets. The two relevant +hooks for forwarded packets are NF\_IP\_PRE\_ROUTING and NF\_IP\_POST\_ROUTING. + +Every time a packet arrives at the NF\_IP\_PRE\_ROUTING hook, connection +tracking creates a conntrack tuple from the packet. It then compares this +tuple to the original and reply tuples of all already-seen connections +\footnote{Of course this is not implemented as a linear search over all existing connections.} to find out if this just-arrived packet belongs to any existing +connection. If there is no match, a new conntrack table entry (struct +ip\_conntrack) is created. + +Let's assume the case where we have already existing connections but are +starting from scratch. + +The first packet comes in, we derive the tuple from the packet headers, look up +the conntrack hash table, don't find any matching entry. As a result, we +create a new struct ip\_conntrack. This struct ip\_conntrack is filled with +all necessarry data, like the original and reply tuple of the connection. +How do we know the reply tuple? By inverting the source and destination +parts of the original tuple.\footnote{So why do we need two tuples, if they can +be derived from each other? Wait until we discuss NAT.} +Please note that this new struct ip\_conntrack is {\bf not} yet placed +into the conntrack hash table. + +The packet is now passed on to other callback functions which have registered +with a lower priority at NF\_IP\_PRE\_ROUTING. It then continues traversal of +the network stack as usual, including all respective netfilter hooks. + +If the packet survives (i.e. is not dropped by the routing code, network stack, +firewall ruleset, ...), it re-appears at NF\_IP\_POST\_ROUTING. In this case, +we can now safely assume that this packet will be sent off on the outgoing +interface, and thus put the connection tracking entry which we created at +NF\_IP\_PRE\_ROUTING into the conntrack hash table. This process is called +{\it confirming the conntrack}. + +The connection tracking code itself is not monolithic, but consists out of a +couple of seperate modules\footnote{They don't actually have to be seperate +kernel modules; e.g. TCP, UDP and ICMP tracking modules are all part of +the linux kernel module ip\_conntrack.o}. Besides the conntrack core, there +are two important kind of modules: Protocol helpers and application helpers. + +Protocol helpers implement the layer-4-protocol specific parts. They currently +exist for TCP, UDP and ICMP (an experimental helper for GRE exists). + +\subsubsection{TCP connection tracking} + +As TCP is a connection oriented protocol, it is not very difficult to imagine +how conntection tracking for this protocol could work. There are well-defined +state transitions possible, and conntrack can decide which state transitions +are valid within the TCP specification. In reality it's not all that easy, +since we cannot assume that all packets that pass the packet filter actually +arrive at the receiving end, ... + +It is noteworthy that the standard connection tracking code does {\bf not} +do TCP sequence number and window tracking. A well-maintained patch to add +this feature exists almost as long as connection tracking itself. It will +be integrated with the 2.5.x kernel. The problem with window tracking is +it's bad interaction with connection pickup. The TCP conntrack code is able to +pick up already existing connections, e.g. in case your firewall was rebooted. +However, connection pickup is conflicting with TCP window tracking: The TCP +window scaling option is only transferred at connection setup time, and we +don't know about it in case of pickup... + +\subsubsection{ICMP tracking} + +ICMP is not really a connection oriented protocol. So how is it possible to +do connection tracking for ICMP? + +The ICMP protocol can be split in two groups of messages + +\begin{itemize} +\item +ICMP error messages, which sort-of belong to a different connection +ICMP error messages are associated {\it RELATED} to a different connection. +(ICMP\_DEST\_UNREACH, ICMP\_SOURCE\_QUENCH, ICMP\_TIME\_EXCEEDED, +ICMP\_PARAMETERPROB, ICMP\_REDIRECT). +\item +ICMP queries, which have a request->reply character. So what the conntrack +code does, is let the request have a state of {\it NEW}, and the reply +{\it ESTABLISHED}. The reply closes the connection immediately. +(ICMP\_ECHO, ICMP\_TIMESTAMP, ICMP\_INFO\_REQUEST, ICMP\_ADDRESS) +\end{itemize} + +\subsubsection{UDP connection tracking} + +UDP is designed as a connectionless datagram protocol. But most common +protocols using UDP as layer 4 protocol have bi-directional UDP communication. +Imagine a DNS query, where the client sends an UDP frame to port 53 of the +nameserver, and the nameserver sends back a DNS reply packet from it's UDP +port 53 to the client. + +Netfilter trats this as a connection. The first packet (the DNS request) is +assigned a state of {\it NEW}, because the packet is expected to create a new +'connection'. The dns servers' reply packet is marked as {\it ESTABLISHED}. + +\subsubsection{conntrack application helpers} + +More complex application protocols involving multiple connections need special +support by a so-called ``conntrack application helper module''. Modules in +the stock kernel come for FTP and IRC(DCC). Netfilter CVS currently contains +patches for PPTP, H.323, Eggdrop botnet, tftp ald talk. We're still lacking +a lot of protocols (e.g. SIP, SMB/CIFS) - but they are unlikely to appear +until somebody really needs them and either develops them on his own or +funds development. + +\subsubsection{Integration of connection tracking with iptables} + +As stated earlier, conntrack doesn't impose any policy on packets. It just +determines the relation of a packet to already existing connections. To base +packet filtering decision on this sate information, the iptables {\it state} +match can be used. Every packet is within one of the following categories: + +\begin{itemize} +\item +{\bf NEW}: packet would create a new connection, if it survives +\item +{\bf ESTABLISHED}: packet is part of an already established connection +(either direction) +\item +{\bf RELATED}: packet is in some way related to an already established connection, e.g. ICMP errors or FTP data sessions +\item +{\bf INVALID}: conntrack is unable to derive conntrack information from this packet. Please note that all multicast or broadcast packets fall in this category. +\end{itemize} + +\subsection{NAT Subsystem} + +The NAT (Network Address Translation) subsystem is probably the worst +documented subsystem within the whole framework. This has two reasons: NAT is +nasty and complicated. The Linux 2.4.x NAT implementation is easy to use, so +nobody needs to know the nasty details. + +Nonetheless, as I was traditionally concentrating most on the conntrack and NAT +systems, I will give a short overview. + +NAT uses almost all of the previously described subsystems: +\begin{itemize} +\item +IP tables to specify which packets to NAT in which particular way. NAT +registers a ``nat'' table with PREROUTING, POSTROUTING and OUTPUT chains. +\item +Connection tracking to associate NAT state with the connection. +\item +Netfilter to do the actuall packet manipulation transparent to the rest of the +kernel. NAT registers with NF\_IP\_PRE\_ROUTING, NF\_IP\_POST\_ROUTING, +NF\_IP\_LOCAL\_IN and NF\_IP\_LOCAL\_OUT. +\end{itemize} + +The NAT implementation supports all kinds of different nat; Source NAT, +Destination NAT, NAT to address/port ranges, 1:1 NAT, ... + +This fundamental design principle is still frequently misunderstood:\\ +The information about which NAT mappings apply to a certain connection +is only gathered once - with the first packet of every connection. + +So let's start to look at the life of a poor to-be-nat'ed packet. +For ease of understanding, I have chosen to describe the most frequently +used NAT scenario: Source NAT of a forwarded packet. Let's assume the +packet has an original source address of 1.1.1.1, an original destination +address of 2.2.2.2, and is going to be SNAT'ed to 9.9.9.9. Let's further +ignore the fact that there are port numbers. + +Once upon a time, our poor packet arrives at NF\_IP\_PRE\_ROUTING, where +conntrack has registered with highest priority. This means that a conntrack +entry with the following two tuples is created: +\begin{verbatim} +IP_CT_DIR_ORIGINAL: 1.1.1.1 -> 2.2.2.2 +IP_CT_DIR_REPLY: 2.2.2.2 -> 1.1.1.1 +\end{verbatim} +After conntrack, the packet traverses the PREROUTING chain of the ``nat'' +IP table. Since only destination NAT happens at PREROUTING, no action +occurs. After it's lengthy way through the rest of the network stack, +the packet arrives at the NF\_IP\_POST\_ROUTING hook, where it traverses +the POSTROUTING chain of the ``nat'' table. Here it hits a SNAT rule, +causing the following actions: +\begin{itemize} +\item +Fill in a {\it struct ip\_nat\_manip}, indicating the new source address +and the type of NAT (source NAT at POSTROUTING). This struct is part of the +conntrack entry. +\item +Automatically derive the inverse NAT transormation for the reply packets: +Destination NAT at PREROUTING. Fill in another {\it struct ip\_nat\_manip}. +\item +Alter the REPLY tuple of the conntrack entry to +\begin{verbatim} +IP_CT_DIR_REPLY: 2.2.2.2 -> 9.9.9.9 +\end{verbatim} +\item +Apply the SNAT transformation to the packet +\end{itemize} + +Every other packt within this connection, independent of its direction, +will only execute the last step. Since all NAT information is connected +with the conntrack entry, there is no need to do anything but to apply +the same transormations to all packets witin the same connection. + +\subsection{IPv6 Firewalling with ip6tables} + +Yes, Linux 2.4.x comes with a usable, though incomplete system to secure +your IPv6 network. + +The parts ported to IPv6 are +\begin{itemize} +\item +IP tables (called IP6 tables) +\item +The ``filter'' table +\item +The ``mangle'' table +\item +The userspace library (libip6tc) +\item +The command line tool (ip6tables) +\end{itemize} + +Due to the lack of conntrack and NAT\footnote{for god's sake we don't have NAT +with IPv6}, only traditional, stateless packet filtering is possible. Apart +from the obvious matches/targets, ip6tables can match on +\begin{itemize} +\item +{\it EUI64 checker}; verifies if the MAC address of the sender is the same as in the EUI64 64 least significant bits of the source IPv6 address +\item +{\it frag6 match}, matches on IPv6 fragmentation header +\item +{\it route6 match}, matches on IPv6 routing header +\item +{\it ahesp6 match}, matches on SPIDs within AH or ESP over IPv6 packets +\end{itemize} + +However, the ip6tables code doesn't seem to be used very widely (yet?). +So please expect some potential remaining issues, since it is not tested +as heavily as iptables. + +\subsection{Recent Development} + +Please refer to the spoken word at the presentation. Development at the +time this paper was written can be quite different from development at the +time the presentation is held. + +\section{Thanks} + +I'd like to thank +\begin{itemize} +\item +{\it Linus Torvalds} for starting this interesting UNIX-like kernel +\item +{\it Alan Cox, David Miller, Alexey Kuznetesov, Andi Kleen} for building +(one of?) the world's best TCP/IP stacks. +\item +{\it Paul ``Rusty'' Russell} for starting the netfilter/iptables project +\item +{\it The Netfilter Core Team} for continuing the netfilter/iptables effort +\item +{\it Astaro AG} for partially funding my current netfilter/iptables work +\item +{\it Conectiva Inc.} for partially funding parts of my past netfilter/iptables +work and for inviting me to live in Brazil +\item +{\it samba.org and Kommunikationsnetz Franken e.V.} for hosting the netfilter +homepage, CVS, mailing lists, ... +\end{itemize} + +\end{document} diff --git a/2002/netfilter-knf2002/abstract b/2002/netfilter-knf2002/abstract new file mode 100644 index 0000000..bf43544 --- /dev/null +++ b/2002/netfilter-knf2002/abstract @@ -0,0 +1,50 @@ +Firewalling mit netfilter/iptables unter Linux 2.4.x + +Der Linux 2.4.x Kernel bietet eine fortgeschrittene Infrastruktur, genannt +netfilter, auf deren Basis ein Paketfilter, NAT und sonstige +Paket-Manipulationen implementiert sind. + +Das gesamte Firewalling-Subsystem wurde gegenueber Kernel 2.2.x neu entwickelt. +Das netfilter/iptables System laesst alles bisher unter Linux existierende +(ipfwadm, ipchains) wie aus grauer Vorzeit erscheinen. + +netfilter/iptables bietet neben dem traditionellen Paketfilter auch optional +Connection Tracking, mittels dessen sich im Handumdrehen eine Stateful +Firewall realisieren laesst. Auch das NAT (Network Address Translation) +System ist jetzt flexibel genug, um saemtliche Formen von NAT anbieten +zu koennen: source NAT, destination NAT, static NAT, NAPT, ... + +Die hohe Modularitaet resultiert in einer sehr leichten Erweiterbarkeit, +so dass in einfacher Weise neue Erweiterungen zum Firewalling-System +entwickelt werden koennen. + +Der Vortrag beschreibt die unterschiedlichen Teile des netfilter/iptables +Systems und gibt dadurch einen Ueberblick ueber dessen Moeglichkeiten und +Anwendungsszenarien. Er beschaeftigt sich mit den folgenden Themen: + +- netfilter/iptables architektur + - netfilter hooks im Netzwerk-Stack + - IP tables als Regelbeschreibung +- Paketfilter +- Connection Tracking +- Network Address Translation + - source NAT + - destination NAT + - Masquerading + - transparent proxy support +- Packet mangling +- Userspace packet queuing +- Userspace packet logging + + +Voraussetzungen: +- Wissen ueber TCP/IP, Routing +- Grundlagen ueber Firewalling (insbesondere Paketfilter) +- Gewisse Grundkenntnisse ueber die Linux/Unix Architektur + + +Ueber den Vortragenden: +Harald Welte ist seit 1995 aktives KNF-Mitglied und der derzeitige +stellvertretende Technische Kontakt des KNF. Er ist der Maintainer des +netfilter/iptables Firewalling-Subsystems im Linux 2.4.x und +2.5.x Kernel und war massgeblich an dessen Entwicklung beteiligt. diff --git a/2002/netfilter-knf2002/netfilter-knf2002.mgp b/2002/netfilter-knf2002/netfilter-knf2002.mgp new file mode 100644 index 0000000..4523dd3 --- /dev/null +++ b/2002/netfilter-knf2002/netfilter-knf2002.mgp @@ -0,0 +1,466 @@ +%include "default.mgp" +%default 1 bgrad +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +%nodefault +%back "blue" + +%center +%size 7 + + +The netfilter/iptables framework in +Linux 2.4.x + + +%center +%size 4 +by + +Harald Welte + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Contents + + + Introduction + Netfilter hooks in protocol stacks + Packet selection based on IP Tables + The Connection Tracking Subsystem + The NAT Subsystem based on netfilter + iptables + Packet filtering using the 'filter' table + Packet mangling using the 'mangle' table + Advanced netfilter concepts + Current development and Future + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Introduction + +Why did we need netfilter/iptables? +Because ipchains... + + has no infrastructure for passing packets to userspace + makes transparent proxying extremely difficult + has interface address dependent Packet filter rules + has Masquerading implemented as part of packet filtering + code is too complex and intermixed with core ipv4 stack + is neither modular nor extensible + only barely supports one special case of NAT (masquerading) + has only stateless packet filtering + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Introduction + +Who's behind netfilter/iptables + Paul 'Rusty' Russel + co-author of iptables in Linux 2.2 + was paid by Watchguard for about one Year of development + James Morris + userspace queuing (kernel, library and tools) + REJECT target + Marc Boucher + NAT and packet filtering controlled by one command + Mangle table + Harald Welte + Conntrack+NAT helper infrastructure (newnat) + Userspace packet logging (ULOG) + PPTP and IRC conntrack/NAT helpers + Jozsef Kadlecsik + TCP window tracking + H.323 conntrack + NAT helper + Continued newnat development + Non-core team contributors + http://www.netfilter.org/scoreboard/ +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Netfilter Hooks + +What is netfilter? + + System of callback functions within network stack + Callback function to be called for every packet traversing certain point (hook) within network stack + Protocol independent framework + Hooks in layer 3 stacks (IPv4, IPv6, DECnet, ARP) + Multiple kernel modules can register with each of the hooks + Asynchronous packet handling in userspace (ip_queue) + +Traditional packet filtering, NAT, ... is implemented on top of this framework + +Can be used for other stuff interfacing with the core network stack, like DECnet routing daemon. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Netfilter Hooks + +Netfilter architecture in IPv4 +%font "courier" + + --->[1]--->[ROUTE]--->[3]--->[4]---> + | ^ + | | + | [ROUTE] + v | + [2] [5] + | ^ + | | + v | + +%font "standard" +1=NF_IP_PRE_ROUTING +2=NF_IP_LOCAL_IN +3=NF_IP_FORWARD +4=NF_IP_POST_ROUTING +5=NF_IP_LOCAL_OUT +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Netfilter Hooks + +Netfilter Hooks + + Any kernel module may register a callback function at any of the hooks + + The module has to return one of the following constants + + NF_ACCEPT continue traversal as normal + NF_DROP drop the packet, do not continue + NF_STOLEN I've taken over the packet do not continue + NF_QUEUE enqueue packet to userspace + NF_REPEAT call this hook again + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +IP tables + +Packet selection using IP tables + + The kernel provides generic IP tables support + + Each kernel module may create it's own IP table + + The three major parts of 2.4 firewalling subsystem are implemented using IP tables + Packet filtering table 'filter' + NAT table 'nat' + Packet mangling table 'mangle' + + Can potentially be used for other stuff, i.e. IPsec SPDB + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +IP Tables + +Managing chains and tables + + An IP table consists out of multiple chains + A chain consists out of a list of rules + Every single rule in a chain consists out of + match[es] (rule executed if all matches true) + target (what to do if the rule is matched) + +%size 4 +matches and targets can either be builtin or implemented as kernel modules + +%size 6 + The userspace tool iptables is used to control IP tables + handles all different kinds of IP tables + supports a plugin/shlib interface for target/match specific options + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +IP Tables + +Basic iptables commands + + To build a complete iptables command, we must specify + which table to work with + which chain in this table to use + an operation (insert, add, delete, modify) + one or more matches (optional) + a target + +The syntax is +%font "typewriter" +%size 3 +iptables -t table -Operation chain -j target match(es) +%font "standard" +%size 5 + +Example: +%font "typewriter" +%size 3 +iptables -t filter -A INPUT -j ACCEPT -p tcp --dport smtp +%font "standard" +%size 5 + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +IP Tables + +Matches + Basic matches + -p protocol (tcp/udp/icmp/...) + -s source address (ip/mask) + -d destination address (ip/mask) + -i incoming interface + -o outgoing interface + + Match extensions (examples) + tcp/udp TCP/udp source/destination port + icmp ICMP code/type + ah/esp AH/ESP SPID match + mac source MAC address + mark nfmark + length match on length of packet + limit rate limiting (n packets per timeframe) + owner owner uid of the socket sending the packet + tos TOS field of IP header + ttl TTL field of IP header + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +IP Tables + +Targets + very dependent on the particular table. + + Table specific targets will be discussed later + + Generic Targets, always available + ACCEPT accept packet within chain + DROP silently drop packet + QUEUE enqueue packet to userspace + LOG log packet via syslog + ULOG log packet via ulogd + RETURN return to previous (calling) chain + foobar jump to user defined chain + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Packet Filtering + +Overview + + Implemented as 'filter' table + Registers with three netfilter hooks + + NF_IP_LOCAL_IN (packets destined for the local host) + NF_IP_FORWARD (packets forwarded by local host) + NF_IP_LOCAL_OUT (packets from the local host) + +Each of the three hooks has attached one chain (INPUT, FORWARD, OUTPUT) + +Every packet passes exactly one of the three chains. Note that this is very different compared to the old 2.2.x ipchains behaviour. + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Packet Filtering + +Targets available within 'filter' table + + Builtin Targets to be used in filter table + ACCEPT accept the packet + DROP silently drop the packet + QUEUE enqueue packet to userspace + RETURN return to previous (calling) chain + foobar user defined chain + + Targets implemented as loadable modules + REJECT drop the packet but inform sender + MIRROR change source/destination IP and resend + LOG log via syslog + ULOG log via userspace + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Connection Tracking Subsystem + + Connection tracking... + + implemented seperately from NAT + enables stateful filtering + implementation + hooks into NF_IP_PRE_ROUTING to track packets + hooks into NF_IP_POST_ROUTING and NF_IP_LOCAL_IN to see if packet passed filtering rules + protocol modules (currently TCP/UDP/ICMP) + application helpers currently (FTP,IRC,H.323,talk,SNMP) + divides packets in the following four categories + NEW - would establish new connection + ESTABLISHED - part of already established connection + RELATED - is related to established connection + INVALID - (multicast, errors...) + does _NOT_ filter packets itself + can be utilized by iptables using the 'state' match + is used by NAT Subsystem + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Network Address Translation + +Overview + + Previous Linux Kernels only implemented one special case of NAT: Masquerading + Linux 2.4.x can do any kind of NAT. + NAT subsystem implemented on top of netfilter, iptables and conntrack + NAT subsystem registers with all five netfilter hooks + 'nat' Table registers chains PREROUTING, POSTROUTING and OUTPUT + Following targets available within 'nat' Table + SNAT changes the packet's source whille passing NF_IP_POST_ROUTING + DNAT changes the packet's destination while passing NF_IP_PRE_ROUTING + MASQUERADE is a special case of SNAT + REDIRECT is a special case of DNAT + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Network Address Translation + + Source NAT + SNAT Example: +%font "typewriter" +%size 3 +iptables -t nat -A POSTROUTING -j SNAT --to-source 1.2.3.4 -s 10.0.0.0/8 +%font "standard" +%size 4 + + MASQUERADE Example: +%font "typewriter" +%size 3 +iptables -t nat -A POSTROUTING -j MASQUERADE -o ppp0 +%font "standard" +%size 5 + + Destination NAT + DNAT example +%font "typewriter" +%size 3 +iptables -t nat -A PREROUTING -j DNAT --to-destination 1.2.3.4:8080 -p tcp --dport 80 -i eth1 +%font "standard" +%size 4 + + REDIRECT example +%font "typewriter" +%size 3 +iptables -t nat -A PREROUTING -j REDIRECT --to-port 3128 -i eth1 -p tcp --dport 80 +%font "standard" +%size 5 + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Packet Mangling + + Purpose of mangle table + packet manipulation except address manipulation + + Integration with netfilter + 'mangle' table hooks in all five netfilter hooks + priority: after conntrack + + Targets specific to the 'mangle' table: + DSCP - manipulate DSCP field + IPV4OPTSSTRIP - strip IPv4 options + MARK - change the nfmark field of the skb + TCPMSS - set TCP MSS option + TOS - manipulate the TOS bits + TTL - set / increase / decrease TTL field + +Simple example: +%font "typewriter" +%size 3 +iptables -t mangle -A PREROUTING -j MARK --set-mark 10 -p tcp --dport 80 + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Advanced Netfilter concepts + +%size 4 + Userspace logging + flexible replacement for old syslog-based logging + packets to userspace via multicast netlink sockets + easy-to-use library (libipulog) + plugin-extensible userspace logging daemon (ulogd) + Can even be used to directly log into MySQL + + Queuing + reliable asynchronous packet handling + packets to userspace via unicast netlink socket + easy-to-use library (libipq) + provides Perl bindings + experimental queue multiplex daemon (ipqmpd) + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Current Development and Future + +Netfilter (although it proved very stable) is still work in progress. + + Areas of current development + infrastructure for conntrack manipulation from userspace + failover of stateful firewalls + making iptables layer3 independent (pkttables) + new userspace library (libiptables) to hide plugins from apps + more matches and targets for advanced functions (pool, hashslot) + more conntrack and NAT modules (RPC, SNMP, SMB, ...) + better IPv6 support (conntrack, more matches / targets) + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Thanks + + Thanks to + the BBS people, Z-Netz, FIDO, ... + for heavily increasing my computer usage in 1992 + + KNF + for bringing me in touch with the internet as early as 1995 + for providing a playground for technical people + for telling me about the existance of Linux! + + Alan Cox, Alexey Kuznetsov, David Miller, Andi Kleen + for implementing (one of?) the world's best TCP/IP stacks + + Paul 'Rusty' Russell + for starting the netfilter/iptables project + for trusting me to maintain it today + + Linux User Group Nuernberg (ALIGN, LUG-N) + for helping me with my initial Linux problems + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +netfilter/iptables in Linux 2.4 +Availability of slides / Links + +The slides and the an according paper of this presentation are available at + http://www.gnumonks.org/ + +The netfilter homepage + http://www.netfilter.org/ + diff --git a/2002/tcp-statetracking-ccc2002/tcp-statetracking-ccc2002.mgp b/2002/tcp-statetracking-ccc2002/tcp-statetracking-ccc2002.mgp new file mode 100644 index 0000000..c98ba30 --- /dev/null +++ b/2002/tcp-statetracking-ccc2002/tcp-statetracking-ccc2002.mgp @@ -0,0 +1,201 @@ +%include "default.mgp" +%default 1 bgrad +%%%%%%%%%%%%%%%% +%deffont "typewriter" tfont "MONOTYPE.TTF" + +%page +%nodefault +%back "blue" + +%center +%size 7 + + +TCP state + windowtracking + + +%center +%size 4 +by + +Harald Welte + + +%page +TCP state + window tracking +What? Why? + + + TCP is a stateful protocol, each endpoint is a state machine + + What is TCP state / windowtracking? + Some intermediate System (Router/Firewall) is trying to derive the current state of the two TCP endpoints + + Why does somebody want TCP state / windowtracking + Evaluation of TCP stack implementations + Hide/Protect broken implementations from a public network + + +%page +TCP state + windowtracking +TCP basics + + states of a TCP endpoint: + LISTEN: port waiting for connection request from remote end + SYN_SENT: we've sent a SYN packet and not received anything yet + SYN_RECEIVED: We've received a SYN in reply to our SYN + ESTABLISHED: fully established TCP connection + FIN_WAIT1: waiting for FIN from remote end or ACK of sent FIN + FIN_WAIT2 waiting for FIN from remote end + TIME_WAIT: waiting for enough time to pass to be sure the remote end received the ACK of its FIN + CLOSED: no connection state at all + CLOSE_WAIT: waiting for a connection termination request from local user + CLOSING: waiting for a connection termination request acknowledgement from the remote end + LAST_ACK: Waiting for ACK of the FIN previously sent to remote end + +%page +TCP state + windowtracking +TCP basics + + sequence numbers + every octet has a corrsponding sequence number + sequence number is increased by one for every payload octet sent + receiver acknowledges last received contiguous sequence number (cumulative ack) + EXTENSION: selective acknowledgement (SACK) option, RFC2018 + receiver can specify seperate sequencenumber blocks it has received + + sliding window protocol + receiver advertises the size of the receive window + sender can only send up to 'window' number of octets which are not ACK'ed yet + EXTENSION: window scaling, RFC1323 + window size of 16bit is too small for high bandwith links, thus window scaling was introduced + +%page +TCP state + windowtracking +TCP state tracking + + Where do we do TCP state tracking? + state tracker needs to see _all_ packets in both directions + problems with asymmetric routing! + + So where's the Problem? + IP is an unreliable, best-effort protocol + If man in the middle does observe a packet, he can make no assumption on whether it actually arrives at the receiver. + +%page +TCP state + window tracking +Problems + + + Example scenario 1 + A sends SYN to B + man in the middle saves state as SYN_SENT + B sends SYN/ACK to A + man in the middle detects state transition to SYN_RECEIVED + SYN/ACK doesn't arrive at A + somebody spoofs ACK A->B to firewall + man in the middle detects state transition to ESTABLISHED + ==> Any traffic between A and B will be accepted (wrong!) + +%page +TCP state + window tracking +Problems + + + Example scenario 2 + fully established TCP connection + A sends FIN to B + man in the middle saves state to FIN_WAIT1 + B sends FIN/ACK to A + man in the middle saves state CLOSING/TIME_WAIT + FIN/ACK doesn't arrive at A + B retransmits FIN/ACK to A + man in the middle doesn't accept any further packets + .oO(booom)Oo. + +%page +TCP state + window tracking +Problems + + + Example scenario 3 (FIN/RST spoofing without windowtracking) + fully established TCP connection + evil guy spoofs FIN A->B (with guessed sequence number + man in the middle saves satet as FIN_WAIT1 + B ignores FIN/ACK because of wrong sequence number + A sends further segments to B + man in the middle doesn't accept further segments after FIN was sent in this direction + .oO(booom)Oo. + + Solution: Real Window tracking + See paper by Guido van Rooj + + +%page +TCP state + window tracking +Further Problems + + + pickup of already established connections + window scaling sucks in this case + window tracking has to be disabled in that case + + selective acknowledgements + man-in-the-middle needs to track all selectively acknowledged segments + this can draw lots of resources at the man in the middle and is prone to DoS + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +TCP state + window tracking +conntrack subsystem of netfilter + +Netfilter architecture in IPv4 +%font "typewriter" +%size 3 + + --->[1]--->[ROUTE]--->[3]--->[4]---> + | ^ + | | + | [ROUTE] + v | + [2] [5] + | ^ + | | + v | + +%font "standard" +1=NF_IP_PRE_ROUTING +2=NF_IP_LOCAL_IN +3=NF_IP_FORWARD +4=NF_IP_POST_ROUTING +5=NF_IP_LOCAL_OUT + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%page +TCP state + window tracking +conntrack subsystem of netfilter + + Connection tracking... + + implemented seperately from NAT + enables stateful filtering + implementation + hooks into NF_IP_PRE_ROUTING to track packets + hooks into NF_IP_POST_ROUTING and NF_IP_LOCAL_IN to see if packet passed filtering rules + protocol modules (currently TCP/UDP/ICMP) + application helpers currently (FTP,IRC,H.323,talk,SNMP) + divides packets in the following four categories + NEW - would establish new connection + ESTABLISHED - part of already established connection + RELATED - is related to established connection + INVALID - (multicast, errors...) + does _NOT_ filter packets itself + can be utilized by iptables using the 'state' match + is used by NAT Subsystem + +%page +TCP state + window tracking +Further Reading + + RFC793,RFC2018,RFC1323: Transmission Control Protocol + http://www.netfilter.org/ - netfilter hacking howto contains some info diff --git a/2002/tex-introduction-cc2002/tex-einfuehrung b/2002/tex-introduction-cc2002/tex-einfuehrung new file mode 100644 index 0000000..ff5a4ff --- /dev/null +++ b/2002/tex-introduction-cc2002/tex-einfuehrung @@ -0,0 +1,147 @@ + +0. Einfuehrung / Geschichte +1. Grundsaetzliches (.tex file, latex, .dvi, dvips, postscript, ...) +2. wie sieht ein LaTex dokument aus? + \documentstyle[german]{article} + \pagestyle{empty} + \begin{document} + .. + \end{document} + +3. Texteingabe + - leerzeichen / leerzeilen irrelevant + - absatz durch leere zeile oder \par + - zeilenumbruch mit \\ + +Trennvorgaben: + - lokal (nur): Donau\-dampf\-schiff + - lokal (auch): Donau"-dampf"-schiff + - global: \hyphenation{Donau-dampf-schiff} + - keine trennung lokal: \mbox{Untrennbar} + - keine trennung global: \hyphenation{Untrennbar} + - ~ == leerzeichen, bei dem kein zeilenumbruch erfolgen darf + +Sonderzeichen: + - deutsch: "a "o "u "A "O "U "s + - sonstige: \'o \`o \^o \=o \.o \u{o} \v{o} \H{o} \t{oo} \c{c} \d{o} + z.b. C'est \c{c}a! + - \$ \& \% \# \{ \} [ ] \_ @ \S \pounds $<$ $>$ $\backslash ?` !` + +Striche und Anfuehrungszeichen: + - Striche: - -- --- + - Anfuehrungszeichen: \glq \grq \glqq \grqq \flq \frq \flqq \frqq + (german left quote, french right quote, ...) + Kurzform: "` "' "> "< + +Leerraeume + - \hspace{length} + - \vspace{length} + - \hfill \vfill +Auslassungszeichen + - \ldots{} + - \dotfill{} + - \vdots + + +Texthervorhebungen + - betonen {\em betontes} + - unterstreichen \underline{ } + - woertlich \verb{text} + +Schriftarten: + - Roman (\rm) + - Fett (\bf) + - Kursiv (\it) (Italic-Korrektur \/) + - Slanted (\sl) + - Sans Serif (\sf) + - Small Caps (\sc) + - Typweriter (\tt) + +Schriftgroessen: + - \tiny + - \scriptsize + - \footnotesize + - \small + - \normalsize + - \large + - \Large + - \LARGE + - \huge + - \Huge + +NFSS: + - \family{cmr|cmss|cmtt} + - \series{ul|el|l|sl|m|sb|b|eb|ub} + - \series{uc|ec|c|sc|m|sx|x|ex|ux} + - \shape{n|it|sl|sc} + - \size{size}{linespacing} + - \selectfont + + +Dokumenststruktur + +Gliederung: + + - \part{Teilueberschrift} \part* + - \chapter{Kapitelueberschrift} \chapter* + + - \section{Abschnittsueberschrift} + - \subsection{} + - \subsubsection{} + - \paragraph{} [text folgt in gleicher zeile wie ueberschrift] + - \subparagraph{} + + + - \setcounter{page|part|chapter|section|...}{wert} + +Titelseite: + - \title{Titel} + - \thanks{Danksagung} + - \author{Autor} + - \date{Datum} + - \maketitle + +Zusammenfassung: + - \begin{abstract} \end{abstract} + +Inhaltsverzeichnis: + - \tableofcontents + - Tiefe des Einbindens: \setcounter{tocdepth}{tiefe} + tiefe: -1 keine ueberschrift + 0 chapter + 1 chapter und section + 2 chapter bis subsection + 3 chapter bis subsubsection + 4 chapter bis paragraph + 5 alle + +Dokumentaufbau: + - \documentstyle[german, option, ...]{style} + Gaengige styles: article, report, book + Stiloptionen: 10pt,11pt,12pt,twoside,twocolumn,titlepage + - \pagestyle{plain|headings|empty|myheadings} + + - \noindent + - Zentriert: \begin{center} \end{center} + - Links-Rechtsbuendig: \begin{flushleft|flushright} + - Zitat: \begin{quotation} \end{quotation} + - Gedichtzeilen: \begin{verse} \end{verse} + - Woertlich: \begin{verbatim} \end{verbatim} + - Randnotiz: \marginpar{Randnotiz} + - Fussnote: \footnote{foobaR} + +Listen und Aufzaehlungen: + - Liste: \begin{itemize} \item \end{itemize} + - Aufzaehlung: \begin{enumerate} \item \end{enumerate} + - Beschreibung: \begin{description} \item[was] \end{description} + +Querverweise: + - Ziel des verweises: \label{name} + - Verweis: \ref{name}, Seite \pageref{name} + +Literaturverzeichnis: + - "Wie in \cite[Seiten 12,13]{1} beschrieben..." + \begin{thebibliography}{99} + \bibitem{1} Markus Mueller, {\sl Mahlzeit - das Kochbuch, Addison-Wesley, 1995} + ... + \end{thebibliography} diff --git a/2002/tex-introduction-cc2002/tex-einfuehrung.tex b/2002/tex-introduction-cc2002/tex-einfuehrung.tex new file mode 100644 index 0000000..8e90d0d --- /dev/null +++ b/2002/tex-introduction-cc2002/tex-einfuehrung.tex @@ -0,0 +1,430 @@ +\documentstyle[german,a4]{article} +\pagestyle{plain} + +\setlength{\oddsidemargin}{0in} +\setlength{\evensidemargin}{0in} +\setlength{\topmargin}{0.0in} +\setlength{\headheight}{0in} +\setlength{\headsep}{0in} +\setlength{\textwidth}{6.5in} +\setlength{\textheight}{9.5in} +\setlength{\parindent}{0in} +\setlength{\parskip}{0.05in} + +\begin{document} + +\title{The UNIX way of text processing: \LaTeX} +\author{Harald Welte $<$laforge@gnumonks.org$>$} +\maketitle + +\begin{abstract} +Dieses Dokument soll als kleines Begleitschreiben zu meinem Einf"uhrungskurs in +{\LaTeX} dienen. Vervielf"altigung erlaubt und erw"unscht. +\end{abstract} + +\tableofcontents + +\section{Einleitung} +Viele Anwender arbeiten heute mit sogenannten {\em WYSIWYG}-Textverarbeitungen. +Dieses relativ neue Konzept erm"oglicht es, ein Textdokument am Bildschirm so +zu bearbeiten, wie es nachher auch aus dem Drucker herauskommt (zumindest +Behaupten dies die Hersteller, die Realit"at sieht meist anders aus). + +Eine ganz andere Philosophie verfolgen Textsatzsysteme wie \TeX oder dessen +Erweiterung {\LaTeX}. Hier wird der Text zun"achst mit einem beliebigen +Texteditor gescrhieben, wobei bestimmte Befehle und Steuerzeichen eingebettet +werden. Anschlie"send wird dann der Textprocessor aufgerufen, der das +eigentliche Resultat generiert. + +Dieser Vorgang erinnert stark an das Programmieren: Der Autor schreibt einen +Quelltext, welcher mittels eines Compilers in Maschinensprache "ubersetzt wird. +Diese Analogie ist kein Zufall, wurde TeX doch von {\em Donald E. Knuth}, einem +der renommiertesten Informatikern "ubehaupt, geschrieben. Knuth hat neben zwei +Professuren unter anderem auch 27 Ehrendoktortitel und zahlreiche Ehrungen +Namhafter Institutionen. + +Knuth schreibt seit Jahrzehnten ma"sgebliche Referenzwerke der Informatik, so +z.B. die mehrteilige Reihe {\em The Art of Programming}. Um seine B"ucher +vern"unftig schreiben zu k"onnen, hat Knuth keine befriedigende Software +gefunden, und hat so kurzerhand selbst eine entwickelt. + +Die ersten TeX-Versionen wurden 1978 ver"offentlicht, und der letzte bekannte +(in Erscheinung tretende) Bug wurde 1985 gefixed. Der Autor hat f"ur jeden +Bugfix eine finanzielle Belohnung ausgesetzt, welche sich mit jedem Fehler +verdoppelt (beginnend bei US\$ 1.28, heute nahe der H"ochstgrenze von +US\$327.68). + +\section{Warum sollte ich {\LaTeX} verwenden?} +\begin{itemize} +\item +Professionelles Textsatzsystem v"ollig kostenlos +\item +Absolut identische Ausgabe unabh"angig von verwendeter Computerhardware, Betriebssystem, Softwareversion, Drucker +\item +Kompatibilit"at "uber Jahrzehnte. Welches propriet"are Textsyetem existiert seit 1978 und kann heute noch problemlos mit den alten Dokuenten arbeiten? +\item +Perfekte Unterst"utzung f"ur alles, was in wissenschaftlichen Dokumenten gebraucht wird: Formelnsatz, Literaturverzeichnisse, Glossar, ... +\end{itemize} + +\section{Mein erstes {\LaTeX}-Dokument} +\subsection{Bearbeiten des .tex Files im Editor} + +Man nehme seinen lieblings-Texteditor und schreibe folgendes: + +\begin{verbatim} +\documentstyle[german,a4]{article} +\pagestyle{empty} +\begin{document} +... +\end{document} +\end{verbatim} + +Die einzelnen Elemente werden sp"ater noch ausf"uhrlich besprochen. Vorerst +sollte einfach das obige Template verwendet werden. Dort wo ``....'' steht, +kann man jetzt seinen eigenen Text hinschreiben. + +\subsection{Das eigentliche Tex(t)processing} + +Nach eingabe des Quelltextes wird der Processor aufgerufen, welcher dann das Ergebnis produziert. Unter Unix/Linux sieht der Befehl folgendermassen aus: + +\begin{verbatim} +latex meinedatei.tex +\end{verbatim} + +Anschlie"send liegt eine Datei {\em meinedatei.dvi} im gleichen Verzeichnis. +Das DVI ist ein device-independent File. Das hei"st, da"s es das Dokument in +einem vom Ausgabeger"at unabh"angigen Format beschreibt. + +Dieses DVI-File kann man sich unter Linux am besten mit dem Programm {\em xdvi} ansehen: + +\begin{verbatim} +xdvi meinedatei.dvi +\end{verbatim} + +Sollte man nnoch etwas am Dokumnt nachbessern wollen, so editiert man wieder das .tex-File, ruft {\LaTeX} auf und sieht sich das neue .dvi an. + +\subsection{Das Ausgeben auf dem Drucker} + +Das .dvi kann nun in das endg"ultige Ausgabeformat "uberf"uhrt werden. Zumeist ist das Postscript. F"ur die Konvertierung nach Postscript wird {\em dvips} verwendet: + +\begin{verbatim} +dvips meinedatei.dvi > meinedatei.ps +\end{verbatim} + +oder gleich zum Drucker schicken: + +\begin{verbatim} +dvips meinedatei.dvi | lpr +\end{verbatim} + +\section{Allgemeines zur Syntax} + +\subsection{Leerzeichen} + +Leerzeichen und ein einfacher Zeilenumbruch werden von {\LaTeX} nicht beachtet. + +Ein neuer Absatz wird durch eine Leerzeile (doppelter Zeilenumbruch) begonnen. +Zeilenumbr"uche k"onnen durch $\backslash\backslash$ am Zeilenende erzeugt +werden. Es k"onnen manuell Leerr"aume eingef"ugt werden: + +\begin{verbatim} +\hspace{length} % horizontaler Leerraum +\vspace{length} % vertikaler Leerraum +\end{verbatim} + +\subsection{Trennung} + +Die Trennung wird von {\LaTeX} automatisch vorgenommen. Hierbei werden die in +der jeweiligen Landessprache ({\em german.sty}) geltneden Trennungsregeln +verwendet. Es k"onnen jedoch vom Autor Trennungsvorgaben gemacht werden: + +\begin{itemize} +\item +Zus"atzliche Trennungsm"oglichkeit: Donau$\backslash$-dampf$\backslash$-schiff +\item +Ausschliessliche Trennvorgabe: Donau\"-dampf\"-schiff +\item +Globale Trennvorgabe f"ur ein Wort: $\backslash$hyphenation\{Donau-dampf-schiff\} +\item +Keine Trennungsm"oglichkeit (im text): $\backslash$mbox\{Untrennbar\} +\item +Keine Trennungsm"oglichkeit (global): $\backslash$hyphenation\{Untrennbar\} +\item +Leerzeichen, bei dem kein Zeilenumbruch erfolgen darf: $~$ +\end{itemize} + + +\subsection{Sonderzeichen} +Sonderzeichen k"onnen nicht einfach im Flie"stext geschrieben werden, da sie +h"aufig von Zeichensatz zu Zeichensatz unterschiedlich sind. Einige andere +Symbole werden von {\LaTeX} selbst als Steuer- und Kommandozeichen verwendet. + +\subsubsection{Deutsche Umlaute} +\begin{verbatim} +"a "o "u "A "O "U "s +\end{verbatim} +"a "o "u "A "O "U "s + +\subsubsection{Ausl"andische Sonderzeichen} +\begin{verbatim} +\'o \`o \^o \=o \.o \u{o} \v{o} \H{o} \t{oo} \c{c} \d{o} +\end{verbatim} +\'o \`o \^o \=o \.o \u{o} \v{o} \H{o} \t{oo} \c{c} \d{o} + +\subsubsection{Sonderzeichen/Symbole} +\begin{verbatim} +\$ \& \% \# \{ \} [ ] \_ @ \S \pounds $<$ $>$ $\backslash$ @' !' +\end{verbatim} +\$ \& \% \# \{ \} [ ] \_ @ \S \pounds $<$ $>$ $\backslash$ @' !' + +\section{Dokumentstruktur} + +\subsection{Gliederung} + +Gr"o"sere Dokumentvorlagen wie book.sty haben Teile und Kapitel. Dise k"onnen wie folgt verwendet werden: + +\begin{verbatim} +\part{Teil"uberschrift} +\chapter{Kapitel"uberschrift} +\end{verbatim} + +Kleinere Dokumentvorlagen wie article.sty bieten die Unterteilung in +Abschnitte, Unterabschnitte, Unter-Unterabschnitte, Abs"tze und Unterabs"atze. +Selbstverst"andlich sind diese Gliederungselemente auch in gr"o"seren +Dokumentvorlagen verwendbar. + +\begin{verbatim} +\section{Abschnitts"uberschrift} +\subsection{Unterabschnitts"uberschrift} +\subsubsection{Unter-Unterabschnitts"uberschrift} +\paragraph{Absatz"uberschrift} +\subparagraph{Unterabsatz"uberschrift} +\end{verbatim} + +Die einzelnen Gliederungselemente werden automatisch durchnummeriert. Wie tief die Nummerierung angezeigt wird, ist einstellbar. Standardm"a"sig wird nur bis Subsection nummeriert, d.h. subsubsection, paragraph und subparagraph erhalten keine angezeigte Nummerierung. + +\begin{verbatim} +\setcounter{secnumdepth}{wert} +\end{verbatim} + +\label{gliederungswerte} +Wobei {\em wert} die folgenden Werte annehmen kann: +\begin{description} +\item[-1] keine Nummern +\item[0] nur Chapter +\item[1] Chapter und Section +\item[2] Chapter bis Subsection +\item[3] Chapter bis Subsubsection +\item[4] Chapter bis Paragraph +\item[5] alle +\end{description} + +\subsection{Titelseite} + +Die meisten Dokumentvorlagen bieten die M"oglichkeit, automatisch eine Titelseite zu generieren. Dazu werden die folgenden Definitionen verwendet: + +\begin{verbatim} +\title{Titel} +\thanks{Danksagung} +\author{Autor} +\date{Datum} +\maketitle +\end{verbatim} + +\subsection{Zusammenfassung} + +Eine Zusammenfassung kann dem eigentlichen Dokument vorangestellt werden: + +\begin{verbatim} +\begin{abstract} +... +\end{abstract} +\end{verbatim} + +\subsection{Inhaltsverzeichnis} + +Aus den Gliederungselementen kann auf Wunsch automatisch ein Inhaltsverzeichnis erzeugt werden. Hierzu verwendet man den Befehl +\begin{verbatim} +\tableofcontents +\end{verbatim} + +Man kann nun noch bestimmen, bis zu welcher Gliederungsebene Eintr"age im Inhaltsverzeichnis gemacht werden sollen: +\begin{verbatim} +\setcounter{tocdepth}{tiefe} +\end{verbatim} + +Wobei {\em tiefe} die gleichen Werte annehmen kann, wie in Teil \ref{gliederungswerte} auf Seite \pageref{gliederungswerte} beschrieben. + + +\section{Formatierung} + +\subsection{Schriftarten} + +Man kann selbstverst"andlich auch zwischen diversen Schriftarten w"ahlen. Der Einfachheit halber werden hier jedoch nur die Standardschriften beschrieben: + +\begin{itemize} +\item +{\rm Roman}: $\backslash$rm +\item +{\bf Fett}: $\backslash$bf +\item +{\it Kursiv}: $\backslash$it (Italic-Korrektur $\backslash$/) +\item +{\sl Slanted}: $\backslash$sl +\item +{\sf Sans Serif}: $\backslash$sf +\item +{\sc Small Caps}: $\backslash$sc +\item +{\tt Typewriter}: $\backslash$tt +\end{itemize} + +\subsection{Schriftgr"o"sen} + +\begin{itemize} +\item {\tiny $\backslash$tiny} +\item {\scriptsize $\backslash$scriptsize} +\item {\footnotesize $\backslash$footnotesize} +\item {\small $\backslash$small} +\item {\normalsize $\backslash$normalsize} +\item {\large $\backslash$large} +\item {\Large $\backslash$Large} +\item {\LARGE $\backslash$LARGE} +\item {\huge $\backslash$huge} +\item {\Huge $\backslash$Huge} +\end{itemize} + +\subsection{Textausrichtung} + +Standardm"a"sig formatiert {\LaTeX} immer im Blocksatz. Dies kann ge"andert +werden: + +\begin{verbatim} +\begin{center} +Zentriert +\end{center} +\end{verbatim} + +Es k"onnen neben {\em center} auch {\em flushleft} oder {\em flushright} +verwendet werden, um linksb"undige bzw. rechtsb"undige Ausgabe zu erhalten. + +\subsection{Zitate} + +Zitate k"onnen wie folgt eingebunden werden: +\begin{verbatim} +\begin{quotation} +Mahlzeit +\end{quotation} +\end{verbatim} + + + +\section{Listen und Aufz"ahlungen} + +\subsection{Listen} + +Eine Liste kann wie folgt erzeugt werden: + +\begin{verbatim} +\begin{itemize} +\item erster eintrag +\item zweiter eintrag +\end{itemize} +\end{verbatim} + +\subsection{Aufz"ahlungen} + +Eine Aufz"ahlung kann wie folgt erzeugt werden: +\begin{verbatim} +\begin{enumerate} +\item erster Eintrag +\item zweiter Eintrag +\end{enumerate} +\end{verbatim} + +\subsection{Beschreibungen/Definitionen} + +Eine Beschreibung kann wie folgt erzeugt werden: +\begin{verbatim} +\begin{description} +\item[Donald E. Knuth] Autor des bekannten TeX Syetems +\item[Donald Becker] Autor von zahllosen Linux-Netzwerktreibern +\end{description} +\end{verbatim} + +\section{Fu"snoten, Querverweise, Literaturverzeichnis} + +\subsection{Fu"snoten} +Eine Fu"snote\footnote{Fussnoten sehen so aus *g*} wird einfach in den Text +mit hineingeschrieben, an der Stelle an der sie erscheinen soll: +\begin{verbatim} +Benutzt man hingegen das Sub-Etha-Sens-O-Matic\footnote{Ein Ger"at zur +detektion in der N"ahe befindlicher Raumschiffe}, so .... +\end{verbatim} + +\subsection{Querverweise} + +Es k"onnen Querverweise eingef"ugt werden, welche dann automatisch auf die +jeweils aktuelle Abschnittsnummer / Seite verweisen, auch wenn sich das Ziel +des Querverweises verschiebt. + +An dem Ziel des Querverweises (also wohin man verweisen m"ochte), wird +folgender Befehl eingef"ugt: +\begin{verbatim} +\label{namedeslabels} +\end{verbatim} + +Ein Querverweis dorthin sieht dann wie folgt aus: +\begin{verbatim} +Wie in Abschintt \ref{namedeslabels} auf Seite \pageref{namedeslabels} +beschrieben +\end{verbatim} + +\subsection{Literaturverzeichnis} + +Vor allem in wissenschaftlichen Dokumenten wird ein Literaturverzeichnis +gebraucht. Es gibt zwei unterschiedliche M"oglichkeiten, ein +Literaturverzeichnis unter {\LaTeX} zu verwenden. + +Die einfache, hier beschriebene Variante eignet sich f"ur kleine, einzelne +Dokumente. Wer h"aufig zu den gleichen Themen dokumente verfasst, sollte sich +mit {\em bibtex} auseinandersetzen, hier kann man sich ein zentrales +Literaturverzeichnis anlegen, worauf von allen Dokumenten aus verwiesen werden +kann. + +Ein Verweis auf ein Literaturverzeichnis sieht so aus: +\begin{verbatim} +Wie in \cite[Seiten 12 ff.]{1} bescrhieben, ... +\end{verbatim} + +Das Literaturverzeichnis am Ende sieht dann so aus: +\begin{verbatim} +\begin{thebibliography}{99} +\bibitem{1} Markus M"uller, {\sl Mahlzeit - das Kochbuch, Addison-Wesley, 1995} +\end{thebibliography} +\end{verbatim} + + +\section{Dokumentvorlagen} + +Wir haben in den bisherigen Beispielen immer die Dokumentvorlage {\em article.sty} vewendet. Die zu verwendende Dokumentvorlage wird im Kopf des Dokuments mit dem {\em $\backslash$documentstyle}-Befehl angegeben. + +G"angige Dokumentvorlagen: +\begin{description} +\item[article] F"r das Verfassen strukturierter Dokumente begrenzter L"ange +\item[book] Zum Verfassen eines Ganzen Buches +\item[dinbrief] Zum Verfassen eines sich exakt an der DIN-Norm orientierenden Briefes +\end{description} + +Zus"atzlich werden beim {\em documentstyle}-Befehl in den eckigen Klammern noch +Optionen angegeben. + +G"angige Optionen: +\begin{description} +\item[10pt, 11pt, 12pt] Standardschriftgr"o"se +\item[german] Unterst"utzung f"ur deutsche Umlaute und Trennregeln +\item[twocolumn] Zweispaltige Formatierung +\item[twoside] Zweiseitiger Druck (Seitennummern, etc.) +\end{description} + +\end{document} -- cgit v1.2.3