본문 바로가기

성공과 실패를 결정하는 1% 네트워크 원리

[성공과 실패를 결정하는 1% 네트워크 원리] 방화벽의 원리와 동작 - 패킷 필터링형, TCP 컨트롤 비트

 

1) 패킷 필터링형이 주류이다

- 서버의 설치 장소와 관계 없이 지금은 바로 앞에 방화벽이 있는 것이 보통입니다.

  그래서 패킷이 방화벽을 통과하는 곳부터 서버측의 탐험 여행을 시작하기로 합니다.

  

- 방화벽의 기본이 되는 개념은 앞에서 설명했듯이 특정 서버와 해당 서버 안의

  특정 애플리케이션에 액세스하는 패킷만 통과시키고, 그 외의 패킷을 차단합니다.

  그러나 특정 서버나 특정 애플리케이션의 패킷만 통과시킨다고 간단히 말했지만,

  네트워크에는 다양한 종류의 패킷이 많이 흐릅니다. 

 

- 그러므로 이 중에서 통과시킬 패킷과 차단할 패킷을 선별하는 것은 간단한 일이 아니기 때문에

  지금까지 다양한 방법이 고안되었습니다. 

  어느 방법으로도 방화벽의 목적을 수행할 수 있지만, 성능, 가격, 사용 편의성 등의 이유로

  지금은 패킷 필터링형이 가장 많이 보급되었습니다. 

 

2) 패킷 필터링의 조건 설정 개념

 

- 패킷의 헤더에는 통신 동작을 제어하는 제어 정보가 들어 있으므로

  이것을 조사하면 여러 가지 사항을 알 수 있습니다.

  그 중에서도 표[5-1]에 정리한 항목은 패킷 필터링의 조건 설정에서 자주 사용하는 것입니다.

  하지만 이 표의 설명만으로는 차단 조건을 이해하기 어려우므로 구체적인 예를 들어 설명하겠습니다. 

 

 

 

- 그림 [5-2]와 같이 공개용 서버를 설치하는 LAN과 사내 LAN이 분리되어 있고,

  웹 서버는 공개 서버용 LAN에 접속되어 있다고 가정합니다.

  그리고 인터넷에서 웹 서버에 대한 액세스를 허가하지 않으면, 

  웹 서버에서 인터넷의 액세스를 금지하도록 패킷을 차단합니다. 

 

 

 

- 이전에는 웹 서버에서 인터넷측에 대한 액세스를 금지하는 예가 적었습니다.

  하지만 지금은 서버에 기생하며 여기에서 다른 서버에 감염되어 가는 부정 소프트웨어가 있으므로

  감염을 막기 위해 웹 서버에서 인터넷측에 액세스하는 것을 금지하고 있습니다.

  이러한 상황에서 패킷 필터링의 조건을 어떻게 설정할까요?

  이것을 예로 하여 패킷 필터링의 개념을 설명하겠습니다. 

 

- 패킷 필터링의 조건을 설정할 때는 먼저 패킷의 흐름에 착안합니다.

  그리고 수신처 IP 주소와 송신처 IP 주소에 따라 시점과 종점을 판단합니다.

  [그림 5-2]의 1)의 예라면 인터넷에서 웹 서버를 향해 패킷이 흐릅니다.

  인터넷에서 보내오는 패킷은 시점을 지정할 수 없지만, 흐름의 종점은 웹 서버가 되므로

  이것을 조건으로 설정하고, 조건에 해당하는 패킷만 통과시킵니다.

 

- 즉, 시점(송신처 IP 주소)은 어디라도 상관없으므로 종점(수신처 IP 주소)이 웹 서버의 IP 주소에

  일치하는 패킷은 통과시킨다는 조건을 설정하면 됩니다. 

  송신처 IP 주소에 따라 시점을 지정할 수 있으면 이것도 조건에 추가합니다.

  이 예와 같이 시점을 지정할 수 없는 경우에는 송신처 IP 주소를 조건으로 지정하지 않아도 상관없습니다. 

 

- 이렇게 해서 인터넷측에서 웹 서버로 흘러가는 패킷은 방화벽을 통과하지만,

  이것만으로는 액세스 동작이 제대로 작동하지 않습니다. 

  패킷을 받으면 정확하게 도착했는지를 송신측에 알리는 수신 확인 응답의 구조가 작용하므로,

  웹 서버에서 인터넷측으로 흐르는 패킷도 있기 때문입니다.

 

- 웹 서버에서 클라이언트에 보내는 데이터가 있고, 이 패킷도 웹 서버에서 인터넷측으로 흘러간 후 

  그곳에서 시점(송신처 IP 주소)이 웹 서버의 주소에 일치하는 패킷도 통과합니다. 

  이와 같이 수신처나 송신처의 주소에 따라 패킷이 어디서, 어디로 흘러가는지를 판단하여 통과시킬 것인지,

  차단할 것인지 결정하는 것이 첫걸음입니다. 

 

3) 애플리케이션을 한정할 때 포트 번호를 사용한다

- 이것뿐이라면 인터넷과 웹 서버 사이를 흐르는 패킷은 전부 통과해서 위험한 상태가 됩니다.

  예를 들어, 서버 머신에서 파일 서버 기능이 유효하므로 네트워크를 경유하여 파일에 부정으로 

  액세스할 경우 정보가 누설될지도 모릅니다.

  위험성이 있는 것은 파일 서버만이 아닙니다.

  매일같이, 해가 거듭할수록 보안 구멍이 발견되는 상황이므로, 어디에 어떤 위험성이 잠재하는지 모릅니다. 

  그러므로 불필요한 것, 이 예에서는 웹 이외의 애플리케이션의 패킷을 전부 차단하는 쪽이 좋습니다. 

 

- 이와 같이 애플리케이션을 한정할 때는 TCP헤더나 UDP 헤더에 기록되어 있는 포트 번호를 조건으로 추가합니다.

  웹 서버의 포트 번호는 80번으로 결정되어 있으므로 전술한 수신처 IP 주소 및 송신처 IP 주소에 수신처 포트 번호가

  80번인 경우에 대한 조건도 추가합니다. 

 

- 즉, 수신처 IP 주소가 웹 서버의 주소와 일치하고, 수신처 포트 번호가 80번인 패킷은 통과합니다.

  또한 송신처 IP 주소가 웹 서버의 주소와 일치하고 송신처 포트 번호가 80번인 패킷도 통과하도록 설정합니다.

  그리고 웹 서버 이외의 애플리케이션에 대한 액세스를 허가할 경우에는 이 애플리케이션의 포트 번호를 설정하여

  이것이 통과되도록 합니다. 

 

 

4) 컨트롤 비트로 접속 방향을 판단한다

-이렇게 해서 애플리케이션도 지정했지만, 아직 조건이 부족합니다.

 웹 서버에서 인터넷측에 액세스하는 동작을 정지시킬 수 없기 때문입니다.

 웹의 동작은 TCP 프로토콜을 사용하여 정지시켜야 하는데, 

 여기에서 도움이 되는 것이 TCP 헤더에 있는 컨트롤 비트입니다.

 

- TCP는 최초에 행하는 접속 단계의 동작에서 3개의 패킷이 흐르는데,

  최초의 패킷만 TCP 컨트롤 비트의 SYN이라는 비트가 1로 되고, ACK라는 비트가 0이 됩니다.

  다른 패킷에서 같은 값을 취하는 경우는 없으므로, 이 값을 조사해서 최초의 패킷과 두 번째 이후의 패킷을

  판별할 수 있습니다. 

 

- 최초의 패킷이 웹 서버 측에서 인터넷측으로 흘러갈 경우, 이것을 차단하도록 설정하면 어떻게 될까요?

  이것을 차단하면 상대로부터 두 번째 패킷이 돌아오는 경우가 없으므로, 

  당연히 TCP의 접속 동작은 실패로 끝납니다.

 

- 즉, 웹 서버가 기점이 되어 인터넷에 액세스하려고 해도 접속 동작이 틀림 없이 실패한다는 것입니다.

  이렇게 해서 웹 서버에서 인터넷에 액세스하는 동작을 정지시킬 수 있습니다. 

 

- 인터넷측에서 웹 서버에 액세스하는 패킷은 어떻게 될까요? 

  인터넷측에서 웹 서버에 액세스할 때 최초의 패킷은 수신처가 웹 서버를 나타내고,

  [그림 5-2]의 표에서 첫 번째 행의 조건에 해당하므로 패킷 필터링을 통과합니다. 

  두 번째 패킷은 송신처가 웹 서버를 나타내지만, TCP 컨트롤 비트의 조건이 두 번째 행과 합치되지 않으므로

  세 번째 행의 조건에 합치되어 패킷 필터링을 통과합니다. 

  그 후의 패킷도 첫 번째 행이나 세 번째 행 중 어느 하나에 합치됩니다.

  결국 인터넷측에서 웹 서버에 액세스할 때 흐르는 패킷은 전부 패킷 필터링을 통과합니다.

 

- 수신처 IP 주소, 송신처 IP 주소, 수신처 포트 번호, 송신처 포트 번호, TCP 컨트롤 비트를 조건으로 사용하고,

  통신의 시점과 종점, 애플리케이션의 종류, 액세스 방향을 판별하는 방법을 설명했는데,

  조건으로 사용하는 항목은 [표5-1]과 같이 많습니다.

 

- 이것을 조합하면 대상이 되는 패킷을 찾아낼 수 있습니다.

  이렇게 해서 허가하는 액세스 동작에서 흐르는 패킷과 그 외의 패킷을 완전히 선별할 수 있을 때까지

  조건을 추가합니다.

  그리고 액세스를 허가하는 패킷만 통과시키고, 그 외는 차단하도록 조건을 설정합니다. 

 

- 실제로는 통과시키는 것과 차단하는 것을 완전히 선별할 수 없는 경우도 있는데,

   DNS 서버에 대한 액세스가 대표적인 예입니다.

   DNS 서버에 조회하는 동작은 UDP를 사용하는데, UDP는 TCP와 달리 접속 단계의 동작이 없으므로,

   TCP처럼 컨트롤 비트에 의해 액세스 방향을 판별할 수 없습니다. 

 

- 그러므로 사내에서 인터넷의 DNS 서버에 액세스하는 것을 허가하고,

   인터넷에서 사내의 DNS 서버에 액세스하는 패킷은 차단한다는 조건을 설정할 수 없습니다. 

   이 성질은 DNS뿐만 아니라 UDP를 사용하는 애플리케이션에 공통입니다. 

   이와 같은 경우에는 어느 정도 위험을 각오한 상태에서 애플리케이션의 패킷을 전부 통과시키거나,

   불편을 감수하고 애플리케이션을 전면적으로 차단하는 방법을 선택해야 합니다.