osqueryのインストールでエラーが発生してこずった件

osquery とは、Facebookが開発したSQLライクな攻撃/侵入検知ツールとのことです。
いろいろなシステム情報をわかりやすいフォーマットでコマンドプロンプト上に表示でき、Splunk というSIEMにシステム情報を取り込むのも簡単そうだったので、MacOS にインストールしてみることにしました。

当初は簡単にインストールできるだろうと考えていましたが、brew install osquery とコマンドを打ったところ、以下のように「Error : osquery has been disabled!」と表示され、インストールできませんでした。

そこでGoogleで検索しましたが、いくら検索してもHomebrewを使う以外の方法が見つからず、困っておりましたが、ようやくあるサイトを見つけ、インストールすることができました。

osquery.ioサイトからMacOS用のpkgファイルがダウンロード可能

そんな中、ようやく以下のサイトを発見しました。

https://osquery.io/downloads/

このサイトにアクセスすると、自動的に最新バージョンのダウンロードページが表示されます。

下にスクロールすると、MacOSのpkgがダウンロードできます。

ダウンロードした後は、(あまり覚えていませんが)たぶん、pkgファイルをダブルクリックしただけで、インストールできました!

今後はこのツールを利用して定期的にシステム状態を監視してみたいと考えています。

「2020年間ビジターアンケートについて」というフィッシングサイトについて調べてみた

今日、FireFoxでGoogle検索していると、突然「2020年間ビジターアンケートについて」という画面が表示されました。
なにやらFireFoxの何番目かのラッキーな利用者で、ただでiPhoneがもらえるとのことだったので、4つほどボタンを押しながら質問に答えていったところ、いまなら100円でiPhoneが買えるとのこと。

無料じゃないじゃんと突っ込みながら、あああ、フィッシングなのねとようやく気がつきました。
結局、その先に進まなかったのでよかったですが、ちょっと癪に障りました。
そこで、このフィッシングについて少し調べてみました。

なお今回のサイトはeraxotics3.liveというドメインでしたが、googleで調べてみると他のドメインもあるようです。

ロシアのフィッシングサーバらしいですが、マルウェアはいない模様

1.aguseをつかってサイトの情報を確認

まず、そのサイトの情報をaguseというサイトを使って調べてみました。
このaguseはセキュリティ技術者においては有名なサイトで、指定したサイトの情報を表示したり、ユーザのPCの代わりに、aguse がそのサイトにアクセスしてくれるので、危険そうなサイトの画面を確認してみたい場合に、よく使われています。

どうもこのサイトにマルウェアは仕掛けられていなさそうです。ちょっと安心。

またこのサイトのサーバはロシアにあるみたいですね。

どうやら、「The spamhaus project」というサイトがこのサイトを注意が必要なサイトとしてリストアップしているようですね。

2.VirusTotalでも念のため確認

aguseでこのサイトにマルウェアはいなさそう(ただのフィッシングサイトらしい)ことはわかりましたが、念のためVirusTotalでも調べておきます。
このサイトもセキュリティ関係者には有名で、サイトにウィルスなどのマルウェアが仕掛けられていないか確認できます。

VirusTotalでは名だたるセキュリティベンダー(今回は79 社)のスキャンエンジンで、指定したサイトにマルウェアがいないか調査してくれますが、先ほどのSpamhaus以外は問題ないといっていますね。

やはり、サイトにアクセスしているだけだと問題なさそうですね。

もし、クレジットカードの番号を入力してしまったら。。。

このように、このサイトにはマルウェアは仕掛けられていませんでしたので、アンケートに答えただけであれば問題なさそうですが、もし万が一、「ここをクリック→」の先に進んでクレジットカード番号を入力してしまった場合、即刻、クレジットカード会社にカード利用を停止してもらうことをお勧めします。

ちなみに私はこのあと、おなじようなサイトにアクセスしないように *.live ドメインに飛ばされた場合には止めてくれるように、ウィルスバスターに登録しておきました。

liveドメイン以外にも同じようなフィッシングサイトはありそうですが、これでちょっと安心かも?

AWSへのポートスキャンをネットワークACLで止めてみた

先日、GuardDuty を設定してから、海外からHTTPやSSHに対してポートスキャンやブルートフォース攻撃を受けていることがわかったので、ネットワークACLで止めることにしました。
最初はセキュリティゲートウェイ(SG)で止めようとしたのですが、SG は許可設定しかできないみたいなので諦めました。

VPCからネットワークACLの設定を行う

そういえばネットワークACLってどこから設定するんだっけ?と最初、悩んでしまいましたので、ネットワークACLにたどり着くところから説明しておきます。

1.VPCの設定画面に移動

AWSマネジメントコンソールにログイン後、”VPC”で検索します。

VPCの画面の左ペインにある「ネットワークACL」を選択します。

ここでメイン画面の中から「インバウンドのルール」タブを選択すると、現在のフィルタリングルールが表示されます。
この例では、VPC内のすべて(3つ)のサブネットはこのルールで守られている(関連づけられている)ようですね。

2.ネットワークACLの編集

ネットワークACLが一つしかないのでそのまま「アクション」のプルダウンから「インバウンドルールの編集」を選択します。

以下の画面に切り替わりますので、ここで「ルールの追加」ボタンを押します。

そして、新しいルールを記述しますが、今回はDENYルールを記載しますので、既存のルール(ルール番号100)より若いルール番号(以下の例では10)を設定します。

この後、保存ボタンを押すと以下のとおり新規に作成したルールが既存のルールより優先して適用されます。

これでGuardDutyで頻発していたポートスキャンやブルートフォースが発生しなくなるはずですので、少し様子を見てみたいと思います。

CISSPのCPEポイントを無料もしくは格安で取得する方法(その1:ISC2 ラボコース)

今現在、ISC2のCISSPの認定を取得しており、その認定を維持するには年間で40ポイントと取らないといけません。
同じくISC2の認定を取得されている方は、同団体から提供されているWebnerやMagazineのクイズでなんとかしている方が多いのではないでしょうか?

私の場合もそれらを軸にして、あとはいくつかの団体が非定期で提供しているセミナーなんかを受けてやりくりしております。
しかしながら、先ほどのWebnerやMagazineは数が限られているのでそろそろ残りがすくなくなってきており、またセミナーについてはコロナの影響で取りやめになったりしており、なかなか取り辛くなってきております。

そこで今後、最近私がみつけたポイントネタをいくつかピックアップしていきたいと思います。

ISC2のバーチャルラボで手軽にセキュリティツールを触ってみる(無料、2CPE)

2020.07.25
バーチャルラボを受講しCertificateを取得して一ヶ月経過しましたが、その後、CPEsに反映されていません。現在、ISC2に理由を確認中です。
2020.08.01
ISC2から以下の通り回答が来ていました。CPE Portalにて別途申請が必要らしいです。(証明書ファイルを一緒にアップロードしておくと良いようです。)
I am happy to provide assistance with your inquiry.
At this time, CPEs earned through PDI need to be reported by the member through the CPE Portal.
We apologize that CPEs are currently not reported on the member’s behalf. 
When submitting the earned CPEs, it is recommended to include your Certificate of Course Completion as documentation, which can be found under the Awards tab in (ISC)2 Learn.

ISCのサイト(www.isc2.org)は一時期、使い勝手がひどかったですが、最近はだんだんよくなってきましたね。
そのサイトにアクセスし、上部のメニューバーから「Members」を選択すると、「CPE Opportunities」という項目がありますので、それをクリックします。

すると、以下の画面が表示されます。

その後、画面を下の方にスクロールしていくと、「Lab Courses」というカテゴリがあり、その右横にバーチャルラボで体験できる操作が表示されています。

そこでどれか自分が興味があるものを選択してもらうと、以下の画面が表示され、この例でいうと2CPEのポイントが獲得できることがわかります。

内容が確認できたら、「FREE FOR MEMBERS」を教えてもらえれば、インストラクションのビデオを見ながら、バーチャルラボを利用して色々なオペレーションを実際に体験することが可能です。

私は取り敢えず上の例にある「Introductory File System Forensics」を試してみましたが、FTK ImageやAutoSPY、Kali Linuxなどのフォレンジックツールを簡単に操作してみることができ、とても参考になりました。

ただし、その後に20問の質問に答えて70点以上の点数と取らないと2CPEがゲットできず、1発合格とはいきませんでした。なお、回数制限は内容なので、英語とはいえなんとかなるかと思います。

AWSでsudo的な権限昇格(その1:スイッチロールの設定)

これまでは、AWSコンソールでデータを確認するだけの場合、一般ユーザでログインし、設定に変更を加えたい場合、rootでログインしていました。
しかし、私の場合、AWSをテスト的に使っており、頻繁に設定変更をおこないたくなるので、いちいちログインし直すこの運用はとても面倒に感じていました。
また、rootでログインしているとGuardDutyが毎回アラートを発砲してしまうので、それも避けたいと考えていました。

そこで今回は、AWSコンソールでLinuxで言うsudo的な運用ができるように、スイッチロールの設定をしてみました。

スイッチロール機能で同一アカウント内で最低限の権限昇格が可能

AWSにはスイッチロール機能というものがあり、パスワードを要求せずに簡単に権限昇格をさせることが可能です。
だだし、パスワードを要求しない分、権限を与えすぎるとrootユーザでログインしたのと変わらなくなり、かなり危なくなりそうなので注意が必要と思われます。

1.IAMでスイッチ先のロール作成

rootユーザでAWSコンソールにログイン後、IAMに移動します。

上記画面の左上にある「ロールの作成」ボタンを押すと、以下の画面が表示されます。
ここで、左から2番目の「別のAWSアカウント」を選択し、現在使っているAWSアカウントIDを入力します。

「別のAWSアカウント」とありますが。。。

実は同一のAWSアカウントも入力可能ですので、同じAWSアカウント内でロールを切り替えたい場合は、こちらを選択してください。
もちろん、別のAWSアカウントのロールに切り替える場合もこちらを使います。

そして、「次のステップ:アクセス権限」ボタンを押すと、今回作成するロールに与えるポリシー(権限)を選択できます。

ポリシーの選択は慎重に。。。

下の例ではAdministratorAccessを設定していますが、実はあとで変更しています。あまり権限を与えすぎると、このユーザIDを乗っ取られた時に、何でもできてしまいますので。

上記画面から「次のステップ:タグ」を押すと、タグの設定ができます。ここは任意ですので、自分がわかりやすいようにタグをいくつか付けて、「次のステップ:確認」を押します。

すると、設定の確認画面が表示されますので、ここでロール名等を入力し、「ロールの作成」ボタンを押します。

これで、新しいロールが作成されました。

2.IAMでスイッチ元のポリシーの作成

次にログインIDに対してスイッチロールさせる為のポリシーを作成します。

IAMの画面の左ペインから「ポリシー」を選択後、メイン画面の左上に表示される「ポリシーの作成」を選択します。
すると以下のポリシー作成画面が表示されますので、「JSON」タブに切り替え後、以下の画面のとおり、記述を行ってください。

一応、記述内容をテキストにしておきますので、コピペした後、「アカウントID」と「ロール名」の部分を書き換えてもらえればOKです。

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": "arn:aws:iam::(スイッチ先のアカウントID):role/(1.で設定したロール名)"
    }
}

上記の記述が終わったら、「ポリシーの確認」ボタンを押します。

すると、ポリシーの名前を記入する画面が表示されますので、それを記入後、「ポリシー の作成」ボタンを押してください。

3.ユーザーにロールへのアクセス権限を付与

権限昇格をさせたいユーザーに2.で作成したポリシー(AdminGroupRoleへのスイッチを許可したもの)を割り当てます。
IAMの画面の左ペインから「ユーザー」を選択後、メイン画面からポリシーを割り当てたいユーザーを選択します。

するとユーザーの概要画面が表示されますので、「アクセス権限」タブの中から「アクセス権限の追加」ボタンを押します。

すると以下の画面が表示されますので、「既存のポリシーを直接アタッチ」を選択後、先ほど作成したポリシー(AdminSwitchPolicy)を選択します。

その後、「次のステップ:確認」ボタンを押すと確認画面が表示されますので、そのまま「アクセス権限の追加」ボタンを押します。

4.実際にスイッチロールしてみる

これでスイッチロールが可能となりましたので、許可したアカウントにてAWSコンソールにログイン後、画面右上に表示されている「ユーザー名@アカウントID」をクリックし、表示されたプルダウンの中から「スイッチロール」を選択します。

すると以下のロール切り替え画面が表示されますので、スイッチ先のアカウント(スアカウントID)とロール(ロール名)、色(背景色)を指定し、「ロールの切り替え」ボタンを押してください。

うまくいけば、画面右上のログイン情報(ロール名@アカウントID)の背景が指定した色に切り替わり、元のログインユーザーではできなかった操作ができるようになります。

以上で、スイッチロールが正常に動作することが確認できました。

しかし、この設定のままだと、ログイン可能なユーザーであれば誰もが特権を持つことができるようになってしまいますので、次回は、スイッチロールができるユーザを制限する方法をアップしたいと思います。

AmazonのGuardDutyを有効化してみた(その3.メール通知)

先日、GuardDuty を有効化しましたが、今の設定では、AWSにログインしない限り、不正なアクセスに気がつくことができません。
そこで、GuardDuty でアラートが発生した際にメールが送信されるように設定してみました。

SNSとCloudWatchを利用しメールを送信

SNSとCloudWatchを利用することで、GuardDutyで検知したアラートをメールで通知することが可能です。

1.Amazon SNSでトピックの作成

まず、Amazon SNSの画面に移動します。すると以下の画面が表示されるので、指示に従いトピック(メッセージチャネル)を作成しましょう。

トピック名について

トピック名にスペース(空白)は使えないようですので、注意してください。

トピック名を入力し、「次のステップ」を押すと以下の画面が表示されます。いくつか設定項目がありますが、トピック名以外はオプションなので、そのまま「トピックの作成」ボタンを押しても問題ありません。

すると以下のようにトピックが作成されます。

2.Amazon SNSでサブスクリプションの作成

トピックを作成した後は、サブスクリプションの作成を行います。
ここでは、作成したトピックで利用するプロトコル(Eメール)やエンドポイント(送信先)を指定します。

プロトコルとエンドポイントを指定後、「サブスクリプションの作成」を実行すると、サブスクリプションが以下のように作成されます。

この時だと思いますが(若干うろ覚え)エンドポイントに指定したメールアドレスに確認のメールが届きますので、必ず「Confirm subscription」のリンクをクリックしてください。

メールのリンクをクリックすることで、先ほど作成したトピックのステータスが「確認済み」となります。

これをやっておかないと、次のCloudWatchの設定をいくらやってもメールが届きません。(私はこれで少しはまりました。)

3.ClowdWatchでルール作成

これでメールを送信する準備が整いましたので、次にCloudWatchを使ってGuardDutyのイベントを送信対象とするルールを作成します。
以下のCloudWatch画面の左ペインから「ルール」を選択します。

すると、以下の画面が表示されますので、「ルールの作成」ボタンを押します。

ボタンを押すと、以下の画面が表示されますので、イベントソースとターゲットを指定します。

指定の方法は以下の通りです。

イベントソースとして「イベントパターン」を選択後、以下の通り設定します。
・サービス名:「GuardDuty」
・イベントタイプ:「GuardDuty Finding」
・イベントパターンのプレビュー:特に編集しなければすべてのGuardDutyのアラートが送信されます。編集する場合は、以下を参考にしてください。

イベントパターンのプレビューの編集例
例)7.0〜8.9までの重要度のアラートが発生した場合のみ通知したい場合

{ “source”: [ “aws.guardduty” ],
“detail-type”: [ “GuardDuty Finding” ],
“detail” : { “severity”: [7.0,7.1,7.2,7.3,7.4,7.5,7.6,7.7,7.8,7.9,8.0,8.1,8.2,8.3,8.4,8.5,8.6,8.7,8.8,8.9 ] }
}

ターゲットとして「SNSトピック」を選択後、以下のとおり設定します。
・トピック:1.で設定したトピック名
・入力の設定:インプットトランスフォーマー
・最初のテキストフィールド記入例:
{“type”:”$.detail.type”,”title”:”$.detail.title”,”description”:”$.detail.description”,”severity”:”$.detail.severity”,”updatedAt”:”$.detail.updatedAt”,”createdAt”:”$.detail.createdAt”,”arn”:”$.detail.arn”}
・次のテキストフィールド記入例:
“GuardDuty で以下の脅威を検知しました。”
“種別  :””タイトル:”
“説明  :<description>”
“重要度 :<severity> “
“更新日時:<updatedAt>”
“作成日時:<createdAt>”
“ARN   :<arn>”

以上を設定後、右下の「設定の詳細」ボタンを押すと、以下の画面が表示させますのでルールの名前などを設定し、「ルールの作成」ボタンを押します。

「ルールの作成」ボタンを押すと、以下のようにルールが作成されます。

4.GuardDutyのアラートを待つ

以上でGuardDutyでアラートが発生するとエンドポイントで指定したメールアドレスにアラートメールが届くようになっているはずです。

もし早く確認したければ、GuardDutyの画面の左ペインから「設定」を選択し、その中から「結果サンプルの生成」を押せば擬似的にアラートを出すことができますが、大量に出てしまうので、個人的にあまりおすすめはしません。

ちなみにGuardDutyのアラートをすべて受け取るようにしていると、毎日数通以上のメールがきてしまうと思いますので、ある程度重要度の高いアラートのみ通知させた方がよさそうです。

AmazonのGuardDutyを有効化してみた(その2.検知状況)

GuardDuty を有効化してから、ちょうど無料期間30日の半分、15日が経過しました。(すっかり有効化したことを忘れそうになっていましたが。。。)
そこで、現在の検知状況と無料期間が終わったあとの予想料金を調べてみました。

ポートスキャンのみを検知。以外と攻撃されていない?

ひさびさにGuardDutyを覗いてみたところ、rootログイン以外にポートスキャンらしきものが検知されていました。(真ん中のリストの真ん中の行)
カウントに89とあるので、89回スキャンされたということでしょうか?ここはよくわかりません。

右ペインの影響を受けるリソースのところにHTTP(80 Port)とあるので、このportへのアクセスはブロックしておいた方がよさそうですね。
たしかに、HTTPSでWordPressを提供しているので、HTTPは不要ですね。

また、右ペインを下までスクロールしていくと、攻撃者の情報も出てきます。

どうやら、11日前から2日前までの間、ロシアのPetersburg Internet Network ltd.というプロバイダを使っている誰かからポートスキャンされているようですね。

無料期間が過ぎても費用は0.00 USD?

十分かどうかわわかりませんが、GuardDutyは働いてくれていることがわかりましたので、今度は無料トライアルの状況を確認してみました。

するとどうでしょう、GurdDutyで監視してくれた各ログの量は以下の通りで、無料トライアル終了後の日次推定コスト0.00 USDとなっています。

CloudTrail ログ940.0 イベント
VPC フローログ25.15 MB
DNS ログ41.24 MB

まあ、このサイトは貧弱で1日に10人も見にきてくれないサイトではありますが、、、まさか0とは思いませんでした。もしかすると、1ヶ月で見ると多少費用がかかるのかもしれませんが。。。

これなら、無料期間が終了した後も使い続けてもいいかもしれません。

AWS Configの機能と、利用した場合の料金の増加について

CloudTrail が人を軸にしてAWSに対する操作を記録するのに対し、Configは各操作対象(何に)を軸にして操作を記録していく機能になります。

CloudTrail はデフォルトで動作しているのに対し、Configはデフォルトでは動作していないので、利用するには初期設定してあげる必要があります。
しかしながら、ここで気になるのがConfigを新たに利用し始めることによるAWS料金の増加です。ログの記録にS3を利用することになるなど、あまり経験のない人には料金の予測がつかず、利用を躊躇してしまうと思います。

しかし、Configの機能はAWSを利用している人であれもが誰もが使っておいた方がよさそうですので、今回、Configの機能を確認しながら、実際利用するとどれくらい料金がが増加するのかを調べてみました。

Config設定後、$0.07/月の料金増加(Configルール未使用の場合)

以下の画面は、Configを利用する前の料金です。
AWSの無料枠内でWordPress用にEC2のインスタンスを1つ作成し、独自ドメインでアクセスできるようにRoute53を利用しています。
実質、Route53の料金$0.55/月(税込)のみです。日本円でいうと60円/月だと思いますので、レンタルサーバとくらべるとめちゃくちゃ安いです。

この状態から、まずはConfigの初期設定をしてみました。

1.記録する対象とログの保存先を設定

操作を記録する対象(リソース)とログの保存先(S3)を設定します。今回は、リージョン内の機能以外に、IAMなどの操作も記録したいので、「グローバルリソースを含める」に追加でチェックを入れました。

2.通知設定とConfigへの権限設定

1.の画面を下にスクロールしていくと、SNS(Simple Notification Service)と権限(ロール)の設定項目があります。特に今回は変更しないので、そのまま「次へ」ボタンをクリックしました。

3.Configルールの設定

Configルール設定をしておくと、そのルールに違反する設定をした場合に警告を出してくれるようになります。(なるはずです。)
現時点(2020.5.22)で88個のルールがあるようですが、これを設定した分だけ料金があがりそうな気がするので、とりあえず、どれも有効にはせず、「次へ」を押しました。

4.設定の確認と利用開始

設定内容が表示されますので、間違いがなければ、「確認」を押しましょう。

20分くらい経過すると、以下のように対象リソースが表示されます。

せっかくなので、今回のS3バケットの作成が記録されているか確認してみる為、上図のリソースの中にある「S3 Backet」をクリックしてみました。

そして、リソース識別子をクリック。

すると、右上に「設定タイムライン」というボタンがあるので押してみます。以下のように、今日の9:37に作成されたことが記録されていました。

ちゃんと動いているようですね。(あたりまえか。。)

5.実際にS3バケットが作成されているか確認してみる

さらにS3バケットが実際に作られているか確認してみます。

どうやら無事に作成されており、Configのログが書き込めるか確認する為?のファイルが置かれているようです。

6. Config設定後の請求書を確認してみる

約1時間前にConfigを設定したばかりなので、まだ反映されていないかもしれませが、この時点で請求書を再度確認してみました。

結果としては、特に変化はなく$0.55/月のままです。
まだS3に何も書き込まれておらず、Configルールも設定していないからかもしれません。
噂では前払い料金がかかるはずなので、もう少し様子を見て見たいと思います。

(2020.5.26追記)
翌日、再度請求書を確認したところ、料金が$0.07増えていました!(以下の図の右側、Configの項目)

料金明細を確認してみたところ、Configuration item毎に$0.003かかるようで、私の場合、24アイテムある(設定したときは23アイテムでしたが)ので、$0.072という計算らしいです。(よく見ると、東京ではなくバージニアで作ってしまっていますが。。。後で変えられるのでしょうか?)

だいたい10円/月くらいなので使い続けてもまったく問題ないですね!
今後機会があれば、今回スルーしたConfigルールも使ってみたいと思っています。

AWS上のWordPressから 自ドメインでメールを送信をする

以前、AWS上でWordPressを立ち上げ、WP Mail SMTP プラグインを使ってメールを送信できるようにしました。

しかし、その時に設定した環境では、送信されるメールの送信元アドレス(Googleのメールアドレス)と送信元サーバ(Amazon)が異なる為、受信したメーラー側で以下のような警告が発生してしまいます。

自分にメールしているだけなので大きな問題はありませんが、ちょっとかっこ悪いのと、SPFやDKIMが使えるかどうかも確認してみたかったので、AWSから自ドメイン(k-ornata)のメールアドレスを送信元にしてメールを送信してみることにしました。

Amazon SES に送信元ドメインを登録し、Route 53にレコードを登録するだけでOK

DNSとしてroute53を利用している前提ですが、Amazon SES に送信元にしたいドメインを登録し、その勢いでroute 53に必要なレコードを登録するだけで設定が完了します。

1.SES から自ドメインを登録

SES Homeにアクセスし、左ペインから Domains を選択します。

「Verity a New Domain」をクリックし、以下の通り、自ドメイン名の入力と、「Generate DKIM Setting」のチェックを入れます。

2.Route 53へのレコード追加

上の画面で「Verity This Domain」をクリックすると、以下のようにDNSサーバに登録するTXT, CNAME, MXレコードの情報が表示されます。
今回はDNSとして Route 53 を使いますので、「Use Route 53」のボタンを押すだけです。

すると以下のように確認画面が表示されますので、必要に応じて(自ドメインでメールを受信したい場合)「Email Receiving Record」にチェックを入れ、「Create Record Sets」にチェックを入れます。

すると、以下の画面が表示され、ドメインの確認とDKIMの設定をAWSが自動で開始してくれます。

処理が完了(だいたい5分くらい)すると、(AWSコンソールの?)管理者のメールアドレスに、以下2通のメールが送られてきます。

ドメインの確認が完了した旨の通知メール
DKIM の設定が完了した旨の通知メール

メール受領後、再度、SES Home の Domainsを確認すると、ステータスが pendingから verified に変わっているのが確認できます。

3.自ドメインでのメール送信確認

以上で自ドメインでメール送信できるようになりましたので、テストメールを送ってみます。
以下のとおり、SES Home のDomains から今回登録したドメインにチェックし、「Send a Test Email」を押します。

すると以下のとおり、テストメール送信用のウィンドウがでますので、各項目を入力し、「Send Test Mail」を押します。

すると、Toで指定したメールアドレスにテストメールが送られてきます。

上記のとおり、Fromがちゃんと自ドメインで送られてきており、SPFやDKIMもパスしています。(簡単すぎて、SPFやDKIMの理解にはつながらないかもしれませんが。。)
なお、Fromの@の左側は(たぶん)何でも大丈夫です。(ユーザの有無とかは気にしなくてよさそうです。)

また、ToはSES Home のEmail Addressesにてverifiedになっているものを使ってください。もしそれ以外のアドレスに送付しようとすると、以下のように「検証されていない」と怒られます。

これはセキュリティ面を考慮し、デフォルトでは検証済のアドレスにしか送れないようにしているらしいです。(これを解除する方法があるらしいですが、ここでは触れません。)

4.WordPressのWP Mail SMTP の送信元アドレスを自ドメインに変更

WordPressからメールを送信する時にWP Mail SMTP プラグインを使っている場合、その送信元アドレスを今回設定した自ドメインのものに変更します。
そしてテストメールを送信してみると、以下の通り、自ドメインのメールアドレスからメールが送信されてくることが確認できます。

これでWordPressのメール環境はスッキリしましたが、あまりにも簡単だったので、SPFやDKIMの勉強にはならなかった気がします。
機会を見て、もうすこし掘りさげてみたいと思います。

AmazonのGuardDutyを有効化してみた(その1.初期設定)

ただいまAWSの無料枠でインスタンスを起動し、勉強しております。その中で、Amazon GuardDuty というセキュリティ機能を使ってみたのでその有効化の手順を記載しておきます。

30日間は無料トライアル可能、有効化もボタン一発。

GuardDutyを有効化するのは非常に簡単で、事前の準備は要らず、ボタンを2回クリックするだけで有効になります。また、最初の30日は無料トライアル期間となっており、その間に有効性を確認し、不要と思えば、簡単に無効化することもできそうです。

1.GuardDuty機能の呼び出し

AWSにログインしたら、検索バーからGuradDutyを呼び出します。

2.GuardDuty画面にてボタンを2回押して有効化

GuardDutyの画面が表示されたら、まずは真ん中の[今すぐ始める]ボタンをクリックします。

すると、サービスのアクセス権限に関する注意書きが書かれている画面に遷移しますので、そこで右下の[GuardDutyの有効化]ボタンをクリックします。

以上で、GuardDutyが有効化され、検知結果画面が表示されます。なお、有効化した直後は以下の通り何も検知していませんが、30分もすれば何か表示されていると思います。

3.無料トライアル期間の確認

GuardDutyの左ペインにある「無料トライアル」をクリックすると、無料トライアル期間を確認できます。またこの画面から、実際に有効化した場合に、費用がいくらくらいかかるか確認できるみたいです。

また、同じく左ペインにある「設定」をクリックし、右ペインに表示された画面を下にスクロールしていくと、GuardDuty の停止や無効化をするボタンがあります。
簡単に無効化できそうですね。

いままでのところ、攻撃の検知は無し

いままでのところ、rootでログインしているので気をつけてねーというワーニング以外は出ていません。
WordPressのサーバに入れたmodsecurityには攻撃検知ログが結構でていたのですが。。。もう少し様子を見て見たいと思います。