RDP 서비스에 대한 DDoS 공격: 인식하고 대처하세요. Tucha의 성공적인 경험

우리는 "제3자"가 어떻게 우리 고객의 업무를 방해하려고 했는지, 그리고 이 문제가 어떻게 해결되었는지에 대한 흥미로운 사례를 말씀드리겠습니다.

어떻게 시작 됐어?

모든 일은 31월 XNUMX일 아침, 그 달의 마지막 날에 시작되었는데, 그때 많은 사람이 긴급하고 중요한 문제를 꼭 마무리해야 했습니다.

저희 클라우드에서 고객을 위해 여러 대의 가상 머신을 호스팅하는 파트너사 중 한 곳에서 오전 9시 10분부터 9시 20분 사이에 여러 대의 가상 머신에서 문제가 발생했다고 보고했습니다. Windows우크라이나 지사 서버가 원격 접속 서비스에 대한 연결을 수락하지 않아 사용자들이 데스크톱에 접속할 수 없었습니다. 하지만 몇 분 후 문제는 저절로 해결된 것 같았습니다.

통신 채널 통계를 확인해 보았지만, 트래픽 급증이나 감소는 발견되지 않았습니다. 컴퓨팅 리소스 부하 통계도 확인해 보았지만, 이상 징후는 없었습니다. 그런데 그게 무슨 문제였을까요?

그러다가 클라우드에서 약 100개의 서버를 더 호스팅하는 또 다른 파트너가 일부 클라이언트가 지적한 것과 동일한 문제를 보고했고, 서버는 일반적으로 접근 가능했습니다(ping 테스트 및 기타 요청에 올바르게 응답했습니다). 하지만 이 서버의 원격 접근 서비스는 때로는 새로운 연결을 허용하고 때로는 거부했습니다. 이는 서로 다른 사이트의 서버에 관한 문제였고, 트래픽은 서로 다른 데이터 전송 채널에서 들어왔습니다.

다음 트래픽을 살펴보겠습니다. 연결 설정 요청 패킷이 서버에 도착했습니다.

xx:xx:xx.xxxxxx IP xxx.xxx.xxx.xxx.58355 > 192.168.xxx.xxx.3389: Flags [S], seq 467744439, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

서버는 이 패킷을 수신하지만 연결을 거부합니다.

xx:xx:xx.xxxxxx IP 192.168.xxx.xxx.3389 > xxx.xxx.xxx.xxx.58355: Flags [R.], seq 0, ack 467744440, win 0, length 0

이는 문제가 인프라 문제가 아니라 다른 원인으로 인해 발생한 것이 분명하다는 것을 의미합니다. 어쩌면 모든 사용자가 원격 데스크톱 라이선스 문제를 겪고 있는 것일 수도 있습니다. 어쩌면 어떤 악성코드가 시스템에 침투하여 오늘 활성화되었을 수도 있습니다. X데이터 и 페티?

우리가 조사를 진행하는 동안, 다른 여러 고객과 파트너로부터도 비슷한 요청을 받았습니다.
도대체 이 기계들은 무슨 일을 하는 걸까?

이벤트 로그에는 비밀번호 추측 시도에 대한 메시지가 가득합니다.

일반적으로 이러한 시도는 원격 접속 서비스에 표준 포트(3389)를 사용하고 어디에서든 접속이 허용되는 모든 서버에 기록됩니다. 인터넷에는 사용 가능한 모든 연결 지점을 끊임없이 스캔하고 비밀번호를 추측하려는 봇들이 넘쳐납니다(이러한 이유로 "123" 대신 복잡한 비밀번호를 사용하는 것을 강력히 권장합니다). 그러나 그날 이러한 시도의 강도는 너무 높았습니다.

어떻게해야합니까?

수많은 최종 사용자의 설정을 변경하는 데 엄청난 시간을 투자하도록 권장하는 것은 단순히 포트를 바꾸는 것일 뿐인데, 좋은 생각이 아닙니다. 고객들이 불만을 가질 것입니다. VPN을 통해서만 접속을 허용하도록 권장하는 것은 어떨까요? IPSec 연결이 제대로 설정되어 있지 않은 상황에서 허둥지둥 설정을 진행하는 것은 역시 고객들에게 좋은 경험이 되지 않을 것입니다. 하지만 어쨌든 이는 바람직한 현상입니다. 저희는 항상 서버를 사설 네트워크에 숨겨두는 것을 권장하며, 설정 관련 지원을 제공할 준비가 되어 있습니다. 직접 설정을 진행하려는 고객을 위해 사이트 간 또는 로드워리어 모드에서 클라우드에 IPSec/L2TP를 설정하는 방법에 대한 안내를 제공합니다. 그리고 직접 VPN 서비스를 구축하려는 고객을 위해서도 관련 정보를 제공합니다. Windows-서버 – 표준 RAS를 높이는 방법에 대한 팁을 항상 공유할 준비가 되어 있습니다. OpenVPN하지만 우리가 아무리 침착했더라도, 고객에게 문제를 알리기에는 적절한 시기가 아니었습니다. 사용자에게 미치는 영향을 최소화하면서 최대한 빨리 문제를 해결해야 했기 때문입니다.

우리가 구현한 솔루션은 다음과 같습니다.포트 3389에 TCP 연결을 설정하려는 모든 시도를 추적하고 150초 이내에 네트워크에서 16개 이상의 서로 다른 서버와 연결을 설정하려는 주소를 선택하는 방식으로 통과 트래픽에 대한 분석을 설정했습니다.이것이 공격 소스입니다(물론 클라이언트 또는 파트너 중 하나가 동일한 소스에서 그렇게 많은 서버와 연결을 설정해야 하는 실제적인 필요가 있는 경우 이러한 소스를 항상 "화이트 리스트"에 추가할 수 있습니다. 동시에 이 150초 이내에 하나의 클래스 C 네트워크에서 32개 이상의 주소가 감지되면 전체 네트워크를 차단하는 것이 합리적입니다. 차단은 3일 동안 설정되며 이 기간 동안 이 소스에서 공격이 발생하지 않으면 이 소스는 "블랙 리스트"에서 자동으로 제거됩니다. 차단된 소스 목록은 300초마다 업데이트됩니다.

이 목록은 다음 주소에서 확인할 수 있습니다. https://secure.tucha.ua/global-filter/banned/rdp_ddos, 이를 기반으로 ACL을 구축할 수 있습니다.

저희는 이러한 시스템의 소스 코드를 공유할 준비가 되었습니다. 그 안에는 엄청나게 복잡한 것이 없습니다(다음은 몇 시간 만에 "즉석에서" 컴파일한 간단한 스크립트 몇 개입니다). 동시에 이 소스 코드는 이러한 공격으로부터 보호하는 데 사용될 수 있을 뿐만 아니라 네트워크 스캔 시도를 감지하고 차단하는 데에도 적용할 수 있습니다. 이 링크를 따라가세요.

또한, 모니터링 시스템 설정을 일부 변경하여 이제 클라우드 내 가상 서버 제어 그룹이 RDP 연결을 설정하려는 시도에 대한 반응을 더욱 면밀히 모니터링합니다. 1초 이내에 반응이 나타나지 않으면 주의해야 합니다.

해결책은 매우 효과적이었습니다. 고객과 파트너, 그리고 모니터링 시스템 모두 더 이상 불만을 제기하지 않습니다. 새로운 주소와 전체 네트워크가 "블랙리스트"에 정기적으로 추가되는데, 이는 공격이 계속되고 있지만 고객 업무에는 더 이상 영향을 미치지 않음을 나타냅니다.

들판에있는 사람은 전사가 아니다.

오늘 다른 운영사들도 비슷한 문제를 겪었다는 사실을 알게 되었습니다. 일부는 여전히 Microsoft가 원격 액세스 서비스 코드를 변경했다고 믿고 있습니다(기억하시겠지만, 첫날 저희도 같은 문제를 의심했지만 이 버전을 즉시 거부했습니다). 그들은 가능한 한 빨리 해결책을 찾기 위해 최선을 다하겠다고 약속했습니다. 반면, 일부는 문제를 무시하고 고객에게 스스로를 보호할 것을 권고했습니다(연결 포트 변경, 서버를 사설 네트워크에 숨기는 등). 그리고 저희는 첫날에 이 문제를 해결했을 뿐만 아니라, 향후 개발될 더욱 포괄적인 위협 탐지 시스템의 기반을 마련했습니다.

적의 시체가 어느 날 강둑에 떠내려가는 것을 기다리지 않고, 침묵만 지키지 않고, 오히려 우리에게 문제를 즉시 알려주셔서 당일에 문제를 해결할 수 있는 기회를 주신 고객과 파트너 여러분께 특별히 감사드립니다.

출처 : habr.com