DDoS შეტევები გეიმ სერვერებზე, გულახდილად

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

როგორ გამოიყურება შეტევა შიგნიდან#

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

volumetric შეტევისას:

• მოთამაშეები ერთდროულად იღებენ time out-ს, ან საერთოდ ვერ უერთდებიან.
• კონსოლი მშვიდია. შეცდომები არ არის, stack trace-ები არ არის, ლოგში არაფერია უჩვეულო.
• მეხსიერება და CPU გრაფიკებზე ნორმალურია ან დაბალი, რადგან სერვერი ჩვეულებრივზე ნაკლებ სამუშაოს აკეთებს და არა მეტს.
• თუ მანქანას სხვა გზით მისწვდები, სერვერის პროცესი მუშაობს და ჯანმრთელია.

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

შეადარე კრაშს: კონსოლს აქვს ბოლო, რაც თქვა სანამ მოკვდებოდა, მეხსიერების გრაფიკზე ჩვეულებრივ ზრდა ჩანს და გადატვირთვა ჩაწერილია. და შეადარე application-layer შეტევას, რომელიც ჩახშობის საპირისპიროდ გამოიყურება: CPU მიჭედებულია, tick rate იატაკზეა, ლოგი კავშირის მცდელობებით სავსეა და სერვერი თვალსაჩინოდ ბევრ სამუშაოს აკეთებს.

სამი დონე და რომელს ხედავ#

შეტევები დაჯგუფებულია იმის მიხედვით, სტეკის რომელ ნაწილს ამოწურავს. დაჯგუფება აკადემიური არ არის: თითოეული დონე სხვადასხვა ადგილას, სხვადასხვა მხარის მიერ ჩერდება.

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

Protocol შეტევები ბიტებით პატარაა და პაკეტებით დიდი. SYN ფლუდი ნახევრად კავშირებს ხსნის, რომლებიც მდგომარეობის თვალყურის დევნებას ხარჯავს ყველაფერზე, რაც გზაზე stateful-ია. fragment ფლუდი გზავნის IP fragment-ებს, რომლებიც არასოდეს სრულდება, ამიტომ reassembly ბუფერები ივსება. ისინი იაფია გასაგზავნად და ჩერდება stateless ფილტრაციითა და გონივრული kernel-ის ნაგულისხმევებით, მათ შორის net.ipv4.tcp_syncookies-ით.

Application შეტევები აგზავნის სრულიად მართებული ტრაფიკის მცირე რაოდენობას, რომლის დამუშავებაც შენ ბევრი გიჯდება. server browser-ის query თავდამსხმელს ერთი პატარა პაკეტი უჯდება და შენ - პასუხი, რომელიც სერვერის ცოცხალი მდგომარეობიდან იგება. join მცდელობა მათ არაფერი უჯდება და შენ - ავტენტიფიკაციის round trip-ს, world-ში შესვლას და შესაძლოა შენახვას. ესაა დონე, რომელშიც ფილტრაცია ვერ გეხმარება, და ქვემოთ მას საკუთარი განყოფილება აქვს.

Reflection და amplification, იაფი ნაწილი#

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

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

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

ბოლო სტრიქონი ისაა, რაც გეიმ ჰოსტინგს პირდაპირ ეხება. Source engine query port-ები წლების განმავლობაში reflector-ებად გამოიყენებოდა, სწორედ ამიტომ დაამატა Valve-მა A2S_INFO-ს challenge: სერვერი უცნობ წყაროს პატარა challenge რიცხვით პასუხობს და სათანადოდ მხოლოდ მაშინ პასუხობს, როცა ეს რიცხვი უკან დაბრუნდება. ეს იგივე ლოგიკაა, რაც TCP handshake-ს აქვს, query პროტოკოლზე დაგვიანებით მიკერებული, და მან ინტერნეტიდან ერთი პოპულარული reflector ამოიღო.

ამ ყველაფრის რეალური გამოსწორება ingress ფილტრაციაა იმ ქსელებში, რომლებიც გაყალბებულ პაკეტებს გარეთ უშვებენ, რაც 2000 წლიდან გამოქვეყნებული საუკეთესო პრაქტიკაა და მაინც ყველგან არ არის დანერგილი. სანამ არ დაინერგება, reflection იაფი რჩება.

რატომ არის გეიმ სერვერები მარტივი სამიზნე#

ოთხი თვისება გეიმ სერვერს უჩვეულოდ მიმზიდველს ხდის და არცერთი მათგანი შენი მნიშვნელობის შესახებ არ არის.

შენი მისამართი განზრახ საჯაროა. მოთამაშეებმა უნდა მიაღწიონ მას. ის server browser-შია, სიების საიტზეა, Discord არხშია, სქრინშოტშია. საჯარო სერვერის გაშვების ისეთი ვერსია არ არსებობს, სადაც მისამართი საიდუმლოა.

თამაშის ტრაფიკის უმეტესობა UDP-ა. handshake არ არის, ამიტომ გაყალბება ტრივიალურია და stateless ფლუდები იაფია. ეს ასევე ნიშნავს, რომ ფილტრს თამაშის პროტოკოლის ცოდნის გარეშე კავშირის მდგომარეობის გამოყენებით ნამდვილი კლიენტისა და გაყალბებული პაკეტის გარჩევა არ შეუძლია. TCP თუ UDP გეიმ სერვერებისთვის არის ფონი იმაზე, რატომ აირჩიეს თამაშებმა UDP და რა ჯდება ეს.

სერვისი ლატენტურობის მიმართ მგრძნობიარეა. ვებსაიტი, რომელსაც დამატებით 400 ms სჭირდება, უფრო ნელია. გეიმ სერვერი, რომელსაც დამატებით 400 ms სჭირდება, სათამაშოდ გამოუსადეგარია. თავდამსხმელს არ სჭირდება, რომ გათიშოს; მას მხოლოდ უნდა, რომ თამაში აღარ ღირდეს, რისთვისაც ტრაფიკის ნაწილი საკმარისია.

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

რას შეუძლია ფილტრაციას და რას ვერა#

აი გულახდილი ანგარიში, და ის იგივეა, რაც უსაფრთხოების გვერდზეა.

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

რაც მას არ შეუძლია, არის რეალური მოთამაშისგან იმ ტრაფიკის გარჩევა, რომელიც ზუსტად მოთამაშეს ჰგავს. ქსელის დონეზე განსხვავება არ არის რეალურ კლიენტს, რომელიც join პაკეტს აგზავნის, და თავდამსხმელს შორის, რომელიც იმავე პაკეტს აგზავნის. მათ გასარჩევად თამაშის საკუთარი მდგომარეობა გჭირდება - ვინ გაიარა ავტენტიფიკაცია, ვინ არის rate-limited, რომელი იდენტობა შემოვიდა ცხრაჯერ წუთში - და ეს მდგომარეობა გეიმ სერვერში ცხოვრობს და არა upstream ფილტრში.

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

• ფილტრაციას ზღურბლი აქვს. რაღაცამ უნდა გააქტიუროს, სანამ mitigation ჩაირთვება, და წამები, სანამ ეს მოხდება, რეალურია. მოკლე, მკვეთრი აფეთქება შეიძლება დასრულდეს მანამ, სანამ ამას რაიმე მნიშვნელობა ექნება.
• ფილტრაციას შეუძლია ლეგიტიმური ტრაფიკი დაგიჯდეს. UDP ფლუდების წინააღმდეგ აგრესიულმა წესებმა შეიძლება რეალური მოთამაშეების პაკეტები გადაყაროს, რის გამოც mitigation ბალანსია და არა გადამრთველი, და რის გამოც "უბრალოდ უფრო მკაცრად გაფილტრე" უფასო არ არის.
• მოთამაშის სახლში ბოლო ნახტომს არაფერი ფილტრავს. თუ თავდამსხმელი მოთამაშეს ესხმის და არა შენს სერვერს, ეს მისი ISP-ის პრობლემაა და შენ ან შენი ჰოსტი ვერაფერს გააკეთებთ. voice chat და peer-to-peer ფუნქციები არის გზა, რომლითაც მისამართები ჟონავს.

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

შეტევები, რომლებიც ზუსტად მოთამაშეებს ჰგავს#

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

Query ფლუდები. განმეორებითი server-browser query-ები ისეთი სიხშირით, რომელსაც არცერთი ბრაუზერი არ გამოიმუშავებდა. თითოეული აიძულებს სერვერს, ააგოს პასუხი, რომელიც მიმდინარე მოთამაშეების სიასა და რუკას შეიცავს. გამოსწორებებია query cache ან rate limit, თუ თამაშს აქვს, query port-ის ნაგულისხმევიდან გადატანა და ზოგ engine-ში საჯარო სიის გამორთვა, სანამ ეს გრძელდება. რამდენიმე თამაშის სერვერის plugin-ები სწორედ ამას გთავაზობს; იხილე rate limit-ები და ბოროტად გამოყენება.

Join ფლუდები და bot-ების შესვლები. კლიენტები, რომლებიც უერთდებიან, handshake-სა და world-ში შესვლის განმავლობაში სლოტს იკავებენ, შემდეგ კი წყდებიან და ბრუნდებიან. Minecraft კლასიკური მსხვერპლია, რადგან კავშირები TCP-ზეა და კლიენტისთვის შესაქმნელად იაფია, ხოლო mitigation არის anti-bot plugin ან წინ მდგარი proxy, რომელიც ავტენტიფიკაციას backend-მა რამის დანახვამდე ატარებს. Velocity Minecraft ქსელის წინ ამის სტანდარტული ფორმაა.

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

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

არასასიამოვნო კანონზომიერება ოთხივეში: მცირე community-ზე ყველაზე ეფექტური application-layer შეტევები ჩვეულებრივ ისეთი ადამიანის მიერ ხორციელდება, რომელიც უკვე მასშია.

რა გეხმარება მეტად, ვიდრე ნებისმიერი ფილტრი#

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

1. მისამართი იმ ადგილებში არ გამოაქვეყნო, რომლებიც სერვერების სია არ არის. ნედლი IP იქ ნუ გამოაქვეყნებ, სადაც სახლის მისამართს არ გამოაქვეყნებდი. მოთამაშეებისთვის გამოიყენე hostname და იცოდე, რომ hostname მოხერხებულობაა და არა დამალვის ადგილი: A ჩანაწერი მისამართზე ჯდება და Minecraft-ის SRV ჩანაწერიც იგივეს აკეთებს. დომენის მიბმა გეიმ სერვერზე განმარტავს, რას იძენ და რას არა სახელით.
2. ვებსაიტი გეიმ სერვერს გამოაცალკევე. ვებსაიტი სხვა ჰოსტინგზე დააყენე სხვა მისამართით. ვებ front end proxy-ს უკან შეიძლება იდგეს, რომელიც მის origin-ს მალავს; UDP-ზე მდგარი გეიმ სერვერი ვერ იდგება. ეს მნიშვნელოვანია, რადგან ვებსაიტი ჩვეულებრივ სწორედ ის ადგილია, სადაც ხალხი თამაშის მისამართს პოულობს. Cloudflare ვებსაიტებისთვის და გეიმ სერვერებისთვის კონკრეტულია იმაზე, რას აპროქსირებს ნარინჯისფერი ღრუბელი და რას არასოდეს.
3. Query port ექსპოზიციად მიიჩნიე. ასე გპოულობენ სიების საიტები და ასევე თავდამსხმელები. გაუშვი იმიტომ, რომ ჩამონათვალში გინდა ყოფნა და არა ჩვევით, და მეორე ნუ დაგრჩება გამოყოფილი, თუ მას არაფერი იყენებს. გეიმ სერვერის პორტები ახსნილი მოიცავს, რომელი პორტები სჭირდება თითოეულ თამაშს რეალურად.
4. დაუშვი, რომ შენი community-ის ვინმე საბოლოოდ პრობლემა გახდება. პერსონალის უფლებები მინიმალური და გასაუქმებელი იყოს, ადმინისტრაციული პაროლები არ გაიზიარო და აქტივობის ლოგი გქონდეს, რომლის წაკითხვაც შემდეგ შეგიძლია. Subuser-ები და ყველაზე მცირე პრივილეგია არის ამის მექანიზმი panel-ის მხარეს.
5. Rate limit თამაშის დონეზე. კავშირების throttle-ები, query caching, anti-bot plugin, რიგი. ეს ერთადერთი დაცვაა ტრაფიკის წინააღმდეგ, რომელსაც ფილტრაცია ვერ ხედავს.
6. გქონდეს backup-ები, რომლებიც აღგიდგენია. შეტევა ერთადერთი ცუდი დღე არ არის და აღდგენის გზა იგივეა. backup, რომელიც არავის აუღდგენია, ჰიპოთეზაა.
7. ორფაქტორიანი ჩართე იმ ანგარიშზე, რომელიც ამ ყველაფერს აკონტროლებს. "გვიმსხვრიეს DDoS-ით" ისტორიების უმეტესობა, რომლებიც ცუდად მთავრდება, სინამდვილეში ანგარიშის კომპრომეტაციის ისტორიაა. ორფაქტორიანი შენს panel ანგარიშზე ორ წუთს იღებს.

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

შეტევის დროს#

მოკლე პროცედურა, რადგან იმ მომენტში ხალხი ცუდად იმპროვიზირებს.

1. დაადასტურე, რას უყურებ. შეამოწმე კონსოლი და გრაფიკები. უქმე სერვერი, ლოგში აქტივობა არ არის, მოთამაშეები წავიდნენ: volumetric ან protocol. მიჭედებული CPU, ლოგი კავშირებით სავსე: application layer.
2. ჩაიწერე დრო. დაწყება, დასრულება და რაც მოთამაშეებმა აცნობეს. დროის ნიშნულების გარეშე მოგვიანებით ვერავინ ვერაფერს მოძებნის.
3. ზედიზედ ნუ გადატვირთავ. ფლუდს ის არ ასუფთავებს, შენახულ პროგრესს კარგავს და ინციდენტს მოგვიანებით წასაკითხად ართულებს.
4. გახსენი ტიკეტი დროის ნიშნულებით. panel-იდან ის ყველა თანამშრომელთან აღწევს და დანართები კერძო რჩება. მიუთითე, იყო თუ არა თამაში საერთოდ სადმე ხელმისაწვდომი, და ნებისმიერი trace, რომლის გადაღებაც მოახერხე - traceroute-ისა და mtr-ის წაკითხვა მეთოდს შეიცავს.
5. თუ ეს application layer-ია, შეცვალე თამაშის კონფიგურაცია. გამორთე საჯარო სია, გაზარდე კავშირების throttle-ები, დროებით ჩართე whitelist. whitelist ბლაგვი იარაღია და ინციდენტს დაუყოვნებლივ ამთავრებს.
6. შემდეგ გაარკვიე, როგორ გიპოვეს და ვის ადარდებდა. მცირე სერვერებზე შეტევები თითქმის ყოველთვის პირადულია და "ვინ"-ის პასუხი ჩვეულებრივ ხელმისაწვდომია, თუ მუდმივ წევრებს ჰკითხავ.

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

FAQ#

შეუძლია თუ არა ჰოსტს გარანტია მოგცეს, რომ სერვერი შეტევისას მუშაობს?

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

დამიცავს დომენის სახელის უკან დამალვა?

არა. დომენი შენი მოთამაშეებისთვის მოხერხებულობაა და არა ფარი: ჩანაწერი იმავე მისამართზე ჯდება და ნებისმიერს წამში შეუძლია მისი მოძებნა. proxy-ები, რომლებიც origin მისამართს ნამდვილად მალავენ, TCP-ზე ვებ ტრაფიკისთვის მუშაობს; ისინი UDP-ს არ ატარებენ, რომელსაც გეიმ სერვერები იყენებენ.

რატომ არის ჩემი სერვერი სათამაშოდ გამოუსადეგარი, როცა გრაფიკები კარგად გამოიყურება?

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

მართლა საფრთხეა booter და stresser სერვისები?

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

რა არის join ფლუდი და როგორ შევაჩერო?

კლიენტები, რომლებიც განმეორებით უერთდებიან სლოტებისა და handshake-ის სამუშაოს დასახარჯად. ის თამაშის შიგნით ჩერდება: anti-bot plugin, კავშირების throttle, proxy, რომელიც ავტენტიფიკაციას რეალური სერვერის ჩართვამდე ატარებს, ან დროებით whitelist. upstream ფილტრაცია ვერაფერს შველის, რადგან თითოეული კავშირი ცალკე ლეგიტიმურია.

უნდა გადავიხადო დამატებით დაცვაში, როგორც add-on-ში?

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