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!

The Low-Intensity, Brute-Force Zombies Are Back

Soulskill posted more than 5 years ago | from the password-123456-letmein dept.

Security 203

Peter N. M. Hansteen writes "In real life, zombies feed off both weak minds and the weak passwords they choose. When the distributed brute-force attempts stopped abruptly after a couple of months of futile pounding on ssh servers, most of us thought they had seen sense and given up. Now, it seems that they have not; they are back. 'This can only mean that there were enough successful attempts at guessing people's weak passwords in the last round that our unknown perpetrators found it worthwhile to start another round. For all I know they may have been at it all along, probing other parts of the Internet ...' The article has some analysis and links to fresh log data."

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

why are passwords even allowed? (5, Informative)

rcpitt (711863) | more than 5 years ago | (#27551219)

None of my systems allow passwords via ssh - and I run log-guardian.pl to "3 strikes - you're out" the idiots who do the brute-forces by putting them into iptables

Anyone with passwords turned on is not secure IMHO

Re:why are passwords even allowed? (3, Informative)

miknix (1047580) | more than 5 years ago | (#27551285)

IMHO if the passwords are strong enough there is nothing to worry about, unless you get pissed off with flooded log files and the waste of bandwidth.

None of my systems allow passwords via ssh

Exactly, using public key authentication and disabling PAM/Password authentication solves the problem.

and I run log-guardian.pl to "3 strikes - you're out" the idiots who do the brute-forces by putting them into iptables

sshguard is nice too, they will be firewalled in no time. (watch out for DoSs though)

However, it is not just ssh. Http and servers also suffer a lot from automated breakin attempts.
Anyway.. I'm glad services running on port 22 are not in the same security level of services in 23,137 and 138. Otherwise it would be the holocaust!!

Re:why are passwords even allowed? (2, Interesting)

Wonko the Sane (25252) | more than 5 years ago | (#27551325)

If you only allow public key authentication then there's really no need to bother blocking them: you'll never block the entire botnet.

Just let them try - they'll never guess the right private key.

Re:why are passwords even allowed? (1)

MichaelSmith (789609) | more than 5 years ago | (#27551343)

The problem is that noise in the logs makes it hard to find real problems. That and the risk of a bug in openssh or openssl, though the current environment is a pretty good test for the software.

If there's a bug on in openssh (1)

Nicolas MONNET (4727) | more than 5 years ago | (#27551447)

... then there's no need to bruteforce it, and therefore blocking a botnet doing that is futile.

Re:If there's a bug on in openssh (1)

palegray.net (1195047) | more than 5 years ago | (#27551563)

I disagree. Should a new bug arise in openssh, I sure feel a lot better knowing that while I do enforce key-only authentication, I also restrict access to specific IP addresses. It's pretty hard to crack a service that you can't reach on the network due to packet filtering.

Re:why are passwords even allowed? (2, Insightful)

BitZtream (692029) | more than 5 years ago | (#27551491)

grep -v for the win!

Re:why are passwords even allowed? (2, Insightful)

palegray.net (1195047) | more than 5 years ago | (#27551589)

tail -f for the bored!

Re:why are passwords even allowed? (2, Insightful)

tagno25 (1518033) | more than 5 years ago | (#27551665)

grep -v |tail -f for the smart and lazy

Re:why are passwords even allowed? (2)

palegray.net (1195047) | more than 5 years ago | (#27551733)

grep -v | tail -f running in a screen session for the smart and lazy who frequently suffer from denial of service attacks from botnets.

Re:why are passwords even allowed? (3, Funny)

The Redster! (874352) | more than 5 years ago | (#27551847)

"aplay -t raw" for the truly over-the-edge!

Re:why are passwords even allowed? (1)

palegray.net (1195047) | more than 5 years ago | (#27552073)

To defeat zombie attacks, I suck live packets out of my router through a modified soda straw running Linux. You can guess where anything routed to /dev/null winds up.

Re:why are passwords even allowed? (2, Informative)

palegray.net (1195047) | more than 5 years ago | (#27551543)

I don't allow password-based logins either (SSH keys only), allow SSH only from specific IP addresses, and I use fail2ban [fail2ban.org] across all services that involve any kind of authentication (mail, ftp, http auth, etc). I've got it set to "two strikes and you're out"; every day I still get hundreds (some days thousands) of IPs banned in the logs. It's pretty sad.

Re:why are passwords even allowed? (2, Interesting)

dbIII (701233) | more than 5 years ago | (#27551777)

From a quick look at fail2ban it looks like one of it's features is that the blocking only lasts until the next log rotation. Considering that attacks are temporary and automatic firewall rule generation could become a script kiddies playpen this is actually a good thing. If they work out you have this and spoof a few adresses as a denial of service attack the system will recover over time without needing someone to go through all the firewall rules.
I'm still a bit nervous about allowing malicious third parties to effectively write firewall rules for me. The ideal is of course to only allow a certain address range in, but some of us don't really know where the next legitimate connection is going to come from.

Re:why are passwords even allowed? (1)

palegray.net (1195047) | more than 5 years ago | (#27552061)

From a quick look at fail2ban it looks like one of it's features is that the blocking only lasts until the next log rotation.

It's configurable, you can select any period of time for the ban to remain in effect.

I'm still a bit nervous about allowing malicious third parties to effectively write firewall rules for me.

That I completely understand. It's not without its potential hazards, but I think the benefits outweigh them.

some of us don't really know where the next legitimate connection is going to come from

I've been thinking about something like a variant on port knocking, wherein a machine would be make several connections attempts to a non-existent service port from source ports whose numbers add up to some magic number. Filtering would then be disabled for the life of that connection. Maybe someone's already done it.

Re:why are passwords even allowed? (1)

Sancho (17056) | more than 5 years ago | (#27552277)

If you just want to keep the logs cleaner and avoid the bot attacks, you can just run your server on another port.

Re:why are passwords even allowed? (1)

maeka (518272) | more than 5 years ago | (#27551581)

I only allow public key connections, and am only listening on port 2022 (I have no issues telling the world that).
My auth.log is completely empty of password attempts. Am I missing something simple-stupid or is the bot net only going after port 22?

Re:why are passwords even allowed? (2, Insightful)

Thantik (1207112) | more than 5 years ago | (#27551617)

I would suspect it's going after port 22 only. If your smart enough to move the port from 22, your probably smart enough to use key pairs and then what is the point of trying to brute force you? Focusing on default 22 is a good strategy because you'll find those who have completely defaulted settings, weak passwords, etc.

Re:why are passwords even allowed? (1)

Ernesto Alvarez (750678) | more than 5 years ago | (#27552311)

Something interesting about your usage of tcp/2022. I did the same thing recently on an occasion when I could not use tcp/22, since it seemed an obvious choice. Probable most automated attacks only concentrate on tcp/22 (the obvious target and if you can move it, you probably know enough to secure it properly), but I've been wondering if someone might start considering scanning on 2022 or any other "obvious" choice.

Right now it seems that nobody is scanning for them, but is anyone else setting ssh servers on tcp/2022 or tcp/2222?

(maybe I should give nmap a try, but I lose nothing by asking I guess)

Re:why are passwords even allowed? (1)

Cheech Wizard (698728) | more than 5 years ago | (#27552613)

I only allow public key connections, and am only listening on port 2022 (I have no issues telling the world that). My auth.log is completely empty of password attempts. Am I missing something simple-stupid or is the bot net only going after port 22?

You're not missing anything. I have used other ports for things like ssh for a long time. I changed after watching one IP try to brute force one of my sites for 8 days straight, 24 hours a day. Since changing ports I *very* rarely see a break-in attempt.

Re:why are passwords even allowed? (1)

Sentry21 (8183) | more than 5 years ago | (#27551667)

Likewise - I use fail2ban with iptables to drop any packets from someone who fails auth about 5 times in a few minutes. I've toyed with the idea of adding them to a global blacklist for all servers in all locations, but in reality this solution works just fine.

fail2ban and firewall won't help with this attack (1, Redundant)

baileydau (1037622) | more than 5 years ago | (#27552003)

Likewise - I use fail2ban with iptables to drop any packets from someone who fails auth about 5 times in a few minutes. I've toyed with the idea of adding them to a global blacklist for all servers in all locations, but in reality this solution works just fine.

If you RTFA, they tell you that these attacks are coming from different machines, presumably so they don't trip such things as fail2ban et al.

Looking at the logs he supplied, this is a _very_ slow attack, the attempts are many seconds, or even minutes apart. You would have to have a very guessable username / password combination for it to work.

I would comment though that I'm not seeing anything like this attack in my logs. I personally use IPTables rules (using hashlimits) to limit 1 connection / IP per minute to my ssh ports. Typically, I see about 3-6 attempts per day (each only gets 1 or 2 tries before they get blocked). Doing an optical integration of my recent logs shows less than a dozen per day and they are not concentrating on any particular username (with the exception of root).

Prior to using hashlimits, I used to get hundreds or even thousands of attempts per day. My record was over 6,000 attempts from a single host. One guy at work has reported over 30,000 attempts in a single day.

I personally don't like the concept of fail2ban as it is permanently adding an IP address to your banned list. As most of these IPs are dynamic, keeping them in your banned list isn't really serving any useful purpose. I personally prefer a system that temporarily bans an IP.

Re:fail2ban and firewall won't help with this atta (1)

perlchild (582235) | more than 5 years ago | (#27552427)

I'm using fail2ban and it configurably allows you to set how long you want to ban, and permanently isn't the default.
You must be thinking of some other tool

Re:fail2ban and firewall won't help with this atta (0, Redundant)

SnowZero (92219) | more than 5 years ago | (#27552703)

Fail2ban is actually configurable and temporary. Personally I've set it up to ban for an hour after 3 failed attempts. In the past this stopped most bots, who would go elsewhere if they were even temporarily banned. It looks like this new one is slow enough (<1 attempt/hr) that my current settings don't detect it. Of course, guessing username+password that way it'll take forever to get in, but it is kind of irksome.

Re:why are passwords even allowed? (2, Insightful)

dbIII (701233) | more than 5 years ago | (#27551683)

Nice in the short term but giving people an easy way to add rules to your firewall may create hassles later once miscreants know that is what you are doing. Some people have scripts that implement temporary blocking so it doesn't hurt much on the day that some script kiddie decides to have fun with them by forging attacks from different addresses.

Re:why are passwords even allowed? (0)

Anonymous Coward | more than 5 years ago | (#27551749)

Anyone with passwords turned on is not secure IMHO

Don't go spouting nonsense like that! Storing SSH keys is only as secure as the physical security of the client. If you're travelling (esp international) and need remote access to servers, passwords are the only way to go.

Re:why are passwords even allowed? (1)

thePowerOfGrayskull (905905) | more than 5 years ago | (#27551955)

Anyone with passwords turned on is not secure IMHO

Don't go spouting nonsense like that! Storing SSH keys is only as secure as the physical security of the client. If you're travelling (esp international) and need remote access to servers, passwords are the only way to go.

Your keys are password protected on the client...

Re:why are passwords even allowed? (1)

daemonburrito (1026186) | more than 5 years ago | (#27552121)

Or they should be. Unfortunately, there are a lot of "how-to"s on the web that use a null key passphrase to make scripting easier. That openssh allows this is a problem, but lots of people have written scripts that depend on it.

Re:why are passwords even allowed? (1, Funny)

Anonymous Coward | more than 5 years ago | (#27551839)

" I run log-guardian.pl to "3 strikes - you're out" the idiots who do the brute-forces by putting them into iptables"

Good to know that if I spoof your IP address I'll prevent you from login your own machines.

Re:why are passwords even allowed? (1)

xlotlu (1395639) | more than 5 years ago | (#27551917)

Better throttle them to some 20b/s.

Re:why are passwords even allowed? (1)

Annorax (242484) | more than 5 years ago | (#27551981)

Why not just set up an /etc/hosts.allow and /etc/hosts.deny file and set up them up so that only connections from trusted locations are allowed.

Yeah, I hear people saying "hey, how do you connect when you're out on the road?".

Simple answer: VPN service for remote users.

Re:why are passwords even allowed? (1)

Ernesto Alvarez (750678) | more than 5 years ago | (#27552363)

I've commented about that SSH/VPN idea somewhere else here [slashdot.org] .

What is the advantage of having an extra VPN in terms of SSH usage?
(I know there are other advantages, but you seem to imply that's just to allow SSH access from everywhere but a list of known addresses)

Re:why are passwords even allowed? (2, Informative)

timmarhy (659436) | more than 5 years ago | (#27551991)

passwords are still the most portable lightweigth authentication method out there, that's why. I had a system that got caught by this when a user with shell access set a weakish password. the user was sandboxed with only a limited whitelist of applications they could execute, so no harm done, but i did log all of the bot's attempts and the IRC channel it connected to along with passwords to other bots. it was very interesting to take the attack a part, at it's core it runs a simple dictionary attack and once it's in attempts to launches the same attack on the root password (no chance mine is 9+ random characters), plants a trojan in /temp (which failed in my case) and then connects to an IRC channel and awaits instructions which were pharsed using a simple perl script (which also failed). it then starts scanning for other victims using another perl script.

the activity on the channel indicated brazilian hackers. the thing that suprised me the most though was the amaturish and fragile nature of the process, instead of insulating the whole package so it could operate in a sandbox it atcually relied heavily on installed dependancies which i suspect means it was targeting the default install of one linux distro.

Re:why are passwords even allowed? (2, Interesting)

al0ha (1262684) | more than 5 years ago | (#27552127)

>> Anyone with passwords turned on is not secure IMHO.

I disagree. I both cases, password auth or key auth, barring any security problem with the protocol, the weakest link is the user. A passphraseless ssh key is tempting to the user for many reasons and unless you audit the passphrases selected by your users, key auth is no more secure than password auth. In fact password auth may actually be more secure if you enforce complexity on the system(s). You have no control over the passphrase on a user's SSH key. You can try to control it, but the user can strip the password at any time and on any remote system.

Not allowing passwords may actually lull you into feeling secure. Multi-user and personal user systems are compromised all the time, and in my and my collegues experiences, break-ins via SSH are as likely to happen via either method. Lame botnets try weak passwords, crafty exploiters try everything and thanks to Phalanx2, their craft became much easier.

Poor Odds (5, Informative)

Nerdfest (867930) | more than 5 years ago | (#27551243)

The odds of them getting into a system like this must be quite low, but I guess they're after the low-hanging fruit. Running your services on a high port rather than the default reduces this, as does disabling password login and using 2-factor authentication. Quite easy to do, and very, very secure.

Re:Poor Odds (1)

ducomputergeek (595742) | more than 5 years ago | (#27551401)

We did remapped SSH to a higher unused port and then took it a step further blocking access to that port on the hardware firewall from every IP address except for the office. If I need to connect to the server, I first have to connect to an OpenBSD box in the office.

We have 3 - 4 PCI scans a day (seems like every payment gateway we support for our clients scans the server daily. None of them even see SSH.

Re:Poor Odds (0)

Anonymous Coward | more than 5 years ago | (#27551407)

it's enabled by default on macs for remote login or help (or whatever they call ssh)

Re:Poor Odds (0)

Anonymous Coward | more than 5 years ago | (#27551541)

Neither "Remote Login" nor "Screen Sharing" are enabled by default.

Re:Poor Odds (1)

Cheech Wizard (698728) | more than 5 years ago | (#27552673)

it's enabled by default on macs for remote login or help (or whatever they call ssh)

Wrong... You post is nothing but flame bait from someone who obviously has never installed OS X.

Good Odds (0)

Anonymous Coward | more than 5 years ago | (#27551763)

In this particular attack after 'root' and 'admin' has been tried, the zombies try 'james' which is the most common first name in the united-states, then they run an alphabetical list of only first names. (as per the article)

Sample:
http://www.bsdly.net/~peter/slowbrutes.all.txt

These zombies are seeking out accounts that are the most likely to have high up privileges.

Since people tend to prefer usernames that reflect their own in some way, and are easy to remember, your first name is probably your most preferred.

And following that, the only chance you really get at using your first name is probably on one that you own.

If you own it, you're most likely to have privileges that exceed other users on your system.

Story of low hanging fruit (1)

dbIII (701233) | more than 5 years ago | (#27552081)

I had to re-install one of those low hanging fruit which was taken over via a dictionary attack about four years ago.
For some reason the guy that was looking after what should have been a simple mail server and incredibly basic web server decided to change things so that everyone with a mailbox had shell access. Then he put a compiler on there. Then, sick of having to "su" all the time he changed the permissions of everything in /etc (system configuration files) and who knows where else so that any user on the system could change them (this guy loves "chmod 777" - lets anybody do anything to the file). Then a user changed their complicated initial password to "coffee", which required the same guy to help since the system rejected such simple passwords. To make things worse the username with that password is a very common girls name. The next step, which is where I failed, was the guy looking after the machine (who should have done nothing other than add new users and edit the very simple plain HTML web pages) asked for ssh access so he could work from home, but he didn't know what the IP address would be. I gave him a hole in the firewall to get to what used to be a fairly secure box, and a few days noticed the thing appeared to be scanning ports all over the place on a Friday afternoon, and it did a few other odd things (ps and grep had been obviously altered) which meant pulling the plug. From looking at the disk afterwards it looked like somebody got in via dictionary attack and once they were in the permissions were such that they could do just about anything they wanted and the thing was rooted. Maybe they built some lkm thing on there with the compiler or just ran a rootkit, it's hard to tell athough "/etc/init.d/functions" had weird stuff in there to start up all kinds of things. Obviously you never even let something like that even do a clean shutdown - you pull the plug and make sure nobody gets a chance to put the disk in another system without knowing what they are doing (read only, no exec). Luckily it didn't take that long to rebuild the thing (new disk, even different media since an upgrade had come out and this time I set up sudo for the guy using it) but I prefer to do other things on weekends, especially when a school reunion was on that weekend. On Monday the users had to all choose new passwords and the "chmod 777" guy was shown a lot of things starting with how easy it is tell ssh to only let in specific users and how to use "sudo" instead of changing permissions everywhere.
To sum up - it only takes a few incredibly stupid actions to add up to low hanging fruit.

I should add (1)

dbIII (701233) | more than 5 years ago | (#27552141)

I know the way to do this to allow only those specific users that need ssh access (one or two in the above case - and never root on an external facing box), use keys instead of passwords, and only accept connections from the IP addresses that legitimate users will be on. None of those things are difficult. The above example shows what can happen with a far too relaxed approach.

One question? (0)

Anonymous Coward | more than 5 years ago | (#27551257)

Is "weakpassword" a weak password? I better change up my server double quick.

Not seeing it yet (3, Funny)

MichaelSmith (789609) | more than 5 years ago | (#27551259)

...unless they are only attacking from my existing list of blocked IP addresses.

Re:Not seeing it yet (1)

Sentry21 (8183) | more than 5 years ago | (#27551685)

A fair point. I've set up on our production servers two lists for ipset [netfilter.org] , one each for China and Korea. Bullshit accesses to SSH and HTTP dropped way way off once I did that.

With 719 unique CIDR blocks for China and 430 for Korea, we get a lot less garbage traffic to our servers. Worth the hour it took to set up, too.

Re:Not seeing it yet (1)

drpt (1257416) | more than 5 years ago | (#27552617)

not here also
Like my water heater I shut off ssh from 24:00 to 06:00 any attempts during that time go on the blacklist.
If anyone bitches, I steal their laptop battery and make them memorize the access rules before they get it back

Oh... (5, Funny)

Perseid (660451) | more than 5 years ago | (#27551293)

...you mean zombie PROGRAMS. Damn.

[puts shotgun down]

Re:Oh... (3, Informative)

MichaelSmith (789609) | more than 5 years ago | (#27551305)

[puts shotgun down]

Don't be so hasty. There are real people herding the zombies.

Re:Oh... (0)

Anonymous Coward | more than 5 years ago | (#27551449)

[puts shotgun down]

Don't put it down yet [thecoffeedesk.com] ...

Re:Oh... (1)

creimer (824291) | more than 5 years ago | (#27551521)

You mean like Zombie Hooker Nightmare [adultswim.com] ?

So the real question is... (1)

evilkasper (1292798) | more than 5 years ago | (#27552575)

.. what's your Zombie plan?

Protect yourself (5, Informative)

Matt Perry (793115) | more than 5 years ago | (#27551329)

Use SSH keys in addition to passwords. Disable ssh root logins. Use the AllowUsers command in sshd_config to restrict what accounts can log in with ssh. Edit /etc/hosts.deny and add IP ranges [iana.org] for where you are unlikely to login from. Use iptables rules to block people [itwire.com] who are hammering your ssh server from the same address. Use tools like Fail2ban [fail2ban.org] and DenyHosts [sourceforge.net] to block other abusers and share abuser information with other victims.

disabling root login is idiotic (1)

Nicolas MONNET (4727) | more than 5 years ago | (#27551457)

It's security theater.
There are good reason for allowing (private key only) root login, allong with autorized_keys command= directives.
Furthermore password+ssh keys is rather pointless.

Re:disabling root login is idiotic (1)

BitZtream (692029) | more than 5 years ago | (#27551855)

Is that good reason: You're an idiot?

Re:disabling root login is idiotic (1)

Ernesto Alvarez (750678) | more than 5 years ago | (#27552489)

While there might be good reasons to allow root access with a restricted key, that's hardly wise and there usually there is no need to do so.

As for the pointlessness of keys AND password, I think you're rather uncreative. There are a few uses of that scheme, the first one to come to my mind is a random password tightly controlled by the IT staff and periodically changed (and the user can do nothing about that) plus a key, under user control. The password allows enforcement of the security rules and insures that a stolen key is useless after a certain amount of time, even if the user chooses a guessable passphrase or leaves it unprotected, while having the security of a public/private key.

Re:disabling root login is idiotic (1)

Matt Perry (793115) | more than 5 years ago | (#27552495)

Furthermore password+ssh keys is rather pointless.

Until your account is compromised and the attacker can now ssh into your other accounts without having to enter a password. I'd rather have to enter the password when the key is used. Better safe than sorry.

Re:Protect yourself (2, Insightful)

anothy (83176) | more than 5 years ago | (#27551515)

mostly good advice. you might consider using ssh keys instead of passwords, depending on your environment. the only thing i'd outright disagree with is pre-denying IP ranges based on a guess of where you're likely to log in from. i've had to leave the country on business unexpectedly on very short notice; it'd suck to have been locked out when i landed.

Re:Protect yourself (2, Informative)

GaryOlson (737642) | more than 5 years ago | (#27551871)

Use VPN. Although it may seem redundant, SSH thru a VPN tunnel does provide a secondary access method which is secure.

Re:Protect yourself (0)

Ernesto Alvarez (750678) | more than 5 years ago | (#27552261)

Use VPN. Although it may seem redundant, SSH thru a VPN tunnel does provide a secondary access method which is secure.

While a VPN is secure, so is SSH.
Your idea might have some merit, until someone decides to go for your VPN solution instead of SSH, then you're in the same kind of trouble.

What I'm trying to stress here is that either you block access from unknown/unexpected addresses or you don't, just as you use an established secure login protocol or you don't. Pretending to block unknown IPs while having a VPN endpoint accesible to anyone is not restricting access to your servers to known addresses, it's having access from everywhere and trading SSH's set of vulnerabilities for your VPN's.

If you assume SSH has some problem, then it's a good idea to do what you've done. Then again, if that is the case, you shouldn't leave it open even to a few addresses (since that fault might be exploited by anyone capable of impresonating/pwning one of these hosts). That VPN is handy if you have services other than SSH, though. On the other hand, SSH is supposed to be designed to work in a hostile environment. If there is a problem with SSH you should probably report it to the appropiate persons, so it can be corrected.

IMHO, you're deceiving yourself into thinking you're restricting using IP addresses when you're not.

PS: I run OpenSSH on port 22, RSA/DSA keys only, non-root, and have another set of security measures in order to escalate (once you get to a non-root account).

Re:Protect yourself (1)

Matt Perry (793115) | more than 5 years ago | (#27552511)

you might consider using ssh keys instead of passwords

If you don't have a password as well then if your account is compromised the attacker will be able to access your accounts on other servers without entering a password. I know generating a ssh key without a password is convenient but it also creates risk.

SPA / PORT KNOCKING - Bye Bye Brute (4, Insightful)

myspace-cn (1094627) | more than 5 years ago | (#27551341)

Roll out SPA / Port knocking, their IP shouldn't be touching your sensitive ports without a rule, table, or chain specifically allowing access. FORGET THE PASSWORD!

Another solution (2, Insightful)

IceCreamGuy (904648) | more than 5 years ago | (#27551347)

Use a script like denyhosts, and I'm sure there are a ton of others out there that are just as good if not better. Unless your password is weak enough to be guessed in five attempts and the attacker isn't already in the denyhosts list, you shouldn't have to worry about too much. And, most importantly, just peruse your auth logs every now and then, it's not really that big of a chore.

Not So Shameless Plug (4, Informative)

value_added (719364) | more than 5 years ago | (#27551425)

For those already familiar with Peter Hansteen's website [home.nuug.no] , I'll offer a Thumbs Up recommendation for his Book of PF [amazon.com] .

There's already been several stories on Slashdot either submitted by or about him, and I don't recall any mention of his book. I'd say his efforts if not his humility deserve some kind of reward, and the reduced sale price of $19.77 is a bargain.

Denial (2)

the eric conspiracy (20178) | more than 5 years ago | (#27551429)

I've used a script to block servers that failed a certain number of attempts along with AllowUsers. That worked well for a couple of years, but was annoying in that you could see the attempts being made and knowing that if you made a config error you could be vulnerable. It seems to me that even after I got several hundred systems in my block list it wasn't making a difference since the pool of zombies was so large.

Now I just use key only access and AuthUsers and feel a lot more secure. I'm thinking I may add a white list of IP addresses as well. That would really lock things down pretty well.

In all seriousness (4, Informative)

actionbastard (1206160) | more than 5 years ago | (#27551497)

This has been going on for years. Really. I've been seeing this crap in my logs since we started running an Internet-facing SSH host nearly ten years ago. It's always the same password based login attempts with the same dictionary/script used in the attacks. This is probably just some training exercise for Chinese hackers at some state-run school to see who can break into the running-dog Yankee Imperialist's computers the fastest.

Re:In all seriousness (1)

cmdr_tofu (826352) | more than 5 years ago | (#27551621)

But this is distributed. Ie, from 13 different IPs there will be 13 different login attempts with different passwords targetting the same username.

To me, this seems like something new. I've been doing this for years to protect my users from your ordinary brute force attack: http://www.debian-administration.org/articles/187 [debian-adm...ration.org] Now, it is no longer effective. Of course my users should not have weak passwords, but rate-limiting by IP is no longer a trustworthy defense against dictionary attacks.

Re:In all seriousness (1)

mikael (484) | more than 5 years ago | (#27552057)

The botnet owners have large lists of likely usernames/passwords and IP addresses to try. In the past they just assigned a bot to try out a complete list of usernames/passwords to try for a range of IP addresses. Now, they just give each bot a range of usernames/passwords for a complete list of IP addresses. It doesn't affect the processing time required, but makes it harder to ban hosts.

I'm safe... (5, Funny)

hoytak (1148181) | more than 5 years ago | (#27551503)

I've now changed my password from Thomas to ThomasX, where X is a digit that I'm not telling.

Re:I'm safe... (2, Funny)

Main Gauche (881147) | more than 5 years ago | (#27551613)

pinkie? C'mon, gimme a hint.

Re:I'm safe... (1, Funny)

Anonymous Coward | more than 5 years ago | (#27551771)

I just cracked it. Very clever using a roman numeral 10 there.

Stop collaborate and listen. (1)

jonpublic (676412) | more than 5 years ago | (#27551517)

Just checked my auth logs and I'm seeing hundreds of various IPs, some of which are connecting up to 20 times. Definitely a new twist. I'll have to do some poking around to see what kind of machines are doing the probing. ( Is it compromised windows boxes?)

Re:Stop collaborate and listen. (0)

Anonymous Coward | more than 5 years ago | (#27551537)

( Is it compromised windows boxes?)

Conficker?

I always wondered about that (1, Interesting)

Anonymous Coward | more than 5 years ago | (#27551619)

Always these stories about zombies dossing this or bruteforcing that, but never a hint as to where these zombies came from, who they are, etc. You'd think that if you can see them in your logs that easily, it should be possible for their isps to see them as well, or else someone could inform them. Why aren't isps sending zombie customers a letter a la "please clean your machine, or we'll shut down your connection". Is it just that they can't reap profits from the customer anymore? In that case, why don't we just blacklist all isps who refuse to terminate zombies?

My server got attacked last Thursday (1)

h4x354x0r (1367733) | more than 5 years ago | (#27551519)

SSH login attempts from hundreds of different IP addresses. Could not get my IT department to block the port at the firewall. It's an old Mac OSX server - thus, why the POS locked up within minutes of the attack starting. Come to think of it, I haven't used SSH for ages. I always ARD into it to administer. CLICK. No more SSH.

At least it made me review my server security. I was way too lax, knowing how little value the data, or even the server itself, has. But the attack itself still annoyed me, so I tightened that bitch up real good (well, as good as you can tighten up an old Mac server).

Re:My server got attacked last Thursday (2, Insightful)

mellon (7048) | more than 5 years ago | (#27551615)

Um. You realize, of course, that remote desktop is a lot less secure than ssh, right?

It doesn't matter if people are trying to pick the lock on your door. What matters is whether they can pick the lock. Use RSA-based authentication, and no amount of brute force is going to improve the odds of their breaking in to the point where it's worth bothering.

Remote desktop, on the other hand, is completely brute-forceable. If you're not seeing brute force attacks, it's because nobody's bothering, not because you're not vulnerable.

Re:My server got attacked last Thursday (1)

dr2chase (653338) | more than 5 years ago | (#27551883)

They're coming pretty steadily. I read the FA, logged in to the ssh-receiving box, looked at the logs, and a half-dozen showed up while I was looking. Makes me wish I had the time to run a honeypot.

Based on my quick reading of the ssh/sshd documentation, I created an empty ~/.ssh/rc file for the accounts with known-good passwords (i.e., mine) and then put "kill -9 $PPID" in /etc/sshrc.

That seemed to work, though I know it will be bad for X11 (which I never use over ssh to my home box).

There may be more elegant ways to do this, but if there are, I didn't find them quickly (which is to say, the ssh documentation, like all Unix documentation, sucks rocks).

Re:My server got attacked last Thursday (2, Informative)

RzUpAnmsCwrds (262647) | more than 5 years ago | (#27552237)

Um. You realize, of course, that remote desktop is a lot less secure than ssh, right?

Remote Desktop uses TLS and X.509 certificates, so it's not exactly trivial to crack. It's easily as secure as SSH using password-based authentication. It's definitely *more* secure if your users never bother to actually check unknown server keys.

Now, compared to SSH using only key-based authentication, Remote Desktop isn't as secure. Unless you use smart cards for authentication with Remote Desktop, which are probably more secure than having your private key stored on your computer. Unless it's encrypted with a strong passphrase. Unless your computer has been rooted and has a keylogger.

Bottom line? Both systems can be plenty secure. It's all in how you configure and use them.

Re:My server got attacked last Thursday (0)

Anonymous Coward | more than 5 years ago | (#27552345)

LOL. So wrong on so many levels, it's not even worth it to bother correcting you. Please turn in any security or systems administration related badges to the front desk and be on your way.

Re:My server got attacked last Thursday (0)

Anonymous Coward | more than 5 years ago | (#27552423)

Use RSA-based authentication, and no amount of brute force is going to improve the odds of their breaking in to the point where it's worth bothering.

Pshaw. Just get a big botnet and try all 2^1048 RSA key possibilities and there you go.

(Yes, I know how big 2^1048 is. I'm kidding)

Re:My server got attacked last Thursday (0)

Anonymous Coward | more than 5 years ago | (#27552175)

We saw it focus on Mac OS X too (ignored Linux and Windows [cygwin] port 22). Given that TFA is named "That grumpy BSD guy" makes me think any BSD based systems were targeted. I wonder if anyone's cracked iPhones were targeted.

Don't just run it on a higher port. (2, Interesting)

Anonymous Coward | more than 5 years ago | (#27551575)

Be proactive on port 22 as well. At the advice of another comment I saw on /. a year or so ago I'm running a honeypot, with three static ports (one of them 22) and 4 roving ports. Establishing a TCP connection to any of them causes your IP to be instantly added to an iptables blacklist. It's worked pretty well; I've got about 2-3 unique addresses trying per day, and about 294 have been blocked since mid-December 2008. It takes care of both port scanners and bots deliberately connecting in order to try and get root on my server.

Of course, the only way to get root on the server anyway is through a Yubikey [yubico.com] OTP or the 64-character randomly generated password I have on an encrypted partition somewhere in case my Yubikey is ever fried/stolen/lost.

Re:Don't just run it on a higher port. (1)

Ernesto Alvarez (750678) | more than 5 years ago | (#27552577)

Is there any difference with respect to a PKCS#11 token?
I've been thinking of using one of these tokens as a "road warrior" SSH key, but then realised that since they need drivers to be useable, that wouldn't be practical to use on machines not owned by me.

Also, why not S/KEY [freebsd.org] instead of one of those yubikeys (or at least the random password)?

quickest fix (2, Interesting)

capn_nemo (667943) | more than 5 years ago | (#27551629)

While it's true there are a variety of techniques that can increase security, I've found simply moving to a new high-numbered port eliminates all random login attempts. Yes, security through obscurity is all it's cracked up to be, but for now, I've eliminated the problem with a pretty quick fix.

Re:quickest fix (1)

cmdr_tofu (826352) | more than 5 years ago | (#27551729)

Good idea, you should run a honey_sshd on port 22 as well.

Tarpit (0)

Anonymous Coward | more than 5 years ago | (#27551655)

I simply use the tarpit xtables module from http://xtables-addons.sourceforge.net/. It holds the connection open consuming resources per x connection initiated by the zombified machine.

Goodness. (4, Informative)

geekboy642 (799087) | more than 5 years ago | (#27551823)

There sure are a lot of people who didn't bother to read the article.
The point of these attacks are that it's a coordinated botnet attack. Meaning if you block any single IP, or even a large subnet, you've cost the attacker nothing. Fail2ban, denyhosts, all of these won't even slow these attacks down.

Re:Goodness. (0)

Anonymous Coward | more than 5 years ago | (#27552663)

What's worse, if you have a long timeout before re-allowing access to an IP (Or if you never re-allow access), your deny list can get very long, reducing iptables performance.

meept (1)

larry bagina (561269) | more than 5 years ago | (#27551877)

last post!

easy and hard is not absolute (1)

kentsin (225902) | more than 5 years ago | (#27551879)

Think of cutting the space into several (2) pieces. Round one we attact piece 1, round 2 we can skip piece 1 and attack piece 2 and round 3 we can skip 1 and 2 and attack only 3.

It is good to check what they are attacking before we urge everyone to choose a hard password.

Noticed It (1)

cheese-cube (910830) | more than 5 years ago | (#27551903)

I noticed this last night when lwatch just start spewing out failed authentication attempts. One point that I don't really see mentioned is that they will try a wide variety of different usernames. A snippet from auth.log:

Apr 12 23:16:27 host sshd[523]: Address 202.42.66.11 maps to changi.aglow.com.sg, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Apr 12 23:16:27 host sshd[523]: Invalid user warpuser from 202.42.66.11
Apr 12 23:16:27 host sshd[523]: pam_unix(sshd:auth): check pass; user unknown
Apr 12 23:16:27 host sshd[523]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=202.42.66.11
Apr 12 23:16:29 host sshd[523]: Failed password for invalid user warpuser from 202.42.66.11 port 58502 ssh2
Apr 12 23:16:32 host sshd[525]: Address 202.42.66.11 maps to changi.aglow.com.sg, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Apr 12 23:16:32 host sshd[525]: Invalid user fwadmin from 202.42.66.11
Apr 12 23:16:32 host sshd[525]: pam_unix(sshd:auth): check pass; user unknown
Apr 12 23:16:32 host sshd[525]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=202.42.66.11
Apr 12 23:16:35 host sshd[525]: Failed password for invalid user fwadmin from 202.42.66.11 port 58869 ssh2
Apr 12 23:16:38 host sshd[535]: Address 202.42.66.11 maps to changi.aglow.com.sg, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Apr 12 23:16:38 host sshd[535]: Invalid user mailadm from 202.42.66.11
Apr 12 23:16:38 host sshd[535]: pam_unix(sshd:auth): check pass; user unknown
Apr 12 23:16:38 host sshd[535]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=202.42.66.11
Apr 12 23:16:40 host sshd[535]: Failed password for invalid user mailadm from 202.42.66.11 port 59272 ssh2

An easy method to out-smart them that has been mentioned before is to simply change the SSH port.

Re:Noticed It (1)

Culture20 (968837) | more than 5 years ago | (#27552303)

Your log snippet shows a script kiddie from a single IP, not a bot-net.

iptables goodness (5, Informative)

grasshoppa (657393) | more than 5 years ago | (#27551963)

Once again, we have a built in linux goody which helps us out;
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m recent --set --name sshattack --rsource
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m recent --rcheck --seconds 300 --hitcount 3 --name sshattack --rsource -j LOG --log-prefix "SSH Drop: "
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m recent --rcheck --seconds 300 --hitcount 3 --name sshattack --rsource -j REJECT --reject-with tcp-reset
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

The above allows three connections in a 5 minute period to port 22. After that it rejects any further connection attempts until the 5 minute timer is up.

Re:iptables goodness (0)

Anonymous Coward | more than 5 years ago | (#27552675)

what happens if they keep attempting it 24/7 and the port now drops all connections constantly? How do you log back in with ssh?

damn! (1)

binaryseraph (955557) | more than 5 years ago | (#27552049)

And here I thought this would be about zombies trying to scratch through my door or eat my cats- you know, in a really laid back, maybe give up and come back later kinda way. what a let down.

Post your banlist (2, Informative)

UnRDJ (712762) | more than 5 years ago | (#27552051)

I get about 5 of these a day, on a relatively small site. I wrote a small shell script out of sheer boredom that parses hosts.deny and gives me country and hostname info. Here's the output from the past week or so. It seems to confirm that most of these are from public isps overseas.

117.21.249.75 CN, China
121.166.163.142 KR, Korea, Republic of
122.128.36.3 KR, Korea, Republic of
189.19.245.182 BR, Brazil 189-19-245-182.dsl.telesp.net.br.
200.111.157.187 CL, Chile
201.6.124.155 BR, Brazil c9067c9b.static.spo.virtua.com.br.
202.229.120.74 JP, Japan
203.125.51.23 SG, Singapore
207.5.149.188 US, United States 149-188.suscom-maine.net.
211.87.224.190 CN, China
211.99.203.168 CN, China
216.164.162.155 US, United States 216-164-162-155.pa.subnet.cable.rcn.com.
217.219.67.86 IR, Iran, Islamic Republic of
218.241.177.241 CN, China
219.121.10.35 JP, Japan m010035.ppp.asahi-net.or.jp.
221.3.131.110 CN, China
61.184.136.164 CN, China
61.191.53.99 CN, China 99.53.191.61.broad.static.hf.ah.cndata.com.
77.79.88.247 TR, Turkey reverse-77-79-88-247.grid.com.tr.
80.179.149.122 IL, Israel 122.sharatim.co.il.
82.165.27.220 DE, Germany p15173261.pureserver.info.
83.19.20.66 PL, Poland byq66.internetdsl.tpnet.pl.
84.53.78.183 NL, Netherlands 84-53-78-183.wxdsl.nl.
87.197.110.47 SK, Slovakia static-dsl-47.87-197-110.telecom.sk.
99.53.191.61 --, N/A adsl-99-53-191-61.dsl.mtry01.sbcglobal.net.
200.219.194.74 BR, Brazil static.200.219.194.74.datacenter1.com.br.
202.190.177.144 MY, Malaysia
164.77.195.60 CL, Chile
89.119.5.106 IT, Italy 89-119-5-106-static.albacom.net.
221.154.206.233 KR, Korea, Republic of
218.208.91.111 MY, Malaysia
65.120.74.22 US, United States
210.185.64.195 AU, Australia 210-185-64-195.intrapower.net.au.
202.168.58.111 AU, Australia 111.58.168.202.static.comindico.com.au.
85.25.71.36 DE, Germany loft1551.serverloft.de.
193.136.39.26 PT, Portugal genid.dcc.fc.up.pt.
150.146.40.173 IT, Italy mspasiano.cedrc.cnr.it.
221.194.128.66 CN, China
82.135.192.72 LT, Lithuania 82-135-192-72.static.zebra.lt.
80.10.250.17 FR, France
207.28.220.1 US, United States voyager.iavalley.cc.ia.us.
164.77.208.198 CL, Chile
38.107.141.131 US, United States host-38-107-141-131.mtl.net.vexxhost.com.
222.218.156.41 CN, China

My Solution (4, Informative)

ironicsky (569792) | more than 5 years ago | (#27552153)

I was having similar brute force attacks.
I've made some alterations to protect my server from brute force SSH attempts.

1) Moved SSH to another random port
2) Bound the SSHD to an IP address that is not used for Web/Mail/FTP, etc.. So the IP should generally see less traffic
3) Disable Password Authentication, Users who are given SSH access must use a password protected key file
4) Disabled Root SSH Login
5) Setup the system that 3 failed logins add the entire IP Subnet(X.X.X.0-X.X.X.255) for 15 minutes, 5 failed attempts 1 week, anything else is a never ending ban. (iptables and hosts.deny, just in case)

pam_abl does the trick (1)

tommi (103396) | more than 5 years ago | (#27552231)

Im really impressed by pam_abl. It covers every pam enabled service so smart password guessers which may traverse between protocols will be covered as well. It's configurable as to how to handle guesses from hosts as well as users.

Really?! (1)

sourcery (87455) | more than 5 years ago | (#27552533)

Will they be in town all week? Can we still get tickets?

Why do they have to be successful? (1)

FlyingBishop (1293238) | more than 5 years ago | (#27552807)

This can only mean that there were enough successful attempts at guessing people's weak passwords in the last round that our unknown perpetrators found it worthwhile to start another round.

There's no reason to assume this has any significant returns. I'd assume, rather, that the botnet herders occasionally find themselves with nothing better to do, so they just run this stuff in idle cycles. No real logic to it, they just have a botnet that isn't currently useful for anything else. And a .0001% chance of getting something is better than 0%, since it costs them very little if they've already written the requisite brute-force code.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?