Problem solve Get help with specific problems with your technologies, process and projects.

Authorization by authentication

A look at how you can restrict HTTP traffic by authenticating at the firewall, router or switch.

The vast majority of firewalls in place today do not discriminate by user. Primarily, they filter packets based on protocols and IP addresses; for example, permitting HTTP on port 80 to and denying all other traffic. This is generally acceptable on the public internet, but more often than not, in intranet or extranet environments, what we really want to do is allow some specific people to get access to an area of the network and have other people denied regardless of what their IP address is and even if they're using the same protocol.

Historically, this has been prohibitively difficult because in order to enforce some policy by user on a firewall or router or switch, you have to authenticate the user at the firewall, router or switch, and those devices were designed to be transparent. That is, the user doesn't even know or care which or how many of those devices exist in the path between his client and the server.

In the past few years, a few features have gradually made their way into network devices that make this worth doing, but they're still quite cumbersome to the user and not very popular. The first set of features you should consider deploying revolves around authentication. One of the easiest ways to do this involves having the user start a telnet, FTP or HTTP session to the network device, which is configured to challenge the user for a name and password, and possibly digital certificate or other multi-factor authentication. Some examples of technologies that use this method are "Lock and Key" and "Auth proxy".

The downside of this is that the user has to remember a domain name or IP address to authenticate to, and open a browser or command line (which is annoying if all you want to do is run an accounting program or access a file server). Perhaps in the not too distant future 802.1x could be used for a more seamless experience, but we'll probably have to wait for IPv6 for a real solution.

Of course, as part of the authentication, you'll need an account database. Given the nature of networks, you're well advised to deploy a RADIUS or TACACS+ server. Many freeware products are available.

The second part of this is authorization. When your user authenticates, the router or firewall (which was blocking all traffic to the resource) can take user-specific access-lists and add them to its existing ACLs. For instance, changing "deny any traffic to the server" to "permit port 80 to the server, but only from the IP address from which the user just authenticated". This temporary change to the ACL remains until it expires. Some vendors support downloading these temporary ACLs from the RADIUS server, which can be pretty handy.

One important thing to know about these technologies is that even though the authentication may require user ID and password, a token, retinal scan and maybe some blood work, the authorization is still only by IP address. It's really only a hack to deal with dynamic addresses. That is, if the user had a static IP address, you could simply add these rules permanently to the ACL and achieve similar security. If a user authenticates and leaves, and someone else takes their IP address before the ACL expires, the router or firewall will never know.

Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years experience in the networking industry, and co-author of several books on networking, most recently, CCSPTM: Secure PIX and Secure VPN Study Guide published by Sybex.

This was last published in June 2004

Dig Deeper on Campus area network

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.