Si tiene una conexión intermitente, tal como la conexión PPP, debería hacer que la primera regla de la cadena input sea '-i ppp0 -j DENY' en el momento del arranque, y luego tener algo como esto en tu script ip-up:
Su script ip-down podría decir algo como:# Re-crear la cadena `ppp-in' ipchains-restore -f < ppp-in.firewall # Remplazar la regla DENY con salto a la cadena que maneja ppp ipchains -R input 1 -i ppp0 -j ppp-in
ipchains -R input 1 -i ppp0 -j DENY
Un problema peor es el rol de los paquetes de ICMP en descubrimiento de MTU. Todas las buenas implementaciones de TCP (incluido Linux) usan el MTU, para intentar deducir que tan largos pueden ir los paquetes a un destino sin fragmentarse (la fragmentación ralentiza el rendimiento, sobre todo cuando ocasionalmente los fragmentos son perdidos). El MTU trabaja enviando paquetes con el bit "Don't fragment" seteado, y luego enviando paquetes más pequeños si obtiene un paquete ICMP indicando "Fragmentation needed but DF set" (necesidad de fragmentación). Este es un tipo de paquete "destination-unreachable", y si nunca se recibe, el host local nunca reducirá la MTU,
Todas las aplicaciones de TCP buenas (Linux incluyó) use descubrimiento de MTU para intentar deducir eso que el paquete más grande que puede conseguir a un destino sin fragmentarse (la fragmentación retarda actuación, sobre todo cuando los fragmentos ocasionales están perdidos). El descubrimiento de MTU trabaja enviando paquetes con el "no Fragmenta" el pedazo puso, y entonces enviando paquetes más pequeños si consigue un paquete de ICMP que indica "la Fragmentación necesitó pero DF puso" (`fragmentation--ed '). Éste es un tipo de `destination-inalcanzable ' el paquete, y si nunca se recibe, el organizador local no reducirá MTU, y el rendimiento será abismal o no existente.
Si sus consultas DNS siempre se dirigen a la misma fuente externa (cualquiera que sea usada en la linea nameserver en /etc/resolv.conf o usando un servidor de nombres de cacheo en modo forward), entonces sólo necesita permitir conexiones de TCP al puerto de 'domain' de esa maquina.
En modo activo, cuando el extremo remoto quiere enviar un archivo (o incluso los resultados de un comando 'ls' o 'dir') intenta abrir una conexión de TCP a la máquina local. Esto significa que no puede filtrar estas conexiones de TCP sin romper un FTP activo.
Si usted tiene la opción de usar modo pasivo, entonces bien; el modo pasivo hace conexiones de los datos del cliente al servidor, incluso para los datos entrantes. Por otra parte, se recomienda que usted sólo permita conexiones TCP de puertos por encima de 1024 y no entre 6000 y 6010 (se usa 6000 para X-Windows).
Si está protegiendo máquinas que podrían ser vulnerables, podría simplemente bloquear fragmentos de ICMP. Los paquetes de ICMP normales no son tan grandes como para requerir fragmentación, así que usted no interrupirá nada excepto los pings grandes. Yo he oído (sin confirmar) informes de que algunos sistemas solo requieren del último fragmento de un gran paquete ICMP para ser adulterados, así que el bloque del primer fragmento no es recomendable.
Aun cuando los programas de exploit que he visto solo usan ICMP, no hay razón para no que los fragmentos TCP o UDP (o de un protocolo desconocido) no puedan usarse en este ataque, asi que bloquear fragmentos de ICMP es sólo una solución temporal.
Esto desecha todos los paquetes mientras duran los cambios.# ipchains -I input 1 -j DENY # ipchains -I output 1 -j DENY # ipchains -I forward 1 -j DENY ... make changes ... # ipchains -D input 1 # ipchains -D output 1 # ipchains -D forward 1 #
Si restringe los cambios a una sola cadena, podría querer crear una nueva cadena con las nuevas reglas, y entonces reemplazar (` -R ') la regla que apuntó a la vieja cadena con una que apunte a la nueva. Este reemplazo ocurrirá atómicamente.
La mejor manera de protegerse del spoofing de IP se llama "Verificación
de la dirección del orígen" y es hecha por el código
de enrutamiento, y no en el de firewalling. Busque un archivo
llamado /proc/sys/net/ipv4/conf/all/rp_filter Si existe,
entonces activar la Verificación de la dirección de orígen
en el arranque es la mejor solución para usted. Para hacer
esto, inserte las siguientes lineas en alguna parte de sus scripts de inicio,
antes de que cualquier interface de red se inicialice (ej. Los usuarios
de Debian las pondrian en /etc/init.d/netbase si es que ellas ya
no esta allí).
Si no puede hacer esto, puede insertar reglas manualmente para proteger cada interface. Esto requiere conocimiento de cada interface. Los kernels 2.1 desechan automáticamente los paquetes que dicen venir de las direcciones 127.* (reservadas para el loopback local) lo# Esta es la mejor forma: activar la Verificación de Dirección Orígen # Protección de spoof en todas las interfaces if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]; then echo -n "Configurando protección de IP spoofing" for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f done echo "done." else echo PROBLEMAS PARA CONFIGURAR LA PROTECCION DE IP SPOOFING. PREOCUPESE. echo "Presione CONTROL-D para continuar..." echo # Iniciar un simple shell de usuario en la consola /sbin/sulogin $CONSOLE fi
Por ejemplo, digamos que tenemos tres interfaces, eth0, eth1 y ppp0. Podemos usar ifconfig para indicar la dirección y la máscara de subred de las interfaces. Digamos que eth0 pertenece a la red 192.168.1.0 con máscara de subred 255.255.255.0, eth1 pertenece a la red 10.0.0.0 con máscara 255.0.0.0 y que ppp0 se conectóa internet (donde cualquier dirección excepto las direcciones IP privadas reservadas se permiten), insertaríamos las siguientes reglas:
Esto no es tan bueno como la Verificación de la Dirección Orígen, porque si su red cambia, entonces tiene que cambiar sus reglas de firewalling.# ipchains -A input -i eth0 -s ! 192.168.1.0/255.255.255.0 -j DENY # ipchains -A input -i ! eth0 -s 192.168.1.0/255.255.255.0 -j DENY # ipchains -A input -i eth1 -s ! 10.0.0.0/255.0.0.0 -j DENY # ipchains -A input -i ! eth1 -s 10.0.0.0/255.0.0.0 -j DENY #
Si usted está ejecutando un kernel de la serie 2.0 , podría querer proteger el loopback también, usando una regla como:
# ipchains -A input -i ! lo -s 127.0.0.0/255.0.0.0 -j DENY #
Cosas tales como inspección de estado (prefiero el término firewalling dinámico) pueden llevarse a cabo en userspace que usa esta librería. Otras ideas ingeniosas incluyen el control de paquetes per-user haciendo un lookup en un daemon de userspace. Esto debe ser bastante fácil.
La capacidad `mark ' de los cortafuegos es subutilizada: podría usarse para representar una prioridad para el código Quality Of Service, lo cual haría que controle prioridades de paquete fácilmente.