101 lines
3.2 KiB
Plaintext
101 lines
3.2 KiB
Plaintext
- 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 :)
|
|
|