nmapのクリスマススキャン(-xS)をもっとキラキラさせよう
あまりに長いあいだこのブログを放置していましたが、大丈夫です。生きています。
ただ、ちょっとメンタル的に色々ありすぎて放置していました。。。さすがに1年以上も更新がないとツラいので、ちょうどクリスマスということで、ポートスキャナツールNmapの、クリスマススキャンについて軽く書いてみることにしました。
Nmapとクリスマス
今日は12月25、クリスマスです。セキュリティ診断の業界では有名ですが、12月25日にnmapで-vオプションを付けてポートスキャンをすると、nmapが、
"Nmap wishes you a merry Christmas!"
というメッセージを出してクリスマスを祝ってくれます。
診断業界の皆は、クリスマスに脆弱性診断をするとき、このメッセージを見るとみんなほんわかとした気分になったものです……(んなわけねーだろ! という誰かの声が聞こえる)
この際Nmapは、ついでに、"Specify -sX for Xmas Scan"と、クリスマススキャンのやり方も教えてくれます。クリスマススキャンとは、通常のSYNスキャンと違い、TCP FlagsのURG/PSH/FINビットを立ててスキャンするものです。一応nmapのマニュアルには、こういう特殊なスキャンをすることで一部のファイアウォールを通過できる場合がある……ということが書いてありますが、まぁこじつけで、実践でこのスキャンを使うことはまず無い。それよりも、ビットがいっぱい立っていてピカピカしているからクリスマスツリーのようだ……ということでクリスマススキャンと呼ばれる説が有名です。
クリスマススキャンをもっとピカピカさせる
さて、こうなると、「たったの3bitじゃもの足りん、TCP Flagsの全bitを立ててもっとピカピカさせよう」と思うのが人情というものです。nmapでは--scanflagsオプションを付けるとこれを実現できます。
やり方は2つあって、一つはTCP Flagsは6bitなので、「--scanflags 63」と指定すれば全ビット起立したパケットが飛びます。もう一つは文字列指定で、「--scanflags URGACKPSHRSTSYNFIN」と、URGからFINまで全部並べると、これも全TCP Flagsのビットが立ったパケットが飛びます。
# nmap -v --scanflags 63 -p 22 10.5.17.208 または # nmap -v --scanflags URGACKPSHRSTSYNFIN -p 22 10.5.17.208
これで、6bit立ちました。キラキラしてますね。
TCP Flagsは9bit
と、ここまで書いておや? と思った方もいるでしょう。そう、実はTCP Flagsは後年さらに拡張されており、現在は6bitではありません（私が大学で学んだときは、まだ6bitだったんだけどな〜）。
元々予備に用意されていた予約ビットを使う形で、まずRFC 3168で、ECN-Echo(ECE)とCongestion Window Reduced(CWR)の2bitが追加されました。さらにRFC 3540で、ECN-nonce(NS)の1bitが追加されました。というわけでこれでもっとピカピカキラキラしたスキャンができるぞ! というわけですが、ちょっと試した限り、--scanflagsは255までしか指定できないので9bitめをキラキラさせることができませんでした。本当はできるのかもしれませんけど、私の知識不足＆時間切れです。
# nmap -v --scanflags 255 -p 22 192.168.2.9 または # nmap -v --scanflags CWRECEURGACKPSHRSTSYNFIN -p 22 192.168.2.9
これで、8bitキラキラさせることができました! これならようやくクリスマスツリーと言えるでしょう(たぶん)。なお、このスキャンの実用性は、まぁ、自己満足だけなのでゼロですね……。
補足すると、scanflagsオプションは奥が深く、「この組み合わせでOS検出ができるぞ!」とか、「クリスマススキャンで特定のACLが回避できるぞ!」とか色々と議論・研究がされているのですが、ちょっとそこまで詳しく調べてない＆よく知らないのでここではつっこまないことにします。
ということで中途半端ですが、おしまい。
参考リンク
- Nmapの真実
- abendさんによるNmap面白ネタ、クリスマススキャンの話も出ています。おもしろ。
sshのポートをデフォルトの22/tcpから変えるべきか論争に、終止符を打ちました
また間が開きましたが、すみだセキュリティ勉強会2015#2を開催しました。発表していただいた@inaz2さん、@yasulibさん、ありがとうございました。当日の発表資料は上記の勉強会ブログからリンクしています。
今回の私の発表は、「攻撃を『隠す』・攻撃から『隠れる』」。ポートスキャンをするとsshが100個現れる「ssh分身の術」がメイン(?)です。
当初は、パケットヘッダやプロトコルのすき間にメッセージを隠したり、ファイルを隠すなども考えていたのですが……。あまりに盛りだくさんになりそうだったので、「ポートスキャンをいかに隠れて実行するか・ポートスキャンからどうやって隠れるか」と、ポートスキャンと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初心者にいい本だなぁと我ながら思っているので、ぜひポチっとしてお買い求めください!
- 作者: 三宅英明,大角祐介
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2015/06/06
- メディア: 単行本
- この商品を含むブログ (6件) を見る
Linux入門書を出しました：「新しいLinuxの教科書」
えらく長いことかかってしまいましたが、Linuxの入門書を書きました。「新しいLinuxの教科書」というタイトルで、友人の三宅氏(id:mollifier)との共著です。
- 作者: 三宅英明,大角祐介
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2015/06/06
- メディア: 単行本
- この商品を含むブログ (6件) を見る
目次については、SBクリエイティブのページに掲載されていますので参照ください。
mollifier氏はバリバリのプログラマで、私はサーバ構築やネットワークセキュリティなどのいわゆるインフラエンジニアなため、2人で色々もみ合うことでイイ感じになったかなと思っています。
対象読者について
想定する読者は以下のような方です。
シェルスクリプトをbashで書く意味
本書ではシェルスクリプトに多くのページを割いていますが、そこではすべて「#!/bin/bash」として、bashスクリプトで記述しました。なぜシェルスクリプトを書く際にshではなくbashを使うのかは、本書内でも詳しく述べています。しかし炎上しやすいテーマなのでここにも少し理由を書いておきます。
私がbashスクリプトを勧めるようになったきっかけは、昔に関根達夫氏の「UNIXシェルスクリプトハンドブック」を読んだことに由来しています。
UNIXシェルスクリプトハンドブック (Technical handbook series (001))
- 作者: 関根達夫
- 出版社/メーカー: ソフトバンククリエイティブ
- 発売日: 2004/03
- メディア: 単行本
- クリック: 8回
- この商品を含むブログ (11件) を見る
当時の私は、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)
- 作者: 坂本文
- 出版社/メーカー: アスキー
- 発売日: 1990/11
- メディア: 単行本（ソフトカバー）
- 購入: 5人 クリック: 34回
- この商品を含むブログ (8件) を見る
The Linux Command Line: A Complete Introduction
- 作者: William E., Jr. Shotts
- 出版社/メーカー: No Starch Press
- 発売日: 2012/01/11
- メディア: ペーパーバック
- この商品を含むブログを見る
また、「The Linux Command Line」については、以下のURLでPDF版が無料で公開されています。（"Download it here."からダウンロードできます）
非常に優れたテキストですから、英語に抵抗のない方はぜひ読まれることをおすすめします。この本は「ほとんど」どころか「一切」マウスを使う操作が出てこない、今どき硬派なLinux入門書ですが、その内容は非常に丁寧で読みやすいものになっています。
おわりに
mollifier氏による書籍紹介も合わせてお読みください：
Certificate Transparencyについて勉強会で発表したので、その補足や落ち穂拾い
終了後にメモするのをサボっていたら1週間経ってしまいましたが、主催している「すみだセキュリティ勉強会」を久々に開催しました。
発表者の@inaz2さん、@furandon_pigさん、ありがとうございました。
今回の発表内容
私の発表は、最近ちょっと気になっているCertificate Transparencyについてでした。発表資料は以下です（パワポ資料を、ノート付きPDFにしています）。
内容については資料を見てもらうとして、以下、時間内で話せなかった部分などを補足します。
復習と用語整理
まず、用語を思い出しておきましょう。
- CT: Certificate Transparency。CTログサーバに発行した証明書を登録することで、証明書発行の「透明性」を確保する仕組み。
- SCT: Signed Certificate Timestamp、署名付き証明書タイムスタンプ。CTログサーバに証明書を登録した際に、発行してもらえるタイムスタンプ。
はじめに復習です。Certificate Transparencyに対応していない証明書は、Google Chromeで閲覧すると、次のように「公開監査記録がありません。」というちょっと気になるメッセージが表示されます（悪の帝国Googleの、不安を煽る手口です）。
一方、Certificate Transparencyに対応している証明書は、Google Chromeで閲覧すると次のように「公開監査が可能です」と表示されます。次の図はドイツ銀行の例です。
ちなみにドイツ銀行は、「db.com」という、世界中のデータベースエンジニアが羨むドメインを所有しています。
証明書の中身を見ると、次のようにX509v3 extensionsの、OID=1.3.6.1.4.1.11129.2.4.2としてSCTが埋め込まれています。
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ログに証明書を登録する過程には「おかしい」ところがあります。
証明書をCTログサーバに登録して、SCTをもらうわけですが……CTログサーバに登録する時点では、証明書には当然のことながらSCTは入っていません。しかし皆さんが先ほどドイツ銀行の例で見たように、証明書にはちゃんとSCTが埋め込まれています。これはなぜでしょうか?
答えを先に言うと、CTログサーバに登録する証明書は「事前証明書(Precertificate)」であり、実際の証明書とは違うものだからです（ここで、「違う」の解釈で実は色々と揉めることになるのですが、とりあえず置いておきます）。
あるドメイン所有者が、CT付き証明書を発行するフローは、実際は次のようになります。
ここで注目すべき点が、事前証明書(Precertificate)の存在です。
事前証明書(Precertificate)
先ほど述べたように、CTログサーバからSCTを発行してもらうためにはまず証明書が必要です。このためSCTを証明書に埋め込みたい場合には、次のような手順を踏む必要があります。（ここ、理解が若干怪しいので後で修正するかも）
- ドメイン保有者は、自らの秘密鍵を元に証明書署名要求(CSR)を作成して認証局(CA)に送付し、公開鍵証明書の発行を依頼する。
- 認証局は、ユーザから受け取ったCSRからTBSCertificateを元にして、事前証明書(Precertificate)を発行する。この事前証明書は、実際に利用されないように、毒入れ(Poison Extensionの付加)をしておく。発行した事前証明書をCTログサーバに登録する。
- CTログサーバは、証明書をログに登録してタイムスタンプ(SCT)を払い出す。
- 認証局は、SCTを入れ込んだ証明書を、事前証明書と同一のシリアルID(Serial Number)で作成する。
- 認証局は、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配布ポイント」というフィールドがあります。
CRLとはCertificate Revocation List、すなわち証明書失効リストのことです。このURLにアクセスすることで、失効リストを入手することができます。
証明書失効リストは、例えばWindowsならば次のように、ファイルをダブルクリックすることで簡単に中身を閲覧できます。
これを見ると分かるように、一般的な証明書失効リストはシリアル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ログサーバに登録しないオプションがあるといいな、というのが私の感じたことでした。
参考リンク
- http://www.certificate-transparency.org/
- 公式サイト、まずはここを熟読しないと始まらない。
- http://tools.ietf.org/html/rfc6962
- Certificate TransparencyのRFC
- https://jp.globalsign.com/blog/2014/certificate_transparency.html
- CTについて色々調べる際、こちらのGlobalSignさんの記事が大変参考になりました。
- http://blog.livedoor.jp/k_urushima/archives/1764230.html
- Certificate Transparencyについて知るきっかけとなった、k_urushima様のブログ。証明書周りの情報が豊富で、大変参考になりました
