비하인드

사용자 경험을 고려한 디도스 방어 with AWS WAF

웹사이트를 운영하다보면 비정상적인 트래픽의 공격은 늘 있는 일입니다. 더군다나 글로벌 서비스를 지향하게 되면, 도메인 자체가 더더욱 많이 노출되기 때문에 그에 상응하여 공격의 대상이 될 확률도 높아집니다.

안전한 웹사이트 운영을 위하여 비디오스튜는 AWS에서 제공하는 WAF를 사용하고 있습니다. 비디오스튜에 접속이루어지기 전에 먼저 WAF라는 수문장을 통과해야만 하는 것이지요. 그 다음엔 비디오스튜에서도 자체적으로 잘못된 요청을 검증하는 몇 가지 장치들을 통해 또 한 번 거르고 있습니다.

< 존재하지 않는 파일들이지만, 숨쉬듯이 들어오는 브루트포스 공격의 흔적들 >

공격의 패턴은 다양하고, 저희도 여러가지 설정을 통해서 다양한 유형에 방어하고 있지만, 이번 포스팅에서는 그중에서도 무차별 디도스 공격에 관한 이야기만을 해볼까합니다.

디도스 공격(DDoS Attack)

디도스 공격은 순간적으로 동시다발적으로 여러개의 요청을 보내 서버의 다운을 유도하는 공격방법입니다. 다운 그 자체도 치명적이지만, 서버에 overflow를 일으켜, 예상치 못한 경우에 나타나는 오류메시지나 설정 등을 통해서 추가적인 공격에 이용할 수 있습니다.

디도스가 막기가 어려운 부분은 아래와 같은 이유들이 있을 것입니다.

• 하나의 컴퓨터에서 발생하는 것이 아님. 즉, 아이피나 에이전트가 다양함. 감염된 좀비피씨 등을 통해서 조종하기에 각 개인은 실제 사용자처럼 요청됨
• 위의 이유로 인해서 디도스에 관한 어떠한 기준점(threshold)를 잡기가 어려움. 지나치게 기준을 낮추면, 정상 사용자가 차단되거나 매번 "로봇이 아닙니다"를 증명하는 불편이 발생함
• 모의실험이 어려움. 일반적인 스트레스 테스트는 단순 처리량에 관한 것이기에 디도스랑은 다른 패턴을 보임
• 순간적인 대량 트래픽으로 인해서, WAF같이 서버리스 방화벽이 아닌 경우, 방화벽 서버 자체도 죽을수가 있음

비디오스튜에서는 디도스 공격도 막으면서 동시에 사용자의 불편도 초래하지 않도록, 두 단계로 나누어서 방어 설정을 하고 있습니다. 느슨한 조건이지만 해체할 수 없는 1단계 차단, 그리고 예민한 조건이지만 해체할 수 있는 2단계 차단으로 구성하고 있습니다.

WAF의 Rate Limit Blocking(1 단계)

제일 첫 단계는 WAF에서 대량의 트래픽에 대해서 1차로 거르는 것입니다. 공격 요청이 실제 웹서버까지 들어가는 경우는 그만큼 검증에 관한 부담이 늘어나는 것이기 때문에, 가장 좋은 것은 WAF선에서 공격을 자르는 것입니다.

문제는 상기했듯이 WAF에서 자르는 요청은 사후 대처가 어렵습니다. 접속 자체가 원찬차단 되는 것이기에, 만약에 정상 고객의 트래픽이었는데 차단이 발생되었다면 수습하기가 다소 어려워집니다. 따라서 조금은 느슨한(이정도면 진짜 진짜 비정상적인 트래픽이라 판단할) 기준으로 잡아줍니다.

지정한 시간안에 받아들이는 요청의 횟수는 [Rules > Add rules > Add my own rules and rule groups]로 추가합니다. 

중요한 것은 Rate-limiting criteria인데, 정답은 없습니다. 왜냐하면 각 서비스마다 고객들의 접속 패턴이 다르기 때문입니다. 다소 타이트하게 설정하고 의도치 않은 차단들이 발생하면 느슨하게 변경해도 되고, 반대로 접근할 수도 있습니다. 시간도 자유로 설정할 수 있지만, 5분으로 하는 경우 그만큼 Rate Limit도 늘려야하는 부분이 있기에(정상이 차단되면 안되니까), 실제 악의적 공격자가 악영향을 주는 텀도 길어지는 것이지요.

포인트는 여기에서의 설정은 기준을 아주 느슨하게 잡는다는 것입니다. 이 설정을 통해서 모든 디도스를 막는게 아니라, 너무 심한 트래픽만 1차로 거르는것이 목적이기 때문입니다.

백엔드 & WAF CAPTCHA(2 단계)

악의적 공격과 단순히 접속이 많은 사용자가 애매하게 섞이는 부분이 바로 이 두번째 단계일 것입니다. 1차 기준보다는 더 타이트한 기준이 적용되어야하고(여전히 걸러야하므로), 동시에 정상 사용자일 수도 있으므로 해체요청이 가능한 수단을 제공해야합니다.

구성 방법은 간단합니다. WAF상에 IP Sets 기능을 이용하여 blacklist ip를 관리하고, 해당 블랙리스트에 있는 IP에 대해서 차단 대신 CAPTCHA 기능을 제공하는 것입니다.

백엔드 코드상에서, 특정 아이피의 유저가 단순히 1분안에 많이 접속하거나, csrf 에러를 많이 발생시키거나 여러 form validation시 실패를 반복하거나, 없는 페이지를 지속적으로 요청하거나 등.. 비정상적인 요청이 반복되면 WAF SDK를 이용하여 IP Sets에 아이피를 동적으로 추가합니다.

그렇게 되면 사용자는 아마존이 띄워주는 구린 디자인의 CAPTCHA를 만나게 됩니다. 이 것을 통과하기 전까지는 WAF가 사용자를 절대 웹서버로 보내주지 않습니다. 사용자가 만약 사람임을 증명하면, `aws-waf-token`이라는 쿠키를 생성하며 그제서야 웹서버로 보내줍니다. 이 쿠키가 살아있는 한 유저는 정상적으로 서비스를 다시 이용할 수 있습니다.

하지만 사용자는 여전히 blacklist ip에 있는 상태입니다. 즉, 허용된 토큰쿠키가 만료되거나 없어지면 다시 CAPTCHA가 뜨게 된다는 것입니다. 따라서 유저가 `aws-waf-token`을 가지고 접근했을 때에는 안내를 통해서 "아이피에 대한 차단 요청"을 한 번 더 하도록 유도하고 있습니다.

< 공격아이피로 오인되었지만, 사람을 인증한 경우 해체관련 안내 >

이후 안내메시지를 클릭하면 구글CAPTCHA를 이용하여 다시 한 번 사람인지 확인하고, 검증 완료시 AWS SDK를 이용하여 해당 IP를 제거하는 API 요청을 일으키면 됩니다.

$token = ''// token from front-end form
$res = remotePost('https://www.google.com/recaptcha/api/siteverify', [], [
    'secret' => '6LfaXX....',
    'response' => $token,
]);
if (isset($res->success) && !!$res->success) {
    // WAF에 등록된 현재의 아이피 제거
    $wafClient = new AwsWaf();
    $wafClient->releaseIp($ip);

    // 안내메시지 중복안내 방어
    setCookie('aws-waf-verified', true, 300);

    return cleanRedirect('/');
}

프론트에서는 `aws-waf-token`가 있고, `aws-waf-verified`가 없는 유저에 대해서만 "수동 해체 요청" 안내메시지를 띄우면 됩니다.

효과

이것은 실제 디도스 트래픽에 대한 그래프입니다. 디도스공격은 특정 시간대에 다양한 아이피로 트래픽을 몰아오기 때문에 저런식으로 폭증하는 형태를 보입니다. 설정된 룰에 의해 상당부분 걸러진 것을 볼 수 있습니다. 여전히 빠져나가는 걸러지지 않는 일부 트래픽이 있는데.. 이 경우 1차조건을 빡빡하게 하면 정상 사용자의 불편을 초래할 수 있으므로, 백엔드에서 조정하는 2차 조건에 대한 보완이 필요해보입니다.

그 밖에...

여기에서는 WAF의 기능 중 Rate Limit Rule와 IP Sets를 이용한 CAPTCHA 차단만을 다루었습니다. 저희팀은 이 Rule외에도 AWS Managed Rule(아마존이 제공하는 여러 패턴의 차단방법)들도 사용중입니다. WAF의 설정에는 정답이 없으므로, 자사의 서비스에 적용하면서 조금씩 커스텀을 하는 방법이 가장 좋다고 생각합니다.