waf 검증을 위한 ddos툴 사용

박건희·2022년 8월 30일
0
post-custom-banner

waf가 ddos를 막아준다고 하지만 실제로 막아주는지는 알 턱이 없다.

그래서 실제로 막아주는지 확인하기 위해서 실제로 ddos를 발생시켜본다.

ddos를 발생시키는 툴은 참 많았다.

이중에서 "Torshammer"라는 툴을 사용할 것 이다.

왜 이 툴을 사용했냐면 대표적으로 들어오는 ddos 공격 유형중 하나인 slow rate 공격을 해주는
툴이고 쉽게 사용할 수 있기 때문에 사용하게 되었다.

1. 토르 다운로드

Torshammer를 사용하기 위해 우선 해당 툴을 다운로드 받는다.

https://sourceforge.net/projects/torshammer/

다운을 받고 이제 토르를 사용할 vm을 생성해준다.

2. vm 생성

virtualbox에서 CentOS7 vm을 만들어준다.
이름은 Thor라고 해준다.
그리고 테스트용 웹서버 DDOS_TEST라는 이름의 vm을 하나 만들어준다.

그리고 다운로드 받은 알집을 해당 Thor vm으로 가져온다.

알집을 풀어준다.

알집을 풀어준 다음에 DDOS_TEST vm으로 가서
테스트를 위해

[root@localhost ~]# yum install  -y httpd
[root@localhost ~]# systemctl enable --now httpd

를 입력해준다.

그리고 cd /var/www/html/를 입력하여
기존에 만들어진 index.html 파일을 집어넣고
images 폴더를 만들어서 그 안에 사진을 저장한다.

완성된 html의 웹페이지 사지닝다.

3. thor 실행

Thor vm으로 가서 알집을 풀어서 나오는
Torshammer 1.0로 들어간다.

그리고 다음 명령어를 입력하여 DDOS 공격을 개시한다.

[root@localhost Torshammer 1.0]# python torshammer.py -t 192.168.0.101 -p80 -r 500

-t는 대상
-p는 포트번호
-r은 스레드 개수, 작업 스레드 개수이다.

스레드를 한 500으로 늘려버리니까 새로고침할 때 확연하게 차이가 나는것을 확인할 수 있다.
그래서 DDOS_TEST의 아이피를 입력해서 공격을 실행한다.

공격이 없는 경우 새로고침 속도

공격이 발생한 경우 새로고침 속도


공격이 발생했을 때 기존의 ms속도에서 second 단위로 지연속도가 확 올라간것을 확인할 수 있다.

4. waf 생성

이제 실제 aws리소스의 ip나 도메인으로 공격을 해본다.
그래서 공격했을때와 안했을때의 새로고침 속도를 비교해보고
waf를 적용시켜서 어느정도 까지 막아주는지 확인을 해본다.

웹 ACL 생성

먼저 waf를 생성하기 위해 Create web ACL를 클릭한다.

이름은 waf-ddos 라고 하고 리전을 서울로 한다

Add AWS resource를 클릭하여
waf로 방어할 AWS 리소스를 추가한다.

ALB에서 alb-seoul을 선택한다음 Add를 클릭한다.

그리고 Next를 눌러준다.

Add rules를 클릭하고 Add my own rules and rule groups를 클릭한다.
등록된 규칙이 없으니 새로 Rule group을 만들어 준다.

rule 그룹 생성

Rule group을 클릭하여 Create rule group를 클릭해준다.

이름은 waf-ddos로 한다음 지역은 서울로 냅두고 Next를 눌러준다.

이름은 waf-ddos라고 설정한다.
Type은 Rate-based rule라고 한다.

rate limit는 1000으로 둔다.

그리고 ddos가 웹서비스와 웹어플리케이션에 대한 공격하여 자원을 소모시키는것을 막기 위해서
클라이언트 IP 필드를 기준으로 속도 제한을 지정하는 Source IP address를 선택한다.

그리고 Only consider requests that match the criteria in a rule statement를
선택하여 속도 제한에 대한 요청 수 계산 기준에서 규칙 문의 기준과 일치하는 요청만
속도 제한 규칙이 고려하도록 설정한다.

ip set 생성

ip set으로 가서 Create IP set을 클릭한다.

<teamCom는 팀에서 사용하는 팀원들의 ip를 집합시켜 놓은 그룹이다.>

생성한 후 다시 Rule groups 생성 창으로 돌아와서 if a request에서 설정한 조건,

즉 teamCom에서 지정한 ip와 외부에서 들어오는 source ip가 일치하지 않을 경우라는 조건문을 만든다.

만일 위의 조건문이 성립된다면 Action에서 Block을 지정하여 전부 막아버리도록 설정을 한다.
그리고 Add rule을 클릭한다.

next를 누른다.

next를 누른다.

최종적으로 점검을 한 다음에 Create rule group
를 클릭하여 규칙을 만들어준다.

정리를 하자면

webACL을 만드는데 만들다가
속도 기반 규칙을 만들기 위해 rule group 만들고,

팀 컴퓨터의 ip를 제외한 나머지에게 속도 기반 규칙을 적용시키기 위해 팀 컴퓨터의 ip가 정의되는 ip set을 만든다.

  • rule group
  • ip set

을 만들고 다시 webACL로 돌아와서 마저 만들어 준다.

Rule group을 선택한다음 이름을 waf-ddos라고 지정해준다.
그리고 방금 만든 Rule group을 선택해준다.
그리고 Add rule을 클릭한다.

Default web ACL action for requests that don't match any rules
에서 ALLOW를 클릭하고 next를 누른다.

왜 allow를 하냐면 rate limit가 1000이 넘지 않는이상 ddos공격이라고 판단할 수 없기 때문에 방금 만든 규칙과 다르다면 전부 allow로 설정한다.

그리고 계속 next를 누른다음 create web ACL을 클릭해준다.

5. AWS 리소스 공격 (alb 공격)

waf를 다 만들었으니 적용한 alb에 ddos공격을 시도하고 공격이 들어왔을 때와
공격이 안들어왔을때의 속도를 비교해보고

waf를 적용했을때와 안했을때를 비교하여

검증 리스트

  • waf가 없을때
    - 평소 속도
    • ddos 공격을 당했을 때 속도
  • waf가 설치 되었을 때
    - waf가 설치된 상태에서 공격을 당했을 때 속도(waf 검증)

우선 공격을 테스트하기 위한 타겟그룹용 인스턴스를 하나를 만든다.
이름은 ddos_test라고 한다.

네트워크는 다음과 같이 설정을 해준다.

그리고 인스턴스 시작을 클릭해준다.

그리고 대상 그룹에 등록하기 위해서 Register targets를 클릭해준다.

ddos_test를 선택하고 include as pending below를 클릭하여 대상 그룹에 등록을 해준다.
그리고 Register pending targets를 클릭한다.

그리고 해당 인스턴스를 웹서버로 사용하기 위해 httpd를 설치하고 실행한다.

그리고 index파일과 images파일을 /var/www/html 경로에 넣어준다.

그리고 해당 로드밸런서의 dns로 ddos 공격을 실행한다.

Thor vm으로 가서 방금전과 똑같은 공격 명령어를 실행한다.

python torshammer.py -t alb-seoul-182834545.ap-northeast-2.elb.amazonaws.com -p80 -r 500

먼저 공격 전 새로고침 속도를 알아보자.

waf가 있는경우

공격 전 지연속도

이상없이 잘 실행되며 지연시간 또한 ms단위로 문제 없는것을 확인할 수 있다.

공격 후 지연속도

1) ip set에 강의장 ip가 등록되어 있는 경우

이상없이 잘 돌아간다.
waf의 allow그래프만 올라가고 지정 속도 이상으로 들어오는
트래픽은 차단하여 서비스를 방어한다.

그런데 지금 사용하는 ip는 허용된 ip여서 allow가 증가하는지 확인해야한다.

waf의 접속 로그는 증가한다.

ddos가 발생하는 ip가 강의장 ip인데
, 강의장 ip는 속도 기반 규칙에서 제외된다.
그렇다면 정상적으로 서비스가 되는것이 맞는것인가??

맞다. 왜냐하면

그렇다면 ip set에 ip가 없는 경우 ddos가 발생할경우를 알아야한다.

waf가 없는경우

공격 전 지연속도

이상없이 잘 실행되며 지연시간 또한 ms단위로 문제 없는것을 확인할 수 있다.

공격이 있는 경우

타임아웃이 발생하여
공격이 성공적으로 들어간것을 확인할 수 있다.
심한 경우 504 Gateway time-out이 발생하는 것을 확인할 수 있다.
waf가 허용한 ip로 인해서 alb의 서비스가 마비된다.

결론적으로 ip set을 허용했을때와 안했을때를 구분지어야한다.

profile
hihihi
post-custom-banner

0개의 댓글