자체 프록시 IP 구축: SSH 초기 설정과 보안 강화

클라우드 서버를 구입해 프록시로 사용할 때 막히는 지점은 기본 연결 자체인 경우가 드뭅니다. 대부분은 서버 측 준비 순서에서 문제가 생깁니다. 순서를 제대로 따르면 클라이언트가 대개 한 번에 연결되지만, 순서가 꼬이면 설정을 고치기 위해 계속 터미널로 돌아가야 합니다.

여기서는 서버 측만 다룹니다. 첫 로그인, 접속 경로 강화, 프록시 서비스 실행, 포트 개방, 클라이언트 연결, 그리고 연결되지 않을 때 계층별로 원인을 찾는 방법까지 설명합니다.

첫 로그인에서는 먼저 접속부터 확인하기

인스턴스를 만든 뒤에는 처음부터 로컬 도구에 의존하지 말고, 제공업체 콘솔에 있는 웹 터미널로 먼저 로그인합니다. 이 단계의 목적은 서버가 살아 있고 네트워크에 도달할 수 있는지만 확인하는 것입니다.

접속한 뒤 sudo -i 를 실행하고 Enter를 눌러 root로 전환합니다. 프롬프트가 $ 에서 # 으로 바뀌면 권한 상승이 성공한 것입니다. 이후 작업은 이 권한으로 진행합니다.

그 자리에서 네 가지 정보를 기록해 둡니다. 공인 IP, 로그인 사용자 이름(Linux 기본값은 root), 비밀번호, SSH 포트(기본값 22)입니다. 클라이언트 접속에는 이 네 값이 모두 필요하며 하나라도 빠지면 연결할 수 없습니다.

기본 포트를 바꾸고 키 기반 로그인으로 전환하기

22번 포트는 매일 셀 수 없이 스캔되고 자동화된 로그인 시도도 흔합니다. 포트를 바꾼다고 서버 자체가 더 강해지는 것은 아니지만, 자동화된 잡음 대부분을 걸러낼 수 있습니다.

변경은 /etc/ssh/sshd_config 에서 합니다. vi 로 파일을 열고 i 를 눌러 편집 모드로 들어간 뒤 PermitRootLogin 과 PasswordAuthentication 줄을 yes 로 바꿉니다. 이후 Esc 를 누르고 :wq 를 입력해 저장하고 종료합니다. 제공업체가 키 로그인을 지원한다면 로컬 공개 키를 서버의 authorized_keys 에 추가한 다음 PasswordAuthentication 을 no 로 바꿔 키만 허용하는 편이 더 안정적입니다.

설정을 바꾼 직후 현재 세션을 바로 종료하지 마세요. 먼저 다른 터미널 창을 열고 새 포트와 새 방식으로 한 번 로그인해 접속되는지 확인한 뒤 기존 창을 닫습니다. 그렇지 않으면 설정 오류 때문에 스스로 접속을 막아 버려 제공업체 콘솔에서 복구해야 할 수 있습니다.

SSH 포트는 Port 줄에서 변경합니다. 변경 뒤에는 설정을 적용하기 위해 SSH 서비스를 다시 시작합니다. Debian 및 Ubuntu 계열에서는 /etc/init.d/ssh restart 를 실행할 수 있습니다.

첫날에 기본 보안 강화를 끝내기

포트 변경과 키 사용 외에도 첫날 처리해 두면 좋은 일이 두 가지 있습니다. 첫째, passwd root 로 root에 충분히 길고 무작위인 비밀번호를 설정하고 추측하기 쉬운 조합은 사용하지 않습니다. 둘째, 사용하지 않는 서비스와 포트를 닫습니다. 서버에서 실행되는 항목이 적을수록 공격 표면도 작아지며, 시스템 방화벽은 실제로 필요한 포트만 허용해야 합니다.

이 서버를 장기간 몇 개의 고정된 출발지에서만 사용할 예정이라면 보안 그룹에서 소스 주소를 해당 위치로 제한합니다. 인터넷 전체에 개방하는 것보다 훨씬 안전합니다.

프록시 서비스를 설치하고 인증 구성하기

서버 측 초기화가 끝났다면 이제 프록시 자체를 설정합니다.

한 가지 방법은 SSH 터널을 직접 사용하는 것입니다. 서버에 추가로 설치할 것이 없고, 클라이언트가 시스템에 기본 제공되는 SSH 서비스를 포워딩에 사용하며 인증 정보도 서버 계정을 그대로 씁니다. 간단하지만 성능은 보통 수준이고 동시 접속이 많아지면 부담이 커지므로 임시 사용이나 적은 수의 계정에 적합합니다.

다른 방법은 서버에 전용 프록시 서비스를 설치하는 것입니다. 보통 설치 명령 한 줄로 설치할 수 있고, 이후 인증 방식과 수신 포트를 직접 설정합니다. 부팅 시 자동 시작도 켜 두어야 합니다. 그렇지 않으면 서버가 한 번 재시작될 때 프록시도 함께 중지됩니다.

인증은 보안 수준이 높아지는 세 단계로 볼 수 있습니다. 사용자 이름과 비밀번호가 가장 간단하지만 유출되면 사실상 프록시를 넘겨준 것과 같습니다. 비밀번호에 소스 IP 허용 목록을 더하면 일상적인 사용에는 대체로 충분합니다. 키 또는 인증서 인증이 가장 견고하며 설정은 조금 더 번거롭지만 장기간 운영할 계정에는 그만한 가치가 있습니다.

포트는 두 곳에서 각각 열기

가장 자주 막히는 부분입니다. 프록시 서비스의 수신 포트는 시스템 방화벽과 제공업체 보안 그룹에서 각각 허용해야 합니다. 두 설정은 서로 독립적이므로 한쪽만 열면 연결할 수 없습니다.

또 쉽게 놓치는 부분이 서비스의 수신 주소입니다. 일부 서비스는 기본적으로 127.0.0.1 에만 바인딩됩니다. 서버 내부 테스트는 성공하지만 외부에서 접속되지 않는다면 이 설정이 원인인 경우가 많습니다. 수신 주소를 서버의 사설 주소 또는 0.0.0.0 으로 변경합니다.

로컬 클라이언트에서 접속하기

환경 관리 도구에서 새 환경을 만들고 실제로 사용하는 프록시 유형을 선택합니다. SSH 터널을 사용한다면 주소는 서버의 공인 IP, 포트는 SSH 포트, 사용자 이름과 비밀번호는 서버 인증 정보를 입력합니다. 입력 후 연결 테스트를 실행합니다.

테스트에 성공했다는 것은 경로가 열려 있다는 뜻일 뿐입니다. 환경을 열고 세 가지를 더 확인합니다. 출구 IP가 서버의 공인 IP인지, DNS도 프록시를 통과하는지 확인합니다. DNS가 로컬에서 계속 해석되면 출구 IP와 맞지 않는 지역 정보가 노출될 수 있습니다. 또한 시간대와 언어가 출구 지역과 일치하는지도 확인합니다. 세 가지를 모두 통과해야 환경을 사용할 수 있다고 볼 수 있습니다.

계정이 많아지면 여러 계정이 하나의 환경을 공유하지 않도록 환경과 출구의 대응 관계를 고정합니다. PurpleMark 같은 도구는 계정마다 개별 출구를 연결할 수 있어 수동으로 매핑 표를 관리하는 것보다 안정적입니다.

연결되지 않으면 바깥쪽부터 안쪽으로 점검하기

가장 바깥 계층부터 봅니다. 보안 그룹에서 허용했는지, 시스템 방화벽에서 허용했는지 확인합니다. 두 곳을 모두 확인한 뒤 다음으로 넘어갑니다.

그다음 서비스 자체를 확인합니다. 프로세스가 아직 실행 중인지, 특히 서버를 재시작한 뒤라면 반드시 확인합니다. 수신 주소가 로컬에만 바인딩되어 있지는 않은지도 봅니다.

그다음 인증 계층을 확인합니다. 사용자 이름이나 비밀번호가 잘못되지는 않았는지, 키 파일 권한이 너무 넓지는 않은지 확인합니다. 권한이 잘못되어 있으면 SSHD가 키를 바로 거부합니다. 마지막으로 클라이언트 측을 확인해 공인 IP를 입력했는지, 실수로 사설 IP를 넣지는 않았는지 봅니다. 이 부분은 특히 혼동하기 쉽습니다.

이 순서대로 확인하면 서비스를 반복해서 재설치하는 대신 보통 두세 차례 점검만으로 문제가 어느 계층에 있는지 찾을 수 있습니다.

마무리

서버 측 준비는 30분도 걸리지 않지만, 이후 몇 달 동안 이 서버를 얼마나 편하게 운영할 수 있는지를 좌우합니다. 접속 경로를 강화하고 필요한 포트를 정확히 열며 인증을 명확하게 구성해 두면 나머지는 일상적인 유지 관리뿐입니다.