サイト運営」カテゴリーアーカイブ

SMTP遮断情報

サイト運営というかサーバ運営情報。メモ代わり。

現在スパム対策のためにSMTP転送を遮断しているIPは以下の通り。
基本的に実害を被ったホストのみ登録しています。

118.152.232.64/26
<*.silicon-valley.jp> 新星電子有限会社管理ドメイン
出会い系システムを販売している有限会社ビーエスディネットワークと深い関わり
113.212.128.0/19
<*.cyber-mailer.comの一部>
115.187.71.168
エルメディア株式会社管理ドメイン
210.153.126.98
<days.sc> エルメディア株式会社管理ドメイン
119.48.0.0/13
とりあえず中国であることは判明
84.90.112.0/21
<*.netvisao.pt> ポルトガルからはるばる

しかしうざったい商売してる連中が多いのです。


↓2009/11/15追加

118.88.8.0/21
<muramatsu-group.net> フィリピンのようです
180.232.0.0/16
これまたフィリピン。多分踏み台ですがお構いなしのクラスB完全規制w

↓2009/11/18追加

210.146.22.0/24
<*.wins-beam.net> ウインズコミュニケーションズ管理ドメイン
61.45.213.64/26
<*.bsd-network.jp> またも新星電子有限会社管理

↓2009/12/28追加

111.223.214.0/24
<*.mail-eng.com> TUCOWS INC.管理ドメイン

↓2010/01/07追加

111.223.217.0/24
<*.mail-eng.com> TUCOWS INC.管理ドメイン

↓2010/01/27追加

113.130.10.192/26
<aqyu209.todoke.jp>等 BeaconNC.INC管理ドメイン

↓2010/02/26追加

113.130.8.128/26
120.143.87.0/24
<*.a-sou.net>等 BeaconNC.INC管理ドメイン

↓2010/02/28追加

61.209.246.0/24
<*.wins-beam.net>の一部 ウインズコミュニケーションズ管理ドメイン

DNSに変なクエリが来ている件

今日はブログのテンプレートをいじったついでにサーバのメンテをやっていたら、syslogになにやら大量のDNSのlogがある。

Feb 3 01:48:20 ns2 named[14726]: client 69.64.87.156#31608: view external: query (cache) ‘./NS/IN’ denied
Feb 3 01:48:26 ns2 named[14726]: client 69.64.87.156#22680: view external: query (cache) ‘./NS/IN’ denied
Feb 3 01:48:32 ns2 named[14726]: client 69.64.87.156#51349: view external: query (cache) ‘./NS/IN’ denied
Feb 3 01:48:39 ns2 named[14726]: client 69.64.87.156#1820: view external: query (cache) ‘./NS/IN’ denied
Feb 3 01:49:01 ns2 named[14726]: client 76.9.16.171#220: view external: query (cache) ‘./NS/IN’ denied
Feb 3 01:49:41 ns2 named[14726]: client 69.64.87.156#35398: view external: query (cache) ‘./NS/IN’ denied
Feb 3 01:49:47 ns2 named[14726]: client 69.64.87.156#20409: view external: query (cache) ‘./NS/IN’ denied
Feb 3 01:49:53 ns2 named[14726]: client 69.64.87.156#44694: view external: query (cache) ‘./NS/IN’ denied
Feb 3 01:50:00 ns2 named[14726]: client 69.64.87.156#48098: view external: query (cache) ‘./NS/IN’ denied
Feb 3 01:50:03 ns2 named[14726]: client 76.9.16.171#19950: view external: query (cache) ‘./NS/IN’ denied
Feb 3 01:50:37 ns2 named[14726]: client 69.64.87.156#45895: view external: query (cache) ‘./NS/IN’ denied
Feb 3 01:50:49 ns2 named[14726]: client 69.64.87.156#52139: view external: query (cache) ‘./NS/IN’ denied
Feb 3 01:50:56 ns2 named[14726]: client 69.64.87.156#60293: view external: query (cache) ‘./NS/IN’ denied

 ルートサーバーのNSレコードを参照するクエリらしく、ご丁寧にお返事を返してしまうとネットワークの負荷を高めてしまう。その上、返事する先がちゃんと質問主なら良いのだが、どうもそうでもない可能性があるらしい。

試しにこのIPを検索してみました。

09020200.JPG

09020201.JPG

上も下も最近検索件数が増えているIPアドレスで、共にアメリカのホスティングの会社のようだ。
更に下のIP等は対応するホストがありませんとまで出ている始末ww (whoisの結果から4日前まではあったらしい)
つまり誰かがこのIPを語ってDNSクエリを送信し続けており、未対応のDNSがそのIPに向かってサイズの大きなお返事を返してしまう。という構図。
立派なDDoS攻撃ですね!!

うちのDNSに関しては先日のエントリ(DNSキャッシュポイズニング問題) の後にBIND9.4.3-P1にバージョンアップしたので、今回の問題クエリに対してもちゃんとdeniedになっている。ひとまずは安心して良さそうだ。

しかしサーバ運営も安定すれば放置で良いというわけじゃないのが大変なところですね・・・。

DNSキャッシュポイズニング問題

何となく常駐板以外をうろうろしていた所、つこうた事件で大騒ぎになっている最中のIPAが「DNSキャッシュポイズニング」に関する対策資料を作成したというネタを見つけた。

そんな問題あったっけ?と言うわけで調べてみた。

他のサーバに聞きに行くときに、ポートと呼ばれる窓口を通して聞きに行きます。
んで、このポートってのは65535個あるんだけど、ランダムに聞きに行くのが理想。
それと、一回聞きに行くごとに違うID(0-65535)を付けて送っています。
でも、これらの番号がもし予想しやすかったら?固定されていたら?
そこに目がけて嘘のデータを投げ込んでしまえば、嘘の住所をDNSが覚えちゃう。つまり、googleに繋ぎたい人を全く別のサイトに接続させたりすることが出来ちゃう!
ポート番号とクエリidがそれぞれ一致しないと、この汚染攻撃は成功しないんだけど、どっちかが予測可能であったら65535通り試す程度で済んじゃうよね。
今回の問題としては、そのポート番号のランダム性が足りなかったり、決め打ち(53番)だったりする事です。

ヤバイ、ヤバイね!

引用元:今更だけどDNSキャッシュポイズニングについて簡単に説明するよ! – そして、DNSポイズニングがなかなか対応されない理由。 – m-birdとFreeBSDの同棲日記

それでうちのDNSサーバもチェックしてみたところ案の定駄目でした。ポートがランダムになっておらず一直線です。
BINDの設定では「query-source」のポートは固定にしていないため数十秒単位で見れば変わってはいるのですが、連続で問い合わせされると役に立たないよう。

対策済みのBINDを早く導入せんとなぁ・・・。
そうはいってもFedora Core 6のバイナリ更新は完全に止まってるんじゃあああああああああああ!
適当なrpm探すかソースからビルドするか・・・。うーむ。

MovableType4.21にバージョンアップ

MovableType4.21が出荷されてから1ヶ月近くが経ち、特に問題が無さそうだったので4.2RC2からアップしました。MT3の頃のバージョンアップは結構スリリングな作業だった覚えがありますが、今は現行のファイルに上書きしてmt.cgiに再アクセスするだけ。楽ちんです。

バージョンアップした後で完全再構築を掛けてみると、途中でエラーが発生して止まってしまった。エラー内容を見ると「MTCommentReplyLink」というタグが解釈できないというような内容。ググってみると日本語のページは見あたらなかったものの、英語のサイトで「MTCommentReplyLink」を「MTCommentReplyToLink」に書き換えればいいような記事を発見した。

 早速書き換えて再度再構築したら無事通りました。古いテンプレートだったのでしょうかね。

以下のウィジェットモジュールに関してモジュールキャッシュを有効にしたら完全再構築が21分から7分半に短縮されました。

  • カテゴリーアーカイブ
  • 月別アーカイブ
  • 最近のコメント

再構築の重さがネックだったMovableTypeもどんどん進化していますね。

MovableType4.2ベータ導入

どうもMovableTypeが4.2で大々的な変更をするとか言う話。テンプレートがぐちゃぐちゃなまま無理矢理MT4に乗り換えた経緯があるので、今回のアップデートはまともに耐えきれる気がしない。
・・・と言うわけで暇なうちにMT4に乗り換えておくことにしました。

とりあえず以下のような行程にて。

  1. MT4.01環境でエクスポート
  2. ルートからディレクトリ全部まっさらにして、MT4.2ベータを再インストール
  3. ユーザも作り直してインポート
  4. 画像フォルダは元の位置にコピー
  5. 個別エントリのファイルネームを「%y/%m/%d-%h%n.html」に変更
  6. StyleCatcherで適当にスタイルを選択
  7. 再構築

個別アーカイブのパーマリンクは絶対に変更したくなかったので、前からこうしていました。よって問題なし。
月別アーカイブは標準のままなので問題なし。
しかし・・・カテゴリアーカイブはカテゴリIDを使って命名したせいで、カテゴリ再構築で対応関係が完全に崩壊。現状は標準設定にしてありますが、これもまた気持ち悪いのでそのうち対策を講じることにします。

そして、カウンタとして導入していた dopvSTAR* も、エントリIDが変更になったために対応が完全に崩壊www
とりあえず再導入の目処は立っていません。カウンタ・・・別にいらねーかw

色々とウィジットいじってた分も無くなってしまったのでまた作り直しだ・・・。ふぅ。
結構大変です。