¿Cómo configurar iptables para eliminar los paquetes que no estoy escuchando?

Si nunca lo has visto sin un script, aquí tienes un script de línea de base para que puedas lograrlo:

checkht="lsof -c httpd | awk '{print $1}' | uniq | grep h"

if [ -n "$checkht" ]; then

    echo "webserver is running let me shut down uptables rules blocking HTTP"
    iptables -vnL --line-numbers |awk '/tcp dpt:80/{print "iptables -D INPUT "$1}' | sh

else

   iptables -A INPUT -s 0.0.0.0/0 -p tcp --dport 80 -j DROP

fi

Comprueba si http se está ejecutando, si lo está, se asegura de que IPTABLES no tenga reglas que bloqueen HTTP. Si no se está ejecutando, impide que el mundo llegue a ese puerto. Sin embargo, debido a que no está escuchando en el puerto, la regla de bloquear tiene poco sentido. No hay nada para que nadie ataque, ya que nada está corriendo.

La respuesta corta es: no por diseño , y aquí hay un ejemplo de lo que tendría que suceder si fuera posible:

1. netcat abre el socket en el puerto X llamando a la llamada relativa al sistema (como listen )
2. kernel atrapa syscall, ejecuta el código de red (en este caso, abre el puerto)
3. kernel habla con el módulo relativo iptables (suponiendo que esté disponible y cargado) y abre un agujero en el firewall para permitir que el tráfico vaya al puerto recién abierto.

Esto abriría un posible agujero de seguridad: ¿cómo sabría el kernel que el programa es legítimo, es decir, no es un troyano que quiere abrir una shell remota? Aquí hay algunas respuestas:

• Porque el programa está en una lista blanca en alguna parte; pero esto cambiaría la seguridad a otro conjunto de problemas:
  • ¿cómo sabes que el programa no se ha comprometido? Podría usar algo como tripwire, pero esto abre otra pregunta de seguridad: ¿cómo puede garantizar que la lista maestra no se vea comprometida?
  • ¿Cómo lidias con las actualizaciones? P.ej. la versión Z de ssh puede perforar agujeros a través del firewall; su sistema se actualiza automáticamente, ahora el hash de ssh ha cambiado y usted está bloqueado.
• Porque el usuario que lo lanza pertenece a un grupo privilegiado: ¿cómo lidias con los binarios de SUID? Eche un vistazo a los permisos del programa ping , por ejemplo.

Otra lata de gusanos ^ W ^ W ^ W conjunto de posibles problemas sería la interfaz entre iptables (a nivel de kernel) y los syscalls; cada cambio menor en iptables requeriría una posible reescritura del código subyacente a las syscalls, la introducción de errores, etc.

En pocas palabras, estás describiendo el problema al que se enfrentan firewalls de aplicaciones (piensa en los firewalls de Windows o Mac). Es factible, pero no es simple.

A nivel de red, es posible que desee echar un vistazo a UPnP cuya función era permitir que los servicios hagan agujeros a través del firewall de una puerta de enlace. Con las obvias consecuencias de seguridad.

O podrías usar un script en su lugar :)

podría escribir un simple script de bash que analice la salida de netcat y construya un nuevo conjunto de reglas iptables en consecuencia cada vez que se ejecute.

Probablemente tenga que asegurarse de permitir las conexiones primero antes de establecer la regla de soltar todas las demás, ya que restablecería todas las conexiones en ejecución cada vez que se ejecute el script.

Luego, puedes establecer un cronjob que ejecutará tu script cada minuto.

Como lorenzog señaló que esta podría no ser la configuración más segura, por otra parte, si no tiene iptables en ejecución de forma predeterminada, probablemente esto sea mejor que nada.

También puede establecer un rango de puertos como una lista blanca e ignorar todos los otros puertos que netstat escupe ...

Como se trata de su caja Kali (VM?), de todos modos solo debería estar ejecutándose para tareas específicas. Kali no debe utilizarse como sistema operativo cliente / servidor predeterminado para las tareas diarias. Así que te dejaría escapar con este tipo de configuración de firewall dinámico;)