Disclaimer: DO Support here

The traffic is blocked/allowed at our network layer before being routed to the droplet. The rules are easily configurable through the control panel and API. You can also specify Droplets (individual or tagged) and our recently new Load Balancers as the targets.

You can also layer multiple firewalls on top of one another if you want to apply specific firewall rules to only a specific set of Droplets/LBs

The Intro tutorial we have is great for details: https://www.digitalocean.com/community/tutorials/an-introduc...

Feel free to reach out to us if you have any more specific questions. :)

How many firewalls can a single user create, and how many rules can be in each firewall? How is the order of multiple firewalls applied to the same droplet determined? Where is there logging to show when a rule matched? Is there any future plan to support REJECTing packets rather than only DROPing? Will the user interface warn the user when they are about to block all traffic (including ssh) to a droplet?

(DO employee here)

The intro article answers many of these questions (and more): https://www.digitalocean.com/community/tutorials/an-introduc...

> How many firewalls can a single user create, and how many rules can be in each firewall?

100 firewalls, 50 rules per firewall

> How is the order of multiple firewalls applied to the same droplet determined?

The rules are all added together and applied at the same priority. Order doesn't matter.

> Where is there logging to show when a rule matched?

No logging is available.

> Is there any future plan to support REJECTing packets rather than only DROPing?

No plans for this.

> Will the user interface warn the user when they are about to block all traffic (including ssh) to a droplet?

There are no footgun warnings, no.

Let me know if you have more questions... thanks!

Just checking if I have this right...

> The rules are all added together and applied at the same priority. Order doesn't matter.

If I make several firewalls, and the order of the rules when mixed results in unexpected traffic flows compared to the firewalls being applied individually, I have a bug that is hard to see, only experience during traffic as "timeout" or "not a timeout", and because of a lack of logging, no way to troubleshoot other than rewriting all the firewalls to try to remove any possibility of conflict, or writing whole new firewalls.

If I understood correctly, it's basically unsafe to mix more than one firewall per droplet, and in general a pain to troubleshoot. This is in contrast to iptables, where you can have multiple tables and chains, they follow a prescribed order, and you can mix and match them with expected results. Not to mention you can add logging whenever you need it.

It's possible you're assuming the firewalls have more rule types than they actually do. Basically these firewalls default to dropping all packets, and any rules you add are to accept a port or port range. Adding such rules together is simple and doesn't depend on order.

Oh... I hadn't quite grasped the limitations. So these "firewalls" are basically two chains with a drop policy and rules with ACCEPT jump targets, and either a source or destination. This seems to be a port whitelist rather than a firewall.

It does seem that if you create one single firewall per role, this is a simple and effective means of applying really basic port access rules to a large number of droplets at once. But by calling it a "firewall", people actually believe it replaces a real modern firewall and have actually dropped real firewalls from their droplets, making overall security worse. Not to mention the many ways you could accidentally open up or restrict more than you wanted to.

Maybe I missed something again. It says your firewalls are stateful. Are the input rule targets really "NEW,ESTABLISHED" and the output rule targets really "ESTABLISHED,RELATED" ? If they are doing connection tracking and verifying the 3way handshake before passing on the connection, I suppose this is useful to prevent syn floods that don't complete a handshake. I'd be interested to know what actual protection these firewalls give other than port whitelisting. (And yes, I see a generic icmp type is included as well as tcp & udp)

The firewalls are stateful, with connection tracking.

Question. Does DO log access to a clients vps in some way if they do not have the cloud firewall product?

In other words if a VPS has traffic to http https ssh ftp and so on coming in from all over. Does DO have logs that show that traffic where it's coming from and where on DO it's going to? Or does DO only know who has spun up and requisitioned the VPS?

(Same question for the firewall product as well).

We do not log any type of network access to a client Droplet/VPS. Whether they use Cloud Firewall or not.

I hope that answers the question. If you have more or would like more information, feel free to reach out to our Support team!

The same thing that their load balancer project offers over HAProxy + Ansible - the ability to configure it via their API (or their Web UI) and have DigitalOcean own the implementation and management of everything. This includes making improvements under the hood, security updates, etc.

There's very little you can't do with enough Ansible and other utilities, but letting your cloud hosting provider handle it comes with a lot of benefits.

Ive always like Ansible/Puppet/file storage. I can quickly boot from ethernet, populate a req key from puppet from ansible, load puppet to the appropriate config needed, and off I go.

No having to dork with servers one at a time. And with Ansible, if I change puppet manifests, I can reload puppet with ansible instead of waiting the default 30m.

iptables will consume resources on your droplet (CPU/network) to filter out the traffic. Cloud Firewalls are applied directly by the DO network, before ever hitting any of your droplets, so it uses none of your resources.

It defines a firewall outside of your machine so your iptables/firewalld configuration on individual droplets can be much simpler. (assuming it works like security groups on AWS, create one apply to many.)

For example, let all your Droplets talk to each other (and no one else), but not have to explicitly track the list of IPs and generate firewall rules from that list on every host every time it changes.

Deny outbound access except through specific hosts (config management, internal package mirrors) so that even an attacker with root can't phone home.

The same reasons anyone uses firewall devices vs. host-based firewalls.

Point and click configuration for those of us not so comfortable with text files, I guess

A GUI. Seriously though, they are probably using the technologies that you mentioned (or some equivalent) under the hood.