毎日モザイク

画像は、恩賜のthinkpadX61ﾀﾝのCPU温度使用率のグラフ。LAN内のホスト名はBCRichで統一したので、これはbichです。

ひとつめ。金曜日の山。

swatchでiptablesにDROP項目を挿入するたびにアラートメールを出す設定にしていたところに、秒速20回前後（連続アクセスは緩めに設定してある）の総当たり攻撃が来て、気がついたときには、面倒くさいから数えなかったけど、自分宛に概ね1万通弱のメールを送ってしまった山……。

早めに気がついて、この程度で済みました……。

正規アカウントが当たってしまったときのために、$mydmainとかのユーザでも配送制限を付けてあるので、捌き切るのに小一時間かかりました。

制限に引っかかっているだけなので、資源は余裕ですから、自分宛を捨ててしまえばいいんですが、ざっと見たら自分宛のキューしかなかったので、いい機会だから、こうなったらどうなるのかを見届けて見ましたw

atのキューも1万件ちかくありましたが、放っときました。

こちらも、挿入後1時間の設定だったので、2時間後に見たときにはにはきれいさっぱり。

「設定次第でメールの山に見舞われる」という解説が書いてあるところが多いですが、「山」はせいぜい数百だろうwwwwとか思ってたら、余裕で万越えます……。

二つ目。土曜日の山。

これも、アホ丸出しw。

clamAVの定時スキャンのホワイトリストに~/.gvfs/を入れていなかったため、マウントしているサーバを延々スキャンし続けたというw

こちらは負荷が低い（CPU usageで40/200程度）ので、全然気づかず、土曜日で人も少ないのでサーバの負荷も問題になるほどにはならず、ほとんど一日中やってました。

自分を信じず、有人監視大事……。

にアップデートしたら、ubuntu系ゲスト全滅のお知らせw

カーネルモジュールは入りますが、/sbin/mount.vboxsfなんかが入らない。

ubuntuは/sbin/mount.vboxsfのリンクは出来ていますが、リンク先の/usr/lib64/以下にguestadditionsが入らないようです。

mintはリンク先の/usr/lib/以下に入ってない。

ホストと共有できないゲストはだいぶ不便っていうか、普段の用途からすると、まるで用をなさない状態に……。

redhat系ゲストは大丈夫っぽい。

キーチェーンアクセスに以下の条件で登録。

属性

• 名前：SSH: /Users/omaenonamae/.ssh/id_rsa
• 種類：アプリケーションパスワード
• 場所：SSH

アクセス制御

• これらのアプリケーションによるアクセスを常に許可
• ssh
• ssh-add
• ssh-agent

名前のところが、SSH:で始まるフルパスでないとログイン時にssh-addに登録されない。

場所もSSHじゃないとダメっぽい。

以上の条件を満たせば、ログイン時にssh-addに登録されて、キーチェーンアクセスに登録した全ての秘密鍵が使える。

ssh関連をssh-agentに投げるfilezillaみたいなのを使うには、こうしておかないと面倒くさい。

また勝ってしまったw（負けてるけど……）

0398-3700-0051

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

こちらも、もう通りません。

トラブルがないと設定を見直すことがないし、後から変更したのを忘れてたりするから、何かやったら必ず書いていくことにしよう。