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.
> 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.
> 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.
> OK but those are *users* who have their own passwords that they have
> chosen, presumably. User-chosen passwords cannot be assumed to be
> secure against a brute-force attack. What I'm saying is that if you're
> the only user, by my reasoning you don't need fail2ban if you just use a
> 12-character truly random password.
But you aren't exactly an authority when you are still guessing about
the cause of your problem, are you? (And haven't mentioned what your
logs said about failed attempts leading up to the break in...).
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
