XSSとCSRFの違いをまとめてみた。
SCRF・・・クロスサイトリクエストフォージェリ
これらの2つはどちらもWEBアプリケーションへの有名な攻撃方法。
ただ、名前が似てるし、攻撃方法と被害もなんかあまり違いがないような気がして、個人的に全く覚えられなかった。
以下のIPAのガイドを見ても、正直わかりづらかったけど、
https://www.ipa.go.jp/security/vuln/websecurity.html
↓この本がかなり分かりやすかったので、この本を参考に、XSSとCSRFの違いをまとめてみた。
https://www.sbcr.jp/product/4797393163/
※注！※
このブログ記事を参考に実際に攻撃する行為はやらないように。責任取りません。
結論
超簡単にまとめると、以下の通り。
・XSS
1.概要
自分の端末でスクリプトが勝手に実行される
2.防御
・怪しげなリンクを踏まない
・CSRF
1.概要
自分が使ってるwebサービスを勝手に利用される
2.防御
・秘密情報はpostメソッドで送る
・重要操作を行う場合、セッションID以外にユーザを識別する情報を使う
・怪しげなリンクを踏まない
次からそれぞれに対してもうちょっと細かく記載。
結論に書いた通りですが、IPAのガイドから引用すると、以下の通り。
ウェブアプリケーションにスクリプトを埋め込むことが可能な脆弱性がある場合、これを悪用した攻撃により、 利用者のブラウザ上で不正なスクリプトが実行されてしまう可能性があります。
※https://www.ipa.go.jp/files/000017316.pdf
つまるところ、XSSに対して脆弱なサイトがある場合、第三者からスクリプトを埋め込まれてしまい、自分の端末(ブラウザ)で好き勝手やられてしまう、ということ。
ウェブアプリケーションにスクリプトを埋め込むことが可能、というのがピンと来なかったのですが、URLパラメータが例として挙げられる。
上の画像はヤフーで「こんにちは」と検索した結果のページだけど、URLの最後に「?」から始まるワードが付いてるのが見える。これがURLパラメータというやつ。
この場合、「p=こんにちは」となっているけど、pというパラメータに、「こんにちは」というワードを格納して、search.yahoo.co.jp/search というURLに送信してやると、pに設定されたワードで検索した結果を返してくれるような仕様になってる。
このようなURLパラメータに、悪意のあるスクリプトを埋め込む、というのがURLパラメータ。
ではこれをつかって、どのように攻撃をするのか。
上記の画像は、なんかしらのSNSが、URLパラメータを使っているとした例。
この図の右側にあるサーバに、XSSに対する脆弱性が残っているとする。
このとき、悪意のある人が、他人をなりすまし、悪意のあるスクリプトを埋め込んだリンクを踏ませようとしてくる。
この例では、SNSをやってる人に、異性を謳った悪い人からアプローチをして、リンクを踏ませようとしてくる。
画像中の赤字部分を見てほしいけど、userというパラメータに、<script>から始まるスクリプトを埋め込んでる。
細かい説明は省きますが、javascriptでcookieを取得するスクリプトを実行し、それをevilsite.comのURLパラメータにくっつけて、window.locationで強制的にevilsite.comに飛ばされる、という内容です。
この例では、XSSに脆弱性があると、上記のような方法を実行され、cookieが盗まれてしまい、アカウントが乗っ取ららてしまう、といったシナリオ。
これが銀行等のサイトだった場合、不正送金される等、より被害が大きくなる可能性あり。
これが、XSS。
対策
・変なリンクを踏まないようにしよう
じゃあCSRFはなんなのか。IPAのガイドでは以下のように記載されてる。
ウェブサイトにCSRFの脆弱性が 利用者 ある場合、悪意ある人により、利 用者が予期しない処理を実行さ せられてしまう可能性があります
※https://www.ipa.go.jp/files/000017316.pdf
クロスサイトスクリプティングと違って、webサイトにおいて、利用者が予期しない処理を実行される、とある。
つまり、XSSでは、自分の端末(ブラウザ)で実行できることはある意味では何でも実行されてしまう脆弱性だけど、CSRFでは、何でもではなく、そのwebサイトのサービスを勝手に実行される、ということ。
例えば、勝手にツイッターでつぶやかれるとか、勝手に5chに犯罪をほのめかす文章を打たれるとか、そんな感じ。
※XSSとの大きな違いはここになりますので、これはよく知っておいてほしい。※
では、ここからもう少し細かい説明は以下。
この例は、なんかしらのSNSにログインして、自分のコメントを投稿している例。
メッセージを入力し、投稿ボタンをクリックすると、「csrf.com/toukou」というCSRFに対して脆弱性のあるサーバ」に、「mss=草生える」というメッセージをセットしてサーバに送信し、SNSに投稿される、というサイトがあったとする。
ユーザ識別のため、ログイン情報(セッションID等)を管理しているCookieも合わせて送信している、という点に着目。
このとき、XSSと同様に、またまた悪意のある人が、異性を語って不正なリンクを踏ませようとする。
今回のリンクでは、javascriptで、「csrf.com/toukou」というURLに、「mss:〇〇○す」といったような、犯罪予告をほのめかすようなメッセージを送信させるようなスクリプトを記載したURLを踏ませる。
このリンクを踏むと、利用者のブラウザでjavascriptが実行され、「csrf.com/toukou」に、犯罪予告メッセージが送信され、SNSに投稿される。
なんでこれで勝手に投稿されるの？と思うけど、cookieは、送信先「csrf.com/toukou」のdoURLに勝手に付与される。
なので、cookieでSNSのログイン状態を管理しているのであれば、このSNSにログインしてるよ！とう情報も合わせて送られてしまうので、勝手に投稿されるということになる。
これがCSRF。
対策
・postメソッドを使おう
・重要操作を行う場合、セッションID以外にユーザを識別する情報を使おう
→トークンとか、もう一度パスワード入力させるとか、リファラを見るとか
・怪しげなリンクを踏まないようにしよう
まとめ
結局のところ一言でいうと、
XSSはブラウザで実行できることは何でも実行される可能性があるのに対し、CSRFはwebサービスで実行できることは何でも実行される可能性がある、ということ。
最低限このあたりを知っておけばいいんじゃないかと思った。
参考文献・図引用元
https://www.ipa.go.jp/security/vuln/websecurity.html
iPad/iPhoneのセキュリティをApple Configurator 2から設定してみる。CIS Benchmarksを添えて。
自分のPCについてはセキュリティのことをある程度？考えてはいるけど、スマホとかタブレットのモバイル端末についてはあんまり考えたことない。
パスワード長くして、英数記号混合で、、それ以外は何？と、思ったので、CIS Benchmarksを使ってiPhoneのセキュリティを向上させてみた。
CIS Benchmarksってなに？
参考リンク↓
https://www.cisecurity.org/cis-benchmarks/
https://www.nri-secure.co.jp/glossary/cis-benchmarks?hs_amp=true
つまり、アメリカ様を始めとした有識者たちが作っている、OSやミドルウェアなどのセキュリティのベストプラクティス集。
今回はiPad OS,iOSのベンチマークを使ってやってみる。
iPad OS,iOSのCIS Benchmarksの中身はどうなってるの？
ざっと中身を見ていく。
・英語。もうこの時点で読みたくない。
→タイトル、設定項目など、書き方が統一されているので、一つの章が読めれば、
あとはなんとかなる。
・ページ数大杉。
→企業所有の端末の場合とか、追加設定とか、個人利用の場合だとそこまで
やらなくても良さそうなものがかなり多いから、全部は見なくて良いと思う。
2章と4章の項目だけやればいいんじゃないかな。
ざっと見た限り、個人所有の端末でやったほうが良さそうなものは、30項目程度。
・どんなこと書いてあるの？
→とりあえずわかりやすそうなところをみると、日本語訳(google)するとこんな感じ。
タイトル
”ロックスクリーンでの通知センター表示を不可にする。”
説明
ロック画面での通知センター表示に関する推奨事項
根拠
オペレーティングシステムとアプリ間のユーザーへの通信は、データの漏洩や
悪用を防ぐために制御する必要があります。 たとえば、一部の2要素認証アプリは、
ロック画面の通知センターに、新しいデバイスからのログインを許可するオプションを
表示します。
以下、監査方法と設定方法が記載されてる。
そんなに難しくないね。
・Apple Configrator 2ってなに？
→iPhoneとか、iPadの端末の設定を一括して設定できるapple様製のツール。
macでしか使えないみたい。
ちなみに、CIS benchmarksは、このApple Configurator 2で設定することが
前提になっているので、macない人はお帰りくださいませ。(・∀・)カエレ!!
世知辛いっすね。
ここまで個人端末では設定しなくてもいいかな？と思った項目
※ここは個人の見解なので、設定したい人はご自由にどうぞ。特に責任は持たないです。
・Level2の項目
→CIS benchmarksは、項目ごとにlevel1、level2というレベル分けをしている。
level1は機能が制限されることなく、一般的に使えるセキュリティ設定で、
level2は機能制限を伴う強力なセキュリティ設定。
個人端末ではここまでやらなくてもよいかと。
・ロック中のSiriの禁止
→単純に、運転中にSiri使えないと不便だから。
・managed/unmanagedとついている項目全般
→管理対象、または非管理対象のアプリやサービスに関する項目。
管理対象とは、組織が管理しているアプリとか、サービスとか、そういうこと。
個人でやってるので、組織を対象とした項目は基本やらない。
・パスワード入力ミス6回で端末のデータ削除
→ど忘れした時にうっかり間違えて端末のデータ消されたくないから。
・3章の設定項目
→3章は組織管理の端末が対象のセキュリティ項目。
個人利用の端末なら不要。
設定してみる
上記をもとにiPhoneをセキュアにしてみる。
試しに2.1.1章と、2.4(パスコード関連)の項目を設定してみる。
iPhoneをUSBでmacに差し込んでから、Apple Configurator 2を開く。
※画像はiPad差し込んだ時の画像。
↓からプロファイルを選択して構成する。
まずは2.1.1章を設定する。
consent message has been configured(「同意メッセージ」が「構成済み」（自動化）になっていることを確認する。)
ナンノコッチャ、というところだけど、つまるところ、構成ファイルをインストールする時に、任意のメッセージを表示させろというもの。
メッセージ内容は任意、設定すれば構成された、ということ。
根拠としては、以下の通り。
ベンチマークのこのセクションでは、エンドユーザーが所有するデバイスに関する推奨事項を示しています。 彼らは自発的に構成プロファイルを受け入れており、同意する明示的な機会を提供する必要があります。
まあこれもなんのこっちゃ、という話だけども、要は構成プロファイルの受け入れは、自発的にやっているものだから、インストールする時にはちゃんと明示的に同意できるようにしておかないとだめだよ、というもの。
わかるようなわからんような、という感じね。
今度は2.4章のパスコード周り。
※2.4.2と2.4.6は個人端末では上述の通り、設定しない。
2.4.1 単純値を許可しない。
2.4.3 最小パスコード長を6文字以上。
2.4.4 自動ロックまでの最長時間を2分以内。
2.4.5 デバイスロックの最大猶予期間を即時。
これらは読めばわかると思うので、細かく説明はしない。
これでOK。
あとはこのプロファイルを流し込んで見る。
以下の画面が出てくるので、あとは端末側で設定。
閉じるを押下して、
右上のインストールを押下するとプロファイルをインストールできる。
説明のところに、さっき入力した文章が記載されてる。
がっ。
これで終了。
終わりに
案外簡単だったんじゃないかなと思う。
Apple Configurator 2は日本語だし、cis benchmarksもそこまで難しい英語の文章でないので。
上記は5項目くらいの設定だったけど、内容的にはそこまで難しくもなく、設定自体も容易。
こんな感じで2章の他の項目も設定してみてくださいな。
セキュリティに気をつけて快適なスマートライフを送ってくださいませ。
以上。
情報処理安全確保支援士の試験に合格したよ日記
2021年度春季の試験で情報処理安全確保支援士の試験に合格しました。
なので合格までの日記でも書こうかなと思ったので経緯を記載します。
情報処理安全確保支援士とは
IPAのサイトから抜粋。
サイバー攻撃の増加・高度化に加え、社会的なIT依存度の高まりから、サイバー攻撃による社会的脅威が急速に増大しています。すなわちサイバーセキュリティ対策は、経営リスクとして、そして社会的責任として、非常に重要な課題になりつつあり、その責任を担える人材の確保が急務となっています。この人材の確保のために2016年10月に「情報処理の促進に関する法律」が改正され、新たな国家資格が誕生しました。これが「情報処理安全確保支援士（略称：登録セキスペ）」です。
ということだそうで。
国家資格「情報処理安全確保支援士（登録セキスペ）」とは：IPA 独立行政法人 情報処理推進機構
日本のサイバーセキュリティに関する資格の一つで、IPAの中では高度の区分に入るよ。
日本のIT関連の国家資格の中で唯一の士業だとかなんとか。
ちなみに合格しただけでは情報処理安全確保支援士を名乗ることはできず、合格しただけで登録していないのに安全確保支援士って名乗ると怒られるみたいね。
きょわい。
情報処理安全確保支援士が守るべき義務や違反した場合の罰則は？ | しかくのいろは
安全確保支援士になるには、諸々の登録の手続きを経て、年会費とか、指定の講習を受けなキャいけないらしい。
まあCISSPと似たようなもんですわな。年会費と講習代高いなぁ！
勉強の流れ
仕事忙しくて正直スケジュール的にはあまり勉強時間を確保できなかった。
ぜんぜんべんきょーしてないわー（）やっべーわー（）という感じ。
2月
試験は4月末で、勉強始めたのは2月くらいから。
2月は1月くらいに買ってあった以下の本にざっと目を通す。
ちなみに買ったのはこの参考書だけ。なんでかって言うと全文pdfが読めるから。
分厚い参考書持ち歩くの嫌いだからiPadで勉強してたので、pdfのほうが助かるのよ。
3月
過去問を解き始める。IPAの過去の情報処理試験の経験から、正直午前問はⅠもⅡも4月ぐらいから過去問を空き時間に解き始めれば良いやと思ったので、まずは午後問から手を出すことにした。
毎週土日に勉強し、土曜に午後Ⅰ、日曜に午後Ⅱの問題をそれぞれ3,4時間で解答・復習という感じで勉強していった。
結局過去問としては、H29年度春季-令和2年度までの試験を4月の試験前までやっていったよ。
午後問全般の所感としては、業務でやっていることと近かったので、解きやすかったとは思う。だけど普段ググって確認するような細かい話を調べられないから、まあそこはきつかったりする。だけど、ひねくれた問題はなかった印象で、サーバ、ネットワーク等、広く浅い知識があればなんとかなるかなと思った。
4月
午後問やるだけでなく、午前問もいい加減やらねばということで、以下のサイトの過去問を空き時間にポチポチ。有名なサイトですな。
正直午前問はほとんど覚えゲーなので、↑の過去問を何周もすればなんとかなる。
午前問もH29年度春季-令和2年度をやったよ。
試験日当日
運良く徒歩10分くらいの場所が会場だったのでかなり助かった。
妻に見送ってもらって、途中のセブンで昼ごはんのおにぎりとチョコレート買って会場に向かう。
コロナだからか座席間隔は結構空いてた。個人的に人近いと集中できないので、こっちのほうが助かる。しかも一番後ろの席。引きこもりの私にとっては最適な環境でした。
午前問は淡々と解答。まあ大丈夫じゃねという感じ。
おにぎりとチョコ食べていざ午後問。
午後問Ⅰ・・・うーん、まあまあ解けたかなあという手応え。
午後問Ⅱ・・・あれ、ちょっと心配かも？という手応え。
手応え言われても分からんと思うけども、午後Ⅱはちょっと自信なかった感じ。ド忘れした部分もあり、ケアレスミスもあったりしたので。
なんとか受かっててほしいなーと思って帰宅。毎度思うけど試験時間長すぎよ。
早めに解答してさっさと帰ろうかと思ったけど、なんだかんだ見直ししてたらほぼ時間なくなってしまった。
7月
そして試験発表日。
正午に発表だったのでドキドキしながら閲覧。
無事自分の試験番号があったのでガッツポ。やったー。
ちなみに、午前Ⅰと午前Ⅱ、午後Ⅰは割と余裕あったけど午後Ⅱは割とギリギリだった。
あーやっぱりちょっと悪かったなあという感じ。まあ受かったからよいか。
久々に情報処理試験受かりましたわ。
結び
というのが合格の流れとざっくり勉強の流れでした。
教本に軽く目を通して、あとは午後問中心に過去問をひたすら解いて、間違ったところは復習という、まあ何も面白くない普通の勉強方法でした。
勉強時間としては、100-150時間くらい？かなあと。
合格したあとの感想としては、普段業務でセキュリティに関することをやっていたことが一番大きいかなあと思った。
午後問とかセキュリティの業務やってなかったら、さっさと諦めて帰ってたかもしれない。
まあこれでCISSPだけでなく情報処理安全確保支援士の試験も合格できたので、仕事での経験も合わせていい感じでスキルをつけてこられているんじゃないかなという感じ。
まあ意識高い言動は疲れるからあまり好きじゃないので、気を張りすぎずに、これからも程よくスキルも経験も向上させていきたいなと思った。
現場からは以上です。
オライリーのゼロトラストネットワークを読んでみたよ日記。
2020年8月に夏休みの宿題本として買っていたけど、怠けに怠けて2021年1月にようやく読み終えた。
なので今回はそのまとめを書いたよ。
↓読んだのはこの本。
全体通しての感想
もっと概念的なものを説明しているのかなと思ったけど、まあまあ具体的な話をしていたから、システム構築には役に立ちそうな気がした。
でも、結局のところ、"何をどうすればゼロトラストネットワークと呼べるのか"という定義がなく、ベンダごとに異なるので、各ベンダが提供しているゼロトラストネットワークの構築方法や、今回読んだような本をベースラインとして、あくまで、"ゼロトラストっぽい"ようなネットワークを作るしかないねと現状は思った。
例えば、マイクロソフトはO365を利用したゼロトラストネットワークの構築方法が掲載されているよ。
ゼロトラストネットワークは、最近バズワードになっているので、意識高い系の人たちや経営者たちが話題に上げることが多くなっている。
でも、現状はなんちゃってゼロトラストしかできないんだよ、というあたりの話は、どんなに疎まれてもしっかり説明し、理解させる必要がありそう。
ここからは、各章の要約を記載します。
第1章
ここではゼロトラストの概念が記載されている。
これまでは境界ごとにセキュリティを設計していた。
たとえば、エリアごとに高い壁を作る感じ。進撃の巨人みたく。
家で例えるなら外は信用できないエリア、家の中は信用できるエリアと分けて、
その境界は門で閉ざしていた。そこに門番おくとかね。
だけど、これだと門番を突破されたらあとは家の中を自由に仕放題。
たとえば住人に変装した悪いやつが家の鍵を偽装していたとする。
この門番を騙して、偽の鍵を使用されてしまったら、家の中に侵入されて家漁られちゃうよねえ。
それを良しとしないのがゼロトラストモデル。
みーんな悪者よ。という前提のもと考えられたモデル。
ゼロトラストは、平たくいうと家の中でもだーれも信用しないよということ。
家の中だったら、家に入ってしまったらあとは財布とか、通帳とかは普通に
とってこれちゃうけど、ゼロトラストはそんなことはさせない。
財布や通帳のありかは知られても、その代わり、だれが、どうやって、どんな信用度を
持っているかどうかで、財布や通帳をとってよいかを決めることがゼロトラストでは可能になる。
概念的には、コントロールプレーンとデータプレーンの2つで構成されるネットワークになる。
コントロールプレーン
保護されているリソースへのアクセスリクエストを受け付け、
デバイスとユーザを認証、認可し、様々なポリシーを適用することで、
OKと判断されたら、データプレーンにアクセスできる？
データプレーン
コントロールプレーン以外のすべてのもの。
ネットワーク上のトラフィックを管理する。
ユーザがアクセスするところと思ってよいかも？
例えば、データ、サーバ、アプリケーションとか諸々。
ゼロトラストモデルには重要な3要素というものがあるよ。
ユーザ認証、デバイス認証、信用の3つ。
ユーザ認証
これまでと同様で、たとえば門にはいるのに必要なもの。
顔とかね。
デバイス認証
門を開ける鍵が、正当な鍵かどうかを認証する。
これは従来あまりしてこなかったものみたい。
まあ確かに鍵の正当性を見ることって、あんまりないよね。
信用
これはスコアで示される。
クレジットカードの信用みたいなもんかね。
これら３つの要素を組み合わせて、こいつには何をしてもよい権限を与える、何をしたらだめみたいな権限を与える、的な感じ
どこにアクセスするにも、これら３要素からアクセスしてもよいのか悪いのか判断されるようなフィルターを通されるみたいな。
疑問点としては、結局通信、デバイス、ユーザすべてを信用しないとしても、
それを信用するかどうかを決める何者かは必要なわけだよね。
ということは、そいつが悪いやつだったりすると、悪さされる。
単一障害点になりえそうな気がするけども。セキュリティ的に単一障害点って、あまり良くないよな。
ただ、信用できるかどうかを、ビットコインみたく、ブロックチェーン的な感じでみんなで計算しあって
証明書発行したりするんだったらちょっと面白いかもねって、思った。
第2章
信用と信頼の管理
PKIを使って管理しようということを話していたと思う。(ここうろ覚え)
第3章
ネットワークエージェントの話
ネットワークエージェントとは、認可判断の対象になるもの。
エージェントの作成には、様々なデータが利用されることになる。
しかも目まぐるしく変化するよ。
組織にアクセスするときに、会社支給端末からの操作とかならよいけど、個人端末からの操作だと、結構あやしいよね。組織は認証済みのユーザだったら、デバイスはなんでもよい。という状況は求めてない。こういった概念がゼロトラストだと出てくる。
ネットワークエージェントとは、ネットワークリクエストをするエンティティについてわかっているデータの組み合わせを表す用語のこと。
通常は、ユーザ、アプリ、デバイスをデータとして含むらしい。
ちなみに、エージェントは認可判断には使うけど、認証には一切関与しないよ。実際問題、認証はエージェントが形成される前に実施され、ユーザとデバイスに対して別々に実施される。デバイスはx509証明書、ユーザは多要素認証を使ったりとか。ここはこれまでのネットワークと同じっぽいね。
ちなみに標準的なエージェントのデータモデルは現状ない。
SNMPとか、MIBは使えるかもしれんどねー。ということらしい。
第4章
ゼロトラストの認可についての話。
4つの要素を利用して認可を行う。こいつらも概念的な話。
エンフォーサ
データプレーン上にあるもの。
認可の判断をデバイスとか、ユーザとかアプリに適用するやつ。
例えば、具体的にはロードバランサ、プロキシ、FWに実装されたりする。
リクエストを受け付けたロードバランサはそのリクエストが認可されるかどうかを
知る必要があるよね。
そのリクエストをコントロールプレーンに送って、認可判断をまかす。
ポリシーエンジン
コントロールプレーン上にあるもの。
認可可否を判断するやつ。その時に利用するリスク分析はトラストエンジンに任す。
トラストエンジン
コントロールプレーン上にあるもの。各エンティティの信用スコアを計算するやつ。
データストア
コントロールプレーン上にあるもの。認可の判断に使うデータたち。
第5章
デバイスの信頼と信用の話。
まず、デバイスをセキュアに受け取ろうとう話。めっちゃ物理的だな。
受け取り方法は、常に品質が保証されたイメージを使用すべきということ。
へんちくりんなイメージを利用していると、怪しげなソフトウェアとかをインストールされる可能性あり。
そのへんは、セキュアブートという方法で対策できたりする。
セキュアブートは、ファームウェアに公開鍵が読み込まれることで、ドライバやブートローダの署名を検証し、
変に弄くられてないかを確認することができるよ。
デバイスの識別に使用いできる署名された証明書を提供する場合は、秘密鍵を安全な場所に保存する必要がある。
それは、一般にHSM、TPMと呼ばれるところに保存する。ここには、OSもアクセスすることが難しいところらしい。
コントロールプレーンではX509とかTPMとかでデバイスを認証するよ。そして信用は時間とともに失われるので、適宜更新しないといけない。
構成管理システムによって提供される、デバイスの種類とか、ロールとかIPアドレスとか、イメージの経過時間とか、アクセス履歴とか位置とか、通信パターンとかを認証に含めたほうがよさげ。
第6章
ユーザの信頼と信用の話。
アイデンティティには非公式のアイデンティティと正式なアイデンティティがあるよね。
非公式は適当なSNSでのアカウントになる。正式なものだと、現実世界では政府発行の個人IDとか、運転免許証とかね。
デジタルアイデンティティの生成は、人間が関与する確認方式が最も強力というのは、あまり変わっていないらしい。
通常、新しい社員を採用するときは、信頼されるユーザが、採用者を登録するよね。そんな感じ。
以後、ユーザを認証するときは、ユーザの専用ディレクトリLDAPとかを使って組み込むのが良いよ。
そこでは、something you know、something you have、Something you areの要素を
複数利用した多要素認証を利用しよう。
アウトオブバウンド認証つかったり、SSO認証も使うのもよいね。
第7章
アプリケーションの信頼と信用。
サプライチェーンセキュリティみたいに、コード作成の部分から考える必要あり。
ソースコード→ビルド→ディストリビューション→実行
これらのフローすべてがセキュアじゃないといかんよ。
意図的でも、意図的でなくても脆弱性が組み込まれる場合がある。
ソースの保存場所はリポジトリにあるので、そこに最小アクセスの原則で
セキュアにアクセスさせることと、コードが改ざんされてないかを確認する。
GITとかはまさにその例。あと、コードレビューね。
ビルド
ビルドサーバは標的型攻撃を受けやすいらしい。
ビルドサーバって昇格されたアクセス権限を持っていて、
本番環境で実行されるコードを生成されるから。
リスクとしては、以下の通り。
- ビルドしたソースはちゃんと意図したコードか。
- ビルドプロセスは大丈夫か。
- ビルド自体正常で、改ざんされてないか。
ビルドシステムは署名されたコードを読み込んで署名された出力を生成するけど、
ビルドそのものは暗号化されないんだって。以下の点に注意しよう。
- 入力を信用するように、署名されたものを入力させること。
- ビルドの冪等性を確保し、誰がビルドしても同じバイナリが生成されること。
- リリースバージョンと成果物バージョンを切り離すこと。
バージョンとビルドIDを管理すること。
改ざんされないように、ハッシュ化と署名をすること。
ディストリビューションのネットワークが不正なものじゃないか確認すること。
あと、全体通して、極力人間が関わる部分を限定させたほうがよいよ。
アプリケーションは、バージョンとビルドIDをちゃんと管理された状態で適切にアップデートさせること、何らかのシークレットを利用して認可を受けたアプリを利用すること。
また、ランタイムも注意しよう。人も含む。アプリをハックするより人を買収したほうが早かったりするよ。
アプリケーションは、アクセスできるリソースをアプリごとに制限しよう。
そうすると、変に攻撃されても、侵害される範囲を制限できるよ。
SELinuxとか、仮想化とかね。
加えて、アプリの挙動も監視しような。
第8章
トラフィックの信頼と信用
ゼロトラストでのトラフィックは、当然暗号化は必要だけど、もう一つ、完全性を確保しておかないといけないよ。
最初のパケットの信頼の確立はファーストパケットと呼ばれる。
これは事前認証と呼ばれる手法で解決できるらしい。SPAというもの。
事前認可鍵を持っているパケットは署名されたパケットを送信できるようになる。
この実装はfwknopを利用されるらしい。
あとは暗号化しようね。
ちなみに、ゼロトラストはOSI参照モデルでいうとでどこに位置するのかという話があった。
ゼロトラストの暗号化によく使われるのは、TLSとIPSEC。
ゼロトラストは全てセキュアしようというのが基本的な考えなので、より下位にある
IPSECのほうがうってつけとされる。
ただ、IPSECってまだあまり普及しきってない。
レガシーに比べて比較的あたらしいプロトコルだから、機器が対応してなかったりするとかなんとか。
そうなん？ここあまりピンとこなかったけど。
なので、クライアントとサーバのやり取りはmTLS、サーバ間のやり取りはIPSECかなってこの本では言ってる。
あとはフィルタリングしようや。
第9章
ここまでは、概要に加えて信用と信頼の話をしてきた。
この賞ではゼロトラストをどう構築していくかという話をする。
ゼロトラは最初から満たさなきゃいけない要件のリストじゃなくて、それらを目標として取り組んでいくもんやで。
この筆者の見解としては、以下にまず取り組むことが大事とされる。
- ネットワークフローはすべて処理される前に認証されなければならない (MUST)。
- ネットワークフローはすべて送信される前に暗号化されるべきである (SHOULD)。
- 認証と暗号化はネットワーク内のエンドポイントで実行されなければならない(MUST)。
- システムがアクセス制御を実行できるようにするために、ネットワークフローはすべて列挙されなければならない(MUST)。
- ネットワーク内では最も強力な認証 / 暗号化スイートを使用すべきである (SHOULD)。
- 認証にパブリック PKI プロバイダを使用すべきではなく(SHOULD NOT)、 代わりにプライベート PKI を使用すべきである。
- デバイスのスキャン、パッチ、ローテーションは定期的に実行すべきである (SHOULD)。
次にシステム図を作ろう。
その後にネットワークフローをとりましょう。全てのパケットをみるような感じ？かなり大規模になるけど。
構築当初は、最初のうちはコントロールプレーンがないアーキテクチャがある。その場合どうするか。
構成管理ツールを使ってズルするといった方法がある。
- 構成管理ツールを使うことで、システム対する変更を一貫した方法で適用できる。
- 構成データをバージョン管理システムに保存すると、変更とその理由がわかる。
- 構成管理システムによって設定ズレが起きない。といったメリットがある。
アプリケーションの認証と認可をしよう。
アプリごとに認証システムを実装するよりは、認証と認可を一元的に提供しとく。SAMLとか、openIDとかね。
ロードバランサとプロキシの認証をしよう。
ロードバランサとプロキシでユーザとデバイスの認証・認可をすることができるよ。
リレーショナルなポリシーを作ろう
2つのデバイス間の通信がFWといった従来のシステムで構成されていた場合、
これらのFWに設定されたポリシーを使ってリレーショナルなポリシーを運用させる感じかね？
ポリシーの分散をしよう。
これも、構成管理システムを使って代替できなくはない。
リレーショナルなポリシーに基づいてソフトウェアFWを設定すれば、
ホストごとのエンフォースメントを作れるし、通信もmTLSを使ってやればよい。
そしてポリシーの導入しましょうね。
次にゼロトラストプロキシを導入しよう。
具体的にアプリケーションプロキシのこと。認証、認可、暗号化を処理するためのもの。
こいつらは、リバースプロキシとフォワードプロキシで稼働させることができる。
どちらか一方の場合もあれば、両方使う場合もある。
第10章
ゼロトラストに対する攻撃者の視点を解説する章
なりすまし
クレデンシャルが盗まれるとやばいよ。
ゼロトラストでは、デバイス、ユーザでそれぞれ認証されるから、
従来よりは安全だけどさ。多層防御的になってるからかな？
DDoS
DDoSは従来から継続的に脅威になるよ。
オンラインのDDoSサービスは使ったりしたほうがよいよね。
エンドポイントの列挙
ゼロトラストでは、機密性は保証されるけど、プライバシーは未保証。
サイト間トンネルを使ってトラフィックを隠蔽することは、ゼロトラストでも可能らしい。
ちょっとようわからん。
コンピューティングプラットフォーム
信用されていないコンピューティングプラットフォーム使うとやばいよ。
コンピュータも永続データのメモリとか暗号化したほうがよさげ？
これも従来から引き続き注意してね。
物理的な脅威
脅迫とかね。あとUSBデバイス差し込まれたりとか。
無効化
実行中のセッションが数日間確立されたままだとあれだから、適宜無効化したりとか？
コントロールプレーンのセキュリティ
ここは俺もおもったわ。ここが侵害されると終わりだよね。
基本は限定的なネットワーク接続と厳密なアクセス制御から。
あと、コントロールプレーンをシステム管理の観点から分離させる。
専用のアカウントで管理されるか、より厳重なアクセス制御が適用される
データセンタの一部で動作させるとかね。
自宅にVPNサーバを構築してみた日記(l2tp,centos7)
ちょくちょく喫茶店に行くのだけど、フリーwifiってあまり信用していないので、やっぱり気軽にVPN使えるようになりたい。
でもケチなので、巷のVPNサービスに金は払いたくない。
という理由から、昔実家で作って放置していたNAS(CentOS)を使ってVPNサーバを作ってみることにしたよ。
ざっと書いてるので間違ってたことがあったら教えて下さい。
VPNはトンネリングと暗号化の2つの技術によって成り立つ。
トンネリングについては以下を参照すると、なんとなくわかるような気がする。
https://www.kddi.com/yogo/通信サービス/トンネリング.html
ようは、VPNって、例えば自宅VPNサーバとモバイルの端末をVPN接続したいなーってなったら、そのサーバとトンネルを張って、その通信を暗号化するということでVPNが成り立つ。
なので、多分だけど極論いえば暗号化しないのであればIPSECいらないんじゃないかな。
で、流れとしては、まずVPNサーバとL2TPというプロトコルを使い、レイヤ2のフレームにL2TPヘッダを加えて、VPNサーバとモバイルの端末の間でトンネルを貼る。
そして、そこでやり取りするレイヤ3のパケットを、IPsecで暗号化して通信するということになるよ。
ふーん、なるほど。なんとなくわかったような気がするよ。完全に理解したかと言われるとあやしいけど。
https://www.infraexpert.com/study/study10.html
[使った機器、ソフト類]
Centos7のlinuxマシン
Xl2tpd
→l2tpdでVPNを実装するためのもの。
Libreswan
→l2tpdはipsecとIKEの機能がないので、それを実装するもの。
[実装]
https://blog.kobalab.net/entry/20170804/1501857811
https://qiita.com/yume_yu/items/09f57a8923341c5b2316
このあたりを参考に。
悩みポイントは後述するけど、流れ的には以下の通り。
①l2tpの設定
xl2tpd.conf
サーバのIPとか、クライアントに払い出すIP範囲をとかを記載するところ。
options.xl2tpd
その名の通りオプションで、
vpn(l2tp)サーバに接続するための認証方法とか、dnsとかを記載するところ
chap-secrets
認証ユーザ、サーバ、パスワード、受け付けるIPアドレスを記載するところ。
②ipsecの設定
ipsec.conf
ipsecの設定を記載するところ。
ここでは、プログラムでいうmain文みたいなもんで、実態は他のファイルに目的ごとにそれぞれ設定ファイルが存在する。
ここにはそれらをincludeするよ、という文のみが記載される。
NAT、NoNAT時において、ipsecの接続モードとか、サーバIPが記載される。
default.secrets
PSKを記載するところ。
③firewalledの設定
centosのファイアウォールにIPSECとL2TP用の穴を空ける。
④sysctlの設定
sysctlはカーネルのパラメータを変更するときに使うlinuxコマンド。
ipv4や、NICに関する?カーネルパラメータをいじる必要があるみたい。
⑤ポートの穴あけ(ポートフォワード)
これはルータ側の設定。
IPSEC AH 50
→認証に使う。
IPSEC ESP 51
→パケットの暗号化に使う
→鍵交換に使う。
L2TP1701(UDP)
→カプセル化(トンネリング?)にはこのポートを使う。
[悩みポイント]
l2tpにつかうポート
これはそんなに起こり得ないかもしれないけど、別のサービスとl2tpに使うポートが競合していて、エラーがでていた。
なんでそんなことが起きたのかというと、昔このマシンにopenvpnを入れようとして、その時は面倒になって途中で設定するのやめたのだけど、その時にopenvpnのサービスを起動しっぱなしにしていたということ。
そこのサービスとポートがかぶってエラー吐いていたので、openvpnのサービスを停止させたら直った。
ip-secのconfig
ここに結構悩んだ。
というのも、参考にしたサイトを見ると、ここには「ローカルのIP」を記入！、
ここには「グローバルのIP」を記入！ぐらいしか記載なくて、
どの端末のローカルのIPアドレスなの？グローバルIPならルータだけど、ローカルならサーバなのか、ルータなのかどっちもあるしわからんやんけ！となり、他に設定あっているかどうかわからん部分も重ねて相まって、原因特定にちょっと時間がかかってしまった。
結論から言うと、
つまるところ、コンフィグに設定するIPアドレス類は、全部VPNサーバにしようとしている端末のIPアドレスで良い。
ルータの穴あけ部分で、通信に必要なポートに接続されたときは、ルータがVPNサーバにポートフォワードするため、configの設定としては、VPNサーバのIPアドレスでよいということ。
言われてみたらそのとおりなんだけど、ああなるほどって思った。
ちなみに、ここまでの作業一連をすべてやってくれる神スクリプトがgitにあるので、さっさとやりたい人はgitしてきたほうが良いよ。
https://gist.github.com/mix3/efbaf5cb47946bff6f56
という感じで、これでVPNにはつながる。ただし、実家のグローバルIPが固定になっていないので、DDNSを使ってIPと紐付ける作業が必要になる。
[DDNS]
ieserverを使ってます。
使い方はieserverのHPを見てもらえればわかるかと。
無料ダイナミックDNS(DDNS)サービス - ieServer.Net
アドレスを更新する際に利用するWgetでのアクセス先には、HTTPSを使うことにするよ。
https://fedorasrv.com/domain-ieserver.shtml
こいつを参考にcronに突っ込む。
で、全部の設定完了。
外部から接続できましたよ。やったぜ。
もちろんiphoneでも利用可能なので、これからフリーwifiあってもセキュアに接続できるね。
ただ、所詮パスワードでしか認証できていないから、証明書とか使ってできないのかなあと思ったりもしている。この辺やり方あったら教えて下さいエッチな人。
nature remo + raspberry piで温度/湿度を表示させたよ日記 ②
前回nature remoから取得できた湿度データを今度は、7segdisplayに表示させるよ。
まずはラズパイでLEDを制御してみる。
とりあえずググったりしてLEDを光らす回路を作ってLEDを光らせることにした。
でもなぜか光らなかったり。
ちょっとブレッドボードが適当な作りな気がして、いろいろと接触不良があるっぽい。
でもとりあえず作った回路とサンプルコードでLEDを光らすことに成功。
めっちゃ簡単なんだけども、おおーってなったよ。ちょっと感動しますね。
この後PNPトランジスタも使って増幅させてみたりして遊んだ。コレクタ接地コレクタ接地。
こんなことやるの大学以来だから楽しいなー。
使った言語はpythonです。別にpythonでなくてもなんでもいいんだけどもね。
7segdisplayに湿度を表示させる。
で、7segdisplayをいじってたら、シフトレジスタを使うっぽかった。
なんでつかうんだっけと思ってデータシート調べたらフリップフロップが中に入っているらしい。わおまじか。
なんとなくの挙動は覚えているけどどういう用途で使うのかがおじさんすっかりわすれてしまったよ。
というわけでググる。
このサイトが一番個人的に参考になりましたね。
ラズパイのGPIOに限りがあるので、それを減らすためにシリアルの信号を保持して、
パラレルの信号に変換できるよってもん。
なーるほどね。じゃあGPIOがが余ってたらあえて使わなくてもいいんだね。
まあ今回はせっかくなのでシフトレジスタを使って実装してみる。
回路図は以下の通り。字が汚くて悲しい。
桁は数値の桁のことですね。
import json
import requests
import RPi.GPIO as GPIO
import time as time
D4 = 17
D3 = 18
D2 = 19
INPUT = 20
STCP = 22
SHCP = 21
def getSensorData():
apikey = "[APIキー]"
headers = {
'Authorization': 'Bearer ' + apikey ,
}
data = response.json()
# print(data[0]["newest_events"]["te"]["val"])
return data
def setup():
GPIO.setmode(GPIO.BCM)
GPIO.setup(D4, GPIO.OUT,initial=GPIO.LOW)
GPIO.setup(D3, GPIO.OUT,initial=GPIO.LOW)
GPIO.setup(D2, GPIO.OUT,initial=GPIO.LOW)
GPIO.setup(INPUT, GPIO.OUT,initial=GPIO.LOW)
GPIO.setup(STCP, GPIO.OUT,initial=GPIO.LOW)
GPIO.setup(SHCP, GPIO.OUT,initial=GPIO.LOW)
def shift(dat,seg_num):
GPIO.output(seg_num,GPIO.HIGH)
for bit in range(0, 8):
GPIO.output(INPUT, 0x80 & (dat << bit))
GPIO.output(SHCP, GPIO.HIGH)
GPIO.output(SHCP, GPIO.LOW)
GPIO.output(STCP, GPIO.HIGH)
GPIO.output(STCP,GPIO.LOW)
def clear():
for i in range(8):
GPIO.output(INPUT, 1)
GPIO.output(SHCP, GPIO.HIGH)
GPIO.output(SHCP, GPIO.LOW)
GPIO.output(STCP, GPIO.HIGH)
GPIO.output(STCP, GPIO.LOW)
def initialize():
for i in [D2,D3,D4]:
GPIO.output(i,GPIO.LOW)
def main():
data = getSensorData()
s = str(data[0]["newest_events"]["hu"]["val"])
while True:
clear()
initialize()
shift(segCode[int(s[-1])],D4)
clear()
initialize()
shift(segCode[int(s[-2])],D3)
try:
clear()
initialize()
shift(segCode[int(s[-3])],D2)
except IndexError:
clear()
initialize()
def destroy():
GPIO.cleanup()
if __name__ == '__main__':
setup()
try:
main()
except KeyboardInterrupt:
destroy()
こんなコード書いたら動くよ。もっと綺麗にかければいいんだけどね。
流れは以下の通り。
1 nature remoからセンサデータを取得。
2 一桁ずつ読み込み、ビットシフトを使ってパラレル変換し、displayに出力。
3 出力のたびにクリア、初期化を行う。
これを3桁分繰り返すことで、displayに表示される。
わーい。光った。この63は湿度のことっすね。
家の湿度63%ってことだよ。なんか感想言いづらい普通の湿度でしたわ。
ちなみに最初はトランジスタ使って電流増幅させてたんだけど、取っ払ってもそんなに
暗くなかったので、取っ払ったものが完成版になりました。
※ソースはトランジスタ取っ払ったバージョンですよ。
トランジスタ有り版との違いは、HIGHかLOWかが逆になるくらいですね。
とりあえず完成したので、遊びがてた適宜使っていくか、もしくはLINEと連携させて、
湿度をLINEに送るやつ作っても、楽しいかもね。
nature remo + raspberry piで温度/湿度を表示させたよ日記 ①
nature remoから取得した温度/湿度をラズパイにつなげた7segd-displayに表示させてみたので、その流れを記載。
こういうの作った。
表示してるのは湿度。
概要
絵が汚くて謝謝。
流れ
ラズパイからAPI使ってNature remoを叩きに行く。
↓
叩かれたNature remoは温度/湿度をラズパイに返す。
↓
受け取った温度/湿度をラズパイのGPIOにつながった7segdisplayに出力する。
開発環境は以下の通り。
・開発PC macbook pro 16 + vscode
・使用言語 python
・ソース管理 Github
macでソースを作ってgithubにpush。ラズパイからソースをpullしてきて
プログラムを実行する流れ。
※github使ってるのはただ単に使ってみたかっただけなので、深い意味はないよ。
まずはNature remoからセンサデータを取得してみる。
nature remo
スマート赤外線リモコンの製品名。
こいつを使うとリモコン操作の家電をスマホで操作することができるよ。
人感センサ、温湿度計等も内蔵していて、それらの値をトリガーにして家電を
操作することもできる。
*温度〜以上だったらエアコンつけるとか。
ちなみにAIスピーカにも、IFTTTにも対応しているので色々と遊ぶことができる。
今の家ではエアコンと中華製ロボット掃除機をAlexaから操作して運用してます。
こんな製品なんだけども、こいつはWebAPIも持っているのでjsonでセンサの値を
取得することができたりする。
アクセストークンを取得する。
以下ページにアクセスして Generate Access Token を押すとトークンが発行される。
センサデータを取得して見る。
curlとか使ってnature remoにHTTP GETを投げつけるとセンサデータが格納されたjsonが返ってくるよ。
入力コマンド
curl -X GET "https://api.nature.global/1/devices" -H "accept: application/json" -k --header "Authorization: Bearer トークンの文字列"
ターミナル上でjsonが表示されるのでかなり見ずらいけども、以下みたいな結果が返ってきます。
※一部省略。名前とか記載されてるので。
"newest_events":{"hu":{"val":66,"created_at":"2020-06-23T06:40:35Z"},"il":{"val":58,"created_at":"2020-06-23T09:03:09Z"},"mo":{"val":1,"created_at":"2020-06-23T09:08:00Z"},"te":{"val":26.6,"created_at":"2020-06-23T07:32:07Z"}
huがhumidity、ilがilluness、moが人感センサの値、teがtemperature。
それぞれの値はvalに記載されてる。時刻はGMTなので日本時間と異なるので注意。
このvalの値を7segdisplayに表示させればOK。
ただ、これはあくまで動作確認用。
ターミナル上のコマンドで取得してきているので、7segdisplayに表示させるなんかしらのプログラムで動作させないといかん。
今回はpython使って作ることにした。
とりあえず湿度を表示させるプログラムは以下。これをラズパイ上で実行する。
import json
import requests
apikey = "トークンの文字列"
headers = {
'Authorization': 'Bearer ' + apikey ,
}
data= response.json()
print(data[0]["newest_events"]["hu"]["val"])
dataの["hu"]の部分をteとかにすれば温度も表示できる。
かんたんね。
あとはこのプログラムで取ってきた湿度とか、温度を7segdisplayに表示させることができれば完成。
この辺の話は次回。
