08 — 인터넷 프로토콜과 서비스 보안
A. DNS
DNS는 도메인 이름에 대응하는 자원 레코드를 조회하는 서비스다. URL에서는 호스트 이름 부분의 해석에 사용한다. stub resolver·재귀 resolver·권한 서버의 역할과 캐시를 나눈다. 재귀 요청은 답을 구해 달라는 요청, 반복 질의는 응답/위임을 따라 다음 서버를 찾는 과정이다. 로컬 hosts·OS 캐시·브라우저 캐시·설정한 resolver의 순서는 OS/응용 설정에 의존한다. 이름해석 순서는 해당 환경의 설정으로 확인한다. zone은 관리·권한 경계이며 하위 영역의 위임에 따라 범위가 정해진다. DNS 용어 RFC8499
A/AAAA는 주소, NS는 권한 서버, MX는 메일 교환 대상, CNAME은 별칭, PTR은 역방향 이름 참조, SOA는 존의 관리 정보를 나타낸다. AXFR은 전체 존 전송, IXFR은 변경분 전송 요청이다. ANY 응답은 서버 정책과 해당 규격에 따라 제공되는 레코드 범위를 확인한다. RFC8482
일반 DNS 구현은 UDP와 TCP를 지원한다. UDP 크기는 확장·협상 조건을 확인하고, TCP는 일반 질의와 존 전송 등에 사용한다. EDNS의 크기 확장과 경로 MTU는 다르다. RFC7766 §5
위조 응답 수용은 질의 ID뿐 아니라 주소·포트·이름·class/type 일치 및 신뢰 규칙이 관여한다. ID/출발지 포트 예측을 어렵게 하는 것과 서명 검증은 다른 통제다. 캐시 오염은 잘못된 답이 이후 질의에도 영향을 주는 문제이고, 로컬 hosts 변조는 로컬 매핑, 등록 계정 탈취는 도메인 관리 권한을 대상으로 한다. RFC5452 §9
DNSSEC는 RRset 서명과 신뢰 앵커·DNSKEY·DS 경로로 데이터 출처와 무결성, 부재 증명을 검증한다. 질의 기밀성·DoS 대응·접속 서비스의 보안은 각각의 보호 수단으로 관리한다. 서명 존 운영과 클라이언트 측 검증도 별도 조건이다. 재귀 허용·존 전송 허용·질의 허용은 서로 다른 정책이다. RFC4033 §3~5
B. FTP·TFTP
FTP 제어 연결은 클라이언트가 서버에 연결한다(기본 TCP21). 데이터 연결은 별도다. active의 PORT/EPRT는 클라이언트 측 수신 지점을 전달해 서버가 연결하게 하고, passive의 PASV/EPSV는 서버 측 수신 지점을 알려 클라이언트가 연결한다. 데이터 포트는 active/passive 방식과 실제 전달·협상 값을 확인한다. QUIT는 프로토콜 명령이며 클라이언트의 exit 별칭과 구분한다. FTP RFC959
bounce는 FTP 서버가 제3자에 데이터 연결하도록 유도하는 문제다. 제어/데이터 연결 상대 검증·허용 대상 제한·필요 없는 기능 제한이 원인에 맞는 대응이며 목적지·포트 정책을 함께 적용해 제3자 연결 범위를 제한한다. 인증된 사용자도 악용할 수 있다. RFC2577
vsftpd의 userlist_enable과 userlist_deny를 함께 읽는다. 활성화 상태에서 deny=YES는 목록 사용자를 거부, NO는 목록 밖 사용자를 거부하는 구조다. PAM 인증, 파일 권한, chroot에 의한 경로 제한, 익명 계정 정책은 별도다. 로깅 활성화·포맷·저장 경로는 서버 설정에서 확인한다. vsftpd.conf
TFTP는 UDP 기반 간소 파일 전송이며 사용자 인증·디렉터리 목록 기능을 자체 제공하지 않는다. 최초 요청의 UDP69와 이후 전송 ID/포트를 구분한다. FTPS는 FTP의 TLS 보호, SFTP는 SSH 기반 파일 전송으로 TFTP와 다르다. TFTP RFC1350
C. 메일 전달
MUA는 작성/열람, 제출 서버는 사용자 메시지 접수, MTA는 전달, MDA는 사서함 전달이라는 역할로 읽는다. 한 제품이 여러 역할을 수행할 수 있다. SMTP는 전송·제출, POP/IMAP은 사서함 접근이다. SMTP envelope의 MAIL FROM/RCPT TO는 전달에, From/To 헤더는 메시지 표시에 사용한다. 서버 수락·최종 배달·열람은 각각 확인할 상태다. 원격 도메인의 MX 조회와 로컬 사서함 전달도 나눈다. SMTP RFC5321
기본적으로 SMTP 전송25·제출587, POP3 110, IMAP143을 구분하되 인증·TLS는 해당 포트의 실제 서비스 설정으로 확인한다. 제출 RFC6409. STARTTLS와 암시적 TLS는 시작 방식이 다르다. POP·IMAP의 삭제·보관은 클라이언트 명령과 서버 정책에 따른다. POP3 RFC1939, IMAP RFC9051
ESMTP는 확장 협상, SMTP AUTH/SASL은 인증, MIME는 내용 형식·첨부 표현이다. MIME/Base64는 내용 표현·인코딩이고 기밀성은 암호화로 보호한다. 릴레이는 사용자·대상 정책으로 제한하고 실제 서버의 설정 형식·경로를 확인한다.
D. 메일 보호
| 수단 | 확인·보호 대상 | 함께 확인할 조건 |
|---|---|---|
| SPF | SMTP 접속 IP가 MAIL FROM/HELO 도메인 정책에 허용되는가 | 표시 From의 정렬·메시지 무결성은 해당 검증 방식과 결합 |
| DKIM | 서명 도메인과 선택 헤더·본문의 서명 유효성 | 서명 대상 헤더·본문 범위와 표시 작성자와의 관계 |
| DMARC | 표시 From 도메인과 SPF 또는 DKIM의 통과 식별자 정렬 | SPF 또는 DKIM의 통과·정렬; 내용의 안전성은 별도 검사 |
| OpenPGP/S/MIME | 메시지 서명·암호화 구성 | 키·신원 신뢰, 첨부 검사·가용성·열람 확인은 별도 관리 |
| SMTP TLS | 설정한 전송 끝점 사이 채널 | 각 홉의 TLS 적용과 사서함 저장 보호 |
SPF RFC7208, DKIM RFC6376, DMARC RFC7489, OpenPGP RFC9580, S/MIME RFC8551
SPF의 fail/softfail 등 결과와 수신 서버의 실제 거부 정책을 나눈다. DMARC의 none/quarantine/reject는 발신 도메인의 요청 정책이며 수신측 로컬 판단과 보고가 별도다. 정렬에는 strict/relaxed 조건이 있다. DKIM은 정규화와 서명한 헤더 목록·본문 범위를 확인한다.
메시지 암호화는 보통 내용용 대칭키와 수신자 키 보호를 조합하고, 서명은 발신자 개인키/검증키의 역할을 나눈다. 알고리즘·키 길이는 적용 규격과 판본을 기준으로 읽는다. 서명이 제공하는 출처 증거와 법적 부인방지는 키 관리·신원·운영 조건을 포함한다(C03/C13).
Received·Authentication-Results는 신뢰하는 경계 안 서버가 생성한 부분을 기준으로 해석한다. 첨부 확장자·내용 검사·스팸 점수는 각 관찰 범위에 맞춰 결합한다. RFC8601의 trust boundary
E. HTTP 메시지
HTTP의 stateless는 각 요청을 처리하는 프로토콜과 요청 간 응용 상태 관리를 분리하는 성질이다. 로그인 상태는 세션 등 응용 기제로 유지한다. HTTP/1.x는 시작줄·헤더·빈줄·본문으로 표현하고 다른 버전은 해당 전송 형식을 따른다. 연결·스트림은 통신 상태, 로그인 세션은 응용 상태다.
GET은 표현 조회, HEAD는 GET에 대응하는 본문 없는 응답, POST는 대상 자원에 처리 요청, PUT은 대상 표현 생성/교체, DELETE는 대상 연결 제거, OPTIONS는 통신 옵션을 알아보는 의미다. 안전성·멱등성·실제 앱 인가를 구분한다. POST 본문의 기밀성은 TLS 등으로 보호하고 크기 제한은 서버·응용 정책에 따른다.
200 성공·201 생성·202 접수 후 미완료·204 응답 내용 없음, 301/302 재지정·304 조건부 조회의 변경 없음, 401 유효한 인증 자격 부족·403 요청 수행 거부·404 찾지 못함·405 메소드 불허, 500 내부 오류·502 상위 응답 문제·503 일시 처리 불가로 비교한다. 401에는 WWW-Authenticate, 405에는 Allow 등 코드별 조건이 있다. HTTP RFC9110
URL fragment는 클라이언트가 해석하는 참조 부분이다. ’+‘의 공백 해석은 form URL-encoding 문맥에 적용하고 일반 URI 문자 처리와 구분한다. URI RFC3986, WHATWG URL의 form 인코딩. Cookie/Set-Cookie 속성과 만료는 C09, no-cache는 재사용 전 검증, no-store는 저장 제한이다. 자세한 웹 운영은 C09-H에서 다룬다.
F. TLS
TLS는 협상·상대 인증·키 설정을 하는 handshake와 응용 데이터 보호를 하는 record를 구분한다. 일반 인증서 기반 서버 인증과 선택적 클라이언트 인증을 구분하며 PSK·재개 등 흐름도 존재한다. CertificateRequest는 서버가 클라이언트 인증서를 요청하는 메시지다. 의도한 상대와 통신하려면 암호화와 함께 인증서의 신뢰·이름·유효성을 검증한다.
TLS1.2는 키 교환/스위트별 메시지와 보호 방식이 다르다. RSA 키 운반은 해당 구형 스위트의 키 설정 방식으로 읽는다. TLS1.3(원천 대조 RFC8446 기준)은 정적 RSA/DH 키 교환을 제거하고 AEAD를 사용하며 ServerHello 뒤 handshake를 암호화한다. 재개는 PSK 흐름으로 묶이고, 0-RTT는 재전송 위험을 고려해 허용할 업무 요청과 방어 정책을 정한다. 호환용 CCS와 구형 키 전환 절차도 구분한다. RFC8446 §1.2·2·8
TLS1.2 AES-GCM 스위트의 SHA256은 PRF 해시를 지정하고 레코드 인증은 GCM 태그로 처리한다. 암호·인증·키도출 역할을 분리한다. PFS는 장기키 유출 때 과거 세션키 노출을 제한하는 성질로 제공 여부는 PSK 사용·키 교환 구성에 따라 확인한다. 단말 침해는 끝점 보안으로 별도 관리한다. RFC5288 §3, C03 키 설정
SSL2/3와 TLS1.0/1.1은 구형 프로토콜로 분류하고 운영에는 해당 보안 권고의 허용 버전을 적용한다. RFC9325의 운영 권고와 2026년7월 RFC9852의 신규 프로토콜 TLS1.3 기본 요구를 구분한다. 후자는 신규 프로토콜에 대한 요구이며 기존 TLS1.2 서비스는 해당 운영 권고와 적용 범위를 확인한다. RFC9325, RFC9852 §4~5
역사적 취약점은 원인과 영향으로 연결한다.
- Heartbleed: 특정 OpenSSL heartbeat 길이 검사 누락에 따른 메모리 읽기 노출. 영향은 해당 구현의 경계 밖 메모리 읽기다. 취약 구현 수정 후 노출 가능 비밀·인증서 처리 범위를 판단한다. OpenSSL 당시 권고
- FREAK: export RSA로 약한 키를 수용하게 하는 조건. Microsoft MS15-031
- Logjam: 약한 유한체 DH 협상·그룹 재사용 문제. 키 교환 알고리즘 선택과 함께 그룹·협상·구현의 안전성을 확인한다. 원 연구, 초록 범위.
- POODLE: SSL3 CBC 패딩 오라클의 역사 사례. 적용 범위는 프로토콜·패딩 처리·구현 조건에 따른다. RFC9325 §3.1
- DROWN: SSL2 서비스를 복호화 오라클로 이용하는 프로토콜 간 공격. 공격의 핵심은 구형 프로토콜의 복호화 응답을 다른 연결의 공격에 이용하는 구조다. 원 연구 초록
HTTPS의 포트443 관례와 실제 사용 프로토콜·종료 위치·웹사이트 업무 신뢰는 별도다.
G. SSH
SSH는 서버 인증·기밀성·무결성의 전송 보호, 사용자 인증, 연결/채널 다중화 역할을 나눈다. 원격 명령·파일 전송·포워딩은 이 통로를 이용하는 용도다. 호스트키 신뢰 확인과 사용자 공개키 로그인은 다른 인증이다. RFC4251
포워딩은 SSH 끝점 사이 구간을 보호한다. 터널 밖 최종 목적지 구간이나 로컬 수신 포트 노출은 별도 통제다. 로컬/리모트 포워딩은 어느 쪽에서 수신하는지부터 읽으며 포워딩 허용 정책과 원격 로그인 허용은 나눠 관리한다.
H. SNMP
관리자/NMS가 agent의 관리 객체를 조회·설정하고 agent는 알림을 보낼 수 있다. MIB는 관리 객체의 정의 체계, OID는 객체 식별자다. ASN.1은 형식 정의, BER은 부호화 규칙을 담당한다. Get/GetNext·Response·Set·Trap을 기본으로, GetBulk/Inform 등은 버전 조건을 붙인다. Trap은 agent가 관리자에게 보내는 알림이다.
v1/v2c는 community 기반 접근을 사용하고 강한 인증·기밀성은 해당 보안 구성에서 확보한다. v3도 설정한 보안 수준에 따라 noAuthNoPriv, authNoPriv, authPriv가 다르다. USM의 인증·기밀성과 접근 허용 뷰/권한은 별도다. public/private는 흔한 community 예시이며 실제 값은 장비 설정에서 확인한다. 관리망/ACL 제한·최소 쓰기 권한·필요 없는 관리 서비스 제거를 함께 본다. RFC3411, 메시지 RFC3416, USM RFC3414
핵심 연결
- DNS는 이름·레코드·캐시·권한을 연결하고 DNSSEC로 서명된 데이터의 진위를 검증한다.
- FTP는 제어와 데이터 연결, 메일은 제출·전달·사서함 접근의 역할로 읽는다.
- SPF는 송신 IP 정책, DKIM은 서명, DMARC는 표시 From과의 정렬을 확인한다.
- HTTP 메시지 의미·전송 연결·로그인 상태를 각 계층에서 이해한다.
- TLS는 협상·상대 인증·키 설정·레코드 보호를 연결한다.
- SSH는 호스트·사용자 인증과 보호 채널, SNMP는 관리 객체·보안 수준·접근 권한을 함께 구성한다.
출처와 범위
2026-09-09까지 대조한 채택 핵심을 유지한다. 2026-09-10에는 출처 연결과 문서 구성을 정리했으며 기술·법령의 최신성 재검증은 수행하지 않았다. 제품·규격은 명시된 버전과 조건을 기준으로 읽는다.