Wrap a Security Blanket Around Your Computer
TCP_wrappers write a message into your system logs every time a connection is requested, whether it is granted access or not. These entries in the logs above are reason enough to have TCP_wrappers installed on your system. The messages are written through the standard syslog facility and by default go to the same place as mail transactions. On my Linux distribution, Caldera Network Desktop based on Red Hat Linux, the default has been changed so that the messages are written to the same log file as other daemons (LOG_DAEMON facility).
In any event, when someone accesses my machine via telnet, a message like this is placed in the /var/log/messages:
Apr 9 17:24:58 ads in.telnetd[15339]: connect from somewhere.else.com
If the connection was refused, the message would read:
Apr 9 17:25:15 ads in.telnetd[15604]: refused connect from someother.place.comIf I want to see all the telnet attempts in my log, I can simply type the command:
grep telnetd /var/log/messagesTCP_wrappers can give me even more information through the use of “booby traps”. TCP_wrappers can be configured to run shell commands when certain services are requested. Let's assume I have reason to suspect someone at nasty.badguy.com is trying to use the Trivial FTP program (TFTP) to steal my password file. In my /etc/hosts.deny file, I can put the following line (this example is straight from the hosts_access(5) man page that comes with TCP_wrappers):
in.tftpd : nasty.bad-guy.com : ( /usr/sbin/safe_finger -l @%h |\
/bin/mail -s %d->%h root) &
Access to TFTP is denied to all users from
nasty.badguy.com. In addition, the command:
safe_finger @nasty.badguy.comis run, and the results are piped into a mail message sent to the root user with the subject line:
in.tftpd->nasty.bad-guy.comsafe_finger is a command provided along with the TCP_wrappers that strips out any “bad” characters, like control sequences and data overruns. Running safe_finger @hostname generates a list of everyone currently logged into that system. The strings %h and %d are called expansions, and tcpd replaces them with the corresponding text for the host name and daemon process, respectively. Other expansions include %a for the client Internet address and %u for the client user name.
Now, this isn't a perfect solution, since our cracker friend may have disabled his finger service or altered it to give false information; however, this example does show us the power of the TCP_wrappers program.
The access control language in the /etc/hosts.allow and /etc/hosts.deny files is quite simple, yet powerful, but TCP_wrappers can be compiled to include even more powerful extensions to the normal access controls. Instead of having the line:
service : host
in the configuration files, you can have the line:
service : host : option : option ...Where option can be allow, deny or many other advanced options.
To enable the advanced options, compile the wrapper programs with the -DPROCESS_OPTIONS. The wrappers are compiled in this way by my Caldera/Red Hat distribution. To check your distribution for the advanced options, run tcpdchk<\!s>-a. On my system, I see the following output:
warning: /etc/hosts.allow, line 6: implicit "allow" at end of rule warning: /etc/hosts.allow, line 7: my.isp.net: host not found warning: /etc/hosts.allow, line 7: implicit "allow" at end of rule warning: /etc/hosts.allow, line 8: implicit "allow" at end of rule
The message implicit<\!s>"allow" indicates my version of the wrappers is looking for additional options in the /etc/hosts.allow file. If your distribution does not have PROCESS_OPTIONS compiled in, you will not see this message.
Using the advanced options, we can do away with the /etc/hosts.deny file entirely, since the options for "allow" and "deny" can be added to any rule. We can change the logging level, control the priority (“niceness”) of the network service, look up user names with the RFC 931 “ident” protocol and display customized “banners” for each service.
More information on these advanced features can be found in the hosts_options(5) man page included with TCP_wrappers, or in the Garfinkel & Spafford book cited above (a must-read for anyone concerned with network security). For now, let's convert our /etc/hosts.allow and /etc/hosts.deny files to use the advanced options. The etc/hosts.deny file is no longer needed. In /etc/hosts.allow we rewrite the rules as follows:
ALL : localhost : allow
in.telnetd : my.isp.net : allow
in.fingerd : ALL EXCEPT .cracker.org : allow
in.tftpd : nasty.bad-guy.com : spawn \
(/usr/sbin/safe_finger -l @%h |\
/bin/mail -s %d-%h root) &
: deny
ALL : ALL : deny
In English, this says the following:
All services from our own machine are allowed.
telnet is allowed from my.isp.net.
finger is allowed from everywhere except hosts in the cracker.org domain.
tftp is not allowed from nasty.badguy.com, and if they try, we will spring a “booby trap” to find the guilty party.
All other services from everywhere else are denied.
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.
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
| 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 |
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?




1 hour 10 min ago
1 hour 28 min ago
3 hours 21 min ago
5 hours 14 min ago
12 hours 8 min ago
12 hours 24 min ago
14 hours 16 min ago
20 hours 8 min ago
1 day 39 min ago
1 day 40 min ago