3. 과제

2023. 3. 10. 17:44ㆍ스터디

X-Forwarded-For(XFF) 

XFF 는 HTTP Header 중 하나로 HTTP Server 에 요청한 Client 의 IP 를 식별하기 위한 표준입니다.

(XFF 헤더는 HTTP 프록시나 로드 밸런서를 통해 웹 서버에 접속하는 클라이언트의 원 IP 주소를 식별하는 사실상의 표준 헤더이다.)

 

웹 서버나 WAS 앞에 L4 같은 Load balancers 나 Proxy server, caching server 등의 장비가 있을 경우 웹서버는 Proxy server 이나 장비 IP 에서 접속한 것으로 인식합니다.그렇기 때문에 웹서버는 실제 클라이언트 IP가 아닌 앞단에 있는 Proxy서버 IP를 요청한 IP로 인식하고, Proxy장비 IP 로 웹로그를 남기게 된다.

 

클라이언트 IP ⟶ Proxy 서버 및 장비 ⟶ 웹 서버

 

이때 웹프로그램에서는 X-Forwarded-For HTTP Hearder 에 있는 클라이언트 IP 를 찾아 실제 요청한 클라이언트 IP 를 알 수 있고, 웹로그에도 실제 요청한 클라이언트 IP 를 남길 수 있습니다.


X-Forwarded-For 는 다음과 같이 콤마를 구분자로 Client 와 Proxy IP 가 들어가게 되므로 첫번째 IP 를 가져오면 클라이언트를 식별할 수 있습니다.

 

문법 : X-Forwarded-For: <client>, <proxy1>, <proxy2>

 

<client> : 클라이언트 IP 주소

<proxy1>, <proxy2> : 하나의 요청이 여러 프록시들을 거치면, 각 프록시의 IP 주소들이 차례로 열거된다. 즉, 가장 오른쪽 IP 주소가 가장 마지막에 거친 프록시의 IP 주소이고, 가장 왼쪽이 IP 주소의 최초 클라이언트의 IP 주소이다.

 

PLURA V5 Agent 도 X-Forwarded-For 를 이용하여 XFF HTTP Hearder 에 있는 정보로 실제 요청한 Client IP 를 찾아내고,
웹로그에도 남깁니다.

 

아파치 웹 서버의 기본(common) 로그 포맷은 다음과 같습니다.

LogFormat "%h %l %u %t \"%r\" %>s %b" common

여기서 IP에 해당하는 항목은 %h 입니다. 이에 대한 자세한 설명을 아파치 공식 한글 문서를 통해 확인해 보겠습니다.

서버에 요청을 한 클라이언트(원격 호스트)의 IP 주소이다. 
HostnameLookups가 On이라면 호스트명을 찾아서 IP 주소 자리에 대신 쓴다. 
그러나 이 설정은 서버를 매우 느리게 할 수 있으므로 추천하지 않는다. 
호스트명을 알려면 대신 나중에 logresolve와 같은 로그를 처리하는 프로그램을 사용하는 것이 좋다. 
여기에 나온 IP 주소는 사용자가 사용하는 컴퓨터 주소가 아닐 수 있다. 
프록시 서버가 사용자와 서버사이에 존재한다면, 원래 컴퓨터 주소가 아니라 
프록시의 주소가 기록될 것이다.

XFF를 사용하고자 한다면 로그 포맷을 다음과 같이 수정해야 합니다.

LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b" common

또는 두 필드 모두 기록할 수 있습니다.

LogFormat "%{X-Forwarded-For}i %h %l %u %t \"%r\" %>s %b" common

 

 

Nginx의 경우는 컴파일 시 --with-http_realip_module 옵션을 추가해야 합니다. 그리고 nginx.conf에 다음과 같은 설정을 추가해야 합니다.

real_ip_header X-Forwarded-For;

 

 

XFF에 Client IP를 실어보내지만 정작 request.getHeader("X-FORWARDED-FOR"); 로 꺼내지 않고 request.getRemoteAddr(); 로 꺼낸다면 결국 Client IP가 아닌 Nginx나 Apache 웹 서버의 IP를 가져오게 될 것이다.

이때는 Tomcat의 RemoteIpValve를 이용하여 Client IP 처리를 조작할 수 있다.

  • Tomcat 앞단에 위치한 웹 서버 IP가 192.168.0.10, 192.168.0.11이다.
  • Client IP는 X-Forwarded-For 헤더에 담겨있다.
 <Valve
   className="org.apache.catalina.valves.RemoteIpValve"
   internalProxies="192\.168\.0\.10|192\.168\.0\.11"
   remoteIpHeader="x-forwarded-for"
   />

위와 같이 설정하면 request.getRemoteAddr(); 을 했을 때 X-Forwarded-For 헤더에 담겨있는 IP를 확인할 수 있게 된다.

 

 

그런데 XFF는 완전한 표준은 아니므로 사용에 주의해야 합니다. 즉, RFC 2616 HTTP/1.1에 정의되어 있지 않습니다.

예를 들어 보통은 Header에 XFF가 없다면 request.getRemoteAddr()을 이용하여 Client IP를 얻으려고 할 것입니다. 이런 느낌으로요.

String clientIp = req.getHeader("X-FORWARDED-FOR");
if (clientIp == null) {
  clientIp = req.getRemoteAddr();
}

만약 WebLogic을 사용하는 경우는 WebLogic Connector(wlproxy?)가 XFF를 사용하지 않으므로 다른 Header 값을 이용해야 합니다. Proxy-Client-IP 또는 WL-Proxy-Client-IP 같이 말입니다.

한편 2014년 RFC 7239를 통해 Forwarded HTTP Extension가 정의되었습니다. 관심있는 사람은 해당 RFC 문서를 확인해 보세요.


이제까지는 HTTP Header에서 XFF를 획득하는 내용에 대한 것을 언급하였는데, 사실 중요한 것은 누군가 XFF에 실어주는 것입니다. 대부분의 스위치나 프락시는 이런 기능을 지원하고 있습니다. 아마존 ELB도 그렇고, HAProxy도 마찬가지입니다.

 

 

 

OWASP TOP 10


A01 : Broken Access Control (접근 권한 취약점)

엑세스 제어는 사용자가 권한을 벗어나 행동할 수 없도록 정책을 시행합니다. 만약 엑세스 제어가 취약하면 사용자는 주어진 권한을 벗어나 모든 데이터를 무단으로 열람, 수정 혹은 삭제 등의 행위로 이어질 수 있습니다. 

A02 : Cryptographic Failures (암호화 오류)
Sensitive Data Exposure(민감 데이터 노출)의 명칭이 2021년 Cryptographic Failures(암호화 오류)로 변경되었습니다. 적절한 암호화가 이루어지지 않으면 민감 데이터가 노출될 수 있습니다. 

A03: Injection (인젝션)
SQL, NoSQL, OS 명령, ORM(Object Relational Mapping), LDAP, EL(Expression Language) 또는 OGNL(Object Graph Navigation Library) 인젝션 취약점은 신뢰할 수 없는 데이터가 명령어나 쿼리문의 일부분으로써, 인터프리터로 보내질 때 취약점이 발생합니다. 

A04: Insecure Design (안전하지 않은 설계)
Insecure Design(안전하지 않은 설계)는 누락되거나 비효율적인 제어 설계로 표현되는 다양한 취약점을 나타내는 카테고리 입니다. 안전하지 않은 설계와 안전하지 않은 구현에는 차이가 있지만, 안전하지 않은 설계에서 취약점으로 이어지는 구현 결함이 있을 수 있습니다. 

A05: Security Misconfiguration (보안설정오류)
애플리케이션 스택의 적절한 보안 강화가 누락되었거나 클라우드 서비스에 대한 권한이 적절하지 않게 구성되었을 때, 불필요한 기능이 활성화 되거나 설치되었을 때, 기본계정 및 암호화가 변경되지 않았을 때, 지나치게 상세한 오류 메세지를 노출할 때, 최신 보안기능이 비활성화 되거나 안전하지 않게 구성되었을 때 발생합니다. 

A06: Vulnerable and Outdated Components (취약하고 오래된 요소)
취약하고 오래된 요소는 지원이 종료되었거나 오래된 버전을 사용할 때 발생합니다. 이는 애플리케이션 뿐만 아니라, DBMS, API 및 모든 구성요소 들이 포함됩니다. 

A07: Identification and Authentication Failures (식별 및 인증 오류)
Broken Authentication(취약한 인증)으로 알려졌던 해당 취약점은 identification failures(식별 실패)까지 포함하여 더 넓은 범위를 포함할 수 있도록 변경되었습니다. 사용자의 신원확인, 인증 및 세션관리가 적절히 되지 않을 때 취약점이 발생할 수 있습니다. 

A08: Software and Data Integrity Failures(소프트웨어 및 데이터 무결성 오류)
2021년 새로 등장한 카테고리로 무결성을 확인하지 않고 소프트웨어 업데이트, 중요 데이터 및 CI/CD 파이프라인과 관련된 가정을 하는데 중점을 둡니다. 

A09: Security Logging and Monitoring Failures (보안 로깅 및 모니터링 실패)
Insufficient Logging & Monitoring(불충분한 로깅 및 모니터링) 명칭이었던 카테고리가 Security Logging and Monitoring Failures (보안 로깅 및 모니터링 실패)로 변경되었습니다. 로깅 및 모니터링 없이는 공격활동을 인지할 수 없습니다. 이 카테고리는 진행중인 공격을 감지 및 대응하는데 도움이 됩니다. 

A10: Server-Side Request Forgery (서버 측 요청 위조)
2021년 새롭게 등장하였습니다. SSRF 결함은 웹 애플리케이션이 사용자가 제공한 URL의 유효성을 검사하지 않고 원격 리소스를 가져올 때마다 발생합니다. 이를 통해 공격자는 방화벽, VPN 또는 다른 유형의 네트워크 ACL(액세스 제어 목록)에 의해 보호되는 경우에도 응용 프로그램이 조작된 요청을 예기치 않은 대상으로 보내도록 강제할 수 있습니다.

 

 

 

DNS(Domain Name Service, Domain Name System   도메인 네임 시스템)

 

 

CDN

 

넷플릭스, 왓챠를 비롯해 유튜브, 틱톡 등 우리는 지금 끊임없이 쏟아지는 콘텐츠 홍수 속에 살고 있습니다. OTT 서비스는 전례 없는 호황기를 맞았고, AI, 사물인터넷, 자율 주행 등 대용량의 데이터를 주고받는 신기술이 하루가 멀다고 등장하고 있습니다.

이렇게 폭발적으로 증가한 데이터를 지연 없이 처리하기 위해서는 데이터를 분산해서 전달하는 기술이 필수적입니다. 이에 지리적으로 먼 거리에 떨어져 있는 사용자에게 지연 없이 콘텐츠를 분산해 전달할 수 있는 CDN 서비스가 등장하게 됩니다.

 

 

CDN이란?

Content Delivery Network의 약자인 CDN은 지리적 제약 없이 전 세계 사용자에게 빠르고 안전하게 콘텐츠를 전송할 수 있는 콘텐츠 전송 기술을 의미합니다.

CDN은 서버와 사용자 사이의 물리적인 거리를 줄여 콘텐츠 로딩에 소요되는 시간을 최소화합니다. CDN은 각 지역에 캐시 서버(PoP, Points of presence)를 분산 배치해, 근접한 사용자의 요청에 원본 서버가 아닌 캐시 서버가 콘텐츠를 전달합니다.

예를 들어 미국에 있는 사용자가 한국에 호스팅 된 웹 사이트에 접근하는 경우 미국에 위치한 PoP 서버에서 웹사이트 콘텐츠를 사용자에게 전송하는 방식입니다.

 

 

CDN이 필요한 경우

인터넷을 통해 비즈니스를 운영하거나 웹 사이트에서 그래픽 이미지, 동영상 파일 등의 콘텐츠를 제공한다면 CDN 서비스를 이용할 필요가 있습니다. CDN은 동영상 스트리밍이나 온라인 게임, 대용량 파일 전송, 그리고 해상도가 높아 용량이 큰 이미지를 다루는 쇼핑몰, 포털 사이트 등에서 안정적인 서비스 제공을 위해 활용되고 있습니다.

하지만 특정 국가나 지역만을 타깃으로 하는 웹 서비스를 운영한다면 CDN 서비스를 활용할 필요가 없습니다. 이 경우 CDN을 이용하면 오히려 불필요한 연결 지점이 늘어나 웹 사이트의 성능 저하를 불러올 수 있기 때문입니다.

 

 

CDN 활용 사례

- 넷플릭스(Netflix)

- 에어비앤비(Airbnb)

- NC소프트, 카카오게임즈

 

 

 

 

TAP

 

네트워크 구간에 설치해서

오가는 패킷을 미러링해서 분석할 때 쓰이는 장비다.

인라인 구간에 설치해서 패킷을 모니터장비로 보내는 역할을 한다. 

 

1. Network TAP

- Network상의 In-Line 한 구간에 이동하는 Packet Data를 복사하여 Monitor 장비로 보내주는 역할을 하는 가장 기본적인 TAP.

- UTP TAP, Fiber TAP, WAN용 TAP의 종류가 있음.

 

- Network TAP은 Network Port가 2개로 Link 사이에 구성되며, Monitor Port는 RX 와 TX, 2 Port로 구성 되어있음

​

​

2. Aggregation TAP

- 1개 이상의 Network Links 또는 Ports에서 수집한 Packet Data들을, 1개의 NIC를 사용하는 Monitor 또는 그 이상의 여러 Monitor 장비로 보내 분석할 수 있게 해 주는 TAP

- Link에 연결하는 Link Aggregation TAP 종류와 Switch Hub의 SPAN 혹은 Mirroring Port에 연결하는 SPAN Aggregation TAP이 있음.

 

 

 

Any-To-Any TAP 소개

DATACOM VERSAstream Data Access Switch TAP은 Any-To-Any Ports TAP으로, 일반적인 TAP 장비처럼 Network Ports와 Monitor Ports가 정해져 있지 않고, 또한 TAP내부의 경로 설정을 통하여 복사한 Packet들의 전송 경로의 설정과 제한을 사용자가 원하는 구성에 맞게 사용할 수 있도록 고안된 장비 임.

 

3. By Pass TAP

- 여러 종류의 TAP은 Link 또는 Switch의 Packet들을 복사하여 Monitor 장비들로 보내 주지만, By Pass TAP은 Real Packet Data들이 Monitor Tool까지 직접 이동하여 실제 Data들을 Control할 수 있는 기능을 갖고 있는 점이 장점임.

- Monitor 장비들이 Data들을 제어 할 수 있게 할 뿐 아니라, Monitor 장비의 장애, 전원 장애 그리고 TAP 장애 시에는 자동으로 By Pass기능을 통하여 끊김 없는 네트워크 통신을 만들어 주며, 항상 Monitor 장비의 Ports들과 Heart Bit 체크를 통하여 장애 복구 시 자동으로 원상 복구하는 기능인 Fail-over을 하는 TAP장비 임.

- 실시간 Packet을 감시하는 보안 분야와 Fail over 기능이 필요한 구성에 많이 사용되는 TAP 임. (출처:mssp.tistory.com)

 

 

 

IPSEC

 

1. IPSec (IP Security)

  ㅇ 네트워크계층(IP 계층) 상에서, IP 패킷 단위로 `인증`,`암호화`,`키관리`를 하는 프로토콜


2. IPSec의 특징

  ㅇ 인터넷 경유 구간에, 일종의 보안 통로인 터널링 형성을 가능케 함
     - Layer 3 계층에서, 캡슐화에 의해 보안 통로 제공

  ㅇ 응용 소프트웨어 필요 없이, 대부분 운영체제에서 직접 제공
     - 수송계층(TCP,UDP등) 하위에서 구현되기 때문에, 응용에 투명함
     - 대부분, 운영체제 쪽에서 IPSec 구현 기능을 직접 제공하는 편임

  ㅇ 가상사설망(VPN)에서 특히 많이 사용
     - 사이트 투 사이트, 클라이언트 투 서버, 클라이언트 투 게이트웨이 등 다양한 적용 가능

  ㅇ IP 버젼별 요구 수준
     - IPv4 : 선택적인 요구사항
     - IPv6 : 보다 강제적인 요구사항


3. IPSec의 주요 보안 서비스

  ㅇ 통신 상대방 인증 (Peer Authentication)
  ㅇ 데이터 원천(근원지) 인증 (Data Origin Authentication)
  ㅇ 비연결형 무결성 (Connectionless Integrity)
     - AH 헤더,ESP 헤더에 의해 제공
     - 각 IP 패킷 마다 메세지 다이제스트가 생성되고, 이를 통해 매 패킷 마다 무결성 여부 확인됨
  ㅇ 기밀성 (Confidentiality)
     - ESP 헤더 만 기밀성 제공
  ㅇ 접근제어 (Access Control)
     - 보안연관을 통해 간접적으로 접근제어 제공
     - 만일, IP 패킷이 기설정된 보안연관이 없으면 이를 폐기하는 등
  ㅇ 재생공격 방지 (Replay Attack Protection) 등


4. IPSec의 프로토콜 구조 

  - IP 계층에서 안전하게 데이터를 보호하기 위하여 다음과 같이 복수의 요소들로 구성

  ㅇ `보안성`을 제공하기 위한 2가지 종류의 프로토콜 `헤더`
     - AH (인증 헤더, Authentication Header)                           
        . 발신지 인증,데이터 무결성 만을 보장
     - ESP (캡슐화된 보안 페이로드, Encapsulating Security Payload)      
        . 발신지 인증,데이터 무결성,기밀성 모두를 보장

  ㅇ `키 관리`를 위한 기능 및 기반구조를 정의하는 프로토콜
     - IKE (Internet Key Exchange)
        . IPSec을 위한 SA(보안연관)을 생성하며, 그에따른 키 교환을 수행하는 복합 프로토콜
           .. 공개 키 방식 구현이 가능하도록, 공개키,개인키 교환을 하는 프로토콜
     - ISAKMP (Internet Security Association and Key Management Protocol)
        . IKE 교환을 위한 메세지 형식,전달 절차 등을 규정하는 기반구조로써 설계됨 

     - 여기서, SA(Security Association,보안연관) 이라 함은,
        . 보안 속성들을 함께 결합시켜, 세분화 및 추상화된 개념을 말하며,
        . 일련의 보안연관을 생성하는 과정이, 바로 IKE에 의함


5. IPSec의 운용 모드 및 방식

     - 운용 모드
        . Tunnel 모드 (터널 모드)  :  패킷 전체 보호
           .. IP 패킷 전체를 보호, 그 위에 새로운 IP 헤더를 추가하는 방식
           .. `두 라우터 간에`, `호스트와 라우터 간에`, `두 게이트웨이 간에` 주로 사용 (IPSec VPN) 
        . Transport 모드 (수송 모드)  :  패킷 일부 보호
           .. IP 헤더 이외 나머지 데이터 부분 만 보호하는 방식
           .. `호스트 대 호스트 (종단대종단) 간에` 주로 사용
     - 운용 방식
        . AH 수송 모드 (AH Transport mode)
        . AH 터널 모드 (AH Tunnel mode)
        . ESP 수송 모드 (ESP Transport mode)
        . ESP 터널 모드 (ESP Tunnel mode)

 

 

IP Sec은 그림에서 보는바와 같이 IP계층을 집중적으로 보호합니다.

 

두가지 모드

IPSec에는 두 가지 모드가 있는데, IP의 내용(payload)만을 보호하느냐, 아니면 헤더까지 모두 보호하느냐에 따라서 전자는 전송 모드(Transport Mode), 후자는 터널 모드(Tunnel Model)라고 합니다.

 

전송 모드(Transport Mode)

전송모드는 전송 계층와 네트워크 계층 사이에 전달되는 payload를 보호합니다. 중간에 IPSec 계층이 있기 때문에 IPSec헤더가 붙고, 이후에 네트워크 계층에서는 이것이 모두 상위층에서 보낸 데이터(payload)로 취급이 되므로 IP 헤더가 붙고 아래 계층으로 전달되지요. 

 

 

 

전송모드는 host-to-host( end-to-end)간 데이터 보호가 필요할때 사용이 됩니다. 아래는 전송모드의 데이터 전송 흐름을 보여줍니다.

 

왼쪽 컴퓨터(host)는 IPSec을 적용하여 데이터를 보냅니다. 네트워크를 통해서 오른쪽 컴퓨터로 데이터가 도착합니다. 자, 이 사이에서 다른 사람이 데이터를 가져가도 IPSec에 대한 보호가 이루어져있으므로 볼 수 없고 라우터를 거쳐 두 당사자만 데이터를 보호할 수 있지요. 그래서 종단 간의 보호(End-To-End Protection, E2EP)가 이루어 질 수 있습니다. 

 

 

 

터널 모드(Tunnel Mode)

터널 모드는 IPSec이 IP 헤더를 포함한 IP 계층의 모든 것을 보호합니다. IP 헤더까지 완전히 보호하고 IPSec의 헤더를 추가하였으니 기존의 IP헤더를 볼 수 없기 때문에 새로운 IP 헤더가 추가됩니다. 

 

이 IPSec 헤더와 새로운 헤더는 누가 추가해줄까요? 바로 호스트, 종단이 아닌 그 중간자가 추가해줍니다. 보통 라우터가 되지요. 

 

 

 

 

아래는 그 흐름을 보여주는데, 전송모드와는 다르게 호스트 A는 별다른 IPSec의 조취를 취하지 않습니다. 하지만 Router A에서 IPSec을 적용하고 새로운 IP 헤더를 추가합니다. 이 헤더에는 목적지 라우터의 주소가 있어서 Router B로 보냅니다. Router B는 이후에 적절한 조취를 취하고 새로운 IP헤더와 IPSec헤더를 제거한 후 Host B에게 전달합니다. 마치 RouterA, RouterB가 터널 역할을 하는 것 같네요.

 

터널 모드는 보통 두개의 라우터간, 호스트와 라우터간, 라우터와 호스트간에 사용이 되는데, 즉, 송수신자 양쪽 모두가 호스트가 아닌 경우에 사용됩니다.

 

 

두 가지 프로토콜

IPSec은 또 두가지 보안 프로토콜을 제공하는데, 인증에 대해서만 검사하는 인증헤더 프로토콜(AH: Authentication Header Protocol)과 페이로드 전체를 보호하여 기밀성을 제공하는 보안 페이로드 캡슐화(ESP: Encapsulating Security Payload)가 그것들입니다.

 

AH(Authentication Header)

발신지 호스트를 인증하고 IP패킷의 무결성을 보장합니다. 인증을 위해서 해쉬함수와 대칭키가 사용되어 Message Digest를 생성하고 헤더에 삽입합니다. AH는 인증과 무결성을 보장하지만 비밀은 보장해주지 않습니다.

 

Next Header : IPSec 다음에 오는 페이로드의 헤더를 말합니다. TCP인지 UDP인지 또는 ICMP인지 의미합니다.

Payload Length : 인증헤더의 길이를 말하며 4바이트 배수가 됩니다. 

Security Parameter Index : 32비트 보안 매개변수 색인(SPI) 필드는 Security Association에 대한 식별자입니다.

Sequence Number : 32비트 순서번호인데 이것은 replay attack을 방지합니다.

Authentication Data: 헤더를 포함하여 전체 페킷에 대한 데이터를 인증 데이터로 만드는데, 이때 IP 헤더의 변경될 수 있는 데이터는 제외하고 인증데이터를 만들게 됩니다. 예를 들어 TTL같은 변경이 될 수 있는 데이터는 인증 데이터를 만들때 포함하지 않습니다. 만들면 AH의 Authentication Data필드에 삽입됩니다.

 

ESP(Encapsulating Security Payload)

AH가 데이터의 기밀성을 보장할 수 없지만 ESP는 기밀성을 보장할 수 있습니다. 또한 AH가 보장하는 IP패킷의 무결성 등 AH가 제공하는 서비스를 모두 보장할 수 있습니다.

 

ESP 헤더의 각각 필드는 32비트입니다. 

눈에 익은 필드들이 몇개 보이지요? 대부분은 AH의 필드와 유사합니다. 또 payload를 암호화하고 있네요.

 

Authentication Data : AH와는 다르게 인증데이터가 IP헤더를 포함하지 않습니다. ESP헤더까지만 인증데이터로 만들고 ESP Trailer에 붙이게 됩니다.

 

AH와 ESP의 대한 차이는 다음의 표로 간략하게 정리하였습니다.

Services AH ESP
Access Control O O
Message Authentication
(Message Integrity)		 O O
Confidentiality X O
Replay Attack Protection O O
Entity Authentication
(Data Source Authentication)		 O O

 

접근제어가 보장된다는 것을 알기 위해서는 SAD(Security Association Database), SP(Security Parameters) 등의 용어에 대해서 이해해야하는데, 이것은 다음 포스팅에서 설명하도록 하겠습니다.

 

 

 

VPN

 

VPN은 Virtual Private Network의 약자로 가설사설망이다.

 

VPN은 모든 네트워크 패킷을 암호화 해서 → VPN 서버에 보내고, (VPN 서버를 통해서) → 인터넷에 안전하게 접속한다. 

 

VPN 서버에 연결하면, 인터넷 트래픽이 그 누구도 들여다볼 수 없는 암호화된 터널을 통과하게 된다.

VPN으로 https를 지원하지 않는 사이트도 안전하게 접속이 가능하다. 모든 트래픽이 암호화 되기 때문이다. 

데이터가 서버에 도착하면 암호 해독 프로세스를 통해 외부 패킷이 제거된다. (복호화)

 

 

VPN 사용

 

1. 공공 Wi-Fi를 정기적으로 사용해야 하는 경우

  • VPN은 공용 Wi-Fi를 이용할 때 꼭 필요하다. 완전한 개인 정보 보호를 원한다면 VPN을 사용하여 인터넷 연결을 보호해야 한다.

2. 데이터를 암호화하고자 할 때

  •  VPN 암호화는 인터넷 트래픽을 보호하고 온라인 발자취를 최소화하려는 경우 사용된다. 

3. 기업 네트워크로 사용할 때 

  • 기업은 VPN을 사용해 모두가 본사에 위치한 같은 네트워크를 사용하는 것처럼 서로 멀리 떨어진 직원들을 연결할 수 있다.

4. 게임을 좋아하는 사람들 

  • 온라인 게임을 좋아하는 사람들은 DDoS 공격, 대역폭 조절 및 콘텐츠 제한에 대처해야 할 수도 있다. 게임에 열중하면서 안정적이고 안전한 연결을 즐기고 싶다면 VPN을 사용하기도 한다.

5. 추적 및 감시를 피하려는 경우

  • 정부 기관은 사용자의 인터넷 사용 기록, 메시지, SNS 게시물과 기타 개인 정보를 추적하고 수집한다. VPN은 트래픽을 암호화하고 IP주소를 숨기고 개인 정보를 보호한다. 

6. 차단된 콘텐츠에 액세스하려는 경우

  • VPN이 가장 많이 사용되는 요인 중 하나는 콘텐츠 액세스이다. 해외에서 스트리밍 서비스와 소셜 네트워크를 사용해야 한다면 VPN이 도움이 될 수 있다. VPN은 IP 주소를 변경하고 원격 서버를 통해 인터넷 연결을 리디렉션한다.

7. 사용자가 자신의 위치를 숨기고 싶을 경우

  • 언론의 자유가 제한된 나라에서 일하는 사람들은 비공개 인터넷 연결에 의존하여 업무를 처리한다. 권위주의 체제하에 사는 사람은 VPN을 사용하여 IP 주소를 숨기고 민감한 메시지에 대한 추가 보안을 보장받는다.
 

 

VPN 방식 1 -  IPSEC 방식

IPSEC방식은 쉽게 말하면 하드웨어 vs 하드웨어 방식이라고 생각하시면 됩니다.

 

 

본사와 지사를 VPN으로 연결할 때 본사에 VPN 하드웨어 장비 한대 , 지사에 VPN 하드웨어 장비 한대 이렇게 VPN 장비와 VPN 장비끼리 연결하는 방식을 말합니다. 보통 이동하지 않고 고정되어 있는 장소를 연결할 때 사용하게 됩니다.

 

위에서 말했듯이 서울본사 하드웨어 VPN과 제주지사 하드웨어 VPN이 연결되어서 터널링이 맺어지면 그때부터는 서울 본사와 제주지사가 같은 내부망에 있는 것처럼 연결이 되게 됩니다.

 

 

VPN 방식2 - SSL VPN

IPSEC이 하드웨어 vs 하드웨어 연결이었다면 , SSL VPN은 하드웨어 vs 소프트웨어 연결방식이라고 보시면 됩니다.

 

 

재택근무를 예로 들면 본사에 하드웨어 VPN 장비 한대를 설치한 후 , 모든 직원들이 집에다가 하드웨어 VPN 장비를 한 대씩 놓고 사용할 수가 없기 때문에 클라이언트 소프트웨어를 깔아서 본사로 접속하는 방식입니다.

 

인터넷을 통해서 본사 하드웨어에 접속을 하시면 자동으로 클라이언트 소프트웨어를 다운로드 받은 후에 ID/PW를 입력하게 되면 본사 VPN과 연결이 됩니다.

 

 

IPSEC방식과 다르게 보통 본사는 항상 고정되어 있는 곳이기 때문에 VPN 하드웨어를 설치하고 직원들이 뿔뿔이 흩어져있거나 이동이 많은 사람들이 사용할 수 있도록 하는 방식입니다. 집에서 재택근무를 하다가 카페로 장소를 옮겨도 인터넷만 된다면 본사로 VPN 접속을 하실 수 있습니다.

 

예를 들어서 화장품 방문 판매원이 본사로 VPN을 접속하는데 IPSEC을 이용한다면 VPN하드웨어를 한대씩 들고 다니면서 세팅값을 변경하면서 사용해야 한다고 생각하면 엄청 불편하겠죠. 그럴 때 사용하는 방식이 SSL VPN 방식이라고 보시면 이해가 쉽습니다.

 

 

로드밸런싱 (Load Balancing)

 로드밸런싱은 클라이언트의 요청을 받는 서버의 부하를 줄이기 위해 트래픽을 분산시키는 기법입니다. 그리고 그 역할을 로드밸런서(LB, Load Balancer)가 수행합니다. 로드밸런서는 VIP(Virtual IP)와 함께 구성됩니다.

 

VIP(Virtual IP) 란?

 VIP란 로드밸런싱의 대상이 되는 여러 서버들을 대표하는 가상의 아이피입니다. 클라이언트들은 Server의 IP로 직접 요청을 하는 것이 아니라 LB가 가지고 있는 VIP를 대상으로 요청을 합니다. 그리고 LB는 설정된 부하 분산 방법에 따라 각 Server로 요청을 분산시킵니다.

 

로드밸런싱 알고리즘

라운드 로빈 방식 (Round Robin Method)

 라운드 로빈 방식은 각 서버를 순차적으로 선택하여 요청을 분산시킵니다.

 

가중치 라운드 로빈 방식 (Weighted Round Robin Method)

 각각의 서버에 가중치를 매기고, 가중치 비율에 따라 요청을 분산시킵니다. 주로 서버의 트래픽 처리 능력이 상이한 경우에 사용됩니다. 예를 들어 A 서버의 가중치가 7, B 서버의 가중치가 3이라면 A와 B로의 트래픽 분산 비율은 7:3이 됩니다.

 

IP 해싱 방식 (IP Hash Method)

 클라이언트의 IP 주소를 해시 처리하고, 특정 서버로 요청을 매핑하여 트래픽을 분배하는 방식입니다. 사용자의 IP 주소를 해시 처리하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장합니다.

 

최소 연결 방식 (Least Connections Method)

 연결된 커넥션 수가 가장 적은 서버를 선택하여 요청을 분산시킵니다. 트래픽으로 인해 세션이 길어지는 경우에 권장하는 방식입니다.

 

최소 응답 시간 방식 (Least Response Time Method)

 서버의 응답 시간이 가장 짧은 곳으로 트래픽을 분산시킵니다.

 

로드밸런서의 종류

 로드밸런서는 OSI 7 계층을 기준으로 어떻게 부하를 분산시키는지에 따라 종류가 나뉩니다.

 

L2 (데이터 링크 계층)

 Mac 주소를 바탕으로 로드밸런싱을 수행합니다.

 

L3 (네트워크 계층)

 IP 주소를 바탕으로 로드밸런싱을 수행합니다.

 

L4 (전송 계층)

 Port 기반의 로드밸런싱을 수행합니다. 주요 프로토콜로는 TCP, UDP가 있습니다.

 

L7 (어플리케이션 계층)

 URL, HTTP 헤더, 쿠키 등과 같은 사용자 요청을 기반으로 로드밸런싱을 수행합니다. 즉, 패킷의 내용을 확인하고 그 내용에 따라 트래픽을 특정 서버에 분배하는 것이 가능합니다. 이를 통해 마이크로서비스간에 통신을 유연하고 효율적으로 구성할 수 있습니다. 하지만 패킷 내용을 복호화하여 처리를 해야하므로 부하가 많이 걸릴 수 있다는 단점이 있습니다.

 

 주요 프로토콜로는 HTTP, HTTPS, FTP가 있습니다.

 

로드밸런싱의 구성

Router Mode

Service Request

  • 사용자가 서비스 요청 시, Destination IP는 L4의 VIP 입니다.
  • L4에서 Real Server로 전송 시, Destination IP를 VIP에서 Real Server로 NAT 합니다. (Destination NAT)
  • Network 대역이 변경되었으므로 MAC주소도 Source와 Destination MAC 모두 Rewriting 됩니다.

Service Response

  • Real Server에서 서비스 응답 시, 목적지 IP가 다른 대역이므로 Gateway(L4)로 전송합니다.
  • L4에서 Source IP를 L4의 서비스 VIP로 NAT해서 클라이언트에게 응답합니다. (Source NAT)

 

 L4를 중심으로 상/하단의 IP대역이 서로 다르게 구성됩니다. L4는 Server 대역 Network의 Gateway 역할을 합니다.

 

Transparent Mode

Service Request

  • 사용자가 서비스 요청 시, Destination IP는 L4의 VIP 입니다.
  • L4에서 Real Server로 전송 시, Destination IP를 VIP에서 Real Server로 NAT 합니다. (Destination NAT)
  • 동일 Network 대역이므로, Destination MAC 주소만 Rewriting 됩니다.

Service Response

  • Real Server에서 서비스 응답 시, Destination IP가 다른 대역의 IP이므로 Gateway(Router)로 전송합니다.
  • Server에서 Gateway 구간에 L4를 거치면서 Source IP를 L4의 서비스 IP로 NAT을 수행합니다. (Source NAT)
  • 동일한 Network 대역이므로 MAC 주소는 따로 Rewriting 되지 않습니다.

 

One-Arm Mode

Service Request

  • 사용자가 서비스 요청 시, Destination IP는 L4의 VIP 입니다.
  • L4에서 Real Server로 전송 시, Destination IP를 VIP에서 Real Server로 NAT을 수행합니다. (Destination NAT)
  • Destination으로 전송을 위해서 Destination MAC 주소도 Rewriting 합니다.
  • Real Server에서 L4로의 전송을 위해서 Source IP도 L4의 IP Pool의 IP로 NAT을 수행합니다. (Source NAT)

Service Response

  • Real Server에 서비스 응답 시, 목적지는 L4에서 NAT된 IP Pool의 IP로 보냅니다.
  • L4에서 클라이언트로 응답 시, Source IP를 Real Server의 IP에서 L4의 서비스 VIP로 NAT을 수행합니다. (Source NAT)
  • Destination IP를 IP Pool의 IP에서 클라이언트 IP로 NAT을 수행합니다. (Destination NAT)

 

 One-Arm Mode는 클라이언트의 IP가 Server에 전달되지 않기 때문에 Server가 실제 클라이언트의 IP를 이용해야 할 경우 부적합한 기법입니다. 일반적으로 권고되지 않는 구성 방법입니다.

 

DSR (Direct Server Return)

 방금 위에서 소개한 기법들은 모든 Inbound, Outbound Packet을 LB를 거치기 때문에 LB에 많은 부하가 발생합니다. 대부분의 서비스들의 트래픽은 보통 Inbound 보다 Outbound Packet의 양이 많습니다. DSR은 Outbound Packet이 LB를 거치지 않고, 클라이언트로 전달하게 만들어 LB의 부하를 줄일 수 있습니다.

 

L2DSR

 

 

 

 L2DSR은 Inbound Packet의 Destination MAC을 바꾸는 기법입니다.

  • LB는 Inbound Packet의 MAC 주소로 변환한 후 Real Server에게 전달합니다.
  • Real Server는 VIP 주소를 갖고 있는 Loopback Interface를 통해 Source IP를 변환하여 클라이언트에게 Outbound Packet을 전달합니다.

 

 L2DSR은 Inbound Packet의 MAC 주소만 변경하기 때문에 LB와 Server들은 모두 같은 네트워크에 속해야 합니다. 그로 인해 물리적인 회선, 위치등의 한계가 있는 구성 방식입니다.

 

L3DSR

 L3DSR은 서로 다른 네트워크에 속해야 한다는 L2DSR 구성 방식의 한계를 극복하기 위한 기법입니다. L3DSR은 IP 패킷의 DSCP 필드를 수정하여 L4 스위치에서 받은 클라이언트 요청을 L3 레이어를 통해 서버가 직접 응답할 수 있게 합니다.

 

 DSCP 필드 수정을 통한 커뮤니케이션이 가능하게 하려면 L4 스위치와 서버 간의 합의점이 필요합니다. 즉, DSCP와 가상 IP의 연결이 필요합니다. LB와 모든 Server는 DSCP/VIP Mapping Table을 알고 있습니다.

  • LB는 Inbound Packet의 Destination IP를 Real Server의 IP로 변환하고, Packet의 Destination IP 정보와 Mapping Table 정보를 바탕으로 DSCP 값도 변경합니다.
  • Real Server는 Mapping Table과 Loopback Interface를 통해 Source IP를 변경하고 DSCP 값을 0으로 만들어 Client에게 바로 전달합니다.

 

 

 

 

 

 

NAT

네트워크 주소 변환(network address translation, 줄여서 NAT)은 컴퓨터 네트워킹에서 쓰이는 용어로서, IP패킷의 TCP/UDP 포트 숫자와 소스 및 목적지의 IP 주소 등을 재기록하면서 라우터를 통해 네트워크 트래픽을 주고 받는 기술을 말한다.Network Address인 IP를 변환(Translation)하는 용도이다.

 

 

목적

 

첫째, 인터넷의 공인 IP주소를 절약할 수 있다는 점

둘째, 인터넷이란 공공망과 연결되는 사용자들의 고유한 사설망을 침입자들로부터 보호할 수 있다는 점

 

1) 인터넷의 공인 IP주소는 한정되어 있기 때문에 가급적 이를 공유할 수 있도록 하는 것이 필요한데 NAT를 이용하면 사설 IP주소를 사용하면서 이를 공인 IP주소와 상호변환할 수 있도록 하여, 공인 IP주소를 다수가 함께 사용할 수 있도록 함으로써 이를 절약할 수 있는 것입니다.

 

2) 공개된 인터넷과 사설망 사이에 방화벽(Firewall)을 설치하여 외부 공격으로부터 사용자의 통신망을 보호하는 기본적인 수단으로 활용할 수 있습니다. 이때 외부 통신망 즉 인터넷망과 연결하는 장비인 라우터에 NAT를 설정할 경우 라우터는 자신에게 할당된 공인 IP주소만 외부로 알려지게 하고, 내부에서는 사설 IP주소만 사용하도록 하여 필요시에 이를 서로 변환시켜 줍니다. 따라서 외부 침입자가 공격하기 위해서는 사설망의 내부 사설 IP주소를 알아야 하기 때문에 공격이 불가능해지므로 내부 네트워크를 보호할 수 있게 됩니다.

 

 

SUBNET

 

1. 개요

  ㅇ Subnet (Sub Network) (서브넷)
     - 네트워크의 논리적인 분할
        . 네트워크가 세분화된 단위 
           .. 통상적으로, 작고 단일한 물리적 네트워크를 말함
        . 큰 네트워크가 작은 네트워크로 분할된 단위

  ㅇ Subnetting (서브넷팅)
     - 네트워크를 보다 세분화하기 위한, IP 주소의 구성 변경
        . IP 주소 체계가 2단계 (네트워크 ID - 호스트 ID) 구분방식인 것을, 
          다시 3단계(네트워크 - 서브네트 - 호스트)로 네트워크 세분화
        . 호스트 구분 ID에 할당된 비트들을 추가적으로 네트워크 구분 ID로 사용 가능

  ㅇ Subnet Mask (서브넷 마스크)
     - 서브 네트워크를 만들기위해 AND 비트 연산에 의해 씌우는 마스크
        . TCP/IP 프로토콜에서 IP 주소체계로 네트워크를 나누는 (분할하는) 논리적인 수단
     -  Mask는 차폐의 의미를 갖음


2. 네트워크 구분에 대한 주소 표현 형식

  ㅇ 2 단계 및 3 단계 주소 형식

3. 서브 네트워킹하는 이유

  ㅇ 브로드캐스팅 영역(브로드캐스트 도메인) 크기를 작게하는 효과
  ㅇ 주소 절약의 효과 
  ㅇ 라우팅 정보의 크기 감소


4. 라우터 및 서브 네트워크

  ㅇ 인터넷은 라우터에 의해 나누어진 서브 네트워크가 모인 커다란 네트워크

  ※ 만일,
     - 하나의 라우터에 있는 다수개의 인터페이스에다가 각각의 서브네트로 나눠 구분하면
       전달되는 라우팅 정보의 크기를 감소시킬 수 있음


5. IPv4 네트워크를 잘게 나누는 방법 (Subnet Mask 사용방법)

  ㅇ `255.255.255.0` 또는 `/24` 마스크는 `255.255.255`까지는 네트워크, `0`은 노드를 가리킴
     - 만일, `147.6.8.169`에 `255.255.255.0`을 마스크하면,
        . `147.6.8`까지는 네트워크를 가리키고,
        . `169`는 그 중 하나의 노드를 가리킴

  ㅇ 만일, `147.6.8.xxx`와 같은 C 클래스급 네트워크를 서브넷 분할코자 한다면,

     * 위의 수치는 2진법 계산을 해보면 쉽게 알 수 있음


6. IPv4 주소의 서브 네트워킹 例

  ※ `네트워크 주소` 및 `서브넷 마스크` 2개로 할당 가능한 IP 주소 범위를 알 수 있음

  ㅇ 192.168.63.0 / 24
     - 서브네트 마스크 길이 : 24 비트 (1개의 서브넷으로 나눌수 있음)
        . Prefix 길이 : 24  (10101100.10101000.00111111).00000000
        . Subnet Mask : 255.255.255.0 
     - 서브넷 수 : 1
     - 네트워크 주소 
        . 192.168.63.0
     - 가능한 IP 주소 범위 
        . 192.168.63.1 ~ 192.168.63.254
     - 브로드캐스트 주소 
        . 192.168.63.255

  ㅇ 192.168.63.0 / 25
     - 서브네트 마스크 길이 : 25 비트 (2개의 서브넷으로 나눌수 있음)
        . Prefix 길이 : 25  (10101100.10101000.00111111.0)0000000
        . Subnet Mask : 255.255.255.128
     - 서브넷 수 : 2
     - 네트워크 주소 
        . 192.168.63.0
        . 192.168.63.128
     - 가능한 IP 주소 범위 
        . 192.168.63.1 ~ 192.168.63.126 
        . 192.168.63.129 ~ 192.168.63.254
     - 브로드캐스트 주소 
        . 192.168.63.127
        . 192.168.63.255

'스터디' 카테고리의 다른 글

2. Header 조사  (0) 2023.02.16
1. HTTP  (1) 2023.02.06

관련글

티스토리툴바