VPS를 위한 Tor 기반 관리 경로
SSH에 SOCKS 프록시를 사용하고, 비공개 onion 엔드포인트를 게시하며, 공개 접근을 닫기 전에 DNS, 인증 및 복구를 확인하십시오.
한눈에 보기
Tor는 VPS에 도달하는 데 사용되는 네트워크 경로를 변경할 수 있으며, SSH onion 엔드포인트는 일반적인 공개 관리 목적지를 피할 수 있습니다. 어느 접근 방식도 서버를 자동으로 보호하지 않습니다. SSH 키를 보호하고, 호스트 신원을 확인하고, 접근을 제한하고, 의존하기 전에 구성을 테스트하세요.
체크아웃뿐 아니라 관리도 보호하십시오
보호된 브라우저를 통해 서버를 주문한다고 해서 이후의 SSH 세션이 자동으로 보호되지는 않습니다. 직접 로그인하면 서버와 경로상의 네트워크에 소스 주소가 드러날 수 있습니다. 선호하는 경로가 실패할 경우의 비상 접근을 포함하여 첫 연결 전에 관리가 어떻게 작동할지 결정하십시오.
Tor는 목적지로부터 클라이언트의 직접 IP를 숨길 수 있지만, 재사용된 자격 증명, 식별 구성 데이터 또는 모든 트래픽 상관 공격에 대한 해결책은 아닙니다. 또한 지연 시간을 추가합니다. 유용한 목표는 동작을 이해하고 확인할 수 있는 일관된 관리 경로입니다.
작동하는 로컬 Tor 클라이언트로 시작하십시오
시스템 Tor 데몬은 일반적으로 127.0.0.1:9050에서 SOCKS를 제공하는 반면, Tor Browser는 일반적으로 9150를 사용합니다. 어느 포트든 가정하지 말고 실제 구성을 확인하십시오. 애플리케이션은 해당 프록시를 통해 연결을 보내야 합니다. Tor Browser를 여는 것만으로 컴퓨터의 모든 프로그램이 라우팅되지는 않습니다.
지원되는 시스템에서 torsocks는 SSH과 같은 애플리케이션을 감싸고 지원되는 네트워크 호출을 Tor을 통해 라우팅합니다. 문서 전용 예제 주소를 서버의 실제 주소로 바꾸어 설정을 테스트하십시오. 다음 명령은 실행 중인 시스템 Tor 데몬과 전용 관리 계정을 가정합니다.
torsocks ssh -i ~/.ssh/silentvps_ed25519 [email protected]경로를 SSH 구성의 일부로 만드십시오
정기적인 사용을 위해 호스트별 구성은 래퍼를 잊을 가능성을 줄입니다. 아래 예제는 SOCKS5 프록시 지원이 있는 netcat 구현을 사용합니다. 구현이 다르므로 설치된 버전에서 -x 및 -X 옵션을 확인하고 호스트 이름 해석이 원격인지 검증하십시오.
IdentitiesOnly는 서버에 제공되는 키를 제한합니다. 이 프로젝트를 위해 사용되는 새 키와 함께 사용하십시오. 신뢰할 수 있는 프로비저닝 채널을 통해 서버의 호스트 키 지문을 확인하고 보관하십시오. Tor는 네트워크 경로를 변경하지만, SSH 호스트 인증은 여전히 필수적입니다.
Host silent-admin
HostName 203.0.113.45
User admin
IdentityFile ~/.ssh/silentvps_ed25519
IdentitiesOnly yes
ProxyCommand nc -X 5 -x 127.0.0.1:9050 %h %pSSH를 onion 서비스 뒤로 이동하십시오
onion 엔드포인트는 공개적으로 접근 가능한 SSH 포트 없이 관리를 허용하고 이 연결에 Tor 출구를 사용하는 것을 피합니다. 서버에 Tor를 설치하고 구성한 다음, onion 가상 포트를 로컬 SSH 서비스에 매핑하십시오. 예제는 시작 구성이며, 서비스 경로와 명령은 배포판에 따라 다릅니다.
Tor가 서비스 디렉터리를 생성한 후, 해당 호스트 이름 파일을 비공개로 검색하고 클라이언트 프록시를 통해 연결을 테스트하십시오. onion 서비스의 신원 키를 비공개로 유지하십시오. 성공적인 독립 로그인 후에만 SSH를 localhost로 제한하고 공개 접근을 제거해야 합니다. 해당 변경을 하기 전에 복구 콘솔이 작동하는지 확인하십시오.
HiddenServiceDir /var/lib/tor/silent-admin/
HiddenServicePort 22 127.0.0.1:22비공개 엔드포인트를 위한 클라이언트 인증 추가
추가 승인 없이, onion 주소를 알게 된 사람은 누구나 서비스와 그 SSH 프롬프트에 접근할 수 있습니다. Tor v3 클라이언트 승인은 별도의 암호학적 관문을 추가합니다: 서비스는 승인된 클라이언트의 공개 키를 가지고 있고 클라이언트는 일치하는 개인 키를 보유합니다.
키 형식과 authorized_clients 디렉터리에 관한 Tor 프로젝트의 현재 지침을 따르세요. 승인되지 않은 클라이언트가 연결할 수 없는지 확인하세요. SSH 키 인증도 유지하고, 자신의 남은 접근 권한을 잃지 않으면서 분실한 기기의 승인을 취소하는 방법을 계획하세요.
DNS 테스트 및 신원 누출 방지
로컬 리졸버가 수행하는 호스트명 조회는 연결이 프록시에 도달하기 전에 대상이 무엇인지 드러낼 수 있습니다. 클리어넷 대상에는 서버 IP를 사용하면 그 특정 조회를 피할 수 있습니다; onion 이름은 Tor 내에서 해석되어야 합니다. 다른 호스트명의 경우, 일반적인 프록시 설정에 의존하지 말고 애플리케이션의 원격-DNS 동작을 확인하세요.
게스트 시스템은 여전히 인증 타임스탬프, 사용자 이름 및 저널 항목을 보관할 수 있습니다. 모든 진단을 무작정 비활성화하기보다는 그 보존을 의도적으로 검토하세요. 또한 식별 가능한 세부 정보가 있는지 로컬 호스트명, 커밋 메타데이터 및 복사된 구성도 점검하세요. Tor는 애플리케이션 트래픽에서 그러한 것들을 제거하지 않습니다.
- 전용 키와 격리된 프로젝트 작업 흐름을 사용하세요.
- 예상되는 SOCKS 포트와 원격 DNS 동작을 확인하세요.
- 리스너를 변경하기 전에 복구 접근 권한과 테스트된 두 번째 로그인을 유지하세요.
- 업데이트 후 Tor 및 SSH 서비스를 검토하세요.
- onion 신원 키나 클라이언트 승인 비밀을 절대 공유하지 마세요.
장시간 세션과 향후 유지 관리를 실용적으로 유지
장시간 관리 작업은 tmux나 screen 안에서 실행하여 연결 중단이 세션을 파괴하지 않도록 하세요. Tor 회로와 네트워크 상황은 변할 수 있으므로 명령을 반복 가능하게 유지하고 재개하는 방법을 이해하세요. 유지 관리가 계획되어 있으면 약간의 추가 지연은 견디기 더 쉽습니다.
동일한 onion 패턴이 로컬 대시보드나 사설 Git 서비스를 앞에 둘 수 있습니다. 각 애플리케이션은 여전히 인증, 소프트웨어 업데이트 및 신중한 구성이 필요합니다. 개인정보 보호 요구 사항이 요구하는 곳에서는 지원, 갱신 및 백업을 위해 계속 보호된 경로를 사용하세요; 일관성은 초기 설정만큼 중요합니다.