インスタンスをEIP(固定IP)にしてWordPressのSEOが変わるか確認してみた

WordPressをAWSで立ち上げてから、インスタンスのIPはパブリックIPのままにしていましたが、これだとインスタンスを再起動する度にIPが変わってしまう為、SEO 上よろしくないのではないかとおもっていました。
そこで今回、IPを固定にするEIP(Elastic IP)に変えてみて、検索結果が上位にくるようになるか確認してみることにしました。

パブリックIPからEIPへの変更は非常に簡単

もしかしたら、EIPにするとDNSの情報も書き直さないとアクセスできなくなるのではないかとおもっていましたが、そんな心配は無用でした。
以下の手順でEIPを作成し、既存のインスタンスに紐づけるだけで完成です。

1.EC2の画面に移動

Elastic IPを設定する為に、EC2の画面に移動します。

2.EIPの作成

左ペインからElasitic IPを選択すると、以下の画面が表示されますので、右上にある、「Elastic IP アドレスの割り当て」ボタンを押します。

すると以下の画面が表示されますので、AmazonのIPv4アドレスを選択したまま、「割り当て」ボタンを押します。

これで以下の通り、EIPとして割り当てられるIPアドレス(下の例では18.X.X.X)が決まります。

3.EIPのインスタンスへの割り当て

次に、先ほどのIPアドレスをチェックボックスでチェックした後、右上の「Actions」と書かれているプルダウンから「Elastic IP アドレスの関連づけ」を選択します。

Elastic IPアドレスは必ずインスタンスに割り当てましょう。

割り当てしていない Elastic IP アドレスは課金されるらしいので、必ずインスタンスに割り当てておきましょう。 

すると、以下の画面が表示されますので、インスタンスのプルダウンからElastic IPを割り当てるインスタンスを選択し、「関連付ける」ボタンを押します。
プライベート IP アドレスも指定できるようですが、ここはオプションのようで何もしなくても勝手にプライベートIPアドレスが割当たるので、放っておいてよいようです。

これで以下の通り、インスタンスにElastic IPが割り当たりました。

パブリックIPアドレスから Elastic IPに切り替える場合、これで作業は完了です。DNSの設定変更などは不要で、いままでのドメイン名でインスタンス上で動いているWordPressにアクセスできました。

EIPに切り替えても。。。

いまのところWordPressへのアクセスは増えていないので、SEOは変わっていない気がします。。。ね。

おすすめのスーツについて(その1)

いままであまりスーツのブランドにこだわっていませんでしたが、銀座でやっていた「男の祭典」なるスーツのディスカウントイベントに参加し、定価が10万円近いスーツを買いました。
そしてそれ以来、やはりスーツは歳相応のものを着た方がよいのではないかと考えるようになりました。
なにより、朝スーツを着た時に気持ちが上がり、仕事をやる気になるので、投資しただけの価値はあるかと思います。

そこで最近私が気に入っているスーツのブランドを今後ピックアップしていきたいと思います。
すべてディスカウントの時やアウトレットで買ったものですので人気のあるデザインではないかもしれませんが、生地や仕立ては値段相応のものであり、着心地は抜群に良いです。

着心地や見た目は値段に比例します(耐久性はまた別の話)

最近、海外のテレビドラマSuitsをよくみています。その中で出てくる法律事務所は一流らしいので着ている服も一着20万円くらいするらしいし、それくらいの服を着ないと認められないらしいです。
しかしそんなに高いスーツはさすがに買えませんし、その半額の10万円のスーツであっても相当気に入ったものでなければ定価では買えません。

そこで、そこそこのブランドで安く買え、着心地や耐久性がいいものを以下に上げておきます。もし普段は量販店でスーツを買っているんだけども、ちょっと奮発して良いものを買いたくなった人は参考にしていただければと思います。

TimothyEverest

わたしが今持っているスーツで一番高いのが、このTimothyEverestというイギリスのスーツです。
このブランドのスーツは、生地が非常に滑らかで光沢があり、高級なスーツをきているという感覚が得られます。(これまで自分が着てきたスーツと比べてですが。。)

定価は大体、9万円〜ではなかったかと思います。

聞きかじった知識によると、イギリスのスーツは割と体にぴったりと合わせて作られているので、着ているとすごく引き締まった感じになるのが良いですね。

裏地もなかなか凝って手を抜いていないですね。

またこのブランドは、イギリスということもあって映画の007にもスーツを提供している点も気に入っている原因の1つです。(ダニエル・グレイグの007はかっこいいですよね。普段着はいまいちという噂もありますが。)

なお若干悪い点を言うと、生地の耐久性があまりよろしくないかなと思います。特にズボンのポケットに穴が空いたり、後ろのポケットの入り口が擦り切れやすい気がします。

銀座三越の「男の祭典」にLet’G0!

このブランドは銀座三越が非定期で開催している「男の祭典」でよくディスカウントセールしていることがあるのでお近くの人はぜひ行ってみることをお勧めです。だいたい半額の5万円くらいで買えるとおもいます。

MacのPythonをバージョンアップさせてみた

Pythonをあまり使ったことがない初心者ですが、諸事情でMAC OS上でPythonを利用とおもったところ、バージョンが古かったのでバージョンアップしてみました。
なお、本件の前提としてパッケージ管理システムHomebrewがインストールされていることが前提となっています。

意外とめんどくさいバージョンアップ?

さきほども言いましたとおりPython超初心者なので、単純にHomebrewでインストールするだけでしょとおもっていましたが、意外とめんどくさかったです。(実はわかってなかっただけですが。)

1.Homebrew でPythonをインストール

まず、以下のとおり、brew install pythonコマンドでインストールをしてみることにしました。(このときはデフォルトでpythonがインストールされているとは知らず。。)

その後、Python -Vコマンドで確認すると、2.7.16との表示がでましたが、どうも最新にはなってない模様です。(この2.7.16が、Catalina 10.15.1のデフォルトのようです。この後、理由が判明。)

2.pyenv でPythonをバージョンアップ

そこで、今度はPythonのバージョン管理ツールと思われるpyenvコマンドを使って、Pythonをバージョンアップさせることにしました。
ちなみに、pyenv も上図のとおり、Homebrew からインストールできます。

pyenv をインストールした後、.bash_profileを以下のとおりホームディレクトリに作成し、sourceコマンドで有効化します。

% cat .bash_profile
export PYENV_ROOT=”$HOME/.pyenv”
export PATH=”$PYENV_ROOT/bin:$PATH”
eval “$(pyenv init -)”

% source ~/.bash_profile

その後、pyenv install –listコマンドで利用可能なPythonのバーションを確認します。

上図のとおりPythonのバージョンがずらずらと表示されるので、その中から最新で安定しているとおもわれるものを選んで pyenv installコマンドでインストールします。今回は、3.8.3をインストールしました。

その後、pyenv versionsコマンドでバージョンを確認すると、system(たぶん、systemにデフォルトでインストールされているものの意味)に*印がついていたので、pyenv globalコマンドで3.8.3に切り替え、再度、Python -Vを打ってみたのですが、変わらずでした。

3.環境変数の見直し

どうも調べたところ、環境変数が足りないらしいことに気がついた為、以下の行を.bash_profileに追加し、再度、sourceコマンドで有効化しました。

export PATH=”$HOME/.pyenv/shims:$PATH”

その後、再度 Python -Vコマンドで確認すると、バージョンが上がっていることを確認できました!

どうも、$HOME/.pyenv/shims ディレクトリ配下に新しいバージョンのpythonが入っていたようで、そこにPathがなかっただけみたいですね。

結論

インストール方法によるpythonコマンドの保存先の違いは以下のとおりです。

Mac OSプレインストール・・・/usr/local/bin配下
Homebrewでインストール・・・/usr/local/bin配下
pyenvでインストール・・・$HOME/.pyenv/shims配下
 ※シンボリックリンクは/usr/local/opt/python/libexec/bin配下

結局、Mac OSに3つもPythonを入れてしまったようです。。。

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で頻発していたポートスキャンやブルートフォースが発生しなくなるはずですので、少し様子を見てみたいと思います。

ベルツノガエルのペットホテル(関東圏)

犬や猫のペットホテルはたくさんありますが、カエルさんのペットホテルはなかなかないですよね。
ということで、私が使ったことがあるペットホテルやペットホテルをやっている病院を紹介します。

1.ホームズ新川崎店の中にあるFeed On(川崎市)

ここは私が何度か使ったことがある熱帯魚店で、私が飼っているベルツノ さんもここで買いました。しかしながら、ここのお店の名前がFeed Onであることを今初めて知りました。😀

料金は1日950円と比較的お安くなっており、何よりここの店長さんがカエルを飼ったことがあるようなので、安心して預けられると思います。
また、ホームズの建物の中にあるということで、夏の暑さや冬の寒さは確実に凌げるのでこの点も安心しています。
預けた場合、売り物の動物の隙間(後ろの方)にこっそり置かれるようですので、管理状態もわかりやすいかと思います。

ただ、ここは店員さんがあまりいないらしく(店長さん以外あまりみた記憶がない)、店長さんも忙しそうなので、こまめに世話をしてもらうことはあまり期待しない方がいいかもしれません。
ベルツノ さんは大きくなると1週間に1回程度しか餌を食べないので、預ける前に餌をあげておけば、あとは預かってもらっている間にウンチをしないことを祈るのみです。

また、ここは電話もあるようですが、諸事情でつながらないことが多いので(1年前の話)、川崎以外に住んでいる人はあまりお勧めできないかもしれません。

2.small animal clinic(千葉市)

ここは小動物専門のお医者さんで、ベルツノガエルの診察もしてもらえます。私のベルツノ の背中にコブができたときは、ここで切除してもらいました。(2回も)
また今回の主題であるペットショップとしても、ここでカエルさんも泊めてもらえるらしいです。
私はまだペットホテルとしてここを使ったことはないですが、ホームページなどを見ると一泊1,500円で泊めてもらえるみたいです。

こちらのお医者さんもカエル好きの方らしく扱いになれているので、安心しておまかせできますし、何より小動物専門の病院&ペットショップというのは魅力的です。
通常は犬猫+小動物になっていると思いますが、そういった病院と比較するとかなりきれいで安全だと思います。
犬猫も受け付けていると、どうしても歳を取った犬猫がいて、たまに待合室でそそうをしてしまうこともあります。
いっぽうでこちらの場合は小動物専門ですので、みんはケージにいれて動物をつれてきており、一見、人間の病院かと思えるくらい待合室に動物感はありませんし、ちょっとおしゃれな感じです。(歯医者さん的な感じ?)

一方で、やはりこういう小動物専門のお医者さんはすくないらしく、予約をとるのが結構大変です。
病院の方であれば、1週間前くらいに電話すれば予約を取れると思いますが、ホテルの方は、予約時期がゴールデンウィールなど他の利用者と被りやすいせいもあると思いますが、なかなか予約をとりづらい感じです。
わたしも1度予約をとろうとおもいましたが、一杯でとることができなかったことがあります。

ペットホテルにベルツノ を預ける前の準備

ベルツノ さんを預けるときは、世話をしやすいようにプラケースに入れて、きれいにしておくと良いと思います。ケースがきれいだと世話をしてくれる方も心持ち大事に扱ってくれると思います。

また、預ける直前に餌をあげておくのがいいと思います。そうすれば1週間くらいは餌をあげる必要がなく、店員さんの負荷を減らせることができると思います。

あと、ケースには名前を買いてテープで貼っておくとよいとおもます。そうしておければ、同じベルツノ さんが泊まっているときに間違えられることもないと思いますし、お店の場合は売り物と間違えられることもないと思います。😁

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で探してみた

おおよそ2年半前に購入したLogicoolの H111 ステレオヘッドセットのイヤーパッドが(なぜか)片側だけボロボロになってしまったのですが、それだけでヘッドセットを買い直すのもいやだったので、イヤーパッドの交換品を探して見ました。

Logicoolの H111 ステレオヘッドセット

純正品が無くても大丈夫。汎用品は若干大きめに作られているかも。

まずAmazonで純正品のパッドがないか探してみたのですが、Logicoolの H111 ステレオヘッドセット自体、取り扱いをもうしていないようなので、早々に諦めました。

そこで汎用的なイヤーパットの交換部品がないか探してみたところ、以下の商品が見つかりました。

直径60mm以外に50mmというのもありましたが、ボロボロになったイヤーパッドを外して直径を測ってみたところ約60mmだったので、私は60mmのものを選択しました。

そして2〜3日後に到着。茶封筒に入って郵便受けに突っ込まれていたようで、これしか頼まなかったので、触った感じは封筒に何もはいっていないかのようだったらしいです。

ちなみに私は2セット(4個入り)を買ってしまいましたが、2個入りパターンもあるみたいですね。
実際はめてみた感じは以下のとおりです。

若干大きめに作られているようで、ちゃんと測ってみるとパッドは直径が65mmくらいありました。したがって少し内側は隙間がありますが、ぱっと見はちょうどよい感じですね。

嵌め込み部分(内側)の直径は以下のとおりだいたい40mmくらいですが、半分はめこんで、そのあと半分はすこしひっぱれば10mmくらいは伸びますので簡単に装着できました。

もしイヤーパッドを交換したいと考えているが、どれにすればいいか迷っている場合には、この記事を参考にしていただければと思います。

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ヶ月で見ると多少費用がかかるのかもしれませんが。。。

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