毎日モザイク

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

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

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

連続稼働しているUbuntuは、cron.dailyが午前6時25分に動く。

この中にaptが入っているので、午前6時25分に起動していなかった機械はアップデートの機会が遅れる。

とかいうことはない。

デスクトップ版には最初からanacronが入っているので、起動時にそれまでの分のcronが実行されていなかったら、起動5分後から再試行を始める。

cronの実行時間

proftpd ubuntu12.04標準。

認証はauth_file.cでバーチャルユーザのみ。

ユーザの利用目的は、webサイト更新

/etc/proftpd/proftpd.conf
#sftpでwelcome.msgを探せなくなるのを直すのが面倒くさいのでコメントアウト
- DisplayLogin                    welcome.msg
+ # DisplayLogin                    welcome.msg
# ファイル名変更で読み込ませたり、止めたり
- Include /etc/proftpd/conf.d/
+ Include /etc/proftpd/conf.d/*.conf

/etc/proftpd/conf.d/sftp.conf

<Limit Login>
    order allow,deny
    allow from 127.0.0.1 #wordpressの自動更新とかのためにlocalhostだけ素のFTP許可。
    DenyAll
</Limit>

 <IfModule mod_sftp.c>
    <VirtualHost xxx.xxx.xxx.xxx> #proftpd はipアドレスのみなので、ifconfigで出るやつを入れる
        <Limit login>
           AllowAll　#sftpはどこからでも許可。制限はiptablesまかせ。
        </Limit>
        SFTPEngine              on
        port                    2222 #sshと分けるため、お好みの空いてるポートで開けてるポート。sftpのみにするなら、元々開けてある21にすると楽かも。
        DefaultRoot             ~/　　#デフォルトルートはsftpでも効くのでべんり
        AllowOverwrite          on
        SFTPLog                 /var/log/proftpd/sftp.log　#log取る
        SFTPHostKey             /etc/ssh/ssh_host_dsa_key　#sshのhostkey。下も
        SFTPHostKey             /etc/ssh/ssh_host_rsa_key
        SFTPAuthorizedUserKeys  file:/path/to/keyfile/%u #%uはユーザ名に展開されるので、ユーザの公開鍵ファイル名をユーザ名に
        SFTPAuthMethods         publickey password　#鍵がなければパスワード
        AuthUserFile        /path/to/virtual/user/proftpd_userfile #バーチャルユーザにも使えます。
        AuthGroupFile       /path/to/virtual/user/proftpd_groupfile
    </VirtualHost>
</IfModule>

inetd,xinetd経由なら、次の接続から。standaloneなら再起動。

鍵形式について

proftpdのmod_sftp.cが読めるのは、RFC 4716形式のみ。

linuxで一般的な、openssh形式のままでは読めないので、変換しないといけない。

公式を読まないとハマりがちなところ。

鍵置き場について。

公開鍵がなければFTPにアクセスできないわけですから、最初に公開鍵をユーザが自分で設置することはできません。管理者がユーザを追加する時に入れることになります。

一般的な ~/.ssh/公開鍵ファイル に置けば、バーチャルユーザをディレクトリごと削除する時に鍵ごと削除できて楽。

ただ、.ssh以下をユーザの所有にしてしまうと、消されたりしたら面倒。管理者の所有にすれば、管理者しか変更できない。

結局管理者が管理することになるので、別の場所にまとめて管理するのが無難かも。

今回はwebサイト用のディレクトリなので、ドットものが増えてウザので、別ディレクトリで管理するのが便利。

鍵かパスワードか

鍵認証最強伝説も、秘密鍵が手に入れば、パスフレーズなしなら瞬殺。短いパスフレーズなら秒殺。パスフレーズをキーチェーン的なものに保存して、ログイン時に自動解錠だったりすると、ログインされたら瞬殺。

鍵ファイルを盗まれるリスクと、超長いパスワードのメモ（さすがに覚えきれないw）を盗まれるリスク。超長いパスワードをブルートフォースアタックで抜けられるリスクを考えると、安全性はどれも大差ない気がします。

鍵認証は鍵管理もあるし、担当者が変わった時も現状の設定変更スクリプトがそのまま使えて変更が楽だし、鍵認証についての説明と鍵管理の説明をする手間も省けるので、超長いパスワードメインで行くことに。

※sshでのログインが鍵認証限定になっていても、proftpdのsftpのパスワード認証には影響しない。

速度

1000baseTのLAN内で、素のFTPに比べるとおおむね半分くらいの速度しか出ませんが、インターネット越しだと、接続環境によってはほとんど変わらないかも。

Error?

requested read offset (32768 bytes) greater than size of 'file name' (10399 bytes)

/var/log/proftpd/sftp.logにこのようなログが大量に……。

ググり倒してみたら、どうもクライアントとの相性問題らしい。

ためしに、proftpdのリリース候補版をコンパイルして入れてみても同じ挙動を示すので、proftpd側の問題ではなさそう。

大小ファイルを上げ下げしても、特に問題は出ないので、気にしない方向でよさそうです。

更にググり倒してみたら、ウザイなら/dev/nullに捨ててしまえwと書いてあったりする。

吐き出させ続けるとアホみたいに巨大なログを吐くので、

SFTPLog /dev/null　#log捨てる

これでいくことに。

残る問題

cyberduckのsftp対応は、openssh sftpが前提なのか、proftpd経由だと挙動がおかしい。

firefoxOSX版のfireftpも挙動がおかしい。ログイン成功のログはでるけど、ファイルリストが出てこない。

Filezillaは上下とも問題なしだけど、この問題が出る。けど気にしないw

mod_delayメモ

proftpdで接続時の返答が遅いことがあるのは、mod_delayがデフォルトで有効になっているから。

何度もググった気がする……

netatalkにmacからファイルをコピーすると、リソースフォーク部分を管理する.Appledoubleという不可視フォルダができます。

これらの不可視ファイル／フォルダ群は邪悪な存在で、有名どころでは.DS_Storeが悪さをしますが、.Appledoubleもなかなか凶悪。

Appleshareのみの環境なら問題は出ませんが、同じディレクトリをFTPなどでも共有していると面倒なことに……。

Mac→netatalk

hage

これをls -laすると

hage .DS_Store .Appledouble

になっていて、これをFTPでgetすると、netatalkを経由しないので邪悪なフォルダ群がそのままコピーされます。

ここまでは何の問題も出ません。余分なクソフォルダがあるだけです。

これを、再度netatalkサーバにコピーしようとするとエラーが出てコピーできません。

afpdのログを見ると

check_name: illegal name: '.AppleDouble'

とあり、不正なフォルダ名なのでダメです。ということのようです。

ということで、netatalkの共有ボリュームから他の方法で落としたフォルダは、別のフォルダに移してからコピーするしかないようです。

OSXServerは仕組みが違うので平気でコピーできます。

OSXServerはファイル名にも寛容なので、Win/Mac他が混在する環境でのファイル共有は、OSXServerが一番簡単なのではないかと。

3.xでは、別の方法で管理するようですが、2.xのNASも多いので、NASで同じ現象が起こったら同じ原因でしょう。

ついでに。

netatalkほかで共有しあっているディレクトリを使うときは、マジでリソースフォークを使っている形式のファイルは止めた方がいいっていうか止めないと面倒です。

epsのpictプレビュー形式が典型的で、プレビュー部分が.AppleDoubleに入ってしまっていて、見えているファイルはプレビューなしになります

カーネルのアップデートがあったので、早朝に再起動しました。

ときどき、logcheckタンが送ってくるメールを眺めていたら、clamxav-daemonが立ち上がっていないふうなログが出ていたので、見てみたら、確かに立ち上がっていない。

起動しようとすると、ログファイルのアクセス権がないと言う。

見てみたら、確かにオーナーが変わっていて、アクセス権がないw

どこで変わった？　と、考えて、思い当たるフシはlogrotateしかありません。

logrotate.d/clamxav-daemonを見ると、やはりここでした……。

ローテーション後のオーナーをデフォルトのまま放置していて、設置後、最初のローテーション以降、ログが書き込まれていない状態になっていた模様……。

logrotateには、自分のサーバでも引っかかった事がある気がする。

と、思ったらここにあったw

横着者には、やっぱり、きっちりバチが当たるんですね……。