노트북 한 대가 온프레미스 서버가 되기까지 네트워크 2편 – 공인 IP, SSH 보안, VPN

 

기능하는 서버와 안전한 서버는 다르다

이전 글에서 포트포워딩을 설정하고, SSH 접속이 가능하도록 만들었다.

 

원했던 건 다 됐다.
밖에서 접속됐고, 명령도 실행됐고, 서버는 “잘 작동”했다.

 

그런데 이상하게도 마음이 편하지 않았다.

서버는 분명 열려 있었는데,
이게 과연 “괜찮은 상태”인지 확신이 들지 않았다.

 

그래서 이런 질문이 머릿속에 남았다.

“이 서버는 지금 얼마나 노출되어 있는 걸까?”

 

서버가 작동하는 것과,
서버가 안전하게 작동하는 건 전혀 다른 문제라는 생각이 들었다.
이 글은 그 질문에서 시작해서, 접근 구조 자체를 바꾸기까지의 기록이다.

 

---

 

외부에서 이 서버는 어떻게 보이는가

가장 먼저 든 생각은 단순했다. “밖에서는 이 서버를 어떻게 보고 있을까?”

그래서 외부 인터넷 기준에서 IP를 확인해봤다.

curl ifconfig.me

 

출력 결과는 다음과 같다.

58.xxx.xx.xx

 

처음엔 이게 서버의 주소라고 생각했지만, 곧 아니란 걸 알게 됐다.

 

이 IP는 서버의 IP가 아니다.
공유기(NAT 장비)의 공인 IP다.

 

구조를 단순화하면 다음과 같다.

[ 인터넷 ]
↓
[ 공인 IP: 58.xxx.xx.xx ] (공유기)
↓
[ 사설 IP: 192.168.45.34 ] (서버)

 

정리하면,

서버는 여전히 192.168.45.0/24 대역의 사설 IP를 쓰고 있고,
외부에서는 공유기까지만 보인다.

다만 포트포워딩으로 특정 포트만 서버로 전달되는 상태였다.

 

여기까지는 알고 있던 내용이었다.
문제는 “외부에서 보이는 모습”이었다.

외부에서 보이는 구조

외부 사용자, 혹은 공격자 입장에서 이 서버는 이렇게 보인다.

[공인 IP (공유기)] → [열린 포트: 22] → [?]

 

그 뒤에 노트북이 있는지, 서버 랙이 있는지는 중요하지 않다.
열린 포트가 있다는 사실만으로도 이미 대상이 된다.

 

---

 

SSH는 왜 공격의 첫 번째 대상이 되는가

SSH의 역할

SSH(Secure Shell)는 원격 서버 접속을 위한 프로토콜이다.
서버 관점에서 SSH는 다음과 같은 의미를 가진다.

 

서버를 관리하는 모든 작업은 SSH로 한다. 모니터도 없고, 키보드도 없는 서버에서
SSH는 사실상 유일한 출입구다. 그래서 서버를 연다는 말은, 결국 SSH를 연다는 말과 거의 같다.

 

현재 SSH 상태 확인

서버의 SSH 상태를 확인했다.

 

dpkg -l | grep openssh-server
systemctl status ssh
ss -tnlp | grep ssh

 

현재 상태는 다음과 같았다.

• OpenSSH 서버 설치 완료
• SSH 데몬 상시 실행 중
• 부팅 시 자동 시작
• 모든 인터페이스에서 22번 포트 리스닝

이 상태의 의미는 명확하다.

 

포트포워딩 활성화
→ SSH 포트 인터넷 노출
→ 전 세계 어디서든 접근 시도 가능

서버는 지금 인터넷에 노출된 상태로 SSH 접속을 기다리고 있다.

 

---

 

실제로 누가 이 서버를 두드리고 있는가

로그 확인

당시에 SSH 접근 시도를 확인하기 위해 인증 로그를 확인했다.

 

sudo tail -f /var/log/auth.log

 

로그에는 다음과 같은 메시지가 반복해서 찍히고 있었다.

 

Failed password for invalid user admin
Failed password for root
Connection closed [preauth]

 

서버를 구축한 지 몇 시간도 지나지 않았는데,
이미 전 세계에서 무차별 접근 시도가 들어오고 있었다.

 

공격 패턴

로그에서 확인된 공격 패턴은 다음과 같다.

• admin, root 같은 계정 이름 추측
• 비밀번호 무차별 대입
• 자동화된 봇에 의한 반복 시도

 

---

SSH 보안 강화 시도

비밀번호 인증 비활성화

가장 먼저 SSH 설정을 강화했다.

비밀번호 인증을 끄고, 키 기반 인증만 허용하고, root 로그인도 막았다.

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

 

이후 SSH를 재시작했다.

 

키 기반 인증으로 전환

비밀번호 대신 SSH 키 기반 인증을 사용하도록 전환했다.

이 조치로 인해,

• 비밀번호 무차별 대입 공격은 무효화되었고
• 키 파일 없이는 접속 자체가 불가능해졌다.

포트 변경

SSH 포트를 22번에서 다른 포트로 변경했다.

하지만 포트 변경은 보안이 아니라 난독화에 가깝다.
전체 포트 스캔을 하는 공격자에게는 큰 의미가 없다.

 

---

SSH 보안 강화의 근본적 한계

설정을 아무리 강화해도 변하지 않는 사실들이 있었다.

• 포트는 여전히 인터넷에 열려 있다.
• 공인 IP는 노출되어 있다.
• 공격 시도 자체는 계속된다.

현재 구조를 다시 보면 다음과 같다.

 

[ 인터넷 ]
→ [ 공인 IP 노출 ]
→ [ 포트 개방 ]
→ [ SSH 인증 ]
→ [ 서버 ]

 

 

이 구조의 본질은
먼저 노출하고, 나중에 막는 방식이다.

이 시점에서 질문이 바뀌었다.

“어떻게 더 잘 막을까?”가 아니라
“애초에 공격 대상이 되지 않을 수는 없을까?”

 

---

VPN: 접근 구조를 근본적으로 바꾸다

VPN을 쓰면 보안이 좋아진다, 암호화된다 — 이런 이야기는 많이 들었지만, 이 순간에 와닿은 건 다른 점이었다.

VPN은 서버를 먼저 보여주지 않는다. 서버는 내부 네트워크에 있고,
먼저 인증된 경우에만 그 네트워크에 들어올 수 있다.

 

기존 구조는 이랬다.

외부 → 인터넷 → 공인 IP → SSH 인증 → 서버

 

VPN 구조는 이렇게 바뀐다.

외부 → VPN 인증 → 내부 네트워크 → 서버

 

차이점은 명확하다.

• SSH 포트를 외부에 열 필요가 없다.
• VPN 연결 전에는 서버가 보이지 않는다.
• 접근 자체가 내부망 문제가 된다.

---

WireGuard VPN 구성

VPN 솔루션 중에서 WireGuard를 선택했다.

설정이 단순했고, 커널 레벨에서 동작하며, 구조가 명확했다.

 

VPN을 구성하고 나니
서버에는 두 개의 네트워크가 생겼다.

 

하나는 기존의 로컬 사설망.
인터넷으로 나가는 출구 역할을 한다.

 

로컬 사설망

인터페이스: wlp2s0
IP: 192.168.45.34
역할: 인터넷 출구

VPN 내부망

인터페이스: wg0
IP: 10.100.0.1
역할: 외부 접근 경로

 

SSH 접속 방식도 자연스럽게 바뀌었다.

예전에는 공인 IP로 바로 접속했다면,
이제는 VPN에 먼저 연결한 뒤 내부 IP로 접속한다.

이제 SSH는 인터넷이 아니라 내부 네트워크 문제였다.

 

---

포트포워딩과 VPN 비교

포트포워딩 구조는 항상 노출된 상태에서 인증을 시도한다.

VPN 구조는 인증된 경우에만 서버가 보인다.  보안 장벽의 개수도 다르다.

 

포트포워딩: SSH 인증 1단계
VPN: VPN 인증 + SSH 인증 2단계

 

공격자 관점에서도 차이는 크다.

포트포워딩은 “항상 시도 가능”
VPN은 “시도 자체가 불가능”

 

---

 

SSH 설정을 아무리 강화해도 포트포워딩이라는 구조는 공격 표면을 제거하지 못한다.

VPN은 서버를 숨기고, 접근을 조건부로 만든다.

 

마무리

이번 글에서는 공인 IP 노출 구조, SSH가 공격 대상이 되는 이유,
포트포워딩의 한계, VPN을 통한 접근 구조 전환을 다뤘다.

 

다음 글에서는 이 온프레미스 경험을
AWS VPC, Security Group, Private Subnet 개념으로 직접 매핑해본다.

 

온프레미스에서 이해한 구조를
클라우드 언어로 번역하는 단계다.

 

네트워크 관련 이야기가 끝나면, 다음으로는 CI/CD 및 도커 관련 이야기로 넘어가보자