선택한 단어 수는 입니다.
최소 단어 이상 선택하여야 합니다.
최소 단어 이상 선택하여야 합니다.
선택한 단어 수는 30입니다.
최대 10 단어까지만 선택 가능합니다.
최대 10 단어까지만 선택 가능합니다.
문제 정의
- 본 논문에서는 저대역 DDoS 공격에 대한 대응 방안으로 Time Limit Factor로서 Time Rate Limit와 Blocking Time 및 세션의 상태를 체크하는 필드들을 추가하여 저대역 DDoS 공격을 방어할 수 있는 알고리즘을 구현하였다. 또한 네트워크의 일시적인 장애로 인한 저대역 DDoS 공격으로 오탐 되었을 경우를 대비하여 공격으로 탐지된 정보에 대해 단순 Drop이 아닌 일정시간동안의 Blocking 기능을 제공하여 일정 시간이 지난 뒤 다시 재 접속이 가능하도록 하였다.
제안 방법
- 3개의 저대역 DDoS 공격용 Client의 경우 단순한 세션 연결만 지속하도록 하였고 이후의 Client들은 모두 정상적인 통신을 하기 위한 Client들로 세션이 연결된 이후에 디렉토리 이동 및 파일 다운로드 등에 관련된 명령어들을 실행하였다. 일정시간 경과 후 연결되어 있는 Client들과 접속이 거부되었던 Client들에서 다시 접속 시도 및 세션 연결 유지 테스트 진행 결과 모두 정상적으로 세션이 연결되어 있었다.
- TLF는 저대역 DDoS 방어를 위해 세션의 모니터링을 위해 필요한 모니터링 시간과 최소한의 통신량에 대한 적절한 설정값을 필요로 한다. FTP 서비스 이용과 관련된 최소한의 통신량을 추출하기 위해 1개의 Client에 대해 FTP control 포트인 서비스 21번 포트에 대해서 서버와 접속하는 각 단계별 패킷의 통신량을 [Table. 2]과 같이 테스트 하였다.
- TLF를 적용하여 저대역 DDoS 공격을 타지하기 위한 방어시스템의 보안정책 설정 화면에 Low Level Attack UI를 [Fig. 8]와 같이 추가하였다.
- 각 세션의 상태들을 관리하고 DDoS 탐지 시 해당 세션을 Blocking 하기 위해 [Fig. 6]와 같이 기존의 세션 테이블에 Time Rate Limit, Blocking Time 및 세션 상태관리를 위한 필드를 추가 하였다.
- 이후 TLF가 적용된 모듈을 추가로 설치 적용후 저대역 DDoS 공격에 대한 동일한 테스트 진행 하였다. 고대역 DDoS 는 공격 툴인 AttackPacket을 이용하였으며 저대역 DDoS는 DOS Command 상에서 FTP 서비스를 이용하여 다음과 같은 방법느오 테스트를 진행하였다.
- 기존 DDoS 방어시스템과의 차이점은 세션 테이블에 TLF를 처리하기 위해 여분의 필드들을 추가하였으며, 세션 테이블을 참조하여 각 필터를 통과하기 이전에 패킷의 전달 과정을 처리하는 전처리부의 일부 함수를 변경하였다. 그리고 저대역 DDoS를 실제적으로 탐지하는 Layer 7의 Low Level Attack 처리부와 패킷의 Drop이 아닌 Blocking을 위한 모둘이 추가되었다.
- 기존 DDoS 방어시스템에서의 고대역 DDoS 공격에 대한 테스트를 진행하여 정상적으로 동작되는가를 확인한 다음 저대역 DDoS에 대한 방어가능 여부를 테스트 하였다. 이후 TLF가 적용된 모듈을 추가로 설치 적용후 저대역 DDoS 공격에 대한 동일한 테스트 진행 하였다.
- DDoS 방어시스템은 공격 탐지에 필요한 각 Layer 필터들을 가지고 있으며 각 필터들의 동작 방법을 결정 하기 위한 방법으로 보안정책에 임계치 및 동작 방법등을 설정 하게 된다. 또한 Layer 4이상에서의 Rate Limit 적용 및 컨텐츠의 내용을 분석하기 위해서 세션 테이블을 관리하고 있으므로 이들 주요 관리 Factor에 대한 구조를 변경하여 저대역 DDoS 공격에 대응 할 수 있도록 한다.
- 본 논문에서는 저대역 DDoS 공격에 대한 대응 방안으로 Time Limit Factor로서 Time Rate Limit와 Blocking Time 및 세션의 상태를 체크하는 필드들을 추가하여 저대역 DDoS 공격을 방어할 수 있는 알고리즘을 구현하였다. 또한 네트워크의 일시적인 장애로 인한 저대역 DDoS 공격으로 오탐 되었을 경우를 대비하여 공격으로 탐지된 정보에 대해 단순 Drop이 아닌 일정시간동안의 Blocking 기능을 제공하여 일정 시간이 지난 뒤 다시 재 접속이 가능하도록 하였다.
- 따라서 FTP 서비스에서의 모니터링시 필요한 최소 통신량의 Factor는 10으로 설정 하였다. 또한 적절한 모니터링 시간의 추출을 위해 일반적인 FTP 사용자의 경우 파일 전송 요청까지 소요되는 시간을 알아보기 위해 5명의 다른 사용자들로 테스트를 진행하여 [Table. 3]과 같은 결과를 얻었다.
- 그리고 저대역 DDoS를 실제적으로 탐지하는 Layer 7의 Low Level Attack 처리부와 패킷의 Drop이 아닌 Blocking을 위한 모둘이 추가되었다. 본 논문에서는 위의 방어시스템 구조에서 기존 고대역 DDoS를 위한 부분을 제외하고 저대역 DDoS공격을 위해 새로이 추가된 부분에 대해서만 기술 하였다.
- 기존 DDoS 방어시스템에서의 고대역 DDoS 공격에 대한 테스트를 진행하여 정상적으로 동작되는가를 확인한 다음 저대역 DDoS에 대한 방어가능 여부를 테스트 하였다. 이후 TLF가 적용된 모듈을 추가로 설치 적용후 저대역 DDoS 공격에 대한 동일한 테스트 진행 하였다. 고대역 DDoS 는 공격 툴인 AttackPacket을 이용하였으며 저대역 DDoS는 DOS Command 상에서 FTP 서비스를 이용하여 다음과 같은 방법느오 테스트를 진행하였다.
- 저대역 DDoS 공격이 TCP Three-way handshaking을 거쳐 세션을 정상적으로 연결한 상태에서 단순 세션연결 유지만 요청하며 MaxClient 상태에 도달한 서버에서 더이상의 서비스를 제공할 수 없게 되는 상황을 만들기 위해 서버에서 접속 가능한 MaxClient의 수를 제한하여 테스트를 진행 하였다. 서버에 ProFTP 서비스를 설치하고 MaxClient는 5개로 제한하였으며 입력 기다림에 대한 Timeout은 5분(300초)으로 제한 하였다.
- 이러한 테스트 결과는 FTP 서비스를 이용하여 서버에 접속한 이후 바로 파일 전송을 요청하는 경우에 한하며, HTTP와 같이 세션을 연결함과 동시에 결과를 요구하는 서비스들의 경우 별도의 테스트를 통하여 적절한 Factor들을 추출하여야 한다. 테스트 결과에 따라 TLF 에 필요한 Factor값으로 30초의 모니터링 시간과 10개의 최소 통신량을 TRL의 Factor값으로 설정하였으며 BT와 관련된 Factor로써 저대역 DDoS 공격으로 탐지된 경우 Drop이 아닌 Blocking을 진행하되 60초간의 Blocking Time을 적용하였다. TLF 와 관련된 Factor들을 모두 적용한 모듈을 기존 DDoS 방어시스템에 모듈 형태로 설치하고 4.
대상 데이터
- 시험에 사용된 시스템의 환경은 서버PC는 OS Ubuntu Linux, ProFTP 1.3.2e, DDoS 방어시스템 OS는 전용 OS, 고대역 DDoS 방어시스템 TLF 모듈 탑재, Client PC는 MS Windows 7, 사용 Tool : Dos Command FTP, Wireshark 1.4.2, AttackPacket 2.6.1.2을 사용하여 테스트 하였다.
성능/효과
- FTP 서비스에 대한 TLF 모듈에 적용한 모니터링을 위해 필요한 시간과 최소 통신량에 대한 Factor로 30초와 10개의 설정값이 적절하게 동작되고 있음이 확인되 었으며 TLF 모듈을 추가로 적용할 경우 기존의 고대역 DDoS 방어시스템으로도 저대역 DDoS 공격을 방어할수 있음을 확인하였다.
- 테스트 결과 TLF 모듈을 적용한 이후에도 DDoS 방어 시스템에서는 모니터링이 진행되는 30초 동안은 TLF 를 적용하기 전의 고대역 DDoS 방어시스템과 동일하게 5개 이상의 Client들에 대해서는 서비스 거부 현상이 발생하였다. 그러나 모니터링 시간의 지난 이후부터 세션에 대한 연결 빛 통신상태를 체크한 결과 단순 연결만 되어 있던 저대역 DDoS 공격에 사용되었던 3개의 Client들에 대한 연결은 이루어지지 않고 있었으며 서비스 거부가 발생되었던 2개의 Client에서 FTP 서비스를 위한 세션 연결 및 통신이 정상적으로 이루어짐을 확인 하였다.
- 고대역 DDoS 방어시스템은 저대역 DDoS 공격으로 단순 연결된 세션들에 대해 정상적인 통신으로 인지하여 세션에 대한 차단이 불가하여 저대역 DDoS 공격을 받은 시스템은 리소스 고갈로 서비스 불가 현상이 발생하였다. 반면 TLF를 적용한 저대역 DDoS 방어시스템으로 동일한 테스트를 진행한 결과 정상적인 서비스를 요청하는 세션의 연결은 계속 유지되었지만 저대역 DDoS 공격에 의한 단순 연결만하고 있는 세션을 종료시켜 시스템의 리소스 고갈을 방지함으로써 정상적인 서비스를 제공할 수 있었다.
- 본 논문에서 제안한 TLF 알고리즘을 고대역 DDoS 방어시스템에 적용하게되면 고대역 및 저대역 DDoS에 대한 방어가 가능할 뿐만 아니라, 서비스를 제공하는 시스템에 모듈형태로 추가 적용을 할 경우 저대역 DDoS 공격에 대한 대처가 가능하다. 그러나, Time Limit Factor를 적용한 저대역 DDoS 알고리즘은 네트워크 환경 및 서비스의 제공 방법에 따라 많은 변수들을 가지고 있기 때문에 일률적으로 정해 질 수가 없다는 단점이 있다.
- 이는 파일전송이 필요해 FTP 서버로 접속하는 대부분의 경우 최소한 30초 이내에는 파일 전송에 관련된 모든 패킷이 지나간다고 할 수 있다. 이 결과를 바탕으로 모니터링에 필요한 시간 Factor로 30초를 추출할 수 있었다.
- 지금까지의 결과에서 볼 수 있듯이 기존의 고대역 DDoS 방어시스템에서 방어할 수 없었던 저대역 DDoS 공격에 대하여 TLF 모듈을 적용한 이후에 단순 접속되어 있는 Client들의 통신 상태를 모니터링하여 비정상적인 통신 상태에 있는 세션을 차단함으로써 서비스를 제공하는 시스템에서는 추가적인 리소스를 확보하여 정상적인 사용자들에게 서비스를 제공해 줄 수 있음을 확인하였다.
- 테스트 결과 TLF 모듈을 적용한 이후에도 DDoS 방어 시스템에서는 모니터링이 진행되는 30초 동안은 TLF 를 적용하기 전의 고대역 DDoS 방어시스템과 동일하게 5개 이상의 Client들에 대해서는 서비스 거부 현상이 발생하였다. 그러나 모니터링 시간의 지난 이후부터 세션에 대한 연결 빛 통신상태를 체크한 결과 단순 연결만 되어 있던 저대역 DDoS 공격에 사용되었던 3개의 Client들에 대한 연결은 이루어지지 않고 있었으며 서비스 거부가 발생되었던 2개의 Client에서 FTP 서비스를 위한 세션 연결 및 통신이 정상적으로 이루어짐을 확인 하였다.
- 테스트 결과, 접속을 요청한 시간부터 파일 전송을 요청하는 시점까지 평균 약 26초 정도가 소요되고 있었다. 이는 파일전송이 필요해 FTP 서버로 접속하는 대부분의 경우 최소한 30초 이내에는 파일 전송에 관련된 모든 패킷이 지나간다고 할 수 있다.
- 파일 전송을 위해서는 세션 생성에 필요한 TCP 3-way handshaking을 시작으로 사용자의 아이디 및 패스워드입력과 필요한 파일의 위치나 이름을 확인하는 단계까지만 최소한 10개의 패킷이 Client에서 서버로 전달되어 지므로 파일을 전송하기 위해서는 이보다 많은 패킷이 전달되어야 FTP의 정상적인 통신이 이루어지고 있다고 판단 할 수 있다. 따라서 FTP 서비스에서의 모니터링시 필요한 최소 통신량의 Factor는 10으로 설정 하였다.
후속연구
- 때문에 각 서비스별 운영 환경에 맞는 Factor들을 추출하여 적용하기 위해서는 각 실환경에서의 테스트 및 일정시간의 모니터링을 통하여 결정되어져야 하며 저대역 DDoS 방어를 위한 TLF 알고리즘의 원활한 동작을 위해서는 고대역 DDoS 방어시스템보다 높은 성능처리와 리소스를 필요로 한다. 시스템에 모듈형태로 적용하지 않고 전용 DDoS 방어시스템에 적용하기 위해서는 TLF를 처리하기 위한 리소스와 서비스별 관리방법등에 대한 별도의 추가적인 연구가 이루어져야 한다.
- 이는 향후 더욱 더 많은 사이버 위협들이 발생할 수 있다는 의미이며, 이러한 결과는 선의의 사용자들까지 피해를 입게 되어 정상적인 서비스를 받을 수 없게 될 수 있다. 이렇듯 진화 및 확장되는 사이버 위협에 대한 공격을 막을 수 있는 기술적인 대응을 위한 연구 및 대응방안을 마련하여 보다 안전한 인터넷 환경을 제공하고 선의의 사용자들에 대한 정상적인 서비스를 보장할 수 있는 방안이 연구되어야 한다.
※ AI-Helper는 부적절한 답변을 할 수 있습니다.