/
カテゴリー

HIRの問題文

現在他の部署のPCから社内のネットワークに繋がらないらしく、原因が不明らしい。
現状は以下の通りであり、これを解決してほしい。
– 手元PCから172.16.2.1への通信がものすごく不安定である。
上司から社内ネットワークの都合上、現在使用している各種プロトコルは変更せずかつstaticを書いてはいけないよう言われている。
上司からの注意点をふまえた上で、この問題を解決して何が原因だったのかを報告してほしい。

概要

この問題のコアになる技術はRIPで、RIPのversionの違いを利用した問題だった。

RIPにはversionが二つあり、違いはクラスフルなのかクラスレスなのかで、この問題ではRIPのアドレス集約機能のせいで正しいサブネットがテーブルに載らないため通信が不安定になっていた。

解法

sh ip route を入力すると以下の結果が返ってくる。

アドレス集約が行われているため、172.16.1.0/24 と 172.16.2.0/24 が 172.16.0.0/16 にまとめられていた。この問題はRIP version2にすることでサブネットの情報まで通知できるようになり、解決する。

講評

採点基準は、”テーブルに正しい情報がのっていないことがわかる”、”RIPのversionが問題であることが説明できる”の二点が正しく報告できていたかで判断した。

参加者の回答状況を見ると想定よりも解答数が少なく、物理図とconfigのVRFに対して苦手意識があったのかもしれない。物理図と論理図の違いが複雑だったために問題が解けなかった場合は、是非vlanやVRFの知識を深めてほしいと感じた。

 /
カテゴリー

問題文


G社で起きた先日のトラブルを解決したあなたは「これで安心してインターネットができるぞ」と意気込み、PCをスイッチ2960bに接続した。
しかし、PCはうまくインターネットに繋がらなかった。
原因を究明して、全てのPCがインターネットに接続できるようにトラブルを解決し報告をしてほしい。
ただし、残念ながら、トラブルが起きている1941a以外の機材は、会社からの許可がないためconfig等の変更をすると厳重注意を受けるそうだ。
インターネットに疎通性があるポートは、2と4~7である。

トポロジー図


 

 

採点基準


 

  • PCから対外へのアクセスができる
  • 複数のPCで対外へのアクセスができる

 

解説


 

トポロジー図の左側のルータがKUB、右側のルータがKATのルータになります。

左側のルータにはNAT技術が使われており変換されるアクセスリスト内には

access-list 101 permit ip 192.168.9.0 0.0.0.255 any
access-list 101 permit ip 192.168.6.0 0.0.0.127 any

と記述されていました。

pcからの接続の場合192.168.6.128/25からの変換を許可する必要があるため

access-list 101 permit ip 192.168.6.128 0.0.0.127 any

を追記します。

これで、対外との接続は可能になります。

次に nat のアクセスリストを参照している記述を確認します。

ip nat inside source list 101 pool nat

問題文にはすべてのPCとあるため、NAPT技術を使う必要があります。

そのため、以下のように変更を加えます。

ip nat inside source list 101 pool nat overload

以下の2つができれば複数台のPCが対外に出ることができます。

 

別解として

192.168.6.0/25 と 192.168.6.128/25の両方を許可するため、192.168.6.0/24と記述

poolでなくinterfaceを指定する(interfaceを指定した場合、自動的にoverloadになり、NAPTになります)方法でも解決することができます。

 

まとめ


いかがでしたか?

この問題の正答率は全体で5割ほどになります

手元の機材数が多く、配線が複雑で悩まれた方もいると思います

問題自体は簡単なので手元の環境の論理図を書くことが大事だと思います

 /
カテゴリー

 [ICTSC7] KNY(MSSのクランプ)の問題解説

こんばんわ。

この問題は、今大会がNTTで行われるということでNTT回線を使用している時に自分の家で起きたことを再現したものです。

当時、自分の家のルーターをVyOSに変えたところ、トラブルが起きました。

症状

症状としては、自分の家のLANからDNSなどは引けるのに、なぜか見れないサイトがあったり、不安定なものになっていました。

原因

原因は、MSSにありました。自分の家の回線では、pppoe認証を行うとMTUが1454byte、MSS1414以下でないと落とされてしまうというものでした。

なので、解決策としては、VyOSのwan側のnicにMTUを設定してあげることと、LAN側のポリシーにMSSを設定してあげることになります。

問題設定

問題のトポロジーとしては以下のような図になっていました。

 

 

NTTの環境再現するためにPPPoEserverをubuntuでたて、MTUとMSSに制限をかけさせてもらいました。

解決法

問題では、VyOSのpppoeのnicにMTUは設定してあったのですが、LAN側のポリシーにはMSSを設定しておりませんでした。なので、LAN側のポリシーにMSS1414でクランプするポリシーを書いてあげれば、パケットは通るようになります。

また、別解としては、VyOSのpppoeのnicではなく、wan側の物理nicにMTUを設定してあげると、自動でMSSを計算しなおしてくれるようです。

この問題にたどり着いたチームは、殆どいませんでしたが、お家でVyOSをたてる際に参考にしていただければ、幸いです。

 

 

 

 

 

 

 

 /
カテゴリー

こんにちは、工学院大学 修士2年の吉町優です。

ICTSCとの関わりとして第4回と第5回に運営委員として参加しています。今回ICTSC8でコンテストインフラのコアルータの構築やOpenFlowを用いたNATの実装を行いました。

トラブルシューティングの技術系のコンテストなので提供インフラも大切ですが、何よりも問題の質を大切に今回は作問しました。

問題の解説に入りたいと思います。

問題文

ある企業Zのシステム管理を請け負っており、事業所Aにおいて社内用のWEBサーバーが見れないという連絡を受けた。
この事業所AのLANのPCから正しくWEBサーバーを閲覧できるようにしてください。
原因を究明し、対策をしてください。

公開情報

参加者手元ににあるSwitchに事業所AのLANを用意しています。(2960のポート1~12)
事業所AのLAN: 192.168.12.64/26
webserver IP 192.168.12.131 (sshアクセス情報あり)
user:admin
pass:0aRPE5yZ1q
事業所Aルータへのアクセス
IP:192.168.12.11 (sshアクセス情報あり)
IP:192.168.12.65 (sshアクセス情報あり)
user:vyos
pass:0aRPE5yZ1q

 

採点基準(得点をあげる箇所)

  • VyOSでパケットキャプチャしLANとLANが混ざってることに気づく(DHCP-Requestに対してDHCP-Replyが2回受信していることなどから推察),ルータが2台いることに気づく 50点
  • LANが混ざっている原因の特定(Softether利用)azure向けIP(130.158.x.x)とkeepaliveパケットより推察100
  • VyOSのフィルタリングによりSoftetherを無効化 100
  • 正しいDHCPを受信し、WEBサーバーが閲覧できるか 50

 

模範解答手法

  1. nmapで192.168.12.64/26をスキャンしネットワーク上のノードを確認する。
  2. route コマンドで経路情報から192.168.12.126がデフォルトゲートウェイだと知り、本来のGWでないと知る。(対外アクセスは可能)
  3. tcpdump にてDHCPをしたときにRequestに対してReplyが2個返ってくることからLANが混ざっていることを推察かつ、softetherドメインのパケットがキャプチャリングできるのでsoftetherが動作していることがわかる。
  4. 特定のIPアドレス(130.158.x.x)がVPNパケットであることを突き止め、VyOSでIPフィルタリング等をかけ、LANとLANの混ざりを解消
  5. DHCPでアドレスを再度取得し、本来のGWが指定されたDHCP-replayを受け取りWEBサーバーへアクセスし、完了。

 

ネットワークトポロジー図

file

 

講評

このProblem-MASに関してはG社の最後の問題として個人的にラスボスとして出題をしました。3つ目の問題なのでこの問題に到達できたチーム数は8チームです。
この内回答を提出し、点を獲得したチーム数は2チームでした。(さくらさんを含んでいます)

肝心の点数ですが、どのチームも基準点に達しておらず解けたチームはいませんでした。難易度が高かったのかなと感じています。
提出された回答の中で一部点を取得しているチームの回答でネットワーク上に二つのルータがあるということを特定できているチームがありました。
確かに症状としては同一LAN内にルータが二つあるように見えるのですが、これはVPNによってLANと遠隔地のLANが結合したためルータが二つあるように見えています。
「ルータをLANから取り外す」や「本来のルータでないルータのMACアドレスからの通信を遮断」という回答があり、一般的な事例に回答が誘導されています。このような症状が発生した場合はVPNでブリッジされているという可能性を視野に入れると本当の原因にたどり着くことができたでしょう。

余談

なぜこの問題を出題したかというと、自分の経験であり、VPNの構築を誤ったことでVPNを介して大学のLANと家のLANがL2ブリッジされてしまい、インターネット疎通が切れたりなどの障害が発生したことでした。(ノードPCの有線NICに家のLANをローカルブリッジした状態でこのNICに研究室の有線LANに接続しLANが混ざった)
Softetherを今回使用しましたが、ルータの設定に関係なくL2ブリッジをユーザーが勝手に行いLANがおかしくなるというケースがあります。
Softetherは非常に優秀なVPNアプリケーションであり、私のお気に入りのソフトの一つです。ネットが閲覧可能な環境ならVPN(サーバー、クライアント共に)できないことはありません。スループットも非常によく多機能であるため皆さんも是非使ってみてください。

 /
カテゴリー

皆さんこんにちは!工学院大学大学院の増本奉之です。ICTSC7のTOM問題について解説をしたいと思います。

問題文

どうやら攻撃者が内部ネットワークに侵入しているらしい。内部向けサービスであるサイトhttp://aipo.tom.ictsc/aipo が正常に見られない時があるみたいだ。この原因を突き止めてほしい。

トラブルの原因

この問題はhttp://aipo.tom.ictsc/aipoにブラウザでアクセスすると怪しい入力フォームのサイトに誘導されます。
原因はVyOSを標的に行われたarpスプーフィングです。攻撃者は内部にいるという想定です。

VyOSはDHCPサーバ,DNSサーバとしても機能しています。クライアントはVyOSへ名前解決を行うよう要求しますが、VyOSは社内DNSへとその要求をフォワーディングしています。
このフォワーディング先のDNSサーバのIPアドレスとMACアドレスの対応が書き換えられてしまっているため、悪意あるDNSサーバに名前解決をフォワーディングしてしまっています。

解説

操作対象はVyOSのみです。よって攻撃者の排除は行えないので、ARPスプーフィング対策を行い、正しいDNSサーバへ名前解決をフォワーディングすることがゴールです。

VyOSでtcpdumpを行うと周期的にarp replyが送られてきていることが分かります。このarp replyによってVyOSのarpテーブルが書き換えられてしまっています。これを防ぐ方法は2種類あります。

1つ目の方法

1つ目の方法は、静的にarpテーブルを記述する方法です。arpingコマンドでDNSサーバのMACアドレスを確認すると、2種類のMACアドレスが確認できます。2つのMACアドレスのうち、どちらかが周期的に送られてくるarp replyの送信元MACアドレスと一致します。こちらが攻撃者のMACアドレスです。よって、もう片方のMACアドレスとDNSサーバのIPアドレスの対応付けを静的に記述すれば、arpテーブルを書き換えられることはありません。
:~# arp -s [IPアドレス] [MACアドレス]

2つ目の方法

2つ目の方法は、arptablesパッケージをインストールし、MACアドレスのフィルタリングを行う方法です。リポジトリの登録例からインストールまでは以下。

# set system package repository squeeze components main
# set system package repository squeeze distribution squeeze
# set system package repository squeeze url http://archive.debian.org/debian
:~# apt-get install arptables

インストールが終わったら以下のコマンドでMACアドレスフィルタリングを行います。

:~# arptables -A INPUT --source-mac [MACアドレス] -j DROP

ちなみにVyOSのfirewall機能(iptables)ではarpテーブルの書き換えは防げません。

最後に

TOM問題を回答するにはTAB問題・URA問題を解かなければいけません。この2つが難しくてTOM問題はあまり解かれませんでした。なのでTOM問題の難易度がどの程度なのかはわかりませんが、上記の2つよりは解きやすいかなと思います(1番最初の問題でもよかったかも)。
次回以降もICTSCには何らかの形で関わって行きたい思っています。
参加者及び関係者の皆様、本当にありがとうございました。

 /
カテゴリー

ICTSC7お疲れ様でした。

大阪工業大学の矢田一樹です。

今回は、B社3問目のKAZ問題:「pingが通らない」を解説します。

コア技術:BGP

問題文

新入社員に自社が押しているBGPに慣れてもらうために設定をさせることにした。
ルーターの数がフルで使われているため、仮想ルーター(vyos)を使って組んだら、
外への疎通が途絶えてしまった。原因を究明して対策を行い報告してほしい。

C社(R1)からE社(R4)にpingが通るようにしてその結果を報告書に加えること。

トポロジ図

 

今回のテーマ

・ルーティングテーブルに乗らない理由に気づく。

・IBGPとEBGPのnext-hopの仕様の違いに気づく。

・static routeは一つだけ使えばいいことに気づく。

 

原因と解決方法

原因

IBGP(同じAS間のルーター)内にあるルーターがEBGP(別のAS間)でピアを張ったときに、パケットを正常に送信できていない。

BGPのNEXTHOPアトリビュートはEBGPとIBGPで仕様が違う。

  • IBGPはルートのnexthopを変更せずに送る。
  • EBGPはルートのnexthopを変更して送る。

この違いによりnexthopが合わなくなり、ベストパスに選ばれないため、ルーティングテーブルに載らなくなる。

  • 具体的には、eth0が192.168.7.10/26のルーターが該当する。

解決方法

IBGPのピアを張った先のルーターに向けてstatic route を記述する必要がある。

採点基準

1.R4までピアを張ったあとに共有される192.168.7.128/26のnexthopがR3(7.67/26)に固定されている事に気づくか。[20%]

2.R1,R2間でIBGPでルート共有した時に、R1のBGPルーティングテーブルの192.168.7.128/26のNextHopが変更されていないのが原因だと気づくか[30%]

3.Static route を正しく設定したか[50%]

報告書とpingの結果で確認する。

講評

・この問題は3問目に該当するためか回答したチームは2~3つであった。

・問題の難易度に関してはvyosが使えれば難しくはないと思う。

・vyosを是非、触って見てほしい。

 /
カテゴリー

皆さんお久しぶりです!ICTSC7で問題リーダーだった伊東と川原です。

ICTSC7の開催から早1か月、問題解説を公開するのが大変遅れて申し訳ありませんでした。準備が整いましたので、来週から順次それぞれの作問担当から問題の解説記事を投稿する予定です。今しばらくお待ちください。この記事の末尾にそれぞれの公開された記事のリンクを順次追加していきます。

各問題の概要について

先立ちまして、協議終了後に少しお見せした問題の概要をまとめたスライドがありますのでご覧ください。

問題解説スライド

記事へのリンク

A社

  • 1問目 (MIC):
  • 2問目 (HIZ):
  • 3問目 (MAH):

B社

C社

  • 1問目 (RYO):
  • 2問目 (MIZ):

D社

E社

F社

G社

まとめ

今大会の問題はいかがでしたでしょうか?

難しかった、悔しい!と思っている方、賞金欲しかった!と思っている方など居ましたら、是非次回も参加してリベンジをしてみてください!

また、初参加の皆さんもこのような問題が出題される大会ですので、興味があればぜひ参加をしてください!

 /
カテゴリー

こんにちは!運営委員の河瀬大伸です!
ICTトラブルシューティングコンテストに参加していただいた皆様、大変お疲れ様でした。
もうコンテストから早1ヶ月以上経ちます。皆様いかがお過ごしでしょうか?

さて、今回ICTトラブルシューティング初めての試みと致しまして、出題された問題全ての解説を行います。

今までのICTトラブルシューティングコンテストはネットワーク問題に偏った出題編成となっておりました。そのネットワークのトラブルはある程度出題範囲が限られてしまい凝った問題を作りづらくパターン化しがちです。

その都合上問題の解説を公開し続けるとネタ切れになるのでは、という恐れから今まで問題解説の公開を行っておりませんでした。

しかし、近頃の出題編成はサーバー問題の比率がとても高まってきており、また、運営委員の人数も増えて、問題のバリエーションが少しずつ広がっている事から、今回運営委員の話し合いにより公開してもよいのではないか、となった次第です。

ICTトラブルシューティングコンテストのトラブルはとても興味深い物が多いです。
記事の最後に問題解説のURLを出題順にまとめていますので、ぜひご覧頂き参加者の皆様の成長の糧になればと思います!
それでは、また次回ICTトラブルシューティングコンテストでお会いしましょう!

続きを読む

 /

こんにちは、電気通信大学 学部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は最終手段であり、使うのはあまり推奨されるものではない」とのコメントを頂き、私としても新しく知ったことも多かったです。

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

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

最近のコメント