[Techtalk] closing ports in /etc/services

[Caitlyn Martin]

Hi, everyone,

I think I find myself disagreeing with our Asimovian robotic friend. 
Let's go back to Carla's orginal question.

Is commenting out lines in /etc/services a valid way to close ports? 
Answer:  yes and no, mostly yes.

Most services are started in one of two ways:  they are invoked by
startup scripts or invoked by the internet superdaemon (inetd or
xinetd).   Let's talk about services started by scripts.  On a Red Hat 9
system they would be located in /etc/rc.d/rc[x].d where [x] refers to
the runlevel the system is going into.  These scripts generally refer to
service by name, and for those services to be recognized and the script
to successfully start the service the service(s) and the corresponding
port(s) must appear in /etc/services.  

For example, lets say I have amanda, the open source backup software,
installed as a client on my machine.  If amanda, amandad, kamanda, and
kamandad (assuming kerberos authentication is used) are not in
/etc/services amanda will not run.  The corresponding ports will not
show up if you do a netstat -a, nor will the show up if you scan the
system with a tool like nmap.  Nothing is listening on the port since
the service is not running.

So, in effect, this does what Carla wants.

The "no" part comes in to play in two areas:  one, there is still
nothing preventing some script or application from opening the port
later, and there is nothing blocking communications to that port. 
That's where a firewall comes in.  That is why I said commenting out
lines in /etc/services is no substitute for a firewall. 

Services controlled by xinetd or inetd are a bit different.  These
services do not have individual startup scripts nor are they
automatically started at boot.  They are started on demand by the
internet superdaemon.  All of these services can also be effectively
disabled by commenting out lines in /etc/inetd.conf on older systems, or
by changing the appropriate configuration file in /etc/xinetd.d on most
modern Linux systems, including Red Hat.  You can also turn on and off
these and most other services using the chkconfig command on a Red Hat
system.  (Thank you, SGI.)  Most can also be disabled by commenting out
lines in /etc/services but not all.  sunrpc and sgifam are two examples
I can think of that will still start if called.  

Now, our robotic friend claims there is no security value in commenting
out lines in /etc/services.  This is the crux of our disagreement. 
First off, the more ways you make sure that things you don't want
running can, in fact, not run, IMHO, the better.  The idea that this
won't deter a cracker is correct, but it's one more step that they have
to be bothered with, more time they have to spend, and more chance for
detection when something magically changes.  The more steps you take to
insure your desired configuration, the tighter the system, and the less
desirable you are as a target of opportunity.  It also may provide some
additional security from less than skillful intruders.

The only difference between getting rid of a startup script or altering
it to kill instead of start a service and commenting it out in
/etc/services is that if you do the latter the script will still try to
run but fail.  I suppose this adds a few seconds to boot time.  The
actual net result, though, is the same.

So, once again, my answer to Carla is yes, it works.

All the best,
Caity