Siz OpenVPN cəllini icma paylaşımından kopyaladınız, fail2ban-ı yenidən başlatdınız və heç bir ünvan heç vaxt bloklanmır. Səbəb demək olar ki, həmişə log formatıdır: Access Server standart filtrin gözlədiyi autentifikasiya xətası sətirlərini yazmır. Filtri dəyişməzdən əvvəl qeydlərin ümumiyyətlə mövcud olduğunu təsdiqləyin, çünki şablon xidmətin heç vaxt yazmadığı şeyə uyğun gələ bilməz.

Bu, Access Server hostunda tətbiq etdiyim runbook-dur: qeydin formasını təsdiqlə, bir ankrajlı ifadə yaz, onu real loga qarşı sına, sonra cəlləri hücuma məruz qalan səthə görə ayır və blokun firewall-a çatdığını yoxla.

Xəta qeydinin mövcud olduğunu təsdiqləyin

Access Server öz strukturlaşdırılmış sətirlərini /var/log/openvpnas.log faylına yazır və müştəri ünvanı syslog sətrinin başında deyil, dırnaq içindəki real_ip sahəsindədir. Hər hansı şablon yazmazdan əvvəl bildiyiniz uğursuz girişi axtarın:

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

Heç nə görünmürsə, növbəti şübhəli log səviyyəsidir. Access Server-in /usr/local/openvpn_as/etc/as.conf faylında log verilənlər bazası üçün debug açarı var (DEBUG_LOGDB=1), və dəyişdirildikdən sonra xidmət yenidən başladılmalıdır. Bu açarı şablonunuz hazır olduqdan sonra yenidən aşağı salınacaq diaqnostik parametr kimi qəbul edin, daimi konfiqurasiya kimi yox.

Faylda olarkən hansı səthlərin ora yazdığını qeyd edin. Müştəri portalının, admin interfeysinin və tunel autentifikasiyasının xətaları eyni fayla düşür, lakin müxtəlif markerlərlə, və bu detallar sonradan cəl düzümünü müəyyən edir.

Bir filtri real_ip üzərində ankrajlayın

İfadəni dar saxlayın. IP ünvanı olan hər sətri iddia edən filtr insanları adi bağlantı kəsilmələrinə görə bloklayacaq və məşğul serverdə yeganə simptom istifadəçilərin noutbuku bağladıqları üçün kilidləndiklərindən şikayət etməsi olacaq. Xəta qeydini iddia edin və dırnaq içindəki ünvanı tutun:

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

Başdakı boşluq kosmetik deyil. Access Server qeydlərini girintiləyir və ona ankraj qurmaq şablonun eyni fayla yazan əlaqəsiz xidmətlərin sətirlərini də iddia etməsinin qarşısını alır. Qeydlərinizdə bunun əvəzinə başda zaman damğası varsa, həmin prefiksə uyğunlaşdırın, lakin iddia etmək istədiyiniz hər qeyddə həqiqətən mövcud olan bir şeyə ankraj qurun.

Səth üzrə dəqiqlik lazım olduqda, səth markerini (WEB_CLIENT, WEB_ADMIN və ya VPN) eyni sətirdə tələb edərək daha da daraldın. Üç şablonlu bir filtr bir sözlə fərqlənən üç filtrdən daha asan yoxlanılır.

İfadəni cəl aktivləşdirməzdən əvvəl sınayın

İstehsal loguna qarşı işlətmədiyiniz filtri heç vaxt aktivləşdirməyin. Sənədləşdirilmiş sınaq filtri iki dəfə ötürür, biri yükləmək, biri tətbiq etmək üçün, və buraxılmış sətirlər hesabatı oxumağa dəyər hissədir:

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

Uyğunluq sayını birinci addımda təsdiqlədiyiniz xətalar ilə müqayisə edin. Sıfır uyğunluq şablonun səhv olduğunu bildirir; autentifikasiya xətası olmayan sətirlərdə uyğunluqlar onun çox geniş olduğunu bildirir. missed.txt faylını iddia etməməyi seçdiyiniz hər sətri izah edə bilənə qədər oxuyun.

Log böyükdürsə bu sınağı surətdə edin və hər Access Server yenilənməsindən sonra təkrarlayın. Log formatı uyğunlaşdırdığınız interfeysdir və sabit API deyil.

Cəlləri daemon-a görə deyil, səthə görə ayırın

Bir Access Server bir neçə autentifikasiya səthi təqdim edir: 943/tcp üzərində müştəri və admin veb interfeysləri, əksər quraşdırmalarda isə 1194/udp və ya 443/tcp üzərində tunel. Hamısını əhatə edən tək bir cəl tuneldəki təxmin cəhdlərinin sizin admin yolunuz olan ünvanı bloklamasına imkan verir və hansı səthin həqiqətən hücuma məruz qaldığını gizlədir. Hər səthə öz portu və hədləri olan ayrı cəl 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

Kiçik sayğaclarla və qısa blokla başlayın, bir həftə real trafik izlədikdən sonra onları artırın. Ortaq ofis ünvanında səxavətli hədd bir NAT arxasındakı hər istifadəçini cəzalandırır və tunel səthində aqressiv blok yadda saxlanmış etimadnamələri gecə ərzində bitmiş qanuni müştərilərin bağlantısını kəsir.

Bloku, backend-i və yan təsirləri yoxlayın

Yenidən başlatmadan sonra status çıxışı cəlin mövcud olduğunu və saydığını təsdiqləyən ən sürətli vasitədir:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Sonra blokun həqiqətən işlətdiyiniz firewall-a çatdığını təsdiqləyin, çünki heç kimin tətbiq etmədiyi backend üçün qurulmuş cəl heç nəyi qorumur. iptables fəaliyyəti ilə ünvanlar cəlin adını daşıyan zəncirdə görünür (f2b-openvpnas-tunnel); nftables fəaliyyəti ilə fail2ban-ın öz cədvəlindəki çoxluğa düşür. Fərziyyə etmək əvəzinə hostunuzun istifadə etdiyini yoxlayın.

İki yan yoxlama blokun özündən daha vacibdir. Birincisi, real_ip sahəsinin müştəri ünvanı olduğunu, yük balanslaşdırıcısı və ya tərs proksi olmadığını yoxlayın; proksinin arxasında hər blok proksiyə düşür və bütün xidməti özü ilə birlikdə çökdürür. İkincisi, blokdan çıxarma prosedurunu yazın, çünki 02:00-da həddi aşan ünvan adətən növbətçi mühəndisə aiddir: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Tənzimləmə zamanı sərhədi yadda saxlayın. Fail2ban bir autentifikasiya səthində sürət məhdudlaşdırıcısıdır, girişə nəzarət qatı deyil. O, MFA-nı, hesab üzrə məhdudiyyətləri və ya admin interfeysini açıq internetdən kənarda saxlamağı əvəz etmir, və Access Server-in eyni porta iki sürət məhdudlaşdırıcısı yığmazdan əvvəl yoxlamağa dəyər öz autoban parametrləri var.

Əlaqəli məqalələr