SSL Server Test

日経NETWORK 2018年9月号より

米クリオスのSSLラボが提供するSSLチェックツール
https://www.ssllabs.com/

財テク.jpというサイトをチェックしたところレーティングはBでKey Exchangeに問題があるとの判定だった。

B判定の主な原因として、下記3点があった。
This server uses SSL 3, which is obsolete and insecure. Grade capped to B.
SSL3に対応している。

This server accepts RC4 cipher, but only with older protocols. Grade capped to B.
ChiperにRC4が利用できる。

This server does not support Forward Secrecy with the reference browsers. Grade capped to B.
Foward Securityに対応していない。。。。

一方で、HSTSに対応している点は評価された。
HTTP Strict Transport Security (HSTS) with long duration deployed on this server.

SSL対応状況について

Chorome68からSSLに対応していないサイトは警告されるようになった。
「日立製作所も対応していないからといって、当社も対応する必要がありません。」
という会社があるとしたら、ホームページの重要性について理解されていないと思わざるを得ない。。。。

利用者視点で言えば、HSTSに対応していないというのもいただけないのだが、なぜSSLの対応にこれだけ腰が重いのかが理解に苦しむ。。。。

snmpwalkコマンドですべてのMIB情報が取得できない

拡張MIBが取得できない場合に試してみるとよい。

RTX1200に対して、snmpwalkコマンドを実行してみた。
全てのMIB情報を取得する場合には、OID指定で”.”を指定するとすべての情報が取得できる。

$ snmpwalk -v 2c -c (コミュニティ名) (IPアドレス) | wc
617 2541 29196
$ snmpwalk -v 2c -c (コミュニティ名) (IPアドレス) . | wc
9100 37101 530108

DNSラウンドロビンについて考える

最近DNSラウンドロビンの構成になっているWebサーバを見かけなくなったのは、ロードバランサが仮想化されて稼働率が限りなく100%に近づいているからということなのか?
とあるサービスにて、複数のロードバランサをDNSラウンドロビンする方法があったのだが、ロードバランサに障害発生した場合に、DNSラウンドロビン登録しているAレコードのキャッシュ有効時間を限りなく短くしたうえで、ロードバランサ障害時にDNSレコードを動的に変更できる運用体制がないと可用性を下げる要因にしかならないのではないか?と思ってみた。
DNSラウンドロビンにおいては、
WindowsでDNSのラウンドロビン機能を利用するの文中にあるように
クライアント側の再試行機能(アクセスできない場合は、別のサーバIPアドレスへの接続を試行する)に”期待”したりする(アプリケーションによっては、アクセスできない場合は自動的に別IPアドレスへ再試行する機能を持っている)
とあり、アプリケーションの実装によっては、アクセスできない場合には別のAレコードの値を参照して再試行するというものがあるらしいが、アプリケーションが直接複数のレコードを使い分けるような実装をしているものがあるとは個人的には考えにくい。
参考)
Load Balancing
Azure Load Balancer の概要

無線中継器を設置してみた

最近、周りで高出力?の無線LANのアクセスポイントが増えたせいか、親機のWZR-HP-G301NHの電波が2階まで届きづらくなった。
WEX-733Dを検討していたが、パソコン工房でジャンク品として500円でたたき売りされていたMZK-W300NH2があったので、異なるメーカでブリッジモードで接続できるかどうか試してみた。
結論としてはうまくいかなかった。
どうもアクセスポイントとしてもかなり評判が悪いようで、異なるメーカでの中継設定をしたサイトにはたどり着けなかった。
MZK-WNHのAPブリッジ(WDS)設定

MZK-W300NH2 でAPブリッジ
などあり、あまり評判がよくない。
PLANEX MZK-W300NH2 で WDSに至っては、EDIMAXのBR6424n V2へのファームウエア更新の方法までのっていた。
うまくいかなかったので、ガラクタ覚悟でファームウエア更新もやってみたがうまくいかなかった。
すこし高い授業料だったが、ブリッジモードで接続する場合には、同一メーカで構成することが無難であることがよく分かった。。。

mydnsからroute53へ移行する

dynamic dnsサービスであるmydnsからAWSのroute53へ移行してみた。
dynamic dnsの移行なので、いろいろ考慮しないといけない点はあるものの、オンプレのDNSサーバを移行するのであれば、かなり楽に移行できそうな感覚だった。
理由は、
・mydnsサービスが昨年使用できない障害が2度発生していたこと(無料で利用させて頂いているだけに何も言えないのですが、DNSが引けなくなることでインターネットから孤立するのは辛すぎる)
・AWS移行検証に当たってまずは移行しやすい部分からやってみたかったこと
やってみて分かったこと
・route53のインターフェイスは英語。でもなんとかなる。
・1ドメイン当たりの管理コストは0.5ドル。
・IPv6をダイナミック管理しようとすると、自前で作らないと難しいかも。(後述記載のサービスの安定性に依存してしまう)
AWS route53セットアップ(2ページ目は使用しない)
Route 53でダイナミックDNSを運用する
IPアドレスを更新するスクリプト
Route53に設定したドメインをスクリプトでDDNS
なお、上記スクリプト実行のためには、下記パッケージを事前にインストールしておく必要がある。(yum installコマンド等)
curl
jq
AWS CLI
その他参考)自分のグローバルIPアドレスを返すサービス(IPv6対応サービスは見つからなかったのが残念)
curl httpbin.org/ip
curl ipinfo.ip

SSL(TLS)通信について

TLSはHTTPSプロトコルやFTPSプロトコルをはじめとした、多くの暗号化通信において、トランスポート層にて利用されている。
今回、太陽光発電のリモコンが集計サーバとうまく通信できていないことの原因を調べるため、RTX1200のポートミラーリング機能を使ってパケットをキャプチャしてみたところ、
Enrypted Alertメッセージがリモコンから集計サーバへの通信時に発生したことを契機にサーバ側から通信が切断(FINフラグが設定)されていることがわかり、原因調査のためにいろんなサイトを探してみた。
Enrypted Alertメッセージが発生した原因は、WiresharkでSSL通信の中身を覗いてみるによれば、Wiresharkにて集計サーバの秘密鍵がないことによって発生しているようで、
なぜうまく通信ができないかの理由にはたどり着けなかったが、よい勉強になったので紹介しておく。
通信できなかった理由については、ミラーリング機能にて取得したポケットを集計サーバの管理会社へ送付し、問い合わせしてみようと思う。
参考サイト
SSL/TLS(Part.1)
HTTPSコネクションの最初の数ミリ秒
SSL Troubleshooting with Wireshark and Tshark (by Sake Blok)

ポート差し込み不良でDestination Host Unreachable

RTX1200でLAN1ポートに刺していたはずの同一セグメントに対するホストにpingを飛ばしたらDestination Host Unreachableが返ってきたという話。
Destination Host Unreachableが返るホスト(IoT機器)から通信テストをしたところルータとの間での通信障害となってしまっており、パケットフィルタリングされているのかとログを調査したが分からなかった。
RTX1200を見てみるとリンクアップしていないような状態だったので、差し込みをしっかり行ったところ通信できるようになった。
変なトラブルに巻き込まれないようにポートへの差し込みはカチッと音がするまで差し込みしましょう。

Zabbixでヤマハルータの温度を取得する

Zabbix温度監視 No.05 SNMPで温度を取得するを参考に
N1200(RTX1200)の温度監視してみることにチャレンジした。
しかし、 No Such Object available on this agent at this OID と怒られて取得に失敗してしまう。
SNMP OID欄にOIDである .1.3.6.1.4.1.1182.2.1.15.0 とすべきところを .1.3.6.1.4.1.1182.2.1.15 としていたことが原因。
代わりに SNMPv2-SMI::enterprises.1182.2.1.15.0 とすることでも正しく取得できる。
OIDは正確に登録しましょう!
$ snmpwalk -v 2c -c (コミュニティ名) (IPアドレス) .1.3.6.1.4.1.1182.2.1.15
SNMPv2-SMI::enterprises.1182.2.1.15.0 = Gauge32: 44
$ snmpwalk -v 2c -c (コミュニティ名) (IPアドレス) SNMPv2-SMI::enterprises.1182.2.1.15.0
SNMPv2-SMI::enterprises.1182.2.1.15.0 = Gauge32: 44