1 / 45

Firewall Architectures

Firewall Architectures. Earliest firewalls. ?. 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. Topics. Faculty of Information Technology. Firewall Architectures Packet Filter

dwayne
Download Presentation

Firewall Architectures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Earliest firewalls ? (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 (c) University of Technology, Sydney 2000 - 2004

  4. Topics Faculty of Information Technology • 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 (c) University of Technology, Sydney 2000 - 2004

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

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

  7. 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. Packet Filters (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. (c) University of Technology, Sydney 2000 - 2004

  9. Packet Filters and FTP • Solution? • Another solution? (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. (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. (c) University of Technology, Sydney 2000 - 2004

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

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

  15. 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. Application Gateway (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 (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 (c) University of Technology, Sydney 2000 - 2004

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

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

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

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

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

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

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

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

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

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

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

  29. Simple Network with NAT (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 (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 (c) University of Technology, Sydney 2000 - 2004

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

  33. Completely Secure? YES! • Anything else NO! (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. (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. (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 (c) University of Technology, Sydney 2000 - 2004

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

  38. Real World What can or cannot be done (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 (c) University of Technology, Sydney 2000 - 2004

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

  41. (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 (c) University of Technology, Sydney 2000 - 2004

  43. End (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 circuitgateway” (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 (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). (c) University of Technology, Sydney 2000 - 2004

More Related