||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|
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
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:
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 : DENYUsing 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:
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:
# # /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 : DENYWe 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.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 : ALLOWThe 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
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
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.
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.
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.
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.
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.
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).
Thank you very much by the article!
A very good work!
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!
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
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
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
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
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|
Last modified: March, 12, 2019