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. 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. 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. Check the past 10
years of cert advisories and count the number of security advisories for
sshd and then count the number for openvpn.
> 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.
> 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. 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.
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.
By allowing access from only a handful of systems that you might be
familiar with, you probably won't have bot attacks.
Nataraj
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
