Is it normal to get hundreds of break-in attempts per day?(serverfault.com)
serverfault.com
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
21 comments
I went to look at my logs and realized I forgot both my own and root's password on my linode. Doh!
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
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
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.
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.
I'd say hundreds is not normal. It is order of magnitude too low.
How would you define an order of mangitude in this case?
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/
I prefer port knocking or two factor auth as a solution to brute force attacks. http://code.google.com/p/google-authenticator/
eh, disabling password auth solves the problem almost as well.
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!
They're likely more interested in obtaining hops from which to attack other machines.
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!
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.
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.
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.
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.
Make sure to open the relevant port on your firewall before you do this!!
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
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
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
kippo's code is going to be less audited than openssh's. do you run kippo as root? is the risk of running kippo worth the stats?
I run it as a dedicated user, on a high port. Port 22 of the router is merely forwarded to the internal high port I use.
Sure, I could chroot the thing as well.
kippo can't be executed as root.
How does it open a server on a port <1024 without privileged access?
It probably doesn't.
# accept traffic to the normal ssh port
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
# accept traffic on the port kippo is listening on
iptables -A INPUT -i eth0 -p tcp --dport 2222 -j ACCEPT
# direct traffic inbound on port 22 to port 2222
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 22 -j REDIRECT --to-port 2222
http://www.faqs.org/docs/iptables/traversingoftables.html
Table nat is traversed <b>before</b> filter table.
Therefore, the rule iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT is unnecessary.
Everyone, hear the post above.
Damn little arrows and imprecise HTC touchscreens... downvoted you by mistake
Damn little arrows and imprecise HTC touchscreens... downvoted you by mistake
That's fine so long as you trust all of the users on your system. Otherwise they could potentially get something running on port 22. Which, so long as you aren't actually sending auth info to 22, probably isn't a big deal.
You use iptables to route port 22 on the external interface to a high port on localhost
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.
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.
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?
Web exploit, get a web shell, crash your ssh daemon somehow, start my own. Since it is running on a non-privileged port, easy enough to run my own ssh daemon there.
Crashing the ssh daemon isn't always easy, but, making the job easier for an attacker because 'obscurity' is considered a good protection scheme in this case opens up other potential vulnerabilities.
Crashing the ssh daemon isn't always easy, but, making the job easier for an attacker because 'obscurity' is considered a good protection scheme in this case opens up other potential vulnerabilities.
Linux' OOM killer, just to give one possible example.
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.
Just use Single Packet Authorization, people.
It really depends on the scenario. Are you using one server? Do you manage a bunch of servers here and there for various clients? Are you responsible for corporate servers? All of them have different acceptable approaches to security.
On my on personal servers? Single-packet or port knocking or whatever, it's fun to play around - that's how you learn. At the enterprise? The internet can't ssh to anything - you need VPN access, and not just any but the correct VPN access, and the right credentials on audited machines. There's nothing for outsiders to knock on (except maybe the VPN - but that has auto-lockout and password rotation tied into the enterprise auth system)
If someone wanted to do port knocking or similar for enterprise stuff I think that'd be a staunch "Umm, no"
On my on personal servers? Single-packet or port knocking or whatever, it's fun to play around - that's how you learn. At the enterprise? The internet can't ssh to anything - you need VPN access, and not just any but the correct VPN access, and the right credentials on audited machines. There's nothing for outsiders to knock on (except maybe the VPN - but that has auto-lockout and password rotation tied into the enterprise auth system)
If someone wanted to do port knocking or similar for enterprise stuff I think that'd be a staunch "Umm, no"
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!
[deleted]
sudo apt-get install denyhosts
There's also fail2ban, which monitors more services than just SSH:
http://www.fail2ban.org/
http://www.fail2ban.org/
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.
I also put in an output line so I can see what passwords they're guessing.
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).
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.
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.
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
)
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.
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.
> Please don't do this... having bots launch a DDoS attack on kernel.org is not good.
Yeah, point them at microsoft.com instead! Should be easy to find a hefty service pack or DirectX install for the bots to hit...
Yeah, point them at microsoft.com instead! Should be easy to find a hefty service pack or DirectX install for the bots to hit...
Even though not all of us like Microsoft, you still shouldn't do this. The best way to handle this is to send random data at 10b/s and slow down the bots.
It'd be interesting to keep a list of the bots, and randomly redirect the traffic back at them. My first thought was that this would mess up people who unknowingly have a bot on their computer, but then I realized this might actually make them look into getting their computer fixed.
Am I missing something here, or is this actually a decent idea?
Am I missing something here, or is this actually a decent idea?
I suppose you could always redirect to 127.0.0.1. Maybe even go for a port that's likely to be open on a statistically random compromised system, like 135 (Windows DCOM, can't close it to localhost without breaking like half the system).
Edit: I just tried this in IE on my Win box; the connection even stayed open for a good long time! Firefox blocked it, though, which is probably good.
Edit: I just tried this in IE on my Win box; the connection even stayed open for a good long time! Firefox blocked it, though, which is probably good.
I doubt these bots can handle the redirect request. Its js and I don't see why someone would code to support it. Maybe someone better informed than me can say whether curl or wget respect redirect by default.
JS? 300 http codes cause a redirection without any JS whatsoever.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
There is an extension to iptables that adds a TARPIT target
http://xtables-addons.sourceforge.net/
http://xtables-addons.sourceforge.net/
Better would be to redirect to a third party service that offers that.
Are there any? I think that's weekend-project sized and donations could support it.
Is there a javascript folding@home client? A better move would be to make bots do something useful for humanity.
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.
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.
I'm not sure kernel.org would appreciate that.
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.
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.
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.
This and changing the port to something non standard is what keeps me sleeping like a baby at night.
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.
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.
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.
Yes.
Well - actually, no. Mere hundreds are kind of abnormally low.
Well - actually, no. Mere hundreds are kind of abnormally low.
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.
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.
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.
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
Link: http://ossec.net
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:
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 => '[email protected]' }
})
recipe :ssh
recipe :iptables
recipe :denyhostsI 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.
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.
Try this in Nginx server config: if ($request ~* "^[^ ]+[ ]+[^:]+://" ) { return 444; }
444 is nonstandard Nginx code that closes the connection without sending any headers.