Hatena::ブログ(Diary)

..たれろぐ.. このページをアンテナに追加 RSSフィード

2018-09-21

JWT 認証のメリットとセキュリティトレードオフの私感

2018/9/25追記: https://gist.github.com/issm/63889b931b8c658f23634070b64f8b23 も参考になるかも。 あと、以下の議論は『セッション』の意味するところに認識違いがあるのかもしれない(認証継続の意味でのセッションと、ステート保持機構としてのセッションと)。


どうして JWT をセッションに使っちゃうわけ? - co3k.org (←のはてブ
とか
JWT認証、便利やん? - ブログ (←のはてブ
で話題になってるので、Webシステム素人の理解と私感をメモしてみる。
OpenID connect とかで使われてるって話だけど、そっちはノータッチで単純にAPIアクセス時の認証の仕組みとして使うことを前提としています。


JWT ベースの認証って、負荷分散などのために複数台のフロントサーバを使う場合や、複数のマイクロサービスを使ったサービスを実現するにあたって、認証(セッション)状態を都度セッションストアに確認したくない・できない場合に生きてくる仕組みなように思う。

一般に短寿命のアクセストークンと比較的長寿命なリフレッシュトークンのセット利用を前提としていて、次のような利用形態が前提(なはず)。

  • 普段の APIリクエスト時はアクセストークンのみで認証する。
  • アクセストークンの寿命が来た場合には、リフレッシュトークン使ってアクセストークンを更新する。
  • そのリフレッシュ時には都度ユーザDBなりにアクセスしてリフレッシュ可否を判定する。
  • APIリクエスト頻度 <<< アクセストークンのリフレッシュ頻度である。


従来の SessionID を使ったトークンベース・cookieベースの認証では、SessionID からユーザID などの認証情報を引かないといけないので、その対応関係(セッション情報)を一時保存するセッションストアが必要になる。

API リクエストが高頻度に発生する場合では、複数台のフロントサーバ分散させる構成にするのが一般的だけれども、セッション情報は全体で共有しないと破綻するので、 memcached や Redis のような共有セッションストアサーバを別途用意して、フロントサーバ全体で共有しなければならなかった。


それに対して JWT だと普段の APIリクエストに対しては、各フロントサーバで JWT から認証情報を取り出せるので、共有セッションストアサーバが不要になる。(そこで改竄検知可能なのが JWT のキモだと思う)

リフレッシュの頻度は APIリクエストに対して十分に低頻度で、バックエンドの普通の DB サーバで十分に対処できる。
このため、リフレッシュが要求された時点で DB を参照してアクセストークンをリフレッシュする/拒否することで認証状態をコントロールする。


トークンの漏洩に対しては、漏洩発覚後、アクセストークンの寿命が来るまでは不正アクセスを許容できるサービスが適用対象で、即時止めたいというサービスには向かない。
そういうサービスの場合は、セッションストアサーバを使って確実にセッション無効化できるように構築しましょう。
無理に JWT で実現しようとしても、blacklist をフロントサーバ間で共有させないといけないので結局共有セッションストアのような仕組みが必要になってしまうので。


共有セッションストアサーバが不要になるというのが、JWT 認証での一番のメリットで、あとはアクセストークンの寿命の設定次第で、許容するリスクとリフレッシュ負荷とのトレードオフを調整する。


この方面は素人なんで要点外したら申し訳ないけれど、調べた範囲だとこういう感じなのかなぁと。

自前サービスのAPI認証用途で使う場合であれば、ユーザの無効化操作と同時にフロントサーバ群にそのユーザ情報を管理APIなどで上手くばらまく仕組みができれば即時無効化もできるはず。
無効化情報はせいぜいアクセストークンの寿命時間分保持すれば十分なので、再起動を考えなければオンメモリでもいけそうな。


各種フレームワークで用意されてる・対応してるセキュアな実装が使えるなら、それに乗っかるのが一番無難な選択よね。

あ、マサカリはウレタンでお願いします。

2018-03-10

ESXi のパスワードにアンダーバー ( _ ) を入れてはまったら

ESXi 触ってみたんですよ。それで、アンダーバーを含んだパスワードを指定したんですね。
そしたらなんか DCUI にはそのパスワードログインできるものの Web Clientログインできないという状態になりまして。

Login Name の部分を使って入力具合を確認すると、キーボード配列日本語配列の状態でアンダーバーを入れると謎の空白キャラクタが入力されていることが判明。
(なお、キーボード配列が US Default ならしかるべきキーを叩くとちゃんとアンダーバーが入ります)
Web Clientログインフォームでは、日本語配列状態でも正しくアンダーバーが入るので、そこの齟齬で Web Clientログインできなくなっていたようです。

一旦アンダーバーのないパスワードに変更するために、

  1. DCUI で ALT+F1 を押し、 ESXi Shell に移る(事前に ESXi Shell 有効にしておくこと)
  2. passwd コマンドでアンダーバーのないパスワードに一時変更する

と変更した後に、

  1. そのパスワードで Web Clientログインし、Web Client からパスワードを変更する

ということで、アンダーバー入りのパスワードにできました。

今度は DCUI 側で不具合が出るので、DCUI の操作は、キーボード配列を US Default にしておくと
いいでしょう(慣れていない人は記号キーの対応表を用意)

IE11 で Java applet が動かない場合

64bitの Windows 環境で最新の Java を入れていても 「表示中のページは Java を使用しています」と出て、インターネットオプションやらコントロールパネルの Java 設定を弄っても効果が無い場合、

32bit版のJREを入れると動くかもしれない。

http://did2memo.net/2017/01/21/internet-explorer-32bit-or-64bit/

はまったorz

2017-12-03

VyOS と PPPoE と MSS clamp の設定と

先に結論。
VyOS で MSS 制限設定入れる場合、そのトラフィックが出入りする全インタフェース
に set policy route しないといけない。(VyOS 1.1.7時点)

よくあるのが Flets の PPPoE の MTU 1454 byte 環境用に MSS 1414 byte と制限し
たい場合はこんなルールを作って、

policy {
    route PPPOE-IN {
        rule 10 {
            destination {
                address 0.0.0.0/0
            }
            protocol tcp
            set {
                tcp-mss 1414
            }
            tcp {
                flags SYN
            }
        }
    }
}

PPPoEインタフェースLAN インタフェースの両方に指定するのが正解です。

set interfaces ethernet eth0 pppoe 0 policy route PPPOE-IN
set interfaces ethernet eth1 policy route PPPOE-IN

いまいちスマートさに欠けるので、別のスマートな設定方法あるか将来バージョンで
set interface ethernet eth0 pppoe 0 mss-limit 1414 みたいなことができればいいなぁとか思いつつ。

以下のサイトは、自身が過去にも参考にさせてもらったりしてるのですが、どれも LAN
側のみに設定しているだけなので、上手くいかない場合があります。

海外だと同じ問題にぶつかって「双方向で指定しないと」って話があるようなんだけ
れども、国内じゃさっぱり見かけないので。

なんで?というお話


TCP において、MSS のネゴシエーションはコネクション確立時に行われ、SYNパケット
に付けられる MSS オプションを使って双方の MSS を送りあった後、より小さい MSS
をコネクションの MSS として採用するという形で実現されています。

PC1 が MSS1200、 PC2 が MSS1400 の場合、通常時は以下のように MSS 情報の交換が
行われます。

1. PC1 --(SYN    : MSS1200)-> PC2
2. PC1 <-(SYN+ACK: MSS1400)-- PC2
3. PC1 --------(ACK)--------> PC2

1. の時点で、 PC2 は PC1 の MSS を知り、自身の MSS より小さいため MSS = 1200 を
採用します。
2. の時点で、 PC1 は PC2 の MSS を知ることになりますが、自身の MSS のほうが小さい
ため、そちらを採用します。
以降このコネクションでは MSS = 1200 として無難に通信が進むことになります。

問題になるのは以下のように、途中のルータで MSS 制限を加える場合。
PC1, PC2 とも途中経路に制限があるとも知らず、 MSS1460 で通信をしようとしています。
ルータ - PC2 間が PPPoE を挟むので、ルータで MSS1414 に制限しようとします。
このとき、ルータが片方向でしか MSS を変えてくれない場合に問題が生じます。

1. PC1 --(SYN    : MSS1460)-> ルータ --(SYN    : MSS1414)-> PC2 
2. PC1 <-(SYN+ACK: MSS1460)-- ルータ <-(SYN+ACK: MSS1460)-- PC2 
3. PC1 --------(ACK)--------> ルータ --------(ACK)--------> PC2

1. ではルータが MSSを1414を変更して PC2 に伝えるので、 PC2 は MSS=1414 を採用します。
しかしながら、 2. において、ルータが戻りパケットの MSS オプションを変更しないので、
そのパケットを見て PC1 は MSS=1460 で大丈夫だと判断してしまいます。
そうすると、パケットサイズによって PC1 -> PC2 のパケットが落ちたりして不安定な状態
になってしまいます。

set interfaces policy で片方のインタフェースにしか指定しないと、まさにこの状態になって
しまいます。

実際の所、どうなってるの?ということで、 PPPoE インタフェースLAN インタフェースを通る
3way ハンドシェイクをモニタ(tcpdump)した結果を見てみましょう。
LAN内の PC から 59.106.194.36 (d.hatena.ne.jp) に接続してみたときの結果です。

まず、LAN側のみ PPPOE-IN を適用している場合。
LAN 側 IF (eth1) を通る 3way ハンドシェイク は次の通り。

$ monitor interfaces ethernet eth1 traffic filter "host 59.106.194.36"
  0.000000 192.168.0.17 -> 59.106.194.36 TCP 58563 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=2
  0.014629 59.106.194.36 -> 192.168.0.17 TCP 80 > 58563 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 WS=9
  0.015777 192.168.0.17 -> 59.106.194.36 TCP 58563 > 80 [ACK] Seq=1 Ack=1 Win=65700 Len=0

次に PPPoE インタフェースをモニタした結果。
$ monitor interfaces pppoe pppoe0 traffic filter "host 59.106.194.36"
  0.000000 218.211.81.60 -> 59.106.194.36 TCP 58548 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1414 WS=2
  0.014321 59.106.194.36 -> 218.211.81.60 TCP 80 > 58548 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 WS=9
  0.015360 218.211.81.60 -> 59.106.194.36 TCP 58548 > 80 [ACK] Seq=1 Ack=1 Win=65700 Len=0

PC -> 59.106.194.36 への MSS は PPPoE に出て行く時点で MSS=1414 に変更されているものの、
59.106.194.36 の応答 SYN パケットのそれは MSS=1460 のまま、変更されていません。


そして、LAN側、PPPoE側の双方に PPPOE-IN を適用した場合では、
$ monitor interfaces ethernet eth1 vif 5 traffic filter "host 59.106.194.36"
Capturing traffic on eth1.5 ...
  0.000000 192.168.0.17 -> 59.106.194.36 TCP 58688 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=2
  0.013817 59.106.194.36 -> 192.168.0.17 TCP 80 > 58688 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1414 WS=9
  0.014805 192.168.0.17 -> 59.106.194.36 TCP 58688 > 80 [ACK] Seq=1 Ack=1 Win=66456 Len=0
$ monitor interfaces pppoe pppoe0 traffic filter "host 59.106.194.36"
Capturing traffic on pppoe0 ...
  0.000000 218.211.81.60 -> 59.106.194.36 TCP 58678 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1414 WS=2
  0.013987 59.106.194.36 -> 218.211.81.60 TCP 80 > 58678 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 WS=9
  0.015217 218.211.81.60 -> 59.106.194.36 TCP 58678 > 80 [ACK] Seq=1 Ack=1 Win=66456 Len=0

PC -> 59.106.194.36 への SYN パケットと、 59.106.194.36 -> PC の応答SYNパケットの双方で MSS=1414
に変更できていることがわかると思います。

なんでなんでー?というお話


詳細は調べてないのでわからないのですが、 policy route で指定する tcp-mss は iptables の mangle
テーブルの PREROUTING チェインに入るようです。

インタフェースの受信パケットは → PREROUTING チェインで MSS 変更 → ルーティング
ルーティングインタフェースから出力、という流れで処理されるため、 LANインタフェースに指定し
ただけでは、 PPPoE インタフェースで受信されたパケットに対して MSS 変更処理がされず、上に書いた
ような状況に遭遇してしまうと考えられます。
(Linux の受信パケットの流れは 画像検索”iptables prerouting” 参照)

以下、LANインタフェースのみに指定したときの iptables の状態。

$ sudo /sbin/iptables -L -n -v -t mangle
Chain PREROUTING (policy ACCEPT 4263 packets, 753K bytes)
 pkts bytes target     prot opt in     out     source               destination 
 342K  142M VYATTA_FW_IN_HOOK  all  --  *      *       0.0.0.0/0            0.0.0.0/0
Chain INPUT (policy ACCEPT 1074 packets, 82127 bytes) pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 2841 packets, 628K bytes) pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 680 packets, 66835 bytes) pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 3521 packets, 695K bytes) pkts bytes target prot opt in out source destination 306K 138M VYATTA_FW_OUT_HOOK all -- * * 0.0.0.0/0 0.0.0.0/0
Chain PPPOE-IN (5 references) pkts bytes target prot opt in out source destination 8559 444K TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 /* PPPOE-IN-10 */ tcp flags:0x02/0x02 TCPMSS set 1414 175K 18M RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 /* PPPOE-IN-10000 default-action accept */
Chain VYATTA_FW_IN_HOOK (1 references) pkts bytes target prot opt in out source destination 1072 166K PPPOE-IN all -- eth1 * 0.0.0.0/0 0.0.0.0/0
Chain VYATTA_FW_OUT_HOOK (1 references) pkts bytes target prot opt in out source destination


続いて、 PPPoE 側、LAN 側の双方に指定した場合の iptables の状態。
$ sudo /sbin/iptables -L -n -v -t mangle
Chain PREROUTING (policy ACCEPT 172 packets, 23721 bytes)
 pkts bytes target     prot opt in     out     source               destination 
 343K  142M VYATTA_FW_IN_HOOK  all  --  *      *       0.0.0.0/0            0.0.0.0/0
Chain INPUT (policy ACCEPT 60 packets, 5003 bytes) pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 99 packets, 18075 bytes) pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 45 packets, 4652 bytes) pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 144 packets, 22727 bytes) pkts bytes target prot opt in out source destination 307K 138M VYATTA_FW_OUT_HOOK all -- * * 0.0.0.0/0 0.0.0.0/0
Chain PPPOE-IN (6 references) pkts bytes target prot opt in out source destination 8594 446K TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 /* PPPOE-IN-10 */ tcp flags:0x02/0x02 TCPMSS set 1414 175K 18M RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 /* PPPOE-IN-10000 default-action accept */
Chain VYATTA_FW_IN_HOOK (1 references) pkts bytes target prot opt in out source destination 48 11695 PPPOE-IN all -- pppoe0 * 0.0.0.0/0 0.0.0.0/0 1075 166K PPPOE-IN all -- eth1 * 0.0.0.0/0 0.0.0.0/0
Chain VYATTA_FW_OUT_HOOK (1 references) pkts bytes target prot opt in out source destination


経緯

新しく買ったタブレットからのWiFi通信が通らず、あかんやーんとしばらく放って
たところ、古いタブレットでも同じ現象が出ることに気づき、 LTE 経由だとちゃん
通信が通ったので、まず WiFi AP の不具合を疑い、ファーム更新したり再起動
たりでも改善せず、MTU 絡みの可能性を疑って、 MSS がちゃんと変更されてるかパ
ケットキャプチャしてみたところ、戻りパケットで MSS が変更されてないことに気
付き、元設定じゃダメじゃんとなった次第。

PPPoE インタフェースにも set policy route の設定を入れたら、新タブでも通信
できるようになったので、ようやく新タブが使えるようになったorz
PCからの通信も妙に遅かったのもこれのせいだったぽい。

これについて書かれたものが見あたらないので、国内だとあまり問題になってない
地雷を踏み抜いたんだろうか…(or VyOSユーザがレアなのか)

VyOSっぽいOSが動くルーター EdgeRouter Lite では機能として MSS clamp が載っ
てる模様。
17,000円で買えるVyOSっぽいOSが動くルーター EdgeRouter Lite(ERLite-3)を使ってみる — どこか遠くでのんびり怠惰に暮らしたい

iptables を触って PPPoE インタフェースの POSTROUTING チェインに無理矢理
TCPMSS を書けばコンフィグ上はシンプルに収まりそうだけど、裏技臭がひどく
て運用的に問題がでそうだし。

Connection: close