/

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

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

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

問題概要 : 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回大会で出題しようと思ってたんですが諸事情により出題できなかった問題なんです…

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

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

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

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

 /