Recientemente (pero también es una pregunta recurrente) vimos 3 hilos interesantes sobre piratería y seguridad:

¿Cómo trato con un servidor comprometido? .
Descubrir cómo se pirateó un servidor pirateado
Pregunta sobre permisos de archivos

El último no está directamente relacionado, pero destaca lo fácil que es arruinar la administración de un servidor web.

Como hay varias cosas que se pueden hacer, antes de que ocurra algo malo, me gustaría tener sus sugerencias en términos de buenas prácticas para limitar los efectos de un ataque y cómo reaccionar en el triste caso.

No se trata solo de proteger el servidor y el código, sino también de auditorías, registros y contramedidas.

¿Tiene alguna lista de buenas prácticas o prefiere confiar en el software o en expertos que analizan continuamente su (s) servidor (es) web (o nada)?

En caso afirmativo, ¿puede compartir su lista y sus ideas / opiniones?

ACTUALIZAR

Recibí varios comentarios buenos e interesantes.

Me gustaría tener una lista simple, de modo que pueda ser útil para los administradores de seguridad de TI, pero también para los maestros de factotum web .

Incluso si todos dieron respuestas buenas y correctas, en este momento prefiero la de Robert, ya que es la más simple, clara y concisa, y la de sysadmin1138, ya que es la más completa y precisa.

Pero nadie considera la perspectiva y la percepción del usuario, creo que es lo primero que hay que tener en cuenta.

Lo que pensará el usuario cuando visite mi sitio pirateado, mucho más si posee datos sensibles sobre ellos. No se trata solo de dónde almacenar los datos, sino de cómo calmar a los usuarios enojados.

¿Qué pasa con los datos, medios, autoridades y competidores?

Hay dos grandes áreas en las que enfocarse:

1. Haciendo que sea difícil entrar.
2. Crear políticas y procedimientos para manejar con calma y eficiencia el evento de que alguien ingrese al punto 1 anterior.

Haciendo difícil entrar

Este es un tema muy complejo, y gran parte se centra en asegurarse de que tenga suficiente información para descubrir que WTF sucedió después del hecho. Los puntos abstractos para simplificar:

• Mantener registros (véase también, Gestión de eventos de información de seguridad)
  • Cualquier intento de autorización, tanto exitoso como fallido, preferentemente con la fuente de información intacta
  • Registros de acceso al cortafuegos (esto puede tener que incluir cortafuegos por servidor, si está en uso).
  • Registros de acceso al servidor web
  • Registros de autenticación del servidor de bases de datos
  • Registros de uso específicos de la aplicación
  • Si es posible, el SIEM puede lanzar alertas sobre patrones sospechosos.
• Hacer cumplir los controles de acceso adecuados
  • Asegúrese de que los derechos estén configurados correctamente en todas partes y evite los "derechos perezosos" ("oh, solo lea a todos") siempre que sea posible.
  • Las auditorías periódicas de las ACL para garantizar que los procedimientos se sigan realmente, y los pasos temporales de solución de problemas ("dar lectura a todos, ver si funciona entonces") se han eliminado correctamente después de que la solución de problemas haya finalizado.
  • Todas las reglas de paso del firewall deben estar justificadas y auditadas periódicamente.
  • Los controles de acceso al servidor web también deben ser auditados, tanto el servidor web como las ACL del sistema de archivos.
• Hacer cumplir la gestión del cambio
  • Cualquier cambio en el entorno de seguridad debe ser rastreado y revisado centralmente por más de una persona.
  • Los parches deben incluirse en este proceso.
  • Tener una compilación de SO (plantilla) común simplificará el entorno y hará que los cambios sean más fáciles de rastrear y aplicar.
• Deshabilitar cuentas de invitado.
• Asegúrese de que todas las contraseñas no estén configuradas por defecto.
  • Las aplicaciones estándar pueden configurar usuarios con contraseñas predefinidas. Cámbialos.
  • Muchos dispositivos de TI se envían con pares de usuario / contraseña que son muy conocidos. Cambie esos, incluso si inicia sesión en esa cosa solo una vez al año.
• Practica el mínimo privilegio. Brinde a los usuarios el acceso que realmente necesitan.
  • Para los usuarios administradores, es aconsejable una configuración de dos cuentas. Una cuenta regular utilizada para correo electrónico y otras tareas de oficina, y una segunda para trabajo con privilegios elevados. Las máquinas virtuales hacen que sea más fácil vivir con ellas.
  • NO aliente el uso regular de cuentas genéricas de administrador / root, es difícil rastrear quién estaba haciendo qué y cuándo.

Crear políticas y procedimientos para manejar con calma y eficiencia el evento de que alguien ingrese

Una política de eventos de seguridad es imprescindible para todas las organizaciones. Reduce en gran medida la fase de respuesta "correr con la cabeza cortada", ya que las personas tienden a volverse irracionales cuando se enfrentan a eventos como estos. Las intrusiones son asuntos grandes y aterradores. La vergüenza de sufrir una intrusión puede causar que los administradores de sistemas de nivel superior comiencen a reaccionar incorrectamente.

Todos los niveles de la organización deben conocer las políticas. Mientras más grande sea el incidente, es más probable que la alta gerencia se involucre de alguna manera, y establecer procedimientos para manejar las cosas ayudará enormemente a defenderse de la "ayuda" desde lo alto. También brinda un nivel de cobertura para los técnicos directamente involucrados en la respuesta al incidente, en forma de procedimientos para que la gerencia intermedia se comunique con el resto de la organización.

Idealmente, su política de Recuperación de Desastres ya ha definido por cuánto tiempo ciertos servicios pueden no estar disponibles antes de que la política de DR entre en vigencia. Esto ayudará a la respuesta a incidentes, ya que este tipo de eventos son desastres. Si el evento es de un tipo en el que NO se cumplirá la ventana de recuperación (por ejemplo: un sitio DR de respaldo en caliente obtiene una fuente en tiempo real de datos modificados, y los intrusos eliminaron un grupo de datos que se replicaron en el sitio DR antes de que fueran por lo tanto, será necesario utilizar procedimientos de recuperación en frío) y luego la alta gerencia deberá involucrarse en las conversaciones de evaluación de riesgos.

Algunos componentes de cualquier plan de respuesta a incidentes:

• Identificar los sistemas comprometidos y los datos expuestos.
• Determine con anticipación si será necesario retener evidencia legal para un enjuiciamiento eventual.
  • Si se va a retener evidencia , no toque nada sobre ese sistema a menos que sea absolutamente necesario . No inicies sesión en él. No tamizar a través de los archivos de registro. Hacer. No. Toque.
  • Para conservar las pruebas, los sistemas comprometidos deben dejarse en línea pero desconectados hasta que un experto forense informático certificado pueda diseccionar el sistema de una manera compatible con las reglas de manejo de pruebas.
    • Apagar un sistema comprometido puede contaminar los datos.
    • Si su sistema de almacenamiento permite esta (dispositivo SAN discreto), tome una instantánea de los LUN afectados antes de la desconexión y márquelos como de solo lectura.
  • Las reglas de manejo de evidencia son complejas y tan fáciles de fastidiar. No lo hagas a menos que hayas recibido capacitación sobre ellos. La mayoría de los administradores de sistemas generales NO tienen este tipo de entrenamiento.
  • Si se retienen pruebas, trate la pérdida de servicio como un desastre de pérdida de hardware y comience los procedimientos de recuperación con nuevo hardware.
• Las reglas preestablecidas para qué tipos de desastres requieren qué tipo de aviso. Las leyes y regulaciones varían según la localidad.
  • Las reglas relativas a 'exposición' y 'compromiso comprobado' varían.
  • Las reglas de notificación requerirán que el departamento de Comunicaciones se involucre.
  • Si el aviso requerido es lo suficientemente grande, la administración de nivel superior tendrá que participar.
• Utilizando los datos de DR, determine cuánto tiempo puede pasar "WTF recién sucedido" antes de que el servicio vuelva a estar en línea se convierta en una prioridad más alta.
  • Los tiempos de recuperación del servicio pueden requerir el trabajo de descubrir qué pasó a estar subordinado. Si es así, tome una imagen de la unidad del dispositivo afectado para su disección después de restaurar los servicios (esta no es una copia probatoria, es para que los técnicos realicen ingeniería inversa).
  • Planifique sus tareas de recuperación de servicios para incluir una reconstrucción completa del sistema afectado, no solo para limpiar el desorden.
  • En algunos casos, los tiempos de recuperación del servicio son lo suficientemente ajustados como para que se deban tomar imágenes de disco inmediatamente después de que se haya identificado un compromiso y no se conserven pruebas legales. Una vez que se reconstruye el servicio, puede comenzar el trabajo de averiguar qué sucedió.
• Examine los archivos de registro para obtener información relacionada con cómo entró el atacante y qué pudo haber hecho una vez dentro.
• Examine los archivos modificados para obtener información relacionada con cómo ingresaron y qué hicieron una vez que ingresaron.
• Examine los registros del cortafuegos para obtener información sobre de dónde provienen, a dónde podrían haber enviado datos y cuánto se pudo haber enviado.

Tener políticas y procedimientos establecidos antes de un compromiso, y bien conocidos por las personas que los implementarán en caso de un compromiso, es algo que solo hay que hacer. Proporciona a todos un marco de respuesta en un momento en que las personas no pensarán con claridad. La alta gerencia puede tronar y retumbar sobre demandas y cargos criminales, pero en realidad reunir un caso es un proceso costoso y saber que de antemano puede ayudar a amortiguar la furia.

También noto que este tipo de eventos deben tenerse en cuenta en el plan general de Respuesta a Desastres. Es muy probable que un compromiso active la política de respuesta de 'hardware perdido' y también que active la respuesta de 'pérdida de datos'. Conocer los tiempos de recuperación de su servicio ayuda a establecer la expectativa de cuánto tiempo puede tener el equipo de respuesta de seguridad para analizar el sistema comprometido real (si no guarda evidencia legal) antes de que sea necesario en la recuperación del servicio.

Cómo pueden ayudar los procedimientos adecuados del servicio de asistencia

Debemos considerar cómo se trata a los clientes aquí (esto se aplica tanto a los clientes internos como externos que contactan a un servicio de asistencia).

En primer lugar, la comunicación es importante ; los usuarios se enojarán por la interrupción del negocio y también pueden estar preocupados por el alcance / las consecuencias de cualquier violación de información que pueda haber tenido lugar como parte de una intrusión. Mantener a estas personas informadas ayudará a controlar su enojo y preocupación, tanto desde el punto de vista de que compartir el conocimiento es bueno, como desde el punto de vista quizás un poco menos obvio de que una cosa que necesitarán escuchar es que usted tiene el control de situación.

El servicio de asistencia y la gestión de TI deben actuar como un "paraguas" en este punto, protegiendo a las personas que realizan el trabajo para determinar el alcance de la intrusión y restaurar los servicios de innumerables consultas que interrumpen ese trabajo.

1. Pruebe y publique actualizaciones realistas para los clientes, y trabaje con ellos para determinar la urgencia de volver a poner un servicio en línea. Es importante estar al tanto de las necesidades de los clientes, pero al mismo tiempo no les permita dictar un horario inviable para usted.
2. Asegúrese de que su equipo de servicio de asistencia sepa qué información puede y no puede divulgarse, y que no debe alentar rumores y especulaciones (y absolutamente no debe discutir nada que pueda perjudicar cualquier acción legal que su organización pueda tomar o enfrentar).
3. Una cosa positiva que debe hacer el servicio de asistencia es registrar todas las llamadas relacionadas con la intrusión; esto puede ayudar a medir la interrupción causada tanto por la intrusión en sí como por los procesos que siguieron para tratarla. Poner un tiempo y un costo financiero en la intrusión y la mitigación puede ser muy útil tanto para refinar estrategias futuras, y obviamente podría resultar útil con cualquier acción legal. El registro de incidentes versus problemas de ITIL puede ayudar aquí: tanto la intrusión en sí como la mitigación se pueden registrar como problemas separados, y cada persona que realiza el seguimiento se rastrea como un incidente de uno o ambos problemas.

Cómo pueden ayudar los estándares de implementación

La implementación en una plantilla establecida (o al menos en una lista de verificación) también ayuda, junto con la práctica de control / gestión de cambios sobre cualquier personalización / actualización de su plantilla de implementación. Puede tener varias plantillas para dar cuenta de los servidores que realizan diferentes trabajos (por ejemplo, una plantilla de servidor de correo, una plantilla de servidor web, etc.).

Una plantilla debería funcionar tanto para el sistema operativo como para las aplicaciones, e incluir no solo la seguridad, sino también todas las configuraciones que utiliza, e idealmente debería tener una secuencia de comandos (por ejemplo, una plantilla) en lugar de aplicarse manualmente (por ejemplo, una lista de verificación) para eliminar el error humano tanto como sea posible.

Esto ayuda de varias maneras:

• Le permite restaurar / reconstruir más rápido en caso de que se produzca una intrusión (tenga en cuenta que no debe implementar desde esta plantilla 'tal cual' porque sabe que es vulnerable, pero le permite volver a su "última buena configuración conocida" " que necesita un mayor endurecimiento antes de la implementación en vivo ... y no olvide actualizar su plantilla de implementación una vez que esté seguro de que está bloqueada correctamente)
• Le ofrece una "línea de base" para comparar un servidor pirateado
• Reduce los errores innecesarios que pueden conducir a una intrusión en primer lugar
• Ayuda con la gestión de cambios y parches porque cuando se hace evidente que necesita un parche / actualización o un cambio de procedimiento por seguridad (o cualquier otra razón), es más fácil ver qué sistemas necesitan el cambio, facilita la escritura de pruebas. para ver si el cambio se aplica correctamente, etc.).
• Si todo es lo más coherente posible y sensible, ayuda a que los eventos inusuales y sospechosos sobresalgan un poco más.

Para la mayoría de nuestros servidores, dependemos de firewalls de host y de red, software antivirus / spyware, IDS de red e IDS de host para la mayoría de nuestra prevención. Esto, junto con todas las pautas generales, tales como privs mínimos, programas no esenciales desinstalados, actualizaciones, etc. A partir de ahí, usamos productos como Nagios, Cacti y una solución SIEM para varias líneas base y notificaciones de cuándo ocurren los eventos. Nuestro HIDS (OSSEC) también realiza muchos registros de tipo SIEM, lo cual es bueno. Básicamente, tratamos de bloquear todo lo posible, pero luego registramos centralmente para que, si algo sucede, podamos analizarlo y correlacionarlo.

Lo que realmente quieres puede dividirse en 3 áreas básicas:

1. Configuración estándar del sistema
2. Sistema / Monitoreo de aplicaciones
3. Respuesta al incidente

Si tiene algún personal de información (garantía | seguridad) disponible, entonces definitivamente debe hablar con ellos. Si bien la respuesta a incidentes es a menudo el único ámbito de dicha oficina, el resto debe ser un esfuerzo de desarrollo conjunto entre todas las partes afectadas.

A riesgo de auto-proxenetismo, esta respuesta a una pregunta relacionada debería indexar muchos recursos útiles para usted: Consejos para asegurar un servidor LAMP.

Idealmente, debe tener el menor número de sistemas operativos compatibles y construir cada uno utilizando una imagen base. Solo debe desviarse de la base tanto como sea necesario para proporcionar los servicios que proporciona el servidor. Las desviaciones deben documentarse o pueden ser necesarias si tiene que cumplir con PCI / HIPAA / etc. u otros cumplimientos. El uso de sistemas de gestión de implementación y configuración puede ayudar mucho a este respecto. Los detalles dependerán mucho de su sistema operativo, cobbler / puppet / Altiris / DeployStudio / SCCM, etc.

Definitivamente debe realizar algún tipo de revisión regular de registros. Dada la opción, un SIEM puede ser muy útil, pero también tienen el inconveniente de ser caros tanto en el precio de compra como en los costos de construcción. Consulte esta pregunta del sitio de IT Security SE para obtener algunos comentarios sobre el análisis de registros: ¿Cómo maneja el análisis de registros? Si esto sigue siendo demasiado pesado, incluso herramientas comunes como LogWatch pueden proporcionar un buen contexto para lo que está sucediendo. Sin embargo, la pieza importante es tomarse el tiempo para mirar los registros. Esto lo ayudará a familiarizarse con lo que constituye un comportamiento normal, para que pueda reconocer lo anormal.

Además de la revisión de registros, también es importante monitorear el estado del servidor. Saber cuándo ocurren los cambios, ya sea planificado o no, es crucial. El uso de una herramienta de monitoreo local como Tripwire puede alertar al administrador de los cambios. Desafortunadamente, al igual que los SIEM y los IDS tienen la desventaja de ser caros de ajustar y / o comprar. Además, sin una buena sintonización, sus umbrales de alerta serán tan altos que cualquier mensaje bueno se perderá en el ruido y se volverá inútil.

Una política adecuada de información de seguridad y gestión de eventos (SIEM) implementada contribuirá en gran medida a facilitar su vida de seguridad.

No soy un experto en seguridad, por lo que principalmente difiero a ellos; pero comenzar con el Principal of Least Privilege casi siempre hace que su trabajo sea mucho más fácil. Aplicar esto como un ungüento curativo funciona bien para muchos aspectos de la seguridad: permisos de archivos, usuarios de tiempo de ejecución, reglas de firewall, etc. KISS tampoco está de más.

La mayor parte de la solución mencionada aquí se aplica a nivel de host y de red, pero a menudo olvidamos las aplicaciones web inseguras. Las aplicaciones web son el agujero de seguridad más comúnmente pasado por alto. A modo de aplicación web, un atacante puede obtener acceso a su base de datos o host. Ningún firewall, IDS, firewall puede protegerlo contra ellos. OWASP mantiene una lista de las 10 vulnerabilidades más importantes y ofrece soluciones para ellas.

http://www.scribd.com/doc/19982/OWASP-Web-Security-Guide