#えむけーろぐ

間違った事を書いていたらやさしく教えてください

#本当にひどい実験 実施報告書

※この記事は苫小牧高専アドベントカレンダー2018 1日目の記事です。

f:id:mktakuyax:20181001122518j:plain

ロットネストアイランドの海。記事とは全く関係ない。

はじめに

今回は、情報科学・工学系第3学年で行われた #本当にひどい実験 の実施報告を書いていく。思ったより長くなったので、興味がない人は最後の「#本当にひどい実験 クソツイグランプリ2018」だけ読んでもらえればと思う。

#本当にひどい実験 とは

#本当にひどい実験 とは、Twitterのハッシュタグである。苫小牧高専 創造工学科 情報科学・工学系3年の情報科学・工学実験Ⅱにおいて、後期6週分の日程で行われた「セキュリティ」というテーマの実験のハッシュタグとして使用された。

twitter.com

最初は僕やツイ廃の3年生達が悪ノリでハッシュタグをつけてツイートしていただけなのだが、2週目には実験を行っていた教室(a.k.a.ダンス部部室)のホワイトボードに「#本当にひどい実験」と書かれていたので、公式(?)なのかもしれない。*1

優秀な学生はこちらの意図に気づき、ハッシュタグを用いて実験や教材に関するフィードバックを書き込んでくれていた。頂いた意見をもとに来年度以降、同じ研究室の後輩である専攻科1年のてっぴーくんや未来の土居研の学生がなんとかしてくれるはずだ。

実験の目的と内容

今回の実験の目的は、IoTセキュリティに関する基礎知識を習得することである。そんな感じのことを実験指導書に書いた気がする。

実験では、僕の専攻科特別研究のテーマ「IoTセキュリティに関する教材の研究開発」のもと開発している、「IoTセキュリティに関する教材」を使用した。この教材は、IoTカーと実験指導書、スライドや補助用の資料から構成される。

IoTカーとは、Raspberry Piを搭載したラジコンカー的なモノである。このIoTカーには、操作用のWebアプリケーションが搭載されている。前進・後退、右左折といったラジコンカーとしての基本機能から、IoTカー搭載のWebカメラを利用した写真撮影機能、撮影した画像の管理機能(ユーザ名・パスワードによる認証付き)といった機能を持つ。

ちなみに僕が開発したのはIoTカーに搭載されているソフトウェアや指導書等の教材であって、ハードウェアそのものは某社から買ったものだ。某社の人曰く、「オモチャを作って各高専に配ったらmkくんの卒研になっていた。」とのこと。

f:id:mktakuyax:20171126220738j:plain

IoTカーの外観。前後左右に走行可能な筐体に、Raspberry Piとモータドライバ回路等が搭載されている。

このIoTカーには、プログラムの不具合や設計ミス、設定の不備などが原因となって発生したセキュリティ上の欠陥、つまり脆弱性が埋め込まれている。これらの脆弱性を発見・修正することによって、攻撃者の立場からIoTセキュリティについて学ぶことができるというのが、この教材のアピールポイントだ。今回の実験は、その初運用も兼ねていた。実験の担当教員はshigyo先生で、僕はTAとして実験のお手伝いをしつつ、教材の評価を行っていた。

実施結果

今年度の実験は、10月11日(木)から11月15日(木)まで、毎週木曜日午後に以下のような日程で行われた。2週間を1つの区切りとして、3つの小テーマに分け、実験レポートも、2週間に1通の提出とした。なお、実験は2人1組で行った。

1〜2週 Raspberry Piのセットアップと動作確認、PythonによるIoTカーの制御

最初の2週間では、Raspberry Piそのもののセットアップと動作確認を行った。作業内容としては以下の通りだ。

  • 配布したmicroSDカードへのOSイメージの書込み
  • SSH接続の設定
  • 基本的なUNIXコマンドの確認
  • PythonによるIoTカーの制御(モータの制御、カメラの制御など)

OSイメージのダウンロードがめちゃくちゃ遅くて大変だった。教室に設置された1つのルータで20台以上のPCを捌くんだから、そりゃそうだ。また、SDカードへの書込みも、展開前のzipファイルをそのまま書き込む人がいたりした。

また、PythonによるIoTカーの制御も、班によって達成度にかなり差があった。

3〜4週 PythonによるWebプログラミング、操作用アプリケーションの設置と設定、動作確認

次の2週間では、Webで動作するIoTカー制御プログラムを買いたり、操作用Webアプリケーションのセットアップと動作確認を行った。

  • Apacheのインストール
  • サンプル用HTMLの作成と確認
  • 1〜2週目で書いたIoTカーの制御プログラムをWebアプリとして移植する作業
  • Webアプリケーションの設置、動作確認

こちらは、1〜2週目で感覚を掴んでくれたのか、躓く学生は少なかったように感じた。ただし、GPIOやカメラを扱うためのRPi特有の設定や、ドキュメントルートに配置するファイルのパーミッションとか、UNIXの扱い方的なところでハテナマークを浮かべる学生がいたのもまた事実だ。

5〜6週 脆弱性の発見と修正

最後の2週間では、脆弱性の発見と修正を行った。最後の2週間にして、やっとセキュリティっぽい話が始まった。

  • セキュリティに関する簡単な講義
  • Webアプリケーションに埋め込まれた脆弱性の発見
  • IoTカーそのものの脆弱性の発見
  • 脆弱性の原因の調査と修正方法の提案
  • 可能であれば、脆弱性の修正

まず最初に、セキュリティに関する簡単な講義を行った。スライド資料は僕が用意し、講義はshigyo先生がしてくれた。スライドには、これまで扱った要素技術とIoTカーそのものについての説明に加えて、これまでに起きたセキュリティに関する有名な事件とその原因、対処方法についての説明、課題のヒントの説明を行った。

課題は、IoTカーに埋め込まれた脆弱性を発見し、原因の調査と修正方法の提案を行うというものだった。前述したスライドを配布し、課題の文章にもキーワードを散りばめておいたので、だいたい自力で発見をしてくれていたようであったし、そうでない学生も段階を追ってヒントを与えていくとなんとか答えを見つけてくれているようだった。

所感

IoTセキュリティといいつつも……

IoTセキュリティに関する教材といいつつも、埋め込まれた脆弱性はWeb寄りなものが多かった。ハードウェア的な脆弱性もあるにはあるのだが、正直言って物足りなかったと思う。実験後に実施したアンケートにも、「IoTカーである必要がよくわからない」と書いていたが、全くそのとおりだ。

せっかく自動車の形をしているのだから、自動車に関するセキュリティの事例をもっと研究して、教材にもその要素を盛り込むべきだった。RPi 3にはBluetoothモジュールが載っているので、そのあたりを使ってみても良いのかもしれない。まぁ、ハードウェアの要素を入れると実験の難易度はだいぶ跳ね上がると思うけど、そこはどうにでもなる。

学生にとってはじめての事が多すぎる

今回対象となった3年生が持っている授業や実験で得た知識は、せいぜいUNIXコマンドの基礎とC言語の基礎くらいだ。一方、今回の実験で扱ったような要素技術を列挙してみると、こんな感じだ。

  • Linuxサーバの構築
  • ApacheによるWebサーバの構築
  • HTMLによる簡単なWebページの作成
  • Pythonによるプログラミング
  • PythonによるGPIOやWebカメラの制御
  • リレーショナルデータベースとSQL
  • Webアプリケーションにありがちな脆弱性

正直、これだけの要素技術を初めて扱うものとして6週間の実験に詰め込むのは無理があると思う。課題やレポートでは、これらについて理解していなくても、「さらっとでも触れて、こういうものがあるんだと知ってくれれば良いよ〜」くらいの難易度にしたつもりではある(実際、コードを書くような課題はほとんどサンプルコードのコピペで済んでしまう)が、それでもこんなに新しい事が次々と出てこられては、戸惑う学生も多かっただろう。

この実験は授業や実験でコードを書く経験を積み、RDBやHTML等の要素技術についてもサラッと習った4年生や5年生になってからやったほうがいろいろ楽しめて良いかなとも思う。とはいえ、まぁなにか新しい事をするとなったらやっぱり学科再編後の人達向けになるだろうし、4年生からはコースが分かれてしまうので、タイミングとしては3年後期のこのタイミングしか無かったのではないかと予想している。(もちろん、カリキュラムを決める権限は僕にはないので憶測でしかない。)

とりあえず一通り体験してもらえたし、何よりみんなでワイワイやるのは楽しい

セキュリティに関する実験とはいえ、セキュリティ以前にまず普通にモノを作ったり、環境を作ったりした事が無い人たちがほとんどだろうから、この実験の前半はそういう経験を積んでもらうことに重点をおいた。

これまでの授業だと、教員や技術職員さんが用意してくれた環境の上で課題のプログラムだけ書くという体験しかしてこなかったはずなので、ゼロから体験してもらおうという意図だ。たぶんわかってる人は勝手に進んでいったし、わからない人は、実験書に書いてあるコマンドをよくわからないまま書き写して、それっぽい結果が返ってきたら次へ進むという感じだったと思う。

今回扱った要素技術については、これから進級して授業や実験で扱ったり、資格試験の勉強で体系的に学ぶことが出来ると思う。また、今回の実験をきっかけにRPi買うなりVPS借りるなりして趣味や自学として触れることもあるだろう。その時に、今回手を動かしてそれぞれの技術に触れたという経験が生きてくると良いなと思っている。

肝心のセキュリティに関しては、「こうするとこうなる」とか、「こういう脆弱性がある」くらいは体験してもらえたと思うので、今回ですべてを理解していなかったとしても、今後なにか自分で作る時に思い出すきっかけになれば良いんじゃないかなと思っている。

そして何より、3年生の皆さんと一緒に実験するのがとても楽しかった。僕が気づきもしなかったような事に気づいてフィードバックをくれたり、実験の進行を助けてくれたりして、とても助かった。3年生の皆さんは学科再編後の第1期生ということで、こういう事には慣れているというか、もう飽き飽きしているかもしれない。しかし、今後もこういう事は続いていくと思うので、引き続き活躍(?)してほしい。

今後

第1回目の運用は終了したので、僕はこれからこの結果を卒業論文にまとめるつもりだ。また、皆さんから頂いたフィードバックを元に、てっぴーくんが来年度以降の実施に向けて教材の改善を行ってくれるはずだ。

そのへんの話は、おととい公開した樽前FM EP17でてっぴーくんとお話させて頂いたので、そちらも合わせてどうぞ。

tarumaefm.com

#本当にひどい実験 クソツイグランプリ2018

もう長い文章をダラダラと書くのは疲れたので、 #本当にひどい実験 というハッシュタグ付きのツイートの中でも、特に僕がおもしろいと思ったものを3つ紹介して、この記事を終わりたいと思う。

おわりに

以上で、#本当にひどい実験 実施報告書は終了とする。

この教材の開発について電気学会の全国大会で発表したところ、優秀ポスター賞をもらうことができた*2。さらに、この実験の実施報告(マジメなやつ)を書いた論文の査読が通れば、査読付き論文デビューだ。これから研究者としてのキャリアを進んでいくつもりは特に無いのだけれど、それでも「専攻科2年間、ただ遊んでただけでは無いんだぞ!」と言える程度には業績を残すことが出来たっぽいので、それはそれで満足かなと思う。

担当教員のshigyo先生、その他アドバイスをしてくださった情報工学科の先生方、そして何よりも、実験を受けつつフィードバックをくれた情報系3年の皆さん、本当にありがとうございました。

明日は #本当にひどい実験 の本当の首謀者である @shigyo先生の担当です。

*1: "本当にひどい○○" の元ネタはたにったさんとない子さんがやっていた飲み会のハッシュタグ #本当にひどい飲み会 である。

*2:優秀ポスター賞 受賞者 | 電気学会 電子・情報・システム部門

苫小牧高専 Advent Calendar 2018をやります

🎉苫小牧高専 Advent Calendar 2018をやります 🎉

adventar.org

2016年、2017年に続き、今年もやります🎉

記事のテーマはなんでもOKなので、苫小牧高専の学生、教職員、OBOG、その他関係者みんな書いてください!!!

アドベントカレンダーって何?

今回利用するAdventarというWebサービスのTOPページに説明が書いてあるので引用します。

Advent Calendarは本来、12月1日から24日までクリスマスを待つまでに1日に1つ、穴が空けられるようになっているカレンダーです。WebでのAdvent Calendarは、その風習に習い、12月1日から25日まで1日に1つ、みんなで記事を投稿していくというイベントです。

Adventar

テーマは技術系にかぎらず、日常生活や料理、ネタアドベントカレンダーなど、毎年いろいろなテーマのアドベントカレンダーがあって楽しいですね。

これまでの苫小牧高専アドベントカレンダーはこんな感じでした。現役生、卒業生、教員、その他特に苫小牧高専に関係の無い人まで、幅広い投稿者がいます。

参加方法

上にも書いたとおり、今回もAdventarというWebサービスを利用しています。

苫小牧高専 Advent Calendar 2018 - Adventarにアクセスし、ログインまたはユーザ登録(TwitterやFacebook、GitHub、GoogleアカウントがあればOK!)を済ませたあと、希望の日付の登録ボタンをクリックして登録してください。早いもの順です。

担当の日付になったらブログを更新し、またAdventarにアクセスして記事のURLを登録してください。(忘れずに!!)前々から下書きとして書いておいて、担当日になったら公開するというのがオススメのやり方です。

僕は初日になんか書きます。

!!!みなさんの楽しい記事お待ちしております!!!

これまでに作ったものをまとめてみた

タイトルの通り。新しいドメインを取ったことだし、せっかくなのでWebサイトを作り直し、そのついでに今まで作ったものをまとめてみた。

Works - m6a.jp

裏ではJekyllを使っているので、なにか作る度に新しくページを追加すればOKなのがポイント。

f:id:mktakuyax:20181029232241p:plain

 

こうせんせいかつ最後の高専祭

高専祭については、去年から専攻科生としての参加なので、学科展も無ければ、クラスの屋台・喫茶も無い。さらに、去年少しだけ手伝ったソフテクのプログラミング体験教室的なやつも、今年は3年生の2人中心に1年生を巻き込みながら自立してやっていけたみたいなので、完全に何もしない人としての参加になる。マインクラフトで例えると、緑の村人だ。

数年前までは、情報出身の専攻科生は情報の学科展を手伝うみたいな風潮があったみたいだけど、僕の1個か2個上の代で消えた気がする。というか、4個上の人達周辺だけの特異な現象だったのかもしれない。

まぁそんなわけで、高専生として参加する最後の高専祭が終わったわけだが、結構楽しかったと思う。他学科の人たちがステージ上でひたすら盛り上がるあの特有のノリは相変わらず苦手だけど、そういうのを遠くから見て一緒に楽しむ心の余裕も生まれてきた。内輪ノリに関しては毎年のように叩かれているけど、逆に体育館にいる全員に通ずるような話をしつつ盛り上げもするというのはかなり難しいことなので、あれはあのままでも良いと思う。

f:id:mktakuyax:20181021095543j:plain

知らない後輩に連れ去られて食べたパンケーキ。美味しかった。

どうやら高専祭は、OB/OGが帰省して教員室参拝をしたり、プチ同窓会が発生したりするキッカケとしても機能しているようなので、来年以降はそういう目的での参加になると思う。

さいげん できません

プログラマの端くれとして、ソフトウェアのインストールだったり、開発だったり、そういった物事が滞りなく進むのは良いことだ。良いことなのだけど、他の誰かの環境や、ある状況下でうまくいかなかったときは、原因を探るために、そのうまくいかない状況を作り出す必要がある。そういうのを、再現するとか、再現性があるとかないとかいう。「あの手順を踏むと再現するね」とか、「僕の環境だと再現しないね」みたいな会話をしたりする。

そういう、なにかうまくいかないことの原因を調査するために、同じような状況を作り出して再現するかどうか確かめているのに、どうも再現出来ない、ということがここ最近多い。

ひとつは、僕の専攻科の特別研究に関することで、もうひとつは内定先での開発アルバイトに関することだ。どちらも、だいたいのアタリはついているのだけど、同じ状況を作って再現しようとすると再現しない。後者の方は、若干答えを掴めそうな感じがあるし、最悪無視すればなんとかなるレベルの話なのでどうでもいいのだけど、前者に関してはさっぱりだ。実験室と同じ環境を研究室に作ってみても、なんと再現しない。それに、人によってうまくいったりいかなかったりするとか、何回か試してみるとうまくいくとか、逆にさっきはうまくいったのに今度はうまくいかないとか、そういう感じだ。

もう仕方がないので、回避策を用意することにする。一応、そこは本質では無いっちゃ無いし。

ところで、こういうトラブルシューティング的なことをやるときに、その人の実力を垣間見ることができるのだなぁといつも思う。後輩がRailsで作ったものがうまく動かない、みたいな時は、いろいろヒアリングしつつ、原因を探って解決するという事ができるけど、それは僕がRailsだけやってるわけじゃなくて、Rubyそのものとか、HTTPとかSQLとか、あとはActive Recrodそのものとか、Railsというデカいものを構成する下位の概念についてそれなりに(少なくとも彼ら彼女らよりは)知っているし、それなりに経験も積んできているから出来ることだ。

今回はもっと低いレイヤの話で、ネットワークとか、Linux、パッケージマネージャがどうこうとか、とかそういう話だ。正直そういうのはめんどくさいので僕はHerokuみたいなものが大好きだし、ちょっとインフラ自分で頑張ってみるかってなっても、自前マシンにDebianをインストールして、適当に設定をしつつ、コミュニティがお膳立てしてくれた公式のDockerイメージを適当に構成して立ち上げるくらい。

結局、普段からそういったモノとよく触れ合っている後輩が緩和策を提案してくれて、そのとおりにやるとなんとなくうまくいった感じがする。それでもまだダメな人や、「さっきはうまくいったのに今度はうまくいかない……。」みたいな事が起きているので、ちょっとどうしようという感じなのだけど。正直ここに時間をあまり使いたくないので、次回以降は回避策を試す感じで考えている。

言い訳として、今回は学校の異常なネットワークのせいで二重ルータを強制されていること、それが無かったら驚くほどちゃんと動いてくれるというのがあるのだが、それでも今回は僕の実力不足、知識不足感が否めないなぁ、と思ったのであった。

CloudflareのPage Rulesを利用して古いブログから新しいブログへフォワーディングする

はじめに

ブログを新しいドメインに変更したのだけど、Googleの検索結果やTwitterには前のドメインのものがリンクされているので、フォワーディングをしたい。具体的には、以下の2点を実現したいということだ。

ぼくはName ServerとしてCloudflareを使っているので、Page Rulesという機能をうまく使えばこのフォワーディングを実現することが出来る。

1.適当なレコードを作成する

Cloudflareのダッシュボードにログインし、旧ドメイン(僕の場合は mktakuya.net )の設定画面へ移動する。

画面上部のタブからDNSを選択し、以下の通りレコードを作成する。

  • 種別: CNAME
  • Name: blog (旧サブドメイン、 blog.mktakuya.net なら blog)
  • Domain Name: blog.m6a.jp (新ドメイン、FQDNを入力すること)
  • TTL: Automatic TTL(なんでも良さそう)
  • Status(雲のマーク): 有効(オレンジ色になっていればOK)

ポイントは、Nameに旧サブドメインが指定されていることと、雲のマークがオレンジ色になっていることだ。それによって、DNSの向き先がCloudflareのサーバになるので、後述するPage Rulesを利用できるようになる。

f:id:mktakuyax:20181017121927p:plain

2.Page Rulesを作成する

Cloudflareのダッシュボード上部のPage Rulesを選択し、Create Page Ruleボタンを押して以下の通りPage Ruleを作成する。

  • If the URL matches: blog.mktakuya.net/*
  • Then the settings are: Forwarding URL
    Status Code: 301(どっちでもいいと思うけど気にする人はこの辺参照)
    destination URL: blog.m6a.jp/$1

こうすることで、 blog.mktakuya.net へのアクセスは当然 blog.m6a.jp にフォワーディングされるし、 https://blog.mktakuya.net/entry/2018/10/09/230943 へのアクセスも、 https://blog.m6a.jp/entry/2018/10/09/230943 へとフォワーディングされる。

f:id:mktakuyax:20181017124442p:plain

3.待つ

待つ。すぐに反映されることもあれば、1日待たされることもある。 

4.確認する

試しに古い方にアクセスしてみたりして、フォワーディングが行われることを確認する。

おわりに

こんな感じでフォワーディングを設定すると、旧ドメインからアクセスした人を新ドメインの方に誘導することが出来る。

注意事項としては、どうやらFeedlyはfeedのURLをフォワーディング等によって変更しても追従してくれないということがある。対策としては、URLのmatchを /* ではなく /entry/ とかにしておいて、別途古い方のドメインでフィードを吐き続けるなり、「移転しました」的なフィードを表示しておくことなどが考えられる。