როგორ დავიცვათ VPS DDoS შეტევებისგან

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

შეტევების ტიპები

• მოცულობითი (ფენა 3 და 4): პაკეტების ნაკადი, რომელიც ქსელურ არხს ავსებს, მაგალითად UDP flood.
• პროტოკოლური შეტევები: კავშირების დამუშავების ბოროტად გამოყენება, მაგალითად SYN flood, რომელიც კავშირების ცხრილს ავსებს.
• აპლიკაციის ფენა (ფენა 7): ბევრი, ლეგიტიმურად გამოიყურება HTTP მოთხოვნა, რომელიც ამოწურავს ვებსერვერს ან მონაცემთა ბაზას.

თითოეული ტიპი სხვადასხვა დაცვას საჭიროებს. მოცულობითი ტრაფიკი სერვერამდე მისვლამდე უნდა შეჩერდეს; აპლიკაციის ნაკადები კი სერვერზე შეიძლება შემცირდეს.

1. ფილტრაცია ქსელის კიდეზე

კიდეზე ფილტრაცია ცუდ ტრაფიკს VPS-ამდე მისვლამდე აშორებს, ასე რომ არხი არ იტვირთება. DDoS Shield-ით ფილტრაცია ქსელის კიდეზე XDP/eBPF-ის გამოყენებით მიმდინარეობს, ხოლო კონსოლი ყოველი IP-ისთვის აჩვენებს ტრაფიკსა და შეტევების ივენთებს. ნებისმიერ პროვაიდერს, რომელსაც განიხილავთ, ჰკითხეთ, რა შედის მომსახურებაში, სად ხდება ფილტრაცია და ამისთვის ცალკე ხარჯი ხომ არ არის.

2. დახურეთ ის, რასაც არ იყენებთ

sudo ufw default deny incoming
sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable

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

3. კერნელის დაყენება SYN flood-ისთვის

SYN cookies უმეტეს დისტრიბუციაში ჩართულია ნაგულისხმევად. შეამოწმეთ:

sysctl net.ipv4.tcp_syncookies

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

4. მოთხოვნების სიჩქარის შეზღუდვა Nginx-ში

http ბლოკში:

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=connperip:10m;

server ან location ბლოკში:

limit_req zone=perip burst=20 nodelay;
limit_conn connperip 20;

გადატვირთეთ sudo nginx -t && sudo systemctl reload nginx ბრძანებით. სტატიკური ფაილები კეშიდან მიაწოდეთ და WordPress-ზე გამოიყენეთ ქეშირების პლაგინი, რათა თითოეული მოთხოვნის ღირებულება შეამციროთ. იხილეთ WordPress-ის დაყენება Nginx-ით.

5. ტრაფიკის მონიტორინგი

ss -s
sudo ss -ntu state established | wc -l
sudo apt install -y nload && nload

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

6. ინციდენტის საკონტროლო სია

1. კონსოლში დაადასტურეთ, შეტევაა თუ ტრაფიკის რეალური ზრდა.
2. შეამოწმეთ შეტევის ივენთები და დაზარალებული IP.
3. დაბლოკეთ შეურაცხმყოფელი წყაროს მისამართები ან დიაპაზონები, რომელთა იდენტიფიცირებაც შეგიძლიათ.
4. ჩართეთ მკაცრი სიჩქარის ლიმიტები ან ტექნიკური მომსახურების გვერდი.
5. დაუკავშირდით პროვაიდერის მხარდაჭერას დროისა და IP-ის მითითებით.
6. შემდეგ გადახედეთ ლოგებს და განაახლეთ ეს გეგმა. დროულად განაახლეთ სარეზერვო ასლები და snapshot-ები.