The Risks of Running Network Services

written by: Andreas Schmidt; article published: year 2007, month 09;


In: Root » Computers and technology » Linux » The Risks of Running Network Services

Dutch French Spanish Portuguese Italian German Japanese Chinese Korean Russian Arabic Bookmark and Share this Article

Standard UNIX distributions ship with a raft of network services. That should come as no surprise—after all, they are sold as general-purpose operating systems. Unfortunately, all distributions—barring OpenBSD—ship with nonessential network services enabled. They are "on" by default.

Network services provide useful functionality to clients. Remote users can download mail, log in to the system, share data remotely, use printers attached to the server—in fact, this and much more. Most significantly though, they also enable remote attackers to break into the system, grab sensitive data, snoop the network, install Trojan programs, spy on end users, crash the system, or wipe the disks.

If you're new to IT security, you might find that last statement bewildering. Wouldn't they need to log in first? Why on earth would vendors ship software like that? Well, obviously the problems that enable attacks to happen are not part of their intended functionality. As history demonstrates, however, security bugs in network daemons are very common—so common, in fact, that, when you're done installing your operating system, the chances are extremely high that your machine is vulnerable to remote attack.

Some administrators realize this and head straight for the vendor's support site to download and install the latest security patches. With that out of the way, they make the system available on the network, knowing that the system is "secure"—at least from a remote attacker. Right? Depends on the network. In general, this isn't enough. Even after applying every security patch available from the vendor, the system is still vulnerable to network attacks for four reasons:

· Insecure network daemon settings

· Insecure network kernel settings

· Insecure network protocols

· Unpublished security bugs in network daemons

Need convincing? Well, limiting ourselves to a subset of network daemons and a subset of their default insecure settings only (and that's quite a limitation), your system is probably vulnerable to some of the following problems post-install.

Your system is most likely configured to run the X Window System (whether you knew it or not). On some default installations, a remote attacker can grab screen shots and kill users'X programs—and that's just for starters. What about capturing every key the administrator types (think passwords) or remapping the administrators'keys to carry out additional commands when they hit a particular key?

Your system is most likely running an SNMP agent. SNMP agents enable emote Network Monitoring Stations (NMS) to collect system information. In its default configuration, remote attackers can also collect, and in some cases modify your system settings. More on that later.

Your system gives away the names of user ids on the system. Traditionally, the finger service was the culprit—vendors shipped the finger server enabled by default, and remote users could query finger and gain a list of usernames ready for attempting brute-force logins. After pressure from customers, the majority of vendors now ship this service disabled. But this isn't a comprehensive solution. In its default state, sendmail enables remote users to query user ids and will report whether they exist or not. Automating this check and building a dictionary of common usernames to check for is hardly rocket science.

In addition to the categories of problems previously mentioned, your system is also vulnerable to published security bugs in network services that the vendor hasn't even fixed yet. That's right—your system could be vulnerable to problems reported in public forums, and yet your vendor doesn't have a fix ready (yet). Again, this might sound crazy. Even worse—it might take six months for a vendor to fix a nasty security hole.

Your system is also vulnerable to so-called 0-day exploits. These are exploits for unpublished vulnerabilities typically sent between friends with the accompanying message of "Do not distribute." Ironically, they often spread like wildfire. In fact, this has lead to a number of security groups having to (somewhat embarrassingly) formally announce security problems they discovered simply because the information "leaked" from the group. The whole 0-day thing seems to generate a lot of excitement within certain sections of the security community (if script kiddies are actually considered to be part of the security community).

A group that argues against full-disclosure and releasing of 0-day exploits is the AntiSecurity movement.

As someone with responsibility for securing a computer system, it's important for you to realize that thousands of people are trying to "break" (meaning "compromise") systems every day. Whether they are working for a security organization, a government agency, or an operating system vendor, or as a private individual, all around the globe people are in labs attempting to find security holes.

When security flaws are discovered, the finder has a number of options. Some people inform the vendor; some publish their findings to full disclosure mailing lists. Some tell their friends, and some tell nobody. (In fact, they might do some or all of these things at different times.)

Securing Network Services

Are you depressed yet? You might be feeling that all the "evil forces" of the world are against you. Fortunately, there are steps you can take to either eliminate or reduce your system's exposure to many of these network-borne threats.

· Disable network services you don't need.

· Use available security features of the services you do need.

· If an existing network server can't be secured as-is, find a replacement that has a proven track record.

· Assume holes. Log relevant activity, analyze intelligently, and notify vendors and others.

· Keep on top of those patches or develop workarounds.

Disclaimer

1) E-articles is not responsible for the information contained by this article as well for any and all copyright infringements by authors and writers. E-articles is a free information resource. If you suspect this article for any copyright infringement, please read the terms of service and contact us to investigate the problem.
2) E-articles is not responsible for inaccuracies, falsehoods, or any other types of misinformation this article may contain and will not be liable for any loss or damage suffered by a user through the user's reliance on the information gained here.

link to this article