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 >>>> vpn. >>> 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 those credentials.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
