1

I've secured SSH on my server (key authentication, no rootlogin, protocol 2, etc), but I'm a bit paranoid.

I cannot use some ip filter since I want to keep flexibility as to from where I can login myself.

I'm thinking about sending an email to myself when someone logs into my system using SSH.

However this makes me wonder:

Let's say I have the above implemented and I get an email that someone just logged in using SSH. And I know for sure it isn't me :) nor is it another admin.

What would be the appropriate response?

  • Bring the server down in panic?
  • Monitor what the malicious user is doing on the server?
  • Kick out the user?
  • Kill it with fire?
  • Something else?

PS

Server is Centos 5.7

EDIT

The server is used as a webserver (Apache/Postgres/PHP) and mailserver (Zimbra).

So I guess the data is mails and databases.

Improve this question
3
  • 1
    This has nothing to do with SSH and everything to do with incident response. Do you want to know how to improve SSH configuration or how to respond to an incident?
    – Alex Holst
    Dec 3, 2011 at 22:03
  • @AlexHolst: sorry for the mislabeling (hey I'm new here :) ). Fixed it. I would like to know how to respond to the incident, but the answer of ewwhite is also welcome. But incident response it is.
    – PeeHaa
    Dec 3, 2011 at 22:08
  • Incident response takes place based on what you're trying to protect. I'm betting/hoping you don't care about the actual system but about data/funcionality provided by it. Add to the post what kind of data is stored on the system and what type of functionality the system provides.
    – Alex Holst
    Dec 3, 2011 at 22:31

4 Answers 4

Reset to default
2

Take a look at an IDS system, personally I use OSSEC http://www.ossec.net/.

It will email you when a rule is triggered, by default it is a bit spammy but can be configured. For example it will email you when:

  1. First time user logins in via SSH
  2. First time a user runs sudo
  3. Failed sudo/su conversions
  4. When the checksum of a file in /etc/ (or any configured dir) is changed.

And a lot more, looks for rootkits and can be configured to autoresponse to threats.

In terms of how you should response, that is really more of a business logic question. Ask yourself

  • How critical is this system? Can it be turned off for a undetermined amount of time without problems?
  • Do you have backups? (And can you trust that those backups will also not get broken into?)

If you can take the box off, take it down. make a full disk backup, you need to invegtigate how they got in, use something like Sleuth kit. You should mount the disk in order to do tests, dont trust the tools on the system that got compromised, you cant trust the binaries are really what you think they are. Also if you are able to determine that a user gained root access, everything on that box is gone, you cant trust the logs, timestamps, binaries, anything. This is where something like rsyslog can help.

If you had customer data that was compromised you have to follow the business plan for how that should go.

Improve this answer
3

I think you're being overly paranoid. You've restricted root login to key-authentication. You've forced the protocol to version 2. I'm assuming you've also restricted which users can login via ssh (via the sshd_config file)...

Short of those techniques, you should make sure that you can limit what a logged-in user can do. Restrict their ability to escalate to the root level. Limit access to commands via sudo or otherwise. Do you have SELinux enabled? Do you have process accounting enabled? You could potentially install DenyHosts as a means of tracking ssh attempts...

Do you have any ability to close SSH access and rely on a VPN for external access to the system?

Improve this answer
1
  • I might be overly paranoid. :-) I am using AllowUsers directive and the others. But I don't have DenyHosts installed. Will look into it. However I cannot close SSH access since it is a VPS. And it's the only means I can access it myself.
    – PeeHaa
    Dec 3, 2011 at 22:06
2

Using the IP blocking scripts is actually a good idea, especially if your blocking script only blocks IP addresses from which you have had failed logins from previously. The biggest advantage I saw immediately was that it cleared up my syslog file. I would get N failed logins within Y seconds, then boom, blocked ip, maybe one or two tries, but the log entry was one line, then they'd stop. After X number of days the entry would be purged. The key thing I had to remember was that if I failed to log in a few times, was to wait before I hit the magical Nth login.

Another thing to consider is once they are on your system, assume they have fully privileged access, what can they use your system for? Can they start a service on the box to receive new connections from the outside, or is there piece of fire walling hardware between that system and the internet? Can the system be used as a launch pad for attacks on other systems, or does your firewall block all outbound access by default (a squid proxy on another host is useful for these situations)? Also how easy is it to jump to other systems once they are on your network?

Improve this answer
2

I'd bring the server down immediately (since intruder managed to log in, he possibly owns your private key and if so you have no means to prevent him from logging in again). Then I'd create another VPS and copy there only the data I need, while verifying that I don't copy any backdoors he installed (preferably copy from some backup made before the attack, for new data use diff to verify every change since the last backup to see if that change is intruder's activity). It's hard to trust hacked system.

Also I'd check how he managed to log in - possibly he owns system(s) that hold your private keys and thus will be able to get your new keys as well, or he managed somehow to alter your sshd config - again, the vulnerability can exist on a new system too.

Besides if you are paranoid, you may like single packet authentication for your SSH.

Improve this answer
2
  • I don't understand how paranoid and SPA are even in the same sentence. "Port knocking" is basically a clear-text password that can be sniffed, replayed, etc.
    – Alex Holst
    Dec 4, 2011 at 17:34
  • 1. Single Packet Authentication is NOT port knocking. Actually (depending on implementation) it is secure, is not clear-text nor subject to replay (see the link in my post). 2. Without knocking I get tons of failed login attempts in auth. log which triggers my panic attack, while even with simple unsecure knocking logs will remain clean.
    – Sandman4
    Dec 4, 2011 at 19:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .