Firewalls: Protecting Networks from Outside Threats

1. Firewalls

2. Overview • In days of old, brick walls were built between buildings in apartment complexes so that if a fire broke out, it would not spread from one building to another • Quite naturally, these walls were called firewalls • Today, when a private network (i.e., intranet) is connected to a public network (i.e., Internet), its users are enabled to communicate with the outside world • At the same time, however, the outside world can interact with the private network and its computer systems • Consequently, the computer systems are visible and can be attacked from the outside world (with a potentially very large number of attackers)

3. Overview • In this situation, an intermediate system can be plugged between the private network and the public network to establish a controlled link, and to erect a security wall or perimeter • The aim of the intermediate system is to protect the private network from network-based attacks that may originate from the outside world, and to provide a single choke point where security and audit may be imposed • These intermediate systems are called firewall systems or firewalls (alternative terms comprise security gateways and secure Internet gateways) • There are many real-world analogies for firewalls

4. Overview • According to RFC 2828, the term firewall refers to an inter-network gateway that restricts data communication traffic to and from one of the connected networks and thus protects that network's system resources against threats from the other network • According to Cheswick and Bellovin, a firewall (system) refers to a collection of components placed between two networks that collectively have the following properties • All traffic from inside to outside, and vice versa, must pass through the firewall • Only authorized traffic, as defined by the local security policy, will be allowed to pass • The firewall itself is immune to penetration

5. Overview • Still another possibility to define the term is to call a system a firewall if it is able • To enforce strong authentication for users who wish to establish inbound or outbound connections • To associate data streams that are allowed to pass through the firewall with previously authenticated and authorized users • It is a policy decision if a data stream is allowed to pass through a firewall • Consequently, the definition leads to the necessity of an explicitly defined firewall policy • This is similar to the definition of Cheswick and Bellovin

6. Firewall Characteristics • Four general techniques: • Service control • Determines the types of Internet services that can be accessed, inbound or outbound • Direction control • Determines the direction in which particular service requests are allowed to flow

7. Firewall Characteristics • User control • Controls access to a service according to which user is attempting to access it • Behavior control • Controls how particular services are used (e.g. filter e-mail)

8. Overview • In either case, a firewall provides perimeter security and does not protect against insider attacks • Components • Firewall policy • Service access policy • Firewall design policy • Packet filters • Staticaly filtering devices • Dynamically filtering devices • Application gateways • Circuit-level gateways • Application-level gateways or proxy servers

9. Firewall Limitations • cannot protect from attacks bypassing it • eg sneaker net, utility modems, trusted organisations, trusted services (eg SSL/SSH) • cannot protect against internal threats • eg disgruntled employee • cannot protect against transfer of all virus infected programs or files • because of huge range of O/S & file types

10. Types of Firewalls • Packet-filtering Router

11. Packet Filtering • All information that is found in an IP packet can be used to selectively filter it (i.e., forward or drop it) • The idea evolved in the late 1980s and early 1990s to provide access control services to TCP/IP-based networks • Today, most commercial router products (e.g., Cisco routers) provide the capability to filter IP packets in accordance with a set of packet filter rules that implement a service access policy • These routers are sometimes called screening routers IP header TCP/UDP header Application data

12. Packet Filtering • The following fields should be taken into account by any packet-filtering device • Network interface • IP header • Source IP address • Destination IP address • Protocol number • TCP header • Source port number • Destination port number • TCP connection flags • Other options • UDP header • Source port number • Destination port number

13. Firewalls – Packet Filters

14. Packet Filtering • A packet filter is stateless, meaning that each IP packet is treated individually • Practical problems occur if inbound connections must be established to dynamically assigned port numbers (e.g., FTP data connection) # r1 (e.g., 1565) # 21 ftp-control (outbound) # r2 (e.g., 1567) # 20 ftp-data (inbound) FTP Client FTP Server

15. Packet Filtering • In the case of FTP, passive mode FTP solves the problem • In passive mode FTP, the FTP data connection is also established outbound • Unfortunately, the underlying problem is more general and also applies to an increasingly large number of applications (e.g., CORBA IIOP and many UDP-based and realtime application protocols) • One way to address the problem is to have packet filters establish and maintain state information to more intelligently filter TCP connections or UDP datagram transport sessions

16. Packet Filtering • This technology was originally developed, pioneered, and patented by Check-Point Software Technologies Ltd. • It was named stateful inspection and is used in the Firewall-1 PORT # r2 # r1 # 21 ftp-control # r2 (e.g., 1567) # 20 ftp-data

17. Firewalls – Stateful Packet Filters • examine each IP packet in context • keeps tracks of client-server sessions • checks each packet validly belongs to one • better able to detect bogus packets out of context

18. Attacks on Packet Filters • IP address spoofing • fake source address to be trusted • add filters on router to block • source routing attacks • attacker sets a route other than default • block source routed packets • tiny fragment attacks • split header info over several tiny packets • either discard or reassemble before check

19. Types of Firewalls • Circuit-level Gateway

20. Circuit-Level Gateways • In essence, a circuit-level gateway is a proxy server for transport layer associations (i.e., TCP connections) • A circuit-level gateway differs from a port-forwarding mechanism • Contrary to a port-forwarding mechanism, the client must be made aware of the circuit-level gateway • Contrary to a port-forwarding mechanism, the circuit-level gateway is generic in the sense that it can handle any TCP connection (if enabled in its configuration)

21. Circuit-Level Gateways Origin server Circuit-level gateway 3) The circuit-level gateway connects to the origin server and copies back and forth data between the two TCP connections Client 2) The circuit-level gateway - checks the client IP address, - authenticates and eventually authorizes the client according to a given network security policy User 1) The client establishes a TCP connection to the circuit-level gateway and requests a second TCP connection to a remote server (origin server)

22. Types of Firewalls • Circuit-level Gateway • The security function consists of determining which connections will be allowed • Typically use is a situation in which the system administrator trusts the internal users • An example is the SOCKS package

23. Circuit-Level Gateways • The most important circuit-level gateway is SOCKS as developed by David and Michelle Koblas in 1992 • The original implementation consisted of two components • A SOCKS server or daemon (i.e., sockd) • A SOCKS library that can be used to replace regular Sockets calls in client software • More specifically, the application developer has to recompile and link the client software with a few preprocessor directives to intercept and replace the regular TCP/IP networking Sockets calls with SOCKS counterparts

24. Circuit-Level Gateways • The design goal of SOCKS was to provide a general framework for TCP/IP applications to securely use (and traverse) a firewall • Consequently, SOCKS is independent of any supported TCP/IP application protocol • When a socksified intranet client requires access to an origin server on the Internet, it must first open a TCP connection to the appropriate port on the SOCKS server residing on the firewall system (the SOCKS server conventionally listens at TCP port 1080) • If this first TCP connection is established, the client uses the SOCKS protocol to have the SOCKS server establish a second TCP connection to the origin server

25. Circuit-Level Gateways • The SOCKS protocol consists of two commands • The CONNECT command requests that the SOCKS server establishes a TCP connection to a given IP address and port number using a specific username • The BIND command requests that the SOCKS server registers a client IP address and a username in case the application protocol requires the client to accept connections back from the origin server (e.g., FTP) • In either case, the username is a string that is passed from the requesting client to the SOCKS server for the purpose of authentication, authorization, and accounting

26. Circuit-Level Gateways • After having received a request, the SOCKS server evaluates the information provided by the client • The evaluation is performed against the sockd configuration file that may include a ruleset • Each rule either permits or denies communications with one or several systems • The SOCKS server sends a reply back to the client (e.g., information indicating whether the request was successful) • Once the requested second connection is established, the SOCKS server simply relays data back and forth between the two TCP connections

27. Circuit-Level Gateways • The original SOCKS implementation was further refined into a SOCKS software package and a protocol that is widely deployed and commonly referred to as SOCKS protocol version 4 (SOCKS V4) • Refer to http://www.socks.nec.com • Many client software packages have been socksified (e.g., most Web browsers in use today) using SOCKS V4 • After the successful deployment of SOCKS V4, the IETF chartered an Authenticated Firewall Traversal (AFT) WG to „start with the SOCKS system“ and to „specify a protocol to address the issue of application-layer support for firewall traversal“ in 1994 (http://www.ietf.org/ html.charters/aft-charter.html)

28. Circuit-Level Gateways • The major result of the IETF AFT WG was the specification of the SOCKS protocol version 5 (SOCKS V5) in 1996 • As such, SOCKS V5 has been submitted to the Internet standards track as a Proposed Standard and it is very likely that the protocol will become an Internet Standard • Additional features in SOCKS 5 • Alternative user authentication schemes • Cryptographic protection of data exchanged between the socksified client and the SOCKS server • Support for UDP-based application protocols • Extended addressing schemes

29. Application-Level Gateways • An application gateway works at either the transport layer ( circuit-level gateways) or the application layer ( application-level gateways) • The major difference is that a circuit-level gateway is generic and is able to proxy any TCP-based application protocol, whereas an application-level gateway is specific and is generally able to proxy only one TCP-based application protocol • Consequently, a firewall must have specific application-level gateways (or proxy servers) for every application protocol that must traverse the firewall • This is a serious disadvantage of application-level gate-ways (e.g., proprietary protocols)

30. Types of Firewalls • Application-level Gateway

31. Application-Level Gateways • In general, the use of an application gateway requires some customization and modification of either the user procedures or the client software • Both approaches have disadvantages • Consequently, it would be nice to have a firewall that maintains all software modifications required for application gateway support in the firewall • This idea led to the development of so-called transparent firewalls • Today, manyvendors provide transparent firewall products

32. Application-Level Gateways • In short, a transparent firewall is configured to listen on the network segment of the firewall for outgoing TCP connections and to autonomously relay these connections on the client's behalf • Note that • Transparency is not necessarily provided in both directions (e.g., inbound transparency is seldom required or used) • A transparent firewall still requires that all messages to and from the Internet be transmitted through the firewall • Similar functionality is required for network address translation (NAT)

33. Application-Level Gateways • The application-level gateway must be able to authenticate and authorize user requests • List of IP addresses that are allowed to connect inbound or outbound • Weak authentication schemes (e.g., password) • Strong authentication schemes • In practice, the firewall policy must define the authentication and authorization schemes that must be used in either direction and for each service • Many policies use the simplest scheme mentioned above for outbound connections and a strong authentication scheme for inbound connections

34. Application-Level Gateways • The application-level gateway or proxy server must have access to some reference information to verify whether the authentication information provided by the client (or user) is valid and legitimate (e.g., a one-way hash value of a user password or the public key certificate for a specific user) • The reference information can be stored either locally or remotely • The second approach is preferable since it makes it possible to aggregate security information and functions for several firewall systems and network access servers at a single point

35. Application-Level Gateways • Typically, a standardized protocol is used to retrieve the reference information from a centralized security server • Protocols • Remote Authentication Dial-In User Service (RADIUS) developed and proposed by Livingston Enterprises, Inc. • Terminal access controller access control system (TACACS) and its derivates (i.e., TACACS+, XTACACS, ... ) developed and proposed by Cisco Systems • Both protocols are widely supported by commercial firewall systems and network access servers

36. Firewall Configurations • Many contemporary firewall systems provide support for network address translation (NAT) • NAT basically means that an organization can use private IP addresses on its own network (i.e., intranet) to increase the address space • In RFC 1918 (BCP 5), the following blocks of the IP address space have been reserved for private use • 10.0.0.0 - 10.255.255.255 24-bit block • 172.16.0.0 - 172.31.255.255 20-bit block • 192.168.0.0 - 192.168.255.255 16-bit block

37. Firewall Configurations • A NAT firewall works similarly to a transparent firewall • IP packets with unknown destination IP addresses are routed to the network segment that hosts the NAT firewall • The NAT firewall, in turn, grabs the IP packets that request a TCP connection establishment, establishes the connection on behalf of the client, and copies data back and forth • In addition, the NAT firewall substitutes the private IP addresses (used on the intranet) with officially assigned IP addresses (used on the Internet) and vice-versa

38. Firewall Configurations • Protection against TCP SYN flooding and other (D)DoS attacks requires modifications in TCP (e.g., SYN cookies) • In the meantime, one can use ad-hoc solutions (e.g., Check-Point‘s SYNDefender, Cisco IOS TCP Intercept, ... )

39. Bastion Host • A system identified by the firewall administrator as a critical strong point in the network´s security • The bastion host serves as a platform for an application-level or circuit-level gateway

40. Firewall Configurations • In addition to the use of simple configuration of a single system (single packet filtering router or single gateway), more complex configurations are possible • Three common configurations

41. Firewall Configurations • Screened host firewall system (single-homed bastion host)

42. Firewall Configurations • Screened host firewall, single-homed bastion configuration • Firewall consists of two systems: • A packet-filtering router • A bastion host

43. Firewall Configurations • Configuration for the packet-filtering router: • Only packets from and to the bastion host are allowed to pass through the router • The bastion host performs authentication and proxy functions

44. Firewall Configurations • Greater security than single configurations because of two reasons: • This configuration implements both packet-level and application-level filtering (allowing for flexibility in defining security policy) • An intruder must generally penetrate two separate systems

45. Firewall Configurations • This configuration also affords flexibility in providing direct Internet access (public information server, e.g. Web server)

46. Firewall Configurations • Screened host firewall system (dual-homed bastion host)

47. Firewall Configurations • Screened host firewall, dual-homed bastion configuration • The packet-filtering router is not completely compromised • Traffic between the Internet and other hosts on the private network has to flow through the bastion host

48. Firewall Configurations • Screened-subnet firewall system

49. Firewall Configurations • Screened subnet firewall configuration • Most secure configuration of the three • Two packet-filtering routers are used • Creation of an isolated sub-network

50. Firewall Configurations • Advantages: • Three levels of defense to thwart intruders • The outside router advertises only the existence of the screened subnet to the Internet (internal network is invisible to the Internet)