# AirSnitch: Wi-Fi 네트워크에서 클라이언트 격리를 해소하고 해제하는 방법 [pdf] > Clean Markdown view of GeekNews topic #27058. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27058](https://news.hada.io/topic?id=27058) - GeekNews Markdown: [https://news.hada.io/topic/27058.md](https://news.hada.io/topic/27058.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-28T01:34:55+09:00 - Updated: 2026-02-28T01:34:55+09:00 - Original source: [ndss-symposium.org](https://www.ndss-symposium.org/wp-content/uploads/2026-f1282-paper.pdf) - Points: 1 - Comments: 1 ## Topic Body _No topic body._ ## Comments ### Comment 52058 - Author: neo - Created: 2026-02-28T01:34:55+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47167763) - 내가 보기엔 이런 공격들은 공격자가 이미 피해자의 네트워크에 연결되어 있어야 가능한 것 같음 대부분은 공항이나 카페 같은 **공유 Wi-Fi** 환경에서 오래전부터 알려진 공격과 유사해 보임 새로움은 일부 라우터가 게스트 네트워크와 일반 네트워크 간의 트래픽을 제대로 분리하지 못한 **구현 취약점**을 악용한다는 점임 - 공격자는 피해자의 네트워크에 연결할 필요가 없고, 같은 **하드웨어**에 연결되어 있으면 됨 Eduroam 사례처럼, 공격자는 Eduroam 자격 증명이 없어도 같은 AP에서 게스트 네트워크를 통해 Eduroam 사용자의 패킷을 가로챌 수 있음 단일 인증된 네트워크만 있다면 이런 격리 손실은 의미 없으며, 이는 브라우저 샌드박스 탈출이 신뢰된 사이트 하나만 방문할 때 무의미한 것과 같음 - 논문 공동 저자로서 “Wi-Fi 암호화를 깨뜨린다”는 표현은 오해의 소지가 있다고 생각함 실제로는 **클라이언트 격리 우회를 가능**하게 하는 것임 대학의 오픈 Wi-Fi에서 다른 네트워크(Enterprise SSID 포함)의 트래픽을 가로챈 사례도 있었음 암호화를 ‘깨는’ 것이 아니라 ‘우회’하는 것임 단일 SSID를 사용하는 개인용 라우터라면 안전함 - XFinity처럼 사용자가 낸 요금으로 만든 Wi-Fi를 도시 전체에 공유하는 경우는 어떻게 되는지 궁금함 - 나도 비슷하게 봄. 클라이언트 격리에 의존하는 환경엔 문제지만 일반 사용자에겐 영향이 적음 대부분의 인증 쿠키는 **TLS**로 보호되므로 실제 위험은 제한적임 - AP는 2.4GHz와 5GHz를 동시에 브로드캐스트할 때 여러 **BSSID**를 가지며, MAC 중복 검사나 WPA2-PSK의 GTK 공유가 약하면 공격이 쉬워짐 오래된 하드웨어, 특히 802.11w 이전 장비는 영원히 취약할 것 같음 - AirSnitch는 Wi-Fi의 **Layer 1~2 핵심 기능**을 악용해 클라이언트 간 동기화 실패를 이용함 공격자는 같은 SSID뿐 아니라 다른 SSID나 네트워크 세그먼트에서도 **양방향 MitM**이 가능함 나는 2000년대 초 WEP 시절부터 이런 걸 경험했기에 지금은 Wi-Fi를 아예 쓰지 않음 카메라엔 테이프, 안테나는 분리, 이메일도 끊음 결국 **구리선이나 광케이블**만이 진정한 보안 수단이라 생각함 - 1974년 영화 *The Conversation*을 좋아할 것 같다고 함 - 나도 비슷한 접근을 함. Wi-Fi는 별도 서브넷으로 분리하고, **GrapheneOS**를 사용하는 등 가능한 모든 하드웨어 마이크를 제거했음 - 클라이언트 격리는 실제로는 꽤 **불편한 기능**임 제조사들은 모든 장치가 하나의 큰 네트워크에서 서로 통신할 거라 가정하지만, 격리되면 Elgato 조명이나 Chromecast 같은 장치가 작동하지 않음 - 그래도 호텔에서 다른 사람이 내 Chromecast를 조작하는 것보단 낫다고 생각함 그래서 나는 항상 **OpenWRT 기반 여행용 라우터**를 들고 다니며, 어떤 네트워크에서도 내 장비들이 집처럼 동작하게 함 - 클라이언트 격리를 쓰지 않아도 유선과 무선 간 브로드캐스트가 다리(bridge)되지 않아 장치 탐색이 안 되는 경우가 있었음 - 클라이언트 격리의 본래 목적이 바로 이런 **IoT 오용 방지**임 기숙사나 공용망에서는 불편하지만, 다른 사람이 내 장치를 제어하거나 악성코드를 퍼뜨리는 걸 막아줌 - 특정 프로토콜이나 IP 범위 예외를 두면 편하겠지만, 그만큼 **데이터 누출 위험**도 커짐 - 기사 제목이 다소 **과장된 느낌**임 Wi-Fi 암호화를 깨는 게 아니라, 같은 네트워크 내에서 **기기 격리만 무력화**하는 수준임 - 하지만 많은 기업·대학·정부 기관이 네트워크 분리를 위해 클라이언트 격리에 의존하므로, 그들에게는 심각한 문제임 - 논문 공동 저자로서 “break”보다는 “bypass”라는 표현이 정확하다고 강조함 - 논문을 읽어보니 대부분의 가정용 Wi-Fi는 SSID를 2.4GHz와 5GHz에서 공유하므로 **취약**할 수 있음 Radius 인증도 일부 영향을 받을 수 있음 완화책은 단일 MAC의 AP만 사용하는 것임 EAP-TLS를 쓰면 안전하지만, 여전히 **VLAN 분리**가 필요함 - 집에 게스트 네트워크가 없다면 안전하다는 의견도 있음 - 공격자는 최소한 하나의 네트워크에 인증해야 하므로 완전한 외부자는 불가능함 - EAP-TLS는 강력하지만, 동일 AP 내 다른 인증된 장치로부터의 **수평 공격**은 막지 못함 내가 일하는 [Supernetworks.org](https://supernetworks.org/)에서는 **기기별 VLAN과 비밀번호**를 제안함 - 이건 정말 큰 문제임 하나의 AP에서 서로 다른 Wi-Fi 네트워크가 있을 때, 한쪽 네트워크의 클라이언트가 다른 네트워크의 트래픽을 **MITM**할 수 있음 대부분의 기업 Wi-Fi가 이런 격리에 의존하고 있음 - 즉, 게스트 네트워크에 접속한 내가 기업 네트워크의 트래픽을 읽을 수 있다는 뜻임 - 실제로 많은 AP가 SSID만 여러 개일 뿐, **L2/L3 격리 보장**이 명시된 사양이 없다는 점이 문제임 - 기사에서 언급된 논문은 [AirSnitch: Demystifying and Breaking Client Isolation in Wi-Fi Networks](https://www.ndss-symposium.org/ndss-paper/airsnitch-demystifying-and-breaking-client-isolation-in-wi-fi-networks/) 임 - 논문 저자 중 한 명이 [Hacker News 스레드](https://news.ycombinator.com/threads?id=vanhoefm)에서 직접 토론 중임 - 논문을 끝까지 읽어보니 핵심은 “**강력한 비밀번호로 보호된 단일 네트워크**라면 AirSnitch는 큰 위협이 되지 않는다”는 점임 - 하지만 보안 네트워크와 게스트 네트워크가 같은 AP를 공유하면, 게스트 쪽에서 보안 네트워크의 클라이언트에 접근할 수 있음 Xfinity의 자동 게스트 네트워크처럼 비활성화하기 어려운 경우도 있음 - 이 공격은 기본적으로 하나의 SSID에서만 작동함 **Private-PSK/Dynamic-PSK**나 EAP/Radius VLAN 속성을 쓰면 완화 가능함 WPA3/SAE에서는 더 복잡하며, 대부분의 장비가 아직 이를 지원하지 않음 - Hostapd는 이제 **WPA3 다중 비밀번호**를 지원함 [spr-networks/super](https://github.com/spr-networks/super) 프로젝트에서 **기기별 PSK+VLAN**을 구현해 사용 중임 다만 Apple 기기의 **Keychain 동기화**와 MAC 랜덤화 때문에 실제 배포가 어렵고, SAE의 구조상 여러 비밀번호를 동시에 시도하기 힘듦 - macOS용 **방화벽 추천**을 찾고 있음 내장 방화벽은 거의 쓸 수 없고, 클라이언트 격리가 우회된다면 로컬 방화벽이 더 중요해짐 개발용 서버를 0.0.0.0에 바인딩해두는데, 공용 Wi-Fi에 연결할 때 포트가 닫혀 있는지 확실히 하고 싶음 - macOS 방화벽 구조를 깊이 이해한 개발자들이 만든 **Little Snitch**가 가장 유명함 [공식 사이트](https://obdev.at/products/littlesnitch/index.html) - 무료 대안으로 [LuLu](https://objective-see.org/products/lulu.html)도 있음 - 나도 Little Snitch를 사용 중임