Re: an actual hacked machine, in a preserved state

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



On Tuesday 03 January 2012 07:57:47 Les Mikesell wrote:
> On Tue, Jan 3, 2012 at 4:28 AM, Bennett Haselton <bennett@xxxxxxxxxxxxx> 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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos


[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux