Otra buena opción es solo habilitar el acceso a través de una llave publica
Mensaje enviado desde mi terminal BlackBerry® de Claro
-Original Message-
From: Carlos Martinez
Sender: centos-es-boun...@centos.org
Date: Thu, 13 Oct 2011 10:47:50
To: ;
Reply-To: centos-es@centos.org
Subject: Re: [CentOS-es] Intento de Hackeo
Saludos.
Para proteger el SSH hay muchas recomendaciones distintas y cada
persona generalmente da la que mejor le ha funcionado (yo daré la mía
también).
Huelga decir que los ataques de diccionario (fuerza bruta), no suelen
ser muy eficientes y el mayor daño que causan radica en el ancho de
banda y los recursos que consumen. Si se tiene una buena clave y el
acceso es solo de tipo administrativo (entra solamente el
administrador), la posibilidad de que den con la clave de acceso es
remota.
Algo un poco distinto ocurre cuando tenemos usuarios normales entrado
por SSH donde la clave muchas veces se vuelve 123456 (asignada incluso
por el mismo administrador). Aquí, un ataque de diccionario se empieza
a tornar peligroso (entre más peces tenga el lago, más probable es
pescar uno).
Con estos dos ambientes (SSH de acceso administrativo y SSH para
acceso remoto de usuarios), lo que yo recomendaría es lo siguiente:
SSH de acceso administrativo
Condiciones:
(a) Solo se accede por SSH al servidor para administrarlo y no hay
usuarios normales con acceso por SSH.
(b) Existe un usuario sin privilegios en el sistema (p. ej.
jesusadmin) que usa el administrador para acceder remotamente .
(c) El login del usuario administrativo no aparece en ninguno de los
diccionarios de nombres de usuario que se bajan de Internet (vaya
cerrando desde aquí la ventana de exposición).
Acciones:
1) crear los grupos usesu y usessh
2) Se hacen miembros del grupo usesu al usuario root y al usuario
administrativo.
3) Se hace miembro del grupo usessh al usuario administrativo.
2) Limitar el uso del comando su: únicamente al usuario de acceso
administrativo (p. ej. jesusadmin) y root puede hacer su. Esto se hace
editando /etc/pam.d/su y poniendo:
authrequiredpam_wheel.so group=usesu
3) Se activan/cambian las siguientes opciones del servicio SSH para
configurar el ingreso por llave DSA:
Protocol 2 # importante la version 1 se considera insegura
LoginGraceTime 20s#se reduce el tiempo de espera. Malo cuando
el canal de acceso no es bueno y toca aumentar el tiempo
PermitRootLogin no # no puede iniciar sesión el root
StrictModes yes
MaxAuthTries 3# solo puede probar 3 veces
RSAAuthentication no # autenticación por llave RSA (insegura) se desactiva
PubkeyAuthentication yes # aquí esta la magia
PasswordAuthentication no # aquí se acaba con la efectividad de
los ataques de diccionario, aunque no se limita el consumo de recursos
GSSAPIAuthentication no # si no se usa se apaga
AllowGroups usessh # solo se permite el acceso a los miembros
del grupo del sistema usessh
4) Crear una llave pública y privada para SSH del tipo DSA con el
comando ssh-keygen -t dsa.
5) La llave publica se deja en la cuenta del usuario administrador en
~/.ssh/authorized_keys. El directorio ~/.ssh debe tener permisos 700 y
el archivo authorized_keys permisos 400 y pertenecer al usuario y
grupo del usuario administrativo. Se protege el archivo de
manipulación y modificación con el comando chattr +i authorized_keys
6) La llave privada se conserva protegida con un passphrase y no debe
estar en ningún servidor. Solamente debe estar en el equipo desde el
cual accedemos o en una memoria USB. SIEMPRE debe estar protegida con
un passphrase. La llave privada es 'lo que tenemos' y el passphrase
'lo que sabemos' en la parte de la autenticación para poder
autenticarnos en el servidor. Ya no se pide clave para ingresar.
7) Protegerse del scan de puertos y del consumo de recursos del ataque
de diccionario de SSH habilitando el Port knocking para SSH.
Si el port knocking no es posible, activar fail2ban. No detiene el
ataque de diccionario pero limita enormemente su efectividad. Si se
está realmente paranoico: fail2ban + cambio de puerto para el servicio
SSH.
El cambio de puerto no lo recomiendo, prefiero el port knocking que
hace algo parecido, pero también funciona. La seguridad a través de la
oscuridad funciona (¿acaso ustedes ven a los ladrones con un cartel
grande que dice "soy ladrón"?. Ellos usan la (in)seguridad a través de
la oscuridad para hacer sus fechorías, así que tampoco deberíamos
andar diciendo en Internet "Mi servidor tiene SSH, por favor
atáquenme").
OPCIONAL:
- Dado que ya no se usan claves en SSH cada uno decide si permite el
acceso a root por SSH o no. Si lo quiere hacer, realizar las
siguientes acciones:
I) Se hace miembro del grupo usessh al usuario root.
II) Se cambia la opción "PermitRootLogin no" del servicio de SSH a
"Permit
