Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Rundown on SSH Brute Force Attacks

Zonk posted more than 9 years ago | from the more-you-know! dept.

Security 360

An anonymous reader writes "Whitedust has a very interesting article on the recent SSH brute force attacks. The article goes into depth on how to monitor these attackes and to report them to the authorities. It also discusses various tools that are available. According to the article, mostly compromised Linux systems from outside of North America are responsible for the attacks. Even the author's DSL connection was getting break-in attempts."

cancel ×

360 comments

Sorry! There are no comments related to the filter you selected.

fp? (0, Offtopic)

Joey Patterson (547891) | more than 9 years ago | (#13081918)

FP?

Linux is still a secure OS tho, (-1)

Anonymous Coward | more than 9 years ago | (#13081922)

amirite?

Re:Linux is still a secure OS tho, (1)

Stevyn (691306) | more than 9 years ago | (#13081935)

Since it's a brute force attack and not using some bug that's been known but not patched for months, I'd say so. However, this is about SSH, not Linux so it's irrelevant.

Re:Linux is still a secure OS tho, (1)

Name Anonymous (850635) | more than 9 years ago | (#13082001)

True enough. However, another limiting factor in how secure a system is would be the strength of the passwords that the users use.

Youre, right, this has NOTHING to do with Linux. (2, Interesting)

DaedalusHKX (660194) | more than 9 years ago | (#13082185)

This has to do with Linux getting to the mainstream... people are using lame passwords and leaving unnecessary services with weak passwords open to the public. (Hey, if you'd know how many people **I** alone know that use "password" or "god" or "mom" as their root (*nix/bsd) or admin (windows) passwords. (Or, funnier still, the ones who leave it blank for ease of use.)

Do people on slashdot NOT know what a brute force / dictionary / wordlist attack is??? It is an attempt to connect to a service, using a random or scripted password and username generator or a list of commonly used ones (root and administrator on various systems obviously comes to mind.)

Most people use SSH without redirecting it through a trusted tunnelling protocol or connection. There are many ways to secure even the most trivial home network.

A word to the wise... instead of clicking okay and next mindlessly when installing your OS, start making a practice of READING the warnings and learning something... it should keep the brown fat cells from drowning out your otherwise idle brain as you get older. (IANAMS - I am not a med student, but so I've heard)

-DaedalusHKX

FP (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#13081931)

LOL

Wow

YOU FAIL IT (0)

Anonymous Coward | more than 9 years ago | (#13081953)

Idiot

REMEMBER (-1, Troll)

The Clockwork Troll (655321) | more than 9 years ago | (#13081932)

Pick a random number generator that is only easy for YOU to remember.

As always... (5, Informative)

jsight (8987) | more than 9 years ago | (#13081936)

If possible, restrict access by source IP address, limit the user accounts w/ SSH access, and don't allow remote root logins.

Another step to improve security if there are very few users is just to ONLY allow public key authentication. I've never seen such a box compromised remotely.

Re:As always... (5, Insightful)

justMichael (606509) | more than 9 years ago | (#13082041)

limit the user accounts w/ SSH access, and don't allow remote root logins.
I tend to think of this in a slightly different direction.

Use AllowUers and only have acocunts that I want logging in. If some package/whatever creates an account and I don't know, it can't be exploited.

Any login not in that list just gets a Password: promt over and over...

If my sshd_config gets changed I'm probably going to know.

The article states "200 to 300 times per day"...

This is only one box out of 63 for one day:
Authentication Failures:
unknown (xxxx.ip.secureserver.net): 2214 Time(s)

Re:As always... (4, Interesting)

SlightOverdose (689181) | more than 9 years ago | (#13082118)

One of my clients had apache running as root, and an attacker was able to create a new account on the system via a hole in a php script.

The attacker then tried about 50 times to login to the new account via ssh, but wasn't in AllowUsers. Eventually the idiot gave up- most likely a script kiddie who didn't realise the potential of his initial attack.

Moral of the story? AllowUsers is a really good idea :-P

Re:As always... (0)

Anonymous Coward | more than 9 years ago | (#13082134)

AllowUsers is awesome.

For a while now, I have been trying to figure out how to limit ssh access to only specific users on a system, and this is exactly what I needed. I guess I could have RTFM, but that would have been to easy.

Anyway, thanks for your post... very helpful

Re:As always... (1, Insightful)

Anonymous Coward | more than 9 years ago | (#13082045)

I got those aswell a while back when I changed my ssh port, the scripts stopped working.

security thru obscurity -> let the ssh deamon listen to a different port, most* automated scripts will fail.

*not for so far I've seen.

It's not the best security, but it will work fine if you're not a big player. And it will make it a bit harder for the scriptkiddies.

[use this advice it at your own risk]

Re:As always... (3, Insightful)

SlightOverdose (689181) | more than 9 years ago | (#13082163)

If you do this, avoid port 2222. Everyone that changes the sshd port uses it, and pretty quick the script kiddies will catch on and scan that port as well.

Re:As always... (3, Interesting)

ben_white (639603) | more than 9 years ago | (#13082078)

I had my home machine compromised this way. I have only 3 users on my home box, and choose all passwords myself to keep them strong. One night I was working on getting a backup system up and created an account backup with the excellent password "backup." I fully intended to change the password and disable remote logins for this account once I got it working. It was getting late, and I just didn't do it prior to hanging it up for the night. The next morning I had found the password had been changed to that account, and reviewing the bash log was able to trace what the intruder had done (ie root kit attempts, using my machine to run further automated attacks on other ip blocks). These weren't very sophisticated blokes, as their changing the password that was my tipoff that I had been cracked.

I take security seriously, but a momentary lapse of judgement, and my machine was compromised. If the idiots hadn't changed the password I might not have noticed for several days. Just an illustration of how vulnerable the internet is, even if you think you are careful and know what you are doing.

Ben

Re:As always... (3, Informative)

MyDixieWrecked (548719) | more than 9 years ago | (#13082081)

I run a webserver out of my room for a dozen or so of my friends.

I've just started disabling shell access to the users of my system by default. If they want to log in with ssh, they have to explicitly enable it from the web-based front-end.

I tried forcing public-key authentication, but I kept running into trouble when I was away from home and needed to log in from someone else's computer.

I've got some explicit rules in iptables, also, where I've been blocking entire IP blocks (ie- I've got several countries blocked completely). Whenever I notice a string of failed login attempts, I do an ARIN lookup of that IP block. So far, nearly every attack has come from korea, so I 've been blocking off those addresses as they come.

I should probably only allow ssh access to american addresses... I know one should always make time for security, but I just haven't had the time to look into how to do that.

also, I've got root login enabled only because I've got a backup script running that mirrors /home and a couple other directories over to my backup server. But root has a very, very strong password. took me weeks to memorize it.

Re:As always... (3, Informative)

clymere (605769) | more than 9 years ago | (#13082197)

try putting your public keys on a usb thumb drive. Toss putty on there as well, and you've got what you need no matter where you're at ;)

Re:As always... (0)

Anonymous Coward | more than 9 years ago | (#13082126)

Disallowing remote root logins isn't going to help keep people from brute-forcing SSH. It just means they can't brute-force root. Since root usually has the best password, I'm not sure that's really important.

Speaking of which, why is it said not to login as root over SSH? The only plausible reason I've ever heard is that the encryption is stronger after the login is complete, so your root password is safer if you 'su' to root after logging into another account. But nobody worries about any of their other account passwords using the initial encryption, or takes any steps to protect them, so that is a bogus argument to me.

Besides the general model of using root as seldom as possible...I just don't understand why you wouldn't login directly as root.

Re:As always... (2, Informative)

makomk (752139) | more than 9 years ago | (#13082217)

Disallowing remote root logins isn't going to help keep people from brute-forcing SSH. It just means they can't brute-force root. Since root usually has the best password, I'm not sure that's really important.

Perhaps, but root is the obvious target - it's both the most powerful account, and the only one that exists on all systems. With user accounts, there's the problem of guessing a valid account name.

Ass Post! (-1, Troll)

neildiamond (610251) | more than 9 years ago | (#13081940)

Ass Post!

What next? (4, Insightful)

hoka (880785) | more than 9 years ago | (#13081944)

What are we going to see next on Slashdot? A review for the movie "Scr1pt k1dd15"? I was interested when I saw the link and after clicking on it, I was sadly disappointed. This has nothing to do with SSH, and could just as easily be used on Apache logins, FTP, Telnet, IRC, etc. Brute forcing is an old concept and is the whole reason you are supposed to use strong passwords (well that and offline password attacks).

I think the idea is (2, Insightful)

Anonymous Coward | more than 9 years ago | (#13081991)

The simple, old attacks are sometimes the most dangerous because you start to assume there's no problem with them. You forget about them. They become a blind spot. The point of the article is to remind you, linux can be just as insecure as windows if you do stupid things like choose bad passwords.

Re:I think the idea is (1)

Neil Blender (555885) | more than 9 years ago | (#13082074)

The simple, old attacks are sometimes the most dangerous because you start to assume there's no problem with them. You forget about them.

If you forget about them, then you aren't checking your logs. If you aren't checking your logs, well, maybe you shouldn't be admining a box with services such as ssh open to the world.

The idea is old, but the attempt is new (4, Insightful)

jfengel (409917) | more than 9 years ago | (#13082025)

The idea of brute force is extremely old, but the fact that somebody is out there actually doing them is important. The use of strong passwords is no longer just a theoretical "it would be a good idea" policy, but now somebody actually is looking to get through.

Other Slashdot readers are reporting the same effect: a recent rise in brute-force, scripted attacks, possibly by compromised boxes.

Most accounts of all sorts remain secure simply because they're obscure, and it's tempting to be lulled by past successes. We always knew that this was possible, but the fact that somebody is actually doing it is news.

drop packets to port 22 (0)

NynexNinja (379583) | more than 9 years ago | (#13081948)

Do what I do, drop packets to port 22!

Article Text (-1)

Anonymous Coward | more than 9 years ago | (#13081951)

By Adrian St Onge (Sat, 16 Jul 2005 16:15:10 +0100)

Download ZoneAlarm Security Suite, Save $10
Introduction

Also known as dictionary attacks, which uses a list of known passwords, a program will connect to a remote SSH server and attempt to login using common user name/password combinations. Recently there has been surge of these attack attempts noticed by server administrators. This paper will attempt to briefly discuss these attacks, how they work, where they come from and most importantly, possible ways to stop them. This article is targeted towards the novice and intermediate.

When the attacks were first noticed, how they are noticed.

It was around May of 2005 that these attacks were first brought to light on the "intrusions" mailing list at SANS. System administrators were noticing failed SSH login attempts in their log files. Some days up to 200 to 300 attempts per day. I also have noticed these dictionary attacks, even on my puny DSL connected box running FreeBSD 4.11. So it would seem that not only networks connected to high speed connects are at risk.

It is also possible that these attacks have been going on longer then just the past few months, as it was noted on the SANS mailing list that at least one individual has seen attempts using a "guest/guest" login/password combinations about a year before these new ones. It is quite obvious that this is the work of an automated program as the user names used are attempted in alphabetical order. The time-stamps are also a dead give away, with connections only a few seconds apart.

Here is an example from my /var/log/auth.log

Jul 14 02:12:19 rage sshd[47297]: Illegal user admin from 203.197.118.71
Jul 14 02:12:25 rage sshd[47299]: Illegal user test from 203.197.118.71
Jul 14 02:12:30 rage sshd[47301]: Illegal user guest from 203.197.118.71
Jul 14 02:12:37 rage sshd[47303]: Illegal user webmaster from 203.197.118.71
Jul 14 02:12:41 rage sshd[47305]: Illegal user mysql from 203.197.118.71
Jul 14 02:12:45 rage sshd[47307]: Illegal user oracle from 203.197.118.71
Jul 14 02:12:50 rage sshd[47309]: Illegal user library from 203.197.118.71
Jul 14 02:12:54 rage sshd[47311]: Illegal user info from 203.197.118.71
Jul 14 02:12:59 rage sshd[47313]: Illegal user shell from 203.197.118.71
Jul 14 02:13:03 rage sshd[47315]: Illegal user linux from 203.197.118.71
Jul 14 02:13:07 rage sshd[47317]: Illegal user unix from 203.197.118.71
Jul 14 02:13:12 rage sshd[47319]: Illegal user webadmin from 203.197.118.71
Jul 14 02:13:16 rage sshd[47321]: Illegal user ftp from 203.197.118.71
Jul 14 02:13:23 rage sshd[47323]: Illegal user test from 203.197.118.71

As you can see in the above example, login attempts were only a few seconds apart indicating the use of a script. It is also obvious that they are using well known account names which could quite possibly could be used in a corporate environment where they might have setup the web development team with the user name "webadmin". It was also speculated on the SANS mailing list that password lists were circulating around with 3,400 to 22,000 passwords listed. It is very easy to come across these types of lists on the web, more reason for administrators to practice safe password use.

A dangerous addition to these attacks is the attempts to break into "root" accounts. I will discuss later on how you can prevent the root account being compromised over SSH, but it is worth noting that, even though you can disable the root account, the attackers still try. More proof that we're dealing with an automated "script kiddie" type of program.

Here is another example from /var/log/auth.log:

Jul 14 02:13:51 rage sshd[47335]: Failed password for root from 203.197.118.71 port 33396 ssh2
Jul 14 02:13:55 rage sshd[47337]: Failed password for root from 203.197.118.71 port 33443 ssh2
Jul 14 02:13:59 rage sshd[47339]: Failed password for root from 203.197.118.71 port 33490 ssh2
Jul 14 02:14:06 rage sshd[47341]: Failed password for root from 203.197.118.71 port 33541 ssh2
Jul 14 02:14:11 rage sshd[47343]: Failed password for root from 203.197.118.71 port 33632 ssh2
Jul 14 02:14:16 rage sshd[47345]: Failed password for root from 203.197.118.71 port 33686 ssh2
Jul 14 02:14:22 rage sshd[47347]: Failed password for root from 203.197.118.71 port 33739 ssh2

Another thing to notice is the "Failed password" column, in the previous example it was reported as "Illegal user". The difference being that for "Failed password", your system actually has that user account to be compromised. If that particular user had a weak password, it wouldn't take long for a dictionary attack to find it. The indication that the user name actually exists or not isn't shown to the attacker.

How to know if you're being attacked and possible locations of the attackers
Finding where these attacker are coming from might be a daunting task, getting the IP address of the connecting computers is easy, but if that is where the attacker actually is might be a different story. Recently I started running p0f on my system. This gave me an indication on what types of systems, how many hops, and the connection type of the attackers. Since p0f is passive the attackers had no knowledge they were being monitored.

Sample output from p0f:

219.232.36.194:54618 - Linux 2.5 (sometimes 2.4) (4) (up: 471 hrs)
-> X.X.X.X:22 (distance 17, link: ethernet/modem)
66.212.215.48:34609 - Linux 2.4/2.6 X.X.X.X:22 (distance 21, link: ethernet/modem)
66.212.215.48:34609 - Linux 2.4/2.6 X.X.X.X:22 (distance 21, link: ethernet/modem)
66.212.215.48:59905 - Linux 2.4/2.6 X.X.X.X:22 (distance 21, link: ethernet/modem)

As with this sample, the rest of my logs show that its mostly Linux based systems that are compromised. P0f works perfect in this situation since you know that the attackers are going to connect, it just sits and waits. It also gives us one very important piece of information, the IP address of the attacker.

With the address of the attacker it is possible to find out who owns it and to report the abuse. It was a part of a few discussions on the SANS mailing list that it is the right of administrators to report these abuses.

With ARIN which most administrators known about, you can look up the information on a single IP address. It reports back with information on the owner including (most times) contact information to report abuse. For example I did a look up on "67.110.118.138" which, ARIN gladly tells us, is registered to XO Communications in Reston, VA USA. We can see that they own the "67.104.0.0" to "67.111.255.255" network block. The most important thing that they provide is an email address and a phone number for reporting abuse.

If you are working in a corporate environment, and you are experiencing unknown attackers attempting to break into your system, it should be your duty to report these attacks to their respective net block owners, if enough people reported them, eventually they would stop.

Solutions

Although this type of attack isn't aggressive, it is one of those attacks that, if you don't have strong passwords or change them frequently, will eventually work. Password security is a must, but it is up to the administrators to enforce it.

There is of course a few things you can do, the most important being disabling root logins over SSH. Adding "PermitRootLogin no" to your sshd_config file will disable the root account from being logged into remotely. If you need to be able to work as root on the same system, the best solution is log into a normal user account and then from there to use "sudo" or even "su - root".

As well as logging from traffic capture programs such as p0f, your system also logs automatically. Under FreeBSD, and most likely Linux, SSH logs invalid and failed logins to "/var/log/auth.log" or "/var/log/messages". Watching this file closely allows the administrator to actually see which user names are being tried by the attackers. If you happen to see a known user name, you know its time to do an audit.

Another interesting program you can use is called Tattle, which was created by C.J. Steele from discussions on the SANS mailing list. Tattle is a perl script that looks through your log files and automatically notifies domain authorities of systems performing SSH dictionary attacks. This is exceptionally handy if you administer a few different systems that offer SSH.
Marcus J. Ranum also has an interesting tool called "Never Before Seen" that is a "Anomaly detection driver". It could easily be used to watch log files and report on SSH attempts that are usually not suppose to be connecting.

As a last step measure you could always reconfigure the port that the SSH daemon listens on. By changing the "Port" setting in your "sshd_config" file, you can easily fool the attackers into thinking you're not running SSH at all, but it's no guarantee that they won't find you again by doing a simple port scan. Changing the port is definitely no solution to strong passwords.

Conclusion

It would seem that these dictionary style attacks are by no means new, but they do offer a slight annoyance with the potential to cause harm. They have become common place as seeing Code Red worm attempts in your web server logs. Your best weapon against these attacks is to monitor, be diligent in your reporting to the proper authorities and always enforce a strong password policy.

Refrences

SANS Mailing Lists- http://lists.sans.org/ [sans.org]
ARIN - http://www.arin.net/ [arin.net]
Tattle - http://sodaphish.com/files/tattle [sodaphish.com]
Never Before Seen - http://www.ranum.com/security/computer_security/co de/ [ranum.com]
p0f - http://lcamtuf.coredump.cx/p0f.shtml [coredump.cx]

brute force... (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#13081956)

what would happen if I told you I could brute force SSH by farted?

I give it five minutes... (1)

LandownEyes (838725) | more than 9 years ago | (#13081957)

till the first Spaceballs "password" reference.

Re:I give it five minutes... (1)

Neoprofin (871029) | more than 9 years ago | (#13082014)

"I hate yogurt, even with strawberries!" Close enough?

Highly annoying (3, Interesting)

oGMo (379) | more than 9 years ago | (#13081958)

I have seen tons of these for 12+ months. Highly annoying. Last week I had one with over 10k connection attempts. What I need is an IDS that will just drop the remote IPs into iptables. Anyone have something like that? Of course if anyone is actually interested in reports on all the IPs, most of which usually are in .cn, I've got back logs for quite awhile. ;-P

Re:Highly annoying (1)

sl4shd0rk (755837) | more than 9 years ago | (#13082011)

Honeypot the login box with Portsentry. Run ssh on a non-standard port.

Re:Highly annoying (4, Interesting)

cdrguru (88047) | more than 9 years ago | (#13082034)

We use a script called sshd_sentry. It is set up so that after five failed attempts the IP address is blocked for 24 hours.

This has essentially ended the problem for us. It allows SSH to be wide open so out-of-the-office employees can log in from a hotel or Treo in case something bad happens and it absolutely blocks dictionary attacks.

No longer a problem.

Re:Highly annoying (2, Informative)

IDreamInCode (672260) | more than 9 years ago | (#13082037)

bfd is a good program to run with APF.

http://www.rfxnetworks.com/bfd.php [rfxnetworks.com]

it looks through your /var/log/secure file and automatically adds attackers to your /etc/apf/deny_hosts.rules file.

It works really well for me. Catches a lot of attackers.

Re:Highly annoying (1)

SlightOverdose (689181) | more than 9 years ago | (#13082149)

I had a script like this that was a little overzealous and blocked all network access to my /8 range... which just happened to be most of Australia.

Re:Highly annoying (2)

red_dragon (1761) | more than 9 years ago | (#13082055)

You might want to consider DShield [dshield.org] -- it works very nicely once scripts are set up to download fresh lists and upload filtered logs for redistribution. Plus, it's free.

Re:Highly annoying (2)

the eric conspiracy (20178) | more than 9 years ago | (#13082060)

Well, I wrote a simple perl script that scans log files and then drops the IPs into IP tables.

Run it every three minutes or so and they won't get but a few shots in.

I tried posting it here but slashdot's lameness filter won't let it through.

Re:Highly annoying (1)

kooshvt (86122) | more than 9 years ago | (#13082188)

I just recently started running Denyhosts [sourceforge.net] . It is a nice little script. Every 10 minutes is scans my log files for denied ssh attempts. If there are more than 5 failed attempts from a single ip address then that ip is added to /etc/hosts.deny. It at least limits thier attack to 10 minutes instead of hours as I had seen in my logs before.

Re:Highly annoying (1)

Juergen Kreileder (123582) | more than 9 years ago | (#13082212)

I'm using netfilter's ipt_recent module to block IPs that flood the ssh port temporarily. Here's [blackdown.de] the configuration I use for shorewall.

some of mine - 1061 today (1)

DrSkwid (118965) | more than 9 years ago | (#13081960)

just 2 ips

218.188.8.186
218.27.88.170

Jul 15 01:00:01 www sshd[46625]: Illegal user amza from 218.27.88.170
Jul 15 01:00:06 www sshd[46666]: Illegal user ana from 218.27.88.170
Jul 15 01:00:10 www sshd[46671]: Illegal user anna from 218.27.88.170
Jul 15 01:00:15 www sshd[46675]: Illegal user anemarie from 218.27.88.170
Jul 15 01:00:19 www sshd[46677]: Illegal user anamaria from 218.27.88.170
Jul 15 01:00:25 www sshd[46679]: Illegal user analusia from 218.27.88.170
Jul 15 01:00:30 www sshd[46684]: Illegal user analuisa from 218.27.88.170
Jul 15 01:00:34 www sshd[46696]: Illegal user anabel from 218.27.88.170
Jul 15 01:00:39 www sshd[46701]: Illegal user analia from 218.27.88.170
Jul 15 01:00:43 www sshd[46704]: Illegal user anan from 218.27.88.170
Jul 15 01:00:47 www sshd[46708]: Illegal user anaya from 218.27.88.170
Jul 15 01:00:52 www sshd[46711]: Illegal user anda from 218.27.88.170
Jul 15 01:00:56 www sshd[46715]: Illegal user ande from 218.27.88.170
Jul 15 01:01:00 www sshd[46718]: Illegal user adonis from 218.27.88.170
Jul 15 01:01:04 www sshd[46730]: Illegal user anders from 218.27.88.170
Jul 15 01:01:09 www sshd[46732]: Illegal user andersen from 218.27.88.170
Jul 15 01:01:12 www sshd[46734]: Illegal user anderson from 218.27.88.170
Jul 15 01:01:16 www sshd[46737]: Illegal user andi from 218.27.88.170
Jul 15 01:01:20 www sshd[46739]: Illegal user andy from 218.27.88.170
Jul 15 01:01:24 www sshd[46741]: Illegal user andley from 218.27.88.170
Jul 15 01:01:28 www sshd[46743]: Illegal user andonia from 218.27.88.170
Jul 15 01:01:32 www sshd[46746]: Illegal user andra from 218.27.88.170
Jul 15 01:01:36 www sshd[46750]: Illegal user andre from 218.27.88.170
Jul 15 01:01:41 www sshd[46754]: Illegal user andras from 218.27.88.170
Jul 15 01:01:45 www sshd[46756]: Illegal user andrea from 218.27.88.170
Jul 15 01:01:50 www sshd[46760]: Illegal user andreas from 218.27.88.170
Jul 15 01:01:54 www sshd[46762]: Illegal user andreassi from 218.27.88.170
Jul 15 01:02:00 www sshd[46764]: Illegal user andree from 218.27.88.170
Jul 15 01:02:06 www sshd[46766]: Illegal user andrei from 218.27.88.170
Jul 15 01:02:12 www sshd[46768]: Illegal user andreia from 218.27.88.170
Jul 15 01:02:16 www sshd[46773]: Illegal user andreina from 218.27.88.170
Jul 15 01:02:20 www sshd[46776]: Illegal user andrew from 218.27.88.170

That's port 22 (1)

AndroidCat (229562) | more than 9 years ago | (#13082065)

For those that want to check their own logs. I just get a sprinkling of those, maybe an average of one or two a day.

Re:some of mine - 1061 today (1)

ForumTroll (900233) | more than 9 years ago | (#13082069)

I get these entries all the time in my logs as well. Futile attempts from a script to generate random login names and passwords. The problem is that you can't really do much about it because they are often in countries that have different laws and blocking by IP/subnet just doesn't work because they have no shortage of IPs/subnets. Best suggestion is just to use strong passwords and a good encryption algorithm.

Re:some of mine - 1061 today (0)

Anonymous Coward | more than 9 years ago | (#13082106)

Yeah, I got a bunch from 206.49.38.26.

By the way, your signature sucks.

Easy fix (4, Informative)

Anonymous Coward | more than 9 years ago | (#13081963)

i have had this on a number of occasions.. i just set the max auth attepts to 4, this renders the attempts useless

Re:Easy fix (1)

RLiegh (247921) | more than 9 years ago | (#13081998)

Where do you set this at, and on what OS?

Re:Easy fix (-1, Troll)

Anonymous Coward | more than 9 years ago | (#13082075)

SSH settings of course, whatever the fucking OS.

You are so stupid.

Re:Easy fix (1)

RLiegh (247921) | more than 9 years ago | (#13082129)

If you don't know, say so; don't blame me for it.

Re:Easy fix (2, Interesting)

brsmith4 (567390) | more than 9 years ago | (#13082063)

To bad you posted AC... this is very informative to newer users that are unaware of /etc/ssh/sshd_config.

Re:Easy fix (5, Informative)

tek.net-ium (841449) | more than 9 years ago | (#13082177)

RTFM. sshd_config(5) MaxAuthTries Specifies the maximum number of authentication attempts permitted per connection. Once the number of failures reaches half this value, additional failures are logged. The default is 6. Crackers will just open up more connections.

Isn't the point of SSH... (0)

Anonymous Coward | more than 9 years ago | (#13081964)

...to have a frontdoor made of 1 mile thick steel instead of a cardboard, so that we DON'T have contact autorities each time some bum goes through it?

DenyHosts (5, Informative)

roubles (716740) | more than 9 years ago | (#13081972)

I use DenyHosts http://denyhosts.sourceforge.net/ [sourceforge.net] from a cronjob. It detects any suspicious logins in /var/log/auth.log and adds the ip address of the user into the /etc/hosts.deny file. It also sends me an email telling me the IP address that was last added to the file.

Lately I have been getting atleast 1 hack attempt a day on my personal computer connected to the internet over a cable connection. On weekends I get more.

Just this morning I had two ssh dictionary attacks. DenyHosts caught them both.

Re:DenyHosts (1, Interesting)

Anonymous Coward | more than 9 years ago | (#13082094)

Does a login attempt really take so much CPU time that these attacks affect performance? If not, it might be simpler to use a strong password, never look at /var/log/auth.log, and carry on with business. If yes, it might be simpler to optimize the ssh login code to make it faster.

Re:DenyHosts (1)

markild (862998) | more than 9 years ago | (#13082112)

Thanks for the tip. I was kinda looking for this. Not actually looking though, but it was some place back in my head.

At a glance it looks like just the program one would need if you're experiencing malicious ssh-logins.

This is useless for people running a web-service that is supposed to accept connections for pretty much anyone though (seeing that it blocks IP's).

Re:DenyHosts (1)

XanC (644172) | more than 9 years ago | (#13082162)

You have the option of blocking IPs only for SSH or for everything. Pretty nice.

However, I'm trying to run it on Debian Woody and I'm getting this:

# ./denyhosts.py
Traceback (most recent call last):
File "./denyhosts.py", line 102, in ?
class Counter(dict):
NameError: name 'dict' is not defined

So maybe it's not so great. :-)

Re:DenyHosts (1)

markild (862998) | more than 9 years ago | (#13082213)

Yeah.. You're right. I'm wrong :D The only-ssh options is real neat. Just got it installed and up'n running. Works like a charm!

You sure you got the latest python installed?

I get these almost continually... (1)

Kevin Burtch (13372) | more than 9 years ago | (#13081973)


If they bother you, you could always use portsentry or something similar to block the IP once a certain number are received.

Re:I get these almost continually... (2, Funny)

AndroidCat (229562) | more than 9 years ago | (#13082132)

That's probably the IP of one their previous victims. If you wanted to have fun, rename the role account they're trying for, create a "root" with almost no access and uses Zork (dungeon) as its shell. (Probably best to try this on the junk spare Pentium box, just in case.)

Guy Says Recent Attacks?? (1)

putko (753330) | more than 9 years ago | (#13081981)

I don't think these are at all "recent".

Haven't these ssh-based attacks been going on since sometime like July of 2004?

The deal was that there was a SSH vulnerability in non-OpenBSD implementations of sshd. The automated stuff kicked off then -- and they've gotten a bit worse in the last few months.

Re:Guy Says Recent Attacks?? (1)

SloWave (52801) | more than 9 years ago | (#13082194)

I've been seeing them for over 2 years now. Same type of attack but the list of login names change so they must ne trying different dictionaries. In my /etc/ssh/sshd_config file I've set the following parameters to hopefully gum them up somewhat...

Protocol 2
LoginGraceTime 12
PermitRootLogin no
MaxAuthTries 2

Non-default Port (2, Informative)

fire-eyes (522894) | more than 9 years ago | (#13081982)

Use a non-default port on any service whenever possible. This simple change goes a long way. Obviously it is not all you should do.

Re:Non-default Port (2, Informative)

ak8b (798032) | more than 9 years ago | (#13082077)

I second this one. I went from several a day to zero since I changed the incoming port. I have my router (a DI-604) do the port change/forward so that I didn't have to change anything on the Linux box or deal with it within my internal network.

I've seen many SSH break in attempts myself. (1)

Name Anonymous (850635) | more than 9 years ago | (#13081985)

I've seen many attempts to log in to my system via SSH. Oddly enough, since I never enabled SSH2, a lot of the attacks fail due to incompatible SSH versions.

Some of the IPs I'm seeing trying to log in (break in) are:
211.98.192.91
66.194.210.4
210.188.243.208
200.198.184.135
222.122.25.100
211.87.224.192
62.231.44.113
212.202.220.163
62.75.216.10
81. 172.160.19
82.127.73.97
82.76.47.40
206.170.12. 98
61.133.218.110
216.70.203.62
66.220.1.112
1 2.167.162.5
80.190.243.50
62.75.216.10
221.249. 246.34
152.92.7.212
210.118.193.95
82.76.47.40
61.135.134.238

Re:I've seen many SSH break in attempts myself. (0)

Anonymous Coward | more than 9 years ago | (#13082196)

Oddly enough, since I never enabled SSH2

umm, i think most people don't use SSH1 for a reason.

Attacks are a sad reminder on stupidity (2, Informative)

m.dillon (147925) | more than 9 years ago | (#13081987)

I get 40 of these a day across half a dozen machines. They only try a small combination of trivial passwords for accounts like 'root' and 'test' and 'admin', and occassionally user names using the same user name as the password, etc. Really quite sad considering that most Linux and BSD installs disable passworded-root logins via ssh by default. My guess is that they are going after Windoz boxes which for some unfathomable reason still allow people to do stupid things with passwords.

I got annoyed enough that I wrote a little script to pull the data out of my logs in real time and add an entry to my firewall, but the attacks are harmless to any sysadmin with a clue.

-Matt

Use another port (5, Informative)

objorkum (695401) | more than 9 years ago | (#13081994)

Use another port than 22. I have not noticed one single bruteforce attempt after I did that.

Won't work (0, Flamebait)

Anonymous Coward | more than 9 years ago | (#13082068)

Too much trouble. If you want someone to log in, you'll have to tell him to use the non-standard port.

Easy to fix (1)

jswoboda (900309) | more than 9 years ago | (#13081996)

I had a lot of these attempts. I just set max autorization atempts to 4... renders these attacks useless.

Brute force isn't new (1)

Zweideutig (900045) | more than 9 years ago | (#13081997)

If setup a delay between the time of the password is accepted from the ssh client, and the time when you indicate a successful login with a shell prompt (or a failure message,) you would slow down a brute force attack. You should delay even delay for a successful login, because if the brute force program doesn't see a shell within a second, it could simply assume it failed and try another. Also, you should be behind a router (OpenBSD and an old PC is what I use.) If you don't need sshd available from outside your LAN, simply don't forward the port. You may consider keeping your LAN on RJ45 (not wifi) to reduce the risk of malicous login attempts. Make sure your wireless access point is locked down as much as possible if you must have it. Blacklisting an IP after say, 7 unsuccessful logins and logging the incident is a good idea (and perhaps have the sysadmin notified of the event.) Some ways to alleviate the risk.

Funny... (1)

ninja_assault_kitten (883141) | more than 9 years ago | (#13081999)

I was just reviewing one of these today from Miami University (Ohio).

Jul 15 04:55:51 combust sshd[12125]: Did not receive identification string from 134.53.130.197
Jul 15 04:59:57 combust sshd[14758]: Invalid user president from 134.53.130.197
Jul 15 04:59:57 combust sshd[1219]: input_userauth_request: invalid user president
Jul 15 04:59:57 combust sshd[1219]: Failed password for invalid user president from 134.53.130.197 port 57698 ssh2
Jul 15 04:59:57 combust sshd[14758]: Failed password for invalid user president from 134.53.130.197 port 57698 ssh2
Jul 15 04:59:57 combust sshd[1219]: Received disconnect from 134.53.130.197: 11: Bye Bye
Jul 15 04:59:58 combust sshd[29612]: Invalid user bob from 134.53.130.197
Jul 15 04:59:58 combust sshd[7875]: input_userauth_request: invalid user bob
Jul 15 04:59:58 combust sshd[29612]: Failed password for invalid user bob from 134.53.130.197 port 57789 ssh2
Jul 15 04:59:58 combust sshd[7875]: Failed password for invalid user bob from 134.53.130.197 port 57789 ssh2
Jul 15 04:59:59 combust sshd[7875]: Received disconnect from 134.53.130.197: 11: Bye Bye
Jul 15 05:00:00 combust sshd[22372]: Invalid user sunshine from 134.53.130.197
Jul 15 05:00:00 combust sshd[6311]: input_userauth_request: invalid user sunshine
Jul 15 05:00:00 combust sshd[22372]: Failed password for invalid user sunshine from 134.53.130.197 port 57864 ssh2
Jul 15 05:00:00 combust sshd[6311]: Failed password for invalid user sunshine from 134.53.130.197 port 57864 ssh2
Jul 15 05:00:00 combust sshd[6311]: Received disconnect from 134.53.130.197: 11: Bye Bye ...
Jul 15 05:11:57 combust sshd[1820]: input_userauth_request: invalid user gus
Jul 15 05:11:57 combust sshd[1820]: Failed password for invalid user gus from 134.53.130.197 port 39530 ssh2
Jul 15 05:11:57 combust sshd[23478]: Failed password for invalid user gus from 134.53.130.197 port 39530 ssh2
Jul 15 05:11:57 combust sshd[1820]: Received disconnect from 134.53.130.197: 11: Bye Bye
Jul 15 05:11:58 combust sshd[14363]: Invalid user adminweb from 134.53.130.197
Jul 15 05:11:58 combust sshd[3817]: input_userauth_request: invalid user adminweb
Jul 15 05:11:58 combust sshd[3817]: Failed password for invalid user adminweb from 134.53.130.197 port 39568 ssh2
Jul 15 05:11:58 combust sshd[14363]: Failed password for invalid user adminweb from 134.53.130.197 port 39568 ssh2
Jul 15 05:11:58 combust sshd[3817]: Received disconnect from 134.53.130.197: 11: Bye Bye

A router? (1)

Zweideutig (900045) | more than 9 years ago | (#13082048)

Do you have your machine directly on your broadband connection, or do you have port 22 forwarded to the router? I don't have port 22 forwarded, and I have never seen this. Sorry if this is too obvious. Do you need to login remotely from work or something? Maybe you could only allow a certain IP?

Re:A router? (1)

ninja_assault_kitten (883141) | more than 9 years ago | (#13082082)

Yeah, I have an inbound port NAT on my home DSL for SSH. I'm not too concerned about it. I just thought it was interesting as I had just enabled it a short time before the first bruteforce attempt. At the time, I wasn't aware SSH bruteforce attacks were so prevalent.

If your paraniod disable password auth. (0)

Anonymous Coward | more than 9 years ago | (#13082003)

password authentication for OpenSSH.

OpenSSH supports several forms of authentication and generally password-only authentication is the weakest it can support.

A much more secure versions is public/private keypair combined with a passphrase that is not related to your normal unix password.

That way if they get a hold of your keys they still have to brute force your passphrase, and if they don't have your private keys then they can't get in even if they do know the password.

Also disable root ssh access and disable any 'sudo' you have setup. That way if a hacker guesses a password he still has to find a local rights elevation exploit (which isn't terrificly difficult in Linux unless you keep things very up to date)

The other form of secure authentication is kerberos, but that is a pain to setup.

How to limit this (newbie sysadmin question)? (1)

Poor College Student (657160) | more than 9 years ago | (#13082020)

-- Newbie sysadmin question --

I've noticed these scripts on my logs before attempting to access my machine (its a moot point now given my network setup, but...), how would you limit from occurring?

I'd like to do the following: If two failed connections with nonexistant usernames are used or three with a known user name, block the connectors IP subnet for a certain time (with the exception of a couple known good subnets).

The blocking would be the easy part, since some script could control iptables (or pf on a bsd machine). But outside of doing creative monitoring with with auth.log, is there another way to detect failed logins?

surprising, just May 2005 (2, Insightful)

whovian (107062) | more than 9 years ago | (#13082035)

I've been seeing these attacks for QUITE a while now. Repeated access attempts which were guesses of people's first names as logins. I used to ban the entire source subnet, but it's futile. Now I just whitelist acceptable IPs.

BlockHosts (1)

smartin (942) | more than 9 years ago | (#13082036)

I installed this [aczoom.com] on my server, seems to work well. Basically it keeps track of ssh attempts and after a preconfigure number of failures within a certain period of time, it bans the hosts. Hooks into tcpwrappers using hosts.allow.

Recent? (0)

Anonymous Coward | more than 9 years ago | (#13082039)

Slashdot must be really hurting for a story. I've been noticing these since the first time I put up a linux box on my home cable line. It's not a new phenomenon, and thank you very much, I know how to report an IP address for abuse.

What is this, Security for Dummies?

Automation (1)

mfloy (899187) | more than 9 years ago | (#13082042)

It shows what an automated land we live in when even the hackers are automating their attacks. The problem with this is that every compromised machine will in turn compromise more, making it very hard to stop.

No root login? (0)

Anonymous Coward | more than 9 years ago | (#13082054)

"There is of course a few things you can do, the most important being disabling root logins over SSH. [...] If you need to be able to work as root on the same system, the best solution is log into a normal user account and then from there to use 'sudo' or even 'su - root'."

I've never understood this advice. If the crackers get hold of an admin account, all they need to do is upload a trojan 'sudo' or 'su' program and wait. I've done so myself on one system (making sure I tick the 'anonymous' box). Blocking root logins doesn't increase security, it just annoys root.

Counter agruments?

Re:No root login? (1)

ledow (319597) | more than 9 years ago | (#13082193)

"If the crackers get hold of an admin account," then you're stuffed anyway.

I can see your argument and tried to think of a few counter-arguments.

If someone can only get to root by coming in as a normal user and su-ing, then we should know which account they came from and hold that user responsible.

Not all SSH accounts are necessarily for admin users anyway (compile farms, cgi hosting, VPN's etc.), so blocking root on those connections doesn't hinder anyone and the users will not be able to get to root anyway, so why not block root logins?

Blocking a unnecessary login is one less login to attack? Especially if it is one that has power that is unnecessary, e.g. compile farms using SSH. Why *should* there be any facility to log in as root remotely?

If someone should find an exploit in SSH that executes with the privileges of the logged in user?

In the same way that you should never log in as root at the terminal anyway, just to make sure you think twice before you actually perform that rm command?

why not disable passwords entirely? (4, Informative)

toby (759) | more than 9 years ago | (#13082058)

If you only need access from a limited set of machines which can have pre-generated keys, you can disable password authentication entirely (PasswordAuthentication no) and use RSA instead, with optional passphrase. In addition to PermitRootLogin no, I suggest judicious use of AllowUsers in sshd_config.

Re:why not disable passwords entirely? (2, Informative)

ngunton (460215) | more than 9 years ago | (#13082221)

Careful if you're doing this on a remote host that you don't have easy console access to (e.g. co-located or rented from a hosting company). If you happen to delete or otherwise lose the key on your local computer (or if you need to login from another computer for some reason) then you'll be unable to.

Reporting is useless (1)

cdrguru (88047) | more than 9 years ago | (#13082062)

Nobody cares. I've tried that approach and it is a waste of my time and the person's on the other end.

We use sshd_sentry which puts the IP address into the hosts.deny list for 24 hours after five failed attempts. This eliminates the problem completely and it doesn't fill up our logs with useless trash.

I am thinking of doing the same thing for relay attempts because that seems to have become the new sport. One reject you would think would be quite sufficient, but no, we're getting a hundred or more requests from the same IP address.

add AllowUsers to /etc/ssh/sshd_config (3, Insightful)

dd (15470) | more than 9 years ago | (#13082066)

A good thing to do is to use the AllowUsers configuration directive for sshd in /etc/ssh/sshd_config. The following would allow some account named 'unprivguy' authenticated ssh access from anywhere. All other ssh connections must come from local and local domain authenticated users. So root@localhost or root@*.mydomain.com could log in. All others are blocked, even if they have the password.

AllowUsers unprivguy *@*.mydomain.com *@localhost

You still see the attempts in your logs, but now you also see:

User root not allowed because not listed in AllowUsers

Brute force attacks (1)

Jarlsberg (643324) | more than 9 years ago | (#13082070)

Brute force attacks are the predominant form of attack on my web server, which are host to several large web shops in Scandinavia. Just this weekend, I've gotten tons of requests from 80.18.87.243 and 200.163.190.132. Most attacks come from Italy, South-America, Korea and China... We don't have a root login, and the user logins are restricted, so the login attempts are annoying more than anything else.

Dynamically blocking with iptables (3, Informative)

meisenst (104896) | more than 9 years ago | (#13082088)

I tried to post this in the talkback on the article but it got horribly munged.

Here are the iptables rules I use to dynamically stop this kind of thing (with a good degree of success):

# SSH
-A PREROUTING -m tcp -p tcp -d $EXTERNAL --dport 22 -m recent --rcheck --hitcount 3 --seconds 600 -j LOG --log-prefix "SSH attack: "
-A PREROUTING -m tcp -p tcp -d $EXTERNAL --dport 22 -m recent --rcheck --hitcount 3 --seconds 600 -j DROP
-A PREROUTING -m tcp -p tcp -d $EXTERNAL --dport 22 -m recent --set -j DNAT --to-destination $INTERNAL:22
-A OUTPUT -m tcp -p tcp -d $EXTERNAL --dport 22 -j DNAT --to-destination $INTERNAL:22

Your mileage may vary. This blocks attempts for 1 minute after 3 attempts (successful or failed, so if someone forgets their password, they may trip it as well).

Re:Dynamically blocking with iptables (1)

meisenst (104896) | more than 9 years ago | (#13082102)

And by 1 minute, I meant 10 minutes... no edit button. Sorry.

Port Knocking + FireHOL (1)

kuom (253900) | more than 9 years ago | (#13082089)

Personally, I find port knocking [portknocking.org] useful in providing an extra layer of security.

Some of the systems that I am responsible for, have restrictions on when and how I can apply patches. So if a vulnerability is discovered, if I cannot patch it right away, I am relying on my FireHOL [sourceforge.net] and port knocker to protect these systems. Since implementing these measures (and good security policy), none of these machines have been compromised in three years.

Of course, saying that, I probably just jinxed it...

Re:Port Knocking + FireHOL (1)

michaelrash (715609) | more than 9 years ago | (#13082176)

Try fwknop. The single-packet strategy it implements provides many advantages beyond port knocking: http://www.cipherdyne.org/fwknop/ [cipherdyne.org]

Like the prior /. story said, Korea is anarchy (1)

merc (115854) | more than 9 years ago | (#13082092)

Most of the attacks I see originate from Korea. Its gotten so bad that we are finally blocking around 3 class A (CIDR/8) networks from our border routers that belong to KRNIC/KORNET/HANANET.

I hope they enjoy their intranet.

Mmm... (1)

ledow (319597) | more than 9 years ago | (#13082120)

I've been seeing these sorts of "attacks" in number since I installed my Linux Desktop machine about 6 months ago. I'm only on plain ADSL that isn't published, not like I'm a likely target.

Every day I get two or three new attackers, most of whom try 50-60 times on common account names (fred, jeff, user, test etc.) and about one a week that goes full-bore for a particular username or a large spread of a few thousand attempts.

I took the appropriate measures... disallowed root login, use public-key authentication only and I also have a script that checks through my logs once every five minutes, permanantly blacklisting anyone who has more than five attempts within a 7-day period (except for known whitelist addresses).

Currently, it runs to 390 unique lines of IP's, some of which have come via

http://www.cyber-defense.org/blacklist.txt [cyber-defense.org]

and at least 50% from my own blacklist. That site (http://www.cyber-defense.org/ [cyber-defense.org] incidentally, also notices the same phenemona.

They actually got in on my parent's computer (4, Interesting)

yorgasor (109984) | more than 9 years ago | (#13082135)

I made an account for my dad on my mom's computer so he could have a samba share over the network, and gave it a really easy, completely forgetting that it was also accessible via ssh. Fortunately, I added their computer to my personal DNS domain so I could remember how to get to it easier. Shortly after it was compromised, I got an email informing me that phish spams were being sent from the computer.

I analyzed the system, and quickly determined that the person was not a big time hacker. Looking at his .bash_history file His only attempt to gain root access was to run 'sudo'. He copied over a list of people to spam, a mail script, and an email. He fired off a test email first, and then spammed the email list. A couple days later, he copied over a different list and message and sent those off. After that, I was tipped off and sealed off his entry.

Since he made no effort to cover his tracks or avoid detection, either this script-kiddie didn't know how to, or had so many computers to manage it wasn't worth his while to do so.

First, I put ssh on another port, then... (3, Interesting)

Dr. Manhattan (29720) | more than 9 years ago | (#13082139)

... I wrote a program that was utterly immune to buffer overflow and other attacks, and use that program to enable SSH for just the IP address I'm coming from. See the .sig for the details.

I sleep just fine now.

These have been going on for a long time (3, Informative)

angst7 (62954) | more than 9 years ago | (#13082142)

I've been logging and reporting these attacks since last October (when I first started using BFD). I'm figuring they've been going on for a long long time. A simple install of APF and BFD will keep you from having too much trouble though. That and making sure noone is using easy to guess passwords.

APF and BFD can be got here: RFX Networks [rfxnetworks.com] .

20th Century Authority (5, Insightful)

handy_vandal (606174) | more than 9 years ago | (#13082147)

The article goes into depth on how to monitor these attackes and to report them to the authorities.

The authorities ... how very ... twentieth-century.

Better we should self-organize our collective defense.

Peer-to-peer government -- making the nation-state obsolete, one node at a time ....

-kgj

Other Attacking IP's (1)

ToAllPointsWest (801684) | more than 9 years ago | (#13082156)

I've seen these in my logs as well: 168.148.40.58 210.22.153.134 80.55.129.94 195.184.172.1 195.5.57.5

sshdban.sh (1)

Noksagt (69097) | more than 9 years ago | (#13082159)

I have the following script cronned once daily on a FreeBSD box. It bans attempts at logging in with illegal users. My hosts.allow already has the hosts which should never be banned white-listed.

Once a month or so, I check the list of banned IPs & manually report U.S. ones to the relevant abuse@ email addresses (figuring that they can de-zombify the boxes.
#!/bin/sh
cd /usr/local/sbin
#remove old file entries
rm ./sshd_block/block.txt
rm ./sshd_block/new_block.txt
#This will parse the messages file and extract the sshd lines
grep sshd /var/log/all.log* | grep 'Illegal user' >> ./sshd_block/block.txt
grep sshd /var/log/auth.log* | grep 'Illegal user' >> ./sshd_block/block.txt
#This line will cut only the IP addresses out of that file
cut -d \ -f 10 ./sshd_block/block.txt | uniq >> ./sshd_block/new_block.txt
#This line will add The references from new_block.txt to the ssh.blacklist
target=`cat /usr/local/sbin/sshd_block/new_block.txt`
for i in $target; do
echo \ \ ALL:$i:deny >> /etc/hosts.allow
done
#remove duplicate entries from ssh.blacklist
cat /etc/hosts.allow | sort | uniq > /etc/hosts.allow.new
mv /etc/hosts.allow.new /etc/hosts.allow

Why do people use ssh with passwords? (2, Insightful)

Lord Bitman (95493) | more than 9 years ago | (#13082174)

I just disabled any SSH use without a key. Duh, right?

.authorizedkeys (1)

jgercken (314042) | more than 9 years ago | (#13082179)

The solution is to not expose SSH to the Net without disabling interactive authentication. IMHO anyone not using certificates or IP access-lists is being negligent.
UsePAM no

Recent? (1)

LittleLebowskiUrbanA (619114) | more than 9 years ago | (#13082182)

Have been seeing these on my public Linux boxes for 6 months. Trivial to stop. Just allow only unique user names, enforce good passwords, etc...
Traced one attack from a Windows box in an Ohio school.

easy fix (2, Informative)

gyratedotorg (545872) | more than 9 years ago | (#13082203)

if your ssh server needs to be publicly available, you can always have it listen on a different port. that seems to thwart 100% of these automated attacks.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?