On Sat, Oct 06, 2001 at 10:15:02PM +0200, Alfonso wrote:
> Hola,
>
> Resulta que servicios que tengo activados como por ejemplo el smtp los tengo
> cerrados por tcp-wrapper v�a hosts.deny / hosts.allow dejando s�lo el paso a
> quien me interesa (red interna), pero no s� si ser� un sistema seguro porque
Ipchains y tcpd funcionan a niveles distintos:
Ipchains: protocolo TCP/IP (Sesi�n)
Tcpd: nivel de Aplicaci�n
Es decir, con Tcpd no puedes evitar que el puerto "se vea abierto"
desde el exterior, lo que controlas son las conexiones al programa final. Te
pongo el desarrollo de la comunicaci�n y donde interviene cada uno:
a) m�quina A env�a paquete Syn a B dirigido al puerto Y
(ipchains)
b) m�quina B responde con paquete Syn Ack a A
(ipchains)
c) m�quina A completa la conexi�n con B
[esto es el proceso three-way-handshake de TCP/IP]
d) m�quina A env�a datos a lo que est� escuchando en la m�quina B puerto Y
[esto dispara el proceso del superdemonio inetd que est� ejecutando el
puerto pero reenv�a a otra aplicaci�n seg�n la definici�n del inetd.conf]
(tcpd)
e) m�quina B responde a la petici�n de A
>
> Y otra cosa: si quiero meter un servicio que se ejecuta desde /etc/init.d/ y
> no desde inetd, �cu�l es la mejor forma de ponerlo bajo tcpd?, �me lo cargo
> de /etc/init.d/ y meto una l�nea en el /etc/inetd.conf?
>
> Gracias y saludos.
>
Creo que el segundo, porque tcpd (creo) no puede funcionar como
demonio, es decir, aceptando conexiones en un puerto siempre e instanciando
nuevos procesos para atender a las conexiones entrantes (sin perder la
escucha en el puerto). Por ello tienes que poner la l�nea en el inetd.conf
que haga que el superdemonio inetd llame a tcpd con los par�metros
necesarios (aplicaci�n a ejecutar).
En cualquier caso, centralizas todos los servicios en un demonio, lo
cual puede ser bueno o malo seg�n tus necesidades. Adem�s de que
determinados programas (Apache?) esperan funcionar de otra forma
(controlando directamente el puerto y creando instancias de procesos hijos a
los que pasan las conexiones).
En resumen, s�lo podr�s hacer �sto para procesos que puedan
ejecutarse en modo "terminal" (aceptan datos de la entrada est�ndar) pero no
para otros que quieran, directamente, hacerse con el control del puerto
correspondiente.
Javi