Date: Mon, 12 Oct 2009 11:45:19 +0200 From: Daniel Roethlisberger <daniel@roe.ch> To: freebsd-stable@FreeBSD.ORG Subject: Re: openssh concerns Message-ID: <20091012094519.GA29445@calvin.ustdmz.roe.ch> In-Reply-To: <alpine.BSF.2.00.0910111552060.48605@fledge.watson.org> References: <200910081823.n98INRVZ082461@lurza.secnetix.de> <alpine.BSF.2.00.0910111552060.48605@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson <rwatson@FreeBSD.org> 2009-10-11: > On Thu, 8 Oct 2009, Oliver Fromme wrote: > >Are you sure? The majority of BSD machines in my vicinity > >have multiple accounts. > > > >And even if there's only one account, there is no reason to be > >careless with potential port-takeover risks. > > > >Therefore I advise against running critical daemons on > >unprivileged ports, especially on machines with shell > >accounts. And if you need to bind to a port >= 1024, use > >mac_portacl(4) to protect it. It's easy to use. > >Alternatively you can increase the value of the sysctl > >net.inet.ip.portrange.reservedhigh, but this is less flexible > >and might have unwanted side effects. > > And, for those that haven't already noticed, "options MAC" is > compiled into GENERIC on 8.0, so working with MAC policies no > longer requires a recompile (or in many cases, even a reboot). If your situation allows running pf, then there's an alternative method: bind sshd normally to port 22, but use pf to deny direct connections to port 22, redirecting connections to some high port X to port 22 using a `rdr pass' rule. You can even make exceptions for trusted IP address ranges which are then allowed to SSH in directly on port 22. That way, an unprivileged process will gain nothing by listening on high port X; it won't get to accept() any SSH connections. -- Daniel Roethlisberger http://daniel.roe.ch/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091012094519.GA29445>