របៀបការពារ VPS ពីការវាយប្រហារ DDoS

ការវាយប្រហារបដិសេធសេវាបែបចែកចាយ (DDoS) បញ្ជូនចរាចរណ៍ច្រើនលើសលប់ទៅកាន់ម៉ាស៊ីនមេ ឬខ្សែបណ្ដាញរបស់វា រហូតដល់អ្នកប្រើប្រាស់ពិតប្រាកដមិនអាចចូលបាន។ ការវាយប្រហារខ្លះមានទំហំធំពេកសម្រាប់ម៉ាស៊ីនមេខ្លួនឯងដោះស្រាយ ដូច្នេះការការពារមានប្រសិទ្ធភាពបំផុតនៅជាស្រទាប់ៗ៖ ត្រងនៅគែមបណ្ដាញជាមុនសិន បន្ទាប់មកកំណត់ Firewall និងការកំណត់កម្មវិធីនៅលើ VPS។ ONIE ការពារម៉ាស៊ីនមេ Cloud នៅទីក្រុងហូជីមិញ ដោយ DDoS Shieldនៅគែមបណ្ដាញ ដោយមិនគិតថ្លៃបន្ថែម ហើយអ្នកអាចដាក់ដំណើរការ VPS ដែលមានការការពារ DDoSក្នុងរយៈពេលពីរបីនាទី។

ប្រភេទនៃការវាយប្រហារ

• Volumetric (layer 3 និង 4): ការបញ្ជូនការវេចខ្ចប់ទិន្នន័យច្រើនលើសលប់ដែលបំពេញខ្សែបណ្ដាញ ឧទាហរណ៍ UDP flood។
• ការវាយប្រហារលើ Protocol: ការរំលោភលើដំណើរការភ្ជាប់ ដូចជា SYN flood ដែលបំពេញតារាងការភ្ជាប់។
• ការវាយប្រហារកម្រិត Application (layer 7): ការស្នើសុំ HTTP ជាច្រើនដែលមើលទៅត្រឹមត្រូវ ដែលធ្វើឲ្យម៉ាស៊ីនមេវែបឬមូលដ្ឋានទិន្នន័យអស់កម្លាំង។

ប្រភេទនីមួយៗត្រូវការការការពារផ្សេងគ្នា។ ចរាចរណ៍បែប Volumetric ត្រូវតែបញ្ឈប់មុនដល់ម៉ាស៊ីនមេរបស់អ្នក ហើយការវាយប្រហារ Application អាចត្រូវបានកាត់បន្ថយនៅលើម៉ាស៊ីនមេ។

1. ត្រងនៅគែមបណ្ដាញ

ការត្រងនៅគែមបណ្ដាញទម្លាក់ចរាចរណ៍អាក្រក់មុនដល់ VPS របស់អ្នក ដូច្នេះខ្សែបណ្ដាញមិនត្រូវបានបំពេញ។ ជាមួយ DDoS Shield ការត្រងដំណើរការនៅគែមបណ្ដាញដោយប្រើ XDP/eBPF ហើយ console បង្ហាញចរាចរណ៍ និងព្រឹត្តិការណ៍វាយប្រហារសម្រាប់ IP នីមួយៗ។ សូមសួរអ្នកផ្ដល់សេវាណាមួយដែលអ្នកពិចារណាថា មានអ្វីខ្លះបញ្ចូលក្នុងសេវា ការត្រងកើតឡើងនៅកន្លែងណា និងថាតើត្រូវបង់ថ្លៃបន្ថែមឬទេ។

2. បិទអ្វីដែលអ្នកមិនប្រើ

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

កុំបើកមូលដ្ឋានទិន្នន័យ ឬផ្ទាំងគ្រប់គ្រងឲ្យអ៊ីនធឺណិតចូលដំណើរការបាន។ ចងវាទៅ 127.0.0.1 ឬបណ្ដាញឯកជន។

3. កែតម្រូវ Kernel សម្រាប់ SYN flood

SYN cookies ត្រូវបានបើកតាមលំនាំដើមនៅក្នុង distribution ភាគច្រើន។ ពិនិត្យដោយ:

sysctl net.ipv4.tcp_syncookies

កុំផ្លាស់ប្ដូរ kernel ច្រើនពេក ហើយត្រូវសាកល្បងមុនពេលប្រើ ព្រោះតម្លៃខុសអាចប៉ះពាល់ដល់ចរាចរណ៍ធម្មតា។

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។ បម្រើឯកសារ static ពី cache ហើយប្រើ caching plugin នៅលើ WordPress ដើម្បីកាត់បន្ថយការចំណាយនៃស្នើសុំនីមួយៗ។ សូមមើលការដំឡើង WordPress ជាមួយ Nginx។

5. តាមដានចរាចរណ៍

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

ការកើនឡើងភ្លាមៗនៃការភ្ជាប់ ឬបញ្ជូនទិន្នន័យ ឬម៉ាស៊ីនមេដែលយឺតទោះបីប្រើ CPU តិច អាចជាសញ្ញានៃការវាយប្រហារ។ កំណត់ការជូនដំណឹង ដើម្បីឲ្យអ្នកដឹងឆាប់។

6. បញ្ជីពិនិត្យឧប្បត្តិហេតុ

1. បញ្ជាក់នៅក្នុង console ថាតើចរាចរណ៍ជាការវាយប្រហារ ឬការកើនឡើងពិតប្រាកដ។
2. ពិនិត្យព្រឹត្តិការណ៍វាយប្រហារ និង IP ដែលត្រូវបានវាយប្រហារ។
3. ទប់ស្កាត់អាសយដ្ឋានប្រភពដែលមានឥរិយាបថមិនល្អ ឬជួរដែលអ្នកអាចកំណត់អត្តសញ្ញាណបាន។
4. បើកការកំណត់អត្រាស្នើសុំឲ្យតឹងរ៉ឹងជាងមុន ឬបង្ហាញទំព័រថែទាំ។
5. ទាក់ទងផ្នែកជំនួយរបស់អ្នកផ្ដល់សេវា ជាមួយពេលវេលា និង IP។
6. បន្ទាប់ពីនោះ ពិនិត្យ logs និងធ្វើបច្ចុប្បន្នភាពផែនការនេះ។ រក្សាការបម្រុងទុក និង snapshotឲ្យទាន់សម័យ។