Firewalls and Tardis


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Firewalls and Tardis

  1. 1. Firewalls and Tardis∗ Brian Campbell January 19, 2004 ∗
  2. 2. Introduction Firewalls are being used to mediate traffic between most organisations and the Internet, and increasingly between home computers and the Internet. This talk aims to give an overview of firewalls and our use of Linux firewalls in the Tardis project, in particular the recent firewall related service failure. Note that I am not an expert in firewalls. Sorry. 1
  3. 3. Firewalls The aim of a firewall is to enforce a given policy (i.e. a set of rules) on network traffic crossing it. This helps to protect internal services from unauthorised external use and prevent accidental exposure of services or information to the outside world. Users can often see firewalls as too restrictive. Tension leads to protocols designed to bypass firewalls (e.g. SOAP). . . 2
  4. 4. Limitations of firewalls Firewalls are not an absolute solution to network security problems. There are various ways for information to pass through or around them (laptops, virtual networks / tunneling). Preventing covert com- munications between an insider and the outside world is far beyond the scope of firewalling. Tradeoffs between complexity, performance and functionality are nec- essary. We will see this happening with some protocols later. 3
  5. 5. Firewalls in networks Internet (evil) Firewall (arbiter of packet justice) Local Network (poor, vulnerable, innocent) A simple setup partitions networks in two, controlling only traffic passing to and from the Internet. 4
  6. 6. Firewalls in networks 2 Internet Laptop H S M TFirewall T T P P Laptop Local Network Firewalls let lots through, even when working properly. 5
  7. 7. Firewalls in networks 3 Internet DMZ Firewall Web server Mail server Local Network More complex setups further partition to allow finer control. The clas- sic setup is a ‘demilitarized zone’ (DMZ) where hosts which provide external services live. 6
  8. 8. TCP/IP overview All Internet traffic is carried in packets according to the HTTP DNS Internet Protocol (IP). Lowest common layer; all the TCP ICMP UDP other protocols are built on it. IP addresses are carried IP in this layer. Ether/PPP/etc (IP packets can become fragmented during transmis- sion, and usually need to be reassembled before apply- ing the firewall rules. This is typically automatic.) User Datagram Protocol (UDP) provides simple packet transmission. Usually used where the application requires low overhead or timely- ness. 7
  9. 9. TCP/IP overview 2 Traffic Control Protocol (TCP) forms a ‘virtual circuit’ (i.e. stream) connection, handling all the reassembly and retransmission for the application. Both UDP and TCP have ‘port’ numbers to identify the ends of the connections. IANA maintains the official allocations of port numbers where services can be expected to be found (e.g. HTTP on port 80), although clients can typically come from any port. The Internet Control Message Protocol provides services relating to IP (e.g. destination unreachable). Be very careful about blocking ICMP packets, as it may have subtle consequences. 8
  10. 10. Stateful firewalling Simple firewalls examine each packet in isolation. So to block TCP connections the (SYN) packets which initiate the connection are con- trolled. All other TCP packets pass through. Other protocols are more difficult. Is that UDP packet a response to something we asked? Also, higher level protocols (e.g. FTP) may use multiple connections. Stateful firewalls remember details about connections, and so can cope with these situations. Also useful for features like Network Ad- dress Translation (NAT). (So we trade greater complexity for more features.) In Linux, this is called connection tracking. 9
  11. 11. Actions on errant packets Dropping (discarding) packets is generally safe, but is a nusiance and makes problems more difficult to diagnose. (Has the machine died, or is it just dropping our packets?) Rejecting packets (with an ICMP message) makes the response clear, but produces more network traffic. Logging packets is extremely useful for diagnosing problems and notic- ing abuse. However, logs can grow large unexpectedly. Rate limiting of log messages helps prevent this. Rate limiting packets can also be useful. 10
  12. 12. Oops Our router currently hosts too many services. One being compro- mised would allow all the internal and external network traffic to be monitored. Worse: the firewall rules allowed external access to all those services! Due to the holiday only remote access was available—all of which goes through the firewall. However, there is a failsafe mechanism to allow recovery after two minutes. Linux on Sparc is a minority platform. What should I have done? 11
  13. 13. What happened? I put the firewall script under the Revision Control System (RCS) so that changes would be recorded and could be backed out. I tightened up the rules to reject by default. After applying the rules, everything appeared to continue normally. Forgot to disable the failsafe, so reapplied the rules after two minutes, without the failsafe this time. After several more minutes all the network traffic stop responding. What went wrong? 12
  14. 14. What went wrong? A daemon on the firewall machine maintains a table of routes to other networks based on information from the Informatics network. Old routes are removed if they have not been seen for some time. This information passes through the firewall. But there was no rule explicitly allowing it through, so the tightened firewall rejected it. What should I have done? 13
  15. 15. What should I have done? I should have checked which services the machine was running. I should have checked the rejected packets on trial runs before dis- abling the failsafe mechanism. I should have set up the new router earlier. 14
  16. 16. Related topics Network Address Translation (NAT) allows addresses and port num- bers to be rewritten on the fly. Useful for sharing a single IP address or redirecting a service. Application proxies provide a useful alternative or supplement to fire- walls. They often provide better separation of networks. ‘Personal’ firewalls have become popular, providing per-machine con- trol. Better yet, many provide per-application control. (Some Unix- like systems provide features which essentially firewall processes from the rest of the system, e.g. systrace and SE Linux.) 15
  17. 17. Related topics 2 Intrusion detection systems watch network traffic for dodgy data. Reading the firewall logs is a poor-man’s version of intrusion detec- tion. Firewalls can also change the contents of packets. More usefully, they can set flags in packet headers indicating priority, etc. Traffic shaping (rate limiting) can keep bandwidth use under control. 16
  18. 18. Tardis ‘opportunities’ We might get a Cisco firewall/router/toaster at some point, in which case someone will have to set it up. This would be good experience, especially given that it’s much harder to obtain than Linux/ipfilter/etc experience. Play machines (or virtual machines) could probably be made available if people want to try this stuff out. You can look at, comment on, and help out with the Tardis firewall rules. 17
  19. 19. References The Linux netfilter web pages, in particular the Packet Filtering HOWTO. RFC 2267, Ferguson and Senie, Network Ingress Filtering. Why you should enforce the right IP addresses from network interfaces. Other RFCs define most of the standards for Internet network com- munication. (IP, ICMP, TCP, UDP, DNS, HTTP, SMTP, FTP, . . . ) IANA ( hold official protocol lists. CERT Security Improvement Module Deploying Firewalls. A dry overview, but decent looking references. 18