Wrap a Security Blanket Around Your Computer
As we have seen, TCP_wrappers provide a simple and effective means to control access to our machines. However, we must still remember “There is no secure in computer security, only more secure or less secure.” As with all security measures, TCP_wrappers have their limitations.
First and foremost, wrappers cannot control access for those services started at boot-time and run until system shutdown. Services like sendmail and httpd (the World Wide Web server) fit this category. These services are always listening to their own ports and require their own access controls. Discussions of the security of sendmail and the World Wide Web fill entire volumes and are certainly outside the scope of this article.
TCP_wrappers may also be vulnerable to “host name spoofing”. Services like rsh and rlogin depend on the host name being correct. If you use a DNS server on which you cannot look up host names, it is possible for an attacker to “spoof” the name lookup by hiding his computer's name behind one your machine “trusts”. You can thwart these attacks by putting an entry for the Internet address and host name in your local /etc/hosts file, so that you do not depend on outside DNS lookups (an added benefit is that host name lookups are a lot faster). Be aware that you are now responsible for keeping the /etc/hosts file up to date. If a computer in the /etc/hosts file changes its Internet address, access will be denied until you change its entry. Fortunately, this is a rare event, and I regularly put entries in my /etc/hosts file for computers I contact often and for every host allowed access to my machine.
TCP_wrappers also do some additional homework to avoid name spoofing attacks. When compiled with the default option PARANOID (see the discussion of wild cards above), the wrappers not only check an Internet address by looking up its name but also by looking up its address. If the two don't match, access is automatically denied.
Another vulnerability can come from “source routing”, a situation where a computer from some “outside” address claims to be a trusted computer on the “inside”. TCP_ wrappers can be compiled with KILL_IP_OPTIONS to disable source routing. Luckily, we Linux users generally do not have to worry about this sort of attack, since IP source routing is turned off by default in the kernel itself.
Finally, even though you can use wrappers to control access to certain services, the best way to avoid exploitation of a service is to completely shut it off from the beginning. If you have no use for rsh or rlogin, edit your /etc/inetd.conf file and put a hash mark, #, in front of the lines for the shell and login services. This advice goes for any other service you don't use. Security holes cannot be exploited on services that are never started. “When in doubt, comment it out” is my motto.
TCP_wrappers are cheap and effective tools for controlling access to your Linux computer. Even without employing the access control features of wrappers, the ability to trace each and every connection to your machine through your system logs can be extremely valuable. TCP_wrappers can control access with a broad brush or a single pen stroke. Either way, I hope this article has raised your awareness of the ease with which you can control the “network face” of your machine.
Lee Brotzman is the Vice President of Advanced Data Solutions, a consulting firm in State College, Pennsylvania. He currently works as an instructor in Internet security, and has presented courses in Unix system security at many U.S. Government facilities. He also serves as a consultant in the design and development of networked information systems and electronic publishing. He resides in State College with his wife/business partner of fifteen years, their three children, one dog, two cats and a goldfish that thrives on dog biscuits (which makes the cats extremely nervous). He can be reached via e-mail at email@example.com.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Designing Electronics with Linux
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- What's the tweeting protocol?
- A Topic for Discussion - Open Source Feature-Richness?
- Dart: a New Web Programming Experience
- Validate an E-Mail Address with PHP, the Right Way
- Home, My Backup Data Center
1 hour 25 min ago
- Kernel Problem
11 hours 28 min ago
- BASH script to log IPs on public web server
15 hours 55 min ago
19 hours 31 min ago
- Reply to comment | Linux Journal
20 hours 3 min ago
- All the articles you talked
22 hours 27 min ago
- All the articles you talked
22 hours 30 min ago
- All the articles you talked
22 hours 31 min ago
1 day 2 hours ago
- Keeping track of IP address
1 day 4 hours ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?