섹션 0. 네트워크 장치의 구조

학습목표

1. 네트워크 장치의 3대 구조를 이해 (기본구조:Inline, Out of path, Proxy)

2. NAT기술 기반 인터넷 공유기 작동원리를 이해 (NAT -> Network Address Translation)

3. 부하분산 장치의 원리를 이해 (웹서비스 기반의 부하분산개념)

4. VPN의 구조와 원리를 이해 (네트워크 보안 장치의 일종 -> Virtual Private Network 기술)

5. 주요 네트워크 보안 장치의 특징을 이해

---

<세 가지 네트워크 장치 구조>

1.  Inline -> Packet을 다룬다 / 필터링이 가능(드랍:차단, 바이패스:허용) -> 라우터

2. Out of path  -> Packet을 다룬다 / 읽기만 함 (인지 목적) -> 네트워크 센서, 탭 스위치

3. Proxy -> Socket stream 데이터를 다룬다 / 필터링이 가능 

ㄴ 패킷에서 스트림을 얻으려면 조립을 해야함 (주로 파일)

프록시 (유저모드, 어플리케이션, 프락시, 소켓, 스트림)  5~7 계층 커버

패킷의 최대 크기 -> MTU

 

<Inline 구조>

packet -> 자동차

network -> 고속도로

인라인 -> 패킷이 통과해서 지나간다

 ex) 공유기, 라우터(인터넷을 이루는 핵심 장치), 방화벽, IPS(침입방지체계)

내부-R-외부(인터넷) : 트래픽이 바깥으로 나감(아웃바운드), 트래픽이 안으로 유입됨(인바운드)

<Out of path 구조> = 센서 + 패킷 수집 장치(L2 Port 미러링 : 포트 미러링)

탭스위치 : 복사전문 - 포트 미러링을 전문적으로 하는 장치

분석 혹은 탐지의 목적, 인지의 목적으로 사용

ex)

만약 PC가 보낸 packet을 센서에서 막으려고 하는 경우, 센서가 abc 닷컴인 것처럼 거짓 응답을 보냄

Q. 센서는 읽기 전용인데 어떻게 거짓 응답을 보내는가?

L7 HTTP -> 소켓 수준, 스트림 단위 데이터 : 네트워크로 갈 때 세그먼테이션(잘게 잘라서)으로 하나가 패킷으로 잘려서 감

IP TCP HTTP -

헤더(IP+TCP : 택배송장)

HTTP부터는 페이로드(여길 들여다보는 행위를 DPI)

HTTP (프로토콜 헤더) => spi (shallow packet inspection)가 허용되어있음(한국)

spi로 어떤건 통과, 어떤건 차단한다 하면 적법한가? -> 차별이 있을 수 있음

망중립성의 원칙 -> 어떤건 되고, 어떤건 안 되고 하게끔 하지 않는 것

dpi 의 경우 사생활과 직결됨 -> 고로 ISP가 할 수 없음

센서 -> 놓치지 않고 수집하는거

라인레이트 -> 트래픽을 디스크에 write 한 다음 나중에 읽어서 분석

Q. 그럼 라인레이트 자체가 디스크에 write 하는거라고 한다면 문제가 되는거 아닌가?

Q. 정확히 라인레이트가 뭐지?

---

<Proxy 구조> = 우회 !! Client 관점

proxy sever + socket + stream

자신을 속이기 위한, IP 주소를 감출 목적으로 사용

속도는 직접 가는 것보다는 떨어짐

실질적으로 인터넷에서 차단이라고 하는 것은 불가능에 가깝다.

user가 proxy 서버의 Listen 포트로 진입, proxy 서버에서 clien 포트를 열어 변경하고자 하는 IP로 변환

 

<Proxy 구조> = 보호와 감시 !! Client 관점

PC에서 인터넷으로 바로 못가게 막음

그렇게 되면 프록시를 거쳐야하는데, 프록시의 경우 모든 것을 다 알 수 있음

고로 인터넷에서 접근을 시도한 경우도 알 수 있음

HTTP 트래픽 모니터링시 감시로 활용 가능

또한 프록시 서버에서 웹에서 받아온 파일을 검사하고 PC로 보내주기도 함

IPS의 경우 단편화된 패킷만 보지만 프록시의 경우에는 HTTP 스트림을 다 볼 수 있기 때문에

파일을 추출해서 보기 유리

Stream 데이터를 회사가 읽을 수 있지만 개인정보를 도청했다고 하기 애매함

-> 회사의 자산을 보호하기 위해서 어쩔 수 없이 해야하는 측면이 있음

 

<Proxy 구조> 보호 !! Server 관점 : Reverse Proxy

리버스 프록시 : 서버를 보호할 목적

IPS 같은게 패킷을 분석해 단편적인 정보를 가지고 막음

IP 대역대 일부 차단(L4 이하 수준에서의 통제)

패킷에 dpi 실시해 시그니처 검색 후 막음

문제! HTTP만 사용하지 않음 -> 암호화를 함

IPS 같은 장비들이 암호화를 볼 수 없음 고로 웹서버인 것처럼 작동하는 프록시 서버

ex) SSL 서버

Client 에서 접속 시도시 DNS는 Client에 진짜 웹서버 주소가 아닌, 프록시의 주소를 알려줌

웹서버를 대리하고는 있으나 실제로는 웹서버가 아님

SSL 서버를 지나고 평문 통신으로 웹 어플리케이션 파이월에서 유입을 막음

-> 서버 보호를 위해 격벽이 되어주듯 존재하는 프록시 서버 : 리버스 프록시

 

리버스 프록시를 사용하게 됐을 경우(= SSL이 적용된 경우) 인터넷 통신 간에 HTTPS 사용

즉 트래픽이 모두 암호화 되어있음 => 트래픽을 분석하려면 복호화 해야함

그래서 프록시 형태로 작동하는 무언가를 PC에 설치해서 쓰는 경우가 있음

 ex) Fiddler 

크롬과 피들러 간 통신은 HTTPS, 피들러에서 바깥으로 나갈 때도 HTTPS 로 하지만 피들러 안에서 복호화를 함

이 때 스림 수준으로 복호화(패킷 단위X)하기 때문에 분석에 용이

* 트래픽 분석 목적으로 로컬에서 위와 같이 사용하는 경우도 있음

 

프록시 구조 -> 단일 호스트 내에서도 프로세스를 분리시켜 프로세스 간의 통신처럼 떼내어 프록시를 운영할 수 있다

 

프록시 목적 -> 우회 / 감시, 차단 / 서버 보호(리버스 프록시) / 로컬에서의 HTTPS를 평문으로 바꿔 분석하고자 할 때