summaryrefslogtreecommitdiff
path: root/2002/firewalling-knf-2002
diff options
context:
space:
mode:
Diffstat (limited to '2002/firewalling-knf-2002')
-rw-r--r--2002/firewalling-knf-2002/abstract48
-rw-r--r--2002/firewalling-knf-2002/firewall.mgp312
-rw-r--r--2002/firewalling-knf-2002/toc100
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 :)
+
personal git repositories of Harald Welte. Your mileage may vary