FJCT Tech blog

富士通クラウドテクノロジーズ公式エンジニアブログです

富士通クラウドテクノロジーズ

FJCT/Tech blog

FJCT エンジニアタスクフォース 2021 レポート

f:id:Con_Humi:20211223232507p:plain
ETFロゴ

皆さんこんにちは。FJCT エンジニアタスクフォース フォース長 の 北條 ( id:Con_Humi ) と申します。

この記事は 富士通クラウドテクノロジーズ Advent Calendar 2021 25日目の記事です。
昨日の記事は、 @u-koji さんによる、「 SSHを駆使して数々の試練(プロキシ、踏み台)を乗り越える話 」でした。

FJCTアドベントカレンダー2021 の最後の記事は、毎年恒例となった FJCT エンジニアタスクフォースの活動について紹介させていただきます。

エンジニアタスクフォース とは?

FJCT エンジニアタスクフォース (以下 ETF) は、 現場のエンジニアが中心 となり、日々の業務の中で生じる様々な課題に対して 全社横断 的に エンジニアの視点からの解決を試みる 、エンジニアの寄り合い的な組織です。

FJCT のエンジニアは事業部門の一員としてエンジニアリングを行っています。ETFは、そんなFJCTのエンジニアコミュニティの中で、「日々の業務の中で感じる課題を解決したいぞ」という モチベーションの高いメンバーが集まり 、非専従ではありますが社内委員会という形で組織されています。

FJCT エンジニアタスクフォースは、社内委員会である 親会 と、個別の施策(ex. 社内開発基盤運用, 新人技術研修)を行う 子会 によって構成されており、現在親会は 10 名程度、子会はそれぞれの施策ごとに ~10名 程度の規模で社内有志メンバーが集まって活動しています。

この記事では、2021 年に ETF が実施した具体的な活動内容を紹介します。
これまでの経緯・活動詳細については、2017 年2018 年2019 年2020年 の記事も合わせてご参照ください。

 2021 年 with コロナ での業務状況

2021 年も covid-19 の状況が大きく変化した年でした。

FJCTでは、2021年初頭から現在に至るまで、 原則リモート勤務 の形で業務が進められています。

2021 年 11月にはオフィスが 銀座 から 川崎 に移転し、そのころには感染者数も落ち着いてきていたことから、新オフィスの様子を見に出社する人もチラチラと居る、そんな状況で業務を進めています。

f:id:Con_Humi:20211224135003j:plain
川崎オフィスのイメージ

新人技術研修

FJCT では ETF を中心に 新人技術研修を内製 で行っています。 昨年に引き続いて 完全リモートでの研修 となり、昨年度の振り返りを踏まえて新たに以下の取り組みを実施いたしました。

  • 講義前後の予習復習のため、Udemy を導入
    • FJCTでは富士通グループに提供されている Udemy Business を全社員が利用できます
  • 技術研修期間中通しての メンター の導入
    • 以前は 開発演習 期間だけでしたが、研修通期で実施
  • 開発技術/経験を補強するために、開発演習を増強
    • チーム開発演習と個人開発演習の2回に分け、それぞれ2週間の期間で実施

丁度今週まで2回目の個人開発演習を実施しており、チーム開発演習や現場での業務経験を生かしたツールやサービスを開発しているようです。

社内GitLab システム刷新

FJCT ではサービスの開発・運用を支える DevOps 基盤として GitLab をセルフホストして利用しています。

2020年の記事では GitLab Enterprise Edition Premium 導入 を紹介しましたが、富士通グループ内での活用事例として GitLab 社にて事例化されておりますので、ご興味のある方はそちらもご参照下さい。

about.gitlab.com

この GitLab も ETF が主幹となって運営を行っておりますが、2021年度に大規模な改修を行いました。

詳しい内容は @aokuma さんの記事をご覧ください。

qiita.com

OSS 活動の推進

ETF では、FJCTが提供しているパブリッククラウドサービスの ニフクラFJcloud-v をより便利にご利用いただくために、GitHub 上で SDK や各種ツールを OSS 公開する活動を推進しています。

昨年より整備を進めているOSS公開フローに法り、今年も幾つかのツールがリリースされました。
ニフクラ SDK for Pythonニフクラ CLI は 2018 年にリリースした ニフクラ SDK for Python ( Developer Preview ) を継続的に改修を重ねてきた成果であり、対応サービスの拡大と使い勝手の向上がなされています。
今後も継続的に改修を続けてまいりますが、お気づきの点や新機能要望がありましたら、Issue や Pull Request をぜひお寄せください。

blog.pfs.nifcloud.com

まとめ

2021 年は with コロナ でのリモートワークの中で、会社の移転をはじめとした大きな変化が FJCT 社内で起こった年でした。
社会では「予測不可能な時代」と言われる中、私を含めFJCTの中でも変化をネガティブに捉えてしまう人は少なからず存在します。
しかし振り返れば、私たち ETF の活動はまさに、現場起点での 変化 を巻き起こしてきた活動であり、 現場起点で会社を変化させていく事 は私たちの存在意義でもありました。

現場のエンジニアが起点となり、自らの意思で会社の中にある困りごとを仕組みや技術によって解決していく活動が行えることは、FJCT の特色の一つだと思います。

変化を前向きにとらえ、むしろ自分たちの望む良い状態に近づけられるように変化を起こしていく、そんな活動を続けていきたいと考えます。

FJCT にご興味を持たれた方は、是非 採用情報のページ もご参照ください。

おまけ

ETF の活動ではありませんが、FJCTではリモートワークならではのコミュニケーション施策促進コンテンツとして、
社内ラジオ番組社内テレビ番組 の配信を行っています。

手前味噌ではありますが、社内メンバーだけで企画・制作しているとは思えないハイクォリティな
コンテンツが提供されており、社内のデザイナーやエンジニアの拘りをモノづくりに生かす、
FJCT の特色が表れていると感じています。

先日放送された年末クリスマス番組の会場機材の様子をおまけとして添付いたします。

f:id:Con_Humi:20211223232034j:plain
年末クリスマス企画の機材の様子

社内CTFを開催しました

この記事は富士通クラウドテクノロジーズ Advent Calendar 2021 6日目の投稿です。

昨日の投稿はこちらです。 qiita.com

本番環境のほかに開発やテスト用の環境は大抵必要ですし、本番環境も一つとは限らないこともあり、似たようなManifestを微妙に変えて使いたいことはたくさんあると思います。 Helm Chartを自作するとそのあたりを柔軟に行えるので重宝しますね。Helm Chartの作成が結構簡単にできる事が伝わるかと思うので、まだの方は是非読んでみてください。

さて、本日の記事では10月に弊社内でCTFを開催したことについて紹介したいと思います。


CTFとは

コンピュータセキュリティの分野において、その知識や技術を競い合う競技としてCTF("Capture The Flag" の略)というものがあります。 競技形式は様々ですが、今回社内CTFとして採用した「Jeopardy形式」と呼ばれるものについて簡単に説明します。

f:id:tofu_cider:20211206070957p:plain
Jeopardy形式

競技は主催者が問題をいくつか用意し、参加者がその問題に各自で挑む形になります。 「フラグ」と呼ばれる事前に定められたフォーマットに従った文字列がそれぞれの問題の中には隠されており、それを見つけ出すためには、与えられた暗号やバイナリファイルを解析したり、用意されたシステムの脆弱性を発見し攻撃するなどといった形で、セキュリティの知識・技術を活用する必要があります。(後程、問題の具体例も交えつつ説明します。) この「フラグ」を見つけ出し回答することで参加者は得点を得ることができ、獲得した得点を競うといった流れになっています。

国内外問わず、誰でも参加できるようなオープンなCTFはたくさんありますので、興味があれば調べてみて下さい。 例えば、 https://ctftime.org/ では色々なCTFの開催情報を調べることができます。

なぜ社内CTFを開催するのか

そんなCTFをなぜ社内開催することになったのか、個人的な部分も含めて経緯を話したいと思います。

DEF CON 27 見学

DEF CONという有名なセキュリティに関するイベントがあります。 私はコンピュータセキュリティに詳しいというわけでもないのですが、それでも名前は知っているぐらいのイベントです。

弊社では社員の技術系イベントへの参加を推奨する取り組みがあり、2年前にラスベガスで開催されたDEF CON 27に関しても、会社の費用負担にて参加できるという話がありました。

これに志願し、運良く見学してきてよいことになりました。 DEF CONの中では色々なセッションを聴講して興味深い話をたくさん聞きましたし、色々なブースでCTFが開かれていたり、会場全体の雰囲気も刺激的でした。

全社的なスキルアップの必要性

DEF CONで多くの刺激を受けた私は、見学の成果報告としてレポートを作成したり社内で報告会を実施するだけではつまらないと感じるようになっていました。そこで、弊社のサービスの開発用の環境で、実際に攻撃を試してみることにしました。そして、DEF CON内の発表で初めて知ったある典型的な脆弱性について探してみたところ、その途中にそれとは異なる脆弱性を見つけてしまいました。

迅速に修正は行われましたし、情報流出などにつながるような致命的な脆弱性でもありませんでしたが、似たようなことが起きないようにするための取り組みが必要であると感じることになりました。

弊社が提供するサービス(及びその中の機能)は多岐にわたり、それらを支えているシステムや開発・運用のチームは一つではありませんが、そのすべてにおいて強固なセキュリティを実現していく必要があります。それらのサービスに対して横断的に対処するアプローチ(簡単なところでは標準化されたチェックリストのようなものや、脆弱性診断など)も重要だと考えていますが、それと同時に、サービスを深く理解している人がそれぞれセキュリティに対する知識を磨き、各々が堅牢なサービスを作り上げていく必要もあると個人的には考えています。

CTFを企画

社内の各所にセキュリティの知識を磨く人がいるべきだという思いから、

  • 社内でセキュリティに関心を持つ人を増やす
  • セキュリティに関する情報交換ができるような社内交流の促進

を目的に、自主的な取り組みとして社内CTFを開くことにしました。

実は社内でCTFが開催されたことはこれが初めてではなく、私の所属していた部内で数年前に開催されたことがありました。 当時は私は運営に関わらないただの参加者であったどころか、CTFに触れること自体が初めてでしたが、それによって関心を持つようになったこともあり、社内CTFによってセキュリティに興味を持つ人が増えることを期待しました。

また、オープンなCTFもたくさんありますが、未知の競技にいきなり参加するのはある程度心理的なハードルがあり、参加のしやすさを考えると社内で開催するメリットもあると思います。

CTF準備

社内CTFを開催するにあたって、作問含めた運営に協力してくれる同僚を募集し、私含めて3人で運営しました。

CTF未経験者を想定して易しめの問題を中心に、以下のジャンルの問題を合計11問(ウェルカム問題除く)作問しています。

  • Crypto(暗号解読)
  • Network(パケット解析)
  • Pwn(プログラムの脆弱性を攻撃)
  • Web(Webサービス脆弱性を攻撃)
  • Misc(その他)

f:id:tofu_cider:20211206070622p:plain
用意した問題

社内交流の促進も狙っているので、チームを組んでの参加を認めつつ、参加者が一斉に挑めるよう競技時間は短期集中で90分とすることにしました。

問題例

CTFを知らない方にはイメージが付きづらいかと思うので、出題した問題について一つ紹介します。

「Webhook」というタイトルの問題では、CTF用に用意されたWebアプリのURLと共に、そのアプリの動作環境の /flag というファイルの中身に答えである「フラグ」がかかれていることが問題文にて示されています。したがって、このWebアプリの脆弱性を見つけ出し、それを利用して /flag というファイルの中身を読み出すことが、この問題を解く上でやるべきことになります。

f:id:tofu_cider:20211206071228p:plain
問題文

実際にWebアプリを見てみると、以下のようなことが分かります。

  • WebhookエンドポイントのURLを登録できる
    • 登録時にはテストメッセージを送り、正常に応答が返ってきた場合のみ登録できる作り(応答内容も表示する)
  • トップページからは登録したWebhookに対してメッセージを送信できる
  • アプリのソースコードも確認できる

f:id:tofu_cider:20211206071408p:plain
Webhookエンドポイント登録画面

f:id:tofu_cider:20211206071904p:plain
トップページ

f:id:tofu_cider:20211206072159p:plain
ソースコード確認画面(一部)

ソースコードが確認できる点については、CTFとしての出題の都合で与えているものになります。)

Webhookのエンドポイントを登録する際に正常に応答が得られるURLかを確認していますが、この部分は「事実上任意のURLに対しリクエストを投げその結果を取得できる」という性質を持っていることになります。

せっかくソースコードが与えられているので、その中身を見に行くと、内部的に pycurllibcurlpython用ライブラリ)を使っていることが分かります。 libcurlCLI上で curl コマンドとしてよく利用されていますが、 curl コマンドがそうであるように、様々なプロトコルを扱うことができます。 目的である /flag というファイルは、 libcurl からは file:///flag というURLによってアクセスできるので、これをWebhookエンドポイントの代わりに指定することで、「フラグ」を得ることができます。

f:id:tofu_cider:20211206072401p:plain
フラグ読み出し

これをスコアサーバーにて回答することで、得点を得ることができます。

f:id:tofu_cider:20211206072840p:plain
得点獲得

この問題で用意したWebアプリの脆弱性は、一般に SSRF (Server-side Request Forgery) として知られているもので、SSRFを題材にして作問しようとしてできたのがこの問題でした。

インフラ周りの工夫

CTF開催に必要となるシステムはニフクラを利用して用意しましたが、以下のような工夫をしています。

  • スコアサーバー(参加者が問題を閲覧したり回答を送信するシステム)にはお手軽に使えるCTFdをニフクラのサーバー上で動かして利用
  • 社内向けなので、社員であることが認証できた人だけに利用を制限
    • CTFの性質上いろいろなツールを使いたいこともあり、問題を解くための作業環境として個人の端末なども認めたかったことから、アクセス元は制限しない
    • Pomeriumを利用して弊社が社内システム等で利用しているIdPとOIDC連携し、スコアサーバーやWebジャンルの問題には認証されたユーザーのみアクセス許可
    • Pwnジャンルの問題は単なるTCPでの通信のためPomeriumを使えないので、SSHポートフォワーディングのみ許可する踏み台サーバーを用意し、スコアサーバーから登録させたSSH公開鍵を利用して認証
  • CTF未経験者は問題を解くための環境を持っていない可能性があるため、Unix系のCLIが欲しくなるような部分では共用サーバーを提供
    • 参加者間で共通ユーザーを利用してもらうが、ログインごとにDockerコンテナを立ち上げ、ログインセッションごとに隔離された環境が利用できる少し変わった設定
      • 一般的なLinux共用サーバーのようにユーザーで分けると、参加者ごとにユーザーを作成するのが面倒になるため
      • 問題を解くために必要になるツール類をインストールしておいたコンテナイメージを利用

f:id:tofu_cider:20211206092919p:plain
インフラ構成図

開催前後の流れ

開催まで

開催3週間前ほどに告知をして参加者を募ることにしました。 CTFが何ものかを知らない人が多いかと思うので、単にCTFを開催すると言っても伝わりにくいのが難しいところでした。 また、未経験者からは難しそうで取っつきにくいイメージを持たれやすいと思うので、未経験者でも解けることをアピールするようにしました。

最終的には、1人のみのチームも含め、14チームが参加してくれました。

当日

多くの社員が基本的に在宅勤務をしている状況なので、参加者はZoomを利用してチーム内でのコミュニケーションをとったりしつつ問題を解いていたようです。

運営としては、競技開始前後はかなり慌ただしかったです。参加者へ注意事項などを説明するオープニングの実施をしつつ、参加者が問題を閲覧できるようにスコアサーバーやWebジャンルやPwnジャンルの問題を配置しているサーバーの設定を変更する作業も必要になるためです。 競技開始後はしばらく見守るだけになりますが、スコアサーバーの設定ミスなどが見つかることもあり、気は抜けませんでした。

そして実際の競技結果が以下のスコアボードです。

f:id:tofu_cider:20211206072933p:plain
スコアボード

90分と時間が短かったこともあり、1チームあたりの正答数は少なめですが、終了1分前に首位が逆転している、なかなか熱い展開でした。

後日

数日の間を空けて、問題の解説をする会を開きました。 その際には、その問題に正答した参加者に解法を説明してもらえないかお願いし、正答者がいた問題すべてで参加者から解説してもらうことができました。 運営側で用意していたものよりも遥かに丁寧で分かりやすい解説資料を用意して下さった人もいたぐらい、参加者の皆さんの解説が素晴らしかったのが印象的でした。

振り返って

実際に開催してみてわかったことも多く、今後の取り組みにも生かしていきたいなと思っています。

苦労した点

  • 難易度の調整が難しい
    • CTF未経験者を想定しているので、難易度は控えめにしたい
    • 一方で、セキュリティに関心を持ってもらうことを意図しているため、現実からかけ離れた設定にはできず、ある程度の難易度にはなってしまう
    • 結局のところ、実際に開催してみないと難易度が適正だったか判断がつかない
  • 開催時間の調整が難しい
    • 参加者の拘束時間を長くしすぎるのも負担になってしまう
    • 短期間すぎると、問題を満足いくまで解けない可能性も増えてくる
  • 運営面での負担も大きい
    • 自主的に開催しており、通常の業務もしながら準備していたのでまとまった時間は取りにくかった

良かったこと

  • 開催後に取ったアンケートでは、好意的な意見がほとんどで、再度社内CTFを開いて欲しいという声もあった
  • 競技後に自主的に反省会をする参加者がいたり、社内コミュニケーションに利用しているSlackでエゴサしたところ結構話題にしてもらえていて、当初の目的に含まれていた社内交流の促進にいくらか繋がっている
  • 個人的な話だが、作問などを通じて新しく学ぶことも多く、運営をすることが良い勉強になった

明日の記事は @HanchA さんから「AWS EC2にPostfix, Dovecot, Zabbixを入れてサーバーを監視してみる」の予定です。 Postfixを運用していたことがあるのですが、上手く監視する方法が分からず苦労した記憶があります。もしかしたらPostfixの監視についての話題もあるのでしょうか?個人的にも気になります。 お楽しみに!

Slack botをRTMからBolt(WebSocket)に書き直しました


f:id:h45unum4:20211202153145p:plain

こんにちは!富士通クラウドテクノロジーズの蓮沼です。

この記事は富士通クラウドテクノロジーズ Advent Calendar 2021の3日目の記事です。

2日目は @herietさんの GitLab Triageでプロジェクトの棚卸しを自動化する でした。 GitLab Triage便利そうですね。年末の時期ですしGitlab issueの大掃除...🤣

という事で今日はSlack botをRTMからBolt(WebSocket)に書き直した話を書きたいと思います。

  • そもそもサムネイル Boltに書き直した経緯
  • まずは権限の再設定を
    • はまりポイント
      • Socket Modeのメニューが表示されない
      • Squid Proxy経由でSocket Modeで通信が行えない
  • Boltを使ったbot開発
  • モーダルを使ってみる
    • Block Kit Builderが便利
    • モーダルを開くショートカット
    • モーダルに入力し、slackチャンネルに投稿してみる
      • ポイント
  • まとめ

そもそもサムネイル Boltに書き直した経緯

FJCTの社内コミュニケーションツールとしてSlackを導入しており、botを活用した運用オペレーション、売上データの分析など、ChatOpsとして様々な業務でbotを活用しています。
私もSlack botを2016年ぐらいから開発して使っており、当時RTMで実装していました。
Botの名前はその名もHaaS(Hasunuma as a Service)
私の代わりに24/365で仕事をしてくれます🤣
しかし最近では新しくSlack botを作成するとRTMは利用出来なく、より細かな権限管理が可能なEvents APIや、モーダルなど双方向の通信で役立つSocket ModeをサポートしているフレームワークBoltを使ったほうがモダンであるため、書き直してみました。

実際のところは

続きを読む

EVPN L2VPN All-Active MultihomingにおけるRoute Typeと経路迂回

この記事は富士通クラウドテクノロジーズ Advent Calendar 2020 23日目です。

はじめに

ネットワークサービス部でネットワークの設計/構築/運用を担当しているid:foobaronです。

本記事では、EVPN L2VPN All-Active MultihomingにおけるRoute Typeと経路迂回についてまとめています。

EVPNの概要については、次の記事「EVPN-VXLANのAll-Active Multihomingによる拠点間の接続を試しました」もご参照ください。

続きを読む

ニフクラとNSX・DFW のトラブルシューティング

この記事は 富士通クラウドテクノロジーズ Advent Calendar 2020 の18日目の記事です。

f:id:higc_fjct:20201218204347p:plain

  • はじめに
  • ニフクラと NSX
    • 歴史
    • NSX 運用体制
    • NSX 運用ツール
    • インフラ CI
  • DFW のトラブルシューティング
    • DFW とはなにか?
    • トラブルの種類は大きく分けると2種類
    • 設定が反映されていない場合の切り分け
      • 「(1)ユーザーが NSX Manager へルール更新操作をする」 の確認
      • 「(2) NSX Manager が ESXi ごとにルールセットをまとめ配信する」 の確認
      • 「(3) ESXi の vsfwd がルールを受け取る」
      • 「(4) vsfwd から vsip 経由で dvfilter(vNIC 毎に作成されるフィルタ)の設定が変更される」 の確認
      • まとめ
    • ルールで許可しているがドロップするケースの切り分け
      • DFW のメカニズム
      • ルールテーブルでドロップした場合の切り分け方法
      • ファイアウォール全体で拒否しているか切り分ける方法
      • コネクショントラッキングテーブルでドロップした場合の切り分け方法
      • コネクショントラッキングテーブルが理由でドロップするケース(1) 非対称ルーティング
      • コネクショントラッキングテーブルが理由でドロップするケース(2) EST 状態で SYN を受け取った場合(6.2.3 で改善)
  • おわりに

はじめに

こんにちは。富士通クラウドテクノロジーズ株式会社の樋口です。 普段は NSX を中心にニフクラのインフラ運用管理をしています。 先日 12/15 に NSX-v 6.4.9 がリリースされました。 NSXNSX-v が開発終了を予定して NSX-T に移っていく予定ですが、 まだまだ NSX-v も現役で運用されています。

今日はニフクラで NSX をどういう風に運用しているかと、 NSX-v の DFW のトラブルシューティングについて記事にしたいと思います。

続きを読む

NSX-T の Go 言語 SDK について調査しました(2020/12版)

vExperts Advent Calender 2020 に参加しています。 17日目の記事です。
(明日は富士通クラウドテクノロジーズ Advent Calendar 2020NSX-v に関する記事を投稿するのでよろしくお願いします)

  • はじめに
  • SDK を選ぶ時のポイントにしたこと
    • どの種類の NSX-T API が使えるか
    • 継続して更新されそうか
    • サポート
  • 調査対象
  • 公開されている SDK の開発状況について
  • 比較結果
    • 比較表
    • 結果まとめ
  • おまけ: vsphere-automation-sdk-go の使い方
  • さいごに

はじめに

こんにちは。富士通クラウドテクノロジーズ株式会社の樋口です。 普段は NSX を中心にニフクラのインフラ運用管理をしています。 NSX-T の操作をするアプリケーションの開発を始めた都合で、 チームで Go 言語の SDK について調査する機会がありました。 検討の際にしらべたことを記事にいたします。

f:id:higc_fjct:20201217212138j:plain
最近vExpert2020刺繍つきニフクラパーカーを社内で作ってもらいました

続きを読む

FJCT エンジニアタスクフォース 2020 レポート

f:id:tily:20191219162021p:plain

みなさんこんにちは! FJCT の竹内です。
FJCT アドカレ 2020 の 12 日目は、毎年恒例となった弊社 ETF の活動について紹介させていただきます。

  • ETF とは?
  • 2020 年コロナ禍における活動
  • コロナ禍に対応した環境の改善
  • 新人技術研修のリモート化
  • 社内外イベントのオンライン化対応
  • OSS 活動の推進
  • まとめ
続きを読む