⚡ CPS (Connection Per Second)

초당 연결 할 수 있는 연결 수를 의미한다.

WAF 계측 시에는 최대 CPS를 측정하기 위해서는 1 Connection의 1개의 요청, 응답사이즈는 1kb로 측정하며, 종료는 Finish로 종료한다.

주의할 점은 한 명의 사용자가 하나의 페이지에 들어간다고 1개의 Connection 이 이뤄지는 것은 아니다. HTTP/2 가 아닌 경우 브라우저는 요청을 병렬화 하여 6개[기본 값] 정도를 한번에 전달한다.(도메인 샤딩 기술, HTTP/1.1)

도메인 샤딩

⚡ TPS (Transaction Per Second)

초당 전달할 수 있는 요청의 수를 의미한다.

1 Connection에서 10개의 transaction하며, 응답 사이즈는 1kb로 설정하여 받는다. 연결 후 전달하는 요청을 측정한다.

⚡ Throughput

1 Connection 10개의 transaction을 응답사이즈를 적절하게 혼합하여 처리량 트래픽을 만듦. (시험성적서 기준 응답 사이즈는 1KB (10%), 8KB(10%), 16KB(10%), 32KB(70%)) 이는 실 환경을 고려한 혼합된 사이즈이다. 하지만 운영에서는 mix 된 사이즈는 실제를 기반으로 혼합하지만 구축된 웹과 차이가 있을 수 있다.

만약에 응답 사이즈가 1KB 일 경우 높은 throughput은 만들기 어렵다. 예를 들어 connection 당 10개 transaction이 있고, 이의 응답 사이즈가 1KB 이면 처리량은 10KB 이다. 해당 장비는 CPS가 최대치 10,000 이라고 가정하면, 처리량은 10KB * 10000 연결 = 100000KB = 100MB 이다. 해당 응답사이즈로 처리량 1GB을 요구 시 장비는 100,000의 CPS를 만들어야 한다. 그러므로 Transaction 당 응답 사이즈가 증가해야 Throughput이 증가가 가능하다. 처리량은 CPS, TPS, 응답사이즈와 연관성이 있다.

⚡ CC(Concurrent connections)

세션을 끊지 않는 상태로 최대 세션을 맺을 수 있는 수를 측정 CC는 메모리의 용량에 비례하여 처리 가능

그림은 전부 WAF의 Proxy 기준으로 작성하였으며, 프록시가 아닌 경우는 계측기 C ↔ WAF로 이해하여 생각하면 된다.

마크다운은 텍스트 기반의 마크업 언어로, 2004년 존 그루버에 의해 만들어졌습니다. 이 언어는 쉽게 쓰고 읽을 수 있으며 HTML로 변환할 수 있습니다. 깃헙 저장소의 README.md와 같이 간결하게 설치 방법, 소스 코드 설명, 이슈 등을 기록하고 가독성을 높일 수 있습니다. 마크다운의 장단점은 다음과 같습니다:

장점:

1. 간결함: 간단한 구조의 문법을 사용하여 빠르게 컨텐츠를 작성할 수 있습니다.
2. 별도의 도구 없이 작성 가능: 특별한 도구 없이 텍스트로 작성할 수 있습니다.
3. 다양한 형태로 변환 가능: 다양한 형식으로 변환할 수 있어 유연하게 활용할 수 있습니다.
4. 용량이 적어 보관이 용이: 텍스트 파일로 저장되기 때문에 용량이 적습니다.
5. 버전 관리 가능: 텍스트 파일이므로 버전 관리 시스템을 이용하여 변경 이력을 관리할 수 있습니다.
6. 다양한 프로그램과 플랫폼 지원: 여러 프로그램과 플랫폼에서 사용할 수 있습니다.
   

   단점:

7. 표준이 없음: 표준이 없어 도구에 따라 변환 방식이나 생성물이 다를 수 있습니다.
8. 모든 HTML 마크업을 대신하지 못함: 모든 HTML 요소를 대체하지는 못합니다.

사용법

1. 제목

제목1

제목2

제목3

제목4

[mark down]

# 제목1
## 제목2
### 제목3
#### 제목4

2. 항목

1. 순서가 있는 항목 1
2. 순서가 있는 항목 3
3. 순서가 있는 항목 5
   1. 순서가 있는 소항목 1
   2. 순서가 있는 소항목 3
   3. 순서가 있는 소항목 5

[mark down]

1. 순서가 있는 항목 1
3. 순서가 있는 항목 3
5. 순서가 있는 항목 5
[tab] 1. 순서가 있는 소항목 1
      3. 순서가 있는 소항목 3
      5. 순서가 있는 소항목 5

Auto-numbering 가능

3. 강조

이텔리체 ** 볼드 **

[mark down]
*이텔리체*
**볼드**

4. 링크

google

[mark down]
[google](https://www.google.com)

5. 이미지

[mark down]
![구글이미지](https://www.google.com/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png)

6. 인용문

인용문

[mark down]
>인용문

7. 코드

abc inline code

code block

[mark down]
```abc``` inline code
\```
code block
\```

8. 수평선

[mark down]
---

9. 표

[mark down]
|항목|값
|---|---|
|a|b|

10. 특수 문자

```abc``` inline code not block

[mark down]
\```abc``` inline code not block

ChatGPT 3.5가 알려주지 않은 것들

• 수평선은 --- 외에도 *** 도 가능하다.
• 줄 바꿈은 <b> 로 가능하다.
• 강조 이텔릭이나 고딕은 * 이 아닌 _ 로도 가능하다.
• 강조에서 취소선은 ~취소문구 사용한다.
• 인용은 > 최대 3 depth를 만들 수 있다.
• *, +, - 를 이용하여 마크다운의 순서가 없는 항목을 달리 만들 수 있다 (velog 불가)
• 이미지 태그를 이용하여 <img src="https://www.google.com/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png" width="100px" /> 사이즈 조절이 가능하다.
• < 이메일 주소 > 로 이메일 링크가 가능하다.
• code block의 경우 스페이스 4칸으로도 대체가 가능하다.
• ```[사용 언어 입력] 코드 블럭 ``` 시 syntax color 가 적용된다.
• - [x] 입력 시 체크리스트가 작성된다. 반대는 -[ ] 이다.
• 표는 정렬이 가능하며, |:---| 왼쪽 정렬, |:---:| 오른쪽 정렬, |:---:| 가운데 정렬이다. 마크다운 표는 간단하게 마크다운으로 만들어주는 사이트도 존재한다.
• 색상을 입히는 법 빨간색 <span style="color:red">빨간색</span> 노란색 형광 <span style="background-color:#fff5b1">노란색 형광</span> 초록색 형광 <span style="background-color:#dcffe4">초록색 형광</span> 하이라이트빨강, 글자색 흰색 <span style="color:white; background-color:red">하이라이트빨강, 글자색 흰색</span>

What type of device are you testing?

Switch / router / Core router / NAT, Proxy / IPS / IPSec / LTE LPC / LTE MME / 3G packet core / Server / Custom

위의 구분으로 DUT의 환경 구성에 맞는 환경에 따라 생성한다

우선은 WAF의 계측기에 대한 프로파일 생성을 위해 NAT / Proxy를 클릭하고 create 를 생성

※ DUT 환경에 따라 모드 선택이 필요하다.

Start-up

처음 생성되는 초기 값이다. 이제 테스트 환경에 따라 변경이 필요하며, 제일 먼저 해야할 것은 물리적인 Interface reserve이다. 우측 상단의 느낌표가 있는 Chassis를 클릭 한다.

연결된 인터페이스를 클릭하면 열쇠 모습으로 잠기는 모습을 볼 수 있다.

reserve를 했다면 할당 된 포트를 확인이 필요하다. 현재 사용하고 있는 계측기 CloudStorm은 40G Interface * 4 가 있으며, 슬롯 당 Interface가 2개이다. 정보는 하단의 [Port Mapping]과 [Port Configuration]를 통해 확인하면 된다.

여기서 주의할 점은 슬롯에 따라 인터페이스가 다를 수 있으며, In, Out에 대한 물리적 포트 연결도 주의해야 한다. 꼭 Port Mapping에서 reverve한 정보 확인이 필요하다.

만약에 DUT의 Interface의 종류가 다르다면 Port Configuration에서 변경 후 slot reboot이 필요하다.

Network Neighborhood setting

이제 network 설정을 해주면 된다.

항목 별 필요한 부분은 Add row로 추가를 하면 되며, 이 외 추가 항목은 [ADD NEW ELEMENT]로 추가를 하면 된다.

위의 설정 값으로 Diagram Mode 확인 시 위와 같다.

Neighborhood 는 위의 그림과 같이 설정을 했다. 시험 환경에 맞게 Network 대역대는 조정을 하면 된다.

사실 제일 기본적인 가이드이고, Network에 대한 지식도 필요하다. 하지만 기본이 되며, 이를 기준으로 각기 다른 시험 환경에 대해서 변경을 하면 된다.

계측기 : 사물을 검사할 때 쓰는 장비

위의 표는 정부자원기술기준시험절차서의 웹방화벽 상세 내용이며, DUT(Device Under Test, 시험 대상 장비)는 기능 설정(파란색 네모)을 하며, 계측기는 제공 조건(빨간 네모)으로 설정하여 목표치(초록 네모)의 수치를 만든다.

허용 실패 수치는 시험 조건에 따라 다를 수 있다

보통 제품 도입 BMT에서 진행하는 계측은 여러가지 제조사의 동일 기준으로 비교함에 있으며, 이의 성능은 실제 망에서 사용 시 성능과 괴리가 있으며, 지표라고 생각하는게 맞다.

예를 들어 한 사람이 100m 트랙에서 10초의 기록을 갖고 있지만, 100m 일반 도로에서는 해당 기록이 안나올 수 있다.

위의 표를 기준으로 가급 장비는 응답 사이즈가 32Kb이며, 1 GET 일 때 10번의 Transaction 으로 조건의 HTTPS 1.5Gbps 이므로 실제 사이트에서 응답 사이즈가 이보다 작을 경우, 또는 암호화 알고리즘 보안 강도가 더 높은 경우, Transaction이 적은 경우 등 다양한 조건에 성능은 달라질 수 있다.

웹방화벽은 대표적으로 Ixia / Spirent 2가지의 계측기를 많이 사용하며, Keysight의 Breakpoint 부터 글을 작성해보려고 한다.

Breakpoint는 제품 사양에 따라 perfectStorm(max 40G) / CloudStorm(max 100G) 으로 나뉜다.

w3techs.com에서 확인 된 24년 1월 웹사이트 HTTPS 사용 추이는 85.2%이며, 이는 한국에 국한되지 않는 글로벌 추이이다.

하지만 WEB에 대한 이해를 돕기 위해 우리는 복호화하여 내용을 볼 필요가 있다. 그래서 HTTPS 패킷을 복호화하는 3가지 방법을 소개하려고 한다.

전체 Flow

우선 우리가 복호화의 방법을 알기 위해서는 HTTPS(RSA) 흐름을 인지할 필요가 있다. DH(Diffie–Hellman)에 대해서는 추가 보완 예정

1. 개인키 사용

WEB 운영자가 아니라면 실제 개인키를 획득하기가 어렵다. 하지만 OpenSSL 을 적용해서 테스트를 한 경우라면 Private.key 를 획득은 쉽다. OpenSSL로 키를 발급 받는 방법도 긴 편이므로 나중에 적어보도록 한다.

우선 개인키를 획득했다면 Wireshark에 넣어주면 된다. RSA Key list에서 주의할 점은 HTTPS이여도 Protocol은 HTTP로 기입을 해야한다.

위와 같이 등록을 하면 열어진 상태에서는 reload 를 한다.

하지만 복호화된 결과는 보여지지 않았다. 이유는 암호화 프로토콜이 TLS 1.3으로 맺어졌고, TLS 1.3의 Cipher suite(보안 알고리즘)은 전부 DH(Diffie–Hellman)으로 개인키로 복호화가 불가하다.

웹 서버의 설정을 암호화 프로토콜은 TLS 1.2로 보안 알고리즘은 TLS_AES_256_GCM_SHA384으로 변경하여 RSA 키 교환 방식으로 변경하였다.

RSA key list 적용

RSA key list 미적용

실제로 테스트를 진행 시 보안 알고리즘 선택을 키 교환 방식을 RSA 임의의 알고리즘으로 적용 시 실패할 수 있다. 이는 브라우저에서 지원하는 보안 알고리즘의 리스트가 다르며 사용 브라우저와 버전에 따라 상이하다. https://www.ssllabs.com/ [Test your browser] 를 이용하여 간편하게 확인이 가능하다.

복호화 방법 : Flow 이미지 중 ⑧ 개인키를 이용

2. Proxy Tool(Burp suite) 사용

대표적인 프록시 툴이다. 개인키의 등록이 아닌 신뢰할 수 있는 루트 인증 기관 인증서를 PC에 설치하는 방법이다.

• 다운로드 사이트 https://portswigger.net/burp/communitydownload

위와 같이 PortSwigger 인증서를 루트 인증서에 설치 시 완료 브라우저는 burp suite 자체 Proxy 탭의 Open browser에서 이용해야 한다.

Intercept on 타이밍은 변조 직전에 On으로 활성화를 해야하며, Intercept 중에는 브라우저 페이지가 넘어가지 않는다.

하지만 이 또한 보안알고리즘의 키 교환방식이 DH(Diffie–Hellman)인 경우 제한이 있다.

DH 알고리즘 사용 시불가 화면

복호화 방법 : Flow 이미지 중 ⑥을 이용

시연을 위해서 서버의 보안 알고리즘을 변경 함

3. Pre-master-scret 키를 사용

[Window 가이드]

윈도우 키를 누른 후에 '환경 변수' 를 입력하여 '시스템 속성'을 열어준다

변수 이름은 'SSLKEYLOGFILE' 로 생성하고, 변수 값은 폴더 위치를 포함한 파일 이름까지 설정한다.

[주의] 윈도우 관리자 권한으로 자동으로 폴더를 생성하지 않으므로, 지정한 폴더의 생성이 필요하다. [주의] 생성이 안되는 경우 재시작 후 브라우저를 열어서 확인이 필요하다.

위와 같이 키가 생긴다면, wireshark 설정에서 아래와 같이 설정한다.

기존의 test1.pcap 의 Pre-master-scret 키가 있어 설정 후 다시 패킷을 불러왔다.

해당 방법이 완벽할 것 같지만, 몇 가지 제한점이 있다. OS 환경 변수를 사용하였기에, 변수가 설정 된 OS 브라우저를 사용해야한다는 점이다. (Jmeter나 Postman 같은 Tool 사용 시 Pre-master-scret 키가 생성되지 않으므로 복호화 불가)

복호화 방법 : Flow 이미지 중 ⑨을 이용

이제 HTTPS 를 복호화한 값을 보도록하자. HTTP/2의 경우 DH(Diffie–Hellman)을 이용하므로 3번째 방법을 꼭 진행해야 한다.

HTTP 2.0을 이해하기 앞서서 Window size에 대한 사전 이해가 필요하다. 여기서 Window size는 OS가 아니다. TCP Window size는 데이터의 양 또는 버퍼의 크기라고 이해를 하면 쉽다.

Window size

TCP(Transmission Control Protocol, 전송 제어 프로토콜)은 연결 이후 데이터와 패킷의 신뢰성을 보장한다.

데이터의 전달할 수 있는 크기는 Window size이며 16bytes(2^16 = 65536, 0-65535, 65535 bytes)의 크기를 갖는다.

데이터를 전달하는 방법은 아래와 같다. 전달한 패킷의 응답이 올 경우 다음 패킷을 전달할 수 있다. (Stop and wait)

좀 더 효율적인 방법도 있다. 3-handshake 후 송신측의 window size와 송신한 window size 값을 계산하여 공간이 부족할 경우에는 송신을 중단하고, 수신 공간이 생기면 TCP Header의 Window Field로 송신측에 알린다. (sliding windows)

이를 일반적으로 Flow control, 흐름제어라고 한다.

TCP Stream 23번의 경우 최초의 패킷은 Window size value 값을 64240을 송신측이 전달하고 동일한 값을 수신측이 받았다.

Window size 65535가 아닌 이유는 일반적으로 MTU 1500일 경우 IP Heaer 20bytes와 TCP Headers 20bytes를 제외한 1460 MSS(Maximum segement size, TCP segmenet의 최대 데이터 양)을 갖는다. 일반적인 경우 65535 / 1460 = 44.886... 이므로 기본적인 값으로 44 * 1460 = 64240의 window size를 전달한다.

만약에 window size가 작다면 어떻게 될까? 매우 비효율적일 것이다. 그러면 많이 보내면 효율적일까? 하지만 보낼 수 있는 송신자 의 보낼 수 있는 Resource와 받을 수 있는 수신자 의 받을 수 있는 Resource는 한정적이며 각기 다르므로 고정할 수는 없다.

DoS 공격중에 Slowread가 있다. Slowread Attack은 window size를 고의적으로 작게보내어 리소스를 소모하는 공격이다.

Window scale

이론적으로 위의 학습을 기반으로 계산해보자. RTT(Round Trip Time)이 20ms, Window size 65535 bytes 일 경우

bps는 bit per second이므로 Bandwidth는 byte * 8 / ms 의 수식으로 계산할 수 있다.

• byte → bit, ms → sec 변환 : 65535 * 8 / 0.02 (sec) = 524280 bit / 0.02 sec
• 0.02 sec → sec 변환 : 524280 * 50 / sec = 26241000 bit / sec
• 단위 변환 : 25599kbps → 24Mbps

고작 처리량이 24Mbps 뿐이 안나온다. 이는 현대의 속도로는 엄청나게 느린 속도이다. 그래서 Window Scale을 사용한다. Window scale이 8일 경우 2^8 256배율을 갖는다. 고로 높은 속도를 위해서는 Window scale가 필요하다.