“문은 열려 있어도, 모든 접근을 허용할 필요는 없잖아요.” 어떤 패킷을 허용할지는 기준이 필요해요.포트 포워딩과 들어오는 연결에서 우리는 바깥 세상에서 우리 집 안으로 들어올 수 있는 ‘통로’를 만드는 법을 배웠어요. 마치 아파트 정문에 “피자 배달 오면 101호로 보내주세요”라고 적어두는 것과 같았죠. 하지만 여기서 한 가지 걱정이 생겨요. 규칙 없이 아무 접근이나 받아들이면, 우리가 의도하지 않은 연결까지 들어올 수 있겠죠. 오늘은 단순히 문을 열고 닫는 수준을 넘어, 미리 정한 규칙과 현재 연결 상태를 기준으로 어떤 패킷을 허용하고 막을지 결정하는 방화벽(Firewall) 이야기를 해볼게요. 즉, 지난 글이 “바깥에서 안으로 들어오는 길을 어떻게 만들까?” 에 가까웠다면, 이번 글은 그다음 단계인 “그 길로 들어오려는 패킷을 어떤 기준으로 들이고 막을까?” 를 보는 편이에요.
방화벽은 문을 여는 규칙만으로 끝나지 않아요
이번에도 아파트 단지 이야기를 가져와 볼까요? 포트 포워딩이 ‘배달 장부’였다면, 방화벽은 정문에서 출입 규칙과 기록을 확인하는 담당자예요.- 포트 포워딩: “피자 배달은 101호로 연결해!” (길 안내)
- 방화벽: “이 접근은 규칙에 맞나? 이미 허용된 흐름의 응답인가?” (정책과 상태 확인)
- 안에서 밖으로 나갈 때: 101호 거주자가 정문을 나가면서 “저 피자 주문하러 가요!”라고 말해요. 요원은 장부에 **
101호 - 피자집 - 대화 중**이라고 적어둡니다. - 밖에서 안으로 올 때: 피자 배달원이 옵니다. 요원은 장부를 봐요. “아하, 아까 101호 사람이 피자 시키러 나갔었지? 들어오세요.”
- 불쑥 찾아올 때: 갑자기 모르는 사람이 “피자 왔어요!”라고 해요. 요원이 장부와 규칙을 보니 맞는 흐름이 없네요. “허용된 접근이 아니니 막자.”
NAT는 방화벽이 아니에요
여기서 많은 분이 헷갈려하는 포인트가 있어요.“공유기(NAT)가 있으니까 바깥에서 안으로 못 들어오잖아요? 그럼 NAT가 방화벽 아닌가요?”사실은 조금 달라요. 공인 IP, 사설 IP, 그리고 NAT에서 본 것처럼 NAT의 본업은 **‘주소를 바꿔주는 것’**이지 ‘보안’이 아니에요.
- NAT: “주소가 사설 IP네? 공인 IP로 바꿔서 보내줄게.” (통역사)
- 방화벽: “이 패킷은 정책과 연결 상태에 맞나? 허용 또는 차단하자.” (정책 판단)
Stateless filtering vs Stateful filtering
방화벽이 패킷을 검사하는 방식은 크게 두 가지로 나뉘어요.1. 이전 상태를 기억하지 않는 Stateless filtering
이 방식은 패킷 하나하나를 독립적으로 봐요. 출발지/목적지 IP, 프로토콜, 포트, TCP flags 같은 조건을 규칙과 비교할 수 있지만, 앞선 패킷과의 연결 관계를 스스로 기억하지 않아요. Stateless 필터는 각 패킷을 독립적으로 보기 때문에, 양방향 통신을 허용하려면 필요한 방향과 조건을 규칙에 직접 표현해야 해요.2. 연결 상태를 기억하는 Stateful filtering
요즘 쓰는 대부분의 방화벽(공유기 포함)은 이 방식을 써요. 안에서 밖으로 나간 요청을 기억했다가, 이미 허용된 흐름의 상태와 일치하는 반환 트래픽을 자동으로 인식할 수 있어요. 이 방식 덕분에 우리는 복잡한 설정 없이도 필요한 응답을 자연스럽게 받을 수 있는 거예요.왜 포트 포워딩만으로는 부족할까요?
“포트 포워딩으로 문을 열었으면 된 거 아닌가?” 싶겠지만, 문을 연다는 건 그만큼 위험이 늘어난다는 뜻이에요. 만약 우리가 게임 서버를 위해25565 포트를 열었다면, 이제 전 세계 누구나 우리 집 25565 문 앞까지 올 수 있어요.
이때 방화벽은 다음과 같은 추가적인 일을 해줘요.
- 특정 주소만 허용: “친구네 집 IP인
211.x.x.x에서 오는 연결만25565로 들여보내 줘.” - 규칙에 안 맞는 접근 차단: “이 포트는 게임 서버용인데, 허용한 조건이 아니네? 이건 통과시키지 말자.”
- 추가 기능 활용: 일부 방화벽은 rate limiting이나 애플리케이션 계층 검사 같은 기능도 제공해요.
근데 왜 상태 기반 필터링이 꼭 필요할까요?
여기서 이런 생각이 들 수 있어요.“그냥 허용할 포트만 적어두면 끝 아닌가요? 굳이 상태까지 기억해야 해요?”문제는 네트워크 대화가 생각보다 훨씬 더 자주 왕복한다는 거예요. 우리가 웹사이트 하나만 열어도, 브라우저는 밖으로 요청을 보내고 서버는 그에 대한 답장을 다시 보내죠. 이때 상태를 기억하지 못하면 두 가지 중 하나가 벌어져요.
- 답장까지 같이 막아버리기 — 그러면 웹페이지가 제대로 안 열려요.
- 답장을 받으려고 문을 너무 넓게 열어두기 — 그러면 원치 않는 패킷까지 들어오기 쉬워져요.
그럼 진짜 공유기에서는 어떻게 보일까요?
이제 집에서 흔히 만나는 설정 장면으로 바꿔볼게요. 이 그림 안에는 사실 세 가지 상황이 같이 들어 있어요.1. 내가 먼저 웹사이트에 접속했을 때
노트북이 먼저 요청을 보냈으니, 공유기는 “이건 진행 중인 대화” 라고 상태를 기록해요. 그래서 서버 답장이 돌아오면 자연스럽게 통과시켜 주죠.2. 바깥에서 아무 예고 없이 들이밀 때
상태 테이블에도 없고, 허용 규칙에도 맞지 않으면 공유기는 일단 막아요. 이게 우리가 평소에 별다른 설정 없이도 불필요한 inbound 접근을 줄일 수 있는 큰 이유예요.3. 포트 포워딩으로 일부러 문을 열어둔 서비스가 있을 때
예를 들어 게임 서버나 NAS처럼 바깥에서 들어오게 허용한 서비스가 있다면, 공유기는 “어느 기기로 보낼지” 를 포트 포워딩 규칙으로 보고, “정말 들여보낼지” 는 방화벽 규칙과 상태를 함께 보고 판단해요. 그러니까 여기서도 핵심은 같아요. 길 안내는 포트 포워딩이 하고, 최종 판단은 방화벽이 한다는 점이죠.공유기에서 한 번 걸러도, 실제로 패킷을 받는 컴퓨터나 NAS 안에서 한 번 더 막을 수 있어요.
그래서 접속이 안 될 때는 공유기 규칙만 볼 게 아니라, 그 기기 자체의 방화벽도 같이 봐야 할 때가 많아요.
잠깐! ‘상태’를 기억한다는 건 메모리를 쓴다는 뜻이에요
방화벽이 모든 연결의 ‘상태’를 기억하려면 공유기의 메모리(RAM)를 사용해요. 수천 명의 사람과 동시에 대화 기록을 남기려면 장부가 두꺼워져야 하는 것과 같죠.- 가끔 공유기가 먹통이 될 때, “연결이 너무 많아서 상태 테이블이 꽉 찼다”는 표현을 쓰기도 해요.
- 토렌트처럼 동시에 수많은 곳과 연결을 맺는 프로그램을 쓰면 이 장부가 금방 차버릴 수 있거든요.
- 그래서 고성능 방화벽이나 공유기일수록 이 ‘상태’를 더 많이, 더 빠르게 처리할 수 있는 능력이 중요해진답니다.
자, 정리해볼까요?
- 방화벽은 들어오고 나가는 패킷을 정책과 연결 상태 기준으로 허용하거나 차단해요.
- NAT는 주소를 바꿔주는 통역사일 뿐, 그 자체가 보안 도구는 아니에요.
- 상태 기반 필터링(Stateful)은 안에서 나간 요청을 기억했다가 허용된 흐름과 일치하는 반환 트래픽을 인식하는 방식이에요.
- 포트 포워딩으로 문을 열었다면, 방화벽 규칙을 통해 허용할 주소와 조건을 더 꼼꼼히 정하는 게 좋아요.
- 모든 연결을 기억하는 데는 비용(메모리)이 들고, 이게 꽉 차면 네트워크가 느려질 수 있어요.
다음 글 예고
같은192.168.0.x처럼 보여도, 정말 같은 동네라고 말할 수 있을까요?
“내 노트북은 이 목적지가 같은 집 안인지, 아니면 공유기에게 맡겨야 하는지 어떻게 판단할까요?”다음 글에서는 서브넷 마스크와 CIDR, 같은 동네인지 어떻게 판단할까요? 이야기를 통해, IP 주소 뒤에 숨어 있는 네트워크 경계선을 같이 열어볼게요.