서버가 끊기지 않는 방화벽 설정 방법

얼마 전 웹서버 이전 작업에서 새 서버의 접속이 갑자기 끊겼다. 방화벽에서 웹 포트만 열고 SSH 포트를 빠뜨린 게 원인이었다. 서버는 멀쩡했지만 관리자가 들어갈 길이 사라진 셈이다. 방화벽 설정 방법을 묻는다면 나는 규칙을 입력하는 명령보다, 접속 경로를 확인하는 순서부터 이야기한다.

먼저 실제로 쓰는 포트를 적는다

웹사이트 한 대를 운영한다면 외부에서 들어와야 할 포트는 보통 HTTP용 80, HTTPS용 443, 관리용 SSH 포트다. SSH는 흔히 22를 쓰지만 실제 값은 서버 설정에서 확인해야 한다. 데이터베이스가 같은 서버의 웹 애플리케이션에서만 쓰인다면 3306 같은 데이터베이스 포트를 인터넷에 열 이유가 없다.

포트 목록은 설치한 프로그램이 아니라 연결 주체를 기준으로 적는 편이 정확하다. 방문자가 접근하는 웹 포트, 관리자가 접근하는 SSH 포트, 서버끼리 통신하는 내부 포트를 나눠 적는다. 예를 들어 백업 서버가 별도로 접속한다면 그 서버의 접근 경로까지 확인해야 한다. 쓰지 않는 포트는 기존 규칙에 남아 있더라도 닫을 대상으로 표시한다.

현재 열려 있는 포트는 서버에서 sudo ss -lntp 명령으로 확인할 수 있다. 다만 이 명령은 프로그램이 대기 중인 포트를 보여줄 뿐, 외부에서 실제 접속할 수 있는지는 알려주지 않는다. 클라우드 보안 그룹이나 호스팅 업체의 방화벽이 앞단에서 막고 있을 수도 있다.

SSH를 확보한 뒤 기본 차단을 적용한다

아래 순서는 UFW를 사용하는 Ubuntu 서버를 기준으로 한다. 먼저 호스팅 업체의 웹 콘솔이나 복구 콘솔에 들어갈 수 있는지 확인한다. SSH 규칙을 잘못 넣었을 때 되돌아올 통로다. 지금 접속한 SSH 창도 닫지 말고 새 창에서 재접속을 시험한다.

실제 SSH 포트가 22라면 sudo ufw allow 22/tcp로 관리 접속을 먼저 허용한다.
웹서비스에는 sudo ufw allow 80/tcp와 sudo ufw allow 443/tcp를 추가한다.
sudo ufw default deny incoming으로 새로 들어오는 연결을 기본 차단한다.
sudo ufw default allow outgoing으로 서버가 시작하는 외부 연결은 허용한다.
sudo ufw status verbose로 규칙을 읽은 뒤 sudo ufw enable을 실행한다.

SSH 포트를 바꿔 쓴다면 22를 그대로 입력하면 안 된다. 설정된 포트를 먼저 허용하고, 새 창에서 해당 포트로 접속되는지 확인해야 한다. 관리자의 공인 IP가 고정돼 있다면 이후 SSH 허용 대상을 그 IP로 좁힐 수 있다. 유동 IP 환경에서 무턱대고 제한하면 다음 접속 때 스스로 잠길 수 있다.

기본 차단은 기존에 성립한 연결까지 일괄 끊는다는 뜻은 아니다. 그래도 현재 SSH 창이 살아 있다는 사실만으로 안전하다고 판단하면 곤란하다. 새 연결이 막혀 있으면 그 창을 닫는 순간 문제가 드러난다. 새 터미널에서 재접속까지 끝내야 관리 경로가 확인된다.

서버 안팎의 규칙을 함께 확인한다

VPS와 클라우드 서버에는 운영체제 방화벽 외에 보안 그룹이나 네트워크 방화벽이 있는 경우가 많다. 어느 한쪽에서 443을 차단하면 다른 쪽에서 허용해도 웹사이트는 열리지 않는다. 반대로 앞단에서 3306을 허용하고 서버에서만 막아 둔 상태라면, 나중에 서버 규칙을 바꾸는 순간 데이터베이스가 노출될 수 있다.

나는 두 곳의 규칙을 같은 표로 대조한다. 80과 443은 방문자에게 필요한지, SSH는 누가 어디서 접속하는지, 데이터베이스와 관리 화면은 외부 공개가 필요한지 적는다. 관리용 서비스는 가능하면 내부 네트워크나 별도 접속 경로로 묶는다. 서버 한 대짜리 소규모 사이트라면 복잡한 장비를 추가하기보다 이 표를 정확히 유지하는 편이 실수가 적다.

IPv6도 빠지기 쉽다. 서버에 IPv6 주소가 있고 서비스가 IPv6에서 대기한다면 IPv4 규칙만 확인해서는 부족하다. UFW의 IPv6 처리 상태와 호스팅 업체의 IPv6 방화벽을 함께 확인한다. 주소 체계마다 허용 범위가 다른 상태로 운영하지 않는 게 좋다.

적용 직후에는 외부에서 접속을 시험한다

방화벽을 켠 뒤에는 서버 내부에서만 확인하지 않는다. 다른 네트워크에서 웹페이지가 80과 443으로 열리는지, 새 SSH 연결이 되는지 시험한다. 사용하지 않는 포트는 외부에서 연결되지 않아야 한다. 특히 웹페이지 첫 화면만 보지 말고 로그인, 파일 업로드, 외부 결제 호출처럼 운영에 필요한 기능도 확인한다.

접속이 안 된다면 웹서비스가 해당 포트에서 실행 중인지, 서버 방화벽이 허용하는지, 앞단 보안 그룹이 허용하는지 순서대로 본다. 무작정 모든 포트를 여는 방식은 원인을 가릴 뿐이다. 규칙을 바꾸기 전 sudo ufw status numbered 결과를 남겨 두면 되돌릴 때도 편하다. 규칙 번호로 삭제할 때는 삭제 후 번호가 바뀔 수 있으니 매번 목록을 다시 읽는다.

트래픽이 적은 사이트에 비싼 방화벽 상품이 먼저 필요한 경우는 드물다. 웹 포트와 관리 포트의 역할을 구분하고, 복구 콘솔을 확보하고, 변경 직후 새 연결을 시험하는 절차가 더 큰 차이를 만든다. 실제 장애도 대개 처리 용량보다 이런 작은 설정 누락에서 시작했다.