Nistspecialpublication800 44ver2

Machine Translated by Google
Publicación especial 800-44

Versión 2
Directrices sobre protección pública

Servidores web
Recomendaciones del Instituto Nacional de

Estándares y Tecnología
millas tracy
Wayne Jansen
Karen Bufanda
Teodoro Winograd
Publicación especial NIST 800-44 Pautas para proteger la web pública

Versión 2 Servidores
Recomendaciones de la Nacional
Instituto de Estándares y Tecnología
Miles TracyWayne JansenKaren

Scarfone y Theodore Winograd
LA SEGURIDAD INFORMÁTICA
División de Seguridad Informática

Laboratorio de Tecnologías de la Información
Instituto Nacional de Normas y Tecnología
Gaithersburg, Maryland 20899-8930
septiembre de 2007
Departamento de Comercio de EE. UU.
Carlos M. Gutiérrez, Secretario
Instituto Nacional de Normas y Tecnología
James Turner, director interino

DIRECTRICES SOBRE LA PROTECCIÓN DE LOS SERVIDORES WEB PÚBLICOS
Informes sobre Tecnología de Sistemas Informáticos
El Laboratorio de Tecnología de la Información (ITL) del Instituto Nacional de Estándares y Tecnología (NIST)
promueve la economía y el bienestar público de los EE. UU. proporcionando liderazgo técnico para la infraestructura
de medición y estándares de la nación. ITL desarrolla pruebas, métodos de prueba, datos de referencia,
implementaciones de prueba de concepto y análisis técnico para avanzar en el desarrollo y el uso productivo de la
tecnología de la información. Las responsabilidades de ITL incluyen el desarrollo de normas y pautas técnicas,
físicas, administrativas y de gestión para la seguridad y privacidad rentables de la información confidencial no
clasificada en los sistemas informáticos federales. Esta serie de publicaciones especiales 800 informa sobre los
esfuerzos de investigación, orientación y divulgación de ITL en seguridad informática, y sus actividades de
colaboración con la industria, el gobierno y las organizaciones académicas.
Instituto Nacional de Estándares y Tecnología Publicación Especial 800-44 Versión 2 Natl.

Inst. Pararse. Tecnología Especificaciones. publ. 800-44 Ver. 2, 142 páginas (septiembre de 2007)
Ciertas entidades comerciales, equipos o materiales pueden identificarse en este

documento para describir adecuadamente un procedimiento o concepto experimental. Dicha
identificación no pretende implicar recomendación o respaldo por parte del Instituto Nacional
de Estándares y Tecnología, ni pretende implicar que las entidades, materiales o equipos son
necesariamente los mejores disponibles para el propósito.
yo
Agradecimientos, Versión 2
Los autores, Wayne Jansen y Karen Scarfone del NIST, Miles Tracy de Tecnología de la Información de la
Reserva Federal y Theodore Winograd de Booz Allen Hamilton, desean expresar su agradecimiento a los
colegas que revisaron los borradores de este documento. En particular, agradecen a Tim Grance, Bill Burr,
Patrick O'Reilly, Ray Perlner y Murugiah Souppaya del NIST, y a Jason Butterfield, Kwok Cheng y Jonathan
Holleran de Booz Allen Hamilton, por su investigación, apoyo técnico y contribuciones escritas a este
documento. Los autores también aprecian los esfuerzos de aquellas personas, agencias y otras organizaciones
que contribuyeron con sus comentarios durante el período de comentarios públicos.
Agradecimientos, Versión original
Los autores, Wayne Jansen del NIST y Miles Tracy y Mark McLarnon de Booz Allen Hamilton, desean expresar
su agradecimiento a los colegas de ambas organizaciones que revisaron los borradores de este documento.
En particular, agradecen a John Wack, Murugiah Souppaya y Tim Grance del NIST, y a Steve Allison, Scott
Bisker, Alexis Feringa, Kevin Kuhlkin y Jonathan Holleran de Booz Allen Hamilton por su investigación, apoyo
técnico y contribuciones escritas a este documento. Los autores también quisieran expresar su agradecimiento
a todos aquellos que contribuyeron con sus comentarios durante el período de comentarios públicos y que
ayudaron con nuestro proceso de revisión interna.
iii
Tabla de contenido
Resumen ejecutivo................................................ .................................................... ............ES-1
1. Introducción ............................................... .................................................... .....................1-1
1.1 Autoridad .................................................. .................................................... ...........1-1 1.2

Propósito y alcance .......................... .................................................... .....................1-1 1.3 Audiencia
y suposiciones ...................... .................................................... .............1-2 1.4 Estructura del
documento ............................... .................................................... ..........1-2
2. Fondo ............................................... .................................................... .....................2-1
3. Planificación y administración de servidores web ........................................... ..........................3-1

3.1 Planificación de la instalación y el despliegue ........................................... .......................3-1 3.2
Personal de gestión de seguridad .................. .................................................... ...........3-3 3.2.1
Gerente sénior de TI/Director de información ............... ..................3-4 3.2.2 Administradores
del programa de seguridad de los sistemas de información .................. ......................3-4 3.2.3
Oficiales de seguridad de los sistemas de información .................. .......................................3-4
3.2.4 Administradores de red y servidores web .................................................... ...3-5 3.2.5
Desarrolladores de aplicaciones web .................................. ..................................3-5 3.3
Prácticas de gestión .......... .................................................... ..........................3-6 3.4 Plan de seguridad
del sistema ........... .................................................... ..........................3-7 3.5 Recursos humanos
Requisitos de ces................................................. ............................3-8 3.6 Plataformas alternativas de
servidores web .................. .................................................... ............3-9 3.6.1 Sistemas operativos de
confianza ........................... .............................................3-9 3.6. 2 Dispositivos de servidor
web ............................................... ..........................3-10 3.6.3 Sistemas operativos y servidores
web reforzados previamente.... .............................3-11 3.6.4 Plataformas
virtualizadas .................. .................................................... ....................3-12 3.7 Lista de
verificación para la planificación y administración de servidores web .................. ............................3-13
4. Protección del sistema operativo del servidor web........................................... .......................4-1
4.1 Instalación y configuración del sistema operativo ........................................... ..........4-1 4.1.1
Parchear y actualizar el sistema operativo ........................... ..........................4-1 4.1.2 Quitar o
deshabilitar aplicaciones y servicios innecesarios ......... ..............4-2 4.1.3 Configurar la
autenticación de usuario del sistema operativo .................. ...............4-4 4.1.4 Configurar los
controles de recursos de forma adecuada .................. ..........................4-6 4.1.5 Instalar y
configurar controles de seguridad adicionales ............... .......................4-6 4.2 Pruebas de
seguridad del sistema operativo .................. .................................................... .4-7 4.3 Lista de
verificación para asegurar el sistema operativo del servidor web .................................. .4-7
5. Protección del servidor web................................................ .................................................... ...5-1
5.1 Instalación segura del servidor web ............................................... ..............................5-1 5.2
Configuración de controles de acceso .................. .................................................... .....................5-2
5.2.1 Configuración de los permisos de la aplicación del servidor web .................. .........5-3
5.2.2 Configuración del directorio de contenido web seguro .................. ....................5-4 5.2.3
Identificadores uniformes de recursos y cookies .................. ..............................5-5 5.2.4 Control
del impacto de los "bots" web en los servidores web... ..................................5-6 5.3 Lista de
verificación para asegurar el servidor web.... .................................................... ..............5-9
IV
6. Protección del contenido web .............................................. .................................................... ......6-1

6.1 Publicación de información en sitios web públicos ........................................... ...........6-1 6.2
Cumplimiento de las Normas sobre la Recopilación de Datos Personales .................. .6-3 6.3
Mitigación de ataques indirectos al contenido .................................. .............................6-5 6.3.1
Suplantación de identidad ............... .................................................... ...................................6-5
6.3.2 Farmacia ... .................................................... ..................................................6 -7 6.4
Asegurar el contenido activo y las tecnologías de generación de contenido...................6-8 6.4.1
Vulnerabilidades con el lado del cliente Tecnologías de contenido activo ........... 6-10 6.4.2
Vulnerabilidades con tecnologías de generación de contenido del lado del servidor .... 6- 12
6.4.3 Consideraciones de seguridad del generador de contenido del lado del servidor ..... 6-15
6.4.4 Ubicación del contenido del lado del servidor Generadores .................... ..........................6-17
6.4.5 Vulnerabilidades de secuencias de comandos entre
sitios ............... .............................................6-17 6.5 Lista de verificación para asegurar el contenido web .................
7. Uso de tecnologías de autenticación y cifrado.................................................. .........7-1
7.1 Determinación de los requisitos de autenticación y cifrado .................................7-1 7.2 Basado
en direcciones Autenticación................................................. ..........................7-1 7.3 Autenticación
básica ............ .................................................... ..........................7-2 7.4 Autenticación
implícita .......... .................................................... ...................................7-2 7.5 SSL/
TLS........ .................................................... .................................................... .......7-3 7.5.1
Capacidades SSL/TLS .................................. .................................................... .7-3 7.5.2
Debilidades de SSL/TLS.................................... ..........................................7-4 7.5.3 Ejemplo
de SSL/TLS Sesión ................................................. ...............7-5 7.5.4 Esquemas de cifrado
SSL/TLS .............. ......................... .............................7-6 7.5.5 Implementación de SSL/
TLS .......... .................................................... .....................7-8 7.5.6 Implementaciones de
SSL/TLS .................. .................................................... .....7-12 7.6 Ataques de fuerza
bruta ...................................... .................................................... .......7-12 7.7 Lista de verificación
para el uso de tecnologías de autenticación y cifrado para servidores web 7-14
8. Implementación de una infraestructura de red segura ........................................... ..............8-1
8.1 Composición y estructura de la red ............................................... ..........................8-1 8.1.1
Diseño de red desaconsejado .............. .................................................... ...........8-1 8.1.2
Zona Desmilitarizada.................................. .................................................... .....8-1 8.1.3
Alojamiento subcontratado.................................... ..........................................................8 -4
8.1.4 Red de gestión .................................................. .......................................8-5 8.2
Configuración de elementos de red ..... .................................................... ....................... 8-5 8.2.1
Configuración del enrutador/cortafuegos ............... .................................................... ......8-5
8.2.2 Sistemas de detección y prevención de intrusos .................................. ...............8-9
8.2.3 Conmutadores de red........................... .................................................... ........ ..8-11
8.2.4 Equilibradores de carga......................................... ....................................................
.8-12 8.2.5 Proxies inversos ............................................... ..........................................8- 12
8.3 Lista de verificación para implementar una infraestructura de red segura...........................8-13
9. Administrar el servidor web................................................ .............................................9-1
9.1 Registro .................................................. .................................................... ...........9-1 9.1.1
Identificación de las capacidades de registro de un servidor web .................. ...........9-1 9.1.2
Identificación de requisitos de registro adicionales .................. ..........................9-3 9.1.3
Configuración de registro genérica recomendada .................. ..........................9-3 9.1.4
Revisión y conservación de archivos de registro ............ .................................................... 9-3
9.1.5 Herramientas de análisis de archivos de registro automatizados .................. .......................9-5
en
9.2 Procedimientos de copia de seguridad del servidor web ............................... ..........................9-5 9.2.1
Políticas y estrategias de copia de seguridad del servidor web ..... ..........................................9-5 9.2.2
Mantener un servidor web de prueba .............................................. ..........................9-7 9.2.3 Mantener
una copia autorizada del contenido web de la organización ......... ...........9-8 9.3 Recuperación de un
compromiso de seguridad .................................. ...........................9-9 9.4 Pruebas de seguridad de los
servidores web ........... .................................................... ...........9-11 9.4.1 Exploración de
vulnerabilidades .................. .................................................... ......9-11 9.4.2 Prueba de
penetración .................................. ..........................................9- 12 9.5 Administración remota de un
servidor web........................................... .......................9-13 9.6 Lista de verificación para el administrador
Registro del servidor web .............................................. .............9-14
Apéndices
Apéndice A— Recursos de seguridad del servidor web en línea.................................. ............. A-1
Apéndice B— Glosario .............................................. .................................................... ..........B-1
Apéndice C— Herramientas y aplicaciones de seguridad web .................................. ............. C-1
Apéndice D— Referencias .............................................. .................................................... ...... D-1
Apéndice E—Lista de control de seguridad del servidor web.................................. .......................... E-1
Apéndice F—Lista de siglas.................................................. .................................................... .... F-1
Apéndice G— Índice .................................................. .................................................... ................G-1
Lista de tablas y figuras
Figura 7-1. Ubicación de SSL/TLS dentro de la pila de protocolos de Internet .................................. ....7-3 Tabla 7-1.
Paquetes de cifrado SSL/TLS.................................................... .......................................................7-7 Figura 7-2.
Ejemplo de CSR ................................................. .................................................... .........7-9
Figura 7-3. Ejemplo de certificado SSL/TLS codificado.................................................. ......................7-10 Figura 8-1.
DMZ simple de un solo cortafuegos ............................................... ..........................................8-2 Figura 8-2. DMZ de
dos cortafuegos ............................................... .................................................... ..8-2
Figura 8-3. Pierna de servicio DMZ.................................................... .................................................... ...8-3 Figura
8-4. Hospedaje de servidor web subcontratado ............................................... .............................8-4
nosotros
Resumen ejecutivo
La World Wide Web (WWW) es un sistema de intercambio de información a través de Internet. En el nivel más básico, la web se
puede dividir en dos componentes principales: servidores web, que son aplicaciones que hacen que la información esté disponible en
Internet (en esencia, publican información), y navegadores web (clientes), que se utilizan para acceder y mostrar la información
almacenada en los servidores Web. Este documento se centra en los problemas de seguridad de los servidores web.1
Desafortunadamente, los servidores web suelen ser los hosts más atacados y atacados en las redes de las organizaciones.
Como resultado, es esencial proteger los servidores web y la infraestructura de red que los respalda. Los siguientes son ejemplos de
amenazas de seguridad específicas para los servidores web:
Las entidades malintencionadas pueden explotar errores de software en el servidor web, el sistema operativo subyacente o
el contenido activo para obtener acceso no autorizado al servidor web. Los ejemplos de este acceso no autorizado incluyen
obtener acceso a archivos o carpetas que no estaban destinados a ser de acceso público (por ejemplo, ataques de cruce de
directorios) y poder ejecutar comandos y/o instalar software en el servidor web.
Los ataques de denegación de servicio (DoS) pueden estar dirigidos al servidor web o su infraestructura de red de
soporte, negando o dificultando que los usuarios válidos hagan uso de sus servicios.
La información confidencial en el servidor web puede leerse o modificarse sin autorización.
La información confidencial en las bases de datos de back-end que se utilizan para respaldar los elementos interactivos de una
aplicación web puede verse comprometida a través de ataques de inyección de comandos (por ejemplo, inyección de lenguaje
de consulta estructurado [SQL], inyección de protocolo ligero de acceso a directorios (LDAP), secuencias de comandos entre
sitios [XSS] ).
La información confidencial transmitida sin cifrar entre el servidor web y el navegador puede ser interceptada.
La información en el servidor web puede cambiarse con fines maliciosos. La desfiguración del sitio web es un ejemplo común
de esta amenaza.
Las entidades malintencionadas pueden obtener acceso no autorizado a los recursos en cualquier otro lugar de la red de la
organización a través de un ataque exitoso al servidor web.
Las entidades malintencionadas pueden atacar entidades externas después de comprometer el host de un servidor web. Estos
ataques pueden lanzarse directamente (p. ej., desde el host comprometido contra un servidor externo) o indirectamente (p. ej.,
colocando contenido malicioso en el servidor web comprometido que intenta explotar vulnerabilidades en los navegadores web de
los usuarios que visitan el sitio).
El servidor puede usarse como un punto de distribución para herramientas de ataque, pornografía o software copiado
ilegalmente.
Los servidores web también pueden enfrentar ataques indirectos para obtener información de sus usuarios. En estos ataques, el usuario
es persuadido o dirigido automáticamente a visitar un sitio web malicioso que parece ser legítimo. La información de identificación que
se recopila puede usarse para acceder al sitio web en sí o formar la base para
1
Para obtener más información sobre cómo proteger los navegadores web, consulte la Publicación especial 800-46 del NIST, Seguridad para el
teletrabajo y las comunicaciones de banda ancha (http://csrc.nist.gov/publications/nistpubs/).
ES-1
el robo de identidad. Los ataques exitosos pueden comprometer los recursos confidenciales del sitio web o dañar la imagen de
una organización. Estos ataques indirectos se producen de dos formas:
Phishing, donde los atacantes utilizan la ingeniería social para engañar a los usuarios para que inicien sesión en un sitio falso
Pharming, donde los servidores del sistema de nombres de dominio (DNS) o los archivos host de los usuarios se ven comprometidos
para redirigir a los usuarios a un sitio malicioso en lugar del sitio legítimo.
Este documento está destinado a ayudar a las organizaciones a instalar, configurar y mantener servidores web públicos seguros. Más
específicamente, este documento describe, en detalle, las siguientes prácticas a aplicar:
Protección, instalación y configuración del sistema operativo subyacente
Protección, instalación y configuración del software del servidor web
Implementación de mecanismos de protección de red apropiados, como firewalls, enrutadores, conmutadores y sistemas de detección
y prevención de intrusiones
Mantener la configuración segura mediante la aplicación de parches y actualizaciones apropiados, pruebas de seguridad, monitoreo
de registros y copias de seguridad de datos y archivos del sistema operativo.
Usar, publicar y proteger la información y los datos de manera cuidadosa y sistemática.
Se recomiendan las siguientes pautas clave a los departamentos y agencias federales para mantener una presencia web segura.
Las organizaciones deben planificar y abordar cuidadosamente los aspectos de seguridad de la implementación de un servidor web
público.
Debido a que es mucho más difícil abordar la seguridad una vez que se ha realizado el despliegue y la implementación, la seguridad debe
considerarse desde la etapa de planificación inicial. Es más probable que las organizaciones tomen decisiones sobre la configuración adecuada y
consistente de las computadoras cuando desarrollan y utilizan un plan de implementación detallado y bien diseñado. El desarrollo de dicho plan
ayudará a los administradores de servidores web a tomar las inevitables decisiones de compensación entre usabilidad, rendimiento y riesgo.
Las organizaciones a menudo no tienen en cuenta los requisitos de recursos humanos tanto para la implementación como para las
fases operativas del servidor web y la infraestructura de soporte. Las organizaciones deben abordar los siguientes puntos en un plan de
implementación:
Tipos de personal requerido (por ejemplo, administradores de sistemas y servidores web, webmasters, administradores de redes,
oficiales de seguridad de sistemas de información [ISSO])
Habilidades y entrenamiento requerido por el personal asignado
Requerimientos individuales (es decir, nivel de esfuerzo requerido de tipos de personal específicos) y colectivos (es decir, nivel
general de esfuerzo).
Las organizaciones deben implementar prácticas y controles de gestión de seguridad apropiados al mantener y operar un servidor
web seguro.
Las prácticas de administración adecuadas son esenciales para operar y mantener un servidor web seguro.
Las prácticas de seguridad implican la identificación de los activos del sistema de información de una organización y la
ES-2
desarrollo, documentación e implementación de políticas, estándares, procedimientos y lineamientos que ayuden a asegurar la
confidencialidad, integridad y disponibilidad de los recursos del sistema de información. Para garantizar la seguridad de un servidor web y
la infraestructura de red de soporte, se deben implementar las siguientes prácticas:
Política de seguridad del sistema de información de toda la organización
Gestión y control de cambios/configuración
Evaluación y gestión de riesgos
Configuraciones de software estandarizadas que satisfacen la política de seguridad del sistema de información
Concienciación y formación en seguridad.
Planificación de contingencia, continuidad de operaciones y planificación de recuperación ante desastres
Certificación y acreditación.
Las organizaciones deben asegurarse de que los sistemas operativos del servidor web se implementen, configuren y
administren para cumplir con los requisitos de seguridad de la organización.
El primer paso para proteger un servidor web es proteger el sistema operativo subyacente. Los servidores web más comúnmente
disponibles operan en un sistema operativo de propósito general. Se pueden evitar muchos problemas de seguridad si los sistemas
operativos subyacentes a los servidores web se configuran adecuadamente. Los fabricantes suelen establecer configuraciones
predeterminadas de hardware y software para enfatizar características, funciones y facilidad de uso, a expensas de la seguridad. Debido a
que los fabricantes no conocen las necesidades de seguridad de cada organización, cada administrador de servidor web debe configurar
nuevos servidores para reflejar los requisitos de seguridad de su organización y reconfigurarlos a medida que esos requisitos cambian. El
uso de guías de configuración de seguridad o listas de verificación puede ayudar a los administradores a proteger los sistemas de manera
consistente y eficiente. Asegurar un sistema operativo inicialmente generalmente incluiría los siguientes pasos:
Parchear y actualizar el sistema operativo
Eliminar o deshabilitar servicios y aplicaciones innecesarios
Configurar la autenticación de usuario del sistema operativo
Configurar controles de recursos
Instalar y configurar controles de seguridad adicionales
Realizar pruebas de seguridad del sistema operativo.
Las organizaciones deben asegurarse de que la aplicación del servidor web se implemente, configure y administre para cumplir
con los requisitos de seguridad de la organización.
En muchos aspectos, la instalación y configuración seguras de la aplicación del servidor web reflejarán el proceso del sistema operativo
mencionado anteriormente. El principio general es instalar la cantidad mínima de servicios de servidor web necesarios y eliminar cualquier
vulnerabilidad conocida mediante parches o actualizaciones. Si el programa de instalación instala aplicaciones, servicios o scripts
innecesarios, deben eliminarse
ES-3
inmediatamente después de que concluya el proceso de instalación. La protección de la aplicación del servidor web generalmente
incluiría los siguientes pasos:
Aplicar parches y actualizar la aplicación del servidor web
Eliminar o deshabilitar servicios, aplicaciones y contenido de muestra innecesarios
Configurar la autenticación de usuarios del servidor web y los controles de acceso
Configurar controles de recursos del servidor web
Pruebe la seguridad de la aplicación del servidor web y el contenido web.
Las organizaciones deben tomar medidas para garantizar que solo se publique contenido apropiado en un sitio web.
Muchas agencias carecen de un proceso o política de publicación web que determine qué tipo de información publicar abiertamente,
qué información publicar con acceso restringido y qué información no debe publicarse en ningún depósito de acceso público. Esto es
lamentable porque los sitios web suelen ser uno de los primeros lugares en los que las entidades malintencionadas buscan información
valiosa. Algunos ejemplos generalmente aceptados de lo que no debe publicarse o al menos debe examinarse y revisarse cuidadosamente
antes de la publicación en un sitio web público incluyen:
Información clasificada o propietaria
Información sobre la composición o preparación de materiales peligrosos o toxinas2
Información confidencial relacionada con la seguridad nacional
Registros médicos
Las salvaguardas detalladas de seguridad física y de la información de una organización.
Detalles sobre la red de una organización y la infraestructura del sistema de información (p. ej., rangos de direcciones, convenciones
de nomenclatura, números de acceso)
Información que especifica o implica vulnerabilidades de seguridad física
Planos detallados, mapas, diagramas, fotografías aéreas y dibujos arquitectónicos de edificios, propiedades o instalaciones
organizacionales
Cualquier información confidencial sobre personas, como información de identificación personal (PII), que podría estar sujeta a
leyes de privacidad federales, estatales o, en algunos casos, internacionales.3
Las organizaciones deben asegurarse de que se toman las medidas adecuadas para proteger el contenido web
del acceso o la modificación no autorizados.
2
Para obtener más orientación sobre la protección de este tipo de información, consulte el Memorando de la Casa Blanca del 19 de marzo de
2000, Acción para salvaguardar la información sobre armas de destrucción masiva y otros documentos confidenciales relacionados con la
seguridad nacional (http://www.usdoj.gov/oip /foiapost/2002foiapost10.htm).
3
Para obtener más orientación sobre la protección de este tipo de información, consulte el Memorando OMB M-06-16 y el Memorando OMB M-07-
16 en http://www.whitehouse.gov/omb/memoranda/.
ES-4
Aunque la información en los sitios web públicos es contenido destinado a ser público, suponiendo que exista un proceso de revisión y
una política creíbles, aún es importante asegurarse de que la información no se pueda modificar sin autorización. Los usuarios de esta
información confían en la integridad de dicha información incluso si la información no es confidencial. Debido a la accesibilidad pública, el
contenido de los servidores web de acceso público es inherentemente más vulnerable que la información a la que no se puede acceder
desde Internet. Esta vulnerabilidad significa que las organizaciones deben proteger el contenido web público mediante la configuración
adecuada de los controles de recursos del servidor web. Ejemplos de prácticas de control de recursos incluyen—
Instale o habilite solo los servicios necesarios.
Instale contenido web en un disco duro dedicado o una partición lógica.
Limite las cargas a directorios que el servidor web no puede leer.
Defina un único directorio para todos los scripts o programas externos ejecutados como parte del contenido web.
Deshabilite el uso de enlaces duros o simbólicos.
Defina una matriz completa de acceso al contenido web que identifique qué carpetas y archivos dentro del directorio de documentos
del servidor web están restringidos y cuáles son accesibles (y por quién).
Deshabilitar listados de directorios.
Use autenticación de usuario, firmas digitales y otros mecanismos criptográficos según corresponda.
Utilice sistemas de detección de intrusiones (IDS) basados en host, sistemas de prevención de intrusiones (IPS) y/o verificadores
de integridad de archivos para detectar intrusiones y verificar el contenido web.
Proteja cada servidor backend (p. ej., servidor de base de datos, servidor de directorio) de ataques de inyección de comandos tanto en
el servidor web como en el servidor backend.
Las organizaciones deben utilizar el contenido activo con prudencia después de sopesar los beneficios obtenidos frente a los
riesgos asociados.
La mayoría de los primeros sitios web presentaban información estática que residía en el servidor, generalmente en forma de documentos
basados en texto. Poco después, se introdujeron elementos interactivos para ofrecer a los usuarios nuevas formas de interactuar con
un sitio web. Desafortunadamente, estos mismos elementos interactivos introdujeron nuevas vulnerabilidades relacionadas con la web
porque implican la ejecución dinámica de código en el servidor web o en el cliente utilizando una gran cantidad de entradas, desde parámetros
del Localizador de recursos universales (URL) hasta el contenido POST del Protocolo de transferencia de hipertexto (HTTP) y , más
recientemente, contenido de lenguaje de marcado extensible (XML) en forma de mensajes de servicios web. Las diferentes tecnologías de
contenido activo tienen diferentes vulnerabilidades asociadas, y sus riesgos deben sopesarse frente a sus beneficios. Aunque la mayoría de
los sitios web utilizan algún tipo de generadores de contenido activo, muchos también entregan parte o la totalidad de su contenido en forma
no activa.
Las organizaciones deben usar tecnologías criptográficas y de autenticación según corresponda para proteger ciertos tipos de
datos confidenciales.
Los servidores web públicos a menudo admiten una variedad de tecnologías para identificar y autenticar a los usuarios con diferentes
privilegios para acceder a la información. Algunas de estas tecnologías se basan en funciones criptográficas que pueden proporcionar un
canal cifrado entre un cliente de navegador web y un servidor web que
ES-5
admite cifrado. Los servidores web pueden configurarse para utilizar diferentes algoritmos criptográficos, lo que proporciona distintos niveles de
seguridad y rendimiento.
Sin una autenticación de usuario adecuada, las organizaciones no pueden restringir selectivamente el acceso a información específica.
Cualquier persona con acceso al servidor puede acceder a toda la información que reside en un servidor web público. Además, sin algún proceso
para autenticar el servidor, los usuarios del servidor web público no podrán determinar si el servidor es el servidor web "auténtico" o una versión
falsificada operada por una entidad maliciosa.
Incluso con un canal cifrado y un mecanismo de autenticación, es posible que los atacantes intenten acceder al sitio mediante un ataque
de fuerza bruta. Las técnicas de autenticación incorrectas pueden permitir a los atacantes recopilar nombres de usuario válidos o potencialmente
obtener acceso al sitio web. Los sólidos mecanismos de autenticación también pueden proteger contra ataques de phishing y pharming. Por lo
tanto, se debe implementar un nivel adecuado de autenticación en función de la sensibilidad de los usuarios y el contenido del servidor web.
Las organizaciones deben emplear su infraestructura de red para ayudar a proteger sus servidores web públicos.
La infraestructura de red (por ejemplo, cortafuegos, enrutadores, IDS) que admite el servidor web desempeña un papel fundamental en la seguridad
del servidor web. En la mayoría de las configuraciones, la infraestructura de red será la primera línea de defensa entre un servidor web público e
Internet. Sin embargo, el diseño de la red por sí solo no puede proteger un servidor web. La frecuencia, la sofisticación y la variedad de los ataques
a servidores web perpetrados hoy respaldan la idea de que la seguridad de los servidores web debe implementarse a través de diversos mecanismos
de protección en capas (es decir, defensa en profundidad).
Las organizaciones deben comprometerse con el proceso continuo de mantener la seguridad de los servidores web públicos para
garantizar la seguridad continua.
Mantener un servidor web seguro requiere esfuerzo, recursos y vigilancia constantes por parte de una organización.
La administración segura de un servidor web a diario es un aspecto esencial de la seguridad del servidor web.
El mantenimiento de la seguridad de un servidor web generalmente implicará los siguientes pasos:
Configuración, protección y análisis de archivos de registro
Copia de seguridad de la información crítica con frecuencia
Mantener una copia autorizada protegida del contenido web de la organización
Establecer y seguir procedimientos para recuperarse de compromisos
Probar y aplicar parches de manera oportuna
Pruebas de seguridad periódicamente.
ES-6
1. Introducción
1.1 Autoridad
El Instituto Nacional de Estándares y Tecnología (NIST) desarrolló este documento en cumplimiento de sus responsabilidades estatutarias
bajo la Ley Federal de Administración de Seguridad de la Información (FISMA) de 2002, Ley Pública 107-347.
NIST es responsable de desarrollar estándares y pautas, incluidos los requisitos mínimos, para proporcionar seguridad de
información adecuada para todas las operaciones y activos de la agencia; pero dichas normas y directrices no se aplicarán a los
sistemas de seguridad nacional. Esta pauta es consistente con los requisitos de la Circular A-130 de la Oficina de Administración y
Presupuesto (OMB), Sección 8b(3), “Sistemas de información de la agencia de seguridad”, como se analiza en A-130, Apéndice IV:
Análisis de secciones clave. Se proporciona información complementaria en A-130, Apéndice III.
Esta guía ha sido preparada para uso de las agencias federales. Puede ser utilizado por organizaciones no gubernamentales de
forma voluntaria y no está sujeto a derechos de autor, aunque se desea la atribución.
Nada de lo contenido en este documento debe tomarse en contradicción con las normas y pautas que el Secretario de Comercio hizo
obligatorias y vinculantes para las agencias federales en virtud de la autoridad legal, ni estas pautas deben interpretarse como que
alteran o reemplazan las autoridades existentes del Secretario de Comercio, el Director de la OMB, o cualquier otro funcionario federal.
1.2 Propósito y alcance
El propósito de las Directrices sobre la protección de servidores web públicos es recomendar prácticas de seguridad para diseñar,
implementar y operar servidores web de acceso público, incluidos los problemas de infraestructura de red relacionados. Es posible
que algunas organizaciones federales deban ir más allá de estas recomendaciones o adaptarlas de otras maneras para cumplir con
sus requisitos únicos. Si bien está diseñado como recomendaciones para los departamentos y agencias federales, puede usarse en
el sector privado de forma voluntaria.
Este documento puede ser utilizado por organizaciones interesadas en mejorar la seguridad en los sistemas de servidores web existentes
y futuros para reducir el número y la frecuencia de los incidentes de seguridad relacionados con la web. Este documento presenta
principios genéricos que se aplican a todos los sistemas.
Esta guía no cubre los siguientes aspectos relacionados con la seguridad de un servidor web:
Protección de otros tipos de servidores de red
Cortafuegos y enrutadores utilizados para proteger servidores web más allá de una discusión básica en la Sección 8
Consideraciones de seguridad relacionadas con el software del cliente web (navegador)4
Consideraciones especiales para sitios web de alto tráfico con múltiples hosts5
Protección de servidores back-end que pueden admitir el servidor web (p. ej., servidores de bases de datos, servidores de archivos)
4
Para obtener más información sobre cómo proteger los navegadores web, consulte la Publicación especial (SP) 800-46 del NIST, Seguridad para
el teletrabajo y las comunicaciones de banda ancha (http://csrc.nist.gov/publications/nistpubs/).
5
Aunque este documento no aborda las preocupaciones de seguridad específicas que surgen de las granjas web de múltiples servidores de alto
tráfico, gran parte de lo que se cubre se aplicará a este tipo de instalaciones.
1-1
Servicios distintos del Protocolo de transferencia de hipertexto (HTTP) y el Protocolo de transferencia de hipertexto seguro
(HTTPS)
Servicios web estilo SOAP6
Protección de la propiedad intelectual.
1.3 Audiencia y suposiciones
Este documento, si bien es de naturaleza técnica, proporciona información básica para ayudar a los lectores a comprender los temas que se
tratan. La audiencia prevista para este documento incluye lo siguiente:
Ingenieros y arquitectos de sistemas, al diseñar e implementar servidores web
Administradores web y de sistemas, al administrar, aplicar parches, asegurar o actualizar servidores web
Webmasters, a la hora de crear y gestionar contenidos web
Consultores de seguridad, al realizar auditorías de seguridad para determinar las posturas de seguridad del sistema de información
(IS)
Gerentes de programa y oficiales de seguridad de tecnología de la información (TI), para garantizar que se hayan considerado las
medidas de seguridad adecuadas para todas las fases del ciclo de vida del sistema.
Este documento asume que los lectores tienen una experiencia mínima en sistemas operativos, redes y servidores web. Debido a la
naturaleza en constante cambio de las amenazas y vulnerabilidades del servidor web, se espera que los lectores aprovechen otros
recursos (incluidos los que se enumeran en este documento) para obtener información más actualizada y detallada.
Las prácticas recomendadas en este documento están diseñadas para ayudar a mitigar los riesgos asociados con los servidores web. Se
basan y asumen la implementación de prácticas descritas en otras pautas del NIST enumeradas en el Apéndice E.
1.4 Estructura del documento
El resto de este documento está organizado en las siguientes ocho secciones principales:
La sección 2 analiza los problemas de seguridad del servidor web y presenta una descripción general.
La sección 3 trata sobre la planificación y gestión de servidores web.
La sección 4 presenta una descripción general de la protección del sistema operativo subyacente para un servidor web.
La Sección 5 trata sobre la instalación y configuración seguras de un servidor web.
La sección 6 examina la seguridad del contenido web.
La sección 7 examina las tecnologías populares de autenticación y encriptación web.
6
NIST SP 800-95, Guía de servicios web seguros, brinda información sobre los riesgos que presentan los servicios web y
cómo mitigarlos (http://csrc.nist.gov/publications/nistpubs/).
1-2
La Sección 8 analiza la protección de un servidor web a través de la infraestructura de red de soporte.
La Sección 9 analiza los aspectos básicos de la administración segura de un servidor web a diario.
El documento también contiene varios apéndices con material de apoyo.
El Apéndice A proporciona una variedad de recursos de seguridad web en línea.
El Apéndice B define los términos utilizados en este documento.
El Apéndice C proporciona una lista de las herramientas y aplicaciones de seguridad del servidor web más utilizadas.
El Apéndice D enumera las referencias utilizadas en este documento.
El Apéndice E proporciona una lista de verificación de seguridad del servidor web.
El Apéndice F contiene una lista de siglas.
El Apéndice G contiene un índice de la publicación.
1-3
2. Fondo
La World Wide Web es una de las formas más importantes para que una organización publique información, interactúe
con los usuarios de Internet y establezca una presencia de comercio electrónico/gobierno electrónico. Sin embargo, si
una organización no es rigurosa en la configuración y operación de su sitio web público, puede ser vulnerable a una
variedad de amenazas de seguridad. Aunque las amenazas en el ciberespacio siguen siendo en gran medida las mismas que
en el mundo físico (p. ej., fraude, robo, vandalismo y terrorismo), son mucho más peligrosas como resultado de tres desarrollos
importantes: mayor eficiencia, acción a distancia y rapidez. propagación de la técnica [Schn00].
Mayor eficiencia: la automatización hace que los ataques, incluso aquellos con mínima oportunidad de éxito, sean
eficientes y extremadamente rentables. Por ejemplo, en el mundo físico, un ataque que tendría éxito una vez cada 10.000
intentos sería ineficaz debido al tiempo y esfuerzo necesarios, en promedio, para un único éxito. El tiempo invertido en
lograr un solo éxito sería superado por el tiempo invertido en los 9.999 fracasos. En Internet, la automatización permite
que el mismo ataque sea un éxito sorprendente. El poder de cómputo y el ancho de banda son cada día menos costosos,
mientras que la cantidad de hosts a los que se puede apuntar crece rápidamente. Esta sinergia significa que casi cualquier
ataque, sin importar cuán baja sea su tasa de éxito, probablemente encontrará muchos sistemas para explotar.
Acción a distancia: Internet permite la acción a distancia. Internet no tiene fronteras, y cada punto de Internet es
potencialmente accesible desde cualquier otro punto. Esto significa que un atacante en un país puede apuntar a un
sitio web remoto en otro país con la misma facilidad que a uno cercano.
Propagación rápida de técnicas: Internet permite una propagación de técnicas más fácil y rápida. Antes de
Internet, se desarrollaron técnicas de ataque que tardarían años en propagarse, si es que alguna vez lo hacían, dando
tiempo para desarrollar contramedidas efectivas. Hoy en día, una nueva técnica puede propagarse en cuestión de horas o
días. Ahora es más difícil desarrollar contramedidas efectivas de manera oportuna.
Los sitios web comprometidos han servido como punto de entrada para intrusiones en las redes internas de muchas
organizaciones. Las organizaciones pueden enfrentar pérdidas monetarias, daños a la reputación o acciones legales si un
intruso viola con éxito la confidencialidad de sus datos. Los ataques de denegación de servicio (DoS) pueden dificultar, si
no imposibilitar, que los usuarios accedan al sitio web de una organización.7 Estos ataques pueden costarle mucho tiempo
y dinero a la organización. Los ataques DoS son fáciles de intentar para los atacantes debido a la cantidad de posibles
vectores de ataque, la variedad de herramientas automatizadas disponibles y el bajo nivel de habilidad necesario para usar las
herramientas. Los ataques DoS, así como las amenazas de iniciar ataques DoS, también se utilizan cada vez más para
chantajear a las organizaciones. Además, una organización puede encontrarse en una situación embarazosa debido a que
intrusos maliciosos cambian el contenido de las páginas web de la organización.
Kossakowski y Allen identificaron tres problemas principales de seguridad relacionados con el funcionamiento de un
sitio web de acceso público [Koss00]:
Configuración incorrecta u otra operación incorrecta del servidor web, que puede resultar, por ejemplo, en la divulgación
o alteración de información privada o confidencial. Esta información puede incluir elementos como los siguientes:
7
Muchos ataques DoS son el resultado de botnets, un grupo de computadoras con un programa instalado de forma subrepticia para provocar que
ataquen otros sistemas. Las redes de bots a menudo se componen principalmente de computadoras domésticas mal protegidas que tienen conectividad
a Internet de alta velocidad. Las botnets se pueden utilizar para realizar ataques de denegación de servicio distribuido (DDoS), que son mucho más
difíciles de defender debido a la gran cantidad de hosts atacantes.
2-1
Activos de la organización
Configuración del servidor o red que podría ser explotado para ataques posteriores
Información sobre los usuarios o administrador(es) del servidor Web, incluidas sus contraseñas.
Vulnerabilidades dentro del servidor web que podrían permitir, por ejemplo, que los atacantes comprometan la seguridad del
servidor y otros hosts en la red de la organización al tomar acciones como las siguientes:
Desfigurar el sitio web o afectar de otro modo la integridad de la información
Ejecutar comandos o programas no autorizados en el sistema operativo host, incluidos los que ha instalado el intruso
Obtener acceso no autorizado a recursos en otras partes de la red informática de la organización
Lanzar ataques a sitios externos desde el servidor web, ocultando así las identidades de los intrusos y quizás responsabilizando
a la organización por los daños.
Usar el servidor como un punto de distribución para software copiado ilegalmente, herramientas de ataque o pornografía, lo
que quizás haga que la organización sea responsable de los daños.
Usar el servidor para lanzar ataques contra clientes web vulnerables para comprometerlos.
Mecanismos de defensa inadecuados o no disponibles para el servidor web para evitar ciertas clases de ataques, como
ataques DoS, que interrumpen la disponibilidad del servidor web e impiden que los usuarios autorizados accedan al sitio web
cuando sea necesario.
En los últimos años, a medida que ha mejorado la seguridad de las redes y las instalaciones de servidores, las aplicaciones
de software mal escritas y los scripts que permiten a los atacantes comprometer la seguridad del servidor web o recopilar datos de
las bases de datos de back-end se han convertido en el objetivo de los ataques. Muchas aplicaciones web dinámicas no realizan una
validación suficiente de la entrada del usuario, lo que permite a los atacantes enviar comandos que se ejecutan en el servidor. Ejemplos
comunes de esta forma de ataque son la inyección de lenguaje de consulta estructurado (SQL), donde un atacante envía información
que se pasará a una base de datos y se procesará, y las secuencias de comandos entre sitios, donde un atacante manipula la aplicación
para almacenar comandos de lenguaje de secuencias de comandos que son se activa cuando otro usuario accede a la página Web.
Se requieren una serie de pasos para garantizar la seguridad de cualquier servidor web público. Sin embargo, como requisito
previo para dar cualquier paso, es esencial que la organización cuente con una política de seguridad. Tomar los siguientes pasos
dentro del contexto de la política de seguridad de la organización debería resultar efectivo:
Paso 1: Instalación, configuración y protección del sistema operativo (SO) subyacente
Paso 2: Instalación, configuración y protección del software del servidor web
Paso 3: Empleo de mecanismos de protección de red apropiados (p. ej., cortafuegos, enrutador de filtrado de paquetes y proxy)
Paso 4: Asegurarse de que todas las aplicaciones desarrolladas específicamente para el servidor web estén codificadas siguiendo
prácticas de programación seguras
2-2
Paso 5: Mantener la configuración segura mediante la aplicación de parches y actualizaciones apropiados, pruebas
de seguridad, monitoreo de registros y copias de seguridad de datos y SO
Paso 6: Usar, publicar y proteger la información y los datos de manera cuidadosa y sistémica
Paso 7: Emplear procesos seguros de administración y mantenimiento (incluida la actualización de servidores/aplicaciones

y revisiones de registros)
Paso 8: Realización de exploraciones de vulnerabilidad iniciales y periódicas de cada servidor web público y de la infraestructura
de red de apoyo (por ejemplo, cortafuegos, enrutadores).
Las prácticas recomendadas en este documento están diseñadas para ayudar a mitigar los riesgos asociados con los
servidores web públicos. Se basan y asumen la implementación de las prácticas descritas en las publicaciones del NIST sobre
seguridad de sistemas y redes enumeradas en el Apéndice A.
Al abordar problemas de seguridad del servidor web, es una excelente idea tener en cuenta los siguientes principios generales de
seguridad de la información [Curt01 y Salt75]:
Simplicidad: los mecanismos de seguridad (y los sistemas de información en general) deben ser lo más simples
posible. La complejidad está en la raíz de muchos problemas de seguridad.
A prueba de fallas: si ocurre una falla, el sistema debe fallar de manera segura, es decir, los controles y configuraciones de
seguridad permanecen vigentes y se aplican. Por lo general, es mejor perder funcionalidad que seguridad.
Mediación completa: en lugar de proporcionar acceso directo a la información, se deben emplear mediadores que hagan
cumplir la política de acceso. Los ejemplos comunes de mediadores incluyen permisos de sistemas de archivos, servidores
proxy, firewalls y puertas de enlace de correo.
Diseño abierto : la seguridad del sistema no debe depender del secreto de la implementación o sus componentes. La
“seguridad a través de la oscuridad” no es confiable.
Separación de privilegios: las funciones, en la medida de lo posible, deben estar separadas y proporcionar la mayor
granularidad posible. El concepto puede aplicarse tanto a sistemas como a operadores y usuarios. En el caso de los sistemas,
las funciones como leer, editar, escribir y ejecutar deben estar separadas. En el caso de los operadores y usuarios del sistema,
los roles deben estar lo más separados posible. Por ejemplo, si los recursos lo permiten, la función de administrador del
sistema debe ser independiente de la del administrador de seguridad.
Mínimo privilegio: este principio dicta que a cada tarea, proceso o usuario se le otorgan los derechos mínimos
necesarios para realizar su trabajo. Al aplicar este principio de manera consistente, si una tarea, un proceso o un usuario se
ven comprometidos, el alcance del daño se limita a los recursos limitados disponibles para la entidad comprometida.
Aceptabilidad psicológica: los usuarios deben comprender la necesidad de la seguridad. Esto se puede proporcionar
a través de la formación y la educación. Además, los mecanismos de seguridad implementados deben presentar a los
usuarios opciones sensatas que les brinden la usabilidad que requieren en el día a día. Si los usuarios encuentran que los
mecanismos de seguridad son demasiado engorrosos, pueden idear formas de evitarlos o comprometerlos. El objetivo no es
debilitar la seguridad para que sea comprensible y aceptable, sino capacitar y educar a los usuarios y diseñar mecanismos y
políticas de seguridad que sean utilizables y efectivos.
2-3
Mecanismo menos común: al proporcionar una función para el sistema, es mejor que un solo proceso o servicio
obtenga alguna función sin otorgar esa misma función a otras partes del sistema. La capacidad del proceso del servidor
web para acceder a una base de datos de back-end, por ejemplo, no debería permitir que otras aplicaciones del sistema
accedan a la base de datos de back-end.
Defensa en profundidad: las organizaciones deben comprender que, por lo general, un único mecanismo de seguridad
es insuficiente. Los mecanismos de seguridad (defensas) deben estar en capas para que el compromiso de un solo
mecanismo de seguridad sea insuficiente para comprometer un host o una red. No existe una "bala de plata" para la
seguridad del sistema de información.
Factor de trabajo : las organizaciones deben comprender lo que se necesitaría para romper las funciones de seguridad del
sistema o de la red. La cantidad de trabajo necesaria para que un atacante rompa el sistema o la red debe exceder el valor
que el atacante obtendría de un compromiso exitoso.
Grabación de compromiso: se deben mantener registros y bitácoras para que, si ocurre un compromiso, la
organización disponga de pruebas del ataque. Esta información puede ayudar a proteger la red y el host después del
compromiso y ayudar a identificar los métodos y las vulnerabilidades utilizadas por el atacante. Esta información se puede
utilizar para proteger mejor el host o la red en el futuro. Además, estos registros y bitácoras pueden ayudar a las
organizaciones a identificar y procesar a los atacantes.
2-4
3. Planificación y gestión de servidores web
El aspecto más crítico de la implementación de un servidor web seguro es la planificación cuidadosa antes de la instalación,
configuración e implementación. Una planificación cuidadosa garantizará que el servidor web sea lo más seguro posible y cumpla con
todas las políticas organizacionales relevantes. Muchos problemas de rendimiento y seguridad de los servidores web se pueden atribuir
a la falta de planificación o controles de gestión. No se puede exagerar la importancia de los controles de gestión. En muchas
organizaciones, la estructura de soporte de TI está muy fragmentada. Esta fragmentación genera inconsistencias, y estas inconsistencias
pueden generar vulnerabilidades de seguridad y otros problemas.
3.1 Planificación de la instalación y el despliegue
La seguridad debe considerarse desde la etapa de planificación inicial al comienzo del ciclo de vida del desarrollo de sistemas para
maximizar la seguridad y minimizar los costos. Es mucho más difícil y costoso abordar la seguridad después del despliegue y la
implementación. Es más probable que las organizaciones tomen decisiones sobre la configuración de hosts de manera adecuada y
coherente si comienzan por desarrollar y utilizar un plan de implementación detallado y bien diseñado. El desarrollo de un plan de este tipo
permite a las organizaciones tomar decisiones de compensación informadas entre la usabilidad y el rendimiento y el riesgo. Un plan de
implementación permite a las organizaciones mantener configuraciones seguras y ayuda a identificar vulnerabilidades de seguridad, que a
menudo se manifiestan como desviaciones del plan.
En las etapas de planificación de un servidor Web, se deben considerar los siguientes elementos [Alle00]:
Identifique los propósitos del servidor web.
¿Qué categorías de información se almacenarán en el servidor Web?
¿Qué categorías de información se procesarán o transmitirán a través del servidor web?
¿Cuáles son los requisitos de seguridad para esta información?
¿Se recuperará o almacenará alguna información en otro host (p. ej., base de datos de back-end, servidor de correo)?
¿Cuáles son los requisitos de seguridad para cualquier otro host involucrado (p. ej., base de datos de back-end,
servidor de directorio, servidor de correo, servidor proxy)?
¿Qué otros servicios proporcionará el servidor web (en general, dedicar el host a ser solo un servidor web es la opción más
segura)?
¿Cuáles son los requisitos de seguridad para estos servicios adicionales?
¿Cuáles son los requisitos para la continuidad de los servicios proporcionados por los servidores web, como los
especificados en los planes de continuidad de operaciones y planes de recuperación ante desastres?
¿En qué lugar de la red se ubicará el servidor web (consulte la Sección 8)?
Identifique los servicios de red que se brindarán en el servidor Web, como los que se brindan a través de los siguientes protocolos:
HTTP
3-1
HTTPS8
Protocolo de almacenamiento en caché de Internet (ICP)
Protocolo de almacenamiento en caché de hipertexto (HTCP)
Protocolo de coordinación de caché web (WCCP)
CALCETINES9
Servicios de bases de datos (p. ej., Conectividad abierta de bases de datos [ODBC]).
Identifique cualquier software de servicio de red, tanto de cliente como de servidor, que se instalará en el servidor web y en cualquier otro servidor
de soporte.
Identificar los usuarios o categorías de usuarios del servidor web y cualquier host de soporte.
Determine los privilegios que tendrá cada categoría de usuario en el servidor web y los hosts de soporte.
Determine cómo se administrará el servidor web (por ejemplo, localmente, remotamente desde la red interna, remotamente desde redes externas).
Decida si se autenticarán los usuarios y cómo se protegerán los datos de autenticación.
Determinar cómo se hará cumplir el acceso apropiado a los recursos de información.
Determine qué aplicaciones de servidor web cumplen con los requisitos de la organización. Considere servidores que pueden ofrecer mayor
seguridad, aunque con menos funcionalidad en algunos casos. Algunas cuestiones a considerar incluyen:
Costo
Compatibilidad con la infraestructura existente
Conocimiento de los empleados existentes.
Relación existente con el fabricante
Historial de vulnerabilidades pasadas
Funcionalidad.
Trabajar en estrecha colaboración con los fabricantes en la etapa de planificación.
La elección de la aplicación del servidor web puede determinar la elección del sistema operativo. Sin embargo, en la medida de lo posible, los
administradores de servidores web deben elegir un sistema operativo que proporcione lo siguiente [Alle00]:
Capacidad para restringir actividades administrativas o de nivel raíz solo a usuarios autorizados
8
Transacciones HTTP protegidas a través de los protocolos Secure Sockets Layer (SSL)/Transport Layer Security (TLS) (consulte la Sección 7).
9
“SOCKS” es una abreviatura de “SOCKetS”.
3-2
Capacidad para controlar el acceso a los datos en el servidor
Capacidad para deshabilitar servicios de red innecesarios que pueden estar integrados en el sistema operativo o en el software del servidor
Capacidad para controlar el acceso a varias formas de programas ejecutables, como Common Gateway
Scripts de interfaz (CGI) y complementos de servidor en el caso de servidores web
Capacidad para registrar actividades de servidor apropiadas para detectar intrusiones e intentos de intrusión
Provisión de una capacidad de firewall basada en host.
Además, las organizaciones deben considerar la disponibilidad de personal capacitado y experimentado para administrar el servidor y los productos del
servidor. Muchas organizaciones han aprendido la difícil lección de que un administrador capaz y experimentado para un tipo de entorno operativo no
es automáticamente tan efectivo para otro.
Aunque muchos servidores web no alojan información confidencial, la mayoría de los servidores web deben considerarse confidenciales debido al daño
que podría causar a la reputación de la organización si se compromete la integridad de los servidores. En tales casos, es fundamental que los servidores
web estén ubicados en áreas que proporcionen entornos físicos seguros. Al planificar la ubicación de un servidor web, se deben considerar los siguientes
aspectos:
¿Existen los mecanismos apropiados de protección de la seguridad física? Ejemplos incluyen-
Cerraduras
Acceso al lector de tarjetas
Guardias de seguridad
IDS físicos (por ejemplo, sensores de movimiento, cámaras).
¿Existen controles ambientales adecuados para que se mantenga la humedad y temperatura necesarias?
¿Hay una fuente de energía de respaldo? ¿Por cuánto tiempo proporcionará energía?
Si se requiere alta disponibilidad, ¿existen conexiones a Internet redundantes de al menos dos proveedores de servicios de Internet (ISP)
diferentes?
Si la ubicación está sujeta a desastres naturales conocidos, ¿está protegida contra esos desastres y/o hay un sitio de contingencia fuera del
área potencial del desastre?
3.2 Personal de Gestión de Seguridad
Debido a que la seguridad del servidor web está estrechamente relacionada con la postura de seguridad del sistema de información general de la
organización, una cantidad de personal de TI y seguridad del sistema puede estar interesado en la planificación, implementación y administración del
servidor web. Esta sección proporciona una lista de funciones genéricas e identifica sus responsabilidades en relación con la seguridad del servidor
web. Estos roles son para fines de discusión y pueden variar según la organización.
3-3
3.2.1 Gerente sénior de TI/Director de información
El Gerente Senior de TI/Director de Información (CIO) se asegura de que la postura de seguridad de la organización sea
adecuada. La Alta Gerencia de TI brinda servicios de dirección y asesoría para la protección de los sistemas de información
de toda la organización. La alta gerencia de TI/CIO es responsable de las siguientes actividades asociadas con los servidores
web:
Coordinar el desarrollo y mantenimiento de las políticas, estándares y procedimientos de seguridad de la información de la

organización.
Coordinar el desarrollo y mantenimiento de los procedimientos de gestión y control de cambios de la organización.
Garantizar el establecimiento y el cumplimiento de políticas de seguridad de TI coherentes para los departamentos de toda
la organización.
Coordinar con la alta gerencia, asuntos públicos y otro personal relevante para producir una política y un proceso
formales para publicar información en sitios web y garantizar que esta política se cumpla.
3.2.2 Gerentes de programas de seguridad de sistemas de información
Los Gerentes del Programa de Seguridad de los Sistemas de Información (ISSPM) supervisan la implementación y el
cumplimiento de los estándares, reglas y regulaciones especificados en la política de seguridad de la organización. Las ISSPM son
responsables de las siguientes actividades asociadas a los servidores Web:
Garantizar que se desarrollen e implementen procedimientos de seguridad.
Garantizar que se sigan las políticas, estándares y requisitos de seguridad.
Garantizar que todos los sistemas críticos estén identificados y que existan planes de contingencia, planes de recuperación
ante desastres y planes de continuidad de operaciones para estos sistemas críticos.
Garantizar que los sistemas críticos se identifiquen y programen para pruebas de seguridad periódicas de acuerdo con los
requisitos de la política de seguridad de cada sistema respectivo.
3.2.3 Oficiales de seguridad de los sistemas de información
Los Oficiales de Seguridad de los Sistemas de Información (ISSO) son responsables de supervisar todos los aspectos de la
seguridad de la información dentro de una entidad organizacional específica. Aseguran que las prácticas de seguridad de la
información de la organización cumplan con las políticas, normas y procedimientos organizacionales y departamentales. Los ISSO
son responsables de las siguientes actividades asociadas con los servidores web:
Desarrollar estándares y procedimientos de seguridad internos para los servidores web y la infraestructura de red de soporte
Cooperar en el desarrollo e implementación de herramientas, mecanismos y técnicas de mitigación de seguridad
Mantener los perfiles de configuración estándar de los servidores web y la infraestructura de red de apoyo controlada por la
organización, incluidos, entre otros, sistemas operativos, firewalls, enrutadores y aplicaciones de servidor web.
3-4
Mantener la integridad operativa de los sistemas mediante la realización de pruebas de seguridad y garantizar que los profesionales
de TI designados realicen pruebas programadas en sistemas críticos.
3.2.4 Administradores de Redes y Servidores Web
Los administradores de servidores web son arquitectos de sistemas responsables del diseño, la implementación y el mantenimiento
generales de un servidor web. Los administradores de red son responsables del diseño general, la implementación y el mantenimiento
de una red. Diariamente, los servidores web y los administradores de red se enfrentan a los requisitos de seguridad de los sistemas
específicos de los que son responsables. Los problemas y las soluciones de seguridad pueden originarse desde el exterior (p. ej.,
parches y correcciones de seguridad del fabricante o equipos de respuesta a incidentes de seguridad informática) o dentro de la
organización (p. ej., la oficina de seguridad). Los administradores son responsables de las siguientes actividades asociadas a los
servidores web:
Instalar y configurar sistemas de conformidad con las políticas de seguridad de la organización y las configuraciones
estándar de sistemas y redes.
Mantener los sistemas de manera segura, incluidas las copias de seguridad frecuentes y la aplicación oportuna de
parches.
Supervisar la integridad del sistema, los niveles de protección y los eventos relacionados con la seguridad
Dar seguimiento a las anomalías de seguridad detectadas asociadas a los recursos de sus sistemas de información
Realización de pruebas de seguridad según sea necesario.
3.2.5 Desarrolladores de aplicaciones web
Los desarrolladores de aplicaciones web son responsables del aspecto, la funcionalidad, el rendimiento y la seguridad del contenido
web y las aplicaciones basadas en web que crean. Como se mencionó en la Sección 2, las amenazas se dirigen cada vez más a las
aplicaciones en lugar del software del servidor web y los sistemas operativos subyacentes. A menos que los desarrolladores de
aplicaciones web se aseguren de que su código tenga en cuenta la seguridad, la seguridad del servidor web será débil sin importar
qué tan bien estén protegidos el servidor y la infraestructura de soporte. Los desarrolladores de aplicaciones web deben asegurarse de
que las aplicaciones que implementen tengan las siguientes características:
Admite un mecanismo seguro de autenticación, autorización y control de acceso según sea necesario.
Realiza la validación de entrada para que los mecanismos de seguridad de la aplicación no se puedan eludir cuando un usuario
malintencionado manipula los datos que envía a la aplicación, incluidas las solicitudes HTTP, los encabezados, las cadenas
de consulta, las cookies, los campos de formulario y los campos ocultos.
Procesa los errores de manera segura para no dar lugar a la exposición de información confidencial de implementación.
Protege la información sensible procesada y/o almacenada por la aplicación. Una protección inadecuada puede permitir la
manipulación de datos y el acceso a información confidencial, como nombres de usuario, contraseñas y números de tarjetas de
crédito.
Mantiene sus propios registros específicos de la aplicación. En muchos casos, el registro del servidor web no es suficiente para
rastrear lo que hace un usuario en el nivel de la aplicación, lo que requiere que la aplicación mantenga sus propios registros.
Los detalles de registro insuficientes pueden provocar una falta de conocimiento sobre posibles intrusiones y la incapacidad de
verificar las acciones de un usuario (tanto legítimas como maliciosas).
3-5
Está "reforzado" contra ataques DoS a nivel de aplicación. Aunque los ataques DoS se dirigen con mayor frecuencia a las
capas de red y transporte, la aplicación en sí misma puede ser un objetivo. Si un usuario malicioso puede monopolizar una
aplicación requerida o un recurso del sistema, se puede evitar que los usuarios legítimos usen el sistema.
3.3 Prácticas de gestión
Las prácticas de administración adecuadas son fundamentales para operar y mantener un servidor web seguro.
Las prácticas de seguridad implican la identificación de los activos del sistema de información de una organización y el
desarrollo, documentación e implementación de políticas, estándares, procedimientos y pautas que aseguren la confidencialidad,
integridad y disponibilidad de los recursos del sistema de información.
Para garantizar la seguridad de un servidor web y la infraestructura de red de soporte, las organizaciones deben implementar las
siguientes prácticas:
Política de seguridad del sistema de información de la organización: una política de seguridad debe especificar los
principios y reglas básicos de seguridad del sistema de información y su propósito interno previsto. La política también debe
describir quién en la organización es responsable de áreas particulares de seguridad de la información (p. ej., implementación,
cumplimiento, auditoría, revisión). La política debe aplicarse de manera coherente en toda la organización para que sea eficaz.
Generalmente, el CIO y la alta gerencia son responsables de redactar la política de seguridad de la organización.
Gestión y control de cambios/configuración: el proceso de controlar la modificación del diseño, el hardware, el firmware y
el software de un sistema proporciona suficiente seguridad de que el sistema está protegido contra la introducción de una
modificación inadecuada antes, durante y después de la implementación del sistema. El control de la configuración conduce a
la coherencia con la política de seguridad del sistema de información de la organización. El control de configuración
tradicionalmente es supervisado por una junta de control de configuración que es la autoridad final en todos los cambios
propuestos a un sistema de información. Si los recursos lo permiten, considere el uso de entornos de desarrollo, control de calidad
y/o prueba para que los cambios puedan examinarse y probarse antes de la implementación en producción.
Evaluación y gestión de riesgos : la evaluación de riesgos es el proceso de analizar e interpretar los riesgos. Implica determinar
el alcance y la metodología de una evaluación, recopilar y analizar datos relacionados con el riesgo e interpretar los resultados
del análisis de riesgo. Recopilar y analizar datos de riesgo requiere identificar activos, amenazas, vulnerabilidades, salvaguardas,
consecuencias y la probabilidad de un ataque exitoso. La gestión de riesgos es el proceso de seleccionar e implementar controles
para reducir el riesgo a un nivel aceptable para la organización.
Configuraciones estandarizadas : las organizaciones deben desarrollar configuraciones seguras estandarizadas para sistemas
operativos y aplicaciones ampliamente utilizados. Esto brindará recomendaciones a los administradores de redes y servidores
web sobre cómo configurar sus sistemas de forma segura y garantizar la coherencia y el cumplimiento de la política de
seguridad de la organización. Debido a que solo se necesita un host configurado de manera insegura para comprometer una red,
se recomienda especialmente a las organizaciones con una cantidad significativa de hosts que apliquen esta recomendación.
Prácticas de programación segura : las organizaciones deben adoptar pautas de desarrollo de aplicaciones seguras para
garantizar que desarrollan sus aplicaciones web de una manera suficientemente segura.
Concientización y capacitación en seguridad: un programa de capacitación en seguridad es fundamental para la postura

general de seguridad de una organización. Hacer que los usuarios y administradores sean conscientes de sus responsabilidades
de seguridad y enseñarles las prácticas correctas les ayuda a cambiar su comportamiento para adaptarse mejor a la seguridad.
3-6
practicas La capacitación también respalda la responsabilidad individual, que es un método importante para mejorar la
seguridad del sistema de información. Si la comunidad de usuarios incluye miembros del público en general, también podría
ser apropiado brindarles información sobre seguridad dirigida específicamente a ellos.
Planificación de contingencia, continuidad de las operaciones y recuperación ante desastres : los planes de contingencia, la
continuidad de las operaciones y los planes de recuperación ante desastres se establecen con anticipación para permitir que
una organización o instalación mantenga las operaciones en caso de una interrupción.10
Certificación y acreditación: la certificación en el contexto de la seguridad de los sistemas de información significa que un sistema
ha sido analizado para determinar qué tan bien cumple con todos los requisitos de seguridad de la organización. La acreditación
ocurre cuando la gerencia de la organización acepta que el sistema cumple con los requisitos de seguridad de la organización.
11
3.4 Plan de Seguridad del Sistema
El objetivo de la planificación de la seguridad del sistema es mejorar la protección de los recursos del sistema de información.12 Los
planes que protegen adecuadamente los activos de información requieren que los administradores y propietarios de la información
(directamente afectados e interesados en la información y/o las capacidades de procesamiento) estén convencidos de que sus activos
de información están protegidos. protegido adecuadamente contra pérdida, uso indebido, acceso o modificación no autorizados, falta
de disponibilidad y actividades no detectadas.
El propósito del plan de seguridad del sistema es proporcionar una descripción general de los requisitos de seguridad y
privacidad del sistema y describir los controles implementados o planificados para cumplir con esos requisitos.
El plan de seguridad del sistema también delinea las responsabilidades y el comportamiento esperado de todas las personas que
acceden al sistema. El plan de seguridad del sistema debe verse como la documentación del proceso estructurado de planificación de
una protección de seguridad adecuada y rentable para un sistema. Debe reflejar los aportes de varios administradores con
responsabilidades relacionadas con el sistema, incluidos los propietarios de la información, el propietario del sistema y el ISSPM.
Para las agencias federales, todos los sistemas de información deben estar cubiertos por un plan de seguridad del sistema.
Otras organizaciones también deberían considerar seriamente la realización de un plan de seguridad del sistema para cada uno de sus
sistemas. El propietario del sistema de información13 es generalmente la parte responsable de garantizar que se desarrolle y mantenga
el plan de seguridad y que el sistema se implemente y opere de acuerdo con los requisitos de seguridad acordados.
En general, un plan eficaz de seguridad del sistema debe incluir lo siguiente:
Identificación del sistema: las primeras secciones del plan de seguridad del sistema brindan información de identificación
básica sobre el sistema. Contienen información general, como los puntos clave de contacto del sistema, el propósito del sistema, el
nivel de sensibilidad del sistema y el entorno en el que se implementa el sistema.
10
Para obtener más información, consulte NIST SP 800-34, Guía de planificación de contingencia para sistemas de tecnología de la información
(http://csrc.nist.gov/publications/nistpubs/).
11
Para obtener más información sobre certificación y acreditación, consulte NIST SP 800-37, Directrices federales para la certificación de seguridad
y acreditación de sistemas de tecnología de la información (http://csrc.nist.gov/publications/nistpubs/).
12
Para obtener más información sobre los planes de seguridad del sistema, consulte NIST SP 800-18 Revisión 1, Guía para desarrollar planes de seguridad
para sistemas de información federales (http://csrc.nist.gov/publications/nistpubs/).
13
El propietario del sistema de información es responsable de definir los parámetros operativos del sistema, las funciones autorizadas y los requisitos de
seguridad. El propietario de la información almacenada, procesada o transmitida por un sistema puede o no ser el mismo propietario del sistema de
información. Además, un solo sistema puede usar información de múltiples propietarios de información.
3-7
Controles—Esta sección del plan describe las medidas de control (establecidas o planeadas) que están destinadas a
cumplir con los requisitos de protección del sistema de información. Los controles se dividen en tres categorías generales:
Controles de gestión, que se centran en la gestión del sistema de seguridad informática y la gestión del riesgo de un sistema.
Controles operativos, que son implementados y ejecutados principalmente por personas (en lugar de sistemas). A
menudo requieren conocimientos técnicos o especializados y, a menudo, se basan en actividades de gestión, así como en
controles técnicos.
Controles técnicos, que son mecanismos de seguridad que emplea el sistema informático. Los controles pueden
brindar protección automatizada contra el acceso no autorizado o el uso indebido, facilitar la detección de violaciones
de seguridad y respaldar los requisitos de seguridad para aplicaciones y datos. Sin embargo, la implementación de controles
técnicos siempre requiere importantes consideraciones operativas y debe ser coherente con la gestión de la seguridad dentro
de la organización [NIST06a].14
3.5 Requisitos de recursos humanos
El mayor desafío y gasto en el desarrollo y mantenimiento seguro de un servidor web público es proporcionar los recursos
humanos necesarios para realizar adecuadamente las funciones requeridas. Muchas organizaciones no reconocen
completamente la cantidad de gastos y habilidades requeridas para implementar un servidor web público seguro. Esta falla a
menudo resulta en empleados con exceso de trabajo y sistemas inseguros. Desde las etapas iniciales de planificación, las
organizaciones deben determinar los requisitos de recursos humanos necesarios.
Los recursos humanos apropiados y suficientes son el aspecto más importante de la seguridad efectiva del servidor web. Las
organizaciones también deben considerar el hecho de que, en general, las soluciones técnicas no reemplazan al personal calificado y
experimentado.
Al considerar las implicaciones de recursos humanos del desarrollo y la implementación de un servidor web, las
organizaciones deben considerar lo siguiente:
Personal requerido: ¿Qué tipo de personal se requiere? Esto incluiría puestos como administradores de sistemas y servidores
web, webmasters, administradores de redes e ISSO.
Habilidades requeridas: ¿Cuáles son las habilidades requeridas para planificar, desarrollar y mantener adecuadamente el
servidor web de manera segura? Los ejemplos incluyen la administración del sistema operativo, la administración de la red, la
experiencia en contenido activo y la programación.
Personal disponible—¿Cuáles son los recursos humanos disponibles dentro de la organización? Además, ¿cuáles son sus
conjuntos de habilidades actuales y son suficientes para admitir el servidor web? A menudo, una organización descubre que sus
recursos humanos existentes no son suficientes y necesita considerar las siguientes opciones:
Capacitar al personal actual: si hay personal disponible pero no tiene las habilidades requeridas, la organización puede optar
por capacitar al personal existente en las habilidades requeridas. Si bien esta es una excelente opción, la organización debe
asegurarse de que los empleados cumplan con todos los requisitos previos para la capacitación.
14
Para obtener más detalles sobre controles de gestión, operativos y técnicos, consulte NIST SP 800-53 Revisión 1, Controles de
seguridad recomendados para sistemas de información federales, y NIST SP 800-100, Manual de seguridad de la información: una
guía para gerentes (http://csrc .nist.gov/publications/nistpubs/).
3-8
Adquirir personal adicional: si no hay suficientes miembros del personal disponibles o no tienen las habilidades necesarias,
puede ser necesario contratar personal adicional o utilizar recursos externos.
Una vez que la organización haya dotado de personal al proyecto y el servidor web esté activo, será necesario asegurarse de que la
cantidad y las habilidades del personal sigan siendo adecuadas. Los niveles de amenaza y vulnerabilidad de los sistemas de TI, incluidos
los servidores web, cambian constantemente, al igual que la tecnología. Esto significa que lo que es adecuado hoy puede no serlo
mañana.
3.6 Plataformas alternativas de servidores web
Aunque muchas organizaciones administran servidores web que funcionan con sistemas operativos de propósito general, hay
instancias en las que una organización puede desear utilizar una de las alternativas que se analizan a continuación. Aunque estas
tecnologías son relativamente nuevas en el área de los servidores web, se basan en tecnologías sólidas y han comenzado a tener un
uso más amplio en el entorno de los servidores web.
3.6.1 Sistemas operativos de confianza
Los sistemas operativos de confianza (TOS) son sistemas operativos con seguridad modificada o mejorada que incluyen mecanismos de
seguridad adicionales que no se encuentran en la mayoría de los sistemas operativos de propósito general. Fueron creados originalmente
para satisfacer la necesidad del gobierno federal de sistemas de control de acceso obligatorio (MAC) de alta seguridad. Los TOS brindan
una política de control de todo el sistema muy segura, un conjunto de privilegios de acceso finamente definido y amplias capacidades de
registro y auditoría. Muchos TOS se verifican de forma independiente para garantizar que cumplan con los requisitos establecidos en su
documentación de diseño.
Los TOS generalmente se usan en aplicaciones para las cuales la seguridad es primordial. Los TOS pueden controlar de forma segura
todos los aspectos de un entorno informático, incluidos los recursos de red, los usuarios, los procesos y la memoria.
Específicamente, los TOS pueden limitar el acceso a los recursos del sistema de manera que no sea probable que se interfiera o se
comprometa.
El uso de un TOS generalmente producirá un servidor web muy seguro; sin embargo, existen algunas dificultades en el uso de los TOS.
Un inconveniente importante es que la configuración y administración de un TOS requiere el conocimiento de cada subsistema protegido
y sus necesidades de acceso. También puede requerir una planificación significativa y gastos generales administrativos para diseñar y
respaldar un sitio web complejo en un TOS. Sin embargo, incluso con estas limitaciones, las organizaciones que tienen requisitos de
seguridad muy altos deberían considerar usar un TOS en su Web.
servidores.
Algunos fabricantes han comenzado a agrupar sus ofertas de SO con la mayor parte o la totalidad de la funcionalidad de los TOS
tradicionales para su uso en entornos de servidor o estación de trabajo. Las organizaciones pueden beneficiarse de tales sistemas
porque gran parte de los gastos generales en el diseño y configuración del servidor web para ejecutarse en un entorno TOS ha sido
realizado por el fabricante. Los servidores web se benefician de la MAC de los TOS en el sentido de que el sistema puede denegar
explícitamente el acceso del proceso del servidor web a partes confidenciales del sistema, incluso si un atacante ha logrado tomar el control
del proceso.
Los siguientes son algunos aspectos a tener en cuenta al considerar una plataforma web:
¿Cuál es el sistema operativo subyacente y cómo le ha ido en las pruebas de seguridad?
¿Tiene la organización la experiencia necesaria para administrar un TOS?
¿Los costos adicionales de comprar y respaldar un TOS son superados por los beneficios?
3-9
¿Los TOS son compatibles con las aplicaciones web y los scripts existentes de la organización?
¿El TOS es compatible con otras aplicaciones y servidores de la organización con los que interoperará?
3.6.2 Dispositivos de servidor web
Un dispositivo de servidor web es una combinación de software/hardware que está diseñado para ser un servidor web "plug-and-play".
Estos dispositivos emplean el uso de un sistema operativo simplificado que está optimizado para admitir un servidor web.
El SO simplificado mejora la seguridad al minimizar funciones, servicios y opciones innecesarias. La aplicación del servidor web
en estos sistemas a menudo está reforzada y configurada previamente para la seguridad.
Estos sistemas ofrecen otros beneficios además de la seguridad. El rendimiento suele mejorar porque el sistema (es decir, el
sistema operativo, la aplicación del servidor web y el hardware) está diseñado y construido específicamente para funcionar como un
servidor web. El costo a menudo se reduce porque el hardware y el software que no son específicamente requeridos por un servidor
web no están incluidos. Estos sistemas pueden ser una excelente opción para organizaciones pequeñas y medianas que no pueden
pagar un administrador web de tiempo completo.
La mayor debilidad de estos sistemas es que pueden no ser adecuados para sitios web grandes, complejos y de varias capas.
Pueden estar limitados en cuanto a los tipos de contenido activo que admiten (p. ej., J2EE, .NET, preprocesador de hipertexto PHP
[PHP]), lo que podría reducir las opciones disponibles para una organización. Un dispositivo puede alojar la base de datos de back-
end, así como la interfaz web de front-end, lo que puede impedir que las organizaciones tengan servidores separados para cada
uno. Finalmente, puede ser difícil configurar dispositivos de diferentes fabricantes para que funcionen juntos. No obstante, debido a
que ofrecen un entorno seguro y una interfaz fácil de configurar, las organizaciones de tamaño pequeño a mediano pueden
considerar que los dispositivos son una opción atractiva que requiere menos esfuerzo administrativo. Los dispositivos de servidor web
están disponibles en la mayoría de los principales fabricantes de hardware y en varios fabricantes especializados que se concentran
únicamente en dispositivos de servidor web.
Además de los dispositivos de servidor web, también hay un número creciente de dispositivos de seguridad disponibles para servidores
web. Estos sistemas aumentan los mecanismos de seguridad del propio servidor web. En algunos casos, estos sistemas pueden evitar
que los ataques lleguen a un servidor web, lo que es especialmente útil si el servidor tiene vulnerabilidades conocidas (por ejemplo,
aún no se han aplicado nuevos parches). Los tipos más comunes de dispositivos de seguridad son:
Aceleradores de capa de sockets seguros (SSL), que descargan el procesamiento computacionalmente costoso necesario
para iniciar conexiones SSL/Transport Layer Security (TLS)
Puertas de enlace de seguridad, que monitorean el tráfico HTTP hacia y desde el servidor web en busca de posibles ataques y
toman las medidas necesarias
Filtros de contenido, que pueden monitorear el tráfico hacia y desde el servidor web en busca de datos potencialmente
confidenciales o inapropiados y tomar las medidas necesarias.
Puertas de enlace de autenticación, que autentican a los usuarios a través de una variedad de mecanismos de autenticación
y controlan el acceso a los localizadores universales de recursos (URL) alojados en el propio servidor web.
3-10
En muchos casos, la mayor parte o la totalidad de la funcionalidad mencionada anteriormente se combina en un solo dispositivo, que con
frecuencia se denomina proxy inverso.15
En organizaciones que requieren sitios web dinámicos complicados, la configuración del dispositivo de seguridad puede ser compleja, lo
que podría provocar errores de configuración que reduzcan la eficacia del dispositivo. Es importante practicar la defensa en profundidad
para garantizar que las vulnerabilidades presentes en el dispositivo de seguridad o su configuración no afecten negativamente a la
organización en su conjunto.
Un desafío adicional que presentan los dispositivos electrodomésticos es que a menudo emplean software de código abierto de uso
común. Esto normalmente no es un problema, pero puede convertirse en uno cuando se encuentra una vulnerabilidad en el software
subyacente porque con frecuencia no es posible usar el parche lanzado por el grupo de software de código abierto. Las razones comunes
de esta incapacidad para usar el parche incluyen posibles violaciones de los acuerdos de licencia o soporte con el fabricante del dispositivo
y problemas técnicos al aplicar actualizaciones al dispositivo (p. ej., los administradores a menudo no tienen acceso a los dispositivos a
nivel del sistema operativo). Por lo tanto, los dispositivos pueden estar expuestos a ataques durante un período de tiempo más largo que los
sistemas que no son dispositivos debido a la demora adicional que implica el desarrollo, las pruebas y el lanzamiento de parches por parte
de los fabricantes de dispositivos. Otro posible problema con los dispositivos es que, por lo general, no permiten la instalación de software
adicional para administración o seguridad, como software antivirus o agentes de detección de intrusos basados en host.
Los siguientes son algunos aspectos a tener en cuenta al contemplar la compra de un dispositivo web:
¿Cómo le ha ido al dispositivo en las pruebas de seguridad? (Tenga en cuenta que las opciones de configuración de los dispositivos
web son necesariamente limitadas, por lo que un dispositivo web generalmente solo será tan seguro como su configuración de
instalación predeterminada).
¿Qué tan heterogénea es la infraestructura del servidor web de la organización? (Las diferentes marcas de electrodomésticos pueden
no funcionar bien juntas).
¿Las opciones de expansión inherentes al dispositivo son aceptables para la organización? (Es posible que las organizaciones que
anticipan o experimenten un rápido crecimiento en el tráfico web no deseen limitarse a un solo dispositivo o proveedor de dispositivos).
¿Qué tan difícil es configurar el dispositivo? ¿Es el dispositivo lo suficientemente flexible para satisfacer las necesidades
de la organización?
¿Qué tan rápido responde el fabricante y proporciona parches para posibles vulnerabilidades?
¿El software subyacente utilizado en el dispositivo es propietario, de código abierto o una combinación de ambos?
¿Durante cuánto tiempo brindará soporte el fabricante al dispositivo y cuál es el historial de soporte del fabricante para los
dispositivos heredados?
3.6.3 Sistemas operativos y servidores web reforzados previamente
En la actualidad, se distribuye un número creciente de paquetes de servidores web y sistemas operativos reforzados previamente.
Estos paquetes incluyen un sistema operativo y una aplicación de servidor web que se modifican y preconfiguran para brindar alta seguridad.
Algunos de estos paquetes incluyen la plataforma de hardware, mientras que otros son distribuciones de software.
15
Esto no implica que todos los proxies inversos estén basados en dispositivos; de hecho, muchos no lo son.
3-11
que incluyen solo el sistema operativo y la aplicación del servidor web. Estas distribuciones generalmente se basan en sistemas operativos
reforzados y/o modificados de uso general (por ejemplo, Linux, Unix, Windows) que están diseñados específicamente para admitir un
servidor web seguro. La aplicación de servidor web también se basa a menudo en una aplicación de servidor web reforzada y/o modificada
generalmente disponible (por ejemplo, Apache, Internet Information Service [IIS]).
Estos paquetes a menudo incluyen una mayor cantidad de opciones de seguridad y están diseñados para ser más fáciles de
configurar mediante el uso de scripts precompilados e interfaces gráficas de usuario (GUI). Aunque cada uno de estos paquetes es
diferente, por lo general se basan en uno o más de los siguientes para brindar un mayor nivel de protección y seguridad:
Configuración predeterminada inicial segura
Sistema operativo reforzado o TOS
Software de servidor web reforzado
Amplias capacidades de auditoría
Envolturas de aplicaciones
Envolturas de red y/o capacidades de firewall basadas en host
IDS basados en host
Administración de seguridad simplificada (p. ej., menús, GUI).
Estos tipos de sistemas deben ser considerados por organizaciones que enfrentan un nivel de amenaza significativo y/o tienen sitios
web de alto valor (p. ej., las principales organizaciones del gobierno federal, bancos, compañías de seguros de salud). Estos paquetes
están disponibles a través de algunos de los principales fabricantes de hardware y software, además de varios fabricantes especializados.
Algunas cuestiones a tener en cuenta al contemplar la compra de un dispositivo web reforzado:
¿Cómo le ha ido a la aplicación del servidor web en las pruebas de seguridad?
¿Qué tan difícil es administrar?
¿Son compatibles la aplicación del servidor web reforzado y el sistema operativo con las aplicaciones web y los scripts existentes
de la organización?
¿Qué tan rápido responde el fabricante y proporciona parches para posibles vulnerabilidades?
3.6.4 Plataformas virtualizadas
La tecnología de máquinas virtuales se utiliza cada vez con más frecuencia para los servidores web. A través de la
virtualización, una sola computadora host física puede ejecutar varias máquinas virtuales, cada una con un sistema operativo invitado
distinto y aplicaciones asociadas. Un sistema operativo invitado no necesita estar al tanto de otros sistemas operativos, ni siquiera del
host compatible, que se ejecutan en la misma plataforma física. La tecnología de máquinas virtuales está mejorando constantemente.
Las nuevas versiones de los sistemas operativos principales se están diseñando teniendo en cuenta la virtualización y los nuevos
procesadores x86 de 64 bits brindan soporte a nivel de hardware para la virtualización.
3-12
La virtualización permite a las organizaciones reducir los costos al ejecutar varios servidores web en una sola computadora host y al
proporcionar un mecanismo para responder rápidamente a los ataques contra un servidor web. La siguiente lista define los tres tipos
principales de tecnología de máquina virtual. Tenga en cuenta que algunos software de virtualización pueden ser una implementación híbrida,
según el hardware y los sistemas operativos invitados.
Virtualización completa, que simula todo el hardware requerido por el sistema operativo invitado. La virtualización completa es útil en
situaciones en las que el sistema operativo invitado se ejecuta en una arquitectura de máquina diferente a la del host. La virtualización
completa da como resultado un impacto significativo en el rendimiento porque todos los comandos deben ser emulados por software.
Virtualización nativa, que simula solo el hardware necesario para ejecutar un sistema operativo invitado sin modificar.
En la virtualización nativa, la mayoría de los comandos se pueden pasar sin modificar a la unidad de procesamiento (CPU) de la
computadora host, lo que reduce el impacto en el rendimiento.
Paravirtualización, que no simula hardware. En cambio, ofrece una interfaz de programación de aplicaciones (API) que puede ser
utilizada por un sistema operativo invitado modificado, o aprovecha las capacidades de virtualización admitidas por el procesador.
La virtualización agrega otra capa de complejidad a la configuración del servidor web. Tanto el sistema operativo host como el sistema
operativo invitado deben estar protegidos. Si la tecnología de virtualización lo admite, se debe realizar una copia de seguridad de cada
sistema operativo invitado y de la aplicación de servidor web instalada para permitir la restauración si se produce un ataque u otra interrupción.
El servidor web y su sistema operativo invitado, el sistema operativo host y el software de virtualización deben parchearse de manera
oportuna. Es importante tener en cuenta que si el sistema operativo invitado o las aplicaciones se ven comprometidas, la máquina virtual
invitada puede infectar otros hosts en la red como si fuera un host físico independiente. Cada sistema operativo invitado y el software de
servidor web asociado deben configurarse y mantenerse siguiendo las recomendaciones de esta publicación.
3.7 Lista de verificación para planificar y administrar servidores web
Terminado Acción
Planificar la configuración y la implementación del servidor web
Identificar las funciones del servidor web Identificar las categorías de

información que se almacenará, procesará y transmitirá a través del servidor web
Identificar los requisitos de seguridad de la información Identificar cómo se publica
la información en el servidor web Identificar los requisitos de seguridad de otros
hosts involucrados (p. ej., base de datos back-end o servicio web)
Identificar un host dedicado para ejecutar el servidor
web. Identificar los servicios de red que proporcionará o admitirá la web.

servidor
Identificar los requisitos de seguridad de cualquier servicio adicional proporcionado o

respaldado por el servidor web.
Identificar cómo se administrará el servidor Web

Identificar usuarios y categorías de usuarios del servidor web y determinar privilegios
para cada categoría de usuario
Identificar los métodos de autenticación de usuarios para el servidor web y

cómo se protegerán los datos de autenticación
Identificar cómo se hará cumplir el acceso a los recursos de información
3-13
Terminado Acción
Identificar los mecanismos de seguridad física apropiados
Identificar los mecanismos de disponibilidad apropiados
Elija el sistema operativo apropiado para el servidor web
Exposición mínima a vulnerabilidades
Capacidad para deshabilitar servicios de red innecesarios que pueden estar integrados en el
SO o software de servidor
Capacidad para controlar el acceso a varias formas de programas ejecutables, como

Scripts CGI y complementos de servidor
Capacidad para registrar actividades de servidor apropiadas para detectar intrusiones e

intentos de intrusión
Provisión de una capacidad de firewall basada en host
Disponibilidad de personal experimentado para instalar, configurar, asegurar y mantener

TÚ
Elija la plataforma adecuada para el servidor web
SO de propósito general
SO de confianza
Dispositivo de servidor web
Sistema operativo y servidor web reforzados previamente
Plataforma virtualizada
3-14
4. Protección del sistema operativo del servidor web
Proteger un servidor web de un compromiso implica fortalecer el sistema operativo subyacente, la aplicación del servidor web y la red para
evitar que entidades malintencionadas ataquen directamente al servidor web. El primer paso para proteger un servidor web, fortalecer el sistema
operativo subyacente, se analiza en profundidad en esta sección.
(La protección de la aplicación del servidor web y la red se tratan en las Secciones 5 y 8, respectivamente).
Todos los servidores web comúnmente disponibles funcionan en un sistema operativo de propósito general. Se pueden evitar muchos problemas
de seguridad si los sistemas operativos subyacentes a los servidores web se configuran adecuadamente. Los fabricantes suelen establecer
configuraciones predeterminadas de hardware y software para enfatizar características, funciones y facilidad de uso, a expensas de la seguridad.
Debido a que los fabricantes desconocen las necesidades de seguridad de cada organización, cada administrador de servidor web debe configurar nuevos
servidores para reflejar los requisitos de seguridad de su organización y reconfigurarlos a medida que esos requisitos cambian. Las prácticas recomendadas
aquí están diseñadas para ayudar a los administradores de servidores web a configurar e implementar servidores web que satisfagan los requisitos de
seguridad de sus organizaciones. Los administradores de servidores web que gestionan servidores web existentes deben confirmar que sus sistemas
abordan los problemas discutidos.
Las técnicas para fortalecer diferentes sistemas operativos varían mucho; por lo tanto, esta sección incluye los procedimientos genéricos
comunes para proteger la mayoría de los sistemas operativos. Las guías de configuración de seguridad y las listas de verificación para muchos
sistemas operativos están disponibles públicamente; estos documentos generalmente contienen recomendaciones para configuraciones que mejoran
el nivel predeterminado de seguridad y también pueden contener instrucciones paso a paso para proteger los sistemas.16 Además, muchas
organizaciones mantienen sus propias pautas específicas para sus requisitos. También existen algunas herramientas automatizadas para fortalecer los
sistemas operativos y se recomienda encarecidamente su uso (consulte el Apéndice D).
Se necesitan cinco pasos básicos para mantener la seguridad básica del sistema operativo:
Planificación de la instalación y la implementación del sistema operativo host y otros componentes para el servidor web
Aplicación de parches y actualización del sistema operativo host según sea necesario
Fortalecimiento y configuración del sistema operativo host para abordar la seguridad de manera adecuada
Instalar y configurar controles de seguridad adicionales, si es necesario
Probar el sistema operativo host para garantizar que los cuatro pasos anteriores abordaron adecuadamente todos los problemas de seguridad.
El primer paso se analiza en la Sección 3. Los otros pasos se tratan en las Secciones 4.1 y 4.2.
4.1 Instalación y configuración del sistema operativo
Esta sección proporciona una descripción general de los pasos segundo, tercero y cuarto de la lista anterior. El resultado combinado de estos pasos
debería ser un nivel razonable de protección para el sistema operativo del servidor web.
4.1.1 Parche y actualización del sistema operativo
Una vez que se instala un sistema operativo, es esencial aplicar los parches o actualizaciones necesarios para corregir las vulnerabilidades
conocidas. Cualquier vulnerabilidad conocida que tenga un sistema operativo debe corregirse antes de usarlo para alojar un servidor web.
dieciséis
Las listas de verificación y las guías de implementación para varios sistemas operativos y aplicaciones están disponibles en NIST en http://
checklists.nist.gov/. Además, consulte NIST SP 800-70, Programa de listas de verificación de configuración de seguridad para productos de TI, disponible en
el mismo sitio web, para obtener información general sobre el programa de listas de verificación de NIST.
4-1
o exponerlo de otro modo a usuarios que no sean de confianza. Para detectar y corregir adecuadamente estas vulnerabilidades, los
administradores de servidores web deben hacer lo siguiente:
Cree, documente e implemente un proceso de aplicación de parches.17
Identificar vulnerabilidades y parches aplicables.18
Mitigar las vulnerabilidades temporalmente si es necesario y factible (hasta que los parches estén disponibles, probados e instalados).
Instale arreglos permanentes (comúnmente llamados parches, revisiones, paquetes de servicios o actualizaciones).
Los administradores deben asegurarse de que los servidores web, especialmente los nuevos, estén adecuadamente protegidos durante el
proceso de aplicación de parches. Por ejemplo, un servidor web que no está completamente parcheado o que no está configurado de forma
segura podría verse comprometido por amenazas si es de acceso público mientras se está parcheando. Al preparar nuevos servidores web
para su implementación, los administradores deben realizar una de las siguientes acciones:
Mantenga los servidores desconectados de las redes o conéctelos solo a una red de "construcción" aislada hasta que todos los
parches hayan sido transferidos a los servidores a través de medios fuera de banda (por ejemplo, CD) e instalados, y los demás
pasos de configuración enumerados en la Sección 4.1 ha sido interpretado.
Coloque los servidores en una red de área local virtual (VLAN)19 u otro segmento de red que restrinja severamente qué acciones
pueden realizar los hosts y qué comunicaciones pueden llegar a los hosts, permitiendo solo aquellos eventos que son necesarios para
parchear y configurar los hosts. No transfiera los hosts a segmentos de red normales hasta que se hayan realizado todos los pasos de
configuración enumerados en la Sección 4.1.
Por lo general, los administradores no deben aplicar parches a los servidores web sin antes probarlos en otro sistema configurado de
manera idéntica porque los parches pueden causar problemas inesperados sin darse cuenta con el funcionamiento adecuado del sistema.
Aunque los administradores pueden configurar servidores web para descargar parches automáticamente, los servidores no deben
configurarse para instalarlos automáticamente para que puedan probarse primero.
4.1.2 Eliminar o deshabilitar aplicaciones y servicios innecesarios
Idealmente, un servidor web debería estar en un host dedicado de un solo propósito. Al configurar el sistema operativo, deshabilite todo
excepto lo que esté expresamente permitido, es decir, deshabilite todos los servicios y aplicaciones, vuelva a habilitar solo aquellos
requeridos por el servidor web y luego elimine los servicios y aplicaciones innecesarios. Si es posible, instale la configuración mínima del
sistema operativo y luego agregue o elimine servicios y aplicaciones según sea necesario. Elija la opción de "instalación mínima", si está
disponible, para minimizar el esfuerzo requerido para eliminar servicios innecesarios. Además, muchos scripts o programas de desinstalación
están lejos de ser perfectos para eliminar por completo todos los componentes de un servicio; por lo tanto, siempre es mejor no instalar
innecesarios
17
Para obtener más información, consulte NIST SP 800-40 versión 2.0, Creación de un programa de administración de parches y vulnerabilidades, que
está disponible en http://csrc.nist.gov/publications/nistpubs/. Se puede implementar un único proceso de administración de parches para los sistemas
operativos y las aplicaciones (incluido el software del servidor web).
18
Para buscar vulnerabilidades en sistemas operativos, servicios y otras aplicaciones, consulte la base de datos nacional de vulnerabilidades (NVD) del
NIST en http://nvd.nist.gov/.
19
Las VLAN se pueden configurar mal fácilmente de manera que reduzcan o eliminen su eficacia como control de seguridad. Las organizaciones que
planean usar VLAN deben asegurarse de que estén configuradas correctamente y que cualquier cambio de configuración se verifique cuidadosamente.
4-2
servicios. Algunos tipos comunes de servicios y aplicaciones que normalmente deben deshabilitarse si no se requieren incluyen los siguientes:
Servicios de uso compartido de archivos e impresoras (p. ej., uso compartido de archivos e impresoras del Sistema básico de entrada/salida
de red de Windows [NetBIOS], Sistema de archivos de red [NFS], Protocolo de transferencia de archivos [FTP])
Servicios de redes inalámbricas
Programas de control remoto y acceso remoto, particularmente aquellos que no encriptan fuertemente sus comunicaciones (por ejemplo,
Telnet)20
Servicios de directorio (p. ej., Protocolo ligero de acceso a directorios [LDAP], Kerberos, Sistema de información de red [NIS])
Servicios de correo electrónico (p. ej., Protocolo simple de transferencia de correo [SMTP])
Compiladores y bibliotecas de lenguaje
Herramientas de desarrollo de sistemas
Herramientas y utilidades de administración de sistemas y redes, incluido el Protocolo simple de administración de redes (SNMP).
Es preferible eliminar servicios y aplicaciones innecesarios que simplemente deshabilitarlos a través de los ajustes de configuración
porque los ataques que intentan alterar la configuración y activar un servicio deshabilitado no pueden tener éxito cuando los componentes
funcionales se eliminan por completo. Los servicios deshabilitados también podrían habilitarse inadvertidamente a través de un error humano.
Eliminar o deshabilitar servicios innecesarios mejora la seguridad de un servidor web de varias maneras
[Alle00]:
Otros servicios no pueden verse comprometidos y utilizados para atacar el host o perjudicar los servicios del servidor web. Cada servicio
agregado a un host aumenta el riesgo de compromiso para ese host porque cada servicio es otra posible vía de acceso para un atacante.
Menos es más seguro en este caso.
Otros servicios pueden tener defectos o ser incompatibles con el propio servidor Web. Al deshabilitarlos o eliminarlos, no deberían afectar al
servidor web y deberían mejorar potencialmente su disponibilidad.
El host se puede configurar para adaptarse mejor a los requisitos del servicio en particular. Diferentes servicios pueden requerir diferentes
configuraciones de hardware y software, lo que podría generar vulnerabilidades innecesarias o afectar negativamente el rendimiento.
Al reducir los servicios, se reduce la cantidad de registros y entradas de registro; por lo tanto, la detección de comportamientos inesperados
se vuelve más fácil (consulte la Sección 9).
Las organizaciones deben determinar los servicios que se habilitarán en un servidor web. Los servicios además del servicio del servidor web que
pueden instalarse incluyen protocolos de acceso a la base de datos, protocolos de transferencia de archivos y
20
Si un programa de control remoto o acceso remoto es absolutamente necesario y no encripta fuertemente sus comunicaciones, debe
canalizarse a través de un protocolo que proporcione encriptación, como Secure Shell (SSH) o IP Security (IPsec). La Sección 7
proporciona información adicional sobre los requisitos para la criptografía.
4-3
servicios de administración remota. Estos servicios pueden ser necesarios en ciertos casos, pero pueden aumentar los
riesgos para el servidor. Si los riesgos superan los beneficios es una decisión que debe tomar cada organización.
4.1.3 Configurar la autenticación de usuario del sistema operativo
Para los servidores web, los usuarios autorizados que pueden configurar el sistema operativo están limitados a un pequeño
número de administradores de servidores web y webmasters designados. Sin embargo, los usuarios que pueden acceder al servidor
web público pueden ser subconjuntos de la comunidad de Internet sin restricciones o restringidos. Para hacer cumplir las restricciones
de la política, si es necesario, el administrador del servidor web debe configurar el sistema operativo para autenticar a un posible
usuario solicitando una prueba de que el usuario está autorizado para dicho acceso. Aunque un servidor web puede permitir el acceso
no autenticado a la mayoría de sus servicios, el acceso administrativo y otros tipos de acceso especializado deben limitarse a
individuos y grupos específicos.
Habilitar la autenticación por parte de la computadora host implica configurar partes del sistema operativo, el firmware y las
aplicaciones en el servidor, como el software que implementa un servicio de red. Aunque normalmente no es el caso de los
servidores web públicos, en situaciones especiales, como sitios de alto valor/alto riesgo, las organizaciones también pueden
usar hardware de autenticación, como tokens o dispositivos de contraseña de un solo uso. Se desaconseja encarecidamente el uso de
mecanismos de autenticación en los que la información de autenticación sea reutilizable (p. ej., contraseñas) y se transmita sin cifrar a
través de una red porque un atacante puede interceptar la información y utilizarla para hacerse pasar por un usuario autorizado.
Para asegurarse de que se cuenta con la autenticación de usuario adecuada, siga los siguientes pasos [Alle00]:
Eliminar o deshabilitar cuentas y grupos predeterminados innecesarios: la configuración predeterminada del sistema
operativo a menudo incluye cuentas de invitado (con y sin contraseña), cuentas de administrador o de nivel raíz y cuentas
asociadas con servicios locales y de red. Los nombres y contraseñas de esas cuentas son bien conocidos. Elimine o deshabilite
las cuentas innecesarias para eliminar su uso por parte de los atacantes, incluidas las cuentas de invitado en las computadoras
que contienen información confidencial. Si no hay ningún requisito para conservar una cuenta o un grupo de invitados, restrinja
severamente el acceso y cambie la contraseña de acuerdo con la política de contraseñas de la organización.
Para las cuentas predeterminadas que deben conservarse, cambie los nombres (siempre que sea posible y en particular para
las cuentas de administrador o raíz) y las contraseñas para que sean coherentes con la política de contraseñas de la organización.
Los nombres de cuenta y las contraseñas predeterminados son comúnmente conocidos en la comunidad de atacantes.
Deshabilitar cuentas no interactivas : deshabilite las cuentas (y las contraseñas asociadas) que deben existir pero que no
requieren un inicio de sesión interactivo. Para los sistemas Unix, deshabilite el shell de inicio de sesión o proporcione un shell
de inicio de sesión con funcionalidad NULL (p. ej., /bin/false).
Crear los grupos de usuarios: asigne usuarios a los grupos apropiados. Luego asigne derechos a los grupos, como se
documenta en el plan de implementación. Este enfoque es preferible a la asignación de derechos a usuarios individuales, que
se vuelve difícil de manejar con un gran número de usuarios.
Cree las cuentas de usuario: el plan de implementación identifica quién estará autorizado para usar cada computadora
y sus servicios. Crea solo las cuentas necesarias. Permitir el uso de cuentas compartidas solo cuando no existan alternativas
viables.
Verifique la política de contraseñas de la organización: configure las contraseñas de las cuentas de manera adecuada.
Esta política debe abordar lo siguiente:
4-4
Longitud: una longitud mínima para las contraseñas. Especifique una longitud mínima de al menos ocho caracteres.
Complejidad: la combinación de caracteres necesaria. Exija que las contraseñas contengan letras mayúsculas y minúsculas y al
menos un carácter no alfabético, y que no sean una palabra del "diccionario".
Antigüedad: cuánto tiempo puede permanecer sin cambios una contraseña. Solicite a los usuarios que cambien sus contraseñas
periódicamente. Las contraseñas de administrador o raíz deben cambiarse cada 30 a 120 días. El período para las contraseñas de
nivel de usuario debe determinarse por la longitud y la complejidad exigidas de la contraseña combinadas con la confidencialidad de la
información protegida. Al considerar la duración adecuada del envejecimiento, también se debe tener en cuenta el nivel de exposición
de las contraseñas de los usuarios. También se debe considerar la aplicación de una duración mínima de antigüedad para evitar que
los usuarios cambien rápidamente de contraseña para borrar su historial de contraseñas y eludir las restricciones de reutilización.
Reutilizar: si se puede reutilizar una contraseña. Algunos usuarios intentan vencer el requisito de caducidad de la
contraseña cambiando la contraseña por una que hayan usado anteriormente. Si es posible, asegúrese de que los usuarios no
puedan cambiar sus contraseñas simplemente agregando caracteres al principio o al final de sus contraseñas originales (por ejemplo,
la contraseña original era "misecreto" y se cambia a "1misecreto" o "misecreto1").
Autoridad: quién puede cambiar o restablecer contraseñas y qué tipo de prueba se requiere antes de iniciar cualquier cambio.
Seguridad de la contraseña: cómo deben protegerse las contraseñas, como no almacenar contraseñas sin cifrar en el
servidor de correo y exigir a los administradores que utilicen contraseñas diferentes para sus cuentas de administración de correo
electrónico que para sus otras cuentas de administración.
Configure las computadoras para evitar que se adivinen las contraseñas: es relativamente fácil para un usuario no autorizado
intentar obtener acceso a una computadora mediante el uso de herramientas de software automatizadas que intentan obtener todas las contraseñas.
Si el sistema operativo proporciona la capacidad, configúrelo para aumentar el período entre los intentos de inicio de sesión con cada intento
fallido. Si eso no es posible, la alternativa es denegar el inicio de sesión después de un número limitado de intentos fallidos (p. ej., tres). Por
lo general, la cuenta se "bloquea" por un período de tiempo (como 30 minutos) o hasta que un usuario con la autoridad adecuada la reactiva.
La opción de denegar el inicio de sesión es otra situación que requiere que el administrador del servidor web tome una decisión que
equilibre la seguridad y la comodidad. La implementación de esta recomendación puede ayudar a prevenir algunos tipos de ataques, pero
también puede permitir que un atacante use intentos de inicio de sesión fallidos para evitar el acceso del usuario, lo que resulta en una
condición DoS. El riesgo de DoS por el bloqueo de la cuenta es mucho mayor si un atacante sabe o puede suponer un patrón en su
convención de nomenclatura que le permite adivinar la cuenta.
nombres
Los intentos fallidos de inicio de sesión en la red no deberían impedir que un usuario o administrador autorizado inicie sesión en la consola.
Tenga en cuenta que todos los intentos fallidos de inicio de sesión, ya sea a través de la red o de la consola, deben registrarse.
Si no se va a implementar la administración remota (consulte la Sección 9.5), deshabilite la capacidad de las cuentas de
administrador o raíz para iniciar sesión desde la red.
Instale y configure otros mecanismos de seguridad para fortalecer la autenticación: si la información en el servidor web
lo requiere, considere usar otros mecanismos de autenticación, como biometría, tarjetas inteligentes, certificados de cliente/servidor o
sistemas de contraseña de un solo uso. Pueden ser más costosos y difíciles de implementar, pero pueden estar justificados en algunas
circunstancias. cuando tal
4-5
se utilizan mecanismos y dispositivos de autenticación, la política de la organización debe cambiarse en consecuencia, si

es necesario. Es posible que algunas políticas de la organización ya requieran el uso de mecanismos de autenticación
sólidos.
Como se mencionó anteriormente, los atacantes que usan rastreadores de red pueden capturar fácilmente las contraseñas que
pasan a través de una red en texto claro. Sin embargo, las contraseñas son económicas y apropiadas si se protegen adecuadamente
durante el tránsito. Las organizaciones deben implementar tecnologías de autenticación y cifrado, como Secure Sockets Layer (SSL)/
Transport Layer Security (TLS), Secure Shell (SSH) o redes privadas virtuales (VPN), para proteger las contraseñas durante la transmisión.
Requerir el uso de una autenticación de servidor fácil de usar con tecnologías de encriptación reduce la probabilidad de éxito de ataques
de suplantación de identidad y de intermediarios.
4.1.4 Configure los controles de recursos adecuadamente
Todos los sistemas operativos de servidor modernos comúnmente utilizados brindan la capacidad de especificar privilegios de acceso
individualmente para archivos, directorios, dispositivos y otros recursos computacionales. Al configurar cuidadosamente los controles de
acceso y negar el acceso no autorizado al personal, el administrador del servidor web puede reducir las infracciones de seguridad
intencionales y no intencionales. Por ejemplo, denegar el acceso de lectura a archivos y directorios ayuda a proteger la confidencialidad de
la información, y denegar el acceso de escritura (modificación) innecesario puede ayudar a mantener la integridad de la información. Limitar
el privilegio de ejecución de la mayoría de las herramientas relacionadas con el sistema a los administradores de sistemas autorizados
puede evitar que los usuarios realicen cambios en la configuración que podrían reducir la seguridad. También puede restringir la capacidad
del atacante de usar esas herramientas para atacar el sistema u otros sistemas en la red.
4.1.5 Instalar y configurar controles de seguridad adicionales
Los sistemas operativos a menudo no incluyen todos los controles de seguridad necesarios para proteger adecuadamente el sistema
operativo, los servicios y las aplicaciones. En tales casos, los administradores deben seleccionar, instalar y configurar software adicional
para proporcionar los controles que faltan. Los controles comúnmente necesarios incluyen los siguientes:
Software antimalware, como software antivirus, software antispyware y detectores de rootkits, para proteger el sistema operativo
local del malware y para detectar y erradicar cualquier infección que ocurra.21 Los ejemplos de cuándo sería útil el software
antimalware incluyen administrador trayendo medios infectados al servidor web y un gusano de servicio de red contactando al servidor
e infectándolo.
Software de detección y prevención de intrusiones basado en host, para detectar ataques realizados contra el servidor web, incluidos
los ataques DoS. La Sección 7.2.2 contiene información adicional sobre el software de detección y prevención de intrusiones basado
en host.
Cortafuegos basados en host, para proteger el servidor de accesos no autorizados.22
Software de administración de parches para garantizar que las vulnerabilidades se aborden con prontitud. El software de administración
de parches se puede usar solo para aplicar parches o también para identificar nuevas vulnerabilidades en los sistemas operativos,
servicios y aplicaciones del servidor web.
21
Hay disponible información adicional sobre software antimalware en NIST SP 800-83, Guía para la prevención y manejo de incidentes de malware (http://csrc.nist.gov/
publications/nistpubs/).
22
Para obtener más información sobre los cortafuegos, consulte NIST SP 800-41, Directrices sobre cortafuegos y política de cortafuegos.
4-6
Algunos administradores de servidores web también instalan una o más formas de detección de intrusiones basadas en host o
software de prevención de intrusiones en sus servidores. Por ejemplo, el software de verificación de integridad de archivos puede
identificar cambios en archivos críticos del sistema.
Al planificar los controles de seguridad, los administradores de servidores web deben tener en cuenta los recursos que
consumirán los controles de seguridad. El rendimiento de un servidor podría degradarse si no tiene suficiente memoria y capacidad de
procesamiento para los controles.
4.2 Pruebas de seguridad del sistema operativo
Las pruebas periódicas de seguridad del sistema operativo son una forma vital de identificar vulnerabilidades y garantizar que las
precauciones de seguridad existentes sean efectivas. Los métodos comunes para probar los sistemas operativos incluyen el análisis de
vulnerabilidades y las pruebas de penetración. El escaneo de vulnerabilidades generalmente implica el uso de un escáner de
vulnerabilidades automatizado para escanear un host o grupo de hosts en una red en busca de vulnerabilidades de aplicaciones, redes
y sistemas operativos. La prueba de penetración es un proceso de prueba diseñado para comprometer una red utilizando las herramientas
y metodologías de un atacante. Implica identificar y explotar iterativamente las áreas más débiles de la red para obtener acceso al resto
de la red, comprometiendo eventualmente la seguridad general de la red.
El escaneo de vulnerabilidades debe realizarse periódicamente, al menos semanalmente o mensualmente, y las pruebas de
penetración deben realizarse al menos una vez al año. Debido a que ambas técnicas de prueba también son aplicables para probar la
23
aplicación del servidor web, se analizan en detalle en la Sección 9.4.
Por lo general, las pruebas no deben realizarse en el propio servidor web de producción. Como se mencionó en la Sección 4.1.1, las
pruebas de parches y cambios en el sistema deben realizarse en un sistema separado; este mismo entorno de prueba debe usarse para
realizar pruebas de seguridad del servidor web.
4.3 Lista de verificación para asegurar el sistema operativo del servidor web
Terminado Acción
Parche y actualice el sistema operativo
Crear, documentar e implementar un proceso de aplicación de parches
Mantenga los servidores desconectados de las redes o en una red aislada que restringe severamente las
comunicaciones hasta que se hayan instalado todos los parches.
Identifique e instale todos los parches y actualizaciones necesarios para el sistema operativo
Identifique e instale todos los parches y actualizaciones necesarios para las aplicaciones y los servicios
incluidos con el sistema operativo
Identifique y mitigue cualquier vulnerabilidad sin parchear
Deshabilite o elimine servicios y aplicaciones innecesarios
Eliminar o deshabilitar cuentas y grupos predeterminados innecesarios
Deshabilitar cuentas no interactivas
Crear los grupos de usuarios para la computadora en particular
Cree las cuentas de usuario para la computadora en particular
Verifique la política de contraseñas de la organización y configure las contraseñas de las cuentas

de manera adecuada (p. ej., longitud, complejidad)
23
Para obtener información sobre otras técnicas de prueba, consulte NIST SP 800-42, Directrices sobre pruebas de seguridad de redes
4-7
Terminado Acción
Evite adivinar la contraseña (p. ej., aumente el período entre intentos, deniegue el inicio de sesión
después de un número definido de intentos fallidos)
Instalar y configurar otros mecanismos de seguridad para fortalecer la autenticación
Configure los controles de recursos de forma adecuada
Denegar el acceso de lectura a archivos y directorios innecesarios
Denegar acceso de escritura a archivos y directorios innecesarios
Limite el privilegio de ejecución de las herramientas del sistema a los administradores del sistema
Seleccione, instale y configure software adicional para proporcionar los controles necesarios no incluidos en
el sistema operativo, como software antivirus, software antispyware, detectores de rootkit, software de
prevención y detección de intrusiones basado en host, firewalls basados en host y software de administración
de parches.
Probar la seguridad del sistema operativo
Identificar un sistema idéntico separado
Pruebe el sistema operativo después de la instalación inicial para determinar las vulnerabilidades
Pruebe el sistema operativo periódicamente (por ejemplo, trimestralmente) para determinar nuevas vulnerabilidades
4-8
5. Protección del servidor web

Una vez que se ha instalado y asegurado el sistema operativo, puede comenzar la instalación del software del servidor web elegido.
Antes de iniciar este proceso, lea atentamente la documentación del fabricante del servidor web y comprenda las diversas opciones
disponibles durante el proceso de instalación. Además, asegúrese de visitar el sitio web del fabricante o un sitio web de base de datos
de vulnerabilidades, como National Vulnerability Database (NVD),24 para determinar si hay vulnerabilidades conocidas y parches
relacionados disponibles que deben instalarse o configurarse como parte de la instalación. proceso. Solo después de realizar estos
pasos preliminares se debe iniciar la instalación. Tenga en cuenta que esta sección trata solo los procedimientos genéricos de
instalación y configuración; las instrucciones específicas para servidores web particulares están disponibles de los fabricantes de
servidores web y de los repositorios de listas de control de seguridad.25
Un servidor parcialmente configurado y/o parcheado no debe exponerse a redes externas (por ejemplo, Internet) ni a
usuarios externos. Además, el acceso a la red interna debe ser lo más limitado posible hasta que todo el software esté instalado,
parcheado y configurado de forma segura. Los servidores web inseguros pueden verse comprometidos en cuestión de minutos
después de conectarse a Internet. Si bien es ideal endurecer completamente la plataforma antes de colocarla en la red, no siempre
es factible. Por ejemplo, algunas combinaciones de herramientas de desarrollo de aplicaciones no pueden instalarse, configurarse
y probarse sobre una configuración de servidor web y sistema operativo previamente reforzada. En tales situaciones, el
endurecimiento gradual o incremental es una opción viable a considerar, con una validación completa del endurecimiento completo
que ocurre en la implementación de producción.
5.1 Instalación segura del servidor web
En muchos aspectos, la instalación y configuración seguras de la aplicación del servidor web refleja el proceso del sistema operativo
analizado en la Sección 4. El principio general, como antes, es instalar solo los servicios necesarios para el servidor web y eliminar
cualquier vulnerabilidad conocida mediante parches o actualizaciones Cualquier aplicación, servicio o script innecesario que esté
instalado debe eliminarse inmediatamente una vez que se complete el proceso de instalación. Durante la instalación del servidor Web,
se deben realizar los siguientes pasos:
Instale el software del servidor web en un host dedicado o en un sistema operativo invitado dedicado si se emplea la
virtualización.
Aplique cualquier parche o actualización para corregir las vulnerabilidades conocidas.
Cree un disco físico dedicado o una partición lógica (independiente del sistema operativo y la aplicación del servidor web)
para el contenido web.
Elimine o deshabilite todos los servicios instalados por la aplicación del servidor web pero que no sean necesarios (p. ej.,
gopher, FTP, administración remota).
Elimine o deshabilite todas las cuentas de inicio de sesión predeterminadas innecesarias creadas por la instalación del servidor web.
Quite toda la documentación de los fabricantes del servidor.
Elimine todos los archivos de ejemplo o de prueba del servidor, incluidos los scripts y el código ejecutable.
24
NVD está disponible en http://nvd.nist.gov/.
25
NIST alberga un repositorio de listas de verificación de seguridad en http://checklists.nist.gov/.
5-1
Aplique la plantilla de seguridad adecuada o el script de refuerzo al servidor.
Vuelva a configurar el banner del servicio HTTP (y otros según sea necesario) para no informar sobre el servidor web y el tipo y la versión del sistema
operativo (esto puede no ser posible con todos los servidores web).
Las organizaciones deben considerar la instalación del servidor web con nombres de directorio, ubicaciones de directorio y nombres de archivo no
estándar. Muchas herramientas de ataque a servidores web y gusanos que se dirigen a servidores web solo buscan archivos y directorios en sus ubicaciones
predeterminadas. Si bien esto no detendrá a determinados atacantes, los obligará a trabajar más duro para comprometer el servidor y también aumenta la
probabilidad de detección de ataques debido a los intentos fallidos de acceder a los nombres de archivo y directorios predeterminados y al tiempo adicional
necesario para realizar un ataque. .
5.2 Configuración de controles de acceso
La mayoría de los sistemas operativos de host de servidor web brindan la capacidad de especificar privilegios de acceso individualmente para
archivos, dispositivos y otros recursos computacionales en ese host. Cualquier información a la que el servidor web pueda acceder usando estos controles
puede potencialmente distribuirse a todos los usuarios que accedan al sitio web público. Es probable que el software del servidor web incluya mecanismos para
proporcionar controles adicionales de acceso a archivos, dispositivos y recursos específicos para su funcionamiento. Es importante establecer permisos
idénticos tanto para el sistema operativo como para la aplicación del servidor web; de lo contrario, se puede otorgar demasiado o muy poco acceso a los
usuarios. Los administradores de servidores web deben considerar la mejor manera de configurar los controles de acceso para proteger la información
almacenada en los servidores web públicos desde dos perspectivas:
Limite el acceso de la aplicación del servidor web a un subconjunto de recursos informáticos.
Limite el acceso de los usuarios a través de controles de acceso adicionales aplicados por el servidor web, donde se requieren niveles de control de
acceso más detallados.
La configuración adecuada de los controles de acceso puede ayudar a prevenir la divulgación de información confidencial o restringida que no está destinada a
la difusión pública. Además, los controles de acceso se pueden utilizar para limitar el uso de recursos en caso de un ataque DoS contra el servidor web. Del
mismo modo, los controles de acceso pueden imponer la separación de funciones al garantizar que los administradores del servidor web no puedan modificar
los registros del servidor web y, potencialmente, garantizar que el proceso del servidor web solo pueda agregarse a los archivos de registro.
Los archivos típicos a los que se debe controlar el acceso son los siguientes:
Software de aplicación y archivos de configuración
Archivos relacionados directamente con los mecanismos de seguridad:
Archivos hash de contraseñas y otros archivos utilizados en la autenticación
Archivos que contienen información de autorización utilizada para controlar el acceso
Material de clave criptográfica utilizado en servicios de confidencialidad, integridad y no repudio
Registro del servidor y archivos de auditoría del sistema
Software del sistema y archivos de configuración
Archivos de contenido web.
5-2
5.2.1 Configuración de los permisos de la aplicación del servidor web
Es vital que la aplicación del servidor web se ejecute únicamente bajo una identidad individual única de usuario y grupo con controles de acceso
muy restrictivos.26 Se deben establecer nuevas identidades de usuario y grupo para uso exclusivo del software del servidor web. El nuevo usuario
y el nuevo grupo deben ser independientes de todos los demás usuarios y grupos y únicos. Este es un requisito previo para implementar los
controles de acceso descritos en los siguientes pasos. Durante la inicialización, es posible que el servidor deba ejecutarse con privilegios de root
(Unix) o administrador/sistema (Windows) para vincularse a los puertos del Protocolo de control de transmisión (TCP) numerados por debajo de
1024 (80 y 443 son los puertos predeterminados para HTTP y HTTPS). Asegúrese de que el servidor web esté configurado para reducir sus
privilegios a los del usuario del servidor web después de realizar sus funciones de inicialización.
Además, utilice el sistema operativo del servidor web para limitar a qué archivos pueden acceder los procesos de servicio del servidor
web. Estos procesos deben tener acceso de solo lectura a los archivos necesarios para realizar el servicio y no deben tener acceso a otros
archivos, como los archivos de registro del servidor. Utilice los controles de acceso del sistema operativo del host del servidor web para aplicar lo
siguiente [Koss00]:
Los procesos de servicio están configurados para ejecutarse como un usuario con un conjunto estrictamente limitado de privilegios
(es decir, no se ejecutan como root, administrador o equivalente).
Los procesos de servicio pueden leer, pero no escribir, los archivos de contenido web.
Los procesos de servicio no pueden escribir en los directorios donde se almacena el contenido web público.
Solo los procesos autorizados para la administración del servidor web pueden escribir archivos de contenido web.
La aplicación del servidor web puede escribir archivos de registro del servidor web, pero la aplicación del servidor web no puede leer los
archivos de registro. Solo los procesos de nivel raíz/sistema/administrativo pueden leer los archivos de registro del servidor web.
Los archivos temporales creados por la aplicación del servidor web, como los que pueden generarse en la creación de páginas web
dinámicas o por los usuarios que cargan contenido, están restringidos a un subdirectorio específico y debidamente protegido (si es posible).
El acceso a los archivos temporales creados por la aplicación del servidor web está limitado a los procesos del servidor web que
crearon los archivos (si es posible).
También es necesario asegurarse de que la aplicación del servidor web no pueda guardar (o, en algunos casos, leer) archivos fuera de la
estructura de archivos específica dedicada al contenido web público. Esto puede ser una elección de configuración en el software del servidor,
o puede ser una elección de cómo el sistema operativo controla el proceso del servidor. Asegúrese de que no se pueda acceder a dichos
directorios y archivos (fuera del árbol de directorios especificado), incluso si los usuarios realizan una exploración directa accediendo a las URL
de esos archivos o mediante ataques transversales de directorio contra el proceso del servidor web.
Para mitigar los efectos de ciertos tipos de ataques DoS, configure el servidor web para limitar la cantidad de recursos del sistema operativo
que puede consumir. Algunos ejemplos incluyen:
26
En los sistemas Unix, un servidor web normalmente se asigna a su propio grupo único. En Windows, la configuración de grupos
específicos puede depender del servidor web instalado. Por ejemplo, el usuario de Apache 2.0 en Windows debe ser miembro del grupo Usuarios.
Hay más información disponible en http://httpd.apache.org/docs/2.0/platform/windows.html.
5-3
Instalar contenido web en una unidad de disco duro o partición lógica diferente a la del sistema operativo y la aplicación del
servidor web.
Poner un límite a la cantidad de espacio en el disco duro que se dedica a las cargas, si se permiten las cargas al servidor web.
Idealmente, las cargas deben colocarse en una partición separada para brindar una mayor seguridad de que no se puede exceder el
límite del disco duro.
Si se permite la carga en el servidor web, asegúrese de que el servidor web no pueda leer estos archivos hasta que se utilice algún
proceso de revisión automático o manual para examinarlos. Esta medida evita que el servidor web se utilice para propagar malware o
traficar software pirateado, herramientas de ataque, pornografía, etc. También es posible limitar el tamaño de cada archivo cargado, lo
que podría limitar los efectos potenciales de un ataque DoS que implique cargar muchos archivos grandes
Asegurarse de que los archivos de registro se almacenen en una ubicación que tenga el tamaño adecuado. Idealmente, los archivos de
registro deben almacenarse en una partición separada. Si un ataque hace que el tamaño de los archivos de registro aumente más allá
de los límites aceptables, una partición física ayuda a garantizar que el servidor web tenga suficientes recursos para manejar la situación
de manera adecuada.
Configurar el número máximo de procesos del servidor web y/o conexiones de red que debe permitir el servidor web.
Hasta cierto punto, estas acciones protegen contra ataques que intentan llenar el sistema de archivos en el sistema operativo host del servidor
web con información extraña e incorrecta que puede hacer que el sistema se bloquee. La información de registro generada por el sistema
operativo del host del servidor web puede ayudar a reconocer tales ataques. Como se discutió en la Sección 9.1, los administradores deben
almacenar registros del servidor web en servidores de registro centralizados siempre que sea posible y también almacenar registros localmente
si es factible. Si un ataque hace que el servidor web se vea comprometido, el atacante podría modificar o borrar los registros almacenados
localmente para ocultar información sobre el ataque. Mantener una copia de los registros en un servidor de registro centralizado brinda a los
administradores más información para usar cuando investigan un compromiso de este tipo.
Además de los controles mencionados anteriormente, a menudo es necesario configurar tiempos de espera y otros controles para reducir aún
más el impacto de ciertos ataques DoS. Un tipo de ataque DoS aprovecha los límites prácticos de las conexiones de red simultáneas al
establecer rápidamente conexiones hasta el máximo permitido, de modo que ningún nuevo usuario legítimo pueda obtener acceso. Al configurar
los tiempos de espera de conexión de red (el tiempo después del cual se interrumpe una conexión inactiva) a un límite de tiempo mínimo
aceptable, las conexiones establecidas se agotarán lo más rápido posible, abriendo nuevas conexiones a usuarios legítimos. Esta medida solo
mitiga los efectos; no derrota el ataque.
Si la cantidad máxima de conexiones abiertas (o conexiones que están medio abiertas, es decir, la primera parte del protocolo de enlace TCP
fue exitosa) se establece en un número bajo, un atacante puede consumir fácilmente las conexiones disponibles con solicitudes ilegítimas (a
menudo llamadas una inundación SYN). Establecer el máximo en un número mucho más alto puede mitigar el efecto de tal ataque, pero a
expensas de consumir recursos adicionales.
Tenga en cuenta que esto es solo un problema para los servidores web que no están protegidos por un firewall que detenga los ataques de
inundación SYN. La mayoría de los firewalls de nivel empresarial protegen los servidores web de las inundaciones SYN al interceptarlos
antes de que lleguen a los servidores web.
5.2.2 Configuración del directorio de contenido web seguro
No utilice enlaces, alias ni accesos directos en el árbol de directorios de archivos de contenido web público que apunten a directorios o archivos
en otro lugar del host del servidor o del sistema de archivos de la red. Si es posible, deshabilite la capacidad de la Web
5-4
software de servidor para seguir enlaces y alias. Como se indicó anteriormente, los archivos de registro y de configuración del servidor web
deben residir fuera del árbol de directorios de archivos especificado para el contenido web público.
Se requieren los siguientes pasos para restringir el acceso a un árbol de directorio de archivos de contenido web específico:
Dedique un único disco duro o partición lógica para el contenido web y establezca subdirectorios relacionados exclusivamente para
los archivos de contenido del servidor web, incluidos los gráficos pero excluyendo las secuencias de comandos y otros programas.
Defina un único árbol de directorios exclusivamente para todos los scripts o programas externos ejecutados como parte del contenido
web (p. ej., CGI, Active Server Page [ASP], PHP).
Deshabilite la ejecución de scripts que no estén exclusivamente bajo el control de cuentas administrativas.
Esta acción se logra creando y controlando el acceso a un directorio separado destinado a contener scripts autorizados.
Deshabilite el uso de enlaces duros o simbólicos.
Definir una matriz completa de acceso al contenido web. Identifique qué carpetas y archivos dentro del documento del servidor web
deben restringirse y cuáles deben ser accesibles (y por quién).
La mayoría de los proveedores de software de servidor web proporcionan directivas o comandos que permiten al administrador web
restringir el acceso de los usuarios a los archivos de contenido del servidor web público. Por ejemplo, el software del servidor web Apache
proporciona una directiva <Limit>, que permite al administrador web restringir qué funciones de acceso opcionales (como Nuevo, Eliminar,
Conectar, Encabezar y Obtener) están asociadas con cada archivo de contenido web; se permitirá cualquier método HTTP omitido de la
directiva <Limit>. Dentro de la directiva <Limit>, los administradores pueden especificar los requisitos que se deben cumplir para que se
permita la acción limitada. La directiva Apache Require permite al administrador web restringir el contenido disponible a usuarios autenticados
o grupos.
Muchas directivas o comandos se pueden anular por directorio. La conveniencia de poder hacer excepciones locales a la política global se ve
contrarrestada por la amenaza de que se introduzca un agujero de seguridad en un subdirectorio distante, que podría estar controlado por un
usuario hostil. El administrador web debe deshabilitar la capacidad de un subdirectorio para anular las directivas de seguridad de nivel superior
a menos que esa anulación sea absolutamente necesaria.
En la mayoría de los casos, las listas de directorios de archivos del servidor web deben estar deshabilitadas. El HTTP especifica que
una URL que termina en un carácter de barra diagonal se trate como una solicitud de una lista de los archivos en el directorio con ese nombre.
Se debe prohibir que los servidores web respondan a dichas solicitudes con una lista de archivos, incluso si el público puede leer todos los
archivos del directorio. Tales solicitudes a menudo indican un intento de localizar información por medios distintos a los previstos por el
administrador del sitio web o el administrador del sitio web. Los usuarios pueden intentar esto si tienen dificultades para navegar por el sitio o
si un enlace parece estar roto. Los intrusos pueden intentar esto para localizar información oculta por la interfaz del sitio web. Los
administradores web deben investigar las solicitudes de este tipo que se encuentran en los archivos de registro del servidor web (consulte la
Sección 9).
5.2.3 Identificadores uniformes de recursos y cookies
Los identificadores uniformes de recursos (URI) son la tecnología de dirección a partir de la cual se crean las URL.
Técnicamente, las URL (p. ej., http://www.mywww.gov) son un subconjunto de las URI. Hay una serie de problemas de seguridad que
surgen de los URI. Debido a que los URI se envían sin cifrar, los datos almacenados en ellos pueden verse fácilmente comprometidos. Por
ejemplo, los URI se registran en numerosas ubicaciones, incluidos los registros del navegador web (es decir, el historial del navegador), los
registros del servidor proxy y los registros de referencia HTTP de terceros. Por lo tanto, ocultar datos confidenciales como
5-5
como nombres de usuario y contraseñas o recursos de servidor ocultos en URI no se recomienda. La seguridad a través de la oscuridad no es segura.
Los URI a menudo se incluyen con el contenido web público. Aunque es posible que estos URI no se muestren como contenido web en el navegador web
de un usuario, se pueden descubrir fácilmente en el código fuente. Por lo tanto, ningún contenido web de servicio público debe incluir URI confidenciales
ocultos en el código fuente. Muchos atacantes y bots maliciosos (consulte la Sección 5.2.4) buscan en el código fuente información confidencial de URI,
que incluye:
Correos electrónicos
Imágenes en otros servidores
Enlaces a otros servidores
Expresiones de texto particulares (por ejemplo, ID de usuario, contraseña, raíz, administrador)
Valores de formulario ocultos
Hipervínculos.
Una cookie es una pequeña pieza de información que se puede escribir en el disco duro del usuario cuando visita un sitio web. La intención de las cookies
es permitir que los servidores reconozcan un navegador específico (usuario). En esencia, agregan estado al protocolo HTTP sin estado. Debido a que las
cookies generalmente se envían en claro y se almacenan en claro en el host del usuario, son vulnerables al compromiso. Hay vulnerabilidades conocidas
en ciertas versiones de Internet Explorer, por ejemplo, que permiten que un sitio web malintencionado recopile de forma remota todas las cookies de un
visitante sin el conocimiento del visitante. Por lo tanto, las cookies nunca deben contener datos que puedan ser utilizados directamente por un atacante (por
ejemplo, nombre de usuario, contraseña). OMB M-00-1327 establece explícitamente que los sitios web federales no deben usar cookies a menos que exista
una necesidad imperiosa de recopilar datos en el sitio, y solo con las aprobaciones, notificaciones y medidas de seguridad adecuadas. Para los sitios web
que necesitan mantener la información de la sesión, el identificador de la sesión se puede pasar como parte de la URL al sitio web en lugar de almacenarse
como una cookie. Independientemente de si se usan cookies o no, se debe usar SSL/TLS para evitar que los atacantes obtengan información de los
mensajes HTTP enviados a través de la red y la usen para secuestrar la sesión de un usuario.
5.2.4 Control del impacto de los "bots" web en los servidores web
Los bots web (también conocidos como rastreadores o arañas) son aplicaciones de software que se utilizan para recopilar, analizar e indexar contenido
web. Los bots web son utilizados por numerosas organizaciones para muchos propósitos. Algunos ejemplos incluyen:
MSNBot, Slurp y Googlebot analizan, indexan y registran lenta y cuidadosamente sitios web para motores de búsqueda web como Windows Live
Search, Yahoo! y Google.
Google utiliza Mediabot para analizar el contenido publicado por una página de AdSense para que se proporcionen anuncios contextualmente
relevantes.
Los "validadores" de hipervínculos son utilizados por los webmasters para validar automáticamente los hipervínculos en su sitio web.
27
OMB M-00-13, Office of Management and Budget Memorandum 2000-13, 2000, está disponible
en http://www.whitehouse.gov/omb/memoranda/m00-13.html.
5-6
EmailSiphon y Cherry Picker son bots diseñados específicamente para rastrear sitios web en busca de direcciones de correo electrónico (e-mail)
para agregarlas a las listas de correo no deseado. Estos son ejemplos comunes de bots que pueden tener un impacto negativo en un sitio web o
en sus usuarios.
Muchos robots de spam rastrean sitios web en busca de formularios de inicio de sesión para crear direcciones de correo electrónico gratuitas
desde las que enviar spam o enviar spam a blogs, libros de visitas, wikis y foros para mejorar la clasificación en los motores de búsqueda de
un sitio web en particular.
Los raspadores de pantalla recuperan contenido de sitios web para colocar una copia en otro servidor. Estas copias se pueden usar para phishing
o para intentar generar ingresos publicitarios al hacer que los usuarios visiten la copia.
Algunos bots malintencionados rastrean sitios web en busca de aplicaciones vulnerables que contengan datos confidenciales (por ejemplo,
números de seguridad social [SSN], datos de tarjetas de crédito).
Los bots pueden representar un desafío para la administración de los servidores por parte de los webmasters porque:
Los servidores web a menudo contienen directorios que no necesitan ser indexados.
Es posible que las organizaciones no deseen que parte de su sitio aparezca en los motores de búsqueda.
Los servidores web a menudo contienen páginas temporales que no deben indexarse.
Las organizaciones que operan el servidor web están pagando por el ancho de banda y quieren excluir robots y arañas que no benefician
sus objetivos.
Los bots no siempre están bien escritos o tienen buenas intenciones y pueden llegar a un sitio web con solicitudes extremadamente
rápidas, lo que provoca una reducción en la capacidad de respuesta o DoS total para los usuarios legítimos.
Los bots pueden descubrir información que el webmaster preferiría que se mantuviera en secreto o al menos no publicitada (por
ejemplo, direcciones de correo electrónico).
Afortunadamente, los administradores web o el webmaster pueden influir en el comportamiento de la mayoría de los bots en su sitio web. Se ha creado
una serie de acuerdos denominados Protocolo de Exclusión de Robots (REP). Aunque REP no es un estándar oficial de Internet, es compatible con la
mayoría de los bots mejor escritos y bien intencionados, incluidos los que utilizan la mayoría de los principales motores de búsqueda.
Los administradores web que deseen limitar las acciones de los bots en su servidor web deben crear un archivo de texto sin formato llamado
"robots.txt". El archivo siempre debe tener este nombre y debe residir en el directorio de documentos raíz del servidor Web. Además, sólo se
permite un archivo por sitio web. Tenga en cuenta que el archivo robots.txt es un estándar admitido voluntariamente por los programadores de bots,
por lo que los bots malintencionados (como EmailSiphon y Cherry Picker) a menudo ignoran este archivo.28
El archivo robots.txt es un archivo de texto simple que contiene algunas palabras clave y especificaciones de archivo. Cada línea del archivo está en
blanco o consta de una sola palabra clave y su información relacionada. Las palabras clave se utilizan para decirle a los robots qué partes de un sitio
web están excluidas.
28
Existen otros métodos para controlar bots maliciosos; sin embargo, cambian constantemente a medida que los operadores de bots
maliciosos y los administradores web desarrollan nuevos métodos para contrarrestar las técnicas de los demás. Dada la naturaleza en
constante cambio de esta área, la discusión de estas técnicas está más allá del alcance de este documento. Hay más información disponible
en http://www.onguardonline.gov/spam.html.
5-7
Se permiten las siguientes palabras clave:
User-agent es el nombre del robot o araña. Un administrador web también puede incluir más de un nombre de agente si se
aplica la misma exclusión a cada bot especificado. La entrada no distingue entre mayúsculas y minúsculas (en otras palabras,
"googlebot" es lo mismo que "GOOGLEBOT" y "GoogleBot").
Un asterisco ("*") indica un registro "predeterminado", que se aplica si no se encuentra ninguna otra coincidencia. Por ejemplo,
si especifica solo "GoogleBot", entonces el "*" se aplicaría a cualquier otro robot.
Disallow le dice a los bots especificados en el campo de agente de usuario qué secciones del sitio web están excluidas.
Por ejemplo, /images informa al bot que no abra ni indexe ningún archivo en el directorio de imágenes ni en ningún
subdirectorio. Por lo tanto, el directorio "/images/special/" no sería indexado por los bots excluidos.
Tenga en cuenta que "/hacer" coincide con cualquier directorio que comience con "/hacer" (por ejemplo, /hacer, /documento, /
docs, etc.), mientras que "/hacer/" coincide solo con el directorio llamado "/hacer/". Un administrador web también puede
especificar archivos individuales para su exclusión. Por ejemplo, el administrador web podría especificar "/mydata/help.html"
para evitar que los bots solo accedan a ese archivo. Un valor de solo "/" indica que los bots especificados no pueden acceder
a nada en el sitio web.
Debe existir al menos un rechazo por registro de agente de usuario.
Hay muchas formas de usar el archivo robots.txt. Algunos ejemplos simples son los siguientes:
Para prohibir todos los bots (compatibles) de directorios específicos:
*
Agente de usuario:
No permitir: /imágenes/
No permitir: /banners/
No permitir: /Formularios/
No permitir: /Diccionario/
No permitir: /_bordes/
No permitir: /_fpclass/
No permitir: /_overlay/
No permitir: /_privado/
No permitir: /_temas/
Para prohibir todos los bots (compatibles) de todo el sitio web:
*
Agente de usuario:
No permitir: /
Para prohibir que un bot específico (en este caso, Googlebot) examine una página web específica:
Agente de usuario:
GoogleBot Disallow: tempindex.htm
Tenga en cuenta que el archivo robots.txt está disponible para todos y no proporciona mecanismos de control de acceso a los
archivos no permitidos. Por lo tanto, un administrador web no debe especificar los nombres de archivos o carpetas confidenciales
porque los atacantes suelen analizar los archivos robots.txt para guiar sus investigaciones iniciales de los sitios web. Si se deben
excluir archivos o directorios, es mejor usar páginas protegidas con contraseña a las que los bots no puedan acceder.
5-8
La protección con contraseña es la única forma confiable de excluir bots que no cumplen o usuarios curiosos. Consulte la Sección 7 para obtener más
información sobre los métodos de autenticación basados en la Web.
A menudo, los spambots ignoran robots.txt y buscan direcciones de correo electrónico en el sitio web y/o formularios a los que pueden enviar contenido
relacionado con spam. Los spambots que simplemente escanean el sitio web generalmente no afectan su disponibilidad. Sin embargo, puede ser
beneficioso evitar que recopilen direcciones de correo electrónico mediante la manipulación de direcciones [Unsp06]: mostrar las direcciones de correo
electrónico en un formato legible por humanos alternativo, como enumerar nombre@mywww.gov como <nombre en mywww dot gobierno>.
Desafortunadamente, estas técnicas no detienen a todos los spambots. La mejor defensa contra la recopilación de direcciones es no mostrar las
direcciones de correo electrónico.
Los robots de spam que buscan formularios web para enviar contenido relacionado con spam son una amenaza directa para el sitio web.
Pueden afectar la imagen de la organización si los visitantes ven el contenido enviado como un respaldo. También pueden afectar la disponibilidad del
sitio web al dificultar que los usuarios encuentren el contenido necesario.
Hay varias técnicas disponibles para reducir la cantidad de envíos de spam, que incluyen:
Bloqueo de envíos de formularios que utilizan palabras clave relacionadas con el spam
Usar la palabra clave rel=“nofollow” en todos los enlaces enviados, lo que hará que los motores de búsqueda omitan los enlaces en sus algoritmos
de clasificación de páginas, lo que afectará directamente los objetivos de un robot de spam [Google05]
Solicitar a los remitentes que resuelvan una prueba de Turing pública completamente automatizada para diferenciar a las computadoras de
los humanos (CAPTCHA) antes de que se les permita enviar contenido.
Todas estas técnicas tienen beneficios e inconvenientes asociados con ellas. Por ejemplo, algunas técnicas de CAPTCHA, que se pueden implementar
como una palabra oculta en una imagen, no cumplen con las pautas de accesibilidad de la Asociación Estadounidense de Discapacidades (ADA) o la
Sección 508. Se puede encontrar información sobre investigaciones en curso sobre la detección de spambots a través de los talleres Adversarial
Information Retrieval on the Web (AIRWeb).29
5.3 Lista de verificación para asegurar el servidor web
Terminado Acción
Instalar de forma segura el servidor web
Instale el software del servidor web en un host dedicado o en un sistema operativo invitado virtualizado dedicado
Aplique cualquier parche o actualización para corregir las vulnerabilidades conocidas
Cree un disco físico dedicado o una partición lógica (separada del sistema operativo y la aplicación del servidor web) para
el contenido web
Elimine o deshabilite todos los servicios instalados por la aplicación del servidor web pero no requeridos (por ejemplo,
gopher, FTP, administración remota)
Elimine o deshabilite todas las cuentas de inicio de sesión predeterminadas innecesarias creadas por la instalación
del servidor web
Eliminar toda la documentación del fabricante del servidor
Elimine cualquier ejemplo o archivos de prueba del servidor, incluidos los scripts y el código ejecutable
Aplique la plantilla de seguridad adecuada o el script de refuerzo al servidor
29
El sitio web de AIRWeb 2006 está disponible en http://airweb.cse.lehigh.edu/2006.
5-9
Terminado Acción
Vuelva a configurar el banner del servicio HTTP (y otros según sea necesario) para NO informar sobre el servidor web y el tipo
y la versión del sistema operativo
Configure los controles de acceso al sistema operativo y al servidor web
Configure el proceso del servidor web para que se ejecute como un usuario con un conjunto estrictamente limitado de privilegios
Configure el servidor web para que los procesos de servicio puedan leer pero no escribir los archivos de contenido web.
Configure el servidor web para que los procesos de servicio no puedan escribir en los directorios donde se almacena el
contenido web público.
Configure el servidor web para que solo los procesos autorizados para la administración del servidor web puedan
escribir archivos de contenido web.
Configure el sistema operativo host para que el servidor web pueda escribir archivos de registro pero no leerlos.
Configure el sistema operativo host para que los archivos temporales creados por la aplicación del servidor web estén restringidos
a un subdirectorio específico y debidamente protegido.
Configure el sistema operativo host para que el acceso a los archivos temporales creados por la aplicación del servidor web se
limite a los procesos de servicio que crearon los archivos.
Instale contenido web en una unidad de disco duro o partición lógica diferente a la del sistema operativo y la aplicación del
servidor web
Si se permiten cargas al servidor web, configúrelo para que se establezca un límite en la cantidad de espacio del disco duro
que se dedica a este fin; las cargas deben colocarse en una partición separada
Asegúrese de que los archivos de registro se almacenen en una ubicación que tenga el tamaño adecuado; los archivos de
registro deben colocarse en una partición separada
Configurar el número máximo de procesos del servidor web y/o conexiones de red que debe permitir el servidor web
Asegúrese de que todos los sistemas operativos invitados virtualizados sigan esta lista de verificación
Asegúrese de que los usuarios y administradores puedan cambiar las contraseñas
Deshabilitar usuarios después de un período específico de inactividad
Asegúrese de que cada usuario y administrador tenga una identificación única
Configurar un directorio de contenido web seguro
Dedique un solo disco duro o partición lógica para el contenido web y establezca subdirectorios relacionados exclusivamente
para los archivos de contenido del servidor web, incluidos los gráficos, pero sin incluir los scripts y otros programas. Defina un solo
directorio exclusivamente para todos los scripts o programas externos ejecutados como parte del contenido del servidor web (p.
ej. , CGI, ASP)
Deshabilite la ejecución de scripts que no estén exclusivamente bajo el control de cuentas administrativas. Esta
acción se logra creando y controlando el acceso a un directorio separado destinado a contener secuencias de comandos
autorizadas Inhabilite el uso de enlaces físicos o simbólicos (por ejemplo, accesos directos para Windows)
Definir una matriz completa de acceso al contenido web. Identifique qué carpetas y archivos dentro del documento del servidor
web deben restringirse y cuáles deben ser accesibles (y por quién)
Verifique la política de contraseñas de la organización y configure las contraseñas de las cuentas de manera adecuada (p.
ej., longitud, complejidad)
Use el archivo robots.txt, si corresponde. Configure
la protección anti-spambot, si corresponde (p. ej., CAPTCHA, nofollow o filtrado de palabras clave).
5-10
6. Protección del contenido web
Los dos componentes principales de la seguridad web son la seguridad de la aplicación de servidor subyacente y el sistema
operativo, y la seguridad del contenido real. De estos, la seguridad del contenido a menudo se pasa por alto.
El mantenimiento de una seguridad de contenido efectiva tiene dos componentes. La más obvia es no colocar ninguna
información privada, clasificada u otra información confidencial en un servidor web de acceso público, a menos que se hayan
tomado otras medidas para proteger la información a través de la autenticación y el cifrado del usuario (consulte la Sección 7).
El componente menos obvio de la seguridad del contenido es evitar compromisos causados por la forma en que se procesan
determinados tipos de contenido en un servidor. A medida que las organizaciones han mejorado en la protección y el
fortalecimiento de sus perímetros de red, sistemas operativos y servidores web, los atacantes recurren cada vez más a la
explotación de vulnerabilidades en las aplicaciones web y la forma en que se procesa la información en los servidores web.
Estos ataques a la capa de aplicación aprovechan los elementos interactivos de los sitios web.
6.1 Publicación de información en sitios web públicos
Con demasiada frecuencia, se presta poca atención a las implicaciones de seguridad del contenido colocado en el sitio web.
Muchas organizaciones no tienen un proceso o una política de publicación web que determine qué tipo de información publicar
abiertamente, qué información publicar con acceso restringido y qué información debe omitirse de cualquier repositorio de acceso
público. Esto es problemático porque los sitios web suelen ser uno de los primeros lugares en los que las entidades maliciosas
buscan información valiosa. Por ejemplo, los atacantes a menudo leen el contenido del sitio web de una organización objetivo para
recopilar inteligencia antes de cualquier ataque [Scam01]. Además, los atacantes pueden aprovechar el contenido disponible en
un sitio web para crear un ataque de ingeniería social o utilizar la información de identificación de las personas en el robo de
identidad [FTC06].
En ausencia de razones de peso, un sitio web público no debe contener la siguiente información:
registros clasificados
Normas y procedimientos internos de personal
Información sensible o propietaria
Información personal sobre el personal o los usuarios de una organización30
Domicilios y números de teléfono
Información de identificación única, particularmente SSN
Material biográfico detallado (que podría emplearse para la ingeniería social)
miembros de la familia del personal
Números de teléfono, direcciones de correo electrónico31 o listados generales del personal, a menos que sea necesario para
cumplir con los requisitos de la organización
30
Para las agencias federales, esto incluiría todos los elementos cubiertos por la Ley de Privacidad de
1974 (http://www.usdoj.gov/04foia/privstat.htm). Esto abarca la información de identificación personal (PII, por sus siglas en inglés), que
es información que se puede usar para identificar, ubicar o contactar a una persona de manera única.
31
Cuando se deba publicar una dirección de correo electrónico en un sitio web, considere el uso de direcciones de correo electrónico o alias
genéricos (por ejemplo, webmaster@mydomain.gov en lugar de jane_doe@mydomain.gov). Hay dos razones para hacer esto. uno, publicado
6-1
Horarios de los directores de la organización o su ubicación exacta (ya sea dentro o fuera de las instalaciones)
Información sobre la composición o preparación de materiales peligrosos o toxinas32
Registros de investigación
Registros financieros (más allá de los que ya están disponibles públicamente)
Registros médicos
Los procedimientos de seguridad física y de la información de la organización.
Información sobre la red de la organización y la infraestructura del sistema de información (p. ej., intervalos de direcciones,
convenciones de nomenclatura, números de acceso)
Planos, mapas, diagramas, fotografías aéreas y planos arquitectónicos de edificios, propiedades o instalaciones
organizacionales
Información sobre planes de recuperación ante desastres o de continuidad de las operaciones, excepto cuando sea absolutamente necesario
Detalles sobre los procedimientos de respuesta a emergencias, las rutas de evacuación o el personal de la organización responsable
de estos problemas
Material protegido por derechos de autor sin el permiso por escrito del propietario.
Políticas de privacidad o seguridad que indican los tipos de medidas de seguridad implementadas en la medida en que pueden ser
útiles para un atacante.
Las organizaciones no deben utilizar servidores web públicos para alojar información confidencial a la que solo deben acceder los
usuarios internos. El compromiso de un servidor web público a menudo conduce al compromiso de dichos datos.
Para garantizar un enfoque coherente, una organización debe crear una política y un proceso formales para determinar y
aprobar la información que se publicará en un servidor web. En muchas organizaciones, esta es responsabilidad del CIO y/o del oficial
de asuntos públicos. Tal proceso debe incluir los siguientes pasos:
Identificar la información que debe ser publicada en la Web
Identificar el público objetivo (¿Por qué publicar si no existe público?)
Identificar posibles ramificaciones negativas de publicar la información.
las direcciones de correo electrónico son mucho más propensas a recibir spam. Dos, las direcciones de correo electrónico de identificación personal pueden
proporcionar información útil a un atacante (p. ej., posibles nombres de usuario, información para intentos de ingeniería social).
32
Para obtener más orientación sobre la protección de este tipo de información, consulte el Memorando de la Casa Blanca del 19 de marzo de 2000, Acción para
salvaguardar la información sobre armas de destrucción masiva y otros documentos confidenciales relacionados con la seguridad nacional (http://www.usdoj.gov/
oip /foiapost/2002foiapost10.htm).
6-2
Identificar quién debería ser responsable de crear, publicar y mantener esta información en particular.
Crear o dar formato a la información para la publicación web
Revisar la información para los controles de confidencialidad y distribución/liberación (incluida la confidencialidad de la

información en conjunto)
Determinar los controles de acceso y seguridad apropiados.
Publicar información
Verificar la información publicada
Revise periódicamente la información publicada para confirmar el cumplimiento continuo de las pautas organizacionales.
Cualquier política o proceso para determinar y aprobar la información a publicar en un servidor Web puede beneficiarse del uso de
herramientas automatizadas. Las herramientas pueden escanear el contenido entrante en busca de palabras clave, formato o
metadatos, y marcarlo para su revisión, aliviando la carga de aquellos que deben verificar el contenido. De manera similar, un
sistema automatizado interno que permite a los usuarios publicar material potencial en un sitio web interno y notifica al personal
de aprobación (posiblemente por correo electrónico) de la publicación permite que el material se revise y se publique en el sitio
web público más rápidamente a través de un proceso repetible. . El uso de un sistema automatizado también ayuda a la rendición
de cuentas porque los registros rastrean quién envió el documento y quién lo aprobó.
Un área del contenido web que a menudo se pasa por alto es la información que a veces se oculta dentro del código fuente de
una página web. Esta información se puede ver desde cualquier navegador web utilizando la opción de menú "ver código fuente".
El código fuente puede, por ejemplo, contener puntos de contacto y revelar partes de la estructura de directorios del servidor web.
Las organizaciones a menudo no prestan atención al contenido del código fuente en sus sitios web, aunque este código puede
contener información confidencial. Los atacantes examinan no sólo el contenido obvio del sitio web, sino también los detalles
dentro del código fuente. Por lo tanto, los administradores web o los webmasters deben revisar periódicamente el código en su
servidor web público.
6.2 Cumplimiento de las normas sobre la recopilación de información personal
Las leyes y regulaciones federales y estatales se aplican a la recopilación de información del usuario en sitios web
gubernamentales de acceso público. Además, muchas agencias gubernamentales tienen pautas de privacidad que abordan el
tipo de información que se podría recopilar sobre los usuarios. Las organizaciones gubernamentales con sitios web deben estar
al tanto de las leyes, reglamentos y pautas de la agencia correspondientes y aplicables. Es posible que las organizaciones
privadas deseen utilizar estas pautas y ejemplos de buenas prácticas de seguridad, pero deben consultar al asesor legal
apropiado y a sus funcionarios de privacidad para conocer las implicaciones legales y políticas aplicables. Sin embargo, las
leyes federales, los reglamentos y las pautas de las agencias aplicables sí se aplican a las organizaciones comerciales que
operan sitios web en nombre de las agencias federales. Las organizaciones deben estar al tanto de los cambios en los requisitos
legales, reglamentarios y contractuales y buscar el asesoramiento de expertos en políticas y leyes.
Las agencias federales que recopilan PII deben hacerlo de acuerdo con la ley federal y la Constitución. La Ley de Privacidad,
por ejemplo, requiere que las agencias minimicen la información recopilada a lo que es
6-3
relevante y necesario para el propósito comercial,33 y, en muchos casos, para recopilar información, en la mayor medida posible,
directamente del sujeto individual.34 Además, las prácticas aceptadas (muchas de las cuales se reflejan en las leyes aplicables tanto a
los instituciones públicas) deben proporcionar a los sujetos:
Tenga en cuenta que se recopila información sobre ellos, incluidas descripciones de qué datos se recopilan, con quién se
comparte y qué se hace con esos datos.
Oportunidades para cancelar la recopilación de datos a menos que la recopilación de datos sea obligatoria por ley,
necesaria para la ejecución de un contrato con la persona en cuestión, o si la persona ha ofrecido libremente su PII
Oportunidades para acceder y revisar los registros que se mantienen sobre ellos mismos y para solicitar correcciones o adiciones,
especialmente si esa información se puede usar para tomar una determinación sobre los derechos, oportunidades o beneficios de
las personas.
Los siguientes son ejemplos de información personal:
Nombre
Dirección de correo electrónico
Dirección de envio
Número de teléfono
Número de Seguro Social
Información financiera.
Las agencias federales y muchas agencias estatales también tienen restringida su capacidad para usar cookies de navegador web
[OMB00a, OMB00b, OMB00c y MASS99]. Una cookie es una pequeña pieza de información que se puede escribir en el disco duro de
un usuario cuando se visita un sitio web. Hay dos tipos principales de cookies:
Las cookies persistentes causan la mayor preocupación. Estas cookies se pueden utilizar para rastrear las actividades de los usuarios
a lo largo del tiempo y en diferentes sitios web. El uso más común de las cookies persistentes es retener y correlacionar información
sobre los usuarios entre sesiones. Las agencias federales y muchas agencias estatales generalmente tienen prohibido usar cookies
persistentes en sitios web de acceso público.
Las cookies de sesión son válidas para una sola sesión (visita) a un sitio web. Estas cookies caducan al final de la sesión o dentro
de un período de tiempo limitado. Debido a que estas cookies no se pueden usar para rastrear información personal, generalmente
no están sujetas a la prohibición que se aplica a las cookies persistentes.
Sin embargo, su uso debe estar claramente establecido y definido en la declaración de privacidad del sitio web.
33
“Cada agencia que mantenga un sistema de registros deberá….mantener en sus registros solo la información sobre un individuo que sea
relevante y necesaria para lograr un propósito de la agencia requerido por ley o por orden ejecutiva del presidente”. Ley de Privacidad, 5
USC § 552a(e)(1), http://www.usdoj.gov/oip/privstat.htm.
34
“Cada agencia que mantenga un sistema de registros deberá…. recopilar información en la mayor medida posible directamente de la
persona en cuestión cuando la información pueda dar lugar a determinaciones adversas sobre los derechos, beneficios y privilegios de
una persona en virtud de los programas federales”. Ley de Privacidad, 5 USC § 552a(e)(2), http://www.usdoj.gov/oip/privstat.htm.
6-4
6.3 Mitigación de ataques indirectos al contenido
Los ataques de contenido indirecto no son ataques directos a un servidor web o su contenido; implican medios indirectos para obtener
información de los usuarios que normalmente visitan el sitio web mantenido en el servidor web.
El tema común de estos ataques es obligar a los usuarios a visitar un sitio web malicioso creado por el atacante y divulgar información
personal creyendo que el sitio que visitaron es el sitio web legítimo. Si bien los clientes de comercio electrónico e instituciones financieras a
menudo son el objetivo, tales ataques no se limitan a esos sitios web. Además de adquirir información personal relacionada con el sitio web
objetivo, los ataques también pueden dirigirse contra la computadora del usuario desde el sitio web malicioso visitado. Los tipos de ataques
indirectos descritos en esta sección son phishing y pharming.
6.3.1 Suplantación de identidad
Los atacantes de phishing utilizan técnicas de ingeniería social para engañar a los usuarios para que accedan a un sitio web falso y divulguen
información personal. En algunos ataques de phishing, los atacantes envían un correo electrónico que parece legítimo pidiendo a los usuarios
que actualicen su información en el sitio web de la empresa, pero las URL del correo electrónico en realidad apuntan a un sitio web falso.35
Otros ataques de phishing pueden ser más avanzados . y aprovechar las vulnerabilidades en la aplicación del sitio web legítimo.36
Aunque el phishing no se puede prevenir por completo a través de medios técnicos empleados en un servidor web, muchas técnicas pueden
reducir la probabilidad de que los usuarios de un sitio web se vean atraídos por un ataque de phishing37
[Ollm04]:
Asegurar la conciencia del cliente sobre los peligros de los ataques de phishing y cómo evitarlos. La Comisión Federal de Comercio (FTC)
ha publicado una alerta para el consumidor que describe los pasos que los usuarios deben seguir [FTC06a]:
No responda mensajes de correo electrónico ni anuncios emergentes que soliciten información personal o financiera.
No confíe en los números de teléfono en correos electrónicos o anuncios emergentes. La tecnología de Voz sobre Protocolo de Internet
se puede utilizar para registrar un teléfono con cualquier código de área.
Utilice software antivirus, antispyware y cortafuegos. Estos pueden detectar malware en la máquina de un usuario que
participa en un ataque de phishing.
No envíe por correo electrónico información personal o financiera.
Revise los estados de cuenta bancarios y de tarjetas de crédito con regularidad.
Tenga cuidado al acceder a sitios web que no son de confianza porque algunas vulnerabilidades de los navegadores web pueden
explotarse simplemente visitando dichos sitios. Los usuarios también deben tener cuidado al abrir cualquier archivo adjunto o
descargar cualquier archivo de correos electrónicos o sitios web que no sean de confianza.
Reenviar correos electrónicos relacionados con phishing a spam@uce.gov ya la organización que se suplanta en el correo electrónico.
35
NIST SP 800-45 versión 2, Directrices sobre la seguridad del correo electrónico, contiene información sobre la detección de correos electrónicos de
phishing. Está disponible en http://csrc.nist.gov/publications/nistpubs/.
36
Un ejemplo de un ataque de phishing avanzado ocurrió en el sitio web de PayPal [Netcraft06].
37
Las organizaciones deben asegurarse de que sus usuarios internos también conozcan estas técnicas para que puedan evitar el phishing.
ataques dirigidos a ellos.
6-5
Solicite una copia de su informe crediticio anualmente de cada una de las tres agencias de informes crediticios: Equifax,
TransUnion y Experian. Si un ladrón de identidad abre cuentas a su nombre, es probable que aparezca en su informe de
crédito.38
Validar la comunicación oficial personalizando los correos electrónicos y brindando información de identificación única
que solo la organización y el usuario deben conocer. Sin embargo, la información confidencial no debe ser divulgada.
Uso de firmas digitales en el correo electrónico. Sin embargo, es posible que la aplicación de correo electrónico del usuario no valide
automáticamente las firmas digitales.
Realización de validación de contenido dentro de la aplicación Web. Las vulnerabilidades en las aplicaciones web de la organización
pueden utilizarse en un ataque de phishing.
Personalización del contenido web, que puede ayudar a los usuarios a identificar un sitio web fraudulento.
Usar la autenticación mutua o basada en tokens en el sitio web para evitar que los phishers reutilicen la información de autenticación
anterior para hacerse pasar por el usuario.
La mayoría de los navegadores web brindan cierto nivel de protección contra el phishing. Todos los navegadores web informan a los
usuarios cuando visitan un sitio seguro a través de un candado o algún otro mecanismo GUI, y también informan a los usuarios si la
dirección del Sistema de nombres de dominio (DNS) visitada no coincide con la del certificado de Infraestructura de clave pública (PKI).
Sin embargo, los sitios de phishing a menudo usan direcciones DNS que son similares a las de los sitios originales y que tienen un
certificado PKI válido, lo que los hace más difíciles de detectar. En tales casos, un navegador web notificaría al usuario del peligro solo si
el sitio fuera un sitio conocido de phishing. Los navegadores pueden descargar periódicamente una lista negra de phishing del sitio web
del fabricante del navegador o comparar todas las solicitudes web con una base de datos antiphishing. Las organizaciones deben utilizar
las funciones antiphishing proporcionadas por el navegador web cuando corresponda. Además, varios proveedores ofrecen soluciones y
servicios antiphishing más avanzados [APWG07]:
Supervisión y prevención de dominios primos: los proveedores (principalmente registradores de nombres de dominio)
supervisan y, en algunos casos, impiden la creación de nombres de dominio similares a los de organizaciones que pueden estar
sujetas a ataques de phishing.
Detección y análisis de ataques: los proveedores monitorean el correo electrónico y la comunicación web para descubrir
campañas de phishing en curso para que las organizaciones puedan tomar las respuestas adecuadas.
Eliminación: los proveedores ayudan a limitar el acceso al sitio web de phishing.
Análisis de fraude : los proveedores supervisan el acceso al sitio web de la organización en busca de posibles intentos de fraude
(como los phishers que intentan utilizar las credenciales capturadas) o supervisan la Web en busca de un uso fraudulento de la
identidad de una organización.
Servicios forenses: después del descubrimiento de un ataque de phishing exitoso, los proveedores ayudan a abordar los
problemas que surgen como resultado del ataque.
38
Según la Ley de Transacciones de Crédito Justas y Precisas de 2003, los consumidores pueden solicitar un informe de crédito gratuito de cada una
de las tres compañías de informes de crédito del consumidor una vez cada 12 meses. Consulte http://www.ftc.gov/os/statutes/fcrajump.shtm para
obtener más información.
6-6
Barras de herramientas del consumidor : los proveedores proporcionan complementos de navegador que pueden proporcionar o aumentar la
detección de phishing disponible en los navegadores de los usuarios.
Autenticación de correo electrónico: los proveedores brindan soluciones seguras de correo electrónico que permiten a los usuarios
discernir si un correo electrónico es de la propia organización o si es un posible ataque de phishing.
Filtrado de correo electrónico: los proveedores brindan soluciones para evitar que los usuarios internos de una organización
reciban correos electrónicos de phishing.
Filtrado web: los proveedores supervisan las solicitudes web salientes de una organización y evitan que los usuarios accedan a sitios web
de phishing conocidos o sospechosos.
Autenticación: los proveedores brindan soluciones de autenticación sólidas que son menos susceptibles a los ataques de
phishing.
Habilitación para el cumplimiento de la ley: los proveedores ayudan a las organizaciones a ponerse en contacto con los
funcionarios encargados de hacer cumplir la ley para ayudar a cerrar y procesar los ataques de phishing.
Al contemplar medidas antiphishing, es importante considerar el tipo de información que se aloja en el sitio web. Es posible que los sitios web
con poca o ninguna información confidencial no necesiten implementar medidas antiphishing más avanzadas o costosas. Los sitios web que
almacenan PII deben considerar seriamente implementar medidas antiphishing más sólidas.
6.3.2 Farmacia
Los atacantes de pharming utilizan medios técnicos, en lugar de ingeniería social, para redirigir a los usuarios para que accedan a un sitio web
falso que se hace pasar por uno legítimo y divulga información personal. El pharming normalmente se logra mediante la explotación de
vulnerabilidades en el software DNS, que se utiliza para convertir nombres de dominio de Internet legibles por humanos en direcciones IP, o
mediante la alteración de los archivos de host mantenidos en una computadora cliente para resolver localmente los nombres de dominio de
Internet. En cualquier caso, el sistema afectado resuelve incorrectamente los nombres legítimos en la dirección del sitio web malicioso. Varias
técnicas pueden ayudar a reducir la probabilidad de que los usuarios de un sitio web se vean involucrados en un ataque pharming [Ollm05]:
Uso de las versiones actuales del software DNS con los últimos parches de seguridad aplicados: un servidor DNS comprometido
permitirá a los atacantes dirigir a los usuarios a un servidor malicioso mientras mantienen un nombre DNS legítimo.
Instalación de mecanismos de protección de DNS del lado del servidor contra el pharming: existen herramientas disponibles para
mitigar las amenazas al software de DNS, como las Extensiones de seguridad de DNS; estos se analizan en NIST SP 800-81, Guía de
39
implementación del sistema de nombres de dominio (DNS) seguro.
Supervisión de dominios de la organización y registro de dominios similares: los ataques de pharming pueden aprovecharse de
los usuarios que escriben mal el nombre de dominio de la organización cuando acceden al sitio.
Simplificación de la estructura y la cantidad de nombres de dominio de la organización: si una organización tiene una estructura de
nombres complicada para sus servidores, se vuelve cada vez más difícil para los usuarios discernir si se encuentran en un sitio ilegítimo. Por
ejemplo, muchas organizaciones harán que los usuarios inicien sesión en una
39
NIST SP 800-81, Guía de implementación del sistema seguro de nombres de dominio (DNS), está
disponible en http://csrc.nist.gov/publications/nistpubs/
6-7
URL, como https://www.organization.org/, pero luego rediríjalos a otra URL, como https://www.secure-organization.org/. Un usuario
redirigido a https://www.secured-organization.org/ puede no notar el ataque.
Uso de conexiones seguras (es decir, HTTPS) para inicios de sesión, lo que permite a los usuarios verificar que los certificados
del servidor sean válidos y estén asociados con un sitio web legítimo: los navegadores modernos notificarán al usuario si el nombre DNS
no coincide con el proporcionado por el certificado. pero algunos sitios de pharming podrían tener un certificado legítimo.40
Garantizar la concienciación del usuario sobre los peligros de los ataques de pharming y cómo evitarlos:
Pharming es un fenómeno reciente; Es posible que muchos usuarios no sepan que deben estar atentos a los ataques de pharming.
Verificación de la resolución del host de terceros: varios proveedores ofrecen complementos de navegadores web de terceros41 que
admiten la comparación de la dirección del Protocolo de Internet (IP) de un sitio web con una dirección IP "buena" previamente verificada, lo
que proporciona a los usuarios una advertencia si el sitio Web es sospechoso.
Uso de secretos previamente compartidos: los secretos previamente compartidos se pueden usar para evitar ataques de pharming. Una
implementación común de los secretos precompartidos es hacer que los usuarios autorizados configuren ciertas preguntas y respuestas que
solo ellos deben saber. Además, el sitio web proporciona a cada usuario una imagen y/o frase específica que solo él y el usuario conocen.
Posteriormente, cuando un usuario inicia sesión en el sitio web, se le hace una de las preguntas secretas. Si el usuario responde correctamente,
se le presenta la imagen/frase secreta y solo entonces se le solicita una contraseña. Dado que un sitio de pharming no conocería esos secretos
previamente compartidos y no podría responder en consecuencia, debería ser reconocible como un sitio malicioso.
La principal desventaja de usar secretos precompartidos es que la aceptación del usuario puede ser baja debido al trabajo que implica
configurar los secretos e iniciar sesión en un sitio. Además, es posible que algunos usuarios no reconozcan los datos que faltan y usen el sitio
pharming de todos modos.
Muchas de las técnicas utilizadas para prevenir ataques de phishing, particularmente en ofertas comerciales, son relevantes para prevenir
ataques de pharming. Al igual que con las soluciones antiphishing, cuando se contemplan medidas antipharming, es importante considerar el
tipo de información alojada en el sitio web. Es posible que los sitios web con poca o ninguna información confidencial no necesiten implementar
medidas contra el pharming más avanzadas o costosas. Los sitios web que almacenan PII deben considerar seriamente la implementación de medidas
antipharming más sólidas. Requerir una autenticación sólida puede reducir en gran medida el riesgo de ataques exitosos de phishing y pharming.
6.4 Protección del contenido activo y las tecnologías de generación de contenido
En los primeros días de la Web, la mayoría de los sitios presentaban páginas de lenguaje de marcado de hipertexto (HTML) estáticas y textuales.
No se produjo interactividad entre el usuario y el sitio web más allá de que el usuario hiciera clic en los hipervínculos.
Poco después, se introdujeron varios tipos de elementos interactivos que ofrecían a los usuarios nuevas formas de
40
En enero de 2001, VeriSign emitió dos certificados de firma de código de Clase 3 a una persona que afirmaba ser un empleado de Microsoft (http://
www.microsoft.com/technet/security/bulletin/ms01-017.mspx). Con certificados TLS disponibles por menos de $20 con poca o ninguna verificación de
antecedentes, cada vez es más fácil para los atacantes adquirir certificados TLS válidos. mientras es
posible que las autoridades de certificación (CA) revoquen certificados, la mayoría de los navegadores no están configurados para realizar la verificación
de la lista de revocación de certificados. La Sección 7.5 proporciona más información sobre TLS.
41
Un complemento es un programa que funciona junto con un navegador web para mejorar las capacidades del navegador. Un navegador generalmente
solicita al usuario que descargue un nuevo complemento cuando se encuentra contenido que requiere una funcionalidad más allá de las capacidades
existentes del navegador.
6-8
interactuar más dinámicamente con los sitios Web. Desafortunadamente, estos elementos interactivos introdujeron muchas vulnerabilidades
relacionadas con la Web que siguen siendo motivo de preocupación en la actualidad.42
El contenido activo se refiere a elementos de programas interactivos descargados al cliente (es decir, un navegador web) y procesados allí en lugar
del servidor. Existe una variedad de tecnologías de contenido activo; algunos de los ejemplos más populares son ActiveX, Java, VBScript, JavaScript
y Asynchronous JavaScript and XML (AJAX). El uso de contenido activo a menudo requiere que los usuarios reduzcan la configuración de seguridad
en sus navegadores web para que se produzca el procesamiento. Si no se implementa correctamente, el contenido activo puede presentar una seria
amenaza para el usuario final. Por ejemplo, el contenido activo puede realizar acciones de forma independiente sin el conocimiento o consentimiento
expreso del usuario. Si bien el contenido activo representa un riesgo para el cliente, también puede presentar un riesgo para el servidor web. La razón
es que la información procesada en el cliente está bajo el control del usuario, quien potencialmente puede manipular los resultados mediante ingeniería
inversa y manipulación del contenido activo. Por ejemplo, el procesamiento de validación de formularios realizado con elementos de contenido activo
en el lado del cliente se puede cambiar para devolver opciones fuera de rango u otros resultados inesperados al servidor. Por lo tanto, el servidor no
debe confiar en los resultados del procesamiento realizado en el cliente por elementos de contenido activo; en su lugar, los resultados deben ser
verificados por el servidor. Las organizaciones que consideren la implementación de contenido activo del lado del cliente deben considerar
cuidadosamente los riesgos tanto para sus usuarios como para sus servidores web.
Los generadores de contenido son programas en un servidor web que generan dinámicamente páginas HTML para los usuarios; estas páginas pueden
generarse utilizando información recuperada de un servidor de fondo, como una base de datos o un directorio, o posiblemente una entrada
proporcionada por el usuario. Algunos de los primeros generadores de contenido fueron scripts CGI ejecutados por el servidor web cuando se solicitaba
una URL específica. Por el contrario, algunos generadores de contenido modernos son un componente integral de los servidores en los que se
ejecutan, como los servidores de aplicaciones Java Enterprise Edition (Java EE). Debido a que los generadores de contenido se implementan en el
servidor, pueden abrir el propio servidor web a las amenazas. El peligro con los generadores de contenido ocurre cuando aceptan ciegamente la
entrada de los usuarios y la aplican a las acciones realizadas en el servidor web. Si el generador de contenido no se implementó correctamente para
restringir la entrada, un atacante puede ingresar ciertos tipos de información que pueden afectar negativamente al servidor web o comprometer su
seguridad. Por ejemplo, un ataque común contra los generadores de contenido es la inyección de lenguaje de consulta estructurado (SQL). En este
tipo de ataque, una entidad maliciosa envía información especialmente diseñada al generador de contenido. La entrada incluye una cadena de
comando SQL específica que, cuando se envía sin filtrar a un servidor de base de datos SQL, potencialmente devuelve al atacante parte o toda la
información almacenada en la base de datos. Las inyecciones de SQL y otros ataques se utilizan para ejecutar comandos u obtener acceso no
autorizado al servidor web o a un servidor de base de datos back-end.
Todos los sitios web que implementan contenido activo y generadores de contenido deben realizar pasos adicionales para proteger el contenido
activo contra riesgos. Es posible que estos pasos, que se analizan en las siguientes secciones, no se apliquen a todas las instalaciones; por lo tanto,
deben utilizarse como orientación junto con la documentación del fabricante correspondiente.
También se requiere precaución especial para descargar scripts o ejecutables preprogramados de Internet.
Muchos administradores web y webmasters se sienten tentados a ahorrar tiempo descargando código disponible gratuitamente de Internet.
Aunque esto es obviamente conveniente, no está exento de riesgos. Hay muchos ejemplos de códigos maliciosos que se distribuyen de esta
manera. En general, no se deben instalar scripts de terceros en un servidor web a menos que un experto de confianza los someta primero a una
revisión exhaustiva del código.
Las revisiones del código de seguridad también deben considerarse para el contenido de los servidores web que son críticos para la
organización o que están altamente amenazados.
42
Para obtener pautas más detalladas sobre contenido activo, consulte NIST SP 800-28 Versión 2, Pautas sobre contenido
activo y código móvil (http://csrc.nist.gov/publications/nistpubs/).
6-9
6.4.1 Vulnerabilidades con tecnologías de contenido activo del lado del cliente
Cada tecnología de contenido activo tiene sus propias fortalezas y debilidades; ninguno es perfectamente seguro. Algunas de las
tecnologías de contenido activo más populares y sus riesgos asociados se analizan a continuación. Las nuevas tecnologías están
surgiendo todo el tiempo y las tecnologías más antiguas se mejoran continuamente. Cualquier administrador web o webmaster que esté
considerando implementar un sitio web con funciones que requieran tecnología de contenido activo en el lado del cliente debe sopesar
cuidadosamente los riesgos y beneficios de la tecnología antes de la implementación. El riesgo relativo de las tecnologías de contenido
activo cambia con el tiempo, lo que complica esta tarea. Sin embargo, los riesgos comunes para el servidor web prevalecen con todas las
tecnologías de contenido activo.
Debido a que estas tecnologías implican colocar el código de la aplicación en el cliente, un atacante puede intentar aplicar ingeniería
inversa al código para comprender cómo funciona con el sitio web de una organización y explotar esa relación. Por ejemplo, confiar
únicamente en las comprobaciones de validación de entrada realizadas en el cliente por el contenido activo y no volver a validar la entrada
en el servidor web permitiría a un atacante utilizar una herramienta o editor de proxy HTTP para modificar los elementos de contenido
activo y omitir cualquiera o todos. comprobaciones realizadas.
Java es un lenguaje de programación orientado a objetos con todas las funciones compilado en un código de bytes independiente de la
plataforma ejecutado por un intérprete llamado Java Virtual Machine (JVM). El código de bytes resultante se puede ejecutar cuando se
compila o se transfiere a otra plataforma habilitada para Java (p. ej., se transmite a través de una página web HTML como un
subprograma). Java es útil para agregar funcionalidad a los sitios web. Muchos servicios ofrecidos por varios sitios web populares
requieren que el usuario tenga un navegador habilitado para Java. Cuando el navegador web ve referencias al código Java, carga el
código y lo procesa utilizando la JVM integrada o una instalada por el usuario.
El lenguaje de programación Java y el entorno de tiempo de ejecución refuerzan la seguridad principalmente a través de una fuerte
seguridad de tipo, mediante la cual un programa puede realizar ciertas operaciones solo en ciertos tipos de objetos. Java sigue el llamado
modelo de seguridad sandbox, utilizado para aislar la memoria y el acceso a métodos y para mantener dominios de ejecución mutuamente
excluyentes. El código Java, como un subprograma web, está confinado a un "sandbox", que está diseñado para evitar que realice
operaciones no autorizadas, como inspeccionar o cambiar archivos en un sistema de archivos del cliente y usar conexiones de red para
eludir las protecciones de archivos o los usuarios. expectativas de privacidad. El código de bytes de Java descargado al cliente se puede
descompilar en una forma más legible para el usuario, lo que lo hace susceptible a ingeniería inversa y posible modificación, lo que
representa una amenaza para el servidor web.
Los subprogramas hostiles también pueden representar amenazas de seguridad para el cliente, incluso mientras se ejecutan dentro de
la zona de pruebas. Un subprograma hostil puede consumir o explotar los recursos del sistema de manera inapropiada, o puede hacer
que un usuario realice una acción no deseada o no deseada. Los ejemplos de vulnerabilidades de subprogramas hostiles incluyen DoS,
falsificación de correo, invasión de la privacidad (p. ej., exportación de identidad, dirección de correo electrónico e información de la
plataforma) e instalación de puertas traseras en el sistema. Debido a que el modelo de seguridad de Java es bastante complejo, puede ser
difícil de entender y administrar para un usuario. Esta situación puede aumentar el riesgo. Además, también se han encontrado muchos
errores de implementación, lo que permite eludir los mecanismos de seguridad [NIST01].
JavaScript es un lenguaje de secuencias de comandos multiplataforma de propósito general, cuyo código se puede incrustar en páginas
web estándar para crear documentos interactivos. El nombre JavaScript es inapropiado porque el lenguaje tiene poca relación con la
tecnología Java y se desarrolló de forma independiente. En el contexto del navegador web, JavaScript es extremadamente poderoso, lo
que permite que los scripts preparados realicen esencialmente las mismas acciones que podría realizar un usuario. Dentro de ese
contexto, JavaScript carece de métodos para acceder directamente a un sistema de archivos del cliente o para abrir conexiones
directamente a computadoras que no sean el host que proporcionó la fuente de contenido. El navegador normalmente limita la ejecución
de un script a la página desde la que se descargó [NIST01].
6-10
En teoría, limitar un lenguaje de secuencias de comandos a los límites de un navegador web debería proporcionar un entorno
relativamente seguro. En la práctica, este no ha sido el caso. Muchos ataques contra los navegadores se derivan del uso de un
lenguaje de secuencias de comandos en combinación con la explotación de una vulnerabilidad de seguridad. Las fuentes de la
mayoría de los problemas han sido dos: la prevalencia de fallas de implementación en el entorno de ejecución y la vinculación
estrecha del navegador con otras funciones, como un cliente de correo electrónico. Los exploits anteriores incluyen el envío de la
lista del historial de URL de un usuario a un sitio remoto y el uso de la dirección de correo del usuario para falsificar correos
electrónicos [NIST01]. Un atacante también puede leer y analizar JavaScript del lado del cliente para identificar posibles
vulnerabilidades en el servidor web.
Adobe Flash es un complemento de navegador para los principales navegadores web que brinda soporte para mejorar la
animación y la interactividad. Aunque los complementos como Flash permiten que los navegadores admitan nuevos tipos de
contenido, no son contenido activo en sí mismos, sino simplemente una tecnología de habilitación de contenido activo. El
complemento Flash permite que los navegadores admitan gráficos vectoriales y rasterizados, transmisión de audio y video, y
ActionScript, un lenguaje de programación similar a JavaScript que se usa para controlar las animaciones Flash. Varias versiones
de Flash contienen fallas de seguridad que permiten la ejecución remota de código, lo que requiere que los usuarios apliquen
parches al complemento.
Adobe Shockwave es un complemento de navegador similar a Adobe Flash pero más robusto. Shockwave proporciona un
motor de renderizado más rápido y admite gráficos tridimensionales acelerados por hardware, gráficos en capas y protocolos de
red. Si bien Flash se usa ampliamente para animaciones web y películas, Shockwave se usa comúnmente para juegos. Al igual
que con Flash, varias versiones de Shockwave contienen fallas de seguridad que permiten la ejecución remota de código, lo que
requiere que los usuarios apliquen parches al complemento.
AJAX es una colección de tecnologías que permite a los desarrolladores web mejorar los tiempos de respuesta entre las páginas
web. El código JavaScript se comunica con el servidor web y modifica dinámicamente el contenido de la página del navegador
web sin depender del servidor web para enviar una respuesta con el marcado XML para toda la página. En su lugar, solo se
transmite la parte necesaria de los datos XML afectados. AJAX permite que el contenido web se comporte más como las
aplicaciones tradicionales, al mismo tiempo que reduce potencialmente la carga en el servidor web. Sin embargo, existen varios
problemas de seguridad con AJAX:
AJAX crea una superficie de ataque más grande que las aplicaciones web tradicionales al aumentar la cantidad de puntos
donde un cliente interactúa con la aplicación.
AJAX puede revelar detalles de funciones internas dentro de la aplicación web.
Es posible que algunos puntos finales de AJAX no requieran autenticación y, en cambio, dependan del estado actual
de la aplicación [SPID06].
Visual Basic Script (VBScript) es un lenguaje de programación desarrollado por Microsoft para crear scripts que se pueden
incrustar en páginas web para verlos con el navegador Internet Explorer. Sin embargo, otros navegadores no necesariamente
admiten VBScript. Al igual que JavaScript, VBScript es un lenguaje interpretado que puede procesar scripts del lado del cliente.
VBScript, que es un subconjunto del lenguaje de programación Microsoft Visual Basic, funciona con controles Microsoft ActiveX.
El lenguaje es similar a JavaScript y presenta riesgos similares.
ActiveX es un conjunto de tecnologías de Microsoft que proporciona herramientas para vincular aplicaciones de escritorio a la
Web. Los controles ActiveX son objetos de programas de componentes reutilizables que pueden adjuntarse a un correo
electrónico o descargarse de un sitio web. Los controles ActiveX también vienen preinstalados en las plataformas Windows. Las
páginas web invocan controles ActiveX utilizando un lenguaje de secuencias de comandos o con una etiqueta HTML OBJECT.
Los controles ActiveX son objetos de programa compilados, lo que dificulta su lectura y la ingeniería inversa.
6-11
A diferencia del modelo de espacio aislado de Java, que restringe los permisos de los subprogramas a un conjunto de acciones seguras,
ActiveX no impone restricciones sobre lo que puede hacer un control. En cambio, los controles ActiveX están firmados digitalmente por sus autores bajo
un esquema de tecnología llamado Authenticode. Las firmas digitales se verifican mediante certificados de identidad emitidos por una autoridad de
certificación de confianza a un editor de software ActiveX, que debe comprometerse a que ningún código dañino se distribuirá a sabiendas bajo este
esquema. El proceso de Authenticode garantiza que los controles ActiveX no se puedan distribuir de forma anónima y que se pueda detectar la
manipulación de los controles. Sin embargo, este proceso de certificación no garantiza que un control se comportará bien [NIST01]. Se han informado
vulnerabilidades en los controles clave de ActiveX, incluidos los componentes instalados por aplicaciones populares como Microsoft Office.
6.4.2 Vulnerabilidades con tecnologías de generación de contenido del lado del servidor
A diferencia de las tecnologías anteriores, CGI, ASP .NET, Java EE y otras interfaces de servidor similares se encuentran en el lado del servidor
(Web) del modelo cliente-servidor. Los usos comunes de la ejecución del lado del servidor incluyen [Ziri02]:
Acceso a la base de datos
Aplicaciones de comercio electrónico/gobierno electrónico
Salas de chat
Grupos de discusión encadenados.
Las aplicaciones del lado del servidor se pueden escribir en muchos lenguajes de programación para ejecutarse en un servidor web. Sin embargo, si
las secuencias de comandos y los componentes no se preparan con cuidado, los atacantes pueden encontrar y aprovechar fallas en el código para
penetrar el servidor web o los componentes de back-end, como un servidor de base de datos. Por lo tanto, los scripts deben escribirse teniendo en
cuenta la seguridad; por ejemplo, no deben ejecutar comandos arbitrarios en un sistema o iniciar programas inseguros. Un atacante puede encontrar
fallas a través de prueba y error y no necesariamente necesita el código fuente del script para descubrir vulnerabilidades [NIST01].
Los generadores de contenido del lado del servidor pueden crear las siguientes vulnerabilidades de seguridad en el servidor:
Pueden filtrar, de forma intencionada o no, información sobre la aplicación del servidor web y el sistema operativo host que puede ayudar a un
atacante, por ejemplo, al permitir el acceso a información fuera de las áreas designadas para el uso de la web.
Al procesar entradas proporcionadas por el usuario, como el contenido de un formulario, parámetros de URL o una consulta de búsqueda,
pueden ser vulnerables a ataques en los que el usuario engaña a la aplicación para que ejecute comandos arbitrarios proporcionados en el
flujo de entrada (por ejemplo, cross-site secuencias de comandos o inyección SQL).
Pueden permitir a los atacantes desfigurar o modificar el contenido del sitio.
Idealmente, las aplicaciones del lado del servidor deberían restringir a los usuarios a un pequeño conjunto de funcionalidades bien definidas y
validar el tamaño y los valores de los parámetros de entrada para que un atacante no pueda sobrepasar los límites de la memoria o aprovechar
comandos arbitrarios para su ejecución. Las aplicaciones deben ejecutarse únicamente con privilegios mínimos (es decir, no de administrador) para
evitar comprometer todo el sitio web. Sin embargo, se pueden aprovechar posibles agujeros de seguridad, incluso cuando las aplicaciones se ejecutan
con una configuración de privilegios bajos, por lo que esta opción solo debe usarse como último recurso. Por ejemplo, una secuencia de comandos
subvertida podría tener suficientes privilegios para enviar por correo el archivo de contraseña del sistema, examinar los mapas de información de la red
o iniciar un inicio de sesión en un puerto con un número alto.
6-12
Las áreas de vulnerabilidad mencionadas afectan potencialmente a todos los servidores web. Aunque estas vulnerabilidades han ocurrido con
frecuencia con aplicaciones CGI, otras interfaces y técnicas relacionadas para desarrollar aplicaciones de servidor no han sido inmunes. CGI,
siendo un estándar temprano y bien soportado, simplemente ganó más atención a lo largo de los años, y existen las mismas áreas de vulnerabilidad
cuando se aplican tecnologías de desarrollo web similares.
Los scripts CGI fueron el mecanismo inicial utilizado para hacer que los sitios web interactúen con las bases de datos y otras aplicaciones.
Sin embargo, a medida que la Web evolucionó, se desarrollaron métodos de procesamiento del lado del servidor que son más eficientes y fáciles de
programar; por ejemplo, Microsoft proporciona ASP.NET para sus servidores IIS, Sun/Netscape admite servlets de Java y el software gratuito PHP es
compatible con la mayoría de las principales plataformas web, incluidas Apache e IIS [NIST01]. Algunos puntos importantes a considerar al contemplar
el despliegue de CGI [Ziri02]:
El sistema de archivos host (consulte la Sección 4.1) proporciona seguridad para CGI.
La mayoría de los servidores permiten restricciones CGI por directorio.
CGI en sí proporciona poca aplicación de seguridad.
Perl facilita la programación segura que la mayoría de los demás lenguajes (p. ej., C, C++, sh) no facilitan.
Los envoltorios CGI disponibles de terceros ofrecen protección adicional para CGI.
El lado del servidor incluye (SSI) es un lenguaje de secuencias de comandos del lado del servidor limitado admitido por la mayoría de los servidores web.
SSI proporciona un conjunto de funciones dinámicas, incluida la hora actual o la última fecha de modificación del archivo HTML, como
alternativa al uso de un programa CGI para realizar la función. Cuando el navegador solicita un documento con un tipo de archivo especial, como
".shtml", hace que el servidor trate el documento como una plantilla, leyendo y analizando todo el documento antes de enviar los resultados al cliente
(navegador web). Los comandos SSI están incrustados dentro de los comentarios HTML (p. ej., ). A medida que el servidor lee el archivo de plantilla, busca comentarios HTML que contengan comandos SSI incrustados. Cuando encuentra
uno, el servidor reemplaza esa parte del texto HTML original con la salida del comando. Por ejemplo, el comando SSI anterior (es decir, #incluir
archivo) reemplaza todo el comentario SSI con el contenido de otro archivo HTML. Esto permite que la visualización de un logotipo corporativo u
otra información estática preparada en otro archivo se produzca de manera uniforme en todas las páginas web corporativas. Un subconjunto de las
directivas disponibles permite que el servidor ejecute comandos arbitrarios del sistema y scripts CGI, lo que puede producir efectos secundarios no
deseados [NIST01]. Algunos puntos importantes a considerar al contemplar el despliegue de SSI:
La seguridad de los SSI es extremadamente débil si el comando exec está habilitado en el servidor web.
El impacto de los SSI puede perjudicar el rendimiento de los servidores web con mucha carga.
La seguridad de los SSI depende en gran medida del sistema operativo host y la aplicación del servidor web para la seguridad.
Microsoft ASP.NET es una tecnología de secuencias de comandos del lado del servidor de Microsoft que se puede utilizar para crear
aplicaciones web dinámicas e interactivas. Una página ASP contiene secuencias de comandos del lado del servidor que se ejecutan cuando
un navegador solicita un recurso ".asp" del servidor web. El servidor web procesa la página solicitada y ejecuta cualquier comando de script que
encuentre antes de enviar una página HTML generada al navegador del usuario. Tanto C# como VBScript se admiten de forma nativa como
lenguajes de secuencias de comandos ASP.NET, pero se pueden admitir otros lenguajes si se instala un intérprete compatible con ASP.NET para
el lenguaje. Por ejemplo, los motores ASP.NET están disponibles para los lenguajes Perl, REXX y Python desde varios
6-13
fuentes. Los siguientes son algunos puntos importantes a tener en cuenta al contemplar la implementación de ASP.NET [Ziri02]:
ASP.NET se basa en gran medida en el sistema operativo host y la aplicación del servidor web para la seguridad.
La seguridad del cliente está bien integrada con el servidor web y los servicios de autenticación del sistema operativo host.
ASP.NET es compatible con Microsoft Code Access Security, que proporciona métodos para que el desarrollador o administrador de
contenido restrinja los privilegios.
ASP.NET es relativamente inmune a los desbordamientos de búfer.
ASP.NET es una tecnología madura y bien documentada.
Java EE se basa en la tecnología Java (consulte la Sección 6.4.1) y proporciona un tipo de subprograma del lado del servidor denominado servlet. El
servidor web primero determina si la solicitud del navegador requiere información generada dinámicamente desde un servlet, que procesa la solicitud y
genera una respuesta HTTP, una página de servidor Java (JSP) o una página HTML estática. Si se requiere un servlet, el servidor web puede ubicar o
instanciar un objeto de servlet correspondiente a la solicitud e invocarlo para obtener los resultados necesarios. Si se solicita un JSP, Java EE compila
el JSP en un servlet, luego lo instancia y lo invoca para obtener una respuesta.
Si se solicita una página HTML estática, Java EE simplemente devuelve el contenido HTML como una página web tradicional.
servidor.
El servidor Java EE normalmente se rellena con los objetos de servlet, que permanecen inactivos hasta que se invocan.
Por lo tanto, poca o ninguna sobrecarga de inicio está asociada con la ejecución de los objetos de servlet. Un servidor web también puede descargar
el manejo de servlets a otro servidor. Al confiar en la portabilidad de Java y observar una API común, los objetos de servlet pueden ejecutarse en casi
cualquier entorno de servidor. Los servlets permiten a los desarrolladores aprovechar un entorno orientado a objetos en el servidor web, que es flexible
y extensible.
Además, los objetos de servlet que no son de confianza se pueden ejecutar en un área segura, y la información generada dinámicamente se
pasa desde el área segura al entorno del servidor restante [NIST01].
Algunos puntos importantes a tener en cuenta al contemplar el despliegue de servlets de Java [Ziri02]:
Java EE está estrechamente integrado con la seguridad del sistema operativo host y la autenticación del servidor web para una mayor seguridad.
Java EE facilita la programación segura mediante:
Aprovechando la seguridad del lenguaje Java
Usar un modelo de seguridad sólido que admita las restricciones de los desarrolladores y administradores de servidores
Emplear el manejo seguro de errores.
Java EE es una tecnología madura y bien documentada.
Una gran cantidad de código robusto de terceros de IBM, Sun, Apache Foundation y otros desarrolladores está disponible para usar con Java
EE.
PHP es un lenguaje de secuencias de comandos utilizado para crear páginas web dinámicas. Con sintaxis de C, Java y Perl, el código PHP está
incrustado en las páginas HTML para la ejecución del lado del servidor. PHP se usa comúnmente para extraer datos de una base de datos y presentarlos
en una página web. La mayoría de los principales servidores web de Windows y Unix admiten la
6-14
lenguaje, y es ampliamente utilizado con la base de datos mySQL [NIST01]. Los siguientes son algunos puntos importantes a considerar al
contemplar la implementación de PHP:
Se debe usar la última versión de PHP disponible porque las versiones anteriores tienen numerosas vulnerabilidades de seguridad.
PHP proporciona una serie de opciones que simplifican el desarrollo; algunas de estas opciones (p. ej., la opción
register_globals , que convierte todos los parámetros de entrada en variables de PHP y puede anular valores en el script de PHP)
pueden dificultar que los principiantes desarrollen programas seguros.
Gran parte del código de terceros disponible gratuitamente para PHP está mal escrito desde una perspectiva de seguridad.43
6.4.3 Consideraciones de seguridad del generador de contenido del lado del servidor
Al examinar o escribir un archivo ejecutable o script de contenido activo, tenga en cuenta lo siguiente:
El código ejecutable debe ser lo más simple posible. Cuanto más largo o más complejo sea, más probable es que tenga problemas.
La capacidad del código ejecutable para leer y escribir programas debe ser limitada. El código que lee archivos puede violar
inadvertidamente las restricciones de acceso o pasar información confidencial del sistema. El código que escribe archivos puede modificar
o dañar documentos o introducir caballos de Troya.
Se debe analizar la interacción del código con otros programas o aplicaciones para identificar vulnerabilidades de seguridad. Por
ejemplo, muchas secuencias de comandos CGI envían correos electrónicos en respuesta a la entrada del formulario al abrir una conexión
con el programa sendmail. Asegúrese de que esta interacción se realice de manera segura.
En hosts Linux/Unix, el código no debe ejecutarse con suid (set-user-id).
El código debe usar nombres de ruta explícitos al invocar programas externos. No se recomienda confiar en la variable de entorno
PATH para resolver nombres de rutas parciales.
Los servidores web deben escanearse periódicamente en busca de vulnerabilidades, incluso si no emplean contenido activo
(consulte la Sección 9.4.1). Los escáneres de seguridad de la red pueden detectar vulnerabilidades en el servidor web, el sistema
operativo u otros servicios que se ejecutan en el servidor web. Los escáneres de vulnerabilidades de aplicaciones web analizan
específicamente las vulnerabilidades del generador de contenido (consulte el Apéndice C para obtener más información).
El código de generación de contenido web debe escanearse y/o auditarse (dependiendo de la sensibilidad del servidor web y su
contenido). Las herramientas disponibles comercialmente pueden escanear código .NET o Java. Varias entidades comerciales ofrecen
servicios de revisión de código.
El código de generación de contenido web debe desarrollarse siguiendo las prácticas recomendadas actuales.44
Para los formularios de entrada de datos, determine una lista de caracteres esperados y filtre los caracteres inesperados de los datos de
entrada ingresados por un usuario antes de procesar un formulario. Por ejemplo, en la mayoría de los formularios, los datos esperados
43
Hay una serie de razones para la poca seguridad de muchos scripts PHP. La más obvia es que muchos scripts se escriben sin preocuparse por
la seguridad. Además, debido a la relativa facilidad de codificar secuencias de comandos PHP, muchos novatos que tienen poco conocimiento
sobre programación segura crean y, a menudo, distribuyen libremente secuencias de comandos mal escritas.
44
OWASP está compilando una guía que contiene las mejores prácticas de desarrollo de aplicaciones web en su sitio
en http://www.owasp.org/index.php/OWASP_Guide_Project.
6-15
cae en estas categorías: letras az, AZ y 0-9. Se debe tener cuidado al aceptar caracteres especiales como &, ÿ, ÿ, @ y !. Estos
símbolos pueden tener significados especiales dentro del lenguaje de generación de contenido u otros componentes de la aplicación
web.
Asegúrese de que las páginas generadas dinámicamente no contengan metacaracteres peligrosos. Es posible que un usuario
malintencionado coloque estas etiquetas en una base de datos o un archivo. Cuando se genera una página dinámica utilizando los datos
alterados, el código malicioso incrustado en las etiquetas puede pasar al navegador del cliente.
Luego, se puede engañar al navegador del usuario para que ejecute un programa elegido por el atacante. Este programa se ejecutará en el
contexto de seguridad del navegador para comunicarse con el servidor web legítimo, no en el contexto de seguridad del navegador para
comunicarse con el atacante. Por lo tanto, el programa se ejecutará en un contexto de seguridad inapropiado con privilegios inapropiados.
La codificación del conjunto de caracteres debe establecerse explícitamente en cada página. Luego, los datos del usuario deben
escanearse en busca de secuencias de bytes que representen caracteres especiales para el esquema de codificación dado.
Cada carácter de un juego de caracteres específico se puede codificar utilizando su valor numérico. La codificación de la salida se
puede utilizar como alternativa para filtrar los datos. La codificación cobra especial importancia cuando los caracteres especiales, como los
símbolos de derechos de autor, pueden formar parte de los datos dinámicos. Sin embargo, la codificación de datos puede consumir muchos
recursos y se debe lograr un equilibrio entre la codificación y otros métodos para filtrar los datos.
Las cookies deben examinarse en busca de caracteres especiales. Cualquier carácter especial debe filtrarse.
Se debe utilizar un mecanismo de cifrado para cifrar las contraseñas ingresadas a través de formularios de script (consulte la Sección
7.5).
Para las aplicaciones web que están restringidas por nombre de usuario y contraseña, ninguna de las páginas web de la aplicación
debe ser accesible sin ejecutar el proceso de inicio de sesión adecuado.
Muchos servidores web y algún otro software de servidor web instalan scripts de muestra o ejecutables durante el proceso de instalación.
Muchos de estos tienen vulnerabilidades conocidas y deben eliminarse de inmediato. Consulte la documentación del fabricante
correspondiente o los sitios web para obtener más información.
Al considerar un generador de contenido del lado del servidor, es importante revisar las bases de datos públicas de vulnerabilidad y
seguridad (como NVD, http://nvd.nist.gov/) para determinar el riesgo relativo de las diversas tecnologías en consideración. Aunque el
registro histórico no será un indicador perfecto del riesgo futuro, sí indica qué tecnologías parecen ser más vulnerables.
Varias organizaciones investigan temas de seguridad de redes y sistemas y publican periódicamente información sobre vulnerabilidades
recientemente descubiertas en el software. Esto incluye software de servidor web y tecnologías de soporte, como lenguajes de secuencias de
comandos y programas externos. Los investigadores, los usuarios y los equipos de respuesta a incidentes de seguridad y los atacantes analizan
regularmente los programas externos que se usan ampliamente. Los atacantes a menudo publican scripts de explotación que se aprovechan de
las vulnerabilidades conocidas en el software del servicio web y los programas externos comúnmente utilizados por los servidores web públicos.
Los administradores web deben revisar las fuentes de información pública con frecuencia y estar al tanto de toda la información relevante para la
seguridad sobre cualquier programa externo que estén considerando.
6-16
6.4.4 Ubicación de los generadores de contenido del lado del servidor
La ubicación del contenido activo en el servidor web es fundamental. Si se encuentra en un directorio incorrecto o en un directorio con los
permisos incorrectos, puede comprometer rápidamente el servidor web. Para evitar este problema—
Los archivos de escritura deben identificarse y colocarse en carpetas separadas. No deben existir archivos de secuencias de
comandos en las carpetas de escritura. Como ejemplo, los datos del libro de visitas generalmente se guardan en archivos de texto
simples. Estos archivos necesitan permisos de escritura para que los invitados puedan enviar sus comentarios.
Los archivos ejecutables (p. ej., CGI, .EXE, .CMD y PL) deben colocarse en carpetas separadas. No se deben colocar otros documentos
legibles o escribibles en estas carpetas.
Los archivos de script (por ejemplo, ASP, PHP y PL) deben tener carpetas separadas. También puede ser beneficioso almacenar los scripts
en una carpeta con un nombre no obvio (p. ej., no "Scripts") para que a un atacante le resulte más difícil encontrar los scripts a través de la
exploración directa.
Los archivos de inclusión (por ejemplo, INC, SHTML, SHTM y ASP) creados para la reutilización del código deben colocarse en directorios
separados. Por lo general, SSI no debe usarse en servidores web públicos. Los archivos de inclusión ASP deben tener una extensión .asp
en lugar de .inc. Tenga en cuenta que gran parte del riesgo con los archivos de inclusión está en su capacidad de ejecución. Si la capacidad
de ejecución está deshabilitada, este riesgo se reduce drásticamente.
6.4.5 Vulnerabilidades de secuencias de comandos entre sitios
Cross-site scripting (XSS) es una vulnerabilidad que normalmente se encuentra en las aplicaciones web interactivas y que permite que los
usuarios malintencionados de la web inyecten código en las páginas web vistas por otros usuarios. Por lo general, ocurre en las páginas web
que no verifican los límites apropiados en la entrada de datos por parte de los usuarios. Los atacantes pueden utilizar una vulnerabilidad de
secuencias de comandos entre sitios explotada para comprometer las computadoras de otros usuarios o para recibir datos de la sesión web de otro
usuario (por ejemplo, ID de usuario y contraseña o cookie de sesión). Por lo tanto, aunque se trata de un exploit del lado del cliente, también afecta
indirectamente al servidor, ya que un usuario comprometido, en particular uno con privilegios elevados, representa una amenaza para el servidor.
Las vulnerabilidades XSS se utilizan con frecuencia para realizar ataques de phishing o explotar las vulnerabilidades de los navegadores web para
obtener el control de las PC de los usuarios finales.
Las vulnerabilidades XSS son muy variadas y, con frecuencia, exclusivas de una aplicación web en particular. Comprenden dos
categorías generales:
Las vulnerabilidades XSS persistentes permiten los ataques más poderosos. Esta vulnerabilidad se produce cuando los datos
proporcionados a una aplicación web por un usuario que no es de confianza se almacenan de forma persistente en el servidor y se
muestran a otros usuarios como contenido web, pero no se validan ni codifican mediante HTML. Un ejemplo común de esto son los tableros
de mensajes en línea, wikis y blogs donde los usuarios pueden publicar mensajes con formato HTML para que otros usuarios los vean. En
este ejemplo, después de que un usuario malintencionado publique un mensaje malicioso o responda, cualquier otro usuario que acceda a
una página que muestre esos datos y cuyo navegador sea vulnerable al exploit puede verse comprometido.
Las vulnerabilidades XSS no persistentes , a veces llamadas reflejadas, son más comunes y algo menos peligrosas que las
vulnerabilidades persistentes. Las vulnerabilidades no persistentes se producen cuando los scripts del lado del servidor utilizan
inmediatamente los datos proporcionados por un cliente web para generar una página de resultados para ese usuario (p. ej., pantalla de inicio
de sesión, página de resultados de búsqueda). Si los datos proporcionados por el cliente no validados se incluyen en la página devuelta sin
ninguna codificación HTML, esto permitirá que el código del lado del cliente se inyecte en la página dinámica. Esto podría no parecer un
problema en la superficie, ya que un atacante solo puede explotarse a sí mismo. Sin embargo, un atacante podría enviar una URL
especialmente diseñada a un usuario y
6-17
engañar al usuario a través de la ingeniería social para que haga clic en la URL creada con fines malintencionados.
Si el navegador web del usuario era vulnerable al exploit, la máquina del usuario podría verse comprometida.
Dado que este ataque requiere cierto nivel de ingeniería social, se considera algo menos peligroso que los
ataques a vulnerabilidades persistentes.
La solución a los ataques XSS es validar todas las entradas del usuario y eliminar cualquier dato inesperado o
potencialmente riesgoso. Otra solución es utilizar una versión citada en HTML45 de cualquier entrada de usuario que
se presente a otros usuarios. Esto evitará que los navegadores web de otros usuarios interpreten esa entrada y actúen
sobre cualquier comando incrustado presente.
6.5 Lista de verificación para asegurar el contenido web
Terminado Acción
Asegúrese de que ninguno de los siguientes tipos de información esté disponible en o a

través de un servidor web público
Información personal sobre el personal de una organización.
Números de teléfono, direcciones de correo electrónico o listados generales del personal, a menos
que sea necesario para cumplir con los requisitos de la organización
Horarios de los directores de la organización o su ubicación exacta (ya sea dentro o fuera de las
instalaciones)
Información sobre la composición, preparación o uso óptimo de materiales peligrosos o toxinas

Registros médicos
Procedimientos de seguridad física y de la información de la organización
Información sobre la red de la organización y la infraestructura del sistema de

información
Planos, mapas, diagramas, fotografías aéreas y planos arquitectónicos de edificios,

propiedades o instalaciones organizacionales
Políticas de privacidad o seguridad que indican los tipos de medidas de seguridad implementadas
en la medida en que pueden ser útiles para un atacante
Establezca una política y un proceso formales documentados para toda la

organización para aprobar contenido web público que:
Identifica la información que debe ser publicada en la Web
Identifica el público objetivo
Identifica posibles ramificaciones negativas de publicar la información.
Identifica quién debe ser responsable de crear, publicar y mantener esta información en particular.
45
Más información sobre cotizaciones HTML está disponible en http://www.w3.org/TR/html4/charset.html#entities y http://
www.w3.org/TR/html4/sgml/entities.html.
6-18
Terminado Acción
Proporciona pautas sobre estilos y formatos apropiados para la publicación en la Web.
Proporciona una revisión adecuada de la información para la sensibilidad y los controles de

distribución/publicación (incluida la sensibilidad de la información en conjunto)
Determina los controles de acceso y seguridad apropiados.
Proporciona orientación sobre la información contenida en el código fuente del

contenido web
Mantener la privacidad del usuario web
Mantener una política de privacidad publicada
Prohibir la recopilación de datos de identificación personal sin el permiso explícito del usuario y
recopilar solo los datos que sean absolutamente necesarios.
Prohibir el uso de cookies “persistentes”
Use la cookie de sesión solo si está claramente identificada en la política de privacidad publicada
Mitigar los ataques indirectos al contenido
Asegúrese de que los usuarios del sitio sean conscientes de los peligros de los ataques de phishing y
pharming y cómo evitarlos.
Valide la comunicación oficial personalizando los correos electrónicos y brindando información de

identificación única (pero no confidencial) que solo la organización y el usuario deben conocer
Use firmas digitales en el correo electrónico, si corresponde.
Realice la validación de contenido dentro de la aplicación web para evitar ataques de phishing
más sofisticados (por ejemplo, ataques basados en secuencias de comandos entre sitios).
Personalizar el contenido web para ayudar a los usuarios a identificar sitios web fraudulentos. Usar
autenticación mutua o basada en token, si corresponde. Sugerir el uso de navegadores web o
barras de herramientas del navegador con protección contra phishing/pharming. Mecanismos de

protección de DNS
Monitorear dominios organizacionales y dominios similares
Simplificar la estructura de los nombres de dominio de la organización
Utilice conexiones seguras para los inicios de sesión
Si es necesario, contrate a un proveedor para que proporcione medidas más estrictas

contra el phishing/anti-pharming
Consideraciones de seguridad del contenido activo del lado del cliente
Sopesar los riesgos y beneficios del contenido activo del lado del cliente
No realice ninguna acción sin el permiso expreso del usuario.
Cuando sea posible, solo use contenido activo ampliamente adoptado, como JavaScript,
PDF y Flash
Cuando sea posible, proporcione alternativas (p. ej., HTML proporcionado junto con PDF)
Mantener la seguridad del contenido activo del lado del
servidor. Solo se debe usar código simple y fácil de entender. Se debe
permitir lectura o escritura limitada o nula en el sistema de archivos.
Se debe permitir una interacción limitada o nula con otros programas (p. ej., sendmail).
No debería haber ningún requisito para ejecutar con privilegios suid en Unix o Linux
Se deben usar nombres de ruta explícitos (es decir, no depende de la variable de ruta)
6-19
Terminado Acción
Ningún directorio tiene permisos de escritura y ejecución
Todos los archivos ejecutables se colocan en carpetas dedicadas

Los SSI están deshabilitados o la función de ejecución está deshabilitada
Toda la entrada del usuario es validada
El código de generación de contenido web debe escanearse o auditarse
Las páginas creadas dinámicamente no crean metacaracteres peligrosos
La codificación del conjunto de caracteres debe establecerse explícitamente en cada página
Los datos del usuario deben escanearse para garantizar que solo contengan la entrada esperada (p.
ej., az, AZ, 0-9); se debe tener cuidado con los caracteres especiales o las etiquetas HTML
Las cookies deben examinarse en busca de caracteres especiales.
El mecanismo de cifrado se utiliza para cifrar las contraseñas ingresadas a través de formularios de
scripts
Para las aplicaciones web que están restringidas por nombre de usuario y contraseña, ninguna de las
páginas web de la aplicación debe ser accesible sin ejecutar el proceso de inicio de sesión adecuado.
Se eliminan todos los scripts de muestra.
No se utilizan scripts de terceros ni código ejecutable sin verificar el código fuente
6-20
7. Uso de tecnologías de autenticación y cifrado
Los servidores web públicos a menudo admiten una variedad de tecnologías para identificar y autenticar a los usuarios
con diferentes privilegios para acceder a la información. Algunas de estas tecnologías se basan en funciones criptográficas
que pueden proporcionar un canal cifrado entre un cliente de navegador web y un servidor web compatible con el cifrado.
Sin la autenticación del usuario, las organizaciones no podrán restringir el acceso a información específica a usuarios
autorizados. Cualquier persona con acceso al servidor podrá acceder a toda la información que reside en un servidor web
público. Además, sin algún proceso para autenticar el servidor, los usuarios no podrán determinar si el servidor es el
servidor web "auténtico" o una versión falsificada operada por una entidad maliciosa.
El cifrado se puede utilizar para proteger la información que atraviesa la conexión entre un cliente de navegador web y un
servidor web público. Sin encriptación, cualquier persona con acceso al tráfico de la red puede determinar, y posiblemente
alterar, el contenido de la información confidencial, incluso si el usuario que accede a la información se ha autenticado
cuidadosamente. Esto puede violar la confidencialidad e integridad de la información crítica.
7.1 Determinación de los requisitos de autenticación y cifrado
Las organizaciones deben examinar periódicamente toda la información accesible en el servidor web público y
determinar los requisitos de seguridad necesarios. Al hacerlo, la organización debe identificar la información que
comparte los mismos requisitos de seguridad y protección. Para la información confidencial, la organización debe
determinar los usuarios o grupos de usuarios que deben tener acceso a cada conjunto de recursos.
Para la información que requiere cierto nivel de autenticación del usuario, la organización debe determinar cuál de las
siguientes tecnologías o métodos proporcionaría el nivel adecuado de autenticación y cifrado. Cada uno tiene sus propios
beneficios y costos únicos que deben sopesarse cuidadosamente con los requisitos y políticas del cliente y de la organización.
Puede ser deseable usar algunos métodos de autenticación en combinación.
Esta guía analiza los mecanismos de autenticación más comúnmente asociados con servidores web públicos y aplicaciones
web. Estos servidores y aplicaciones pueden admitir mecanismos de autenticación más avanzados y se analizan en NIST
SP 800-63.46
7.2 Autenticación basada en direcciones
El mecanismo de autenticación más simple que admiten la mayoría de los servidores web es la autenticación
basada en direcciones. El control de acceso se basa en la dirección IP y/o el nombre de host del host que solicita
información. Aunque es fácil de implementar para pequeños grupos de usuarios, la autenticación de direcciones puede
ser difícil de manejar para los sitios web que tienen una gran población de usuarios potenciales (es decir, la mayoría de
los servidores web públicos). Es susceptible a varios tipos de ataques, incluida la suplantación de IP y el envenenamiento
de DNS. Este tipo de autenticación debe usarse solo cuando se requiere una seguridad mínima, a menos que se use junto
con métodos de autenticación más fuertes.
46
NIST SP 800-63, Directrices de autenticación electrónica, está disponible en http://csrc.nist.gov/publications/nistpubs/.
7-1
7.3 Autenticación básica
La tecnología de autenticación básica utiliza la estructura de directorios del contenido del servidor web. Normalmente, todos los
archivos en el mismo directorio están configurados con los mismos privilegios de acceso. Un usuario solicitante proporciona una
identificación de usuario reconocida y una contraseña para acceder a los archivos en un directorio determinado. Se puede
aplicar un control de acceso más restrictivo a nivel de un solo archivo dentro de un directorio si el software del servidor web
proporciona esta capacidad. El software de servidor web de cada proveedor tiene su propio método y sintaxis para definir y
utilizar este mecanismo básico de autenticación.
Desde una perspectiva de seguridad, el principal inconveniente de esta tecnología es que toda la información de la
contraseña se transfiere de forma codificada, en lugar de encriptada. Cualquiera que conozca el esquema de codificación
estandarizado puede decodificar la contraseña después de capturarla con un rastreador de red. Además, cualquier contenido
de la Web se transmite como texto sin cifrar, por lo que este contenido también puede ser capturado, violando la confidencialidad.
Estas limitaciones se pueden superar utilizando la autenticación básica junto con SSL/TLS (consulte la Sección 7.5). La
autenticación básica es compatible con navegadores web compatibles con el estándar [Koss00]. La autenticación básica es
útil para proteger la información de bots maliciosos (consulte la Sección 5.2.4) porque los bots no deben tener las credenciales
necesarias para acceder a los directorios protegidos. Sin embargo, este mecanismo no debe considerarse seguro frente a
atacantes más decididos y sofisticados.
7.4 Autenticación implícita
Debido a los inconvenientes de la autenticación básica, se introdujo una técnica mejorada conocida como
autenticación implícita en la versión 1.1 del protocolo HTTP.47 La autenticación implícita utiliza un mecanismo de
desafío-respuesta para la autenticación del usuario. Bajo este enfoque, se envía un valor nonce o arbitrario al usuario, a quien
se le solicita una identificación y una contraseña, como con la autenticación básica. Sin embargo, en este caso, la información
ingresada por el usuario se concatena y se forma un hash criptográfico del resultado.
Este hash se concatena con el nonce y un hash del método y la URL solicitados, y el resultado se repite como un valor de
respuesta que se envía al servidor.
Debido a que la contraseña del usuario no se envía en claro, no se puede rastrear directamente desde la red. El servidor no
necesita la contraseña del usuario para autenticar al usuario, solo el valor cifrado del ID de usuario y la contraseña. Debido a
que el nonce puede servir como un indicador de puntualidad (por ejemplo, puede estar compuesto por información de fecha y
hora), los ataques de repetición también se frustran. Desafortunadamente, el resto de la información se envía en claro y es
vulnerable a la intercepción y alteración. La autenticación de resumen también es susceptible a los ataques de diccionario fuera
de línea (consulte la Sección 7.6), donde el atacante prueba varias contraseñas en un intento de recrear el valor de resumen
capturado. Estas limitaciones se pueden superar utilizando la autenticación implícita junto con SSL/TLS (consulte la Sección
7.5).48 Al igual que la autenticación básica, la autenticación implícita es útil para proteger la información de bots maliciosos
(consulte la Sección 5.2.4).
47
Hay más información disponible sobre autenticación básica y implícita en IETF RFC 2617, Autenticación HTTP: autenticación de acceso básica y implícita
(http://www.ietf.org/rfc/rfc2617.txt).
48
Por ejemplo, se pueden realizar ataques de diccionario fuera de línea contra contraseñas de autenticación implícitas interceptadas para identificar las
contraseñas de texto no cifrado. Las contraseñas de autenticación de resumen interceptadas que se envían a través de conexiones protegidas con SSL no
son susceptibles a ataques de diccionario fuera de línea.
7-2
7.5 SSL/TLS
Los protocolos SSL y TLS proporcionan autenticación de servidor y cliente y encriptación de las comunicaciones.49 Netscape
Communications introdujo SSL por primera vez en 1994 y se revisó dos veces (la versión actual es SSL versión 3).50 En
1996, el Grupo de Trabajo de Ingeniería de Internet (IETF ) estableció el grupo de trabajo TLS para formalizar y avanzar el
protocolo SSL al nivel de estándar de Internet. La versión 1.0 del protocolo TLS se especifica formalmente en la Solicitud de
comentarios (RFC) 2246,51 de IETF, que se publicó en 1999 y se basa en gran parte en la versión 3 de SSL. La versión 3 de
SSL y la versión 1 de TLS son esencialmente idénticas y se analizan juntas en este documento. La mayoría de los principales
componentes de Internet, como los navegadores web, admiten el uso de SSL 3 y TLS 1.0. TLS 1.1, especificado en RFC
4436, se lanzó en abril de 2006 y es probable que las versiones futuras de los navegadores web lo admitan.
TCP/IP rige el transporte y enrutamiento de datos a través de Internet. Otros protocolos, como HTTP, LDAP y el
Protocolo de acceso a mensajes de Internet (IMAP), se ejecutan "sobre" TCP/IP en el sentido de que todos usan TCP/IP para
admitir tareas de aplicaciones típicas, como mostrar páginas web o enviar mensajes electrónicos. mensajes de correo Por lo
tanto, SSL/TLS puede admitir más que solo comunicaciones web seguras. La figura 7-1 muestra cómo encaja SSL/TLS entre
las capas de aplicación y red/transporte del conjunto de protocolos de Internet.
Figura 7-1. Ubicación SSL/TLS dentro de la pila de protocolos de Internet
7.5.1 Capacidades SSL/TLS
SSL/TLS proporciona las siguientes capacidades para HTTP y otros protocolos de capa de aplicación [SSL98]:
Autenticación del servidor: SSL/TLS permite que un cliente web (usuario) confirme la identidad de un servidor web.
Los clientes web habilitados para SSL/TLS (navegadores) pueden emplear técnicas estándar de criptografía de clave
pública para comprobar que el nombre de un servidor y la clave pública están contenidos en un certificado válido emitido
por una CA incluida en la lista de CA de confianza del cliente. Esta confirmación puede ser importante si el usuario, por
ejemplo, envía un número de tarjeta de crédito a través de la red y desea confirmar la identidad del servidor receptor.
Autenticación de cliente: SSL/TLS permite que un servidor web confirme la identidad de un usuario usando las
mismas técnicas que se usan para la autenticación del servidor al invertir los roles. Web compatible con SSL/TLS
49
La comprensión adecuada de SSL y la información presentada en esta sección requiere al menos una comprensión básica de los
algoritmos criptográficos, las funciones de resumen de mensajes, las firmas digitales, los algoritmos de cifrado simétrico y los algoritmos de
cifrado asimétrico. Para obtener una introducción a la criptografía, consulte NIST SP 800-32, Introducción a la tecnología de clave pública y la
infraestructura PKI federal. Para obtener más información sobre la seguridad de la capa de transporte, consulte NIST SP 800-52, Directrices
para la selección y el uso de implementaciones de seguridad de la capa de transporte (TLS). Ambos documentos se pueden encontrar en http://
csrc.nist.gov/publications/nistpubs/.
50 Las versiones de SSL anteriores a la 3.0 no son seguras y no deben
51
utilizarse. http://www.ietf.org/rfc/rfc2246.txt
7-3
el software del servidor puede confirmar que el certificado de un cliente es válido y que fue emitido por una CA incluida
en la lista de CA de confianza del servidor.52 Esta confirmación puede ser importante si el servidor, por ejemplo, es un
banco que envía información financiera confidencial a un cliente. y quiere confirmar la identidad del destinatario.53 Si se
va a realizar la autenticación del cliente, también se debe realizar la autenticación del servidor.
Cifrado de comunicación: SSL/TLS puede cifrar la mayor parte de la información que se transmite entre un
navegador web (cliente) y un servidor web o incluso entre dos servidores web. Con un algoritmo de cifrado adecuado,
SSL/TLS proporciona un alto grado de confidencialidad. Además, todos los datos enviados a través de una conexión SSL/
TLS encriptada están protegidos con un mecanismo para detectar la manipulación; es decir, para determinar automáticamente
si los datos han sido alterados en tránsito.
7.5.2 Debilidades de SSL/TLS
Varias limitaciones son inherentes a SSL/TLS. Los paquetes se cifran en la capa TCP, por lo que la información de la
capa IP no se cifra. Aunque esto protege los datos web que se transmiten, una persona que supervisa una sesión SSL/TLS puede
determinar tanto el remitente como el receptor a través de la información de la dirección IP sin cifrar. Además, SSL/TLS solo
protege los datos mientras se transmiten, no cuando se almacenan en cualquier punto final. Por lo tanto, los datos siguen siendo
vulnerables mientras están almacenados (por ejemplo, una base de datos de tarjetas de crédito) a menos que se tomen medidas
de seguridad adicionales en los puntos finales.
Si SSL/TLS se implementa o se usa incorrectamente, las comunicaciones que se pretende proteger pueden ser vulnerables
a un ataque de "intermediario". Esto ocurre cuando una entidad malintencionada intercepta todas las comunicaciones entre
el cliente web y el servidor web con el que el cliente intenta establecer una conexión SSL/TLS. El atacante intercepta las
claves legítimas que se pasan de un lado a otro durante el protocolo de enlace SSL/TLS (consulte la Sección 7.5.3) y sustituye
las claves del atacante, lo que hace que el cliente web parezca que el atacante es el servidor web y el servidor web que el
atacante es el cliente Web [SSL98]. Si SSL/TLS se implementa y utiliza correctamente, no es susceptible de ataques de
intermediarios.
La información cifrada intercambiada al comienzo del protocolo de enlace SSL/TLS en realidad está cifrada con la clave pública
o clave privada de la entidad malintencionada, en lugar de las claves reales del cliente web o del servidor web. El programa
atacante termina estableciendo un conjunto de claves de sesión para usar con el servidor web real y un conjunto diferente de
claves de sesión para usar con el cliente web. Esto permite que el programa atacante no solo lea todos los datos que fluyen entre
el cliente web y el servidor web real, sino que también cambie los datos sin ser detectado. Esta amenaza se puede mitigar si los
clientes confían en certificados de servidor emitidos por CA de confianza o en certificados autofirmados obtenidos por mecanismos
seguros. La presentación de un certificado autofirmado puede ser una indicación de que se está produciendo un ataque de
intermediario. Los navegadores pueden realizar algunas comprobaciones automáticamente, pero no se puede confiar en ellas en
todos los casos.
Incluso sin realizar un ataque de intermediario, los atacantes pueden intentar engañar a los usuarios para que accedan a un sitio
web no válido. Hay varios métodos posibles de ataque, que incluyen:
Presentar un certificado autofirmado desconocido para el usuario y lograr que el usuario lo acepte como legítimo.
Aunque el navegador web puede configurarse para mostrar una advertencia cuando se solicita un certificado autofirmado.
52
Los servidores y los clientes utilizan diferentes tipos de certificados para la autenticación; específicamente, los clientes deben autenticarse mediante un
certificado de firma. Consulte la Sección 7.5.3 para obtener información adicional.
53
La autenticación de cliente realizada por SSL/TLS rara vez se usa para servidores web públicos debido a la logística involucrada en proporcionar
certificados de cliente a los usuarios y tenerlos instalados correctamente para que los usen los navegadores web.
7-4
presentado, las organizaciones que confían en certificados autofirmados pueden indicar a los usuarios que ignoren dichas
advertencias.
Explotar vulnerabilidades en un navegador web para que el sitio web parezca válido para una persona no capacitada.
usuario
Aprovechar una vulnerabilidad de secuencias de comandos entre sitios en un sitio web legítimo. El navegador web accederá a
dos sitios diferentes, pero al usuario le parecerá que solo está accediendo al sitio legítimo.
Aprovechar el proceso de aprobación de certificados para recibir un certificado válido y aplicarlo al propio sitio del atacante. Al
usar un certificado válido en lo que parece ser un sitio válido, el certificado se validará y el usuario tendría que darse cuenta de
alguna manera de que el sitio al que se accede es malicioso.
Los ataques de suplantación de SSL pueden ocurrir sin requerir la intervención del usuario. Como prueba de concepto en 2005, Shmoo
Group registró un nombre de dominio internacionalizado que se parecía a un sitio válido cuando se mostraba en un navegador. El
certificado SSL coincidía con el nombre de dominio internacionalizado del sitio web, por lo que no se produjo ninguna advertencia para
el usuario. En la barra de direcciones, la URL parecía casi idéntica a la del sitio web falsificado original [NVD06].
Los usuarios pueden evitar ataques menos sofisticados al confirmar la validez de un certificado54 antes de confiar en la seguridad de
una sesión SSL/TLS y rechazar los certificados para los cuales el navegador presenta advertencias.55 Los navegadores realizan algunas
comprobaciones automáticamente, pero no se puede confiar en ellas en todos los casos. .
7.5.3 Ejemplo de sesión SSL/TLS
Los protocolos SSL/TLS utilizan una combinación de cifrado de clave pública y clave simétrica. El cifrado de clave simétrica es mucho
más rápido que el cifrado de clave pública, mientras que el cifrado de clave pública es más adecuado para proporcionar autenticación y
establecer claves simétricas. Una sesión SSL/TLS siempre comienza con un intercambio de mensajes denominado protocolo de enlace
SSL/TLS. El protocolo de enlace permite que el servidor se autentique ante el cliente utilizando técnicas de clave pública; esto permite
que el cliente y el servidor cooperen en la creación de claves simétricas utilizadas para el cifrado y descifrado rápidos y la detección de
manipulaciones durante la sesión siguiente. El protocolo de enlace también permite que el cliente se autentique en el servidor.
Los detalles programáticos exactos de los mensajes intercambiados durante el protocolo de enlace SSL/TLS están fuera del alcance
de este documento. Sin embargo, los pasos básicos involucrados se pueden resumir de la siguiente manera [SSL98]:
1. "El cliente envía al servidor el número de versión de SSL/TLS del cliente, la configuración de cifrado, los datos generados
aleatoriamente y otra información que el servidor necesita para comunicarse con el cliente mediante SSL/TLS".
2. “El servidor envía al cliente el número de versión de SSL/TLS del servidor, la configuración de cifrado, los datos generados
aleatoriamente y otra información que el cliente necesita para comunicarse con el servidor a través de SSL/TLS. El
servidor también envía su propio certificado y, si el cliente solicita un recurso de servidor que requiere autenticación de
cliente, solicita el certificado del cliente”.
54
La verificación de un certificado con la mayoría de los navegadores web implica hacer clic en el ícono de un candado en la esquina inferior derecha del
navegador (este ícono solo aparecerá al acceder a un recurso protegido por SSL/TLS).
55
Cuando las organizaciones usan certificados autofirmados e instruyen a los usuarios para que los acepten, pueden alentar a los usuarios a hacerlo
con certificados potencialmente maliciosos.
7-5
3. “El cliente utiliza parte de la información enviada por el servidor para autenticar el servidor. Si el
no se puede autenticar el servidor, se advierte al usuario del problema y se le informa que no se puede establecer
una conexión cifrada y autenticada. Si el servidor se puede autenticar con éxito, el cliente continúa con el Paso
4”.
4. “Usando todos los datos generados en el apretón de manos hasta este punto, el cliente (con la cooperación del
servidor, según el cifrado que se utilice) crea el secreto premaestro para la sesión, lo cifra con la clave pública
del servidor (obtenida del certificado del servidor, enviado en el Paso 2) y envía el secreto premaestro cifrado al
servidor.
5. “Si el servidor ha solicitado la autenticación del cliente (un paso opcional en el protocolo de enlace), el cliente
también firma otro dato que es exclusivo de este apretón de manos y conocido tanto por el cliente como por el
servidor. En este caso, el cliente envía tanto los datos firmados como el propio certificado del cliente al servidor,
junto con el secreto premaestro cifrado”.
6. “Si el servidor ha solicitado la autenticación del cliente, el servidor intenta autenticar al cliente. Si el cliente no puede
ser autenticado, la sesión se termina. Si el cliente puede autenticarse con éxito, el servidor usa su clave privada
para descifrar el secreto premaestro, luego realiza una serie de pasos (que también realiza el cliente, comenzando
desde el mismo secreto premaestro) para generar el secreto maestro.
7. “Tanto el cliente como el servidor utilizan el secreto maestro para generar las claves de sesión, que son
claves simétricas utilizadas para cifrar y descifrar la información intercambiada durante la sesión SSL/TLS y
para verificar su integridad, es decir, para detectar cualquier cambio en los datos entre el momento en que se
envía y el momento en que se recibe a través de la conexión SSL/TLS. ”
8. “El cliente envía un mensaje al servidor informándole que los futuros mensajes del cliente serán encriptados con la
clave de sesión. Luego envía un mensaje separado (encriptado) que indica que la parte del cliente del protocolo
de enlace ha terminado”.
9. “El servidor envía un mensaje al cliente informándole que los futuros mensajes del servidor serán encriptados
con la clave de sesión. Luego envía un mensaje separado (encriptado) que indica que la parte del servidor del
protocolo de enlace ha terminado”.
10. “El protocolo de enlace SSL/TLS ahora está completo y la sesión SSL/TLS ha comenzado. El cliente y el servidor
utilizan las claves de sesión para cifrar y descifrar los datos que se envían entre sí y para validar su integridad”.
7.5.4 Esquemas de cifrado SSL/TLS
Los protocolos SSL/TLS admiten el uso de una variedad de algoritmos criptográficos diferentes para operaciones como
la autenticación del servidor web y el cliente web entre sí, la transmisión de certificados y el establecimiento de claves
de sesión. Los clientes web y los servidores web pueden admitir diferentes conjuntos de cifrado o conjuntos de cifrado,
según factores como las versiones de SSL/TLS que admiten; políticas organizacionales con respecto a la fuerza de
cifrado aceptable; y restricciones gubernamentales sobre exportación, importación y uso de software compatible con
SSL/TLS. Entre otras funciones, los protocolos de protocolo de enlace SSL/TLS determinan cómo el servidor web y el
cliente web negocian qué suites de cifrado utilizarán para autenticarse mutuamente, transmitir certificados y establecer
claves de sesión. La Tabla 7-1 proporciona una lista de conjuntos de cifrado federales, su uso recomendado y su fuerza
relativa [SSL98 y Chow02].
7-6
Tabla 7-1. Paquetes de cifrado SSL/TLS
Recomendado Paquetes de cifrado Certificado de servidor

Usar
Máxima Seguridad Cifrado: Estándar de cifrado avanzado DSS o RSA con un tamaño de clave de 2048 bits o
(AES) Cifrado de 128 bits o superior56, con respaldo superior y función hash SHA-1 o SHA-256.
al estándar de cifrado de datos triple Tenga en cuenta que el uso de SHA-256 en los certificados
(3DES) Cifrado de 168 bits (usando tres claves)57 puede causar incompatibilidades con clientes más antiguos.
HMAC: algoritmo hash seguro 1 (SHA-1) o SHA-256

58
Autenticación: Estándar de firma digital

(DSS) o RSA
Seguridad y Cifrado: cifrado AES de 128 bits DSS o RSA con un tamaño de clave de 1024 bits o
Actuación superior y SHA-1.
HMAC: SHA-1
Autenticación: DSS o RSA
Seguridad y Cifrado: cifrado AES de 128 bits con respaldo a DSS o RSA con un tamaño de clave de 1024 bits o
Compatibilidad Triple DES) cifrado de 168 bits (usando tres claves) superior y SHA-1.
HMAC: SHA-1
Autenticación: DSS o RSA
Autenticación y HMAC: SHA-1 DSS o RSA con un tamaño de clave de 1024 bits o
Detección de manipulaciones Autenticación: DSS o RSA superior y SHA-1.
El certificado de servidor utilizado en el protocolo de enlace SSL/TSL (descrito con más detalle en la Sección 7.5.5) especifica
el algoritmo que admite la clave pública del certificado, la clave pública y el tamaño de la clave. El certificado también puede
describir su uso previsto (por ejemplo, para generar firmas digitales, cifrado o autenticación).
Durante la fase de negociación, el cliente indica los conjuntos de cifrado y las longitudes de clave que admite. En última
instancia, el servidor dicta la elección del conjunto de cifrado y la longitud de la clave.
La elección de un algoritmo de cifrado adecuado depende de varios factores que varían para cada organización.
Aunque a primera vista puede parecer que siempre se debe usar el cifrado más fuerte disponible, eso no siempre es cierto.
Cuanto mayor sea el nivel de encriptación, mayor será el impacto que tendrá en los recursos del servidor web y la velocidad de
las comunicaciones.59 Además, varios países aún mantienen restricciones sobre la exportación, importación y/o uso de
encriptación. Los problemas de patentes y licencias pueden afectar los esquemas comerciales de encriptación que se pueden
usar. Los factores comunes que influyen en la elección del algoritmo de cifrado son los siguientes:
Seguridad requerida
Valor de los datos (ya sea para la organización y/u otras entidades; cuanto más valiosos sean los datos, más fuerte
será el cifrado requerido)
56
Para obtener más información sobre AES, consulte http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf.
57
Triple DES es considerablemente más lento que AES. Para obtener más información sobre DES y 3DES,
consulte http://csrc.ncsl.nist.gov/cryptval/.
58
Para obtener más información sobre SHA y el Secure Hash Standard (SHS) asociado, consulte FIPS PUB 180-2, Secure Hash Standard,
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf . NIST ha recomendado que el uso de SHA-1 se elimine
gradualmente para 2010 a favor de SHA-224, SHA-256 y otras funciones hash más grandes y más fuertes. Consulte http://csrc.nist.gov/
hash_standards_comments.pdf para obtener información adicional.
59
AES 128 es la excepción a esta regla porque proporciona mayor rendimiento y seguridad que 3DES.
7-7
Valor temporal de los datos (si los datos son valiosos pero solo por un período de tiempo corto [por ejemplo, días en lugar de
años], entonces se podría usar un algoritmo de cifrado más débil)
Amenaza a los datos (cuanto mayor sea el nivel de amenaza, más fuerte será el cifrado requerido)
Otras medidas de protección que existen y que pueden reducir la necesidad de un cifrado más sólido, por
ejemplo, el uso de métodos de comunicación protegidos, como circuitos dedicados en lugar de la Internet pública.
Rendimiento requerido (los requisitos de mayor rendimiento pueden requerir la adquisición de recursos adicionales del sistema,
como un acelerador criptográfico de hardware, o pueden requerir un cifrado más débil)
Recursos del sistema (menos recursos [por ejemplo, proceso, memoria] pueden requerir un cifrado más débil)
Restricciones de importación, exportación o uso
Esquemas de cifrado admitidos por la aplicación del servidor web
Esquemas de cifrado compatibles con los navegadores web de los usuarios previstos.
7.5.5 Implementación de SSL/TLS
Se necesita una firma digital para implementar SSL/TLS en un servidor web. Un certificado, que es el equivalente digital de una tarjeta de
identificación, se utiliza junto con un sistema de cifrado de clave pública. Los certificados pueden ser emitidos por terceros de confianza,
conocidos como CA, o pueden estar autofirmados. Los requisitos organizacionales determinan qué enfoque se utiliza.
Aunque la secuencia de pasos no es idéntica para todos los servidores web, la implementación de un certificado firmado por un tercero
para un servidor web generalmente incluye al menos tres pasos:
Generación y envío de una solicitud de firma de certificado (CSR)
Recoger un certificado SSL/TLS firmado de una CA
Instalar el certificado y configurar el servidor web para usar SSL/TLS para cualquier recurso especificado.
Un CSR consta de tres partes: información de solicitud de certificación, un identificador de algoritmo de firma y una firma digital sobre la
información de solicitud de certificación. Los servidores web habilitados para SSL/TLS brindan instrucciones específicas para la
generación de una CSR. Hay dos tipos principales de CSR. El más popular es el Estándar de criptografía de clave pública codificada (PKCS)
#10, Estándar de sintaxis de solicitud de certificación, que utilizan los servidores web más nuevos [RSA00]. El otro tipo de CSR, basado en
la especificación de correo con privacidad mejorada (PEM), se denomina encabezado de mensaje PEM o formato profesional de sitio web.
El uso de esta CSR generalmente se limita a servidores web más antiguos. La mayoría de los servidores web generan CSR compatibles
con PKCS #10 similares al CSR de muestra que se muestra en la Figura 7-2. Una CSR proporciona no solo información adicional sobre una
entidad determinada, o una "contraseña de desafío" mediante la cual la entidad puede solicitar posteriormente la revocación del certificado,
sino también atributos para su inclusión en los certificados X.509 [RSA00].
7-8
-----COMENZAR SOLICITUD DE CERTIFICADO-----

MIIBujCCASMCAQAwejELMAkGA1UEBhMCQ0ExEzARBgNVBAgTClRFc3QgU3RhdGUx
ETAPBgNVBAcTCENvbG9yYWR0MRswGQYDVQQKExJDYW5hZGlhbiBUZXN0IE9yZy4x
EjAQBgNVBAsTCU9VIE9mZmljZTESMBAGA1UEAxMJd3d3LmV4LmNhMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQD5PIij2FNa+Zfk1OHtptspcSBkfkfZ3jFxYA6ypo3+YbQ
hO3PLTvNfQj9mhb0xWyvoNvL8Gnp1GUPgiw9GvRao603yHebgc2bioAKoTkWTmW+C8+Ka
42wMVrgcW32rNYmDnDWOSBWWR1L1j1YkQBK1nQnQzV3U/h0mr+ASE/nV7wIDAQABo
AAwDQYJKoZIhvcNAQEEBQADgYEAAAhxY1dcw6P8cDEDG4UiwB0DOoQnFb3WYVl7d4
+6lfOtKfuL/Ep0blLWXQoVpOICF3gfAF6wcAbeg5MtiWwTwvXRtJ2jszsZbpOuIt0WU1+cCYi
vxuTi18CQNQrsrD4s2ZJytkzDTAcz1Nmiuh93eqYw+kydUyRYlOMEIomNFIQ=
-----FINALIZAR SOLICITUD DE CERTIFICADO-----
Figura 7-2. Ejemplo de CSR
Se debe verificar la ortografía y la puntuación cuando se proporciona información durante el proceso de generación
de CSR. La URL que se proporciona debe coincidir exactamente con la URL para la que se utiliza el certificado.
Los clientes SSL/TLS están configurados para generar un error si las URL no coinciden. En algunos casos, un usuario
puede reconocer este error en un cuadro de alerta y continuar.
Una vez que se ha generado el CSR, la organización lo envía a una CA. El papel de la CA es cumplir con la CSR
mediante la autenticación de la entidad solicitante y la verificación de la firma de la entidad. Si la solicitud es válida, la
CA construye un certificado X.509 a partir del nombre de dominio (DN) y la clave pública; el nombre del emisor (más
comúnmente conocido como el nombre común [CN]); y la elección de la CA del número de serie, el período de validez o
el algoritmo de firma. Al recibir una CSR enviada, la CA debe verificar la CSR y crear un certificado X.509 firmado. En
este punto, la mayoría de las CA alertarán al solicitante por teléfono, correo electrónico, etc., que el certificado X.509 está
disponible. Una vez notificados, los solicitantes podrán descargar sus certificados a través de una interfaz web protegida
con SSL/TLS.
La Figura 7-3 muestra un certificado X.509 codificado en formato PEM. De forma similar al CSR, al proporcionar un
certificado a un asistente de configuración o incluso al guardarlo en un disco duro, las líneas "BEGIN CERTIFICATE" y
"END CERTIFICATE" son vitales. Sin ellos, la aplicación del servidor web no podrá interpretar el contenido codificado
del certificado.
7-9
-----INICIAR CERTIFICADO-----
MIIDjjCCAvegAwIBAgIBAzANBgkqhkiG9w0BAQQFADCBzzELMAkGA1UEBhMCQ0ExED
AOBgNVBAgTB09udGFyaW8xETAPBgNVBAcTCFdhdGVybG9vMR8wHQYDVQQKExZVb
ml2ZXJzaXR5IG9mIFdhdGVybG9vMSswKQYDVQQLEyJJbmZvcm1hdGlvbiBTeXN0ZW1zI
GFuZCBUZWNobm9sb2d5MSUwIwYDVQQDExxVVy9JU1QgQ2VydGlmaWNhdGUgQXV0a
G9yaXR5MSYwJAYJKoZIhvcNAQkBFhdpc3QtY2FAaXN0LnV3YXRlcmxvby5jYTAeFw05O
DA4MjcxNjE0NDZaFw05OTEwMjExNjE0NDZaMIHGMQswCQYDVQQGEwJDQTEQMA4G
A1UECBMHT250YXJpbzERMA8GA1UEBxMIV2F0ZXJsb28xHzAdBgNVBAoTFlVuaXZlcn
NpdHkgb2YgV2F0ZXJsb28xKzApBgNVBAsTIkluZm9ybWF0aW9uIFN5c3RlbXMgYW5kIFRl
Y2hub2xvZ3kxGTAXBgNVBAMTEGlzdC51d2F0ZXJsb28uY2ExKTAnBgkqhkiG9w0BCQEW
GndlYm1hc3RlckBpc3QudXdhdGVybG9vLmNhMIGfMA0GCSqGSIb3DQEBAQUAA4GNAD
CBiQKBgQCw8Sc7X4EeAxBxTPgmTd4Utau0BIqYTdnIRXXg/ryAn2A7G5MtkMHj0triXoineu
RxW9MQSQW8jMAv+xznMaL6OxnG+txyBjYx1zh02D+npBp4Fy81kgbypp5Usf18BonsqSe9Sl
2P0opCCyclGr+i4agSP5RM5KrycTSVoKHERQIDAQABo4GAMH4wOgYJYIZIAYb4QgEEB
C0WK2h0dHA6Ly9pc3QudXdhdGVybG9vLmNhL3NlY3VyaXR5L2NhLWNybC5wZW0wLQ
YJYIZIAYb4QgENBCAWHklzc3VpbmcgQ0EgYXNzdW1lcyBubyBsaWFibGl0eTARBglghkgB
hvhCAQEEBAMCAEAwDQYJKoZIhvcNAQEEBQADgYEADZOtbpvbnBaWOPIMOSbqTQK
1LUjn4uHN3BLmqxznIzdiMu4RXyxne5Uq9EA7LbttutH7fioOW+ID9Zrn1aH1FoU1dtEvovXm
A6m5G+SN8A9tIAvRGjNmphB82xGkwEXuLN0afYz5XaFo3Z73INw6WxVoxDhPTgNIyYEii
Sp6Qfc=
-----FIN DEL CERTIFICADO-----
Figura 7-3. Ejemplo de certificado SSL/TLS codificado
Cuando un navegador web se pone en contacto con un sitio web que utiliza SSL/TLS, el navegador examina el certificado e
intenta verificar su validez. Cada navegador tiene un almacén de certificados, y estos suelen incluir certificados raíz para
muchas CA de terceros. Si el navegador tiene un certificado raíz para la CA de terceros que emitió el certificado del servidor
web, puede usar el certificado raíz de la CA para validar el certificado del servidor web, que se basa parcialmente en ese
certificado raíz. Si el navegador no tiene el certificado raíz necesario, generalmente muestra una advertencia al usuario que
dice que el certificado del servidor web no se pudo verificar y le pregunta al usuario cómo debe proceder.
Algunas organizaciones deciden crear y firmar sus propios certificados de servidor web en lugar de tener certificados
emitidos por CA de terceros. La principal ventaja de los certificados autofirmados es que evita el costo de comprar y renovar
certificados; sin embargo, de forma predeterminada, los navegadores web no podrán validar los certificados autofirmados,
por lo que no garantizan la legitimidad del certificado o del servidor web. Dado el creciente uso de phishing y otras técnicas
para engañar a los usuarios para que visiten sitios web no autorizados, es inaceptable no autenticar la identidad del servidor
antes de usar SSL/TLS con él. Si solo se va a acceder a un servidor web en particular desde los propios sistemas de la
organización (p. ej., teletrabajadores que usan computadoras portátiles proporcionadas y administradas por la organización),
entonces los navegadores de esos sistemas podrían aprovisionarse con los certificados raíz necesarios para validar la
autodeterminación del servidor web. certificado firmado y autenticar la identidad del servidor. De lo contrario, generalmente
no se recomienda el uso de certificados autofirmados para servidores web públicos debido a la logística involucrada en la
distribución segura de los certificados raíz a los navegadores web de los usuarios y la instalación correcta de los certificados
por parte de los usuarios para que los navegadores puedan autenticar los certificados de la organización. servidores web
Para todos los certificados SSL/TLS para servidores web, independientemente del emisor o el formato, los administradores
deben extremar las precauciones para proteger su certificado y las claves de cifrado. Las siguientes son recomendaciones:
Cree y almacene una copia de seguridad del certificado en medios de solo lectura en caso de que el certificado original
se elimine accidentalmente. Si el certificado se pierde y no se puede recuperar del medio de copia de seguridad, se
debe crear un nuevo certificado.
7-10
Cree y almacene una copia de seguridad de las claves de cifrado en medios de solo lectura en caso de que las claves se eliminen
accidentalmente. Si las claves se pierden y no se pueden recuperar de los medios de copia de seguridad, se debe crear un nuevo par
de claves y un certificado. Tenga en cuenta que la copia de seguridad de las claves debe estar protegida físicamente y también debe
estar cifrada.
Guarde el certificado original en una carpeta o partición a la que solo puedan acceder los administradores de la Web o del sistema
y que esté protegida por los mecanismos de autenticación adecuados.
Considere ejecutar un verificador de integridad de archivos en el servidor web (consulte la Sección 8.2.2) y asegúrese de que
esté monitoreando cualquier cambio en el certificado.
Examine los registros del sistema con regularidad para validar y garantizar la prevención de accesos no autorizados al sistema.
Si un usuario malintencionado obtiene acceso no autorizado a un servidor web, la integridad de todo el servidor se pierde
inmediatamente una vez que se modifica el par de claves de cifrado. Una vez que se compromete una clave en un certificado SSL/
TLS, puede permanecer comprometida; por ejemplo, algunas CA no emiten información de revocación y muchas implementaciones de
clientes no obtienen ni procesan información de revocación.
Una vez que un certificado está listo, debe instalarse y SSL debe habilitarse y configurarse. Algunos pasos son comunes a todos los
servidores web:
Deshabilite SSL 1.0 y SSL 2.0.
Configure SSL/TLS para restringir los algoritmos criptográficos a los conjuntos de cifrado seleccionados (consulte la Sección 7.5.4).
Indique la ubicación del certificado SSL/TLS e indique al servidor que comience a utilizar SSL/TLS. En ciertos casos, se debe
indicar al servidor web que comience a usar SSL/TLS, e incluso se le debe dar la ubicación del certificado SSL/TLS y las claves
privadas si se almacenaron como archivos en el disco duro.
Indique al servidor que escuche en el puerto TCP 443. Este es el puerto TCP predeterminado desde el cual los clientes
acceden a los recursos SSL/TLS (se pueden usar otros puertos). En la mayoría de los casos, si el servidor no usaba
previamente SSL/TLS, este puerto estaría deshabilitado por razones de seguridad. Probablemente será necesario configurar
la infraestructura de red que admite el servidor web para permitir el tráfico SSL/TLS (consulte la Sección 8.2). Todos los puertos que
no sean TCP 443 deben cerrarse y la infraestructura de la red (por ejemplo, firewalls) debe actualizarse para bloquear los intentos de
conexión a todos los demás puertos. Sin embargo, si el servidor web va a alojar tanto contenido HTTP como HTTPS, TCP 80 también
debe estar abierto.
Configure el servidor para proteger los recursos necesarios (directorios y/o archivos) mediante SSL/TLS.
Configure la aplicación del servidor web para que los recursos apropiados estén protegidos con SSL/TLS.
Estos recursos solo son accesibles desde una URL que comienza con "https://".
Las versiones más nuevas del estándar HTML se han modificado para incluir una respuesta para informar a los clientes cuando un archivo
que han solicitado está disponible solo a través de SSL/TLS. El código de estado HTTP 403.4 indica que una solicitud HTTP GET debe
tener un prefijo https:// porque el recurso solicitado está protegido con SSL/TLS. Para obtener más información, consulte los RFC 2246,
2626 y 2817.60 La mayoría de los navegadores web actuales también brindan a los usuarios una indicación visual fácil de usar del estado
del certificado SSL/TLS de un servidor, como cambiar el color de una barra de estado.
60
http://www.ietf.org/rfc/rfc2246.txt, http://www.ietf.org/rfc/rfc2626.txt y http://www.ietf.org/rfc/rfc2817.txt
7-11
7.5.6 Implementaciones de SSL/TLS
Aunque algunos servidores web vienen empaquetados con capacidades SSL ya integradas, muchos no lo hacen. Esta sección analiza
varias implementaciones comerciales y de código abierto de SSL/TLS. Algunos de estos paquetes contienen la funcionalidad para
generar certificados SSL sin necesidad de una CA. La siguiente lista incluye algunos de los kits de herramientas SSL disponibles:
OpenSSL es una implementación de código abierto de SSL/TLS para plataformas Unix y Linux (http://
www.openssl.org/).
Network Security Services (NSS) es una implementación de código abierto de SSL/TLS desarrollada por la fundación Mozilla.61
NSS se deriva de la implementación SSL original de Netscape.
GnuTLS es una implementación de código abierto de SSL/TLS desarrollada por la Free Software Foundation.62
Java Secure Socket Extension (JSSE) es una implementación de SSL/TLS desarrollada por Sun para su distribución como
parte de Java Runtime Environment (JRE).63
La interfaz del proveedor de soporte de seguridad (SSPI) es una implementación de SSL/TLS disponible en Microsoft Windows
Server 2003.
IBM Java Secure Sockets Extension (IBMJSSE) es una implementación de SSL/TLS para WebSphere Application
Server.
Las organizaciones del gobierno federal están obligadas a utilizar los Estándares Federales de Procesamiento de la Información (FIPS)-
implementaciones de SSL/TLS validadas al proteger datos mediante SSL/TLS. El Programa de validación de módulos criptográficos
(CMVP) realiza pruebas de validación de módulos criptográficos, incluidas las implementaciones de SSL/ TLS.64 NIST proporciona una
lista de proveedores e implementaciones que cumplen con FIPS 140-265.66 Independientemente de la implementación de SSL/TLS
que se use, es importante asegurarse de que los parches de seguridad se apliquen con regularidad. Las fallas de seguridad en las
implementaciones de SSL/TLS pueden potencialmente permitir a los atacantes falsificar certificados PKI, falsificar firmas digitales,
realizar ataques DoS o ejecutar código arbitrario en la Web.
servidor.
7.6 Ataques de fuerza bruta
Muchos sitios web autentican a los usuarios a través de combinaciones de nombre de usuario y contraseña, ya sea a través de HTTP
Basic, HTTP Digest o un formulario web sobre SSL. Independientemente de la implementación, las combinaciones de nombre de
usuario y contraseña son susceptibles a ataques de fuerza bruta. Los ataques de fuerza bruta pueden ocurrir en múltiples formas:
Recolección de nombres de usuario : las aplicaciones que diferencian entre una contraseña no válida y un nombre de usuario no
válido pueden permitir a los atacantes construir una lista de cuentas de usuario válidas.
61
http://www.mozilla.org/projects/security/pki/nss/
62
http://www.gnu.org/software/gnutls/ http://
63
java.sun.com/products/jsse/index.jsp http ://
64
csrc.nist.gov/cryptval/ http://csrc.nist.gov/
publications/fips/fips140-2/fips1402.pdf http://csrc.nist.gov/
sesenta y cinco
66
cryptval/140-1/1401vend. htm
7-12
Ataques de diccionario : los atacantes usan palabras comunes del diccionario y sus variantes para intentar obtener acceso a la
cuenta de un usuario.
Ataques de fuerza bruta : los atacantes prueban todas las contraseñas posibles para intentar obtener acceso a la cuenta de un
usuario.
Hay una serie de métodos para reducir la vulnerabilidad de un servidor web a un ataque de fuerza bruta:
Utilice autenticación sólida: las técnicas de autenticación sólidas, como tokens de hardware, contraseñas de un solo uso,
autenticación biométrica y certificados de cliente SSL/TLS, son mucho más resistentes a los ataques de fuerza bruta que las contraseñas.
Se puede lograr una autenticación más fuerte combinando múltiples mecanismos de autenticación para formar un esquema de
autenticación de múltiples factores. Sin embargo, la autenticación fuerte puede ser prohibitivamente costosa o difícil de incorporar a un
sistema.
Usar tiempos de espera: incurrir en un retraso de varios segundos después de un intento de inicio de sesión fallido puede ralentizar a
un atacante. Sin embargo, los atacantes pueden intentar múltiples inicios de sesión al mismo tiempo desde diferentes clientes.
Usar bloqueos: bloquear una cuenta de usuario después de varios intentos de inicio de sesión fallidos evita que el atacante
inicie sesión con éxito en una cuenta. La principal desventaja de esta técnica es que puede dejar el sistema abierto a un ataque
DoS. Además, un atacante puede probar varias contraseñas comunes con nombres de usuario aleatorios, lo que puede otorgar al
atacante acceso al sistema mientras evita el bloqueo [Whit06].
Hacer cumplir una política de contraseñas: al exigir que las contraseñas tengan una cierta longitud y que contengan letras
minúsculas, letras mayúsculas, números y/o símbolos, un simple ataque de diccionario no funcionará en el sistema.
Hacer cumplir una política de cambio de contraseña: al requerir que las contraseñas se cambien periódicamente, es posible que
un atacante no tenga tiempo suficiente para forzar una contraseña potencial. Sin embargo, las políticas estrictas de cambio de
contraseña pueden frustrar a los usuarios y debilitar las contraseñas al hacer que los usuarios sigan patrones, como usar contraseña1,
contraseña2, etc. [Bell06]
Usar listas negras: el bloqueo de direcciones IP o dominios conocidos por intentar ataques de fuerza bruta para que no
accedan al sistema puede detener a algunos atacantes, pero es posible que algunos ataques provengan de sistemas
comprometidos que, de otro modo, se considerarían legítimos.
Use el software de monitoreo de registros: el monitoreo atento de los registros de intentos de contraseña no válidos puede ayudar a
una organización a detectar ataques de fuerza bruta, lo que podría darle tiempo a la organización para responder antes de que el
ataque tenga éxito.
Aparte de la autenticación sólida, ninguno de estos mecanismos previene por completo los ataques de fuerza bruta; sin embargo, el
uso de una o más de estas técnicas dificulta que un atacante obtenga acceso al sistema. Sin embargo, al considerar qué tecnologías
adoptar, es importante considerar las contraseñas como parte del sistema en su conjunto. Por ejemplo, un sitio web que utiliza nombres
de usuario y contraseñas para recuperar las personalizaciones de los usuarios puede no necesitar preocuparse por prevenir ataques de
fuerza bruta [Bell06]. En los sistemas donde se protege la información confidencial, algunas de estas técnicas pueden ser necesarias. De
todos modos, es posible que una organización ya tenga políticas con respecto a los ataques de fuerza bruta. Si es así, esas políticas deben
seguirse y mejorarse si es necesario.
7-13
7.7 Lista de verificación para el uso de tecnologías de autenticación y cifrado para servidores web
Terminado Acción
Configurar tecnologías de cifrado y autenticación web
Para los recursos web que requieren una protección mínima y para los que hay una audiencia pequeña y
claramente definida, configure la autenticación basada en direcciones
Para los recursos web que requieren protección adicional pero para los que hay una audiencia pequeña
y claramente definida, configure la autenticación basada en direcciones como una segunda línea de
defensa.
Para los recursos web que requieren una protección mínima pero para los que no hay una audiencia
claramente definida, configure la autenticación básica o implícita (mejor)
Para los recursos web que requieren protección contra bots maliciosos, configure la autenticación básica o
implícita (mejor) o implemente las técnicas de mitigación que se analizan en la Sección 5.2.4.
Para las organizaciones que deben cumplir con FIPS 140-2, asegúrese de que la implementación de
SSL/TLS esté validada por FIPS
Para los recursos web que requieren la máxima protección, configure SSL/TLS
Configurar SSL/TLS
Asegúrese de que la implementación de SSL/TLS esté completamente parcheada
Use un certificado emitido por un tercero para la autenticación del servidor (a menos que todos los sistemas
que usan el servidor estén administrados por la organización, en cuyo caso podría usarse un certificado
autofirmado en su lugar)
Para configuraciones que requieren un nivel medio de autenticación del cliente, configure el servidor para que
requiera un nombre de usuario y una contraseña a través de SSL/TLS. Para configuraciones que requieran
un alto nivel de autenticación de cliente, configure el servidor para que requiera certificados de cliente a través
de SSL/TLS. Asegúrese de que los conjuntos de cifrado débil estén deshabilitados ( consulte la Tabla 7.1 para
conocer el uso recomendado de conjuntos de cifrado federales)
Configurar el verificador de integridad de archivos para monitorear el certificado del servidor web
Si solo se va a usar SSL/TLS en el servidor web, asegúrese de que el acceso a través de cualquier puerto TCP
que no sea 443 esté deshabilitado
Si la mayor parte del tráfico al servidor web se realizará a través de SSL/TLS encriptado, asegúrese de
que se empleen los mecanismos de registro y detección adecuados en el servidor web (porque el monitoreo
de la red no es efectivo contra las sesiones SSL/TLS encriptadas)
Protéjase contra ataques de fuerza bruta
Use autenticación fuerte si es posible
Usar un retraso después de intentos fallidos de inicio de sesión
Bloquear una cuenta después de un número determinado de intentos fallidos de inicio de sesión
Hacer cumplir una política de contraseñas
Lista negra de direcciones IP o dominios conocidos por intentar ataques de fuerza bruta
Use software de monitoreo de registros para detectar ataques de fuerza bruta
7-14
8. Implementación de una infraestructura de red segura
La infraestructura de red que admite el servidor web juega un papel fundamental en la seguridad del servidor web. En la
mayoría de las configuraciones, la infraestructura de red es la primera línea de defensa entre Internet y un servidor web
público. Sin embargo, el diseño de la red por sí solo no puede proteger un servidor web. La frecuencia, la sofisticación y la
variedad de los ataques perpetrados en la actualidad respaldan la idea de que la seguridad web debe implementarse a
través de diversos mecanismos de protección en capas (defensa en profundidad). Esta sección analiza los componentes de
red que pueden admitir y proteger servidores web para mejorar aún más su seguridad general. Si bien los problemas de
seguridad son primordiales, las consideraciones de infraestructura de red están influenciadas por muchos factores además
de la seguridad, incluidos el costo, el rendimiento y la confiabilidad.
8.1 Composición y estructura de la red
Los cortafuegos y los enrutadores son dispositivos o sistemas que controlan el flujo de tráfico de red entre redes.
Pueden proteger los servidores web de las vulnerabilidades inherentes a la suite TCP/IP y ayudar a reducir los
problemas de seguridad asociados con aplicaciones y sistemas operativos inseguros. Sin embargo, una organización
tiene muchas opciones al determinar un entorno de red para un servidor web y la seguridad puede no ser el factor principal
para decidir entre esas opciones. La composición y la estructura de la red son las primeras y, en muchos aspectos, las
decisiones más críticas que afectan la seguridad del servidor web porque determinan qué elementos de la infraestructura de
la red protegen el servidor web. Por ejemplo, si el servidor web está ubicado antes del cortafuegos principal de la organización,
entonces el cortafuegos no se puede usar para controlar el tráfico hacia y desde el servidor web. La composición y la
estructura de la red también determinan qué otras partes de la red son vulnerables si el servidor web se ve comprometido.
Por ejemplo, un servidor web accesible externamente ubicado en la red de producción interna somete a la red interna a un
ataque si el servidor web está comprometido. Además, una organización puede optar por no tener el servidor web ubicado
en su red y subcontratar el alojamiento a un tercero.
8.1.1 Diseño de red desaconsejado
Algunas organizaciones optan por ubicar sus servidores web públicos en sus redes de producción internas. Es decir, sus
servidores web residen en la misma red que los usuarios y servidores internos. La principal debilidad de este diseño es que
expone los componentes internos de la red a riesgos adicionales. Los servidores web son a menudo objetivos de los atacantes.
Si los atacantes logran comprometer un servidor web, tendrán acceso a la red interna y podrán comprometer hosts internos
más fácilmente. Por lo tanto, no se recomienda este diseño.
Otro diseño de red que generalmente no se recomienda es colocar el servidor web antes del firewall o enrutador
de una organización que proporciona filtrado de IP. En esta estructura, la red ofrece poca o ninguna protección para el
servidor Web. Debido a que el propio servidor web tiene que mantener la seguridad, proporciona un único punto de falla.
Para estar incluso un poco seguro en esta ubicación, el sistema operativo del servidor web y la aplicación deben estar
extremadamente bien reforzados, con todos los servicios innecesarios e inseguros deshabilitados y todos los parches de
seguridad necesarios aplicados. Para mantener la seguridad de la configuración, el administrador del servidor web debe
mantenerse actualizado sobre las vulnerabilidades y los parches relacionados. Otra limitación de esta estructura es que es
difícil proporcionar cualquier tipo de administración remota segura o capacidad de actualización de contenido.
8.1.2 Zona desmilitarizada
Una zona desmilitarizada (DMZ) describe un host o segmento de red insertado como una "zona neutral" entre la red privada
de una organización e Internet. Evita que los usuarios externos del servidor web obtengan acceso directo a la red interna de
una organización (intranet). Una DMZ mitiga los riesgos de ubicar un servidor web en una red interna o exponerlo directamente
a Internet. Es una solución de compromiso que
8-1
ofrece la mayor cantidad de beneficios con la menor cantidad de riesgo para la mayoría de las organizaciones. La DMZ permite
el acceso a los recursos ubicados dentro de ella tanto a usuarios internos como externos. Hay una amplia variedad de
configuraciones de DMZ, cada una con sus propias fortalezas y debilidades.
Crear una DMZ implica colocar un firewall entre el enrutador de borde de una organización y su red interna, y crear un
nuevo segmento de red al que solo se puede acceder a través del dispositivo DMZ. El servidor web se coloca en el nuevo
segmento, junto con otros componentes de infraestructura de red y servidores que deben ser accesibles desde el exterior.
En algunas configuraciones, el propio enrutador de borde puede actuar como un cortafuegos básico. La Figura 8-1 ilustra un
ejemplo de esta DMZ simple que usa un enrutador con listas de control de acceso (ACL) para restringir ciertos tipos de tráfico de
red hacia y desde la DMZ.
Figura 8-1. DMZ simple de un solo cortafuegos
Una DMZ de un solo firewall es un enfoque de bajo costo porque la organización solo necesita agregar un solo firewall
y usar su enrutador de borde existente para brindar protección a la DMZ. Por lo general, es apropiado solo para organizaciones
pequeñas que enfrentan una amenaza mínima. La debilidad básica en el enfoque es que, aunque el enrutador puede proteger
contra la mayoría de los ataques de red, no es "consciente" de los protocolos de la capa de aplicación del servidor web (por
ejemplo, HTTP) y, por lo tanto, no puede proteger contra los ataques de la capa de aplicación dirigidos a la Web. servidor. Un
enfoque superior es agregar un segundo firewall entre Internet y la DMZ, como se muestra en la Figura 8-2.
Figura 8-2. DMZ de dos cortafuegos
8-2
Una configuración de DMZ de dos cortafuegos mejora la protección sobre una DMZ de enrutador-cortafuegos porque los cortafuegos
dedicados pueden tener conjuntos de reglas de seguridad más complejos y potentes. Además, debido a que un firewall dedicado a
menudo puede analizar el tráfico HTTP entrante y saliente, puede detectar y defenderse contra los ataques de la capa de aplicación
dirigidos al servidor web. Según los conjuntos de reglas de los cortafuegos y el nivel de tráfico que recibe la DMZ, este tipo de DMZ
puede provocar una degradación del rendimiento.
Para las organizaciones que desean la seguridad de la DMZ de dos cortafuegos pero no tienen los recursos para comprar
dos cortafuegos, existe otra opción llamada DMZ de "tramo de servicio". En esta configuración, se construye un firewall con
tres (o más) interfaces de red. Una interfaz de red se conecta al enrutador de borde, otra interfaz se conecta a la red interna
y una tercera interfaz de red se conecta a la DMZ (consulte la Figura 8-3).
Figura 8-3. Pierna de servicio DMZ
Esta configuración somete al cortafuegos a un mayor riesgo de degradación del servicio durante un ataque DoS dirigido a la
DMZ. En la configuración de red DMZ estándar de un solo cortafuegos que se describió anteriormente, un ataque DoS contra el
servidor web generalmente afecta solo al servidor web. En una configuración de red DMZ de rama de servicio, el firewall soporta
la peor parte de cualquier ataque DoS porque debe examinar cualquier tráfico de red antes de que llegue al servidor web (o
cualquier otro DMZ o recurso de red interno) [NIST02a].
Sin embargo, es cada vez más probable que un ataque DoS tome la forma de un ataque DDoS y consuma todo el ancho de
banda de la red entrante y los dispositivos relacionados (por ejemplo, enrutadores de borde de Internet) antes de llegar a un
firewall DMZ.
Las ventajas de una DMZ desde el punto de vista de la seguridad son las siguientes:
El servidor web puede estar mejor protegido y el tráfico de red hacia y desde el servidor web puede monitorearse.
El compromiso del servidor web no amenaza directamente la red de producción interna.
Se puede proporcionar un mayor control sobre la seguridad del servidor web porque se puede controlar el tráfico hacia y
desde el servidor web.
La configuración de la red DMZ se puede optimizar para admitir y proteger los servidores web.
8-3
Las desventajas de una DMZ desde el punto de vista de la seguridad son las siguientes:
Los ataques DoS dirigidos al servidor web pueden tener un efecto en la red interna.
Dependiendo de la configuración del cortafuegos que controle el tráfico entre la DMZ y la red interna, es posible que el servidor
web se use para atacar o comprometer hosts en la red interna.
En otras palabras, la protección que ofrece la DMZ depende en gran medida de la configuración del cortafuegos.
Para las organizaciones que admiten su propio servidor web, una DMZ es casi invariablemente la mejor opción. Ofrece
protección para el servidor web y otros servidores accesibles externamente sin exponer la red interna. Sin embargo, solo debe
considerarse seguro cuando se emplea junto con los otros pasos que se analizan en este documento.
8.1.3 Alojamiento subcontratado
Algunas organizaciones optan por externalizar el alojamiento de sus servidores web a un tercero (por ejemplo, un ISP, un servicio
de alojamiento web u otra agencia gubernamental). En este caso, el servidor web no estaría ubicado en la red de la organización. La
red del servicio de hospedaje tendría una red dedicada que hospeda muchos servidores web (para muchas organizaciones) que operan
en una sola red (consulte la figura 8-4).
Figura 8-4. Alojamiento de servidor web subcontratado
Desde el punto de vista de la seguridad, las ventajas de la externalización son las siguientes:
Los ataques DoS dirigidos al servidor web no tienen efecto en la red de producción de la organización.
El compromiso del servidor web no amenaza directamente la red de producción interna.
El subcontratista puede tener un mayor conocimiento sobre cómo asegurar y proteger los servidores web.
8-4
La red puede optimizarse únicamente para el soporte y la protección de los servidores web.
Las desventajas de la subcontratación desde el punto de vista de la seguridad son las siguientes:
Requiere confiar en un tercero con el contenido del servidor web.
Es más difícil administrar remotamente el servidor web o actualizar remotamente el contenido del servidor web.
Se puede proporcionar menos control sobre la seguridad del servidor web.
El servidor web puede verse afectado por ataques dirigidos a otros servidores web alojados por el subcontratista en la misma
red.
La subcontratación a menudo tiene sentido para las organizaciones más pequeñas que no pueden permitirse el lujo de mantener el
personal del servidor web necesario. También puede ser apropiado para organizaciones más grandes que no deseen alojar sus propios
servidores web. La subcontratación generalmente no tiene sentido para las organizaciones que desean mantener un control estricto
sobre sus servidores web.
8.1.4 Red de gestión
Los servidores web y otros componentes importantes pueden conectarse entre sí y administrarse a través de las redes estándar de
una organización oa través de una red separada conocida como red de administración. Si se utiliza una red de administración, cada
host que se administra a través de la red tiene una interfaz de red adicional conocida como interfaz de administración que se conecta
a la red de administración. Además, cada host administrado no puede pasar ningún tráfico entre su interfaz de administración y
cualquiera de sus otras interfaces de red. Las consolas y otros hosts que se utilizan para administrar los componentes web se
conectan únicamente a la red de administración. Esta arquitectura aísla efectivamente la red de administración de las redes de
producción. Los beneficios de hacer esto son proteger los componentes de algunos ataques y garantizar que los componentes se
puedan administrar en condiciones adversas (por ejemplo, ataque DDoS). Las desventajas de usar una red de administración incluyen
los costos adicionales del equipo de red y otro hardware (por ejemplo, computadoras personales [PC] para las consolas) y la
inconveniencia para los administradores de componentes web de usar computadoras separadas para la administración y el monitoreo.
8.2 Configuración de elementos de red
Una vez que el servidor web se ha colocado en la red, los elementos de la infraestructura de la red deben configurarse para admitirlo
y protegerlo. Los elementos principales de una infraestructura de red que afectan la seguridad del servidor web son los cortafuegos,
los enrutadores, los IDS, los sistemas de prevención de intrusiones (IPS), los conmutadores, los equilibradores de carga y los proxies
inversos. Cada uno tiene un papel importante que desempeñar y es fundamental para la estrategia general de proteger el servidor web
a través de la defensa en profundidad. Desafortunadamente, cuando se trata de proteger un servidor web, no existe una solución única.
Un firewall o IPS por sí solo no puede proteger adecuadamente un servidor web público de todas las amenazas o ataques.
8.2.1 Configuración de enrutador/cortafuegos
Existen varios tipos de cortafuegos. Los cortafuegos más básicos son enrutadores que pueden proporcionar control de acceso para
paquetes IP. En el medio hay cortafuegos con estado que pueden proporcionar control de acceso basado en TCP y Usuario.
8-5
Protocolo de datagramas (UDP) e IP. Los cortafuegos más potentes son los cortafuegos de capa de aplicación o proxy que pueden
comprender y filtrar el contenido web.67
Una percepción errónea común acerca de los cortafuegos (y los enrutadores que actúan como cortafuegos) es que eliminan todos los riesgos y
pueden proteger contra la configuración incorrecta del servidor web o el diseño deficiente de la red. Por desgracia, este no es el caso. Los cortafuegos
y los enrutadores en sí mismos son vulnerables a la configuración incorrecta y las vulnerabilidades del software. Además, muchos firewalls tienen una
visión limitada de la capa de aplicación donde ocurren muchos ataques. Por lo tanto, los servidores web en particular son vulnerables a muchos
ataques, incluso cuando se encuentran detrás de un firewall seguro y bien configurado.
Un cortafuegos (o un enrutador que actúe como cortafuegos) que protege un servidor web debe configurarse para bloquear todo acceso al servidor
web desde Internet excepto los puertos necesarios, como los puertos TCP 80 (HTTP) y 443 (HTTPS). Un firewall es la primera línea de defensa de
un servidor web; sin embargo, para estar verdaderamente seguras, las organizaciones deben implementar una protección en capas para sus
servidores web (y redes). Lo que es más importante, las organizaciones deben esforzarse por mantener todos los sistemas en una posición segura
y no depender únicamente de firewalls, enrutadores o cualquier otro componente único para detener a los atacantes.
Un enrutador empresarial moderno puede funcionar como una red y un filtro de capa de transporte (por ejemplo, un firewall básico). Un
enrutador que funciona como un firewall de capa de red/transporte puede proporcionar filtrado basado en varios datos [NIST02a], incluidos los
siguientes:
Dirección IP origen
Dirección IP de destino
tipo de tráfico
Estado y número de puerto TCP/UDP.
La fuerza de los enrutadores está en su costo. La mayoría de las organizaciones ya tienen un enrutador de borde que se puede configurar
para proporcionar capacidades de firewall de capa de red/transporte.
Las debilidades de los enrutadores incluyen lo siguiente:
Susceptibilidad a los ataques de la capa de aplicación (p. ej., no puede examinar el contenido web en busca de código malicioso incrustado)
Susceptibilidad a ataques a través de puertos permitidos
Dificultad de configuración y administración
Limitaciones en las capacidades de registro
Capacidades de procesamiento que pueden estar más limitadas y sobrecargadas por conjuntos de reglas complejas (es decir, listas de
control de acceso)
Expresividad del conjunto de reglas y capacidades de filtrado insuficientes.
67
Para obtener más información sobre los cortafuegos, consulte NIST SP 800-41, Directrices sobre cortafuegos y política de
cortafuegos (http://csrc.nist.gov/publications/nistpubs/).
8-6
Los únicos cortafuegos de capa de red "puros" disponibles en la actualidad son los dispositivos de cortafuegos para oficinas pequeñas/
oficinas domésticas (SOHO) y los cortafuegos personales [NIST02a] que solo pueden realizar un filtrado básico a nivel de paquetes.
Los cortafuegos de inspección con estado son dispositivos de capa de transporte que incorporan "conocimiento" del estado de una conexión
TCP. Los cortafuegos de inspección de estado mantienen información interna, como el estado de las conexiones que pasan a través de ellos y
el contenido de algunos de los flujos de datos. Esto permite especificar filtros y conjuntos de reglas mejores y más precisos. Los cortafuegos de
inspección con estado agregan la capacidad de aplicar reglas basadas en el estado de la conexión a las capacidades de un enrutador de filtrado.
Los cortafuegos de capa de aplicación (a veces llamados cortafuegos de puerta de enlace de proxy de aplicación) son cortafuegos avanzados
que combinan el control de acceso a la capa de red y de transporte con la funcionalidad de la capa de aplicación. Los firewalls de la capa de
aplicación no permiten el tráfico directamente entre Internet y la red interna. Por lo general, pueden realizar registros y controles de acceso
extensos.
Los cortafuegos de capa de aplicación se consideran el tipo de cortafuegos más seguro y tienen numerosas ventajas sobre los enrutadores de
filtrado de paquetes y los cortafuegos de inspección de estado, incluidos los siguientes:
Capacidades de registro
Capacidades de filtrado (puede filtrar tipos específicos de contenido web y comandos HTTP específicos)
Cumplimiento del protocolo
Validación de comportamientos de protocolo
Detección integrada basada en firmas de ataques a la capa de aplicación
Facilidad de configuración
Capacidades de autenticación de usuario.
Las principales desventajas que tienen los firewalls de capa de aplicación en comparación con los enrutadores de filtrado de paquetes y los
firewalls de inspección de estado son las siguientes:
Velocidad de rendimiento (si la plataforma no tiene el tamaño adecuado)
Costo (si se requiere hardware de alta gama para operar de manera eficiente)
Soporte inadecuado para protocolos nuevos y menos populares.
Aunque no es estrictamente una limitación, algunos firewalls de capa de aplicación se implementan en hosts que ejecutan sistemas
operativos de uso general (p. ej., Windows, Linux, Unix). Este arreglo introduce una capa adicional de complejidad y algún riesgo adicional
porque el sistema operativo de uso general también debe protegerse además del software de firewall en sí. Los cortafuegos de la capa de
aplicación se implementan cada vez más como dispositivos basados en dispositivos, que pueden utilizar sistemas operativos especializados.
Los enrutadores y los firewalls de inspección con estado también suelen ejecutarse en sistemas operativos especializados.
Para proteger con éxito un servidor web mediante un firewall, asegúrese de que el firewall esté parcheado al nivel más reciente o más
seguro (tanto la aplicación como el sistema operativo subyacente) y esté configurado para realizar lo siguiente:
Controle todo el tráfico entre Internet y el servidor web
8-7
Bloquee todo el tráfico entrante al servidor web, excepto el tráfico que sea necesario, como los puertos TCP 80
(HTTP) y/o 443 (HTTPS)
Bloquee todo el tráfico entrante con una dirección IP interna (para evitar ataques de suplantación de IP)
Bloquee las conexiones del cliente desde el servidor web a Internet y la red interna de la organización (esto reducirá el impacto de algunos
compromisos exitosos)
Bloquear (junto con el sistema de prevención o detección de intrusos [consulte la Sección 8.2.2]) direcciones IP o subredes que
el IDS o IPS informa que están atacando la red organizacional
Notificar al administrador de la red o del servidor web o al personal de seguridad apropiado sobre actividades sospechosas a
través de un medio apropiado (p. ej., página, correo electrónico, trampa de red)
Proporcionar filtrado de contenido
Protéjase contra los ataques DoS
Detectar solicitudes de URL de ataques mal formados o conocidos
Registre eventos críticos, incluidos los siguientes detalles:
Hora Fecha
Dirección IP de la interfaz
Nombre de evento específico del fabricante
Evento de ataque estándar (si existe)
Direcciones IP de origen y destino
Números de puerto de origen y destino
Protocolo de red.
La mayoría de los cortafuegos realizan algún tipo de registro del tráfico que reciben. Para la mayoría de los cortafuegos, la configuración de
registro predeterminada es adecuada, siempre que el registro esté habilitado. Los administradores deben consultar la documentación del
fabricante si creen que necesitan registrar información adicional. Ciertos cortafuegos incluyen la capacidad de rastrear y registrar información
para cada regla, lo que permite la responsabilidad en un grado muy específico.
Muchos cortafuegos admiten la capacidad de decidir selectivamente qué información registrar. Si un cortafuegos recibe una serie de paquetes
similares desde la misma ubicación, puede decidir no registrar ningún paquete adicional después del primero. Si bien esta es una característica
valiosa, tenga en cuenta las consecuencias: cada paquete que se descarta y no se registra es una evidencia potencial de intenciones maliciosas.
El principio de registro, un aspecto fundamental de la rendición de cuentas, se analiza en detalle en la Sección 9.1.
Al igual que con los sistemas operativos y otros elementos de seguridad, un firewall requiere actualizaciones. Esto incluye la actualización del
firmware para hardware y cortafuegos basados en enrutadores. Las instrucciones específicas sobre cómo actualizar un firewall se encuentran
en la documentación del fabricante. Los administradores deben buscar actualizaciones de firewall con frecuencia.
8-8
8.2.2 Sistemas de detección y prevención de intrusos
Un IDS es una aplicación que monitorea los eventos que ocurren en un sistema o red y los analiza en busca de signos de incidentes
potenciales, que son violaciones o amenazas inminentes de violación de las políticas de seguridad informática, políticas de uso
aceptable o prácticas de seguridad estándar.68 Un IPS tiene todas las capacidades de un IDS y también puede intentar detener
posibles incidentes. Debido a que los sistemas IDS e IPS ofrecen muchas de las mismas capacidades, a menudo se denominan
colectivamente sistemas de detección y prevención de intrusos (IDPS).
Cuando un IDPS detecta un posible incidente, notifica a los administradores a través de mensajes de consola, correos
electrónicos, páginas u otros mecanismos de IDPS.
Los dos tipos de IDPS más relevantes para la seguridad web son los basados en host y los basados en red.69 Un IDPS
basado en host monitorea las características de un solo host y los eventos que ocurren dentro de ese host para identificar y
detener actividades sospechosas. El software IDPS basado en host debe instalarse en cada computadora individual que se
vaya a monitorear o proteger. Los IDPS basados en host están muy integrados con los sistemas operativos de las computadoras host
que protegen. Por lo tanto, un IDPS basado en host debe diseñarse específicamente para cada sistema operativo (y, a menudo, para
cada versión de ese sistema operativo). Los IDPS basados en host monitorean varios aspectos de los hosts, como el tráfico de red,
los registros del sistema, los procesos en ejecución, el acceso y la modificación de archivos, y los cambios en la configuración del
sistema y las aplicaciones.
Los IDPS basados en host son especialmente útiles cuando la mayor parte del tráfico de red hacia y desde un servidor web
está encriptado (por ejemplo, SSL/TLS está en uso) porque la funcionalidad y la capacidad de los IDPS basados en red (ver a
continuación) están severamente limitadas cuando la red el tráfico está encriptado. Además, debido a que están ubicados en el
servidor, los IDPS basados en host pueden detectar algunos ataques e intentos de penetración no reconocidos por los IDPS basados
en red. Lamentablemente, los IDPS basados en host pueden tener un efecto negativo en el rendimiento del host. En general, habilitar
capacidades de detección más amplias y tener más eventos para monitorear tienen un impacto negativo en el rendimiento del host.
Es posible que los IDPS basados en host no detecten algunos ataques basados en la red, como ciertos ataques DoS. Si un IDPS
basado en host se encuentra en un servidor web comprometido, es muy probable que el atacante también comprometa el propio
IDPS.
Un IDPS basado en la red supervisa el tráfico de la red en busca de segmentos de red o dispositivos de red particulares y analiza la
actividad del protocolo de la red y la aplicación para identificar y detener la actividad sospechosa. La mayoría de los IDPS basados
en la red utilizan "firmas de ataque" predefinidas para detectar e identificar ataques. Las firmas de ataque son patrones que
corresponden a tipos conocidos de intrusiones. Los IDPS basados en la red también utilizan otros métodos de detección para
identificar actividades anómalas, violaciones de protocolos y otras actividades inusuales.
A diferencia de un IDPS basado en host, un IDPS basado en red puede monitorear la actividad de la red para muchos
hosts simultáneamente. Los IDPS basados en la red generalmente pueden detectar más ataques basados en la red y pueden
proporcionar más fácilmente una imagen completa de los ataques actuales contra una red. Debido a que los IDPS basados en la
red se instalan en hosts dedicados, no tienen un efecto negativo en el rendimiento del host del servidor web y no se ven
comprometidos inmediatamente por un ataque exitoso al servidor web.
Los IDPS basados en red tienen algunas limitaciones. El momento de un ataque puede tener un impacto significativo en la capacidad
de un IDPS basado en red para detectar un ataque. Por ejemplo, si un atacante extiende el tiempo de un ataque durante un período
de horas o días, es posible que IDPS no detecte el ataque. La configuración de la red, como el uso de enrutamiento asimétrico, puede
tener un impacto negativo en la capacidad de un
68
Para obtener más información sobre los IDPS, consulte NIST SP 800-94, Guía de sistemas de detección y prevención de intrusiones (IDPS)
69
Otras categorías importantes de IDPS incluyen IDPS inalámbrico, que examina únicamente los protocolos de redes inalámbricas, y el software de
detección de anomalías en el comportamiento de la red, que monitorea los flujos de tráfico de la red en busca de anomalías de flujo. Ninguno de estos
tipos de tecnologías IDPS analiza la actividad web.
8-9
IDPS basado en la red para detectar ataques. Los IDPS basados en la red también son más susceptibles de ser desactivados por ataques
DoS (incluso aquellos que no están dirigidos directamente al IDPS). Además, dependiendo de cómo se integre el IDPS basado en la red en la
red, es posible que se vea afectada negativamente la disponibilidad de la red en caso de falla del hardware del IDPS.
Tanto los IDPS basados en host como en red requieren actualizaciones frecuentes de sus bases de datos de firmas de ataques para que
puedan reconocer nuevos ataques. Un IDPS que no se actualice con frecuencia no podrá reconocer los ataques más recientes (ya menudo
los más populares). Ambos tipos de IDPS pueden tener una capacidad limitada para detectar ataques de día cero porque es poco probable
que se disponga de una firma adecuada. Un IDPS basado en host puede tener una mejor oportunidad de detectar un ataque de día cero
porque es más capaz de detectar las acciones realizadas por un atacante después de una explotación exitosa (por ejemplo, nuevas cuentas
privilegiadas no autorizadas, instalación de software malicioso).
Los verificadores de integridad de archivos son una forma simple de IDPS basados en host. Un verificador de integridad de archivos
calcula y almacena un hash para cada archivo de interés y establece una base de datos de hash de archivos. Proporciona una
herramienta para que los administradores del sistema reconozcan los cambios en los archivos, en particular los cambios no autorizados.
Los verificadores de integridad de archivos están disponibles como productos independientes y se incluyen con otras técnicas IDPS basadas
en host. Algunos IDPS basados en host pueden monitorear los intentos de acceso a archivos y detener los intentos sospechosos de leer,
modificar, eliminar y ejecutar archivos. Se podría configurar un IDPS basado en host con esta capacidad para proteger archivos importantes
del servidor web.
Para proteger con éxito un servidor web mediante un IDPS, asegúrese de que el IDPS esté configurado para:
Supervisar el tráfico de red hacia y desde el servidor web
Supervise los cambios en archivos críticos en el servidor web (capacidad de verificación de integridad de archivos)70
Supervisar los recursos del sistema disponibles en el host del servidor web (basado en host)
Bloquear (junto con el firewall) direcciones IP o subredes que están atacando la red organizacional
Notificar a las partes correspondientes (p. ej., administrador de IDPS, administrador del servidor web, equipo de respuesta a incidentes)
sobre posibles ataques a través de los medios apropiados de acuerdo con la política y los procedimientos de respuesta a incidentes
de la organización.
Detecte la mayor variedad posible de escaneos y ataques con un nivel aceptable de falsos positivos
Registrar eventos, incluidos los siguientes detalles:
Hora Fecha
Dirección IP del sensor
Nombre de ataque específico del fabricante
Nombre de ataque estándar (si existe)
70
Ciertos archivos críticos, como los archivos que almacenan contraseñas de usuario y archivos de registro, cambiarán periódicamente y, por lo tanto,
no deben protegerse con un verificador de integridad de archivos. Esta tendencia variará según el servidor web y el sistema operativo empleado.
8-10
Direcciones IP de origen y destino
Números de puerto de origen y destino
protocolo de red
Para eventos de red, capture la información del encabezado del paquete para ayudar con el proceso de análisis y análisis
forense
Actualice con nuevas firmas de ataques con frecuencia (p. ej., de forma diaria o semanal, generalmente después de probar las
actualizaciones).
Además, es fundamental que los IDPS basados en la red y sus sistemas operativos subyacentes estén reforzados porque los
IDPS basados en la red suelen ser el objetivo de los atacantes. En particular, los IDPS basados en la red no deben responder a ningún
tipo de interrogación del sistema a través de sus interfaces de monitoreo. Si se desea una gestión remota, debe realizarse a través de un
medio fuera de banda (por ejemplo, una red aislada separada). Aunque a veces son difíciles de administrar e interpretar, los IDPS son un
sistema crítico de alerta temprana que puede proporcionar al administrador del servidor web la información necesaria para defender el
servidor web de un ataque [NIST07].
8.2.3 Conmutadores de red
Los conmutadores de red son dispositivos que proporcionan conectividad entre dos o más hosts ubicados en el mismo segmento de
red. Son similares a los concentradores en que permiten las comunicaciones entre hosts, pero, a diferencia de los concentradores, los
conmutadores tienen más "inteligencia" y envían comunicaciones solo a aquellos hosts a los que se dirigen las comunicaciones. El
beneficio de esto desde el punto de vista de la seguridad es que cuando se emplean conmutadores en una red, es mucho más difícil
espiar las comunicaciones entre otros hosts en el segmento de la red. Esto es extremadamente importante cuando un servidor web está
en un segmento de red que utilizan otros hosts. Por ejemplo, si se usa un concentrador y un host en la DMZ se ve comprometido, un
atacante puede espiar las comunicaciones de otros hosts en la DMZ, lo que posiblemente comprometa esos hosts o la información que
comunican a través de la red. . Por ejemplo, los servidores de correo electrónico en sus configuraciones predeterminadas reciben
contraseñas sin cifrar; un compromiso del servidor web conduciría a la exposición de las contraseñas de correo electrónico al rastrearlas
desde el servidor web comprometido.
Muchos conmutadores incluyen configuraciones de seguridad específicas que mejoran aún más la seguridad de la red al dificultar
que una entidad malintencionada "venza" al conmutador. Algunos ejemplos incluyen la capacidad de minimizar el riesgo de
suplantación de identidad del Protocolo de resolución de direcciones (ARP) y ataques de envenenamiento de ARP.71 Si un
conmutador tiene estas capacidades de seguridad, deben estar habilitadas (consulte la documentación correspondiente del
fabricante).
Los conmutadores pueden tener un impacto negativo en los IDPS basados en la red (consulte la Sección 8.2.2). La mayoría
de los conmutadores de red permiten a los administradores de red configurar un puerto específico en el conmutador, conocido como
puerto de expansión, para que replique todo el tráfico del conmutador al puerto utilizado por el IDPS. Esto permite que un IDPS basado
en la red vea todo el tráfico en un segmento de red en particular. Sin embargo, bajo cargas altas, es posible que el conmutador deba dejar
de enviar tráfico al puerto de distribución, lo que hace que el IDPS no pueda monitorear la actividad de la red. Además, otros dispositivos
utilizan puertos de distribución y, por lo general, hay muy pocos puertos de distribución en un conmutador; por lo tanto, es posible que no
sea posible conectar un IDPS a un conmutador en particular porque todos sus puertos de distribución están en uso.
71
El envenenamiento de ARP ocurre cuando un atacante actualiza con éxito la memoria caché de ARP en un host de destino con una entrada de ARP
falsificada. Esto generalmente se usa para redirigir el tráfico de la red con fines maliciosos.
8-11
8.2.4 Equilibradores de carga
Los balanceadores de carga distribuyen las solicitudes HTTP a través de varios servidores web, lo que permite a las organizaciones
aumentar la capacidad de su sitio web agregando servidores adicionales de manera transparente. Los balanceadores de carga
actúan como servidores virtuales y reciben todas las solicitudes HTTP al sitio web. Estas solicitudes se reenvían, según la política
del equilibrador de carga, a uno de los servidores que aloja el sitio web. La política del equilibrador de carga intenta garantizar que
cada servidor reciba una cantidad similar de solicitudes. Muchos balanceadores de carga son capaces de monitorear los servidores
y compensar si uno de los servidores deja de estar disponible.
Los balanceadores de carga a menudo se complementan con mecanismos de almacenamiento en caché. Muchas de
las solicitudes HTTP que recibe el servidor web de una organización son idénticas y devuelven respuestas HTTP idénticas. Sin
embargo, cuando se utiliza la generación de contenido dinámico, estas respuestas idénticas deben generarse cada vez que se
realiza la solicitud. Para aliviar este requisito y reducir aún más la carga en los servidores web individuales, las organizaciones
pueden implementar servidores de almacenamiento en caché.
Al igual que los conmutadores de red, los balanceadores de carga no son específicamente dispositivos de seguridad, pero son
herramientas esenciales para mantener la disponibilidad de un sitio web. Al asegurarse de que varios servidores web individuales
compartan la carga, en lugar de colocarla en un solo servidor web, la organización puede resistir mejor el alto volumen de solicitudes
utilizadas en muchos ataques DoS. Los cortafuegos, conmutadores y enrutadores también deben configurarse (cuando sea posible)
para limitar la cantidad de tráfico que pasa a los servidores web, lo que reduce aún más el riesgo de ataques DoS exitosos.
8.2.5 Proxies inversos
Los proxies inversos son dispositivos que se encuentran entre un servidor web y los clientes del servidor. El término "proxy inverso"
se utiliza porque el flujo de datos es el inverso de un proxy tradicional (directo). Los proxies inversos pueden servir como una valiosa
adición a la seguridad de un servidor web. El término proxy inverso se usa de forma poco estricta en la industria y puede incluir algunas
o todas las siguientes funciones:
Aceleradores de cifrado, que descargan el costoso procesamiento computacional necesario para iniciar conexiones SSL/
TLS
Puertas de enlace de seguridad, que monitorean el tráfico HTTP hacia y desde el servidor web en busca de posibles ataques y
toman las medidas necesarias, actuando en esencia como un firewall a nivel de aplicación.
Filtros de contenido, que pueden monitorear el tráfico hacia y desde el servidor web en busca de datos potencialmente
confidenciales o inapropiados y tomar las medidas necesarias.
Puertas de enlace de autenticación, que autentican a los usuarios a través de una variedad de mecanismos y controlan el acceso
a las URL alojadas en el propio servidor web.
Se deben considerar los proxies inversos para cualquier implementación de servidor web de alto riesgo. Si bien agregan riesgo al
requerir la implementación de hardware y software adicional, el riesgo generalmente se ve compensado por los beneficios. Además de
la lista de funciones anterior, los proxies web también son valiosos porque agregan una capa adicional entre un servidor web y sus
usuarios menos confiables. Debido a su naturaleza altamente especializada, los servidores proxy son más fáciles de proteger que los
servidores web. Los servidores proxy también ofuscan aún más la configuración, el tipo, la ubicación y otros detalles de un servidor
web que son pertinentes para los atacantes. Por ejemplo, los servidores web tienen pancartas que frecuentemente revelan el tipo y la
versión del servidor web y, a veces, estas pancartas no se pueden cambiar. Con un proxy inverso, esto no es un problema porque el
proxy puede reescribir el banner antes de enviarlo a los usuarios.
8-12
8.3 Lista de verificación para implementar una infraestructura de red segura
Terminado Acción
Identificar la ubicación de la red
El servidor web está ubicado en una DMZ, o el alojamiento del servidor web está subcontratado
Evaluar la configuración del cortafuegos
El servidor web está protegido por un firewall; si enfrenta una amenaza mayor o es más vulnerable, está protegido por un firewall
de capa de aplicación
El cortafuegos controla todo el tráfico entre Internet y el servidor web
El cortafuegos bloquea todo el tráfico entrante al servidor web excepto los puertos TCP 80 (HTTP) y/o 443
(HTTPS), si es necesario
El cortafuegos bloquea (junto con el IDPS) las direcciones IP o las subredes que, según los informes del IDPS, están atacando la red
de la organización
Firewall notifica al administrador de la red o del servidor web de actividad sospechosa a través de un medio apropiado
Firewall proporciona filtrado de contenido (firewall de capa de aplicación)
El cortafuegos está configurado para proteger contra ataques DoS
El cortafuegos detecta solicitudes de URL de ataques mal formados o conocidos
Firewall registra eventos críticos
El cortafuegos y el sistema operativo del cortafuegos están parcheados al nivel más reciente o más seguro
Evaluar los sistemas de detección y prevención de intrusos
El IDPS basado en host se utiliza para servidores web que funcionan principalmente con SSL/TLS.
IDPS está configurado para monitorear el tráfico de red hacia y desde el servidor web después del firewall
IDPS está configurado para monitorear cambios en archivos críticos en el servidor web (IDPS basado en host o verificador de
integridad de archivos)
IDPS bloquea (junto con el firewall) direcciones IP o subredes que están atacando la red organizacional
IDPS notifica a los administradores de IDPS o al administrador del servidor web sobre los ataques a través de los medios
apropiados
IDPS está configurado para maximizar la detección con un nivel aceptable de falsos positivos
IDPS está configurado para registrar eventos
IDPS se actualiza con nuevas firmas de ataques con frecuencia (por ejemplo, diariamente)
El IDPS basado en host está configurado para monitorear los recursos del sistema disponibles en el host del servidor web.
Evaluar conmutadores de red
Los conmutadores se utilizan para proteger contra las escuchas ilegales de la red
Los conmutadores están configurados en modo de alta seguridad para vencer los ataques de suplantación de identidad y envenenamiento
de ARP
Los switches están configurados para enviar todo el tráfico en el segmento de la red a IDPS basados en la red
Evaluar balanceadores de carga
Los balanceadores de carga se utilizan para aumentar la disponibilidad del servidor web
Los balanceadores de carga se complementan con cachés web, si corresponde
Evaluar proxies inversos
Los proxies inversos se utilizan como puerta de enlace de seguridad para aumentar la disponibilidad del servidor web
Los proxies inversos se complementan con capacidades de aceleración de cifrado, autenticación de usuarios y filtrado de
contenido, si corresponde.
8-13
9. Administrar el servidor web

Después de implementar inicialmente un servidor web, los administradores deben mantener su seguridad de forma continua. Esta sección
proporciona recomendaciones generales para la administración segura de servidores web. Las actividades vitales incluyen el manejo y
análisis de archivos de registro, la realización de copias de seguridad periódicas del servidor web, la recuperación de compromisos del
servidor web, la prueba periódica de la seguridad del servidor web y la realización de una administración remota segura.
9.1 Registro
El registro es la piedra angular de una sólida postura de seguridad. Capturar los datos correctos en los registros y luego monitorear esos
registros de cerca es vital.72 Los registros de la red y del sistema son importantes, especialmente los registros del sistema en el caso de las
comunicaciones protegidas por HTTPS, donde el monitoreo de la red es menos efectivo. El software del servidor web puede proporcionar datos
de registro adicionales relevantes para eventos específicos de la web. De manera similar, las aplicaciones web también pueden mantener sus
propios registros de acciones.
La revisión de registros es mundana y reactiva, y muchos administradores de servidores web dedican su tiempo a realizar tareas que
consideran más importantes o urgentes. Sin embargo, los archivos de registro suelen ser el único registro de comportamiento sospechoso.
Habilitar los mecanismos para registrar información permite que los registros se utilicen para detectar intentos de intrusión fallidos y exitosos y
para iniciar mecanismos de alerta cuando se necesita más investigación. Deben existir procedimientos y herramientas para procesar y analizar
los archivos de registro y revisar las notificaciones de alerta.
Los registros del servidor web proporcionan:
Alertas de actividades sospechosas que requieren mayor investigación
Seguimiento de las actividades de un atacante
Asistencia en la recuperación del sistema
Asistencia en la investigación posterior al evento
Información requerida para trámites judiciales.
La selección e implementación de un software de servidor web específico determina qué conjunto de instrucciones detalladas
(presentadas a continuación) debe seguir el administrador del servidor web para establecer las configuraciones de registro. Es posible
que parte de la información contenida en los pasos a continuación no sea completamente aplicable a los productos de software de servidor
web de todos los fabricantes.
9.1.1 Identificación de las capacidades de registro de un servidor web
Cada tipo de software de servidor web admite diferentes capacidades de registro. Según el software del servidor web utilizado, uno o más de
los siguientes registros pueden estar disponibles [Alle00]:
Registro de transferencias : cada transferencia se representa como una entrada que muestra la información principal relacionada con la
transferencia.
72
Para obtener más información sobre el registro, consulte NIST SP 800-92, Guía para la gestión de registros de seguridad informática, que está
disponible en http://csrc.nist.gov/publications/nistpubs/.
9-1
Registro de errores : cada error se representa como una entrada, incluida una explicación del motivo de este informe de error.
Registro del agente : este registro contiene información sobre el software cliente del usuario utilizado para acceder al contenido web.
Registro de referencia : este registro recopila información relevante para el acceso HTTP. Esto incluye la URL de la página que
contenía el enlace que el software de cliente del usuario siguió para iniciar el acceso a la página web.
La mayoría de los servidores web admiten el Registro de transferencias y, por lo general, se considera el más importante. Hay varios
formatos de registro disponibles para las entradas del registro de transferencia. Por lo general, la información se presenta en el Código
estándar estadounidense para el intercambio de información (ASCII) sin delimitadores especiales para separar los diferentes campos
[Alle00]:
Formato de registro común (CLF): este formato almacena información relacionada con una transferencia (Registro de transferencia)
en el siguiente orden:
Servidor remoto
Identidad de usuario remoto de acuerdo con RFC 141373
Usuario autenticado de acuerdo con el esquema básico de autenticación (ver Sección 7.3)
Fecha
URL solicitada
Estado de la solicitud
Número de bytes realmente transferidos.
Formato de registro combinado: este formato contiene los mismos siete campos anteriores. También proporciona
información que normalmente se almacena en el Registro del agente y el Registro del remitente, junto con la transferencia real.
Mantener esta información en un formato de registro consolidado puede ayudar a una administración más eficaz.
Formato de registro extendido: este formato proporciona una manera de describir todos los elementos que deben recopilarse
dentro del archivo de registro. Las dos primeras líneas del archivo de registro contienen la versión y los campos a recopilar, y
aparecen en el archivo de registro de la siguiente manera:
#Versión: 1.0
#Campos: fecha hora c-ip sc-bytes time-take cs-version 1999-08-01
02:10:57 192.0.0.2 6340 3 HTTP/1.0
Este ejemplo contiene la fecha, la hora, la dirección de origen, la cantidad de bytes transmitidos, el tiempo necesario para la
transmisión y la versión de HTTP.
Otros formatos de archivo de registro: algún software de servidor proporciona información de registro en diferentes formatos
de archivo, como formatos de base de datos o formatos separados por delimitadores. Otro software de servidor proporciona la
73
Consulte el sitio web de IETF: http://www.ietf.org/rfc/rfc1413.txt.
9-2
capacidad para que un administrador defina formatos de archivo de registro específicos en el archivo de configuración del servidor web
usando una sintaxis particular (si el formato CLF predeterminado es insuficiente).
9.1.2 Identificación de requisitos de registro adicionales
Si un servidor web público admite la ejecución de programas, secuencias de comandos o complementos, puede ser necesario que los programas,
secuencias de comandos o complementos realicen registros adicionales. A menudo, los eventos críticos tienen lugar dentro del propio código de
la aplicación web y no serán registrados por el servidor web. Si los webmasters desarrollan o adquieren programas de aplicación, scripts o
complementos, se recomienda encarecidamente que definan e implementen un enfoque de registro completo y fácil de entender basado en los
mecanismos de registro proporcionados por el sistema operativo del servidor web. La información de registro asociada con programas, scripts y
complementos puede agregarse significativamente a la información típica registrada por el servidor web y puede resultar invaluable al investigar
eventos.
9.1.3 Configuración de registro genérico recomendada
La siguiente configuración es un buen punto de partida para iniciar sesión en servidores web públicos [Alle00]:
Utilice el formato de registro combinado para almacenar el Registro de transferencia o configure manualmente la información descrita
por el formato de registro combinado para que sea el formato estándar para el Registro de transferencia.
Habilite el registro de referencia o el registro de agente si el formato de registro combinado no está disponible.
Establezca diferentes nombres de archivo de registro para diferentes sitios web virtuales que pueden implementarse como parte de un
único servidor web físico.
Utilice la identidad de usuario remoto como se especifica en RFC 1413.
Asegúrese de que existan procedimientos o mecanismos para que los archivos de registro no llenen el disco duro.
Garantizar que haya suficiente capacidad de registro disponible es una preocupación porque los registros a menudo ocupan mucho más
espacio de lo que los administradores estiman inicialmente, especialmente cuando el registro se establece en un nivel muy detallado.
Los administradores deben monitorear de cerca el tamaño de los archivos de registro cuando implementan diferentes configuraciones de
registro para asegurarse de que los archivos de registro no llenen el almacenamiento asignado. Debido al tamaño de los archivos de registro,
puede ser necesario eliminar y archivar los registros con mayor frecuencia o reducir el nivel de detalle del registro.
Algunos programas de servidor web brindan la capacidad de aplicar o deshabilitar la verificación de controles de acceso específicos
durante el inicio del programa. Este nivel de control puede ser útil, por ejemplo, para evitar la alteración inadvertida de archivos de registro
debido a errores en la administración de acceso a archivos. Los administradores del servidor web deben determinar las circunstancias en las
que pueden desear habilitar dichas comprobaciones (suponiendo que el software del servidor web admita esta función).
9.1.4 Revisión y conservación de archivos de registro
Revisar los archivos de registro es una tarea tediosa y lenta que informa a los administradores de los eventos que ya han ocurrido. En
consecuencia, los archivos suelen ser útiles para corroborar otras pruebas, como un pico de utilización de la CPU o un tráfico de red anómalo
informado por un IDPS. Cuando se usa un registro para corroborar otra evidencia, se requiere una revisión enfocada. Por ejemplo, si un IDPS
informó una conexión FTP saliente desde el servidor web a las 8:17 am, entonces es apropiado revisar los registros generados alrededor de
las 8:17 am. Los registros del servidor web también deben revisarse en busca de indicaciones de ataques. La frecuencia de las revisiones
depende de los siguientes factores:
9-3
Cantidad de tráfico que recibe el servidor
Nivel de amenaza general (ciertos sitios reciben muchos más ataques que otros sitios y, por lo tanto, sus registros deben revisarse con
mayor frecuencia)
Amenazas específicas (en ciertos momentos, surgen amenazas específicas que pueden requerir un análisis de archivos de registro
más frecuente)
Vulnerabilidad del servidor web
Valor de los datos y servicios proporcionados por el servidor Web.
Las revisiones deben realizarse con regularidad (por ejemplo, diariamente) y cuando se detecte una actividad sospechosa o se emita una advertencia
de amenaza. Obviamente, la tarea podría convertirse rápidamente en una carga para el administrador de un servidor web. Para reducir esta carga, se
han desarrollado herramientas de análisis de registros automatizados (consulte la Sección 9.1.5).
Además, se necesita un análisis a largo plazo y más profundo de los registros. Debido a que un ataque típico a un servidor web puede involucrar
cientos de solicitudes únicas, un atacante puede intentar disfrazar un ataque a un servidor web aumentando el intervalo entre solicitudes. En este
caso, es posible que la revisión de los registros de un solo día o de una semana no muestre tendencias reconocibles. Sin embargo, cuando se analizan
las tendencias durante una semana, un mes o un trimestre, se pueden reconocer más fácilmente varios ataques del mismo host o subred.
Los archivos de registro deben protegerse para garantizar que si un atacante compromete un servidor web, los archivos de registro no se pueden
modificar para cubrir el ataque. Aunque el cifrado puede ser útil para proteger los archivos de registro, la mejor solución es almacenar los archivos de
registro en un host separado del servidor web. Esto a menudo se denomina servidor de registro centralizado. El registro centralizado a menudo se
realiza usando syslog, que es un protocolo de registro estándar.74 Alternativamente, algunas organizaciones usan software de administración de
eventos e información de seguridad (SIEM) que usa servidores centralizados para realizar análisis de registros, servidores de bases de datos para
almacenar registros y agentes instalados en los hosts o procesos individuales que se ejecutan en los servidores centralizados para transferir registros
del servidor web o datos de registro de los hosts a los servidores y analizar los registros.75
Los archivos de registro deben respaldarse y archivarse con regularidad. El archivado de archivos de registro durante un período de tiempo
es importante por varias razones, incluida la compatibilidad con ciertas acciones legales y la resolución de problemas con el servidor web. El
período de retención de los archivos de registro archivados depende de varios factores, incluidos los siguientes:
Requerimientos legales
Requisitos organizativos
Tamaño de los registros (que está directamente relacionado con el tráfico del sitio y la cantidad de detalles registrados)
Valor de los datos y servicios del servidor web
Nivel de amenaza.
74
Syslog se define en IETF RFC 3164, The BSD Syslog Protocol, que está disponible en http://www.ietf.org/rfc/rfc3164.txt.
75
Se proporciona más información sobre las implementaciones de syslog y SIEM en NIST SP 800-92, Guía para la gestión de registros de
seguridad informática, que está disponible en http://csrc.nist.gov/publications/nistpubs/.
9-4
9.1.5 Herramientas de análisis de archivos de registro automatizados
La mayoría de los servidores web públicos reciben cantidades significativas de tráfico y los archivos de registro se vuelven voluminosos
rápidamente. Se deben instalar herramientas de análisis de registros automatizados para aliviar la carga del administrador del servidor
web. Estas herramientas analizan las entradas en los archivos de registro del servidor web e identifican actividades sospechosas e inusuales.
Como se mencionó en la Sección 9.1.2, algunas organizaciones utilizan el software SIEM para el registro centralizado, que también puede
realizar análisis de archivos de registro automatizados.
Muchas herramientas comerciales y de dominio público están disponibles para respaldar el análisis regular de los registros de transferencia.
La mayoría opera en formatos de registro comunes o combinados. Estas herramientas pueden identificar las direcciones IP que son la fuente
de un gran número de conexiones y transferencias.
Las herramientas de registro de errores indican no solo los errores que pueden existir en el contenido web disponible (como archivos que
faltan), sino también los intentos de acceder a direcciones URL inexistentes. Tales intentos podrían indicar lo siguiente:
Sondeos de la existencia de vulnerabilidades para ser utilizados posteriormente en el lanzamiento de un ataque
Recopilación de información
Interés por contenidos específicos, como bases de datos.
El analizador de registros automatizado debe enviar cualquier evento sospechoso al administrador del servidor web responsable o al
equipo de respuesta a incidentes de seguridad lo antes posible para una investigación de seguimiento. Algunas organizaciones pueden desear
utilizar dos o más analizadores de registro, lo que reducirá el riesgo de perder un atacante u otros eventos significativos en los archivos de
registro [NIST06b].
9.2 Procedimientos de copia de seguridad del servidor web
Una de las funciones más importantes de un administrador de servidor web es mantener la integridad de los datos en el servidor web. Esto es
importante porque los servidores web suelen ser algunos de los servidores más expuestos y vitales en la red de una organización. Hay dos
componentes principales para hacer una copia de seguridad de los datos en un servidor web: una copia de seguridad periódica de los datos y el
sistema operativo en el servidor web, y el mantenimiento de una copia autorizada protegida separada del contenido web de la organización.
9.2.1 Políticas y estrategias de copia de seguridad del servidor web
El administrador del servidor web necesita realizar copias de seguridad del servidor web periódicamente por varias razones. Un servidor web
podría fallar como resultado de un acto malicioso o no intencional o una falla de hardware o software. Además, las agencias federales y muchas
otras organizaciones se rigen por normas sobre la copia de seguridad y el archivo de datos del servidor web. Los datos del servidor web también
deben respaldarse regularmente por razones legales y financieras.
Todas las organizaciones necesitan crear una política de copia de seguridad de datos del servidor web. Tres factores principales influyen
en el contenido de esta política:
Requerimientos legales
Leyes y reglamentos aplicables (federales, estatales e internacionales)
Requisitos de litigio
Requisitos de la misión
9-5
Contractual
Prácticas aceptadas
Criticidad de los datos para la organización
Lineamientos y políticas organizacionales.
Aunque la política de copia de seguridad del servidor web de cada organización será diferente para reflejar su entorno particular, debe
abordar los siguientes problemas:
Propósito de la póliza
Partes afectadas por la póliza
Servidores web cubiertos por la póliza
Definiciones de términos clave, especialmente legales y técnicos
Requisitos detallados desde la perspectiva legal, comercial y de la organización.
Frecuencia requerida de copias de seguridad
Procedimientos para garantizar que los datos se retengan y protejan adecuadamente
Procedimientos para garantizar que los datos se destruyan o archiven correctamente cuando ya no se necesiten
Procedimientos para preservar información para solicitudes de la Ley de Libertad de Información (FOIA), investigaciones legales y
otras solicitudes similares
Responsabilidades de los involucrados en las actividades de retención, protección y destrucción de datos
Período de retención para cada tipo de información registrada76
Deberes específicos de un equipo de respaldo de datos central/organizacional, si existe.
Existen tres tipos principales de copias de seguridad: completas, incrementales y diferenciales. Las copias de seguridad completas incluyen el
sistema operativo, las aplicaciones y los datos almacenados en el servidor web (es decir, una imagen de cada dato almacenado en los discos duros
del servidor web). La ventaja de una copia de seguridad completa es que es fácil restaurar todo el servidor web al estado (por ejemplo, configuración,
nivel de parche, datos) en el que se encontraba cuando se realizó la copia de seguridad. La desventaja de las copias de seguridad completas es que
requieren mucho tiempo y recursos para realizarse. Las copias de seguridad incrementales reducen el impacto de las copias de seguridad al hacer una
copia de seguridad solo de los datos que han cambiado desde la copia de seguridad anterior (ya sea completa o incremental).
Las copias de seguridad diferenciales reducen la cantidad de conjuntos de copias de seguridad a los que se debe acceder para restaurar una configuración mediante la
copia de seguridad de todos los datos modificados desde la última copia de seguridad completa. Sin embargo, cada copia de seguridad diferencial aumenta a medida que
76
Las organizaciones deben considerar cuidadosamente el período de retención de los registros de transacciones web y otros registros relacionados con el servidor web.
Muchas organizaciones están sujetas a múltiples conjuntos de requisitos legales y reglamentarios que pueden afectar la retención de registros web. La Administración
Nacional de Archivos y Registros (NARA) tiene un sitio web para la administración de registros federales, que se encuentra en http://www.archives.gov/records-
mgmt/.
9-6
transcurre el tiempo desde la última copia de seguridad completa, lo que requiere más tiempo de procesamiento y almacenamiento
que una copia de seguridad incremental. Por lo general, las copias de seguridad completas se realizan con menos frecuencia (semanal a
mensual o cuando se produce un cambio significativo) y las copias de seguridad incrementales o diferenciales se realizan con mayor
frecuencia (diaria a semanal). La frecuencia de las copias de seguridad estará determinada por varios factores:
Volatilidad de la información en el sitio Web
Contenido web estático (copias de seguridad menos frecuentes)
Contenido web dinámico (copias de seguridad más frecuentes)
Comercio electrónico/gobierno electrónico (copias de seguridad muy frecuentes)
Volatilidad de configurar el servidor Web
Cantidad de datos a respaldar
Dispositivo de respaldo y medios disponibles
Tiempo disponible para volcar datos de respaldo
Criticidad de los datos
Nivel de amenaza que enfrenta el servidor Web
Esfuerzo requerido para la reconstrucción de datos sin respaldo de datos
Otras funciones de copia de seguridad o redundancia de datos del servidor web (p. ej., matriz redundante de discos económicos
[RAID]).
9.2.2 Mantener un servidor web de prueba
La mayoría de las organizaciones probablemente deseen mantener un servidor web de prueba o desarrollo. Idealmente, este servidor debería
tener hardware y software idénticos al servidor web de producción o en vivo y estar ubicado en un segmento de red interna (intranet) donde
pueda estar totalmente protegido por las defensas de la red perimetral de la organización. Aunque el costo de mantener un servidor web
adicional no es insignificante, tener un servidor web de prueba ofrece numerosas ventajas:
Proporciona una plataforma para probar nuevos parches y paquetes de servicio antes de la aplicación en el servidor web de
producción.
Proporciona una plataforma de desarrollo para que el webmaster y el administrador del servidor web desarrollen y prueben nuevos
contenidos y aplicaciones.
Proporciona una plataforma para probar los ajustes de configuración antes de aplicarlos a los servidores web de producción.
El software crítico para el desarrollo y las pruebas, pero que podría representar un riesgo de seguridad inaceptable en el servidor de
producción, se puede instalar en el servidor de desarrollo (por ejemplo, compiladores de software, kits de herramientas administrativas,
software de acceso remoto).
El servidor web de prueba debe estar separado del servidor que mantiene una copia autorizada del contenido en el servidor web de producción
(consulte la Sección 9.2.3).
9-7
9.2.3 Mantener una copia autorizada del contenido web de la organización
Todas las organizaciones deben mantener una copia autorizada (es decir, verificada y de confianza) de sus sitios web públicos en un host
al que no se pueda acceder desde Internet. Este es un complemento, pero no un reemplazo, de una política de copia de seguridad
adecuada (consulte la Sección 9.2.1). Para sitios web simples y relativamente estáticos, esto podría ser tan simple como una copia del sitio
web en un medio de sólo lectura (por ejemplo, disco compacto grabable [CD-R]).
Sin embargo, para la mayoría de las organizaciones, la copia autorizada del sitio web se mantiene en un servidor seguro.
Este host generalmente se encuentra detrás del firewall de la organización en la red interna y no en la DMZ (consulte la Sección 8.1.2).
El propósito de la copia autorizada es proporcionar un medio para restaurar la información en el servidor web público si se ve
comprometida como resultado de un accidente o una acción malintencionada.
Esta copia autorizada del sitio web permite que una organización se recupere rápidamente de las infracciones de integridad del sitio web (p. ej.,
desfiguración).
Para lograr con éxito el objetivo de proporcionar y proteger una copia autorizada del contenido del servidor web, se deben cumplir los siguientes
requisitos:
Proteja la copia autorizada del acceso no autorizado.
Use medios de una sola escritura (apropiados para sitios web relativamente estáticos).
Ubique el host con la copia autorizada detrás de un firewall y asegúrese de que no haya acceso externo al host.
Minimice los usuarios con acceso autorizado al host.
Controle el acceso de los usuarios de la manera más granular posible.
Emplee una fuerte autenticación de usuario.
Emplear procedimientos apropiados de registro y monitoreo.
Considere copias autorizadas adicionales en diferentes ubicaciones físicas para una mayor protección.
Establecer procedimientos apropiados de actualización de copias autorizadas.
Primero actualice la copia autorizada (cualquier prueba en el código debe realizarse antes de actualizar la copia
autorizada).
Establezca políticas y procedimientos sobre quién puede autorizar actualizaciones, quién puede realizar actualizaciones, cuándo
pueden ocurrir actualizaciones, etc.
Establezca un proceso para copiar una copia autorizada en un servidor web de producción.
Transferir datos físicamente utilizando medios físicos seguros (p. ej., medios cifrados y/o de escritura única, como CD-R).
Utilice un protocolo seguro (p. ej., SSH) para las transferencias de red.
Incluya los procedimientos para restaurar a partir de la copia autorizada en los procedimientos de respuesta a incidentes de la
organización (consulte la Sección 9.3).
9-8
Considere la posibilidad de realizar actualizaciones automáticas desde la copia autorizada al servidor web periódicamente (por
ejemplo, cada 15 minutos, cada hora o diariamente) porque esto sobrescribirá la desfiguración de un sitio web automáticamente.
9.3 Recuperación de un compromiso de seguridad
La mayoría de las organizaciones eventualmente enfrentan un compromiso exitoso de uno o más hosts en su red. El primer paso para
recuperarse de un compromiso es crear y documentar las políticas y procedimientos requeridos para responder a intrusiones exitosas
antes de una intrusión.77 Los procedimientos de respuesta deben describir las acciones que se requieren para responder a un
compromiso exitoso del servidor web y el secuencia apropiada de estas acciones (la secuencia puede ser crítica). La mayoría de las
organizaciones ya cuentan con un equipo de respuesta a incidentes dedicado, al que se debe contactar de inmediato cuando hay
sospecha o confirmación de un compromiso. Además, es posible que la organización desee asegurarse de que parte de su personal
tenga conocimientos en los campos de análisis forense informático y de redes.78
Un administrador del servidor web debe seguir las políticas y los procedimientos de la organización para el manejo de
incidentes, y se debe contactar al equipo de respuesta a incidentes para obtener orientación antes de que la organización tome alguna
medida después de un compromiso de seguridad sospechado o confirmado. Ejemplos de pasos que se realizan comúnmente después
de descubrir un compromiso exitoso son los siguientes:
Informe el incidente a la capacidad de respuesta a incidentes informáticos de la organización.
Aísle los sistemas comprometidos o tome otras medidas para contener el ataque de modo que se pueda recopilar
información adicional.79
Consultar con prontitud, según corresponda, con la gerencia, el asesor legal y las fuerzas del orden.
Investigue hosts similares80 para determinar si el atacante también ha comprometido otros sistemas.
Analice la intrusión, incluidos:
El estado actual del servidor, comenzando con los datos más efímeros (p. ej., conexiones de red actuales, volcado de
memoria, marcas de tiempo de archivos, usuarios registrados)
Modificaciones realizadas en el software y configuración del sistema
Modificaciones realizadas en los datos
Herramientas o datos dejados por el atacante
Archivos de registro del sistema, detección de intrusos y firewall.
77
Para obtener más información sobre esta área, consulte NIST SP 800-61, Guía de manejo de incidentes de seguridad informática, y NIST SP 800-18
Revisión 1, Guía para desarrollar planes de seguridad para sistemas de información federales.
78
Hay más información disponible sobre informática y análisis forense de redes en NIST SP 800-86, Guía para la integración de técnicas forenses
en la respuesta a incidentes (http://csrc.nist.gov/publications/nistpubs/).
79
El aislamiento del sistema debe realizarse con sumo cuidado si la organización desea recopilar pruebas. Muchos atacantes configuran sistemas
comprometidos para borrar evidencia si un sistema comprometido se desconecta de la red o se reinicia.
Un método para aislar un sistema sería reconfigurar el conmutador o enrutador ascendente más cercano.
80
Los hosts similares incluirían hosts que están en el mismo rango de direcciones IP, tienen contraseñas iguales o similares, comparten una
relación de confianza y/o tienen el mismo sistema operativo y/o aplicaciones.
9-9
Restaurar el sistema.
Instale una versión limpia del sistema operativo, las aplicaciones, los parches necesarios y el contenido web; o restaurar
el sistema desde las copias de seguridad (esta opción puede ser más riesgosa porque las copias de seguridad pueden
haberse realizado después del compromiso, y la restauración desde una copia de seguridad comprometida aún puede
permitir que el atacante acceda al sistema).
Deshabilite los servicios innecesarios.
Aplicar todos los parches.
Cambie todas las contraseñas (incluso en hosts no comprometidos, si se cree que sus contraseñas han sido vistas por el host
comprometido, o si se usan las mismas contraseñas en otros hosts).
Reconfigure los elementos de seguridad de la red (p. ej., firewall, enrutador, IDPS) para brindar protección y
notificación adicionales.
Sistema de prueba para garantizar la seguridad.
Vuelva a conectar el sistema a la red.
Supervise el sistema y la red en busca de señales de que el atacante está intentando acceder al sistema o la red nuevamente.
Documentar las lecciones aprendidas.
Según la política y los procedimientos de la organización, los administradores del sistema deben decidir si reinstalar el sistema
operativo de un sistema comprometido o restaurarlo desde una copia de seguridad. Los factores que a menudo se consideran
incluyen los siguientes:
Nivel de acceso que obtuvo el atacante (p. ej., raíz, usuario, invitado, sistema)
Tipo de atacante (interno o externo)
Propósito del compromiso (p. ej., alteración de la página web, depósito de software ilegal, plataforma para otros ataques)
Método utilizado para el compromiso del sistema
Acciones del atacante durante y después del compromiso (p. ej., archivos de registro, informes de detección de intrusos)
Duración del compromiso
Alcance del compromiso en la red (p. ej., la cantidad de hosts comprometidos)
Resultados de la consulta con la gerencia y el asesor legal.
Cuanto menor sea el nivel de acceso obtenido por el intruso y cuanto más entienda el administrador del servidor web
acerca de las acciones del atacante, menor será el riesgo de restaurar desde una copia de seguridad y parchear la vulnerabilidad. Para
incidentes en los que se sabe menos sobre las acciones del atacante y/o en los que el atacante obtiene acceso de alto nivel, se
recomienda reinstalar el sistema operativo y las aplicaciones desde el
9-10
el medio de distribución original del fabricante y que los datos del servidor web se restauren a partir de una copia de seguridad en buen
estado.
Si se inicia una acción legal, los administradores del sistema deben conocer las pautas para manejar un host después de un
compromiso. Consulte a un asesor legal y a las autoridades policiales pertinentes, según corresponda.
9.4 Pruebas de seguridad de los servidores web
Las pruebas periódicas de seguridad de los servidores web públicos son fundamentales. Sin pruebas periódicas, no hay garantía de que
las medidas de protección actuales funcionen o que el parche de seguridad aplicado por el administrador del servidor web funcione como
se anuncia. Aunque existe una variedad de técnicas de prueba de seguridad, la exploración de vulnerabilidades es la más común. El
escaneo de vulnerabilidades ayuda al administrador del servidor web a identificar vulnerabilidades y verificar si las medidas de seguridad
existentes son efectivas. También se utilizan pruebas de penetración, pero con menos frecuencia y, por lo general, solo como parte de una
prueba de penetración general de la red de la organización.81
9.4.1 Exploración de vulnerabilidades
Los escáneres de vulnerabilidades son herramientas automatizadas que se utilizan para identificar vulnerabilidades y configuraciones
incorrectas de hosts. Muchos escáneres de vulnerabilidades también brindan información sobre cómo mitigar las vulnerabilidades
descubiertas.
Los escáneres de vulnerabilidades intentan identificar vulnerabilidades en los hosts escaneados. Los escáneres de vulnerabilidades pueden
ayudar a identificar versiones de software desactualizadas, parches faltantes o actualizaciones del sistema, y pueden validar el cumplimiento
o las desviaciones de la política de seguridad de la organización. Para lograr esto, los escáneres de vulnerabilidades identifican los sistemas
operativos y las principales aplicaciones de software que se ejecutan en los hosts y los comparan con las vulnerabilidades conocidas en
sus bases de datos de vulnerabilidades.
Sin embargo, los escáneres de vulnerabilidades tienen algunas debilidades significativas. Por lo general, solo identifican vulnerabilidades
superficiales y no pueden abordar el nivel de riesgo general de un servidor web escaneado. Aunque el proceso de escaneo en sí está
altamente automatizado, los escáneres de vulnerabilidades pueden tener una alta tasa de errores de falsos positivos (informando
vulnerabilidades cuando no existen). Esto significa que una persona con experiencia en seguridad y administración de servidores web debe
interpretar los resultados. Además, los escáneres de vulnerabilidades generalmente no pueden identificar vulnerabilidades en aplicaciones
o códigos personalizados.
Los escáneres de vulnerabilidades se basan en la actualización periódica de la base de datos de vulnerabilidades para reconocer
las vulnerabilidades más recientes. Antes de ejecutar cualquier escáner, los administradores del servidor web deben instalar las últimas
actualizaciones de su base de datos de vulnerabilidades. Algunas bases de datos se actualizan con más regularidad que otras (la frecuencia
de las actualizaciones debe ser una consideración importante al elegir un escáner de vulnerabilidades).
Los escáneres de vulnerabilidades a menudo son mejores para detectar vulnerabilidades conocidas que las más esotéricas porque es
imposible que cualquier producto de escaneo incorpore todas las vulnerabilidades conocidas de manera oportuna. Además, los fabricantes
desean mantener alta la velocidad de sus escáneres (cuantas más vulnerabilidades se detecten, más pruebas se requerirán, lo que
ralentiza el proceso de escaneo en general). Por lo tanto, los escáneres de vulnerabilidades pueden ser menos útiles para los
administradores de servidores web que operan servidores web, sistemas operativos o aplicaciones codificadas a la medida menos
populares.
Los escáneres de vulnerabilidad proporcionan las siguientes capacidades:
81
Para obtener información sobre otras técnicas de prueba, consulte NIST SP 800-42, Directriz sobre pruebas de seguridad
de red (http://csrc.nist.gov/publications/nistpubs/).
9-11
Identificación de hosts activos en una red
Identificar servicios activos (puertos) en hosts y cuáles de ellos son vulnerables
Identificación de aplicaciones y captación de banners
Identificación de sistemas operativos
Identificación de vulnerabilidades asociadas con sistemas operativos y aplicaciones descubiertos
Probar el cumplimiento de las políticas de uso/seguridad de la aplicación host.
Las organizaciones deben realizar un análisis de vulnerabilidades para validar que los sistemas operativos y las aplicaciones del servidor web
estén actualizados con los parches de seguridad y las versiones de software. El escaneo de vulnerabilidades es una actividad laboriosa que
requiere un alto grado de participación humana para interpretar los resultados. También puede interrumpir las operaciones al consumir ancho
de banda de la red, ralentizar los tiempos de respuesta de la red y afectar potencialmente la disponibilidad del servidor escaneado o sus
aplicaciones. Sin embargo, el escaneo de vulnerabilidades es extremadamente importante para garantizar que las vulnerabilidades se mitiguen
lo antes posible, antes de que los adversarios las descubran y las exploten. El análisis de vulnerabilidades debe realizarse semanal o
mensualmente.
Muchas organizaciones también ejecutan un análisis de vulnerabilidades cada vez que se publica una nueva base de datos de
vulnerabilidades para la aplicación de análisis de la organización. Los resultados del escaneo de vulnerabilidades deben documentarse y
las deficiencias descubiertas deben corregirse.
Las organizaciones también deberían considerar ejecutar más de un escáner de vulnerabilidades. Como se discutió anteriormente,
ningún escáner puede detectar todas las vulnerabilidades conocidas; sin embargo, el uso de dos escáneres generalmente aumenta la
cantidad de vulnerabilidades detectadas. Una práctica común es utilizar un escáner comercial y uno gratuito. Los escáneres de
vulnerabilidades basados en la red y en el host están disponibles de forma gratuita o pagando una tarifa.
9.4.2 Prueba de penetración
“Las pruebas de penetración son pruebas de seguridad en las que los evaluadores intentan eludir las características de seguridad de un sistema
en función de su comprensión del diseño y la implementación del sistema” [NISS99]. El propósito de las pruebas de penetración es ejercitar las
protecciones del sistema (particularmente la respuesta humana a las indicaciones de ataque) mediante el uso de herramientas y técnicas
comunes desarrolladas por los atacantes. Esta prueba es muy recomendable para sistemas complejos o críticos.
Las pruebas de penetración pueden ser una técnica invaluable para el programa de seguridad de la información de cualquier organización.
Sin embargo, es una actividad que requiere mucha mano de obra y requiere una gran experiencia para minimizar el riesgo para los sistemas
específicos. Como mínimo, puede ralentizar el tiempo de respuesta de la red de la organización debido al mapeo de la red y el escaneo de
vulnerabilidades. Además, existe la posibilidad de que los sistemas se dañen o se vuelvan inoperables durante las pruebas de penetración.
Aunque este riesgo se mitiga mediante el uso de probadores de penetración experimentados, nunca se puede eliminar por completo.
Las pruebas de penetración ofrecen los siguientes beneficios [NIST02b]:
Prueba la red utilizando las mismas metodologías y herramientas empleadas por los atacantes
Verifica si existen vulnerabilidades
Va más allá de las vulnerabilidades superficiales y demuestra cómo estas vulnerabilidades pueden explotarse iterativamente para
obtener un mayor acceso
9-12
Demuestra que las vulnerabilidades no son puramente teóricas
Proporciona el "realismo" necesario para abordar los problemas de seguridad.
Permite probar los procedimientos y la susceptibilidad del elemento humano a la ingeniería social.
9.5 Administración remota de un servidor web
Se recomienda enfáticamente que la administración remota y la actualización remota de contenido para un servidor web se permitan solo
después de una cuidadosa consideración de los riesgos. La configuración más segura es prohibir cualquier administración remota o
actualizaciones de contenido. Sin embargo, eso podría no ser viable para todas las organizaciones. El riesgo de habilitar la administración
remota o las actualizaciones de contenido varía considerablemente según la ubicación del servidor web en la red (consulte la Sección 8.1).
Para un servidor web que está ubicado detrás de un firewall, la administración remota o la actualización de contenido se pueden
implementar de forma relativamente segura desde la red interna, pero no sin riesgo adicional. Por lo general, no se debe permitir la
administración remota o la actualización de contenido desde un host ubicado fuera de la red de la organización, a menos que se realice
desde una computadora controlada por la organización a través de la solución de acceso remoto de la organización, como una VPN.
Si una organización determina que es necesario administrar o actualizar contenido de forma remota en un servidor web, seguir estos
pasos debería garantizar que el contenido se implemente de la manera más segura posible:
Utilice un mecanismo de autenticación sólido (p. ej., par de claves pública/privada, autenticación de dos factores).
Restrinja qué hosts se pueden usar para administrar o actualizar contenido de forma remota en el servidor web.
Restringir por usuarios autorizados
Restringir por dirección IP (no nombre de host)
Restringir a hosts en la red interna o aquellos que usan la solución de acceso remoto empresarial de la organización.
Utilice protocolos seguros que puedan proporcionar cifrado tanto de contraseñas como de datos (p. ej., SSH, HTTPS); no utilice
protocolos menos seguros (p. ej., telnet, FTP, NFS, HTTP) a menos que sea absolutamente necesario y se canalice a través de un
protocolo cifrado, como SSH, SSL o IPsec.
Hacer cumplir el concepto de privilegio mínimo en la administración remota y la actualización de contenido (p. ej., intentar minimizar
los derechos de acceso para las cuentas de actualización/administración remota).
No permita la administración remota desde Internet a través del firewall a menos que se realice a través de mecanismos sólidos,
como VPN.
Cambie las cuentas o contraseñas predeterminadas para la aplicación o utilidad de administración remota.
No monte ningún recurso compartido de archivos en la red interna desde el servidor web o viceversa.
9-13
9.6 Lista de verificación para administrar el servidor web
Terminado Acción
Realizar registro
Use el formato de registro combinado para almacenar el Registro de transferencia o configure manualmente la información
descrita por el formato de registro combinado para que sea el formato estándar para el Registro de transferencia
Habilite el registro de referencia o el registro de agente si el formato de registro combinado no está disponible
Establecer diferentes nombres de archivo de registro para diferentes sitios web virtuales que pueden implementarse
como parte de un único servidor web físico
Use la identidad del usuario remoto como se especifica en RFC 1413
Almacenar registros en un host separado (syslog)
Asegúrese de que haya suficiente capacidad para los registros
Archivar registros de acuerdo con los requisitos de la organización
Revise los registros diariamente
Revise los registros semanalmente (para ver tendencias a más largo plazo)
Usar herramientas de análisis de archivos de registro automatizados
Realizar copias de seguridad del servidor web
Crear una política de copia de seguridad del servidor web
Realice una copia de seguridad del servidor web de forma diferencial o incremental de forma diaria o semanal
Realice una copia de seguridad completa del servidor web de forma semanal o mensual
Archivar copias de seguridad periódicamente
Mantener una copia autorizada de los sitios web
Recuperarse de un compromiso
Aísle los sistemas comprometidos o tome otras medidas para contener el ataque para que se pueda recopilar información
adicional.
Investigue hosts similares para determinar si el atacante también ha comprometido otros sistemas
Consultar, según corresponda, con la gerencia, el asesor legal y los funcionarios encargados de hacer cumplir la ley de
manera expedita
Analizar la intrusión
restaurar el sistema
Vuelva a conectar el sistema a la red
Supervise el sistema y la red en busca de señales de que el atacante está intentando acceder al sistema o la red
nuevamente
Documentar lecciones aprendidas
Prueba de seguridad
Realice periódicamente exploraciones de vulnerabilidades en el servidor web, el contenido generado dinámicamente y la

red de soporte.
Actualice el escáner de vulnerabilidades antes de la prueba
Corrija cualquier deficiencia identificada por el escáner de vulnerabilidades
Realice pruebas de penetración en el servidor web y la infraestructura de red de soporte
Corregir las deficiencias identificadas por las pruebas de penetración.
9-14
Terminado Acción
Llevar a cabo actualizaciones de contenido y administración
remota Usar un mecanismo de autenticación sólido (p. ej., par de claves pública/privada, autenticación
de dos factores)
Restrinja los hosts que se pueden usar para administrar o actualizar contenido de forma remota en el
Servidor web por dirección IP y a la red interna
Utilice protocolos seguros (p. ej., SSH, HTTPS)
Hacer cumplir el concepto de privilegio mínimo en la administración remota y la actualización

de contenido (p. ej., intentar minimizar los derechos de acceso para las cuentas de administración/
actualización remotas)
Cambie las cuentas o contraseñas predeterminadas desde la utilidad o aplicación de administración

remota
No permita la administración remota desde Internet a menos que existan mecanismos como
Se utilizan VPN
viceversa
9-15
Apéndice A—Recursos de seguridad del servidor web en línea
Este apéndice contiene listas de recursos en línea que pueden ser útiles para los administradores de servidores
web y otros para lograr una mayor comprensión de la seguridad del servidor web y para proteger sus servidores web.
Recursos de seguridad de contenido activo
Recurso/Título URL
Active Software Professionals (ASP) Alliance cgisecurity.net http://www.aspalliance.com/ http://
Department of Homeland Security (DHS) Build Security In www.cgisecurity.com/lib/ https://
Portal buildsecurityin.us-cert.gov/
Explotación de vulnerabilidades comunes en el hipertexto de PHP http://www.securereality.com.au/studyinscarlet.txt

Aplicaciones de preprocesador (PHP)
Seguridad Java SE http://java.sun.com/security/ http://

El sitio oficial de Microsoft ASP.NET 2.0 www.asp.net/ http://www.owasp.org/
Proyecto de seguridad de aplicaciones web abiertas (OWASP)
Los diez mejores de OWASP http://www.owasp.org/index.php/Category:OWASP_Top

_Diez_Proyecto
Guía de seguridad de PHP http://phpsec.org/php-security-guide.pdf http://
Consorcio de seguridad de aplicaciones web www.webappsec.org/
Recursos de seguridad del servidor web Apache
Recurso/Título URL
Consejos de seguridad de Apache 1.3 http://httpd.apache.org/docs/1.3/misc/security_tips.html

Consejos de seguridad de http://httpd.apache.org/docs/2.0/misc/security_tips.html
Apache 2.0 Consejos de http://httpd.apache.org/docs/2.2/misc/security_tips.html
seguridad de Apache 2.2 Apache Secure Sockets Layer (SSL) http://www.apache-ssl.org/
Tutoriales de Apache http://httpd.apache.org/docs/misc/tutorials.html http://apache-
Apache-server.com server.com/
Asegurar Apache http://www.adobe.com/v1/documentcenter/partners/asz_aswps_se

curado_apache.pdf
Protección de Apache: paso a paso http://www.securityfocus.com/infocus/1694
Protección de Apache 2: paso a paso http://www.securityfocus.com/infocus/1786
Asegurar sus páginas web con Apache http://apache-server.com/tutorials/LPauth1.html
A-1
Recursos de evaluación de aplicaciones y revisión de código
Recurso/Título URL
Detección de seguridad de aplicaciones web http://www.oreillynet.com/pub/a/sysadmin/2006/11/02/webapp_sec

vulnerabilidades urity_scans.html
Seguridad de compilación del DHS en el portal https://buildsecurityin.us-cert.gov/

Cabra web de OWASP http://www.owasp.org/index.php/OWASP_WebGoat_Project
OWASP WebEscarabajo http://www.owasp.org/index.php/OWASP_WebScarab_Project
Un proceso para ejecutar el código de seguridad http://www.computer.org/portal/site/security/index.jsp?pageID=sec

Reseñas urity_level1_article&TheCat=1001&path=security/2006/v4n4&file=b
asic.xml
Dinámica SPI http://www.spidynamics.com/
Pasar por http://wapiti.sourceforge.net/

Watchfire http://www.watchfire.com/ http://
Consorcio de seguridad de aplicaciones web www.webappsec.org/projects/articles/

Artículos
Proveedores de certificados digitales (autoridades de certificación de terceros)
Recurso/Título URL
CertiSign Certificación Digital Ltd. http://www.certisign.com.br/
red de investigación alemana http://www.pca.dfn.de/

Entrust.net Ltd. http://www.entrust.net/ http://
GeoTrust Inc. www.geotrust.com/
GlobalSign NV/SA http://www.globalsign.net/ http://
Ve papi www.godaddy.com/
IKS GmbH http://www.iks-jena.de/produkte/ca/
IdenTrust http://www.identrust.com/
Cambio de carril.net http://www.cambiodecarril.net/
Register.com http://www.register.com/
Centro de confianza de TC http://www.trustcenter.de/
Deshielo http://www.thawte.com/certs/server/request.html
VeriSign http://www.verisign.com/
Recursos generales de seguridad del servidor web
Recurso/Título URL
Una mirada al servidor web y la web http://www.cgisecurity.com/papers/fingerprint-port80.txt

Firmas de ataques de aplicaciones
Centro de Educación e Investigación en http://www.cerias.purdue.edu/
Aseguramiento y Seguridad de la Información
(CERÍAS)
Equipo de Respuesta a Emergencias Informáticas http://www.sei.cmu.edu/pub/documents/sims/pdf/sim011.pdf

Centro de Coordinación (CERT/CC), Aseguramiento
Servidores web públicos
A-2
Recurso/Título URL
certificado http://www.cert.org/
Sitio web del Departamento de Defensa (DoD) http://www.defenselink.mil/webmasters/policy/dod_web_policy_120

Políticas y procedimientos de administración 71998_con_enmiendas_y_correcciones.html
Asociación Nacional de Garantía de la Información http://www.nsa.gov/ia/industry/niap.cfm

Instituto Nacional de Normas y http://csrc.nist.gov/
Tecnología (NIST) Seguridad informática
Centro de Recursos
NIST National Vulnerability Database Office of http://nvd.nist.gov/ http://
Management and Budget Circular No. A-130 www.whitehouse.gov/omb/circulars/a130/a130.html
Base de datos de vulnerabilidades de código abierto http://www.osvdb.org/

Foro de RIESGOS http://catless.ncl.ac.uk/Risks/ http://
Instituto SANS www.sans.org/ http://www.sans.org/
SANS Top-20 de ataques de seguridad en Internet top20.htm

Objetivos
Programa de listas de verificación de configuración de seguridad http://checklists.nist.gov/

para productos de TI
Gestión de confianza en la World Wide Web http://www.firstmonday.dk/issues/issue3_6/khare/ Computadora del Departamento
de Energía de EE. UU. http://www.ciac.org/ciac/ Capacidad de Asesoramiento de Incidentes (CIAC)
Equipo de Respuesta a Emergencias Informáticas http://www.us-cert.gov/

de los Estados Unidos (US-CERT)
Preguntas frecuentes sobre seguridad en la World Wide Web http://www.w3.org/Security/Faq/www-security-faq.html

Preguntas
Recursos de seguridad del servidor web de Internet Information Services (IIS)
Recurso/Título URL
Avisos y alertas de eEye http://research.eeye.com/html/advisories/published/index.html
Lista de comprobación de seguridad de IIS 5.0 http://www.microsoft.com/technet/prodtechnol/windows2000serv/techn

ologies/iis/tips/iis5chk.mspx
IIS 6 Seguridad http://www.securityfocus.com/infocus/1765
Prácticas recomendadas de seguridad de IIS 6 http://technet2.microsoft.com/WindowsServer/en/library/ace052a0-

a713-423e-8e8c-4bf198f597b81033.mspx
Herramienta de bloqueo de IIS http://www.microsoft.com/technet/security/tools/locktool.mspx
Guía de la Agencia de Seguridad Nacional (NSA) para http://www.nsa.gov/notices/notic00004.cfm?Address=/snac/os/win2k/ii

la configuración y administración seguras de Microsoft s_5_v1_4.pdf
IIS 5.0
Seguridad en IIS 6.0 http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Li

brary/IIS/f8f81568-31f2-4210-9982-b9391afc30eb.mspx?mfr=true
A-3
Recursos varios de seguridad web
Recurso/Título URL
dominosecurity.org http://www.dominosecurity.org/ http://
Proyecto Honeynet project.honeynet.org/ http://
Página de seguridad de Lotus Domino www-128.ibm.com/developerworks/lotus/security/
Página de inicio de Microsoft Internet Explorer http://www.microsoft.com/windows/products/winfamily/ie/default

.mspx
Centro de seguridad de Mozilla http://www.mozilla.org/security/

netcraft http://www.netcraft.com/
Recursos de suplantación de identidad
Recurso/Título URL
Grupo de trabajo contra el phishing (APWG) http://www.antiphishing.org/ http://
Comisión Federal de Comercio (FTC), “Cómo no obtener www.ftc.gov/bcp/edu/pubs/consumer/alerts/alt127.htm

Enganchado por una estafa de 'Phishing'”
Centro de Quejas de Delitos en Internet (ICCC) http://www.ic3.gov/ http://
Red de informes de phishing www.phishreport.net/
Información de WebBot
Recurso/Título URL
BotSpot http://www.botspot.com
Configuración de los archivos robots.txt http://www.robotstxt.org/wc/exclusion.html#robotstxt
Seguridad del agente móvil de NIST http://csrc.nist.gov/mobileagents/projects.html
Mostrando a los robots la puerta http://www.ariadne.ac.uk/issue15/robots/
Universidad de Maryland Condado de Baltimore (UMBC) http://agents.umbc.edu/

AgentWeb
Publicaciones del NIST sobre seguridad de redes y sistemas82
Publicación URL
SP 800-18 Revisión 1, Guía para desarrollar seguridad http://csrc.nist.gov/publications/nistpubs/800-18-

Planes para Sistemas de Información Federales Rev1/sp800-18-Rev1-final.pdf http://
SP 800-26, Guía de autoevaluación de seguridad para csrc.nist.gov/publications/nistpubs/800-26/sp800-

Sistemas de tecnología de la información 26.pdf
SP 800-27, Principios de ingeniería para la información http://csrc.nist.gov/publications/nistpubs/800-

Seguridad tecnológica 27A/SP800-27-RevA.pdf
SP 800-28 Versión 2 (BORRADOR), Directrices sobre Active http://csrc.nist.gov/publications/nistpubs/

Contenido y código móvil
82
El sitio web principal para todas estas publicaciones se encuentra en http://csrc.nist.gov/publications/index.html.
A-4
Publicación URL
SP 800-32, Introducción a la tecnología de clave pública y la http://csrc.nist.gov/publications/nistpubs/800-32/sp800-

infraestructura PKI federal 32.pdf
SP 800-34, Guía de planificación de contingencia para información http://csrc.nist.gov/publications/nistpubs/800-34/sp800-

Sistemas Tecnológicos 34.pdf
SP 800-37, Guía para la Certificación de Seguridad y http://csrc.nist.gov/publications/nistpubs/800-37/SP800-

Acreditación de Sistemas de Información Federales 37-final.pdf
SP 800-40 Versión 2, Creación de un parche y http://csrc.nist.gov/publications/nistpubs/800-40-

Programa de Gestión de Vulnerabilidades Ver2/SP800-40v2.pdf
SP 800-41, Directrices sobre cortafuegos y política de cortafuegos http://csrc.nist.gov/publications/nistpubs/800-41/sp800-

41.pdf
SP 800-42, Directrices sobre pruebas de seguridad de redes http://csrc.nist.gov/publications/nistpubs/800-42/NIST SP800-42.pdf

http://csrc.nist.gov/publications/nistpubs/800-45-
SP 800-45 Versión 2, Directrices sobre correo electrónico

Seguridad versión 2/SP800-45v2.pdf http://
SP 800-46, Seguridad para Teletrabajo y Banda Ancha csrc.nist.gov/publications/nistpubs/800-46/sp800-

Comunicaciones 46.pdf
SP 800-52, Directrices para la selección y uso de http://csrc.nist.gov/publications/nistpubs/800-52/SP800-

Implementaciones de seguridad de la capa de transporte (TLS) 52.pdf
SP 800-53 Revisión 1, Controles de seguridad recomendados http://csrc.nist.gov/publications/nistpubs/800-53-

para sistemas de información federales SP 800-61, Guía de Rev1/800-53-rev1-final-clean-sz.pdf
manejo de incidentes de seguridad informática http://csrc.nist.gov/publications/nistpubs/800-61/sp800-

61.pdf
SP 800-63, Pauta de autenticación electrónica http://csrc.nist.gov/publications/nistpubs/800-63/SP800-

63V1_0_2.pdf
SP 800-68, Guía para asegurar Microsoft Windows http://csrc.nist.gov/itsec/download_WinXP.html

Sistemas XP para profesionales de TI
SP 800-69, Guía para asegurar Microsoft Windows http://csrc.nist.gov/itsec/guidance_WinXP_Home.html

XP Home Edition: una configuración de seguridad NIST
Lista de Verificación
SP 800-77, Guía de VPN IPsec http://csrc.nist.gov/publications/nistpubs/800-77/sp800-

77.pdf
SP 800-81, Sistema seguro de nombres de dominio (DNS) http://csrc.nist.gov/publications/nistpubs/800-81/SP800-

Guía de implementación 81.pdf
SP 800-83, Guía para la prevención de incidentes de malware y http://csrc.nist.gov/publications/nistpubs/800-83/SP800-

Manejo 83.pdf
SP 800-86, Guía para la integración de técnicas forenses en la http://csrc.nist.gov/publications/nistpubs/800-86/SP800-

respuesta a incidentes 86.pdf
SP 800-92, Guía para el registro de seguridad informática http://csrc.nist.gov/publications/nistpubs/800-92/SP800-

administración 92.pdf
SP 800-94, Guía para la detección y prevención de intrusiones http://csrc.nist.gov/publications/nistpubs/800-94/SP800-

Sistemas (IDPS) 94.pdf
SP 800-95, Guía de servicios web seguros http://csrc.nist.gov/publications/nistpubs/800-95/SP800-

95.pdf
A-5
Apéndice B—Glosario
Protocolo de resolución de direcciones (ARP): un protocolo utilizado para obtener la dirección física de un nodo. Una
estación cliente transmite una solicitud ARP a la red con la dirección de Protocolo de Internet (IP) del nodo de destino con el que
desea comunicarse, y con esa dirección el nodo responde devolviendo su dirección física para que se le puedan transmitir los
paquetes. .
Generador de contenido: un programa en un servidor web que generará dinámicamente páginas de lenguaje de marcado de
hipertexto (HTML) para los usuarios. Los generadores de contenido pueden variar desde scripts simples de interfaz de puerta
de enlace común (CGI) ejecutados por el servidor web hasta servidores de aplicaciones Java EE o .NET en los que la mayoría,
si no todas, las páginas HTML servidas se generan dinámicamente.
Zona desmilitarizada (DMZ) : un host o segmento de red insertado como una "zona neutral" entre la red privada de una
organización e Internet.
Host: casi cualquier tipo de computadora, incluido un mainframe centralizado que es el host de sus terminales, un servidor que es
el host de sus clientes o una computadora personal (PC) de escritorio que es el host de sus periféricos. En las arquitecturas de
red, una estación cliente (la máquina del usuario) también se considera un host porque es una fuente de información para la red,
en contraste con un dispositivo, como un enrutador o conmutador, que dirige el tráfico.
Revisión: término de Microsoft para "parche".
Control de acceso obligatorio: un medio para restringir el acceso a los recursos del sistema en función de la confidencialidad
(representada por una etiqueta) de la información contenida en el recurso del sistema y la autorización formal (es decir, autorización)
de los usuarios para acceder a información de tal confidencialidad.
Administrador de red: una persona que administra una red de área local (LAN) dentro de una organización.
Las responsabilidades incluyen garantizar la seguridad de la red, instalar nuevas aplicaciones, distribuir actualizaciones de
software, monitorear la actividad diaria, hacer cumplir los acuerdos de licencia, desarrollar un programa de administración de
almacenamiento y proporcionar copias de seguridad de rutina.
Nonce: un valor generado aleatoriamente que se utiliza para derrotar los ataques de "reproducción" en los protocolos de
comunicación. Una de las partes genera aleatoriamente un nonce y lo envía a la otra parte. El receptor lo encripta usando la clave
secreta acordada y lo devuelve al remitente. Debido a que el remitente generó aleatoriamente el nonce, esto derrota los ataques de
reproducción porque el reproductor no puede saber de antemano el nonce que generará el remitente. El receptor niega las conexiones
que no tienen el nonce correctamente encriptado.
Sistema operativo: la "aplicación de control maestro" del software que ejecuta la computadora. Es el primer programa que se
carga cuando se enciende la computadora, y su componente principal, el núcleo, reside en la memoria en todo momento. El
sistema operativo establece los estándares para todos los programas de aplicación (como el servidor web) que se ejecutan en la
computadora. Las aplicaciones se comunican con el sistema operativo para la mayoría de las operaciones de interfaz de usuario y
administración de archivos.
Parche—Un “trabajo de reparación” para una pieza de programación; también conocido como "arreglo". Un parche es la
solución inmediata que se brinda a los usuarios; a veces se puede descargar del sitio web del fabricante del software.
El parche no es necesariamente la mejor solución para el problema, y los desarrolladores de productos a menudo encuentran una
mejor solución cuando empaquetan el producto para su próxima versión. Un parche generalmente se desarrolla y distribuye como
un reemplazo o una inserción en el código compilado (es decir, en un archivo binario o módulo de objeto). En muchos sistemas
operativos, se proporciona un programa especial para administrar y rastrear la instalación de parches.
B-1
Pharming: uso de medios técnicos para redirigir a los usuarios para que accedan a un sitio web falso que se hace pasar por uno
legítimo y divulga información personal.
Phishing: uso de técnicas de ingeniería social para engañar a los usuarios para que accedan a un sitio web falso y divulguen
información personal.
Proxy: un proxy es una aplicación que "interrumpe" la conexión entre el cliente y el servidor. El proxy acepta ciertos tipos de tráfico
que ingresan o salen de una red, lo procesa y lo reenvía. Esto cierra efectivamente el camino directo entre las redes internas y
externas, lo que dificulta que un atacante obtenga direcciones internas y otros detalles de la red interna de la organización. Los
servidores proxy están disponibles para los servicios comunes de Internet; por ejemplo, un proxy de Protocolo de transferencia de
hipertexto (HTTP) utilizado para el acceso a la Web y un proxy de Protocolo simple de transferencia de correo (SMTP) utilizado para el
correo electrónico.
Service Pack: término de Microsoft para una colección de parches integrados en una sola actualización grande.
Protocolo SOCKS: un protocolo de Internet que permite que las aplicaciones cliente formen una puerta de enlace a nivel de circuito a
un firewall de red a través de un servicio de proxy.
Administrador del sistema: una persona que administra un sistema informático, incluidos su sistema operativo y sus aplicaciones. Las
responsabilidades de un administrador del sistema son similares a las de un administrador de red.
Virtualización: el uso de una capa de abstracción para simular hardware informático de modo que varios sistemas operativos
puedan ejecutarse en una sola computadora.
Vulnerabilidad: una exposición de seguridad en un sistema operativo u otro software de sistema o componente de software de
aplicación. Una variedad de organizaciones mantienen bases de datos de vulnerabilidades de acceso público basadas en los números
de versión del software. Cada vulnerabilidad puede comprometer potencialmente el sistema o la red si se explota.
Servidor web: una computadora que proporciona servicios de World Wide Web (WWW) en Internet. Incluye el hardware, el sistema
operativo, el software del servidor web y el contenido del sitio web (páginas web). Si el servidor web se usa internamente y no por el
público, puede conocerse como un "servidor de intranet".
Administrador del servidor web: el servidor web equivalente a un administrador del sistema. Los administradores de servidores
web son arquitectos de sistemas responsables del diseño, la implementación y el mantenimiento generales de los servidores web.
Pueden o no ser responsables del contenido de la Web, que tradicionalmente es responsabilidad del Webmaster.
Webmaster: una persona responsable de la implementación de un sitio web. Los webmasters deben ser competentes en
HTML y en uno o más lenguajes de secuencias de comandos y de interfaz, como JavaScript y Perl. Pueden o no ser responsables del
servidor subyacente, que tradicionalmente es responsabilidad del administrador web (ver arriba).
B-2
Apéndice C—Herramientas y aplicaciones de seguridad web
Las herramientas y aplicaciones a las que se hace referencia en este apéndice no son de ninguna manera una lista completa de
herramientas y aplicaciones para usar para la seguridad web, ni esta publicación implica ningún respaldo de ciertos productos.
Herramientas de análisis de archivos de registro
Herramienta
Capacidad Sitio web linux/ Win32 Costo
Unix
Cosa análoga Más común http://www.analog.cx/intro.html 9 9 Libre

A nosotros
Descripción Analog es una herramienta automatizada de análisis de archivos de registro del servidor web que compilará en casi cualquier plataforma
que soporta el lenguaje de programación C.
Cronólogo Linux/Unix 9 Libre

http://www.cronolog.org/
Descripción Cronolog es un programa que lee mensajes de registro de su entrada y los escribe en un conjunto de salida
archivos construidos usando una plantilla y la fecha y hora actual.
LiveStats6 La mayoría de los servidores http://www.deepmetrix.com/ 9 9 $$$
web y sistemas operativos
Descripción Livestat6 es una herramienta automatizada de análisis de archivos de registro del servidor web.
NetTracker La mayoría de los servidores 9 9 $$$

http://www.unica.com/
web y sistemas operativos
Descripción NetTracker es una herramienta automatizada de análisis de archivos de registro del servidor web.
Muestra de tela Linux/Unix http://swatch.sourceforge.net/ 9 Libre
Descripción Swatch es una utilidad de análisis de syslog de Linux/ Unix.

Wwwstat Linux y Unix con http://ftp.ics.uci.edu/pub/websoft/wwwstat/ 9 Libre
Perl instalado
Descripción Wwwstat es una herramienta automatizada de análisis de archivos de registro del servidor web para el formato de archivo de registro común access_log
archivos
$$$=Este producto implica una tarifa.
Herramientas de escaneo de vulnerabilidades
Herramienta
Unix
Internet Vulnerabilidad http://www.iss.net/ 9 $$$

Seguridad escáner
Sistemas
(ISS)
Internet
Escáner
Descripción ISS Internet Scanner es una herramienta de exploración de vulnerabilidades basada en la red que identifica agujeros de seguridad
en los hosts de la red.
metasploit Vulnerabilidad 9 9 Libre

http://www.metasploit.com/
escáner
Descripción Metasploit es una herramienta gratuita de análisis de vulnerabilidades que identifica agujeros de seguridad en los hosts de la red.
nessus Vulnerabilidad http://www.nessus.org/ 9 9 Libre
escáner
C-1
Herramienta
Unix
Descripción Nessus es una herramienta gratuita de análisis de vulnerabilidades basada en la red que identifica agujeros de seguridad en
anfitriones de la red.
Retina Vulnerabilidad http://www.eeye.com/ 9 $$$

escáner
Descripción Retina es un escáner de seguridad de red de propósito general que identifica una gran cantidad de vulnerabilidades del
servidor web.
SMO Vulnerabilidad http://www.saintcorporation.com/ 9 $$$

escáner
Descripción SAINT es una herramienta de análisis de vulnerabilidades basada en la red que identifica agujeros de seguridad en la red.
Hospedadores.
SARA Vulnerabilidad http://www-arc.com/sara/ 9 Libre

escáner
Descripción SARA es una herramienta gratuita de análisis de vulnerabilidades basada en la red que identifica agujeros de seguridad en
anfitriones de la red.
Herramientas de escaneo de aplicaciones web
Herramienta
Unix
Acunetix Vulnerabilidad web http://www.acunetix.com/ 9 $$$

escáner
Descripción El escáner de vulnerabilidades web Acunetix es un escáner de vulnerabilidades de aplicaciones web.
Vulnerabilidad web de AppScan http://www.watchfire.com/ 9 $$$

escáner
Descripción AppScan es un escáner de vulnerabilidades de aplicaciones web.

Nadie Común http://www.cirt.net/code/nikto.shtml 9 9 Libre
Puerta
Vulnerabilidad de
interfaz (CGI)
escáner
Descripción Nikto es un escáner que identifica vulnerabilidades en scripts CGI.

días Proxy web para http://www.parosproxy.org/index.shtml 9 9 Libre
pruebas de
seguridad
Aplicaciones web Descripción Paros permite interceptar y modificar todos los datos del Protocolo de transferencia de hipertexto (HTTP)
y del Protocolo seguro de transferencia de hipertexto (HTTPS) entre el servidor y el cliente, incluidas las cookies y
los campos de formulario, y permite la prueba de seguridad de la aplicación. http://www.foundstone.com/us/resources/
SiteDigger Un escáner de 9 Libre

vulnerabilidad proddesc/sitedigger.htm
web que
analiza los datos de
Google en su sitio
Descripción SiteDigger busca en el caché de Google para buscar vulnerabilidades, errores, problemas de configuración,
información patentada y puntos de seguridad interesantes en los sitios web.
Interrogador de cifrado http://www.foundstone.com/us/resources/ 9 Libre

SSLDigger SSL proddesc/ssldigger.htm
C-2
Herramienta
Unix
Descripción SSLDigger es una herramienta que se utiliza para evaluar la solidez de los servidores SSL probando los cifrados admitidos.
Se sabe que algunos de estos cifrados son inseguros.
Pasar por Vulnerabilidad web http://wapiti.sourceforge.net/ 9 9 Libre

escáner
Descripción Wapiti es un escáner de vulnerabilidades de aplicaciones web de código abierto.
Vulnerabilidad web de WebInspect http://www.spidynamics.com/ 9 9 $$$

escáner
Descripción WebInspect es un escáner de vulnerabilidades de aplicaciones web.

Herramienta de evaluación de http://www.owasp.org/index.php/Categoría: 9 Libre
aplicaciones Web WebScarab
OWASP_WebScarab_Proyecto
Descripción WebScarab es un marco para analizar aplicaciones que se comunican mediante los protocolos HTTP y HTTPS.
Wikto Herramienta de http://www.sensepost.com/research/wikto/ 9 Libre

evaluación del servidor web
Descripción Wikto es un servidor web y un escáner de vulnerabilidades de aplicaciones web.

C-3
Apéndice D—Referencias
[Todos00] Julia Allen et al., Protección de servidores de red, abril de 2000, http://
www.sei.cmu.edu/pub/documents/sims/pdf/sim010.pdf
[APWG07] Grupo de trabajo antiphishing, Vendor Solutions, febrero de 2007,

http://www.antiphishing.org/solutions.html
[Campana06] Steve Bellovin, "Sabiduría no convencional", IEEE Security & Privacy, vol. 4, número 1, enero-febrero de
2006, página 88
[Chow02] Pete Chown, conjuntos de cifrado estándar de cifrado avanzado (AES) para seguridad de la capa de
transporte (TLS), RFC 3268, enero de 2002, http://www.ietf.org/rfc/rfc3268.txt
[Coop01] Russ Cooper, 10 pasos para mejorar la seguridad de IIS, Revista de seguridad de la información, agosto
de 2001, http://www.infosecuritymag.com/articles/september01/features_IIS_security.shtml
[Corto01] Matt Curtin, Developing Trust: Online Privacy and Security, noviembre de 2001
[FTC02] Comisión Federal de Comercio, Recolección de direcciones de correo electrónico: cómo los spammers
cosechan lo que siembran, noviembre de 2002, http://www.onguardonline.gov/spam.html
[FTC06] Comisión Federal de Comercio, Pretexting: Su información personal revelada, febrero de 2006, http://
www.ftc.gov/bcp/conline/pubs/credit/pretext.htm
[FTC06a] Comisión Federal de Comercio, How Not to Get Hooked by a 'Phishing' Scam, octubre de 2006, http://
www.ftc.gov/bcp/edu/pubs/consumer/alerts/alt127.htm
[Google05] Google, Prevención del spam en los comentarios, enero de

2005, http://googleblog.blogspot.com/2005/01/preventing-comment-spam.html
[Johanson05] Eric Johanson, El estado de los ataques homógrafos, febrero de 2005, http://
www.shmoo.com/idn/homograph.txt
[Coss00] Klaus-Peter Kossakowski y Julia Allen, Protección de servidores web públicos, 2000, http://
www.sei.cmu.edu/pub/documents/sims/pdf/sim011.pdf
[MASA99] Mancomunidad de Massachusetts, Orden Ejecutiva 412, 1999, http://

www.state.ma.us/consumer/New/privexeco.htm
[Netcraft06] Netcraft, La falla de seguridad de PayPal permite el robo de identidad, junio de

2006, http://news.netcraft.com/archives/2006/06/16/paypal_security_flaw_allows_identity_thef
t.html
[NISS99] Glosario de seguridad del sistema de información nacional, NSTISSI No. 4009, enero de 1999
[NIST01] Wayne A. Jansen, NIST Special Publication 800-28, Pautas sobre contenido activo y código móvil, octubre
de 2001, http://csrc.nist.gov/publications/nistpubs/index.html
[NIST02a] John Wack et al., NIST Special Publication 800-41, Directrices sobre cortafuegos y política de
cortafuegos, enero de 2002, http://csrc.nist.gov/publications/nistpubs/index.html
D-1
[NIST02b] John Wack et al., NIST Special Publication 800-42, Directrices sobre pruebas de seguridad
de redes, febrero de 2002, http://csrc.nist.gov/publications/nistpubs/index.html
[NIST06a] Marianne Swanson et al., NIST Special Publication 800-18 Revisión 1, Guía para desarrollar
planes de seguridad para sistemas de información federales, febrero de 2006, http://
csrc.nist.gov/publications/nistpubs/index.html
[NIST06b] Karen Kent y Murugiah Souppaya, NIST Special Publication 800-92, Guide to Computer
Security Log Management, abril de 2006, http://csrc.nist.gov/publications/nistpubs/index.html
[NIST06c] Miles Tracy et al., NIST Special Publication 800-45, Versión 2, Directrices sobre seguridad del
correo electrónico, febrero de 2007, http://csrc.nist.gov/publications/nistpubs/index.html
[NIST07] Karen Scarfone y Peter Mell, Publicación especial del NIST 800-94, Guía de sistemas de
prevención y detección de intrusos (IDPS), febrero de 2007, http://csrc.nist.gov/publications/
nistpubs/index.html
[NVD06] Base de datos de vulnerabilidad nacional, CVE-2005-0233, septiembre de

2006, http://nvd.nist.gov/nvd.cfm?cvename=CVE-2005-0233
[Ollm0 Gunter Ollman, La guía de phishing: comprensión y prevención de ataques de phishing,

NGSSoftware, septiembre de 2004, http://www.nextgenss.com/papers/NISR-WP Phishing.pdf
[Ollm05] Gunter Ollman, The Pharming Guide: Comprensión y prevención de ataques relacionados
con DNS por parte de phishers, NGSSoftware, agosto de 2005, http://www.nextgenss.com/
papers/ThePharmingGuide.pdf
[OMB00a] Memorándum de la Oficina de Administración y Presupuesto 2000-13,

2000, http://www.whitehouse.gov/omb/memoranda/m00-13.html
[OMB00b] Carta de aclaración de cookies de la Oficina de Administración y Presupuesto

1, 2000, http://www.whitehouse.gov/omb/inforeg/cookies_letter72800.html
[OMB00c] Carta de aclaración de cookies de la Oficina de Administración y Presupuesto

2, 2000, http://www.whitehouse.gov/omb/inforeg/cookies_letter90500.html
[OWASP06] Proyecto de seguridad de aplicaciones web abiertas (OWASP), Guía OWASP, marzo de 2006,
http://owasp.cvs.sourceforge.net/*checkout*/owasp/guide/current%20draft.pdf
[RSA00] PKCS #10 Versión 1.7, Estándar de sintaxis de solicitud de certificación, 26 de mayo
de 2000, ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-10/pkcs-10v1_7.pdf
[Sal75] Jerome H. Saltzer y Michael Schroeder, "La protección de la información en los sistemas
informáticos", Actas del IEEE, vol. 63, páginas 1278–1308
[Estafa01] Joel Scambray et al., Hacking Exposed Segunda edición, McGraw-Hill, 2001
[Schn00] Bruce Schneier, Secretos y mentiras: seguridad digital en un mundo interconectado, John Wiley
& Sons Inc., 2000
D-2
[SPID06] SPI Dynamics, Peligros de seguridad de AJAX, 2006,

http://www.spidynamics.com/assets/documents/AJAXdangers.pdf
[SSL98] Introducción a SSL, Netscape Communication, Netscape Corporation, 1998, http://

docs.sun.com/source/816-6156-10/contents.htm
[Unsp06] Unspam Technologies, Cómo evitar ser recolectado por Spambots, http://
www.projecthoneypot.org/how_to_avoid_spambots.php
[Blanco06] James A. Whittaker, "Cómo pensar en la seguridad", IEEE Security & Privacy, vol. 4, número 2, marzo–
abril de 2006, páginas 68–71
[WWW01] Preguntas frecuentes sobre seguridad en la World Wide Web, septiembre de 2001, http://www.w3.org/Security/Faq/
[Ziri02] Neal Ziring, Ejecución del servidor web: Problemas del sistema y de seguridad, presentado a Information
Foro del marco técnico de aseguramiento, 1 de marzo de 2002
D-3
Apéndice E—Lista de verificación de seguridad del servidor web
Esta sección proporciona una versión combinada de las listas de verificación de seguridad individuales proporcionadas al final
de muchas secciones de este documento.
Planificación y administración de servidores web
Terminado Acción
Planificar la configuración y el despliegue del servidor web
Identificar las funciones del servidor web.
Identificar categorías de información que se almacenará, procesará y transmitirá a través del servidor web
Identificar los requisitos de seguridad de la información.
Identificar cómo se publica la información en el servidor web Identificar los
requisitos de seguridad de otros hosts involucrados (p. ej., base de datos back-end o servicio web)
Identificar un host dedicado para ejecutar el servidor web
Identificar los servicios de red que serán proporcionados o soportados por el servidor Web
Identificar los requisitos de seguridad de cualquier servicio adicional proporcionado o respaldado por el servidor web.
Identificar cómo se administrará el servidor Web
Identificar usuarios y categorías de usuarios del servidor web y determinar privilegios para cada categoría de usuario
Identificar los métodos de autenticación de usuarios para el servidor web y cómo se protegerán los datos de autenticación
Identificar cómo se hará cumplir el acceso a los recursos de información
Identificar los mecanismos de seguridad física apropiados
Identificar los mecanismos de disponibilidad apropiados
Elija el sistema operativo apropiado para el servidor web
Exposición mínima a vulnerabilidades
Capacidad para deshabilitar servicios de red innecesarios que pueden estar integrados en el sistema operativo o en el software
del servidor
Capacidad para controlar el acceso a varias formas de programas ejecutables, como secuencias de comandos CGI y
complementos de servidor
Capacidad para registrar actividades de servidor apropiadas para detectar intrusiones e intentos de intrusión
Provisión de una capacidad de firewall basada en host
Disponibilidad de personal experimentado para instalar, configurar, proteger y mantener el sistema operativo
Elija la plataforma adecuada para el servidor web
SO de propósito general
SO de confianza
Dispositivo de servidor web
Sistema operativo y servidor web reforzados previamente
Plataforma virtualizada
E-1
Protección del sistema operativo del servidor web
Terminado Acción
Parche y actualice el sistema operativo
Crear, documentar e implementar un proceso de aplicación de parches
Mantenga los servidores desconectados de las redes o en una red aislada que restringe severamente las comunicaciones
hasta que se hayan instalado todos los parches.
Identifique e instale todos los parches y actualizaciones necesarios para el sistema operativo
Identifique e instale todos los parches y actualizaciones necesarios para las aplicaciones y los servicios incluidos con el
sistema operativo
Identifique y mitigue cualquier vulnerabilidad sin parchear
Deshabilite o elimine servicios y aplicaciones innecesarios
Eliminar o deshabilitar cuentas y grupos predeterminados innecesarios
Deshabilitar cuentas no interactivas
Cree los grupos de usuarios para la computadora en particular. Cree las
cuentas de usuario para la computadora en particular. Verifique la política
de contraseñas de la organización y configure las contraseñas de las cuentas apropiadamente (por ejemplo, longitud,
complejidad).
Evite adivinar la contraseña (p. ej., aumente el período entre intentos, deniegue el inicio de sesión después de un número
definido de intentos fallidos)
Instale y configure otros mecanismos de seguridad para fortalecer la autenticación . Configure los controles
de recursos de forma adecuada. Deniegue el acceso de lectura a archivos y directorios innecesarios.
Deniegue el acceso de escritura a archivos y directorios innecesarios.
Limite el privilegio de ejecución de las herramientas del sistema a los administradores del sistema
Seleccione, instale y configure software adicional para proporcionar los controles necesarios no incluidos en el
sistema operativo, como software antivirus, software antispyware, detectores de rootkit, software de prevención y detección
de intrusiones basado en host, firewalls basados en host y software de administración de parches.
Probar la seguridad del sistema operativo
Identificar un sistema idéntico separado
Pruebe el sistema operativo después de la instalación inicial para determinar las vulnerabilidades
Pruebe el sistema operativo periódicamente (por ejemplo, trimestralmente) para determinar nuevas vulnerabilidades
Protección del servidor web
Terminado Acción
Instalar de forma segura el servidor web
Instale el software del servidor web en un host dedicado o un invitado virtualizado dedicado
TÚ
Aplique cualquier parche o actualización para corregir las vulnerabilidades conocidas
Cree un disco físico dedicado o una partición lógica (separada del sistema operativo y la aplicación del servidor
web) para el contenido web
E-2
Terminado Acción
Elimine o deshabilite todos los servicios instalados por la aplicación del servidor web pero no requeridos (por ejemplo, gopher,
FTP, administración remota)
Elimine o deshabilite todas las cuentas de inicio de sesión predeterminadas innecesarias creadas por la instalación del
servidor web
Eliminar toda la documentación del fabricante del servidor
Elimine cualquier ejemplo o archivos de prueba del servidor, incluidos los scripts y el código ejecutable
Aplique la plantilla de seguridad adecuada o el script de refuerzo al servidor
Vuelva a configurar el banner del servicio HTTP (y otros según sea necesario) para NO informar sobre el servidor web y el tipo
y la versión del sistema operativo
Configure los controles de acceso al sistema operativo y al servidor web
Configure el proceso del servidor web para que se ejecute como un usuario con un conjunto estrictamente limitado
de privilegios
Configure el servidor web para que los procesos de servicio puedan leer pero no escribir los archivos de contenido web.
Configure el servidor web para que los procesos de servicio no puedan escribir en los directorios donde se almacena el
contenido web público.
Configure el servidor web para que solo los procesos autorizados para la administración del servidor web puedan
escribir archivos de contenido web.
Configure el sistema operativo host para que el servidor web pueda escribir archivos de registro pero no leerlos.
Configure el sistema operativo host para que los archivos temporales creados por la aplicación del servidor web estén
restringidos a un subdirectorio específico y debidamente protegido.
Configure el sistema operativo host para que el acceso a los archivos temporales creados por la aplicación del servidor
web se limite a los procesos de servicio que crearon los archivos.
Instale contenido web en una unidad de disco duro o partición lógica diferente a la del sistema operativo y la aplicación del
servidor web
Si se permiten cargas al servidor web, configúrelo para que se establezca un límite en la cantidad de espacio del disco duro
que se dedica a este fin; las cargas deben colocarse en una partición separada
Asegúrese de que los archivos de registro se almacenen en una ubicación que tenga el tamaño adecuado; los archivos de
registro deben colocarse en una partición separada
Configurar el número máximo de procesos del servidor web y/o conexiones de red que debe permitir el servidor web
Asegúrese de que todos los sistemas operativos invitados virtualizados sigan esta lista de verificación
Asegúrese de que los usuarios y administradores puedan cambiar las contraseñas
Deshabilitar usuarios después de un período específico de inactividad
Asegúrese de que cada usuario y administrador tenga una identificación única
Configurar un directorio de contenido web seguro
Dedique un solo disco duro o partición lógica para contenido web y establezca subdirectorios relacionados exclusivamente
para archivos de contenido del servidor web, incluidos gráficos pero excluyendo scripts y otros programas.
Defina un único directorio exclusivamente para todos los scripts o programas externos ejecutados como parte del contenido
del servidor web (p. ej., CGI, ASP)
Deshabilite la ejecución de scripts que no estén exclusivamente bajo el control de cuentas administrativas. Esta
acción se logra creando y controlando el acceso a un directorio separado destinado a contener secuencias de comandos
autorizadas Inhabilite el uso de enlaces físicos o simbólicos (por ejemplo, accesos directos para Windows)
E-3
Terminado Acción
Definir una matriz completa de acceso al contenido web. Identifique qué carpetas y archivos dentro del documento
del servidor web deben restringirse y cuáles deben ser accesibles (y por quién)
Verifique la política de contraseñas de la organización y configure las contraseñas de las cuentas de manera
adecuada (p. ej., longitud, complejidad)
Use el archivo robots.txt, si corresponde.
Configure la protección anti-spambot, si corresponde (p. ej., CAPTCHA, nofollow o filtrado de palabras clave).
Protección del contenido web
Terminado Acción
Asegúrese de que ninguno de los siguientes tipos de información esté disponible en o a través de
un servidor web público
Información personal sobre el personal de una organización.
Números de teléfono, direcciones de correo electrónico o listados generales del personal, a menos que sea necesario
para cumplir con los requisitos de la organización
Horarios de los directores de la organización o su ubicación exacta (ya sea dentro o fuera de las instalaciones)
Información sobre la composición, preparación o uso óptimo de materiales peligrosos o toxinas
Registros médicos
Procedimientos de seguridad física y de la información de la organización
Información sobre la red de la organización y la infraestructura del sistema de información
Planos, mapas, diagramas, fotografías aéreas y planos arquitectónicos de edificios, propiedades o instalaciones
organizacionales
Políticas de privacidad o seguridad que indican los tipos de medidas de seguridad implementadas en la medida en
que pueden ser útiles para un atacante
Establezca una política y un proceso formales documentados para toda la organización para aprobar
contenido web público que:
Identifica la información que debe ser publicada en la Web
Identifica el público objetivo
Identifica posibles ramificaciones negativas de publicar la información.
Identifica quién debe ser responsable de crear, publicar y mantener esta información en particular.
Proporciona pautas sobre estilos y formatos apropiados para la publicación en la Web.
Proporciona una revisión adecuada de la información para la sensibilidad y los controles de

distribución/publicación (incluida la sensibilidad de la información en conjunto)
E-4
Terminado Acción
Determina los controles de acceso y seguridad apropiados.
Proporciona orientación sobre la información contenida en el código fuente del contenido web
Mantener la privacidad del usuario web
Mantener una política de privacidad publicada
Prohibir la recopilación de datos de identificación personal sin el permiso explícito del usuario y recopilar solo los datos
que sean absolutamente necesarios.
Prohibir el uso de cookies “persistentes”
Use la cookie de sesión solo si está claramente identificada en la política de privacidad publicada
Mitigar los ataques indirectos al contenido
Asegúrese de que los usuarios del sitio sean conscientes de los peligros de los ataques de phishing y pharming y cómo
evitarlos.
Valide la comunicación oficial personalizando los correos electrónicos y brindando información de identificación
única (pero no confidencial) que solo la organización y el usuario deben conocer
Use firmas digitales en el correo electrónico si corresponde
Realice la validación de contenido dentro de la aplicación web para evitar ataques de phishing más sofisticados (por
ejemplo, ataques basados en secuencias de comandos entre sitios)
Personalice el contenido web para ayudar a los usuarios a identificar sitios web fraudulentos
Use autenticación basada en token o mutua si corresponde
Sugerir el uso de navegadores web o barras de herramientas de navegador con protección contra phishing/
pharming
Utilice las versiones actuales del software DNS con los parches de seguridad más recientes
Instalar mecanismos de protección DNS del lado del servidor
Monitorear dominios organizacionales y dominios similares
Simplificar la estructura de los nombres de dominio de la organización
Utilice conexiones seguras para los inicios de sesión
Si es necesario, contrate a un proveedor para que proporcione medidas antiphishing/anti-pharming más sólidas.
medidas
Consideraciones de seguridad del contenido activo del lado del cliente
Sopesar los riesgos y beneficios del contenido activo del lado del cliente
No realice ninguna acción sin el permiso expreso del usuario.
Cuando sea posible, use solo contenido activo ampliamente adoptado, como JavaScript, PDF y
Destello
Cuando sea posible, proporcione alternativas (p. ej., HTML proporcionado junto con PDF)
Mantenga la seguridad del contenido activo del lado del servidor
Solo se debe usar un código simple y fácil de entender.
Se debe permitir una lectura o escritura limitada o nula en el sistema de archivos. Se debe permitir
una interacción limitada o nula con otros programas (p. ej., sendmail). No debe existir ningún requisito para ejecutar
con privilegios suid en Unix o Linux. , no depende de la variable de ruta)
Ningún directorio tiene permisos de escritura y ejecución
Todos los archivos ejecutables se colocan en carpetas dedicadas
Los SSI están deshabilitados o la función de ejecución está deshabilitada
Toda la entrada del usuario es validada
E-5
Terminado Acción
El código de generación de contenido web debe escanearse o auditarse
Las páginas creadas dinámicamente no crean metacaracteres peligrosos. La codificación
del conjunto de caracteres debe establecerse explícitamente en cada página. Los datos del
usuario deben escanearse para asegurarse de que contienen solo la entrada esperada (p. ej., az, AZ, 0-9); se debe
tener cuidado con los caracteres especiales o las etiquetas HTML Se deben examinar las cookies en busca de
caracteres especiales Se utiliza un mecanismo de cifrado para cifrar las contraseñas ingresadas a través de
formularios de scripts Para las aplicaciones web que están restringidas por nombre de usuario y contraseña,
ninguna de las páginas web de la aplicación debe ser accesible sin ejecutar el proceso de inicio de sesión apropiado
Se eliminan todos los scripts de muestra.
No se utilizan scripts de terceros ni código ejecutable sin verificar el código fuente
Uso de tecnologías de autenticación y cifrado para servidores web
Terminado Acción
Configurar tecnologías de cifrado y autenticación web
Para los recursos web que requieren una protección mínima y para los que hay una audiencia pequeña y
claramente definida, configure la autenticación basada en direcciones
Para los recursos web que requieren protección adicional pero para los que hay una audiencia pequeña y
claramente definida, configure la autenticación basada en direcciones como una segunda línea de defensa.
Para los recursos web que requieren una protección mínima pero para los que no hay una audiencia
claramente definida, configure la autenticación básica o implícita (mejor)
Para los recursos web que requieren protección contra bots maliciosos, configure la autenticación básica o
implícita (mejor) o implemente las técnicas de mitigación que se analizan en la Sección 5.2.4.
Para las organizaciones que deben cumplir con FIPS 140-2, asegúrese de que la implementación
de SSL/TLS esté validada por FIPS
Para los recursos web que requieren la máxima protección, configure SSL/TLS
Configurar SSL/TLS
Asegúrese de que la implementación de SSL/TLS esté completamente parcheada
Use un certificado emitido por un tercero para la autenticación del servidor (a menos que todos los sistemas que
usan el servidor estén administrados por la organización, en cuyo caso podría usarse un certificado autofirmado
en su lugar)
Para configuraciones que requieren un nivel medio de autenticación del cliente, configure el servidor para que
requiera un nombre de usuario y una contraseña a través de SSL/TLS.
Para configuraciones que requieren un alto nivel de autenticación del cliente, configure el servidor para que
requiera certificados de cliente a través de SSL/TLS
Asegúrese de que los conjuntos de cifrado débiles estén deshabilitados (consulte la Tabla 7.1 para conocer el uso recomendado de
los conjuntos de cifrado federales)
Configure el verificador de integridad de archivos para monitorear el certificado del servidor
web. Si solo se va a usar SSL/TLS en el servidor web, asegúrese de que el acceso a través de cualquier puerto TCP que
no sea 443 esté deshabilitado.
Si la mayor parte del tráfico al servidor web se realizará a través de SSL/TLS encriptado, asegúrese
de que se empleen los mecanismos de registro y detección adecuados en el servidor web (porque el
monitoreo de la red no es efectivo contra las sesiones SSL/TLS encriptadas)
E-6
Terminado Acción
Protéjase contra ataques de fuerza bruta
Use autenticación fuerte si es posible
Usar un retraso después de intentos fallidos de inicio de sesión
Bloquear una cuenta después de un número determinado de intentos fallidos de inicio de sesión
Hacer cumplir una política de contraseñas
Lista negra de direcciones IP o dominios conocidos por intentar ataques de fuerza bruta
Use software de monitoreo de registros para detectar ataques de fuerza bruta
Implementación de una infraestructura de red segura
Terminado Acción
Identificar la ubicación de la red
El servidor web está ubicado en una DMZ, o el alojamiento del servidor web está subcontratado
Evaluar la configuración del cortafuegos
El servidor web está protegido por un firewall; si enfrenta una amenaza mayor o es más vulnerable, está protegido por
un firewall de capa de aplicación
El cortafuegos controla todo el tráfico entre Internet y el servidor web
El cortafuegos bloquea todo el tráfico entrante al servidor web, excepto los puertos TCP 80 (HTTP) y/o 443
(HTTPS), si es necesario.
El cortafuegos bloquea (junto con el IDPS) las direcciones IP o las subredes que, según los informes del IDPS, están
atacando la red de la organización
Firewall notifica al administrador de la red o del servidor web de actividad sospechosa a través de un medio apropiado
Firewall proporciona filtrado de contenido (firewall de capa de aplicación)
El cortafuegos está configurado para proteger contra ataques DoS
El cortafuegos detecta solicitudes de URL de ataques mal formados o conocidos
Firewall registra eventos críticos
El cortafuegos y el sistema operativo del cortafuegos están parcheados al nivel más reciente o más seguro
Evaluar los sistemas de detección y prevención de intrusos
El IDPS basado en host se utiliza para servidores web que funcionan principalmente con SSL/TLS.
IDPS está configurado para monitorear el tráfico de red hacia y desde el servidor web después del firewall
IDPS está configurado para monitorear cambios en archivos críticos en el servidor web (IDPS basado en host o verificador
de integridad de archivos)
IDPS bloquea (junto con el firewall) direcciones IP o subredes que están atacando la red organizacional
IDPS notifica a los administradores de IDPS o al administrador del servidor web sobre los ataques a través de los
medios apropiados
IDPS está configurado para maximizar la detección con un nivel aceptable de falsos positivos
IDPS está configurado para registrar eventos
IDPS se actualiza con nuevas firmas de ataques con frecuencia (por ejemplo, diariamente)
El IDPS basado en host está configurado para monitorear los recursos del sistema disponibles en el host del servidor
web.
Evaluar conmutadores de red
Los conmutadores se utilizan para proteger contra las escuchas ilegales de la red
E-7
Terminado Acción
Los conmutadores están configurados en modo de alta seguridad para vencer los ataques de suplantación de identidad
y envenenamiento de ARP
Los switches están configurados para enviar todo el tráfico en el segmento de la red a IDPS basados en la red
Evaluar balanceadores de carga
Los balanceadores de carga se utilizan para aumentar la disponibilidad del servidor web
Los balanceadores de carga se complementan con cachés web, si corresponde
Evaluar proxies inversos
Los proxies inversos se utilizan como puerta de enlace de seguridad para aumentar la disponibilidad del servidor web
Los proxies inversos se complementan con capacidades de aceleración de cifrado, autenticación de usuarios y filtrado de
contenido, si corresponde.
Administrar el servidor web
Terminado Acción
Realizar registro
Utilice el formato de registro combinado para almacenar el Registro de transferencia o configure manualmente la información
descrita por el formato de registro combinado para que sea el formato estándar para el
Registro de transferencia
Habilite el registro de referencia o el registro de agente si el formato de registro combinado no está disponible
Establecer diferentes nombres de archivo de registro para diferentes sitios web virtuales que pueden
implementarse como parte de un único servidor web físico
Use la identidad del usuario remoto como se especifica en RFC 1413
Almacenar registros en un host separado (syslog)
Asegúrese de que haya suficiente capacidad para los registros
Archivar registros de acuerdo con los requisitos de la organización
Revise los registros diariamente
Revise los registros semanalmente (para ver tendencias a más largo plazo)
Usar herramientas de análisis de archivos de registro automatizados
Realizar copias de seguridad del servidor web
Crear una política de copia de seguridad del servidor web
Realice una copia de seguridad del servidor web de forma diferencial o incremental de forma diaria o semanal
Realice una copia de seguridad completa del servidor web de forma semanal o mensual
Archivar copias de seguridad periódicamente
Mantener una copia autorizada de los sitios web
Recuperarse de un compromiso
Aísle los sistemas comprometidos o tome otras medidas para contener el ataque para que se pueda recopilar
información adicional.
Investigue hosts similares para determinar si el atacante también ha comprometido otros sistemas
Consultar, según corresponda, con la gerencia, el asesor legal y los funcionarios encargados de hacer cumplir la ley de
manera expedita
Analizar la intrusión
restaurar el sistema
E-8
Terminado Acción
Vuelva a conectar el sistema a la red
Supervise el sistema y la red en busca de señales de que el atacante está intentando acceder al sistema o la red
nuevamente
Documentar lecciones aprendidas
Prueba de seguridad
Realice periódicamente exploraciones de vulnerabilidades en el servidor web, el contenido generado dinámicamente

y la red de soporte.
Actualice el escáner de vulnerabilidades antes de la prueba
Corrija cualquier deficiencia identificada por el escáner de vulnerabilidades
Realice pruebas de penetración en el servidor web y la infraestructura de red de soporte
Corregir las deficiencias identificadas por las pruebas de penetración.
Llevar a cabo la administración remota y las actualizaciones de contenido
Utilice un mecanismo de autenticación sólido (p. ej., par de claves pública/privada, autenticación de dos factores)
Restrinja los hosts que se pueden usar para administrar o actualizar contenido de forma remota en el servidor web por
dirección IP y en la red interna Use protocolos seguros (por ejemplo, SSH, HTTPS)
Hacer cumplir el concepto de privilegio mínimo en la administración remota y la actualización de contenido (p. ej., intentar
minimizar los derechos de acceso para las cuentas de administración/actualización remotas)
Cambie las cuentas o contraseñas predeterminadas desde la utilidad o aplicación de administración remota
No permita la administración remota desde Internet a menos que existan mecanismos como
Se utilizan VPN
viceversa
E-9
Apéndice F—Lista de siglas
3DES Estándar de cifrado de datos triple
LCA Lista de control de acceso

HAY Asociación Americana de Discapacidad
AES Estándar de cifrado avanzado
AIREWeb Recuperación de información contradictoria en la web
AJAX JavaScript asíncrono y XML
API Interfaz de programación de aplicaciones
APWG Grupo de trabajo contra el phishing
ARP protocolo de resolucion de DIRECCION
ASCII Código estándar estadounidense de intercambio de información
ÁSPID Página del servidor activo
QUE Autoridad de certificación

CAPTCHA Prueba de Turing pública completamente automatizada para diferenciar a las computadoras de los
CD-R humanos Disco compacto grabable Centro para la educación y la investigación en el aseguramiento y la
CERÍAS seguridad de la información Centro de coordinación del equipo de respuesta a emergencias informáticas
CERT/CC Capacidad de asesoramiento sobre incidentes informáticos (Departamento de Energía de EE. UU.)
CIAC
director de información Director de información Interfaz
CGI de puerta de enlace común
CLF Formato de registro común Módulo
CMVP criptográfico Programa de validación Nombre común
CN Unidad central de procesamiento Solicitud de firma
UPC de certificado
RSE
DDoS Denegación de servicio distribuida

DESDE Estándar de cifrado de datos
DHS Departamento de Seguridad Nacional
DMZ Zona desmilitarizada
DN Nombre de dominio
DNS sistema de nombres de dominio
Departamento de Defensa
Departamento de Defensa
De Negación de servicio
DSS Estándar de firma digital
FIPS Estándar federal de procesamiento de información

FISMA Ley Federal de Gestión de la Seguridad de la Información
FOIA Acta de Libertad de Información
FTC Comisión Federal de Comercio
FTP Protocolo de transferencia de archivos
interfaz gráfica de usuario

Interfaz gráfica del usuario
HTCP Protocolo de almacenamiento en caché de hipertexto

HTML Lenguaje de marcado de hipertexto
HTTP Protocolo de Transferencia de Hipertexto
HTTPS Protocolo de transferencia de hipertexto seguro
F-1
IBMJSSE Extensión de sockets seguros Java de IBM

ICCC Centro de Quejas de Delitos en Internet
PCI Protocolo de almacenamiento en caché de Internet
IDPS Sistema de Detección y Prevención de Intrusos

DNI Sistema de detección de intrusos
IETF Grupo de Trabajo de Ingeniería de Internet
IIS Servidor de información de Internet
IMAP Protocolo de acceso a mensajes de Internet
IP protocolo de Internet
IPS Sistema de Prevención de Intrusión
IPSec Seguridad del protocolo de Internet
ES Sistema de informacion
ISP Proveedor de servicios de Internet
EEI Sistemas de seguridad de Internet
ESO Oficial de seguridad del sistema de información
ISSPM Gerente del programa de seguridad de los sistemas de información
ESO Tecnologías de la información
ITL Laboratorio de Tecnologías de la Información
JRE Entorno de tiempo de ejecución de Java

JSSE Extensión de socket seguro de Java
JSP Página del servidor Java
JVM máquina virtual de Java
Y Red de área local

LDAP Protocolo ligero de acceso a directorios
MAC Código de autenticación de mensajes
NARA Administración Nacional de Archivos y Registros

NetBIOS Sistema básico de entrada/salida de red
NFS Sistema de archivos de red
NIS Sistema de información de red
NIST Instituto Nacional de Normas y Tecnología
NSA Agencia de Seguridad Nacional
NSS Servicios de seguridad de red
NVD Base de datos de vulnerabilidad nacional
ODBC Conectividad de base de datos abierta

OGP Oficina de Gerencia y Presupuesto
TÚ Sistema operativo
OWASP Proyecto de seguridad de aplicaciones web abiertas
ordenador personal
Computadora personal
PDF Formato de Documento Portable
PEM Correo con privacidad mejorada
PHP Preprocesador de hipertexto PHP
información personal
Información de identificación personal
PKCS Estándar de criptografía de clave pública
PKI Infraestructura de Clave Pública
F-2
REDADA Conjunto redundante de discos económicos

REPS Protocolo de exclusión de robots
RFC Solicitud de comentarios
SHA-1 Algoritmo hash seguro-1

SHS Estándar de hash seguro
SIEM Información de seguridad y gestión de eventos
SMTP Protocolo simple de transferencia de correo
SNMP Protocolo Simple de Manejo de Red
SOHO oficina pequeña oficina en casa
SP Publicación Especial
sql lenguaje de consulta estructurado
SSH Cubierta segura
SSI El lado del servidor incluye
SSL Capa de sockets seguros
Número de Seguro Social
Número de seguro social
SSPI Interfaz del proveedor de soporte de seguridad
TCP Protocolo de Control de Transmisión

TLS Transport Layer Security
TOS Sistema operativo de confianza
UDP Protocolo de datagramas de usuario

UMBC Universidad de Maryland Condado de Baltimore
URI Identificador uniforme de recursos
URL Localizador Uniforme de Recursos
EE. UU. Estados Unidos
CERT de EE. UU. Equipo de respuesta a emergencias informáticas de Estados Unidos
VLAN Red de área local virtual

vpn Red privada virtual
WCCP Protocolo de coordinación de caché web

WWW World Wide Web
XML Lenguaje de marcado extensible

XSS Secuencias de comandos entre sitios
F-3
Apéndice G—Índice
A D
Control de acceso, 5-2, 5-5, 7-1 Defensa en profundidad, 2-4
Listas de control de acceso (ACL), 8-2 Zona Desmilitarizada (DMZ), 8-1
Bloqueo de cuenta, 4-5 Ataques de denegación de servicio (DoS), 2-1, 5-2, 5-3, 5-4
Contenido activo, 6-9, 6-15 Despliegue, 3-1
Lado del cliente, 6-10 Plan de despliegue, 3-1, 4-4
Lado del servidor, 6-12 Autenticación implícita, 7-2
Vulnerabilidades, 6-10, 6-12 Directivas, 5-5
ActiveX, 6-11 Directorios, 5-2, 5-4
Protocolo de resolución de direcciones (ARP), 8-11 Planificación de recuperación ante desastres, 3-7
Autenticación basada en direcciones, 7-1 Nombres de dominio, 6-7
Administración, 9-1
Flash de Adobe, 6-11
Adobe Shockwave, 6-11
Y
Registro de agentes, 9-2 Cifrado, 4-6, 7-1, 7-3, 7-4, 7-6
Alias, 5-4 Aceleradores de cifrado, 8-12
Funciones antiphishing, 6-6 Algoritmo de cifrado, 7-7
Software antispyware, 4-6 Registro de errores, 9-2, 9-5
Software antivirus, 4-6 Formato de registro extendido, 9-2
Cortafuegos de capa de aplicación, 8-7
JavaScript asíncrono y XML (AJAX), 6-11
Ataques, 2-1 F
Autenticación, 4-4, 7-1, 7-3
Comprobadores de integridad de archivos, 8-10
Pasarelas de autenticación, 3-10, 8-12
Archivos, 5-4
Copia autorizada del sitio web, 9-8
Cortafuegos, 4-6, 8-1, 8-5
B GRAMO
Política de copia de seguridad, 9-5

Grupos, 4-4
Copias de seguridad, 9-5
Autenticación básica, 7-2

Botnets, 2-1 H
Botes, 5-6, 7-2
Software de detección y prevención de intrusiones basado en host, 4-6
Preprocesador de hipertexto (PHP), 6-14
C
Instalación de certificado, 7-11 yo
Certificados, 7-8
Identificación, 7-1
Solicitud de firma de certificado (CSR), 7-8
Respuesta a incidentes, 9-9
Certificación y acreditación, 3-7
Oficial de seguridad de los sistemas de información (ISSO), 3-4
Gestión del cambio, 3-6
Gerente del programa de seguridad de los sistemas de información, 3-4
Director de Información (CIO), 3-4
Validación de entrada, 2-2, 6-15, 6-17
Conjuntos de cifrado, 7-6
Sistemas de detección y prevención de intrusos (IDPS), 8-9
Autenticación de cliente, 7-3
Sistemas de detección de intrusos (IDS), 8-9
Formato de registro combinado, 9-2
Sistemas de prevención de intrusos (IPS), 8-9
Comandos, 5-5
Interfaz de puerta de enlace común (CGI), 6-13
Formato de registro común (CLF), 9-2 j
Compromiso, 9-9
Filtros de contenido, 3-10, 8-12 Java, 6-10
Generadores de contenido, 6-9, 6-12 Java Enterprise Edition (EE), 6-14
Lado del servidor, 6-15, 6-17 JavaScript, 6-10
Planificación de la continuidad de las operaciones, 3-7

Galletas, 5-6, 6-4
Script entre sitios (XSS), 6-17
G-1
L S
Privilegio mínimo, 2-3 Modelo de seguridad Sandbox, 6-10
Enlaces, 5-4 Guiones, 5-5
Equilibradores de carga, 8-12 Programación segura, 3-6
Archivos de registro, 5-3, 9-1 Capa de sockets seguros (SSL), 7-3
Registro, 5-4, 8-8, 9-1 Aceleradores de capa de sockets seguros (SSL), 3-10
Aparatos de seguridad, 3-10
Lista de verificación de configuración de seguridad, 4-1
METRO
Controles de seguridad, 3-8, 4-6
Malware, 4-6 Pasarelas de seguridad, 3-10, 8-12
Controles de gestión, 3-6 Red de Política de seguridad, 2-2, 3-6
gestión, 8-5 Metacaracteres, 6-16 Pruebas de seguridad, 4-7, 9-11
Microsoft ASP.NET, 6-13 Entrenamiento de seguridad, 3-6
Configuración incorrecta, 2-1 Gestión sénior de TI, 3-4

Información sensible, 6-2, 7-1
Separación de privilegios, 2-3
Autenticación del servidor, 7-3
norte
El lado del servidor incluye (SSI), 6-13
Servicios, 4-3
Administradores de red, 3-5
Atajos, 5-4
Infraestructura de red, 8-1, 8-5
Visualización del código fuente, 6-3
Conmutadores de red, 8-11
Robots de spam, 5-7, 5-9
Una vez, 7-2
Arañas, 5-6
Configuración estandarizada, 3-6
O Enlaces simbólicos, 5-5
Cifrado de clave simétrica, 7-5
Configuración del sistema operativo, 4-2
SYN inundación, 5-4
Seguridad del sistema operativo, 4-1
Plan de seguridad del sistema, 3-7
Alojamiento subcontratado, 8-4
T
PAGS
Amenazas, 2-1
Política de contraseñas, 4-4
Registro de transferencias, 9-1
Software de gestión de parches, 4-6
Seguridad de la capa de transporte (TLS), 7-3
Parches, 4-1, 5-1
Sistemas operativos de confianza (TOS), 3-9
Pruebas de penetración, 4-7, 9-11, 9-12
Permisos, 5-3, 6-17
Datos personales, 6-3 EN
Personal, 3-8
Identificador uniforme de recursos (URI), 5-5
Farmacia, 6-7
Actualizaciones, 4-1, 5-1
Suplantación de identidad, 6-5
Cargas, 5-4
Seguridad física, 3-3
Cuentas de usuario, 4-4
Planificación, 3-1
Plataformas, 3-9
Plataformas pretempladas, 3-11 EN
Secretos previamente compartidos, 6-8
Cifrado de clave pública, 7-5 Plataformas virtualizadas, 3-12

Guión de Visual Basic (VBScript), 6-11
Vulnerabilidades, 2-2, 4-1, 6-10, 6-12, 6-17
R Escáneres de vulnerabilidad, 9-11
Exploración de vulnerabilidades, 4-7, 6-15, 9-11
Registro de referencia,
9-2 Registros de
referencia, 5-5 Proxies inversos, 3-11, En
8-12 Evaluación de riesgos, 3-6
Gestión de riesgos, 3-6 Protocolo de Desarrolladores de aplicaciones web, 3-5
exclusión de robots (REP), 5-7 robots.txt, 5- 7 Robots web, 5-6
Detector de rootkits, 4-6 Enrutadores, 8-1, 8-5 Navegadores web, 7-3

Contenido web, 5-3, 5-4, 5-6, 7-2, 8-6
Seguridad del contenido web, 6-1
Proceso de publicación web, 6-1
Administradores de servidores web, 3-5, 4-4
G-2
Dispositivos de servidor web, 3-10 Webmasters, 4-4

Instalación del software del servidor web, 5-1
G-3

Nistspecialpublication800 44ver2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Nistspecialpublication800 44ver2

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

Publicación especial 800-44

Directrices sobre protección pública

Recomendaciones del Instituto Nacional de

Publicación especial NIST 800-44 Pautas para proteger la web pública

Miles TracyWayne JansenKaren

División de Seguridad Informática

Departamento de Comercio de EE. UU.

Carlos M. Gutiérrez, Secretario

Instituto Nacional de Normas y Tecnología

James Turner, director interino

DIRECTRICES SOBRE LA PROTECCIÓN DE LOS SERVIDORES WEB PÚBLICOS

Informes sobre Tecnología de Sistemas Informáticos

Instituto Nacional de Estándares y Tecnología Publicación Especial 800-44 Versión 2 Natl.

Ciertas entidades comerciales, equipos o materiales pueden identificarse en este

DIRECTRICES SOBRE LA PROTECCIÓN DE LOS SERVIDORES WEB PÚBLICOS

Agradecimientos, Versión original

DIRECTRICES SOBRE LA PROTECCIÓN DE LOS SERVIDORES WEB PÚBLICOS

Resumen ejecutivo................................................ .................................................... ............ES-1

1. Introducción ............................................... .................................................... .....................1-1

1.1 Autoridad .................................................. .................................................... ...........1-1 1.2

2. Fondo ............................................... .................................................... .....................2-1

3. Planificación y administración de servidores web ........................................... ..........................3-1

DIRECTRICES SOBRE LA PROTECCIÓN DE LOS SERVIDORES WEB PÚBLICOS

6. Protección del contenido web .............................................. .................................................... ......6-1

DIRECTRICES SOBRE LA PROTECCIÓN DE LOS SERVIDORES WEB PÚBLICOS

Apéndice A— Recursos de seguridad del servidor web en línea.................................. ............. A-1

Apéndice B— Glosario .............................................. .................................................... ..........B-1

Apéndice C— Herramientas y aplicaciones de seguridad web .................................. ............. C-1

Apéndice D— Referencias .............................................. .................................................... ...... D-1

Apéndice E—Lista de control de seguridad del servidor web.................................. .......................... E-1

Apéndice F—Lista de siglas.................................................. .................................................... .... F-1

Apéndice G— Índice .................................................. .................................................... ................G-1

Lista de tablas y figuras

Paquetes de cifrado SSL/TLS.................................................... .......................................................7-7 Figura 7-2.

Ejemplo de CSR ................................................. .................................................... .........7-9

Figura 7-3. Ejemplo de certificado SSL/TLS codificado.................................................. ......................7-10 Figura 8-1.

DMZ simple de un solo cortafuegos ............................................... ..........................................8-2 Figura 8-2. DMZ de

dos cortafuegos ............................................... .................................................... ..8-2

Figura 8-3. Pierna de servicio DMZ.................................................... .................................................... ...8-3 Figura

8-4. Hospedaje de servidor web subcontratado ............................................... .............................8-4

DIRECTRICES SOBRE LA PROTECCIÓN DE LOS SERVIDORES WEB PÚBLICOS

La información confidencial en el servidor web puede leerse o modificarse sin autorización.

DIRECTRICES SOBRE LA PROTECCIÓN DE LOS SERVIDORES WEB PÚBLICOS

Protección, instalación y configuración del sistema operativo subyacente

Protección, instalación y configuración del software del servidor web

Usar, publicar y proteger la información y los datos de manera cuidadosa y sistemática.

Habilidades y entrenamiento requerido por el personal asignado

DIRECTRICES SOBRE LA PROTECCIÓN DE LOS SERVIDORES WEB PÚBLICOS

Política de seguridad del sistema de información de toda la organización

Gestión y control de cambios/configuración

Evaluación y gestión de riesgos

Concienciación y formación en seguridad.

Planificación de contingencia, continuidad de operaciones y planificación de recuperación ante desastres

Parchear y actualizar el sistema operativo

Eliminar o deshabilitar servicios y aplicaciones innecesarios

Configurar la autenticación de usuario del sistema operativo

Configurar controles de recursos

Instalar y configurar controles de seguridad adicionales

Realizar pruebas de seguridad del sistema operativo.

DIRECTRICES SOBRE LA PROTECCIÓN DE LOS SERVIDORES WEB PÚBLICOS

Aplicar parches y actualizar la aplicación del servidor web

Eliminar o deshabilitar servicios, aplicaciones y contenido de muestra innecesarios