/

Q1

IPsec パラメータ「IPsecプロトコル」「暗号化」「認証」「Diffie-Hellman グループ」の4つを1番セキュアな組み合わせになるよう選択ください。

IPsecプロトコル

  • A: AH
  • B: ESP

暗号化

  • C: DES
  • D: 3DES
  • E: AES

認証

  • F: MD5
  • G: SHA

Diffie-Hellman グループ

  • H: 1
  • I: 2
  • J: 5

問題解説

「IPsecプロトコル」

AHは「Authentication Header」の略であり、認証機能を持っています。ESPは「Encapsulated Security Payload」の略であり、ペイロード部に対して暗号化を行うことができます。よって暗号化が行われるESPの「B」が正答となります。

「暗号化」

「電子政府における調達のために参照すべき暗号のリスト」*1より共通鍵暗号を抜粋

分類暗号技術
64 ビットブロック暗号該当なし
128 ビットブロック暗号AES , Camellia
ストリーム暗号KCipher-2

よって選択肢内にある「E」が正答となります。

「認証」

「暗号の危殆化に関する調査 報告書」*2の報告書に

ハッシュ関数においては、MD5 が既に危殆化している状態であると専門家の間では認識されおり、数分程度の探索でコリジョンが発見できるとの報告がなされている。

等の記載からSHAの「G」が正答となります。

「Diffie-Hellman グループ」

グループID鍵長
1768 ビット
21024 ビット
51536 ビット

上の表より共有鍵が最長となる5の「J」が正答となります。

Q2

正しいMTUの計算を選択ください。なお環境として「NGN_PPPoE」「L2TPv3」「IPsec ( プロトコルESP、暗号AES256、認証SHA-1 ) 」を使用しているものとします。

  • A: 1366
  • B: 1296
  • C: 1336
  • D: 1454

問題解説

PPPoE MTU1454
IP header (IPsec)20
SPI4
Sequence Number4
初期化ベクトル (AES 256)16
ESP 認証データ (SHA 1)12
=小計1398
=1398 以下で最大の 16 の倍数1392
Padding 長1
プロトコル (次ヘッダ)1
=小計1390
IP header (L2TPv3)20
UDP (L2TPv3)8
L2TPv312
Ethernet14
=L2TPv3 MTU1336

上の表より1336byteの「c」が正答となります。

Q3

インターネットVPNを実現する技術であり、楕円曲線DHを用いて鍵交換を行い、Linux Kernelのメインラインにマージされることが決定したものは以下のうちどれか。

  • A: IPSec
  • B: OpenVPN
  • C: WireGuard
  • D: VXLAN

問題解説

正答はC: WireGuardです。

IPSec, OpenVPNは共に楕円曲線DHを用いて鍵交換を行いますが、Linuxのメインカーネルにマージされておらず、利用する場合にはカーネルモジュールに追加するなどの追加作業が必要となります。

VXLANはL2ネットワークを延伸するためのプロトコルであり、DH鍵交換を行いません。

Q4

4G/LTEパケット交換網において、ユーザプレーンとコントロールプレーンで利用されるトンネリングプロトコルの組み合わせとして正しいものは次のうちどれか。

  • A: ユーザプレーン: GTPv0-U コントロールプレーン: GTPv1-C
  • B: ユーザプレーン: GTPv0-U コントロールプレーン: GTPv2-C
  • C: ユーザプレーン: GTPv1-U コントロールプレーン: GTPv1-C
  • D: ユーザプレーン: GTPv1-U コントロールプレーン: GTPv2-C

問題解説

正答はD: ユーザプレーン: GTPv1-U コントロールプレーン: GTPv2-Cです。

GTPv0-UとGTPv1-Cはそれぞれ3G時代に利用されていたユーザプレーンとコントロールプレーンのプロトコルであり、4G/LTE時代に利用されていたものとは別のプロトコルです。

ユーザプレーンとコントロールプレーンそれぞれが正しく4G/LTE時代に利用されているDが正解となります。

 /

問題文

あなたはローカルネットワーク上にwebサーバを構築し、IPv6アドレスを使用してwebページに接続できるようにセットアップをしています。
webページへはhttp://nginx.icttoracon.netでアクセスできるようにしたいです。

nginxのホストには、すでにnginxのパッケージをインストール済みです。
CSR1000Vとnginxのホストには固定でIPv6アドレスを割り当てました。
クライアント(VNC Server)にIPv6アドレスが自動設定されるように、CSR1000VにはSLAACの設定を行いました。

しかし、クライアント(VNC Server)のブラウザからhttp://nginx.icttoracon.netにアクセスしてもWelcome to Nginxのページを表示させることができません。
このトラブルを解決し、Welcome to Nginxのページを表示させてください。

クライアントが増えても自動でアクセスできるよう、設定変更はCSR1000Vとnginxホストのみとしてください。
DNSサーバはCSR1000Vを使用します。
各ノードにはssh/telnet用にIPv4アドレスが設定されていますので必要に応じて使用してください。
予選終了後に実環境で採点されるので、スコアサーバでの解答は不要です。

file

接続情報

HostProtocolIPv4 addressUser/Pass
CSR1000Vtelnet192.168.0.1admin/admin
nginxssh192.168.1.2admin/admin

ゴール

VNCサーバのブラウザからhttp://nginx.icttoracon.netでWelcome to Nginxのサイトが表示されること
上記のアクセスがIPv6で行われていること
(恒久的な設定でなくても構わない)

問題解説

本問題には3つの原因があります。
順を追って調べてみましょう。

疎通性確認

まずはクライアントマシンからnginxホストまでIPv6で疎通性があるか確認してみます。
簡単な確認ではありますが、トラブル原因のレイヤをある程度限定できます。

ubuntu@ICTSC-VNC:~$ ping fc01::2 -c 4
PING fc01::2(fc01::2) 56 data bytes
64 bytes from fc01::2: icmp_seq=1 ttl=63 time=0.887 ms
64 bytes from fc01::2: icmp_seq=2 ttl=63 time=0.607 ms
64 bytes from fc01::2: icmp_seq=3 ttl=63 time=0.802 ms
64 bytes from fc01::2: icmp_seq=4 ttl=63 time=0.699 ms

--- fc01::2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3040ms
rtt min/avg/max/mdev = 0.607/0.748/0.887/0.110 ms

コマンドの結果から本問題は初期状態でIPv6の疎通性があることが確認できます。

名前解決

名前解決ができるかどうか試してみましょう。
ドメイン名からIPv6アドレスを取得するにはAAAAレコードを参照します。
例としてAAAAレコードを取得するコマンドを以下に示します。

ubuntu@ICTSC-VNC:~$ dig nginx.icttoracon.net AAAA

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> nginx.icttoracon.net AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40684
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;nginx.icttoracon.net.        IN  AAAA

;; Query time: 89 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Wed Dec 04 22:46:46 JST 2019
;; MSG SIZE  rcvd: 49
ubuntu@ICTSC-VNC:~$

AAAAレコードは取得できていません。
問題文でDNSサーバはCSRとされていますが、クライアントはどこを参照しているのでしょうか。

ubuntu@ICTSC-VNC:~$ cat /etc/resolv.conf | grep -v "^#"

nameserver 127.0.0.53
options edns0
search localdomain
ubuntu@ICTSC-VNC:~$ cat /run/systemd/resolve/resolv.conf | grep -v "^#"

nameserver 133.242.0.3
nameserver 133.242.0.4
search localdomain
ubuntu@ICTSC-VNC:~$ 

IPv4でDNSサーバを受け取っているようですが、CSRのIPアドレスではありません。
1つ目の原因はDNSサーバ(CSR)が参照できていないことです。

問題文からクライアントの設定変更ではなくルータの設定変更で対応する方針であることがわかります。
クライアントの設定とCSRの設定を確認すると、クライアントのIPv6アドレスはRAを用いた自動設定であることがわかります。
ただしDNSサーバのアドレスが配布されていません。
RAでIPv6アドレスが設定されている場合は、以下の2つの方法でDNSサーバを配布することができます。

  • ステートレスDHCPv6
  • RAを用いたDNS配布(RFC8106)

例としてRAのみでDNSの配布を行います。
IOS-XEのコマンドリファレンスを参照すると、以下の設定でDNSの配布が行えそうです。

csr1000v#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
csr1000v(config)#int gi 1
csr1000v(config-if)#ipv6 nd ra dns server fc00::1

クライアントで確認してみます。

ubuntu@ICTSC-VNC:~$ cat /run/systemd/resolve/resolv.conf | grep -v "^#"

nameserver 133.242.0.3
nameserver 133.242.0.4
nameserver fc00::1
search localdomain
ubuntu@ICTSC-VNC:~$ dig nginx.icttoracon.net AAAA

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> nginx.icttoracon.net AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35863
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;nginx.icttoracon.net.        IN  AAAA

;; ANSWER SECTION:
nginx.icttoracon.net.    10  IN  AAAA    fc01::2

;; Query time: 12 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Wed Dec 04 22:51:49 JST 2019
;; MSG SIZE  rcvd: 77

ubuntu@ICTSC-VNC:~$

DNSサーバとしてfc00::1が設定され、AAAAレコードが正しく参照できています。

nginx設定

IPv6の疎通性があり、名前解決も行えているので一旦クライアントの作業を終え、nginxホストを確認してみます。
まずは80ポートの使用状況を確認してみます。

[admin@nginx ~]$ sudo lsof -i:80
COMMAND  PID  USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
nginx   1421  root    6u  IPv4   9815      0t0  TCP *:http (LISTEN)
nginx   1422 nginx    6u  IPv4   9815      0t0  TCP *:http (LISTEN)

typeを見るとIPv4となっており、nginxがIPv6アドレスで待ち受けていないことがわかります。
2つ目の原因はnginxはIPv6アドレスで待ち受けていないことです。
nginxがIPv6アドレスで待ち受けるよう、設定を変更します。

server {
    listen       80;
+   listen       [::]:80;
    server_name  localhost;

--- snip ---
[admin@nginx ~]$ sudo nginx -s reload
[admin@nginx ~]$ sudo nginx -s reload
[admin@nginx ~]$ sudo lsof -i:80
COMMAND  PID  USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
nginx   1421  root    6u  IPv4   9815      0t0  TCP *:http (LISTEN)
nginx   1421  root   10u  IPv6  10932      0t0  TCP *:http (LISTEN)
nginx   1540 nginx    6u  IPv4   9815      0t0  TCP *:http (LISTEN)
nginx   1540 nginx   10u  IPv6  10932      0t0  TCP *:http (LISTEN)

フィルタリング設定

nginxがIPv6で待ち受ける状態となりました。
しかしまだクライアントからアクセスができません。
nginxホストのディストリビューションを確認してみます。

[admin@nginx ~]$ ls /etc | grep release
centos-release
redhat-release
system-release
system-release-cpe
[admin@nginx ~]$ cat /etc/centos-release 
CentOS release 6.10 (Final)
[admin@nginx ~]$

CentOS6.10であるため、フィルタリングはiptablesで行っていると予想されます。
iptablesのルールを確認してみましょう。

[admin@nginx ~]$ sudo iptables -L INPUT
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 
ACCEPT     icmp --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh 
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:http 
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited 

一見すると問題が無いように見えますが、クライアントはWelcome to Nginxのページにアクセスできません。
それもそのはず、iptablesはIPv4のフィルタリング設定だからです。
実は初期状態からIPv4で80ポートは許可されており、クライアントはIPv4を用いてWelcome to Nginxのページを表示させることはできてました。

IPv6のフィルタリングはip6tableで行います。
ip6tableのルールを確認すると、80ポートのアクセスを許可しているルールが無いことがわかります。

[admin@nginx ~]$ sudo ip6tables -L INPUT
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all      anywhere             anywhere            state RELATED,ESTABLISHED 
ACCEPT     ipv6-icmp    anywhere             anywhere            
ACCEPT     all      anywhere             anywhere            
ACCEPT     udp      anywhere             fe80::/64           state NEW udp dpt:dhcpv6-client 
ACCEPT     tcp      anywhere             anywhere            state NEW tcp dpt:ssh 
REJECT     all      anywhere             anywhere            reject-with icmp6-adm-prohibited 

3つ目の原因はIPv6の80ポートが拒否されていることです。
問題文には恒久的な設定ではなくて構わないとしか記載されていないので、80ポートを許可する方法か、プロセスを停止する方法があります。
問題としてはどちらで行ってもいいですが、望ましいのは80ポートを許可する方法です。
ip6tablesで80ポートを許可します。

[admin@nginx ~]$ sudo ip6tables -I INPUT 6 -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
[admin@nginx ~]$ sudo ip6tables -I INPUT 6 -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
[admin@nginx ~]$ sudo ip6tables -L INPUT
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all      anywhere             anywhere            state RELATED,ESTABLISHED 
ACCEPT     ipv6-icmp    anywhere             anywhere            
ACCEPT     all      anywhere             anywhere            
ACCEPT     udp      anywhere             fe80::/64           state NEW udp dpt:dhcpv6-client 
ACCEPT     tcp      anywhere             anywhere            state NEW tcp dpt:ssh 
ACCEPT     tcp      anywhere             anywhere            state NEW tcp dpt:http 
REJECT     all      anywhere             anywhere            reject-with icmp6-adm-prohibited 

クライアントでアクセスしてみると、Welcome to Nginxのページが表示されます。

 /

問1 経路問題 その1

問題文

下記の図で、vmx2からvmx1のge-0/0/2へpingが飛ばない。 logを見て、考えられる原因について最もふさわしいものを選べ。なお、aclなどfilteringの設定はなく、vmx2の設定は適切であるとする。また、本問においてvmx2のgwはxrv1であるとする。

file
file
  • A: xrv1の物理インタフェースがdownしている
  • B: vmx1からの戻りの経路がない
  • C: vmx1とxrv1の間のvlan設定が間違っている
  • D: ospfのAD値設定が間違っている

解説

Bが正解。vmx1からの戻りの経路がないため。
pingの送信元インタフェースであるvmx2の192.168.1.4/24について、vmx1のshow routeには情報がないことが読める。
pingが通るためには、end-end間に存在する各機器において、往路、復路とも経路を保持している必要がある。往路の経路があるからpingが通るはず、と勘違いしてトラブルシューティングを長引かせてしまった経験をしたことがある人は、すぐに気づく問題である。

  • A:誤り。show ip routeでconnectedもospf経路交換も見えるため、IFは生きていると考えられる。
  • C:誤り。vmx1が10.0.1.20/30の経路をOSPFで受け取っていること等から、疎通性は正常であると判断できる。
  • D:誤り。AD値の設定は正常に見える。

問2 経路問題 その2

下記の図で、vmx2からvmx1のge-0/0/2へpingが飛ばない。logを見て、考えられる原因について最もふさわしいものを選べ。なお、aclなどfilteringの設定はなく、vmx2の設定は適切であるとする。また、本問においてvmx2のgwはxrv1であるとする。

file
  • A: xrv1のstatic routeの設定が原因となっている
  • B: vmx1のルーティングにかかわるプロセスがdownしている
  • C: vmx1において、xrv1とは反対側の上流に経路が向いていることが予想される
  • D: vmx1とxrv1の間のvlan設定が間違っている

解説

Aが正解。xrv1に/32のstatic routeが記載されており、10.0.1.5への経路がxrv2の方に向いているため。
10.0.1.4/30のエントリが見えるが、そのすぐ下に/32があり、ロンゲストマッチの原則から10.0.1.5/32への通信はxrv2の方へ向く。
本問は簡単な例だが、このようにいつの間にか経路が意図しない方に向いていることや、それを原因とする故障はたまに発生する。

  • B:誤り。show ip routeの結果を見る限り、考えにくい。
  • C:誤り。そうなっているかもしれないが、そもそもvmx1まで通信が明らかに到達しない。
  • D:誤り。10.0.1.4/30がdirectly connectedである点、10.0.0.1/32などをOSPFで受けとっている点から、疎通性は正常であると判断できる。

問3 経路情報の伝搬

IPルーティングに関する説明で正しいものを選べ。

  • A: 経路集約を行うことでルータ間での経路交換のメッセージ量やメモリの消費量を低減させることができる。
  • B: BGPは多量の経路を扱うプロトコルであるため、経路情報を可逆圧縮したNLRIと呼ばれるメッセージを用いて経路交換を行う。これは経路集約と呼ばれ、異なるメーカ間での相互接続性を確保するためにLZMAアルゴリズムが用いられている。
  • C: RIPやOSPFでは類似したアドレスの情報を多量に交換するため、各ルータの交換する経路情報はZIP形式で圧縮されている。
  • D: eBGPの設定されているルータはフルルートを保持しており、インターネット上の全ネットワークに接続性を持つこのため、eBGPルータは他のBGPルータに対して0.0.0.0/0の経路のみを配信する。

解説

Aが正しい回答です。経路集約を行うことで交換する経路数が減少するため、メッセージの量や、ルータの保持する経路を減らすことができます。
B,Cは誤りです。OSPFやBGPでは可逆圧縮を用いた経路の交換は行われません。
Dは誤りです。フルルートやそれに相当する経路を持つルータで0.0.0.0/0を生成して他のルータに広告することはよくありますが、iBGPルータあるいはRRルータとの間ではBGPで学習したすべての経路を交換します。

問4 ドキュメント記載に最適なアドレスは?

あなたは研究室のネットワークを管理している。あなたは後輩のために”他の1台のホストへの多量のIPv4 pingの送り方”という例を研究室の運用ドキュメントに記載することにした。このような場合に以下の中で【最も適した】アドレスはどれか?

ping -f <ipv4アドレスの宛先>

条件:後輩たちははNWに馴染みがないため、コマンド例をそのままコピーアンドペーストしてしまうことがある。この際に実際に存在するホストに対してパケットが送信されてしまい迷惑がかかることがないようにしたい。

  • A: 192.0.2.100
  • B: 0.0.0.0
  • C: 255.255.255.255
  • D 172.32.0.1
  • E 10.255.255.255
  • F 192.0.3.100
  • G 127.0.0.1

解説

正解A: ドキュメント向けアドレスであり適切です。[RFC5737] IPv4 Address Blocks Reserved for Documentationに記載があります。この中では、以下のようなアドレスがドキュメント向けに予約されています。

192.0.2.0/24 (TEST-NET-1)
198.51.100.0/24 (TEST-NET-2)
203.0.113.0/24 (TEST-NET-3)

他の選択肢は以下の通り誤りとなります。
B, C, Eはホストを指定するには不適切なアドレスです。D,FはGlobalアドレスであり、例示としては考えられますが、今回の条件と照らし合わせると不適切です。GはloopbackのIPアドレス空間なので他のホストではありません。RFC5735: Special Use IPv4 Addressesに記載があります。

問5 NAT

IPv4環境におけるNATの説明のうち正しいものを選べ

  • A: NAPTを利用することで1つのグローバルアドレスしか所持しない環境でも複数のノードがインターネット上のノードと同時に通信できる。しかし、DNSはプロトコル上、送り元、送信先のポートが53でなければならないため、同時にDNSサーバと通信できるノードは1台のみである。
  • B: NATによりHTTPSを用いてインターネット上のWebサーバと通信をすることが可能である。しかし、クライアント(送信元)のIPアドレスが変換されていると、クライアントはサーバ証明書の確認を行うことはできない。
  • C: NATはプライベートIPアドレスをグローバルIPアドレスに変換する技術であるため、宛先をプライベートIPアドレスに変換することはできない。
  • D: NATはプライベートIPアドレスをグローバルIPアドレスに変換する技術であるため、グローバルIPアドレスをグローバルIPアドレスに変換することはできない。
  • E: 他の選択肢はすべて誤り。

解説

この問題は出題が不適切であるため、C, D, Eを正答としています。
当初はEのみが正当である(C,Dが不適切である)としていました。これは、Linuxおよびいくつかの主要なルータのNAT機能においてプライベートアドレスアドレス空間であるかの判定は行われておらず、グローバルアドレス同士あるいはプライベートアドレス同士のNATが記載できるためです。しかし、NATに関するStandards TrackやInformationalの主要なRFCでは、Privateアドレス空間とExternalアドレス空間(グローバルアドレス空間)を前提として論じられているため、C, D も正答としました。

Aの前半は正しいが後半は誤りです。DNSの通信において、Query送出側のポートが53である制限はありません。B前半は正しいですが後半は誤りです。NAT処理を行ってもHTTPSのサーバの証明に影響はありません。

問6 IPv6

IPv6に関する説明のうち正しいものを選べ。

  • A IPv6ではMACアドレスからユニークに生成されるEUI-64アドレスをホスト部に含むアドレスが広く使われる。このため、IPv6を用いた通信ではMACアドレスを含まないEthernetヘッダが用いられている。
  • B IPv6ではIPv4の上に成り立つネットワークであるため、ホストや途中のルータではIPv4が有効になっていなければならない。
  • C 同一のネットワークに所属するIPv6ホストは送り元と宛て先でペイロードの交換を行う前にNLRIメッセージを交換し、到達性の確認してからペイロードの転送を行う。
  • D IPv4ではEthernet上のL2アドレスの解決にはARPプロトコルが用いられる。IPv6ではARPは用いられず、OSPFv3を用いてL2アドレスを相互に交換しMACアドレスを解決してフレームの転送が行われる。
  • E: 他の選択肢はすべて誤り。

解説

Eが正解です。

他の選択肢が不適切な理由は以下の通りです。
AはIPv6の通信においてもEthernetの通信にMACアドレスが不要になるわけではありません。前半部分については正しいですが、EthernetフレームにはMACアドレスが従来通り必要です。
Bについて、 IPv6はIPv4上のネットワークに構築されるわけではありません。IPv4で接続されたネットワークは不要です。
Cについて、同一ネットワークの通信に選択肢の動作は不要です。NLRIはBGPにおいて用いられる経路情報です。
Dは誤りです。IPv6においてEthernetアドレスの解決にはNeighbor Discoveryの仕組みが用いられます。

問7 OSPF その1

※本問題中の「図:Routing-K1」は他の問題に含まれる「図:Routing-K1」と同様です。

以下のpingの結果として適切なものはどれか。理由が述べられているものについては最も適切な理由なものを選べ。

R1#ping 192.168.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
(略)
  • 1: 成功する。
  • 2: 失敗する。R1とR2のMTUサイズが異なるのでPath MTU Discoveryが失敗しIPパケットが破棄される。
  • 3: 失敗する。R1とR2のMTUサイズが異なりOSPFのMTU mismatchによりOSPFのネイバー関係が確立できないため
  • 4: 失敗する。R1のOSPFはconnected経路をredistributeしていないため、R2はR1に付与されているアドレスに到達できない。

解説

続く4問は同じ構成となるため、状態を説明します。

  • このネットワークはR1, R2間のOSPFがMTU mismatchでOSPFのneighbor関係を確立されていない以外は正常な設定です。
  • OSPFのnetworkコマンドのワイルドカードマスクが/32で書かれているものと/24で書かれているものが存在しますが、今回の設問範囲では影響がありません。

回答に際してポイントとなるのは以下の点でした。

  • OSPFがR1-R2間でneighborを確立できていないこと
  • R1,R2間のI/FでOSPFが確立されていない場合でも、図の状態ではOSPF経路に載るため、R2からR3に対してこの経路は広告されること

以上を元に以下解説していきます。

1が正解。R1,R2間ではOSPFが確立されていないものの、Connectedな経路です。I/FのMTUサイズが意図的に変更されているが、例では明らかに小さいサイズのパケットです。
2,3,4はconnectedの通信には関係がありません。

問8 OSPF その2

※本問題中の「図:Routing-K1」は他の問題に含まれる「図:Routing-K1」と同様です。
以下のpingの結果として適切なものはどれか。理由が述べられているものについては最も適切な理由なものを選べ。

R1#ping 192.168.255.2 source 192.168.255.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.2, timeout is 2 seconds:
Packet sent with a source address of 192.168.255.1
(略)
  • 1: 成功する。
  • 2: 失敗する。R1とR2のMTUサイズが異なるのでPath MTU Discoveryが失敗しIPパケットが破棄される。
  • 3: 失敗する。R1とR2のMTUサイズが異なりOSPFのMTU mismatchによりOSPFのネイバー関係が確立できず、R1は対象アドレスの経路情報を持たない。
  • 4: 失敗する。R1のLoopback0のサブネットマスクは/32であるが、OSPF設定でnetworkコマンドのワイルドカードマスクが/24であるため、Loopback0のアドレスは広告されない。
  • 5: 失敗する。R1のOSPF設定でpassive-interface Loopback0が設定されているため、Loopback0を送り元アドレスとするIPパケットは送出できない。

解説

3が正解。OSPFのMTU mistmatchによりR1-R2間のOSPFの状態はEXSTARTのままで確立できていません。このため、R1はR2のLo0に関する経路を持たず、pingは失敗します。

他の選択肢は以下の点が誤り。
1は上記により誤りです。
2について、IPのPath MTU Discoveryと今回の結果には関係はありません。
4について、該当のnetworkコマンドはLoopback0を含む/24のアドレスを持つインタフェースでOSPFを有効にすることを示します。このため、マスク長が異なるためLoopback0のアドレスが配信されないわけではありません。
5についてpassive-interface Loopback0はOSPFに関する設定です。これをsourceとするIPパケットの送出を禁止するわけではありません。

問9 OSPF その3

※本問題中の「図:Routing-K1」は他の問題に含まれる「図:Routing-K1」と同様です。

以下のpingの結果として適切なものはどれか。理由が述べられているものについては最も適切な理由なものを選べ。

R3#ping 192.168.0.2 source 192.168.255.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
Packet sent with a source address of 192.168.255.3
  • 1: 成功する。
  • 2: 失敗する。R1とR2のMTUサイズが異なりOSPFのMTU mismatchによりOSPFのネイバー関係が確立できず、R2はR3に対してこのOSPF確立が失敗したconnected経路の情報を広告しない。
  • 3: 失敗する。R3のLoopback0のネットマスクは/32であるが、OSPF設定でnetworkコマンドのマスクアドレスが/24であるため、Loopback0のアドレスはR2に広告されず、R2は応答できない。
  • 4: 失敗する。R1とR2のMTUサイズが異なりOSPFのMTU mismatchによりOSPFのネイバー関係が確立できていないため、R2とR3の間のOSPF関係を確立できない。

解説

1の通り成功します。R2-R3間のOSPFは正常であり、関係する経路情報はR2,R3に伝搬されているためです。

2はR2においてあるインタフェースのOSPF確立がMTU mismatch起因で失敗しても、そのインタフェースがOSPFに参加していればそのインタフェースにかかわる情報はConnected経路としてR3に広告されます。
3について該当のnetworkコマンドはLoopback0を含む/24のアドレスを持つインタフェースでOSPFを有効にすることを示めします。このため、マスク長が異なるためLoopback0のアドレスが配信されないわけではありません。
4についてR2あるインタフェースのOSPF確立がMTU mismatch起因で失敗しても他のインタフェースでOSPFの確立ができないわけではありません。

問10 OSPF その4

※本問題中の「図:Routing-K1」は他の問題に含まれる「図:Routing-K1」と同様です。

以下のpingの結果として適切なものはどれか。理由が述べられているものについては最も適切な理由なものを選べ。

R3#ping 192.168.0.1 source 192.168.255.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.255.3
  • 1: 成功する。
  • 2: 失敗する。R1とR2のMTUサイズが異なりOSPFのMTU mismatchによりOSPFのネイバー関係が確立できていないため、R2はR3がOSPF経由で学習した経路宛のパケットを破棄する。
  • 3: 失敗する。R1とR2のMTUサイズが異なりOSPFのMTU mismatchによりOSPFのネイバー関係が確立できていないため、R1はR3のLoopback0の経路を持たない。
  • 4: 失敗する。R1とR2のMTUサイズが異なりOSPFのMTU mismatchによりOSPFのネイバー関係が確立できていないため、R3はR1向けの該当経路を持たない。

解説

3が正解です。R3からのパケットはR1に到達しますが、R1がR3の経路を持たないため、pingは失敗します。R2は192.168.0.0/24をOSPF経路として持ち、R3に広告できます。このため、R3は192.168.0.1宛のパケットをR2に送出できます。R2はR1にパケットをルーティングをしますが、到着したR1では192.168.255.3への経路を(R1はR2とOSPFが確立できていないため)知らないため、パケットを破棄します。

他の選択肢は以下の点が誤りです。
1は以上の通りpingできないため誤りとなります。
2についてはR2はネイバー確立が失敗したインタフェースへのパケット転送を破棄するわけではありません。
4についてはR2のconnected経路をR3は受け取っているため、R3からのパケットはR1に到達できます。このため、この理由は適切でありません。

 /

問題文

あなたはサーバホスティング会社に勤めているシステムエンジニアです。
顧客より、下記のとおり依頼をいただきました。

前任者退職に伴って確認しようと思いサーバ内を確認していたところ、
間違えてFWサーバとwebサーバを再起動してしまいました。
再起動前はwebページに正常にアクセスできていたのですが、アクセスできなくなってしまったため、
いい感じに直していただきたいです。

しかし、セキュリティを考えていた設定とかもあると思うので、外部アクセスなどへはそのまま利用してほしいです。
あと、監視サーバからのURL監視も通るようにしてほしいです。こちらは特に制限をかける必要はありません。
でも、サーバの担当者が出張中で認証情報がわからないので、監視サーバへはログインできないです。
また、再発しないように設定いただけると嬉しいです。

変更した設定などはコマンドレベルでご報告いただけますようお願いします。

対応してほしいところ

上記依頼に則った上で、下記を満たすように修正してください。

  • VNCから以下のwebページへHTTPアクセスが正常に通るようにしてください。
    • 対象URL: http://www.qwe.example/
    • monitorから正常に監視ができるようにしてください。
    • FWサーバ 2222番ポートへの接続で、webへssh接続できるようにしてください。
  • 構成
  • アクセス可能
    • VNC(踏み台、クライアントPCと想定してください)
    • firewall01 (192.168.0.100/10.111.100.1 admin:USerPw@19)
    • web01 (10.111.100.10 admin:USerPw@19 ※FWサーバよりアクセス可能)
  • アクセス不可
    • monitor(192.168.0.200)
      • ※ 例示用URLのため、VNCのhostsに記載して名前解決しています
      • ※ 192.168.128.0/17 のIP帯からwebサーバへのランダムアクセスを行っています。
      • 問題環境の都合上ではありますが、一般userのアクセスと考えて対応してください。

構成図

( Internet )
      |
+-----+-----+      +-----+-----+
|    VNC    |      |  Monitor  |         
+-----+-----+      +-----+-----+
      |                  |
------+------------------+------- 192.168.0.0/16
      |
+-----+-----+
|    FW     |                
+-----+-----+
      |
------+-------------------------- 10.111.100.0/24
      |
+-----+-----+
|    WEB    |                
+-----+-----+

問題解説

本問題の要件としては下記の通りです。

  • VNC – NAT(firewall) – web の通信が通らないため直す
  • Monitor(監視サーバ)からの通信を、正常に通す
  • 外部アクセス(※記載の 192.168.128.0/17)のwebアクセスを可能にした状態で、既存の攻撃対策ルールを適用する

問題文より、firewall および webを再起動してしまった影響と読み解けるので、両サーバの設定を確認します。
今回問題が発生していた箇所は両サーバのfirewall設定が永続化しておらず、
再起動したためロールバックしてしまった、というシナリオでした。不]具合が発生していた箇所を記載します。

iptables NAT設定 (FWサーバ)

入っているNAT設定は WEBサーバ(10.111.100.10)に対する SSH(22) と HTTP(80)のDNAT設定です。
DNATルールにおかしい箇所があります。

誤っている箇所

  • -A PREROUTING -s 192.168.0.100/32 -p tcp -m tcp –dport 2222 -j DNAT –to-destination 10.111.10.10:22
  • -A PREROUTING -s 192.168.0.100/32 -p tcp -m tcp –dport 80 -j DNAT –to-destination 10.111.10.10:80

通信元ポートが22/80だったアドレスを”10.111.10.10″に変換となってしまっています。(第3オクテットが違います)
下記の例の様に直すと、正しいDNAT設定となります。\
また、前任者がsaveした際にできたであろう、 /etc/sysconfig/iptables.save をリストアする事によっても正しいDNAT設定に直す事も可能です。~
※後述のFORWARDルールについてはこちらをリストアしても直っていません。

解答例

  • -A PREROUTING -s 192.168.0.100/32 -p tcp -m tcp –dport 2222 -j DNAT –to-destination 10.111.100.10:22
  • -A PREROUTING -s 192.168.0.100/32 -p tcp -m tcp –dport 80 -j DNAT –to-destination 10.111.100.10:80

これでVNCからWEBサーバに対するNATでのSSH接続が可能となります。

iptables FORWARDルール (FWサーバ)

iptablesでの攻撃対策ルールについてです。
FWサーバの各ルールは基本的に各接続許可/拒否をログ出力するように設定されています。
FWサーバ(192.168.0.100)の/var/log/messagesを見てみると下記のような出力が確認できます。

Nov 16 06:21:07 firewall01 kernel: iptables : FORWARD_ALLOW IN=eth0 OUT=eth1 SRC=192.168.0.200 DST=192.168.100.10 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=64121 DF PROTO=TCP SPT=42576 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0 
Nov 16 06:21:08 firewall01 kernel: iptables : FORWARD_ALLOW IN=eth0 OUT=eth1 SRC=192.168.0.200 DST=192.168.100.10 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=64122 DF PROTO=TCP SPT=42576 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0 
Nov 16 06:21:10 firewall01 kernel: iptables : FORWARD_ALLOW IN=eth0 OUT=eth1 SRC=192.168.0.200 DST=192.168.100.10 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=64123 DF PROTO=TCP SPT=42576 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0 
Nov 16 06:21:11 firewall01 kernel: SYN_FLOOD IN=eth0 OUT=eth1 SRC=192.168.0.200 DST=192.168.100.10 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=15639 DF PROTO=TCP SPT=42636 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0 

監視サーバ(192.168.0.200)からのアクセスがどうやらSYN_FLOODとして判定され拒否されていそうです。
FORWARDルールを確認してみます。

-A FORWARD -s 192.168.0.0/16 -p tcp -m state --state NEW -m tcp --dport 22 -j FORWARD_ALLOW
-A FORWARD -s 192.168.0.0/16 -d 10.111.100.10/32 -p tcp -m tcp --dport 80 -j SYN_CHECK
-A FORWARD -s 192.168.0.200/32 -d 10.111.100.10/32 -p tcp -m state --state NEW -m tcp --dport 80 -j FORWARD_ALLOW 
-A FORWARD ! -s 192.168.0.200/32 -d 10.111.100.10/32 -p tcp -m state --state NEW -m tcp --dport 80 -j FORWARD_ALLOW 
-A FORWARD -s 192.168.0.0/16 -d 10.111.100.10/32 -p tcp -m state --state NEW -m tcp --dport 22 -j FORWARD_ALLOW 
-A FORWARD -s 192.168.0.0/16 -d 10.111.100.10/32 -p tcp -m tcp --dport 22 -j ACCEPT 
-A FORWARD -d 10.111.100.10/32 -p tcp -m tcp --dport 443 -j FORWARD_ALLOW 
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT 

ここで気にするべき点は、iptablesの上から順にルールを読む動作です。
WEBサーバのhttpに対するアクセスをした場合、一番最初に読むFORWARDルールは

-A FORWARD -s 192.168.0.0/16 -d 10.111.100.10/32 -p tcp -m tcp –dport 80 -j SYN_CHECK

となります。

上記FORWARDルールの順だと、依頼されている

あと、監視サーバからのURL監視も通るようにしてほしいです。こちらは特に制限をかける必要はありません

にマッチせず、WEBサーバのHTTPに対するFORWARD通信はすべて下記のSYN_CHECKルールに適用されてしまいます。
SYN_CHECKルールは15秒間に5回アクセスが発生した場合一時的にアクセスを拒否する。という動作をします。
※問題用として拒否制限はかなり厳しくしてあります。

-A SYN_CHECK -p tcp -m tcp -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A SYN_CHECK -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m recent --rcheck --seconds 20 --name SYN_ATTACK --rsource -j REJECT --reject-with icmp-port-unreachable 
-A SYN_CHECK -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m recent --rcheck --seconds 15 --hitcount 5 --name SYN_sorce --rsource -j SYN_FLOOD 
-A SYN_CHECK -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m recent --set --name SYN_sorce --rsource 
-A SYN_CHECK -p tcp -m tcp -j RETURN 
-A SYN_FLOOD -m recent --set --name SYN_ATTACK --rsource -j LOG --log-prefix "iptables : SYN_FLOOD " 
-A SYN_FLOOD -j REJECT --reject-with icmp-port-unreachable 

その為、監視サーバ(192.168.0.200)のFORWARDは真っ先に許可してあげる必要があります。
下記の様に順番を入れ替えます。

-A FORWARD -s 192.168.0.0/16 -p tcp -m state --state NEW -m tcp --dport 22 -j FORWARD_ALLOW 
-A FORWARD -s 192.168.0.200/32 -d 10.111.100.10/32 -p tcp -m state --state NEW -m tcp --dport 80 -j FORWARD_ALLOW ★このルールをSYN_CHECKルールより上に入れる。
-A FORWARD -s 192.168.0.0/16 -d 10.111.100.10/32 -p tcp -m tcp --dport 80 -j SYN_CHECK 
-A FORWARD ! -s 192.168.0.200/32 -d 10.111.100.10/32 -p tcp -m state --state NEW -m tcp --dport 80 -j FORWARD_ALLOW 
-A FORWARD -s 192.168.0.0/16 -d 10.111.100.10/32 -p tcp -m state --state NEW -m tcp --dport 22 -j FORWARD_ALLOW 
-A FORWARD -s 192.168.0.0/16 -d 10.111.100.10/32 -p tcp -m tcp --dport 22 -j ACCEPT 
-A FORWARD -d 10.111.100.10/32 -p tcp -m tcp --dport 443 -j FORWARD_ALLOW 
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT 

これでFWサーバの問題点はすべて解決しました。

firewalld (webサーバ)

WEBサーバでの問題点です。
問題文の通り、依頼主はFWサーバとWEBサーバを再起動してしまっています。
その為、webサーバ側にも何か起こっている可能性があります。
今回は、firewalldの許可リストからhttpが外れている事象でした。

# systemctl status firewalld.service
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
   Active: active (running) since 土 2019-12-07 14:28:58 JST; 1 day 4h ago
     Docs: man:firewalld(1)
 Main PID: 569 (firewalld)
   CGroup: /system.slice/firewalld.service
           └─569 /usr/bin/python2 -Es /usr/sbin/firewalld --nofork --nopid

firewalldは上がっているので、ルールを確認します。

# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources: 
  services: dhcpv6-client ssh
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

httpのアクセスが許可されていなさそうです。

その為下記のコマンドで永続許可します。
※80番ポート許可でもOKです。

# firewall-cmd --zone=public --add-service=http --permanent
# firewall-cmd --reload

これですべての問題点が解決できた事になります。

 /

問題文

通信事業者である「Ictsc Fiber」では最近、MP‐BGPの検証を行っています。 今日も、Loopbackを用いてピアを張り、ルート共有を行う検証を同僚が行っていました。 ですが、上手くピアを張ることができずあなたに助けを求めに来ました。 原因を究明して解決し、正常にピアを張ってください。またピアを張った後に、図に示す「1841-A」の「Loopback 1」のルート共有を行ってください。

トラブルの概要

MP-BGPの設定を行い、Loopback間でピアを張ろうとしたが上手く張れません。以下の図に示す「C1941」と「1841-A」に設定を追記し、ピアを正常に張れるようにしてください。 また、1841-Aの「Loopback 1」のルート情報を共有し、C1941から1841-Aの「Loopback 1」へ疎通可能にしてください。

解説

今回の問題では、MP-BGPと呼ばれる技術を用いてルータ間でのIPv6ルートの共有を行おうとしています。 MP-BGPとは正式名称で「Multi Protocol BGP」と呼ばれ、Ipv4以外のプロトコルに対応しています。そのため、IPv6プロトコルを使用することができます。MP-BGPでも、ピアを確立しルート共有を行うという順番は変わりません。

MP-BGPでEBGPピアを張る際には、BGPと同じ様にEBGP Neighborの設定が必要になります。また、BGPと違ってaddress familyと呼ばれる設定をする必要があります。今回は以下の設定がそれぞれの機器に行われていました。

  • C1941
  router bgp 1
  no bgp default ipv4-unicast
  bgp router-id 1.1.1.1
  neighbor fd00:173::1 remote-as 2
  address-family ipv6 unicast
  neighbor fd00:173::1 activate
  • 1841-A
router bgp 2
  no bgp default ipv4-unicast
  bgp router-id 2.2.2.2
  neighbor fd00:172::1 remote-as 1
  address-family ipv6 unicast
  neighbor fd00:172::1 activate

物理インタフェースを用いるのであれば、これらの設定でピアを張ることができます。


ですが、今回の問題はLoopbackを用いてピアを張る必要があるため、追加で設定を加える必要があります。 実際に追加する必要がある設定は以下になります。

  • C1941
ipv6 route fd00:173::/64 fd00:171::2
neighbor fd00:173::1 update-source loopback 0
neighbor fd00:173::1 ebgp-multihop 2
  • 1841-A
ipv6 route fd00:172::/64 fd00:171::1
neighbor fd00:172::1 update-source loopback 0
neighbor fd00:172::1 ebgp-multihop 2

各機器に設定する項目は同じです。これらの設定を加えることでLoopback間でピアを張ることができます。 追加設定の内容について説明していきます。

ipv6 route ipv6_network_address nexthop

この設定は、IPv6でのスタティックルートを追加するものです。EBGPピアを張る際は、ピアの宛先のアドレスに疎通性がないと張ることが出来ません。初期の設定のままでは、疎通性がないためスタティックルートを追加する必要があります。

neighbor ipv6_network_address update-source loopback 0

ピアを張る際に送るメッセージを送る送信元は、デフォルトでは物理インターフェースに指定されているためLoopback 0 間でピアを張ることができません。そのため、送信元をLoopback 0に指定する必要があります。

neighbor ipv6_network_address ebgp-multihop 2

EBGPピアを張る際の送るメッセージのTTL(Time to Live)はデフォルトで「1」に設定されています。そのため、Loopbackを用いてピアを張る場合、TTLが1より大きくなってしまうためパケットが捨てられてしまいメッセージが宛先に届きません。そのため、この設定によってTTLの数を増やす必要があります。因みに、最後の値の部分を指定しないと、「255」に設定されます。

以上の設定によって、ピアを張ることができます。


さらに、今回の問題では、ピアを張ることが出来たら1841-Aの「Loopback 1」のネットワークをMP-BGPによって共有を行うという指定がありました。それを踏まえてルート共有を行う設定は以下のとおりです。

  • 1841-A
router bgp 2
 address-family ipv6 unicast
 network fd00:174::/64

この設定を行うとMP-BGPでのルート共有が行われます。

回答例

  • C1941
ipv6 route fd00:173::/64 fd00:171::2
router bgp 1
 neighbor fd00:173::1 update-source loopback 0
 neighbor fd00:173::1 ebgp-multihop 2
  • 1841-A
ipv6 route fd00:172::/64 fd00:171::1
router bgp 2
 neighbor fd00:172::1 update-source loopback 0
 neighbor fd00:172::1 ebgp-multihop 2
 address-family ipv6 unicast
 network fd00:174::/64

採点基準

  • 各ルータのLoopback 0に向けてIPv6でのstatic routeが設定されている(30%)
  • neighborを張る送信元をそれぞれの Loopback 0に設定した(60%)
  • ebgp-multihopを2以上に設定している(90%)
  • BGPによって受け取ったルート情報でR1からR2のloopback 1に疎通性が取れる(100%)