Re: security risk of having a long list of services in inetd
- From: Eduardo M KALINOWSKI <eduardo@xxxxxxxxxxxxxxxxx>
- Date: Sat, 30 Aug 2008 08:36:09 -0300
Paul Dufresne wrote:
Yes, I know. But as I see it, each mapping is like a *possible* door
to the Internet.
When there is so much, it become too hard to look at each door to see
if there is a program behind,
and if it does what it should.
Taken from http://en.wikipedia.org/wiki/Inetd :
"the long list of services that inetd traditionally provided gave
computer security experts pause. The possibility of a service having
an exploitable flaw, or the service just being abused, had to be
considered. Unnecessary services were disabled and off by default
became the mantra. It is not uncommon to find an /etc/inetd.conf with
almost all the services commented out in a modern Unix distribution."
I think you are mixing you're mixing /etc/inetd.conf (or whatever its
actual location is in Debian) with /etc/services. The latter file is
just a mapping of common port numbers to service names, so that iptables
can, for example, display service names instead of ports, or you can
type "telnet HOST smtp" instead of "telnet HOST 25".
It's presence or contents have no effect in the ability to have a
program listening on a port. It's actually easier to bind a socket to a
port number than first lookup the port number corresponding to the
service "foo" and later bind to that number. Telnet might do the long
way to make things easier for the user, but some kind of backdoor will
simply start listening on some predefined port, without bothering about
/etc/services.
/etc/inetd.conf, however, lists ports that are listened to and programs
to run when a connection is made to that port. That file should be as
empty as possible (unless necessary for some service you need, you
shouldn't even be running inetd or some equivalent), and if it's not in
a default install, I'd consider it a bug.
Moreover I now see that /etc/hosts.allow and /etc/hosts.deny are empty
(well just comments), which means that it is open to everybody.
The problem with that is that the installer cannot know the requirements
of each system, it's not possible to supply files denying everything,
because some hosts will need to have access to the daemon (otherwise,
there is no need to run it, or at least, bind it only to the loopback
interface if it's only for other programs in the same machine).
--
Q: What is printed on the bottom of beer bottles in Minnesota?
A: Open other end.
Eduardo M KALINOWSKI
eduardo@xxxxxxxxxxxxxxxxx
http://move.to/hpkb
--
To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
- References:
- security risk of having a long list of services in inetd
- From: Paul Dufresne
- security risk of having a long list of services in inetd
- Prev by Date: MySQL goes away?
- Next by Date: Re: Lilo Can't Boot vmlinuz-2.6.26-1-amd64
- Previous by thread: Re: security risk of having a long list of services in inetd
- Next by thread: Can't Detach from a startup script
- Index(es):
Relevant Pages
|
