Google認証システムに端末を追加した

最近新しいスマートフォンを購入しました。モバイル回線としてIIJmioのファミリーシェアプランを契約しているので、SIMは3枚あります。USBドングル用に使っているSIMをとりあえず差し替えて使ってみることにしました。 自分のスマートフォン利用の一つにGoogle Authenticator(Google認証システム)があります。これは外部のWebサービス(github等)での2要素認証に利用できます。RFC 6238に準拠しているサービスであれば何でも利用できるようです。 自分のスマホ運用は基本2台(音声通話用・データ通信用)なのですが、この機会に2台でGoogle Authenticatorを使いたいため、別途端末を追加する方法を探したのですが、「あとからの追加」というのはできないようです。新規登録であれば同時に複数台登録は可能なようなので、以下の手順をとりました。 github側の2段階認証停止 personal settings ->security 念の為recovery codesを記録しておく Two-factor authenticationをOffにする 旧端末側がらgithubの認証情報を削除 github上で再度2段階認証を有効化する 画面に表示されたQRコードを新旧端末で確認、登録 同程度のタイミングで両端末にgithub上の認証コードを入力 時間切れに注意。切れそうになったら次のコードが出るまで待つ 完了 基本的に常に身に着けているデバイスではありますが、これ以外にも重要なデータ(Chromeのパスワードマネージャー情報など)が入っているものですから紛失などには気をつけましょう。 なお、新しく購入したデバイスはnextbitのrobinです。+Styleで購入しました。

Rowhammer問題私的まとめ

確認できた範囲の情報を記録しておこうと思います。 Rowhammer問題 最近のメモリで見られる 同じ行に連続してアクセスすると直接アクセスしていない領域の値が化ける現象(RowHammer問題) を利用してLinuxで権限昇格ができる模様 http://t.co/10kwCTzMyJ — Fadis (@fadis_) 2015, 3月 10 PC Watchの記事「DRAMスケーリングの課題と打開策」にて解説がなされています。以下当該記事より引用: Row Hammer問題は、DRAM技術が微細化したことで深刻になり始めたメモリセル間の干渉によって発生するエラーの問題だ。 DRAMメモリセルの同じRow(行)に対する連続したアクセスが、隣接したRowのセルのデータを不安定し、エラーを生じさせる。この問題は2012年頃から話題になり始めた。Intelはメモリ制御に関する特許(Row hammer condition monitoring, US 20140006704 A1など)の中で言及した。そして、今年(2014年)6月のコンピュータアーキテクチャ学会「ISCA (International Symposium on Computer Architecture)」でRow Hammerに関する論文が発表されたことで、コンピュータ業界で広く知られるようになった。 ハードウェアについてあまり詳しくないのですが、高密度化、高速化したメモリで、特定のセル(row)に高い頻度でアクセスすると隣接するrowのメモリ内容が化ける、という現象のようです(Rowhammerの論文PDF)。 攻撃への応用 Googleのセキュリティ対策チーム”Project Zero”が、この現象を応用して攻撃に利用する、という記事を公開しました(“Exploiting the DRAM rowhammer bug to gain kernel privileges“)。応用例として、ChromeのNaClサンドボックス上で本来実行できないはずの命令を実行させたり、カーネルの権限上昇を行う手法が解説されています。 確認手段 userlandで試験を行うツールがgithubで公開されています(“https://github.com/google/rowhammer-test“)。また、memtest86 6.0.0 Free editionにもRowhammerテスト機能が追加されているようです。 rowhammer_testを実行して、実際にエラーが起きると以下のような出力をして停止します。 自分はデスクトップ(non-ECC)x2、ノート(non-ECC)x1、サーバー(ECC)x1に対して実施してみましたが、以前から挙動が若干怪しげなデスクトップマシン1台でのみ検出されました。 Google Groupsにてある程度報告が上がってきていますが、発生するときは数十~数百程度の試行回数で発生するようです(上記自分の例では11回目で発生)。自分の他のマシンでは1万以上行っても問題が出ませんでした。 自分はVirtualBox環境下でこのテストに引っかかったのですが、GroupsではXen guest上でエラーを検出できたという報告もありました。Cygwinでも確認できるよそうです。 @knok 参考になるかはわかりませんが、原理上 Cygwin… Continue reading Rowhammer問題私的まとめ

CVE-2008-0166の爪痕

偶然にも500万個のSSH公開鍵を手に入れた俺たちはという資料が公開されました。GitHubから公開鍵を大量に集めて調査してみたという内容なのですが、なかなか衝撃的だったので英語blogで内容をかいつまんで紹介してみました。 500万個のssh公開鍵のうち、Debian/Ubuntuで作成されたブラックリスト入りの鍵が208件あったそうです。割合として考えてみればそれほど多くはないのですが、まだ爪痕が残っていることを実感します。

SSLv3の脆弱性(POODLE)対応

SSL 3.0に、プロトコル自体の脆弱性がGoogleによって発見されました。”Paddning Oracle On Downgrade Legacy Encryption”略してPOODLEと呼ばれています。 検証サイト https://www.poodletest.com/ が立ち上がっており、脆弱性の詳細に関する元ソースへのリンクもあります。 今回の脆弱性はサーバー、クライアントともに対策が必要になります。とり急ぎ自分の周りにあるSSL/TLSを使うサービスに対策を施しました。 Apache+mod_ssl SSL_Engine onとしているセクション内で、以下の設定をしました。 SSL 2.0, 3.0を無効にし、利用可能な暗号からMD5,  3DES等を外しています(参考: httpsだからというだけで安全?調べたら怖くなってきたSSLの話!?)。 Postfix 参考: Postfix TLS Support Courier-imapd Debianのcourier-imapdはOpenSSLをリンクしているのでTLS1のみ設定しています。 確認方法 OpenSSLのs_clientを利用することで、任意のバージョンのSSL/TLSを使った接続を試すことができます。 上記サンプルでは、1回目はSSLv3, AESでの接続、2回目はSSLv3, RC4での接続ができています(参考: 私が愛した openssl (SSL/TLS 編))。設定が正しくできれば、以下のような結果となりネゴシエーションに失敗します。 STARTTLSを使う場合は-starttlsオプションが利用できます。 Debianでの対応状況(2014/10/16朝頃) w3mはSSLv3を無効化するパッチの当たったバージョンがsidにアップロードされています SSLv3が無効にされたOpenSSL 1.0.1jがリリースされており、sidにもアップロードされています。

caffから受け取った署名を自分の鍵へ取り込む(gpg import)

ずいぶん間が開いてしまいましたが、GnuPG key signの作業をする(signing-party/caff)の続きです。前回は自分が相手に対して署名を行い、その結果を送るための手続きについて説明しました。今回はその逆、自分が受け取った相手からの署名を自分の鍵に追加する方法について説明します。 メールをファイルに保存 相手がcaffを使っている場合、pgp鍵のおそらくは各IDごとに1通のメールが届きます。 私の鍵の場合だと、IDとしているメールアドレスは4つあるので、一人当たり4通メールが送られてきます。それらを1つづつファイルとして保存します。 メールの内容は、それぞれのIDに対応する、自身の公開鍵で暗号化されたpgp asciiメッセージです。 メールの復号化 このメールをpgpコマンドで復号化します。 上記コマンド例では、入力されたファイルをmsgというファイル名で復号化しています。復号化した内容は、caffの標準テンプレートであれば以下のようになります。 署名の取り込み この復号化されたファイルには、添付ファイルとして鍵への署名があります。本文中にも説明がありますが、gpg –importコマンドを実行することで署名を自分の鍵に取り込むことができます。 これを、届いたメールの数だけ実施します。さすがに毎回passphreaseを入力するのはしんどいので、gpg-agent等を使うと楽になります。gpg-agentはバージョン2系からついてきます。1.4系にはありません。エージェントの使い方はssh-agentとよく似ているので、そちらに慣れている人であれば楽に使えるでしょう。 私は以下のようなワンライナーで一括処理をするようにしています。 公開キーサーバー上の鍵の更新 最後に、公開キーサーバーへ新しい(電子署名の増えた)鍵を送信して更新します。これは普段から公開キーサーバーに鍵を登録している人だけがすればよい作業なので、運用によっては不要な作業です。 以上で作業は終わりです。

GnuPG key signの作業をする(signing-party/caff)

先日JNUGの総会へ行ってきて、OpenPGPの鍵の本人確認をしてきました。その後にやるべき作業を、忘備録として記しておきます。 key signの作業を楽にするためのツールはいろいろありますが、今回はsigning-partyパッケージに含まれるcaffを使います。 Package: signing-party Version: 1.1.4-1 Maintainer: Thijs Kinkhorst <thijs@debian.org> Description-ja: 各種 OpenPGP 関連ツール signing-party はあらゆる種類の PGP/GnuPG 関連ツール集で、キーサイン、 キーリングの分析、キーサインパーティの準備用ツールを含んでいます。 . * caff: “CA – Fire and Forget” 鍵にサインしてメールを送信します * pgp-clean: 自己署名以外の全署名を鍵から削除します * pgp-fixkey: 鍵から破損したパケットを除去します * gpg-mailkeys: サイン済みの鍵をその所有者へ単純にメール送信します * gpg-key2ps: 指紋を短冊にした PostScript ファイルを生成します * gpgdir: 再帰的にディレクトリを暗号化するツールです * gpglist: あなたの UID にサインした人を表示します * gpgsigs: GnuPG 鍵の一覧に対してサイン済みの鍵に注釈を付けます… Continue reading GnuPG key signの作業をする(signing-party/caff)

NAT(masquerade)のログをとる

最近の社会情勢を鑑みて、知らないうちにマシンや回線が乗っ取られて悪事に使われた時の対策として、NATのログをとるようにしてみました。 自分はDebianマシンをルーターにしているので、iptablesでルールを一つ追加するだけで済みます。 FORWARDチェインにstateがNEWなもののみ記録をします。わかりやすいようにprefixを付けています。 しかしこれで十分かというとそうでもないですね。利用しているマシンの裏で悪さされたら通常利用と区別がつかないわけで…ルーター自体が乗っ取られてもアウトです。もうちょっといい方法がないか考えたいところです。  

Android 2.x向けにL2TP/IPSecサーバ(openswan+xl2tpd)を設定する

前々から設定しかけてはうまくいかなかった、Android向けL2TP/IPSecがようやく動くようになったので、どんな設定をしたかをまとめてみます。対象はDebian squeezeです。 パッケージとして必要になるのは、openswanとxl2tpdです。これらをapt-get installします。 まずopenswanの設定をします。これはIPSecの実装の一つです。もともとFreeS/Wanというプロジェクトがあったのですが、その開発が止まったためforkしてできたのがOpenswanです。ほかにStrongswanという実装もあるようですが、ここでは触れません。 /etc/ipsec.confというファイルが存在しているので、それを編集します。冗長なコメントは消しています。 次に、L2TP向けの設定ファイル/etc/ipsec.d/l2tp-psk.confを新規に作成します。 次に、/etc/ipsec.secretsを編集します。ハイライトされた行を追加します。your-passwordを自分が設定したいパスワードにしてください。このパスワードがIPSec事前共有鍵になります。 次に、sysctl関連の設定をします。/etc/sysctl.d/for-ipsec.confファイルを作成し、以下のように設定します。自分はすべてのインターフェースに{accept,send}_redirectsを設定しています。各自のインターフェース名に合わせて設定してください。 ファイルを作成したら、sysctl -p /etc/sysctl.d/for-ipsec.confを実行してこのsysctl設定を有効化します。リブート時には/etc/init.d/procpsの中でこのファイルが自動的に読まれます。 ここで、一度ipsecを起動してみます。/etc/init.d/ipsec startして、ipsec verifyを実行してみてください。問題なければ以下のような出力が出ます。[NG]という出力があれば、何か設定に失敗していることになります。 ipsecはデフォルトでは自動起動になっていないので、insserv ipsecを実行して自動起動するようにしてください。 最後は、xl2tpdの設定です。/etc/xl2tp.confを以下のように設定します。 2行目で、ppp認証用のユーザー、パスワードを記述したファイル名を指定します。10,11行目でVPNに振るアドレスを指定します。各自にあったIPアドレスレンジを使ってください。16行目では、xl2tpdが起動するpppdの設定ファイル名を指定しています。うまく動かないときは、各種デバッグオプションを有効にしてみてください。 /etc/xl2tpd/l2tp-secretsは以下のように書きます。user, passwdは適切なものにしてください。 /etc/ppp/options.l2tpd.lnsの設定例は以下になります。 最初、MTU/MRUのサイズを指定しないで動かしていたら外部との通信がうまくいかなかったので、かなり小さめ(1280)にしています。16行目のネームサーバは適切なものに変更してください。 あとは/etc/init.d/xl2tpd restartを実行して、Android側の設定をしてゆきます。VPNのタイプはL2TP/IPSec PSK、VPNサーバ名とIPSec事前共有鍵(ipsec.secretsの値)を設定します。L2TPセキュリティ保護は無効にします。 あとは接続を実行し、l2tp-secretsに書いたユーザー名、パスワードを入力すれば接続できるはずです。設定がおかしいと、一瞬pppセッションが確立したあとすぐ切られる、というような状況が起きることがあるので気を付けてください。 知人から、これらに関していくつか助言をいただいています。 [blackbirdpie id=”237744346173153281″] ICSとOpenswanの組み合わせでは動かないことがあるようです。 [blackbirdpie id=”237735014954070016″] 新しいkernelにはopenl2tpというin-kernel l2tpモジュールがあるそうです。ただし、まだuserlandはDebianパッケージが(sidにも)ありません。 参考: AndroidスマートフォンからLinuxサーバにVPN接続する – いろいろwiki@princo.org 追記(2012/8/24): MS-CHAP-v2の脆弱性と攻撃ツールの流通が報告されていますが、pppの設定を見ての通り、L2TP/IPSecでもMS-CHAP-v2を使っています。暗号化されたトンネルの下でpppを確立するため、直ちに危険というわけではありませんが、PSK共有鍵方式だと安全とはいえないようです。 セキュリティ アドバイザリ 2743314 カプセル化されていない MS-CHAP v2 認証により、情報漏えいが起こる を公開 【注意喚起】MS-CHAPv2プロトコルの破綻 証明書ベースの接続(CRT VPN)の設定を今後は調べてみようと思います。

denyhostsからfail2banへ

sshdに対する攻撃を防ぐ手段として、denyhostsがあります。これは同じIPから連続してアクセスを試み、一定回数失敗するとtcpwrapperの/etc/hosts.denyに対象IPを記述してアクセスできないようにしてくれます。 ただ、今回いくつか環境を変更したので、もっといろいろなアプリケーションに対応させるため、同じようなソフトであるfail2banを利用することにしました。denyhostsはtcpwrapperしか対応できないのに対して、fail2banはそれ以外にも複数(iptables, ipfw等)を利用することができます。新たなルールを追加する事も容易でおすすめです。 今回は、http://blog.somsip.com/2012/02/using-fail2ban-to-protect-wordpress/ を参考にしてWordpressや(使ってないけど)phpMyAdminの対応も入れてみました。 これでしばらく様子を見てみます。