2015年11月17日火曜日

SSL LabsでA+評価をもらえるWebのTLS設定

職場で公開している、とあるWebサーバのCA証明書をようやく入手できたので、TLS対応しました。

いまどきはどんな設定するんだろうと思い検索すると、「SSL Labsで検査する」というのがひとつの指標のようです。

よい検査結果を得るためには、というか、これだけサイバー攻撃が激しくなっているいまを生き抜くために、2015年秋現在では最低でも使えるプロトコルはTLSv1以上にするのはもちろんのこと、暗号の組も現時点で弱いことが確定したものは排除しなければならず、さらに最近見つかったDHのlogjam脆弱性にも対応しなければいけません。

まず暗号の組は

Guide to Deploying Deffie-Hellman for TLS

で。とても長くなってますが、そういう時代なんでしょう。

このなかで、dhparam.pemファイル作成については

logjam対策でやったことまとめ

が日本語なのでわかりやすいと思います(といっても、opensslで1行コマンドですが)。

ここまでやって「B評価」。レポートを読むと、セッション関係の設定を改めなければならないようです。Nginxの場合ですが、ssl_session_cacheをきちんと設定するのがよいようです。ここまででひとまず「A評価」。レポートを見ると、「HSTS Preload」という項目が無効らしいことが気になります。

つまり、80番につないできたら443に飛ばす設定をして、HSTS Preloadというらしいですが、httpスキームを入れてもブラウザが80番でなく、443番に勝手につなぎにいく相手を並べたJSONファイルがネット上にあって、それに関連する設定を加えるのと、ブラウザが随時読みに行くそのJSONファイルに登録してもらう作業が必要なようです。

もろもろありますが、「とりあえずNginxならこう書いておけ」という例が

Nginx Configuration for HSTS Preload

というページにありました。ただ、resolverに8.8.8.8と4.4.4.4を設定しているのはやめるべきだと思う。

ひとまずここまでやると、「A+評価」になりました。うれしいです。

SSL LabsさんでA+評価いただきました

とはいえ、ブラウザがHSTS Preloadしないよという行は残りますので、HSTS Preloadファイルへの追加登録依頼をしなければいけないわけですが、それは

HSTS Preloadを導入しよう

というブログエントリにしたがって、Webフォームから入力することになるようです。このとき、www.ではじまるサイトが必要なようですが、当方まだできていないので、これは後日対応しようと思います。

2015年11月15日日曜日

NTTフレッツ光のCTU設定変更(結局フレッツ光ネクストに契約切り替えたので意味なしエントリになりました:2015-12-15)

(追記:2015-12-15)フレッツ光プレミアムは新規契約打ち切り、フレッツ光ネクストというCTUいらない子な契約に切り替えていくようで、自宅もそうしたらとても快適になりました。

それから、以下の記述は10年ほど前に契約した当時の、住友電工のCTUにのみ該当するようで、クレーム後いったん予防交換といって工事屋さんが置いていった日立のCTUでは、デフォルトのパケットフィルタ設定は入っていないようでした。

CTUにつないでいたBuffaloのWi-Fiルータはフレッツ光のPPPoEリンク設定がデフォルトで入っていたようで、ほとんど何も考えずにISPのログイン設定するだけで終わったので、フレッツな人はみんなネクストに契約切り替えたほうがいいと思います。うちは集合住宅で光ケーブルが部屋まできていないので上限100Mbpsのままですけど、いままでがひどすぎたので劇的な改善であります。

工事料金無料、契約は「隼」(最大1Gbps)ではないので料金同じ、2年縛り割引もそのまま引き継ぐということで、特にこちらから申込書を書くこともなく、ただ契約変更通知が郵送されてきただけでした。工事屋さんは管理人室内の終端ボックスの配線付け替えとCTUの引取り、データリンクの確認と伝票の印刷だけしてお帰りになられました。簡単。

ひかり電話とかフレッツ・テレビ(スカパーHDとかがフレッツIPv6網で観られる)を契約するとそういう機能つきのNTTご提供ルータに交換するみたいですが、うちはシンプルにやっております。


自宅はNTT西のフレッツ光を使っていますが、どうも最近つながらない、よく切れるという症状で悩んでおりました。

困るのは、SSH接続がブツブツ切れることでして、これではサーバのメンテナンスもできません。コンパイル途中で切れるとか、インデックス作成中に切れるとかすると、shellが子プロセスもろとも落ちるので、ちっとも作業が進みません。

NTT西に電話して、機器や配線の電気的な点検を依頼するとか、週末なので問い合わせフォームしかなかったけれど某ISPのカスタマサポートに通信制限状況の問い合わせを投げてみるとかしてみましたが、そうしている間、瞬間的にIPアドレス重複のメッセージが現れたのをみつけて、どうもDHCPサーバになっているCTU(NTT用語で要するにPPPoEルータ)が怪しいと思い、設定を見なおしてみました。

まず、自分のMacのIPアドレスが使われるのはたまらないので、MACアドレス指定でスタティックなIPアドレス設定に変更。

そのあと、ログをみるわけですが、「不正アクセスログ」という画面ぐらいしかまともに時系列のログがないので開いてみたところ、「つながらない」と思っていた相手への接続をCTUが切断していました。現員は「SPIによる破棄」。へえ、そんな立派なものがと思いつつ、「なんで捨てるんだよ」という怒りにも似たやるせなさが。

検索すると、CTUのWAN側IPv4アドレスが「123から125の間で始まる場合」、つまり上から8bitが123-125のブロックの場合、一部のIPアドレスに対するパケット送信をSPIが破棄するという問題がある、という古い記事(しばらく前にファームウェアの更新があったけれど、それより古いという意味)がいくつか見つかり、「ファイアーウォールをオフにしてください」と書かれているサイトが複数ありました。

CTUの設定画面上、たしかにオフが誰でもわかる選択項目だけれど、それは乱暴ではないかと思いつつ。
CTUログイン直後の画面左にファイアウォール設定項目がある

とはいえ、「制限なし」は乱暴ではないかと思う。SPIは「詳細設定」のなか

ということで、SYN Flooding対策にはSPIほしい気もするけどどうなんだと思いながらも、現実にいまつながらない相手があり、家人のスマホらしきIPアドレスでも破棄されているので、これは手元のMacだけの問題ではないと思い、SPIを停止して様子をみることにしました。

ただ、SPIを止めるためには、「ファイアウォール詳細設定」という別立ての項目を設定して、とパケットフィルタリングのルールを自分で書く画面と同じところに入らなければならないわけです。
「詳細設定」画面の上にSPIの項目があるけれど、「編集」を押さなければならない仕様

ここでようやく選択できる。OKで前の画面に戻る
こうなると、普通のルータ同様に細かくルールを書かないとフィルタリングなしになるような気がするのですが、結論からいうとそうでもないようです。でも、ルールの書き方の規則がわかったので、以下続けます。

ルールは先頭(若い番号)から順に評価されます。なので、「全部閉じて開くものを指定する」か「全部開いておき、閉じるものを指定する」か、どちらかを最初に決めなければなりません。

それで、後者を選んだ場合、デフォルトは「全部閉じている」になります。よって、先頭に、全てを「許可」するルールを置かなければなりません。ルール番号は1がいいでしょうか。「IPバージョン」に「IPv4・IPv6」を選び、「プロトコル」を「すべてのプロトコル」に変更するのを忘れないでください。初期値は「IPv6」「TCP」です。

そのあと、Windowsのファイル共有関係の137-139と445を書いておけば十分なようです。念のため、以下の図では53/TCPと53/UDP(DNS)を拒否するルールを書いていますが、「不正アクセスログ」をみると、特にルールを書かなくても「NATによる破棄」を理由として、たいていの試みは失敗するような動作をするようです。少なくともWell Knownなポートに関してはSYNの時点で捨ててくれますし、そうでない怪しい443(HTTPS)からの接続とかは、宛先ポートによらずESTABLISHEDのところで捨ててくれます。したがって、ルールがなくてもそれなりにうまく制限してくれるのかもしれない。

しかし、443や53から接続する攻撃があるのに驚きました。ルールの書き間違いを期待しているんでしょうか。あるいは、送信元が80や443だと通してしまう誤ったフィルタが設定された商品があるんでしょうか。
特定のポートを制限するなら、先頭に「全部通過する」ルールを置く必要があるので注意
いずれにせよセッション有効時間が短いので、調べ物に時間をかけていると、せっかく入力したルールを保存できないまま、最初からやりなおしになるので、最小限の設定からはじめるのがいいと思います。

この画面には「戻る」ボタンしかありませんが、変更内容はメモリに保持されています。これを保存するには、「戻る」で現れたトップ画面の画面左にある「設定反映」ボタンを押さなければなりません。すると、いったん確認画面を経由したあと、再起動が必要な選択をしたから再起動してくださいというメッセージとともに、「再起動」ボタンが配置された画面に遷移します。再起動は1分ぐらいだと思います。ときどき適当なサイトにpingでも打ちながら待っていると、そのうち反応があります。いつまでたってもunreachableな場合は、おそらく1番ルールの「最初にすべての通信を許可する」ときに「すべてのプロトコル」を選ぶのを忘れていて、ICMPが通らなくなっています。

あとはお好みで調整してください。再起動の時点で「不正アクセスログ」を開くと、早くも多数の怪しいパケットを捨てたことがみてとれます。

ひとまずこれで様子見です。

2015年11月5日木曜日

Mac OS XのKeychainに対応するOpenSSHパッチがGiHubにありました

以前、Mac OS Xのキーチェーンアクセスに対応したOpenSSHのパッチについてのエントリを書きました。

El Capitanになり、入っていたMacPortsの全リコンパイルをなんとか終えてしばらくしてから、port -uv upgrade outdatedしたら、MacPortsのOpenSSHが7.1p1になりました。

Homebrewのほうはどうだろうと思ったら、メンテナンスされているパッチのリポジトリをGitHubで見つけました。

https://github.com/zoltansx/openssh-keychain

Homebrewの場合は、dups/opensshのkegをeditしろとのことで、追加すべきコードを含め、手順がReadme.mdに書かれております。

気になる方は、上記URLを参照してみてはいかがでしょうか。

当方で試してみたところ、無事7.0p1がコンパイルでき、キーチェーンアクセスに保存されたpassphraseを用いてssh接続できました。ありがたや。

2015年11月1日日曜日

Yosemite以後のMac OSでJavaインストールのダイアログを消すにはJDKを入れる

そのまんまですが、El CapitanでJava6を入れないで、やむなくOracle JREを入れたけれど、いつまでもインストールしろとうるさいので調べたら、こんなFAQがOracleにありました。

After I updated to Mac OS X 10.10 (Yosemite), why am I told to install Java after I already installed the latest Java?

回答は、「full JDKを入れろ」でありました。Java SEですね。見つかりにくいですが、たぶんこのへんからたどるとよいのでは。

たしかに、JREだけだと空のディレクトリがあちこちにあって、なんか変だなと思っておりました。環境変数JAVA_HOMEを設定すればjavaコマンドは動きますが、ダイアログはシステムが出しているわけで、ユーザ側の環境変数は関係ないはずで。

それで、Java SE入れて再起動すると、あたりまえですが特に環境変数JAVA_HOMEを設定しなくてもOracle Java 8が動きました。まあ、しのごの考えないで、さっさと再起動するのがいいような気がします。

一方、検索してみると、El Capitanのrootlessを解除してApple Java 6を入れる手順が説明されていますが、気持ちはわかりますがやめたほうがいいんではないかと思う次第。

AppleのJava 6サポートはEl Capitanが最後なんだそうです。Java 6依存のコードは、Oracle Javaの新しいコード(Java 8とか)で警告なくコンパイルできるよう、リファクタリングしなければいけませんね。いろいろめんどくさいですが。