Great Circle Associates Firewalls
(September 1992)

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: which services ? (was Re: none + some VS all - some)
From: Richard Childers <rchilder @ us . oracle . com>
Date: Thu, 24 Sep 92 17:42:51 PDT
To: firewalls @ GreatCircle . COM

"i'm interested in people's comments about these two issues.
 to be more specific, "none + some" refers to the configuration
 of disallowing all packets in general, and then specifically allowing
 some (like SMTP/NNTP) and "all - some" refers to the configuration
 of allowing all by default and then specifically not allowing others
 (like Xserver)."

Here's my understanding of how to do this.

There is a set of services, which corresponds roughly to a list of
numbered and named sockets, which, in BSD Unix, at least, can be
found in a file called /etc/services.

Some of them may be commented out, services which have a universally
agreed-upon socket number honored around the world, but are no longer
used much, such as uucpd.

Others are not commented out, either through slack administration or
a genuine desire to provide those services to users.

For each socket, there is usually a binary, somewhere, which handles
traffic through these specific sockets. Often, the service starts with
a "in.", such as "in.routed". These services are services which don't
have their own dedicated process running all the time, as they are
rarely used, and they are invoked by an intermediate daemon, inetd,
so that all of these services ( and their corresponding server images )
are represented by one server image that acts as a traffic cop, passing
requests on to other processes and invoking them as necessary, to save
CPU and process table from the potential load.

It gets a little more interesting when you realize that the operating
system and socket paradigm were created with the intention of supporting
a very large array of possible TCP- and UDP-based services, numbered from
1 and extending up to, oh, 32767, probably, or thereabouts.

So even if a given socket is not explicitly documented locally, software
may still be written and run successfully which will base exchanges of
data on the use of an arbitrary socket ID. This is the basis of many new
services, which have proved successful enough to have been officially been
given a particular NIC-sanctioned socket ID ... such as those pertaining
to X Windows.


So, realistically, you have an array of numbers, say 1 to 32767, each of
which may or may not have a NIC-sanctioned usage associated with it, and
each of which may or may not be documented locally. How do you sort out
those which you want from those which you do not ?

The way I've done it is to eliminate, ruthlessly, everything I don't need.
That's right, whittle away according to the Need. If you don't use it, you
don't need it. Get rid of it - comment it out of your services file, or
initialize your gateway to filter it, or whatever.

When you're done, you'd be amazed at how little you truely _need_. This is,
by the way, an educational process, as you may learn something about the
interdependencies of the networking daemons in this way, also.

When someone says they need a service, provide it ... and monitor it, until
you're sure it's not a security issue.

Even if you trust a given service, don't assume that someone might not come
up with a way to use that socket for their own purposes. So you are never
truely safe. Logging is an excellent way to handle this, as you can generate
statistical profiles of usage on a per-protocol basis, and red-flag yourself
via email when anything deviates over N% from the norm.

The bottom line - if you don't know what it is, get rid of it and see what
happens. If you can live without it, live without it until you can't. Give
up the "everything but the kitchen sink" approach, it is inconsistent with


I thought I was going to learn something from this mailing list. Perhaps
those more knowledgeable would be so kind as to correct this and show me
where I have erred ? I am confident that this has errors in it ...  (-:

-- richard

-- richard childers		rchilder @
 us .
 oracle .
 com		1 415 506 2411
         oracle data center  --  unix systems & network administration

                    Klein flask for rent. Inquire within.

Indexed By Date Previous: I'm willing to do something to reduce traffic.
From: karl @ grebyn . com (Karl A. Nyberg)
Next: Re: conversion to digest
From: Brent Chapman <brent @ GreatCircle . COM>
Indexed By Thread Previous: I'm willing to do something to reduce traffic.
From: Unknown
Next: Re: which services ? (was Re: none + some VS all - some)
From: sidney @ borland . com (Sidney Markowitz)

Search Internet Search