Seeking opinions on your network airgap/killswitch creation.
Seeking opinions on your network airgap/killswitch creation.
Hey there! I'm gathering thoughts from fellow tech enthusiasts to polish this concept. The core idea is a remote, physical airgap/kill switch at the OSI layer 1—essentially cutting the connection like snapping a cable. We've evaluated it from two security angles: a preventive strategy (keeping key network segments offline until needed) and a reactive one (disconnecting automatically when certain triggers occur, like an IDS alert). Since it operates at the lowest layer, it doesn't rely on Ethernet; it handles everything from serial to USB and even various signaling methods. The control interface is a web-based UI that lets you manage ports manually and experiment with features like scheduled port changes or group triggers. We've also included non-IP triggers such as SMS, with strong safeguards—number restrictions, MFA, etc.—to limit risks. For future versions, we're planning fiber upgrades and aiming for CAT6A compliance, targeting 10GbE soon. The Fluke DX2-5000 will be tested on CAT6A, and we're eyeing dual power supplies plus a battery backup. Performance-wise, it's about 13W under load and around 11W idle. I've captured a screenshot of one unit in action for reference. A note: the port status LED is RGB-based, but it doesn't display well on camera. We chose this to accommodate color vision differences and component availability. Feedback is welcome—some ideas we haven’t considered yet! People are using it to isolate backup servers, manage building access after hours, or even simulate network failures for testing redundancy.
It's fascinating. I do something comparable at home for my son's space, since his room uses a dedicated (compact) switch linked to a smart plug. That plug follows a schedule and stays active only when he needs it. All his wireless gadgets are managed through the router.
Earlier, before developing this product, we followed a comparable method using a high-end datacentre PDU with console controls for power management on each port. Several challenges emerged that influenced our design choices. Initially, integrating Cisco-managed switches proved slow—taking 3 to 4 minutes to come online after booting. Over time, repeated usage became frustrating. Another problem was the gradual decline in switch performance, which contradicted expectations since managed switches aren’t meant for constant switching. We initially called it a network kill switch, but many customers began describing it as an airgapping solution. Different market perspectives exist, especially in OT/CNI sectors where disconnecting any device from a network is seen as an air gap. Of course, air gapping involves more than just a disconnection.
Yeah. Again, from your perspective, just avoid using the word airgap. Your clients might call whatever they want, but to protect against possible legal issues, sticking to the original name you used is safer. You might be able to reference quotes from customers who think it’s an airgap, but make sure those aren’t included in any promotional content. As for how the device works right now, an actual air gap would mean a physical barrier that can’t be bypassed without touching something at the source. But since the setup allows easy work around—like a frustrated employee losing access and using a simple method such as a text message—it wouldn’t meet the definition of an airgap. A better analogy is just a small opening with only air, not a solid wall. A deactivated port wouldn’t fit either. I’m sure the product is excellent, but I just want you to avoid mixing up the terms here.
Emosun presents some solid ideas. The Deadman switch setup involves writing a script, hiding it, and if they’re terminated, the system checks for deactivation. That’s straightforward. If that triggers a problem, negative outcomes occur. When a script can command a device to act maliciously, it signals an airgap breach. There are some considerations here. Perhaps include a mode where the device can be activated through a single method, but only one way to trigger it. Offer a physical breaker or button for opening, requiring manual access to the unit. This could be a strong selling feature. Consider isolating the enable logic from the control circuit—physically separating them creates a logical air gap. You can’t compromise a relay. Essentially, you’re building a dynamic air gap solution that’s fully customizable. Government, Tier 3 data centers, and power plants would appreciate this.
Positive comments received. We can set up a layer that requires multiple parties or users to verify before enabling or disabling a port. For instance, an engineer must get approval from his line manager to turn a port on or off. This arrangement can be layered as needed. Your suggestion about physical security is solid. We already have the necessary hardware to support push buttons and ignition keys. I’ll need to research how to make this setup modular, since any physical modifications require an EMC re-test, which is costly and time-consuming. Perhaps a GPIO interface on the rear—like a terminal block—could work. Users could then connect their own triggers, whether from a physical button or integrated into their automation system. Regarding possible attack paths, I’ve worked in cybersecurity for a while. While many focus on rare edge cases, simpler solutions always exist. https://xkcd.com/538/ Your concept aims to boost network resilience by adding extra hurdles for would-be hackers or malware. It doesn’t substitute strong security practices, which are essential today. If you’re specifically targeted, there are more direct ways to breach systems. I’ve previously conducted red team physical penetration tests and found that even buildings with strict access controls can be compromised if someone has the right credentials. The old saying holds: a high-vis jacket, ladder, and tools can let someone in without question. Once, someone helped me gain entry by pretending to struggle with equipment while I hid my gear.