Consegna Blog

Recently we discovered that a customer’s website was being attacked in what is best described as a “slow DoS”. The attacker was running a script that scraped each page of the site to find possible PDF files to download, then was initiating many downloads of each file.

Because the site was fronted by a Content Delivery Network (CDN), the site itself was fine and experienced no increase in load or service disruption, but it did cause a large spike in bandwidth usage between the CDN and the clients. The increase in bandwidth was significant enough to increase the monthly charge from around NZ$1,500 to over NZ$5,000. Every time the customer banned the IP address that was sending all the requests, a new IP would appear to replace it. It seems the point of the attack was to waste bandwidth and cost our customer money — and it was succeeding.

The site itself was hosted in AWS on an EC2 instance, however the CDN service the site was using was a third party — Fastly. After some investigation, it seemed that Fastly didn’t have any automated mitigation features that would stop this attack. Knowing that AWS Web Application Firewall (WAF) has built in rate-based rules we decided to investigate whether we could migrate the CDN to CloudFront and make use of these rules.

All we needed to do was create a CloudFront distribution with the same behaviour as the Fastly one, then point the DNS records to CloudFront — easy right? Fastly has a neat feature that allows you to redirect at the edge which was being used to redirect the apex domain to the www subdomain — if we were to replicate this behaviour in CloudFront we would need some extra help, but first we needed to make sure we could make the required DNS changes.

To point a domain at CloudFront that is managed by Route 53 is easy, you can just set an ALIAS record on the apex domain and a CNAME on the www subdomain. However, this customers DNS was managed by a third-party provider who they were committed to sticking with (this is a blog post for another day). The third-party provider did not support ALIAS or ANAME records and insisted that apex domains could only have A records — that meant we could only use IP addresses!

Because CloudFront has so many edge locations (108 at the time of writing), it wasn’t practical to get a list of all of them and set 108 A records — plus this would require activating the “static IP” feature of CloudFront which gives you a dedicated IP for each edge location, which costs around NZ$1,000 a month.

And to top all that off, whatever solution we decided to use would only be in place for 2 months as the site was being migrated to a fully managed service. We needed a solution that would be quick and easy to implement — AWS to the rescue!

So, we had three choices:

1. Stay with Fastly and figure out how to ban the bad actors
2. Move to CloudFront and figure out the redirect (bearing in mind we only had A records to work with)
3. Do nothing and incur the NZ$5,000 cost each month — high risk if the move to a managed service ended up being delayed. We decided this wasn’t really an option.

We considered spinning up a reverse proxy and pointing the apex domain at it to redirect to the www subdomain (remember, we couldn’t use an S3 bucket because we could only set A records) but decided against this approach because we’d need to make the reverse proxy scalable given we’d be introducing it in front of the CDN during an ongoing DoS attack. Even though the current attack was slow, it could have easily been changed into something more serious.

We decided to stay with Fastly and figure out how to automatically ban IP addresses that were doing too many requests. Aside from the DNS limitation, one of the main drivers for this decision was inspecting the current rate of the DoS — it was so slow that it was below the minimum rate-based rule configuration that the AWS WAF allows (2,000 requests in 5 minutes). We needed to write our own rate-based rules anyway, so using CloudFront and WAF didn’t solve our problems straight away.

Thankfully, Fastly had an API that we could hit with a list of bad IPs — so all we needed to figure out was:

1. Get access to the Fastly logs,
2. Parse the logs and count the number of requests,
3. Auto-ban the bad IPs.

Because Fastly allows log shipping to S3 buckets, we configured it to ship to our AWS account in a log format that could be easily consumed by Athena, and wrote a couple of AWS Lambda functions that:

1. Queried the Fastly logs S3 bucket using Athena,
2. Inspected the logs and banned bad actors by hitting the Fastly API, maintaining state in DynamoDB,
3. Built a report of bad IPs and ISPs and generated a complaint email.

The deployed solution looked something like this:

By leveraging S3, Athena, Lambda and DynamoDB we were able to deploy a fully serverless rate-based auto-banner for bad actors with a very short turnaround. The customer was happy with this solution as it avoided having to incur the $5000 NZD / month cost, avoided needing to change the existing brittle DNS setup and also provided some valuable exposure into how powerful serverless technology on AWS is.

It’s implementing solutions like this that helps set Consegna apart from other cloud consultancies — we are a true technology partner and care deeply about getting outcomes for customers that align with their business goals, not just looking after our bottom line.

At Consegna we pride ourselves on our experience and knowledge.  Our recently appointed National Client Manager has a knack for knowing virtually everybody in Wellington. This can be amusing if you’re with him as a 10 minute walk down Lambton Quay can take half an hour. We tend to now leave gaps that long between meetings. One of the questions he will ask people is one we probably all ask, “how’s business?”  The answer is always the same, “busy!”

Now sometimes that can just be a standard answer, but if it’s true and we’re all so busy then what are we busy doing? We would like to think we’re doing super innovative work but how much time do we actually dedicate to innovation? Most of the time we’re busy just trying to complete projects. Google famously scraped their “20% time” dedicated to innovation because managers were judged on the productivity of their teams and they were in turn concerned about falling behind on projects where only 80% capacity was used. Yet, the flipside of that was that  “20% time” formed the genesis of Gmail, Adsense and Google Talk.

So this leads on to thinking how can we continue to create when we’re all so busy? We have to be innovative about being innovative.  One solution that organisations have been working on is the idea of a hackathon. A short period of time, usually around 48 hours, for organisations to stop what they’re doing and work on exciting new things that traditionally might be out of scope or “nice to haves”.

Consegna was selected as the University of Auckland cloud enablement partner in 2017 and were recently involved with the University’s cloud centre of excellence team who wanted to promote and facilitate innovation within their internal teams. One answer to create more innovation was hosting a Hackathon with Auckland University internal teams. In total there were 17 teams of 2-6 people a team. They were tasked with trying to solve operational issues within the University – and there were a number of reasons we jumped at the chance to help them with their hackathon.

First and foremost we liked the idea of two days being used to build, break and create. We were there as the AWS experts to help get the boat moving, but deep down we’re all engineers and developers who like to roll up our sleeves and get on the tools.

Secondly, after watching larger companies like Facebook define why they use Hackathons, it resonated with the team at Consegna. “Prototypes don’t need to be polished, they just need to work at the beginning”. Facebook Chat came out of a 2007 Hackathon which evolved into Web Chat, then Mobile Chat which then became Facebook Messenger as we know it today. The end result of a hackathon doesn’t need to be be pretty, but the potential could know no bounds. Consegna were able to help Auckland University build something where its success was not judged on immediate outcomes, but on the potential outcomes to do amazing things.

Hackathons can also be incredibly motivating for staff members. For those of you who are familiar with Daniel Pink’s book “Drive”, you’ll know money doesn’t always motive staff like we traditionally thought it did. Autonomy, Mastery and Purpose are key parts of Pink’s thinking but also the key to a successful hackathon. The business is not telling you how to do something and in a lot of cases, the guidelines can be very fluid in that they’re not telling you what to build. A guiding question to a successful hackathon can be succinctly put as “what do you think?”

We applaud Auckland University for inviting us along to allow their staff members to pick our brains and learn new things. Want to know how to program Alexa? No problem! How can I collect, process and analyse streaming data in real time? Talk to one our lead DevOps Architects, they’ll introduce you to Kinesis. There was as much learning and teaching going on at the hackathon as there was building some amazing applications.

It’s important to be aware of potential pitfalls of hosting a hackathon and to be mindful you don’t fall for the traps. You want to make sure you get the most out of your hackathon, everybody enjoys it and that there are plenty of takeaways otherwise bluntly, what’s the point?

Hackathons as a general rule don’t allow for access to customers. If you’re wanting to dedicate just 48 hours to solve a problem then how can you have understanding and empathy for customers if they’re not around? If they’re not there to collect feedback and iterate can you even build it? Auckland University got around that problem by largely building for themselves; they were the customer. They could interview each other for feedback so this was a tidy solution so if you think a hackathon will offer a solution for customer-facing applications you might want to think about either making customers available for further enhancements outside of the hackathon or think of a different innovation solution altogether.

Before I mentioned how Facebook use hackathons to inspire innovation, but there is one downside – they’re unpaid and on weekends. Employees can feel obligated to participate to please hierarchies which forces innovation out of their staff. Generally, this is not going to go well. The driving factors Pink mentions are not going to be as prevalent if staff are doing it in their own time, usually without pay – to build something the business owns. From what I’ve seen Facebook put on some amazing food for their hackathons but so what? Value your staff, value the work they do and don’t force them to do it on their own time. Auckland University’s hackathon was scheduled over two working days, in work time and made sure staff felt valued for what ultimately was a tool for the University.

Over the two days, the 18 teams presented their projects and there were some amazing outcomes. MiA, the winner, used a QR code on a big screen so students can snapshot the QR code and register their attendance to each lecture. This was done with an eye on Rekognition being the next iteration and using image recognition software to measure attendance. Generally speaking, there’s not a whole lot wrong with how the University currently measures attendance with good old fashioned pen and paper but how accurate is it when you’re allowing humans to be involved and how cool is it for an AWS product to take the whole problem away?

In all, it was an amazing event to be a part of and we must thank Auckland University for inviting us. Also thanks to AWS for providing a wealth of credits so there was no cost barrier to building and creating.

If you’re thinking of hosting your own hackathon I wish you well. It’s a great way to take a break from being busy and focus on creating new tools with potentially unlimited potential. It will get your staff scratching a learning and creative itch they’ve been aching to get at.

Most importantly, always take time and make strategies to keep innovating. Don’t be too busy.