teoria-identd: (0.02)
	¿Que hacemos con el puerto auth (113) del servicio identd?


UNA EXCEPCION: PUERTO AUTH (113)

"DENY/DROP versus ACCEPT"

	Hay algunos (pocos) servidores FTP, SMTP y POP3 en internet que
	 intentan autenticar al establecer la conexión con ellos.
	Para esto inician una conexión a nuestro puerto auth (113)

    DENY/DROP
	Si tenemos el puerto 113 DENY/DROP, no contestamos nada, asi que el
	 servidor espera un TIMEOUT antes de continuar la conexión (o la aborta)

    REJECT
	Reject devuelve un ICMP "connection refused" que no es lo que espera el
	 servidor y estamos igual...
    
    ACCEPT
	Si permitimos pasar el paquete y NO tenemos el servicio identd activo
	 nuestro kernel devolverá un paquete TCP RST (RESET) y eso hace feliz
	 al servidor.
	Por cierto los Windows hacen eso (enviar un TCP RST) ¿y verdad que se
	 puede bajar FTP, enviar correo, y demás...?

	RIESGO: Hay que asegurarse de que el servicio identd NO esta activo,
	 porque no queremos dar ninguna pista a los posibles intrusos, ni
	 permitirles explotar vulnerabilidades (si algún dia se le descubre
	 alguna) de identd.


    ¿PERO QUE INFORMACION DA EL SERVICIO IDENTD?
	Identd debe devolver el usuario/demonio que ha establecido la conexión
	 que se le pregunta, pero solo de las conexiones que tenemos activas
	 con la maquina que nos pregunta.

	Aun así la existencia de este servicio nos identifica fácilmente como
	 máquina Unix en un escaneo de puertos y nos convierte en un objetivo
	 apetitoso para un hacker con mucho tiempo libre...


MI RECOMENDACION:

	Yo lo tengo DENY/DROP y busco mirrors de los servidores FTP que no me
	 van, no quiero ningún agujero en mi cortafuegos...

	Es una lástima que no exista un target RESET en ipchains.
	Se lo he pedido a Rusty que está preparando iptables para los futuros
	 kernel 2.4 y me ha dicho que es muy fácil de hacer, ya que iptables
	 es modular, y que lo programe yo :-(


MAS INFORMACION:
	- man identd
	- rfc1413