DDoS ដើម្បីជួយសង្គ្រោះ៖ របៀបដែលយើងធ្វើតេស្តភាពតានតឹង និងផ្ទុក

Variti បង្កើតការការពារប្រឆាំងនឹង bots និងការវាយប្រហារដោយ DDoS ហើយក៏ធ្វើការសាកល្បងភាពតានតឹង និងការផ្ទុកផងដែរ។ នៅក្នុងសន្និសីទ HighLoad++ 2018 យើងបាននិយាយអំពីវិធីការពារធនធានពីប្រភេទផ្សេងៗនៃការវាយប្រហារ។ សរុបមក៖ ញែកផ្នែកនៃប្រព័ន្ធ ប្រើប្រាស់សេវាកម្មពពក និង CDNs និងធ្វើបច្ចុប្បន្នភាពជាប្រចាំ។ ប៉ុន្តែអ្នកនៅតែមិនអាចគ្រប់គ្រងការការពារដោយគ្មានក្រុមហ៊ុនឯកទេស :)

មុនពេលអានអត្ថបទ អ្នកអាចអានអរូបីខ្លីៗ នៅលើគេហទំព័រសន្និសីទ.
ហើយ​ប្រសិន​បើ​អ្នក​មិន​ចង់​អាន ឬ​គ្រាន់​តែ​ចង់​មើល​វីដេអូ​នោះ ការ​ថត​របាយការណ៍​របស់​យើង​គឺ​នៅ​ខាង​ក្រោម​នៅ​ក្រោម​ការ​បំផ្លាញ។

ការថតវីដេអូនៃរបាយការណ៍

ក្រុមហ៊ុនជាច្រើនបានដឹងពីរបៀបធ្វើការធ្វើតេស្តបន្ទុករួចហើយ ប៉ុន្តែមិនមែនទាំងអស់សុទ្ធតែធ្វើការធ្វើតេស្តភាពតានតឹងនោះទេ។ អតិថិជនរបស់យើងមួយចំនួនគិតថាគេហទំព័ររបស់ពួកគេងាយរងគ្រោះដោយសារតែពួកគេមានប្រព័ន្ធផ្ទុកខ្ពស់ ហើយវាការពារបានយ៉ាងល្អពីការវាយប្រហារ។ យើងបង្ហាញថានេះមិនពិតទាំងស្រុងទេ។
ជាការពិតណាស់ មុនពេលធ្វើតេស្ត យើងទទួលបានការអនុញ្ញាតពីអតិថិជន ចុះហត្ថលេខា និងបោះត្រា ហើយដោយមានជំនួយពីយើង ការវាយប្រហារ DDoS មិនអាចត្រូវបានអនុវត្តលើនរណាម្នាក់បានទេ។ ការធ្វើតេស្តត្រូវបានអនុវត្តនៅពេលជ្រើសរើសដោយអតិថិជន នៅពេលដែលចរាចរណ៍ទៅកាន់ធនធានរបស់គាត់មានតិចតួច ហើយបញ្ហានៃការចូលប្រើនឹងមិនប៉ះពាល់ដល់អតិថិជនទេ។ លើសពីនេះទៀត ដោយសារមានអ្វីមួយតែងតែអាចខុសក្នុងអំឡុងពេលដំណើរការសាកល្បង យើងមានទំនាក់ទំនងជាប្រចាំជាមួយអតិថិជន។ នេះអនុញ្ញាតឱ្យអ្នកមិនត្រឹមតែរាយការណ៍ពីលទ្ធផលដែលសម្រេចបានប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងអាចផ្លាស់ប្តូរអ្វីមួយកំឡុងពេលធ្វើតេស្តផងដែរ។ នៅពេលបញ្ចប់ការសាកល្បង យើងតែងតែបង្កើតរបាយការណ៍មួយ ដែលយើងចង្អុលបង្ហាញពីចំណុចខ្វះខាតដែលបានរកឃើញ និងផ្តល់អនុសាសន៍សម្រាប់ការលុបបំបាត់ភាពទន់ខ្សោយរបស់គេហទំព័រ។

របៀបដែលយើងកំពុងធ្វើការ

នៅពេលធ្វើតេស្ត យើងធ្វើត្រាប់តាម botnet ។ ដោយសារយើងធ្វើការជាមួយអតិថិជនដែលមិនមានទីតាំងនៅលើបណ្តាញរបស់យើង ដើម្បីធានាថាការធ្វើតេស្តមិនបញ្ចប់ក្នុងនាទីដំបូងដោយសារតែដែនកំណត់ ឬការការពារត្រូវបានបង្កឡើង យើងផ្គត់ផ្គង់បន្ទុកមិនមែនមកពី IP តែមួយទេ ប៉ុន្តែមកពីបណ្តាញរងរបស់យើងផ្ទាល់។ លើសពីនេះ ដើម្បីបង្កើតការផ្ទុកដ៏សំខាន់ យើងមានម៉ាស៊ីនមេសាកល្បងដ៏មានអនុភាពរបស់យើងផ្ទាល់។

ប្រកាស

ច្រើនពេកមិនមានន័យថាល្អទេ។
បន្ទុកតិច យើងអាចនាំធនធានទៅបរាជ័យ កាន់តែប្រសើរ។ ប្រសិនបើអ្នកអាចធ្វើឱ្យគេហទំព័រឈប់ដំណើរការលើសំណើមួយក្នុងមួយវិនាទី ឬសូម្បីតែសំណើមួយក្នុងមួយនាទី នោះជាការល្អណាស់។ ដោយសារតែយោងទៅតាមច្បាប់នៃអត្ថន័យ អ្នកប្រើប្រាស់ ឬអ្នកវាយប្រហារនឹងធ្លាក់ចូលទៅក្នុងភាពងាយរងគ្រោះពិសេសនេះដោយចៃដន្យ។

ការបរាជ័យដោយផ្នែកគឺប្រសើរជាងបរាជ័យទាំងស្រុង
យើង​តែងតែ​ណែនាំ​ឱ្យ​ធ្វើ​ឱ្យ​ប្រព័ន្ធ​ខុស​គ្នា​។ ជាងនេះទៅទៀត វាមានតម្លៃបំបែកពួកវានៅកម្រិតរូបវ័ន្ត ហើយមិនគ្រាន់តែដោយកុងតឺន័រប៉ុណ្ណោះទេ។ នៅក្នុងករណីនៃការបំបែករាងកាយ ទោះបីជាមានអ្វីមួយបរាជ័យនៅលើគេហទំព័រក៏ដោយ វាមានប្រូបាប៊ីលីតេខ្ពស់ដែលវានឹងមិនឈប់ដំណើរការទាំងស្រុងនោះទេ ហើយអ្នកប្រើប្រាស់នឹងបន្តមានសិទ្ធិចូលប្រើយ៉ាងហោចណាស់ផ្នែកនៃមុខងារ។

ស្ថាបត្យកម្មល្អគឺជាមូលដ្ឋានសម្រាប់និរន្តរភាព
ការអត់ឱនកំហុសនៃធនធាន និងសមត្ថភាពរបស់វាក្នុងការទប់ទល់នឹងការវាយប្រហារ និងបន្ទុកគួរតែត្រូវបានដាក់នៅដំណាក់កាលរចនា តាមពិតនៅដំណាក់កាលនៃការគូរគំនូសតាងលំហូរដំបូងនៅក្នុង notepad ។ ព្រោះប្រសិនបើមានកំហុសធ្ងន់ធ្ងរអាចឈានទៅដល់ការកែតម្រូវនៅពេលអនាគត ប៉ុន្តែវាពិតជាលំបាកខ្លាំងណាស់។

មិនត្រឹមតែកូដគួរល្អទេ ប៉ុន្តែក៏មានការកំណត់ផងដែរ។
មនុស្សជាច្រើនគិតថាក្រុមអភិវឌ្ឍន៍ល្អគឺជាការធានានៃសេវាកម្មដែលអត់ឱនចំពោះកំហុស។ ក្រុមអភិវឌ្ឍន៍ដ៏ល្អគឺពិតជាចាំបាច់ ប៉ុន្តែត្រូវតែមានប្រតិបត្តិការល្អផងដែរ DevOps ល្អ។ នោះគឺយើងត្រូវការអ្នកឯកទេសដែលនឹងកំណត់រចនាសម្ព័ន្ធលីនុច និងបណ្តាញឱ្យបានត្រឹមត្រូវ សរសេរការកំណត់រចនាសម្ព័ន្ធឱ្យបានត្រឹមត្រូវក្នុង nginx កំណត់ដែនកំណត់។ល។ បើមិនដូច្នោះទេធនធាននឹងដំណើរការបានល្អតែក្នុងការធ្វើតេស្តប៉ុណ្ណោះហើយនៅចំណុចខ្លះអ្វីៗនឹងខូចនៅក្នុងផលិតកម្ម។

ភាពខុសគ្នារវាងការធ្វើតេស្តបន្ទុក និងភាពតានតឹង
ការធ្វើតេស្តផ្ទុកអនុញ្ញាតឱ្យអ្នកកំណត់អត្តសញ្ញាណដែនកំណត់នៃដំណើរការប្រព័ន្ធ។ ការធ្វើតេស្តស្ត្រេសគឺសំដៅស្វែងរកចំណុចខ្សោយនៅក្នុងប្រព័ន្ធ ហើយត្រូវបានប្រើដើម្បីបំបែកប្រព័ន្ធនេះ និងមើលពីរបៀបដែលវានឹងមានឥរិយាបទនៅក្នុងដំណើរការនៃការបរាជ័យនៃផ្នែកមួយចំនួន។ ក្នុងករណីនេះ លក្ខណៈនៃការផ្ទុកជាធម្មតានៅតែមិនស្គាល់ចំពោះអតិថិជន មុនពេលការធ្វើតេស្តភាពតានតឹងចាប់ផ្តើម។

លក្ខណៈពិសេសប្លែកនៃការវាយប្រហារ L7

ជាធម្មតាយើងបែងចែកប្រភេទនៃបន្ទុកទៅជាបន្ទុកនៅកម្រិត L7 និង L3&4 ។ L7 គឺជាការផ្ទុកនៅកម្រិតកម្មវិធី ដែលភាគច្រើនវាមានន័យត្រឹមតែ HTTP ប៉ុន្តែយើងមានន័យថាការផ្ទុកណាមួយនៅកម្រិតពិធីការ TCP ។
ការវាយប្រហារ L7 មានលក្ខណៈពិសេសប្លែក។ ទីមួយ ពួកគេមកដោយផ្ទាល់ទៅកម្មវិធី នោះគឺវាមិនទំនងថាពួកគេនឹងត្រូវបានឆ្លុះបញ្ចាំងតាមរយៈមធ្យោបាយបណ្តាញទេ។ ការវាយប្រហារបែបនេះប្រើតក្កវិជ្ជា ហើយដោយសារបញ្ហានេះ ពួកគេប្រើប្រាស់ស៊ីភីយូ អង្គចងចាំ ថាស មូលដ្ឋានទិន្នន័យ និងធនធានផ្សេងទៀតយ៉ាងមានប្រសិទ្ធភាព និងមានចរាចរតិចតួច។

HTTP ទឹកជំនន់

ក្នុងករណីនៃការវាយប្រហារណាមួយ បន្ទុកគឺងាយស្រួលក្នុងការបង្កើតជាងការដោះស្រាយ ហើយក្នុងករណី L7 នេះក៏ជាការពិតផងដែរ។ វាមិនងាយស្រួលទេក្នុងការបែងចែកចរាចរណ៍វាយប្រហារពីចរាចរណ៍ស្របច្បាប់ ហើយភាគច្រើនវាអាចធ្វើបានដោយប្រេកង់ ប៉ុន្តែប្រសិនបើអ្វីៗទាំងអស់ត្រូវបានគ្រោងទុកត្រឹមត្រូវ នោះវាមិនអាចយល់បានពីកំណត់ហេតុដែលការវាយប្រហារគឺ និងកន្លែងដែលសំណើស្របច្បាប់នោះទេ។
ជាឧទាហរណ៍ដំបូង សូមពិចារណាការវាយប្រហារដោយទឹកជំនន់ HTTP ។ ក្រាហ្វបង្ហាញថាការវាយប្រហារបែបនេះជាធម្មតាមានអានុភាពខ្លាំងនៅក្នុងឧទាហរណ៍ខាងក្រោម ចំនួនសំណើខ្ពស់បំផុតលើសពី 600 ពាន់ក្នុងមួយនាទី។

HTTP Flood គឺជាមធ្យោបាយងាយស្រួលបំផុតដើម្បីបង្កើតបន្ទុក។ ជាធម្មតា វាត្រូវការឧបករណ៍ធ្វើតេស្តផ្ទុកមួយចំនួន ដូចជា ApacheBench ហើយកំណត់សំណើ និងគោលដៅ។ ជាមួយនឹងវិធីសាស្រ្តដ៏សាមញ្ញបែបនេះ មានប្រូបាប៊ីលីតេខ្ពស់ក្នុងការដំណើរការចូលទៅក្នុងឃ្លាំងសម្ងាត់របស់ម៉ាស៊ីនមេ ប៉ុន្តែវាងាយស្រួលក្នុងការឆ្លងកាត់វា។ ឧទាហរណ៍ ការបន្ថែមខ្សែអក្សរចៃដន្យទៅក្នុងសំណើ ដែលនឹងបង្ខំឱ្យម៉ាស៊ីនមេបម្រើទំព័រថ្មីជានិច្ច។
ដូចគ្នានេះផងដែរកុំភ្លេចអំពី user-agent នៅក្នុងដំណើរការនៃការបង្កើតបន្ទុកមួយ។ ភ្នាក់ងារអ្នកប្រើប្រាស់ជាច្រើននៃឧបករណ៍សាកល្បងដ៏ពេញនិយមត្រូវបានត្រងដោយអ្នកគ្រប់គ្រងប្រព័ន្ធ ហើយក្នុងករណីនេះការផ្ទុកប្រហែលជាមិនទៅដល់ផ្នែកខាងក្រោយទេ។ អ្នកអាចកែលម្អលទ្ធផលយ៉ាងខ្លាំងដោយបញ្ចូលបឋមកថាត្រឹមត្រូវច្រើន ឬតិចពីកម្មវិធីរុករកទៅក្នុងសំណើ។
សាមញ្ញដូចការវាយប្រហារ HTTP Flood ដែរ ពួកគេក៏មានគុណវិបត្តិរបស់ពួកគេផងដែរ។ ទីមួយ បរិមាណថាមពលច្រើនត្រូវបានទាមទារដើម្បីបង្កើតបន្ទុក។ ទីពីរ ការវាយប្រហារបែបនេះមានភាពងាយស្រួលក្នុងការរកឃើញ ជាពិសេសប្រសិនបើវាមកពីអាសយដ្ឋានមួយ។ ជាលទ្ធផល សំណើភ្លាមៗចាប់ផ្តើមត្រូវបានត្រងដោយអ្នកគ្រប់គ្រងប្រព័ន្ធ ឬសូម្បីតែនៅកម្រិតអ្នកផ្តល់សេវា។

អ្វីដែលត្រូវរកមើល

ដើម្បីកាត់បន្ថយចំនួនសំណើក្នុងមួយវិនាទីដោយមិនបាត់បង់ប្រសិទ្ធភាព អ្នកត្រូវបង្ហាញការស្រមើលស្រមៃបន្តិច និងរុករកគេហទំព័រ។ ដូច្នេះ អ្នកអាចផ្ទុកមិនត្រឹមតែឆានែល ឬម៉ាស៊ីនមេប៉ុណ្ណោះទេ ប៉ុន្តែក៏មានផ្នែកនីមួយៗនៃកម្មវិធីផងដែរ ឧទាហរណ៍ មូលដ្ឋានទិន្នន័យ ឬប្រព័ន្ធឯកសារ។ អ្នកក៏អាចរកមើលកន្លែងនៅលើគេហទំព័រដែលធ្វើការគណនាធំៗ៖ ម៉ាស៊ីនគិតលេខ ទំព័រជ្រើសរើសផលិតផល។ល។ ទីបំផុត វាជារឿយៗកើតឡើងដែលគេហទំព័រនេះមានប្រភេទអក្សរ PHP ដែលបង្កើតទំព័រជាច្រើនរយពាន់បន្ទាត់។ ស្គ្រីបបែបនេះក៏ផ្ទុកម៉ាស៊ីនមេយ៉ាងខ្លាំង ហើយអាចក្លាយជាគោលដៅសម្រាប់ការវាយប្រហារមួយ។

កន្លែងដែលត្រូវស្វែងរក

នៅពេលដែលយើងស្កែនធនធានមុននឹងធ្វើការសាកល្បង យើងមើលទៅដំបូងនៅកន្លែងដែលខ្លួនវាផ្ទាល់។ យើងកំពុងស្វែងរកវាលបញ្ចូលគ្រប់ប្រភេទ ឯកសារធ្ងន់ៗ - ជាទូទៅអ្វីគ្រប់យ៉ាងដែលអាចបង្កើតបញ្ហាសម្រាប់ធនធាន និងធ្វើឱ្យប្រតិបត្តិការរបស់វាថយចុះ។ ឧបករណ៍អភិវឌ្ឍន៍ Banal នៅក្នុង Google Chrome និង Firefox ជួយនៅទីនេះ ដោយបង្ហាញម៉ោងឆ្លើយតបទំព័រ។
យើងក៏ស្កេនដែនរងផងដែរ។ ឧទាហរណ៍ មានហាងអនឡាញជាក់លាក់មួយ abc.com ហើយវាមានដែនរង admin.abc.com ។ ភាគច្រើនទំនងជានេះគឺជាផ្ទាំងគ្រប់គ្រងដែលមានការអនុញ្ញាត ប៉ុន្តែប្រសិនបើអ្នកដាក់បន្ទុកលើវា វាអាចបង្កើតបញ្ហាសម្រាប់ធនធានចម្បង។
គេហទំព័រនេះអាចមាន subdomain api.abc.com ។ ភាគច្រើនទំនងជានេះគឺជាធនធានសម្រាប់កម្មវិធីទូរស័ព្ទ។ កម្មវិធីអាចរកបាននៅក្នុង App Store ឬ Google Play ដំឡើងចំណុចចូលពិសេស បំបែក API និងចុះឈ្មោះគណនីសាកល្បង។ បញ្ហាគឺថាមនុស្សតែងតែគិតថាអ្វីដែលត្រូវបានការពារដោយការអនុញ្ញាតគឺមានភាពស៊ាំនឹងការបដិសេធនៃការវាយប្រហារសេវាកម្ម។ សន្មត់ថាការអនុញ្ញាតគឺជា CAPTCHA ដ៏ល្អបំផុត ប៉ុន្តែវាមិនមែនទេ។ វាងាយស្រួលក្នុងការបង្កើតគណនីសាកល្បង 10-20 ប៉ុន្តែតាមរយៈការបង្កើតពួកវា យើងទទួលបានមុខងារស្មុគស្មាញ និងគ្មានការក្លែងបន្លំ។
ជាធម្មតា យើងមើលប្រវត្តិសាស្រ្តនៅ robots.txt និង WebArchive, ViewDNS និងរកមើលកំណែចាស់នៃធនធាន។ ពេលខ្លះវាកើតឡើងដែលអ្នកអភិវឌ្ឍន៍បានបញ្ចេញ mail2.yandex.net ប៉ុន្តែកំណែចាស់ mail.yandex.net នៅតែមាន។ mail.yandex.net នេះមិនត្រូវបានគាំទ្រទៀតទេ ធនធានអភិវឌ្ឍន៍មិនត្រូវបានបែងចែកទៅឱ្យវាទេ ប៉ុន្តែវានៅតែបន្តប្រើប្រាស់មូលដ្ឋានទិន្នន័យ។ ដូច្នោះហើយ ដោយប្រើកំណែចាស់ អ្នកអាចប្រើធនធាននៃកម្មវិធីខាងក្រោយ និងអ្វីៗគ្រប់យ៉ាងដែលនៅពីក្រោយប្លង់យ៉ាងមានប្រសិទ្ធភាព។ ជាការពិតណាស់ វាមិនតែងតែកើតឡើងនោះទេ ប៉ុន្តែយើងនៅតែជួបប្រទះរឿងនេះជាញឹកញាប់។
តាមធម្មជាតិ យើងវិភាគប៉ារ៉ាម៉ែត្រសំណើទាំងអស់ និងរចនាសម្ព័ន្ធខូគី។ អ្នកអាចនិយាយថា ទម្លាក់តម្លៃមួយចំនួនទៅក្នុងអារេ JSON នៅខាងក្នុងខូគី បង្កើតសំបុកជាច្រើន និងធ្វើឱ្យធនធានដំណើរការក្នុងរយៈពេលយូរមិនសមហេតុផល។

ស្វែងរកបន្ទុក

រឿងដំបូងដែលគិតដល់ពេលស្រាវជ្រាវគេហទំព័រគឺត្រូវផ្ទុកទិន្នន័យ ព្រោះស្ទើរតែគ្រប់គ្នាមានការស្វែងរក ហើយសម្រាប់ស្ទើរតែគ្រប់គ្នា ជាអកុសលវាត្រូវបានការពារយ៉ាងលំបាក។ សម្រាប់ហេតុផលមួយចំនួន អ្នកអភិវឌ្ឍន៍មិនយកចិត្តទុកដាក់គ្រប់គ្រាន់ក្នុងការស្វែងរកទេ។ ប៉ុន្តែមានអនុសាសន៍មួយនៅទីនេះ - អ្នកមិនគួរធ្វើសំណើប្រភេទដូចគ្នាទេ ព្រោះអ្នកអាចជួបប្រទះនឹងការលាក់ទុកដូចជាករណីទឹកជំនន់ HTTP ដែរ។
ការធ្វើសំណួរចៃដន្យទៅកាន់មូលដ្ឋានទិន្នន័យក៏មិនមានប្រសិទ្ធភាពដែរ។ វាល្អប្រសើរជាងក្នុងការបង្កើតបញ្ជីពាក្យគន្លឹះដែលពាក់ព័ន្ធនឹងការស្វែងរក។ ប្រសិនបើយើងត្រលប់ទៅឧទាហរណ៍នៃហាងអនឡាញ៖ ចូរនិយាយថាគេហទំព័រលក់សំបកកង់រថយន្ត និងអនុញ្ញាតឱ្យអ្នកកំណត់កាំនៃសំបកកង់ ប្រភេទរថយន្ត និងប៉ារ៉ាម៉ែត្រផ្សេងទៀត។ ដូច្នោះហើយ ការបញ្ចូលគ្នានៃពាក្យដែលពាក់ព័ន្ធនឹងបង្ខំឱ្យមូលដ្ឋានទិន្នន័យដំណើរការក្នុងលក្ខខណ្ឌស្មុគស្មាញជាង។
លើសពីនេះ វាមានតម្លៃក្នុងការប្រើ pagination៖ វាពិបាកជាងសម្រាប់ការស្វែងរកដើម្បីត្រឡប់ទំព័រចុងក្រោយនៃលទ្ធផលស្វែងរកជាងទំព័រដំបូង។ នោះគឺដោយមានជំនួយពី pagination អ្នកអាចធ្វើពិពិធកម្មបន្ទុកបន្តិច។
ឧទាហរណ៍ខាងក្រោមបង្ហាញពីការផ្ទុកការស្វែងរក។ វាអាចត្រូវបានគេមើលឃើញថាចាប់ពីវិនាទីដំបូងនៃការធ្វើតេស្តក្នុងល្បឿន 10 សំណើក្នុងមួយវិនាទីគេហទំព័របានធ្លាក់ចុះហើយមិនឆ្លើយតប។

ប្រសិនបើគ្មានការស្វែងរកទេ?

ប្រសិនបើគ្មានការស្វែងរកទេ នេះមិនមែនមានន័យថាគេហទំព័រនោះមិនមានវាលបញ្ចូលដែលងាយរងគ្រោះផ្សេងទៀតនោះទេ។ វាលនេះអាចជាការអនុញ្ញាត។ សព្វថ្ងៃនេះ អ្នកអភិវឌ្ឍន៍ចូលចិត្តបង្កើត hashe ស្មុគស្មាញ ដើម្បីការពារមូលដ្ឋានទិន្នន័យចូលពីការវាយប្រហារតារាងឥន្ទធនូ។ នេះគឺល្អ ប៉ុន្តែ hashe បែបនេះប្រើប្រាស់ធនធាន CPU ច្រើន។ លំហូរដ៏ធំនៃការអនុញ្ញាតមិនពិតនាំឱ្យដំណើរការដំណើរការបរាជ័យ ហើយជាលទ្ធផល គេហទំព័រឈប់ដំណើរការ។
វត្តមាននៅលើគេហទំព័រនៃទម្រង់គ្រប់ប្រភេទសម្រាប់មតិយោបល់ និងមតិកែលម្អ គឺជាហេតុផលដើម្បីផ្ញើអត្ថបទធំៗនៅទីនោះ ឬគ្រាន់តែបង្កើតទឹកជំនន់ដ៏ធំ។ ពេលខ្លះគេហទំព័រទទួលយកឯកសារភ្ជាប់ រួមទាំងទម្រង់ gzip ផងដែរ។ ក្នុងករណីនេះ យើងយកឯកសារទំហំ 1TB បង្រួមវាទៅជាបៃ ឬគីឡូបៃជាច្រើនដោយប្រើ gzip ហើយផ្ញើវាទៅគេហទំព័រ។ បន្ទាប់មកវាត្រូវបានពន្លាហើយឥទ្ធិពលគួរឱ្យចាប់អារម្មណ៍ខ្លាំងណាស់ត្រូវបានទទួល។

API សម្រាក

ខ្ញុំចង់យកចិត្តទុកដាក់បន្តិចចំពោះសេវាកម្មដ៏ពេញនិយមដូចជា Rest API។ ការធានា Rest API គឺពិបាកជាងគេហទំព័រធម្មតា។ សូម្បីតែវិធីសាស្រ្តការពារមិនពិតប្រឆាំងនឹងការបង្ខំ brute ពាក្យសម្ងាត់ និងសកម្មភាពមិនស្របច្បាប់ផ្សេងទៀតក៏មិនដំណើរការសម្រាប់ Rest API ដែរ។
Rest API ងាយស្រួលបំបែកព្រោះវាចូលប្រើមូលដ្ឋានទិន្នន័យដោយផ្ទាល់។ ក្នុងពេលជាមួយគ្នានេះ ការបរាជ័យនៃសេវាកម្មបែបនេះនាំឱ្យមានផលវិបាកធ្ងន់ធ្ងរសម្រាប់អាជីវកម្ម។ ការពិតគឺថា Rest API ជាធម្មតាត្រូវបានប្រើមិនត្រឹមតែសម្រាប់គេហទំព័រសំខាន់ប៉ុណ្ណោះទេ ប៉ុន្តែសម្រាប់កម្មវិធីទូរស័ព្ទ និងធនធានអាជីវកម្មខាងក្នុងមួយចំនួនផងដែរ។ ហើយប្រសិនបើទាំងអស់នេះធ្លាក់ចុះ នោះឥទ្ធិពលគឺខ្លាំងជាងនៅក្នុងករណីនៃការបរាជ័យគេហទំព័រសាមញ្ញ។

កំពុងផ្ទុកមាតិកាធ្ងន់

ប្រសិនបើយើងត្រូវបានផ្តល់ជូនដើម្បីសាកល្បងកម្មវិធីសាមញ្ញមួយទំព័រ ទំព័រចុះចត ឬគេហទំព័រនាមប័ណ្ណដែលមិនមានមុខងារស្មុគស្មាញ យើងស្វែងរកខ្លឹមសារធ្ងន់ៗ។ ឧទាហរណ៍ រូបភាពធំៗដែលម៉ាស៊ីនមេផ្ញើ ឯកសារគោលពីរ ឯកសារ pdf - យើងព្យាយាមទាញយកទាំងអស់នេះ។ ការធ្វើតេស្តបែបនេះផ្ទុកប្រព័ន្ធឯកសារបានល្អ និងស្ទះបណ្តាញ ដូច្នេះមានប្រសិទ្ធភាព។ នោះគឺ ទោះបីជាអ្នកមិនដាក់ server ចុះក៏ដោយ ការទាញយកឯកសារធំមួយក្នុងល្បឿនទាប អ្នកនឹងបិទឆានែលរបស់ម៉ាស៊ីនមេគោលដៅ ហើយការបដិសេធសេវាកម្មនឹងកើតឡើង។
ឧទាហរណ៍នៃការធ្វើតេស្តបែបនេះបង្ហាញថាក្នុងល្បឿន 30 RPS គេហទំព័រឈប់ឆ្លើយតប ឬបង្កើតកំហុសម៉ាស៊ីនមេទី 500 ។

កុំភ្លេចអំពីការដំឡើងម៉ាស៊ីនមេ។ ជាញឹកញាប់អ្នកអាចរកឃើញថាមនុស្សម្នាក់បានទិញម៉ាស៊ីននិម្មិត ដំឡើងកម្មវិធី Apache នៅទីនោះ កំណត់រចនាសម្ព័ន្ធអ្វីគ្រប់យ៉ាងតាមលំនាំដើម ដំឡើងកម្មវិធី PHP ហើយខាងក្រោមអ្នកអាចឃើញលទ្ធផល។

នៅទីនេះបន្ទុកបានទៅដល់ឫសហើយមានចំនួនត្រឹមតែ 10 RPS ប៉ុណ្ណោះ។ យើងរង់ចាំ 5 នាទី ហើយម៉ាស៊ីនមេបានគាំង។ វាជាការពិតដែលថាវាមិនត្រូវបានគេដឹងទាំងស្រុងពីមូលហេតុដែលគាត់ដួលនោះទេប៉ុន្តែមានការសន្មត់ថាគាត់គ្រាន់តែមានការចងចាំច្រើនពេកហើយដូច្នេះឈប់ឆ្លើយតប។

ផ្អែកលើរលក

ក្នុង​មួយ​ឬ​ពីរ​ឆ្នាំ​ចុង​ក្រោយ​នេះ ការ​វាយ​ប្រហារ​ដោយ​រលក​បាន​ក្លាយ​ជា​ការ​ពេញ​និយម​យ៉ាង​ខ្លាំង។ នេះគឺដោយសារតែស្ថាប័នជាច្រើនទិញផ្នែកខ្លះនៃផ្នែករឹងសម្រាប់ការការពារ DDoS ដែលទាមទារពេលវេលាជាក់លាក់មួយដើម្បីប្រមូលស្ថិតិដើម្បីចាប់ផ្តើមត្រងការវាយប្រហារ។ នោះគឺពួកគេមិនត្រងការវាយប្រហារក្នុងរយៈពេល 30-40 វិនាទីដំបូងឡើយ ព្រោះវាប្រមូលផ្តុំទិន្នន័យ និងរៀន។ ដូច្នោះហើយ ក្នុងរយៈពេល 30-40 វិនាទីនេះ អ្នកអាចបើកដំណើរការបានច្រើននៅលើគេហទំព័រ ដែលធនធាននឹងកុហករយៈពេលយូររហូតដល់សំណើទាំងអស់ត្រូវបានសម្អាត។
ក្នុងករណីនៃការវាយប្រហារខាងក្រោម មានចន្លោះពេល 10 នាទី បន្ទាប់ពីនោះផ្នែកថ្មីដែលបានកែប្រែនៃការវាយប្រហារបានមកដល់។

នោះគឺ ការពារជាតិបានរៀន ចាប់ផ្តើមត្រង ប៉ុន្តែផ្នែកថ្មី និងខុសគ្នាទាំងស្រុងនៃការវាយប្រហារបានមកដល់ ហើយការការពារបានចាប់ផ្តើមរៀនម្តងទៀត។ តាមពិត ការត្រងឈប់ដំណើរការ ការការពារមិនមានប្រសិទ្ធភាព ហើយគេហទំព័រមិនអាចប្រើបាន។
ការវាយប្រហារដោយរលកត្រូវបានកំណត់លក្ខណៈដោយតម្លៃខ្ពស់ខ្លាំងណាស់នៅកំពូលវាអាចឈានដល់មួយរយពាន់ឬមួយលានសំណើក្នុងមួយវិនាទីក្នុងករណី L7 ។ ប្រសិនបើយើងនិយាយអំពី L3&4 នោះវាអាចមានចរាចរណ៍រាប់រយជីហ្គាបៃ ឬតាមនោះរាប់រយ mpps ប្រសិនបើអ្នករាប់ក្នុងកញ្ចប់។
បញ្ហាជាមួយនឹងការវាយប្រហារបែបនេះគឺការធ្វើសមកាលកម្ម។ ការវាយប្រហារបានមកពី botnet និងទាមទារកម្រិតខ្ពស់នៃការធ្វើសមកាលកម្មដើម្បីបង្កើតការកើនឡើងមួយដងដ៏ធំ។ ហើយការសម្របសម្រួលនេះមិនតែងតែដំណើរការទេ៖ ពេលខ្លះទិន្នផលគឺជាប្រភេទនៃកំពូលប៉ារ៉ាបូល ដែលមើលទៅគួរអោយអាណិត។

មិនមែន HTTP តែម្នាក់ឯងទេ។

បន្ថែមពីលើ HTTP នៅ L7 យើងចូលចិត្តទាញយកពិធីការផ្សេងទៀត។ តាមក្បួនមួយ គេហទំព័រធម្មតា ជាពិសេសការបង្ហោះធម្មតាមាន mail protocols និង MySQL ជាប់។ ពិធីសារសំបុត្រត្រូវទទួលរងការផ្ទុកតិចជាងមូលដ្ឋានទិន្នន័យ ប៉ុន្តែពួកវាក៏អាចផ្ទុកយ៉ាងមានប្រសិទ្ធភាព និងបញ្ចប់ដោយស៊ីភីយូលើសទម្ងន់នៅលើម៉ាស៊ីនមេ។
យើងទទួលបានជោគជ័យយ៉ាងខ្លាំងដោយប្រើភាពងាយរងគ្រោះ SSH ឆ្នាំ 2016 ។ ឥឡូវនេះ ភាពងាយរងគ្រោះនេះត្រូវបានជួសជុលសម្រាប់ស្ទើរតែគ្រប់គ្នា ប៉ុន្តែនេះមិនមានន័យថាការផ្ទុកមិនអាចត្រូវបានដាក់ជូន SSH នោះទេ។ អាច។ មានការអនុញ្ញាតច្រើនយ៉ាងសាមញ្ញ SSH ស៊ីស៊ីភីយូស្ទើរតែទាំងស្រុងនៅលើម៉ាស៊ីនមេ ហើយបន្ទាប់មកគេហទំព័រនឹងដួលរលំពីសំណើមួយ ឬពីរក្នុងមួយវិនាទី។ អាស្រ័យហេតុនេះ សំណើមួយ ឬពីរដែលផ្អែកលើកំណត់ហេតុមិនអាចសម្គាល់ពីបន្ទុកស្របច្បាប់បានទេ។
ការតភ្ជាប់ជាច្រើនដែលយើងបើកនៅក្នុងម៉ាស៊ីនមេក៏នៅតែពាក់ព័ន្ធផងដែរ។ កាលពីមុន Apache មានកំហុសចំពោះបញ្ហានេះ ឥឡូវនេះ nginx ពិតជាមានកំហុសចំពោះបញ្ហានេះ ដោយសារវាត្រូវបានកំណត់រចនាសម្ព័ន្ធតាមលំនាំដើមជាញឹកញាប់។ ចំនួននៃការតភ្ជាប់ដែល nginx អាចរក្សាការបើកចំហមានកំណត់ ដូច្នេះយើងបើកចំនួននៃការតភ្ជាប់នេះ nginx លែងទទួលយកការតភ្ជាប់ថ្មីទៀតហើយ ជាលទ្ធផលគេហទំព័រមិនដំណើរការទេ។
ចង្កោមសាកល្បងរបស់យើងមានស៊ីភីយូគ្រប់គ្រាន់ដើម្បីវាយប្រហារការចាប់ដៃ SSL ។ ជាគោលការណ៍ ដូចដែលការអនុវត្តបង្ហាញ ពេលខ្លះ botnets ក៏ចូលចិត្តធ្វើបែបនេះដែរ។ ម្យ៉ាងវិញទៀត វាច្បាស់ណាស់ថាអ្នកមិនអាចធ្វើដោយគ្មាន SSL បានទេ ព្រោះលទ្ធផល Google ចំណាត់ថ្នាក់ សុវត្ថិភាព។ ម្យ៉ាងវិញទៀត SSL ជាអកុសលមានបញ្ហាស៊ីភីយូ។

L3&4

នៅពេលយើងនិយាយអំពីការវាយប្រហារនៅកម្រិត L3&4 ជាធម្មតាយើងកំពុងនិយាយអំពីការវាយប្រហារនៅកម្រិតតំណ។ បន្ទុកបែបនេះស្ទើរតែតែងតែអាចសម្គាល់បានពីភាពស្របច្បាប់ លុះត្រាតែវាជាការវាយប្រហារដោយទឹកជំនន់ SYN។ បញ្ហាជាមួយនឹងការវាយប្រហារដោយទឹកជំនន់ SYN សម្រាប់ឧបករណ៍សុវត្ថិភាពគឺជាបរិមាណដ៏ធំរបស់ពួកគេ។ តម្លៃ L3&4 អតិបរមាគឺ 1,5-2 Tbit/s ។ ប្រភេទនៃចរាចរណ៍នេះគឺពិបាកណាស់ក្នុងដំណើរការសូម្បីតែក្រុមហ៊ុនធំៗ រួមទាំង Oracle និង Google ផងដែរ។
SYN និង SYN-ACK គឺជាកញ្ចប់ព័ត៌មានដែលប្រើនៅពេលបង្កើតការតភ្ជាប់។ ដូច្នេះ SYN-ទឹកជំនន់គឺពិបាកក្នុងការបែងចែកពីបន្ទុកស្របច្បាប់៖ វាមិនច្បាស់ថាតើនេះជា SYN ដែលបានមកដើម្បីបង្កើតការតភ្ជាប់ ឬជាផ្នែកនៃទឹកជំនន់។

UDP-ទឹកជំនន់

ជាធម្មតា អ្នកវាយប្រហារមិនមានសមត្ថភាពដូចដែលយើងមានទេ ដូច្នេះ amplification អាចត្រូវបានប្រើដើម្បីរៀបចំការវាយប្រហារ។ នោះគឺអ្នកវាយប្រហារស្កេនអ៊ីនធឺណិត ហើយរកឃើញម៉ាស៊ីនមេដែលងាយរងគ្រោះ ឬកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវ ដែលឧទាហរណ៍ ក្នុងការឆ្លើយតបទៅនឹងកញ្ចប់ព័ត៌មាន SYN មួយ ឆ្លើយតបជាមួយ SYN-ACKs ចំនួនបី។ ដោយការក្លែងបន្លំអាសយដ្ឋានប្រភពពីអាសយដ្ឋាននៃម៉ាស៊ីនមេគោលដៅ វាអាចបង្កើនថាមពលដោយនិយាយថាបីដងជាមួយនឹងកញ្ចប់ព័ត៌មានតែមួយ និងបញ្ជូនចរាចរទៅកាន់ជនរងគ្រោះវិញ។

បញ្ហាជាមួយនឹងការពង្រីកគឺថាពួកគេពិបាកក្នុងការរកឃើញ។ ឧទាហរណ៍ថ្មីៗរួមមានករណីដ៏រំជួលចិត្តនៃ memcached ដែលងាយរងគ្រោះ។ លើសពីនេះ ឥឡូវនេះមានឧបករណ៍ IoT ជាច្រើន កាមេរ៉ា IP ដែលភាគច្រើនត្រូវបានកំណត់រចនាសម្ព័ន្ធតាមលំនាំដើម ហើយតាមលំនាំដើម ពួកវាត្រូវបានកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវ ដែលជាមូលហេតុដែលអ្នកវាយប្រហារភាគច្រើនធ្វើការវាយប្រហារតាមរយៈឧបករណ៍បែបនេះ។

SYN ពិបាក - ទឹកជំនន់

SYN-flood ប្រហែលជាប្រភេទនៃការវាយប្រហារដែលគួរឱ្យចាប់អារម្មណ៍បំផុតតាមទស្សនៈរបស់អ្នកអភិវឌ្ឍន៍។ បញ្ហាគឺថាអ្នកគ្រប់គ្រងប្រព័ន្ធជារឿយៗប្រើការទប់ស្កាត់ IP ដើម្បីការពារ។ លើសពីនេះទៅទៀត ការទប់ស្កាត់ IP ប៉ះពាល់មិនត្រឹមតែអ្នកគ្រប់គ្រងប្រព័ន្ធដែលធ្វើសកម្មភាពដោយប្រើស្គ្រីបប៉ុណ្ណោះទេ ប៉ុន្តែជាអកុសលផងដែរ ប្រព័ន្ធសុវត្ថិភាពមួយចំនួនដែលត្រូវបានទិញក្នុងតម្លៃដ៏ច្រើន។
វិធីសាស្រ្តនេះអាចប្រែទៅជាគ្រោះមហន្តរាយ ព្រោះប្រសិនបើអ្នកវាយប្រហារជំនួសអាសយដ្ឋាន IP ក្រុមហ៊ុននឹងបិទបណ្តាញរងរបស់ខ្លួន។ នៅពេលដែល Firewall ទប់ស្កាត់ចង្កោមរបស់វា លទ្ធផលនឹងបរាជ័យ អន្តរកម្មខាងក្រៅ ហើយធនធាននឹងបរាជ័យ។
លើសពីនេះទៅទៀតវាមិនពិបាកក្នុងការបិទបណ្តាញផ្ទាល់ខ្លួនរបស់អ្នកទេ។ ប្រសិនបើការិយាល័យរបស់អតិថិជនមានបណ្តាញ Wi-Fi ឬប្រសិនបើដំណើរការនៃធនធានត្រូវបានវាស់វែងដោយប្រើប្រព័ន្ធត្រួតពិនិត្យផ្សេងៗ នោះយើងយកអាសយដ្ឋាន IP នៃប្រព័ន្ធត្រួតពិនិត្យនេះ ឬការិយាល័យរបស់អតិថិជន Wi-Fi ហើយប្រើវាជាប្រភព។ នៅចុងបញ្ចប់ ធនធានហាក់ដូចជាមាន ប៉ុន្តែអាសយដ្ឋាន IP គោលដៅត្រូវបានរារាំង។ ដូច្នេះ បណ្តាញ Wi-Fi នៃសន្និសីទ HighLoad ដែលផលិតផលថ្មីរបស់ក្រុមហ៊ុនកំពុងត្រូវបានបង្ហាញ អាចត្រូវបានរារាំង ហើយនេះរួមបញ្ចូលការចំណាយលើអាជីវកម្ម និងសេដ្ឋកិច្ចមួយចំនួន។
កំឡុងពេលសាកល្បង យើងមិនអាចប្រើការពង្រីកតាមរយៈ memcached ជាមួយធនធានខាងក្រៅណាមួយបានទេ ព្រោះមានកិច្ចព្រមព្រៀងដើម្បីបញ្ជូនចរាចរណ៍ទៅអាសយដ្ឋាន IP ដែលអនុញ្ញាតប៉ុណ្ណោះ។ ដូច្នោះហើយ យើងប្រើការពង្រីកតាមរយៈ SYN និង SYN-ACK នៅពេលដែលប្រព័ន្ធឆ្លើយតបទៅនឹងការបញ្ជូន SYN មួយជាមួយនឹង SYN-ACK ពីរឬបី ហើយនៅលទ្ធផល ការវាយប្រហារត្រូវបានគុណនឹង 2 ឬ 3 ដង។

ឧបករណ៍

ឧបករណ៍សំខាន់មួយដែលយើងប្រើសម្រាប់បន្ទុកការងារ L7 គឺ Yandex-tank ។ ជាពិសេស phantom ត្រូវបានគេប្រើជាកាំភ្លើង បូករួមទាំងមានស្គ្រីបជាច្រើនសម្រាប់បង្កើត cartridges និងសម្រាប់ការវិភាគលទ្ធផល។
Tcpdump ត្រូវបានប្រើដើម្បីវិភាគចរាចរបណ្តាញ ហើយ Nmap ត្រូវបានប្រើដើម្បីវិភាគម៉ាស៊ីនមេ។ ដើម្បីបង្កើតបន្ទុកនៅកម្រិត L3&4 OpenSSL និងវេទមន្តតិចតួចរបស់យើងជាមួយបណ្ណាល័យ DPDK ត្រូវបានប្រើ។ DPDK គឺជាបណ្ណាល័យពី Intel ដែលអនុញ្ញាតឱ្យអ្នកធ្វើការជាមួយចំណុចប្រទាក់បណ្តាញដោយឆ្លងកាត់ជង់លីនុចដោយហេតុនេះបង្កើនប្រសិទ្ធភាព។ តាមធម្មជាតិ យើងប្រើ DPDK មិនត្រឹមតែនៅកម្រិត L3&4 ប៉ុណ្ណោះទេ ប៉ុន្តែវាក៏នៅកម្រិត L7 ផងដែរ ព្រោះវាអនុញ្ញាតឱ្យយើងបង្កើតលំហូរផ្ទុកខ្ពស់ខ្លាំង ក្នុងចន្លោះសំណើរាប់លានក្នុងមួយវិនាទីពីម៉ាស៊ីនមួយ។
យើងក៏ប្រើម៉ាស៊ីនភ្លើងចរាចរណ៍ជាក់លាក់ និងឧបករណ៍ពិសេសដែលយើងសរសេរសម្រាប់ការធ្វើតេស្តជាក់លាក់។ ប្រសិនបើយើងរំលឹកឡើងវិញនូវភាពងាយរងគ្រោះនៅក្រោម SSH នោះសំណុំខាងលើមិនអាចត្រូវបានគេកេងប្រវ័ញ្ចនោះទេ។ ប្រសិនបើ​យើង​វាយលុក​ពិធីការ​សំបុត្រ យើង​ប្រើ​ឧបករណ៍​ប្រើប្រាស់​សំបុត្រ ឬ​គ្រាន់តែ​សរសេរ​ស្គ្រីប​លើ​ពួកវា។

ការរកឃើញ

ជាការសន្និដ្ឋានខ្ញុំចង់និយាយ៖

• បន្ថែមពីលើការធ្វើតេស្តបន្ទុកបុរាណ វាចាំបាច់ក្នុងការធ្វើការធ្វើតេស្តភាពតានតឹង។ យើង​មាន​ឧទាហរណ៍​ជាក់ស្តែង​ដែល​អ្នក​ម៉ៅការ​បន្ត​របស់​ដៃគូ​ធ្វើ​ការ​សាកល្បង​បន្ទុក​ប៉ុណ្ណោះ។ វាបានបង្ហាញថាធនធានអាចទប់ទល់នឹងបន្ទុកធម្មតា។ ប៉ុន្តែបន្ទាប់មកបន្ទុកមិនប្រក្រតីមួយបានលេចឡើង អ្នកទស្សនាគេហទំព័របានចាប់ផ្តើមប្រើប្រាស់ធនធានខុសគ្នាបន្តិចបន្តួច ហើយជាលទ្ធផលអ្នកម៉ៅការបន្តបានបញ្ឈប់។ ដូច្នេះវាមានតម្លៃក្នុងការស្វែងរកភាពងាយរងគ្រោះ ទោះបីជាអ្នកត្រូវបានការពារពីការវាយប្រហារ DDoS រួចហើយក៏ដោយ។
• វាចាំបាច់ក្នុងការផ្តាច់ផ្នែកខ្លះនៃប្រព័ន្ធពីអ្នកដទៃ។ ប្រសិនបើអ្នកមានការស្វែងរក អ្នកត្រូវផ្លាស់ទីវាទៅម៉ាស៊ីនដាច់ដោយឡែក ពោលគឺមិនមែនទៅ Docker ទេ។ ដោយសារតែប្រសិនបើការស្វែងរកឬការអនុញ្ញាតបរាជ័យ យ៉ាងហោចណាស់អ្វីមួយនឹងបន្តដំណើរការ។ ក្នុងករណីហាងអនឡាញ អ្នកប្រើប្រាស់នឹងបន្តស្វែងរកផលិតផលនៅក្នុងកាតាឡុក ចូលទៅកាន់អ្នកប្រមូលទិញ ប្រសិនបើពួកគេត្រូវបានអនុញ្ញាតរួចហើយ ឬផ្តល់សិទ្ធិតាមរយៈ OAuth2។
• កុំធ្វេសប្រហែសលើសេវាកម្មពពកគ្រប់ប្រភេទ។
• ប្រើ CDN មិនត្រឹមតែដើម្បីបង្កើនប្រសិទ្ធភាពការពន្យារពេលបណ្តាញប៉ុណ្ណោះទេ ប៉ុន្តែក៏ជាមធ្យោបាយការពារប្រឆាំងនឹងការវាយប្រហារលើការហត់នឿយរបស់ឆានែល និងគ្រាន់តែជន់លិចចូលទៅក្នុងចរាចរណ៍ឋិតិវន្ត។
• ចាំបាច់ត្រូវប្រើសេវាកម្មការពារឯកទេស។ អ្នកមិនអាចការពារខ្លួនអ្នកពីការវាយប្រហារ L3&4 នៅកម្រិតឆានែលបានទេ ព្រោះអ្នកទំនងជាមិនមានឆានែលគ្រប់គ្រាន់ទេ។ អ្នកក៏ទំនងជាមិនទប់ទល់នឹងការវាយប្រហារ L7 ដែរ ព្រោះវាអាចមានទំហំធំណាស់។ លើសពីនេះ ការស្វែងរកការវាយប្រហារតូចៗនៅតែជាសិទ្ធិនៃសេវាកម្មពិសេស ក្បួនដោះស្រាយពិសេស។
• ធ្វើបច្ចុប្បន្នភាពជាទៀងទាត់។ វាមិនត្រឹមតែអនុវត្តចំពោះខឺណែលប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងចំពោះដេមិន SSH ផងដែរ ជាពិសេសប្រសិនបើអ្នកបើកពួកវាទៅខាងក្រៅ។ ជាគោលការណ៍ អ្វីគ្រប់យ៉ាងត្រូវតែធ្វើបច្ចុប្បន្នភាព ពីព្រោះអ្នកទំនងជាមិនអាចតាមដានភាពងាយរងគ្រោះមួយចំនួនដោយខ្លួនឯងបានទេ។

ប្រភព: www.habr.com