Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Security

Rundown on SSH Brute Force Attacks 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."
This discussion has been archived. No new comments can be posted.

Rundown on SSH Brute Force Attacks

Comments Filter:
  • What next? (Score:4, Insightful)

    by hoka ( 880785 ) on Saturday July 16, 2005 @01:29PM (#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).
  • by Anonymous Coward on Saturday July 16, 2005 @01:36PM (#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.
  • by jfengel ( 409917 ) on Saturday July 16, 2005 @01:40PM (#13082025) Homepage Journal
    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.
  • by whovian ( 107062 ) on Saturday July 16, 2005 @01:41PM (#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.
  • Re:As always... (Score:5, Insightful)

    by justMichael ( 606509 ) on Saturday July 16, 2005 @01:43PM (#13082041) Homepage
    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... (Score:1, Insightful)

    by Anonymous Coward on Saturday July 16, 2005 @01:43PM (#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]
  • by dd ( 15470 ) * on Saturday July 16, 2005 @01:46PM (#13082066) Homepage
    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
  • by handy_vandal ( 606174 ) on Saturday July 16, 2005 @01:57PM (#13082147) Homepage Journal
    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
  • Re:As always... (Score:4, Insightful)

    by SlightOverdose ( 689181 ) on Saturday July 16, 2005 @02:00PM (#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.
  • by Lord Bitman ( 95493 ) on Saturday July 16, 2005 @02:01PM (#13082174)
    I just disabled any SSH use without a key. Duh, right?
  • Re:As always... (Score:3, Insightful)

    by arivanov ( 12034 ) on Saturday July 16, 2005 @03:37PM (#13082753) Homepage
    If you took security seriously you would have disabled passwords for ssh in first place. Anyone who allows a conventional password based login on an internet facing system via ssh deserves everything he gets. After all this means that he/she did not bother to learn how to use it. It is the same as buying a Ferrari and driving it only fist gear.

    If you want to access your home PC use RSA/DSA keys instead. This cuts out all brute force attacks once and for all.

    Alternatively use PAM/RADIUS and SecureID. You can buy managed SecureID service for under 100$ per token per year. Costs money, but works fairly well.
  • Re:As always... (Score:2, Insightful)

    by daliman ( 626662 ) <slashdot@onthero ... inus threevowels> on Saturday July 16, 2005 @07:46PM (#13084028) Homepage
    If you don't allow remote root logins (not remote root access, using su) then the attacker needs to know two passwords - one user and the root. How is this not more secure?

To do nothing is to be nothing.

Working...