I am interested in opinions regarding the use of xinetd versus the use of tcp wrappers. The two programs have similar functionality, but I find xinetd suits my needs better. The biggest problem is the age of xinetd, and AFAIK it is no longer being kept up. Are there any known security issues with xinetd? Another issue is that xinetd makes use of a non-standard inetd.conf layout, but I''m willing to accept that limitation. I''m looking for security reasons why I might not wish to use xinetd. Anyone? -jjr Jeffrey J. Radice jjr@simpson.com hypURzine Development http://oj.simpson.com Box 4343, Austin, TX 78765 512-432-4757
> > I am interested in opinions regarding the use of xinetd versus > the use of tcp wrappers. The two programs have similar functionality, > but I find xinetd suits my needs better. > > The biggest problem is the age of xinetd, and AFAIK it is no longer > being kept up. Are there any known security issues with xinetd? > Another issue is that xinetd makes use of a non-standard inetd.conf > layout, but I''m willing to accept that limitation. I''m looking > for security reasons why I might not wish to use xinetd. Anyone?You will get better performance from xinetd because you will be execing fewer programs within each process. For example. When you use tcpd, inetd will fork another process, then exec tcpd. Tcpd will do its verification and exec the program that will ullitimately provide the service. Xinetd will perform its checks, fork and exec the service program. It does not do much of the "paranoid" DNS verification that tcpd does. [mod: Thus it is open to the attack that the "paranoid" DNS verification fixes. i.e. create a reverse mapping for bad.host.attacker.com that reads trusted.host.victim.com and you can use services that were not intended for you.... -- REW] As far as not being kept up, tcpd has not been updated for the 12 to 18 months. The last few upgrades were to support additional operating systems, so it has essentially not changed over the last two years. Both are good products. For connect intensive applications I would choose xinetd. For any other applications I''d use tcpd. You may also wish to look at portmap 4 or portmap 5beta (or rpcbind 1.1 for Solaris). This portmap daemon is built around the TCP/Wrapper library giving you some additional protection. You also get it from Wietse''s FTP site. Alternatively you could turn on kernel firewalling to perform the same function. Regards, Phone: (250)387-8437 Cy Schubert OV/VM: BCSC02(CSCHUBER) UNIX Support BITNET: CSCHUBER@BCSC02.BITNET ITSD Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it."
Hi, I have recently heard of a remote root exploit in sendmail-8.8.4, but nor this list neither bugtraq had talked about the problem. Is there REALLY a bug, or is this just a false fire? I changed to qmail anyway which, I realised, suits my needs much better. To the xinetd thread: I use xinetd, and found it much more secure than the simple inetd. I haven''t tried, but maybe you can still filter things through tcp-wrappers with server=/usr/sbin/tcpd server_args=/here/or/there/whatever if there any need or use :) Regards, raas
} Xinetd will perform its checks, fork and exec the service program. It does } not do much of the "paranoid" DNS verification that tcpd does. } } [mod: Thus it is open to the attack that the "paranoid" DNS verification } fixes. i.e. create a reverse mapping for bad.host.attacker.com that reads } trusted.host.victim.com and you can use services that were not intended } for you.... -- REW] Not exactly... xinetd does *no* DNS checks so is immune to DNS spoofing! The access controls are specified as IP addresses. This is obviously good for some applications and rubbish for others (you can always run tcpd under xinetd). [mod: I stand corrected. Thanks. -- REW] Adding tcpd''s domain lookups into xinetd would require xinetd to fork and then do its access checks since the DNS calls would otherwise block xinetd causing it to be very sluggish. NB If people are interested I have a patch around which adds explicit netmask specification to all address range specs. I have passed this to the maintainers, but its not been taken up as yet. Nigel. -- [ Nigel.Metheringham@theplanet.net - Unix Applications Engineer ] [ *Views expressed here are personal and not supported by PLAnet* ] [ PLAnet Online : The White House Tel : +44 113 251 6012 ] [ Melbourne Street, Leeds LS2 7PS UK. Fax : +44 113 2345656 ] [Q: You know when you run sendmail.... A: No, you DELETE sendmail]
I''m the author of tcpd, so my answer is certainly biased. tcpd is from the `smaller is better'' school. It sacrifices some cpu cycles to minimize the risk of running it. xinetd saves a few cpu cycles but it involves an order of magnitude more code, not counting helper utilities. Wietse> > } Xinetd will perform its checks, fork and exec the service program. It does > } not do much of the "paranoid" DNS verification that tcpd does. > } > } [mod: Thus it is open to the attack that the "paranoid" DNS verification > } fixes. i.e. create a reverse mapping for bad.host.attacker.com that reads > } trusted.host.victim.com and you can use services that were not intended > } for you.... -- REW] > > Not exactly... xinetd does *no* DNS checks so is immune to DNS spoofing! > The access controls are specified as IP addresses. This is obviously good > for some applications and rubbish for others (you can always run tcpd > under xinetd). > > [mod: I stand corrected. Thanks. -- REW] > > Adding tcpd''s domain lookups into xinetd would require xinetd to fork and > then do its access checks since the DNS calls would otherwise block xinetd > causing it to be very sluggish. > > NB If people are interested I have a patch around which adds explicit > netmask specification to all address range specs. I have passed this to > the maintainers, but its not been taken up as yet. > > Nigel. > > > -- > [ Nigel.Metheringham@theplanet.net - Unix Applications Engineer ] > [ *Views expressed here are personal and not supported by PLAnet* ] > [ PLAnet Online : The White House Tel : +44 113 251 6012 ] > [ Melbourne Street, Leeds LS2 7PS UK. Fax : +44 113 2345656 ] > [Q: You know when you run sendmail.... A: No, you DELETE sendmail] > >