web-dev-qa-db-ja.com

メールサーバーをターゲットとするログで多くのPAM認証エラーが発生します。どうすれば止められますか？

Ubuntuサーバー上のauth.logファイルのエラーを特定するのに助けが必要です。数週間前、auth.logのSSHポート（22）へのログイン試行が多すぎることがわかったため、SSHポートを変更しました。 1週間はきれいでしたが、別のポートを介して別のログイン試行が見つかりました。

PAM auth error

（画像内の）赤の行の複製がたくさんあります。繰り返し行は次のとおりです。

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]

彼らは私のメールサーバーにログインしようとしていると言うことができます（レルムはmail.mydomain.comであるため）。 PAMとは何ですか？また、メールサーバー（ポート25）でこれらの認証試行を停止するにはどうすればよいですか？

また、PAMに関連するauth.logでCRONログを取得することもありますが、これらの意味を誰かが教えてくれれば素晴らしいことです。

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
serversshauthenticationpam
4
terresquall

まず、これはメールサーバーで見られることは珍しくありません。 Everyポート25がWebに公開されている場合、インターネット上のメールサーバーはこれらを認識します。私の職場のメールゲートウェイとメールサーバーでさえこれらにヒットします。これらの試行の多くが除外され、ブロックされる理由は、IDS/IPS（Intrustion Detection/Prevention System）の境界にありますOSINT（オープンソースインテリジェンス）の多くのソースを参照するネットワーク。ブロックされたレピュテーションベースの不良IPセットを作成します。これらのプローブの一部は通過しますが、試行しても成功しません。

おそらく、それはサーバーに対する標的のブルートフォースではなく、「インターネットのスキャナーとプローブ」がすべてのインターネットに直接接続されたSMTPサーバーに対して処理を行うことです。これらはおそらく、オープンリレーをプローブしようとするスパムボットであり、オープンリレーが見つからない場合は、SMTPサーバーをメールリレーとして使用するためにアカウントにアクセスしようとする可能性があります。または、「弱いパスワード」が使用されているかどうかを確認しようとするサービススキャナーであり、彼らはそれらを悪用し、サーバーを悪用してメールサーバー経由で独自のメールを送信します。

ユーザーが必要でない限りユーザーにアクセスを許可しないなど、強力なパスワードの他のセキュリティ慣行に従っている限り、サーバーに侵入しないという観点で行ってください。私は認証の失敗についてはあまり気にせず、認証が成功した場合にはもっと気になります。

追加のセキュリティオプションは、ユーザーを禁止するために機能するFail2Banを設定することですが、これを適切に機能させるために、まだ失敗してIPを自動禁止するためにメールサーバーでfail2banを機能させるための時間がない何度も認証します）。ただし、注意しないとyoをブロックする可能性があるため、これを軽く踏んでください。 （「動作する」Fail2Ban構成ができたら、この回答へのコメントとして共有しますが、思い通りに動作させるのは難しいです）

cron:sessionのauth.logエントリについては、システムのcronデーモンが/etc/crontab、/etc/cron.{d,daily,hourly,monthly,weekly}/*からcronタスクを実行していることに注意してください、およびrootユーザーcrontab（cronユーザーがrootとして実行されるように設定されているcrontabがrootとして設定されている場合）。ルートアカウントですべてのcrontabを実際にチェックし、「[VARIABLE] _」として「悪い」ものが自動的に実行されていないことを確認すれば、通常は問題ありません。

9
Thomas Ward