5 ms·

Isn't this just doing the same exact thing as iptables only worse since it's not transparent to the operating system? I've created bad firewall rules by mistak

Isn't this just doing the same exact thing as iptables only worse since it's not transparent to the operating system? 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.

NetStrikeForce 9y ago
Most people don't need anything more complex than this for their firewall needs, so iptables is overkill. 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)
- egeozcan 9y ago
  > Not only that, but iptables is just terrible to use and it just makes you want to kill yourself. 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.
- tasn 9y ago
  iptables is terrible, but nftables is great and mostly available. I wrote a post about my nftables config a while back. Plug: https://stosb.com/blog/explaining-my-configs-nftables/ https://stosb.com/blog/explaining-my-configs-nftables/
derefr 9y ago
1. These are stack-neutral: they let "cloud orchestrator" software plug one service into another by starting up Instance B and then opening the firewall port on Existing Instance A to talk to it, without having any ability to talk to or manage Existing Instance A, let alone knowledge of what it would have to say. Existing Instance A might be a Windows Server instance, or some custom unikernel; this approach would still work. 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.
gr2020 9y ago
Sometimes software like Docker (in certain network configurations) will use iptables for its own purposes, clobbering some of your own iptables rules. Having an external firewall for access control is super advantageous in cases like this.
- tomsthumb 9y ago
  Docker in _most_ (all?) situations on linux will use IPTables to allocate and admin it's networks and interfaces.
calpaterson 9y ago
Many many people work in environment where their machines are firewalled by a different time so perhaps it's no worse to them. These sorts of services are never as flexible as iptable and friends but they're still useful, especially for defense in depth (my planned usage).
ionrock 9y ago
Personally, I think it is more convenient to think about things like this (ie firewall rules) as data, which makes the use of an API a convenient way to work with the data. The converse, in my mind, is that I'd have to configure each node and ensure a text representation of my firewall rules are correct. That opens the door for some thinking about concurrency that I thankfully get to avoid with an API like this. 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.

NetStrikeForce 9y ago

Most people don't need anything more complex than this for their firewall needs, so iptables is overkill. 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)

egeozcan 9y ago
> Not only that, but iptables is just terrible to use and it just makes you want to kill yourself. 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.
tasn 9y ago
iptables is terrible, but nftables is great and mostly available. I wrote a post about my nftables config a while back. Plug: https://stosb.com/blog/explaining-my-configs-nftables/ https://stosb.com/blog/explaining-my-configs-nftables/

derefr 9y ago

1. These are stack-neutral: they let "cloud orchestrator" software plug one service into another by starting up Instance B and then opening the firewall port on Existing Instance A to talk to it, without having any ability to talk to or manage Existing Instance A, let alone knowledge of what it would have to say. Existing Instance A might be a Windows Server instance, or some custom unikernel; this approach would still work. 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.

gr2020 9y ago

Sometimes software like Docker (in certain network configurations) will use iptables for its own purposes, clobbering some of your own iptables rules. Having an external firewall for access control is super advantageous in cases like this.

tomsthumb 9y ago
Docker in _most_ (all?) situations on linux will use IPTables to allocate and admin it's networks and interfaces.

calpaterson 9y ago

Many many people work in environment where their machines are firewalled by a different time so perhaps it's no worse to them. These sorts of services are never as flexible as iptable and friends but they're still useful, especially for defense in depth (my planned usage).

ionrock 9y ago

Personally, I think it is more convenient to think about things like this (ie firewall rules) as data, which makes the use of an API a convenient way to work with the data. The converse, in my mind, is that I'd have to configure each node and ensure a text representation of my firewall rules are correct. That opens the door for some thinking about concurrency that I thankfully get to avoid with an API like this. 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.