All the host- and router-based services used for troubleshooting and managing your network can prove just as useful to a potential attacker who wants to get to know your network a little better. Here are some steps you can take to minimise the risks.

The first thing to be aware of is what services are running when you switch the box (server, router, whatever) on for the first time. By default many systems enable the use of at least some of these services by default, so it’s up to you if you want them disabled for security.

On a Unix system, the control of these ‘lightweight’ services is handled by inetd. On routers, it’ll be part of the config file: however if the default is enable a service, you may not see it explicitly mentioned in the config, so you’ll need to check your products’ manuals and test to see if the feature runs or not if you try it.

So what are these services, and what’s the problem with running them?

Finger:
One of the most obvious security risks (by default runs on TCP port 79). This returns detailed information when queried on everyone logged in to the system. Using an argument with finger will return information on anyone matching that argument included in the /etc/passwd file on a Unix system, whether they’re logged in or not.

Telling a potential attacker about the people who work for the company gives them a good helping hand in being able to pretend they are that person, either by guessing a password, given a username, or by contacting the help desk, say, and knowing enough about that person to convince the person at the other end to reset a password, or change access rights.

The safest thing is to disable finger altogether - although it can be handy, there are other ways of finding out the information they produce, if you’re entitled to know it.

Echo and Chargen:
The echo (TCP & UDP port 7) and character generator (port 19) services were designed for testing connections, echoing back whatever’s sent, or returning a character pattern. These can be used to create Denial of Service attacks and should be disabled.

NTP:
It is essential to run the Network Time Protocol (UDP port 123) on your network devices if you want to be able to make sense of troubleshooting logs and debugs. What you don’t want, though, is for an unauthorised device to pretend it’s the NTP server and start changing dates and times. Not only does that completely mess up any troubleshooting (including determining when the attacker carried out various attacks) but it could have pretty drastic implications if you have time-based access-lists, say, or cron jobs set.

So you should set authentication for your NTP environment - the mechanics of this will vary from device to device - typically you will configure trusted server addresses, or use a key-based authentication mechanism to ensure that anyone offering to update the time is a valid source.

Telnet:
How would we survive without telnet? Well, for security, you should. Telnet passes its data - including login details - in the clear, so should not be used where there’s a chance of that data being intercepted and read. Make sure the data is authenticated and encrypted - or do as more and more people are now doing, and use SSH instead.

Ping:
The most basic form of troubleshooting, Ping is also one of the easiest for an attacker to use to find your hosts and network devices. Ping sweeps should be detected by your Intrusion Detection Systems, but to avoid potential DoS attacks, or reconnaissance intrusions, if you have another way of testing connectivity, you should block pings from coming in from the outside world.

FTP:
If you have to let people upload files to a drop box on a server, making that directory writeable but not readable, will help prevent it being used as a host site for dodgy files that you really don’t want anything to do with. Or if it’s an FTP service that’s for downloading only, disable write access (see also feature: Keeping Unix Servers Secure). If you have to offer both, how about two servers? Make sure that users can’t change directories, or gain more information than they need. Look at passive, rather than active, anonymous FTP but restrict the range of ports your FTP server can choose to use. Many people now use HTTP (or HTTPS) to move files about instead.

TFTP:
There’s no security inherently available in TFTP so if you have to have it, make sure it runs in a restricted environment on servers. If you have TFTP enabled on your routers for backup booting, make sure that you have configured specific hosts/files that can be uploaded, and use access lists to limit what can carry out TFTP operations.

There are other services that you might need but this covers some of the most common - there will be a separate feature on DHCP and DNS implementations out soon.

Additional security measures you need to take include making sure your firewalls are correctly configured,and access lists restrict not just what addresses are allowed but what protocols also. You might want to look at running something like TCP Wrapper (see Using TCP Wrappers to restrict connections ) on your Unix servers to give you extra control over what the services themselves can offer.