> > 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
Yo creo que ipchains funciona a nivel IP (red), tcpd sí en 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) Alguien puede explicar eso de los paquetes syn o dónde hay documentación > 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] ¿three-way-handshake? ¿a tres bandas? ¿que es eso? > 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 > De acuerdo. > > > > 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). Sí, esa era la única opción que se me ocurría, pero me parecía poco elegante... > 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). También existe una opción para ponerlo bajo inetd, lo que pasa es que iría más lento. > 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. ¿seguro? no podría ponerlo para cualquier aplicación, pues vaya. Bueno, yo lo que quería decir es que si yo hago un netstat más un lsof y cierro por tcpd las aplicaciones que escuchan lo que no me interesa abrir al mundo ¿necesito de todas formas las ipchains para estar más seguro? > > Javi Saludos. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
