[CentOS] an actual hacked machine, in a preserved state

[Marc Deop]

On Tuesday 03 January 2012 07:57:47 Les Mikesell wrote:
> On Tue, Jan 3, 2012 at 4:28 AM, Bennett Haselton <bennett at peacefire.org> wrote:
> >
> > But assuming the attacker is targeting my production system, suppose
> > they find a vulnerability and obtain the ability to run commands as root
> > on the system.  Then wouldn't their first action be to remove
> > restrictions on where you can log in from?  (Or, they could just
> > continue to run root commands using whatever trick they'd discovered?)
> 
> No, they'd probably replace your ssh binary with one that makes a
> hidden outbound connection to their own control center.  And replace
> netstat with one that doesn't show that connection.   If anyone has
> ever gotten root access, all other bets are off - those tools are a
> dime a dozen.

Those kind of things can be detected with SHA512 (for example)

> 
> > Yes, but the argument for "security over obscurity" is that the "secret"
> > should reside in something that cannot be obtained even in trillions of
> > trillions of guesses (i.e. a strong password), not in something that
> > could be obtained in a few dozen or a few thousand guesses (i.e. finding
> > OpenVPN listening on a given port).  The reason being is that if
> > something is obtainable in a few thousand guesses, then it will create
> > the illusion of being unguessable, but an attacker could still get it.
> 
> Openvpn runs over UDP.  With the tls-auth option it won't respond to
> an unsigned packet.  So without the key you can't tell the difference
> between a listening openvpn or a firewall that drops packets silently.
>  That is, you can't 'find' it.

We are not going to argue drop vs reject, are we? :P

> 
> > Unfortunately it may not be possible to tell that a particular safeguard
> > ever actually "worked" or made a difference.  How could you ever know,
> > for example, that an attacker was stopped because you used an ssh key
> > instead of a 12-character truly random password?
> 
> If you look at your logs under normal conditions, you'll know if
> someone has tried and failed a password login.  After someone has
> gotten in, it may be too late because they can destroy the evidence.
> Logging remotely to a more protected machine can help a bit.
> 

Remote syslog? that way they'll have to hack into two different machines...

Regards