Intelligent Cybersecurity Framework for Smart Grid — When Protecting the Grid Means Trusting the Wire

#SmartGrid #Cybersecurity #W5500 #TOE #IndustrialControl #ESP32 #SCADA #IntrusionDetection #Ethernet #GraduationProject

📚 Context: University graduation project (Computer Engineering, 2025–2026) — a working, physically-built three-tier smart-grid defense system. ✅ Implementation status: Hardware built and demonstrated (real-device photos + project report included). W5500 usage verified at the code level across all networked nodes.

01 — What is this project?

Smart grids are attractive targets. The moment control units, relays, and SCADA endpoints get network addresses, they inherit the entire threat surface of an IP network — DoS floods, scanning, ARP spoofing, false-data injection. Most student and hobby "grid security" demos stop at detecting an attack and printing an alert. They rarely close the loop down to the physical layer, and they almost never think about the security of their own control channel.

This project does both. It is a three-tier, layered defense system that watches live grid traffic, decides when an attack is happening, and then reaches all the way down to physically isolate the affected grid unit — cutting the cooling fan, raising alarms, and showing an on-device warning.

The three tiers are cleanly separated:

• Detection Layer (Raspberry Pi): sits on a switch configured with port mirroring, so every packet flowing through the grid network is copied to it. A real-time detection engine inspects that traffic and classifies attacks.
• Control Layer (Arduino master): the central decision authority. It receives attack alerts from the Pi and issues mode commands (Normal / Standby / Attack) to the grid units.
• Execution Layer (ESP32 + W5500 grid units ×2): each unit receives commands and drives real hardware — a relay-controlled cooling fan, an LED, a buzzer, and a 16×2 I²C LCD that displays "Attack Detected."

The result is not a slideshow — it's a closed control loop that converts a detected cyber attack into a physical protective action in real time.

02 — Why a wired Ethernet control plane?

Here is the design decision that makes this project genuinely interesting, and it is one that most builders get wrong.

The execution units are ESP32 boards. Every ESP32 has Wi-Fi built in. The path of least resistance would have been to run the entire command-and-control network over Wi-Fi and ship zero extra hardware. This project deliberately did not do that. Every command hop — Pi → Arduino, Arduino → ESP32 — runs over wired W5500 Ethernet on a fixed 192.168.1.0/24 network.

🔷 The control plane must not be the weakest link

This is a cybersecurity system. It would be self-defeating to route the very commands that isolate a compromised grid over a wireless link that can be jammed, deauthenticated, or spoofed. By putting the control plane on physical Ethernet, the project removes the wireless attack surface from the exact channel it cannot afford to lose. The thing doing the protecting is itself hardened.

🔷 Deterministic, fixed-topology addressing

Grid infrastructure is not a laptop wandering between access points. It's a fixed set of nodes at known locations. Static IPs (Arduino .200, grid units .10 / .20, Pi as client), hardware link-status monitoring, and automatic reconnect give this system the deterministic, "always at the same address" behavior that industrial control demands.

🔷 One transport, two very different MCUs

The master is an Arduino; the grid units are ESP32s. Both speak to the network through the same W5500 + Arduino Ethernet API. One networking model, identical code idioms, works across heterogeneous silicon — which is exactly why a hardwired TCP/IP controller beats stitching together each MCU's native, incompatible network stack.

03 — System architecture

Data flow on attack: Grid traffic → mirrored to Pi → IDS engine flags a flood/scan/DDoS → Pi opens a TCP socket to Arduino :5006 and sends a single command byte → Arduino ACKs, then opens a TCP socket to the targeted ESP32 unit(s) at :5005 → ESP32 cuts the relay (fan OFF), fires LED + buzzer, and prints "Attack Detected" to the LCD.

04 — Why W5500? ⭐

🔷 The technical core

Both the Arduino master and the ESP32 grid units use the W5500 as their sole network interface. In the firmware this is unambiguous:

• #include <SPI.h> + #include <Ethernet.h>, with explicit W5500_CS and W5500_RST pin definitions
• A proper hardware reset sequence (RST LOW → HIGH) before Ethernet.init(W5500_CS)
• Static configuration via Ethernet.begin(mac, ip, dns, gateway, subnet)
• Live health monitoring with Ethernet.linkStatus() and an automatic reconnect routine

🔷 Socket mode: TCP / TOE (Sn_MR_TCP, 0x01)

Every networked node in this system runs the W5500 in hardwired TCP (TOE) socket mode. This is verifiable directly from the API usage, not inferred:

• The ESP32 units instantiate EthernetServer server(5005) and accept connections with server.available() → listen/accept = TOE TCP server.
• The Arduino instantiates EthernetServer piServer(5006) for the Pi and acts as an EthernetClient to reach the ESP32 units (client.connect(target, 5005)) → TOE TCP client + server on the same chip.

The W5500's hardwired TCP/IP engine handles the full handshake, retransmission, and connection state in silicon. The MCUs never run a software TCP stack — which matters, because those MCUs are simultaneously timing relay switching, driving a buzzer, and refreshing an LCD. Offloading the entire transport layer to the W5500 keeps the control loop responsive and predictable.

🔷 Why not the alternatives?

• ESP32 native Wi-Fi: rejected on purpose — a wireless control plane is an unacceptable attack surface for a security system (see §02).
• A software stack (LwIP) on the MCU: would steal CPU cycles from the real-time control tasks and add non-deterministic latency to the command path. The W5500's fixed-latency hardware offload is a better fit for a control loop.
• ENC28J60: requires a software TCP/IP stack on the host anyway, reintroducing exactly the CPU-load and complexity problem the W5500 avoids.

For a system whose entire value proposition is reliable, hardened, deterministic command delivery, a hardwired TOE controller isn't a convenience — it's the architecturally correct choice.

🔷 Verified evidence ✅

• ✅ W5500 initialization, CS/RST pin control, and reset sequence present in firmware for both node types
• ✅ TOE TCP server + client usage confirmed in code (EthernetServer, EthernetClient, server.available(), client.connect())
• ✅ Consistent static addressing and link-status/reconnect logic across all nodes
• ✅ Physically built and demonstrated — real-device photographs and a full project report are part of the repository

05 — Key components

🌐 WIZnet W5500 — Hardwired TCP (TOE) mode

The transport backbone for the entire system. Three independent W5500 interfaces (one on the Arduino master, one on each ESP32 grid unit) form a private, wired control network. Each runs the W5500's hardwired TCP/IP engine in server and/or client roles, giving the whole system a deterministic, offloaded, Wi-Fi-free command channel.

🧠 Raspberry Pi — Detection engine

Receives port-mirrored traffic and runs a real-time, threshold-based intrusion-detection engine that tracks per-source and per-protocol packet rates (ICMP / SYN / UDP floods, DDoS from a single source) and watches SCADA-relevant ports such as Modbus/502. On a positive detection it becomes a TCP client to the Arduino and issues the attack command.

🎛️ Arduino Master — Control authority

The central state machine (Normal / Standby / Attack, per-grid or grid-wide). Runs a W5500 TCP server for the Pi and a W5500 TCP client toward the grid units, translating high-level detection events into targeted physical commands with acknowledgements.

⚡ ESP32 Execution Units (×2) — Physical enforcement

Each unit terminates a W5500 TCP server and drives the protective hardware: a 2-channel relay (cooling-fan cutoff, active-LOW), an LED and buzzer for local alerting, and an I²C 16×2 LCD that surfaces the current mode and the "Attack Detected" warning.

🔌 Supporting hardware

Managed switch with port mirroring, 5 V 2-channel relay modules, cooling fans (dynamo), and the grid-unit indicators — all orchestrated over the W5500 control plane.

06 — Application scenarios

01. SCADA / substation protective isolation. The exact pattern demonstrated here — detect anomalous traffic on grid control ports, then physically de-energize or isolate the affected feeder — maps directly onto real substation and SCADA hardening, where a compromised control node must be cut off deterministically.

02. Industrial control-plane segmentation. Any plant that wants its safety/shutdown commands on a network that cannot be attacked wirelessly can adopt this "wired W5500 control plane, separate from the data network" topology. It's a reusable blueprint for keeping the command channel out of band.

03. Intrusion-triggered physical response (IDS → actuation). The Pi-to-Arduino-to-actuator chain generalizes to any scenario where a network IDS must drive a physical outcome — HVAC cutoff, door isolation, power shedding — with the W5500 guaranteeing the last-hop command actually lands.

04. Teaching platform for cyber-physical security. Because it is fully built and every tier is observable (serial logs, LCD, relays you can hear click), it's an excellent hands-on lab for demonstrating how detection, decision, and actuation fit together — and why the transport under a security system deserves as much scrutiny as the detection logic.

Conclusion

This project's most instructive idea isn't the attack detector — it's the insistence that the channel doing the protecting must itself be un-attackable. That's why an ESP32 system deliberately runs its command plane on hardwired W5500 Ethernet instead of Wi-Fi.

• ✅ A complete, physically-built three-tier cyber-physical defense (detect → decide → physically isolate)
• ✅ Closes the loop from packet analysis all the way to a relay cutting a fan and an LCD reading "Attack Detected"
• ✅ Uses three W5500 interfaces across heterogeneous MCUs (Arduino + 2× ESP32) as a single, unified control transport
• ✅ Runs the W5500 in hardwired TCP (TOE) mode — offloading the full transport stack so the MCUs stay free for real-time control
• ✅ Makes a genuine security argument for wired Ethernet over Wi-Fi on the control plane — the standout design decision
• ✅ Deterministic static-IP topology with link monitoring and auto-reconnect, fit for fixed industrial layouts
• ✅ Fully observable and demonstrable — a strong reference for cyber-physical / smart-grid security education

07 — Similar Projects on WIZnet Makers

Network security is a surprisingly deep vein on the WIZnet Makers platform, and this project sits in good company. Lining it up against its neighbors shows exactly what makes it distinct. (All entries below were checked against their live project pages.)

• Intrusion detection system using W5100 + Arduino — [WIZnet] The closest conceptual ancestor: an Arduino-based IDS built on a WIZnet chip (W5100). It detects — but stops at detection. No decision hierarchy, no physical response. → https://maker.wiznet.io/WIZnet/projects/intrusion-detection-system-using-w5100-arduino/

• SCADA Cyber Range — [WIZnet] An academic, high-fidelity SCADA cybersecurity training environment (Modbus, ARP, Nmap-based exercises on a W5100 test bed). Same smart-grid security domain — but built to teach attacks, not to defend a live grid. → https://maker.wiznet.io/WIZnet/projects/scada-cyber-range/

• FPGA Firewall Project — [Lihan__] Hardware packet filtering on a DE1-SoC FPGA with W5500 in MACRAW mode — a 4-rule engine parsing IPv4/TCP/UDP with inline two-W5500 forwarding. Same "network security" goal, opposite W5500 mode: raw L2 frame filtering in silicon vs. this project's TOE TCP control bus. → https://maker.wiznet.io/Lihan__/projects/fpga-firewall-project/

• ARPoLAN: Network Monitoring and Security Tool — [Benjamin] An Atmega32u4 + W5500 offensive tool that performs network scanning and ARP spoofing (plus USB-HID "Rubber Ducky" tricks). A red-team mirror image: this project defends against exactly the ARP spoofing that ARPoLAN launches — both on the same W5500. → https://maker.wiznet.io/Benjamin/projects/arpolan-network-monitoring-and-security-tool/

• SCADA Modbus TCP Relay Timer — [Sunny_] An Arduino Modbus TCP slave that drives a timed relay for SCADA, with EEPROM runtime storage and an Ethernet watchdog. It shares this project's physical relay actuation over Ethernet — but as a neutral control utility, with no detection or security layer on top. → https://maker.wiznet.io/Sunny_/projects/scada-modbus-tcp-relay-timer/

Comparison

Insight

The platform reveals a full spectrum of WIZnet-chip network security: someone attacks with it (ARPoLAN), someone filters in silicon with it (FPGA Firewall), someone detects with it (W5100 IDS), someone teaches with it (SCADA Cyber Range), and someone actuates a relay with it (SCADA Relay Timer). This project is the only one that closes the entire loop — from detecting the attack, through a central control decision, to physically isolating the compromised grid unit. Even the neighbor that also drives a relay does so as a neutral timer, with no detection above it. And it's the clearest example of treating W5500 not as a mere link but as a deliberately-hardened control plane: where the firewall pushes W5500 into MACRAW for raw filtering, this project leans on W5500's TOE TCP as a trustworthy command bus and consciously rejects the ESP32's own Wi-Fi to keep that bus un-attackable. Detection + decision + physical enforcement, on a control channel that is itself secured — that is the gap it fills.

Q&A

Q. What WIZnet chip and mode does this use? The W5500 in hardwired TCP (TOE) socket mode (Sn_MR_TCP). There are three W5500 interfaces — one on the Arduino master and one on each of the two ESP32 grid units — each acting as a TCP server and/or client on a private wired network.

Q. It's built on ESP32 — why bother adding a W5500 instead of using ESP32 Wi-Fi? Because the whole point is security. A wireless control plane can be jammed, deauthenticated, or spoofed, which would defeat a system whose job is to isolate compromised grid units. Routing all command traffic over wired W5500 Ethernet removes that attack surface from the one channel the system cannot afford to lose.

Q. Why offload TCP to the W5500 rather than run a software stack on the MCU? The MCUs are busy: timing relay switching, driving a buzzer, and refreshing an LCD. The W5500's hardwired TCP/IP engine handles handshake, retransmission, and connection state in silicon, so the control loop stays deterministic and responsive. A software stack (LwIP) would add CPU load and non-deterministic latency to the exact path that must be reliable.

Q. Is the "AI detection" a trained ML model? The detection layer is a real-time, threshold-based intrusion-detection engine (per-protocol and per-source packet-rate thresholds, SCADA-port monitoring). It's the decision brain of the system; the W5500 is what guarantees its decisions reliably reach the actuators.

스마트 그리드 지능형 사이버보안 프레임워크 — 그리드를 지키려면, 지키는 통로부터 믿을 수 있어야 한다

#SmartGrid #Cybersecurity #W5500 #TOE #IndustrialControl #ESP32 #SCADA #IntrusionDetection #Ethernet #GraduationProject

📚 컨텍스트: 대학 졸업작품 (Computer Engineering, 2025–2026) — 실제로 제작·시연된 3계층 스마트 그리드 방어 시스템. ✅ 구현 검증 상태: 하드웨어 실물 제작 및 시연 완료 (실물 사진 + 프로젝트 보고서 포함). 네트워크에 연결된 모든 노드에서 W5500 사용을 코드 레벨로 확인함.

01 — 이 프로젝트는 무엇인가?

스마트 그리드는 매력적인 공격 표적이다. 제어 유닛·릴레이·SCADA 엔드포인트가 네트워크 주소를 갖는 순간, IP 네트워크의 모든 위협 표면 — DoS 플러딩, 스캐닝, ARP 스푸핑, 허위 데이터 주입 — 을 그대로 물려받는다. 대부분의 학생/취미 수준 "그리드 보안" 데모는 공격을 탐지하고 경고를 출력하는 데서 멈춘다. 물리 계층까지 루프를 닫는 경우는 드물고, 자기 자신의 제어 채널 보안까지 고민하는 경우는 거의 없다.

이 프로젝트는 그 둘을 모두 한다. 실시간 그리드 트래픽을 감시하고, 공격 여부를 판단하고, 그런 다음 물리 계층까지 내려가 해당 그리드 유닛을 실제로 격리한다 — 냉각 팬을 차단하고, 경보를 울리고, 장치 화면에 경고를 띄운다.

3계층은 명확히 분리되어 있다:

• 탐지 계층 (Raspberry Pi): 포트 미러링으로 설정된 스위치에 물려 있어 그리드 네트워크를 흐르는 모든 패킷의 복사본을 받는다. 실시간 탐지 엔진이 이 트래픽을 검사해 공격을 분류한다.
• 제어 계층 (Arduino 마스터): 중앙 의사결정 권한. Pi로부터 공격 알림을 받아 그리드 유닛에 모드 명령(Normal / Standby / Attack)을 내린다.
• 실행 계층 (ESP32 + W5500 그리드 유닛 ×2): 각 유닛이 명령을 받아 실제 하드웨어를 구동한다 — 릴레이로 제어되는 냉각 팬, LED, 부저, 그리고 "Attack Detected" 를 표시하는 16×2 I²C LCD.

결과물은 슬라이드쇼가 아니라, 탐지된 사이버 공격을 실시간으로 물리적 보호 동작으로 변환하는 닫힌 제어 루프다.

02 — 왜 유선 이더넷 제어 평면인가?

이 프로젝트를 진짜 흥미롭게 만드는 설계 결정이 여기 있는데, 대부분의 제작자가 놓치는 지점이다.

실행 유닛은 ESP32 보드다. 모든 ESP32에는 Wi-Fi가 내장돼 있다. 가장 저항이 적은 길은 명령·제어 네트워크 전체를 Wi-Fi로 돌리고 추가 하드웨어를 하나도 붙이지 않는 것이다. 이 프로젝트는 의도적으로 그렇게 하지 않았다. Pi → Arduino, Arduino → ESP32 — 모든 명령 홉이 고정 192.168.1.0/24 네트워크의 유선 W5500 이더넷 위에서 돈다.

🔷 제어 평면이 가장 약한 고리가 되어선 안 된다

이건 사이버보안 시스템이다. 침해된 그리드를 격리하는 바로 그 명령을, 재밍·디어스·스푸핑당할 수 있는 무선 링크로 흘려보내는 건 자기모순이다. 제어 평면을 물리 이더넷에 올림으로써, 이 프로젝트는 절대 잃어선 안 되는 바로 그 채널에서 무선 공격 표면을 제거한다. 보호하는 주체 자신이 먼저 견고해진다.

🔷 결정적이고 고정된 토폴로지 주소 체계

그리드 인프라는 AP 사이를 떠도는 노트북이 아니다. 알려진 위치에 고정된 노드 집합이다. 고정 IP(Arduino .200, 그리드 유닛 .10 / .20, Pi는 클라이언트), 하드웨어 링크 상태 감시, 자동 재연결이 산업 제어가 요구하는 "항상 같은 주소에 있다"는 결정적 동작을 보장한다.

🔷 하나의 전송 계층, 전혀 다른 두 종류의 MCU

마스터는 Arduino, 그리드 유닛은 ESP32다. 둘 다 동일한 W5500 + Arduino Ethernet API로 네트워크와 대화한다. 하나의 네트워킹 모델, 동일한 코드 관용구가 이종 실리콘에서 그대로 동작한다 — 하드와이어드 TCP/IP 컨트롤러가, 각 MCU의 서로 호환되지 않는 네이티브 네트워크 스택을 억지로 엮는 것보다 나은 정확한 이유다.

03 — 시스템 아키텍처

공격 발생 시 데이터 흐름: 그리드 트래픽 → Pi로 미러링 → IDS 엔진이 플러드/스캔/DDoS 탐지 → Pi가 Arduino :5006 으로 TCP 소켓을 열어 명령 바이트 1개 전송 → Arduino가 ACK 후, 표적 ESP32 유닛의 :5005 로 TCP 소켓을 열어 명령 전달 → ESP32가 릴레이 차단(팬 OFF), LED + 부저 작동, LCD에 "Attack Detected" 출력.

04 — 왜 W5500인가? ⭐

🔷 기술적 핵심

Arduino 마스터와 ESP32 그리드 유닛 모두 W5500을 유일한 네트워크 인터페이스로 사용한다. 펌웨어에서 이건 명백하다:

• #include <SPI.h> + #include <Ethernet.h>, 그리고 명시적인 W5500_CS / W5500_RST 핀 정의
• Ethernet.init(W5500_CS) 이전의 정식 하드웨어 리셋 시퀀스 (RST LOW → HIGH)
• Ethernet.begin(mac, ip, dns, gateway, subnet) 를 통한 정적 설정
• Ethernet.linkStatus() 기반 실시간 상태 감시 + 자동 재연결 루틴

🔷 소켓 모드: TCP / TOE (Sn_MR_TCP, 0x01)

이 시스템의 모든 네트워크 노드는 W5500을 하드와이어드 TCP(TOE) 소켓 모드로 돌린다. 추론이 아니라 API 사용 자체에서 직접 확인된다:

• ESP32 유닛은 EthernetServer server(5005) 를 만들고 server.available() 로 연결을 수락한다 → listen/accept = TOE TCP 서버.
• Arduino는 Pi를 위한 EthernetServer piServer(5006) 를 운영하는 동시에 ESP32 유닛에 도달하기 위해 EthernetClient 로도 동작한다 (client.connect(target, 5005)) → 같은 칩에서 TOE TCP 클라이언트 + 서버.

W5500의 하드와이어드 TCP/IP 엔진이 핸드셰이크, 재전송, 연결 상태를 실리콘에서 처리한다. MCU는 소프트웨어 TCP 스택을 절대 돌리지 않는다 — 이게 중요한 이유는, 그 MCU들이 동시에 릴레이 스위칭 타이밍을 맞추고, 부저를 울리고, LCD를 갱신하고 있기 때문이다. 전송 계층 전체를 W5500으로 오프로드하면 제어 루프가 반응성 있고 예측 가능하게 유지된다.

🔷 대체 솔루션 대비

• ESP32 네이티브 Wi-Fi: 의도적으로 배제 — 무선 제어 평면은 보안 시스템에 용납할 수 없는 공격 표면이다(§02 참조).
• MCU 위의 소프트웨어 스택(LwIP): 실시간 제어 태스크에서 CPU 사이클을 빼앗고, 명령 경로에 비결정적 지연을 추가한다. W5500의 고정 지연 하드웨어 오프로드가 제어 루프에 더 적합하다.
• ENC28J60: 어차피 호스트에 소프트웨어 TCP/IP 스택이 필요해서, W5500이 피하려는 CPU 부하·복잡도 문제를 그대로 다시 불러온다.

신뢰성 있고, 견고하고, 결정적인 명령 전달이 존재 이유의 전부인 시스템에서, 하드와이어드 TOE 컨트롤러는 편의가 아니라 아키텍처적으로 올바른 선택이다.

🔷 검증된 증거 ✅

• ✅ 두 노드 유형 모두 펌웨어에 W5500 초기화, CS/RST 핀 제어, 리셋 시퀀스 존재
• ✅ 코드에서 TOE TCP 서버 + 클라이언트 사용 확인 (EthernetServer, EthernetClient, server.available(), client.connect())
• ✅ 모든 노드에 걸친 일관된 정적 주소 체계 및 링크 상태/재연결 로직
• ✅ 실물 제작·시연 완료 — 실제 장치 사진과 프로젝트 보고서가 저장소에 포함

05 — 핵심 구성요소

🌐 WIZnet W5500 — 하드와이어드 TCP(TOE) 모드

전체 시스템의 전송 백본. 3개의 독립 W5500 인터페이스(Arduino 마스터 1개 + 각 ESP32 그리드 유닛 1개씩)가 사설 유선 제어 네트워크를 구성한다. 각각 W5500의 하드와이어드 TCP/IP 엔진을 서버/클라이언트 역할로 돌려, 시스템 전체에 결정적이고 오프로드된 Wi-Fi 없는 명령 채널을 제공한다.

🧠 Raspberry Pi — 탐지 엔진

포트 미러링된 트래픽을 받아, 소스별·프로토콜별 패킷 레이트(ICMP / SYN / UDP 플러드, 단일 소스 DDoS)를 추적하고 Modbus/502 같은 SCADA 관련 포트를 감시하는 실시간 임계값 기반 침입탐지 엔진을 돌린다. 탐지 성공 시 Arduino에 TCP 클라이언트로 접속해 공격 명령을 전송한다.

🎛️ Arduino 마스터 — 제어 권한

중앙 상태 머신(Normal / Standby / Attack, 그리드별 또는 전체). Pi를 위한 W5500 TCP 서버와 그리드 유닛을 향한 W5500 TCP 클라이언트를 운영하며, 상위 탐지 이벤트를 ACK가 포함된 표적 물리 명령으로 변환한다.

⚡ ESP32 실행 유닛 (×2) — 물리적 집행

각 유닛이 W5500 TCP 서버를 종단하며 보호 하드웨어를 구동한다: 2채널 릴레이(냉각 팬 차단, active-LOW), 지역 경보용 LED와 부저, 그리고 현재 모드와 "Attack Detected" 경고를 표시하는 I²C 16×2 LCD.

🔌 보조 하드웨어

포트 미러링 지원 관리형 스위치, 5V 2채널 릴레이 모듈, 냉각 팬(다이나모), 그리고 그리드 유닛 표시장치들 — 모두 W5500 제어 평면 위에서 오케스트레이션된다.

06 — 응용 시나리오

01. SCADA / 변전소 보호 격리. 여기서 시연된 바로 그 패턴 — 그리드 제어 포트의 이상 트래픽을 탐지한 뒤 해당 피더를 물리적으로 차단·격리 — 은 실제 변전소·SCADA 견고화에 그대로 대응된다. 침해된 제어 노드는 결정적으로 끊어내야 하기 때문이다.

02. 산업 제어 평면 분리. 안전/셧다운 명령을 무선으로 공격당할 수 없는 네트워크에 두고 싶은 어떤 플랜트든, 이 "데이터 네트워크와 분리된 유선 W5500 제어 평면" 토폴로지를 채택할 수 있다. 명령 채널을 대역 외로 유지하는 재사용 가능한 청사진이다.

03. 침입 트리거 물리적 대응 (IDS → 액추에이션). Pi→Arduino→액추에이터 체인은 네트워크 IDS가 물리적 결과를 구동해야 하는 모든 시나리오 — HVAC 차단, 문 격리, 전력 차단 — 로 일반화되며, W5500이 마지막 홉 명령이 실제로 도달함을 보장한다.

04. 사이버-피지컬 보안 교육 플랫폼. 완전히 제작됐고 모든 계층이 관찰 가능하므로(시리얼 로그, LCD, 딸깍 소리가 들리는 릴레이), 탐지·판단·액추에이션이 어떻게 맞물리는지, 그리고 왜 보안 시스템 아래의 전송 계층이 탐지 로직만큼의 검증을 받아야 하는지를 보여주는 훌륭한 실습 랩이다.

Conclusion

이 프로젝트의 가장 교훈적인 아이디어는 공격 탐지기가 아니라, 보호하는 채널 자신이 공격 불가능해야 한다는 고집이다. ESP32 시스템이 명령 평면을 Wi-Fi가 아닌 하드와이어드 W5500 이더넷으로 의도적으로 돌리는 이유가 바로 이것이다.

• ✅ 완전히 실물 제작된 3계층 사이버-피지컬 방어(탐지 → 판단 → 물리적 격리)
• ✅ 패킷 분석부터 팬을 끊는 릴레이와 "Attack Detected" LCD까지 루프를 닫음
• ✅ 이종 MCU(Arduino + ESP32 2개)에 걸쳐 3개의 W5500 인터페이스를 단일 통합 제어 전송으로 사용
• ✅ W5500을 하드와이어드 TCP(TOE) 모드로 운영 — 전송 스택 전체를 오프로드해 MCU를 실시간 제어에 집중시킴
• ✅ 제어 평면에서 Wi-Fi 대신 유선 이더넷을 쓰는 진짜 보안 논거를 제시 — 가장 돋보이는 설계 결정
• ✅ 링크 감시·자동 재연결을 갖춘 결정적 정적 IP 토폴로지 — 고정 산업 배치에 적합
• ✅ 완전히 관찰·시연 가능 — 사이버-피지컬 / 스마트 그리드 보안 교육의 강력한 레퍼런스

07 — WIZnet Makers 내 유사 프로젝트

네트워크 보안은 WIZnet Makers 플랫폼에서 의외로 두터운 갈래이고, 이 프로젝트는 좋은 이웃들 사이에 있다. 이웃들과 나란히 놓고 보면 이 프로젝트가 무엇으로 구별되는지가 정확히 드러난다. (아래 항목은 모두 실제 프로젝트 페이지에서 내용을 확인함.)

• Intrusion detection system using W5100 + Arduino — [WIZnet] 가장 가까운 개념적 조상: WIZnet 칩(W5100) 위에 올린 Arduino 기반 IDS. 탐지는 하지만 탐지에서 멈춘다 — 의사결정 계층도, 물리적 대응도 없다. → https://maker.wiznet.io/WIZnet/projects/intrusion-detection-system-using-w5100-arduino/

• SCADA Cyber Range — [WIZnet] 학술적이고 고충실도인 SCADA 사이버보안 훈련 환경(W5100 테스트베드 위의 Modbus·ARP·Nmap 기반 실습). 동일한 스마트 그리드 보안 도메인이지만, 살아있는 그리드를 방어하기 위해서가 아니라 공격을 가르치기 위해 만들어졌다. → https://maker.wiznet.io/WIZnet/projects/scada-cyber-range/

• FPGA Firewall Project — [Lihan__] DE1-SoC FPGA 위에서 W5500을 MACRAW 모드로 돌리는 하드웨어 패킷 필터링 — IPv4/TCP/UDP를 파싱하는 4-rule 엔진 + 두 개의 W5500을 통한 인라인 포워딩. 같은 "네트워크 보안" 목표, 정반대 W5500 모드: 실리콘에서의 생 L2 프레임 필터링 vs 이 프로젝트의 TOE TCP 제어 버스. → https://maker.wiznet.io/Lihan__/projects/fpga-firewall-project/

• ARPoLAN: Network Monitoring and Security Tool — [Benjamin] Atmega32u4 + W5500 기반 공격 도구로, 네트워크 스캐닝과 ARP 스푸핑(+ USB-HID "Rubber Ducky")을 수행한다. 레드팀 거울상: 이 프로젝트는 ARPoLAN이 실행하는 바로 그 ARP 스푸핑을 방어하며, 둘 다 같은 W5500 위에 있다. → https://maker.wiznet.io/Benjamin/projects/arpolan-network-monitoring-and-security-tool/

• SCADA Modbus TCP Relay Timer — [Sunny_] SCADA용 타이머 릴레이를 구동하는 Arduino Modbus TCP 슬레이브. EEPROM 런타임 저장과 Ethernet 워치독을 갖췄다. 이 프로젝트와 이더넷 기반 물리 릴레이 구동을 공유하지만, 그 위에 탐지·보안 계층이 없는 중립적 제어 유틸리티다. → https://maker.wiznet.io/Sunny_/projects/scada-modbus-tcp-relay-timer/

비교

인사이트

플랫폼은 WIZnet 칩 네트워크 보안의 전 스펙트럼을 보여준다: 누군가는 그걸로 공격하고(ARPoLAN), 누군가는 실리콘에서 필터링하고(FPGA Firewall), 누군가는 탐지하고(W5100 IDS), 누군가는 가르치고(SCADA Cyber Range), 누군가는 릴레이를 구동한다(SCADA Relay Timer). 이 프로젝트는 전체 루프를 닫는 유일한 사례다 — 공격 탐지부터, 중앙 제어 판단, 침해된 그리드 유닛의 물리적 격리까지. 릴레이를 구동하는 이웃조차 그 위에 탐지가 없는 중립적 타이머일 뿐이다. 또한 W5500을 단순 링크가 아니라 의도적으로 견고화된 제어 평면으로 다루는 가장 명확한 예이기도 하다: 방화벽이 W5500을 MACRAW로 밀어 생 필터링에 쓰는 반면, 이 프로젝트는 W5500의 TOE TCP를 신뢰할 수 있는 명령 버스로 기대며, 그 버스를 공격 불가능하게 유지하기 위해 ESP32 자체의 Wi-Fi를 의식적으로 거부한다. 탐지 + 판단 + 물리적 집행을, 그 자체가 보안된 제어 채널 위에서 — 그것이 이 프로젝트가 채우는 빈자리다.

Q&A

Q. 어떤 WIZnet 칩과 모드를 쓰나? W5500을 하드와이어드 TCP(TOE) 소켓 모드(Sn_MR_TCP) 로 사용한다. W5500 인터페이스가 3개 — Arduino 마스터에 1개, 두 ESP32 그리드 유닛에 각 1개 — 이며, 각각 사설 유선 네트워크에서 TCP 서버 및/또는 클라이언트로 동작한다.

Q. ESP32 기반인데, 왜 ESP32 Wi-Fi 대신 굳이 W5500을 붙였나? 핵심이 보안이기 때문이다. 무선 제어 평면은 재밍·디어스·스푸핑당할 수 있고, 이는 침해된 그리드 유닛 격리가 임무인 시스템을 무력화한다. 모든 명령 트래픽을 유선 W5500 이더넷으로 돌리면, 시스템이 절대 잃어선 안 되는 그 채널에서 공격 표면을 제거한다.

Q. 왜 MCU에 소프트웨어 스택을 돌리지 않고 TCP를 W5500으로 오프로드하나? MCU가 바쁘기 때문이다: 릴레이 스위칭 타이밍, 부저 구동, LCD 갱신. W5500의 하드와이어드 TCP/IP 엔진이 핸드셰이크·재전송·연결 상태를 실리콘에서 처리하므로 제어 루프가 결정적이고 반응성 있게 유지된다. 소프트웨어 스택(LwIP)은 신뢰성이 필수인 바로 그 경로에 CPU 부하와 비결정적 지연을 더한다.

Q. "AI 탐지"는 학습된 ML 모델인가? 탐지 계층은 실시간 임계값 기반 침입탐지 엔진이다(프로토콜별·소스별 패킷 레이트 임계값, SCADA 포트 감시). 이것이 시스템의 판단 두뇌이고, W5500은 그 판단이 액추에이터에 신뢰성 있게 도달하도록 보장하는 부분이다.