情報処理安全確保支援士の用語メモ
dyoshikawaNAT/NAPT
NAT
network address translation
プライベートIPアドレスとグローバルIPアドレスを相互に変換する
端末がインターネットにアクセスするにはグローバルIPが必要、グローバルIPがないとリクエスト先がどこにレスポンスを返せばいいかわからなくなる
NATの課題
1つのグローバルIPあたり1つのプライベートIPアドレスしか通信できない
そのため基本的に1対1の紐付けになる
もし複数同時に通信させるとリクエスト先はレスポンスをどのプライベートIPに返せばいいかわからなくなってしまう
NAPT
network address and port translation
NATの課題を解決した技術
グローバルIP+ポートの単位でプライベートIPと紐づけられる
これにより1対多の紐付けが可能になり、1つのグローバルIPで複数プライベートIPによる同時通信が可能になる（ポートが枯渇しない限りは）
参考
dyoshikawaローカルブレークアウト
すべての通信をデータセンター経由にすることは通信を一元管理できるセキュリティ上のメリットがあるが、通信コストが嵩んだり帯域不足になって遅くなったりデメリットも大きい
そのため信頼できるクラウドサービスのリストを作り、それらとの通信についてはデータセンターを経由せずに直接通信を許可する
参考
dyoshikawaSMTP-AUTH
SMTPサーバ メール送信に使うサーバ
POPサーバ メール受信に使うサーバ
メール送信時、SMTPサーバがクライアントにID＋パスワード認証を求めるのがSMTP-AUTH
昔は何の認証もなく、SMTPサーバにアクセスできる者なら誰でも好き勝手にスパムメールなど送れてしまっていた
参考
dyoshikawaIPv6 GUA
IPv6 グローバルユニキャストアドレス
IPv4のグローバルIPアドレスに相当
dyoshikawaMITB攻撃
man in the browser attack
端末がマルウェアに感染するとブラウザを乗っ取られ、意図しない操作を行わされてしまう
例えば、インターネットバンクの振り込み処理で、振込先口座を書き換えられるなど
トランザクション署名
MITB攻撃の対策としてトランザクション署名がある
署名生成のための専用端末を別途用意する
専用端末には署名のための秘密鍵が保管されている
利用者は振り込み時に振り込み内容を専用端末に入力する、そうすると専用端末が入力値から署名を算出して返す
利用者は振り込み内容と署名をメイン端末に入力し振り込みリクエストを送信する
マルウェアに振り込み内容を改ざんされても署名の検証に失敗して振り込みはエラーになる
マルウェアは秘密鍵を持っていないので正しい署名を再生することはできない
参考
dyoshikawaスマーフ攻撃
DoS攻撃の一種
送信元アドレスを攻撃対象に偽装し、ICMPパケットをブロードキャストアドレスに送信する
たくさんの端末が攻撃対象に応答することによって攻撃対象に負荷をかける
ICMPパケット
pingコマンドで使われる
用途はネットワーク診断など
対策
攻撃の踏み台に利用されるネットワークや端末はスマーフアンプといわれる
スマーフアンプにされないための対策は、ネットワーク外部からのICMPパケット+ブロードキャスト通信をブロックするよう設定すること
参考
dyoshikawaルートキット
マルウェアの活動を隠蔽する攻撃者のツール
参考
dyoshikawaDNSキャッシュポイズニング
DNSキャッシュサーバ（フルサービスリゾルバ）がまだキャッシュされていないドメインの名前解決を行うために権威DNSサーバに問い合わせリクエストを投げた時、攻撃者が悪意のあるサイトのIPアドレスを真正な応答より先に応答して登録させる攻撃
対策
権威サーバへの問い合わせに使うポートをデフォルトの53番ではなくランダム化する、また問い合わせIDもランダム化することで、攻撃者がどのポートに偽の応答を送りつければよいかわからなくする
より根本的な対策はDNSSECを設定すること
DNSSEC
公開鍵暗号方式を使用して署名の検証を行う
権威サーバ側
ドメイン管理者は秘密鍵を使用して署名を作成しRRSIGレコードとして公開
公開鍵はDNSKEYレコードとして公開
問い合わせ応答時は署名と内容を返す
キャッシュサーバ側
キャッシュサーバは署名つき応答を受け取る
別途DNSKEYより公開鍵を取得する
公開鍵で署名を検証することで、真正の応答であることを確認する
参考
dyoshikawaIPスプーフィング
送信元IPアドレスを偽装すること
スプーフィングはなりすましの意
送信元IP制限による防御設定をくぐり抜ける攻撃の際などに使われる
対策
TCP通信の場合、TCPセッションの確立が必須となるため、IPスプーフィングの成立は困難
そこで攻撃者はさらにTCPシーケンス番号予測攻撃でTCPセッション確立を偽装しようとする
そのためシステム側ではTCPシーケンス番号予測攻撃への対策をする
TCPシーケンス番号
TCPパケットの順序や欠落がないかを確認するための番号
シーケンス番号の初期値をイニシャルシーケンス番号（ISN）という
TCPシーケンス番号予測攻撃
IPスプーフィングした攻撃者クライアントが任意のクライアント側ISNを生成しSYNをサーバに送信
サーバはサーバ側ISNを生成しSYN+ACKを（攻撃者ではない）真正なIPに応答する
攻撃者はSYN+ACKを受け取れないが気にせず、サーバ側ISNを予測してその値でACKを送信する
ACKを受け取ったサーバはシーケンス番号を確認し、正しい番号であればセッションを確立させてしまう
要するに、TCPセッションの確立にはクライアント側ISNとサーバ側ISNを適切に交換することが必要
なので攻撃者はサーバ側ISNの値を読み切れれば攻撃が成功する
TCPシーケンス番号予測攻撃への対策
ISNを予測不可能になるようランダム化する（昔は予測が容易な設定がされていたことがしばしばあったらしい）
参考
dyoshikawaIDS/IPS
intrusion detection system
侵入検知システム
intrusion prevention system
侵入防止システム
IDSは攻撃の検知、ネットワークの監視、アラートを行う
IPSはIDSの機能に加え、不正と判断した通信をブロックする機能が追加されている
攻撃の検知方法
シグネチャ型
攻撃パターンをシグネチャとして登録し、一致するかで判定する
アノマリ型
正常な通信パターンを登録し、そこから外れた通信を異常とみなす
ネットワーク監視方法
ホスト型
サーバ内にインストールされる
ネットワーク型
通信系路上に設置される
参考
dyoshikawaDMZ
直訳すると非武装地帯
内部ネットワークと外部のインターネットの間に配置するネットワークを指す
例えばDMZにはインターネット公開用のWEBサーバを配置する
参考
dyoshikawaPINコード
personal identify number
個人識別番号
端末が盗まれた際、不正利用を防ぐため鍵の役割をする値
4桁の数字であることが多いが桁数や文字種はなんでも良い
パスワードとの違いは、PINコードは端末自体と紐づいていること
端末の所有+PINカードの記憶の2要素認証になっており実はセキュア
PINコードがバレても端末が盗まれない限り不正利用は不可能
参考
dyoshikawaソルトとストレッチング
ハッシュ化したパスワードの解読をより困難にするテクニック
ソルト
ハッシュ化前のパスワードに付加するランダムな文字列
レインボーテーブル攻撃対策になる
また、複数のユーザが同じパスワードを登録していた場合にそれをわからなくできる
ログイン認証時のハッシュ値の一致確認時にソルトが必要になるため、ユーザ毎に保存する
ストレッチング
ハッシュ化を複数繰り返すことで、攻撃者の総当たりによる解読のコストを高めることができる
dyoshikawaPPPoE
Point-to-Point Protocol over Ethernet
イーサネット上でPoint-to-Pointプロトコル（PPP）を実行するためのネットワークプロトコル
イーサネット
ローカルネットワークの標準技術
イーサネットだけではインターネットに接続することができないので、PPPを組み合わせる必要がある
PPP
point to point protocol
インターネットを通じて2点間でデータを転送するための通信プロトコル
ユーザ認証、暗号化、IPアドレスの割り当てなどの機能を持っている
ユーザ認証機能でインターネットサービスプロバイダの認証を行い、機器にIPアドレスを割り当てることでインターネットを利用できる
参考
dyoshikawaDNSリフレクション攻撃
DNSサーバに偽装した送信元IPアドレス（攻撃先）でクエリを送信する
DNSサーバは攻撃先に応答する
これを多数のDNSサーバに行うことで負荷をかける攻撃
DNSはクエリより応答のサイズが大きい性質があり、DNSアンプと呼ばれる
DNSクエリはUDPプロトコルであり、TCPの3ウェイハンドシェイクのようなプロセスがないためIP偽装が容易である
対策
DNSサーバ側が攻撃の踏み台にされないように対策する
レートリミットの有効化、FWやIPSを使った不審な通信のブロック、不要なオープンリゾルバ（外部ネットワークからクエリを受け取ることができるDNSサーバ）の無効化など
dyoshikawaオープンリレー
メールサーバが外部からのメールを中継できる状態のこと
悪意のあるユーザからスパムメール送信の踏み台にされてしまうため、通常はメールサーバに認証を設けるなどしてオープンリレーを無効化する
dyoshikawaOP25B
outbound port 25 blocking
ISPなどのメールサーバが配置されたネットワークにおいてアウトバウンドの25番ポートを塞ぐ設定をすること
25番ポート: SMTPプロトコルを用いたメール送信に使う
メールサーバのユーザクライアントが攻撃者に乗っ取られた際、当該メールサーバは（その利用者の利用量制限の範囲で）スパムメールの踏み台にされてしまう
それ自体はもう仕方ない（？）が、アウトバウンド25番ポートが開いているとさらに外部の別のメールサーバを踏み台にする試みがなされてしまい被害が拡大するリスクがある
そのためOP25Bを行うことで被害を局所化する
外部のメールサーバでメール送信したい場合は25番の代わりに587番ポートを使う
25番は認証なしだが、587番は認証が必須なので悪用が困難
ユーザが乗っ取られることで（中継先メールサーバがそのユーザの利用を想定している場合は）587番の認証も突破できるが、認証が必須であることでユーザの追跡ができるのと、被害を利用量の制限以内に抑えることはできるメリットがある
参考
dyoshikawaSPF/DKIM/DMARC
送信元メールアドレスは偽装可能なので、本当にそのメールアドレス所有者がメールを送信してきているか確認するためにSPF、DKIMを設定する
SPF
sender policy framework
メールアドレス所有者はDNSサーバのSPFレコードにIPアドレスを登録して公開する
受信側はSPFレコードのIPアドレスと実際のメールの送信元IPアドレスの一致を確認する
DKIM
domain keys identified mail
公開鍵暗号方式を活用
メールアドレス所有者はDNSサーバに公開鍵を登録して公開する
そしてメール送信時にメール内容をハッシュ化した値を秘密鍵で暗号化して署名を作成し付加する
受信者は署名を公開鍵で検証し、送信者の正しさ（真正性）とメール内容の改ざんがないこと（完全性）を確認する
DMARC
domain based message authentication reporting and comformance
SPFまたはDKIMが設定されていることが前提
メールアドレス所有者はDMARCにより認証に失敗したメールの処理方法を指定することができる
何もしない（none）
隔離（quarantine）
拒否（reject）
また、認証結果のレポートを受け取ることができる
さらにalignmen機能によりSPF or DKIMの認証結果と送信元ドメインの一致を確認することで、より強力に真正性を検証できる
strict 完全一致を求める
relax サブドメインの不一致を許可
dyoshikawa中間者攻撃
ネットワーク通信におけるセキュリティ脅威のひとつ
2者間の通信に攻撃者が介入し、通信を傍受•改ざんする
参考
dyoshikawaHTTPS
HTTP over TLS（昔はSSL）
データを暗号化して送受信することで攻撃者の盗聴を防ぐ
SSLまたはTLSプロトコルを使用
公開鍵暗号方式と共通鍵暗号方式を組み合わせる
TLS証明書の発行
サービス管理者は秘密鍵・公開鍵を用意する
認証局（CA）に公開鍵と共に証明書発行を依頼する
（企業ならdigicert、非営利団体ならlet's encryptなど）
CAはサービス管理者のドメイン所有権や身元を確認し、OKであればデジタル証明書（TLS証明書）が発行される
この証明書にサービス管理者の公開鍵が含まれている
秘密鍵はサーバー側で厳重に保管される
TLSハンドシェイク
クライアントハロー: 使用可能な暗号化方式とクライアントランダムを送信する
サーバーハロー: 選択した暗号化方式とサーバーランダムを送信する
クライアントハローとサーバーハローは平文で行われる
そしてサーバーはTLS証明書を送信し、クライアントはCAの公開鍵で証明書の署名を検証する
クライアントがプリマスターシークレットと呼ばれるランダム値を再生し、サーバーの公開鍵で暗号化して送信、サーバーは自身の秘密鍵で複合する
クライアントとサーバーはそれぞれクライアントランダム+サーバーランダムからセッション鍵を生成する（同じランダム値のセットからなのでそれぞれ同一のセッション鍵が生成される）
以降はセッション鍵を使って共通鍵暗号化方式でデータを暗号化して送受信する
TLSハンドシェイクは毎回行われるの？
同一サーバと同一クライアントで連続でhttps通信がなされた場合は都度TLSハンドシェイクするのか？という疑問がわいた
これに対する答えは、TLSのセッション再利用によるハンドシェイク簡略化、TLSチケットによるセッションの復元、keep-aliveの有効化によるTCP接続自体の継続、HTTP2/3より可能になった単一のTLS接続上での複数の応答の並列処理などで最適化が働く
dyoshikawaPKI
public key infrastructure
信頼できる第三者である認証局（CA）が秘密鍵と公開鍵の紐付きを保証する
CAの階層構造
CAはルートCAを頂点とした階層構造になっている
まずルートCAが絶対的に信頼できるCAとして君臨し、ルートCAと信頼関係を結んだ配下のCAも信頼できる、さらにルートCA配下のCAの配下も信頼できる（以下再帰的に続く）という仕組みになっている
サーバ証明書の検証の例
サーバ管理者が秘密鍵・公開鍵を用意する
ルートCA直下のCAaに公開鍵と共に証明書発行申請したとする
CAaはサーバ管理者の身元や所有権を確認しOKであれば申請時の公開鍵入りのデジタル証明書を発行する
証明書には署名がついているが、この署名はCAaの秘密鍵により生成される
このためシステム管理者の秘密鍵・公開鍵とCAの秘密鍵・公開鍵が別々に存在することに注意が必要
サーバ証明書の親としてCAaの証明書があり、さらにCAaの証明書の親がルートCAの証明書となる
サーバ証明書の署名はCAaの秘密鍵で生成され、CAa証明書の署名はルートCAの秘密鍵で生成される
一般的にクライアントは最初からOSやブラウザにおいてルートCAの公開鍵をインストールされている
クライアントがサーバに接続する際、まずサーバ証明書を取得し、親がCAaであることを確認する
そのためCAaの証明書を取得し、そこから公開鍵を取り出してサーバ証明書の署名検証に使う
続いてCAaの親であるルートCAの公開鍵でCAaの証明書の署名検証をする
そこでOKであればルートCAお墨付きということが確認できるので検証は完了、サーバ証明書を信頼できる
サーバ証明書内の公開鍵も信頼して使うことができる
ルートCAの例
有名どころはdigicertなど
Apple Amazon Google MicrosoftなどのビックテックもルートCAを提供している
参考
dyoshikawaTLSクライアント認証
サーバ証明書に加えてクライアント証明書が存在し、サーバとクライアントが相互に認証する方式
クライアント証明書があることで、サーバに対して身元を証明し認証する
サーバに特定の端末にだけアクセスさせたいような場合に対象端末にクライアント証明書と秘密鍵をセットして使う
サーバ証明書発行については割愛
クライアント証明書は組織の内部CAから発行されることが多い
クライアント側で秘密鍵と公開鍵を生成し、CAに対して発行依頼する
発行された証明書と秘密鍵をクライアントは保持する
TLSハンドシェイクの際にクライアント側の認証プロセスが追加される
サーバはクライアント証明書の署名をCAの公開鍵で検証し、その後証明書からクライアントの公開鍵を取得する
そしてクライアントからハンドシェイクの通信内容をハッシュ化した値を暗号化した署名が送られてくるので、公開鍵で復号しサーバ側でもハッシュ化した値と一致することを検証する
dyoshikawaHMAC
hash-based message authentication
code
共通鍵を使う
事前に受信者と送信者が共通鍵を交換しておく
送信者は送信する内容（メッセージ）に共通鍵を組み合わせた値をハッシュ化する
このハッシュ値がHMAC
HMACとメッセージをセットで送信する
受信者は同じように受け取ったメッセージと共通鍵を組み合わせてハッシュ化してHMACを生成する
受信したHMACとこのHMACが一致すればメッセージが改ざんされていないことを検証できる
ただし、受信者と送信者で少なくとも2人が同じ共通鍵を持っていることになるので、送信者の保証はできない
参考
dyoshikawaVPN
virtual private network
仮想的に専用線接続を実現する
IPベースの通信に専用の接続方法や暗号化を加える
インターネットVPN
パブリックなインターネット上で仮想専用線を実現する
コストメリットがあるが、セキュリティは暗号化の強度のみに頼ることになる
サイト間VPN
別名LAN型VPN
LAN同士が接続する
クライアントVPN
別名リモートアクセス型VPN
端末にVPNクライアントソフトをインストールし、拠点LANとの接続を確立する
IP-VPN
ISPが提供するVPNサービス
複数の加入者で帯域を共用する閉域網を利用する
参考
dyoshikawaVPNのモード
トランスポートモード
データの暗号化をクライアントが直接行う
VPNソフトウェアをクライアントにインストールする必要がある
IPヘッダは暗号化されず平文
トンネルモード
クライアントはVPNゲートウェイに平文でデータを送信し、VPNゲートウェイが暗号化を行って送信先に送信する
送信先のVPNゲートウェイのIPさえ平文であれば良いので、エンドツーエンド端末のIPヘッダを暗号化することができる
dyoshikawaIPsec
VPNの暗号化を実現する技術のひとつ
レイヤ3ネットワーク層で暗号化する
例えばSSL/TLS VPNの場合はレイヤ7アプリケーション層の暗号化になる
dyoshikawaUTM
unified threat management
統合脅威管理
IPS/IDS、firewall、VPNなどセキュリティに関わるさまざまな機能を内包するオールインワンなハードウェアもしくはソフトウェア
dyoshikawaSIEM
security information and event management
ログ収集とその分析、脅威検知と管理者への通知を統合的に行うツール
IDSとの違いは？
SIEMはIDSと統合して動作する
IDSはSIEMのデータソースとなる
dyoshikawaEDR
endpoint detection and response
エンドポイントを守るためのツール
脅威の検知から対応まで自動で行う
エンドポイントとは
ネットワークの末端端末
PC、モバイル端末、IoT機器など
IPS/IDSとの違い
IPS/IDSはネットワークに、EDRはエンドポイントに焦点
dyoshikawaDNS名前解決のプロセス
クライアント ローカルDNSキャッシュを確認し、なければISPのDNSリゾルバサーバに再帰問い合わせする
リゾルバサーバ キャッシュを確認し、なければ反復問い合わせの開始
リゾルバサーバ ルートDNSサーバにTLDサーバのIPアドレスを問い合わせる
リゾルバサーバ TLDサーバに権威DNSサーバのIPアドレスを問い合わせる
リゾルバサーバ 権威DNSサーバに対象サーバのIPアドレスを問い合わせる
リゾルバサーバ クライアントに対象サーバのIPアドレスを返す
TLDサーバとは
top level domain
.com .jpなどのトップレベルドメインを管轄するDNSサーバ