ALIXのブロードバンドルータで動かしているOpenVPNについては、本家のHOWTOの中にセキュリティについての記述があります。
この中により強固なセキュリティを確保するために、暗号化アルゴリズムとしてAES-256-CBCも選択できるという記述がありました。 そこまでは必要ないとしても、よりセキュアな環境を作るために少し変更を加えていこうと思います。
テスト環境
今回は次のような環境で、図左の端末からPHS通信カード(AX420S)を使いOpenVPN経由で家のサーバに接続します。
tls-authを併用する
HOWTOには通常の認証に加えて追加の共通鍵を追加する事で,DoS攻撃への耐性を高めるなどいくつかの利点があると説明されています。 予防的なものですから、これを無神経に配ってもそれほど脅威ではないでしょうね。 低コストでそれなりの効果は期待できそうなので、導入することにします。
まずは有効にするためにサーバとクライアントで共有する鍵ファイルta.keyを生成します。
$ cd /etc/openvpn $ sudo openvpn --genkey --secret ta.key
このファイルと同じものをクライアントとなるWindows XPにも転送します。 server.confやclient.confの先頭の方に次のように設定を加えていきます。
/etc/openvpn/server.confファイル
...
tls-server
tls-auth ta.key 0
...C:\Program Files\OpenVPN\config\client.confファイル
...
tls-client
tls-auth ta.key 1
...サーバ側をリスタート(/etc/init.d/openvpn restart)してから、クライアントから接続します。 Windows XP側の"View Log"でログを確認すると無事に認識されたようです。
client.logファイルから抜粋
...
Sat Mar 06 16:00:05 2010 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sat Mar 06 16:00:05 2010 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
Sat Mar 06 16:00:05 2010 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
...udpの使用
TCPはパケットの再送などを上位レイヤで実現できるので、使う事ができる環境なら「UDPよりもTCP」という認識があるかもしれません。ただUDPはオーバヘッドが少ないですし、VPNの用途では望ましいのかもしれません。
HOWTOではproto udpを使う事でDoS攻撃に対してはUDPの方がより望ましい耐性を備えていると説明されています。
プロセス実行ユーザの変更
root以外のユーザでプロセスを実行する方法として、実行後に"nobody"などroot以外のユーザに権限を降格させる方法と、そもそもプロセスの起動自体をroot以外で行なう方法、最後にchroot環境が説明されています。
お勧め：実行後に権限を降格させる方法
よりお手軽な方法はapacheなどと同様にuser, group行でroot以外のユーザを指定する方法です。 当初から採用している方法はこれで、最低限これぐらいは必要でしょう。
Linux限定：最初からroot以外のユーザでプロセスを起動する方法
もう一方はプロセスの起動自体をroot以外のユーザにする方法です。 OpenVPNが使用するポートは特権ポートではないですから原理的には問題ないですが、 Linux環境のみで有効なこの方法は少しばかり複雑です。
セキュリティを高めるためにあまり複雑な方法を採用するのは、よくよく考慮する事が必要です。 この方法は悪くはないですし潜在的な脅威が高まるとは思えませんが、設定ファイルやTLS鍵ファイルの管理など、考慮するべき点は他にもあり、あまり報われない気がします。
プロセスがハイジャックされた場合を考えれば、より汎用的な次の方法がお勧めです。
chroot環境の利用
HOWTOで説明しているchroot環境は、プロセスが起動後に初期設定を終えてから特定のディレクトリに引きこもる方法です。 初期設定は終っているので、下記に挙げた例外を除けばserver.confファイルにchroot行を追加するだけです。
もしプロセスがハイジャックされても、そこから起動されたプログラムがアクセスできる範囲は、chrootで指定したディレクトリ以下に限定されるため、より安全になるはずです。
これもあまりにも簡単なのでuser, group行と合せてchrootも使うことにしました。
$ sudo mkdir /var/jail/openvpn
/etc/openvpn/server.confの最後に追加
...
## chroot after initialization
chroot /var/jail/openvpnHOWTOでは動的に読み込まれる、crl-verify行に指定しているファイルとclient-config-dir行に指定しているディレクトリはchrootしたディレクトリをトップディレクトリとした場所に配置するよう書いていますが、これを使用していなければディレクトリを作成する以外の準備作業は不要です。
chrootに指定するディレクトリは任意なので/etc/openvpn以下にしたい場合もあると思いますが、openvpnプロセスがcoredumpした場合を考えると十分な余裕のあるファイルシステムにディレクトリに配置する事をお勧めします。
共通鍵は256bit程度、公開鍵は2048bitを使う
より長いサイズの鍵を使いましょうという話しがHOWTOにありますが特に説明は不要と思われます。
CAのプライベート鍵ファイルの管理
親CA、中間CAのプライベート鍵ファイル(demoCA/private/cakey.pem)の管理はサーバに配置しないようにして分離しておきましょう。 HOWTOにはフロッピーディスクなどに格納してネットワークアクセスを難しくするようアドバイスされています。 日本で無難な対応はMOやUSBメモリなどにdemoCAディレクトリ一式を配置して必要なタイミングでマウントするのが最善でしょう。
少し脱線して鍵の管理について…
まぁ個人レベルでそこまでする必要はないと思いますけどね。 少なくとも鍵ファイルを使うサーバ(Consumer)とdemoCAディレクトリ(Provider)を共存させるのはやめましょう。 企業でプライベートなCAを運用するのであれば、こういったメディアの管理に加えて部屋への物理的な入室制限も考えなければいけないところです。
まぁそれでも抜け道はいろいろ発生するんですよね。 より良い対応は手順を守らせるフレームワークの策定と、その手順を現実的に対応可能な範囲で四半期毎といった間隔で改訂していくことでしょう。
二人以上が共謀しないと漏洩しない仕組みは、割と低コストで実現可能な範囲に収まります。 物理的な鍵の管理と、論理的なパスワードを別々の人間が管理するだけで実現できますからね。 一般的な日本の会社だと責任の範囲だけ決めて、そういう仕組みが機能するようにはならないのかなぁ…。
さいごに
OpenVPNはお手軽にインターネット経由でVPNを実現可能にする仕組みで、RSA鍵の有効期限を短く設定するぐらいの考慮があれば比較的安全なインフラが構築できるでしょう。 問題はパフォーマンスですが
0 件のコメント:
コメントを投稿