SSHD Brings down my system once again

Once again my Winbox has been totally hosed by sshd. I forgot to disable it after a reboot and when I came home the machine was barely working at all.

It appears that some lamer asswipe was trying to bruteforce me, but poor fool was looking for root password. Heh… This is a windows machine, and I have no user called root so he is never going to find it :)

Unfortunately, all these requests put strain on my poor little machine to the point where it keels over and dies. My EventViewer is overflowing with sshd events, and errors. I think the sshd service forks so many children that it runs out of working memory. And if some of the login attempts hang for the 2 minute login grace period, it is likely that the system simply cannot allocate space for other services, including registry lookups and such.

Again, I don’t think I was pwn3d. My registry is intact, and I don’t see any other signs of tampering with my system. Just the consistent brute force pounding every other day. I tweeked the sshd_config to limit the grace period to 20 sec, lowered the number of max concurrent auth attempts and to drop any excessive traffic. This should help conserving the resources…

However, considering the fact that cygwin is not rock solid, I no longer feel completely safe running this service on my machine. I don’t want some silly cygwin based buffer overflow to compromise my machine. So I’m taking sshd off again for a while. I might need to find another solution to access my desktop remotely :P

This entry was posted in sysadmin notes and tagged , . Bookmark the permalink.



5 Responses to SSHD Brings down my system once again

  1. Dan McCarron UNITED STATES says:

    Did you get his IP addy?

    //Dan

    Reply  |  Quote
  2. Luke UNITED STATES says:

    Well, there were probably 7 different ones, all banging the shit out of me :O

    Might be zombies, or whatnot. I didn’t bother to investigate that much. You should have seen my apache logs – all my traffic for two last weeks were some assholes trying to run IIS exploits :P

    Oh well, it should be all bouncing off the NIC right now. I’m planning to set up a linux box for ssh :)

    Reply  |  Quote
  3. Dan McCarron UNITED STATES says:

    I recommend Free/OpenBSD instead of linux, Open being my first choice. you won’t need any fancy hardware to setup a fancy server. If you decide to try it and need any help/tips on setting it up, just buzz me. You can get started with a floppy and just do an ftp install , takes hardly any time on cable.

    MS!=server , but you know this.

    //Dan

    Reply  |  Quote
  4. Again, I don’t think I was pwn3d. My registry is intact, and I don’t see any other signs of tampering with my system.

    First of all, from within the system itself it is impossible to be sure if there was a break in. The attacker could have covered his tracks by changing the logs. He could also modify your tools. So he could have changed your registry, but your compromised registry editor won’t tell you. You have to look at the system from the outside with trusted tools, like from a LiveCD.

    Second, with Windows there is no way to be sure there was no break in, even when looking from the outside, because the attacker could have modified the logs. The BSDs aren’t vulnerable to this because you can make the logs append-only so that even root can’t modify them (chflags sappnd /var/logs/authlog).

    As an experiment just last month I set up OpenBSD on a VM (Qemu), locked it down, and allowed sshing into it. I gave my friend the root password and the IP address of the machine. I told him to log in, compromise the machine, and cover his tracks, then tell me when he was done. I would then try to find evidence.

    I first inspected the machine by sshing in myself as root. He did it! Or so it seemed. I checked authlog, which had been locked down with sappnd. No evidence there, which suprised me. I was wondering how he got past the sappnd flag. Then I suspected that he mounted a loopback device over the logs, so I ran “losetup -a”, which also showed nothing.

    It turns out that he actually modifed losetup, mount, umount, and many other tools so they would give me false information. My tools weren’t reliable. So I booted the install CD and investigated from the trusted tools on it. The logs were all intact, and I could see everything he did up until he mounted the loopback device over the logs. It was impossible for him to hide.

    So always check from the outside.

    I recommend using something like DenyHosts, which will limit the number of guesses from a single IP, then ban that IP in hosts.deny. This did exist back then when you wrote this. ;-)

    My DenyHosts setup allows only 3 or 4 wrong guesses for any single IP, then adds the IP to hosts.deny. They don’t even have a chance to guess a legitimate username, let alone a password. Root logins are disabled, and it won’t even let you try to guess root because it will ban you instantly for entering root as the user.

    Reply  |  Quote
  5. Oops, make that “vnconfig” instead of “losetup”. I couldn’t remember the right name.

    Reply  |  Quote

Leave a Reply

Your email address will not be published. Required fields are marked *