インフラエンジニア勉強雑記

インフラ技術に関して勉強したメモを残したものです。誤っている内容があればコメントもしくはメッセージでお知らせいただけると助かります。

Linux Chronyd(旧ntpd)に関して 概要・設定方法に関して

1.概要

1.1.NTPとは

NTP(Network Time Protocol)とはサーバやPCの時間を上位のNTPサーバと同期するためのプロトコルです。UDPを使用し、ポート番号は123です。
stratumと呼ばれる階層構造を撮っており、0~16で設定可能です。stratum 0は原子時計GPSなどを使用しており、誤差はほぼ無いと言っても問題ありません。最下層のstratum 16から時刻を同期することはできません。基本的にstratum 0から個人が取得することはできません。
以下が公開されているNTPサーバの例となります。

1.2.NTPの利用目的

サーバやPCなどはハードウェアクロックを参照して、時間が設定されます。仮想マシンの場合はハイパーバイザの時間と同期することが多いです。(設定で変更が可能です)
ただし、ハードウェアクロックを使用していると次第にズレが生じてきます。サーバ間の連携時に時刻が同期されていないとシステムが正常に動作しない可能性もあるため、導入はほぼ必須となります。
以下がインフラシステムにおけるNTPが必須な環境の例です。

  • HAを構成しているBIG-IP:HA機器間で時間がずれているとHAが構成できません。

  • ADサーバとクライアントPC:ドメインに参加しているPCは基本的にNTPの同期先がADサーバとなりますが、NTPの導入は行いましょう。クライアントPCとAD間で5分以上の差があるとLDAP認証に失敗します。

  • ログサーバ:ログを保管している場合、各機器のタイムスタンプがずれていると切り分けに時間を要する可能性があります。

1.3.動作

NTPの動作する時の時間計算の方法などは別の記事で説明します。
NTPでは時刻を同期する際にstepモードとslewモードで動作します。

  • stepモード:NTPサーバーから取得した時刻情報でシステム時刻を即時補正

  • slewモード:NTPサーバーから取得した時刻情報でシステム時刻を徐々に補正

1.4.閏秒の対策

閏秒とは協定世界時UTCに対して、世界時UT1との差が0.9秒以内に収まるように挿入される1秒のことを指します。
UT1は地球の自転を基準にした時刻系です。実際の1日と原子時計の1日を修正するための秒となります。
この1秒で毎回世界中のシステム管理者たちは事前に調査を行います。自身のシステムのNTPが変動することでシステムの再起動などが発生する可能性があるからです。また、事前にベンダからパッチなどが提供されることもあります。
一番最近閏秒が挿入されたのは2017年1月1日0:00(UTC)です。日本時間だと午前9時となります。

  • Windowsの場合:閏秒が挿入されても次の時刻同期時にstepモードで修正します。

*RHELの場合:閏秒を処理しますが、カーネルによってはバグがあり、システムハングアップなどの可能性があります。

1.5.クローズドなネットワークの場合

インターネットと通信できない場合は通常のNTPサーバを上位と同期しないで設置したり、専用のアプライアンス製品を導入することがあります。
例としてセイコーがあります。電話線を使用して時刻同期を行えたり、GPSを使用して時刻同期を行うことが可能です。
タイムサーバー | セイコーソリューションズ

2.Chronydの概要・設定方法について

2.1.概要

ChronydはLinuxのバージョン7から標準となったデーモンで、NTPクライアントおよびNTPサーバの機能を有していますとなります。Linuxのバージョン6まで使用されていたntpdはyumを使えばインストールできますが、Chronydの方が改善されているので、こちらを優先して使用しましょう。
ntpdより時間をより高速に、より高い精度で動機が可能です。

2.2.設定方法

設定ファイルは/etc/chrony.confです。以下はデフォルトの/etc/chrony.confです。
主要そうな部分だけ説明していきます。

2.2.1. server

問い合わせ先のNTPサーバを設定できます。

server ntp.nict.jp
server 192.168.0.1

2.2.2.allow

NTPサーバとして動作する際に、アクセスを許可するクライアントを指定します。

allow all #全て許可する場合
allow 192.168.0.0/24 #特定のネットワークからのみアクセスを許可する場合

2.2.3.cmdallow

上記のallowと似ていますが、chronycコマンドを実行できるネットワークを指定可能です。
デフォルトだとローカルホストのみ有効になっているので、この設定は基本的にいじらなくても問題ないです。
使用する場合はbindcmdaddressコマンドと併用する必要があります。

cmdallow all #全て許可する場合
cmdallow 192.168.0.0/24 #特定のネットワークからのみアクセスを許可する場合

2.2.4.dumpdir

時刻の変動割合を計算するためにchronydでは測定履歴を保存する必要があります。設定ファイル内のdumponexitやchronycのdumpコマンドを使用して測定履歴を保存したい場合は本設定で保存先のディレクトリを設定する必要があります。

dumpdir /var/log/chrony

上記設定を入れてダンプを取得すると、NTPのソースIPアドレスが1.2.3.4の場合は/var/log/chrony/1.2.3.4.datに保存されます。

2.2.5.dumponexit

本記述があると、プログラムの終了時に記録された時間ソースの測定履歴をdumpdirで定義したファイルに保存します。

dumponexit

2.2.6.local

上位のNTPサーバと同期していなくても、同期しているように振る舞います。インターネットと通信できない環境でNTPサーバが必要となった場合などに使用します。

local stratum 10 #このNTPサーバは上位NTPサーバと同期していなくてもstratum 10としてクライアントからは確認できます。

2.2.7.log

本設定項目では、特定の情報を記録することを示します。ログファイルは、logdirで指定されたディレクトリに書き込まれます。列の意味を示すためにバナーがファイルに定期的に書き込まれます。 rawmeasurements、measurements、statistics、tracking、rtc、refclocks、tempcompなどが設定可能です。

log measurements statistics tracking

2.2.8.logdir

ログが出力されるディレクトリを指定することができます。

logdir /var/log/chrony

2.2.9.makestep

通常chronydは、必要に応じてクロックを遅くしたり速くしたりすることで、システムに時間オフセットを徐々に修正させます。 状況によっては、システムクロックが大幅にずれているために、このスルー処理にシステムクロックを修正するのに非常に長い時間がかかることがあります。
chronydでは起動してからしばらくstepモードでシステム時間を修正することができます。
起動してから①何秒のズレが生じているか、②起動してから何回目の同期までstepモードにするかを設定できます。

makestep ① ②
makestep 1.0 3 #起動してから1秒以上のズレが生じている場合、3回までstepモードで時刻補正を行います。

2.2.10.maxupdateskew

Chronydは自身が時刻ソースに対してどのくらい早いまたは遅いかを調べます。またその値の誤差範囲を推定します。誤差の範囲が大きすぎる場合は、測定値がまだ安定していない、もしくは 推定利得または損失率があまり信用出来ないことを示している可能性があります。 本設定ではこの推定値が信頼できるかできないかのしきい値を設定します。 一般的に電話回線を介したサーバへのダイアルアップ接続の場合は100、LAN上のコンピューターの場合は5または10です。なおデフォルトだと1000です。

maxupdateskew 10

2.2.11.rtcsync

rtcsyncディレクティブは、システム時刻が定期的にRTCにコピーされます。
Linuxでは、RTCコピーはカーネルによって11分ごとに実行されます。
macOSでは、システムクロックが同期状態にあるとき、chronydは60分ごとにRTCコピーを実行します。

他のシステムではこのディレクティブは何もしません。

2.3.確認用コマンド

時刻同期ができているかは基本的にchronydを使用して確認を行います。

2.3.1.時刻同期状態の確認

$ chronyc sources

2.3.2.chrony トラッキングの確認

$ chronyc tracking

2.3.3.クライアントの情報の確認

$ chronyc -a clients

2.3.4.RTCなどの同期状況

$ timedatectl

BIG-IP ASMについて③ DoS Protectionの設定方法

※編集中

 

1.Preventing DoS attacks on applications

1.1.DoS protection for applications

①「Security」→「DoS Protection」→「DoS Profiles」をクリックします。

②「Create」をクリックします。

③「Name」にプロファイル名を入力して「Finished」をクリックします。

④「DoS Profiles」のリストに作成されたリストが追加されます。プロファイル名をクリックし、「Application Security」タブをクリックします。

⑤「General Settings」の「Application Security」で「Edit」をクリックして「Enabled」のチェックボックスにチェックを入れます。

f:id:light-spoqz:20190307220909p:plain

⑥「Heavy URL Protection」を設定します。どのURLを対象とするか、対象外とするか、自動検知を使用するか選択が可能です。別項で詳細を説明します。

⑦「Geolocations」を設定します。「Edit」をクリックして以下の設定を行います。

  • Geolocation Blacklist:アクセスを拒否したい国を設定します。
  • Geolocation Whitelist:アクセスを許可する国を設定します。それ以外の設定で攻撃を検知してもアクセスを許可します。
  • How to detect attackers and which mitigation to use:Stress-basedやTPS-based Detectionで検知した国に対しての低減方法を設定します。

設定が完了したら「Close」をクリックします。

DoS攻撃などを検知した場合にiRuleを使用したい場合は「Trigger iRule」で設定をします。

⑨動的に新しいコンテンツをロードする1ページからなるアプリケーションをよりよく保護するには、「Single Page Application」を有効にします。

⑩多数のURLを取り扱うには「URL Patterns」で類似のURLの論理セットを作成できます。「Not Configured」をクリックしてURLのパターンを入力します。(例:/product/*.php
次にシステムは、複数のURLを1つにまとめたURLパターンを調べます。他の同様のURLから統計情報を集計することにより、アクセス頻度が低いURLに対するDoS攻撃をより簡単に推測できます。

⑪パフォーマンスの高速化を使用する場合は、「Performance acceleration」で使用するTCP fastL4プロファイルを選択します。
プロファイルは「Local Traffic」→「Profiles」→「Protocol」→「Fast L4」で作成します。

⑫「Update」をクリックすると設定が保存されます。

1.2.Creating a whitelist for DoS protection

①「Security」→「DoS Protection」→「DoS Profiles」をクリックします。

②プロファイル名をクリックします。

③特定の信頼されたアドレスに対するDoS攻撃のチェックを省略するには、ホワイトリスト設定を編集します。

  • 画面右側の「Address Lists」で、「+」をクリックします。
  • 下の「Property」で、名前を1つずつ入力し、DoS攻撃の有無を調べる必要のない信頼できるIPアドレスまたはサブネットを入力して、「Add」をクリックします。(最大20個のIPアドレスを追加できます。)
  • 完了したら、「Update」をクリックします。新しいホワイトリストがアドレス一覧に追加されます。
  • 新しいホワイトリストを使用するには、「Default Whitelist」の後に、追加したホワイトリストの名前を入力します。

④デフォルトのホワイトリストではなく、HTTPトラフィック用に新規にホワイトリストを作成する場合は、「Override Default」を選択し、デフォルトのホワイトリストと同じようにホワイトリストを作成します。
⑤完了したら、「Update」をクリックします。

1.3.Proactive Bot Defenseの設定

 Proactive Bot Defenseを使用するためにはクライアントのブラウザがJavaScriptを受け入れる必要があります。また、この機能はDNSの逆引きを行うため、DNSサーバとDNSゾルバを設定する必要があります。

WebサイトでCross-Origin Resource Sharing(CORS)を使用している場合、Proactive Bot Defenseには制限があります。

①「Security」→「DoS Protection」→「DoS Profiles」をクリックします。

②プロファイル名をクリックし、「Application Security」タブをクリックします。

③「General Settings」をクリックし、「Application Security」が「enable」となっていることを確認します。

④「Proactive Bot Defense」をクリックします。

⑤「Operation Mode」を使用するタイミングを設定します。

f:id:light-spoqz:20190307220532p:plain

⑥「Block requests from suspicious browsers」設定では以下の設定を行います。

  • Block Suspicious Browsers:疑わしいブラウザをブロックしたい場合は有効にします。
  • CAPTCHA ChallengeCAPTCHAチャレンジを送信したい場合は有効にします。

CAPTCHA Setting」をクリックしてCAPTCHAレスポンスを変更することもできます。 

⑦「Grace Period」設定では、システムがボットをブロックするまでに待機する秒数を入力します。デフォルト値は300秒です。
⑧「Cross-Domain Requests」設定ではCross-Domain Request(埋め込み画像、CSSスタイルシートXMLJavaScriptFlashなどのHTML以外のリソースに対するリクエストなど)を検証する方法を指定します。Cross-Domain Requestは、HostヘッダーとReferrerヘッダーの異なるドメインを持つリクエストです。

設定 概要
Allow all requests 単純なチャレンジに合格した場合、有効なcookieを使用せずに、別のドメインによって参照されているHTML以外のURLに到着する要求を許可します。システムは、HTTPリダイレクトやcookieなどの基本的なブラウザ機能をテストするためのチャレンジを送信します。
Allow configured domains; validate in bulk このセクションで構成されている他の関連する内部または外部ドメインへの要求を許可し、事前に関連ドメインを検証します。関連サイトドメインへのリクエストには、いずれかのサイトドメインからの有効なCookieを含める必要があります。外部ドメインは、簡単なチャレンジに合格すれば許可されます。 Webサイトがあまり多くのドメインを使用していない場合はこのオプションを選択してから、それらすべてを以下のリストに含めます。
また、WebサイトでCORを使用している場合は、このオプションを選択してから「Related Site Domains」リストでWebSocketドメインを指定します。
Allow configured domains; validate upon request 要求時に検証このセクションで設定されている他の関連する内部または外部ドメインへの要求を許可します。関連サイトドメインへのリクエストには、メインドメインからの有効なCookieが含まれている必要があります。外部ドメインは、簡単なチャレンジに合格すれば許可されます。 Webサイトで多数のドメインを使用している場合は、このオプションを選択し、下のリストにメインドメインを含めます。

 「Allow configured domains」を選択したら、アクセス先のリソースとして「Related Site Domains」を加える必要があります。また、アクセス元の外部サイトとして「Related External Domains」を設定します。

⑨「URL Whitelist」設定で他のドメインからアクセスを許可するリソースURLを追加します。/index.htmlの形式でURLを入力し、「Add」をクリックします。ワイルドカードはサポートされています。

⑩完了したら、「Update」をクリックします。

1.4.bot defense loggingの作成

ログの設定を行う前にSplunkへのリモートロギングを設定したことを確認してください。ローカルロギングは推奨ではありません。

1.5.bot signature checkingの設定

ボットシグネチャチェックは通常、Proactive Bot Defenseで使用されます(Proactive Bot Defenseを使用するとデフォルトで有効になります)。 システムはボットシグネチャチェックを実行します。これは、既知のボットをそれらのHTTP特性に基づいて正当なまたは悪意のあるものとして識別します。 特定のカテゴリの悪意のあるボットまたは良性のボットを無視、報告、またはブロックするかどうかを指定できます。 必要に応じて、特定のシグネチャを無効にすることもできます。

①「Security」→「DoS Protection」→「DoS Profiles」をクリックします。

②プロファイル名をクリックし、「Application Security」タブをクリックします。

③「General Settings」をクリックし、「Application Security」が「enable」となっていることを確認します。

④「Bot Signatures」をクリックします。

⑤「Bot Signature Check」設定で「Enabled」を有効にします。

f:id:light-spoqz:20190307222635p:plain

⑥「Bot Signature Categories」で悪意のある、または良性のボットの各カテゴリについて、要求がシグネチャと一致したときに実行するアクションを選択します。

設定 概要
None

何もしません。

Report ログを出力します。
Block 要求をブロックし、ログを出力します。

すべての悪意のあるカテゴリまたはすべての無害なカテゴリに対して1つのアクションを選択することも、別々のカテゴリに対して異なるアクションを実行することもできます。

この設定はProactive Bot Defenseにおける設定を上書きします。

⑦特定のシグネチャを無効にしたい場合は「Bot Signatures List」で対象のシグネチャを「Disabled Signatures」へと移動させます。

⑧完了したら、「Update」をクリックします。

1.6.TPS-based DoS detection設定方法

f:id:light-spoqz:20190307230810p:plain

1.7.Behavioral & Stress-based Detection設定方法

①「Security」→「DoS Protection」→「DoS Profiles」をクリックします。

 DoS Profiles Listの画面が表示されます。

②作成したDoS Profile名をクリックします。

③上部の「Application」タブをクリックします。

④左の「Behavioral & Stress-based Detection」をクリックします。

⑤右上の「Edit All」をクリックします。

⑥「Operation Mode」ではプルダウンメニューから以下から設定可能です。

  • Off:Behavioral & Stress-based Detectionを無効にします。Offにしているとそれ以外の設定項目は表示されません。
  • Transparent:DoS攻撃に関するデータをDoSレポート画面に表示しますが、要求をブロックしたり、緩和策の実行はしません。
  • Blocking:疑わしいIPアドレス、位置情報、URL、またはサイト全体に必要な緩和策を適用します。 DoSレポート画面にDoS攻撃に関する情報も表示します。

f:id:light-spoqz:20190307231005p:plain
⑦「Thresholds Mode」では以下の設定をプルダウンメニューから設定が可能です。

  • Automatic:システムがしきい値を自動的に設定します。しきい値を最大で設定し、7日間の履歴データを使用して最適なしきい値を計算します。その後、システムは12時間ごとにしきい値を更新します。
  • Manual:手動でしきい値を設定することが可能です。「Manual」を選択すると「Stress-based Detection and Mitigation」の設定項目が表示されます。

⑧「Stress-based Detection and Mitigation」は「Thresholds Mode」で「Manual」を設定した場合のみ表示され、以下の設定が可能です。

  • By Source IP:攻撃者としてIPアドレスを扱うときの条件を指定します。システムは、最もアクセスされた送信元IPアドレスに対して1つの自動しきい値を計算し、残りに対しては別のしきい値を計算します。
  • By Device ID:デバイスを攻撃者として扱う場合の条件を指定します。自動しきい値の場合、1つのしきい値はアクセス頻度の高いデバイスIDに対して計算され、もう1つのしきい値は残りのしきい値に対して計算されます。
  • By Geolocation:特定の国を攻撃者として扱うタイミングを指定します。自動しきい値を使用している場合は、上位20の位置情報のしきい値が計算され、1日の時間ごとに異なるしきい値が設定されます。したがって、午前9:00に計算されたしきい値は、午前8:00〜9:00のデータに基づいており、翌日の午前8:00に使用されます。
  • By URL:システムが攻撃を受けているURLを処理するタイミングを指定します。自動しきい値の場合、1つのしきい値はアクセスの多いURLに対して計算され、もう1つのしきい値は残りのしきい値に対して計算されます。 (重いURLは計算に含まれません。)
  • Site Wide:Webサイト全体がいつ攻撃を受けているかを判断する方法の条件を指定します。自動しきい値の場合、サイト全体で1つのしきい値が使用されます。

また、少なくとも1つの緩和方法を選択する必要があります。

  • Client Side Integrity Defense:Sends a JavaScript challenge to determine whether the client is a legal browser or an illegal script. Only used when the Operation Mode is set to Blocking.
  • CAPTCHA Challenge:Issues a CAPTCHA challenge to the traffic identified as suspicious by source IP address, geolocation, URL, or site wide.
  • Request Blocking:

デフォルト値はF5の推奨値のようなので、初期値はこれで設定し、問題があれば後で調整しましょう。

 ⑨「Behavioral Detection and Mitigation」では通信動作からどのようにDDoS攻撃を低減するかを設定します。

設定項目 設定
Bad actors behavior detection システムは通信動作と異常検出を調査することによって攻撃者のIPアドレスを識別します。
Request signatures detection 要求を調査し、システムが識別した攻撃パターンを防御するためのシグネチャを作成します。「Use approved signatures only」を選択すると、システムによって生成されたシグネチャを使用する前に承認する必要があります。
Mitigation
  • Conservative Protection:「Bad actors behavior detection」が有効になっている場合、異常検出の信頼性とサーバーの正常性に基づいて、異常なIPアドレスからの要求をスローダウンおよびレート制限します。「Request signatures detection」が有効になっている場合は、動作シグネチャと一致する要求をブロックします。
  • Standard Protection:「Bad actors behavior detection」が有効になっている場合、異常検出の信頼性とサーバーの正常性に基づいて、異常なIPアドレスからの要求スローダウンします。異常なIPアドレスからの要求をレート制限し、必要に応じて、サーバの状態に基づいてすべての要求をレート制限します。異常なIPアドレスからの同時接続数を制限し、必要に応じて、サーバーの状態に基づいてすべての同時接続数を制限します。「Request signatures detection」が有効になっている場合は、動作シグネチャと一致する要求をブロックします。
  • Aggressive Protection:「Bad actors behavior detection」が有効になっている場合、「Standard Protection」に加えて、積極的に(攻撃の前であっても)すべての保護アクションを実行します。保護技術の影響を高めます。「Request signatures detection」が有効になっている場合は、動作シグネチャと一致する要求をブロックします。ブロックされた要求の影響を増やします。
  • No Mitigationトラフィックの動作を学習および監視しますが、何もしません。

 ⑩「Prevention Duration」では次の緩和ステップに進むことを決定するまでの間隔を指定します。

設定項目 設定
Escalation Perid 攻撃者のIPアドレスまたは攻撃されたURLに対する攻撃を防ぐときに、システムが次のステップに進むまでに各緩和ステップで費やす最小時間を指定します。 DoS攻撃の間、システムは有効になっている緩和方法に対して、ここで設定された時間の間、攻撃防止を実行します。 この期間が過ぎても攻撃が阻止されない場合、システムは次の有効な防止手順を実行します。 1から3600までの数値を入力してください。デフォルトは120秒です。
De-escalation Period 有効になっている緩和方法を使用してステップを再試行するまでに、最後のエスカレーションステップで費やした時間を指定します。 0(ステップが再試行されないことを意味する)から86400秒の間の数(エスカレーション期間よりも大きい)を入力します。 デフォルト値は7200秒(2時間)です。


Configuring heavy URL protection
Recording traffic during DoS attacks
Configuring CAPTCHA for DoS protection
Associating a DoS profile with a virtual server

BIG-IP ASMについて② DoS Protectionの概要

 1.DoS対策の概要

※本記事はv13.1.1.4を参考に作成されています。

BIG-IP ASMではクライアント側のトランザクションレート(TPS-based)またはサーバー側の遅延(latency-based)の計算に基づいて、通信がDoS攻撃であると判断します。 本設定ではシステムでしきい値を設定することが可能です。

ASMでは以下の異なるDoS Protectionの設定が可能です。

DoS Protection 概要
Proactive bot defense システムに影響がある前にDoS攻撃を止めます。
Bot signatures 正当なbotからの通信は許可し、悪意のあるbotに対しどのように動作させるかを設定することが可能です。(無視することもブロックすることも可能です。)悪意のあるbotをログに残すことでレポートとして可視化することが可能です。
TPS-based detection 主に1秒あたりのリクエスト数によって攻撃かを判定し、ブロックします。
Stress-based detection サーバの応答遅延や1秒間のリクエスト数を元にDoS攻撃を検知します。
Behavioral detection トラフィックの分析と通信フローの機械学習によって自動的にDoS攻撃の検知と軽減を行う。
Heavy URL protection ユーザーがデータベースを照会したり複雑な照会を送信したりすると、システム遅延が発生する可能性があるため、それらを防ぎます。
CAPTCHA challenge CAPTCHA(ompletely Automated Public Turing test to tell Computers and Humans Apart)を使用し、プログラムにより自動化された攻撃を防ぎます。

2.DoS Protectionの説明

2.1.Proactive Bot Defense

2.1.1.概要

botからの自動化された攻撃からアプリケーションを予防的に保護することができます。本防御方法はProactive Bot Defenseと呼ばれており、以下の攻撃に対して有効です。

ASMのセキュリティポリシーで利用可能なWebスクレイピングブルートフォース保護に加えて、Proactive Bot Defenseを使用可能です。Proactive Bot DefenseはDoSプロファイルを介して実行されるので、セキュリティポリシーを作成しなくても使用可能です。

Proactive bot defenseが有効となっているASM経由でクライアントがWebサイトにアクセスすると、ASMがJavaScriptチャレンジをクライアントに対して送信します。大抵のブラウザはJavaScriptが有効とされているため、botではないクライアントは問題ないですが、botなどはJavaScriptを処理できないためレスポンスを返しません。そのため、この機能を使用する場合はクライアントがJavaScriptが有効であるブラウザを使用することが必要です。

クライアントがJavaScriptチャレンジを正常に処理し、有効なCookieを使用して要求を再送信するとシステムはサーバに到達できるようになります。JavaScriptチャレンジに対して応答しないとリクエストは未回答のまま残り、サーバに送信されません。CookieなしでHTML以外のURLに送信された要求はドロップされて、botとみなされます。

システムがJavaScriptチャレンジを検証しないようにURLリストを設定することも可能です。この設定でWebサイトへのアクセスが短縮されます。

2.1.2.Proactive Bot DefenseとCORS

Cross-Origin Resource Sharing(CORS)は、Webサイトが他のドメインサイトのリソースへアクセスを許可できる方法です。Proactive Bot Defenseは正常な通信でもCORS要求をブロックします。ブラウザは通常クロスドメインリクエストが、セッションライディングなどを防ぐためにクッキーを含まないため、ブロックされます。

したがって、Proactive Bot Defenseを有効にしてWebサイトでCORSを使用している場合は、CORS URLをProactive Bot URLホワイトリストに追加することが推奨されています。

一般的なクロスドメインリクエストは、埋め込み画像、スタイルシートCSS)、JavaScriptなどの他のドメインのリソースを参照する場合です。 Proactive Bot Defenseはクロスドメインリクエスト設定でリソースを許可する特定のドメインを設定できます。

2.2.TPS-based DoS Protection

TPSによりDoSを検知する場合は以下の値が計算されます。

■Transaction Rate Detection Interval

  • 1秒あたりのリクエストの短期平均で10秒毎にアップデートされる(特定のURLやIPアドレスにでそれぞれ計算される)

■Transaction Rate History Interval

  • 1秒あたりのリクエストの長期平均は過去一時間で計算され、10秒ごとにアップデートされる。

上記の設定された値と以下の計算により、攻撃と検知されます。

Transaction Rate History Intervalに対するTransaction Rate Detection Intervalの比率が、「TPS increased by」設定で定義されたパーセンテージよりも大きい場合、ASMは攻撃を受けていると判断、もしくはURLやIPアドレス、位置情報を疑います。もし、Transaction Rate Detection Intervalが「TPS reached」設定よりも大きい場合、再度それぞれのURLやIPアドレス、位置情報が疑わしいか攻撃を受けています。

TPSベースでDoSの防御を行おうとすると、誤検知を行う可能性があります。例えば新製品が発表された時など、Webサイトは多くのユーザのアクセスがあり、この通信をDoSとして誤検知する可能性があります。

ただし、TPSベースの方がストレスベースの防御よりも早く検出が可能であるため、Webシステムの最大負荷状態を理解して設定する必要があります。

2.3.behavioral & stress-based DDoS protection

2.3.1.Stress-based DoS protection

ストレスベースの検出では、遅延時間、少なくとも1つの疑わしいIPアドレス、URL、動作が重いURL、サイト全体のエントリ、または位置情報が必要になります。

平均遅延時間は仮想サーバーとDoSプロファイルごとに測定されます。 1つの仮想サーバーに複数のDoSプロファイルを設定した場合、各DoSプロファイルは仮想サーバーで独自の統計を持ちます。
ストレスベースのDoS保護には、Behavioral DoS protectionも含まれます。有効にすると、システムはトラフィックの動作を調べて、DoS攻撃を自動的に検出します。Behavioral DoS protectionは、問題のあるトラフィックを確認し、軽減します。

DoS攻撃ではサービス/応答時間が遅いため、ストレスベースの保護はTPSベースの保護よりも誤検知が起こりにくくなります。ただし大幅な待ち時間の増加が検出されたら、それ以上の対処を行うかどうかを判断することが重要です。1秒あたりのリクエスト数の増加を調べて、これらの数を過去の統計情報と比較することで、不審か通常かを特定できます。

2.3.2.Behavioral DoS protection

Behavioral DoS Protection(BADoS)は、機械学習とデータ分析を使用してトラフィックの動作を分析することにより、DDoS攻撃に対する自動保護を提供します。他のDoS Protectionと連携して、Behavioral DoSはクライアントとサーバー間のトラフィックを分析し、レイヤ7(HTTP)とレイヤ3およびレイヤ4のベースライントラフィック/フロープロファイルを自動的に算出します。

例えば、botからのDDoS攻撃を受けた場合、サーバーの処理速度が低下したりクラッシュする可能性があります。このような場合においてBehavioral DoSは、サーバーが正常な処理を行えるようにトラフィックをわざと遅く(スローダウン)することによって攻撃を軽減します。

Behavioral DoSは、リアルタイムで相関関係を確認し、サーバーの正常性と負荷を継続的に監視します。異常は監視され、システムは必要に応じて緩和(スローダウンまたはブロック)を行います。

以下がBehavioral DoSの概要です。

  • 通常のトラフィックの振る舞いを学習
  • サーバーの状態に基づいて攻撃を検出
  • 異常な振る舞いを検知
  • 疑わしいクライアントを遅くすることで攻撃の軽減
  • 学習し動作改善

システムはトラフィックデータを監視し変化する状況に適応するため、しきい値の設定は必要ありません。学習のみから予防的DoS保護まで、緩和レベルを設定します。システムはレイヤ7 DoS攻撃を迅速に検出し、問題のあるトラフィックを特定し、攻撃を軽減することができます。

Behavioral DoSを有効にしたDoSプロファイルを使用すると、1つまたは最大2つのVirtual Serverの保護が可能です。

3.DoS緩和手法

TPS-basedもしくはStress-based Protectionを設定している場合に、システムがDoS攻撃を緩和する方法を指定可能です。

  • JavaScript challenges (Client-Side Integrity Defenseとも呼ばれます)
  • CAPTCHA challenges
  • 要求のブロック (レート制限もしくは全ブロックなど)

クライアントが正規のブラウザを使用しているかどうかを分析するためにJavaScriptチャレンジを使用することができます。クライアントがチャレンジに応じてJavaScriptを実行した場合、システムは意図的に対話を遅くします。 Client Side Integrity Defenseによる緩和策は、Operation Modeがブロッキングに設定されている場合にのみ有効になります。

同じ疑わしい基準に基づいて、システムはCAPTCHA(文字認識)チャレンジを発行して、クライアントが人間なのか違法なスクリプトなのかを判断することもできます。 DoS保護をどの程度厳密に適用するかに応じて、サーバーへの通過を許可する要求の数を制限したり、疑わしいと思われる要求をブロックしたりできます。

DoSプロファイルで要求ブロックを使用して、システムが要求をブロックするときの条件を指定することもできます。 TPSベースまたはストレスベースの検出の動作モードが[ブロック]に設定されている場合、システムはDoS攻撃中にのみ要求をブロックします。リクエスブロッキングを使用して、疑わしいIPアドレス、疑わしい国、または攻撃を受けている疑いのあるURLからのすべてのリクエストをレート制限またはブロックできます。サイト全体のレート制限は、攻撃を受けている疑いのあるWebサイトへのリクエストもブロックします。すべてのリクエストをブロックすると、システムはホワイトリストに登録されているものを除き、疑わしいIPアドレスと位置情報をブロックします。レート制限を使用している場合、DoSプロファイルに設定されているしきい値検出基準に応じて、システムによって一部の要求がブロックされます。

選択した軽減方法は、画面に表示されている順序で使用されます。以前の方法で攻撃を阻止できなかった場合にのみ、システムは必要に応じて方法を実行します。

3.1.geolocation mitigation

疑わしいトラフィックを送信している国からのトラフィックを検出することで、位置情報に基づくDoS攻撃を軽減できます。これは、TPS-baseおよびStress-baseの異常に対するDoSプロファイルの緩和方法の一部です。この方法は、以下のように異常な活動から保護するのに役立ちます。

  • Geolocation-based Client Side integrity:トラフィックDoSプロファイルで設定されたしきい値を超えた場合、クライアントが所属する国を疑わしいと判断し、被疑国に所属するクライアントに対してJavaScriptのチャレンジを送信します。
  • Geolocation-based CAPTCHA challenge:トラフィックDoSプロファイルで設定されたしきい値を超えた場合、クライアントが所属する国を疑わしいと判断し、被疑国に所属するクライアントに対してCAPTCHAチャレンジを発行します。
  • Geolocation-based request blocking:被疑国に所属するクライアントからのリクエストの全部または一部をブロックします。

国をホワイトリストブラックリストに追加できます。ブラックリストに登録された国からの攻撃が検知されると通信がブロックされます。

3.2.heavy URL protection

heavy URLは、リクエストごとに大量のサーバーリソースを消費する可能性があるURLです。DoS攻撃の対象となることで、高レイテンシに達する可能性があります。

通常、大規模なサイトでは複雑なデータベースクエリを伴います。例えば、過去の統計情報の取得などです。長期間の統計情報の取得を行うと大量のデータ検索が必要となるため、多くのリソースを要します。

ASMでは、DoSプロファイルを使用してheavy URLの保護が可能です。heavy URLを自動的に検出するための待ち時間しきい値を指定できます。heavy URLとなり得るURLが判明しているのであれば、システムがそれらを監視するように手動で追加したり、無視して監視しないように設定することができます。

システムは各URLとサイト全体の24時間のテールレイテンシを測定します。 URLの平均テールレイテンシが24時間のサイトレイテンシの2倍を超える場合、そのURLは重いと見なされます。

3.3.cross-domain requests

 DoSプロファイルでProactive Bot Defenseを使用すると、どのクロスドメイン要求が正当であるかを指定できます。クロスドメインリクエストとは、リクエストを行っているリソースのドメインとは異なるドメインからのリソースに対するHTTPリクエストです。

アプリケーションが複数のクロスドメインリソースにアクセスし、それらのドメインのリストがある場合は、それらのドメインへのクロスドメイン要求を検証できます。

たとえば、Webサイトではsite1.com(メインサイト)とsite2.com(リソースが格納されている場所)の2つのドメインを使用しています。これをDoSプロファイルで設定するには、Proactive Bot Defenseを有効にし、「Cross-Domain Requests」設定で「Allowed configured domains」オプションを選択して、関連サイトドメインのリストで両方のWebサイトを指定します。ブラウザがsite1.comにリクエストを送信すると、site1.comとsite2.comの両方に対して同時に別々のクッキーが取得され、site1.comからsite2.comへのクロスドメインリクエストが許可されます。

site1.comのみが関連サイトドメインとして設定されている場合、ブラウザがsite1.comにリクエストを送信すると、site1.comのcookieのみが取得されます。ブラウザがsite2.comから画像を取得するためにクロスドメインリクエストを行うと、ブラウザはcookieを取得し、すでに有効なsite1.com cookieを持っている場合にのみ許可されます。

3.4.site-wide DoS mitigation

複数のURLを攻撃する大規模ボットネットを使用した攻撃など、高度に分散されたDoS攻撃を軽減するために、DoSプロファイルでサイト全体の軽減策を使用するタイミングを指定できます。 TPSベースまたはストレスベースのDoS保護に対してサイト全体の緩和策を設定できます。この場合、特定のURLやIPアドレスではなく、サイト全体が疑わしいと見なされる可能性があります。サイト全体で大量のトラフィックが発生しているが、問題を特定して処理できないとシステムが判断した場合、サイト全体の緩和策が実施されます。

システムが正当な要求を落とす可能性があるため、システムはサイト全体の緩和方法を最後の手段としてのみ実装します。ただし、攻撃を受けている場合でも、Webサイトの可用性は少なくとも部分的に維持されます。システムがサイト全体の緩和策を適用するとき、それは他のすべてのアクティブな検出方法が攻撃を阻止することができなかったからです。

設定されたしきい値を超えた場合、サイト全体が疑わしいと見なされます。同時に特定のIPアドレスとURLも疑わしいと判断される可能性があります。軽減は、最大期間が経過するか、サイト全体が攻撃されなくなったと判断されるまで続きます。

3.5.CAPTCHA challenges in DoS detection

CAPTCHACompletely Automated Public Turing test to tell Computers and Humans Apart)Challengeでは、クライアントがWebサイトまたはアプリケーションにアクセスする前に識別できる文字を表示します。 クライアントが文字を正しく識別できるかどうかによって、クライアントが人間であるのか、それとも違法なスクリプトであるのかが決まります。 TPS-baseのDoS検出、Stress-baseのDoS検出、またはProactive Bot Defenseの一部として、CAPTCHAチャレンジを緩和方法として設定できます。 

システムは標準のCAPTCHAレスポンスをクライアントに提供します。 必要に応じてレスポンスをカスタマイズできます。

3.6.DoS protection and HTTP caching

HTTPキャッシングにより、頻繁に要求されるWebオブジェクト(または静的コンテンツ)をメモリに保存して、帯域幅を節約し、Webサーバーのトラフィック負荷を減らすことができます。 Web高速化プロファイルには、キャッシュを構成するための設定があります。

DoS ProtectionとともにHTTPキャッシングを使用している場合は、キャッシュされたコンテンツに対するDoS保護がどのように機能するかを理解する必要があります。 キャッシュされたコンテンツを提供するURLは、パーセンテージで増加した相対TPSを超えると、DoS攻撃と見なされます。 静的URLまたはキャッシュ可能URLへの要求は、レート制限によって常に軽減されます。 

4.まとめ

  • TPS-base、Stress-base、Behaviral-base、Proactive Bot Defenseなどを使用してDoSを防御
  • JavaScript challenges、CAPTCHA challenges、スローダウン、ブロックなどでDoSを緩和 

BIG-IP ASMについて① ASM概要 - インフラエンジニア勉強雑記

BIG-IP ASMについて② DoS Protectionの概要 - インフラエンジニア勉強雑記

 

 

 

 

SSL/TLSについて⑥ SSLハンドシェイク

 1.SSLハンドシェイクとは

1.1.概要

SSL/TLS通信を開始するためにはTCPの3ウェイハンドシェイクのあとにSSLハンドシェイクが行われます。どのようなSSL/TLSのどのバージョンを使用するか、Cipher Suitesの選択、証明書の交換・検証、共通鍵の生成なども行われます。

HTTPS接続でサーバーとクライアントの間で転送されるデータは暗号化されます。共通鍵暗号化方式の方が公開鍵暗号化方式よりも計算コストが少ないので、データの暗号化通信では共通鍵暗号化方式が使用されています。共通鍵暗号化方式を使用するには、両端に共通鍵が必要です。公開鍵暗号化方式で鍵を交換し、共通鍵暗号化方式で通信を暗号化します。

1.2.Cipher Suiteとは

SSL通信で使用する暗号化技術の組み合わせをまとめたものをCipher Suiteといいます。以下はLinux上でコマンドを実行した結果です。

# openssl ciphers -v

ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384
ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
DH-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH/DSS Au=DH Enc=AESGCM(256) Mac=AEAD
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD
DH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH/RSA Au=DH Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256
DH-RSA-AES256-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=AES(256) Mac=SHA256
DH-DSS-AES256-SHA256 TLSv1.2 Kx=DH/DSS Au=DH Enc=AES(256) Mac=SHA256
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
DH-RSA-AES256-SHA SSLv3 Kx=DH/RSA Au=DH Enc=AES(256) Mac=SHA1
DH-DSS-AES256-SHA SSLv3 Kx=DH/DSS Au=DH Enc=AES(256) Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1
DH-RSA-CAMELLIA256-SHA SSLv3 Kx=DH/RSA Au=DH Enc=Camellia(256) Mac=SHA1
DH-DSS-CAMELLIA256-SHA SSLv3 Kx=DH/DSS Au=DH Enc=Camellia(256) Mac=SHA1
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384
ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384
ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1
ECDH-ECDSA-AES256-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1
PSK-AES256-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA1
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256
ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1
DH-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH/DSS Au=DH Enc=AESGCM(128) Mac=AEAD
DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD
DH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256
DH-RSA-AES128-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=AES(128) Mac=SHA256
DH-DSS-AES128-SHA256 TLSv1.2 Kx=DH/DSS Au=DH Enc=AES(128) Mac=SHA256
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
DH-RSA-AES128-SHA SSLv3 Kx=DH/RSA Au=DH Enc=AES(128) Mac=SHA1
DH-DSS-AES128-SHA SSLv3 Kx=DH/DSS Au=DH Enc=AES(128) Mac=SHA1
DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1
DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1
DH-RSA-SEED-SHA SSLv3 Kx=DH/RSA Au=DH Enc=SEED(128) Mac=SHA1
DH-DSS-SEED-SHA SSLv3 Kx=DH/DSS Au=DH Enc=SEED(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1
DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1
DH-RSA-CAMELLIA128-SHA SSLv3 Kx=DH/RSA Au=DH Enc=Camellia(128) Mac=SHA1
DH-DSS-CAMELLIA128-SHA SSLv3 Kx=DH/DSS Au=DH Enc=Camellia(128) Mac=SHA1
ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA256
ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA256
ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA1
ECDH-ECDSA-AES128-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA1
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1
CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1
PSK-AES128-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1
EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1
DH-RSA-DES-CBC3-SHA SSLv3 Kx=DH/RSA Au=DH Enc=3DES(168) Mac=SHA1
DH-DSS-DES-CBC3-SHA SSLv3 Kx=DH/DSS Au=DH Enc=3DES(168) Mac=SHA1
ECDH-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
IDEA-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1
PSK-3DES-EDE-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=3DES(168) Mac=SHA1
KRB5-IDEA-CBC-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=IDEA(128) Mac=SHA1
KRB5-DES-CBC3-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=3DES(168) Mac=SHA1
KRB5-IDEA-CBC-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=IDEA(128) Mac=MD5
KRB5-DES-CBC3-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=3DES(168) Mac=MD5
ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1
ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1
ECDH-RSA-RC4-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1
ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
PSK-RC4-SHA SSLv3 Kx=PSK Au=PSK Enc=RC4(128) Mac=SHA1
KRB5-RC4-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=SHA1
KRB5-RC4-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=MD5

  一列目の内容を使用して内容を説明します。

ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
  • ECDHE-RSA-AES256-GCM-SHA384:Cipher Suiteの名称
  • TLSv1.2:SSL/TLSのバージョン
  • Kx=ECDH:公開鍵暗号化方式
  • Au=RSA:鍵認証時の暗号化方式
  • Enc=AESGCM(256):共通鍵暗号化方式
  • Mac=AEAD:メッセージ認証符号

2.SSLハンドシェイクの詳細

TCP 3ウェイハンドシェイクは完了しているものとします。

2.1.Client Hello

クライアントがサーバに対してSSLコネクションの開始を要求します。

Client HelloにはSSL/TLSのバージョンやCipher Suitesのリストが記載されています。

受信したサーバは、Cipher Suiteのリストを確認して暗号化方式を確定します。もしCipher Suiteのリスト内にサーバが認識できない、サポートしていない暗号化方式があった場合などは無視します。サーバが使用できる暗号化方式がClient HelloのCipher Suiteのリスト内にない場合は失敗のアラートを上げて、コネクションがクローズします。

以下はWireSherkでキャプチャしたClient Helloの内容です。

Frame 1165: 251 bytes on wire (2008 bits), 251 bytes captured (2008 bits) on interface 0
Ethernet II, Src: AsustekC_XX:XX:XX (08:62:66:XX:XX:XX), Dst: Vmware_XX:XX:XX (00:0c:29:XX:XX:XX)
Internet Protocol Version 4, Src: 192.168.XX.XX, Dst: 192.168.XX.XX
Transmission Control Protocol, Src Port: 51136, Dst Port: 443, Seq: 1, Ack: 1, Len: 197
Secure Sockets Layer
   TLSv1.2 Record Layer: Handshake Protocol: Client Hello
      Content Type: Handshake (22)
      Version: TLS 1.0 (0x0301) 
      Length: 192
      Handshake Protocol: Client Hello
         Handshake Type: Client Hello (1)
         Length: 188
         Version: TLS 1.2 (0x0303) #クライアントが対応しているSSL/TLSバージョン
         Random: a0c2c39f89971d0f62c98ca3244e031b6b0025d3c5ff71ce...
            GMT Unix Time: Jun 21, 2055 00:37:03.000000000 東京 (標準時)
            Random Bytes: 89971d0f62c98ca3244e031b6b0025d3c5ff71ce63c33e16...
         Session ID Length: 0
         Cipher Suites Length: 40
         Cipher Suites (20 suites) #クライアントが対応しているCipher Suite
            Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
            Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
            Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
            Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
            Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
            Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
            Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
            Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
            Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
            Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
            Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
            Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
            Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
            Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
         Compression Methods Length: 1
            Compression Methods (1 method)
         Compression Method: null (0)
         Extensions Length: 107
         Extension: ec_point_formats (len=4)
            Type: ec_point_formats (11)
            Length: 4
            EC point formats Length: 3
            Elliptic curves point formats (3)
               EC point format: uncompressed (0)
               EC point format: ansiX962_compressed_prime (1)
               EC point format: ansiX962_compressed_char2 (2)
         Extension: supported_groups (len=8)
            Type: supported_groups (10)
            Length: 8
            Supported Groups List Length: 6
            Supported Groups (3 groups)
               Supported Group: x25519 (0x001d)
               Supported Group: secp256r1 (0x0017)
               Supported Group: secp384r1 (0x0018)
      Extension: SessionTicket TLS (len=0)
         Type: SessionTicket TLS (35)
         Length: 0
         Data (0 bytes)
      Extension: status_request (len=5)
         Type: status_request (5)
         Length: 5
         Certificate Status Type: OCSP (1)
         Responder ID list Length: 0
         Request Extensions Length: 0
      Extension: application_layer_protocol_negotiation (len=14)
         Type: application_layer_protocol_negotiation (16)
         Length: 14
         ALPN Extension Length: 12
         ALPN Protocol
            ALPN string length: 2
            ALPN Next Protocol: h2
            ALPN string length: 8
            ALPN Next Protocol: http/1.1
      Extension: extended_master_secret (len=0)
         Type: extended_master_secret (23)
         Length: 0
      Extension: signature_algorithms (len=48)
         Type: signature_algorithms (13)
         Length: 48
         Signature Hash Algorithms Length: 46
         Signature Hash Algorithms (23 algorithms)
            Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
            Signature Hash Algorithm Hash: SHA256 (4)
            Signature Hash Algorithm Signature: ECDSA (3)
            Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
            ........(省略)
            Signature Hash Algorithm Hash: SHA512 (6)
            Signature Hash Algorithm Signature: DSA (2)

  

2.2.Server Hello,Server Certificate,Server Key Exchange,Certificate Request,Server Hello Done

サーバはClient HelloのCipher Suitesが問題ない場合、Server Helloを返します。以下の情報が含まれています。

  • Server Hello
  • Server Certificate
  • Server Key Exchange(省略可)
  • Certificate Request(省略可)
  • Server Hello Done

Server HelloではClient Helloで送付されたSSL/TLSのバージョンから1つのバージョンとCipher Suiteから1つの暗号化方式を選択して送付します。

Server Certificateでサーバはサーバ証明書をクライアントに送信します。

Server Key Exchangeでは一時的なRSA鍵を生成してサーバの署名を付けて送信します。サーバが証明書を保有していない場合、Server Certificateで公開鍵が含まれていない場合の代替として使用します。

Certificate Requestではクライアント証明書をクライアントに要求する場合に使用されます。

Server Hello Doneではサーバ側から送信する情報が送信されたことをクライアントに通知します。

Frame 1167: 1325 bytes on wire (10600 bits), 1325 bytes captured (10600 bits) on interface 0
Ethernet II, Src: Vmware_XX:XX:XX (00:0c:29:XX:XX:XX), Dst: AsustekC_XX:XX:XX (08:62:66:XX:XX:XX)
Internet Protocol Version 4, Src: XX:XX:XX.XX, Dst: XX:XX:XX.XX
Transmission Control Protocol, Src Port: 443, Dst Port: 51136, Seq: 1, Ack: 198, Len: 1271
Secure Sockets Layer
   TLSv1.2 Record Layer: Handshake Protocol: Server Hello
      Content Type: Handshake (22)
      Version: TLS 1.2 (0x0303) #TLSのバージョン
      Length: 61
      Handshake Protocol: Server Hello
         Handshake Type: Server Hello (2)
         Length: 57
         Version: TLS 1.2 (0x0303)
         Random: 8d9cf0959b23ec35daf4070cfc8e4e09ded3bcfafa54e041...
            GMT Unix Time: Apr 15, 2045 21:37:41.000000000 東京 (標準時)
            Random Bytes: 9b23ec35daf4070cfc8e4e09ded3bcfafa54e0418f0d7a73...
         Session ID Length: 0
         Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) #使用するCipher Suite
         Compression Method: null (0)
         Extensions Length: 17
         Extension: renegotiation_info (len=1)
            Type: renegotiation_info (65281)
            Length: 1
            Renegotiation Info extension
               Renegotiation info extension length: 0
         Extension: ec_point_formats (len=4)
            Type: ec_point_formats (11)
            Length: 4
            EC point formats Length: 3
            Elliptic curves point formats (3)
               EC point format: uncompressed (0)
               EC point format: ansiX962_compressed_prime (1)
               EC point format: ansiX962_compressed_char2 (2)
         Extension: SessionTicket TLS (len=0)
            Type: SessionTicket TLS (35)
            Length: 0
            Data (0 bytes)
   TLSv1.2 Record Layer: Handshake Protocol: Certificate #サーバ証明書の送信、読み飛ばして良い
      Content Type: Handshake (22)
      Version: TLS 1.2 (0x0303)
      Length: 853
      Handshake Protocol: Certificate
         Handshake Type: Certificate (11)
         Length: 849
         Certificates Length: 846
         Certificates (846 bytes)
            Certificate Length: 843
            Certificate: 308203473082022fa003020102020103300d06092a864886... (id-at-commonName=www.test.co.jp,id-at-organizationName=test inc,id-at-stateOrProvinceName=Tokyo,id-at-countryName=JP)
               signedCertificate
                  version: v3 (2)
                  serialNumber: 3
                  signature (sha256WithRSAEncryption)
                     Algorithm Id: 1.2.840.113549.1.1.11 (sha256WithRSAEncryption)
                  issuer: rdnSequence (0)
                     rdnSequence: 5 items (id-at-commonName=test.co.jp,id-at-organizationName=test inc,id-at-localityName=Default City,id-at-stateOrProvinceName=Tokyo,id-at-countryName=JP)
                        RDNSequence item: 1 item (id-at-countryName=JP)
                           RelativeDistinguishedName item (id-at-countryName=JP)
                              Id: 2.5.4.6 (id-at-countryName)
                              CountryName: JP
                        RDNSequence item: 1 item (id-at-stateOrProvinceName=Tokyo)
                           RelativeDistinguishedName item (id-at-stateOrProvinceName=Tokyo)
                              Id: 2.5.4.8 (id-at-stateOrProvinceName)
                              DirectoryString: uTF8String (4)
                                 uTF8String: Tokyo
                        RDNSequence item: 1 item (id-at-localityName=Default City)
                           RelativeDistinguishedName item (id-at-localityName=Default City)
                              Id: 2.5.4.7 (id-at-localityName)
                              DirectoryString: uTF8String (4)
                                 uTF8String: Default City
                        RDNSequence item: 1 item (id-at-organizationName=test inc)
                           RelativeDistinguishedName item (id-at-organizationName=test inc)
                              Id: 2.5.4.10 (id-at-organizationName)
                              DirectoryString: uTF8String (4)
                                 uTF8String: test inc
                        RDNSequence item: 1 item (id-at-commonName=test.co.jp)
                           RelativeDistinguishedName item (id-at-commonName=test.co.jp)
                              Id: 2.5.4.3 (id-at-commonName)
                              DirectoryString: uTF8String (4)
                                 uTF8String: test.co.jp
                  validity
                     notBefore: utcTime (0)
                        utcTime: 19-02-17 12:02:11 (UTC)
                     notAfter: utcTime (0)
                        utcTime: 29-02-14 12:02:11 (UTC)
                  subject: rdnSequence (0)
                     rdnSequence: 4 items (id-at-commonName=www.test.co.jp,id-at-organizationName=test inc,id-at-stateOrProvinceName=Tokyo,id-at-countryName=JP)
                        RDNSequence item: 1 item (id-at-countryName=JP)
                           RelativeDistinguishedName item (id-at-countryName=JP)
                              Id: 2.5.4.6 (id-at-countryName)
                              CountryName: JP
                        RDNSequence item: 1 item (id-at-stateOrProvinceName=Tokyo)
                           RelativeDistinguishedName item (id-at-stateOrProvinceName=Tokyo)
                              Id: 2.5.4.8 (id-at-stateOrProvinceName)
                              DirectoryString: uTF8String (4)
                                 uTF8String: Tokyo
                        RDNSequence item: 1 item (id-at-organizationName=test inc)
                           RelativeDistinguishedName item (id-at-organizationName=test inc)
                              Id: 2.5.4.10 (id-at-organizationName)
                              DirectoryString: uTF8String (4)
                                 uTF8String: test inc
                        RDNSequence item: 1 item (id-at-commonName=www.test.co.jp)
                           RelativeDistinguishedName item (id-at-commonName=www.test.co.jp)
                              Id: 2.5.4.3 (id-at-commonName)
                              DirectoryString: uTF8String (4)
                                 uTF8String: www.test.co.jp
                  subjectPublicKeyInfo
                     algorithm (rsaEncryption)
                        Algorithm Id: 1.2.840.113549.1.1.1 (rsaEncryption)
                     subjectPublicKey: 3082010a0282010100be8f84e278ef1cbcdf719cb16957b1...
                        modulus: 0x00be8f84e278ef1cbcdf719cb16957b185185cd7a005c138...
                        publicExponent: 65537
                  extensions: 1 item
                     Extension (id-ce-subjectAltName)
                        Extension Id: 2.5.29.17 (id-ce-subjectAltName)
                        GeneralNames: 2 items
                           GeneralName: dNSName (2)
                              dNSName: test.co.jp
                           GeneralName: dNSName (2)
                              dNSName: *.test.co.jp
               algorithmIdentifier (sha256WithRSAEncryption)
                  Algorithm Id: 1.2.840.113549.1.1.11 (sha256WithRSAEncryption)
               Padding: 0
               encrypted: 3a736d642a393d78dbd219a05326b3bdf77e80a2c835be28...
   TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange #ECDHEを使用しているため、サーバ側の共通鍵の送信
      Content Type: Handshake (22)
      Version: TLS 1.2 (0x0303)
      Length: 333
      Handshake Protocol: Server Key Exchange
         Handshake Type: Server Key Exchange (12)
         Length: 329
         EC Diffie-Hellman Server Params
            Curve Type: named_curve (0x03)
            Named Curve: secp256r1 (0x0017)
            Pubkey Length: 65
            Pubkey: 0458b7a49226cb09596a651985d5c7e613da3a218557a795...
            Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
               Signature Hash Algorithm Hash: SHA256 (4)
               Signature Hash Algorithm Signature: RSA (1)
            Signature Length: 256
            Signature: 9fae3a95e3e856223aaa3b31a58e5e05e93a3cafe5f70eef...
   TLSv1.2 Record Layer: Handshake Protocol: Server Hello Done #Server Helloの完了
      Content Type: Handshake (22)
      Version: TLS 1.2 (0x0303)
      Length: 4
      Handshake Protocol: Server Hello Done
         Handshake Type: Server Hello Done (14)
         Length: 0

 

2.3.ClientKeyExchange,ClientCertificate,CertificateVerify,ChangeCipherSpec,Finished

証明書を受信したクライアントは、証明書の正当性をルート証明書を使用して検証します。検証が問題なく完了すると、公開鍵を取り出します。

以下の情報が含まれています。

  • ClientKeyExchange 
  • ClientCertificate(省略可)
  • CertificateVerify(省略可)
  • ChangeCipherSpec 

ClientKeyExchange ではRSAの場合クライアントはPre-Master Secretを生成し、DHEやECDHEの場合は共通値を生成し送信します。DHEやECDHEの場合はサーバ側で生成した共通値とクライアント側で生成した共通値を元にPre-Master Secretをクライアント側、サーバ側のそれぞれで生成します。

ClientCertificateではCertificate Requestをクライアントから受信した場合に証明書を送信します。

CertificateVerifyではクライアント証明書を送信した場合に、秘密鍵があることを証明するための署名を送信します。

ChangeCipherSpec では無暗号化通信が終了したことを送信します。 

Frame 1169: 180 bytes on wire (1440 bits), 180 bytes captured (1440 bits) on interface 0
Ethernet II, Src: AsustekC_XX:XX:XX (08:62:66:XX:XX:XX), Dst: Vmware_XX:XX:XX (00:0c:29:XX:XX:XX)
Internet Protocol Version 4, Src: XX.XX.XX.XX, Dst: XX.XX.XX.XX
Transmission Control Protocol, Src Port: 51136, Dst Port: 443, Seq: 198, Ack: 1272, Len: 126
Secure Sockets Layer
   TLSv1.2 Record Layer: Handshake Protocol: Client Key Exchange #ClientKeyExchange 
      Content Type: Handshake (22)
      Version: TLS 1.2 (0x0303)
      Length: 70
      Handshake Protocol: Client Key Exchange
         Handshake Type: Client Key Exchange (16)
         Length: 66
         EC Diffie-Hellman Client Params
            Pubkey Length: 65
            Pubkey: 04fd64e92a34b6c46357f68b9f7ed7c8b07cdbb81e2dc91a...
   TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec #ChangeCipherSpec 
      Content Type: Change Cipher Spec (20)
      Version: TLS 1.2 (0x0303)
      Length: 1
      Change Cipher Spec Message
   TLSv1.2 Record Layer: Handshake Protocol: Encrypted Handshake Message
      Content Type: Handshake (22)
      Version: TLS 1.2 (0x0303)
      Length: 40
      Handshake Protocol: Encrypted Handshake Message

 2.4. ChangeCipherSpec

以下の情報が含まれています。

  • ChangeCipherSpec 

ChangeCipherSpec では無暗号化通信が終了したことを送信します。 

Frame 1170: 312 bytes on wire (2496 bits), 312 bytes captured (2496 bits) on interface 0
Ethernet II, Src: Vmware_XX:XX:XX (00:0c:29:XX:XX:XX), Dst: AsustekC_XX:XX:XX (08:62:66:XX:XX:XX)
Internet Protocol Version 4, Src: XX.XX.XX.XX, Dst: XX.XX.XX.XX
Transmission Control Protocol, Src Port: 443, Dst Port: 51136, Seq: 1272, Ack: 324, Len: 258
Secure Sockets Layer
   TLSv1.2 Record Layer: Handshake Protocol: New Session Ticket
      Content Type: Handshake (22)
      Version: TLS 1.2 (0x0303)
      Length: 202
      Handshake Protocol: New Session Ticket
         Handshake Type: New Session Ticket (4)
         Length: 198
         TLS Session Ticket
            Session Ticket Lifetime Hint: 300 seconds (5 minutes)
            Session Ticket Length: 192
            Session Ticket: 9279ba948314a9ff957a530421bd544ef1d157b4f254d1d1...
   TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec #ChangeCipherSpec 
      Content Type: Change Cipher Spec (20)
      Version: TLS 1.2 (0x0303)
      Length: 1
      Change Cipher Spec Message
   TLSv1.2 Record Layer: Handshake Protocol: Encrypted Handshake Message
      Content Type: Handshake (22)
      Version: TLS 1.2 (0x0303)
      Length: 40
      Handshake Protocol: Encrypted Handshake Message

 

 2.5.暗号化通信開始

この後は生成された共通鍵を使用して暗号化通信を行います。

 

 

SSL/TLSについて① SSL/TLS通信の概要 - インフラエンジニア勉強雑記

SSL/TLSについて② SSLの通信フロー - インフラエンジニア勉強雑記

SSL/TLSについて③ 証明書とは - インフラエンジニア勉強雑記

SSL/TLSについて④ 証明書の発行方法、ルート証明書のインポート方法 - インフラエンジニア勉強雑記

SSL/TLSについて⑤ SSLの終端機器 - インフラエンジニア勉強雑記

SSL/TLSについて⑥ SSLハンドシェイク - インフラエンジニア勉強雑記

SSL/TLSについて④ 証明書の発行方法、ルート証明書のインポート方法

 

1.CSRの発行方法(Linux OpenSSL)

①サーバ用の秘密鍵生成

# openssl genrsa -out /etc/pki/tls/private/server.key 2048

 

Generating RSA private key, 2048 bit long modulus
...................................................+++
................+++
e is 65537 (0x10001)

  

②SAN用の情報作成

# vi /etc/pki/tls/openssl.cnf

 

[alt_names]
DNS.1 = test.com
DNS.2 = *.test.com

  

③サーバ用のCSR生成(サーバ側、認証局どちらでも可)

# openssl req -new -key /etc/pki/tls/private/server.key -out /etc/pki/tls/certs/server.csr

 

 Enter pass phrase for /etc/pki/tls/private/privkey.pem: #①で入力したパスワードを入力

You are about to be asked to enter information that will be incorporatedinto your certificate request.What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blankFor some fields there will be a default value,If you enter '.', the field will be left blank.-----

Country Name (2 letter code) [JP]: #国名、日本だとJP

State or Province Name (full name) [Tokyo]: #都道府県

Locality Name (eg, city) [Default City]: #市区町村

Organization Name (eg, company) [test inc]: #会社名

IT test (eg, section) : #部署名

Common Name (eg, your name or your server's hostname) : #アクセス先サーバのFQDN

  

④証明書の内容確認(テスト用に作成したCSRです)

 # openssl req -text -noout -in /etc/pki/tls/certs/server.csr

 

Certificate Request:
   Data:
      Version: 0 (0x0)
      Subject: C=JP, ST=Tokyo, L=Default City, O=test inc, OU=IT test, CN=test.com
      Subject Public Key Info:
      Public Key Algorithm: rsaEncryption
         Public-Key: (2048 bit)
         Modulus:
            00:d3:cf:af:cf:32:7f:3c:29:c4:cf:45:be:c8:1e:
            16:e4:66:98:6c:02:9f:75:c9:07:d4:01:95:61:af:
            6c:c9:d1:2d:ea:94:b4:5e:e3:0c:6a:3c:a9:27:25:
            5d:7e:90:e6:dd:69:3c:fe:d3:21:55:b4:b9:bd:34:
            3f:25:9f:d5:b9:5c:b6:d9:6e:94:90:a2:9e:46:01:
            64:86:59:0d:9c:90:ab:02:e9:b1:cb:26:58:4b:19:
            db:ef:6c:52:5d:a6:f4:dc:2d:b9:39:7e:97:53:f6:
            97:71:b6:26:b8:9f:d4:f9:94:13:ab:6d:ac:42:2e:
            9c:03:d5:94:70:0a:ae:2d:a4:44:56:75:80:ea:c3:
            5a:df:42:d6:b9:2e:a5:45:e2:cf:3f:2b:c8:f3:2d:
            e3:ed:9c:58:fe:74:dc:a5:0b:7a:b3:40:8b:8b:65:
            f9:39:3f:6f:6b:b3:4b:41:d0:a7:ce:89:8c:56:52:
            f0:b9:67:0d:39:b3:76:65:ba:f4:9a:35:e3:6d:23:
            dd:78:52:22:17:f6:86:00:b6:58:a8:da:1c:b4:84:
            f6:02:b8:de:ac:01:11:8a:f1:86:23:7b:50:1a:95:
            da:15:53:ce:98:4c:fd:41:0d:dd:e4:e8:79:ed:30:
            11:7f:bd:0b:1b:b9:c5:83:70:56:8a:9a:01:df:73:
            89:59
         Exponent: 65537 (0x10001)
      Attributes:
      Requested Extensions:
         X509v3 Basic Constraints:
            CA:FALSE
         X509v3 Key Usage:
            Digital Signature, Non Repudiation, Key Encipherment
         X509v3 Subject Alternative Name:
            DNS:test.com, DNS:*.test.com
   Signature Algorithm: sha256WithRSAEncryption
      10:cf:11:1b:a7:d2:f6:a9:e8:76:2c:73:4e:13:4c:1b:a1:e1:
      b9:d7:16:19:2a:93:c6:fa:fa:ad:d9:6f:1d:8e:e8:50:64:13:
      5d:c9:c7:17:0f:fc:5d:16:4f:90:27:bc:9f:d7:13:e6:5f:d3:
      c5:48:1b:ca:c0:b2:d0:e4:ea:e4:23:aa:84:36:50:b6:2a:24:
      7e:c9:4d:58:9c:e8:2b:98:72:de:e5:3a:7b:67:e7:8b:85:fc:
      9e:8d:74:e4:36:79:ee:c8:56:37:ad:9c:1f:0f:aa:7a:88:26:
      d0:8c:67:ea:27:19:fa:e7:dc:42:f9:12:e0:24:ef:bf:27:60:
      54:0e:b3:37:68:c5:54:c4:45:9d:30:63:3b:d0:14:05:a4:4f:
      da:e2:20:8f:8a:94:97:6d:4e:c3:07:c4:03:0d:28:96:d2:69:
      39:a5:18:6d:12:dc:5f:2d:b0:fd:a0:17:81:71:f3:94:8b:46:
      db:6d:68:20:94:e0:14:99:92:01:3f:ab:1d:98:8c:b2:a5:fa:
      a1:21:4e:be:28:a2:68:62:eb:fe:37:49:ad:d9:c9:c5:b0:22:
      05:88:fb:3f:6e:b5:c0:57:3c:39:15:61:42:ec:52:a7:18:81:
      84:29:2f:46:19:52:f3:42:0c:ce:19:de:55:fb:a5:b5:79:0f:
      41:f1:c7:2f

 

 

CSRを中間認証局に送付、もしくは自己認証局にアップロードして完了となります。

 

2.自己認証局の設定・証明書の発行方法(Linux OpenSSL)

本手順はLinuxサーバを認証局とし、証明書を発行する方法です。本手順ではRHEL7.1を使用しております。SANに関する内容は後述いたします。

①OpenSSLのインストール

# yum -y install openssl

 

認証局として使用するための設定変更

# vi /etc/pki/tls/openssl.cnf

##### [ CA_default ]ハッシュ方式の変更(デフォルト?) #####
default_md = sha256

##### [ req ]ハッシュ方式の変更 #####

default_md = sha256

req_extensions = v3_req

##### [ req_distinguished_name ]CSRで入力する内容を事前に決めておきたい方向け #####

countryName_default = JP #日本
stateOrProvinceName_default = Tokyo #都道府県
localityName_default = Shinjuku #市区町村
0.organizationName_default = test inc. #組織名

organizationalUnitName_default = IT test #部署名

##### [ v3_req ]SAN対応 #####

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

subjectAltName = @alt_names

  

認証局用の秘密鍵生成

# openssl genrsa -aes256 -out /etc/pki/CA/private/cakey.pem 2048

Generating RSA private key, 2048 bit long modulus
..................................+++
.....................+++
e is 65537 (0x10001)
Enter pass phrase for /etc/pki/CA/private/cakey.pem:
Verifying - Enter pass phrase for /etc/pki/CA/private/cakey.pem:

  

認証局用のCSR生成

# openssl req -new -key /etc/pki/CA/private/cakey.pem -out /etc/pki/CA/cacert.csr

Enter pass phrase for /etc/pki/CA/private/cakey.pem:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [JP]:
State or Province Name (full name) [Tokyo]:
Locality Name (eg, city) [Default City]:
Organization Name (eg, company) [test inc]:
IT test (eg, section) :
Common Name (eg, your name or your server's hostname)
:
Email Address :

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password :
An optional company name []:

  

認証局用の証明書生成(本証明書がルート証明書となる)

# openssl x509 -days 3650 -in /etc/pki/CA/cacert.csr -req -signkey /etc/pki/CA/private/cakey.pem -out /etc/pki/CA/cacert.pem

Signature ok
subject=/C=JP/ST=Tokyo/L=Default City/O=test inc
Getting Private key
Enter pass phrase for /etc/pki/CA/private/cakey.pem:

  

⑥証明書失効のための準備

# touch /etc/pki/CA/index.txt
# echo 00 > /etc/pki/CA/serial

 

⑦SAN用の情報作成

※証明書を複数発行する場合はopenssl.cnfに書くよりも外部に出したほうが管理が楽となると感じております。

# vi /etc/pki/tls/san1.ext

subjectAltName=DNS:test.com,DNS:*.test.com

  

⑧サーバ用の証明書発行(認証局にて実施)

# openssl ca -in /etc/pki/tls/certs/server.csr -out /etc/pki/tls/certs/server.crt -days 3650 -extfile /etc/pki/tls/san1.ext

 

Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for /etc/pki/CA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 2 (0x2)
Validity
Not Before: Feb 6 15:03:05 2019 GMT
Not After : Feb 3 15:03:05 2029 GMT
Subject:
countryName = JP
stateOrProvinceName = Tokyo
organizationName = test inc
organizationalUnitName = IT test
commonName = test.com
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:test.com, DNS:*.test.com
Certificate is to be certified until Feb 3 15:03:05 2029 GMT (3650 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

  

⑨作成した証明書をSSL有効化対象のサーバにアップロード

3.証明書の発行方法(Windows ADCA)

今後作成いたします。

4.クライアントにおけるルート証明書のインポート方法(Windows端末)

クライアント端末へのルート証明書のインポート方法です。IEなどのブラウザからも可能ですが、コンピュータアカウントへの追加ができないため、本手順のほうが良いと考えております。

①Winキーを押してmmcと入力し、Enterキーを押します。

②「ファイル」→「スナップインの追加と削除」をクリックします。

③利用できるスナップインから証明書を選択し、「追加」をクリックします。

④一つのユーザに追加する場合は「ユーザアカウント」、コンピュータ全体に導入する場合は「コンピューターアカウント」にチェックを入れて「次へ」をクリックします。

802.1Xを有効にする場合はコンピュータアカウントとすることが必須となります。

⑤「完了」をクリックします。

⑥「OK」をクリックします。

⑦「信頼されたルート証明機関」→「証明書」を右クリックし、「すべてのタスク」→「インポート」をクリックします。

⑧「次へ」をクリックします。

⑨ファイル名を参照して、「次へ」をクリックします。

5.おまけ

5.1.DigiCert SSLTools

Check Website Security | DigiCert SSLTools

SSL/TLSのセキュリティ設定が問題ないか確認するためのサイトです。もちろんですが、イントラネット内のサイトでは使用できません。

 

SSL/TLSについて① SSL/TLS通信の概要 - インフラエンジニア勉強雑記

SSL/TLSについて② SSLの通信フロー - インフラエンジニア勉強雑記

SSL/TLSについて③ 証明書とは - インフラエンジニア勉強雑記

SSL/TLSについて④ 証明書の発行方法、ルート証明書のインポート方法 - インフラエンジニア勉強雑記

SSL/TLSについて⑤ SSLの終端機器 - インフラエンジニア勉強雑記

SSL/TLSについて⑥ SSLハンドシェイク - インフラエンジニア勉強雑記

802.1Xについて① 概要

 

1.IEEE 802.1X認証とは

1.1.概要

NWに接続する端末を認証するための技術です。認証方法の中では設定が面倒な部類に入りますが、セキュリティを強固にすることが可能です。この名称は長いため、ドットイチエックスとかイチエックスと略されて呼ばれることが多いです。

本技術を使用する際にはクライアント、スイッチ、認証サーバの3つが絡むため、障害発生時に原因の切り分けが非常に大変ですが、その分セキュリティも強固なので、導入している企業は多いです。

また、構築だけでなく運用にも気を配る必要があります。802.1X認証に対応していないクライアントに対してはMAB(MAC Authentication Bypass)を有効にしたり、配下にスイッチングハブなどが入っていると正常に認証されない場合などがあります。

本技術の方式の中にはSSL証明書を使用するものもあるため、SSL証明書の検証方法をよく理解しておいたほうが良いです。(SSL証明書を受信したクライアントはどのように証明書が正当なものか検証を行っていたか。)

1.2.通信フロー

この認証を行うためには以下の機器から構成されます。

  • サプリカント(Supplicant):認証クライアント。Windows端末やMac端末などのデバイスやクライアントにインストールされたソフトウェアが対象となる。
  • オーセンティケータ(Authenticator):802.1Xに対応したスイッチや無線LAN
  • 認証サーバ:認証を行うためのサーバ。Radiusが利用されることが多い。

以下は認証のフローです。使用するEAPの種類によってフローが変動するため、注意が必要です。

f:id:light-spoqz:20190212002611j:plain

上記で色々な通信を記載してますが、今回では以下を理解してください。

  1. サプリカントがオーセンティケータ(スイッチもしくは無線AP)に接続したタイミングで認証が開始する。
  2. サプリカントとオーセンティケータ間の通信はオーセンティケータがプロキシして認証サーバと通信する。

詳細の通信フローは後日パケットキャプチャを付与して説明します。

2.EAPとは

認証プロコトルの一つです。EAPの中には以下のような認証方法があります。

  • EAP-MD5:ユーザー名とパスワードによる認証だが、平文を流さないためにMD5ハッシュを用いる。クライアント側のみ認証される。
  • EAP-TLS (Transport Layer Security):サーバ、クライアント双方に電子証明書を準備し、これによって認証を行う。両者にルート証明書保有している必要がある。
  • EAP-TTLS (Tunneled TLS):EAP-TLSの拡張版。米ファンク・ソフトウェア社 (Funk Software) が開発したEAP製品。まずはサーバ側にのみ電子証明書を準備してサーバ認証済みのTLS通信路を構築し、その暗号化通信路を通してパスワードによるクライアント認証を行う。
  • EAP-PEAP (Protected EAP):米マイクロソフト社が開発したEAP規格でIDとパスワードで認証する方式。SSL (Secure Sockets Layer) と同じ暗号化技術によって認証通信全体が暗号化されている。サーバ側にのみ電子証明書を準備してサーバの認証を行った後に、TLSによる暗号化通信路を用いてさらにEAP通信を行い、クライアントを認証する。この際クライアントの認証はパスワードやキートークンなど、電子証明書以外の認証手段を利用する事が一般的である。
  • LEAP(Lightweight EAP) :米シスコシステムズ社が開発したEAP製品。

個人的にはEAP-TLSを使用することが多いです。ただし、クライアント端末にクライアント証明書のインポートが必要になるため、PCの更改と合わせて実施することが推奨です。既存のPC環境を変更したくなく、AD環境であればPEAPがいいです。

 

3.まとめ

  • NWのセキュリティを強固にしたいのであればIEEE 802.1Xを導入するべき。
  • クライアント、NW機器、認証サーバの3種類が絡むため、切り分けが困難。
  • 導入や運用に手間がかかるため、コストと相談する必要あり。

BIG-IP ASMについて① ASM概要

 

1.BIG-IP ASM概要

1.1.ASMの概要

BIG-IPは様々なモジュールをインストールすることで、様々な機能を実装することが可能です。その中でもASM(Application Security Firewall)はWAF(Web Applicaiton Firewall)のモジュールとなります。

名称からわかるようにWebを脅威から守るための装置です。近年増加しているWebサイトのセキュリティ脅威増加の対策の一つとして使用します。

例として以下の脅威から守ることが可能です。

1.2.ASMのモード

これらの内容はWAFを導入している企業全般に言えることですが、運用が非常に大変です。セキュリティの脆弱性を突いた攻撃は日々増加しており、それらに対応するためにASMではシグネチャをF5社から取得し、適用が可能です。(平均6週間に一度、現在2000程度のシグネチャが用意)

これらのシグネチャをすべて割り当てればいいわけではありません。適用した結果、誤検知により正常なWeb通信を止めてしまう可能性があるからです。

一般的にWAFを導入する際は暫定的なポリシーを適用し、トランスペアレントモードで1ヶ月ほど運用することが多いです。このモードでは通信に対してセキュリティポリシーで検査を行いますが、通信を遮断することはありません。ログに出力のみ行わせておき、「正常な通信ではこのシグネチャが通信を止めてしまうな」といった判断を人の手を介して行います。1ヶ月後に正常な通信が行えるようにセキュリティポリシーをチューニングして、ブロッキングモードに変更することで通信の遮断を行います。

2.セキュリティポリシーの種類

ASMはセキュリティポリシーを使用してシステムを保護します。保護ルールを定義したものをセキュリティポリシーといい、ポリシーをバーチャルサーバに対して割り当てることで、複数のWebサーバに対して異なるポリシーを割り当てることが可能です。

セキュリティポリシータイプ 用途
Automatic security policy システムがトラフィックを調査し、トラフィックの統計分析とアプリケーションの動作に基づいてポリシーを作成します。ポリシーを手動で変更することもできます。
Manual security policy 「rapid deployment」または「 an application-ready security policy (pre-configured template) 」を使用しポリシーを作成すると、手動でポリシーのチューニングが可能です。初期設定だと基本的なポリシーのみ作成し、チューニングを行います。
Security policy integrated with vulnerability assessment tool WhiteHat Sentinel、IBM®AppScan®、Trustwave®App Scanner(Cenzic)、Qualys®、QuotiumSeeker®、HP WebInspectなどの脆弱性評価ツールからの出力を統合してセキュリティポリシーを作成します。インポートされた脆弱性レポートの結果に基づいて、Application Security Manager™はWebサイトの脆弱性を自動的に軽減するポリシーを作成します。ポリシーを確認して微調整することもできます。
Parent security policy 複数のセキュリティポリシーの基礎となるセキュリティポリシーを作成します。類似のアプリケーションが複数ある場合に便利です。親ポリシーの設定は、子ポリシーに継承されます。親ポリシーを調整することによって、子ポリシーも変更されます。
Child security policy セキュリティポリシーに基づくセキュリティポリシーを作成します。子ポリシーを作成すると、設定の値は親から継承されます。一部の設定は編集でき、その他の設定は親ポリシーでのみ変更できます。
Template security policy テンプレートを使用して、新しいポリシーを設定します。テンプレートはポリシーの作成時にのみ使用されます。親ポリシーとは異なり、テンプレートは作成後のポリシーには影響しません。

3.セキュリティポリシーの作成準備

セキュリティポリシーを作成する前に、保護対象のアプリケーションと、それを保護することの理由を理解しておく必要があります。

以下の点をセキュリティポリシー作成前に確認しておく必要があります。

  • どのくらい厳密なポリシーを作成するか。
  • 保護したいアプリケーションはいくつあるか。複数のアプリケーションを保護する場合、それらは差異があるのか。(一つのポリシーを使い回せるか、それぞれのアプリケーションで別々のポリシーを定義する必要があるか。)
  • 親ポリシーから制御したい機能はあるか。ポリシーは、親ポリシーから設定を継承が可能である。
  • どのくらいのトラフィックを想定しているか、アプリケーションがどのプロトコルを使用するか。HTTPSを使用する場合、セキュリティの検査を行うためにはSSLの終端が必要になるため、BIG-IPの型番からきちんと検討が必要になる。
  • アプリケーションには、たくさんのパラメータとURLが関連付けられているか。

厳密なセキュリティポリシーは、アプリケーションの変更に影響されるため、維持するために時間と稼働がかかることが多いです。一方で基本的なポリシーでは、複数のアプリケーションに適用した場合でも、メンテナンスは少なく済みます。

4.まとめ

  • BIG-IP ASMはWebアプリケーションの脆弱性を突いた攻撃を防ぐための機器。
  • 導入直後はトランスペアレントモード、運用開始後はブロッキングモードが一般的。

おまけ

GartnerにおけるWAF市場調査の結果です。(2018年分)

以下のURLからダウンロードが可能です。ただし、登録が必要となります。

Gartner Magic Quadrant for Web Application Firewalls | Resource Center | Imperva

図だけですと以下ページから確認可能です。(Impervaのページですが)

Imperva Recognized as a 2018 Gartner Magic Quadrant WAF Leader, Five Years Running | Imperva

 

上記内容の概略は以下です。

  • 強み:様々なクラウドに対応しており、iRuleなどの機構により既存のユーザは本WAFを使用している。また、コミュニティが充実している。
  • 弱み:コストが他の製品と比較して高い。Silverline®(F5によるSOC)が南アメリカ、中東、アフリカ、中国に存在していない。

コストはBIG-IPを提案する場合に必ず通る道です。機能ではあまりWAFは差異が出ないです。