Tutoriales y Manuales
Entradas Mensuales
-
►
2024
(Total:
1090
)
- ► septiembre (Total: 50 )
-
►
2023
(Total:
710
)
- ► septiembre (Total: 65 )
-
►
2022
(Total:
967
)
- ► septiembre (Total: 72 )
-
►
2021
(Total:
730
)
- ► septiembre (Total: 56 )
-
►
2020
(Total:
212
)
- ► septiembre (Total: 21 )
-
►
2019
(Total:
102
)
- ► septiembre (Total: 14 )
-
►
2017
(Total:
231
)
- ► septiembre (Total: 16 )
-
►
2016
(Total:
266
)
- ► septiembre (Total: 38 )
-
▼
2015
(Total:
445
)
- ► septiembre (Total: 47 )
-
▼
abril
(Total:
28
)
- Nueva variante del virus CryptoLocker: Crypt0L0cker
- Microsoft también recompensará a los hackers que e...
- Telefónica autorizada por la CNMC para comprar de ...
- Project Fi: el operador móvil virtual de Google
- La nueva API de Youtube dejará sin soporte algunos...
- Cambios en el algoritmo de Google: Mobilegeddon
- Disponible el juego SuperTuxKart 0.9
- Contraseñas WiFi WPA/WPA2 vía GPU con Pyrit
- El drama de la viuda de un hacker al no poder recu...
- Wifi en los aviones: ¿puede suponer un problema de...
- Chrome para Windows XP tendrá soporte hasta finale...
- Windows Server 2003 dejará de recibir soporte en m...
- Nuevo programa de recompensas de fallos de segurid...
- Vulnerabilidad crítica en IIS de Microsoft
- Ping de la muerte para Apple, llamado Darwin Nuke ...
- Parrot Security OS; Kali Linux a la italiana
- Firmware vulnerable de algunos Routers D-Link DIR
- Ficheros PDF con contraseña con John the Ripper
- PixieScript v2.4, ataque automatizado Pixie Dust A...
- Asuswrt-Merlin, el firmware personalizado para rou...
- Mitigación de ataques UDP Reflection DrDoS
- Opciones de seguridad de red en el kernel /proc en...
- Un simple enlace hace fallar a Google Chrome en Wi...
- Tor busca estudiantes que quieran desarrollar herr...
- Anonymous desenmascara a las empresas que alojan l...
- Manual: Instalar y configurar un servidor Team Spe...
- 43 años después, Telnet a pesar de ser inseguro, s...
- Kali Linux NetHunter 1.2 con soporte para Nexus 6 ...
-
►
2014
(Total:
185
)
- ► septiembre (Total: 18 )
-
►
2013
(Total:
100
)
- ► septiembre (Total: 3 )
-
►
2011
(Total:
7
)
- ► septiembre (Total: 1 )
Blogroll
Etiquetas
seguridad
(
396
)
privacidad
(
364
)
google
(
355
)
ransomware
(
341
)
vulnerabilidad
(
305
)
Malware
(
265
)
Windows
(
246
)
android
(
244
)
cve
(
237
)
tutorial
(
237
)
manual
(
222
)
software
(
206
)
hardware
(
196
)
linux
(
127
)
twitter
(
117
)
ddos
(
95
)
WhatsApp
(
92
)
Wifi
(
85
)
cifrado
(
77
)
herramientas
(
75
)
hacking
(
73
)
sysadmin
(
68
)
app
(
65
)
Networking
(
57
)
nvidia
(
53
)
ssd
(
51
)
youtube
(
50
)
firmware
(
44
)
adobe
(
43
)
office
(
41
)
hack
(
40
)
firefox
(
36
)
contraseñas
(
32
)
eventos
(
32
)
antivirus
(
31
)
juegos
(
31
)
cms
(
30
)
flash
(
28
)
anonymous
(
27
)
apache
(
26
)
MAC
(
25
)
programación
(
25
)
exploit
(
23
)
multimedia
(
23
)
javascript
(
22
)
Kernel
(
20
)
ssl
(
19
)
SeguridadWireless
(
17
)
documental
(
16
)
Forense
(
15
)
conferencia
(
15
)
Debugger
(
14
)
lizard squad
(
14
)
técnicas hacking
(
13
)
auditoría
(
12
)
delitos
(
11
)
metasploit
(
11
)
Virtualización
(
10
)
adamo
(
9
)
reversing
(
9
)
Rootkit
(
8
)
Ehn-Dev
(
7
)
MAC Adress
(
6
)
antimalware
(
6
)
oclHashcat
(
5
)
Entradas populares
-
Después de ver qué es una vCPU y la diferencia entre núcleos (cores) e hilos en los procesadores, pasamos a explicar toda la nomenclatura d...
-
En la Operación Torpedo el FBI utilizó Metasploit Framework , un software totalmente libre construido originalmente sobre lenguaje Perl y p...
-
Recientemente, 2K Games ha sufrido un ataque dentro de su plataforma de soporte técnico. Dicha plataforma, fue hackeada y utilizada para...
Mitigación de ataques UDP Reflection DrDoS
viernes, 10 de abril de 2015
|
Publicado por
el-brujo
|
Editar entrada
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).
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"
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:
Errores en el /var/syslog o dmesg (mensajes del kernel)
Los errores net_ratelimit los podemos "ignorar" porque son simplemente que al kernel no le hado tiempo de escirbirlo en el syslog
Errores
iptables tiene tres tablas (-t)
net.ipv4.ip_forward=1
La tabla NAT está formada por tres cadenas:
Por ejemplo si intenenmos hacer una regla con la tabla NAT y la acción DROP:
Si estamos detrás de un router (NAT), hay que usar la cadena FORWARD en este caso para hacer -j DROP
Por ejemplo /etc/sysconfig/iptables:
El orden correcto es:
Los ataques quedarán automáticamente logeados en el syslog
Ejemplo para ver los paquetes que han pasado por el filtro en iptables:
http://www.ip2location.com/free/visitor-blocker
De un listado de ip's (blocklist.txt)
Ejemplo con los países deChina(cn) Korea(kr) Taiwan(tw) Pakistan(pk) Singapore(sg) HongKong(hk)
Ejemplo de banear a China:
Otro ejemplo:
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"
Chain INPUT (policy ACCEPT 211K packets, 19M bytes)
O usando ss (iproute2)
kernel
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:
Con un null-route:
- Aumentar el tamaño del buffer UDP desde 128K a 32MB
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
echo 2000 > /proc/sys/net/core/netdev_max_backlog
- Disminuyendo el timeout de UDP (por defecto suele ser 30 segundos)
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,
http://wiki.elhacker.net/sistemas-operativos/gnulinux/tuning-sysctl-conf
El fichero de configuración sysctl.conf se encaraga de leer los parámetros del kernel.
Mostrar todas las variables configuradas
Cargar todas las variables configuradas:
Podemos aplicar los cambios en directo con:
Los más importantes de este directorio son:
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:
La siguiente es una lista de algunos de los archivos más importantes dentro
El directorio /proc/sys/net/ipv4/conf/ permite a cada interfaz del sistema ser configurada en diferentes formas:
¿Porque el valor 2 y no 1? Si nuestro kernel lo soporta:
rp_filter - INTEGER
/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.
Durante los últimos meses varios servidores de Team Speak han estado recibiendo continuos ataques DDoS usando DrDDoS (basados en UDP).
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
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
O un script más completo y personalizado escrito en Python que permite configurar el puerto:#!/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
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 2974UDP: bad checksum. From 14.41.56.229:19 to 91.126.240.73:9987 ulen 4457UDP: bad checksum. From 1.215.244.35:19 to 91.126.240.73:9987 ulen 2979UDP: bad checksum. From 222.81.62.71:19 to 91.126.240.73:9987 ulen 1492UDP: bad checksum. From 211.219.0.193:19 to 91.126.240.73:9987 ulen 3876UDP: bad checksum. From 211.219.0.193:19 to 91.126.240.73:9987 ulen 4128UDP: bad checksum. From 211.219.0.193:19 to 91.126.240.73:9987 ulen 4674UDP: bad checksum. From 59.27.106.194:19 to 91.126.240.73:9987 ulen 4450UDP: bad checksum. From 222.81.62.71:19 to 91.126.240.73:9987 ulen 4454UDP: bad checksum. From 112.187.159.189:19 to 91.126.240.73:9987 ulen 1497UDP: bad checksum. From 66.46.124.134:19 to 91.126.240.73:9987 ulen 5940UDP: bad checksum. From 124.193.31.162:19 to 91.126.240.73:9987 ulen 2977UDP: bad checksum. From 66.46.124.134:19 to 91.126.240.73:9987 ulen 1490UDP: bad checksum. From 14.41.56.229:19 to 91.126.240.73:9987 ulen 1501UDP: bad checksum. From 1.215.244.35:19 to 91.126.240.73:9987 ulen 1487UDP: bad checksum. From 124.193.31.122:19 to 91.126.240.73:9987 ulen 2980UDP: bad checksum. From 59.17.206.69:19 to 91.126.240.73:9987 ulen 1498UDP: 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)
- INPUT (entrada)
- FORWARD (redirección, router, NAT (DMZ))
- OUTPUT (salida)
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 4La 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 nethashMatching against the IPSet in IPTables:
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
iptables -A INPUT -m set –set geoblock src -j DROPOtro ejemplo en bash script:
for IP in $(wget -O - http://www.ipdeny.com/ipblocks/data/countries/countryX.zone)Y aplicando la regla:
do
# regular big hammer - block port 22 for countryX
sudo ipset add geoblock $IP,22
done
iptables -I INPUT -m set --set geoblock src -j DROP
Ejemplo de banear a China:
# Create the ipset listAplicando la regla a iptables:
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
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/Ejemplo de reglas ataque UDP Chargen source port 19, SSDP (Upnp) Puerto origen 1900 y NTP puerto origen 123).
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
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 -suPodemos 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=33554432o 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=2000o 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)
http://wiki.elhacker.net/sistemas-operativos/gnulinux/tuning-sysctl-conf
Optimizando el Kernel de Linux (sysctl.conf)
/etc/sysctl.confEl 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_broadcastsY comprobar como el valor será 1:
cat /proc/sys/net/ipv4/icmp_echo_ignore_broadcastsPero 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=1O 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 enrutadorLa 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
- 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_filterO en el fichero /etc/sysctl.conf
echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter
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
Enviar por correo electrónico
Escribe un blog
Compartir en X
Compartir con Facebook
Compartir en Pinterest
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.