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/07 20:12] – rlunaro | linux:ssh [2022/12/02 21:02] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 28: | Line 28: | ||
==== La contramedida más adecuada ==== | ==== La contramedida más adecuada ==== | ||
- | Navegando por internet, he visto varias medidas: la mayor parte se basan en analizar el log del sistema para identificar los ataques y posteriormente bloquear las ip' | + | Navegando por internet, he visto varias medidas: la mayor parte |
+ | se basan en analizar el log del sistema para identificar los | ||
+ | ataques y posteriormente bloquear las ip' | ||
- | La medida me parece totalmente desacertada por varios motivos: 1) muchos de esos ataques provienen de adsl' | + | 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. | ||
- | Otras soluciones más peregrinas son cambiar la dirección del puerto ssh o ponerlo por horas; no me parecen ni medio elegantes((cada uno tiene sus opiniones sobre cómo administrar su sistema, y lo siento mucho pero esto no me parece una solución)). | + | Otras soluciones más peregrinas son cambiar la dirección del puerto |
+ | ssh o ponerlo por horas; no me parecen ni medio elegantes((cada uno | ||
+ | tiene sus opiniones sobre cómo administrar su sistema, y lo siento | ||
+ | mucho pero esto no me parece una solución)). | ||
Sin embargo en | Sin embargo en | ||
Line 50: | Line 59: | ||
< | < | ||
+ | |||
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 --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 | 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 | ||
Line 62: | Line 72: | ||
< | < | ||
+ | ## Type: string | ||
+ | # | ||
+ | # 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="" | ||
+ | </ | ||
+ | Que nos permite especificar un fichero de reglas de firewall personalizadas. Descomentamos la variable y lo dejamos así: | ||
+ | |||
+ | < | ||
+ | FW_CUSTOMRULES="/ | ||
</ | </ | ||
+ | ==== El fichero de reglas personalizadas ==== | ||
+ | |||
+ | A continuación editaremos el fichero de reglas personalizadas: | ||
+ | |||
+ | < | ||
+ | sudo vi / | ||
+ | </ | ||
+ | Y en la función fw_custom_after_antispoofing insertaremos las reglas: | ||
<code bash> | <code bash> | ||
Line 80: | Line 113: | ||
echo -n " | echo -n " | ||
- | iptables -I INPUT -i lo -p tcp --dport 22 \ | + | iptables -I INPUT -i eth+ -p tcp --dport 22 \ |
-m state --state NEW -m recent --set --name SSH | -m state --state NEW -m recent --set --name SSH | ||
Line 86: | Line 119: | ||
# After 3 unsucessful retries, drop the | # After 3 unsucessful retries, drop the | ||
# connection for 60 seconds | # connection for 60 seconds | ||
- | iptables -I INPUT -i lo -p tcp --dport 22 \ | + | iptables -I INPUT -i eth+ -p tcp --dport 22 \ |
-m state --state NEW -m recent --update \ | -m state --state NEW -m recent --update \ | ||
| | ||
Line 95: | Line 128: | ||
</ | </ | ||
- | ==== En qué consiste ==== | ||
- | Evitar esto es muy sencillo instalando | + | Es decir, hemos instalado |
+ | iptables -el comando básico para hacer un filtrado | ||
+ | limitaremos los intentos | ||
+ | parámetro --hitcount. Una vez alcanzado ese valor, será preciso | ||
+ | esperar lo que diga --seconds para poder volver a conectarse. | ||
+ | |||
+ | ==== Reiniciar el firewall ==== | ||
< | < | ||
- | 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 | + | |
</ | </ | ||
- | Es decir, hemos instalado un código que mediante | + | ==== Instalación remota ==== |
- | iptables -el comando básico para hacer un filtrado | + | |
- | limitaremos | + | El riesgo de hacer una instalación en remoto de estas cosas es que podemos |
- | vez alcanzado ese valor, será preciso esperar MAX_ATTEMPTS_TIMEOUT para | + | colgar |
- | poder volver | + | los riesgos lo que haremos será poner una entrada |
+ | noche borre el fichero que hemos creado y así nos permita reiniciar la máquina. | ||
+ | |||
+ | |||
+ | < | ||
+ | # field allowed values | ||
+ | # ----- -------------- | ||
+ | # minute | ||
+ | # hour | ||
+ | # day of month | ||
+ | # month 1-12 (or names, see below) | ||
+ | # day of week 0-7 (0 or 7 is Sun, or use names) | ||
+ | |||
+ | # a las 23:00 borramos el fichero | ||
+ | 0 23 * * * | ||
+ | |||
+ | # a las 23:10 restauramos el firewall | ||
+ | 10 23 * * * root /etc/rc.d/ | ||
+ | |||
+ | </ | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
linux/ssh.1226088759.txt.gz · Last modified: 2022/12/02 21:02 (external edit)