# 리틀 스니치 for Linux

> Clean Markdown view of GeekNews topic #28365. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=28365](https://news.hada.io/topic?id=28365)
- GeekNews Markdown: [https://news.hada.io/topic/28365.md](https://news.hada.io/topic/28365.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-04-10T09:36:46+09:00
- Updated: 2026-04-10T09:36:46+09:00
- Original source: [obdev.at](https://obdev.at/products/littlesnitch-linux/index.html)
- Points: 2
- Comments: 1

## Topic Body

- 애플리케이션의 **네트워크 연결을 시각화하고 제어**할 수 있는 도구로, 어떤 프로그램이 어떤 서버와 통신하는지 확인 가능
- **Connections View**에서 실시간 및 과거 트래픽을 앱별로 표시하며, 클릭 한 번으로 **연결 차단**과 **데이터 사용량 추적** 지원
- **Blocklists**와 **Rules** 기능을 통해 원치 않는 트래픽을 범주별 또는 세부 조건별로 **정교하게 제어** 가능
- 내부적으로 **eBPF**를 이용해 커널 수준에서 연결을 감시하고, 웹 UI를 통해 **PWA 형태의 인터페이스** 제공
- **보안 도구가 아닌 프라이버시 중심 도구**로, 일반 소프트웨어의 외부 통신 차단에는 적합하지만 고급 공격 방어용으로는 제한적임

---

### 개요
- **Little Snitch for Linux**는 애플리케이션의 네트워크 연결을 실시간으로 시각화하고 제어할 수 있는 도구
  - 어떤 애플리케이션이 어떤 서버와 통신하는지 확인 가능
  - 원치 않는 연결 차단, 트래픽 기록, 데이터 사용량 추적 기능 제공
- **Linux 커널 6.12 이상**과 **BTF 커널 지원** 필요
- 웹 UI는 `http://localhost:3031/`에서 접근 가능하며, **PWA(Progressive Web App)** 형태로 설치 가능

### 연결 모니터링
- **Connections View**에서 현재 및 과거 네트워크 활동을 애플리케이션별로 표시
  - 규칙과 차단 목록에 의해 차단된 항목, 데이터 사용량, 트래픽 히스토리 표시
  - 최근 활동, 데이터량, 이름 기준으로 정렬 및 필터링 가능
  - 클릭 한 번으로 연결 차단 가능
- 하단의 **트래픽 다이어그램**은 시간에 따른 데이터량을 시각화
  - 특정 구간을 드래그해 확대하면 해당 기간의 활동만 필터링되어 표시됨

### 차단 목록 관리
- **Blocklists** 기능으로 원치 않는 트래픽 범주를 일괄 차단 가능
  - 원격 소스에서 자동 다운로드 및 최신 상태 유지
  - 지원 형식: 도메인당 한 줄, 호스트명당 한 줄, `/etc/hosts` 형식(IP + 호스트명), CIDR 네트워크 범위
  - ### 와일드카드, 정규식, glob, URL 기반 형식은 지원하지 않음
    - 효율성을 위해 **도메인 기반 목록** 사용 권장
    - 예시 목록: Hagezi, Peter Lowe, Steven Black, oisd.nl
    - macOS용 `.lsrules` 형식은 Linux 버전과 **호환되지 않음**

### 사용자 정의 규칙
- **Rules** 기능은 블록리스트보다 세밀한 제어 제공
  - 특정 프로세스, 포트, 프로토콜 단위로 설정 가능
  - 규칙 목록은 정렬 및 필터링 가능
- 규칙을 통해 **세부적인 네트워크 제어 정책** 구성 가능

### 접근 보안
- 기본적으로 웹 인터페이스는 로컬에서 실행 중인 모든 프로세스가 접근 가능
  - 악성 애플리케이션이 규칙 변경, 차단 목록 수정, 필터 비활성화 가능성 존재
- 이를 방지하기 위해 **인증 요구 설정** 가능
  - 세부 설정은 고급 구성(Advanced configuration)에서 수행

### 내부 구조
- **eBPF**를 이용해 Linux 네트워크 스택에 후킹
  - eBPF 프로그램이 **출력 연결을 감시**하고 데이터를 데몬으로 전달
  - 데몬은 통계 추적, 규칙 처리, 웹 UI 제공 역할 수행
- eBPF 프로그램과 웹 UI의 **소스코드는 GitHub에서 공개**

### 고급 구성
- 기본 UI는 주요 설정만 노출하며, 고급 설정은 **텍스트 파일**로 구성
  - 변경 후 `littlesnitch` 데몬 재시작 필요
- 기본 설정 경로: `/var/lib/littlesnitch/config/`
  - 직접 수정하지 말고, 수정할 파일을 `/var/lib/littlesnitch/overrides/config/`로 복사 후 편집
  - override 디렉터리의 설정이 항상 우선 적용됨
- 주요 설정 파일
  - **`web_ui.toml`**: 네트워크 주소, 포트, TLS, 인증 설정
    - 여러 사용자가 접근 가능할 경우 인증 활성화 필요
    - 루프백 외부 노출 시 TLS 추가 필요
  - **`main.toml`**: 규칙에 일치하지 않는 연결의 기본 동작 설정
    - 기본값은 허용이며, 필요 시 거부로 변경 가능
    - 잘못 설정 시 시스템 접근 불가 위험 존재
  - **`executables.toml`**: 실행 파일 그룹화 규칙
    - 버전 번호 제거로 동일 앱의 여러 버전을 하나로 표시
    - 셸 및 앱 관리 프로세스의 부모 관계 정의
    - 커뮤니티 피드백을 통해 지속 개선
- eBPF 프로그램과 웹 UI는 **사용자 빌드 버전으로 교체 가능**
  - override 디렉터리의 버전이 우선 적용됨

### 한계점
- **보안 도구가 아닌 프라이버시 도구**로 설계
  - macOS 버전보다 단순하며, eBPF 제약으로 기능적 한계 존재
- eBPF는 **저장 공간 및 프로그램 복잡도 제한**이 있어
  - 트래픽이 많을 경우 캐시 테이블이 넘쳐 패킷과 프로세스, DNS 이름 간 매핑이 불완전해질 수 있음
  - IP 주소에서 원래 조회된 호스트명을 복원할 때 **추론(heuristics)** 사용
  - macOS 버전은 **딥 패킷 검사(DPI)** 로 더 정확한 매핑 수행
- **일반 소프트웨어의 외부 통신 감시 및 차단**에는 적합하지만
  **고급 공격자에 대한 시스템 방어용으로는 부적합**

### 라이선스
- 구성 요소 3개로 구성
  - **eBPF 커널 프로그램**과 **웹 UI**는 **GNU GPL v2**로 공개, GitHub에서 이용 가능
  - **데몬(`littlesnitch --daemon`)** 은 **비공개(proprietary)** 이지만 **무료 사용 및 재배포 가능**

## Comments



### Comment 55023

- Author: neo
- Created: 2026-04-10T09:36:46+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47697870) 
- 나는 Little Snitch나 Open Snitch를 사용하지 않지만, **허용된 프로그램을 악용한 요청**도 차단할 수 있는지 궁금했음  
  예를 들어 `suspicious.py`가 Firefox를 호출해 데이터를 업로드하면, 방화벽이 이를 막을 수 있는지 알고 싶음
  - Little Snitch for Linux는 **프로세스와 부모 프로세스의 네임스페이스**를 함께 고려해 규칙을 평가함  
    스크립트를 `#!/bin/interpreter`로 실행하면 스크립트 경로에 규칙이 적용되지만, `interpreter script` 형식으로 실행하면 다르게 동작함
  - 단순 규칙으로는 차단되지 않음  
    Open Snitch에서는 부모 트리에 **python 프로세스**가 포함되어 있는지 등을 기준으로 세밀하게 매칭할 수 있음
  - 라이브러리 로딩이나 **프로세스 간 메모리 조작**(예: OpenProcess, WriteProcessMemory, CreateRemoteThread)까지 고려하면 훨씬 복잡해짐  
    예전 Windows 방화벽인 Outpost나 Zone Alarm은 이런 행위를 탐지하는 **Leak Control** 기능을 제공했음
  - SELinux의 **MAC 정책**을 활용하면 각 프로세스가 접근할 수 있는 파일과 포트를 제한할 수 있음  
    대부분의 배포판이 이 기능을 포함하지만, 일반 사용자는 규칙 학습이나 설정을 잘 하지 않음

- Fedora 43에서 실행해봤는데 CPU 코어를 모두 점유하고, **50K 라인 로그를 남기며 실패**했음  
  `BPF_PROG_LOAD syscall returned Argument list too long` 오류가 발생함
  - 개발자가 Fedora에서 테스트하지 않았다고 밝힘  
    ARM64 VM에서는 로드되지만 프로세스를 식별하지 못함  
    eBPF 호환성 문제를 조사 중이며, 리소스가 한정되어 시간이 필요하다고 함
  - 이미 [GitHub 이슈](https://github.com/obdev/littlesnitch-linux/issues/1)가 등록되어 있음
  - 공식 다운로드 페이지에 따르면 **Btrfs 파일 시스템**에서는 작동하지 않음  
    Fedora 기본 파일 시스템이 Btrfs라 프로세스 식별이 불가능하며, 1.0.1 버전에서 수정 예정임
  - 나도 같은 문제를 겪었음. CPU 절반만 쓰지만 **웹 UI가 작동하지 않음**
  - 이런 게 바로 **평범한 리눅스 경험**임. 2026년이 리눅스 데스크톱의 해라는 말이 농담처럼 들림

- 리눅스 사용자로서 **코드의 개방성**을 중요하게 생각함  
  OpenSnitch + OpenSnitch-UI 조합으로 충분히 만족하고 있음

- 리눅스에서 **유료 툴 모델**이 얼마나 실현 가능한지 궁금했음  
  대부분은 무료, 후원 기반, 혹은 오픈코어 모델임  
  Little Snitch가 Linux 버전을 무료로 공개한 이유가 “리눅스에서는 돈이 안 된다”는 인식 때문인지, 다른 이유가 있는지 궁금함
  - 리눅스 커뮤니티는 **폐쇄형 소프트웨어에 대한 불신**이 강함  
    나도 네트워크 트래픽을 다루는 폐쇄형 프로그램은 꺼림칙함  
    대신 FOSS 프로젝트에는 매년 수천 달러를 기부함  
    하지만 이런 사용자는 소수라, 완전 오픈소스로는 수익을 내기 어려움
  - OpenSnitch가 이미 존재하고 무료이기 때문에, **유료 대체재**는 설득력이 약함  
    특히 방화벽처럼 **권한이 높은 코드**는 오픈소스가 아니면 신뢰하기 어려움
  - Little Snitch for Linux의 개발자는 “우리는 투자자가 아닌 **작은 독립 팀**이며, 이번 결정은 개인적인 선택이었다”고 밝힘  
    결과가 어떻게 될지 궁금하다고 함
  - 개발자의 동기는 [공식 블로그 글](https://www.obdev.at/blog/little-snitch-for-linux/)에 잘 설명되어 있음

- 관련 블로그 포스트: [Little Snitch for Linux 소개](https://obdev.at/blog/little-snitch-for-linux/)

- 예전에 Windows용 **ZoneAlarm**이 있었음  
  리눅스에는 왜 이런 게 없었는지 늘 궁금했음  
  - 예전에 AmigaOS용으로 ZoneAlarm과 비슷한 프로그램을 직접 만들었음  
    [Direwall 코드](https://github.com/JetSetIlly/Direwall)를 찾아보니 옛날 C 스타일이 그대로 남아 있음  
    소켓 라이브러리를 패치해 동작했는데, 지금도 컴파일될지 궁금함
  - ZoneAlarm의 강점은 기술뿐 아니라 **사용자 교육과 UX 설계**였음  
    처음엔 시끄럽게 묻지만, 학습 후 조용해지는 구조를 명확히 설명했음  
    그래서 사용자 신뢰를 얻었고, 나도 그 점 때문에 추천했음
  - 당시에는 GNU 소프트웨어가 대부분이라 **스파이웨어가 거의 없었음**  
    상용 소프트웨어가 리눅스로 들어오면서 네트워크 감시 욕구가 생겼음
  - ZoneAlarm을 2000년대 초에 썼던 기억이 남  
  - Kerio Personal Firewall도 기억남. 이후 ZA나 Comodo로 옮겼는데, **격리 실행 기능**이 인상적이었음  
    Windows의 무분별한 실행을 제한할 수 있어서 좋았음

- Little Snitch를 오래 사용해왔고, **모든 네트워크 요청을 수동 승인**함  
  하지만 커널 확장 수준의 권한을 가진 프로그램을 얼마나 신뢰할 수 있을지 고민됨  
  회사나 개발자에 대한 정보가 거의 없어 궁금함
  - Little Snitch for Linux 개발자가 직접 답변함  
    eBPF 컴포넌트는 **GPLv2 오픈소스**로 공개되어 있으며, [GitHub 코드](https://github.com/obdev/littlesnitch-linux)에서 확인 가능함  
    다만 데몬은 root 권한으로 실행되어야 하므로, **SELinux 같은 접근 제어**로 제한할 필요가 있음  
    첫 릴리스라 버그 리포트 대응 중이며, 리눅스 환경의 다양성에 놀랐다고 함
  - 이 회사는 20년 넘게 활동한 **Mac용 독립 개발사**로, Little Snitch는 오래전부터 사랑받는 제품임
  - 나는 Android용 **Little Snitch/OpenSnitch 영감의 FOSS 방화벽**을 공동 개발 중임  
    macOS에서는 커널 확장이 아니라 **Network Extension API**를 사용함  
    네트워크 관찰이 목적이라면 [Sniffnet](https://github.com/GyulyVGC/sniffnet) 같은 GUI 스니퍼도 있음

- Linux 포트 출시를 축하함  
  완전 오픈소스이자 터미널 기반의 대안으로 내가 유지 중인 [RustNet](https://github.com/domcyrus/rustnet)을 소개함  
  **TUI 기반 실시간 패킷 모니터링** 도구로, 방화벽은 아니지만 Landlock을 통해 자체 샌드박싱함
  - 흥미로워 보여서 나중에 사용해볼 예정임

- OpenSnitch와 비교가 궁금함  
  [OpenSnitch GitHub](https://github.com/evilsocket/opensnitch)
  - Little Snitch를 써봤는데 **IP→도메인 해석**이 거의 안 되고, 프로세스 식별도 실패함  
    이는 Linux 버전의 **기술적 한계** 때문임  
    eBPF 기반이라 캐시 오버플로 시 프로세스 매핑이 불가능하고, macOS처럼 **딥 패킷 검사**를 쓸 수 없음  
    [공식 설명](https://obdev.at/products/littlesnitch-linux/index.html)에 자세히 나와 있음
  - 나도 OpenSnitch를 설치했지만 지금은 꺼둔 상태임. 아마 피로감 때문이었을 듯함
  - 개발자 블로그에 따르면, 기존 도구들이 **“프로세스별 연결을 한눈에 보고 클릭 한 번으로 차단”** 하는 기능을 제공하지 않아 직접 만들었다고 함  
    [관련 글](https://obdev.at/blog/little-snitch-for-linux/)
  - OpenSnitch는 완전한 **오픈소스**이며 구독도 없음. 소프트웨어는 이렇게 되어야 함

- OpenSnitch를 만족스럽게 사용 중임  
  다만 **플러그인 시스템**이 생겨서 사용자 행동과 네트워크 연결을 함께 분석하고, **예상치 못한 연결만 알림**으로 띄워주면 좋겠음  
  팝업 대신 CLI 기반의 **자동 허용 래퍼**도 있으면 편리할 것 같음
