Lessons learned from running my honeypot

So… I’ve been running my ssh/http honeypot for almost a month now. While
I’m not really ready to release all my reports to the intar-webs yet,
there are some lessons that are readily apparent. And sadly, these
are the same lessons everyone else has been screaming about for the
last dozen years.

SSH lessons

  1. Don’t allow root to ssh into your server. Make sure your
    /etc/ssh/sshd_config has “PermitRootLogin no” set.

  2. Don’t use stupid passwords. Passwords like “password”,
    “admin”, and “123456” and their assorted variations are the
    top passwords that ssh brute force attacks try.

  3. Longer passwords are better than shorter passwords. Well over
    95% of the passwords tried are 8 characters or less.

  4. Don’t keep the default passwords for any software you install.
    Looking at Google for the passwords tried shows that many of them
    are default passwords for one piece of software or another.

  5. Don’t keep the default passwords for any hardware (including
    routers). They keep trying “admin” accounts with the password
    “admin” which was a default for older home routers.

Webserver lessons

  1. Patch bash! They keep trying ShellShock attacks against my
    honeypot, so they must be suceeding enough of the time to make
    it worth their while.

  2. Patch PHP! The second most common attack is against old PHP

  3. Don’t install things into their default directories on the
    webserver. Most attacks are against default scripts that get
    put into the cgi-bin directory. Even renaming cgi-bin to CGI-BIN
    and changing your httpd.conf file to reflect that change eliminates
    more than 95% of the attacks. Close after that are phpMyAdmin.
    webtools, ccbill, cgibin (no dash), and /mail. Rename those
    directories and even if you’re vulnerable, they probably won’t
    find you quickly.

What are they trying to run?

  1. Number one thing they are trying to run is the Atrix IRC worm.
    This is an IRC bot that lets them attack other servers, AND can
    give them the ability to run commands on your server as whatever
    UID is running httpd.

  2. bash. yes, bash. There’s an option in bash to open a network
    connection to the outside world. This lets them telnet to whatever
    port they decided to use and have a bash shell on your server to
    run whatever they want to.

  3. ssh brute force scripts. These try to login to other servers
    and then report the successfull attempts back to another server.

  4. ONE instance of a rootkit. Why? I have no idea. I assume
    the other attacks are precursors to downloading and running a
    rootkit on your server.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s