Newbie - what to do about huge number attempted ssh logins
 

Lastb often shows me a huge list of attempted ssh logins.
Such as this excerpt:
Is there something I should do about them?
I'd like for logwatch not to have to send me such a huge report.

I think I can put something in /etc/hosts.deny but I'm sort of lost in the man page. Can you please tell me exactly what line to put in hosts.deny for the example above? (Currently /etc/hosts.deny is empty). And am I right in thinking that would prevent them from getting logged?

will make SSHD refuse connection attempts.

You should run DenyHosts or Fail2Ban to do this automatically.

You can also limit the users (or groups) that can use SSH as well as forcing the use of keys instead of passwords.

If you just want to reduce the clutter in your logs, run your SSH daemon on another port. I have my external SSH on port 443 now because the proxy at one the sites I work at won't allow connections to anything except ports 80, 8080 or 443. A side effect of doing that was since most port scans only check port 22 for SSH I now get no attempts to access my SSH server. Please note, that's just convenience, not extra security :)

You could also throw a few rules on your firewall to disallow an IP after a certain number of attempts during a specific time period:

With these, any IP address that has tried to log in 4 times in the last 2 minutes gets dropped. Since I've got a low-usage server, I've found this to be less hassle than fail2ban or DenyHosts.

Interestingly, I've found that the number of attempts has dropped precipitously. There is the occasional clown who has tailored their attack so that it evades something like this, but that is rare. By the way, a big thumbs up to folks at Codero. I was getting pestered by one of these slow rollers, complained to them since it was one of their IP addresses, and they actually did something about it. Never had that happen before.

You could also read the sticky ( fifth thread ) on the LQ "Security Forum" which is titled "Failed SSH login attempts" and has an interesting discussion about how to prevent them becoming annoying.

Thanks, everyone. Hangdog42 I'm trying the iptables - seems a lot simpler than trying to install DenyHosts or Fail2Ban (extreme newbie fearful of breaking the server and having to crawl to host Support).

I agree you should read the sticky Failed SSH login attempts thread before deciding what to do and note using /etc/hosts is not your best option. You run a dedicated Centos-5.5 server with a forum. Overcome your fear of b0rkage by gathering knowledge and experience, enabling a backup scheme (you do make off-site backups do you?) and creating a staging server at home or work (virtualization?) to test things before moving it to your production environment. Taking the easy way out will eventually lead to the worst possible "solution".

unSpawn this is of course good advice.

I backup the database with mysqldump and tar.gz the public_html every day. The backup files are copied to another server (shared) and also to my PC. I wrote a script to make my backups and scp to other server but so far haven't succeeded in getting it to run as cron job, so I run the script manually every 11:00 PM.

No clue how to make a staging server or how to back up anything other than user accounts (via DirectAdmin).

I had already read 'Failed SSH Login attemps' as part of extensive googling. It says "Access restriction can be done using iptables or tcp_wrappers (hosts.allow/deny)" so I figure iptables is ok for starters?

yum install doesn't find DenyHosts or Fail2Ban so I guess I would download (via rpm?) first and then run yum?

Part of my overall hesitation is because my host's techs login as root every so often and I don't want to accidentally block them. I don't know all the names. There is just one of them in /home/ at the moment.

Edit: Doing the iptables thing seems to have been remarkably successful so far - no attempts for the last two hours.

Ahhh, good!


Feel free to create a separate thread in the Programming or Newbie forum to get that issue fixed.


Install VMware server (freely installable), Virtualbox or whatever else equivalent and you have the basis to run a "guest system" on. From there on it would just be a regular installation except for the fact that you won't be using a complete machine or disk but files on disk. The benefits of using virtualization are numerous: nearly error-free (restore a snapshot and try something again), portable between machines, quick(er) boot-up (suspend mode), relatively safe (host isolation), can run with any type of network configuration (bridge mode, host-NAT, isolated LAN), et cetera, et cetera.


I've addressed that in your other thread.


While web-based system management panel software can streamline operations they also force you to accept what procedures they offer, they often are opaque in how they address or change things and they often will not show the level of detail and control you get from hand-editing a set of configuration files. While some have grown accustomed to (graphical) interfaces that provide interactive clues, help, and warnings some people have come to depend on them for the wrong reasons, like allowing them to perform operations w/o having to read any documentation at all. That's why I maintain that using web-based system management panel software is no substitute for theoretical knowledge and practical experience.
(@all: any DirectAdmin experts in the house?)


Good. Iptables is OK as long as you know what you're doing. 'You search fail2ban' should return "fail2ban-0.8.2-3.el5.rf.noarch" if you have the RPMForge repo installed and enabled.


That's probably pure laziness. Nobody should need to log in as root. Log in over SSH as unprivileged user with pubkey auth then use Sudo.


Cool!


* Also it's time you know issues on LQ should be split up wrt their topic. Anything that touches on security remains here, backups, server configuration, distribution-specific issues, et cetera should be split off or see new threads created in their respective forum.

Thanks again, unSpawn.

I think this is a security thought:

I really don't like the way my host logs in as root.
This looks as though they log in as root over SSH from some PC.
Which I have read is a very bad thing to do. I no longer do it myself. What I do is SSH in as [SOME_USER] and then do SSH [ANOTHER_USER_AT_SOME_HOST], using public key arrangement.. I figure that is OK as it is within the same server, and is better than su because with su the password goes over the PuTTY connection.

Nothing I can do about my host, though.

My iptables blacklisted my own IP!

All straightened out with the aid of hosts's Support. I think it happened because I had four sessions running in 'screen'.

I like the iptables thing but I have temporarily removed it with 'iptables -F AUTOBAN'.
It was made with
Before I put it back:

Is there a way to keep iptables from blacklisting me?
And, is there a way to un-blacklist an IP?

I have done further research. Actually I don't believe iptables blacklists? it just drops?

It was DirectAdmin that added my IP to their blacklist. I have put myself in DirectAdmin whitelist.

Try adding this before the AUTOBAN section and replace XXX.XXX.XXX.XXX with your actual IP address.

Yes, it just drops and it should stop dropping after a few minutes. As soon as you have fewer than 4 connection attempts in a 2 minute period, that rule shouldn't be enforced. I'd be surprised if screen was causing the drop because the multiple screen sessions are being run over a single SSH connection. As far as I know, iptables shouldn't even know about the screen sessions.

Looks like it, yeah.


SSH'ing to root requires the root account to be enabled. Bad. When you SSH in the first time the connection is encrypted already.


You could ask them? If they can agree to use public key auth and a fixed set of management IP addresses or IP ranges then you could use iptables to limit access (plus port knocking?) plus set a "from=123.456.789.*,456.789.123.*,789.123.456.*" limit on the public key in authorized_keys. That's still bad but at least then you've tried to mitigate the situation.

* BTW I've cleaned up offending IP addresses and account names. There's no need to disclose that kind of information wrt a Live server.

Sorry, I don't know what you mean about "SSH'ing to root requires the root account to be enabled. Bad. When you SSH in the first time the connection is encrypted already. "

How would a person log in as root if root wasn't enabled? You've lost me. And are you saying that su root is better than SSH root?

Also, not a chance my host will change their ways. Support is good but not real communicative and not generally hand holders. All contact is via problem tickets.