In this lesson we will learn how access to networks and host systems are controlled.

Services over a Network

In the Information Assurance class, we saw the inherent tension between security and services. When you provide or make use of a service, you open a window into your system that, potentially, an attacker could use to gain access to the system.

Let's focus specifically on a few concrete network services (i.e. services that are provided over a network) that we are familiar with:

ServiceProtocolPortTCP/UDPTools
World Wide Web HTTP 80 TCP browsers
Name Resolution DNS 53 UDP nslookup
Secure Remote Shell SSH 22 TCP ssh (PuTTY)

The service here that is most obviously a security risk is SSH, Secure Remote Shell. If a host is running an SSH server, any bad guy who guesses, steals or beats out of someone a valid username and password can execute commands on that host without having physical access to the machine. So providing the service of SSH is clearly a security risk.

What's the risk in providing the service of a website? Consider an organization "foo.org" that wants to have a web site, i.e. they want to allow the World Wide Web service. They have a host (www.foo.org). There is a web-server process running on that host listening to port 80 and processing whatever HTTP requests come via that port, as webservers do. Why is there a security concern? First of all, we've seen how hard it is to write a program that deals well with unexpected input. So we are concerned that a bad guy might send a really bizarre HTTP request to port 80 on www.foo.org, such that the web-server process that recieves this bizarre HTTP requests does something undersirable (like crashing, going into an infinite loop, or reading/writing/deleting files that it really shouldn't) simply because the programmer forgot to add code that would deal gracefully with such strange input. Secondly, we saw how HTML/Javascript injection could cause bad things to happen to users of the site, so foo.org has to worry about that possiblity.

What's the risk in using the DNS service? Consider your laptop running a DNS client. You are at a local bar that provides WiFi, you connect via dhcp and are given the IP Address of a nameserver to use. Your laptop has a DNS client process that contacts the server with a query and then listens at a particular port (not 53, but some random high-numbered port, since this is a client), eventually a reply comes and the DNS client process receives it as input and does some processing based on the response. Well, can you trust a nameserver you pick up at a bar? If the nameserver is controlled by someone bad, it may be sending back some strange response that your laptop's DNS client program doesn't handle well (once again, it's hard to write a program that deals properly with unanticipated input) ... perhaps crashing the client, sending it into an infinite loop, or causing it to read/write/delete some file that it really shouldn't be messing with.

Disabling Services

Suppose you weigh the risk of providing/using a particular service versus the benefit, and decide not to provide/use it. How do you implement that decision? How do you disable a particular service? To be concrete, if you decided you didn't want your host to be a webserver, how would you put this decision into effect? There are basically two ways to do it:
  1. Don't have a web-server process running. If there's no process listening to port 80 and processing what's received there, there's no security risk. Anything sent to port 80 on the host would simply be ignored. The system administrator would have to continually monitor the system to make sure that no processes were running and listening to port 80, since process can be started by users at any time.
  2. Don't allow any data sent to port 80 to be delivered to a process. In this case, any network traffic coming in to the host bound for port 80 would be ignored by the operating system rather than delivered to a process listening on port 80. In this case, once this rule was set, the system administrator could forget about it, because whether or not users tried to start webserver processes wouldn't matter — no process will receive port 80 traffic.
This is the web-server view (and the view would be analogous for servers involved with DNS or SSH). What about the client view? What if you wanted to stop users from browsing the web? We don't really know what port incoming traffic for a webserver will use, but the outgoing traffic will have 80 as the destination port. In this case, the operating system would simply refuse to send out any network traffic that was destined for port 80, so that users could run web browsers, but the browsers would be unable to connect to webservers (at least those running on port 80).

The moral of this story is that we can disable a service by throwing out packets whose source or destination port is the port number for that service. Because the operating system lets some packets pass and throws out others, this is called filtering. (Usually we would be able to choose to filter out not only a particular port number, but also TCP or UDP, so that we could, for instance, allow UDP port 80 traffic to come in, but not TCP port 80 traffic.)

More than just on/off: Controlling who can access a service

Suppose we have a host www.foo.org, and we'd like to allow SSH access to it, but only from a specific computer: say from host drbrown.cs.usna.edu with IP Address 131.122.90.251. We could accomlish this by filtering packets so that port 22 TCP packets were all thrown out (i.e. not forwarded to the process listening on port 22) unless their source IP Address was 131.122.90.251. By filtering on a combination of port, TCP/UDP, source IP address and destination IP address, we have control over who can access what services from where to where.

Firewalls and ACLs

Packets must be disassembled to inspect internal layers and, therefore, must be reassembled before forwarding the packet. The extra memory reads and writes can significantly affect network performance, which is why sometimes firewalls are implemented as a single, highly specialized, device called a firewall.
A firewall is a device or program that filters network traffic in order to control access to services. A firewall is configured with a set of rules, called an Access Control List (ACL), which it uses to determine for each and every packet it sees whether to forward the packet to its destination or drop it (i.e. filter it out). ACL rules can forward or drop based on the sender's and recipient's IP addresses, port number, and protocol (i.e. UDP/TCP) — as you would hopefully expect given the discussions above. More advanced ACL rules filter by rate of traffic, TCP connection states, and by application layer content. The syntax used to define rules in ACLs varies between vendors, but the fundamental features are the same.

The Great (fire)Wall of China



We're interested in firewalls as a security tool — a way to implement decisions we make regarding which services to provide (or use) and to (or from) whom. However, firewalls are also used to censor content, restrict communication, and limit behavior. The most famous example of this is the "Great Firewall of China" which, although it consists of much more than just firewalls, uses firewalls as one tool to control the Chineses people's access to information and ability to communicate with the outside world. Sites like facebook.com are shutoff by simply not allowing packets bound to facebook IP addresses out, and not letting packets sent from facebook IP addresses in.

BBC article, Cracks in the wall, May 2012
Daily Mail, China Briefly Blocks ALL Foreign Sites, April 2012
Wired Old (but good) article about the wall, October 2007


Photo from http://www.flickr.com/photos/exfordy/

Click to check out the Dilbert below:

Location of firewalls

Windows 7 has a builtin firewall. That means that the operating system filters all network coming into and out of your PC. You can pull up the firewall from the Windows shell (command prompt) with the command Firewall.cpl. If you click on "Advanced Settings" in the resulting window, and then click on "Inbound Rules", you should see some of the ACL rules that define your firewall's behavior. For example, the first rule I see informs me that ICMP traffic is allowed in. If I turned this off, I would become un-ping-able!

Firewalls can also be placed in routers. This allows us to control access and services in and out of a network, rather than in and out of a single host. Let's look at one concrete example of the consequences of doing something like this. Consider the following two networks, which are connected by a router.

Suppose the firewall in this diagram is configured with an ACL rule that drops (i.e. filters out) all traffic into the router via the firewall that is bound for port 80. What is the effect in terms of services? Hosts on network 8.55.221.0 could access a webserver within their own network, since traffic within their own network never goes through the router. Moreover, these hosts could access a webserver on the 111.5.22.0 network, because that traffic, while indeed bound for port 80, is going out of the router via the firewall and so is not stopped by the rule. However, hosts from the 111.5.22.0 network cannot access a webserver (assuming it's listening on port 80) on the 8.55.221.0 network.

So where you place a firewall within a network affects the way it controls access to network services.

Interactive Firewall Exercise

We are assuming a generic ACL language for this exercise. Our ACL will only be capable of filtering IP addresses and TCP or UDP port numbers. ACL rules will look like what you see in the image to the right. Remember: Routers evaluate each rule in an ACL in order from top to bottom. Once a packet meets the criteria of a rule, the prescribed action is taken (forward or drop) and the remaining rules in the list are ignored. If the packet does not meet the criteria of any rule, then the packet is dropped by default. The next packet received is scanned and evaluated against the ACL starting over with the first rule in the list. This process repeats for each packet received by the router.

Secnario: You are a network administrator responsible for an HTTP server at 10.10.10.8, a DNS server at 10.10.10.16, and a SMB file server at 10.10.10.32 and you are tasked with designing an ACL for your organization's firewall for inbound Internet traffic. Your ACL must enforce the following criteria:

Below is your ACL. Initially it just has a rule that forwards everything (not very secure!), you can add rules, remove rules and move rules with the controls below. Build an ACL that meets your network's requirements, and test with the "Test Firewall" button. Note: Please review the Service/Protocol/Port Table to remind yourself of the port numbers and protocols associated with the services you are providing.

Note: The last rule must match all packets so that every packet is matched by at least one rule. Therfore forward/drop is the only thing you can choose.

Reviewing Network Address Translation (NAT) and Contrasting with Firewalls

At this point we'll return very briefly to Network Address Translation (NAT), which we already noted is what allows a network like USNA's to have many more hosts with internet connectivity than the number of IP Addresses is actually owns. Review the demo below to remind yourself how your laptop, which has private (i.e. not routable on the internet) IP address 10.24.126.7, can communicate with host foobar.com (64.223.160.9), which is outside USNA's network.

Your Laptop
10.24.126.7
USNA
Gateway
131.121.226.100
NAT Table
InOut
10.24.126.7:3214347688
  
  
  
foobar.com
64.223.160.9
From:
   10.24.126.7
   Port 32143
To:
   64.233.160.9
   Port 80
From:
   131.121.226.100
   Port 47688
To:
   64.233.160.9
   Port 80
From:
   64.233.160.9
   Port 80
To:
   131.121.226.100
   Port 47688
From:
   64.233.160.9
   Port 80
To:
   10.24.126.7
   Port 32143
BEGIN
DEMO
RESET
DEMO

NAT is different from a firewall, after all it's not making decisions to forward some packets and drop others. What NAT does is to allow a network like USNA to accomodate many more internet-connected hosts than available IP addresses. NAT does have some security ramifications though. For instance, in the example from the demo, could host foobar.com try using netcat to connect to your laptop on port 80 in order to determine whether or not your laptop had a webserver running on it? No! Your laptop has no real IP address, so foobar.com cannot send it packets, except to reply to requests from your laptop. Because only then would the NAT table have an entry to translate back to your laptop's internal (10.*.*.*) address.

One effect of NAT (as opposed to having hosts inside your network have real IP addresses) is that hosts inside cannot act as servers — not because any packets are blocked, but because there is no IP address that folks on the outside can use to specify hosts on the inside. So the effect is similar to having a firewall block incoming packets bound for a port like port 80. However, don't confuse NAT and firewalls. NAT does not filter packets, and it doesn't affect traffic going out of the network. One thing NAT and firewalls have in common, though, is that they slow the flow of packets in and out of the network, because each packet needs to be processed.