On 1/3/2012 12:50 AM, Nataraj wrote:
> On 01/02/2012 10:48 PM, Bennett Haselton wrote:
>> True but I travel a lot and sometimes need to connect to the machines
>> from subnets that I don't know about in advance.
> You could secure another system somewhere on the internet (could be a
> $20/month virtual host), leave no pointers to your production systems on
> that system, and allow remote logins on your production systems from
> that other host. It's called a back door.
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?)
> You could also take a look
> at something like fwknop. That in combination with some type of back
> door for the situation where you don't have your keys available should
> cover any situation where you need to get to your system. But access
> using the key authentication should be preferred and only use the back
> door for emergencies.
>> If I used openvpn to connect, and then connected via ssh over openvpn,
>> this seems like essentially security through obscurity :) by just
>> replacing the public ssh daemon with a different public daemon (with a
>> different connection protocol) which an attacker could try to
>> brute-force the same way they could try to brute-force sshd.
> Pretty much all security is based on something that you know/have that
> the attacker doesn't know/have. This is true for computer access, the
> locks on your front door and the safe at the bank.
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.
> What your getting
> from the people on this list is their experience, comments based on what
> they did that worked and what they did that didn't.
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?
One way you can know is if you have two barriers one behind the other,
and attackers get through the first barrier but not the second one, then
you know the second barrier mattered. That's why the argument for
SELinux sounds persuasive, because of identified instances where
attackers circumvented the first barrier (finding a way to make Apache
create executables in /tmp/) but were stopped by the second (SELinux
prevented those executables from being run).
> Check the past 10
> years of cert advisories and count the number of security advisories for
> sshd and then count the number for openvpn.
OK, that's different from the obscurity factor (since the difference in
exploit frequency, would still be a reason to use openvpn instead of
sshd, even if the attacker knew that you were using it). However that
also has to be weighed against the side effects of using a non-standard
setup. I assume, for example, that most security audit tools would look
at IP addresses that attempted to log in via ssh. That wouldn't work if
your gateway is OpenVPN instead of sshd. (In my experience, everything
you're doing differently from everyone else, makes it harder to get help
when things go wrong.)
>> However it still seems that this would only matter if the attacker got
>> in by brute-forcing the login. If they obtained the ability to run
>> privileged commands any other way, then (1) they could continue to run
>> privileged commands that way anyway, or (2) as their first action they
>> could just remove all the IP address restrictions on ssh connections at
>> which point they could connect normally via ssh from anywhere.
> The more security mechanisms you have in place, the greater is the
> probability that even if they made a partial compromise of your system,
> they might fail when they try to get through to the next level and if
> you have warning systems, such as daily reports or even alerts sent to
> your cell phone, you might be able to stop them first.
For partial compromises that makes sense.
However for total compromises (i.e. if attacker is running root commands
on your system), then presumably this would only work if your tripwire
warning system was obscure enough that the attacker didn't know to look
for it. Otherwise their first action would be to disable the tripwire
before it warned you.
>> So if this only matters when the attacker is trying to brute-force the
>> login, and I still think that a 12-character random password is
>> un-bruteforceable which makes the IP restrictions moot.
> Experience has shown that passwords can be cracked much more easily then
> private/public keys.
"passwords", generally, can be. I don't think 12-character truly random
passwords can be. (If once you hit the "takes 100,000 years to crack"
mark, you don't care any more.)
> Your the one telling us that your system has been
> compromised. Others sharing this fact may not have their systems
> compromised, or if they did, they learned from it.
>> If I'm wrong, then why? What do you think -- if my password is already
>> a 12-character random string, do think it adds additional security to
>> restrict ssh logins to only subnets that I'm logging in from? If so,
>> then what's a specific scenario where the attacker would be able to
>> break in (or would have a larger chance of breaking in) if I'm not
>> restricting ssh logins by IP, but would not be able to break in if I
>> were restricting ssh logins?
> That's a straight probability calculation. How many billion systems are
> on the Internet? If I allow logins from even 100,000 systems versus
> several billion, I've substantially reduced the probability of a
> sucessful brute force attack.
Others have pointed out that the limiting factor is the rate at which
the ssh daemon can accept or refuse logins. With that being the case,
it doesn't matter if the attacker has 1 billion systems or 100,000 --
they're throttled by the ssh daemon. And with 10^24 possible
truly-random-12-char passwords there's no way they can brute force your
password that way in either case.
I mean, I don't want to miss anything here, but if you think I'm wrong
about this, then why?
> I have had problems with password guessing attacks on my pop and ftp
> servers (my ssh port is totally closed).
> Since I'm providing services to users, I can't just close those ports.
> I've been running fail2ban now for some time and it has helped, but I
> wanted to further reduce having even a handful of guesses. I discovered
> that the majority of attacks are coming from Asia, Russia, eastern
> Europe, South America and the middle east. Well I don't have any ftp
> users in those areas, so I blocked access to these countries and in fact
> now only allow access from regions where I have users. Things have been
> pretty darn quiet since I did that.
>
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.
Bennett
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
