Potřebuji pomoc s určením některých chyb v mém auth.log soubor na mém serveru Ubuntu. Před několika týdny jsem našel množství pokusů o přihlášení k mému portu SSH (22) na auth.log , tak jsem změnil port SSH. Týden byl čistý a pak jsem našel další hromadu pokusů o přihlášení přes jiný port.
Dostávám mnoho duplikátů čar červeně (na obrázku). Opakující se řádky jsou následující:
saslauthd[1140]: pam_unix(smtp:auth): check pass; user unknown
saslauthd[1140]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
saslauthd[1140]: DEBUG: auth_pam: pam_authenticate failed: Authentication failure
saslauthd[1140]: do_auth : auth failure: [user=roselia] [service=smtp] [realm=mail.mydomain.com] [mech=pam] [reason=PAM auth error]
Mohu říci, že se pokoušejí přihlásit k mému poštovnímu serveru (protože sféra je mail.mydomain.com ), ale nemohu přesně říct, o co se snaží, protože nevím, co je PAM. Co je PAM? A co mám udělat, abych zastavil tyto pokusy o ověření na mém poštovním serveru (port 25)?
Občas také dostávám do mého auth.log nějaké protokoly CRON to souvisí s PAM a bylo by skvělé, kdyby mi někdo řekl, co to znamená:
CRON[32236]: pam_unix(cron:session): session opened for user root by (uid=0)
CRON[32235]: pam_unix(cron:session): session opened for user root by (uid=0)
CRON[32236]: pam_unix(cron:session): session closed for user root
CRON[32235]: pam_unix(cron:session): session closed for user root
Přijatá odpověď:
Za prvé, toto není neobvyklé vidět na poštovních serverech. Každý Mail Server na Internetu je vidí, pokud je port 25 vystaven webu. Dokonce i e-mailové brány a poštovní servery na mém pracovišti jsou zasaženy, proto mnoho z těchto pokusů se odfiltrují a zablokují je IDS/IPS (systém detekce/prevence narušení) na hranici sítě, který odkazuje na mnoho zdrojů OSINT (Open Source Intelligence) k vytvoření sady špatných IP založených na pověsti, které jsou blokováno. Některé z těchto sond projdou, ale když se o to pokusí, nejsou úspěšné.
S největší pravděpodobností to není cílená hrubá síla proti vašemu serveru, jsou to „skenery a sondy internetu“, které dělají svou věc každému serveru SMTP směřujícímu k internetu. Pravděpodobně se jedná o spamboty, kteří se pokoušejí prozkoumat otevřená relé, a pokud nenajdou otevřený přenos, pravděpodobně se pokusí získat přístup k účtům, aby mohli použít server SMTP jako přenos pošty. Nebo je to servisní skener, který se snaží zjistit, zda nemáte ve hře nějaká ‚slabá hesla‘, aby je mohli zneužít a následně zneužít váš server k odesílání vlastní pošty přes vaše poštovní servery.
Související:Chybí režim spánku v nabídce napájení a když stisknu tlačítko napájení notebooku?Dokud se budete řídit dalšími bezpečnostními postupy silných hesel, neumožňovat uživatelům přístup, pokud to nepotřebují atd., měli byste se řídit tím, že se nebudou nabourávat na váš server. Méně bych se staral o selhání autentizace a více by mě zajímalo, kdyby autentizace byla úspěšná.
Další možností zabezpečení je nastavení Fail2Ban, který bude fungovat tak, aby zakázal uživatele, ale ještě jsem to pořádně nezprovoznil a neměl jsem čas se v tom ponořit, aby můj poštovní server fungoval fail2ban a autobanoval IP adresy, pokud selžou. příliš mnohokrát). S tím však šlápněte na lehkou váhu, protože to může také blokovat vás pokud si nedáš pozor. (Jakmile budu mít ‚funkční‘ konfiguraci Fail2Ban, sdílím to jako komentář k této odpovědi, ale bylo složité přimět ji, aby se chovala tak, jak chci.)
Pokud jde o cron:session záznamy ve vašem auth.log , to je jen poznámka, že systémový cron démon běží cron úlohy z /etc/crontab , /etc/cron.{d,daily,hourly,monthly,weekly}/* a root uživatel crontab podle plánu nastaveného pro úlohy cron jako uživatel root (kde jsou crontab nastaveny tak, aby se spouštěly jako root ). Ty jsou obvykle v pořádku, za předpokladu, že skutečně zkontrolujete každý jednotlivý crontab pod účtem root, abyste se ujistili, že nic „špatného“ neběží automaticky jako root .