/

問題文

192.168.19.10のインターフェースから192.168.19.125にICMPパケットが通らないので通してください。

192.168.19.66のインターフェースから192.168.19.140にICMPパケットが通らないので通してください。

※192.168.19.125と192.168.19.140からもICMPパケットを常に送っております。

情報

IPアドレス: 192.168.19.100 ユーザー: admin パスワード: ospf

問題のゴール状態

192.168.19.10のインターフェースから192.168.19.125にICMPパケットが通る。

192.168.19.66のインターフェースから192.168.19.140にICMPパケットが通る。

解説

トポロジーはこのようになっていました。

 

トポロジーを見て貰えれば分かりますが、ゲートウェイがサブネット外にあります。

よってeth1、eth2ともにサブネットを/27にして、eth1ではパケットにvlanタグがついているのでeth1をvlan56のインターフェースにすることで解決する問題でした。

解き方

192.168.19.125への通し方

eth1のインターフェースでsudo tcpdump -ei eth1を行うと、802.1qタグでVLAN 56がついたARP Requestを見ることができます。

そこで/etc/network/interfacesに書いてあるeth1のインターフェースをeth1.56のインターフェースにすることで、リクエストされている192.168.19.10のARPに応えることが可能となります。

しかし、ARPが来ていた192.168.19.30がサブネット外であるため、192.168.19.125から来たICMPパケットをデフォルトゲートウェイであるeth0に流してしまうので、
eth1のサブネットを/28から/27に直し、/etc/network/interfacesに書いてあるStatic routeを反映します。

これで192.168.19.125に対してICMPパケットが通ります。

192.168.19.140への通し方

eth2においてsudo tcpdump -i eth2を行うとICMP リクエストパケットが来ているがリプライを返していないことがわかります。

sudo tcpdump -i eth0 を行うと192.168.19.100であるeth0のインターフェースよりICMPのリプライを返しています。

そこで/etc/network/interfacesに書いてあるStatic routeが反映されているかip routeを確認すると反映されていないことが分かります。

/etc/network/interfacesに書いてあるStatic routeをコマンドで入力するとNetwork Unreachableと出てきます。

ゲートウェイがルーティングテーブル内にないことが分かり、Static routeのゲートウェイのIPアドレスを確認すると、eth2のサブネット外になっていることがわかります。

eth2のL2内にあるゲートウェイのIPアドレスを調べるために送られてきているICMPパケットのMACアドレスを確認し、ARPテーブルを確認するとStatic routeに書いてあるゲートウェイのIPアドレスがあるので、そのアドレスがサブネット内に来るように計算し、設定を行うとICMPが通るようになります。


ちなみにこの問題はパスワードがospfとなっていたが全く関係なく、L2の調査が出来るかどうかを問う問題でした。

 /

問題文

日本拠点とベネチア拠点間にGREトンネルを開通する。
しかし、うまく疎通性の確認が取れない。
あなたは今から日本拠点のトンネル構築をするルータである 892J-A の設定を調査して解決し、何が原因だったのか報告してほしい。

情報

  • 892J-A

ポート: FastEtheret0〜7
ユーザー: admin
パスワード: 1Fa3Iiik

892J-Aのみ操作を行う

問題のゴール状態

PCから192.168.4.255 への疎通性がある

提出すべきもの

  • 設定したコンフィグ
  • 参加者PCから 192.168.4.255 までのトレースルートの結果

構成

禁止行為

  • 物理配線・論理構成(IPアドレス・VRFなど)の変更

トラブルの概要

  • tunnel vrf コマンドを入れていない為、GREトンネルがアップしない
  • +VRF tunnel にスタティックルートを書いてない為、192.168.4.255にPingが飛ばない

解説

今回のトラブルは、この中のGREトンネルのインターフェース(892J-Aのtunnel80)がLinkUpせず、PCから 192.168.4.255 へ疎通できないものでした。

まず、CiscoのGREトンネルの挙動についてのおさらいですが、GREトンネルはそれ自体のIPアドレスとは別にカプセル化したパケットの宛先IPと送信元IPもしくは送信元インターフェースを指定する必要があります。トンネルのインターフェースがLinkUpする条件は、この宛先IPアドレスへの経路がルーティングテーブルにインストールされているかどうかとなります。

これはVRF-Liteと呼ばれるルーティングテーブルを仮想的に分割する技術を使用していても使用することは可能ですが、その場合はカプセル化したパケットの宛先IPアドレスがどのルーティングテーブルに従って送信するかを明示的に指定する必要があります。今回の場合カプセル化したパケットはVRF global に従うように設定する必要があります。

その部分の解答コンフィグを以下に示します。

interface tunnel80
tunnel vrf global
exit

また、トンネルインターフェースとPCを接続するインターフェースが所属するVRF tunnel に、192.168.4.255 への経路が書かれていなかったため、それを手動で追加する必要があります。

その部分の解答コンフィグを以下に示します。

ip route vrf tunnel 192.168.4.255 255.255.255.255 192.168.4.201

以上のコマンドを入力することで、PCから192.168.4.255まで疎通することができるようになります。その時のtracerouteの結果は以下のようになります。

192.168.4.255 へのルートをトレースしています。経由するホップ数は最大 30 です

1 <1 ms <1 ms <1 ms 192.168.4.1
2 <1 ms <1 ms <1 ms 192.168.4.255

トレースを完了しました。

ここまでのコマンドとtracerouteの結果を示すことで、この問題は完答となります。またコマンドはこの通りでなくても同じことができるものであれば得点としています。

回答例

int tunnel 80
tunnel vrf global
exit
ip route vrf tunnel 192.168.4.255 255.255.255.255 192.168.4.201

採点基準

  • tunnel vrf コマンドを正しく入力している。:60%
  • スタティックルートまで正しく入力し、想定通りのtraceroute結果を示している。:満点
 /
カテゴリー

皆さんこんにちは!工学院大学大学院の増本奉之です。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には何らかの形で関わって行きたい思っています。
参加者及び関係者の皆様、本当にありがとうございました。

 /
カテゴリー

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

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

 

 

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

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

続きを読む

 /

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

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

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

 /

こんにちは。電気通信大学 学部1年の田中 京介こと kyontan です。

「cloudpack杯 第5回ICTトラブルシューティングコンテスト」では、FreeBSD を用いた問題を出題しました。
改めてその魅力を知っていただくと共に、出題した問題について、問題の概要や解説などをしていこうと思います。

概要

今回出題した問題は、FreeBSD と、その機能である Jail という仮想環境を用いた仮想ネットワークの構築を行うものでした。

出題意図として、皆さんが日頃から使っているであろう Linux とは異なった環境で新鮮な気持ちになって取り組んで頂けたらという気持ちがありました。また、最近 LXC, Docker を始めとしたコンテナ技術も流行っていますのでその先駆けとなった Jail の復権を……

続きを読む

 /

みなさんこんにちは!大阪工業大学藪野好一です。
ICTSC5が終了してからもうすぐ1ヶ月ですね。とても時間の経過が早いと感じるこの頃です。

前回は、WEBアプリケーションを作ってみましたというタイトルでブログを書かせて頂きましたが、今回は大会1日目の午前に出題したWEBサーバーに繋がりませんという問題の解説をしたいと思います。

問題文

ある部署の追加に伴ってネットワークの改修を行った。しかし、改修後サーバーに繋がらなくなった。このトラブルの原因を特定し、正しく繋がるように設定を変更して欲しい。また、変更点と原因を詳しく説明して欲しい。

トラブルの原因

この問題は、WEBサーバーに繋がらないといっていますが、原因はサーバー側ではなく経路情報の交換が行われないというトラブルで、そのトラブルを解決してもらう問題でした。経路情報が正しく回っていない理由は2つあります。

1つ目は、MTUのサイズの不一致で、2つ目がアクセスリストの暗黙のdenyによるOSPFパケットの拒否でした。対向するインターフェイスのMTUサイズが一致しないと隣接関係を確立することが出来ないため、OSPFでの経路情報の交換が行えません。アクセスリストとは、通過するパケットの許可と拒否を設定することが出来るリストで、通過が許可されていないパケットは通過が暗黙的に拒否されます。今回最初に適用していたアクセスリストでは、OSPFの通過を許可する条件に一致しないため、OSPFパケットの通過が暗黙的に拒否されます。

この2つの理由によりOSPFによる経路交換が行われなくなりWEBサーバーに接続できない状態となっていました。

yabuno_issue

まとめると次のようになります。

  • MTU(Maximum Transmission Unit)
    • 一度の転送で送れるデータの最大量
    • 対向のインターフェイスのMTUのサイズが違うとOSPFの隣接関係が確立出来ない
  • ACL(Access Control List)
    • 通過するパケットの許可と拒否を設定することが出来るリスト
    • 通過が許可されていないパケットは通過が暗黙的に拒否される

解決方法

今回のトラブルでは、OSPFによる経路情報の交換が行われていないため、OSPFにより正しく経路情報の交換が行われるように設定の変更を行う必要があります。そのために、対向ルーターのMTUサイズを一致させ、アクセスリストをOSPFが通過できるように書き換えます。これにより、OSPFによる経路情報の交換が行えるようになります。

yabuno_answer

さらに、次の2点の修正も行うことによりトラブルの発生を抑制したり、トラブルシューティングを容易にすることが出来ます。

1つ目がMSSの調整です。MSSとは、TCPで受信可能なヘッダを除いたデータサイズです。MTUサイズがイーサネットの標準サイズである1500から変更されている場合はMSSサイズも設定することが推奨されています。今回最初に設定されていたMTUサイズは1360だったので、TCPヘッダ(20byte)とIPヘッダ(20byte)の合わせて40byteを引いた1320をMSSサイズとして設定します。

2つ目は、アクセスリストで暗黙的に通過が拒否されているicmp のunreachableパケットの通過を許可する設定への変更である。このicmp unreachableパケットの通過が拒否されると、宛先に届けられなかったという情報が正常に帰って来ないためトラブルの原因となります。そのため、icmpのunreachableも通過を許可するようにアクセスリストを書き換えることが望ましいと考えます。

出題意図

普段は当たり前のように経路交換を行っているルーティングプロトコルがうまく動作しない場合の例とそれによって起こるトラブルを知って欲しいという思いから問題を出題しました。

最後に

1問目のインターネットに繋がりません問題と一緒に出題したため、問題の難易度が高くなってしまったようで、正解率はとても低かったです。
もし、OSPFが回っていないというトラブルに遭遇した際にこの問題の事を思い出していただければ幸いです。

今回初めてトラブルシューティングコンテストに関わらせていただきましたが、多くの経験をさせて頂きました。この場をお借りしてお礼申し上げます。実行委員のみなさま、運営委員のみなさま、参加者のみなさま本当にありがとうございます。そしてお疲れさまでした。

 /
カテゴリー

はじめまして!帝塚山大学の松 涼雅です。

ICTトラブルシューティングコンテストの参加は2回目となります。

今回は、HOT STAGE(会場内での準備期間)に入りましたので準備の模様を紹介します。

 

続きを読む