[CentOS-es] Intento de Hackeo
Jesús Rivas
jesus en evangelizacion.org.mx
Jue Oct 13 12:24:28 EDT 2011
Muchas gracias carlos
El 13/10/2011 10:47, Carlos Martinez escribió:
> 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<jesus en 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"<jesus en evangelizacion.org.mx>
>>> Para: centos-es en 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 en 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 en 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
Más información sobre la lista de distribución CentOS-es