teora-filtrado-2: (0.02)
	Nociones de filtrado de paquetes (II) -Problemas del filtrado-


Resumen de contenido:
--------------------
Problemas del filtrado de paquetes
    Es fcil perderse (olvidar opciones) entre tanta letra
    Hay que saber que paquetes enva y recibe cada servicio
    El "log" de paquetes de ipchains no es seguro (ataque DoS)
    El servicio auth



Problemas del filtrado de paquetes


    Es fcil perderse (olvidar opciones) entre tanta letra

	No he visto nada ms crptico que un script con docenas de reglas
	de filtrado de paquetes

	Bueno, pensandolo mejor, cuando mezclas reglas de filtrado y bash
	el resultado es an peor...

	Ms adelante os propondr una solucin ;-)



    Hay que saber que paquetes enva y recibe cada servicio

	En esto nos vamos a concentrar en este cursillo ms adelante



    El "log" de paquetes de ipchains e ipfwadm no es seguro (ataque DoS)

	Se pueden registrar en /var/log/messages (flag "-o", o "-l")
	 todos los paquetes prohibidos, pero tiene algunos riesgos:

	DoS Flood de logs en ataque
	    Si alguien consigue "vernos" y nos somete a un escaneo sistemtico
	     e ininterrumpido, nuestra mquina puede quedar colapsada por la
	     cantidad de log generado, quedndose sin espacio de disco.

	    Esto es un ataque "DoS" (de Denegacin de Servicio)

	Soluciones ahora:
	    a) No hacer log, crear reglas para contar los intentos de acceso a
	     servicios comunes (www, telnet, ssh, etc)
	     Esto es seguro y nos permite hacernos una idea de que tipo
	     de ataques se intentan contra nosotros.
	    b) Hacer un sistema que permita desactivar el log manualmente
	    c) Confinar el archivo de log en cuestin a una particin diferente
	     (no lo he probado)
	    d) Seguramente "snort" que viene con Potato nos sirva para esto,
	     sustituyendo al log del filtrado de paquetes
	     (no lo he probado a fondo) 

	Solucin futura:
	    a) Emplear "iptables" cuando el kernel 2.4 sea estable ya que
	     permite limitar la cantidad de log generado.



    El servicio auth

	El puerto auth (113) es el servicio identd

	Hay unos pocos servidores FTP, SMTP y POP3 en Internet que intentan
	autenticar al establecer conexin con ellos.

	Para esto inician una conexin a nuestro puerto auth (113), esperando
	una contestacin o un TCP RST (servicio no disponible)

	Identd debe devolver el usuario/demonio que ha establecido la conexin
	que se le pregunta, pero solo de las conexiones que tenemos activas
	con la mquina que nos pregunta.

	Aun as la existencia de este servicio nos identifica fcilmente como
	mquina Unix en un escaneo de puertos y nos convierte en un objetivo
	apetitoso para un hacker con mucho tiempo libre...


	DENY/DROP
	    Si tenemos el puerto 113 como DENY/DROP, no contestamos nada, as
	    que el servidor espera un TIMEOUT antes de continuar la conexin
	    (o la aborta)

	REJECT
	    Reject devuelve un ICMP "connection refused" que no es lo que
	    espera el servidor y estamos igual... (por verificar ms)
    
	ACCEPT
    	    Si permitimos pasar el paquete y NO tenemos el servicio identd
	    activo, nuestro kernel devolver un paquete TCP RST (RESET) y esto
	    hace feliz al servidor.

	    Por cierto los Windows hacen esto (enviar un TCP RST)


	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 algn da se le descubre
	 alguna) de identd.


	MAS INFORMACIN: man identd, RFC1413

