レンタルサーバとセキュリティ設定 2017

こんにちわ、TenForward こと加藤です。

この記事はファーストサーバ Advent Calendar 24 日目の記事です。

Qiita で書いた記事で Advent Calendar に参加しないと、[いいね数をカウント](https://qiita.com/ishikun/items/afdb347eda39bf85ef46)してもらえないので、2 度目の記事を書きます（ウソ）。

# Zenlogic の SSL/TLS で使う CipherSuite 設定の更新

昨年はレンタルサーバにおける暗号関連の設定をどのように決めているかということを書きました。

* [レンタルサーバとSSL/TLS](https://qiita.com/tenforward/items/12fdfd87dea998bb7434) (ファーストサーバ Advent Calendar 2016 | 7 日目)

その後も弊社のサービスである [Zenlogic](https://zenlogic.jp/) では暗号関連の設定の見直しをしており、今年はこのような案内をしております。

* [【重要】CipherSuite の見直しに関するご案内](https://zenlogic.jp/news/support/2017100501/) (Zenlogic サポートサイト/ サポートからのお知らせ / 2017-10-05)

このメンテナンスは Web サーバの CipherSuite の設定変更ですが、メールと FTP についても対応予定です。

Web/メール/FTP の暗号化については SSL/TLS を使います。ですので、アクセスしてくるクライアントを考慮しながら、基本的には同じような CipherSuite の設定にすれば良いという考えで設定を決めています。この辺りの CipherSuite を決める課程のお話は[昨年の記事](https://qiita.com/tenforward/items/12fdfd87dea998bb7434)で紹介しました。

## "3DES" 無効化しても大丈夫?

この案内で
> 「3DES」(3-key Triple DES)を用いた「CipherSuite」を無効化

とあります。これは OpenSSL の定義で言うところの `DES-CBC3-SHA`（正式には `TLS_RSA_WITH_3DES_EDE_CBC_SHA`）を無効化しているのですが、無効化してしまって大丈夫でしょうか?

### au

[昨年の記事](https://qiita.com/tenforward/items/12fdfd87dea998bb7434)で、「ガラケー」でサポートしている CipherSuite として au の「[EZweb コンテンツ制作ガイド](http://www.au.kddi.com/ezfactory/web/pdf/contents_guide.pdf)」を紹介しました。

これに載っている CipherSuite だけだと、`DES-CBC3-SHA` を無効化すると、EZweb 対応ブラウザからは接続できません。

しかし! [2017年6月に更新の文書がリリースされていました](https://www.au.com/ezfactory/web/)!!（ケータイのアップデート自体はだいぶ前からされているようですが、文書の更新が今年）

* [SHA-2 対応ケータイアップデートについて（Version-1.3）](https://www.au.com/ezfactory/web/pdf/sha-2_update.pdf)

以下の CipherSuite が使えるようになったと、7 ページに載っています。

* AES256-SHA（優先順位 1 番目）
* AES128-SHA（優先順位 3 番目）

使える CipherSuite がこれ以外には見当たりませんが、とりあえず `DES-CBC3-SHA` を削除しても、きちんとアップデートした EZweb の機種からは接続できそうです。

### NTT docomo

昨年は見つけられておらず、紹介していませんでしたが、NTTドコモの情報も見つけました（きちんと更新されているようです）。

* [作ろうiモードコンテンツ：主なスペック](https://www.nttdocomo.co.jp/service/developer/make/content/ssl/spec/index.html)（NTTドコモ）

対応機種の情報も載っています。au と同じく `AES256-SHA`（`TLS_RSA_WITH_AES_256_CBC_SHA`）と `AES128-SHA`（`TLS_RSA_WITH_AES_128_CBC_SHA`）に対応していますので、比較的新し目の機種であれば `DES-CBC3-SHA` を無効化しても大丈夫です。

### Softbank

ソフトバンクの技術文書は[ここ（Mobile CreationのWEB & NETWORKページ）](http://creation.mb.softbank.jp/mc/tech/tech_web/web_docandtools.html)にあっては SSL/TLS 関連の文書は 2016 年が最新なのですが、脆弱な CipherSuite しか使えず、端末がこの仕様のままであれば接続できそうにないのですが、どうなのでしょう?

共通鍵暗号のアルゴリズムとして `RC4` しか書かれていません（`3DES`すら✕）。一覧表には TLS 1.2 の CipherSuite の記載もあって、それが「✕」になっていますので、古い文書が放置されているわけでもありません。使えるのは、

* `RSA_WITH_RC4_128_MD5`
* `RSA_WITH_RC4_128_SHA`

だけになっています。アップデートでこのあたり更新されているのなら誰か教えてください（これだけしかサポートしていないなら、Zenlogic で運用しているサーバには、昨年の CipherSuite 更新以来接続できなくなっているです）。

----
ソフトバンクだけがちょっと詳細不明ですが、大体は大丈夫なようです。Windows XP や、古いゲーム機から接続しない限りは大丈夫ではないでしょうか。

# SFTP（SSH）における暗号関連設定

Zenlogic でサポートしているファイル転送は FTP（FTPS）だけではありません。そう、SFTP です。名前も機能も似ていますが、ssh を使っていますので、SSL/TLS の CipherSuite をそのままコピペするというわけにはいきません（他でもコピペはしてませんが!!）。

Zenlogic の SFTP サーバにおいても、SSL/TLS と同様に定期的に設定を見なおしていますので、今回はその辺りに関係する話をしてみたいと思います。ただし、以下で書くことは 実際の Zenlogic の設定とは全く異なります（記事を書く際の確認は自分で運用しているサーバや手元のテスト環境で行っています）。

## OpenSSH

sftp サーバを提供する場合に一番使われるサーバは OpenSSH でしょうか。

OpenSSH（sshd）には SSL/TLS の CipherSuite で行っている設定と同様な設定項目が 3 つあります。

* KexAlgorithms（鍵交換アルゴリズム）
* Ciphers（暗号方式）
* MACs（メッセージ認証コード）

手元で動かしている OpenSSH 7.6p1 の設定を見てみると、これらの項目は設定していませんでした。この場合にどのような値に設定されているのかを確認してみましょう（[sshd_config(5)](https://man.openbsd.org/sshd_config)にも書いてあるんですが、`KexAlgorithms`だけ man と違うような…）。OpenSSH 7.6p1 で試しています。

```shell-session
$ sudo /usr/sbin/sshd -T | egrep  '(kex|ciphers|macs)'
ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
macs umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
kexalgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
```

そのホスト上でどのような値がサポートされているかは `ssh -Q` で調べられます（←クライアントプログラムで調べてるのでサーバ設定する場合はサーバ上の同じバージョンのクライアントで調べないとダメです）。

```shell-session
$ ssh -Q kex（鍵交換アルゴリズム）
diffie-hellman-group1-sha1
diffie-hellman-group14-sha1
  :（略）
$ ssh -Q cipher（暗号方式）
3des-cbc
aes128-cbc
aes192-cbc
  :（略）
$ ssh -Q mac（メッセージ認証コード）
hmac-sha1
hmac-sha1-96
hmac-sha2-256
  :（略）
```

最新の OpenSSH を使っていれば、デフォルトの状態でもそこそこイケてる設定にはなっているでしょうが、クライアント側の環境が分かっていれば、このあたりの設定は強固なやつだけにしておいても良いでしょう。

例えば、以下のように設定します（一例です。特定のサービスでこのように設定しているこということではありません）。

```shell-session
# Key Exchange Algorithm
KexAlgorithms	curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
# Ciphers
Ciphers		chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
# MACs
MACs		hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com
```

この設定が有効になっているかは先ほど紹介した `sshd -T` コマンドで調べられます。さらに、実際に接続したときにちゃんと期待した設定で接続されているかどうかも確認してみましょう。

```shell-session
$ ssh -vv myhost.example.com
  :（略）
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
debug2: MACs ctos: hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com
debug2: MACs stoc: hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com
  :（略）
```

たくさん似たような出力があるのでわかりづらいのですが、上の辺りでしょうか。サーバの設定通りになっているのがわかります。

**この辺りの設定はクライアントとサーバのプログラムでどのような方式がサポートされるのか次第ですので、よく確認しながら設定しましょう。でないと接続できなくなります。**

自分で運用しているサーバで厳し目に設定したところ、知らない所からの接続が拒否されていましたので、設定次第では攻撃を防ぐ効果もあるでしょう。

```
Dec 21 17:31:14 myhost sshd[22992]: Unable to negotiate with xxx.yyy.zzz.aaa port 59877: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1 [preauth]
```

### 古い OpenSSH を使っている場合

CentOS 6 のような少し古い環境でサーバを運用したり、クライアントが古い場合は注意が必要です。CentOS 6 は OpenSSH 5.3p1 が使われていますので、デフォルト状態では以下のようになり、先に示した例とはかなり違います。

```shell-session
$ sudo /usr/sbin/sshd -T | egrep '(kex|macs|cipher)'
ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
macs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
kexalgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
```

クライアント側も同様にどのような方式をサポートしているかを確認しましょう。

## proftpd

実は proftpd にも SFTP サーバ用のモジュールがあります。proftpd を使って SFTP サーバを運用する人は少ないかもしれませんが、少しだけ紹介しておきましょう。

proftpd で sftp サーバを運用する場合は、[オンラインマニュアル（ProFTPD module mod_sftp)](http://www.proftpd.org/docs/contrib/mod_sftp.html)があります。しかし、使っているproftpdのバージョンによって設定できる値が異なってきますので、お使いのバージョンのソースアーカイヴに含まれているドキュメントを参照して設定しましょう。

proftpd の mod_sftp には、OpenSSH の設定で紹介した設定と同じ、次のような設定があります。

* SFTPKeyExchanges（鍵交換アルゴリズム）
* SFTPCiphers（暗号方式）
* SFTPDigests（メッセージ認証コード）

次のように設定してみます（これも同様に一例です）。

```
SFTPCiphers                     aes256-ctr aes192-ctr aes128-ctr
SFTPDigests                     hmac-sha2-512 hmac-sha2-256
SFTPKeyExchanges                ecdh-sha2-nistp521 ecdh-sha2-nistp384 ecdh-sha2-nistp256
```

接続してみました。

```shell-session
$ sftp -vv myhost.example.com
  :（略）
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256
debug2: host key algorithms: ssh-rsa,ssh-dss
debug2: ciphers ctos: aes256-ctr,aes192-ctr,aes128-ctr
debug2: ciphers stoc: aes256-ctr,aes192-ctr,aes128-ctr
debug2: MACs ctos: hmac-sha2-512,hmac-sha2-256
debug2: MACs stoc: hmac-sha2-512,hmac-sha2-256
  :（略）
```

設定通りになっていますね。

# 最後に

今回は、レンサバの SFTP の設定ということで、SFTP サーバの暗号関連の設定を変えてみました。イコール SSH サーバの設定ですね（OpenSSH のお話は）。

SSH サーバを運用している方は多いでしょうから、一度設定を見なおしてみてはいかがでしょうか? クライアントとして比較的新しいソフトウェアが使えるのなら、より強固な方式だけを許可する設定をして、鍵交換のところで攻撃と思われる接続を結構拒否できましたよ。

# 参考
* [Security/Guidelines/OpenSSH](https://wiki.mozilla.org/Security/Guidelines/OpenSSH) (Mozilla Wiki)