어느날 찾아온 Sentry의 DDOS 공격

어느 평화롭던 업무시간 네트워크 파트에서 연락이 왔다

해외망 트래픽이 급증 하고 있습니다. 차단 해야할까요?

담당하던 서비스는 꽤 자주 공격을 받았기에 출발지 IP를 확인 하고, 차단을 진행하려고 했다.

근데 어디서 많이 본 IP다. 알고 봤더니 클라우드에 올라가있는 설치형 Sentry 장비이다.

오늘은 이 이야기를 해보려고 한다.

우선 Sentry는 배포 해둔 React 프로젝트에 연결 하여 사용 해둔 것 이다.

123.123.123.123 GET /bundle/aaaaa.js? "sentry/22.6.0 (https://sentry.io)"

로그를 보니, User Agent "sentry/22.6.0 (https://sentry.io)" 로 요청이 계속 오고 있었다.

번들링된 js 파일이었는데, 꽤 사이즈가 커서 대역폭을 많이 사용 한것으로 보인다.

왜 Sentry가 계속 요청하는지 처음에 개발팀에서는 파악 하기가 어려웠다.

이것 저것 경우의 수를 보다가 아주 머리 아픈 설정을 보게 된다.

Sentry에서 에러가 캡쳐가 되면 소스맵핑을 위해 javascript 파일을 요청하게 된 것이다.

그래도 이게 js 파일을 샘플링 해서 다운로드 할줄알았는데 에러가 캡쳐되면 무조건 1번씩 요청을 한 것 이다.

마침, 그전날에 배포 한게 한가지 있었는데 거기서 에러가 좀 나고 있던 것 이다..

일단 대역폭 문제가 있었기 때문에, off를 통해 임시적으로 해결 하고 근본적인 문제를 해결 하려고 찾아보았다.

Sentry가 계속 요청을 한 것은 멀지 않은 곳에서 원인을 찾을 수 있었다.

Sentry 입장에서는 버전이 없는 상황이다보니, 에러가 발생할때마다 그냥 새로 다운로드를 받아온 것 이다.

이게 백그라운드에서 에러가 계속 나고 있었으니, 사실상 SELF DDOS를 날린 것 이다..

우린 기본적으로 빌드를 하면 소스맵을 업로드 한다. 근데 왜 또 요청을 보내는 것인지 이해가 되지 않았다.

찬찬히 빌드 히스토리를 찾아보니, 이런.. Jenkins에서 소스맵 배포에 실패 했는데 무시하고 그대로 완료로 처리가 된 것 이다.

Jenkins 에러를 고치고 위에 옵션을 다시 한번 활성화 해보았는데, 트래픽이 줄어든 것을 확인 할 수 있었다.

1. 최근에 배포한 기능이 백그라운드에서 에러를 꽤 많이 유발 하여, Sentry에 에러가 많이 캡쳐되기 시작

2. Sentry 매커니즘에 따라 소스맵이 없었다보니, 직접 요청하여 다운로드를 시도 하였음.

3. 하지만 샘플링은 없고 에러가 뜰때마다 요청을 하니 사실상 Self DDOS를 하고 있던 것 임.

4. Sentry 설정 -> 프로젝트 설정 -> CLIENT SECURITY -> Enable JavaScript source fetching -> off 후 정상화 확인

5. 알고 봤더니, 소스맵 업로드시, 어느 시점부터 인프라 형상 변경으로 오류가 나고 있었는데 인지 하지 못했음

6. (5)의 문제를 해결 하고 확인 해봤더니 모든 것이 정상으로 돌아옴.

아직 왜 Jenkins 설정이 실패해도 무시되게 바뀌었는지는 추적이 어렵긴하지만, Jenkins 설정이 정상이었다면 금방 찾았을건데

이런 삽질을 다른 사람은 하지 않기를 바라며 글을 마친다.

tech.yangs