DDoS სამაშველოში: როგორ ვატარებთ სტრესისა და დატვირთვის ტესტებს

Variti ავითარებს დაცვას ბოტებისა და DDoS შეტევებისგან, ასევე ატარებს სტრესისა და დატვირთვის ტესტირებას. HighLoad++ 2018 კონფერენციაზე ვისაუბრეთ იმაზე, თუ როგორ დავიცვათ რესურსები სხვადასხვა ტიპის შეტევებისგან. მოკლედ: სისტემის ნაწილების იზოლირება, ღრუბლოვანი სერვისების და CDN-ების გამოყენება და რეგულარულად განახლება. მაგრამ თქვენ მაინც ვერ შეძლებთ დაცვას სპეციალიზებული კომპანიების გარეშე :)

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

მოხსენების ვიდეო ჩანაწერი

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

როგორ ვმუშაობთ

ტესტირებისას ჩვენ ვაბაძავთ ბოტნეტს. ვინაიდან ჩვენ ვმუშაობთ კლიენტებთან, რომლებიც არ არიან განლაგებული ჩვენს ქსელებში, იმისთვის, რომ ტესტი არ დასრულდეს პირველ წუთში ლიმიტების ან დაცვის გამოწვევის გამო, ჩვენ ვაწვდით დატვირთვას არა ერთი IP-დან, არამედ ჩვენი ქვექსელიდან. გარდა ამისა, მნიშვნელოვანი დატვირთვის შესაქმნელად, ჩვენ გვაქვს ჩვენი საკმაოდ ძლიერი სატესტო სერვერი.

პოსტულატები

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

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

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

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

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

L7 შეტევების გამორჩეული მახასიათებლები

ჩვენ ჩვეულებრივ ვყოფთ დატვირთვის ტიპებს დატვირთვებად L7 და L3&4 დონეზე. L7 არის დატვირთვა აპლიკაციის დონეზე, ყველაზე ხშირად ეს ნიშნავს მხოლოდ HTTP, მაგრამ ჩვენ ვგულისხმობთ ნებისმიერ დატვირთვას TCP პროტოკოლის დონეზე.
L7 შეტევებს აქვს გარკვეული გამორჩეული თვისებები. პირველ რიგში, ისინი პირდაპირ მიდიან აპლიკაციაში, ანუ ნაკლებად სავარაუდოა, რომ ისინი აისახება ქსელის საშუალებით. ასეთი შეტევები იყენებენ ლოგიკას და ამის გამო ისინი მოიხმარენ პროცესორს, მეხსიერებას, დისკს, მონაცემთა ბაზას და სხვა რესურსებს ძალიან ეფექტურად და მცირე ტრაფიკით.

HTTP წყალდიდობა

ნებისმიერი თავდასხმის შემთხვევაში დატვირთვის შექმნა უფრო ადვილია, ვიდრე გატარება და L7-ის შემთხვევაშიც ეს ასეა. ყოველთვის ადვილი არ არის თავდასხმის ტრაფიკის გარჩევა ლეგიტიმური ტრაფიკისგან და ყველაზე ხშირად ეს შეიძლება გაკეთდეს სიხშირით, მაგრამ თუ ყველაფერი სწორად არის დაგეგმილი, მაშინ შეუძლებელია ჟურნალებიდან იმის გაგება, თუ სად არის თავდასხმა და სად არის ლეგიტიმური მოთხოვნები.
როგორც პირველი მაგალითი, განიხილეთ HTTP Flood შეტევა. დიაგრამა გვიჩვენებს, რომ ასეთი შეტევები, როგორც წესი, ძალიან ძლიერია; ქვემოთ მოცემულ მაგალითში, მოთხოვნის პიკური რაოდენობა წუთში 600 ათასს აღემატებოდა.

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

რა უნდა მოძებნოთ

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

სად უნდა გამოიყურებოდეს

როდესაც ჩვენ სკანირებთ რესურსს ტესტირებამდე, პირველ რიგში, რა თქმა უნდა, ვუყურებთ თავად საიტს. ჩვენ ვეძებთ ყველა სახის შეყვანის ველს, მძიმე ფაილებს - ზოგადად, ყველაფერს, რასაც შეუძლია პრობლემები შეუქმნას რესურსს და შეანელოს მისი მოქმედება. ბანალური განვითარების ინსტრუმენტები Google Chrome-სა და Firefox-ში გვეხმარება აქ, სადაც ნაჩვენებია გვერდის რეაგირების დრო.
ჩვენ ასევე ვამოწმებთ ქვედომენებს. მაგალითად, არის გარკვეული ონლაინ მაღაზია abc.com და მას აქვს ქვედომენი admin.abc.com. სავარაუდოდ, ეს არის ავტორიზაციის მქონე ადმინისტრაციული პანელი, მაგრამ თუ მასზე დატვირთვას აყენებთ, ამან შეიძლება პრობლემები შეუქმნას მთავარ რესურსს.
საიტს შეიძლება ჰქონდეს ქვედომენი api.abc.com. სავარაუდოდ, ეს არის რესურსი მობილური აპლიკაციებისთვის. აპლიკაციის ნახვა შეგიძლიათ App Store-ში ან Google Play-ში, დააინსტალირეთ სპეციალური წვდომის წერტილი, ამოკვეთეთ API და დაარეგისტრირეთ სატესტო ანგარიშები. პრობლემა ის არის, რომ ადამიანები ხშირად ფიქრობენ, რომ ყველაფერი, რაც დაცულია ავტორიზაციით, იმუნურია სერვისზე უარის თქმაზე. სავარაუდოდ, ავტორიზაცია არის საუკეთესო CAPTCHA, მაგრამ ეს ასე არ არის. ადვილია 10-20 სატესტო ანგარიშის შექმნა, მაგრამ მათი შექმნით ჩვენ მივიღებთ წვდომას რთულ და დაუფარავ ფუნქციონირებაზე.
ბუნებრივია, ჩვენ ვუყურებთ ისტორიას, robots.txt და WebArchive, ViewDNS და ვეძებთ რესურსის ძველ ვერსიებს. ზოგჯერ ხდება, რომ დეველოპერებმა გამოუშვეს, ვთქვათ, mail2.yandex.net, მაგრამ ძველი ვერსია, mail.yandex.net, რჩება. ეს mail.yandex.net აღარ არის მხარდაჭერილი, მასზე არ არის გამოყოფილი განვითარების რესურსები, მაგრამ ის აგრძელებს მონაცემთა ბაზის მოხმარებას. შესაბამისად, ძველი ვერსიის გამოყენებით, შეგიძლიათ ეფექტურად გამოიყენოთ backend-ის რესურსები და ყველაფერი, რაც დგას განლაგების უკან. რა თქმა უნდა, ეს ყოველთვის არ ხდება, მაგრამ ამას მაინც ხშირად ვაწყდებით.
ბუნებრივია, ჩვენ ვაანალიზებთ მოთხოვნის ყველა პარამეტრს და ქუქიების სტრუქტურას. თქვენ შეგიძლიათ, ვთქვათ, გადააგდოთ გარკვეული მნიშვნელობა JSON მასივში ქუქი-ფაილის შიგნით, შექმნათ უამრავი ბუდე და რესურსი უსაფუძვლოდ დიდი ხნის განმავლობაში იმუშაოთ.

ძებნის დატვირთვა

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

თუ ძებნა არ არის?

თუ ძებნა არ არის, ეს არ ნიშნავს, რომ საიტი არ შეიცავს სხვა დაუცველ შეყვანის ველებს. ეს ველი შეიძლება იყოს ავტორიზაცია. დღესდღეობით, დეველოპერებს მოსწონთ რთული ჰეშების გაკეთება, რათა დაიცვან შესვლის მონაცემთა ბაზა ცისარტყელას ცხრილის შეტევისგან. ეს კარგია, მაგრამ ასეთი ჰეშები მოიხმარს უამრავ CPU რესურსს. ყალბი ავტორიზაციის დიდი ნაკადი იწვევს პროცესორის უკმარისობას და შედეგად, საიტი წყვეტს მუშაობას.
საიტზე კომენტარებისა და გამოხმაურების ყველა სახის ფორმის არსებობა არის ძალიან დიდი ტექსტების იქ გაგზავნის ან უბრალოდ მასიური წყალდიდობის შექმნის მიზეზი. ზოგჯერ საიტები იღებენ თანდართულ ფაილებს, მათ შორის gzip ფორმატში. ამ შემთხვევაში ვიღებთ 1 ტბაიტიან ფაილს, შეკუმშავთ რამდენიმე ბაიტზე ან კილობაიტზე gzip-ის გამოყენებით და ვაგზავნით საიტზე. შემდეგ იხსნება და ძალიან საინტერესო ეფექტი მიიღება.

დაისვენეთ API

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

მძიმე შინაარსის ჩატვირთვა

თუ შემოგვთავაზებენ ტესტირებას ჩვეულებრივი ერთგვერდიანი აპლიკაციის, სადესანტო გვერდის ან სავიზიტო ბარათის ვებსაიტზე, რომელსაც არ გააჩნია რთული ფუნქციონირება, ჩვენ ვეძებთ მძიმე კონტენტს. მაგალითად, დიდი სურათები, რომლებსაც სერვერი აგზავნის, ორობითი ფაილები, pdf დოკუმენტაცია - ვცდილობთ ჩამოტვირთოთ ეს ყველაფერი. ასეთი ტესტები კარგად იტვირთება ფაილური სისტემა და ბლოკავს არხებს და, შესაბამისად, ეფექტურია. ანუ, მაშინაც კი, თუ სერვერს არ დააყენებთ, დიდი ფაილის გადმოწერას დაბალი სიჩქარით, თქვენ უბრალოდ ჩაკეტავთ სამიზნე სერვერის არხს და შემდეგ მოხდება სერვისზე უარის თქმა.
ასეთი ტესტის მაგალითი გვიჩვენებს, რომ 30 RPS სიჩქარით საიტმა შეწყვიტა რეაგირება ან წარმოქმნა სერვერის 500-ე შეცდომა.

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

აქ დატვირთვა წავიდა root და შეადგინა მხოლოდ 10 RPS. 5 წუთი ველოდებოდით და სერვერი გაფუჭდა. მართალია, ბოლომდე ცნობილი არ არის, რატომ დაეცა, მაგრამ არის ვარაუდი, რომ მას უბრალოდ ზედმეტი მეხსიერება ჰქონდა და ამიტომ შეწყვიტა პასუხი.

ტალღაზე დაფუძნებული

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

ანუ, დაცვამ ისწავლა, დაიწყო ფილტრაცია, მაგრამ შეტევის ახალი, სრულიად განსხვავებული ნაწილი მოვიდა და დაცვამ ისევ დაიწყო სწავლა. სინამდვილეში, ფილტრაცია წყვეტს მუშაობას, დაცვა ხდება არაეფექტური და საიტი მიუწვდომელია.
ტალღის შეტევები ხასიათდება ძალიან მაღალი მნიშვნელობებით პიკზე, მას შეუძლია მიაღწიოს ასი ათას ან მილიონ მოთხოვნას წამში, L7-ის შემთხვევაში. თუ ვსაუბრობთ L3&4-ზე, მაშინ შეიძლება იყოს ასობით გიგაბიტი ტრაფიკი, ან, შესაბამისად, ასობით mpps, თუ ითვლით პაკეტებში.
ასეთი შეტევების პრობლემა სინქრონიზაციაა. შეტევები მოდის ბოტნეტიდან და მოითხოვს სინქრონიზაციის მაღალ ხარისხს, რათა შეიქმნას ძალიან დიდი ერთჯერადი სპიკი. და ეს კოორდინაცია ყოველთვის არ მუშაობს: ზოგჯერ გამომავალი არის რაღაც პარაბოლური მწვერვალი, რომელიც საკმაოდ პათეტიკურად გამოიყურება.

მარტო HTTP არა

L7-ზე HTTP-ის გარდა, ჩვენ გვსურს სხვა პროტოკოლების გამოყენება. როგორც წესი, ჩვეულებრივ ვებსაიტს, განსაკუთრებით რეგულარულ ჰოსტინგს, აქვს ფოსტის პროტოკოლები და MySQL. ფოსტის პროტოკოლები ექვემდებარება ნაკლებ დატვირთვას, ვიდრე მონაცემთა ბაზები, მაგრამ ისინი ასევე შეიძლება ჩაიტვირთოს საკმაოდ ეფექტურად და დასრულდეს სერვერზე გადატვირთული CPU.
ჩვენ საკმაოდ წარმატებულები ვიყავით 2016 წლის SSH დაუცველობის გამოყენებით. ახლა ეს დაუცველობა დაფიქსირდა თითქმის ყველასთვის, მაგრამ ეს არ ნიშნავს იმას, რომ დატვირთვა ვერ გადაეცემა SSH-ს. შეუძლია. უბრალოდ ავტორიზაციების უზარმაზარი დატვირთვაა, SSH ჭამს სერვერის თითქმის მთელ პროცესორს, შემდეგ კი ვებსაიტი იშლება ერთი ან ორი მოთხოვნისგან წამში. შესაბამისად, ჟურნალებზე დაფუძნებული ეს ერთი ან ორი მოთხოვნა არ შეიძლება გამოირჩეოდეს ლეგიტიმური დატვირთვისგან.
ბევრი კავშირი, რომელსაც ჩვენ ვხსნით სერვერებზე, ასევე რჩება აქტუალური. ადრე Apache იყო ამაში დამნაშავე, ახლა nginx არის ამაში რეალურად დამნაშავე, რადგან ის ხშირად კონფიგურირებულია ნაგულისხმევად. კავშირების რაოდენობა, რომელიც nginx-ს შეუძლია ღიად შეინახოს, შეზღუდულია, ამიტომ ჩვენ ვხსნით კავშირების ამ რაოდენობას, nginx აღარ იღებს ახალ კავშირს და შედეგად საიტი არ მუშაობს.
ჩვენს სატესტო კლასტერს აქვს საკმარისი CPU SSL ხელის ჩამორთმევისთვის. პრინციპში, როგორც პრაქტიკა გვიჩვენებს, ბოტნეტებსაც ზოგჯერ მოსწონთ ამის გაკეთება. ერთის მხრივ, ნათელია, რომ თქვენ არ შეგიძლიათ SSL-ის გარეშე, რადგან Google-ის შედეგები, რეიტინგი, უსაფრთხოება. მეორეს მხრივ, SSL-ს სამწუხაროდ აქვს CPU პრობლემა.

L3&4

როდესაც ვსაუბრობთ შეტევაზე L3&4 დონეზე, ჩვენ ჩვეულებრივ ვსაუბრობთ შეტევაზე ბმულის დონეზე. ასეთი დატვირთვა თითქმის ყოველთვის განსხვავდება ლეგიტიმურიდან, თუ ეს არ არის SYN-flood შეტევა. უსაფრთხოების ხელსაწყოებისთვის SYN-flood შეტევების პრობლემა მათი დიდი მოცულობაა. მაქსიმალური L3&4 მნიშვნელობა იყო 1,5-2 ტბიტ/წმ. ასეთი ტრაფიკის დამუშავება ძალიან რთულია მსხვილი კომპანიებისთვისაც კი, მათ შორის Oracle-ისა და Google-ისთვის.
SYN და SYN-ACK არის პაკეტები, რომლებიც გამოიყენება კავშირის დამყარებისას. აქედან გამომდინარე, SYN-flood ძნელია განასხვავოთ ლეგიტიმური დატვირთვისგან: არ არის ნათელი, არის თუ არა ეს SYN, რომელიც მოვიდა კავშირის დასამყარებლად, თუ წყალდიდობის ნაწილი.

UDP- წყალდიდობა

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

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

რთული SYN- წყალდიდობა

SYN-flood ალბათ ყველაზე საინტერესო ტიპის თავდასხმაა დეველოპერის თვალსაზრისით. პრობლემა ის არის, რომ სისტემის ადმინისტრატორები ხშირად იყენებენ IP დაბლოკვას დაცვის მიზნით. უფრო მეტიც, IP დაბლოკვა გავლენას ახდენს არა მხოლოდ სისტემის ადმინისტრატორებზე, რომლებიც მოქმედებენ სკრიპტების გამოყენებით, არამედ, სამწუხაროდ, უსაფრთხოების ზოგიერთ სისტემაზე, რომლებიც შეძენილია დიდი ფულით.
ეს მეთოდი შეიძლება კატასტროფად იქცეს, რადგან თუ თავდამსხმელები ჩაანაცვლებენ IP მისამართებს, კომპანია დაბლოკავს საკუთარ ქვექსელს. როდესაც Firewall დაბლოკავს საკუთარ კლასტერს, გამომავალი ჩაიშლება გარე ურთიერთქმედებებით და რესურსი მარცხდება.
უფრო მეტიც, არ არის რთული საკუთარი ქსელის დაბლოკვა. თუ კლიენტის ოფისს აქვს Wi-Fi ქსელი, ან თუ რესურსების შესრულება იზომება სხვადასხვა მონიტორინგის სისტემების გამოყენებით, მაშინ ჩვენ ვიღებთ ამ მონიტორინგის სისტემის IP მისამართს ან კლიენტის ოფისის Wi-Fi-ს და ვიყენებთ მას, როგორც წყაროს. დასასრულს, როგორც ჩანს, რესურსი ხელმისაწვდომია, მაგრამ სამიზნე IP მისამართები დაბლოკილია. ამრიგად, HighLoad-ის კონფერენციის Wi-Fi ქსელი, სადაც კომპანიის ახალი პროდუქტის პრეზენტაცია მიმდინარეობს, შესაძლოა დაიბლოკოს, რაც გარკვეულ ბიზნეს და ეკონომიკურ ხარჯებს იწვევს.
ტესტირების დროს ჩვენ არ შეგვიძლია გამოვიყენოთ გაძლიერება memcached-ის საშუალებით რაიმე გარე რესურსებით, რადგან არსებობს შეთანხმებები ტრაფიკის გაგზავნაზე მხოლოდ დაშვებულ IP მისამართებზე. შესაბამისად, ვიყენებთ SYN-ისა და SYN-ACK-ის საშუალებით გაძლიერებას, როდესაც სისტემა პასუხობს ერთი SYN-ის გაგზავნას ორი ან სამი SYN-ACK-ით, ხოლო გამოსავალზე შეტევა მრავლდება ორჯერ ან სამჯერ.

ინსტრუმენტები

ერთ-ერთი მთავარი ინსტრუმენტი, რომელსაც ვიყენებთ L7 დატვირთვისთვის, არის Yandex-tank. კერძოდ, ფანტომი გამოიყენება როგორც იარაღი, ასევე არსებობს რამდენიმე სკრიპტი ვაზნების გენერირებისთვის და შედეგების გასაანალიზებლად.
Tcpdump გამოიყენება ქსელის ტრაფიკის გასაანალიზებლად, ხოლო Nmap გამოიყენება სერვერის გასაანალიზებლად. L3&4 დონეზე დატვირთვის შესაქმნელად გამოიყენება OpenSSL და ცოტა ჩვენი ჯადოქრობა DPDK ბიბლიოთეკით. DPDK არის Intel-ის ბიბლიოთეკა, რომელიც საშუალებას გაძლევთ იმუშაოთ ქსელის ინტერფეისით Linux სტეკის გვერდის ავლით, რითაც გაზარდოთ ეფექტურობა. ბუნებრივია, ჩვენ ვიყენებთ DPDK-ს არა მხოლოდ L3&4 დონეზე, არამედ L7 დონეზე, რადგან ის საშუალებას გვაძლევს შევქმნათ ძალიან მაღალი დატვირთვის ნაკადი, წამში რამდენიმე მილიონი მოთხოვნის ფარგლებში ერთი მანქანიდან.
ჩვენ ასევე ვიყენებთ მოძრაობის გარკვეულ გენერატორებს და სპეციალურ ინსტრუმენტებს, რომლებსაც ვწერთ კონკრეტული ტესტებისთვის. თუ გავიხსენებთ დაუცველობას SSH-ში, მაშინ ზემოაღნიშნული ნაკრების ექსპლუატაცია შეუძლებელია. თუ ჩვენ თავს დაესხმებით ფოსტის პროტოკოლს, ჩვენ ვიღებთ ფოსტის უტილიტებს ან უბრალოდ ვწერთ მათზე სკრიპტებს.

დასკვნები

დასკვნის სახით მინდა ვთქვა:

• გარდა კლასიკური დატვირთვის ტესტირებისა, აუცილებელია სტრეს ტესტირების ჩატარება. ჩვენ გვაქვს რეალური მაგალითი, როდესაც პარტნიორის ქვეკონტრაქტორი მხოლოდ დატვირთვის ტესტირებას ახორციელებდა. მან აჩვენა, რომ რესურსს შეუძლია გაუძლოს ნორმალურ დატვირთვას. მაგრამ შემდეგ გამოჩნდა არანორმალური დატვირთვა, საიტის ვიზიტორებმა დაიწყეს რესურსის გამოყენება ცოტა განსხვავებულად და შედეგად ქვეკონტრაქტორი დაწვა. ამრიგად, ღირს მოწყვლადობის მოძიება მაშინაც კი, თუ უკვე დაცული ხართ DDoS შეტევებისგან.
• აუცილებელია სისტემის ზოგიერთი ნაწილის იზოლირება სხვებისგან. თუ თქვენ გაქვთ ძებნა, თქვენ უნდა გადაიტანოთ იგი ცალკეულ მანქანებში, ანუ არც Docker-ში. რადგან თუ ძებნა ან ავტორიზაცია ვერ მოხერხდა, რაღაც მაინც გააგრძელებს მუშაობას. ონლაინ მაღაზიის შემთხვევაში, მომხმარებლები გააგრძელებენ პროდუქციის პოვნას კატალოგში, გადადიან აგრეგატორიდან, ყიდულობენ თუ ისინი უკვე ავტორიზებული არიან, ან ავტორიზაციას ახდენენ OAuth2-ის მეშვეობით.
• ნუ უგულებელყოფთ ყველა სახის ღრუბლოვან სერვისს.
• გამოიყენეთ CDN არა მხოლოდ ქსელის შეფერხებების ოპტიმიზაციისთვის, არამედ როგორც დაცვის საშუალება არხის ამოწურვაზე თავდასხმებისგან და უბრალოდ სტატიკურ ტრაფიკში დატბორვისგან.
• აუცილებელია სპეციალიზებული დაცვის სერვისების გამოყენება. თქვენ არ შეგიძლიათ დაიცვათ თავი L3&4 შეტევებისგან არხის დონეზე, რადგან დიდი ალბათობით უბრალოდ არ გაქვთ საკმარისი არხი. თქვენ ასევე ნაკლებად სავარაუდოა, რომ შეებრძოლოთ L7 შეტევებს, რადგან ისინი შეიძლება იყოს ძალიან დიდი. გარდა ამისა, მცირე შეტევების ძიება კვლავ სპეცსამსახურების, სპეციალური ალგორითმების პრეროგატივაა.
• რეგულარულად განაახლეთ. ეს ეხება არა მხოლოდ ბირთვს, არამედ SSH დემონს, განსაკუთრებით თუ ისინი ღიაა გარედან. პრინციპში, ყველაფერი უნდა განახლდეს, რადგან ნაკლებად სავარაუდოა, რომ შეძლებთ დამოუკიდებლად თვალყური ადევნოთ გარკვეულ დაუცველობას.

წყარო: www.habr.com