네트워크 공격을 방어 관점에서 분류하기: 도청·위조·가용성

네트워크 공격 이름을 많이 외워도 실제 대응이 바로 떠오르지는 않는다. 먼저 무엇이 훼손되는지, 어느 계층에서 막아야 하는지, 탐지 뒤 무엇을 확인할지를 연결해야 한다. 이 글은 공격 절차를 재현하는 대신 방어자가 알아야 할 경계만 정리한다.

출발점은 기밀성·무결성·가용성이다

정보 보안의 기본 목표는 흔히 CIA 세 가지로 묶는다.

• 기밀성(Confidentiality): 허가되지 않은 주체가 정보를 읽지 못하게 한다.
• 무결성(Integrity): 정보가 허가 없이 변경되거나 파괴되지 않게 한다.
• 가용성(Availability): 필요한 사용자가 제때 정보와 시스템을 이용할 수 있게 한다.

인증성은 통신 상대나 데이터 출처가 주장한 대상이 맞는지를 다룬다. 책임 추적성, 부인 방지 같은 속성도 함께 쓰이지만, 이를 CIA와 경쟁하는 별도의 ‘네 번째 원칙’처럼 고정할 필요는 없다. 조직과 표준의 모델에 따라 보조 속성을 표현하는 방식이 다르기 때문이다.

또한 MAC이라는 약어는 문맥을 확인해야 한다. 네트워크에서 MAC address는 링크 계층 주소이고, 암호학의 message authentication code는 비밀 키를 이용해 메시지의 무결성과 인증성을 확인하는 값이다. HMAC 같은 message authentication code는 메시지를 암호화하지 않으므로 기밀성을 제공하지 않는다. 단순 checksum도 전송 오류 탐지에는 쓸 수 있지만, 공격자가 값을 함께 다시 계산할 수 있어 적대적 변조 방지 수단이 되지 못한다.

도청은 전송 내용과 메타데이터를 나눠 본다

도청은 통신 내용을 몰래 관찰하거나 기록해 기밀성을 해친다. 평문 HTTP, Telnet처럼 내용 자체가 노출되는 프로토콜은 TLS가 적용된 HTTPS, SSH 같은 보호된 채널로 바꾸는 것이 우선이다. 공용 네트워크에서 내부망 전체로 안전한 경로가 필요할 때는 검증된 VPN도 선택지가 된다.

다만 TLS를 썼다는 사실만으로 모든 정보가 숨겨지지는 않는다. 접속 IP, 트래픽 양과 시간 같은 메타데이터는 관찰될 수 있다. 인증서와 hostname 검증을 끄면 암호화된 채널을 잘못된 상대와 맺을 수도 있다. 따라서 다음을 함께 확인한다.

• 평문 프로토콜과 평문 자격 증명을 제거했는가
• TLS 인증서 검증과 서버 이름 검증이 켜져 있는가
• 비밀 값을 URL query, 로그, 오류 메시지에 남기지 않는가
• 필요한 범위보다 넓게 패킷과 애플리케이션 로그를 보관하지 않는가

위장과 중간자 공격은 상대 확인이 핵심이다

masquerade와 spoofing은 공격자가 다른 사용자·호스트·서비스인 것처럼 보이게 한다. 중간자 공격은 두 통신자 사이에서 메시지를 중계하거나 바꾼다. 비밀번호 하나만 확인하는 구조보다 MFA, 짧은 수명의 자격 증명, 인증서 검증, 필요한 구간의 상호 인증을 조합한다.

TCP session hijacking처럼 기존 연결의 신뢰를 악용하는 문제도 ‘TCP를 썼으니 안전하다’고 볼 수 없다. TCP는 신뢰성 있는 바이트 전달을 제공하지만 상대의 업무상 신원과 애플리케이션 메시지 무결성까지 보장하지 않는다. TLS, 안전한 session token 관리, 재인증, 짧은 만료 시간과 이상 행위 탐지가 별도로 필요하다.

링크 계층 공격은 같은 네트워크 경계를 본다

ARP spoofing, rogue DHCP, switch forwarding table 고갈 같은 공격은 주로 로컬 링크와 네트워크 장비 설정을 노린다. 인터넷 전체에서 동일한 방식으로 바로 수행되는 공격이라고 일반화하면 범위를 잘못 짚게 된다.

관리형 네트워크라면 다음과 같은 방어를 검토할 수 있다.

• 사용자·서버·관리 네트워크를 목적에 따라 분리한다.
• 승인된 DHCP server와 switch port 정책을 관리한다.
• 장비가 지원하는 경우 DHCP snooping, Dynamic ARP Inspection 같은 기능을 설계에 맞게 적용한다.
• 갑작스러운 gateway MAC 변경, DHCP 응답원 변경, 비정상 broadcast 증가를 관찰한다.
• switch 관리 plane 접근과 설정 변경 이력을 보호한다.

이 기능들은 이름만 켠다고 끝나지 않는다. VLAN, trunk, 신뢰 port를 잘못 지정하면 정상 통신을 끊을 수 있으므로 장비 문서와 현재 topology를 기준으로 단계적으로 검증해야 한다.

DNS 위조와 DNS 암호화는 같은 문제가 아니다

악성 DNS 응답이나 rogue DNS는 사용자를 잘못된 주소로 보낼 수 있다. DNSSEC은 서명된 DNS 데이터의 출처와 무결성을 검증하는 체계다. DNS 질의 내용을 숨기는 기술은 아니다. DoH와 DoT는 client와 recursive resolver 사이의 전송 구간을 암호화하지만, 그 자체가 응답 데이터의 종단 간 진위를 증명하지는 않는다.

따라서 ‘DNSSEC 또는 DoH 하나만 쓰면 DNS가 안전해진다’고 결론 내리기보다 역할을 나눈다.

• zone 서명과 validating resolver로 DNS 데이터 검증 범위를 정한다.
• 승인된 resolver를 사용하고 endpoint와 정책을 관리한다.
• TLS 인증서 오류를 무시하지 않아 잘못된 목적지 연결을 한 번 더 차단한다.
• DNS 응답 변화와 신규 도메인, 비정상 조회 패턴을 관찰한다.

DNS 질의가 실제 주소로 이어지는 과정은 재귀·반복 DNS resolver의 차이에서 더 자세히 볼 수 있다.

DoS와 DDoS는 정상 요청과 자원 고갈을 함께 다룬다

DoS는 service의 가용성을 떨어뜨리는 행위이고, DDoS는 여러 출발지에서 분산해 이를 수행한다. 공격량이 회선이나 upstream 자원을 넘으면 애플리케이션 server 안의 설정만으로 막을 수 없다. 반대로 요청 하나하나는 정상처럼 보여도 비싼 query나 login endpoint에 집중되면 애플리케이션 자원이 먼저 고갈될 수 있다.

대응은 계층별로 나눈다.

• upstream·CDN의 대규모 traffic 흡수와 자동 완화 기능
• connection·request rate limit과 timeout
• cache, queue, circuit breaker와 기능 축소 모드
• WAF의 HTTP 요청 규칙과 bot·abuse 제어
• 용량 지표, 오류율, latency, dependency 상태를 묶은 alert
• 담당자·통신사·cloud provider 연락 경로가 포함된 runbook

WAF는 HTTP 요청 패턴을 다루는 한 계층이지 모든 volumetric DDoS를 해결하는 장비가 아니다. AWS에서 WAF가 연결되는 위치와 검사 한계는 CloudFront·ALB와 AWS WAF의 관계에서 이어서 볼 수 있다.

사고가 의심될 때의 확인 순서

1. 영향받은 사용자, 시간대, endpoint와 자산 범위를 고정한다.
2. 기밀성·무결성·가용성 중 어떤 징후인지 분류한다.
3. DNS, route, TLS, 인증, 애플리케이션 로그의 시간축을 맞춘다.
4. 증거를 보존한 뒤 자격 증명 회수, 경로 차단, 격리처럼 되돌릴 수 있는 조치를 우선한다.
5. 정상화 뒤에는 단일 도구가 아니라 예방·탐지·대응 control이 함께 작동했는지 확인한다.

네트워크 계층의 정상 흐름을 먼저 알아야 이상 징후도 구분할 수 있다. IP·ICMP·ARP·DHCP의 역할과 TLS 1.3 handshake를 함께 보면 공격 이름보다 통신 경계가 먼저 보인다.

참고 자료

• NIST CSRC: Information security 용어 정의
• RFC 2104: HMAC
• RFC 8446: TLS 1.3
• RFC 4033: DNS Security Introduction and Requirements
• CISA: Understanding and Responding to DDoS Attacks