모두
모두콘텐츠
얼마 전 작은 쇼핑몰 서버를 옮기면서 방화벽 규칙을 확인했는데, 웹 접속은 잘 되는데도 운영자가 관리 화면에 들어가지 못했다. 새 서버의 접속 허용 목록에 운영자 사무실의 현재 IP가 빠져 있었다. 방화벽 설정에서 무서운 건 규칙을 몇 개 빠뜨리는 일보다, 그 규칙을 적용한 뒤 서버에 다시 들어갈 길이 없어지는 일이다.
열어야 할 포트부터 적는다
규칙을 만들기 전에 실제 접속 경로를 종이에 적어본다. 일반적인 웹사이트라면 방문자가 들어오는 통로는 80번과 443번 포트다. 관리자 접속에 22번 포트를 쓴다면 누가, 어느 IP에서 들어오는지도 적는다. 애플리케이션과 데이터베이스가 같은 서버에 있다면 데이터베이스 포트를 외부에 열 이유는 대개 없다.
흔히 보이는 실수는 나중에 필요할지 모른다는 이유로 포트를 넓게 여는 것이다. 예를 들어 데이터베이스의 3306번 포트를 전체 인터넷에 허용해 두면 접속 시도와 비밀번호 대입 공격이 꾸준히 들어온다. 애플리케이션 서버만 데이터베이스에 접속한다면 그 서버의 사설 IP에서 오는 요청만 허용하면 된다. 서버 한 대 안에서만 통신한다면 외부 인터페이스로 접속을 받지 않도록 서비스 자체의 수신 주소도 확인해야 한다.
관리자 접속도 마찬가지다. 사무실처럼 IP가 고정된 곳에서만 접속한다면 해당 IP만 허용하는 편이 단순하다. 집이나 이동 중 접속이 잦아 IP가 자주 바뀐다면 특정 주소 하나에만 의존하는 규칙은 운영 중 장애가 된다. 이때는 별도의 관리 접속 경로를 마련하고, 실제로 접속되는지 확인한 뒤 허용 범위를 좁히는 게 안전하다.
허용 규칙을 먼저 만들고 차단을 적용한다
방화벽의 기본 원칙은 필요한 인바운드 접속만 허용하고 나머지는 차단하는 것이다. 다만 작업 순서가 중요하다. 현재 관리 접속을 유지한 채 관리자 IP, 웹 서비스 포트, 서버 간 통신에 필요한 규칙을 먼저 등록한다. 새 터미널에서 관리자 접속이 다시 되는지 확인한 다음 기본 차단 규칙을 적용한다. 열려 있던 터미널 하나에서 명령이 성공했다고 접속 경로까지 검증된 것은 아니다.
원격 서버라면 작업 전에 호스팅 관리 화면의 콘솔 접속 방법도 확인한다. 접속이 끊겼을 때 방화벽 규칙을 되돌릴 수 있는 경로다. 콘솔을 제공하지 않는 환경이라면 일정 시간이 지나면 이전 규칙으로 복구되도록 예약 작업을 걸고, 검증이 끝난 뒤 예약을 취소하는 방법이 있다. 이 준비 없이 원격 접속 포트를 막으면 서버는 정상 작동해도 운영자는 손을 댈 수 없다.
이미 연결된 세션과 그 응답 트래픽을 허용하는 상태 기반 규칙도 확인한다. 인바운드만 막는 구성이라면 웹서버가 업데이트를 받거나 이름을 조회할 때 쓰는 아웃바운드 통신에는 영향이 적다. 아웃바운드까지 제한한다면 DNS 조회, 시간 동기화, 패키지 업데이트, 외부 결제 연동처럼 서버가 먼저 시작하는 통신을 따로 적어야 한다. 웹 화면이 뜬다는 이유만으로 이런 기능까지 정상이라고 판단하면 사고가 늦게 드러난다.
클라우드 방화벽과 서버 내부 규칙을 함께 본다
클라우드 서버에는 서비스 관리 화면의 네트워크 방화벽과 운영체제 내부 방화벽이 함께 있는 경우가 많다. 둘 중 한쪽에서 막으면 접속은 실패한다. 그래서 장애가 나면 애플리케이션부터 고치기 전에 두 규칙을 나란히 확인한다. 외부 방화벽에서 443번을 열었더라도 내부에서 차단 중이면 방문자는 사이트에 들어오지 못한다.
IPv4 규칙만 보고 끝내는 것도 자주 놓치는 부분이다. 서버에 IPv6 주소가 붙어 있고 서비스가 그 주소로도 요청을 받는다면, IPv6 방화벽 정책도 같은 기준으로 확인해야 한다. 반대로 IPv6를 쓰지 않는다면 실제로 외부 접속 경로가 열려 있는지부터 확인한다. 주소 체계가 하나 더 있다고 무조건 위험한 것은 아니지만, 운영자가 규칙을 한쪽만 관리하면 의도와 다른 통로가 남을 수 있다.
규칙 이름이나 메모에는 포트 번호만 쓰지 말고 허용 이유를 남기는 편이 좋다. ‘운영자 원격 접속’, ‘웹 공개’, ‘애플리케이션에서 데이터베이스 접속’처럼 적어두면 나중에 서버를 이전하거나 담당자가 바뀔 때 삭제할 규칙을 판단하기 쉽다. 한동안 사용하지 않은 허용 규칙을 발견해도 이유를 모르면 선뜻 닫기 어렵다.
서버 밖에서 접속을 검사한다
규칙을 적용한 뒤에는 서버 내부에서만 검사하지 않는다. 외부 네트워크에서 웹 접속과 관리자 접속을 각각 확인하고, 열지 않기로 한 포트에도 접속이 되는지 확인한다. 80번을 443번으로 보내는 구성이라면 두 포트의 동작을 따로 본다. IPv6를 사용한다면 IPv4와 IPv6 결과도 각각 확인한다. 내부 검사만으로는 클라우드 방화벽이나 외부 경로에서 막히는 문제를 발견하기 어렵다.
접속 실패가 모두 방화벽 때문인 것은 아니다. 서비스가 해당 포트에서 실제로 요청을 받고 있는지, 수신 주소가 서버 외부 접속을 허용하는지, 최근 변경한 규칙에서 거부 기록이 남았는지를 순서대로 보면 원인을 좁힐 수 있다. 로그를 켤 때는 차단된 모든 패킷을 장기간 기록하기보다 필요한 규칙과 기간을 정해 둔다. 인터넷에 노출된 서버에서는 잡음이 많아 중요한 기록이 묻힐 수 있다.
현재 규칙을 파일이나 운영 문서에 남기고, 서버 복구 절차에도 포함한다. 백업에서 서버를 되살렸는데 방화벽 규칙이 빠지면 사이트가 안 열리거나 관리 포트가 예상보다 넓게 열릴 수 있다. 방화벽 설정은 강한 규칙을 많이 만드는 작업이라기보다, 필요한 접속을 정확히 적고 실제 경로에서 반복해 확인하는 운영 작업에 가깝다.
