auth.logのエラーを特定するのに助けが必要です 私のUbuntuサーバー上のファイル。数週間前、auth.logのSSHポート（22）へのログイン試行が多数見つかりました。 、SSHポートを変更しました。 1週間はきれいでしたが、その後、別のポートからのログイン試行が何度も見つかりました。
（画像の）赤の線の重複がたくさんあります。繰り返し行は次のとおりです。
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が何であるかわからないため、彼らが何をしようとしているのか正確にはわかりません。 PAMとは何ですか？また、メールサーバー（ポート25）でこれらの認証の試行を停止するにはどうすればよいですか？
また、auth.logでCRONログを取得することもあります。 これはPAMに関連しているので、誰かがこれらの意味も教えてくれれば素晴らしいと思います。
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
承認された回答：
まず、これはメールサーバーで見られることは珍しくありません。 すべて ポート25がWebに公開されている場合、インターネット上のメールサーバーはこれらを認識します。私の職場のメールゲートウェイやメールサーバーでさえ、これらに見舞われています。その理由は多く これらの試みのうち、フィルターで除外されてブロックされるのは、ネットワークの境界にあるIDS / IPS（Intrustion Detection / Prevention System）であり、OSINT（オープンソースインテリジェンス）の多くのソースを参照して、評判ベースの不正なIPのセットを作成します。ブロックされました。これらのプローブの一部は通過しますが、試行しても成功しません。
おそらく、それはサーバーに対する標的型の総当たり攻撃ではなく、インターネットに直接接続されているすべてのSMTPサーバーに対して「インターネットのスキャナーとプローブ」が機能しているのです。これらはおそらくオープンリレーをプローブしようとしているスパムボットであり、オープンリレーが見つからない場合は、SMTPサーバーをメールリレーとして使用するためにアカウントへのアクセスを試みてプローブしている可能性があります。または、サービススキャナーが、「弱いパスワード」が使用されているかどうかを確認して、パスワードを悪用し、サーバーを悪用してメールサーバー経由で独自のメールを送信できるようにします。
関連：電源メニューに休止状態がありません。ラップトップの電源ボタンを押すとどうなりますか？強力なパスワードの他のセキュリティ慣行に従い、ユーザーが必要としない限りユーザーにアクセスを許可しないなどの限り、サーバーに侵入しないという点でうまくいくはずです。認証の失敗についてはあまり気にせず、認証が成功したかどうかについてはもっと気になります。
追加のセキュリティオプションは、ユーザーを禁止するように機能するFail2Banを設定することですが、これはまだ正しく機能しておらず、メールサーバーが失敗した場合にIPを自動禁止するためにfail2banを機能させるためにそれを掘り下げる時間がありませんでした何度も認証する）。 あなたをブロックすることもできるので、これで軽く踏みます 注意しないと（「機能する」Fail2Ban構成ができたら、それをこの回答へのコメントとして共有しますが、希望どおりに動作させるのは難しいです）
cron:sessionについて auth.logのエントリ 、これはシステムのcronに注意してください。 デーモンはcronを実行しています /etc/crontabからのタスク 、/etc/cron.{d,daily,hourly,monthly,weekly}/* 、およびroot rootユーザーとしてcronジョブに設定されたスケジュールごとのユーザーcrontab（crontabはrootとして実行するように設定されています） ）。ルートアカウントの下にあるすべてのcrontabを実際にチェックして、rootとして「悪い」ものが自動的に実行されていないことを確認すれば、通常は問題ありません。 。