Pythonのplotly dashで左右に縦軸があるグラフをつくるサンプルコードのメモです。
yaxis2プロパティを設定する必要があります。
左右軸とは関係ありませんが、そのほかに、以下のようなことをしてます。
- グラフの凡例を上部に表示するために、
legendのorientationとyanchorをいじっています - グラフの右上にマウスをホバーさせた際に表示されるツールボックス(?)を消すために、
displayModeBarをFalseにしてます
PythonのPlotly DashでJP DNSサーバーのRTT等を可視化するウェブアプリを作った
概要
フロントエンド周りの勉強を目的に、Plotly Dash*1を用いて 権威DNSサーバーのRTT等の可用性を可視化するウェブアプリケーションを作ってみました。
実装
実装はシンプルで、下記のような感じ。
- dnspython*2を使ってDNSのクライアントを書きました
- SOAレコードを定期的に問い合わせて結果をinfluxdbに書き込みます
- influxdbの結果をPlotly Dashで表示します。
- NSIDを引いているので、どのエニーキャストノードが応答してるか分かります。
- プローブ(問い合わせを定期的に実施しているノード)が地理的にどの辺にあるか地図にプロットしてます。（東京のプローブは、さくらインターネットのVPSです。AS番号も表示してます。）
その他
DNSをモニタリングするツールは、そもそもいろいろあったります。
*1:Introduction to Dash https://dash.plot.ly/introduction
*2:A DNS toolkit for Python http://www.dnspython.org/
Auditdのaureportをcronで使おうとしてハマる
aureportコマンドをcrontabで実行した際、何度やっても<no events of interest were found>と出力されてしまっていました。
結論としては、--input-logsオプションをつけることで想定通り動作するようになりました。
--input-logs Use the log file location from auditd.conf as input for analysis. This is needed if you are using aureport from a cron job.
SCT（Signed Certificate Timestamp）のLogIDについて
SCTに存在するLogIDがどのように作成されているのか書きたいと思います。
ここで言っているLogIDとは、下記のものです。
例としてgoogle.co.jpにChromeでアクセスして表示させています。
まずLogIDがなんなのかCertificate TransparencyのRFC 6962を確認してみます。
3.2. Structure of the Signed Certificate Timestampによれば
LogIDは、key_idをフィールドにもつ構造体の様です。そして、key_idはCTログサーバーの公開鍵を
DER形式でSHA256ハッシュをとったものと書いてあるように見えます。
CTログサーバーの公開鍵があれば、LogIDを作れそうです。 CTログサーバー（Chromeのポリシーに対応する）の公開鍵は次から取得することができます。
www.certificate-transparency.org
始めの図の一つ目のLogIDである、Google 'Pilot' logを作ってみます。Google 'Pilot' logの公開鍵は下記のようです。
{
"description": "Google 'Pilot' log",
"key": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEfahLEimAoz2t01p3uMziiLOl/fHTDM0YDOhBRuiBARsV4UvxG2LdNgoIGLrtCzWE0J5APC2em4JlvR8EEEFMoA==",
"url": "ct.googleapis.com/pilot/",
"maximum_merge_delay": 86400,
"operated_by": [
0
],
"dns_api_endpoint": "pilot.ct.googleapis.com"
}
KEYにある値をEC鍵（Elliptic Curve）としてopensslでSHA256ハッシュをとってみます。
$ cat << EOF | openssl ec -outform der -pubin | openssl dgst -SHA256 -binary | hexdump -C -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEfahLEimAoz2t01p3uMziiLOl/fHTDM0YDOhBRuiBARsV4UvxG2LdNgoIGLrtCzWE0J5APC2em4JlvR8EEEFMoA== -----END PUBLIC KEY----- EOF read EC key writing EC key 00000000 a4 b9 09 90 b4 18 58 14 87 bb 13 a2 cc 67 70 0a |......X......gp.| 00000010 3c 35 98 04 f9 1b df b8 e3 77 cd 0e c8 0d dc 10 |<5.......w......| 00000020
すると、はじめの図に記載した通りのLogIDを得ることができました。
ちなみに、CTでの署名アルゴリズムはRFC 6962に下記のように記載されているように
NIST P-256に記載される楕円曲線暗号を使うか、RSAの最低2048bitの鍵で署名する必要があるようです。
2.1.4. Signatures
Various data structures are signed. A log MUST use either elliptic curve signatures using the NIST P-256 curve (Section D.1.2.3 of the Digital Signature Standard [DSS]) or RSA signatures (RSASSA-PKCS1- V1_5 with SHA-256, Section 8.2 of [RFC3447]) using a key of at least 2048 bits.
TLS ExtensionによるSCTの提供について
CT1において、SCT2をクライアントに提供する方法は3つあります。
1. X.509 v3 Extensionによる方法
これは、いろいろなウェブサイトのサーバー証明書で見ることができます。証明書自体にSCTが埋め込まれているものです。
例えばtwitter.comの現時点の証明書であれば以下の様な感じで書かれていました。
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1(0)
Log ID : A4:B9:09:90:B4:18:58:14:87:BB:13:A2:CC:67:70:0A:
3C:35:98:04:F9:1B:DF:B8:E3:77:CD:0E:C8:0D:DC:10
Timestamp : Jul 17 19:51:00.991 2018 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:21:00:8B:F9:25:DD:54:D4:8F:0C:F6:61:1E:
9C:10:3D:12:BA:C5:07:1C:E5:74:9D:AE:B1:E5:A1:0A:
95:EB:10:E4:19:02:20:23:7B:A2:00:02:68:8A:80:00:
20:97:B6:11:BD:16:0B:B6:E2:EF:EC:EC:1E:F7:0B:E3:
E3:9F:B3:8B:51:C8:30
Signed Certificate Timestamp:
Version : v1(0)
Log ID : 87:75:BF:E7:59:7C:F8:8C:43:99:5F:BD:F3:6E:FF:56:
8D:47:56:36:FF:4A:B5:60:C1:B4:EA:FF:5E:A0:83:0F
Timestamp : Jul 17 19:51:01.145 2018 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:20:6E:08:9D:A7:60:20:E5:B9:85:22:FD:4E:
BE:9C:24:DB:6F:28:D6:BB:FC:52:75:9C:98:B1:32:91:
9E:8B:36:26:02:21:00:FF:6E:5A:E9:72:34:F0:03:4B:
15:BF:96:1C:C0:ED:9B:2F:33:18:0B:E8:D9:BC:86:C5:
0A:4C:89:67:2D:BF:8A
2.TLS Extensionによる方法
TLSネゴシエーションのServer Helloの際に、SCTを提供する方法です。
google.co.jpにHTTPSでアクセスしたときのTLSネゴシエーションをWiresharkで見てみると以下のような形で
SCTが書かれていました。
TLS Extensionによる方法でSCTを提供する場合、証明書に埋め込む必要がないので、
1の方法と比べて、Precertificateがいらないメリットがあるのかなと思います。
認証局から証明書(SCTが含まれない)を発行してもらい、CTログサーバーには 自分で登録し、受領したSCTを自身のウェブサーバーに設定して公開すればよいからです。
CTログサーバーに登録する方法としては、例えばSectigo(COMODO)が下記のように公開しています。
上記の手順に従うと、手動でMammoth（Sectigoが運用するCTログサーバー）に登録することができそうです。
3.OCSP Stapling
TLS通信を行う際の、OCSP StaplingにてSCTを提供する方法がある様なのですが 実例を知らない為どのように実際に見えるのかわかりません。
CT（Certificate Transparency）ログサーバーの可用性
CTログサーバーの可用性を確認できるウェブサイトを見つけました。
作者は、イギリスのNetcraft社（セキュリティ関連の会社）の人の様です。
This website monitors Certificate Transparency log servers to check that they are behaving correctly. ct.grahamedgecombe.com
OWASP ZAPでHTTPS通信の中身を確認したい
手順は以下の通り。
ちなみに、得体のしれないルート証明書をインポートすると、
得体のしれないソフトウェアや人に、中間者攻撃を許すことに繋がるので要注意。
1. OWASP ZAPでルート証明書を作成する
「ツール」→「オプション」→「ダイナミックSSL証明書」にて画面を開き「生成」ボタンをクリック。
-----BEGIN CERTIFICATE----- MIIFCDCCA/CgAwIBAgIEjYma0zANBgkqhkiG9w0BAQsFADCBhDEnMCUGA1UEAwwe ... -----END CERTIFICATE-----
