Coping With 1 Million SSH Authentication Failures? 497
An anonymous reader writes "I own a small Web development studio that specializes in open source software, primarily Drupal, WordPress, and Joomla for small businesses. Our production servers, which host about 50 sites and generate ~20K hits/week, are managed by a 3rd party that I'm sure many on Slashdot would recognize. Earlier today I was researching some problems on one of our sites and found that there have been over 1 million SSH authentication failures from ~1200 IP addresses on one of our servers over the last year. I contacted the ISP, who had promised me that server security would be actively managed, and their recommendation was, 'change the SSH port!' Of course this makes sense and may help to an extent, but it still doesn't solve the problem I'm facing: how do you manage server security on a tight budget with literally no system admin (except for me and I know I'm a n00b)? User passwords are randomly generated, we use a non-standard SSH port, and do not use any unencrypted services such as FTP. Is there a server monitoring program you would recommend? Is there an ISP or Web-based service that specializes in this?"
fail2ban (Score:5, Informative)
fail2ban, key-auth
Re:fail2ban (Score:5, Informative)
> fail2ban, key-auth
+1
Change port. Use iptables to only allow access from known subnets/hosts.
Re: (Score:3, Informative)
And use DenyHosts [sourceforge.net]
Re:fail2ban (Score:5, Insightful)
This is really cool until you find yourself trying to log in from the same access point where somebody with a virus was attached earlier in the day. Better to just use crypto (key-based authentication only) and rate-limiting.
Re:fail2ban (Score:5, Informative)
proactive blocking (Score:4, Informative)
In addition to using reactive tools like fail2ban and denyhost, also block most of the world proactively:
git clone git://github.com/bugi/iptables-by-country.git
Re:fail2ban (Score:5, Informative)
fail2ban firewalls off the port for a time you specify
DenyHosts blocks the ip in /etc/hosts.deny
I find fail2ban to be much more effective since I can use it for more than just SSH (on my system: ftp, imap, pop3, ssh, smtp). Some of the newer botnets will attempt to crack the password using another service and then try the resulting password on ssh so it's important to have more complete coverage.
Re: (Score:3, Informative)
More accurately it blocks the attacker's IP at the firewall.
Re: (Score:2, Informative)
Install OSSEC, too. There may be other stuff going on.
Re:fail2ban (Score:5, Funny)
Someone fucked up big time when they taught you html:
[url]http://www.fail2ban.org/[/url]
hashlimit (Score:5, Informative)
You can also use the hashlimit module for iptables. I find it works pretty well for allowing people in who need to access and block things like the ssh worm that was causing ssh to run out of resources.
You might check out the end of this presentation that I made 4 years ago.
http://www.bloomingtonlinux.org/wiki/15th_meeting [bloomingtonlinux.org]
I've been using hashlimit successfully for years in a web hosting environment.
I'd also recommend hiring someone who focuses their efforts on managing the servers and taking care of network security. This job is usually referred to as a system administrator or network administrator. DOH!
Re: (Score:3, Insightful)
That's probably the most relevant thing I've seen. I'm amazed at how many places don't want or have people with a clue working on their equipment. TFA said they have *NO* sys/net admin, and the guy who attends to those task is a "n00b".
There's more than one way to address th
Re: (Score:3, Insightful)
"I'd also recommend hiring someone who focuses their efforts on managing the servers and taking care of network security. This job is usually referred to as a system administrator or network administrator. DOH!"
Quite to the point. There's a rising trend on questions like "I'm having problems about X but I prefer being cheap on coping with X, what should I do?". And then there's the rising trend on answering something else than "if you depend on X you'll need to invest on X".
And now, about the problem at h
Re: (Score:3, Interesting)
good against 1 attacking host -- not large botnets (Score:3, Insightful)
I am using fail2ban, but I do not think it's a particularly great tool when you see how many different IP addresses the attacks come from, so you're somewhere stuck in the middle trying to optimise how to make fail2ban more effective, while not being a problem for your own users:
- you configure blocking from 1 login attempt and a long block time cuts down on most of the outside attacks, but if some legitimate user mistypes his password, he'll be locked out for that same long block time...
- you configure sev
Re:fail2ban (Score:4, Funny)
Because it your production server is *nix, you are probably *already* running a shitload of random scripts written by unknown cunts ?
Re:fail2ban (Score:4, Interesting)
Nobody's going to guess a 2048-bit RSA key.
No but they can steal if from your users' computers. It's one thing to have staff use keys when they are on your secure network but having users who are out on the web using keys when you can't control the security on their machines is only as secure as your dumbest client. Of course if they can hack and steal keys, they can probably steal passwords as well. For remote access one of the securest ways is using a security token. Every time user logs in they have to enter a different number.
Re: (Score:3, Interesting)
Nobody's going to guess a 2048-bit RSA key.
http://ftp.de.debian.org/debian/pool/main/o/openssh-blacklist/openssh-blacklist_0.4.1.tar.gz [debian.org]
If the 2048 RSA key is one of these they probably will, get it, especially if they have a million chances.
Re: (Score:3, Insightful)
Because stealing RSA/DSA SSH keys is so much more common than dictionary/brute attacks...
Re: (Score:3, Interesting)
"Because stealing RSA/DSA SSH keys is so much more common than dictionary/brute attacks..."
You seem to forget that if you are seeing those attack levels is because of user computers already rooted, so anything on the client's side it's already at the attacker disposal. What do you prefer? Seeing thousands of failed login attempts in your logs or not seeing anything because the attack succeded by taking control of the ssh keys on the client's machine?
Re: (Score:3, Interesting)
The best authentication relies on two factors, what you have and what you know.
A rooted client gives the attacker access to at least one part of that.
A separate physical RSA token is probably the only thing to prevent that, since they work without being attached to the authenticating system and even full scale keylogging monitored by a squad of hackers in rotating shifts will not really suffice.
Hardware firewall or use bfd (Score:3, Informative)
Tar Pitting (Score:5, Informative)
I'm a big fan of tarpitting SSH connections myself. It dramatically cuts down on the repeated ssh attempts, and keeps my logs much cleaner.
Basically, an iptables rule:
-A INPUTCHAIN -m state --state NEW -m recent -p tcp --dport 22 --update --seconds 30 --hitcount 4 --rttl --name SSH -j DROP
Re: (Score:2, Informative)
Fail2ban [fail2ban.org] can do stuff that automatically!
Re:Tar Pitting (Score:5, Insightful)
Let me see if I have this right. If iptables can keep count of incoming connections within the kernel and drop incoming connections as they happen without any intervention from a userspace program, that's _not_ automatic.
But running a gigantic shell script to scrape text messages out of your system logs and then call randomly chosen commands which may or may not have any effect on the observed problem some time after it occurs, then that's "doing that stuff automatically"?
Maybe those words don't mean what one of us thinks they do.
Re:Tar Pitting (Score:4, Informative)
Re:Tar Pitting (Score:5, Interesting)
I use a variation on tarpitting that has worked very well for me.
It cut the attempts down from 60,000/day to 20 or 30 per day.
I just add a small delay between the initial connection attempt
and when I send the username/password prompt. The delay (in
seconds) is the number of attempts in the last 30 minutes,
squared. This makes all but the most determined attacker
give up and go away very quickly.
I have been using this with both FTP and SSH for the last
year, and it works great.
Re:Tar Pitting (Score:4, Interesting)
Re:Tar Pitting (Score:5, Informative)
Any site that connects more than 4 times in 60 seconds gets all packets subsequently dropped.
You could change DROP to TARPIT (if your kernel supports it) to fuck with them a little more.
Re:Tar Pitting (Score:4, Interesting)
But what happens if you call scp from a number of scripts in parallel? You will get banned?
The problem is that you want to act only on the failed login attempts.
I love it! (Score:2)
Re:Tar Pitting (Score:4, Funny)
Incidentally, I would quite like to know how this AC went about implementing this.
He'll be back. He has to wait an hour before being able to log in again.
Re: (Score:2, Insightful)
Re:Tar Pitting (Score:5, Insightful)
That, and create only a single user who can log in, that takes you to the real log in prompt. That way an attacker has to guess the one user+password, and have a legitimate userid+password to gain access.
It's not foolproof, but it foils the vast majority of script attackers.
And DISABLE ROOT LOGIN!
sshblack (Score:2, Insightful)
sshblack works very well for me. It monitors failed ssh connections and inserts entries into iptables to block the IPs.
use openvpn ? (Score:2)
Passwords? (Score:5, Informative)
Here's my excuse to ride my usual hobbyhorse about passwords being obsolete. SSH supports certificate-based authentication, which is not only more secure, it's less of a hassle for the user. Don't know if it would be practical for your application (you might tell us more about that) but it's worth a look.
Re: (Score:2)
Re: (Score:2)
I agree with both parent posts. PKI Certs are certainly the way to go, but it's really hard to do this right.
This is a case where some consulting to (a) set up the PKI stuff; (b) train our (unfortunately anonymous) questioner on how to disseminate the certs; and (c) apply the appropriate tarpit/other firewall settings, would probably be money-well-spent.
Re:Passwords? (Score:4, Interesting)
fwknop (Score:5, Informative)
Re: (Score:2)
I agree completely. We use fwknop as a part of a required two-factor authorization scheme for a US Government customer. It is a minor inconvenience to use it to open the ssh port before connecting, but it virtually eliminates attack attempts. How can you hack a closed port?
You are being brute-forced (Score:4, Informative)
Welcome to the internet -- this happens to every site with a public IP.
First off, do not change your SSH port. It won't do a whole lot for you, and it will be more hassle than it works.
There are a whole lot of programs available to deal with SSH brute forcing. sshguard is one of them, and it's not too bad (you can apt-get install it). It's a bit of a hack -- it just watches your logs and takes appropriate action -- but it does work.
The other thing you can do immediately is simply turn off password authentication in ssh. Anyone getting in will need a key. This is what sourceforge and github both do. This isn't always practical for every site, but it will damn sure keep your passwords from being brute-forced.
Never passwords! (Score:2)
Use public key authentication. It's super easy and much more secure, unless your random passwords happen to be over 300 characters long (ssh-keygen makes 2048-bit keys by default; assume 6 bits per character in a random password if each character is in the base64 set). Also, sshguard is your friend. After a small number of invalid logins - 4 by default - that IP gets firewalled for a short period of time.
Fail2ban or denyhosts (Score:4, Informative)
SSH public key authentication (Score:4, Informative)
Re:SSH public key authentication (Score:4, Funny)
The simplest way is to drop SSH and just use telnet. They won't be expecting that!
Fail2Ban (Score:2)
If your not willing to invest money into intrusion detection, vulnerability scanning, or moving to a more responsive provider, accept that your server is going to constantly be scanned by the droves of script kiddies out there throwing everything but the kitchen sink at any server that responds to a ping and keep monitoring those logs, which hopefully are stored on a separate server in case you are ever actually compromised. In the mean time, try installing Fail2Ban on your server. It will block an IP addre
Spend more than 10 minutes? (Score:3, Informative)
Seriously. I'm in the same shoes and it's easy. I came across it pretty quick and all these SSH log in problems went away.
Check out...waaaaait...
What's most troubling is this:
I own a small Web development studio that specializes in open source software, primarily Drupal, WordPress, and Joomla for small businesses
You operate a business and you haven't figure out this chief problem yet...but you want us to help you out?
Well...Here's the solution: denyhosts [sourceforge.net]
Someone else'll chime in with it....Just hope you read up and configure it properly....or you'll find yourself locked out of your own servers.
Re:Spend more than 10 minutes? (Score:5, Informative)
DenyHosts (Score:2)
Great tool that pools the resources of multiple servers to proactively block IPs that are trying to brute-force the SSH port on any server in the pool:
http://denyhosts.sourceforge.net/ [sourceforge.net]
I use it, and it has Just Worked for years.
So? (Score:5, Interesting)
If you really have secure passwords, the random guessers aren't going to get them. Log it and move on.
I get thousands of Chinese hackers attempting to break into the battery monitor in my tool shed, big deal. I don't know why my battery voltage and solar current is so important to them, but they can knock themselves out all day.
If the logs bother you then install fail2ban and configure it to lock people out after a few bad guesses. (Then be ready to unlock yourself from an alternate IP when you inevitably lock yourself out.)
Re: (Score:3, Interesting)
Move to a higher order port and use denyhosts (Score:4, Informative)
I use one or more of these on my public facing servers.
1. Move the default ssh port to a higher order port (5000+)
2. Use Denyhosts http://denyhosts.sourceforge.net/ [sourceforge.net] to block repeated attempts
3. use key exchange instead of username/password
4. use network based IPS.
Just moving the ssh port reduced the ssh brute force attack for me. Either stop being a noob or hire a sys admin.
Re:Move to a higher order port and use denyhosts (Score:5, Funny)
1. Move the default ssh port to a higher order port (5000+)
Agreed. The higher the better. For the ultimate in security, I recommend 65536.
Re: (Score:3, Insightful)
You are assuming they are actually attacking your computer.
They are not. They're stupid bots. Poorly written stupid bots.
They do not do portscans, at least not of random ports. They do not attempt to find ssh elsewhere.
I swear, I keep having this idiotic discussion. Have it about spam too. 'But why would you block email servers that don't appear to understand the SMTP protocol? Spammers can just write better servers.'
We're not trying to block hypothetical attacks. We're not trying to stop hypothetical t
Re: (Score:3, Insightful)
I used to feel the same way. But really, moving the port lets you focus on the real threats.
Look at it this way: if you are being targeted with a sophisticated hack, any dangerous attempts to log in to port 22 will get lost in the massive amount of bot traffic. But if your SSH server is on port 12344, then the reports in your logs will be more meaningful. You'll know that someone was conducting real reconnaissance and you can start worrying. There's no reason that you can't change the port as well as r
Re: (Score:3, Insightful)
Re: (Score:3, Interesting)
Changing the port might be troublesome if you're trying to SSH from public locations like airports and such. They usually leave port 22, 443 and 8080 open for their own services and block all others, so you will have to either set up VPN to get into your servers or wait until you're elsewhere. Additionally, an evenly-slightly determined hacker can still find where your sshd process is listening on by running a basic nmap scan.
Key exchange and disabling root login is probably the best way to go. Fail2ban wor
BlockHosts (Score:3, Informative)
We started using BlockHosts to feed iptables rules, and our failure logs went from 30-50k per day to 100. Basically, with more than 'x' failed logins within 'y' time frame, the source IP is blocked for 'z' time period. Since it uses iptables, you could block it from just the ssh port, or the entire system (we do the latter).
All three variables are configurable, and we also have whitelisted a few select standby IPs for contingency use. (As another poster said, you **will** lock yourself out eventually.)
Throttle Inbound Connections (Score:5, Informative)
I have a similar situation and cannot limit to very specific IP ranges. I have done the following with good success. I pulled some examples from my configuration that can be tweaked for yours if you like.
1. Limit incoming SSH attempts to a low number. In my case I limit to 2 connections in 60 seconds. I can tighten it even more but this did a lot to kill brute force attempts.
iptables -I INPUT -p tcp -i vlan1 --dport 2242 -j DROP
iptables -I INPUT -p tcp -i vlan1 --dport 2242 -m state --state NEW -m limit --limit 2/min -j ACCEPT
iptables -I INPUT -p tcp -i vlan1 --dport 2242 -m state --state RELATED,ESTABLISHED -j ACCEPT
2. Automatic blacklist via DenyHosts. This helps cut down attempts from known ranges without even giving them the chance even at a slow rate. http://denyhosts.sourceforge.net/
An iptables recipie (Score:5, Insightful)
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH --rsource -j LOG --log-prefix "SSH_brute_force "
-A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH --rsource -j DROP
Stops 'em *somewhat* dead. If you want to whitelist hosts so they are not impacted by this rule, just add;
-A INPUT -s your.ip.address -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
Before the throttling ruleset.
fail2ban (Score:2)
http://www.fail2ban.org/wiki/index.php/Main_Page [fail2ban.org]
That should cover automatic banning of repeat offenders. It works by reading logs, so it can work with many services. You could for example make it block all those attempting to exploit your CMSes.
OpenBSD PF (Score:4, Insightful)
you know what I am saying?
pam_abl (Score:3, Interesting)
http://lmgtfy.com/?q=pam_abl [lmgtfy.com]
Share and enjoy!
I don't understand the problem (Score:3, Interesting)
So there have been a million failed attempts to log in over SSH in a year. That's about one failed attempt every 30 seconds.
What's wrong with that? It's not like they're getting in, right?
That grumpy BSD guy (Score:2)
OSSEC is what I use (Score:2)
OSSEC [ossec.net] is what I've been using for years and it works well. IT's much more comprehensive a security package than fail2ban but uses log monitoring as it's basis.
It's worth a look.
Easy (Score:2)
Change the port and use private certificates for authentication.
However, changing the port to something will get the bots off your back. They still don't try other ports.
Change ports (Score:2)
Although the solutions like fail2ban and denyhosts are undeniably useful, you will cut down well over 90% of the drive-by ssh attempts by simply changing the port.
None of the scripts, that I'm aware of, actually portscan your machine looking for the SSH login headers, they all hit port 22 and try to log in. It takes too long to scan a machine so if nothing is listening on port 22, they will move on.
You will still get the odd attempt from someone who has portscanned you - these will be relatively rare. In th
Re: (Score:3, Interesting)
I actually go one step further: after IPv6-enabling my site, I only allow v6 ssh inbound. Since Teredo makes it possible to get v6 from nearly anywhere, it doesn't cause any inconvenience, and ssh attacks have basically vanished. 'course, it won't last forever, but it works great right now.
Enforce RSA keys and disable passwords (Score:2)
Working as intended. (Score:2)
And then just ignore the attempts. fail2ban can sometimes be ok, but be aware that it creates a denial-of-service vulnerability that is exploitable by attackers who can can spoof source addresses.
Re: (Score:2)
fail2ban can sometimes be ok, but be aware that it creates a denial-of-service vulnerability that is exploitable by attackers who can can spoof source addresses.
Yeah my server went off line a week ago and while debugging the problem I noticed the kernel complaining at startup that a file included from my pf configuration was corrupt. Its a script I wrote which updates that file, not fail2ban. The file was my blocked hosts table.
So from now on I am just going to put up with the dictionary attacks.
It happens. Deal with it. (Score:2)
Either learn to live with it, or at least take some steps to slow them down. I find that throttling back the number of connections any one IP address can make in a short time pretty much slows it down to a reasonable level. Alternatively, you can also put some "trap" logins on your system. Usernames lik
Do nothing (Score:2)
Wrong security concern. (Score:2)
I own a small Web development studio that specializes in open source software, primarily Drupal, WordPress, and Joomla
Right off the bat, you're far too focused on the security of least concern, ssh. Unless you set an idiotic password, it's not going to be guessed. It sounds like you have that covered.
But.. the part you've missed is your FAR more vulnerable applications. You say your ISP is "actively managing" your security, but how certain are you they're doing a decent job of it? Do they have experts
apply patches fastidiously (Score:2)
Somebody might want to check my math here...my stats are a bit rusty
Ok let's assume a few things:
1) your passwords are 8 chars long and use upper and lowercase alpha and numbers only
2) they are essentially random passwords that are NOT in the dictionary.
This would mean that there are 2^62 possible passwords in your password space. That's 4,611,686,018,427,387,904 possible passwords. The chances of guessing one password in that space within a million random tries is 1,000,000/4,611,686,018,427,387,904. Tha
Simples solution: Port knocking. (Score:2)
That should keep the CPU usage down, and your system secure from that type of attack. You can’t do much more than that.
You could run a script to find the owner of all those IPs... maybe do a bit of statistics to see what you can find out... But in the end it will be someone that you can not sue or contact in any way anyway.
SSH Key (Score:3, Informative)
Instead of generating passwords, have your users supply their SSH key and turn off passwords. Much better solution.
Lock it down. (Score:3, Insightful)
I can't believe the person who set the server up left this port open to the world. If you want the server secure then you will close all the ports that are not actually needed - in your case this likely means you keep 80 and 443 open.
For remote management make get a few IPs for the desktops that are meant to connect to it and make sure the ISP opens SSH port only to the IPs.
You can tunnel X over SSH and do file management, whatever you need so it should be enough.
Don't bother changing it to some random port, security through obscurity is total bullshit in this age of port scanners.
Re:whatcouldposiblygowrong (Score:5, Funny)
He could get trolled on slashdot by the very people he's coming to ask for help to become *less* of a noob.
I'll bet you teach your kid gun safety by shooting him in the neck.
Re: (Score:2, Insightful)
If somebody tries to perform surgery without a proper medical education, do you offer pointers, or do you tell them to drop the knife and find a real surgeon?
Companies running public-facing servers without good technical expertise are a menace.
Re: (Score:2)
Then the answer to the question is the link to someone who can provide that.
I doubt the responses would have been quite so hostile if the topic had been car repair - poorly maintained vehicles are a menace on the roads!
The answer does not necessarily have to be "here is what you do" - it can be "find someone who knows what they are doing". Trolling him is not likely to create any positive effect, except among the already insular server admin clique. Save the "oh my god, so this noob totally connected a 54-5
Re:whatcouldposiblygowrong (Score:5, Insightful)
That's a beautiful and witty analogy but to reverse it:
If he asked "How can I stop my house being burgled?" and you said, "Without a full alarm, CCTV and patrol system, don't even bother. Leave it to the professionals."
Some others might see some practical value in suggesting, "Maybe lock your door at night."
My opinion in this situation is first to take what advice you can and do something yourself as soon as possible (since any extra security is better than nothing). Next, as you suggested and when he has the resources to employ someone to do it properly, seek professional help. Simply doing nothing until he can do it properly sounds a bit dangerous.
Re: (Score:2)
Some others might see some practical value in suggesting, "Maybe lock your door at night."
The problem is there is no simple laymans advice like that that would solve his problem. He needs someone to fit new locks to his doors, etc not just turn the key in the door.
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
Since it seems to have escaped your attention, I'd like to point out the fact that unqualified surgeons can (will ?) kill people; unqualified admins won't.
Which seems to be a somewhat relevant matter.
Re: (Score:3, Insightful)
Practically speaking, it really isn't different.
The surgeon who kills someone might, if the victim's family is very lucky, be assessed damages of a couple million. An idiot with a cracked server farm can easily cause that much damage on the net.
WTF? In one case, a web server has been vandalized. In the other, a person is dead.
the web is new (Score:2)
when surgery was first performed, anyone could and did do it
to much suffering, yes
but you can't expect the regimented laws and well-established protocols of long experience with a brand new technology
and yes, the internet is STILL brand new technology
we are only beginning to see standards and laws and social changes from its appearance
as well as further technological change
you can't expect the standards you are asking for
Re: (Score:3, Insightful)
People without perspective are a menace.
Re:whatcouldposiblygowrong (Score:5, Funny)
Society places economic value on everything, and the amount of damage a cracked server farm can potentially do far outstrips the economic value of a human life.
You forgot to start that sentence with, "you might be a psychopath if..."
Re: (Score:3, Insightful)
I'm sorry you're too psychologically immature to recognize economic reality, but that's really not my problem, and hardly makes me a psychopath.
It's not a sign of being "psychologically mature" to hold the notion that human life is a fungible commodity.
A poor person in the slums of Bangalore is economically worth more dead (for his organs) than alive. You state that society places an economic value on everything, including people. Yet for some reason, society has outlawed murder, even if the result is a net monetary profit for society.
Your complete failure to comprehend that a human life is worth more than its economic value to society is why I cal
Re: (Score:2)
what could go wrong?
Lots.
worst case scenario?
Depends how realistic we are being with our range of possible scenarios.
Worst not-ridiculously-unlikely case: ill configured service, service minus important patches, or poorly chosen authentication/privilege setup, or something similar, allows an automated hack in and therefore the server becomes yet another bot in the net or possibly even a C&C box for the botnet.
A zombied server is usually more trouble for the rest of the 'net then a zombied home machine because they generally have access to bet
Re: (Score:2)
Yeah this is just normal for me. I have a script which hooks into syslog and blocks offending hosts in pf but frankly I don't think it is worth the risk of doing that. Make sure sshd has a secure configuration and don't worry about the brute forcing.
Re:Ignore it? (Score:5, Insightful)
1 million per year over 50 sites == 20,000 per year per site, or 54 per day per site. Change the passwords every few months (and use different ones for each site).
Further - 1,200 different remote hosts means what, 17 attempts per remote host per site per year. Probably randomly p0wned PCs that hit addresses at random, make a few attempts using default or ocmmon passwords, then move on.
Re: (Score:2)
Re: (Score:2, Interesting)
But a million cars haven't driven past. Only ~1200 --- in the past year. This is no big deal. Hell, I start thinking something is wrong when I DON'T see many failed SSH attempts in the daily log reports.
Re:Exactly (Score:5, Funny)
That's easy, just move the front door to where one of your upstairs windows is and install tiny robots that will draw the curtains if the traffic noise gets too loud.
Re: (Score:2)
Yep.. Port knocking is a great low budget solution to this.