Add firewalls

[keyctl]

On recent Debian distributions, nftables is recommended instead of iptables.

Necessary ports in our system:

• *
  • 22 TCP (internal)
• aslans*
  • 22 TCP (external)
• aslcert*
  • 443 TCP (internal)
• asldb*
  • 3306 TCP (internal)
  • 4567 TCP, UDP (internal)
  • 4568 TCP (internal)
  • 4444 TCP (internal)
• aslld*
  • 80 TCP (external)
  • 443 TCP (external)
• asllog*
  • 10514 TCP (internal)
• aslweb*
  • 80 TCP (internal)
  • 443 TCP (internal)

[keyctl]

Not sure what to give priority here, network firewalls or host-based firewalls?

[Miro-H]

If we say we use two network firewalls, one before the webservers and one after them, we could pretend that they are some professional firewall product instead of just nftables rules on a host, because we could not implement that with VMs in another way. (this is how the TA hinted that their group did it last year)

[keyctl]

If we say we use two network firewalls, one before the webservers and one after them, we could pretend that they are some professional firewall product instead of just nftables rules on a host, because we could not implement that with VMs in another way. (this is how the TA hinted that their group did it last year)

So you say we should focus on the network firewalls?

[Miro-H]

So you say we should focus on the network firewalls?

In my opinion, yes

[keyctl]

So one problem I see with this is that my machine runs low on memory already with 8GB of RAM. Although that is with Firefox running, but without logging and backup infrastructure. How much resources can we assume other teams to have? I mean, in total this will be around 10 machines then.

[Miro-H]

True, but this shouldn't be a restriction to our architecture design in my opinion. We could still tell them that they can use the non-redundant version for testing

[keyctl]

@Miro-H We don't have machines for the firewalls yet. Are these meant to be created anyways?

[keyctl]

Also, I'm not sure if we can simply separate the network again as with the external network for the client. I think for having a proper setup with explicit firewall hosts we should mimic the physical separation, which can only be induced by using separate networks, right?

[Miro-H]

@Miro-H We don't have machines for the firewalls yet. Are these meant to be created anyways?

Yes, I think we should create firewall machines, otherwise we have no firewall?

[Miro-H]

Also, I'm not sure if we can simply separate the network again as with the external network for the client. I think for having a proper setup with explicit firewall hosts we should mimic the physical separation, which can only be induced by using separate networks, right?

You're right, we need to introduce another network so that we have: aslclient <-net1-> aslfw01 <-net2-> aslweb <-net2-> aslfw02 <-net3-> aslcert, asldb, aslbkp, asllog, aslans

[Miro-H]

@keyctl Stumbled across other ports that must be open:

• All servers, internal network
  • 22 SSH (for ansible configuration)
• ansserver, public network
  • 22 SSH (for remote administration)

Also, how do we access the ansserver? Directly or through the firewall?

[keyctl]

Also, how do we access the ansserver? Directly or through the firewall?

The "better" option would be using SSH over VPN, but this is very troublesome to set up. We may have to expose the configuration server to the public internet.

[keyctl]

@Liblor Are there any ports that have to be exposed from asldb machines other than 3306?

[Liblor]

Currently that should be the only port. For the replication part we'd need some other ports, if there's a way to get it working. I'll look into it.

[keyctl]

aslclient <-net1-> aslfw01 <-net2-> aslweb <-net2-> aslfw02 <-net3-> aslcert, asldb, aslbkp, asllog, aslans

I wonder how the routing should be done in this scenario. Should we manually set the routes here, or am I missing a more convenient solution?

[Miro-H]

I'd set them manually in the /etc/hosts?

[keyctl]

But this is not about retrieving an IP, but to know where to send the IP packets targeted at an IP. The /etc/hosts does not provide functionality to set a gateway, does it?

[Miro-H]

The /etc/hosts does not provide functionality to set a gateway, does it?

I don't think so either. I though about the wrong thing, I was thinking about a single host that wants to send a packet to some hostname, because then he should pick the right network interface for the translated IP automatically. But I think you're right, on the firewalls we need basic routing.

[keyctl]

But I think you're right, on the firewalls we need basic routing.

Not just the firewalls, sorry for being picky here. All hosts need to know where to send their packets. For instance, aslweb* needs to be able to respond to the client directly, but send all other packets to the firewall separating the DMZ (without specifying this firewall as destination). So, the hosts need their routes setup, and the firewalls need to route the packets accordingly.

[keyctl]

I also fear this has to be done during Vagrant provisioning, because aslans* otherwise cannot talk to other hosts in the internal network (assuming that aslans* will be placed in the DMZ). So I'll wait for you pushing your Vagrant changes.

[Miro-H]

Hm, should we really but the aslans machine in the DMZ? It is the most critical server after all.

The vagrant changes are really annoying... Hope I'm done soon

[keyctl]

Hm, should we really but the aslans machine in the DMZ? It is the most critical server after all.

It's the only way to meet the requirements of the assigment, namely that we have to be able to manage the system remotely. Another option would be using VPNs, but this introduces further complexity and I doubt we get this running correctly before the deadline without making other sacrifices.

[Miro-H]

Hm, should we really but the aslans machine in the DMZ? It is the most critical server after all.

It's the only way to meet the requirements of the assigment, namely that we have to be able to manage the system remotely. Another option would be using VPNs, but this introduces further complexity and I doubt we get this running correctly before the deadline without making other sacrifices.

I see. We should mention this in the report in the risk acceptance part

[Liblor]

@Liblor Are there any ports that have to be exposed from asldb machines other than 3306?

An update on this, asldb needs the following ports:

• Standard MariaDB Port: 3306
• Galera Replication Port: 4567
• IST Port: 4568
• SST Port: 4444

[keyctl]

@Liblor May I assume that's all for TCP?

[Liblor]

@Liblor May I assume that's all for TCP?

The documentation says that port 4567 is used with UDP and TCP. For the others it doesn't say anything, but I think so.

[keyctl]

@Miro-H @Liblor I was thinking of using host-based firewalls after all.

• They are easier to implement.
• They do not consume further resources.
• We have network separation, which means only the load balancer and the Ansible master are exposed anyways. Functionally, this is equivalent to just blocking all traffic to non-exposed servers, but in a lightweight manner.

[keyctl]

@RequestForCoffee Do we need any special ports for the load balancer?

[RequestForCoffee]

The load balancer(s) simply bind to ports 443&80 and forward packets to the webserver(s) via 443&80 at the TCP level.

[Miro-H]

@Miro-H @Liblor I was thinking of using host-based firewalls after all.

• They are easier to implement.
• They do not consume further resources.
• We have network separation, which means only the load balancer and the Ansible master are exposed anyways. Functionally, this is equivalent to just blocking all traffic to non-exposed servers, but in a lightweight manner.

Sounds reasonable to me. If we have a medium or high risk somewhere, we can still mention that security can be improved by buying a dedicated network firewall.

[Liblor]

@Miro-H @Liblor I was thinking of using host-based firewalls after all.

* They are easier to implement.

* They do not consume further resources.

* We have network separation, which means only the load balancer and the Ansible master are exposed anyways. Functionally, this is equivalent to just blocking all traffic to non-exposed servers, but in a lightweight manner.

yes, I also think this approach makes sense (especially in our setting).

[keyctl]

I'm already working on this, but I may need help testing as I don't know if our listed ports here are complete. Also, the patch will depend on #57 and #68.