linux:ssh
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| linux:ssh [2008/11/02 10:48] – rlunaro | linux:ssh [2022/12/02 21:02] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 3: | Line 3: | ||
| ===== Limitar intentos de conexion SSH ===== | ===== Limitar intentos de conexion SSH ===== | ||
| - | ==== En qué consiste | + | ==== Introducción |
| El presente artículo trata de cómo limitar los intentos de conexión | El presente artículo trata de cómo limitar los intentos de conexión | ||
| Line 26: | Line 26: | ||
| </ | </ | ||
| + | ==== La contramedida más adecuada ==== | ||
| - | Evitar esto es muy sencillo instalando un par de reglas de firewall. El | + | Navegando por internet, he visto varias medidas: la mayor parte |
| - | problema es hacerlo en SuSE de una forma que queda perfectamente integrada | + | se basan en analizar |
| - | en el sistema. | + | ataques y posteriormente bloquear las ip's. |
| - | Para llevar | + | La medida me parece totalmente desacertada por varios motivos: |
| + | 1) muchos de esos ataques provienen de adsl' | ||
| + | va a variar forzosamente al cabo de un tiempo. 2) algunas soluciones ni | ||
| + | siquiera bloquean la ip, simplemente registran la ip atacante, y dejan | ||
| + | al administrador la tarea de bloquearlas. | ||
| - | Modificaremos el script de arranque | + | Otras soluciones más peregrinas son cambiar la dirección |
| - | reglas de filtrado oportunas. Básicamente consisten en contar los intentos | + | ssh o ponerlo por horas; no me parecen ni medio elegantes((cada uno |
| - | fallidos de acceso en un tiempo inferior a X segundos. Si los intentos | + | tiene sus opiniones sobre cómo administrar su sistema, y lo siento |
| - | fallidos superan N, entonces se rechaza todo intento posterior de conexión | + | mucho pero esto no me parece una solución)). |
| - | mediante un " | + | |
| - | desde esa IP. | + | |
| - | N y X serán configurables, | + | Sin embargo |
| - | configuración de ssh /etc/sysconfig/ssh | + | En [[http://kevin.vanzonneveld.net/techblog/ |
| - | De esta forma, la ejecución podrá activarse o desactivarse por el usuario | + | * Instala dos reglas en el firewall del sistema |
| - | a voluntad, e incluso configurar | + | * Esas reglas registran los intentos de conexión de fallidos: |
| + | * A los X segundos de inactividad, | ||
| + | Tiene una ventaja que en mi modesta opinión es fundamental: | ||
| - | ==== Instalando la contramedida ==== | + | * No mantiene ningún registro; lo cual es perfecto porque esas IP's atacantes son muy variables |
| + | * Funciona automáticamente: | ||
| + | * Funciona incluso con nosotros: un atacante que se apoderara de nuestra consola, no podría intentar más de N contraseñas. | ||
| - | Dado que el entorno | + | ==== Las reglas |
| - | de forma que parezca que ha estado ahí toda la vida. | + | |
| + | < | ||
| + | sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH | ||
| + | sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP | ||
| + | </ | ||
| + | ==== Instalando las reglas en SuSE ==== | ||
| - | Vamos a implementar | + | No pierdas el tiempo modificando scripts peregrinos por ahí, SuSE tiene un mecanismo para instalar reglas personalizadas |
| - | / | + | |
| - | Para ello editaremos el fichero de arranque del demonio ssh (es un buen | + | En / |
| - | momento para hacer una copia de seguridad). Donde antes ponía: | + | |
| - | start) | + | < |
| - | [.....] | + | ## Type: string |
| - | echo | + | # |
| + | # 25.) | ||
| + | # Do you want to load customary rules from a file? | ||
| + | # | ||
| + | # This is really an expert option. NO HELP WILL BE GIVEN FOR THIS! | ||
| + | # READ THE EXAMPLE CUSTOMARY FILE AT / | ||
| + | # | ||
| + | # | ||
| + | FW_CUSTOMRULES="" | ||
| + | </ | ||
| - | startproc -f -p $SSHD_PIDFILE / | + | Que nos permite especificar un fichero de reglas de firewall personalizadas. Descomentamos la variable y lo dejamos así: |
| - | # Remember status and be verbose | + | < |
| - | | + | FW_CUSTOMRULES="/ |
| + | </ | ||
| + | ==== El fichero de reglas personalizadas ==== | ||
| + | A continuación editaremos el fichero de reglas personalizadas: | ||
| - | ahora pondremos lo siguiente: | + | < |
| + | sudo vi / | ||
| + | </ | ||
| - | start) | + | Y en la función fw_custom_after_antispoofing insertaremos las reglas: |
| - | [.....] | + | |
| - | echo -n " | + | |
| - | startproc -f -p $SSHD_PIDFILE / | + | <code bash> |
| - | # limit the failed connection attempts to port 22 | + | fw_custom_after_antispoofing() |
| - | # to prevent systematic password guessing attacks | + | { |
| - | if [ " | + | |
| - | then | + | |
| - | echo -n " [Security enhaced on]" | + | |
| - | iptables -I INPUT -p tcp --dport 22 -i eth+ \ | + | |
| - | -m state --state NEW -m recent --set | + | |
| - | iptables -I INPUT -p tcp --dport 22 -i eth+ \ | + | |
| - | -m state --state NEW -m recent --update \ | + | |
| - | --seconds $MAX_ATTEMPTS_TIMEOUT --hitcount $MAX_ATTEMPTS -j DROP | + | |
| - | fi | + | |
| + | # | ||
| + | # | ||
| + | # Custom rules to stop script kiddies accesing ssh port | ||
| + | # | ||
| + | # | ||
| - | | + | echo -n " |
| - | | + | |
| + | iptables -I INPUT -i eth+ -p tcp --dport 22 \ | ||
| + | -m state --state NEW -m recent --set --name SSH | ||
| + | |||
| + | |||
| + | | ||
| + | # connection for 60 seconds | ||
| + | iptables | ||
| + | -m state --state NEW -m recent --update \ | ||
| + | | ||
| + | |||
| + | |||
| + | echo " | ||
| + | |||
| + | </ | ||
| Es decir, hemos instalado un código que mediante una llamada al comando | Es decir, hemos instalado un código que mediante una llamada al comando | ||
| iptables -el comando básico para hacer un filtrado de paquetes en Linux-, | iptables -el comando básico para hacer un filtrado de paquetes en Linux-, | ||
| - | limitaremos los intentos de conexión al puerto 22 a MAX_ATTEMPTS. Una | + | limitaremos los intentos de conexión al puerto 22 a lo que diga el |
| - | vez alcanzado ese valor, será preciso esperar | + | parámetro --hitcount. Una vez alcanzado ese valor, será preciso |
| - | poder volver a conectarse. | + | esperar |
| + | |||
| + | ==== Reiniciar el firewall ==== | ||
| - | Bien, lo que nos queda es que cuando echemos abajo el servicio, estas | ||
| - | reglas se desactiven tambiÃn. Para ello instalaremos los comandos de | ||
| - | borrado de reglas en la opción stop) del script. Es decir, donde dice: | ||
| < | < | ||
| - | stop) | + | / |
| - | echo -n " | + | </ |
| - | ## Stop daemon with killproc(8) and if this fails | + | |
| - | ## set echo the echo return value. | + | |
| - | killproc -p $SSHD_PIDFILE -TERM / | + | ==== Instalación remota ==== |
| - | # Remember status and be verbose | + | El riesgo de hacer una instalación en remoto de estas cosas es que podemos |
| - | | + | colgar el acceso ssh y quedarnos sin acceso a la máquina. A fin de contener |
| - | </ | + | los riesgos lo que haremos será poner una entrada de cron que a las doce de la |
| + | noche borre el fichero que hemos creado y así nos permita reiniciar la máquina. | ||
| - | Pondremos lo siguiente: | ||
| < | < | ||
| - | stop) | + | # field allowed values |
| - | | + | # ----- -------------- |
| - | ## Stop daemon with killproc(8) and if this fails | + | # |
| - | ## set echo the echo return value. | + | # |
| + | # day of month | ||
| + | # month 1-12 (or names, see below) | ||
| + | # day of week 0-7 (0 or 7 is Sun, or use names) | ||
| - | killproc -p $SSHD_PIDFILE -TERM /usr/sbin/sshd | + | # a las 23:00 borramos el fichero |
| + | 0 23 * * * | ||
| - | | + | # a las 23:10 restauramos el firewall |
| - | if [ " | + | 10 23 * * * root / |
| - | then | + | |
| - | echo " | + | |
| - | iptables -D INPUT -p tcp --dport 22 -i eth+ \ | + | |
| - | -m state --state NEW -m recent --set | + | |
| - | iptables -D INPUT -p tcp --dport 22 -i eth+ \ | + | |
| - | -m state --state NEW -m recent --update \ | + | |
| - | --seconds $MAX_ATTEMPTS_TIMEOUT --hitcount $MAX_ATTEMPTS -j DROP | + | |
| - | fi | + | |
| - | |||
| - | # Remember status and be verbose | ||
| - | rc_status -v | ||
| </ | </ | ||
| - | Y ya está: cada vez que el servicio sshd se pare, tambiÃn las reglas | ||
| - | de filtrado serán desactivadas. De esta forma, sucesivas paradas/ | ||
| - | no llenarán las reglas de filtrado del kernel, y lo mantendrá todo | ||
| - | " | ||
| - | Ahora sólo nos queda instalar las variables de configuración. En el | ||
| - | fichero / | ||
| - | < | ||
| - | ## Path: Network/ | ||
| - | ## Description: | ||
| - | ## Type: string | ||
| - | ## Default: | ||
| - | ## ServiceRestart: | ||
| - | # | ||
| - | # Options for sshd | ||
| - | # | ||
| - | SSHD_OPTS="" | ||
| - | # | ||
| - | # do you want to limit the number of failed | + | |
| - | # connections to the ssh port? set this | + | |
| - | # option to " | + | |
| - | # | + | |
| - | SECURITY_ENHACED=" | + | |
| - | # | + | |
| - | # this option will set the maximum number of | + | |
| - | # failed connection attempts will be allowed | + | |
| - | # before closing the connection | + | |
| - | # | + | |
| - | MAX_ATTEMPTS=4 | + | |
| - | # | + | |
| - | # this option will set the time the connection | + | |
| - | # will be dropped for annoying ip | + | |
| - | # | + | |
| - | MAX_ATTEMPTS_TIMEOUT=60 | + | |
| - | </ | + | |
linux/ssh.1225622888.txt.gz · Last modified: 2022/12/02 21:02 (external edit)
