Firewall

A web application firewall that checks every request to your web services and load balancers before it reaches your app.

A firewall checks every request before it reaches your app. It blocks attacks such as SQL injection and cross-site scripting, turns away bots and scanners probing for weak spots, turns away any one visitor making too many requests, and lets you allow or block addresses. Add one to any project with public web services.

A project has one firewall. Its rules apply to every web service and load balancer it protects, on any machine and in any zone. There's no machine or size to choose.

Create a firewall

On the project's Services page, click Add next to Firewall.
Under Protect, choose what it protects. Every web service and load balancer is on to start with. Each web service shows the machine it runs on.
Leave Protect new web services and load balancers on so that anything you add later starts behind the firewall, or turn it off.
Under Settings, keep the defaults or change any of them. See Rules.
Click Create firewall.

The form shows the monthly fee under Price. The firewall protects your services within a couple of minutes, and they stay online while it starts.

In an app Athena built, you can also type /firewall in Athena's box.

The settings start with these defaults:

Setting	Default
Block attacks	On, with the OWASP Core Rule Set
Block bots and scanners	On
Block ICMP traffic	Off
Rate limit	Standard, 300 requests a minute per visitor
Allowed addresses	None, so everyone can visit
Blocked addresses	None

What it blocks

Reason	What it means
Attacks	Requests the OWASP Core Rule Set recognises, such as SQL injection, cross-site scripting and remote code execution.
Bots & scanners	Tools probing for weak spots, such as requests for `/.env`, `/.git` or `/wp-admin`, and attack tools like sqlmap.
Rate limit	A visitor making more requests than the rate limit allows.
Blocked addresses	Addresses you blocked, and anyone outside your allowed addresses.

The firewall's Overview shows, for the Last 24 hours, how many requests it checked and how many it blocked for each reason. The counts update every few minutes.

A blocked visitor sees a short page saying so instead of your app.

Rules

Change the settings on the firewall's Rules page, then click Save changes. The page has the same settings as the create form. Changes go live within a minute on every machine, and your services stay protected while they roll out.

Block attacks

Checks every request against the OWASP Core Rule Set at its gentlest level, which rarely blocks real visitors. Turn it off only if part of your app is wrongly blocked and you can't work around it. The other settings keep working without it.

Block bots and scanners

On by default. Turn it off only if your site really is WordPress, or serves one of the paths scanners ask for.

Block ICMP traffic

Off by default. This is a setting for the project's machines rather than your web traffic: when it's on, the machines stop answering ping and traceroute. Removing the firewall turns it off again.

Rate limit

How many requests one visitor can make, with room for a page and everything it loads at once.

Setting	Requests a minute, per visitor
Off	No limit
Relaxed	1,200
Standard	300
Strict	60

A visitor over the limit sees Too many requests and can try again a moment later.

Rate limits your app sets itself, such as on sign-in attempts, keep working. The firewall passes each visitor's real address to your app, so your app can still tell visitors apart.

Allowed addresses

When the list has any addresses, only visitors from them can open what the firewall protects. This is useful for internal tools reached from your office or VPN. Leave the list empty to let everyone in.

Blocked addresses

Addresses that are always turned away.

Each entry on either list has a label and an IP address or a range, such as 203.0.113.0/24. Click Add address to add one. A list holds up to 200 entries.

Choose what it protects

On the firewall's Settings page, under Protects, turn load balancers and web services on or off, and turn Protect new web services and load balancers on or off. Then click Save. Anything you take out is reached directly again within a minute.

Request bodies

Form posts, JSON and XML bodies up to 1 MB are checked for attacks. Larger ones are refused with Too large. File uploads and other binary bodies pass to your app unchecked, whatever their size.

Where it runs

A copy of the firewall runs on each machine that has a web service it protects, in front of that service. Requests are checked on the machine they were already going to, so the firewall adds no extra stop on the way. If one machine goes down, the copies on the others keep protecting their services. The machine's memory bar on the Resources page shows each copy as Firewall (see Price).

A load balancer behind the firewall runs the same rules in its own proxies. See Load balancers.

If a copy stops

If the firewall's copy on a machine stops responding, that machine's web services are reached directly until it's back, and you get a notification naming the machine. The services stay online, unprotected, rather than going down with the copy. The copy goes back in front of its services by itself when it recovers.

The firewall's Overview shows each protected service as Protecting or Not responding.

Load balancers

The firewall can protect a load balancer. Its rules then check every request to the load balancer's address before a web service is chosen, in every zone the load balancer runs in. Each of the load balancer's proxies takes 64 MB more of its machine to run them.

It doesn't matter which you add first:

Add the firewall first, and a new load balancer starts behind it while Protect new web services and load balancers is on.
Add the load balancer first, and the firewall lists it under Protect when you create the firewall.

The web services in a load balancer have no addresses of their own, so the load balancer's rules protect everything that reaches them. Blocks at a load balancer count on the firewall's Overview with the rest.