¿Mejores prácticas para asegurar un servidor web público? [cerrado]

Navega tus respuestas
5

Estoy buscando hacer una lista de verificación "mínima" para asegurar un servidor web público Unix. Supongamos que es una pila LAMP (o similar). Esta lista debe ser lo que mínimos implementarías. Obviamente, los requisitos aumentarán para los sitios de alto tráfico (protección DDoS, alta disponibilidad, etc.), pero no me preocupa eso. Solo busco una lista de los mínimos para hospedar un único servidor web que ejecute Apache o NGINX y que tenga una base de datos MySQL o MariaDB básica en el servidor y una aplicación PHP sencilla. Supongamos que se está ejecutando en AWS, DigitalOcean, etc. Algunas ideas incluyen:

  • Rangos de IP de listas negras / listas blancas por país
  • Deshabilitar el inicio de sesión remoto por root
  • Habilitar fail2ban (deshabilita las IP después de tantos intentos fallidos de inicio de sesión)
  • Configure el firewall para que solo permita la entrada de puertos relevantes (por ejemplo, ssh, sftp, https)
  • Solo permita HTTPS y luego pruebe la validez del certificado y la configuración del servidor utilizando la herramienta de prueba Qualys SSL Labs ( enlace )
  • Habilite la autenticación de múltiples factores en todos los lugares públicos, como Amazon / Digital Ocean / etc. cuenta, sus credenciales al servidor, etc.
  • Cambie la contraseña de root a un mínimo de 16 caracteres, alfanuméricos con caracteres especiales.
  • ¿Qué más?
pregunta wubs 08.03.2017 - 17:15
fuente

2 respuestas

2

Marcus Müller tiene un punto, esta es una pregunta muy amplia.

Las mejores políticas de seguridad tienen un enfoque. Algún famoso general (¿Federico el Grande?) Una vez dijo "proteger todo es proteger nada". Comience estableciendo un "perfil de amenazas" para que sepa de qué se está protegiendo, luego identifique las mejores prácticas para protegerse de las amenazas . Obviamente, revise su perfil de amenaza cada vez que experimente ataques específicos.

A lo que ya se ha dicho, agregaría lo siguiente:

  • Mueve tu sshd a un puerto no estándar. El script kiddies ataca el puerto 22, si tu sshd no está allí, solo los atacantes más inteligentes incluso lo encontrarán.

  • Considere poner todos los puertos de escucha no públicos (sshd, SNMP, rsyslogd, etc.) detrás de una VPN. El acceso (humano o inter-servidor) a esos servicios será un poco más tedioso de configurar, pero esto ofrece una fuerte protección. El acceso solo VPN es especialmente recomendado para servidores que no requieren acceso público directo (como servidores de base de datos o de cola de mensajes).

  • Defina reglas de egreso para su firewall, no solo reglas entrantes. Especialmente para los servicios que a los blackhats les gusta explotar una vez que han atacado tu servidor (como SMTP). Si de alguna manera su servidor se ve comprometido, pero su secuestrador no puede hacer ping o SMTP o SFTP hacia el exterior ... esa es una línea de defensa adicional que le da tiempo para atacarlos.

  • (requiere mucho trabajo, pero vale la pena) Considere la posibilidad de actualizar toda su granja de servidores a IPv6 (que todos tendrán para hacer lo suficientemente pronto de todos modos). Tenga en cuenta que fail2ban será menos valioso ya que solo funciona en IPv4. IPSec está integrado en IPv6.

respondido por el Daniel de Segovia Gross 09.03.2017 - 11:51
fuente
3

Definitivamente agregaría que SSH no debería permitir solo la autenticación con contraseña, sino la clave pública (y / o algún segundo token).

Personalmente agregaría habilitar seLinux (o appArmor) a la lista, y también habilitaría y configuraría auditd, y exigiría el uso de sudo.

Hay mucho más que podrías hacer si quisieras superar el mínimo, pero consideraría esas tres cosas como parte de la base que desearías.

Si desea algo más formal, puede consultar los puntos de referencia de CIS ( enlace ). Posiblemente no sean mínimos, pero tienen algún reconocimiento (sea cual sea su opinión sobre el CIS).

CentOS (y sospecho que a RedHat le gusta) también tiene algunas herramientas para SCAP ( enlace ) que puede consultar si se aplican.

    
respondido por el iwaseatenbyagrue 08.03.2017 - 20:14
fuente

Lea otras preguntas en las etiquetas

¿Es prudente mostrar que “el correo electrónico ha sido analizado por el antivirus XYZ” en el pie de página de los correos electrónicos? [cerrado] ¿Cuál es la diferencia entre las "Autoridades de certificación de raíz de confianza" y las "Autoridades de certificación de raíz de terceros" en los almacenes de certificados de Windows?