Project

General

Profile

Actions

Bug #2333

closed

Suricata doesn't see http traffic as http traffic in wierd proxy

Added by Francis Trudeau over 6 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Normal
Target version:
-
Affected Versions:
Effort:
Difficulty:
Label:

Description

I don't know if this is a bug or expected behavior as it's an odd case.

In trying to make rules for localtunnel:

https://localtunnel.github.io/www/

Suricata wouldn't recognize certain (non standard) http traffic. Pcap attached.

localtunnel reaches out, get a config, then connects to localtunnel(dot)me 10 times (this looks configurable) and waits for data. When someone goes to the public url, that data is shoved down one of the connections to the client machine, which pipes it off to whatever you set it up, in this case it was lighttpd.

The http data coming down from the "proxy" is all busted. I am not sure if Suricata doesn't see as http because of the bustedness of it, or if the wrong IP in the conversation is sending the data, a GET in this case.

The conversation starts in packet 65 of attached pcap.

I separated the exfil conversation for testing. It's attached as exfil.pcap

This fires:

alert tcp any any -> any any (msg:"ET POLICY localtunnel Data Exfiltration"; content:"host|3a 20|"; sid:303033; rev:1;)

This does not:

alert http any any -> any any (msg:"ET POLICY localtunnel Data Exfiltration"; content:"host|3a 20|"; sid:303034; rev:1;)


Files

localtunnel.connection.pcap (16.1 KB) localtunnel.connection.pcap Whole localtunnel conversation Francis Trudeau, 12/04/2017 03:18 PM
exfil.pcap (3.12 KB) exfil.pcap Just one connection exfiltrating data Francis Trudeau, 12/04/2017 03:20 PM
Actions #1

Updated by Victor Julien over 6 years ago

So this is not valid HTTP as the server and client have switched places. I don't think Suricata should try to 'fix' this by accepting the server to act as client and vice versa.

How about having rules to simply detect this protocol anomaly?

Actions #2

Updated by Francis Trudeau over 6 years ago

Victor Julien wrote:

So this is not valid HTTP as the server and client have switched places. I don't think Suricata should try to 'fix' this by accepting the server to act as client and vice versa.

How about having rules to simply detect this protocol anomaly?

Yeah, that's what I was planning. I kind of figured this was too far out to be expected to magically be recognized.

Thanks for looking.

Actions #3

Updated by Andreas Herz over 6 years ago

  • Status changed from New to Closed
  • Assignee set to Francis Trudeau
  • Target version set to TBD
Actions #4

Updated by Victor Julien about 5 years ago

  • Target version deleted (TBD)
Actions

Also available in: Atom PDF