리눅스 앱용 커널 수준 Tor 격리 도구 Oniux 소개

 (blog.torproject.org)
4P by GN⁺ | ★ favorite | 댓글 2개
  • 임의의 Linux 프로그램을 별도 네트워크 환경에 가두고 모든 트래픽을 Tor로 보내도록 해, 앱별 프록시 설정에 의존하던 누출 위험을 줄이는 도구임
  • 핵심은 Linux 커널의 네트워크 네임스페이스로, 앱에는 시스템 인터페이스 대신 onion0만 보이게 만들어 우회 연결을 어렵게 함
  • 기존 torsocks는 libc 함수 덮어쓰기 방식이라 정적 바이너리나 Zig 생태계처럼 libc를 거치지 않는 호출에서 데이터가 샐 수 있음
  • oniux는 Arti와 onionmasq 기반의 Linux 전용 Rust 도구이고, torsocks는 CTor 기반 C 구현으로 크로스플랫폼이며 15년 넘게 쓰여 온 방식임
  • 사용자는 기존 명령 앞에 oniux를 붙여 curl, bash, hexchat 등을 실행할 수 있지만, 새롭고 실험적인 도구라는 점을 감안해야 함

oniux가 해결하려는 Tor 격리 문제

  • 프라이버시가 중요한 앱이나 서비스를 실행할 때는 모든 패킷이 실제로 Tor 경유로만 나가야 함
  • 프록시 설정을 잘못 입력하거나 SOCKS 래퍼 밖에서 시스템 호출이 발생하면 데이터가 노출될 수 있음
  • oniux는 Linux 네임스페이스를 이용해 서드파티 애플리케이션에 Tor 네트워크 격리를 제공하는 명령줄 유틸리티임
  • Arti와 onionmasq 위에서 동작하며, Linux 프로그램을 자체 네트워크 네임스페이스에 넣어 Tor로 라우팅함
  • 문서 상단에는 oniux가 별도 웹사이트를 갖게 되었고, 이 글의 버전 번호는 크게 오래되었다는 경고가 있음

Linux 네임스페이스가 맡는 역할

  • 네임스페이스는 Linux 커널의 격리 기능으로, 2000년 무렵 도입됨
  • 애플리케이션의 특정 부분을 시스템 나머지 영역과 안전하게 분리할 수 있음
  • 네임스페이스는 격리 대상에 따라 여러 형태로 나뉨
    • 네트워크 네임스페이스
    • 마운트 네임스페이스
    • 프로세스 네임스페이스
    • 그 외 여러 형태
  • Linux의 시스템 리소스는 일반적으로 모든 애플리케이션이 전역적으로 접근할 수 있음
    • 운영체제 시계
    • 전체 프로세스 목록
    • 파일 시스템
    • 사용자 목록
  • 네임스페이스는 애플리케이션 일부를 운영체제 나머지 부분에서 컨테이너화하며, Docker도 격리 프리미티브를 제공할 때 이 기능을 사용함

Tor와 네임스페이스를 결합하는 방식

  • oniux는 각 애플리케이션을 시스템 전체 네트워크 인터페이스에 접근할 수 없는 네트워크 네임스페이스 안에서 실행함
  • 해당 네임스페이스에는 eth0 같은 시스템 인터페이스 대신 사용자 지정 네트워크 인터페이스 onion0만 제공됨
  • 이 방식은 운영체제 커널이 제공하는 보안 프리미티브에 의존해 임의 애플리케이션의 Tor 접근을 격리함
  • SOCKS 방식과 달리, 개발자 실수로 일부 연결이 설정된 SOCKS를 거치지 않아 데이터가 새는 상황을 줄일 수 있음

oniux와 torsocks의 차이

  • torsocks는 Tor가 제공하는 SOCKS 프록시로 트래픽을 보내기 위해 네트워크 관련 libc 함수를 덮어쓰는 도구임
  • 이 방식은 oniux보다 크로스플랫폼성이 높지만, 동적 링크된 libc를 통하지 않는 시스템 호출에서는 데이터가 샐 수 있음
  • 특히 순수 정적 바이너리와 Zig 생태계 애플리케이션은 torsocks 지원 범위에서 제외됨

  • oniux

    • 독립 실행 애플리케이션임
    • Linux 네임스페이스를 사용함
    • 모든 애플리케이션에서 동작함
    • 악성 애플리케이션도 데이터 누출이 불가능한 구조임
    • Linux 전용임
    • 새롭고 실험적인 도구임
    • Arti를 엔진으로 사용함
    • Rust로 작성됨

  • torsocks

    • 실행 중인 Tor 데몬이 필요함
    • ld.so preload 해킹을 사용함
    • libc를 통해 시스템 호출을 하는 애플리케이션에서만 동작함
    • 악성 애플리케이션은 raw assembly로 시스템 호출을 만들어 데이터가 샐 수 있음
    • 크로스플랫폼임
    • 15년 넘게 검증됨
    • CTor를 엔진으로 사용함
    • C로 작성됨

설치와 사용 예시

  • Linux 시스템과 Rust 툴체인이 필요함
  • 설치는 cargo install로 진행함
cargo install --git https://gitlab.torproject.org/tpo/core/oniux --tag v0.4.0 oniux
  • 단순 HTTPS 요청을 Tor 경유로 실행할 수 있음
oniux curl https://icanhazip.com
  • IPv6 요청도 지원함
oniux curl -6 https://ipv6.icanhazip.com
  • onion service 접근도 가능함
oniux curl http://2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion/…
  • 로깅은 RUST_LOG=debug로 활성화할 수 있음
RUST_LOG=debug oniux curl https://icanhazip.com
  • 셸 전체를 Tor 경유로 실행하면 그 안의 모든 프로세스를 격리할 수 있음
oniux bash
  • 데스크톱 환경에서는 그래픽 애플리케이션도 격리 가능함
oniux hexchat

내부 동작 흐름

  • oniux는 먼저 clone(2) 시스템 호출로 자식 프로세스를 생성함
  • 자식 프로세스는 자체 네트워크, 마운트, PID, 사용자 네임스페이스 안에서 격리됨
  • 이후 자식 프로세스는 /proc의 자체 복사본을 마운트하고, 부모 프로세스의 UID와 GID에 맞춰 UID/GID 매핑을 설정함
  • 애플리케이션이 Tor를 통해 이름을 해석하도록 nameserver 항목이 들어 있는 임시 파일을 만들고, 이를 /etc/resolv.conf에 bind mount함
  • 자식 프로세스는 onionmasq를 사용해 onion0이라는 TUN 인터페이스를 생성함
  • 이어서 rtnetlink(7) 작업으로 인터페이스를 설정하며, IP 주소 할당 같은 작업이 포함됨
  • 자식 프로세스는 TUN 인터페이스의 파일 디스크립터를 Unix Domain socket을 통해 부모 프로세스에 전달함
  • 부모 프로세스는 최초 clone(2) 실행 이후 이 메시지를 기다림
  • 전달이 끝나면 자식 프로세스는 사용자 네임스페이스의 root 프로세스가 되면서 얻은 모든 capability를 내려놓음
  • 마지막으로 사용자가 제공한 명령을 Rust 표준 라이브러리 기능으로 실행함

실험적 상태와 사용상 주의

  • oniux는 비교적 새로운 기능이며 Arti와 onionmasq 같은 새로운 Tor 소프트웨어를 사용함
  • 현재는 기대한 대로 동작하지만, torsocks는 15년 넘게 사용되어 더 많은 실전 경험을 갖고 있음
  • 목표는 oniux도 torsocks와 비슷한 성숙도에 도달하는 것임

함께 보면 좋은 글 β

ndrgrd   [-]

Tor는 프라이버시에는 나쁘지 않은 것 같은데 익명성에 알맞은 도구인지는 잘 모르겠네요. 출구 노드들을 이미 국가기관들이 장악하고 있다는 이야기도 있고.

답변달기
GN⁺   [-]
Hacker News 의견들

  • 10년쯤 전 네트워크 네임스페이스가 막 뜨던 시기에 Tor 개발자와 이 주제로 얘기한 적이 있음
    당시 받은 피드백은, 사람들이 안전하다고 착각하면서도 식별 가능한 정보를 많이 새어나가게 만들 쉬운 방법이라는 것이어서 더 밀어붙이지 않았음

    • Tor 쪽이 그 방향을 밀어붙인 건 전략적 실수였다고 봄
      심각한 위협에 놓인 사람은 Tor Browser를 쓰고 다른 유출 경로도 계속 조심해야 하는 건 맞지만, Tor가 어디에나 쓰이는 상태가 됐다면 대량 감시는 훨씬 어려워졌을 것임
      지금은 대량 감시가 누가 Tor를 쓰는지 탐지할 수 있는데, 모두가 쓰고 있었다면 그 사실이 별 의미 없었을 것임
    • 이상함. torsocks와 torify도 같은 일을 하지만 더 덜 견고하게 할 뿐임

  • 이게 전부 TCP에만 해당되는 것 아닌가? 다시 말해 TCP가 아닌 활동은 어떤 방식으로 보호할 수 있는지 궁금함

    • 자세한 건 모르지만 https://gitlab.torproject.org/tpo/core/onionmasq에는 이렇게 나와 있음
      이 프로젝트는 TCP 및 UDP 상태를 처리할 수 있는 단순한 사용자 공간 네트워크 스택을 구현해, 트래픽을 Tor 네트워크로 전달할 수 있게 하려는 시도임
    • Tor Browser 사용자는 YouTube나 DNS를 어떻게 처리하나? HTTP/3는 어떻게 되는지도 궁금함
    • TCP가 아닌 활동은 라우팅되지 않고 전송에 실패할 것임

  • 첫 페이지의 설치 안내가 동작하지 않음. 버전 번호를 0.4.0에서 0.5.0으로 바꿔야 함
    cargo install --git https://gitlab.torproject.org/tpo/core/oniux oniux@0.5.0

  • Oniux는 orjail과 비슷한 “공식” 지원 도구처럼 보임. orjail은 4년 동안 커밋이 없지만, iptables/iproute 도구를 쓰는 셸 스크립트로 여전히 아주 잘 동작함 [1]
    orjail에는 추가 격리를 위해 firejail과 함께 실행하는 옵션도 있는데, Oniux에는 아직 없는 기능으로 보임
    [1] https://github.com/orjail/orjail/blob/master/usr/sbin/orjail

  • 처음엔 이게 torsocks처럼 로컬에서 실행 중인 tor 데몬을 통해 트래픽을 보내는 방식이라고 생각했음
    그런데 로컬 tor 데몬을 중지해도 oniux는 계속 동작하고, torify와 torsocks는 동작하지 않는 걸 봄. 문서에 실제로 그렇게 쓰여 있었음. 꽤 괜찮음
    Docker 안에서도 동작하지만 --privileged가 필요했음. 바이너리를 debian:12 컨테이너에 복사하니 거기서도 동작함:
    docker run -it --rm --privileged -v "$PWD/oniux:/usr/bin/oniux" debian:12

  • 재미있는 사실로, 이건 curl에서 5년째 깨져 있었고 블로그 예제들도 마찬가지임. Tor 개발자들이 예전에는 앱이 .onion 도메인 이름 해석을 시도하면 안 된다고 고집했기 때문임: https://daniel.haxx.se/blog/2025/05/16/leeks-and-leaks/
    해결책을 찾을 수 있으면 좋겠음

  • 이제 Chrome으로 Tor 웹사이트에 접속할 수 있다는 뜻인가?

    • 가능은 하지만 제발 그러지 않는 게 좋음. 오히려 더 튀게 됨. Tor Browser에는 Chrome에는 없는 여러 지문 방지 전략이 있음
    • 예전에도 프록시 환경 변수나 설정만 지정하면 가능했음. tor 데몬의 표준 포트는 9050임
      사실 임의의 프로토콜을 통해 트래픽을 라우팅하게 해주는 SOCKS 프록시는 비교적 쉽게 만들 수 있음. 예를 들어 SOCKS5 프록시를 변환 계층으로 써서 syncthing 위에서 웹사이트를 제공하거나 방문할 수 있음: https://github.com/acheong08/syndicate

  • 예제로 hexchat을 쓰는데, 이런 프로세스는 사용자 설정으로 실행되는 건가? 설정을 바꾸는 걸 잊으면 IRC 사용자명이 새어나가지 않나
    브라우저를 실행하면 쿠키도 새어나갈 수 있고?

    • 관심사의 분리임. Tor가 지문 식별을 막기 위해 많은 노력을 하지만, 개인적으로 Tor와 Oniux의 주목적은 출발지 IP를 추적 불가능하게 만드는 것이라고 봄
      Gmail에 Tor로 로그인하는 경우에도 같은 말을 할 수 있었을 것임. HTTPS가 아니었다면 말임
    • 사용자명이 새어나간다는 게 무슨 뜻인지 모르겠음. 사용자명이 Tor를 쓴다는 사실은 드러날 수 있음
      같은 IRC 호스트에 접속하는 모든 사용자명이 같은 사람이라는 사실도 여전히 드러날 것임
      익명성을 유지하려 한다면 IRC는 꽤 위험해 보임. 많은 사람이 접속 해제 시간을 기록하고 있어서, 다른 네트워크 장애 이벤트와 상관관계를 맞출 수 있기 때문임

  • 여기 개발자 경험은 아주 잘 만들어졌고, 바보도 쓸 수 있을 정도임. 만든 사람들 잘했음 <3

    • 전혀 그렇지 않음. 바보들은 기발함. 익명성을 보존하는 방식으로 이걸 쓰는 데 필요한 운영상 주의는 대부분의 사용자에게 너무 어려움

  • 좋음. 이제 프로토타입을 C로 다시 작성해주면 기꺼이 쓰겠음

    • 이건 Rust로 작성됐음. C 버전이 왜 필요한가?
답변달기