/
カテゴリー

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社

まとめ

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

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

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

最近のコメント