AWSでオートスケールする設定でAWS Configを使うときは注意

AWSで以前から気になっていたSecurity Hubを試してみようと思いたったが、1週間後にCost Explorerを見たら予想外にコストがかかっていて驚いた。

Security Hubそのものは初回30日間無料なのだが、Security Hubの稼働に必要なConfig (AWS Config)は無料期間なしなので試しと言っても費用がかかってしまう。ConfigはAWSのあらゆるサービスの操作ログと設定のスナップショットを取って、運用ポリシー（ルール）に反した設定が存在するときに警告を出したり、自動的に修復することができるらしい。Security Hubはこの仕組みを使ってAWS内の設定でセキュリティ上問題があるものを集約し表示するというもの。

で、AWSで操作しない限りConfigのログはそうそう増えないはずなのだけど、EC2でオートスケーリングするようにしているとそうではないのだ。インスタンスを作って起動して停止して削除してという操作のタイミングでいちいちConfigのログが増えていく。そして新しいログに対して問題があるかどうか審査がなされる。

Configの料金体系は「AWS アカウントに記録された設定項目あたり 0.003USD」と「ルール評価ごとに 0.001USD（最初の10万件）、0.0008USD（次の40万件）、0.0005USD（50万件超）」となっている。Security Hubが作成したルールは全部で191件あった。たった1週間で2万件ほどの記録がなされていた。2万件→60ドル→7000円くらい？オートスケーリングでインスタンスが増えたり消えたりするたびに課金されていたのだろう。具体的にどういうカウントになっていたかまだ調べ切れていないがConfigが集めたログはS3バケットに保存されるので時間があれば詳細を調べてみたい。

有料と言ってもそう高いものではないだろうと思っていたが、想定外のコストがかかってしまって驚いた。オートスケーリングが有効になっていると課金タイミングが増えて余分なコストがかかってしまうからだと推測した。

参考情報

自分の電話番号が詐欺サイトのサポートセンターとして掲載されていた件

始まりは突然に？

先月くらいから心当たりのない電話番号から着信がときどき来るようになった。

大方何かの勧誘かと思って取らずにいたのだけれど、先日何かの気が向いて取ってみることにした。すると突然「そちらで注文した車のパーツのことなんですが」と話し始めた。何のことかよくわからないが、とりあえず一通り聞いた後で「どこで注文されたんですか？」と聞いてみるとサイト名を教えてくれた。サイト名なのかドメインなのかよく聞き取れなかったが、どうやらその通販サイトで購入したらしい。それでその通販サイトに載っている電話番号に電話したとのことであった。

とりあえず自分は車のパーツ販売をしていないただの個人であることを伝え、電話番号を間違えているのではないかと伝えると相手も納得したのか、話は終わりとなった。

ここで終われば、ただの間違い電話だったんだなで終わるのだがそうではなかった。午後になって再度別の人から「そちらで注文した車のパーツの発送はいつなのか」という電話があった。これは穏やかではないなと思い、先ほどと同じようにサイト名を尋ねた。何度か聞き返しながら判明したのは「○○.xyz」というドメイン名だった。やはりさっきの人と同じようにこの電話番号が問い合わせ先として掲載されていると言う。電話先の人に同情しつつ、自分がそのサイトのオーナーではないこと、何の関係もない個人であることを伝え、商品が届かないということであれば警察に相談した方がいいのではないかと言ったことを伝えた。

突然のことで状況を呑み込めず驚いたようだったがすぐに状況を理解したようで、警察に相談する方向で話が進んだ。その際にこの電話番号を伝えても問題ないかと聞かれたのでもちろんと同意して話は終わった。

2人とも自分が詐欺サイトの被害者かもしれないのに、すんなりと納得してくれたのでよかったが、お金がおそらく戻ってこないことを思うとかわいそうに思う。どちらも善良そうな感じであった。似たような訛りがあったのは偶然だろうか。

サイトを見てみる

問題のサイトのドメインが分かったのでアクセスしてみることにした。自分のパソコンでアクセスするとセキュリティソフトにより、危険サイトの警告が出た。この時点でもうお察しである。

警告を無視してサイトにアクセスすると、どこかの通販サイトをまねたわけでもないCMSのデフォルトかのようなシンプルな通販サイトが表示された。車のパーツサイトというわけではなくありとあらゆるものを扱っているようだ（見かけ上は）。いったいどうしてこのサイトで購入しようと思うのだろうかとやや頭を抱えた。そもそもどうやったらこのサイトにたどり着くのだろう。世の中にはこういうサイトでも注文する人がそれなりにいるのですね。

ご丁寧に特定商取引法の表示もある。その問い合わせ先電話番号としてたしかに自分の電話番号が表示されていることを確認した。また、全ページのフッターにサポートセンターの記載があり、その電話番号も自分の電話番号となっていた。そりゃこれを見ればこの電話番号にかけますね。購入前に電話してればよかったのにと思わなくもない。

責任者氏名と所在地も書かれているがでたらめだろう。所在地にいたっては、都内らしき住所が書かれているが、検索してみたところその区にその町名は存在しないようだった。

さてどうするか。通報かな

いまのところ自分は何件か間違い電話がかかってきたというだけで、直接多大な被害を受けたわけではない。だからと言ってこの状況を放置しておきたくはないだろう。できれば自分の電話番号の記載をやめてほしいし、詐欺サイトの存在をしかるべき機関に届けて対処してもらいたいと思う。

自分が注文していれば詐欺の被害者として、消費者庁や生活相談センターや警察に相談したり被害届を出したりということになるが、自分の立場だとどうすればいいのか。

とりあえず#9110かなと思って電話をかけてみたがつながらないので別の手段を取ることにした。しばらく検索してみたが、自分の場合は警視庁のサイバー犯罪に関する情報提供から連絡すればよさそうなのでそうすることにした。

他にやることは

どうも詐欺サイトがCloudflareを使っているようだったので、Cloudflareの通報フォームからも連絡することにした。Commentsにはシンプルに"Stop this website."と書いた。

あとは無駄だと思いながらも、当該詐欺サイトのフォームと連絡先のメールアドレスにもこの電話番号の掲載を止めるよう連絡した。

すると…

翌日午前中に最寄りの警察署の生活安全課から電話があった。「相談」として承るとのことだった。「被害届」の扱いとはしないということだろう。特に目立った被害はないのでそれで同意した。警察として特にやれることはなさそうで、引き続き電話がかかってくるようなら電話番号の変更を検討するように言われたが、これは大きなお世話だろう。担当者はあまりこの手のことに知識がないようで、警告が出るのでアクセスできない、結果としてサイトの内容を確認できないとのことだった。また使われた電話番号は050のIP電話なのだが、携帯電話の番号なのかとも聞かれた。サイトについては別の部署などで詳しく調べるとは言っていたが。とりあえず警察内で一通りの扱いはしてもらえそうではあった。連絡があるとは思ってなかったので、思っていたよりはきちんと対応してもらえたという印象。

自分の中では昨日一通りの通報をして済んだことのつもりだったが、警察から電話があり、そのやりとりの中のアクセスできないの一言が気になったので、再度アクセスしてみることにした。すると、警告が出てアクセスできないとかではなく、確かにアクセスできない。どうもDNSレコードが削除されたようだ。Cloudflareへの通報が効いたのだろうか。そんな素直な会社には思えなかったが。サイトオーナーが逃げたということだろうか。

自分の電話番号の掲載が止まったという点では喜ばしいが、被害に遭った人の調査が難航するのではないかとやや困惑する結末となった。

追記

インターネット・ホットラインセンターにも通報していました。

あと、ウェブ魚拓を取ろうとしたけどrobots.txtによって禁止されていてできないとのことでした。

elFinderはPHPのpost_max_sizeとupload_max_filesizeを無視する

elFinderはブラウザで動作するファイルマネージャーで、サーバーやAWS S3やDropboxのファイルを扱えるツールである。サーバー側はPHPで動作するようになっている。

タイトルの「無視する」という表現は正確ではないが、アップロードするファイルの大きさを制限したいと思ったときに、サーバー側がPHPで動いているのだからphp.iniなどでpost_max_sizeとupload_max_filesizeを設定するのが普通の発想だと思うが、これが効かず、もっと大きなサイズのファイルもelFinderでアップロードできてしまう。なぜかと言うと、elFinderは分割アップロードに対応しているからである。

post_max_sizeとupload_max_filesizeは何か

どちらもPHPの設定項目で、post_max_sizeはPOSTする際のデータを受け入れ可能な最大サイズを、upload_max_filesizeはファイルをアップロードする際のファイルサイズの上限を定めている。post_max_sizeはそのPOSTでの合計データサイズなので、upload_max_filesizeをpost_max_sizeより大きくしても意味はない。複数ファイルを同時アップロードするときは、1個1個がupload_max_filesizeより小さくないといけないし、合計サイズがpost_max_sizeより小さくないといけない。普通に<input type="file">でフォームを作るとこの制限に従わなくてはいけない。

elFinderでは？

elFinderでファイルをアップロードする場合はこれらの制限を実質無視できることになる。もちろんpost_max_sizeかupload_max_filesizeのどちらかが0になっていて、一切アップロードができない設定の場合はelFinderでもアップロードはできなくなるが、ごく小さなファイルをアップロードできる設定になっていれば、elFinderはその設定を検知して、アップロード可能なファイルサイズに分割してアップロードしようとする（chunked uploading）*1。これによりどんなに大きいファイルでもアップロードできることになる*2

ではelFinderでアップロードサイズを制限したい場合は？

このままだと例えばelFinderにアクセス可能な人に悪意があったり、ふといたずらを思いついたりして、1TBのファイルをアップロードするとかも可能になってしまうので、アップロードできるファイルサイズの上限を設定しておいた方がよい。uploadMaxSizeという項目で設定できる。これはサーバー側に設置するphpスクリプト内で指定する。

 

PHPの方で上限を設定しているのにelFinderだとそれ以上のファイルもいくらでもアップロードできてしまう、なんで？？？となったので、ここに調べた内容をまとめておく。上限に引っかかってアップロードできない、困ったみたいな情報はいくらでも出てくるのだが、上限の設定が効かなくて困ったという話はあまり見かけなかった。おそらく分割アップロードをサポートし始めたのもわりと最近なのだろう。

*1:実際のところ、若干のマージンを取っているので、例えばpost_max_sizeが1とかだとアップロードはできない。

*2:こちらも実際はPHP_INT_MAXが上限となる。普通はその前にサーバーのストレージサイズが問題になるけど。

バグ修正のため2020年3月4日にLet's Encryptの証明書の一部が強制的に失効する件

Let's Encrypt に重大なバグが発覚。該当サイトは2020/3/4 までに対応が必須 - Qiita の件

慌ててメールボックスを見てみるとLet's encryptから「ACTION REQUIRED: Renew these Let's Encrypt certificates by March 4」というタイトルのメールが届いていました。差出人（FROM）は「[email protected]」でした。3月4日までにこのドメインの証明書をrenewしろってことですね。

対応としては --force-renew で間違いないようです。メール本文にもそう書かれてました。

Revoking certain certificates on March 4 - Help - Let's Encrypt Community Support によれば、2020-03-04 20:00 UTCつまり日本時間の3月5日午前5時から対象となる証明書を失効させる作業を行うとのことです。そんな重要なことはLet's Encryptのトップページにも載せてくれよ…。

 

 

 

 

 

 

 

AWS EC2でログイン手段を失った既存のインスタンスに自分のSSH公開鍵を入れる方法

  1. 対象のインスタンスから[ボリューム]をデタッチする
    戻せるように、どのボリュームがどのインスタンスのどのデバイス（/dev/xvda1など）にアタッチされていたのかはメモしておく。またはボリュームに分かるように名前を付けておく。
  2. ログイン可能な他のEC2インスタンスにアタッチする
    アタッチ先のインスタンスはrunningでも問題ないが同じアベイラビリティゾーンにある必要がある
  3. アタッチしたインスタンスにログインして、先ほどアタッチしたボリュームを手動でマウントする。
    例：sudo mount /dev/xvdf /mnt
  4. .ssh/authorized_keysに公開鍵情報を追加する
  5. アンマウントする
  6. デタッチする
  7. 元のインスタンスにアタッチする

AWS Route 53でGoogleのドメイン所有者認証をしつつ、SPFの設定も行う

先ほど

したがって、AWSのDNSサービスであるRoute 53ではTYPEにSPFが選べてしまうが選んではいけない。TXTにしなければならない。

と書いたが、Route 53ではTXTレコードは１ドメインに対して１つしか設定できない。

メールアドレスのドメインパートに使用しているドメインのTXTレコードにすでにGoogleのドメイン所有権確認のための値（"google-site-verification:xxxxxxxxxxxxxxxxxxxxx"）を設定済みの場合はどうすればよいか*1。
（TXTレコードを複数設定可能なDNSサービスであれば、TXTレコードを別に設定すればよい）

SPFレコードはTXTレコードとして設定しなくてはいけないのだから、ドメインの所有権確認をTXTレコードでやるのをあきらめて別の方法でやるしかない。
別の方法だと、Google Analyticsなどでもおなじみのドキュメントルートに指定されたファイルを設置する方法もあるが、CNAMEを設定する方法もあるのでこれを使う。

*1:Verify your domain with a TXT record - G Suite Admin Help

SPFを設定しようとしてタイプにSPFを使用してはいけない（TXTを使用する）

RFC 4408だとTXTレコードでもSPFレコードでもいいよ（互換性のためにTXTレコード推奨）という感じだったと思うが、RFC 7208では

SPF records MUST be published as a DNS TXT (type 16) Resource Record
(RR) [RFC1035] only.

https://tools.ietf.org/html/rfc7208#section-3.1

とTXTレコードに記述しなければならない（MUST）となっていて、SPFレコードに書く話はなくなっている。
理由みたいなのはhttps://tools.ietf.org/html/rfc7208#section-14.1に書かれている。

したがって、AWSのDNSサービスであるRoute 53ではTYPEにSPFが選べてしまうが選んではいけない。TXTにしなければならない。

余談だが、DNSのリソースレコードタイプ（Resouce Record Type）としてのSPFレコードとSPFの値としてのSPFレコードが混在していてとてもややこしい。今回の話をまとめると「SPFレコード（SPF値）はSPFレコード（RR Type=SPF）ではなくTXTレコード（RR Type=TXT）に書く」みたいなことになるのかな。

SPFに関してよく参照されるであろうSPF（Sender Policy Framework） : 迷惑メール対策委員会が書かれた時点（2010å¹´1月）ではRFC 7208（2014å¹´4月）は存在せず、この件については古い情報となってしまっているので注意が必要。