インターネットで使われるドメイン名及びIPアドレスを管理。
多数のDNSサーバで構成される『分散型』データベース。
ルートDNSサーバを頂点とし、ドメイン名空間と呼ばれるツリー構造を構成しており、インターネットでは、『負荷分散』と『可用性』を考慮して13のルートDNSサーバが配置されている。

ルートDNSサーバの配下には、ドメイン名（jp,co.jpなど）に対応したDNSサーバがある。あるドメイン名を管理するDNSサーバに関する情報は、ツリー構造の『上位階層』のドメイン名を管理するDNSサーバが保持している。
ホストに関する情報は、そのホストがしょぞくするドメイン名を管理するDNSサーバが保持している。
ドメイン名の中で、www.example.co.jpのように特定のホストを表現したドメイン名を『FQDN』と呼ぶ。
DNSの最も一般的な使われ方は、『FQDN』からIPアドレスへの変換である。これを「ホストの名前解決」と呼ぶ。
一つのドメインを管理するDNSサーバは、通常は『可用性』を考慮して『プライマリサーバ』と『セカンダリサーバ』の２台で構成される。

２．クライアントPCの直接接続方式でインターネットに接続する場合の、ホストの名前解決の動作

直接接続方式：グローバルIPアドレスを使用して、インターネットに直接接続する。
間接接続方式：プライベートIPアドレスを使用し、ルータのNAT機能でグローバルIPアドレスに変換したり、プロキシサーバで中継したりして、インターネットに間接的に接続する。

⇒・PCには、DNSサーバXがIPアドレスを返す。
　・DNSサーバXから問い合わせをうけたルートDNSサーバは、ドメイン名空間においてルートDNSサーバの一つ下位にあるDNSサーバに関する情報をDNSサーバXに返す。
　・DNSサーバXが、要求されたホスト及びIPアドレスの情報をキャッシュしていた場合には、Xはその情報を直ちにPCに返す。
　・DNSサーバXは、要求されたホストの情報を保持するDNSサーバから、ホストに対応するIPアドレスを得る。

2016-10-11

IPアドレス詐称対策に関する問題

05.ファイアウォール・IDS・IPS・UTM

【H25春秋SC午後1問2】

１．攻撃の検出について

【DNSの名前解決通信】

UDPを使用
UDPは、TCP（3wayハンドシェイクを用いてコネクションを確立）と比べて送信元IPアドレスの詐称の検知が困難。

【キャッシュポイズニング攻撃（CP攻撃）】

応答パケットの送信元IPアドレスや宛先ポート番号を細工した攻撃により、大量のDNSパケットがFWにより通過を拒否された。
CP攻撃を成功しにくくする対策
⇒　問合せPTの送信元ポート番号をランダムに変えること

根本的な対策は、公開鍵暗号によるディジタル署名の仕組みを応用したDNSSECというDNSセキュリティ拡張方式を導入することだが、鍵の管理などの運用手順が必要になる。

【FW-A及びC-DNSサーバ（キャッシュDNS）の調査】

C-DNSサーバには、
・上記のCP攻撃を成功しにくくする設定が行われている。
・再帰的な名前解決の問合せPTの送信元を限定する設定が行われている。
しかし、拒否される応答PTが多い状況のため、FW-AとC-DNSサーバを調査。

(1)送信元を詐称した問合せPT

送信元が外部メールサーバ、かつ、宛先がC-DNSサーバ、かつ、FW-Aが通過を許可した問合せPT。→　10分に1個受信。
内容は、国内の取引先G社が取得したドメイン名のTXTレコードの問合せ。
⇒　拒否しない設定にしている理由：送信元が外部メールサーバの場合、再帰的な名前解決を許可する必要があるから。

(2)DNSサーバに向けた応答PT

(1)の問合せPTが届いた直後の1秒間に、送信元がG社のDNSサーバ、かつ、宛先がC-DNSサーバである応答PTが100個届き、FW-Aが通過を拒否した。
100個の応答PTの宛先ポート番号は、到着順に連番であった。
応答内容はG社のドメイン名のTXTレコードであった。
TXTレオードには、SPFレコードが設定されていた。SPFレコードに設定されていたIPアドレスは、G社に割り当てられたものではなかった。
C-DNSサーバが(1)の問合せPTの名前解決を行うための問合せPTは、インターネット上のDNSサーバに送信されてはいなかった。

この攻撃は偶然に成功する可能性があり、攻撃に続く攻撃として、
⇒　G社のドメイン名になりすましたメールを外部メールサーバに送信する
という、TXTレコードを利用する機能への攻撃が発生する。

(3)C-DNSサーバのキャッシュ

C-DNSサーバのキャッシュには、G社のドメイン名のTXTレコードが保存されていた。
TXTレコードには、SPFレコードが設定されており、G社に割り当てられたIPアドレスのうち、G社がメールを送信するサーバのIPアドレスが設定されていた。

２．支社システムの検討と導入

A社では、インターネット及びIP-VPNのトラフィック増加に対処するため、支社システムを導入することとした。
支社システムには、新たなFWを導入し、インターネット、新たなDMZ及び支社LANを接続することにした。
新たなDMZには、支社プロキシサーバを導入した。
支社プロキシサーバの名前解決に、C-DNSサーバを利用することと、FW-AとC-DNSサーバの設定の見直しを検討した。
検討の結果、送信元が支社プロキシサーバに詐称された問合せPTを拒否する設定は不可能であり、FW-AのIPアドレス詐称対策機能が有効に機能しないことがわかった。
再検討した結果、支社システムに機能を追加することで対応することにした。
この対策によって、支社プロキシサーバとC-DNSサーバ間の通信が不要になることも確認した。

送信元を支社プロキシサーバに詐称した問合せPTに対し、FW-AのIP
アドレス詐称対策機能が有効に機能しない理由
⇒　支社プロキシサーバからの正規問い合わせPTと詐称された問い合わせPTとを識別できないから

支社システムに追加する機能
⇒　リゾルバ機能およびDNSキャッシュ機能（C-DNSサーバと同じ機能。前述あり）

05.

2016-10-10

プロキシ経由のWebアクセスに関する問題

02.PKI

【H23秋SC午後1問3】

１．T社におけるインターネットサイトへのアクセスについて

業務目的に限りインターネット上のWebサイトへのアクセスを許可
各従業員のインターネットサイトへのアクセスログを取得している
アクセスログ取得のためにインターネットサイトに向けて送信された内容をログとして取得している
本社及び各支社のLANに設置したPCからは直接インターネットにアクセスできないように、ルータ及びファイアウォールを設定している。
ブラウザからインターネットサイトへのアクセスは、DCに設置したプロキシを経由して行う。

【プロキシで利用している機能の利用目的】
(1)利用者認証機能

ブラウザがHTTPリクエストのProxy-Authorizationヘッダに付与し、Uプロキシに送信した認証情報を、各従業員の利用者IDとパスワードにてらして、アクセスした利用者を識別し認証する。

(2)アクセスログ取得機能

HTTPリクエストごとに、アクセス日時、アクセス元IPアドレス、利用者ID,リクエストライン、インターネットサイトのIPアドレス、受信データサイズ、インターネットサイトからのレスポンスコード

(3)送信内容取得機能

インターネットサイトにデータが送信された場合その内容を取得する。

(4)フィルタリング機能

インターネットサイトへのアクセスを業務目的だけに制限する。
HTTP通信ではブラックリスト方式、HTTPS通信ではホワイトリスト方式で、インターネットサイトのホストのFQDNに基づいたアクセス規制をする。

(5)ウイルスチェック機能

インターネットサイトからのウイルス感染やインターネットサイトへのウイルス送信を防止する。送受信データ内のウイルスをチェックする。

インターネットへのアクセス管理ルールに基づき、インターネットサイトへのHTTPS通信によるアクセスを原則として禁止している理由
⇒　ログを平文で記録できないから。

HTTPS通信を行うことで上記の利用目的を達成できなくなるもの
⇒　(2)、(3)、(5)

ブラウザのURL入力欄にURLを入力したときに、ブラウザがプロキシに最初に送信するHTTPメッセージのリクエストライン
⇒　入力したURL：https://〇〇.co.jp/index.html
⇒　CONNECT 〇〇.co.jp:443 HTTP1.1

２．HTTPS通信時の安全性の確認について

HTTPS通信でWebサーバのサーバ証明書の正当性を確認しないまま、ブラウザがアクセスを継続すると、偽サイトに誘導された場合でなくても、攻撃を受けて、通信を盗聴される可能性がある。
⇒　中間者攻撃

HTTPS通信時にプロキシで詳細なログを取得するため、Lプロキシを導入する。

【Lプロキシを利用した場合のHTTPS通信】
ブラウザとLプロキシ間、及びLプロキシとWebサーバ間において、それぞれ独立の暗号化された通信路を確立する。
Lプロキシは証明書１を受け取ると、ブラウザには転送せずに、自信で証明書１の検証を行う。
次にLプロキシは認証局として証明書１と同じコモンネームのサーバ証明書（証明書２）を新たに作成し、ブラウザに送る。

＜図４＞略

ブラウザがLプロキシ経由でWebサーバとHTTPS通信を行うとき、ブラウザが暗号化してLプロキシに送信したデータはLプロキシで一旦複合される。Lプロキシでアクセスログの取得、送信内容の取得及びウイルスチェックが行われた後、送信データは再度暗号化されて、Webサーバに送信される（受信データも同様）。

サーバ証明書の検証においてブラウザが確認すべき内容のうち、中間者攻撃のような攻撃への対策となるもの
⇒・サーバ証明書のコモンネームとアクセス先のホスト名が一致すること
　・サーバ証明書がブラウザで信頼する認証局から発行されていること

３．Lプロキシについて

ブラウザは証明書２の検証において、証明書２の正当性を確認できないため、事前にブラウザで実施すること
⇒　プロキシのルート証明書を信頼するルート証明書としてインストールする

上記を実施しないとブラウザが証明書２の正当性を確認できない理由
⇒　証明書２はブラウザが信頼する認証局が発行したものではないから

証明書２について、Lプロキシ自身のサーバ証明書をLプロキシが新たに作成する必要がある理由
⇒　サーバ証明書のコモンネームとアクセス先のホスト名を一致させるため

2016-10-09

公開鍵基盤の構築に関する問題

02.PKI

【H21春SC午後2問1】

１．暗号化について

2011年以降に調達できなくなる暗号アルゴリズム

共通鍵暗号
⇒　2-key Triple DES

公開鍵暗号
⇒　鍵長1,024ビットのRSA および DSA
　　鍵長160ビットのECDSA

ハッシュ関数
⇒　SHA-1（ある条件下でハッシュ値の衝突を意図的に起こすことができる脆弱性あり）

メールの暗号化と署名、複合と署名の検証を行うために必要となる証明書
⇒　ルート証明書

２．ウイルス定義ファイルの最新化について

Tシステム（テレワーク環境）で使用するPC（テレワークPC）は、社内PCと同じアプリケーションプログラム、ウイルス対策ソフトが導入されたものを貸与。しかしウイルス定義ファイルは社内に設置されている配布用のサーバだけから自動的に配布されるようになっている。そのためテレワークPCについては、VPN（IPsecを利用）で社内ネットワークに接続されていない時に問題が起こる可能性がある。
⇒　問題：社内ネットワークに接続されないと、ウイルス定義ファイルが更新されない。
⇒　対策：インターネット上のウイルス定義ファイル配布サーバからも更新できるように、PCの設定を変更する。

３．テレワークPCの秘密鍵の管理について

テレワーク対象者が、他人が社内ネットワークへ不正にアクセスしないようにするため自分のテレワークPCに注意する点（秘密鍵の漏えい防止の観点から）
⇒　・テレワークPCの紛失、盗難対策を行う。
　　・テレワークPCを他人に貸与しない。
　　・テレワークPC以外に秘密鍵および証明書を導入しない。
　　・テレワークPCno利用者パスワードを堅牢なものにする。

４．秘密鍵の推測によるデータの改善やなりすましについて

秘密鍵が推測が成功した場合の、改ざんやなりすましの方法
⇒　電子署名の対象のデータを改ざんした上で、そのハッシュ値から、推測した秘密鍵で署名を生成し、本来の所有者と偽って送信する。

５．PKI構築について

電子化された注文票を、インターネットを使って安全に送付する方法（注文票を作成したグループ販社とA者の者だけで内容を知る）
・Webシステムを利用する方法（SSLで暗号化された通信路を使って送付する）
・メールを利用する方法（S/MIMEを使用してメールの暗号化と電子署名を行う）

SSLもS/MIMEも公開鍵基盤（PKI）の上で動作するため、まず認証局（CA）が必要となる。
利用者は、自分自身の秘密鍵と公開鍵の対（鍵ペア）を生成する。CAはこの公開鍵に対して公開鍵証明書を発行する。

証明書を発行するために、自営CAの秘密鍵を使う必要があるが、自営CAの秘密鍵が漏えいすると、双方（グループ販社とA社）に被害が及ぶ。
⇒　グループ販社の発注担当者の証明書が偽造され、偽の注文票が送られる可能性がある。

利用者が証明書署名要求（CSR）を作成するためには、事前に、鍵ペアを生成しておく必要がある。
鍵ペアの生成は、利用者本人でなく、A社（鍵ペア生成プログラムを開発）が行う。
その際、利用者の鍵ペアの取扱いについての注意事項をきちんと決めておく必要がある。
⇒　・CAにおいて、利用者の秘密鍵を厳重に管理する。
　　・鍵ペアと証明書の送付後に、CAでは秘密鍵を削除する。

６．秘密鍵で署名したメールの送信について

Nシステム：営業部における受注業務での受注誤りを減らすためのシステム

グループ販社において、証明書をNシステム以外の用途に使用しないようにする。

グループ販社の発注担当者が、証明書の使用制限に反して、第三者に対し、A社の自営CAで生成された秘密鍵を用いて署名したメールを送信した場合にメール受信者で発生する問題（自営CAを採用していることを考慮）
⇒　問題：署名の正当性を確認できない。
⇒　理由：A社CAのルート証明書を導入していないから。

2016-10-08

利用者ID管理システム及び認証システムの設計に関する問題

01.認証とアクセスコントロール

１．社員IDの登録手順におけるセキュリティ上の問題点

ID登録や削除は人事システムと連携していない。そのため、自らIDとパスワードの登録をアジア地域の情報システム部に依頼している。情報システム部は、依頼内容に沿ってIDとパスワードを登録する。

上記登録手順についてのセキュリティ上の問題点

⇒　承認が行われず、社内システムにアクセスする必要がないものもIDを登録できてしまう。

２．新システムにおける利用者認証方式について

■現状

日本、欧米、アジアという地域ごとに業務を行っている。

【人事管理】

正社員は地域ごとに人事システムで行っている。契約社員は、支店ごとに契約社員を管理する者が人事システムを使わずに管理している。

■Gシステム

各地域の社内システムのうち、共通性の高いものを、全地域から利用できる共通のシステム（Gシステム）として一本化する。

■GIAMシステム

GシステムにおけるID管理、SSOおよびアクセス制御を行うグローバルID・アクセス管理システム

■GIAMの各サブシステム

【認証サブシステム】

認証サーバ（G認証サーバ）、LDAPサーバ（GLDS）から成り、N社全体で一意となるID（GID）とパスワードによる利用者認証およびSSOを実現する。

利用者認証が成功すると、HTTPヘッダにGIDを埋め込んでGポータルおよびGシステムに送信する。

【ID管理サブシステム】

日次で各地域の人事システムから正社員の利用者情報を収集し、新たに登録された正社員に対して、GIDと初期パスワードを生成してGLDSに登録する。

【Gポータル】

G認証サーバか渡されたGIDおよびGLDSに登録された利用者属性に基づいて、ポータル画面を生成し、所属地域のポータルサーバへのリンクを表示する。全地域のPCではブラウザにGポータルをホームページとして設定し、Gポータルのポータル画面が初期表示されるようにする。

【グローバルDS（GDS）】

認証サブシステム、ID管理システム、Gポータル各サーバのコンピュータ名が登録される。

■現在の利用者認証方式

【日本】

ICカードによる利用者認証、エージェント型の認証サーバを開発して利用、PCと社内システムのシングルサインオンはSPNEGOプロトコルによって実現。

利用者が日本社内システムにアクセスすると、日本社内システムは、認証Cookieの検証を行った後、メニュー画面をブラウザに表示する。日本ポータル及び日本社内システムでの認証Cookieの検証では、日本認証サーバと併せて開発された、エージェントと呼ばれるJavaプログラムがアプリケーションプログラムからメソッドとして呼び出される。

【欧米地域】

ID、パスワードによる利用者認証、リバースプロキシ型の認証サーバを利用、PCと社内システムのシングルサインオンはSPNEGOプロトコルによって実現

IDの体系は日本と同じであり、日本と重複しているIDがある。

【アジア地域】

ID、パスワードによる使用者認証、リバースプロキシ型のサーバを利用、PCと社内システムのシングルサインオンは実現されていない。

■GIAMシステムの設計について

GIAMシステムにエージェント型の認証サーバを採用した場合、GポータルやGシステムに市販のパッケージ製品を採用する際に必要となるカスタマイズ

⇒　既存システムからエージェントを呼び出すための変更

SPNEGOによるSSOを実現するためのGDSと各地域のDSに関する変更

⇒　GDSと各地域のDS間で信頼関係を結ぶ

ID体系に関する変更により解決する現状の問題

⇒　日本と欧米地域のIDに重複があるという問題

３．ID管理サブシステムについて

設計に不十分な点があり、各地域の人事システムとは別のサーバから利用者情報を収集する必要がある。

⇒　契約社員の利用者情報が取り込まれていない点

４．地域のポータルサーバへのアクセスについて

【日本】

ブラウザ起動⇒日本認証サーバ（Kerberos要求・応答）⇒⇒ブラウザに日本ポータルへのリンク表示⇒日本ポータルへ

【欧米】

ブラウザ起動（Kerberos要求・応答）⇒欧米ポータルのURI表示⇒欧米ポータルへ

【アジア】

ブラウザ起動（Kerberos要求・応答）⇒アジアポータルのURI表示⇒アジアポータルへ

一部の地域で、Gポータルのポータル画面中のリンクから地域のポータルサーバへのアクセスが失敗する。失敗する地域、ポータル画面に載せるリンクはどのサーバのURIか

⇒　地域：日本　サーバ名：日本認証サーバ（まず日本認証サーバにアクセスし、利用者認証を受けなければならないため）

５．要望対応

■欧米地域からの要望

現行システム同様、一度PCにログオンすれば欧米社内システムとGシステムへのSSOができるようにしてほしい。
社内シンクライアントサーバにアクセスし、仮想デスクトップから欧米社内システムとGシステムにアクセスする際においてもSSOを実現してほしい。
他地域へ出張中でも、仮想デスクトップから、欧米社内システムとGシステムにアクセスする際においてSSOを実現してほしい。

■ICカードによる利用者認証不採用理由

テスト工数の期間と工数が大きくなるため。テスト工程での機能検証内容は

⇒　多種の個人所有機器での利用者認証の動作検証

■利用者が他のシンクライアントサーバにアクセスした場合に発生するおそれがある問題

ネットワークに関連する要因

⇒　ネットワーク遅延が大きいことから、仮想デスクトップの操作に対するレスポンスが悪化する。

６．一部地域の利用者についてID・パスワードの再入力が必要であることについて

一部の地域の利用者は、PCにおける利用者認証のあと、Gポータル及び地域のポータルサーバにアクセスしようとしたときにIDとパスワードの再入力が必要である。当該地域におけるシステム設定の変更が必要。

⇒　SPNEGOを使用していない、アジア地域。

構成要素：アジア認証サーバ／設定内容：SPNEGOの設定をする。
構成要素：アジアPC／SPNEGOの設定をする。

情報セキュリティスペシャリスト受験ノート

情報セキュリティスペシャリストの試験勉強用のノートです。

安全確保支援士 2017年春勉強開始

2016年秋、試験受けてきました。

DNS（ドメインネームシステム）に関する問題

１．DNS