OpenVPN Access Server için Fail2ban filtresi: real_ip ve jail

Access Server kendi günlük biçimini yazar, bu yüzden hazır filtreler hiçbir şey bulamaz. real_ip üzerine sabitleyin, jail'leri yüzeye göre ayırın ve adresin proxy olmadığını doğrulayın.

Bir topluluk gönderisinden OpenVPN jail kopyaladınız, fail2ban'ı yeniden başlattınız ve hiçbir adres asla engellenmiyor. Nedeni neredeyse her zaman günlük biçimi: Access Server, hazır bir filtrenin beklediği kimlik doğrulama hatası satırlarını yazmıyor. Filtreye dokunmadan önce kayıtların gerçekten var olup olmadığını doğrulayın, çünkü bir desen hizmetin hiç kaydetmediği bir şeyle eşleşemez.

Access Server ana bilgisayarında izlediğim çalışma kitabı şudur: kaydın biçimini doğrula, tek bir sabitlenmiş ifade yaz, gerçek günlükte dene, sonra jail'leri saldırıya uğrayan yüzeye göre ayır ve engellemenin güvenlik duvarına ulaştığını doğrula.

Hata kaydının var olduğunu doğrulayın

Access Server kendi yapılandırılmış satırlarını /var/log/openvpnas.log dosyasına yazar ve istemci adresi syslog satırının başında değil, tırnak içindeki real_ip alanında bulunur. Herhangi bir desen yazmadan önce gerçekleştiğini bildiğiniz başarısız bir oturum açmayı arayın:

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

Hiçbir şey görünmezse sıradaki şüpheli günlük düzeyidir. Access Server'ın /usr/local/openvpn_as/etc/as.conf içinde günlük veritabanı hata ayıklama anahtarı vardır (DEBUG_LOGDB=1), ve değiştirdikten sonra hizmetin yeniden başlatılması gerekir. Bu anahtarı, deseniniz hazır olduğunda yeniden düşürülecek bir tanılama ayarı olarak görün, kalıcı bir yapılandırma olarak değil.

Dosyadayken hangi yüzeylerin ona yazdığını not edin. İstemci portalı, yönetim arayüzü ve tünel kimlik doğrulaması hataları aynı dosyaya farklı işaretlerle düşer ve bu ayrıntı jail düzenini sonradan belirler.

real_ip üzerinde bir filtre sabitleyin

İfadeyi dar tutun. IP adresi içeren her satırı sahiplenen bir filtre, insanları sıradan bağlantı kopmaları yüzünden engeller ve yoğun bir sunucuda tek belirti, kullanıcıların dizüstü bilgisayar kapattıkları için kilitlendiklerinden şikâyet etmesidir. Hata kaydını sahiplenin ve tırnak içindeki adresi yakalayın:

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

Baştaki boşluk kozmetik değildir. Access Server kayıtlarını içeri doğru kaydırır ve buna sabitlenmek, desenin aynı dosyaya yazan ilgisiz hizmetlerin satırlarını da sahiplenmesini engeller. Kayıtlarınız bunun yerine başta bir zaman damgası taşıyorsa o öneki eşleştirin, ancak sahiplenmeyi düşündüğünüz her kayıtta gerçekten bulunan bir şeye sabitlenin.

Yüzey başına kesinlik gerektiğinde, aynı satırda yüzey işaretini (WEB_CLIENT, WEB_ADMIN veya VPN) isteyerek daha da daraltın. Üç desenli tek bir filtre, tek kelimeyle ayrılan üç filtreden daha kolay denetlenir.

Bir jail'i etkinleştirmeden önce ifadeyi test edin

Üretim günlüğüne karşı çalıştırmadığınız bir filtreyi asla etkinleştirmeyin. Belgelenen test, filtreyi iki kez geçirir; biri yüklemek, biri uygulamak için, ve kaçırılan satırlar raporu okumaya değer kısımdır:

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

Eşleşme sayısını ilk adımda doğruladığınız hatalarla karşılaştırın. Sıfır eşleşme, desenin yanlış olduğu anlamına gelir; kimlik doğrulama hatası olmayan satırlardaki eşleşmeler ise çok geniş olduğu anlamına gelir. Sahiplenmemeyi seçtiğiniz her satırı açıklayabilene kadar missed.txt dosyasını okuyun.

Günlük büyükse bu testi bir kopyada yapın ve her Access Server yükseltmesinden sonra yineleyin. Günlük biçimi eşleştirdiğiniz arayüzdür ve kararlı bir API değildir.

Jail'leri yüzeye göre ayırın, daemon'a göre değil

Bir Access Server birkaç kimlik doğrulama yüzeyi sunar: 943/tcp üzerinde istemci ve yönetici web arayüzleri, çoğu kurulumda tünel ise 1194/udp veya 443/tcp üzerinde. Hepsini kapsayan tek bir jail, tüneldeki tahmin denemelerinin yönetici yolunuz da olan bir adresi engellemesine izin verir ve hangi yüzeyin gerçekten saldırı altında olduğunu gizler. Her yüzeye kendi bağlantı noktası ve eşikleriyle ayrı bir jail verin:

# /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

Küçük sayaçlar ve kısa bir engellemeyle başlayın, bir hafta gerçek trafiği izledikten sonra bunları yükseltin. Paylaşılan bir ofis adresindeki cömert bir eşik, tek bir NAT arkasındaki her kullanıcıyı cezalandırır ve tünel yüzeyindeki saldırgan bir engelleme, kayıtlı kimlik bilgileri gece boyunca süresi dolan meşru istemcilerin bağlantısını keser.

Engellemeyi, backend'i ve yan hasarı doğrulayın

Yeniden başlatmadan sonra durum çıktısı, jail'in var olduğunu ve saydığını doğrulayan en hızlı yoldur:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Ardından engellemenin gerçekten işlettiğiniz güvenlik duvarına ulaştığını doğrulayın, çünkü kimsenin uygulamadığı bir backend için yapılandırılmış jail hiçbir şeyi korumaz. iptables eyleminde adresler jail'in adını taşıyan bir zincirde görünür (f2b-openvpnas-tunnel); nftables eyleminde fail2ban'ın kendi tablosundaki bir kümede yer alırlar. Varsaymak yerine ana bilgisayarınızın kullandığını denetleyin.

İki yan etki denetimi engellemenin kendisinden daha önemlidir. Birincisi, real_ip alanının istemci adresi olduğunu, yük dengeleyici veya ters proxy olmadığını doğrulayın; bir proxy arkasında her engelleme proxy'ye düşer ve tüm hizmeti beraberinde götürür. İkincisi, engeli kaldırma prosedürünü yazın, çünkü 02:00'de eşiği aşan adres genellikle nöbetçi mühendise aittir: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Ayarlarken sınırı aklınızda tutun. Fail2ban tek bir kimlik doğrulama yüzeyinde bir hız sınırlayıcıdır, bir erişim denetimi katmanı değildir. MFA'nın, hesap başına kısıtlamaların veya yönetim arayüzünü genel internetin dışında tutmanın yerini almaz ve Access Server'ın, aynı bağlantı noktasına iki hız sınırlayıcı yığmadan önce denetlemeye değer kendi autoban ayarları vardır.

İlgili makaleler