According to my current understanding, tcpwrappers can be used via inetd or xinetd. Lately I have been informed that inetd/xinetd came into existence to make more efficient use of hardware in earlier days and are therefore seen rarely nowadays.
My question is, if tcpwrappers are now considered to be an outdated technique, too. If yes, what is their replacement?
Services that run constantly on certain ports. The reason inetd and suchlike saved memory is because they didn't require daemons to run all the time, just on demand. These days, on-demand daemons are pretty rare.
Things like Apache, MySQL, and Tomcat all stay running and listening to their designated ports. Some even spin up new processes to handle each connection, others just handle it in the same process. By not having to load a bunch of code each time a connection starts, the cost to establish a specific connection is smaller than it would be with inetd-like processes.
You are wrong about both TCPwrappers and [x]inetd.
tcpwrappers can be used via inetd or xinetd
Yes - but you can use them with any network daemon - it's just a matter of using a different lib when you build the application.
inetd/xinetd came into existence to make more efficient use of hardware in earlier days and are therefore seen rarely nowadays
No not really - running services via [x]inetd has always been very inneficient compared to a standalone daemon - the difference they make is that the code is much simpler, and is only mapped into memory when a connection is made.
This is still true today - if you're running a dedicated webserver, then there's not much point in keeping daemons running for, say POP messages if there's only a single user connecting a couple of times a day to collect mail generated from cron jobs. Or starting a VNC server when you need remote GUI access on a headless machine.
One of the nice things about tcpwrappers is that they make scripting complex responses very simple compared with a kernel based firewall.
tcpwrappers was originally implemented as a standalone program which would check hosts.allow and hosts.deny. If the connection passed, then it the desired daemon would be started to run a single request. The configuration for inetd would be configured to run the tcpd wrapper with the daemon's program and options as parameters.
xinted is an extended inetd. Is has significantly more configuration options than the old inetd. The trivial services like echo, chargen, time, daytime, and discard are built-in. Many daemon process which often run continuously can be run from xinetd. This is usually done when the service is rarely used. This limits the number of processes which need to be running at the expense of slower start-up times. Services which can be run this way include mail servers, vnc, apache, and many other daemons.
inetd performs the same tasks as xinetd but with a simple one line configuration for each service. This limits it ability to be configured, but simplifies automatic configuration. Installation procedures which can automatically configure inetd may not be able to do the same for xinetd. Many sites now choose to use xinetd rather than inetd.
The wrapper code has been made into a library and is often linked with daemons which are always running. These daemons will use the library to check incoming connections before using them. This allows name based restrictions which can not be reliably implemented in a firewall. This includes a number of DNS based checks. One of the daemons which is usually built using the library is xinetd.
inetd/xinetd came into existence in the days when people were running lots of remote accessible services on every machine - including things like time/date/chargen etc. These days, given a more hostile internet and a greater awareness of potential for using such things to launch DDOS attacks, most machines will run very few servers (very few should be running anything other than SSH), with specific machines for things like DNS, SMTP etc. As such, the newer daemons that implement such protocols usually have everything that the wrappers did inside them.
Additionally, firewall capabilities can be used to provide most of what tcpd/udpd used to do.
Essentially the job that TCP-Wrappers does for services being called via a "super server" can be replaced (for other processes and a "super server") by stateful firewalling, through iptables/netfilter in the case of most modern Linux installations (and for basic functionality, stateless firewall rules would do also).
