Utracono połączenie Postfix po AUTH

12

Przeglądając dzienniki na moich serwerach pocztowych, zauważyłem następujące wiadomości:

Nov 29 12:09:38 mta postfix/smtpd[8362]: connect from unknown[183.13.165.14]
Nov 29 12:09:39 mta postfix/smtpd[8362]: lost connection after AUTH from unknown[183.13.165.14]
Nov 29 12:09:39 mta postfix/smtpd[8362]: disconnect from unknown[183.13.165.14]
Nov 29 12:09:39 mta postfix/smtpd[8409]: connect from unknown[183.13.165.14]
Nov 29 12:09:40 mta postfix/smtpd[8409]: lost connection after AUTH from unknown[183.13.165.14]
Nov 29 12:09:40 mta postfix/smtpd[8409]: disconnect from unknown[183.13.165.14]

W tych przypadkach nie ma awarii SASL. Istnieją awarie SASL są rejestrowane w innym czasie, ale nigdy nie lost connection after AUTH.

Co się tutaj dzieje i czy powinienem coś z tym zrobić?
To nie są MX-y i już zostały smtpd_client_connection_rate_limitustawione.

Możliwe powiązanie:
systemy wymagają SMTPS lub STARTTLS przed ogłoszeniem AUTH.

postfix 84104
źródło
Czy możesz zwiększyć poziom debugowania postfiksa?
Khaled
Mogę, ale dzięki temu pliki dziennika będą rosły znacznie szybciej, a te zdarzenia są sporadyczne. Co to zwiększone rejestrowanie pomoże jednoznacznie?
84104
1
Tak więc musisz go zwiększyć przez krótki czas i kiedy spodziewasz się tego błędu. Mam nadzieję, że daje to więcej wskazówek na temat tego błędu.
Khaled

Odpowiedzi:

9

To jest botnet z Chin łączący się z twoim urządzeniem próbującym dostarczyć spam. Ale bot jest zbyt głupi, aby wiedzieć, co zrobić, gdy każe mu się uwierzytelnić. Bot po prostu przestaje dostarczać pocztę, a następnie rozłącza się w celu zaatakowania następnej ofiary.

Absolutnie nie ma się czym martwić.

mailq
źródło
3
Wystarczająco blisko. Wygląda na to, że jest to jakiś skrypt, który wydaje AUTH i wychodzi nieczysto po otrzymaniu 503 5.5.1 Error: authentication not enabled. Był w stanie replikować się za pomocą ncat. Jednak dlaczego wciąż próbuje, dopóki nie osiągnie limitu prędkości, jest poza mną. Może próbuje brutalnie wymusić pary nazwa użytkownika / hasło? Tak czy inaczej, zbyt głupio, zbyt się martwię.
84104
2
W ramach testu dostaję tylko ten wiersz do moich dzienników i nigdy nie widzę żadnych awarii SASL tylko przy użyciu Thunderbirda i nieprawidłowego hasła do znanego konta. Ponieważ uwierzytelniona poczta zawsze przechodzi bez przeszkód przez Postfix, poprawną odpowiedzią jest, jeśli to możliwe, użycie opublikowanego skryptu fail2ban w celu ograniczenia do minimum liczby prób użycia siły. Próby użycia hasła „brute force” to absolutna obawa, aby uniknąć przekształcenia skrzynki w otwarty przekaźnik - szczególnie jeśli jest to jedyna linia w logach.
CubicleSoft,
Dzienniki wyglądają, jakby dostawał jedną sekundę, co może oznaczać, że ktoś próbuje brutalnie zmusić serwer, co JEST czymś, o co należy się martwić. Zalecam używanie przynajmniej fail2ban. Nie rozwiąże to całkowicie problemu brutalnej siły, ale znacznie go złagodzi.
Severun
21

Moje pliki dziennika były zapełniane i marnowanie procesora pozwala nawet na połączenie z tych szarpnięć. Stworzyłem fail2banregułę.

Jul 11 02:35:08 mail postfix/smtpd[16299]: lost connection after AUTH from unknown[196.12.178.73]

Zawartość /etc/fail2ban/jail.conf

[postfix]
# Ban for 10 minutes if it fails 6 times within 10 minutes
enabled  = true
port     = smtp,ssmtp
filter   = postfix
logpath  = /var/log/mail.log
maxretry = 6
bantime  = 600
findtime = 600

Zawartość /etc/fail2ban/filter.d/postfix.conf

# Fail2Ban configuration file
#
# Author: Cyril Jaquier
#
# $Revision$
#

[Definition]

# Option:  failregex
# Notes.:  regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)
# Values:  TEXT
#

# Jul 11 02:35:08 mail postfix/smtpd[16299]: lost connection after AUTH from unknown[196.12.178.73]

failregex = lost connection after AUTH from unknown\[<HOST>\]

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =
the7erm
źródło
2
To uratowało mi dzień. Dodałem następujące zasady: failregex = ^%(__prefix_line)slost connection after AUTH from \S+\[<HOST>\].$. W ciągu kilku minut miałem wiele setek takich prób połączenia. Musiałem coś z tym zrobić.
chmike
Jest to nieco bardziej ogólne:failregex = lost connection after AUTH from (.*)\[<HOST>\]
CubicleSoft,
@chmike: Kropka przed końcem $musi zostać usunięta. Nie działało tutaj z tym w wyrażeniu regularnym.
cweiske
3

W takim smtpd_recipient_restrictionszestawie reject_unknown_client_hostname:

smtpd_recipient_restrictions = reject_unknown_client_hostname

a to spowoduje odrzucenie klientów i zbłąkane lub głupie boty zombie o nieznanych nazwach hostów. Twoje dzienniki będą wyglądać tak, gdy ustawione:

postfix/smtpd[11111]: NOQUEUE: reject: RCPT from unknown[183.13.165.14]: 450 4.7.1 Client host rejected: cannot find your hostname, [183.13.165.14]
Pan
źródło
Odpowiedź na to (bardzo stare) pytanie jest już zaakceptowana.
BE77Y
1
Nieznana nazwa hosta była / nie jest problemem. lost connection after AUTHbył / jest.
84104
1
Ich problem brzmi: „Co się tutaj dzieje i czy powinienem coś z tym zrobić?” I to jest całkowicie poprawna odpowiedź.
inorganik
2

Nie jestem pewien, czy jest wiele powodów do zmartwień, w zasadzie klient / „ktoś” łączy się, wydaje AUTH i rozłącza się z własnej woli. Może to być próba sprawdzenia możliwości serwera z klienta pocztowego - lub próba przywrócenia ważności demona.

Tak długo, jak masz wystarczające bezpieczeństwo, to tylko kolejne pukanie do drzwi ze świata.

cienki lód
źródło
Nawet jeśli zdarzy się to 3 lub 4 razy z rzędu?
Alexis Wilke,