Brute Force

This is incredibly common, my laptop is usually attacked within half an hour if I port forward.

It is nothing to feel special about, not a targeted attack. However, if you have any stupid passwords like guest/guest, testing/password and such, eventually someone is going to guess right.

I think turning off root access should be sufficient, as well as not adding common usernames with bad passwords.

I personally take no risks and have absolutely no passwords, just keys.

Yep, it's just distributed brute-force guessing of bad passwords. Every single one of my servers saw these until I switched to a non-standard port.

As long as you don't have bad passwords, generally they won't get in. However, here's a neat little tool I've heard about (but haven't tried, since I'd probably just implement my own perl scripts to do this anyway):

http://fail2ban.sourceforge.net/

It watches the log files for failed login attempts, and then adds those IPs to the deny list.

DenyHosts is another tool you could try out if fail2ban doesn't work out for you…I've been using it on ~5 servers for about a year now and it works great.

Thanks Guys, moving my ssh to a non standard port seems to have done the trick, I am careful not to have stupid passwords as well, but I will keep an eye on it.

Cheers.

One of the best things to do is not to allow passwords at all. I running ssh on a nonstandard port using key based authentication only.

Remember if need be you can always log in via LISH so you won't be locked out if you have to access your Linode from a different computer occasionally.

Andrew

Are you aware of any howtos on how to set up key based ssh as I have no experience with that at this point, or perhaps someone can give me a quick run down on the steps involved.

Cheers All.

Google is great for searching :)

http://www.google.com/search?hs=xou&hl= … tnG=Search">http://www.google.com/search?hs=xou&hl=en&lr=&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&q=ssh+key+based+authentication&btnG=Search

One good link I found quickly:

http://software.newsforge.com/software/ … 1214.shtml">http://software.newsforge.com/software/04/03/15/211214.shtml

@NecroBones:

http://fail2ban.sourceforge.net/

Just thought I'd "support" Fail2ban by saying that it works great, and that it's very easy to set up even if you don't know much about Linux; extra especially superduper easy, and if you order now you'll recive 10% more peace of mind for free, if you are using Debian, of course.

/Tony - recovered Red Hat source code-junkie turned pro-package Debian user.

One problem with something like fail2ban is the extra resources it consumes. By default it scans the log once every second, imagine the IO tokens this consumes on a Linode! If you decrease this to a sane value, no more then once per minute, you lose effectiveness. Since all but a few of these attacks last less then a minute, they won't be caught while they are still going on. Then there is the increased latency garnered from each rule added to iptables that every inbound packet has to be checked against. You've also got the extra RAM that running another daemon consumes, a precious commodity on a Linode where RAM is a bit more scarce then a typical server. Then there is also the processing involved in keeping track of what IPs were blocked when so that they can be automatically removed.

iptables already has mechanisms in place for blocking traffic that crosses a threshold. You don't have to have another daemon running using valuable RAM or a process constantly scanning a log file looking for authentication failures. You also don't have an input chain that is 800 rules long. Check out this sample Debian init.d script that limits new connections to port 22 to 3 per 60 second interval: http://www.linode.com/forums/viewtopic.php?p=6935#6935

Thanks unixfool, I have got the key based authentication sorted out, google did do the trick in the end, can't remember what link, was more a case of doing some reading and once I had some understanding of how it worked, then I had it going, so now I have a non standard ssh port and key authentcation only, so I am feeling better about the whole thing.

Mike thanks for the input on the fail2ban suggestion, that information is quite valuable and it I hadn't known how fail2ban worked I may have employed a solution using that.

Having said that Tony, your mentioning it is appreciated too, as if people don't suggest things how can we get alternatives to solving our problems, and if it were not a Linode, UML type of system then it may have been an excellent choice.

Thanks to everyone, and I feel that I have built a more secure system thanks to everyone's help

Cheers. :D

@mikegrb:

One problem with something like fail2ban is the extra resources it consumes. By default it scans the log once every second, imagine the IO tokens this consumes on a Linode!

You're right, Linode sucks… thanks for pointing that out… Now if you all excuse me I'm going to go and cancle my account… :mrgreen:

This page might be of some use for people interested in this (I don't think I've seen it mentioned here before, correct me if I'm wrong): Using iptables to rate-limit incoming connections.

Fail2ban is very easy to use, so unless you know that your server can't handle it it's a great solution; I'm using it mainly because it's fun to get e-mails about people getting blocked. :lol:

@mikegrb:

One problem with something like fail2ban is the extra resources it consumes. By default it scans the log once every second, imagine the IO tokens this consumes on a Linode!

BTW, I think I've got a pretty good grasp on how it works with those IO tokens here, but it really should be easier to get that information and for non-tech people to understand what it really means.

Is that information easily available somewhere and I've just missed it?

@tony:

BTW, I think I've got a pretty good grasp on how it works with those IO tokens here, but it really should be easier to get that information and for non-tech people to understand what it really means.

Is that information easily available somewhere and I've just missed it?

Is this helpful? http://www.linode.com/wiki/index.php/IO_Tokens

Thanks, but I can't let go of the feeling that that information should be almost forced on new users; that their Linode-experience would be happier if they knew more about the limits and/or possibilities earlier on… Maybe some sort of once-you're-up-and-running kind of a guide to more knowledge?

It seems like a good thing to put in the FAQ. I just looked and was surprised it was not there. If anything is Frequently Asked, the io thing is it.

That said, I somehow knew about the iotokens issue before I signed up and have always known to cat /proc/iotokens when I'm having issues. I just can't recall HOW I knew to do this – probably lurking in the forums for a while.

By the way, I found mikegrb's reply really useful. And I completely understand why there is a need to limit io, given the machine hardware is shared.

@ryantate:

It seems like a good thing to put in the FAQ. I just looked and was surprised it was not there. If anything is Frequently Asked, the io thing is it.

That said, I somehow knew about the iotokens issue before I signed up and have always known to cat /proc/iotokens when I'm having issues. I just can't recall HOW I knew to do this – probably lurking in the forums for a while.

By the way, I found mikegrb's reply really useful. And I completely understand why there is a need to limit io, given the machine hardware is shared.

Another nice feature, tied to this, would be to get automagic warnings about the performence of ones Linode; allowing the admin to either learn more about how to optimize the setup, or, more likely, just put themselfs inline for an upgrade… No more thinking about where the problem is, they'd just push a button or two to get and upgrade when needed.