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
_______________________________________________
cobalt-security mailing list
cobalt-security@xxxxxxxxxxxxxxx
http://list.cobalt.com/mailman/listinfo/cobalt-security