Hatena::ブログ(Diary)

ろば電子が詰まっている

2015-08-29

sshのポートをデフォルトの22/tcpから変えるべきか論争に、終止符を打ちました

また間が開きましたが、すみだセキュリティ勉強会2015#2を開催しました。発表していただいた@inaz2さん、@yasulibさん、ありがとうございました。当日の発表資料は上記の勉強会ブログからリンクしています

今回の私の発表は、「攻撃を『隠す』・攻撃から『隠れる』」。ポートスキャンをするとsshが100個現れる「ssh分身の術」がメイン(?)です。

f:id:ozuma:20150829164138p:image

当初は、パケットヘッダやプロトコルのすき間にメッセージを隠したり、ファイルを隠すなども考えていたのですが……。あまりに盛りだくさんになりそうだったので、「ポートスキャンをいかに隠れて実行するか・ポートスキャンからどうやって隠れるか」と、ポートスキャンとnmapに絞って発表しました。

発表資料

私の発表資料は以下です。

発表ノート付きなのでPDFです。以下、落穂ひろいなど。

スキャンするポート数とカバレッジ

勉強会ではカバレッジという言葉を使いましたが、元ネタのnmap公式ガイドブック(目ン玉本)では、"Effectiveness"と書かれています。ちょっと分かりにくいので、勉強会ではCoverageという言葉にしました。

10ポートスキャンすればEffectivenessが50%というのは、初めて読んだときには「たったの10ポートでそんなにカバーできるの!?」とちょっとビックリしましたが、冷静に考えてみれば感覚的にはまぁそんなもんかなという印象です。

ただ、この値はインターネット越しにスキャンを行った場合ですね。データセンターなどで同一セグメントからポートスキャンを行う場合は、もっとたくさんの開放ポートが見えるので話は違ってくると思います。

sshのポートは、やっぱり22/tcpから変えましょう

「sshのポートをデフォルトの22/tcpから変えても意味ないよ」というブログ記事は、はてなブックマークあたりで定期的に炎上するテーマです。以前から、「ピンポンダッシュが激減するんだから、ゴチャゴチャ言ってないで変えるべき」派だった私は、変えなくていいよ派の「ポートスキャンすれば一発で分かるじゃん」という意見懐疑的でした。今回のネタはその辺が出発点になっています。

今回、こうして具体的にポートスキャン一発では分からない手法がいっぱいあるよと示すことで、「sshのポートをデフォルトの22/tcpから変えたほうがいいか?」の議論を終結させることができたので満足です(たぶん)。

デコイについて

当日はC-130フレアだけ示しましたが、第二次世界大戦でのハリボテ戦車のデコイなど、面白い話は色々転がっています。お近くの軍事オタに聞いてみると良いでしょう。

kippoのバナーについて

当日にwakatonoさんから、「kippoはpythonで書かれているので、返すバナーをランダム化すればいい」とコメントをもらいました。確かに簡単ですし、面白いと思います。

こういうイメージ。↓

root@kali:~# nmap -sV -p0-65535 192.168.2.66
....(snip)....
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 5.3 (protocol 2.0)
2200/tcp open  ssh     OpenSSH 5.1p1 Debian 5 (protocol 2.0)
2201/tcp open  ssh     Sun_SSH 1.1 (protocol 2.0)
2202/tcp open  ssh     OpenSSH 5.3 (protocol 2.0)
2203/tcp open  ssh     OpenSSH 5.1p1 Debian 5 (protocol 2.0)
2204/tcp open  ssh     OpenSSH 4.6 (protocol 2.0)
2205/tcp open  ssh     OpenSSH 5.3p1 Debian-3ubuntu7 (protocol 2.0)
2206/tcp open  ssh     OpenSSH 5.1p1 FreeBSD-20080901 (protocol 2.0)
2207/tcp open  ssh     Sun_SSH 1.1 (protocol 2.0)
2208/tcp open  ssh     OpenSSH 5.5p1 Debian-6+squeeze2 (protocol 2.0)
2209/tcp open  ssh     OpenSSH 5.3 (protocol 2.0)
....(snip)....

これなら、どれがホンモノのsshかの推定は困難だし、面倒でもありません。

Port Knockingについて

当日質問もいただきましたが、事前に特定のポートにアクセスしないと対象ポートに到達できないようにするPort Knockingというアプローチもあります。

私はknockdはきちんと運用したことが無いので(rsyncとかでの連携ホストがある場合、運用がメンドくさそうだなぁ〜、と思っていた)、すっぽり話題として抜けちゃいました。ちょっとマジメに触ってみて、何かあれば後日書くかも。

宣伝

6月にLinuxの入門書を出しました。Linux初心者にいい本だなぁと我ながら思っているので、ぜひポチっとしてお買い求めください!

新しいLinuxの教科書

新しいLinuxの教科書

2015-06-05

Linux入門書を出しました:「新しいLinuxの教科書」

えらく長いことかかってしまいましたが、Linuxの入門書を書きました。「新しいLinuxの教科書」というタイトルで、友人の三宅氏(id:mollifier)との共著です。

新しいLinuxの教科書

新しいLinuxの教科書

Linuxの入門書にも色々な切り口がありますが、本書は「CLI(コマンドラインインタフェース)」と「シェル(bash)」を中心としました。というか、ほぼそれしか書いていません。後半は、ページを多く割いてシェルスクリプトについて入念に解説しています。マウスを使う場面はほとんど出てきませんから、本書を読む際にはマウスを窓から投げ捨ててしまっても問題ありません。

目次については、SBクリエイティブのページに掲載されていますので参照ください。

mollifier氏はバリバリのプログラマで、私はサーバ構築やネットワークセキュリティなどのいわゆるインフラエンジニアなため、2人で色々もみ合うことでイイ感じになったかなと思っています。

対象読者について

想定する読者は以下のような方です。

おすすめする読者
  • とりあえずLinuxを学習するためにインストールしてみたが、マウスでちょっとつっつくくらいしかできておらず、CLIの基礎知識をしっかり身につけたい
  • Linuxのコマンドラインを基礎からきちんと学習したい
  • 今までなんとなく自己流でLinuxを学んでいたので、一度体系的に基礎を固めたい
  • Gitの基本操作を身につけたい

第19章で、mollifierが渾身の「Git入門」を書いてくれたので、ここだけでも一読の価値があると思います。

おすすめしない読者

本書はシェルの操作を中心したLinux入門書であるため、以下のような目的の方は読んでみても期待外れとなるかもしれません。

  • GUIを利用して、「ここをクリックして設定」などのスクリーンショットを多用した解説書が欲しい
  • ApacheやTomcatなど、サーバ構築の入門のためのLinux解説書を求めている
  • Linuxの各種設定(ネットワーク、ユーザ管理、セキュリティ等)についての入門書を求めている
  • Linuxで、RubyやPHPを利用したプログラミングを行いたい
  • Linuxカーネルに対する知識を得たい

シェルスクリプトをbashで書く意味

本書ではシェルスクリプトに多くのページを割いていますが、そこではすべて「#!/bin/bash」として、bashスクリプトで記述しました。なぜシェルスクリプトを書く際にshではなくbashを使うのかは、本書内でも詳しく述べています。しかし炎上しやすいテーマなのでここにも少し理由を書いておきます。

私がbashスクリプトを勧めるようになったきっかけは、昔に関根達夫氏の「UNIXシェルスクリプトハンドブック」を読んだことに由来しています。

この本はすべてのシェルスクリプトをbashで記載しており、冒頭でその理由として、「移植性に気を使ってshで書いても、結局はLinux/Solaris/BSD間の実装の差に苦労する。しかしbashは、GNUによる実装ひとつしか無い。だから機種間の実装による差に悩まされず移植性に優れている。シェルスクリプトはshではなく、むしろbashで書くべき」と述べられています(昔に読んだので細かい表現が若干違うかもしれません)。

当時の私は、DebianとRedHatとSolarisとHP-UXとAlphaのDigital UNIXの/bin/shの差に苦労しており、この主張に全面的賛同しました。最近はSolarisにも普通にbashが入っていますから(それどころか最近のSolarisはzshすらデフォルトで入っています)、bashをわざわざ避ける理由はもうありません。このような主張をされている方は非常に少ないのですが、言われてみればその通りで、どうして今まで思いつかなかったのだろう? という感じです。(なお、bashスクリプトなのにshebangを「#!/bin/sh」にするのは死罪に値します。決してやってはいけません)。

これ以降、私はシェルスクリプトをshスクリプトではなくbashスクリプトで書くようになりました。ただし、たとえばFreeBSDではbashは/usr/local/bin/bashにインストールされるので、「本当に/bin/bashでいいのか」問題はまだ残っているのですが……。

書き足りなかったこと

まず、ネットワーク周りの設定については全くと言っていいほど書いていません。pingコマンドがほんのちょっと登場するだけです。これにはいくつか理由はあるのですが、単純に分量が多くなりすぎてムリということと、本書はシェルの使い方を基本とした本ですから、分野からしてそもそも対象外だな、と判断しました。

また、Linuxの運用管理に関わる部分もほとんど触れていません。起動・終了とパッケージのインストールについては触れましたが、cronの設定やサービスの起動など、一般的なLinuxサーバ入門的な部分はありません。またカーネルパラメータなども出てきません。これらは、この本で基礎を身につけたあと、それぞれ興味のある方向に進んでくださいというスタンスです。

細かい点で言うと、bashのhelpコマンドをそういえば紹介していなかったな……というのが心残りです。例えばbashの組み込みコマンドsetヘルプを読むには「man bash」としてから「SHELL BUILTIN COMMANDS」のところのsetコマンドを読めばいいのですが、bashのmanは巨大なため、これはいささか不便です。この場合、次のようにhelpコマンドを使えば簡単に組み込みコマンドのヘルプを参照できます。

$ help set

参考文献

今回の本を書くために様々な書籍を参考にしましたが、私が特に意識したのは以下の2冊です。

たのしいUNIX―UNIXへの招待 (Ascii books)

たのしいUNIX―UNIXへの招待 (Ascii books)

The Linux Command Line: A Complete Introduction

The Linux Command Line: A Complete Introduction

特に坂本文さんの「たのしいUNIX」は、私がUNIXを学び始めた15年ほど前に読み、当時とても面白く読んだことを覚えています。今読み返してみても楽しめますし、2015年現在でも役に立つ素晴らしい良書とは思うのですが、やはりどうしても時代の流れは感じてしまいます(Linuxは全く登場しませんし、端末エミュレータは使わず物理端末を使う前提で書かれていますしね……)。非常におこがましいとは思いますが、「たのしいUNIX」の現代版とでもいうようなコマンドライン中心の本が書きたいな……と長いこともやもやしていたので、その野望はちょっぴり達成できたかな、と思います。

また、「The Linux Command Line」については、以下のURLでPDF版が無料で公開されています。("Download it here."からダウンロードできます)

非常に優れたテキストですから、英語に抵抗のない方はぜひ読まれることをおすすめします。この本は「ほとんど」どころか「一切」マウスを使う操作が出てこない、今どき硬派なLinux入門書ですが、その内容は非常に丁寧で読みやすいものになっています。

おわりに

mollifier氏による書籍紹介も合わせてお読みください:

「あの、ふだんはzshのことしか語らないmollifier氏がbashを語る」という点でも、本書は貴重です。

2015-05-16

Certificate Transparencyについて勉強会で発表したので、その補足や落ち穂拾い

終了後にメモするのをサボっていたら1週間経ってしまいましたが、主催している「すみだセキュリティ勉強会」を久々に開催しました。

発表者の@inaz2さん、@furandon_pigさん、ありがとうございました。

今回の発表内容

私の発表は、最近ちょっと気になっているCertificate Transparencyについてでした。発表資料は以下です(パワポ資料を、ノート付きPDFにしています)。

内容については資料を見てもらうとして、以下、時間内で話せなかった部分などを補足します。

復習と用語整理

まず、用語を思い出しておきましょう。

  • CT: Certificate Transparency。CTログサーバに発行した証明書登録することで、証明書発行の「透明性」を確保する仕組み。
  • SCT: Signed Certificate Timestamp、署名付き証明書タイムスタンプ。CTログサーバに証明書を登録した際に、発行してもらえるタイムスタンプ。

はじめに復習です。Certificate Transparencyに対応していない証明書は、Google Chromeで閲覧すると、次のように「公開監査記録がありません。」というちょっと気になるメッセージが表示されます(悪の帝国Googleの、不安を煽る手口です)。

f:id:ozuma:20150523230051p:image:w500

一方、Certificate Transparencyに対応している証明書は、Google Chromeで閲覧すると次のように「公開監査が可能です」と表示されます。次の図はドイツ銀行の例です。

f:id:ozuma:20150516142447p:image:w500

ちなみにドイツ銀行は、「db.com」という、世界中のデータベースエンジニアが羨むドメインを所有しています。

証明書の中身を見ると、次のようにX509v3 extensionsの、OID=1.3.6.1.4.1.11129.2.4.2としてSCTが埋め込まれています。

f:id:ozuma:20150516145026p:image:w360

OpenSSLでも、現在最新の1.0.2aでx509サブコマンドの-textオプションを使えば、次のように証明書内のSCTを直接見ることができます。

$ echo Q | openssl s_client -connect www.db.com:443 | openssl x509 -text -noout
....(省略)....
X509v3 extensions:
    X509v3 Subject Alternative Name:
        DNS:db.com, DNS:staging.ext.intranet.db.com, DNS:staging.www.db.com, DNS:www.db.com
....(省略)....
  CT Precertificate SCTs:
      Signed Certificate Timestamp:
          Version   : v1(0)
          Log ID    : A4:B9:09:90:B4:18:58:14:87:BB:13:A2:CC:67:70:0A:
                      3C:35:98:04:F9:1B:DF:B8:E3:77:CD:0E:C8:0D:DC:10
          Timestamp : May  6 08:29:23.108 2015 GMT
          Extensions: none
          Signature : ecdsa-with-SHA256
                      30:46:02:21:00:9C:59:F7:55:82:3D:88:13:62:D2:7A:
                      0B:3E:A7:E5:60:41:D2:B1:17:75:2F:0D:FD:BF:CF:F4:
                      AA:1A:50:D9:E1:02:21:00:89:20:3A:68:74:53:5B:D8:
                      74:9D:6D:86:A7:69:9F:54:C1:F3:20:C3:F8:E9:79:0E:
                      4E:F1:DE:A9:77:75:5D:2F
      Signed Certificate Timestamp:
          Version   : v1(0)
          Log ID    : 56:14:06:9A:2F:D7:C2:EC:D3:F5:E1:BD:44:B2:3E:C7:
                      46:76:B9:BC:99:11:5C:C0:EF:94:98:55:D6:89:D0:DD
          Timestamp : May  6 08:29:23.337 2015 GMT
          Extensions: none
          Signature : ecdsa-with-SHA256
                      30:45:02:21:00:C4:34:D5:81:95:B4:22:2D:D6:1F:4B:
                      86:04:82:A7:0C:C8:5B:DA:C7:40:CA:03:BA:B8:F1:73:
                      65:8B:3F:48:72:02:20:6C:FD:4C:FE:04:0F:F0:13:25:
                      B7:9E:0F:ED:56:71:10:DF:E5:7E:5B:F2:1D:E7:CB:21:
                      63:F4:9D:41:15:D3:0C
....(省略)....

以下、上記の勉強会資料で抜けていた部分や補足、落ち穂拾いです。

SCTは証明書に埋め込まないといけない?

発表では、SCT(Signed Certificate Timestamp)が上記のように証明書内に埋め込まれている様子を確認しました。しかしSCTは、仕様上は証明書に埋め込む必要は無く、TLS extensionもしくはOCSP Staplingを利用しても構いません。(OCSP StaplingだってTLS Extensionを利用しているので、こういう言い方は若干語弊があるけど、とりあえず細かい部分は無視)。

が、これらの方法に対応するにはWebサーバ自体の対応が必要です。一方、証明書に埋め込むだけならば、ひとつフィールドが増えるだけなので既存のアプリなどもほぼ影響を受けません。

そのため現実的には、2015年現在、SCTは証明書に埋め込むパターンでしか使われていません(し、たぶんこれから先もそうでしょう)。

SCTを証明書に入れ込む流れの奇妙な点

勉強会でちらりと言いましたが、実はCTログに証明書を登録する過程には「おかしい」ところがあります。

f:id:ozuma:20150516151032p:image:w500

証明書をCTログサーバに登録して、SCTをもらうわけですが……CTログサーバに登録する時点では、証明書には当然のことながらSCTは入っていません。しかし皆さんが先ほどドイツ銀行の例で見たように、証明書にはちゃんとSCTが埋め込まれています。これはなぜでしょうか?

答えを先に言うと、CTログサーバに登録する証明書は「事前証明書(Precertificate)」であり、実際の証明書とは違うものだからです(ここで、「違う」の解釈で実は色々と揉めることになるのですが、とりあえず置いておきます)。

あるドメイン所有者が、CT付き証明書を発行するフローは、実際は次のようになります。

f:id:ozuma:20150516174138p:image:w500

ここで注目すべき点が、事前証明書(Precertificate)の存在です。

事前証明書(Precertificate)

先ほど述べたように、CTログサーバからSCTを発行してもらうためにはまず証明書が必要です。このためSCTを証明書に埋め込みたい場合には、次のような手順を踏む必要があります。(ここ、理解が若干怪しいので後で修正するかも)

  1. ドメイン保有者は、自らの秘密鍵を元に証明書署名要求(CSR)を作成して認証局(CA)に送付し、公開鍵証明書の発行を依頼する。
  2. 認証局は、ユーザから受け取ったCSRからTBSCertificateを元にして、事前証明書(Precertificate)を発行する。この事前証明書は、実際に利用されないように、毒入れ(Poison Extensionの付加)をしておく。発行した事前証明書をCTログサーバに登録する。
  3. CTログサーバは、証明書をログに登録してタイムスタンプ(SCT)を払い出す。
  4. 認証局は、SCTを入れ込んだ証明書を、事前証明書と同一のシリアルID(Serial Number)で作成する。
  5. 認証局は、SCTを入れ込んだ証明書をドメイン所有者に発行する。

※CTログサーバは実は誰でも登録できるのですが、ここでは一番ありがちなケースとして、ドメイン保有者が認証局から証明書を発行してもらうケースを考えています。

このうち、いかにもビミョーなのが、「毒入れをした事前証明書を発行する」「同一のシリアルIDで証明書を発行する」という2点でしょう。事前証明書には、OID 1.3.6.1.4.1.11129.2.4.3で定義されるpoison extensionを入れる必要があります(これもCertificate TransparencyのRFC 6962に記述がありますので、興味のある方は読んでみてください)。しかし、一般的なPKIの仕組みから見て、いきなりこんなものが出てくると、「なんだか気持ち悪いなぁ」という感想しか私は持てませんでした(個人的な感想です:小波感)。

さらに気持ち悪いのは、「事前証明書と、SCTを入れ込んだ証明書は、同一のシリアルIDで発行する」という点でしょう。社内認証局などを運用したことのある方ならお分かりでしょうが、認証局が同一のシリアルIDで違う証明書を発行するというのは、非常にイレギュラーな処理であり普通はやりたくありません。Certificate Transparencyは認証局にこれを強要しており、美しくありません。あるいは、スマートじゃありません、と言っても良いです。

事前証明書を失効(Revoke)させれば良いのでは

ここまでの話を聞いて、ちょっと詳しい方なら「じゃぁ、その事前証明書を失効(Revoke)させればいい」と思ったかもしれません。残念ながら、Certificate Transparencyの仕組みではそれはできません。

ここで、証明書失効リストの仕組みについてまず確認しておきましょう。先ほどのドイツ銀行の証明書を見てみると、下記のように「CRL配布ポイント」というフィールドがあります。

f:id:ozuma:20150516180625p:image:w500

CRLとはCertificate Revocation List、すなわち証明書失効リストのことです。このURLにアクセスすることで、失効リストを入手することができます。

証明書失効リストは、例えばWindowsならば次のように、ファイルをダブルクリックすることで簡単に中身を閲覧できます。

f:id:ozuma:20150516180733p:image:w500

これを見ると分かるように、一般的な証明書失効リストはシリアルIDに対して証明書を失効させます。通常、発行した証明書には、それを発行したIssuerごとに一意のシリアルIDが付いていますから、このIDを指定して失効させれば良いわけです。

が、先ほど見たようにCertificate Transparencyの仕組みでは、事前証明書とSCTを入れ込んだ証明書の2つは、同一のシリアルIDを持ちます。このため事前証明書を失効させると、肝心のSCTを入れ込んだ証明書も失効してしまいます。このため、事前証明書をシリアルIDを指定した方式で失効させることができません。

CT対応・非対応をユーザが選択できないか?

勉強会で解説しましたが、証明書をCT対応させてしまうと、証明書が誰でもアクセスできるCTログサーバに登録されます。そのため、CTログサーバをクロールしてCommonNameを収集されることにより、サーバのFQDNは秘匿することができず、全世界に公開されてしまいます。(例えば、test-admin-auth.example.comとかいうテストサーバは、内部だけで使いたいので、FQDN自体を外部に出したくありませんよね)。

このため、ユーザが証明書ごとに、CT対応させるかさせないかを選べるのがベターであると個人的には考えます。

ちなみにCybertrustのWebを見てみると、CT対応・CT非対応の証明書を選択してダウンロードできるようになっています。

これを見て「おっ」と思ったのですが、よく見ると証明書自体は問答無用にCTログサーバに登録してしまい、ユーザがSCT有・無の証明書を単に選択してダウンロードできるだけのようです。他の大手の認証局のWebも確認しましたが、「そもそもCTログサーバに登録しない」というオプションを提供しているところは無いようです。(あったらすみません調査不足です)

なお、一部の認証局はEV証明書のみCTログサーバに登録しているので、敢えてOV証明書を使うことでサーバのFQDNを秘匿する、という手があります。しかしこれは現時点での微妙な解なので(OV証明書もそのうちCTログサーバに登録するかもしれません)、やはり根本的にCTログサーバに登録しないオプションがあるといいな、というのが私の感じたことでした。

参考リンク

2015-05-01

Certificate Transparencyガチャを作った。

このところ、Certificate Transparency(RFC 6962)について調べている。

これについてはまだ日本語で書かれた解説も少なく、なかなかつかみ所が無くて理解に苦労した。

要するに、発行されるSSL証明書すべてをログDB(CT Log)にガシガシ記録し、みんなが見られるようにしておく。そうして監査ログを作っておき、「多数の目による監視」をして、意図しないニセモノ証明書の発行を防ごう……というのが表向きの目的のようだ。

しかしこのCTにはイロイロと突っ込みどころも多くて、あまりスマートじゃないなぁと私は思っている。とりあえず少し調べてみて、私が「これはどうかなぁ……」と思うのは次のあたり。

  • 証明書にCTログのタイムスタンプ(SCT)を付けるために、本物の証明書と同じシリアルIDを持つPrecertificateを作らないといけない。これはとても気持ち悪い
    • Precertificateと本物のCertificateは同一シリアルIDを持つため、Precertificateは失効(Revoke)させることもできない
    • このためPrecertificateには、実際に利用されないようpoison extensionを入れておくんだけど、それも気持ち悪すぎる
  • 「CTログ登録しないと、ChromeからEV証明書の緑表示を消すよ!」と脅しをかけるようなGoogleの態度がよろしくない
  • あまり外部に公開したくないFQDNも、証明書を作っただけで強制公開されるというのは微妙

しかし、CTはまだ知名度が低すぎるので、まずは簡単に触れるツールがあった方が良い。ということで作ってみた。Certificate Transparencyガチャ。

Certificate Transparencyガチャとは何か

f:id:ozuma:20150501002711p:image:w360

「number: 」のところにCT logのエントリ番号を入れると、そのCertificateを閲覧することができる。

例えば、2015/04/30現在、一番最後のエントリである7352182を入力すると、www.ageru.ne.jpのCERTIFICATEが表示される。

Log Entry: 7352182
Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Domain Validation CA - SHA256 - G2
Subject: C=JP, OU=Domain Control Validated, CN=www.ageru.ne.jp
-----BEGIN CERTIFICATE-----
MIIFBjCCA+6gAwIBAgISESGzoK6eRVuALX5brYlguRj7MA0GCSqGSIb3DQEBCwUA
MGAxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTYwNAYD
VQQDEy1HbG9iYWxTaWduIERvbWFpbiBWYWxpZGF0aW9uIENBIC0gU0hBMjU2IC0g
RzIwHhcNMTUwNDI4MDkzMzMyWhcNMTYwNjAyMDU1NTIyWjBKMQswCQYDVQQGEwJK
UDEhMB8GA1UECxMYRG9tYWluIENvbnRyb2wgVmFsaWRhdGVkMRgwFgYDVQQDEw93
......(省略)......
6MrYU4qFxnQhlAa54NMn6BbdEr5YQyCxFBS63usgqTj0IIaOjFU6g9i8ohZwQNG9
OEokLJ7uQrxwezGh9rFQL2vo2lzn87uvyvGjwR/YLozYtbsU3FoPtxDDgT7u07Vw
jdslRjp+DpuPdDo562yLyO83JC4pzgn6ZJTUsxIUhK5QsRmOE/MOJgDJ
-----END CERTIFICATE-----

CT logはURLをポチっと叩けばサクっと簡単に見られるようなお手軽構造ではないので、こういうものがあると便利! ……だと思う。

そして目玉機能が、その下の「GACHA GACHA」機能。「I'm Feeling Lucky」ボタンを押すことで、CT Logからランダムに証明書を抽出して表示することができる。何度も試してみれば、どこかの組織原則外部公開しない開発用サーバとか、運が良ければ引けるかもしれないぞ! しかもこのガチャ、なんと非課金です。

もう少し細かい

Certificate Transparencyについて、次回のすみだセキュリティ勉強会で発表します。

是非お越しください……と言いたいところなのですが、既に満員になっちゃいました。次回をご期待ください。

参考リンク

GMO GlobalSignのブログ、Certificate Transparencyとはなにか がとても分かりやすく参考になりました。

2015-03-20

sslscanでサーバのSSL/TLS状態を簡単にチェックする

最近はSSL/TLSのセキュリティ問題が多発しているため、自分運用しているサーバのSSL/TLSの設定をテストしたいという人は多いと思います

SSL/TLSの状態をチェックするには、Qualys SSL LabsのSSL Server Testがよく使われます。しかしこれは外部から第三者にスキャンさせるわけですから、(心理的・社内政治的な)敷居が高いという点もありますし、そもそもインターネット側から直接接続できない環境のテストが行えません。

そこで、IPアドレスを指定するだけでよろしく対象のSSL/TLSサーバの状態をチェックしてくれるツールがあると便利だな、ということになります。本稿では、このような目的に利用されるsslscanというコマンドを紹介します。

sslscanはLinuxで動作し、ペネトレーションテスト用に使われるKali Linuxにもインストールされているお手軽なSSLチェックツールです。ただし、このソフトウェアは結構スピードでモリモリとバージョンアップしているので、少し前の知識で使っていると色々置いてきぼりになってしまいます。最近はsslscanがかなりいい感じになってきているので、若干細かすぎて伝わらない感があるけど、頑張って伝えます。

sslscanの入手

sslscanはGitHub上で開発されているため、本体はそちらから入手できます。なお、これは本来のsslscanからのfork版であるようです。そのため作者に敬意を表して、rbsec-sslscanと呼んだ方がいいかもしれません。本稿では煩雑になるため、単にsslscanと記述します。

なお先述した通り、最新版のKali Linuxを使っているならば既にイイ感じのが入っていますから、特に自分でビルドする必要はありません。しかしここでは、自分でビルドする際の注意点などを記しておきましょう。

staticリンク版の提供

sslscanは当然のことながらOpenSSL関連のライブラリを利用するのですが、昨今の事情から、OS付属のOpenSSLをそのままテストツールに使うことは望ましくありません。

例えばSSLv2は既にobsoleteとなっているため、最近のLinuxディストリビューションでは、OpenSSLのSSLv2サポートをdisableにしてコンパイルしたパッケージが提供されているものがあります(Ubuntu 14.04など)。これは「普通の」利用者にとっては当たり前なのですが、テストツールを使いたい立場としてはちょっと困ります。そのようなobsoleteな設定が無いかどうかをテストしたいのに、OS環境に引きずられてテストすべきプロトコルで投げてくれないのは困るわけです。

そこで、「ほんならsslscanの実行ファイルにOpenSSLのライブラリをダイナミックリンクせぇへんで、『アリアリ』のOpenSSLをstaticリンクしてmakeしたればええやん?」という発想がでてきます。そのため今のsslscanは、"make static"とコンパイルすることで、OpenSSLのライブラリをstaticリンクしてビルドすることができます。

sslscanをビルドする際に「make static」と打つと、次のようにまずその場でOpenSSLのリポジトリをドサっと持ってきて、OpenSSL自体をビルドするところからはじまります。なかなかにロックです。

f:id:ozuma:20150320165654p:image:w640

これで、動作させるOS環境上のOpenSSLは利用しない、ポータブルなテストツールができます。こうしてビルドしたsslscanコマンドには、次のようにlibssl.soやlibcrypt.soがリンクされていないことが分かります。

[ozuma@cent6 sslscan]$ ldd ./sslscan
  linux-vdso.so.1 =>  (0x00007ffffe9d3000)
  libdl.so.2 => /lib64/libdl.so.2 (0x00007fec01756000)
  libc.so.6 => /lib64/libc.so.6 (0x00007fec013c2000)
  /lib64/ld-linux-x86-64.so.2 (0x00007fec01969000)

現在のKali Linux 1.1.0 には、このstaticリンク版が入っており、すぐに使うことができます。

static版かどうかの判定

自分が使っているsslscanコマンドがdynamic版なのかstatic版なのかは、--versionオプションを付ければすぐに分かります。以下はKali Linux 1.1.0に付属の、staticリンクされたsslscanコマンドの例です。

root@kali:~# sslscan --version
    -static
    OpenSSL 1.0.1m-dev xx XXX xxxx

このように、静的リンクされたsslscanでは「-static」と表示されます。あるいは、先ほどのようにlddコマンドで確認しても良いでしょう。

ちなみにKaliのsslscanコマンドは特殊で、上で見たように「-static」の前に何もありません。手でビルドすると、通常は次のようにバージョン情報が合わせて表示されます。

[ozuma@cent6]% ./sslscan --version
    1.10.0-rbsec-1-gf53f2f4-static
    OpenSSL 1.0.1n-dev xx XXX xxxx

SSLv2チェック

sslscanコマンドとSSLv2チェックのお話をする前に、ここで、Ubuntu 14.04の標準パッケージにあるsslscanコマンドを確認しておきましょう。

結論から先に言うと、Ubuntu 14.04の標準パッケージのsslscanコマンドは、テスト用ツールとしては不適切です。Ubuntu14標準パッケージのsslscanはバージョン1.8.2ですが、次のようにlibssl.soやlibcrypt.soがOS標準のOpenSSLライブラリにリンクされています。

ozuma@ubuntu14:~$ ldd /usr/bin/sslscan
  linux-vdso.so.1 => (0x00007fffe05fe000)
  libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f4df9653000)
  libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f4df9279000)
  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4df8eb2000)
  libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4df8cae000)
  /lib64/ld-linux-x86-64.so.2 (0x00007f4df98cc000)

Ubuntu 14.04ではOpenSSLパッケージのSSLv2がはじめから無効化してありますから、このsslscanコマンドもSSLv2はテストしてくれません。これを知らずにこのまま実行すると、「SSLv2を検査しているつもりが検査していなかった!」ということになります。

なお最近のsslscanコマンドは気が利いており、実行時に、利用しているOpenSSLのライブラリがSSLv2をサポートしているかどうかをチェックして、サポートしていない場合は警告してくれます。

次の例は、Ubuntu 14.04上で、sslscan Ver.1.10.0を「make static」ではなく「make」でダイナミックリンクでビルドしたものです。これは当然Ubuntu標準パッケージのOpenSSLを使うため、SSLv2をサポートしません。そのため、実行時に次のように「OpenSSL version does not support SSLv2」と赤字で警告してくれます。

f:id:ozuma:20150320170310p:image:w640

また、ちょっと前のKali Linux(確か、1.0.6の頃)に付属していたsslscan 1.8.2では、TLS1(TLS 1.0)しか対応していませんでした。現在のsslscan 1.10.0では、ちゃんとTLSv1.1、TLSv1.2に対応しています。(なお、この頃のKali Linux付属のsslscanは、先述のダイナミックリンク版だったため、SSLv2はテストしてくれないことにも注意が必要です)。

前置きが長くなりましたが、sslscanは進化が早いためなるたけ最新版を、staticリンク版で使いましょう。ということです。

sslscanの機能と出力

sslscanコマンドの使い方は簡単で、コマンドライン引数に対象のIPアドレスを記述するだけです。なお、対象ポートはデフォルトで443/tcpとなるため、別のポートを指定したい場合には「IPアドレス:ポート番号」の形でコロンで指定します。

$ sslscan <IPアドレス>

または

$ sslscan <IPアドレス>:<ポート番号>

f:id:ozuma:20150320171334p:image:w640

現在、sslscanコマンドには次のようなチェック機能があります。なお、オプションを指定することでチェックを省略することもできます。

このうち最後のCipherリスト出力が、sslscanのメインテーマ(?)です。ここでは、基本的に問題のある設定が赤や黄色で表示されます。

f:id:ozuma:20150320174724p:image:w640

例えば上の例では、「TLSv1.0」や「TLSv1.1」のところは黒字なので問題ありません(先ほど、SSLv2は赤字になっていましたね)。40bitの「40」が赤字になっていますが、これは鍵長が短い(weak)警告です。またピンク色になっているのはADH(anonymous) Cipherの警告、黄色はRC4の警告です。

このようにsslscanコマンドは結果を色で区別するため、パッと見は分かりやすいのですが、テキストに出力して後で見るときには困ってしまうのが欠点です。例えば鍵長が短いCipherは色で表示せず、[WEAK]とか付けて表示するモードがあると使いやすいんですけどね。

オプションの紹介

サポートしていないCipherも表示: --failed

sslscanの1.8.2の頃までは、Cipherリストはダメだったものも接続できたものも、全てが表示されていました。しかし現在の1.10.0では、接続できた(Accept)のもののみ表示されます。

それでは困る(試したCipherすべてを表示しておきたい)場合は、--failedオプションを付ければ、試行したすべてのCipherが表示されます。

f:id:ozuma:20150320173619p:image

これで、sslscan1.8.2の頃と同じ動作にすることができます。

結果をXML出力: --xml

xmlオプションを利用することで、出力結果をxmlファイルとして保存できます。ただし、警告のカラー表示などの情報は一切入らないので、純粋に結果テキストだけが保存されます。

テストの一部省略: --no-heartbleed など

「--no-heartbleed」や「--no-compression」などを指定することで、一部のテストを省略できます。Heartbleedチェックは応答待ちで少々時間がかかるので、大量のホストに実行する場合は指定してテストを省略した方がいいかもしれません。

すりーでぃーいーえす(3DES)の112bit問題

最後に、3DES(トリプルデス)の鍵長問題について補足しておきます。

sslscanでスキャンしていると、3DESのbit数が168bitではなく112bitと表示されることがあります。

f:id:ozuma:20150320175026p:image:w640

これは、3DESでは原理上の鍵長は56(bit)×3=168(bit)ですが、既知の攻撃手法によって実質の鍵長が112bitとなってしまうためです。そのため最近のOpenSSLでは、3DES系の暗号方式の鍵長は112bitと表示されます。

この辺の事情は、以下のenigma63様のスライドが分かりやすいため必見です。ssmjpで聞かせて頂きました。すりーでぃーいーえす。

参考:3DESの件 〜俺、112bitになります〜

(おまけ) Windows版sslscan.exe

READMEには「まだexperimentalだ」という記述がありますが、sslscanはWindows向けにコンパイルされたsslscan.exeがリリースされています。

とりあえず、私の手元でちょっと試した限りだと特に問題なく動いているようです。

f:id:ozuma:20150320220527p:image:w640

どうしてもWindowsで動かさないといけない人は、試してみると良いかもしれません。

結論

細かすぎて伝わらない部分が多かったかもしれませんが、だいたい語りました。まぁ、Kali Linuxを最新版にして使いましょう、ってことですな。