セキュリティ の記事一覧

4/21（木）にGMO Developers Night#34 「ペンテスターから見た最近のセキュリティ状況」をオンラインにて開催しました！今回は、GMOインターネットグループにジョインした「GMOサイバーセキュリティ byイエラエ株式会社（旧称：イエラエセキュリティ）」のホワイトハッカーたちが、幅広いトピックを対談式でディープに語りあかしました。イベント告知：https://developers.gmo.jp/15344/本記事はこちらのイベントの書き起こしとなりますので、ぜひご覧ください。 登壇者（敬称略） GMOサイバーセキュリティbyイエラエ株式会社代表取締役CEO　牧田 誠オフェンシブセキュリティ部部長　ルスラン・サイフィエフ株式会社川口設計代表取締役　川口 洋 会社説明 牧田当社のミッションは、「日本のセキュリティを守る」ということです。誰もが犠牲にならない、安全なインターネット社会を創っていきたいと思っております。逆に言うと、現在はあまりセキュアではないということになるんです。我々、ペンテスター、ホワイトハッカーから見ている世界、日本の最近のセキュリティの状況と、一般の方々が見ている世界では、少し違いがあると感じています。我々はあまりセキュアではない世界を見ているんですけど、恐らく今日参加されている500名の皆様も、そこに気付いているからこそ参加されているのではと考えています。今までの侵入テストの案件をすべて集計して統計をとったところ、90％以上の案件で侵入に成功しているという結果が出ました。我々ペンテスターは、90％以上の会社やシステムに対して侵入できる、脆弱であるという景色を見ていて、この景色を、このあとの対談の中で少しでも参加者の皆様と共有できたらと思っています。そして、GMOインターネットグループに4月にジョインし、新しい社名で活動していますが、その理由は、我々が掲げている「日本のセキュリティを守る」というミッションを最短で実現できるからです。イエラエのホワイトハッカーが持つノウハウをプロダクトに落とし込んで、プロダクトをGMOインターネットグループのお客様、ドメインでいうと日本の90％、レンタルサーバーだと日本の60％のシェアを持っているわけですけど、我々のサービスでそれらのお客様を守るというのが、グループジョインの理由です。 対談 テーマ：ペンテスターから見た最近のセキュリティ問題 川口最近のセキュリティ状況をペンテストで見てきて、話題はありますか。 最近のテーマは「監視」です。ルスラン 川口ペンテストで、お客様のシステムの監視はどのようにできているのでしょうか？監視をくぐり抜けてゴールを達成しているケースが多いように思いますが。 監視に検知されずにゴールを達成することもあるし、あとはゼロトラスト環境で端末が監視されていても不足していることが多い。基本的に多くのお客様はセキュリティ製品を導入、運用している。しかし、そのような製品は今まで出ている攻撃やばらまき攻撃に対してはすごく有効だけど、そうでない攻撃を使えば、技術のある攻撃者なら監視をすり抜けることは可能です。ルスラン 川口依頼されるお客さんは、それなりにやってるからペンテストやろうといるのに、セキュリティの監視をやっているにも関わらずここは監視されてるだろうからこうやって抜ければいいよねとルスランさんはかいくぐってやっているということ？ それもあるし、案件やお客様の要望に応じることもあります。例えば、お客様の中で我々のセキュリティ製品が本当に稼働しているか確認するために、Emotetのような攻撃を実行してみましょう、ということでテストして評価という感じですかね。ゼロトラスト環境を作ったので評価してあげるという感じですね。例えばAzureのグローバル管理者を奪取することが最終ゴールの案件であればそこまでたどり着いたけど、監視チームに検知されなかったというのはあり得る話ですね。ルスラン 川口Azureグローバル管理者を取られたたら、為す術がない、アドミンとしては聞きたくない報告だ。「ゼロトラスト」というキーワードは、マーケティングや営業のキーワードとしてよく使われていて、うちもそろそろゼロトラストを考えなければ、と導入する動きがここ2～3年進んできているけど、広くゼロトラストだと言っている環境においても、ペンテストで抜けていって、権限が取れたというケースがあるんですね。 あります。ゼロトラスト自体の考え方はモデルとしてはいいんですけど、実現しているベンダーさんや、導入している会社での実装状況によって変わっていったりします。最近ですと、ゼロトラストといいつつVPNの代わりにVPNっぽいものを入れた製品もある。あとは、SaaS化されたとか、SSOが実装されたとか、IdP（Identify Provider）としてはAzureやOktaを使っているという例も多い。一つの例で言うと、セキュリティ製品がいろいろ導入されている端末、仮にEDRとかアンチウイルスとか全部あるという端末に感染ができた場合、外部遠隔操作ができた場合、かつEDRとかも検知されていない場合、通信も判別されていないという状態であれば、攻撃者としては全部SaaSなので、オンプレミス環境がない環境を考えてみると、すべてクラウドになると、すべての業務がクラウドになります、一番守りたい資産、社員の守りたい資産といえばブラウザになるんですね。ブラウザの中のCookie、多要素認証がいろいろ付けてあっても、人は対象のサイトに認証してあるんだったら、多要素認証を通しての形で、そのセッションを我々が取得できたら、外部からもどこからでもアクセスできる。EDRは、そこの端末にあるからこそ動作するが、我々がVPNのセッションを修復できるのであれば我々の端末から内部に入れるとか、モニターできるツールをすり抜けるいうことも実現します。ゼロトラストは端末がすべてだから、端末から来るものを全部監視するけど、通信がどう監視されるかは基本的に会社によるというということになります。ルスラン 牧田今の話はエッセンスが2つあると思います。最初の「監視が大事」ということ、これはペンテスターの視点。我々のような一般の人は、防御の方へ行きたいじゃないですか、ファイアウォール、ゼロトラストやEDRといった防御の方に行きたい。監視が大事って話は、EDRやファイアウォールはバイパスできる前提で考えないといけないよ、というペンテスターの目線なんです。2つ目は、ゼロトラストで全部クラウドになって、セッション1つでシングルサインオンで全部いける点、みんなにとっては便利だけど、攻撃者、ペンテスターにとっても便利であること。オンプレミス環境だと、セッションが分かれていて、全部セッションをとらないといけなかったけど、シングルサインオンで、マルウェアに感染して、ブラウザのセッションをダンプすれば、そのあとは全部のセッションに行けてしまう。ゼロトラストは、ペンテスターにとっても便利だし、完全にセキュアではないという点。 川口Cookieをとるとか、聞きたくない話ですね。攻撃者に入られて、Cookieを持っていかれましたとなると、そりゃそうだよね…となるけど、運用や設定でなんとかなるものなんですか？Cookieを取られないようになんとかしようなのか、それともCookieを取られてもいい策をとるのか、どっちがよいでしょうか。 対策といえば、セキュリティ製品にすべて頼るというのは、現時点では見たことないです。多少カスタムなものを作って、仮にChromeを使っている場合はChrome以外から使うことがないので、Cookieに触れた瞬間に監視してアラートを出すといったものを作るとか、現時点では有効な感じ。そのあとの話となると、不審アクセスのような感じでCookieが取られて、攻撃者であればあちこちにアクセスするとか、例えばAzureEDのようなIdPに外部からアクセスしてしまったとか、感染した端末を踏み台にすればIPアドレスも変わらないけど、外部からいきなりアクセスした場合はIPアドレスが変わる、といったような、細かいログを解析して不審だなといったのを見ていくしかないと思う。こうなってくると、SaaS側ですべてのログを収集しながらやるという必要があるし、boxなどのクラウドストレージの場合は、いきなりいろんなファイルにアクセスしてダウンロードし始めたということならある程度見られるぐらい。ルスラン 川口守りにくいと思いますがどうですか？ 牧田そうです。開発者は守りたいじゃないですか。Cookieを取られないための対策もしますし、万が一取られても大丈夫なように、暗号化したり、端末のホスト名やユーザー名、macアドレスなど全部マッチしない限りセッションを有効にしないように工夫する。でもペンテスターの目線だと、ならばそこを解析すればいい、と考えるんですね。この暗号化方式で鍵はこれね、じゃあ復号して、macアドレス変えて、再暗号化すればいいよね、と。 対策が大変なのは、SSOみたいな感じで各サイトに認証するじゃないですか、SSO自体の対策としては、例えば各サイトにアクセスするにはまたIdPとか多要素認証、一番よければYubiKeyみたいなFIDOがあってさらに認証しなければいけないという導入ができるのであればよいが、ただし認証済みのセッションが取れるということは、基本的には、各サイトのCookieの有効期間がサービスによって異なるので、例えばAzureのSSOのCookieの有効期間を1時間とすればそれは1時間で切れるが、BOXやDropboxなどのほかのサービスでは1か月とか無限とか異なるので、そのあたりのコントロールは、ユーザー側、システム管理者側にはないので、そこがちょっと大変。ルスラン テーマ：開発者が使っているサービスで気になるもの 川口開発者が使っているサービス、代表的にはGitHub回りだけど、ここになんか情報が入っているとなると、そこのアカウント権限が取れちゃうというところからスタートするというのがあって、日常のオペレーションでGitやGitHubを使わざるを得ないところにペンテスターが差し込んでくると、ここも攻略の糸口になっているケースが多いと思いますが。 我々のゴールはいろいろあるけど、やり方もいろいろあって、例えば感染済みの端末からスタートするとか、外部公開されている情報を探してそこからエントリーポイントを探しに行きます。両方とも外部の情報を集めるので、Gitから始めることはあります。会社名を入れるとかいろいろ検索して、何も見つからない案件はほぼなく、そもそも企業の中に開発者がいない案件ぐらいかもしれないですね。あっちこっちに認証情報がどこでもあるというわけではありませんが、情報収集という意味ではかなり役に立つものがあります。昔の事例でいうと、Gitってなにが悪いかというと、何か間違えてアップロードした後に消しても、コミットが消されていない状態であれば、誰でも履歴から過去のコミットを見て情報が得られるので、ある案件では、鍵が取れて、鍵から外部のサービスにAPIキーで入れて、そこから内部情報が取れたというケースがあります。ルスラン 川口ついうっかりコミットしたという例があると思う。認証情報とかをignoreに入れずについ入れてしまって、消したからいいだろうと思ったらコミットの方にあるみたいな。見えるよね、探れるよね、というところから、あとになって悲鳴が聞こえるパターンですよね。 牧田一番びっくりしたのは、あるセキュリティ製品で、ソースコードが公開されたというもの。 あれは、開発者というよりは開発者のインターンが会社に入ってDropboxのリンクをメモの中に入れていて、Dropboxのリンクに入ると、機密情報が誰でもダウンロードできる状態だったのでかなり大変でしたね。ルスラン 川口Dropboxのリンクとか1回リンク作ってしまって期限なしになるから、それがどこかで漏れると、フォルダ以下だったらざくざく見れてしまいますね。 そうですね。プレミアムサービスに加入しなければ、基本的にアクセス経歴とかも取れない。ルスラン 牧田無料版で使っている場合は確かに。会社アカウントだけじゃなくて、個人のプライベートのアカウントで会社の情報まで間違ってコミットしちゃったというのがあって、ペンテスターってすごいですよね、すぐに人を特定して、この人がこのTwitterアカウントを持っていて、と紐付けて、そこで鍵が取れてしまって、とかいうのがあったりするので、プライベートで使う時は気を付けないといけないですよね。 川口会社が創業期だったりすると、そのあたりが割と緩く管理されたりするじゃないですか、個人の能力に依存してシステムが開発されてたりしてとか、もしくは中途で結構できるエンジニアが入ってきたりすると、ちょっと境界線が甘い時期があって、そういうところが突かれると厄介。会社が大きくなると結構きっちり分けて管理するようになると思うけど、会社のステージによっては割とケアされてなくて、ペンテスト受けてみて気付くパターン。 牧田僕が面白いと思ったのは、自分たちの会社で使うソースコードの中で、固有の言葉を入れて、それをクローリングしておくということ。誰かが間違ってパブリックにした時に、固有値を検索して引っかかるのですぐ止められるというのは、賢い対策。みんな気を付けて二重チェックとか三重チェックするといっても、注意力に頼る部分って限界があるので。 テーマ：運用管理体制のチェックが必要だと思ったこと 川口今度は運用回りで、このあたりはもう少し気にした方が安全なのでは？という事例を聞きたいと思う。開発できちんと作っていても、運用が一番ベタだけどシステムのパスワードを書いたExcelファイルがあって、パスワード管理台帳を取り出せるという例が結構あったりする。わたしもいろいろ相談を受ける中で、パスワード管理台帳を持って行かれて、さんざんシステムをペンテスターにやられましたという相談を受けることがあります。 結構あります。特にオンプレミスのドメインがあるとファイルサーバーもあるので、「平文パスワードの管理」「共通パスワードの管理」「脆弱なパスワード」が報告書の中のTOP3。たぶん最近はクラウドのみの環境になってきて、みなさんがパスワードマネージャーをきちんと使うようになってきて、少なくはなってきた。でも、やっぱり大企業やオンプレがある環境とかだと整理が大変だし、昔ながらのやり方で残していることが多いです。ルスラン 川口ここまで頑張ってやってるのに、なぜパスワードリストやパスワードを書いた手順書がさらりと置いてあるんだという感じの相談を受けると、ここがなんとかなればもうちょっと安全なのにと、見つけたのがセキュリティベンダーの方でよかったなあと。 そうですね。平文パスワードはないにしても、基本的に我々がゴールとするシステムが、仮になにかしら特殊に作られたシステムにしましょう、そのシステムのパスワードが毎日変わるわけでもないし、たぶんいつか作られてずっと運用されている形になるので、どの会社でも「納品物」みたいな感じのフォルダがあるんですね、そこに仕様書があって、その仕様書の中にパスワードが書いてあるとか、それで半分以上のパスワードが取れるという感じ。ルスラン 川口納品物フォルダはゾッとしますね。あるあるですけど。 納品されてからパスワードを変えていればいいけど、そのままなので…。隣りに変えてはだめと書いてあるので。ルスラン 川口パスワードは想像できるが、APIの鍵のような鍵管理をどう安全に運用していくかというのは、鍵を使わないケースというのはせいぜいSSHの公開鍵ぐらいという組織もあれば、APIの鍵をバンバン使いこなす企業もあるけど、鍵管理はどうですか？ SSHに関していうと、そもそもSSHで鍵を使って認証しているのであれば、かなりいい方という感じ。それにYubiKeyで二段階認証があれば、おお、すごいという。となると、基本的にそのサーバーは対象にしない。ゴールを達成するためには絶対にその経路を通るということは必要ないので、ほかを探すことに決めます。パスワードが分かっているSSHの証明書だったら、それはちょっと解析してみてみるとか、あとは社員個人のアカウントだったらそれで入ってみるとか、牧田さんと一緒にやった案件では、ある鍵ですべてのサーバーに入れたというところもありました。ルスラン 牧田各企業で監視用、障害対応のものを作りがちだけど、それが仮に攻撃者に取られたりすると、悪用されてしまう。 ほかのAPI鍵とかAWS鍵になってくると、今でも外部と内部という感じがあって、例えばある会社だと内部はセキュアという考え方で、その中では内部のGitがあって、内部のGitはそもそも認証なしでエクスプローラですべてのプロジェクトが見れたりして、それが内部だから鍵がそのままハードコードされていたりするのもあります。そうなると、アクセス制限ができてない会社がかなり多い。要は、開発者であってもアクセスできる領域がどこまでかを決めなければならないはずだが、何でもかんでもできるとか、一般社員で営業なのにGitに入れてプロジェクトをクローンできるとか、認証なしでイメージをとれるとか、そこからいろいろ鍵をとって本番環境まで至ってしまうこともあります。あとは、会社によっては、物理的にセキュアエリア、セキュアルームを作っているけど、論理的にはそこのネットワークに入れてしまうとあとは信頼性の高いエリアということで二段階認証もなにもないということもあります。オンプレ環境で横展開してしまうと、監視に気付かなければずっとそこにいて何でもできるという状態になります。二段階認証を破らないと入れない環境だと、かなりできてるな、と喜ぶ。しっかりやってるなと。ルスラン 牧田せっかくセキュリティルーム、物理的に行かないとデータベースに触れないという制限を作っても、運用を考えると、障害が発生した時に自宅から緊急対応したいじゃないですか、セキュリティパッチを緊急で当てたいとか。そうした場合、物理的にセキュリティルームとかデータセンターに行くのが難しいので、皆さんどうしても遠隔でアクセスしたくなるんですよね。で、メンテナンスの手順書を作り出して、きちんと鍵もパスワードもそこに丁寧に書きがち。そうすると、せっかく物理ルームにアクセス制限してるのに、緊急メンテナンス用、障害対応用のVPNの情報が見れてしまう、アクセスできてしまう場合が多いので、そこを使って入れてしまうということがあるんですね。 結局、緊急用の手順書や鍵を置いてあるところは仮にファイルサーバーとして考えても、ファイルサーバー自体がおそらく信頼のあるユーザーしかアクセスしないと考えられているかもしれないけど、ある権限までは入れてしまう、確かに物理的に行かないとどこかに入れないけど、手元に緊急用のVPNの認証情報がなんでもあるから、それを使い回してつなげばよいというのもある。もちろん繋げる時間を決めてあるかとか、繋がった途端監視されて切断されるとか、会社によってはプロセスがあるはずだけど、一番悪いシナリオでは、何も気付かれず監視されずだったらそこにまで入って終わってしまう。ルスラン 川口そんな危ないシステムを動かすのなら、Slackに一報を飛ばして欲しいですね。本当にここが突破されたらまずいというところは、通知が飛ぶ仕組みになってないと気付きようがないですね。 通知はすごくいいと思います。特に管理者側におすすめなのは、資産管理、どこに何があるかとか、そのシステム自体にはどのように入れるかを把握しておく、彼らが自分で考えて作った経路はあると思うけど、我々も中に入って社内wikiとかを読んで、正常に入れる経路を把握する、それがイコール我々がその経路を通ると検知されてしまう、だったらそれを通ってはいけない、だから同じサーバーなり同じシステムに、ほかには入る経路は何があるかとか、管理者自体がどんなふうに入ってメンテナンスするかを考えてみて、それを利用してしまうと実はそこには検知やアラートを出す仕組みをわざわざ入れてない、あるいは忘れたということがあって、最終のところまで入れてしまうということもある。検知を回避するという意味では。ルスラン 川口ある役所で相談を受けたとき、「分かりやすいところにパスワードを置いてありますから」と言ってました。悪い人が先に使うと思うので、先に使ってもらってアラートをあげてもらいますという。このバッチファイルなんですか、と聞いたら、「それはログインしたら危険なものです」という。分かりやすく置いてあるので、使われることをむしろ期待しているという、使った人がいたら速攻取り締まりますという。 それはいいですね、ハニーポット的な。ルスラン 川口わかりやすく置いていれば使われるんだという。たぶん、ログインすると全職員にアラート飛ぶんだろうなという。それは手間が掛からなくできそうだと。 その次のステップを考えないといけなくて、どこからやられたかとか、次に何を確認すべきか、という演習。IR（Incident Response）的な。要は、端末をネットワークから取り出さないといけないけど、どのくらい時間がかかるとか、ユーザーが高権限のアカウントをハニーポットにしてある場合は、高権限のアカウントで実は横展開されてしまった可能性はなないか、どういう風に実装していたかにもよるけど。ルスラン 牧田Active Directoryの問題があるじゃないですか、あれは非常に守りにくい。たぶんルスランさんは侵入できなかったことがないと思うんですけど、以前印象に残っていたフレーズで、「Active Directoryの侵入方法は無限にあるから大丈夫だ」と。侵入できそう？大丈夫？と聞くと、「無限にあるから大丈夫」という。ならばどう守ったらいいのという。例えば「administrator」というダミーのアカウントを作って、使われたら取り締まるというアイディアはいいなと。 でも、どのアカウントでも作っていいというわけではない。ある会社で、ダミーアカウントを作りましたと、でも、どう見てもそのアカウントを使いたいという気持ちにならなかった。なぜかというと、権限も何もなにもない、ログインした経歴もない、パスワードが弱いかもしれないがそのアカウントが取れたところで何も変わらないという。確かになんとかアドミンというアカウントだったけど、どうみても権限がなさ過ぎて逆に怪しいということは侵入者からは見えるんです。生きているかのようなアカウントで、多少権限があって履歴があるようなものを作ってあげないとすり抜けてしまう。ルスラン 川口クライアント認証をやっているシステムがあると思うけど、こういう時に突破できてしまう、こういう設定さえあればよかったのに、というエピソードがあれば。 最近、かなり多いですね。クライアント証明書、ウェブアプリとか、個人的にはすごくいいと思うけど、その認証はその証明書をどんなふうに保管するかいうのが大事になってくる。WindowsのマシンであればTPMで保存している場合は基本的には現時点では安全ですね。どこかにはまだ公開されていない攻撃があるけど、少なくても今のところはTPMからの証明書の奪取ができない状況ですね。ただし、TPMじゃなくて、ファイルとして保存してあるとか、スクリプトプロバイダーとかほかの形で保存してあるとかであれば、システム権限さえとれればWindows端末から証明書の奪取ができてしまうのが現実です。Macの端末の場合は違っていて、MacはKeychainというものがあって、ユーザー側とシステム側のKeychainがあって、ユーザーのセッションに会社から遠隔操作ができる状態になっていたら、基本的にはすごく簡単にダンプしてしまうということができる。システム側のKeychainに入っている場合は、ユーザー自分自身でルート権限でGUIから取るしかないのでまだ安全。ルスラン 川口証明書をさらりと普通のフォルダに置いているケースがありそうで怖いですね。 大企業の場合はどこかに集めてそれを配布するんですけど、全部バックアップ用に証明書が置いてあるとか。ルスラン 質疑応答 質問１：あるシステムに侵入しようとして、SELinux ON の場合に侵入失敗・断念する場合はどのくらいありますか？ 我々がやってる侵入の中では、Linuxにエクスプロイトを使って侵入するというケースはかなり少ない。基本的に運用や設計の問題で何かしてしまおうということが多くて、Linuxへアクセスするなら普通にSSHで一般社員がやるような形でかつバレない形にします。外部の場合は、例えばあるサービスが脆弱でそれを利用するということはないことはないけど、かなり少ないのかなと思います。ルスラン 川口SELinux自体を使いこなすことも難しいし、製品によってはSELinux OFFで使えということも書いてあるので、ONで使っている環境が圧倒的に少ないですね。きっちりできればいいけど、それでも日常のオペレーションで開発者、運用者と同じオペレーションでこられると、SELinuxが評価されてますね。 例えばリバースシェルがとれて、そこから侵入しようとすると、SE Linuxはかなり邪魔になるけど、そもそも我々が得たいなにかしらの目的にはSE Linuxを突破する必要性はないことが多い。必要であれば頑張るしかないし、別に触らなくてもいいという時もあります。ルスラン 川口だいだい、パスワードのExcelファイルが取れてたりするとそのまま入っていくよねということになるので、SE Linux以前の問題ですね。 我々の目的が何でもかんでも侵入していくのではなく、会社の資産、クレジットカード情報、個人情報だったりソースコードだったり、これを入手するということなので、経路は何でもいいということもあるんですね。ムリにそこを通らなくてもいいと。ルスラン 質問２：「9割侵入できる」ということですが、実際にそこからデータ窃取できる割合はどの程度なのでしょうか？ 大体同じ割合です。ただ、ゴールが何になるかで変わったりする。ドメイン管理者を取ることがゴールでそこで終わるケースもあるし、守りたい資産、データへ入れるかどうかというケースもある。侵入はどちらも成功しているので確かに9割以上になるけど、データの取得まで頼まれたところで、できなかったことはほぼない、といえます。ルスラン 川口データの取得がゴールの場合、できなかったことはないのはすごいいい答えです。方法は無限にあるからというのと一緒で、分かる気がするんですよ。いろんな企業にお会いすると、ルスランさんにやられることを期待する企業の方が時々いるんですけど、ほんとにみんな取られたいんだなという。 簡単に言うと、時間と予算の問題もあるので、我々が例えばスコープとしてフィッシングも入れますか、内部フィッシングを入れますかとか内部IRを突破しながらやりますかとか、IRに捕まったらどうしますかとか、無限の質問があるんですけど、IRに捕まったら無意味みたいなシステムの脆弱性だけを見るんだったら短縮の時間でいろいろやってできましたということを見せればいいし、IRが強いとかいう会社ならば、じゃあIRのままでやってみましょう、捕まることは可能か不可能かというところを見てみましょうというケースもある。ルスラン 川口ここでIRというのは、SOCのチームがいますよとか、CSIRTとの連携ができてますとか、それも含めてのIR？ はい。例えば社内のSOCがあるとか、誰かレスポンスできるような守り側のチーム、セキュリティチームみたいな人たちがいるとか、アウトソーシングしている、委託のSOCがいるとか、いろいろあったりする。ルスラン 牧田ペンテストの目的がセキュリティを試すことというお客様もいますし、ブルーチームとか、IR、セキュリティチームがちゃんと運用できているか確認したいお客様もいます。ノイズが多いじゃないですか、誤検知とか、アラート来たけど違ったとか、そんな時に1回本物のやつを入れてみる。本物のやつが来た時に、24時間以内に検知して対策できるかどうか、そういう目的でやられるお客様もいらっしゃる。 質問３：多要素認証のあるWebサイトの認証を通すのが毎回面倒です。ユーザビリティを落とさないセキュリティ強化はありませんか？ 川口確かに、毎回多要素認証求めてくるなよ、というのはやる側もすごく思うところ。このブラウザを覚えて欲しい、とすごく思うけど、多要素認証が全部入れば言うことないということだけど、それはなかなか社内で浸透させにくいし、開発者に関しても開発効率が落ちるから何とかしてくれと言われそうだけど、お客様との会話や報告会でどういうアドバイスをされるんですか？ セキュリティ＝ユーザビリティではないからですね、残念ながら。ルスラン 牧田攻撃者目線を知ると、ちょっと我慢できるようになるかもしれませんね。例えば、パスワードの話に戻るけど、IDとパスワードだけの認証の場合、いろいろなサービスから漏れたパスワードをそのまま使っている方々もいっぱいいるし、それをちょっと1文字変えてとかでできることもあるし、Active Directoryのドメインコントローラに侵入できて、ハッシュ値を取って、8桁だと何時間で解けるんでしたっけ？ ハッシュの種類によるけど、Windowsであれば我々のサーバーなら数時間。ルスラン 牧田むかし、パスワードを8桁にしようよ、6桁はだめよ、という話があったけど、8桁のパスワードで数時間。どうしてもパスワードは漏れる。Emotetのように、ブラウザに保存したパスワードはダンプできてしまうんですよね。全部保存をしていたパスワードとIDが漏れてしまう前提で考えると、やっぱり我慢しようかという風に思えるかもしれませんね。 川口ブラウザにパスワードを覚えさせるのは、非ITの人にはしょうがないという気がするけど、IT業界の人にはパスワードマネージャーを会社で導入してなんとかしたいという気もしますよね。 牧田ブラウザのパスワードをダンプする、そうすればパスワードマネージャーを使いましょうという。恐ろしいですよ、すべての履歴をとられてしまう。 パスワードマネージャーも端末で実行できるんであれば、ダメかなと。ものによって、例えばシステム権限で動いていたりするので、権限昇格をしない限りはまだマシであったりすることもあるんですけど、我々がやるときは権限昇格が必要だったら、必要に応じてゼロデイを探して出してやるというところもあったりする。時間が許す限りはやれるけど、テストの期間はそれほど長くないので、3日程度で見つけられるのなら探すんですけど、それ以上かかるものは期間内には触らない。ルスラン 川口ペンテスターがゼロデイを見つけてくるとさらりと言うのは衝撃的だと思う。 牧田次回の話題にしたいんですけど、セキュリティ製品って権限が高いじゃないですか、セキュリティ製品にゼロデイがあるととんでもないことになる。我々一般の人はセキュリティ製品を信じるけど、ペンテスターは、2～3日で見つけられるのならゼロデイ見つけておこうか、そんな感じ。 あとは多要素認証について追加で言うと、各サイトに与える認証とかがあると便利だけど、SSOはあるにしてもその中で多要素認証みたいなものを実現できるのであればいいと思ったりして、例えばAzureのIdPを使って、いろんなアプリケーションにテストするけど、それはそれでよいけど、ただし、何を追加して欲しいかというと、例えば一部のアプリを絶対に守らなければいけない、例えばAWSの管理コンソールとかAzureの管理コンソールとかがあったりしたら、そこだけに例えばFIDOの確認を追加する、SSOされるときにはそこにアクセスする瞬間、多要素認証を聞かれる、多要素認証もできる限りFIDOにする、というのを個人的におすすめだと思う。ルスラン さいごに ご視聴・ご参加いただき、ありがとうございました。参加いただいた方からは参考になりました、興味深かった、またやってほしいですなど、温かいコメントをたくさんいただき、大変嬉しく思っております。重ねて御礼申し上げます。 映像はアーカイブ公開しておりますので、以下より是非ご視聴ください。 https://youtu.be/TzBleQoIENg

こんにちは。GMOインターネット セキュリティエンジニアの関です。今回はクロスサイトスクリプティングの手法の一つ、DOM based XSSの検査の手法について、PortSwiggerが公開しているWeb Security Academyのテストページを使って解説していきます。※Web Security Academyはアカウント登録をすれば誰でも無料で使えます。 1.　注意事項 検査により、意図せずにシステムの停止や不具合を引き起こしてしまう可能性があるため、紹介する手順を試してみたい場合は本番に影響を及ぼさない検証環境か、それ専用に作られたテストサイトでの作業をお勧めします。自組織が管理しないWebアプリケーションへの検査は、場合によっては不正アクセスとして違法となる可能性があります。 2.　クロスサイトスクリプティングとは クロスサイトスクリプティングとは、リクエストヘッダやパラメータに含まれる情報を画面に出力する処理にエスケープ不備があり、第三者（攻撃者）が用意した悪意あるスクリプトが埋め込まれた結果、意図しない処理を実行されてしまう脆弱性です。 想定される被害として、偽ページの表示や認証情報の奪取があります。 クロスサイトスクリプティングには以下3つの分類があります。 反射型XSS蓄積型XSSDOM based XSS 上記のうち、DOM based XSSはJavaScriptから動的にHTMLを操作するアプリケーションにおいて動作します。正規のスクリプトの動きを悪用し、不正なスクリプトを実行させることが特徴です。 自動の脆弱性診断などでよくあるパターンでは、対象のWebサーバに対して検査コードを含むリクエストを発行し、そのレスポンスの内容によって脆弱性が存在するかを調べますが、DOM-based XSSではクライアント上でJavaScriptが動作するまではXSSが発生しません。そのため、ツールによっては検知が難しく、手動で検証が必要な脆弱性となります。 3.　検出パターン / 例 今回は「BurpSuite」というローカルプロキシツールを使って検査していきます。セットアップや基本的な使い方について解説している記事などは検索すれば多数ヒットしますので、ここでは解説の対象外とします。※BurpSuite自体は無料でダウンロードできます。 まず、検査の際には以下文字列がレスポンス内にあることをトリガーとします。（ツールによっては下記の文字列がヒットすればDOM based XSSの可能性ありとして検出されるものもあります。） innerHTMLdocument.writejavascriptlocation.hrefevalsetTimeoutsetIntervalFunctionjQuery　他 検査文字列は以下の通りです。 javascript:alert(1)"><svg onload=alert(1)><script>alert(1)</script>　他 ※なお、トリガーとなる文字列や検査文字列は一例となります。 4.　検査手順詳細 ①　検査したい目的の画面まで遷移します。 ②　今回は検索処理なので、適当な文字列を挿入し検索を実行します。　　（SOCtestと検索してみました。） →左側の検索結果画面には、「0 search results for 'SOCtest'」と表示されています。 ③　Burp上で実際のレスポンスrawデータを確認してみます。 →対象のレスポンス内で「SOCtest」と検索してみると、0 matchesとなっています。 ④　レスポンスrawデータの中で、検索結果表示に該当する箇所を探してみます。　　今回は下記のように定義されていました。 ⑤　呼び出されているsearchMessageをもう一段掘り下げて確認してみると、scriptでこのように記載されています。 →innerHTMLとあるため、DOM-based XSSが発生する可能性があります。（トリガーパターン参照） ⑥　XSSの検査コードを挿入してみます。「"><svg onload=alert(1)>」（検査文字列パターン参照） →javascriptのポップアップが表示されたことが分かります。 ⑦　ここで改めて、レスポンスrawデータを確認してみますが、　　"><svg onload=alert(1)>は出力されていないため、ツールによっては自動検知が困難となります。 5.　おわりに 今回は、DOM based XSSの検出方法について紹介してきました。攻撃の特性上、ツールでは検出しにくいという点は説明した通りですが、そのほかにもWAFやブラウザのXSSフィルタでもブロックしにくい厄介な脆弱性です。 まずはこういった攻撃手法があることを認識することが第一歩だと思います。 具体的な対策手法や、もっと深堀して検査したい！という方は、調べてみるとチートシートやより詳細に解説している記事がありますので是非ご参照ください。

こんにちは、GMOインターネットの國分です。今回は2021年11月17日~20日、27日に実施されたHardeningイベントについて、魅力をお伝えできたらと思います。 はじめに Hardeningとはコンピューティングシステムのセキュリティを強化、堅牢化することの総称として使われ、今回参加のHardening　2021 Active faultでは仮想Webショップを経営側、インフラ側両方をロールプレイを行いながら、堅牢化を疑似体験するイベントが行われました。 実際のWebショップを触って作業するのは開催5日間のうち1日のみで、他日程についてどんなプログラムが展開されたのかなどをレポートいたします。 【参考サイト】https://wasforum.jp/hardening-project/ チームビルディング Hardeningイベントはチーム戦です。応募した人の中から運営側が6人～8人のチーム編成で割り振られます。約1か月前にチーム確定についてのメールが届き、ミッションが開始されました。 チームにもよりますが、大体イベント開催までの1カ月間で週1回～2回のミーティングを実施して、様々なミッションやイベントに向けた事前準備を行います。 TODO チームリーダー、福リーダーの選定チーム名の決定チームフラッグの作成（Zoom背景やロゴマーク）前回資料からの対策案策定経験者からの事前共有会稟議の書き方の勉強スキルマップの作成担当業務の割り振りマーケットプレイス購入品と落札額の決定インシデント対応フローの作成事前シミュレーション 比較的簡単なことから、時間がかかりそうなことまで事前に準備しなければならないものは、多岐にわたりとても1人ではやりきれないタスク量でした。 今回はオンライン開催だったこともあり、学生から社会人までの幅広い年齢層、かつ外国からも参加されている方もいらっしゃいました。そのため、チーム全員がMTGできる時間帯を合わせてミッションを行うのはとても大変でした。 欠席者が出た場合のフォロー、MTGの際の発言しやすい雰囲気づくり、このあたりがチームの一体感を生むために必要になってきたように感じます。 マーケットプレイスの活用 イベントの2日前には、マーケットプレイスの説明がありました。マーケットプレイスでは、オークション形式でセキュリティ製品を購入することができます。各ベンダーの皆さんがセキュリティ製品のプレゼンを行い、どのセキュリティ製品を獲得して、イベント当日に挑むかの参考になりました。 ※一部このプレゼンの前に提供される製品もありました。また、公式のマーケットプレイスには存在しない、ランサムウェア復旧サービスもありました。 FireWallWebAplicationFireWall(WAF)エンドポイントセキュリティセキュリティ情報サービスJPCERT/CC 前日準備 前日になるとサーバー構成図、ネットワーク図、ミッション、ルール等の情報が記載された資料が配られます。この日になって、やっとどんなOSやどんなサーバー構成なのかが判明するので、担当サーバーを決めたり、初動対応に必要な資料作成に入ります。 今回は前回参加者から事前に「こんなFirewallじゃない？」との共有をうけ、事前学習していたのですが、実際は予想のFireWallとは別のものが登場し急遽その対応方法を調査して、ルール投入方法とバックアップ方法を調査したり。また、接続に関しても特定のソフトウェアで接続テストしていたが別のソフトウェアに変更になったりと色々想定と違っていました。 前日にバタバタとせわしなく、多くの対応に追われながらイベント準備を進めていきました。 イベント当日 イベント当日の9時にはチーム全員がZoomに集合し、全員いることが確認されたチームから競技環境に入り、Hardeningが始まります。 サーバー担当 パスワードの変更各種バックアップ不審なファイルの調査、隔離、削除不審なプログラムの調査、停止FireWallの設定セキュリティ製品ベンダー対応インシデント調査、対応 Web担当 マーケットプレイスで購入した商品の稟議処理購買処理Webショップの修正在庫管理発送業務メール対応広報対応 イベント当日のランキングはYoutubeライブで配信されていますが、対応に追われなかなか見れない。 サーバーは24台、WebShopは4種類あり、7人のチームでしたが基本いつも人が足りない状態でした。それぞれのタスクを各人員が行っている中、Webショップは攻撃され、Webショップが止まったり、Webショップのページが改ざんされたりのインシデントが発生し、その対応を行うなか、「Web担当はインシデントの説明」、「サーバー担当は証跡の作成」を求められるので競技時間で与えられた8時間はあっという間に過ぎていきました。 Softening Day Softening Dayでは、Hardening当日に実施した内容発表する場と、攻撃側の種明かしの日になります。今回はオンラインとオフライン混合で行われ、発表の際に変身する人がいたり、独唱する人が居たりと、予想の上を行くおもしろい発表会でした。 各チームの対応を聞くことで自分たちに何が足りなかったのかも分かる場となっているので、自分たちが気が付かなかったり、見つけられなかったインシデントの内容が聴けるので、どのチームの発表も参考になります。 参加証明書も貰えます。※名前付きのものも別途貰えます。 さいごに 止めてはダメなWebShop、どうして増えないサブスクリプションの人数、IP直で来ないでよ攻撃者等々、イベント当日は色々ありましたが、振り返るとあっというまに時が過ぎていき、各人それぞれ何が足りないかを認識できる特別な時間になりました。インシデントの経験がない人は経験が積め、経験がある人はあの時できなかった対応が今回出来るぞと意気込めるそんなイベントです。セキュリティに興味がある人は経営側、システム側両方の対応が体験できるこのイベントは、どんなセキュリティ参考書よりも記憶に残り、これからの糧になるイベントだと思います。ちょっとでも興味を持ってくれたら、ぜひ参加して爪痕を残してくれればと思います。

こんにちは、新里です。ここでは人気があるCMSであるWordPressを実際にサーバー上に立てて、セキュリティスキャン・対策などを簡単に紹介します。 環境 まずは適当にサーバーを用意してWordPressを動作させます。環境は以下の通りです。 Ubuntu : 20.04WordPress ：5.8.1(MariaDB) sudo apt install mariadb-client mariadb-server apache2 php php-mysql certbot python3-certbot-apache cd /var/www/html wget https://ja.wordpress.org/latest-ja.tar.gz tar -zxvf latest-ja.tar.gz 各種インストールしてDBの作成・WordPressのセットアップを行った後、サイトを見てみると、デフォルトの投稿があります。とりあえずWordPressをサクッと動かすことができました。テスト投稿はあっても無くても良いので、WordPressにログインしてテスト投稿を消してまっさらな状態にしておきます。 wpscanで確認する デフォルトで立ち上げたWordPressのセキュリティスキャンを行ってみます。ここではよく利用されるwpscanを利用して行ってみます。ドメインは便宜上hogehogeとしています。 # dockerで実行 docker run -it --rm wpscanteam/wpscan --url https://hogehoge --enumerate u _______________________________________________________________ __ _______ _____ \ \ / / __ \ / ____| \ \ /\ / /| |__) | (___ ___ __ _ _ __ ® \ \/ \/ / | ___/ \___ \ / __|/ _` | '_ \ \ /\ / | | ____) | (__| (_| | | | | \/ \/ |_| |_____/ \___|\__,_|_| |_| WordPress Security Scanner by the WPScan Team Version 3.8.19 Sponsored by Automattic - https://automattic.com/ @_WPScan_, @ethicalhack3r, @erwan_lr, @firefart _______________________________________________________________ [+] URL: https://hogehoge/ [xxx.xxx.xxx.xxx] [+] Started: Wed Oct 20 08:38:53 2021 Interesting Finding(s): [+] Headers | Interesting Entry: Server: Apache/2.4.41 | Found By: Headers (Passive Detection) | Confidence: 100% [+] XML-RPC seems to be enabled: https://hogehoge/xmlrpc.php | Found By: Direct Access (Aggressive Detection) | Confidence: 100% | References: | - http://codex.wordpress.org/XML-RPC_Pingback_API | - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_ghost_scanner/ | - https://www.rapid7.com/db/modules/auxiliary/dos/http/wordpress_xmlrpc_dos/ | - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_xmlrpc_login/ | - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_pingback_access/ [+] WordPress readme found: https://hogehoge/readme.html | Found By: Direct Access (Aggressive Detection) | Confidence: 100% [+] Upload directory has listing enabled: https://hogehoge/wp-content/uploads/ | Found By: Direct Access (Aggressive Detection) | Confidence: 100% [+] The external WP-Cron seems to be enabled: https://hogehoge/wp-cron.php | Found By: Direct Access (Aggressive Detection) | Confidence: 60% | References: | - https://www.iplocation.net/defend-wordpress-from-ddos | - https://github.com/wpscanteam/wpscan/issues/1299 [+] WordPress version 5.8.1 identified (Latest, released on 2021-09-09). | Found By: Rss Generator (Passive Detection) | - https://hogehoge/index.php/feed/, <generator>https://wordpress.org/?v=5.8.1</generator> | - https://hogehoge/index.php/comments/feed/, <generator>https://wordpress.org/?v=5.8.1</generator> [+] WordPress theme in use: twentytwentyone | Location: https://hogehoge/wp-content/themes/twentytwentyone/ | Latest Version: 1.4 (up to date) | Last Updated: 2021-07-22T00:00:00.000Z | Readme: https://hogehoge/wp-content/themes/twentytwentyone/readme.txt | Style URL: https://hogehoge/wp-content/themes/twentytwentyone/style.css?ver=1.4 | Style Name: Twenty Twenty-One | Style URI: https://wordpress.org/themes/twentytwentyone/ | Description: Twenty Twenty-One is a blank canvas for your ideas and it makes the block editor your best brush. Wi... | Author: the WordPress team | Author URI: https://wordpress.org/ | | Found By: Css Style In Homepage (Passive Detection) | | Version: 1.4 (80% confidence) | Found By: Style (Passive Detection) | - https://hogehoge/wp-content/themes/twentytwentyone/style.css?ver=1.4, Match: 'Version: 1.4' [+] Enumerating Users (via Passive and Aggressive Methods) Brute Forcing Author IDs - Time: 00:00:00 <=================================================================================================================> (10 / 10) 100.00% Time: 00:00:00 [i] User(s) Identified: [+] admin | Found By: Wp Json Api (Aggressive Detection) | - https://hogehoge/index.php/wp-json/wp/v2/users/?per_page=100&page=1 | Confirmed By: Author Id Brute Forcing - Author Pattern (Aggressive Detection) [!] No WPScan API Token given, as a result vulnerability data has not been output. [!] You can get a free API token with 25 daily requests by registering at https://wpscan.com/register [+] Finished: Wed Oct 20 08:38:57 2021 [+] Requests Done: 53 [+] Cached Requests: 7 [+] Data Sent: 14.086 KB [+] Data Received: 403.391 KB [+] Memory used: 199.523 MB [+] Elapsed time: 00:00:03 適当にadminユーザーを作成した、"admin"が判明していますね。これは投稿してあるWordPressのREST API（wp-json）からユーザ一覧を取得することができています。他にもApacheのバージョン、WordPressのバージョン、利用しているプラグインなど一通り出てきました。バージョンが判明すると、対象となるバージョンの脆弱性から攻撃を受けてしまうので、あまり良い気がしません。以下、簡単に対策を行います。 HTTPヘッダからバージョンを消す HTTP headerServer: Apache/2.4.41 まずはこの部分を見せないようにします。 # /etc/apache2/conf-enabled/security.conf ServerTokens Prod # /etc/php/7.4/apache2/php.ini expose_php = Off readme.htmlを削除する デフォルトではWordPressをインストールしたディレクトリに"readme.html"があります。ログイン画面へのURLへの記載があったりするので削除しておきます。 Indexesを無効にする 何もしないと/wp-contents/uploads/配下にアクセスするとファイル一覧が見れてしまいます。これはちょっと良くないですね。 そこで、Apacheもしくは.htaccessの設定で以下を設定しておきます。 Options -Indexes ログイン画面 何もしないとWordPressの管理画面に直接アクセスすることができます。先にユーザー名が判明しているので、ユーザー名を使った辞書攻撃や、パスワード再発行から当該ユーザーに対してパスワード変更通知メールを送信することができたりもします。 そこで管理者画面にアクセスする時は、何個か対策を用意しておきます。これらは利用しているWordPressの環境に合わせて行います。 セキュリティのプラグインを入れて画像認証（CAPTCHA）BASIC認証を使う特定のIP以外からのアクセスはブロック セキュリティプラグインを使う ここではSiteGuardというWordPress向けのプラグインを利用します。SiteGuardを使うとログイン画面の制御の他に、wpscanで指摘されたREST APIを無効にしてユーザー名の取得を防ぐことが出来ます。WordPressのプラグインからSiteGuardを指定してインストールして、ログインページの設定を行います。 とりあえずデフォルトの設定にして変更を保存しておきます。そして管理画面にアクセスするとCAPTCHAの指定が出てきます。他にも一定回数のログイン試行で失敗するとロックする仕組みや、ログインURL（wp-login.php）を変える機能など、機能が充実してます。WordPressのプラグインを使って、簡単にセキュアにする時は良いでしょう。 他にも管理画面にBASIC認証をかけたり、特定のIPからのみアクセス可能にする(例えば社内のみからアクセス可能)といった設定をすることで、不意のログインやアクセス対策をすることが出来るでしょう。 おまけ SiteGuardには前述したREST APIを無効化する機能があります。WordPressはREST APIで様々な情報にアクセスできます。ユーザー名・記事・アップロードしているファイルなどです。これらの情報にアクセス出来るため、意図しないファイルアップロードがアクセスされる可能性があります。実際に行って見てみましょう。 適当にExcelファイルを用意する。WordPressにファイルをアップロードする 手順1：適当にExcelファイルを用意する ここではサンプルとして適当なExcelファイルを用意します。PDFや画像ファイルなどでも構いません。 手順2：WordPressにファイルをアップロードする 　用意したファイルをWordPressにアップロードします。 ここではファイル(private_items.xlsx)をWordPressにアップロードしただけで、まだ記事は何も公開されていない状態です。 公開した記事が無い状態でファイルをアップロードしただけなら、そのファイルは見られないと通常は思うはずです。しかし、アップロードしたファイルは実はすでに見える状態になっています。ここでWordPressにログインしていないユーザーでREST APIをブラウザから叩いて見てみましょう。URLは"サイト名/wp-json/wp/v2/media"などでアクセス可能です。 先程アップロードしたファイルが見えてきました。ここで実際にこのファイルのURL（https://wp〜/wp-content/uploads/2021/11/private_items.xlsx）にアクセスすると、先程アップロードしたファイルを実際に見ることが出来ます。誤ってアップロードしたファイルや不意にアップロードしたファイルなど、REST APIを利用することで、公開・非公開に関わらず、記事で使ってなくてもファイルのURLを特定して見ることが出来ます。 このようなREST APIの利用はSiteGuardの"REST API無効化"で防ぐことが出来ます。この機能を有効にすると、先程のWordPressのREST APIのURLを見にいってもアクセスすることが出来なくなります。またREST API経由でのユーザーIDの取得についても防止できるというメリットがあります。WordPressは非常に手軽に利用できて、豊富なプラグイン・テンプレートがあるので誰でも簡単に利用できます。ただ、便利で簡単に使える反面、セキュリティにも一定の配慮をした方が良いでしょう。

こんにちは！GMOインターネットでシステムの運用保守を担当している桑原です。今回はSplunkでファームウェアのバージョンを管理する方法(今回は概略)とそのメリットについて紹介させていただきます。 課題 唐突ですがみなさん、システムのファームウェアバージョンをどのように管理しているでしょうか？メーカーのコマンドで取得して管理、メーカーの統合監視ツールで管理、ソースコードはGitで管理しているけど、ファームウェアは・・・様々な回答があると思います。私が担当しているシステムの範囲においては、これまでコマンドで管理していましたが、以下のような課題がありました。 メーカーによって出力フォーマットが異なり視覚的に見づらい欲しいデータだけをフィルタリング、レポーティングしたい（もちろん作りこめば可能ですが） 今回は上記の課題をSplunkで解決してみようと思います。 そもそもSplunkとは？ あらゆるデータをもとに適切なインサイトとアクションを導き出すソフトウェアです。Splunk社より提供されています。 https://www.splunk.com/ja_jp Splunkでファームウェアのバージョンを管理できるのか？ データとしてバージョンを取得できるのであれば、それをSplunkに取り込みます。あとは管理しやすいようにダッシュボードを作成するだけです。完成イメージをご紹介します。 赤四角で囲った部分がフィルタになります。複数のサービスやリージョンをここで絞ることで、出力結果を限定することができます。 特定のファームウェアバージョンのリストだけを抽出したい場合は、ファームウェアバージョンのフィルタを作ると良いでしょう。青で囲った部分が出力結果になります。※都合上モザイクをかけております。 図のように何もフィルタリングしていない場合は、Splunkに取り込んでいる全ての機器のファームウェアバージョンが出力されます。 Splunkで管理するメリット 1. フィルタリングで知りたい情報だけを瞬時に kernelやアプリケーションに脆弱性があるように機器のファームウェアにも脆弱性があります。 システム運用管理者にとって脆弱性対処すべきかの判断は悩ましいポイントですよね。ただ、その前に脆弱性のバージョンが管理する機器に存在するかを調べる必要があります。 数千台もある機器を一個ずつログインしてバージョン調べていたら、その間に脆弱性を突かれる、なんて悲しいことになるかもしれません。そんなケースで効果を発揮するのがSplunkのフィルタリング機能です。 例えば下図のようにフィルタに特定のバージョンを指定するだけで、瞬時に該当機器を抽出することができます。人間が頭を使うべき判断や、対処のスケジューリングに時間を使うことができることが、1つのメリットに上げられます。 2. レポートが容易に システム運用管理者であれば、上司やお客様にレポートを提出する機会があると思います。都度、集計してグラフを作るのは台数に比例して時間がかかります。 例えばバージョンの割合や台数をレポートするために円グラフを使いたいケースがあるとします。Splunkを利用すれば、先ほどのリスト抽出と同時にグラフ作成することも可能です(下図)。 もちろん円グラフだけでなく、用途に応じて他のグラフも利用できます。 このように、日々のレポート作成が容易になるのが2つ目のメリットになります。 まとめ Splunkでもファームウェアのバージョンを管理できます。Splunkで管理すれば、フィルタリングにより特定バージョンの抽出や日々のレポーティングが容易になります。 もちろんファームウェアだけに限りません。Kernelや各種ソフトウェアのバージョンもSplunkに取り込めば管理可能です。 バージョン管理で頭を悩ませているシステム運用管理者の方々、今回の紹介が少しでも参考になれば幸いです。

こんにちは！GMOインターネットの濱本です。今回は社内向けに実施しました「社内ハードニング」についてご紹介します。 はじめに ハードニングとは まず、ハードニングとは何ぞや？というところからお話したいと思います。ハードニング（Hardening）とは単純な英単語としては「硬化」などの意味を持ちますが、ここで言うハードニングとは「システムに対するセキュリティの堅牢」のことを指します。 日本では、WASForumによって「Hardening Project」というセキュリティ堅牢化の競技会が毎年実施されており、私も過去に何度か参加させていただきました。セキュリティの堅牢化に興味のある方は、ぜひとも以下「Hardening Project」に関してもご参照いただけると幸いです。 【参考サイト】https://wasforum.jp/hardening-project/ 　上記、本家ハードニングイベントに実際に参加したことで、セキュリティの堅牢化に関してより多くのエンジニアの方々に重要性を伝えるべきだと感じ、今回社内イベントとしてハードニングを実施することを決意致しました。 実施の目的 さて、そんな「社内ハードニング」についてですが、やはり実施するからには「目的」が重要です。今回、どんな目的で実施したのかを以下に記載いたします。 当事者意識 まず最初にイベントを実施するうえで、参加した方々に感じて欲しかったこととしては「当事者意識」です。起きてほしくないことですが、情報漏洩などのインシデントが長時間発生しないと、徐々にではありますが「自分たちの環境では起きないだろう」「そんなに堅牢化しなくても大丈夫だろう」と気持ちが緩みます。 そこで、競技用の環境ではありますが、「え？！内部に侵入されている？！なぜ？！」「あれ？！システムが止まっている！」という感じでインシデントを体験していただくことで、「自分たちが構築してきた環境は大丈夫なのか？！」という「当事者意識」を持っていただきたかったのです。 コミュニケーションの活性化 続いては「コミュニケーション」の活性化です。コロナ禍の中、リモートワークにて業務を行ってきましたが、長時間も続けていくと徐々にではありますがメンバー間によるコミュニケーションが減っていきます。 特に同じチーム内でのコミュニケーションだけではなく、業務上関係が少ない他チームとは今まで以上にコミュニケーションを取る機会が減ってしまい、いざというときの連携にも影響が及ぶと考えました。 このため、競技を実施していくうえでは可能な限り普段関わらないようなチームの方々とメンバーを組み、チーム間の垣根を越えたコミュニケーションの活性化を目指しました。 実施のエピソード では、実際に「社内ハードニング」を実施していくうえでいくつかのエピソードを交えながらどのように進めていったのかをお話いたします。 競技環境について さて、「社内ハードニング」を実施しよう！と言っても、残念ながら現在の私たちにはイベントに使えるような競技形式の環境というのは持っていませんでした。 そこで、本家「Hardening Project」にも協力されている「株式会社 川口設計」の川口さんに相談を行い、川口さんが普段外部で使用されている「Micro Hardening」というイベント用の競技環境をGMOのために貸していただけないか相談しました。結果、快諾していただき無事イベントに必要な競技環境を用意することができました。 https://www.sec-k.co.jp/mh チーム構成の検討 続いて重要だったのは、目的の一つでもある「コミュニケーションの活性化」のためのチーム構成でした。イベントおよび競技とはいえ、実際にインシデント対応を行っていただくためチーム間のスキルや能力が偏らないように意識しながらも、なるべく同じチームの人が一緒にならないように注力しました。 そのため今回はスキルや能力の偏りを無くすため、参加者全員にフォーマットを統一したスキルマップの入力をお願いし、提出していただいた内容を私を含む事務局側で本来の業務や関係性を考慮しながら、なるべくバラバラになるように意識しながら4名×5つのチーム割としました。 急遽2日間構成に変更 さて、競技環境も用意できチーム割も順調に進んでいる中、社内から以下のような声が出てきました。 「イベントを1日(8時間)ではなく、2日間(4時間×2日)に分けてくれないか」と・・・ 最初、上記内容を聞いた時は正直焦りましたが、実際に2日間に分けて実施してみたところ、この2日間にイベントを分けるというのが私たち事務局側の想定を超えた形で「コミュニケーションの活性化」へと繋がることとなるとは、この時点では想像もしていませんでした。 結果、イベントに関しては以下のような形で2日間に分けて実施をすることになりました。 イベントは2日間(4時間×2日)1セットあたり45分間1セットごとに競技環境がリセットされる各セット(45分間)で攻撃される内容はすべて同じ1日目に2セット分を実施し、2日目に再度2セット実施することで合計4セット実施する2日目の最終4セット目で最も点数の高いチームが優勝4名×5チーム（A、B、C、D、Eとチームごとにアルファベットを振りました） 当日 そして、イベントの日程調整などもありましたが当日使う資料などの準備も間に合い、8月初旬に無事イベントを実施することができました。 1日目 まずは参加していただいた方々に競技環境や目的を説明したのち、実際に使用する競技環境への接続などをテストしていただきました。そこで第一の問題が発生！なんとチームEのリーダーの方が急遽、業務都合上イベントを一時的に抜けることになったのです。チームEだけ3名で競技するのは不公平にもなると考え、急遽ではありますが私と一緒にイベントの運営をしてくれているエンジニアをチームEに参加させました。 これで問題は解決…と思いきや次の問題が発生！チームAがファイアーウォールの設定を誤ってしまい競技環境に接続できなくなってしまったのです。私を含む運営側でフォローするも競技環境には再接続ができないため、やむなく緊急用に用意していた環境をチームAに渡すことで乗り切りました。 バックアップや臨時対応の重要性を運営側としても改めて実感した1日目でした。そして、1日目の各チームのスコアは以下の通り。 1セット目は各チームまずは環境の確認などを実施していたようでスコアとしてはほとんど差がありません。しかし2セット目からは、各チームで攻撃に対する対策などを実施した結果、若干ではありますがチームDが抜け出る結果となりました。 さて、2セット目が終わったためイベント初日は無事終了と運営側は考えていたのですが、ここでイベントを2日間に分けたことによる予想外な出来事が起こります。なんと！各チームでイベントの振り返りMTGが開催され、翌日の3セット目、4セット目に向けた対策の話し合いが行われたのです。 のちほどイベント後のアンケート結果も公開致しますが、この1日目と2日目の間の各チームの作戦会議が「コミュニケーションの活性化」に大きく関わってきていると運営側は感じています。 2日目 前日は夜遅くまで各チームで対策MTGなどが行われたのち、2日目の開催です。 1日目にチームEのリーダーの方が抜けてしまいましたが2日目は最初から無事参戦することができました。 上記が3セット目のスコアとなっていますが、1日目とは打って変わってせめぎあっています。前日に対策を考えてきた効果が表れたチームもあれば、対策を強化しすぎた結果スコアが伸びないチームも。 次が最後の4セット目。この4セット目で最も高いスコアを出したチームが優勝となりますが結果は・・・・ 優勝したのはチームEでした！ 途中まではチームDが1歩抜けていましたが、チームDが終盤伸び悩んでいたところをチームEが抜き去るという結果になりました。なお、チームCに関してはスコアを上げるために必要な機能を対策の一環で停止させてしまっており、それに気が付かないまま最後を迎えてしまいました。 アンケート結果 イベントの日程変更や、イベント初日のバタバタもありましたがイベントは無事終了。 あとは実際に参加していただいた方々にアンケートを行い、本来の「目的」を達成できたかどうか・・・ 上記がアンケート結果の抜粋となりますが、参加してくれた多くの方が今回の社内ハードニングに「満足」してくれたようです。またそれぞれのアンケート結果を見る限りでは、「普段関わりのない方々とコミュニケーションが取れて良い体験でした」というコメントなどもあり、本イベントの「目的」に掲げていた「コミュニケーションの活性化」に関しては、成功だと感じました。 総括 以上が今回社内で実施いたしました「社内ハードニング」についてとなります。 「目的」のすべてに対して満足のいく結果にはなりませんでしたが、コロナ禍でコミュニケーションが希薄化している中で、本イベントを実施したことによる「コミュニケーションの活性化」に関しては大きく貢献することができたのではないかと感じています。 「当事者意識」に関しても、ゲーム感覚とはいえインシデントを経験していただくことで、参加者のみなさんはドキドキしたとお声をいただいていますので、ある一定の効果はあったのではないかと思います。 また、参加された多くの方々次回もあれば参加したいとアンケートで回答してくれていることからも準備などで大変ではありましたが、本イベントを実施して良かったなと思いました。 引き続き「コミュニケーションの活性化」のため同様のイベントを企画し、より多くの方々にセキュリティの堅牢化の重要性を説いていきたいと思います。

こんにちは。GMOインターネットでセキュリティ担当している割田です。今回は、セキュリティ対策でテストに分類される「ペネトレーションテスト（ペンテスト）」を実施するペンテスターのスキルを効果的にアップさせる方法についてご紹介します。 はじめに セキュリティ対策には、色々な段階のものがありますが、一般的に脆弱性の確認手段としては、『診断』と『テスト』があります。 診断網羅的に脆弱性の可能性を確認テスト実際の挙動で脆弱性有無を確認 また、それらテストの中に「ペネトレーションテスト」というものがあります。 「ペネトレーションテスト」とは、対象環境の構成要素を元に攻撃シナリオを作り、そのシナリオと専門知識を武器に、対象環境の様々な脆弱性を深く調査するテストです。 そして「ペネトレーションテスト」の技術者を『ペンテスター』と呼びます。 ペンテスターに関する基礎知識 ペンテスターとペネトレーションテスト環境 ペンテスターが、ペネトレーションテストを学習するためには、テスト環境の準備が必要です。 テスト環境の構成要素 ネットワークを含むインフラ環境アプリケーションデータベースなど ペンテスターへの道 ここからはペンテスターへの道として、スキルアップ方法の課題を記します。 スキルアップ方法一覧 『ペンテスター』のスキルを効果的に向上させるには、サービス環境と同等の環境整備が必要であり、それら環境が無いとシナリオ作成や攻撃方法の幅が少なく効果的な学習ができません。学習環境を利用する方法として大きく分けて下記の3つがあります。 自力構築競技参加外部サービス利用 具体的には以下を指します。 1自力構築ローカル環境やConoHaなどのVPS環境に　●1から構築　●外部提供のものを利用して構築2競技参加外部や内部で開催される競技へ参加する　●ハードニングプロジェクト　●CTF(Capture The Flag)等への競技参加3外部サービス利用環境提供している環境を利用する　●OSCP資格勉強用環境　●Hack The BOX環境 環境構築における課題 しかし、実際問題、自力で環境構築する事は、とても大変です。具体的に以下のようなことが考えられます。 テスト環境自作の難点 ●複合環境の準備　サービス環境と同様の複合環境（OSなど）を用意する必要がある●脆弱性の準備　検証練習をするための脆弱性を持つ環境を準備する必要がある●攻撃シナリオの考慮　効果的に学習できるように複数のシナリオを考える必要がある●難易度の考慮　利用者に合わせた難易度の環境が必要である●初心者への考慮　初心者でも検証方法を理解するための資料（WriteUP）が必要である オススメのスキルアップ方法 上記で記した課題の解決策として、今回私が個人的にオススメしたい方法は、『外部サービスのHack The Box環境を利用する方法』です。 ※Hack The Boxとは、セキュリティをゲーム形式で学習できるオンライン学習　のプラットフォームです。色々な脆弱性を含むサーバ環境が複数用意されてお　り、サーバ環境の管理者権限を取得する事で、点数を得る事が出来ます。 参照：https://www.hackthebox.eu/ オススメするポイントは多くありますが、4つに絞ってご紹介します。 1.いろいろな環境が用意されている 様々なOS（Linux/Windows等）多種多様な脆弱性色々な攻撃が体験できるシナリオが用意されている 2.難易度の範囲が広い 初心者用でも楽しめる環境がある経験者も楽しめる難易度の高い環境もある 3.困ったとき用のWriteUPがある 攻略方法のヒントが公式に記載された資料(WriteUP)がある※動画などが付いているものもあり初心者でもわかる内容になっている。 4.ゲーム要素もあり楽しめる 点数制度があり、ゲーム感覚でクリアを楽しめる簡単なものから難しいものまで幅広く環境があるサイト自体も遊び心がある作りになっていて楽しい ペンテスターがペネトレーションテストのスキルに集中して学習できる。また、初心者から熟練者までが、継続的に楽しみながらスキルアップ出来る良い環境だと個人的に感じています。 余談 実は、夏季休暇中の夜は『Hack the Box』に勤しんでいました。まだまだ遊び足りないので、ライフワーク的に続ける予定です。 弊社では、社内でのハードニングイベントも実施しますので、そちらの環境（内製）にも活かして行きたいと考えています。 おわりに 今回は、ペンテスターの効果的なスキルアップ方法として『Hack The BOX』をお勧めしましたが、興味もって頂けましたでしょうか。 セキュリティエンジニアの仕事は見えづらいものなので少しでも興味を持って頂けたら嬉しいです。

みなさま、こんにちは。GMOインターネット株式会社の斉藤です。前回の記事ではmoshというベンチなOSSツールと、VPSのポート制限のお話しが登場しました。このポート制限は、ConoHaのネットワーク機能に備わっているパケットフィルタを使って実現しています。今回はそれらを簡単に操作できるツールconoha-netをご紹介したいと思います。 ConoHaのパケットフィルタ機能 ConoHaには基盤側にパケットフィルタが備わっており、TCPポートやソースIPアドレスによるフィルタリングが行えます。仮想サーバーが接続されている仮想スイッチでフィルタリングされるので、OSやVPSの設定に依存しないのも特徴です。 なので簡易的なファイアーウォールのように使えますし、フィルタリングルールを「セキュリティグループ」という形でまとめて、複数サーバーにまとめて適用したりもできるので台数が増えたときの管理も楽です。 ただ、設定するにはConoHaのAPIを叩く必要があります。以下の記事が参考になります。 https://impov.hatenablog.com/entry/2016/05/30/210105 これからわかるとおり、複数のAPIを叩く必要があります。これは仕組みとして以下の3構造になっています。 仮想サーバーは複数のポート（=仮想NIC）を持つポートには複数のセキュリティグループを割り当てられるセキュリティグループには複数のセキュリティグループルールを割り当てられる 最初にお話ししたとおりConoHaのパケットフィルタは非常に柔軟な設定が可能です。ただ仮想サーバーや仮想ポートなどのレイヤーが多く、単純な設定をするにも多くのAPIを叩く必要があったりと少し煩雑な面もあります。 これらの手間を解決するためにconoha-netと言うツールを開発しました。開発はだいぶ前なのですが、私も業務で使いますし十分枯れていて使いやすいツールだと思います。 conoha-net conoha-netはセキュリティグループをコマンドラインから操作するツールです。インストール方法や使い方などはGitHubに書いてあります。 hironobu-s/conoha-net: A security group management tool for ConoHahttps://github.com/hironobu-s/conoha-net はじめに、以下を実行してみましょう。 list-group -a gncs-ipv4-sshのように末尾にが付いたものが見えます。 -all, -ssh, -web これらは実はコントロールパネルから設定できる「許可ポート」のことなんです。現状でコントロールパネルから設定可能なセキュリティグループが一覧で出ている状態なんですね。 hiro@personal$ conoha-net list-group -a UUID SecurityGroup Direction EtherType Proto IP Range Port 01c8f7d2-9a61-4158-bec9-882d9ea82c4e gncs-ipv4-ssh egress IPv4 ALL ALL a80a3376-5fff-41f1-b4de-6f975968e5a7 gncs-ipv4-ssh egress IPv6 ALL ALL ee75d97a-fe30-4974-944d-850da19356d9 gncs-ipv4-ssh ingress IPv4 tcp 22 - 22 0c905231-5ac8-4627-89d0-c8bb96b185f7 gncs-ipv6-all egress IPv6 ALL ALL 15962089-aaae-498f-86a9-7df572ce01fb gncs-ipv6-all ingress IPv6 ALL ALL f375fc43-bfab-48cc-a66d-418b6d709a60 gncs-ipv6-all egress IPv4 ALL ALL 1d1b7066-7da5-4694-9e8b-445b01d7df64 gncs-ipv4-all ingress IPv4 ALL ALL 771f3074-4fe8-4051-804e-6f5f7f4860b1 gncs-ipv4-all egress IPv6 ALL ALL b8d81897-4229-4ddf-8325-11a7d0b42efd gncs-ipv4-all egress IPv4 ALL ALL 448761e1-4943-453e-9edb-51d4bf81364c default egress IPv4 ALL ALL 4f505718-d378-4f24-991a-02d20b8285e4 default ingress IPv6 ALL ALL 66619594-8dea-4fc6-8815-5db7ef623930 default ingress IPv4 ALL ALL b950e586-53d5-4944-bdbd-fbba045c2d3d default egress IPv6 ALL ALL 12d97dca-94a2-4b99-938e-ff8be875d8a9 gncs-ipv4-web ingress IPv4 tcp 20 - 20 286a0a55-2c25-4810-9274-021d474126f6 gncs-ipv4-web ingress IPv4 tcp 443 - 443 85421073-7b49-41bf-9da1-d6e48b0f6c88 gncs-ipv4-web egress IPv4 ALL ALL ab501cfa-e67a-4255-9291-382400a45b2b gncs-ipv4-web ingress IPv4 tcp 21 - 21 b73d7eca-06b9-4252-ae9c-adad891dbb88 gncs-ipv4-web egress IPv6 ALL ALL daf58069-fd85-4281-a86e-3a8d23fd389b gncs-ipv4-web ingress IPv4 tcp 80 - 80 05bb817c-5179-4156-99ec-f088ff5c5d8e my-group egress IPv6 ALL ALL 5ecc4a23-0b92-4394-bca6-2466f08ef45e my-group egress IPv4 ALL ALL ↓コントロールパネル コントロールパネルからは特定のポート（22, 80, 443とか）しか設定できませんが、conoha-netを使うと自由に設定できますし、ソースIPアドレスの指定もできるようになります。たとえば、SSHへの接続を133.130.0.0/16からのみにしたい場合はこんな感じです。 hiro@personal$ conoha-net create-rule -d ingress -e IPv4 -p 22 -P tcp -i 133.130.0.0/16 my-group 5697eb75-3517-44a9-bc40-d532a4aedd89 hiro@personal$ conoha-net list-group UUID SecurityGroup Direction EtherType Proto IP Range Port 05bb817c-5179-4156-99ec-f088ff5c5d8e my-group egress IPv6 ALL ALL 5697eb75-3517-44a9-bc40-d532a4aedd89 my-group ingress IPv4 tcp 133.130.0.0/16 22 - 22 5ecc4a23-0b92-4394-bca6-2466f08ef45e my-group egress IPv4 ALL ALL JSON出力もできるので、スクリプトやプロビジョニングツールからも扱いやすいです。 hiro@personal$ conoha-net -o json list-group | jq . [ { "direction": "egress", "ether-type": "IPv6", "ip-range": "", "port": "ALL", "proto": "ALL", "security-group": "my-group", "uuid": "05bb817c-5179-4156-99ec-f088ff5c5d8e" }, { "direction": "ingress", "ether-type": "IPv4", "ip-range": "133.130.0.0/16", "port": { "max": 22, "min": 22 }, "proto": "tcp", "security-group": "my-group", "uuid": "5697eb75-3517-44a9-bc40-d532a4aedd89" }, { "direction": "egress", "ether-type": "IPv4", "ip-range": "", "port": "ALL", "proto": "ALL", "security-group": "my-group", "uuid": "5ecc4a23-0b92-4394-bca6-2466f08ef45e" } ] conoha-netを使うと、セキュリティグループの設定をより簡単に行えるはずです。良かったら使ってみて下さい。 それはまた次回お目にかかりましょう。