In this lesson we will learn how access to networks and host systems are controlled.
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 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 (
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
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
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.
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.)
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 126.96.36.199 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 188.8.131.52 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 184.108.40.206 network cannot access a webserver (assuming it's listening on port 80) on the 220.127.116.11 network.
So where you place a firewall within a network affects the way it controls access to network services.
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.
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.