/

こんにちは!ICTSC8 問題リーダーの中西です。

大変遅くなりましたが、ICTSC8で出題された全問題の問題解説を公開します!
解けた問題は別解法の確認を、解けなかった問題は次回から解けるようになるために、是非勉強にお役立てください!

 


始まりの国

始まりの国には、様々な種族が住んでいる。エイトもこの国の出身である。
立地からか、外国との交流が盛んで旅人も多い。

永遠の国

エルフは魔法を使って生活を便利にすることが上手な種族である。
エルフの国はたくさんの村から構成され、村を指導する長は村人の尊敬を集めている。

謎の国 ICTSC

この国は未だに多くのことが謎に包まれている。
外国との交流は少なく、内情を知るものはほとんどいない。
一説では、政府が強大な力を持ち、魔法陣を使った交信を厳しく制限しているという。

荒廃の国

かつては栄えた国だったが、長く続いた内乱のせいで今は見る影もない。
治安は悪く、盗賊が人々を悩ませているという。

伝統の国

この国はドワーフを中心に構成されている。
ドワーフは何よりも繋がりを大切にしている種族である。
しかし自分の種族以外の人を冷たい目で見ることがある。

研究の国

この国では研究が盛んであり、教育にも力を入れている。
国の各地に学校があり、見習い魔導師たちが机を並べて勉強している。

ホビットの国

この国には、サーバが得意なホビットがたくさん住んでいる。 ホビットは商売が上手く、この国最大の会社であるホビットカンパニーは他国にもその名を轟かせる。

妖精の国

妖精の国がどこにあるのかは知られていない。しかし、たまに迷い込む者がいるという。妖精は様々なものに姿を変えて、出会ったものを惑わすと伝えられている。

 /

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

今回は、リソース削減・ネットワーク基盤に依存しないために全て一つの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アドレスで全チームにアクセスできるようにした。

 

 /

問題文

一行は妖精を研究している学者のところへやってきた。長年研究している学者でさえも、妖精についてはまだわからないことが多いらしい。学者が持つ貴重な妖精の文字や、書物に残る記録を見せてもらうことができた。

学者「そうだ、あなた方は凄腕のトラブルシューターと聞きました。是非あなた方にお願いしたいことがあります」

エイト「色々教えてもらったし、もちろん良いわよ!」

妖精のことを話してもらったお礼として、依頼を引き受けることにした。

学者「試しに妖精の国の言葉を使ってサーバのアドレスを設定してみたのですが、アクセスできないんです。DNSサーバに書き込む呪文をどこか間違えたと思うのですが……調べてみてくれませんか」

アクセスできるサーバ

| ServerName | Hostname   | Address       | User  | Password   | Note       |
| ---------- | ---------- | ------------- | ----- | ---------- | ---------- |
| nsd-master | ns1.2.fy   | 192.168.22.53 | admin | ByeByeBind | DNS master |
| nsd-slave  | ns2.2.fy   | 192.168.22.54 | admin | ByeByeBind | DNS slave  |
| cache      | cache.2.fy | 192.168.22.70 | admin | ByeByeBind | DNS cache  |

Webサーバ一覧

| ドメイン名          | IPアドレス    |
| ------------------- | ------------- |
| χητηολλψ.fy | 192.168.22.81 |
| ιτηεα.fy       | 192.168.22.82 |
| νεπηρεν.fy   | 192.168.22.83 |
| ρηαντολκ.fy | 192.168.22.84 |
| νοπητ.fy       | 192.168.22.85 |
| τιατ.fy         | 192.168.22.86 |

注意事項

セキュリティ周りの設定を無効化せずに解決すること。ただし、トラブルシューティングの間、検証目的での無効化は行っても良い。

達成すべき事項

192.168.22.70 をリゾルバに設定したPCからドメインを引き、ブラウザ上でそのドメイン名が書いてあるページを開くことができる。

解説

Punycode問題です。

国際化ドメイン名をPunycodeに変換していないままレコードを登録したため、レコードを引けないという状態になっています。
解決するには各ドメイン名をPunycodeに置き換える必要があります。

変換方法はlibidnなどのパッケージに含まれるidnコマンドを使用する方法もありますが、Punycodeでググると変換を行ってくれるWebサイトが引っかかるので、そちらで変換しても問題ありません。

変換を行うと以下のようになります。

χητηολλψ.fy → xn--sxaamas2ato.fy
ιτηεα.fy → xn--mxahfh9c.fy
νεπηρεν.fy → xn--qxaafwdpi.fy
ρηαντολκ.fy → xn--mxalkdjmk1a.fy
νοπητ.fy → xn--sxalgev.fy
τιατ.fy → xn--mxap6ac.fy

後はこれに合わせてzoneファイルを書き換えればいいです。
また、Slaveにも変更を適応させるため、SOAレコードのインクリメントも行います。

最後にDNSSECの再署名を行います。
鍵ファイルは/etc/nsd/内に、Kfy.+007+40373といった名前で二種類置いてありましたが、ファイルの中身を見ればZSK、KSKのどちらの鍵ファイルか分かるようになっていました。

鍵ファイルの中身はこのようになっています。(当日の問題で使用されていたファイル名と内容とは若干違いがあります)
(zsk)(ksk) という記載があり、ここで判別できます。

$ cat Kexample.com.+007+15443.key
example.com. IN DNSKEY 256 3 7 AwEAAdPhQCgp0125MKKcYGwQMjUg9H12gk70eZDoLHDYYR25nEQ5rTY296E9+9sl91Q6QmbAz5XA9lWwB+oJYGU1+DZA6S3c4ZxAz8ib1yuiWOmKCGiT+xIunULcMEMKP05eDddOf+6kouxazSFMmRjlB4CwWfxWnWGG1aevwOuMoK3H ;{id = 15443 (zsk), size = 1024b}

$ cat Kexample.com.+007+12753.key
example.com. IN DNSKEY 257 3 7 AwEAAdvhV55tAUr/CgnxSGw+Zfaj+OxxKiUskreYqrImF4YIHCpAGxBQgisC1MsaAxXz6gY8IZdtnOdf7+XOo2If4H1wnvwAIBuf7/Jw2z2qVAso6u1ok4xGDcUxA1WAnmqFWAGyEEEAQITnqT2gGN5TBN/UeM4WagcC8efuYXZJRm81oMhCg8jS/0U62VEu0HZb3fjauBVXBV7wug02SlohwVe2+JrdY9U59O5FdxOeGU1WWYYwpSCOnYUAG6ijWIv2KjPfK4o0B+Mn+jECwk9pvrHg7HwnP7cwNidWqRLzO49KklakhcwSrjMEoPYcsfZ7O/j/RxBKqv4NqsuanMoDxGE= ;{id = 12753 (ksk), size = 2048b}

署名を行うコマンドは以下のとおりです。
署名を行うと、 fy.zone.signed ファイルが再生成されます。

sudo ldns-signzone fy.zone $ZSK $KSK

ちなみに、解答してくれたチームはどのチームもPunycodeへの変換部分までは解答してくれていましたが、DNSSECの再署名まで行っているチームは2チームだけでした。

 /

問題文

旅を続ける一行は、通りかかった小さな村に一夜の宿を借りることにした。一軒一軒民家を回っていたが、泊めてもらえるどころか人の姿さえ見当たらなかった。
半ば諦めながら最後の民家の戸を叩くと、赤い帽子を被った男が出てきた。

男は快く一行を受け入れてくれた。家の中で男にこれまでの冒険を話すと、かなり興味を持ったようだった。

男「色々な国でトラブルを解決してきたようだな。それなら、君たちの実力を見せてほしい」

男はそういって銀色の平たい箱を取り出した。

エイト「それは?」

男「これは俺が昔遊んでたサーバさ。CentOSが大好きでね。ちょうどいい、webサーバを構築して見せてくれないか」

エイト「セントオーエス…遷都を応援してるのかしら?」

サーバへのアクセス情報

  • サーバ名: centos
  • アドレス: centos.1.fy
  • ユーザー名: centos
  • パスワード: CentOSL0ve

達成すべき事項

  • Apache をインストールする。
  • hello world! と書かれたファイルを用意し、hello world! をブラウザで表示させる。

解説

この問題文を要約すると、「CentOSが大好きな赤い帽子を被った男に、昔遊んでいたサーバーにWebサーバーを構築してくれと腕試しをされた。」という問題です。

この問題はトラブルシュートというより、おまけの知識問題となっています。

おそらくApacheのインストールを行おうと yum コマンドを叩くとエラーが返ってきたと思います。

そこでおもむろに cat /proc/version を叩くと以下の内容が返ってきます。

Linux version 4.13.3-1-ARCH (builduser@tobias) (gcc version 7.2.0 (GCC)) #1 SMP PREEMPT Thu Sep 21 20:33:16 CEST 2017

そうです、実はこのサーバーのOS、CentOSではなくArchLinuxだったのです。
問題文を見ると、CentOSが大好きと言ってはいますが、サーバーのOSがCentOSだとは言ってないですね。

男「これは俺が昔遊んでたサーバさ。CentOSが大好きでね。ちょうどいい、webサーバを構築して見せてくれないか」

サーバ(CentOSとは言ってない) というのに気づければokです。

ArchLinuxでは pacman をパッケージマネージャとして利用しているので、以下のコマンドを使用することでインストールすることが出来ます。

$ pacman -Syyu apache

また、ArchLinuxではsystemdをinitとして使用しているので、systemctlを使用してサービスを起動します。

$ systemctl start httpd
$ systemctl enable httpd

hello world! ページですが、 httpd.conf から DocumentRoot を探せばindex.htmlを置く場所が分かります。
今回は /srv/http ですので、そこに index.html を置けば完成です。

$ grep DocumentRoot /etc/httpd/conf/httpd.conf
# DocumentRoot: The directory out of which you will serve your
DocumentRoot "/srv/http"
    # access content that does not live under the DocumentRoot.

$ sudo sh -c "echo 'hello world!' > /srv/http/index.html"
 /

問題文

ホビットカンパニーの社長からの1つ目のトラブルを解決した後、社長が嬉しそうに話かけてきた。

ホビット社長「やっぱり君たちにお願いしてよかったよ」

エイト「褒められてるわよ、やったじゃない!」

すると社長が独り言のように呟いた。

ホビット社長「もしかしたら…君たちならあのトラブルを解決してくれるかもしれないな」

エイト「何かあるんですか?」

ホビット社長「実は我が社でOpenStackを構築したのだが、何故かログインできないのだ。もしよければ解決してくれないか?」

アクセスできるサーバ

  • OpenStack All-in-One がセットアップされたサーバ1台のsshのアクセス情報 (sudo権限あり)

達成すべき事項

  • OpenStack Horizon のダッシュボードを開ける状態にする

問題内容

ICTSC7 の運営側で実際に起きたトラブルを(厳密ではないですが)再現したものです。今回は電源に関するトラブルがありましたが、ICTSC7 ではこのようなトラブルがおきており、しかもその際には HotStage 期間に3日を費やすも原因が究明できず、お蔵入りとなったのでありました。

OpenStack Horizon は Python で書かれた WSGIアプリケーションで、OpenStack の各コンポーネントのフロントエンドとしての機能を果たすコンポーネントです。
Horizon の設定ファイルは主に /etc/httpd/conf.d/15-horizon_vhost.conf と /etc/openstack-dashboard/local_settings に記述されていますが、今回は一方のみを変更しています。

この中で、認証サーバである Keystone のエンドポイント等を指定しているのですが、その際に Keystone の API バージョンを誤って指定したことによりトラブルが発生していました。

具体的には、以下の部分を変更して出題しました。

/etc/openstack-dashboard/local_settings 200行目付近

OPENSTACK_KEYSTONE_URL = "http://10.0.0.20:5000/v2.0"

変更後 (問題が起きている状態) は以下です。

OPENSTACK_KEYSTONE_URL = "http://10.0.0.20:5000/v3.0"

回答例

まず、認証情報ですが /root/keystonerc_admin に openstack コマンドを使用する際に使用する認証情報(IDとパスワード等) が記述されています。

問題内容の節にて述べた設定ファイルの変更を元に戻し、た上で、Apache のリスタートを行うことで問題が解決します。
また、Apache をリスタートしてもブラウザからログインができず、エラーもでずにログイン画面からログイン画面にリダイレクトし続ける状態になることがありますが、これはブラウザのセッション(クッキー)を削除することで解決します。
(これについては Keystone 等にも特にエラーログが流れないので、解決に苦労した方もおられるかもしれません。)

想定解は上記の通りでしたが、OPENSTACK_KEYSTONE_URL = "http://10.0.0.20:5000/v3" にすることでも問題が解決するようでした。このあたりは OpenStack のバージョンにも依存してきますね。

講評

/root/keystonerc_admin を使用してのopenstack コマンドを用いた操作は正常に行えることから、 Keystone 側の設定がおかしいわけではないということがある程度予想できます。

その上で、Horizon にのみログインできないという挙動から Horizon の設定における Keystone 関連のエンドポイントのパスやバージョンを確認するというのが運営側の想定解答方針でした。

本問のトラブルは、 OpenStack Ocata では起きないため、意図的に OpenStack Newton を使用して構築された OpenStack 上でのトラブルでした。このバージョンからトラブルに気が付いた方もおられたのでは無いでしょうか。

前回の運営委員が解決できなかったということを踏まえ 、配点がかなり高い問題でしたが、6チームから解答を受け、4チームが正解されました。

おわりに

なかなか OpenStack を手で構築したという方は少ないかもしれませんが、そのような経験があると、全体のコンポーネントの関連性や設定についても理解が深まるため、一度行われてみると良いかもしれません。

 

 

 /

こんにちは、電気通信大学 学部3年の中西建登です。
第4回はRedmine問題を出題し、問題解説を一人でやっていたのですが、
今回は運営メンバーのやる気を出すことに成功し、皆様に全ての問題に於いて問題解説を皆様にお届けしています。

今回は(今回も)OSSを用いた問題を出してみました。2日目午後に唯一出た問題として、所謂「ラスボス」という立ち位置で出題させて頂きました。
Rails系のOSS問題という事で、前回の問題文をもじって問題名を「GitLabの意図しない挙動の調査について」としてみました。前回も参加してくださった方にクスッとして頂ければなという狙いでしたが、如何だったでしょうか?(笑)

さて、ではここから問題解説をお届けします。

続きを読む

 /

ICTSC5お疲れ様でした。
電気通信大学の吉村弘基と申します。

今回は僕が問題を作成した「管理画面が見えない」という問題の解説を行っていきます。

問題文

弊社では社内ネットワークを見直すこととなった。
しかし、ネットワークの見直しを行い、変更作業を完了した後に、社内の管理画面にアクセスできなくなった。
管理画面にアクセスしようとするとよくわからないサイトが表示されるようになってしまい困っている。
自分の部署(参加者手元)から管理画面が見えるように設定を修正して欲しい。
また、ネットワークの見直しにあたって追加でslaveのDNSサーバを構築することとなった。
元々DNSサーバを管理していた担当者は「日付を間違えた」とだけ言っていたが何のことなのかよくわからないが何のことか分かれば修正してくれ。
とにかくまずはBINDをインストールし、設定を行って欲しい。
その際、セキュリティに気をつけて、設定を変更を行ってくれ。

原因

・ゾーンが複数あり、BINDのView機能によって参加者の手元からは本来見えるべき管理画面とは違うものが見えている

・iptablesによってUDP 53番が許可されていない

 

解決方法

  1. BINDの設定を書き換え、参加者の手元から正しい管理画面が見えるように設定する

  2. iptablesの設定を変更し、UDP 53番を許可する

  3. slaveのDNSサーバの設定をする

  4. ゾーンファイルのシリアルが3016022701などと1000年分ほど進んだ値になっているので正しい値に修正する

出題意図

将来的に頻繁に触ることになる人も思われる、DNSサーバとして有名なBINDには様々な機能があるので、それを知ってもらおうと思って出題しました

採点時に重要視したポイントは解決方法の1. 2番です。

出題側としては間違った管理画面を安易にどこからも名前解決できないようにするのは避けて欲しかったのですが、それに関しては若干問題文が不足しており、誘導が不十分だったと思っています。

 

最後に

チーム16の大人チームから「BINDは最終手段であり、使うのはあまり推奨されるものではない」とのコメントを頂き、私としても新しく知ったことも多かったです。

もし、次回以降も運営として参加することがあればもうすこしまともな問題を出せればと思っています。

参加者の皆様、ありがとうございました。

 /

みなさんこんにちは. 2日目午前の問題 (サーバーが再起動する!) を作成した市川です.

本問題の背景 (CVE-2015-5600の概要)

OpenSSHでは,LinuxのPAMモジュールを利用することで認証プロセスをアプリケーションから分離して行うことができます.パスワードを用いた認証には大きく分けて2種類の方法があり,

  •  PasswordAuthentication
  •  ChallengeResponseAuthentication

です.

いずれの方法もLinuxに登録されているユーザーの認証情報を用いてログインを行いますが,PasswordAuthenticationが平文でパスワードの照合を行うのに対し,ChallengeResponseAuthenticationはチャンレンジレスポンス認証を用いるため平文パスワードがネットワークを流れることはありません.(もちろんSSLで暗号化されているため平文ではないが,復号するとパスワードがそのまま見える,という意味です.)
以上の理由からChallengeResponseAuthenticationが用いられることはそれほど珍しくなく,また鍵の設置を必要としないため緊急時のログイン手段としてはよく用いられます.

さて,ChallnegeResponseAuthenticationを行うデバイスにはbsdauth, pam, skeyがあり,これらを指定することで認証デバイスを順に試すことができます.今回用いた脆弱性CVE-2015-5600は,このデバイスにpamをカンマ区切りで大量に指定することで,パスワード認証の本来の上限回数を超えて試行出来てしまう,というものです.

問題文

最近サーバー(10.X.10.2)が頻繁に再起動して困っている.
原因調査と問題解決をお願いしたい.
また,報告する際には

  • 何が原因だったのか
  • それに対しどのような対処を行ったか

を明記していただきたい.
また,サーバーに何らかの脆弱性が存在する場合は必ずその箇所を修正すること.

解説

問題が公開されてからしばらくすると,CVE-2015-5600を悪用したブルートフォース攻撃が開始されます.攻撃対象のユーザーubuntuのパスワードは12345に設定されており,10000から順にインクリメントしながら攻撃を行います.ログインに成功したらすぐにsudo rebootを行い,作業妨害を行うことを繰り返します.
なお,Linuxの標準の設定ではPAMモジュールにfaildelay (ログインが失敗した際,強制的に待ち時間を入れるモジュール)が設定されており,これでは競技時間内にブルートフォース攻撃を複数回仕掛けることは困難でした.そのため/etc/pam.d/以下のfaildelayに関する設定を全て解除,無効化し,1秒間に最大で約10回のパスワード入力が試行できるよう細工を施しました.

この問題を解決するためには,

  • ChallengeResponseAuthenticationを無効にする
  • 公開鍵認証方式に変える
  • /etc/pam.dの不適切な設定を修正する

などの対策を講じることで解決できます.(以上3点が揃った解答に対しては満点を与える予定でした.)

講評

ほとんどのチームが

  • 特定の端末 (攻撃サーバー)からのアクセスを制限
  • ubuntuユーザーの設定を変える (パスワード変更,sudo権限剥奪,ユーザー削除)

など,根本的な解決に至っていない解答をしていました.そのため問題文に
また,サーバーに何らかの脆弱性が存在する場合は必ずその箇所を修正すること.
の部分を強調して再度周知したものの,完全な正解に至る解答は見られませんでした.
麻生情報ビジネス専門学校チームが唯一CVE-2015-5600に言及しており,高い得点を与えましたが,PAMの設定不備を指摘したチームは1つもありませんでした.

 /

はじめまして。本問題の雑用係をしています工学院大学の福田夏樹と申します。

問題解説のブログを書いて欲しいというリーダからのお願いを受けて、締め切りギリギリになって本記事を書き始めました。

拙文ではありますが、問題解説をさせていただきます。

問題概要 : Webページが見られない

問題文

本日、我が’boku-tech company’のカスタマーサービスセンターから、
「Webページに接続できない。接続できても重い」
という苦情が寄せられていることが判明した。
また、数日前に新しいサーバが納品され、社内のネットワークのどこかに接続されたようだ。
しかし、その作業は外部の業者が行っており、ネットワークや納入されたサーバの状況を社内で知っている人はいない。

今回に限り、優秀な技術者と聞く君たちに該当のサーバ類の一部の操作権を付与する。
現状を調査した上でその解決をし、その原因と解決方法を報告してほしい。
なお、サーバ上では各種サービスが動いているらしいが、それらや他のサーバを完全停止することはできない。

我が社が作業を外注した時の資料を入手することができた。
その資料には下記の制約が書かれていた。
この制約を満たすように設定・定義してもらいたい。この制約に反しないかぎり、他の設定を変更しても構わない。

  • webサーバーのリソースをsnmpプロトコルを用いてサービスサーバにログが残させる事
  • Service Server に対して、ドメイン “service.rabbit” のAレコードが引けること
  • webサーバに含まれるコンテツの再生が出来る事

君たちが操作できるサーバは下記のとおりである

Service Server

  • IP : 10.X.8.66
  • User: admin
  • Password : チームごとに与えられているもの

Web Server

  • IP: 10.X.8.2
  • User: admin
  • Password : チームごとに与えられているもの

Router
– IP : 10.X.8.192
– User: vyos
– Password : チームごとに与えられているもの

トラブルの原因

まずは、トラブルを起こしていたトポロジ図は下記のようになります。

トポロジ図

今回の問題でトラブルとして使用したものは次のものです

  • SNMP のリクエストによるCPU枯渇
  • Ping パケットの大量送信による帯域枯渇
  • SYN Flood によるセッション数枯渇

その他、仕込んでいたトラブルも有りましたが、そのあたりは ICTSC5の1日目にあったLTの資料をご参考にください。

解決方法

上記のトラブルの原因を一つ一つ解決していけば解決できます。

代表的な解決方法を上げると、以下のようになります。

SNMP

SNMPのコミュニティ名をデフォルトである public から任意のものに変更する。

今回の問題では、/etc/snmp/snmpd.conf に記述されている public という文字列を任意のものに書き換えることができれば解決になります。

Ping

VyOS にて、ICMPのフィルタリングをする。

フィルタリングの方法は複数あるので、コマンドは省略しますが、検索をかけるといくつか出てきます。

SYN

サーバOSのSynCookieを有効化する。

今回の問題の場合は、次のコマンドを入力すると解決になります。

 

sysctl -w net.ipv4.tcp_syncookie=1

 

などあります。

その他の解説などは、本問題担当であった法政大学の伊東氏がLT資料ブログを書いているので、ご参考にしてください。

出題意図

近年世界的に起きているDoS攻撃の基本的な対策方法を日本の若きエンジニア達に知ってほしいため、
また、前回大会において出題されたセキュリティ攻撃に関する問題においての解答率が出題者の想定よりも低かったため、本大会では攻撃の種類を変えて、再度出題しました。

採点基準

問題文に記述されている

  • webサーバーのリソースをsnmpプロトコルを用いてサービスサーバにログが残させる事
  • Service Server に対して、ドメイン “service.rabbit” のAレコードが引けること
  • webサーバに含まれるコンテツの再生が出来る事

を満たす様な設定ができているかを判断しています。

簡単に言うと、原因となっている攻撃がフィルタリング等できていれば得点が入る様にしました。

最後に

問題を解いたみなさんは、解けた時はとても嬉しいと思いますが、
実は出題者側も、みなさんが解いてくれた時は嬉しかったりします。

本問題は一般的にはDDoS攻撃という部類になり、その攻撃手法は今回のもののみではなく多岐に渡ります。
更に、その対処も難しいものとなっています。

セキュリティ的な脆弱性も、ヒューマンエラーによるものでも、ソフトウェアにある潜在的なものでも、トラブルの元となるということも知っていただければ幸いです。

では、又の機会にお会いしましょう。

作成者
麻生情報ビジネス専門学校 何 力平
概要
 RFC 3986では 予約文字(Reserved Character)と非予約文字(Unreserved Character)が定められています。
予約文字:区切り文字などの特定目的で用いるために予約されている文字であり、その目的以外ではURLに使用できません。
ファイル名には次の文字は使えません
: / ?  * < > | \
URLには次の文字は使えません(予約文字)
: / ? * # [ ] @ ! $ & ‘ ( ) + , ; =
パーセントエンコーディング(英: percent-encoding)とは URLにおいて使用できない文字を使う際に行われるエンコード(一種のエスケープ)の名称である。RFC3986のSection 2.1で定義されている。
一般にURLエンコードとも称される。
本問題ではURLにおいて使用できない文字を使い、ダウンロードできないようになっている。
問題文
あなたはABC社のCEです。
お客様から「会社新製品のマニュアルをダウンロードできない」というようなクレームが出ました。
  URL  http://192.168.1.1/product/question#20160227.txt
原因を分析し、その原因を説明する簡単な文章を提出してください。
ダウンロードしたマニュアルも併せて提出してください。
お客様の作業環境:
     Windows7/10+Firefox/Chrome/Iexplorer10/Iexplorer11
解決方法
解決方法は#をパーセントエンコーディングを使い、%23に替えることです。
http://192.168.1.1/product/question%2320160227.txt
講評
本問はネットワーク問題かサーバー問題か分類しにくいだけど、現実でよく出るトラブルです。
RFC 3986では予約文字と非予約文字が定められています。予約文字-区切り文字など特定目的で用いるために予約されている文字で その目的以外ではURLに使用できません。
それでWeb ブラウザが#や!や@などの予約文字があるURLを解読するときに認識ミスを起こしました。
解決方法は#をパーセントエンコーディングを使い、%23に替えることです。パーセントエンコーディングとは URLにおいて使用できない文字を使う際に行われるエンコードの名称です。一般にURLエンコードとも称されます。このような知識は教科書にも載っていないから、選手たちの知識の広さと深さが要求されます。

最近のコメント