/var/log/study

つまり雑記

せっかくseccon2017の予選に出たからメモ書きを残しておく

writeupでは無く後に自分が見直すためのメモ

問題リスト

https://score-quals.seccon.jp/question/

自分が取り組んだやつ

回答できたやつ

  • Log search
    • NoSQL Injection って文字列が最終的に出てきたけど、何がInjectされたのかよくわかってない
    • *.txt で200のリクエストを返しているヤツを見つければ良いだけだと感じた
      • なので、問題が公開されてから結構経った時点で問題を解くのは不利なのでは？と思った
        • ログが増えた状態になって見つけるのが大変になりそう
      • たぶん自分が解けたのは見つけるタイミングが良かったから

回答できなかったやつ

  • Qubic Rube
    • 正6面体からQRコードを引っ張ってきてゴニョるやつ
    • 3つめのURLぐらいまでやって面倒で諦めた
    • 振り返ってみると ImageMagic とかで画像を切り貼りしたら良かったのかなぁ？と思うが、面倒だなって思うのでどっちにしろやらなかったと思う。
  • SqlSRF
    • writeupを見る限り union句を使ったSQL分でmenu.cgiを引き出すまでは良かった
    • その後総当りっぽい事をやっていて、発想はあったがチャレンジはしたくなかったし別の方法があるなぁと思った。
    • 総当りの後、wgetを使ってゴニョる必要があったところまでは辿り着かなかったものの、wgetでsmtpって出来るのかなぁ？と思っていた
      • writeupを見る限り通常の利用方法の範囲では無理そう
  • automatic_door
    • .htaccessを仕込んでphpを動作させ、任意のコマンドをOS上で実行するところまでは行けた
    • そのあと /flag_x をきちんと調査するのを怠がって変なコマンドを流したら、新規でファイルをアップロードできなくなってタイムアップ
      • ここらへんCTF慣れしていない弱さがでたと思った。

感想

webの問題を中心に解いてみた。というかそれ以外の問題は手をつける気にならなかった。

webの問題だけを練習しまくったりしたら、チーム戦とかで貢献できるようになるかもなぁって思った。

ISC DHCP から置き換わるであろう Kea の話し 前編

Kea DHCP

ISC DHCP から置き換わるであろう Kea の話し 前編

Kea DHCPにまつわる話を 前、中、後編という感じで書きます。

前編です。以下の記事は2017/12/10にwebにある情報を元に記述しています。

今回書く話し

ISC DHCPとKea, その問題点

wikipedia をさっくりと眺めると、Internet Systems Consortiumが開発している DHCP プロトコルのリファレンス実装とのことです。

で、そのISC DHCPに何の不満があるか？と言うと、主に開発面でISCの方々が厳しい思いをしているようで、以下のスライドの6ページ目にその厳しさが詰まっています。

www.slideshare.net

遅いとか、設定が複雑とかは、dhcpを利用する規模によって受け取り方が違うと思うので一概には言えないと個人的には思いますが、中の人たちがそのように言うのだから、そうなのでしょう。

そのような中でBIND10の中にDHCPを混ぜ込んで開発をスタートさせ、BIND10から離れてKeaというのがリリースされたのが2015年だそうです。(上記のスライドの7ページ目にそのように記載指定あります。)

現状のKeaにどのような機能があるのか？は後述しますが、このKeaがリリースされてすでにまる2年が経とうとしています。

そこで問題点として上げられるのが、ISC DHCP は何時までサポートが続くのか？ということです。参考となる一文は ISC の Software Support Policyに以下のように記述してあります。

The exact timeframe for EOL will depend on the maturity of Kea and other available options. We intend to create one more major branch, DHCP 4.4, and that will be the last major branch for ISC DHCP.

要はkeaの開発具合によってISC DHCPは終了したいと書いてあります。

つまり端的な問題点として上げられるのは近いうちに開発やサポートが終了する事が問題だと考えています。

この手のミドルウェアは、脆弱性がたまーに見つかって、パッチが出るのでバージョンアップする必要があると思うのですが、そんなときにISC DHCPは開発が終了していてパッチが当たったバージョンが無く困る状況を回避する必要があるはずです。

一応補足しておくと、似たような問題にpython2.7があると思うので、現実的にはISC DHCPがバンドルされたOSのEOLが訪れるまでは大丈夫ではないか？と思っていますが。

Kea の 情報源について

Keaは大体半年に1度のメジャーリリースをロードマップにしいています。なので、本ブログを2018年に見ても参考にならない可能性があるので、最初に一次の情報源をまとめておきます。

Keaについて

ISC DHCPとBIND10の苦難から生まれたKeaがどのようなDHCPなのか？という特徴は以下の4点が挙げられます。

  • 複数のコンポーネントから構成されている
  • JSON形式の設定ファイル
  • バックエンドが選択可能
  • プラグイン機構により、DHCPとしての動作の拡張が可能
  • 設定を変更するためのWebAPIサーバーが付属している

複数のコンポーネントから構成されている

Kea DHCPは以下のコンポーネントで構成されています。

  • Dhcp4
  • Dhcp6
  • DDNS
  • Control-Agent

上記で補足が必要なのは、Control-Agentくらいだと思いますが、それは後述するWebAPIのところで詳しく述べます。

JSON形式の設定ファイル

ISC DHCPの頃は、多分独自の設定ファイル記法でした。KeaではJSON記法を利用することが可能です。

各コンポーネント用の記述 + ロギングのための設定と言う形になっています。

バックエンドが選択可能

バックエンドは以下から選択が可能です。

RDBMSやNoSQLをバックエンドで使うつもりがなかったので特に検証等をしていないためどの様に動作するかは知りません。

プラグイン機構により、DHCPとしての動作の拡張が可能

C++もしくはC言語、もしくはそれらから呼び出せる言語ならプラグインが作成可能です。 (作る必要になったときに備えて、自分はgolangを使って上手いことC++を回避できないか検討していました。)

Kea内ではhookと呼ばれており、DHCPとしての挙動の様々なタイミングで処理を呼び出せる様になっています。

Hook用のデベロッパーズガイドがあるので詳しいことはそちらに任せます。

乱数を用いてIPを払い出すようなプラグインは、C++を勉強してビルドできるようになるまでを含めて大体半日もあれば出来るくらいなので、プラグインは偉大だなと思えます。

設定を変更するためのWebAPIサーバーが付属している

たぶんKeaの目玉の機能となると思います。 Kea v1.2.0からの機能で、Mozillaからのサポートを受けて開発された機能となります。 前述したControl-Agentがwebのapiの受け口を持っており、JSONを送信することで様々な操作が可能です。次の記事で動かし方等をフォローアップしていきます。

前編まとめ

ということで、前編はKeaの特徴を日本語で振り返る記事になりました。

中編ではKeaを実際に動かしてみます。

Dockerとiptablesの共存

Docker

タイトル通り

Docker自体がiptablesをゴリゴリと書き換えてくるので、どの様にiptablesを設定するか？という話。

で、iptablesを使いたいのはセキュリティのためだったりすると思うが、本記事を参考にしたからと言っても、何も責任は取れないことだけ明記しておく。

ネットでよく見る話し

ネット上ではDocker チェインを書き換えろ！

iptables -L -v の結果

  • DOCKER チェイン
  • DOCKER-ISOLATION チェイン
  • DOCKER-USER チェイン

上記の3つがある

冷静に考えて

自動的に書き換わるDOCKERチェインよりも、使ってくださいと言わんばかりの名前をしている DOCKER-USER チェインを書き換えてみたい。

ソースを追う

github.com

DOCKER-USER so the user is able to filter packet first.

と書いてある。

多少使ってみた結果。

たとえば、systemctl restart docker とか docker-compose up とか docker-compose down では、自分が追記したルールは削除されないことを確認している

dockerのロギングドライバでfluentdに設定を投げつける時にstdoutとstderrを分ける

Docker

タイトル通り。

3回設定して、3回悩んだから書いておく。

gist.github.com

TODO

  • fluent-gem install fluent-plugin-rewrite-tag-filter

上記の意図

  1. dockerからロギングドライバで送られてくるログをfluentdで受けられる
  2. tagにdockerが付いているログのsourceを見て、stdoutに出力されたものか、stderrに出力されたものなのか？で分類する
    • stdoutならstdoutをtagのprefixとして追加
    • stderrならstderrをtagのprefixとして追加
  3. stdoutがtagに着いてたら...
  4. stderrがtagについていたら...

stdoutとstderrを分けてたい思うんだけど、fluentd初心者な自分だと実現方法を探り当てるまでに時間が掛かった。

実現するための技術は以下のページだけだから凄くしょうもない話しだけど、逆引き的な意味合いで。

docs.fluentd.org

『千葉県南房総金谷のワークプレイス「まるも」』というところで開発合宿的なことをしてきた話(の開発以外の話し)

極々プライベートな話しなので、特に技術的な知見は無いです。

2017年10月28日~29日にかけて、千葉県南房総の金谷にあるワークプレイス「まるも」というところで開発合宿的なことをしてきました。

marumo.net

結論から書くと、結構良かったのでブログに書き残しておこうと思いました。

前提

万が一、google等の検索から流入してくる場合は前提がよくわからない可能性があるので、前提というか背景的なことを少し書きます。

自分自身は、Twitter上で やま(´･_･`)ぐち (@yaaamaaaguuu) | Twitter と言うアカウントで生きていて、いわゆるwebっぽいIT系の会社でお仕事をしてます。

そんな会社の同期や後輩、先輩方等々、縁のある方々と勉強会っぽいことをしていて、半年に1度くらいの頻度で集中してプログラムを書く合宿的なことをしています。

今回の「まるも」は、そんな方々とプログラムを書いたりする為に利用させていただきました。

諸々のデータ

見出し 値
出発地 新宿
参加人数 11人
実施したこと プログラミングとか
利用開始 2017/10/28 (土) 10:00~ くらい
利用終了 2017/10/29 (日) ~16:00 くらい
天候 雨 (というか台風)

まるもの立地

最寄りの駅は浜金谷という駅です。新宿駅から特急で2時間くらい、鈍行で3時間くらいっぽいです。

たしか朝の7:50くらいの特急電車にのって、最寄駅についたのが、9:40チョット前だったと記憶してます。

最寄駅からは歩いて5分くらいと近かったのが好印象。

まるもの内観とか

事前にブログを書くことは知っていたので、パノラマ画像をせっかく取ったのに、はてなブログにはアップロードできないことを今知りました (´･_･`)

なので普通の画像を掲載しますが、こんな感じです。

f:id:yaaamaaaguuu:20171105204622j:plain

4つの円卓といくつかのテーブルあったので、11人での作業スペースを利用すると、テーブルが1台、荷物置きとして使えるくらいの余裕がある感じでした。

また写真にもちらっと写っていますが、ホワイトボードと黒板がいい感じに作業の補助をしてくれました。

細かい話

IT系の開発合宿をするにあたって、最低限必要になるのが、wifiと電源タップですが、電源タップは持参していく必要が無いくらい充実していて、wifiも全く問題が無かったです。

当日は台風で、特に土曜の夜から日曜の朝にかけての雨量, 風量が凄く、「まるも」内も雨漏りをしていたのですが、特に作業に影響が出るほどではなく快適に作業できてました。

プロジェクターや、ディスプレイも2枚ほどあったのですが、今回は特に利用せず。

またきちんとリサーチしていけばよかったなぁということが、実は「まるも」にキッチンがついている！ということです。有料で利用できるとのことで、調べていたらみんなで料理して晩御飯が食べれたのになぁという気持ちでした。

周辺の話

f:id:yaaamaaaguuu:20171105212057j:plain

周辺に野良猫が住み着いている模様。とても人懐こい。(とまるもの方もおっしゃっていた。)

と、いう話はさておき、「まるも」の周辺にはいくつもごはん屋さんがあり、昼食には困りませんでした。ただ、閉店は結構早いらしく、22:00前後にご飯を食べようとした自分たちは若干困った挙句ガストに行きました。

11人で合宿をしていたとは書きましたが、実質は2~3人のチームに分けての作業をしていたため、お昼も別々。ということで自分たちが食べに行ったごはん屋さんだけ紹介します。どっちも一番最初のリンクに張ってあるごはん屋さんなんですけどね😇

https://tabelog.com/chiba/A1206/A120603/12026715/tabelog.com

初日の昼はピザのゴンゾーというお店。お店に釜があって、焼き立てでピザを出してくださる店でした。5~6ページに渡るピザのメニューでどれも美味しそうでした。

f:id:yaaamaaaguuu:20171105213414j:plain

tabelog.com

2日目の昼はさすけ食堂というところで、さすけ定食をいただきました。アジフライ+鯵の刺し身の定食でボリューミー。写真は撮り忘れ。

宿について

今回は 自転車のイベント が同時期に開催されていたため、LPには掲載されていない金谷ステーションという所を案内していただきました。

金谷ステーション公式WEBサイト | This is a 最高すぎる時間

素泊まりなので非常に安く利用でき、開発合宿の夜間に寝るだけなら必要十分という感じの宿でした。

風呂は男性の方しか事情がわからないのですが、1度に3人くらいずつ入れます。

まとめ

様々なことをざっくりとしか書いていませんが、集中して開発するための空間 + 新宿から離れた場所でご飯を食べると言う意味では非常に良いところだったと思っています。

開発合宿の参考になれば。

flaskのデフォルトのログを出力されないようにする

やりたいことはタイトルどおり。

注意

本記事ではデフォルトで出力されるログを握りつぶすことを主眼においている。

アプリケーションレイヤーできちんとログを出力すること。

動機

flaskのアプリケーションのロギングを自分で細かく設定したい手前、デフォルトで出力されるアクセスログをどの様に消したら良いかがイマイチ分かりづらかったから。

調査した結果としてわかったこと

flaskのデフォのログと書いているがタイトル詐欺で、flaskにデフォで設定されているログの設定はwerkzeug 側で設定されているもの。

つまり本記事を正確に言い表すならば、「werkzeugのデフォルトのログを出力させ無いようにする。」となる。

またwerkzeugが出力するデフォルトの形式を手軽に、程よく改造するのは面倒くさそうだった。

デフォだとApacheのログ形式で、アクセスログが設定されているのだけども、アプリケーション側のログをLTSVとかにし始めると、デフォルトで出力されるログも同じように...というのがお行儀が良いのだろうが、リクエスト自体はリバースプロキシサーバー側でもロギング出来るので一旦握りつぶす方針にした。

デフォルトのログ

深いことは考えずに、アプリケーションを書いて

from flask import Flask

app = Flask(__name__)

@app.route("/", methods=["GET"])
def root():
    return "hello world"


if __name__ == "__main__":
    app.run(debug=True, host="0.0.0.0", port=5000)

サクッと動かして

python app.py

別ターミナルで

curl loclahost:5000

とかすると出力される

172.17.0.1 - - [03/Nov/2017 14:55:23] "GET / HTTP/1.1" 200 -

このアクセスログを握りつぶしたい。

ドキュメントを読む

Logging — Flask Documentation (0.13-dev)

なるほど。

pythonのloggingの設定のrootに何も設定していないと、StreamHandlerが設定されるとのこと。

じゃあStreamHandlerをみると?

16.8. logging.handlers — ロギングハンドラ — Python 3.6.3 ドキュメント

なるほど。stdoutに設定されているとのことらしい。

順番はめちゃくちゃだけど、werkzeugのコードを探すと

以下がloggerを設定している箇所

github.com

以下でログを出力するためのヘルパーメソッドとなる。

github.com

なるほど。

WSGIRequestHandler 内にある, log_request などが、 logメソッドを呼び、それは最終的に werkzeug/_internal.py にある、_log メソッドを経由してgetattrでloggingの持つメソッドを文字列で指定しながら呼び出している形となる模様。

つまり

きちんと取り組むなら、以下のファイル内にある WSGIRquesutHandler の logメソッドなどなどを継承したオブジェクトを作って... とかが考えられる。

github.com

が、前述したとおり一旦握りつぶせるだけで良いので、 /dev/null を向き先にしたFileHandlerで全てのログを握りつぶす。

import logging 
from flask import Flask

l = logging.getLogger()
l.addHandler(logging.FileHandler("/dev/null"))
app = Flask(__name__)

@app.route("/", methods=["GET"])
def root():
    return "hello world"


if __name__ == "__main__":
    app.run(debug=True, host="0.0.0.0", port=5000)

上記を起動すると分かるが、flaskが出力する全てのデフォルトのログを握りつぶした状態となったはず。

webサーバー開発週報 第3週目

github.com

進捗

  • httpサーバーとしての新機能は無し
  • httpサーバーとしての機能修正も無し
  • 細々とした修正をした
    • virtual host を設定できるようにすることを見越して

今週の詰まりどころ

  • 進捗が少ないのでなし
  • グローバル変数的なものの扱いをどうするのか、未だによくわかってない
    • ググったらそれっぽいのは出てくるけど、試せてない

感想

  • 今週は新しい進展が無かった
    • 仕事の負荷が若干上がってきた
    • 仕事で使いたいコードを書いていた
  • 来週はもう少し時間を取りたい