[Network] 방화벽의 패킷 필터링 과정 알아보기

🌱 들어가기 전

지난 포스팅까지는 클라이언트 측 LAN에서 라우터까지 어떻게 패킷이 흘렀는지 알아보았었다.

그 이후로도 전기 신호로 변환되고, 패킷이 중계되고, 통신 회선이나 프로바이더의 네트워크를 통해 서버 측으로 어떻게 이동하는지 그러한 과정이 있지만 내용이 너무 깊은 것 같아서 생략했다.

이번 포스팅에서는 웹 서버에서 어떤 식으로 요청이 처리되는지 알아보고자 한다.

 

---

 

🌱 웹 서버는 어디에 설치될까요?

과거에는 사내의 LAN에 서버를 설치한 다음, 인터넷에서 직접적으로 액세스했다.

이러면 패킷은 액세스 회선, 서버측 라우터를 경유해서 서버 머신에 도착하여 패킷이 흐르게 된다.

하지만, 이 방법은 서버와 클라이언트 모두에 글로벌 주소를 할당해야 돼서 IP 주소가 부족해진다.

또한, 서버가 직접적으로 노출되기 때문에 보안적으로도 좋지 않다.

그래서 요즘은 방화벽을 통해서 특정 서버에서 동작하는 특정 애플리케이션에 접근하는 패킷만 통과하고, 나머지 패킷은 차단시켜서 보안적 측면을 보완하였다. 

 

혹은, 회사 내에 설치하지 않고 프로바이더가 운영하는 데이터센터 시설에 서버를 가지고 들어가서 설치하거나, 프로바이더가 소유하고 있는 서버를 빌려쓰는 형태로 운영하는 경우도 있다. 

💬 여기서 프로바이더는, 서비스를 제공하는 인터넷 통신사를 의미한다.

 

데이터센터는 대부분 프로바이더 중심 부분 쪽과 직결되어 있어 서버 설치 시 고속으로 액세스 가능하다는 장점이 있다. 설치 장소도 단순 회사보다 안전한 건물 내에 설치하는 경우가 많기 때문에 안전성이 높다.

아무튼 이 경우에는 인터넷 중심 부분에서 데이터 센터로 패킷이 흘러가고, 서버 머신에 도착하기 때문에 데이터 센터 쪽에 방화벽이 설치되어 있다면 1차적으로 걸러진 패킷에 대해서 패킷이 받게 된다.

 

두 경우 모두 라우터에서 중계되고, 최종적으로 서버에 도착한다는 것은 동일하다.

 

---

 

🌱 방화벽의 원리와 동작 과정

💬 패킷 필터링

방화벽은 기본적으로 특정 서버와 해당 서버 내부의 특정 애플리케이션에 액세스하는 패킷만 통과시키고, 나머지는 차단시킨다.

여기서 어떤 기준으로 패킷을 통과시키고 거르는지는 다양한 방법이 있지만 (패킷 필터링, 애플리케이션 게이트웨이, 서킷 게이트웨이 등) 여기서는 패킷 필터링에 대해서 중점적으로 다루어보자.

 

궁금해서 간단하게 애플리케이션 게이트웨이와 서킷 게이트웨이에 대해서 찾아보았다.

- 애플리케이션 게이트웨이
OSI 7계층의 응용 레이어에서 동작하는 게이트웨이이다.
방화벽의 프록시를 이용하여 사용할 수 있으며, 서비스마다 다른 프록시 서버를 통해서 연결하는 방법이다.
패킷 필털이 방식보다 비교적 높은 보안성을 가지고 있지만, 하드웨어에 의존적이고 응용 계층에서 동작하다 보니 네트워크에 부하가 많이 든다.

- 서킷 게이트웨이
OSI 7계층에서 세션 레이어, 응용 레이어에서 사이에서 동작하는 게이트웨이이다.
서비스마다 프록시 서버가 있는 것이 아닌, 하나의 프록시를 통해 모든 서비스를 처리할 수 있도록 만들었다.

 

패킷 필터링의 조건에서는 아래와 같은 설정 정보들을 자주 사용한다.

 

헤더의 종류	조건 설정에 사용하는 항목	설명
MAC 헤더	송신처 MAC 주소	라우터는 패킷 중계 시 MAC 주소를 바꿔쓴다. - 중계 대상 라우터의 MAC 주소는 수신처 MAC 주소 항목에, 자신의 MAC 주소는 송신처 MAC 주소 항목에 기록한다. - 이때, 송신처 MAC 주소를 통해서 직전에 중계한 라우터의 MAC 주소를 알 수 있게 된다.
IP 헤더	송신처 IP 주소	패킷을 최초로 송신한 기기의 IP 주소. 패킷을 송신한 기기를 조건으로 설정하는 경우에 사용한다.
	수신처 IP 주소	패킷을 건네줄 대상의 IP 주소. 패킷이 갈 목적지를 조건으로 설정하는 경우에 사용한다.
	프로토콜 번호	주요 프로토콜 번호는 다음과 같다. - IP:0, ICMP:1, TCP:6, UDP:17, OSPF:89
TCP 헤더 or UDP 헤더	송신처 포트 번호	패킷을 송신한 프로그램에 할당된 포트번호. - 서버 프로그램에 할당된 포트 번호는 고정되기 때문에 서버 측에서 반송된 패킷에 적힌 포트 번호를 통해서 서버에 대한 판별이 가능하다. - 클라이언트 프로그램의 포트 번호는 랜덤으로 할당되기 때문에 판단하기 어렵다.
	수신처 포트 번호	패킷을 건네줄 대상의 프로그램에 할당된 포트 번호. - 마찬가지로 서버의 포트 번호는 조건 설정으로 많이 하는데, 클라이언트 포트 번호는 거의 하지 않는다.
	TCP 컨트롤 비트	TCP 프로토콜 제어 시 사용하는 정보이다. ACK: 유효함 (정확하게 도착) PSH: 송신 버퍼테 저장 없이 바로 송신 RST: 접속을 강제로 종료 SYN: 통신 개시 시 접속 동작에서 최초로 보낸 패킷의 SYN=1, ACK = 0 이때 이 패킷을 필터링 하면 그 뒤의 동작을 차단할 수 있다. FIN: 연결 끊음
	프레그먼트	IP 프로토콜의 조각 나누기 기능으로 패킷을 분할하고, 이 패킷이 두 번째 이후임을 나타낸다.
ICMP 메시지	ICMP 메시지 유형	ICMP 메시지는 패킷 배송 도중에 이상이 있거나, 통신 상대의 동작을 확인할 때 사용한다. 0: ping 명령으로 보내는 ICMP 에코 메시지에 응답하는 것. - 0과 8을 차단하면 ping 명령의 응답은 돌아오지 않는다. (어떤 기기가 네트워크에 존재하는지 ping 명령어로 찾을 때가 많은데 그런 걸 차단해버리는 거임) 8: ping 명령을 실행하면 ICMP 에코 메시지가 송싱되는데, 이를 ICMP 에코라고 한다.

 

공개용 서버를 설치한 LAN과 사내 LAN이 분리되어 있고, 웹 서버는 공개 서버용 LAN에 접속되어 있다고 생각해보자.

 

패킷 필터링 조건 설정 시 먼저, 송/수신처 IP 주소에 따라서 시작점과 종점을 판단한다.

인터넷에서 웹 서버로 패킷이 들어오다면 종점인 수신처 IP 주소가 실제 웹 서버의 IP 주소와 일치하는지 판단하여 패킷을 통과시키게 된다.

그리고 이러한 조건들을 위와 같이 작성해두어서 필터링을 진행하는 것이다.

첫 번째 행을 보자. 송신처 IP, 포트 번호는 어떤 것이든 상관없지만 수신처 IP / 포트번호가 일치해야 해당 요청이 들어오게 된다.

- 여기서 포트 번호까지 보는 것은 애플리케이션까지 한정시키려고 하는 것이다. 여기서는 웹 서버에서 흔히 사용하는 80번으로 고정시킨 사례를 보는 것이다.

 

하지만, 단순히 수신처로 패킷이 필터링되어 들어가는 것뿐만 아니라 수신처가 패킷을 잘 받았는지 다시 송신처에게 알려야 한다.

이 경우 반대로 수신처의 IP, 포트 번호는 상관 없이 송신처의 IP / 포트번호가 패킷을 보냈던 곳인지 판단해야 한다.

 

 

💬 IP / 포트 번호만으로는 부족해!

사실 IP와 포트 번호를 통해서 어떤 웹 서버의 애플리케이션으로 패킷이 들어오게 할지는 정했다.

하지만, 웹 서버 측에서 인터넷 쪽으로 액세스하는 동작은 어떻게 컨트롤할 수 있을까?

단순히 웹 서버에서 인터넷으로 흐르는 패킷을 정지시키면 양방향 통신인 TCP 프로토콜에 의해 인터넷에서 웹 서버 측으로 흐르게 하는 것도 정지하게 된다.

 

이를 위해 TCP 헤더의 컨트롤 비트를 사용한다. 

앞서 말한 것처럼 최초의 패킷만 SYN=1, ACK=0으로 설정되는데, 인터넷 -> 웹 서버로 보내는 이 값을 차단했다고 생각해보자.

그러면 최초의 패킷에 대해서 응답하는 경우가 없기 때문에 웹 서버 -> 인터넷 측으로 패킷이 흐르지 않게 된다.

그래서 인터넷에 액세스를 하려고 해도 접속 동작이 무조건 실패하게 된다.

 

반대로 인터넷 -> 웹 서버로 패킷이 흐를 때 최초의 패킷의 수신처는 '웹 서버'가 될 것이다.
그러면 표의 첫 번째 행이 일치해서 통과할 것이다.
이후, 두 번째 패킷은 송신처가 웹 서버가 될 것이지만, 최초의 패킷이 아니기 때문에 컨트롤 비트가 SYN=1, ACK=0이 아닐 것이다.

그래서 두 번째 행의 조건에 일치하지 않게 되면서 세 번째 조건으로 가게 되고, 패킷이 통과하게 될 것이다.

이런 식으로 이후에 인터넷 -> 웹 서버로 흐르는 패킷들은 모두 첫 번째나 세 번째 행을 통과하여 패킷 필터링이 통과하게 된다.

 

 

💬 항상 완전하게 통과시키거나 차단시킬 수 있을까?

TCP가 아닌 UDP에서도 완전하게 위의 구조가 동작할까?

우리는 이전에 DNS 서버를 통해 IP 주소를 얻어오는 행위는 UDP 프로토콜을 사용한다고 배웠었다.

하지만, UDP의 경우 별도의 접속 단계가 없기 때문에 TCP처럼 컨트롤 비트를 통해 액세스 방향을 판별할 수 없다.

그래서 웹 서버 -> 인터넷은 허용하지만 인터넷 -> 웹 서버는 차단하도록 만들 수는 없다.

이때는 어느 정도의 위험성을 가지고 패킷을 전부 통과하거나, 전부 차단하는 방법을 선택해야 한다.

 

 

💬 사내 LAN과 공개 서버 LAN

 

위에서 봤던 그림을 다시 보자.

지금까지는 인터넷 <-> 공개 서버용 LAN 패킷을 고려하였지만, 사실 사내 LAN <-> 인터넷 사이의 패킷 왕래도 고려해야 한다. 

패킷 필터링형 방화벽은 패킷 통과 및 차단뿐만 아니라 주소 변환 기능도 가지고 있기 때문에, 인터넷 <-> 사내 LAN을 왕래하는 패킷 사이의 주소 변환 기능도 필요하다. 

💡보통 인터넷 라우터의 라우팅 테이블에는 프라이빗 주소를 등록하지 않아서 프라이빗 주소로 갈 패킷을 중계하지 않고 버리기 때문에 주소 변환이 필요하다.

하지만, 방화벽에 내장되어 있는 라우터는 사용자가 스스로 설정할 수 있기 때문에 프라이빗 주소를 등록하면 프라이빗 주소 그대로 공개 서버용 LAN과 사내 LAN 사이에서 패킷을 중계할 수 있다. 그래서 별도로 공개 서버용 LAN과 사내 서버용 LAN을 왕래하는 패킷은 주소 변환을 할 필요가 없다!

 

방화벽은 패킷을 통과시키기 전에 출발지 IP 주소와 도착지 IP 주소를 확인하고 필요한 경우 주소 변환을 작업을 진행한다.

이때, 패킷 필터링형 방화벽의 경우 프라이빗 IP 주소와 글로벌 IP 주소 간의 대응을 자동으로 처리할 수 있다.

만약 내부 네트워크에서 출발한 패킷의 프라이빗 IP 주소를 방화벽이 감지하게 되면, 해당 주소를 인터넷에 접속하기 위해 할당된 글로벌 IP 주소로 변환하고 (주소 변환 테이블 참고), 변환된 패킷은 인터넷에 전송된다. 포트 번호 역시 마찬가지로 안 쓰는 포트로 변환하고, 나중에 원래의 포트로 변환하는 그런 작업을 진행한다. (이전 포스팅에서 설명했던 과정과 비슷하다.)

 

결과적으로 방화벽에 패킷이 도착하면, 조건에 해당하는지 판단하고 패킷을 중계한다.

패킷 중계 동작은 라우터와 거의 비슷하기 때문에 패킷이 통과하는지가 가장 중요하다.

(참고로, 패킷을 버리게 되면 버린 기록을 남기게 된다. 침입자 로그 확인용도...? 근데 라우터 자체를 방화벽으로 사용하게 되면 메모리가 적어서 보통 로그를 안 남긴다고 한다)

 

하지만, 방화벽으로 모든 공격을 막는 것은 당연히 안 된다.

방화벽은 단순히 시점과 종점만을 확인하기 때문에 패킷 사이에 특수한 데이터는 알 수가 없다.

그래서 패킷 내용을 조사해서 위험한 데이터가 들어있는지 판단해서 차단하는 장치나 그런 걸 준비하는 것이 중요하다.

🌱 패킷 필터링형 방화벽은 수신처 IP 주소, 송신처 IP 주소, 수신처 포트 번호, 송신처 포트 번호, 컨트롤 비트 등으로 패킷을 통과시킬지 판단한다.