ഒരു banaction, രണ്ട് ട്രാൻസ്പോർട്ട്: fail2ban-VPN-jail ശരിയാക്കൽ

fail2ban-ൽ ഒന്നും സ്വയം ഒരു പാക്കറ്റ് ഇടുന്നില്ല: അത് ഒരു പ്രവർത്തനം വിളിക്കുന്നു, ആ പ്രവർത്തനമാണ് പ്രോട്ടോക്കോളും പോർട്ടും പേരിടുന്നത്. jail ഒരു ban റിപ്പോർട്ട് ചെയ്യുമ്പോൾ ഡീമൺ ലോഗിനുകൾ സ്വീകരിക്കുന്നത് തുടരുകയാണെങ്കിൽ, ആ ban സാധാരണയായി യഥാർത്ഥമാണ്, ലോഗ് സൂചിപ്പിക്കുന്നതിനേക്കാൾ ഇടുങ്ങിയതും. മറ്റേ ട്രാൻസ്പോർട്ടിലൂടെ വീണ്ടും ബന്ധിപ്പിക്കുന്ന ക്ലയന്റ് ഇൻസ്റ്റാൾ ചെയ്ത നിയമം ഒരിക്കലും കണ്ടുമുട്ടുന്നില്ല. എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് പ്രവർത്തനം എന്ത് ഇൻസ്റ്റാൾ ചെയ്തു എന്നതും ഡീമൺ എന്ത് കേൾക്കുന്നു എന്നതും താരതമ്യം ചെയ്യുക, കാരണം തെളിവ് പ്രവർത്തനം എഴുതിയ ഫയർവാൾ ചെയിനിലാണ്, jail-ന്റെ പട്ടികയിലല്ല.

ചെയിൻ വായിക്കുക, jail-ന്റെ സാരാംശമല്ല

fail2ban സേവനത്തിന്റെ ചെയിനിന് മുന്നിൽ സ്വന്തം ചെയിൻ ചേർക്കുന്നു, അതിനാൽ കൗണ്ടർ പട്ടിക ഉള്ളത് കൃത്യമായി കാണിക്കുന്നു. jail-ന്റെ പേരിലുള്ള ഒരു ചെയിനിൽ ഒരു നിയമം മാത്രമുണ്ടെങ്കിൽ, അതിന്റെ പ്രോട്ടോക്കോൾ കോളം udp എന്ന് വായിക്കുന്നുവെങ്കിൽ, തുടർന്ന് വരുന്ന TCP ലോഗിനുകൾക്ക് അത് പൂർണ്ണ വിശദീകരണമാണ്. തടയപ്പെട്ട ഉറവിടത്തിൽ നിന്നുള്ള UDP പാക്കറ്റുകൾ മാത്രമാണ് നിരസിക്കപ്പെടുന്നത്. സേവനത്തിന് ഒരു TCP ശ്രോതാവുണ്ട്, ആ ചെയിനിൽ ഒന്നും അതിനെ തൊടുന്നില്ല.

അയൽ jail-ന്റെ പ്രഭാവവും ശ്രദ്ധിക്കുക. ഒരു ഹോസ്റ്റ് തികച്ചും കോൺഫിഗർ ചെയ്തതായി തോന്നാം, കാരണം കാണാത്ത പകുതി മറ്റൊരു jail നൽകുന്നു, അതേ ബിൽഡ് ആ jail ഇൻസ്റ്റാൾ ചെയ്യാത്തിടത്ത് ഒന്നും ചെയ്യുന്നുമില്ല.

പ്രവർത്തനം ഒരു പ്രോട്ടോക്കോളിന് പേരിടുന്നു, അവിടെത്തന്നെ അത് പൊട്ടുന്നു

ഓരോ banaction ഉം ഒരു ഫയർവാൾ കമാൻഡ് ടെംപ്ലേറ്റാണ്, പ്രോട്ടോക്കോൾ അതിന്റെ ഒരു പ്ലേസ്ഹോൾഡറിലുണ്ട്. ഈ ഇടുക്കം ഉദ്ദേശപൂർവമാണ്, കാരണം വെബ് jail-നും DNS jail-നും ഒരേ പോർട്ടുകൾ തടയുന്നതിൽ കാര്യമില്ല. സേവനം ഒന്നിലധികം ട്രാൻസ്പോർട്ടുകളിൽ കേൾക്കുമ്പോൾ ഇത് കെണിയാകുന്നു, VPN ഡീമണുകൾ ഇത് പതിവായി ചെയ്യുന്നു. ഫിൽട്ടർ രണ്ട് ട്രാൻസ്പോർട്ടുകളുടെയും പരാജയപ്പെട്ട ലോഗിനുകൾ കാണാം, പക്ഷേ പ്രവർത്തനം ഒന്നിനെ മാത്രം ഉൾക്കൊള്ളുന്നു.

SoftEther, OpenVPN വിന്യാസങ്ങൾ സാധാരണയായി UDP-യിലും TCP-യിലും ഒരുമിച്ച് കേൾക്കുന്നു, രണ്ട് സാഹചര്യങ്ങളിലും ലോഗ് വരി ഒരുപോലെ കാണുന്നതിനാൽ ഫിൽട്ടർ രണ്ടും നിരീക്ഷിക്കുന്നു. അസമമിതി jail-ന്റെ സ്വന്തം റിപ്പോർട്ടിൽ ഒരിക്കലും പ്രത്യക്ഷപ്പെടുന്നില്ല. fail2ban പരാജയങ്ങൾ ശരിയായി എണ്ണി, തുടർന്ന് ആ പരാജയങ്ങൾ വന്ന ട്രാഫിക്കിന്റെ പകുതിക്ക് ബാധകമായ ഒരു നിയമം ഇൻസ്റ്റാൾ ചെയ്തു.

ban രണ്ട് ട്രാൻസ്പോർട്ടുകളെയും ഉൾക്കൊള്ളട്ടെ

പകരം jail-ന്റെ നിർവചനത്തിൽ ഇത് ശരിയാക്കുക; കൈകൊണ്ട് എഴുതിയ നിയമങ്ങൾ അടുത്ത റീലോഡിൽ കെട്ടുപിണയും. ഓരോ പ്രോട്ടോക്കോളിനും ഓരോന്ന് വീതം രണ്ട് പ്രവർത്തനങ്ങൾ വ്യക്തമായി എഴുതുക:

action = %(banaction)s[name=%(__name__)s-tcp, actionname=%(__name__)s-tcp, protocol="tcp", port="%(port)s", chain="%(chain)s"]
         %(banaction)s[name=%(__name__)s-udp, actionname=%(__name__)s-udp, protocol="udp", port="%(port)s", chain="%(chain)s"]

ഇത് protocol = all ഉപയോഗിച്ച് ചുരുക്കാൻ ശ്രമിക്കരുത്. സ്ഥിരസ്ഥിതി banaction ഒരു multiport പ്രവർത്തനമാണ്, അത് -p <protocol> -m multiport --dports <port> ആയി വികസിക്കുന്നു; L4 പ്രോട്ടോക്കോൾ ഇല്ലാത്തതിനാൽ പോർട്ട് പൊരുത്തത്തിന് പരിശോധിക്കാൻ ഒന്നുമില്ല, അതിനാൽ iptables നിയമം നിരസിക്കുന്നു, jail ഇപ്പോഴും വിജയകരമായ ban റിപ്പോർട്ട് ചെയ്യുന്നു. iptables-allports അല്ലെങ്കിൽ nftables-allports പോലുള്ള എല്ലാ പോർട്ട് പ്രവർത്തനം ഒരു എൻട്രി സ്വീകരിക്കുന്നു, പക്ഷേ ആ ഉറവിടത്തിലെ എല്ലാ പോർട്ടുകളും തടയുന്നു, അത് മറ്റൊരു തീരുമാനമാണ്, അതിന് സ്വന്തം ന്യായീകരണം വേണം. protocol tcp അല്ലെങ്കിൽ udp ആയി തന്നെ വയ്ക്കുക, രണ്ട് എൻട്രികളും സ്വീകരിക്കുക.

ക്രമീകരണം വിശ്വസിക്കുന്നതിന് പകരം നിയമം നിലനിൽക്കുന്നുവെന്ന് തെളിയിക്കുക, കാരണം ഒരു ചെയിൻ അത് പിടിക്കുന്നതുവരെ ക്രമീകരണം ഒരു ഉദ്ദേശ്യം മാത്രം വിവരിക്കുന്നു:

iptables -S f2b-vpn-tcp
iptables -S f2b-vpn-udp

ഓരോ ചെയിനും ഒരു നിയമം പട്ടികപ്പെടുത്തണം, ആദ്യത്തേതിൽ -p tcp, രണ്ടാമത്തേതിൽ -p udp, രണ്ടും തടയപ്പെട്ട വിലാസം പേരിടുന്നു. തുടർന്ന് അതേ വിലാസം രണ്ട് ട്രാൻസ്പോർട്ടുകളിലും നിരസിക്കപ്പെടുന്നുവെന്ന് ഉറപ്പാക്കുക. ചെയിനിൽ കാണാത്ത ban ഒരു പ്രതീക്ഷയാണ്, അതേ ലക്ഷണത്തെക്കുറിച്ചുള്ള അടുത്ത റിപ്പോർട്ട് വീണ്ടും അതേ മണിക്കൂർ ചെലവാക്കും.

ban ഇപ്പോഴും എന്ത് വിട്ടുകളയുന്നു, അടുത്ത സംഭവം

പ്രവർത്തനം ചെയ്യുന്നത് ഒരു ഉറവിടം നിരസിക്കുക എന്നതാണ്, അതിലും പട്ടികപ്പെടുത്തിയ പോർട്ടുകളിൽ മാത്രം. വിലാസങ്ങൾ മാറ്റുന്ന ആക്രമണകാരിയോട് അത് ഒന്നും ചെയ്യുന്നില്ല, നൂറുകണക്കിന് ഉപയോക്താക്കൾ പങ്കിടുന്ന കാരിയർ-ഗ്രേഡ് NAT എക്സിറ്റിൽ നിന്ന് ശത്രുതയുള്ള യന്ത്രത്തെ വേർതിരിക്കാനും അതിന് കഴിയില്ല, അവിടെ ഒരു ban ഒന്നും ചെയ്യാത്ത ആളുകളെ പുറത്താക്കുന്നു. ഫിൽട്ടർ ക്ലയന്റിന് യഥാർത്ഥത്തിൽ ഉള്ള വിലാസം വായിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക, കൈമാറിയ ഹെഡറോ പ്രോക്സി വിലാസമോ അല്ല. പിശക് സ്വയം കാലഹരണപ്പെടാൻ വിൻഡോ മതിയായ ചെറുതാക്കി വയ്ക്കുക.

ഇവയൊന്നും പ്രോട്ടോക്കോൾ പരിഹാരം ഒഴിവാക്കാനുള്ള വാദമല്ല; രണ്ട് ആശയങ്ങൾ ഒരുമിച്ച് പിടിക്കാനുള്ള വാദമാണ്. ban jail-ന്റെ സാരാംശം സൂചിപ്പിക്കുന്നതിനേക്കാൾ ഇടുങ്ങിയതാണ്, പൂർണ്ണമായ ban പോലും ഭീഷണിയേക്കാൾ ഇടുങ്ങിയതാണ്. ഫയർവാൾ ചെയിൻ ഡീമണിന്റെ ശ്രോതാക്കളുടെ പട്ടികയ്ക്ക് അടുത്ത് വയ്ക്കുക, പ്രോട്ടോക്കോൾ തോറും താരതമ്യം ചെയ്യുക, കാരണം ban-ന് സേവനത്തിൽ എത്താനാകുമോ ഇല്ലയോ എന്നത് ആ രണ്ട് പട്ടികകളാണ് തീരുമാനിക്കുന്നത്.

റീലോഡ് കമാൻഡും ചെയിൻ പട്ടികയും jail-ന് അടുത്തുള്ള റൺബുക്കിൽ സൂക്ഷിക്കുക. അടുത്ത ആൾക്ക് രണ്ടും ആവശ്യമാണ്, jail-ന്റെ സാരാംശം ഒന്നും അവനോട് പറയുകയുമില്ല.