RDP 서비스에 대한 DDoS 공격: 인식하고 대응합니다. Tucha의 성공적인 경험

"제XNUMX자"가 어떻게 우리 고객의 업무를 방해하려고 했는지, 그리고 이 문제가 어떻게 해결되었는지에 대한 멋진 이야기를 들려드리겠습니다.

어떻게 시작 됐어?

이 모든 것은 많은 사람들이 긴급하고 중요한 문제를 해결할 시간이 절실히 필요한 월말인 31월 XNUMX일 아침에 시작되었습니다.

우리 클라우드에서 클라이언트의 여러 가상 머신을 유지하는 파트너 중 한 명이 9시 10분부터 9시 20분까지 우리 우크라이나 사이트에서 실행되는 여러 Windows 서버가 원격 액세스 서비스에 대한 연결을 허용하지 않는다고 보고했습니다. 데스크톱에 로그인하려고 시도했지만 몇 분 후에 문제가 저절로 해결되는 것 같았습니다.

통신채널 운영에 대한 통계를 올렸으나 트래픽 급증이나 장애는 발견되지 않았다. 컴퓨팅 리소스 로드에 대한 통계를 살펴보았는데 이상이 없었습니다. 그게 뭐였지?

그런 다음 클라우드에서 약 XNUMX개 이상의 서버를 호스팅하는 다른 파트너는 일부 고객이 언급한 것과 동일한 문제를 보고했으며 일반적으로 서버에 액세스할 수 있는 것으로 나타났습니다(핑 테스트 및 기타 요청에 올바르게 응답). 이러한 서버의 원격 액세스 서비스는 새로운 연결을 수락하거나 거부합니다. 우리는 다른 사이트의 서버에 대해 이야기하고 있었고 트래픽은 다른 데이터 전송 채널에서 발생했습니다.

이 트래픽을 살펴보겠습니다. 연결 요청이 포함된 패킷이 서버에 도착합니다.

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

이는 문제가 인프라 운영상의 문제로 인해 발생하는 것이 아니라 다른 문제로 인해 발생한다는 것을 의미합니다. 어쩌면 모든 사용자가 원격 데스크톱 라이선스에 문제를 겪고 있을까요? 아마도 어떤 종류의 맬웨어가 시스템에 침투하여 몇 년 전과 마찬가지로 오늘 활성화되었을 수도 있습니다. XData и 페티?

문제를 정리하는 동안 더 많은 고객과 파트너로부터 유사한 요청을 받았습니다.
이 기계에서는 실제로 무슨 일이 일어나는가?

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

일반적으로 이러한 시도는 표준 포트(3389)가 원격 액세스 서비스에 사용되고 어디에서나 액세스가 허용되는 모든 서버에 등록됩니다. 인터넷은 사용 가능한 모든 연결 지점을 지속적으로 검색하고 비밀번호를 추측하려고 시도하는 봇으로 가득 차 있습니다(이것이 "123" 대신 복잡한 비밀번호를 사용하는 것이 좋습니다). 그러나 그날 이러한 시도의 강도는 너무 높았습니다.

어떻게해야합니까?

수많은 최종 사용자가 다른 포트로 전환하기 위해 설정을 변경하는 데 많은 시간을 소비하는 것을 고객이 권장합니까? 좋은 생각은 아닙니다. 고객이 만족하지 않을 것입니다. VPN을 통해서만 액세스를 허용하는 것이 좋습니다? 서두르고 공황 상태에서 IPSec 연결을 설정하지 않은 사람들을 위해 IPSec 연결을 늘리는 것은 아마도 그러한 행복이 클라이언트에게도 미소를 짓지 않을 것입니다. 어쨌든 이것은 신적인 일이라고 말해야 하지만, 우리는 항상 개인 네트워크에 서버를 숨길 것을 권장하고 설정을 도울 준비가 되어 있으며, 스스로 알아내고 싶은 사람들을 위해 지침을 공유합니다. 사이트 간 또는 도로 모드 전사에서 클라우드에 IPSec/L2TP를 설정하고, 누구든 자신의 Windows 서버에 VPN 서비스를 설정하려는 경우 항상 설정 방법에 대한 팁을 공유할 준비가 되어 있습니다. 표준 RAS 또는 OpenVPN. 그러나 우리가 아무리 멋져도 클라이언트를 대상으로 교육 작업을 수행하기에 가장 좋은 시기는 아니었습니다. 사용자의 스트레스를 최소화하면서 최대한 빨리 문제를 해결해야 했기 때문입니다.

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

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

우리는 이러한 시스템의 소스 코드를 공유할 준비가 되어 있으며 지나치게 복잡한 것은 없으며(말 그대로 몇 시간 만에 컴파일된 몇 가지 간단한 스크립트입니다), 동시에 조정하고 사용할 수 없습니다. 이러한 공격으로부터 보호할 뿐만 아니라 네트워크 검색 시도를 탐지하고 차단합니다. 이 링크를 따라가세요.

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

이 솔루션은 매우 효과적인 것으로 나타났습니다. 클라이언트와 파트너 모두, 그리고 모니터링 시스템에서 더 이상 불만이 없습니다. 새로운 주소와 전체 네트워크가 정기적으로 블랙리스트에 추가됩니다. 이는 공격이 계속되지만 더 이상 고객의 작업에 영향을 미치지 않음을 나타냅니다.

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

오늘 우리는 다른 운영자들도 비슷한 문제에 직면했다는 것을 알게 되었습니다. 누군가는 여전히 Microsoft가 원격 액세스 서비스 코드를 일부 변경했다고 믿고 있으며(기억하신다면 우리는 첫날에 같은 것을 의심했지만 매우 빠르게 이 버전을 거부했습니다) 신속하게 해결책을 찾기 위해 가능한 모든 조치를 취할 것을 약속합니다. . 어떤 사람들은 단순히 문제를 무시하고 클라이언트에게 스스로를 보호하라고 조언합니다(연결 포트 변경, 개인 네트워크에서 서버 숨기기 등). 그리고 첫날 우리는 이 문제를 해결했을 뿐만 아니라 우리가 개발할 보다 글로벌한 위협 탐지 시스템을 위한 기반을 마련했습니다.

침묵을 지키지 않고 강둑에 앉아 어느 날 적의 시체가 떠오를 때까지 기다리지 않고 문제에 즉시 관심을 기울여 제거 할 수있는 기회를 주신 고객과 파트너에게 특별히 감사드립니다. 같은 날에 말이죠.

출처 : habr.com