એકાઉન્ટ લોક વિરુદ્ધ સરનામું પ્રતિબંધ: OpenVPN ખરેખર ક્યાં ગણે છે

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

PAM ને પ્રમાણીકરણ સોંપતા VPN માટે ગણતરી એ છે જ્યાં સુધી PAM સ્ટેક પહોંચે છે, શ્રોતાએ નોંધ્યું તે નહીં.

બે ગણતરીઓ, બે અલગ ભોગ

દર મર્યાદક સ્રોત જુએ છે અને પૂછે છે કે તાજેતરમાં ત્યાંથી કેટલા પ્રયાસો આવ્યા. લોક ઓળખ જુએ છે અને પૂછે છે કે તે એકાઉન્ટે કેટલી નિષ્ફળતાઓ એકઠી કરી. પ્રથમ સેવાની ઉપલબ્ધતા રક્ષે છે, બીજું ઓળખપત્ર રક્ષે છે; એક બીજાનું સ્થાન લેતું નથી.

તેથી પાંચ નિષ્ફળતા પછી અમે IP બ્લોક કરીએ છીએ એ વાક્ય ઓળખપત્ર ભરવાના અહેવાલનો જવાબ નથી. હુમલાખોર સ્રોત બદલે છે, દરેકને થોડા પ્રયાસો મળે છે અને એકાઉન્ટ ક્યારેય ગણાતું નથી. ઊલટું, સ્રોત નિયંત્રણ વગરનું લોક હુમલાખોરને જાણી જોઈને નિષ્ફળ થઈને એકાઉન્ટ અમર્યાદિત સમય લૉક રાખવા દે છે.

બંને નિયંત્રણોની પુનઃપ્રાપ્તિની વાર્તા પણ અલગ છે. સરનામા પ્રતિબંધ એવા ટાઈમર પર પૂરો થાય છે જેના વિશે કોઈએ વિચારવાની જરૂર નથી; એકાઉન્ટ લોકને વ્યવસ્થાપક, દસ્તાવેજીકૃત રાહ જોવાનો સમય અથવા સ્વ-સેવા રીસેટની જરૂર પડી શકે.

જે સંગ્રહસ્થાન પહેલેથી ગણતરી ધરાવે છે તે શોધો

કંઈ ઉમેરતા પહેલાં જાણો કે નિષ્ફળતાનું સંગ્રહસ્થાન પહેલેથી છે કે નહીં. સ્થાનિક Linux એકાઉન્ટ, ડિરેક્ટરી સેવા અને બાહ્ય ઓળખ પ્રદાતા દરેક પોતાની ગણતરી રાખે છે, અને તેમની સામે મૂકેલું PAM મોડ્યુલ પ્રથમને વિસ્તારવાને બદલે બીજું બનાવે છે.

grep -rnE 'faillock|pam_tally|pam_unix' /etc/pam.d/
ls -l /etc/pam.d/ | head -20

VPN ખરેખર જે સેવા ફાઈલનું નામ આપે છે તે વાંચો અને તેની સમાવેશ લાઈનો અનુસરો. ઘણા વિતરણોમાં VPN સેવા સામાન્ય ફાઈલ સમાવે છે, એટલે તમે ગોઠવો છો તે ગણતરી SSH અને સ્થાનિક લૉગિનને પણ લાગુ પડે છે.

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

pam_faillock માં એક નહીં, ત્રણ કૉલ સ્થાનો છે

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

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

faillock --user alice
faillock --user alice --reset

નિરીક્ષણ સાધન એ જોવાનો સૌથી ઝડપી રસ્તો છે કે ગણતરી ખરી છે કે નહીં: તે એકાઉન્ટની નોંધાયેલી નિષ્ફળતાઓ દર્શાવે છે અને તેમને સાફ કરી શકે છે. જો નિયંત્રિત નિષ્ફળતા તે આઉટપુટ બદલતી નથી, તો કૉલનું સ્થાન ખોટું છે.

સમર્પિત સેવા નામ અલગીકરણ નથી

VPN ને પોતાની PAM સેવા ફાઈલ આપવી ઇચ્છિત નીતિને દૃશ્યમાન બનાવે છે, પણ અસરને મર્યાદિત કરતી નથી. સામાન્ય ફાઈલનો કોઈ પણ સમાવેશ તે ફાઈલ જે કરે છે તે લાવે છે, આખી સિસ્ટમ માટેની ગણતરીઓ સહિત.

સ્પષ્ટ નક્કી કરો કે લોક ફક્ત VPN ઍક્સેસ આવરે છે કે તે જ એકાઉન્ટને પ્રમાણિત કરતી દરેક સેવા. બંને જવાબ વાજબી છે; ભૂલ એ છે કે તમે એક પસંદ કર્યું એમ માનવું જ્યારે સ્ટેક બીજું અમલમાં મૂકે છે.

પછી ખર્ચ ધ્યાનમાં લો. હુમલાખોર લોક ઉપજાવી શકે છે, અને ત્રાસ પામતો વપરાશકર્તા એ એકાઉન્ટનો માલિક છે. થ્રેશોલ્ડ, રાહ જોવાનો સમય અને વ્યવસ્થાપક પુનઃપ્રાપ્તિ માર્ગ નીતિનો ભાગ છે, અને પુનઃપ્રાપ્તિ ઘટના દરમિયાન VPN ફરી ગોઠવવા પર આધારિત ન હોવી જોઈએ.

ક્રમ સ્વીકારો, એક અસ્વીકાર નહીં

મંજૂર યોજના હેઠળ નિયુક્ત ઓળખ સાથે પરીક્ષણ કરો, અને એક ઘટના નહીં પણ સાંકળનું પરીક્ષણ કરો: માન્ય એકાઉન્ટ પ્રમાણિત થાય, જાણી જોઈને ખોટો પાસવર્ડ ગણતરી ખસેડે, ગોઠવેલું લોક અમલમાં આવે અને દસ્તાવેજી પુનઃપ્રાપ્તિ ઍક્સેસ પાછી આપે.

faillock --user test-vpn-01
journalctl -u openvpn-server@lab -n 30 --no-pager | grep -i 'auth\|pam'

સફળતાના વર્તનને નિષ્ફળતા જેટલા ધ્યાનથી જુઓ. જો સફળ લૉગિન ઇતિહાસ સાફ ન કરે, તો સામાન્ય ભૂલોના ધીમા સંચય પછી એકાઉન્ટ લૉક થશે. જો દરેક સેવામાંથી બધું સાફ કરે, તો ગણતરી નીતિ કહે તેના કરતાં નબળી છે.

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