Hay que tener en cuenta que cuando modificamos los parámetros vía sysctl los cambios surten efecto al instante, pero tras un reinicio se pierden, por eso conviene guardar las personalizaciones y cambios en el fichero de configuración de sysctl /etc/sysctl.conf. En alguna otra entrada ya hemos visto algún cambio de estos parámetros, como por ejemplo el valor del swappiness para optimizar el uso de memoria, que hacer ante un kernel panic o ip_conntrack_max.
Un ejemplo de lo que deberíamos tener configurado en sysctl.conf para disponer de una seguridad básica:
# IP Spoofing protection net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.rp_filter = 1 # Ignore ICMP broadcast requests net.ipv4.icmp_echo_ignore_broadcasts = 1 # Disable source packet routing net.ipv4.conf.all.accept_source_route = 0 net.ipv6.conf.all.accept_source_route = 0 net.ipv4.conf.default.accept_source_route = 0 net.ipv6.conf.default.accept_source_route = 0 # Ignore send redirects net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 0 # Block SYN attacks net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_max_syn_backlog = 2048 net.ipv4.tcp_synack_retries = 2 net.ipv4.tcp_syn_retries = 5 # Log Martians net.ipv4.conf.all.log_martians = 1 net.ipv4.icmp_ignore_bogus_error_responses = 1 # Ignore ICMP redirects net.ipv4.conf.all.accept_redirects = 0 net.ipv6.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv6.conf.default.accept_redirects = 0 # Ignore Directed pings net.ipv4.icmp_echo_ignore_all = 1
Si decidimos modificar el fichero mediante el uso del comando sysctl debemos saber:
Los parámetros a modificar se encuentran listados en /proc/sys/ y los más significativos son :
- dev : Establece los parámetros de configuración de los dispositivos conectados
- fs : Los parámetros relacionados con los sistemas de ficheros, inodes, quota, etc
- kernel : Comportamiento general del kernel
-net : Contiene los parámetros para configuración de la red
-vm : Se utiliza para la configuración de la memoria virtual.
La estructura del comando sysctl es :
sysctl [ parámetro ] variable=valor
Las opciones más habituales son :
-a : Muestra todos los valores disponibles
-w : Establece el valor indicado
-p : Carga en sysctl los valores definidos en el archivo /etc/sysctl.conf
Si establecemos un valor con la opción -w los cambios se pierden al reiniciar el equipo. Para evitar que esto ocurra hay que escribir los cambios en /etc/sysctl.conf
Un listado completo que se curró un tipo lo tenemos aquí:
https://klaver.it/linux/sysctl.conf
Asegurando tu pc con systcl
A continuación un ejemplo de como podemos asegurar nuestro PC con sysctl
disable ip_forward
Es para evitar enrutar paquetes entre distintas interfaces de red. Como se mencionó antes, este script está destinado a máquinas sin "ip forwarding".
enable icmp_echo_ignore_broadcasts
Con ésto hacemos que el sistema ignore los pedidos de PING a direcciones de broadcast. Los mismos no tienen sentido y pueden ser utilizados para ataques smurf.
enable icmp_ignore_bogus_error_responses
Esto protege al sistema de errores espúrios que algún atacante puede estar enviándonos. Sin esta directiva, el sistema enviaría a syslog este tipo de errores, generando carga en CPU, disco, posiblemente red y pudiendo llegar al extremo de llenar la partición de log. Con esta directiva estos errores son ignorados silenciosamente.
enable rp_filter
Mediante esta directiva se filtran paquetes que entran por una interfaz, pero con un IP de origen que está enrutado por otra interfaz. El kernel consulta por dónde enrutaría el paquete si el mismo fuese de salida y si la interfaz resultante es distinta a la que está entrando, el paquete se descarta silencionsamente. IPSEC se queja si se utiliza esta directiva sobre interfaces de red físicas.
disable accept_source_route
Aquí le decimos al sistema operativo que no acepte paquetes que indiquen desde origen por dónde se deben enrutar, sino que confiamos en las tablas de routing del sistema operativo.
disable accept_redirects
Esto instruye al sistema para que ignore paquetes ICMP del tipo "redirect". Independientemente de si estos paquetes sean bloqueados o no luego por IPTABLES, el sistema los ignorará y no cambiará sus tablas de routing.
disable send_redirects
Asimismo se pide que el sistema no envíe este tipo de paquetes, que de todos modos sólo deberían enviarlos los routers (y, como ya se ha dicho antes, este script es para sistemas sin "ip forwarding").
disable log_martians
Esta directiva indica que se deben ignorar silenciosamente los paquetes con IPs "imposibles". Hay otra línea de pensamiento según la cual se debe alertar por syslog de la presencia de estos paquetes en la red (utilizando "enable" en vez de "disable"). Sin embargo, considero que ignorarlos al menos es coherente con la recomendación anterior de ignorar los paquetes espúrios. Personalmente prefiero no ver estos paquetes en el log del sistema, especialmente en instalaciones con máquinas Windows mal configuradas ya que a menudo estas se "autoconfiguran" con IPs del rango 169.254.0.0/16 en segmentos de red con otra numeración, haciéndolos candidatos ideales a IPs "imposibles".
enable tcp_timestamps
Mediante esta directiva, se habilita la utilización de timestamps tal y como está documentado en la RFC 1323. Esto ayuda a calcular el tiempo total de ida y vuelta desde que se envía un paquete TCP al servidor remoto y se recibe su correspondiente ACK. Este tiempo es muy importante para determinar con precisión el timeout de retransmisión, evitando retransmisiones innecesarias y aumentando así el ancho de banda percibido. También esto agrega 12 bytes al encabezado TCP, por lo que no se recomienda su utilización en conexiones muy lentas, como por ejemplo vínculos satelitales lentos, leased lines, módems de 56K, etc.
Hay opiniones encontradas sobre la seguridad y la utilidad de los timestamps. Por un lado, tienen la "vulnerabilidad" de que es teóricamente posible descubrir el uptime de una máquina que utilice TCP timestamps. También hay gente que ha reportado problemas con esta opción. Sin embargo, por otro lado se hace prácticamente imprescindible con redes muy rápidas, pero que tengan altas latencias, o que puedan sufrir congestiones o retrasos. Los paquetes TCP de una conexión tienen un número de secuencia de 32 bits para el caso que lleguen a destino desordenados o que lleguen duplicados. Una transmisión sostenida a 1Gbps utilizará todos los números de secuencia en poco más de 30 segundos. Si un paquete se demora debido a una congestión momentánea puede darse el caso de tener 2 paquetes distintos en tránsito con el mismo número de secuencia, algo que hay que evitar por todos los medios. Si se utiliza tcp_timestamps se puede determinar cuál paquete es cuál, evitando confusiones.
enable tcp_syncookies
Con esta directiva el sistema operativo se protege contra un ataque de denegación de servicio consistente en llenar la cola de conexiones semi-abiertas (usualmente unos pocos cientos de entradas, consultar /proc/sys/net/ipv4/tcp_max_syn_backlog en vuestra instalación). El ataque puede hacerse muy fácilmente enviando muchos paquetes SYN, pero no completando el protocolo incial de conexión, lo que llena rápidamente la cola de conexiones semi-abiertas de la máquina atacada. En contraste, el o los atacantes no necesitan guardar ningún tipo de cola o tabla, ya que sólo se dedican a enviar paquetes SYN, posiblemente desde direcciones IP falsas. Si la máquina atacada no está utilizando tcp_syncookies comenzará a rechazar conexiones al llenarse dicha cola, posiblemente rechazando conexiones válidas, denegando el servicio.
Al utilizar tcp_syncookies, una máquina con la cola de conexiones semi-abiertas llena sigue sin poder guardar más conexiones allí, pero en vez de eso envía un paquete de respuesta SYN/ACK especial al equipo que solicita la conexión. Dicho paquete contiene un número de secuencia especial (calculado a partir de los números IP y puertos origen y destino, además de una marca horaria) y si el o los atacantes estaban utilizando IPs falsos nunca lo recibirán ni responderán. Por el contrario, en un intento válido de conexión se recibirá y responderá correctamente este paquete, incluyendo el número de secuencia y completando así el protocolo inicial de conexión (la máquina permite la conexión aunque no haya una entrada en la cola de conexiones semi-abiertas ya que es capaz de recuperar la información que se guardaría allí desde el número de secuencia cuidadosamente calculado).
En todo caso, este mecanismo respeta todos los protocolos (la elección del número de secuencia inicial es responsabilidad de la máquina que recibe el pedido de conexión y puede seleccionar cualquier número, ya sea aleatorio o calculado) y sólo entra en funcionamiento en caso de ataque o sobrecarga, no en situaciones normales.
disable tcp_sack
Esta facilidad, definida en la RFC 2018, se utiliza para aumentar el rendimiento evitando largas retransmisiones ya que permite identificar selectivamente los paquetes que se deben retransmitir (de allí su nombre). Sin embargo, un atacante puede utilizarla para forzar a la máquina víctima a hacer costosas búsquedas dentro de la cola de paquetes en vuelo. Dichas búsquedas pueden consumir bastante CPU, denegando su utilización para otras aplicaciones y clientes en la máquina atacada. También se puede alargar muchísimo el tiempo de transferencia pidiendo constantes retransmisiones, durante todo el cual tendremos un alto consumo de CPU. La máquina del atacante no necesita tener grandes cantidades de memoria ni consumir mucha CPU. Si multiplicamos este tipo de ataques por varios clientes maliciosos, tenemos un ataque distribuído de denegación de servicio en toda regla. Por este motivo se recomienda no activar esta opción.
Fuente: http://www.kriptopolis.org/iptables-1
No hay comentarios:
Publicar un comentario