DoS (Denial of Service)
Ping of death
Ping
- 네트워크와 시스템이 정상적으로 작동하는지 확인하기 위한 유틸리티
- ICMP (Internet Control Messaging Protocol) 사용 : 호스트 서버와 인터넷 게이트웨어 사이에서 메세지를 제어하고 오류를 알려줌 > 정상적으로 전송이 되지 않으면 Reply
3계층 프로토콜로, IP 프로토콜 (비연결성) 과는 다른 프로토콜이다.
인터넷에서 라우터를 거치면서 전송이 되는데, 존재하지 않는 주소로 전송한다면 이 IP패킷은 없어지지 않고 머물게 된다.
TTL (Time to Live) 라우터를 하나 거칠 때 마다 TTL의 수가 줄어드는데, TTL의 수가 0이 되면 패킷은 없어진다. (전송하지 않음)
Ping of death
- 윈도우 95, 98, 레드햇 리눅스 6.0 이하 버전에서 유효
- ICMP 패킷을 최대한 길게하여 (65500 bytes) 공격 대상에게 전송
- 네트워크에서는 패킷을 전송하기 적당한 크기로 분할
- ICMP 패킷은 네트워크에서 수백개의 패킷으로 잘게 쪼개짐
- 공격 대상은 조각화된 패킷을 모두 처리해야하므로 부하가 커짐
ping 프로토콜은 ICMP 프로토콜을 사용하며, ICMP 프로토콜은 무조건 받은 패킷에 대한 응답을 보내야하는데 이러한 과정에서 부하가 커지는 것을 유도하는 방식
ping -n 100 -l 65000 공격대상ip
-n : echo 메세지 개수
-l : 전송 메세지 크기
보안 대책
- ping이 내부 네트워크에 들어오지 못하도록 방화벽에서 ICMP 프로토콜 차단
외부에서 오는 모든 ICMP 프로토콜을 차단하는 법 - 현재 대부분의 시스템의 일정 수 이상의 ICMP 패킷을 무시하게 설정
ICMP를 모두 무시하지는 않지만 일정 이상의 수가 오면 막음 - 운영체제 별 패킷 설치
- 방화벽 / 침입탐지 시스템 : 외부에서 오는 모든 패킷을 검사해야함
SYN Flooding
SYN : TCP 프로토콜에서 3way-handshacking시 SYN을 주고받는다.
- 네트워크에서 서비스를 제공하는 서버에서는 동시 사용자 수가 제한
- 존재하지 않는 클라이언트가 접속한 것처럼 속여 다른 사용자가 서버의 서비스를 제공받지 못하게 하는 공격
- TCP / IP의 구조적 문제를 악용한 DoS
공격자
- 짧은 시간에 많은 양의 SYN만 전송
- 출발지 주소 : 존재하지 않는 시스템의 IP 주소로 위조
공격 대상 (서버)
- 가상의 클라이언트가 ACK 패킷을 보내올 때까지 SYN Received 상태로 대기
- 서버의 가용 동시 접속자 수를 모두 SYN Received 상태로 만듦
서버에 설정된 대기 시간 안에 서버가 수용할 수 잇는 동시 사용자 수의 한계를 넘는 연결 시도
존재하지 않는 IP에 SYN + ACK를 전송하므로, ACK가 절대 다시 돌아오지 않고 모든 서버는 SYN Received에 머물러 있다.
네트워크 캡처 결과
출발지 IP > 도착지 IP로 Flags[S] (SYN)을 보낸다는 의미이다.
출발지가 전부 다른 것이 계속 전송되고 있는 것이므로, 이런 식으로 Flags[S] 만 지속적으로 오는 것을 확인하면 이것이 SYN Flooding 공격이라는 것을 알 수 있다.
보안 대책
- 보안 패치로 대기 시간 축소
- 윈도우 NT / 2K : 255초, 유닉스 / 리눅스 : 60ch, 아파치 : 300초 > 15초 (너무 짧으면 정상적인 얘들도 짤릴 수 있음) - 침입 탐지 시스템 또는 침입 차단 시스템 설치
- 패킷 스캔 시 flag값이 [S] 인 경우에 갑자기 연속적으로 많이 보이면 SYN flooding 공격이라는 것을 확인 (정상적인 것도 막을 수도 있음)
- 매우 짧은 시간에 똑같은 형태의 패킷 수신으로 SYN flooding 공격 수행 - Syn-Cookie 사용
- 클라이언트로부터 SYN 패킷을 받으면, 간단한 인증 정보가 담긴 Syn _Cookie를 시퀀스 넘버 값에 삽입
* SYN으로 인해 원래는 TCP SYN Received 상태가 되어야하지만, 세션 종료시킴
- 클라이언트가 SYN_Cookie가 포함된 값으로 ACK를 보내면 서버는 다시 세션을 열고 통신을 시작함
Boink, Bonk, TearDrop
TCP가 제공하는 연결 지향성을 악용하는 공격 기법이다.
TCP 프로토콜 : 데이터 전송 시 신뢰성 있는 연결 제공
- 패킷을 일정한 크기로 나누어서 전송한다. 따라서 나중에 패킷의 순서를 알아야한다.
- 패킷의 순서가 올바른지 확인
- 중간에 손실된 패킷은 없는지 확인
- 손실된 패킷의 재전송 요구
- 신뢰성이 확인되지 않는 데이터 전송에 대하여 반복적인 재요청과 수정 > 계속 이 요청을 반복하게 되는 공격 기법
공격 대상이 이러한 반복적인 재요처과 수정을 계속하게 함으로써 시스템의 자원을 고갈시키는 공격 > 시퀀스 넘버 조작
TCP 통신 시 데이터 패킷은 시퀀스 넘버를 포함한다.
ex) 패킷 크기 100, 첫번째 패킷 : 1, 두번째 패킷 :101 ...
Bonk : 첫번째 패킷을 1번으로 보낸 후, 두번째, 세번째 ... 패킷 모두 시퀀스 넘버를 1로 조작하여 전송 (패킷 필터링으로 막을 수 있음)
Boink : 처음 몇 개의 패킷은 정상적으로 전송하다가, 중간에서 일정 시퀀스 넘버로 전송 (필터링 가능)
Teardrop : 중첩과 빈 공간을 만들어 시퀀스 넘버를 더 복잡하게 섞음
TearDrop
중간에 빈 공간이 생기거나, 중첩이 생김
이렇게 재조합을 통해서 중간에 빠진 곳에 대해 재요청을 해야하는데, 방화벽이나 침입차단 레벨에서 이게 공격인지 확인하기 어렵다
IP 패킷 재조합 코드의 버그를 이용한 TearDrop 공격
Q ) IP 패킷에 대한 재조합 버그란?
A )
3계층에서는 단위로 데이터그램을 사용한다. 따라서 이 데이터그램은 패킷단위로 구분이 되어 전송이 된다.
패킷을 받는 곳에서는 메모리에 패킷이 들어오는대로 저장을 한다.
패킷의 각각의 시퀀스 넘버를 모르기 때문에, 패킷 재조합 프로그램이 메모리에 있는 패킷들을 읽어서 패킷을 재조합을 한다.
패킷 버퍼에 메모리 순서에 맞는 원래 데이터그램을 완성한다.
즉, IP 패킷 재조합 코드는 메모리에 존재하는 각각의 패킷의 시퀀스 넘버를 확인해서 memcpy로 패킷 버퍼에 순서대로 복사한다.
시작 위치 + 길이 값을 이용하여 패킷 버퍼에 복사하여 패킷 버퍼에 넣는다.
패킷 버퍼에 IP 패킷을 저장하는 과정
- 패킷의 크기가 너무 크지 않은지 검사 함 ( 패킷 버퍼 > 길이 값 검사)
- 패킷의 크기가 너무 작지 않은지 검사 하지 않음
- 패킷의 길이 저장 변수 : 부호있는 변수
- 버퍼 저장 변수 : 부호 없는 변수
- 패킷의 길이가 음수 = 버퍼 저장 변수에서는 엄청나게 큰 패킷 길이로 인식 > 버퍼 오버플로우 발생
패킷 길이 값을 음수로 만드는 과정
- 패킷 헤더 조작으로 중첩된 패킷을 생성
- 시퀀스 넘버를 조작하여 패킷의 길이가 음수가 되도록 함
- offset : 패킷의 시작 위치 (메모리 상의 시작 주소)
- end : 패킷의 끝 위치 = offset + 패킷 길이
- 중첩 발생 시 offset < 이전 패킷의 끝 위치
offset : offset + 중첩 길이 (이전 패킷의 end - offset) - 패킷 길이 = end - (수정된 offset)
ex) 첫번째 패킷은 0~100 / 두번째 패킷은 50~150이다.
첫번째는 offset 0, end 100이므로 그대로 패킷 버퍼에 저장
두번째는 offset 50인데, 중첩 길이가 50(100 - 50)이므로 offset이 100으로 수정되고, end 50으로 총 100~50까지 패킷 버퍼에 저장
ex) 첫번째 패킷은 0~ 190 / 두번째 패킷은 50~170이다.
중첩이 발생했으므로 두번째 패킷의 수정된 offeset = 50 + (190-50) = 190
end = 170이므로 패킷 길이는 170 - 190이 되므로 패킷 길이가 -20이 된다.
패킷 버퍼에 memcpy가 일어날 때는 -20가 아니라 엄청나게 큰 크기로 인식하므로 버퍼 오버플로우가 발생한다.
보안 대책
- 최근 시스템에 대하 파괴력 없음 : packet의 데이터 부분에 데이터가 있는지 확인
- SYN flooding 이나 Ping of Death에 대한 대응책과 동일하게 보안 패치 진행
보안 장비를 이용하여 패킷 검사
재요청 시 게속 packet이 주어지지 않으면 해당 ip에서 더 이상 패킷을 받지 않을 수도 있음
Land
- 패킷을 전송 시, 출발지 IP 주소 = 목적지 IP 주속값
- 조작된 IP 주소값 = 공격대상의 IP 주소
- 패킷이 네트워크 밖으로 나가지 못하고 자신에게 돌아옴
보안 대책
- 운영 체제 패치
- 방화벽 등과 같은 보안 솔루션에서 패킷의 출발지 주소와 목적지 주소의 적절성을 검증하는 기능을 이용하여 필터링
Smurf
그 스머프에서 따온거 맞음
어떤 스머프가 "가가멜이 나타났다" 라고 소리친 후, 다른 스머프에게 확성기를 넘기면 그 스머프가 다른 스머프들에게 공격받음
A가 B를 공격한다고 생각하자.
- ICMP 패킷 사용하며 다이렉트 브로드캐스트를 악용
- ICMP 프로토콜 : 3계층 프로토콜로 연결성을 확인해준다. 따라서 공격 대상과 공격자는 다른 네트워크에 속할 수 있다.
- ICMP 프로토콜은 request와 reply가 오고가기 때문에, B를 공격하고 싶다면 어떤 IP에서 엄청나게 많은 request를 생성하고, 해당 reply가 모두 B로 갈 수 있도록 한다. - 브로드캐스팅 :
- 목적지 IP : 255.255.255.255
- 동일 내부 네트워크 안에 있는 모든 시스템에게 패킷 전송
- 라우터를 넘어가지 않음 (브로드 캐스팅은 같은 네트워크에게만 가능)
여기서 두 가지의 문제점이 발생한다.
공격자(A)와 공격대상(B)가 다른 네트워크에 존재한다.
1 ) 어떻게 다른 네트워크에 브로드캐스팅이 가능한가? (동일 네트워크 내에서만 브로드 캐스팅이 되는 것이 아닌가?)
2) 어떻게 공격 대상에게 reply가 가도록 할 수 있는가?
다이렉트 브로드캐스트
대부분 막혀있음
해당 방법으로 1) 다른 네트워크에 브로드캐스팅을 해결할 수 있음
- 다른 (원격지) 네트워크에 브로드 캐스트
- 네트워크 주소에 맨 마지막에 255를 붙인다. ex) 172.16.0.0 네트워크에 브로드 캐스트 하려면 172.16.0.255
공격
해당 방법으로 2) 공격 대상에세 reply가 가도록 하는 것을 해결할 수 있음
- 출발지 IP : 공격 대상의 IP
- 목적지 IP : 특정 네트워크의 .255
꼭 브로드 캐스팅이 공격 대상의 네트워크를 대상으로 이루어지지 않고 다른 네트워크를 사용할 수도 있음
에이전트에 의한 스머프 공격의 실행
- ICMP Request를 받은 172.16.0.0 네트워크는 ICMP Request 패킷의 위조된 시작 IP주소로 ICMP Reply를 전송
- 공격 대상은 수많은 ICMP Reply를 받게 되고, Ping fo Death 처럼 수많은 패킷이 시스템을 과부하 상태로 만듦
공격 예방
- 모든 라우터가 다이렉트 브로드캐스트를 지원하는 것은 아니기에, 라우터에서 다이렉트 브로드캐스트를 막음
- 출발지 IP를 위조해서 보내는데, 방화벽을 통할 때 출발지 IP가 해당 네트워크 내부 주소가 아니라면 (공격 대상 IP) 막음
DDoS (Distributed Denial of Service)
분산 서비스 거부 공격
인터넷 상에 존재하는 많은 호스트들이 공격자의 명령으로 인해, 수많은 호스트(에이전트)들이 공격 대상을 공격함
- 특성상 대부분 공격이 자동화된 툴을 이용함
- 공격을 증폭시켜주는 중간자들이 필요하다. 중간자가 많을수록 공격이 강해짐
- 공격자가 누구인지 알 수 없도록 한다.
- 공격 툴마다 명칭과 구조가 다르다
- 공격자 : 공격을 주도하는 해커의 컴퓨터
- 마스터 : 공격자에게서 직접 명령을 받는 시스템으로 여러 대의 에이전트를 관리
- 핸들러 프로그램 : 마스터 시스템의 역할을 수행하는 프로그램
- 에이전트 : 공격 대상에 직접 공격을 가하는 프로그램
- 데몬 프로그램 : 에이전트 시스템의 역할을 수행하는 프로그램
예전 : 직접 취약점을 찾아 에이전트를 만듦 | 최근 : 악성코드를 이용하여 에이전트를 만듦 |
- 공격 준비 시간이 오래 걸림 - 공격자의 IP 추적 용이 - 공격 명령어 필터링 가능 |
- 악성 코드(봇)과 결합 - 특정 날짜에 공격 대상을 공격하도록 코드화 - 인터넷을 통해 전파 후 잠복 (잠복 기간엔 공격성 X / 좀비pc or 봇넷) - 본인의 pc가 봇넷인지 확인하기 힘듦 |
'Hacking > Network' 카테고리의 다른 글
네트워크 보안 시스템 (2) | 2024.10.13 |
---|---|
무선 랜 보안 (0) | 2024.10.13 |
Session Hijacking | 세션 하이재킹 (2) | 2024.10.13 |
Spoofing | 스푸핑 (0) | 2024.10.13 |
Sniffing | 스니핑 (0) | 2024.10.12 |