rfc 2196 - udecar-sc/arq-m-2001-1/brevis3.doc · web viewlos servicios tienden a viajar como ondas...

PROGRAMA MAGISTER EN CIENCIAS DE COMPUTACION

TAREA 3

SEGURIDAD EN SITIOS

Asignatura: Organización y Arquitectura de Sistemas de Computación

Alumno: Lautaro Brevis A.

JUNIO DE 2001

Seguridad en sitios Página 1 de 48

INDICEINDICE

TITULO PAGINAINTRODUCCIONINTRODUCCION 5GLOSARIOGLOSARIO 61.- APROXIMACION INICIAL1.- APROXIMACION INICIAL 7

1.1.- Evaluación de riesgos 71.2.- Identificación de los bienes 81.3.- Identificación de las amenazas 8

2.- POLÍTICAS DE SEGURIDAD2.- POLÍTICAS DE SEGURIDAD 92.1.- Qué es una política de seguridad y para qué tener una 92.1.1.- Definición de una Política de Seguridad 102.1.2.- Propósito de una Política de Seguridad 102.1.3.- Quiénes deberían estar involucrados en la creación de una política

10

2.2.- Características de una buena política de seguridad 112.3 Manteniendo la política flexible 12

3.- ARQUITECTURA DE SEGURIDAD3.- ARQUITECTURA DE SEGURIDAD 133.1.- Objetivos 13

3.1.1.- Planes de seguridad completamente definidos 133.1.2.- Separación de servicios 143.1.3.- Denegar todo / Permitir todo 143.1.4.- Identificar las reales necesidades de los servicios

15

3.2.- Redes y configuración de servicios 163.2.1.- Protegiendo la infraestructura 163.2.2.- Protegiendo la red 163.2.3.- Protegiendo los servicios 17

3.2.3.1.- Servidores de Nombres (DNS y NIS (+)) 193.2.3.2.- Servidores de Passwords/Keys (NIS (+) y KDC)

19

3.2.3.3.- Servidores de Autenticación/Proxy (SOCKS, FWTK)

20

3.2.3.4.- Correo electrónico 213.2.3.5.- World Wide Web (WWW) 213.2.3.6.- Transferencia de archivos (FTP, TFTP) 213.2.3.7.- NFS 22

3.2.4.- Protegiendo la protección 223.3.- Firewalls 23

4.- PROCEDIMIENTOS Y SERVICIOS DE SEGURIDAD4.- PROCEDIMIENTOS Y SERVICIOS DE SEGURIDAD 264.1.- Autenticación 26

4.1.1.- Passwords one-time 26


4.1.2.- Kerberos 274.1.3.- Elección y protección de tokens secretos y PIN’s 274.1.4.- Aseguramiento de Password 28

4.2- Confidencialidad 294.3.- Integridad 294.4- Autorización 314.5.- Acceso 314.5.1.- Acceso físico 314.5.2.- Conecciones de red departamentales 324.5.3.- Otras tecnologías de redes 324.5.4.- Modems 33

4.5.4.1.- Las lineas de modem deben ser administradas

33

4.5.4.2.- El discado de usuarios debe ser autenticado

33

4.5.4.3.- Capacidad de call-back 334.5.4.4.- Todos los logins deben ser loggeados 344.5.4.5.- Elegir la presentación de entrada cuidadosamente

34

4.5.4.6.- Autenticación dial-out 344.5.4.7 Asegurarse que el modem sea a "pueba de balas", tanto como sea posible

35

4.6.- Auditoría 354.6.1.- ¿Qué recolectar? 354.6.2.- Procesos de recolección 364.6.3.- Carga de la recolección 364.6.4.- Manejo y preservación de datos auditados 374.6.5.- Consideraciones legales 37

4.7.- Backups seguros 375.- MANEJO DE INCIDENTES DE SEGURIDAD5.- MANEJO DE INCIDENTES DE SEGURIDAD 37

5.1.- Preparando y planificando el manejo de incidentes 385.2.- Notificación y puntos de contacto 39

5.2.1.- Administradores y personal local 405.2.2.- Esfuerzo legal y agencias de investigación 405.2.3.- Equipo de manejo de incidentes de seguridad en computación

41

5.2.4.- Sitios afectados e involucrados 415.2.5.- Comunicaciones internas 415.2.6.- Relaciones públicas – publicación en la prensa 42

5.3.- Identificando un incidente 425.3.1.- ¿Es real? 425.3.2.- Tipos y alcances de los incidentes 435.3.3.- Evaluando la magnitud del daño 43


5.4.- Manejando un incidente 445.4.1.- Tipos de notificación e intercambio de información

44

5.4.2.- Protegiendo la evidencia y log de actividades 445.4.3.- Contención 455.4.4.- Erradicación 455.4.5.- Recuperación 465.4.5.- Pasar a la siguiente etapa 46

5.5.- Consecuencias de un incidente 465.6.- Responsabilidades 47

5.6.1.- No cruzar la linea 475.6.2.- Buen ciudadano de Internet 475.6.3.- Respuesta administrativa a los incidentes 47

6.- CONTINUACIÓN DE LAS ACTIVIDADES6.- CONTINUACIÓN DE LAS ACTIVIDADES 487.- CONCLUSIONES7.- CONCLUSIONES 48


INTRODUCCIONINTRODUCCION

Este documento está referido al RFC 2196, el cual es una guía para el desarrollo de políticas de seguridad computacionales y procedimientos para sitios que tienen sistemas en Internet. Se enumeran los factores que se deben considerar para establecer dichas políticas.El contenido incluye políticas, tópicos de seguridad en redes y sistemas y respuesta a los incidentes de seguridad.

Está destinado principalmente a sitios que trabajan en el ambiente Internet. Pero también a aquellos sitios que permiten comunicarse con otros sitios. Y en forma general también puede ser utilizado en sistemas aislados.


GLOSARIO GLOSARIO

ADMINISTRADOR Se refiere a aquellas personas que son responsables por la operación diaria del sistema y de los recursos de la red

ADMINISTRADOR DE SEGURIDAD

Se refiere a aquellas personas que son responsables por la seguridad de la información. En algunos lugares, esta función será realizada en forma conjunto por el "Administrador" definido anteriormente, mientras que en otros será un rol separado

INTERNET Un conjunto de miles de redes, conectadas por un conjunto común de protocolos técnicos, los cuales hacen posible que usuarios de distintas redes se puedan comunicar o usar servicios localizados en otras redes

SITIO Cualquier organización donde los computadores personales o recursos están relacionados a través de una red. Estos recursos pueden incluir:

Computadores hosts que el usuario usa Routers Servidor de terminales PC's Otros dispositivos que tengan acceso a la Internet

Un sitio puede ser un usuario final de servicios de Internet o un proveedor de servicios de nivel intermedio en la red.Se asume que el sitio tiene la capacidad de establecer políticas y procedimientos por sí mismo, con la concurrencia y soporte de aquellos que son dueños de los recursos. Se asume que los sitios que son parte de grandes organizaciones, saben cuando necesitan consultar, colaborar o requerir recomendaciones

TOMADOR DE DECISIONES

Se refiere a aquellas personas de un lugar, que establecen o aprueban políticas. Ellas son a menudo las personas propietarias de los recursos


1.- APROXIMACION INICIAL1.- APROXIMACION INICIAL

Una pauta generalmente aceptada para el desarrollo de planes de seguridad para un sitio, es la propuesta por Fites y contiene los siguientes pasos:a) Identificar qué objeto se está intentando protegerb) Identificar de qué se está tratando de proteger al objetoc) Determinar cuáles son las probables amenazasd) Implementar medidas que protegerán los bienes, medidas en costo/eficienciae) Revisar el proceso continuamente y efectuar las correcciones cada vez que se

detecte un problema

Si bien este documento se centrará en el item (d), los restantes no deben ser obviados, en aras de obtener un efectivo plan de protección para el sitio. Una vieja regla en seguridad es que el costo de protegerse contra alguna amenaza, debe ser menor que el costo de recuperarse, si la amenaza ataca.El costo en este contexto debe estar referido a pérdidas en moneda real, reputación, fiabilidad y otros menos obvios. Sin un conocimiento de qué es lo que se quiere proteger y contra qué, es muy difícil cumplir esta regla.

1.1.- Evaluación de riesgos

Una de las razones más importantes para crear una política de seguridad es que el gasto efectuado en ello produce beneficios en el costo de no tenerla. Aunque esto parezca obvio, es posible confundirse acerca de dónde se debe enfocar el esfuerzo. Como ejemplo, existe gran cantidad de publicidad acerca de los intrusos en computación, pero los estudios de seguridad computacional muestran que en la mayoría de las organizaciones, la pérdida de confianza en las personas es mucho mayor en la actualidad.

El análisis de riesgo involucra la determinación de qué es lo que se necesita proteger, de qué protegerlo y cómo protegerlo. Este es el proceso de determinar todos los riesgos, rankeándolos por nivel de gravedad. Esto involucra tomar decisiones desde el punto de vista costo/beneficio, en relación con lo que se quiere proteger. Como se mencionó anteriormente, no se debe gastar en proteger algo, más allá de su valor.

En relación al análisis de riesgo, existen dos elementos que se tratarán:

a) Identificar los bienesb) Identificar las amenazas


Para cada bien, los objetivos básicos de seguridad son: disponibilidad, confiabilidad e integridad. Para ello, cada amenaza debe ser analizada en función de su efecto en estos objetivos.

1.2.- Identificación de los bienes

El primer paso en el análisis de riesgo es identificar todo aquello que debe ser protegido. Algunos son obvios, como el valor de la propiedad de la información, la propiedad intelectual y los elementos de hardware, pero algunos no son considerados, como las personas que operan los sistemas. El punto esencial es listar todas aquellas cosas que podrían ser afectadas por un problema de seguridad.

Una lista de categorías es sugerida por Pfleeger, la cual considera:

a) Hardware : Cpu’s, teclados, terminales, workstations, computadores personales, impresoras, unidades de discos, lineas de comunicación, servidores y equipos de comunicaciones.

b) Software : Programas fuente, programas objeto, utilitarios, programas de diagnóstico, sistemas operativos, programas de comunicaciones.

c) Datos : En ejecución, almacenados en linea, archivados off-line, backups, registros de auditorías, bases de datos, en tránsito sobre medios de comunicación.

d) Personas : Usuarios, administradores, mantenedores de hardware.e) Documentación : De programas, hardware, sistemas, procedimientos administrativos

locales.f) Suministros : Papel, formularios, cintas, medios magnéticos

1.3.- Identificación de las amenazas

Una vez que se identifican los elementos que requieren protección, es preciso identificar las amenazas hacia ellos. En seguida se analizan las amenazas, para determinar los potenciales daños que existen. Esto ayuda a identificar de qué amenazas se está intentando proteger los elementos. Las siguientes son amenazas clásicas que deben ser consideradas. Dependiendo de la situación, habrá más amenazas específicas que identificar y localizar:

Acceso no autorizado a recursos y/o información Revelación involuntaria o no autorizada de información Denegación de servicio


2.- POLÍTICAS DE SEGURIDAD2.- POLÍTICAS DE SEGURIDAD

2.1.- Qué es una política de seguridad y para qué tener una

La toma de decisiones referidas a seguridad que se realiza (o no) como administrador, determina principalmente cuán segura o insegura es la red o cuánta funcionalidad ofrece y cuán fácil es de usar. Sin embargo, no se pueden tomar buenas decisiones en seguridad sin determinar cuáles son los objetivos de ella. Este es el primer paso, antes de hacer uso de las herramientas de seguridad, ya que se debe determinar para qué chequear y qué restricciones imponer.

Por ejemplo, los objetivos pueden ser muy diferentes a los objetivos de un vendedor de productos. Los vendedores intentan configurar y operar sus productos de la forma más simple posible, lo cual implica que las configuraciones serán lo más abiertas o inseguras posible. Mientras esto facilita la instalación de nuevos productos, también permite accesar los sistemas, los cuales se encuentran abiertos a cualquier usuario.

Los objetivos serán determinados por la siguiente combinación de factores:

Servicios ofrecidos v/s seguridad provista : Cada servicio ofrecido a los usuarios, importa su propio riesgo de seguridad. Para algunos servicios, el riesgo pesa más que el beneficio del servicio y el administrador puede determinar la eliminación de dicho servicio, más que intentar asegurarlo.

Facilidad de uso v/s seguridad : Los sistemas de más fácil uso, deben permitir el acceso a cualquier usuario y no requerir de contraseñas, es decir, no habría seguridad. El requerimiento de contraseñas hace al sistema un poco menos conveniente, pero más seguro. El requerimiento de dispositivos generadores de passwords one-time, hace al sistema aún más difícil de usar, pero mucho más seguro.

Costo de seguridad v/s riesgo de pérdida : Existen muchos costos de seguridad distintos: monetario (es decir, el costo de adquirir hardware y software de seguridad tales como firewall y generadores de passwords one-time), perfomance (el encriptado y desencriptado toma tiempo) y facilidad de uso (como se mencionó anteriormente).

Existen también muchos niveles de riesgo: pérdida de privacidad (es decir, el acceso a lectura de información por individuos no autorizados), pérdida de datos (es decir, corrupción o borrado de la información) y la pérdida del servicio (es decir, el llenado de espacio en disco, uso de recursos computacionales y denegación de acceso a la red). Cada tipo de costo debe ser dimensionado con respecto a cada tipo de pérdida.

Los objetivos deben ser comunicados a todos los usuarios, staff de operación y administradores, a través de un conjunto de reglas de seguridad llamadas “Políticas


de Seguridad”. Se usa este término en lugar de “Políticas de Seguridad Computacional”, ya que el alcance incluye todos los tipos de tecnología de información y la información almacenada y manipulada por la tecnología.

2.1.1.- Definición de una Política de Seguridad

Una Política de Seguridad es una expresión formal de reglas que deben cumplir aquellas personas que tienen acceso a información y tecnologías de una organización.

2.1.2.- Propósito de una Política de Seguridad

El principal objetivo de una Política de Seguridad es informar a los usuarios, staffs y administradores de los requisitos obligatorios a cumplir, para proteger los bienes de información y tecnología. La política debe especificar los mecanismos a través de los cuales se realiza. Otro propósito es proveer de una linea base a través de la cual adquirir, configurar y auditar sistemas computacionales y redes, en conformidad con la política. Por lo tanto el intento de usar un conjunto de herramientas de seguridad en ausencia de a lo menos una política de seguridad implícita, es un absurdo.

Una Política de Uso Apropiado (AUP), puede también ser parte de una política de seguridad. Esta debería explicar lo que los usuarios deben y no deben hacer con los componentes del sistema, incluyendo el tipo de tráfico permitido en la red. La AUP debe ser lo más explícita posible, para evitar ambigüedades o malos entendidos. Por ejemplo, una AUP debe listar cualquier grupo USENET prohibido. (Nota: una Política de Uso Apropiado se refiere como una Políttica de Uso Aceptable para algunos sitios).

2.1.3.- Quiénes deberían estar involucrados en la creación de una política

Para que una política de seguridad sea apropiada y efectiva, necesita tener la aceptación y el respaldo de todos los niveles de la organización. Es especialmente importante que la dirección de la organización respalde totalmente el proceso de la política de seguridad. La siguiente es una lista de individuos que deberían estar involucrados en la creación y revisión de documentos de políticas de seguridad: Administrador de seguridad Staff técnico de tecnologías de información Administradores de grandes grupos de usuarios dentro de la organización (por

ejemplo, división de negocios, departamento de ciencias de computación de una Universidad, etc.)

Team de asistencia a incidentes de seguridad Representantes de los grupos de usuarios afectados por las políticas de seguridad Administrador responsable Consejo legal (si es apropiado)Seguridad en sitios Página 10 de 48

La lista anterior es representativa en muchas organizaciones, pero no es necesariamente completa. La idea es contar con representantes claves de la organización, administradores del presupuesto y de políticas de autoridad, staff técnico que sabe qué puede y no puede ser soportado y el consejo legal, que conoce las implicancias legales de la elección de las políticas. En algunas organizaciones puede ser necesario incluir personal de auditoría. El involucrar este grupo es importante si es que se alcanza la más amplia aceptación posible de las políticas.

2.2.- Características de una buena política de seguridad

Esta debe ser implementable a través de procedimientos de administración de sistemas, publicando pautas directivas aceptables u otros métodos apropiados.

Esta debe ser exigible con herramientas de seguridad si es preciso, y con sanciones, donde la prevención actual no es técnicamente factible

Debe definir claramente las areas de responsabilidad de los usuarios, administradores y la dirección

Los componentes de una buena política de seguridad incluyen:

Pautas para adquisición de tecnología computacional con requerimientos específicos o características de seguridad deseadas. Estas deberían complementar pautas y políticas de adquisición existentes.

Una política de privacidad que define expectativas razonables de privacidad en temas tales como monitoreo correo electrónico, registros en teclado y acceso a archivos de usuarios.

Una política de acceso que defina privilegios y derechos de acceso, para proteger los bienes de pérdida o divulgación, especificando pautas de uso aceptables por los usuarios, staff de operaciones y administradores. También debería proveer de pautas para conexiones externas, comunicación de datos, conexión de dispositivos a redes e incorporación de nuevo software al sistema. También se debería especificar cualquier mensaje de notificación requerido (es decir, los mensajes de conexión deberían proveer advertencias sobre uso autorizado y lineas de monitoreo y no sólo decir “Bienvenido”)

Una política de responsabilidad, que define las responsabilidades de los usuarios, staff de operaciones y administradores. Esta debería especificar una capacidad de auditoría y proveer pautas para el manejo de incidentes (es decir, qué hacer y con quién contactarse si un posible intruso es detectado)

Una política de autenticación que establece confianza a través de una efectiva política de contraseñas y establece pautas para autenticación en forma remota y el uso de dispositivos de autenticación (es decir, passwords one-time y dispositivos que las generan)

Una declaración de disponibilidad, que establezca expectativas de los usuarios acerca de la disponibilidad de los recursos. Esta debería localizar redundancias y


recuperar elementos, tan bien como especificar las horas de operación y los períodos de mantención. También debería incluir información de contactos para el sistema de reportes y fallas en la red.

Un sistema de tecnología de información y una política de mantención de redes que describan cómo el personal de mantención, tanto interno como externo, puede manejar y usar la tecnología. Un tópico importante que se indica aquí es si la mantención remota es permitida y cómo se controla dicho acceso. Otra area que se considera aquí es el outsourcing y cómo se maneja.

Una política de reporte de violaciones que indique qué tipo de violaciones (es decir, privacidad y seguridad, tanto interna como externa) deben ser reportadas y de quén son esos reportes. Una atmósfera no amenazante y la posibilidad de reportes anónimos, resultarán en una gran probabilidad que una violación será reportada si es que se detecta.

Información de soporte que proveen los usuarios, staff y administradores, con información de contacto para cada tipo de política de violación; pautas acerca de cómo manejar consultas acerca de incidentes de seguridad o información que pueda ser considerada confidencial y propietaria; referencias cruzadas a procedimientos de seguridad e información relacionada, tales como políticas de la compañía y leyes y regulaciones gubernamentales.

Podría haber requerimientos regulatorios que afecten algunos aspectos de la política de seguridad (es decir, monitoreo en linea). Los creadores de la política de seguridad deberían considerar la búsqueda de asistencia legal en la creación de la política. Como mínimo, la política debería ser revisada por un consejo legal.

Una vez que la política de seguridad ha sido establecida, debería ser claramente comunicada a los usuarios, staff y administradores. Habiendo todo el personal firmado una declaración que indique que han leído, comprendido y están de acuerdo en cumplir la política, es una parte importante del proceso. Finalmente, se requiere el seguimiento para verificar si soporta exitosamente las necesidades de seguridad.

2.3 Manteniendo la política flexible

Para que una política de seguridad sea viable en el largo plazo, se requiere una gran flexibilidad, basada en un concepto arquitectónico de la seguridad. Una política de seguridad debería ser independiente de situaciones específicas de software y hardware (como sistemas específicos que tienden a ser reemplazados durante la noche). Los mecanismos para actualizar las políticas, deben ser claramente explicados. Esto incluye los procesos, las personas involucradas y las personas que deben decidir los cambios.

También es importante reconocer que existen excepciones a cada regla. Cuando sea posible, la política debe explicar cuáles excepciones a la política general existen. Por ejemplo, bajo qué condiciones se permite al administrador del sistema ver los archivos Seguridad en sitios Página 12 de 48

de usuario. También puede haber algunos casos cuando múltiples usuarios tienen acceso al mismo UserId. Por ejemplo, en sistemas con un usuario raíz, los administradores de sistema pueden conocer las passwords y usar la raíz.

Otra consideración es la llamada "Garbage Truck Syndrome", la cual se refiere a qué debería ocurir en un sitio si, en forma repentina, una persona clave no se encuentra disponible. Mientras la mayor seguridad radica en la mínima diseminación de información, el riesgo de perder información crítica se incrementa cuando esa información no es compartida. Es importante determinar el adecuado balance para un sitio.

3.- ARQUITECTURA DE SEGURIDAD3.- ARQUITECTURA DE SEGURIDAD

3.1.- Objetivos

3.1.1.- Planes de seguridad completamente definidos

Todos los sitios deberían definir un plan de seguridad integral. Este plan debería ser de mayor nivel que las políticas discutidas con anterioridad y debería ser considerado como un marco de trabajo.

Es importante tener este marco de trabajo en su lugar, tal que las políticas individuales sean consistentes con la arquitectura de seguridad del sitio. Por ejemplo, tener una política fuerte con el acceso Internet y tener débiles restricciones en el uso del modem, es inconsistente con una filosofía fuerte de restricciones de seguridad para accesos externos

Un plan de seguridad debe definir: la lista de servicios de red que serán provistos, qué areas de la organización proveerán los servicios, quiénes tendrán acceso a aquellos servicios, cómo serán provistos los accesos, quién administrará aquellos servicios, etc.

El plan debe indicar también cómo se manejarán los incidentes. Es importante definir en cada sitio, las clases de incidentes y sus correspondientes resguardos. ¿Por ejemplo, los sitios con firewalls deben establecer un límite al número de intentos de violar el sistema, antes de gatillar una respuesta?. Los niveles de escalamiento deben ser definidos tanto para los ataques como para las respuestas. ¿Los sitios sin firewalls deben determinar si un único intento de conectar a un host constituye un incidente?. ¿Qué hay de una sistemática exploración del sistema?

Para sitios conectados a Internet, el magnificar en forma incontrolada los incidentes de seguridad referidos a Internet puede ocultar un (potencialmente) mayor problema de Seguridad en sitios Página 13 de 48

seguridad interna. Así mismo, algunas compañías que nunca han sido conectadas a Internet, pueden tener políticas internas bien definidas, pero fallan al adecuarlas a una política de conexión externa.

3.1.2.- Separación de servicios

Existen muchos servicios que un sitio puede querer ofrecer a sus usuarios, algunos de los cuales pueden ser externos. Existe una variedad de razones de seguridad para intentar aislar servicios dedicados sobre los computadores hosts. Existen también razones de perfomance en muchos casos, pero una discusión más detallada excede el alcance de este documento.

Los servicios que un sitio puede proveer, en muchos casos tendrán diferentes niveles de acceso y modelos de confianza. Los servicios que son escenciales a la seguridad o adecuada operación de un sitio, deberían ser mejores si residen en una máquina dedicada, con acceso muy limitado, más que en una máquina que provee servicios que son tradicionalmente menos seguros o requieren altos niveles de acceso por usuarios que pueden violar la seguridad.

Es importante distinguir entre hosts que operan dentro de diferentes modelos de confianza (por ejemplo, todos los hosts dentro de un firewall) y cualquier otro host en una red expuesta.

Algunos de los servicios que deberían ser examinados para una potencial separación, son indicados en la sección 3.2.3. Es importante recordar que la seguridad es tan fuerte como débil sea el enlace en la cadena. Varios de los más publicitados accesos de intrusos en años recientes han sido a través de la explotación de la vulnerabilidad en sistemas de correo electrónico. Los intrusos no intentaban robar el correo electrónico, sino que utilizaban la vulnerabilidad de ese servicio para obtener acceso a otros sistemas.

Si es posible, cada servicio debería correr en una máquina distinta, que esté sólo dedicada a proveer un servicio específico. Esto ayuda a aislar a los intrusos y a limitar los potenciales daños.

3.1.3.- Denegar todo / Permitir todo

Existen dos filosofías diametralmente opuestas, que pueden ser adoptadas para definir un plan de seguridad. Ambas alternativas son legítimas y la elección de ellas dependerá del sitio y sus necesidades de seguridad.

La primera opción es desconectar todos los servicios y habilitarlos caso a caso, en base a requerimientos. Esto puede ser efectuado en el host o el nivel de red apropiado. Seguridad en sitios Página 14 de 48

Este modelo que definiremos como "Denegar todo" es más seguro que el otro que se describirá más adelante. Se requiere más trabajo para implementar exitosamente una configuración "Denegar todo", tanto como una buena comprensión de los servicios. El permitir sólo conocer los servicios provistos proporciona un mejor análisis de un servicio/protocolo particular y el diseño de un mecanismo de seguridad ajustado al nivel de seguridad del sitio.

El otro modelo que se definirá como "Permitir todo" es mucho más fácil de implementar, pero es generalmente menos seguro que el modelo "Denegar todo". Simplemente activa todos los servicios, usualmente como defecto del nivel host y permite a todos los protocolos viajar a los límites de la red, usualmente el nivel de defecto del router. A medida que los problemas de seguridad comienzan a aparecer, ellos son restringidos en el host o el nivel de red.

Cada modelo puede ser aplicado a diferentes partes del sitio, dependiendo de los requerimientos de funcionalidad, administrativos, de control, políticas de seguridad etc. Por ejemplo, la política puede ser usar el modelo "Permitir todo", cuando se setean las workstations para uso general, pero adoptar "Denegar todo" cuando se establecen como servidores de información, como un hub email. Así mismo, en "Permitir todo" puede ser adoptada para el tráfico entre LAN's internas al sitio, pero una política "Denegar todo" puede ser usada entre el sitio y la Internet

Se debe ser cuidadoso para mezclar filosofías como en el ejemplo anterior. Muchos sitios adoptan la teoría de una cubierta dura y crujiente y un suave medio "Squishy". Ellos están gustosos de pagar el costo de seguridad para sus tráficos externos y requieren fuertes medidas de seguridad, pero no son capaces de proveer protecciones similares internamente. Estos delicados trabajos tan grandes como las defensas externas, nunca son violados y los usuarios pueden estar de acuerdo en esto. Una vez que la capa exterior (firewall) es violada, la destrucción interna de la red es simple.

3.1.4.- Identificar las reales necesidades de los servicios

Existe una gran variedad de servicios que pueden ser provistos en forma interna y sobre Internet. El manejo de la seguridad es en muchas formas la administración de accesos a servicios internos al sitio y administrar el cómo los usuarios internos accesan la información desde sitios remotos.

Los servicios tienden a viajar como ondas en la Internet. Con los años, muchos sitios han establecido servidores FTP anonimos, servidores gophers, servidores WAIS, servidores WWW, etc., a medida que se han ido popularizando, pero no es particularmente necesario en todos los sitios. Se debe evaluar todos los nuevos servicios que son establecidos, con escepticismo, para determinar si son necesarios o son sólo una moda pasajera en Internet.


Se debe tener en mente que la complejidad de la seguridad puede aumentar exponencialmente con el número de servicios provistos. El filtrado en routers requiere ser modificado para soportar nuevos protocolos. Algunos protocolos poseen dificultad inherente para filtrar en forma segura (por ejemplo RPC y servicios UDP), así como proporcionan mayor apertura a las redes internas. Los servicios provistos en la misma máquina pueden interactuar en forma catastrófica. Por ejemplo, el permitir FTP anonimos en la misma máquina del servidor WWW, puede permitir a un intruso ubicar un archivo en el area de FTP anónimo y provocar que el servidor HTTP lo ejecute.

3.2.- Redes y configuración de servicios

3.2.1.- Protegiendo la infraestructura

Muchos administradores de redes van rápidamente a proteger los hosts de sus redes. Pocos administradores hacen un esfuerzo por proteger las mismas redes. Hay algún fundamento en esto. Por ejemplo, es más fácil proteger un host que una red. También, los intrusos están posiblemente tras los datos de los hosts; el dañar la red no debería servir a sus propósitos. Esto indica que existen razones para proteger las redes. Por ejemplo, un intruso puede desviar el tráfico de una red hacia un host externo, para examinar los datos (es decir, buscar passwords). También, la infraestructura incluye algo más que las redes y los routers que las interconectan. La infraestructura incluye administración de redes (por ejemplo, SNMP), servicios (por ejemplo DNS, NFS, NTP, WWW) y seguridad (por ejemplo autenticación de usuarios y restricciones de acceso).

La infraestructura también necesita protección contra el error humano. Cuando un administrador desconfigura un host, ese host puede degradar su servicio. Esto sólo afecta a los usuarios que requieren ese host y (a menos que ese host sea un servidor principal), el número de usuarios afectados será limitado. Sin embargo, si un router es desconfigurado, todos los usuarios de la red serán afectados. Obviamente se trata de un número mucho mayor de usuarios.

3.2.2.- Protegiendo la red

Existen varios problemas a los cuales las redes son vulnerables. El problema clásico es un ataque de "denegación de servicio". En este caso, la red es llevada al estado en que no puede transportar datos a los usuarios. Existen dos formas comunes en que esto puede realizarse: atacando a los routers o inundando la red con tráfico extraño. El término router es usado como ejemplo una gran clase de componentes activos de interconexión de redes, lo que incluye firewalls, servidores proxy, etc.

Un ataque a un router está destinado a provocar la detención del transporte de paquetes o enviarlos en forma indebida. El caso anterior se puede deber a una desconfiguración, la inserción de actualización de ruteo falsa o un "ataque de Seguridad en sitios Página 16 de 48

inundación" (es decir, el router es bombardeado con paquetes no ruteados, causando una degradación en su perfomance). Un ataque de inundación en una red es similar al un ataque de inundación en un router, excepto que los paquetes de inundación son transmitidos. Un ataque de inundación ideal debería ser a través de la inserción de un único paquete, el cual explota algunos defectos conocidos en los nodos de la red y provoca que ellos retransmitan el paquete o generen paquetes de error, cada uno de los cuales es atrapado y replicado por otro host. Un paquete de ataque bien elegido puede generar una explosión exponencial de transmisiones.

Otro problema clásico es conocido como "spoofing". En este caso, actualizaciones de ruteo falsas son enviadas a uno o más routers, causando que ellos desruteen los paquetes. Esto difiere de un ataque por denegación de servicio sólo en el propósito existente en el ruteo falso. En la denegación de servicio, el objetivo es lograr que el router quede inutilizado; un estado que será rápidamente detectado por los usuarios de la red. En el "spoofing", la ruta falsa causará que los paquetes sean ruteados a un host, desde el cual un intruso puede monitorear los datos en los paquetes. Estos paquetes son entonces re-ruteados a su destino correcto. Sin embargo, el intruso podría haber ya alterado el contenido de los paquetes.

La solución a la mayor parte de estos problemas es proteger la actualización de ruteo de los paquetes enviados por los protocolos de ruteo en uso (por ejemplo RIP-2, OSPF). Existen tres niveles de protección: password con texto borrado, comprobación criptográfica y encriptación. Las passwords ofrecen una mínima protección contra los intrusos que no tienen acceso directo a la red física. Las passwords también ofrecen alguna protección contra routers desconfigurados (es decir, routers que fuera de su esquema intentan rutear paquetes). La ventaja de las passwords es que tienen muy bajo overhead, en ancho de banda y consumo de CPU. La comprobación protege contra la inserción de paquetes falsos, aún si los intrusos tienen acceso directo a la red física. Combinado con un número de secuencia u otro identificador único, una comprobación puede proteger también contra la repetición de un ataque, donde una antigua pero válida actualización de ruteo es retransmitida por un intruso o un router fallado. La mayor seguridad es provista por la encriptación completa o identificación única, de la actualización de ruteo. Esto previene de intrusos, determinando la topología de la red. La desventaja de la encriptación es el overhead involucrado en el procesamiento de actualizaciones.

RIP-2 y OSPF soportan passwords de texto borrado es sus especificaciones de diseño. Además, existen extensiones a cada protocolo base para soportar encriptación MD5.

Desgraciadamente no existe una adecuada protección contra un ataque por inundación o contra un host o router fallados, que se encuentren inundando la red. Sin embargo, este tipo de ataques se detecta rápidamente cuando ocurre y puede ser terminado en forma simple.


3.2.3.- Protegiendo los servicios

Existen muchos tipos de servicios y cada uno tiene sus propios requerimientos de seguridad. Esos requerimientos variarán de acuerdo al uso que se pretenda del servicio. Por ejemplo, un servicio que deba sólo ser usado en un sitio (por ejemplo NFS), puede requerir diferentes mecanismos de protección que un servicio provisto para uso externo. Puede ser suficiente proteger el servidor interno de accesos externos. Sin embargo, un servidor www, que provee una home page destinada a usuarios en cualquier lugar de la Internet, requiere protección propia del sistema. Esto es, el servidor de servicios de protocolo debe proveer seguridad, dondequiera sea requerida, para prevenir acceso no autorizado y modificación a la base de datos de la Web.

Los servicios internos (es decir, servicios que son usados por un usuario dentro de un sitio) y servicios externos (es decir, servicios disponibles en forma deliberada a usuarios fuera de un sitio), tendrán en general requerimientos de protección diferentes. Por consiguiente, es adecuado aislar los servicios internos en un conjunto de computadores host y los servicios externos en otro conjunto de computadores host. Esto es, servidores internos y externos no deberían ser localizados en forma conjunta en el mismo computador host. De hecho, muchos sitios van más lejos y tienen un conjunto de subredes (o aún más, diferentes redes), que son accesibles desde el exterior y otro conjunto que puede ser accesado solamente desde el interior del sitio. De hecho, normalmente existe un firewall que conecta esas particiones. Se debe tener la seguridad de que tales firewalls operen correctamente.

Existe un creciente interés en usar intranets para conectar diferentes partes de una organización (por ejemplo, divisiones de una compañía). Mientras en este documento se distingue entre externo e interno (público y privado), los sitios que usan intranets deberían considerar la necesidad de tres separaciones y tomar las acciones apropiadas al diseñar y ofrecer servicios. Un servicio ofrecido en una intranet no debería ser público o completamente privado como un servicio de una subunidad organizacional. Por esto, el servicio necesitaría su propio sistema de soporte, separado de los servicios y redes internas y externas.

Una forma de servicio externo merece una consideración especial y es el acceso anónimo o sin contraseña. Este puede ser FTP anónimo o login sin contraseña (no autenticado). Es muy importante asegurar que los servidores FTP anónimos y login sin contraseña sean cuidadosamente aislados desde cualquier host y sistemas de archivo que deban mantener usuarios externos. Otra area con especial atención debe ser el anónimo con pago y acceso de escritura. Un sitio puede ser legalmente responsable por el contenido de la información disponible al público, cuidando de monitorear que la información depositada por usuarios anónimos sea recomendable.

Ahora, debemos considerar algunos de los más populares servicios: servicio de nombre, servicio de password, servicio de autenticación/proxy, correo electrónico, Seguridad en sitios Página 18 de 48

www, transferencia de archivos y NFS. Ellos son los servicios más frecuentemente usados y por ende son los puntos más obvios de ataque. También, un ataque exitoso en uno de esos servicios puede producir un desastre fuera de toda proporción con los servicios básicos.

3.2.3.1.- Servidores de Nombres (DNS y NIS (+))

Internet usa el Sistema de Nombres de Dominio (DNS) para resolver direcciones para host y nombres de redes. El Servicio de Información de la Red (NIS) y NIS + no son usados en la generalidad de la Internet, pero están sujetos a los mismos riesgos que un servidor DNS. El nombre de una dirección es crítico para asegurar la operación de cualquier red. Un intruso que consiga controlar un servidor DNS, puede rerutear el tráfico, para alterar las protecciones de seguridad. Por ejemplo, el tráfico rutinario puede ser desviado a un sistema que es monitoreado; o los usuarios pueden ser llevados a develar secretos de autenticación. Una organización debería crear sitios protegidos y bien conocidos, para actuar como servidores de nombre secundarios y proteger así los DNS maestros de denegación de servicios de ataque, usando filtrado en routers.

Tradicionalmente, el DNS no ha tenido capacidades de seguridad. En particular, la información retornada desde un query podría no ser chequeada en cuanto a modificaciones o verificar que proviene del servidor de nombre en cuestión. Se ha trabajado en incorporar firmas digitales dentro del protocolo, las cuales cuando se despliegan permitirán verificar criptográficamente la integridad de la información.

3.2.3.2.- Servidores de Passwords/Keys (NIS (+) y KDC)

Los servidores de passwords y claves generalmente protegen su información vital (es decir, las passwords y claves) con algoritmos de encriptación. Sin embargo, aún una password encriptada one-time puede ser detectada por un diccionario de ataque (en el que las palabras comunes son encriptadas para ver si corresponden a la encriptación almacenada). Por consiguiente es necesario asegurar que esos servidores no son accesables por hosts que no planean usarlos para el servicio y aún aquellos hosts deberían sólo ser capaces de accesar el servicio (es decir, servicios generales tales como Telnet y FTP no deberían ser permitidos para nadie que no sean los administradores).

3.2.3.3.- Servidores de Autenticación/Proxy (SOCKS, FWTK)

Un servidor proxy proporciona un número de incremento de seguridad. Esto permite a los sitios concentrar servicios a través de un host específico, para permitir monitorear, ocultar la estructura interna, etc. Esta concentración de servicios es un atrayente Seguridad en sitios Página 19 de 48

objetivo para un potecial intruso. El tipo de protección requerida por un servidor proxy depende en gran medida del protocolo proxy en uso y los servicios proxieados. La regla general de limitar el acceso solamente a aquellos hosts que requieren los servicios y limitar el acceso por los hosts que proveen esos servicios, es un buen punto de partida.


3.2.3.4.- Correo electrónico

Los sistemas de correo electrónico (e-mail) han sido la principal fuente para los intrusos, ya que los protocolos e-mail están entre los servicios más viejos y más conocidos. Así también, un servidor e-mail requiere acceso al mundo exterior; la mayor parte de los servidores e-mail aceptan entrada desde cualquier fuente. Un servidor e-mail generalmente consiste de dos partes: un agente para enviar y recibir y un agente de procesamiento. Ya que el e-mail está disponible para todos lo usuarios y es usualmente privado, el agente de procesamiento, requiere privilegios del sistema, para liberar el mail. La mayor parte de las implementaciones e-mail ejecutan ambas porciones del servicio, lo cual significa que el agente de recepción también posee privilegios del sistema. Esto abre varias brechas de seguridad, que este documento no describirá. Existen algunas implementaciones disponibles que permiten una separación de los dos agentes. Tales implementaciones son consideradas más seguras, pero requieren cuidadosa instalación, para evitar crear un problema de seguridad.

3.2.3.5.- World Wide Web (WWW)

El Web está creciendo en popularidad en forma exponencial, a causa de su facilidad de uso y la poderosa capacidad de concentrar servicios de información. La mayor parte de los servidores Web aceptan algún tipo de dirección y acción de parte de las personas que accesan sus servicios. El ejemplo más común es tomar un requerimiento de un usuario remoto y transferir la información provista de un programa que se ejecuta en el servidor, al proceso requerido. Algunos de esos programas no son escritos considerando la seguridad y pueden por esto, tener brechas en la seguridad. Si un servidor Web está disponible para la comunidad de Internet, es muy importante que la información confidencial no sea localizada en conjunto, en el mismo host que el servidor. De hecho, es recomendado que el servidor tenga un host dedicado que no sea “confiable” para otros hosts internos.

Muchos sitios pueden desear localizar en forma conjunta el servicio FTP con su servicio WWW. Pero esto debe ocurrir sólo para servidores ftp anónimos, los cuales sólo proveen de información (ftp-get). El poner información en ftp anónimo, en conjunto con www, es peligroso (por ejemplo podrían resultar en modificaciones a la información que el sitio está publicando en el Web) y en ellos mismos efectuar las consideraciones de seguridad para cada servicio diferente.

3.2.3.6.- Transferencia de archivos (FTP, TFTP)

FTP y TFTP permiten a los usuarios recibir y enviar archivos electrónicos en forma punto a punto. Sin embargo, ftp requiere autenticación, mientras que TFTP no lo requiere. Por esta razón, TFTP se debería evitar, tanto como sea posible.Seguridad en sitios Página 21 de 48

La configuración incorrecta de los servidores ftp, puede permitir a los intrusos copiar, reemplazar y borrar archivos, en cualquier lugar del host, por lo que es muy importante configurar este servicio correctamente. El acceso a passwords encriptadas y datos propietarios y la introducción de caballos de Troya, son algunas de las potenciales brechas en la seguridad que ocurren cuando el servicio no se configura en forma correcta. Los servidores Ftp deben residir en su propio host. Algunos sitios eligen ubicar Ftp junto con un servidor Web, ya que los dos protocolos comparten consideraciones de seguridad comunes. Sin embargo, en la práctica esto no es recomendado, especialmente cuando el servicio Ftp permite el depósito de archivos. Como se mencionó en la sección (3.2.3), los servicios ofrecidos internamente por su sitio, no deberían ubicarse en conjunto con servicios ofrecidos externamente. Cada uno debería tener su propio host.

TFTP no soporta el mismo rango de funciones que Ftp y no posee todo tipo de seguridad. Este servicio debería solamente ser considerado para uso interno y ser configurado en forma restrictiva, tal que el servidor sólo tenga acceso a un conjunto de archivos predeterminados (en vez de archivos de lectura-a-todo-el mundo del sistema). Probablemente el uso más común de Tftp es descargar archivos de configuración de un router para un router. Tftp debería residir en su propio host y no debería ser instalado en hosts que soporten Ftp externo o acceso Web.

3.2.3.7.- NFS

El Servicio de Archivos de Red, permite a los hosts compartir discos comunes. NFS es usado frecuentemente por hosts sin discos, que dependen de un servidor de discos para todas sus necesidades de almacenamiento. Desafortunadamente, NFS no tiene la seguridad en su concepción. Por esto es necesario que el servidor NFS sea accesable sólo por aquellos hosts que lo usan para servicio. Esto se consigue especificando a cuáles hosts el sistema de archivos está siendo exportado y de qué manera (es decir, read-only, read-write, etc.). Los archivos del sistema no deberían exportarse a cualquier host externo a la red local, ya que se requeriría que el servicio NFS sea accesible externamente. Idealmente el acceso externo al servicio NFS debería ser bloqueado por un firewall.

3.2.4.- Protegiendo la protección

Es sorprendente cuán a menudo un sitio pasará por alto las debilidades más obvias y su seguridad, por dejar que el servidor de seguridad se abra por sí mismo a un ataque. Basándose en las consideraciones previamente discutidas, debería ser claro que: el servidor de seguridad no debería ser accesible desde sitios externos; debería ofrecer el mínimo de acceso a los usuarios del sitio, excepto para la función de autenticación; y no debería ser ubicado en forma conjunta con otros servidores. Más aún, todos los Seguridad en sitios Página 22 de 48

accesos al nodo, incluyendo acceso a los mismos servicios deberían ser logeados para proporcionar una “huella de papel” en el momento de una brecha en la seguridad.

3.3.- Firewalls

Una de las medidas de seguridad más destacada y publicitada en Internet es el uso de un Firewall. Los Firewalls han sido la panacea para muchos, si no todos, los temas de seguridad en Internet. Pero no lo son. Los Firewalls son otra de las herramientas en la búsqueda de sistemas de seguridad. Ellos proporcionan un cierto nivel de protección y son en general una forma de implementar políticas de seguridad en el nivel de red. El nivel de seguridad que proporciona un Firewall puede variar tanto como el nivel de seguridad de una máquina particular. Existe el tradicional balance entre seguridad, facilidad de uso, costo, complejidad, etc.

Un Firewall es uno de los mecanismos usados para controlar y monitorear accesos a y desde una red, con el propósito de protegerla. Un Firewall actúa como un gateway, a través del cual todo el tráfico fluye desde y hacia la red y/o sistema protegido. Los Firewalls ayudan a detectar limitaciones en la cantidad y tipo de comunicaciones que tienen lugar entre la red protegida y las otras redes (por ejemplo, Internet u otra sección de la red del sitio).

Un Firewall es generalmente una forma de construir una muralla entre una parte de una red, por ejemplo una red interna de la compañía y otra parte, por ejemplo la Internet global. La carácterística única de esta muralla es que necesita estar concebida para tráfico con características particulares a transferir a través de puertas cuidadosamente vigiladas (gateways). La parte difícil es establecer el criterio por el cual los paquetes tienen acceso permitido o denegado a través de las puertas.La literatura acerca de Firewalls usa diferente terminología para describir las variadas formas de Firewalls. Esto puede confundir a los administradores del sistema que no están familiarizados con Firewalls. Lo que se debe notar aquí es que existe una descripción fija para los Firewalls.

Los Firewalls no son siempre una máquina individual. En lugar de ello, los Firewalls son a menudo una combinación de routers, segmentos de red y computadores hosts. Para el propósito de este documento, el término Firewall consistirá de más de un dispositivo físico. Los Firewalls son comúnmente construídos usando dos componentes diferentes: routers de filtrado y servidores proxys.

Los routers de filtrado son los componentes más fáciles de conceptualizar en un Firewall. Un routers mueve datos de un lugar a otro entre dos o más redes. Un router normal toma un paquete de una red A y rutea este a su destino en la red B. Un router de filtrado hace lo mismo, pero no decide solamente cómo rutear el paquete, sino que considera si este paquete debe ser ruteado por él. Esto se logra instalando una serie de filtros a través de los cuales el router decide qué hacer con un paquete de datos.


Una discusión referida a las capacidades de una marca particular de router, corriendo una versión de sw particular, escapa al alcance de este documento. Sin embargo, cuando se evalúa un router usado para filtrar paquetes, los siguientes criterios pueden importar cuando se implementa una política de filtrado. Direcciones IP fuente y destino, números de puerta TCP fuente y destino, estado del bit de reconocimiento TCP, números de puerta UDP fuentes y destino y dirección de flujo del paquete (es decir, A -> B o B -> A). Otra información necesaria para construir un esquema de filtrado seguro es si el router reordena las instrucciones de filtrado (diseñado para optimizar filtros, esto puede algunas veces cambiar el significado y causar acceso no intencionado) y si es posible de aplicar filtrado para paquetes de entrada y salida en cada interface (si los routers filtran sólo paquetes de salida, entonces el router está al exterior de los filtros y puede ser más vulnerable a un ataque). En suma, para que el router sea vulnerable, esta distinción entre aplicar filtros a paquetes de entrada o salida es especialmente relevante para routers con más de dos interfaces. Otro tema importante se refiere a las capacidades de crear filtros en las opciones del encabezado IP y el fragmento de estado de un paquete. El construir un buen filtro puede ser muy difícil y requiere una buena comprensión del tipo de servicios (protocolos) que serán filtrados.

Para mayor seguridad, los filtros restringen el acceso entre las dos redes conectadas a un host, el host salvaguardia. Sólo es posible accesar la otra red a través de este host salvaguardia. Dado que sólo este host, más que otros host, puede ser atacado, es fácil de mantener un cierto nivel de seguridad, ya que sólo este host ha sido protegido cuidadosamente. Para permitir que los recursos estén disponibles a los legítimos usuarios a través del Firewall, los servicios han sido enviados anticipadamente por el host salvaguardia. Algunos servidores poseen concepción de adelantamiento (como servidores DNS o SMTP), para otros servicios (por ejemplo Telnet, Ftp, etc.), los servidores proxy pueden ser usados para permitir el acceso a los recursos a través del Firewall en una forma segura.

Un servidor proxy está hecho para concentrar los servicios de aplicación a través de una única máquina. Existe una única máquina (la máquina salvaguardia) que actúa como un servidor proxy para una variedad de protocolos (Telnet, SMTP, Ftp, Http, etc.), pero pueden haber computadores host individuales para cada servicio. En vez de conectarse directamente a un servidor externo, el cliente se conecta al servidor proxy, el cual inicia una conexión al servidor externo requerido. Dependiendo del tipo de servidor proxy utilizado, es posible configurar clientes internos para ejecutar esta redirección en forma automática, sin conocer al usuario. Otros deben requerir que el usuario se conecte directamente al servidor proxy y entonces iniciar la conexión a través de un formato específico.

Existen significativos beneficios en seguridad, los cuales pueden ser derivados del uso de servidores proxys. Es posible agregar listas de control de acceso a protocolos, requiriendo los usuarios o sistemas prorporcionar algún nivel de autenticación, antes de que se confiera el acceso. Los servidores proxy más poderosos, algunas veces llamados Application Layer Gateways (AlGs) se pueden escribir para que aprendan Seguridad en sitios Página 24 de 48

protocolos específicos y pueden ser configurados para bloquear sólo secciones del protocolo, Por ejemplo un ALG para Ftp puede explicar las diferencias entre el comando “put” y el “get”. Una organización podría permitir a usuarios efectuar “get” a archivos desde Internet, pero no ser permitir “put” de archivos internos en un servidor remoto. En contraste, un router de filtrado podría bloquear todos los accesos Ftp o ninguno, pero no un subconjunto.

Los servidores proxys también pueden ser configurados para encriptar tramas de datos, basados en una variedad de parámetros. Una organización debe usar esta caracaterística para permitir conexiones encriptadas entre dos ubicaciones cuyos únicos puntos de acceso están en Internet.

Los firewalls están concebidos como una manera de mantener fuera a los intrusos, pero a menudo son usados como una forma de legitimar a los usuarios dentro del sitio. Existen muchos ejemplos donde un usuario válido requiere acceso regularmente al sitio “home”, mientras va en viaje de negocios. El acceso a la Internet está a menudo disponible, pero puede ser a través de una máquina o red poco confiable. Un servidor proxy correctamente configurado permite a los usuarios legítimos accesar el sitio, mientras denega acceso a los otros usuarios.

El mejor esfuerzo en técnicas Firewall, se encuentra usando una combinación de un par de routers protegidos con uno o más servidores proxys en una red entre los dos routers. Este seteo permite a los routers externos bloquear cualquier intento de uso bajo el nivel IP, para romper la seguridad, mientras el servidor proxy permite manejar potenciales brechas en la seguridad en los protocolos de nivel superior. El propósito de los router internos es bloquear todo el tráfico, excepto al servidor proxy. Si este setup es implementado en forma rígida, se puede alcanzar un nivel superior de seguridad.

La mayor parte de los Firewalls proporcionan registros que pueden ser sintonizados para permitir administrar en forma segura la red más conveniente. El registro puede ser centralizado y el sistema puede ser configurado para enviar alertas por condiciones anormales. Es importante monitorear regularmente esos logs para chequear cualquier presencia de intrusos o intentos de quiebre. Desde luego, algunos intrusos intentarán cubrir sus rastros, editando los logs, por lo que es deseable proteger esos logs. Se disponde de una variedad de métodos, incluyendo: escribir sólo una vez, leer muchos drives WORM, logs de papers y logging centralizado vía el utilitario “syslog”. Otra técnica es el uso de una “simulada” impresora serial, pero teniendo la puerta serial conectada a una máquina o PC que mantiene los logs.

Los Firewalls están disponibles en un amplo rango de calidades y potencia. Los paquetes comerciales van desde los US$ 10.000 hasta sobre US$ 250.000. Se pueden construir “Firewalls caseros”, por menos dinero. Se debe recordar que un correcto seteo de los Firewalls (comercial o casero) requiere significativos conocimientos en TCP/IP. Además, requieren mantención regular, instalación de parches y


actualizaciones y monitoreo regular. Se deben considerar estos costos adicionales, además de los costos de los elementos físicos.

Una nota final acerca de los Firewalls, es que ellos pueden ser de gran ayuda al implementar la seguridad de un sitio y lo protegen de una gran variedad de ataques. Sin embargo es importante recordar que son sólo una parte de la solución. Ellos no protegen el sitio contra todo tipo de ataques.

4.- PROCEDIMIENTOS Y SERVICIOS DE SEGURIDAD4.- PROCEDIMIENTOS Y SERVICIOS DE SEGURIDAD

4.1.- Autenticación

Por muchos años, el método prescrito para autenticar usuarios ha sido el uso de passwords estándar y reusables. Originalmente esas passwords eran usadas por usuarios de terminales, para autenticarse en un computador central. En ese tiempo no existían las redes (internas o externas), por lo que el riesgo de descubrirlas era mínimo. Hoy día, los sistemas están conectados a través de una red local y ellas a su vez están fuertemente conectadas a la Internet. Los usuarios se loggean a través de todo el mundo; sus passwords reusables son transmitidas a través de las mismas redes, posibilitando ser capturadas. De hecho, el Centro de Coordinación CERT y otros centros están observando un gran número de indidentes que involucran intrusión de paquetes que capturan dichas passwords.

Con el advenimiento de las nuevas tecnologías como las passwords one-time (por ejemplo S/Key), PGP y dispositivos de autenticación basados en tokens, las personas están usando strings de passwords como tokens secretos. Si esos tokens secretos no son seleccionados ni protegidos adecuadamente, la autenticación sería fácilmente violada.

4.1.1.- Passwords one-time

Como se mencionaba anteriormente, dados los ambientes de redes actuales, es recomendable que los sitios referidos a la seguridad e integridad de sus sistemas y redes, consideren cambiarse desde las passwords reusables. Ha habido muchos incidentes que involucran programas de red troyanos (por ejemplo Telnet y Rlogin) y programas de detección de paquetes de red. Esos programas capturan la tripleta password/nombre de cuenta/nombre host. Los intrusos pueden usar la información capturada para accesos subsecuentes a esos host y cuentas. Esto es posible ya que 1) la password es usada en forma reusable y 2) la password viaja por la red en forma de texto oculto.Seguridad en sitios Página 26 de 48

Varias técnicas de autenticación han sido desarrolladas para resolver este problema. Entre esas técnicas se encuentran las tecnologías preguntas-respuestas, que proporcionan passwords que son usadas sólo una vez (comúnmente llamadas passwords one-time). Existe un número de productos disponibles que se deberían considerar de usar.

4.1.2.- Kerberos

Kerberos es un sistema de seguridad de red distribuído que proporciona autenticación a través de redes no seguras. La integridad y la encriptación son también provistas, si se requiere por la aplicación. Kereberos fue desarrollada en el MIT (Massachusetts Institute of Technology), a mediados de 1980. Existen dos versiones (4 y 5) las cuales para propósitos prácticos son incompatibles.

Kereberos consiste en una base de datos de clave simétrica, que usa un centro de distribución clave, lo que se conoce por Kerberos server. Un usuario o servicio (conocido como “principales”) conceden “tickets” electrónicos, después de comunicarse con el KDC. Esos tickets son usados para autenticación entre los principales. Todos los tickets incluyen un tiempo que limita el periodo de tiempo para el que el ticket es válido. Por esto, los clientes y servidores Kereberos deben tener un tiempo base seguro y ser capaces de mantener el tiempo cuidadosamente.

El lado práctico de Kereberos es su integración con el nivel de aplicación. Las aplicaciones típicas como Ftp, telnet, POP y NFS han sido integradas con el sistema Kereberos.

4.1.3.- Elección y protección de tokens secretos y PIN’s

Cuando se seleccionan tokens secretos, se debe cuidar elegirlos cuidadosamente. Como en la selección de passwords, ellos deberían ser robustos en relación con el esfuerzo bruto pensado para ellos. Esto es, ellos no deberían ser palabras individuales en cualquier lenguaje, industria o acrónimos culturales, etc. Idealmente deberían ser más grandes que pequeños y consistir de frases de paso que combinen mayúsculas y minúsculas, dígitos y otros caracteres.

Una vez elegida, la protección de esos tokens secretos es muy importante. Algunos son usados como pines a dispositivos de hardware (como tarjetas token) y no deberían ser escritos o ubicados en el mismo lugar que el dispositivo con el cual son asociados.

Finalmente, cuando se usen productos de criptografía como PGP, se debe cuidar de determinar la propia longitud clave y asegurarse que los usuarios estén entrenados para ello.


4.1.4.- Aseguramiento de Password

Los siguientes consejos ayudan en la selección y mantención de passwords tradicionales, pero se debe recordar que ninguna de estas medidas proporciona protección contra su divulgación ilegal, debido a la existencia de programas destinados a este objetivo.

(1) La importancia de passwords robustas. En muchos casos de penetración de sistemas, los intrusos requieren obtener el acceso a una cuenta del sistema. Una forma de lograrlo es adivinando la password de un usuario legítimo. Esto se puede lograr a través de un programa de chequeo de passwords, que utiliza un gran diccionario contra el archivo de passwords del sistema. En este caso, la única forma de protegerse es a través de la selección cuidadosa de passwords que no puedan ser adivinadas (es decir, combinación de números, letras y caracteres de puntuación). Las passwords deben tan grandes como el sistema y el usuario lo puedan tolerar.Cambiando las passwords de defecto. Muchos sistemas operativos y programas de aplicación son instalados con cuentas y passwords por defecto. Estas se deben cambiar inmediatamente por aquellas que no puedan ser adivinadas o destruídas.

(2) Restringir el acceso al archivo de passwords. Un sitio que desea proteger la porción de passwords encriptada del archivo, en forma tal que no permita su disponibilidad a los intrusos. Una técnica efectiva es usar passwords ocultas, donde el campo password del archivo estándar, contiene una password falsa. El archivo con las passwords legítimas es protegido en otra parte del sistema.

(3) Password envejecidas. El cuándo y cómo expira una password, es aún objeto de controversias en la comunidad de seguridad. Se acepta generalmente que una password no debería ser mantenida una vez que la cuenta tiene un largo periodo sin uso, pero se debate fuertemente si un usuario debería ser obligado a modificar una buena password que está en uso. Los argumentos para cambiar las passwords se refieren a la prevención del uso continuado de cuentas penetradas. Sin embargo, la oposición a esta postura indica que los cambios frecuentes a passwords conduce a los usuarios a escribir sus passwords en areas visibles o los obliga a tener passwords muy simples y fáciles de adivinar. También se debe considerar que un intruso utilice una password capturada más temprano que tarde, en cuyo caso la password antigua proporciona muy pequeña protección.

(4) Mientras no exista respuesta definitiva a este dilema, una política de password debería considerar el asunto y proporcionar pautas acerca de la frecuencia en que un usuario deba cambiar su password. Ciertamente un cambio anual a su password no es difícil para la mayoría de los usuarios. Se recomienda que las passwords sean modificadas al menos, cuando una cuenta de privilegios se encuentre


comprometida o exista un cambi crítico en el personal (especialmente si se trata del administrador).

(5) Bloqueo de cuentas y passwords. Algunos sitios utilizan el deshabilitar las cuentas, después de varios intentos fallidos de autenticación. Si se decide utilizar esta técnica, es preferible que no exista advertencia de ello. El mensaje sólo debe indicar un login fallido. Para implementar esto se requiere que los usuarios legítimos contacten al administrador para solicitar la reactivación de sus cuentas.

(6) Acerca del “demonio de los dedos”. Por defecto el “demonio de los dedos” despliega considerable información del usuario y sistema. Por ejemplo, una lista de todos los usuarios que están utilizando el sistema o el contenido de un archivo de plan de usuarios. Esta información puede ser utilizada por los intrusos para identificar los usernames y adivinar las passwords. Se recomienda que los sitios modifiquen la aplicación para restringir la información desplegada.

4.2- Confidencialidad

Existirá información que el sitio deseará proteger. Los sistemas operativos tienen mecanismos de protección de fábrica, los que permiten a un administrador controlar quiénes pueden accesar el sistema o ver el contenido de un archivo determinado. Una buena forma de proporcionar confidencialidad es a través de la encriptación. Esta se logra con una mezcla de datos, lo que hace muy difícil detectarla. Los receptores autorizados y los propietarios de la información poseerán las claves de la descripción que permitirá fácilmente descubrir el texto a una forma de lectura. Se recomienda el uso de encriptación para proporcionar confidencialidad y proteger la información valiosa.

El uso de la encriptación es controlada y regulada algunas veces a nivel gubernamental, por lo que se recomienda a los administradores estar bien informados de las leyes y políticas que regulan su uso, antes de emplearlas.

4.3.- Integridad

Un administrador se deberá asegurar que la información no ha sido alterada en una forma no autorizada. Esto significa que se deberá proporcionar algún grado de confianza acerca de la integridad de la información del sistema. Una forma de proporcionar esto es producir una cuadratura off-line de los archivos no alterados, almacenar esa cuadratura y periodicamente asegurarse que las cuadraturas del archivo on-line no han cambiado (lo que indicaría que los datos han sido modificados).

Algunos sistemas operativos vienen con programas de cuadraturas, tal como el UNIX. Sin embargo, puede que no proporcionen la protección que se requiere. Por esto se Seguridad en sitios Página 29 de 48

sugiere el uso de un programa robusto criptagráficamente, tal como el programa de mensajes MD5, para producir cuadraturas que permitan asegurar las integridad.

Existen otras aplicaciones donde se debe asegurar la integridad, como por ejemplo al transmitir un mensaje e-mail entre dos lugares. Existen productos que pueden proporcionar esta capacidad. Una vez identificadas las capacidades requeridas, se pueden identificar las tecnologías que las provean.


4.4- Autorización

La autorización se refiere al proceso de garantizar privilegios a procesos y finalmente a usuarios. Esto difiere de la autenticación, la cual es un proceso para identificar a un usuario, Una vez que se identifica, los privilegios, derechos, propiedades y acciones permitidas al usuario, son determinadas por la autorización.

Una aproximación popularizada por los sistemas UNIX es asignar a cada objeto, tres clases de usuario: propietario, grupo y mundo. El propietario es el creador del objeto o el usuario asignado como propietario por el super usuario. Los permisos del propietario (lectura, escritura y ejecución), se aplican sólo a él. Un grupo es un conjunto de usuarios qye comparten derechos de acceso a un objeto. Los permisos del grupo (lectura, escritura y ejecución) se aplican a todos los usuarios del grupo (excepto el propietario). El mundo se refiere a cada persona con acceso al sistema. Los permisos al mundo (lectura, escritura y ejecución) se aplican a todos los usuarios (excepto al propietario y los miembros del grupo).

Otro caso el añadir a un objeto una lista que contiene las identidades de todos los usuarios permitidos (o grupos). Esto es un ACL (Lista de Control de Acceso). La ventaja de los ACL es que son fácilmente mantenidos (una lista central por objeto) y es muy fácil de chequear visualmete quienes han tenido acceso y a qué. Las desventajas son los recursos extras requeridos para almacenar tales listas, así como el vasto número de tales listas requeridas para sistemas grandes.

4.5.- Acceso

4.5.1.- Acceso físico

La restricción física de acceso al host, permite que sólo aquellas personas que se supone usan el host, tengan acceso. Los hosts incluyen terminales “confiables” (es decir, terminales que permiten uso no autenticado, tal como consolas del sistema, operador de terminales y terminales dedicados a trabajos especiales) y microcomputadores y workstations individuales, especialmente aquellas conectadas a la red. Se debe asegurar que las areas de trabajo de las personas se encuadre a las restricciones de acceso. En otro caso, ellas encontrarán la forma de evadir la seguridad física (ejemplo taco en la puerta abierta).

Mantener las copias originales y de respaldo de datos y programas. Aparte de ello, deben ser protegidos de robo. Es importante mantener respaldos en lugares separados de los originales, no sólo por consideraciones de daños, sino también para evitar robos.

Los hosts portátiles poseen riesgos particulares. Se debe asegurar que no habrá problemas si uno de los computadores portátiles es robado. Se debe considerar pautas Seguridad en sitios Página 31 de 48

acerca de los tipos de datos que se permiten en los discos de los computadores portátiles y cómo ellos deben ser protegidos (por ejemplo la encriptación).

Otras areas donde se debe restringir el acceso físico son los armarios de cableado y elementos importantes de las red como los servidores de archivos, nombre del servidor hosts y los routers.

4.5.2.- Conecciones de red departamentales

Esto quiere decir puntos conectados en red, ubicados de una manera conveniente para permitir a los usuarios conectar los computadores portátiles a la red.

Se debe considerar si es necesario proveer este servicio, considerando que cualquier usuario incorpore un host no autorizado a la red. Esto incrementa el riesgo de ataques a través de técnicas tales como direcciones IP falsas, intervención ilegal en paquetes, etc. Los usuarios y la administración del sitio deben apreciar los riesgos involucrados. Si se decide proveer conexiones departamentales, se debe planear el servicio cuidadosamente y definir en forma precisa dónde se proporcionará, para permitir asegurar seguridad en el acceso físico.

Un host departamental debería ser autenticado antes de permitir a sus usuarios accesar los recursos de la red. Como una alternativa, es posible controlar el acceso físico. Por ejemplo, si el servicio es usado por estudiantes, se debe proveer enchufes de conexión en laboratorio de estudiantes.

Si se está proporcionando acceso walk-up a los visitantes que se conectan a la red desde su domicilio (por ejemplo, para leer e-mail,etc.), se debe considerar el uso de una subred que no tenga conectividad a la red interna.

Se debe vigilar cualquier area que contenga acceso no monitoreado a la red, tales como oficinas vacantes. Puede ser mejor desconectar tales areas a los closets de cableado y considerar el uso de hubs seguros y monitorear intentos de conexión de host no autorizados.

4.5.3.- Otras tecnologías de redes

Las tecnologías consideradas incluyen X.25, ISDN, SMDS, DDS y Frame Relay. Todas se proveen por enlaces físicos y poseen el potencial de ser interferidos.

Con las tecnologías de switch, el uso de circuitos virtuales permanentes o Grupos de usuarios cerrados, dondequiera esto sea posible. Las tecnologías que proveen autenticación y/o encriptación (tal como IPv6), deben ser consideradas en los enlaces donde la seguridad es importante.Seguridad en sitios Página 32 de 48

4.5.4.- Modems

4.5.4.1.- Las lineas de modem deben ser administradas

Aunque ellos proporcionan un acceso conveniente a un sitio para los usuarios, también permiten un efectivo desvío a los firewalls del sitio. Por esta razón es escencial mantener el control sobre los modems.

No se debe permitir a los usuarios instalar una linea de modem sin la debida autorización. Esto incluye a las instalaciones temporales (por ejemplo conectar un modem a una linea de fax o teléfono, durante la noche).

Se debe mantener un registro de todas las lineas de modem, con el objeto de chequear modems no autorizados.

4.5.4.2.- El discado de usuarios debe ser autenticado

El chequeo al username y password se debe realizar, antes que el usuario acceda a la red.Se debe recordar que las lineas de teléfono pueden ser interferidas y es bastante fácil interceptar mensajes a teléfonos celulares. Los modernos modems de alta velocidad utilizan técnicas de modulación más sofisticadas, que los hacen más difíciles de monitorear, pero se debe asumir que los hackers saben escuchar estas lineas. Por esta razón se deben usar passwords one-time si es posible.

Es útil tener un único punto de discado, para que todos los usuarios sean autenticados en la misma forma.

Los usuarios ocasionalmente olvidarán la password. Se debe establecer un corto retardo (2 segundos) entre el primer y segundo login fallido y forzar a la desconexión después del tercero. No se debe explicar al usuario que el username o password eran incorrectas.

4.5.4.3.- Capacidad de call-back

Algunos servidores de discado ofrecen el call-back, esto es, el usuario disca, es autenticado y entonces el sistema desconecta la llamada y efectúa una nueva llamada a un número específico. Call-back es útil ya que si alguien estaba tratando de adivinar un username y una password, serán desconectados y es sistema entonces volverá a llamar al usuario legítimo. Esto significa que los usuarios sólo se pueden loggear desde una ubicación (donde el servidor está configurado para call-back).Seguridad en sitios Página 33 de 48

Esta característica debe ser usada con precaución; puede ser fácilmente baypaseado. Como mínimo se debe asegurar que la llamada de retorno nunca se haga desde el mismo modem que el de entrada. Aunque call-back puede mejorar la seguridad en modems, no debería dependerse sólo de esto.

4.5.4.4.- Todos los logins deben ser loggeados

Todos los logins, exitosos o no, deben ser loggeados. Sin embargo no se deben mantener las passwords correctas en el log. Ya que la mayor parte de las passwords incorrectas son digitadas por usuarios autorizados, ellas sólo varían en un carácter, respecto de la password actual. Por esto, si no se puede mantener un log seguro, no se debe logear.

Si la linea de identificación de llamada está disponible, se debe aprovechar para registrar los números llamados en cada intento de login. Se debe considerar que la linea de identificación de llamada, no es confiable. Use el dato para propósitos de información únicamente y no para autenticación.

4.5.4.5.- Elegir la presentación de entrada cuidadosamente

Algunos mensajes desplegados por defecto en algunos sistemas, contienen el tipo de host y el hardware o sistema operativo presente. Esto puede ser información valiosa para los intrusos. En vez de ello, cada sitio debería crear su propia presentación de login, cuidando de incluir sólo la información necesaria. Sólo el nombre del sitio, una advertencia corta acerca del monitoreo de las sesiones y el respectivo prompt del username/password. Se debe verificar desde el punto de vista legal la información incluída en la presentación.

Para aplicaciones de alta seguridad, se debe considerar el uso de password secreta (es decir, no responder a una llamada de entrada hasta que el usuario haya tipeado su password). Esto simula a un modem muerto.

4.5.4.6.- Autenticación dial-out

Los usuarios dial-out deben ser autenticados, especialmente porque el sitio deberá pagar los cargos telefónicos

Nunca se debe permitir dial-out desde un discado no autenticado y se debe considerar si esto será permitido desde uno autenticado. El objetivo es prevenir a los usuarios que llaman usando el pool de modem como parte de una cadena de logins. Esto puede ser


difícil de detectar, especialmente si un hacker establece un camino a través de carios hosts en su sitio.

Al menos no se debe permitir que los mismos modems y lineas de teléfono sean usados para dial-in y dial-out. Esto se puede implementar si se ejecutan en forma separada los pool de modems dial-in y dial-out.

4.5.4.7 Asegurarse que el modem sea a "pueba de balas", tanto como sea posible

Se debe asegurar que los modems no puedan ser reprogramados mientras están en servicio.Se debe programar el modem para restablecer la configuración estándar, al inicio de cada nueva llamada. De fallar esto, haga que el restablecimiento se produzca al final de cada llamada. Esta precaución protegerá contra reprogramaciones accidentales de los modems. Efectuando el restablecimiento al comienzo y final de cada llamada, se asegura con un alto nivel de confiabilidad que una nueva llamada no heredará datos de una sesión de llamada previa.

Chequear el término de llamadas por el modem. Cuando un usuario termina una sesión de un servidor de acceso, se debe verificar que el servidor cuelga la linea de teléfono adecuadamente. Es igualmente importante que el servidor fuerce logouts desde cualquier sesión activa si el usuario cuelga en forma inesperada.

4.6.- Auditoría

Esta sección cubre los procedimientos para recolectar datos generados por la actividad de red, los cuales pueden ser usados en analizar la seguridad de una red y responder a incidentes de seguridad.

4.6.1.- ¿Qué recolectar?

Los datos auditados deben considerar cualquier intento de alcanzar un nivel diferente de seguridad, para cualquier persona, proceso u otra entidad en la red. Esto incluye login y logout, acceso a super usuario (o el equivalente no-Unix), generación de tickets (por ejemplo, para Kerberos) y cualquier otro cambio de acceso o status. Es especialmente importante notar acceso "anonymous" o "visitante" a servidores públicos.

La recolección de datos diferirá para diferentes sitios y para diferentes tipos de cambios de acceso dentro de un sitio. En general, la información a recolectar incluye: usernames y hostname para login y logout; derechos de acceso previo y nuevo para un cambio en derechos de acceso y un cronómetro. Por supuesto, existe mucho más


información que puede ser recolectada, dependiendo de la disponibilidad del sistema y la cantidad de espacio disponible para almacenar dicha información.

Una nota muy importante es que no se deben recolectar las passwords. Esto crea una potencial brecha en la seguridad si los registros de auditoría son accesado en forma indebida.

4.6.2.- Procesos de recolección

Los procesos de recolección deben ser dictados para el host o recurso que se esté accesando.Dependiendo de la importancia del dato, se puede mantener almacenado en forma local y después se envía a un medio de almacenamiento.El almacenar los datos auditados en archivos, permite su rápida recuperación, lo cual puede ser importante si un ataque se está produciendo. Sin embargo, este medio es también el menos confiables. Esto se mejora en almacenamientos como los CD-ROM, los cuales no pueden ser alterados en su contenido, pero con las desventajas de costo y no rápida obtención de los datos.

Las impresoras de linea son útiles en aquellos casos en que los datos son permanentes y son requeridos en forma rápida. Un ejemplo de este caso es un sistema en tiempo real, donde se debe registrar el punto exacto de la falla. La desventaja de este tipo de impresoras es la obligación de mantener la impresora alimentada y efectuar la búsqueda de problema manualmente, además de determinar el lugar donde almacenar el volumen de papel que se acumula. Las impresoras láser pueden sufrir pérdida de datos en los búffers.

También está el problema del camino entre el dispositivo que genera el log y los medios de almacenamiento, camino que puede sufir algún daño. Por lo tanto este camino debe transcurrir entre un mínimo número de redes y routers.

4.6.3.- Carga de la recolección

La recolección de datos puede derivar en un gran volúmen de información. Las formas para reducir el espacio son: la compresión de datos, mantener datos de resúmen de aquellos que se encuentren en dispositivos de almacenamiento masivo. La desventaja de esto último radica en la respuesta a los incidentes, cuya adecuada evaluación exige un análisis de datos detallado al mínimo tiempo.


4.6.4.- Manejo y preservación de datos auditados

Los datos de auditoría deben ser sometidos a los más cuidadosos respaldos. Si un intruso accede a estos datos, el sistema está en riesgo.

Estos datos son claves en la detección, investigación y seguimiento de un incidente. Por ello se debe recurrir a asesoría legal para determinar el adecuado tratamiento de los datos.

4.6.5.- Consideraciones legales

El contenido de los datos de auditoría, exige la preparación para las contingencias que se derivan de su existencia y contenidos. Una de las areas se refiere a la privacidad de los individuos. La otra se refiere a que un host de una organización sea utilizado como puente para atacar a otra. ¿Es responsabilidad la primera de negligencia?.

Estos factores exigen a las Empresas considerar aspectos legales a los datos de auditoría.

4.7.- Backups seguros

Los backups forman parte de un plan integral de seguridad. En este contexto, existen varios aspectos importantes: Asegurarse que el sitio esté creando backups Asegurarse que se estén utilizando sitios externos de almacenamiento para el

backup Utilizar encriptado de backups, para proteger la información almacenada

externamente No asumir que siempre los backups son buenos Periodicamente verificar la completitud y corrección de los backups.

5.- MANEJO DE INCIDENTES DE SEGURIDAD5.- MANEJO DE INCIDENTES DE SEGURIDAD

Aquí se proporciona una guia a utilizar para antes, durante y después que un incidente de seguridad computacional ocurre en un host, red, sitio o ambiente muti-sitio.La filosofía es reaccionar de acuerdo a un plan.

La seguridad computacional tradicional, mientras presta gran atención a un plan de seguridad integral del sitio, presta poca atención a cómo manejar un ataque, cuando este ocurre. El resultado es que cuando el ataque ocurre, muchas decisiones son tomadas de prisa, causando un grave daño al rastreo de los incidentes, recolección de Seguridad en sitios Página 37 de 48

evidencia a ser utilizada, preparación y recuperación del sistema y protección a los datos valiosos del sistema.

Uno de los más importantes beneficios de un eficiente manejo de incidentes, se da en el aspecto económico. Tener el personal técnico y administrativo para responder a un incidentes, requiere muchos recursos. El debido entrenamiento para un manejo eficiente del problema, ahorra recursos.

Debido a la existencia de las redes de alcance mundial, muchos de los incidentes no se restringen sólo a un sitio. Es vital que todos los sitios involucrados, sean informados lo antes posible.

Otro beneficio se refiere a las relaciones pública, ya que la prensa tiende a dañar la imagen de una organización cuando sufre algún incidente de seguridad. El manejo eficiente de los incidentes, minimiza la exposición negativa.

Un beneficio final se refiere a los aspectos legales. Es posible que en el futuro, las organizaciones adquieran la responsabilidad porque uno de sus nodos fue utilizado para lanzar del ataque. En forma similar, las personas que desarrollan parches o corrección de errores, pueden ser demandados, debido a que estos no son efectivos, permitiendo el daño a los sistemas. El conocer acerca de la vulnerabilidad de los sistemas operativos y patrones de ataque y el tomar medidas preventivas contra esas amenazas, prepara a la organización para enfrentar de mejor manera los problemas legales.

5.1.- Preparando y planificando el manejo de incidentes

El manejo de incidentes debe prepararse en primer lugar para responder a un incidentes, antes de que este ocurra. Esto incluye establecer un adecuado nivel de protecciones. La protección también debe considerar una pauta para el manejo de incidentes, como parte del plan de contingencia de la empresa.Una plan escrito, elimina muchas de las ambigüedades que ocurren en el manejo de un incidente y conducen a un conjunto de respuestas más minucioso y preciso.

Es de vital importancia probar el plan, antes de que un incidente ocurra (se puede contratar a especialistas que intenten penetrar en la seguridad del sistema)

El aprender a responder eficientemente a un incidente es importante por lo siguiente: Protege los bienes que están comprometidos Proteger los recursos que podrían ser usados más provechosamente si un incidente

no requirió sus servicios Cumplir con las regulaciones Prevenir el uso de su sistema en el ataque a otro sistema Minimizar la potencial exposición negativaSeguridad en sitios Página 38 de 48

Así mismo, la atención de un plan se debe centrar en los objetivos para manejar incidentes. Se identifica el siguiente conjunto:

Entender cómo ocurrió Encontrar la forma de evitar el aprovechamiento futuro de la misma vulnerabilidad Evitar una escalada y más incidentes Evaluar el impacto y daño de los incidentes Recuperarse del incidente Actualizar las políticas y procedimientos como sea necesario Encontrar quién hizo esto

Debido a la naturaleza de los incidentes, podría haber conflicto entre el analizar la fuente original del problema y recuperar el sistema y los servicios. Los objetivos globales (como asegurar la integridad de los sistemas críticos) deberían ser la razón para no analizar un incidente. Pero todas las partes involucradas, deben estar concientes que sin análisis, el problema podría repetirse.También es importante priorizar las acciones a tomar en un incidente. Aunque las prioridades varían de institución a institución, la siguiente lista de prioridades puede servir como punto de partida para definir la respuesta de una organización:

Prioridad Uno: Proteger la vida humana y la seguridad de las personas Prioridad Dos: Proteger datos sensibles o clasificados Prioridad Tres: Proteger otros datos incluyendo propietarios, científicos,

administrativos y otros datos, ya que la pérdida de datos es costosa en término de recursos.

Prioridad Cuatro: Prevenir el daño en los sistemas (ejemplo, pérdida o alteración del sistema de archivos, daño a los discos, etc.)

Prioridad Cinco: Minimizar la interrupción de los servicios computacionales.

5.2.- Notificación y puntos de contacto

Es necesario mantener varios contactos con el personal, antes que un incidente real ocurra. Muchas veces los incidentes no son emergencias reales y pueden ser manejados internamente.

Se deben especificar “puntos de contacto” para cada tipo de comunicación. Estos pueden ser técnicos o administrativos y pueden incluir agencias legales o de investigación, así como proveedores y vendedores de servicios. Una vez establecidos, se debe determinar cuánta información será compartida con cada clase de contacto, definiendo con quiénes se compartirá la información.

5.2.1.- Administradores y personal localSeguridad en sitios Página 39 de 48

Cuando un incidente está ocurriendo, un tema muy importante es decidir quién está a ca rgo de la coordinación de las actividades. Un gran error es tener un número de personas trabajando en forma independiente y en forma conjunta. Esto sólo agrega confusión y un esfuerzo inefectivo.Un individual “punto de contacto” puede o no ser la persona a cargo de manejar el incidente. En este caso se deben identificar dos roles: la person a cargo de manejar el incidente tomará decisiones tales como interpretar la política asociada al evento. En contraste, el “punto de contacto” debe coordinar el esfuerzo de todas las partes encargadas de manejar el evento.Otra importante función del POC (“punto de contacto”) es mantener contacto con el aspecto legal y agencias externas. Debe recolectar la evidencia siguiendo los procedimientos establecidos.

Una de las tareas más críticas del POC es la coordinación de todos los procesos relevantes. En incidentes complejos, se debe contar la participación de equipos encargados de dar las respuestas adecuadas.

El manejo de incidentes debe poseer algún mecanismo de escalamiento, para lo que se debe crear un esquema interno de clasificación de incidentes. Asociado a cada nivel de incidente, estará el apropiado POC y los procedimientos. Al escalar un incidente, pueden cambiar los procedimientos y el POC, lo cual debe ser comunicado a todos los involucrados.

Finalmente, los usuarios deben saber cómo reportar sospechas acerca del incidente.

5.2.2.- Esfuerzo legal y agencias de investigación

En el evento que un incidente tenga consecuencias legales, se debe establecer contacto con las agencias de investigación, lo más temprano posible. La policía y las oficinas de seguridad local deben ser informadas en forma apropiada.

Existen muchos asuntos legales y prácticos que considerar, algunos de los cuales son:

Si la organización corre el riesgo de publicidad negativa, al cooperar con el esfuerzo del investigación

Responsabilidad por daños a otro sistema, con ataque efectuado desde el sistema propio.

Distribución de información Responsabiliad debido al monitoreo

El balance entre soporte a la actividad investigativa y limitación de responsabilidad es difícil.


Finalmente, el consejo legal de la organización debería evaluar los procedimientos escritos del sitio, para responder a los incidentes.

5.2.3.- Equipo de manejo de incidentes de seguridad en computación

En el mundo existen algunos equipos preparados para responder a incidentes de seguridad en computación, tales como el CERT y el alemán DFN-CERT.Los equipos existen para las agencias gubernamentales y grandes corporaciones.De existir tales equipos, una de las primeras consideraciones que se debe tener es darles cuenta del incidente, apenas este comienza a ocurrir. Ellos son responsables de efectuar la coordinación adecuada sobre una gran cantidad de sitios.Si el incidente se origina en una falla de hardware, además se deberá comunicar del hecho al proveedor.

Al establecer una política de seguridad para manejo de incidentes, es deseable crear un subgrupo responsable de manejar los incidentes, el cual poseerá comunicación con otros equipos.

5.2.4.- Sitios afectados e involucrados

Si un incidente tiene impacto en otros sitios, es adecuado informales a ellos. Cada sitio puede elegir contactar al otro directamente o pasar la información adecuada al equipo de respuesta de incidentes.

Los asuntos legales y de responsabilidad, son diferentes para cada sitio y es adecuado definir políticas para compartir y loggear información con otros sitios, antes de que los incidentes ocurran. La transferencia de información debe considerar los aspectos legales y de seguridad.

5.2.5.- Comunicaciones internas

Es crucial durante un incidente, el comunicar por qué se toman ciertas medidas y cómo se espera que se comporten los usuarios. En particular, se debe ser muy claro en indicar qué es lo que los usuarios pueden y no pueden decir al mundo exterior (inclusive a otros departamentos de la organización).

Las comunicaciones con clientes y partner contractuales, deberán manejarse de una manera sensible.

Los departamentos de relaciones públicas, también deben ser involucrados en el plan de manejo de incidentes, para proporcionar respuestas adecuadas al exterior.


5.2.6.- Relaciones públicas – publicación en la prensa

Ha habido un gran desarrollo en la cantidad de medios de cobertura dedicados a los incidentes de seguridad computacional en USA. Los lectores de otros países pueden aprender de las experiencias en USA.

Uno de los asuntos más importantes a considerar es cuándo, quién y cuánta información entregar al público a través de la prensa.

Mientras sea difícil determinar por adelantado, qué nivel de detalle entregar a la prensa, algunos elementos a considerar son los siguientes:

Mantener el nivel de detalle técnico en un bajo perfil. Evitar la especulación en las declaraciones de prensa Trabajar con profesionales que den apoyo legal, para asegurar la protección de la

evidencia Intentar no forzar una entrevista de prensa, antes de prepararse No permitir la atención de la prensa a detractores del manejo del incidente

5.3.- Identificando un incidente

5.3.1.- ¿Es real?

Esta etapa considera determinar si el problema realmente existe. De hecho, muchas de las fallas atribuídas a infección por virus, ataque de intrusos, etc., son simples fallas del hardware o fallas en la manipulación de los usuarios del sistema.Para identificar si el problema es realmente un incidente, es útil cualquier software de detección disponible. La información auditada también es muy importante, especialmente para determinar si existe un ataque. Es importante obtener una foto del sistema, apenas se sospeche que algo anda mal. Finalmente es importante comenzar un libro de registros de eventos.

Existen ciertas indicaciones o síntomas que indican que un incidente merece especial atención:

Caída del sistema Nuevas cuentas de usuarios o repentina alta actividad en una cuenta con un bajo

uso Nuevos archivos o archivos con nombres extraños Discrepancia en las cuadraturas Cambios en longitud o fechas de archivos Intentos de escribir al sistema Modificación o borrado de datosSeguridad en sitios Página 42 de 48

Denegación de servicio Inexplicable baja perfomance del sistema Anomalías Indagaciones sospechosas Exámenes sospechosos Inhabilitación de un usuario para loggear, debido a modificaciones en su cuenta

5.3.2.- Tipos y alcances de los incidentes

Junto con la identificación del incidente, está la evaluación del alcance e impacto del problema. Es importante identificar correctamente los alcances del incidente, con el fin de tratarlo y priorizarlo en forma adecuada.

Para identificar el alcance e impacto, se debe definir un conjunto de criterios, acordes al sitio y al tipo de conexiones disponibles. Algunos consideran:

¿Es un incidente muli-sitio? ¿Están varios computadores del sitio afectados por este incidente? ¿Está involucrada información sensible? ¿Cuál es el punto de entrada del incidente (red, linea telefónica, terminal local,

etc.)? ¿Está la prensa involucrada? ¿Cuál es el daño potencial del incidente? ¿Cuál es el tiempo estimado para terminar con el incidente? ¿Qué recursos serían requeridos para manejar el incidente? ¿Está el aspecto legal involucrado?

5.3.3.- Evaluando la magnitud del daño

El análisis de la magnitud del daño puede consumir bastante tiempo, pero debería conducir al entendimiento de la naturaleza del incidente y ayudar a la investigación. Tan temprano como haya ocurrido el incidente, el sistema y todos sus componentes caen bajo sospecha. El software del sistema es el más probable objetivo. La preparación incluye el chequeo de todos los medios (comenzando con el sistema de archivos), usando algún algoritmo resistente al sabotaje.

Si el sistema soporta loggin centralizado, se debe recurrir a los logs y observar alguna anormalidad.

5.4.- Manejando un incidente

Ciertos pasos son necesarios de adoptar durante el manejo de un incidente. En todas las actividades relacionadas con la seguridad, lo más importante es conseguir que Seguridad en sitios Página 43 de 48

todos los sitios manejen políticas y objetivos de seguridad, los cuales deberían ser definidos con el apoyo de los administrador y asesoría legal.Uno de los objetivos fundamentales es restablecer el control de los sistemas afectados y limitar el impacto del daño.Dado que las actividades involucradas son complejas, se debe intentar obtener toda la ayuda necesaria.

5.4.1.- Tipos de notificación e intercambio de información

Al confirmarse la ocurrencia de un incidente, se debe comunicar al personal apropiado. Esta comunicación debe considerar el mayor detalle posible del problema, con el fin de ayudar a la comprensión y detección del problema.También se debe tener mucho cuidado en determinar a quienes se les proporcionará la información. Cualquier información, ya sea a personal local o externo debe ser explícita.Otras consideraciones importantes en la comunicación del problema son la veracidad de la información, la forma como la información es entregada (uso del lenguaje apropiado) y las diferencias culturales.

Si se involucra a un equipo de respuesta a los incidentes, es necesario que se complete una planilla con alguna información que permita actuar con certeza. La mínima información de esta planilla, sería:

Zona horaria del log Información acerca del sistema remoto, incluyendo nombres de hosts, direcciones

IP y tal vez identificaciones de usuarios. Todas las entradas relevantes del log, para el sitio remoto Tipo de incidente

5.4.2.- Protegiendo la evidencia y log de actividades

Cuando se responde a un incidente, se debe documentar en forma detallada todo lo relacionado con el incidente. Esto ayudará a tomar buenas decisiones y permitirá hacer una evlauación acabada del problema.Durante las etapas iniciales de un incidente, frecuentemente es infactible determinar si la prosecución es viable, por lo que se debería documentar los hechos, como si se fuera a presentar evidencia a una corte. Lo mínimo a considerar es:

Todos los eventos del sistema (registros de auditoría) Todas las acciones tomadas Todas las conversaciones externas (personas, fecha-hora y contenido)


La forma más adecuada es manteniendo un libro de registros. Mucha de esta información es potencial evidencia en caso de un problema legal. En este caso, se debería considerar:

Periódicamente activar el fotocopiado, firmando las copias del libro de registro para un custodio de la documentación

El custodio debe almacenar esas copias en un lugar seguro La recepción de la información a almacenar, debería ser firmada

5.4.3.- Contención

El propósito de la contención es limitar el alcance del ataque. Una parte fundamental es la toma de decisiones (por ejemplo, determinar si el sistema se baja, desconexión de la red, monitoreo del sistema o actividades de la red, etc.).Algunas veces esta toma de decisiones es trivial: bajar el sistema si la información es propietaria, clasificada o sensible.

La organización o sitio debería definir un riesgo aceptable en el manejo de un incidente y debería dictar acciones y estrategias específicas, acorde a ello.

Una actividad final de esta etapa es comunicar a las autoridades pertinentes.

5.4.4.- Erradicación

Una vez que un incidente ha sido contenido, es el momento de erradicar las causas.Antes de erradicar las causas, se debe tomar cuidado en recolectar información de los sistemas comprometidos y las causas del incidente.Se debe disponer de software que permita ayudar en el proceso de erradicación (por ejemplo antivirus).Eliminar las vulnerabilidades, una vez que un incidente ha ocurrido es difícil. La clave es reconocer y aprender de ellas.

En el peor de los casos puede ser necesario volver a personalizar el sistema. Para facilitar esta tarea, se debe mantener almacenada una copia del seteo del sistema original y cada cambio que haya ocurrido.

En el caso de un ataque a través de la red, es preciso instalar parches para cada vulnerabilidad del sistema operativo.

Como se dijo anteriormente, un registro de seguridad puede ser muy valioso durante la etapa de eliminar las vulnerabilidades.


Si se ha conseguido aislar una vulnerabilidad, el siguiente paso es encontrar un mecanismo para proteger el sistema.

5.4.5.- Recuperación

Una vez que un incidente ha sido erradicado, la siguiente fase es la recuperación. Esto significa retornar el sistema a la normalidad.En general, se debería cargar los servicios en función de su demanda. Aprender que los procedimientos de recuperación para el sistema son extremadamente importantes y deberían ser específicos para el sitio.

5.4.5.- Pasar a la siguiente etapa

Una vez que el sistema ha retornado a un estado "seguro", es posible que aún permanezcan algunos problemas en él. Una de las etapas más importantes de respuesta a los incidentes es también la más frecuentemente omitida: la etapa siguiente. En esta etapa, el sistema debe ser monitoreado por aquellos itemes que han desaparecido durante la etapa de limpieza.

El elemento más importante de esta etapa es ejecutar el análisis post-mortem. Exactamente qué ha ocurrido y en qué momento. Cuán bien se involucró el staff en el manejo del incidente. Qué tipo de información fue requerida en abundancia y cómo poder llegar a ella de una manera más rápida. Qué debería hacer diferente el staff, la próxima vez.

Después del incidente, es preciso escribir un reporte con la exacta secuencia de los eventos: el método empleado para descubrir el problema, los procedimientos de corrección, procedimientos de monitoreo y un resumen de las lecciones aprendidas. Esto ayudará a clarificar la comprensión del problema.

5.5.- Consecuencias de un incidente

En la ruta de un incidente, tienen lugar varias acciones. Ellas se pueden resumir en lo siguiente:

Se debería tener un inventario de los recursos del sistema Las lecciones aprendidas de un incidente, deberían ser incluídas en el plan de

seguridad, para evitar repetir su ocurrencia Un nuevo análisis de riesgos se debe desarrollar, a la luz del incidente Si se estima necesario, debe comenzar una investigación persecución de los

individuos causantes del incidente


5.6.- Responsabilidades

5.6.1.- No cruzar la linea

Una cosa es proteger su propia red, pero otra muy diferente es asumir que se debe proteger otras redes.Durante el manejo de un incidente, ciertas vulnerabilidades de los sistemas propios y de otros, comienzan a aparecer. Es fácil y tentador perseguir a los intrusos a través de los sistemas, siguiendo sus pistas. Pero se debe considerar que en cierto punto, el cruzar la linea, aún con la mejor de las intenciones, convierte en intruso al que lo hace.

La mejor regla es no utilizar facilidades de sitios remotos que no sean públicos. Para sitios no propios, se debe contactar a sus respectivos puntos de contacto.

5.6.2.- Buen ciudadano de Internet

Durante un incidente de seguridad, existen dos elecciones que uno puede hacer.Primero, un sitio puede elegir observar a un intruso y esperar atraparlo o el sitio puede hacer limpieza después del incidente y excluir al intruso del sistema. Esta es una decisión que se debe tomar en forma meditada, debido a las responsabilidades legales de mantener un sitio abierto, conociendo que está siendo utilizado por un intruso para lanzar ataques a otros sitios.Ser un buen ciudadano de Internet significa que se debe advertir a los otros sitios que pueden ser atacados por un intruso.

5.6.3.- Respuesta administrativa a los incidentes

Cuando un incidente de seguridad involucra a un usuario, la política de seguridad del sitio debe indicar que acción tomar. La transgresión debe ser considerado un hecho grave, pero es muy importante determinar el rol que jugó el individuo. ¿Era el usuario un ingenuo?. ¿Podría haber una equivocación en atribuir el problema de seguridad al usuario?El aplicar acciones administrativas que asumen intencionalidad, puede no ser apropiado para un usuario que simplemente hizo algo equivocado. En este caso es más adecuado imponer sanciones más acordes, como reprimenda y educación.

6.- CONTINUACIÓN DE LAS ACTIVIDADES6.- CONTINUACIÓN DE LAS ACTIVIDADES


En este punto, el sitio posee una robusta y completa política de seguridad y ha desarrollado los procedimientos para asistir en configuración y administración de la tecnología, de acuerdo a esas políticas.Al encontrarse los sistemas y redes en un ambiente estático, se requerirá la revisión permanente de las políticas y procedimientos.Existen algunos pasos que se pueden ejecutar, para ayudar a mantener estos cambios:

Suscribirse a aquellos agents de equipos de respuesta de incidentes, tales como Centro de Coordinación CERT y actualizar el sistema contra las amenazas que se aplican al sitio tecnológico

Monitorear los parches de seguridad producidos por los proveedores del equipamiento

Observar activamente las configuraciones del sistema, para identificar cambios que puedan ocurrir e investigar las anomalías

Revisar todas las políticas de seguridad y los procedimientos anualmente (por lo menos)

Leer listas de correo relevantes y el USENET, para mantenerse actualizado con la última información

Chequear regularmente el cumplimiento de las políticas y procedimientos. Esta auditoría debe ser ejecutada por alguna persona distinta de quien define o implementa las políticas y procedimientos

7.- CONCLUSIONES7.- CONCLUSIONES

Como conclusiones, se puede rescatar la importancia de contar con una adecuada política de seguridad en sitios, junto con los procedimientos para cada uno de los casos. Estas políticas y procedimientos deben ser acatados por personal competente, que garantice su utilidad.

Esta política exige un fuerte compromiso de los más altos niveles de la organización, para poder así materializarla.

Las organizaciones modernas, deben comprender la relevancia de un recurso que ha pasado a constituírse en uno de los más importantes: la información. De su adecuada administración y protección, depende gran parte de la sobrevivencia de la organización.


rfc 2196 - udecar-sc/arq-m-2001-1/brevis3.doc · web viewlos servicios tienden a viajar como ondas...

Documents