¿Servidor web de seguridad excesivo?

9

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

— Aaron
fuente

8

Para un servidor público, diría que instalar algo como tripwire no es excesivo.

ClamAV es un asunto diferente. Consideraría configurar eso si sus visitantes compartirán archivos cargándolos y descargándolos de su sitio web. Los archivos PDF pueden contener exploits.

En los servidores públicos, tengo SSH que no permite la autenticación de contraseña, solo la autenticación de clave pública. Si SSH solo es posible desde una LAN interna, entonces puede relajar esto.

Siempre que sea posible, colocaría el servidor en una DMZ para que no pueda originar conexiones a otras computadoras en sus LAN internas.

— RedGrittyBrick
fuente

2

No olvide LMD (Linux Malware Detection), rfxn.com/projects/linux-malware-detect : esto busca el tipo de malware que infecta aplicaciones web (HTML, PHP, cambios de archivos JavaScript) para usar su sitio para SEO spam, phishing, infección de las PC de los visitantes, etc.

— RichVel

3

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.

— Torre
fuente

1) Tenía la impresión de que ModSecurity solo podía empaquetarse con Apache (estoy usando nginx). ¿Pero aparentemente puede funcionar de manera independiente? Tendré que investigar esto gracias! He seguido calomel.org/nginx.html para algunas características.

— Aaron

4) Uso iptables para bloquear todo el tráfico entrante y saliente a menos que sea mi puerto ssh, https o https (entrante, saliente). Abriré más a medida que avance. Sin embargo, el golpe de puerto es una adición interesante para ssh. ¡Gracias de nuevo!.

— Aaron

@ Aaron, no estoy seguro de por qué usarías nginx. Puede usar apache + mod_security como proxy con cualquier httpd extraño y sin características que exija usar.

— Torre

2

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.

— Ernie
fuente

2

"¡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.

— moskit
fuente

Es bueno saberlo ... Teniendo en cuenta que no tengo intención de tomar la ruta apache, me atendré a todos los aspectos de seguridad que pueda encontrar para nginx. Probablemente terminaré tomando la ruta clamscan / rkhunter también. ¡Gracias por los consejos!

— Aaron

0

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

— affanzbasalamah
fuente

Protección anti spam ? Si. Pero aquí el autor quiere bloquear su servidor contra usuarios no autorizados, con lo que captcha no tiene nada que ver.