[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RE : [cobalt-security] Forensics on a hacked server



Hi Alain,

> One bottom-line question I wonder about is this: is there any way to be
> secure from these kinds of attacks ? 

No, not really. You can make it more troublesome for an intruder to get in, 
but you can never achive total security. But make it just difficult enough so 
that he rather targets the unsecured box next to yours and you're spared for 
the moment.

It is possible to increase your awareness by adding extra tools like Tripwire 
or Fcheck which check the filesystem for modifications. If some files 
(binaries in/usr/bin for example) change out of the blue, then you instantly 
know something is wrong. 

Additional agents like Snort can scan the network traffic for suspicious 
activity and Logcheck can scan the logfiles for unusual activity.

But basically those tools don't prevent an intrusion all by themselves. They 
just act as "tripwires" to alert you if someone has gained unauthorized 
access.

LCAP can prevent the loading of malicious kernel modules once someone gets in. 

Denying the compiler GCC to anyone but root is also a good security measure as 
it limits the damage that an intruder can do if he managed to get into your 
box as regular user. Either directly by SSH, or through an exploited service 
which runs as unprivileged user (httpd for instance).

Installing a firewall on the RaQ itself can help to make it more difficult for 
an intruder to get in or to make use of installed backdoors. But a firewall 
doesn't protect you against vulnerabilities in services to which you need to 
allow access to from anywhere (Apache, Sendmail, POP3, IMAP and so on). 
Likewise, a software firewall running on the same server is never as good and 
as reliable as a dedicated - separate - firewall which you put in front of 
your network assets.

Some of these tools and/or procedures can help to get an early warning when 
something fishy is happening. Some carefully implemented procedures can make 
it more difficult for an intruder to get in and to actively use the RaQ for 
his shabby business (ingress & egress filters on a firewall for instance).

But this is a constant struggle. Build a better alarm system and the hacker 
will sooner or later come back with better tools.

So there is no patented solution that works all the way. Even if there were, 
there is still the possibility that the box next to yours in the datacenter 
is hacked and runs a tool that is sniffing your login details while you login 
to your box as admin by POP, IMAP, FTP or HTTP without using an encrypted 
connection instead.

Even if you never ever submit your admin password over an unsecured connection 
there is still the chance that someone gets in by sniffing your users POP3 or 
IMAP passwords to get in with their login details. Once on the command line 
he can then try to exploit services from the inside to get root access. 

Disabling and denying shell access to all users but admin is therefore one of 
the first security procedures you should implement.

Finally you should have a good backup solution at hand which allows you to 
quickly restore a compromised server. Hopefully you'll never need it, but 
isn't that true for all security measures?

-- 

With best regards,

Michael Stauber