![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
概要 †
主な議題 †
雑多 †セキュリティ上では万全ではない（通信を傍受されたりフィッシング詐欺に遭ったりする危険性がある）ようです。それを防ぐ仕組みとしてサーバー側でHTTPSで必ず接続するようにとブラウザに指示するのが、HSTSの設定です。 Hypertext Strict Transport Security（HSTS） HSTSの設定は2回目以降のアクセスについてHTTPのURLをブラウザに打ち込んでも、HTTPSでアクセスさせる仕組みです。 しかし、初回のアクセスについては、HTTPでアクセスすることがあり得るので、セキュリティは万全とはいえない状態です。（万全とはいえないケースについてはこちら） プリロードHSTS そのため、HSTSをさらに確実にするために「プリロードHSTS（Preload HSTS）」という仕組みがあります。なんかめっちゃ頑張ってサーバ側で設定して、サーバからのレスポンスヘッダに一項目追加すると、できる。Apacheでmod_headersが使えるサーバーなら.htaccessかhttpd.confに一行書けばよい。Header set Strict-Transport-Security "max-age=31536000; includeSubDomains?; preload"。 PEM root.pemというのがroot認証のときに必要なものらしい。中身をみると、BEGIN CERTIFICATEのようなやつが書いてあって、あ、これがそうだったのねという感じになるね。 https://www.ecoop.net/memo/archives/guide-for-pem.htmlのようになっていて、これを知っていると、ログでPEM吐いてんなあとわかる。 証明書チェーンの全てを含む場合 テキストエディタで以下のファイルを開き、内容をコピーして .pemファイルに貼り付けます 発行されたサーバー証明書ファイル 中間証明書ファイル root 証明書ファイル .pemファイルには、上記のの順番で貼り付けてください。また、各証明書の開始タグと終了タグを省略することはできませんので注意してください。 x.509 証明書を発行するためのCAの構造を規定する規格 これ読んだほうが良さそう https://securityblog.jp/security_wordlist.html CAは公開鍵が正しいことを保証するもの。 オレオレ証明書は暗号化できているが、改ざんと通信相手が正しい保証が得られない。 Forward Secrecy(あるいはPerfect Forward Secrecy, PFS)は、全ての暗号化された通信を記録しておき、後からある期間の鍵を盗んだことができたとしても、それ以前に記録しておいた通信は復号できないという性質を指す。鍵交換にECDHEまたはDHEを使っている場合はPFSであると言うことができる。なお、ECDHE/DHEのEは"Ephemeral"のEである。 https://qiita.com/harukasan/items/fe37f3bab8a5ca3f4f92 これしっかりしている文章だからちゃんと勉強 クライアントが証明書の正当性確認するプロトコルはOCSP Staplingと呼ばれている。HTTPS通信を行う際には、証明書が失効していないか確認するため、OCSP Responderに証明書の正当性を確認する必要がある。HTTPS通信の度にOCSPリクエストを行わなければならないため、OCSP responderが低速であった場合、大きなボトルネックになる。 TLSの共通鍵通信を可能にするまでの流れを TLSハンドシェイクというらしい cert rotation HTTPSで通信するときに、サーバの証明書交換をdowntimeなしで行うための方法 サーバ側ではサーバ証明書情報を置く必要がある SSLは公開鍵で共通鍵を渡して通信する方法。 セッションはクッキーと似ていますが、必要な情報をクライアントではなくサーバ側に保存します。その為、よりセキュアに利用することができます。ここではセッションの使い方について解説します。 クッキーはサーバがユーザのブラウザのメモリに保存するというスタイル。 セッションは、サーバに必要な情報をメモして、セッションIDだけブラウザ側のクッキー「など！！」に保存してもらうスタイル。 悪い事例 †IoT †
怪しいセキュリティ対策 †
SSL/TLS †TLS Transport layer security TLSは、公開鍵暗号方式で共通鍵の受け渡しを行い、あとは受け渡した共通鍵を使って共通鍵暗号方式（秘密鍵暗号方式）でやり取りすることで、通信の安全性を高める仕組み SSL Secure sockets layer SSL, TLSはSSL 3.0までバージョンアップ語TLS 1.0に名前変更 TLS 1.2以前のものは多くの脆弱性がある、TLS 1.3はまだ1個しか見つかっていない。 TLSは証明書でなりすましを防ぎ、公開鍵方式で暗号化するもの。 SSLは1990年代中頃、当時の主要なブラウザ Netscape Navigator を制作していたNetscape社で開発されました。SSLプロトコルの最初のバージョンである「SSL 1.0」は、プロトコル自体に重大な欠陥があったため、公開されることはありませんでした。 次のバージョンである「SSL 2.0」が1994年11月にリリースされ、実際にブラウザへ実装されたのが 1995年3月にリリースされた Netscape Navigator 1.1でした。しかし、この「SSL 2.0」は外部のセキュリティアドバイザーに全く相談せずに開発されたため、のちに重大な脆弱性が発見されてしまいます。そのために、Netscape社は次の新たなプロトコル開発をしなければなりませんでした。 1995年11月に「SSL 3.0」がリリースされました。名前こそSSLとなっていますが、その設計は根本から見直され、これがのちに紹介する現在のTLSプロトコルの基本設計となります。しかし、「SSL 3.0」も2014年9月に仕様上の脆弱性（POODLE）が発見され、根本的な対処法としては「SSL 3.0」を無効化するしか方法がありませんでした。そのため、2015年6月にはIETF(インターネット技術タスクフォース)※によって「SSL 3.0」の使用は禁止されました。 1996年5月、SSLをNetscape社からIETFへ移管するために、TLSワーキンググループが結成されました。これは当時のブラウザにおいて、Netscape社のNetscape NavigatorとMicrosoft社のInternet Explorerの激しいシェア争いが行われる中、安全なインターネット通信を実現するためにセキュリティプロトコルとして広く使われ始めたSSLを、セキュリティ専門家を交えた第三者機関で開発するための措置でした。 1999年1月、TLS（Transport Layer Security）という名称で「TLS 1.0」がリリースされ、実質SSLからTLSへと移行しました。「SSL 3.0」との違いはわずかですが、両バージョンの互換性はありません。 2006年4月にはTLSの改良として「TLS 1.1」がリリースされ、それまでに発見された攻撃手法に対応することを目的としたセキュリティの強化が行われました。 2008年8月には現時点で最新の「TLS 1.2」がリリースされ、脆弱性のある古い仕組みの排除や、最新の暗号化に対応するなど、安全性を高める改良が行われています。 2017年12月現在、次のバージョンとなる「TLS 1.3」がドラフトとして提案されています。まだ正式な決定がなされていないため、細かな仕様変更が含まれる可能性はありますが、すでに一部のブラウザやWebサーバにて利用が可能となっています。古い脆弱な暗号化が大幅に無効化される予定となっており、安全性をさらに高める改良が行われるようです。 TLSは現在、1.2が推奨バージョンとされ、最新バージョンの1.3も2018年8月に正式リリースされている。SSL Labsの調査では、Webサイトの94％が既にTLS 1.2に対応しており、各社のブラウザとも、まだ1.0または1.1を使っている接続は1％に満たないと説明している。 AppleとGoogle、Microsoft、Mozilla Foundationは10月5日、それぞれのWebブラウザで、TLS 1.0およびTLS 1.1を2020年に無効化する計画を発表した。 Microsoftはこの問題に対し「2017年2月14日以降はSSLサーバ証明書についてSHA-1ハッシュアルゴリズムで生成されたものは受け入れ中止」暗号アルゴリズムに関しては、SHA-1が十分な安全性を確保することが難しくなった2010年問題が起こり、2013年にやっとRSA2048bitへの移行が完了した企業も多かったと思います。ですが、次はまた2017年までにハッシュアルゴリズムSHA-2への移行が必要になりました。現在SHA-2の寿命は2030年と予想されており、今TLS1.2に移行しハッシュアルゴリズムをSHA-2にしておけば、ひとまず安心出来ると言えるのではないでしょうか。 SSL 3.0以前、TLS 1.0, 1.1は、POODLEHeartbleed、FREAKなど既に発見されている脆弱性がありマジ危ない。2020年にはdeprecated SSLには複数の認証レベルがある。
SSLの通信方式に関する設定はサブドメイン単位で設定できるっぽい 「WebサーバーにインストールされているSSLサーバー証明書を確認」みたいな方法でSSLの確認ができる https://www.ibm.com/support/knowledgecenter/en/SS7MHN/Talent_Suite_Release_Notes_1_4_6/how_do_you_know_browser_supports_tls_ssl.html サポートしているSSLのバージョンとCypher Setは以下で可能 nmap --script ssl-enum-ciphers -p 443 home.wakatabe.com SSL certificates are made as a chain from root CA to user's (service's) certificate. 透明性の証明 証明書の誤発行を防ぐ新たな技術 パブリックなSSL証明書は、認証局(CA:Certification Authority)によって発行され、その内容が保証されます。 しかし、近年認証局が不正アクセスを受けて偽のSSL証明書を発行したり、誤って不正な証明書をSSL発行したりという事件がありました。 そこでGoogle社が考案したのが、不正なSSL証明書を早期に発見・検知するための仕組みであるCTを(Certificate Transparency)です。これは、現在RFC6922として規格化され、Google Chrome などが対応しています。 CTは認証局が証明書を発行する都度、全ての証明書発行の証跡を、第三者の監査ログに記載する仕組みです。主に、ウェブサイトの運営者やドメイン名の管理者が、その監査ログサーバ（以下「ログ））を確認することで、自分のドメインに対して不正な証明書や、ポリシー外の認証局からの証明書が発行されていないかを検証することができます。それにより利用者が不正に発行された証明書を信頼することを防止します。 CTはあくまで証明書の信頼性を高めるための追加の仕組みであり、これまでの証明書の検証の仕組みが無くなるわけではありません。 ログに証明書を提供すると、ログからはSigned Certificate Timestamp（SCT）と呼ばれるデータが返されます。SCTは、ログが特定の時間内（「Maximum Merge Delay (MMD)」と呼ばれます）に証明書データが格納されたことを保証するタイムスタンプ情報です。ウェブサーバなどのSSL/TLSサーバはログから取得したSCTを、証明書と一緒にブラウザなどのSSL/TLSクライアントに提示しなければいけません。SSL/TLSクライアントは、証明書とSCTを使って、ログの中にその証明書のデータが登録されているかどうかを確認することができます。 CT対応しなかった場合、Google ChromeでEV SSL証明書では2015年2月以降グリーンバーが表示されなくなり、OV SSLならびにDV SSL証明書では2016年6月以降警告が表示されます。 実はプライマリ・サーバとセカンダリ・サーバの違いは、ゾーン情報をローカルのゾーン情報ファイルから入手するか、ほかのDNSサーバ（プライマリ・サーバ）から入手しているかの違いでしかない。問い合わせ側は特に区別はしない（できない）。リゾルバは、通常は複数のDNSサーバからランダムに選択して利用することになる。 これを自ドメインに対する「オーソリティ（権限）」を持つと表現する。SOAレコードはドメインにおけるオーソリティを記述するレコードである。 ただし、より正確にはオーソリティを持っていると見なされるのは、上位ドメインのゾーン情報で、そのドメインのDNSサーバとして指定されたサーバ（NSレコードに記載されたサーバ）に限られる。ドメイン・ツリーに参加していないサーバが、いかにその情報を知っていると主張しても、外部からはそれが正しい情報かどうか確認できないからだ。 認証のためにCNAMEを指定させることもある。これはホストofijeoirj08uru08r3.google.hostingservice.comみたいなものにダイレクトさせて、そもそも SPF：実際に送られてきたIPに直接、あなたの住所としてありえるものはどれですか？と問い合わせる方法。複数IPから送る可能性があるので、問い合わせはinculdeみたいな形で書かれる。 SPF (Sender Policy Framework)とは、 電子メールの送信元ドメインが詐称されていないかを検査するための仕組みです。 送信側は、あらかじめ自ドメインの権威DNSサーバ上に自ドメインの送信者がメールを外部に向けて送出する可能性のあるメールサーバのIPアドレスの一覧を記述（公開）する。SPFの仕様は、 RFC4408(*1)で定められています。 インターネットでメール送信に使用されるプロトコルであるSMTP (Simple Mail Transfer Protocol)は、 差出人のメールアドレス(Fromアドレス)を自由に設定することが可能です。 このため、 送信元を偽った「なりすましメール」を簡単に送ることができてしまい、 これが迷惑メールに利用されてきました。 SPFは、こうしたメールアドレスにおけるなりすましを防ぐための技術の一つで、 DNSを利用するのが特徴です。 ドメインをSPFに対応させるには、 そのドメインのゾーンデータにSPFレコード(*2)という情報を追加します。 SPFレコードには、 そのドメイン名を送信元としてメールを送ってもよいサーバのIPアドレス等を記述します。 一方、SPFに対応したメール受信サーバは、 メールの受信時にそのメールの送信元となっているドメイン(*3)のSPFレコードを、 DNSで問い合わせます。 送信元のサーバがSPFレコード中で許可されていない場合は、 送信ドメインの詐称が行われたと判断して、 受信を拒否するなどの処理を行います。 つまりSPFは、送信元サーバのIPアドレスとDNSを利用して、 あらかじめ想定された送信元以外からのなりすましメールを検出できるようにする機構で、 より多くのドメインがこの仕組みに対応することで、 その効果が高くなります。 電子メールの送信者偽称を防ぐ送信ドメイン認証技術には、ここで説明する「Sender Policy Framework（SPF）」のほかに、「DomainKeys? Identified Mail（DKIM）」、「Sender ID」など様々な方式が標準化されている。その中でもSPFは、他の方式に比べて既存システムに影響を与えず早期に導入できる点が評価されている。 https://salt.iajapan.org/wpmu/anti_spam/admin/tech/explanation/spf/ SPFでは、送信元のIPアドレスを元に認証を行うため、認証時に送信元ホストが本来の送信元に属していないようなケースでは認証に失敗する。 Sample 6: メールを送信しないドメイン 管理しているドメインが全くメール送信しない場合には、“-all”を利用してその旨を公開できる。example.org. IN TXT "v=spf1 -all" これは面白い DDoS †(1)単純な嫌がらせ そもそもDDoS攻撃だけでは、マルウェアのように不正にデータを盗んだり、改ざんしたり、消去したりといったクラッキング行為を行うことはできません。 嫌がらせの動機は様々でしょうが、サイト運営者が困ることを目的としてDoS攻撃またはDDoS攻撃を仕掛ける人が一定数存在しています。 (2)妨害行為 競合サイトをアクセスしづらい状態にするなどなんらかの営利目的を持っての妨害行為としてDDoS攻撃を仕掛ける場合があります。ライバル企業の犯行の可能性が疑われることも珍しくありません。 (3)抗議活動 そのサイトの運営元に対するなんらかの抗議活動としてDDoS攻撃を仕掛ける場合があります。 政治問題に対する抗議活動として、DDoS攻撃を仕掛ける事例は過去に様々な国の政府を対象に実行されています。 (4)脅迫行為 企業などの特定の組織に対して、DDoS攻撃を事前に予告し、DDoS攻撃を引き換えにして身代金等様々な脅迫行為を行う場合があります。 特に2017年から仮想通貨サイトやFXサイトに対して、DDoS攻撃を悪用した脅迫行為が相次いでいます。 https://www.jpcert.or.jp/newsflash/2017092101.html (5)他のサイバー攻撃との併用 サイバー攻撃には、DDoS攻撃以外にも存在し、同時に複数のサイバー攻撃を用いることがあります。 例えば、DDoS攻撃を仕掛け、管理者がDDoS攻撃の対処をしている間に他のサイバー攻撃を行うなど、DDoS攻撃を目くらましとして使用される場合があります。 ・ネットインフラ支援サービス企業を狙ったDDoS攻撃(2016年) インターネットの基盤サービスを提供する企業を狙った大規模なDDoS攻撃攻撃が行われ、ツイッターやアマゾンだけでなく、ソニー、米決済大手ペイパル、ニューヨーク・タイムズなど米メディア大手、米動画配信大手ネットフリックスなどで障害が発生しました。 ・マルウェア「Mirai」を使用した、史上最悪規模のDDoS攻撃(2016年) 2016年10月にMiraiが行ったDDoS攻撃では、米国のセキュリティ情報サイトやDNSサービスを提供する企業が停止し、連鎖的にTwitterやSpotifyといったサービスも利用できなくなりました。 ・パレスチナ爆撃抗議事件(2012年) イスラエルによるパレスチナ攻撃に抗議したハッカー集団「Anonymous(アノニマス)」は、イスラエルによるパレスチナ攻撃の抗議活動として、イスラエル政府が保有する複数のサイトに対してDDoS攻撃を行ないました。この攻撃でイスラエル政府や銀行系を中心に、約600におよぶウェブサイトがダウンしています。 踏み台 †bastion hostを直訳すると要塞ホストだが、確かに踏み台は要塞ホストの一種と言える。 ただ、日本語で「要塞ホスト」と書いてしまうと、「踏み台」という意味は読み取れなくなるな。 AWSではbastion hostは踏み台と思えばいいみたい。 |
