Firewall role

[c-goes]

• [x] disable LXD auto rule generation
• [x] add role to infrastructure.yml playbook
• [x] .gitignore for rules file
• [x] NAT rules?
• [ ] service_ports -> read from json/yaml files?
• [ ] are all services using TCP, not UDP?
• [ ] test bash scripts in scripts/
• [x] remove delegate_to
• [ ] PR

[c-goes]

I could push changes to your branch for the first item in task list

[c-goes]

@antfeh Do you plan to implement packet anonymization (for team-to-team connections) with the firewall role? I found this https://www.usenix.org/system/files/conference/ase17/ase17_paper_trickel.pdf

Maybe a router container that anonymizes with NAT the scorebot traffic and also the traffic from teams. I've had this feature in my head for a long time, but haven't made it yet. It would be great if you could do it.

[antfeh]

I could push changes to your branch for the first item in task list

You are welcome to do this.

[c-goes]

Done. Also disabled automatic LXD NAT rule generation via roles/infrastructure_lxd/vars/main.yml configurable. You could add the NAT rules now for internet access (at least for installation of the services). You can test your rules now via Vagrant. I'm going to add a router container for anonymization, but I'm not sure what iptables rules hat needed. We need to route (from 10.38.1.1 and from all the teams, destination is all services) through it with NAT.

[antfeh]

Removed the delegate_to statements.

[antfeh]

Done. Also disabled automatic LXD NAT rule generation via roles/infrastructure_lxd/vars/main.yml configurable. You could add the NAT rules now for internet access (at least for installation of the services). You can test your rules now via Vagrant. I'm going to add a router container for anonymization, but I'm not sure what iptables rules hat needed. We need to route (from 10.38.1.1 and from all the teams, destination is all services) through it with NAT.

If we use a container for anonymization wouldn't it create a bottleneck for all our traffic? The other thing that bothers me: even if we anonymised the traffic, what do we gain from it? The firewall rules should be enough to handle unwanted connections.

[c-goes]

If we use a container for anonymization wouldn't it create a bottleneck for all our traffic?

Should be no problem with the 10 GBit container networking. Maybe the NAT slows it down a bit.

The other thing that bothers me: even if we anonymised the traffic, what do we gain from it? The firewall rules should be enough to handle unwanted connections.

From the linked paper: "First, it forwards all team-to-team transmissions and official service verification transmissions that verify each team’s service is running properly. While forwarding these transmissions,it anonymizes the packets by masquerading all the traffic as itself. Thus, when a team receives a packet it has the source IP of the Router. We designed it this way to prevent teams from dropping traffic from their competitors while allowing the service checks to get through. One interesting development note is that this was not as straight forward to setup as we thought because the AWS network prevents masquerading by default [7]. To bypass this restriction, the source/destination checking must be disabled."

Not sure how hard it is to implement. Let's make it work first without the router container (internet access etc.)

[antfeh]

Ok! Looks good. I just briefly went over the paper, so i missed the important parts :D