internetの最近のブログ記事
Postfixの場合、バーチャルドメインの存在しないアカウントであっても、user部分がローカルアカウントとダブっているとローカルアカウントで受け取ってしまうようだ。これが今回のブラックホール作成の動機となった。
前のエントリで紹介した方法は、送ろうとしたサーバに例えば、"554 Service unavailable; Client host [(IP address)] blocked using list.dsbl.org; http://dsbl.org/listing?(IP address);"というメッセージを返してしまう。 普通はこれを喰らった直後に、同一ドメインの別MXに送信しようとしてくるようだ。Service unavailableだから仕方がないのかも知れないが、バックアップMXが自分の管理外だと設定する意味が無くなってしまう。
さて、本当にブラックホールに送るには、受け取った振りをする必要がある。このような場合、一旦受け取るためにはそのメアドを実在するように見せかけるためにvirtualで設定しておかなければならない。
実際のブラックホール処理はパイプラインを使って行う。例えば、blackholeというアカウントを作っておいて、/etc/postfix/aliasesにこう設定しておく。
blackhole: :include:/etc/postfix/blackhole
Postfixでincludeを活かす為にはmain.cfに最低限以下の設定が必要なので注意して欲しい。
allow_mail_to_commands = alias,include
で、肝心の/etc/postfix/blackholeにはこう書く
"| cat > /dev/null"
どや、参ったか。
ローカルドメイン宛で、宛先不明のメールをブラックホールに落すにはmain.cfに以下の設定を追加する。
luser_relay = blackhole
バーチャルドメインでこの設定が出来るともっと平和になるのだが、どうやら無理のようだ。
実は今年に入ってからコソーリこのサーバを11月下旬に借り始めたVPSに引っ越している。SMTPサーバとしてPostfixを選択しているが、面白い設定があったので導入してみた。DNSを利用したオープンリレーサーバ等のブラックリストチェックだ。スパム配信に使われやすいサーバが登録されている。
/etc/postfix/main.cf(抜粋)
smtpd_recipient_restrictions =
permit_mynetworks, permit_sasl_authenticated,
reject_rbl_client spamcop.net,
reject_rbl_client dynablock.wirehub.net,
reject_rbl_client opm.blitzed.org,
reject_rbl_client relays.ordb.org,
reject_rbl_client sbl-xbl.spamhaus.org,
reject_rbl_client all.rbl.jp,
reject_rbl_client list.dsbl.org,
reject_rbl_client cn-kr.blackholes.us,
reject_rbl_client brazil.blackholes.us,
reject_rbl_client russia.blackholes.us,
permit_auth_destination,
reject
私のサーバにはまともなメールは一日に多い日で100数十通程度しかこない。はっきり言って使っているブラックリストが多すぎるが、トラフィックが少ないことと、同じサーバでBINDをキャッシュサーバとしても動かしているので許して欲しい。
reject_rbl_clientで並んでいる下の三つは過激だ。中国や韓国、ブラジル、ロシア(スパム多発国)に割り当てられているIPアドレスを持つメールサーバからの配信を全て拒否してしまう。
これを導入してからスパムが激減した。導入前はMUA側のベイジアンフィルターで自動的にごみ箱逝きにするしかなかったのだが、このブラックリストを通過してくるスパムは一日一通から二通の状況が続いている。Postfixを自前で動かしていてスパムに悩まされている方は試してみて欲しい。
同じ原理を応用したMovabletype用のプラグインであるMT-DSBLも導入してみた。その名のとおり、DSBLのみを参照している。ここ数週間はコメントスパムが来ないので、楽しみにして待つことにしたい。
先日、2chに書き込む為のSquidの設定を紹介した。今回は更に一歩進めて、怪しいサイトを巡回するときに使える、送受信時のデータ浄化を行うPrivoxyと、匿名自動多段proxyのTorの設定を紹介してみる。それぞれのツールの詳細については実際に使う前に専門サイトで調べて欲しい。
ここではTorをprivoxyの下請けとして動作させてみる。もちろんlocalhostのユーザはtorを直接利用可能だ。この設定では外部ユーザへのインタフェースとしては単なるhttp proxyということになる。
privoxyもtorもRPMパッケージが存在しているので、パッケージ導入した方が実行ユーザの作成やらinitスクリプトを作成したりする手間が省けるので楽だ。設定も他のサービスアプリに比べると簡単だ。
まず、入口側のprivoxyの設定だが、localhostでしか使わないのであれば、特に触らなくてもデフォルトで動作する。
インターネットに設置しているサーバに設置する際は、当然注意が必要で、アクセスを厳しく制限し、listenするportも変えた方がいいだろう。誰か知らない人がこれを使って爆破予告をする事態を想像して欲しい。
以下に、公開する場合の設定例を挙げる。設定ファイルは/etc/privoxy/configだ。localhostでしか使わない方はtorの設定まで読み飛ばして欲しい。
privoxyの待ち受けアドレスとポートの設定(4.1)
listen-address 1.3.6.9:7743
privoxyのアクセス制限(4.5)
特定のIPアドレスからのアクセスのみ許可する(強く推奨) 。iptables等のファイアウォールでdrop(臭いものに蓋)してしまってもよいが、何かのテストの際に問題切り分けの為一時的にiptablesを外したような場合に問題になる。面倒でもここは手を抜かない方がいいと思われる。iptablesの設定例は後で紹介する。permit-access 127.0.0.1 permit-access 1.2.3.4 permit-access 1.2.4.0/24
次にprivoxyを通した後にtorをかます設定を行う前に、torの設定を見直す。設定ファイルは/etc/tor/torrcだ。
torの待ち受けアドレスとポートの設定
torはlocalhostでしか使わないのでデフォルトのまま。SocksPort 9050 # what port to advertise for application connections SocksBindAddress 127.0.0.1 # accept connections only from localhost
torをデーモン化する設定
privoxyと同時に使うならtorもデーモン化した方がいいだろう。RunAsDaemon 1
続いてprivoxyからtorに中継する設定を行う。再びprivoxyの設定ファイルを開く。
privoxyからtorへの転送設定(5.2)
forward-socks4a / localhost:9050 .
これだけだが、自分のサイトや信頼できるサイト、それからtor経由では書き込めない2ch等には直接アクセスする例外を設定する。(5.1)
forward .2ch.net . forward vartmp.net .
最後にファイアウォール(iptables)の設定を追加して仕上げる。ここではINPUTをDROPするポリシーを前提にしている。先ほどprivoxyに1.3.6.9:7743でlistenさせる設定をし、アクセス制限を加えた。それと整合する設定を追加する。最低限、以下が必要だ。
#/sbin/iptables -P INPUT DROP #/sbin/iptables -A INPUT -i lo -j ACCEPT #/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT #/sbin/iptables -A INPUT -p tcp -s 1.2.3.4 --dport 7743 -d 1.3.6.9 -j ACCEPT #/sbin/iptables -A INPUT -p tcp -s 1.2.4.0/24 --dport 7743 -d 1.3.6.9 -j ACCEPT
wgetでも使いたい方は/etc/wgetrcを書き換える。今回の設定例ではlocalhostでlistenさせていないので、localhostから使う場合でも外に出ているインターフェースを使う必要がある。設定ファイルは/etc/wgetrcだ。
http_proxy = 1.3.6.9:7743wgetrcを書き換えると、明示的にオプションを指定しない限り、privoxyが使われる。直接アクセスする際は-Y offのオプションが必要だ。
念のため、自動起動関連の操作も説明しておく。
自動起動スクリプト確認
#/sbin/chkconfig --list
自動起動スクリプト登録
#/sbin/chkconfig --add privoxy #/sbin/chkconfig --add tor
自動起動スクリプト設定
#/sbin/chkconfig --level 345 privoxy on #/sbin/chkconfig --level 345 tor on
起動
#/sbin/service privoxy start #/sbin/service tor start
参考情報（使用したバージョン)
Privoxy : 3.0.3 (stable) Tor: 0.0.9.2末筆ながら、このような素晴しいツールの作者、並びにtorのネットワークを維持しているonion routersの運営者に感謝したい。
ISPがtransparent proxy(日本語でどう呼ぶ?透過的代理サーバか強制プロクシか・・・)を設定している--検閲用?--ので、全てのポート80へのアクセスがキャッシュされており、2ch等には書き込めない。2chは漏れ串経由(Proxy関連情報を環境変数に出すProxyサーバ)の書き込みは受け付けてくれない。ということで、VPSに働いてもらうことした。
まずVPSにsquidをインスコする。設定ファイルは/etc/squid/squid.confだ。中身に匿名串に変身させるための設定が2種類コメントアウトされた形で紹介されている。テストしてみたところ、どちらも2chには激し過ぎる設定だった。最終的に落ち着いたのは以下の設定だ。
http_port 13128 forwarded_for off header_access X-Forwarded-For deny all header_access Via deny all header_access Cache-Control deny all
確か現時点では2chは3128のポートスキャンをやっていないはずだが、礼儀?としてポートを変えておいた方がいいと思う。残りは串っぽい環境変数を出さないようにする設定だ。2chではリファラを消すと書き込みができないので、アレンジする際は注意して欲しい。
言うまでもなくアクセス制御には十分な注意が必要だ。うっかり誰でも使えるようにしてしまって、悪い人が踏台に使ったりすると、いい迷惑を被ることになる。
バンコクに出掛ける前に、レジストラのDNSのゾーン設定を完璧にしてレジストラのDNSを使うように設定していた。本日時点でゾーン情報は十分伝播しているようだが、どうしてもWHOISが更新できない。
digコマンドでレジストラのDNSを直接指定して検索したところ、NSレコードが2つしかない。つまりレジストラが用意するプライマリDNSとセカンダリDNS各1台ずつだ。これはおかしい。独自ネームサーバに対応するAレコードは用意してあり、dns1.example.orgやdns2.example.orgは名前解決しているのに、NSレコードが引っ張れていない。ということは、ネームサーバ登録(=NSレコード追加)が出来ていない事になる。
ネームサーバ登録ページではdns1とdns2が確かに登録されているように見える。これは何度も確認している。ただし、個別に更新や削除をするとエラーになってしまう。駄目元で同じホスト名とIPアドレスの組みを追加してみたら、重複エラーにはならずにすんなり受け付けられた。当然画面上では変更前と同一に見える。何だか怪しい手応えを感じたので、その直後にWHOISを更新してみたら、エラーは出ず、すんなりDNSの変更が通った。
どうやらレジストラのネームサーバ登録ページに騙されていたらしい。登録されているように見えても実は登録されていなかった事になる。言われたとおりやらない私と、登録時のチェック機能に問題がありそうだが、とにかく結果OKとなった。
レジストラが提供する設定変更ツールを使って自前のDNS(アメリカとシンガポールに各一台(笑))を登録しようとしたが、エラーになってしまう。Zoneeditや鯖屋のDNSなら登録できるのに、自分自身のドメイン名を冠したネームサーバが登録できないのは悔しい。ネームサーバの名前は解決済み(正引き可能)なのにだ。
普通にuseraddせずにWebminで間違った方法でユーザのパスワードを登録していたのが原因だった。気付くのが遅れたのは、平IDで一度もパスワードを使ってログインしなかったからだ。rootでの初回ログイン時に、ビルドまでの作業に使う平IDを真っ先にWebminで作って、公開鍵秘密鍵方式に即座に変更した為、自分が登録したユーザでパスワードを使ったログインをする機会が無かった。
Webminのユーザ管理画面にはパスワード欄が二つある。通常のパスワードと暗号化されたパスワードだ。私はこれを勘違いして、暗号化されたパスワードの欄に生のパスワードを入力していた。どうやらこれは、自分で暗号化した人が暗号化されたパスワードを入力するための欄みたいだ。
正しい手順は、ユーザ登録時に普通のパスワード欄に生のパスワードを入力する。すると、次回表示したときには暗号化されたパスワードしか表示されない。
悔しいので、この週末は久しぶりに天使の都(クルンテープ)でくつろぐ事にする。(欝死)
自宅鯖では問題ないし、双方での./configureの出力も全く同一だった。実行ファイルの大きさも同じだが、md5を取ると違っていた。一体何が違うのだろうか。
レジストラが提供する設定変更ツールを使って自前のDNS(アメリカとシンガポールに各一台(笑))を登録しようとしたが、エラーになってしまう。Zoneeditや鯖屋のDNSなら登録できるのに、自分自身のドメイン名を冠したネームサーバが登録できないのは悔しい。ネームサーバの名前は解決済み(正引き可能)なのにだ。
IPアドレスでネームサーバを登録する事ができないのはわかっていたので、一応自前でマスタサーバを建てた後にドメイン外にあるスレーブにゾーン情報を転送し、DNSレコードをスレーブのみの構成にアップデートしてまず放置した。そのゾーン情報の中には自前のネームサーバの名前とアドレスが入っている。その後、そのスレーブをマスタ+別のスレーブに入れ換えれば目的達成かと思われたが、エラーになってしまう。
レジストラのサポートに聞いたら、ゾーン情報更新ツール(別売)で、最初に自前のネームサーバの情報を登録しろという指示が返って来たが、そのプロセス(新DNSの正引き可能化)はもう終わっている。一応言われたとおりにやってみたが、やはり駄目だった。
そう言えばエラーコードらしきものもあったので、更にサポートに突っ込んで原因を追求したい。私がBINDの設定を何かミスっているのかも知れない。
LAN側でもhosts列挙を止めてDNSを使うように変更し、私がコントロールしているPCを全て登録した。また、自宅ネットまでポート53と953が通っていたので、LANで使っているDNSにセカンダリDNSを兼任させることにした。更に、鯖屋さんに頼んで、VPSのIPアドレスでホスト名を逆引き出来るようにしてもらった。これで安心してメールサーバが動かせる。
今朝起きたらVPSが使えるようになったという連絡が来ていた。
まず最初にsshを使ってパスワードでログインする。自宅サーバのメンテ用に使っている公開鍵を転送し、設定を変更する。ssh2のみ受け付け、ログインは10秒以内、パスワードのみのログインは不可とした。
sshだが、自宅にもチャレンジャーが沢山やってきていた。ポート22(ssh)をそのまま使ってパスワードのみの認証にしていたときは/var/log/secure(セキュリティログ)が蝿取紙状態だった。95%以上が中国か韓国(の踏台?)からのチャレンジだ。手入力でチャレンジしているようで、ときどきタイポがあったりして笑えた。
sshを固めたら、仮想マシンの中を探検してみる。WebminがOpenssl付きでインスコされていたのには驚いた。BINDはWebminで設定してみることにしよう。
昨夜の実験でDNS情報を汚してしまったので、まず最初にDNSをしっかり建てたい。BINDをapt-getを使ってインスコし、ついでにJail(chroot)化も行う。ゾーン情報をWebminで叩き込んで、デーモンを始動、セカンダリDNS側の設定を行って、WHOISのDNS情報を書き換えた。ドメイン名を使ってまともにテスト出来るのは木曜日あたりになりそうだ。
次にSendmailを殺してPostfixに置き換える。設定ファイルは自宅鯖からそのままコピーして停止させておく。
Qpopper(POPサーバ)のソースを自宅鯖から転送し、VPS側でビルド、インスコする。この鯖でPOPを使うのは10人といない筈なので、デーモンではなくてxinetd配下で動かすようにした。APOPやSSLに手だしする前に生POPのテストをlocalhostから実施する。
ここで問題。パスワードを間違えていないのに認証ではねられる。FAQによるとパスワードがシャドウ化された環境では./configure時に--enable-specialauthを指定しないといけないとある。しかし、マニュアルにはほとんどの環境で./configureがよきにはからうと書いてあった。とりあえず--enable-specialauthを指定して再構築してみたが結果は同じだった。
自宅鯖では問題ないし、双方での./configureの出力も全く同一だった。実行ファイルの大きさも同じだが、md5を取ると違っていた。一体何が違うのだろうか。
別サイト構築の実験用にインターネットに公開するサーバを作ろうと思い立った。レンタルだと余り好き勝手にできないし、サービスをするソフトそのものやバージョンを入れ換えたり、組合せを変更したりできないし、Hackも当然できない。
実験用のハードを購入する前に、自宅で暇を持て余しているファイルサーバを使って、BIND, Apache, Postfix, Qpopperをインスコしてみた。BINDとApache以外はほとんど設定する箇所はない。Apacheの設定前にゾーン情報をzoneedit.comに無料で設置したセカンダリDNSに吸わせてから、メール等の疎通を確認しようとしたところ、残念な事が判明した。ポート25(SMTP),80(HTTP),110(POP3)が通って来ない。ISPが主要ポートのinboundを塞いでいるようだ。
このISPはモデムをリセットしてもIPアドレスが変更されない。ルータのMacアドレスを変更(笑)しないとIPアドレスが変わらない、事実上の固定IP状態だった。なるほど、こういう背景があったとは知らなかった。
まあ、アマチュア無線や、自宅で衛星から直接CSを受信するのも禁止されている--ケーブルテレビは国内一社のみで数十チャンネルしかない--国なので仕方がないか。先にハードを購入しなかったのが不幸中の幸いだ。
実験用のハードを会社のDMZに置くわけにもいかない(笑)ので、アメリカのとあるVPS（仮想プライベートサーバ)をレンタルすることにした。選べるディストロの中からWBELを選択した。メモリは96MB、ディスクは4GB、転送量は20GB/月、IPは一個が占有できる。メモリはスワップなしの64MBとどちらにするか悩んだが、ヘビー級のアプリを稼働させるかも知れないので、とりあえずスワップする方を選んだ。実験が終わればスワップなしのプランに移行する事もできる。月US$19.95也。参考までに今皆さんがアクセスしているこのサーバは月US$8で日本国内に設置されている。
root権限が貰える事になるが、Kernelだけは触れない。特殊なハードは使わないので、ほぼ何でもできてしまうはず。UMLで動いているのかな。わくわく。
