¿Se está ejecutando apt-get upgrade de vez en cuando para mantener un servidor web seguro?

Ha eliminado muchos problemas que normalmente lo meten en problemas (es decir, suponiendo que la aplicación que está alojando es completamente segura). Desde una perspectiva práctica, es absolutamente necesario tenerlos en cuenta.

Pero, presumiblemente, dado que los conoce, tiene algunas medidas de protección implementadas. Entonces hablemos del resto.

Para empezar, probablemente no debería ejecutar una actualización "de vez en cuando". La mayoría de las distribuciones operan listas de correo de anuncios de seguridad, y tan pronto como se anuncia una vulnerabilidad allí, es bastante pública (bueno, a menudo es antes de eso, pero en su situación realmente no puede monitorear todas las listas de seguridad en el mundo). Estas son listas de poco tráfico, por lo que realmente debería suscribirse a su distribución y actualizarla cuando reciba notificaciones de ella.

A menudo, un servidor con mantenimiento casual puede ser atacado por fuerza bruta o por diccionario durante un largo período de tiempo, ya que el mantenedor no está realmente buscando las señales. Entonces, es una buena idea aplicar las contramedidas habituales (autenticación de contraseña sin ssh, fail2ban en ssh y apache) e idealmente configurar alertas de monitoreo cuando ocurra actividad sospechosa. Si eso está fuera de su presupuesto de mantenimiento (tiempo), acostúmbrese a iniciar sesión regularmente para verificar esas cosas manualmente.

Si bien no se considera tradicionalmente como parte de la seguridad, desea asegurarse de que puede iniciar un nuevo servidor rápidamente. Esto significa scripts de configuración del servidor (herramientas como Ansible, Chef, etc. son útiles en la administración del sistema de todos modos) y un sistema de respaldo automático que haya probado. Si su servidor ha sido violado, debe asumir que está comprometido para siempre y simplemente borrarlo, y eso apesta si no ha realizado copias de seguridad periódicas de sus datos.

No. Esto es no suficiente para mantenerte seguro.

Probablemente lo mantendrá seguro por algún tiempo, pero la seguridad es compleja y acelerada, por lo que su enfoque realmente no es lo suficientemente bueno para la seguridad a largo plazo. . Si todos hicieran las mismas suposiciones que usted está haciendo en su pregunta, Internet sería una gran red de bots ahora.

Así que no, no limitemos esta pregunta a los paquetes. Analicemos la seguridad del servidor de manera integral para que cualquiera que lea esto tenga una idea de cuántas piezas en movimiento hay realmente.

• APT (por ejemplo, los repositorios de Ubuntu) solo cubre una parte de su pila de software. Si está utilizando (por ejemplo) Wordpress u otra biblioteca PHP popular y no está controlada por un repositorio, también debe actualizarla. Los marcos más grandes tienen mecanismos para automatizar esto, pero asegúrese de realizar copias de seguridad y monitorear el estado del servicio porque no siempre funcionan bien.

• ¿Lo escribiste todo tú mismo, así que crees que estás a salvo de los niños del guión? Hay inyección de SQL automatizada y bot de explotación XSS corriendo, hurgando en cada cadena de consulta y formulario por igual.

  Este es en realidad uno de los lugares donde un buen marco ayuda a proteger contra programadores inadecuados que no aprecian los matices de estos ataques. Tener un programador competente auditando el código también ayuda a disipar los temores aquí.

• ¿PHP (o Python, o lo que sea que esté ejecutando) realmente necesita poder escribir en todas partes? Reforzar su configuración y mitigarás muchos ataques. Idealmente, los únicos lugares donde una aplicación web es capaz para escribir son una base de datos y lugares donde las secuencias de comandos nunca se ejecutarán (por ejemplo, una regla nginx que solo permite servir archivos estáticos).

  Los valores predeterminados de PHP (al menos cómo los usan las personas) permiten que PHP lea y escriba PHP en cualquier lugar de la raíz web. Eso tiene serias implicaciones si su sitio web es explotado.

• Y su programa de actualización es activamente dañino. ¿Qué diablos es "de vez en cuando"? Los errores de seguridad remotos críticos tienen una vida media corta, pero ya hay un retraso entre el día 0 y la disponibilidad del parche, y algunos exploits también se revierten a partir de los parches (para detectar los ataques lentos).

  Si solo está aplicando actualizaciones una vez al mes, existe una gran posibilidad de que esté ejecutando software explotable en la naturaleza. TL;DR:Usa actualizaciones automáticas.

• Las versiones de distribuciones no duran para siempre. Si fue sensato y eligió una versión LTS de Ubuntu, tiene 5 años desde el lanzamiento inicial. Dos versiones LTS más saldrán dentro de ese tiempo y eso te da opciones.

  Si estaba en un alboroto de "NUEVO ES MEJOR" y optó por 16.10 cuando configuró su servidor, tiene 9 meses . Sí. Luego, debe actualizar hasta 17.04, 17.10 antes de poder relajarse en 18.04 LTS.

  Si su versión de Ubuntu caduca, puede actualizar durante todo el día, sin embargo, no obtendrá ninguna actualización de seguridad.

• Y la pila LAMP en sí misma no es el único vector de ataque a un servidor web estándar.

  • Usted debe fortalecer su configuración SSH:solo use claves SSH, deshabilite contraseñas, desvíe el puerto, deshabilite los inicios de sesión raíz, controle los intentos brutos y bloquéelos con fail2ban .
  • Cortafuegos de cualquier otro servicio con ufw (y otros).
  • Nunca exponga la base de datos (a menos que necesite y luego bloquee la IP entrante en el firewall).
  • No deje scripts PHP aleatorios instalados o lo hará olvídalos y ellos lo harán ser hackeado.

• No hay seguimiento en su descripción. Estás ciego. Si algo entra allí y comienza a enviar spam, infectar sus páginas web, etc., ¿cómo puede saber que sucedió algo malo? Seguimiento de procesos. Comparación de archivos programada con git (asegúrese de que sea acceso de solo lectura desde el servidor).

• Considere la seguridad (física y remota) de su ISP. ¿Están los "hosts" de diez centavos (también conocidos como piratas de CPanel), que gastan $ 2 / mes en planes de alojamiento ilimitados, que invierten los mismos recursos en seguridad que una instalación de servidor dedicado? Pregunte e investigue el historial de infracciones.

• Y luego estás tú . La seguridad de la computadora en la que codificas todo esto es casi tan importante como el servidor. Si usa las mismas contraseñas, es una responsabilidad. Proteja sus claves SSH con una clave física FIDO-UF2.

He estado haciendo DevOps durante ~15 años y es algo que puede aprender en el trabajo, pero en realidad solo se necesita una infracción (un adolescente, un bot) para arruinar un servidor completo y causar semanas de trabajo desinfectando el producto de trabajo.

Solo siendo consciente sobre lo que se está ejecutando y lo que está expuesto, lo ayuda a tomar mejores decisiones sobre lo que está haciendo. Solo espero que esto ayude a alguien a iniciar el proceso de auditoría de su servidor.

Pero si usted, el programador de aplicaciones web promedio, no está dispuesto a profundizar en este tipo de cosas, ¿debería incluso ejecutar un servidor? Esa es una pregunta seria. No voy a decirle que no debería hacerlo en absoluto, pero ¿qué sucede cuando ignora todo esto? Su servidor es pirateado, su cliente pierde dinero y expone información personal del cliente (por ejemplo, datos de facturación) y lo demandan. ? ¿Está asegurado para ese nivel de riesgo de pérdida y responsabilidad?

Pero sí, esta es la razón por la que los servicios gestionados cuestan mucho más que los servidores tontos.

Sobre la virtud de las copias de seguridad...

Una copia de seguridad completa del sistema es posiblemente lo peor que puede tener, por seguridad. — porque estarás tentado a usarlo si te piratean. Su único lugar es recuperarse de una falla de hardware.

El problema de usarlos en hacks es que se restablece a un punto anterior en el tiempo. Sin embargo, ahora son evidentes más fallas en su pila, existen aún más exploits para el agujero que lo atrapó. Si vuelve a poner ese servidor en línea, podría ser pirateado al instante. Podría bloquear el tráfico entrante y hacer una actualización del paquete y eso podría ayudarlo, pero en este punto todavía no sabe qué lo atrapó o cuándo lo atrapó. Estás basando todas tus suposiciones en un síntoma que viste (inyección de anuncios en tus páginas, spam rebotado en tu mailq). El hack podría haber sido meses antes de eso.

Obviamente, son mejores que nada, y están bien en el caso de que un disco se apague, pero, de nuevo, son basura para la seguridad. .

Buenas copias de seguridad son recetas

Quiere algo, solo un documento en lenguaje sencillo o algo técnico como una rutina Ansible/Puppet/Chef, que pueda guiar a alguien para restaurar todo el sitio en un servidor completamente nuevo. Cosas a considerar:

• Una lista de paquetes para instalar
• Una lista de cambios de configuración para realizar
• Cómo restaurar la fuente del sitio web desde el control de versiones.
• Cómo restaurar el volcado de la base de datos* y cualquier otro archivo estático que no pueda controlar.

Cuanto más detallado seas aquí, mejor porque esto también sirve como una copia de seguridad personal . Mis clientes saben que si yo mueren, tienen un probado planean restaurar sus sitios en el hardware que controlan directamente.

Una buena restauración con guión no debería llevar más de 5 minutos. Por lo tanto, incluso la diferencia de tiempo entre una restauración con secuencia de comandos y la restauración de una imagen de disco es mínima.

Es muy probable que mantenga el servidor principalmente seguro si ejecuta actualizaciones con frecuencia (es decir, al menos diariamente, en lugar de solo "de vez en cuando").

Pero, los errores críticos ocurren de vez en cuando, como Shellshock o ImageTragick. También la configuración insegura del servidor podría hacer posibles los ataques. Esto significa que también debe realizar más acciones además de ejecutar actualizaciones periódicas, como:

• reduzca la superficie de ataque ejecutando un sistema mínimo, es decir, no instale ningún software innecesario
• reduzca la superficie de ataque restringiendo cualquier servicio accesible desde el exterior, es decir, no permita el inicio de sesión SSH basado en contraseña (solo basado en clave), no ejecute servicios innecesarios, etc.
• asegúrese de comprender el impacto de las actualizaciones críticas
• espere que el sistema sea atacado e intente reducir el impacto, por ejemplo ejecutando servicios a los que se puede acceder desde el exterior dentro de algún chroot, cárcel o contenedor
• registrar eventos importantes como inicios de sesión fallidos, comprender los registros y analizarlos

Aún así, el vector de ataque inicial más utilizado son probablemente las aplicaciones web inseguras como Wordpress u otro CMS. Pero su suposición era que la aplicación web es completamente segura, así que espero que realmente lo sea.