En general:
Ver y modificar la configuración del firewall requiere privilegios de administrador ( root) al igual que abrir servicios en el rango de número de puerto restringido. Eso significa que debe iniciar sesión como rooto utilizar alternativamente sudopara ejecutar el comando como root. Intentaré marcar tales comandos con el opcional [sudo].
Contenido:
- El orden importa o la diferencia entre
-Iy-A
- Mostrar la configuración actual del firewall
- Interpretando la salida de
iptables -L -v -n
- Conoce tu entorno
- Las cadenas INPUT y FORWARD
- Módulos del núcleo
1. El orden importa o la diferencia entre -Iy-A
Lo que debe recordar es que las reglas del firewall se verifican en el orden en que se enumeran. El núcleo dejará de procesar la cadena cuando se active una regla que permitirá o deshabilitará un paquete o conexión.
Creo que el error más común para los administradores de firewall novatos es que siguen las instrucciones correctas para abrir un nuevo puerto, como el siguiente:
[sudo] iptables -A INPUT -i eth0 -p tcp --dport 8080 -j ACCEPT
y luego descubre que no tendrá efecto.
La razón de esto es que la -Aopción agrega esa nueva regla, después de todas las reglas existentes
y dado que muy a menudo la regla final en el firewall existente era una que bloquea todo el tráfico que no está explícitamente permitido, lo que resulta en
...
7 2515K 327M REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
8 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080
O equivalente en iptables-save:
...
iptables -A INPUT -j REJECT
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
y nunca se alcanzará la nueva regla que abre el puerto TCP 8080. (como lo demuestran los contadores que permanecen obstinadamente en 0 paquetes y cero bytes).
Al insertar la regla con -Ila nueva regla habría sido la primera en la cadena y funcionará.
2. Visualice la configuración actual del firewall
Mi recomendación para el administrador del firewall es mirar la configuración real que está ejecutando el kernel de Linux, en lugar de tratar de diagnosticar problemas de firewall con herramientas fáciles de usar. A menudo, una vez que comprende los problemas subyacentes, puede resolverlos fácilmente en un asunto respaldado por esas herramientas.
El comando [sudo] iptables -L -v -nes tu amigo (aunque a algunas personas les gusta iptables-savemás). A menudo, cuando se discuten configuraciones, es útil usar la --line-numbersopción también para numerar líneas. Refiriéndose a la regla #X hace que discutirlos sea algo más fácil.
Nota: las reglas de NAT están incluidos en la iptables-savesalida, pero que muestran por separado mediante la adición de la -t natopción es decir, [sudo] iptables -L -v -n -t nat --line-numbers.
Ejecutar el comando varias veces y verificar el incremento de contadores puede ser una herramienta útil para ver si una nueva regla realmente se activa.
[root@host ~]# iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 784K 65M fail2ban-SSH tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
2 2789K 866M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
3 15 1384 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
4 44295 2346K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
5 40120 2370K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80
6 16409 688K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443
7 2515K 327M REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT 25 packets, 1634 bytes)
num pkts bytes target prot opt in out source destination
Chain fail2ban-SSH (1 references)
num pkts bytes target prot opt in out source destination
1 0 0 REJECT all -- * * 117.239.37.150 0.0.0.0/0 reject-with icmp-port-unreachable
2 4 412 REJECT all -- * * 117.253.208.237 0.0.0.0/0 reject-with icmp-port-unreachable
Alternativamente, la salida de iptables-saveda un script que puede regenerar la configuración de firewall anterior:
[root@host ~]# iptables-save
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [441:59938]
:fail2ban-SSH - [0:0]
-A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A fail2ban-SSH -s 117.239.37.150/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-SSH -s 117.253.208.237/32 -j REJECT --reject-with icmp-port-unreachable
COMMIT
Es una cuestión de preferencia lo que encontrará más fácil de entender.
3. Interpretar la salida de iptables -L -v -n
La política establece la acción predeterminada que usa la cadena cuando no coincide ninguna regla explícita. En la INPUTcadena configurada para ACEPTAR todo el tráfico.
La primera regla en la cadena INPUT es inmediatamente interesante, envía todo el tráfico (fuente 0.0.0.0/0 y destino 0.0.0.0/0) destinado al puerto TCP 22 ( tcp dpt:22) el puerto predeterminado para SSH a un destino personalizado ( fail2ban-SSH) . Como su nombre lo indica, fail2ban mantiene esta regla (un producto de seguridad que, entre otras cosas, analiza los archivos de registro del sistema para detectar posibles abusos y bloquea la dirección IP del abusador).
Esa regla habría sido creada por una línea de comandos de iptables similar ao iptables -I INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSHse encuentra en la salida de iptables-save as -A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH. A menudo encontrará cualquiera de esas anotaciones en la documentación.
Los contadores indican que esta regla ha coincidido con 784'000 paquetes y 65 megabytes de datos.
El tráfico que coincide con esta primera regla es procesado por la fail2ban-SSHcadena que, como una cadena no estándar, se enumera debajo de la cadena de SALIDA.
Esa cadena consta de dos reglas, una para cada abusador (dirección IP de origen 117.253.221.166 o 58.218.211.166) que está bloqueada (con a reject-with icm-port-unreachable).
-A fail2ban-SSH -s 117.253.221.166/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-SSH -s 58.218.211.166/32 -j REJECT --reject-with icmp-port-unreachable
Los paquetes SSH que no son de esos hosts bloqueados aún no están permitidos ni deshabilitados, y ahora que la cadena personalizada se haya completado se verificará con la segunda regla en la cadena INPUT.
Todos los paquetes que no estaban destinados al puerto 22 pasaron la primera regla en la cadena INPUT y también serán evaluados en la regla INPUT # 2.
La regla de ENTRADA número 2 hace que este sea un firewall con estado , que rastrea las conexiones. Esto tiene algunas ventajas, solo los paquetes para las nuevas conexiones deben verificarse con el conjunto completo de reglas, pero una vez permitidos, se aceptan paquetes adicionales que pertenecen a una conexión establecida o relacionada sin una verificación adicional.
La regla de entrada n. ° 2 coincide con todas las conexiones abiertas y relacionadas y los paquetes que coinciden con esa regla no tendrán que evaluarse más.
Nota: los cambios de reglas en la configuración de un firewall con estado solo afectarán las conexiones nuevas, no las conexiones establecidas.
En contraste, un filtro de paquete simple prueba cada paquete contra el conjunto completo de reglas, sin rastrear el estado de la conexión. En dicho firewall no se utilizarían palabras clave de estado .
La regla INPUT # 3 es bastante aburrida, todo el tráfico que se conecta a la lointerfaz loopback ( o 127.0.0.1) está permitido.
Las reglas INPUT 4, 5 y 6 se usan para abrir los puertos TCP 22, 80 y 443 (los puertos predeterminados para SSH, HTTP y HTTPS resp.) Al otorgar acceso a NUEVAS conexiones (las conexiones existentes ya están permitidas por la regla INPUT 2).
En un firewall sin estado, esas reglas aparecerían sin los atributos de estado:
4 44295 2346K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
5 40120 2370K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
6 16409 688K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
o
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
La regla INPUT final, # 7 es una regla que bloquea todo el tráfico al que NO se le otorgó acceso en las reglas INPUT 1-7. Una convención bastante común: todo lo que no está permitido se niega. En teoría, esta regla podría haberse omitido al establecer la POLÍTICA predeterminada en RECHAZAR.
Siempre investiga toda la cadena.
4. Conoce tu entorno
4.1. La configuración en un firewall de software no afectará la configuración de seguridad mantenida en otra parte de la red, es decir, a pesar de abrir un servicio de red con iptableslas listas de control de acceso no modificadas en los enrutadores u otros firewalls en su red, aún puede bloquear el tráfico ...
4.2. Cuando no hay ningún servicio escuchando, no podrá conectarse y obtener un error de conexión rechazada , independientemente de la configuración del firewall. Por lo tanto:
- Confirme que un servicio está escuchando (en la interfaz de red / dirección IP correcta) y utilizando los números de puerto que espera
[sudo] netstat -plnuto utiliza alternativamente ss -tnlp.
- Si aún no se supone que sus servicios se estén ejecutando, emule un escucha simple con, por ejemplo, netcat:
[sudo] nc -l -p 123o openssl s_server -accept 1234 [options] si necesita un escucha TLS / SSL (verifique las man s_serveropciones).
- Verifique que puede conectarse desde el propio servidor, es decir,
telnet <IP of Server> 123o echo "Hello" | nc <IP of Server> 123cuando pruebe el servicio seguro TLS / SSL openssl s_client -connect <IP of Server>:1234, antes de intentar lo mismo desde un host remoto.
4.3. Comprenda los protocolos utilizados por sus servicios. No puede habilitar / deshabilitar adecuadamente los servicios que no comprende suficientemente. Por ejemplo:
- ¿Se utiliza TCP o UDP o ambos (como con DNS)?
- ¿utiliza el servicio un puerto predeterminado fijo (por ejemplo, algo como el puerto TCP 80 para un servidor web)?
- alternativamente, ¿se elige un número de puerto dinámico que puede variar (es decir, servicios RPC como NFS clásico que se registra con Portmap)?
- FTP infame incluso utiliza dos puertos , un número de puerto fijo y uno dinámico cuando se configura para usar el modo pasivo ...
- Las descripciones de servicio, puerto y protocolo
/etc/servicesno coinciden necesariamente con el servicio real que utiliza un puerto.
4.4. El filtro de paquetes del núcleo no es lo único que puede restringir la conectividad de red:
- SELinux también podría estar restringiendo los servicios de red.
getenforceconfirmará si SELinux se está ejecutando.
- Aunque los TCP Wrappers se vuelven un poco oscuros siguen siendo una herramienta poderosa para hacer cumplir la seguridad de la red. Consulte con
ldd /path/to/service |grep libwrapy los /hosts.[allow|deny]archivos de control.
5. INPUTo FORWARDcadenas
El concepto de cadenas se explica más a fondo aquí, pero en resumen:
La INPUTcadena es donde abre y / o cierra puertos de red para servicios que se ejecutan localmente, en el host donde emite los comandos de iptables.
La FORWARDcadena es donde aplica reglas para filtrar el tráfico que el núcleo reenvía a otros sistemas, sistemas reales, pero también contenedores Docker y servidores de Servidores invitados virtuales cuando su máquina Linux actúa como un puente, enrutador, hipervisor y / o dirección de red traducción y reenvío de puertos.
Una idea errónea común es que, dado que un contenedor Docker o un invitado KVM se ejecuta localmente, las reglas de filtro que se aplican deben estar en la cadena INPUT, pero ese no suele ser el caso.
6. Módulos del núcleo
Dado que el filtro de paquetes se ejecuta dentro del kernel de Linux, también se puede compilar como módulo dinámico, en realidad, múltiples módulos. La mayoría de las distribuciones incluyen netfilter como módulos y los módulos de netfilter necesarios se cargarán en el kernel según sea necesario, pero para algunos módulos un administrador de firewall deberá asegurarse manualmente de que se carguen. Esto se refiere principalmente a los módulos de seguimiento de conexión, como los nf_conntrack_ftpque se pueden cargar insmod.
Los módulos cargados actualmente en el kernel en ejecución se pueden mostrar con lsmod.
El método para garantizar que los módulos se carguen de forma persistente en los reinicios depende de la distribución de Linux.
