はてなブックマーク

■ KnotDNS _ 昨年の IW2018 の資料が公開されたようで。 _ 自分は Knot DNS の話をしたですよ。DNSSEC やりたいけどあんなの運用まわらん、とか、Let's Encrypt で DNS 認証させたいけど自動化できなくてめんどくさい、とか言ってる人いればぜひ Knot を使ってみてくださいませ。自動化できるよ。まあ、BIND でできないわけじゃないけど。いきない Knot に乗り換えるのが怖くても、資料にあるように、BIND やら NSD やら使い慣れたものを前段、後段に置いて三段構成にすれば、Knot をほとんど意識せず、これまでとほとんど変わらない感覚で自動化できるよ。 _ 資料に書こうか迷ったけど結局やめておいたネタ。 _ 資料では Let's Encrypt の dns-01 認証による証明書取得を自動化する方法について触れてるけど、そうはいってもうちの

■ 1.1.1.1 いろいろ _ ここのところブロッキングの話を追いかけてたもんだから、そのちょっと前にホットだった cloudflare の public DNS のネタを消化しきれてない。ということで、もうだいぶ遅れ気味だけどまとめて放出。 _ あ、JANOG41.5 でやったブロッキングの話の資料は ここにあります。周回遅れすぎて今さら見る必要ないかと思いますが。 ■ DNS over TLS _ お使いの unbound.conf に以下の設定を追加するだけで、cloudflare に対して DNS over TLS でクエリをやりとりするようになります。ただし最新の 1.7.x 以降のみ。 server: tls-cert-bundle: "/etc/ssl/cert.pem" # ルート証明書束 forward-zone: name: "." forward-tls-upstr

■ 通信の秘密 _ ちうことで、ついに 裁判に。 _ 今回の件で痛感したのが、通信の秘密ってぜんぜん理解されてないんだなー、ということ。憲法で定められている基本的人権のひとつなのに。 _ ブロッキングを問題視してない人ってのは、たぶん「ブロックすること」が通秘の侵害だと考えてるんじゃないかなぁ。名指しされたサイトにアクセスしなければブロックされることもなく、ブロックされないのであれば自分自身の通信の秘密は侵害されない。そう考えてるんじゃないかと推測する。 _ この考え方は間違ってるからね。いや、ブロックすることも侵害なんだけど、それ以前に「ブロック対象かどうかチェックすること」が通信の秘密の侵害。名指しされたサイトにアクセスするのではなく、たとえば youtube で動画を見るだけでもブロック対象かどうかチェックされ、そうでなかったからブロックされずに youtube にアクセスできるわけ

■ 1.1.1.1 _ NANOG で話題になってるんだけど、どうやら cloudflare が 1.1.1.1 と 1.0.0.1 というおそろしいアドレスで public dns を始めようとしているっぽい。 % dig +noall +ans 1.1.1.1.in-addr.arpa ptr @1.1.1.1 1.1.1.1.in-addr.arpa. 1735 IN PTR one.cloudflare-dns.com. 今日の夕方ごろは応答に2秒とかかかってたけど、夜になってからは 10ms 以内で返ってくるようになった。anycast への組み込みが完了したのかな？ _ で、なんで cloudflare なの？ 1.1.1.0/24 は 常時かなりのトラフィックが流れていて汚れてるからどっかに割り振りはしないで研究やら何やらの用途のために予約するとか言ってなかったっけ？ いちお

■ memcached フィルタ _ memcached のアクセス制御に関する注意喚起とかまあそんな感じで、本来内部用途でしか使われないはずの memcached が外部におっぴらげになってるサーバが世の中にたくさんあって、認証なしでガバガバだもんだから外から自由にデータを出し入れできて情報流出/改竄できちゃうどころか、UDP でもアクセスできるもんだから増幅率超特大の reflection attack の踏み台に使えて あちこちで大規模 DDoS の被害多発とかそんなヤバい事態になってるそうでマジヤバい。 _ で、それに対する対処は、とーぜんムダに開いてる memcached のポートを閉じることなんだけど、増幅率がハンパなくて踏み台にされると超ヤバい(語彙貧困)ので、個々のホストではなく、ISP とかホスティング屋さんがネットワークのレベルでフィルタを入れてる例があるっぽい。 外部

■ root KSK ロールオーバー _ 新聞はそっち方面の専門家でない人にもニュースを届ける必要があるので、難しい内容も噛み砕いて説明する必要があって、その結果まわりくどい説明になっちゃうことがあるのは理解している。事情はわかってるので、ふだんはそういう記事を見つけても記者さん苦心したんだろうな、とあたたかい目で見るようにしている。が、いくらなんでも これはひどい。噛み砕いて説明するのに苦心したのはすごくよく伝わってくる。しかしその挑戦にもかかわらず素人さんが理解できる内容になっているとは到底思えないし、わかりやすい説明のために専門用語を使っていないため、そっち方面を理解している人に対してさえ意味不明。この記事の内容を事前に知っていた人(=記事を読む必要がない人)が何度か読み直して「ああ、あのことか」と気がつくのがやっと。誰に対しても存在する価値のない記事になっちゃってる。もうすこし何と

■ デカいメールヘッダ _ うーん。→ 【Exchange Onlineに関するお知らせ】 ヘッダー サイズの超過によって Exchange Online からのメール配信に失敗する場合がある _ MS の Office365 はリレーするメールに長大なヘッダを付加するのはよく知られていることなんだけど、最近は肥大化がさらに進んで、受け取り側で headers too large で蹴られるような事態になってるそうで。このお知らせにある例では、32KB が上限だったようなんだけど、32KB って小さすぎる値じゃないよねぇ。 _ 調べてみたところ、sendmail のデフォルトがまさに MaxHeadersLength=32768 だった。つまり、意図してヘッダサイズを小さな値に制限していなくても、sendmail をデフォルトのままで使っていればそれだけで O365 からのメールの受け取り

■ PHP の mail() 関数で FizzBuzz _ といってもループはできないので数値は生のリストで与えるんだけど。 $ php -r 'mail("","","","","-be \${tr{\${map{1:2:3:4:5:6:7:8:9:10:11:12:13:14:15:16:17:18:19:20:21:22:23:24:25:26:27:28:29:30:31:32:33:34:35:36:37:38:39:40:41:42:43:44:45:46:47:48:49:50}{\${if={\${eval:\$item%15}}{0}{FizzBuzz}{\${if={\${eval:\$item%3}}{0}{Fizz}{\${if={\${eval:\$item%5}}{0}{Buzz}{\$item}}}}}}}}}{:}{\\n}}");' 1 2 Fizz 4

■ exim で php のメール送信でコード実行される件。 _ 昨年末から続いている PHP でメール送信するところでリモートからコード実行できちゃう一連の脆弱性の話。これまでは主に sendmail がターゲットだったけど、 PHPMailerの脆弱性CVE-2016-10033はExim4やWordPress4.6でも影響があった という話が。Host ヘッダからコード注入するとか何を食ったらそんな発想に至るのかまったく想像の埒外なんだけど世の中いろんなこと考える人いるなぁ。ちなみに Host ヘッダの細工で、コード実行以外にも wordpress に認証なしでパスワードリセット要求もできるらしいよ。 _ で、これとは別件なんだけど、やっぱり PHP のメール送信でコード実行される脆弱性が先月 Squirrelmail に見つかってる。解説としては こっちの方がわかりやすいかな。以下

■ SSH のホスト鍵検証 _ 子供のころ遊んだよね、忍者ごっこ。「アイコトバをいえ！ やま！」「かわ！」 _ これ、セキュリティ的に重要な要素なんだけど、みんな忘れちゃったのか無視してるんだか。他人に知られてはならない重要な情報を伝達するにあたっては、まず相手が味方であることの確認からはじめなければならない。忍者の合言葉というのは、その味方の確認なわけだ。相手確認をサボって本来情報を伝えるべきでない相手に伝えてしまったら暗号化する意味がない。オレオレ SSL がダメなのは、この確認ができないから。そして、SSL だけではなく、SSH でも当然接続先の確認は必須である。 _ この SSH の接続先検証に関するオプションが StrictHostKeyChecking。これを no にする(検証しない)というのは、 SSL でいえば接続先の証明書を検証しない(不正な証明書でも気にせず接続する)

■ サブドメイン管理者が親ドメインの SSL 証明書を取得する _ 中国最大級の認証局「WoSign」がニセの証明書を発行していたことが判明。サブドメインの管理権限がある人が親ドメインの SSL 証明書が取得できちゃったんだって。この問題、他の CA でもあるんだよね、実は。 _ 具体的に言うと Let's Encrypt がそれ。 この記述。example.com ドメインの所有者かどうか判断する方法のひとつとして、_acme-challenge.example.com の TXT レコードに指定のトークンを記述せよ、というのが挙げられている。ということで、ユーザが自由にサブドメインを作れるサービス上で _acme-challenge というサブドメインを作成すれば親ドメインの証明書を発行してもらえる。今回の WoSign の件のように任意のサブドメインでいけるわけではなく、ラベルにアン

■ postqueue -j _ postfix 3.1 でキューを JSON 形式で出力できるようになった件。もすこし詳しく。 _ 実際の出力はこんな感じ。jq をかませて読みやすくしてるけど、実際はキュー1個につき1行で出力される。 % postqueue -j | jq . { "queue_name": "hold", "queue_id": "3qDrfV1xKRz3Ztt", "arrival_time": 1456819639, "message_size": 286, "sender": "MAILER-DAEMON", "recipients": [ { "address": "foo@example.com" }, { "address": "bar@example.net" } ] } この例では recipients の配列が冗長に見えるけど、これは強制的にキューか

■ ssh ポートフォワード _ sh スクリプトの中から、ポート転送しないとたどりつけないホストにアクセスしたい。ただし、常時ポートフォワードしてるわけではないので、スクリプトの中でポート転送を開始し、終了もスクリプトの中で面倒見る必要がある。 _ 教科書的なやりかたはこう。 _ ssh をバックグラウンドで起動し(-f)、リモートホストでは何もコマンドを実行しない(-N)。が、バックグラウンドにいってしまったプロセスを止めるために ps | grep でいくつも動いてる(かもしれない) ssh のコマンドの中からスクリプトで起動したものを特定して kill するという処理が必要になる。めんどくさい。pid をどっかのファイルに吐き出してくれる、とかいうオプションがあればいいんだけど、そういうものはなさげ。 _ じゃあどうしよう。

2015年5月2日(土) ■ ファイルアップローダーのセキュリティ _ 徳丸さんとこ。 Apacheの多重拡張子にご用心。 ファイルのアップロードは、実は簡単ではないととらえるべきだと思います。 アップロード自体は難しくもなんともないよね。アップロードしたファイルをダウンロードさせるのであれば気をつけなきゃいけないことはたくさんあるけど。 _ ファイルをダウンロードさせるためのスクリプトなのであれば、アップロードだけじゃなくてダウンロードの部分まで面倒を見るべき、つまり推奨されてるとおり、対策の (3)(4) が正道だと思う。 _ が、たとえば、プログラムを1ビットも書かなくても、WebDAV という仕組みを使えばファイルのアップロードやら削除やらは好き放題できる。でも、DAV でもファイルのダウンロードは素の HTTP の GET を使うので、DAV が有効な場所でスクリプトが実行可能に

2015年2月23日(月) ■ apache 多重拡張子 _ mod_mime の多重拡張子の扱いって常識じゃなかったのか。apache をインストールしたことある人ならば、manual/hoge.html.ja という二重拡張子を持つファイルが存在してることはドキュメントを読まなくても知ってるはずだと思うんだけどなぁ。AddHandler/AddType/AddCharset/AddLanguage/AddEncoding/AddOutputFilter はいずれも拡張子によって挙動を変えるわけで、単一の拡張子しか扱えないとすればこれらのディレクティブは排他にしか使えなくて困るじゃないか。 _ で、これはセキュリティの懸念があるから使うなというのがよくわからん。hoge.php.jpg というファイルをアップロードされて、それをそのままダウンロードしたらそいつが PHP スクリプトとして

2015年2月20日(金) ■ Superfish _ オレオレ CA 証明書をつっこんで HTTPS なサイトに MITM で広告つっこむよ、と。 _ うーん。セキュリティゲートウェイやアンチウイルスソフト、あるいは Web アプリケーションの開発補助ツールでも同じような動作をするものが多いので、このやりかたを批判するとしたらこういう製品もすべて批判することになっちゃうんだよなぁ。かるくぐぐってみただけで こんなに見つかった。ほかにもまだまだいっぱいある。Superfish は広告追加というユーザにはとくに益のない目的でやってるので叩き放題だけど、こういう製品の場合はセキュリティ向上やら開発やらという大義名分があって、実際わりと広く受け入れられてるんだよね。自分としてはそういう目的であってもひじょーに気持ち悪くて勘弁願いたいんだけど。 _ アンチウイルスの場合、通信経路に割り込むのではな

2014年11月21日(金) ■ 逆引き shellschock _ きのうの dnsops BoF で発表してきました。 資料置いときます。 _ スライドに書いてないこと、当日話さなかったことについていくつか補足。 こういう危険な文字をリゾルバがどのように扱うべきかの規定は、探したかぎりでは見つからなかった(たぶんどこにも規定されてないと思うんだけど確証はない) BIND8 のコードは 4.9.7 にバックポートされ、BIND4 も最終的にはサニタイズ処理するようになった つまり、OpenBSD はバックポート以前のコードをずっと保守している OpenBSD については近所のコミッターさんに直接報告済み courier については開発者にメールで報告済み _ OSX や OpenBSD、Windows などのリゾルバが脆弱だとはいえないと思う。glibc など BIND8 由来のコードは

2014年9月24日(水) ■ SSDP _ IW2014 DNS DAYのプログラムが発表されてました。今年も喋ります。お題は IP53B。よろしく。 _ 内容は IP53B に関連するんだけど、持ち時間があまり長くないのと、あくまで "DNS" DAY ということでテーマがそぐわないかもということで、当日に喋らないかもしれないネタを今のうちに投下してみる(余裕があれば喋りたい)。 _ SSDPというプロトコルがあるですよ。UPnP で使われるもの。1900/udp。はい、UDP です。amp 攻撃の踏み台に利用可能。 増幅率はおよそ30倍ぐらい。踏み台になりうるオープンな SSDP サーバは、 全世界で1700万台、国内に65万台も存在している模様。 オープンリゾルバよりも多い。 _ さらに悪いことに、オープンソースの複数の SSDP 実装には、外部から任意コードを注入できる 脆弱性の

2014年6月23日(月) ■ 無題 _ 持ち時間30分で50枚って無理だよね…。まだ何枚か増えるし。 2014年6月26日(木) ■ 無題 _ ひさしぶりに大手町に来たけど、以前といろいろ違いすぎててアレ。再開発やってるのは知ってたけどここまでとは。当時は公庫ビルの職員食堂とか日経新聞の社員食堂とかよく忍びこんで昼飯食ってたけど、ビルどころか、ビルが面していた通りごと消滅しちゃってるし。 _ KDDI とか NTT com とかのビルは変わらぬ姿で安心する。通信設備が入ってるビルはそう簡単に建て替えられんからね。それでも、生活彩家がなんでセブンに変わってるんですかー。 ■ .local _ ということでみなさまおつかれさまでした。今日話題になった、というか話題にした件。 RFC6762。 Any DNS query for a name ending with ".local." MUS

2014年6月19日(木) ■ さよなら greylisting _ MS の Office365 と超絶相性が悪いみたい。word やら excel やらじゃなくて、メールサービスとしての o365 ね。 _ spammer は配送効率を重視して送信失敗しても再送しないことが多いという仮定のもと、いったん 4xx で一時エラーを返してから、再送してきたメールだけを受け取るというのが greylisting。で、再送されてきたメールなのかどうかを判定するのに使われるのが送信元の IP アドレス。from、to、IP アドレスの3つセット(triplet)で判定するとか、IP アドレスだけで判定するとか流儀はあれど、いずれにせよ判定には必須。が、o365 は再送のたびに違う IP アドレスから送信してくるみたい。よって、greylisting をやってるサイトでは o365 からのメールは受

2014年6月5日(木) ■ openssl 祭 _ openssl に また穴。 _ んーと、MITM によって、攻撃者が強制的に強度の弱い暗号を使わせるようにすることができる、という直球ド真ん中のダウングレード攻撃ということかな？ とはいえ、おそらくクライアント/サーバがサポートしない暗号を使わせることまではできないだろうから、平文(eNULL)まで弱くなるということはないような気がする。つまり apache でいえば、SSLCipherSuite HIGH:MEDIUM と設定してある場合、この脆弱性を突いて HIGH じゃなくて MEDIUM な暗号を使わせるようにすることはできても、LOW な暗号にさせることはできないんじゃないかということ。 _ ……あ、いや、違う？ もしかして鍵交換に介入して共通鍵を奪われちゃう？ だとすれば、どんな暗号アルゴリズムでも自由に復号できちゃうから