/

こんにちは、電気通信大学 学部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つもありませんでした.

 /

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

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

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

問題概要 : 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攻撃という部類になり、その攻撃手法は今回のもののみではなく多岐に渡ります。
更に、その対処も難しいものとなっています。

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

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

作成者
麻生情報ビジネス専門学校 何 力平
概要
 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回大会で出題しようと思ってたんですが諸事情により出題できなかった問題なんです…

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

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

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

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

 /
 /
カテゴリー

はじめに

はじめまして。北海道大学の小林巧です。
普段は@chamaharunというアカウントでくだらないことをつぶやいたり、
石狩市にあるデータセンターでサーバー構築のアルバイトをしたりしています。
ICTトラコン、「名前だけは知っている」程度だったのですが、
昨年さくらインターネット新卒の凄腕エンジニア川畑さんよりお声がけいただきまして、

右も左も分からぬまま学生運営スタッフにjoinしました。
僕も問題作成をさせていただいているので、解いていただけると嬉しいです。

 

自宅ラックとは

「自宅ラックとは、ロマンである。」

ニコニコ大百科「自宅ラック」より

とありますが、自宅にデータセンター向け規格の19インチのラックを設置して趣味その他に使用することを言うようです。

自宅ラックとの出会い

自己紹介にも書いたように、データセンターでのアルバイトをしているのですが、

仕事に慣れてくるにつれて、業務で行っているBIOSの設定などの作業だけでなく、
ハードウェア交換といった保守作業やWebやDNSなどのサーバ構築作業を行ってみたくなったのと、
自宅にあったMicroServerで出来ることにスペック的にも拡張性的にも限界を感じていたところに、

昨年11月、幸いにも引越しが決まり、新居にて自宅ラックを始めたのでした。

 

ラックが自宅に届いた時の感動を振り返ってみようと思います。

 

19インチの静音ラックをヤフオクで入手。
ラック内に機器の設置と配線を済ませ、電源を入れてみる。。。
「ファーーーーー」
って音、まるで自宅がDCになったかのようです。。。
さて、ラックの防音効果は如何ほどか、
サイドの蓋を閉め、前面のドアを閉めます。
「ゴオオオオオオオオオ」
全然静音じゃない。まるで轟音ラック。
これからは毎日これと共に寝るのか。
自宅ラック生活がスタートしました。

 

こばやしの自宅ラック

こんな感じです。

1

  •  DELL R415 8コア 8G
  • FUJITSU RX200S5 8コア 32GB
  • HP MicroServer N54L 2コア 16GB
  • HP MicroServer N54L 2コア  8GB
  • DELL PoerConnect 5224
  • HP MicroServer N54L 2コア 8GB

いずれも新品で揃えると150万円前後かかると思いますが、一学生に出せるような金額ではないので、
型落ちで安くなった新品を購入したり、ヤフオクや秋葉原で中古品を手にいいれることで、
10万円前後の支出に抑えました。
XenServerとHyper-Vによる仮想マシンが30-40台程度常時起動していて、

そのほとんどがWebサーバで、Webサービスを開発したり、友人に貸したりしています。

 

工夫していること・苦労していること

ドメインとIPアドレス

複数のWebサーバに外部からアクセスするにあたって、1つ問題があります。
VPSなどのインフラサービスと違って、一つのIPアドレス共有しなければならないので、
HTTPのリクエストも、SSHも直接IPアドレスに対して繋ぎに行くわけには行きません。

そこで、HTTPとSSHにそれぞれ、代理サーバを用意しています。

ルータから特定のポートに来た通信をそれぞれに転送するよう設定します。

nginxでは以下のような設定ファイルを書くことで簡単にリバースプロキシを構築することができます。

 

server {
    listen 80;
    server_name hime.charakoba.com;

    proxy_set_header    X-Real-IP       $remote_addr;
    proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header    Host            $http_host;
    proxy_redirect      off;
    proxy_max_temp_file_size    0;

    location / {
        proxy_pass http://192.168.11.125;
    }
}

 

特に、HTTPのリバースプロキシは設定ファイルの書き換え/再読み込みを頻繁に行うので、

図のように、ロードバランサを置いて片方のリバースプロキシがダウンしていても正常にリクエストに答えられうようにしています。

3

SSHの踏み台サーバは、よりセキュリティを意識して構築しています。

rootでのログイン禁止はもちろん、

全ユーザーに対して公開鍵認証を要求しパスワード認証を禁止します。

こばやし家内のサーバにアクセスする場合は、

踏み台サーバに対して一度SSHログインしたのち、対象のサーバにSSHでログインします。

2

 

一般の家庭であるこばやし家には動的IPアドレスが一つ割り当てられています。

変動するIPアドレスにドメインを割り当てる方法として、IPアドレスが変更される度にDNSサーバに通知し更新してもらう、

DDNS(DynamicDNS)というものがありますが、DDNSで設定できるドメインってあまりカッコいいイメージが無かったので、

何か良い方法はないかと調べていたところ、

お名前.comで取得したドメインはDDNSで使えそうということがわかり、

WindowsServerでクライアントを設定し運用しています。

 

 

最後に・こばやしのやぼう

他にも、新規仮想マシンを作成した際にあらゆる設定を自動化するような実験などを行っています。
今後は騒音と電気代の面から自宅ラックを実家に移設し、
VPNを張って遠隔で管理したりしていこうかと考えています。

まだまだこばやし家は発展途中ですがこういった工夫をすることで、
IT企業が普通に行っていることを高価な機器を使わずに実現できたらなぁと考えています。

 /
カテゴリー

こんにちは!電気通信大学の吉村と申します。

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

前回のICTSC4ではネットワーク寄り、今回はサーバ・インフラ寄りで担当しており、まだまだわからないことも多いのですがどうぞよろしくお願いいたします。

 

さて、今回はDNSサーバについての話をします。

DNSサーバと聞いてまず最初に思い浮かぶのはBINDかと思います。

ですが、今回は”NSD”というDNSサーバを紹介します。

続きを読む

 /
カテゴリー

はじめまして!情報科学専門学校 荒川です。
ICTSC5運営委員では、主にインフラチームとしてL1周りを担当しております。

突然ですが!

150台強の仮想サーバを少ない人数で管理しようとしたとき、
今時手作業でやろうとかは思わないですよね・・・

  1. パッケージインストール
  2. ホスト名の設定
  3. 各インスタンスのパスワードを変える

たったこの3ステップを全サーバに手作業で適用させようするならば

fw3HA6j7ZeoSgdn <やってられるかこんな作業!

まあ、こうなりますよね・・・

そこで出てくるのが

構成管理ツール

その中でも今日はAnsibleの紹介。

そもそもAnsibleとは?

  • 管理対象のサーバーに特別なソフトウェア(エージェント)をインストール不要!
    SSH で対象サーバに接続さえ出来ればいい
  • クライアント側になにもいらない
  • モジュールは「どんな」言語でも書ける
  • 誰が何回実行しても、同じ結果になる ←ココ重要

設定ファイルを用意せずとも、簡単に指定した複数のサーバーで特定の処理を実行させることが可能です。

早速使ってみました。

Vagrantで起動したCentOSにAnsibleをインストールしてみました。
CentOSは7.2.1511を、Ansibleは1.9.4を使用しました。

EPEL リポジトリのインストール

# yum install -y epel-release

yum install コマンドでインストール

# yum install -y ansible

Ansibleでは、設定ファイルをYAML形式というシンプルなフォーマットで記述することが出来ます。

例: Apache と PHP をインストールする

webapp.yml

  • hosts: webserver
    user: vagrant
    sudo: yes
    tasks:
  • name: install apache
    action: yum pkg=httpd state=installed
  • name: install php
    action: yum pkg=php state=installed

実行

$ ansible-playbook webapp.yml

これで簡単に指定した複数のサーバで特定の処理を実行させることが可能になります!

20080331002943<ね?簡単でしょ?

まだまだAnsibleの使い方はたくさんあるので、詳しくは参考サイトを見てください。

参考サイト
http://knowledge.sakura.ad.jp/tech/3124/
http://tdoc.info/blog/2013/04/20/ansible.html
http://apatheia.info/blog/2013/04/06/about-ansible/

最近のコメント