Posts ICTSC2019 一次予選に出た話
Post
Cancel

ICTSC2019 一次予選に出た話

ICTSC (ICT トラブルシューティングコンテスト・トラコン) 2019 の一次予選に出たら 2 位になってしまったので自分の担当問題についてだけ記録しておきます. 先に言っておくと,チームで一番しょぼかったのであんまり期待して読まないでください. また,コマンドの実行結果等はすべてこの記事の初回執筆時のものです. 正答解釈等に誤りがありましたらコメントや Twitter までお寄せください.

ICTSC とは

https://icttoracon.net/ No.9 慶應義塾大学「味処まるたか」チームの最若手として出場しました.足引っ張らないかヒヤヒヤした(実際引っ張ったけど). チーム名の由来は SFC 生おなじみの海鮮料理屋です.勝手に拝借しました.

出場理由

先輩に「出ようぜ」っていわれたから.背景としては,B2 で今年度からインフラ・ネットワークの世界に飛び込んだけど研究テーマも見つからずぼーっとしてたので,やることというか目標を与えてもらったと思ってます.

結果

総合得点 1690 点で全 57 チーム中まさかの第 2 位を獲得してしまいました.さらに,慶應義塾大学 (本部三田キャンパス・東京都港区) ですがキャンパスが SFC (湘南藤沢キャンパス・神奈川県藤沢市) という条件も重なり本選進出 (二次予選パス) へのシード権も獲得しました.

自分の所感

めちゃくちゃ悔しいです.他チームの方からすると「嘗めとんのか?」と言われそうですが聞いてください.獲得 1690 点中私の得点はわずか 140 点,担当問題の配点は 300 点,個人得点率は約 47% **です.最若手とはいえ,半分も取れなかったことが非常に残念です. さらに,弊研究室は独自でメールサーバを運用しており,担当の院生がもうすぐ卒業する(予定)ことから,私が次期メールサーバ担当になると噂されているのですが,今回担当したメールの問題で惨敗**…..これが一番悔しいです.

問題の振り返り

上述の通り自分の担当問題だけを振り返っていきます.問題一覧と解答・解説は公式ブログに載っかっているのでそちらをご参照ください.

メールは届いてるけど…

問題詳細はこちら(何故かリンクタイトルがおかしい). 複数のメールのメールヘッダを読んで,その中から正常に配送されなかったものを探し出しその理由を答える問題です.

私の解答

お疲れ様です.味処まるたかです.
問題「メールは届いてるけど...」の回答を送らせていただきます.

この問題の回答は2つあります.

1. mail3
- 該当するメール: mail3
- 理由: ヘッダーの `Authentication-Results` を見ると,mail3では `spf=softfail (ictsc.net: domain of transitioning root@mx3.prob2019-q1.ictsc.net does not designate 103.202.216.33 as permitted sender)` となっており,このメールの送信元IPアドレスは正当な送信者のDNSサーバにsoftfailとして扱うよう登録されている(正当な送信元IPアドレスとして指定されていない)ことがわかります.このため,mail3はspamとして配送されている可能性がある,もしくは受信したユーザに対し警告が出るなど,期待していた配送が行われなかったと考えられます.

2. mail4
- 該当するメール: mail4
- 理由: ヘッダーの `Authentication-Results` を見ると,mail4では `dkim=neutral (invalid public key)` となっており,このメールを署名した秘密鍵と正当な送信者のDNSサーバに登録されている公開鍵が正しい鍵ペアではないことがわかります.このため,mail4はspamとして配送されている可能性がある,もしくは受信したユーザに対し警告が出るなど,期待していた配送が行われなかったと考えられます.

以上となります.よろしくお願いいたします.

コピペしてて恥ずかしくなってきた…

mail2

まず mail2 に関してはいわゆる spoofing (なりすまし) 状態なわけですが,完全に見落としていました.得点表と配点を見た限りだと,私と同じように mail3 と mail4 に気づいても mail2 を見落としたチームが多かったのではないかと勝手に思っています.コンテストだから良かったものの(?),実際のオペレーションではかなり多いスパムメールの種類だと思うので,見落としは絶対に許されません.あなたのアカウントは乗っ取られました.以下のリンクからパスワードをリセットしてください.とかね.ユーザが騙されてしまうと大変なことになります.ぱっと見でユーザが騙されてしまいやすいからこそ管理者が一番気を配らなければならないところでした.(ちなみに弊研究室では今年から spoofing メールに関しては自動でフィルタされるようになりました.)

mail3

spf の問題でした.上述の通り,ヘッダで「正規の送信元はこのサーバが正しいって言ってないらしいんだよね.けど同時に『そんなに厳しくしないあげてちょんまげ』っていってるよ」という状態 (softfail) です.この場合,(受信したメールサーバの設定によりますが) 普通はスパムメールとして配送したり,Gmail の場合だと受信箱には入るけど開けると警告が出る状態になったります.そこに気づいたのはいいんです. 次に私は当然 DNS に書いてあるspfのレコードを探します.そこで私が打ったコマンドがこちら.

1
dig TXT ictsc.net

はいアウト. これでは帰ってくる Answer Section はこうなっちゃいます.

1
2
;; ANSWER SECTION:
ictsc.net.    299 IN  TXT "ca3-c2c495a91b264da1a11f8d801cddd27b"

これでは spf のレコードを確認することはできません.しかし私は「そうか,これはコンテストだからメールは模擬メールで実際の DNS には spf レコードが設定されていないんだ!」と勝手に思い込んでしまったわけです.ここで spf レコードの参照方法をググってみたり運営に質問を送ってみたりしていれば気づけたはずでした.大失敗です.

mail4

DKIM の問題でした.こちらもヘッダで「この署名を検証するための公開鍵がなんかおかしいんやが….とりあえず検証のしようがないから怪しいって扱っとくな」という状態になっています.ここに気づいたはいいものの mail3 の解答を見てお察しの通り,またも同じコマンドで同じ失敗を繰り返しました.

接続が不安定になっちゃった

問題詳細はこちら.DHCP に従う設定になっているクライアント (Ubuntu) と静的 IP アドレスを指定して良いと思いこんでいるクライアント (Ubuntu) が混在する環境下で,VyOS で DHCP Server を動かすときに正常に IP アドレスが割り当てられない問題です.本来であればこのような状況でも,DHCP サーバ側がアドレスプールにあるアドレスに事前に ping し自分の知らないところで持たれている IP アドレスを把握することによって重複する IP アドレスが割り当てられることはないのですが,この問題では VyOS に service dhcp-server global-parameters ‘ping-check false;’ が設定されており,そのせいで静的 IP アドレス設定に重複する IP アドレスを別のクライアントに払い出してしまったというわけですね. この問題は順当な解き方をしているわけではなかったのですが,要件は満たしているということで満点をいただきました.

私の解答

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
お疲れ様です.味処まるたかです.
問題「接続が不安定になっちゃった」の回答を送らせていただきます.

以下,IPv4のことのみについて記述しています.

まず,client1と2の通信が不安定になった原因はclient1が通常用セグメントにIPアドレスを持っていないことでした.
VyOSの設定を見てみると,通常用セグメントではDHCP Serverが有効になっていましたが,リースを見てみるとclient2に `192.168.1.2` のアドレスを割り振っているだけで,client1に対してリースされていませんでした.
これは,client1のeth0ではdhcp clientが無効でstatic IP `192.168.1.2` が手動設定されていたのに対し,client2のeth0はdhcp clientが有効化されていたのが原因です.
ここでclient1のeth0のdhcp clientを有効化しても一時的に問題は解決するとは思いますが,今後clientそれぞれのIPアドレスが変わる可能性があるので,VyOSでDHCP Serverの設定を切ってclient2のeth0に `192.168.1.3` を手動で割り振りました.

- VyOSに行った設定
以下を実行

> configure
> set service dhcp-server disabled true
> commit
> save

- client2に行った設定
`/etc/netplan/01-netcfg.yaml``eth0` に対して

>      addresses:
>        - 192.168.1.3/24
>      dhcp4: 'no'
>      dhcp6: 'no'
>      gateway4: 192.168.1.1
>      nameservers:
>        addresses:
>          - 210.188.224.10
>          - 210.188.224.11
>        search:
>          - localdomain

を設定し,以下を実行

> sudo netplan apply

以上となります.よろしくお願いいたします.

なにをしたかと言うと,VyOS 側で DHCP Server 自体を切ってクライアント側には手動で IP アドレスを設定することで IP アドレスが重複しないようにしたんですね.たしかにこれなら正常に通信できるようになるし,再起動等してもまた問題なく通信が始められます.が,VyOS の設定が汚いです.そもそも動いていない DHCP サーバに色々設定を残しちゃっているので,もし実際のオペレーションでこの状態で前任者から引き継いだら「この記述消して大丈夫なんかなぁ,今は動いてないみたいだけど,何かのときに使うんじゃないだろうか…」と思って消すのためらってしまいます (私なら). ちなみに nameserver とかの設定は最初から静的 IP アドレスが設定されていた client1 の設定をそのままコピーしてきました.これも,もし DHCP で違う設定を配布していたとしたら減点になっていたかもしれません. また,最後にクライアント側で行った sudo netplan apply は,ぐぐったらややこしいコマンドを実行するようにいわれるのですが実際はこれだけでいいと先輩に教えてもらいました. 点数はもらったものの自分としては反省点の多い問題でした.

本選がんばるぞい!

えらそうに長々と書いてきましたが,一次予選はとにかく反省点だらけでした.本選でもこの調子では先輩方や他のチーム,研究室のファカルティに合わせる顔がありません.本選までは

  • 少なくとも自信を持って「メール問題全部もってこい」状態にする
  • 逆にメール以外の問題が解ける気がしないのでちゃんとまんべんなくお勉強する
  • 実践として ORF-NOC がんばる ということで対策に励みたいです.本選がんばるぞい!
This post is licensed under CC BY 4.0 by the author.

Folding@home を Ubuntu Server ではじめよう

Cisco Catalyst 初期設定