Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default

Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default

[sl]

Amended:

/rc/bin/service should be tracked under /sys/lib/dist instead of
in-place, and most of them should be disabled by default.

Related:

/sys/log entities should match program name and all defaults should be
present on system after install


sl

Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default

[cinap_lenrek]

makes sense, yeah.

--
cinap

Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default

[sl]

> but if someone want to exhaust your tcp connections they can do
> that with any service that accepts connections.

Yes, of course. And any valid user on the system can make things go
wrong in a huge number of ways (like your example: running malicious
services on any port that is not already being used).


> anyway, i'm fine with less services listening by default if
> that fixes the robot scanner problem for them.

Okay.

What about having hg track /sys/lib/dist/rc/bin/service instead of
/rc/bin/service?

sl

Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default

[cinap_lenrek]

when your users accounts get compromized, then you'r screwed with
the current authorization scheme, which means they can run arbitrary
commands over cpu service.

enabling/disabling other services wont fix that.

--
cinap

Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default

[sl]

> 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.

I let this one go by too easily.

We're not always dealing with an intelligent, determined attacker.
Most attacks are automated and opportunistic.

Skynet is big, dumb, slow, and stupid. It dials a lot of ports without
knowing in advance if they are going to be open. It works off a big list
of ports that it expects to be open.

It's worth considering that more ports open means more potential
connections. It's also worth pointing out that the robots who dial
a list of common ports are more frequently encountered than the
robots who portscan first, or who already know about Plan 9. The
result is that the cpu port is rarely accessed, while common
ports (such as the ones I suggested disabling) are constantly
accessed by random Internets.

sl

Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default

[Kurt H Maier]

Quoting sl@9front.org:

> The result is that the cpu port is rarely accessed, while common
> ports (such as the ones I suggested disabling) are constantly
> accessed by random Internets.

And even answering those connections with "no." means sending
packets.  And packets cost money.

khm

Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default

[sl]

> 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

Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default

[Devon H. O'Dell]

2015-05-21 9:27 GMT-07:00  <sl@9front.org>:
>> 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

There's also at least a non-zero memory and computation overhead for
accepting connections and putting them into TCP instead of just
dropping them.

--dho

Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default

[cinap_lenrek]

only the total number of connections that you accept matter,
not if you spread the connections over different services.

the only valid point is that you avoid the connection overhead
for automatic scans for common services that try to bruteforce
passwords (or try to send spam email over the open smtp service)
when you do not listen on these common ports.

but if someone want to exhaust your tcp connections they can do
that with any service that accepts connections.

anyway, i'm fine with less services listening by default if
that fixes the robot scanner problem for them.

--
cinap

Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default

[sl]

> currently I don’t use /rc/bin/service/* at all.
> I think services are different among servers.
> how do you resolve this problem?

In practice, I don't have much in /rc/bin/service/.

Instead, I store custom tcp* scripts in different directory and start
them with listen1 run from /cfg/$sysname/cpustart.


sl

Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default

[sl]

> i'm not against this, but what exactly is the problem? its not like
> these services are usable unless you have an actual account on the 
> auth server (and created a mailbox for the user in case of imap/pop3).

Potentially, Skynet connecting to open ports and wasting system
resources when the ports are not even being used for any legitimate
purpose. It's just bad practice to leave the windows broken, even if
you trust the security guard asleep at the desk inside.


> what we really want is a authorization scheme that would allow us to
> grant a user the services he can use on the system. right now its
> a all or nothing. if you have an account you can use every service
> in the network.

Yes. But why ship broken windows?

sl

Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default

[cinap_lenrek]

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.

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.

I know that disabling services is common wisdom, but this is not unix.

Then theres another aspect thats different from unix:

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.

--
cinap

proposal: disable most of /rc/bin/services/tcp* by default

[sl]

Why are so many services enabled by default?

I propose to disable the following in the default install by moving
them from tcp* to !tcp*.  Functionality can be enabled by simply
copying !tcp* back to tcp* (and following whatever other procedures
were already required).

Let's turn these off:

	tcp110	# pop3
	tcp143	# imap
	tcp21	# ftp
	tcp23	# telnet
	tcp25	# smtp
	tcp53	# dns
	tcp513	# rlogind
	tcp993	# imap over tls
	tcp995	# pop3 over tls

In addition: Items that are left enabled by default (and really, even
the ones disabled by default) should be checked to ensure that the
installer creates the log files they attempt to write to.

I volunteer to do this if no one objects.

sl

Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default

[cinap_lenrek]

tricky todo as /rc/bin/service is tracked by hg. so when you do this,
you will shoot down services from the net as they run sysupdate.

all these services require authentication (except dns), and they
run as none initially. tho i see your point, this is not 1995.

--
cinap

Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default

[Kurt H Maier]

Quoting cinap_lenrek@felloff.net:

> tricky todo as /rc/bin/service is tracked by hg. so when you do this,
> you will shoot down services from the net as they run sysupdate.

Perhaps the files in /rc/bin/service can be renamed/disabled as part of
the installer?  That wouldn't nuke existing installs, but would provide
sane defaults going forward.

khm

Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default

[mischief]

[-- Attachment #1: Type: text/plain, Size: 916 bytes --]

I am in favor of this and also putting the service directory in .hgignore. Creation of log files would be nice too.

On May 20, 2015 11:16:35 AM PDT, sl@9front.org wrote:
>Why are so many services enabled by default?
>
>I propose to disable the following in the default install by moving
>them from tcp* to !tcp*.  Functionality can be enabled by simply
>copying !tcp* back to tcp* (and following whatever other procedures
>were already required).
>
>Let's turn these off:
>
>	tcp110	# pop3
>	tcp143	# imap
>	tcp21	# ftp
>	tcp23	# telnet
>	tcp25	# smtp
>	tcp53	# dns
>	tcp513	# rlogind
>	tcp993	# imap over tls
>	tcp995	# pop3 over tls
>
>In addition: Items that are left enabled by default (and really, even
>the ones disabled by default) should be checked to ensure that the
>installer creates the log files they attempt to write to.
>
>I volunteer to do this if no one objects.
>
>sl

[-- Attachment #2: Type: text/html, Size: 1242 bytes --]

Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default

[cinap_lenrek]

i'm not against this, but what exactly is the problem? its not like
these services are usable unless you have an actual account on the 
auth server (and created a mailbox for the user in case of imap/pop3).

this is not like unix where services run as "root" and then impersonate
some user on the system, but they start as "none" and cant do anything
(even if there are bugs) unless the user authenticates.

if you have an account, then you can as well cpu in and run commands.

what we really want is a authorization scheme that would allow us to
grant a user the services he can use on the system. right now its
a all or nothing. if you have an account you can use every service
in the network.

--
cinap

Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default

[Kurt H Maier]

Quoting cinap_lenrek@felloff.net:

> i'm not against this, but what exactly is the problem?

Open ports attract automated attacks. Even if they don't work,
bandwidth costs money.

khm

Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default

[cinap_lenrek]

ok, that makes sense.

--
cinap

Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default

[arisawa]

Hello 9front users,

currently I don’t use /rc/bin/service/* at all.
I think services are different among servers.
how do you resolve this problem?

Kenji Arisawa

> 2015/05/21 3:16、sl@9front.org のメール：
> 
> Why are so many services enabled by default?
> 
> I propose to disable the following in the default install by moving
> them from tcp* to !tcp*.  Functionality can be enabled by simply
> copying !tcp* back to tcp* (and following whatever other procedures
> were already required).
> 
> Let's turn these off:
> 
> 	tcp110	# pop3
> 	tcp143	# imap
> 	tcp21	# ftp
> 	tcp23	# telnet
> 	tcp25	# smtp
> 	tcp53	# dns
> 	tcp513	# rlogind
> 	tcp993	# imap over tls
> 	tcp995	# pop3 over tls
> 
> In addition: Items that are left enabled by default (and really, even
> the ones disabled by default) should be checked to ensure that the
> installer creates the log files they attempt to write to.
> 
> I volunteer to do this if no one objects.
> 
> sl

Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default

[sl]

>> tricky todo as /rc/bin/service is tracked by hg. so when you do this,
>> you will shoot down services from the net as they run sysupdate.
> 
> Perhaps the files in /rc/bin/service can be renamed/disabled as part of
> the installer?  That wouldn't nuke existing installs, but would provide
> sane defaults going forward.

This sounds good to me.

sl

Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default

[sl]

> all these services require authentication (except dns), and they
> run as none initially. tho i see your point, this is not 1995.

Most of them require additional configuration to make them really
do anything useful, anyway. I don't see any reason to leave the
ports open by default.

sl