동역학적 사고로 보는 컴퓨터 네트워크와 보안 구조

이 포스팅은 네트워크 스택과 웹 애플리케이션을 ‘동역학 시스템’으로 바라보고, 각 층에서 상태 변화와 임계점을 학습한 문서이다. 네 단계에 걸쳐 이론적 설명, 상태 모델 설계, Python 시뮬레이션, 분석 질문을 제시했다. 각 단계는 교차 피드백을 통해 전체 시스템의 안정성과 취약점을 이해하는 데 목적이 있다.

Phase 1 — TCP/IP를 동역학 시스템으로 이해하기

1. 이론: TCP와 소켓 구조

• 3‑way handshake – 클라이언트가 SYN 패킷을 보내 연결을 요청하면 서버는 SYN/ACK로 응답하고, 클라이언트가 다시 ACK를 보내면 연결이 성립한다. 이 과정에서 클라이언트는 CLOSED → SYN_SENT → ESTABLISHED, 서버는 LISTEN → SYN_RECV(half‑open) → ESTABLISHED 상태를 거친다.
• 포트와 소켓 – bind()는 IP/포트로 로컬 주소를 할당하고 listen()은 소켓을 passive 상태로 만들어 클라이언트 연결을 받아들일 준비를 한다. 커널은 두 개의 대기열을 유지하는데, 하나는 아직 핸드쉐이크가 완성되지 않은 half‑open 연결(SYN backlog), 다른 하나는 서버가 accept()를 호출하기 전에 대기하는 established 연결(accept backlog)이다.
• 백로그(queue)의 필요성 – SYN flood 공격은 서버의 half‑open queue를 채워 정상적인 연결을 방해한다. 서버는 제한된 크기의 backlog를 사용하여 무한한 연결 시도를 억제하며 필요에 따라 net.ipv4.tcp_max_syn_backlog나 net.core.somaxconn 등의 파라미터로 조정할 수 있다.
• SYN Cookies – 현대 리눅스는 net.ipv4.tcp_syncookies를 통해 SYN flood에 대응한다. SYN Cookie는 서버가 SYN_RECV 상태를 메모리에 저장하지 않고도 handshake를 완료할 수 있도록 하는 방식으로, 응답 SYN/ACK의 시퀀스 번호에 연결 정보를 암호화하여 클라이언트의 최종 ACK에서 이를 복원한다. 동역학 관점에서 이는 queue 자체를 제거하여 임계점 문제를 우회하는 전략이다.
• 시스템 동영학 방정식 (Governing Equation) - 본 시스템에서 TCP 백로그(Backlog)의 상태 변화는 다음과 같은 1차 선형 미분 방정식으로 표현할 수 있다. 단, 이 식은 $H < H_{\max}$ 영역에서만 유효한 선형 근사이며, $H$가 $H_{\max}$에 도달하면 유입률 $\lambda$가 clamp되면서 비선형 거동이 시작된다.

$$\frac{dH}{dt} = \lambda - \mu H$$

$H(t)$: 시점 $t$ 에서의 SYN_RECV(Half-open) 상태의 연결 수 (백로그 크기)

$\lambda$: 새로운 SYN 패킷의 유입률 (Arrival rate)

μ: 타임아웃 또는 연결 완료에 따른 처리율 (Service rate)

2. 모델링 과제: TCP 연결 상태 머신 설계

아래 표는 TCP 연결의 주요 상태와 전이 조건을 요약한 것이다. 상태 머신 설계 시 각 상태가 특정 이벤트(패킷 수신, 시간 초과 등)에 의해 다른 상태로 이동하는 동역학을 모델링한다.

이 모델을 기반으로 백로그 크기, handshake 시간, 타임아웃을 파라미터로 사용하여 동역학을 시뮬레이션할 수 있다. 서버가 과도한 SYN을 받으면 SYN_RECV 상태가 backlog 상한에 도달하고 새로운 요청을 드롭(drop)하게 된다.

3. 코드 실험: TCP 동역학 시뮬레이션

Python 시뮬레이션에서는 discrete time step을 사용하여 매 스텝마다 새로운 연결 요청이 특정 확률로 도착하도록 모델링했다. half‑open queue와 established queue를 deque로 구현하고, 각 연결은 handshake time 이후 established로 승격되며 hold time 동안 유지된다. SYN backlog 또는 accept backlog가 꽉 차면 해당 연결은 드롭(drop)으로 기록한다. 아래 그림들은 두 가지 시나리오를 보여 준다.

정상 부하 시 동역학

위 그래프는 arrival probability 0.5, half‑open backlog 50, accept backlog 30일 때 half‑open과 established 큐의 개수를 보여 준다. 드롭은 거의 발생하지 않으며 일부 half‑open 상태가 남아있는 정도이다. 이러한 상황에서는 queue와 handshake가 균형을 이루어 시스템이 안정적이다.

SYN flood 시나리오

arrival probability를 1.0으로 높이고 half‑open backlog 3, accept backlog 2로 줄인 경우에는 거의 모든 새 연결이 backlog 한계에 부딪혀 드롭된다. 초록색 선은 cumulative drop 수를 나타내며 시간이 지남에 따라 선형적으로 증가한다. SYN flood 공격자가 half‑open 연결을 채워 backlog 임계점을 넘게 하여 새로운 연결이 거부되는 상황을 잘 보여 준다.

4. 분석 질문

SYN flood는 왜 backlog를 임계점까지 밀어 넣는가? 3‑way handshake에서 서버는 SYN을 받으면 즉시 리소스를 할당하고 SYN/ACK를 전송한다. 클라이언트의 최종 ACK가 오지 않으면 half‑open 상태가 계속 유지되며 queue를 점유한다. 대량의 SYN을 보내고 최종 ACK를 보내지 않는 공격은 backlog를 채워 정상적인 요청을 밀어낸다.

연결이 half‑open 상태에 머무는 이유는? 서버는 클라이언트의 마지막 ACK를 기다리지만 이를 받지 못하면 TCP 타임아웃이 발생할 때까지 SYN_RECV 상태를 유지한다. 타임아웃을 길게 설정하면 half‑open 상태가 오래 지속되어 자원 고갈이 더 쉽게 일어난다.

이는 비선형 붕괴인가? yes. 앞서 정의한 동역학 방정식 $\frac{dH}{dt} = \lambda - \mu H$ 에 따르면, 시스템은 유입량에 따라 선형적으로 반응하는 것처럼 보입니다. 그러나 실제 백로그 큐의 크기가 Hmax에 도달하는 순간, 정상적인 유입률 λ가 강제로 차단되거나 처리율 $\mu$가 급격히 저하되는 불연속적 임계점(Discontinuous Threshold)이 발생한다.

작은 λ 의 증가가 시스템을 평형 상태에서 완전히 이탈시켜 서비스 거부 상태로 몰아넣는 이 현상은 전형적인 비선형 시스템의 임계 전이(Critical Transition) 및 붕괴 모델로 해석할 수 있다.

Phase 1 → Phase 2 연결: TCP에서 backlog 임계점이 서비스 거부를 유발하듯, 상위 계층인 HTTP에서도 상태 관리의 임계점(세션 만료, 로그인 실패 제한)이 시스템 안정성을 결정한다.

Phase 2 — HTTP의 구조적 취약성 이해

1. 이론: Stateless 설계와 상태 유지

• HTTP 요청/응답 – HTTP는 기본적으로 무상태(stateless) 프로토콜이며 각 요청은 독립적이다. 서버는 클라이언트의 이전 상태를 기억하지 않으므로 로그인 및 장바구니 등 지속적인 상태를 유지하기 어렵다.
• 쿠키와 세션 ID – 이 문제를 해결하기 위해 서버는 로그인 응답에서 쿠키를 설정하여 브라우저에 난수 형태의 세션 ID를 저장하고, 브라우저는 이후 모든 요청에 쿠키를 포함해 서버가 동일한 세션임을 인식하도록 한다. 세션 ID는 128비트 이상의 엔트로피를 가져야 하며(OWASP 권장), 해커가 무차별 대입으로 세션을 추측하려면 평균 2^127번의 시도가 필요하므로, 공격 속도가 10 k/s라 하더라도 사실상 무한대에 가까운 시간이 걸린다.
• 서버 측 세션 저장 – 대부분의 웹 프레임워크는 세션 ID를 키로 사용해 메모리나 데이터베이스에 사용자 정보를 저장한다. 세션이 만료되면 ID는 무효화된다. 일정 시간이 지난 세션이나 로그아웃 시 세션을 삭제하는 것은 저장 공간과 보안을 위해 중요하다.

2. 모델링 과제: 로그인 상태 전이 그래프 설계

변수 failed_attempts는 로그인 실패 횟수를, session_timeout은 세션 만료 시간을 나타낸다. 공격자는 본 상태 그래프를 악용해 무차별 대입(브루트포스) 시도를 할 수 있다.

3. 코드 실험: 로그인 무차별 대입 시뮬레이션

아래 그래프는 8자리 비밀번호(문자셋 36가지), 초당 10개의 시도를 가정한 온라인 공격 시나리오로 로그인 공격의 성공 확률을 시간에 따라 나타낸 것이다. (참고: Phase 3에서 다루는 10¹⁰회/초 속도는 해시를 직접 크래킹하는 오프라인 공격 시나리오로, rate limit이 적용되지 않는 상황을 가정한다.) 두 곡선을 비교하면 계정 잠금이 공격자의 성공 확률을 크게 낮추는 것을 볼 수 있다.

• 파란색: rate limit이 없는 경우 누적 성공 확률은 시도 횟수에 정비례하여 증가한다. 비밀번호 공간이 매우 큰 경우 처음에는 확률이 극히 작지만 시간이 충분하면 결국 1에 가까워진다.
• 주황색: 10회 실패마다 1시간 잠금을 적용하면 일정 시간 안에 공격자가 할 수 있는 시도 수가 크게 줄어든다. 로그 스케일에서 보듯 초반 성공 확률이 두세 자릿수 감소하며 실질적으로 공격을 거의 불가능하게 한다.

4. 분석 질문

실패 횟수 제한이 왜 임계 억제 장치인가? OWASP는 계정 잠금을 취약점 완화책으로 권장하며 일반적으로 3–5회 혹은 5–10회 실패 후 일정 시간 잠금하는 것이 좋다고 설명한다. 무차별 대입 공격은 반복적으로 비밀번호를 추측하는 데 의존하는데, 실패 횟수 제한을 두면 공격자의 가능한 시도 수를 선형에서 시분할로 축소해 성공 확률을 기하급수적으로 낮춘다. 이는 앞 단계의 SYN backlog와 유사하게 작은 제어 장치가 시스템의 임계점을 이동시켜 붕괴를 억제하는 효과를 가진다.

로그인 시스템은 어떤 피드백 루프를 가져야 안정한가?

• 적응형 lockout – 실패 횟수가 많아질수록 잠금 시간이 증가하도록 설계하면 공격자가 감행할 수 있는 시도 수를 더욱 줄인다.
• 지연 삽입 – 서버는 각 실패 시도 후 응답을 의도적으로 지연하여 공격자의 시도 속도를 줄인다.
• 알림과 CAPTCHA – 일정 횟수 이상 실패하면 CAPTCHA 같은 추가 인증 단계를 요구해 봇을 차단한다.

이러한 피드백 루프는 상태 머신에 음의 피드백을 도입해 시스템을 안정적으로 유지한다.

Phase 2 → Phase 3 연결: Phase 2의 계정 잠금이 공격자의 시도 속도를 제한하는 장치였다면, Phase 3은 비밀번호 자체의 엔트로피가 공격 비용을 기하급수적으로 높이는 메커니즘을 다룬다.

Phase 3 — 암호학을 에너지 모델로 보기

1. 이론: 해시와 엔트로피

• 해시 함수와 salt – 비밀번호는 평문으로 저장하면 안 되며, salt를 이용한 해시를 저장해야 한다. 각 bit의 엔트로피는 가능한 키 공간을 두 배로 늘리며 해커가 평균적으로 2^(H-1) 번의 시도를 해야 올바른 값을 찾는다. 추가로 salt는 rainbow table 공격을 방지한다.
• 엔트로피와 키 공간 – 엔트로피 H는 가능한 비밀번호 수의 로그2 값이며, 길이 n과 문자 집합 크기 A일 때 H = n × log₂(A)이다. 공격자는 초당 R개의 시도를 할 수 있으므로 성공까지 걸리는 예상 시간은 T ≈ 0.5 × 2^H / R이다. 엔트로피가 1비트 증가하면 가능한 비밀번호 공간이 두 배가 되어 크래킹 시간도 두 배 증가한다.
• Key Stretching (bcrypt, Argon2) – 현대 비밀번호 저장은 단순한 해시+salt를 넘어 bcrypt, scrypt, Argon2 같은 adaptive hash function을 사용한다. 이들은 해시 연산 1회의 비용을 의도적으로 높여 공격자의 실제 시도 속도 R을 수 자릿수로 떨어뜨린다. 동역학 모델 관점에서 이는 처리율 $R$을 인위적으로 낮추는 댑퍼로, Phase 1의 SYN backlog 임계점처럼 작은 제어 장치가 시스템 전체의 공격 난이도를 극적으로 변화시킨다.

2. 모델링 과제: 에너지 모델 식

공격 성공 시간 T는 다음 식으로 근사할 수 있다.

$$T \approx \frac{2^{H}}{2R} = \frac{2^{n\log_{2}A}}{2R} = \frac{A^{n}}{2R}$$

여기서 H는 비밀번호 엔트로피(비트), A는 문자 집합 크기, n은 비밀번호 길이, R은 초당 시도 수이다. 식을 통해 길이가 한 자리 늘어날 때 크래킹 시간이 기하급수적으로 증가함을 확인할 수 있다.

3. 코드 실험: 엔트로피별 크래킹 시간

다음 그래프는 문자 집합 62(대·소문자+숫자)일 때 비밀번호 길이를 4–16까지 늘리면서 두 가지 공격 속도(초당 10^10회와 10^6회)에 대한 예상 크래킹 시간을 계산한 것이다. 로그 스케일로 표시하여 증가 추세가 명확히 보인다.

높은 공격 속도(파란색)에서도 길이가 12–14자 이상이면 기대 크래킹 시간이 천 년 이상으로 상승한다. 낮은 속도(주황색)는 rate limit와 hash 연산 비용을 감안한 값으로, 일반 사용 환경에서 더욱 현실적이다. 여기에 계정 잠금 등 제어 장치를 추가하면 공격자는 사실상 성공할 수 없다.

4. 분석 질문

왜 8자리와 16자리는 질적으로 다른가? 비밀번호 길이가 한 자리 늘어날 때마다 가능한 조합 수가 문자 집합 크기만큼 곱해지므로 비밀번호 공간이 기하급수적으로 확장된다. 8자리 비밀번호(36문자 집합)는 $36^8 ≈ 2^41$개의 조합이지만 16자리 비밀번호는 $36^16 ≈ 2^82$개로 $2^41$배 증가한다. 이는 단순한 선형 증가가 아니라 지수적 증가로, 공격자가 평균적으로 시도해야 할 횟수와 시간도 지수적으로 늘어난다. 따라서 일정 길이 이상에서는 에너지 모델 관점에서 ‘상전이’(phase transition)처럼 공격 성공 확률이 급격히 떨어진다.

이 증가가 선형인가, 상전이인가? 위 식에서 T ∝ A^n이므로 한 자리 증가할 때마다 엔트로피가 additive하게 늘어나지만 시도 횟수는 multiplicative하게 증가한다. 이는 선형적 증가가 아니며, 공격자의 자원이 고정되어 있을 때 어느 길이 이상에서 실질적으로 시도 불가능한 영역으로 넘어가는 상전이 현상이다. 보안 설계자는 이러한 임계점을 고려해 비밀번호 정책을 설정해야 한다.

Phase 3 → Phase 4 연결: Phase 3까지는 인증/암호화 계층의 동역학을 다뤄다면, Phase 4는 입력–출력 경계에서 신뢰 모델 자체가 붕괴되는 사례를 살펴본다.

Phase 4 — 취약점을 신뢰 모델 붕괴로 이해하기

1. 이론: 입력–출력 경계와 신뢰 붕괴

• SQL Injection – 취약한 코드가 사용자 입력을 그대로 SQL 쿼리 문자열에 삽입하면 입력이 데이터가 아니라 코드로 해석된다. 아래 예시처럼 파라미터를 직접 문자열 연결하여 쿼리를 수행하면 공격자가 ' OR 1=1-- 같은 입력으로 인증 우회를 할 수 있다. 안전한 방식은 준비된 구문(prepared statements)이나 파라미터 바인딩을 사용해 입력을 코드와 분리하는 것이다.
• XSS (Cross‑site scripting) – 브라우저는 같은 출처(same‑origin) 정책을 통해 스크립트가 사이트 경계를 넘지 못하도록 한다. 그러나 웹 애플리케이션이 사용자의 입력을 적절히 이스케이프하지 않고 페이지에 삽입하면, 공격자가 악성 스크립트를 주입해 브라우저가 이를 신뢰하여 실행한다. 이는 사용자의 쿠키, 세션 ID 등에 접근할 수 있어 전체 신뢰 체계를 붕괴시킨다.
• SameSite 쿠키 – CSRF 공격을 막기 위한 하나의 동역학적 안정화 장치로, SameSite=Strict는 쿠키가 cross‑site 요청에서 전송되지 않도록 해 세션 탈취를 어렵게 한다. 하지만 다른 방어와 병행해야 한다.
• CSP (Content Security Policy) – XSS 방어의 또 다른 중요한 층으로, 브라우저 레벨에서 허용된 스크립트 출처를 명시적으로 지정하여 인라인 스크립트나 신뢰할 수 없는 외부 스크립트의 실행을 차단한다. 동역학 관점에서 CSP는 스크립트 실행 경로에 추가 검증 단계를 삽입하여, 신뢰 경계가 무너져도 실행 자체를 차단하는 이중 안전장치 역할을 한다.

2. 모델링 과제: 신뢰 경계 모델 설계

SQL Injection과 XSS는 본질적으로 **신뢰 경계(trust boundary)**가 붕괴된 사례이다. 이를 상태 전이 관점에서 모델링하면 다음과 같다:

• Input → Validation → Execution 경로에 대해, 입력이 데이터로써만 처리되면 정상 동작이다. 그러나 검증/정규화 과정이 없으면 입력이 코드로 승격되어 곧바로 실행 상태로 전이되고, 이는 신뢰 경계가 무너진 것이다.
• 대응 상태 – 입력을 검증 후 매개변수화하는 분기와, 검증하지 않고 바로 사용해 취약한 분기를 명시적으로 모델링해야 한다. 이를 통해 안전 경로와 불안전 경로를 구분하고, 어디서 경계가 깨지는지 시각화할 수 있다.

XSS 모델에서는 브라우저가 스크립트를 로드하는 단계에서 출처 확인과 콘텐츠 인코딩을 수행한다. 검증 실패 시 스크립트를 무시하고 경고 상태로 전환해야 하며, 성공 시에만 실행 상태로 넘어간다.

3. 분석 질문

입력 문자열이 왜 코드로 실행되는가? 문자열을 SQL 쿼리에 직접 연결하면 쿼리 파서가 문자열 내부의 구문을 명령어로 해석하기 때문이다. 이는 데이터와 코드를 분리하지 않고 동일한 신뢰 영역에서 처리한 결과이다. 준비된 구문을 사용하면 데이터가 쿼리 템플릿의 매개변수로 전달되어 파서가 구조를 변경할 수 없으므로 신뢰 경계가 유지된다.

브라우저는 왜 스크립트를 신뢰하는가? 브라우저는 기본적으로 서버에서 제공되는 HTML과 스크립트를 신뢰한다. Same‑origin 정책을 통해 다른 도메인에서 제공되는 스크립트는 차단하지만, 애플리케이션이 내부적으로 신뢰하지 않아야 할 입력을 HTML에 삽입하면 스크립트가 같은 출처로 간주되어 실행된다. 따라서 서버는 모든 출력에 대해 적절한 인코딩을 적용해야 한다.

SameSite 쿠키는 어떤 동역학 안정화 장치인가? SameSite 속성은 브라우저가 쿠키를 cross‑site 요청에서 보내지 않도록 제한하여 세션 쿠키가 외부 사이트에 노출되는 것을 막는다. 이는 login session이 다른 사이트로 재사용되는 것을 방지하는 일종의 ‘댐퍼’ 역할을 한다. 하지만 form token, referer 검증 등 다른 대책과 함께 사용해야 한다.

결론: 임계점과 안정화를 통한 통합적 시각

나는 네트워크의 각 층을 동역학 시스템으로 모델링하여 보안 취약점이 어떠한 상태 전이와 임계점에서 발생하는지 탐구했다. TCP에서는 SYN backlog가 포화되면서 작은 증가가 서비스 거부라는 비선형적 결과를 낳았으며, HTTP에서는 무상태 특성 때문에 세션 관리가 필수적임을 확인했다. 암호학에서는 비밀번호 길이 한 자리 증가가 공격 성공 시간을 기하급수적으로 늘려 ‘상전이’와 같은 현상을 보여 준다. 마지막으로 SQLi와 XSS는 입력–출력 경계의 붕괴로 인해 신뢰 모델이 무너지는 사례로 분석하였다.

모델링, 시뮬레이션, 임계점 분석, 그리고 안정화 조건 설계라는 공통의 프레임워크를 통해 시스템의 취약점을 체계적으로 이해하고 설계 변경을 통해 방어할 수 있음을 확인하였다. 이러한 동역학적 접근은 네트워크 보안뿐만 아니라 다른 복잡한 시스템의 안정성 분석에도 확장될 수 있을 거라고 생각한다.