Is it normal to get hundreds of break-in attempts per day?

http://serverfault.com/questions/244614/is-it-normal-to-get-hundreds-of-break-in-attempts-per-day

by splattne • 15 years ago

199 76 15 years ago

I've noticed this too. Almost immediately after I signed up and created a hosting account with KnownHost, the hacking attempts started, even before I had logged in to Cpanel for the first time.

I got an automated email every time somebody failed to log in, so my iPhone was plinging every few seconds for 30 minutes before I added a filter in GMail to mark those mails as read. I've since installed fail2ban.

eli• 15 years ago

I've got a script set up to scan my logs and temporarily ban clearly malicious IPs. It finds a few hundred new ones each day.

hvs• 15 years ago

fail2ban does a nice job of this.

njharman• 15 years ago

I'd say hundreds is not normal. It is order of magnitude too low.

wtn• 15 years ago

How would you define an order of mangitude in this case?

seiji• 15 years ago

At times, a few hundred per minute is "normal."

I prefer port knocking or two factor auth as a solution to brute force attacks. http://code.google.com/p/google-authenticator/

epenn• 15 years ago

My home firewall catches 20-25 failed login attempts per day, all of which seem to originate in China. I'm tempted to setup a honeypot that'll show a fake bash prompt just to see what gets thrown at it. Naturally I assume there is an elite international force that will stop at nothing to break in and steal the larger original jpegs of my Facebook photos as well as all of my college homework. I'm on to you, elite international force!

nickbp• 15 years ago

They're likely more interested in obtaining hops from which to attack other machines.

thwarted• 15 years ago

Apparently, their appetite for the original, larger copies of photos uploaded to Facebook and for college homework knows no bounds!1!!

jamroom2• 15 years ago

You can eliminate 99% of these attempted logins by changing your SSH port from the standard 22 to something else (say 2177 or whatever). Login as root (or su), open the /etc/ssh/sshd_config file and change the port number. Save your changes and restart ssh with "/etc/init.d/ssh restart" and you are good to go. You'll want to update any SSH clients you use to use the proper port (-p option on command line). Hope this helps!

ulf• 15 years ago

Even better is to additionally setup a fake SSHd at port 22, so that port scanners do not even bother keeping on looking for the port and instead use what they suspect to be working

mfontani3• 15 years ago

I use https://code.google.com/p/kippo/ as a ssh honeypot, and https://github.com/mfontani/kippo-stats to display stats about it (number of attempts, successful logins, most usernames tried, most passwords tried for "root").

The data is quite interesting.

Here's a snapshot of where most "attacks" to my honeypot originate from (the more, the brighter): http://darkpan.com/files/latlong255.png

dedward2• 15 years ago

As interesting and fun as honeypots are - unless it's your own gig, or the data from the honeypot fits into a larger security plan, it's just adding one more thing to manage. Move the port, run denyhosts, and in general just have access firewalled off to begin with.

cd342• 15 years ago

Good grief I hope you never do this. Do NOT use a port > 1023 for anything that should run as root. If you do, and your machine gets compromised, any unprivileged user could start an ssh daemon, you might think, oh, why is the key different, accept it, and they've keylogged your login attempt.

staunch• 15 years ago

I don't disagree in principle. In practice: how did they manage to start their own daemon on a port sshd is already bound to?

getsat2• 15 years ago

This is only an issue if you're using password authentication and do not drop traffic on ports on which you are not running services.

Just use Single Packet Authorization, people.

jamroom2• 15 years ago

Thanks for this - this is good advice. Using a port over 1023 doesn't make sense and isn't necessary - the idea is to just change the port from the normal 22. Thanks!

drdaeman• 15 years ago

This won't give you much security (most of entropy is in your password/keyfile), but will highly lower the convenience, because you'd have to use `-p 2177` or put the port number in `$HOME/.ssh/config`.

Same goes to port-knocking.

Just throw in denyhosts/fail2ban, and follow simple rules (no root login, no password/keyboard-interactive logins, possibly, except for special emergency "oh-shit-i've-lost-my-keyfile" account with secure passphrase and non-dictionary username), and you'll be perfectly safe.

eru• 15 years ago

You are right about the entropy in one sense. So against a determined attacker the port does not matter.

On the other hand, most drive-by attackers won't bother going for the other ports. Perhaps you can make some argument involving the probability/entropy/information of the attacks vs your defenses.

notaddicted• 15 years ago

Make sure to open the relevant port on your firewall before you do this!!

mike-cardwell• 15 years ago

  sudo apt-get install denyhosts

Job done.

troels• 15 years ago

Have never heard of this tool before. Is it a standard thing or is it only for the clinically paranoid?

epochwolf2• 15 years ago

It's pretty standard in the group of sysadmins I hang out with on irc.

rosser2• 15 years ago

Just because you're paranoid doesn't mean script kiddies aren't trying to root your box.

chrisaycock• 15 years ago

There's also fail2ban, which monitors more services than just SSH:

http://www.fail2ban.org/

bediger• 15 years ago

I'm too lazy and too stupid to put in denyhosts or any of the other anti-guessing software, but I have put in a 7-second delay on password-authenticated SSH logins, as per http://www.aerospacesoftware.com/howtos/ssh-kiddies.html That makes my sshd less a honeypot and more a tarpit.

I also put in an output line so I can see what passwords they're guessing.

tvon2• 15 years ago

FWIW, denyhosts and mod-security don't seem to require any real additional configuration beyond just installing them on Ubuntu 10.10 (and copying the example config for mod-security from /usr/share/doc/mod-security-common/examples).

fretlessjazz• 15 years ago

I run Rails and became tired of seeing 404s to standard ASP or PHP software (such as phpmyadmin), so I added this to our Apache conf:

RewriteRule \.(asp|aspx|php|jsp)$ - [F,L,NC]

RewriteRule (w00tw00t) - [F,L,NC]

RewriteRule (phpmyadmin) - [F,L,NC]

RewriteRule (php-my-admin) - [F,L,NC]

That cuts off those requests before they hit a Rails process and suck up any additional resources.

mfontani3• 15 years ago

On Lighty, I simply have:

    url.redirect = (
        "^(.*)php(.*)$" => "http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.37.3.tar.bz2",
        # other stuff
    )

I do not use php on the server.. I don't know if these kits end up downloading the kernel or not, though.

buro9• 15 years ago

Please don't do this... having bots launch a DDoS attack on kernel.org is not good.

Just throw the request away or return a 404 at the load balancer level.

If you're on Apache use mod_security, if you're not put Varnish in front and configure it to return simple 404 errors on such pages.

But don't mod_rewrite, redirect or otherwise throw traffic onto someone else's server, let alone one that will result in a traffic cost for them.

tvon2• 15 years ago

I'm not sure kernel.org would appreciate that.

mbreese• 15 years ago

Yeah, I'm not sure that kernel.org is the right way to go here... plus, I'm pretty sure they'll not be happy.

But, I do wonder if there is some other way to do the same thing. Perhaps we could setup some kind of tarpit like server that sends out a file very slowly... like .1K / sec (~1 packet every 10 secs). Just enough to keep their connection alive, but slow enough to not use too much bandwidth.

But, I'm not sure if this would be any better than just sending a 404 quickly.

blhack• 15 years ago

Is there a javascript folding@home client? A better move would be to make bots do something useful for humanity.

ck2• 15 years ago

You MUST try the free and awesome configserver firewall

http://configserver.com/cp/csf.html

It's fantastic. Among a million other things, monitors logs for several kinds failed login attempts and can automagically ban them via iptables (with timeouts if you so desire).

Be sure to donate to keep this fantastic software alive if you use it.

tcopeland• 15 years ago

As some of the commenters on serverfault suggested, the easiest fix is to just disable password auth in sshd_config. No need to fool with denyhost's whitelisting and whatnot, just use public key auth only.

megamark16• 15 years ago

This and changing the port to something non standard is what keeps me sleeping like a baby at night.

mbailey• 15 years ago

Yes. And I'm sure it's been said: fail2ban

asnyder• 15 years ago

Denyhosts is pretty good too.

wingo2• 15 years ago

I went to look at my logs and realized I forgot both my own and root's password on my linode. Doh!

edu• 15 years ago

use private/public key to login!!!

wingo2• 15 years ago

I do indeed; that's why I had forgotten my password, because I always log in with my key. Amusing, this!

getsat2• 15 years ago

You'll have to reboot the Linode to change the root password from your control panel. Do not use passwords to auth over SSH!

Use ssh-keygen to generate a key and copy the contents of the .pub to your ~/.ssh/authorized_keys and disable PasswordAuthentication in /etc/ssh/sshd_config and /etc/init.d/ssh reload

maratd• 15 years ago

There are really two issues here. One is SSH and the other is HTTP.

SSH is easy. Get a static ip or figure out the ip range for your ISP. Drop any connection not in that IP range using iptables on that port. Done.

HTTP requires more creativity. It really depends on how you have things set up. I have a honeypot default vhost on Apache. If you enter just the IP address for the server, you get the honeypot. That's what most of these bots will hit. The 404 errors caused are very annoying and mess up the logs. On the honeypot, I have a RewriteRule that rewrites anything that would cause a 404 to index.html which is a blank page.

idm• 15 years ago

Use a VPN (openvpn), and attach sshd to your VPN subnet instead of using 0.0.0.0 or your publicly routable IP. This is also great for any other services you might want to administer remotely. It's normal to bind your database/cache to 127.0.0.1, but you can also bind to an IP in your VPN subnet, which makes it a little easier than tunneling through SSH to access your database.

Vivtek• 15 years ago

Yes.

Well - actually, no. Mere hundreds are kind of abnormally low.

yalogin• 15 years ago

For SSH break-in attempts an easier solution would be to use a random (at least alpha numeric) userid. These dictionary based attacks only use standard, most generic login ids.

JoshTriplett• 15 years ago

No need to bother making your userid cryptographically secure; either turn off passwords or use a secure password. It doesn't matter whether the bots find a valid username, as long as they can't guess your password.

bkaid• 15 years ago

I created a free test server on Windows Azure a few weeks ago with remote desktop access enabled and had failed login attempts within 2 minutes of the server going live, without publishing the ip address or dns name anywhere.

sucuri2• 15 years ago

OSSEC (open source) is very good at blocking those. It looks at all your logs and blocks brute forces via SSH, HTTP, etc...

Link: http://ossec.net

jarin• 15 years ago

If you're running a Rails server on Ubuntu, protecting your server is as simple as deploying your app with Moonshine, with the ssh, iptables, and denyhosts plugins.

It requires maybe 7-10 lines of configuration to have a fairly well-insulated system:

  # config/moonshine.yml
  :ssh:
  :port: 9024
  :allow_users:
    - rails

  # app/manifests/application_manifest.rb
  configure({
    :denyhosts => { :admin_email => 'admin@example.com' }
  })
  
  recipe :ssh
  recipe :iptables
  recipe :denyhosts

aquarin2• 15 years ago

I have thousands attempts at my nginx server mostly from China and most of them checking for free proxy server. I am even convinced it is some sort of automatic software scanning IP ranges for proxy. Freedom is difficult in some countries.

aquarin2• 15 years ago

If you see requests like: "GET http://somesite/proxycheck.php

Try this in Nginx server config: if ($request ~* "^[^ ]+[ ]+[^:]+://" ) { return 444; }

444 is nonstandard Nginx code that closes the connection without sending any headers.

Is it normal to get hundreds of break-in attempts per day?

Related Stories