He estado haciendo una investigación "extensa" sobre la seguridad de un servidor web Linux. Además de lo que se considera lo "básico" (eliminación de servicios no utilizados, fortalecimiento de ssh, iptables, etc.), ¿es aconsejable incluir anti-rootkits (Tripwire) y un antivirus (ClamAV)? ¿Son estos simplemente excesivos para un servidor web? Sé que esta es una pregunta muy vaga, pero tengo curiosidad sobre las opiniones de los demás.
Mi entorno futuro: - ubuntu 10.04 - fail2ban - nginx 0.8.x - php 5.3.x (suhosin, apc, memcached) - mongodb 1.6.x
Posibles aplicaciones: - servicios web - aplicaciones web con cargas de usuarios (imágenes, archivos PDF, etc.) - sitios web típicos (formularios, etc.)
Si tiene algún otro consejo, ¡no dude en agregarlo!
Gracias
No, no fuiste lo suficientemente lejos.
1) Necesita un firewall de aplicación web como mod_security y asegúrese de que esté configurado para bloquear ataques, no solo para registrarlos.
2) Bloquee php con phpsecinfo .
3) Bloquee la cuenta MySQL de su aplicación web, asegúrese de que su aplicación no tenga
FILEprivilegios, es con mucho la más peligrosa en MySQL.4) Cortafuegos de todos los UDP y todos los TCP que no necesita. Considere la posibilidad de utilizar el puerto de golpe para ssh No prohibir no es tan bueno como conseguir cero intentos.
fuente
Probablemente pueda instalar AIDE de forma segura en un servidor web: agregar y eliminar clientes no cambia demasiados archivos de configuración, y probablemente podría filtrar la conversación normal con bastante facilidad.
Pero algo que muchas guías de seguridad del servidor web no mencionan es que debe activar noexec en su partición / tmp en / etc / fstab. Si está ofreciendo alojamiento al público, muchas personas instalarán aplicaciones web inseguras sin su conocimiento (y no tienen el conocimiento para mantener sus aplicaciones actualizadas), y básicamente están persiguiendo estos errores para siempre. Si se asegura de que el único lugar donde un atacante puede guardar el software es el directorio de inicio del cliente y el directorio / tmp, entonces el atacante corre el riesgo de mostrarle dónde están ingresando si no pueden usar el directorio / tmp. No les gusta hacer eso.
Hacer esto ha resuelto la gran mayoría de los problemas de seguridad en nuestro servidor de alojamiento web.
fuente
"¡Bienvenido a bordo! A bordo de nuestro nuevo avión puede disfrutar de restaurante, cine, gimnasio, sauna y piscina. Ahora abróchense los cinturones de seguridad, nuestro capitán tratará de llevar toda esta mierda al aire".
mod_security es una molestia tanto para usted como para el servidor. Sus recursos están hambrientos y sus reglas necesitan un mantenimiento serio y será una tarea interminable. Y no, no funciona de forma independiente o con Nginx. Si siente que realmente lo necesita, configure un servidor proxy separado (Apache, mod_proxy, mod_security). También funciona como DMZ, sus servidores reales pueden cerrarse por completo al mundo exterior, y si se rompe el proxy, de todos modos no hay nada.
ClamAV también es muy pesado, si se ejecuta como un demonio. Es mejor ejecutar clamscan periódicamente durante horas no activas desde Cron.
Tripwire es excesivo, en mi humilde opinión. Pero algo útil para cazar rootkits sería útil, hay muchos scripts (rkhunter, chkrootkit).
Creo que al menos el 90% de los rootkits, etc., llegan a los servidores a través de cargas desde máquinas de desarrollo de Windows. No hay una buena manera de evitar esto, excepto forzar a los desarrolladores a nunca usar Windows. La mayoría de los troyanos buscan credenciales FTP, por lo que nunca use FTP.
fuente
¿El uso de la protección de formulario captcha en el popular motor CMS (Wordpress, Jomlaa, Drupal) se considera prácticas de seguridad? En caso afirmativo, puede usar estos:
fuente