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

66

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?

Peter Mortensen
fuente
1
Hay mucha superposición con serverfault.com/questions/42/securing-a-fresh-ubuntu-server y
Zoredache
1
Ubuntu tiene UFW Debian no lo hace;) Me woundering si las personas fueron configurando iptables ellos mismos o utilizando algún software como firehol
Thomaschaaf
Siempre he tendido a escribir las reglas de iptables. Tengo una placa de caldera que hace cosas como soltar todos los fragmentos, paquetes de Navidad, etc. Cualquier cosa más allá de eso es específica del sistema, y ​​generalmente es bastante pequeña. No puedo enfatizar suficientes fragmentos al usar iptables, por cierto. Por alguna razón que aún no he investigado, iptables solo verifica el primer fragmento y pasa ciegamente el resto sin verificarlo. En mi opinión, eso hace que los fragmentos sean una responsabilidad.
Scott Pack
3
Uhm ... Debian tiene ufw. packages.debian.org/ufw
womble

Respuestas:

50

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
pQd
fuente
44
Después de hacer todo esto, ejecuta BASTILLE contra el sistema para buscar cualquier otra cosa. También recomendaría hacer un escaneo completo de controles inseguros de Nessus del sistema; luego arregle todo lo que alerta.
Scott Pack
13
Compilar un kernel personalizado no proporciona ventajas de seguridad a menos que realmente sepa lo que está haciendo. También descuidará mantenerlo actualizado a menos que lo coloque dentro del sistema de administración de paquetes, lo que podría empeorar la seguridad.
Adam Gibbins
3
-1 por seguridad a través de la oscuridad. De lo contrario, una respuesta decente.
dwc
@ Adam: sí, lo sé, aún así prefiero tener un núcleo monolítico que consta solo de las partes que necesito. eso es probablemente muy atrasado, pero aún así lo hago. @dwc: es solo un paso adicional que es solo una guinda o, como decimos, cereza en la cima de la pila de cosas desagradables y malolientes.
pQd
1
Y te refieres a sudo no su -
LapTop006
18

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

Jerjes
fuente
"... un pequeño número de ojos frente a una tierra llena de ojos". - Deseo que suficientes "corporaciones" se den cuenta de esto, pero la seguridad a través de la oscuridad parece ser la tendencia más seguida. Sí, ejecutar un servicio, como ssh, en un puerto no estándar no mantendrá alejado a un atacante determinado. Sin embargo, mantendrá alejados los script kiddies: alguien ejecuta un ataque de diccionario en un rango de direcciones IP en el puerto 22.
L0neRanger
12
  • 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)
x-way
fuente
Obtienes un voto positivo por deshabilitar la autenticación de contraseña.
derobert
6

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.

jtimberman
fuente
5

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.

pcapademic
fuente
+1 para una buena respuesta. Debo señalar que la denegación predeterminada no es molesta de administrar si la aborda correctamente. Seguramente debes saber lo que estás permitiendo, ¿verdad? De hecho, esto debe escribirse en lenguaje sencillo como una declaración de política. Si no está haciendo eso como una rutina normal, entonces no está haciendo su trabajo como administrador. Si es así, es sencillo actualizar las reglas del firewall.
dwc
Muy buenos puntos. Cada organización debe tener una declaración de política de seguridad en lenguaje sencillo. A medida que cambian las necesidades de la organización, la declaración de política debe actualizarse. Aunque solo fuera para que el administrador planifique la implementación de la regla de firewall y el CYA, un administrador inteligente mantendría dicha declaración de política incluso si la administración de la organización no puede molestarse en pensar en la seguridad.
pcapademic
4

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

Osito de peluche
fuente
3

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.

Vihang D
fuente
44
Ugh Me tenías hasta "cambiar el puerto SSH". No tiene sentido. Especialmente no cuando cualquier joe schmoe con suficiente tiempo en sus manos puede escanear puertos y descubrir instantáneamente en qué puerto se está ejecutando SSH. Declara el nombre del servicio (y la versión del servidor) tan pronto como se conecte.
Matt Simmons
3
Sí, sé que cualquiera puede escanear el puerto y encontrar el puerto correcto. Pero la mayoría de los ataques están en el puerto predeterminado. Solo intenta obtener algunas estadísticas cambiando el puerto.
Vihang D