So here goes:

First we are just going to limit the number of tries the attacker gets per session. For this we only allow expected connection methods.

MaxAuthTries 0 <--- This doesn't work on the OpenBSD ssh server, but works on Openssh
PubkeyAuthentication no
GSSAPIAuthentication no
KerberosAuthentication no

This is just so we can get a more accurate account of the attempts.

Then we restart ssh.

Go to http://www.hexten.net/sw/pam_abl and get the source.

Build it with the make command.
If you happen to have debian as I you must have:
libdb4.3-dev
libpam0g-dev

Now that the build is sucessful you should copy the pam_abl.so to /lib/security where the other pam module are located and the pam_abl executable to /sbin or where ever you want, as long as it is in your path. It is in the tools directory that also got build.

Now we have to create a config file called /etc/security/pam_abl.conf where you should put the configuration. It should look like this:

host_db=/var/lib/abl/hosts.db
host_purge=2d
host_rule=*:5/1h,10/1d
user_db=/var/lib/abl/users.db
user_purge=2d
user_rule=*:3/10m


The purge says how long people get blacklisted, the * are all users but you can define something like !root and root will never get blacklisted. The 5/1h and such means 5 bad attempts in an hour.

Then create the /var/lib/abl directory with mkdir /var/lib/abl.

Now to get pam to use it you just have to go to /etc/pam.d/ssh and put a line like this before the system-auth

auth required pam_abl.so config=/etc/security/pam_abl.conf

if you want to use it globally you can put it in your system-auth, but beware of locking yoursef out. If that happens you can unblock users before the time out happens with the tool: pam_abl that you installed although I haven't tried it yet

The output is something like:
Failed users:
/*user*/ (1)
Not blocking
root (4)
Blocking users[*]
Failed hosts:
/*host*/ (5)
Blocking users[*]

Most of this is on the documentation on site.

A note: I have tried it in another machine and there seem to be some portability issues for 64bit arch. What happens is the db files aren't created and there are other people having the same problem.

The main thing to remember about SSH is that, without digital certificates, SSH is simply an open shell into your box.

Without digital certificates, SSH is no more "secure" than RSH. Oh sure, it encrypts the traffic, but if it's an intruder's traffic then who cares? If anyone can attempt a connection, and all that's holding them back is a password, then your computer will be under constant attack.

You should therefore always use certificates ... in addition to passwords ... to make sure that SSHD does not even answer the connection request of anyone who cannot present a valid certificate. This is a very simple configuration change, easily done and abundantly documented.

Everyone does not have or want to show certificates. You have a point when you say the intruders commands are encrypted. Yet, passwords should always be strong and no need for certificates should be necessary.

--Abid Kazmi

Securehack, I respectfully dissent. And here's why...

Of course one's passwords should be strong, and of course there should be no default userids that have been overlooked ... ... but if that were actually the case, then no one would ever succeed in breaking-in anywhere.

You'd rather not let someone get to the password-prompt if you can establish sooner that they have no reasonable business being there. Certificates enable you to achieve that: "if you don't have a badge, you don't even get an opportunity to 'say the magic word.'" Steal a machine and we simply revoke that certificate and once again you're out in the cold.

The security of ssh is "no better than" that of rsh except that the traffic along the pathway is encrypted. But an intruder has little reason to try to grab a password by sniffing packets... there is an easier way. He just fires up his own ssh client and starts bombarding your system with password-guesses, and we have seen how often that's done and how well it works. If you use certificates, the intruder doesn't even get the opportunity to make a single guess. He's out in the cold without the slightest clue.

And I respectfully take your knowledge. I fully understand the whole aspect of your thinking but majority of people don't use certificates.
Most of the time, even in this thread, you can basically create a script to stop these attacks. Thus, I really did not take your facts as serious, realistic actions.
Correct. But as I have said, certificates are a no-no most-of-the-time.
Anyways, people have different security point-of-views so I will leave it at this. =)

--S. Abid Kazmi

I'd have to agree with securehack here. A certificate is only as good as the trust you have in the authority issuing the certificate. Even most of the current certificate models suffer from people fraudulently obtaining them from unwitting/lazy authorities. Plus it's fairly unrealistic to require everyone using ssh to get a validated certificate (most people running web servers have self-signed certificates anyway).

I'd also have to take issue with your notion that ssh is the equivalent to giving someone an encrypted shell. With proper password complexity and a sufficient delay time between login attempts, a true bruteforce attack is fairly unlikely to succeed. Even using a fairly rudimentary password complexity (say 6 digits and only upper + lower case characters) a parallel cracking tool that tried 5 passwords per second would take longer than your entire lifetime to cycle through all combinations (and that is assuming you know the username). These types of attacks only work well if you can try significant numbers of login attempts per second and are really more suited to offline password cracking techniques.

Respectfully acknowledging these two opinions, I close by politely maintaining my original point: ssh, just like rsh, provides you with a shell prompt. Yes, it encrypts the traffic that passes through the network, but who-cares. Once you get to a user/pass prompt, you are knocking at the door. My point is, "why wasn't there a moat? How did they make it across the drawbridge?"

When you log on to a secured web-site, the certificate owned by that web-site is intended to verify the identity of the web-site to which you are connecting. Anyone is allowed to connect. Certifying authorities are used to make it more difficult for a rogue to present a "look-alike" website.

In this scenario, per contra, your objective is to identify the user who is connecting; not the sshd-server computer to which he is connecting. Thus the situation is reversed from (or in-addition-to) the web-page scenario. "Anyone" is not "allowed to connect." You have issued a particular, uniquely identifiable, non-forgeable certificate to an authorized user, and you require anyone who wishes to enter to first present this badge, "in order to cross the moat." Only you can issue, and/or sign, the certificates that will be accepted by your system. Any certificate that is compromised can be individually revoked. Certificates cannot be forged.

The situation is exactly like the ones that businesses use to protect their buildings: they issue badges, which cannot be forged but which can be individually revoked. Persons who do not possess a valid badge cannot get far enough into the building to supply a password or use their "regular" keys.

Having no intent to start a flame-war, as of course neither of you do either, I simply observe that any "magic-word-only" scenario is inherently weaker than any scenario that involves some kind of badge. If you intend to restrict access to your system only to a set of users who are known to you, then only those users should have the ability to reach a password-prompt. SSHD provides this capability, and it must be used. Nothing less will provide adequate, manageable security.

"Script kiddies" are opportunists. Don't give them "opportunity."

Respectfully acknowledging these two opinions, I close by politely maintaining my original point: ssh, just like rsh, provides you with a shell prompt.
How would a remote shell that used certificate-based authentication be any different on that point?

Yes, it encrypts the traffic that passes through the network, but who-cares.
Anyone who would rather not have sensitive information transmitted in plaintext (like your root password).

Once you get to a user/pass prompt, you are knocking at the door.
Which if the authentication mechanism is implemented properly is more analogous to a steel vault door on a bank safe. I really think that you are significantly overestimating how easy it is to crack passwords, given that you are using a proper authentication mechanism and usernames/passwords with significant complexity. Are passwords the perfect solution? No, clearly not, but they do offer a much higher degree of security than you have implied in your previous posts. The reason this SSH attack works is not due to a fundamental SSH flaw or even a flaw with password authentication really, it's due to people being lazy and using horrendously stupid usernames and passwords. Look at the list of passwords this attack tries:
test test
guest guest
admin admin
root password
root root
root 123456

In my book if you use "root" as your "root" password then you are really asking to be hacked. In fact if you use 1 digit and 1 alphabetical character in you password, then you are immune to all most versions of this attack.

My point is, "why wasn't there a moat? How did they make it across the drawbridge?"
I do see your point and agree with you on some of it, but I really don't believe that certificates are the answer. As I see it, these are the primary problems with certificates:

• Entire process implicitly relies on you trusting the CA
  - CAs can and have been fooled into giving certs to malicious people
• Not portable
  - If I need to access a server from a random location, I need to somehow have my cert with me
• Not convenient
  - Everyone setting up a SSH server now needs to apply for the cert and wait till it's approved
• Costs $
  - certs from Verisign are $349
  - certs from less reputable CAs are like $50.
  - SSH password or key $0 --> spend $50 on beer instead

So I don't think you'll ever see certificates integrated into SSH for those reasons. Now, key-based authentication solves many of those shortcomings and is essentially invulnerable to bruteforce attacks used against password authentication. Even then, you can still have you key stolen.

I simply observe that any "magic-word-only" scenario is inherently weaker than any scenario that involves some kind of badge
I would dispute that. They both have inherent weaknesses that are very different. For example given proper implementation, it's completely possible to use a password of length and complexity that it would take longer than the universe has been in existence to crack.

good point! just that keys also suffer portability issues

RE:
Jul 19 21:04:33 server sshd[28379]: Illegal user test from XXX.XXX.XXX.XXX
Jul 19 21:04:34 server sshd[28381]: Illegal user guest from XXX.XXX.XXX.XXX
Jul 19 21:04:36 server sshd[28383]: Illegal user admin from XXX.XXX.XXX.XXX
Jul 19 21:04:37 server sshd[28385]: Illegal user admin from XXX.XXX.XXX.XXX
Jul 19 21:04:38 server sshd[28387]: Illegal user user from XXX.XXX.XXX.XXX


hrm, well I have taken the liberty of using a bit of code that was posted here:
/etc/hosts.allow
sshd: ALL: spawn (echo "Attempt from %h %A %c %d TO %d at `date` by %u %c %s %r %n %d %p" | tee -a /var/log/sshd.log)
It's not exactly perfect, but it does do what I need it to do, and that is separate the sshd entries in auth.log. Then, just copy and paste ip addresses of the scanning party into my firewall script from the newly made ( sshd.log ).
This won't solve the problem by any means, adding the ip addresses to your firewall script will just blocks the ip address of the scanner / infected computer. Worms spread like the common cold, usually on a windows box. Never The Less: Keep your usernames and passwords on the obscure nature and DO NOT ALLOW ROOT LOGINS to any outside machines, such as a firewall or server. "SU" is our friend. Also, in /etc/ssh/sshd_config you may want to change the port that ssh uses and forward that port on the firewall. This will help to identify a true hax0r that has port scanned you for the use of a brute force ssh.
http://stephnet.zapto.org/firewall.png

Sincerely,

Wanker
Stephnet's Administrator

Am I missing something or forwarding the port is the same as using the standart port?

You should change the port that sshd listens on. By default it uses port 22. For security sake edit the sshd_config file and change the port number to something other than the default. I recommend making the following changes:
<CODE>
# Only v2 (recommended)
Protocol 2

# Both v1 and v2 (not recommended)
#Protocol 2,1

# Only v1 (not recommended)
#Protocol 1

# Listen port (the IANA registered port number for ssh is 22)
Port xxx
</CODE>

As you can see I have changed the 'Port' from 22 to xxx with xxx representing the port of your choice. Now also edit the /etc/services file to reflect the port's function:
/etc/services:
<CODE>
#ssh 22/tcp <--(Commented out)
ssh xxx/tcp # Secure Shell
</CODE>

Edit the file as root and save it.

Now in your router you need to forward the port you picked to the ssh box (presuming you use a normal router with NAT enabled).

You may need to restart sshd for changes to take affect but I am not sure. Depending on your distro you can try:

<CODE>
/etc/init.d/sshd restart
</CODE>

That's it! When accessing your box remotely remember to use the new port xxx rather than the default 22.

I misunderstood, I asumed you're going to forward 22 -> to xxx at the gateway.. sorry my bad,

BTW: why is the change in services any good?

BTW2: for Redhat #service sshd restart

To all:

If you have the capability to perform asymmetric key exchange, why use passwords at all why not just turn off passwords?

RE:
================================================================================================
The security of ssh is "no better than" that of rsh except that the traffic along the pathway is encrypted. But an intruder has little reason to try to grab a password by sniffing packets... there is an easier way. He just fires up his own ssh client and starts bombarding your system with password-guesses, and we have seen how often that's done and how well it works. If you use certificates, the intruder doesn't even get the opportunity to make a single guess. He's out in the cold without the slightest clue.
================================================================================================

/etc/ssh/sshd_config:

PasswordAuthentication
Specifies whether password authentication is allowed. The
default is “yes”.

why not just turn it off?

PermitRootLogin
Specifies whether root can login using ssh(1). The argument
must be “yes”, “without-password”, “forced-commands-only” or
“no”. The default is “yes”.
If this option is set to “without-password” password authentica-
tion is disabled for root.

Also, if you combine this with iptables to allow only certain networks, address ranges or individual ip's to access the system, you limit the risk even more. You can additionally set icmp to not answer or DROP.

There are other things that can be done to improve security, like using SELINUX, AIDE or Tripwire or a system that monitors other system for changes and if something that get's modified then copy back the original binary immediately, before it can be exploited.

I think that SSH can be as secure as you want it to be if ... someone has not planted holes in it.

Certificates require one to trust the 3rd party.

Cheers.

RE: forwarding sshd ports for security
Thank you Mossy.

Q. why is the change in services any good?

Well, services (ssh) changing the port it listens on is good security practice anyway unless you run a large network that has multiple shell accounts for users, such as an isp, ect.. My firewall script using iptables blocks port scans and now port 22 the default port for ssh. Before I didn't really have a reason to change the port that sshd listens on because we are a small network and we didn't really have any issues until recently. In lieu of this new (worm - malware) that attempts ssh logins it makes sense to change the port.

Q. for Redhat #service sshd restart

I guess I'm unclear on if this is a question or an answer. If your asking how to restart the service ssh in Redhat, I'm prolly not the guy to ask because I run Debian Linux. In debian all your services should be in /etc/init.d/
and that would be something like /etc/init.d/ssh restart
I hope this sheds some light on why I recommend changing ports for sshd.
Sincerely,

Wanker
Stephnet's Administrator