[성공과 실패를 결정하는 1% 네트워크 원리] 방화벽의 원리와 동작 - 사내 LAN, 방화벽 통과, 방화벽으로 막을 수 없는 공격

1편)

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

 

 

5) 사내 LAN에서 공개 서버용 LAN으로 조건을 설정한다

 

- [그림 5-2]와 같은 구성의 경우 인터넷과 공개 서버용 LAN을 왕래하는 패킷의 조건을 설정할 뿐만 아니라

  사내 LAN과 인터넷 또는 사내 LAN과 공개 서버용 LAN을 왕래하는 패킷의 조건도 설정해야 합니다.

  이 때, 조건이 서로 악영향을 끼치지 않도록 주의해야 합니다.

 

- 예를 들어, 사내 LAN과 공개 서버용 LAN 사이를 자유로이 왕래할 수 있도록 

  수신처 IP 주소가 공개 서버용 LAN과 일치하는 패킷을 전부 통과시켰다고 가정해 봅시다.

  그런 다음 깜빡 잊고 송신처 IP 주소를 조건으로 설정하지 않으면 

  인터넷측에서 흘러온 패킷이 무조건 공개 서버용 LAN에 유입됩니다.

  이렇게 되면 공개 서버용 LAN에 설치한 서버 전부가 위험한 상태에 빠지므로

  이런 사태가 되지 않도록 신중하게 조건을 설정해야 합니다. 

 

 

6) 밖에서 사내 LAN으로 액세스할 수 없다

- 패킷 필터링형 방화벽은 패킷을 통과시킬지, 차단시킬지를 판단할 뿐만 아니라 

  주소 변환의 기능도 가지고 있으므로 설정도 필요합니다.

  즉, 인터넷과 사내 LAN을 왕래하는 패킷은 주소 변환을 해야 하므로 설정이 필요합니다.

 

- 구체적으로는 패킷 필터링과 마찬가지로 패킷의 시점과 종점을 조건으로 지정한 후 

  주소 변환이 필요한 경우에는 주소 변환을 하고, 

  변환이 필요하지 않은 경우에는 변환하지 않도록 설정합니다.

 

- 프라이빗 주소와 글로벌 주소의 대응이나 포트 번호의 대응은 자동으로 할 수 있으므로

  주소 변환을 해야 할지 설정합니다. 

  주소 변환의 구조를 생각했지만, 주소 변환을 이용하면 당연히 인터넷측에서

  사내 LAN에는 액세스할 수 없게 됩니다. 

  따라서 사내 LAN에 대한 액세스를 금지하도록 패킷 필터링의 조건을 설정할 필요가 없습니다. 

 

 

7) 방화벽을 통과한다

- 방화벽에는 여러 가지 조건이 설정되어 있습니다.

  여기에 패킷이 도착하면 조건에 해당하는지 판정하고,

  통과시킬지와 차단할지를 결정합니다.

  이렇게 판정한 후 차단하는 대상이 되면 패킷을 버리고, 버린 기록을 남깁니다. 

 

- 버린 패킷 중에는 부정 침입의 흔적을 나타낸 것이 있으므로,

  이것을 분석하여 침입자의 수법을 밝히거나 향후 부정 침입 대책에 도움이 될 수 있기 때문입니다. 

 

- 통과시킨다는 판정을 내린 경우에는 패킷을 중계하는데,

  이 중계 동작은 라우터의 동작과 같습니다. 

  패킷을 통과시킬지, 차단할지를 판단하는 것에 착안하면 방화벽은 특별한 구조를 가지고 있다는 느낌이 듭니다.

  방화벽 전용 하드웨어나 소프트웨어가 시판되고 있다는 점도 특별하다는 인상이 강합니다. 

 

- 일단 통과시킨다고 결정되면 그 이상의 특별한 구조는 없습니다.

  그러므로 '패킷 필터링'이라는 구조는 방화벽용의 특별한 구조라고 생각할 것이 아니라

  라우터의 패킷 중계 기능 중에서 부가 기능이라고 생각하는 것이 좋습니다. 

 

- 단, 판정 조건이 복잡해지면 라우터의 명령으로 설정하기가 어려워지고,

  패킷을 버린 기록을 남기는 것도 라우터에 크게 부담스러운 큰 작업이기 때문에

  전용 하드웨어나 소프트웨어를 사용하는 것입니다.

  복잡한 조건 설정이나 버린 패킷의 기록이 필요하지 않으면

  패킷 필터링 기능을 가진 라우터를 방화벽으로 사용할 수도 있습니다. 

 

 

8) 방화벽으로 막을 수 없는 공격

- 방화벽은 패킷 흐름의 시점과 종점을 보고 통과시킬지, 차단할지 판단하는데,

  시점과 종점만 보고 위험한 패킷을 전부 판단할 수 있는 것은 아닙니다. 

  예를 들어, 웹 서버에 좋지 않은 상태가 있어서 특수한 데이터를 포함한 패킷을 받으면

  웹 서버가 다운된다는 상황을 생각해 보겠습니다. 

 

- 방화벽은 시점과 종점만 조사하므로 패킷 중에 특수한 데이터가 포함되어 있어도

  이것에 신경쓰지 않고 패킷을 통과시켜 버립니다.

  그러면 이 패킷이 웹 서버에 도착하여 웹 서버는 다운됩니다. 

  이 예에서 알 수 있듯이 패킷의 내용을 조사하지 않으면 위험한지 판단할 수 없어서 

  방화벽의 구조는 이러한 상황에 대처할 수 없게 됩니다. 

 

- 이러한 상황에 대해 두 가지의 대처법이 있습니다.

  이 문제의 원인은 웹 서버 소프트웨어의 버그에 있으므로

  버그를 고쳐서 다운되지 않도록 하는 것이 한 가지 대처법입니다.

  이런 종류의 버그 중에서 위험성이 높은 것은 정보가 보안 구멍으로 널리 공개되어

  버그를 수정하지 않은 새 버전이 배포되는 경우입니다. 

  이 때, 보안 구멍 정보를 수집하여 항상 새로운 버전으로 갱신하는 것이 중요합니다 .

 

- 또 한 가지 방법은 패킷의 내용을 조사하여 위험한 데이터가 포함되어 있는 경우에

  패킷을 차단하도록 장치나 소프트웨어를 방화벽과는 별도로 준비하는 방법입니다.

  이 방법은 패킷의 내용까지 조사하므로 완벽하다고 단순하게 생각하면 안됩니다. 

  패킷의 내용이 위험한지는 웹 서버에 버그가 있는지의 여부로 결정됩니다. 

 

- 그러므로 잠재적인 버그가 숨어있는데도 아직 버그가 발견되지 않은 경우에는

  패킷이 위험하다고 판단할 수 없기 때문에 패킷을 차단할 수 없습니다. 

  결국 미지의 위험성에는 대처할 수 없는 것입니다. 

 

- 이 점은 발견된 버그를 고치는 방법과 크게 다르지 않습니다.

  단, 여러 대의 서버가 있는 경우에는 새로운 버전으로 바꾸기를 미루거나

  잊어버리기 쉬우므로 패킷의 내용을 검사하는 방법은 효과가 있습니다.