[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Probando xinetd (chuleta) ¿alguien lo usa?



Hola a todos,

He estado mirandome el xinetd, y me gusta... ;-)

xinetd es un reemplazo del demonio de demonios inetd más asegurable, os adjunto
mi chuleta del tema ;-)

Un extracto de mi chuleta:

VENTAJAS:
- La característica de seguridad que más nos interesa de xinetd es la
 posibilidad de restringir los interfaces en los que escuchan los demonios
- Es incluso posible tener en el mismo puerto diferentes servicios para cada
 interface (comprobado :-)
- Mecanismos de control de acceso incluidos (hosts.allow / hosts.deny como
 tcpwrapper, su propio control de acceso con "only_from" y por la hora)
- Posibilidad de "nice" de los servidores
- Posibilidad de logging personalizado para cada servicio
- Posibilidad de redirección de servicios
   

¿Alguien lo usa ya en producción? ¿Que tal va?


Saludos,
-- 
-------------------------------------------------
Manel Marin   e-mail: manel3@apdo.com
Linux Powered (Debian 2.2 potato)  kernel 2.2.17

Mira mis chuletas de Linux en  http://perso.wanadoo.es/manel3
-------------------------------------------------
Mi petición de drivers para Linux es la nº 33126
 (Pasate por http://www.libranet.com/petition.html ;-)
I-xinetd: (0.04) (potato)
	Instalar y asegurar xinetd, reemplazo mas seguro y flexible para inetd


POR HACER:
*FALTA PROBAR INTENSIVAMENTE, ahora todo parece funcionar...*


VENTAJAS:
- La característica de seguridad que más nos interesa de xinetd es la
 posibilidad de restringir los interfaces en los que escuchan los demonios
- Es incluso posible tener en el mismo puerto diferentes servicios para cada
 interface (comprobado :-)
- Mecanismos de control de acceso incluidos (hosts.allow / hosts.deny como
 tcpwrapper, su propio control de acceso con "only_from" y por la hora)
- Posibilidad de "nice" de los servidores
- Posibilidad de logging personalizado para cada servicio
- Posibilidad de redirección de servicios

INCONVENIENTES:
- Archivo de configuración diferente (tipo named), se hace raro al principio
- Cada vez que convertimos la config de inetd a xinetd perdemos nuestras
 customizaciones
- Al instalar nuevos servidores que requieren ser lanzados por inetd no se
 añaden a xinetd.conf (aunque he leído que se nos avisará)
- No hay configuración desde Linuxconf (para inetd si)


PROCEDEMOS:

1) Instalar el paquete xinetd

    - Do you want to convert inetd to xinetd?  YES

    Los scripts de arranque se modifican automáticamente para que xinetd
    reemplace a inetd, y xinetd queda funcionando tras la instalación


2) Limitar acceso a nuestra red y a interface de nuestra red

    - Añadir al inicio de xinetd.conf:

*NOTA* Esta sección defaults no es estrictamente necesaria, ya que el xinetd
  de Potato respeta la configuración de tcpwrappers (lee POR DENTRO...) de
  /etc/hosts.allow y /etc/hosts.deny
---8<---
defaults
{
	only_from = 192.168.0.0/24		# Nuestra red local
}
--->8---

    - y a la sección de cada servicio añadir la opción

---8<---
	interface = 192.168.0.1		# La IP de este servidor en el
					# interface de nuestra red local
--->8---

    por ejemplo:

service smtp
{
	socket_type     = stream
	protocol        = tcp
	wait            = no
	user            = mail
	server          = /usr/sbin/exim
	server_args     = -bs
	interface	= 192.168.0.1
}

    esta misma linea en inetd.conf (sin limitación de interface) es:

smtp   stream  tcp     nowait  mail    /usr/sbin/tcpd  /usr/sbin/exim -bs


3) Hacer que servidor de nombres netbios nmbd (samba) no finalice con el error:
 "netbios-ns service was deactivated because of looping"

    - Añadir a la sección de netbios-ns un "flags = REUSE" quedando así:

# SERVIDOR DE NOMBRES NETBIOS port 137 (sin "flags = REUSE" peta)
service netbios-ns
{
	socket_type     = dgram
	flags		= REUSE
	protocol        = udp
	wait            = yes
	user            = root
	server          = /usr/sbin/nmbd
	server_args     = -a
	interface	= 192.168.0.1
}


4) Activar los cambios de xinetd

    a) /etc/init.d/xinetd stop
    b) /etc/init.d/xinetd start
    
    ATENCIÓN: "reload" no hace activas las limitaciones de interfaces,
     supongo que porque los sockets ya están abiertos...

    NOTA: Asegurarse de los puertos/interfaces que debe usar xinetd están
     libres antes de activar xinetd para evitar problemas con "netstat -tuna"


PRUEBAS:

    comprobar que se escucha en el interface deseado (192.168.0.1) y no en
    todos (0.0.0.0) en "Local Address" haciendo netstat -tuna

    SUGERENCIA: Lee mi chuleta S-tcp-wrapper
	desconectar de Internet (el cable físico)
	desactivar cortafuegos
	nmap a IP alias 10.0.0.0, a 192.168.0.1 y a 127.0.0.1
	    (nmap -P0 -sT -sU -v -p 1-65535 10.0.0.0)

	telnet 10.0.0.0 smtp (y a 192.168.0.1 y a 127.0.0.1)
	activar cortafuegos
	conectar a Internet


ARCHIVOS:
    config:	/etc/xinetd.conf
    acceso:	/etc/hosts.allow y /etc/hosts.deny
    log:	/var/log/daemon.log


POR DENTRO:

  hosts.allow / hosts.deny soportados

    xinetd de Potato ha sido compilada con la opción "--with-libwrap" así que
    cuando xinetd hace el chequeo de acceso primero pide a libwrap que
    compruebe /etc/hosts.allow y /etc/hosts.deny, entonces si libwrap acepta
    la conexión xinetd consultará su propio mecanismo de control de acceso


  Limitación de interfaces

    Si se limitan los interfaces a la red local eth0 un escaneo (nmap) desde
    Internet (ppp0, eth1, etc...) no encuentra ningún servicio activo.

    Además "netstat -tuna" muestra la IP del interface en vez 0.0.0.0 en la
    columna "Local address"


LIMITACIONES:
    - No se puede poner la opción "interface" en la sección "defaults" (de
     ajustes globales) hay que escribirla en cada servicio
    - No se puede poner dos interfaces en el mismo servicio, hay que escribir
     la sección dos veces (comprobado)


POR HACER:
    Añadir puerto a syslog (solo pone "refused connect from 10.0.0.0")
    Probar si es mas rápido que inetd + tcpwrappers


MAS INFO:
    man xinetd.conf
    /usr/doc/xinetd/examples/sample.conf.gz	# Ejemplo de configuración

Reply to: