Hacker News Reader

Comment by genpage | Hacker News Reader

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. :)

View on HN

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!

Reply on news.ycombinator.com