Rate Limit 을 처리하는 이유 (브루트 포스/SMS 공격 등)

Rate Limit은 네트워크 트래픽을 제한하는 방법이다.

 

이는 특정 시간 내에 어떤 작업을 반복할 수 있는 횟수를 제한하는 것으로. 예를 들어, 계정 로그인 시도 횟수를 제한하는 것도 Rate Limit의 한 예이다. Rate Limit 은 악의적인 사용자를 막는 데 도움이 되며 서비스에 가해지는 부담을 줄일 수 있다. 

 

참고 자료 : https://www.cloudflare.com/learning/bots/what-is-rate-limiting

Rate Limit 을 하는 이유

1. 보안 및 공격 방지

• 예전에 네이버의 경우에는 Rate Limit 제한이 없어서 이름과 생년월일을 통해 타인의 주민번호 뒷자를 알 수 있었다.
• 일부 사이트의 경우 Rate Limit 이 없었기 때문에 무작위 대입 공격을 통해 타인의 비밀번호를 알 수 있었다. 
• Mail/SMS 또는 2차 인증을 할 때 제한시간을 두는 경우가 있다. 이는 사용자 계정을 보호하기 위한 목적도 있지만 서비스의 비용을 줄기이 위한 목적도 있다. 예를 들어 Mail/SMS 을 발송할 경우에는 서비스 제공자에게 일정 비용을 지불해야 한다. 만약 초당 1000건의 SMS 가 발송되었을 경우 분당 6만건이며 6만건에 대한 SMS 비용은 504,000 원 이다. (알리고 기준)

2. 서버 부하 방지

• 데이터베이스 검색 리소스가 큰 경우 1인당 너무 많은 요청을 보낼 경우 서버에 부하가 발생할 수 있다.
  이것은 서버의 불필요한 비용 증가의 원인이 된다. 
• 클라이언트의 잘못된 개발로 불필요한 API 요청이 발생할 수 있다.
  이런 경우 불필요한 네트워크 비용, 리소스 등이 낭비된다. 

3. API 사용량 제한

• 유저 에이전트, IP 기반, Referrer 에 따라 API 요청을 제한둘 수 있다. 클라우드 플레어에서는 이러한 기능을 제공해준다.
• Open API 을 만들어 외부 사용자에게 공개할 경우 무차별적인 사용으로 인해 서비스가 원활하지 못할 수 있다.
  API 사용량을 제한두어 DDoS 방어, 리소스 최적화, 데이터베이스 부하 방지 등을 할 필요가 있다. 
• API 사용량 제한에 대해 대한 사례로는 뤼튼 블로그도 괜찮았다. 
  https://brunch.co.kr/@wrtntech/21

뤼튼이 ‘Rate Limit’ 문제를 해결한 방법은?

대표 사례

내가 알아본 잘된 예는 에이비앤비가 있었다.

에어비앤비는 새로운 기기에서의 로그인, 비밀번호 찾기 등을 할 때 시간을 제한하여 SMS 발송 횟수를 제한하고 있었다.

 

반면 국내 기업의 유명 스타트업의 경우 1분당 50 건의 SMS 발송이 가능하여 당황하였고 더 이상의 실험은 하지 않았다. 

 

이렇게 방어하는 방식이 아닌 유료화 혹은 2FA 에서 SMS 을 제외하는 기업들도 늘어났으며 대표적이 사례로는 X(구 트위터) 가 있다. 

이러한 조치는 비용을 줄이기 위한 목적도 있지만, 코로나19 팬데믹 시대 이후로 해외에서는 알뜰폰과 같은 사업장에서 SMS 인증을 받을 경우 금전적인 보상이 있었기 때문에 최근들어 무차별적인 SMS 인증이 증가하였다. 

 

이러한 문제로 인해 트위터는 2차인증으로 사용하던 SMS 인증 방식을 유료화로 도입하고 있는 것으로 보인다. 

관련 기사: https://www.yna.co.kr/view/AKR20230219001700091

트위터, SMS 이용한 인증 유료 구독자로 제한 | 연합뉴스

 

공격을 막는 알고리즘

서비스에게도 사용자에게도 좋지 않은 공격을 방어하기 위한 Rate Limit 알고리즘이 있다.

알고리즘에서도 언급되며 실무에 적용 가능한 방식은 5가지가 있으며 실무에서 사용하고 있는 방식은 Sliding Window Counter 이다. 

 

여러 Rate Limit 에 대해 어떤 것이 있을지 고민을 해보았지만, 서비스 이용자 관점에서 가장 적절해 보이던 방식이 Sliding Window Counter 였다. 

 

Rate Limit 을 고려해야 할 만큼의 서비스는 메모리의 처리량을 고려해야 하는 수준의 서비스라 생각되기에 메모리에 효율적인 알고리즘을 도입해야 한다.

1. Leaky Bucket : 네트워크에 일정 시간 동안 허용되는 요청 수를 관리하는 알고리즘으로 FIFO 라고 할 수 있다.
2. Token Bucket : 버킷 용량 이상의 토큰을 저장하지 않으며, 토큰에 여유가 있는 경우에만 요청을 허용한다.
   
3. Fixed Window Counter (=Semaphore) : 정해진 시간 단위로 요청을 제한하는 방식이다. 
   ex. 13시~14시 10번 제한을 두며 14시가 지나면 요청 제한 횟수가 초기화 된다. 
4. Sliding Window Log : 정해진 시간 범위로 요청을 제한하는 방식이다. 
   ex. 1분에 2회 요청이 가능한 경우 01분 14초,  01분 34초에 요청했을 경우 02분 15초 이후에 다음 요청이 가능하며, 그 다음은 01분 35초에 가능하다. 
5. Sliding Window Counter : 슬라이딩 윈도우 로그와 비슷하지만 요청을 비율로 계산하여 시간 내에 요청을 제한하는 방식이다. 
   ex. Log 를 쌓는것이 아닌 비율을 통해 계산한다. 계산할 때 시그마를 이용할 수 있다. (수학 안한지 7년인데 얘 때문에 가끔 본다.)