Me doy cuenta de que hay diferentes opiniones, pero una de las principales actitudes de las personas que realmente conocen las redes y la seguridad es que la mayoría de estas reglas de iptables/sysctl son redundantes, si no perjudiciales para usted y la red. Algunos lo criticarán agresivamente por romper con el comportamiento estándar sin razón. Algunos ejemplos:
-
El comportamiento estándar de TCP/IP es RECHAZAR para que el compañero obtenga alguna pista sobre lo que está pasando. Tal vez alguien simplemente escribió una URL incorrecta o su administrador está contando los hosts o alguien quiere conectarse a su servidor de juegos pero escribió el puerto incorrecto. Con DROP solo obtienen tiempos de espera oscuros y molestos.
-
No hay necesidad de descartar paquetes no válidos o con formato incorrecto, todos estos ataques tienen una década de antigüedad. Los desarrolladores del kernel de Linux están mucho más actualizados que usted en cuanto a qué tipo de paquetes son válidos y cuáles no. "¿Qué pasa con los defectos futuros", podrían argumentar algunos. Bueno, ¿cómo sabes que la futura falla estará en el controlador de TCP y no en el analizador de TCP de iptables?
-
La mayoría de las configuraciones de sysctl son predeterminadas. Si no lo son, generalmente hay una razón. Por ejemplo, ¿por qué deshabilitar el envío de redireccionamientos? Encuentro muy útil que un par me informe que mi enrutamiento es malo, incluso si nunca reaccionaría ("accept_redirects", default=0) automáticamente.
-
Con sus log_martians y otras reglas de registro, espero que también tenga una cuota en /var/log, o será muy divertido llenar su disco de forma remota, generalmente eliminando sus servicios/aplicaciones. Además, debe usar un límite de velocidad para el registro o alguien podría llenar la cuota para evitar que vea los intentos de fuerza bruta de la contraseña SSH en auth.log u otras cosas. ¿Realmente estás leyendo esos registros en un escritorio? Recomiendo logcheck.
-
Parece que bloquea ICMP. Además del problema de DHCP mencionado, esto también impide el descubrimiento de PMTU. Sin PMTUD, obtendrá un comportamiento extraño cuando utilice el sistema en lugares con conexión DSL u otras configuraciones de red. Algunos paquetes simplemente se eliminarán y nadie le dirá por qué.
-
Filtrar paquetes salientes es un poco oscuro. ¿No confías en ti mismo? Por lo general, no debe ejecutar ningún programa en el que no pueda confiar. Los sistemas operativos básicos son en su mayoría incapaces de aislar estos programas de espionaje o incluso manipular los datos de otros programas (por ejemplo, ataques de tiempo de caché)
-
Necesita paquetes NUEVOS para tener SYN. Esto se romperá si una conexión TCP continúa después de que el estado respectivo en iptables ya haya expirado. No estoy seguro de cuáles son los tiempos de espera predeterminados, pero un tipo de netfilter advirtió al respecto.
Entonces, ¿cuándo debería tener una computadora de escritorio un firewall?
-
Si hay un ataque específico en las noticias al que su sistema operativo actual o servidores son vulnerables, y una de las soluciones rápidas recomendadas es una regla de firewall.
-
Tienes que ejecutar ciertos servicios que no permiten una configuración segura. La mayoría lo hace, y el resto se reemplaza mejor con alternativas seguras.
-
Tiene redes más complejas con varias máquinas virtuales y/o interfaces en su escritorio.
La primera y más importante herramienta para la seguridad de su red es la actualización del sistema. En segundo lugar, está netstat y nmap, que debe usar para encontrar y confirmar qué servicios está ejecutando. Luego simplemente deshabilite aquellos que no necesita o confínelos a 127.0.0.1.
Bonificación si lee hasta aquí:los paquetes están ESTABLECIDOS, RELACIONADOS o NUEVOS, todo lo demás lo suelta. También suelta NUEVO a menos que solo se establezca SYN. Dado que ESTABLISHED,RELATED parece verificar las banderas, esto hace que todas las reglas --tcp-flags y también la regla -f sean redundantes. Lo mismo para la SALIDA, pero dado que no se ACEPTAN paquetes para la SALIDA de todos modos, eso probablemente no importe.
Sería cuidadoso al hacer que estos formen parte del mismo conjunto de reglas para dispositivos dentro de una red confiable y aquellos en una DMZ. Al usar las reglas que ha definido allí, no responderá a un servidor DHCP que le pregunte (eco ICMP) si su IP está en uso. Esto podría conducir a una situación de dirección duplicada.
Crearía dos conjuntos diferentes de reglas para aplicar a cada escenario, algo como lo que se menciona arriba es una buena línea de base para una máquina DMZ, pero crea algunos desafíos en una LAN típica.
Además, definitivamente recomendaría agregar registros a marcianos, caídas salientes, conexiones caídas entrantes, etc. Esto puede ser crucial para la resolución de problemas y puede ser información más útil para su SIEM.
Para una PC cliente, conectada directamente a Internet a través de ppp, el siguiente conjunto de reglas es un buen comienzo:
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
iptables -A INPUT -p udp -j REJECT
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
ip6tables -A INPUT -j REJECT
- Permite todo en la interfaz local interna.
- Permite cualquier paquete que sea una respuesta para un paquete que envíe. Esto incluye paquetes dentro de una conexión TCP, respuestas a paquetes UDP como pequeñas consultas de DNS. Para el protocolo FTP sin cifrar de estilo antiguo, esto incluye la conexión de datos, suponiendo que ip_conntrack_ftp esté cargado
- Rechazar todos los intentos de abrir una conexión TCP desde el exterior
- Rechazar todos los paquetes UDP iniciales (sin respuesta).
Alternativamente, puede usar -j DROP en las dos últimas reglas. Para una discusión sobre este tema, consulte ¿Rechazar paquetes IP con un error ICMP, o simplemente descartarlos?