The mytardis-chef recipes shouldn't mess with firewall rules

[steveandroulakis]

I discovered this issue with my own in-house fork of the mytardis chef cookbook. Basically, I'm using the recipes in the context of a Chef installation for a large number of our servers, and (naturally) we want the firewall settings to be configurable according to the specific requirements of each node.

When I tried integrating our local firewall stuff into a machine using my mytardis cookbooks, I discovered that the nginx.rb recipe is unilaterally updating the firewall rules to allow universal SSH, HTTP and HTTPS access. Now this might be OK on a cloud virtual running a non-production MyTardis instance. But it is NOT OK on a production MyTardis system. And it is certainly not OK that the nginx.rb recipe is messing with the SSH access settings.

The fix is simple ... just remove the last 3 lines of the recipe. But it might cause you to need to make other changes elsewhere to compensate (in the cloud use-case) so I'm hesitant to submit a pull request.

The real problem here is that the Chef various iptables recipes (all of them I've been able to find!) work on the basis that they are creating an "iptables" file from scratch, rather than updating existing firewall settings. So basically if the "nginx.rb" file is going to create rules to allow HTTP and HTTPS, then >>something<< has to be creating a rule for SSH ... or else Chef is going to "brick" SSH access. Somebody took a pragmatic decision that "nginx.rb" should add the SSH rule, but that has bad consequences. In fact, the better solution is for the core mytardis recipes to NOT mess with this.

original LH ticket

This ticket has 0 attachment(s).

[steveandroulakis]

The mytardis-chef recipes shouldn’t mess with firewall rules

Tim: Do you agree with this? (the fw lines added were yours)

Assigned to you to get a response, you don’t have to do anything!

Cheers, Steve

by Steve Androulakis

[steveandroulakis]

The mytardis-chef recipes shouldn’t mess with firewall rules

The "somebody" in question was me, I’ll admit. As identified in the ticket, you need the rule if you don’t want Chef to brick your SSH access. On the cloud, losing SSH generally means "start from scratch".

Locking down SSH is generally a good idea, and I can see why opening SSH to world+dog is a bad thing.

However, I did spend a few years in corporate operations, so there’s a few reasons why it’s not as bad as it seems:

1. If you are running a production server without a completely separate hardware firewall protecting that subnet, then you’re asking for trouble.
   • Pretty much every cloud service includes a separate firewall around the VM.
   • IP/Port-based ACLs are pretty easy to implement even on the most basic Cisco routers.
2. You should not be using password-based SSH for privileged users in production.
   • Yes, this is an overhead. It does however virtually eliminate the chance of brute-forcing access to the host.
3. IPtables is not the last line of defence. You still have /etc/hosts.allow & /etc/hosts.deny available.
   • http://static.closedsrc.org/articles/dn-articles/hosts_allow.html

By all means, add a switch to disable iptables modification if a certain node attribute is present. However I think the default behaviour should still be to modify iptables.

by Tim Dettrick

[steveandroulakis]

The mytardis-chef recipes shouldn’t mess with firewall rules

by Tim Dettrick

[steveandroulakis]

The mytardis-chef recipes shouldn’t mess with firewall rules

My take was ... and is ... that putting any firewall configuration stuff into THAT recipe is wrong.

Any firewall configuration should be done in a different (typically site-specific) recipe. For instance, if you have a recipe for configuring a demo cloud virtual with MyTardis, then it would be appropriate to do the firewall configuration there.

But anyway, the CMM mytardis cookbook has diverged significantly from the "master" on github, so this issue is academic for me.

by Stephen Crawley

[steveandroulakis]

The mytardis-chef recipes shouldn’t mess with firewall rules

I’m leaning towards making it a configurable variable at the cookbook level (default: firewall rules in conf NOT PRESENT).

I’ll get back to you.

by Steve Androulakis