안녕하세요 개발팀 진우 매니저입니다.
TV나 뉴스 등을 보다 보면 "어디어디가 해커로부터 사이트가 해킹되어 개인 정보를 탈취당했다!", "어디어디는 랜섬웨어에 감염되어 해커로부터 비트코인을 요구받았다!" 등의 홈페이지가 공격을 받았다는 내용의 기사를 종종 볼 수 있는데요, 이렇게 공격을 시도하는 공격 기법에는 방법이나, 피해를 보는 것에 따라 여러 가지 종류(DDoS, CROS, Injection 등)가 있습니다.
이중 오늘은 아임웹은 DDoS 공격을 막기 위해서 어떠한 노력들을 하고 있는지 다뤄보고자 하며, [DDoS 공격이란 무엇인가부터]시작하여 [앞으로 더 나아가야 할 방향]까지 이야기해 보도록 하겠습니다.
DDoS 공격이란 무엇인가
DDoS (Distributed Denial of Service attack)으로 불리는 DDoS 공격은 특정 서버나 네트워크 장비에 분산적으로 수많은 접속을 시도, 리소스를 부족하게 하여 다른 이용자가 정상적으로 서비스를 이용하지 못하도록 하는 공격 기법입니다.
쉽게 이야기하자면 한 번에 하나씩밖에 일을 못하는 A라는 로봇에게 적게는 십여 개부터 많게는 몇천 개에 달하는 일을 한 번에 시켜서 정신을 못 차리게 하고 고장이 나도록 유도하는 공격이라고 보시면 됩니다. (여기서 A라는 로봇이 위에서 말한 특정 서버나 네트워크 장비가 되는 것입니다.)
그렇다면, 아임웹은 어떻게 대비하고 있나!
가. WebServer Application IP 차단
처음 시도했던 방법은 유입되는 IP를 수집하여 Application 단에서 프로그래밍을 통해 Black-list에 등록하여 차단하는 방법을 사용했었습니다. 이 방법은 Application 단에서 IP를 차단하는 방법이기 때문에 실제로 IP 차단이 되는 등 유의미한 효과를 가지기는 했었습니다. 하지만 VPC를 넘어 WebServer까지 접근을 한 상태에서 IP를 차단한 것이기 때문에 WebServer에 발생되는 리소스는 줄이지 못하는 문제가 있었습니다.
- 장점: IP를 실제로 차단하여 Application 단에 접근하는 것을 막을 수 있음
- 단점: WebServer까지는 접근을 하는 것이기 때문에 해당 부분에 리소스 증가를 줄이지는 못함
나. Application + Nacl을 이용한 IP 차단
이 조합을 이용한 방법에 앞서 Nacl이라는 것에 대해 간략한 설명이 필요할 거 같습니다. Nacl는 AWS VPC 서비스에서 제공하는 NetworkACL의 약자로 간략히 말씀드리면 VPC 단 가장 앞에서 특정 IP들을 판단하여 Inbound 및 Outbound를 컨트롤하는 문지기라고 생각하시면 좋을 거 같습니다.
본론으로 돌아와 그렇다면 Application과 Nacl을 조합한 IP 차단을 어떻게 했었는지 말씀드리겠습니다. "가."의 문제는 IP 차단은 실제로 동작하지만 WAS까지의 접근은 허용되어야 하며 이를 통해 발생되는 리소스 증가가 문제였습니다. 때문에 "가."에서 이용했던 차단을 위한 IP 검증률은 그대로 가져가되 IP 차단을 하는 위치를 변경해 보면 될 것으로 판단하여 이 차단하는 위치를 Application 단에서 Nacl 단으로 변경하게 된 것입니다.
이를 통해 최초 접근하는 리소스는 WAS 단까지 접근이 되었지만, 그 이후에 Nacl 단 차단룰에 IP가 추가되게 되고 더 이상 본 서비스 VPC에 접근하지 못하는, 즉 저희가 원했던 WAS 단의 리소스 감소 및 IP 차단이라는 두 마리 토끼를 모두잡는 효과를 거두게 되었습니다.
하지만... 언제나 그렇듯 일이 그렇게 쉽게 풀릴 리가 없었습니다...
Nacl에는 치명적인 단점이 존재했는데 그것은 바로 추가할 수 있는 IP 수의 제한이 있다는 것이었습니다. 생각해 보면 제한이 없다면 네트워크 성능의 악영향이 발생되기 때문에 제한을 두는 것은 너무나도 당연한 것이었습니다. 그렇지만 과거의 저는 그것은 알지 못했고, 나름 완벽할 줄 알았던 방어 대책은 또 다른 변화가 필요했습니다.
- 장점: IP를 실제로 차단하여 VPC 자체에 접근하는 것을 막을 수 있음 (WAS 리소스 감소 효과)
- 단점: Nacl 룰에 추가 가능한 IP의 개수의 제한이 있음
Network ACL과 Security Group
다. Application + AWS WAF를 이용한 IP차단
AWS에는 전 세계 각지에서 발생되는 공격들의 패턴을 파악해두었다가 대응(차단 또는 제한 등)을 할 수 있게 해주는 서비스를 제공하는데 그것이 바로 WAF입니다.
앞선 방법에서 경험한 것들을 토대로 '가능한 VPC 단까지 진입조차 못하게 한다면 좋겠다', '혹시나 WAS 단까지 접근을 하더라도 그 양이 줄었으면 좋겠다.'라는 목표를 수립했고, 현 상황에서 그것을 모두 충족할 수 있는 서비스는 WAF였습니다. 하지만 현재 인프라에 WAF를 붙이는 것은 굉장히 까다로운 작업이었습니다.(이 부분은 별도의 포스팅을 통해 회고하도록 하겠습니다.) 갖은 노력 끝에 WAF를 붙이는 것에 성공을 했고, 이를 통해 얻은 효과에 대해 말씀드리도록 하겠습니다.
"나."에서 발생했던 단점은 Nacl 룰에 개수 제한이 있다는 것인데 WAF는 이 수치가 굉장히 높았습니다. 더불어 WAF 자체가 지능적인 방화벽이기 때문에 탐지패턴 등을 지정해 주면 자체적으로 접근하는 리소스에 대해 탐색 및 차단을 해주는 기능을 제공하는 것이었습니다. WAF가 가장 앞단에서 공격성 접근을 막아준다면 VPC 단까지 진입되는 리소스 자체도 막을 수 있는 구조가 되기 때문에 가장 이상적인 구조였고 그렇게 동작되기를 바랐습니다.
그렇지만 이 탐지패턴은 최대 5분 동안의 접속 로그를 기준으로 판단 후, 차단을 해주는 로직이었기 때문에 실제 DDoS를 막기에는 역부족이었습니다.(DDoS 발생 시 보통 1분 이내로 엄청난 트래픽이 몰리게 됩니다)
그래서 WAF에서 차단되지 못하고 들어오는 공격성 접근에 대해 Application 단에서 2차 탐지를 하고 탐지가 완료된 경우 Waf Block List에 추가를 해주는 방향으로 세팅을 하게 되었습니다.
위와 같은 세팅을 통해 아직 부족하지만 그래도 어느 정도 원하는 방어 대책을 수립하게 되었습니다.
- 장점: IP를 실제로 차단하여 VPC 자체에 접근하는 것을 막을 수 있음 (WAS 리소스 감소 효과), IP 추가 Limit이 굉장히 큼
- 단점: WAF는 최대 5분간의 로그를 분석해서 차단을 하기 때문에 완벽한 차단은 이루어지지 않음(Application 단에서 추가 조치 필요)
CloudFront 와 WAF를 함께 사용하는 구조
앞으로 더! 더! 더! 나아가야할 방향
지금까지 아임웹이 DDoS에 어떻게 대처해 왔는지, 어떠한 보안 솔루션을 적용하며 연구해 나가고 있는지를 되돌아보았습니다.
DDoS를 방어할 수 있는 보안 솔루션이 점점 강력하고 좋아지는 만큼 DDoS 공격 또한 더 많은 양, 다양한 공격 패턴으로 진화하고 있습니다. DDoS 를 100% 방어할 순 없겠지만 꾸준하게 계층별로 보안을 추가하면서 피해를 완화하고 고객님들의 사이트를 보호하는 것이 최선이라 생각합니다. 지금도 아임웹 개발팀은 최선이라 생각되는 보안 솔루션을 끊임없이 연구하고 있습니다.
고객님들께 원활한 서비스를 제공할 수 있도록 아임웹 구성원 모두가 여러 방면으로 노력하고 있습니다.
그럼 이만 다음 포스팅에서 뵙겠습니다😄
by 개발 진우
