wakatonoの戯れメモ

はてなダイアリーから引っ越してきました。

PrintNightmareその後(といっても1日しか経過してないけど)

PrintNightmare(CVE-2021-34527)は、修正ファイルがリリースされた模様

以下の記事を書いてから半日も経たないうちに、修正ファイルがリリースされた。

wakatono.hatenablog.com

修正ファイルは以下のところに。

修正プログラム名のところにSecurity Rollupと書かれてはいるが、これ立派にOOBリリース(定例外リリース)なので、見間違えないように。

msrc.microsoft.com

Print Spoolerサービスが止まるとPDFでの保存ができなくなる理由

自分も忘れていたが、PDFは「どんな紙に印刷されるのか」を想定した設定を行える。それこそA4縦とかA4横とか。

これらの設定は、Microsoft write to PDFの場合はPDFプリンタに設定に、Microsoft Office Professional Plus 2019の場合は(多分だけど)文書ファイル中の設定に記載され、PDF保存の際にはこちらの内容が使われる。

しかし、Microsoft 365 apps for enterpriseで使えるOfficeアプリの場合は、この設定をどうもPrint Spoolerサービスが稼働している時に見えるプリンタ(多分Microsoft write to PDF)からAPI経由で読み出しており、これがPrint Spoolerサービスが止まっている時には(プリンタが見えないから用紙の設定を読み出せない→)保存できない、というからくりのようだ。

でもこれ、明らかにavailabilityを落とす要因にしかならないので*1、改善したほうがよいとは思う。

*1:印刷するのとファイルを保存するのが関係するなんて、普通はあまり思わない

PrintNightmareめんどくせえ…

Print Nightmare(CVE-2021-34527)、修正プログラムがまだ出ておらず、Workaroundだけが出てる状態だけど(2021年7月7日 1:26時点)、この2つあるWorkaroundのうちの1つが一見面倒に見えて、1つがお手軽だけどいろいろと大変なことになる、という話し。

追記:修正公開されたようです(2021年7月7日 10:00時点の情報)。が、こんだけ迅速だと地雷埋まってないか心配。

Workaround自体は、以下のページに記述されている。

msrc.microsoft.com

Workaroundは2つ。Print Spoolerサービスを停止するか、ローカルポリシーを変更するか~Print Spoolerサービス停止は大いなる罠~

Print Spoolerサービスの停止はものすごい罠で、「Print Spoolerサービスを停止する=ローカルにつながってるプリンタがリモートから見えなくなる」のは正しいんだが、ローカルのプリンタも見えなくなる。それもリアルなプリンタだけではなく、仮想プリンタ(例:Microsoft Print to PDFとかMicrosoft XPS writeとか)も見えなくなる

とはいえ、仮想プリンタが見えないだけならば、WordとかExcelとかPowerPointの「保存する」で、「PDF形式」で保存すりゃいいんじゃね?と思うわけだが、これが大いなる罠だった(一部の環境の人にとって)。

  • Print Spooler停止→WordとかでPDF保存出来ない(まじか)

Print Spoolerを停止したら、保存→PDF形式を指定してファイル保存できないと嘆いていた友人A。一方で、Print Spoolerを停止してもPDF形式を指定してファイル保存できるオレ。話を聞くと、にわかには信じがたい事実が判明してくる…。

検証開始~環境の差異はMicrosoft Officeのバージョンとアドオン有無

基本は環境の差異の確認なので、確認してみたら、わりかしあっさり出てきた(もっと面倒だと思ってた)。

  • オレが使ってるOffice:Microsoft Office Professional Plus 2019
  • 友人Aが使ってるOffice:Microsoft 365 apps for enterpriseで使えるOfficeアプリ。どうもAdobe Acrobatも入ってるっぽく、OfficeのAcrobatアドオンも含まれているっぽい。

Microsoft 365で使えるOfficeのアプリのせいか、Acrobatアドオンが悪さしているのかわからないが、友人Aの環境では、Microsoft 365 apps for enterpriseで使えるOfficeアプリケーションは(少なくともWordとExcelは)、PDFに印刷もPDFに保存もPDFにエクスポートも「全部同じコンポーネント(=印刷)を通るっぽく、そりゃ使えないわ、という結論に。

Acrobatアドオンが悪さをしているのか、Microsoft 365 apps for enterpriseで使えるOfficeで挙動が変わったのかわからないが、PDF作成時の使用コンポーネントが統一されたっぽく、それでPDF作成が出来ない、と考えられる。

ちなみにMicrosoft Office Professional Plus 2019では、以下のような感じ。

よろしい。ならばローカルポリシーを変更だ

ということで、ローカルポリシーを変更する方法を提示*1

mmc.exeを管理者権限で実行
→「ローカルコンピューターポリシー」のスナップイン追加
ローカルコンピューターポリシー
→コンピューターの構成
→管理用テンプレート
→プリンター
と進んで、右に出てきた項目から「印刷スプーラーにクライアント接続の受け入れを許可する」を選択して右クリック、編集→「無効」を選んで「適用」を押す。
→Print Spooler を再起動

文章にすると長いが、実際にやってしまえばすぐに終わる*2

以下が、「印刷スプーラーにクライアント接続の受け入れを許可する」まで選択して、右クリックでメニューまで出した画面。

f:id:wakatono:20210707014958p:plain

mmc.exe実行→スナップイン追加→該当ポリシー選択まですませた画面

で、編集を選択すると、以下のような画面が表示される。

f:id:wakatono:20210707015112p:plain

ポリシー編集画面

オレの場合は、すでに「無効」にした後なのでこうなっているが、何もしてないと「未構成」になっている。ここは潔く「無効」にすることに。

ポリシーを変更したら、忘れずPrint Spoolerを再起動だ。お兄さんとの約束だぞ!

ここまでやってもPrint Spoolerサービスを再起動しないと無駄なので、サービス再起動をしよう。Print Spoolerを停止できる人ならば再起動もできるとは思うが、念のため画面は以下に。

f:id:wakatono:20210707015638p:plain

サービス管理画面

上記はmmc.exeを実行→「サービス」スナップインを追加→サービス一覧表示→Print Spooler選択→右クリックまで済ませた画面。

ここで「再起動」を選んで左クリックでことたりる。

むすび~サービス停止は罠が多い&慣れればポリシーいじるほうがラクだが、いじったことを忘れないように

今回、Print Spoolerサービスの停止が何気に罠が多いという知見と、ポリシーいじるのが意外にラクだという知見(の確認)の両方を得た(後者はドメイン環境だと当たり前なんだけど、あまり個人環境では使わないんだよね)。

ただ、あくまでこれはWorkaroundなので、修正プログラムが公開されたら早めの適用を。そして修正プログラムを適用したら、ポリシーをもとに戻すことも考慮するように*3。でないと、このポリシー変更でまた無用なトラブルを引き起こす、ということも考えられるので…。

 

 

 

 

*1:Print Spoolerを停止するのに比べれば手間はかかるが、やれば数分で終わる

*2:オレ自身は、mmc.exeを叩いてイベントログ見たりサービス一覧みたりというのをわりかししょっちゅうやるので、すぐに終わると錯覚しているだけかもしれんw

*3:リモートから印刷などさせないという話だったらそれでOK

smacircle S1に乗ってみた

我が家に来たsmacircle S1、やっと乗ってみた。徒歩10分くらい圏内をぐるりとまわった感じ。

簡単ではあるけど所感を…。

 

現時点の結論

感覚的には、今の時点では以下のような感じ

  • まるでA-bike electricのような、相当癖のある乗り心地
  • 現時点では、とてもじゃないけど万人には勧められない
  • きちんと乗りこなすならば、結構慣れが必要

あくまで「現時点では」と前置いてますが、これらは小径車の宿命でもあるかなと思ってたりします。

www.wheelingtokyo.com

 

インプレッション

感覚的には以下のような感じ。

  • 展開/収納はやっぱきつい
  • 乗り味はかなり独特
  • 幹線道路で乗るのはかなりリスキー

それぞれについて、詳細は以下に。

 

展開/収納はやっぱきつい

これだけど、やっぱ12kgくらいある本体を保持しながら、ロックボタンを押し込んで~というのはかなり厳しいと感じた。

さらにバックミラーとかウインカー/ナンバープレートとかの着け外しが、何気に煩わしい。

どんだけ慣れても、展開/収納で1分切るのはかなり難しそう(というか、バックミラーとナンバープレートがある時点で無理目)。

 

乗り味はかなり独特

アクセル/ブレーキが普通のスクーター等とは違うので、ホントに慣れが必要。

それこそ、ひとけのないところで運転練習するくらいの気持ちでいないと、相当危ないし、実際そういう道路で慣らし運転(?)してて一度こけた*1。自転車や普通の原付なんかでは、無意識で操作出来ているところを意識しなきゃいけないので*2、周囲を意識的に注意する+運転を意識的に注意する、というダブルの気遣いで、かなり気疲れする。

普通の自転車に慣れてる/普通の原付*3に慣れてるという人たちがこれ乗ると、多分「こわい」と思う。なんというか、従前の車種とは全然別のモノだと思ったほうがいい。A-bike electricみたいなキワモノ自転車のほうが、種としては近い感じ。

ちなみにブレーキについては、摩擦音が全くしないわりにはよく効くので、結構気持ちがいい。

 

幹線道路で乗るのはかなりリスキー

最高速度が20km/hくらいだけど、これで20km/h出すのはかなり勇気がいる。

慣れれば~とも思ったけど、小径車でコントロール失いやすいのは、乗ったことある人ならばわかる話だと思う。

 

結び

悪くはないとは思うけど、きちんと乗りこなすには相当の慣れが必要。

特に、アクセルブレーキの操作が全く異なるのは、これまでのものと全く違うので、ここを承知の上で乗りこなす必要がある。

電動キックボードで5kmとか10kmとか乗りたいか?というのとノリはいっしょかなと*4

*1:速度はほとんど出てなかったので、左ひざに擦過傷だけで済んだけど、速度が出てたら(たぶん)これだけでは済まないと思う

*2:普通のハンドルレバーやアクセルでないから、相当の操作をきちんと意識的にやらないとダメ

*3:スクーターやカブなど

*4:これだと正直、2~3km圏くらいがいいところではないか、と思うけど、慣れれば10kmでも20kmでも行ける人はいるかなとも

我が家にsmacircle S1がやってきた

我が家にsmacircle S1がやってきた。

まだ乗車してはいないが、やったことを淡々とメモしていく。

smacircle S1とは何か?

最近いろんな種類が出ている電動モビリティの1つ。

kibidango.com現物はすでに海外では販売されているが、日本で乗るためには保安部品の装着&ナンバー取得が必須。

今回のkibidangoさんのやつは、この保安部品~具体的には、ウインカー、ナンバー灯、バックミラーなんかか~をつけて、日本でのレギュレーションを満足したものを販売してたり。

smacircle S1の最大の特徴

折りたたみ時のサイズが小さいこと。

あとで述べるけど、畳むと専用(?)のバックパックにバッテリー、ナンバー、バックミラーなんか含めて全部入ってしまうレベルの小ささはもはや反則。

買う前に留意すべき事項

それは、あなたの体重

この電動モビリティ、耐荷重が100kgなのですが、これは当然持ち物着る物全部あわせてこの重さに収まっていないといけない。

乗りたいならば体重を減らそう。そうでもなければ別のものを選ぶのもアリかと思う。

現物が到着

紆余曲折して、現物が到着した。

現物(が入ってる箱)はこんな感じ。

f:id:wakatono:20210611000711p:plain


現物が来たらやること(手続き)

大まかに以下のとおり。

なお前提は、乗る人が(最低限)原付免許を持っていること&ヘルメットを所有していること。

  1. 公道で走りたいのであれば、何はともかくナンバー取得
  2. ナンバー取るならば、自賠責保険加入
  3. まさかに備えて任意保険加入

オレの場合は、3は自家用車の任意保険に、ファミリーバイク特約を追加する手配をしていたので、1と2だけで済んだ。

ナンバーは区役所で取得可能(書類が揃っていれば、ものの10分で発行してもらえた)。任意保険はコンビニで10分でできた(ローソンでLoppi使って手続き)。

なお、当然といえば当然だが、順序は「ナンバー取得」→「自賠責保険加入」の順序でなければならない。

これは自賠責保険に加入するためには、車台番号とナンバープレートの情報が必要なため。ちなみに自賠責保険に加入していないと各種法律により罰せられるので、自賠責加入サボるな。

現物が来たらやること(車体関係)

  1. ナンバー取り付け
  2. ひととおりの組み上げ(展開)
  3. 展開時の自分のスマートフォンとsmacircle S1の対応付け
  4. 折り畳み

ナンバー取り付けが一番の壁。

交付されたナンバープレートに付属するネジが、smacircle S1についてくるナンバー取付用のステーのネジ穴よりも微妙に大きい感じで、取り付けだけでかなり難儀。

ネジについては、ひとまわり小さいボルトとナットの組を用意しておいてもいいレベル。

折り畳んでオプションのバックパックに全部詰めたあと

こんな感じになった。バックパックには、ナンバーがついたウインカー等のユニットと、シート兼用のバッテリーも入ってる。なお、カートは自分が前から持ってたやつ。

写真の説明はありません。

 

展開と折り畳みの印象

ナンバーの着け外しミラーの着け外しが、結構面倒。

ほかはまぁ許容だけど、この2つが結構面倒。慣れればいいのかもしれないけど、という感じ。

 

とりあえず事前にチェックした感はこんなところ。

明日以降、乗った後の簡単なインプレッションを(書けたら)書くよ。

コインチェックのインシデント対応報告を読み解く

久々に(技術的にも実務的にも)良い意味で考えさせられる対応報告書を読んだ。

コインチェックの対応報告書がそれ。

読み解いてみたけど、存外に大変なことに(主にオレが書いた文の分量が)…。

コインチェックからリリースされたたインシデント対応報告

読んでいて、真面目な意味で面白く、かつ自分で考えようと思えばいろいろと考えられる報告書は、久しぶりに出会った。オレもこういう報告書を書けるようになりたい…。

corporate.coincheck.com

真面目な意味で「どこが」面白いのか?(あくまで私見

あくまで私見ではあるが、「監視業務にてレスポンスの遅延を検知し関連システムの調査を開始」という1行が、ものすごく興味をそそられた。

その次に「第三者によりドメイン登録情報が変更されていたことを確認」という結果につながるのが面白い。

この間の経過時間は、おおよそ7時間ちょっと。

その7時間にどんな調査/確認が行われたのか?は、いろいろと考える価値があるのだが、「レスポンス遅延」から「ドメイン登録情報が変更されていた」という経緯が、「風が吹けば桶屋が儲かる」を連想するレベルで「?」となり、その後に「レスポンスの内容を考える」ことにつながった。

その結果、自分の知見の総動員とまではいかないまでも、結構な勢いで自身の知見から仮説の再構成をするに至った。正直相当疲れたけど、ものすごく面白かった。

 

調査開始から事案確認までに実施したことを想定する

 

以降は、調査開始から事案確認までに、コインチェックで実施したのではないか?という調査の内容を考えていたりする。

 

レスポンスの遅延を検知

こういう話が出てくると、レスポンスの遅延が何に起因して発生するのか?が気になってくる。

オレとかは、Webサーバ/Webアプリケーションサーバへのアクセス時に発生する処理を並べて、遅延が発生するとしたらどこ?というのを考える。例えば以下のような処理がざっと並びますが、それぞれでどうなったら遅延が発生するのか?を考えてみることに。例えば、遅延という話だと、以下のような話が考えられる。

次に、遅くなる傾向(一斉に遅くなる/偏って遅くなる/遅くなることもある)などから、例えば以下のような話が考えられる。実際の対応現場では、もしかしたらもっと多岐にわたった検討を実施したかもしれないが、オレが考えられるのはさしあたり以下のような感じ。

  • 一斉にまんべんなく遅くなる場合
    単純にリソース不足。
    ロードバランサ等に異常はなく、均等に処理を割り振って、サーバ側の負荷が均等に上昇・処理量が増えている
    回線の帯域が逼迫している
    DNSの処理が遅延している
  • 特定のサーバに偏って遅くなる場合
    リソースが少ない特定のサーバが遅くなっていたり、ロードバランサのバランシングポリシーが誤っている(Webサーバ/アプリケーションサーバのリソース搭載状態によって、バランシングポリシーを均等ではなく30%:70%に振り分けるなどはありえる、もしくは同じリソースを持っているWebサーバ/アプリケーションサーバに、アクセスを均等に割り振らなければいけないはずが、なぜかバランシングポリシーがそうなっていないか)
    特定のサーバに至る回線が逼迫している
    特定のDNSレコードのみ名前解決が遅くなることがある
  • 特定の処理に偏って遅くなる場合
    特定処理(例えばDBMSトランザクションが入る処理)で処理遅延が発生する
    排他処理でリソース解放を待って遅くなる
    その他、希少リソースを取り合うなどの理由で遅くなることも
  • ばらついて遅くなる場合
    サーバ側に上記のような問題がある
    ユーザからサーバまでの通信経路に(局所的に)問題が出ている
    DNSの応答が時々遅くなる

上記の項目を全部一人で~となるとさすがに死ぬし、解決までの時間がかかりかねないので、それぞれに詳しいメンバが調査にあたったはず。とはいえ、Webサーバ/アプリケーションサーバ、DBサーバ、DNS、ネットワークの負荷がどんだけかかってるか?というレベルのチェックであれば、きちんとした運用をやっているところであれば、(時間はともかく)確実に状況を把握できるはず。

この時点で、DNSはあくまで疑義があるパーツの1つであり、ましてやレジストラの登録情報が改ざんされているなんて普通は考えない*1

 

Webサーバ/アプリケーションサーバのリソースも処理負荷も回線帯域も問題ない場合に見るところ~例えばNWの遅延

次に見るべきところは、NW上の(TCP/UDPレベルの)レスポンス遅延がどれだけあるか?という(わりかし)ミクロなところかなと思う。TCPはOSのプロトコルスタックが、UDPはアプリケーションが返すものだが、負荷に問題がない以上、おおよそのレスポンスを見積もるのはそんなに難しい話ではない。特に、国内のデータセンタ等に情報を置いているサービスであれば、海をまたぐレベルでの遅延はほぼ起こり得ない(除く沖縄)。

おそらくだが、ここで遅延をミクロに見ていたエンジニアが「おかしい」と気付いたのが、DNSのレスポンス遅延なのではないか。

原因はともかく、DNSのレスポンス遅延(フルリゾルバがキャッシュする前の、権威DNSからのレスポンスが遅い)は、遅くともこの段階で見つかる可能性が高い。ただ、DNSの負荷や経路に異常がない(DNS側から見たら、インターネット上の通信経路に異常がない)可能性は非常に高いので、システム側からではこういう話は気づきづらい。

 

権威DNSからのレスポンスが何故遅れる?~ここでDNSの配置が問題に?

権威DNSからのレスポンスが遅れる、でも権威DNSの負荷は問題なく、経路も問題ない、となると、レスポンスの内容を確認する動きになる。知らないDNSがいる、という話は、この段階でわかる可能性が高い

権威サーバは、リクエストに応じてレスポンスを返すが、このレスポンスは通常は、途中に存在するフルリゾルバ(DNSキャッシュサーバ)に一定時間留め置かれる。フルリゾルバがDNSからのレスポンスをキャッシュしている場合には、遅延が発生せず、そうでない場合には遅延が発生するのではないか?と考えるに至る。

 

DNSの配置がなぜ問題に?

ここで、DNSの配置がなぜ問題になるのか?を述べておく。

DNS自体は、クエリをさばいてレスポンスを返す単純なしくみであり、不明な内容があると、(権威DNSであっても)それを知っていると思われるDNSにリクエストを送る。例えばだが、あるドメインにおいて、サブドメインまるごと委任した場合なぞは、委任された先にもDNSが設置され、あるドメインの権威DNSが情報を持っていないサブドメインに対するリクエストと判断された場合には、サブドメインの情報を持つDNSに問い合わせを送り、応答をクエリ元に返す。

当然この場合、単独のDNSのみで処理を完結するよりも時間を要する。さらに、国外にあるDNSが、国内にあるDNSにリクエストを転送するような処理を考えると、

国内→国外→国内という感じで、一度国内にある(委任先の)DNSにリクエストを送る。

なお面白いことに、ここで何気に「距離」が効いてくる*2
物理的な距離が1000kmほど離れているところだとどの程度の時間がかかるか?だが、単純に委任先のDNSにリクエストが到達するだけでも、「国内→1000km→国外→1000km→国内」というように、2000km程度の時間がかかる。そして、光速度は30万km/秒と言われているが、光ファイバ内だとおおよそ6~70%程度まで低下するため、20万km/秒となる。この光速度で2000kmを移動するためには、0.01秒(=10m秒)を要する。光速度不変の法則とかいわずにもっと根性出せや、と思うかもしれないが、これが物理法則から導き出される限界の1つである。

 

そういう目でDNSのレスポンスを見て、レジストラへの登録情報に目が行く

システムを運用してる側からしたら、システムが順風満帆に動作していることのほうが稀で、実際には小さいトラブルや不具合が発生しながらも問題ないレベルに局所化していることのほうが(多分)圧倒的に多い

となると、まず「自分とこの不具合」を疑って、徹底的に調査を行い、不具合がないところでやっと外に目が行き始める。

そこで「外部要因の1つ」であるレジストラの登録情報に注目し、そこで改ざんに気がついた、というオチになったのではないか。

 

レジストラの登録情報が改ざんされていると発生する懸念

レジストラの登録情報~今回の場合はDNSの情報~が改ざんされていたわけだが、これはかなり重大で、ドメインを乗っ取られるのに等しい。

Webサーバが乗っ取られるのは、それはそれで困るが、ドメインが乗っ取られることは、リクエストそのものの最初の行き先を操られるというさらに困った事態に陥る。

レジストラの登録情報が改ざんされる=DNSの情報が改ざんされる、と考えると、メールの行き先も改ざん者が自由に変えられる。改ざんされて登録されたDNS上のMXレコードを攻撃者が持つホストにすれば、coincheck.com宛のメールを受け取り放題になる。ここで報告書の「問い合わせメール~」につながる。

 

別にコインチェックを擁護するわけではないが、この件は事象から原因にたどり着くまでが難しい…

後からはどうとも言えるかもしれないが、オレはこの机上検証を行うことで、「レスポンス遅延」から「レジストラの登録情報改ざん」を突き止めた方々の努力に敬意を表したい・そして、多岐にわたるレスポンス遅延の要因を1つ1つ潰し、レジストラの登録情報改ざんに至るまでの(想定)プロセスが、相当大変だという結論に至ったのは、1つの知見を得たとか考えている。

それこそここまでのことを10秒でトレースできる人がいれば~という話なのかもしれないが、そんな人はそうそういるわけではないし、オレもスタートとゴール(そしてその後)を見るまでは、そんなこと思いもしなかった

 

結び~適切な仮説設定と、仮説に基づいた地道な調査が一番重要

ここまでにいろんなことを書いたが、最も重要なのは「適切な仮説設定」と「地道な調査」ということ。仮説設定が間違っていると、調査はあさっての方向に行きがちだし、地道な調査を行わないと、積み重ねる事実が瓦解しかねない。

自分も気をつけないとなぁ…と感じた瞬間である。

 

*1:もしかしたら考えていたかもしれないが、遅延という事象に結びつくか?といわれるとそこは謎。

*2:実はTCPなどでも同じだが

みんなVPN死ね症候群にかかってないか?

極端なテレワーク推奨期間に入ってはや数ヶ月(?)、VPNについて「クラウドベースに移行するのを視野に入れて」とかなんとかいろいろと出てるけど、別にVPNが悪いわけじゃないぞ。使うVPNの種類と使い所を間違っているだけだ

ということで、本日はざっくりとしたVPNの種類と使い所を、自分の記憶と理解の範囲だけで説明してみよう*1

 

VPN is 何?~種類の前にまずはここから

VPNとは、「専用線とみなして使うことができる回線であり、専用線のようなもの」である。」という以上の意味しかない。ちなみに対義語はPN(Private Network)。技術的には、「接続される2点もしくはそれ以上をつなぐ」専用に使われる回である。しかしVPNは、技術的に専用線のようなものと言えるかもしれないけど、厳密には専用線ではない。それっくらいの意味しかない。

IP-VPN is 何?

IP専用のVPN。網は通信事業者が準備しているものを使う。機密性、完全製、可用性(この場合は利用可能な帯域)は、通信事業者がサービス内容に応じて設定する。結構お高い。

インターネットVPN is 何?

IPsecSSLなどを用いて、機密性と完全製を担保するタイプのVPN。可用性(帯域)は、通る経路によってだいぶ異なるため、まず保証はされない。ただ、トポロジにもよるが、IP-VPNよりは安価にすむことが多い*2

テレワークで使われるのは?~当然インターネットVPNだが…

インターネットVPNの場合は、接続されるのはエンドユーザと(例えば)会社であり、そこからさらに「別のサービスを使う」ための接続が走る。

ユーザ - 職場 - サービスサイト、というような構成になる。

サービスサイトは、なんでも適当なものを想定すればよい。例えばどこかのWebサイトでもよいし、Zoomなどのオンライン会議サービスなどでもよい。

インターネットVPNの問題は?~インターネット技術のよさをある意味全く無効化してしまっていること

テレワークで使われるのは、インターネットVPNだが、別にインターネットVPNが悪いわけではない。ユースケースが悪いのだ。

多くの場合、ユーザは手元の端末(コンピュータなど)から職場などに置いてあるコンピュータににVPN経由で接続し、そこからさらに外部のサービスに接続することになると思うのだが、このときに「通信が必ず職場を通る」ことになる。インターネットは、経路制御プロトコルなどの働きにより、できるだけ高速に通信ができる/通信ができやすい経路をユーザが意識しなくても使用することが可能である。

しかし、テレワークの場合、必ず「職場」を通り、そこからサービスに接続することから、「職場」がボトルネックになる。ボトルネックになっても、仕組み上しょうがない状態であり、もはやどうしようもない。

解決法の案~サービスはサービスに、会社の中は会社に、という形でTPOに応じた通信を実現する必要があるが、問題も。

解決法はいたってシンプルで、会社であろうと外部サービスであろうと、最適な経路を使えるようにすることだ。しかし、会社を通らないとガバナンス上(情報管理上)のリスクを抱えることになる。例えば「社員の私物PCに、業務上の機密資料が複製される」などがそのひとつである。

なので、テレワークを行う社員に配布するコンピュータは、そういうことを行えないような仕掛けを施す必要がある。

むすび~テレワーク時の情報管理に留意する必要はあるが、なるべく必要なサービスにはユーザの手元コンピュータから直接利用できるようにしよう

例で情報持ち出しのリスクの話を挙げたが、このあたりは別にテレワーク云々関係なく考えなければ行けない話である。

通信のボトルネックになるのが職場、というケースが多いことを勘案すると、そこは通らないが、情報管理をきっちりとやる、ということを考えるのがよい。

*1:恐ろしいチャレンジだ…

*2:そうでないと困る

CVE-2020-10136~IP-in-IPに脆弱性…

久しぶりに個人的なツボにはまる脆弱性が…

CVE-2020-10136の脆弱性概要

詳しくは以下のJVNの記事を見てください。
要は「IP over IPを実現する規格の1つで、悪用される脆弱性があるからね」というもの。

jvn.jp

この脆弱性を悪用すると、何ができるのか?

脆弱なIP-in-IPを使えるところを経由して、好きなところにIPパケットを送りつけることができます。いわば「IPパケットプロキシ」のような感じです。

IP-in-IPは、以下のRFCに記述されています。

tools.ietf.org

TCPコネクションが必要など、戻りパケットが必須な攻撃を仕掛けるためには、少しアタマを使う必要がありますし、DDoSのように「大量にあちこちからパケットを送りつける用途」には若干効率が落ちる可能性はありますが*1、単にパケット送りつけられればいいという話であれば、これは非常に有用な脆弱性になります。

対策のサマリ

該当するJVNhttp://jvn.jp/ta/JVNTA90492923/index.html)にも記述はありますので、そちらをご覧いただきたいですが、個人的にはそれも含めて以下の3つのいずれかになる、と考えています。

  • ベンダ製品を使っている場合には、修正を待つ
  • IPsec AHを使って、パケット認証を行う
  • IPsecトンネルなど、別の手段に置き換える

以下、上記のような結論に至った経緯を説明します。

IP-in-IPの通常利用と悪用のイメージ

以下に、通常の利用イメージ(あくまでイメージw)を示します。

f:id:wakatono:20200604035719p:plain

通常のIP-in-IPの利用イメージ

普通ならば、Normal Userが、IP-in-IPサービスを経由して、任意の(Normal Userが通信したい)ホストにIPパケットを送りつけます。

詳細は省略しますが、通常はNormal Userとの間で、IP-in-IPを利用したトンネルを開設していると考えられるので、戻ってきたIPパケットは、宛先IPアドレスがNormal Userのものであれば、またIP-in-IPを使ってNormal Userに送り届けられます。

ところが、通常のIP-in-IPの規格を見ると、以下のようなことも可能そうです…。
そして、今回の脆弱性は、どうもこういうことが出来てしまう、というように読めます。

f:id:wakatono:20200604040351p:plain

攻撃者もIP-in-IPを使うイメージ

ポイントは、Normal UserもAttacker(攻撃者)も、フォーマットが正しいパケットさえ送っていれば、カプセル化を解除の上IP-in-IP serviceを提供するコンピュータ上での処理が走る、ということです。

攻撃者が送りつけたいIP packet2とIP packet3は、送信元IPアドレスに何が入ってるかわからないですが、IPパケットを送りつけるだけで成立する攻撃を仕掛けたいのであれば、これだけで事足ります。

JVNで挙げられている対策~送信元を限定した遮断は「役に立たない」

今回、該当するJVNhttp://jvn.jp/ta/JVNTA90492923/index.html)には、以下の4つの対策が記述されています。

  1. アップデートする
  2. IP-in-IP を無効化する
  3. PoC を確認する
  4. 侵入検知システムでフィルタリングする

この中で、1のアップデートについてはよくわからない*2ですが、2についてはすべてのIP-in-IPを遮断・無効にする対策であり、使わずにすむのであれば、それが一番いいと思っています。

なお、よく言われる「送信元を限定する」対策は、今回の場合は役に立ちません。理由は後述します。

3は確認のための手段なので、有用といえば有用ですが、それで何かの対策になるか?は怪しいです。3を実施して、影響あるとなったら1,2,4のいずれかを実施する、というのが正しいでしょう。

4は「検知する」だけであり、これだけで遮断はできません。

送信元限定が対策にならない理由~IPはステートレス&IP-in-IPは認証レス

送信元限定が対策にならない理由は2つ。

  • IPプロトコルはステートレスである
  • IP-in-IPに認証の仕組みがない

IPプロトコルがステートレスであり、かつIP-in-IPそのものには認証のしくみがないため、別の認証手段が必要となります。実際、RFC2003(RFC 2003 - IP Encapsulation within IP)でも、Authentication Header(RFC 1826 - IP Authentication Header)について言及されています。

じゃあ対策は?~IPsecを使うこと。でもこの時点で、IP-in-IPいらなくね?

ここまで読んでくれた人はもう理解したと思いますが、安全にIP-in-IPを使うためには、IP-in-IPパケットの送信元が正当であることを確認出来る必要があります。今、IPパケット単位でこのようなことを実現できるポピュラーな技術はIPsecです。実際、前述のAuthentication Header(RFC 1826 - IP Authentication Header)も、IPsecを実現する1つの形態です(パケット認証のみを行うモード)。今はだいたいESPだけで暗号化+認証いけてしまうのですが、AHのような認証だけ行うというのも今回の場合は有効である、ということです。

もっとも、ここまでやっておいて、IP-in-IP + AHとするくらいならば、IPsecトンネルモード使えばいいんじゃないか?と思うのはオレだけではないはずです。

 

むすび~IP-in-IPを使うならばベンダの修正を適用 or AHを併用する or 他の選択肢を採用できないか?を考えよう

今回の脆弱性は、いろいろとステートレスの意味を考えさせられるものでした。

とりあえず「不正なIP-in-IP通信を検知できる」というところでしのいで(問題は、しのいだところで不正なパケット送付を防止できるわけではないこと)、ベンダ製装置を使用しているのであれば、修正を適用する、もしくはIPsec AHを使う、もしくは別の手段に乗り換えるかというくらいしかないです。

 

*1:カプセル化を解除した後のパケットサイズが、攻撃先に送られるパケットサイズになるので、帯域を食いつぶす系の攻撃には効率が悪い

*2:各ベンダが、IP-in-IPをどう実装しているのか?がよくわからないため