ASEGURANDO UNA MAQUINA: (0.03) *A REESCRIBIR* ¿Que hay que filtrar en un cortafuegos de filtrado de paquetes y porque? AUTOR Y MOTIVO: Manel Marin, Licencia GNU GPL ;-) Hay que hacer todo lo posible para que desde internet no se pueda llegar a comprometer la seguridad de nuestro sistema. INCONVENIENTES: Configurar un cortafuegos de filtrado de paquetes es difícil, ya que hay que conocer como se comporta cada servicio (mirar mis chuletas teoria-puertos*), pero es muy seguro y consume pocos recursos. NO CONFIAR CIEGAMENTE EN EL CORTAFUEGOS: Es un error común... ¿Y si mañana se le descubre un agujero de seguridad al ipchains? Asegura tu servidor todo lo posible (lee mis chuletas S-*) POLITICA POR DEFECTO: DENY/DROP La politica más segura es prohibir todo tráfico que no se sepa lo que hace. Es mejor una queja de un usuario que no puede hacer lo que quiere que un compromiso de seguridad de root. PROHIBIR EL SPOOFING ¿Que es eso? Un intruso puede hacerse pasar por la IP de tu PC o por tu loopback (127.0.0.1), o por la IP de un PC de tu red y tener pleno acceso a tu sistema/red. Es increible pero es así. ¿PERO QUE ES EL "loopback"? Muchos servicios se pueden usar en red o desde el mismo PC donde residen, si lo usas desde el mismo PC, sin que tu lo sepas, utilizan el interface loopback para la conexión. SER INVISIBLE: "DENY/DROP versus REJECT" "Ser invisible", que no nos vean, no contestar nada (PING, etc...) Usar mejor: DENY/DROP (ignorar silenciosamente todo intento de conexión) que REJECT (devuelve inmediatamente un ICMP de "connection refused") Esto hace muchísimo mas lento el escaneo de puertos y demás tests de vulnerabilidades ya que obliga a esperar un TIMEOUT para cada puerto (Lo he probado con Nessus) IP DINAMICA mejor que IP ESTATICA Si cada vez que nos conectamos a internet tenemos una IP diferente le estamos "complicando la vida" a alguien que nos quiera "seguir la pista". IMPEDIR CONEXIONES DESDE FUERA: En los kernel 2.0 y 2.2 se puede prohibir toda conexión TCP a mi máquina desde internet permitiendonos conectar nosotros y recibir respuestas, esto se hace prohibiendo la entrada de paquetes SYN. En los kernel 2.3-2.4 (gracias a iptables) aparece la noción de control de conexión, con lo que parece que se podrá hacer lo mismo con UDP, (al fin... :-) IMPEDIR QUE NOS APROVECHEN PARA CONSEGUIR ANONIMATO: 1) Enmascara solo paquetes de la red interna. Alguien puede querer utilizarnos como retransmisor emmascarando su identidad IP (tunneling) con nuestro masquerade. Es un error común activar el enmascaramiento de paquetes para permitir a todos los PC de una red interna acceder a internet sin impedir que lo aprobechen desde fuera para obtener anonimato. PUERTOS A FILTRAR DE ENTRADAS DE INTERNET Y PORQUE: GENERAL: 1) Puerto CERO, nadie piensa nunca en el (menos los hackers) 2) Puertos bajos: 1-1023, no queremos que accedan a nuestros servicios locales. 3) Si no se hace lo anterior hay que negar el acceso desde internet a los puertos netbios 137-138-139 para evitar que desde internet puedan acceder a los recursos compartidos de los win95 de tu red TCP/IP, y a todos los servicios locales que quieras proteger. 4) Prohibir los "fragmentos IP", hay muchos ataques relacionados con ellos. Por supuesto recompila antes el kernel para desfragmentar siempre (lee mis chuletas S-kernel-*) TCP: 1) Prohibir todo intento de conexión iniciado desde internet (paquetes "SYN") 2) Si es posible, solo permitir respuestas a tus peticiones (ACK, ! SYN) 3) Prohibir explicitamente todo servicio TCP local con puerto > 1023 Prohibir entradas a los servidores X (puertos 6000-6009) * El primer servidor X usa el puerto 6000 * Cada servidor X adicional usa un puerto consecutivo Prohibir acceso a los servidores proxy * squid: 3128 * wwwoffle: 8080 y 8081 4) Utiliza mi chuleta "S-puertos" para identificar los puertos abiertos UDP: 1) Cuando sea posible prohibir conexiones iniciadas desde internet (esto será posible con "iptables" en los kernel 2.4 :-) 2) Prohibir en general y abrir pequeños agujeros a IPs de confianza: - Aceptar UDP de tus servidores DNS (port 53) a TU_RED (port 1024...65535) - Aceptar UDP de tu servidor de "hora atomica" NTP (puerto ntp) 3) Prohibir explicitamente todo servicio UDP local con puerto > 1023 Prohibir entradas a servicio NFS: 2049 * Este servicio UDP utiliza el portmap para obtener el puerto, ai que podria ser un puerto distinto... 4) Utiliza mi chuleta "S-puertos" para identificar los puertos abiertos ICMP: ¿QUE HACER? Entrada de ICMP: dejar pasar los mínimos posibles 1) Aceptar entradas de ICMP de (tipo 3, código 4) * Tipo 3 es "destination unreachable", destino inalcanzable * Código 4 es "fragmentation needed", fragmentación necesaria - Se utilizan para descubrir la unidad máxima de transferencia, MTU, en conexiones transcontinentales. 2) Puedes aceptar icmp/0 "echo reply" (contestación a nuestros ping) 3) Para utilizar traceroute necesitas aceptar: * icmp/3 (destino inalcanzable) * icmp/11 (tiempo excedido) 4) Se puede considerar como ataques o previos las entradas de los ICMP: 8 (ping) que nos hacen previo a un ataque 5 (redirect) 4 (source quech) intento de ataque DoS Salida de ICMP: 1) No dejar salir ningún ICMP a) Se nos puede detectar enviando paquetes que nos obliguen a contestar con un ICMP "destination unreachable". b) Se pueden utilizar para encubrir canales de comunicación. INCONVENIENTE: Los ICMP de salida ayudan en la comunicación, aunque yo no tengo problemas desde que los tengo prohibidos. 2) Se puede utilizar las salidas del ICMP/12 parameter problems como indicio de ataque a nuestro sistema 3) Puedes permitir salidas de ping enviados por nosotros (icmp/8). UNA EXCEPCION: puerto auth (113) del servicio identd "DENY/DROP versus ACCEPT" Hay unos pocos servidores FTP, SMTP y POP3 en internet que intentan autenticar al establecer conexión con ellos. Para esto inician una conexión a nuestro puerto auth (113) DENY/DROP Si tenemos el puerto 113 como 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 esto hace feliz al servidor. Por cierto los Windows hacen esto (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... MAS INFORMACION: man identd, rfc1413 SALIDA DE PAQUETES: 1) Cada regla de entrada deberia tener una regla de salida relacionada ya que la comunicación siempre es en los sentidos... 2) Para usar traceroute hay que permitir la salida UDP de los puertos 33434 a 33600 (tres puertos por cada nodo a detectar). LOG DE PAQUETES PROHIBIDOS Y SEGURIDAD: 1) registrar en /var/log/messages (flag "-o", o "-l") todo paquete prohibido. ESTRATEGIA DE LOG: * Evitar log de paquetes no significativos reincidentes (el tiempo y la práctica te enseñará cuales) * Log de todo acceso prohibido * Log de intentos de salidas ppp0 UDP y ICMP no permitidos, para detectar que servicios quieren usar nuestros usuarios... RIESGO: DoS Flood de logs en ataque Si alguien consigue "vernos" y nos somete a un escaneo sistemático e ininterrumpido, nuestra máquina puede quedar colapsada por la cantidad de log generado, e incluso quedarse sin espacio de disco. Esto es un ataque "DoS" (de Denegación de Servicio) Soluciones ahora: a) Hacer un sistema que permita desactivar el log manualmente b) Hacer reglas para contar los paquetes de ese tipo recibido, no es un log, es seguro y nos permite hacernos una idea de que tipo de ataques se intentan contra nosotros. c) Confinar el log en cuestión a una partición diferente (no lo he probado) Solución futura: a) Emplear "iptables" cuando el kernel 2.4 sea estable ya que permite limitar la cantidad de log generado. PROGRAMAS PARA ESTABLECER EL FILTRADO DE PAQUETES: Cada version de kernel tiene su programa que gestiona el filtrado: 2.0 -> ipfwadm 2.2 -> ipchains 2.3-2.4 -> iptables (hay un modulo ipchains, pero iptables es mejor) Cada uno de estos programas tiene una sintaxis diferente... Esto obliga a volver a escribir todas las reglas del cortafuegos para cada versión de kernel. INFORMACION INDISPENSABLE: http://www.robertgraham.com/pubs/firewall-seen.html (en Inglés) MIS CHULETAS RELACIONADAS: - S-BASES - teoria-tcp-ip - teoria-cortafuegos-filtrado - teoria-cortafuegos-proxy - teoria-puertos* - S-DOC (documentación recomendada) - chuletas de seguridad S-*