Wrap a Security Blanket Around Your Computer
With the Internet growing by leaps and bounds, the security of computer systems has become a major focus of large corporations, small businesses and individuals alike. Hardly a week goes by without a security flaw being discovered in some network. Many companies are reducing the threat by installing firewalls between their internal networks and the Internet, but this option is generally too expensive and cumbersome for single users running Linux from home or office. TCP_wrappers was written by Wietse Venema, Eindhoven University of Technology, The Netherlands. It provides a simple, elegant and effective means to safeguard your network services from being accessed and possibly abused by intruders.
In this article we will discuss what TCP_wrappers are and how they work, and how to configure TCP_wrappers to protect your machine from unauthorized access. We'll also discuss some of the more advanced features of TCP_wrappers which provide detailed logging and can even help track attempts to break into your machine.
First, we need to know how a transmission control protocol (TCP) connection, such as telnet, is accomplished. TCP network connections are based on the “client/server” model. The telnet program is a client that communicates with a server program, or daemon, called telnetd or in.telnetd, depending on how your machine is set up. Since most Linux distributions use the name in.serviced in the directory /usr/sbin for network daemons, I will use that naming convention for the remainder of this article.
All requests for network services first go through the “Internet daemon”, inetd. (As with all things in life, there are exceptions to this rule, see “What TCP_wrappers Cannot Do” below.) This daemon uses two configuration files to determine how to respond to requests for network connections. The file /etc/services lists the names of particular services and the port numbers for those services. The file /etc/inetd.conf lists the names of the services and the names of the programs or daemons providing the services. Listing 1 and Listing 2 contain some sample lines from the /etc/services and /etc/inetd.conf files.
If I sit down at my.linux-box.com and type the command:
telnet your.machine.com
My telnet client sends a packet of information containing (among other things) the Internet address of the source my.linux-box.com, the Internet address of the destination your.machine.com and the port number for the connection. The port number for telnet is 23. inetd looks up port 23 in /etc/services and finds the service name telnet. It then looks up telnet in /etc/inetd.conf and finds that it needs to run the daemon called in.telnetd, listed in the rightmost column of Listing 2. inetd runs in.telnetd connecting it to port 23 and then goes about the business of listening for more connections. in.telnetd responds to my client, asking for a user name and password and starting up the telnet session.
What if you don't want anyone else to telnet into your computer? You can modify the code for in.telnetd to look at the source address of the connection request and to reject any addresses from outside your local machine or domain. If telnet were the only network service this would be easy, but there are dozens of network services, and it would be a nightmare to modify every daemon to limit access to your machine.
At this point TCP_wrappers comes to the rescue. The wrapper program is a tiny daemon that stands between inetd and network daemons such as in.telnetd and in.ftpd. Since all TCP connections are started up in basically the same fashion, a single wrapper program can be used to control access to almost all TCP network services.
When wrappers are installed, the Internet daemon is reconfigured to run the wrapper instead of the ordinary network daemon. The wrapper checks the source address of the connection and the service it wishes to connect to and decides whether to allow the connection. If your.machine.com denies my request for a telnet session, all I see is a dropped connection. If the request is allowed, everything proceeds normally, and the wrapper never actually interacts with my telnet client. In either case, the wrappers write a note in the system logs to let you know whether I was successful in connecting to your machine.
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| 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 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
| Dart: a New Web Programming Experience | May 07, 2013 |
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- RSS Feeds
- Trying to Tame the Tablet
- New Products
- What's the tweeting protocol?
- Dart: a New Web Programming Experience
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.




17 min 19 sec ago
2 hours 49 min ago
7 hours 29 min ago
9 hours 51 min ago
1 day 2 hours ago
1 day 5 hours ago
1 day 6 hours ago
1 day 7 hours ago
1 day 7 hours ago
1 day 12 hours ago