meta's blog - The Power To Serve

■ cvsup-mirror でミラーサーバの構築

FreeBSD 7.2-RELEASE 出ました。リリース直後は freebsd-update サーバも cvsup サーバも混み合ってアップデートできない状態でした。

研究室や自宅やその他で FreeBSD マシンが増えてきたので、ローカルに1台 cvsup のミラーを構築してみました。

# cd /usr/ports/net/cvsup-mirror
# make
===>  Vulnerability check disabled, database not found
===>  Extracting for cvsup-mirror-1.3_8
===>  Patching for cvsup-mirror-1.3_8
===>  Configuring for cvsup-mirror-1.3_8
I am going to ask you a few questions so that I can set up your
FreeBSD mirror configuration.  Every question has a [default]
answer.  To accept the default, just press ENTER.

At this point, I am just gathering information.  I will not touch
your system until you type "make install".

Master site for your updates [cvsup-master.freebsd.org]? cvsup2.jp.freebsd.org

How many hours between updates of your files [1]?

Now you must decide which sets of files you wish to make available
from your mirror site.  You can choose any combination, and you
can put each set anywhere you want to on your disks.  Although each
set is optional, we strongly encourage every mirror site to carry
at least the main source repository.

Do you wish to mirror the main source repository [y]?
Where would you like to put it [/home/ncvs]?
Do you wish to mirror the installed World Wide Web data [y]? n
Do you wish to mirror the GNATS bug tracking database [y]? n
Do you wish to mirror the mailing list archive [y]? n

Now, a few questions so that I can set up your CVSup server properly.

For security reasons, both the CVSup client and server should run
under their own unique user and group IDs.  These IDs should have no
special access privileges.  Normally, the user:group "cvsupin:cvsupin"
is used for the client and "cvsup:cvsup" is used for the server, but
you can choose other names if you wish.  At "make install" time, I
will create the users and groups, if they don't already exist.

Use unique user and group IDs for these.  Do not use "nobody",
"nonroot", or "nogroup".

Unique unprivileged user ID for running the client [cvsupin]?
Unique unprivileged group ID for running the client [cvsupin]?
Unique unprivileged user ID for running the server [cvsup]?
Unique unprivileged group ID for running the server [cvsup]?

The CVSup server does its logging via syslog.  At "make install"
time, I will set up the logging for you, if necessary.  I will use
the "!program" feature of syslog to keep your CVSup log messages
separate from the messages of your other daemons.

Syslog facility for the server log [daemon]?

You can control the load on your machine by limiting the number of
clients that the CVSup server will serve at once.  CVSup won't load
your network especially heavily, but it is more CPU and disk
intensive than most other file server software.

Maximum simultaneous client connections [8]?

Building the "config.sh" file ... Done.
Building the "cvsupd.access" file ... Done.
# make install

あとは /etc/rc.conf に

cvsupd_enable="YES"

とでも書いておきます。しばらく放っておくと cron で手元にミラーが構築されるので、

# /usr/local/etc/rc.d/cvsupd start

を実行して cvsupd を起動しておけばOKです。

cron で同期してくれるのを待つのではなく、すぐに同期を実行したい場合は

# /usr/local/etc/cvsup/update.sh

を実行します。シェルスクリプトの中を見るとわかりますが、フルパスで実行しないと動かないので注意が必要です。

これで構築したミラーサーバが cvsup.freebsd.vmeta.jp です。利用はご自由に。利用の際は supfile で compress を無効にするか、cvsup (csup) に -Z (大文字) オプションを付けて圧縮を無効にしてください。

■ xrdp v0.9.5 以前と Windows 10 の組み合わせでコード 0x80004005 のエラーが発生する問題

正確な日付は記憶していないのですが、2018年のGW中にリリースされた Windows 10 Insider Preview と xrdp v0.9.5 以前の組み合わせにおいて、「認証エラーが発生しました (コード: 0x80004005)。」というエラーが発生して Windows クライアントから xrdp に接続できないという問題が発生しています。

2018年5月という日付と、リモートデスクトップという単語の組み合わせから、以下の問題を連想する方が多いかもしれませんが、0x80004005 エラーと CVE-2018-0086 CVE-2018-0886 の修正は無関係です。

2018-05-15 16:28 追記: 下記リンク先のマイクロソフトの記事において、CVE番号が間違っています。正しくは CVE-2018-0886 です。

• 2018 年 5 月の更新プログラム適用によるリモート デスクトップ接続への影響

発生条件

サーバ側

• xrdp v0.9.5 以下
• OpenSSL 1.1.0 未満 (OpenSSL 1.0.x)

クライアント側

• Windows 10 Insider Preview Build 17661.rs_prerelease.180428-1349
• 今後 Insider Preview でない通常リリースでも発生するかもしれません

その他

• クライアント・サーバ間の通信モードがTLSであること

何が起こっているか

Microsoft Remote Desktop Protocol (以下MS-RDP) には、RC4により通信を暗号化する従来のモード(もはや安全でない)と、TLSにより通信を暗号化するTLSモードが存在しますが、TLSによる暗号化を使用する場合に本問題が発生します。

上記のバージョンの Windows 10 Insider Preview 以降、リモートデスクトップクライアント(以下mstsc)がTLSモードで使用する暗号化スイートに変更があり、Forward securecyを満たす暗号化スイートのみを使用するようになったようです。

Forward securecy については筋よく説明しているサイトが他にたくさんあるので、ここで詳しくは説明はしませんが暗号化に使用する鍵に一時的な(Ephemeral)な鍵を定期的に交換して使用し、認証用の公開鍵が漏洩しても通信内容の解読を困難にするものです。ECDHE- や DHE- が頭につく暗号化スイートがそれです。

一方でxrdpにTLSが実装された最初のまともなリリースであるv0.9.1からv0.9.5以前のバージョンには、OpenSSL 1.1.0 未満との組み合わせで使用した場合、Forward securecyを満たす暗号化スイートが使用されないというバグがありました。このバグは以下のissueで修正され、v0.9.6には含まれています。

• https://github.com/neutrinolabs/xrdp/pull/1023
• https://github.com/neutrinolabs/xrdp/pull/1024

ここまで書くと察しの良い方はお気づきになるかもしれませんが xrdp v0.9.5 以前と OpenSSL 1.1.0 未満の組み合わせにおいて、クライアント側はForward securecyを満たす暗号化スイートを要求するにも関わらず、サーバとなるxrdp側はそれを使用できないという状態に陥ります。ここで暗号化スイートのミスマッチが起こりネゴシエーションに失敗、接続できないという結果になります。

対処方法

対処方法は、先に上げた発生条件をどれか1つでも崩せばいいわけですから簡単です。Windowsのバージョンを下げることや、TLSによる暗号化を使用しないのは安全でない場合が多く、おすすめしません。OpenSSLのバージョンを1.1.0以降に上げるのも、OSにかなり根深い部分を触ることになる可能性があり、非常に面倒なのでできれば行いたくないですね。

というわけで、最も簡単なのは xrdp のバージョンを v0.9.6 以降に上げることです。この記事を書いている時点では v0.9.6 が最新です。xrdpとクライアントとの間でどんな暗号化が使用されているかを知るには、/var/log/xrdp.log を見てください。接続時に以下のようなログが記録されるはずです。

[20180507-15:02:00] [INFO ] TLS connection established from ::ffff:192.168.0.60 port 51710: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384

このログの場合は、コネクションはTLSv1.2によって保護され、暗号化スイートは ECDHE-RSA-AES256-GCM-SHA384 であることがわかります。