K-ornata – ページ 34 – k2-ornata（個人的「やってみたこと」ブログ）

ロジクールのヘッドセット H111r のイヤーパッドが壊れたので Amazon で探してみた

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

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

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

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

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

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

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

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

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

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

<br />

AmazonのGuardDutyを有効化してみた（その３．メール通知）

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

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

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

１．Amazon SNSでトピックの作成

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

トピック名について

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

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

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

２．Amazon SNSでサブスクリプションの作成

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

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

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

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

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

３．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トピック」を選択後、以下のとおり設定します。
・トピック：１．で設定したトピック名
・入力の設定：インプットトランスフォーマー
・最初のテキストフィールド記入例：
{“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>”

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

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

４．GuardDutyのアラートを待つ

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

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

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

AmazonのGuardDutyを有効化してみた（その２．検知状況）

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

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

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

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

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

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

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

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

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

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

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

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

Affinity Photoで今後使ってみたいテクニック（雪を降らせる、その１）

YouTubeなどを見ているとAffinity Photoをつかったテクニックをいろいろ紹介していましたので、自分でもできるかいろいろ試してみています。

その中で今回は、以下のように砂漠に雪を降らせる操作をしてみました。（若干、手抜きなのでイマイチな感じになっていますが、許してください。）

雪のブラシを作成＆ぼかしをうまく使うのがポイント

今回はオリジナルのブラシを作成するという荒技？になります。また、次回の説明になりますが、複数のぼかしをうまく使わないと、やわらかい雪の感じはでてきません。（私もまだまだですが。。。）

１．雪の元となるjpegを作成する

500px × 500px程度で新規にドキュメントを作成し、以下のように大きさのことなる円を作成します。

そしてこれを[command]+[shift]+[option]+SでJPEGに書き出します。

今回は、snow.jpg という名前で書き出しています。

２．snow.jpg を新規強度ブラシとして取り込み

下図のとおり、Affinity Photoの右上にある４本線（赤矢印部分）をマウスでクリックし、表示されたメニューから「新規強度ブラシ」を選択します。

すると、以下のようにFinderが表示されますので、先ほどのsnow.jpg を選択します。

snow.jpg を選択後、下図の「ブラシ」タブを開き、一番下までスクロールさせると、snow.jpg をベースにしたブラシが作成されています。

なお、このままだと雪はかけない（雪が線のように繋がってしまう）ので、このブラシを右クリックして、「ブラシの編集…」を選択します。

すると、以下のようにブラシのダイアログが表示されますので、「一般」タブにて赤枠で囲った部分を調整し、ブラシでなぞったときに雪どうしがつながらないようにします。

ただし、これだけだと同じパターンの雪が描画されるだけですので、次に「ダイナミクス」のタブを開き、赤枠部分を「ランダム」に設定した上でチューニングします。
これで雪の間隔や方向、強弱をランダムにしながら描画することができるブラシが出来上がります。

これで「閉じる」ボタンを押すと、以下のように雪のブラシが取り込まれているのが確認できると思います。

この雪のブラシを選択し、ブラシの色を白にして、ブラシ[b]で画面をなぞってもらうと、白い雪がランダムに画面上に表示されます。

ただし、このままだとあまりにもゆきの粒がはっきりしてしまうので、ぼかしをつかって、雪のやわらかい感じと動いている感じを出す必要があります。

ちょっと、ページが長くなってしまったので、続きは別の原稿で説明させていただくつもりです。（Youtubeを見てもらってもいいですが。。「affinity snow」で検索すれば出てくると思います。）

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

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

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

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

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

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

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

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

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

２．通知設定とConfigへの権限設定

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

３．Configルールの設定

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

４．設定の確認と利用開始

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

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

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

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

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

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

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

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

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

６． Config設定後の請求書を確認してみる

約１時間前に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に必要なレコードを登録するだけで設定が完了します。

１．SES から自ドメインを登録

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

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

２．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コンソールの？）管理者のメールアドレスに、以下２通のメールが送られてきます。

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

３．自ドメインでのメール送信確認

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

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

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

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

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

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

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

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

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

Affinity Photoで今後使ってみたいテクニック（写真の融合）

YouTubeなどを見ているとAffinity Photoをつかったテクニックをいろいろ紹介していましたので、自分でもできるかいろいろ試してみています。

その中で今回は、以下のように２枚の写真を自然に融合させる方法を試してみました。

マスクの仕組みを理解するのがポイント

複数の写真を融合させるには、マスクの仕組みを理解するのがポイントになります。

１．融合させる１枚目の写真を読み込み

[command]+Oで１枚目の写真を読み込ませます。

２．融合させる２枚目の写真を読み込み

１枚目と同様に２枚目の写真を読み込ませます。

３．上位レイヤ（２枚目）をマスク

以下の様に、右側のペインから「レイヤーのマスク」を選択します。そうすると四角で囲ったように、上位レイヤに対してマスクがかかります。

４．グラディエーションツールでマスクにグラディエーションをかける

以下のとおり左のアイコンから「グラディエーションツール」を選択し、３．で作成したマスクにグラディエーションをかけます。

これで、上位レイヤーの写真が右下に行くほど薄くなりますが、まだ中途半端です。
これは、よく見ていただくとわかりますが、点線の中の線の右端の丸の中が黒ではなく灰色になっている為です。

５．マスクの灰色を黒にする

そこで、以下の通り赤矢印で示した右端の丸を選択し、青矢印で示してように（ちょっとわかりづらいですが。）黒を選択すると、綺麗に融合されます。
（右側のペインのマスクレイヤを良く見ていただくと、左上から右下にかけて、徐々に色が白から黒に変わっているのがわかると思います。）

マスクは黒色に近づくほど写真を透明にしていくと理解すれば、いろいろ応用できそうですね。

AmazonのGuardDutyを有効化してみた（その１．初期設定）

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

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

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

１．GuardDuty機能の呼び出し

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

２．GuardDuty画面にてボタンを２回押して有効化

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

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

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

３．無料トライアル期間の確認

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

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

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

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

WordPressサーバに導入したmodsecurityのログを確認する方法

modsecurity（WAF）をWordPressと同じサーバ上に導入できたものの、出力されたログファイルを生で読むのはなかなか厳しそうです。

http://k2-ornata.com/mod-security-install/

また、modsecurityのログを可視化してくれるjwallというツールがあるようですが、導入はなかなかむずかしそう（ubuntu用に提供されていない？）に感じています。
そこで、とりあえずコマンドラインで簡単にログの内容を確認する方法を記載しておきます。

コマンドラインでログを分析

Linuxのコマンドである、cat やgrep, sortなどを駆使することで、ログをいろいろな角度から分析できそうです。

１．ルールIDでカウント

以下のコマンドを利用することで、ルールID毎に何件検知されているかを確認することが可能です。

これを実行すると、以下の様な実行結果が表示されます。これで、ルールID毎の検知数が分かります。

＜コマンドの実行例＞
362 [id "990012"]
 88 [id "959151"]
 14 [id "990002"]
 12 [id "950120"]
  4 [id "960024"]
  2 [id "950005"]
  2 [id "950907"]

ちなみに各 sed の構文では以下の処理をしています。

sedの構文について

“s/^.*[id/[id/g“・・・行の先頭（^）から[idまで（.*[id）を、[idに置換
“s/”].*$/”]/g“・・・”]から行の最後まで(.*$)を、”]に置換

これにより、[id “XXXXXX”]のみを抽出しています。

２．送信元IPアドレスでカウント

今度は、通信の送信元でアラートをカウントしてみます。
なお私の環境の場合、AWSのゲートウェイでNATされている関係上、modsec_audit.logのBセクションに記載されている X-Forwarded-For のIPアドレスで調べてみました。　

＜コマンド実行例＞
 90 X-Forwarded-For: 44.224.22.196
 45 X-Forwarded-For: 122.97.215.50
 44 X-Forwarded-For: 103.86.49.187
 33 X-Forwarded-For: 106.161.128.84
 30 X-Forwarded-For: 44.225.84.206
 19 X-Forwarded-For: 106.161.129.59
 12 X-Forwarded-For: 195.54.160.121
 12 X-Forwarded-For: 106.161.131.223
  8 X-Forwarded-For: 5.101.0.209
  5 X-Forwarded-For: 198.71.239.46
  5 X-Forwarded-For: 106.161.117.191
  4 X-Forwarded-For: 66.249.79.211
  4 X-Forwarded-For: 66.249.71.97
  4 X-Forwarded-For: 131.72.236.178
  3 X-Forwarded-For: 91.234.217.2
  3 X-Forwarded-For: 80.82.78.104
  3 X-Forwarded-For: 210.212.250.45
  3 X-Forwarded-For: 198.71.238.22
  3 X-Forwarded-For: 194.31.64.180
  3 X-Forwarded-For: 118.157.150.165
  2 X-Forwarded-For: 97.74.24.222
  2 X-Forwarded-For: 97.74.24.201
  2 X-Forwarded-For: 97.74.24.140
--More--

IPアドレスを逆引きしたところ、一番多い 44.224.22.196 はアメリカのAmazon、122.97.215.50 は中国の China Unicom という通信会社のネットワークを使っている機器からのようですね。

こんな感じでもう少しmodsecurityのチューニングをしていきたいと思っています。