On 01/10/2012 07:58 AM, Ned Slider wrote: > On 10/01/12 13:34, Bennett Haselton wrote: >> On 1/10/2012 5:16 AM, John Doe wrote: >>> From: Bennett Haselton<bennett@xxxxxxxxxxxxx> >>> >>>> On 1/10/2012 2:02 AM, Adrian Sevcenco wrote: >>>>> UsePrivilegeSeparation >>>>> Specifies whether sshd(8) separates privileges by creating an >>>>> unprivileged child process to deal with incoming network traffic. >>>>> After successful authentication, another process will be created that >>>>> has the privilege of the authenticated user. The goal of privilege >>>>> separation is to prevent privilege escalation by containing any >>>>> corruption within the unprivileged processes. The default is >>>> ``yes''. >>>> OK. So it sounds like if you found a particular exploit in sshd that >>>> could *only* do certain things -- like write a file to an arbitrary >>>> location on disk -- then this privilege separation would prevent that >>>> exploit from being used to make the child process write somewhere that >>>> it didn't have privileges to write to. >>> Do a ps and look at the sshd tree. Example: >>> root 6014 0.0 0.1 97816 3760 ? S 11:01 0:00 \_ sshd: bob [priv] >>> bob 6029 0.0 0.0 97816 1796 ? S 11:01 0:00 \_ sshd: bob@pts/2 >>> bob 6030 0.0 0.0 108392 1760 pts/2 Ss 11:01 0:00 \_ -bash >>> >>> The sshd child is running as bob; so it has bob (and not root) rights... >>> >>> JD >> Yes, I understand that. What I said was that if you could take complete >> control of the sshd process you were connecting to, even if that process >> was completely unprivileged, you could still make it say "Accept a login >> from 'root' with password 'foo'" and then log in as root. >> > Probably. > > If a flaw were to exist in OpenSSH that allows execution of arbitrary > code then pretty much anything is possible, which is why it is wise to > always stay fully patched and limit exposure by only providing access > (to the sshd service) to those that need it. Heck, even security through > obscurity (running on a non-standard port) will limit exposure to the > extent that the casual attacker scanning for machines vulnerable to a > zero-day vulnerability will probably pass you by given the number of > lower hanging fruit out there. > > What you are talking about is essentially a zero-day vulnerability > that's being actively exploited in the wild. So although you said you > weren't talking about layers of security in front of sshd, these are > exactly the layers of defence that will help limit the scope of such an > attack. You can't look at security in isolation, you have to look at the > whole picture, identify the risks in your systems and then take measures > to mitigate those risks that are relevant to you. IOW, if you only > access the system from a handful of locations, firewalling the sshd > service to only allow access from those IP ranges essentially makes the > rest of the discussion redundant. Similarly, running on a non-standard > port will be highly effective against the casual attacker scanning large > areas of the IP address space for vulnerable machines to attack, less so > against a targeted attack. Ding, Ding, Ding .... what he <^^^> said :D 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. Wide open sshd ports on the Internet are dangerous. There have been NO critical sshd security issues in any release of RHEL (and therefore CentOS) since 2003 ... and that was for CentOS-2.1. Critical being the kind that allows remote access directly via sshd ... please see this link for an explanation of the severities: https://access.redhat.com/security/updates/classification/ So, the person is not getting sshd access remotely via an exploit. They MIGHT get access via some other exploit (httpd exploit of php code that provides shell access, something that then can escalate that to root level access (that would be an "Important" level of problem (allowing local user to escalate)) ... but the vast majority of the time, it is logins via the sshd port because of bad passwords (or published passwords, or e-mailed passwords, etc.), no IP control on the sshd port via iptables, allowing root to login directly, not using keys for access, etc.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
