ការពន្យល់អំពីកំហុសហាមឃាត់ 403 និងវិធីជួសជុលវាឱ្យលឿន

អេក្រង់ហាមឃាត់ 403 បញ្ឈប់អ្នកប្រើប្រាស់ភ្លាមៗ។ វាក៏អាចបំបែក APIs រារាំងការចូល និងការពារ crawler ពីការទៅដល់ទំព័រសំខាន់ៗផងដែរ។

ការណែនាំនេះបង្ហាញអ្នកពីរបៀបកំណត់អត្តសញ្ញាណកន្លែងដែលការរារាំងកើតឡើង មូលហេតុដែលវាកើតឡើង និងការជួសជុលណាដែលអនុវត្តចំពោះការដំឡើងរបស់អ្នក។ សូមអនុវត្តតាមជំហានតាមលំដាប់លំដោយ ហើយជាធម្មតាអ្នកអាចកំណត់បាននូវច្បាប់ ឬការអនុញ្ញាតពិតប្រាកដដែលបង្កឱ្យមានការបដិសេធ។

ចម្លើយរហ័ស៖ សារហាមឃាត់ 403 មានន័យថាសំណើរបស់អ្នកបានទៅដល់គេហទំព័រ ប៉ុន្តែច្បាប់ចូលប្រើបានរារាំងវា។ ការរារាំងអាចមកពីការអនុញ្ញាត ច្បាប់ម៉ាស៊ីនមេ គោលការណ៍ CDN ឬ WAF កម្មវិធីជំនួយសុវត្ថិភាព ឬគោលការណ៍ចូលប្រើកន្លែងផ្ទុក។ ចាប់ផ្តើមដោយបញ្ជាក់ពីកន្លែងដែលការរារាំងកើតឡើង (គែមទល់នឹងប្រភពដើម) បន្ទាប់មកសាកល្បងអថេរមួយក្នុងពេលតែមួយរហូតដល់អ្នកកំណត់អត្តសញ្ញាណច្បាប់ពិតប្រាកដ។

អត្ថន័យពិតនៃកំហុសហាមឃាត់ 403

1. និយមន័យភាសាអង់គ្លេសសាមញ្ញ

កំហុសហាមឃាត់ 403 មានន័យថាម៉ាស៊ីនមេបានទទួលសំណើរបស់អ្នក យល់វា ហើយនៅតែបដិសេធមិនបម្រើធនធាន។ នោះត្រូវគ្នានឹងស្តង់ដារ HTTP៖ លេខកូដស្ថានភាព 403 (ហាមឃាត់) បង្ហាញថាម៉ាស៊ីនមេយល់ពីសំណើ ប៉ុន្តែបដិសេធមិនបំពេញវាដូច្នេះសំណើនេះបានឈានដល់អ្វីមួយដែលអាចនិយាយថា "ទេ"។

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

2. ៤០៣ ទល់នឹង ៤០១ ទល់នឹង ៤០៤ ទល់នឹង ៤២៩ (ភាពច្បាស់លាស់រហ័ស)

កូដស្ថានភាពទាំងនេះច្រើនតែមានការច្របូកច្របល់ ដូច្នេះសូមបញ្ជាក់វាឱ្យច្បាស់លាស់មុនពេលអ្នកបំបាត់កំហុស។

• 401 គ្មានការអនុញ្ញាត ជាធម្មតាមានន័យថាគេហទំព័ររំពឹងថានឹងមានការផ្ទៀងផ្ទាត់ ហើយអ្នកមិនបានផ្តល់ព័ត៌មានផ្ទៀងផ្ទាត់ដែលមានសុពលភាពទេ។
• ហាមឃាត់ 403 ជាធម្មតាមានន័យថា គេហទំព័របដិសេធការចូលប្រើ ទោះបីជាអ្នកត្រូវបានផ្ទៀងផ្ទាត់ក៏ដោយ ឬវារារាំងអ្នកដោយសារហេតុផលផ្អែកលើច្បាប់ (IP ទីតាំង បឋមកថា អត្រា ឬគោលការណ៍)។
• រកមិនឃើញ 404 មានន័យថា ម៉ាស៊ីនបម្រើនិយាយថា ធនធានមិនមានទេ (ឬវាជ្រើសរើសលាក់វា)។
• 429 សំណើច្រើនពេក មានន័យថា អ្នកបានឈានដល់ដែនកំណត់អត្រា ដែលអាចមើលទៅដូចជា "ការហាមឃាត់" ប៉ុន្តែដំណើរការខុសគ្នា។

នៅក្នុងការអនុវត្តជាក់ស្តែង CDN និង WAF ពេលខ្លះប្រគល់ 403 នៅពេលដែលពួកគេចង់លាក់មូលហេតុពិតប្រាកដ។ ដូច្នេះអ្នកត្រូវតែបញ្ជាក់ពីកន្លែងដែលការឆ្លើយតបមានប្រភព។

3. ហេតុអ្វីបានជាគេហទំព័រប្រើប្រាស់ 403 តាមគោលបំណង

មិនមែនរាល់ការឆ្លើយតបហាមឃាត់ 403 ទាំងអស់សុទ្ធតែបង្ហាញពីកំហុសនោះទេ។ ក្រុមជាច្រើនចេតនាបញ្ជូន 403 មកវិញដើម្បីការពារ៖

• ផ្លូវ​គ្រប់គ្រង (ដូចជា /wp-admin/) នៅពេលដែលអ្នកប្រើប្រាស់ខ្វះការអនុញ្ញាត
• ឯកសារខាងក្នុង ការបម្រុងទុក ឬថតឯកសារដែលលាក់
• ខ្លឹមសារ​ដែល​មាន​ការ​រឹតត្បិត​ពី​ប្រទេស ឬ​ទំព័រ​ដែល​មាន​ការ​រឹតត្បិត​ការ​អនុលោម
• API នៅពេលដែលថូខឹនខ្វះវិសាលភាព ហត្ថលេខាបរាជ័យ ឬគំរូសំណើបង្កឱ្យមានច្បាប់រំលោភបំពាន

ដូច្នេះការងាររបស់អ្នកគឺសាមញ្ញ៖ សម្រេចចិត្តថាតើប្លុកនេះត្រូវបានបម្រុងទុកឬអត់។ បន្ទាប់មករក្សាវាទុក កែតម្រូវវា ឬដកវាចេញ។

សារទូទៅដែលភ្ជាប់ទៅប្លុកហាមឃាត់ 403៖

• "អ្នកមិនមានសិទ្ធិចូលប្រើធនធាននេះទេ។"
• "ការចូលប្រើត្រូវបានបដិសេធ។"
• "ហាមឃាត់៖ អ្នកមិនមានសិទ្ធិមើលទំព័រនេះទេ។"
• "សំណើត្រូវបានរារាំងដោយច្បាប់សុវត្ថិភាព។"
• "បញ្ជី​ថត​ត្រូវ​បាន​បដិសេធ។"

ជង់ផ្សេងៗគ្នាបង្ហាញពាក្យពេចន៍ខុសៗគ្នា ប៉ុន្តែបញ្ហាឫសគល់នៅតែដដែល៖ ការសម្រេចចិត្តចូលប្រើបានរារាំងសំណើ។

ហេតុអ្វីបានជាកំហុសហាមឃាត់ 403 ជារឿងធម្មតាឥឡូវនេះ

1. កម្លាំងចរាចរណ៍ Bot រារាំងកាន់តែខ្លាំង

គេហទំព័រទំនើបៗប្រឈមមុខនឹងការស៊ើបអង្កេតដោយស្វ័យប្រវត្តិឥតឈប់ឈរ។ ការស្រាវជ្រាវថ្មីៗបានបង្ហាញពីភាពធ្ងន់ធ្ងរនៃរឿងនេះ៖ ៥១% នៃចរាចរណ៍គេហទំព័រទាំងអស់ នៅឆ្នាំ 2024 បានមកពីប្រភពស្វ័យប្រវត្តិ ដូច្នេះឥឡូវនេះ សំណុំសុវត្ថិភាពជាច្រើនរារាំងមុន ហើយសួរសំណួរនៅពេលក្រោយ។

និន្នាការដូចគ្នានោះរួមបញ្ចូលទាំងប្រព័ន្ធស្វ័យប្រវត្តិកម្មដែលមានគំនិតអាក្រក់។ របាយការណ៍ក៏បានកត់សម្គាល់ផងដែរថា 37% នៃចរាចរណ៍បានមកពី bots ព្យាបាទដែលជួយពន្យល់ពីមូលហេតុដែលប្រព័ន្ធវាយតម្លៃកេរ្តិ៍ឈ្មោះ IP និង bot បង្កឱ្យមានការឆ្លើយតបហាមឃាត់ចំនួន 403 ច្រើនជាងមុន។

2. កម្មវិធី និង API ស្ថិតនៅក្រោមការវាយប្រហារឥតឈប់ឈរ

ទោះបីជាអ្នកដំណើរការគេហទំព័រតូចមួយក៏ដោយ កញ្ចប់របស់អ្នកនៅតែត្រូវបានស្កេន។ ទូរមាត្រសហគ្រាសបង្ហាញពីមាត្រដ្ឋាន៖ Akamai បានរាយការណ៍ ការវាយប្រហារតាមអ៊ីនធឺណិតចំនួន ៣១១ ពាន់លានដងនៅឆ្នាំ ២០២៤ហើយសម្ពាធនោះហូរចុះទៅជាលំនាំដើមដ៏តឹងរ៉ឹងជាងមុនលើការបង្ហោះ CDN និងគោលការណ៍ WAF។

អ្វីដែលអាក្រក់ជាងនេះទៅទៀត ការវាយប្រហារនៅតែបន្តកើនឡើង។ ការស្រាវជ្រាវដូចគ្នានេះពិពណ៌នាអំពី កើនឡើង ៧៤% ពីមួយឆ្នាំទៅមួយឆ្នាំដែលជំរុញឱ្យក្រុមបន្ថែមច្បាប់បដិសេធបន្ថែមទៀត ដែលជារឿយៗប្រែទៅជាការឆ្លើយតប 403។

APIs ក៏ទាក់ទាញការរំលោភបំពានដែលផ្តោតសំខាន់ផងដែរ។ Akamai បានចងក្រងជាឯកសារ ការវាយប្រហារ API ចំនួន ១៥០ ពាន់លានដង ចាប់ពីខែមករា ឆ្នាំ២០២៣ ដល់ខែធ្នូ ឆ្នាំ២០២៤ហើយច្រកផ្លូវ API ជាច្រើនឆ្លើយតបនឹងចរាចរណ៍គួរឱ្យសង្ស័យជាមួយ 403 ជាជាងសារពិពណ៌នាបន្ថែម។

3. ការរំលោភបំពាន API ទទួលបានការយកចិត្តទុកដាក់ជាពិសេស

អ្នកវាយប្រហារច្រើនតែកំណត់គោលដៅលើតក្កវិជ្ជា API ពីព្រោះវានាំឱ្យមានការក្លែងបន្លំ និងការដណ្តើមយកគណនី។ ចំណុចទិន្នន័យថ្មីៗមួយបានបញ្ជាក់យ៉ាងច្បាស់ថា៖ 44% នៃ API កំណត់គោលដៅចរាចរណ៍ bot កម្រិតខ្ពស់ បង្ហាញពីមូលហេតុដែលអ្នកផ្តល់សេវាគែមឥឡូវនេះអនុវត្តច្បាប់មិនប្រក្រតីដ៏តឹងរ៉ឹងជាងមុន ជាពិសេសសម្រាប់ការចូល ការទូទាត់ប្រាក់ និងចំណុចបញ្ចប់ការស្វែងរក។

ជាលទ្ធផល វគ្គកម្មវិធីរុករក "ធម្មតា" អាចដំណើរការ ខណៈពេលដែលកម្មវិធីភ្ញៀវ API ឧបករណ៍គ្មានក្បាល ឬឧបករណ៍ crawler ត្រូវបានរារាំងជាមួយនឹងការឆ្លើយតបហាមឃាត់ 403។

ការធ្វើរោគវិនិច្ឆ័យរហ័ស៖ ស្វែងរកកន្លែងដែល 403 មកពីណា

មូលហេតុទូទៅបំផុតដែលត្រូវពិនិត្យជាមុនសិន៖

• ច្បាប់ CDN ឬ WAF រារាំង IP ប្រទេស ភ្នាក់ងារអ្នកប្រើប្រាស់ ឬគំរូសំណើរបស់អ្នក។
• ការ​ផ្លាស់ប្ដូរ​សិទ្ធិ​ឬ​ភាពជាម្ចាស់​រារាំង​អ្នកប្រើប្រាស់​ម៉ាស៊ីនបម្រើ​បណ្ដាញ​ពី​ការអាន​ផ្លូវ។
• ច្បាប់បដិសេធ Apache ឬ Nginx ត្រូវគ្នានឹង URL ថតឯកសារ ឬគំរូឯកសារ។
• កម្មវិធីជំនួយសុវត្ថិភាព WordPress ឬការកំណត់ hotlink រារាំងការចូលប្រើបន្ទាប់ពីការអាប់ដេត។
• គោលការណ៍ផ្ទុកទិន្នន័យលើពពកបដិសេធការអានជាសាធារណៈ ឬបដិសេធសំណើចំណុចបញ្ចប់គេហទំព័រ។

1. បញ្ជាក់ថាវាជា HTTP 403 ពិតប្រាកដ (មិនមែនជាការរារាំងក្នុងស្រុកទេ)

ចាប់ផ្តើមជាមួយនឹងការធ្វើតេស្តដែលស្អាត និងអាចធ្វើម្តងទៀតបាន។ ប្រើសំណើ HTTP ដោយផ្ទាល់ ដើម្បីឱ្យអ្នកអាចមើលឃើញបឋមកថា។

curl -i https://example.com/protected-path

បន្ទាប់មក ប្រៀបធៀបវាជាមួយនឹងសំណើ "ដូចកម្មវិធីរុករក"។ WAF មួយចំនួនរារាំងហត្ថលេខា curl លំនាំដើម។

curl -i -A "Mozilla/5.0" https://example.com/protected-path

ប្រសិនបើសំណើទីពីរទទួលបានជោគជ័យ អ្នកទំនងជាប្រឈមមុខនឹងច្បាប់ bot ច្បាប់ user-agent ឬទំព័របញ្ហាប្រឈមដែល curl មិនអាចដោះស្រាយបាន។

2. ពិនិត្យមើលថាតើប្លុកកើតឡើងនៅស្រទាប់ CDN/WAF ដែរឬទេ

ឥឡូវនេះ សូមក្រឡេកមើលបឋមកថាឆ្លើយតប។ អ្នកចង់ឆ្លើយសំណួរមួយ៖ តើម៉ាស៊ីនមេដើមបានបង្កើត 403 ឬអន្តរការីបង្កើតវា?

• ប្រសិនបើអ្នកឃើញបឋមកថាជាក់លាក់របស់អ្នកលក់ (លេខសម្គាល់ CDN, លេខសម្គាល់ដានគែម ឬលេខសម្គាល់ "ray") គែមនោះទំនងជាបានរារាំងអ្នក។
• ប្រសិនបើបឋមកថាមើលទៅដូចជាម៉ាស៊ីនមេដើមរបស់អ្នក (Apache, Nginx, IIS ឬក្របខ័ណ្ឌកម្មវិធីរបស់អ្នក) ប្រភពដើមទំនងជាបានរារាំងអ្នក។

ការត្រួតពិនិត្យតែមួយនេះការពារការខ្ជះខ្ជាយពេលវេលា។ វាក៏ប្រាប់អ្នកពីកន្លែងដែលត្រូវពិនិត្យមើលកំណត់ហេតុជាមុនសិនផងដែរ។

3. បង្កើតឡើងវិញជាមួយអថេរសាមញ្ញ (IP, ឃុកឃី, ផ្លូវ, វិធីសាស្ត្រ)

បញ្ហាហាមឃាត់ 403 ជារឿយៗអាស្រ័យលើ "រូបរាងរបស់អ្នក" ចំពោះម៉ាស៊ីនមេ។ ដូច្នេះ សូមផ្លាស់ប្តូរអថេរមួយក្នុងពេលតែមួយ។

• អាសយដ្ឋាន IP: សាកល្បងពីទិន្នន័យទូរសព្ទចល័ត វ៉ាយហ្វាយផ្សេង ឬ VPN (ប៉ុន្តែត្រូវចាំថា VPN អាចបង្កឱ្យមានការរារាំងផងដែរ)។
• ខូគី: សាកល្បងនៅក្នុងបង្អួចអនាមិក ឬសម្អាតខូគីគេហទំព័រ។
• ផ្លូវ URL៖ សាកល្បង​ទំព័រ​សាធារណៈ​ដែល​គេ​ស្គាល់​ធៀប​នឹង​ទំព័រ​ដែល​បរាជ័យ។
• វិធីសាស្ត្រ HTTP៖ API មួយចំនួនអនុញ្ញាតឱ្យ GET ប៉ុន្តែរារាំង POST ឬ PUT តាមគោលការណ៍។

ដរាបណាអ្នករកឃើញអថេរដែលបង្វែរលទ្ធផល អ្នកនឹងមានចំណុចសំខាន់មួយលើមូលហេតុចម្បង។

ប្រសិនបើអ្នកត្រូវការសួររកការគាំទ្រផ្នែកបង្ហោះ ឬផ្នែកសុវត្ថិភាព សូមផ្ញើព័ត៌មាននេះ៖

• URL ពិតប្រាកដដែលបរាជ័យ និង URL នៅលើគេហទំព័រតែមួយដែលដំណើរការ។
• ពេលវេលាដែលការប្លុកនេះបានកើតឡើង និងតំបន់ប្រហាក់ប្រហែលរបស់អ្នក។
• អាសយដ្ឋាន IP របស់អ្នក ប្រសិនបើអ្នកអាចចែករំលែកវាបាន បូករួមទាំងថាតើអ្នកបានប្រើ VPN ឬប្រូកស៊ីឬអត់។
• រូបថតអេក្រង់នៃទំព័រកំហុស និងលេខសម្គាល់សំណើណាមួយដែលបង្ហាញនៅលើទំព័រ។
• ថាតើបញ្ហានេះកើតឡើងចំពោះអ្នកប្រើប្រាស់ទាំងអស់ ឬកើតឡើងចំពោះតែឧបករណ៍ ឬបណ្តាញជាក់លាក់ប៉ុណ្ណោះ។

របៀបជួសជុលកំហុស 403 ហាមឃាត់នៅលើគេហទំព័ររបស់អ្នក (ជំហានរបស់ម្ចាស់/អ្នកអភិវឌ្ឍន៍)

1. ជួសជុលការអនុញ្ញាតឯកសារ និងថតឯកសារជាមុនសិន

នៅលើម៉ាស៊ីនមេ Linux ជាច្រើន បញ្ហាការអនុញ្ញាតបង្កឱ្យមានការឆ្លើយតបហាមឃាត់ 403 ពីព្រោះអ្នកប្រើប្រាស់ម៉ាស៊ីនមេគេហទំព័រមិនអាចអានឯកសារ ឬឆ្លងកាត់ថតឯកសារបានទេ។

ប្រើវិធីសាស្រ្តនេះ៖

• បញ្ជាក់អ្នកប្រើប្រាស់ម៉ាស៊ីនបម្រើគេហទំព័រ (ជាញឹកញាប់ www-data, apacheឬ nginx).
• ពិនិត្យមើលភាពជាម្ចាស់ និងការអនុញ្ញាតនៅលើផ្លូវពេញលេញ មិនមែនគ្រាន់តែឯកសារចុងក្រោយនោះទេ។
• សូមពិនិត្យមើលស្រទាប់សុវត្ថិភាពដូចជា SELinux ឬការអនុញ្ញាតកម្រិតសំឡេងកុងតឺន័រ ប្រសិនបើអ្នកប្រើវា។

ប្រសិនបើបញ្ហានេះបានចាប់ផ្តើមបន្ទាប់ពីការដាក់ពង្រាយ សូមផ្តោតលើអ្វីដែលបានផ្លាស់ប្តូរ៖ ថតឯកសារបង្កើតថ្មី តំណភ្ជាប់ស៊ីមថ្មី ឬអ្នកប្រើប្រាស់ថ្មីដែលជាម្ចាស់ឯកសារ។

2. ពិនិត្យមើលច្បាប់ Apache និងអន្ទាក់ .htaccess

Apache អាចប្រគល់ការឆ្លើយតបហាមឃាត់ 403 ដោយសារតែច្បាប់បដិសេធជាក់លាក់។ ក្រុមជាច្រើនភ្លេចច្បាប់បដិសេធចាស់ៗនៅក្នុងថតឯកសារដែលដាក់ក្នុងនោះ។

ជនល្មើសទូទៅពីរគឺ៖

• ការណែនាំអំពីការអនុញ្ញាត ដែលបដិសេធការចូលប្រើថតឯកសារ។
• សរសេរច្បាប់ឡើងវិញ ដែលបង្ខំឱ្យមានការឆ្លើយតបហាមឃាត់សម្រាប់លំនាំជាក់លាក់។

Apache ថែមទាំងបានចងក្រងឯកសារថា ទង់ [F] RewriteRule បណ្តាលឱ្យមានការឆ្លើយតបហាមឃាត់ 403ដូច្នេះសូមស្វែងរកការកំណត់រចនាសម្ព័ន្ធរបស់អ្នកសម្រាប់ [F] និងគំរូ "បដិសេធ" ណាមួយ។

សូមពិនិត្យមើលផងដែរចំពោះការរារាំងដោយចៃដន្យនៅលើថតឯកសារដែលលាក់ ផ្នែកបន្ថែមឯកសារ ឬភ្នាក់ងារអ្នកប្រើប្រាស់។ គំរូទាំងនោះច្រើនតែចាប់ផ្តើមជាការរឹងរូស "បណ្ដោះអាសន្ន" ហើយបន្ទាប់មកបំបែកចរាចរណ៍ពិតប្រាកដនៅពេលក្រោយ។

3. ពិនិត្យមើលលំនាំ "បដិសេធទាំងអស់" របស់ Nginx និងឯកសារលិបិក្រមដែលបាត់

ជាទូទៅ Nginx នឹងប្រគល់ 403 នៅពេលដែលវារារាំងការចុះបញ្ជីថត នៅពេលដែលវាបដិសេធគំរូទីតាំង ឬនៅពេលដែលវាមិនអាចបម្រើ សន្ទស្សន៍ ឯកសារសម្រាប់ផ្លូវថតឯកសារ។

ស្វែងរកលំនាំដូចជា៖

• deny all; នៅក្នុង location ប្លុក
• ប្លុក regex ដែលត្រូវគ្នានឹងថតឯកសារ dot
• បាត់មួយ index ការណែនាំសម្រាប់ផ្លូវដែលអ្នករំពឹងថានឹងបម្រើ

ប្រសិនបើ 403 កើតឡើងតែលើ "URL ថតឯកសារ" ដូចជា /docs/ ប៉ុន្តែមិននៅលើ /docs/page.htmlបន្ទាប់មកការកំណត់រចនាសម្ព័ន្ធលិបិក្រមក្លាយជាការសង្ស័យយ៉ាងខ្លាំង។

4. ជួសជុលប្លុក CDN/WAF (ភាគច្រើននៃ 403s "ភ្លាមៗ" រស់នៅទីនេះ)

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

មូលហេតុទូទៅនៃគែមរួមមាន៖

• ការការពារ Bot រារាំងកម្មវិធីដែលមិនមែនជាកម្មវិធីរុករកតាមអ៊ីនធឺណិត
• ច្បាប់ដែលគ្រប់គ្រងដោយ WAF រារាំង payload ដែលមើលទៅដូចជាការចាក់ SQL ឬ XSS
• ការរារាំងកេរ្តិ៍ឈ្មោះ IP ដែលប៉ះពាល់ដល់ ISP, VPN ឬតំបន់ទាំងមូល
• ដែនកំណត់អត្រាលើចំណុចបញ្ចប់នៃការចូល ការស្វែងរក ឬ API

ដើម្បីជួសជុលវាឲ្យបានរហ័ស សូមទាញយកសំណើដែលត្រូវបានរារាំងជាក់លាក់មួយពីកំណត់ហេតុគែមរបស់អ្នក ហើយកំណត់ថាតើច្បាប់មួយណាដែលដំណើរការ។ បន្ទាប់មកកែសម្រួលច្បាប់។ កុំបិទសុវត្ថិភាពទាំងស្រុងសម្រាប់គេហទំព័រទាំងមូល ប្រសិនបើមានចំណុចបញ្ចប់តែមួយខូច។

5. ជួសជុលការចាក់សោកម្មវិធីជំនួយសុវត្ថិភាព WordPress និង CMS

On CMS គេហទំព័រមួយចំនួន កំហុស 403 ដែលត្រូវបានហាមឃាត់ ជារឿយៗកើតចេញពីកម្មវិធីជំនួយសុវត្ថិភាព ការកំណត់ "ការការពារតំណភ្ជាប់ក្តៅ" ឬជញ្ជាំងភ្លើងបង្ហោះដែលស្ថិតនៅពីមុខ PHP។

សាកល្បងជំហានជាក់ស្តែងទាំងនេះ៖

• បិទកម្មវិធីជំនួយសុវត្ថិភាពជាបណ្ដោះអាសន្នដោយប្តូរឈ្មោះថតឯកសារកម្មវិធីជំនួយតាមរយៈ FTP ឬកម្មវិធីគ្រប់គ្រងឯកសារ។
• សូមពិនិត្យមើលការអាប់ដេតថ្មីៗដែលបានបន្ថែមច្បាប់កាន់តែតឹងរ៉ឹង។
• សូមបញ្ជាក់ថា ផ្លូវ​អ្នកគ្រប់គ្រង​របស់អ្នក​មិន​ត្រូវបាន​រឹតបន្តឹង​ដោយ IP ទេ លុះត្រាតែអ្នក​មានបំណង​ធ្វើដូច្នោះ។

នៅពេលដែលគេហទំព័រផ្ទុករួច សូមបើកការគ្រប់គ្រងឡើងវិញម្តងមួយៗ។ វិធីសាស្ត្រនេះផ្តល់ឱ្យអ្នកនូវដានមូលហេតុ និងផលប៉ះពាល់ដ៏ច្បាស់លាស់។

6. ជួសជុលករណី "AccessDenied" របស់ Amazon S3 និង Static Hosting

គេហទំព័រឋិតិវន្តខូចជាមួយនឹងកំហុសហាមឃាត់ 403 នៅពេលដែលគោលការណ៍ធុង ACL ឬការកំណត់ការចូលប្រើសាធារណៈមិនត្រូវគ្នានឹងចេតនារបស់អ្នក។

ប្រសិនបើអ្នកប្រើចំណុចបញ្ចប់គេហទំព័រ AWS នឹងកត់ត្រាឥរិយាបថសំខាន់មួយ៖ ប្រសិនបើវត្ថុមាន ប៉ុន្តែអ្នកមិនបានផ្តល់សិទ្ធិអានលើវាទេ ចំណុចបញ្ចប់គេហទំព័រនឹងប្រគល់លេខកូដឆ្លើយតប HTTP 403 (ការចូលប្រើត្រូវបានបដិសេធ)។ដូច្នេះអ្នកគួរតែពិនិត្យមើលការអនុញ្ញាត ទោះបីជាឯកសារ "មាន" ក៏ដោយ។

សូមប្រយ័ត្នចំពោះការការពារលំនាំដើមផងដែរ។ AWS ពន្យល់ថា ចាប់តាំងពីខែមេសា ឆ្នាំ២០២៣ ការកំណត់ Block Public Access ទាំងអស់ត្រូវបានបើកតាមលំនាំដើមសម្រាប់ធុងថ្មីដែលអាចធ្វើឱ្យក្រុមដែលរំពឹងថានឹងមានឥរិយាបថសាធារណៈបែបលំនាំដើមភ្ញាក់ផ្អើល។

នៅពេលអ្នកដោះស្រាយបញ្ហានេះ សូមសម្រេចចិត្តឱ្យច្បាស់ថាតើធុងគួរតែជាសាធារណៈ (កម្រ) ឬថាតើអ្នកគួររក្សាវាទុកជាឯកជន ហើយបម្រើខ្លឹមសារតាមរយៈស្រទាប់ដែលបានគ្រប់គ្រងដូចជា CDN ដែលមាន URL ដែលបានចុះហត្ថលេខា។

7. ជួសជុលវ៉ារ្យ៉ង់ 403 ជាក់លាក់ IIS (ជាពិសេសតម្រូវការ SSL)

នៅលើការបង្ហោះ Windows, IIS អាចផ្ញើការឆ្លើយតប 403 សម្រាប់ហេតុផលដែលមើលទៅមិនទាក់ទងគ្នានៅក្នុងកម្មវិធីរុករក។ ឧទាហរណ៍ ប្រសិនបើគេហទំព័ររបស់អ្នកតម្រូវឱ្យមាន HTTPS, Microsoft កត់សម្គាល់ថា។ ៤០៣.៤ | តម្រូវឲ្យមាន SSL ជាមូលហេតុជាក់លាក់មួយ ដូច្នេះសូមបញ្ជាក់ថាអ្នកមិនបានបង្ខំ SSL ដោយចៃដន្យលើការភ្ជាប់ដែលនៅតែទទួលបានចរាចរណ៍ HTTP នោះទេ។

នៅពេលអ្នកបំបាត់កំហុស IIS តែងតែពិនិត្យមើលស្ថានភាពរង និងកំណត់ហេតុម៉ាស៊ីនមេ។ ជាធម្មតាស្ថានភាពរងចង្អុលទៅការអនុញ្ញាតពិតប្រាកដ ឬការមិនត្រូវគ្នានៃមុខងារ។

របៀបជួសជុល 403 Forbidden ក្នុងនាមជាអ្នកទស្សនា (ដំណោះស្រាយរហ័ស)

1. បិទ VPN, ប្រូកស៊ី និងមុខងារ "ភាពឯកជន" របស់កម្មវិធីរុករកតាមអ៊ីនធឺណិត

គេហទំព័រជាច្រើនរារាំងជួរ IP ដែលបានចែករំលែក ដើម្បីបញ្ឈប់ការលួចយក និងការក្លែងបន្លំ។ ដូច្នេះប្រសិនបើអ្នកប្រើ VPN សូមផ្អាកវា ហើយសាកល្បងម្តងទៀត។ ប្រសិនបើគេហទំព័រផ្ទុកភ្លាមៗ កេរ្តិ៍ឈ្មោះ IP របស់អ្នកបានបង្កឱ្យមានការឆ្លើយតបហាមឃាត់ 403។

2. សម្អាតខូគីសម្រាប់គេហទំព័រនោះ ហើយព្យាយាមម្តងទៀត។

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

3. សាកល្បងបណ្តាញផ្សេងទៀត ហើយបន្ទាប់មកទាក់ទងគេហទំព័រ

ប្រសិនបើអ្នកនៅតែឃើញសារហាមឃាត់ 403 សូមប្តូរបណ្តាញ ហើយសាកល្បងម្តងទៀត។ ទិន្នន័យទូរសព្ទចល័តច្រើនតែមានឥរិយាបទខុសពីបណ្តាញសាជីវកម្ម។

ប្រសិនបើបញ្ហានៅតែបន្ត សូមទាក់ទងម្ចាស់គេហទំព័រជាមួយព័ត៌មានលម្អិត។ សូមរួមបញ្ចូល URL ត្រាពេលវេលា និងទីតាំងប្រហាក់ប្រហែលរបស់អ្នក។ ព័ត៌មាននោះជួយពួកគេស្វែងរកព្រឹត្តិការណ៍រារាំងនៅក្នុងកំណត់ហេតុបានយ៉ាងរហ័ស។

ផលប៉ះពាល់ SEO៖ នៅពេលដែលការហាមឃាត់ 403 ប៉ះពាល់ដល់ចំណាត់ថ្នាក់

1. យល់ពីអ្វីដែលម៉ាស៊ីនស្វែងរកធ្វើជាមួយកំហុសរបស់អតិថិជន

ការឆ្លើយតបហាមឃាត់ 403 ជាប់លាប់អាចបណ្តាលឱ្យបាត់បង់សន្ទស្សន៍ និងចរាចរណ៍ធ្លាក់ចុះ។ ឯកសាររបស់ Google ចែងថា បំពង់​ធ្វើ​លិបិក្រម​របស់ Google មិន​ពិចារណា URL ដែល​ត្រឡប់​កូដ​ស្ថានភាព 4xx សម្រាប់​ការ​ធ្វើ​លិបិក្រម​ទេ ហើយ URL ដែល​ត្រូវ​បាន​ធ្វើ​លិបិក្រម​រួច​ហើយ និង​ត្រឡប់​កូដ​ស្ថានភាព 4xx ត្រូវ​បាន​លុប​ចេញ​ពី​លិបិក្រម។ដូច្នេះអ្នកគួរតែចាត់ទុក 403s ដែលរីករាលដាលជាបន្ទាន់។

2. អន្ទាក់ SEO ទូទៅដែលបណ្តាលឱ្យមាន 403s ដោយចៃដន្យ

គំរូទាំងនេះច្រើនតែប៉ះពាល់ដល់ SEO ដោយក្រុមនានាមិនបានកត់សម្គាល់ភ្លាមៗទេ៖

• ការទប់ស្កាត់ "បូតមិនស្គាល់" និងការទប់ស្កាត់ Googlebot ឬ Bingbot ដោយចៃដន្យ
• ការរារាំងប្រទេសដែលក៏រារាំងកម្មវិធីរុករកតាមអ៊ីនធឺណិតនៅក្នុងទីផ្សារសំខាន់ៗផងដែរ
• ការរឹតបន្តឹងការរៀបចំត្រូវបានចម្លងទៅក្នុងការកំណត់រចនាសម្ព័ន្ធផលិតកម្មអំឡុងពេលចេញផ្សាយ
• ការកំណត់អត្រាដែលរារាំងឧបករណ៍វារក្នុងអំឡុងពេលវារច្រើន

ការរារាំងដោយចៃដន្យជាច្រើនកើតឡើងនៅពេលដែលក្រុម "រារាំងបូត" យ៉ាងខ្លាំងក្លាពេក ហើយចាប់បានសត្វវារពិតប្រាកដនៅក្នុងបណ្តាញ។

3. ប្រើគំរូដែលមានសុវត្ថិភាពជាងសម្រាប់ខ្លឹមសារដែលត្រូវបានការពារ

ប្រសិនបើអ្នកត្រូវការការពារខ្លឹមសារ សូមតម្រឹមវិធីសាស្ត្រនេះជាមួយនឹងគោលដៅរបស់អ្នក៖

• ប្រសិនបើអ្នកចង់ឱ្យខ្លឹមសារមានលក្ខណៈឯកជន សូមប្រើការផ្ទៀងផ្ទាត់ និងការអនុញ្ញាត មិនមែន "ប្លុកអាថ៌កំបាំង" ទេ។
• ប្រសិនបើអ្នកចង់ឱ្យខ្លឹមសារមានជាសាធារណៈ ប៉ុន្តែមិនត្រូវបានធ្វើលិបិក្រមទេ សូមប្រើការគ្រប់គ្រងការធ្វើលិបិក្រមជាក់លាក់ជាជាងពឹងផ្អែកលើឥរិយាបថ 403។
• ប្រសិនបើអ្នកត្រូវការទប់ស្កាត់ស្វ័យប្រវត្តិកម្មដែលរំលោភបំពាន សូមកែសម្រួលច្បាប់ bot ដើម្បីឱ្យអ្នកប្រើប្រាស់ពិតប្រាកដ និង crawler ដែលបានផ្ទៀងផ្ទាត់នៅតែអាចឆ្លងកាត់បាន។

វិធីសាស្រ្តនេះរក្សាឥរិយាបថសុវត្ថិភាពរបស់អ្នកឱ្យរឹងមាំ ខណៈពេលដែលកាត់បន្ថយការខូចខាតចរាចរណ៍សរីរាង្គដោយចៃដន្យ។

ការពារការហាមឃាត់ 403 ពីការត្រឡប់មកវិញ

1. ត្រួតពិនិត្យសម្រាប់ការកើនឡើងភ្លាមៗ

បន្ថែមការជូនដំណឹងសម្រាប់ការកើនឡើងយ៉ាងខ្លាំងនៃការឆ្លើយតបហាមឃាត់ចំនួន 403។ ការកើនឡើងខ្ពស់ជារឿយៗមានន័យថាច្បាប់ WAF ថ្មី ការដាក់ពង្រាយដែលខូច ឬការតំរែតំរង់ការអនុញ្ញាត។

តាមដានតាមចំណុចបញ្ចប់ ប្រទេស និងប្រភេទភ្នាក់ងារអ្នកប្រើប្រាស់ ដូច្នេះអ្នកអាចសម្គាល់ "មានតែការចូលដែលខូច" ធៀបនឹង "គេហទំព័រទាំងមូលខូច"។

2. កត់ត្រាបរិបទត្រឹមត្រូវ (ដូច្នេះអ្នកអាចបំបាត់កំហុសក្នុងរយៈពេលប៉ុន្មាននាទី)

នៅពេលអ្នកកត់ត្រាសំណើ សូមចាប់យកព័ត៌មានលម្អិតគ្រប់គ្រាន់ដើម្បីពន្យល់ពី "មូលហេតុ" នៃការរារាំងមួយបានកើតឡើង៖

• លេខសម្គាល់សំណើ និងលេខសម្គាល់ទំនាក់ទំនង
• អាសយដ្ឋាន IP របស់អតិថិជន (និងបឋមកថា IP ដែលបានបញ្ជូនបន្ត ប្រសិនបើអ្នកប្រើប្រូកស៊ី)
• ភ្នាក់ងារអ្នកប្រើប្រាស់ និងផ្លូវសំណើ
• លេខសម្គាល់ច្បាប់ WAF ឬការសម្រេចចិត្តគោលនយោបាយនៅពេលដែលអាចអនុវត្តបាន

ទិន្នន័យនេះប្រែក្លាយពាក្យបណ្តឹងមិនច្បាស់លាស់ទៅជាព្រឹត្តិការណ៍ដែលអាចស្វែងរកបាន។

3. ពិនិត្យមើលច្បាប់បដិសេធដូចជាកូដ

ច្បាប់ចូលប្រើសមនឹងទទួលបានការគ្រប់គ្រងការផ្លាស់ប្តូរ។ ចាត់ទុកពួកវាដូចជាកូដ៖

• កត់ត្រា​មូលហេតុ​ដែល​អ្នក​បាន​បន្ថែម​ច្បាប់។
• កំណត់ម្ចាស់សម្រាប់ច្បាប់។
• ពិនិត្យ និងលុបច្បាប់ដែលលែងត្រូវគ្នានឹងការគំរាមកំហែងបច្ចុប្បន្ន។

ទម្លាប់នេះកាត់បន្ថយ “ភាពរសាត់នៃសុវត្ថិភាព” ដែលជាកត្តាជំរុញដ៏ធំបំផុតមួយនៃបញ្ហាហាមឃាត់ 403 ដែលមានអាយុកាលយូរអង្វែង។

សំណួរដែលសួរញឹកញាប់លើកំហុសហាមឃាត់ 403

ហេតុអ្វីបានជាខ្ញុំឃើញកំហុសហាមឃាត់ 403 នៅលើបណ្តាញមួយ ប៉ុន្តែមិនមែននៅលើបណ្តាញផ្សេងទៀត? ស្រទាប់សុវត្ថិភាពជារឿយៗត្រូវបានរារាំងដោយកេរ្តិ៍ឈ្មោះ IP តំបន់ ឬជួរ VPN ដែលបានចែករំលែក។ សាកល្បងលើទិន្នន័យចល័ត និងបណ្តាញផ្ទះធម្មតា ដើម្បីបញ្ជាក់គំរូ។

តើកម្មវិធីជំនួយសុវត្ថិភាពអាចបណ្តាលឱ្យមានកំហុសនេះបានទេ? បាទ/ចាស៎។ កម្មវិធីជំនួយសុវត្ថិភាព និងជញ្ជាំងភ្លើងសម្រាប់បង្ហោះអាចរារាំងផ្លូវអ្នកគ្រប់គ្រង ចំណុចបញ្ចប់ XML-RPC REST ឬការប៉ុនប៉ងចូលបន្ទាប់ពីការធ្វើបច្ចុប្បន្នភាពច្បាប់។

តើនេះតែងតែជាបញ្ហាសិទ្ធិទេ? ទេ។ ការអនុញ្ញាតបង្កឲ្យមានករណីជាច្រើន ប៉ុន្តែការរារាំងគែម និងច្បាប់បដិសេធបង្កឲ្យមានករណី "ភ្លាមៗ" ជាច្រើន ជាពិសេសបន្ទាប់ពីការផ្លាស់ប្តូរច្បាប់សុវត្ថិភាព។

តើនេះនឹងធ្វើឱ្យប៉ះពាល់ដល់ SEO ដែរឬទេ? វាអាចធ្វើទៅបាន ប្រសិនបើ crawler ចូលទៅកាន់ទំព័រដែលត្រូវបានរារាំងម្តងហើយម្តងទៀត។ ចាត់ទុកការរារាំងយ៉ាងទូលំទូលាយថាជាការបន្ទាន់ និងផ្ទៀងផ្ទាត់ការចូលប្រើ crawler លើ URL សំខាន់ៗ។

ក្នុងនាមជាម្ចាស់គេហទំព័រ តើខ្ញុំគួរជួសជុលអ្វីមុនគេ? ចាប់ផ្តើមដោយកំណត់ថាតើប្លុកនោះមកពី CDN/WAF ឬម៉ាស៊ីនមេដើម។ ជំហានតែមួយនោះការពារការខ្ជះខ្ជាយពេលវេលា។

ស្វែងយល់ពីសេវាកម្មរបស់យើង។

ប្រើប្រាស់ជំនាញ Cloud Computing ដ៏រឹងមាំរបស់ 1Byte ដើម្បីជំរុញអាជីវកម្មរបស់អ្នកតាមរបៀបដ៏ធំមួយ

Domains

1Byte ផ្តល់ពេញលេញ domain សេវាកម្មចុះឈ្មោះដែលរួមមានបុគ្គលិកគាំទ្រដោយយកចិត្តទុកដាក់ ការថែទាំអតិថិជនដែលមានការអប់រំ ការចំណាយសមរម្យ ក៏ដូចជា ក domain ឧបករណ៍ស្វែងរកតម្លៃ។

ឈ្មោះដែន

វិញ្ញាបនបត្រ SSL

បង្កើនសុវត្ថិភាពលើអ៊ីនធឺណិតរបស់អ្នកជាមួយនឹងសេវាកម្ម SSL របស់ 1Byte ។ ការការពារដែលមិនអាចប្រៀបផ្ទឹមបាន ការរួមបញ្ចូលដោយគ្មានថ្នេរ និងសន្តិភាពនៃចិត្តសម្រាប់ដំណើរឌីជីថលរបស់អ្នក។

វិញ្ញាបនបត្រ SSL

Cloud Server

មិនថា cloud server កញ្ចប់ដែលអ្នកជ្រើសរើស អ្នកអាចពឹងផ្អែកលើ 1Byte សម្រាប់ភាពជឿជាក់ ភាពឯកជន សុវត្ថិភាព និងបទពិសោធន៍គ្មានភាពតានតឹង ដែលមានសារៈសំខាន់សម្រាប់អាជីវកម្មជោគជ័យ។

សេវាកម្ម Cloud Server

Shared Hosting

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

បង្ហោះចែករំលែក

Cloud Hosting

តាមរយៈកម្មវិធីដែលមានភាពបត់បែនខ្ពស់ 1Byte ដ៏ទំនើប cloud hosting ផ្តល់ដំណោះស្រាយដ៏អស្ចារ្យដល់អាជីវកម្មខ្នាតតូច និងមធ្យមលឿនជាងមុន សុវត្ថិភាពជាងមុន និងក្នុងតម្លៃកាត់បន្ថយ។

សេវាកម្ម Cloud Hosting

WordPress Hosting

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

WordPress Hosting

ភាពជាដៃគូ AWS

ក្នុងនាមជាដៃគូ AWS ផ្លូវការ ទំនួលខុសត្រូវចម្បងមួយរបស់យើងគឺជួយអាជីវកម្មក្នុងការធ្វើទំនើបកម្មប្រតិបត្តិការរបស់ពួកគេ និងប្រើប្រាស់ច្រើនបំផុតក្នុងការធ្វើដំណើររបស់ពួកគេទៅកាន់ពពកជាមួយ AWS ។

សេវាកម្ម AWS

សន្និដ្ឋាន

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