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 <cama...@gmail.com>
Sender: centos-es-boun...@centos.org
Date: Thu, 13 Oct 2011 10:47:50
To: <centos-es@centos.org>; <je...@evangelizacion.org.mx>
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:
auth required pam_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
"PermitRootLogin without-password"
III) Se ejecuta el paso 5 para el usuario root.
--------------------------------------------
SSH con acceso a usuarios
--------------------------------------------
Condiciones:
(a) Se accede por SSH al servidor para administrarlo y también 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 su al usuario root y al usuario administrativo.
3) Se hace miembro del grupo usessh al usuario administrativo y a
todos los usuarios que ingresen por SSH al servidor.
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:
auth required pam_wheel.so group=usesu
Opcional: usar también sudo y asegurarlo.
3) Se activan/cambia las siguientes opciones del servicio SSH para
configurar el ingreso por llave DSA:
Protocol 2 # importante
LoginGraceTime 30s #se reduce el tiempo de espera
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 yes # no hay de otra a menos que abramos
un curso de autenticación por llave para SSH en la empresa
GSSAPIAuthentication no # si no se usa se apaga
AllowGroups usessh # solo se permite el acceso a los miembros
del grupo del sistema usessh
4) Activar y configurar fail2ban
5) Implementar una política de claves que obligue al cambio periódico
de las mismas cada 3 meses o menos, que verifique que tengan una
longitud mínima de 8 ó más caracteres y se verifiquen contra un
diccionario de frases regionalizado.
OPCIONAL:
- activar el acceso por llave para el usuario administrativo y para el root.
PARANOIA TOTAL:
- habilite el port knocking y enséñele a los usuarios a usarlo o cree
scripts de acceso en Windows, Linux y MAC para que los usuarios puedan
acceder (esto va para muy bien para aquellos que tienen alma de
pedagogos).
PARANOIA ABSOLUTA:
- Todos los usuarios usan port knocking y se autentican con llave
MIS RESPETOS Y ADMIRACIÓN (por favor de ser posible, envíeme el
procedimiento de configuración):
- Use kerberos contra un AD para autenticar los usuarios, con una
divertida política de claves y fail2ban.
Hasta la próxima:
Carlos A. Martínez
2011/10/13 Jesús Rivas <je...@evangelizacion.org.mx>
>
> Creo que cambiando el puerto ssh no es una solucion, pues te dan un port
> scan y dan con los puertos abiertos y empiezan el ataque, si no es asi,
> pues no tengo problemas en cambiar el puerto.
>
> Lo que comentas de quitar el acceso a root al ssh ya lo hice, asi como
> limitar el numero de intentos y el tiempo para logearse.
>
> Creo que no puedo moverle para que solo unas ip entren al servidor por
> ssh ya que tengo ip dinamicas para entrar al servidor, aunque si se
> puede agradeceria la aportacion.
>
>
> El 12/10/2011 09:01, César CRUZ ARRUNATEGUI escribió:
> > cambia el puerto de ssh
> >
> > César D. Cruz Arrunátegui
> >
> >
> > ----- Mensaje original -----
> > De: "Jesús Rivas"<je...@evangelizacion.org.mx>
> > Para: centos-es@centos.org
> > Enviados: Martes, 11 de Octubre 2011 10:53:18 GMT -05:00 Colombia
> > Asunto: [CentOS-es] Intento de Hackeo
> >
> > Hola gente, tenemos un servidor con centos 5 y en el log secure veo
> > intentos de acceso por ssh muy seguramente un script (checando la IP
> > google dice que es alguien de beijing).
> >
> > Primero agregue la ip a hosts.deny pero luego me di cuenta que la ip
> > cambio y siguio cambiando, entonces no veo el caso de estar agregando
> > las ip al hosts.deny
> >
> > Luego cerre el acceso por ssh a root que bueno gloogeando me tope que es
> > una buena practica de seguridad, asi como tambien limitar el numero de
> > intentos el tiempo para poner la contraseña y ahi de ratos veo en el log
> > intentos de acceso por ahi, pero pues por ahi ya no podra entrar.
> >
> > ¿Alguna otra recomendacio que me puedan dar para evitar esto?
> > _______________________________________________
> > CentOS-es mailing list
> > CentOS-es@centos.org
> > http://lists.centos.org/mailman/listinfo/centos-es
> >
> >
>
> --
> Saludos!!!
>
>
> Jesus Alonso Rivas
> Sistemas
>
> _____________________________________
> Evangelización Activa
> Comunicación Digital al Servicio del Evangelio
> www.evangelizacion.org.mx
>
> _______________________________________________
> CentOS-es mailing list
> CentOS-es@centos.org
> http://lists.centos.org/mailman/listinfo/centos-es
_______________________________________________
CentOS-es mailing list
CentOS-es@centos.org
http://lists.centos.org/mailman/listinfo/centos-es
_______________________________________________
CentOS-es mailing list
CentOS-es@centos.org
http://lists.centos.org/mailman/listinfo/centos-es
