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<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 >
-- 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
