“The only system which is truly secure is one which is switched off and unplugged, locked in a titanium lined safe, buried in a concrete bunker, and is surrounded by nerve gas and very highly paid armed guards. Even then, I wouldn’t stake my life on it.”

This view, expressed by a university director of computer operations, is shared by many. However, in real life, network systems must be accessible, open to their users, and easily manageable. None of these factors lend themselves well to high security, but there are certain fairly easy steps you can take to alleviate some of the most obvious risks.

Firstly, decide what you are trying to protect yourself from. This will help you decide what level of paranoia to cater for. Unless you work for a government agency or high profile pharmaceutical multinational, it’s unlikely you need to secure your network against infiltration from a foreign power. More likely your risks are from a disgruntled soon-to-be ex-employee, a developer trying out a jazzy new application on a server on your live network, or the hacker who’s out to prove his ‘skills’ but doesn’t really have anything against your company personally. In these instances, some relatively basic measures will suffice to protect your network against the majority of hazards.

Open router

Your routers control your network access. Get into these, and someone could wreak havoc on your network. It’s now two years since I left a company where I looked after a sizeable routed infrastructure for a multinational corporation, yet if I could get back into the building I would still be able to log in to the routers. With no centralised access control, such as TACACS, each router has a list of user IDs and passwords. Because of the hassle involved in going round every device to modify this list, old IDs are rarely removed — and the passwords aren’t changed for valid users either.

Many routers are configured such that you need a password to be able to telnet in, but if you can connect directly to the console port you’re away. Again, with an estimated 80 per cent of security issues coming from within an organisation, don’t be blasé about the need for physical access providing you a level of security. You may also want to restrict where the router will accept telnet requests from for further security, although this is seldom popular with Ops, who like the freedom to be able to log in from anywhere on the network.

Restrict addresses from where your routers will accept SNMP commands — read-only as well as read/write. You can learn a lot about someone’s network if you launch a MIB walker tool against a core router. Equally, turn off services, such as finger, that can again provide a wealth of topology information.

Set up access lists to control access to areas within the network and to limit traffic. Quite apart from security concerns, passing vast quantities of routing updates over a slow speed WAN to a site with only one exit point is wasteful. Oh, and if you can, apply access lists on input interfaces rather than output ones: again its wasteful to process traffic just to throw it away on the last leg.

On the subject of filtering, since DDoS attacks tend to originate from spoofed RFC1918 addresses, applying anti spoofing filters on your inbound interfaces from the Internet will prevent this unauthorized traffic from reaching your corporate network. Of course your ISP shouldn’t be allowing this sort of addressed traffic across their network anyway – it’s worth asking them though.

Network devices tend to be quite good at telling you if they’re not happy about things. Log configuration changes, so you can tell if anyone’s doing anything they shouldn’t, and monitor exception reports that might point at security breaches. And actually look at the syslog reports on a regular basis.

It’s quite easy to put something on a network that sends out routing information, persuades all your routers that it has a better path to the rest of the world, and blackholes all your traffic. It won’t affect your servers and databases, but nobody will be able to access them — and that goes for all your commercial web servers too. Set up authentication — typically MD5 based - on your routing updates, and you won’t have to worry about this.

Switching on…

Switches too, have security mechanisms, if you care to use them. Access to them should be protected, as for routers. Disable unused ports so that users can’t just plug in wherever they like. Options like port security — allowing only specified MAC addresses to use a port — or the newer and more flexible 802.1x standard that ties login names to specific VLANs, offer total control over your switched infrastructure.

Rate-limit traffic, particularly broadcast or multicast traffic. Users typically don’t use or need 100Mbit/s but if a java application goes awry, and starts sending multicasts out at a rate of thousands per second, you could find that while the switch port can handle the throughput, the segment’s router falls over trying to process all those multicasts. The end result will be a loss of network connectivity.

There are a lot more security measures you can take, using for example intrusion detection probes and dedicated firewalls, but the steps listed above are all possible using the facilities of your existing network hardware, without spending any of your IT budget. As a bare minimum, make sure these are applied, and give yourself a better degree of comfort.

Louise McKeag is a network administrator for a large UK enterprise.