ISUCON9のために作成していたデプロイツールが完成しなかったため代わりに前日の数時間で作ったデプロイツールのユーザービリティが壊滅していた。

ISUCON9お疲れ様でした。megumishです。

チームmeguryohikaで@hiklaiumさんと@ryotoさんと参加し0点(megumishが最後にFailedした。最高得点は5310とかだった気がする))を獲得しました。

僕は主にデプロイツールのお世話をして、デプロイが出来るような環境を準備していました。ただし、ユーザービリティが悪く、デプロイの準備をするのに時間を取られてしまいました。

本当にただそれだけで得点に関わるようなことはできなかった(本当に申し訳ない……)ので以下はISUCON参加記というより、Rust製デプロイツールIzaと急ごしらえで作成したデプロイツールSaaの紹介(反省文)になります。

なので以下は与太話で、ISUCONに関する話はしません。

ちなみにIzaとSaaの名前の由来は

「いざ、デプロイ」

「さぁ、デプロイ」

になります。

完成しなかったデプロイツール「Iza」

IzaはRust製のデプロイツールです。Rustで書かれているのは僕が最も書き慣れている言語がRustだからです。

きっかけは、ISUCONの練習をしていた時に書いていたデプロイ用のshell-scriptをもっとちゃんと改良したらどうなるのか?と思ったことです。

他の製品の話を出してしまえば端的に言ってAnsibleのインタラクティブCLI版と同じポジションにいるツールになります。

これをISUCON9-qualまでになんとか完成させて使いたかったのですが完成しませんでした。

前日に急ごしらえ「Saa」

次にSaaというものがあり、これはPython製のデプロイツールです。ISUCON9予選の前日の数時間と当日の朝に作り上げました。

これはIzaと似たツールでコマンドラインで簡単にコマンドやサーバーに配置するファイルをデプロイパッケージという単位で作成できるというものです。

デプロイをする際はsaa deploy package1 package2のように指定するだけでとても簡単なのですが、問題はデプロイパッケージを作成するところにありました。

(以下saaを実行するときのコマンドをsaaコマンドと呼び、デプロイする時にサーバー上で実行するコマンドをリモートコマンドと呼ぶ)

問題点1 リモートコマンドやファイルを管理するIDがハッシュ値のため区別がつきにくい

例えば次のsaaコマンドはパッケージs1に指定したコマンドIDのリモートコマンドを追加するものです。

 ./saa.py package add command s1 4e0304bb8d6803e3933ae06abed9768ad981f0a50569c40773b1be2dc0e19dd9

これを見てもらうと分かるのですが、ぱっと見でなんのコマンドをパッケージに追加しているのか分かりません。

そのため以下のようにコマンドIDに別名をつけることでもっと見やすくすることが可能だったのかもしれません。

 ./saa.py package add command s1 systemctl-restart-isucari
# systemctl restart isucari.python.service をするコマンドを追加

問題点2 リモートコマンドやファイルにSSH接続情報が直接結びついていた

リモートコマンドは以下のようなjsonで表されるオブジェクトです。

    {
        "id": "6241074d168892ea79a527169d7081eb17cf11317bd620d4ad4d84ba88e15ff2",
        "ssh_id": "0bf974a00b59f58bd4dcc45154e3b35c8ff99da37f255fdc303f55dd74deb3df",
        "strings": [
            "systemctl",
            "restart",
            "isucari.python"
        ]
    }

リモートコマンドがssh_idなるものを持っています。ssh_idはサーバーに接続するためのユーザーとホストの情報が乗ったオブジェクトのIDでこれを各コマンドに結びつけていました。

そのせいで、単にパッケージの対象であるサーバーを変えたい時はいちいち別のリモートコマンドを作成する必要がありとても面倒でした。

正直、これが一番時間をとっていた原因だと思っています。

パッケージに接続情報を紐づけるか、もしくはリモートコマンドとSSH接続情報の組をパッケージに追加できるようにするのが解決策かなと思います。

問題点3 ツールには学習コストがある

これはチームメンバーに指摘されて気が付いたのですが、ツールは使うためにそれなりの学習コストがいります。

そのため、すぐに実戦投入するのはかなり危険な判断だったなぁと思いました。

なので本当は最低でも一週間前に作っておきチームメンバーに周知しておくのが正解だったかなと思います。ついでにドックフーディングもできるので上記のような問題を解決できるかもしれませんし。

咲き誇れデプロイツール「Iza」

最後にこれはただの宣伝なのですが、デプロイツール「Iza」の紹介をしておきます。

まだ未完成なので何とも言えないのですが、DDDとヘキサゴナルアーキテクチャを使い変更に強いライブラリを目指しています。

実態とは少しかけ離れているのですが、紹介スライドも貼っておきます。

speakerdeck.com

またレポジトリも公開しておきます。(本当はできた時点で公開すれば良いかなと思ったけど、ISUCON熱が冷めないうちに温めておくことで完成させる意志を育成します。)

github.com

デプロイがひと通りできるようになってバージョン0.2.0がリリースしたら下のツイッターでおしらせします。

twitter.com

では、いつかIzaが素晴らしいデプロイツールとして咲き誇らせることを心に誓いつつ今回の記事は終わりにします。あとどうせならISUCON本番までに完成させて、誰かに使ってもらえたら幸いだなぁと思っています。

ちなみにSaaが抱えていた問題はIzaではそもそも設計が違うためほとんどないはずです。ですが、早めに完成させてみて色々試したいものですね。

読了ありがとうございました。

ISUCONに関するおまけ

序盤で得た束の間の一位

サイバーセキュリティ問題を解決するための組織づくりを追求します

2019/03/21 よりサイバーセキュリティを無くす会「Exploit Crackers」を発足しました。

詳しくは下記より

akakou.hatenablog.com

なぜ組織づくりか

セキュリティの問題は安全性の問題であり、人と人との問題であると私は捉えています。

よってまずはセキュアな組織づくりのフレームワークを考えうることが最善の策なのではないかと考えています。

何をするか

とりあえず知識が足りないので組織づくりに関しての本を読んでいます。

また、組織を作ったとしても何をするのかという感じになってしまうので、コミュニティ支援やOSや言語などのプラットフォーム製作を主なプロダクトとして視野に入れています。

興味のある人へ

もし興味のある人がいたら、ぜひ Exploit Crackersに参加して欲しいです。

join.slack.com

上のリンクからslackに入れます。今日の報告としてはとりあえず以上です。よろしくお願いします。

ドドド・スタートアップにTwitter経由で採用されて3ヶ月経った感想

インターネットのいわゆるポエムというものは自分も他の人も大抵は負の感情駆動だと思うのですが

今回のポエムは残念ながら正の感情駆動ということを初めに注意として言っておきます。

ドドド・スタートアップに入社した

まだ会社設立から数年も経ってない新しい会社、いわゆるドドド・スタートアップに11月に入社しました。

きっかけはTwitterで以下のようなイキりツイートをかましていた時に声をかけていただいた次第です。

感想

(初めに注意として弊社と言う表現はあえて使っていません)

端的に言って僕が働く場所としては最高です。あくまで"僕が”働く場所としてです。たまたま僕が会社に合っていたということが大きいと思います。

なので以下はただただ会社を褒めるだけの記事になります。

“楽しい”がある明日を創る

まず、会社の理念は下記の通りらしいです。

https://www.handii.co.jp/philosophy/company-identity

正直に言ってしまうと初めにこれを見たときは険しい感情が芽生えました。

というのもこう言った大層な理念は大抵はすぐに形骸化してただのホームページに生えてるだけの文章になりがちだと思うからです。

まだ働いてから3ヶ月しか経ってない段階でいうのも少しはばかられますが、僕の視点から見るとこの理念は完全に体現されていると思います。

Missionについてはプロダクトがリリース出来てないので今の段階で言及するのは微妙なのですが

少なくともVisionValueは確実に現実になっているなぁという感じがします。

どのように楽しいの?

理念では楽しいというのが繰り返し強調されていますが、では具体的にどんな風に楽しいのかについて語ります。

以下の特徴をまとめて言うと、人に恵まれていると言うのが正しいと思います。

クソなことをクソと言える

めちゃくちゃ口汚い表現ですが、端的に言うとおかしいなと思ったことをその場で言えばそれに対して納得のいくように議論が進んでいきます。

お気持ちと論理を切り分けられる

議論をする時に感情的になることはよくあるものです。人間だからしょうがないです。

そこで議論する時に大切なのは良くも悪くもお気持ちと論理を切り分けられることです。

会社の人が言っていた言葉として、感情は議論の副産物と言うのがありました。副産物を副産物としてきちんと切り分けられる環境がここにあります。

本質的に「ちゃんとして」る

CTOがよく「ちゃんとして」と言います。これは外部に対してよく言ってる言葉です。

この会社は本質的にちゃんとしていると思います。もし、ちゃんとしていないことがあったとしてもすぐに誰かがそれはクソと言う発言をすることでちゃんとした方向に持っていきます。

開発陣だけでなく、コーポレート部や経営陣も例外ではなくちゃんとしています。

「つらくなってないか?」

基本的に楽しいですが、仕事なのでつらいときもあります。ですが、つらいときはそのつらさを軽減するために周りが動いてくれますし

もしつらさを発露できなかったとしてもCTOが「つらくなってないか?」とわりと頻繁に聞いてくれます。

これらのおかげでつらさは本質的に発生するつらさのみとなっていて、最低限のつらさで働くことができます。

なんかごきげんという社内レクがある

初めに社内レクをやるよと聞いたとき、悪い予感がしました。インターネットで語られる社内レクは散々なものです。

これは完全に個人の感想で、小学生でも言えるような感想ですが、楽しかったです。

社内レクは12月はパン作り、1月は書き初め、2月はDIYをやりました。

和気藹々と社内レクで普段やらないことをやるのは単純に楽しいです。

実は2月の社内レクは一日中寝ていたので参加できなかったのですが、Slackの様子を見ていて参加できなくてとても残念だと思うほどにこれまでの社内レクは楽しいものでした。

じゃあ何をやっとるの?

いわゆるイケイケFinTech(Financial + Technologyの略、別の言い方で表せば「新しめの金融」)企業です。

まだプロダクトがリリースしてないので何も言えないのですが、新しい金融を作るのが目標です。

僕はRustでサーバーサイドのエンジニアをやっています。

一緒に働きたい人へ

ここまで読んでくれた方には吉報です。

なんとこの会社では採用活動を行なっています。

急にリクルーティングの話になって最悪の気持ちになった人もいますでしょうが、もし興味のある方は

僕か

twitter.com

CEOか

twitter.com

CTOか

twitter.com

kotaroか

twitter.com

かばにゃすか

twitter.com

はまともまで

twitter.com

DMをお願いします。

Twitterアカウントがないよーと言う方は

採用についてのお問い合わせ

Contact

まで連絡してください。

べた褒めの記事でしたが、合う合わないの激しい会社だと思うのでそこは織り込んでお願いします。

CTFはどんなカテゴリがあるか?頻出カテゴリ1Web問編

こんにちはmegumishです。

最近、CTFに入門しようとしてる方に具体的にどういうカテゴリの問題があるのかと聞かれることがよくあります。

そこで、どうせならと一つの記事として情報をまとめておこうと思います。

そもそもCTFって?

CTFは Capture The Flagの略で、ここではサイバーセキュリティの競技を指します。

CTFは問題に提供された環境内のどこかにあるフラグを探す競技です。

要はセキュリティの知識を駆使して、宝探しをすると言うゲームになります。

(もしくは、脱出ゲームのようだと言った方が正しい場合もありますが)

だいたいのカテゴリの練習方法にてオンラインイベント型CTFに出ると書きましたが、じゃあどこでオンラインCTFを探せばいいのかと思う方もいるかと思いますが

ctftime.org

にほとんどのオンラインCTFの開催情報が載っています。

CTFで頻出されるカテゴリ

Web

Webページのセキュリティを突く問題です。

さて、セキュリティを突くと言うことはどう言うことでしょうか?

普段、私たちはTwitterGoogle検索などを使っていますが、そう言ったWebページを見るのにはHTTPリクエストを送る必要があります。

HTTPリクエストにはそのリクエストを受け取るサーバーが意図していなかった情報が付加されているとクラッシュしたり、意図していない動作をするケースがあります。

このような動作を使うことで、本来私たちが手に入れることができないはずだった情報を入手することができたりします。

こういったことをセキュリティを突く、あるいはExploit(エクスプロイト)と言ったりします。

先ほど「本来私たちが手に入れることができないはずだった情報を入手する」と言いました。こうやって手に入れられる情報のうち、指定されたフォーマットのもの(例えば NANTOKA_CTF{F1AG_D4Y0})みたいなものをフラグと言い、問題ページで提出することで競技上の得点を手に入れることができます。

使えるツール

  • Webブラウザー(firefox, google chromeなど) Webブラウザで色々なリクエストを送って見て観察して見るのがまず第一の問題を解く手法です。
  • Webブラウザーのインスペクターツール これは検証用ツールとも呼ばれるツールです。HTTPのレスポンスや通信している場所などを確認できます。
  • curl・httpie 少し難しいですが、CLIコマンドラインインターフェース)上のツールになります。

検証用ツールでも同様のことはできますが、好きな文字列をリクエスト上で簡単で再現することができます。

練習方法

  • オンラインイベント型CTFに出る 王道の練習方法です。Web問は基本的にサーバーのソースコードが公開されないため開催中しか試せないので、CTFに出て問題を解くのが確実な練習方法になります。
  • オンライン常設型CTFに出る これは ふるかわ さんが

nanuyokakinu.hatenablog.jp

にまとめてくれています。 - 本を読む

体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践

通称・徳丸本と呼ばれる本がWeb問を解く取っ掛かりとしても極めて行く方にも良いのかと思います。

疲れました。

唐突ですが疲れました。

他のカテゴリは後日書きます……。(が、自分は怠惰なのであまり期待しないでください。)

将来の夢:すべてを再構築し、それらすべての再構築を容易にする

f:id:megumish:20181221002602j:plain

こんにちは、megumishです。

僕には将来の夢があります。それは

すべてを再構築し、それらすべての再構築を容易にする

ことです。

Why

f:id:megumish:20181221004626j:plain

ではなぜ僕がそのようなことを思うのでしょうか順に追っていきましょう。

すべてを再構築したい理由

すべてを再構築したい理由は、現状のものがどのように出来ているかについて詳しく知りたいからです。

それだけなら書籍や文献を読めばいいと思うかもしれませんが

僕は理論から学ぶのがとても苦手で、何かを実際に試して見ないと実際にそれを知ることができないのです。

だからこそ、現在できているものでも再構築することで学ぶことができるのではないかと考えています。

すべての再構築を容易にしたい理由

僕は何かをちょっとでもいいから再構築したり実験したりして何かを得た時に

心動かされたことが何度もあります。

それは競技プログラミングでの解答コードだったり、Exploitコードだったり、Rustのライブラリのコードだったりします。

価値を生み出さねば役に立たないと言われる時代だからこそ

一見無価値に見える再構築の喜びを自分だけでなく他の人にも簡単に味わえるようになってほしいと言うのが

僕が未来へ託す願いです。

How・What

f:id:megumish:20181221010117j:plain

僕はコンピュータが好きです。

コンピュータ上で動くプログラムは僕がミスをした時にそれをすぐに教えてくれて

しかもその場で直したものを即座にもう一度試すことを厭いません。

理論が苦手な僕にとっても幾度もの体験を繰り返し起こして学ばせてくれる環境を与えてくれる

コンピュータはまさに僕が学習し得意になるのにうってつけの存在でした。

だから、僕がはじめに再構築したいと思っているものはコンピュータです。

コンピュータのことをもっと深く知って、もっともっと僕自身が楽しみたいと考えています。

最後に

自分が思うに結局、夢というのは自分のやりたいことを語ることに他なりません。

正直言って、僕は何かを再構築することで誰かの役に立ちたいとかはあまり思っていません。

ただ自分が思う素晴らしい何かを作ってみたいという思いだけです。

自分は昔から天邪鬼な人間でした。

生まれつきの心臓病を抱えていたけど、だからと言って医者にはなりたくありませんでした。

それは面白くなさそうだし、自分ならもっと大きなことをやってもっともっと人を救えると思ったからです。

もっと言えば、心臓病の人間を元気付けるなんてどうでもいいのです。

僕はすべての人が救われてほしいけどそれは途中で無理だって気づいて、そんで両極端に触れるのが大好きだから最大限自分を救おうとしています。

このブログを見ている人もきっとあなた自身を救えるそんなことになってほしいものですね。

ISUCON8本戦に行きました。

ISUCON8本戦行きました〜

行きました。うさぎさんとhikaliumさんがチームメンバーでした。 twitter.com twitter.com

こちらはhikaliumさんのブログです。 

hikalium.hatenablog.jp

うさぎさんのブログです。

kimiyuki.net

僕がやったこと

  • Dockerからアプリケーションを剥がす デプロイを慣れた形でするために、もともとDockerで動いてたアプリケーションを剥がしました。

手順としては

  1. Python3.7.0をxbuildでどこかに置いておく

  2. 置いたPython3.7.0のpipでpipenvをインストール

  3. pipenvで依存関係をインストール

  4. アプリケーションをsystemdに登録して動かす

という感じでした。

  • /sendの代わりに/send_bulkを使うようにする(失敗)

この実装をうさぎさんに任されたのですが

うさぎさんがバグを埋め込んでいたらしくそれを直すために手間取ってしまいました。

結果この実装は時間内に終わらずmasterにはマージされませんでした。

この実装には非同期処理でログをキューで貯めて送信するということをやっていたのですが

そもそも僕は非同期処理の実装がかなり苦手で、非同期処理に関する経験をもっと深めていかないといけないなぁという感じでした。

感想

体力の配分が間違っていたのと、やはりコーディングスキルが足りないのでもっと磨きたいと思いました。

11月から仕事を始めるのでそこで開発力をガンガン磨いて行きたいです。

Team:Harekazeに入ってからもうすぐ一年

これは

adventar.org

の2日目の記事です。

一日目はhiwwさんの

hiww.hatenablog.com

でした。

僕がTeam:Harekazeに入ってからもうすぐ一年が経ちます。

Harekazeに入ったきっかけはTwitterでチームを募集してたところをたまたまhiwwさんに声をかけてもらったところからだと思います。

Harekazeに入って初めてのCTFはSECCONCTF2016でしたが正直いってあまり貢献はできませんでした。

HarekazeはもともとSECCONCTF2016のために結成されたチームだったので、貢献できなかったのは残念でした。

しかし、幸運なことにHarekazeはこのあとも活動を続け、自分がチームに貢献できたと言えるような出来事もいくつかありました。

初期で言えば、Harekazeロゴの作成では一部協力していました。なかなかカッコ可愛いロゴになったかと思います。

Harekazeのロゴステッカーが欲しい方はお近くのHarekazeメンバーに言ってもらえれば在庫があれば渡せるかと思います。

最近ではPwnがそこそこできるようになってきたので、CTFでも貢献できるようになってきたのは嬉しいことです。

チームに入ってよかったなと思うのは、やはりチームの方々と交流できることと一緒に問題を解けることです。

自分が全くわからない問題でもチームメンバーの取り組み方をみて試行錯誤できるのはチーム戦の面白いところだと思います。

現在は自分が発足した企画もあるので、それに関してはちゃんと活動していきたいところですね。

さて、来週はいよいよSECCONCTF2017のオンライン予選があります。今年は去年よりも貢献して、欲を言えば国際予選に出れる順位を取れたらいいなと考えています。

ではHarekaze各位のみなさん、マイペースでいいのでこれからも頑張っていきましょう!