Protección del servidor SSH contra la fuerza bruta

Tengo un pequeño servidor SVN, antiguo Dell Optiplex ejecutando Debian. No tengo grandes demandas en mi servidor, porque es solo un pequeño servidor SVN ... pero sí quiero que sea seguro.

Acabo de renovar mi servidor a un optiplex más nuevo y mejor, y comencé a buscar un poco en el antiguo servidor. Lo quité después de experimentar problemas. Cuando reviso los registros, está lleno de intentos de fuerza bruta y de alguna manera alguien ha logrado ingresar a mi máquina. Esta persona creó un volumen adicional llamado "knarkgosse" con dos directorios "root" y "swap1" o algo así. Realmente no sé por qué y qué hacen, pero seguro que quieren evitar que esto vuelva a suceder. Sin embargo, esto me parece un poco extraño porque cambio mi contraseña cada pocos meses, y las contraseñas siempre son letras y números aleatorios juntos ... no es fácil de forzar.

Sé que puedo evitar que root inicie sesión y usar sudoers ... y cambiar el puerto SSH, pero ¿qué más puedo hacer?

Entonces tengo algunas preguntas:

1. ¿Cómo puedo evitar iniciar sesión durante 5 minutos después de X cantidad de intentos incorrectos? ¿O ralentiza los intentos después de cada intento incorrecto?

2. ¿Hay algún tipo de lista negra central a la que se pueda conectar un servidor? ¿Una lista negra que realiza un seguimiento de las direcciones IP que son "inseguras" y nunca se les debe otorgar acceso?

3. ¿Qué más puedo hacer para aplicar seguridad a mi servidor?

Como dije antes, estoy ejecutando Debian 5 con Apache (¿problema de usuario de www-data?), Svn, mysql, php, phpmyadmin, hudson. Está en una red doméstica con reenvío de puertos en 80, 443, 8080, 8180, 23 y 22.

Fail2ban y Port Knocking deberían abordar la mayoría de sus necesidades.

También se recomienda cambiar su puerto SSH y solo permitir la autenticación basada en claves.

Se puede argumentar que puede llegar a un punto de rendimientos decrecientes al agregar medidas de seguridad adicionales, pero de nuevo, depende de usted decidir cuándo está "lo suficientemente seguro".

También es una buena idea no permitir el inicio de sesión de root.

No hay sustituto para contraseñas seguras Y autenticación de clave. Dicho esto, Fail2Ban es una gran herramienta para prohibir las IP de los usuarios que intentan autenticarse demasiadas veces. También está disponible como un paquete preconstruido para la mayoría de las distribuciones. Ten en cuenta que puedes ser expulsado accidentalmente, así que asegúrate de tener también una IP de recuperación en la lista blanca o un fácil acceso a la consola ...

Fail2Ban tiene varios buenos ejemplos de cómo configurar todo lo que solicitó ... sin embargo, no tiene un repositorio universal de direcciones incorrectas. No creo que haya tal repositorio en ningún lugar debido a la facilidad de obtener otra IP (dhcp refresh / bot-net ataca / etc ...). También deshabilitaría el inicio de sesión a través de ssh utilizando los nombres de usuario comunes de tipo 'administrador' (root / admin / administrador / sysop / etc.), ya que estos son los más utilizados.

He detenido los ataques de fuerza bruta con:

• fail2ban
• sshd.config:
  • Contraseña Autenticación No
  • PermitRootLogin No
• Limitación de las tasas de SSH Connect con iptables ( http://www.debian-administration.org/articles/187 )

Hay una serie de buenas sugerencias que se ofrecen aquí. Respetuosamente sugiero que tres cosas deberían hacer esto relativamente seguro:

1. Ejecute el sshd en un puerto alto aleatorio. Los bots generalmente solo van después del puerto 22 y las variaciones en el puerto 22 como 2222.
2. Deshabilite la autenticación basada en contraseña en la configuración sshd:

UsePAM no

3. Solo autentíquese con este sitio a través de pares de claves SSH precompartidas. Hombre en ssh-keygen para comenzar con la autenticación basada en PKI.

Espero que esto ayude.

Siempre he sido un gran admirador de CSF / LFD, que puede bloquear las direcciones IP de las personas que intentan fuerza bruta, escaneo de puertos y algunas otras opciones. Básicamente es un gran contenedor de perl para tablas IP, pero el archivo de configuración no es difícil de leer y la documentación no es mala.

También podrías mirar en sshguard. No lo he usado pero he escuchado cosas buenas.

Fuentes:
http://isc.sans.edu/diary.html?storyid=9370

http://www.sshguard.net/

http://www.sshguard.net/docs/faqs/

"Sshguard supervisa los servidores desde su actividad de registro. Cuando los registros indican que alguien está haciendo algo malo, sshguard reacciona bloqueándolo por un momento. Sshguard tiene una personalidad delicada: cuando un tío travieso insiste en molestar a su anfitrión, reacciona más y más firme ".

Tengo un servidor SSH conectado a Internet en el puerto predeterminado y nunca he tenido problemas.

• tcp_wrappers (es decir, hosts.allow hosts.deny) para SSH ... No creo que haya un SSH que no tenga soporte compilado en él.
• iptables esto junto con tcp_wrappers eliminó aproximadamente el 99% de mis escaneos de puertos aleatorios / intentos de fuerza bruta ... el único problema es que necesita saber desde dónde se conectará para permitir esos rangos de IP / IP ... Simplemente lo hice una búsqueda en proveedores populares de mi área para ver sus rangos de IP y permitir que ... la mayoría de los escaneos parecen provenir de tierras lejanas :)
• PermitRootLogin sin contraseña (es decir, solo los pares de claves RSA / DSA que están cifrados con una frase de contraseña) funciona maravillosamente para tareas automatizadas ... cuando inicio sesión para interactuar, obviamente uso mi cuenta (regular) que está configurada con acceso sudo
• sudoers
• actualizaciones constantes .. Actualizo este cuadro con frecuencia con todas las actualizaciones críticas / de seguridad
• cambios de contraseña / frase de contraseña
• Ejecute chkrootkit de vez en cuando para ver si tengo algún problema ... (hay varios que realizan esta función)

¡Espero eso ayude!

Hay una mejor manera de hacer esto, usar fail2ban significa que debe agregar una aplicación, y funciona en la capa de la aplicación.

Si usa iptables, es más eficiente ya que opera en la capa de red y no tiene que instalar una aplicación adicional.

Utilice el módulo reciente de iptables http://www.snowman.net/projects/ipt_recent/

iptables -N SSHSCAN
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j LOG --log-level info --log-prefix "SSH SCAN blocked: "
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j DROP
iptables -A SSHSCAN -j ACCEPT

Una opción (que se utilizará además de otras medidas de seguridad) es hacer que sshd escuche en un puerto que no sea el 22. No lo he intentado yo mismo, pero he oído que reduce la cantidad de ataques de fuerza bruta por parte de bots.

Debo enfatizar que esto no es seguridad real, solo reduce la cantidad de ataques automáticos de fuerza bruta. Demasiado trabajo para comprobar cada puerto, supongo.

Algo que no se menciona aquí y que realmente debería es limitar el acceso a través del firewall. Esto no se adapta a todas las situaciones, pero si se conecta al host desde una ubicación coherente con una IP estática, puede bloquear SSH por completo, excepto a esa IP. Esto asegurará que los intrusos no puedan entrar. Sin embargo, como mencioné, esto no siempre se adapta a todas las situaciones, especialmente si su IP es dinámica y cambia con frecuencia.

DenyHosts, http://denyhosts.sourceforge.net/ , es un buen proyecto con el que he tenido suerte. Si configuras denyhosts para que se sincronice, descargará nuevas direcciones IP para agregar a una lista de prohibición que han tenido que imponer a otros sistemas bruteforce usando denyhosts. También expira las IP que no han intentado aplicar fuerza bruta por un tiempo.

Sin embargo, usar la autenticación de clave pública y deshabilitar el registro de contraseña es probablemente lo mejor que puede hacer. Derrota cualquier ataque de fuerza bruta.

Lo que ha sido efectivo para mí:

1. Como otros han dicho, no hay inicio de sesión raíz, Autenticación de contraseña establecida en no (solo inicio de sesión con teclas) en sshd_config

2. Solo uno o dos usuarios pueden iniciar sesión a través de ssh y tienen nombres casi oscuros que no están en las listas comunes de nombres de usuarios de herramientas de fuerza bruta (es decir, no "admin" o "apache" o "web" o " johnny ")

3. Reglas de firewall restrictivas (básicamente, todo está bloqueado excepto mi puerto de servicio y ssh). Incluso restrinjo el ping, para evitar los escaneos más crudos (para disgusto de mi compañero).

4. En mi servidor web, restrinjo el acceso a unas pocas direcciones IP específicas, pero parece que no es una opción para usted. Ciertamente no puedo hacerlo yo mismo en todos nuestros anfitriones. También es posible que desees investigar el "golpeteo de puertos".

5. Y mi favorito: el módulo de respuesta activa de OSSEC para bloquear una serie de condiciones de fuerza bruta y alertas sobre otros errores, también. Detecta x inicios de sesión inválidos en y cantidad de tiempo, y luego bloquea (a través de un comando iptables firewall-drop) durante un cierto período de tiempo. Estoy bloqueando durante unas 12 horas por diversión. :)

Una cosa que hago aquí para asegurarme de no bloquear demasiado las cosas incorrectas es que en /etc/ossec.conf, configuro la respuesta activa a un nivel alto (que no existe en la configuración predeterminada) y luego vaya a sshd_rules.xml y establezca las reglas que quiero bloquear a ese nivel y modifique los umbrales para bloqueo vs. alerta según sea necesario.

Si está ejecutando Apache, también puede bloquear cosas que violen las reglas de apache. No bloqueo en estos solo por el problema de NAT, quiero pensar en bloquear una universidad entera o algo así. :) Además, puede escribir reglas personalizadas para bloquear ciertas condiciones en los archivos de registro, lo que puede ser realmente útil.