배경

드림핵 워게임 풀 때마다 바보같지만 이러한 과정을 반복하고 있었다.

1. 칼리에서 워게임 소스코드 다운
2. 소스코드를 호스트로 복붙
3. VSCode로 열어서 분석하고 주석 달고 Writeup 작성
4. 다시 칼리로 복붙
5. 칼리 안 워게임 폴더에 주석 단 소스코드랑 README.md(write-up) 넣고 git 커밋

매번 파일을 호스트↔게스트로 왔다갔다 옮기는 게 너무 번거로웠다. 하지만 VSCode에 Remote-SSH라는 기능을 쓰면 한방에 해결된다길래 시도해봤는데 생각보다 오래걸렸지만 성공했다!

여담으로 SSH는 정보기 공부할 때 많이 나오는 개념중에 하나였지만 실제로 사용해본적은 없었기 때문에 막연한 기능이라고 생각하고 넘어갔었다.(부끄러운일이다..)

예상 결과

• SSH config 파일에 HostName, User, IdentityFile 정도만 적으면 바로 연결될 줄 알았다.
• 드림핵 강의에서 알려준 방식(근데 이거 VirtualBox 기준이었음)을 VMware에 그대로 적용하면 될 줄 알았다.

실제 결과 (겪은 문제들)

1. 드림핵 가이드는 VirtualBox 기준이었음

드림핵에서 알려준 포트 포워딩 방식:

이름: SSH
프로토콜: TCP
호스트 포트: 22
게스트 포트: 22

근데 여기 게스트 IP 입력하는 칸이 없다. VirtualBox NAT 엔진이 알아서 게스트를 찾아서 연결해주는 구조라서 그렇다.

하지만 VMware는 달랐다. 포트 포워딩 규칙에 게스트(가상머신) IP를 직접 입력해야만 규칙이 성립하는 것이었다. 이 차이를 모르고 드림핵 가이드 그대로 따라가려다가 한참 헤맸었다..

2. VMware NAT Settings 버튼이 안 보임

VM 설정 창(Network Adapter → Advanced)에는 NAT Settings 관련 버튼 자체가 없었다. 알고 보니 Virtual Machine Settings 창이 아니라 Edit → Virtual Network Editor로 들어가야 하는 메뉴였다.

3. Virtual Network Editor에서도 Add 버튼이 안 눌림

Virtual Network Editor → VMnet8(NAT) → NAT Settings → Port Forwarding까지는 들어갔는데 이번엔 Add... 버튼이 아예 비활성화돼있었다.

원인은 관리자 권한이었다. VMware를 일반 권한으로 켜면 네트워크 설정 파일에 쓰기 권한이 없어서 편집 자체가 막히기 때문에, 우클릭 → "관리자 권한으로 실행"으로 다시 켜니까 바로 해결되었다.

4. 규칙 추가했는데 창 닫았다 열면 사라져있음

Add로 규칙(Host Port 22 → 칼리 IP:22) 넣고 OK 눌렀는데, 창 다시 열어보니까 테이블이 텅 비어있다. 이것도 결국 관리자 권한 문제였다. — 입력은 되는 것처럼 보이는데 실제 저장은 조용히 실패하고 있었던 것! 관리자 권한으로 재실행하고 다시 넣으니까 이번엔 사라지지 않았다.

5. 칼리 IP가 DHCP라서 매번 바뀔 수 있는 거였음

포트 포워딩 규칙에 넣은 게스트 IP가 칼리가 DHCP로 받은 값이었다. ip a 를 입력해보니 dynamic, valid_lft 1477sec처럼 임대 시간이 붙어있는 임시 주소였다. — 재부팅하면 바뀔 수 있는 상태였던 것

포트 포워딩 규칙은 특정 IP 하나를 딱 박아두는 방식이라 칼리 IP가 바뀌면 그 규칙 자체가 의미 없어진다.

6. Connection refused

키를 등록하려고 이 명령어 쳤는데 (Windows PowerShell)

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh ojun@127.0.0.1 -p 22 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

"내 윈도우 공개키를 칼리로 전송해서 거기 authorized_keys 파일 끝에 추가해라" 라는 명령어이다.

ssh: connect to host 127.0.0.1 port 22: Connection refused

Connection refused는 타임아웃이랑 다르게 요청은 도착했는데 응답하는 게 없다는 뜻이라서 포트 포워딩 규칙이 진짜 적용됐는지부터 다시 확인해야 했다. 확인해보니 역시나 4번이랑 똑같은 이유로 규칙이 저장 안 된 상태였다.

원인 분석

정리하면 결국 원인은 두 가지로 좁혀짐.

1. 드림핵 가이드(VirtualBox)랑 VMware의 포트 포워딩 구현 방식이 다름. VirtualBox는 게스트 IP를 알아서 추론하는데 VMware는 직접 입력해줘야 한다.
2. VMware Virtual Network Editor는 관리자 권한 없이 켜면 설정 저장이 조용히 실패함. 에러 메시지 하나도 안 뜨고 그냥 입력한 게 사라지니까 원인 찾는 데 시간 엄청 걸렸다.

추가로 칼리 IP가 DHCP라 유동적이라는 것까지 겹쳐서 포트 포워딩 규칙을 잘 넣어도 재부팅하면 다시 깨질 수 있는 상태였다.

해결

1) 칼리 IP 고정 (NetworkManager 방식)

최신 칼리는 /etc/network/interfaces 방식이 아니라 NetworkManager로 관리된다. nmcli로 고정함(클로드의 힘을 빌렸다^^)

nmcli connection show
# → "Wired connection 1" 확인

sudo nmcli connection modify "Wired connection 1" ipv4.addresses 192.168.xxx.xxx/24
sudo nmcli connection modify "Wired connection 1" ipv4.gateway 192.168.xxx.x
sudo nmcli connection modify "Wired connection 1" ipv4.dns "8.8.8.8 1.1.1.1"
sudo nmcli connection modify "Wired connection 1" ipv4.method manual
sudo systemctl restart NetworkManager

ip a로 다시 확인했을 때 dynamic 표시가 사라지고 valid_lft forever로 바뀐 것을 보고 고정되었음을 알 수 있었다.

2) VMware 관리자 권한으로 재실행하고 포트 포워딩 다시 설정

Host Port: 22
Type: TCP
Virtual Machine IP Address: 192.168.xxx.xxx
Virtual Machine Port: 22
Description: SSH to Kali

이번엔 창을 닫았다 열어도 규칙이 사라지지 않는것을 확인

3) SSH 서버 켜기

sudo systemctl enable --now ssh
sudo systemctl status ssh

active (running), Server listening on 0.0.0.0 port 22 로그 확인!

4) SSH 키 만들고 등록 (Winodes PowerShell)

ssh-keygen -t ed25519
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh ojun@127.0.0.1 -p 22 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

5) SSH config 작성

Host linuxvm
    HostName 127.0.0.1
    Port 22
    User ojun
    IdentityFile ~/.ssh/id_ed25519

6) VSCode Remote-SSH 연결

Remote - SSH 확장 설치 → Ctrl+Shift+P → Remote-SSH: Connect to Host → linuxvm 선택 → 왼쪽 아래에 SSH: linuxvm 뜨면 성공

결과 확인

VSCode 터미널에 칼리 프롬프트(ojun@kali:~$)가 떠서 신기했다. ~/Dreamhack 폴더를 Open Folder로 열어서 파일을 직접 편집하고 저장해봤는데 저장한 내용이 칼리 파일시스템에 그대로 반영되는 것까지 확인함. 이제 다운로드 → 복붙 → 편집 → 재복붙으로 이어지던 과정이 칼리 안에서 한 번에 끝나게 된 것이다.

참고 — 보안 관련 메모

SSH가 0.0.0.0(모든 인터페이스)에서 리스닝 중인 게 좀 걸려서 클로드에게 물어보니, 결론적으로는 VMware NAT(vmnet8) 네트워크가 호스트 밖에서는 아예 접근 불가능한 사설 네트워크라 실질적 위험은 없지만 그래도 방어적으로 비밀번호 인증은 꺼두라고 하였다.

# /etc/ssh/sshd_config
PasswordAuthentication no

sudo systemctl restart ssh

이러면 SSH 키 없이는 접속 자체가 불가능해져서 무차별 대입 공격 걱정을 덜 수 있다.

느낀 점

VirtualBox 기준 가이드를 VMware에 그대로 적용하려다 많이 고생했다. 두 가상화 프로그램의 NAT 구현 방식 차이(게스트 IP 자동 추론 여부)를 미리 알았으면 훨씬 빨리 끝났을 것이다. 또한 GUI 설정 창이 에러 없이 조용히 실패하는 경우(관리자 권한 문제)는 디버깅이 까다롭다는 것을 느꼈다. — 다음부턴 이런 종류의 문제를 만나면 권한 문제부터 먼저 의심해봐야겠다.

보안공부를 하는 입장에서 이제야 SSH를 직접 사용해보는 것이 부끄러운 일이지만 그래도 이번일을 통해서 SSH가 어떻게 동작하고 어떤 설정을 해야하는지 조금은 와닿는 계기가 되었다.

뭘 하려고 했나

Burp Suite Proxy 탭에서 Open browser 버튼 누르면 내장 Chromium이 켜지면서 프록시 설정이랑 인증서까지 자동으로 잡혀서 바로 트래픽 가로채기 실습을 시작할 수 있어야 정상이다. 근데 버튼 누르자마자 Burp's browser failed to start라는 팝업만 뜨고 아무것도 안 켜졌다.

1. 파일이 깨졌나 싶어서 확인해봄

Burp에 진단 로그 보는 기능이 있길래 열어봤더니, BROWSER POOL 항목에 Live: N/A, Total: 0이라고 찍혀 있었다. 브라우저가 아예 한 번도 켜진 적이 없다는 뜻.

그래서 Burp 폴더 안에 있는 chrome.exe를 직접 실행해보니 이런 에러가 떴다.

클로드에 물어보니, dll 파일 하나가 깨진 것 같았다고한다. 백신 로그도 확인해봤는데 딱히 이 파일을 차단했다는 기록은 없었다. 그냥 다운로드/설치 중에 파일이 어쩌다 손상됐나보다 하고 넘어갔다.

한 일: burpbrowser 폴더 통째로 삭제하고 Burp 재실행해서 다시 받게 유도함

결과: 삭제하고 나니까 이번엔 Burp 자체가 안 켜졌다. 스플래시 화면만 반짝하고 사라지는데 작업관리자에도 프로세스가 안 보임. 뭔가 같이 지워지면 안 되는 것까지 지워버린 듯ㅇㅅㅇ

2. 아예 밀고 재설치

그냥 처음부터 다시 까는 게 낫겠다 싶어서 Burp를 완전히 삭제하고 공식 사이트에서 새로 받았다.

결과: 설치는 잘 됐고 Burp 창도 멀쩡히 켜졌다. 근데 브라우저 켜는 순간 또 똑같은 에러. Burp's browser failed to start.

허허^_^

3. Burp 자체 진단 기능으로 다시 확인

에러 팝업에 Run health check라는 버튼이 있길래 눌러봤다. Burp가 스스로 진단해주는 기능이라고 한다. 출력 결과로는 이런 결과가 나왔다.

그리고 아래에 이런 메시지가 떴다.

No dev tools websocket output from local chromium process 13128

이게 중요한 것으로 보였다. 파일 손상 문제는 이미 해결된 상태였고(재설치했으니까), 크롬 프로세스도 실제로 켜지긴 켜졌다(PID 13128이 존재한다는 거니까). 근데 Burp랑 그 브라우저 사이의 통신(DevTools 프로토콜 웹소켓)이 안 되는 거였다. 프로세스는 살아있는데 대화가 안 되는 상황.

4. 로컬 통신을 막을 만한 걸 하나씩 꺼봄

프로세스는 뜨는데 통신만 막히는 거면 방화벽이나 가상 네트워크 어댑터 쪽을 의심해볼 만했다.

• 방화벽: BurpSuite.exe랑 chrome.exe(burpbrowser 안에 있는 거)를 방화벽 허용 목록에 수동으로 추가함 → 안 됨
• VMware 가상 네트워크 어댑터: VMnet1, VMnet8 잠깐 꺼봄 → 안 됨
• Burp 관리자 권한 실행 여부: 혹시 관리자 권한으로 켜서 하위 프로세스랑 권한이 안 맞나 싶었는데 애초에 관리자 권한으로 실행하고 있지도 않았음
• 별도 백신 프로그램: V3, 알약 같은 거 설치돼있나 확인함 → 아무것도 없었음

이 네 가지를 다 확인했는데도 에러는 그대로였다.

결국 원인이 뭐였는지

모르겠다. No dev tools websocket output 이 문구로 검색해봐도 딱 맞는 사례가 안 나왔다. 흔한 케이스는 아닌 것 같다. 방화벽, 가상 어댑터, 권한, 백신 이 네 가지 유력한 용의자를 다 지웠는데도 남는 게 없어서포기했다.

그래서 어떻게 했나 (우회)

계속 원인 찾다가는 공부 진도가 안 나갈 것 같아서 그냥 우회하기로 했다. Burp의 핵심 기능(프록시로 트래픽 가로채기, Repeater, Intruder 이런 거)은 내장 브라우저 없어도 똑같이 동작한다고 클로드가 말했다. 그래서 그냥 평소 쓰던 크롬을 수동으로 Burp 프록시에 연결해서 쓰면 되는 거였다.

1. 크롬 프록시 설정에서 127.0.0.1:8080(Burp가 기본으로 열어두는 주소)으로 수동 설정
2. http://burp 들어가서 CA 인증서 다운로드
3. 그 인증서를 크롬 신뢰 저장소에 등록
4. 아무 사이트나 들어가봤는데 인증서 경고도 안 뜨고, Burp의 HTTP history에 요청이 실시간으로 잘 찍혔다

느낀 점

• 같은 에러 문구(failed to start)라도 상황마다 원인 레이어가 완전히 다를 수 있다. 처음엔 파일 손상, 나중엔 통신 문제로 원인 자체가 바뀌었다.
• Burp에 Run health check 같은 자체 진단 기능이 있다는 걸 이번에 처음 알았다. 다음부턴 무작정 추측하지 말고 이런 기능부터 먼저 써봐야겠다.
• 모든 흔한 원인을 다 지워봤다고 정답이 나오는 건 아니었다. 이럴 땐 완벽하게 원인을 찾는 것보다 일단 공부를 계속할 수 있는 우회로를 찾는 게 더 현실적인 선택인 것 같다!

막혔던 부분

해결 방법

정리