Tienda Wifi

Tienda Wifi
CiudadWireless es la tienda Wifi recomendada por elhacker.NET

Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon Mitigación de ataques UDP Reflection DrDoS


Los ataques DrDDoS (Reflection) están de moda. Según todos los estudios de grandes empresas como CloudFlare, Akamai, Incapsula, Prolexic, Fortinet, Arbor, etc cada vez se producen con mayor frecuencia e intensidad. Existen de varios tipos de ataques basados en UDP (User Datagram Protocol.), pero sin duda los de mayor peligro son los DrDDoS al existir una gran variedad de protocolos explotables mediante IP Spoofing como Chargen, SSDP, NTP o LDAP.




Durante los últimos meses varios servidores de Team Speak han estado recibiendo continuos ataques DDoS usando DrDDoS (basados en UDP).

PostHeaderIcon Ataques UDP Reflection Flood DrDoS (Inundación mediante Reflexión y Amplificación)


A continuación se describen algunos ejemplos de mitigación de los diferentes tipos de ataques. Los ataques suelen ser siempre Chargen (source port 19), NTP (puerto origen 123) y SSPD (UPNP) (puerto origen 1900).


UDP es un protocolo no orientado a conexión, sin control de errores. UDP no garantiza la entrega ni comprueba la secuencia de los datagramas. UDP es rápido y permite multidifusión (un datagrama, muchos destinatarios)

UDP tiene dos "estados"  aunque sea un protocolo "stateless"

  • Unreplied
  • Assured
Es importante tener en cuenta que hay un máximo de pps (packets per second) que puede procesar nuestro ancho de banda (velocidad).

Máximo paquetes por segundo según la velocidad de red:


Podemos monitorizar los paquetes por segundo con herramientas de tráfico como ntopng, iptraf, ss o directamente desde el kernel:

  • /sys/class/net/eth0/statistics/rx_packets: número de paquetes recibidos
  • /sys/class/net/eth0/statistics/tx_packets: número de paquetes transmitidos
Medir paquetes por segundo con un sencillo script bash:

#!/bin/bash
INTERVAL="1"  # update interval in seconds
if [ -z "$1" ]; then
        echo
        echo usage: $0 [network-interface]
        echo
        echo e.g. $0 eth0
        echo
        echo shows packets-per-second
        exit
fi
IF=$1
while true
do
        R1=`cat /sys/class/net/$1/statistics/rx_packets`
        T1=`cat /sys/class/net/$1/statistics/tx_packets`
        sleep $INTERVAL
        R2=`cat /sys/class/net/$1/statistics/rx_packets`
        T2=`cat /sys/class/net/$1/statistics/tx_packets`
        TXPPS=`expr $T2 - $T1`
        RXPPS=`expr $R2 - $R1`
        echo "TX $1: $TXPPS pkts/s RX $1: $RXPPS pkts/s"
done
O un script más completo y personalizado escrito en Python que permite configurar el puerto:




Errores en el /var/syslog o dmesg (mensajes del kernel)

[..]
UDP: bad checksum. From 124.193.31.122:19 to 91.126.240.73:9987 ulen 2974
UDP: bad checksum. From 14.41.56.229:19 to 91.126.240.73:9987 ulen 4457
UDP: bad checksum. From 1.215.244.35:19 to 91.126.240.73:9987 ulen 2979
UDP: bad checksum. From 222.81.62.71:19 to 91.126.240.73:9987 ulen 1492
UDP: bad checksum. From 211.219.0.193:19 to 91.126.240.73:9987 ulen 3876
UDP: bad checksum. From 211.219.0.193:19 to 91.126.240.73:9987 ulen 4128
UDP: bad checksum. From 211.219.0.193:19 to 91.126.240.73:9987 ulen 4674
UDP: bad checksum. From 59.27.106.194:19 to 91.126.240.73:9987 ulen 4450
UDP: bad checksum. From 222.81.62.71:19 to 91.126.240.73:9987 ulen 4454
UDP: bad checksum. From 112.187.159.189:19 to 91.126.240.73:9987 ulen 1497
UDP: bad checksum. From 66.46.124.134:19 to 91.126.240.73:9987 ulen 5940
UDP: bad checksum. From 124.193.31.162:19 to 91.126.240.73:9987 ulen 2977
UDP: bad checksum. From 66.46.124.134:19 to 91.126.240.73:9987 ulen 1490
UDP: bad checksum. From 14.41.56.229:19 to 91.126.240.73:9987 ulen 1501
UDP: bad checksum. From 1.215.244.35:19 to 91.126.240.73:9987 ulen 1487
UDP: bad checksum. From 124.193.31.122:19 to 91.126.240.73:9987 ulen 2980
UDP: bad checksum. From 59.17.206.69:19 to 91.126.240.73:9987 ulen 1498
UDP: bad checksum. From 46.183.220.250:3099 to 91.126.240.73:1434 ulen 9
[..]

Los errores net_ratelimit los podemos "ignorar" porque son simplemente que al kernel no le hado tiempo de escirbirlo en el syslog

Apr  8 16:27:30 kernel: net_ratelimit: 6 callbacks suppressed
Apr  8 16:37:32 kernel: net_ratelimit: 16 callbacks suppressed
Apr  8 16:40:44 kernel: net_ratelimit: 16 callbacks suppressed
Apr  8 16:41:02 kernel: net_ratelimit: 10 callbacks suppressed
Apr  8 16:41:09 kernel: net_ratelimit: 5 callbacks suppressed
Apr  8 16:41:23 kernel: net_ratelimit: 8 callbacks suppressed
Apr  8 16:41:34 kernel: net_ratelimit: 4 callbacks suppressed
Apr  8 16:41:39 kernel: net_ratelimit: 5 callbacks suppressed
Apr  8 16:41:45 kernel: net_ratelimit: 5 callbacks suppressed
Apr  8 16:42:01 kernel: net_ratelimit: 7 callbacks suppressed
Apr  8 16:42:07 kernel: net_ratelimit: 5 callbacks suppressed
Apr  8 16:46:13 kernel: net_ratelimit: 7 callbacks suppressed

Errores

[..]
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
[..]

Tablas y cadenas de iptables




iptables tiene tres tablas (-t)

  • FILTER (filtrado, tabla por defecto)
  • NAT (PREROUTING, POSTROUTING)
  • MANGLE (alteración de paquetes, QoS)
 Chains (reglas) (-A (append) -I (insertar) de FILTER

  • INPUT (entrada)
  • FORWARD (redirección, router, NAT (DMZ))
  • OUTPUT (salida)
 Si usamos forward debemos activar el el soporte para el reenvío IP:

net.ipv4.ip_forward=1

La tabla NAT está formada por tres cadenas:

  • PREROUTING: Permite modificar paquetes entrantes antes de que se tome una decisión de enrutamiento.
  • OUTPUT: Permite modificar paquetes generados por el propio equipo después de enrutarlos
  • POSTROUTING: Permite modificar paquetes justo antes de que salgan del equipo.

Por ejemplo si intenenmos hacer una regla con la tabla NAT y la acción DROP:

iptables -t nat -I PREROUTING -p udp --sport 19 -j DROP

No es posible:
The "nat" table is not intended for filtering, the use of DROP is therefore inhibited.

Si estamos detrás de un router (NAT), hay que usar la cadena FORWARD en este caso para hacer -j DROP

iptables -A FORWARD -p udp --sport 19 -j DROP

Acciones (-j)

  • ACCEPT (permite que el paquete pase)
  • REJECT (antes DENY) (se contesta que el servicio no está disponible (icmp destination port unrechable)
  • DROP (no se contesta nada)

Jugando con Iptables

Hay que recordar que cuando se crea un conjunto de reglas iptables, el orden es importante. El orden es secuencial de arriba a abajo. Por eso hay que tener muy encuenta el -I que insertará en primer lugar o el -A (append) añadirá al final la nueva regla.

Por ejemplo /etc/sysconfig/iptables:

-A INPUT -p udp -m udp --sport 19 -j DROP
-A INPUT -p udp -m udp --sport 19 -j LOG  --log-prefix "Ataque 19 udp chargen " --log-level 4
La anterior regla nunca funcionará, porque primero dropea los paquetes y ya no llegará nunca a logearlos.

 El orden correcto es:

-A INPUT -p udp -m udp --sport 19 -j LOG  --log-prefix "Ataque 19 udp chargen " --log-level 4
-A INPUT -p udp -m udp --sport 19 -j DROP

Los ataques quedarán automáticamente logeados en el syslog

Ejemplo para ver los paquetes que han pasado por el filtro en iptables:

iptables -L -v -n | less
Chain INPUT (policy ACCEPT 289M packets, 45G bytes)
 pkts bytes target     prot opt in     out     source               destination
5781K   23G LOG        udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp spt:19 LOG flags 0 level 4 prefix `Ataque 19 udp chargen '
5781K   23G DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp spt:19

Posibles contramedidas contra ataques DDoS basados en UDP

  • Ipset (permite banear por países de manera rápida y eficiente)
  • iptables con el módulo u32 (próximamente los veremos)

Baneando Países enteros con IPSet

Una alternativa al uso de IPSET es utilizar listados enormes de reglas iptables bloqueando rangos enteros de países.

http://www.ip2location.com/free/visitor-blocker

De un listado de ip's (blocklist.txt)

#!/bin/bash
#Script to process ip ranges to ban using IPSet and IPTables
ipset create countryblock hash:net
while read line; do ipset add countryblock $line; done < blocklist.txt
iptables -I INPUT -m set --match-set countryblock src -j DROP


Ejemplo con los países deChina(cn) Korea(kr) Taiwan(tw) Pakistan(pk) Singapore(sg) HongKong(hk)
ipset -N geoblock nethash
for IP in $(wget -O – http://www.ipdeny.com/ipblocks/data/countries/{cn,kr,pk,tw,sg,hk}.zone)
do
ipset -A geoblock $IP
done
Matching against the IPSet in IPTables:

iptables -A INPUT -m set –set geoblock src -j DROP
Otro ejemplo en bash script:

for IP in $(wget -O - http://www.ipdeny.com/ipblocks/data/countries/countryX.zone)
do
    # regular big hammer - block port 22 for countryX
    sudo ipset add geoblock $IP,22
done
Y aplicando la regla:
iptables -I INPUT -m set --set geoblock src -j DROP

Ejemplo de banear a China:

# Create the ipset list
ipset -N china hash:net # remove any old list that might exist from previous runs of this script
rm cn.zone
# Pull the latest IP set for China
wget -P . http://www.ipdeny.com/ipblocks/data/countries/cn.zone
# Add each IP address from the downloaded list into the ipset 'china'
for i in $(cat /etc/cn.zone ); do ipset -A china $i; done
# Restore iptables
/sbin/iptables-restore < /etc/iptables.firewall.rules
Aplicando la regla a iptables:
iptables -A INPUT -p tcp -m set --match-set china src -j DROP

Otro ejemplo:

# Block incoming traffic from some countries. cn and pk is for China and Pakistan. See other countries code at http://www.ipdeny.com/ipblocks/
if [ "$(ipset --swap BlockedCountries BlockedCountries 2>&1 | grep 'Unknown set')" != "" ]
then
    ipset -N BlockedCountries nethash
    for country in pk cn
    do
        [ -e $IPSET_LISTS_DIR/$country.lst ] || wget -q -O $IPSET_LISTS_DIR/$country.lst http://www.ipdeny.com/ipblocks/data/countries/$country.zone
        for IP in $(cat $IPSET_LISTS_DIR/$country.lst)
        do
            ipset -A BlockedCountries $IP
        done
    done
fi
[ -z "$(iptables-save | grep BlockedCountries)" ] && iptables -I INPUT -m set --set BlockedCountries src -j DROP
Ejemplo de reglas ataque UDP Chargen source port 19, SSDP (Upnp) Puerto origen 1900 y NTP puerto origen 123).

iptables -I INPUT -p udp --sport 19 -j DROP
iptables -I INPUT -p udp --sport 1900 -j DROP
iptables -I INPUT -p udp --sport 123 -j DROP

Y comprobar los paquetes y tráfico "dropeado"

iptables -L -v -n | less

 Chain INPUT (policy ACCEPT 211K packets, 19M bytes)
 245K   79M DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0
          udp spt:1900

Manejando y procesando muchos paquetes UDP

Con el comando:
netstat -su
 Podemos ver los paquetes UDP recibidos y con errores

Udp:
    549439142 packets received
    2385643 packets to unknown port received.
    22270 packet receive errors
    1101315355 packets sent

O usando ss (iproute2)

ss -ua

kernel
net.ipv4.udp_rmem_min = 131072
net.ipv4.udp_wmem_min = 131072
net.core.netdev_max_backlog=2000
net.core.rmem_max=67108864

Iptables Vs Null-Route

A veces es mejor no usar iptables para bloquear IPs. Utilizar la tabla de enrutamiento (route table) para hacer un null-route a esa ips, es decir que las redirija a un agujero negro (blackhole).

 Incluso si la tabla de enrutamiento no está destinado a reemplazar el firewall, se puede utilizar porque es más rápida y utiliza muchos menos recursos del sistema (casi ninguno) que un firewall de software durante el ataque y, lo más importante, cuando una IP es-encamina nulo, si es falsa o no, el núcleo se detendrá cualquier retransmisión adicional de segmentos SYN / ACK, por tanto, se librará de las conexiones medio abiertas (SYN_RECV) más rápido de esa manera, ya que serán eliminados de la tcp_max_syn_backlog al final de la actual retransmisión.

Las reglas de ruteo son mucho más simples que iptables. Con iptables, un match puede basarse en muchas variables diferentes, incluyendo protocolos, origen y destino de los paquetes, e incluso otros paquetes que fueron enviados antes de que el paquete actual. En el enrutamiento, lo único que importa es la dirección IP remota, así que es muy fácil de optimizar. Además, muchos sistemas tienen un montón de reglas de enrutamiento. Un sistema típico sólo puede tener 5 o 10, sino algo que está actuando como un router BGP puede tener decenas de miles. Por lo tanto, durante mucho tiempo ha habido extensas optimizaciones en la selección de la ruta correcta para un paquete particular.

Sin embargo, esto no protege contra la mayoría de los ataques UDP y también es importante tener en cuenta que los paquetes el extremo remoto envía do alcanzar el sistema. Es sólo respuestas que no vuelva. Así, una conexión TCP no se puede establecer, el bloqueo de las cosas como el correo electrónico distribuido ataque de denegación de servicio.

Con iptables:
iptables -I INPUT -s $REMOTEADDRESS -j DROP

Con un null-route:

ip route add blackhole $REMOTEADDRESS

Posibles Soluciones (mitigaciones)

  • Aumentar/Incrementar tamaño de búffers (para poder procesar muchos paquetes)
  • Disminuir tiempos de espera (timeout) (para no llenar nunca la cola de paquetes en espera y poder procesar correctamente todos los paquetes que nos llegan).

- Aumentar el tamaño del buffer UDP desde 128K a 32MB

sysctl -w net.core.rmem_max=33554432
o bien:

echo 33554432 > /proc/sys/net/core/rmem_max

- Incrementar el tamaño de la cola para los paquetes entrantes. En Ubuntu, por defecto es 1.000

sysctl -w net.core.netdev_max_backlog=2000
o en "directo":

echo 2000 > /proc/sys/net/core/netdev_max_backlog

- Disminuyendo el timeout de UDP (por defecto suele ser 30 segundos)

echo  15 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout

Los valores del /proc/sys/net/ipv4 controlan la pila ipv4, número de conexiones en espera, número de conexiones máximas, reduciendo valores de tiemout,


  • tcp_max_syn_backlog (/proc/sys/net/ipv4/tcp_max_syn_backlog)
  • tcp_syncookies (/proc/sys/net/ipv4/tcp_syncookies)
  • somaxconn (/proc/sys/net/core/somaxconn)  incluye sockfd y backlog
  • tcp_synack_retries
  • ip_conntrack_max ( ip_conntrack: table full, dropping packet.) y nf_conntrack_max 
  • ip_conntrack_tcp_timeout_syn_recv (net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv)
Tuning y hardering sysctl.conf
http://wiki.elhacker.net/sistemas-operativos/gnulinux/tuning-sysctl-conf

Optimizando el Kernel de Linux (sysctl.conf)

/etc/sysctl.conf

El fichero de configuración sysctl.conf se encaraga de leer los parámetros del kernel.

Mostrar  todas las variables configuradas
sysctl -a

Cargar todas las variables configuradas:

sysctl -f

Podemos aplicar los cambios en directo con:
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
Y comprobar como el valor será 1:
cat /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
Pero para hacerlo permanente (que no se pierda al reiniciar el sistema) debemos escribirlo en el sysctl.conf


sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1
O editando el fichero sysctl.conf y añadiendo:


net.ipv4.icmp_echo_ignore_broadcasts=1

/proc/sys/net/core/

El directorio  /proc/sys/net/core contiene una variedad de configuraciones que controlan la interacción entre el núcleo (kernel) y las capas de red (networking)


  • net.core.rmem_max – max size of rx socket buffer
  • net.core.wmem_max – max size of tx socket buffer
  • net.core.rmem_default – default rx size of socket buffer
  • net.core.wmem_default – default tx size of socket buffer
  • net.core.optmem_max – maximum amount of option memory
  • net.core.netdev_max_backlog – how many unprocessed rx packets before kernel starts to drop them


Los más importantes de este directorio son:

  • message_burst - Establece la cantidad de tiempo en décimas de segundos requeridos para escribir un nuevo mensaje de advertencia. Este ajuste se utiliza para mitigar denegación de servicio (DoS). El ajuste predeterminado es 50.
  • message_cost - Configura un costo en cada mensaje de aviso. Cuanto mayor sea el valor de este archivo (por defecto 5), se ignora el más probable es que el mensaje de advertencia. Este ajuste se utiliza para prevenir ataques de DoS. La idea de un ataque DoS es bombardear su sistema con peticiones que generen errores y llenen sus particiones con archivos logs o necesiten todos los recursos del sistema para manipular el registro de errores. Los ajustes en message_burst y message_cost están diseñados para ser modificado en función del riesgo aceptable del sistema contra la necesidad de un registro exhaustivo.
  • netdev_max_backlog - Establece el número máximo de paquetes permitido para hacer cola cuando una interfaz en particular recibe paquetes más rápido que el kernel puede procesarlos. El valor por defecto de este archivo es 300.
  • optmem_max - Configura el tamaño máximo de la memoria intermedia auxiliar por socket.
  • rmem_default - Establece el tamaño de búfer de recepción socket defecto, en bytes.
  • rmem_max - Establece buffer del socket tamaño máximo de la recepción en bytes.
  • wmem_default - Establece el socket de enviar el tamaño predeterminado de búfer en bytes.
  • wmem_max - Establece el socket de enviar el tamaño máximo del búfer en bytes.



/proc/sys/net/


Este directorio contiene subdirectorios que tratan diversos temas de redes. Las diferentes configuraciones en el momento de la compilación del núcleo colocan diferentes directorios aquí, tales como:

  • /proc/sys/net/ethernet
  • /proc/sys/net/ipv4
  • /proc/sys/net/ipx
  •  /proc/sys/net/ipv6

/proc/sys/net/ipv4/

El directorio /proc/sys/net/ipv4 contiene configuraciones de red adicionales. Muchas de estas configuraciones, usadas en conjunto con otros, son útiles en la prevención de ataques al sistema o cuando se utiliza el sistema para que actúe como un enrutador


La siguiente es una lista de algunos de los archivos más importantes dentro

  • icmp_destunreach_rate, icmp_echoreply_rate, icmp_paramprob_rate y icmp_timeexeed_rate - Establece el máximo ICMP envía tasa de paquetes, en centésimas de segundo, para hosts bajo ciertas condiciones. Un valor de 0 elimina cualquier retraso y no es una buena idea.
  • icmp_echo_ignore_all y icmp_echo_ignore_broadcasts - Permite que el kernel ignore paquetes ICMP ECHO desde cada host o tan sólo los procedentes de direcciones de broadcast y multicast, respectivamente. Un valor de 0 permite que el kernel responda, mientras un 1 ignora los paquetes. 
  • ip_default_ttl - Ajusta el valor Time to Live (TTL), lo que limita el número de saltos que un paquete puede efectuar antes de alcanzar su destino. El aumento de este valor puede disminuir el rendimiento del sistema. 
  • ip_forward - Permite interfaces en el sistema para reenviar paquetes a otro. De forma predeterminada, este archivo se establece en 0. Si configura este a 1 activa el reenvío de paquetes de red.
  • ip_local_port_range - Especifica el rango de puertos a usar por TCP o UDP cuando se necesita un puerto local. El primer número es el puerto más bajo que se utilizará y el segundo especifica el puerto más alto. Cualquier sistema que se crea que necesitará más puertos que los predeterminados 1024 hasta 4999 debería usar el rango de 32.768 a 61.000.
  • tcp_syn_retries - Proporciona un límite en el número de veces que el sistema retransmitirá un paquete SYN cuando se intenta establecer una conexión.

 El directorio /proc/sys/net/ipv4/conf/ permite a cada interfaz del sistema ser configurada en diferentes formas:
  • /proc/sys/net/ipv4/conf/default/   incluyendo el uso de valores por defecto para dispositivos no configurados  
  • /proc/sys/net/ipv4/conf/all/  configuraciones que invalidan todas las configuraciones especiales
Recordemos que los valores 0 y 1 corresponden a:
  • 0 - deshabilitado, inhabilitado, off
  • 1 - habilitado,on

Evitando el IP Spoofing

Activar Reverse Path Filtering = rp_filter (Reverse Path filter)  

 Forward Information Base (FIB) 
echo 2 > /proc/sys/net/ipv4/conf/default/rp_filter
echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter
O en el fichero /etc/sysctl.conf

net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2

¿Porque el valor 2 y no 1? Si nuestro kernel lo soporta:

rp_filter - BOOLEAN
        1 - do source validation by reversed path, as specified in RFC1812
            Recommended option for single homed hosts and stub network
            routers. Could cause troubles for complicated (not loop free)
            networks running a slow unreliable protocol (sort of RIP),
            or using static routes.
 
        0 - No source validation.


 rp_filter - INTEGER
        0 - No source validation.
        1 - Strict mode as defined in RFC3704 Strict Reverse Path 
            Each incoming packet is tested against the FIB and if the interface
            is not the best reverse path the packet check will fail.
            By default failed packets are discarded.
        2 - Loose mode as defined in RFC3704 Loose Reverse Path 
            Each incoming packet's source address is also tested against the FIB
            and if the source address is not reachable via any interface
            the packet check will fail.

Variables más importantes de /proc/sys/net/ipv4/* 

https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

/proc/sys/net/ipv4/tcp_max_syn_backlog: 
Número máximo de peticiones de conexión recordados, que siguen siendo no recibió un reconocimiento de la conexión de cliente. El valor por defecto es 1024 para sistemas con más de 128 MB de memoria ram y 128 para máquinas con poca memoria. Si el servidor sufre sobrecargas, intente aumentar este número.

/proc/sys/net/core/somaxconn:
Límite de socket listen() backlog, conocido en el espacio de usuario como SOMAXCONN. El valor predeterminado es 128. El valor deberían elevarse sustancialmente para apoyar ráfagas de solicitud. Por ejemplo, para apoyar una ráfaga de 1.024 solicitudes, establezca SOMAXCONN a 1.024.

/proc/sys/net/netfilter/nf_conntrack_max o
/proc/sys/net/netfilter/ip_conntrack_max
Por defecto 65536. Aumenta las conexiones TCP simultáneas / concurrentes. Errores en dmesg de nf_conntrack: table full, dropping packet.

Ejemplo Configuración  fichero sysctl.conf


# gets rid of "IPv6 addrconf: prefix with wrong length 56" in dmesg
net.ipv6.conf.eth0.autoconf=0
net.ipv6.conf.eth1.autoconf=0
net.ipv6.conf.all.autoconf=0
net.ipv6.conf.default.autoconf=0

# Log Spoofed Packets, Source Routed Packets, Redirect Packets
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1

# para ver conexiones CLOSE_WAIT netstat -anp | grep ':80 ' | grep CLOSE_WAIT | awk '{print $7}' | cut -d \/ -f1 | grep -oE "[[:digit:]]{1,}" | xargs kill
# por defecto 2 horas !!
# cat /proc/sys/net/ipv4/tcp_keepalive_time 7200
net.ipv4.tcp_keepalive_time = 120

# default net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_intvl = 30
# default net.ipv4.tcp_keepalive_probe = 9
net.ipv4.tcp_keepalive_probes = 5

# Decrease the time default value for tcp_fin_timeout connection
# 15 por defecto
net.ipv4.tcp_fin_timeout = 10

# ip conntrack table full dropping packet centos
# por defecto centos 6
#net.nf_conntrack_max = 65536
net.nf_conntrack_max = 165536
net.netfilter.nf_conntrack_max = 165536

#cat /sys/module/nf_conntrack/parameters/hashsize
#16384
sys.module.nf_contrack.parameters.hashsize = 24576

# default 600 (10 minutes)
net.netfilter.nf_conntrack_generic_timeout = 120
# default 432000 (5 days!)
net.netfilter.nf_conntrack_tcp_timeout_established = 54000



# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 1

# trafico ICMP
net.ipv4.icmp_echo_ignore_all = 1

# ataque arp
net.ipv4.conf.all.arp_filter = 1
#net.ipv4.conf.eth0.hidden = 1

# Por defecto1024
#/proc/sys/net/core/somaxconn
net.core.somaxconn = 5120

# Size of the backlog connections queue.
net.ipv4.tcp_max_syn_backlog=4096
net.ipv4.tcp_max_syn_backlog = 30000
net.ipv4.tcp_max_tw_buckets = 2000000
net.core.netdev_max_backlog = 50000

0 comentarios :

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.