내부 DDOS 공격에 대한 기록 (JVM OOM)

1. 개요

사내 200명을 대상으로 운영중인 서버에서 2개월 간격으로 서버의 오동작을 유발하였던 OOM이슈를 Agent (Client) 의 cURI session 관련기능을 수정하여 해결하였습니다.

해결방법은 비교적 간단하였으나, JVM OOM 이슈를 분석하고 처리하는 과정에서의 배운점을 기록으로 남김으로써 향후에 발생 할 수 있는 이슈에 원활하게 대응하는데 도움이 될 것이라고 생각되어 포스팅을 작성하였습니다.

 

 

 

2. 본론

제가 사내에서 운영중인 서버는 네트워크 접근관리 서버로써 client-side에 Agent 라는 소프트웨어를 설치하여, 서버에 주기적으로 Agent 활성상태와 보안 터널을 Health check 를 하는 방식으로 동작하고 있습니다.

운영을 시작한지 6개월이 넘어가던 시점에 서버에서 JVM OOM 이 최초 발생하였으며, 서버에 heap dump 가 남겨져 있었기에 MAT 로 분석을 하였습니다.

[Server OOM 로그]

캡쳐를 보면 ConcurrentHashMap 을 요소로 갖는 list 가 heap memory의 96%를 사용하여 heap OOM 이 발생한것을 확인하였으며, ConcurrentHashMap 의 용도를 찾아보니 WAS 의 session 정보가 저장되는 메모리로 확인되었습니다.

 

[memory report]

[List 객체 상세분석]

 

또한 Thread stack 로그를 분석한 결과 agent request 를 받아 session 을 생성하기위해 배열을 복사하는 과정에서 OOM 에러가 발생한것을 확인 할 수 있었습니다.

 

[Tread Stack 로그]

 

위의 로그에서 힌트를 얻어 Agent 에서 전송하는 HTTP request 를 검증하고자 서버에서 Agent 가 전송한 Session ID 모두 출력하여 비교를 해본결과, Heath check 시 request 마다 cookie에 서버에서 발급한 Session ID 를 전송하지 않는것을 확인하였고, Agent (C++) 의 소스를 확인해보니 cURI 모듈에서 session 유지처리를 하지않는것이 확인 되었습니다. 

 

 

이후 원인의 정확한 검증을 위해 jmeter script (100개 thread, 1s 간격) 로 WAS 서버에 부하를 발생시켜서 에러를 재현하였으며, HTTP session 을 유지했을 때, 그렇지 않은경우보다 heap memory 가 6배 감소하는것을 확인 할 수 있었습니다

 

[수정 전 Heap memory 모니터링]

[수정 전 GC 모니터링 : Session 유지 설정]

 

 

[수정 후 Heap memory 모니터링]

[수정 후 GC 모니터링 : Session 유지 설정]

 

이후 수정된 Agent 로 충분한 테스트를 거쳐 운영에 반영을 하였으며, 이후부터 지금까지 해당 heap memory 이슈가 발생하지 않고 있습니다.

 

 

3. 결론

 

WAS 서버가 Agent 로부터 의도하지않은 DDOS 공격을 받게되어서 분석,모니터링,테스트,코딩 등으로 2개월 정도 메인 업무 이외의 시간을 할애하여 분석하고 해결하였습니다.

그로 인해 JVM OOM 이 발생하였을때 활용 할 수 있는 방법들 (MAT, Jmeter, Vitual VM 등) 관련한 기본기술을 습득 할 수 있었습니다.

또한  2개월 간격으로 발생하는 OOM으로 인해 서버가 다운되어 사용자가 내부 네트워크에 접근하지 못하고 업무에 제약을 받는것을 보고 안정적인 서버운영의 중요성도 깨달을 수 있었습니다.