Machine Translated by Google

Publicación especial 800-123

Guía del servidor general

Seguridad

Recomendaciones del Instituto

Nacional de Normas y Tecnología

Karen Bufanda
Wayne Jansen
millas tracy
Machine Translated by Google

Publicación especial del NIST 800-123

Guía de seguridad general del servidor

Recomendaciones de la Nacional
Instituto de Estándares y Tecnología

Karen Bufanda
Wayne Jansen
millas tracy

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

julio de 2008

Departamento de Comercio de EE. UU.

Carlos M. Gutiérrez, Secretario

Instituto Nacional de Normas y Tecnología

James M. Turner, director adjunto

Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

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 del país. 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.

Publicación especial del Instituto Nacional de Estándares y Tecnología 800-123 Natl.

Inst. Pararse. Tecnología Especificaciones. publ. 800-123, 53 páginas (julio de 2008)

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
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

Agradecimientos

Los autores, Karen Scarfone y Wayne Jansen del Instituto Nacional de Estándares y Tecnología (NIST) y Miles
Tracy de Tecnología de la Información de la Reserva Federal, desean agradecer a sus colegas que revisaron los
borradores de este documento y contribuyeron a su contenido técnico. Los autores desean agradecer a Murugiah
Souppaya, Tim Grance y Jim St. Pierre de NIST, Robert Dutton de Booz Allen Hamilton y Kurt Dillard por su ayuda
entusiasta y perspicaz durante el desarrollo del documento. Un agradecimiento especial también a los expertos en
seguridad que brindaron comentarios durante el período de comentarios públicos, en particular Dean Farrington
(Wells Fargo), Joseph Klein (Command Information), Dr.
Daniel Woodard (The Bionetics Corporation), y representantes de la Administración Federal de
Aviación.

Gran parte del contenido de esta publicación se derivó de la Publicación especial 800-44 Versión 2 del NIST,
Directrices sobre la protección de servidores web públicos, de Miles Tracy, Wayne Jansen, Karen Scarfone y
Theodore Winograd, y la Publicación especial 800-45 Versión 2 del NIST. Directrices sobre la seguridad del
correo electrónico, por Miles Tracy, Wayne Jansen, Karen Scarfone y Jason Butterfield.

iii
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

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 ............................... .................................................... ..................................1-2 1.4 Estructura
del documento .... .................................................... ..........................................1-2

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

2.1 Vulnerabilidades, amenazas y entornos del servidor ........................................... ........2-1 2.2
Categorización de la seguridad de la información y los sistemas de información ..................2-2 2.3
Pasos básicos de seguridad del servidor ....................................... .......................................2-3 2.4
Principios de seguridad del servidor.... .................................................... ....................................2-4
3. Planificación de la seguridad del servidor ....................................... .................................................... ..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
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 servidores, redes y seguridad .................. ..........................3-5 3.3
Prácticas de gestión ............ .................................................... ..........................3-5 3.4 Plan de
seguridad del sistema ............... .................................................... ..........................3-6 3.5
Requerimientos de Recursos Humanos ........... .................................................... ...............3 -7
4. Protección del sistema operativo del servidor ........................................... ..............................4-1
4.1 Parchear y actualizar el sistema operativo ............................................... ..........................4-1 4.2
Fortalecimiento y configuración segura del sistema operativo .................. ..........................................4-2
4.2.1 Quitar o deshabilite servicios, aplicaciones y protocolos de red
innecesarios .................................. .................................................... ........................4-2 4.2.2
Configurar la autenticación de usuario del SO .................. .......................................................4-4
4.2.3 Configurar los controles de recursos de forma adecuada .................................. ......4-6 4.3
Instalar y configurar controles de seguridad adicionales .................................. ...........4-6 4.4 Pruebas
de seguridad del sistema operativo ........................ ..........................................4-7
5. Protección del software del servidor................................................ .............................................5-1
5.1 Instalación segura del software del servidor ........................................... .......................5-1 5.2
Configuración de controles de acceso .................. .................................................... ...............5-2 5.3
Restricciones de los recursos del servidor .................. .................................................... ....5-3 5.4
Selección e implementación de tecnologías de autenticación y encriptación ...............5-4
6. Mantenimiento de la seguridad del servidor ........................................... ..........................6-1
6.1 Registro .................................................. .................................................... ...........6-1 6.1.1
Identificación de capacidades y requisitos de registro .................. ..........6-1 6.1.2 Revisión y
conservación de archivos de registro .................. ...................................6-2 6.1.3 Herramientas
de análisis de archivos de registro automatizados .................................................... ............6-3
6.2 Procedimientos de copia de seguridad del servidor .................. .................................................... .....6-4
6.2.1 Políticas de copia de seguridad de datos del servidor .................. .....................................6-4

IV
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

6.2.2 Tipos de copia de seguridad del servidor ............................... ...................................6-5

6.2.3 Mantener un servidor de prueba . .................................................... .............................6-6
6.3 Recuperación de un compromiso de seguridad ........... .................................................... ..6-6
6.4 Servidores de prueba de seguridad .................................. ..................................................6 -8
6.4.1 Escaneo de vulnerabilidades........................................... ...................................6-9
6.4.2 Prueba de penetración ... .................................................... ..............................6-10
6.5 Administración remota de un servidor ........... .................................................... .............6-11

Apéndices

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

Apéndice B— Siglas y abreviaturas .................................................. .......................... B-1

Apéndice C— Recursos ............................................... .................................................... ....... C-1

en
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

Resumen ejecutivo

Los servidores de una organización brindan una amplia variedad de servicios a usuarios internos y externos, y muchos servidores
también almacenan o procesan información confidencial para la organización. Algunos de los tipos de servidores más comunes son
servidores web, de correo electrónico, de base de datos, de administración de infraestructura y de archivos. Esta publicación aborda
los problemas generales de seguridad de los servidores típicos.

Los servidores suelen ser el objetivo de los atacantes debido al valor de sus datos y servicios. Por ejemplo, un servidor puede contener
información de identificación personal que podría usarse para realizar un robo de identidad.
Los siguientes son ejemplos de amenazas de seguridad comunes a los servidores:

Las entidades malintencionadas pueden explotar errores de software en el servidor o su sistema operativo subyacente para
obtener acceso no autorizado al servidor.

Los ataques de denegación de servicio (DoS) pueden dirigirse al servidor o a su infraestructura de red de soporte, denegando o
dificultando que los usuarios válidos hagan uso de sus servicios.

La información confidencial en el servidor puede ser leída por personas no autorizadas o modificada de manera no
autorizada.

La información confidencial transmitida sin cifrar o débilmente cifrada entre el servidor y el cliente puede ser interceptada.

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.

Las entidades malintencionadas pueden atacar a otras entidades después de comprometer un servidor. 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 comprometido que intenta explotar vulnerabilidades en los clientes de los usuarios
que acceden al servidor).

Este documento está destinado a ayudar a las organizaciones a instalar, configurar y mantener servidores 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

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.

Se recomiendan las siguientes pautas clave a los departamentos y agencias federales para mantener un
servidor seguro.

Las organizaciones deben planificar y abordar cuidadosamente los aspectos de seguridad de la implementación de un servidor.

Debido a que es mucho más difícil abordar la seguridad una vez que se han realizado el despliegue y la implementación, la seguridad
debe considerarse cuidadosamente 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 a tomar las inevitables decisiones de equilibrio
entre usabilidad, rendimiento y riesgo.

ES-1
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

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 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, 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 seguro.

Las prácticas de administración adecuadas son esenciales para operar y mantener un servidor 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 ayuden a garantizar la confidencialidad, integridad y disponibilidad de los recursos
del sistema de información. Para garantizar la seguridad de un servidor 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 el sistema operativo del servidor se implemente, configure y administre
para cumplir con los requisitos de seguridad de la organización.

El primer paso para asegurar un servidor es asegurar el sistema operativo subyacente. Los servidores más comúnmente disponibles operan
en un sistema operativo de propósito general. Se pueden evitar muchos problemas de seguridad si los servidores subyacentes de los
sistemas operativos 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 debe configurar nuevos servidores para reflejar los
requisitos de seguridad de su organización y reconfigurarlos a medida que esos requisitos cambien. El uso de guías de configuración de
seguridad o listas de verificación puede ayudar a los administradores a proteger los servidores 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, aplicaciones y protocolos de red innecesarios

Configurar la autenticación de usuario del sistema operativo

ES-2
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

Configurar controles de recursos

Instalar y configurar controles de seguridad adicionales, si es necesario

Realizar pruebas de seguridad del sistema operativo.

Las organizaciones deben asegurarse de que la aplicación del servidor 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 reflejarán el proceso del sistema operativo
mencionado anteriormente. El principio general es instalar la cantidad mínima de servicios necesarios y eliminar cualquier vulnerabilidad conocida
mediante parches o actualizaciones. Si el programa de instalación instala aplicaciones, servicios o scripts innecesarios, deben eliminarse
inmediatamente después de que finalice el proceso de instalación. La protección de la aplicación del servidor generalmente incluiría los siguientes
pasos:

Parche y actualice la aplicación del servidor

Eliminar o deshabilitar servicios, aplicaciones y contenido de muestra innecesarios

Configurar la autenticación de usuarios del servidor y los controles de acceso

Configurar controles de recursos del servidor

Pruebe la seguridad de la aplicación del servidor (y el contenido del servidor, si corresponde).

Muchos servidores también usan tecnologías de autenticación y encriptación para restringir quién puede acceder al servidor y para proteger la
información transmitida entre el servidor y sus clientes. Las organizaciones deben examinar periódicamente los servicios y la información
accesible en el servidor y determinar los requisitos de seguridad necesarios. Las organizaciones también deben estar preparadas para migrar
sus servidores a tecnologías criptográficas más sólidas a medida que se identifiquen debilidades en las tecnologías criptográficas existentes de
los servidores. Por ejemplo, NIST ha recomendado que el uso del Secure Hash Algorithm 1 (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.

Las organizaciones deben estar al tanto de los requisitos criptográficos y planificar la actualización de sus servidores en consecuencia.

Las organizaciones deben comprometerse con el proceso continuo de mantener la seguridad de los servidores para garantizar
la seguridad continua.

Mantener un servidor seguro requiere esfuerzo, recursos y vigilancia constantes por parte de una organización.
La administración segura de un servidor a diario es un aspecto esencial de la seguridad del servidor. Mantener la seguridad de un servidor
generalmente implicará las siguientes acciones:

Configurar, proteger y analizar archivos de registro de forma continua y frecuente

Copia de seguridad de la información crítica con frecuencia

Establecer y seguir procedimientos para recuperarse de compromisos

Probar y aplicar parches de manera oportuna

Pruebas de seguridad periódicamente.

ES-3
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

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, Director de la OMB, o cualquier otro
funcionario federal.

1.2 Propósito y alcance

El propósito de este documento es ayudar a las organizaciones a comprender las actividades fundamentales realizadas
como parte de la protección y el mantenimiento de la seguridad de los servidores que brindan servicios a través de comunicaciones
de red como función principal. Los hosts que, por cierto, brindan uno o varios servicios con fines de mantenimiento o accesibilidad,
como un servicio de acceso remoto para la resolución remota de problemas, no se consideran servidores en este documento. Los
tipos de servidores a los que se refiere esta publicación incluyen servidores externos de acceso público, como servicios web y de
correo electrónico, y una amplia gama de servidores internos. Este documento analiza la necesidad de proteger los servidores y
brinda recomendaciones para seleccionar, implementar y mantener los controles de seguridad necesarios.

Este documento aborda servidores comunes que utilizan sistemas operativos (SO) generales como Unix, Linux y Windows.
Muchas de las recomendaciones de este documento también pueden aplicarse a servidores que utilizan sistemas operativos
especializados o se ejecutan en dispositivos propietarios, pero otras recomendaciones no se podrán implementar o pueden tener
consecuencias no deseadas, por lo que dichos servidores se consideran fuera del alcance de este documento.
Otros tipos de servidores fuera del alcance de este documento son servidores virtuales y servidores altamente especializados,
particularmente dispositivos de infraestructura de seguridad (por ejemplo, firewalls, sistemas de detección de intrusos), que
tienen configuraciones y necesidades de seguridad inusuales.

Otros documentos del NIST, como la Publicación especial (SP) 800-45 Versión 2, Directrices sobre la seguridad del correo
electrónico y SP 800-44 Versión 2, Directrices sobre la protección de servidores web públicos, brindan recomendaciones para
tipos particulares de servidores. Las recomendaciones de este documento pretenden ser una base para otros documentos
relacionados con el servidor y no anulan las recomendaciones más específicas realizadas en dichos documentos.

1-1
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

1.3 Audiencia

Este documento ha sido creado principalmente para administradores de sistemas y administradores de seguridad que son responsables de
los aspectos técnicos de la protección de servidores. El material de este documento tiene una orientación técnica y se supone que los lectores
tienen al menos un conocimiento básico de la seguridad de sistemas y redes.

1.4 Estructura del documento

El resto de este documento está organizado en las siguientes secciones principales:

La Sección 2 proporciona información básica sobre los servidores y presenta una descripción general de los problemas de seguridad de
los servidores. También presenta los pasos de alto nivel para asegurar un servidor.

La sección 3 trata sobre la planificación y la gestión de la seguridad de los servidores.

La sección 4 presenta una descripción general de cómo proteger el sistema operativo de un servidor.

La Sección 5 analiza las acciones necesarias para instalar y configurar de forma segura el software del servidor, como el software del
servidor web y el software del servidor de correo electrónico.

La Sección 6 proporciona recomendaciones para mantener la seguridad de un servidor.

El documento también contiene apéndices con material de apoyo:

El Apéndice A contiene un glosario.

El Apéndice B contiene una lista de siglas y abreviaturas.

El Apéndice C enumera los recursos impresos y en línea que pueden ser útiles para comprender la seguridad general del servidor.

1-2
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

2. Fondo
Un servidor es un host que proporciona uno o más servicios para otros hosts a través de una red como función principal.1
Por ejemplo, un servidor de archivos proporciona servicios de uso compartido de archivos para que los usuarios puedan acceder,
modificar, almacenar y eliminar archivos. Otro ejemplo es un servidor de base de datos que proporciona servicios de base de datos para
aplicaciones web en servidores web. Los servidores web, a su vez, proporcionan servicios de contenido web a los navegadores web de
los usuarios. Hay muchos otros tipos de servidores, como aplicaciones, autenticación, servicios de directorio, correo electrónico,
administración de infraestructura, registro, servicios de resolución de nombres/direcciones (por ejemplo, servidor de nombres de dominio
[DNS]), impresión y acceso remoto.

Esta sección proporciona información básica sobre la seguridad del servidor. Primero analiza las vulnerabilidades y amenazas
comunes del servidor y las ubica en el contexto de los tipos de entornos en los que se implementan los servidores. A continuación,
explica cómo se pueden categorizar las necesidades de seguridad de un servidor para poder determinar los controles de seguridad
apropiados. La sección también brinda una descripción general de los pasos básicos que se requieren para garantizar la seguridad
de un servidor y explica los principios fundamentales de la seguridad.
servidores.

2.1 Vulnerabilidades, amenazas y entornos del servidor

Para asegurar un servidor, es fundamental definir primero las amenazas que se deben mitigar. El conocimiento de las amenazas
potenciales es importante para comprender las razones detrás de las diversas prácticas de seguridad técnica de línea de base
presentadas en este documento. Muchas amenazas contra los datos y los recursos son posibles debido a errores:
ya sea errores en el sistema operativo y el software del servidor que crean vulnerabilidades explotables, o errores cometidos por
usuarios finales y administradores. Las amenazas pueden involucrar actores intencionales (p. ej., un atacante que quiere acceder a la
información en un servidor) o actores no intencionales (p. ej., un administrador que se olvida de desactivar las cuentas de usuario de
un ex empleado). Las amenazas pueden ser locales, como un empleado descontento, o remotas. , como un atacante en otra área
geográfica. Las organizaciones deben realizar evaluaciones de riesgos para identificar las amenazas específicas contra sus servidores
y determinar la eficacia de los controles de seguridad existentes para contrarrestar las amenazas; luego deben realizar la mitigación de
riesgos para decidir qué medidas adicionales (si corresponde) deben implementarse, como se analiza en la Publicación especial (SP)
800-30 del NIST, Guía de evaluación de riesgos para sistemas de tecnología de la información. La realización de evaluaciones y
mitigación de riesgos ayuda a las organizaciones a comprender mejor su postura de seguridad y decidir cómo deben protegerse sus
servidores.

Las prácticas básicas de seguridad técnica que se presentan en esta publicación se basan en principios y prácticas de seguridad
técnica comúnmente aceptados, documentados en varios SP del NIST (incluidos SP 800-14, SP 800-23 y SP 800-53) y otras fuentes
como el Departamento Marco técnico de aseguramiento de la información de Defensa (DoD) . En particular, NIST SP 800-27,
Principios de ingeniería para la seguridad de la tecnología de la información (una línea de base para lograr la seguridad), contiene un
conjunto de principios de ingeniería para la seguridad del sistema que proporcionan una base sobre la cual se basa un enfoque más
coherente y estructurado para el diseño, desarrollo, y se puede construir la implementación de capacidades de seguridad de TI.

Un elemento importante de la planificación de los controles de seguridad apropiados para un servidor es comprender las
amenazas asociadas con el entorno en el que se implementa el servidor.2 Las recomendaciones de esta publicación se basan en la
suposición de que los servidores se encuentran en entornos empresariales típicos y, por lo tanto, enfrentan las amenazas y tienen las
necesidades de seguridad generalmente asociadas con dichos entornos. Organizaciones

1
A los efectos de este documento, un host que no proporciona servicios a otros hosts como función principal, pero que, de paso,
proporciona uno o varios servicios con fines de mantenimiento o accesibilidad, no se considera un servidor. Un ejemplo es una
computadora portátil que tiene un servicio de acceso remoto habilitado para que el personal de soporte de TI pueda mantener la computadora
portátil de forma remota y solucionar problemas.
2
Hay información adicional disponible sobre entornos en NIST SP 800-70, Programa de listas de verificación de configuración de seguridad para
productos de TI: Guía para usuarios y desarrolladores de listas de verificación (http://csrc.nist.gov/publications/PubsSPs.html).

2-1
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

es probable que la implementación de servidores en entornos de mayor seguridad deba emplear controles de seguridad
más restrictivos que las recomendaciones de esta publicación. Para los servidores en entornos heredados, las
organizaciones deben protegerlos como si estuvieran en un entorno empresarial típico o en un entorno de mayor
seguridad, según corresponda, y realizar las mínimas alteraciones de control de seguridad posibles para facilitar el acceso heredado.

2.2 Categorización de Seguridad de la Información y Sistemas de Información

El modelo clásico de seguridad de la información define tres objetivos de seguridad: mantener la

confidencialidad, la integridad y la disponibilidad. La confidencialidad se refiere a proteger la información para que no
sea accedida por personas no autorizadas. La integridad se refiere a garantizar la autenticidad de la información: que
la información no se altere y que la fuente de la información sea genuina. Disponibilidad significa que los usuarios
autorizados pueden acceder a la información. Cada objetivo aborda un aspecto diferente de brindar protección a la
información.

Determinar qué tan fuerte debe protegerse un sistema se basa en gran medida en el tipo de información que el sistema
procesa y almacena. Por ejemplo, un sistema que contiene registros médicos probablemente necesite una protección
mucho más sólida que una computadora que solo se usa para ver documentos publicados públicamente. Esto no implica
que el segundo sistema no necesite protección; todos los sistemas deben estar protegidos, pero el nivel de protección
puede variar según el valor del sistema y sus datos. La publicación Federal Information Processing Standards (FIPS)
(PUB) 199, Standards for Security Categorization of Federal Information and Information System establece criterios para
determinar la categoría de seguridad de un sistema.3 FIPS PUB 199 define tres categorías de seguridad: baja, moderada
y alta. basado en el impacto potencial de una brecha de seguridad que involucre un sistema en particular:

“El impacto potencial es BAJO si se espera que la pérdida de confidencialidad, integridad o disponibilidad tenga un
efecto adverso limitado en las operaciones de la organización, los activos de la organización o las personas. Un efecto
adverso limitado significa que, por ejemplo, la pérdida de confidencialidad, integridad o disponibilidad podría (i) causar
una degradación en la capacidad de la misión en la medida y duración que la organización pueda realizar sus
funciones principales, pero la efectividad de la las funciones se reducen notablemente; (ii) resultar en daños menores
a los activos de la organización; (iii) resultar en una pérdida financiera menor; o (iv) resultar en daños menores a las
personas.

El impacto potencial es MODERADO si se espera que la pérdida de confidencialidad, integridad o disponibilidad

tenga un efecto adverso grave en las operaciones de la organización, los activos de la organización o las personas.
Un efecto adverso grave significa que, por ejemplo, la pérdida de confidencialidad, integridad o disponibilidad podría
(i) causar una degradación significativa en la capacidad de la misión en la medida y duración en que la organización
pueda realizar sus funciones principales, pero la eficacia de las funciones se reducen significativamente; (ii) resultar
en un daño significativo a los activos de la organización; (iii) resultar en pérdidas financieras significativas; o (iv)
resulte en un daño significativo a las personas que no implique la pérdida de la vida o lesiones graves que pongan
en peligro la vida.

El impacto potencial es ALTO si se espera que la pérdida de confidencialidad, integridad o disponibilidad tenga un
efecto adverso grave o catastrófico en las operaciones de la organización, los activos de la organización o las
personas. Un efecto adverso grave o catastrófico significa que, por ejemplo, la pérdida de confidencialidad, integridad
o disponibilidad podría (i) causar una degradación grave o pérdida de la capacidad de la misión hasta tal punto y
duración que la organización no pueda realizar una o más de sus funciones principales; (ii) resultar en daños
importantes a los activos de la organización; (iii) resultar en pérdidas financieras importantes; o (iv) resulten en daños
graves o catastróficos a las personas que impliquen la pérdida de la vida o lesiones graves que pongan en peligro la
vida”.

3
FIPS PUB 199 está disponible para descargar desde http://csrc.nist.gov/publications/PubsFIPS.html.

2-2
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

Cada sistema, incluidos todos los servidores que forman parte del sistema, debe protegerse en función del impacto potencial en el
sistema de una pérdida de confidencialidad, integridad o disponibilidad. Las medidas de protección (también conocidas como controles de
seguridad) tienden a clasificarse en dos categorías. En primer lugar, es necesario resolver las debilidades de seguridad del sistema. Por
ejemplo, si un sistema tiene una vulnerabilidad conocida que los atacantes podrían explotar, el sistema debe parchearse para eliminar o
mitigar la vulnerabilidad. En segundo lugar, el sistema debe ofrecer solo la funcionalidad requerida a cada usuario autorizado, para que
nadie pueda usar funciones que no son necesarias. Este principio se conoce como privilegio mínimo. La limitación de la funcionalidad y la
resolución de las debilidades de seguridad tienen un objetivo común: dar a los atacantes la menor cantidad posible de oportunidades para
violar un sistema.

Un problema común con los controles de seguridad es que a menudo hacen que los sistemas sean menos convenientes o más
difíciles de usar. Cuando la facilidad de uso es un problema, muchos usuarios intentarán eludir los controles de seguridad; por ejemplo,
si las contraseñas deben ser largas y complejas, los usuarios pueden anotarlas. Equilibrar la seguridad, la funcionalidad y la usabilidad
suele ser un desafío. Esta guía intenta lograr un equilibrio adecuado y hacer recomendaciones que brinden una solución razonablemente
segura al mismo tiempo que ofrecen la funcionalidad y la facilidad de uso que requieren los usuarios.

Otro principio fundamental respaldado por esta guía es el uso de múltiples capas de seguridad: defensa en profundidad. Por ejemplo,
un sistema puede estar protegido contra ataques externos por varios controles, incluido un firewall basado en la red, un firewall
basado en host y la aplicación de parches al sistema operativo. La motivación para tener múltiples capas es que si una capa falla o
no puede contrarrestar una determinada amenaza, otras capas pueden evitar que la amenaza infrinja con éxito el sistema. Una
combinación de controles basados en la red y en el host suele ser más eficaz para proporcionar una protección constante a los sistemas.

NIST SP 800-53 Revisión 2, Controles de seguridad recomendados para los sistemas de información federales, propone controles
mínimos de seguridad técnica, operativa y de gestión de referencia para los sistemas de información.4
Estos controles deben implementarse en función de las categorizaciones de seguridad propuestas por FIPS 199, como se describe
anteriormente en esta sección. Esta guía debería ayudar a las agencias a cumplir con los requisitos básicos para los servidores
implementados en sus entornos.

2.3 Pasos básicos de seguridad del servidor

Se requieren una serie de pasos para garantizar la seguridad de cualquier servidor. 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 para la seguridad del servidor
dentro del contexto de la política de seguridad de la organización debería resultar efectivo:

1. Planificar la instalación y la implementación del sistema operativo (SO) y otros componentes para el
servidor. La sección 3 aborda este paso.

2. Instale, configure y asegure el sistema operativo subyacente. Esto se discute en la Sección 4.

3. Instale, configure y asegure el software del servidor. La Sección 5 describe este paso.

4. Para servidores que alojan contenido, como servidores web (páginas web), servidores de bases de datos (bases de datos) y
servidores de directorio (directorios), asegúrese de que el contenido esté debidamente protegido. Esto depende en gran medida
del tipo de servidor y del tipo de contenido, por lo que está fuera del alcance de esta publicación brindar recomendaciones para la
seguridad del contenido. Los lectores deben consultar las publicaciones pertinentes del NIST (consulte el Apéndice C) y otras
fuentes de recomendaciones de seguridad para obtener información sobre cómo proteger el servidor.
contenido.

4
NIST SP 800-53 Revisión 2, creado en respuesta a FISMA, está disponible en http://csrc.nist.gov/publications/PubsSPs.html.

2-3
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

5. Emplear mecanismos de protección de red adecuados (p. ej., cortafuegos, enrutador de filtrado de paquetes y
apoderado). La elección de los mecanismos para una situación particular depende de varios factores, incluida la ubicación
de los clientes del servidor (por ejemplo, Internet, acceso interno, interno y remoto), la ubicación del servidor en la red, los
tipos de servicios ofrecidos por el servidor, y los tipos de amenazas contra el servidor. En consecuencia, esta publicación
no presenta recomendaciones para seleccionar mecanismos de protección de red. NIST SP 800-41, Directrices sobre
cortafuegos y política de cortafuegos y NIST SP 800-94, Guía para los sistemas de detección y prevención de intrusiones
(IDPS), contienen información adicional sobre los mecanismos de protección de la red.

6. Emplear procesos seguros de administración y mantenimiento, incluida la aplicación de parches y actualizaciones,

monitoreo de registros, copias de seguridad de datos y SO, y pruebas de seguridad periódicas. Este paso se describe
en la Sección 6.

Las prácticas recomendadas en este documento están diseñadas para ayudar a mitigar los riesgos asociados con los
servidores. Se basan y asumen la implementación de prácticas descritas en las publicaciones del NIST sobre seguridad de
sistemas y redes enumeradas en el Apéndice C.

2.4 Principios de seguridad del servidor

Al abordar problemas de seguridad del servidor, es una excelente idea tener en cuenta los siguientes principios generales
de seguridad de la información:5

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.

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 del
administrador del sistema debe ser independiente de la del administrador de la base de datos.

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.

5
Derivado de Matt Curtin, Developing Trust: Online Privacy and Security, noviembre de 2001 y de Jerome H. Saltzer y Michael
Schroeder, "The Protection of Information in Computer Systems", Proceedings of the IEEE, vol. 63, páginas 1278–
1308

2-4
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

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.

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-5
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

3. Planificación de la seguridad del servidor

El aspecto más crítico de la implementación de un servidor seguro es la planificación cuidadosa antes de la instalación, configuración e
implementación. Una planificación cuidadosa garantizará que el servidor sea lo más seguro posible y cumpla con todas las políticas
organizacionales relevantes. Muchos problemas de rendimiento y seguridad de los servidores pueden atribuirse 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, se deben considerar los siguientes elementos:6

Identifique los propósitos del servidor.

– ¿Qué categorías de información se almacenarán en el servidor?

– ¿Qué categorías de información se procesarán o transmitirán a través del servidor?

– ¿Cuáles son los requisitos de seguridad para esta información?

– ¿Se recuperará o almacenará alguna información en otro host (p. ej., servidor de base de datos, servidor de directorio,
servidor web, servidor de almacenamiento conectado a la red (NAS), servidor de red de área de almacenamiento (SAN))?

– ¿Cuáles son los requisitos de seguridad para cualquier otro host involucrado?

– Qué otro(s) servicio(s) proporcionará(n) el servidor (en general, dedicando el host a un solo
servicio 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 el servidor, 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?

Identificar los servicios de red que se proporcionarán en el servidor, como el Protocolo de transferencia de hipertexto
(HTTP), Protocolo de transferencia de archivos (FTP), Protocolo simple de transferencia de correo (SMTP), Sistema de archivos de red

6
Contenido derivado de Julia Allen et al., Seusing Network Servers, abril de
2000, http://www.sei.cmu.edu/pub/documents/sims/pdf/sim010.pdf

3-1
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

(NFS) o servicios de bases de datos (p. ej., Conectividad abierta de bases de datos [ODBC]). También se deben identificar los
protocolos de red que se utilizarán para cada servicio (por ejemplo, IPv4, IPv6).

Identifique cualquier software de servicio de red, tanto de cliente como de servidor, que se instalará en el servidor y en cualquier otro
servidor de soporte.

Identifique los usuarios o categorías de usuarios del servidor y cualquier host de soporte.

Determine los privilegios que tendrá cada categoría de usuario en el servidor y los hosts de soporte.

Determine cómo se administrará el servidor (p. ej., 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 cumplen 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 puede determinar la elección del sistema operativo. Sin embargo, en la medida de lo posible,
los administradores de servidores deben elegir un sistema operativo que proporcione lo siguiente:7

Capacidad para restringir granularmente las actividades administrativas o de nivel raíz solo a usuarios autorizados

Capacidad para controlar granularmente 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 para servidores web, si corresponde

Capacidad para registrar actividades de servidor apropiadas para detectar intrusiones e intentos de intrusión

7
Contenido derivado de Julia Allen et al., Seusing Network Servers, abril de
2000, http://www.sei.cmu.edu/pub/documents/sims/pdf/sim010.pdf

3-2
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

Provisión de una capacidad de firewall basada en host para restringir el tráfico entrante y saliente

Compatibilidad con protocolos de autenticación sólidos y algoritmos de cifrado

Además, las organizaciones deben considerar la disponibilidad de personal capacitado y experimentado para administrar el 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.

Muchos servidores albergan información confidencial, y muchos otros, como los servidores web públicos, deben tratarse como
confidenciales debido al daño que podría sufrir la reputación de la organización si se compromete la integridad de los servidores. En
tales casos, es fundamental que los servidores estén ubicados en entornos físicos seguros. Al planificar la ubicación de un servidor, se
deben considerar los siguientes aspectos:

¿Existen los mecanismos de protección de seguridad física apropiados para el servidor y sus componentes de red
(p. ej., enrutadores, conmutadores)? Ejemplos incluyen-

– Cerraduras

– Acceso al lector de tarjetas

– Guardias de seguridad

– Sistemas de detección de intrusos físicos (p. ej., sensores de movimiento, cámaras).

¿Existen controles ambientales adecuados para que se mantenga la humedad y temperatura necesarias? Si se requiere alta
disponibilidad, ¿existen controles ambientales redundantes?

¿Hay una fuente de energía de respaldo? ¿Por cuánto tiempo proporcionará energía?

¿Existe un equipo adecuado de contención de incendios? ¿Minimiza el daño al equipo que de otro modo no se vería afectado por
el fuego?

Si se requiere alta disponibilidad, ¿hay conexiones de red redundantes? (Para los servidores conectados a Internet, esto
generalmente significa conexiones a Internet de al menos dos proveedores de servicios de Internet [ISP] diferentes).
¿Hay otro centro de datos que se pueda usar para alojar servidores en caso de una catástrofe en el centro de datos original?

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 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 involucrado en la planificación, implementación
y administración del servidor. Esta sección proporciona una lista de funciones genéricas e identifica sus responsabilidades en relación
con la seguridad del servidor. Estos roles son para fines de discusión y pueden variar según la organización.

3-3
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

3.2.1 Director de información

El Director de Información (CIO) se asegura de que la postura de seguridad de la organización sea adecuada. El CIO brinda
servicios de dirección y asesoría para la protección de los sistemas de información para toda la organización. El CIO es
responsable de las siguientes actividades asociadas con los servidores:

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.

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. Los ISSPM son
responsables de las siguientes actividades asociadas a los servidores:

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:

Desarrollar estándares y procedimientos de seguridad interna para los servidores 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 perfiles de configuración estándar para los servidores y la infraestructura de red de soporte controlada por la
organización, incluidos, entre otros, sistemas operativos, firewalls, enrutadores y aplicaciones de servidor.

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-4
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

3.2.4 Administradores de servidores, redes y seguridad

Los administradores de servidores son arquitectos de sistemas responsables del diseño, la implementación y el
mantenimiento generales de un servidor. Los administradores de red son responsables del diseño general, la implementación
y el mantenimiento de una red. Los administradores de seguridad se dedican a realizar funciones de seguridad de la
información para servidores y otros hosts, así como redes. Las organizaciones que tienen un equipo de seguridad de la
información dedicado suelen tener administradores de seguridad. Diariamente, los administradores de servidores, redes y
seguridad 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 con
servidores:

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.3 Prácticas de gestión

Las prácticas de gestión adecuadas son críticas para operar y mantener un servidor 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 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 es responsable 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.

3-5
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

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 software de servidor ampliamente utilizados. Esto proporcionará recomendaciones a los administradores de servidores
y redes 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 para servidores 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 ajustarse a las mejores prácticas
de seguridad. 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.8

Certificación y acreditación: la certificación en el contexto de la seguridad del sistema 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.
9

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.10 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 documentación del proceso estructurado.

8
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/PubsSPs.html).
9
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/PubsSPs.html).
10
El material de esta subsección se deriva de 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/PubsSPs.html).

3-6
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

de planificar 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ón11 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, incluido el
entorno de red, la ubicación del sistema en la red, y las relaciones del sistema con otros sistemas.

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 principalmente implementados y ejecutados 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.12

3.5 Requisitos de recursos humanos

El mayor desafío y gasto en el desarrollo y mantenimiento seguro de un servidor 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 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. Se cuenta con recursos humanos adecuados y suficientes.

11
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.

12
Para obtener más detalles sobre los controles de gestión, operativos y técnicos, consulte NIST SP 800-53 Revisión 2, 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/PubsSPs.html).

3-7
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

el aspecto más importante de la seguridad efectiva del servidor. 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, las organizaciones deben
considerar lo siguiente:

Personal requerido: ¿Qué tipo de personal se requiere? Ejemplos de posibles puestos son administradores de sistemas,
administradores de servidores, administradores de redes e ISSO.

Habilidades requeridas: ¿Cuáles son las habilidades requeridas para planificar, desarrollar y mantener adecuadamente el
servidor de manera segura? Los ejemplos incluyen la administración del sistema operativo, la administración de la red 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 respaldar el servidor? 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 el personal está 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.

– 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 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, cambian constantemente, al igual que la tecnología. Esto significa que lo que es adecuado hoy puede no
serlo mañana, por lo que las necesidades de personal deben reevaluarse periódicamente y se debe realizar capacitación adicional y
otras actividades de desarrollo de habilidades según sea necesario.

3-8
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

4. Protección del sistema operativo del servidor

Los servidores 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 se configuran adecuadamente. Debido a que los fabricantes desconocen las necesidades de seguridad de
cada organización, los administradores de servidores deben configurar nuevos servidores para reflejar los requisitos de seguridad de sus organizaciones y
reconfigurarlos a medida que esos requisitos cambian. Las prácticas recomendadas aquí están diseñadas para ayudar a los administradores de servidores
con la configuración de seguridad del servidor. Los administradores de servidores que administran los servidores existentes deben confirmar que sus
servidores abordan los problemas discutidos.

Las técnicas para asegurar 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 suelen contener recomendaciones para configuraciones más sólidas que el nivel de seguridad
predeterminado y también pueden contener instrucciones paso a paso para proteger los servidores.13 Además, muchas organizaciones mantienen sus
propias pautas específicas para sus requisitos. También existen algunas herramientas automatizadas para proteger los sistemas operativos y se recomienda
su uso.

Después de planificar la instalación y la implementación del sistema operativo, como se describe en la Sección 3, y de instalar el sistema operativo, son
necesarios los siguientes pasos básicos para asegurar el sistema operativo:

Parchear y actualizar el sistema operativo

Fortalezca y configure el sistema operativo para abordar la seguridad adecuadamente

Instalar y configurar controles de seguridad adicionales, si es necesario

Pruebe la seguridad del sistema operativo para asegurarse de que los pasos anteriores abordaron adecuadamente todos los problemas de seguridad.

El resultado combinado de estos pasos debería ser un nivel razonable de protección para el sistema operativo del servidor.

4.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 o exponerlo a usuarios que no
sean de confianza. Para detectar y corregir adecuadamente estas vulnerabilidades, los administradores del servidor deben hacer lo siguiente:

Cree, documente e implemente un proceso de aplicación de parches.14

Identificar vulnerabilidades y parches aplicables.15

Mitigar las vulnerabilidades temporalmente si es necesario y factible (hasta que los parches estén disponibles, probados e instalados).

Instalar arreglos permanentes (parches, actualizaciones, etc.)

13
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.
14
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/PubsSPs.html. Se puede implementar un único proceso de administración de parches para los sistemas operativos
y las aplicaciones (incluido el software del servidor).
15
Para verificar las vulnerabilidades en los sistemas operativos, el software del servidor y otras aplicaciones, consulte la base de datos nacional de vulnerabilidades
(NVD) del NIST en http://nvd.nist.gov/.

4-1
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

Los administradores deben asegurarse de que los servidores, especialmente los nuevos, estén adecuadamente protegidos durante el
proceso de aplicación de parches. Por ejemplo, un servidor que no está completamente parcheado o que no está configurado de forma
segura podría verse comprometido por amenazas si se puede acceder a él abiertamente mientras se está parcheando. Al preparar nuevos
servidores 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
se hayan transferido 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 esta sección. ha sido interpretado.

Coloque los servidores en una red de área local virtual (VLAN)16 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 regulares hasta que se hayan realizado todos los pasos de
configuración enumerados en esta sección.

Por lo general, los administradores no deben aplicar parches a los servidores de producción sin antes probarlos en otro servidor con una
configuración idéntica, ya que los parches pueden causar problemas inesperados sin darse cuenta con el funcionamiento adecuado del servidor.
Aunque los administradores pueden configurar servidores para descargar parches automáticamente, los servidores no deben configurarse para
instalarlos automáticamente para que puedan probarse primero.

4.2 Fortalecimiento y configuración segura del sistema operativo

Los administradores deben realizar los siguientes pasos para reforzar y configurar de forma segura un sistema operativo de servidor:

Eliminar servicios, aplicaciones y protocolos de red innecesarios

Configurar la autenticación de usuario del sistema operativo

Configure los controles de recursos de forma adecuada.

Estos pasos se analizan con más detalle en las Secciones 4.2.1 a 4.2.3. Además, para situaciones particularmente de alta seguridad, los
administradores deben considerar configurar el sistema operativo para que actúe como un host bastión. Un host bastión tiene controles de
seguridad particularmente fuertes y está configurado para ofrecer la menor funcionalidad posible. Los detalles para establecer un host bastión
son necesariamente específicos del sistema operativo, por lo que están fuera del alcance de esta publicación.

4.2.1 Quitar o deshabilitar servicios, aplicaciones y protocolos de red innecesarios

Idealmente, un servidor debería estar en un host dedicado de un solo propósito. Al configurar el sistema operativo, elimine todos los
servicios, aplicaciones y protocolos de red (p. ej., IPv4, IPv6) que no sean necesarios y deshabilite los componentes innecesarios que no se
puedan eliminar. Si es posible, instale la configuración mínima del sistema operativo y luego agregue, elimine o deshabilite servicios, aplicaciones
y protocolos de red según sea necesario. 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 que es mejor no instalar servicios innecesarios. Los tipos comunes de servicios y aplicaciones que
generalmente se deben eliminar si no se requieren (o deshabilitar si no se pueden eliminar) incluyen los siguientes:

dieciséis

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
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

Servicios de uso compartido de archivos e impresoras (p. ej., sistema básico de entrada/salida de red de Windows [NetBIOS] uso
compartido de archivos e impresoras, sistema de archivos de red [NFS], FTP)

Servicios de redes inalámbricas

Programas de control remoto y acceso remoto, particularmente aquellos que no encriptan fuertemente sus comunicaciones (por
ejemplo, Telnet)17

Servicios de directorio (p. ej., Protocolo ligero de acceso a directorios [LDAP], Sistema de información de red [NIS])

servidores web y servicios

Servicios de correo electrónico (p. ej., 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.

La eliminación o desactivación de servicios innecesarios mejora la seguridad de un servidor de varias formas:18

Otros servicios no pueden verse comprometidos y utilizarse para atacar al host o perjudicar los servicios del servidor.
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. Al eliminarlos o deshabilitarlos, no deberían
afectar al servidor 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 6.1).

Las organizaciones deben determinar los servicios que se habilitarán en un servidor. Los servicios adicionales que pueden instalarse
incluyen servidores web, protocolos de acceso a bases de datos, protocolos de transferencia de archivos y 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.

17
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 shell seguro (SSH) o seguridad de protocolo de Internet (IPsec).
18
Contenido derivado de Julia Allen et al., Seusing Network Servers, abril de 2000, http://
www.sei.cmu.edu/pub/documents/sims/pdf/sim010.pdf

4-3
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

4.2.2 Configurar la autenticación de usuario del sistema operativo

Para los servidores, los usuarios autorizados que pueden configurar el sistema operativo están limitados a una pequeña cantidad de
administradores de servidores designados. Sin embargo, los usuarios que pueden acceder al servidor pueden variar desde unos pocos
empleados autorizados hasta toda la comunidad de Internet. Para hacer cumplir las restricciones de la política, si es necesario, el
administrador del servidor debe configurar el sistema operativo para autenticar a un posible usuario solicitando una prueba de que el usuario
está autorizado para dicho acceso. Incluso si un servidor permite el acceso no autenticado a la mayoría de sus servicios, el acceso
administrativo y otros tipos de acceso especializado deben limitarse a personas 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. En situaciones especiales, como servidores 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 de forma clara a través de una red que no sea de confianza porque un atacante puede interceptar y utilizar la
información para hacerse pasar por un usuario autorizado.

Para asegurarse de que se cuenta con la autenticación de usuario adecuada, siga los siguientes pasos:19

Quitar o deshabilitar cuentas predeterminadas innecesarias: la configuración predeterminada del sistema operativo a
menudo incluye cuentas de invitado (con y sin contraseña), cuentas de administrador o raíz y cuentas asociadas con servicios
locales y de red. Los nombres y contraseñas de esas cuentas son bien conocidos. Elimine (siempre que sea posible) 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. Para las cuentas predeterminadas que deben conservarse, incluidas las cuentas de invitado,
restrinja severamente el acceso a las cuentas, lo que incluye cambiar los nombres (cuando 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.
Tenga cuentas de usuario ordinarias para los administradores del servidor que también sean usuarios del servidor.

Configure la sincronización de tiempo automatizada: algunos protocolos de autenticación, como Kerberos, no funcionarán si la
diferencia de tiempo entre el host del cliente y el servidor de autenticación es significativa, por lo que los servidores que usan dichos
protocolos deben configurarse para sincronizar automáticamente la hora del sistema con un servidor de tiempo confiable. Por lo general,
el servidor de tiempo es interno de la organización y utiliza el Protocolo de tiempo de red (NTP) para la sincronización; Los servidores
NTP disponibles públicamente también están disponibles en Internet.

19
Contenido derivado de Julia Allen et al., Seusing Network Servers, abril de
2000, http://www.sei.cmu.edu/pub/documents/sims/pdf/sim010.pdf

4-4
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

Verifique la política de contraseñas de la organización: configure las contraseñas de las cuentas de manera adecuada. Los elementos
que pueden abordarse en una política de contraseñas incluyen los siguientes:

– Longitud: una longitud mínima para las contraseñas.

– Complejidad: la combinación de caracteres requerida. Un ejemplo es requerir que las contraseñas contengan
mayúsculas, minúsculas y caracteres no alfabéticos, y no contener palabras del “diccionario”.

– Antigüedad: cuánto tiempo puede permanecer sin cambios una contraseña. Muchas políticas requieren que los usuarios y
administradores para cambiar sus contraseñas periódicamente. En tales casos, la frecuencia debe determinarse por la longitud y
la complejidad impuestas de la contraseña, la confidencialidad de la información protegida y el nivel de exposición de las
contraseñas. Si se requiere el envejecimiento, se debe considerar la aplicación de una duración mínima del envejecimiento 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 envejecimiento de una contraseña
requisito cambiando la contraseña a una que hayan usado anteriormente. Si la política prohíbe la reutilización, es beneficioso, si es
posible, asegurarse 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, por ejemplo, no almacenar contraseñas
sin cifrar en el servidor, y requiere que los administradores usen contraseñas diferentes para sus cuentas de administración del servidor
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 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 el servidor es accesible externamente y un atacante conoce o puede
suponer un patrón en su convención de nomenclatura que les permite adivinar los nombres de las cuentas.

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 el servidor no se administrará de forma remota, deshabilite la capacidad para que el administrador o las cuentas de nivel raíz inicien
sesión desde la red.

Instale y configure otros mecanismos de seguridad para fortalecer la autenticación: si la información en el servidor 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 mas

4-5
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

costosos y difíciles de implementar, pero pueden estar justificados en algunas circunstancias. Cuando se utilizan tales 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 mediante IPsec o SSL/TLS, para proteger las contraseñas
durante la transmisión a través de redes que no son de confianza. Requerir que la autenticación del servidor se use con tecnologías de
encriptación reduce la probabilidad de éxito de ataques de intermediarios y de suplantación de identidad.

4.2.3 Configurar adecuadamente los controles de recursos

Todos los sistemas operativos de servidor de uso común 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 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 servidor u otros hosts en la red.
La auditoría también debe estar habilitada según corresponda para monitorear los intentos de acceder a los recursos protegidos.

En algunos casos, los administradores configuran el sistema operativo para proporcionar un entorno virtual aislado en el que se ejecutará
el software del servidor. Este entorno, a veces llamado sandbox o jail, presenta un conjunto limitado de recursos reales o virtuales a los
que pueden acceder el software del servidor o sus usuarios. El sistema operativo está configurado para que los procesos del servidor y
las acciones del usuario no puedan "salir" del entorno. Un ejemplo común de un entorno virtual aislado es el uso del comando chroot de
Unix para contener la actividad FTP anónima. Incluso si un usuario malicioso explotara una vulnerabilidad en el servicio FTP, el usuario
solo obtendría acceso al entorno virtual y no al sistema operativo subyacente. Los detalles sobre la creación de entornos sandbox y jail
son específicos del sistema operativo y del servidor y, por lo tanto, están fuera del alcance de esta publicación.

4.3 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, configurar y mantener 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 rootkit, para proteger el sistema operativo
local del malware y para detectar y erradicar cualquier infección que ocurra.20 Los ejemplos de cuándo sería útil el software
antimalware incluyen un sistema administrador trayendo medios infectados al servidor y un gusano de servicio de red contactando al
servidor e infectándolo.

Software de detección y prevención de intrusiones (IDPS) basado en host, para detectar ataques realizados contra el servidor,
incluidos los ataques DoS. Por ejemplo, una forma de IDPS basado en host, software de verificación de integridad de archivos, puede
identificar cambios en archivos críticos del sistema.

20
Hay disponible información adicional sobre el software antimalware en NIST SP 800-83, Guía para la prevención y el manejo de
incidentes de malware (http://csrc.nist.gov/publications/PubsSPs.html).

4-6
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

Cortafuegos basados en host, para proteger el servidor de accesos no autorizados.21

Software de administración de parches o administración de vulnerabilidades para garantizar que las vulnerabilidades se aborden
con prontitud. El software de administración de parches y administración de vulnerabilidades se puede usar solo para aplicar
parches o también para identificar nuevas vulnerabilidades en los sistemas operativos, servicios y aplicaciones del servidor.

Algunos servidores también utilizan tecnologías de cifrado de disco para proteger sus datos almacenados de atacantes que obtienen
acceso físico a los servidores. Las tecnologías de cifrado de disco están integradas en algunos sistemas operativos y también hay
disponibles productos de cifrado de disco de terceros.

Al planificar los controles de seguridad, los administradores de servidores 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. Los administradores de servidores también deben considerar cualquier control de seguridad basado en la red,
como firewalls de red y sistemas de detección de intrusos, que podrían brindar protección adicional para el servidor. Si los controles de
seguridad basados en el host consumen demasiados recursos para un servidor o no son factibles, los administradores del servidor
pueden necesitar compensar mediante el uso de controles de seguridad adicionales basados en la red para proteger el sistema operativo,
los servicios y las aplicaciones del servidor. Para muchos servidores, los controles de seguridad basados en la red se utilizan además de
los controles de seguridad basados en el host para proporcionar capas adicionales de seguridad.

4.4 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 y que los controles de seguridad estén configurados correctamente (por ejemplo,
los algoritmos criptográficos requeridos están en uso para proteger las comunicaciones de la red). 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 aplicación del servidor, se analizan en detalle en la
Sección 6.4. 22

Los factores que se deben considerar al decidir si probar el servidor de producción o un servidor que no sea de producción configurado
de manera similar incluyen los siguientes:

El posible impacto en el servidor de producción. Por ejemplo, si es probable que cierta técnica de prueba provoque una
denegación de servicio, entonces esa técnica probablemente debería usarse contra la no producción.
servidor.

La presencia de información confidencial de identificación personal (PII). Si las pruebas pueden exponer PII confidencial, como
números de seguro social (SSN) o información de tarjetas de crédito, a personas sin autorización para verla, entonces las
organizaciones deberían considerar realizar las pruebas en un servidor que no sea de producción que tenga una versión falsa de la
PII ( por ejemplo, datos de prueba en lugar de PII sensible real).

21
Para obtener más información sobre los cortafuegos, consulte NIST SP 800-41, revisión 1 (borrador), Directrices sobre cortafuegos y política de cortafuegos.
(http://csrc.nist.gov/publications/PubsSPs.html).
22
Para obtener información sobre otras técnicas de prueba, consulte NIST SP 800-115 (Borrador), Guía técnica para pruebas de seguridad de la información
(http://csrc.nist.gov/publications/PubsSPs.html).

4-7
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

Cuán similar pueden configurarse los servidores de producción y de no producción. En la práctica, suele
haber incoherencias entre los entornos de prueba y producción, lo que puede provocar la pérdida de
vulnerabilidades si se utilizan servidores que no son de producción.

4-8
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

5. Protección del software del servidor

Una vez que se ha instalado y asegurado el sistema operativo, como se describe en la Sección 4, el siguiente paso es instalar y
asegurar el software del servidor elegido, que se describe en esta sección. Antes de comenzar este proceso, lea atentamente la documentación
del software del servidor y comprenda las diversas opciones disponibles durante el proceso de instalación. Además, asegúrese de visitar el sitio
web del fabricante del software del servidor o un sitio web de base de datos de vulnerabilidades, como National Vulnerability Database (NVD),23
para determinar si hay vulnerabilidades conocidas y parches relacionados disponibles que deben instalarse o configurarse como parte de el
proceso de configuración. 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 particulares están disponibles de los fabricantes de servidores y de los repositorios de listas de verificación de seguridad.24

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 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 software del servidor

En muchos aspectos, la instalación y configuración seguras del software del servidor 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 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 software del servidor, se deben realizar los siguientes pasos:

Instale el software del servidor 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 vulnerabilidades conocidas en el software del servidor.

Cree un disco físico dedicado o una partición lógica (separado del sistema operativo y la aplicación del servidor) para los datos del
servidor, si corresponde.

Elimine o deshabilite todos los servicios instalados por la aplicación del servidor pero no requeridos (por ejemplo, gopher, FTP, HTTP,
administración remota).

Elimine o deshabilite todas las cuentas de usuario predeterminadas innecesarias creadas por la instalación del servidor.

Quite toda la documentación de los fabricantes del servidor.

Elimine todos los archivos de prueba o de ejemplo del servidor, incluido el contenido de muestra, los scripts y el código ejecutable.

23
NVD está disponible en http://nvd.nist.gov/.
24
NIST alberga un repositorio de listas de verificación de seguridad en http://checklists.nist.gov/.

5-1
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

Quite todos los compiladores innecesarios.

Aplique la plantilla de seguridad adecuada o el script de refuerzo al servidor.

Para servidores externos, vuelva a configurar los banners de servicio para que no informen el servidor y el tipo y la versión del
sistema operativo, si es posible.25

Configure pancartas de advertencia para todos los servicios que admitan tales pancartas.26

Configure cada servicio de red para escuchar las conexiones de los clientes solo en los puertos TCP y UDP necesarios, si es posible.27

Las organizaciones deberían considerar instalar el servidor con nombres de directorio, ubicaciones de directorio y nombres de
archivo no estándar si es posible. Muchas herramientas de ataque al servidor y gusanos que se dirigen a los servidores 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 servidor 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 pueda acceder utilizando estos
controles puede distribuirse potencialmente a todos los usuarios que acceden al servidor. Es probable que el software del servidor 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; de lo contrario, se puede
otorgar demasiado o muy poco acceso a los usuarios. Los administradores de servidores deben considerar la mejor manera de configurar los
controles de acceso para proteger la información almacenada en los servidores desde dos perspectivas:

Limite el acceso de la aplicación del servidor 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, donde se requieren niveles
más detallados de control de acceso.

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. Del mismo modo, los controles de acceso pueden imponer la separación de funciones al garantizar que los administradores
del servidor no puedan modificar los registros del servidor y, potencialmente, garantizar que el proceso del servidor 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:

25
Esto disuade a los atacantes novatos y algunas formas de malware, pero no disuadirá a los atacantes más expertos de identificar el servidor y el
tipo de sistema operativo.
26
Si la organización aún no tiene un texto de banner de advertencia estándar aprobado, trabaje con el asesor legal de la organización para desarrollar un
texto de banner adecuado.
27
Contenido derivado de Julia Allen et al., Seusing Network Servers, abril de 2000, http://
www.sei.cmu.edu/pub/documents/sims/pdf/sim010.pdf

5-2
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

– 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 del servidor.

Es vital que la aplicación del servidor se ejecute solo bajo una identidad individual única de usuario y grupo con controles de acceso muy
restrictivos. Las nuevas identidades de usuarios y grupos deben establecerse para uso exclusivo del software del servidor. 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);
asegúrese de que el servidor esté configurado para reducir sus privilegios a los del usuario del servidor después de realizar sus funciones
de inicialización.

Además, utilice el sistema operativo del servidor para limitar a qué archivos pueden acceder los procesos de servicio. 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. Use los controles de acceso del sistema operativo del host del servidor para hacer cumplir lo siguiente:28

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 solo pueden escribir en archivos y directorios de contenido del servidor si es necesario.

Los archivos temporales creados por el software del servidor están restringidos a un subdirectorio específico y adecuadamente
protegido (si es posible). El acceso a estos archivos temporales está limitado a los procesos del servidor que crearon los archivos (si es
posible).

También puede ser necesario asegurarse de que el software del servidor no pueda guardar (o, en algunos casos, leer) archivos fuera de la
estructura de archivos específica dedicada al contenido del servidor. 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) tanto directamente como a través del software del servidor.

5.3 Restricciones de recursos del servidor

Para mitigar los efectos de ciertos tipos de ataques DoS, configure el servidor para limitar la cantidad de recursos del sistema operativo que
puede consumir. Algunos ejemplos incluyen:

Instalar el contenido del servidor en un disco duro o partición lógica diferente al del sistema operativo y al software del servidor.

28
Derivado de Klaus-Peter Kossakowski y Julia Allen, Seuring Public Web Servers, 2000, http://
www.sei.cmu.edu/pub/documents/sims/pdf/sim011.pdf. Sus recomendaciones son específicas para servidores web, pero los
mismos principios se aplican a cualquier tipo de servidor.

5-3
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

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. 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, asegúrese de que el servidor 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 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. archivos

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 tenga suficientes recursos para manejar la situación de
manera adecuada.

Configurar el número máximo de procesos del servidor y/o conexiones de red que debe permitir el servidor.

Hasta cierto punto, estas acciones protegen contra ataques que intentan llenar el sistema de archivos en el sistema operativo del servidor con
información extraña e incorrecta que puede causar que el servidor se bloquee. La información de registro generada por el sistema operativo
del servidor puede ayudar a reconocer tales ataques. Como se discutió en la Sección 6.1, los administradores deben almacenar los registros
del servidor en servidores de registro centralizados siempre que sea posible y también almacenar los registros localmente si es factible. Si un
ataque hace que el servidor 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 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 de las inundaciones SYN al interceptarlos antes de que lleguen a los
servidores.

5.4 Selección e implementación de tecnologías de autenticación y cifrado

Muchos servidores admiten una variedad de tecnologías para identificar y autenticar usuarios con diferentes privilegios para acceder a
la información. Sin la autenticación del usuario, un servidor no puede restringir el acceso a los usuarios autorizados; todos los servicios
y la información serán accesibles para cualquier persona con acceso al servidor. En muchos casos, esto no es aceptable. El cifrado se puede
utilizar para proteger la información que atraviesa la conexión entre un servidor y un cliente. 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

5-4
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

la información ha sido autenticada. Esto puede violar la confidencialidad e integridad de la información crítica.

Las organizaciones deben examinar periódicamente los servicios y la información accesible en el servidor 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 algún nivel de autenticación del usuario, la organización debe determinar qué tecnologías o métodos
de autenticación proporcionarían 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. NIST SP 800-63, Directrices de autenticación electrónica, contiene información adicional
sobre los mecanismos de autenticación.

Las organizaciones del gobierno federal están obligadas a utilizar los Estándares Federales de Procesamiento de la Información (FIPS)-
implementaciones criptográficas validadas cuando se utiliza la criptografía para proteger los datos almacenados y las
comunicaciones de datos. El Programa de validación de módulos criptográficos (CMVP) realiza pruebas de validación de módulos
criptográficos.29 NIST proporciona una lista de fabricantes e implementaciones que cumplen con FIPS 14030. Implementaciones de
seguridad de la capa de transporte (TLS), NIST

32
SP 800-77, Guía de VPN con IPsec, y NIST SP 800-113, Guía de VPN con SSL.

Las organizaciones deben estar preparadas para migrar sus servidores a tecnologías criptográficas más sólidas con el tiempo, a
medida que se identifiquen debilidades en las tecnologías criptográficas existentes de los servidores. Por ejemplo, NIST ha recomendado
que el uso del Secure Hash Algorithm 1 (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.33 Las organizaciones deben estar al tanto de las funciones criptográficas. requisitos y recomendaciones y
planean actualizar sus servidores en consecuencia.

29
http://csrc.nist.gov/groups/STM/index.html Al
30
momento de escribir este artículo, la versión actual de FIPS 140 es 140-2, Requisitos de seguridad para módulos criptográficos
(http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf). FIPS 140-3 está actualmente disponible en borrador
(http://csrc.nist.gov/publications/PubsFIPS.html). http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401vend.htm
31
Todos estos SP del NIST están disponibles en http://csrc.nist.gov/publications/PubsSPs.html.
32

33
Consulte http://csrc.nist.gov/groups/ST/hash/index.html, FIPS PUB 180-2, Secure Hash Standard,
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf, y FIPS PUB 180-3 (Borrador), http://
csrc.nist.gov/publications/PubsFIPS.html para información adicional sobre los requisitos de la función hash.

5-5
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

6. Mantenimiento de la seguridad del servidor

Después de implementar inicialmente un servidor, los administradores deben mantener su seguridad de forma continua. Esta sección
proporciona recomendaciones generales para administrar servidores de forma segura. Las actividades vitales incluyen el manejo y el análisis
de archivos de registro, la realización de copias de seguridad periódicas del servidor, la recuperación de compromisos del servidor, la prueba
periódica de la seguridad del servidor y la administración remota de forma segura. Como se discutió en la Sección 4, las guías de configuración
de seguridad y las listas de verificación están disponibles públicamente para muchos sistemas operativos y software de servidor; muchos de
estos documentos contienen recomendaciones específicas del sistema operativo y del servidor para el mantenimiento de la seguridad.
Otras actividades de mantenimiento discutidas en secciones anteriores, y por lo tanto no duplicadas aquí, incluyen probar e implementar
parches y actualizaciones del sistema operativo y del servidor, mantener la configuración segura del software del sistema operativo y del
servidor, y mantener controles de seguridad adicionales utilizados para el servidor.34

6.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.35 Los registros de la red y del sistema son importantes, especialmente los registros del sistema en el caso de las
comunicaciones encriptadas, donde el monitoreo de la red es menos efectivo. El software del servidor puede proporcionar datos de registro
adicionales relevantes para eventos específicos del servidor.

La revisión de registros es mundana y reactiva, y muchos administradores de servidores 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 proporcionan:

Alertas de actividades sospechosas que requieren mayor investigación

Seguimiento de las actividades de un atacante

Asistencia en la recuperación del servidor

Asistencia en la investigación posterior al evento

Información requerida para trámites judiciales.

La selección e implementación de software de servidor específico determina qué acciones debe realizar el administrador del servidor
para establecer configuraciones de registro. Parte de la información contenida en los pasos a continuación puede no ser completamente
aplicable a todos los productos de software de servidor.

6.1.1 Identificación de capacidades y requisitos de registro

Cada tipo de software de servidor admite diferentes capacidades de registro. Algunos programas de servidor pueden usar un único
registro, mientras que otros programas de servidor pueden usar varios registros (cada uno para diferentes tipos de registros). Alguno

34
Esto incluye controles de seguridad tanto basados en el host como en la red. Sin embargo, en muchos entornos, los controles de seguridad
basados en la red, como los firewalls empresariales y los sistemas de detección de intrusos, los mantiene alguien que no es el administrador
del servidor.
35
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/PubsSPs.html.

6-1
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

El software del servidor permite a los administradores seleccionar entre varios formatos de registro, como propietario, base de datos y separado por
delimitadores.

Si un servidor 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 y el
servidor no los registrará. Si los administradores del servidor 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 host del servidor. La información de registro asociada con programas, scripts y complementos puede agregarse
significativamente a la información típica registrada por el servidor y puede resultar invaluable al investigar eventos.

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 brindan la capacidad de hacer cumplir 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 deben determinar las circunstancias en las que pueden desear habilitar dichas
comprobaciones (suponiendo que el software del servidor admita esta función).

Todos los servidores deben usar tecnologías de sincronización de tiempo, como el Protocolo de tiempo de red (NTP), para mantener sus relojes
internos sincronizados con una fuente de tiempo precisa. Esto proporciona marcas de tiempo precisas para los registros.

6.1.2 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 sospechosa desde un servidor web a las 8:17 am, entonces es apropiado revisar los registros generados alrededor de las 8:17 am. Los
registros del servidor también deben revisarse en busca de indicaciones de ataques. La frecuencia de las revisiones depende de los siguientes factores:

Cantidad de tráfico que recibe el servidor

Nivel de amenaza general (ciertos servidores reciben muchos más ataques que otros servidores 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

Valor de los datos y servicios proporcionados por el servidor.

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 un servidor.

6-2
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

administrador. Para reducir esta carga, se han desarrollado herramientas de análisis de registros automatizados (consulte la Sección 6.1.3).

Además, se necesita un análisis a largo plazo y más profundo de los registros. Debido a que un ataque al servidor puede involucrar cientos de
solicitudes únicas, un atacante puede intentar disfrazar un ataque al servidor 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, 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. Esto a menudo se denomina servidor de registro centralizado.
El registro centralizado a menudo se realiza mediante syslog, que es un protocolo de registro estándar. 36 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 o datos de registro de los hosts a los servidores y analizar los registros.37

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. El período de
retención de los archivos de registro archivados depende de varios factores, incluidos los siguientes:

Requisitos legales y reglamentarios

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

Nivel de amenaza.

6.1.3 Herramientas de análisis de archivos de registro automatizados

Muchos servidores reciben cantidades significativas de tráfico y los archivos de registro rápidamente se vuelven voluminosos.
Se deben instalar herramientas de análisis de registros automatizados para aliviar la carga de los administradores de servidores. Estas herramientas
analizan las entradas en los archivos de registro del servidor e identifican actividades sospechosas e inusuales. Como se mencionó en la Sección 6.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 también están disponibles para respaldar el análisis regular de tipos particulares de registros del
servidor.

El analizador de registros automatizado debe enviar cualquier evento sospechoso al administrador del servidor responsable o al equipo de respuesta a
incidentes de seguridad lo antes posible para una investigación de seguimiento. Algunas organizaciones

36
Syslog se define en IETF RFC 3164, The BSD Syslog Protocol, que está disponible en http://www.ietf.org/rfc/rfc3164.txt.
37
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/PubsSPs.html.

6-3
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

puede 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.38

6.2 Procedimientos de copia de seguridad del servidor

Una de las funciones más importantes de un administrador de servidor es mantener la integridad de los datos en el servidor. Esto es
importante porque los servidores suelen ser algunos de los hosts más expuestos y vitales en la red de una organización. El administrador
del servidor necesita realizar copias de seguridad del servidor periódicamente por varios motivos. Un servidor 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. Los datos del servidor también deben
respaldarse regularmente por razones legales y financieras.

6.2.1 Políticas de respaldo de datos del servidor

Todas las organizaciones necesitan crear una política de respaldo de datos del servidor. 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

– 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 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 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

38
Derivado de Karen Kent y Murugiah Souppaya, NIST SP 800-92, Guía para la gestión de registros de seguridad informática, abril
de 2006, http://csrc.nist.gov/publications/PubsSPs.html

6-4
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

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 registrada

Deberes específicos de un equipo de respaldo de datos central/organizacional, si existe.

6.2.2 Tipos de copia de seguridad del servidor

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 (es decir, una imagen de cada dato almacenado en los discos duros del servidor). La
ventaja de una copia de seguridad completa es que es fácil restaurar todo el servidor 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 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.

– Contenido estático (copias de seguridad menos frecuentes)

– Contenido dinámico (copias de seguridad más frecuentes)

– Comercio electrónico/gobierno electrónico (copias de seguridad muy frecuentes)

Volatilidad de configurar el servidor

Tipo de datos a respaldar (p. ej., sistema, aplicación, registro o datos de usuario)

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

6-5
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

Esfuerzo requerido para la reconstrucción de datos sin respaldo de datos

Otras funciones de copia de seguridad o redundancia de datos del servidor (p. ej., matriz redundante de discos económicos
[RAID]).

Para servidores con datos altamente dinámicos, las copias de seguridad estándar pueden ser insuficientes para garantizar la
disponibilidad de los datos del servidor. Algunos servicios tienen datos modificados de forma continua, y una falla del servidor que
requiera la restauración de una copia de seguridad provocaría la pérdida de todos los cambios de datos realizados desde la copia
de seguridad anterior. Algunos servidores ofrecen servicios de replicación que permiten que los cambios de datos de un servidor se
dupliquen en otro servidor, ya sea para cambios individuales o pequeños lotes de cambios. La replicación supone una carga adicional
para los servidores y las redes, por lo que las organizaciones deben sopesar los costos de la replicación frente a los costos de la
pérdida de disponibilidad en caso de que ocurra una falla en el servidor. La replicación no pretende reemplazar las copias de
seguridad estándar, solo para proporcionar la capacidad de duplicar cambios recientes en los datos.

6.2.3 Mantener un servidor de prueba

La mayoría de las organizaciones probablemente deseen mantener un servidor de prueba o desarrollo para sus servidores más
importantes, como mínimo.39 Idealmente, este servidor debería tener hardware y software idénticos al servidor de producción o en
vivo y estar ubicado en un segmento de red interna (intranet) donde pueda estar completamente protegido por las defensas de la
red perimetral de la organización. Si bien el costo de mantener un servidor adicional no es insignificante, tener un servidor de
prueba ofrece numerosas ventajas:

Proporciona una plataforma para probar nuevos parches y paquetes de servicio antes de la aplicación en la producción.
servidor.

Proporciona una plataforma de desarrollo para que el administrador del servidor desarrolle y pruebe nuevos contenidos y
aplicaciones.

Proporciona una plataforma para probar los ajustes de configuración antes de aplicarlos a los servidores 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).

6.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.
Las organizaciones deben crear y documentar las políticas y procedimientos requeridos para responder a intrusiones
exitosas.40 Los procedimientos de respuesta deben describir las acciones que se requieren para responder a un compromiso exitoso
del servidor y la 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, el

39
Las organizaciones más grandes a veces tienen varios servidores y entornos de prueba y desarrollo para sus servidores y sistemas más críticos.
Por ejemplo, podría haber un servidor para pruebas de desarrolladores, otro servidor para pruebas de garantía de calidad y uno o más servidores
accesibles externamente para pruebas de socios comerciales.
40
Para obtener más información sobre esta área, consulte NIST SP 800-61 Revisión 1, 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.
(http://csrc.nist.gov/publications/PubsSPs.html).

6-6
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

La organización puede desear asegurarse de que parte de su personal tenga conocimientos en los campos de informática y análisis forense
de redes.41

Un administrador del servidor 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.42

Consultar con prontitud, según corresponda, con la gerencia, el asesor legal y las fuerzas del orden.

Investigue hosts similares43 para determinar si el atacante también ha comprometido otros sistemas.

Analice la intrusión, incluidos:

– El estado actual del servidor, empezando por los datos más efímeros (p. ej., red actual
conexiones, volcado de memoria, marcas de tiempo de archivos, usuarios registrados)

– Modificaciones realizadas en el software y configuración del servidor

– Modificaciones realizadas en los datos

– Herramientas o datos dejados por el atacante

– Archivos de registro del sistema, detección de intrusos y cortafuegos.

Restaure el servidor antes de volver a implementarlo.

– Instale una versión limpia del sistema operativo, las aplicaciones, los parches necesarios y el contenido del servidor; o restaurar el
servidor 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 servidor).

– Deshabilitar servicios innecesarios.

– Aplicar todos los parches.

– Cambie todas las contraseñas (incluso en hosts no comprometidos, si se cree que el servidor comprometido ha visto sus contraseñas, o
si se usan las mismas contraseñas en otros hosts).

41
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/PubsSPs.html).
42
El aislamiento del servidor 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 servidor sería reconfigurar el conmutador o enrutador ascendente más cercano.
43
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.

6-7
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

– Reconfigurar los elementos de seguridad de la red (p. ej., firewall, enrutador, IDPS) para brindar
protección y notificación adicionales.

Pruebe el servidor para garantizar la seguridad.

Vuelva a conectar el servidor a la red.

Supervise el servidor y la red en busca de señales de que el atacante está intentando acceder de nuevo al servidor
o la red.

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 servidor 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,
exfiltración de datos)

Método utilizado para el compromiso del servidor

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 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 acerca de las acciones del atacante y/o en los que el atacante obtiene acceso de alto nivel,
se recomienda que el sistema operativo, el software del servidor y otras aplicaciones se reinstalen desde el medio de distribución
original del fabricante y que el servidor los datos se restaurarán solo a partir de una buena copia de seguridad conocida.

Si se emprenden acciones legales, los administradores del servidor 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.

6.4 Servidores de pruebas de seguridad

Las pruebas periódicas de seguridad de los servidores son críticas. 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 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 a identificar vulnerabilidades y verificar si las medidas de
seguridad existentes son efectivas. También se utilizan pruebas de penetración, pero

6-8
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

se usa con menos frecuencia y, por lo general, solo como parte de una prueba de penetración general de la red de la organización.44

6.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, el software del servidor y otras aplicaciones de
software importantes que se ejecutan en los hosts y las 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 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). Además, es posible que los escáneres de vulnerabilidades no puedan reconocer que existen controles de compensación que mitigan
una vulnerabilidad detectada. Esto significa que una persona con experiencia en seguridad y administración de servidores 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 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). Debido al posible impacto negativo de la
exploración de vulnerabilidades, los administradores de servidores pueden desear explorar primero los servidores de prueba con nuevas
actualizaciones de la base de datos de vulnerabilidades para determinar su impacto en los servidores antes de explorar la producción.
servidores.

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
que operan servidores, sistemas operativos o aplicaciones codificadas a la medida menos populares.

Los escáneres de vulnerabilidad proporcionan las siguientes capacidades:

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

Identificar vulnerabilidades asociadas con sistemas operativos descubiertos, software de servidor y otras aplicaciones

Probar el cumplimiento de las políticas de uso/seguridad de la aplicación host.

44
Para obtener información sobre otras técnicas de prueba, consulte NIST SP 800-115 (Borrador), Guía técnica para pruebas de seguridad
de la información (http://csrc.nist.gov/publications/PubsSPs.html).

6-9
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

Las organizaciones deben realizar un análisis de vulnerabilidades para validar que los sistemas operativos y el software del servidor 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.

6.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”.45 El propósito de las pruebas de penetración es ejercitar las
protecciones del sistema (en particular, la respuesta humana a las indicaciones de utilizando herramientas y técnicas comunes desarrolladas
por los atacantes. Esta prueba es muy recomendable para servidores 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:46

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

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.

45
Definición del Comité de Sistemas de Seguridad Nacional, Glosario de Garantía Nacional de la Información (IA), Instrucción CNSS
No. 4009, junio de 2006 Derivado de John Wack et al., NIST SP 800-42, Directriz sobre pruebas de seguridad de red, febrero de
46
2002, http:/ /csrc.nist.gov/publications/PubsSPs.html

6-10
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

6.5 Administración remota de un servidor

La administración remota de un servidor debe permitirse solo después de una cuidadosa consideración de los riesgos. El riesgo
de habilitar la administración remota varía considerablemente según la ubicación del servidor en la red. Para un servidor que está
ubicado detrás de un firewall, la administración remota se puede implementar de manera relativamente segura desde la red interna,
pero no sin riesgo adicional. Por lo general, no se debe permitir la administración remota 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 un servidor de forma remota, seguir estos pasos debería garantizar
que la administración remota 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 el servidor de forma remota.

– Restringir por usuarios autorizados

– Restringir por dirección IP (no nombre de host)

– Restringir a hosts en la red interna o aquellos que usan el control remoto empresarial de la organización
solución de acceso.

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 (p. ej., intentar minimizar los derechos de acceso
para las cuentas de 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.

Utilice protocolos de administración remota que admitan la autenticación del servidor para evitar ataques de intermediarios.

Cambie las cuentas o contraseñas predeterminadas para la aplicación o utilidad de administración remota.

6-11
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

Apéndice A—Glosario

Los términos seleccionados utilizados en la publicación se definen a continuación.

Disponibilidad: Garantizar que los usuarios autorizados puedan acceder a la información.

Confidencialidad: Proteger la información para que no sea accedida por personas no autorizadas.

Endurecimiento: configurar el sistema operativo y las aplicaciones de un host para reducir las debilidades de seguridad
del host.

Integridad: garantizar la autenticidad de la información: que la información no se altere y que la fuente de la información sea
genuina.

Mínimo Privilegio: Ofrecer solo la funcionalidad requerida a cada usuario autorizado, para que nadie pueda utilizar funciones
que no son necesarias.

Control de gestión: un control de seguridad que se centra en la gestión de un sistema o la gestión del riesgo de un
sistema.

Administrador de red: una persona responsable del diseño, la implementación y el mantenimiento generales de una red.

Control operativo: un control de seguridad que es implementado y ejecutado principalmente por personas, en lugar de sistemas.

Parche: una actualización de un sistema operativo, aplicación u otro software emitido específicamente para corregir problemas
particulares con el software.

Evaluación de Riesgos: El proceso de analizar e interpretar el riesgo.

Gestión de riesgos: El proceso de selección e implementación de controles para reducir el riesgo a un nivel aceptable
para la organización.

Administrador de Seguridad: Persona dedicada a realizar funciones de seguridad de la información para servidores y otros
hosts, así como redes.

Control de Seguridad: Una medida de protección para un sistema.

Servidor: un host que proporciona uno o más servicios para otros hosts a través de una red como función principal.

Administrador del servidor: un arquitecto del sistema responsable del diseño, la implementación y el mantenimiento
generales de un servidor.

Software de servidor: software que se ejecuta en un servidor para proporcionar uno o más servicios.

Servicio: en el contexto de un servidor, una función que un servidor proporciona para que la utilicen otros hosts.

Control Técnico: Un control de seguridad automatizado empleado por el sistema.

Actualización: Una nueva versión de un sistema operativo, aplicación u otro software.

A-1
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

Apéndice B—Siglas y abreviaturas

Los acrónimos y abreviaturas utilizados en esta guía se definen a continuación.

3DES Estándar de cifrado de datos triple

AES Estándar de cifrado avanzado

QUE Autoridad certificada

CGI Interfaz de Entrada Común
director de información Director de información
CMVP Programa de validación de módulos criptográficos
UPC Unidad Central de procesamiento

DNS sistema de nombres de dominio

Departamento de Defensa
Departamento de Defensa
De Negación de servicio

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
FTP Protocolo de transferencia de archivos

HTTP Protocolo de Transferencia de Hipertexto

HTTPS Protocolo de transferencia de hipertexto seguro

IDPS Sistema de Detección y Prevención de Intrusos

IETF Grupo de Trabajo de Ingeniería de Internet
IMAP Protocolo de acceso a mensajes de Internet
IP protocolo de Internet
IPsec Seguridad del protocolo de Internet
IPv4 Protocolo de Internet versión 4
IPv6 Protocolo de Internet versión 6
ISP Proveedor de servicios de Internet
ESO Oficial de seguridad de los sistemas 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

LDAP Protocolo ligero de acceso a directorios

PNC Programa Nacional de Listas de Verificación

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
NTP Protocolo de tiempo de red
NVD Base de datos de vulnerabilidad nacional

ODBC Conectividad de base de datos abierta

OGP Oficina de Gerencia y Presupuesto

B-1
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

TÚ Sistema operativo

PKI Infraestructura de Clave Pública

REDADA Conjunto redundante de discos económicos

RFC Solicitud de comentarios

BEBER Algoritmo hash seguro

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
SP Publicación Especial
SSH Cubierta segura
SSL Capa de sockets seguros

TCP Protocolo de Control de Transmisión

TLS Transport Layer Security

URL Localizador Uniforme de Recursos

VLAN Red de área local virtual

vpn Red privada virtual

B-2
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

Apéndice C—Recursos

Las listas a continuación brindan ejemplos de recursos que pueden ser útiles para comprender la seguridad general
del servidor.

Sitios de recursos del NIST

Nombre del sitio URL

Programa de validación de módulos criptográficos (CMVP) http://csrc.nist.gov/groups/STM/cmvp/index.html

Programa Nacional de Listas de Verificación (NCP) http://checklists.nist.gov/

Base de datos de vulnerabilidad nacional (NVD) http://nvd.nist.gov/

Documentos NIST específicos de seguridad del servidor

Titulo del documento URL

SP 800-44 Versión 2, Directrices sobre protección pública http://csrc.nist.gov/publications/nistpubs/800-44-

Servidores web ver2/SP800-44v2.pdf

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

Seguridad versión 2/SP800-45v2.pdf http://

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

Guía de implementación 81.pdf

Documentos generales de seguridad del NIST

Titulo del documento URL

FIPS 140-2, Requisitos de seguridad para cifrado http://csrc.nist.gov/publications/fips/fips140-

Módulos 2/fips1402.pdf

FIPS 140-3 (Borrador), Requisitos de seguridad para http://csrc.nist.gov/publications/PubsFIPS.html

Módulos criptográficos

FIPS 180-2, estándar hash seguro (SHS) http://csrc.nist.gov/publications/fips/fips180-2/fips180-

2withchangenotice.pdf http://

FIPS 180-3 (borrador), estándar hash seguro (SHS) csrc.nist.gov/publications/PubsFIPS.html http://csrc.nist.gov/

FIPS 199, Normas para la categorización de seguridad de publications/fips/fips199/FIPS-PUB 199-final.pdf http://csrc.nist. gov/
Información Federal y Sistemas de Información publications/nistpubs/800-14/800-

SP 800-14, Principios y prácticas generalmente aceptados para asegurar

los sistemas de tecnología de la información 14.pdf

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

SP 800-23, Directrices para organizaciones federales sobre http://csrc.nist.gov/publications/nistpubs/800-23/sp800-

Garantía de Seguridad y Adquisición/ Uso de 23.pdf
Productos probados/ evaluados

SP 800-27 Revisión A, Principios de ingeniería para http://csrc.nist.gov/publications/nistpubs/800-

Seguridad de la tecnología de la información 27A/SP800-27-RevA.pdf http://

SP 800-30, Guía de gestión de riesgos para la información csrc.nist.gov/publications/nistpubs/800-30/sp800-

Sistemas Tecnológicos 30.pdf

SP 800-32, Introducción a la tecnología de clave pública y http://csrc.nist.gov/publications/nistpubs/800-32/sp800-

C-1
Machine Translated by Google

GUÍA DE SEGURIDAD GENERAL DEL SERVIDOR

Titulo del documento URL

la Infraestructura Federal PKI 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.0, Creación de un programa de http://csrc.nist.gov/publications/nistpubs/800-40-

gestión de parches y vulnerabilidades SP 800-41 Revisión Ver2/SP800-40v2.pdf http://

1 (borrador), Directrices sobre cortafuegos y política de cortafuegos csrc.nist.gov/publications/PubsSPs.html

SP 800-52, Directrices para la selección y el uso de implementaciones

de seguridad de la capa de transporte (TLS) SP 800-53 Revisión 2, http://csrc.nist.gov/publications/nistpubs/800-52/SP800-

Controles de seguridad recomendados para sistemas de información 52.pdf

federales http://csrc.nist.gov/publications/nistpubs/800-53-
Rev2/sp800-53-rev2-final.pdf

SP 800-55 Revisión 1, Guía de medición del rendimiento para la seguridad http://csrc.nist.gov/publications/nistpubs/800-55-

de la información Rev1/SP800-55-rev1.pdf

SP 800-60 Revisión 1, Volumen 1 (Borrador), Guía para http://csrc.nist.gov/publications/PubsSPs.html

Asignación de tipos de información y sistemas de información a
categorías de seguridad

SP 800-61 Revisión 1, Incidente de seguridad informática http://csrc.nist.gov/publications/nistpubs/800-61-

Guía de manipulación rev1/SP800-61rev1.pdf

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

63V1_0_2.pdf

SP 800-63-1 (Borrador), Pauta de autenticación electrónica http://csrc.nist.gov/publications/PubsSPs.html

SP 800-70, Programa de listas de verificación de configuración de seguridad http://csrc.nist.gov/checklists/download_sp800-70.html

para productos de TI: orientación para usuarios de listas de verificación y
Desarrolladores

SP 800-77, Guía de VPN IPsec http://csrc.nist.gov/publications/nistpubs/800-77/sp800-

77.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-88, Directrices para la desinfección de medios http://csrc.nist.gov/publications/nistpubs/800-

88/NISTSP800-88_rev1.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-100, Manual de seguridad de la información: una guía para http://csrc.nist.gov/publications/nistpubs/800-

Gerentes 100/SP800-100-Mar07-2007.pdf http://

SP 800-113, Guía de VPN SSL csrc.nist.gov/publications/nistpubs/800-

113/SP800-113.pdf

SP 800-115 (borrador), Guía técnica de información http://csrc.nist.gov/publications/PubsSPs.html

Pruebas de seguridad

C-2