When logging requests to our servers using StackPath or Edgio (or even directly against the origin), we could check the IIS CGI.SERVER_PROTOCOL variable. We discovered that many, many spammers blindly use “HTTP/1.0” and we started logging all HTTP/1.0 form posts and discovered that they all were unwanted spam. After that, we started logging & blocking and have yet to identify any false positives.
I noticed that, since migrating to Fastly, that all HTTP requests are HTTP/1.1. Are HTTP/1.0 requests being auto-upgraded to HTTP/1.1? Less that 1% of all HTTP traffic uses 1.0 (or lower) and we’ve yet to see anything legitimate. I’ve created a corp rule to add a corp signal and will probably add a corp block rule in the near future. (Our unpublished API endpoints are whitelisted.)
Where can I find documentation on other request parameters that may be transformed/upgraded/changed in the course of a request?
However, we’re not “upgrading” requests from HTTP/1.0 to HTTP/1.1 as much as we just don’t support HTTP/1.0 connections at the edge. What’s likely happening is that the clients are either connecting with the upgraded spec or if they don’t support HTTP/1.1 whatsoever, the requests are being dropped.
ok. I see that I can add a corp rule condition to add a signal for any of:
Protocol Version equals HTTP/0.9
Protocol Version equals HTTP/1.0
… but I haven’t seen any “HTTP10” signals logged since adding the rule.
This probably means that this information is not available at my WAF level and abusers aren’t able to progress to use the more outdated protocol so that we can be easily block it.
This was one of the easiest & quickest security rules that we leveraged to identify & block abuse.
If there’s no way for HTTP/1.0 traffic to proceed and/or be identified by the WAF, why are the protocols available to be added as rule conditions? Should I delete this new rule as it seems that the conditions would never be met?
This is because the control settings can apply to origin-installed WAFs outside of Fastly’s origin. It’s not intuitive that it’s available for a Fastly-edge install, admittedly.
Should I delete this new rule as it seems that the conditions would never be met?
That seems reasonable. If you haven’t seen any traffic affected by the rule, it’s worth deleting it or maybe attempting to refine it to flag the original spambot issues (unless they’re being effectively stopped with other rules).
The “rule that will never work” in this environment has been disabled.
Again, this was the easiest rule that previously enabled us to block a lot of bogus spam requests with high precision and without much effort.
Please let me know if there’s any interest in receiving signals via our HTTP responses to aid in detecting similar abuse to other clients. I’d like to contribute data to the service that we’ve invested in using for the next 3 years.