4 ms·
(DO employee here) The intro article answers many of these questions (and more): https://www.digitalocean.com/community/tutorials/an-introduction-to-digitaloce
by beardicus 9y ago
(DO employee here)
The intro article answers many of these questions (and more): https://www.digitalocean.com/community/tutorials/an-introduction-to-digitalocean-cloud-firewalls 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!
- peterwwillis 9y agoJust 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.
- beardicus 9y agoIt'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.
- peterwwillis 9y agoOh... 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)
- beardicus 9y agoThe firewalls are stateful, with connection tracking.