Consejos para una configuración segura de iptables para defenderse de los ataques. (¡lado del cliente!)

Me doy cuenta de que hay opiniones diferentes, pero una de las principales actitudes de las personas que realmente saben sobre redes y seguridad es que la mayoría de estas reglas de iptables / sysctl son redundantes, si no dañan a usted y a 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 interlocutor obtenga alguna pista sobre lo que está sucediendo. Tal vez alguien acaba de escribir una URL equivocada 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 es necesario eliminar 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 sobre qué tipo de paquetes son válidos y cuáles no. "¿Qué pasa con las fallas futuras", algunos podrían argumentar. Bueno, ¿cómo sabes que la falla futura estará en el controlador TCP y no en el analizador TCP de iptables?

• La mayoría de las configuraciones de sysctl están predeterminadas. Si no lo son, suele haber una razón. Por ejemplo, ¿por qué deshabilitar el envío de redirecciones? Me resulta muy útil que un par me informe de que mi enrutamiento es malo, incluso si nunca reaccionaría ("accept_redirects", predeterminado = 0) automáticamente.

• Con tus log_martians y otras reglas de registro, espero que también tengas una cuota en / var / log, o será muy divertido llenar tu disco de forma remota, generalmente matando tus servicios / aplicaciones. Además, debe usar un límite de velocidad para el registro o alguien podría completar la cuota para evitar que vea los intentos de robo de la contraseña de SSH en auth.log, u otras cosas. ¿Estás leyendo esos registros en un escritorio? Recomiendo logcheck.

• Pareces bloquear ICMP. Aparte del problema de DHCP mencionado, esto también evita el descubrimiento de PMTU. Sin PMTUD, obtendrá un comportamiento extraño cuando use el sistema en lugares con conexión DSL u otras configuraciones de red. Algunos paquetes simplemente se eliminarán y nadie te dirá por qué.

• El filtrado de 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. La mayoría de los sistemas operativos son incapaces de aislar a estos programas de escuchas ilegales o incluso de manipular los datos de otros programas (por ejemplo, ataques de tiempo de caché)

• Necesitas paquetes NUEVOS para tener SYN. Esto se interrumpirá si la 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 un escritorio tener un firewall?

• Si hay un ataque específico en las noticias a las que su SO o servidores actuales son vulnerables, y una de las soluciones rápidas recomendadas es una regla de firewall.

• Debe ejecutar ciertos servicios que no permiten una configuración segura. La mayoría lo hace, y el resto es mejor reemplazado por 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, hay netstat y nmap, que debe utilizar para encontrar y confirmar qué servicios está ejecutando. Luego simplemente deshabilite los que no necesita o confínelos a 127.0.0.1.

Bono si lees esto hasta aquí: los paquetes están ESTABLECIDOS, RELACIONADOS o NUEVOS, todo lo demás que sueltes. También sueltas NUEVO a menos que solo se establezca SYN. Dado que ESTABLISHED, RELATED parece marcar los indicadores, esto hace que todas las reglas --tcp-flags y también la regla -f sean redundantes. Lo mismo para OUTPUT, pero como no se ACEPTAN paquetes para OUTPUT, eso probablemente no importa.

Tendría cuidado al hacer que estos sean parte del mismo conjunto de reglas para dispositivos dentro de una red confiable y aquellos en una DMZ. Al usar las reglas que tiene definidas allí, no va a responder a un servidor DHCP preguntando (ICMP echo) si su IP está en uso. Esto podría llevar a una situación de dirección duplicada.

Yo crearía dos conjuntos diferentes de reglas para aplicar a cada escenario, algo como lo que se menciona arriba es una buena base para una máquina DMZ, pero crea algunos desafíos en una LAN típica.

También definitivamente recomendaría agregar el registro a marcianos, caídas salientes, conexiones caídas entrantes, etc. Esto puede ser crucial para la solución de problemas y puede ser más útil para que coman los 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

1. Permite todo en la interfaz local interna.
2. 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 tales como pequeñas consultas de DNS. Para el protocolo FTP sin cifrar de estilo antiguo, esto incluye la conexión de datos, asumiendo que ip_conntrack_ftp está cargado
3. Rechazar todos los intentos de abrir una conexión TCP desde el exterior
4. Rechazar todos los paquetes udp iniciales (sin respuesta).

Alternativamente, puedes usar -j DROP en las dos últimas reglas. Para una discusión sobre este tema, consulte ¿Rechazar paquetes IP con un error de ICMP, o simplemente eliminarlos?

Entonces, para elaborar su pregunta, esto es lo que he estado ejecutando (y usaré sus ejemplos con notas, ya que las mías están prácticamente sin comentarios, ya que se han llevado a la red de la red desde que IPCHAINS murió hace tantos años. )

Esto podría funcionar para un sistema interno, pero a menudo pasará tiempo configurando sus iptables para nuevas aplicaciones que no se tienen en cuenta. También eliminé mi regla de SSH, pero esa es una norma bastante estándar que verás (y en muchas configuraciones, la única que verás para permitir entradas).

###############
# VARIABLE DEFINITIONS
IPTABLES=/sbin/iptables

#Your DHCP Server for input of ICMP packets
DHCPSERVER=127.0.0.1
PUBIF=eth0

# KERNEL PARAMETER CONFIGURATION
#
# DROP ICMP ECHO-REQUEST MESSAGES SENT TO BROADCAST OR MULTICAST ADDRESSES
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
#
# DONT ACCEPT ICMP REDIRECT MESSAGES
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
#
# DONT SEND ICMP REDIRECT MESSAGES
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
#
# DROP SOURCE ROUTED PACKETS
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
#
# ENABLE TCP SYN COOKIE PROTECTION FROM SYN FLOODS
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
#
# ENABLE SOURCE ADDRESS SPOOFING PROTECTION
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

# LOG PACKETS WITH IMPOSSIBLE ADDRESSES (DUE TO WRONG ROUTES) ON YOUR NETWORK
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians

# DISABLE IPV4 FORWARDING
echo 0 > /proc/sys/net/ipv4/ip_forward
###############
$IPTABLES -F
###############
# LOGDROPPER
$IPTABLES -N LOGNDROP > /dev/null 2> /dev/null 
$IPTABLES -F LOGNDROP 
$IPTABLES -A LOGNDROP -j LOG --log-prefix "LOGNDROP: " 
$IPTABLES -A LOGNDROP -j DROP

###############
# LO allowance
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT

###############
# Only bring what you need to survive
$IPTABLES -A INPUT -p icmp -s $DHCPSERVER -j ACCEPT
$IPTABLES -A INPUT -i $PUBIF -s $DHCPSERVER -p tcp --sport 68 --dport 67 -j ACCEPT
$IPTABLES -A INPUT -i $PUBIF -s $DHCPSERVER -p udp --sport 68 --dport 67 -j ACCEPT
###############
# INPUT
#
# DROP INVALID
$IPTABLES -A INPUT -m state --state INVALID -j LOGNDROP

# ALLOW ONLY ESTABLISHED, RELATED
$IPTABLES -A INPUT -p tcp -i $PUBIF -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -p udp -i $PUBIF -m state --state ESTABLISHED,RELATED -j ACCEPT

# DROP INVALID SYN PACKETS
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j LOGNDROP
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j LOGNDROP
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j LOGNDROP

# MAKE SURE NEW INCOMING TCP CONNECTIONS ARE SYN PACKETS; OTHERWISE WE NEED TO DROP THEM
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOGNDROP

# DROP PACKETS WITH INCOMING FRAGMENTS. THIS ATTACK RESULT INTO LINUX SERVER PANIC SUCH DATA LOSS
$IPTABLES -A INPUT -f -j LOGNDROP

# DROP INCOMING MALFORMED XMAS PACKETS
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ALL -j LOGNDROP

# DROP INCOMING MALFORMED NULL PACKETS
$IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE -j LOGNDROP

###############
# OUTPUT

# DROP INVALID
$IPTABLES -A OUTPUT -m state --state INVALID -j LOGNDROP

# DROP INVALID SYN PACKETS
$IPTABLES -A OUTPUT -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j LOGNDROP
$IPTABLES -A OUTPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j LOGNDROP
$IPTABLES -A OUTPUT -p tcp --tcp-flags SYN,RST SYN,RST -j LOGNDROP

# DROP PACKETS WITH OUTGOING FRAGMENTS. THIS ATTACK RESULT INTO LINUX SERVER PANIC SUCH DATA LOSS
$IPTABLES -A OUTPUT -f -j LOGNDROP

# DROP OUTGOING MALFORMED XMAS PACKETS
$IPTABLES -A OUTPUT -p tcp --tcp-flags ALL ALL -j LOGNDROP

# DROP OUTGOING MALFORMED NULL PACKETS
$IPTABLES -A OUTPUT -p tcp --tcp-flags ALL NONE -j LOGNDROP

$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -A INPUT -j LOGNDROP
$IPTABLES -A FORWARD -j LOGNDROP

Si su red es ruidosa, o tiene muchas cosas en marcha, esto llenará su volumen de registro rápidamente. Pero estoy paranoico, y también destrozo a las personas si están creando configuraciones que son ruidosas innecesariamente.