ICTSC, イベント

お久しぶりです。ICTトラブルシューティング(以後トラコン)実行委員会の伊勢幸一です。このツチノコブログでも様々なブロガーによって何度か紹介されているので、ご存じの読者も多いと思いますが、学生による、学生のためのインフラ技術コンテストであるトラコンの第5回目が、来る2016年2月27日、28日に六本木ミッドタウン、シスコシステムズ合同会社にて開催されます。トラコンに関する過去のツチノコエントリーは以下をご参照ください。

ツチノコブログICTSCエントリ集

 

それでは「cloudpack杯 第5回ICTトラブルシューティングコンテスト」の参加チームをご紹介しましょう!

banar0-860x225

エントリーNO. 1 チーム「MOTHER4」 ECCコンピュータ専門学校

大阪市梅田にあるECCコンピュータ専門学校は第1回、第2回、第3回のトラコン出場実績があります。前回の第4回にもエントリーしていただいたのですが、残念ながら事前選考審査に洩れてしまい、出場がかないませんでした。ごめんなさい。今回は参加募集開始直後、真っ先にエントリーをしてきていただき、無事に事前選考審査を通過して再び出場していただくことになりました。前回参加できなかった無念を晴らしてください。

 

エントリーNO.2 チーム「WCDI」 日本工学院八王子専門学校

前回のチャンピオン校で関係者の記憶にも新しいチームです。今回はメンバーが一部入れ替わっているとはいえ、まぎれもなくディフェンディングチャンピオンとして、他チームの挑戦を受ける立場にあります。日本工学院八王子専門学校も第2回から参加し、続く第3回、第4回は同じチーム「WCDI」として参加しています。サーバ、ネットワーク、アプリケーションとバランスの良いチーム構成を特徴とし、今回も優勝めざして連覇を目指すと血気盛んです。

DSC_8560

エントリーNO.3 チーム「RabbitHouse」 東京電機大学

今回初出場のチームです。メンバー全員がコンピュータ大好き人間で、いままでコンピュータ技術に対し全力で取り組んできたとの事です。今回はもっとたのしい事、面白い事を知るために本コンテストにエントリしてきました。ちなみに東京電機大学は、調布にある電気通信大学、大阪電気通信大学それぞれと全く関係は無いそうです。

 

エントリーNO.4 チーム「FJB技術部」 船橋情報ビジネス専門学校

第2回に初出場。そして前回の第4回でも出場している千葉県にある専門学校です。今までチームメンバーは各回毎に入れ替わっていましたが、今回のメンバーの中の2名は前回コンテストにも参加したトラコン経験者、前回の結果は不本意に終わってしまったので、今回は納得できる結果を出したいとの事です。「結果を出す」。大事ですね。私も見習わなければなりません・・・

 

エントリーNO.5 チーム「WAN PUNK MAN’s」 東北電子専門学校

第2回に初出場、以後メンバーを変えながら第3回、第4回と連続出場している宮城県仙台市のチームです。リーダの門脇君は前回もリーダを務め、また東北電子専門学校の学内ネットワーク技術コンテストであるN-1の第2回大会実行委員長でもあります。N-1は第2回のトラコンに出場した同校のメンバが「こういうコンテストを学内でもやりたい!」と自分達で企画し学校の先生等にプレゼンテーションをして実現しました。同校のネットワークセキュリティ科の1年生を対象とし、2年生が問題作成と運営を行う競技です。第2回目のN-1は先日2016年2月13日に開催されました。学内でも学生が企画運営し学生が参加するというコンテストイベントが増えるといいですね。

DSC_0717 DSC_0720

エントリーNO.6チーム「KanaiLab」 法政大学

今回が初出場です。チーム名から想像すると理工学部応用情報工学科金井敦教授の研究室のメンバーだと思います。トラコン初体験なのですが、優勝目指して頑張るというコメントを頂いています。実は今回のコンテストで学生運営委員として参加している伊東道明君も法政大学なのですが、本人に聞いてみたところ特に誘った訳でも無いとの事。ただ伊東君はツィッターとかでトラコン情報をつぶやいていたのでそれを見て参加する事にしたのかも?おそるべしSNS。

 

エントリーNO.7チーム「麻生情報ビジネス専門学校 CN科」 麻生情報ビジネス専門学校

第1回に初出場、そしてしばらくお休みし一年ぶりに前回の第4回に出場し、今回は2回連続出場です。今回のトラコン運営委員をしている何力平(カ リキヘイ)君は前回の参加メンバーの一人です。麻生情報ビジネス専門学校には北九州校と福岡校がありますが、今回の出場メンバーは福岡校の生徒だそうです。九州からの出場はこのチームだけですので頑張ってもらいたいですね。

 

エントリーNO.8チーム「mi_chan」 神奈川総合産業高校

初出場かつ本コンテスト初の高校生チームです。事前情報は全くありません。募集要項では本来このコンテストの対象は高専、専門学校、大学、大学院と記載されていたので、最初自分たちには参加資格が無いと思っていたそうですが、直接運営委員に問い合わせて高校生でも参加できると知って応募したそうです。

応募要項の対象学生に高校生を入れて無かったのは、まさか高校生が参加するとは思っていなかっただけで、もちろん高校生チームでも参加可能です。次回からの参加対象には高校生も含めますね。

 

エントリーNO.9チーム「\U1F62A」 九州工業大学大学院

前回「端末なかったので一旦解散しました」というチーム名で参加した吉浜君と神武君に新メンバー3名を加えての再挑戦です。前回は上位グループに位置してはいましたが残念ながら入賞は果たせず。今回は前回の反省を含めネットワーク問題への対策を万全にしての参加です。メンバー全員が大学院2年生であり今年度で修士過程を終了するため、本トラコンで優勝し、有終の美を飾ろうと意気揚々です。ちなみにチーム名の「\U1F62A」というのはUnicodeでいうと「sleepy face」なのですが、なんで?

端末無かった

エントリーNO.10チーム「Yakisoba」 筑波大学

本コンテストには初出場ですが、メンバー全員がセキュリティ・キャンプの卒業生であり、アルバイトとしてエンジニアをしたり、危機管理コンテストや様々なハッカソンへの参加経験があるそうです。プログラミング、サーバ、セキュリティ問題等に強さを発揮しそうな予感。またこういったCTF系のエンジニアがサーバネットワークというインフラ問題にどう取り組むのか興味深々ですね。それにしても筑波大学の学食では「焼きそば」が人気メニューなのかしら?

 

エントリーNO.11チーム「かやはらパン」 専門学校穴吹コンピュータカレッジ

メンバー全員がネットワーク大好きというこのチームの通う学校は第1回、第3回と出場し、本大会では3回目の挑戦です。四国の香川県高松市にある穴吹コンピュータカレッジは学校法人穴吹学園グループのカレッジ校です。同学園の穴吹情報公務員カレッジも第1回から第4回まで連続出場しておりますが残念ながら今回は出場していません。穴吹情報公務員カレッジは第2回の優勝チームでもあります。穴吹コンピュータカレッジと穴吹情報公務員カレッジを合わせるとこの穴吹学園だけが唯一第1回から第5回まで連続出場している事になります。皆勤賞おめでとう!

穴吹

エントリーNO.12チーム「ぷちKAIT」 神奈川工科大学

前回「Qool-five」(クールファイブと読みます)というチーム名で初出場し、今回で2回連続出場となりますが、メンバーは総入れ替えされています。というより、メンバーの所属学科はQool-fiveと同じ情報ネットワークコミュニケーション学科なのですが全くの別チームなのでしょう。ということは初出場も同然なので緊張せず普段の力を存分に発揮してもらいたいです。

 

エントリーNO.13チーム「中川パブリック」 千葉工業大学

今回初出場です。若年者ものづくり競技大会や技能五輪のITネットワークシステム部門の出場を目指し、技術修得に取り組んでいる仲間が集まってチームを編成し、本トラコンに挑戦することになったそうです。これらのものづくり競技や技能五輪は実際にサーバやネットワーク機器などをケーブルで接続し、OSをインストールしたり環境パラメータを設定してシステムを構築したりする競技で、トラコンの競技スタイルと良く似ています。初出場ですがひょっとするとトラコン競技との相性は良いのかも。

 

エントリーNO.14チーム「MWC」 早稲田大学

今回が初出場です。学部4年生と大学院2年生による混成部隊となってます。どのような背景でトラコン参加に応募してきたのか全く情報が無いので、競技当日に聞いてみたいと思います。

 

エントリーNO.15チーム「kstm」 信州大学

今回が初出場であり、大学名から長野県にある学校であることがわかります(あたりまえ)。このチームは先輩からこのトラコンの事を教えられ、そして挑戦する事になったそうです。初出場チームであり、またその先輩という方にも私は面識無いのでそれ以外の情報は全くありません。こちらも競技当日に話を聞いてみたいと思います。

 

また、今回から運営学生達がブログを始めました。

http://icttoracon.net/tech-blog/

こちらも覗いてみてください。運営学生がどのようにコンテストを構成しようとしているのかの片鱗がうかがえます。

それでは運営側も選手側も風邪などひかないように体調管理を大切に。トラコン当日に六本木ミッドタウンで会いましょう!

CONBU, wifi, コラム, セキュリティ

くまがいです。CROSS2016 ご来場ありがとうございました。大盛況で楽しかったですね。会場無線 LAN を CONBU で提供していましたので、繋がらない報告がないか Twitter を追っていたら、こんな投稿を見つけました。

WiFi繋いだら現在地が秋葉原になってる #cross2016

CROSS2016 は横浜ですので、位置情報がおかしいですね。

Wi-Fi測位のしくみ

スマホが現在位置を取得する方法のひとつとして、Wi-Fi の BSSID(MACアドレス) を利用したシステムがあります。端末は、周囲に見えている Wi-Fi の BSSID をサーバに送りつけます。するとその BSSID に対応した位置が返ってきます。

簡単な仕組みですが、これを世界中で実現させるには途方もない労力が必要です。位置とそれに対応する BSSID のデータベースを構築するには、測位したい全ての場所へ行って無線 LAN を受信する必要があり、今後も更新していかなければなりません。

スマホが Wi-Fi AP の位置情報を収集している

Skyhook Wireless(2010年頃以前の iOS での利用で有名)は、ウォードライビング、車で移動しながら無線 LAN を受信することによってデータベースを構築したといわれていますが、現在 Google や Apple は、この情報収集をスマホユーザ自身にやらせています。

たとえば iOS では、近くの Wi-Fi アクセスポイントの情報とその位置を端末に保存しておき、定期的に Apple へ送信しています。

Apple は Wi-Fi 測位に関する API や、誤った位置情報の修正、オプトアウトの手段などの情報を公開していません。iOS 8 および iOS 9 のプライバシーと位置情報サービスについて の「Wi-Fi と基地局の位置情報のクラウドソーシングデータベース」で何をやっているのか書かれていますが、これ以外の公式情報は見つけられませんでした。

本当のところ何を送ってるんだろう

ここまでは比較的広く知られていることかもしれません。が、具体的にどのような情報がやりとりされているのかはあまり知られていません。

試しに、手元の iPhone がどんな情報を送っているのか観察してみようと思います。使ったのは (iPhone5s, iOS8.2.1), (iPhone5, iOS9.2.1), Burp Suite 1.6.32 です。ちょっと古い理由は特になく、たまたま手元にあったからです。

観察・収集編

我々の iPhone で収集された Wi-Fi と位置データが Apple のサーバへ送信されていく様子です。
pbcwloc_270_01
おっ、何か MAC アドレスっぽいものを送っているのを見つけた!?

pbcwloc_270_02
うわー! バイナリかよ、解散~ と思いましたがこれは Protocol Buffers でシリアライズされた何かのようです。JSON や XML のような人間にやさしいエンコーディングではないため一瞬諦めそうになりました。

Protocol Buffers はバイナリエンコーディングのシリアライズフォーマットで、データ構造はエンコーディングに含まれません。データ構造は別途 IDL(インタフェース定義言語) の .proto で定義して使うもので、エンコードされたデータからはデータ構造がよくわからないのです。

ちょっと .proto をでっち上げてみました。中を見ても何だか分からない項目がいっぱいあります。いくつかは iOS7 か 8 で増えたようです。

message WiFiAccessPoint {
required string bssid = 1;
optional int32 channel = 2;
optional int64 signal_dbm = 3;
message Location {
required double latitude = 1;
required double longitude = 2;
optional int32 unknown3 = 3;
optional int32 unknown4 = 4;
optional int32 unknown5 = 5;
optional int32 unknown6 = 6;
optional int32 unknown7 = 7;
optional int32 unknown8 = 8;
optional int64 unknown9 = 9;
optional int64 unknown10 = 10;
optional int32 unknown11 = 11;
optional int32 unknown12 = 12;
}
optional Location location = 4;
optional string application = 5;
optional int32 unknown7 = 7;
}
message SmartphoneToAppleRequest {
repeated WiFiAccessPoint ap = 3;
}&

実をいうと、このメッセージは2013年頃(iOS6.0)に一度解析したことがあります。それを使って、今回のブログで気楽なネタにしようと思ったら、内容が丸ごと変わっていて全然気楽じゃありませんでした!!!

この .proto でデコードしてみたところ、以下のような内容を Apple へ送信しているようです。

ap {
bssid: "74:3:bd:28:xx:xx"
channel: 4
signal_dbm: -89
location {
latitude: 35.6897295965
longitude: 139.770113602
unknown10: -1
unknown11: 7
unknown12: 0
}
application: "com.google.Maps"
unknown7: 0
}

このケースでは、収集した約300個の BSSID が Apple へ送信されたのを観察できました。無線LANについては BSSID, チャネル、電波強度らしきものが送信されていて、SSID は送信されていないようです。_nomap は考慮されていないようで、ssid_nomap という SSID を出してみたところ普通に送信されていました。Apple に関しては _nomap は効いていないようです。

lat/lng の座標以外には、位置情報をリクエストしたであろうアプリの Bundle ID らしきものが入っています。自分の場合は他に com.protogeo.Moves や com.google.ingress などが入っていました。

その他に、端末の機種名と OS のバージョンも送っていますね。端末を個別に識別するようなものはなさそうです。HTTP ヘッダにも怪しいものはありません。認証もなく、匿名で突然送りつけているようです。

位置情報が狂う原因

AP を持ってオフィスの引越しをすると、引越し前の位置が表示されてしまうことがあります。オフィスに設置していた AP の BSSID に対応する位置情報が更新・収集されていないのが原因ですが、オフィスはともかく、最近は個人宅ではあまり聞かない現象のように思います。なぜオフィスの引越しでよく起こるのでしょうか?

オフィスには複数の AP があり、複数の BSSID が受信できるとします。すると、引越し以前から近隣にある AP よりそれらを優先して使われてしまうのかもしれません。また、都心のオフィスでは空が開けていない場所が多く、GPS の電波が受信しにくいため、BSSID と位置情報が更新されにくいのかもしれません。

更新に関しても、端末の識別もなく収集しているため、ある程度のデータが溜まって確信度が高くならないと有効にならないはずです。

収集されたデータがどのように運用されているのかは調べようがなく、曖昧な記述になってしまいましたが、きっと大きく外してはいないと思います。

観察・利用編

普通に現在位置を取得するパターンです。iOS で現在位置を取得するアプリ(ここでは Google Maps)を起動してみます。

clls_01_03
BSSID らしきものを送っていますね。これらの BSSID は確かに現在、周囲に見えているものです。

clls_02_03
位置情報が含まれたレスポンスが返ってきました。結構大きいようです。送った BSSID の他にも大量に何かがくっついています。例によってバイナリですが、これも Protocol Buffers ですので解析してみます。

でっちあげた .proto です。

message WiFiAccessPointResp {
required string bssid = 1;
message Location {
required int64 latitude = 1; // * 10e-9
required int64 longitude = 2; // * 10e-9
optional int32 unknown3 = 3;
optional int32 unknown4 = 4;
optional int32 unknown5 = 5;
optional int32 unknown6 = 6;
optional int32 unknown7 = 7;
optional int32 unknown8 = 8;
optional int32 unknown9 = 9;
optional int32 unknown10 = 10;
optional int32 unknown11 = 11;
optional int32 unknown12 = 12;
}
optional Location location = 2;
optional int32 channel = 21;
}

message AppleToSmartphoneRequest {
optional int32 unknown1 = 1;
optional WiFiAccessPointResp ap = 2;
optional int32 unknown3 = 3;
optional int32 unknwon4 = 4;
}

message AppleToSmartphoneResponse {
repeated WiFiAccessPointResp ap = 2;
}

収集編での構造と同じかと思いきや微妙に違う………。lat/lng は float じゃなくて固定小数点に変わっているしタグもずれています。。これも 2013 年頃解析したものとは違います。

デコード結果は以下です。

ap {
bssid: "10:6f:3f:6:xx:xx"
location {
latitude: 3565078352
longitude: 13972113022
unknown3: 42
unknown4: 0
unknown5: 21
unknown6: 14
unknown11: 62
unknown12: 69
}
channel: 3
}

位置情報を取得するのに送信した周囲の BSSID の位置情報は、このようにして返ってきました。lat/lng 以外にも何かついてきているようです。

このケースでは、リクエスト時に BSSID を複数(12個)送信しています。レスポンスには、リクエスト時に送信した BSSID 以外にも周辺の BSSID と位置情報が100個ほど含まれていました。iOS, locationd がこのレスポンスから実際の位置情報をどのように計算しているかはわかりません。

BSSID から位置情報を取得したいならもっと簡単な方法がある

Apple のこれを使えば BSSID から位置情報を取得できる!と思うかもしれませんが、そんな面倒でグレーなことをしなくても、もっと簡単で正当な方法があります。

Google Maps Geolocation API で BSSID から位置情報を取得できます。
geolocation
ブラウザからも使われています。

プライバシーの問題

Wi-FiのMACアドレスはもはや住所と考えるしかない 高木浩光@自宅の日記 2011年11月26日

個人で設置している AP の MACアドレス(BSSID) から位置情報が引けるとなると、BSSID は住所に相当するのではないかという指摘があります。これに対し、Google Maps Geolocation API は「2つ以上のBSSIDが含まれないリクエストでは位置情報を取得できない」としています。

The request body’s wifiAccessPoints array must contain two or more WiFi access point objects. macAddress is required; all other fields are optional.

特定の BSSID から位置を調べようとした場合、その近隣の BSSID なんて事前に分からないので、位置情報が取得できません。これで多少は安全になります。一つの AP が複数の BSSID を吹いているなど、推測されやすい状況はありえますが。

結論

一般的に AP が設置されてもすぐに位置情報に反映されるわけではありませんが、カンファレンスやイベントなどで一時的に設置された AP でも、その情報がたくさんの来場者のスマホから送信されてしまい、それなりに確信度の高い位置情報として扱われてしまうのかもしれません。AP は複数台設置されるため、測位の場合でも優先されてしまうのかもしれません。

今回は Wi-Fi 測位のみを扱いましたが、その他 GPS(GNSS)や携帯電話基地局での測位とハイブリッドになっていることがほとんどであり、その挙動は多様です。大きく位置が狂うことが有り得るのは Wi-Fi 測位の特徴といえます。

他の測位手法については、他の機会に触れたいと思います。
それと Android も調べたかったのですが力尽きました。

IPv6, イベント, インフォメーション

みなさま、IPv6への接続はできてますか?

ユーザ環境は気付かないうちにIPv6化されていたりするのですが、サービス提供側でのIPv6対応はあまり進んでいません。
その現状を踏まえ、JPNIC様と共同で「サーバ管理者向け、IPv6対応対応セミナー」を開催させていただくことになりました。

↓↓開催案内文


サーバ管理者向け、IPv6対応セミナー in 恵比寿 開催のご案内

北米地域のレジストリであるARINにおけるIPv4アドレス在庫の枯渇や、またApple社でのiOS 9におけるIPv6対応必須化が報道され、IPv6についてのトピックスが増えてきています。
国内での、IPv6接続が容易にできる環境も整いつつあり、知らないうちに利用する環境がIPv6に対応していたということも身近になってきました。
こうした状況の中、コンテンツのIPv6化がなされていないと、ユーザーのところに思うように届けたい情報が届いていないことも起こってくるかもしれません。

そこで、DMM.com ラボとJPNICでは、誰もが気軽に参加できる「サーバ管理者向け、IPv6対応セミナー in 恵比寿」を企画しました。

IPv6の最新動向とともに、サーバのIPv6化に向けた基礎知識を解説します。
また話者は、JPNICにおける「IPv6教育専門家チーム」のメンバーが務めますが、そのメンバーを囲んで、ビアバッシュも開催し、IPv6についてフランクな意見交換会も実施する予定です。

ぜひ多くの方にご参加いただければ幸いです。皆さまのご参加をお待ちしております。

◇日 時:2016年2月16日(火) 16:30~20:00 (開場 16:00)
※19:00頃からはビアバッシュ形式の懇親会です(参加費無料)

◇会 場:株式会社 DMM.com ラボ 本社 会議室
(東京都渋谷区恵比寿4-20-3 恵比寿ガーデンプレイスタワー21F)
http://labo.dmm.com/about/access/

◇主 催:株式会社 DMM.com ラボ
<http://labo.dmm.com/>
一般社団法人 日本ネットワークインフォメーションセンター(JPNIC)
<https://www.nic.ad.jp/>

◇プログラム(予定)

16:30-17:15(45分) IPv6を取り巻く最新動向
話者:株式会社インテック 廣海緑里

17:15-18:45(90分) サーバのIPv6化入門
話者:株式会社ブロードバンドタワー 許先明、國武功一

18:45-19:00(15分) DMMのIPv6に関する取り組み
話者:株式会社 DMM.com ラボ 佐々木健

19:00-20:00(60分) ビアバッシュ懇親会 ~IPv6の小話をしよう~

◇対象者:IPv6に興味のある方・対応を考えたいサーバ管理者など

◇参加費:無料

◇当日の持ち物:名刺2枚と筆記用具

◇定員:70名

◇U R L:https://www.nic.ad.jp/ja/topics/2016/20160126-01.html

◇参加申し込み:tech-seminar[at]nic.ad.jp 宛に以下の情報を、2月15日18時ま
でにお送りください。ただし定員になり次第、締め切ります。

Subjectは、「2月16日 IPv6セミナー申し込み」としてください。

– お名前:
– ご所属先:
– 業種と職種:
– メールアドレス:

◇その他: 当日、会場ではWiFiをご利用いただけます

◇お問い合わせ先:IPv6対応セミナー 事務局 <JPNIC内>
Mail: tech-seminar[at]nic.ad.jp
Tel: 03-5297-2311(月~金、10:00-18:00)

PAGE TOP