From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from u2.inri ([107.191.125.208]) by pp; Thu May 21 12:27:41 EDT 2015 Date: Thu, 21 May 2015 12:27:34 -0400 From: sl@9front.org To: 9front@9front.org Subject: Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default Message-ID: List-ID: <9front.9front.org> X-Glyph: ➈ X-Bullshit: stable wrapper SSL factory module module dependency control MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit > I was not suggesting to not remove these standard services in the default > configuration. I wanted to understand what the [security] gain is here, > and if removing these service scripts wouldnt make things worse. Okay. > This is a cpu server, there will be at least *one* service listening (cpu). > If your intend is to waste system resources, then you can as well use the > cpu service for that, it makes no difference what port you use. True. Here is another aspect to consider: What are the ramifications of each open port that is: - not configured - misconfigured in all possible combinations of file systems (nobody even responded to my post about user none being treated differently by cwfs and hjfs), auth configurations, single-user, and multi-user systems? Can anyone even say they've attempted to examine this? My contention is that simple is better. You don't have to ask questions about a service that is not provided. There should be a justification for each service provided. Why are these ports open? > There are no priviledged ports. Any user can listen on any port as long > as it is not in use already. Say, none starting to listen on dns/tcp port > because someone forgot to rename the listener for that after setting up > dns service. This can have consequences far worse as it could then poison > dns caches and redirect all traffic to some other machine. That's a good point. But it opens up the question of dangerous ports that we currently *do not* have open by default. Based on this line of thought, how do we protect those ports, and why is (say) tcp port 53 more important to defend than (say) tcp port 80? What if a user sets up a malicious socks proxy? I have to leave for work now so I don't have time to repeat this question for all 65,535 possible ports. But it seems unlikely that we're going to create dummy scripts for tcp1 through tcp65535. sl