In this lesson we will learn how access to networks and host systems are controlled.
In the Pillars of Cyber Security discussion, 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:
|World Wide Web||HTTP||80||TCP||browsers|
|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 coerces 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 web site? 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 web servers 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
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 name server 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 name server you pick up at a bar? If the name server 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.
Or worse yet, what if you are trying to view the web site at
www.navysports.com and instead the DNS server replies with the IP address of
www.armysports.com? Your browser would say that you are at
www.navysports.com would appear in the browser's address bar, but you would in fact be reading about the Black Knights.
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. We can even filter based on the host address (IP address) of either the server or client.
What Pillar of Cyber Security do you think is associated with a firewall? Let's think about this for a minute. We use firewalls to control, allow or deny, communication on a given port or to a specific host [IP address]. General communications between hosts are required for a service to be offered by a server or used by a client. Is there a Pillar of Cyber Security associated with services? ... That's right Availability. We can use a firewall to allow or deny a service; i.e. control the availability of a service.
www.aeon.com, and we'd like to allow SSH access to it, but only from a specific computer: say from host
drip.flux.netwith IP Address
188.8.131.52. We could accomplish 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
184.108.40.206. 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.
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/
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 220.127.116.11 could access a web server within their own network, since traffic within their own network never goes through the router. Moreover, these hosts could access a web server on the 18.104.22.168 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 22.214.171.124 network cannot access a web server (assuming it's listening on port 80) on the 126.96.36.199 network.
So where you place a firewall within a network affects the way it controls access to network services.
Scenario: 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.
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 accommodate 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 web server 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.