TAFS Advent Calendar

  こんにちは。 今年もAdvent Calendarに参加します。MPPAです。 自分的には今年一番の職務上で出会ってはまった事象を、 今回の記事に書きたいと思います。 👊目次👺 事象紹介 実際に試す環境づくり（AWS Lambda） 事象再現 さいごに 1.事象紹介：Outlookの謎通信 メールによくリンクが張ってありますが、これをOutlookでクリックして、 ブラウザで開くと以下のようなアクセスが行われていることがわかりました。 　・メールのリンクをクリックする 　・ まずHEADリクエストがサーバーに送信される。←　期待してない 　・続いてブラウザが開いてリンクにアクセスする。 赤字の部分が、サーバー側というかコーディングしている上では予期せぬ動きで、 作成時にデバッグ、単体テストを実施しているときは全く気づきませんでした。 今回はパスワードリセットのメールで、リンクをクリックするとパスワードが初期化されるというものでしたので、皆メールのリンクをクリックするはずです。 色々調べてみたのですが、このような仕様がOutlookにあるなんていうのはどこにも見当たらず。。。 ちなみに環境は 　サーバー：GCP（Google Cloud)　CroudRun関数 　言語：Python 　クライアント：Windows 11 　メーラー：Outlook デスクトップアプリ（Classic） です。OutlookのWebアプリや最新のOutlook(new)では事象は発生しないようです。 2.実際に試す環境づくり（AWS Lambda） では、実際に環境を作成してきます。 用意するものは簡単です。 複雑なアプリケーションを作る必要はなく、受け口を作っておけばいいのです。 というわけで、AWS Lambdaを利用してHello Worldとでも返すコンテンツを作成します。 Lambdaで関数の作成を選んで、行きます。 ここ半年で猛烈に学習したPythonで「hello_lambda」を作成します。 コードはこんな感じにしておきましょう。 import json def lambda_handler ( event , context ):         http_method = event[ "requestCo...

背景 AmazonLinux2上で利用していたSplunkを AmazonLinux2023上でも同じような設定で動くのかを検証しました。 その検証でAmazonLinux2とAmazonLinux2023との仕様変更により 躓いた点と解決策についてまとめてみました。 今回の構成 構成は下図のような構成とし、クラスターの管理をしているコンポーネントである Cluster Masterとデータの保管、インデクシングを行うIndexerClusterを構築。 ※Splunkバージョン：9.0.2 実施内容 ClusterMasterからS3バケットにインデックスを格納する処理(SmartStore)を 構築する設定を記載した設定ファイルをIndexerClusterに配布。 このときに設定ファイルを配布する処理は動いたもののIndexer側でメタデータ取得ができない事象が発生しました。 ①bundle applyで作成されたチェックサム：下4桁 2784 ②正常に配布処理が完了すると各クラスターメンバーのバンドルチェックサムも 　配布時に生成されたチェックサムと一致します。今回は配布できていなため一致していません。 原因 今回の配布処理が適用されていなかったのは IndexerCluster側でIMDSv2を有効ではなかったことが原因でした。 (デフォルトでSplunk側ではIMDSv1が有効になっている) IMDSv2を有効にすることで、AmazonLinux2023上のメタデータ取得が 正常に行われS3とEC2インスタンス間の通信が行われます。 IMDS(インスタンスメタデータサービス)とは IMDSはEC2内から実行中のインスタンス情報(インスタンスIDやIPアドレス等)を 取得できる仕組みのこと。バージョン1,2が存在します。※1 バージョン1・・・リンクローカルIPで動作しており仕組みにHTTPリクエストを送ることで誰でも取得可能。 バージョン2・・・バージョン1での照会方法をURLだけでなくトークンを合わせて利用することでセキュリティ強化。 AmazonLinux2023からの仕様変更 AmazonLinux2ではIMDSv1 or IMDSv2どちらも利用可能だったのですが AmazonLinux2023ではIMDSv2のみ使用するようになっており、Spl...

  こんにちは。 TAFS Adventカレンダー2023 にチャレンジしますMPPAです。 表題に掲げた「かっこよく」いかにも胡散臭いタイトルですが、 周りにヒアリングしたところ、この方法が「まだ当たり前のように使われているわけではない」と独自調査（これも胡散臭い）で判断したので記事にしようと思います。 👹 お品書き 👺 1.　本日のゴール 2.　RD Gatewayを利用するメリット 3.　準備 4.　かっこよく接続する環境を作る 5.　最後に 1.本日のゴール 今回はAWSを利用してWindowsVMを起動し、RD Gatewayを利用してRDP接続します。 2.RD Gatewayを利用するメリット ゲートウェイにも認証があるため、ユーザー認証や証明書認証適用できるため、このゲートウェイを通過したもののみが内部へアクセスできるようになります。 ゲートウェイ認証での制御でアクセスすれば、無造作に作成されたAdministrator/P@ssw0rdみたいな 真っ裸な サーバーへのアクセスも いったんは 安心です。 また、リモートデスクトップ標準ポート3389をセキュリティグループにて許可する必要がなくなります。攻撃対象になりやすい3389ポートなので閉めておけば ちょっとは 安心です。 もう一つ大きなメリットとして、例えば443ポートでゲートウェイが通信していれば、 443ポートでゲートウェイを通過してSSLトンネルを利用してリモートデスクトップに接続可能です。（私はこの接続あまり 好きじゃない ですけどまあセキュアですよ） と言うわけでこれと言ったメリットが説明できなくて ごめんなさい🙏 。 3.準備 ざっくりですが以下のように環境を作りました。 名前 備考 リージョン ap-southeast-1 シンガポールリージョン VPC mppadev-vpc1 SUBNET mppadev-public-subnet1 10.1.129.0/24 ルートテーブル mppadev-public-route1 インターネットGW mppadev-inet1 セキュリティグループ mppadev-sec-group1 　 Elastic IP mppadev-elaip1 証明書を使うので利用 4.かっこよく接続する環境を作る 4.1　VMの作成 まずは...