개요
다른 사람들이 작성한 개발 블로그 글들을 보면, 개인 프로젝트에 AWS 같은 클라우드 서비스를 사용하다가 트래픽 공격이나 S3 버킷에 대량 파일이 업로드되어 수천만원 단위의 요금 폭탄을 맞는 사례를 종종 접할 수 있다. 이런 사례를 접하다 보니, 자연스레 인스턴스 보안 설정에 더욱 신경을 쓰게 된다. 그런데 하루는 문득 이런 의문이 들었다.
특정 IP 대역에만 인바운드 규칙을 허용하면 정말 안전할까?
누군가 IP 주소를 속여서 접근할 수는 없는 걸까?
위의 의문에서 출발하여 네트워크 통신의 하위 계층의 동작 방식과, 통신의 신뢰성 보장 원리를 찾아보았고, 학습한 내용을 정리해본다.
IP 주소 기반 접근 제어
네트워크의 가장 기본적인 보안은 방화벽이나 라우터를 통해 이루어진다. 이들은 네트워크에 진입하는 데이터 패킷을 검사하여 누구를 들여보내고 누구를 막을지 결정한다.
IP 패킷 헤더는 위와 같은 구조를 가지는데, 데이터 패킷이 도착했을 경우에는 패킷의 출발지 IP주소(Source Address)를 확인하여 출발지 IP주소가 접근이 허용 목록(Whitelist)에 해당하는지 검사한다. 만약 출발지 IP가 허용 목록에 있다면 패킷을 통과시키고, 없다면 패킷을 차단하게 된다.
이러한 규칙은 클라우드 환경에서 매우 흔하게 사용한다. 예를 들어, AWS EC2 인스턴스의 보안 그룹에서 특정 IP 주소에만 SSH 접근을 허용하도록 인바운드 설정을 하는 것이 바로 이 원리를 이용한 것이다.
TCP 3-way HandShake & IP Spoofing
그런데 만약 이 출발지 IP 주소가 위조된 것이라면 어떻게 될까? 택배를 발신 주소를 위조하여 전송할 수 있는 것처럼, 공격자는 자신의 진짜 IP를 숨기고 허용된 IP인 척 위장할 수 있다. 이를 IP 스푸핑(IP Spoofing)이라고 한다.
단순히 패킷의 출발지 주소만 검사하는 방식으로는 이런 위장을 막아낼 수 없다. 그래서 신뢰성이 중요한 통신(TCP)에서는 연결을 시작하기 전에 특수한 절차를 거치는데, 이것이 바로 TCP 3-way Handshake이다.
TCP 3-way Handshake는 두 호스트가 서로 연결을 맺을 의사가 있음을 확인하고, 초기 시퀀스 번호를 교환하여 동기화하며 양방향 통신이 가능한지 확인하는 과정으로, 세부적으로는 아래와 같은 단계를 거친다.
1단계: 연결 요청 (SYN)
"안녕하세요 B님, 저는 A입니다. 통신 가능할까요? 저는 지금부터 100번부터 번호를 매기겠습니다."
이 단계에서 클라이언트는 서버로 TCP 패킷을 하나 보낸다. 이 패킷에는 아래와 같은 두 가지 중요한 정보가 담겨 있다.
- SYN (Synchronize) 플래그
- 연결을 시작할 때 사용하는 플래그
- 초기 시퀀스 번호 (Initial Sequence Number, ISN)
- 클라이언트가 무작위로 생성한 숫자이다. 이는 앞으로 데이터를 주고받을 때, 데이터 조각들이 뒤섞이지 않도록 각 조각에 붙일 일련번호의 시작점을 서버에게 알려주는 역할을 한다.
서버는 이 SYN 패킷을 받고 클라이언트가 통신을 원한다는 사실과, 앞으로 받을 데이터의 번호가 몇 번부터 시작될지 인지하게 된다.
2단계: 요청 수락 및 확인 (SYN-ACK)
"100번 번호가 매겨진 요청을 잘 수신했습니다 A님. 저도 당신에게 데이터를 보낼 준비가 되었습니다. 저는 200번부터 번호를 매길게요."
클라이언트의 요청을 받은 서버는 응답 패킷을 보낸다. 이 패킷은 두 가지 역할을 동시에 수행한다.
- ACK (Acknowledge) 플래그
- 요청을 잘 받았다는 확인 응답이다. 서버는 클라이언트가 보낸 시퀀스 번호(100)에 1을 더한 101을 Acknowledgement Number 필드에 담아 보낸다. 이는 100을 잘 수신하였으니 101번 데이터를 보내면 된다는 뜻을 가진다.
- SYN (Synchronize) 플래그
- 서버 역시 클라이언트에게 데이터를 보낼 준비가 되었음을 알려준다. 이때 서버도 자신만의 초기 시퀀스 번호(e.g. 200)를 생성하여 함께 보낸다.
이 단계가 IP 스푸핑을 차단하는 핵심 단계이다. 만약 공격자가 A를 사칭하여 연결 요청을 보냈다면 서버가 응답한 이 패킷은 A에게 보내지고 A는 자신이 연결 요청을 한 적이 없다고 서버에 전달할 것이다. (RST)
3단계: 최종 연결 확립 (ACK)
"200번 번호가 매겨진 요청을 잘 수신했습니다 B님. 이제 통신을 시작해요!"
서버로부터 SYN-ACK 패킷을 받은 클라이언트는 마지막으로 확인 패킷을 서버에 보낸다.
- ACK (Acknowledge) 플래그
- 연결 요청(SYN)과 확인 응답(ACK)을 모두 잘 받았다는 최종 확인
- 클라이언트는 서버가 보낸 시퀀스 번호(200)에 1을 더한 201번을 Acknowledgement Number 필드에 담아 보낸다.
이 3단계 패킷이 서버에 도달한 시점에서 양쪽 모두 서로가 통신 가능한 상태임을 확인을 마치게 되고 연결을 수립하게 된다.
TCP Sequence Prediction Attack
그럼 3-way Handshake를 통해 연결을 수립한다면 그 상대는 항상 신뢰할 수 있는 것일까? 공격자들은 이 방어막을 우회하거나 무력화하기 위한 또 다른 방법을 찾아냈다. 3-way Handshake의 서버가 보내는 2단계 응답(SYN-ACK)을 진짜 클라이언트가 받지 못하게 만드는 방법이다.
1단계: 목표물 마비 (DDoS 공격)
먼저 공격자는 연결을 가로챌 클라이언트 A에게 SYN Flooding과 같은 DDoS 공격을 가하여 네트워크 대역폭을 가득 채우거나 시스템 자원을 고갈시킨다.
2단계: 연결 시도 (IP 스푸핑)
클라이언트 A가 마비된 후, 공격자는 자신의 IP를 클라이언트 A의 IP로 위조하여 목표 서버에 1단계 연결 요청(SYN)을 전송한다.
3단계: 응답 가로막기 및 연결 가로채기
서버는 이 요청을 받고, 클라이언트 A의 IP 주소로 응답(SYN-ACK)을 보내지만, 클라이언트 A는 현재 DDoS 공격으로 마비되어 있어 패킷을 처리하지 못해 RST 패킷을 전송하지 못한다.
이때 공격자가 클라이언트 A가 보냈어야 할 ACK 패킷을 서버에 보내고, 서버는 정상적인 ACK를 받았으므로, 클라이언트 A와 연결이 성공적으로 수립되었다고 믿게 된다. 하지만 실제로 서버와 통신하는 주체는 클라이언트 A로 위장한 공격자이다.
다만, 이 공격이 성립하기 위해서는 아래의 두 가지 기술이 필요하다.
- DDoS를 이용한 클라이언트 마비
- TCP 시퀀스 번호 예측
클라이언트 측의 대응이 허술하여 DDoS에 쉽게 마비가 되더라도, 현대 네트워크 환경에서는 TCP 시퀀스 번호를 예측하는 일이 사실상 불가능에 가까운 일이다.
암호화를 통한 패킷 스니핑 방어
공격자가 시퀀스 번호를 알아내는 가장 확실한 방법은 클라이언트와 서버 사이에 오가는 패킷을 직접 엿보는 패킷 스니핑이다.
하지만 오늘날의 대부분의 인터넷 통신은 HTTPS와 같은 프로토콜을 통해 암호화되어 있다. 암호화는 패킷의 내용 전체를 잠가버리기 때문에, 공격자가 중간에 패킷을 가로채더라도 시퀀스 번호를 포함한 어떤 정보도 해독할 수 없다.
난수화를 통한 블라인드 공격 방어
패킷을 엿볼 수 없다면, 공격자는 순전히 추측을 통해 시퀀스 번호를 예측해야 한다.
구형 운영체제에서는 시퀀스 번호를 규칙적인 패턴으로 생성하는 취약점이 있었지만 현대의 운영체제들은 이 문제를 대부분이 해결했다. 가령 리눅스의 경우, 2.0 이후부터는 랜덤에 가까운 알고리즘으로 난수를 생성해내기 때문에, 추측하는게 불가능에 가깝다.
맺음말
현대의 암호화 표준과 OS의 보안 강화 덕분에 TCP 시퀀스 번호를 예측하여 연결을 가로채는 공격은 현실적으로 성공하기 불가능에 가까운 공격 방식이다.
우리가 AWS 콘솔에서 무심하게 설정하는 보안 그룹 인바운드 설정 아래에서는 위와 같이 복잡한 과정을 통해 통신의 신뢰성을 지키고 있다. 막연하게 설정만 하다가 같은 의구심이 들었던 누군가에게 이 글이 조금이나마 궁금증을 해소해줄 수 있기를 바라며 글을 마친다.
참고자료
- IP 패킷 헤더 이미지 출처: https://networklessons.com/cisco/ccna-routing-switching-icnd1-100-105/ipv4-packet-header
- 3-way Handshake 이미지 출처: https://medium.com/@oumasydney2000/understanding-the-tcp-three-way-handshake-a-fundamental-pillar-of-internet-communication-53c9230724c2
- https://en.wikipedia.org/wiki/TCP_sequence_prediction_attack
- https://www.tech-faq.com/tcp-sequence-prediction-attack.html