search

aau-network-security / haaukins

A Highly Accessible and Automated Virtualization Platform for Security Education
https://general.haaukins.com
Apache License 2.0
184 stars 39 forks source link

Disable all NICs by default. Specify which to enable. #332

Closed kidmose closed 4 years ago

kidmose commented 4 years ago

Is your feature request related to a problem? Please describe. In the context of #304 ; It seems to me that the problem was either of the two (or both): 1) Some challenges were based on a VM image that included a nic that wasn't supposed to be there, leading to an unintended communication path from the lab and onto the Internet. I would expect the solution to be an update to the image used for that challenge. 2) When haaukins creates a lab and the VMs inside it, I expect the VMs to be isolated to inside that lab's network. Haaukins did not provide the expected isolation.

The solution of always disabling nic2 (bbe3a071) seems to land somewhere between those two problems, not quite addressing them fully.

I foresee that someone might create a new challenge, where the VM image comes with nic3 enabled. If a human mistake can be made once, the same human mistake can be made again. A malicious challenge could even include nic3 as a bridged IF... The current fix to haaukins does not seem to address this.

Describe the solution you'd like I suggest that the default behaviour is isolation, with the exercise specification describing explicitly what networking is to be configured. The platform must of course enforce this. As an example, the way it is handled in docker-compse is described here: https://docs.docker.com/compose/networking/#specify-custom-networks

It is important that the platform by default disables all NICs and then opens up according to challenge specification.

Describe alternatives you've considered 1) Disable nic2 in the VM image. This should be done and complements my suggested solution. 2) Hard-code routine for disabling nic2-4. This is bad because it is unflexible as it does not support multiple networks, and it is fails if virtualbox starts supporting 5 NICs... 3) Log an error and fail if there are any other NICs in an image than nic1. Do the same if it is not configured as expected (E.g. device type, network name). This an OK solution, that is better than the hard coded fix of only disabling nic2, but inferior to the "Isolate by default, specify what to open"

Additional context N/A

mrtrkmn commented 4 years ago

I foresee that someone might create a new challenge, where the VM image comes with nic3 enabled. If a human mistake can be made once, the same human mistake can be made again. A malicious challenge could even include nic3 as a bridged IF...

Actually, for this kind of situations we have review and test process for the challenges, so I think, it is NOT a concern at the moment.

It is important that the platform by default disables all NICs and then opens up according to challenge specification.

I will look around.

mrtrkmn commented 4 years ago

I think, you mentioned about wrong pull request, it is NOT related with disabling NICs.

In the context of #320 ;

kidmose commented 4 years ago

I think, you mentioned about wrong pull request, it is NOT related with disabling NICs.

In the context of #320 ;

aboslutely right. should be #304 . Edited the issue.

kidmose commented 4 years ago

Actually, for this kind of situations we have review and test process for the challenges, so I think, it is NOT a concern at the moment.

And the review and test process will always catch if e.g. a NIC is added by mistake?

To me, haaukins is one component, that provides a promise of isolation, and the challenges are another component. If haaukins relies on the challenges to be tested to only have one NIC, it is directly against Postel's law. If you insist this is a good idea, I'll leave that up to you :)

mrtrkmn commented 4 years ago

341 merged into 1.6.9