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
