Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

http dpd sigs don't trigger for large requests #343

Open
JustinAzoff opened this issue Apr 23, 2019 · 3 comments

Comments

Projects
None yet
2 participants
@JustinAzoff
Copy link
Contributor

commented Apr 23, 2019

Attached is a pcap where the client sends a 1500byte or so http request to the server

http_large_req_8001.zip

even though the request starts with "GET" and the response starts with "HTTP " the dpd signature doesn't match because the client request exceeds the default dpd_buffer_size of 1024 bytes. Only 5 bytes from each flow should have been needed to identify this as HTTP.

@jsiwek

This comment has been minimized.

Copy link
Member

commented Apr 24, 2019

Only 5 bytes from each flow should have been needed to identify this as HTTP.

If you're requiring a match from both directions to identify it as HTTP, then it's more like you need 5 bytes from resp, but an arbitrary number of bytes from orig because we need to buffer everything orig sends for replaying into the analyzer that gets instantiated whenever the match finally occurs.

Is the idea here to change to default dpd.sig for HTTP so that it has no requires-reverse-signature dependency and just enables HTTP analysis on matching either orig or resp signature, but not necessarily both ?

Otherwise, seems it's a question of tuning the dpd_buffer_size -- either leaving it up to each site to do that, or upping our default if there's good reason to think it's deficient for a lot of users.

(I did take a peek into DPD matching code/logic and didn't notice any obvious bugs there -- I generally could make sense of it, and still seems like it's the way things should be done generally, but possible I'm overlooking a better solution)

@JustinAzoff

This comment has been minimized.

Copy link
Contributor Author

commented Apr 24, 2019

yeah, I wonder if http sigs should be relaxed in cases where the client is obviously HTTP.. like maybe not 100% confirmed as http, but attach the analyzer earlier to see what it does

@JustinAzoff

This comment has been minimized.

Copy link
Contributor Author

commented May 13, 2019

I've since seen this on two more cases:

A powershell HTTP request on port 4615 with a 4k Authorization: Kerberos .... header

An apache struts exploit

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.