Differences

This shows you the differences between two versions of the page.

--- cyberconquest [2023/03/31 19:57] – gaelin
+++ cyberconquest [2024/02/06 07:11] (current) – gaelin
@@ Line 1: / Line 1: @@
-// This post is still under construction. I am adding more details and images //
+// This is my first post so I am still getting the hang of it :) //
 ====== Cyber Conquest @ DakotaCon 10.1 ======
 A purple team (offensive and defensive) cybersecurity competition that I designed, planned and lead a team to build.
 **Start:** 2023/01
 **Competition Date:** 2023/03/25
+{{ :cyberconquest2023-laptop.jpg?nolink&600 |}}
 ===== Overview =====
@@ Line 53: / Line 54: @@
 ===== Infrastructure =====
-The virtual systems were hosted in the DSU [[https://ialab.dsu.edu|IALab]]((My favorite vCloud cluster, And also the largest one in the state of South Dakota)). Each team had their own virtual network holding their router and a few virtual systems. Each of these networks had its associated vlan trunked to the competition room and split out to physical ports on a switch in the room. Each team then had a switch at their table to connect the laptops and raspberry PI, which was connected back to the main switch. All of the team tables were arranged in a circle around a center table that had the actual physical systems (traffic lights, water towers, wind turbines). On the center table I had a scoring PI that used multiple MCP23008 GPIO expanders to get enough GPIO ports to support the 2 water sensors per team for scoring((Ironically not actually necessary with the 6 teams we had competing but still)).
+The virtual systems were hosted in the DSU [[https://ialab.dsu.edu|IALab]]((My favorite vCloud cluster, And also the largest one in the state of South Dakota)). There were two main competition networks, a 'Blue' network connecting all the teams' networks and a 'Red' network with the scoring engine as well as virtualized kali boxes and some laptops. Both networks were connected together through the [[https://defsec.club/doku.php?id=ialab:networks|DefSec Router]] where traffic could be monitored by white team. Each team had their own virtual network holding their router and a few virtual systems. Each of these networks had its associated vlan trunked to the competition room and split out to physical ports on a switch in the room. Each team then had a switch at their table to connect the laptops and raspberry PI, which was connected back to the main switch. Each team had two laptops which were scored and in scope (Atlantis and Metropolis) plugged directly into their team's switch. Each team also had two laptops which were on the competition wide ream team network. All of the team tables were arranged in a circle around a center table that had the actual physical systems (traffic lights, water towers, wind turbines). On the center table I had a scoring PI that used multiple MCP23008 GPIO expanders to get enough GPIO ports to support the 2 water sensors per team for scoring((Ironically not actually necessary with the 6 teams we had competing but still)).
+===== Building and Testing =====
+== Water tower ==
+{{ :watertower-wiring-final.png?nolink&200|}}
+The most complicated system to wire was the water tower. It had a water sensor and a pump which was controlled via a relay. I wanted to make sure that teams could not just lower the speed of their pump and disable the controlling program, so I used a relay to ensure the pump speed was constant.
+----
+== Improving the wind turbine ==
+{{::windmill-safe-shutoff-3-relay.png?nolink&300 |3 relay wind turbine design}}
+My original design for the wind turbine had it being controlled by a single relay. After testing it for a bit I thought that it would be cool to make it spin forwards or backwards so I added a second relay. This design however is very bad for the motor. When the 1 relay design shuts the motor off, it just disconnects it and it spins out on its own, however when the 2 relay design shuts the motor off, it shorts the contacts causing the motor to jerk to a stop which causes unnecessary wear and tear to the motor. This effect is even worse if instead of stopping it switches speed. Then the motor has power applied in the opposite direction forcing the motor to stop even more abruptly and potentially back driving too much power to the board and damaging something. The solution to this is to add a third relay that disconnects one lead on the motor for a short time as it changes state. The problem with doing something like that for a competition setup is that when a malicious team gains access to the system they could remove the safety code to keep it from jerking and force it to constantly switch directions fast and break the motor. After trying to solve this problem for a while I realized that there was actually a very easy solution all along of just switching to use an actual motor controller hat. The motor controller was actually designed to change motor speed meaning that if you gave it a really drastic speed change like full forward to full backward it would slow it down gently((Gently is relative. It happens over fractions of a second but has a noticeable impact on the amount of jerking from sudden speed changes)) and not cause as much thrashing.
 ===== Lessons Learned and Final Thoughts =====
-I loved this project. It was very stressful and a lot of work((I logged almost 26 hours of dev time alone, not counting the actually physical testing, debugging and setup)) but it is also one of the most enjoyable projects that I have worked on. I got to work with cyber security (intentionally making systems vulnerable), blinky lights, motors, wiring, networking and of course infrastructure setup! I enjoyed figuring out how to wire up all of the physical components and learning about how things like the FT232H and MCP23008 work.
+I loved this project. It was very stressful and a lot of work but it is also one of the most enjoyable projects that I have worked on. I got to work with cyber security (intentionally making systems vulnerable), blinky lights, motors, wiring, networking and of course infrastructure setup! I enjoyed figuring out how to wire up all of the physical components and learning about how things like the FT232H and MCP23008 work.
 One of the coolest things I learned about was [[https://fritzing.org/|Fritzing]]. It is a FOSS wiring diagram creator which is such an awesome piece of software. I really wish I had known about it for [[https://www.firstinspires.org/robotics/frc|FIRST robotics]] in High School.
@@ Line 69: / Line 86: @@
 Everyone who helped with the initial soldering day where we soldered headers onto the GPIO breakout boards as well as the motor controller hats.
-The amazing on campus faculty who helped with acquiring resources((Beacom Wizard Tom)), 3d printing((Filament Pharaoh Tyler)), and network infrastructure((Cloud Master Eric)) setup.
+The amazing on campus faculty who helped with acquiring resources((Beacom Wizard Tom)), 3d printing((Filament Pharaoh Tyler)), and network infrastructure setup((Cloud Master Eric)).
+{{ :cyberconquest2023-room.jpg?nolink&600 |}}

Gaelin blog

User Tools

Site Tools

Differences

Page Tools