OpenVPN Access Server ਲਈ Fail2ban ਫਿਲਟਰ: real_ip ਅਤੇ jail

ਤੁਸੀਂ ਕਮਿਊਨਿਟੀ ਪੋਸਟ ਤੋਂ ਇੱਕ OpenVPN jail ਕਾਪੀ ਕੀਤਾ, fail2ban ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕੀਤਾ, ਅਤੇ ਕੋਈ ਵੀ ਪਤਾ ਕਦੇ ਬਲੌਕ ਨਹੀਂ ਹੁੰਦਾ। ਕਾਰਨ ਲਗਭਗ ਹਮੇਸ਼ਾ ਲੌਗ ਫਾਰਮੈਟ ਹੁੰਦਾ ਹੈ: Access Server ਉਹ ਪ੍ਰਮਾਣੀਕਰਨ-ਅਸਫਲਤਾ ਲਾਈਨਾਂ ਨਹੀਂ ਲਿਖਦਾ ਜਿਨ੍ਹਾਂ ਦੀ ਸਟਾਕ ਫਿਲਟਰ ਉਮੀਦ ਕਰਦਾ ਹੈ। ਫਿਲਟਰ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਰਿਕਾਰਡ ਮੌਜੂਦ ਹਨ ਵੀ, ਕਿਉਂਕਿ ਪੈਟਰਨ ਉਸ ਚੀਜ਼ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾ ਸਕਦਾ ਜੋ ਸੇਵਾ ਨੇ ਕਦੇ ਲੌਗ ਨਹੀਂ ਕੀਤੀ।

ਇਹ ਉਹ ਰਨਬੁੱਕ ਹੈ ਜੋ ਮੈਂ Access Server ਹੋਸਟ 'ਤੇ ਅਪਣਾਉਂਦਾ ਹਾਂ: ਰਿਕਾਰਡ ਦੀ ਸ਼ਕਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਇੱਕ ਐਂਕਰ ਕੀਤੀ ਸਮੀਕਰਨ ਲਿਖੋ, ਇਸਨੂੰ ਅਸਲ ਲੌਗ 'ਤੇ ਪਰਖੋ, ਫਿਰ ਹਮਲੇ ਵਾਲੀ ਸਤ੍ਹਾ ਅਨੁਸਾਰ jail ਵੰਡੋ ਅਤੇ ਜਾਂਚੋ ਕਿ ਬਲੌਕ ਫਾਇਰਵਾਲ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ।

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਅਸਫਲਤਾ ਦਾ ਰਿਕਾਰਡ ਮੌਜੂਦ ਹੈ

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), ਅਤੇ ਇਸਨੂੰ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਸੇਵਾ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨੀ ਪੈਂਦੀ ਹੈ. ਉਸ ਸਵਿੱਚ ਨੂੰ ਇੱਕ ਨਿਦਾਨ ਸੈਟਿੰਗ ਵਜੋਂ ਲਵੋ ਜੋ ਪੈਟਰਨ ਤਿਆਰ ਹੋਣ 'ਤੇ ਦੁਬਾਰਾ ਹੇਠਾਂ ਲਾਹੁਣੀ ਹੈ, ਸਥਾਈ ਸੰਰਚਨਾ ਵਜੋਂ ਨਹੀਂ।

ਫਾਈਲ ਵਿੱਚ ਹੁੰਦਿਆਂ ਨੋਟ ਕਰੋ ਕਿ ਕਿਹੜੀਆਂ ਸਤ੍ਹਾਵਾਂ ਇਸ ਵਿੱਚ ਲਿਖਦੀਆਂ ਹਨ। ਕਲਾਇੰਟ ਪੋਰਟਲ, ਐਡਮਿਨ ਇੰਟਰਫੇਸ ਅਤੇ ਟਨਲ ਪ੍ਰਮਾਣੀਕਰਨ ਦੀਆਂ ਅਸਫਲਤਾਵਾਂ ਇੱਕੋ ਫਾਈਲ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਮਾਰਕਰਾਂ ਨਾਲ ਆਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਉਹ ਵੇਰਵਾ ਬਾਅਦ ਵਿੱਚ jail ਦਾ ਖਾਕਾ ਤੈਅ ਕਰਦਾ ਹੈ।

real_ip 'ਤੇ ਇੱਕ ਫਿਲਟਰ ਐਂਕਰ ਕਰੋ

ਸਮੀਕਰਨ ਨੂੰ ਤੰਗ ਰੱਖੋ। IP ਪਤਾ ਵਾਲੀ ਹਰ ਲਾਈਨ ਦਾ ਦਾਅਵਾ ਕਰਨ ਵਾਲਾ ਫਿਲਟਰ ਲੋਕਾਂ ਨੂੰ ਆਮ ਡਿਸਕਨੈਕਟ ਲਈ ਬਲੌਕ ਕਰੇਗਾ, ਅਤੇ ਰੁੱਝੇ ਸਰਵਰ 'ਤੇ ਲੈਪਟਾਪ ਬੰਦ ਕਰਨ ਕਾਰਨ ਲੌਕ ਹੋਣ ਦੀ ਉਪਭੋਗਤਾ ਸ਼ਿਕਾਇਤ ਹੀ ਇਕੋ ਨਿਸ਼ਾਨ ਹੁੰਦੀ ਹੈ। ਅਸਫਲਤਾ ਦੇ ਰਿਕਾਰਡ ਦਾ ਦਾਅਵਾ ਕਰੋ ਅਤੇ ਹਵਾਲਾ ਚਿੰਨ੍ਹਾਂ ਵਾਲਾ ਪਤਾ ਫੜੋ:

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

ਸ਼ੁਰੂਆਤੀ ਖਾਲੀ ਥਾਂ ਸਜਾਵਟ ਨਹੀਂ ਹੈ। Access Server ਆਪਣੇ ਰਿਕਾਰਡ ਅੰਦਰ ਖਿਸਕਾਉਂਦਾ ਹੈ, ਅਤੇ ਇਸ 'ਤੇ ਐਂਕਰ ਕਰਨ ਨਾਲ ਪੈਟਰਨ ਉਸੇ ਫਾਈਲ ਵਿੱਚ ਲਿਖਣ ਵਾਲੀਆਂ ਅਸੰਬੰਧਿਤ ਸੇਵਾਵਾਂ ਦੀਆਂ ਲਾਈਨਾਂ ਦਾ ਦਾਅਵਾ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਜੇ ਤੁਹਾਡੇ ਰਿਕਾਰਡਾਂ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਇਸਦੀ ਥਾਂ ਸਮਾਂ-ਛਾਪ ਹੈ, ਤਾਂ ਉਸ ਅਗੇਤਰ ਨੂੰ ਮਿਲਾਓ, ਪਰ ਉਸ ਚੀਜ਼ 'ਤੇ ਐਂਕਰ ਕਰੋ ਜੋ ਤੁਸੀਂ ਦਾਅਵਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਹਰ ਰਿਕਾਰਡ ਵਿੱਚ ਸੱਚਮੁੱਚ ਮੌਜੂਦ ਹੈ।

ਜਦੋਂ ਸਤ੍ਹਾ ਅਨੁਸਾਰ ਸ਼ੁੱਧਤਾ ਲੋੜੀਂਦੀ ਹੋਵੇ, ਉਸੇ ਲਾਈਨ ਵਿੱਚ ਸਤ੍ਹਾ ਮਾਰਕਰ (WEB_CLIENT, WEB_ADMIN ਜਾਂ VPN) ਮੰਗ ਕੇ ਹੋਰ ਤੰਗ ਕਰੋ। ਇੱਕ ਸ਼ਬਦ ਨਾਲ ਵੱਖਰੇ ਤਿੰਨ ਫਿਲਟਰਾਂ ਨਾਲੋਂ ਤਿੰਨ ਪੈਟਰਨ ਵਾਲਾ ਇੱਕ ਫਿਲਟਰ ਜਾਂਚਣਾ ਸੌਖਾ ਹੈ।

jail ਸਮਰੱਥ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਮੀਕਰਨ ਪਰਖੋ

ਪ੍ਰੋਡਕਸ਼ਨ ਲੌਗ 'ਤੇ ਨਾ ਚਲਾਇਆ ਫਿਲਟਰ ਕਦੇ ਸਮਰੱਥ ਨਾ ਕਰੋ। ਦਸਤਾਵੇਜ਼ੀ ਪਰੀਖਿਆ ਫਿਲਟਰ ਨੂੰ ਦੋ ਵਾਰ ਪਾਸ ਕਰਦੀ ਹੈ, ਇੱਕ ਵਾਰ ਲੋਡ ਕਰਨ ਲਈ ਅਤੇ ਇੱਕ ਵਾਰ ਲਾਗੂ ਕਰਨ ਲਈ, ਅਤੇ ਖੁੰਝੀਆਂ ਲਾਈਨਾਂ ਦੀ ਰਿਪੋਰਟ ਹੀ ਪੜ੍ਹਨ ਯੋਗ ਹਿੱਸਾ ਹੈ:

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 ਨਹੀਂ ਹੈ।

jail ਸਤ੍ਹਾ ਅਨੁਸਾਰ ਵੰਡੋ, ਡੈਮਨ ਅਨੁਸਾਰ ਨਹੀਂ

ਇੱਕ Access Server ਕਈ ਪ੍ਰਮਾਣੀਕਰਨ ਸਤ੍ਹਾਵਾਂ ਪੇਸ਼ ਕਰਦਾ ਹੈ: 943/tcp 'ਤੇ ਕਲਾਇੰਟ ਅਤੇ ਐਡਮਿਨ ਵੈੱਬ ਇੰਟਰਫੇਸ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਤੈਨਾਤੀਆਂ ਵਿੱਚ 1194/udp ਜਾਂ 443/tcp 'ਤੇ ਟਨਲ। ਸਭ ਨੂੰ ਢਕਣ ਵਾਲਾ ਇੱਕ jail ਟਨਲ 'ਤੇ ਅੰਦਾਜ਼ੇ ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਉਹ ਪਤਾ ਬਲੌਕ ਕਰਨ ਦਿੰਦਾ ਹੈ ਜੋ ਤੁਹਾਡਾ ਐਡਮਿਨ ਰਸਤਾ ਵੀ ਹੈ, ਅਤੇ ਇਹ ਲੁਕਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਸਤ੍ਹਾ 'ਤੇ ਸੱਚਮੁੱਚ ਹਮਲਾ ਹੋ ਰਿਹਾ ਹੈ। ਹਰ ਸਤ੍ਹਾ ਨੂੰ ਆਪਣੇ ਪੋਰਟ ਅਤੇ ਸੀਮਾ ਵਾਲਾ ਵੱਖਰਾ jail ਦਿਓ:

# /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 ਪਿੱਛੇ ਹਰ ਉਪਭੋਗਤਾ ਨੂੰ ਸਜ਼ਾ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਟਨਲ ਸਤ੍ਹਾ 'ਤੇ ਹਮਲਾਵਰ ਬਲੌਕ ਰਾਤੋ-ਰਾਤ ਮਿਆਦ ਪੁੱਗੇ ਸੰਗ੍ਰਹਿਤ ਪ੍ਰਮਾਣ ਵਾਲੇ ਜਾਇਜ਼ ਕਲਾਇੰਟਾਂ ਨੂੰ ਡਿਸਕਨੈਕਟ ਕਰਦਾ ਹੈ।

ਬਲੌਕ, backend ਅਤੇ ਮਾੜੇ ਪ੍ਰਭਾਵ ਜਾਂਚੋ

ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਸਥਿਤੀ ਆਉਟਪੁੱਟ ਸਭ ਤੋਂ ਤੇਜ਼ ਪੁਸ਼ਟੀ ਹੈ ਕਿ jail ਮੌਜੂਦ ਹੈ ਅਤੇ ਗਿਣ ਰਿਹਾ ਹੈ:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਬਲੌਕ ਉਸ ਫਾਇਰਵਾਲ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਚਲਾਉਂਦੇ ਹੋ, ਕਿਉਂਕਿ ਜਿਸ backend ਨੂੰ ਕੋਈ ਲਾਗੂ ਨਹੀਂ ਕਰਦਾ ਉਸ ਲਈ ਬਣਾਇਆ jail ਕੁਝ ਵੀ ਨਹੀਂ ਬਚਾਉਂਦਾ। iptables ਕਾਰਵਾਈ ਨਾਲ ਪਤੇ jail ਦੇ ਨਾਮ ਵਾਲੀ ਚੇਨ ਵਿੱਚ ਦਿਸਦੇ ਹਨ (f2b-openvpnas-tunnel); nftables ਕਾਰਵਾਈ ਨਾਲ ਉਹ fail2ban ਦੀ ਆਪਣੀ ਸਾਰਣੀ ਦੇ ਸੈੱਟ ਵਿੱਚ ਆਉਂਦੇ ਹਨ। ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਜੋ ਤੁਹਾਡਾ ਹੋਸਟ ਵਰਤਦਾ ਹੈ ਉਹ ਜਾਂਚੋ।

ਦੋ ਮਾੜੇ-ਪ੍ਰਭਾਵ ਜਾਂਚਾਂ ਬਲੌਕ ਤੋਂ ਵੀ ਜ਼ਰੂਰੀ ਹਨ। ਪਹਿਲਾ, ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ real_ip ਕਲਾਇੰਟ ਦਾ ਪਤਾ ਹੈ ਅਤੇ ਲੋਡ ਬੈਲੰਸਰ ਜਾਂ ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਨਹੀਂ; ਪ੍ਰੌਕਸੀ ਪਿੱਛੇ ਹਰ ਬਲੌਕ ਪ੍ਰੌਕਸੀ 'ਤੇ ਪੈਂਦਾ ਹੈ ਅਤੇ ਪੂਰੀ ਸੇਵਾ ਨੂੰ ਨਾਲ ਲੈ ਡੁੱਬਦਾ ਹੈ। ਦੂਜਾ, ਅਨਬਲੌਕ ਕਾਰਵਾਈ ਲਿਖ ਕੇ ਰੱਖੋ, ਕਿਉਂਕਿ 02:00 ਵਜੇ ਸੀਮਾ ਲੰਘਣ ਵਾਲਾ ਪਤਾ ਆਮ ਤੌਰ 'ਤੇ ਡਿਊਟੀ ਵਾਲੇ ਇੰਜੀਨੀਅਰ ਦਾ ਹੁੰਦਾ ਹੈ: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24।

ਟਿਊਨ ਕਰਦਿਆਂ ਸੀਮਾ ਯਾਦ ਰੱਖੋ। Fail2ban ਇੱਕ ਪ੍ਰਮਾਣੀਕਰਨ ਸਤ੍ਹਾ 'ਤੇ ਦਰ ਸੀਮਕ ਹੈ, ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਪਰਤ ਨਹੀਂ। ਇਹ MFA, ਪ੍ਰਤੀ-ਖਾਤਾ ਪਾਬੰਦੀਆਂ ਜਾਂ ਐਡਮਿਨ ਇੰਟਰਫੇਸ ਨੂੰ ਜਨਤਕ ਇੰਟਰਨੈੱਟ ਤੋਂ ਦੂਰ ਰੱਖਣ ਦਾ ਬਦਲ ਨਹੀਂ ਹੈ, ਅਤੇ Access Server ਦੀਆਂ ਆਪਣੀਆਂ autoban ਸੈਟਿੰਗਾਂ ਹਨ ਜੋ ਇੱਕੋ ਪੋਰਟ 'ਤੇ ਦੋ ਦਰ ਸੀਮਕ ਢੇਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚਣ ਯੋਗ ਹਨ।