സെർവർ ഫയർവാൾ സെറ്റപ്പ്: DDoS-നും ബോട്ടുകൾക്കുമെതിരെ സെർവർ സുരക്ഷ ഉറപ്പാക്കാം

സെർവർ ഫയർവാൾ ക്രമീകരണം എന്നാൽ സെർവറിൽ ആവശ്യമായ പോർട്ടുകൾ മാത്രം തുറന്ന് ബാക്കിയുള്ള അനാവശ്യ ആക്സസുകൾ തടയുന്ന നടപടിയാണ്; ഇത് DDoS, ബ്രൂട്ട് ഫോഴ്സ്, ഹാനികരമായ ബോട്ട് ട്രാഫിക്കുകളെ തടയുന്ന ആദ്യ സുരക്ഷാ തലമായി പ്രവർത്തിക്കുന്നു. പ്രായോഗികമായി ലക്ഷ്യം SSH ആക്സസ് നിയന്ത്രിക്കുക, വെബ് സർവീസുകൾ നിയന്ത്രിതമായി തുറക്കുക, സംശയാസ്പദ അഭ്യർത്ഥനകളെ നിരക്ക് നിയന്ത്രണത്തിലാക്കുക, ലോഗുകൾ നിരീക്ഷിക്കുക, കൂടാതെ സാധ്യമെങ്കിൽ CDN/WAF പോലുള്ള ഉയർന്ന തലത്തിലുള്ള സുരക്ഷാ സംവിധാനങ്ങളിലൂടെ ട്രാഫിക് സെർവറിലേക്ക് എത്തുന്നതിനു മുമ്പ് ഫിൽട്ടർ ചെയ്യുക എന്നതാണ്.

ഒരു വെബ് സെർവർ ഇന്റർനെറ്റിൽ തുറക്കുന്നതും തന്നെ മിനിറ്റുകൾക്കുള്ളിൽ പോർട്ട് സ്‌കാനിംഗുകൾ, SSH ശ്രമങ്ങൾ, സെക്യൂരിറ്റി ബോട്ടുകൾ, വ്യാജ യൂസർ ഏജന്റുകൾ എന്നിവ നേരിടേണ്ടി വരും. പ്രത്യേകിച്ച് WordPress, ഇ-കൊമേഴ്‌സ്, പാനൽ, API അല്ലെങ്കിൽ ഗെയിം സെർവർ ഉപയോഗിക്കുന്ന സാഹചര്യങ്ങളിൽ ഫയർവാൾ സാങ്കേതികമാത്രമല്ല, സ്ഥിരതയ്ക്കുള്ള നിർബന്ധവുമാണ്. ഈ ഗൈഡിൽ ലിനക്സ് സെർവറുകളിൽ പ്രായോഗികമായി നടപ്പാക്കാവുന്ന, ഘട്ടം ഘട്ടമായ ഒരു ഫയർവാൾ ആർക്കിടെക്ചർ കാണിക്കും; UFW, firewalld, nftables, Fail2ban, വെബ് ആപ്ലിക്കേഷൻ ഫയർവാൾ, DDoS കുറയ്ക്കൽ എന്നിവ ഉൾപ്പെടുത്തി വിശദീകരിക്കും.

ഒരു പ്രധാന സത്യം മനസ്സിലാക്കാം: സെർവറിന്റെ പ്രാദേശിക ഫയർവാൾ മാത്രം വലിയ തോതിലുള്ള DDoS ആക്രമണങ്ങൾ തടയാൻ പാടില്ല. 20 Gbps, 80 Gbps അല്ലെങ്കിൽ അതിലധികമുള്ള ആക്രമണം ഡാറ്റ സെന്ററിലോ നെറ്റ്‌വർക്ക് ബാക്ക്ബോണിലോ എത്തുമ്പോൾ, പാക്കറ്റുകൾ നിങ്ങളുടെ ഓപ്പറേറ്റിങ് സിസ്റ്റത്തിലെ നിയമങ്ങളിലേയ്ക്ക് എത്തുന്നതിനു മുൻപേ ബാൻഡ്‌വിഡ്ത്ത് നിറക്കാനാകും. അതുകൊണ്ട് സുരക്ഷയുടെ ശരിയായ സമീപനം പല തലങ്ങളിലും ഉള്ള സംരക്ഷണമാണ്: സേവനദാതാവ് തലത്തിലുള്ള DDoS സംരക്ഷണം, CDN/WAF, ഓപ്പറേറ്റിങ് സിസ്റ്റം ഫയർവാൾ, ആപ്ലിക്കേഷൻ നിരക്ക് നിയന്ത്രണം, പതിവ് ലോഗ് വിശകലനം എന്നിവ ചേർന്ന് പ്രവർത്തിക്കണം. അനുയോജ്യമായ ഇന്‍ഫ്രാസ്ട്രക്ചർ തിരഞ്ഞെടുക്കാൻ Hostragons VPS ആൻഡ് VDS സർവർ പരിഹാരങ്ങൾ പേജ് സന്ദർശിക്കാം, വെബ് സൈറ്റ് സുരക്ഷിത ഹോസ്റ്റിങ്ങിനായി Hostragons വെബ് ഹോസ്റ്റിംഗ് പാക്കേജുകൾ പേജും പ്രയോജനം ചെയ്യും.

സെർവർ ഫയർവാൾ എന്തിന്?

സെർവർ ഫയർവാൾ നെറ്റ്‌വർക്ക് ട്രാഫിക് സ്രോതസ്സ് IP, ലക്ഷ്യ IP, പോർട്ട്, പ്രോട്ടോക്കോൾ, കണക്ഷൻ നില, ചിലപ്പോൾ പാക്കറ്റ് സവിശേഷതകൾ എന്നിവ അനുസരിച്ച് ഫിൽട്ടർ ചെയ്യുന്ന സുരക്ഷാ ഘടകമാണ്. ഉദാഹരണത്തിന്, നിങ്ങളുടെ വെബ്‌സൈറ്റിനായി 80, 443 പോർട്ടുകൾ തുറന്നിരിക്കണം, എന്നാൽ ഡാറ്റാബേസ് പോർട്ട് ആയ 3306 പൊതു ഇന്റർനെറ്റിൽ തുറക്കരുത്. SSH (22 പോർട്ട്) എല്ലാവർക്കും തുറക്കാൻ അനുവദിക്കുന്നതിന് പകരം, നിങ്ങളുടെ ഓഫീസ് IP മുതൽ മാത്രം കണക്ഷൻ അനുവദിക്കുന്നത് സുരക്ഷിതമാണ്.

ഫയർവാളിന്റെ പ്രധാന ലക്ഷ്യം എല്ലാ ആക്രമണങ്ങളും മായ്ക്കുക എന്നതല്ല. പ്രധാന ഉദ്ദേശം ആക്രമണ സാധ്യതകൾ കുറയ്ക്കുകയാണ്. ആക്രമണ സാധ്യതകൾ കുറവായാൽ ആക്രമികൾ പരീക്ഷിക്കേണ്ട ഓപ്ഷനുകൾ കുറയും. ഉദാഹരണത്തിന്, പുതിയ ലിനക്സ് സെർവറിൽ SSH, വെബ് പാനൽ, മെയിൽ, ഡാറ്റാബേസ്, മോണിറ്ററിംഗ് ഏജന്റ്, ടെസ്റ്റ് സർവീസുകൾ ഒരേ സമയം തുറന്നു നിന്നാൽ ഓരോതും അപകടകരമാണ്. നല്ല ഫയർവാൾ ക്രമീകരണം “ഡിഫോൾട്ട് നിരാകരിക്കുക, ആവശ്യമുള്ളത് അനുവദിക്കുക” എന്ന തത്വം പാലിക്കുന്നു.

DDoS-യും ബോട്ട് ട്രാഫിക്കും എന്താണ്?

DDoS ആക്രമണങ്ങൾ എന്തുകൊണ്ട് വ്യത്യസ്തമാണ്?

DDoS, അഥവാ ഡിസ്‌ട്രിബ്യൂട്ടഡ് ഡിനയൽ ഓഫ് സർവീസ്, നിരവധി സ്രോതസ്സുകളിൽ നിന്ന് വരുന്ന ട്രാഫിക് വ്യാപകമായി ലക്ഷ്യ സേവനം ഉപയോഗയോഗ്യമാക്കാതാക്കാൻ ശ്രമിക്കുന്നു. ചിലപ്പോൾ ഇത് ബാൻഡ്‌വിഡ്ത്ത് നിറക്കുന്നു, ചിലപ്പോൾ സെർവറിന്റെ CPU, റാം ഉപയോഗം വർദ്ധിപ്പിക്കുന്നു, ചിലപ്പോൾ ആപ്ലിക്കേഷൻ തലത്തിലെ വിലയേറിയ പ്രവർത്തനങ്ങൾ സൃഷ്ടിക്കുന്നു. ഉദാഹരണത്തിന്, സെക്കൻഡിൽ 50,000 HTTP അഭ്യർത്ഥനകൾ സ്വീകരിക്കുന്ന ചെറിയ ആപ്ലിക്കേഷൻ സെർവർ, നെറ്റ്‌വർക്ക് ബാൻഡ്‌വിഡ്ത്ത് നിറഞ്ഞിട്ടില്ലെങ്കിലും PHP-FPM, Node.js, ഡാറ്റാബേസ് കണക്ഷൻ പൂൾ എന്നിവ കാരണം പ്രതികരിക്കാൻ കഴിയാതാകാം.

ബോട്ടുകൾ എല്ലാമും ദുഷിതമാണോ?

അല്ല. Googlebot, Bingbot, ചില നിരീക്ഷണ ബോട്ടുകൾ ഉപകാരപ്രദമാണ്. എന്നാൽ ദുഷിത ബോട്ടുകൾ അഡ്മിൻ പാനൽ സ്‌കാനിംഗ്, ഓപ്പൺ ഡയറക്ടറി തിരയൽ, ഫോർം സ്‌പാം, ഉള്ളടക്കം പകർത്തൽ, XML-RPC ദുർവിനിയോഗം, വ്യാജ രജിസ്ട്രേഷൻ, ലോഗിൻ ശ്രമങ്ങൾ തുടങ്ങിയ പ്രവർത്തനങ്ങൾ നടത്തുന്നു. അതിനാൽ ബോട്ട് മാനേജ്മെന്റിൽ എല്ലാ ബോട്ടുകളും തടയൽ ലക്ഷ്യം അല്ല, പെരുമാറ്റം അനുസരിച്ച് വേർതിരിക്കലാണ്. ഉയർന്ന പിഴവ് നിരക്ക്, ചെറുതായി വളരെ അഭ്യർത്ഥനകൾ, യഥാർത്ഥ ബ്രൗസറിനെ പകർത്താത്ത ഹെഡറുകൾ, സംശയാസ്പദ URL മാതൃകകൾ പ്രധാന സൂചനകളാണ്.

സെറ്റപ്പ് ആരംഭിക്കുന്നതിന് മുൻപ് പരിശോധനാ ലിസ്റ്റ്

ലൈവ് സെർവറിൽ ഫയർവാൾ നിയമങ്ങൾ എഴുതുമ്പോൾ ഏറ്റവും വലിയ അപകടം, നിങ്ങളുടെ തന്നെ സെർവറിൽ നിന്ന് പുറത്താക്കപ്പെടുക എന്നതാണ്. അതിനാൽ മാറ്റങ്ങൾ വരുത്തുന്നതിനു മുൻപ് ചെറിയ തയ്യാറെടുപ്പ് നിർബന്ധമാണ്. താഴെ കാണുന്ന പരിശോധനാ ലിസ്റ്റ് പ്രൊഡക്ഷൻ പരിസ്ഥിതികളിൽ സാധാരണ ഉപയോഗിക്കുന്ന സുരക്ഷിത തുടക്കമാണ്.

• സജീവമായ SSH സെഷൻ അടയ്ക്കരുത്; രണ്ടാമത്തെ ടെർമിനലിൽ പരീക്ഷണം ചെയ്യുക.
• സെർവർ പ്രൊവൈഡർ കോൺസോൾ, VNC അല്ലെങ്കിൽ റിക്കവറി ആക്സസ് നൽകുന്നതായി ഉറപ്പാക്കുക.
• നിലവിലെ തുറന്ന പോർട്ടുകൾ പരിശോധിക്കുക: ss -tulpn അല്ലെങ്കിൽ netstat -tulpn കമാൻഡ് ഉപയോഗിക്കുക.
• വെബ്, മെയിൽ, DNS, ഡാറ്റാബേസ്, പാനൽ, മോണിറ്ററിംഗ് സർവീസുകൾ ഉപയോഗിക്കുന്ന പോർട്ടുകൾ രേഖപ്പെടുത്തുക.
• IPv6 ഉപയോഗിക്കുന്നുവെങ്കിൽ IPv6 ഫയർവാൾ നിയമങ്ങളും ആസൂത്രണം ചെയ്യുക.
• ആദ്യം allow (അനുമതി) നിയമങ്ങൾ, പിന്നീട് deny (തടയൽ) നിയമങ്ങൾ നടപ്പിലാക്കുക.
• നിയമങ്ങൾ സ്ഥിരതയുള്ളതാണെന്ന് ഉറപ്പാക്കുക; സെർവർ റീബൂട്ട് ചെയ്താലും നിലനിൽക്കണം.

ഉദാഹരണത്തിന് വെബ്‌സൈറ്റ് മാത്രമുള്ള സാധാരണ സെർവറിൽ പൊതുവെ തുറന്നിരിക്കേണ്ട പോർട്ടുകൾ 80, 443, കുറച്ച് SSH പോർട്ടുകളാണ്. മെയിൽ സെർവർ പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ 25, 465, 587, 993 പോർട്ടുകൾ തുറക്കേണ്ടതില്ല. ഡാറ്റാബേസ് ഒരു സെർവർക്കുള്ളിൽ മാത്രമേ ഉപയോഗിക്കുകയുള്ളൂ എങ്കിൽ 3306, 5432 പോർട്ടുകൾ പുറം ലോകത്ത് അടച്ചിരിക്കണം.

ഏത് ഫയർവാൾ ടൂൾ തിരഞ്ഞെടുക്കണം?

ലിനക്സ് ലോകത്ത് നിരവധി ടൂളുകൾ ഉണ്ട്, മിക്കതും സമാനമായ കേർണൽ ഫിൽട്ടറിംഗ് അടിസ്ഥാനത്തിൽ പ്രവർത്തിക്കുന്നു, എന്നാൽ ഉപയോഗത്തിൽ വ്യത്യാസമുണ്ട്. തുടക്കക്കാർക്ക് UFW ലളിതവും വേഗവുമാണ്. കോർപ്പറേറ്റ് അല്ലെങ്കിൽ Red Hat അടിസ്ഥാന സിസ്റ്റങ്ങൾക്കായി firewalld സാധാരണമാണ്. കൂടുതൽ പ്രഗത്ഭമായ സാഹചര്യങ്ങളിൽ nftables ആധുനികവും ലവചനീയവുമാണ്. താഴെ ടേബിൾ തിരഞ്ഞെടുപ്പ് സുഗമമാക്കും.

ഘട്ടം ഘട്ടമായ സെർവർ ഫയർവാൾ ക്രമീകരണം

1. തുറന്ന പോർട്ടുകളും സർവീസുകളും കണ്ടെത്തുക

ആദ്യം തുറന്നിരിക്കുന്ന പോർട്ടുകൾ കണ്ടുപിടിക്കുക. ലിനക്സ് സെർവറിൽ ss -tulpn കമാൻഡ് ഉപയോഗിച്ച് ഏത് സർവീസ് ഏത് പോർട്ടിൽ കേൾക്കുന്നു എന്ന് കാണാം. ഉദാഹരണത്തിന് nginx 0.0.0.0:80, 0.0.0.0:443-ൽ കേൾക്കുകയാണെങ്കിൽ വെബ് ട്രാഫിക് എല്ലാ ഇന്റർഫേസുകളും സ്വീകരിക്കുന്നു എന്ന്. MariaDB 0.0.0.0:3306-ൽ കേൾക്കുമ്പോൾ അത് പൊതുജനങ്ങൾക്ക് അപകടകരമാണ്; സാധാരണ ഡാറ്റാബേസ് 127.0.0.1-ൽ പ്രവർത്തിക്കണം.

പ്രായോഗിക നിയമം: ഇന്റർനെറ്റിൽ തുറക്കേണ്ട സർവീസുകൾ 0.0.0.0-ൽ കേൾക്കരുത്. ആദ്യം സർവീസ് കോൺഫിഗറേഷൻ ശരിയാക്കുക, ശേഷം ഫയർവാൾ ഉപയോഗിച്ച് തടയുക. ഫയർവാൾ ഓഫ് ആയാലും സർവീസ് പുറം ലോകത്ത് തുറന്നിരിക്കരുത്.

2. ഡിഫോൾട്ട് പോളിസി ബ്ലോക്ക് ആക്കുക

സുരക്ഷിത നിയമങ്ങളിൽ വരും ട്രാഫിക് നിരാകരിച്ച് പോകും, പുറപ്പെടുന്ന ട്രാഫിക് ആവശ്യാനുസരണം അനുവദിക്കും. ഇത് പിഴവായി പുതിയ സർവീസുകൾ അനാവശ്യമായി തുറക്കുന്നത് തടയുന്നു. UFW ഉപയോഗിക്കുന്ന ഉബുണ്ടുവിൽ, ആദ്യം SSH അനുവദിച്ച്, 80, 443 തുറക്കുകയും, വരും ട്രാഫിക് ഡിഫോൾട്ടായി നിരാകരിച്ച് ഫയർവാൾ സജീവമാക്കുകയും ചെയ്യുന്നു.

ഉദാഹരണമായി: SSH-നായി നിങ്ങളുടെ അഡ്മിൻ IP അനുവദിക്കുക, HTTP, HTTPS തുറക്കുക, അനാവശ്യ പോർട്ടുകൾ അടയ്ക്കുക, ശേഷം ഫയർവാൾ ഓൺ ചെയ്യുക. SSH അനുവദിക്കാതെ ഫയർവാൾ സജീവമാക്കുന്നത് സാധാരണ തെറ്റ് ആണ്, പ്രത്യേകിച്ച് റിമോട്ട് സെർവർമുകളിൽ.

3. SSH ആക്സസ് നിയന്ത്രിക്കുക

SSH ആണ് ആക്രമികൾ ഏറ്റവും കൂടുതൽ ലക്ഷ്യമിടുന്ന സർവീസ്. ഡിഫോൾട്ട് 22 പോർട്ട് തുറന്നിരിക്കുന്ന സെർവർ ദിവസം നൂറുകണക്കിന് പാസ്‌വേഡ് ശ്രമങ്ങൾ നേരിടും. ഏറ്റവും സുരക്ഷിത മാർഗം SSH ആക്സസ് IP വിലാസങ്ങളിൽ മാത്രം പരിമിതപ്പെടുത്തുകയാണ്. സ്ഥിര IP ഉള്ളവർക്ക് ഓഫീസ് അല്ലെങ്കിൽ VPN IP മാത്രം അനുവദിക്കുക. സ്ഥിര IP ഇല്ലെങ്കിൽ കീ-ബേസ്‌ഡ് ഓതന്റിക്കേഷൻ ഉപയോഗിച്ച് പാസ്‌വേഡ് പ്രവേശനം അടയ്ക്കുക.

• റൂട്ട് SSH ലോഗിൻ നിഷേധിക്കുക.
• പാസ്‌വേഡിനു പകരം SSH കീ ഉപയോഗിക്കുക.
• AllowUsers, AllowGroups ഉപയോഗിച്ച് ഉപയോക്താക്കളെ നിയന്ത്രിക്കുക.
• Fail2ban ഉപയോഗിച്ച് പരാജയപ്പെട്ട ശ്രമങ്ങൾ താൽക്കാലികമായി തടയുക.
• അഡ്മിൻ പാനൽ പോർട്ട് IP നിയന്ത്രണത്തിലാക്കുക.

പോർട്ട് മാറ്റം മാത്രം കനിഞ്ഞ സുരക്ഷ നൽകില്ല, എന്നാൽ ബോട്ട് ശബ്ദം കുറയ്ക്കാം. യഥാർത്ഥ സംരക്ഷണം IP നിയന്ത്രണം, ശക്തമായ ഓതന്റിക്കേഷൻ, ലോഗ് നിരീക്ഷണത്തിലൂടെയാണ്.

4. വെബ് പോർട്ടുകൾ നിയന്ത്രിതമായി തുറക്കുക

വെബ് സൈറ്റ് ഹോസ്റ്റ് ചെയ്യുന്ന സെർവറുകൾക്ക് 80, 443 പോർട്ടുകൾ ആവശ്യമാണ്. ഇന്നത്തെ കാലത്ത് 443 (HTTPS) മുഖ്യ ട്രാഫിക് പോർട്ടായിരിക്കണം, 80 HTTPS-ലേക്കുള്ള റിഡയറക്ട് മാത്രമായിരിക്കണം. SSL സർട്ടിഫിക്കറ്റില്ലാത്ത സൈറ്റുകൾ ഉപഭോക്തൃ വിശ്വാസവും SEO പ്രകടനവും നഷ്ടപ്പെടുത്തും. ഈ സന്ദർഭത്തിൽ Hostragons SSL സർട്ടിഫിക്കറ്റുകൾ ലിങ്ക് HTTPS സുരക്ഷിതത്വത്തിലേക്ക് നയിക്കാൻ അനുയോജ്യമാണ്.

വെബ് പോർട്ടുകൾ തുറക്കുമ്പോൾ യഥാർത്ഥ IP ട്രാഫിക് ശ്രദ്ധിക്കുക. CDN അല്ലെങ്കിൽ റിവേഴ്സ് പ്രോക്സി ഉപയോഗിക്കുന്നുവെങ്കിൽ, 80, 443 പോർട്ടുകൾ എല്ലാ ഇന്റർനെറ്റിനും തുറക്കാതെ CDN IP പരിധികളിൽ നിന്നുള്ള ട്രാഫിക് മാത്രം അനുവദിക്കുക. ഇതു വഴി ആക്രമികൾ യഥാർത്ഥ സെർവർ IP അറിയിച്ചാലും നേരിട്ട് വെബ് സർവീസ് ആക്സസ് ചെയ്യാനാകില്ല.

5. ഡാറ്റാബേസ്, ആഭ്യന്തര സർവീസുകൾ ഇന്റർനെറ്റിൽ നിന്ന് അടയ്ക്കുക

MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB പോലുള്ള സർവീസുകൾ ഇന്റർനെറ്റിൽ തുറന്നിരിക്കുന്നത് ഗുരുതര അപകടമാണ്. Redis-ൽ ഓതന്റിക്കേഷൻ ഇല്ലായ്മ, Elasticsearch-ൽ അനധികൃത ഇൻഡക്സ് ആക്സസ്, MongoDB-യിൽ തുറന്ന അഡ്മിൻ പോർട്ട് മുൻകാലത്ത് നിരവധി ഡേറ്റാ ചോർച്ചകൾക്ക് കാരണമായിട്ടുണ്ട്. ഈ സർവീസുകൾ സാധ്യമായെങ്കിൽ ലോക്കൽഹോസ്റ്റ് അല്ലെങ്കിൽ സ്വകാര്യ നെറ്റ്‌വർക്കിൽ മാത്രം കേൾക്കണം.

ഉദാഹരണത്തിന്, ഒരേ സെർവറിൽ പ്രവർത്തിക്കുന്ന WordPress വെബ്സൈറ്റിനായി ഡാറ്റാബേസ് 127.0.0.1-ൽ പ്രവർത്തിക്കണം. വേറെ ആപ്ലിക്കേഷൻ സെർവർ ഉപയോഗിക്കുന്നുണ്ടെങ്കിൽ ആ പ്രത്യേക IP-നു മാത്രമേ ആക്സസ് അനുവദിക്കൂ. 3306, 5432 പോലുള്ള പോർട്ടുകൾ പൊതു ഇന്റർനെറ്റിൽ തുറക്കുന്നത് ബോട്ടുകൾ സ്ഥിരമായി തട്ടിവരുന്ന പിശകാണ്.

6. Fail2ban ഉപയോഗിച്ച് ബ്രൂട്ട് ഫോഴ്സ് തടയുക

Fail2ban ലോഗ് ഫയലുകൾ നിരീക്ഷിച്ച് പുനരാവൃത്തമായി പരാജയപ്പെട്ട ലോഗിൻ ശ്രമങ്ങൾ കണ്ടെത്തി ബന്ധപ്പെട്ട IP-നെ താൽക്കാലികമായി തടയുന്നു. SSH, nginx, Apache, Postfix, Dovecot, WordPress ലോഗിൻ, ചില പാനൽ സർവീസുകൾക്കായി jail പരമർശനങ്ങൾ സജ്ജമാക്കാം. ഉദാഹരണത്തിന് 10 മിനിറ്റിനുള്ളിൽ 5 തവണ പരാജയപ്പെട്ട SSH ശ്രമം കാണിച്ച IP-നെ 1 മണിക്കൂർ തടയുന്നത് ലളിതവും കാര്യക്ഷമവുമാണ്.

Fail2ban ക്രമീകരണത്തിൽ അതിശക്തമായ നിയമങ്ങൾ ഉപയോഗിക്കുമ്പോൾ ശ്രദ്ധിക്കുക. തെറ്റായ ലോഗ് മാതൃക യഥാർത്ഥ ഉപയോക്താക്കളെ തടയാം. അതിനാൽ ആദ്യ ഘട്ടത്തിൽ bantime മൂല്യം യുക്തിപൂർവ്വം കൂട്ടി, ലോഗുകൾ നിരീക്ഷിച്ച് പിന്നീട് ക്രമീകരണം ശക്തിപ്പെടുത്തുക.

7. നിരക്ക് നിയന്ത്രണവും കണക്ഷൻ പരിധികളും കൂട്ടിച്ചേർക്കുക

DDoS, ബോട്ട് ട്രാഫിക്കിനെതിരെ ഓപ്പറേറ്റിങ് സിസ്റ്റം നിരക്ക് നിയന്ത്രണം സഹായകരമാണ്. ഉദാഹരണത്തിന് ഒരേ IP-യിൽ നിന്നുള്ള അതിവേഗ പുതിയ കണക്ഷനുകൾ തടയാം. വെബ് സെർവറുകളിൽ nginx-യ്ക്ക് limit_req, limit_conn, Apache-ക്ക് mod_evasive പോലുള്ള മോഡ്യൂളുകൾ ഉപയോഗിക്കാം. ആപ്ലിക്കേഷൻ തലത്തിൽ ലോഗിൻ, തിരയൽ, ഷോപ്പിംഗ് കാർട്ട്, പേയ്‌മെന്റ്, API എന്റ്പോയിന്റുകൾക്ക് പ്രത്യേക നിരക്ക് നിയന്ത്രണം വേണം.

ഉദാഹരണമായി: ഒരു ലോഗിൻ പേജിൽ ഓരോ IP-ക്കും മിനിറ്റിൽ 10 ശ്രമം മതിയാകും. തിരയൽ എന്റ്പോയിന്റിൽ സെക്കൻഡിൽ 2-5 അഭ്യർത്ഥനകൾ മതിയാകും. API-കൾക്ക് യൂസർ അടിസ്ഥാനമുള്ള ടോക്കൺ, IP പരിധി, പെരുമാറ്റ വിശകലനം എന്നിവ ചേർന്ന് രൂപകൽപ്പന ചെയ്യണം. ഇങ്ങനെ ആക്രമികൾ IP മാറി നിരക്കുകൾ മറികടക്കാൻ കഴിയില്ല.

UFW-ഉപയോഗിച്ച് സുരക്ഷിത സെറ്റപ്പ് ഉദാഹരണം

ഉബുണ്ടു അല്ലെങ്കിൽ ഡെബിയൻ അടിസ്ഥാന വെബ് സെർവറിൽ ലളിതമായ സുരക്ഷിത തുടക്കം ഇങ്ങനെ ആകാം: നിലവിലുള്ള സർവീസുകൾ പരിശോധിക്കുക, അഡ്മിൻ IP-യിൽ നിന്ന് SSH അനുവദിക്കുക, 80, 443 തുറക്കുക, വരും ട്രാഫിക് ഡിഫോൾട്ടായി നിരാകരിക്കുക, UFW സ്ഥിതി പരിശോധിക്കുക. SSH ആക്സസ് സ്ഥിര IP-മുതൽ നിയന്ത്രിക്കാനാകാത്ത പക്ഷം താൽക്കാലികമായി മുഴുവൻ IP-കളിൽ SSH അനുവദിച്ച് പിന്നീട് VPN അല്ലെങ്കിൽ സ്ഥിര IP പരിഹാരത്തിലേക്ക് മാറ്റാം.

ഉദാഹരണമായി: 203.0.113.10 എന്ന IP അഡ്മിൻ IP ആക്കുക. SSH ഈ IP-യിൽ നിന്നു മാത്രമേ കണക്ട് ചെയ്യൂ. വെബ് ട്രാഫിക് 80, 443 പോർട്ടുകളിൽ എല്ലാവർക്കും തുറന്നു നിർത്തുക. ഡാറ്റാബേസ്, Redis, പാനൽ, ടെസ്റ്റ് പോർട്ടുകൾ പുറമെ അടച്ചിരിക്കുക. ഇത് ചെറിയ മുതൽ മധ്യതല സ്ഥാപനങ്ങളുടെ വെബ് സൈറ്റുകൾക്കായി നല്ല തുടക്കമാണ്. ഡൊമെയ്ൻ, DNS ശരിയായി ക്രമീകരിക്കാൻ Hostragons ഡോമേൻ പരിശോധനയും രജിസ്ട്രേഷൻ ലിങ്ക് സഹായിക്കും.

firewalld-ഇന്റെ സോൺ ആശയം

AlmaLinux, Rocky Linux, RHEL അടിസ്ഥാന സെർവറുകളിൽ firewalld സാധാരണമാണ്. firewalld സോൺ ആശയത്തിൽ പ്രവർത്തിക്കുന്നു. Public സോൺ ഇന്റർനെറ്റിൽ തുറന്ന ഇന്റർഫേസുകൾക്കായി, trusted സോൺ വിശ്വാസയോഗ്യമായ സ്വകാര്യ നെറ്റ്‌വർക്ക്, drop സോൺ അനിഷ്ട ട്രാഫിക് മൗനമായി തള്ളാൻ ഉപയോഗിക്കുന്നു. പ്രധാനമായും runtime, permanent നിയമങ്ങളുടെ വ്യത്യാസം മനസ്സിലാക്കണം. runtime നിയമം ഉടനെ പ്രാവർത്തികമാകുന്നു, എന്നാൽ റീബൂട്ട് ചെയ്താൽ നഷ്ടപ്പെടാം; permanent നിയമം സ്ഥിരതയുള്ളതാണ്, എന്നാൽ റീലോഡ് ആവാം.

കോർപ്പറേറ്റ് അന്തരീക്ഷങ്ങളിൽ firewalld ഉപയോഗിക്കുമ്പോൾ സർവീസ് അടിസ്ഥാനത്തിലുള്ള നിയമങ്ങൾ കാര്യങ്ങൾ എളുപ്പമാക്കുന്നു. ഉദാഹരണത്തിന് http, https സർവീസുകൾ public സോണിൽ തുറക്കാം, ssh സർവീസ് പ്രത്യേക IP-കളിൽ നിന്ന് മാത്രം ആക്സസ് ചെയ്യാം. അഡ്മിൻ നെറ്റ്‌വർക്ക്, ബാക്കപ്പ് നെറ്റ്‌വർക്ക്, യൂസർ ട്രാഫിക് വേർതിരിച്ചിട്ടുണ്ടെങ്കിൽ സോൺ ഘടന സുരക്ഷയും വായനാസൗകര്യവും വർദ്ധിപ്പിക്കും.

CDN, WAF, പ്രൊവൈഡർ തല DDoS സംരക്ഷണം

പ്രാദേശിക ഫയർവാൾ പാക്കറ്റുകൾ സെർവറിലേക്ക് വന്ന ശേഷം തീരുമാനമെടുക്കുന്നു. വലിയ DDoS ആക്രമണങ്ങളിൽ ട്രാഫിക് സെർവറിലേക്ക് എത്തുന്നതിനു മുമ്പ് ഫിൽട്ടർ ചെയ്യുകയാണ് ലക്ഷ്യം. അതിനാൽ CDN, WAF, പ്രൊവൈഡർ തല DDoS സംരക്ഷണം അത്യന്താപേക്ഷിതമാണ്. CDN സ്റ്റാറ്റിക് ഉള്ളടക്കം എഡ്ജ് ലൊക്കേഷനുകളിൽ നൽകുന്നു, WAF ആപ്ലിക്കേഷൻ തലത്തിലെ ഹാനികര അഭ്യർത്ഥനകൾ തടയും, പ്രൊവൈഡർ സംരക്ഷണം നെറ്റ്‌വർക്ക് തലത്തിലെ വലിയ ആക്രമണങ്ങൾ ശമിപ്പിക്കുകയോ നീക്കുകയോ ചെയ്യുന്നു.

അധിഷ്ഠിത മോഡലിൽ DNS റെക്കോർഡുകൾ CDN-വഴി പോകുകയും യഥാർത്ഥ സെർവർ IP മറച്ചു വെക്കുകയും ചെയ്യുന്നു, സെർവർ ഫയർവാൾ CDN IP പരിധികളിൽ നിന്നുള്ള 80, 443 മാത്രം സ്വീകരിക്കുന്നു. അഡ്മിൻ പോർട്ടുകൾ VPN അല്ലെങ്കിൽ സ്ഥിര IP വഴി മാത്രമേ ആക്സസ് ചെയ്യപ്പെടൂ. ഇത്തരമൊരു മോഡൽ നേരിട്ട് IP-യിലേക്ക് ആക്രമണം കുറയ്ക്കുകയും, ബോട്ട് ട്രാഫിക് ആപ്ലിക്കേഷനിലേക്ക് എത്തുന്നതിനു മുമ്പ് തടയുകയും ചെയ്യുന്നു. വെബ് സുരക്ഷയും പ്രകടനവും ഒരുമിച്ച് കൈകാര്യം ചെയ്യുന്ന ഉള്ളടക്കങ്ങൾക്ക് വെബ് സൈറ്റിന്റെ വേഗം വർദ്ധിപ്പിക്കൽയും സുരക്ഷയും മാർഗ്ഗനിർദ്ദേശങ്ങൾ സന്ദർശിക്കുക.

ബോട്ടുകൾക്കെതിരെ ആപ്ലിക്കേഷൻ തല മുൻകരുതലുകൾ

ബോട്ട് തടയൽ IP ബാൻ ലിസ്റ്റിൽ മാത്രം ഇല്ല. ആധുനിക ബോട്ടുകൾ പ്രോക്സി, മൊബൈൽ നെറ്റ്‌വർക്ക്, ഡാറ്റാ സെന്റർ IPകൾ, വ്യത്യസ്ത യൂസർ ഏജന്റുകൾ ഉപയോഗിക്കും. അതിനാൽ പെരുമാറ്റ-കേന്ദ്രമായ സമീപനം വേണം. ഒരേ IP-യിൽ നിന്ന് ചുരുങ്ങിയ സമയം കൊണ്ടുള്ള നിരവധി ലോഗിൻ ശ്രമങ്ങൾ, നിരന്തര 404 തള്ളലുകൾ, wp-login.php, xmlrpc.php തീവ്ര ഉപയോഗം, സാധാരണ ഉപയോക്താവിനെ അപേക്ഷിച്ച് വ്യത്യസ്തമായ ക്ലിക്ക് പാറ്റേണുകൾ, സംശയാസ്പദ ഹെഡറുകൾ എന്നിവ വിശകലനം ചെയ്യണം.

• ലോഗിൻ, രജിസ്ട്രേഷൻ ഫോമുകളിൽ നിരക്ക് നിയന്ത്രണം പ്രയോഗിക്കുക.
• അനാവശ്യ XML-RPC ആക്സസ് അടയ്ക്കുക അല്ലെങ്കിൽ നിയന്ത്രിക്കുക.
• അഡ്മിൻ പാനൽ വ്യത്യസ്ത URL, IP നിയന്ത്രണം, മള്‍ടി-ഫാക്ടർ ഓതന്റിക്കേഷൻ ഉപയോഗിച്ച് സംരക്ഷിക്കുക.
• WAF തലത്തിൽ സംശയാസ്പദ യൂസർ ഏജന്റ്, റഫറർ മാതൃകകൾ ഫിൽട്ടർ ചെയ്യുക.
• ഫോമുകളിൽ CAPTCHA അല്ലെങ്കിൽ അദൃശ്യ ബോട്ട് വെരിഫിക്കേഷൻ സൗകര്യം ഉപയോഗിച്ച് സജീവം നിലനിർത്തുക.
• API എന്റ്പോയിന്റുകൾക്ക് കീ, സെൻസർ, ക്വോട്ട, ടൈംസ്റ്റാമ്പ് പരിശോധനകൾ ചേർക്കുക.

ബോട്ട് നിയന്ത്രണത്തിൽ ഉപയോക്തൃ അനുഭവം പ്രശ്നപ്പെടുത്തരുത്. അത്യധികം CAPTCHA, കടുത്ത തടയൽ, തെറ്റായ ദേശങ്ങൾ ബ്ലോക്ക് ചെയ്യൽ യഥാർത്ഥ ഉപഭോക്താക്കൾക്ക് ദോഷകരമാണ്. അതിനാൽ അളവ്, പരിശോധന, കട്ടപ്പാടിൽ ക്രമീകരണം ഏറ്റവും നല്ല മാർഗമാണ്.

ലോഗ് നിരീക്ഷണം, അലാർം നിയമങ്ങൾ

സ്ഥാപനം കഴിഞ്ഞു എന്ന് കരുതുന്നത് വലിയ തെറ്റാണ്. ഫയർവാൾ ഒരു ജീവിച്ചിരിക്കുന്ന സംവിധാനമാണ്, തുടർച്ചയായി നിരീക്ഷണം വേണം. auth.log, secure ലേക്ക് SSH ശ്രമങ്ങൾ, nginx access log-ൽ അസാധാരണ അഭ്യർത്ഥനകൾ, error log-ലെ 404, 500 വർധന, സിസ്റ്റം മെറ്റ്രിക്‌സിൽ CPU, കണക്ഷൻ എണ്ണത്തിന്റെ മാറ്റങ്ങൾ എന്നിവ പരിശോധിക്കുക. ലളിതമായ അലാർവും ആക്രമണം ആരംഭിച്ചപ്പോൾ ചില മിനിറ്റുകൾ നേടും.

ആദ്യം ഉപയോഗിക്കാവുന്ന പരിധികൾ: 5 മിനിറ്റിൽ ഒരേ IP-യിൽ നിന്ന് 100-ത്തിലധികം 404 അഭ്യർത്ഥനകൾ, 1 മിനിറ്റിൽ ലോഗിൻ പേജിൽ 20-ലധികം ശ്രമങ്ങൾ, CPU ഉപയോഗം 10 മിനിറ്റുകൾ 90% മുകളിലായിരിക്കുക, കണക്ഷനുകൾ സാധാരണ മൂല്യത്തിന് 3 മടങ്ങായിരിക്കുക. ഈ പരിധികൾ സൈറ്റിനനുസരിച്ച് വ്യത്യാസപ്പെടും; പ്രധാനമാണ് സാധാരണ ട്രാഫിക് പ്രൊഫൈൽ മനസ്സിലാക്കുക.

പൊതുവായ പിശകുകൾ, ഒഴിവാക്കാനുള്ള വഴി

• SSH അനുവദിക്കാതെ ഫയർവാൾ ഓൺ ചെയ്യുക: അകലെയുള്ള സെർവറിൽ ആക്സസ് നഷ്ടപ്പെടാൻ കാരണമാകും. രണ്ടാമത്തെ സെഷനിൽ പരീക്ഷണം നിർബന്ധമാണ്.
• IPv6 മറക്കുക: IPv4 അടച്ചിട്ടെങ്കിലും IPv6 വഴി സർവീസ് തുറന്നിരിക്കാം.
• ഡാറ്റാബേസ് പൊതു ഇന്റർനെറ്റിൽ തുറന്നിടുക: 3306, 5432, 6379, 9200 പോലുള്ള പോർട്ടുകൾ ബോട്ടുകൾ സ്ഥിരം സ്കാൻ ചെയ്യുന്നു.
• CDN ഉപയോഗിച്ച് യഥാർത്ഥ IP തുറന്നിടുക: ആക്രമികൾ CDN മറികടന്ന് നേരിട്ട് സെർവറിലേക്ക് എത്താം.
• നിയമങ്ങൾ രേഖപ്പെടുത്തിയില്ലാതെ മാറ്റുക: അടിയന്തര സാഹചര്യം വന്നപ്പോൾ നിയമങ്ങളുടെ പ്രാധാന്യം മനസ്സിലാക്കാൻ പ്രയാസം.
• ബാക്കപ്പ് ആക്‌സസ് പദ്ധതി ഇല്ലാതിരിക്കുക: തെറ്റായ നിയമത്തിൽ കോൺസോൾ ആക്‌സസ് ഇല്ലെങ്കിൽ ഇടപെടൽ വൈകും.

വർഗ്ഗീകരിച്ച ഫയർവാൾ നയം ഉദാഹരണം

ഒരു ചെറിയ സ്ഥാപന വെബ് സൈറ്റിനായി പ്രയോഗിക്കാവുന്ന സംക്ഷിപ്ത നയം: വരും ട്രാഫിക് ഡിഫോൾട്ടായി നിരാകരിക്കുക; 443 എല്ലാം അനുവദിക്കുക; 80 HTTPS റിഡയറക്ട് മാത്രം; SSH VPN അല്ലെങ്കിൽ സ്ഥിര IP-യിൽ നിന്ന് മാത്രം ആക്സസ് ചെയ്യുക; ഡാറ്റാബേസ് ലോക്കൽ അല്ലെങ്കിൽ സ്വകാര്യ നെറ്റ്‌വർക്കിൽ; CDN ഉപയോഗിച്ചാൽ 80, 443 CDN IP പരിധിയിൽ മാത്രം അനുവദിക്കുക; Fail2ban SSH, വെബ് ലോഗിൻ ശ്രമങ്ങൾ നിരീക്ഷിക്കുക; ലോഗുകൾ കേന്ദ്ര മോണിറ്ററിംഗിലേക്ക് അയയ്ക്കുക.

മധ്യതല ഇ-കൊമേഴ്‌സ് സൈറ്റിൽ പേയ്‌മെന്റ് കോൾബാക്ക് IP-കൾ allowlist ചെയ്യപ്പെടും, അഡ്മിൻ പാനൽ VPN പിന്നിൽ; API-കൾക്ക് യൂസർ അടിസ്ഥാനമായ ക്വോട്ട; WAF-ൽ SQL Injection, XSS നിയന്ത്രണങ്ങൾ സജീവമാക്കും; ദേശം, ASN അടിസ്ഥാനത്തിലുള്ള താൽക്കാലിക ഫിൽട്ടറിംഗ് പദ്ധതിയും ഉണ്ടാകും. ഈ പദ്ധതി എഴുതി സൂക്ഷിക്കുന്നത് അത്യന്താപേക്ഷിതമാണ്; ആക്രമണ സമയത്ത് മുൻകൂട്ടി തയ്യാറാക്കിയ നിർദ്ദേശങ്ങൾ അനുസരിക്കുക ഇടപെടൽ സമയവും കുറയ്ക്കും.

പരീക്ഷണം: നിയമങ്ങൾ ശരിയായി പ്രവർത്തിക്കുമോ?

സെറ്റപ്പ് കഴിഞ്ഞു കഴിഞ്ഞ് നിർബന്ധമായും ടെസ്റ്റ് നടത്തണം. വേറെ നെറ്റ്വർക്കിൽ നിന്ന് തുറന്ന പോർട്ടുകൾ സ്കാൻ ചെയ്യുക, SSH ആക്സസ് അനുവദിച്ച IPയിൽ നിന്ന് മാത്രമാണെന്ന് സ്ഥിരീകരിക്കുക, വെബ് സൈറ്റ് HTTPS വഴി പ്രവേശനയോഗ്യമാണെന്ന് ഉറപ്പാക്കുക, ഡാറ്റാബേസ് പോർട്ട് പുറം ലോകത്ത് അടച്ചിട്ടുണ്ടെന്ന് ഉറപ്പാക്കുക. CDN ഉപയോഗിക്കുന്നുവെങ്കിൽ യഥാർത്ഥ സെർവർ IP-യിലേക്ക് നേരിട്ട് HTTP അഭ്യർത്ഥന അയച്ച് തടയപ്പെട്ടതായ് സ്ഥിരീകരിക്കുക.

ടെസ്റ്റിംഗ് സമയത്ത് പ്രൊഡക്ഷൻ സിസ്റ്റങ്ങളിൽ അമിതമായ സ്കാനിംഗ് ഒഴിവാക്കുക. ലക്ഷ്യം സുരക്ഷിതമായ പരിശോധനം മാത്രമാണ്. കൂടാതെ എല്ലാ മാറ്റത്തിനും ശേഷം നിയമങ്ങൾ എക്സ്പോർട്ട് ചെയ്യുകയോ രേഖപ്പെടുത്തുകയോ ചെയ്യുക. പ്രശ്നം വന്നാൽ മുൻപത്തെ സുരക്ഷിത ഘടനയിലേക്ക് മടക്കാൻ ഇത് സഹായിക്കും.

പരിപാലനവും അപ്‌ഡേറ്റും

സെർവർ സുരക്ഷ ഏകദേശം ഒരിക്കൽ ക്രമീകരിക്കുന്ന കാര്യമല്ല, ഇത് തുടർച്ചയായ പരിപാലനമാണ്. പുതിയ സർവീസ് ചേർക്കുമ്പോൾ പോർട്ട് ആവശ്യകത പരിശോധിക്കുക, പഴയ സർവീസ് നീക്കംചെയ്യുമ്പോൾ അനുമതികൾ നീക്കംചെയ്യുക, സുരക്ഷാ അപ്‌ഡേറ്റുകൾ സമയബന്ധിതമായി നടപ്പിലാക്കുക, ലോഗുകൾ നിശ്ചിതമായി പരിശോധിക്കുക. മാസത്തിൽ കുറഞ്ഞത് ഒരു പ്രാവശ്യം തുറന്ന പോർട്ടുകൾ പരിശോധിക്കുക, മൂന്ന് മാസം തോറും ഫയർവാൾ നിയമങ്ങൾ പരിശോധിക്കുക നല്ല ശീലമാണ്.

കൂടാതെ ബാക്കപ്പ് പദ്ധതിയും സുരക്ഷാ തന്ത്രത്തിന്റെ ഭാഗമാണ്. DDoS ആക്രമണം ആക്സസ് തടയാം, പക്ഷേ റാൻസംവെയർ അല്ലെങ്കിൽ അനധികൃത ആക്സസ് ഡേറ്റ നഷ്ടത്തിന് കാരണമാകും. സുരക്ഷിത ഹോസ്റ്റിംഗ്, SSL, ഡൊമെയ്ൻ മാനേജ്മെന്റ്, ബാക്കപ്പ് എന്നിവ കൂടി പരിഗണിക്കണം. ഈ സന്ദർഭത്തിൽ സുരക്ഷിത ഹോസ്റ്റിംഗ് തിരഞ്ഞെടുക്കുമ്പോൾ ശ്രദ്ധിക്കേണ്ടത് , SSL സർട്ടിഫിക്കറ്റിന്റെ ഇൻസ്റ്റലേഷൻ നൽകിയ രീതിയിൽ ഉള്ളടക്കങ്ങൾ സഹായി ആയി.

സംക്ഷേപം

സെർവർ ഫയർവാൾ ക്രമീകരണം DDoS, ബോട്ടുകൾക്കെതിരെ സെർവറിനെ പൂർണ്ണമായും അദൃശ്യമാക്കുകയില്ല; പക്ഷേ ആക്രമണ സാധ്യത കുറയ്ക്കുകയും അനധികൃത ആക്സസ് അപകടം കുറയ്ക്കുകയും സംഭവങ്ങൾ നിയന്ത്രിതമായി കൈകാര്യം ചെയ്യാൻ സഹായിക്കുകയും ചെയ്യും. ഏറ്റവും ഫലപ്രദമായ സമീപനം സേവനദാതാവ് തല DDoS സംരക്ഷണം, CDN/WAF, കർശന പോർട്ട് നയം, SSH നിയന്ത്രണം, Fail2ban, നിരക്ക് നിയന്ത്രണം, ലോഗ് നിരീക്ഷണം എന്നിവ ചേർന്ന് നടപ്പാക്കലാണ്.

പുതിയ പ്രോജക്ട് ആരംഭിക്കുമ്പോൾ തന്നെ ഫയർവാൾ നയം രൂപപ്പെടുന്നത് ഭൂരിഭാഗം പ്രശ്നങ്ങൾ ഒഴിവാക്കും. Hostragons-ൽ സെർവർ, ഹോസ്റ്റിംഗ്, ഡൊമെയ്ൻ, SSL അടിസ്ഥാന സൗകര്യങ്ങൾ വിലയിരുത്തുമ്പോൾ സുരക്ഷാ ആവശ്യകതകളും കൂടി പരിഗണിച്ച് ശക്തമായ വെബ് പരിസ്ഥിതി രൂപപ്പെടുത്താം. ചെറിയ ഒരു പരിശോധനാ ലിസ്റ്റ് ഉപയോഗിച്ച് തുടങ്ങാം: തുറന്ന പോർട്ടുകൾ അടയ്‌ക്കുക, SSH നിയന്ത്രിക്കുക, HTTPS നിർബന്ധിതമാക്കുക, ലോഗുകൾ നിരീക്ഷിക്കുക.

അധികമായുള്ള ചോദ്യങ്ങൾ

സെർവർ ഫയർവാൾ DDoS ആക്രമണം പൂര്‍ണമായും തടയുമോ?

അല്ല. പ്രാദേശിക ഫയർവാൾ ചെറിയ തോതിലുള്ള പ്രോട്ടോക്കോൾ തലത്തിലുള്ള ആക്രമണങ്ങൾ കുറയ്ക്കാനാകും, എന്നാൽ വലിയ തോതിലുള്ള DDoS ആക്രമണങ്ങൾക്ക് സേവനദാതാവ് തല DDoS സംരക്ഷണം, CDN, WAF എന്നിവ ആവശ്യമുണ്ട്.

വെബ് സെർവറിൽ ഏത് പോർട്ടുകൾ തുറന്നിരിക്കണം?

സാധാരണ വെബ് സെർവറിൽ 80, 443 പോർട്ടുകൾ തുറന്നിരിക്കണം. SSH പോർട്ട് അഡ്മിൻ IP-കളിൽ മാത്രം അനുവദിക്കണം. ഡാറ്റാബേസ്, ആഭ്യന്തര സർവീസ് പോർട്ടുകൾ ഇന്റർനെറ്റിൽ അടച്ചിരിക്കണം.

UFW അല്ലെങ്കിൽ firewalld ഉപയോഗിക്കണമോ?

ഉബുണ്ടു, ഡെബിയൻ സെർവർകൾക്ക് UFW ലളിതമായ തുടക്കം നൽകും. AlmaLinux, Rocky Linux, RHEL-ൽ firewalld സാധാരണമാണ്. കൂടുതൽ പ്രഗത്ഭമായ സാഹചര്യങ്ങളിൽ nftables ഉപയോഗിക്കാം.

ബോട്ട് ട്രാഫിക് IP തടയലിൽ മാത്രം നിർത്താമോ?

സാധാരണയായി അല്ല. ആധുനിക ബോട്ടുകൾ വ്യത്യസ്ത IPകളും പ്രോക്സികളും ഉപയോഗിക്കുന്നു. അതിനാൽ IP തടയലിനൊപ്പം നിരക്ക് നിയന്ത്രണം, WAF നിയമങ്ങൾ, പെരുമാറ്റ വിശകലനം, CAPTCHA, ആപ്ലിക്കേഷൻ അടിസ്ഥാന ക്വോട്ടകൾ എന്നിവ വേണം.

ഫയർവാൾ ക്രമീകരിക്കുമ്പോൾ ഏറ്റവും വലിയ അപകടം എന്താണ്?

ഏറ്റവും വലിയ അപകടം തെറ്റായ നിയമം കാരണം സ്വന്തം SSH ആക്സസ് നഷ്ടപ്പെടുകയാണ്. അതിനാൽ ആദ്യം SSH അനുവദനീയത സജ്ജമാക്കുക, രണ്ടാമത്തെ സെഷനിൽ പരീക്ഷണം നടത്തുക, സേവനദാതാവ് കോൺസോൾ ആക്സസ് ഉറപ്പാക്കുക.