Fail2Ban: już zbanowany?

Mam Fail2Ban uruchomiony na moim Centos Server. (Konfiguracja poniżej)

W moim var / log / messages zauważyłem coś naprawdę dziwnego:

Jun 19 12:09:32 localhost fail2ban.actions: INFO   [postfix] 114.43.245.205 already banned

Skonfigurowałem Fail2Ban, aby dodać zablokowany adres IP do iptables.

Moje jail.conf:

[postfix]

enabled  = true
filter   = postfix
action   = iptables
port     = smtp,ssmtp
filter   = postfix
logpath  = /var/log/maillog
bantime  = 43200
maxretry = 2

Mój postfix.conf:

[INCLUDES]

before = common.conf

[Definition]
failregex = reject: RCPT from (.*)\[<HOST>\]: 550 5.1.1
            reject: RCPT from (.*)\[<HOST>\]: 450 4.7.1
            reject: RCPT from (.*)\[<HOST>\]: 554 5.7.1
            reject: RCPT from (.*)\[<HOST>\]: (.*)@yahoo.com.tw
ignoreregex =

Moje pytanie brzmi: w jaki sposób ktoś, kto został już zablokowany, może iptablesnadal łączyć się z serwerem?

Ponowne więzienie zalecane w innej odpowiedzi tutaj nie rozwiązało problemu. W końcu jednak to naprawiłem, więc oto moja metoda na wypadek, gdyby pomogła innym.

Fail2ban domyślnie blokuje tylko TCP. Przynajmniej z moją konfiguracją zauważyłem, że komunikat „już zbanowany” pojawił się, gdy boty wróciły, aby zamiast tego spróbować zablokowanego portu przez UDP.

Aby rozwiązać ten problem, powiedz Fail2ban, aby zablokował port dla wszystkich protokołów zamiast tylko TCP. Musisz wprowadzić tę zmianę w /etc/fail2ban/jail.conf oraz w sekcji [Init] każdej akcji, której używasz na /etc/fail2ban/action.d/ .

Zmień to:

# Default protocol
protocol = tcp

Do:

# Default protocol
protocol = all

Następnie wyłączyłem żądania echa ICMP, więc zablokowane adresy IP nie mogły uzyskać dostępu do serwera:

1. nano /etc/sysctl.conf

2. Dodaj te dwie linie:

   net.ipv4.icmp_echo_ignore_all = 1  
   net.ipv4.icmp_echo_ignore_broadcasts = 1
   

3. Wyjdź i zapisz plik.
4. Uruchom sysctl -p, aby zmiana zaczęła obowiązywać.

Następnie uruchom przeładowanie klienta fail2ban i nie powinieneś już widzieć tych „już zbanowanych” wiadomości, chyba że zostaniesz spamowany przez IP, który dostanie kilka prób dostępu, zanim blok zacznie obowiązywać.

Ważne jest również, aby zablokować wszystkie porty dla każdego przestępcy, a nie port, do którego próbowano uzyskać dostęp, używając akcji iptables-allports w każdym z Jailów. W przeciwnym razie mogą wywołać kolejne Więzienie i skończyć jako „już zbanowane” w dziennikach.

Jeśli spojrzysz na wynik iptables-save, zobaczysz, że fail2banłańcuchy są skonfigurowane, więc oceniają pakiety zgodnie z regułami określonymi przez filtry, na przykład:

:fail2ban-ssh - [0:0]
-A INPUT -p tcp -A INPUT -p tcp -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh 
-A fail2ban-ssh -j RETURN

Ruch nadal dociera do serwera, zanim zostaną zastosowane inne reguły routingu, a ruch zostanie odrzucony. fail2banwciąż widzi ten początkowy ruch i dlatego widzisz komunikaty „już zbanowane”. Ponadto istnieje specjalny filtr dla recidivists ( /etc/fail2ban/filter.d/recidive.conf):

# Fail2Ban filter for repeat bans
#
# This filter monitors the fail2ban log file, and enables you to add long
# time bans for ip addresses that get banned by fail2ban multiple times.
#
# Reasons to use this: block very persistent attackers for a longer time,
# stop receiving email notifications about the same attacker over and
# over again.
#
# This jail is only useful if you set the 'findtime' and 'bantime' parameters
# in jail.conf to a higher value than the other jails. Also, this jail has its
# drawbacks, namely in that it works only with iptables, or if you use a
# different blocking mechanism for this jail versus others (e.g. hostsdeny
# for most jails, and shorewall for this one).

[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# common.local
before = common.conf

[Definition]

_daemon = fail2ban\.server\.actions

# The name of the jail that this filter is used for. In jail.conf, name the
# jail using this filter 'recidive', or change this line!
_jailname = recidive

failregex = ^(%(__prefix_line)s| %(_daemon)s%(__pid_re)s?:\s+)WARNING\s+\[(?!%(_jailname)s\])(?:.*)\]\s+Ban\s+<HOST>\s*$

[Init]

journalmatch = _SYSTEMD_UNIT=fail2ban.service PRIORITY=4

# Author: Tom Hendrikx, modifications by Amir Caspi

Stanie się tak, jeśli zabroniony adres IP nie jest faktycznie adresem IP klienta łączącego się z serwerem. Np. Jeśli twój serwer znajduje się za modułem równoważenia obciążenia lub serwerem proxy.

Ostatnio zajęło mi to trochę czasu. Czerwony śledź polegał na tym, że dzienniki zostały skonfigurowane do przechwytywania X-Forwarded-Foradresu IP zamiast rzeczywistego adresu źródłowego, który w moim przypadku był modułem równoważącym obciążenie.

W tym przypadku fail2ban nie jest zbyt pomocny, ponieważ zakazanie obrażającego adresu IP spowoduje zablokowanie całego ruchu.

Chcę przyczynić się do rozwiązania mojego problemu za pomocą wiadomości „już zbanowanych”. Jak pisałeś, miałem ich setki w ciągu kilku minut, podczas gdy napastnik powinien był zostać już zbanowany.

Zanim zacznę, oto mój system:

• Plesk 12
• Centos 7
• Moduł Plesk zainstalowany, działający i konfigurujący dla mnie fail2ban

Kiedy zainstalowałem OpenVPN na moim serwerze root, przełączyłem firewalld na iptables. Mogło to spowodować dla mnie ten problem, ale poza tym mój system był w większości nietknięty i całkiem świeżo zainstalowany (Strato rootserver sugerował instalację obrazu).

Jeśli masz ten problem, sprawdź /etc/fail2ban/jail.d/00-firewalld.conf dla linii, która wygląda następująco:

banaction = firewallcmd-ipset

Od momentu, kiedy to skomentowałem, zapisałem plik i uruchomiłem ponownie fail2ban.service, wszystko było w porządku z fail2ban. Żadnych więcej wiadomości

Nie jestem ekspertem, ale mam nadzieję udzielić właściwej odpowiedzi. Jeśli to Ci odpowiada, daj mi znać!

Moje pytanie brzmi: w jaki sposób ktokolwiek, kto został już zablokowany w iptables, może nadal łączyć się z serwerem?

Połączył się z serwerem tylko jeden raz, ale w tym jednym połączeniu próbował dostarczyć wiele e-maili do prawdopodobnie nieistniejących skrzynek pocztowych (takich jak info@domain.com, sales@domain.com, tech@domain.com itp.)

Skonfigurowałeś filtr Postfiksa, aby blokować te próby, aby IP został zbanowany po X próbach. Klient może być już odłączony od Postfixa, ale ponieważ postfix nie zakończył przetwarzania całej swojej wiadomości e-mail, fail2ban może wykryć kolejną próbę od tego samego klienta, gdy postfix przetwarza pocztę, a zatem adres wiadomości jest już zbanowany. Wynika to z tego, jak działa kolejka Postfix.

Moje pytanie brzmi: w jaki sposób ktokolwiek, kto został już zablokowany w iptables, może nadal łączyć się z serwerem?

Niesamowite dobre pytanie. Szukałem, czy moje reguły zapory nie działają, ale są iptables --list-rulesdokładnie dopasowane do innego serwera produkcyjnego z działającym fail2ban.

Pomysłowym rozwiązaniem było dodanie portu 8080 do zablokowanych portów, ponieważ nadal uzyskiwałem dostęp do strony logowania przez porty programistyczne.

Więc poprawką w mojej sytuacji jest to, że ten problem był dość prostą adaptacją mojego jail.local:

[JIRA-LOGIN-tcp]
  enabled = true
  port = http,https,8080
  protocol = tcp
  filter = JIRA-LOGIN-ERROR
  logpath = /var/atlassian/application-data/jira/log/atlassian-jira-security.log
  bantime = 600
  maxretry = 1

patrz /unix//a/525798/22315

prawdopodobnie brakuje portu 587 w wierszu „port =” i można sprawdzić plik konfiguracyjny Postfiksa lub wykonać polecenie „lsof -i: 587”, aby dowiedzieć się bezpośrednio, czy Postfix został skonfigurowany do otwierania tego portu.