VPN ગેટવે પર Fail2ban: શું સુધારે છે અને શું નહીં

દરેક ખુલ્લી સેવાને એ જ સલાહ મળે છે: તેના પર fail2ban મૂકો. VPN ગેટવે માટે આ સલાહ ન તો ખોટી છે ન તો પૂરતી, અને તેને હાર્ડનિંગની ટિક તરીકે ગણવો એ જ રીતે લોકો એવા jail સાથે રહી જાય છે જે કંઈ ઉપયોગી બ્લોક કરતું નથી. Fail2ban તમે જે નિષ્ફળતા રેકોર્ડ તરફ તેને દોરો છો તે વાંચે છે અને અમલ બેકએન્ડને મેળ ખાતા સ્રોતો પ્રતિબંધિત કરવા કહે છે. તેનું આખું મૂલ્ય એના પર છે કે કઈ પ્રમાણીકરણ સપાટીએ રેકોર્ડ બનાવ્યો, તેમાંનું સરનામું ખરેખર ક્લાયન્ટ છે કે નહીં, અને તે સરનામા પાછળના બાકીના બધાનું શું થાય છે.

યાંત્રિક રીતે fail2ban શું છે

ફિલ્ટર લોગની લાઇનો મેળવે છે, jail સ્રોત પ્રમાણે મેળ ગણે છે, અને ક્રિયા ફાયરવોલ બેકએન્ડ દ્વારા પ્રતિબંધ લાગુ કરે છે. ત્રણ ચલ ભાગ, અને દરેક સ્વતંત્ર રીતે ખોટો હોઈ શકે.

ત્રણમાંથી કોઈ પ્રમાણીકરણ માર્ગને સ્પર્શતું નથી: fail2ban ઘટના પછી પુરાવા પર પ્રતિક્રિયા આપે છે અને ક્યારેય પોતે ઓળખપત્ર ચકાસતું નથી. તેથી jail સ્વચ્છ રીતે ચાલી શકે છે જ્યારે તે જે સપાટીનું નામ લે છે તે પહેલાં જેટલી ખુલ્લી છે તેટલી જ રહે છે.

ટનલ શ્રોતા લોગિન ફોર્મ નથી

OpenVPN શ્રોતા જો tls-auth કે tls-crypt થી સુરક્ષિત હોય, તો સામાન્ય TLS પ્રક્રિયા શરૂ થાય તે પહેલાં નિયંત્રણ-ચેનલ સુરક્ષા વગરના પેકેટ ફેંકી દે છે. જે સ્કેનર પાસે ક્યારેય કી નથી હોતી તે તમારું ફિલ્ટર ગણી શકે એવું કંઈ ઉત્પન્ન કરતું નથી. પ્રમાણપત્ર પ્રમાણીકરણ બીજું દરવાજો ઉમેરે છે, કારણ કે અનુમાન કરવા જેવો પાસવર્ડ નથી. Fail2ban પ્રોજેક્ટ સામાન્ય લોગ-આધારિત મોડેલનું દસ્તાવેજીકરણ કરે છે, અને સામાન્ય VPN ફિલ્ટર અપ્રમાણિત પેકેટને અર્થપૂર્ણ નિષ્ફળતા ઘટનામાં ફેરવતું નથી.

જો ગેટવે ફક્ત પ્રમાણપત્રો સ્વીકારે છે, તો તમે જે બ્રૂટ-ફોર્સ વાર્તા સામે બચાવ કરો છો તે તે પોર્ટ પર બિલકુલ ન હોઈ શકે.

તો તમે કઈ સપાટીનું રક્ષણ કરો છો?

એ જ હોસ્ટ ઘણી વાર ત્રણ અલગ વસ્તુઓ ખોલે છે: ટનલ શ્રોતા, ક્લાયન્ટ-પ્રોફાઇલ કે સ્વ-સેવા પોર્ટલ, અને વ્યવસ્થાપન પૃષ્ઠ. પોર્ટલ અને એડમિન પૃષ્ઠમાં પાસવર્ડ ફોર્મ હોય છે અને ફિલ્ટર ગણી શકે એવી લોગ લાઇનો ઉત્પન્ન કરે છે. ટનલ કદાચ ફક્ત હેન્ડશેક ભૂલો ઉત્પન્ન કરે છે જેનો અર્થ સાવ બીજો હોય છે. jail ને ઉત્પાદનના નામ સાથે નહીં, સપાટી સાથે મેળવો.

ખોટો લોગ જોતું એક jail કોઈ jail ન હોવા કરતાં ખરાબ છે, કારણ કે તે કવરેજ વગર આત્મવિશ્વાસ પેદા કરે છે. લોગિન ફિલ્ટરને ટનલની હેન્ડશેક ભૂલો તરફ દોરો અને કાઉન્ટર એ સ્કેનરો પર વાગશે જેમની પાસે ક્યારેય કી નહોતી, જ્યારે પોર્ટલ સામેનો પાસવર્ડ હુમલો ગણાશે નહીં. jail ના આંકડા પર ભરોસો કરતાં પહેલાં ફિલ્ટર જે લોગ લાઇન મેળવે છે તે વાંચો.

સ્રોતનું આરોપણ એ નબળી કડી છે

પ્રતિબંધ તેટલો જ સારો છે જેટલું તેનું લક્ષ્ય સરનામું. જ્યારે સેવા સ્થાનિક રિવર્સ પ્રોક્સી પાછળ હોય, ત્યારે લોગમાંનું ક્લાયન્ટ સરનામું પ્રોક્સી હોઈ શકે, અને તેને પ્રતિબંધિત કરવાથી બધા નીકળી જાય છે. અવિશ્વસનીય સ્રોતમાંથી આવેલા ફોરવર્ડેડ હેડર પર ભરોસો કરવાથી હુમલાખોરને મનસ્વી સરનામાં પ્રતિબંધિત કરવાની ક્ષમતા મળે છે. UDP માં સ્રોત સરનામાં બનાવટી બનાવી શકાય છે, તેથી તેમને ગણવા પૂર્ણ થયેલા TCP લોગિનને ગણવા કરતાં વધુ કાળજી માંગે છે.

jail ના README માં સ્રોત આરોપણની પદ્ધતિ નોંધો, કારણ કે અવિશ્વસનીય હોપમાંથી આવેલો ફોરવર્ડેડ હેડર પ્રતિબંધને શસ્ત્રમાં ફેરવે છે.

આડી કિંમત બીજા લોકો છે

એક ઓફિસ NAT પાછળના ઘણા કર્મચારીઓ એક સરનામું વહેંચે છે, તેથી એક જૂનો સંગ્રહિત પાસવર્ડ થ્રેશોલ્ડ વટાવાતાં આખી ઓફિસને લૉક કરી શકે છે. લોગ એક સ્રોત અને એક ખાતું બતાવે છે જે નિષ્ફળ ગયા, આખી ઓફિસનું વિરામ નહીં.

ટૂંકા પ્રતિબંધો અને સંતુલિત થ્રેશોલ્ડ તેને ઘટાડે છે, અને દસ્તાવેજીકૃત અનબેન માર્ગ તો પણ થાય ત્યારે સહાયક ભાર ઘટાડે છે. સરનામું એક સ્થૂળ સંકેત, ઓળખ નહીં છે, અને ટિકિટ ખોલનાર વ્યક્તિ થ્રેશોલ્ડ નહીં, વિરામનું વર્ણન કરશે.

ક્યારે અપનાવવું, અને ક્યારે બીજું કંઈ સુધારવું

જ્યારે તમે નિયંત્રિત કરો છો તેવી સપાટી પર સાચી, આરોપી શકાય તેવી, પુનરાવર્તિત ઓનલાઇન લોગિન નિષ્ફળતા હોય, અને અમલ બેકએન્ડ ખરેખર તે સપાટીને આવરી લે ત્યારે તેને અપનાવો. જ્યારે સમસ્યા નબળી ઓળખપત્ર નીતિ, ઇન્ટરનેટ પર ખુલ્લું વ્યવસ્થાપન પૃષ્ઠ, કે સમાધાન થયું હોવાથી સફળતાપૂર્વક લોગિન થતું ખાતું હોય ત્યારે બીજું કંઈ સુધારો. પ્રતિબંધ એમાંનું કંઈ સુધારી શકતો નથી અને તમારા અપલિંકને પહેલેથી સંતૃપ્ત કરી ચૂકેલા ટ્રાફિકને શોષી પણ શકતો નથી. એ છેલ્લી સમસ્યા ઉપરવાસની છે, એવા કોઈની જે પેકેટ તમારા સુધી પહોંચે તે પહેલાં ફિલ્ટર કરી શકે.

દરેક jail ને એક સપાટી સાથે બાંધેલું રાખો, ખોટા પોઝિટિવની સમીક્ષા કરો, અને પ્રતિબંધિત સરનામાંની સંખ્યાને બદલે ટાળેલા પ્રમાણીકરણ કાર્યને માપો.