/
カテゴリー

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社

まとめ

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

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

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

 /
カテゴリー

こんにちは! ICTSC6 運営委員の田中京介です。
第6回 ICTトラブルシューティングコンテストの最終日から早1ヶ月となってしまいました。
今回は前回の反省を踏まえ、大会終了後すぐに問題解説を公開するとお伝えしていたにも関わらず、このように日が開いてしまい申し訳ありません。

今回は全15問の問題が公開され、大別するとネットワーク系の問題が7問、サーバー系の問題が8問ありました。これは前回と似た傾向であり、サーバー系の問題の出題が多かったです。

また、出題時間で見てみると、1日目は6問、2日目は9問が出題されました。
特に、2日目の午後は同時に6問が出題されたこともあり、過去のICTSCでも例を見ないような、慌ただしい時間になったのではないでしょうか。

ICTSC6に参加された方には問題を振り返って頂き、そして次回参加される方には今後の糧として頂ければと思い、今回も全問題の解説を公開いたします。

※問題文については、当日に補足、修正が行われた部分があります。しかし、現時点では運営委員もコンテストサイトへアクセス出来ない状況にあるため、後日最新のデータを得られしだい、更新を行う予定です。

それでは、また次回の ICTトラブルシューティングコンテストでお会いしましょう!

(2016/9/24 追記: 問題5 および 問題15 の解説が誤っていたため訂正いたしました。皆様の混乱を招いてしまい、申し訳ありませんでした。)

問題1 「ルーターの設定がわかりません」

出題時間: 1日目午前, 問題技術: VPN, 満点: 30点

問題文

あなたは、とある会社のネットワークを管理を担当している。今回、本社と支社をVPNで接続することになった。その際出来る限り費用を抑えるため、支店側は仮想ルーターを使用することになった。

「VPNのパラメーターってシスコのデフォルトだよね」
「そうだね」

2人で作業を行っていたのだが、もう一人が「ルーターの設定は終わったよ」と言って別の仕事に出かけてしまった。しかし、VPNが張れていないようなので、設定を確認しようとしたところ画面に何も表示されない。

現在の状況は以下の通りである。

  • ルーターにコンソール接続しても何も表示されない
  • IPSecSAがアクティブになっていない

標準設定でコンソールを接続すれば、通信ができるようにして欲しい。
なぜVPN接続できないのか原因を確認し、VPN接続できるようにして欲しい。
これらのトラブルの原因を詳しく説明して欲しい。

トポロジ図

問題01 トポロジ図

採点基準

  • DHのグループを合わせている
  • ボーレートを9600(デフォルト値)と異なっていたことに言及している
  • Ciscoルータ Show crypto isakmp sa で相手が見えている
  • vyOS show vpn ipsec sa で相手が見えている
  • インターフェースに暗号マップを適用していないことに気づいている
  • アクセスリストが不適切であったことに気づいている

解説

  • まず、ターミナルにうまく表示されない問題ですが、これはルーターのボーレートとターミナルのボーレートの不一致によって発生します。
  • ボーレートとは、信号の伝送速度のことであり、これが一致していない場合正しく通信が行われず、画面に何も表示されなかったり、文字化けが発生したりします。
  • IPSecSAがアクティブになっていない問題は、3つの理由でトラブルが発生しています。DHグループの不一致、暗号マップをインターフェースに適用していない、VPN対象となるパケットのアクセスリストがワイルドカードマスクで指定しなければならないところをサブネットマスクで指定しているの3つです。
  • DHグループによって、鍵交換のためのアルゴリズムで使われる鍵の生成情報が異なるので、一致している必要があります。
  • 暗号化マップとは、トランスフォームセット、暗号化対象のACL、IPsecピアのアドレスを定義したものです。これを、インターフェースに適用する必要があります。
  • 暗号化対象のACLの設定が不適切なため、正しく対象パケットを指定出来ていないので、VPNがうまく張れません。これらの設定を正しく設定しなおすことによりトラブルは解決します。

問題2 「繋がらなくなりました」

出題時間: 1日目午前, 問題技術: VLAN ID, 満点: 10点

問題文

あなたはとあるビルのネットワーク管理を任されている。

ある日そのビルの点検で停電が発生した。点検後、ある部署でインターネットに繋がらなくなったという連絡を受けた。

  • 部署アドレス(10.100+x.5.0/24)【xはチーム番号】

部署アドレスで正しく繋がるようにして欲しい。

その後、設定を変更した箇所とその理由を詳しく説明して欲しい。

トポロジ図

問題02 トポロジ図

採点基準

  • 部署アドレスで通信ができる
  • トラブルの原因を詳しく説明できている
  • スイッチのインターフェースに正しいVLANを適用している
  • ルーターのサブインターフェースに正しいアドレスとカプセル化タイプを指定している

解説

  • この問題のトラブル発生原因は大きく分けて2つあります。
  • 1つ目が、スイッチのインターフェースにVLANが適用されていないという点。2つ目が、ルーターのサブインターフェースの設定がされていない点です。
    • スイッチにVLANを定義したとしても、スイッチのインターフェースにVLANが適用されていないと、VLANは利用できません。
    • ルーターのサブインターフェースにトランクポートで送られてくるパケットの情報を書かないと、それぞれのVLANとうまく通信出来ません。
  • VLANはネットワークを考える上で必須技術となっていると思います。そのVLAN関連のトラブルシューティングを体験して頂きたいと考え問題出題をしました。
  • また、今回の停電後にトラブルが発生したというのは、設定を行ったあと設定を保存していなかったために設定が消えてしまい、発生したトラブルという想定で出題しました。設定を変更したら、その設定を保存する大切さも考えて頂きたいという思いからこのような設定にしました。

問題3 「移行したアプリケーションが動かない!」

出題時間: 1日目, 問題技術: MySQL sql_mode, 満点: 40点

問題文

担当者のAさんは,あるアプリケーションが動いているサーバをリプレースする作業を命じられました.

そこで,新しいサーバをセットアップしました.その際,以前使用していたディストリビューションのバージョンが古くなっていたため,新しいサーバでは,最新バージョンのディストリビューションを採用することにしました.

ところが,新しいサーバでアプリケーションを動かしてみたところ,エラーが発生して動作しません.

Aさんに代わって,原因の調査と復旧手段を報告して下さい.

トポロジ図

問題03 トポロジ図

採点基準

  • Webサービスがきちんと動いているかどうか
  • なぜWebサービスがきちんと動かなかったら,きちんと原因の特定ができているか.
    • (特に,あるクエリが昔のバージョンで動作し,今のバージョンで動作しない理由についてきちんと言及できているか.)

解説

MySQL5.7.8 からは デフォルトの sql_mode が

ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,
      ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
    

になっている

  • これにより,select a, count(*) from hoge; のような group by なしの クエリが落ちてしまう.
  • ONLY_FULL_GROUP_BYを外せばOK

問題4 「アップローダが動きません!」

出題時間: 2日目午前, 問題技術: inode, 満点: 30点

問題文

とある喫茶店では、「らびっとほーす」というサービスをWebにて提供している。

このサービスはログイン不要で自由にファイルをアップロード/ダウンロードできるサービスです。

このサービスは今まで順調に稼働していたが、ある日を境に突然アップロードができなくなってしまった。

まだ調査が進んでおらず、原因が分かっていないので。原因究明を行ってほしい。また、可能であれば対処を行ってほしい。

ただ、このサービスはある程度のユーザーがおり、アップロードができない状態でもダウンロードを行うユーザーはいるため、できる限り復旧時にダウンタイムを設定しないこと。

また、喫茶店の一人娘の自称姉がよくわからないままに立てたサービスであるため、サーバーのログイン情報以外のことは分かっていません。

このサービスは人気であるため、ダウンタイムが発生すると減点される可能があります。

トポロジ図

問題04 トポロジ図

採点基準

  • inode 不足に気が付く
  • ディスクを新規に作成して問題を解決し、アップロードを可能にする (満点)
  • 減点: ダウンタイムの長さに応じて / ファイルが消えている場合など

解説

  • アップローダプログラムのログや、 touch 等でファイルシステムに新規にファイルを作成できないことから inode 不足を推測してほしい
  • 近年のWebアプリケーションでは非常に高い可用性が求められている。今回の問題についても、既にアップロードができないという機能不全が生じているが、それでもダウンロードの要求は多くあったため、その要求を止めないことがまずサービスの継続のためには必要であると認識してほしい。
    • その上で、ダウンタイムを減らして復旧を行うための方法を考えて実行してほしい
  • 今回は、3秒間隔で GET / のステータスコードが 200 OK となるかのみを見る SLAチェッカが動作していました。
    • 時間があればアップロードやダウンロードなどを行うSLAを用意したかったのですが間に合わず……
  • また、ディスクには意図的に空き領域を設けてあり、新規のパーティションを作成することができるようになっていました。
    • これ用いてパーティションを作り、手動マイグレーションを実行することが今回の意図した解答でした。

問題5 「引継ぎ失敗しました」

出題時間: 1日目午後, 問題技術: Aux, 満点: 30点

問題文

先日、弊社で長年ネットワーク機器の設定を行っていたインフラエンジニアがやめてしまった。
今回あなたには彼を引き継いでネットワーク機器の設定を行ってほしい。
変更する機器はルータAで、最終的にルータBと疎通が取れるようにしてほしい。
ただ、作業に伴い以下の事を注意してほしい。

——注意事項——

  • 引き継ぎ内容に漏れがあったためルータAの設定内容や一部認証情報は分からない。
  • ネットワークを止めるわけにはいかないので電源は落とさないように。

——ここまで——

作業が終わったら確認のため、ルータAのコンフィグと作業内容を全て報告するように。
尚、足りない情報はルータBの設定から得るか、自ら探して欲しい。

ルータA “イネーブル” パスワード:*******
ルータB “イネーブル” パスワード:*******

トポロジ図

problem-05

 

想定解

  • コンソールポートからルータAに未知のユーザ名とパスワードがかかっている事を知る
    (telnetはdisableにしておく)
  • 電源を落としてはいけないのでAUXポートからコンソール接続する
  • show runから、未知のユーザ名が ictsc6 だと気付く
  • 以下のコマンドを用い、任意のユーザ名とパスワードに変更する
    • no username ictsc6 password
    • username 任意 password 任意

<ここから 順不同>

  • show ip int等のコマンド、もしくはping等からシリアルインタフェースが admin shut 状態にあることに気付く
  • シリアルインタフェースをno shutdownする
    • (shutしてる理由は、本来変更対象ではないルータBを操作し、直ってしまうケースを回避するため)
    • (ACLがあるのでルータBからの変更だけでは繋がらないが、念のため)
  • ルータA側のACLで、ルータBからの応答が暗黙のDenyになってることに気付く
  • 暗黙のDenyにならないよう以下の変更を加える
    • 今ある設定を消すのはよろしくないので、ACLを消した場合は減点
      (元通り再設計した場合は不問)
    • access-list 100 permit icmp ルータB ipaddress 0.0.0.0 ルータA ipaddress 0.0.0.0 echo-reply

シリアルインタフェースのカプセル化がルータAとルータBで違うことに気付く

  • ルータAの設定を以下のように変更し、ルータBのカプセル化に合わせる
    • あくまでも変更するのはルータAなので、ルータBを変更した場合は減点
    • int s0/0/0
    • encapsulation ppp

<ここまで 順不同>

  • 以上の設定を終え、ルータAからルータBへ疎通が取れることを確認する
  • ルータAのコンフィグと全ての作業内容を報告し、終了

採点基準

  • AUXポートから入った事とユーザー+パスワードを変更するコマンドの記述があれば加点 (+?点)
  • ACLによって暗黙のDenyになっていた事と適切なACLコマンドの記述があれば加点 (+?点)
  • シリアルインタフェースのカプセル化が異なっていた事とカプセル化を変更するコマンドの記述があれば加点 (+?点)
  • シリアルインタフェースがadmin shut状態にあった事とその状態から回復させるコマンドの記述があれば加点 (+?点)
    • 気付きだけでコマンドの記述が無い場合、減点 (-?点 x 該当数)
    • 暗黙のDenyを回避する方法がACLの全削除だった場合減点 (-?点)
    • カプセル化変更をルータBに行った場合減点 (-?点)
    • 公平を期す為、電源を落としリカバリした場合、得点なし もしくは 獲得した得点の半分を減点する
      • 再起動はpingによる監視およびwrしてないホスト名によって判断する。
        (pingによる監視にしたのはサービスへの到達性が重要になると考えたため)

解説

今回の問題では、ルータBと疎通を取るためにルータAのインタフェースに変更を加える作業が大部分となっています。
内容として、設定の違いまたはミスによって通信ができないトラブルを再現しました。
そして、今回のように複数個所にトラブルがある場合、running-configやshowコマンドから異常個所を特定する力も必要になってくる為、あえて問題点を複数箇所用意しました。

しかし問題の主旨は別にあり、電源を切らずルータAに掛かっているパスワードを突破する事が重要な要素となっています。
問題文にもあるように、電源を落とすわけにはいかない事からROMモニタからのパスワードリカバリを行うことは出来ません。
また、今回の場合一部認証情報が欠落しており、sshからの接続も出来ません。
それを打開策の一つとして、AUXポートからコンソールケーブルを挿し、パスワードリカバリする方法がある為
今回の問題ではその方法を用いて突破できる形にしました。

実作業でも「電源を落とさない」「疎通性は確保したまま」で変更しなければいけない場面はとても多いはずです。
この問題を通して、その考え方を理解していただければと思います。

問題6 「VMがネットワークにつながらない!」

出題時間: 1日目午後, 問題技術: MACアドレス衝突, 満点: 40点

問題文

ある日、VMに対して操作を行ったら2台のVMがネットワークに対しておかしな挙動をするようになりました。

担当者のAさんは調査を行いましたが何が何だかでお手上げです。

引きこもってしまったAさんに代わって情報を集めるところから始めて、原因を報告してください。

トポロジ図

問題06 トポロジ図

採点基準

  • MACアドレスの重複に気づくこと (満点)

解説

問題7 「自動マウントをしてくれない!」

出題時間: 1日目午後, 問題技術: pam_mount, 満点: 30点

問題文

ある日、普段windowsの各ユーザーに対して割り当てているsamba共有フォルダをubuntuで同様に割り当てることになりました。

各ユーザーの~/privateというディレクトリに\\file.example.local\private\%username%という共有ファイルをマウントします。

上司から頼まれたAさんはpam_mountというパッケージを導入し、実現しようとしました。

ところが作業ユーザーでは~/privateに期待通りのフォルダをマウントできていますが、書き込みができません。

失踪したAさんから仕事を引き継ぎ、正しく動作するように設定してください。

要件は以下の通りです。

  • 可能な限りpam_mountを使うこと
  • 共有フォルダに対して読み書きの操作ができること
  • 新規ユーザーで滞りなくマウントを完了し、読み書きの操作ができること

トポロジ図

問題07 トポロジ図

採点基準

  • 作業ユーザーからマウントした共有フォルダへ読み書きができること(6点)
  • 新規ユーザーの~/privateから共有フォルダへマウントできていること
    • 書き込みが出来ること(12点)
    • 読み込みができること(12点)

解説

  • Sambaのroフラグ
    • 接続した共有ディレクトリが読み込み専用になる
  • chattr +i
    • inodeの編集禁止フラグを設定する
    • skelに用意することで新規ユーザーのマウント先がファイルになり、マウントできず、削除できず…という状況を作ることができる

2日目

問題8 「社内ネットワークを設定して!」

出題時間: 2日目午前, 問題技術: IPv6 / v4, 満点: 40点

問題文

昨日社内ネットワークのトラブルを解決するように頼まれたあなたは、上司に呼び出されこのようなことを言われました。
「社内ネットワークをIPv6アドレスに変更しようという案があってね。その一環として社内ネットワークの一部をIPv6ネットワークに変更するんだけど、そのIPv6ネットワークからIPv4ネットワークに通信できるようにルータ(参加者に設定してもらうルータ)の設定お願い。」
「とりあえず通信できればいいけど、できればルータを再設定しないでもいい設定をしてくれると嬉しいな。」
「そうそう、僕の方で調べてたらNAT64というのがあったと思うよ。」
「昨日起こったトラブルを解決してくれたなら、外に繋がるようになってるはずだから。」
あなたは上司に言われたようにルータの設定を行い、設定したルータのコンフィグを提出してください。

トポロジ図

問題08 トポロジ図

採点基準

  • IPv6ネットワークからIPv4ネットワークに通信ができる(NAT-PTの設定ができている)
  • NAT-PTがダイナミックの設定になっている
  • NAT-PTがNAPTの設定になっている

解説

  • IPv6ネットワークからIPv4ネットワークには規格が異なるため、基本的には通信できません。そこで、様々なIPv6ネットワークとIPv4ネットワークの共存技術を知ってもらう目的で出題しました。
  • 共存技術にはNAT-PT, NAT64, v4v6トンネリングなどいろいろありますが今回の場合ルータの機能の制約の関係でNAT-PT以外の設定はできません。
  • IPv6を用いた出題は初めてなため、参加者のIPv6の知識を調べる目的も兼ねて出題しました。

問題9 「レプリケーションが出来ない!」

出題時間: 2日目午前, 問題技術: MySQL replication, 満点: 20点

問題文

とある企業にてWebサイトの構築を行う業務があった。Aさんはデータベース周りの設定を担当していたが、初めてのレプリケーション設定と慣れないMYSQLの為悪戦苦闘していた。

納期が迫る中、Aさんは私事でどうしても本国に帰らないと行けなくなってしまった。試行錯誤が垣間見えるconfigを元にレプリケーションの設定を完了して欲しい。

トポロジ図

問題09 トポロジ図

採点基準

  • レプリケーションが行えてる
    • 予めサンプルDBを準備しておいて、マスターでの変更がレプリケーション側で反映されていることが確認できる.

解説

  • mysqlのレプリケーションが上手く動作しない問題
    • /etc/my.cnfの設定ミス
      • server-id等
    • mysql slave側の設定ミス
      • master_log_file
      • master_log_pos等

問題10 「IPアドレスが振られない!」

出題時間: 2日目午後, 問題技術: DHCP, 満点: 40点

問題文

某C社では,CloudStackを用いたインフラ業務を行っている.ある日,Debian 8とUbuntu 16のインスタンスを建てた時にDebian 8にだけIPv4アドレスが割り振られないトラブルが発生した.

インスタンスのオーケストレーションの為にも,DHCPを用いたIPv4アドレス等の自動設定は必要不可欠であり,大量のインスタンスに対して,手動でIPv4アドレス設定することは難しい.

C社は,このトラブルをあなたに解決してもらい,インスタンス起動時にDHCPによるIPv4アドレスリリースが正常に動作させるようにしたいと考えている.

ただし,DHCPサーバやCloudStackホストマシンに対して調査・変更を加えることはできない.

原因を特定し,この問題を解決してほしい.

トポロジ図

問題10 トポロジ図

採点基準

  1. UDP Checksumが壊れている事を指摘しているか … 25%
  2. Ubuntu 16ではUDP Checksumが壊れているのにDHCPを正常に処理していることを指摘しているか … 25%
  3. 実際に何らかの方法でDebian 8にDHCPを処理されられたか … 50%

解説

KVM + linux-bridge 環境では,DHCPパケットのUDPのChecksumが破損する状況が発生する.
これを解決する為に,それぞれのディストリビューションのdhclientにはパッチが当てられているが,Debianだけは9から適用される.

問題11 「聞きたくても、聞こえない」

出題時間: 2日目 (通し), 問題技術: IP Phone, 満点: 50点

問題文

あなたの会社では、先日待望のIP電話が導入されました。

IP Phone は業務に関係のないことにも使えるようです。

  • 社長(運営)との雑談のため

そんな IP Phone ですが、どうやら先日社内インフラ部がセキュリティ上の理由でスイッチの設定を変更した結果、こちら(参加者)の声が社長に聞こえなくなってしまったようです。

インフラ部は非常に対応が悪く、問題があるといっても一向に聞き入れず、調査を行ってくれません。しかし、何か正当な理由があればスイッチの設定変更には応じてくれるみたいです。

  • もしコアスイッチ等に問題があるのであれば、質問に 設定変更依頼 と題して変更したい内容とポートなどの情報を伝えて下さい。
  • 社員とわいわい雑談できないためか、最近は社長もご機嫌斜めです。早めに解決してください!

トポロジ図

問題11 トポロジ図

採点基準

  • 音声の伝送に必要なポートがxxxxx/UDP であることをパケットキャプチャから読み取り報告する
  • 運営が報告したポートを疎通する設定にした後、運営の番号へ通話を試行し通話ができることを確認する

解説

  • SIPプロトコルに関する出題は初めてであるため、難しいと考えられるが、ミラーポートが与えられているということから、パケットキャプチャを上手く活用し、必要な情報を推測してほしい
  • IP Phone は起動時に、DHCP → TFTPサーバ → SIPサーバ の順でアクセスを行い、自機のセットアップを行います
    • このとき、IP Phone が通話に用いる (音声データを伝送する) ポートはメディアポートと呼ばれ、通話の開始時 (INVITE リクエスト時) に待ち受けポートを SIPサーバへ伝えます。
    • 実際にパケットキャプチャを行うと、そのポートに向かって RTP (Real-time Transport Protcol, UDP) で音声パケットが伝送されていることが分かります。
  • 今回は SIP プロトコルそのものが用いるポートである、 5060/UDP or TCP は塞がれていませんでした。
    • このため、通話のセッション自体は生成されるが、音声データだけが伝送されないという現象が生じます。
  • メディアポートは TFTP サーバにおいてある各端末固有の xml ファイル内の startMediaPort, endMediaPort タグに書かれているレンジからランダムで選択されることになっています。
    • 今回使用した機種 (CP-7960G, CP-7961G) では、xml ファイルのファイル名は SEP0123456789ab.cnf.xml というような形で、SEP{IP Phone のMACアドレス}.xml という形で TFTPサーバのルートに置かれています。
    • IP Phone のネットワークにアクセスすることができる参加者手元の配線は IP Phone へ繋がっている1本しかないため、これを一度引っこ抜き、PC に接続してアクセスする方法が作問者の意図した方法です。
      • 当日は思わぬトラブル(?)があり、会場の AP から SIPサーバや TFTPサーバにアクセスすることもできました。
  • 各チームには事前に生成した xml にて、100ポート分の mediaPort のレンジを指定しており、これを特定して中間経路にある L2SW の acl を変更してもらうことで通話が可能になります。
    • 全てのポートの解放を要求することでも、通話は可能になりますが、セキュリティ上よろしくないという理由で減点しています。
    • また、パケットキャプチャから、特定の1つのポートについての acl 変更申請をされたチームもありました。上記の説明を見るとお分かりかとは思いますが、メディアポートは100ポートの中からランダムで選ばれるため、1ポートだけを開けても正答とはなりません。 (この場合、通話100回に1回の確率で声が通る不思議な電話が完成します)

問題12 「調子が悪いんでしょうか?」

出題時間: 2日目午後, 問題技術: PathMTU, 満点: 30点

「NTT西日本杯」第6回 ICTトラブルシューティングコンテスト 問題解説 “調子が悪いんでしょうか?” | ツチノコブログ にて解説記事が公開されています。

採点基準

  • 報告書にmtuの設定が不適切とあれば加点
  • 報告書にPathMTUDiscoveryまで拒否されていたとあれば加点

問題13 「本社のサーバーに繋がりません」

出題時間: 2日目午後, 問題技術: RIP + OSPF, 満点: 10点

問題文

ある日、会社Aの支社は本社に対して専用回線をつなぐことになりました。

社内ネットワークのルーティングプロトコルに支社は OSPF を使用し、本社は RIPv2 を利用しています。

このネットワークが正しく動作するように設定してほしいと頼まれたあなたは、ルータ(892J)の設定を新入社員のBさんに任せる事にしました。

Bさんから設定が終わったとの報告を受けていたので、無事に必要な設定を終えたとあなたは判断していました。

しかし、その翌日に他の部署(10.100 + team_number.7.0/24 ネットワーク)の社員から本社のWebサーバー繋がらないという連絡が入ったのでBさんが設定したルータ(892J)の設定を修正することになりました。

そこで、修正したルータのrunning-configと他の部署から繋がらなかった原因を報告書にして提出してください。

本社Webサーバ : http://web.ictsc6.pkpk/

トポロジ図

問題13 トポロジ図

採点基準

  • 報告書に再配送時のmetric設定が不適切とあれば加点(+?点)
  • 本社のサーバーにIPaddress/24ネットワークからアクセスできれば加点(+?点)

解説

  • 今回の問題では、参加者側からWebサーバに通信できない状態にありました。
  • その中で注目すべきは、RIPのHOP数制限とtracerouteの結果です。
  • この問題でWebサーバへtracerouteをしてみると、二つ目から*表示という結果になってしまいます。
  • その理由が、以下の再配送設定にあります。router rip
    redistribute ospf 1
    offset-list 0 in 16 インタフェース名
  • ospfで学習した経路をripに再配送する場合、この設定のままだとシードメトリック値が20となってしまいrip側では破棄されてしまいます。
  • また、offset-listでは、ripから得た経路情報のhop数に16加算し学習しています。
  • ripのHOP数制限は15ですので、経路情報が破棄されてしまい通信ができないという状態になっていました。
  • 会社の環境や機材によってはOSPFではなくRIPを使用せざるおえない状況がでます。
  • この問題では、そういったRIPとOSPFを併用している環境において起こり得る正しく経路情報を配送できないトラブルを再現してみました。

問題14 「sshでサーバに接続できない!」

出題時間: 2日目午後, 問題技術: ssh, 満点: 10点

問題文

とある会社のとあるチームではCloudStackを用いて仮想化基盤を運用している

新人研修を行うときは新しく研修用サーバを用意し踏み台サーバから公開鍵認証のみでサーバにアクセスする方式を採用している。

ある日上司が研修用サーバにいたずらをしかけられる。

  • 「研修用のサーバ、sshではいれなくしといたよ!がんばって~:innocent:」と満面の笑みで衝撃的な内容を言い放ち、さっそうと早退していきました。

上司のいたずらをかいくぐり、公開鍵認証でssh接続できるようにしてほしい。

※幸いなことにweb consoleへのアクセス権は上司から貰っている

これまた上司のいたずらかweb consoleのキーボードレイアウトがUSキーボードに設定されているようだ。

トポロジ図

問題14 トポロジ図

採点基準

  1. 実際に踏み台サーバからssh接続できる
  2. 原因となった設定を報告
  3. 修正点などがあればなおよい

解説

  • /etc/ssh/sshd_config のAuthorizedKeyFile のpath指定ミス
  • authorized_keysのnistp521が512になっている
  • chattr +i で/etc/ssh/sshd_configが書き込めない

問題15 「なんかwebページおかしい?」

出題時間: 2日目午後, 問題技術: hsts, 満点: 20点

問題文

先日、社内にて外部向けホームページを作成した。

現在そのホームページを社内検証用Webサーバーにて公開したところ、うまく作成した通りにホームページが表示されない問題が発生した。

社内検証用のWebサーバーへのアクセス権と、 社内クライアント用VMのゲストユーザー操作権を与えるので、webサーバーをsshで操作し、CloudStackのwebコンソールからクライアント用VMを操作して障害の原因を調査し正常にwebページが表示されるように解決してほしい。

ただし、Webサーバーにもともとあるセキュリティ性は落としてはならない。

トポロジ図

9833eab6-4baa-11e6-9536-3a42e806d535

 

 

採点基準

  1. httpの外部参照をhttpsに変更できているか
  2. レイアウトが変更されていないか
  3. HSTS設定を変更していないか

解説

  • HSTSによりhttpsを強制しているため、httpで外部参照しているWEBフォントやjsファイルは信頼されないコンテンツとしてwebブラウザが弾くことが原因。
  • 外部参照をhttpからhttpsに変更することで問題が解決される。
 /
カテゴリー

こんにちは!運営委員の門脇です!

ICTSC6に参加して頂きました皆様、お疲れ様でした!

 

 

さて、準備期間中に運営はラック内配線の整理もやっていました。

今回は「運営委員が何をしていたか」を少しでもご紹介できれば、と思います。

続きを読む

 /
カテゴリー

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

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

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

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

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

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

続きを読む

最近のコメント