DDoS შეტევა RDP სერვისებზე: ამოცნობა და ბრძოლა. წარმატებული გამოცდილება თუჩასგან

მოდი მოგიყვეთ მაგარი ამბავი იმის შესახებ, თუ როგორ ცდილობდნენ „მესამე მხარეები“ ჩვენი კლიენტების მუშაობაში ჩარევას და როგორ მოგვარდა ეს პრობლემა.

როგორ დაიწყო ეს ყველაფერი

ყველაფერი დაიწყო 31 ოქტომბრის დილას, თვის ბოლო დღეს, როცა ბევრს უიმედოდ სჭირდება დრო გადაუდებელი და მნიშვნელოვანი საკითხების მოსაგვარებლად.

ერთ-ერთმა პარტნიორმა, რომელიც ინახავს კლიენტების რამდენიმე ვირტუალურ მანქანას, რომელსაც ემსახურება ჩვენს ღრუბელში, იტყობინება, რომ 9:10-დან 9:20 საათამდე ჩვენს უკრაინულ საიტზე გაშვებული Windows-ის რამდენიმე სერვერი არ იღებდა კავშირებს დისტანციური წვდომის სერვისთან, მომხმარებლებს არ შეეძლოთ. შევიდნენ თავიანთ სამუშაო მაგიდაზე, მაგრამ რამდენიმე წუთის შემდეგ პრობლემა თავისთავად მოგვარდა.

ჩვენ შევადგინეთ სტატისტიკა საკომუნიკაციო არხების ფუნქციონირების შესახებ, მაგრამ არ აღმოვაჩინეთ ტრაფიკის აწევა ან წარუმატებლობა. ჩვენ გადავხედეთ სტატისტიკას გამოთვლითი რესურსების დატვირთვის შესახებ - არანაირი ანომალია. და რა იყო ეს?

შემდეგ კიდევ ერთმა პარტნიორმა, რომელიც მასპინძლობს კიდევ ასამდე სერვერს ჩვენს ღრუბელში, მოახსენა იგივე პრობლემები, რაც მათმა ზოგიერთმა კლიენტმა აღნიშნა, და აღმოჩნდა, რომ ზოგადად სერვერები ხელმისაწვდომი იყო (სწორად პასუხობდა პინგ ტესტს და სხვა მოთხოვნებს), მაგრამ ამ სერვერებზე დისტანციური წვდომის სერვისი ან იღებს ახალ კავშირებს ან უარყოფს მათ და ჩვენ ვსაუბრობდით სერვერებზე სხვადასხვა საიტებზე, რომელთა ტრაფიკი მოდის მონაცემთა გადაცემის სხვადასხვა არხებიდან.

მოდით შევხედოთ ამ ტრაფიკს. კავშირის მოთხოვნით პაკეტი მიდის სერვერზე:

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/L2TP დასაყენებლად საიტიდან საიტის ან გზის რეჟიმში - warrior, და თუ ვინმეს სურს VPN სერვისის დაყენება საკუთარ Windows სერვერზე, ისინი ყოველთვის მზად არიან გაგიზიარონ რჩევები, თუ როგორ დააყენოთ სტანდარტული RAS ან OpenVPN. მაგრამ, რაც არ უნდა მაგარი ვიყოთ, ეს არ იყო საუკეთესო დრო კლიენტებს შორის საგანმანათლებლო სამუშაოების ჩასატარებლად, რადგან ჩვენ გვჭირდებოდა პრობლემის მოგვარება რაც შეიძლება სწრაფად, მომხმარებლებისთვის მინიმალური სტრესით.

ჩვენ მიერ განხორციელებული გამოსავალი იყო შემდეგი. ჩვენ დავაყენეთ გადასასვლელი ტრაფიკის ანალიზი ისე, რომ დავაკვირდეთ ყველა მცდელობას TCP კავშირის დამყარების პორტთან 3389 და მისგან ავირჩიოთ მისამართები, რომლებიც 150 წამში შეეცდებიან დაამყარონ კავშირები ჩვენს ქსელში 16-ზე მეტ სხვადასხვა სერვერთან. - ეს არის თავდასხმის წყაროები ( რა თქმა უნდა, თუ ერთ-ერთ კლიენტს ან პარტნიორს აქვს რეალური საჭიროება დაამყაროს კავშირი ამდენ სერვერთან ერთი და იგივე წყაროდან, თქვენ ყოველთვის შეგიძლიათ დაამატოთ ასეთი წყაროები "თეთრ სიაში". თუ C კლასის ერთ ქსელში ამ 150 წამის განმავლობაში იდენტიფიცირებულია 32-ზე მეტი მისამართი, აზრი აქვს მთელი ქსელის დაბლოკვას. დაბლოკვა დაყენებულია 3 დღით და თუ ამ დროის განმავლობაში არ განხორციელებულა შეტევა მოცემული წყაროდან, ეს წყარო ავტომატურად წაიშლება „შავი სიიდან“. დაბლოკილი წყაროების სია ახლდება ყოველ 300 წამში.

ეს სია ხელმისაწვდომია ამ მისამართზე: https://secure.tucha.ua/global-filter/banned/rdp_ddos, თქვენ შეგიძლიათ შექმნათ თქვენი ACL მასზე დაყრდნობით.

ჩვენ მზად ვართ გავუზიაროთ ასეთი სისტემის წყაროს კოდი; მასში არაფერია ზედმეტად რთული (ეს არის რამდენიმე მარტივი სკრიპტი, რომელიც შედგენილია სიტყვასიტყვით რამდენიმე საათში მუხლზე), და ამავე დროს მისი ადაპტირება და გამოყენება შესაძლებელია. მხოლოდ ასეთი თავდასხმისგან დასაცავად, არამედ ქსელის სკანირების ნებისმიერი მცდელობის აღმოსაჩენად და დაბლოკვის მიზნით: მიჰყევით ამ ბმულს.

გარდა ამისა, ჩვენ შევიტანეთ გარკვეული ცვლილებები მონიტორინგის სისტემის პარამეტრებში, რომელიც ახლა უფრო მჭიდროდ აკვირდება ჩვენს ღრუბელში ვირტუალური სერვერების საკონტროლო ჯგუფის რეაქციას RDP კავშირის დამყარების მცდელობაზე: თუ რეაქცია არ მოჰყვება მეორე, ეს არის ყურადღების მიქცევის მიზეზი.

გამოსავალი საკმაოდ ეფექტური აღმოჩნდა: აღარ არის პრეტენზია როგორც კლიენტების, ისე პარტნიორების მხრიდან და მონიტორინგის სისტემის მხრიდან. ახალი მისამართები და მთელი ქსელები რეგულარულად ემატება შავ სიას, რაც მიუთითებს იმაზე, რომ შეტევა გრძელდება, მაგრამ აღარ იმოქმედებს ჩვენი კლიენტების მუშაობაზე.

არის უსაფრთხოება ციფრებში

დღეს გავიგეთ, რომ მსგავსი პრობლემა სხვა ოპერატორებს შეექმნათ. ვიღაცას ჯერ კიდევ სჯერა, რომ მაიკროსოფტმა გარკვეული ცვლილებები შეიტანა დისტანციური წვდომის სერვისის კოდში (თუ გახსოვთ, ჩვენ იგივე ეჭვი გვქონდა პირველ დღეს, მაგრამ ძალიან სწრაფად უარვყავით ეს ვერსია) და გვპირდება, რომ ყველაფერს გააკეთებს, რომ გამოსავალი სწრაფად მოძებნოს. . ზოგიერთი ადამიანი უბრალოდ იგნორირებას უკეთებს პრობლემას და ურჩევს კლიენტებს დამოუკიდებლად დაიცვან თავი (შეცვალეთ კავშირის პორტი, დამალეთ სერვერი კერძო ქსელში და ა.შ.). და პირველივე დღეს, ჩვენ არა მხოლოდ მოვაგვარეთ ეს პრობლემა, არამედ შევქმენით საფუძველი უფრო გლობალური საფრთხის აღმოჩენის სისტემისთვის, რომლის განვითარებასაც ვგეგმავთ.

განსაკუთრებული მადლობა კლიენტებს და პარტნიორებს, რომლებიც არ დუმდნენ და არ ისხდნენ მდინარის ნაპირზე და ელოდნენ მტრის გვამს, რომელიც ერთ დღეს გაცურავდა მის გასწვრივ, მაგრამ მაშინვე მიიპყრო ჩვენი ყურადღება პრობლემაზე, რამაც საშუალება მოგვცა აღმოფხვრა. ის იმავე დღეს.

წყარო: www.habr.com