TCP는 연결형 프로토콜이다. 이는 클라이언트와 서버가 실제 데이터 교환 이던에 데이터 전송 방법을 정의하는 매개변수들을 협의하며 연결의 시작과 끝에 명확한 구분이 있다는 뜻이다. TCP 는 두 노드 사이에서 신뢰할 수 있고 순서를 유지하는 방식으로 데이터를 전송하므로 애플리케이션 계층 프로토콜은 이런 기능을 자체적으로 내장할 필요가 없다.
반면 UDP 는 비연결형 프로토콜이다. 그러므로 데이터가 의도된 목적지에 도달하리라는 보장도 없고 전송을 보장하는 데이터 형태에 대한 보장도 없다(심지어 UDP 헤더에서는 TCP와 달리 체크섬 계산초자 옵션이다). UDP 소켓을 통해 데이터를 전송하는 애플리케이션은 데이터를 신뢰할 수 있게 전송하기 위한 추가적인 기법을 구현할 수 있지만 이러한 기능은 UDP 소켓이 사용될 때 애플리케이션 계층에 내장되야 한다.
* iptables 를 이용한 전송 계층 헤더의 기록
iptables LOG 타겟은 TCP와 UDP 헤더 기록을 위한 광범위한 장치를 가지고 있다. TCP 헤더는 UDP 헤더보다 훨씬 더 복잡하며, TCP 헤더 항목의 일부는 iptables 정책에 LOG 규칙이 추가될 때 iptables 에 특정 명령 행 인자가 주어질 경우에만 기록된다.
– TCP 헤더의 기록
TCP 헤더는 RFC 793에 정의돼 있으며 TCP 세그먼트(패킷)의 헤더 길이는 포함된 옵션의 수에 따라 다양하다. 옵션(유일한 가변 길이 항목)을 제외한 헤더의 길이는 항상 20바이트다.
INPUT, OUTPUT, FORWARD 체인의 LOG 규칙은 모두 –log-tcp-options 인자를 포함한다. 그러므로 로그 메시지는 TCP 세그먼트가 옵션을 포함할 때마다 알아볼 수 없는 16진수 코드를 포함한다.
iptables 가 TCP 순서번호와 승인 값도 포함하게 하려면 –log-tcp-sequence 인자를 사용하면 된다.
– UDP 헤더의 기록
UDP 헤더는 RFC 768에 정의돼 있다. 길이가 8바이트밖에 되지 않으며 가변 길이 항목은 없다.
LOG 타겟이 UDP 헤더를 나타내는 방법에 영향을 줄 수 있는 특수 명령 행 인자는 없기 때문에 iptables는 UDP 헤더를 항상 동일한 방식으로 기록한다.
앞서 작성한 iptables 정책의 기본 LOG 규칙은 –log-tcp-options 인자를 사용하지만 iptables 는 UDP 패킷이 이런 규칙 중 하나와 일치하는 경우에도 제대로 동작하며, 실제 패킷에 들어있는 정보만을 기록한다. 즉, 존재하지도 않는 TCP 헤더의 옵션 부분을 기록하려고 하지 않는다. UDP 체크섬은 기록되지 않지만 나머지 세 항목(SPT, DPT, LEN)은 모두 포함한다.
* 전송 계층 공격 정의
네트워크 계층 공격의 정의와 마찬가지로 전송 계층 공격은 말단 호스트의 전송 스택 구현에 존재하는 취약점이나 오류 조건(error condition)을 공격하기 위해 전송 계층 헤더의 항목을 악용하는 패킷이나 패킷들로 정의된다.
전송 계층 공격은 다음과 같이 세 분류로 나뉜다.
— 연결 자원 소진 : 목표 호스트나 호스트 집합에서 새로운 연결을 서비스하는 데 사용할 수 있는 자원을 모두 포화시키기 위해 설계된 패킷. 대표적인 예로 SYN 플러딩 형태의 DDoS 공격이 있다.
— 헤더 악용 : 악의적으로 구성됐거나 깨진, 또는 변조된 전송 계층 헤더를 포함하는 패킷. 대표적인 예로는 TCP 연결을 파괴하기 위해 설계된 가짜 RST 패킷이 있다. 스캔 자체가 악의적인 것은 아니지만 포트 스캔도 이 범주에 포함된다.
— 전송 스택 공격 : 말단 스택에 존재하는 취약점에 대한 전송 계층 소택 공격을 포함하는 패킷. 즉, 전송 계층 정보를 처리하는 커널 코드 자체가 공격 목표다. 대표적인 예로는 넷필터 TCP 옵션 처리 코드에 존재하는 취약점에 대해 2004년에 발표된 공격이 있다. 이 공격은 TCP 패킷 자체를 공격하지는 않지만 넷필터 프레임워크를 통해 스택으로 직접 후킹되는 코드를 공격한다.
* 전송 계층 악용
어떤 면에서 전송 계층은 네트워킹된 애플리케이션과 스택 위로 통신하기 전에 나오는 마지막 게이트웨이기 때문에 공격자에게 매력적인 공격 목표다. 전송 계층 정보를 포함하는 수상한 활동의 다수는 노골적인 공격이 아니라 정탐이다.
– 포트 스캔
포트 스캔은 특정 IP 주소에서 어떤 TCP나 UDP 서비스가 접근 가능한지 알아보기 위해 호스트의 정보를 얻어내는 기술이다. 공격자는 시스템 스캔을 통해 접근이나 공격할 서비스의 정보를 얻기 때문에 이는 성공적인 침투의 중요한 단계일 수 있다.
반면 포트 스캔은 단지 어떤 서비스가 이용 가능한지 알아보는 데에도 중요한 단계일 수 있다. 포트 스캔 자체에는 본질적으로 악의적인 어떤 것도 없다. 포트 스캔은 집의 모든 문을 두드려보는 사람에 비유할 수 있다. 그러나 누군가가 집의 모든 문을 두드린다면 이는 그가 집에 침입할 가장 좋은 방법에 대한 정보를 모으고 있을 수도 있다는 의미기 때문에 이를 알아채는 것은 중요한 일이다.
마찬가지로(긍정 오류를 줄이기 위한 튜닝 연습을 한다는 가정하에) 포트 스캔을 탐지하는 것은 좋은 생각이며, 대부분의 네트워크 침입 탐지 시스템은 스캔될 때 알림을 전송할 수 있는 기능을 제공한다.
— 취약한 서비스로 포트 스캔 일치 시키기
포트 스캔을 위해 목표 시스템의 가능한 모든 포트에 대해 전체 시험을 수행할 필요는 없다. 예를 들어 OpenSSH 3.3과 BIND 4.9 서버의 침투에 능숙한 공격자라면 나머지 65,533 개의 포트도 모두 바인딩된 서버를 가진다는 사실을 알아내는 것은 별 소용이 없다. 더욱이 시스템의 모든 포트를 시험하기 위해 생성한 떠들썩한 스캔은 보통의 포트 스캔 임계치를 넘을 가능성이 매우 높기 때문에 IDS 의 경고를 유발하기 십상이다. 공격자 입장에서는 불필요한 주목을 받지 않는 것이 좋다. 공격자는 IDS가 스캔의 실제 출발지를 결정하기 더 어렵게 하기 위해 Nmap의 미끼 (-D) 옵션을 사용할 수 있다. 이 옵션은 포트 스캔을 여러 개의 스푸핑된 출발지 주소로 중복되게 함으로써 목표 시스템이 동시에 여러 개의 독립적인 출발지에 의해 스캔되고 있는 것처럼 보이게 한다. 목적은 IDS 알림을 본 보안 관리자가 실제 스캔 출발지를 알아내기 힘들게 하는 것이다.
— TCP 포트 스캔 기술
TCP 포트의 포트 스캔에는 엄청나게 많은 기술을 사용할 수 있다. 여기서는 Nmap을 사용하여 포트 스캔 기술을 다룰 것이다.
TCP connect() 스캔 – (Nmap -sT)
TCP SYN 또는 반개방(half-open) 스캔 – (Nmap -sS)
TCP FIN, XMAS, NULL 스캔 – (Nmap -sF, -sX, -sN)
TCP ACK 스캔 – (Nmap -sA)
TCP 유휴 스캔(idle) 스캔 – (Nmap -sI)
UDP 스캔 – (Nmap -sU)
또 스캔에서는 Nmap이 스캔을 전송하기 전에 해당 방화벽 시스템의 동작 여부를 알아보지 않게(즉, 호스트의 발견을 생략하게) 강제하기 위해 Nmap -P0 명령 행 옵션을 사용한다. Nmap의 관점에서 볼 때 스캔된 포트는 다음의 세 상태 중 하나에 속한다.
열림 : 포트에 바인딩된 서버가 있으며 접근 가능하다.
닫힘 : 포트에 바인딩된 서버가 없다.
필터링됨 : 포트에 바인딩된 서버가 있을 수 있지만 이와 통신하기 위한 시도는 차단되며 Nmap은 포트가 열려있는지 또는 닫혀있는지 알 수 없다.
— TCP connect() 스캔
통상적인 클라이언트 애플리케이션이 네트워크를 통해 TCP 포트와 바인딩된 서버와 통신하고자 할 때는 로컬 TCP 스택이 클라이언트 입장에서 원격 스택과 연동한다. 두 스택은 애플리케이션 계층 데이터가 전송되기 전에 클라이언트와 서버 사이에 있을 통신을 관리하는 매개변수를 협상해야 한다. 이 협상을 표준 TCP 쓰리웨이 핸드셰이킹(three-way handshake) 이라고 한다.
TCP connect() 스캔의 문맥에서 스캐너는 스캔되는 각 포트에 SYN과 마지막 ACK 패킷을 전송한다. 일반 사용자는 Nmap을 사용해서 이런 방식으로 원격 시스템을 스캔할 수 있다. 어떤 특수 권한도 필요치 않다
— TCP SYN이나 반개방 스캔
SYN 이나 반개방 스캔은 목표 포트가 열렸는지 아니면 닫혔는지를 알려주는 SYN/ACK 이나 RST/ACK 응답을 모으기 위해 스캐너가 각 TCP 포트로 SYN 패킷을 전송한다는 점에서 connect() 스캔과 유사하다. 그러나 이 경우 스캔 시스템은 고의적으로 SYN/ACK 로 응답하는 열린 포트로 ACK 패킷을 반환하지 못하게 하기 때문에 쓰리웨이 핸드쉐이크는 완료되지 않는다. 그러므로 SYN 스캔은 핸드쉐이크가 정상적으로 완료될 수 없다는 점에서 반개방 스캔이라고도 한다.
connect() 시스템 호출은 목표로부터 수신한 SYN/ACK 에 대해 ACK으로 응답하는 바닐라 TCP 스택 코드를 호출하기 때문에 SYN 스캔에는 사용할 수 없다. 그러므로 SYN 스캔에서 전송되는 모든 SYN 패킷은 TCP 스택 전체를 우회하는 기법을 이용해서 생성해야 한다. 이 작업에는 보통 OS 커널의 전송 시 SYN 패킷을 모방하는 데이터 구조를 만들기 위해 원시 소켓을 사용한다.
— 원시 소켓과 원하지 않은 SYN/ACK
원격 시스템에 대한 TCP SYN 패킷을 생성하기 위해 connect() 시스템 호출 대신 원시 소켓을 사용하는 것은 흥미로운 쟁점을 유발한다. 원격 호스트가 SYN/ACK 로 응답하면 스캔 시스템상의 로컬 TCP 스택은 SYN/ACK 를 수신하지만 아웃바운드 SYN 패킷은 로컬 스택으로부터 온 것이 아니다(원시 소켓을 통해 SYN을 생성했기 때문). 그러므로 SYN/ACK 는 스택이 관련되는 한 정당한 TCP 핸드쉐이크의 일부가 아니다. 그러므로 스캐너의 로컬 스택은 SYN/ACK 패킷을 원하지 않은 패킷으로 보고 목표 시스템에 RST을 전송한다. 이러한 스캔 시스템의 동작은 명령어로 스캔을 시작하기 전에 다음과 같은 iptables 규칙을 OUTPUT 체인에 추가해서 막을 수 있다.# iptables -I OUTPUT 1 -d target -p tcp –tcp-flags RST RST -j DROP
Nmap은 SYN 스캔 모드(-sS, 특수 권한을 가진 사용자를 위한 기본 스캔 모드)에 사용되는 TCP SYN 패킷을 직접 만들기 위해 원시 소켓을 사용한다. 이러한 패킷의 특징은 (로컬 TCP 스택을 사용하지 않고) Nmap 에 의해 직접 결정되기 때문에 스택이 일반적으로 생성하는 TCP SYN 패킷과는 상당히 다르다.
실제 TCP 스택이 생성하는 SYN 패킷과 달리 Nmap은 실제 TCP 세션의 협상을 신경쓰지 않는다. Nmap의 유일한 관심사는 원격 호스트의 포트가 열렸는지 (Nmap은 SYN/ACK를 수신함), 닫혀있는지(Nmap은 RST/ACK을 수신함), 아니면 필터링됐는지(Nmap은 아무것도 수신하지 않음)다. 그러므로 Nmap이 전송하는 TCP SYN 패킷은 원격 TCP 스택이 SYN/ACK, RST/ACK으로 응답하거나 응답하지 않게(포트가 필터링된 경우) SYN 플래그를 설정한 TCP 패킷으로서 원격 호스트에 적합하기만 하면 된다.
— TCP FIN, XMAS, NULL 스캔
FIN, XMAS, NULL 스캔은 (RFC를 따르는) 모든 TCP 스택이 포트에서 SYN, ACK, RST 제어 비트를 설정하지 않은 뜻밖의 TCP 패킷을 수신한 경우 특정한 방법으로 응답해야 한다는 사실에 기반해서 동작한다. 포트가 닫혀있다면 TCP는 RST/ACK으로 응답하지만 포트가 열려있다면 TCP는 어떤 패킷으로도 응답하지 않는다.
— TCP ACK 스캔
TCP ACK 스캔 (Nmap -sA)은 스캔되는 각 패킷에 TCP ACK 패킷을 전송하고 열린 포트와 닫힌 포트로부터 RST 패킷(RST/ACK 패킷이 아님)을 기다린다. 목표 포트에서 RST 패킷이 반환되지 않으면 Nmap은 해당 포트가 필터링된 것으로 추정한다.
ACK 스캔의 목적은 포트가 열려있거나 닫혀있는지를 결정하는 것이 아니라 포트가 상태유지형 방화벼에 의해 필터링되는지 여부를 결정하는 것이다. 넷필터 연결추적 하위시스템(상태 매칭을 통해)사용될 때마다 iptables 방화벽은 상태유지형이기 때문에 뜻밖의 ACK 패킷은 방화벽 시스템의 TCP 스택에 도달할 수 없다. 그러므로 RST 패킷이 스캐너로 반환되지 않는다.
— TCP 유휴 스캔
TCP 유휴(Idle) 스캔은 세 개의 시스템(스캔을 시작하는 시스템, 스캔 목표, 이용률이 작은[여기서 이 스캔 이름의 “유휴” 부분이 나왔다] TCP 서버를 실행 중인 좀비 호스트)을 필요로 하는 고급 스캔 방식이다.
유휴 스캔은 IP가 IP 스캑을 통해 전송되는 모든 패킷에 대해 IP ID 값을 1씩 증가시킨다는 사실을 이용해서 공격할 수 있다. 유휴 스캔은 이 사실과 함께 TCP 스캔이 열린 포트로의 SYN 패킷에 대한 응답으로 SYN/ACK 패킷을 전송하거나 닫힌 포트로의 SYN 패킷에 대한 응답으로 RST/ACK 패킷을 전송해야 한다는 요구사항도 이용한다. 또 모든 TCP 스택은 원하지 않은 RST/ACK 패킷을 무시해야 한다. 스캐너는 이러한 사실을 이용해서 좀비 호스트가 스캐너에서 좀비 호스트로 유지되는 TCP 세션동안 IP ID 값을 어떻게 증가되는지 지켜본다. 이와 동시에 스캐너는 목표 시스템에서 좀비 호스트의 IP 주소로 SYN 패킷을 스푸핑한다. 결과적으로 스캐너는 좀비 시스템으로부터 전송되는 패킷의 IP 헤더에 있는 IP ID 값을 감시할 수 있으며, 이 정보를 이용해서 목표 시스템의 포트가 열려있는지 아니면 닫혀있는지를 예측할 수 있다.
스캐너가 좀비의 IP 주소로 스푸핑된 출발지 IP 주소를 가지는 SYN 패킷을 목표 시스템의 열린 포트로 전송하면 목표는 SYN/ACK 으로 (좀비 시스템에) 응답한다. 좀비가 수신한 SYN 패킷은 실제로 원하지 않은 것이기 때문에(스캐너가 스푸핑한 것) 좀비는 RST로 응답하며, 이때 IP Id 카운터를 1만큼 증가시킨다. 스캐너가 닫힌 포트로 SYN 패킷을 전송하면(역시 출발지 IP 주소는 스푸핑됨) 목표 시스템은 RST/ACK 로 좀비에 응답하며, 좀비는 원하지 않은 패킷을 무시한다. 이 경우 좀비로부터 어떤 패킷도 전송되지 않으므로 IP ID 값은 증가되지 않는다.
스캐너는 IP ID 값이 어떻게 증가되는지를 감시해서(목표 시스템의 열린 포트에 대해서는 1만큼 증가되며 닫힌 포트에 대해서는 증가되지 않음) 목표의 어느 포트가 열려있는지 유후할 수 있다. 그러나 idel 스캔의 성공에 가장 중요한 요소는 좀비에서 이용할 수 있는 서비스의 이용률이다. 널리 쓰이는 웹서버는 좀비로 적합하지 않다. 이 경우 모든 TCP 연결이 IP ID 값을 증가시키기 때문에 대부분의 경우 스캐너가 제어할 수 없는 속도로 IP ID 값이 증가되며, 결국 IP ID 값의 변화를 스캔된 포트에 적용할 수 없게 된다.
유휴 스캔의 목표가 되는 시스템은 좀비 호스트로부터 전송된 스푸핑된 SYN 패킷만을 보기 때문에 스캔의 실제 출발지를 알 수 없다. 목표 시스템의 iptables 로그는 정상적인 SYN 스캔처럼 보인다.
— 좀비 호스트에서 기본 버리기 방화벽이 실행 중이라면 유휴 스캔이 동작할 수 있는 유일한 방법은 스캐너가 출발지 포트를 좀비의 열린 TCP 포트로 하드 코딩하는 것이다. 좀비 TCP 스택은 필터링된 SYN/ACK 을 볼 수 없으므로 RST를 전송하지 않을 것이며, IP ID도 증가되지 않기 때문이다. 방화벽이 설치된 경우에는 이용률이 낮은 서비스가 유일하게 이용 가능한 포트일 수도 있다.
– UDP 스캔
UDP는 연결을 수립하기 위한 제어 메시지를 구현하지 않기 때문에 UDP 서비스에 대한 공격은 간단하며, UDP 포트로 데이터를 전송한 후 적당한 시간 내에 응답이 오는지 알아보는 방식으로 수행된다. 서버가 대기하고 있지 않는 필터링되지 않은 포트로 UDP 패킷을 전송하면 ICMP 포트 도달 불가 메시지를 받기 때문에 스캐너는 UDP 포트가 닫혔는지 여부를 쉽게 알 수 있다.
반면 열린 포트로 UDP 패킷을 전송하면 이 패킷이 필터링되지 않았다 하더라도 응답을 전혀 받지 못할 수도 있다. 이는 UDP 서버가 응답해야 할 의무를 가지지 않기 때문이다. 서버가 응답하는지 여부는 전적으로 포트에 바인딩된 특정 서버 애플리케이션의 결정에 달려있다.
방화벽이 특정 포트에 대한 UDP 패킷을 스캐너로부터 차단하면 스캐너 입장에서는 아무 응답도 받지 못하므로 포트에 바인딩된 UDP 애플리케이션이 응답을 하지 않는 것처럼 보인다(이는 필터링 되는 포트가 Nmap에 의해 open|filtered 로 보고되기 때문이다).
– 포트 스윕
포트 스윕(sweep)은 포트 스캔과 유사한 정탐 방법이다. 그러나 포트 스윕은 단일 호스트에서 접근 가능한 서비스를 알아보는 것이 아니라 여러 호스트에 대해 단일 서비스의 이용 가능성을 확인하는 것이다. 보안 관점에서 보면 포트 스윕은 한 시스템이 웜에 의해 침투당해서 새로 감염시킬 목표를 찾고 있는 경우가 많기 때문에 포트 스캔보다 더 심각한 것이다. 네트워크에 다수의 윈도우 시스템(보통 웜의 주요 목표)이 실행 중이면 포트 스윕을 탐지하는 것은 포트 스캔을 탐지하는 것보다 더 중요하다. 그러나 웜에 직면했을 때는 수분 만에 전 세계 수천 대의 시스템을 감염시킨 SQL 슬래머(Slammer) 때처럼 빠른 탐지조차 큰 의미를 지니지 못할 수도 있다. 웜이 탐지된 시점에는 조치를 취하기엔 너무 늦은 경우가 대부분이기 때문이다.
Nmap의 기능을 이용하면 특정 서비스에 대해 네트워크 전체를 쉽게 스윕할 수 있다. 예를 들어 공격자가 SSH 데몬을 공격한다면 Nmap은 다음과 같이 10.0.0.8/8 서브넷 전체에서 SSH 서비스를 이용할 수 있는 모드 개체를 찾을 수 있다.
# nmap -P0 -p 22 -sS 10.0.0.0/8
– TCP 순서 번호 예측 공격
수립된 TCP 연결에 데이터를 삽입하기 위해서 공격자는 데이터 전달을 추적하기 위해 사용되는 현재의 순서 번호를 알아야 한다(또는 추측해야 한다). 순서 번호는 데이터를 전송하기 전에 연결 양측이 각기 선택한 초기 순서 번호에 따라 달라진다. 초기 순서 번호가 무작위로 선택되게 보장하기 위해 일부 TCP 스택에서는 상당한 작업이 수행되며 순서 번호 항목의 크기 역시 공격자가 TCP 연결을 스니핑하지 못할 때 순서 번호의 예측을 어렵게 한다.
네트워크 게이트웨이가 iptables를 실행 중일 때 내부 네트워크의 누군가가 외부 TCP 세션에 대한 순서 번호 예측 공격을 하지 못하게 막는 가장 좋은 방법 중 하나는 내부 네트워크에서 시작된 스푸핑된 패킷을 버리는 규칙을 만드는 것이다.
– SYN 플러딩
SYN 플러딩(flooding)은 스푸핑된 출발지 주소로부터 엄청난 양의 TCP SYN 패킷을 생성한 후 이를 특정 TCP 서버로 전달한다. SYN 플러딩의 목적은 목표 TCP 스택이 SYN/ACK 패킷을 전송하는 데 자신의 자원을 모두 소비하고 절대 받을 수 없는 ACK 패킷을 기다리게 만들어서 서버가 본래 작업을 하지 못하게 하는 것이다. SYN 플러딩은 서비스 거부 공격이다. iptables 는 limit 매치를 통해 어느 정도 SYN 플러딩 공격을 막을 수 있다.
# iptables -I FORWARD 1 -p tcp –syn -m limit –limit 1/s -j ACCEPT
* 전송 계층 응답
– TCP 응답
TCP 문맥에서 전송 계층은 통신을 종료하기 위한 고유의 응답 메커니즘을 가지며, TCP RST(재설정)나 RST/ACK(재설정/승인) 패킷의 형태로 구현된다. 이 패킷은 더 이상 데이터를 전송할 수 없으며 현재 상태와 무관하게 연결이 종료될 거라고 수신 TCP 스택에게 알린다. RST 플래그는 TCP 헤더에서 6비트 단위의 제어 비트 항목의 한 요소다. 이 패킷은 TCP 클라이언트나 서버가 더 이상 지속할 수 없는 상황에 봉착했을 때마다 쓰이며 연결의 양쪽 모두 RST를 전송할 수 있다.
— RST와 RST/ACK
RFC 793에 따르면 TCP 스택이 RST/ACK 패킷을 생성해야 하는 경우는 세 가지 뿐이다. 나머지 경우 ACK 비트를 설정하지 않은 RST 패킷이 전송된다. 더욱이 TCP 세션에서 마지막에 전송된 패킷의 ACK 플래그와 연결을 종료하기 위해 사용되는 RST 패킷 사이에는 반대 관계가 존재한다. 즉, 마지막 패킷이 ACK 플래그를 가지고 있다면 RST 패킷은 ACK 플래그를 포함할 수 없다. 반대로 마지막 패킷이 ACK 플래그를 포함하고 있지 않았다면 RST 패킷은 ACK 플래그를 포함해야 한다.
— 침입 탐지 시스템과 RST 생성
RFC 793은 RST 패킷이 승인 값과 이에 대응되는 ACK 제어 비트를 포함하는 상황을 매우 명확히 명시히고 있지만 많은 침입 탐지 시스템이 TCP 연결을 종료시키기 위해 RST를 생성할 때 RFC를 따르지 않는다.
— SYN 쿠키
SYN 플러딩 공격 하에서 TCP 스택이 잘 동작하게 할 수 있는 흥미로운 방법은 SYN 쿠기를 활성화하는 것이다. 수동형 IDS가 공격에 대한 응답으로 SYN 쿠키를 구현할 수는 없지만 커널이 CONFIG_SYN_COOKIES 지원을 활성화하고 컴파일된 리눅스에서는 다음과 같은 명령어를 이용해서 /proc 파일시스템을 통해 SYN 쿠키를 쉽게 활성화할 수 있다.
# echo 1 > /proc/sys/net/ipv4/tcp_syncookies
– UDP 응답
UDP 스택은 기본적인 응답 매커니즘으로 ICMP를 활용한다. UDP서버가 대기 중이지 않은 포트로 UDP 패킷이 전송되면 보통 응답으로 ICMP 포트 도달 불가(ICMP Port Unreachable) 메시지가 전송된다.
침입 탐지 시스템과 방화벽은 UDP 트래픽에 대한 응답으로도 ICMP 포트 도달 불가 메시지를 생성할 수 있다. iptables REJECT 타겟은 –reject-with icmp-port-unreachable 명령 행 인자를 통해 이러한 응답을 지원한다.
— 방화벽 규칙과 라우터 ACL(Access Control List)
RST로 의심스러운 TCP 연결을 종료시키거나 UDP 트래픽에서 공격을 탐지한 후 ICMP 포트 도달 불가 메시지를 전송하는 것과 같은 전송 계층 응답은 많은 경우에 유용하다. 그러나 이러한 응답은 개별적인 TCP 연결이나 UDP 패킷에만 적용된다. 공격자가 새로운 공격을 시도하지 못하게 막는 영속적인 방어 기술은 없다.
다행히 TCP RST나 ICMP 포트 도달 불가 메시지를 전송하는 것은 방화벽 정책의 차단 규칙이나 공격자 IP와 공격을 받고 있는 서비스에 대한 라우터 ACL과 동적으로 결합될 수 있다.
그러나 일단 공격자에 대한 차단 규칙이 시작되면 이 규칙은 설정 가능한 시간 후에 이를 제거할 수 있는 별도의 코드를 이용해서 관리해야 한다.
Tags: iptables
