Is this a virus or script kiddie trying to find a weakness in my ssh?
Have you people seen anything similar? I think I am pretty secure:
I keep my system up to date Dont allow root to access ssh Only one specified user can access ssh Passwords disabled (Only certificate) Added this ip to hosts.deny Code:
debby:# cat /var/log/auth.log |grep invalid |grep 201.234.230.18 |
If that log didn't convince you then neither http://www.dshield.org/ipinfo.html?i....18&update=yes will.
|
http://www.linuxquestions.org/questi...tempts-340366/ - last sticky on the top part of these forums!
|
@ unSpawn
Thats a cool page should I bother contacting the admin with that log or not worth it? Also what change did you make to my post so that its now more readable (So I dont repeat my mistake) @unixfool I did see that post although its pretty old (from 2004) I am finding this security stuff interesting, maybe there is a future in it :) |
Quote:
Quote:
|
What he said :-]
|
Best bet is run ssh on a non standard port, it will at least keep the bots out. also isntall fail2ban and test. 10 strikes and IP gets banned for a few hours.
I had on of my home servers hacked this way, was internet facing and never gave thought to it but ssh has no brute force protection built in (which is retarded since it should) so after weeks, perhaps months, a virus was trying to brute force and eventually guessed my username/password combination. Fail2ban will catch this then ban the IP. |
Quote:
|
@Red Squirrel
I cant change the default port otherwise my work network doesn't let me out at least on the other ports I have tried so far. It looks like having a firewall and not allowing anyone but the user you need to logon and only allowing logon with certficates its pretty good at least against brute force attempts like what I and lots of others seem to be seeing from malware and scripts. |
Quote:
Just a word of advice that such ban tools as fail2ban or denyhosts isn't cutting it anymore... |
Quote:
Even after years of people screaming at the top of their lungs to use good passwords, in 9/10 systems I end up examining after a break in I can find a bad password in <30s using a password cracker that was used to gain initial access to a system (usually a joe (username, name, either forward/backward), common dictionary word (money, computer, monitor, etc), or sports team (eagles, dolphins, browns, mets, etc.) Letting the cracker run for a few days will pick out all the common ones even written in leet or with numbers attached. Every password should be a MINIMUM of 8 chars (realistically much longer), contain no words even modified, contain symbols, numbers, never be duplicated on multiple systems, and should also contain a mix of upper and lower case letters. |
Quote:
http://isc.sans.org/diary.html?storyid=4045 http://cipherdyne.org/blog/2008/03/t...-attempts.html |
IMHO, you should not use password authentication at all. Use pubkey authentication. The instructions on the changes to /etc/sshd_config are given in the comments just above the "UsePAM Yes" line.
If you run Windows at work and use putty for ssh, the putty keygen program can generate the keypairs you need. Then load in your key, and at the top, an openssh version of the public key is displayed. You can cut and paste this text to produce a public key to add to the server's authorized_keys file. Do this before disabling password authentication. Keep the old ssh session open after the changes and test it from another terminal. Be sure to passphrase protect your private key (on the client). Passphrases are typically longer than passwords but can be a lot easier to remember. If you login to different servers or several times during a terminal session, you can use ssh-agent and ssh-add to store the passphrase securely in memory. The next time it won't be needed to enter the passphrase. Remember that the private key is used on the client. If you were to loose it, without a passphrase, it would allow someone else to log into the server. Unixfool: One thing you might try is something like fail2ban, that bans an IP if certain ports are scanned just once. Your iptables rules could log attempts on certain ports you aren't using such as telnet or smtp. A cron job could scan the log and modify hosts.deny or add iptables rules. This is similar to fail2ban, but the iptables rule is simpler. A similar technique is to reserve certain IP addresses in you subnet for a dead-zone. An IDS could be configured to watch for attempts on these IPs which indicate that someone is scanning the network. For important fixed IP addresses on a local ethernet segment, consider using "arp -s" or "arp -f" to fix the mac addresses to known permanent values. This can help protect against arp poisoning by a compromised host or a jack box on the lan. |
Quote:
I'm not trying to be rude, really, but have you guys read the above posts and URLs? |
Quote:
Lets take a quick step into the realm of the absurd just for comparison sake... Lets assume there are 5m distributed hosts, they know your account name, your machine can take the traffic and load (heh) from the attempts, and your fail2ban is setup for 10th attempt is banned. That equates to them making ~45m c/h. That is just about equal to having a password cracker running at about 15k c/s (my servers average) locally (54m c/h). Do the math on how long it will take them to figure out your 16+ character unique password of mixed case, numbers, and common symbols. It's completely absurd. The chances of a remote exploit on a daemon, hell on ssh itself, are far higher than your password being broken *IF* your password is good. Don't get me wrong, I'm not saying you shouldn't take additional precautions, but the first precaution taken should be a strong password if the system has to be accessible from the outside via passwords, because without it, the rest of the protections are just offering a false sense of security. The better solution is to use passwords in conjunction with keys... but that can be problematic in some situations. |
All times are GMT -5. The time now is 04:16 AM. |