[CentOS] defense-in-depth possible for sshd?
johnny at centos.org
Fri Jan 13 13:40:36 UTC 2012
On 01/12/2012 08:56 PM, Bennett Haselton wrote:
> On 1/12/2012 5:25 PM, Johnny Hughes wrote:
>> On 01/12/2012 10:31 AM, Tilman Schmidt wrote:
>>> Am 10.01.2012 19:05, schrieb Johnny Hughes:
>>>> Limit access to the sshd port from only authorized places ... and
>>>> the authorized places can be an openvpn type connection if you
>>>> always need access from difference IPs. If you have a laptop, put
>>>> an openvpn client on it and take it with you if you need access
>>>> from dynamic places. Connect the openvpn to the endpoint someplace
>>>> and then use that to connect to the sshd on the server via the
>>> I'm not convinced that would actually improve security.
>>> What that does is replace the risk of intrusion via an sshd
>>> exploit by the risk of intrusion via an OpenVPN exploit.
>>> But it also adds a layer of complexity, and complexity is
>>> the enemy of security. So the risk of an exploitable hole
>>> in OpenVPN would have to be provably so much lower than in
>>> SSH that the difference outweighs the increase of risk
>>> through added complexity. I don't know of any data to
>>> support that claim.
>> Not at all ... you first have to crack the OpenVPN system to gain access
>> to the ssh port at all (that did not get you into the machine, it got
>> you an IP address that then allows you to TRY to access the machine) ...
> I think Tilman is saying that rather than "cracking" OpenVPN in the
> sense of tricking into allowing you access, you could find an exploit in
> OpenVPN where simply sending the right packets to the OpenVPN server
> would allow you to execute arbitrary code as root on the server, the
> same way as an attacker might try to do to the sshd server.
Except there is no way to see the openvpn port if you don't first have a
valid certificate from the server if the firewall is properly configured
... Les has explained this dozens of times on the list. Also, I
normally do not put VPN on the server itself, but on an external
device. It doesn't have to be openvpn ... it can be a cisco ipsec vpn,
etc. If it was a machine at an ISP, I would use openvpn on the machine.
> Or is there a reason that an exploit against OpenVPN would be less
> powerful than an exploit against sshd?
Sure ... an exploit against openvpn does not open a shell as root, that
makes it MUCH less important. The vast majority of other exploits are
also not actually against the OS itself but rather they normally target
bad programming from some framework like php or java (or asp or .net on
windows) where some kind of web application allows the user to send a
file off the machine. As I have stated before, there hasn't been a
remotely exploitable openssh (sshd) problem on CentOS or RHEL since
version EL 2.1 in 2003. People are not getting into a machine by
exploiting openssh ... they are exploiting data (or files) to gain
access to people's passwords and then using that data to login normally
on people's machines. They might be getting that data by sniffing
packets when someone crosses their routers to login and check their
e-mail or if someone has mailed them (unencrypted) the password, etc.
Somehow they get password data, then they log in.
If there was some kind of access restriction (keys, iptables restricting
IPs, etc) to the ssh logins, then even with the login credentials the
bad guy can not gain a root shell on the machine. Their goal is
normally not to open a rogue shell as the apache user (though things
like SELinux make those things much less probable), it is to gain full
root access via ssh on the machine. To do that, they need a exploit to
gain access, and then be able to somehow escalate that access to some
other user that can see or do something bad.
> This came up earlier, and you said that OpenVPN has had far fewer such
> exploits logged against it than sshd. In that case it really would be
> more secure, but not because it provides an extra "layer", but rather
> simply because exploits against it are more rare.
I did not say that ... as I said before, most exploits do not just open
up a shell that lets people have full access to your machine as root.
Most exploits will allow someone to execute a command as the owner of
the listening service (apache for httpd, as an example) that is
running. SELinux greatly inhibits any of those processes (the initial
rogue ones that the other exploited process allowed) being able to do
things outside the contexts where the initial user (apache) is allowed
to go. So, with SELinux enabled, if a person was able to use an
exploit to put something in a tmp directory, they would not be able to
make that file they put there executable and they would not be able to
escalate the apache user to become root. They might be able to craft
some kind of sql query to mail a SQL Dump of some application that
maintains its usernames and passwords in it. If that data had anyone's
username and password in it that would also be allowed to ssh into the
machine (because they use the same password in their e-mail or on
<X_WEB_APP> as the do to login) ... well then, they just use ssh and
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 262 bytes
Desc: OpenPGP digital signature
More information about the CentOS