[Network] 네트워크의 3가지 구조(Inline, Out of Path, Proxy)

Inline 구조

• Inline 구조를 갖는 네트워크 장치 예시
  • 라우터
  • 공유기
  • 방화벽
  • IPS(침입 방지 시스템)
• 데이터 단위: L3 계층의 데이터 단위인 패킷(Packet)
• 기능
  • 패킷 필터링
    • 패킷을 차단(drop)하거나 차단하지 않고 전송(bypass) 중 선택 가능
  • 네트워크 인터페이스 필터링
    • 패킷을 bypass 했을 때, 해당 패킷을 어떤 네트워크 인터페이스(ex. 다른 라우터 또는 L2 Dsitribution/Access 스위치 등..)를 목적지로 해서 전송할지를 선택 가능

Out of Path 구조

• 데이터 단위: L3 계층의 데이터 단위인 패킷(Packet)
• 기능
  • 필터링 기능은 없음
  • 읽기 전용(Read-Only) 기능을 수행하여 패킷을 모니터링 및 분석
    • 네트워크 보안 감지
    • 네트워크 장애 감지
    • 네트워크 패킷 분석

L2 Port Mirroring

네트워크 장애나 보안을 감지하는 센서 기능을 수행하기 위해서는 네트워크에서 흐르는 패킷 데이터를 따로 수집해야 하며, 이를 위한 물리적인 장치가 필요하다. 이 때, 패킷 데이터를 따로 수집하기 위해 수행하는 것을 L2 Port Mirroring이라고 한다.

• 방법
  1. L2 스위치(Access/Distribution)의 특정 포트(인터페이스 단자)에 센서를 연결
  2. 해당 포트로 흐르는 L2 프레임을 센서 장치로 복사(미러링)하여 수집

L2 스위치의 ‘포트’는 애플리케이션 계층에서 프로세스의 식별자인 포트 번호와는 그 의미가 다르다. 계층에 따라 포트라는 용어가 의미하는 바가 다르다.

• 제약
  • 미러링 작업은 부하가 크므로 고성능 하드웨어 필요.
  • 이를 위해 사용하는 전용 장치를 Tap이라고 부름.

유해사이트 차단 예시

• 내 PC에서 outbound되는 패킷을 ISP에서 모니터링하고 있다.
• 해당 패킷의 내용을 확인하고 유해사이트에 대한 요청일 경우, 이를 차단한다.
  • 이때, payload까지 확인하는 행위를 DPI라고 하는데, 이는 법적으로 금지되어 있다. 한국에서는 SPI라고 HTTP 헤더 수준까지만 확인 가능하다.
  • 정확히는 차단이 아니라, ISP 수준의 센서에서 모든 요청 트래픽을 수집하고 이를 확인하여 유해사이트인 경우 본인이 해당 사이트인 것처럼 거짓 응답을 한다. 이는, ISP 수준의 센서가 해당 사이트보다 더 빠르게 응답할 수 있기에 가능하다.

(Application) Proxy 구조

• 데이터 단위: 소켓 스트림
  • 소켓 스트림: 유저 모드의 애플리케이션에서 다루는 데이터
• 특징
  • Inline & Out of path 구조에서는 다루는 데이터 단위가 패킷이기 때문에 사람의 눈으로 확인하기 위해서는 이 패킷들을 조립하는 복잡한 구조를 거쳐야 했음
  • 프록시 구조에서는 이미 조립된 상태인 소켓 스트림을 다룸 -> 네트워크를 통과하는 데이터를 파일 단위로 볼 수 있게 되어, 사람의 눈으로 식별 & 분석하기 매우 용이
• 기능
  • 소켓 스트림을 다루어 유저 모드 애플리케이션에서 스트림 전체를 모니터링 가능 -> 통신 우회 용도로 사용
  • 소켓 스트림 필터링: 소켓 스트림이 프록시를 통과하는 것에 대한 허용 여부 필터링

프록시는 그 프록시가 어떤 목적인지와 어떤 관점인지에 따라 약간 구조가 달라질 수 있다.

Proxy - 우회(클라이언트 관점)

클라이언트의 관점에서 프록시 서버는 네트워크 우회 통신을 하기 위해 주로 사용된다.

 

A라는 PC에서 구글과 다이렉트로 통신을 한다고 할 때, 구글 웹서버의 관점에서 자기 자신에게 통신 요청을 보낸 서버 즉, A의 PC에 대한 정보(해당 서버 이름, IP, 등등)를 구글 웹 서버는 모두 볼 수 있다. 다시 말해, 출발지 서버에 대한 정보를 모두 알 수 있다.

 

보통의 경우에는 문제가 없지만, 구글 웹 서버에게 자신의 정보를 노출하고 싶지 않을 수 있다. 이럴 때 사용할 수 있는 것이 프록시이다. 클라이언트 자신의 IP 주소와 같은 정보를 숨기기 위해서도 프록시를 사용하기도 한다. 프록시 서버를 두어 통신을 하면 구글 웹서버에서 볼 수 있는 출발지 IP 주소는 내 PC의 주소가 아닌 프록시 서버의 IP 주소가 된다.

 

또 다른 경우, ISP에서 내 PC가 접속하려는 웹서버에 대한 접근을 차단했을 수도 있다. (Out of Path) 하지만, 나는 어떻게 해서든 이 서버에 접근하고 싶다.. 이럴 때 내 PC에서 프록시 서버를 통해 구글 웹 서버에 우회하여 접속할 수 있다. 물론 이렇게 프록시 서버를 통해 통신하는 방법은 직접 통신할 때보다 속도가 느리다.

 

정리

• 목적: 클라이언트가 네트워크 우회 통신에 사용
• 기능:
  • 클라이언트 IP 숨김
  • ISP 차단을 우회
• 구조:
  1. 클라이언트는 프록시 서버로 요청 전송
  2. 프록시 서버는 목적지 서버(예: 구글)에 요청 전송
  3. 목적지 서버는 프록시 서버를 통해 클라이언트 요청 처리

프록시 서버 구조

1. 프록시 서버는 소켓을 하나 생성해서 내 PC에서 보낼 요청에 대한 대기(Listen) 상태에 있다.
2. 내 PC에서 프록시 서버에 요청을 보낸다.
3. 프록시 서버는 프록시 서버 자신이 도착지인 구글 웹서버로 요청을 보내기 위한 소켓을 또 하나 생성한다.
4. 생성한 소켓을 통해 구글 웹서버로 내 PC의 요청을 그대로 보내준다.

Proxy - 보호와 감시 (클라이언트 관점)

프록시 구조는 클라이언트의 관점이되 보호와 감시를 하기 위한 구조이다. 먼저 클라이언트를 감시하는 용도를 살펴보자.

 

여기서는 프록시 서버가 내 PC 기준으로 내부 네트워크 안으로 이동하게 된다. 위처럼 내 PC가 구글 웹서버와 통신할 때 해당 프록시 서버를 이용해서 통신하면 프록시 서버 입장에서는 내 PC가 구글 웹서버로 어떤 통신을 보내는지 모두 살펴볼 수 있다. 즉, 감시의 기능을 하게된다.

앞서 설명한 것처럼 프록시에서 다루는 데이터 단위는 소켓 스트림이기에 프록시 서버는 네트워크에서 흐르는 데이터를 파일 단위로 볼 수 있고, 사람의 눈으로 식별하기 매우 쉬워진다. 때문에, 이러한 구조에서 프록시 서버는 감시의 역할을 한다.

 

또 한 가지 목적으로, 프록시는 클라이언트를 보호하는 역할도 한다. 만약 내 PC가 구글 웹서버에서 특정 csv 파일을 다운로드 받는다고 가정하자.

 

먼저 구글 웹서버는 내 PC가 요청한 csv 파일을 전송할 것이다. 이때, 프록시 서버를 사용하고 있기 때문에 먼저 프록시 서버로 csv 파일을 전송한다. 그러면 프록시 서버에도 해당 csv 파일이 저장된다. 이때, 프록시 서버는 구글 웹서버가 전송한 csv 파일이 악성 파일인지 아닌지 등 검사를 함으로써 내 PC가 위험에 빠지지 않도록 보호해주는 역할을 한다.

 

다운로드 받는 파일이 프록시 서버를 거치는 것은 알겠다.

 

그런데 만약, 다운로드 받는 파일이 프록시 서버의 파일 시스템 용량을 초과하는 경우는 어떻게 될까?

 

일단 프록시 서버에서 항상 파일 전체를 다운로드 받는 것은 아니다. 스트리밍 하듯 중계만 하기도 하며 전체 파일을 캐싱할 목적으로 모두 다운로드 받은 후 보내 줄 수도 있다. 이는 어디까지나 구현의 문제로, 그 구현 방식에 따라 동작이 달라진다.

 

그리고 Proxy가 더 이상 데이터를 저장 할 수 있는 공간이 없다면 당연히 시스템 오류가 발생할 것이다. 때문에, 적절한 구현 방식을 채택해야 하며, 캐싱한 데이터들을 무한정 쌓아두지 않고, 참조주기를 따져 일정 기간이 넘어가면 삭제하도록 구성하는 것이 보통이다.

 

정리

• 목적: 클라이언트의 아웃바운드 트래픽을 모니터링하고, 인바운드 트래픽으로부터 클라이언트 보호
• 위치: 클라이언트 기준으로 네트워크 내부망에 위치
• 기능:
  • 감시: 클라이언트 요청을 모니터링.
  • 보호: 악성 데이터 차단 및 검사.
• 구조:
  • 모든 클라이언트 요청은 프록시 서버를 경유.
  • 프록시 서버가 데이터를 캐싱하거나 스트리밍 방식으로 전달.

Reverse Proxy (서버 관점)

 

리버스 프록시는 서버 관점에서 서버를 보호하기 위한 용도로 사용된다. 해커 PC에서 구글 웹 서버로 통신하는 상황이라고 하자. 해커는 구글 웹 서버를 해킹하기 위해 구글 웹 서버에 대한 정보를 알아내려고 통신을 시도한다. 이러한 상황에서 구글 웹서버의 정보를 해커 PC에 노출시키지 않도록 하기 위해서도 프록시가 활용되는데, 이러한 프록시를 ‘리버스 프록시’라 부른다.

 

구글 웹서버가 리버스 프록시로 프록시 구조를 사용 중이라면, 해커 PC가 구글 웹서버의 도메인을 입력하여 요청을 보낸다면, DNS로부터 반환받는 IP 주소는 실제 구글 웹 서버의 IP 주소가 아닌 프록시 서버의 IP 주소가 된다. 결국, 프록시 서버가 구글 웹 서버를 보호하는 역할을 하게 된다

 

정리

• 목적: 서버를 보호하기 위해 사용.
• 위치: 서버 기준에서 네트워크 내부망에 위치
• 기능
  • 실제 서버의 IP 및 정보를 외부에 숨김.
  • 부하 분산, SSL 종료(Termination) 등의 부가 기능 지원.
• 구조
  1. 클라이언트는 리버스 프록시 서버로 요청 전송.
  2. 리버스 프록시 서버는 백엔드 서버로 요청 전달.
  3. 백엔드 서버 응답은 리버스 프록시를 통해 클라이언트로 전달.

PC에 설치하는 Proxy

마지막으로 PC에 설치할 수 있는 프록시 서버가 있다. PC에 프록시 서버를 설치하는 이유는 무엇일까?

 

내 PC에서 구글 웹서버로 요청을 보낼 때, 이 보내지는 네트워크 데이터를 분석하고 싶은 경우가 있을 수 있다. 요즘엔 보통 HTTPS로 통신하기 때문에 데이터가 모두 암호화되어 있는 상태이다. 이렇게 암호화된 데이터를 복호화해서 사람의 눈으로 식별하고 분석하기 위해 내 PC에 설치할 수 있는 프록시 서버가 존재한다. 대표적으로 Fiddler라는 프로그램이 있다.

 

PC에 설치하는 프록시 서버 구조는 다음과 같다.

1. 내 PC의 크롬 브라우저에서 구글 도메인으로 접속한다. (크롬은 실행 중인 프로세스임)
2. 이 때, PC에 설치된 프록시 서버(ex. Fiddler)는 소켓을 하나 생성해 크롬 프로세스의 요청을 대기(Listen)하는 포트를 하나 개방한다.
3. 그리고 크롬 브라우저에 입력한 도메인으로 접속할 때 보낸 데이터들이 HTTPS로 프록시 서버로 들어온다.
4. 프록시 서버에서는 HTTPS로 암호화된 데이터를 복호화 할 수 있으며, 이를 통해 네트워크 데이터 분석이 가능하다.
5. 프록시 서버가 클라이언트 용(구글 웹서버로 요청을 보내기 위함) 소켓을 하나 생성하고 구글 웹 서버로 HTTPS 통신을 수행한다.

정리

• 목적: 네트워크 트래픽 분석.
• 구조
  1. PC에 프록시 서버(예: Fiddler)를 설치.
  2. 브라우저 요청은 PC 내부의 프록시 서버를 경유.
  3. 프록시 서버가 데이터를 복호화 후 분석 가능.
• 활용 사례: HTTPS 복호화, 요청 내용 디버깅.