SSH Password Gropers Are Now Trying High Ports 349
badger.foo writes "You thought you had successfully avoided the tiresome password guessing bots groping at your SSH service by moving the service to a non-standard port? It seems security by obscurity has lost the game once more. We're now seeing ssh bruteforce attempts hitting other ports too, Peter Hansteen writes in his latest column." For others keeping track, have you seen many such attempts?
Low Hanging Fruit (Score:5, Informative)
It's still just going after low-hanging fruit. Anyone weth any real awareness of security does now allow password-only SSH connections anyway. Key based auth and fail2ban is pretty much required these days. You can always add some port knocking to obscure it a bit if you don't like reading about failed access attempts.
Re:Low Hanging Fruit (Score:5, Interesting)
Re:Low Hanging Fruit (Score:5, Funny)
You can brute force a key to....it just takes much, much, much, much longer....
Re:Low Hanging Fruit (Score:5, Informative)
Better than that... (Score:4, Informative)
The below will create a dynamic blacklist. Any IP address that connects more than three times in five hours (pass or fail) will go into a blacklit that will persist until they stop trying for at least a day.
This will recodr your bad actors _and_ it will "expire" in case you invalidate a system by accident (e.g. over-use).
iptables --new-chain SSHTHROTTLE
iptables --append SSHTHROTTLE --match recent --name bad_actors --update --seconds 86400 --jump DROP
iptables --append SSHTHROTTLE --match hashlimit --hashlimit-name ssh_throttle --hashlimit-upto 5/hour --hashlimit-mode srcip --hashlimit-burst 2 --jump ACCEPT
iptables --append SSHTHROTTLE --match recent --name bad_actors --set --jump DROP
iptables --append INPUT --in-interface ext+ --proto tcp --match conntrack --ctstate NEW --dport 22 --syn --jump SSHTHROTTLE
Re:Better than that... (Score:4, Insightful)
If I ever did this on any of my employer's servers I wouldn't expect to keep my job for much longer. Any countermeasure that cannot tell the difference between good and bad attempts is worthless. Imagine a room full of webdevs behind a NAT that use SCP to transfer files and then take a guess at the resulting productivity after your "solution" is implemented.
Re:Low Hanging Fruit (Score:5, Funny)
Re:Low Hanging Fruit (Score:5, Informative)
I've been using key based authentication for ssh for years. I just moved the service to a high port to get rid of all the script kiddy password guessing attempts that were clogging my log file. I also added a "throttle" in iptables:
# Block brute force attacks
# Drop repeated ssh connection attempts within 20 seconds interval
-A INPUT -p tcp -m tcp -m state -m recent -i eth1 --dport 22222 --state NEW -j DROP --rcheck --seconds 20 --name THROTTLE --rsource
# Accept ssh connection if not attempted within past 20 sec.
-A INPUT -p tcp -m tcp -m state -m recent -i eth1 --dport 22222 --state NEW -j ACCEPT --set --name THROTTLE --rsource
It just cuts down on the noise. I used the same technique back when people were doing the DNS cache poisoning attacks to limit how many hits my DNS could get from the same source (first query should update the cache in a legitimate site's DNS so no reason why I should get repeated hits from the same site).
Cheers,
Dave
Re: (Score:2)
I like that. Thanks for sharing!
Re: (Score:3)
Re:Low Hanging Fruit (Score:4, Insightful)
Using a high port is one more thing you can do. To me, using it to filter out 90% of scanners is worth it even though it will still let through the 10% of people scanning high ports.
Exactly this.
Using a high port will not prevent a determined act of corporate espionage, but it probably will make J. Random Script-Kiddie move on.
Re:Low Hanging Fruit (Score:4, Informative)
Yes, as part of a defense in depth and not as a measure by itself.
Re:Low Hanging Fruit (Score:5, Insightful)
I'm saying that just because an obscurity measure is no substitute for a security measure doesn't mean it's not worth doing.
A sysadmin's time is valuable. A simple measure which eliminates 90% of the noise in a log is almost always worth doing, especially if it doesn't significantly inconvenience legitimate users.
Re:Low Hanging Fruit (Score:5, Insightful)
It's not security by obscurity, I really wish this meme would die, seeing as so many people are misapplying it. This is one thing that you can do to make it more expensive to try and crack your systems. It's not the only thing that you should be doing and calling one technique security by obscurity when you can easily figure out which port it is, really just conveys ignorance about what you're talking about.
Anything you can do that makes it inconvenient to try and crack your system is going to help a bit.
Re: (Score:3)
It absolutely works. Obviously it's not foolproof and should not be relied on as the only security measure, but if it adds enough time/complication/etc that it's just easier to move on to an easier target it does greatly reduce the chances of a successful attack.
Re: (Score:2)
DROP means regular TCP retransmit will defeat your throttle without the cracker having to do anything.
I'd instead use REJECT.
Re:Low Hanging Fruit (Score:4, Informative)
Re:Low Hanging Fruit (Score:5, Informative)
I'd use TARPIT [wikipedia.org] instead.
Re: (Score:2)
I used the same technique back when people were doing the DNS cache poisoning attacks to limit how many hits my DNS could get from the same source (first query should update the cache in a legitimate site's DNS so no reason why I should get repeated hits from the same site).
Except if they're all behind NAT; then you're hurting legitimate users.
Re: (Score:3)
Re:Low Hanging Fruit (Score:4, Informative)
It's actually quite hard to spoof anything now. No domestic connection will forward packets that don't from from the designated IP address. You need to have access to either the LAN of a decently-sized corporation or the internal network of an ISP. Easy enough for skilled hackers to get, yes - they can compromise a device somewhere - but beyond the script kiddie.
Re: (Score:3)
Better than port knocking is single packet authorization.
http://www.cipherdyne.org/fwknop/docs/SPA.html [cipherdyne.org]
Unless they have either a correct password or gpg private key and an exact port number and protocol, they aren't even going to have the slightest idea that a computer even exists at the IP address they are scanning.
No (Score:3)
"You thought you had successfully avoided the tiresome password guessing bots groping at your SSH service by moving the service to a non-standard port?"
No, because that's crappy "security".
Denyhosts/fail2ban is a much better solution.
Re:No (Score:5, Interesting)
It's not for security.
It's to stop the script kiddies of the internet wasting your bandwidth and cluttering your logs with thousands upon thousands of rejection messages in their futile attempts to gain access. They can't get in, but their efforts are annoying.
Re:No (Score:5, Funny)
I'd never heard of "security through ignorance", but I find it compelling.
Perhaps we could call it "ostriching ".
Re:No (Score:4, Interesting)
I don't look at the logs so I'm not annoyed. Problem solved.
The other problem is when you have a device like an old wrt54gl which has to perform unnecessary work (and therefore gets hotter than it needs to) when trying to deal with several password attempts a second.
Changing the port to something like and rate limiting it from unknown addresses makes a huge difference.
I agree with not looking at the logs though, or at least in the default configuration. How is knowing that someone failed to log in a useful thing to know? That's just the security system doing it's job and is just noise. What you want to log is the successful logins from remote IP addresses that haven't been seen before, or have previously been seen trying many incorrect combinations of username and password. That's a significant event.
Distributed attacks (Score:2)
Denyhosts/fail2ban is a much better solution.
Not if the brute force attempts are distributed across thousands of different /24s, or if a botnet member is behind the same carrier-grade NAT as your machine.
Comment removed (Score:5, Informative)
Re: (Score:2)
These days I've got thousands of IP-addresses on my hosts.deny
What's even cooler is you can set Denyhosts to synchronise your local hosts.deny or hosts.evil list, so you can quickly build a large and fairly comprehensive blacklist that updates over time.
Re:Don't rely on security-though-obscurity (Score:5, Insightful)
You might as well expire those banned IP addresses after a day because 99.97% of them are compromised machines on dynamic connections. Having a file that size just wastes computing resources (having to check every single one) and slightly increases the chance you won't be able to log in from some random place one day.
No I haven't, and here is why: (Score:3, Interesting)
I've blackhole'd all ports I'm not actually using, so the machines don't respond at all. I've setup port-knocking to open the port I actually use for SSH, and my SSH key is passphrase protected. Passphrase not password.
I've never even seen anything that wasn't me attempting to log in in my sshd and system logs. Root login disabled, and pubkey authentication is the only enabled method... so even if they did figure out my port knocking sequence they could literally spend infinity time trying to figure out my non-root non-existent password.
Also, wtf password groper? This used to be a news for nerds site, not a news for computer molesters site...
Re:No I haven't, and here is why: (Score:5, Funny)
I've setup port-knocking to open the port I actually use for SSH, and my SSH key is passphrase protected. Passphrase not password.
Pfft. Lightweight. Nobody's ever getting into my passnovelseries-protected pubkey. Passnovelseries not passnovel.
And I change languages and character sets every chapter.
Re:No I haven't, and here is why: (Score:5, Funny)
I've setup port-knocking to open the port I actually use for SSH, and my SSH key is passphrase protected. Passphrase not password.
Pfft. Lightweight. Nobody's ever getting into my passnovelseries-protected pubkey. Passnovelseries not passnovel. And I change languages and character sets every chapter.
Not bad, not bad! But I'll share a little pro-tip with you; I do all the above, PLUS I turn my monitor upside down when I'm typing in my passphrase so that even if someone stole my SSH key, they'd still have to figure out it's orientation!!
Re: (Score:3)
what's an easy way to set up port knocking?
Use random IPv6 from a /64 range (Score:4, Interesting)
Typically server hosting with ipv6 will assign a /64 range to each box. Assign your ssh port to a randomly generated address somewhere i the range (2**64 addresses) and port scanning will never find it.
Re:Use random IPv6 from a /64 range (Score:4, Insightful)
Typically server hosting with ipv6 will assign a /64 range to each box.
Which would require you to switch to a hosting provider with IPv6 and move your own home or office to an area whose ISP offers IPv6.
Re: (Score:2)
Re: (Score:2)
I suspect the answer is as long as not too many people know they exist :/ Theres also teredo and 6to4 (though they may have problems with overloaded or even discontinued relays if they get too popular).
CSF is the answer (Score:2)
Re: (Score:3)
Unlikely... unless the port scan is distributed across a botnet. Just 65K machines can scan the entire port space for any given protocol with one attempt apiece.
Dumbass parroting. (Score:5, Interesting)
It seems security by obscurity has lost the game once more.
How, exactly?
By ensuring the vast majority of brute force attacks - which hit port 22 - fail?
Security isn't fucking binary, and obscurity is a perfectly valid layer of the onion.
Re:Dumbass parroting. (Score:5, Interesting)
Well and good, but all any security implementation buys you is *time*. The real problem with StO is that the time it buys you is unpredictable, and in Kerckhoffs' era of large and slow system upgrades, it might take years to update a cryptosystem once it was broken. Malware authors have happily used StO for years -- for example, evading detection mechanisms by using a number of off the shelf packers in sequence. The approach works because they replace their malware faster than anyone figures out the packing sequence. The windtalkers during WWII were a security through obscurity approach, and it worked fine for the duration of the war, but would have gone horribly in the next one.
Now, what we're dealing with here is network defense, which isn't crypto. In network defense, creative lying is enormously helpful because you can use it to differentiate between your ignorant attackers and knowledgeable members of the community. The majority of attackers scan horizontally (all hosts on a fixed number of ports) rather than vertically (all ports on a number of hosts) because vertical scanning is a waste of time. Most attackers normally hit 9-10 ports and then move onto the next potential target -- they don't see the network in terms of what the hosts *are*, just what they can *exploit*. Moving SSH to a random port means that the attacker now has to spend 6000x the effort to figure out of there's anything on the host he cares about, and he's probably not going to bother when there are nice sysadmins out there happy to put everything on port 22 (as always, I don't have to outrun the bear. I just have to outrun you.) Copy it with some aggressive port blocking (like port 22) or a threshold random walk scan detector and you've got a perfectly fine way to ignore idiots. It's also worth noting that the mentioned port is 2222, which tends to be "stupid port manipulation rule #2" among folks (the other one being to add 1 in front of the port numbers, I can't tell you how fascinating it was to watch port 16888 the first time we blocked bittorrent).
Typical geek shit (Score:5, Insightful)
For some reason, geeks seem to think there is magic, perfect, computer security. "Just do THIS and your servers are secure, nobody can ever break in!" Those of us who've dealt with physical security understand there's NO SUCH THING. Good security is a layered approach. You never rely on one thing for security, you have layers so that when, not if, a layer fails you aren't automatically fucked, the other layers hopefully catch it.
While moving SSH to another port may not be a real big security improvement, security improvement don't have to be big to be useful, particularly if the cost is low, and in this case the cost is zero.
Also here's some news: It is 2013 and just now the bots seem to be adapting. That means that it was pretty effective. Seems to me SSH has been in use for, oh, getting close to 18 years now. That's not a bad amount of time for something to stop the bots.
The sooner geek admins start to understand that there is NO perfect security, ever, the sooner we'll start to have better computer security.
Very few (Score:5, Interesting)
We're running a network of 80+ servers around the world (https://wonderproxy.com).
We've moved in stages getting things off standard ports.
Whole network standard - several hundred attempts per day
a few standard, rest on non-standard ports - tens of attacks per day
all non-standard ports - 0-5 attacks per day.
It's been worth doing just for the reduced reporting volume in our status systems.
Re: (Score:2)
VPN (Score:4, Interesting)
I thought all the cool kids put machines behind firewalls then SSH after connecting to the VPN.
Re: (Score:2)
Because that's two steps instead of one.
VPNs are no more secure than SSH, just make SSH as secure as you need it.
My god, they've discovered nmap (Score:2)
Paging Captain Romero - of course you will get traffic on high ports - there's only so many available to try. Moving your ports around just delays the inevitable and culls out the lazy.
Re: (Score:2)
Making them scan for open ports wastes exponentially more time than just automatically hitting 22, and exponentially more than that if their scanner checks response types on open ports to see if 666 really is a Doom server or is that where ssh is hiding. As others have mentioned, it’s not about security so much as making things less convenient for attackers.
Re: (Score:2)
No, not "exponentially". A fixed constant factor higher in fact.
Let's not use up the art terms until we mean them. Adding a port-knocking *sequence* before access could get you into exponential territory.
Rgds
Damon
Re: (Score:2)
A fixed constant factor higher in fact.
Not even fixed constant factor. Rather, a fixed constant term (additivie constant, rather than multiplicative). Indeed, once the attacker has found the ssh port, he can start banging his list of username/passwords at that port, and he doesn't need to repeat the port-search sequence for each username/password that he tries...
if you can log (Score:2)
Administrators group (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
You need two passwords to get root instead of one. Plus it is easier to assign blame because you know whose account was hacked, not just that the root password was lost.
Re: (Score:2)
The largest practical advantage is auditing in the case where you have multiple administrators.
Re: (Score:3)
What's the practical difference between being able to log in to root and being able to log in to a member of the sudoers group?
The attacker has to guess/discover a username in the sudoers group as well as brute-force the password space. If the attack is targeted, that doesn't help. If it's random, it can be a big help.
Rate limit and require keys on my VPS server (Score:2)
I have a couple of internet-facing VPS servers that I use, and I do ssh into them on a regular basis. But after a weak password let someone in, I re-installed and switched to requiring ssh keys. I also turned on simple rate limiting for ssh (I keep mine on port 22) connection attempts. I still allow password ssh logins, but only for connections originating within my VPN.
I haven't had very many problems with brute force attacks since. I'm still vulnerable to any ssh key-handling vulnerabilities that may
I would be interested in the success rate. (Score:2)
People, who configured their ssh to listen to a non standard port, are aware of a problem and probably at least a bit more knowledgeable than the average user. So I'd expect better passwords and maybe other means of protection. Does it really pay to try higher ports in comparison to the higher effort?
Re: (Score:2)
People, who configured their ssh to listen to a non standard port, are aware of a problem and probably at least a bit more knowledgeable than the average user. So I'd expect better passwords and maybe other means of protection.
Either that, or they're more interested in tinkering with stuff, changing things that don't need changing ... thus more likely to mess something up and leave a hole open.
Seems to me the problem is logs filled with crap, and the right solution is not to log failed PasswordAuthentication login attempts if you have disabled PasswordAuthentication. No idea if OpenSSH supports that.
SSHGuard FTW (Score:4, Informative)
I'll probably have to go learn about key-based security. But meanwhile, I'm really happy with sshguard. It defends against brute force attacks by monitoring logs and aplying increasingly (exponentially) tougher time-outs as attacks from IP addresses continue. It's reduced my log from 100s of entries per day to about 15. http://www.rferl.org/content/world-press-photo-winners/24903576.html [rferl.org]
They've got it in FreeBSD ports, which makes it easy to install into an existing firewall.
Re: (Score:2)
Great - copy/paste fail. That's a link to the Swedish journalist picture of Syria that got a prize. Here's the link for SSHGuard for the Google impaired.
http://www.sshguard.net/ [sshguard.net]
Glad copy/paste fail didn't betray any other links I've hit while surfing-the-net-and-drinking-whiskey simultaneously.
Comment removed (Score:4, Insightful)
iptables (Score:5, Informative)
If you want to end almost any possibility of brute force, load this with iptables:
Those three lines will slow the amount of connections by the same ipaddress to sshd. When the attacker reaches 4 hit counts it will be blocked for 60 seconds before resetting. If the attacker keeps attacking before the 60 seconds are up it will reset the the time limit to another 60 seconds. Have been using it for years and it is extremely effective. Even a botnet attack (which is unlikely) would be futile because there just aren't enough attempts.
Seriously, this type of thing should be built directly into ssh. If not this sophisticated, then at least it should include attempt and restart delays which would not be as effective but beat the hell out of the default behavior.
Re: (Score:2)
Given that there other, useful, general case workarounds for managing network traffic, this should NOT be built into SSH, rather the sysadmin should be clever enough to apply a general solution to his specific problem. Baking this sort of crap into every daemon out there is Microsoftian.
Most security IS security by obscurity. (Score:2)
From the summary: "It seems security by obscurity has lost the game once more."
I've got news for you. Most security IS security by obscurity. Think about it. If the attacker knew your password, account, IP address, certificates, keys, and combinations you would have no security.
Port knocking anyone? (Score:3)
Like others have said, moving sshd to a high port was never meant to be additional security, just annoyance-reduction to reduce the sheer load in terms of bandwidth and log space. I did that for a while, but then (well over a decade ago) I saw an article about port knocking [wikipedia.org] which is where you (i.e. the sshd) don't answer until the system receives a secret sequence of connection attempts at various ports... i.e. a secret "knock". The secret knock is a kind of password, and can be sent by executing a specialized client, or if you are somewhere where you don't have one available, by manually making telnet attempts, i.e. "telnet 16111; telnet 28123; telnet 22222".
The knock is basically a password for OSI network layer connections. This not only reduces the annoyance level of unsophisticated phishing attacks, but basically eliminates them altogether with a layer of real security. That security is not very strong... in a targeted attack, anyone who can monitor your link layer anywhere along a connection you make can see your secret knock... but it's an easy add-on and better than just playing tag with script-kiddies by moving ssh protocol to a high port.
FYI: iptables tutorial (Score:3)
iptables can be fantastically complex and powerful to protect enterprise networks from all manner of attack. It is also fast and easy to do a simple, basic, strong setup which will provide a powerful firewall to secure a server.
Some useful iptables tutorials and references:
1) From CentOS, but iptables runs the same way regardless of OS [centos.org]. This one creates a pretty solid simple iptables ruleset to protect a server.
2) An Ubuntu tutorial, again simple and informative. [ubuntu.com]
3) From the netfilter/iptables project homepage. [netfilter.org] Good primer on network concepts too.
4) Deeper information, but very useful. [frozentux.net] Another good discussion of network concepts.
I recommend typing in a simple text file with the iptables commands, the chmod'ing it so that it is executable. Then execute it ("./myrules"). This works for a small, but powerful list of rules that can protect a server. Some of the tutorials talk of rulesets with thousands of lines. There are different, more efficient ways to load those.
Quick overview of iptables:
1) There are three default chains (containers which sets of rules) called INPUT, FORWARD and OUTPUT.
2) Each of these can have a default policy of ACCEPT or DROP. Input should have a default policy of drop. IMPORTANT - while you're first playing with iptables, make sure input has a default policy of Accept ("iptables -P INPUT ACCEPT") or you may well lock yourself out of your machine. Once you've got the rules set up as you'd like (you view the rules with "iptables -L -v"), then you can do "iptables -P INPUT DROP".
3) Always set these three "housekeeping" or basic rules (prefacing with a '#' is a comment):
# For the loopback interface 127.0.0.1, accept everything. Append to input chain.
iptables -A INPUT -i lo -j ACCEPT
# For ICMP packets, accept pings only
iptables -A INPUT -p ICMP --icmp-type echo-request -j ACCEPT
# For established connections, accept everything, using the older state module
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
4) Your input chain, which deals with incoming packets, will have a default policy of drop. Only ports which are then specifically allowed will be open:
# Accept SSH on port 22
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Accept HTTP on port 80
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# Accept HTTPS on port 443
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
5) You're not using your box as a router, so your FORWARD chain should not get any activity. I leave the policy as Accept, so if there is any traffic logged here, I know something unusual is going on:
# Otherwise, accept all for FORWARD
iptables -P FORWARD ACCEPT
6) Finally your output chain should just allow everything:
# Accept everything:
iptables -P OUTPUT ACCEPT
7) Check your iptables ruleset with "iptables -L -v". If everything looks good, set your default input policy to drop with "iptables -P INPUT DROP"
And that is a spiffy, powerful way to block all ports but 22 (ssh), 80 (http) and 443 (https) by using iptables.
Not a problem (Score:5, Funny)
I'm running my ssh server on port 23¾ now; that ought to keep the muggles out for a while.
Re: (Score:2)
My defenses include:
Adding ALL : ALL to my hosts.deny
Adding the ranges I want to allow access to my hosts.allow
Denying root access
I'm also hoping to start using a Yubikey for password authentication, just waiting for my hardware token to arrive in the mail.
Re: (Score:2)
And yes - most of the hack attempts I'm seeing are coming from China
Re: (Score:2)
Correction: most of the hack attempts you're seeing appear to come from China. I expect it's likely most of the attacks would come from botnets, which thrive in China thanks to the high adoption rate of pirate software. The actual hackers could be anywhere.
Re:Security by obscurity ... (Score:4, Insightful)
We are talking about banning ranges of IP addresses. Only the last leg of the journey matters. Saying the attackers aren't in China is a difference without distinction.
Re: (Score:2)
Agreed.
Re: (Score:2)
Denying root access
I'm also hoping to start using a Yubikey for password authentication, just waiting for my hardware token to arrive in the mail.
"Yubikey" looks very interesting. I have been thinking about two-factor and OTP hardware to increase my security, but I wasn't aware of actual implementations that worked for Linux.
Re: (Score:2)
Re: (Score:2)
We have them for work, but they are only firmware 2.1 so you can't use them for Windows authentication
I do security by antiquity (Score:5, Funny)
You see, I don't use SSH, I use plain old telnet. That's right! These kiddies never heard of it!
And if they actually get in, I have a few gigabytes of stories growing up that they have to read. Like the time I was growing up in Idaho. We wore onions on our belts because that was the style back then, Benny Goodman was all the rage and I'd take my best girl - Betsy - to the church dance ... we were all Presbeterian in that town and with one church, new people would just go there - even the Jews because there wasn't a Synagogue - but that's another story and I won't bore you with that because I can be a bit long winded at my age - so anyway my best girl got her new dress and we over to the next town to Jo's soda shop - he had the BEST malts in the entire area - and the whipped cream was made fresh from a local dairy farm - farmer brown's was his name - he served in WWI as an infrantry man in France and boy the stories he told about those French girls - like the one he met, Jaquoline I think or it was Juliette - she had dark hair and hazle eyes and her father was a banker for a German who had a home in France before the war - of course when the war started the Germen businessman had to run home and he ended fighting himself, even though his father pulled some mighty strings to get him out of the German army ...ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
Re: (Score:3)
Re: (Score:2)
How so? You lock up an account after a few password failures. Why would it matter where the attempt is made. They'd have to try getting in with other accounts.
Re:Just lock em out... (Score:5, Insightful)
Re:Just lock em out... (Score:5, Funny)
Back at university someone would always use this one lecturer's five login attempts up at some random time once a week. I wonder what large companies do to prevent disgruntled employees trying to log in as steve.jobs or bill.gates and DoSing them every day.
Re: (Score:3)
I wonder what large companies do to prevent disgruntled employees trying to log in as steve.jobs or bill.gates and DoSing them every day.
Quite simple really. They will find the disgruntled employee, and fire him.
Re: (Score:2)
Thereby turning a nuisance into a DoS.
...and watch them lock YOU out (Score:2)
You lock up an account after a few password failures.
Which opens up a denial of service opportunity for anyone who can guess the primary administrators' usernames: the botnet could log in with an incorrect password several times to lock out the legit user. Cue a truck roll to reset the lockout.
Re: (Score:3)
"That'd be quite effective against a single host, but much less effective against a botnet of thousands, each of which gets their quota of 5 tries..."
I disagree with that. Assuming an attacker controls one million bots which is a reasonably big botnet (the largest known peaked at 30 million). That only give him 5 million tries to guess a valid login/password pair. But let's assume, the attacker already knows the login.
Where do you start? There is about 1 million words in the english language. So a simple pa
Interface for specifying approved IPs (Score:2)
Then only allow the IPs you want to connect.
So how do you predict the IP address of the machines from which you will be connecting in advance? If you expose a web interface to edit the list of allowed IP addresses so that you can connect from an additional IP address, all you've done is added the length of that web interface's password to your SSH password.
Re: (Score:2)
To specify which IPs are trusted IPs (Score:2)
I'm not sure where your Web access brainstorm comes from but it has no place in a security strategy of default deny. Default deny is very very simple. Either you are a trusted IP or you aren't.
The web access part is the interface to specify which IPs are trusted IPs at the moment and which aren't.
Re: (Score:2)
Use a VPN..
Re:The length of the VPN's password (Score:4, Informative)
So your saying a 32 char password is better then a 16 char password, whoda thunk it.
Or, to rephrase that, all you've done is make it 500 trillion times harder to crack your ssh (if you're using good passwords), if you are using keyfiles for both then there pretty much needs to be a remote exploit in both the listeners.
Re: (Score:3)
You regularly connect via SSH from random IPs?
Your phone doesn't have a static IP, neither does a hotel or a random customer whom whose premises you need to quickly fix something. Or aunt Judy, if shit happens to your home server while you're away.
Random IPs in China?
You usually recall you've set up such blocks when you're already on your business trip you didn't expect 5 years ago.
And looking at my logs, they use botnets anyway. Heck, among 37 distinct IPs from today on one box, I see even a pwned IP from Vatican.
Home server? Not everybody has that luxury (Score:2)
I always have my home server available on a fixed IP
Not everybody has the luxury of 1. a home server and 2. an ISP TOS that allows a home server. And even in your case, all you've done is added the length of your home server's password to your SSH password.
When an attacker controls 10,000 IPs (Score:5, Insightful)
An attacker can only try logging in a few times a minute.
How does your system determine which IP addresses belong to a particular attacker's botnet?
In Russia, attacker locks YOU out (Score:2)
Don't most people use attempt limits now?
See replies to macbeth66's post asking the same question [slashdot.org].
Re: (Score:2)
Re: (Score:3)
Upon 10 failed attempts on a given account, drop them to a fake shell prompt and log them. Put the longest or most entertaining logs up on a public web page for mockery.
Also known as "how to increase CPU and bandwidth usage on my server tenfold". It's like answering positively to a telemarketing call just to waste their time. It might seem like fun, but your number goes on a suckers list.
Re: (Score:2)
Re: (Score:3)
2222 is the worst alternate port you could use, that's probably the second port a multi-port brute-force script will try after 22.