| Inicio | Noticias | Comunicados | Mapa de sitio | RSS |
|
Seguridad de un servidor web Haga público su servidor web mientras que lo mantiene seguro... Por: Sean-Philip Oriyano, consultor independiente. Los servidores web son una de las muchas caras públicas de una organización y por lo tanto son potencialmente un blanco fácil. Como recurso público, un servidor web es como un “cebo de tiburón” para algunos. Pero no tiene que ser así. Aprenda como un servidor web puede ser público y estar blindado al mismo tiempo. Los servidores web representan una paradoja interesante, ¿Cómo compartir la información de su organización sin sacrificar el -así llamado- almacenamiento? Solucionar este dilema es un trabajo arduo y poco agradecido; pero es también uno de los más importantes. Antes de avanzar en el tema, veamos algunas de las amenazas que su servidor puede enfrentar en virtud de estar en el "frente de batalla". AMENAZAS CONTRA LOS SERVIDORES WEB
Hoy día, hay un enorme número de amenazas a las que hace frente a un servidor web, muchas de ellas dependen del uso, el sistema operativo y el ambiente que se haya configurado en el sistema mismo. Estos son algunos de los ataques más genéricos que su "pobre" servidor puede enfrentar. ° Negación del servicio Un ataque por negación del servicio (DOS) es uno de los ataques de la “viejo-escuela” que el servidor puede enfrentar. El ataque es muy simple, y hoy en día es realizado por aquellos individuos conocidos comúnmente como script kiddies, con un perfil de habilidades técnicas bajo. En resumen, un ataque DOS es un ataque en el cual un sistema ataca otro con la intención de consumir todos los recursos del sistema (tales como ancho de banda o ciclos del procesador), no dejando nada libre para peticiones legítimas. Generalmente, estos ataques se han relegado a la categoría de molestias, pero no por ello hay razón para bajar la guardia ante ellos, aunque hay un montón de cosas más para mantenerse despierto. ° Negación del servicio distribuida El ataque por negación del servicio distribuido (DDoS) es el hermano mayor del ataque DOS y como tal es más malo y más sucio. La meta del ataque DDoS es hacer la misma cosa que el DOS, pero a una escala mucho más grande y compleja. En un ataque de DDoS, en vez de un sistema ataque a otro, un atacante utiliza sistemas múltiples para apuntar un servidor (su servidor), y sistemas múltiples significa (en algunos casos) no centenares o millares, sino hasta cientos de millares. Donde el ataque DOS es tan solo una molestia, un ataque de DDoS puede ser mortal, ya que puede llevar a un servidor fuera de línea rápidamente. La buena noticia es que el nivel de habilidad requerido para contrarestar un ataque DDoS apagado no es tan alto. ° Algunos de los ataques mas comunes de DDoS incluyen:
La desconfiguración de la página web ocurre de vez en cuando. Como su nombre lo indica, este ataque resulta de una desconfiguración del sitio, cuando un servidor está incorrectamente configurado, y un atacante utiliza esta debilidad para modificar páginas bajo cualquier cantidad de razones, por ejemplo la diversión o promover una causa política. ° Inyección SQL Inyecciones SQL (lenguaje de consulta estructurada), son los ataques realizados contra bases de datos. En este caso, un atacante utiliza debilidades en el diseño de la base de datos o de la página web para extraer información o más aún, para manipular información dentro de la base de datos. Aunque no es posible en este caso ser más específicos respecto a cómo quitar este tipo de ataque, usted puede evitarlo si tiene conocimientos de SQL, los cuales debería tener -si está hospedando una base de datos en su servidor web-. ° Codificación pobre Cualquier persona que ha sido desarrollador o ha trabajado en tecnologías de la información ha visto los problemas asociados a prácticas descuidadas o perezosas en la codificación. Una pobre codificación puede generar un gran número de factores, incluyendo un pobre entrenamiento, nuevos desarrollos, o una escasa garantía de calidad para una aplicación. En el mejor de los casos, una codificación pobre puede ser no mas que una molestia, donde las funcionalidades de una aplicación no trabajen según lo anunciado; pero en el peor de los casos, las aplicaciones pobremente codificadas pueden tener "agujeros" de seguridad importantes. ° Códigos empaquetado (Shrink-wrapped code) Este problema se relaciona con los anteriores casos de codificación pobre, pero con una diferencia: Básicamente, el problema proviene de la conveniencia de obtener componentes precompilados o desarrollados de antemano, que se pueden utilizar como bloques para construir aplicaciones propias. Su desventaja es que los componentes utilizados pueden no haber pasado un proceso de revisión de su código -tal como el que usted haría-, y su uso puede crear problemas potenciales. Adicionalmente, no es extraño escuchar por parte de los desarrolladores que realmente "no saben como analizar el código y entender totalmente lo que está haciendo" como para saber poner en uso componentes “empaquetados”. En al menos un caso puedo pensarlo. Estoy enterado de un revelador caso en el que usando un bloque del código empaquetado para proporcionar un mecanismo de autentificación -para una aplicación que autentificaba usuarios reales-, también se enviaban electrónicamente las mismas credenciales de manera secreta a una tercera persona. EN LOS TERRAPLENES
Autorización, ahora que le he asustado a fondo sobre qué clases de amenazas están hacia fuera allí, Hecharé una ojeada cómo usted puede protegerse contra daño. Primero, déjeme detallar mi plan del seis-punto para los servidores de protección del Web: 1. Servidores separados del Web para el uso interno y externo. Esto suena como un ningún-brainer, pero él todavía lleva el repetir. La mayoría de las organizaciones tienen usos Tela-basados o sitios usados internamente, así como usos y los sitios utilizaron externamente. En una situación ideal, estos dos sistemas de servidores y contente debe ser mantenido separado, con los sitios internos y externos teniendo sus propios servidores con como poca cruce entre ellos como posible. Partiendo sistemas aparte tenga gusto de esto, usted evitan la probabilidad (o por lo menos disminuya el riesgo) de un atacante que practica una abertura un servidor y conseguir el acceso a los datos o aún a los sistemas internos. 2. Servidores separados del desarrollo y de la producción. En mi tiempo, tengo sabido varias compañías que han violado esta regla dejando su trabajo del equipo del desarrollo sobre los servidores de la producción para desarrollar su código o código existente del pellizco retorcido. Típicamente, esto es justo un caso del extremo holgazanería-uno que puede conducir a los problemas catastróficos más adelante cuando un atacante ve su código sin pulir y lo explota a su poseer extremos. También, considere que sus propios reveladores pueden comprometerse seguridad por código de prueba y que pellizca. Hágase un favor: Instrumento un ambiente del desarrollo. 3. Intervenciones regulares. Cualquier uso del web server o del Web digno de su sal tendrá cierto método de generar registros de la actividad en el sistema. Después de que se registre esta información, hágale la parte de su rutina regular para explorar los registros para los problemas, tales como faltas del uso o sospechoso actividad. Tenga presente que un registro de la intervención es como la evidencia recogida en una escena de crimen: Es esencialmente sin valor a menos que usted se preponga examinar él más adelante. 4. Mantenga su sistema actualizado. Realmente necesito pasar con esto ¿uno? Sí. Remendar un sistema es un problema a menudo-pasado por alto cuando realmente no debe estar. Idealmente, usted debe vigilar si los remiendos, los paquetes del servicio, las actualizaciones, u otros artículos llegan a estar disponibles que puede ayudar asegure su sistema. Dependiendo de su plataforma de recibimiento y otros factores, usted puede tener la opción del tener estas actualizaciones entregado automáticamente, o usted puede tener que utilizar el manual pasado de moda método de la entrega. También tenga presente que muchas veces, actualizaciones son solamente la manera de fijar problemas tales como ésos se relacionó con los desbordamientos del almacenador intermediario, red ediciones del cliente, y así sucesivamente. 5. Exploración de la vulnerabilidad. En artículos anteriores (véase Recursos), cubrí el asunto de exploración de la vulnerabilidad como herramienta para encontrar problemas en su recibimiento y infraestructura del uso. La exploración de la vulnerabilidad puede ser una muy de gran alcance herramienta en la lucha en curso para destapar problemas referente a software, por ejemplo la configuración y ediciones que remiendan. Otra ventaja es ésa estas herramientas de la exploración se ponen al día regularmente, así que usted puede utilizarlas para encontrar los problemas más últimos que, en un número de casos, incluyen las ediciones que usted no puede incluso estar enterado de, permitiendo que usted las trate antes de que puedan explótese. Herramientas tales como el freeware Nessus (véase Recursos) puede ser un gran activo a los administradores sin importar si usted recibe en Linux®, UNIX®, o una cierta otra plataforma. 6. Entrenamiento del revelador. Éste puede ser un pedacito más difícil de quitar, pero cosecha una enorme recompensa, si está emprendido. Educar los reveladores en la codificación segura las prácticas pueden dar lugar a la eliminación o a la reducción de los problemas asociados a la codificación descuidada o perezosa. OTROS DETALLES
Aparte de estos seis puntos, hay un montón de cosas más que usted puede hacer para mejorar seguridad en la estructura del "hosting" de su organización. Echemos una mirada a algunas de las cosas que tienden a causar problemas y como pueden ser tratadas. ° Mala configuración Mientras el hardware y el software se hacen más complejos y los equipos de IT se reducen, el potencial para tener el tema bajo radar, crece. Afortunadamente, usando exploradores de la vulnerabilidades, escaneos automatizados, educación llana y simple y la teniendo la diligencia debida se pueden reducir problemas del mala configuración. ° Banderas de Información Las banderas de información pueden revelar información a aquellos que saben que la información está ahí y decirles cómo buscarla. Tales banderas pueden revelar información como los datos de la versión, mismos que pueden ayudar a un atacante. "HTTP/1.1 200 OK Server: Content-Location: http://w.x.y.z/index.htm Date: Thu, 1 Jan 2009 14:03:52 GMT Content-Type: text/html Accept-Ranges: bytes Last-Modified: Wed, 31 Dec 2008 18:56:06 GMT ETag: "067d136a639be1:15b6" Content-Length: 4325 Por ejemplo, cuando hace una petición a un servidor web para solicitar un contenido estático, como un archivo básico .html o .htm, algo conocido como el "content location header" se anexa a lA respuesta. En la configuración de default, de algunos servidores web, header referirá a la dirección IP y puede o no proporcionar el nombre de dominiop completo (Fully Qualified Domain Name -FQDN-). En el peor panorama, el header podía revelar direcciones IP internas junto con otros datos. Echemos una ojeada el header siguiente. Este header revela que un poquito acerca de su servidor, pero no tema: Los servidores web pueden comunmente tener esta información a salvo o modificarla al gusto de su organización. (Consulte la documentación de su web server para más información.) ° Permisos Los permisos todavía tienden para ser un problema en algunos círculos. A menudo, están incorrectamente asignados o planeado incorrectamente, permitiendo a los individuos el acceso a las partes o aplicaciones del servidor que no debieran. Compruebe siempre para estar seguro de que los que manejan e interactúan con su servidor tienen los permisos apropiados para hacer lo que necesitan y no más: Esto también se conoce como privilegios mínimos (least privilege). ° Mensajes de error Todos hemos obtenido el temido mensaje 404 o alguno de sus primos de vez en vez, diciéndonos que la información que buscamos no se puede encontrar o ha sido una víctima de cierto tipo de falla. Pero estos mensajes de error podrían revelar mucho más si se mira más de cerca. Para un hacker, cualquier mensaje de error que su servidor genera puede revelar información sobre como están configuradas sus aplicaciones, qué bibliotecas utiliza, sus conexiones a la base de datos y otras muchas cosas. Afortunadamente esto no tiene que ser así. Utilize todos los mensajes de error a su favor duramte las pruebas y el desarrollo para ayudarse a "cachar" fallas. Pero cuando libere su aplicación o servidor web a producción, los mensajes de error deben ser deshabilitados o configurados para revelar sólo información muy genérica. (Consulte la documentación de su web server para saber como hacer esto.) ° Servicios Al construir un sistema para hospedar su servidor web y aplicaciones, planee cuidadosamente qué características y funcionalidades necesita, y después construya el servidor para cumplir esa meta. Básicamente, cuando resuelva lo que su servidor hará, habilite solo aquellos servicios y funcionalidades para soportar el rol y remueva o deshabilite aquellas que no sean necesarias para el ambiente. Tenga en mente que cualquier otro servico o funcionalidad presente y habilitada es justo otro potencial agujero que un atacante puede explotar. ° Protocolos De nuevo, tal como en los servicios, cualquier protocolo -tal como NetBIOS- que no necesite debe inhabilitado o francamente removido. ° Cuentas de usuario No es poco común para sistemas operativos y aplicaciones, tener cuentas de usuario por defecto desde el momento de su instalación. Para estar seguros esto es algo a lo que se debe prestar atención. Establezca un punto de verificación sobre las cuentas presentes, inhabilitando o quitan las que no necesita, y fortaleciendo (y cambiando) las contraseñas de las que si necesita. ° Muestras y archivos de prueba No es extraño para algunos servidores y aplicaciones web incluir archivos de muestra y componentes de prueba para mostrar lo que se puede hacer con el producto. En un ambiente seguro, estos archivos debe ser eliminados de los servidores y aplicaciones web en producción, ya que pueden ser manipulados y permitir accesos no autorizados. ° Puertos Revise que puertos requieren su servidor web y aplicaciones para funcionar, permita (y monitoree) esos puertos. De hecho, los puertos que no esté utilizando deben ser cerrados y bloqueado por un Firewall. OTRAS MEDIDAS DE PROTECCIÓN
Hay otros artículos cuya utilización puede considerar para fortalecer su ambiente de hosting: * sistemas de la Intrusión-detección (anfitrión y red-basado). Estos sistemas son los dispositivos del hardware o del software que pueden ayudarle a supervisar el acceso a través la red a y desde su servidor así como actividad en el servidor sí mismo. * Software de Antivirus. Oui, vous devriez avoir un sur votre web server. * Cortafuegos. El un montón de cortafuegos está disponible: Elija el eso los mejores ajustes sus necesidades, y lo despliegan delante de su web server. * Sentido común. Sí, tuve que agregar éste. En la década pasada, cuando el Internet hacía su manera en nuestro diario vivir-amba en el personal y en la idea de los mundos- del negocio estaba a consiga lo que usted podría en el Internet, porque era la cosa a hacer. Como resultado de este “Zerg acometa” para conseguir en el Internet rápidamente hacer a el chapoteo grande antes de sus competidores, muchos de información fue puesto hacia fuera allí eso nunca debe haber estado. Recuerde, no todo necesita para estar en el Internet. También, tenga presente que si usted puso algo encendido el Internet, usted bonito no puede poner mucho el genie detrás en la botella más adelante. ¿No convencido? Heche una ojeada www.archive.org y vea lo que ha tenido su Web site o los de sus competidores encima los últimos 10 años. CONCLUSIÓN
Asegurar un servidor web server y las aplicaciones que hospeda es de hecho una tarea desalentadora, pero no imposible. Con una cierta investigación y una buena dosis de trabajo duro (y quizá algunas noches con un poco de café), usted puede hacer su ambiente de hosting mucho más fuerte y evitarse algunos dolores de cabeza a largo plazo. RECURSOS
Aprenda: * Obtenga las últimas noticias e información sobre seguridad en securityfocus.com. * Instituto de SANS es su tienda one-stop para la seguridad información, programas de la certificación, e investigación. * Aprenda más sobre la exploración de vulnerabilidades dentro del artículo "developerWorks" de Sean-Philip Oriyano, Anatomía de un ataque Web(Feb de 2009). * La zona de desarrollo web de developerWorks contiene herramientas e información para el desarrollo Web 2.0. * Eventos técnicos y webcasts de IBM: Esté actualizado sobre "developerWorks" sus acontecimientos técnicos y webcasts. Consiga los productos y las tecnologías: * El explorador de vulnerabilidades Nessus, proporciona varias características de exploración, por ejemplo exploración de alta velocidad, perfiles y análisis de vulnerabilidades. Sobre el autor: Sean-Philip Oriyano ha estado trabajando activamente en campo desde 1990. A través de su carrera ha alcanzado posiciones como especialista de soporte a consultores e instructor senior. Actualmente, es instructor de IT especializado en infraestructura y asuntos de seguridad para varias empresas públicas y privadas. Sean ha dado cursos a la Fuerza Aérea, la Marina, y el Ejército de los Estados Unidos en Norteamérica e internacionalmente. Sean está certificado como CISSP, CHFI, CEH, CEI, CNDA, SCNP, SCPI, MCT, MCSE, y MCITP, y es miembro del EC-Council, ISSA, Elearning Guild, e Infragard. Puede contactar a Sean en Esta dirección electrónica esta protegida contra spam bots. Necesita activar JavaScript para visualizarla . Traducción: SIP Ver nota original en inglés. |
| Última actualización el Viernes, 10 de Julio de 2009 14:08 |