diff options
Diffstat (limited to '2002/firewalling-knf-2002')
| -rw-r--r-- | 2002/firewalling-knf-2002/abstract | 48 | ||||
| -rw-r--r-- | 2002/firewalling-knf-2002/firewall.mgp | 312 | ||||
| -rw-r--r-- | 2002/firewalling-knf-2002/toc | 100 |
3 files changed, 460 insertions, 0 deletions
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 <laforge@sunbeam.franken.de> + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%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 :) + |