![]() For teams (like ours) that installed an additional VPN on the jump box, networking was actually more stable than most on-site events. Designed to be a jump-box for access to the network, this device simulated teams connecting their computers to the traditional physical network. In order to allow competitors to connect to the network, the OOO established a wireguard based VPN with a node on the network for each of the teams. ![]() Through the use of the API, this interaction was fully transparent to the teams. Likewise, each team had a dedicated instance they had to defend for each of their opponents. However, in this architecture each team had a dedicated machine to attack for each of their opponents. I remember two years ago the node challenge ended up being a race to see who could exploit it first, because a persistent exploit could remove all other teams’ ability to attack it. In previous years, this was a real concern. From the outset, it seems like team 2 is just out of luck – until the problem is restored they cannot exploit it. Consider the following situation: team 1 finds an exploit that crashes the service. For instance, two different teams might connect to 10.13.37.1 to attack one of A*0*E's problems.
0 Comments
Leave a Reply. |