SSH, VPN എന്നിവയുടെ ഇൻഗ്രസ് നിയമങ്ങൾ: അനുമതി പട്ടിക യഥാർത്ഥത്തിൽ നിയന്ത്രിക്കുന്നത് എന്ത്

ഒരു നിയമം മാറ്റുന്നതിന് മുമ്പ് ഒരിക്കൽ കണക്ട് ചെയ്യുക, ക്ലയന്റ് തങ്ങിനിൽക്കുന്നുണ്ടോ അതോ ഉടൻ നിരസിക്കപ്പെടുന്നുണ്ടോ എന്ന് രേഖപ്പെടുത്തുക. ആ ഒരു വ്യത്യാസം ഏത് തീരുമാനം പാക്കറ്റ് ഇട്ടുകളഞ്ഞു എന്ന് പറയുകയും നയ ഫയലുകൾ വായിക്കുന്ന ഒരു മണിക്കൂർ ലാഭിക്കുകയും ചെയ്യുന്നു. ബാക്കി യാത്ര ചെറുതാണ്: പാക്കറ്റ് ഒരു ഹുക്ക് കടക്കുന്നു, ഒരു നിയമവുമായി ഒത്തുപോകുന്നു, ഒന്നുകിൽ ശ്രോതാവിനെ എത്തുന്നു അല്ലെങ്കിൽ എത്തുന്നില്ല. അനുമതി പട്ടിക ആ മൂന്ന് വസ്തുതകൾക്ക് ചുറ്റുമുള്ള കണക്കെഴുത്ത് മാത്രമാണ്.

ഒരു SSH ശ്രമം ഇൻപുട്ട് ഹുക്ക് വരെ പിന്തുടരുക

ക്ലയന്റ് ഹോസ്റ്റിന്റെ വിലാസത്തിലേക്ക് പോർട്ട് 22 ൽ ഒരു SYN അയയ്ക്കുന്നു, ആ പാക്കറ്റ് പ്രാദേശിക സേവനത്തിനുള്ളതാണോ എന്ന് കേർണൽ തീരുമാനിക്കുന്നു. അങ്ങനെയെങ്കിൽ ഇൻപുട്ട് പാത പ്രവർത്തിക്കുന്നു, നിയമക്കൂട്ടം പാക്കറ്റ് സ്വീകരിക്കുന്നു അല്ലെങ്കിൽ ഉപേക്ഷിക്കുന്നു. നിശ്ശബ്ദത എന്നാൽ ശ്രോതാവ് അത് കാണുന്നതിന് മുമ്പേ SYN മരിച്ചു എന്നാണ്, വേഗത്തിലുള്ള നിരസിക്കൽ എന്നാൽ എന്തോ ഒരു റീസെറ്റോടെ ഉത്തരം നൽകി എന്നാണ്. ഇവ വ്യത്യസ്ത നിയമങ്ങളിൽ നിന്നുള്ള വ്യത്യസ്ത വിധികളാണ്, രണ്ടും സാധുവായ ഫലങ്ങളാണ്.

അതിനുശേഷം ശ്രോതാവ് സ്ഥിരീകരിക്കുക, കാരണം ഇല്ലാത്ത ഒരു സേവനത്തെ ഒരു നിയമവും രക്ഷിക്കുന്നില്ല. ss -ltnp പ്രവർത്തിപ്പിച്ച് നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന പോർട്ടിലും വിലാസ കുടുംബത്തിലും എന്തെങ്കിലും ബന്ധിച്ചിട്ടുണ്ടോ എന്ന് പരിശോധിക്കുക, തുടർന്ന് ക്ലയന്റിൽ ssh -v വായിച്ച് അത് എവിടെ നിൽക്കുന്നു എന്ന് കാണുക.

ഫോർവേഡിംഗ് ഒരു വേറിട്ട തീരുമാനമാണ്

ഒരു VPN സെർവറിൽ കൂടുതൽ താൽപര്യമുള്ള ഹുക്ക് forward ആണ്, കാരണം ക്ലയന്റ് ട്രാഫിക് യന്ത്രത്തിന് കൈമാറുന്നതിന് പകരം അതിലൂടെ റൂട്ട് ചെയ്യുന്നു. സ്വന്തം VPN ക്ലയന്റ് മാത്രം പ്രവർത്തിപ്പിക്കുന്ന ഹോസ്റ്റിന് മറ്റുള്ളവരുടെ പാക്കറ്റുകൾ കൈമാറുന്ന ഹോസ്റ്റിനെക്കാൾ വളരെ ചെറിയ നിയമക്കൂട്ടം മതി. രണ്ട് രൂപകൽപ്പനകളും ഒരു യന്ത്രത്തിൽ കലർത്തിയാൽ ശരിയെന്ന് തോന്നുന്നതും ഒന്നും കടത്തിവിടാത്തതുമായ നിയമങ്ങൾ ഉണ്ടാകും.

ആന്തരിക നയം ഒരു വേറിട്ട ചോദ്യമായി എഴുതുക: ഏത് ക്ലയന്റ് വിലാസങ്ങൾക്ക് ടണലിലൂടെ ഏത് ലക്ഷ്യസ്ഥാനങ്ങളിൽ എത്താം. അഡ്മിനിസ്ട്രേറ്റീവ് പാത, ഉദാഹരണത്തിന് SSH, സ്വന്തം ഉറവിട നിയന്ത്രണത്തോടെ ഇൻപുട്ട് പാതയിൽ നിർത്തുക. പരീക്ഷണ വേളയിൽ ചേർത്ത അയഞ്ഞ forward നിയമമാണ് പരീക്ഷണത്തെ അതിജീവിക്കുന്ന ക്ലാസിക് വൈകല്യം, അതിനാൽ മാറ്റത്തിന് ശേഷം നിങ്ങൾ തിരുത്തിയ ഒരു വരിയല്ല, മുഴുവൻ കൂട്ടവും പരിശോധിക്കുക. ടണൽ ശ്രോതാവ് തുറക്കുന്നത് ബന്ധിപ്പിച്ച ഓരോ ക്ലയന്റിനും ഹോസ്റ്റ് നിയന്ത്രിക്കാനുള്ള അനുമതിയല്ല.

ഡ്രോപ്പും റിജക്ടും പ്രവർത്തനങ്ങളാണ്, നയങ്ങളല്ല

ബേസ് ചെയിനിന്റെ നയം സ്വീകരിക്കുന്നു അല്ലെങ്കിൽ ഉപേക്ഷിക്കുന്നു, ഒപ്ഷനുകളുടെ മുഴുവൻ പട്ടിക അത്രമാത്രം, എന്ന് nftables റഫറൻസ് പറയുന്നു. നിരസിക്കൽ തിരഞ്ഞെടുത്ത ഉത്തരത്തോടുകൂടിയ ഒരു നിയമ പ്രവർത്തനമായി നിലനിൽക്കുന്നു, അതുകൊണ്ടാണ് അത് ഒരു നയമായി എഴുതുന്നത് nftables ലും iptables ലും പരാജയപ്പെടുന്നത്. പ്രായോഗികമായി drop ക്ലയന്റിന് ഒരു വിവരവും നൽകുന്നില്ല, reject അതിന് പ്രവർത്തിക്കാവുന്ന ഒരു പിശക് നൽകുന്നു.

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

ആ രേഖാചിത്രം ഒട്ടിക്കാനുള്ള ഫയലായല്ല, ഒരു തീരുമാനത്തിന്റെ രൂപമായി വായിക്കുക, കാരണം വിലാസ ശ്രേണികൾ ഉദാഹരണങ്ങളാണ്. SSH പോർട്ടിൽ വ്യക്തമായ reject അനധികൃത ക്ലയന്റിനെ ടൈംഔട്ട് കാത്തിരിക്കുന്നതിന് പകരം ഒരു സെക്കൻഡിൽ പരാജയപ്പെടുത്തുന്നു, ഇത് നിങ്ങളുടെ സ്വന്തം ഡീബഗ്ഗിംഗ് ചുരുക്കുന്നു. നിശ്ശബ്ദത യാദൃച്ഛിക സ്കാനിംഗ് നിരുത്സാഹപ്പെടുത്തുന്നു, അധികാരമുള്ള ഉപയോക്താവിനോട് ഒന്നും പറയുന്നുമില്ല. ഓരോ സേവനത്തിനും തിരഞ്ഞെടുത്ത് കാരണം എഴുതുക, അല്ലെങ്കിൽ അടുത്ത വ്യക്തി അത് തിരികെ മാറ്റും.

യഥാർത്ഥത്തിൽ വേണ്ട കൺട്രോൾ ട്രാഫിക് സൂക്ഷിക്കുക

എല്ലാ ICMP യും തടയുന്നത് പാതയുടെ MTU കണ്ടെത്തൽ തകർക്കുന്ന ഒരു ജനപ്രിയ സ്ഥിരമൂല്യമാണ്, ലക്ഷണം സ്ഥാപിക്കപ്പെട്ടതിന് ശേഷം വലിയ പാക്കറ്റുകളിൽ തങ്ങിനിൽക്കുന്ന കണക്ഷനാണ്. IPv6 ൽ അയൽ കണ്ടെത്തൽ അതിന്റെ സ്വന്തം ICMPv6 തരങ്ങളെ ആശ്രയിച്ചിരിക്കുന്നു, അവ ഉപേക്ഷിച്ചാൽ ഏതെങ്കിലും TCP നിയമം പരിശോധിക്കുന്നതിന് മുമ്പേ കണ്ണി തകരും. രണ്ടും വ്യാപക അനുമതികളല്ല, പേരിട്ട ആശ്രിതത്വങ്ങളായി അനുമതി പട്ടികയിൽ വരണം. കണ്ടെത്തൽ നിശ്ശബ്ദമായി തകർക്കുന്ന നയം അൽപ്പം ഡയഗ്നോസ്റ്റിക് ട്രാഫിക് അനുവദിക്കുന്ന നയത്തേക്കാൾ മോശമാണ്.

നിങ്ങൾ ആരംഭിച്ച കണക്ഷനുകൾക്ക് established, related അവസ്ഥകൾ അനുവദിക്കുക, മറുപടികൾ അവസ്ഥ അറിയുന്ന എൻജിന് വിടുക. തുടർന്ന് മറുപടി പാത കൂടുതൽ പുറത്ത് തടയപ്പെട്ടിട്ടില്ല എന്ന് സ്ഥിരീകരിക്കുക, കാരണം മുകളിൽ പുറത്തേക്കുള്ള ട്രാഫിക്കിന് മാത്രമുള്ള നിയന്ത്രണം നിങ്ങൾ ഹോസ്റ്റിനെ കുറ്റപ്പെടുത്താൻ പോയ അതേ ടൈംഔട്ട് സൃഷ്ടിക്കുന്നു.

പഴയ പാത ഉപേക്ഷിക്കുന്നതിന് മുമ്പ് വീണ്ടെടുപ്പ് തെളിയിക്കുക

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

ഒരു VPN സേവനത്തിന്, ഒരിക്കലും കണക്ട് ചെയ്യാത്ത ഒരു ക്ലയന്റിൽ നിന്ന് ആവർത്തിക്കുക, കാരണം പുനരാരംഭിച്ച സെഷൻ പുതിയത് ചർച്ച ചെയ്യേണ്ട അവസ്ഥ പുനരുപയോഗിക്കാം. വിജയിച്ച കൃത്യമായ നിയമക്കൂട്ടം ചെക്സം അല്ലെങ്കിൽ പകർപ്പോടെ രേഖപ്പെടുത്തുക, പിന്നീടുള്ള തിരുത്തൽ ഊഹിക്കുന്നതിന് പകരം താരതമ്യം ചെയ്യാം. നിയമങ്ങളുടെ ക്രമം ഉടമസ്ഥതയുള്ളവരുമായി ഏകോപിപ്പിക്കുക, കാരണം മുൻപുള്ള ഒരു നിയമം നിങ്ങൾ ചേർത്തതിനെ നിശ്ശബ്ദമായി തോൽപ്പിക്കുന്നു.