OpenVPN Access Server માટે Fail2ban ફિલ્ટર: real_ip અને જેલ

તમે કોમ્યુનિટી પોસ્ટમાંથી એક OpenVPN જેલ કોપી કરી, fail2ban ફરી શરૂ કર્યું, અને કોઈ પણ સરનામું ક્યારેય બ્લોક થતું નથી. કારણ લગભગ હંમેશા લોગ ફોર્મેટ જ છે: Access Server એ પ્રમાણીકરણ નિષ્ફળતાની લાઇનો લખતું નથી જે સ્ટોક ફિલ્ટર અપેક્ષા રાખે છે. ફિલ્ટરને અડકતા પહેલા ખાતરી કરો કે રેકોર્ડ જરાય છે, કારણ કે પેટર્ન તેની સાથે મેળ ખાઈ શકતું નથી જે સેવાએ ક્યારેય લોગ કર્યું નથી.

Access Server હોસ્ટ પર હું જે રનબુક અનુસરું છું: રેકોર્ડનો આકાર ખાતરી કરો, એક એન્કર્ડ અભિવ્યક્તિ લખો, તેને અસલ લોગ પર ચકાસો, પછી હુમલાનો ભોગ બનેલી સપાટી પ્રમાણે જેલ વિભાજિત કરો અને ચકાસો કે બ્લોક ફાયરવોલ સુધી પહોંચે છે.

ખાતરી કરો કે નિષ્ફળતાનો રેકોર્ડ છે

Access Server તેની પોતાની માળખાયેલ લાઇનો /var/log/openvpnas.log માં લખે છે, અને ક્લાયન્ટનું સરનામું syslog લાઇનની શરૂઆતમાં નહીં, પરંતુ અવતરણ ચિહ્નોમાં રહેલા real_ip ફીલ્ડમાં રહે છે. કોઈ પેટર્ન લખતા પહેલા જાણીતું નિષ્ફળ લોગિન શોધો:

grep -i 'LOG ERR' /var/log/openvpnas.log | tail -20

જો કંઈ દેખાય નહીં, તો લોગ સ્તર આગળનો શંકાસ્પદ છે. Access Server પાસે /usr/local/openvpn_as/etc/as.conf માં લોગ-ડેટાબેઝ ડિબગ સ્વિચ છે (DEBUG_LOGDB=1), અને તેને બદલ્યા પછી સેવા ફરી શરૂ કરવી પડે છે. તે સ્વિચને એવી નિદાન સેટિંગ તરીકે ગણો જે તમારી પેટર્ન મળ્યા પછી ફરી નીચે ઉતારવાની હોય, કાયમી રૂપરેખાંકન તરીકે નહીં.

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

real_ip પર એક ફિલ્ટર એન્કર કરો

અભિવ્યક્તિ સાંકડી રાખો. IP સરનામું ધરાવતી કોઈપણ લાઇન દાવો કરતું ફિલ્ટર લોકોને સામાન્ય ડિસ્કનેક્શન માટે બ્લોક કરશે, અને વ્યસ્ત સર્વર પર એકમાત્ર લક્ષણ એ છે કે વપરાશકર્તાઓ ફરિયાદ કરે છે કે લેપટોપ બંધ કરવા બદલ તેમને લૉક કરવામાં આવ્યા. ભૂલનો રેકોર્ડ દાવો કરો અને અવતરણ ચિહ્નો વચ્ચેનું સરનામું પકડો:

# /etc/fail2ban/filter.d/openvpnaccess.local
[Definition]
failregex = ^ .*LOG ERR.*"real_ip": "<HOST>".*
ignoreregex =

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

જ્યારે સપાટી પ્રમાણે ચોકસાઈની જરૂર હોય, ત્યારે એક જ લાઇનમાં સપાટીનો માર્કર (WEB_CLIENT, WEB_ADMIN અથવા VPN) માંગીને વધુ સાંકડું કરો. એક શબ્દમાં ભિન્ન ત્રણ ફિલ્ટર કરતાં ત્રણ પેટર્નવાળું એક ફિલ્ટર ઓડિટ કરવું સહેલું છે.

જેલ સક્રિય કરતા પહેલા અભિવ્યક્તિ ચકાસો

પ્રોડક્શન લોગ પર ન ચલાવ્યું હોય તેવું ફિલ્ટર ક્યારેય સક્રિય કરશો નહીં. દસ્તાવેજીકૃત પરીક્ષણ ફિલ્ટરને બે વાર પસાર કરે છે, એક વાર લોડ કરવા અને એક વાર લાગુ કરવા, અને ચૂકી ગયેલી લાઇનોનો અહેવાલ એ જ ભાગ છે જે વાંચવા લાયક છે:

fail2ban-regex --print-all-missed /var/log/openvpnas.log \
  /etc/fail2ban/filter.d/openvpnaccess.local \
  /etc/fail2ban/filter.d/openvpnaccess.local > missed.txt

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

લોગ મોટું હોય તો આ પરીક્ષણ નકલ પર કરો, અને કોઈપણ Access Server અપગ્રેડ પછી ફરી ચલાવો. લોગ ફોર્મેટ એ જ ઇન્ટરફેસ છે જેની સામે તમે મેળ કરો છો, અને તે સ્થિર API નથી.

જેલને સપાટી પ્રમાણે વિભાજિત કરો, ડીમન પ્રમાણે નહીં

એક Access Server ઘણી પ્રમાણીકરણ સપાટીઓ રજૂ કરે છે: 943/tcp પર ક્લાયન્ટ અને એડમિન વેબ ઇન્ટરફેસ, અને મોટાભાગની તૈનાતીમાં 1194/udp અથવા 443/tcp પર ટનલ. બધાને આવરી લેતી એક જ જેલ ટનલ પરના અનુમાનના પ્રયાસોને એવું સરનામું બ્લોક કરવા દે છે જે તમારો એડમિન માર્ગ પણ છે, અને છુપાવે છે કે કઈ સપાટી ખરેખર હુમલા હેઠળ છે. દરેક સપાટીને તેના પોતાના પોર્ટ અને થ્રેશોલ્ડ સાથે અલગ જેલ આપો:

# /etc/fail2ban/jail.d/openvpnaccess.local
[openvpnas-web-client]
enabled  = true
port     = 943
protocol = tcp
filter   = openvpnaccess
logpath  = /var/log/openvpnas.log
maxretry = 3
findtime = 10m
bantime  = 1h
[openvpnas-tunnel]
enabled  = true
port     = 443
protocol = udp
filter   = openvpnaccess
logpath  = /var/log/openvpnas.log
maxretry = 5
findtime = 10m
bantime  = 1h

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

બ્લોક, બેકએન્ડ અને આડઅસર ચકાસો

ફરી શરૂ કર્યા પછી, સ્ટેટસ આઉટપુટ એ સૌથી ઝડપી પુષ્ટિ છે કે જેલ અસ્તિત્વમાં છે અને ગણતરી કરે છે:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

પછી ખાતરી કરો કે બ્લોક તમે ખરેખર ચલાવો છો તે ફાયરવોલ સુધી પહોંચે છે, કારણ કે જે બેકએન્ડને કોઈ લાગુ કરતું નથી તેના માટે ગોઠવાયેલી જેલ કંઈ જ રક્ષણ આપતી નથી. iptables ક્રિયા સાથે સરનામાં જેલના નામવાળી ચેઇનમાં દેખાય છે (f2b-openvpnas-tunnel); nftables ક્રિયા સાથે તે fail2banના પોતાના ટેબલના સેટમાં આવે છે. ધારી લેવાને બદલે તમારો હોસ્ટ જે વાપરે છે તે તપાસો.

બે આડઅસર તપાસ બ્લોક કરતાં વધુ મહત્ત્વની છે. પ્રથમ, ચકાસો કે real_ip ક્લાયન્ટનું સરનામું છે અને લોડ બેલેન્સર કે રિવર્સ પ્રોક્સી નથી; પ્રોક્સી પાછળ દરેક બ્લોક પ્રોક્સી પર પડે છે અને આખી સેવાને સાથે લઈ જાય છે. બીજું, અનબ્લોક પ્રક્રિયા લખી રાખો, કારણ કે 02:00 વાગ્યે થ્રેશોલ્ડ વટાવતું સરનામું સામાન્ય રીતે ઓન-કૉલ એન્જિનિયરનું હોય છે: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

ટ્યુન કરતી વખતે સીમા ધ્યાનમાં રાખો. Fail2ban એક પ્રમાણીકરણ સપાટી પરનું રેટ લિમિટર છે, એક્સેસ કંટ્રોલ સ્તર નહીં. તે MFA, દરેક ખાતાના પ્રતિબંધો કે એડમિન ઇન્ટરફેસને જાહેર ઇન્ટરનેટથી દૂર રાખવાનું વિકલ્પ નથી, અને Access Server પાસે પોતાની autoban સેટિંગ્સ છે જે એક જ પોર્ટ પર બે રેટ લિમિટર ઢગલો કરતા પહેલા તપાસવા યોગ્ય છે.