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