import of old now defunct presentation slides svn repo

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 :)
+