ENTRAR EN EL FOROHACK ANTIGUO (Muchos temas viejos y de menor nivel)
00:06:09 22/11/2019
æNo estas registrado?
Login: Clave:
7 Usuarios en lķnea: 0 registrados, 7 invitados.
Conéctate y verįs los usuarios en lķnea
Tema: Ataques a Proxies Reversos
    Responder
Todos Los Foros -> Hacking General -> Ataques a Proxies Reversos
Autor Mensaje (Ver Versión para Imprimir)
ambu
Aprendiz nivel 1
Arreglando las imįgenes

Mensajes: 37
Registrad@:
29/07/2008
Estado: Desconectad@
Ver śltimo Post
Ataques a Proxies Reversos

El Reverse Proxy surgiŪ como una nueva alternativa tecnolŪgica para poder satisfacer algunas necesidades fundamentales en las redes de computadores. Por medio del Reverse Proxy se tiene una puerta idealmente ?nica de entrada a la red, proporcionando seguridad, facilidad de acceso y control en la informaciŪn que entra y sale de la red. El proxy correctamente configurado, y algunas veces en conjunto con uno o dos firewalls que lo encierran, ha brindado una arquitectura de red bastante eficiente en la actualidad en cuanto a la seguridad y unificaciŪn de servicios para el cliente. Por todas estas razones el proxyse ha convertido en un blanco significativo de ataques en las redes, y es Čste el tema central de este documento.

II. QU… ES UN REVERSE PROXY?

Un ReverseProxy es un intermediario entre una red p?blica y un conjunto de servidores privados; el cual se encarga de administrar las solicitudes de servicios por parte de uno o varios computadores externos. Estos funcionan manipulando los requerimientos HTTP que son enviados por varios computadores; en un proceso en cual se atienden las solicitudes y al mismo tiempo manipulan la presentaciŪn de estos servicios para evitar comprometer informaciŪn crĢtica del grupo de servidores privados a donde se solicitan.

III. DE QU… SE COMPONE UN REVERSE PROXY?

      * Servidor Proxy: Es el encargado de administrar todas las solicitudes HTTP que se realizan por parte del cliente. Generalmente cuenta con un mecanismo de cache; en el cual se procesan solicitudes sin necesidad de enviarlas a los Servidores de contenido; lo que hace que se generen respuestas m·s r·pidas. El mecanismo de cache trabaja en conjunto con un mecanismo de balanceo de carga, el cual distribuye las solicitudes entre los diferentes servidores de contenido para evitar congestionamiento y demora en las respuestas a las solicitudes.

      * Servidores de contenido: Son los que atienden las solicitudes de HTTP que son enviadas por los clientes. Estos son los tienen toda la informaciŪn critica de la organizaciŪn o empresa como las bases de datos, sistemas de informaciŪn, etc. Generalmente est·n protegidos por un firewall el cual filtra la informaciŪn que viene del Servidor Proxy.

      * Cliente: Es el que constantemente esta haciČndole solicitudes HTTP a un Servidor. Generalmente existen tres tipos de clientes: los empleados, los cuales trabajan para la organizaciŪn; la cual tiene todos sus servicios y aplicaciones en los diferentes Servidores de contenido; los External Bussiness Partners (EBN), los cuales son personas o instituciones vinculadas a la organizaciŪn, pero no necesariamente hacen parte de ella; y por ?ltimo encontramos los tipos de clientes que no hacen parte activa de la empresa, pero tienen acceso a algunas de sus aplicaciones y servicios.

      * Firewall: Es el que se encarga de filtrar las solicitudes por parte de un cliente. …ste se puede ubicar en diferentes puntos para aumentar el grado de seguridad de los Servidores de contenido. No necesariamente todas las topologĢas utilizan los firewalls para manejar la seguridad de conjunto de servidores.




Imagen 1: Arquitectura de una Arquitectura de ReverseProxy *

IV. C”MO FUNCIONA UN REVERSE PROXY?

El cliente realiza una peticiŪn HTTP

Cualquier tipo de cliente de los anteriores ya mencionados, est· en posiciŪn de solicitar un servicio; esta se realiza utilizando el protocolo SSL (Secure Socket Layer) para aumentar el grado de seguridad una vez se establece un canal de comunicaciŪn entre el cliente y el Servidor Proxy (Imagen 2).


Imagen 2: El cliente realiza una peticiŪn http*

El cliente es autenticado por el Servidor Proxy

La autenticaciŪn en un Proxy Reverso se da cuando un cliente de cualquier tipo realiza una solicitud de servicio; la cual es procesada por el Servidor Proxy. Para validar que el cliente es un tipo de usuario valido, la validaciŪn se puede clasificar en varios tipos seg?n el modo o el escenario; los cuales ser·n explicados mas adelante.

La solicitud es enviada y procesada por los Servidores de contenido

Una vez la solicitud se encuentra en el Servidor Proxy; este determina si el recurso solicitado se puede obtener del cache para evitar tener que procesar la solicitud hasta el servidor de contenido (Imagen 3). La solicitud que viene desde el cliente se realiza mediante un URL relativo; es decir;   un servicio cuya ubicaciŪn real sŪlo se puede resolver por el Servidor Proxy; asĢ que una vez determinada la direcciŪn real, esta es enviada para que el Servidor de contenido la pueda procesar.



Imagen 3: La solicitud es enviada y procesada por los Servidores de Contenido*

Con el fin de obtener eficiencia y buen desempeŅo, el Servidor Proxy realiza un balance de carga enviando la solicitud hacia el Servidor o Servidores de contenido que estČn menos ocupados atendiendo otras solicitudes mediante el mČtodo de round robin o cola de espera; de esta manera se garantiza un mejor uso de los canales y Servidores en la red. Una vez esta llega al Servidor de Contenido se establece un canal de comunicaciŪn en el cual solo se abren los puertos que se necesiten para dicha solicitud.

La respuesta es recibida y procesada por el Servidor Proxy

Una vez establecido el canal, el Servidor de Contenido se encarga de atender la solicitud y devolver la respuesta hacia el Servidor Proxy (Imagen 4).



Imagen 4: La respuesta es recibiday procesada por el Servidor Proxy*

Si en un principio la solicitud no es valida; el Servidor Proxy se encarga de redireccionar al cliente hacia una p·gina de error que puede ser configurada por el administrador del sistema de acuerdo a las necesidades de la organizaciŪn o empresa. En caso de que la solicitud sea v·lida, el Servidor Proxy envĢa la respuesta hacia el cliente con una direcciŪn relativa del Servidor de Contenido que esta enviando la respuesta; con el fin de prevenir intrusiones, ataques o flujo de informaciŪn indeseada hacia el mismo.

A continuaciŪnse explica el mecanismo mediante el cual una topologĢa de Reverse Proxies, maneja el enmascaramiento de direcciones para evitar comprometer la integridad de los Servidores de Contenido a los cuales llegan las solicitudes.

V. MAPEO DE DIRECCIONES

Esta topologĢa tiene como objetivo que todos los Servidores de Contenido sean invisibles para el cliente; razŪn por lacual es el Servidor Proxy el que se encarga de procesarlas cuando es el caso y enrutarlas a los diferentes destinos.

Con el fin de que un Proxy Reverso funcione debe ser configurado para redireccionar tanto las solicitudes como las respuestas de los clientes y los Servidores de Contenido por medio de un sistema de tablas internas. Estas tablas contienen toda la informaciŪn de los URLs; los cuales pueden ser reales o relativos; y que permiten enviar las solicitudes y respuestas a sus respectivos destinos. Estas tablas solo pueden ser acezadas por el Reverse Proxy; el cual puede modificarlas a su gusto seg?n las polĢticas y reglas de seguridad que se deseen implementar para filtrar las solicitudes HTTP. Las direcciones reales son las que est·n previamente asignadas a los diferentes Servidores de Contenido tanto como al Servidor Proxy; y por otro lado, las direcciones relativas son las que se muestran a los clientes para no comprometer los Servidores de Contenido. Generalmente estas ?ltimas deben ser configuradas en el Servidor Proxy para que este pueda realizar el proceso de atenciŪn de requerimientos de tal forma que se eviten al m·ximo problemas de intrusiŪn o perdida de informaciŪn critica.

El proceso mediante el cual se procesan las solicitudes HTTP de los clientes, por parte del Servidor Proxy hacia el Servidor de Contenido se conoce como ģmapeoregularī. En este proceso el Servidor Proxy se encarga de redireccionar la solicitud hacia el Servidor de Contenido de tal manera que se le pueda indicar a este ?ltimo donde se puede obtener el recurso solicitado.

En el caso en que el Servidor Proxy redirecciona la respuesta de el Servidor de Contenido hacia el cliente; este proceso es conocido como ģmapeo reversoī. En este punto el Servidor Proxy se encarga de enviar la respuesta solicitada, de tal manera que el URL que la identifica no comprometa la integridad del Servidor de Contenido que la generŪ.

El sistema de tablas interno contiene toda la informaciŪn relacionada con los URL reales y como se relacionan con los URL relativos; para que se establezcan patrones mediante los cuales siempre que se haga una solicitud de cierto tipo, o una respuesta de alguna clase en particular; el Servidor Proxy pueda procesarla y de acuerdo con estos patrones mostrar un tipo de URL.

En el siguiente ejemplo se explica como funciona este proceso:

Inicialmente contamos con una topologĢade tipo Proxy Reverso en la cual encontramos los siguientes equipos con las respectivas direcciones IP:

ø Cliente: 169.254.63.118

ø Servidor Proxy: 169.254.63.119

ø Servidor de Contenido:169.254.63.120

ø Servidor de Contenido2:169.254.63.121

El Servidor Proxy tiene configurado en sus sistema de tablas las siguientes relaciones:

Rol
   

DirecciŪn Real
   

DirecciŪn Relativa

Cliente
   

http://169.254.63.118
   

http://www.cliente.com

Proxy Reverso
   

http:// 169.254.63.119
   

http:// 169.254.63.119

Servidor Web 1
   

http://169.254.63.120
   

/contenido1/

Servidor Web 2
   

http://169.254.63.121
   

/contenido2/

Esta es una de la muchas posibles configuraciones que se pueden realizar en el Servidor Proxy. Para este caso en particular; el Servidor Proxy se identifica por la direcciŪn http:// 169.254.63.119; a la cual llegan todas las solicitudes del cliente. Si Čste ?ltimo necesita un servicio del primer Servidor Web; este es solicitado como http://169.254.63.119/contenido1/; y asĢ mismo para el otro servidor como http://169.254.63.119/contenido2/. De esta forma queda ilustrado el proceso mediante el cual se atienden las solicitudes a los Servidores Web con direcciones http://169.254.63.120y http://169.254.63.121; aunque sus URL solo sean transparentes para el ServidorProxy.

A continuaciŪn se explica como es el proceso de autenticaciŪn; el cuales un paso fundamental para poder establecer una conexiŪn entre el Servidor Proxy, el Servidor de Contenido y el cliente.

VI.AUTENTICACI”N

AsĢ como un Proxy Reverso puede ser usado para acelerar el acceso de las transacciones provenientes de Internet a uno de los servidores de una red privada (m·s adelante se ver· este punto m·s profundamente en balanceo de carga); por medio la utilizaciŪn del cachČ del mismo y de distribuciones de Proxies Reversos que facilitan el acceso a la informaciŪn; tambiČn pueden ser utilizados como un medio extra de seguridad, dependiendo del uso que se le quiera dar.

Dependiendo del tipo de informaciŪn que se le quiera solicitar al usuario, existen dos tipos de autenticaciŪn para servidores Proxyreversos:

      * AutenticaciŪn fuerte: se necesita un ID del usuario, pin y tarjeta de autenticaciŪn de 2 factores. Este tipo de autenticaciŪn es usado para un uso interno de la red, para controlar acceso en los sitios Web de la Intranet. Este modo de autenticaciŪn es propicio para uso dentro de una compaŅĢa, ya que con este mecanismo, los empleados autorizados pueden ser suministrados por una tarjeta que les de acceso a informaciŪn confidencial Ū asitios Web restringidos.

      * AutenticaciŪn Suave: se necesita un id del usuario y un password. Este modo de autenticaciŪn se usa para acceder a contenido Web o a aplicaciones que se encuentran inmersas en la Intranet. Estas solicitudes provienen en su mayorĢa de Internet. Estos accesos a la subred se encuentran en las listas de acceso que posee el servidor Proxy Reverso.

Seg?n el tipo de   escenario; el Proxy Reverso se puede clasificar como:

?            El cliente se autenticamediante una conexiŪn segura contra el ServidorProxy

?            El servidor Proxy se autentica mediante una conexiŪn segura contra el Servidorde Contenido

?            El cliente se autenticamediante una conexiŪn segura contra el ServidorProxy, y este contra el Servidor de Contenido

Para poder clasificar la validaciŪn por tipo de escenario; es necesario tener en cuenta que las topologĢas donde seutiliza la tecnologĢa de Proxies Reversos, generalmente hacen uso de firewalls; los cuales est·n localizados en diferentes puntos a los largo de la red, seg?n las necesidades de la organizaciŪn o la empresa.

En el primer escenario se utiliza cuando existe poco riesgo de que la informaciŪn entre el Servidor Proxyy el Servidor de Contenido pueda ser comprometida. Por eso sŪlo es necesario autenticar hacia el lado del cliente; con el fin de tener una conexiŪn en tČrminos de un usuario autorizado. El segundo escenario se da cuando existen clientes dentro de un firewall y solicitan un recurso a un servidor que esta por fuera de este. El tercer escenario garantiza un nivel de seguridad m·s alto; ya que existe la autenticaciŪn entre los tres puntos de comunicaciŪn; generando un canal seguro de transmisiŪn de datos a la vez que se utiliza la autenticaciŪn de usuarios autorizados.

Al final del proceso de autenticaciŪn queda abierto un canal de comunicaciŪn entre el cliente y el Servidor Proxy.

Fuera de estas formas de autenticaciŪn por tipo de ingreso de datos, tambiČn existe otro tipo de autenticaciŪn que depende del medio que se va a usar para tales fines. Est·n las b·sicas usadas en p·ginas HTML, la autenticaciŪn de HTTP, y la encriptada usando el protocolo SSL.

Con este ?ltimo se pueden llegar a implementar las firmas digitales, como un medio de aseguramiento de autenticaciŪn.

Con las dos primeras formas de autenticaciŪn, las de HTML y HTTP usan servidores externos de autenticaciŪn, de esta forma, se manda el username y el password para que el servidor verifique el ingreso.

La tercera opciŪn, utiliza el protocolo SSL y es usado para transmisiŪn de informaciŪn segura como manejo de n?meros de tarjetas de crČdito y otras transacciones coninformaciŪn vital. Es importante notar que este tipo de transacciones toman m·s tiempo de lo normal, ya que tiene que procesar informaciŪn extra (overhead) al encriptar la informaciŪn, pero este problema es balanceado con el uso del cachČ, para agilizar las transacciones, pero en ultimas se puede decir que es un buen mecanismo si sequiere mantener la confiabilidad de la informaciŪn, sacrificando un poco de tiempo de acceso.

Controlando el acceso con clientes certificados

El manejo de clientes certificados se puede alcanzar con el protocolo SSL en conjunto con un control de acceso. El control de acceso se lleva a cabo con un sistema de directorio de acceso LDAP (LightweightDirectory Access Protocol), asegurando que cada cliente tenga una ?nica entrada al directorio de acceso. De esta forma se puede garantizar un acceso seguro al implementar polĢticas sobre a quien se le da acceso y a quien no y a que tipo de informaciŪn puede tener acceso, de esta forma si el certificado casa con la entrada al directorio el cliente puede acceder a los servicios que presta el servidor.

Para tener funcionando este servicio de certificaciŪn, el servidor debe configurar las entradas de usuario en sudirectorio de acceso para luego indicarle al Proxy donde se encuentra el directorio para que verifique usuarios y el grupo de informaciŪn que se puede llegar a acceder.

VII. BALANCEO DE CARGA EN PROXIES REVERSOS

Como ya se ha dicho anteriormente, el Proxy Reverso cumple la funciŪn de intermediario entre una red privada de servidores y Internet. Pero para hacer el acceso eficientemente, los Proxies Reversos utilizan balanceo de carga para distribuir las solicitudes hacia la red de servidores y lograr un acceso a la informaciŪn eficiente.

Pero este balance puede llegar a tener una utilidad grande cuando un cliente solicita informaciŪn a un servidor que se puede llegar a encontrar fuera de servicio, en estos casos el Proxy Reverso cumple la funciŪn de redireccionar la solicitud a alguno otro que la posea.

Profundizando en este punto, vemos que un Reverse Proxy funciona como una puerta de acceso para m?ltiples servidores que est·n detr·s de Čl, basados en hostnames virtuales; lo cual quiere decir que los clientes que solicitan informaciŪn solo pueden ver la direcciŪn global IP Ū la URL que le muestra el Proxy Reverso; de esta forma los servidores escuchan solicitudes a direcciones IP Ū a puertos por medio de este ?ltimo; el cual puede redireccionar solicitudes como HTTP para enviarlas por alg?n camino   disponible y seguro.

En el caso en el que se estČn manejando m·s de un Proxy Reverso, por medio del DNS puede enrutar la solicitud de manera aleatoria usando ģround-robinī para seleccionar la IP del Proxy Reverso a utilizar. En este caso el cliente no sabe que hay detr·s de este procedimiento y siempre va a utilizar la misma URL en cada solicitud, pero realidad toma un servidor Proxy diferente cada vez.

La ventaja de usar varios Proxy Reverso para manejar las solicitudes entrantes, esta en el uso del cachČ, ya que las solicitudes m·s frecuentes no tienen que llegar hasta los servidores al estar guardadas en la cachČ del Proxy bajando la utilizaciŪn del canal dram·ticamente.

Otra forma de balancear la carga es por medio del uso de compresiŪn de material HTTP. Este mČtodo es muy eficaz para salvar el uso del ancho de banda de una red.

Esta forma de compresiŪn puede ser usada por cualquier archivo de texto como HTML/XML sea din·micamente o est·ticamente creado. Este tipo de compresiŪn puede reducir los archivos hasta en un 90%, salvando consigo el uso de las maquinas al sumarle la encripciŪn de SSL.

En la prŪxima parte se explica como se maneja   la seguridad en una topologĢa que soporte esta tecnologĢa; la cual esta basada a travČs del protocolo de encripciŪn SSL.


III. SEGURIDADEN PROXIES REVERSOS

La seguridad en un Reverse Proxy; como ya se habĢa mencionado anteriormente; es manejada a travČs del protocolo SSL; el cual utiliza mecanismos de encripciŪn para poder transmitir informaciŪn critica como logins y passwords a travČs del canal de comunicaciŪn entre el cliente, el Servidor Proxy y los Servidores decontenido; en el cual solo se abren los puertos necesarios para prestar alg?ntipo de servicio. Durante el proceso todos estos datos reciben el nombre de ģcipher textī, y estos viajan a travČs del canal de comunicaciŪn, para ser desencriptados en su destino por alg?n tipode cipher o algoritmo de desencripciŪn.

Actualmente existen una gran cantidad de ciphers; lo cuales varĢan seg?n la versiŪn del protocolo SSL; por lo tanto ofrecen una cantidad de alternativas seg?n lo que se este buscando en tČrminos de rapidez, seguridad, etc. La diferencia entre estos algoritmos es el uso de una longitud de bits determinada para encriptar los datos en el canal de comunicaciŪn; generando un proceso de encripcion tanto como de desencripcion m·s difĢcil a medida que se utiliza un mayor numero de bits.

SSL es un protocolo de nivel cinco en el est·ndar   OSI (Open System Interconnection); el cual permite establecer un canal de comunicaciŪn seguro entre dos puntos, mediante la combinaciŪn de encripciŪn de llaves publicas con encripciŪn simČtrica; el cualse autentica mediante certificados. La conexiŪn que se realiza entre los dos puntos es de tipo cliente-servidor donde ambos extremos deben soportar este protocolo para el intercambio de informaciŪn.





Imagen 4: EncripciŪn enSSL

La encripcion mediante llaves simČtricas, cosiste en utilizar la misma clave en el proceso   de encripcion y desencripcion dentro de la comunicaciŪn entre dos puntos mediante el protocolo SSL. Es un mČtodo bastante r·pido y generalmente se utiliza para encriptar grandes cantidades de datos. El proceso de encripcion mediante llaves publicas consiste en generar dos llaves relacionadas entre si; con las caracterĢsticas que una de ellas es de tipo privado y la otra de tipo publico. Las llaves ģpublicasī son distribuidas a diferentes usuarios dentro de la organizaciŪn o empresa; seg?n las necesidades de esta ultima; y la llave privada solo es manejada por la persona encargada de crearla. Una vez establecido el canal entre dos puntos, se pueden encriptar los datos mediante el uso de las   llaves p?blicas; para despuČs realizar el proceso de desencripcion al otro lado de la comunicaciŪn, mediante la llave privada.   La combinaciŪn de estas dos tČcnicas de encripcion, son conocidas como sistemas hĢbridos; los cuales aumentan la seguridad en el envĢo de datos mediante el protocolo SSL; haciendo que sea m·s difĢcil la adquisiciŪn y manipulaciŪn de informaciŪn critica por parte de extraŅos o atacantes, ya que se ven en el proceso de adquirir mas de una llave.

El proceso mediante el cual se establece una conexiŪn entre un cliente y un Servidor de contenido en un Reverse Proxy se le llama ģtunnelingī; y este consiste en que se abre un socket entre el cliente y el Servidor Proxy, y entre este ?ltimo y el Servidor de Contenido. Los datos de conexiŪn se copian en ambas sesiones para dar una apariencia de una comunicaciŪn transparente; y simular la peticiŪn y resoluciŪn directa de solicitudes entre el Servidor de Contenido y el cliente.

El hecho de que todos los datos que se envĢan tengan que ser encriptados genera un overflow o sobrecarga del canal, por lo que las conexiones se vuelven algo lentas; sin embargo como el Servidor Proxy cuenta con un mecanismo de cachČ, es posible que los par·metros de conexiŪn se puedan mantener y aprovechar para futuros procesamientos de solicitudes hechas por los clientes.

Como el tipo de solicitudes que maneja un Reverse Proxy son de tipo HTTP; y la comunicaciŪn se da a travČs de los canales por medio del protocolo SSL; el tipo de URLs manejados son de tipo HTTPS; que es un protocolo que maneja el envĢo de solicitudes mediante el protocolo Secure Socket Layer; es decir; que estas van encriptadas mediante ciphers definidos en los est·ndares del SSL(versiŪn 2.0 y versiŪn 3.0)[3>. Esta comunicaciŪn consiste en establecer dos canales: el primero entre el cliente y el Reverse Proxy, en donde se maneja el protocolo http; y el segundo entre el Reverse Proxy y el Servidor de Contenido, el cual maneja el protocolo HTTPS ya que se necesita que los datos vayan encriptados con el fin de evitar problemas de seguridad que puedan comprometer al Servidor de contenido.



Imagen 5: ComunicaciŪn entre un cliente y un Servidor de Contenido a travČs de un Reverse Proxy.

A continuaciŪn se explican algunos tipos de implementaciones que actualmente se encuentran en el mercado; cada una de ellas ofreciendo sus respectivos servicios y tecnologĢas para garantizar un nivel de seguridad y calidad para las diferentes empresas que adquieren sus productos.

IX. ALGUNAS IMPLEMENTACIONES DE PROXIES REVERSOS

A. Proxy Reverso con ORENOSP

Este Reverse Proxy corre bajo plataformas Windows como Windows NT 4.0, Windows 2000 and Windows XP.

      * Dentro de las especialidades que podemos encontrar en Orenosp es la capacidad de   reemplazar URLs internas en HTML externas en p·ginas HTML.
      * Protocolo SSL
      * Restricciones de acceso por direcciones IP
      * Filtro Nimda: Puede filtrar cualquier solicitud que corresponda con una URL especĢfica y puede guardar estas solicitudes en LOGS.
      * Soporta los tres modos de autenticaciŪn para Proxy: HTML, HTTP y SSL.
      * Distribuye la carga entre m?ltiples servidores Web redireccionando las solicitudes HTTP
      * Soporta IP versiŪn 6.
      * M?ltiples servidores pueden publicar vĢa una sola direcciŪn global IP usando hostnames virtuales.
      * Puede manejar contenido HTTP comprimido.



B. Proxy Reverso con SQUID

Squid fue creado por la ģNacional Science Foundationī y es un Proxy de cŪdigo abierto (open source) de alto desempeŅo, el cual fue diseŅado para correr sobre plataformas Unix.

Soporta:

      * Proxying y Caching de HTTP, FTP y URLķs.
      * Protocolo SSL.
      * JerarquĢas de CachČ.
      * ICP (Internet Cache Protocol): utilizado entre Web Caches, HTCP (Hypertext Caching Protocol), CARP (CachČ Array Routing Protocol): usa una funciŪn hash para decidir que cachČ debe responder, y diseŅos de cachČ.
      * Transparent caching WCCP (Web Cache Communication Protocol): Mantiene un redireccionamiento del tr·fico entre los routers de la red.
      * Control de Accesos.
      * AceleraciŪn de HTTP.
      * SNMP (Simple Network Managment Protocol): es un protocolo de operaciones est·ndar de mantenimiento, utilizado en su gran mayorĢa, para ayudar a soportar el crecimiento que ha tenido Internet, analizando flujo de tr·fico.

C. Proxy Reverso con APACHE

      * Proxying y Caching de HTTP, FTP y URL„s.
      * Protocolo SSL.
      * Control de Accesos.
      * Distribuye la carga entre m?ltiples servidores Web redireccionando las solicitudes HTTP.
      * M?ltiples servidores pueden publicar vĢa una sola direcciŪn global IP usando hostnames virtuales.
      * Puede manejar contenido HTTP comprimido.

D. Proxy Reverso con MICROSOFT PROXY SERVER

      * Web caching
      * CARP (Cache Array Routing Protocol): usa una funciŪn de hashing para decidir que cachČ debe responder, y diseŅos de cachČ.
      * ICP (Internet Cache Protocol): utilizado entre Web Caches.
      * LAT (Local Address Translation): usado para camuflar la topologĢa interna de la red previniendo ataques tipo IP spoofing.
      * RAS (Remote Access Service): limita las conexiones dial-up para ciertas horas del dĢa.
      * JerarquĢas de Cache y Proxying
      * Firewall security capabilities.

E. Proxy Reverso con NETSCAPE PROXY SERVER

Este servidor fue pensado para plataformas Unix   y Windows, y a diferencia del Microsoft Proxy Server, no esta hecho para desarrollar las funciones de Proxy y de Firewall en el mismo servidor.

      * ICP (Internet Cache Protocol): utilizado entre Web Caches.
      * CARP (Cache Array Routing Protocol): usa una funciŪn de hashing para decidir que cache debe responder, y diseŅos de cache.
      * Filtros por direcciones IP.
      * Spyglass's SurfWatch: puede filtrar contenido Web, como ActiveX y MIME.
      * Interscan Virus-Wall anti-virus software: escaneo de virus.
      * LDAP (Lightweight Directory Access Protocol): asegura una entrada por cada usuario registrado.

X. VULNERABILIDADES Y SUS RESPECTIVOS ATAQUES

Para hablar de vulnerabilidades de proxies, es necesario tener en cuenta que existen distintos tipos de proxies, no sŪlo los mencionados en el capĢtulo anterior, sino diversas implementaciones m·s, las cuales ofrecen ciertos servicios de diversas formas y asĢ mismo tienen vulnerabilidades diferentes.

Otro aspecto importante para tener en cuenta antes de entrar a hablar de vulnerabilidades es que gran parte de los ataques que reciben estos servidores se llevan a cabo vĢa los puertos abiertos correspondientes a los servicios ofrecidos, como el puerto 80 o 8080 para HTTP, el puerto 443 para HTTPS (SSL), el 110 para POP3, el 25 para SMTP, el 20 y el 21 para FTP entre otros, a menos de que estos sean cambiados para los diferentes servicios o se dejen otros puertos abiertos en el servidor donde se encuentra el proxy.

Entre las vulnerabilidades principales se encuentran por ejemplo la configuraciŪn local que se le haya dado a la definiciŪn de las reglas para expresiones regulares que definen que tipo de encabezados son permitidos por el servidor proxy para que Čste redireccione las solicitudes al servidor encargado de dicho contenido o las rechace.

Este tipo de vulnerabilidad puede llevar a ataques con consecuencias como la denegaciŪn del servicio (DoS) debido a que en el momento de efectuar el parse de la expresiŪn ingresada en la solicitud hecha al proxy, Čsta genera un overflow. En caso de que dicha expresiŪn llegue al servidor de destino, Čsta tambiČn puede servir como herramienta para reunir informaciŪn sobre el o los distintos servidores internos que se desean acceder (fingerprinting) y de esta forma tambiČn puede permitir realizar otras operaciones como ejecutar comandos del sistema, por ejemplo la escritura y cambio de contenido en archivos, la obtenciŪn de listados y del contenido de archivos de cualquier tipo como contraseŅas, entre otros.

Otra vulnerabilidad es la incorrecta configuraciŪn del mŪdulo de SSL, lo cual puede llevar a que los intentos para conectarse de manera segura sean ignorados causando tambiČn negaciŪn del servicio o a que personas sin la autorizaciŪn debida para conectarse logren negociar la conexiŪn con el proxy hacĢa la red interna.

Una herramienta muy ?til para hacer fingerprinting y para detectar vulnerabilidades es netcat, con la que se pueden realizar algunos de los ataques mencionados anteriormente; y el cual se utilizar· mas adelante en este documento para simular un ataque de denegaciŪn de servicio.   Por ejemplo:

$ nc 192.9.1.100 80 < archivo.txt

En donde archivo.txt contiene un archivo de 25Kb de texto que al ser enviado hace que el Reverse Proxy no responda, causando el resultado mencionado anteriormente; que como se mencionŪ anteriormente; ser· explicado mas a fondo mas adelante.



Imagen 6: Ejemplo - NegaciŪn del Servicio(Pruebadel ataque desde un equipo hacia el Servidor Proxy con direcciŪn 192.9.1.100)

A. Ejemplo: MIGMAF

Cuando se habla de herramientas de comunicaciŪn como servidores, routers, firewalls, proxies, entre otros, se habla de canales que permiten la comunicaciŪn entre dos puntos en Internet. Tales medios de comunicaciŪn tienen ģhuecosī por los cuales una comunicaciŪn puede ser interceptada, suplantada, inhabilitada, redireccionada o negada.

En el caso de transacciones redireccionadas, encontramos el caso de Migmaf, un troyano que convierte los PCs en servidores de p·ginas pornogr·ficas y fue descubierto a mediados del aŅo 2003.

Asi pues; este troyano instala un Reverse Proxy en el computador infectado que para cumplir la funciŪn de redireccionar todas las solicitudes HTTP contra un servidor central, habitualmente con contenido pornogr·fico. De esta forma, se consigue ocultar la ubicaciŪn real de ese servidor central e impidiendo cualquier posible acciŪn de bloqueo de su contenido.

El funcionamiento del sistema es relativamente complejo, al llegar hasta los   dominios de direcciones y asocia la direcciŪn IP de la m·quina donde se est· ejecutando el troyano con un nombre de sistema dentro de esos dominios. Esto les permite tener asociadas a los nombres utilizados en las URL virtualmente miles de direcciones IP diferentes, en redes diversas y potencialmente distribuidos por todo el planeta.

La existencia de varios millares de sistemas con el troyano hace que cualquier intento de bloquear el acceso al contenido del servidor central sea muy difĢcil. Adicionalmente, el troyano est· escuchando el puerto 81/tcp donde hay un servidor socks de forma que desde el servidor central se puede utilizar esta conexiŪn para, por ejemplo, enviar correo spam de forma que su origen queda totalmente oculto. Una vez m·s, los receptores de este tipo de correos consideran que es el sistema vĢctima quien ha realizado el envĢo.

Adem·s del grado de expansiŪn de este troyano, tambiČn fue pensado para hacer un uso eficiente de los recursos, monitoreando el tiempo de transmisiŪn de Web. Para detectar este troyano se debe buscar el archivo WINGATE.EXE.

XI DEMO DEL ATAQUE
Para demostrar lo vulnerable que es una topologĢa de Proxies Reversos; se realizŪ un demo en el cual se representa uno de los ataques a los que estos pueden estar expuestos. Bajo esa idea se utilizŪ un simulador de un Reverse Proxy y dos computadores m·s; uno que representaba el cliente atacante, y otro que representaba el Servidor Web.

El   Servidor Web de Contenido se configurŪ con Apache 2.0.4 en una m·quina Linux Redhat.

Para el Reverse Proxy se utilizŪ una herramienta libre llamada at32 Proxy Reverse; con la cual se puede realizar un manejo f·cil de todas las operaciones de funcionamiento y configuraciŪn posibles en este tipo de tecnologĢa; como la creaciŪn de reglas de redireccionamiento, creaciŪn de logs, etc.

…sta es una aplicaciŪn que tiene una interfaz Web; mediante la cual se pueden configurar todas las reglas de redireccionamiento y enmascaramiento de URLs, con el fin de   proteger los Servidores de contenido. Estas reglas son configurables mediante la creaciŪn de expresiones regulares o cadenas simples, las cuales permiten realizar comparaciones cada vez que llega un requerimiento al Servidor Proxy por parte tanto de un cliente como de un Servidor de Contenido o Web. Estas reglas tambiČn pueden ser configuradas mediante la creaciŪn de archivos de texto plano (.txt) en donde se especifican los par·metros explicados a continuaciŪn:

?          Name: nombre de la regla.

?          Address: direcciŪn a la cual aplica la regla.

?          Port: puerto al que aplica la regla.

?          Desc: descripciŪn de la regla.

?          Requestmod: par·metro a configurar para cambiar el header de la solicitud del cliente a conveniencia del Reverse Proxy.

?          Responsemod: par·metro aconfigurar para cambiar el header de la respuesta del Servidor de Contenido hacia el Cliente, para evitar comprometerlo.

?          ConditionidCOUNT:

?          RequestidCOUNT: n?mero de solicitudes hechas hacia el Reverse Proxy.

?          ResponseidCOUNT: n?mero de respuestas enviadas hacia el ReverseProxy.

?          Enable: par·metro que indica si la regla esta activa o no.

?          Changelocation: indica la prioridad de esta regla con las dem·s.

?          Password: indica si el cliente necesita de un password para poder conectarse con el Reverse Proxy.

En el prŪximo tema presentaremos una breve explicaciŪn de cŪmo funciona el Reverse Proxy; con un conjunto de direcciones.

Presentamos una breve explicaciŪn de cŪmo funciona el Reverse Proxy; con el siguiente conjunto de direcciones:

Rol
   

DirecciŪn

Servidor de Contenido
   

169.254.63.118

Servidor Proxy
   

169.254.63.117

Cliente
   

169.254.63.120

Como primer paso, se crean las siguientes reglas de redireccionamiento y enmascaramiento

?   Por defecto; el ServidorProxy debe tener una regla que captura cualquier tipo de solicitud; en este caso; esta redirecciona el requerimiento del cliente hacia la direcciŪn del Servidor de Contenido.

AsĢ se verĢa en el archivo de reglas del programa at32 Reverse Proxy:

name=Regla1

address=http://169.254.63.118

port=80

descr=Esta regla redirecciona la solicitud del cliente tal como viene al servidor

requestmod=delete   host add host:169.254.63.118

responsemod=

conditionidCOUNT=0

requestidCOUNT=0

responseidCOUNT=0

enabled=t

changelocation=t

password=

?   Redireccionamiento de la solicitud; en caso de que en el encabezado HTTP se encuentre la cadena 169.254.63.117; es decir; redirecciona todo hacia el Servidor de contenido, encaso de que le hagan una solicitud al Servidor Proxy.

AsĢ se verĢa enel archivo de reglas del programa at32 Reverse Proxy:

name=Regla2

address=http://169.254.63.118

port=80

descr=Esta regla redirecciona la solicitud del cliente si en el encabezado http viene la cadena 169.254.63.117

requestmod=delete    host addhost:169.254.63.118

responsemod=

conditionidCOUNT=2

requestidCOUNT=0

responseidCOUNT=0

enabled=t

changelocation=f

password=

Al final de la configuraciŪn se puede tener una apreciaciŪn de las reglas de la siguiente manera; sin embargo esto no significaque no se puedan crear tantas reglas como se necesiten para satisfacer las necesidades del tipo de Reverse Proxy que se desea manejar:



Imagen 7: Reglas configuradas en el at32 Proxy Reverse

DespuČs de tener configurado el Reverse Proxy se procede a realizar el ataque; el cual consiste en mandar un archivo de tamaŅo considerado por el puerto que atiende las solicitudes en el Servidor Proxy, con el fin de lograr un ataque de NegaciŪn del Servicio (DoS). En este caso se utiliza una herramienta llamada Netcat con la cual se puede establecer una conexiŪn a un puerto de la m·quina de destino y se puede ejecutar desde el envĢo de diferente tipo de headers y solicitudes, hasta transmisiŪn de archivos y otro tipo de datos. El ataque fue implementado con un archivo de texto plano, el cual fue enviado por el puerto de atenciŪn del Proxy (80).   A continuaciŪn se muestra el comando necesario para realizar esta acciŪn:



magen 8 : Comando en Netcat con el cual se realizo el ataque al Reverse Proxy

DespuČs de ejecutar el comando, el Servidor Proxy queda bloqueado; y sin posibilidad de atender mas solicitudes; por lo que cualquier peticiŪn que realice un cliente hacia la direcciŪn del mismo (169.254.63.117 para este ejemplo), tendr· como resultado el siguiente aviso:



Imagen9 : aviso desplegado cuando se intenta solicitar un recurso al Reverse Proxy despuČs del ataque



A continuaciŪnse muestra el resultado en el Servidor Proxy:



Con el dibujoanterior se puede observar que el programa genera un registro de error; en lacarpeta donde se encuentra la aplicaciŪn ac32 Reverse Proxy. Este es unarchivo que   se   puede configurar para que genere un registrode cada solicitud realizada por el cliente; sin embargo no viene por defecto, ytoca especificarle a la aplicaciŪn, que se desea la creaciŪn de logs. AcontinuaciŪn se presentan dos tipos de transacciones que se encuentran en losregistros: una solicitud normal, y la solicitud que es generada por lasituaciŪn del ataque anterior o registro de error:
Request   Normal

-REQUEST-

16:24:21 16 Feb 04

Method: GET

Protocol: HTTP/1.1

URI         (fm client): /

Query      (fm client):

URI+Query (to server): /

Client IP: 169.254.63.120



Header from Client:

Accept: */*

Accept-Language: es-co

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 5.01;Windows NT 5.0)

Host: 169.254.63.117

Connection: Keep-Alive



Header sent to Server:

Accept: */*

Accept-Language: es-co

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 5.01;Windows NT 5.0)

host:169.254.63.119



Header received from Server:

HTTP/1.1 200 OK

Date: Mon, 16 Feb 2004 21:22:09 GMT

Server: Apache/2.0.40 (Unix)

Last-Modified: Wed, 11 Feb 2004 00:48:48 GMT

ETag: "5401-829-ff62dc00"

Accept-Ranges: bytes

Content-Length: 2089

Keep-Alive: timeout=15, max=100

Connection: Keep-Alive

Content-Type: text/html; charset=ISO-8859-1



Header sent to Client:

HTTP/1.1 200 OK

Date: Mon, 16 Feb 2004 21:22:09 GMT

Server: Apache/2.0.40 (Unix)

Last-Modified: Wed, 11 Feb 2004 00:48:48 GMT

ETag: "5401-829-ff62dc00"

Accept-Ranges: bytes

Content-Length: 2089

Keep-Alive: timeout=15, max=100

Connection: Keep-Alive

Content-Type: text/html; charset=ISO-8859-1
Request despuČs del Ataque

16:24:21 16 Feb 04

Method: GET

Protocol: HTTP/1.1

URI         (fm client): /apache_pb

Query      (fm client):

URI+Query (to server): /apache_pb

Client IP: 169.254.63.120



Header from Client:

Accept: */*

Referer: http://169.254.63.117/

Accept-Language: es-co

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 5.01;Windows NT 5.0)

Host: 169.254.63.117

Connection: Keep-Alive


Header sent to Server:

Accept: */*

Referer: http://169.254.63.117/

Accept-Language: es-co

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 5.01;Windows NT 5.0)

host:169.254.63.119



Header received from Server:

HTTP/1.1 404 Not Found

Date: Mon, 16 Feb 2004 21:22:09 GMT

Server: Apache/2.0.40 (Unix)

Content-Length: 280

Keep-Alive: timeout=15, max=100

Connection: Keep-Alive

Content-Type: text/html; charset=iso-8859-1



Header sent to Client:

HTTP/1.1 404 Not Found

Date: Mon, 16 Feb 2004 21:22:09 GMT

Server: Apache/2.0.40 (Unix)

Content-Length: 280

Keep-Alive: timeout=15, max=100

Connection: Keep-Alive

Content-Type: text/html; charset=iso-8859-1

Lo que se puede analizar de los registros anteriores; es que con este   tipo de ataque, el Servidor Proxy no es capaz de redireccionar la solicitud del cliente hacia el Servidor de Contenido; por lo que en el par·metro Content-Length, aparece un valorde 280; lo que significa que es el tamaŅo de una pagina tĢpica que muestra el header response: 404 Not Found. Por el contrario cuando el Servidor Proxy esta funcionando correctamente el Content-Length en este caso particular esde 2089; que es el tamaŅo de la p·gina solicitada.

En la tabla a continuaciŪn se muestra el tr·fico generado por Windump, cuando se realizŪ el ataque. La tabla muestra cada lĢnea de envĢo de datos tanto en la salida normal de la la aplicaciŪn como en hexadecimal:

Servidor Proxy:

Salida 1: el cliente realiza una solicitud de conexiŪn al Reverse Proxy mediante el envĢo del flag SYN.

16:24:18.793679 IP (tos 0x0, ttl 128, id 354, len 48) 169.254.63.120.1064 > 169.254.63.117.80: S [tcp sum ok>

4179830108:4179830108(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)



Salida 1 en Hexadecimal: el cliente realiza una solicitud de conexiŪn al Reverse Proxy mediante el envĢo del flag SYN.

0x0000                  4500 0030 0162 4000 8006 267c a9fe 3f78                  E..0.b@...&|..?x

0x0010                  a9fe 3f75 0428 0050 f923 255c 0000 0000                   ..?u.(.P.#%....

0x0020                  7002 4000 4d3d 0000 0204 05b4 0101 0402               p.@.M=..........



Salida 2: el Reverse Proxy contesta la solicitud de conexiŪn al cliente mediante el envĢo del flag SYN+ACK.

16:24:18.793938 IP (tos 0x0, ttl 128, id 1835, len 48) 169.254.63.117.80 > 169.254.63.120.1064: S [tcp sum ok> 3170545738:3170545738(0) ack 4179830109 win 17520 <mss 1460,nop,nop,sackOK> (DF)



Salida 2 en hexadecimal: el Reverse Proxy contesta la solicitud de conexiŪn al cliente mediante el envĢo del flag SYN+ACK.

0x0000                  4500 0030 072b 4000 8006 20b3 a9fe 3f75                                    E..0.+@.......?u

0x0010                  a9fe 3f78 0050 0428 bcfa b04a f923 255d                     ..?x.P.(...J.#%>

0x0020                  7012 4470 db76 0000 0204 05b4 0101 0402               p.Dp.v..........



Salida 3: el cliente termina de realizar la conexiŪn mediante el envĢo del flag ACK.

16:24:18.794033 IP (tos 0x0, ttl 128, id 356, len 40) 169.254.63.120.1064 > 169.254.63.117.80: . [tcp sum ok> 1:1(0) ack 1 win 17520 (DF)



Salida 3 en Hexadecimal: el cliente termina de realizar la conexiŪn mediante el envĢo del flag ACK.

0x0000                  4500 0028 0164 4000 8006 2682 a9fe 3f78                                    E..(.d@...&...?x

0x0010                  a9fe 3f75 0428 0050 f923 255d bcfa b04b                   ..?u.(.P.#%>...K

0x0020                  5010 4470 083b 0000                                                                      P.Dp.;..



Salida 4: el cliente realiza el envĢo de una solicitud hacia el Reverse Proxy.

16:24:18.794585 IP (tos 0x0, ttl 128, id 357, len 324) 169.254.63.120.1064 > 169.254.63.117.80: P 1:285(284) ack 1 win 17520 (DF)



Salida 4 en Hexadecimal: el cliente realiza el envĢo de una solicitud hacia el Reverse Proxy. El tamaŅo total del datagrama seg?n la salida hexadecimal, es de 68 bytes; sin embargo realmente ocupa mas de este valor (84 bytes).

0x0000                  4500 0144 0165 4000 8006 2565 a9fe 3f78                                    E..D.e@...%e..?x

0x0010                  a9fe 3f75 0428 0050 f923 255d bcfa b04b                   ..?u.(.P.#%>...K

0x0020                  5018 4470 6bb1 0000 4745 5420 2f20 4854                P.Dpk...GET./.HT

0x0030                  5450 2f31 2e31 0d0a 4163 6365 7074 3a20                TP/1.1..Accept:.

0x0040                  2a2f 2a0d 0a41 6363 6570 742d 4c61 6e67                                    */*..Accept-Lang

0x0050                  7561                                                                                                               ua



Salida 5: El Reverse Proxy contesta que recibiŪ el envĢo de datos por parte del cliente; a pesar de que el datagrama tenia un valor bastante grade; mediante el uso del flag ACK

16:24:18.993278 IP (tos 0x0, ttl 128, id 1836, len 40) 169.254.63.117.80 > 169.254.63.120.1064: . [tcp sum ok> 1:1(0) ack 285 win 17236 (DF)



Salida 5 en Hexadecimal: El Reverse Proxy contesta que recibiŪ el envĢo de datos por parte del cliente; a pesar de que el datagrama tenia un valor bastante grade; mediante el uso del flag ACK

0x0000                  4500 0028 072c 4000 8006 20ba a9fe 3f75             E..(.,@.......?u

0x0010                  a9fe 3f78 0050 0428 bcfa b04b f923 2679               ..?x.P.(...K.#&y

0x0020                  5010 4354 083b 0000 2020 2020 2020                        P.CT.;........


Salida 6: el Reverse Proxy pide terminar la conexiŪn con el cliente mediante el flag RESET por el puerto 1064.

16:25:52.683702 IP (tos 0x0, ttl 128, id 1837, len 40) 169.254.63.117.80 > 169.254.63.120.1064: R [tcp sum ok> 3170545739:3170545739(0) win 0 (DF)


Salida 6 en Hexadecimal: el Reverse Proxy pide terminar la conexiŪn con el cliente mediante el flag RESET por el puerto 1064.

0x0000                  4500 0028 072d 4000 8006 20b9 a9fe 3f75                              E..(.-@.......?u

0x0010                  a9fe 3f78 0050 0428 bcfa b04b f923 2679               ..?x.P.(...K.#&y

0x0020                  5004 0000 4b9b 0000 2020 2020 2020                        P...K.........


Salida 7: el Reverse Proxy pide terminar la conexiŪn con el cliente mediante el flag RESET por el puerto 1063.

16:25:52.685541 IP (tos 0x0, ttl 128, id 1838, len 40) 169.254.63.117.80 > 169.254.63.120.1063: R [tcp sum ok> 3166440966:3166440966(0) win 0 (DF)



Salida 7 en Hexadecimal: el Reverse Proxy pide terminar la conexiŪn con el cliente mediante el flag RESET por el puerto 1063.

0x0000                  4500 0028 072e 4000 8006 20b8 a9fe 3f75                              E..(..@.......?u

0x0010                  a9fe 3f78 0050 0427 bcbc 0e06 f923 2679             ..?x.P.'.....#&y

0x0020                  5004 0000 ee1f 0000 2020 2020 2020                         P.............

Este log nos muestra el momento en el que la solicitud del cliente es atendida por el ServidorProxy, estableciendo un canal de comunicaciŪn entre los dos equipos; sin embargo en el momento del ataque se puede observar que el Servidor Proxy envĢados comandos de RESET hacia el cliente que crea la solicitud. Lo interesante es que el comando es enviado a los puertos 1064 y 1063; donde este ultimo no habĢa tenido participaciŪn durante el intercambio de paquetes; ya que la conexiŪn en el cliente se estableciŪ por el puerto 1064; generando un comportamiento extraŅo y poco com?n.

XII. CONCLUSIONES

El Proxy Reverso es una nueva tecnologĢa que ofrece una gran cantidad de ventajas y mejoras en cuanto al ·rea de seguridad frente a ataques a diferentes servidores de Contenido. A pesar de esto, al comprometer el Proxy Reverso se pueden obtener consecuencias mucho mas graves, debido a la gran responsabilidad que maneja al cuidar la integridad de los canales de comunicaciŪn y la informaciŪn que implica el uso de los diferentes Servidores de Contenido. No se debe ahorrar en polĢticas de seguridad, para poder garantizar una integridad confiable en la informaciŪn critica que puede llegara manejar este tipo de tecnologĢas; y en el contexto de los Proxies Reversos; cualquier acciŪn quese realice para apoyar esta idea debe ser considerada como necesaria e indispensable.

Como buena estrategia de seguridad; al trabajar con una topologĢa que maneje   ReverseProxies; es recomendable activar la opciŪn de Reverse Path Filtering; la cual es una estrategia bastante utilizada para determinar la confiabilidad de los paquetes enviados. Esta opciŪn consiste en examinar la interfaz por lacual saliŪ la respuesta a un paquete; de tal forma que si esta no es la misma por la que llego, el paquete es considerado errŪneo y deberĢa ser ignorado.

XII. GLOSARIO

Firewall:Dispositivo (hardware Ū software), encargado de suministrar protecciŪn contraataques Ū solicitudes que puedan ir en contra de la integridad de losdispositivos a proteger.

HTTP: Hyper Text Transfer Protocol.

EBN: External Bussiness Partners. Personaso instituciones vinculadas a una organizaciŪn, pero no necesariamente hacen parte de ella.

DMZ :Demilitarized Zone.

SSL: Secure Socket Layer.

URL: Universal Resource Locator.

Pin deautenticaciŪn: n?mero que identifica de manera ?nica a una persona

Web: Concepto dered que simboliza una telaraŅa gigantesca (Internet)

Intranet: es unared privada que puede ser accedida solo por personas autorizadas, especialmentemiembros Ū empleados de la organizaciŪn.

HTML: H(yper)t(ext) M(arkup)L(anguage)

Overhead:sobrecarga de las capacidades de envio de datos, en el proceso de transmisiŪnde los mismos.

LDAP: LightweightDirectory Access Protocol.

Round robin:algoritmo para manejar colas de procesos, en el cual el primer proceso que entraes el primero en salir.

CachČ: Memoriade r·pido acceso, generalmente contiene informaciŪn temporal.

XML : eX(tensible) M(arkup)L(anguage).>

Overflow: Flujode informaciŪn que corre por encima de los lĢmites de procesamiento

HTTPS: SecureHTTP.

ORENOSP: Nombre de un conocido reverse proxy

Nimda: Nombre de un gusano informatico

SQUID: Nombre de un conocido reverse proxy

FTP: File Transfer Protocol.

HTCP: HypertextCaching Protocol.

CARP: CachČ Array Routing Protocol.

WCCP: Web Cache Communication Protocol.

SNMP: Simple Network Managment Protocol.

ICP: Internet CacheProtocol.

LAT: Local AddressTranslation.

RAS: Remote AccessService.

POP3: Post Office Protocol -Version 3

SMTP: Simple MailTransfer Protocol.

DoS: Denial ofService.

Spam: Mandar correo con informaciŪn nosolicitada (publicidad). Mandar un mensaje a individuales, grupales o m?ltipleslistas de correo

OSI: Open System Interconnection.



autor: Cygog



es algo estenso pero a mi me parece muy completo y muy vacano

salu2
04/05/2009 00:04:50 
Drayfe
Aprendiz nivel 3
Arreglando las imįgenes

Mensajes: 81
Registrad@:
19/08/2005
Estado: Desconectad@
Ir Arriba
RE: Ataques a Proxies Reversos

No me lo he leido entero, pero tiene buena pinta.
No se si va aki o en redes :S

Un saludo.


Colabora en mi web de musica Roseinheaven
04/05/2009 09:26:54 
RevangelyonX
Aprendiz nivel 3

Mensajes: 92
Registrad@:
11/09/2005
Estado: Desconectad@
Ir Arriba
RE: Ataques a Proxies Reversos

Muy muy bueno, no habķa oķdo hablar del Reverse, el texto estį muy bien, una pena que no sea tuyo :).

El tema puede ir en redes, en seguridad, en general y en hacking jejeje. Tiene contenido :).

A parte tiene un manejo de herramientas śtiles, estį muy bien realmente. Sabiendo que existe un Firewall entre el atacante y el Proxy, se podrį ańadir una regla de tamańo de petición hacia un puerto ?

Quizį ańadiendo reglas al firewall se puede evitar ese ataque DOS, no sé, pero el texto me ha gustado mucho.




08/05/2009 14:29:21 
wibastian
Aprendiz nivel 1

Mensajes: 28
Registrad@:
07/10/2004
Estado: Desconectad@
Ir Arriba
RE: Ataques a Proxies Reversos

se ve buenisimo, creo que esta bien posteado en la categoria de hacking si en el fondo explica como atacar los proxies reversos
10/05/2009 06:52:02 
RevangelyonX
Aprendiz nivel 3

Mensajes: 92
Registrad@:
11/09/2005
Estado: Desconectad@
Ir Arriba
RE: Ataques a Proxies Reversos

CITA
se ve buenisimo, creo que esta bien posteado en la categoria de hacking si en el fondo explica como atacar los proxies reversos

Exacto, del mismo modo se explica qué es y como montarlo


10/05/2009 08:24:18 


REGĶSTRATE PARA PODER ENVIAR UN MENSAJE (tardas 20 segundos)

Copyright ForoHack.com