Softpanorama May the source be with you, but remember the KISS principle ;-)	Home	Switchboard	Unix Administration	Red Hat	TCP/IP Networks	Neoliberalism	Toxic Managers
	(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix

TCP Wrapper support and SSH Security issues

In many cases using firewall is an overkill and badly affect applications. In this case TCP wrappers as lightweight and very elegant solution for controlling access of any communication protocol can be used instead.

There are two ways to use TCP-wrappers. The most common method, wrapping, is applied to TCP servers that are normally invoked by inetd. You "wrap" the server by editing /etc/inetd.conf and modifying the server's configuration line. Instead of invoking the server directly, you invoke the TCP-wrapper daemon, tcpd , which in turn invokes the original server. However, sshd is usually not invoked by inetd , so the second method, source code modification, must be applied. To participate in TCP-wrapper control, the SSH server must be compiled with the flag -- with-libwrap to enable internal support for TCP-wrappers. sshd then invokes TCP-wrapper library functions to do explicit access-control checks according to the rules in /etc/hosts.allow and /etc/hosts.deny. So in a sense, the term "wrapper" is misleading since sshd is modified, not wrapped, to support TCP-wrappers.

Both Solaris and Linux ssh is compiled with TCP-wrapper support

/etc/hosts.allow
/etc/hosts.deny

As ssh is compiled with LIBWRAP support, tcp-wrappers access controls may be defined as described in the hosts_access(5) man page.

On other operating systems you mileage can vary. If there is no built-in TCP wrapper support you have two options:

recompile ssh with TCP wrapper support
use xinetd or inetd with TCP wrappers for launching the daemon

TCP-wrappers Configuration

The access control language for TCP-wrappers has quite a few options and may vary depending on whose package you use and what version it is. We won't cover the language completely in this book. Consult your local documentation for a complete understanding: the manpages on tcpd (8), hosts_access (5), and hosts_options (5). We will just indicate some simple, common configurations.The TCP-wrapper configuration is kept in the files /etc/hosts.allow and /etc/hosts.deny. These files contain patterns of the form:

service_1 [service_2 service_3 ...] : client_1 [client_2 client_3 ...]

Each pattern matches some (server,client) pairs, and hence may match a particular client/server TCP connection. Specifically, a connection between client C and server S matches this rule if some service service_i matches S, and some client_j matches C. (We explain the format and matching rules for these subpatterns shortly.) The hosts.allow file is searched first, followed by hosts.deny. If a matching pattern is found in hosts.allow, the connection is allowed. If none is found there, but one matches in hosts.deny, the connection is dropped. Finally, if no patterns match in either file, the connection is allowed. Nonexistence of either file is treated as if the file existed and contained no matching patterns. Note that the default, then, is to allow everything. There is also an extended syntax, documented on the hosts_options (5) manpage. It may or may not be available, depending on how your TCP-wrapper library was built. It has many more options, but in particular, it allows tagging an individual rule as denying or rejecting a matching connection; for example:

sshd1 : bad.host.com : DENY

Using this syntax, you can put all your rules into the hosts.allow file, rather than having to use both files. To reject anything not explicitly allowed, just put ALL: ALL:DENY at the end of the file.

In a pattern, each service is a name indicating a server to which this pattern applies. SSH recognizes the following service names:

sshd: The main SSH server. This can be sshd, sshd1, sshd2, or whatever name you invoke the daemon under (its argv[0] value).
sshdfwd-x11: The X forwarding port.
sshdfwd-N: Forwarded TCP port N (e.g., forwarded port 2001 is service sshdfwd-2001).

TIP: The X and port forwarding control features are available only in SSH1 and SSH2; OpenSSH uses only libwrap to control access to the main server.

Each client is a pattern that matches a connecting client. It can be:

An IP address in dotted-quad notation (e.g., 192.168.10.1).
A hostname (DNS, or whatever naming services the host is using).
An IP network as network-number/mask (e.g., 192.168.10.0/255.255.255; note that the "/n-mask-bits" syntax, 192.168.10.0/24, isn't recognized).
"ALL", matching any client source address.

a sample /etc/hosts.allow configuration. This setup allows connections to any service from the local host's loopback address, and from all addresses 192.168.10.x. This host is running publicly available servers for SSH1, POP, and IMAP, so we allow connections to these from anywhere, but SSH-2 clients are restricted to sources in another particular range of networks.

#
# /etc/hosts.allow 
#
# network access control for programs invoked by tcpd (see inetd.conf) or 
# using libwrap. See the manpages hosts_access(5) and hosts_options(5). 
# allow all connections from my network or localhost (loopback address)
 
ALL : 192.168.10.0/255.255.255.0 localhost

# allow connections to these services from anywhere

ipop3d imapd sshd1 : ALL 

# allow SSH-2 connections from the class C networks 
# 192.168.20.0, 192.168.21.0, ..., 192.168.27.0 

sshd2 : 192.168.20.0/255.255.248.0 

# allow connections to forwarded port 1234 from host blynken sshdfwd-1234 : blynken.sleepy.net 
# restrict X forwarding access to localhost 

sshdfwd-x11 : localhost 

# deny everything else

ALL : ALL : DENY

We allow connections to the forwarded port 1234 from a particular host, blynken.sleepy.net. Note that this host doesn't have to be on any of the networks listed so far but can be anywhere at all. The rules so far say what is allowed, but don't by themselves forbid any connections. So for example, the forwarding established by the command ssh1 -L1234:localhost:21 remote is accessible only to the local host, since SSH1 defaults to binding only the loopback address in any case. But ssh1 -g -L1234:localhost:21 remote is accessible to blynken.sleepy.net as well, as is either command using ssh2 instead (since ssh2 doesn't affect the localhost restriction and ignores the -g option). The important difference is that with this use of TCP-wrappers, sshd rejects connections to the forwarded port, 1234, from any other address.

The sshdfwd-x11 line restricts X-forwarding connections to the local host. This means that if ssh connects to this host with X forwarding, only local X clients can use the forwarded X connection. X authentication does this already, but this configuration provides an extra bit of protection.[127]

The final line denies any connection that doesn't match the earlier lines, making this a default-to-closed configuration. If you wanted instead to deny some particular connections but allow all others, you would use something like this:

ALL : evil.mordor.net : DENY telnetd : completely.horked.edu : DENY ALL 
	: ALL : ALLOW

The final line is technically not required, but it's a good idea to make your intentions explicit. If you don't have the host_options syntax available, you instead have an empty hosts.allow file and the following lines in hosts.deny:

ALL : evil.mordor.net telnetd : completely.horked.edu

Notes About TCP-wrappers

Here are a few things to remember when using TCP-wrappers:

You can't distinguish between ports forwarded by SSH1 and SSH2: the sshdfwd-* rules refer to both simultaneously. You can work around this limitation by linking each against a different libwrap.a, compiled with different filenames for the allow and deny files, or by patching the ssh and sshd executables directly, but then you have to keep track of these changes and extra files.
The big drawback to TCP-wrappers is that it affects all users simultaneously. An individual user can't specify custom access rules for himself; there's just the single set of global configuration files for the machine. This limits its usefulness on multiuser machines.
If you compile SSH with the -- with-libwrap option, it is automatically and always turned on; there's no configuration or command-line option to disable the TCP-wrappers check. Remember that SSH does this check not only for forwarded ports and X connections but for connections to the main SSH server. As soon as you install a version of sshd with TCP-wrappers, you must ensure that the TCP-wrappers configuration allows connections to the server, for instance with the rule sshd1 sshd2 sshd : ALL in /etc/hosts.allow.
Using hostnames instead of addresses in the TCP-wrappers rule set involves the usual security tradeoff. Names are more convenient, and their use avoids breakage in the future if a host address changes. On the other hand, an attacker can potentially subvert the naming service and circumvent the access control. If the host machine is configured to use only its /etc/hosts file for name lookup, this may be acceptable even in a highly secure environment.
The TCP-wrappers package includes a program called tcpdchk. This program examines the wrapper control files and reports inconsistencies that might signal problems. Many sites run this periodically as a safety check. Unfortunately, tcpdchk is written only with explicit wrapping via inetd.conf in mind. It doesn't have any way of knowing about programs that refer to the control files via the libwrap routines, as does sshd. When tcpdchk reads control files with SSH rules, it finds uses of the service names sshd1, sshdfwd-n, etc., but no corresponding wrapped services in inetd.conf, and it generates a warning. Unfortunately, we know of no workaround.

Top Visited <p>Your browser does not support iframes.</p>					Switchboard
					Latest
					Past week
					Past month

NEWS CONTENTS

190313 : Se ( Se, )

Old News ;-)

Se curing SSH Using Denyhosts

Posted by narom on August 20th, 2007 SSH is a great way to remotely administer a server. However, it still has a number of issues when you open it up to the world. The server and client communications are secure but that doesn't mean the hosts involved are. Opening an SSH service to the world allows for brute force attacks and means that the carbon interface is still the weakest link.

There are some very simple steps you can take to really harden remote access over SSH, especially if you can't simply tie the service down to a limited number of source ports.

First things first, sshd_config. In Ubuntu this is usually found in /etc/ssh and can be used to configure a great number of features. The simplest ones to deal with are always the best. Restricting the users who can login via SSH is a first principle. This can be done in one of two ways, by user or by group. AllowGroups allows any user in this group authenticated access to the server via SSH. A more fine grained approach is to use the AllowUsers option.

Another easy win is by moving the listen port from 22 to some other randomly assigned port. This reduces the likelihood of a scan showing SSHD running.

Other steps you might want to take include disabling root access, disable password authentication and using keys only.

The next step is a wee tool called Denyhosts (http://denyhosts.sourceforge.net/). Make sure you've got the additional sources enabled in /etc/apt/source.list and then type:

sudo apt-get update

sudo apt-get install denyhosts

DenyHosts is a python script intended to be run by Linux system administrators to help thwart SSH server attacks (also known as dictionary based attacks and brute force attacks).

Denyhosts acts as a dynamic blocker for SSH and other services. It relies on the /etc/hosts.deny and hosts.allow. It dynamically builds a list of hosts that repeatedly connect to your server. By default the service will block connections from IP sources that are repeated attempting to connect and access your host. The denyhosts process is configured in /etc/denyhosts.conf

There are additional things that can be done using iptables to rate limit connections and you should always run a firewall on your hosts but I'll deal with that in a separate post.

Once you've put these steps in place you can rest assured the SSH on a public facing host is much more secure, there's no guarantees but every little helps.

Tags: Denyhosts, General, installing denyhosts ubuntu, Networking, security, Server, SSH hardening, Ubuntu Security

8 Responses to "Securing SSH Using Denyhosts"

Patrick Says:
August 24th, 2007 at 8:50 am
This is great but I also recommend sshblack - a perl script that tails your syslog or messages and sees the sshd failed login attempts. You can then set a number of failed attempts before adding the host to a deny rule in your iptables firewall. This will block any traffic from this host for a set amount of time. Works wonders! I've adapted it to check my apache logs for certain know virus/worms and block those hosts too.
Zlatko Says:
August 27th, 2007 at 3:07 am
All great, I've used DenyHosts year or two ago. But I have much simpler and more effective solution. Just start SSH service on another port. Yeah, that's. Instead of 22 use anything else, for example 10022. In /etc/ssh/sshd_config change Port 22 to Port 10022, restart and you're done. I guarantee you that not one probe will reach your port. DenyHosts will still pass a few, before it blocks the port. And you can remember the new port easily, or just put it into ~/.ssh/config and be done.

The effectiveness of this approach is based on the fact that port 22 is hardcoded in all those cracker scripts, and they don't bother searching for ssh on another port. It's much harder for them if they also need to find the port, so they count on many people who leave ssh at default port.

Try this approach and you won't regret it.
Jim Says:
August 27th, 2007 at 3:51 pm
I don't know about that !!

in my /var/log/secure I see crackers going after a number of different ports to find my ssh port,
It seems they are checking other ports more than port 22.
I also use fail2ban, and ban IPs for about 20 minutes and i don't seem to see any repeats of same IP after that.
Peter Boosten Says:
August 28th, 2007 at 10:48 am
Many solutions to the same problem: I use sshguard, which basically does the same.

There are other things you can do as well, like limiting the number of IP addresses you can connect from in your authorized_keys file (I do that for several users): the account of our service desk to access the machines has been limited to internal IP addresses only, since this account has the power (sudo) to shutdown or reboot the machine. I don't want that to happen from 'the outside'.

The authorized_keys file looks a bit like this:
from="192.168.1.*,192.168.2.*,192.168.200.*" ssh-rsa [key goes here] [user]

The file itself is immutable for the user himself.
Rich Says:
August 28th, 2007 at 5:52 pm
All of the above suggestions are fine, except that they all leave a small window of opportunity for a brute force scan to succeed. If during the first few tries, they randomly find a matching user/pass pair, they are in, even with all of the above options. Yes, low likelyhood, but not zero likelyhood.

A better solution is ssh-faker: http://www.pkts.ca/ssh-faker.shtml

It is setup so that only the set of IP addresses you actually use to connect to it are allowed through to the sshd deamon. Everyone else stops at ssh-faker and needs to enter a password here first, before they even get to the sshd deamon the very first time. Result, hacker attack scans for sshd ports (no matter what port) are stopped dead because they think they find an sshd, but it does not work like an sshd. So they don't even get one try to brute force a user/pass to sshd.

You, when you connect from a new IP, simply telnet to your machine and port (telnet machine 22) and enter your ssh-faker password. Ssh-faker then puts an entry into /etc/hosts.allow that then lets you connect straight through to sshd from that IP.

If you usually connect from only 2 or 3 static ip locations, you'll only have 2 or 3 IP's in hosts.allow. If you connect from varied different locations, all you have to do is periodocally clean the entries from hosts.allow to make sure no one else gets a try.
Ross Peoples Says:
August 30th, 2007 at 9:14 pm
DenyHosts is great! I'm so glad I came across this article. Not 10 minutes after installing it, I've already got IP's in my deny list. It's not like I run a server or anything, it's my desktop machine at home. I had no idea this scanning happens so much so often. Thanks for bringing this to our attention (or at least mine).
lws Says:
September 1st, 2007 at 11:09 am
Thank you very much by the article!
A very good work!
--------
riseringseeker Says:
September 3rd, 2007 at 3:17 am
denyhosts is working great for me, blocks all kinds of bad guys. The only problem I am having is since I changed from Mandriva to Ubuntu, I cannot get a reprt sent to ADMIN_EMAIL. I had a little trouble with this in Mandriva as well, but cannot remember how I overcame it.

Any suggestions would be welcome!

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 12, 2019