As your sites become more popular, you'll notice that the odd actor will test the fences for vulnerabilities. Many of them are white-hats, trying to point out flaws in exchange for a bounty. But, some of them are bad actors. Whatever the case may be, the more data and tools you have at your disposal, the quicker you can respond. We'll look at a case which demonstrates how Fly Middleware can be used defensively.
Middleware 1: Google Analytics
The first indication that trouble was afoot came from the Real-Time Overview within Google Analytics. It's neat to see where people go and what they discover when they first land on our pages. We get a fair amount of traffic but, well, this looked odd from the eyes of a fledgling SaaS:
The number accelerated by hundreds every few seconds. Further analysis showed that all the traffic was originating from an IP in Paris and was requesting pages on our hostname that contained no actual content. It appeared as though someone was testing end-points using a tool like Burp Suite.
Typically, Google Analytics is served from the client; you attach the snippet to your
<HEAD> tag. If someone uses a client-side blocker like Ghostery or Disconnect.me, they can block the snippet. This leads to a phantom visit within your dashboard, a request tied to no-one.
We run the Fly server-side Google Analytics Middleware on our own pages. But, for a contrast, we've also been attaching the regular client snippet. During the incident yesterday, here's how both of them interpreted the stark increase in traffic. First, client-side Google Analytics:
Now, the server-side report:
The server-side report also includes the pages and pages of URLs that were being hammered - you can see what the intention was:
Discovering the source was interesting, but in order to put a stop to it we needed to have an IP address. To figure that out, it was off to look within the server logs.
Middleware 2: Papertrail Syslog
While polishing up our Papertrail Syslog Middleware, we created a Papertrail account and started importing data. Within Papertrail, it was immediately clear that someone was up to no good. There were thousands upon thousands of erroneous requests per second.
... Aug 30 16:07:19: XXX.XXX.XXX.XXX - - [2017-08-30T23:07:19.247767641Z] "GET /security/admin_reset.html HTTP/1.1" 404 19 "" "Mozilla/4.0 (compatible; MSIE 6.0b; Windows NT 5.1)" Aug 30 16:07:19: XXX.XXX.XXX.XXX - - [2017-08-30T23:07:19.283743651Z] "GET /security/admin_reset.zip HTTP/1.1" 404 19 "" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 7.0; InfoPath.3; .NET CLR 3.1.40767; Trident/6.0; en-IN)" Aug 30 16:07:19: XXX.XXX.XXX.XXX - - [2017-08-30T23:07:19.490763848Z] "GET /security/admin_reset.php HTTP/1.1" 404 19 "" "Mozilla/5.0 (Windows; U; MSIE 9.0; WIndows NT 9.0; en-US))" Aug 30 16:07:19: XXX.XXX.XXX.XXX - - [2017-08-30T23:07:19.554069372Z] "GET /security/admin_review HTTP/1.1" 404 19 "" "Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2226.0 Safari/537.36" ...
After retrieving the IP address,
XXX.XXX.XXX.XXX, it was time for a-blacklistin'.
Middleware 3: Web Application Firewall
The Web Application Firewall is a piece of Middleware you can activate in a click or two. We placed the IP within the blacklist:
In an instant, the requests subsided. Our Syslog returned to normal and server-side Google Analytics followed suite. The client-side instance remained the same, blissfully unaware.
While this was a relatively benign attempt, it felt like an interesting case for clear, accurate, and accessible logging and an easy-to-use application firewall. With an organized proxy, powerful defensive features become less complex and are applied ubiquitously to any service or back-end that you've attached to your hostname. Fly started when we wondered "what would a programmable edge look like"? Developer workflows work great for infrastructure like CDNs and optimization services. You should really see for yourself, though.
Make Your Applications Fly
Faster apps, simpler tools, happier visitors.Free Signup