Hatena::ブログ(Diary)

思い立ったら書く日記

 

2016-10-01

セブンシスターズ(Seven Sisters)への旅路: ブライトン(Brighton) 経由

| 22:01 | セブンシスターズ(Seven Sisters)への旅路: ブライトン(Brighton) 経由を含むブックマーク

2016 年 9 月、セブンシスターズ(Seven Sister)を旅してきました。このセブンシスターズは、「Mr.ホームズ 名探偵最後の事件」や「映画けいおん!」などのロケ地になります。セブンシスターズに行く経路を調べるときに、様々なブログの情報を参考にしたため、僕も旅路の記録を残します。いづれセブンシスターズを訪れる方のお役に立てば嬉しいです。

はじめに

セブンシスターズへの旅路

僕の場合、ロンドン ヴィクトリア駅を出発して、鉄道・バス・徒歩の 3 つの手段でセブンシスターズを一望できる「Seaford Head view point」に辿り着きました。

  1. 鉄道: ロンドン ヴィクトリア駅(London Victoria) からブライトン駅
  2. バス: ブライトンから Seven Sisters Country Park
  3. 徒歩: Seven Sisters Country の Seaford Head view point へ

1. 鉄道: ロンドン ヴィクトリア駅からブライトン駅

まず、ロンドン ヴィクトリア駅から鉄道(Southern railway)でブライトンに移動します。僕の場合は、ヴィクトリア駅構内(下図の赤枠)でチケットを購入して、プラットフォーム 18 または 19 発(下図の紫色の枠)の鉄道に乗りました。ロンドンからブライトンまでは、約 1 時間掛かります(Southern railway の路線図(network map))。

f:id:kaito834:20160924200947p:image:w645:h303

引用元: VictoriaStationMap.pdf

チケット券売機では、行き先、片道(Single) or 往復(Return)、チケットの種類を指定してチケットを購入します。僕は下表のように指定して、31 £でチケットを購入しました。なお、Southern railway のウェブサイトからチケットを購入した場合も、同じ券売機で発券できるようです(参考ブログ記事)。

行き先Brighton
片道/往復Return
チケットの種類Anytime Day Return(当日中であれば時間指定なく復路の鉄道に乗れる)

チケットを購入したら、電光掲示板(Street View)で鉄道の時刻および出発プラットホームを確認して、そのプラットホームに向かいます。あとは停車中の車両に乗り、出発するまで待機します。ヴィクトリア駅発の Southern railway に 2 回乗った限りでは、定刻よりも数分遅れて車両が出発しました。


2. バス: ブライトンから Seven Sisters Country Park

ブライトン駅に着いたら、バス(Brighton & Hove Bus)で Seven Sisters Country Park に移動します。ブライトンのバス停「Sea Life Centre」(下図の赤枠)から 12 番線(12A または 12X)のバスに乗り、Exceat のバス停「Seven Sisters Park Centre」(下図の紫色の枠)で降ります。「Sea Life Centre」から「Seven Sisters Park Centre」まで約 1 時間掛かります(Brighton & Hove Bus 12 番線の時刻表)。

f:id:kaito834:20160924224614p:image:w532:h213

引用元: 12, Brighton - Eastbourne, Route Map

バス停に向かう前に、ブライトン駅の Travel Centre(下図の赤枠)で One day バスチケット、地図や時刻表などを入手します。Travel Centre で「ブライトン駅からセブンシスターズのバスチケットが欲しい」と伝えると、One day バスチケット(約 8 £)を購入できました。もし Southern railway のチケットをウェブサイトで購入する場合には、PlusBus を購入する方がバス代を節約できます(参考ブログ記事)。

f:id:kaito834:20160924221732p:image:w645:h303

引用元: http://www.nationalrail.co.uk/stations-and-destinations/stations-made-easy/brighton-east-sussex-station-plan

さて One day バスチケットは、購入時点では左下図のようになっています。One day チケットを使うためには、透明カバーをめくって、使用日の年月日をスクラッチして透明カバーを貼り付けます(右下図)。年月日を間違えないようにご注意を(僕は間違えてしまい、バスドライバーに訂正してもらいました)。また、Travel Centre に置いてある地図や時刻表の中では、A4 冊子の時刻表(左下図)が役に立ちました。少し荷物になってしまいますが、主要なバス停と通過予定時刻をオフラインですぐに確認できるからです。

|f:id:kaito834:20160925181530p:image:w200:h250|f:id:kaito834:20160925181528p:image:w200:h250

ブライトン駅での準備が終わったら、バス停「Sea Life Centre」(下図の赤枠)に向かいます。ブライトン駅から徒歩で 10 分程度掛かります。バス停の電光掲示板でバスが到着するまでの見込み時間を確認して、バスの到着を待ちます。Route: 12(12A または 12X), Destination: Eastbourne のバスが到着したら、ドライバーに One day バスチケットを提示して、バスに乗ります。

f:id:kaito834:20160924223533p:image:w323:h403

引用元: City Centre Bus Routes


3. 徒歩: Seven Sisters Country Park から Seaford Head view point

Seven Sisters Country Park に着いたら、あとは目的地に向かって歩くだけです。僕は、セブンシスターズのリーフレットの「Path to Seaford Head view point」(ピンク色の点線)と「Beach Trail」(橙色の点線)の 2 つのルートを歩きました。

f:id:kaito834:20160925214634p:image:w657:h457

引用元: p.2, Seven Sisters Leaflet

バス停「Seven Sisters Park Centre」は、ちょうど Visitor Centre の裏手(上図の赤枠)にあります。「Path to Seaford Head view point」ルートに入るためには、まずバスで来た道を戻って The Cuckmere Inn に向かいます。The Cuckmere Inn の駐車場付近に入り口があり、そこから Seaford Head view point に向かって歩きます。The Cuckmere Inn から南下した交差点(実際には三叉路)で外側のルートを選び、ところどころで写真を撮りながら 45 分前後で Seaford Head view point に着きました。この view point でしばらく眺めを堪能しました:) 帰りは Beach を経由する上図の内側のルートを辿って、Visitor Centre まで戻りました。Visitor Centre を戻ったときには、約 2 時間半が経過していました。

Visitor Centre で一息ついたら、今後は「Beach Trail」ルートに向かいました。Visitor Centre から道路を挟んだ向かい側に「Beach Trail」または「South Downs Way」ルートの入り口があります。入口から 30 分前後歩くと、Beach に着きました。Beach を横断すると、セブンシスターズの崖を真下から見上げることができます。セブンシスターズの大きさを体感でき、Seaford Head view point とは違った趣があります:)

リーフレットには明記されていませんが、Beach からセブンシスターズの崖に登ることもできます(上図の星印付近)。実際に登っている人もいましたが、勾配がきつく大分歩いた後だったため、崖を登ることを断念しました。Beach で小一時間セブンシスターズの崖を見上げたら、Visitor Centre に戻るとともに帰路につきました。

サイドストーリー:ブライトンに辿り着けずに Haywards Heath 駅で鉄道が止まった

旅路は以上ですが、ここでサイドストーリーを一つ。

この旅でロンドン ヴィクトリア駅から鉄道には 2 回乗りました。初めにヴィクトリア駅からブライトン駅への鉄道に乗ったとき、車両がブライトン駅まで行かずに、Haywards Heath 駅で止まってしまいました(Southern railway 全体がちょうど約一週間メンテナンス作業を行っており、この影響を受けたようです)。電光掲示板で表示されるブライトン行きが次々キャンセルされたため、その日はロンドンに戻りました*1

ヴィクトリア駅に戻るために、まず Bedford 駅行きの Tramlink で East Croydon 駅(下図の赤枠)まで移動しました。そして、East Croydon 駅でヴィクトリア駅行きの Southern railway に乗り換え、ヴィクトリア駅に戻りました。

f:id:kaito834:20161001210311p:image:w757:h533

引用元: Southern_Network_Map.pdf, Network Map by route

駅員さんに相談して Tramlink に乗りましたが、このとき乗り換えが必要なことを聞きとれていませんでした。そこで、Tramlink で隣に座っていた女性に「どうすればヴィクトリア駅に帰れるか」聞きました。このとき、下図をおかげで East Croydon 駅(または Gatwick Airport 駅)における乗り換えの必要性をようやく理解できました。

英語のスピーキング・リスニングが堪能であれば会話だけで十分でしょうが、そうでない場合には会話以外で共通認識を作れる地図が大事と痛感しました。「地図、大事」覚えた。

おわりに

だだっ広い原っぱから壮大な景色を眺める解放感はいいですね。普段の生活圏にない風景だからか、一時的に日常生活を忘れてしまいます。とりあえず特に何もない空間で無心になりたい方は、機会があれば是非。

*1:駅員さんからは「バスでブライトン行けるよ!」と言われましたが、下調べしていなかったことと、滞在日数に余裕があったため、ロンドンに戻りました

2016-08-22

IO-DATA 製レコーディングハードディスクにおけるクロスサイトリクエストフォージェリ(CSRF)の脆弱性が修正された

| 09:05 | IO-DATA 製レコーディングハードディスクにおけるクロスサイトリクエストフォージェリ(CSRF)の脆弱性が修正されたを含むブックマーク

2016 年 8 月 8 日、アイ・オー・データ機器のレコーディングハードディスクにおけるクロスサイトリクエストフォージェリ(CSRF)の脆弱性(JVN#35062083)が修正されました。2016 年 1 月 3 日、僕は HVL-A2.0 でこの脆弱性を発見し、IPA に報告しました。そして、7 ヶ月後に関連製品を含めて当該脆弱性が修正されました。

この日記では、この脆弱性について下記 4 点をまとめました。

  • 脆弱性があった機能
  • 再現手順
  • 製品開発者による修正
  • 報告から取扱終了までの時系列

脆弱性があった機能

レコーディングハードディスク「RECBOX HVL-A2.0」には、保存しているコンテンツを操作できる WebUI 機能(下図)があります。この WebUI にはユーザ認証がなく、この機能の URL にアクセスできれば誰でも利用できます。

f:id:kaito834:20160821123234p:image:w422:h227


当該 WebUI で動画コンテンツを選択して、[削除] (画面上部を参照) を実行すると、Web ブラウザが /dms/transfer_tool/api/remove に POST リクエストを送信します。HTTP Body の「id」パラメータは、動画コンテンツの識別子を指します。

POST /dms/transfer_tool/api/remove HTTP/1.1
Host: 192.168.0.220:55247
Content-Length: 11
Accept: */*
Origin: http://192.168.0.220:55247
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: http://192.168.0.220:55247/dms/doc/transfer_tool/transfer_tool.html?20151071356
Accept-Encoding: gzip, deflate
Accept-Language: ja,en-US;q=0.8,en;q=0.6
Connection: close

id=FS-13936

指定した動画コンテンツの削除に成功すると、当該製品は HTTP レスポンスコード 200 を応答します。

HTTP/1.1 200 OK
Server: Linux/2.6.31.8 UPnP/1.0 DiXiM/5.0
Date: Sun, 21 Aug 2016 03:21:44 GMT
Connection: close
Content-Type: application/json
Access-Control-Allow-Origin: *


この動画コンテンツの削除機能に CSRF の脆弱性*1が存在しました。この HTTP リクエストに秘密情報を含んでいません。また XMLHttpRequest における Origin ヘッダおよびカスタムヘッダの検証(参考1, 参考2)も実施していませんでした。したがって、当該製品の利用者が罠サイトを閲覧すると、任意の動画コンテンツを削除する CSRF 攻撃を受ける恐れがありました。

再現手順

手順 1 から 4 で、当該製品に対する CSRF 攻撃を再現できます。この CSRF 攻撃を実現するためには、攻撃者が「削除対象コンテンツ ID」と「当該製品の IP アドレス」を推測する必要があります*2

  1. 削除対象コンテンツが存在することを確認する
    • http://当該製品のIPアドレス:55247/dms/transfer_tool/api/browse?id=FS-4&starting_index=0&requested_count=0
    • パラメータ id の「FS-4」は、削除対象コンテンツを格納しているフォルダのコンテンツ ID を指す
  2. 罠サイトに実証コードを配置する
  3. 当該製品の利用者を罠サイトに誘導する
  4. 改めて手順 1. を実施して、削除対象コンテンツが存在しないことを確認する
削除対象コンテンツ ID

脆弱性報告時の動画コンテンツ ID の分布*3をふまえると、動画コンテンツ ID を総当たりに試行すれば、現実的に任意の動画コンテンツを削除できる可能性があると判断しました。

当該製品の IP アドレス

WebRTC 実装仕様を利用することで、当該製品の IP アドレスを特定できると判断しました。

まず当該製品は、初期設定で DHCP サーバから IP アドレスを取得するよう設計されており、当該製品と利用者の PC が同一 LAN に接続する使い方が一般的だと考えます。また、Google Chrome および Mozilla Firefox の WebRTC 実装には、JavaScript からローカルホストの IP アドレスを取得できる仕様があります*4。そこで、Web ブラウザが動作するローカルホストの IP アドレスを取得して、同一 LAN の IP アドレスに対して当該製品の固有情報の有無(例:特定 URI の画像ファイル)を試行すれば、当該製品の IP アドレスを特定できます。

実際に Buffer NAS に対する Exploit コードをもとに、実証コード:cve-2016-4845_csrf-delete-withWebRTC_poc.htmlを準備しました。

製品開発者による修正

当該製品の最新バージョン 2.04 を確認したところ、/dms/transfer_tool/api/remove に対する POST リクエストの HTTP Body に「token」パラメータが追加されていました。この修正によって、攻撃者がこの「token」パラメータの値を推測できない限り、CSRF 攻撃が成功しなくなりました。

POST /dms/transfer_tool/api/remove HTTP/1.1
Host: 192.168.0.220:55247
Content-Length: 81
Accept: */*
Origin: http://192.168.0.220:55247
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: http://192.168.0.220:55247/dms/doc/transfer_tool/transfer_tool.html?201607211648
Accept-Encoding: gzip, deflate
Accept-Language: ja,en-US;q=0.8,en;q=0.6
Connection: close

id=FS-1411&token=BQQGBgIPBwMi%2Fl6%2B4d4QwZyLDbj8Syiy9XPvxOMTMOAAIXC8c34b0g%3D%3D

報告から取扱終了までの時系列

年月日事柄
2016年1月3日IPA脆弱性を報告
2016年1月4日IPA から届出情報受信の連絡
2016年1月8日IPA から届出情報受理の連絡
2016年2月4日IPA から「JPCERT/CCによる製品開発者への連絡開始」の連絡
2016年2月20日IPA に追加の実証コードを送付
2016年8月3日製品開発者が当該脆弱性を修正したファームウェア 2.04 を公開
2016年8月8日JVN における脆弱性情報の公表

さいごに

脆弱性を修正いただいた(株)アイ・オー・データ機器、報告から修正および取扱終了まで調整いただいた IPA および JPCERT/CC、ご対応ありがとうございました。


参考情報

  • ブラウザハック
    • 9.3 クロスオリジンでの Web アプリケーションの特定, 第 9 章 Web アプリケーションに対する攻撃
    • フックしたブラウザの内部 IP アドレスの特定, 10.1 標的の特定, 第 10 章 ネットワークに対する攻撃

*1:厳密には CSRF の脆弱性と言えません。IPA安全なウェブサイトの作り方」およびOWASPにおける CSRF の定義では「ログイン状態のユーザ」を規定しています。しかし、この脆弱性はその定義を満たしません(当該機能にはログイン機構が存在しないため)。便宜上、この日記では CSRF の脆弱性と呼称します。

*2:この再現手順では削除対象コンテンツ ID を「FS-6411」、当該製品の IP アドレスを「192.168.0.220」としています。

*3:2016/01/02 時点で FS-108 から FS-8781 の範囲に 671 の動画コンテンツが分布していました

*4:2016 年 1 月 3 日報告時点で、Chrome 47.0.2526.106 m および Firefox 43.0.1 を使いローカルホストの IP アドレスを取得できることを確認済み

2016-06-05

ガンホー問い合わせフォームにおけるアップロードファイルに起因する脆弱性が修正された

| 20:54 | ガンホー問い合わせフォームにおけるアップロードファイルに起因する脆弱性が修正されたを含むブックマーク

2016 年 5 月 3 日、ガンホー・オンライン・エンターテイメント株式会社(以降、ガンホー社)に「République(リパブリック)」について問い合わせるとき、お問い合わせフォームに脆弱性を発見しました。同日中にガンホー社および IPA に報告したところ、同月 31 日、当該脆弱性が修正されました。

アップロードファイルに起因する脆弱性

要約

ガンホー社の問い合わせフォームでは、クエリストリングで Content-Type を指定できる実装でした。アップロードファイルを確認するウェブページで、この実装を悪用して、ウェブブラウザ上で任意のスクリプトを実行できました。

脆弱性があったお問い合わせフォーム

当該お問い合わせフォームでは、ユーザが問い合わせに関するファイルをアップロードできます(下図*1)。このアップロード機能では、ファイルの拡張子を検証していますが、ファイルの中身(マジックバイトなど)を検証していないようです。スクリプトを含む HTML ファイルを「a.jpeg」で保存すると、当該お問い合わせフォームに「a.jpeg」をアップロードできました。

f:id:kaito834:20160602011800p:image:w467:h202


お問い合わせを送信する前に、アップロードしたファイルをウェブページで確認できます。このウェブページでは、クエリストリングに「mime」パラメータを指定でき(左下図)、このパラメータの値が Content-Type ヘッダにそのまま出力されました。試しに mime=text/plain と指定すると、Content-Type: text/plain; charset=utf-8 と出力されました(右下図)。

f:id:kaito834:20160602011801p:image:w352:h170f:id:kaito834:20160602011803p:image:w352:h170

脆弱性の再現手順

下記の (a), (b) の手順で脆弱性を再現できました。

(a) 当該問い合わせフォームに下記のHTMLファイルを「a.jpeg」としてアップロードする

<html>
<head>
<title>test</title>
<script>alert(1);</script>
</head>
<body>
</body>
</html>

(b) 当該脆弱性のあるウェブページに遷移して、「mime」パラメータに「text/html」を指定する。この結果として、アラートダイアログがポップアップ表示できた(下図)。

f:id:kaito834:20160604010136p:image:w464:h190

この脆弱性による脅威

ガンホー社には、「contact.gungho.jp ドメインを使ったフィッシングサイトに悪用されること」を脅威としてお伝えしました。

ガンホー社による脆弱性の修正

2016 年 5 月 29 日、報告したウェブページで改めて再現手順を実施したところ、「mime」パラメータが削除されていました。このとき、Content-Type ヘッダには、image/jpeg; charset=utf-8 または text/plain; charset=utf-8 が設定されていました。

ウェブブラウザContent-Type ヘッダの値
Google Chrome 50.0.2661.102 m(左下図)image/jpeg; charset=utf-8
Mozilla Firefox 46.0.1image/jpeg; charset=utf-8
MS Edge 25.10586.0.0(右下図*2text/plain; charset=utf-8
f:id:kaito834:20160604013214p:image:w374:h236f:id:kaito834:20160604013212p:image:w432:h212

前述の手順で脆弱性が再現しなくなったものの、任意のファイルをアップロードできることは変わりません。このため、IE8 などのウェブブラウザではまだセキュリティ上の問題が発生する可能性があります(2016 年 1 月 13 日で IE8 のサポートが終了していますが)。そこで、ガンホー社に修正完了確認を問い合わせたときに、X-Content-Type-Options: nosniff を提案しました。実際に X-Content-Type-Options ヘッダを出力するかは、ガンホー社の判断次第になります。

発見から修正までの時系列

年月日アクション
2016年5月3日ガンホー社および IPA脆弱性を報告
同日ガンホー社から一次返信
2016年5月6日ガンホー社から「担当部署に連絡した」との返信
同日IPA から届出情報受信の返信
2016年5月10日IPA から届出情報受理の連絡
2016年5月11日IPA から届出情報をガンホー社に通知したとの連絡
2016年5月29日脆弱性が修正されたことを確認
同日ガンホー社に修正完了確認を問い合わせ
2016年5月30日IPA から修正完了の連絡
同日ガンホー社から問い合わせへの回答
2016年6月1日IPAガンホー社に「脆弱性情報および時系列を公表すること」の連絡を依頼
2016年6月3日IPA からガンホー社への情報展開および取扱い終了連絡
2016年6月5日この日記を公開

さいごに

脆弱性を修正いただいたガンホー社、報告から修正および取扱終了まで調整いただいた IPA、ご対応ありがとうございました。

*1:2016 年 6 月 2 日に取得したスクリーンショット

*2:2016 年 6 月 4 日に取得したスクリーンショット

2015-04-11

「Amazon Web Services パターン別構築・運用ガイド」を読んだ

| 15:04 | 「Amazon Web Services パターン別構築・運用ガイド」を読んだを含むブックマーク

2015 年 03 月 25 日に「一番大切な知識と技術が身につく Amazon Web Services パターン別構築・運用ガイド」(以降、パターン別構築・運用ガイド)が出版されました。著者の一人、佐々木 拓郎 氏のブログで興味を持ち、当該書籍を読みました。この日記では、感想と読書メモを記録します。

感想

AWS を使ったシステムを構築する、または AWS を使ったシステムを運用する技術者だけではなく、AWS を使ってシステムをレビューする技術者にも役に立つ書籍だと感じました。

僕は AWS を使ったシステムを構築または運用していませんが、AWS を使ったシステムをセキュリティの観点からレビューする場合があります。そのときには、AWS の仕様やセキュリティ機能などの知識が必要です。最終的には AWS 公式ドキュメントを確認しますが、AWS の全般的な知識があれば、どういった点を確認すればよいかポイントを絞れます。この書籍は、そういった全般的な AWS の知識を得る上でとても役に立ちます:)

類似した書籍には「Amazon Web Services クラウドデザインパターン実装ガイド」(以降、実装ガイド)(2013 年 02 月 03 日出版) がありますが、「パターン別構築・運用ガイド」では、「実装ガイド」でふれていない Elastic Beanstalk / Cloud Formation / Cognito などを使った構築例や IAM にも言及しています。また、セキュリティに関する言及も豊富です。例えば、「AWS のセキュリティ」という独立した章、AWS アカウント(通称 root アカウント) における MFA(Multi-Factor Authentication) を有効にすべき項目として紹介する*1、などです。

AWS 公式ドキュメントなどで詳細・不明点を確認するための道しるべとして、この書籍を活用するつもりです。著者の皆様、よい書籍を執筆していただき、ありがとうございました!

読書メモ

  • 当該書籍を読んで、気になった記述をピックアップおよび引用しました。
  • 主に AWS の仕様やセキュリティに関する事柄が該当します。
  • 斜体の文章は当該書籍からの引用です。
Chapter1 AWSの基本
  • pp.22-23 AWSネットワークとVPCネットワーク
    • AWS サービスを AWS ネットワーク、VPC ネットワークごとに分類
    • AWSネットワークはインターネットからのアクセスできるネットワークのこと
    • VPCネットワークはVPC環境内の閉じられたネットワークのこと
  • pp.24-27 Amazon Elastic Compute Cloud
  • pp.27-29 Amazon Elastic Block Store
    • EBSの暗号化
      • AES-256アルゴリズム
      • 暗号化オプションを有効にしたSnapshotを他のAWSアカウントと共有すること、AWS利用ユーザにパブリックに公開することはできない
  • pp.30-33 Amazon Simple Storage Service
    • S3の暗号化
      • サーバサイト暗号化(SSE), AES-256アルゴリズム
      • Amazon S3キー管理(SSE-S3)
      • クライアントキー(SSE-C)
      • AWS KMS(SSE-KMS)
    • S3のアクセス管理
      • バケットポリシー、ACL、IAMでの制御の3つ
      • 表 1-3-1 S3のアクセス管理の単位
  • pp.35-42 Amazon Relational Database Service
    • RDSインスタンスへのアクセスポート
      • RDSインスタンスへは、特定のポートとプロトコルでしかアクセスできません
    • RDSのログ
      • AWSマネージメントコンソール等からRDSのログを確認することができます
    • パラメータグループ
    • オプショングループ
  • pp.47-51 Amazon ElastiCache
    • パラメータグループ
  • pp.61-63 AWSの料金体系
    • 従量課金には、時間ベース、容量ベース、回数ベースの3つがあります
    • 容量ベース
      • ネットワーク課金の考え方としては、インとアウトがあります。外のネットワークからAWSへの通信をインと呼び、AWSから外部のネットワークへの通信はアウトと呼びます。インについては、基本無料です。アウトの通信に対して、1GBあたり幾らという計算の仕方で課金されます
Chapter2 AWSを利用する
  • pp.68-76 AWSアカウントの作成
    • MFA(Multi-Factor Authentication)の設定
      • AWSマネージメントコンソールにサインインして、最初に行うことはMFA(Multi-Factor Authentication)の設定です...特に、現在ログインしているアカウントはルートアカウントと呼ばれ、AWSに対するあらゆる権限を持っています。これが乗っ取られると、AWSのリソースが思うままに使われ、莫大な料金が請求されるだけではなく、最悪の場合、犯罪に利用されることもあります
  • pp.76-91 ユーザアカウントの作成(IAMアカウント)
    • アクセスキーの入手
      • ただし、同じアクセスキーは二度とダウンロードできないので、ダウンロードしたCSVファイルは注意して管理してください
    • IAMポリシー
      • ポリシーは、Managed PoliciesとInline Policiesの2種類があります
  • pp.116-117 Default-VPC
  • pp.118-132 Custom-VPCを作成する
    • VPCネットワークの作成
      • Tenancyで「Dedicated」を設定すると、EC2インスタンスを起動するホストサーバを指定(占有)できます。セキュリティやコンプライアンスの問題で、ホストサーバを他システムと共有することが許されない場合等に使用します
  • pp.133-136 AWS操作用の公開鍵・秘密鍵の作成(KeyPair)
    • AWS外部で作成した公開鍵のインポート
      • 表2-5-2 インポートできる鍵の制限
  • pp.137-142 Security Groupを作成する
    • Security GroupはAWSにおいてファイアウォールの役割を果たします。Security GroupはWhite List方式なので、「何を許可するのか」のみを指定できます。何も指定しなければ、全てを拒否することになります
  • pp.159-162 Elastic IP(EIP)の利用
    • EC2に割り当てることのできるグローバルIPには、2種類あります。1つは、先ほど利用したパブリックIP、もう1つがElastic IP(EIP)です
  • pp.163-167 ELBサービスの詳細
    • External-ELBとInternal-ELB
    • SSLターミネーション
    • スティッキーセッション
      • スティッキーセッションとは、同じユーザからきたリクエストを同じインスタンスで処理させるようにする機能です。ELBのスティッキーセッションは、ELBが独自に発行するCookieを利用する方式と、アプリケーションが発行したCookieを利用する方式の2種類が選択できます
    • ログ取得機能
      • ELBで処理したリクエストのログを取得することができます
Chapter3 パターン別構築例
  • pp.233-239 Elastic Beanstalkを利用したロードバランシングとHTTPSサイトの構築
    • ELB、RDS、Auto Scalingの設定変更
      • SSL証明書は前節でアップロードした証明書を利用します...証明書をアップロードしたのはELBの画面ですが、AWS側ではIAMのなかに保存されています
  • pp.256-263 CloudFrontとの連携
    • 表3-3-4 Distributionの設定(Default Cache Behavior Settings)
      • Forward Cookies
      • Forward Query Strings
      • Restrict Viewer Access
    • 表3-3-5 Distributionの設定(Distribution Settings)
      • Logging
  • pp.275-278 Auto Scaling使用時のEC2インスタンスの初期化処理
  • pp.327-331 EC2インスタンスにメールサーバを構築する
    • メール送信に必要な準備
      • AWSでは、不適切なメール(スパムメール等)の送信に利用されることを防ぐため、パブリックIPやEIPから一定以上のメールが送信できないように制限されています。また、パブリックIPやEIPは原則としてRBL(Real-time Blackhole List)に登録されています。これらは不用意に不適切なメール送信を防ぐことを目的としています
  • pp.342-348 Cognitoによるユーザ認証と2Tierアーキテクチャ
    • Cognitoは、モバイル向けに設計されたAWSの認証・認可のサービスです。Cognitoを利用することにより、アクセスキーとシークレットキーを利用しない認証の仕組みを実現できます
    • Cognitoを中心としたユーザ認証とアクセス認可
      • 構成要素としては、Identity Providerによる認証と、CognitoによるCredentialの発行、IAMロールによる権限の付与の3つの要素になります
      • Cognitoの機能は従来から提供されていたSTS(Security Token Services)を利用したWeb Identity Federationと非常に似ています。Cognitoの内部的には、STSを利用しているというところは同じで、認証やロールの設定等がより簡単に使えるラッパー的なAPIと考えることができるかもしれません
Chapter4 AWSのセキュリティ
  • pp.365- AWSのアカウント種類
    • IAMポリシー
      • AWSが最初から設定しているポリシーをAWS Managed Policiesといい、各ユーザが独自に作成したポリシーをCustomer Managed Policiesといいます
      • IAMマネージドポリシーは、2015年2月に提供された新しいポリシーの管理方法です。IAMユーザやグループ、ロールといった各役割に付与する権限を、オブジェクトとして管理できるようになりました...これまでのポリシー管理方法は「マネージドポリシー」に対して、インラインポリシーとよばれます
Chapter5 管理と運用
  • pp.430-431 AMIの運用方法
    • AMIのオンライン取得
      • AMIはEC2インスタンスが稼働している状態でも取得することは可能です
  • pp.432-435 AWSのサービスログ/操作履歴のログを収集保存する
    • AWSサービスのログを収集する
      • S3のログの注意点としては、2015年2月現在では、ベストエフォート型で全てのアクセスログが完全に出力するという保証はありません。また、ログ出力はリアルタイムではなく、少し遅れて出力されます

2014-11-29

Error "server certificate change is restricted during renegotiation" on Burp Suite Free Edition v1.6

| 16:07 | Error "server certificate change is restricted during renegotiation" on Burp Suite Free Edition v1.6を含むブックマーク

The following errors happened when I used Burp Suite Free Edition v1.6 with upstream proxy; @ posted an image of these errors. Thanks for @anshuman_bh and @, I have known solutions for the errors. And, I blogged this entry for someone who may face the errors.

Attempting to auto-select SSL parameters for <FQDN>
Failed to auto-select SSL parameters for <FQDN>
javax.net.SSLException: server certificate change is restricted during renegotiation
server certificate change is restricted during renegotiation

Solution

  • Use latest Burp Suite

Burp Suite v1.6.07 applied a workaround related to the errors by @Burp_Suite (tweet). If you use Burp Suite Free Edition, I use, you cannot update to date soon. Then you can do some workarounds.

Workarounds
  • Use Burp Suite without upstream proxy by @anshuman_bh (tweet)
  • Use Java 1.7_67 and earlier version; it is bad for security reason.
    • The errors happened with Java 1.7_71 .
    • I confirmed that it was not the errors Burp Suite with Java 1.7_67 .
  • Use Burp Suite with OWASP ZAP by @ and @ (tweet)
    • Burp Suite -> OWASP ZAP -> upstream proxy