삽질의 정수

1.1. Code Injection - LDAP

LimSeongHyeon — Sun, 22 Feb 2026 23:48:24 +0900

본 게시물은 KISA의 "주요정보통신기반시설 기술적 취약점 분석·평가 방법 상세가이드"를 기반으로 작성된 글입니다. 또한, AI가 작성하지 않았음을 알립니다.

KISA 한국인터넷진흥원

www.kisa.or.kr

1. LDAP(Lightweight Directory Access Protocol) 이란?

LDAP은 디렉터리 서비스에 접근하기 위한 네트워크 프로토콜이다.

여기서 "디렉터리 서비스"라는 워딩은 트리 형태로 정보가 저장되어 있다는 말과 같다고 생각하면 된다.

우리가 일반적으로 생각하는 RDB는 PK를 통해 정보를 찾는다면, 디렉터리 서비스는 "회사 > 개발팀 > 홍길동"과 같이 우리가 파일을 찾듯 정보에 접근하는 구조라고 생각하면 된다.

2. 왜 LDAP을 사용하는가?

여기서 왜 RDB나 다른 데이터 저장 및 접근 방식을 채택하지 않고 LDAP을 사용할까? 라는 의문이 생기게 된다.

일반적인 RDB는 굉장히 범용적으로 설계되어 있다. 복잡한 JOIN을 수행하고, Transaction 처리를 하며, 무결성을 보장하기 위한 여러 장치가 맞물려 돌아가게 된다. 하지만 사용자 인증 정보를 조회하는 것이 이러한 일들이 필요할까?

사용자 인증을 구현한다고 생각해보자.

인증 정보를 읽어와 코드(Application) 수준에서 이를 비교하는 로직으로 구현할 것이다.

이름, 부서, 직위, 직책, 권한 등과 같은 정보들은 가끔 수정될 뿐, 읽기 처리가 대부분일 것이다.

일반적으로 삽입, 수정, 삭제에 의해 무결성에 문제가 발생 되어 RDB는 이를 방지하기 위해 여러 장치를 가지고 있는 것인데, 조회가 대부분이고 관계성도 크게 필요없는 이 상황에서는 RDB 선택이 오버 엔지니어링이 되는 것이다. 추가적으로 단순함으로 인해 유지보수 편의성에 대한 이점도 챙길 수 있다.

또한, RDB와 다르게 LDAP은 트리구조로 이루어져있다.

RDB를 부모-자식 관계로 3 Depth 정도 구성되어 있다고 가정해보자, 이를 가져오려면 3개의 테이블을 JOIN해야 한다. JOIN은 기본적으로 Cartesian Product를 전제하기 때문에 depth 하나당 얼마나 무겁게 동작하는지 대략 짐작이 될 것이다.

반면 LDAP은 트리 형태로 단일 특정이 가능하다는 것이다. 여기서 발생하는 압도적인 읽기 성능 차이가 발생한다.

이러한 LDAP을 한번 잘 구축하게 되면 중앙에서 인증을 관리하면 매우 편하다.

회사에 시스템이 한개라는 보장이 없다. 메일, VPN, 사내 포탈, 사내 형상 관리 등 전부 같은 아이디/비밀번호로 사용하게 구성하면 각 시스템마다 DB 구축해서 만드는 것 보다 LDAP에게 물어보고 처리하는게 훨씬 깔끔한 구조가 된다는 말이다.

정리해보자

내가 생각하기에 LDAP을 사용하는 이유는 크게 3가지다.

인증 로직은 읽기 작업의 비율이 압도적인데 RDB는 오버 엔지니어링이다.
트리구조로 인해 depth에 따른 읽기 성능이 RDB보다 압도적이다.
LDAP을 하나 잘 구축해놓으면 통합 인증 체계를 구성하기 용이하다.

Question

여기서 한 가지 의문이 든다.
최근 같은 이유로 떠오르는 NoSQL로 인증 체계를 만들어도 LDAP이 더 뛰어난 가치를 지닐까?

개인적인 생각으론 NoSQL이 압도적으로 확정성이 편하고 성능에 대한 차이가 굉장히 미비하지 않을까 싶다. 이전에 MongoDB 컨퍼런스에서 사용 사례들을 봤을때 생각보다 RDB에 비해 드라마틱한 성능개선이 가능함을 체감했다.

그럼에도 LDAP을 채택해야 할 이유가 있을까?

Answer

NoSQL로 인증 체계를 만든다는 것이 굉장히 많은 워크로드를 요구하는 작업이다.

데이터 비교만 가능해서 되는게 아니라 패스워드 해싱, 세션 관리, MFA, 토큰 발급/갱신/폐기 등등 제대로 사용하려면 구현해야 할 항목들이 많아진다. 더욱이 사내에서 사용하는 VPN, NAS, CI/CD 등 각 시스템마다 통합 가능한 체계를 직접 구축해야된다는 것이다.

이렇게 만들어진 체계가 보안적으로 안전하다고 확신할 수도 없다.

결론적으로, LDAP이 표준으로 자리 잡은 이유는 기술적 우수성보다 생태계 Lock-in이다. 대부분의 네트워크, 운영체제, 소프트웨어들이 LDAP을 기본 지원하도록 만들어졌다. 새롭게 만들어서 이 모든 것과 호환 가능하게 구현할 자신이 있는가?

기업 입장에서는 그 약간의 성능 향상을 위해 이러한 리스크들을 감수할 이유가 없다.

3. LDAP 구축 및 실습

3.1. Docker Container 생성

docker run -it --name ldap-server -p 389:389 ubuntu:22.04 /bin/bash

3.2. LDAP 설치

LDAP 설치

apt update
apt install -y slapd ldap-utils iproute2 vim
service slapd start

Administrator password: [YOUR-PASSWORD]

LDAP 설정

dpkg-reconfigure slapd

- Omit OpenLDAP server configuration? no
- DNS domain name: example.com
- Organization name: MyLab
- Administartor password: admin1234
- Confirm password: admin1234
- Do you want the database to be removed when slapd is purged? no
- Move old database? yes

설치 확인

slapcat

3.3. LDAP 데이터 삽입 및 테스트

OU(Organizational Unit) 생성

vim /tmp/base.ldif

--------------------------------------------------------------
dn: ou=People,dc=example,dc=com
objectClass: organizationalUnit
ou: People
--------------------------------------------------------------

LDIF(LDAP Data Interchange Format)은 LDQP에 데이터를 넣을 때 사용하는 텍스트 포멧이다. INSERT 문을 담은 .sql 파일이라고 생각하면 된다.

dn: ou=People,dc=example,dc=com은 이 데이터가 트리에서 어디에 위치할지 지정하는 것이다. 해당 경우에는 example.com 아래 People 이라는 디렉터리를 만든다고 이해하면 된다.

objectClass: organizationalUnit은 엔트리의 타입을 지정하는 것이다. LDAP의 모든 엔트리에 타입이 존재해야하고 타입에 따라 속성이 정해진다.

ou: People은 OU(Organizational Unit)의 이름을 People로 설정한다.

ldapadd -x -D "cn=admin,dc=example,dc=com" -w admin1234 -f /tmp/base.ldif

위 명령어는 /tmp/base.ldif 파일을 이용하여 LDAP에 새 엔트리를 추가하라는 명령어이다.

사용자 추가

vim /tmp/users.ldif

--------------------------------------------------------------
dn: uid=hong,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: hong
sn: Hong
givenName: Gildong
cn: Hong Gildong
displayName: Hong Gildong
uidNumber: 10000
gidNumber: 10000
userPassword: pass1234
loginShell: /bin/bash
homeDirectory: /home/hong
mail: hong@example.com

dn: uid=kim,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: kim
sn: Kim
givenName: Cheolsu
cn: Kim Cheolsu
displayName: Kim Cheolsu
uidNumber: 10001
gidNumber: 10001
userPassword: secure5678
loginShell: /bin/bash
homeDirectory: /home/kim
mail: kim@example.com
--------------------------------------------------------------

ldapadd -x -D "cn=admin,dc=example,dc=com" -w admin1234 -f /tmp/users.ldif

사용자 확인

ldapsearch -x -b "dc=example,dc=com" -D "cn=admin,dc=example,dc=com" -w admin1234

인증 테스트

# 성공
ldapwhoami -x -D "uid=hong,ou=People,dc=example,dc=com" -w pass1234

# 실패
ldapwhoami -x -D "uid=hong,ou=People,dc=example,dc=com" -w wrongpass

리스닝 확인

ss -tlnp | grep 389
LISTEN 0      2048         0.0.0.0:389       0.0.0.0:*
LISTEN 0      2048            [::]:389          [::]:*

만약 127.0.0.1:389로만 리스닝 되고 있다면 아래 명령어로 0.0.0.0:389로 리스닝 받을 수 있게 지정해주세요.

service slapd stop
slapd -h "ldap://0.0.0.0:389" -u openldap -g openldap
service slapd start

3.4. Python을 이용한 LDAP 인증 정보 호출

LDAP Python 라이브러리 설치

# windows
pip install ldap3==2.6

# mac & linux
pip install python-ldap

LDAP 인증 테스트 코드

import ldap3

LDAP_SERVER = "ldap://localhost:389"
PEOPLE_DN = "ou=People,dc=example,dc=com"
ADMIN_DN = "cn=admin,dc=example,dc=com"
ADMIN_PW = "admin1234"

def ldap_authenticate(uid: str, password: str):
    server = ldap3.Server(LDAP_SERVER, port=389)

    # 1) 관리자 계정 접속
    admin_conn = ldap3.Connection(server, user=ADMIN_DN, password=ADMIN_PW)
    if not admin_conn.bind():
        print("Failed to bind to LDAP server")

    # 2) uidd와 password로 사용자 검색
    admin_conn.search(
        search_base=PEOPLE_DN,
        search_filter=f"(&(uid={uid})(userPassword={password}))",
        search_scope=ldap3.SUBTREE,
        attributes=["cn", "mail", "uid"]
    )

    if not admin_conn.entries:
        admin_conn.unbind()
        return None

    entry = admin_conn.entries[0]
    admin_conn.unbind()

    return {
        "uid": str(entry.uid),
        "cn": str(entry.cn),
        "mail": str(entry.mail),
    }

if __name__ == "__main__":
    while True:
        uid = input("Enter UID: ")
        password = input("Enter password: ")

        print(f"""
        [USER INFORMATION]
        {ldap_authenticate(uid, password)}
        """)

4. 취약점 분석 및 실습

취약점 포인트

    # 2) uidd와 password로 사용자 검색
    admin_conn.search(
        search_base=PEOPLE_DN,
        search_filter=f"(&(uid={uid})(userPassword={password}))",
        search_scope=ldap3.SUBTREE,
        attributes=["cn", "mail", "uid"]
    )

모든 코드 인젝션 문제는 단순하게도 사용자의 입력을 신뢰하여 일어난다.

해당 코드의 search_filter에 들어가는 입력 값을 이용하여 사용자를 특정하고 있다. 이 filter의 값을 변경하여 질의 자체를 바꿀 수 있다는 점이 LDAP Injection 취약점의 포인트이다.

전체 와일드 카드 사용

(&(uid=*)(userPassword=*))

uid: *
password: *

해당 경우에는 모든 조건이 참이 되어 첫 번째 유저를 반환하게 된다.

Password 와일드 카드 사용

(&(uid=hong)(userPassword=*))

uid: hong
password: *

해당 경우는 uid=hong을 특정하고 비밀번호 검증을 무력화 하게된다.

부분 와일드 카드 사용

(&(uid=h*)(userPassword=*))

uid: h*
password: *

해당 경우에는 h로 시작하는 UID 중 첫 번째를 결과로 가진다. *를 이용해서 substring match를 사용할 수 있다는 의미이다.

반면

(&(uid=hong)(userPassword=p*))

uid: hong
password: p*

userPassword에 p*를 삽입하면 결과가 나오지 않는 것을 볼 수 있다. 그 이유는 userPassword는 기본적으로 equaility match만 허용하기 때문에 단일 와일드카드로 비교하지 않는 이상 참/거짓 유무를 확인할 수 없다.

RFC 4519

그 근거를 찾기위해 우선 userPassword 타입을 확인해봤다.

ldapsearch -x -D "cn=admin,dc=example,dc=com" -w admin1234 \
  -b "cn=Subschema" -s base "(objectClass=subschema)" attributeTypes \
  | grep -i "userpassword"

RFC 4519를 확인해보니 Section 2.41에 기재되어 있다.

https://www.rfc-editor.org/rfc/rfc4519.txt

여기서 userPassword에 EQUALITY octetStringMatch만 존재하는 것을 확인할 수 있다. 만약 우리가 원하는 Substring이 가능하려면 아래 사진과 같이 SUBSTR라는 항목이 존재해야 한다.

만약 LDAP Injection을 통해 Blind Injection 가능 여부를 판단할 때, 추측되는 attribute type이 SUBSTR 특성을 지니고 있는지 확인해보면 될 것 같다.

정리해보자!

와일드카드(*)를 이용하면 단일 조회의 경우 첫 번째 결과를 가져온다.
이는 LDAP의 절대적인 특성이 아니라 일반적으로 코드 수준에서 이와 같이 구현한다. ex) conn.entires[0]
와일드카드(*)를 이용하여 substring match로 사용이 가능하다.
userPassword 처럼 substring match가 아닌 equaility match만 가능한 attribute들이 존재한다. 이러한 경우 와일드 카드로 blind injection을 통해 값을 직접적으로 알아내는 것은 어렵다.

5. 대응방안

자 그럼 가장 중요한 대응방안에 대한 이야기이다.

5.1. 관리자 바인드로 이스케이핑된 UID 검색

    safe_uid = ldap3.utils.conv.escape_filter_chars(uid)
    admin_conn.search(
        search_base=PEOPLE_DN,
        search_filter=f"(uid={safe_uid})",
        search_scope=ldap3.SUBTREE,
        attributes=["cn", "mail", "uid", "dn"]
    )
    
    if not admin_conn.entries:
    admin_conn.unbind()
    return None

    user_dn = admin_conn.entries[0].entry_dn
    admin_conn.unbind()

uid의 값은 바로 신뢰하지 않고 이스케이프하여 할당하고, uid와 password를 동시 조건으로 사용하는 것이 아니라 분리하여 검증한다.

5.2. 사용자 DN으로 바인드 및 password 검증

    user_conn = ldap3.Connection(server, user=user_dn, password=password)
    if not user_conn.bind():
        return None

    user_conn.unbind()
    return {"uid": uid, "dn": user_dn}

위에서 찾은 DN과 password를 이용하여 직접 바인드를 시도하여 로그인 성공 여부를 확인한다.

해당 조치 방안은 다음과 같은 효과를 갖는다.

uid에 대한 값은 이스케이핑 처리되어 이스케이프 함수에 제로데이가 발견되지 않는 이상 신뢰 가능하다.
패스워드가 검색 필터에 들어가지 않으므로 패스워드 필드에 대한 인젝션 경로가 완전히 차단된다.
LDAP 서버의 bind를 이용하여 해시 비교와 계정 정책등을 자체 처리할 수 있다. (이미 잘 구현되어 있는 기능을 가져다 쓰므로 인증 로직에 대한 휴먼 에러를 줄일 수 있다.)
평문 패스워드가 검색 필터 문자열로 노출되지 않는다.
LDAP 서버에 어떤 필터로 요청이 왔는지 로그를 남기고 있다고 가정해보자. 필터에 비밀번호 평문이 포함되면 LDAP 서버에 사용자 비밀번호 평문이라는 민감한 정보가 로그에 남게 된다.
반면, LDAP bind 요청은 credentials 필드에 담겨 전송되기 때문에 LDAP 서버에서 로그로 기록하지 않는다.

만약 세상이 녹록치 않아 이러한 대응방안을 적용할 수 없다면, 입력값에 대한 이스케이핑 처리라도 적용해야 한다.

safe_uid = ldap3.utils.conv.escape_filter_chars(uid)
safe_pw = ldap3.utils.conv.escape_filter_chars(password)

admin_conn.search(
    search_base=PEOPLE_DN,
    search_filter=f"(&(uid={safe_uid})(userPassword={safe_pw}))",
    search_scope=ldap3.SUBTREE,
    attributes=["cn", "mail", "uid"]
)

6. 트러블 슈팅

6.1. session terminated by server

해당 경우는 Docker 컨테이너 내부에서 LDAP 서비스가 꺼져있을 확률이 크다.

docker exec -it ldap-server /bin/sh
service slapd start

위와 같이 컨테이너에 service slapd start 명령어를 수행해주도록 하자

7. 후기

코드 인젝션에 옛날 고조선 시대에 사용했을 법한 스택들이 모여있어서 마주하는 것을 미루어왔다. 최근에 필요한 SSTI 정도만 공부했는데 이참에 최신화된 주통기를 보면서 하나씩 정리할 예정이다.

사실 입사 면접을 보는데 당당하게 코드인젝션에 대한 진단도 가능할거라 자만하고 답했는데, 이젠 잘 안나오는 옛날 코드 인젝션들도 진단 가능한거냐고 물어보셔서, 잘못 대답한 것 같다고 정정 했었다.

당당하게 할 수 있다고 대답한게 부끄러워서 지금이라도 공부한다...

VMWare Interface IP 재부여

LimSeongHyeon — Mon, 8 Sep 2025 14:26:02 +0900

실습하는 중에 VMWare에 사용할 이미지가 인터페이스 자체에 IP를 고정 등록해버려서 아무리 네트워크 세팅을 바꿔도 변경되지 않는 문제가 있었다. 혹시 host-only로 바꿨음에도 호스트에서 ping 조차 도달하지 않고 ssh 접근 안될 때 참고하면 좋을 것 같아 작성해둔다.

1. status 확인

$ nmcli dev status

2. 잘못된 연결 분리

$ nmcli dev disconnect eth1
$ nmcli dev status

3. 인터페이스 프로파일 생성

$ nmcli con add type ethernet ifname eth1 con-name hostonly208 \
  	ipv4.addresses 192.168.208.100/24 \
  	ipv4.method manual \
  	ipv4.never-default yes \
  	connection.autoconnect yes

4. 프로파일 활성화

$ nmcli con up hostonly208

VMWare 공유폴더 설정

LimSeongHyeon — Mon, 8 Sep 2025 13:31:01 +0900

실습 중 파일을 centOS로 옮겨야 하는 상황이 빈번하게 발생해서 공유폴더를 만들어 두고 공용으로 참조 가능하게 만들기 위해 설정하는 방법을 찾아서 정리해보았다.

환경

VMWare Workstation
Host: Windows 11
VM: centOS 7

1. VMWare 설정

Settings > Options에 가보면 Shared Folders가 있다. 여기서 원하는 디렉토리를 등록하고 Always enabled로 바꿔주면 된다. 이때, 간혹 한글 경로가 문제되는 경우가 있으므로 영문 경로를 참조할 수 있게 해주자.

2. VMWare Tools 설치

$ yum install -y open-vm-tools open-vm-tools-desktop
$ systemctl enable --now vmtoolsd

VMWare Tools를 설치해야 머신 내에서 공유 폴더에 접근할 수 있다.

3. 수동 마운트

$ vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other

바로 마운트가 적용되지 않는 경우가 많아서 수동 마운트로 직접 마운트 시켜주도록 하자.

4. 결과

/mnt/hgfs에 적용했던 shared 디렉토리가 나타난 것을 확인할 수 있다. 나는 심볼릭 링크를 통해 root에서 접근 가능하게 사용하고 있다.

5. 심볼릭 링크

$ ln -s /mnt/hgfs/shared /shared

1. Pre-engagement Interactions

LimSeongHyeon — Fri, 1 Aug 2025 13:36:32 +0900

본 게시물 PTES(http://www.pentest-standard.org)의 내용을 기반으로 작성됩니다.

The Penetration Testing Execution Standard

High Level Organization of the Standard The penetration testing execution standard consists of seven (7) main sections. These cover everything related to a penetration test - from the initial communication and reasoning behind a pentest, through the intell

www.pentest-standard.org

Preview

실제 테스트 시작 전 모든 사항을 명확히 정의하고 계약을 수립하는 단계이다. 계약 내용에 내포되어야 할 사항들과 고려해야할 사항들을 PTES에서 명시해주고 있다. 해당 항목들은 세계에서 가장 성공적인 침투 테스터들의 수년간 경험을 결합한 결과라고 한다.

Introduction to Scope

네트워크 접근을 위한 다양한 도구와 기법에 대해서는 정말 많은 자료들이 존재한다. 하지만 침투 테스트 이전 단계인 Preparation 에 대한 내용은 거의 찾아볼수가 없다. 이 사전 준비 활동을 제대로 완료하지 않으면 Scope Creep (범위가 계속 확장되는 문제), 목적 및 기대치 불일치에 대한 고객 불만족, 허가받지 않은 영역에 대한 테스트로 인한 법적 문제와 같은 문제를 발생시킬 수 있다.

Scope를 정의하는 것은 결국 "무엇을"테스트 할 것인가를 정의하는 것이다. 가령 내가 Scope에 정의되지 않은 영역을 테스트했는데 실제 장비들이 오동작을 일으키는 문제를 범했다. 그런데 그 장비들이 의료장비라고 생각해보자. 법적 문제를 회피할 수 도, 감당할 수 도 없을 것이다. 결국 불미스러운 상황에 대해 테스터와 고객의 책임소지를 명확히 하는 장치 중 하나가 될 것이다.

Scope에 대해 테스터들이 어떻게 시간을 분배하고 사용하는지 작성되어야 한다. 침투 테스트는 본질적으로 시간 기반 서비스이다. 무작정 테스트 하는 것이 아니라 어떤 스코프에 얼만큼의 시간을 배분할 것인지 명시되어야 한다. 하지만 결코 시간으로만 비용 측정이 불가능한 상황도 존재한다. 때문에 단위 가격에 대한 설정이 존재해야 한다.

예를들어 고객이 100개의 IP주소를 1,000만원의 가격으로 테스트 해달라고 요청한다면 결국 IP 주소 하나당 10만원을 제공한다는 의미이다. 절대적으로 1개의 IP 주소에 대한 노동력이 모두 동일할 순 없지만, 이런 단위체계가 존재해야 고객과 공급자 모두에게 명확한 가격 구조를 형성하게 될 것이다.

그럼 이러한 의문을 갖게 될 것이다. "아무리 명확한 가격 구조를 형성하게 된다해도 특정 IP에 들어있는 서비스의 복잡도가 매우 높으면 작업량이 너무 달라지는 것 아닌가?". 이런 의심처럼 Scope에 대한 선형적인 가격 측정은 특정 Volume에 대해서만 효과적이다. 특정 지표가 결코 작업량을 대체하는 단위가 될 수 없다. 이런 단위 불일치는 결국 이 서비스에 대해 저가 책정하게 되고, 불완전한 작업을 하게하는 동기를 유발한다.

이때 이러한 비즈니스에서 발생할 수 있는 문제점은 "고객이 이 Scope 책정에 대해 납득할 수 있는가?"이다. 테스터들은 같은 IP여도 복잡도와 작업량이 크게 달라진다는 것을 인지한다. 심지어 어떤 작업에서는 기하급수적인 작업량이 필요해짐도 유추할 것이다. 하지만 과연 고객도 그렇게 생각할 수 있을까?. 사실상 이러한 기술적 지식 차이로 인한 의사소통 문제를 해결하기 위해 컨설턴트가 존재한다고 생각한다. 그리고 이 소통에 대한 이해를 바탕으로 문서가 작성되어져야 하는 것이다.

다시 돌아와서 이 모든 내용을 정리하자면, 모의 침투는 자선 사업이 아니다. Scope를 커버하기 위해서는 노동력이 필요하고 이는 곧 가격이된다. 그럼 이 Scope를 어떻게 정의해야 하는가? 선형적인 단위만으론 측정할 수 없고 각 항목에 대한 좀 더 자세한 복잡도로 인한 노동력 산출 작업이 필요하다. 하지만 고객은 이러한 복잡도 산출에 대해서 이해하지 못할 수 있다. 때문에 이를 이해시키고 가이드 해주는 것이 결국 테스터의 일 중 하나이기도 하다. 이 때 테스터는 Deep dive와 Wide Scan 사이에서 고객의 목적에 맞는 Scope를 설정하고 계약 과정에서 이 사실을 망각하지 않아야 한다.

Metrics for Time Estimation

이제 위에서 범위를 산출했다면 해당 범위들을 테스트하기 위한 시간을 정해야 한다. 경험이 많은 테스터라면 직감적으로 얼마나 오래 걸릴지 판단할 수 있겠지만, 그렇지 않다면 이전에 수행한 유사항 테스트의 이메일이나 스캔 로그들을 검토하고 시간 요구사항을 추정하는 것이 좋다. 이 때 반드시 추정시간 안에 끝낼 수 있으리란 보장이 없기 때문에 20% 정도를 패딩(Padding)한다.

패딩은 모든 테스트에 절대적으로 필요하다. 테스팅 과정에서 방해가 발생할 경우를 대비한 완충 역할을 한다.예를들어, 네트워크에서 중대한 취약점이 발견되어 이를 해결하기 위해 여러 권한자와 회의가 필요할 수 있다. 테스터의 업무적 의지와는 별개로 많은 시간을 소모할 수 있다는 의미이다. 이로 인해 반드시 패딩을 추가하여 예상치 못한 사항에 대해 완충할 수 있도록 하여야 한다.

하지만 패딩된 시간으로 넘어가지 않고 산출했던 시간안에 모든 분석이 끝나게 되면 어떻게 해야할까?. 고객은 패딩된 시간적 금액까지 금전적으로 지불하게 된다. 만약 패딩된 시간을 사용하지 않는다면 고객은 아무것도 제공되지 않는 시간에 대한 비용을 지불한 셈이 된다. 때문에 보안팀 혹은 개발팀에게 악용하기 위해 취한 단계를 설명해준다던가, 원래 제공 목록에 포함되지 않았던 경영진 요약 보고서를 작성해준다던가, 스코프 내에서 부가적인 취약점들을 해결하려고 시간을 더 사용한다던가 등의 추가적인 가치를 제공하는 것 까지가 테스터들의 몫이다.

마지막으로 모든 프로젝트에는 명확한 마감일이 있어야 한다. 테스팅이 종료되는 날짜에 도달 했거나, 그 날짜를 넘겨 추가 테스팅이나 작업이 필요한 경우에 반드시 작업과 소요 시간 그리고 서명된 작업 명세서가 있어야 한다. 일부 테스터들은 고객에게 추가 비용을 요구하면 돈에 너무 집착하는 사람으로 보일까 걱정하고 이로인해 추가적인 계약서를 작성을 요구하길 꺼려한다. 하지만 pentest-standard의 저자에 의하면 경험상 주요 테스트에서 좋은 가치를 제공한다면 고객은 비용 지불을 거부하지 않을테니 걱정할 필요가 없다고 한다.

Scoping Meeting

범위 설정 회의는 대부분 계약서를 체결한 후에 열리게 된다. 범위와 관련된 내용들 자체가 고객의 비밀이고 법적 문제가 발생할 소지가 있기 때문이다. 때문에 불가피하게 범위 설정 회의를 먼저 진행해야 한다면 비밀유지협정(NDA)을 체결하는 것이 중요하다.

다시 돌아와서, 범위 설정 회의의 목적은 "무엇을 테스트 할 것인가?"이다. 지금까지도 무엇(What)에 대해 이야기 해놓고 이게 또 무슨 소린가 싶다. 여기서 중요한건 테스트 수행 규칙이나 비용에 대한 이야기는 해당 회의에서 다루지 않는다. 온전히 범위에 대한 이야기만 다루고, 나머지에 대한 금액적, 수행 규칙에 대한 내용은 별도로 논의하는것이 바람직 하다. 여러 주제를 함께 논의하면 이 범위 설정에 대한 핀트가 혼돈이 생길 수 있기 때문이다.

프로젝트의 대략적인 규모(ROM)가 정해졌으면 고객과 만나서 시스템의 구조들에 대해 세운 가정들이 맞는지 확인해야 한다. 특히 중요한 사항은 어떤 IP 대역이 테스트 범위에 포함되는지 명확히 해야한다. 간혹 고객들은 테스트를 현실적으로 만들기 위해 "테스터가 알아서 알아내고, 알아서 침투해야죠"라는 태도로 말하기도 한다. 물론 그렇게 하면 이상적이지만 그럴수 없는 이유가 크게 두가지가 있다.

하나는 법적 책임이다. 범위를 정하지 않고 침투함으로써 실제 서비스에 큰 문제가 생기게 된다면 테스터는 면책을 증명할 방법이 없다. 말을 그렇게 했으나 서면으로 작성되어 있는 사항이 아니니 고객이 "그렇게까지 할거라고 이야기 하지 않았잖아요!"라고 하면 책임을 피할 방법이 없는 것이다. 특히 개발자나 엔지니어에게 자신의 설계에 문제가 있음이 커리어에 크게 문제되거나 책임을 피하지 못할거라는 생각 때문에 비협조적인 경우도 있다. 때문에 범위를 규정한 내용의 계약서는 테스터를 보호하기 위한 가장 효력있는 수단이 될 것이다.

하나는 시간도 자원이라는 점이다. 실제 해커들은 이런 계약 관계처럼 시간을 지정하고 행하지 않는다. 만약 몇 년을 걸쳐 취약점 분석을 진행할 대규모 프로젝트이고, 그만큼 금전적인 보상도 충분히 이루어 진다면 당연히 문제되지 않을 것이다. 하지만 대부분 그렇지 않다. 테스터는 실제 해커보다 훨씬 제한된 시간 안에 최대한 많은 취약점들을 찾아야 한다. 대상 시스템이 어느 나라에서 운영되고 있고, 백업 서버는 어디에 몇개가 있고, 실제 하드웨어와 방화벽, IDS, IPS 솔루션은 어떤걸 소유하고 운용중이고, 각 관리자 마다 접근할 수 있는 범위는 어디까지이고, 실제 코드 백업 전략은 어떤 것을 사용하고 있고 등등 모든것을 확인하기에는 시간이 너무 오래 걸릴 것이다.

결국 테스터와 고객 모두 "레드티밍"인지 "모의해킹"인지 구분을 명확히하여 범위를 지정해야 된다는 말이다. 대다수의 외부 테스터에게 의뢰하는 내용이 레드 티밍일 확률이 적다. 고객이 이러한 구분히 명확할 확률이 낮기에 테스터는 이를 이해시키고, 함께 범위를 지정해야 한다. 결국 고객은 금전적인 비용을 지불하고 테스트를 받는 것이기 때문에 이 비용이 아깝지 않게 테스터에게 범위를 지정하고 필요하다면 권한에 대한 부분도 고려해야 한다. 동시에 테스터는 이 범위 지정으로 인해 법적 책임으로부터 자유로워 질 수 있다.

Additional Support Based on Hourly Rate

테스터가 과연 고객과 모든 업무 범위에 대해서 빠짐없이 서면으로 규정할 수 있을까? 모든일이 그렇듯 당연히 불가능 할 것이다. 언제나 항상 예외가 발생할 것을 염두해 두어야 한다. 이 파트에선 왜 임의로 테스트를 하면 안되는지에 대한 두 가지 이유와 그럼 어떻게 해야할지를 살펴보자.

첫번째 이유는 범위 확장(Scope Creep) 때문이다. 위에서도 언급했지만, 범위가 확장되면 자원이 소모되어 테스터의 수익을 깎게되고 이러한 부정적인 동기가 결과물에 영향을 줄 가능성이 높다. 이로 인해 고객은 결과에 대해 불만족할 확률이 높아진다. 결국 테스팅도 하나의 비즈니스이기 때문에 고객 만족도를 관리할 필요가 있다. 이런 부정적인 동기부여는 사실상 고객 만족도도 비즈니스 평판도 깎아내리는데 일조할 것이다.

두번째 이유는 법적 책임이다. 많은 임시 요청들이 제대로 문서화 되지 않아 법적 분쟁이나 조치에 대해서 정당성을 입증하기 굉장히 곤란스러운 상황에 처하곤 한다. 누가 무엇을 말했고, 어떤것을 요구했고 받아들여 졌는지 그 무엇도 입증할 수 없다. 더군다나 계약서에는 수행할 작업을 명시하는 법적 문서이자 허가증이다. 객관적으로 이런 상황에서 테스터의 손을 들어줄 확률이 매우 낮아지게 된다.

사실 위 스코프 설정에 관한 이야기에 포함된 내용이기도 하고 계속 반복되는 느낌이 있지만 사실 굉장히 중요하다. 우리는 윤리적인 테스트를 하는 사람들이지 일방적인 수사를 하는 사람들이 아니다. 때문에 원래 범위를 벗어나는 모든 요청을 수행할 작업들을 명확하게 식별할 수 있도록 작업명세서(SOW) 형태로 문서화 해야하고, 추가 작업 또한 시간당 고정 요금으로 진행하여 상호간의 서명 없이는 추가 작업을 진행할 수 없음을 계약서에 반드시 명시해야한다.

고객이 "하는김에 이것도 조금 봐주시면 안될까요?"하는 요청들을 좋은 마음에 문서화 없이 넘어가서는 절대 안된다는 말이다.

Questionnaries

이제 테스터가 고객의 요구사항을 파악하기 위해 해야할 질문(질문 내용이 아닌 질문하는 행위 그 자체)에 대해 다뤄보려고 한다. 많은 테스터들이 기술적인 부분에 집중하여 이 단계를 소홀히 하곤 한다. 하지만 이 질문들이 고객이 원하는 목표를 명확하게 할 수 있는 유일한 방법이다.

고객과의 첫 미팅에서 던져야 할 핵심 질문들이 있다. 단순히 체크리스트를 채우는 것이 아니라 고객의 진짜 의도를 파악하기 위해서 말이다. "침투 테스트를 왜 하려고 하시나요?"라는 질문 하나로 프로젝트의 방향이 어느정도 정해지게 된다. 컴플라이언스 때문에 어쩔 수 없이 하는 고객도 있을 것이고, 실제로 시스템들이 얼마나 안전한지 확인하고 싶은 고객도 있을 것이다. 같은 침투 테스트도 이 두 목적은 전혀 다른 접근 방식을 요구한다.

만약 "컴플라이언스 만족"을 위해서라면 체크박스를 채우는 형식적인 테스트가 될 가능성이 높다. 하지만, "실제로 얼마나 안전한지"를 확인하기 위해서라면 좀 더 깊이 있고 실질적인 보안 검토가 필요할 것이다. 테스터 입장에서도 같은 시간과 노력을 투입하더라도 이러한 방향성에 따라 시간 분배를 달리 해야하고 이로인해 결과의 질이 달라질 수 밖에 없다.

여기서 주의할 점은 고객 스스로도 자신이 정확히 어떤 테스트를 해야할지 모르는 경우가 많다는 것이다. "그냥 해킹 당하는지 확인해주세요."와 같은 말을 하는 고객이 많다는 이야기이다. 때문에 이러한 장르를 결정할 수 있도록 테스터는 컨설턴트의 입장에서 접근해야 한다. 네트워크 침투 테스트를 원하는건지, 웹 애플리케이션 테스트를 원하는건지, 물리적 보안까지 포함한 종합 테스트를 원하는건지 말이다.

질문은 결국 소통의 도구이다. 기술적 전문성도 물론 중요하다. 하지만 고객이 진짜 필요로 하는 것이 무엇인지, 혹시 고객이 자신의 목적을 잘 모르고 있는 것은 아닌지에 대해 확인하고, 설명하고, 솔루션을 제시할 수 있는 자세가 필요하다. 그리고 그것을 빠짐없이 확인하기 위해 이러한 질문하는 시간이 필요한 것이다.

General Questions

그럼 질문하는 행위가 중요하다는 것을 알았으니 이번에는 그럼 구체적으로 어떤 질문들이 왜 필요한지에 대해서 다뤄보려고 한다. 모든 질문들은 PTES의 General Questions에서 확인이 가능하다. 이번 색션에서는 모든 질문을 다루는 것은 아니고 특히 필요한 내용만 다루도록 한다.

"언제 테스트를 하시겠습니까?"

이 질문은 당연해 보이지만 여기에 사실 꽤나 많은 인과가 담겨있다. 업무 시간중에 하면 실제 운영 환경에서의 반응을 확인할 수 있지만, 서비스에 영향을 줄 위험이 있다. 반면, 업무 시간 외에 하면 안전하지만 평상시와 다른 환경에서 테스트를 하게된다. 특히 금융권이나 의료 시설 같은 곳에서 이러한 문제가 생긴다고 생각해보자. 평범한 손해에서 그치지 않을 것이다. 그럼, 그 책임을 누가 질 것인가?. 때문에 이러한 사실을 사전에 확인할 필요가 있다.

"방화벽, IDS/IPS, WAF, 로드 벨런서와 같이 침투 테스트 결과에 영향을 줄 장비가 있습니까?"

앞서 침투 테스트는 시간 기반의 서비스임을 설명했었다. 이러한 침투 테스트에 대한 결과에 영향을 주는 장비가 있는데 이를 모르고 테스트를 시도한다고 생각해보자. 끝없는 시행착오를 반복하며 해당 장비들이 있는지 없는지를 확인하는 행위에 굉장히 많은 시간을 쏟아야 할 것이다. 정해진 기한동안 정해진 비용으로 테스트를 진행하는데 해당 행위에서 시간을 낭비하게 된다면 고객도 테스터도 손해인 상황이 발생하게 되는 것이다. 때문에 사전에 이러한 장비들이 있는지 확인할 필요가 있다. 그리고 전달받지 못한 장비들로 인하여 지연이 발생할 수 있음을 사전에 고지해야 한다.

"소스코드나 시스템에 대한 문서 제공이 가능합니까?"

어떻게 보면 위 질문에 가장 좋은 케이스가 될 수 있는 질문이다. 잘 정리된 소스코드나 시스템에 대해서 제공받으면 테스터는 해당 내용을 파악하는 시간을 획기적으로 줄일 수 있다. 이 말은 테스터가 자원 식별 및 분석하는 시간을 아끼고 취약점 분석에 많은 시간을 투자할 수 있음을 의미한다.

이러한 자원을 받아서 테스트를 진행하는 것이 반드시 옳은 방법은 아니다. 특정 상황에서는 내부 구조를 알지 못하고 테스트를 진행하는 것이 목적에 맞을 수 있다. 하지만, "줄 수 있지만, 의도적으로 목적을 위해 주지 않는 것"과, "주는 것이 좋은 결과를 만들지만, (유출 등과 같은 이유로)찝찝해서 주지 않는 것"은 전혀 다른 결과를 가져온다는 말이다. 고객에게 이러한 장단점을 잘 이해시키고 좋은 결정을 하도록 만드는 것도 결국 테스터의 몫이다.

"어디까지 확인이 필요하십니까?"

쉘을 획득했을 때 root 권한까지 획득할 것인가?, 패스워드와 같은 해시값을 발견하면 키크랙을 시도할 것인가?, 데이터베이스 접근이 확인되면 데이터베이스 조작 및 권한 획득도 가능한지 확인할 것인가?와 같이 침투 테스트의 상한선을 지정할 필요가 있다. 또한 퍼징이나 DoS와 같은 시스템 부하가 발생할 수 있는 작업들을 허용할 것인지에 대해서도 논의가 이루어져야 한다. 지금까지 이야기와 마찬가지로 논의되지 않고 임의로 시도했을때 책임 소지는 온전히 테스터에게 있으므로 반드시 논의되어야 하는 내용이다.

결국 이런 질문들은 단순 정보 수집이 아니라 "고객과 테스터간 기대치 조율", "고객과 테스터간 지켜야할 법적 증거를 만드는 지표", "테스터가 테스트 해야할 방향성"을 제공해주는 지표가 되는 것이다.

Scope Creep

PTES에선 범위 확장(Scope Creep)은 침투 테스팅 회사를 파산시키는 가장 효율적인 방법 중 하나라고 표현하고 있다. 많은 회사와 관리자들이 이를 식별하는 방법이나 발생했을 때 어떻게 대응해야 하는지에 대해 대부분 모르고 있다.

"이것도 한 번 봐주시면 안될까요?" 이런 말을 듣다 보면 어느새 원래 계약보다 두 배, 세 배의 작업을 하고있게 된다는 것이다. 고객이 추가 작업을 요청하는 것은 사실 좋은 신호다. 해당 작업에 만족하고 서비스를 더 받고싶다는 의미이기 때문이다. 하지만 여기서 "서비스 정신"을 발휘해서 "그 정도는 그냥 해드릴게요"라고 하는 순간 당연한 서비스가 된다는 것이다. 특히 한국의 비즈니스 문화에서는 이런 일들이 많이 발생한다는 것이다.

여기서 딜레마는 기존 고객과의 관계는 정말 소중하다는 것이다. 새로운 고객을 들이기 위해서는 영업 비용, 제안서 작성 비용, 신뢰 구축 등 많은 시간적, 금전적 자원이 들어가게 되는 것이다. 그럼 어떻게 기존 고객과 유대감을 유지하며 이러한 범위 확장을 막을 수 있을까?

가장 근본적이게도 처음부터 명확하게 선을 긋는 것이다. 기존 범위에 포함되지 않는 작업이기 때문에 추가적인 보상을 요구해야 한다는 의미이다. 다만, 기존 고객에 대해서는 가격을 낮게 유지하는 것이 좋다. 기존 고객에 대한 작업으로 나오는 소스들은 새로운 고객을 유치할 수 있는 가장 좋은 자료가 될 뿐더러 이러한 좋은 결과물로 반복적인 비즈니스를 산출할 수 있을 것이다.

아마 대부분 이런 경험이 있을 것이다. 가족들과 함께 계곡에서 행복한 추억을 만들기 위해 추억을 쌓고 밥을 먹으려는데 음식의 가격이 부당하게 비싸다고 느껴진 경험 말이다. 계곡에 다시 가고 싶은가? 계곡에 간 근본적인 이유는 놀며 행복한 추억을 만들기 위함이였고 그 목적을 달성 했다. 그럼에도 불구하고 음식점 가격이 높아 다음엔 가고 싶지 않아진다. 좋은 상황을 이용해 폭리를 취하게 된다면 반복 비즈니스를 무너뜨리는 계기가 될 것이다. 우리는 어떤 음식점이 되어야 하는가?

Specify Start and End Dates

범위 확장을 방지하는 다른 중요 요소는 시작일과 종료일을 명시적으로 지정하는 것이다. 프로젝트가 명확한 끝을 가질 수 있어야 한다. 그럼에도 불구하고 일자 조정이 어려운 흔한 이유가 뭘까? 흔히 실수하는 항목이 재테스트 기간이다. 재테스트는 계약 시 좋은 조건처럼 느껴진다. "취약점을 발견하고 조치하시게 되면 재테스트 해드리겠습니다."라고 자신 있게 말하면 책임감 있는 회사처럼 생각하게 될 것이고, 새로운 고객을 확보하는데 많은 도움이 될거라고 생각한다. 혹은 테스팅 회사가 제안하지 않더라도 고객이 이러한 제안을 먼저 할 수도 있다. 이러한 재테스트가 왜 문제인지 생각해볼 필요가 있다.

고객에게 테스팅을 진행한 후 확인된 취약점을 알려 주었다. 고객이 취약점을 받아 패치를 하는데 2주가 걸렸다. 그래서 재테스트를 했더니 문제가 발견됐다. 고객이 취약점을 받아 패치를 하는데 2주가 걸렸다. 그래서 재테스트를 했더니 문제가 발견됐다... 당신은 재귀함수 이야기를 아는가?

어느 한 컴퓨터공학과 학생이 유명한 교수님을 찾아가 물었다. "재귀함수가 뭔가요?"

"옛날 옛날 한 산 꼭대기에 이 세상 모든 지식을 통달한 선인이 있었어. 마을 사람들은 모구 그 선인에게 수많은 질문을 했고, 모두 지혜롭게 대답해 주었지. 그의 답은 대부분 옳았다고 하네. 그런데 어느 날, 그 선인에게 한 선비가 찾아와서 물었어"

"재귀함수가 뭔가요?"

"옛날 옛날 한 산 꼭대기에 이 세상 모든 지식을 통달한 선인이 있었어. 마을 사람들은 모구 그 선인에게 수많은 질문을 했고, 모두 지혜롭게 대답해 주었지. 그의 답은 대부분 옳았다고 하네. 그런데 어느 날, 그 선인에게 한 선비가 찾아와서 물었어"

이래도 당신은 재테스트를 무료로 제공할 것인가? 결국 명확한 시작일과 종료일을 정하는 것은 우리 자신을 보호하는 일이다. 동시에 고객에게도 명확한 기대치를 제공하는 일이기도 하다. "언제 테스트가 끝나나요?"에 대한 답을 명확히 할 수 있어야 함과 동시에 달콤해보이는 조건에 현혹되어 재귀함수에 빠지지 않아야 한다는 말이다. 재테스트는 서비스가 아닌 별도의 프로젝트임을 명심해야 한다.

Specify IP Ranges and Domains

Dealing withThird Parites

Define Acceptable Social Engineering Pretexts

Dos Testing

Payment Terms

Goals

Establish Lines of Communication

Emergency Contact Information

Rules of Engagement

Capabilities and Technology in Place

0. 훑어보기

LimSeongHyeon — Fri, 1 Aug 2025 09:36:17 +0900

하드웨어

디스크 스케줄링 알고리즘

SCAN (순차 검색)	한 방향으로 모든 요청을 처리한 다음, 반대 방향의 모든 요청을 처리한다. 엘레베이터 알고리즘으로도 불리며 디스크 암으로부터 가장 멀리 떨어진 요청이 Worst Case가 된다.
SSTF (최단 탐색 시간 우선) Shortest Seek Time First	디스크 암이 현재 위치에서 가장 가까운 요청을 처리한다. 평균 탐색 시간을 최소화하지만 디스크 암으로부터 가장 멀리 떨어진 요청이 계속 대기되는 현상이 발생할 수 있다.
C-SCAN (원형 순차 검색) Circular SCAN	한 방향으로 모든 요청을 처리하고 반대편으로 이동하여 다시 한방향으로 모든 요청을 처리한다. SCAN과 다르게 단방향으로 처리된다
FCFS (선입선출) First-Come, First-Served	요청이 큐에 도착한 순서대로 처리한다. 요청에 따라 편차가 많으며 오버헤드가 많이 발생할 수 있다.

네트워크

용어

NAC (Network Access Control)	네트워크에 접근하는 장치들의 식별 및 보안 정책 준수 여부 평가 등을 통해 네트워크 통제 강화 및 접근 제어
SMTP - EHLO (Extended Hello)	SMTP 세션을 시작할 때 클라이언트가 서버에 자신의 신원을 알리고 서버의 기능을 확인하는데 사용함.
Enhanced Open Wirless Encryption	개인용 무선 네트워크에서 사용되며 기존 WPA2/WPA3와 다르게 PSK 혹은 패스프레이즈 없이 개인용 무선 네트워크를 암호화 한다.
FIDO (Fast IDentity Online)	모바일 앱에서 생체인증, 보안키, 인증 어플등을 통해 ID/PW를 대신하는 FIDO1.0을 웹으로 확장하기 위해 고안된 무선통신 암호화 기술을 FIDO2라고 부른다. 참고로 FIDO 인증을 사용할 수 있도록 브라우저 및 관련 웹 플랫폼에 내장할 수 있는 표준 웹 API를 WebAuthn이라고 부른다.
VMPS (VLAN Management Policy Server)	VMPS는 MAC주소를 확인하고 해당 MAC주소에 해당하는 VLAN을 찾아주는 역할을 하는데 MAC 주소 위조 공격에 매우 취약하다.

VPN

PPTP (Point-to-Point Tunneling Protocol)	GRE Tunnel 사용
L2TP (L2 Tunneling Protocol)	L2 VPN (IKE & ESP) 보통 IPSec이랑 같이 씀
SSTP (Secure Socket Tunneling Protocol)	IPSec 사용 안하고 SSL/TLS 기반 암호화

무선

WAP (Wireless Application Protocol)	휴대폰 등 모바일 기기가 무선으로 인터넷에 접속할 수 있도록 만든 통신 규약. 초기 스마트폰 시대에 웹 브라우징을 위해 사용되었다.
WTP (Wireless Transaction Protocol)	WAP 내에서 데이터 전송 시 요청과 응답을 안정적으로 처리하는 프로토콜. 무선 환경의 불안정한 연결에서도 데이터가 제대로 전달되도록 보장한다.
WSP (Wireless Session Protocol)	클라이언트와 서버 간의 연결 상태를 관리하는 프로토콜. 연결이 일시 중단 되어도 나중에 다시 이어받을 수 있는 기능을 제공하여 배터리와 네트워크 지원을 절약한다.
WTLS (Wireless Trasport Layer Security)	무선 통신에서 데이터를 암호화하여 안전하게 전송하는 보안 프로토콜. 도청이나 데이터 변조를 방지한다.
WPA (WiFi-Protected Access)	IEEE 802.11i 표준에 정의된 보안 규격으로 WiFi 네트워크의 보안을 강화한 암호화 방식. 기존 WEP보다 안전한 RC4 알고리즘을기반으로 암호화 한다.

어플리케이션

SMTP

EHLO (Extended Hello) > AUTH > MAIL (FROM) > RCPT (TO) > DATA > QUIT

EHLO	클라이언트가 서버에 자신을 소개하고 확장 가능을 확인한다.
AUTH	사용자 인증 절차를 수행한다.
MAIL FROM	발신자 주소를 지정한다.
RCPT TO	수신자 주소를 지정한다.
DATA	실제 이메일 내용을 전송한다.
QUIT	연결을 종료한다.

전자문서 교환 표준

EDI (Electorinic Data Interchange)	기업 간의 전자상거래 시 전자문서를 교환하기 위한 문서화 표준
XML (Extensible Markup Language)	W3C에서 제안한 웹에서 구조화된 문서를 교환하기 위한 웹 표준
XML/EDI	XML 문서를 활용해 전자문서를 교환하는 웹 표준
ebXML (Electronic Business XML)	UN/CEFACT와 OASIS에서 표준화한 기업간 전자상거래 프레임워크

FTP

ftp (File Transfer Protocol)	서버와 클라이언트 간 파일을 전송하기 위한 프로토콜
tftp (Trivial FTP)	파일 전송을 위한 간단한 프로토콜로 보안 기능이나 복잡한 기능 없이 UDP 기반으로 동작하며 69번 포트를 사용한다.
vsftp (Very Secure FTP)	FTP 소프트웨어 중 하나. 가벼우면서도 보안기능이 강화되어 있어 FTP 서버를 운영할때 사용한다.
proFTP	FTP 서버 소프트웨어 중 하나. 사용자 인증, 디렉토리 제한, 보안 기능과 같은 다양한 기능과 확장성을 제공한다.

명령어

netstat

-p	프로토콜 사용 프로세스 ID 출력
-r	라우팅 테이블 확인 및 연결되어 있는 포트번호 확인
-n	현재 다른 PC와 연결 상태인 포트번호 확인
-e	랜카드에서 송수신한 패킷의 용량 및 종류 확인

Windows

파일 및 설정 보호

SAM (Security Account Manager)	- HKEY_LOCAL_MACHNE\SAM에 저장된 키는 Administrator, System 그룹만 모든 권한을 갖는다. - 크래킹을 통해 패스워드를 얻을 수 있다. - 운영체제가 작동하는 한 접근할 수 없도록 잠겨져 있다. - 레지스트리 HKEY_LOCAL_MACHINE\SAM에 구체화된 자료들을 실제로 저장한다.
BitLocker	Windows에서 제공하는 볼륨 단위 암호화 기능이며, Windows의 시스템 파티션 외의 파티션을 암호화한다.
EFS (Encrypted File Service)	파일 및 디렉터리에 대한 추가 수준의 보안을 제공하며, 공개 키 시스템을 사용하여 NTFS 파일 시스템 볼륨에서 개별 파일의 암호화 보호를 제공한다. 일부 EFS 설정은 윈도우 서버 도메인환경의 그룹 정책으로 관리할 수 있다.

시스템 서비스 포트 및 프로토콜

NetBios 데이터그램 서비스	UDP 138
NetBios 세션 서비스	TCP 139
NetBios POP3	TCP 110
IMAP	TCP 143

Android

안드로이드 시스템 권한

ACCESS_CHECKIN_PROPERTIES	체크인 데이터베이스의 속성테이블 액세스 권한
LOADER_USAGE_STATS	액세스 로그 읽기 권한
SET_PROCESS_LIMIT	제한처리 지정 권한
CHANGE_COMPONENT_ENABLED_STATE	애플리케이션 컴포넌트 활성화/비활성화 여부

공격

AI 공격

Membership Inference Attack	공격자가 가지고 있는 데이터가 인공지능 모델 학습에 사용된 데이터인지 아닌지 알아내는 공격
Adversarial Attack	입력 이미지를 최소한으로 변조하여 인공지능 모델이 오인식하도록 만드는 공격
Poisoning Attack	공격자가 AI 모델의 학습 과정에 관여하여 AI 시스템 자체를 손상시키는 공격
Model Inversion Attak	인공지능 모델에 반복적으로 질의하여 학습에 사용된 데이터를 추출하는 공격

네트워크 공격

Port Mirroring	실제 데이터가 오고가는 포트의 정보를 그대로 복제하여 쓰지 않은 포트에 복제하여 다른 포트로 전송하는 것을 말한다. 주로 TX, RX 값을 확인하는 것을 말한다.
Switch Jamming	스위치를 무력화시켜 더미 허브처럼 작동하게 하여 패킷을 모든 포트에 전달하게 되고 공격자가 이 패킷을 가로채는 공격을 말한다.

악성코드

Nimda	2001년 9월에 확산된 컴퓨터 바이러스
Mirai	2016년에 발견된 IP 카메라 혹은 가정용 라우터와 같은 IoT 장치를 공격하는 DDoS 공격용 붓넷.
Stuxnet	산업시설을 감시하고 파괴하는 웜 바이러스
SQL Slammer	마이크로소프트 SQL 서버의 버퍼 오버플로 버그를 이용하여 감염시키는 웜 바이러스

조치

ModSecurity

SecAuditEngine On \| Off \| DetectionOnly	DetectionOnly : 보안 정책 효과를 확인하고 테스트
SecRuleEngine On \| Off \| RelevantOnly	RelevantOnly : 로그를 간소화하여 중요 정보에 집중

Snort

alert tcp any any -> any 80	tcp 80으로 들어올 경우 alert 발생
msg:"HTTP Get Flooding Detect";	해당 메세지 생성
content: "GET/HTTP1";	패킷의 내용이 GET/HTTP1을 포함하는지 검사
depth:13;	패킷의 처음 13 Bytes 내에서 문자열 검색 (검색 성능 향상)
nocase;	대소문자 구분하지 않음
threshold;	중복적으로 발생하는 로그 정리
type threshold, track by src, count 10, seconds 1;	1초안에 10번 카운트시 로그 발생
sid:1000001	sid 1000001 부여

공격 방해

DNS 싱크홀

악성 IP 주소를 알고 있는 경우 이에 대한 요청이 들어올 때 해당 쿼리를 차단하거나 유효하지 않은 응답을 반환하여 악의적인 접근을 막거나 방해하는 방식을 의미한다.

접근 통제 구성요소

정책 (Policy)	- 조직의 보안 목표와 규칙을 정의 - 누가, 무엇을, 언제, 어떻게 접근할 수 있는지 명시 - 상위 레벨의 추상적 보안 지침
매커니즘 (Mechanism)	- 정책을 실제로 구현하는 기술적 수단 - 인증, 인가, 감사 등의 구체적 방법 - 하드웨어 / 소프트웨어적 보안 도구

시큐어 코딩

버퍼 오버플로우 취약 함수

취약한 함수	안전한 대체 함수	설명
strcpy	strncpy	- strcpy: 길이 제한 없이 문자열 복사 - strncpy: 최대 n개 문자까지만 복사
strcat	strncat	- strcat: 길이 제한 없이 문자열 뒤에 추가 - strncat: 최대 n개 문자까지만 추가
gets	fgets	- gets: 길이 제한 없이 한 줄 읽기 - fgets: 버퍼 크기 지정하여 안전하게 읽기
sprintf	snprintf	- sprintf: 길이 제한 없이 문자열 버퍼에 출력 - snprintf: 최대 n개 문자까지만 출력
scanf	fgets + sscanf	- scanf: 길이 제한 없이 입력 받기 - fgets + sscanf : fgets로 먼저 받은 후 sscanf로 파싱
fscanf	fgets + sscanf	- fscanf: 길이 제한 없이 파일에서 입력 - fgets + sscanf : fgets로 먼저 받은 후 sscanf로 파싱
vsprintf	vsnprintf	- vsprintf: 길이 제한 없이 가변 인자로 문자열 출력 - vsnprintf: 최대 n개 문자까지만 출력
getwd	getcwd	- getwd: 버퍼 크기 지정 불가 - getcwd: 버퍼와 크기를 명시적으로 지정

암호화 및 인증

인증

OTP (One-Time Password)	해시 및 대칭키 암호화를 사용한다. 실물 OTP 장치로 인증하기 때문에 소유기반 인증 방식이다.
HSM (Hardware Security Module)	FIPS 140-2 안정성 인증 적용 표준을 사용하며 공개키를 사용한다.
I-PIN (Internet Personal Identification Number)	지식기반 인증 방식으로 ID/PW 및 주민번호를 대체하기 위해 만들어 졌다.
공인인증서	소유기반 인증 방식으로 별도 매체의 고유정보를 제시하도록 함으로 써 인증을 수행한다.
ID/PW	지식기반 인증방식으로 구축비용이 적고 사용하기 편리하다.
메시지 인증 코드 (MAC)	재전송 공격을 막기 위해선 아래와 같은 방법을 취한다. - 순서 번호 (Sequence Number): 송신 메시지에 1씩 증가하는 번호를 넣는다. - 타임스탬프 (Timestamp): 송신 메시지에 현재 시각을 넣는다. - 비표(nonce): 메시지를 수신하기에 앞서 수신자는 송신자에게 일회용의 랜덤 한 값을 건네준다.

디지털 서명

PGP (Pretty Good Privacy)	PGP는 이메일과 파일을 암호화하고 디지털 서명을 제공한다. 공개키로 암호화하고 개인키로 복호화 하는 특징을 지니고 있고 압축 기능을 가지고 있다. 현재는 OpenPGP 표준으로 발전되어 다양한 프로그램에서 구현되고 있다.
이중 서명	메시지를 보낸 사람이 개인키로 첫 번째 서명을 하고, 수신자가 이 서명과 원래 메시지를 받아 자신의 개인키로 두번째 서명을 한다. 메시지에 두개의 서명을 포함시키는것을 이중서명이라 한다. 송수신측에서 모두 서명하기 때문에 트랜잭션의 신뢰성을 높힌다.
CRL (Cetificate Revocation List)	인증 기관에서 만들고 디지털 서명한 취소된 공개 키 인증서 목록이다. 여기엔 아래와 같은 목록이 포함된다. - 인증서 폐지 목록의 버전 - 서명 알고리즘 및 발급 기관의 이름 - 인증서 발급일 및 다음 갱신일 - 취소된 인증에 대한 정보 (일련 번호, 폐지 일자, 폐지 사유 등)

키분배

Blom	대칭 다항식을 이용한 키 분산 키를 생성한다. 중앙 서버없이 사용자 간 직접 키 계산이 가능하고 λ명 까지 공모 공격 방어가 가능하다.
커버로스	티켓 기반 중앙집중식 인증 시스템이며 AS, TGS, SS 3단계 구조이다. 단일 로그인 (SSO)를 지원한다.
공개키분배	공개키 암호화 기반 키 교환을 의미하며 대표적으로 PKI, Diffie-Hellman, RSA등을 활용한다. CA 중심의 인증서 체계를 사용한다.
키 로밍	다양한 장치 혹은 위치에서 동일 키를 사용할 수 있다. 서버, 클라우드, 스마트 카드와 같이 사용자 이동성을 지원한다.

프로토콜

Needham-Schroeder Protocol

신뢰할 수 있는 서버 (KDC, Key Distribution Center)를 통해 두 사용자가 안전한 통신을 설정하게 하는 프로토콜이다.

대칭키 프로토콜, 공개키 프로토콜 두가지가 있다.

공개키 프로토콜에선 MITM 공격이 가능함을 발견했고, 이를 해결하려면 메시지에 송신자 신원을 명시적으로 포함시켜야 한다. (5단계)

대칭키 프로토콜은 재전송 공격에 취약하다. 공격자가 세션키로 오래되고 손상된 값을 사용해도 수신자는 알 수 없다. (3단계)

OCSP
(Online Certificate Status Protocol)

실시간으로 온라인 인증서가 유효한지 확인할 수 있는 프로토콜 이다. 인증서의 상태로는 good(유효), revoked(폐기 혹은 정지), unknown(정보없음)이 있다.

도구

대분류

Debugger	가장 널리 사용되는 리버스 엔지니어링 소프트웨어 도구이다. 프로그램 실행 중에 코드를 단계별로 분석하고 변수 값, 레지스터 상태, 메모리 내용 등을 확인하여 프로그램 동작을 이해하고 수정하는 도구이다. ex) OllyDbg, IDA Pro, x64dbg, WinDbg
Decompiler	컴파일된 바이너리 코드를 원래 소스코드로 변환하는 도구. ex) Ghidra, IDA Pro, RetDec, Reflector
Static Analysis Tools	프로그램의 바이너리 코드를 분석하여 구조, 제어 흐름, 데이터 흐름을 이해하고 프로그램 동작을 추적하는 도구. ex) IDA Pro, Ghidra, Binary Ninja, Radare2
Cryptography Tools	프로그램 내에서 사용된 암호화 데이터를 해독하고 분석하는 도구. ex) Cryptool, OpenSSL
Packing and Unpacking Tools	프로그램의 실행 파일을 압축하거나 암호화하여 분석을 어렵게 만드는 기법을 사용하는 프로그램을 분석하는 도구 ex) UPX, PEiD, Exeinfo PE
Monitoring Tools	프로그램 실행 중에 API 호출, 파일 I/O, 네트워크 트래픽 등을 모니터링 하고 분석하는 도구 ex) Process Monitor, Wireshark, Filemonitor, API Monitor, Procexp
Hex Editor	파일을 16진수 형태로 열어 바이너리 데이터를 직접 수정하거나 분석하는 도구 ex) HxD, 010 Editor

그 외 도구

windbg	마이크로소프트에서 제공하는 윈도우용 디버깅 도구이다.
ltrace	어플리케이션의 공유 라이브러리에 대한 호출을 확인하기 위해 사용되는 리눅스 디버깅 도구이다.

3. TCP/IP

LimSeongHyeon — Mon, 21 Jul 2025 17:18:24 +0900

TCP / IP

TCP / IP vs OSI 7 Layer

OSI 7 Layer는 통신 표준이라는 말을 사용하고, TCP/IP는 산업 표준이라는 말을 사용한다. 왜 OSI가 더 정교하게 분류 해 놓았는데 산업에서는 TCP/IP를 사용하는지에 대한 의문이 생긴다. 여기에는 확신할 순 없지만 복합적인 배경이 있었다고 생각한다.

TCP/IP가 1970년대 미국 국방부(DARPA)의 ARPANET 프로젝트로 개발되었다. 반면 OSI는 1980년대 국제표준화기구(ISO) 주도로 이론적이고 이상적인 모듈화를 위해 설계 되었다.

여기서 많은 공학도들은 감을 잡았을 것이다. 이론과 이상을 쫓게되면 실제 구현과 적용에 대해서 복잡도가 올라가고, 결국 이익을 내어야 하는 집단에서의 복잡도 증가는 비용문제로 이어진다. 심지어 이미 TCP/IP가 세상에 먼저 나와서 산전수전 다 겪고 적응해 있는 상황에서 산업 환경에서 무리하게 OSI를 채택할 필요가 없었다.

그럼에도 불구하고 이론적, 분석적으로 OSI가 뛰어난 모델임에는 틀림이 없고 지금까지 교육과 분석의 목적으로 사용하게 되었다. 산업에서의 표준은 성능이나 완벽함이 아니라 결국 실용적 우위와 이에 대한 수요에 의해서 지정됨을 증명하는 사례라고 본다.

그래서 결론은 OSI와 TCP/IP가 어떻게 다른가 이다. 위에서 시대적인 배경을 설명했듯 TCP/IP가 더 먼저 나온 구조이다. 사실상 동일한 구조를 더 세부적으로 나눈 것이 OSI 7 Layer 라고 보아도 무방하다.

Application 계층에서는 OSI에서의 Application, Presentation, Session의 역할을 하나로 본 것이다. 이전에 Upper Layer는 Software적인 레이어라고 설명한 적이 있다. 이런 특성을 하나의 계층으로 통합되어져 있는 형태이다. 때문에 세션관리, 암호호, 데이터 변환이 모두 해당 계층에서 이루어 진다. 예시로 HTTPS는 HTTP에 TLS 암호화를 합친 하나의 프로토콜로 본다. 만약 이를 Application 수준의 HTTP와 Presentation 수준의 TLS를 따로 구분하여 사용했다면 매우 불편했을 것이다.

Transport 계층은 OSI와 거의 동일하게 수행한다. 다른점은 OSI에서는 Transport Layer가 순수하게 전송 기능만 담당하고 세션 관리 및 데이터 표현, 암복호화는 Presentation Layer에서 수행 했다. 하지만 TCP/IP의 Transport 계층에서는 일부 세션 관리 기능도 포함 되어 있으며 TCP 자체에서 연결 설정 및 해제를 진행하는 3-way handshake를 담당한다.

Internet 계층은 IP 프로토콜에 특화된 계층이다. OSI의 Network 계층에서는 IP 프로토콜 뿐만 아니라 다양한 네트워크 프로토콜을 지원했다. 하지만 TCP/IP에서는 이 IP 프로토콜에 집중한 계층 구조이다.

Network Access 계층은 OSI의 Physical 계층과 Data Link 계층을 통합한 계층이다. 실제 동작은 두 모델이 동일하지만, TCP/IP모델에서는 이 두 계층을 하나로 묶어서 표현한다. 초기에는 "네트워크에 접근하는 방법" 정도로 계층을 바라보고 디자인 했었지만, 시간이 흘러 이를 분해해보니 MAC 주소를 찾는 부분과 실제 물리적으로 전송하는 부분을 분리하는게 좋겠다고 생각하여 OSI에 반영되었다고 보면 된다. 즉, OSI 모델이 TCP/IP의 Network Access 계층을 좀 더 세분화 하여 명확히 구분한 것 뿐이다. 사실상 내부적으로 MAC 주소를 사용하고 프레임을 구성하는 작업들은 동일하다.

TCP / IP Protocol Suite

그럼 실제로 TCP/IP에 대한 프로토콜들이 어떤 식으로 분류되어 있는지 확인해볼 필요가 있다.

Application Layer에서는 우리가 일상적으로 사용하는 서비스들이 모여있다. 웹 브라우징을 하는 HTTP, 이메일 관련 작업을 하기위한 SMTP 및 POP3, 도메인 이름을 IP로 변경해주는 DNS, HTTP와 TLS가 결합하여 암호화 프로토콜을 구사하는 HTTPS. OSI 모델처럼 Application, Presentation, Session을 따로 구분하지 않고 하나의 프로토콜 안에서 모든 기능을 처리한다.

Transport Layer는 단순하게도 TCP, UDP가 주로 사용된다. TCP는 신뢰성이 중요한 웹, 이메일과 같은 통신에 사용되고, UDP는 속도가 중요한 게임이나 스트리밍. 특히, 실시간성을 요구하는 통신에서 사용된다. 위에서 언급했듯이 OSI와 다른 점은 TCP에서 연결 설정과 해제까지 담당한다는 점이다.

Internet Layer는 결국 IP가 핵심 프로토콜이다. IPv4나 IPv6가 실제 주소 체계를 담당한다. ICMP나 ARP, RARP와 같은 프로토콜도 있지만, 재미있게도 같은 Internet 계층에서도 이를 더 쪼개서 높고 낮은 계층을 갖게 한다. 그래서 ARP, RARP < IP < ICMP와 같은 내부 계층을 갖고 있다. ICMP는 ping이나 traceroute와 같은 진단 도구에 사용된다. ARP는 IP 주소를 MAC 주소로, RARP는 MAC 주소를 IP주소로 변환시키는 역할을 한다.

Network Access Layer에서는 Ethernet이 가장 많이 사용되고, Wi-Fi와 같은 무선 프로토콜도 해당 계층에 소속된다. 여기서 중요한 점은 위에서 언급했듯 실제 하드웨어 기술들을 하나의 계층으로 묶어서 처리한다는 점이다.

이러한 Protocol Suite을 보면 왜 사람들이 OSI로 갈 수 없었는지 조금 체감이 된다. 추상화로 인해 더 실용적이고 단순하게 설계되어 있으며 실제 인터넷은 해당 프로토콜들로 돌아가고 있다.

TCP vs UDP

TCP

TCP는 연결 지향 프로토콜이다. 데이터 전송 전에 3-way handshake로 연결을 확보하고 데이터를 전송한다. 이후 4-way handshake 혹은 RST(RESET)를 수행하여 연결 종료를 수행한다.

위 그림과 같이 SYN > SYN ACK > ACK로 연결을 유지시킨다. 이후 원하는 정보를 요청하고 응답하여 정보를 주고 받고 FIN > ACK > FIN > ACK를 통해서 연결을 해제한다. 각 handshake 기법에 대해서는 아래에서 다뤄보자.

3-way handshake

SYN은 Synchronize를 의미하며 동기화 하자는 메시지를 의미한다. ACK는 Acknowledgement를 의미하며 받은 데이터를 확인했다고 알리는 메시지이다. 서버는 클라이언트의 SYN을 받기 전까지 LISTEN 상태에 들어가 있는다. 클라이언트가 서버에게 SYN을 요청하게 되고 SYN_SENT 상태로 변경한다. 이때, 서버는 SYN_RCVD 상태에 돌입하게 되고 SYN 요청에 대한 ACK와 자신과 연결하기 위한 정보인 SYN를 동시에 보낸다. SYN를 받은 클라이언트는 ESTAB 상태로 판정하며 서버에게 ACK를 보낸다.

클라이언트 (SYN):

"서버야 연결해줘. 참고로 지금 데이터 순서 시작 번호는 1000, 수신 버퍼는 65535 bytes, 최대 세그먼트 크기는 1460 bytes야"

서버 (SYN-ACK):

"그래 클라이언트야 연결하자. 순서 시작 번호 1000 잘 받았어. 참고로 내 순서 시작 번호는 2000, 수신 버퍼는 32768 bytes, 최대 세그먼트 크기는 1460 bytes야"

클라이언트 (ACK):

"너의 순서 시작 번호 2000 잘 받았어."

+ 궁금증

여기서 왜 순서 시작 번호를 0으로 약속하지 않고 가변적으로 선택하게 되는지 의문이 생긴다. 크게 두 가지 이유가 있었다. 첫번째는 "연결 혼동 문제"이다. 같은 클라이언트가 서버에 연속으로 연결하면 앞에 연결된 패킷이 지연되어 늦게 도착하면 이를 오인하고 잘못 받아들일 수 있다. 두번째는 "보안 취약점"이다. 만약 0부터 시작하게 약속되어 있다면 공격자는 데이터의 조각을 가지고 순서를 너무 쉽게 짐작할 수 있을 것이다. 더 적극적으로는 서버에 0에 가까운 순서번호를 부여해서 지속적으로 보내면 원치않는 정보를 수신하게 만들 수 도 있을 것이다. 그래서 예측할 수 없고 이전과 섞이지 않게 하기 위해 연결때마다 새로운 번호를 사용한다.

+ 궁금증

여기서 같은 연결임을 결정하는 요소가 무엇인지 궁금해진다. TCP 연결은 5-tuple이라고 불리는 5개의 요소로 유일하게 식별한다.

출발지 IP 주소 (Source IP)
출발지 포트 번호 (Source Port)
목적지 IP 주소 (Destination IP)
목적지 포트 번호 (Destination Port)
프로토콜 (TCP)

4-way handshake

FIN은 FINAL를 의미한다. 연결 유지 상태인 ESTAB(Established) 상태인 클라이언트가 서버에 요청을 중단하고자 FIN을 보낸다. 이 때, 클라이언트는 FIN에 대한 응답을 기다리는 FIN_WAIT_1 상태에 들어간다. FIN 요청을 받은 서버는 CLOSE_WAIT 상태에 들어가고 클라이언트에게 FIN에 대한 ACK를 보낸다. ACK를 받은 클라이언트는 서버의 FIN을 대기하는 상태인 FIN_WAIT_2에 들어가게 된다. 이렇게 다시 한번 서버의 FIN을 기다리는 이유는 서버가 필요한 데이터 전송이 끝나지 않았을 수 있기 때문에 클라이언트는 확실하게 서버의 FIN 요청을 대기하게 된다. 서버는 FIN 요청을 클라이언트에게 보내고 마지막 ACK를 기다리는 LAST_ACK 상태에 들어간다. 서버에게 FIN 요청을 받은 클라이언트는 CLOSED 상태에 돌입하기 위한 타이머를 동작시키고 서버에게 ACK를 보낸다. ACK를 받은 서버는 즉시 CLOSED 상태에 들어가게 된다. 하지만, 클라이언트는 기존에 설정해두었던 타이머가 종료되어야 비로소 CLOSED 상태에 들어가게 된다.

클라이언트 (FIN):

"서버야 나 이제 보낼게 없어. 송신 종료할게"

서버 (ACK):

"확인했어"

클라이언트:

"서버가 더 보낸게 있을 수 있으니까 기다려보자."

FIN (서버):

"클라이언트야 나도 이제 송신 종료할게"

클라이언트:

"혹시 모르니까 몇 분뒤에 종료해야겠다. (타이머 설정)"

ACK (클라이언트):

"확인했어"

+ 궁금증

굳이 ACK를 보내고 바로 종료하지 않고 타이머를 맞춰놓고 ACK를 보내고도 타이머가 끝나야 종료되는지 궁금할 것이다. TCP는 결국 신뢰성이 핵심 설계 철학이다. "마지막 ACK를 서버가 받아서 잘 종료하는 것"까지가 신뢰성인 것이다. 만약 마지막 ACK 이후 바로 종료되게 설계 했다면 아래와 같은 문제 상황이 발생할 것이다.

서버는 클라이언트로부터 ACK가 잘 도착하지 않으면 FIN을 다시보낸다. 이 때 클라이언트는 이미 CLOSED 상태에 돌입했으므로 해당 요청은 허용되지 않은 전송으로 간주하고 RST를 전송한다. 이 때 서버는 RST 응답을 확인하고 연결 유지가 불가능하다고 판정하여 비정상 종료를 하게 된다. 이처럼 비정상 종료가 발생하지 않는 신뢰성 있는 프로토콜을 만들기위해 설계한 것이 TCP이므로 이를 방지하고자 타이머를 통해서 서버가 ACK를 받지 못한 상황에 대해 유예시간을 두는 것이다.

UDP

UDP는 TCP와는 정반대로 신뢰성이 없고 빠른 전송이 목표인 프로토콜이다. 한 번 요청이 오면 계속 응답으로 데이터를 전송한다. 일반적으로 TV를 떠올리면 이미지하기 쉽다. 축구 생중계를 보고있는데 연결이 불안정해서 잠깐 끊겼다. 이 때 TV는 끊기고 나서 끊긴 부분부터 보여주는 것이 아니라 지금 당장 진행되고 있는 부분부터 보여줄 것이다. 이렇듯 실시간성이 중요하고 이전에 발생한 누락된 정보가 크게 중요치 않은 경우 사용하는 프로토콜이다.

IPv4 Addressing

IPv4 기본 구성

Class

Reserved Address

Subnet Mask

Subnetting

Host to Host

Network to Network

2. OSI 7 Layer

LimSeongHyeon — Mon, 21 Jul 2025 13:24:27 +0900

OSI (Open System Interconnection)

국제표준화 기구 ISO (International Standard Organization)에서 Open 시스템간 원할한 정보 교환을 위해 7계층을 가지는 Protocol 표준을 제시하였고 이걸 ISO 7 Layer라고 부른다. 사람과 사람이 말로 소통할때도 언어를 가지고 소통을 한다. 언어에는 발음, 뜻, 문법등과 같은 항목을 약속하고 이것을 지켜 소통을 하는데 이것들을 표준화로 정해놓았다고 생각하면 수월할 것 같다.

이렇게 계층을 분류하는 이유는 위에서 언급한 상호 호환성을 증가시키기 위함도 있지만 각 계층별 역할을 명시함으로써 복잡함을 감소시키는 이유도 있다.

OSI 7 Layer를 배우면서 계단과 같은 느낌을 많이 받았다. 예를들어 각 층마다 처리할 수 있는 업무가 정해진 회사가 있다고 가정해보자. 3층에서 처리가 가능한 업무를 하고자 한다면 3층 까지만 올라가서 업무를 처리하고 내려오면 된다.

그렇다면 회사를 설계할때, 더 원초적인 업무를 처리하는 것이 아래층에 존재해야 오르락 내리락하는 과정을 줄일 수 있을 것이다. 또한 아랫층에서 처리 가능한 업무를 최대한 진행하고 어쩔 수 없는 업무만 윗층에서 처리하는 것이 효율적일 것이다.

이런 효율적인 측면에서의 설계사항이 OSI 7Layer와 네트워크 구축 과정에서 잘 드러나게 된다.

L1. Physical Layer

Physical Layer는 이름 자체로 알 수 있듯이 물리적인 연결에 관한 계층이다. 전기적(물리적)인 연결로 인해서 활성, 관리, 비활성과 같은 작업을 한다고 생각하면 된다. 해당 계층에서는 물리적인 신호인 bit 단위로 전송이 된다. 직관적으로 설명하자면 케이블이나 무선 전파를 활용한 모스부호로 통신하는것을 연상하면 된다. 해당 계층에서의 문제점은 누군가 전기적인 신호에 케이블을 연결하거나 무선 전파를 수신하는 것과 같이 물리적으로 연결만 하면 누구든 통신에 참여하게 된다. 즉 특정 대상에게만 전달 하는 것을 보장할 수 없다.

주요 장비로는 Cable, Ethernet Hub, Repeater (Multi-port Repeater)등이 있다. 이 장비들은 데이터의 내용을 이해하거나 처리하지 않고 신호를 증폭시키거나 재생성하여 전달하는 역할을 한다.

L2. Data Link Layer

Data Link Layer는 논리적인 연결(Link)을 수행한다. 논리적인 연결이라 함은 source(송신지)가 있고, destination(수신지)가 있다는 의미이다. 해당 계층에서의 송/수신지는 MAC Address를 일반적으로 사용한다. 하지만 MAC Address는 물리적인 주소임과 동시에 평면적이여서 고유하지만 소속에 관한 정보는 알수가 없다.

평면적이다 라는 표현을 설명하자면, 한국 사람들은 누구나 주민등록번호를 고유하게 또 유일하게 가지고 있다. 하지만 주민등록번호를 우편 주소란에 적으면 우편이 제대로 발송되지 않을 것이다. 우체국에서는 해당 주민등록번호가 어디에 사는지 어딜 가르키는지 조차 모르기 때문이다.

하지만 우리집에 5명의 가족이 살고있는데 우편에 주민등록번호가 적혀있으면 찾아줄 수 있을 것이다. 해당 주민등록번호가 누군지 가족들에게 물어보고 본인 주민등록번호라고 말하는 사람에게 전달해주면 될 것이다.

이렇듯 평면적이라고 함은 물리적으로 연결되어 있는 사이에서는 어떻게든 찾아서 전달해줄 수 있지만, 이것을 전국 혹은 세계에서 바라보았을 때 소속을 알 수 없어 외부적으로는 표현이 불가능 하다라는 이야기이다.

Data Link Layer에서는 추가적으로 데이터가 손상이 되어 있는지, 수신자가 처리할 수 있는 상황인지, 동시에 너무 많은 전송이 이루어지고 있진 않은지와 같은 내용들을 확인하고 전달한다. 그리고 해당 계층에서 전송되어지는 데이터 형식을 Frame이라고 부른다.

주요 장비로는 L2 Switch, Bridge등이 있다. MAC 주소를 기반으로 프레임을 처리하는 역할을 주로 수행한다. L2 Switch는 MAC 주소 테이블을 학습(Learning)하여 프레임을 적절한 포트로 전달하는 역할을 한다. Bridge는 서로 다른 네트워크 세그먼트를 연결하여 충돌 도메인을 분할하는 역할을 한다. 하지만 요즘 시대에는 Switch를 사용하는걸로 자리가 잡혔다. 충돌을 0에 가깝게 제거할 수 있기 때문이다.

L3. Network Layer

Network Layer에서는 네트워크간 연결을 수행한다. 노드간 경로 선택과 연결성을 제공해주며 논리적 주소를 이용한 Packet을 라우팅해준다.

위에서 Data Link 계층에서의 MAC은 평면적이라고 설명하였다. 이제 네트워크간 연결을 수행해야하기 때문에 평면적인 주소로는 주소지를 찾을 수 없다. 때문에 Network 계층에서는 계층적 주소인 IP Address를 사용한다.

우리가 흔히 사용하는 3계층 주소인 IP Address에는 Network 부분과 Host 부분으로 나누어져 있다. 만약 IP 주소가 192.168.1.100이고 서브넷 마스크가 255.255.255.0라면 192.168.1이 Network 부분, 100이 Host 부분을 의미하게 된다. Network는 이 동네가 어느 동네인지, Host는 그 동네에 몇 번째 집인지를 나타낸다.

이렇게 계층적인 주소를 쓰는 이유는 목적지가 우리 동네(네트워크)의 데이터가 아니면 다른 동네로 넘겨주기 위해서 이다. 그래서 Network Layer의 핵심 기능은 라우팅(Routing)이다. 라우터는 라우팅 테이블을 가지고 있는데, 이 테이블에는 "이 주소로 오는 데이터는 이 방향으로 보내야해"가 기록되어 있다.

라우터가 최종 목적지에 직접 전달 하는게 아니라 부산을 가려면 이쪽 방향으로 가야해 정도만 기록이 되어있는 것이다. 만약 고속도로에서 모든 시군구 읍면리가 다적혀있는 이정표를 보여주게 되면 주행하다 멈춰서 이정표를 빤히 보다 다시 출발해야 할 것이다. 때문에 이정표는 큰 분기점에 대해서만 간단하게 적혀있는게 유리할 것이다. 바로 이 이정표 데이터가 테이블 형태로 라우터에 들어있는 것이다.

주요 장비로는 L3 Switch, Router가 있다. 결국 위 설명처럼 IP 주소를 기반으로 라우팅하는 것이 핵심인 장비들이다. Data Link와 동일하게 라우팅 테이블에 IP 주소들을 찾아 매핑하는 것 또한 학습(Learning)이라고 표현한다. 라우터는 말그대로 라우팅 기능을 수행하고, L3 Switch는 스위칭과 라우팅 모두 수행한다. 여기서 스위칭을 제공한다는 의미는 VLAN간 통신을 가능하게 한다는 의미이며 이후에 자세히 다뤄보도록 하자.

L4. Transport Layer

Transport Layer에서는 양쪽 호스트간 전송을 제어하는데 이 전송 과정에서 신뢰성을 확보한다. 신뢰성은 오류 확인 및 복구를 통해서 확보한다. 이러한 오류 확인 및 복구를 위해 Segmentation(단편화)를 진행한다. 또한, TCP 혹은 UDP와 같이 어떻게 전송할지에 대한 전송 방법 또한 선택한다.

단편화 같은 경우는 데이터의 길이를 일정한 크기로 적절하게 잘라내고 분배하여 전송한다. 수신자 쪽에서는 이를 받고 순서대로 다시 조합한다.

예를들어 큰 비행기를 외국에 수출한다고 가정해보자. 큰 비행기를 수송하기 위해 큰 선박을 가지고 비행기를 수송하게 될 것이다. 이 비행기가 목적지에 도착하고 나면 비행기에 문제가 없는지 검사하게 될 것이다. 비행기가 문제가 없는지 확인하기 위해서는 비행기에 전부를 면밀히 확인해야하고 문제가 있으면 이렇게 큰 비행기를 다시 큰 선박으로 배송해야할 것이다. 비용이 너무나도 많이든다. 또한 해적을 만났을 때 비행기를 통째로 도난당할 것이다.

반면, 이 비행기를 부품단위로 나누어서 일정한 크기의 컨테이너에 넣어 보낸다고 생각해보자. 검사자 입장에서는 컨테이너 내부에 들어있는 부품이 문제가 있는지 없는지 확인하고 문제가 있으면 해당 부품만 다시 보내달라고 요청할 것이다. 그리고 이 경우에 큰 선박을 사용할 필요 없이 작은 여러개의 선박으로 받을 수 있다. 해적을 만났을 때 모든 부품을 잃어버리지 않을 확률이 높아진다. 이런 안정성, 속도, 효율 측면에서 나누어 보내는것이 유리하기 때문에 segmentation으로 나누어 데이터를 전송한다.

TCP의 경우에는 각 컨테이너마다 수령확인서를 받고 순서에 맞춰 조립하고 중간에 유실된 부품들은 재배송을 요청한다. 반면 UDP는 빠르게 보내기만 하고 도착 여부를 확인하지 않는다. 이는 TCP/IP에서 다시 한번 다뤄보도록 하자.

Network 계층에서는 논리적이고 계층적인 IP 주소를 통해 라우팅하여 대상에게 데이터를 전달한다고 했다. 그런데 생각해보면 일반적인 서버에선 IP만으로 정보를 수신하여 분류하고 있지 않다. IP 주소로 받은 데이터를 Port로 다시 분류하여 Application에 전달한다. 이 포트 번호를 통한 구분도 Transport 계층에서 이루어진다.

주요 장비로는 L4 Switch, L4 Firewall이 있다. 위에서 언급했듯 포트 번호를 사용한단 의미는 L4장비는 포트를 사용하는 역할을 수행한다는 의미이다. L4 Switch는 들어오는 패킷들을 적절히 알맞은 서버 인스턴스에 분배해주는 Load Balancer 역할을 수행하고, L4 Firewall은 특정 포트로 들어오는 패킷만 허용하거나 차단하는 Firewall의 역할을 수행한다.

Lower Layer (L1 ~ 4)

Physical Layer부터 Transport Layer까지를 Lower Layer라고 부른다. 굳이 이렇게 4개의 계층을 따로 부르는 이유는 해당 계층들이 실직적인 데이터 전송에 관여하는 계층이기 때문에 그렇다. 즉 "데이터를 어떻게 안전하고 정확하게 목적지로 전달하는가?"에 초점을 맞춘 계층이라는 의미이다.

Physical Layer에서는 실제 데이터를 물리적인 장치로 전달할 수 있게 하고, Data Link Layer는 직접 연결된 장치 간 송신지/수신지를 판정하고 프레임을 전달한다. Network Layer는 네트워크간 패킷을 라우팅하며, Tranport Layer는 신뢰성 있는 종단간 데이터 전송을 맡는다.

L5. Session Layer

Session Layer는 이름과 같이 세션 관리를 담당하는 계층이다. 세션이라 함은 두 응용 프로그램간 대화를 유지시키는 것을 의미한다. 체크포인트를 설정해서 전송 중 오류가 발생하면 해당 지점부터 재전송하는 동기화(Synchronization)나 반이중(Half-duplex) 또는 전이중(Full-duplex)과 같은 통신 모드를 결정한다.

반이중(Half-duplex)는 송신과 수신을 동시에 할 수 없는 단방향 전송 방식이다. 대표적인 예시로 무전기 사용 시 단일 주파수를 사용하기 때문에 버튼을 누르면 듣는건 불가하고 말할 수 있고, 버튼을 때면 듣기만 가능하다. 또한 마지막에 Over를 붙이는 이유는 송신을 완료함을 알리는 메세지를 사용한다. 대표적인 반이중 통신으로 볼 수 있다.

전이중(Full-duplex)는 송신과 수신을 동시에 하는 양방향 전송 방식이다. 일반적인 전화 통화를 생각하면 된다. 서로 동시에 말할수도 들을수도 있다.

정리하자면 Session Layer는 친구와 전화 중에 잠깐 다른일을 하고와서 "우리 어디까지 이야기 했지?"라고 물어보고 다시 이어나가는 그림을 생각하면 된다. 주로 SQL 세션이나 RPC(Remote Procedure Call), 웹 브라우저와 서버간의 세션 쿠기로 인한 상태 유지 등을 연상하면 된다.

L6. Presentation Layer

Presentation Layer는 데이터 표현 방식과 형식 변환을 담당한다. 데이터 표현이나 형식이라 하면 인코딩/디코딩 정도로 생각할 수 있지만 그 외에도 압축 / 압축해제, 암호화 / 복호화와 같은 역할도 이에 해당된다.

이 계층부터는 꽤나 우리와 가까운 위치로 올라오게 된다. JPEG는 이미지 압축 포멧이고, 우리가 일상적으로 접근하는 HTTPS는 SSL/TLS 암호화를 진행한다. 그리고 UTF-8과 같은 인코딩 방식들도 많이 접하게 된다.

L7. Application Layer

Application Layer는 사용자가 직접 상호작용하는 계층이다. 아주 대표적으로는 UI가 제공된다는 점이다. 우리가 지금 보고있는 이 웹 브라우저도 HTTP/HTTPS 프로토콜을 UI 형태로 제공하고 있다. 이메일도 SMTP, POP3, IMAP과 같은 프로토콜을 UI 형태로 제공하고 있다. 이렇듯 사용자가 직접적으로 상호작용하는 계층이다. 유저에게 input을 받고 통신 결과를 output으로 써 제공하는 계층이라고 생각하면 편하다.

주요 장비로는 L7 Switch, WAF, Proxy Server, API Gateway등이 있다. 사실상 L7 수준의 장비까지 오면 서버에 준하는 장비라고 생각하면 된다. 당장 Linux만 생각해 보더라도 그 안에서 여러가지 서비스를 실행시킬 수 있다. 당연히 하나만 중점적으로 수행할 수 있게 만들 수 도 있을 것이다.

HTTP 헤더나 URL 기반으로 더 고차원적인 Load Balancing을 구현 하면(Nginx, Apache) L7 Switch가 되고, ModSecurity 같은 것을 구축하여 웹 애플리케이션 레벨의 공격을 차단하면 WAF 장비가 된다. 또 적절하게 들어오는 패킷에 Client 혹은 Server의 정보를 숨기면 Proxy Server가 되고, 각 엔드포인트 별로 트래픽 밸런싱을 수행하면 API Gateway가 될 것이다.

Upper Layer (L5 ~ 7)

Lower Layer와는 다르게 Upper Layer는 전송 자체에 신경쓰기 보다는 "전송된 데이터를 어떻게 처리할 것인가? 전송된 데이터의 의미가 무엇인가?"에 집중한다. 연결을 유지시킨다던가, 데이터 형식을 바꾸고 암호화를 한다던가, 데이터를 압축한다던가, 인가된 요청인지 판별한다던가, 사람이 읽을 수 있는 형태로 변환하는 것 처럼 전송 자체가 아닌 데이터 가공 및 분석에 초점이 맞춰져 있다.

"데이터 가공 및 분석에 초점이 맞춰져 있다"는 말은 결국 소프트웨어적으로 해결을 해야한다는 의미이기도 하다. 이게 L5, L6의 장비가 별도로 존재하지 않는 이유이기도 하다. 지금까지 사실상 L5, L6, L7의 역할을 묶어 서버라는 개념으로 구동시키고 있으니 말이다. 하지만 L7에서만 해결할 수 있는 작업들이 존재하고 해당 목적으로만 구동되는 장비로 분류를 하기 시작한 것이다.

이러한 특성 때문에 L7 장비들은 하드웨어와 소프트웨어의 경계를 흐리는 존재가 되었고 클라우드 환경에서는 대부분 소프트웨어 정의 네트워킹(SDN: Software-Defined Networking) 형태로 넘어가고 있다.

Capsulation

캡슐화의 궁극적인 목적은 결국 해당 계층에서 관여할 수 있는 데이터를 지정하고 집중시키는 것이다.

예를들어 편지를 배달해주시는 우체부가 있다고 가정해보자. 편지에 어떤 내용이 적혀있고, 편지의 내용이 영어인지 한글인지 보낸이가 답장을 기다리고 있는지 이런 사실들은 우체부가 알 필요가 없다. 필요하지 않은 정보를 얻기위해 편지를 뜯어서 확인하고 다시 붙이는 노동력을 투자할 이유가 없다는 말이다.

데이터 전송도 동일하다. Data Link 계층은 MAC 주소를 기반으로 데이터를 전달해주는 역할을 한다고 설명했다. 해당 계층에서는 IP가 무엇인지, 어떤 인코딩의 데이터인지 세션은 유지되어야 하는 것인지 알 필요가 없다. 왜냐하면 MAC 주소를 기반으로 전달만 해주면 되기 때문에 너무 많은 정보를 얻기위해 리소스를 투자할 필요가 없다는 뜻이다.

결국 편지를 쓰는 과정을 생각해보면 이해가 쉽다. 편지에 내용을 적고 주소와 받는이를 적는다. 우체부를 통해 편지는 우체국에 접수될 것이고, 우체국에서는 해당 주소를 담당하는 또 다른 우체국으로 넘길 것이다. 그리고 마지막 우체국에 도달하면 우체국에서 집으로 배송할 것이고, 집에 도착하게 되면 받는이를 보고 대상에게 전달할 것이다. 이때 우체국은 "주소" 집중할 것이고, 가족들은 "받는이"에 집중할 것이다. 또한 수신자는 "내용"에 집중할 것이다. 즉 거쳐가는 분기점 마다 필요한 정보들이 다르고 이를 효율적으로 다루기 위해 캡슐화를 사용한다.

Encapsulation (송신)

Upper Layer에서 유저가 입력하거나 Application으로 인해 발생한 내용을 Data로 가져온다.
Upper Layer에서 발생한 데이터에 데이터가 잘 전송되기 위한 헤더를 붙힌다. TCP의 경우 송/수신측 포트, 오류 검출용 Check Sum, Control Flag (SYN, ACK 등), Sequence Number 등으로 헤더를 구성하여 붙힌다. 여기서 중요한 사실은 Data를 그대로 보내는 것이 아닌 일정한 크기로 자르고 다시 붙힐 수 있게 Sequence Number를 부여해서 전송한다는 것이다. 여기서 발생한 모든 데이터를 Segment라고 부른다.
위에서 만들어진 Segmnet에 송/수신 IP 주소, IP 버전, TTL(TIme To Live)와 같은 내용을 IP Header에 포함시켜 부착한다. 이를 Packet이라고 부른다.
위에서 만들어진 Packet에 송/수신 MAC 주소, 프로토콜 타입과 같은 내용을 L2 Header에 포함시켜 부착한다. 추가적으로 오류 검출을 위한 작업을 위해 FCS(Frame Check Sequnce)를 트레일러에 부착하여 CRC 오류 검출이 가능하도록 만든다. 이를 Frame 이라고 한다.
위에서 만든 Frame을 bit로 변환하는 작업을 수행하고 실제 물리적인 연결을 통해 해당 데이터를 전송한다.

Decapsulation (수신)

물리적인 회선을 통해서 bits 형태의 데이터가 도착한다. 물리적인 전달이 아닌 MAC Address에 대한 확인 혹은 더 상위 계층의 작업이 필요하다면 상위 계층으로 Decapsulation한다.
Bits를 L2 Header와 Packet Data, FCS로 분류한다. FCS를 통해 해당 데이터에 오류가 있진 않은지 파악한다. 만약 L2 장비라면 L2 Header를 확인하고 필요한 경우 수정하여 다시 Encapsulation 하여 전송한다. 이 경우는 MAC Address만 확인하면 되는 경우가 될 것이다. 이 때 Packet Data에 대한 내용을 직접적으로 확인할 수 없고 확인이 필요하다면 상위 계층으로 Decapsulation 해야한다. Packet Data가 필요한 경우라 함은 주로 IP 주소가 필요한 경우가 될 것이다.
Packet Data를 다시 IP Header와 Segment Data로 분류한다. 만약 L3 장비라면 IP Header를 확인하고 필요한 경우 수정하여 Encapsulation 한다. 이 상황에서 송/수신 IP 주소를 확인할 수 있다. 마찬가지로 Segment Data에 대한 내용이 필요하다면 상위 계층으로 Decapsulation 해야한다. Segment Data가 필요한 경우는 주로 Port 번호가 필요한 경우가 될 것이다.
Segment Data를 TCP Header와 Data로 분리한다. 여기서 TCP Header를 통해서 송/수신측 포트번호, 해당 요청이 SYN인지 ACK인지에 대한 Control Flags, 오류가 있진 않은지 확인하는 Checksum과 같은 내용들을 확인할 수 있다. 만약 해당 Data에 대해서 세션 검증이나 인코딩, 혹은 Application 수준의 결과로 반환하는 경우 Data를 더 상위 계층으로 올리게 될 것이다.
Upper Layer는 결국 Software Layer이기 때문에 들어온 Data를 가공하고 사용하는 작업을 진행할 것이다.

1. Network

LimSeongHyeon — Mon, 21 Jul 2025 09:05:35 +0900

정보 전달을 어떻게 해야할까?

일상 생활에서 대화를 하기 위해서 3가지가 필요할 것이다.

말하는 사람
매체
듣는 사람

사람과 사람이 대화한다고 생각해 보자.
A라는 사람이 B라는 사람에게 말을 하면, 공기라는 매개를 통해서 음파가 B라는 사람에게 정보가 전달될 것이다.
이때, 송신자는 A가 될 것이고, 통신 매체는 공기, 수신자는 B가 될 것이다.

그럼 어떤 학회에서 사람과 사람이 대화하는데, 서로 다른 언어를 사용하는 사람과 대화를 해야 한다고 생각해 보자.
그럼 사람들은 본인의 통역가를 데리고 다닐 것이다. 하지만 모든 언어에 대한 통역가를 데리고 다닐 순 없으니, 대표적으로 영어로 통역해 주는 통역가를 데리고 다닐 것이다.

그럼 A는 A의 통역가에게 전달하고, A의 통역가는 B의 통역가에게 전달하고, B의 통역가는 B에게 전달할 것이다. 그리고 여러 명이서 대화하고 있는 상황에서는 다른 소리들도 들릴 것이다.

Shannon-Weaver Model

Shannon–Weaver model - Wikipedia

From Wikipedia, the free encyclopedia Linear model of communication The five essential parts of the Shannon–Weaver model: A source uses a transmitter to translate a message into a signal, which is sent through a channel and translated back by a receiver

en.wikipedia.org

1948년 클로드 새넌(Claude Shannon)이 제시한 모델에 위와 같은 이야기가 잘 담겨져 있다.

Shannon-Weaver 모델에서는 5가지의 기본 구성요소로 커뮤니케이션 모델이 이루어져있다고 설명한다.

Information Source (정보원)
Transmitter (송신기)
Channel (채널)
Receiver (수신기)
Destination (목적지)
Noise Source (잡음원)

기본적인 네트워크 통신은 위 6가지의 구성 요소들이 고려되어 동작된다. 때문에 잘 기억해 두었다 앞으로 네트워크 구성에 대해서 적용하여 살펴보면 이해가 빠르게 될 것이다.

네트워크

위에서 정보 전달에 관한 이야기를 다뤘지만 어쨌든 우리가 필요한건 "그래서 네트워크가 무엇인가?"이다. 네트워크는 아주 간단하게도 통신 매체를 통해 노드(단말)가 연결(링크)되어 있으면 그 자체로 네트워크이다. 연결은 유선이 될 수도, 무선이 될 수도 있다.

이때 유,무선과 같이 연결(링크)시켜 주는 매개를 전송 매체(Medium)이라고 부른다. 이 전송 매체는 물리적으로 존재하며 전기적인 신호를 전달하게 된다.

A 기기와 B 기기가 각자 자신의 마음대로 정보를 전달하면 서로 이해할 수 없을 것이다. 때문에 표준화된 정보 전송 방법을 정하고 정보를 전달할 때, 해당 방법을 지켜주어야 하는데 이를 프로토콜(Protocol)이라고 부른다.

네트워크 범위

네트워크를 배우지 않았더라도 한번쯤은 들어봤을 LAN, MAN, WAN과 같은 네트워크망 규모에 따른 분류이다. 작게는 집이나 방부터 국가간의 연결, 심지어 항성간 연결의 범주까지 표현하지만 현실적으로 접할 LAN, MAN, WAN에 대해서 알아보도록 하자.

LAN (Local Area Network)은 소규모 지역 내의 장비들을 연결한 네트워크이다. 집에서 사용하는 와이파이나 사무실 네트워크가 가장 대표적인 예시다. 보통 한 건물이나 캠퍼스 내에서 구축되며, 내부 장비들 간의 연결을 위해 스위치를 사용하고 외부 인터넷과의 연결을 위해 라우터를 사용한다. 속도가 빠르고 지연시간이 짧으며, 관리자가 직접 제어할 수 있다는 특징이 있다.

MAN (Metropolitan Area Network)은 도시나 대도시권 전체를 연결하는 중간 규모의 네트워크이다. 통신사나 인터넷 서비스 제공업체(ISP)가 도심 내에 구축한 네트워크가 이에 해당된다. 길에서 KT, SKT 같은 통신사 직원들이 케이블 매설 작업을 하는 모습을 본 적이 있을 것이다. 이런 광케이블들이 도시 전체를 거미줄처럼 연결하여 MAN을 구성한다. 여러 LAN을 연결하는 역할을 하며, 일반적으로 통신사가 소유하고 관리한다.

WAN (Wide Area Network)은 국가 혹은 대륙간 세계에 걸쳐 있는 장거리 네트워크이다. 우리가 미국에 있는 서버에 접근이 가능하다. 하지만 대한민국과 미국은 육지로 이어져있지도 않다. 그럼 어떻게 연결되는걸까? 위성통신을 썼더라면 이렇게 빠른 시간 내로 통신되진 않았을 것이다. 정말 놀랍게도 해저에 케이블로 대륙과 대륙을 이었다. Submarine Cable Map을 확인해보면 어떻게 사람의 힘으로 이 케이블들을 다 매설했을까 싶을정도로 경이롭다. (케이블 매설을 수심 1,000m ~ 8,000m에 매설해서 상어가 물어뜯는 사고도 종종 발생한다고 한다...)

Submarine Cable Map

www.submarinecablemap.com

네트워크 기술

Ethernet

Technoeconomic analysis of PANDA FTTC architecture: Cost comparison to metro ethernet and TWDM NGPON-2 architectures

우리가 일반적으로 접하고 있는 IEEE 802.3표준에 의해 정의된 네트워크 기술이다. 이제는 Ethernet 이외에는 대부분 기술들이 쓰임이 탈락되어 졌다고 봐도 무방하다. 프레임 단위로 전송이 이루어지며 보통 동축 케이블, UTP, 광섬유와 같은 매체로 전송이 된다. 과거에는 CSMA/CD(Carrier Sense Multiple Access with Collision Detection)과 같은 방식으로 동작했었는데, 대부분 스위치 기반 네트워크로 전환하면서 충돌이 대부분 줄어들었다.

Ethernet에는 여러가지 topology가 존재하지만 주로 과거에 버스형을 사용했지만 최근에는 스위치로 각 장비들을 개별연결 하는 스타형으로 많이 사용하고 있다. 이렇게 구성하면 각 링크가 독립적이여서 충돌을 제거할 수 있다.

사실상 이렇게 스위치에 선꽂아서 쓴다는게 확장하기 너무나도 좋은 구조이고, 속도도 매우 준수하여 사실상 유선 LAN의 표준이 되어있다.

+ CSMA/CD (Carrier Sense Multiple Access with Collision Detection)

참고로 Carrier Sense는 송신 전 채널이 비어있는지 확인하는 작업, Multiple Access는 여러개의 노드가 공유 매체에 접근하는 행위이다. Collision Detection은 충돌을 감지할수 있고, 감지되면 백오프 시킨다.

+ 위 이미지를 보면 확장에 용이하다는 말이 얼마나 굉장한 의미를 내포하는지 알 수 있게 된다. 저런 구조가 수십 ~ 수백개 연결된다고 생각하면 기술적 종속성이 발생하는 순간 해결하기 매우 어려울 것이다.

Token Ring

https://en.wikipedia.org/wiki/Token_Ring

IBM에서 개발한 LAN 기술이다. 논리적으로 고리(Ring)을 만든다고 해서 TokenRing이다. Token이라는 제어 신호를 옆으로 전달하여 목적지에 다다를때까지 이를 반복하는 방식이다. 단점이 직감적으로 느껴질 것이다. 바로 SPOF(Single Point of Failure)를 갖게된다. Ring의 Node중 하나라도 장애를 일으키면 전체 네트워크가 마비된다.

FDDI (Fiber Distributed Data Interface)

TokenRing의 진화 버전이다. 이중 링 구조(Dual Ring Topology)를 사용한다. Token Ring에서는 단방향으로 데이터를 전달하기 때문에 중간에 Node 하나가 장애를 일으키면 해당 Node 건너의 모든 노드와의 연결이 마비된다고 설명하였다. FDDI에서는 Ring을 각각 다른 방향으로 배치하여 하나의 Node가 동작하지 않아 문제가 생기면, 다른 방향의 Ring을 이용하여 복구시킨다.

ATM (Asynchronous Transfer Mode)

https://www.technopediasite.com/2018/08/reasons-behind-downfall-of-atm.html

ATM은 고정 길이(53 bytes)의 셀(cell)을 사용하는 패킷 교환 기반의 네트워크 기술이다. 고정 길이를 사용한다는 것은 속도와 Trade-Off한 패널티이다. 때문에, 속도면에서 장점을 가지게 된다. 기존의 PSTN(회선교환 방식)에서는 모든 연결에 일정 대역폭을 고정하여 배정했었다. 하지만 ATM은 필요할때만 대역폭을 사용하고, 사용하지 않을 땐 대기하지 않고 넘긴다. 마치 대역폭을 공유자원으로서 사용하는 프로세스와 같다. 때문에 이름에서 알 수 있듯 비동기(Asynchronous) 전송을 한다고 간주한다.

네트워크 전송 방식

Broadcast

연결된 네트워크의 모든 노드에게 전송하는 방식이다.

아파트 관리사무소에서 안내 방송을 하는 모습을 상상하면 매우 직관적이다. 예를들어 오늘 아파트에 잠시동안 정전이 된다는 사실을 모든 호수에 개별적으로 전달하려면 매우 힘들것이다.

반면에, "금일 12시부터 14시까지 안전점검을 위해 정전이 있을 예정이오니 양해 부탁드립니다."를 아파트 동 전체에 안내방송을 하면 매우 간편하게 해결될 것이다.

그럼 직관적으로 Broadcast의 단점도 보일 것이다. 이미 방송된 정보를 알고 있거나 해당되지 않는 사람들도 연락을 받아야 한다는 문제가 있고, 이러한 안내 방송이 1분에 한번씩 나오면 주민들은 스트레스 받을 것이다. 실제로 네트워크는 이 Broadcast를 사용했을 때 발생하는 이런 스트레스를 해결하기 위해 여러 기술들을 고안하게 된다.

Unicast

연결된 네트워크에서 특정 단일 노드에게만 전송하는 방식이다.

고급 아파트에서는 모든 우편물을 관리사무소에서 중앙 관리한다고 가정해보자. 관리사무소에는 각 호수별 주민 정보가 기록된 장부가 있어서, 누가 어느 호수에 살고 있는지 파악할 수 있다. 예를 들어 홍길동씨에게 편지를 전달하고 싶다면, 관리사무소 직원이 장부를 확인해서 홍길동씨가 101호에 살고 있다는 것을 확인하고 해당 호수로 편지를 배달해줄 것이다.

하지만 홍길동씨가 이 아파트에 처음 이사를 와서 아직 관리사무소 장부에 정보가 등록되지 않았다면 어떨까? 이런 경우 관리사무소에서는 전체 동에 안내방송을 한다. "홍길동님, 우편물이 도착했으니 관리사무소로 와서 호수를 알려주시기 바랍니다." 그럼 홍길동씨는 관리사무소에 와서 본인이 101호에 산다고 알려주고, 관리사무소는 이 정보를 테이블에 기록한다. 다음부터는 테이블에 홍길동씨 정보가 있기 때문에 안내방송 없이도 바로 101호로 편지를 배달할 수 있다.

Multicast

Multicast는 여러개의 노드들을 그룹화 하여 해당 그룹을 기준으로 전달하는 전송 방식이다.

고급 아파트에 여러 소모임이 있고, 홍길동씨를 포함한 5명이 매주 아파트 청소를 하는 "청소봉사단"이라는 소모임을 만들었다고 가정해보자. 관리사무소에서는 이런 소모임 정보도 별도 장부로 관리하고 있다.

어떤 사람이 이 청소봉사단에 너무 고마워서 감사 편지를 보내려고 한다. 이때 5명 각각에게 개별적으로 편지를 보내는 것(Unicast X 5)은 비효율적이고, 아파트 전체에 방송하는 것(Broadcast)은 청소봉사단과 관계없는 주민들에게까지 불필요한 정보를 전달하게 된다. 이런 상황에서 관리사무소에 가서 "청소봉사단 회원들에게만 편지를 전달해주세요"라고 요청할 수 있다. 관리사무소 직원은 소모임 테이블을 확인해서 청소봉사단에 속한 5명의 호수를 파악하고, 해당 호수들에만 편지를 배달해준다.

이처럼 Multicast는 전체가 아닌 특정 그룹에게만 정보를 전달하는 방식으로, Broadcast보다는 효율적이면서도 개별 Unicast보다는 편리한 절충안이라고 할 수 있다. 네트워크에서도 동일한 데이터를 받아야 하는 여러 노드들을 그룹으로 묶어서 한 번의 전송으로 해당 그룹 전체에게 데이터를 전달할 수 있다.

LAN Card

Windows에서는 NIC(Network Interface Card)이라고도 불리는 랜카드는 위에서 언급한 커뮤니케이션 모델의 통역가 역할을 한다. 컴퓨터 내부에서는 디지털 데이터(0과 1의 비트)로 정보를 처리하지만, 네트워크 케이블을 통해서는 전기적 신호나 광신호로 데이터를 전송해야 한다. 랜카드는 이 두 신호 형태 사이의 변환을 담당한다. 송신 시에는 컴퓨터의 디지털 데이터를 네트워크로 보낼 수 있는 물리적(전기적) 신호로 변환하고, 수신 시에는 네트워크에서 오는 물리적(전기적) 신호를 컴퓨터가 이해할 수 있는 디지털 데이터로 변환 한다.

학회장에서 통역가가 수많은 소음 속에서 자신의 담당자를 부르는 소리만 골라 듣듯이, 랜카드도 네트워크를 떠도는 수많은 데이터 중에서 자신의 컴퓨터가 대상인 신호만을 선별한다. 네트워크에는 여러 컴퓨터가 연결되어 있고, 동시에 많은 데이터가 오가고 있다. 하지만 모든 데이터가 내 컴퓨터에 필요한 것은 아니다. 랜카드는 각 데이터 패킷의 목적지 주소를 확인하여, 자신의 MAC Address와 일치하는 데이터만 받아들이고 나머지는 무시한다. 이러한 필터링 과정을 통해 불필요한 데이터 처리로 인한 시스템 부하를 줄이고, 보안성도 향상시킨다. 마치 통역가가 관련 없는 대화는 걸러내고 필요한 내용만 통역해주는 것과 같은 원리다.

그래서 결론은 랜카드는 물리적 신호와 논리적 데이터 사이의 통역가 역할을 하면서, 동시에 노드에서 네트워크의 효율성과 보안을 담당하는 핵심 구성 요소이다.

Bandit Level 10 → Level 11 [10/34]

LimSeongHyeon — Sat, 12 Jul 2025 14:17:50 +0900

OverTheWire: Level Goal

We're hackers, and we are good-looking. We are the 1%.  Level Goal The password for the next level is stored in the file data.txt in one of the few human-readable strings, preceded by several ‘=’ characters. Co

overthewire.org

The password for the next level is stored in the file data.txt, which contains base64 encoded data

data.txt에 password가 존재하는데 base64로 인코딩 되어있는 것 같다.

우선 데이터를 읽어보자.

OverTheWire에 Base64가 해당 레벨의 Command 중 하나이니 man page를 확인해보자.

man page 내용은 아래와 같다.

base64로 인코딩된 데이터라고 했으니 디코딩 시키면 패스워드가 나올거 같다.

디코딩 옵션인 -d / --decode를 사용해보자

HIT!

Prompt Injection

LimSeongHyeon — Mon, 7 Jul 2025 11:44:25 +0900

python에서 int값의 제한이 없는걸로 알고 있는데 진짜 맞는지 확인하려고 클로드한테 물어봤더니, 무제한 정수를 작성하다 응답이 중지되어 버렸다.