CloudFront Domain Hijacks under Attack
My blog has moved: https://vincentyiu.co.uk Update: To my attention in April, it appears that Mindpoint may have been behind the automated assigning of the hijackable instances. See https://www.mindpointgroup.com/blog/pen-test/cloudfront-hijacking/ This is great, but CloudFront’s engineers definitely missed a whole lot, so I’m not sure if they actually see the problem. Given that they have access
GitHub Pagesとwwwなしドメイン
wwwなしドメインをGitHub Pagesで運営しようとAレコードを使って設定すると、全てのリクエストが302 Foundで処理されるようになる。特に実用上の問題はないが、パフォーマンス上のデメリットは大きい。www付きで運営するのが手っ取り早いが、wwwなしでどうしても運営したい場合はCloudflare経由にするのがコストが低い解決法だろう。 CloudflareにはCNAME Flatteningという機能があって、これによりCNAMEレコードを使ってwwwなしドメインを設定できるようになっている。これを使って設定すると302 Foundによるリダイレクト経由になることを回避することができる。設定は特に(GitHub Pagesを使おうというような人には)難しいことはない。 GitHub Pages側が提供するwwwあり→wwwなしへの301 Moved Permanentlyによ
インフラの継続的デリバリー - naoyaのはてなダイアリー
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
