Cloud Firewalls
digitalocean.com
digitalocean.com
It'll be interesting to see what the tooling support looks like for this, it looks like it's launching with API support day one: https://developers.digitalocean.com/documentation/v2/ which is great. It looks like they're already working to get it into Terraform: https://github.com/hashicorp/terraform/pull/15121 which is fantastic!
I look forward to the day that I can automatically spin up a DigitalOcean set of Droplets running Kubernetes using this.
Stackpoint.io can do this, you paste your DO API key and get a k8s cluster in a few minutes. Would be nice if DO built something like that in-house.
Curious, why? Isn't it much nicer to keep that separate from DO so that you can move away from DO easily should there be a reason to?
I'm not sure if I'm weird this way, but one main reason we use DO and not, say, AWS is because we're afraid of vendor lock-in. The more we depend on specialized services, the harder it gets to move somewhere. I wonder whether this is a common sentiment in 2017 or whether I'm just old-fashioned.
I've created bad firewall rules by mistake many times and enforcing them transparently so the machines can't see them makes the issue almost impossible to debug and fix.
Of course I have the same gripe with AWS VPC setups I guess... I just think it's funny how the cloud keeps reinventing cloud versions of things that perform objectively worse than the original, but then everyone still uses them out of pure convenience or stupidity.
Not only that, but iptables is just terrible to use and it just makes you want to kill yourself.
I've deployed a pretty standard policy now in DO with a couple of clicks, works as expected.
(And before anyone jumps, you should be using a host firewall too; defence in depth)
I can't agree more. Luckily though, if you have some setup scripts that you reuse, you don't have to think about iptables... Until the moment that you need to make this harmless quick change that shouldn't cause any problems and you end up locking yourself out of the server somehow.
I wrote a post about my nftables config a while back.
Plug: https://stosb.com/blog/explaining-my-configs-nftables/
2. Depending on how they've implemented this, traffic that hits their firewall and bounces off might not be counted toward your bandwidth bill (presuming there's any part of DO's services that bills for bandwidth.) Once the traffic is served to your instance, they can't know whether your instance's OS firewall has just thrown it away, so they have to assume it hasn't and bill you for that. SDN-level firewalls enable "automatic DDoS protection"-type services, where you receive (and get charged for!) regular traffic, but not malicious traffic.
That said, I can see your point that you are hiding some details from the OS that might be helpful such as what hosts you can talk to.
Fortunately, just because you might configure a firewall with an API rather than some Ansible plays, it doesn't mean that you can't continue to use Ansible to fill in the gaps. For example, if you did use Ansible to previously configure your iptables, you might change the playbook to call the API based on some YAML. You might use the same YAML to write some information on the host that your application can use to understand the firewall rules that are used.
The point being is that it is always good to remember these are not either/or decisions.
Lastly, I'll also speak up for those folks that don't know much about firewalls and iptables. I understand the principles, but I'm far from feeling confident managing that system myself. In my case, I'm really glad to have an option that lets me get the benefits without forcing me to operate a system I'm not well equipped to do.
We occasionally experience problems with %steal due to other VMs in the same host. It was a lot worse when we had a critical service hosted in Linode, but that was gutted and moved to actual hardware. Only a small, low-traffic bit still remains in Linode.
What kind of issues are you running into? There's a lot of issues that can happen on a server, but a lot of them are due to not enough resources or a misconfiguration.
Now, if your server is seeing constant issues on the host your server is on...
I love these features but double the RAM for the same price still outweighs them.
Do you consider this when you're talking about value? I know little about vultr.
5 vs 10 vs 20 vs 40 dollars doesn't mean much, and Linode pricing starts to converge on DO's after the $80 price point.
This depends entirely on what you're doing with it. For a hobby project, it makes a big difference to me.
Linode is like that old king on the block. They've had security issues in the past (multiple) and since they do store your credit card information those did get released (If I recall). They're decent and they work. They're a bit slower than the other two in my opinion, but they work and that's something I need.
DigitalOcean has been fairly solid and reliable. Yeah you can say you get more resources for how much you spend elsewhere, but DigitalOcean has been more reliable and solid than Vultr. I mean I remember opening support tickets with them and their response being "We took care of someone else on that node. Go ahead." Took me a solid 2 hours just to install a Ubuntu image on one of their (Vultr's) storage nodes. DigitalOcean has never had to give those kinds of responses to me and overall performance and the composition of their nodes has been fairly solid and reliable.
Yeah Vultr and Linode are cheaper and you get more, but I really feel DigitalOcean is solid and more reliable than Vultr. I mean Vultr's SLA is 100% uptime, but their credit return policy is to the effects of "we'll just give you your cheap money back". I don't care about credits and I just want my service online and not having to worry about anything, and most of Vultr's answers has usually been "wait" or "we did it" (but no real long-term solution to the problem). DO has been focusing on providing long-term solutions to problems I've had and no "bs" excuses. Linode has been solid as well, but don't have many of the features DO is starting to roll out with (which fair enough, it's their decision). DO has nothing but praise from me.
To secure internal traffic on DO you have to encrypt it, using for example something like tinc.
That might not be a big deal, or it might mean your site is 100% broken. I can't guess, but I'd assume since you went to the effort to setup a store you need it in some way.
(No backups? Of a database? That's one power-cut, or hardware failure away from complete data loss too!)
Besides latency, data protection issues also become a problem when you cross borders. My employer's (SAP) cloud platform advertises as a unique selling point that they have data centers in a wide variety of locations, so that a customer's data never has to leave their jurisdiction (which is important e.g. for government and its contractors).
And that's before we get to high-availability setups. Remember how AWS us-east was down just a few months ago?
After that we will be doing a customer beta followed by a GA release scheduled for Q3.
=]]
It's a bit of a fluid process as it depends on the type of service, product, feature, we are rolling out.
My biggest takeaway from the experience was how much the simplicity and speed of DO's dashboard interface stood out - the AWS web interface just felt laggy by comparison. I know it sounds like a poor reason to favour a platform but DO was just a simple pleasure to navigate and use.
Love how DigitalOcean allows you to specify droplets as sources, groups of droplets (tags) as sources, or CIDR ranges.
In other words, you can take down any Digital Ocean site for 24 hours after paying $1 to a booter unless they are behind CloudFlare or some other mitigation.
I was able to provision a new droplet right away, so the downtime was minimal. I think the way DigitalOcean handled the incident was perfectly reasonable, and was a much better experience than I've had with other cloud providers in the past.
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.
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.
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. :)
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!
> 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 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)
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).
I hope that answers the question. If you have more or would like more information, feel free to reach out to our Support team!
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.
Computer firewalls are similar in that they are designed to protect the computer (the passenger compartment) from security threats (fire). Just like the firewall in your car, a firewall on a computer probably won't completely prevent security threats from getting through but it will help.