おはようございます、作問者のやつはしです。

今回は、リソース削減・ネットワーク基盤に依存しないために全て一つのVM上で完結させました。

残念ながら、この問題に辿りついたチームは1つで、解答数は0でした。

日の目を見ることはなかった問題ですが、SDNに関する問題は、今までなかったので参考問題として公開します。

 

問題文

無事に課題が終わったパトリシアは、学校を案内してくれることになった。

パトリシア「課題を手伝ってくれてありがとう♪。じゃあ学校を案内するね」

食堂や教室、体育館などを案内してもらった。

パトリシア「ここが最後よ–ここは私が志望してる研究室で、魔法陣の仮想化を研究しているの」

パトリシア「教授は、OpenFlowを使って特殊なNATを作成しているの……でも、昨日Dockerコンテナに移行してから動いていないそうなの」

エイト「ふむ、ここで教授に恩を売っておきたいところね」

パトリシア「そうなの、でも、私一人じゃできなくて……何度も悪いんだけど、手伝ってくれないかな?」

アクセスできるサーバー

  • サーバ名 : openflow
  • アドレス : openflow.3.mgi
  • ユーザ : admin
  • パスワード : hello_openflow

注意事項

  • VyOS1・VyOS2・VyOS3・VyOS4のIPアドレス・サブネット・VLANに変更を加えてはいけない。(Config自体は変えてもよい)
  • コンテナの停止・再起動は許可する。

達成すべき事項

  • VyOS4で ping 172.16.100.150 を実行し、VyOS3より返答を受け取れる。
  • OpenFlow を使って、 192.168.1.2->172.16.100.150 の SNAT と 172.16.100.150->192.168.1.2 の DNAT を実現する。

その他

OVSがインストールされたUbuntu上に、以下の5つのコンテナが存在する。
– VyOS1(192.168.1.1/24 & 172.16.100.100/24)
– VyOS2(172.16.100.200/24 & 10.30.100.1/24)
– VyOS3(192.168.1.2/24)
– VyOS4(10.30.100.2/24)
– OpenFlowController(Docker Default Network)

以下に簡単なトポロジーを示す。
VyOS3(192.168.1.2)-(192.168.1.1)VyOS(172.16.100.100)-(172.16.100.200)VyOS2(10.30.100.1)-VyOS4(10.30.100.2)

解説

この問題は、OpenvSwitch上でOpenFlowを動かしたもの。

まず、この問題の初期状態は、このようになっている。

OVSの設定を

sudo ovs-vsctl show

で確認すると、VyOS3-VyOS1,VyOS2-VyOS4では、

sudo ovs-vsctl set-fail-mode br0 standalone
sudo ovs-vsctl set-fail-mode br2 standalone

で設定してあり、L2スイッチとして動作している。
次にVyOS1-VyOS2では、

sudo ovs-vsctl set-fail-mode br1 secure

で、OpenFlowのエントリーによって処理されている。
そこで、

sudo ovs-ofctl dump-flows br1 --protocols=OpenFlow13

でエントリーを確認できる。
エントリーでは、図に書いてあるようなIP変換のみ処理されている。
ここでarpによるmacアドレスの解決ができないことに注目する。
なのでVyOS1とVyOS2でお互いにstaticでmacアドレスをお互いに登録する。
しかし、VyOSのconfigにインターフェースの設定を書いた場合、OVSにインターフェースの主導権をとられているため、反映されない。
VyOS1とVyOS2には以下のコマンドでvbashに入る

docker exec -it vyos1 /bin/vbash
docker exec -it vyos2 /bin/vbash

そして、linuxの処理として

arp -s 172.16.100.100 "VyOS2のmacアドレス" dev eth1
arp -s 172.16.100.200 "VyOS1のmacアドレス" dev eth1

staticでmacアドレスと登録する。
これでL2を解決できた。
次に、VyOS3からVyOS4にICMPパケットを飛ばすには、
VyOS1で

docker exec -it vyos1 /bin/vbash
su - vyos
configure
set protocols static route 10.30.100.0/24 next-hop 172.16.100.200
commit
save

のように設定する。
この設定で、ルーティングができるようになったのでICMPパケットが飛ぶ。

これでSDNの一端であるOpenFlowを用いた問題は解決である。
SDNでは、arpやDHCPなどL2の処理をプログラムしなければならない煩わしさがあるが、この問題のようにトポロジーを工夫することで、こういったNATやファイアーウォールなどのフィルターを、簡単に書き導入することが可能である。
ICTSC7では、運営でNAVT(Network Address Vlan Translation[作問者命名])と呼ばれるVLAN+IPaddressを全く別のIPに割り当てることでそれぞれのチームのセグメントIPを同じにし、運営からは、任意のIPアドレスで全チームにアクセスできるようにした。

 

 /

伝統の国 第3のトラブルの問題解説を以下に示します。

問題文 

NAT-PTの問題を解決した後、再びドワーフが話しかけてきた。

ドワーフ「2つもトラブルを解決してくれるとは驚いた。俺とあんたたちはもう家族も同然だよな? だから最後にあと1つだけいいか?」

エイト「え~まだあるの?」

ドワーフ「実は新しく喫茶店の支店作っていてなぁ~。そことIPsecで魔法陣をつなぎたいんだが、うまくつながらないんだ。なんとかしてくれよ~俺たち家族だろう?」

エイト「もう~調子がいいんだから。何度もごめんね。これだけ手伝ってあげてくれない?」

トポロジー図

採点基準

  1. IKEPhase1の成功が確認することができる。
  2. IKEPhase2の成功が確認することができる。
  3. 参加者手元PC及びルータからpingコマンドが通ることを確認することができる

解説

今回、1841と1941双方のルータには、通常のIPsec(NAPT前のアドレスによる記述)が設定されていました。
そのため、真ん中のルータにより、NAPT変換されることによって正しく通信が行えない状況でした。
今回はTEDによる解決方法による解答方法を記述します。(別解は後述)
1841に設定されたIPsecの記述を全て消した後
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
crypto isakmp keepalive 30 periodic
crypto ipsec transform-set T-IPSEC esp-3des esp-md5-hmac

これによりTEDによるIKEPhase1が成功します。
次に
crypto map M-IPSEC 1 ipsec-isakmp
set peer 192.168.140.2
set transform-set T-IPSEC
match address 101

interface Gi0/0
crypto map M-IPSEC

以上の記述でIKEPhase2が成功します。
そして、対向からのpingですが、帰りのパケットに対するルート情報が記述されていないため
ip route 192.168.130.0 255.255.255.0
を追記します。
別解としては、NAPT変換されていることが根本的な問題ですから、IPsecのアドレスをNAPT後のアドレスにすれば解決することができます。

まとめ

いかがでしたか?
この問題は基準点以上の正答チームは7チーム(前問のtypo)中1チームでした。
真ん中のルータを触れなくした理由は単純に真ん中のNAPTルータの設定を消すことを阻止するためでした。
debugコマンド、手元環境の論理図を書くこと等を用いると解答しやすかったのではないかと思います。

 /

こんにちは,ぱろっくです.

妖精の国 第二のトラブルに関する解説を書かせていただきます.

問題文

国から国への船旅の途中、激しい嵐に遭った。荒れ狂う海の中で波に流され、気がつけば小さな島に漂着していた。

エイト「何とか元の航路に戻りたいけど……船の修理が終わるまでこの島で過ごすことになりそうね」

探索していると、島の中央に神殿があることに気づいた。神殿の柱には見知らぬ文字と美しい模様が刻まれていたが、何を表しているのかはわからなかった。そして、祭壇には大きな黒い箱が安置されていた。

エイト「何だろうこの箱……ってサーバじゃない」

詳しく調べてみると、そのサーバは強大な力を持っていることがわかった。そして、その中には先人の訪れた形跡があった。

エイト「どうやらこのサーバの力を試してみようとしたけど、途中で力尽きてしまったようね。この強大な力を使えれば、魔法の研究や応用が爆発的に発展するに違いないわ! よくわからないけど、私たちで動かしてみましょう」

採点基準

  1. CUDAのシンボリックリンクがcuda-8.0ではなくcuda-7.5にはられているのに気づき,修正してmakeが通るようになっている.
  2. GPUのスレッド数をTitanXの上限まで落としてsuccessと出力できている.

解説

この問題では,近年流行しているGPUプログラミングに関するものでした.普段触ったことのない方には新鮮に感じたと思います.これをきっかけにGPUプログラミングに興味を持ってもらえたら嬉しいです.

今回起きていたトラブルは,まずCUDAを新しいバージョンに入れ替えた際にシンボリックリンクが張り替えられていない問題が発生していました.

makeファイル内で記述されていたコンパイル時の-arch及び-codeコンパイラオプションをTitanX(pascal)に合わせていたのですが,古いバージョンの方にシンボリックリンクがはられたままであったためコンパイルが通りませんでした.

そのため,まずシンボリックリンクを張り替えれば,このトラブルは解決し,コンパイルが通るようになります.

次に,実行ファイルの出力がfailedになってしまうトラブルが起きます.

これは,ファイル内でGPUの1ブロックあたりのスレッド上限数である1024を超えてしまい,処理が正常に行われていないため起こるトラブルです.

そのため,ソースコード内のスレッド数の指定を1024以下に変更するなどの対策をすればトラブルが解決しsuccessと出力されるようになります.

まとめ

以上が本問題の解説となります.

この問題は,さくらインターネット株式会社様の「高火力コンピューティング」サービスから機材提供をしていただきました.ご提供していただき本当にありがとうございました.問題提供していた環境を普段も使いたいという方はこちらをご参照ください.

 /
カテゴリー

問題文

一行は学校に行ってみたいというエイトの夢を叶えるために、学校を訪れた。

エイト「ここが学校か~、頭が良さそうな感じがしていいわね!」

女の子「いっけない、遅刻遅刻〜」

「「いたっ!?」」

女の子「ごめんなさい。昨日から魔法陣は動かないし寝坊して遅刻するし踏んだり蹴ったりだわっ」

エイト「最後は自分のせいなんじゃ……。ちょっと待って! この人たちなら力になれるかもしれないわ!」

女の子「学内のWebページにも繋がらない。色々触ってみたけど無理だったの……DNSサーバが原因じゃないかと思うんだけど」

エイト「うーん……。いったいどのあたりを触ってみたの?」

女の子「学内のWebサーバに繋がらなくて、でも学外のWebサーバには繋がってたの。よくわからなくて、スイッチも設定を見ていろいろやってたら今度は学外サーバにも繋がらなくなっちゃって…もうよくわからないわ」

エイト「なんだか他人事とは思えないわ……助けてあげてくれない?」

達成すべき事項

  • http://devtest.dns.1.mgi(コンテストネットワークでのみアクセス可能なドメイン)から任意のHTML(テストページを含む)を取得する。
    • スイッチ(2960-A_fa0/11)に接続したPCのDNSをdns.1.mgi(192.168.19.10) に設定した上でアクセスできることが達成条件です。

解説

発生していたトラブルは
① 手元のスイッチからDNSサーバへ疎通が取れない
② DNSサーバが学内ドメインの名前解決に失敗している
の2点でした。

トラブル①について

お手持ちのPCとスイッチを接続しIPアドレスを設定してもDNSサーバへ疎通が取れなかったと思います。
ここでスイッチのコンフィグを見てみると、

 interface FastEthernet11
 switchport access vlan <各チームに割り当てられたVLAN ID>
 switchport mode trunk

となっています。
“switchport mode trunk”を削除するか、”switchport mode access” と設定をしてあげることでトラブル①は解決します。

トラブル②について

用意されたDNSサーバに対して学外ドメイン(google.comやyahoo.co.jpなど)の名前解決を行う場合はしっかりIPアドレスが返ってきます。
一方で学内ドメイン(devtest.dns.1.mgi)はIPアドレスが返ってきません。しかし、会場に提供されていたWi-Fiを経由して運営が用意したDNSサーバを使ってdevtest.dns.1.mgiにアクセスすると、正常に名前解決は成功し、テストページを開くことができました。
女の子が用意したDNSサーバに何か問題がありそうです。

DNSサーバにはdnsmasqがインストールされていました。何かあったときはエラーログです。/var/log/syslogを見てみると

 Aug 25 11:19:23 dns daemon.warn dnsmasq[18697]: possible DNS-rebind attack detected: devtest.dns.1.mgi

のような出力がされています。
DNS-rebind attackとは、

DNS Rebindingは、DNSの返すIPアドレスを巧妙に変化させることにより、JavaScriptやJavaアプレットなどのsame origin policyを破り、インターネットからローカルネットワーク(通常外部からはアクセスできない)などに対してアクセスする手法をいう。

DNS Rebinding ~今日の用語特別版~ – 徳丸浩の日記より引用)

と説明されています。TTLを極端に短くした状態で(5秒など)ターゲットに悪意のあるドメインへアクセスさせ何らかのスクリプトを読み込ませます。その後、攻撃者は悪意のドメインのレコードをプライベートIPアドレスへ変更することで、攻撃者はスクリプトを使用して情報取得を行うことが可能となります。

先ほどのdnsmasqのログは 「DNS Rebinding攻撃と思われる挙動を検知した」、と言っていることがわかります。
思えば、devtest.dns.1.mgiのレコードを引くと返ってくるのはプライベートIPアドレス(172.16.67.2)です。

となれば、dnsmasqの防御機能を無効化する or ドメインのホワイトリストを設定してあげればOKです。

/etc/dnsmasq.confを見てみると、

 stop-dns-rebind

という設定が末尾に書かれています。これをコメントアウトしdnsmasqを再起動すると名前解決ができるようになります。
あるいは、

 rebind-domain-ok=1.mgi

という設定を加えることでも名前解決ができるようになります。

余談

どちらのトラブルも私の実体験で起こったものです。
トラブル①に関しては、スイッチの設定をあれこれいじったり試していて、いつの間にかこうなっていた…というトラブルでした。
トラブル②に関しては、大学の研究室に一時的にOpenWRTを載せたルータを設置したときのことでした。Webアクセスは問題なく行えるのに、なぜか学内のNTPサーバに対する時刻同期が出来ないと研究室のメンバーに言われ、最初は学内のNTPサービスが終わっちゃったんだなあ…と思ってました。IPアドレスが返ってこないということは抹消されたんだな、と。授業中、ふと学内無線LANを使用してNTPサーバの名前解決を行ったところ、消えたと思っていたIPアドレスが返ってきました。奴は生きていた。帰ってきたんだ…。ここからは必死に原因を調査して解決した…というお話でした。

 /
カテゴリー

荒廃の国 第一のトラブルの問題文

ドワーフが経営している寂れた宿に訪れた。

ドワーフ「いらっしゃいませ……何もないところですがごゆっくりしてください……。」

エイト「ありがとうございます。 あれ? 宿の魔法陣が繋がらないわ?」

ドワーフ「すいません……。盗賊対策にACLを書いたんですが、繋がらなくなって困っているんです……」

エイト「なるほどね。これはあんたたちの出番じゃない?」

達成すべき事項

参加者手元PCからloopback0にpingが通る。

概要

この問題では、ACLとVRFサポートの設定の不備によりIPアドレスが付与されなくなっていたため、そもそもPCにIPアドレスが付与されていないことに気付く必要がありました。

この問題は、ACLとVRFサポートの設定の両方を変更することで解決できます。

問題の達成条件はpingを通すことだったので、手動でIPアドレスを設定することで達成できますが、DHCP問題を解決することで追加点がありました。

解法

以下の設定をすることで、DHCPの問題が解決されます。

ena
conf t
ip access-list extended guild
permit udp any any eq 67
exit
ip dhcp use vrf remote
exit

講評

前回に引き続きVRFを使用した問題を出題しましたがいかがだったでしょうか?

参加者の解答状況は前回よりも多くなっていたため、過去の問題解説からVRFの対策をしていたように見受けられましたが、手動でIPアドレスを設定して通過するチームが多くDHCPの問題まで解決できているチームはほとんどいませんでした。