OpenVPNのセキュリティ周りの動作について気になった点をメモ
OpenVPN 2.3系、証明書認証を前提。だいたいmanpageから。 https://openvpn.net/index.php/open-source/documentation/manuals/65-openvpn-20x-manpage.html
各設定項目はデフォルトで安全よりに設定されている。ca, cert, keyを正しく設定すればしばらくは問題なさそう。
参考 https://openvpn.net/index.php/open-source/documentation/security-overview.html
オプション。 通常OpenVPNサーバーはUDP上で構成され、最初のパケットを処理する際にとてもコストの高いTLS（over UDP）セッションの確立処理が必要になる。 偽装されたUDPパケットを送られるとCPUとメモリを浪費させるDoS攻撃ができてしまうので、最初のパケットには専用の共通鍵を用いたHMAC検証機構がある。 この鍵ファイルは tls-auth オプションで指定する。
ここで使う鍵はプロセス毎にしか指定できず、複数のクライアントがいるなら全てのクライアントで共通になる。この鍵を自動更新する機構はプロトコルには無い。 漏洩時に切り分けと鍵更新が面倒になるので多人数で利用するサーバーでの利用は難しいかもしれない。
OpenVPNがUDP上に独自実装したTLS variant（バックエンドはOpenSSLまたはGnuTLS）で、通常のTLS同様に、サーバー検証とクライアント検証を行う。
このTLSで使う鍵交換・暗号・署名アルゴリズムは tls-ciphers で設定する。対応するラベルはopensslのアルゴリズム指定書式に準じていて openvpn —show-tlsで分かる。ひどい命名規則だ。 サーバーは共通のサーバー証明書を（SNIは非対応）、クライアントは個別のクライアント証明書を利用する。それぞれ cert, keyで証明書と秘密鍵を指定。 証明書は ca オプションで指定したCAから認証されているか検証され、オプションで名前（CommonNameだけらしい）の検証と証明書タイプの検証もできる。
証明書の失効はCRL（失効リスト）のみ対応、crl-verifyで有効化。
基本的にクライアント識別やログに記録されるクライアント名はクライアント証明書のcommon nameで行われる。一応一部文字は除去されるようだが、 証明書発行処理を自動化する際はログインジェクションや偽装に注意。 また一つのクライアント証明書を使いまわした複数端末から同時接続も許可できるが、ログが面倒になるのでおすすめしない。
鍵交換はECDHEも指定できるが、曲線の指定方法がない。DHEはdhparamが dh オプションで指定できる。
トラフィックは制御チャネルで共有した鍵を使って暗号化と署名を行っている
デフォルトの暗号アルゴリズムは Blowfish。 設定ファイル上では cipher で設定する。 鍵長を指定するkeysizeは古いアルゴリズム用なので今は使わずcipherで指定する。 パケット署名はHMACで、デフォルトはSHA1。 auth オプションで指定する。
暗号モード設定は外向きにのみ適用されるので、クライアントとサーバーの両方で個別に設定が必要。
ややこしいことにcipherで署名つきのAES-128-CBC-HMAC-SHA1も指定できる。GCMをつかったAEAD署名はパッチはあるもののまだ取り込まれていない。 利用可能な暗号は openvpn —show-ciphersでわかる。
comp-lzoオプションでLZOパケット圧縮が利用でき、他にもビルドオプションでsnappy、LZ4に対応する。 パケット圧縮を有効にすると、攻撃者がトラフィックを生成することでCRIME攻撃が原理的には可能になる。 ただ圧縮はパケット単位なので、TLS上のCRIME同様同一セッションに攻撃トラフィックが乗る必要がある。ブラウザとVPNの出口側がセキュアであれば問題はないはず。
暗号化パケットはシーケンス番号とsliding window（デフォルトで64パケット/15秒）で管理している。つまり短時間の順序変化と重複は許容され、パケットのドロップや重複は上位レイヤの回復処理に依存している。
no-replayとno-ivオプションがありシーケンス番号とIVを省略できるが、リプレイと暗号文一致攻撃による平文回復（BEAST攻撃と同じ）が可能になるため基本的に有効にしてはいけない。
floatオプションを指定しない限り、各コネクションのリモートIPアドレス・ポートは固定され他のアドレスからのパケットはドロップされる。
L3モードでは内部ルーティング機能があり、最低限のルート管理とクライアント間トラフィックの分離が可能。
ファイアウォール的な機能はないので、OS側のフィルタ機構を使う。 特にL2モードではARPフィルタなどイーサネットレベルのフィルタリングも忘れずに設定する。
クライアント毎のトラフィックは status オプションで定期的にダンプ可能。IPアドレス割り当ては ifconfig-pool-persist で固定割り当てが可能。
shaperオプションでコネクション当りの外向き速度制限が可能で、client-connectフックを使えばクライアント毎に異なる速度制限を生成することも出来るようだ。ただし内向きの速度制限は見当たらない。
基本的にクライアント別に細かい設定や認証をしたい場合は、フックスクリプト経由で設定ファイルを動的生成する。 どのオプション項目が動的生成に対応しているか記載がないので、個別に検証が必要。
]]>HPがこれまでのサポート方針を変更し、今後のファームウェアアップデートは保証期間内あるいは長期サポートの契約者にのみにアクセスが制限されることになった。 HP社のFAQ
2014年1月以前に公開されたファームウェアは今のところ一般に公開されているようだが、いつまで配信が続くかは不透明だ。 PC world
Proliant ML110、ML115シリーズや、MicroServerなど、HP製の安価なサーバー製品は個人で利用している人も多いと思われるが、そのほとんど全ては延長サポートなど受けていないだろう。
セキュリティ上必要なアップデートは今後も提供されるということだが、今後公式ウェブサイトでのアップデータ一般公開が停止された場合、混乱に便乗してアップデータに偽装したウイルス・マルウェアをダウンロードさせようとするウェブサイトが現れるのは避けられない。 今のうちに公式ウェブサイトから安全なファイルをダウンロードして、手元にバックアップしておくことを強くおすすめする。
もし管理下にHP製のサーバーがあるなら、不用心な末端ユーザーが変なサイトからダウンロードしてきたアップデータもどきを実行することがないように、あらかじめ注意しておいたほうがいいかもしれない。
]]>VPSプロバイダのDigitalOceanがシンガポールリージョンをリリースした。
DigitalOceanは標準でSSD、snapshotに対応、時間課金なのでAnsibleのテスト環境として利用している。ストレージがSSDだとテスト時間が大部分ネットワークレイテンシなので確認してみた。
国内からのtracerouteは良い時に85msくらい。 AS133165
NTT経由のときはいいけれど、telia.netに行ってしまうと西海岸経由で悲惨なことになる。経路依存なので、必要な場所から ping speedtest-sgp1.digitalocean.com してチェックしたほうが良さそう。
7 xe-7-4.a16.tokyjp01.jp.ra.gin.ntt.net (61.213.145.93) 12.994 ms 13.205 ms 13.757 ms 8 ae-6.r24.tokyjp05.jp.bb.gin.ntt.net (61.213.169.177) 14.429 ms 13.953 ms 13.817 ms 9 as-0.r20.sngpsi02.sg.bb.gin.ntt.net (129.250.4.91) 76.973 ms 87.418 ms 87.652 ms 10 ae-1.r00.sngpsi02.sg.bb.gin.ntt.net (129.250.4.143) 76.893 ms 87.259 ms 76.356 ms 11 116.51.27.150 (116.51.27.150) 101.476 ms 101.557 ms 97.790 ms 12 103.253.144.242 (103.253.144.242) 85.614 ms 94.697 ms 94.266 ms 13 *** (***) 100.764 ms 89.258 ms 88.088 ms
5 ae-12.r24.tokyjp05.jp.bb.gin.ntt.net (129.250.5.92) 1.547 ms 1.414 ms 1.474 ms 6 as-0.r20.sngpsi02.sg.bb.gin.ntt.net (129.250.4.91) 79.530 ms 75.088 ms 75.270 ms 7 ae-1.r00.sngpsi02.sg.bb.gin.ntt.net (129.250.4.143) 75.647 ms 75.388 ms 75.380 ms 8 116.51.27.150 (116.51.27.150) 229.987 ms 229.558 ms 230.153 ms 9 103.253.144.242 (103.253.144.242) 201.196 ms 201.171 ms 201.127 ms 13 *** (***) 249.515 ms 238.729 ms 238.970 ms
逆向きを見るとteliaの西海岸経由している
3 103.253.144.250 (103.253.144.250) 10.348 ms 10.335 ms 10.336 ms 4 10ge-v107-mad-prov-ixn.airenetworks.es (62.115.40.169) 6.781 ms 6.716 ms 6.683 ms 5 hnk-b2-link.telia.net (213.155.136.118) 39.762 ms hnk-b2-link.telia.net (80.91.245.149) 39.921 ms 38.904 ms 6 las-bb1-link.telia.net (213.155.132.215) 205.099 ms 200.264 ms las-bb1-link.telia.net (213.155.136.44) 211.212 ms
今のところシンガポール国外宛が詰まっているようで、シンガポール内のサーバー相手だと十分出ている。
またサービスイン直後なせいか直近の各種リポジトリからのパッケージダウンロードが重くなっている模様。
Hosted by World's Fastest Indian (Tokyo) [5320.20 km]: 21.617 ms Testing download speed........................................ Download: 19.77 Mbit/s Testing upload speed.................................................. Upload: 9.12 Mbit/s
Hosted by Viewqwest Pte Ltd (Singapore) [7.42 km]: 26.385 ms Testing download speed........................................ Download: 151.81 Mbit/s Testing upload speed.................................................. Upload: 27.08 Mbit/s
メモリ512MBのドロップレット
processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 2 model name : QEMU Virtual CPU version 1.5.0 stepping : 3 cpu MHz : 1999.999 cache size : 4096 KB fpu : yes fpu_exception : yes cpuid level : 4 wp : yes flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm up rep_good unfair_spinlock pni vmx cx16 popcnt hypervisor lahf_lm bogomips : 3999.99 clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management:]]>
Twitterのお気に入り（ふぁぼったツイートのリスト）からリンクを抽出して、はてなブックマークで共有するOAuthアプリを作ってみた。
conohaが開催しているこのこんというのに応募しようと思って約3日で作ったもの。基本機能はテストしているものの、実アカウントが少ないので絶賛人柱募集中。
とにかくPythonでアプリ、プロセス管理、サーバー管理まで揃えている。 応募用にSlideShareでまとめ（？）たもの↓
時間がかかったのはだいたいOAuthとMongoEngineのせい。 MongoEngineのシリアライズが変なのでモンキーパッチして性能を稼いでいたりと、内部的には余り美しくないけれど、そこそこのアカウントをopenvzなVPSでも裁けるようにgevent、celery、redis で頑張ってみた。
共有先サンプルは http://b.hatena.ne.jp/causeless/bookmark （リツイートしたリンクの共有とツイートのコメント化有効）
今のところuWSGIはvirtualenvで作ったアプリ別のモジュールをロードすることは出来るものの、システムのlibpython.soを直接使っているため、そのままではビルド時のPythonしか動かない。
異なるバージョンのpythonを含むvirutalenvに入ろうとすると、PYTHONPATHが違うためimport siteの時点でモジュールのロードに失敗する。
Python version: 2.6.6 (r266:84292, Nov 22 2013, 12:16:22) [GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] ... Set PythonHome to /path/to/py27env 'import site' failed; use -v for traceback
他のバージョンのpythonを使うには、対応するpythonとpythonプラグイン対応のuWSGIをビルドし直す必要がある。
デフォルトのままpipなどでインストールすると、python他プラグイン全部入りのuwsgiバイナリが出来ているはず。 （pipで入れていれば/tmp/pip-build-root/uwsgiに必要なファイルが展開されているので、これを元にビルド）
uwsgiソースのbuildconfディレクトリには、uwsgi本体ビルド用の設定ファイルが含まれている。 pythonを含まないバイナリを作るには、buildconf/nolang.iniを使ってビルドするか、main_plugin=からpythonとgeventを抜いておく必要がある。（geventもpythonに依存しているためビルド出来ない）
python uwsgiconfig.py --build nolang
次にプラグインをビルドするのだが、uwsgiconfig.pyはリンクするlibpython.soをビルド時のPython環境から探しているらしく、ほしいバージョンのsharedなpythonとlibpythonがセットで必要。 さらに面倒なことにpythonビルドツールのpythonzはデフォルトではsharedなビルドを作ってくれない。（OSXは別？）
一応configureオプションを渡すことでビルドは可能で、
pythonz install 2.7.6 --verbose --configure='--enable-shared LDFLAGS="-Wl,-rpath -Wl,\\$$ORIGIN/../lib"'
あるいは手動でインストール
./configure --prefix=/usr/local/python27 --enable-shared LDFLAGS="-Wl,-rpath /usr/local/python27/lib" make sudo make altinstall
必要なバージョンのsharedなpythonバイナリでプラグインをビルド。pluginsディレクトリにプラグインのテンプレートが入っている。
python2.7 uwsgiconfig.py --plugin plugins/python nolang python27 python2.7 uwsgiconfig.py --plugin plugins/gevent nolang gevent27
これでuwsgiバイナリと*_plugin.soが出来るのでバイナリを置き換え。
sudo cp uwsgi /usr/bin/uwsgi sudo mkdir -p /usr/lib/uwsgi sudo cp *.so /usr/lib/uwsgi
アプリの設定ファイルから
[uwsgi] plugins-dir=/usr/lib/uwsgi plugin=python27_plugin.so virtualenv=/path/to/py27env chdir=/path/to/py27app
とロードさせればpython2.7を利用できる。
同様にphp-embeddedの入った環境で
python uwsgiconfig.py --plugin plugins/php nolang php
でphpプラグインもビルドできた。
ものすごく面倒なのでuwsgi側でvirtualenvから自動ロードするか、libpython.soをplugins-dirに持ってくるようにパッチを当てたい……
]]>DTIのserversman VPSをx86_64化してIPv6がいくらか動くようになったのでOpenVPNサーバーにしてみた。
まずOpenVZ上ではカーネルもジュールを導入できないので、sitトンネルを使えない。 トンネルパケットをユーザースペースで処理するtb_tunがあるのでサービスとして起動する。 http://code.google.com/p/tb-tun/
setsid tb_userspace tb {{tunnel_server}} any sit > /var/log/tunnel.log 2>&1 &
tbにIPv6アドレスを割り当て。
ifconfig tb up
ifconfig tb inet6 add {{tunnel_client_ipv6}}
venetをデフォルトにするためmetricを増やして追加しておく。
ip -f inet6 route add default metric 10 dev tb
他のOpenVZマネージャ（SolusVM）ではIPv6割り当てが無いのにデフォルトルートが設定されている。その場合削除しておく。
ip -f inet6 route del default metric 1 dev venet0
iptablesで-p 41のINPUT/OUTPUTを通しておく事を忘れずに。
iptables -A INPUT -p 41 -s {{tunnel_server}} -j ACCEPT
ここまででトンネルIPv6は到達可能になった。
IPv6ルーティングを有効化
net.ipv6.conf.all.forwarding = 1
He.netを経由させるRoutedなソース範囲に対してルール付きのテーブルを作成、デフォルトルートに指定
ip -f inet6 rule add src {{tunnel_routed}} table 10
ip -f inet6 route add default metric 1 dev tb table 10
ip6tablesのFORWARDを許可
ip6tables -A FORWARD -i tun0 -s {{tunnel_routed}} -j ACCEPT
ip6tables -A FORWARD -i tb -d {{tunnel_routed}} -j ACCEPT
ServersMan@VPSはopenvzカーネルが古すぎてip6tablesのconntrackが機能していない。 常用するならもっとまともなフィルタルールが必要。
routedなIPv6を割り当てる。クライアントにはデフォルトルートとしてpushする。
server-ipv6 {{tunnel_routed}}
push "route-ipv6 ::/0"
残念ながら、openvpn 2.3.6ではまだIPv6 DNSサーバーアドレスをpushすることができない。 そのためAAAA filteringされていないHe.net提供のIPv4 DNSサーバーを指定するか、クライアント側で上書きしてもらう必要がある。
ひとまずこれでnativeのIPv6を生かしたままIPv6 over OpenVPNが出来た。
]]>Ansibleのtemplateモジュールではjinja2が使われているため、カスタムフィルタを登録して好きな処理を書ける。
templateはplaybookのパース時にも使われるので、Ansibleロード時点でグローバルなプラグインとして導入する必要がある。今のところロードするフィルタの切り替えはansible.cfgで切り替えるしか無いようだ。 (ドキュメントには ./libraryに置くことでロードできるらしいのだがcfgで上書きされているっぽい)
フィルタの登録はFilterModule().filters()が返す辞書。
import socket class FilterModule(object): def filters(self): return {"A": socket.gethostbyname}
このファイルを適当な名前でfilter_pluginsフォルダに置くとansibleロード中に読み込まれる。
実際のパス指定はansible.cfgの
filter_plugins = /usr/share/ansible_plugins/filter_plugins
]]>http://forbiddenrobots.usb0.net/
Googleのrobots.txtとmetaタグ仕様 https://developers.google.com/webmasters/control-crawl-index/docs/robots_txt に準じているつもり。
Flask＋uwsgi-emperor＋MongoEngineを試すのがメインだったので、 コアはFlask、サーバーはnginx＋uwsgiでuwsgi-emperorでプロセス管理、バックエンドにMemcachedキャッシュとMongoEngine。 httpにpython-requests、htmlパーサはBeautifulSoup4という普通な構成。
ひとまず動くところまで出来たけれど、gevent化やmongodbの分散とか実装してみたい。 いまだにgeventをwindows環境で動かすことができていないのでしばらく掛かりそうだけど。
]]>昨日は鍵共有を甘く見て爆死したためCentOS＋NginxのサーバーをWindows環境に対応させてみる。
RPMに慣れていた都合上、主なサーバーにCentOS6を使っている。 CentOS/RHEL6.4では2013年10月時点で、標準のOpenSSLは1.0.0、Nginxは1.0系が導入される。Nginxには公式リポジトリもあるが、openssl-1.0.0を前提にビルドされている。
これらはコミュニティサポートのあるRPMで提供されているものの、NginxでHTTPSサーバーを建てようとすると、TLSはv1.0 まで、対応cipherはDHE-RSA-AES-SHAまでになり、QualsysのSSLテストでは色々と指摘される。
既存のパッケージで対策不能なのは、TLS1.2対応（兼BEAST対策）とRSA鍵共有。
BEASTは未対策のブラウザがTLSv1.0以前のCBCモードで通信する場合に発生しうる。一時的な対策としてストリーム暗号のRC4が使われているが、TLSv1.2ではCBCモードの問題が解消されているためTLSv1.2で導入された暗号モードを使えば問題は無い。しかし、TLSv1.2はopenssl-1.0.0には入っていない。
将来解読される可能性がある（RSA）鍵共有を使わない、というForward Secrecyは各所で既に行われている。RSA鍵共有に替わるものとして、多くのブラウザはDH鍵共有・ECDH鍵共有が実装されている。 CentOSのopensslでも有効なDH鍵共有を利用できればいいのだが、クライアント側、例えばWindows＋IE環境ではDHE-RSAが無いためにRSA鍵共有が優先され、Forward Secrecyを保証できないことをご指摘頂いた。（Win7＋IEでブラウザのCipherテストみるとDHE-DSSは実装されているのにDHE-RSAが無い）
Windows＋IEに対応するためには、ECDH鍵共有を有効にする必要がある。Googleなど多くのサービスは既にECDHE-RSAを有効にしている。
TLSv1.2と、多くのブラウザでRSA鍵共有以外を使おうとすると、OpenSSLとNginxをリビルドする必要があった。
システムのopensslをいじるのでVMなどのビルド用サンドボックス環境で要検証。
まず、1.0.1のopenssl-develをビルド環境にインストールする。 CentOS6でのopenssl-1.0.1e のビルド手順は http://www.ptudor.net/linux/openssl/ がとても詳しいのでそのまま。 生成されたRPMをインストールしてopenssl version が1.0.1eになり、openssl cipher -v 'HIGH' でKx=ECDHが含まれるかチェックしておく。
Nginxはmainline 1.5.6のSRPMをリビルド。自動インストールするのであれば、nginx.specファイルでRequires: openssl >= 1.0.1e のバージョンを指定しておく。 出来たバイナリはopenssl-1.0.1eのcipherに対応しているはず。 例えば
ssl_protocol TLSv1.2; ssl_ecdh_curve secp384r1; ssl_ciphers EECDH+aRSA+AESGCM;
が通るか確認。
次のように明示しておく。
ssl on; ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; # RC4無し ssl_ciphers EECDH+HIGH:EDH+HIGH:HIGH:+3DES:!RC4:!MD5:!aNULL:!eNULL:!LOW:!EXP:!PSK:!SRP:!DSS:!KRB5; # RC4有り # ssl_ciphers EECDH+AESGCM:EECDH+SHA384:EECDH+SHA256:EECDH+RC4:EECDH+HIGH:EDH+AESGCM:EDH+SHA384:EDH+SHA256:EDH+RC4:EDH+HIGH:AESGCM:SHA384:SHA256:RC4:HIGH:+3DES:!MD5:!aNULL:!eNULL:!LOW:!EXP:!PSK:!SRP:!DSS:!KRB5; ssl_ecdh_curve prime256v1; ssl_dhparam /path/to/dhparam2048.pem; ssl_certificate /path/to/server.crt ssl_certificate_key /path/to/private.key
これでほぼ全てのブラウザで対応できたはず。
Forward Secrecy Yes (with most browsers) ROBUST (more info)
他人のビルドしたopensslを試す無謀な方は
http://yumrepo.usb0.net/GPG-KEY
pub 4096R/848C083D 2013-11-17
指紋 = D11E 88FF 3FC0 4339 EE1D BBA4 4F1E A7EE 848C 083D
uid causeless (myrepo sign key) <causeless@gmail.com>
[myrepo] gpgcheck = 1 enabled = 0 name = My Repo - $basearch baseurl = http://yumrepo.usb0.net/RPMS/$basearch/ [myrepo-noarch] gpgcheck = 1 enabled = 0 name = My Repo - noarch baseurl = http://yumrepo.usb0.net/RPMS/noarch/ [myrepo-source] gpgcheck = 1 enabled = 0 name = My Repo - noarch baseurl = http://yumrepo.usb0.net/RPMS/source/]]>
いかにしてパスワード認証を脆弱にするか。プログラミング黎明期からずっとデベロッパーの頭を悩ませ続ける問題です。
ここでは脆弱なパスワード認証を実現するための方法を紹介します。
不届きなブラウザがパスワードを記憶してしまうことがあります。 パスワードは間違いの無いように、ひともじひともじ、人間が入力するべきです。
<input name="pw" type="password" autocomplete="off" />
とするのは常識ですね。ブラウザのパスワード管理機能より、脳内の文字列の方がずっと安心です。
などで、ブラウザのパスワード保存をスキップする方法もあります。
貼り付けも自動入力と同罪です。onpaste属性を利用して
<input name="pw" type="password" autocomplete="off"
onpaste="javascript:function(){return false;}" />
もしくはjavascriptで、onpasteイベントの匿名リスナを登録する方法がメジャーのようです。 他にも、やや面倒だったり環境依存しますが、
など、ペーストを防ぐ方法もいくつかあります。 古典的には右クリックを禁止する方法も使われましたが、近頃のブラウザは無視してしまうことが多いので不十分です。
javascriptが無効なフィーチャーフォンに対応しなければならないこともあります。
<input name="pw" type="password" autocomplete="off"
maxlength="8" onpaste="javascript:function(){return false;}" />
のようにmaxlengthは多くのブラウザでサポートされています。
このポリシーを仕様の段階で明確化するため、データベースの生パスワードを保存しているカラムは CHAR(8) と定義しましょう。長すぎるパスワードはRDB側で無視することが出来ます。
デバッグチームから、環境やブラウザによっては期待通りに動作しないパスワードがある、なんてレポートが送られてくるかもしれません。 おかしなパスワードが入力されることが無いように、入力の段階でさにたいずしましょう。
$("input").bind("change", function(e) { if ($(this).val().match(/[^a-zA-Z0-9.-]|SELECT|DROP/)) { alert("不正な文字列"); $(this).val(""); } });
ちょっと長いのでjQueryに頼っていますが、ログイン失敗は致命的なので仕方がありません。 問題が起きそうなパスワードではアラートを出してユーザに適切なパスワードを入力してもらいましょう。
同じパスワードの使い回しを防ぐために、過去のパスワードは全て保存しておき、変更の際にチェックしましょう。
どんなに古いパスワードでも遡ってチェックできるように、生パスワードをアカウントやメールアドレスと紐つけてデータベースに保存しておきます。万一消えてしまうと本人さえ覚えておらず取り返しがつかないので、DBオペレーターはバックアップをローカルPCにとっておくべきですね。
パスワードは定期的に変更しましょう！ 安全[誰の？]のため、数ヶ月に一度は強制的に変更させるべき[要出典]でしょう。 このポリシーはいまや業界標準となっています。
これは同時に、ユーザーに脆弱なパスワード認証の重要性を思い出してもらう良い機会です。 何度も何度もパスワードを考えさせれば、より覚えやすいパスワードを編み出してくれることでしょう。
パスワードを思い出すのが億劫なユーザーのために、秘密の質問を用意しておきましょう。
質問内容はユーザーに決めさせるより、あらかじめよく検討した質問を選択式にしておくと、忘れにくく間違いが少なくなります。 たとえば親の旧姓や、叔父の名前、卒業した小学校など、指紋同様生涯変化することがないものにするべきです。もしくは、ペットの名前、好きな歌手、乗り換える駅のように、誰でも何度となく耳にする名前を使うことも検討してみましょう。
先ほど生パスワードを保存しておいたので、パスワードを変更することなくメールで送る事ができます。データベース設計を厳格にしておくと、こんな効果もあります。
パスワードを忘れてしまったユーザーが最後に頼るのは電話のようなアナクロな方法です。人件費が高コスト要因ですが、チャットのできるJavaアプレットやActiveXプラグインを使い、海外にアウトソーシングすれば比較的安上がりです。
ユーザーのアカウント名とメールアドレスがデータベースに入っているか、オペレータが確認してパスワードを口頭やチャットでユーザーに伝えることができます。オペレータにデータベースへのアクセス権限を与え、チェック項目を最小限に抑えておくことで、対応にかかる時間が短くなりコスト削減に繋がります。
一般ユーザー向けのウェブサイトでは難しくなりつつありますが、IE6とWindows XPといったブラウジング環境を限定するのは、銀行業務など確実性の求められるウェブアプリを実現する方法としていまだ一般的です。第三者によってよく研究されたブラウザと安定したOSに、高度に最適化されたソフトウェアが日々の業務を支えています。
高度に最適化されたアプリケーションは、最新のブラウザのエミュレーション機能（互換モード）によって不正に利用する事が難しくなり、アプリケーションはしばしば難解でプログラマが重要な情報を解読するまでにかかる時間が引き伸ばします。アルゴリズム秘匿によるセキュリティは長い実績に裏付けられています。
変種として、簡易ブラウザ内蔵のスマートフォンアプリを使わせる、という方法もあります。いずれにせよ、ブラウザの解釈やUIを開発者側で制限する事が重要です。
パスワードなどの情報の流出がおきたという情報の流出を避けるのはとても重要です。 ひとたび情報流出が露見すると、様々な手法で低コストでシンプルかつ脆弱になったパスワード認証が、不安を煽る自称セキュリティ専門家のせいで、複雑で不便で高コストな認証システムへのリプレースを迫られる事になります。
内部で問題が発覚したら、必要な対策が終了するまでは価値ある顧客にのみ電話など安全な方法で連絡し、一般向けの情報は対策完了後にスキャン画像から生成したPDFとして短時間掲示するのが懸命です。再配布を禁じるために意匠と著作権表示を付け、サーバーのrobots.txtを設定してInternet Archiveやウェブ魚拓に取得されることは避けなければなりません。
脆弱でないパスワードを実装してしまう恐れがある、こんな安地パターンが知られています。
多くの人がよく使われるパスワード辞書に載っているパスワードを使いたがります。これを警告することはユーザーをいたずらに不安にさせます。人は自分は他人と違うと思い込みたがる生き物です。
もっとも、パスワードが辞書やどこからか流出したリストに載っているため、という事実を、定期的なパスワード変更のため、と表現することはマナーの一つなので覚えておきましょう。
生のパスワードを破棄してソルト付きのハッシュを保存していると、オペレータですら忘れたパスワードは復元することが出来ません。アカウントへのアクセスを回復するには、全く新しいパスワードを設定することになります。
同一のソルトを使い回さない限りパスワードを変更しても総当りがヒットする確率は変わらない、という説を信じられない人は多く、しばしば理解が得られません。 ルーレットの同じ目に賭け続ける戦略と、毎回違う目に賭ける戦略では、儲けに大きな差があると感じるのはとても自然なことです。
互換性も心配です。cryptのように、ある程度規格化された方法がありますが、短いパスワードカラムではラウンド数すら入りきりません。
特殊文字を含む8文字より10文字の大小英数字の方が総当り耐性が高いなんて、1000回パスワードを変えるよりも2文字ランダムな英数字を追加する方が強いなんて、にわかには信じられません。
特殊文字のエスケープやUnicodeの正規化処理を実装する必要性すらないと言うのでしょうか？
せいぜい葉書一枚ですむマトリクス認証と違って、ワンタイムパスワードトークンを購入・送付するコストは洒落になりません。
RFC6238 のようなオープンな実装は、アルゴリズムが公開されているのが心配ですし、サーバーでntpdを動かすなんて面倒です。
違う国から連続してアクセスがあったり、突然スパム行為を始めたり、他のサイトから漏洩した脆弱なパスワードが使われている、そんな脆弱さが明白なアカウントが見つかることはよくあります。
セッションを無効化したり、アカウントを一時的に凍結したり、パスワードの変更を推奨する通知メールを送ることは、潜在的なリスクを白日の下に晒してしまいます。
新しいブラウザほど、旧来の仕様が変更されている可能性が高くなります。
右クリック禁止禁止しかり、最近のブラウザではウェブアプリがユーザーインターフェースを制御することが難しくなり、またどのブラウザでも似たような外観・挙動になってしまい、蓄えたノウハウによる差別化が難しくなっています。もっとも、フューチャーフォンやメーカーサポートが打ち切られたスマートフォンなど、まだまだ見せ所は残っているので安心です。
万一データベースに侵入され、それが露見すれば、アカウントのパスワードをリセットすることになります。 これによって、どれだけのユーザーがアカウントにアクセスできなくなるのか未知数です。特にアクティブなユーザーが少ない場合、致命傷になりえます。
簡単にチェックできる手法をまとめたので、既に実践されていて役に立たないという方が多いかもしれません。
もしアカウント認証をスクラッチで実装する機会があったら、ぜひここに挙げたアンチパターンに気をつけて実装してみてください。よりよい認証を実装できるかもしれません。
パスワード認証をより効率よく脆弱にする方法がありましたら、ぜひお知らせください。
]]>先日、久しく寝かせていたレンタルサーバーを使おうと思い、メールアカウントを設定したのだが、SSL通信に失敗した。原因はよくある、中間証明書の設定ミス。POPS/SMTPSサーバーにインストールされた証明書セットが間違っていた。
HTTPSの設定確認はQualys Labのチェックツールが日本語化されていてわかりやすい。ただ、任意のポートを楽にチェックしてくれるサービスが見つからなかったので、opensslを使った方法をメモしておく。
コマンドは
$ openssl s_client -connect app.usb0.net:443 -showcerts < /dev/null CONNECTED(00000003) depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA verify return:1 depth=1 O = AlphaSSL, CN = AlphaSSL CA - G2 verify return:1 depth=0 OU = Domain Control Validated, CN = *.usb0.net verify return:1 --- Certificate chain 0 s:/OU=Domain Control Validated/CN=*.usb0.net i:/O=AlphaSSL/CN=AlphaSSL CA - G2 1 s:/O=AlphaSSL/CN=AlphaSSL CA - G2 i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA --- Server certificate -----BEGIN CERTIFICATE----- MIIEmzCCA4OgAwIBAgISESF/E/8j4rVO8kDXSzgoA5hEMA0GCSqGSIb3DQEBBQUA 略
最初の depth=X はサーバーの証明書を0とした、opensslのバリデータが辿った証明書の深さ。 2013年現在、普通のウェブサービスが使う安価な証明書なら、中間CAがルートCAとの間に1段挟まれるので、depth=2が OU = Root CA になっている。
次のCertificate chainとServer certificateはサーバーから送られて来た証明書。 通常、サーバー自身の証明書 (ここでは、 CN=*.usb0.net) と、中間証明書 (O=AlphaSSL/CN=AlphaSSL CA - G2) が、送信されている。
サーバーに正しく中間CA証明書とサーバー証明書がインストールされていて、対応するルートCA証明書がシステムにインストールされていれば、
Verify return code: 0 (ok)
となる。
ただし、アップデートの速いブラウザやディストリビューションは中間CA証明書も信頼済みリストに含めている場合があるので、中間証明書が正しく提供されていなくても、Verifyに成功してしまうことがある。 ルート証明書（issuerのOU = Root CA）以外の証明書全て、サーバーにインストールされクライアントに提供されることを確認する。
サーバーID証明書よりも中間CA証明書の方が期限が長い場合が多いので普通は気にする必要が無いが、証明書更新の際に一緒に中間CAも更新することを忘れずに。
しばしばルートCA証明書を含む不適切な設定のサーバーがあるが、ルートCAの証明書ををサーバーから送る必要はない。証明書を送る帯域がコネクションあたり1KBくらい無駄になる。
特に、間違ったルートCA証明書（テスト用認証局など）を送信している場合は、HTTPSをよく理解していないユーザーを危険に晒す事になるので、直ちに削除する必要がある。
Djangoフレームワークのドキュメントを信用しない、大抵の開発者には無関係な話。
PythonのウェブフレームワークDjangoは他のフレームワーク同様、cookieによるセッション機能が実装されている。 セッションのハイジャック手法の一つにSession Fixation攻撃があり、対策としては、セッションIDに紐ついた権限の変更（または昇格）時にセッションIDを再生成するのが一般的と思う。
DjangoのSession周りのドキュメントにも、Session Fixation対策が示唆されているのだが、あたかもフレームワーク側で対策済みかのように書かれている。
In order to prevent session fixation attacks, sessions keys that don’t exist are regenerated:
しかし、有効なセッションIDは攻撃者が普通にウェブアプリにアクセスすれば手に入るので、存在しないIDを無視するだけではFixation対策にならない。これではサブドメインやディレクトベースでアカウント管理される共用サ―バーのようにFixationが起こせる条件下では、攻撃者は誘導されてログインしたユーザーの権限を乗っ取ることができてしまう。
実際にDjango 1.5.2で試すと、セッションミドルウェア実装はセッションオブジェクト（dict）を明示的に変更しても、IDが変化しないようだ。安全よりも性能側に振ってあるのだろう。
自前でIDの再生成を実装しているユーザーには全く影響しないが、ドキュメントをチュートリアルとしてそのまま実装すると、Session Fixationに脆弱かつ可搬性の高いコードが出来上がることになる。 ちなみに、Django組み込みのadminアプリはログイン時にIDを再生成しているので問題はない。ただ、セッションIDを明示的に再生成するAPIが見当たらない……
個人的にはセッションの再生成はフレームワーク側でサポートするべきだと思う（セッションストアの更新時にIDも変更するだけ）し、少なくともドキュメントは正しく防御方法を示すべきだ。再生成による性能劣化が問題なら再生成の必要がないことを明示するAPIを用意すればいい。
PHPのStrict Session関連でもそうだが、存在しないIDを無視するという“Fixation対策”は英語圏でも蔓延しているのだろうか？
]]>Twistedの勉強がてら、並列にN回(以上)クエリをして、結果がTTLを除き一致することを確認するスプーフィング対策を考えてみた。 （商用DNSアプライアンスとかでは既に実装されてたりするんだろうか？）
現在の主なDNSのspoofing手法は、リゾルバの使うUDPソースポート番号やクエリ先ネームサーバーを様々な方法で予測あるいは強制して、クエリIDがヒットするまで偽のパケットを送り続ける。 ポート番号のようなDNSの外側に付加された追加エントロピーを攻略されると、DNSパケットのクエリIDは16ビットしか無い。しかもしばしば攻撃者はブラウザやメーラー経由で能動的に好きなタイミングでクエリを発生させることができる。そのため、DNSSECなどで保護されていないDNSレスポンスは比較的短時間で攻撃成功率が現実的になる。 そのため、0x20のような追加エントロピーや、攻撃を検出してTCPで問い合わせる、といった方法があるようだ。
クエリIDの長さが足りないのなら、複数回クエリして、その全てが同じ内容であることを確認すればいい。N個のレスポンスを比較すれば、その全てのパケットが擬装されている可能性は2^(-16*N)になる。 つまり、N個の相同なレスポンスを得るまでリゾルバ側がクエリをリトライする。（あるいはTCPにフォールバックする）
以下の場合、クエリIDを長くすることでスプーフィングを防ぐ事ができる。
ほとんどの場合ではN回のリクエストで済んでしまうが、AnycastやGeoDNSやラウンドロビンなど、レスポンスRRsetがそもそも変化する状況では、リクエスト数がより大きくなる。たとえばN=2として所要パケット数は、レスポンスの組み合わせの平方根程度になる。
TCPへのフォールバックを使わない対処法としては、レスポンス全体ではなく、リソースレコード単位で比較して、共通部分のみをレスポンスとして再構成する方法も考えられる。 ネームサーバーがm>>1種類のリソースからk個のレコードをランダム抽出してラウンドロビンしていると仮定すると、m!/k!大雑把にm^k通りのレスポンスが得られ、2回一致するには(m^k)^(1/2)程度のリクエストが必要になる。一方、個々のRR毎に二回一致すればいいのであれば、 (m/k)^(1/2)程度で一つは共通するRRが見つかる。 リゾルバが得られるRRsetが変化してしまうのでRFCに反するが、少なくともA/AAAA/NSレコードではリゾルバはそのうちの一つを任意に選んで使って良いので実用上の問題にはならない。（RRSetの完全性が必要なタイプは個別に実装するか、DNSSECを使う） このRR単位で比較するdegradedな場合、だいたい4回クエリすれば、 k*4^2サーバー程度のRRラウンドロビンから共通のレコードを探すことが出来る。たとえばdig google.com A は11レコードを返すので、背後でバランスされているIPアドレスが160程度なら4～5クエリで解決出来ると期待できる。
一番の問題になりうるのは多段階のCNAMEでバランシングされている場合で、c段CNAMEの連鎖が発生している場合、その全てに一つずつレスポンスを得るためにはm^(c/2)のオーダーのクエリが必要になってしまう。この手法を取り入れようとすると、実質毎回TCPでクエリすることになり効率が悪い。
実際には局所性を高めるために（GeoIPなど）、クエリソースIP範囲に対してある程度決まったレスポンスを返すだろうから、極端に悪くなることはなさそうだが。
この方式でもレスポンスのうちTTLは攻撃者が1/2^16で操作可能になる。 ランダムにレスポンスの一つからTTLを採用してしまうと、極端に短いTTLによるDoSと、極端に長いTTLによるDoS・リバインディングを排除できない。
短いTTLでのDoSは単にリトライすれば（RR内容の改竄はこの検査を通らないので）若干の遅延だけで解決できるので、検査したレスポンスのうち最小のTTLを採用してしまうのがよさそう。
ネームサーバー側の負荷はリトライ数倍になるが、上限リトライ数を数回でキャップするのは通常のクエリと同じなのと、Androidのようにブラウザの同一ページ並列ロードですらキャッシュせずパラレルにクエリする実装もあるのでこの方法自体がDoSとみなされることも無いだろう。BINDのRRLでリミットされていても遅延をかけたリトライなら成功する。（クライアント側が攻撃対象のDoSなら防ぎようがないが）
truncateされないクエリに対してもTCPでクエリする場合が増えるので、TCP負荷は増加する。今のところ（truncateの必要のない）TCPクエリをrefuseするネームサーバーは少ないだろうが、ルートネームサーバのように問題になるかもしれない。 最悪の場合、TCPを使わず標準準拠なUDPクエリを（と透過な最後のリトライ）採用することになる。
Twistedのスタブリゾルバ実装をモンキーパッチしてminimalなフォワーダを実装してみた。並列クエリとリトライのみで、RRsetの編集やTCPへのフォールバックは実装していない。 （フルリゾルバ出口用にUDPプロキシとして書きなおしているけれどいつになるやら……）
N=2で通常通りのブラウジングしてみたところ、8.8.8.8にフォーワードした場合で大雑把に5%ほどの追加クエリが発生した。
retrystats: [1100, 42, 5, 1, 2] #リトライ数0からインデックスした配列
リトライはだいたいTTLが短い上に複数のCDNを使っているplatform.twitter.com
自分で運用している単独のリゾルバ相手なら（キャッシュテーブルが一つなので当然だが）キャッシュが消える瞬間以外エラーはでていないようだ。Unboundの自動リキャッシュ機能を使えばゼロに出来るだろうか？
少なくともこの方法でリモートのリゾルバとローカルの間でspoofingを受ける心配はなくなると思われる。
]]>このssl_ciphersだとWindows＋IEでRSA鍵共有が優先されてしまう問題が有ったのでobsolute
理由が記載されていない設定例しか見当たらなかったのでメモしておく。2013/9時点の理解。
Apacheでも名前の読替えで全て同じ設定が可能。
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;ssl_ciphers AESGCM:SHA384:SHA256:@STRENGTH:RC4:HIGH:!EXP:!LOW:!MD5:!aNULL:!eNULL:!KRB5:!PSK:!SRP;ssl_prefer_server_ciphers on; ssl_stapling on; add_header Strict-Transport-Security max-age=31536000;
ssl_ciphers HIGH:!MD5:!aNULL:!eNULL:!EXP:!KRB5:!PSK:!SRP;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!RC4:!MD5:!aNULL:!eNULL:!EXP:!KRB5:!PSK:!SRP;
ciphersの記述を細分すると、
AESGCM:SHA384:SHA256:@STRENGTH
TLSv1.2以降で導入された方式をMACでリストアップして、暗号強度順に並べている。これらに対応しているクライアントはTLSv1.2で接続しているはず。デフォルト有効ではないものの、メジャーブラウザは実装済み。 なお、
TLSv1.2:!eNULL
でも同じ結果になるはずだが、1.0.1eより前ではTLSv1.2という一括指定は使えないようだ。
RC4:HIGH:!EXP:!LOW
BEAST未対策かつTLSv1.2非対応の古いブラウザ向けにRC4-128bitを優先する。米国輸出規制対応の弱いRC4は!EXPで排除される。(64bitのRC4が実装された時のために!LOWをいれておく) RC4が無効化されていればそれ以外に128bit以上の暗号を使う。
!MD5
今のところ弱衝突はでていないが、MD5が必須なのはSSLv2以下のブラウザだけなので無効にして構わない。SHA1に非対応のブラウザは流石に無いと考えていい。
!aNULL:!eNULL:!KRB5:!PSK:!SRP
署名なし、暗号化なしは無効。また古い形式と事前共有など。使われることは無いだろうが ssl_prefer_server_ciphers on なので念のため無効にしておく
これらのルールは
openssl ciphers -v 'ciphersuites'
で利用される順序が確認できる。
トラフィックが少ないのでワーカー毎キャッシュを無効にして、全て共有。
OCSP応答をサーバー側にキャッシュする。最初のセッション確立までの遅延を減らせる。nginxの場合、resolverを明示的に設定が必要
同じくトラフィックが少ないのでブラウザにSSLの利用を強制する。
]]>次の記事でMarkDownで書きなおしてみた
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;ssl_prefer_server_ciphers on;
ssl_ciphers AESGCM:SHA384:SHA256:@STRENGTH:RC4:HIGH:!EXP:!LOW:!MD5:!aNULL:!eNULL:!KRB5:!PSK:!SRP;
ssl_stapling on;
add_header Strict-Transport-Security max-age=31536000;
ssl_ciphers HIGH:!MD5:!aNULL:!eNULL:!EXP:!KRB5:!PSK:!SRP;・クライアントの構成から、SSLv3とRC4を無効にできるなら、
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!RC4:!MD5:!aNULL:!eNULL:!EXP:!KRB5:!PSK:!SRP;
で利用される順序が確認できる。openssl ciphers -v 'ciphersuites'