방화벽과 포트 설정 — 서버 22·80·443번 문 열기

서버의 방화벽과 포트가 무엇인지, 어떤 포트를 왜 열고 닫는지 문지기 비유로 정리. 외부에서 서버에 접속하려면 무엇이 필요한지 기초부터 설명했다.

이 글은 오라클 무료 서버로 나만의 서버를 만드는 과정 중, ‘바깥세상이 서버에 접속하도록 문을 여는’ 단계에 대한 기록입니다.

서버를 만들었는데, 왜 아무도 못 들어올까

지난 글에서 오라클의 공짜 서버를 빌려 블로그를 올렸다. 그런데 서버를 만들었다고 바로 세상에 열리는 건 아니었다. 주소를 입력해도 화면이 안 뜨고 하염없이 기다리기만 했다. 서버는 분명 살아 있는데, 바깥에서 들어올 ‘문’이 닫혀 있었던 것이다.

돌이켜보면 이 ‘문 여는 단계’가 서버 구축에서 처음 만나는 가장 큰 벽이었다. 오늘은 그 문을 여는 이야기를 해보려 한다.

포트란 무엇인가 — 서버의 여러 출입문

먼저 알아야 할 개념이 ‘포트’다.

📌 포트(port)란? 서버로 들어오는 ‘용도별 출입문’이라고 보면 된다. 하나의 서버에는 여러 개의 문이 있고, 각 문마다 번호가 붙어 있다. 어떤 문은 관리자가 드나드는 문, 어떤 문은 방문자가 웹페이지를 보러 오는 문이다.

서버라는 건물에 문이 여러 개 있다고 상상하면 쉽다. 그리고 각 문에는 번호표가 붙어 있는데, 우리가 알아야 할 주요 문은 세 개다.

포트 번호이름무엇에 쓰나
22SSH관리자(나)가 서버에 원격으로 접속할 때
80HTTP방문자가 일반 웹페이지를 볼 때
443HTTPS방문자가 보안 연결된 웹페이지를 볼 때

📌 SSH / HTTP / HTTPS SSH는 관리자가 멀리서 서버를 조종하는 통로다. HTTP는 웹페이지가 오가는 일반 통로이고, HTTPS는 여기에 보안 자물쇠가 채워진 통로다. 주소창이 ‘https’로 시작하고 자물쇠가 보이는 게 바로 이 443번 문을 쓴다는 뜻이다.

내 서버는 처음에 22번(관리용) 문만 열려 있었다. 그래서 나는 관리자로 접속할 수 있었지만, 정작 방문자가 블로그를 보러 오는 80번과 443번 문은 닫혀 있었다. 그러니 아무도 못 들어왔던 것이다.

방화벽이란 — 문 앞의 문지기

그럼 이 문들은 누가 여닫을까. 바로 방화벽이다.

📌 방화벽(firewall)이란? 서버의 문 앞을 지키는 ‘문지기’다. 어떤 손님(접속)을 들여보내고 어떤 손님을 막을지 정해둔 규칙에 따라 통제한다. 기본적으로는 대부분의 문을 잠가두기 때문에, 원하는 문은 “이 문은 열어줘라”고 따로 알려줘야 한다.

방화벽이 있기에 서버는 아무나 함부로 들어오지 못하게 보호된다. 문제는, 블로그처럼 누구나 방문해야 하는 서비스는 80번과 443번 문을 열어달라고 이 문지기에게 부탁해야 한다는 점이다.

오라클의 함정 — 문지기가 둘이었다

여기서 내가 가장 크게 헤맸다. 오라클 서버는 문지기가 하나가 아니라 둘이었기 때문이다. 아래 그림처럼, 방문자가 서버 안에 닿으려면 두 명의 문지기를 모두 통과해야 한다.

방문자가 클라우드 방화벽과 서버 내부 방화벽이라는 두 문지기를 모두 통과해야 서버의 웹 서비스에 닿는 구조를 보여주는 다이어그램

첫 번째 문지기는 클라우드 콘솔 쪽 방화벽(오라클에서는 ‘보안 목록’이라 부른다)이고, 두 번째 문지기는 서버 내부의 방화벽이다. 두 문지기가 각각 따로 문을 지키고 있어서, 한 명에게만 “문 열어줘”라고 부탁하면 다른 한 명이 여전히 막고 있어 접속이 안 된다.

나는 처음에 이걸 몰라서, 클라우드 콘솔 쪽에서만 문을 열고는 “왜 안 되지?” 하며 한참을 씨름했다. 알고 보니 서버 안에도 또 다른 문지기가 버티고 있었던 것이다. 이 사실을 깨닫고 두 곳을 모두 열어주자, 그제야 블로그가 세상에 나타났다.

직접 열어보니 — 순서도 중요했다

두 번째 문지기(서버 내부 방화벽)를 열 때는 한 가지 함정이 더 있었다. 이 문지기는 규칙을 위에서부터 순서대로 확인하는데, 맨 아래에 “위에서 허락하지 않은 나머지는 전부 막아라”는 규칙이 자리 잡고 있었다. 그래서 새로 여는 80번·443번 문 규칙을, 이 ‘전부 막아라’ 규칙보다 위쪽에 끼워 넣어야 했다. 아래에 넣으면 이미 막아버린 뒤라 아무 소용이 없었다.

이런 건 아는 사람에겐 당연하지만, 처음 하는 사람에겐 보이지 않는 함정이다. 나도 규칙을 분명히 추가했는데도 접속이 안 돼서, 순서가 문제라는 걸 뒤늦게 알아챘다.

왜 ‘모두에게 여는’ 게 괜찮을까

문을 열 때, “누구에게 이 문을 열어줄까”도 정해야 한다. 나는 ‘모든 곳에서의 접속’을 허용하도록 열었다. 언뜻 위험해 보이지만, 블로그는 원래 전 세계 누구나 방문할 수 있어야 하니 이게 정상이다. 우리 집 가게 문을 모든 손님에게 여는 것과 같은 이치다. (물론 관리자용 22번 문은 이야기가 다르지만, 그건 다른 기회에 다뤄보고 싶다.)

문을 열어두면 실제로 누가 두드리나

문 세 개를 열어놓고 한 달을 지내봤다. 그리고 오늘 서버의 기록을 열어봤는데, 솔직히 예상보다 훨씬 시끄러웠다. 먼저 지금 이 서버의 문지기가 어떤 상태인지부터 그대로 옮기면 이렇다.

문상태누가 쓰나
22번 (SSH)열림나 (관리)
80번 (HTTP)열림방문자
443번 (HTTPS)열림방문자
그 밖의 모든 문거부–

딱 세 개만 열려 있고 나머지는 전부 막혀 있다. 이 글에서 설명한 그대로다. 그런데 열어둔 문에는 곧바로 손님이 아닌 손님이 몰려왔다.

22번 문 — 32일 동안 53,865번의 노크

바로 앞에서 “관리자용 22번 문은 이야기가 다르니 다른 기회에”라고 미뤄뒀는데, 실은 그 기록이 가장 할 말이 많았다. 관리용으로 열어둔 22번 문에서는 32일 동안 비밀번호를 맞혀보려는 시도가 53,865번 있었다. 하루 평균 1,683번, 한 시간에 70번꼴이다. 시도한 곳은 2,731개의 서로 다른 주소였고, 그중 가장 집요한 한 곳은 혼자서 1,472번을 두드렸다.

무엇으로 들어오려 했는지도 남아 있다. 가장 많이 시도된 계정 이름들이다.

시도된 계정 이름횟수
admin7,133회
user2,497회
debian1,626회
test1,357회
postgres724회
ftpuser697회
deploy653회
oracle604회

전부 ‘누구나 쓸 법한 흔한 이름’이다. 즉 이들은 나를 노린 게 아니라, 인터넷 전체를 훑으며 흔한 이름과 흔한 비밀번호가 걸리는 서버를 찾고 있었던 것이다. 서버를 만들고 문을 여는 순간, 나도 그 그물 안에 들어간다.

다행히 비밀번호로 뚫린 건 0건이다. 애초에 이 서버는 비밀번호로는 아예 접속이 안 되도록 꺼두고, 열쇠 파일을 가진 사람만 들어올 수 있게 해두었기 때문이다. 53,865번의 시도가 전부 헛수고였던 이유는 문지기가 세서가 아니라, 맞힐 비밀번호 자체가 없어서다. 이 이야기는 SSH를 다룬 글에 더 적어두었다.

80·443번 문 — 방문자보다 침입 시도가 많았다

웹페이지를 보러 오는 문도 조용하지 않았다. 같은 기간 서버에 들어온 요청 69,657건 중, 존재하지도 않거나 관리자만 쓰는 주소를 두드린 게 이만큼이다.

두드린 곳횟수무엇을 노린 것인가
xmlrpc.php20,499회요청 하나에 비밀번호를 여러 개 실어 보내는 통로
wp-login.php5,922회관리자 로그인 화면
wp-admin/install.php1,476회설치가 안 끝난 사이트를 가로채려는 시도
.env67회비밀번호가 적힌 설정 파일을 훔치려는 시도

이 표를 만들고 나서야 방화벽의 의미를 제대로 이해했다. 방화벽은 문을 잠그는 도구가 아니라, 열 문을 최소한으로 줄이는 도구다. 열어둔 세 개의 문에는 이렇게 매일 두드리는 소리가 나는데, 만약 필요도 없는 문을 열 개쯤 더 열어뒀다면 그만큼 두드릴 곳이 늘었을 것이다. 그래서 ‘이 문은 왜 열려 있지?’라는 질문에 답할 수 없는 문은 닫아두는 게 맞다.

※ 위 숫자는 2026년 8월 7일에 이 블로그를 돌리고 있는 서버에서 직접 확인한 값이다. 서버 사양과 요금제, 공격의 양은 시기와 환경에 따라 달라진다. 보안상 서버의 실제 주소는 적지 않았다.

정리하며

서버를 만드는 것과 세상에 여는 것은 별개의 일이었다. 서버에는 용도별 문(포트)이 있고, 그 문을 지키는 문지기(방화벽)가 있다. 특히 오라클은 문지기가 둘이라, 두 곳을 모두 열어야 비로소 방문자가 들어올 수 있었다.

문을 열고 나니, 이제 그 안에 무엇을 어떻게 담을지가 다음 고민이었다. 나는 프로그램들을 각각의 상자에 나눠 담는 방식을 썼는데, 처음엔 이게 왜 편한지 잘 몰랐다. 그 이야기는 아직 나도 정리가 덜 됐으니, 좀 더 손에 익으면 그때 풀어보고 싶다.


※ 이 글은 개인의 학습·구축 경험을 공유하기 위한 기록입니다. 클라우드 서비스의 화면과 설정 방식은 변경될 수 있으니, 실제 이용 시에는 해당 서비스의 최신 안내를 확인하시기 바랍니다.

steadydawn
steadydawn

감이 아니라 데이터와 규칙으로 투자에 접근해보려는 사람입니다. 투자 전문가는 아니고 배우는 쪽에 가깝습니다. 그래서 시중에 알려진 공개 전략을 직접 코드로 백테스트해보고, 나온 숫자를 좋든 나쁘든 그대로 기록합니다. 특히 결과가 좋게 나올수록 한 번 더 의심하려 합니다. 이 블로그가 돌아가는 서버도 직접 구축해 운영하고 있어, 투자 이야기와 함께 서버·개발 이야기도 남깁니다.

기사 : 49

댓글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다