summaryrefslogtreecommitdiff
path: root/2002/firewalling-knf-2002/firewall.mgp
blob: d277a35064b28184f532683001648ff4adeebeeb (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
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

personal git repositories of Harald Welte. Your mileage may vary