0

What is the correlation between these programs? tcpd and inted/rinetd are very old but despite this they are still present in many distributions ... why? And there is also a correlation between hosts.allow and hosts.deny with tcpd but i noticed that these files are present even when tcpd is not installed ... (trying with the command dpkg also noticed that hosts.allow/deny is not correspond to no package) ... well .. a mess. Who helps me clarify?

Thanks

vincenzogianfelice
  • 175
  • 1
  • 10

1 Answers1

1

The traditional setup is to use inetd to open listening sockets, similar to what systemd is doing with socket activation now, only thirty years before that. inetd will unconditionally start the daemon when a connection comes in.

For some rudimentary access control, you'd configure inetd to start tcpd instead of the real server. This program would check that the connection is allowed according to the hosts.allow and hosts.deny files, and then execute the real service if it is.

This is significantly older than iptables or similar host-based firewall solutions, so it will also work on stacks that do not have a firewall at all, like AmiTCP or Miami on AmigaOS.

The other upside is that the configuration to check the source address is part of service startup, so once it is configured, there is no way to accidentally expose services by flushing the firewall rules.

The downside is that the port is initially open, so a network scan will show it, and the connection is immediately closed after it has been established.

The hosts.allow and hosts.deny files are no longer shipped, as "missing" files mean "allow all connections", so these form a valid configuration on their own, and anyone still using them probably knows what they are doing.

Note that when you use tcpd for access control, you lose the benefit of the wait option in inetd, where the service is started with the listener socket and is responsible for accepting further connections after being started (i.e. where you only have a single instance for multiple parallel connections).

There is no udpd, because verifying the source of UDP packets is impossible.

Simon Richter
  • 4,409
  • 18
  • 20
  • so are inetd / rinetd and tcpd all different and independent of each other? – vincenzogianfelice Feb 18 '20 at 18:14
  • @vincenzogianfelice, yes, that is the point. In the Unix world, programs are generally designed to do only a single thing, and the system administrator would then combine these tools, mostly using scripts and configuration files. `tcpd` makes the most sense when used from `inetd`, as far as I know it can't listen on sockets on its own, but it doesn't care which `inetd` implementation you use underneath (you could also use `socat`, for example). – Simon Richter Feb 18 '20 at 19:13
  • So, in this case, tcpd (and hosts.* files) may be useless with xinetd since xinetd already has an "only_from" option to accept or deny specific hosts ... right or am I wrong?? – vincenzogianfelice Feb 19 '20 at 04:50
  • @vincenzogianfelice, the functionality is duplicated, yes. `xinetd` has a different design philosophy, which you can also see in that it parses configuration fragments from a directory (i.e. implements a service registry) instead of leaving integration to the administrator. – Simon Richter Feb 19 '20 at 09:09
  • Ok...i think i understand... documenting myself better I discovered that both **xinetd** and the `hosts.deny` and `hosts,allow` files (the latter are part of the tcp wrappers.. right? ) cannot be applied to all services or programs, to use both xinetd and the hosts files , as the programs must be compiled specifically ... right? (in particular, to use the hosts files, the programs must be compiled with the **librwap** library?) – vincenzogianfelice Feb 19 '20 at 17:09
  • 1
    If the daemon is compiled against libwrap, then that implements the check against the `hosts.allow` and `hosts.deny` files, but you'd do that only for services where it makes sense for the daemon to stay around after the first connection. Using `inetd`, you can build services from shell scripts, and those would not use `libwrap`, so you'd configure them to use `tcpd` instead. – Simon Richter Feb 20 '20 at 09:42
  • thank you very much!! – vincenzogianfelice Feb 21 '20 at 04:27