¿Qué pasos toma para proteger un servidor Debian? [cerrado]

Estoy instalando un servidor Debian que está conectado directamente a Internet. Obviamente quiero que sea lo más seguro posible. Me gustaría que chicos / chicas agreguen sus ideas para asegurarlo y qué programas utilizan para ello.

¿Quiero que parte de esta pregunta cubra qué utiliza como firewall? ¿Solo iptables configurado manualmente o utiliza algún tipo de software para ayudarlo? Cual es la mejor manera? ¿Bloquear todo y permitir solo lo que se necesita? ¿Hay quizás buenos tutoriales para principiantes sobre este tema?

¿Cambias tu puerto SSH? ¿Utiliza software como Fail2Ban para prevenir ataques de fuerza bruta?

Obligatorio:

• instalación del sistema con modo experto, solo paquetes que necesito
• cortafuegos escrito a mano con política predeterminada en la entrada de iptables: caída, que permite el acceso a SSH, HTTP o cualquier otro servidor dado que se esté ejecutando
• Fail2Ban para SSH [y, a veces, FTP / HTTP / otro, según el contexto]
• deshabilitar los inicios de sesión raíz, forzar el uso de usuario normal y sudo
• kernel personalizado [solo viejo hábito]
• actualización programada del sistema

Dependiendo del nivel de paranoia adicionalmente:

• política de caída en la salida, excepto un par de destinos / puertos permitidos
• integritpara verificar si algunas partes del sistema de archivos no están modificadas [con la suma de verificación mantenida fuera de la máquina], por ejemplo Tripwire
• exploración programada al menos con nmap del sistema desde el exterior
• comprobación automática de registros para patrones desconocidos [pero eso es principalmente para detectar el mal funcionamiento del hardware o algunos bloqueos menores]
• ejecución programada de chkrootkit
• atributo inmutable para /etc/passwdagregar nuevos usuarios es un poco más difícil
• / tmp montado con noexec
• el control de puertos u otra forma no estándar de abrir puertos SSH [por ejemplo, visitar la página web 'secreta' en el servidor web permite la conexión SSH entrante durante un período limitado de tiempo desde una dirección IP que visualizó la página. Si se conecta, -m state --satete ESTABLISHEDse encarga de permitir el flujo de paquetes siempre que use una sola sesión SSH]

Cosas que no hago yo mismo pero que tienen sentido:

• seguridad para el núcleo
• syslog remoto para que los registros no se puedan sobrescribir cuando el sistema se ve comprometido
• alertando sobre cualquier inicio de sesión SSH
• configurar rkhunter y configurarlo para que se ejecute de vez en cuando

Solo una nota sobre cortafuegos de su máquina ...

• Use una lista blanca, no una lista negra, es decir, bloquee todo y solo permita lo que necesita, niegue todo lo demás.
• No utilice GUI / ncurses ni ningún otro software que intente realizar la tarea de escribir su firewall por usted. Si lo hace, permitirá que el software haga suposiciones por usted, no necesita correr ese riesgo y no debería hacerlo. Configúrelo usted mismo, si no está seguro, desactívelo; lo descubrirá pronto si es necesario. Si ya es un sistema en funcionamiento y no puede interrumpir el tráfico (bloqueándolo accidentalmente), ejecute tcpdump (volcado a archivo) y tome muestras, estudíelas más tarde y luego descubra qué es válido y qué no.
• Personalmente, no veo ningún punto en ejecutar un servicio en un puerto no estándar, las herramientas no son tan tontas en estos días para suponer que debido a que algo se está ejecutando en el puerto 22, por ejemplo, entonces debe ser ssh, y no de otro modo, por ejemplo amap, y nmapla -Aopción de. Dicho esto, puedes (y probablemente deberías si estás preocupado) modificar tus servicios para esconderse de miradas indiscretas, por ejemplo, lo siguiente le permitiría al atacante saber la versión exacta de lo OpenSSHque estás ejecutando, luego pueden buscar exploits para Esa versión exacta. Si ocultas esas cosas, las harás más difíciles.

    [root @ ud-olis-1 uhtbin] # telnet localhost 22
    Intentando 127.0.0.1 ...
    Conectado a localhost.localdomain (127.0.0.1).
    El carácter de escape es '^]'.
    SSH-2.0-OpenSSH_3.9p1

• Mantenga todos sus servicios públicos actualizados y actualizados con los últimos parches de seguridad.
• No almacene DATOS en el servidor de puerta de enlace, al menos ganará tiempo cuando logren entrar en esta máquina, y perderá un servicio o dos, y algún tiempo, pero no datos.

La conclusión es que nunca tendrá éxito en hacer algo 100% seguro, eso simplemente no es posible, por lo que el objetivo es hacer que sea lo más seguro posible, si es demasiado esfuerzo para romper su sistema, es lo suficientemente bueno, y más flojo script-kiddies pasará al siguiente sistema.

• iptables es el camino a seguir para cualquier sistema Linux, pero configúrelo usted mismo.

Nunca use ningún "software de seguridad" que no esté basado en estándares abiertos: están condenados a estar mal escritos y serán pirateados (no es cuestión de "si", sino de "cuándo"). El código abierto y los protocolos abiertos están abiertos al escrutinio público y convergen para convertirse en un producto maduro y confiable; El software de código cerrado se basa principalmente en la autoconfianza de los autores de cuán grande / seguro es un producto que creen que es, es decir, una pequeña cantidad de ojos frente a una tierra llena de ojos.

Espero que ayude :)

• deshabilitar inicio de sesión raíz
• deshabilitar inicio de sesión por contraseña (permitir solo inicio de sesión por clave pública)
• cambiar el puerto SSH

• use denyhosts (o similar)

• escriba su propio script de iptbles (para que controle exactamente qué permitir y pueda eliminar todo lo demás)

• forzar el uso de comunicaciones seguras SSL / TLS y asegurarse de tener certificados válidos, no caducados y firmados

• active la verificación estricta de certificados para todos los servicios externos (por ejemplo, al autenticar usuarios con un servidor LDAP en otra máquina)

Empieza aqui:

http://www.debian.org/doc/manuals/securing-debian-howto/

Como punto de partida general, sigo los puntos de referencia / guías del Centro de Seguridad de Internet , que son compilaciones completas de las mejores prácticas de seguridad. No parece que su referencia de Debian se haya actualizado en algún tiempo, pero una descripción general de los pasos es:

• Aplicar los últimos parches / paquetes del sistema operativo
• Habilite la contabilidad del sistema / kernel / proceso.
• Habilite MAC (por ejemplo, SELinux o AppArmor).
• Habilite el firewall basado en host (iptables).
• Verifique las fuentes APT.list (las claves son correctas, las fuentes son confiables).
• Minimice los servicios de red, desactive todo lo que no sea necesario y firewall lo que es.
• Use TCPWrappers para restringir aún más el acceso al sistema.
• Solo use protocolos de red encriptados, deshabilite los servicios sin encriptar (telnet, ftp, etc.).
• Configure el acceso remoto solo a SSH.
• Deshabilite las contraseñas de inicio de sesión de los usuarios y requiera autenticación basada en claves.
• Deshabilite el uso compartido del sistema de archivos (NFS, SMB).
• Habilite el registro remoto / centralizado del sistema (¡y revise regularmente los registros!).
• Establezca una contraseña de nivel de BIOS / firmware.
• Establecer una contraseña de gestor de arranque.
• Configure las copias de seguridad del sistema, tenga un plan de recuperación de desastres y PRUEBE que las copias de seguridad son válidas y que el personal conoce los procedimientos de recuperación de desastres.

Hay muchos recursos en todas estas configuraciones, incluidos los comandos específicos y los archivos de configuración para implementar en el sistema en los puntos de referencia de CISecurity.

Sugeriría no conectar una máquina directamente a Internet. Coloque algún tipo de firewall entre la máquina e Internet. Esto le permite hacer monitoreo de seguridad y de red sin poner más carga en el servidor. Personalmente, creo que la segmentación de redes y funciones con frecuencia simplifica la resolución de problemas de la red, aunque en ocasiones, la complejidad adicional dificulta el análisis.

La política de firewall más segura, pero más molesta de administrar, es negar todo y permitir explícitamente solo el tráfico que debe permitir. Esto es molesto, porque con frecuencia se necesita actualizar la política del firewall a medida que la red necesita cambiar.

También sugeriría utilizar algún tipo de firewall de interfaz en el servidor: la defensa en profundidad es la clave. El uso de puertos no estándar para servicios relacionados con la administración no hace daño. fail2ban está bien. Siga las preguntas más específicas sobre las aplicaciones de seguridad en Serverfault para encontrar más ideas.

La seguridad es como la broma sobre los dos excursionistas y el oso: aunque uno nunca puede lograr la seguridad perfecta, es útil ser un objetivo más difícil que los otros muchachos.

Algunas personas han señalado el Manual de seguridad de Debian . Esto debería ser perfectamente adecuado para todo menos para requisitos militares.

Muchas personas piensan que ser ridículamente paranoico es genial o profesional o algo así. Es no , es sólo molesto para otros administradores de plano y represiva para sus usuarios. La mayoría de las cosas que verá recomendadas son solo trabajo falso para sentirse útil para el administrador paranoico, pero en realidad no son útiles, ya que la violación de seguridad real probablemente sea causada por un sistema no suficientemente actualizado y / o de una fuente interna.

Dicho esto, considero que uno de mis principios es no confiar en nada en la red local más que nada en Internet. Por lo tanto, configuro todo para requerir autenticación incluso en la red local. Encripto y autentico todo el tráfico entre cada computadora usando IPsec.

Estoy en el proceso de convertir al cifrado de disco completo para todos mis servidores.

Instalo solo los servicios que uso. No tengo un firewall; Configuro los servicios que necesito para requerir autenticación o limitarlos (por la propia configuración del programa o por envoltorios TCP) a ciertas IP. Lo único que necesitaba bloquear usando iptables era memcachedque no tenía ningún archivo de configuración y no usaba envoltorios TCP.

Utilizo buenas contraseñas generadas aleatoriamente para mis cuentas y confío en mi servidor SSH (y en todos los demás servicios) para mantener a los que no conocen la contraseña. fail2banes solo para aquellos con espacio limitado para archivos de registro, IMO. (Debería tener contraseñas lo suficientemente buenas como para poder confiar en ellas).

Revise este buen tutorial en www.debian.org/doc/manuals/securing-debian-howto/

Personalmente, cambio el puerto ssh y uso fail2ban + denyhosts. Y bloqueo todo lo que no es necesario. Cuanto más bloquees, menos tendrás que preocuparte.