Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security

Rundown on SSH Brute Force Attacks 360

Posted by Zonk from the more-you-know! dept.
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 More

Rundown on SSH Brute Force Attacks

Comments Filter:

  • As always... (Score:5, Informative)

    by jsight ( 8987 ) on Saturday July 16, 2005 @12:28PM (#13081936) Homepage
    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... (Score:5, Insightful)

      by justMichael ( 606509 ) on Saturday July 16, 2005 @12: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:5, Interesting)

        by SlightOverdose ( 689181 ) on Saturday July 16, 2005 @12:53PM (#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
      • If some package/whatever creates an account and I don't know, it can't be exploited.

        How could it possibly be exploited? As long as the password field is * or !! and there is no authorized_keys file, then you can't login using ssh.

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

      by ben_white ( 639603 )
      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 th

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

        by arivanov ( 12034 )
        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 c

    • Re:As always... (Score:4, Informative)

      by MyDixieWrecked ( 548719 ) on Saturday July 16, 2005 @12:48PM (#13082081) Homepage Journal
      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... (Score:4, Informative)

        by clymere ( 605769 ) on Saturday July 16, 2005 @01:06PM (#13082197) Homepage
        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 ;)
        • that's actually a good idea... I honestly never thought of that.

          have thumb drives improved at all in the last 5 years?

          I got one when they first came out (a 32mb one). It would frequently erase itself. I'd put it in and it would be called "Untitled" and have no files on it.

          I didn't have anything important on it. Just some Hotline bookmarks and a hotline client for mac and windows.

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

          by Wonko ( 15033 )

          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 ;)

          First of all, your public key goes onto the server you are logging into. You need your private key on the client.

          Second, it isn't very secure to use your private key from an untrusted machine. What you want to use from untrusted machines are one time passwords.

    • Re:As always... (Score:5, Informative)

      by Homology ( 639438 ) on Saturday July 16, 2005 @01:23PM (#13082282)
      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.

      No kidding? By disallowing password authentication you've stopped the script kiddies dead in their tracks. As for disallowing root access, here are some words from [neohapsis.com] an OpenBSD developer:

      ... All unmitigated horseshit. Sorry. Look I use sudo, and I like it. but it is no substitute for allowing root login to a box, and is no substitute for "su", Sorry. They are different. I don't want to add a billion sudoable local accounts to run boxen in a distributed authentication environment. I want "root" local, and be done with it. I want root exposed if someone knows the root password, not if someone knows the root password or fourteen other idiot's passwords that are used every day. That's not more secure. If you want a useful diff to help stop this ridiculous discussion from propping up every little while. Here's what I propose: ....

      Saying "don't login as root" is horseshit. It stems from the days when people sniffed the first packets of sessions so logging in as yourself and su-ing decreased the chance an attacker would see the root pw, and decreast the chance you got spoofed as to your telnet host target, You'd get your password spoofed but not root's pw. Gimme a fucking break. this is 2005 - We have ssh, used properly it's secure. used improperly none of this 1989 bullshit will make a damn bit of difference. -Bob

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

        by Tassach ( 137772 )

        Saying "don't login as root" is horseshit. It stems from the days when people sniffed the first packets of sessions so logging in as yourself and su-ing decreased the chance an attacker would see the root pw

        That may have been the reason you did it in the past, but it's not the reason you do it now. The reason for not logging in directly as root (or under any other shared accout, for that matter) is ACCOUNTABILITY. If you log in as root directly, all that gets logged is the host you came from. If yo

  • What next? (Score:4, Insightful)

    by hoka ( 880785 ) on Saturday July 16, 2005 @12: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).

    • I think the idea is (Score:2, Insightful)

      by Anonymous Coward
      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.

    • The idea is old, but the attempt is new (Score:5, Insightful)

      by jfengel ( 409917 ) on Saturday July 16, 2005 @12: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.

  • Highly annoying (Score:4, Interesting)

    by oGMo ( 379 ) on Saturday July 16, 2005 @12:31PM (#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 (Score:5, Interesting)

      by cdrguru ( 88047 ) on Saturday July 16, 2005 @12:41PM (#13082034) Homepage
      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 (Score:3, Interesting)

        by justMichael ( 606509 )

        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.

        While this approach looks like a great solution on the surface, it can have some rather unfortunate side effects.

        You want to be careful where you deploy this type of setup.

        Take this example. You run a fairly successful ecommerce site in a very competitive space. One of your competitors discovers you use this method and decides they don't want you to compete with them on Googe, Y

    • 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.

    • 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.

    • 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 (Score:2, Interesting)

        by str8 ( 28028 )
        Perl is an appropiate tool for this in my mind. I did what you did but had syslog send the entries to a FIFO which the script reads from.
        I give them 2 tries in 10 seconds or 3 in 60 before they get put into the bit bucket. I then send an email to myself with the IP, times, and usernames.
        Kinda fun to watch my gmail account get 4-5 of these a day.

        Psst. Hey buddy. Can you spare a .sig?
    • 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.
    • 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.
    • This [sourceforge.net] has been mentioned elsewhere in a comment - it might be worth looking into, as it seems to do pretty exactly what you want.

      Outside of that, if you're not doing so yet, why not contribute those logs to DShield [dshield.org]? More data is always good for them. :)
    • Comment removed based on user account deletion
  • 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 ana

  • Easy fix (Score:4, Informative)

    by Anonymous Coward on Saturday July 16, 2005 @12:32PM (#13081963)
    i have had this on a number of occasions.. i just set the max auth attepts to 4, this renders the attempts useless

  • DenyHosts (Score:5, Informative)

    by roubles ( 716740 ) on Saturday July 16, 2005 @12:33PM (#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 (Score:3, Interesting)

      by theCoder ( 23772 )
      I recently stumbled upon sshdfilter [liv.ac.uk]. It analyzes sshd output in real time by running sshd in with the -e option and adds attempts to login with invalid usernames to an iptables chain to drop all packets from that host. I've only been running it for a week or so, but it seems to be working well.

      Seems like a similar idea to DenyHosts, just a different implementation.

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

    • 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.)
  • 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.
    • 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 (Score:3, Informative)

    by fire-eyes ( 522894 ) on Saturday July 16, 2005 @12:35PM (#13081982) Homepage
    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 (Score:2, Informative)

      by ak8b ( 798032 )
      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.
      • Not only that but changing the port really helps with spotting a real attack. Dumb scripts always try port 22. Since I run SSH on a different port all that random noise falls away. If I see failed login attempts I know I'm looking at something with some intelligence.

  • Attacks are a sad reminder on stupidity (Score:3, Informative)

    by m.dillon ( 147925 ) on Saturday July 16, 2005 @12:36PM (#13081987) Homepage
    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

    • distrubingly, i discovered yesterday that FreeBSD apparently does NOT require a user to set a password for root. Not during install, not ever. Sure, you need to have added a user to wheel...but most people will for the convenience. Now you've got a machine ready to be owned by the compromise of any user account thats in wheel. OpenBSD on the other hand, not only required I set a password for root, but also refused anything that didn't have letter, numbers, and at least one special character!

  • Use another port (Score:5, Informative)

    by objorkum ( 695401 ) on Saturday July 16, 2005 @12:37PM (#13081994) Homepage
    Use another port than 22. I have not noticed one single bruteforce attempt after I did that.
    • I agree. It doesn't protect against someone specifically targetting your machine, they'll just port-scan you and then proceed on the new port. But it's very effective against the widespread robot attacks we've seen for the past couple of years.
    • Use port 443. As a bonus, corporate firewalls will think it's an HTTPS site and you can log in to your box from work.

  • surprising, just May 2005 (Score:3, Insightful)

    by whovian ( 107062 ) on Saturday July 16, 2005 @12: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.
  • 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.
  • 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.

  • why not disable passwords entirely? (Score:5, Informative)

    by toby ( 759 ) * on Saturday July 16, 2005 @12:45PM (#13082058) Homepage Journal
    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.
    • 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.
  • 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 reque

    • A skript kiddie from there had been pounding me for months from 68.39.149..
      I've gone back and forth with Comcast but the upshot is: Pound Sand.
      As a result I banned his entire ip range. I had to, his password attacks were coming too fast & blocking out legit clients. This action took out 255 innocent customers of Comcast NJ - but's that's the risk of subscribing to a rogue ISP.

  • add AllowUsers to /etc/ssh/sshd_config (Score:4, Insightful)

    by dd ( 15470 ) * on Saturday July 16, 2005 @12: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
  • 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 (Score:4, Informative)

    by meisenst ( 104896 ) on Saturday July 16, 2005 @12:49PM (#13082088) Homepage
    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).
  • 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 authenti

  • They actually got in on my parent's computer (Score:5, Interesting)

    by yorgasor ( 109984 ) <ron@@@tritechs...net> on Saturday July 16, 2005 @12:55PM (#13082135) Homepage
    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.
  • ... 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 (Score:4, Informative)

    by angst7 ( 62954 ) on Saturday July 16, 2005 @12:56PM (#13082142) Homepage
    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 (Score:5, Insightful)

    by handy_vandal ( 606174 ) on Saturday July 16, 2005 @12: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
    • This has got to be the best, most lucid, most interesting post on slashdot for at least 5 years.
      • This has got to be the best, most lucid, most interesting post on slashdot for at least 5 years.

        Thanks, made my day.

        In the interest of journalistic balance, it should be noted that I've posted plenty of asinine, ill-thought-out comments in the past five years.

        But I recognized the Authority post as a keeper, the moment the idea came to me. So, thanks again for your affirmation.

        -kgj
  • 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 e

  • I just disabled any SSH use without a key. Duh, right?
  • 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.

  • Comment removed (Score:3, Informative)

    by account_deleted ( 4530225 ) on Saturday July 16, 2005 @01:07PM (#13082203)
    Comment removed based on user account deletion
  • Comment removed based on user account deletion
  • One of my favorite features of Tiger Server is that I can enable ssh login (and just about every other service including console login) only for the users I choose. That way, even if one of my lusers' accounts is compromised, the bad guys can't get to a command line.

    Oh yeah, and I (manually) set their shell to /bin/false. That way if I screw something else up, there's no way anybody's launching a shell as them.

    Last, Tiger doesn't have passwords for any of the standard unix accounts, so no amount of dictio
  • I just installed SSHBlack.pl the other day on my server to deal with this. It is at http://www.pettingers.org/code/sshblack.html [pettingers.org] . What it does is monitor /var/log/secure or whatever file has the failed attempts. If it sees 5 failed attempts in a recent time from an IP, it by default adds a new iptables rule fo X amount of days. It also has some protection to prevent a DOS issue from two many IPs being added.

    For me, since I run shorewall, I changed one line to run shorewall drop instead of adding its
  • http://it.slashdot.org/~(H)elix1/journal/38378 [slashdot.org]

    I had installed DB2, and used db2admin/db2admin as the default account. Win32 box, but was undead by the time I got back from a roadtrip. Not only do you need to make sure your passwords are strong, but avoid the 'common' passwords folks will set up for a dev account. Looking at my firewall logs for the last year just confirms how fast you will go down if you use a simple/common account and password.
  • Comment removed based on user account deletion

  • My box was compromised by this (Score:4, Interesting)

    by Malc ( 1751 ) on Saturday July 16, 2005 @06:31PM (#13083966)
    A few months back my Debian Woody system was compromised by this. I had major security issues: a weak password and an old unpatched kernel.

    I got up in the morning and looked at my logcheck emails. It was odd: there were messages saying the ethernet card had entered promiscuous mode, and several kernel modules loaded. Further investigation revealed two connections to remote port ircd, but netstat wouldn't show the process ID(s) that owned this connections. The machine was in a mess: I couldn't run man, or gzip (needed by the apt-get process) and several other key commands as they immediately seg faulted. Rebooting resulted in the same issues: ethernet card in prom. mode, etc. Perhaps a packet sniffer was running on my networking looking for passwords to upload.

    My problems started when I created an account for a friend and gave it a weak password without making him change it. The ssh dictionary attack broke in that way. Furthermore, I wasn't running a normal Debian kernel. Instead one that somebody else had created with MPPE support (it would be nice after all these years if one could have MS-CHAP support for PPP straight out of the box). I hadn't kept tabs on the kernel notices and ensured that this kernel was ok with them - it hadn't been updated for at least a year. Thus the script that broke in via SSH was able to exploit a local security hole and elevate privileges - game over.

    I write all this as a reminder to people to take care. Debian is fairly secure if you use standard packages and keep them up to date. I'm generally quite carefull about what I install, which services run, what ports are exposed to the internet, keeping and eye on it, etc. Two careless mistakes and I had to rebuild the system and change all my passwords - thankfully nothing more. Be warned.

Slashdot Top Deals

"Hello again, Peabody here..." -- Mister Peabody

Close