In these days of intrusion detection systems and other ‘advanced’ ways of protecting your network against hackers, it’s easy to forget the basics. Yet it’s the simple stuff that keeps the vast majority of intruders out – and you often don’t even need a firewall to implement some basic security.

Ports and protocols
When a connection is made between two Internet-connected computers, there are three key elements in the connection request from the sender. First is the receiver’s IP address, which uniquely identifies the destination computer - rather like a telephone number uniquely identifies the recipient of a phone call. Second is the ‘port number’. This term harks back to the days when each terminal connected to a mainframe had a separate cable going into its own ‘port’ on the back of the computer, but it’s effectively a channel identifier: there are 65,000 or so available ports in an IP-based network, some of which have specific, standardised purposes (port 25 is set aside for SMTP email connections, for example) and most of which don’t. Finally we have the protocol type – TCP and UDP being the two most common for Internet communications.

These three items combine to give a very simple way of identifying and setting up connections. An SMTP email connection to X would have address X, port 25, using the TCP protocol; a DNS request to Y would have address Y, port 53, using the UDP protocol (though if the UDP connection failed, it’d try the same address and port again using TCP).

If you want to restrict the types of traffic that can get into and out of your network, then, all you need to do is enforce some rules about what address/port/protocol combinations are permitted. The best place to do this is at the device that connects the LAN to the Internet – the router. Even cheap-and-cheerful routers often have what’s called ‘packet filtering’ – the ability to forward or drop packets depending on the way they’re addressed.

The usual trick is to tell the router to drop everything and only permit certain types of traffic. So if the only incoming traffic you wanted was SMTP connections to your mail server, you’d tell the router to drop everything by default and for incoming traffic, permit connections destined for the mail server’s IP address on TCP port 25.

You’d probably want to permit some outgoing communications as well, of course – web browsing, perhaps. Nothing complicated here – simply define some rules on outgoing traffic too, in this case connections destined for external hosts on destination TCP port 80.

Connections vs packets
Internet communications are a two-way thing. So in our web browsing example above, how does the router – which has been told to allow outgoing traffic on port 80 – know to let the response back into the network when it arrives? The answer is that it depends on how the router works.

Most basic routers don’t have any concept of a ‘connection’ – that is, they don’t realise that the packets in a communication are in any way related to each other. This gives us a problem – namely that although our outgoing web requests on port 80 will be permitted, when the corresponding response comes back from the remote web server, the router won’t know that it’s meant to be passing them into the LAN.

We therefore have to define an ‘incoming’ rule for each of our ‘outgoing’ rules – and vice versa. So as well as saying ‘permit outgoing TCP packets with destination port 80’, we need to say ‘permit incoming packets with source port 80’ (when the response comes back, the source and destination ports and addresses will have been swapped over).

It’s at this point that traditional packet filtering runs out of steam, security-wise. The problem with defining ‘incoming’ rules in this way is that the router will forward packets that come in with source port 80 regardless of whether they’re genuine web responses or simply an attacker trying his luck – the router isn’t clever enough to put the response in the context of the original request and only permit the packets in if there’s a corresponding outgoing stream. It’s precisely this kind of issue that gave the early firewall manufacturers their inspiration.

This brings us to a couple of conclusions. First, implementing packet filtering on a router will definitely help keep the amount of intrusions down, because if you’re blocking all traffic except that which you think is necessary, you’re certain to be keeping a lot of attackers at bay. The second conclusion, though, is that packet filtering is not close to being sufficient to keep all attacks out.

What we can learn, though, is this: because most Internet connected networks have both a router and a firewall (the router handles the physical connection between the corporate Ethernet and whatever WAN technology’s being used – Frame Relay, ATM, basic serial comms, etc) there’s nothing to stop you doing some basic firewalling at the router. Why let the firewall get hammered with loads of junk connections when the router could be blocking them altogether? Just because it’s old, basic technology, don’t forget that the router’s in-built filtering may well be useful as a second line of defence to the network – and that at the very least it can help keep the loading on the firewall down to a minimum.

Next week: Network Address Translation