1. (c) University of Technology, Sydney 2000 - 20041 Firewall Architectures

2. (c) University of Technology, Sydney 2000 - 2004 2 Earliest firewalls ?

3. (c) University of Technology, Sydney 2000 - 2004 3 What are we dealing with? Data Stream on a wire – ‘data in flight’ Sequence of bits Relayed from machine to machine Will assume using Ethernet

4. (c) University of Technology, Sydney 2000 - 2004 4 Firewall Architectures  Packet Filter  Application Gateway/Proxy  Stateful Inspection Firewall Deployment Methods  Choke Router  Bastion Host  DMZ Platform Selection  Proprietary, Open Source  UNIX vs Windows  General Purpose Platform vs Appliance Faculty of Information Technology Topics

5. (c) University of Technology, Sydney 2000 - 2004 5 Types of Firewall Packet Filter Proxy Server Stateful Inspection

6. (c) University of Technology, Sydney 2000 - 2004 6 Packet Filter Applications Presentations Sessions Transport DataLink Physical DataLink Physical Applications Presentations Sessions Transport DataLink Physical Network Go / No - Go

7. (c) University of Technology, Sydney 2000 - 2004 7 Packet Filters PRO Cheap (you have to buy a router anyway). Already sits in the ideal position for a firewall. CON Routers are made to be cheap and fast, so they don’t have memory or time for state information. Certain things don’t work without state information. Hard to configure.

8. (c) University of Technology, Sydney 2000 - 2004 8 Packet Filters and FTP The FTP protocol uses a control connection and a data connection. The port number for the data connection is passed on the control connection. Without state tables, packet filters have no way to keep track of the data connection’s port, so they can’t filter it specifically.

9. (c) University of Technology, Sydney 2000 - 2004 9 Packet Filters and FTP Solution? Another solution?

10. (c) University of Technology, Sydney 2000 - 2004 10 Packet Filters and FTP Another solution? Passive FTP (pasv)  client inside firewall initiates control connection as usual on port x outgoing => port 21 on server  client issues pasv command  server replies with port p command (p > 1023)  client initiates data connection from port (x + 1) outgoing => port p on server  Both connections start from inside the firewall, so stateful firewall allows them.

11. (c) University of Technology, Sydney 2000 - 2004 11 Stateful Inspection Works by sitting in the Kernel, where the packets go naturally. Uses (in most cases) a general purpose computer, so it’s flexible. Sits before the TCP/IP protocol stack, so it can be protected.

12. (c) University of Technology, Sydney 2000 - 2004 12 Stateful Packet Filter Applications Presentations Sessions Transport DataLink Physical DataLink Physical Applications Presentations Sessions Transport DataLink Physical Network Presentations Sessions Transport Applications l Tracks the conversation flow l Allows packets based on l Can be fooled by “fiddling” the packet flags

13. (c) University of Technology, Sydney 2000 - 2004 13 Proxy Server/Application Gateway Works by forcing everything to go through a process on the firewall box (a proxy). From the client’s perspective, the proxy is the server. From the server’s perspective, it’s the client.

14. (c) University of Technology, Sydney 2000 - 2004 14 Application Gateway / Proxy Applications Presentations Sessions Transport DataLink Physical DataLink Physical Applications Presentations Sessions Transport DataLink Physical Network Presentations Sessions Transport Applications TelnetTelnet HTTPHTTPFTPFTP l Screens limited number of applications l Connectivity & Transparency are broken l Performance is poor due to many data copies & context switches l Flexibility & Open-ness lost, dependent on vendor

15. (c) University of Technology, Sydney 2000 - 2004 15 Application Gateway PRO Easy to program. Can be made as flexible as you’d like. CON Performance hit. Usually application specific. Require changes in user behavior. Doesn’t protect the TCP/IP protocol stack itself.

16. (c) University of Technology, Sydney 2000 - 2004 16 Additional Pieces TCP-Wrapper  Provides control at a TCP packet level  proxy daemon for inetd, i.e. UNIX only and others to find out …  Socks  Circuit Gateways  Transparent Proxies

17. (c) University of Technology, Sydney 2000 - 2004 17 State of the Art Today most firewalls are a combination of technologies No perfect answer Still only part of the security puzzle

18. (c) University of Technology, Sydney 2000 - 200418 Firewall Deployment Methods

19. (c) University of Technology, Sydney 2000 - 2004 19 Philosophies Hotly debated area Schemes have evolved with the technology Important elements  Availability  Maintainability  Practicality

20. (c) University of Technology, Sydney 2000 - 2004 20 The Gateway Only entry point Go / No Go decisions Easy to check payload

21. (c) University of Technology, Sydney 2000 - 2004 21 Start Point

22. (c) University of Technology, Sydney 2000 - 2004 22 Start Point Bastion Host

23. (c) University of Technology, Sydney 2000 - 2004 23 Defence in Layers DMZ

24. (c) University of Technology, Sydney 2000 - 2004 24 Segregate Bastion Host Choke Router DMZ

25. (c) University of Technology, Sydney 2000 - 2004 25 Segregate Dual Homed Bastion Host

26. (c) University of Technology, Sydney 2000 - 2004 26 Segregate Firewall

27. (c) University of Technology, Sydney 2000 - 2004 27 Segregate Firewall DMZ

28. (c) University of Technology, Sydney 2000 - 2004 28 Simple Network

29. (c) University of Technology, Sydney 2000 - 2004 29 Simple Network with NAT

30. (c) University of Technology, Sydney 2000 - 2004 30 Network Address Translation Security by Obscurity Conscious design? Fortunate result of problem solving  Using limited address spaces  Allowing more convoluted designs

31. (c) University of Technology, Sydney 2000 - 2004 31 More Architectural Choices Design for availability  redundant firewalls  redundant routes  redundant ISPs Throughput  number of hops in path  NIC capabilities

32. (c) University of Technology, Sydney 2000 - 200432 Platform Selection

33. (c) University of Technology, Sydney 2000 - 2004 33 Completely Secure? NO! YES! Anything else

34. (c) University of Technology, Sydney 2000 - 2004 34 Operating System Choices Unix Was written to be as flexible as possible. Originated in environments where security was not an issue.

35. (c) University of Technology, Sydney 2000 - 2004 35 Operating System Choices Windows Developed for a business environment, where security is important. Supposed to be as user friendly as possible. Security isn’t user friendly.

36. (c) University of Technology, Sydney 2000 - 2004 36 Operating System Choices Appliances  Hide the details  Limited Functionality in the operating system  Full functionality for the task

37. (c) University of Technology, Sydney 2000 - 2004 37 Open Source Totally visible  to ALL Support  In-house skills  Reproducible Version control

38. (c) University of Technology, Sydney 2000 - 200438 Real World What can or cannot be done

39. (c) University of Technology, Sydney 2000 - 2004 39 Firewalls Cannot Protect traffic that does NOT flow thru them Protect networks inside the firewall Stop all application based attacks

40. (c) University of Technology, Sydney 2000 - 2004 40

41. (c) University of Technology, Sydney 2000 - 2004 41

42. (c) University of Technology, Sydney 2000 - 2004 42 Firewalls CAN Control raw traffic flows Provide a point to log and “examine” events Be a Billboard to advertise your security policy

43. (c) University of Technology, Sydney 2000 - 2004 43 End

44. (c) University of Technology, Sydney 2000 - 2004 44 Circuit Gateway/SOCKS/Proxy SOCKS - a protocol that includes a set of client libraries for proxy interfaces with clients. “SOCKS, the most popular circuit gateway” (RFC 1928 versions 4 and 5)  tcp sessions; client s/w for proxy server, e.g. AnalogX Circuit (Level) Gateway  allows sessions, doesn’t analyze packets. Permission granted based on port number. More transparent, not as secure, as application gateway (proxy server)  supports sessions based on port no (doesn’t analyze packets)  sets up end-to-end session between client and remote server  needs SOCKS running on client Basically, a Circuit Gateway is like a ‘null’ Proxy server

45. (c) University of Technology, Sydney 2000 - 2004 45 Additional Pieces contrast Circuit Gateway with Application Gateway = Proxy Server  client connects to proxy server  no change required to client (except need to point client at proxy)  Transparent proxy (don’t even need to do that) Transparent Proxies  built as part of network architecture, so all o/g port 80 traffic goes through it and the user does not have to configure browser. Includes cache too (caching proxy).