რას ვაკეთებთ თავდასხმების წინააღმდეგ და რას ვერ აკეთებს ვერცერთი ჰოსტი

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

რა არის თამაშის სერვერზე თავდასხმა სინამდვილეში#

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

Volumetric. მილის გავსება. თავდამსხმელს არ აინტერესებს, რას გააკეთებს შენი სერვერი პაკეტებთან; მიზანია წამში უფრო მეტი ბიტის გაგზავნა, ვიდრე არხს გადააქვს, რომ კანონიერი პაკეტები სადღაც upstream როუტერმა გადააგდოს. ციფრებით: დატვირთული თამაშის სერვერი გადაადგილებს დაახლოებით 50-150 KB/s ერთ მოთამაშეზე. ასი მოთამაშე დაახლოებით 15 MB/s-ია, ანუ 120 Mbit/s. იაფი booter გამოწერა ათობით გიგაბიტს აგზავნის. არ არსებობს გეგმა, რომლის ყიდვითაც შენი სერვერი მას "შთანთქავს", რადგან შეშუპება ხდება მანამ, სანამ შენი სერვერი საქმეში ერევა. ეს ერთადერთი კატეგორიაა, სადაც პრობლემას ჰოსტი წყვეტს.

პროტოკოლისა და მდგომარეობის ამოწურვა. SYN flood-ები, რომლებიც ნახევრად გახსნილ TCP კავშირებს ტოვებს, ფრაგმენტირებული UDP, რომელიც არასოდეს იკრიბება, კავშირების ცხრილები, გავსებული სესიებით, რომლებიც არსად მიდის. მოცულობა მცირეა; ზიანი ადგება ცხრილს, რომელსაც სტრიქონების სასრული რაოდენობა აქვს. უმეტესობას kernel-ისა და firewall-ის პარამეტრები აგვარებს, ისევე როგორც ნებისმიერი კომპეტენტური upstream ფილტრი.

აპლიკაციის დონე. ყველაზე ძვირი. ავთენტიფიკაციის გარეშე query პაკეტების flood შენი სერვერების სიის პორტზე. ათასობით login მცდელობა Minecraft სერვერზე, რომელიც online-mode=false-ზე მუშაობს. Source engine-ის connect flood. Mod ბრძანება, რომელიც chunk-ებს ტვირთავს, და ვიღაც, ვინც აღმოაჩენს, რომ ასი ანგარიშით მისი გაშვება შეუძლია. ტრაფიკი მცირეა, ვალიდურია და მოთამაშეებისგან გარჩევადი არ არის. შენი სერვერის წინ არცერთ ფილტრს არ შეუძლია მისი უსაფრთხოდ გადაგდება, რადგან მისი გადაგდება მოთამაშეების გადაგდებას ნიშნავს.

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

რას აგდებს upstream ფილტრაცია#

ფილტრაცია საჯარო ინტერნეტსა და node-ს შორის დგას და მუშაობს იმ ტრაფიკზე, რომელიც სტრუქტურულად არასწორია ან სტრუქტურულად უაზროა.

• Volumetric flood-ები პორტებზე, რომლებზეც არაფერი უსმენს. UDP flood პორტ 3479-ზე მანქანაზე, რომელიც მხოლოდ 27015-ზე პასუხობს, უფასოდ გადასაგდებია.
• Reflection და amplification, რაც booter სერვისის ნამდვილ გაგზავნილ ტრაფიკში უმეტესია. თავდამსხმელი შენს მისამართს წყაროდ აყალბებს, მესამე მხარის სერვერს მცირე მოთხოვნას უგზავნის და ის სერვერი დიდ პასუხს შენ გიგზავნის. თავდამსხმელის საკუთარი გამტარობა მრავლდება.
• დეფექტური ტრაფიკი. პაკეტები შეუძლებელი header კომბინაციებით, გაყალბებული წყაროები, რომლებიც ძირითად შემოწმებას ვერ გადიან, ფრაგმენტები, რომლებიც არასოდეს სრულდება.

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

ბოლო ორი ხაზი თამაშის ჰოსტინგისთვის საინტერესოა: შენი საკუთარი query პორტი reflector-ია. ის ყველას პასუხობს UDP-ით იმაზე მეტი ბაიტით, ვიდრე მიიღო. ეს იგივე მექანიზმია, ოღონდ სხვისკენ მიმართული. ეს არის მიზეზი, რომ query პორტი მოხერხებულობად კი არა, გამოფენილ ზედაპირად განიხილო, რასაც ქვემოთ სექცია ეხება.

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

რას ვერ აგდებს ფილტრაცია#

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

• Botnet, რომელიც handshake-ს ასრულებს. თუ მანქანები მართლა უკავშირდებიან, სადაც ავთენტიფიკაციაა, იქ გადიან და კარგად ფორმირებულ თამაშის პაკეტებს აგზავნიან, ისინი ნებისმიერი როუტერის თვალში მოთამაშეები არიან. დაცვა თამაშშია: allow list, პაროლი, ban, slot-ების ლიმიტი, შესვლების rate limit.
• Query flood დასაჯერი სიხშირით. წამში ერთი query სამი ათასი მისამართიდან არის წამში სამი ათასი query შენს სერვერზე და თითო უწყინარი მოთხოვნა თითო წყაროდან. წყაროს მიხედვით rate limiting-ი ვერაფერ უცნაურს ხედავს.
• ძვირი ბრძანებები. ყველაფერი შენს თამაშში ან mod-ებში, რასაც პასუხი უფრო მეტი CPU ჯდება, ვიდრე მოთხოვნა. სამყაროს გენერაცია, ინვენტარის დიდი ოპერაციები, plugin, რომელიც ყოველ ჩატის შეტყობინებაზე ბაზის query-ს უშვებს. ეს გამოყენებული აპლიკაციის ბაგია და არა ქსელური მოვლენა, და მეტი გამტარობა მას ვერ შეეხება.
• დარეკვა შიგნიდან. გაჟონილი RCON პაროლი, subuser, რომელსაც შენთან წაეჩხუბა, ადმინის ანგარიში ორფაქტორიანი ავთენტიფიკაციის გარეშე. წაიკითხე RCON უსაფრთხოდ და subuser-ები და მინიმალური პრივილეგია, რადგან ეს სერვერის გაფუჭების გაცილებით ხშირი მიზეზებია, ვიდრე ნებისმიერი flood.

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

შენი მისამართი არის სამიზნე და ის გაჟონავს#

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

თუ შენი სერვერი საჯარო ბრაუზერშია ჩამოთვლილი, მისი მისამართი დიზაინითვე გამოქვეყნებულია. Steam-ის master server list, Minecraft-ის server list ping და ყოველი community tracker, რომელიც მათ სკანირებს, სწორედ იმისთვის არსებობს, რომ შენი მისამართი უცხოებს გადასცეს. ეს არის ჩამოთვლის აზრი. ჩამოთვლილ სერვერს საჯარო მისამართი ისევე აქვს, როგორც მაღაზიას საჯარო კარი.

გასაკონტროლებელია ის გაჟონვები, რომლებიც განზრახ არ არის:

• DNS ჩანაწერი, რომელიც მანქანაზე მიუთითებს. play.example.com, რომელიც თამაშის სერვერის მისამართზე წყდება, ნორმალურია, მაგრამ ვებსაიტის ძველი A ჩანაწერი იმავე მანქანაზე უფასო რუკაა. DNS ჩანაწერები ახსნილი და ქვედომენები სერვერებისთვის აღწერს მათ მოწესრიგებულად შენახვას.
• Discord-ის სტატუს bot, რომელიც ნედლ მისამართს embed-ში აქვეყნებს არხში, რომელშიც ნებისმიერს შეუძლია შესვლა.
• კონსოლის სკრინშოტები. მისამართი, პორტი და ზოგჯერ RCON პაროლი, ყველაფერი წასაკითხი.
• Crash report-ები და mod-ების ლოგები, ჩასმული საჯარო support არხში. მათ უმეტესობაში ჩაწერილია bind მისამართი და სრული command line.
• Web map იმავე მანქანაზე. Dynmap ან BlueMap პორტ 8123-ზე HTTP სერვისია, რომელიც ზუსტად აცხადებს, სად ცხოვრობს თამაშის სერვერი.

Cloudflare-ის კითხვა მუდმივად ჩნდება, ამიტომ აი პირდაპირი პასუხი: ნარინჯისფერი ღრუბელი HTTP-სა და HTTPS-ს ატარებს proxy-ით. ის ჩვეულებრივ გეგმაზე Minecraft-ს, Source-ს ან სხვა UDP თამაშის ტრაფიკს არ ატარებს, ამიტომ ვებსაიტის მის უკან დაყენება ვებსაიტის მისამართს მალავს და სხვა არაფერს. თუ ვებსაიტი და თამაშის სერვერი ერთ მანქანაზეა, თამაშის პორტი მაინც ეუბნება ყველას, ვინც ჰკითხავს. Cloudflare ვებსაიტებისა და თამაშის სერვერებისთვის აღწერს, რას ფარავს და რას არ ფარავს proxy.

მისამართის შეცვლა უკანასკნელი საშუალებაა და ეს ღილაკი არ არის. გახსენი ticket და ჰკითხე, ნუ დაუშვებ, რომ ახალი ხელმისაწვდომია; დაელოდე პასუხს, რომელიც იმაზეა დამოკიდებული, რა ხდება სინამდვილეში და არა იმაზე, რამდენად გაბრაზებული ხარ.

Query პორტები: ყველაზე ხმამაღალი, რასაც აჩენ#

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

ორი პარამეტრი მართლა ეხმარება.

Source engine სერვერებზე query rate limiter წლებია არსებობს და არავის რადარზე არ არის, რადგან ნაგულისხმევი მნიშვნელობები უკვე გონივრულია:

// Per-client query rate before the server stops answering that addresssv_max_queries_sec 3.0// Window in seconds over which the rate is measuredsv_max_queries_window 30// Total queries per second the server will answer from everybodysv_max_queries_sec_global 60

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

Minecraft-ზე ორი server.properties გასაღები მნიშვნელოვანია და ისინი განსხვავებული რამეებია:

# The GameSpy-style query protocol. Off by default. Leave it off.enable-query=falsequery.port=25565# The server list ping. Turning it off hides you from the multiplayer list# but players who already know the address can still join.enable-status=true

enable-query არის დამატებითი, უფრო ძველი პროტოკოლი, რომელიც უმთავრესად მესამე მხარის სტატუს ხელსაწყოებისთვის არსებობს. თუ შენს გაშვებულ არცერთ რამეს ის არ სჭირდება, ეს წმინდა გამოფენილი ზედაპირია. enable-status=false მოძალადე ინსტრუმენტია, რომელსაც თავდასხმისას მიმართვა ღირს: სერვერი სიის ping-ებს საერთოდ აღარ პასუხობს, რის გამოც flood-ის იგნორირება იაფია, იმ ფასად, რომ ყველასთვის გათიშულად გამოიყურები.

პარამეტრები, რომლებიც შენზე თავდასხმას აძვირებს#

აქ ცხოვრობს ნამდვილი დაცვა იმ თავდასხმებისთვის, რომელთაგან ვერავინ გაგიფილტრავს.

1. Allow list. ყველაზე ეფექტური კონტროლი, რაც არსებობს. კერძო სერვერს, რომელზეც server.properties-ში white-list=true და enforce-whitelist=true წერია, ან Valheim-ზე შევსებული permittedlist.txt აქვს, botnet-ი საერთოდ ვერ შეუერთდება. თუ შენი community ერთმანეთის მცოდნე ორმოცდაათი ადამიანია, ამის წინააღმდეგ არგუმენტი არ არსებობს.
2. არასოდეს გამოიყენო offline mode. Minecraft-ზე online-mode=false ნიშნავს, რომ სერვერი არავის ამოწმებს, ამიტომ ნებისმიერს შეუძლია ნებისმიერად შემოსვლა, შენადაც. ერთადერთი კანონიერი გამოყენებაა proxy-ს უკან, რომელიც ავთენტიფიკაციას აკეთებს, forwarding-ის გამართვით. Minecraft whitelist და უფლებები შეიცავს დეტალებს.
3. შეზღუდე კავშირები. Bukkit-ზე დაფუძნებულ სერვერებს bukkit.yml-ში აქვთ settings.connection-throttle მილიწამებში, ნაგულისხმევად 4000. ეს არის მისამართზე მინიმალური შუალედი კავშირის მცდელობებს შორის და შესვლის flood-ისგან დაცვის ყველაზე იაფი საშუალებაა.
4. პაკეტების ლიმიტები. Paper-ს გლობალურ კონფიგურაციაში აქვს პაკეტების rate limiter ნაგულისხმევი ლიმიტითა და თითო პაკეტის გადაფარვებით. ფაილის გზა Paper-ის ვერსიებს შორის შეიცვალა (paper.yml, შემდეგ config/paper-global.yml), ამიტომ შეამოწმე ის, რომელსაც შენი build ნამდვილად წერს, და სამი წლის ფორუმის პოსტიდან გზას ნუ გადაიწერ.
5. გამორთე RCON, თუ არაფერი იყენებს. უმეტეს სერვერზე ის ჩართულია და უქმად დგას, ანუ პაროლით დაცული shell ღია პორტზე ყოველგვარი მიზეზის გარეშე.
6. Firewall-ით დახურე ადმინისტრირების ზედაპირი. Web map-ები, web admin პანელები, ბაზის პორტები და RCON უნდა იყოს მისაწვდომი მისამართებიდან, რომლებსაც აკონტროლებ, და არსად სხვაგან. Firewall-ის წესები, რომლებიც მნიშვნელოვანია და rate limit-ები და ბოროტად გამოყენება აღწერს გონივრული წესების ნაკრების ფორმას.
7. ჩაიწერე, ვინ შედის. როცა თავდასხმა ადამიანია და არა botnet-ი, პასუხია ban და მოდერაციის პოლიტიკა, და ორივეს ჩანაწერები სჭირდება. ლოგები, რომლებიც ღირს შენახვა თანმხლები პოსტია.

მესამე პუნქტის connection throttle ერთი ხაზია და სერვერზე, რომელსაც ოდესმე შესვლის flood ჰქონია, სწორედ ეს ხაზია, რამაც ის დაასრულა:

settings:  connection-throttle: 4000

თავდასხმისას: პირველი ათი წუთი#

1. დაადასტურე, რომ ეს თავდასხმაა. სანამ რამეს დაასკვნი, დატვირთვის გრაფიკს შეხედე. CPU-ს მკვეთრი ზრდა ნორმალური მოთამაშეთა რაოდენობით ჩვეულებრივ plugin-ია ან chunk-ი და არა flood-ი; ნორმალური CPU და ყველას timeout უფრო ქსელს ჰგავს. სერვერის დატვირთვის გრაფიკის კითხვა მოკლე ვერსიაა.
2. ნუ დაჯდები restart ღილაკზე. გადატვირთვა flood-ს არ ასუფთავებს, ხოლო სერვერი, რომელიც მუდმივად კვდება და ბრუნდება, crash loop-ისგან გარჩევადი არ არის.
3. გაჩუმდი. ჩართე allow list, ან დააყენე enable-status=false, ან დაწიე გლობალური query rate. სერვერის თავდასხმისთვის მოსაწყენად გახდომა ყველაზე მეტ თავდასხმას ასრულებს, რადგან თავდამსხმელი ჩვეულებრივ წუთობრივ იხდის.
4. მოთამაშეებს სხვაგან ელაპარაკე. Discord-ზე და არა სერვერზე. სამასი ადამიანისთვის ხელახლა დაკავშირების ცდის თხოვნა შენს მოთამაშეებს მეორე ტალღად აქცევს.
5. გახსენი ticket დროებითა და ლოგებით. "ადრე ლაგავდა" გამოსაძიებელი არ არის. დროის ნიშნული დროის ზონით, კონსოლის გამოტანა მის გარშემო და ის, რაც გრაფიკებზე ნახე, გამოსაძიებელია.
6. შემდეგ შეცვალე. ახალი RCON პაროლი, გადახედე, ვისაც აქვს subuser წვდომა, და შეამოწმე, ზემოთ ჩამოთვლილი გაჟონვებიდან რომელი გეხებოდა.

რას ვაკეთებთ, პირდაპირ ნათქვამი#

პატიოსანი სია, არაფრის დამრგვალების გარეშე:

• Upstream ფილტრაცია აშკარა volumetric flood-ებს, reflection-სა და დეფექტურ ტრაფიკს node-მდე მისვლამდე აგდებს. თავდასხმები, რომლებიც რეალურ მოთამაშეებს ჰგავს, არ ფილტრება და ჩვენ ამის საპირისპიროს არ ვიმჩნევთ.
• ყოველი სერვერი ერთი container-ია მყარი CPU ლიმიტით, რომელიც შენ ნაყიდ წილზეა დაყენებული. მეზობელს, რომელსაც თავს ესხმიან ან უბრალოდ დატვირთულია, შენი CPU ვერ წაართმევს. სერვერი, რომელიც 100%-ზე დგას, ნელია და არა გატეხილი, და ამის გამო არასოდეს ჩერდება.
• გამტარობა უზომოა იმ აზრით, რომ გიგაბაიტზე არ ითვლება. ეს არ არის ნებართვა, გაზიარებული uplink გადატვირთო, და bandwidth და სამართლიანი გამოყენება ხსნის, სად გადის ხაზი.
• მეხსიერების ლიმიტზე container ჩერდება და სუფთად გადაიტვირთება და არა swap-ში რჩება, რაც ერთი სერვერის პრობლემას node-ის პრობლემად გადაქცევას უშლის.
• დამკვირვებელი ყოველ ორ წუთში ამოწმებს, უკან ხომ არ წავიდა uptime, ან სერვერი ხომ არ გამოირთო. შენ მოთხოვნილი გადატვირთვები არ ითვლება. საათში სამი მოულოდნელი გადატვირთვა სერვერის გვერდზე გაფრთხილებას და ავტომატურ ticket-ს ქმნის; ექვსი სერვერს აჩერებს, რომ თავს ზიანი აღარ მიაყენოს.
• Backup-ები ყველა გეგმაზეა, ინახება იმ მანქანისგან განცალკევებით, რომელსაც იცავს, ხოლო პლატფორმის საკუთარი backup-ები ღამით ეშვება ცალკე აპარატურაზე და გადამოწმდება და იწმინდება განრიგით.
• არის ერთი ლოკაცია, გერმანია, და ერთი node ფლოტის snapshot-ში. Uptime-ის პროცენტს არ ვაქვეყნებთ, რადგან ხელმისაწვდომობა ნიმუშებითაა გაზომილი და არა სახელშეკრულებო, ხოლო რიცხვი, რომლის უკან ვერ ვდგავართ, ციფრის არარსებობაზე უარესია. სტატუსის გვერდი აჩვენებს, რაც არის.

თუ თავდასხმის სახეებზე უფრო ღრმა განხილვა გინდა და არა ჰოსტინგის მხარეზე, DDoS თავდასხმები თამაშის სერვერებზე ახსნილი მათ სათითაოდ შლის.

FAQ#

აქვს RE:NODE-ს DDoS დაცვა?

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

გააჩერებს თავდასხმას ჩემი სერვერის პორტის შეცვლა?

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

შემიძლია თამაშის სერვერი Cloudflare-ის უკან დავაყენო მისამართის დასამალად?

ჩვეულებრივ გეგმაზე არა. Proxy HTTP-სა და HTTPS-ს ამუშავებს და არა UDP-ს ან ნედლ TCP-ს, რომელსაც თამაშის სერვერები იყენებს. ასე შეგიძლია დამალო ვებსაიტი, web map ან სტატისტიკის გვერდი, რაც ღირს, თუ ისინი თამაშთან ერთ მანქანაზე არიან, მაგრამ თამაშის პორტი პირდაპირ მისაწვდომი რჩება.

ჩემი სერვერი ათი წუთი ცუდად ლაგავდა და მერე გამოსწორდა. ეს თავდასხმა იყო?

ჩვეულებრივ არა. ათწუთიანი ლაგი, რომელიც თავისით მთავრდება, გაცილებით უფრო ხშირად არის plugin, რომელიც რაღაც ძვირს აკეთებს, chunk-ის გენერაცია, backup-ის გაშვება ან მეხსიერების ლიმიტის მიღწევა. ჯერ ამ ფანჯრის დატვირთვის გრაფიკი და კონსოლის ლოგი შეამოწმე; თავდასხმა ჩვეულებრივ პაკეტების დაკარგვად და timeout-ებად ჩანს და არა CPU-ს სუფთა ნახტომად.

უკეთ გადაურჩება უფრო დიდი გეგმა თავდასხმებს?

Volumetric flood-ის წინააღმდეგ არა, რადგან შეშუპება ყველაფრისგან upstream-შია, რასაც ქირაობ. აპლიკაციის დონის თავდასხმის წინააღმდეგ ზოგჯერ კი, რადგან CPU-ს მეტი მარაგი ნიშნავს, რომ სერვერი დამატებით სამუშაოს უფრო დიდხანს ეწევა. უკეთესი დანახარჯია ჩვეულებრივ allow list და ნახევარი საათი ზემოთ ჩამოთვლილი პარამეტრების გამკაცრებაზე.

შეიძლება ჩემი სერვერი შეჩერდეს იმის გამო, რომ ვიღაცამ მას შეუტია?

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