監視対象の設定。
swatchでdovecotの総当たり攻撃対策をしていたつもりが、どうも引っ掛かりが悪い。
もっといっぱい来てるはずなのに、iptablesでブロックされる回数が少なすぎる……。
と思って、ログをよく見たら、あれでした。
dovecot: last message repeated 10 times
今までは、/var/log/mail.logを見てたんですが、dovecotが出すログだと、認証エラーは
dovecot: pop3-login: Aborted login (auth failed, 1 attempts):
だけで、20秒以内に他のログが挟まらないと、syslogdにlast messsage repeat n timesに置き換えられてしまう。
利用者数名の低稼働サーバではあんばい悪すぎ。
ubuntuのログ設定はインストール時から弄ってないので、他にdovecotのログが出るのは/var/log/syslog,/var/log/auth.log。
/var/log/syslogも/var/log/mail.logとdovecotについては同じ内容が出るので、他のログが挟まらないと置き換えられてしまう。
/var/log/auth.logは
auth: pam_unix(dovecot:auth): check pass; user unknown
auth: pam_unix(dovecot:auth): authentication failure;と、ユーザが存在しなければ必ず2行出る。
それでも、存在するユーザ名が当たって、短時間でパスワード変更のみのアクセスがあると置き換えられますが、ユーザ名パスワードの組み合わせを順次変えていくのが一番多いので引っかけ率は格段に上がるはず。
利用者が内外で数百人程度の会社で借りてるサーバでも、last message repeat n timesが出るタイミングがあったりするくらいだから、簡単な手口でこのくらい引っかけられればいい方だろう。
と、ここまで書いて思い出した……。
STARTTLS以外では認証しない設定にしたはずで、実際にテストしても、クリアテキストでは認証は通らない。
なんでログを吐いているんだろう……。
と、思ったけど、思い出したw
STARTTLSに対応していない古いクライアントがあったんで、あとからクリアテキストも許可したんだった。しかも、01-mail-stack-delivery.confは最初に思いついた通り、STARTTLSだけになってて、10-auth.confの方を修正してクリアテキストを通してあるという間抜けな設定……。
当然といえば当たり前ですが、postfixのほうも、STARTTLSのみにしたあとでコメントアウトし、クリアテキスト許可にしてあったw
こちらも、もう通りません。
トラブルがないと設定を見直すことがないし、後から変更したのを忘れてたりするから、何かやったら必ず書いていくことにしよう。
