/
カテゴリー

こんにちは!運営委員の河瀬大伸です!
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は最終手段であり、使うのはあまり推奨されるものではない」とのコメントを頂き、私としても新しく知ったことも多かったです。

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

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

 /

みなさんこんにちは. 2日目午前の問題 (サーバーが再起動する!) を作成した市川です.

本問題の背景 (CVE-2015-5600の概要)

OpenSSHでは,LinuxのPAMモジュールを利用することで認証プロセスをアプリケーションから分離して行うことができます.パスワードを用いた認証には大きく分けて2種類の方法があり,

  •  PasswordAuthentication
  •  ChallengeResponseAuthentication

です.

いずれの方法もLinuxに登録されているユーザーの認証情報を用いてログインを行いますが,PasswordAuthenticationが平文でパスワードの照合を行うのに対し,ChallengeResponseAuthenticationはチャンレンジレスポンス認証を用いるため平文パスワードがネットワークを流れることはありません.(もちろんSSLで暗号化されているため平文ではないが,復号するとパスワードがそのまま見える,という意味です.)
以上の理由からChallengeResponseAuthenticationが用いられることはそれほど珍しくなく,また鍵の設置を必要としないため緊急時のログイン手段としてはよく用いられます.

さて,ChallnegeResponseAuthenticationを行うデバイスにはbsdauth, pam, skeyがあり,これらを指定することで認証デバイスを順に試すことができます.今回用いた脆弱性CVE-2015-5600は,このデバイスにpamをカンマ区切りで大量に指定することで,パスワード認証の本来の上限回数を超えて試行出来てしまう,というものです.

問題文

最近サーバー(10.X.10.2)が頻繁に再起動して困っている.
原因調査と問題解決をお願いしたい.
また,報告する際には

  • 何が原因だったのか
  • それに対しどのような対処を行ったか

を明記していただきたい.
また,サーバーに何らかの脆弱性が存在する場合は必ずその箇所を修正すること.

解説

問題が公開されてからしばらくすると,CVE-2015-5600を悪用したブルートフォース攻撃が開始されます.攻撃対象のユーザーubuntuのパスワードは12345に設定されており,10000から順にインクリメントしながら攻撃を行います.ログインに成功したらすぐにsudo rebootを行い,作業妨害を行うことを繰り返します.
なお,Linuxの標準の設定ではPAMモジュールにfaildelay (ログインが失敗した際,強制的に待ち時間を入れるモジュール)が設定されており,これでは競技時間内にブルートフォース攻撃を複数回仕掛けることは困難でした.そのため/etc/pam.d/以下のfaildelayに関する設定を全て解除,無効化し,1秒間に最大で約10回のパスワード入力が試行できるよう細工を施しました.

この問題を解決するためには,

  • ChallengeResponseAuthenticationを無効にする
  • 公開鍵認証方式に変える
  • /etc/pam.dの不適切な設定を修正する

などの対策を講じることで解決できます.(以上3点が揃った解答に対しては満点を与える予定でした.)

講評

ほとんどのチームが

  • 特定の端末 (攻撃サーバー)からのアクセスを制限
  • ubuntuユーザーの設定を変える (パスワード変更,sudo権限剥奪,ユーザー削除)

など,根本的な解決に至っていない解答をしていました.そのため問題文に
また,サーバーに何らかの脆弱性が存在する場合は必ずその箇所を修正すること.
の部分を強調して再度周知したものの,完全な正解に至る解答は見られませんでした.
麻生情報ビジネス専門学校チームが唯一CVE-2015-5600に言及しており,高い得点を与えましたが,PAMの設定不備を指摘したチームは1つもありませんでした.

 /
作成者
麻生情報ビジネス専門学校 何 力平
概要
pingはIPネットワークにおいて、ノードの到達性を確認するための基本的なツールの一つである。pingはICMPの”echo request”パケットを対象ノードに投げ、対象ノードから”echo reply”が返ってくることで到達性を確認する。
Address Resolution Protocol (略称:ARP)は、イーサネット環境で、IPアドレスから対応するMACアドレスを動的に得るためのプロトコル。代理ARP:他のネットワークにARP要求があった場合にルーターがホストに代わって回答する仕組みである。Proxy ARPなどと呼ばれており、NAT環境化において使用される例が多い。
スタティックルーティングとは、ルータなどが、管理者が予め設定した固定的な経路表(ルーティングテーブル)に基づいて経路選択を行なうこと。スタティックルーティングは経路情報の交換がない分通信量を節約でき、外部から不正な経路情報を送信される危険性もない。
本問題では経路を選択する方法を聞きます。
問題文
選手達はROUTER2とROUTER3を管理しています。
10.0.0.1がら20.0.0.1にPING(echo request)すると、パケットはROUTER2を経由し、20.0.0.1に到着します。
逆に、20.0.0.1から返信(echo reply)すると、ROUTER3を経由し、10.0.0.1に到着します。
ROUTER0とROUTER1の設定を参照しながら、ROUTER2とROUTER3を設定してください。
ルーティングテーブルを変更しないでください。
rikihei-topo
解決方法
R2
 interface GigabitEthernet0/1
no ip proxy-arp
R3
interface GigabitEthernet0/0
no ip proxy-arp
講評
key words in 892J:
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0
mac-address-table aging-time 16
本問は見た目がルーティングテーブルを変更せずに特定の通信経路を選び、とても難しい問題です。実はL2、L3の技術とOSI7層の動きを組み合わせ考えると、簡単な問題です。
問題の考え方法は通信経路を選ぶ機器がルーターだけではなく、892jのスイチ機能を気づき、ルーターの適当のポートに「no ip proxy-arp」を使います。
ネットワーク技術者としていつも新しい技術を勉強することは大事だけど、学んだ知識、特に基本知識の活用が大切だと思います。そして、勉強するときにコマンドを暗記ではなく、「なぜ」、「どのように使う」、「他の似ている技術との差」を理解することが必要です。
残念ですが、今回、満点の解答を行ったのはありませんでした。次回は似る問題を出るかもしれませんが、選手たちの答えを期待しています。
 /

はじめまして。本問題の雑用係をしています工学院大学の福田夏樹と申します。

問題解説のブログを書いて欲しいというリーダからのお願いを受けて、締め切りギリギリになって本記事を書き始めました。

拙文ではありますが、問題解説をさせていただきます。

問題概要 : Webページが見られない

問題文

本日、我が’boku-tech company’のカスタマーサービスセンターから、
「Webページに接続できない。接続できても重い」
という苦情が寄せられていることが判明した。
また、数日前に新しいサーバが納品され、社内のネットワークのどこかに接続されたようだ。
しかし、その作業は外部の業者が行っており、ネットワークや納入されたサーバの状況を社内で知っている人はいない。

今回に限り、優秀な技術者と聞く君たちに該当のサーバ類の一部の操作権を付与する。
現状を調査した上でその解決をし、その原因と解決方法を報告してほしい。
なお、サーバ上では各種サービスが動いているらしいが、それらや他のサーバを完全停止することはできない。

我が社が作業を外注した時の資料を入手することができた。
その資料には下記の制約が書かれていた。
この制約を満たすように設定・定義してもらいたい。この制約に反しないかぎり、他の設定を変更しても構わない。

  • webサーバーのリソースをsnmpプロトコルを用いてサービスサーバにログが残させる事
  • Service Server に対して、ドメイン “service.rabbit” のAレコードが引けること
  • webサーバに含まれるコンテツの再生が出来る事

君たちが操作できるサーバは下記のとおりである

Service Server

  • IP : 10.X.8.66
  • User: admin
  • Password : チームごとに与えられているもの

Web Server

  • IP: 10.X.8.2
  • User: admin
  • Password : チームごとに与えられているもの

Router
– IP : 10.X.8.192
– User: vyos
– Password : チームごとに与えられているもの

トラブルの原因

まずは、トラブルを起こしていたトポロジ図は下記のようになります。

トポロジ図

今回の問題でトラブルとして使用したものは次のものです

  • SNMP のリクエストによるCPU枯渇
  • Ping パケットの大量送信による帯域枯渇
  • SYN Flood によるセッション数枯渇

その他、仕込んでいたトラブルも有りましたが、そのあたりは ICTSC5の1日目にあったLTの資料をご参考にください。

解決方法

上記のトラブルの原因を一つ一つ解決していけば解決できます。

代表的な解決方法を上げると、以下のようになります。

SNMP

SNMPのコミュニティ名をデフォルトである public から任意のものに変更する。

今回の問題では、/etc/snmp/snmpd.conf に記述されている public という文字列を任意のものに書き換えることができれば解決になります。

Ping

VyOS にて、ICMPのフィルタリングをする。

フィルタリングの方法は複数あるので、コマンドは省略しますが、検索をかけるといくつか出てきます。

SYN

サーバOSのSynCookieを有効化する。

今回の問題の場合は、次のコマンドを入力すると解決になります。

 

sysctl -w net.ipv4.tcp_syncookie=1

 

などあります。

その他の解説などは、本問題担当であった法政大学の伊東氏がLT資料ブログを書いているので、ご参考にしてください。

出題意図

近年世界的に起きているDoS攻撃の基本的な対策方法を日本の若きエンジニア達に知ってほしいため、
また、前回大会において出題されたセキュリティ攻撃に関する問題においての解答率が出題者の想定よりも低かったため、本大会では攻撃の種類を変えて、再度出題しました。

採点基準

問題文に記述されている

  • webサーバーのリソースをsnmpプロトコルを用いてサービスサーバにログが残させる事
  • Service Server に対して、ドメイン “service.rabbit” のAレコードが引けること
  • webサーバに含まれるコンテツの再生が出来る事

を満たす様な設定ができているかを判断しています。

簡単に言うと、原因となっている攻撃がフィルタリング等できていれば得点が入る様にしました。

最後に

問題を解いたみなさんは、解けた時はとても嬉しいと思いますが、
実は出題者側も、みなさんが解いてくれた時は嬉しかったりします。

本問題は一般的にはDDoS攻撃という部類になり、その攻撃手法は今回のもののみではなく多岐に渡ります。
更に、その対処も難しいものとなっています。

セキュリティ的な脆弱性も、ヒューマンエラーによるものでも、ソフトウェアにある潜在的なものでも、トラブルの元となるということも知っていただければ幸いです。

では、又の機会にお会いしましょう。

 /

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

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

概要

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

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

続きを読む

作成者
麻生情報ビジネス専門学校 何 力平
概要
 RFC 3986では 予約文字(Reserved Character)と非予約文字(Unreserved Character)が定められています。
予約文字:区切り文字などの特定目的で用いるために予約されている文字であり、その目的以外ではURLに使用できません。
ファイル名には次の文字は使えません
: / ?  * < > | \
URLには次の文字は使えません(予約文字)
: / ? * # [ ] @ ! $ & ‘ ( ) + , ; =
パーセントエンコーディング(英: percent-encoding)とは URLにおいて使用できない文字を使う際に行われるエンコード(一種のエスケープ)の名称である。RFC3986のSection 2.1で定義されている。
一般にURLエンコードとも称される。
本問題ではURLにおいて使用できない文字を使い、ダウンロードできないようになっている。
問題文
あなたはABC社のCEです。
お客様から「会社新製品のマニュアルをダウンロードできない」というようなクレームが出ました。
  URL  http://192.168.1.1/product/question#20160227.txt
原因を分析し、その原因を説明する簡単な文章を提出してください。
ダウンロードしたマニュアルも併せて提出してください。
お客様の作業環境:
     Windows7/10+Firefox/Chrome/Iexplorer10/Iexplorer11
解決方法
解決方法は#をパーセントエンコーディングを使い、%23に替えることです。
http://192.168.1.1/product/question%2320160227.txt
講評
本問はネットワーク問題かサーバー問題か分類しにくいだけど、現実でよく出るトラブルです。
RFC 3986では予約文字と非予約文字が定められています。予約文字-区切り文字など特定目的で用いるために予約されている文字で その目的以外ではURLに使用できません。
それでWeb ブラウザが#や!や@などの予約文字があるURLを解読するときに認識ミスを起こしました。
解決方法は#をパーセントエンコーディングを使い、%23に替えることです。パーセントエンコーディングとは URLにおいて使用できない文字を使う際に行われるエンコードの名称です。一般にURLエンコードとも称されます。このような知識は教科書にも載っていないから、選手たちの知識の広さと深さが要求されます。
 /

こんにちは!問題作成者の帝塚山大学の松涼雅です!

共同作成者の大阪工業大学の上野洋太郎です!

 

僕たちが作成した問題の解説と裏話をしていきたいと思います。

僕たちが作成した問題は1日目の午前に出題しました。

 

起きていたトラブルをまとめるとこんな感じになります。

起きていたトラブル

  1.  .htaccessファイルの記述を間違えているためwebページが表示されない
  2. ディレクトリのパーミッションが間違っているためapache(www-data)からwebページが参照できない

この二つです。

 

結果

完答したのは3チームでした!

完答ありがとうございます!

点数を獲得したのは7チーム(完答含む)でした。

 

どこで点数差がついたの?

きっと気になるのは採点基準ですよね。

採点基準は上にまとめた二つの項目が解決できているかってだけです。

.htaccessファイルを修正できているか、ディレクトリのパーミッションを修正できているか

この二つです。

完答してくださった3チームは二つとも修正してくれました!(うれしい!)

のこりの4チームはディレクトリのパーミッションの修正のみでした。

 

ディレクトリのパーミッションの修正だけはダメなの?

実は回答をしてくれた全チームのwebサイトに実際にアクセスして挙動を確かめたのですがディレクトリのパーミッションを修正しただけだとwebページ上のリンクを踏んだ際に正しい挙動をしないんです。

URLを直打ちした場合だとちゃんと表示されちゃうんですけどね。

 

URL直打ちできたら十分じゃないの?

  1. もしそのwebページをブックマークしている人がいたらどうしよう?
  2. その人はURLを直打ちできる?(URLの直打ちを一般ユーザに強要しちゃう?)
  3. 何のためにリダイレクトの設定をしたんだろう?(間違ってるんだけど)
  4. リダイレクトの設定をすることでブックマークで直接アクセスしてくるユーザも強制的に新しいwebページへ誘導してあげれるんです。

問題作成者の僕らとしては、ここらへんを重視した採点をしていたのでリダイレクトの設定を修正できていなかった場合は点数を低めにしました。

 

まとめ

起きていたトラブルはこんな感じ

  1.  .htaccessファイルの記述が間違えているためwebページが表示されない
  2. ディレクトリのパーミッションが間違っているためapache(www-data)からwebページが参照できない
  • 上の二つのトラブルを修正できればok!
  • だけどディレクトリのパーミッションの修正のみのチームが多かったよ
  • URL直打ちしたらパーミッションの修正のみでも行けるけど一般ユーザはそれで対応できる?
  • .htaccessファイルを修正することで一般ユーザに手間をかけさせないようにした方が良いと思う

って感じです。

 

あとがき

実はこの問題は第4回大会で出題しようと思ってたんですが諸事情により出題できなかった問題なんです…

少しでも皆さんに楽しんでいただき、「あ、こんな技術があるんだ~」って思ってもらえるのが作成者の一番の喜びです。

もし、問題作成などに興味のある方はぜひ運営に参加してください!

問題作成以外にもネットワークの設計やサーバの構築など色々あるので運営参加者のニーズを満たせること間違いなしです!

ぜひよろしくお願いします!

 /

最近のコメント