/var/log/study

つまり雑記

EdgeRouter X がファクトリーリセットも効かなくなったのを直した話し

タイトルどおり。 現状は解決に至っていないので、問題の解決方法を知りたいだけならココを見るのは無駄である。

解決した。

yaaamaaaguuu.hatenablog.com

上記を書いてはや数ヶ月。EdgeRouterは息をしなくなった。当然自宅リージョンは全断の状態で非常に困っている。

いまネットを問題なく使えているのはwifiのアクセスポイントとして使っていたやつを急遽ルーターとして再活躍してもらっているからだ。

死んだルーターは以下のやつ。

Ubiquiti Networks Edgerouter ER-X(日本国内)

Ubiquiti Networks Edgerouter ER-X(日本国内)

先に諸々で現状困っていることを書き残す

  • ルーターがDiskfullで死んでいる
  • コンソール接続ができている
    • 一応ファクトリーリセットが効いている様
      • 既存のユーザーのパスワード等は効かない
    • ただし、リセットの一部の工程は上手くいっていない模様
      • 初期ユーザーのパスワードセットとか user: ubnt, password: ubnt とかが設定されてない
  • シングルモードユーザーでのログインを試みているが上手くいっていない
    • が、EdgeRouterの U-Boot でどうしたらLinuxのbootargsにsingleを渡せるのかが分からない
    • bootargsは一応書き換えられるが、書き換えた状態からU-BootのCLIからbootさせる方法がわかっていない
      • 分かった

作業ログてきなモノ

現状の整理

  • 最近なんか調子が悪かった
    • web UIがすぐ落ちたり
  • EdgeRouterにssh出来ない
    • そもそもpingが到達しない
    • 自宅のルーターだからと言って、気軽になんどかrebootした
  • 筐体のLEDは光っている
  • ファクトリーリセットを何度か実行しても状況が変わらない

思い返す

大丈夫だと思ってさらっと見逃したが、ディスクフルだったのでは?という気がしてきた。

対応策

  1. 2年間の保証があるとのことで対応してもらいたい
    • 代理店?が休業中っぽい 😇
  2. USBでコンソールに繋いでなんとかする
    • 仕方がないので今回はこっち

ER-XにUSBでコンソールにつなぐ

元ネタは以下。

community.ubnt.com

なるほど。USB-TTLで変換するのがあれば、ルーターにはシリアルポートが無いバージョンのやつだけどコンソール接続できそう。

amazonで似たようなやつを調達した。

現状の作業環境はOSX high sierraなので、ドライバの配布ページ からドライバをダウンロード, インストールして使えるようにして、結線は以下のようにした。

左から、接続なし, 緑, 白, 黒

このMacについて -> システムレポート -> USB でUSB-TTL が接続できているか?が確認でき、

f:id:yaaamaaaguuu:20171218013355p:plain

ターミナル上で、 /dev/tty.usbserial の有無でドライバが正しくインストールできているか?が確認できる。

でもって、minicomというやつを使えば、コンソール接続できるらしいのでおもむろに brew install minocom した。

接続は以下のコマンド

minicom -b 57600 -o -D /dev/tty.usbserial

f:id:yaaamaaaguuu:20171218013706p:plain

色々出ているが、 no space left というワードが決定的

でもって、bootの途中に、boot方法どうする?と聞かれるので 4 を押す。

そのあとに以下を叩いて現状確認

printenv
~~~
bootargs=console=ttyS1,57600n8 ubi.mtd=7 root=ubi0_0 rootfstype=ubifs rootsqimg=squashfs.img rootsqwdir=w rw
~~~

あとはbootargsにsingleを加えてシングルユーザーモードで起動するようにする

setenv bootargs=console=ttyS1,57600n8 ubi.mtd=7 root=ubi0_0 rootfstype=ubifs rootsqimg=squashfs.img rootsqwdir=w rw single
saveenv
boot bfd40000

bootコマンドの引数の理由は、特に何も指定しなかった時のbootのログから Booting image at bfd4000... とあったのでそれに従った。

Please choose the operation:
   1: Load system code to SDRAM via TFTP.
   2: Load system code then write to Flash via TFTP.
   3: Boot system code via Flash (default).
   4: Entr boot command line interface.
   7: Load Boot Loader code then write to Flash via Serial.
   9: Load Boot Loader code then write to Flash via TFTP.
default: 3
 0

3: System Boot system code via Flash.
## Booting image at bfd40000 ...
   Image Name:   Linux Kernel Image
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    1708328 Bytes =  1.6 MB
   Load Address: 80001000
   Entry Point:  803799d0
...........................   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

残作業として、 /root.dev が100%になっていることを確認したらフォーラムに以下の事が記載されていたので、それにしたがって古いファームウェアを消した。

community.ubnt.com

その後rebootしたらいつも通りのEdgeRouterが戻ってきたので、あとは頑張って設定を復旧するのみ 😇

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

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

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

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

前編, 中編の振り返り

  • ISC DHCPの開発が終わってサポートも終わろうとしているよ
  • 今後は Kea というDHCPを開発していくよ
  • Keaは色々便利機能とかがあるけど、特にWebAPIサーバーが生えていて便利!!!
  • 色々APIが生えているよ
  • ドキュメントの類いが充実しているよ

今回書くこと

  • 中編で取り扱わなかったAPIについての言及
  • 有料のhookの存在
  • 最近の開発動向

中編で取り扱わなかったAPIについての言及

中編では主に3つのAPIが生えていると言及しました。また主に設定変更等を含むサーバー操作系のAPIについて言及もしたので、本記事ではそれ以外のリース情報操作系と統計情報閲覧系について言及しようと思います。

  • 設定変更等を含むサーバー操作系
  • リース情報の操作系
  • サーバーが受け取ったパケットの統計情報の閲覧系

リース情報の操作系

http://kea.isc.org/docs/kea-guide.html#lease-cmds に記載があります。利用方法は、 設定ファイルで libdhcp_lease_cmds.so を読み込むだけなのですが、一点注意があり、 Control-Agent の設定には対象のhookを 記載してはいけない という事があります(Dhcp4やDhcp6にだけ記載するということ)。もし両方を読み込むと、リース操作系として使えるAPIは常に、no current lease manager is available というエラーのレスポンスを受け取ることとなります。一応、Control-AgentとDhcp4の両方でhookを読み込んだとしても、標準のAPIには影響が無いことを確認しています。

APIを上手く叩けず、試行錯誤していたらたまたま気づきました。コードを読んでもなぜそうなっているのか?は追えなかったのですが 内部のコンポーネントの一つの LeaseMgr を生成するためのここらへん の処理が不可解な状態になっているのではないかなぁ?と推測しています。

さて注意点を先に記載したのですが、上記APIで出来ることとしては、リースデータベースを操作することです。ここで思い出していただきたいのが、Kea のバックエンドには複数種類の方法を選ぶことが出来る点です。つまりこのAPIで本当に提供したいことはMySQLPostgreSQL, Cassandraを抽象化し、バックエンドにかかわらずリースの情報を操作するインターフェースを提供することとなります。

Note: not all backends support this command.

なんてこっそりと書いてありますが、どのバックエンドでも利用できそうな雰囲気をしています。コードは以下にリンクするので困ったら読めば良いと思います。

出来ることは以下となっています。

  • lease4-add
    • adds new IPv4 lease;
  • lease4-get
    • checks if an IPv4 lease with the specified parameters exists and returns it if it does;
  • lease4-del
    • attempts to delete an IPv4 lease with the specified parameters;
  • lease4-update
    • updates an IPv4 lease;
  • lease4-wipe
    • removes all leases from a specific IPv4 subnet;

個人的には、払い出したIPとmacaddressのリストが欲しいと思うので、lease4-get-all とかのコマンドが欲しいよね?と思ってます。

サーバーが受け取ったパケットの統計情報の閲覧系

http://kea.isc.org/docs/kea-guide.html#stats に記載がありますが、DHCPが受け取ったパケットの統計情報を見ることが出来るAPIが生えています。

利用の仕方は標準APIと同様、設定のjsonでhookは指定せず利用可能ですが、APIを叩く際はサービスを指定することだけ忘れないようにしてください。(Control-Agentに対して(サービスを指定しない状態)でlist-commandsとかをしても統計APIは見えない気がします。)

叩いてみた程度なので、使いみちについてはよくわかってませんが、運用する際は頭の片隅においておくのが良いと思います。

statistic-get-all を叩くと以下の様なレスポンスが返って来ます。たとえば、declined-addresses とかがやたら増えていたら、DHCPとして嬉しくないことが管理配下のサブネットで発生している!とかが分かるんですかね。

[
  {
    "arguments": {
      "declined-addresses": [
        [
          0,
          "2017-12-17 15:24:55.003177"
        ]
      ],
      "reclaimed-declined-addresses": [
        [
          0,
          "2017-12-17 15:24:55.003183"
        ]
      ],
      "reclaimed-leases": [
        [
          0,
          "2017-12-17 15:24:55.003188"
        ]
      ],
      "subnet[1].assigned-addresses": [
        [
          0,
          "2017-12-17 15:24:55.003195"
        ]
      ],
      "subnet[1].declined-addresses": [
        [
          0,
          "2017-12-17 15:24:55.003201"
        ]
      ],
      "subnet[1].reclaimed-declined-addresses": [
        [
          0,
          "2017-12-17 15:24:55.003208"
        ]
      ],
      "subnet[1].reclaimed-leases": [
        [
          0,
          "2017-12-17 15:24:55.003214"
        ]
      ],
      "subnet[1].total-addresses": [
        [
          224,
          "2017-12-17 15:24:55.003159"
        ]
      ]
    },
    "result": 0
  }
]

有料のhookについて

管理者向けのリファレンス に記載がありますが、いくつか有料のhook(plugin)が販売されています。エンタープライズな感じで使いたい会社に向けたライブラリを提供している印象です。

https://www.isc.org/product/kea-premium-hook-library-kea-1-3-package/ で購入することが可能で、$499だそうです。

  • legal_log: Forensic Logging Hooks
    • たぶん監査とか用のログを出力するライブラリ
  • host_cmds: Host Commands
    • staticにipを割り振るためのライブラリ
    • 標準のAPIでも出来ることは出来るのですが、効率よく処理を行うためのライブラリとなります。
  • flex_id: Flexible Identifiers for Host Reservations
    • こちらもstaticにipを割り振るためのライブラリ
    • 何を持ってipを割り振るか?を柔軟にするヤツっぽい

また Currently this library is only available to ISC customers with a support contract. という形で以下のライブラリも扱っているようです。

  • subnet_cmds: Subnet Commands
    • サブネットを操作するためのライブラリ
    • 標準のAPIでもサブネットを操作することは可能なのですが複数のサブネットを効率よく操作するものだと思います。

最後に開発最近の動向

では最後に少しだけ最近のKeaの開発動向についてを触れて終わりにしたいと思います。

半年ほど前に1.2.0, 先月くらいに1.3.0, 半年くらい先に1.4.0が予定されている状態です。

http://kea.isc.org/wiki/KeaReleaseNotes120 とか https://www.isc.org/blogs/kea-1-3-released-take-it-for-a-spin/ とか http://kea.isc.org/milestone/Kea1.4 が元ネタです。

  • 1.2.0
    • いくつかの DHCPオプションに対応した
    • Control-Agentが追加されてhttpなAPIが叩けるようになった
  • 1.3.0
    • lease_cmd.so が付属するようになった
      • 上記のhookを読み込むとhttpなAPIでリースを操作可能となった
    • Control-Agentをhttpsで叩ける様になったとのこと
  • 1.4.0
    • High Availability と呼ばれる機能が開発中
    • Radius と呼ばれる認証認可のプロトコルに対応しようと考えている
    • 実はCassandraの対応が実験的機能なので、改善しようと考えている
    • Migration Assistantを作ろと考えている
      • ただし、Keaの機能ではなくWebサービスで実装しようと思っている

前後のバージョンの状態を見るに、KeaのDHCPとしての改善は若干落ち着いてきており、より運用を楽にするための改善、ISCとのコンパチビリティとマイグレーションをどの様にしていくか?に主眼が置かれつつあるのかな?という気がします。

まとめ

Kea DHCPに纏わる話を 、後編という感じで書きました。

クラウドの台頭により、需要が減っているプロトコルミドルウェアなのかもしれませんが、今後DHCPを新規で立てる際は、残り何年もないISC DHCPより、Keaを選択する人がこの記事によって増えたらと思います。

また前中後に分割しても書ききれなかった知見や、Keaをプロダクションに持っていくためのスクリプトを書いていたりするのがあるので、それはそれで、また機会があれば纏めて書き残したり公開したりしたいと思っていますので、今後共よろしくお願いいたします。

Caskがmelpaにつながらないと言っている時のワークアラウンド

普段emacsのパッケージ管理には cask ってやつを使っている。macbrewの caskでは無く、emacsのcaskだ。

で、久々にemacsのパッケージをインストールしようと思ったら以下のエラーが出た。

cask install
Contacting host: melpa.org:443
Failed to download ‘melpa’ archive.
Contacting host: elpa.gnu.org:443
Package refresh done
Failed to download ‘gnu’ archive.
Setting ‘package-selected-packages’ temporarily since "emacs -q" would overwrite customizations
Setting ‘package-selected-packages’ temporarily since "emacs -q" would overwrite customizations
Package ‘s-’ is unavailable

原因

今回、自分で起きた問題の原因はmelpaにつなぎに行くときのSSL証明書がいつぞやから変わった模様

解決方法

emacs -q で起動する -> M-x package-refresh-contents 的なやつを実行すると無事解決が出来た。

惜しい解決方法

以下のcommitを真似してhttpsにしても、うまくいかない。(どこかのcommit番号では意味があったのかもしれないが、今は有効的な手段では無さそう。)

github.com

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

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

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

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

またこの記事は 富士通クラウドテクノロジーズ Advent Calendar 2017 の11日目です。

昨日は @alice02 さんの 「サーバ脆弱性スキャンの定期実行・結果通知を自動化してみた」 でした。

この世に存在しているサーバは常に悪意のある攻撃者からの攻撃対象になっています。

と言う一文が、脆弱性対策の重要性をよく表していると思いますので、まだチェックしていない方は是非チェックしてみてください。

前置き

新卒入社2年目の @yaaamaaaguuu です。PHP, Python, Golang を NGINX Unit で動かしてみた - /var/log/study とかを書いた人です。

2017年12月11日現在、富士通クラウドテクノロジーズ(FJCT) で、二フクラのためのソフトウェアエンジニアをやっています。去年のAdventCalenderでは 「レガシーなPHPを改善する為に(新入社員が勝手に)取り組んだ3つの事」という記事を書くくらいはWeb寄りのエンジニアでしたが、部署配属によりインフラに近いエンジニアとなりました。大まかな担務としては物理を含まないネットワークを中心に取り扱っています。

そんな自分が去年 ~ 今年にかけて任された仕事のうちの1つに Keaの検証 というのがあり、日本語で公開されている知見は少ないため書き残しておこうと思います。

と言う意図の記事を書いていたらめちゃくちゃ長くなったので 前後編 3分割しました。DHCP としてKeaが革新的なのはAPIがあることなので、AdventCalender的にはこの記事で登録しています。

前篇のあらすじ

  • ISC DHCPの開発もサポートも終わろうとしている
  • 今後ISCは Kea というDHCPを開発していく
  • Keaは色々便利機能とかがあるけど、特にWebAPIサーバーが生えていて便利!!!

今回書く話し

  • Kea DHCPを動かしてみる
  • Kea DHCPについているAPIの動かし方と注意点
  • ログのフォーマット
  • Keaの検証してみて良いと思った話しとまとめ

対象

DHCPとDockerを動かしていきますので、DHCPプロトコルを知っているかた かつ Dockerの動かし方を知っている方向けに書いています。

最新版の動作を試すには?

前篇でKeaの特徴などを述べてきましたが、ではKeaを動作させるにはどうしたら良いか?を書いておきます。

2017/12/10、現在 インストールのページを眺めても、最新版であるv1.3.0のパッケージは提供されていません。v1.2.0を提供しているのもBSD系とArchLinuxだけですね。せめてv1.2.0以上でないとAPIサーバーの機能が使えず嬉しさ半減です。

なので、最新版をDockerのイメージとして用意いたしました。 (ただし、野良ビルドですので、プロダクション等で利用されても特に責任は取れせんので注意してください。)

https://hub.docker.com/r/shouhei/kea-dhcp/

dockerをインストール済みの方は、以下のコマンドでイメージをダウンロード可能です。

docker pull shouhei/kea-dhcp:v1_3_0

自分ではLinux上で動くことしか検証していません。DHCPがリクエストを受けられるようにhost networking機能を使っているためMacでは動作しないのがわかっています。(もしAPIだけ動けば良いんだ!という気持ちならば、host networkingの設定を外したり、コメントアウトしたりしたら良いと思います。 )

設定ファイルのサンプルは以下においてあるので、それを利用します。ホストについている全てのネットワークインターフェスから、192.168.10.0/24 でIPを配布する設定となっています。検証の環境に合わせて適宜変更してください。変更する際は管理者リファレンスの8.2を参照すると良いです。

kea-docker/config.json.example at master · shouhei/kea-docker · GitHub

肝心の動作方法は以下のような感じで。

docker run --net=host -v ${PWD}/config.json.example:/etc/kea-config.json -it kea-dhcp:latest kea-dhcp4 -c /etc/kea-config.json

すると、設定ファイルで指定したインターフェースがつながっているネットワークでIPの配布が可能になるはずです。

ここまでは極々普通のDHCPサーバーです。

Kea の API サーバーを動かす

まず、KeaのAPIサーバーをDockerで試すには、以下の理由から少し工夫が必要です。

  1. Dockerの1プロセス1コンテナのモデルを守りたい
  2. APIサーバーであるControl-Agentは、Dhcp4サーバー等に処理をディスパッチするためのwebの受け口である
    • ディスパッチの経路がソケットファイル

図にすると以下のように動いて欲しいのです。

f:id:yaaamaaaguuu:20171211025058p:plain

なので、上記を満たすためのdocker-composeファイルと設定ファイルも作成しておきました。

gist.github.com

上記をローカルにコピーして docker-compose up を実施すると動くはずです。

サンプルの設定は簡易版です。後述する config-write というAPIでKeaの持つ設定を別名で書き出すことも、同名で書き出すこともできますが、同名で書き出すとControl-Agent用の設定か、DHCP4の設定が上書きされて消されるのできちんとやる場合は設定ファイルを分割して読み込ませてください。

APIの叩き方は以下のコマンドの様に、curlを使って、Headerに Content-Type: application/json をつけ、POSTメソッドでJSONを投げつけます。

curl -H "Content-Type: application/json" -d '{"command": "list-commands", "service": ["dhcp4"]}' localhost:8080

基本的には以下の3つのkeyとvlaueを指定することでAPIを動作させます。

  • command
    • コマンド
    • apiのlist-commandsで一覧が見れる
    • 後述するサービスとの組み合わせで利用できるコマンドが異なるのに注意
  • service
    • dhcp4なのか、dhcp6なのかとか
    • 配列形式での指定
    • 癖があるので後述する
  • arguments
    • apiによって異なるのでリファレンス参照

APIリファレンス自体は http://kea.isc.org/docs/kea-guide.html#ctrl-channel にあります。

現状標準で使えるAPIとしては大きく分けて3つあります。

  1. 設定変更等を含むサーバー操作系
  2. リース情報の操作系
  3. サーバーが受け取ったパケットの統計情報の閲覧系

サーバー操作系のAPIではconfig全体を書き換える、読み取るくらいしかできないのですが、それでもプログラムから設定の自動生成、投入するには事足りると思います。

また(有料のAPI群にまぎれて)リース情報の操作系を取り扱うhookとAPIはv1.3.0からは同梱されるようになりました。hookを読み込むことで使えるようになります。リース情報のデータベースを初期化したりするapiが生えています。 http://kea.isc.org/docs/kea-guide.html#lease-cmds に詳しい情報が書いてあります。が検証しきれていないので特に言及はしないことにします。

Kea の APIの挙動

APIの種類やコマンドKeaのAPIは挙動に癖があると感じています。これらはおそらくバージョンが上がっていくごとに改善されていくと思うのですが、現状の挙動と癖を書いておこうと思います。

設定変更等を含むサーバー操作系のAPIの注意点

リファレンスには書いてあるのですが、自分が最初に触ったときに若干引っかかったことを記載しておきます。

  • config-write
    • 現在DHCPがメモリ上に持っている設定をファイルに書き出す
  • config-set
    • リクエストとして送ったデータをDHCPの設定としてメモリ上に持つようにする
    • ファイルには書き出さない
      • 書き出したい場合は上記config-write を呼び出す。
    • config-setの後、特にサーバーの再起動等は不要
    • argumentsとして渡すのは、全設定となる
      • 渡さなかった設定値は、サーバーで設定されているデフォルト値となるはず
    • config-setの際はソケットファイルの設定だけは書き換えないように注意する必要がある
      • ソケットファイルを書き換えたが最後、DHCP的にはソケットファイルが見つからず、APIのリクエストが通らなくなる気がします

引数について

serviceにはリスト形式でdhcp4やdhcp6が指定できますが、何も指定しないと、control-agentを指定する事になります。

また、v1.3.0 では control-agentを文字列で指定できません。(ソースを読む限りそうなっていますし、文字列で指定するように修正するのは大変そうだなぁと思っています。)

つまり、dhcp4とcontrol-agentを同時に指定することは不可能です。なので、config-write で設定を上書きしたい際は設定ファイルを分割させる必要があります。

APIレスポンスについて

後述しますが、ログが充実している代わりに、APIレスポンスのメッセージが凄く貧弱です。

HTTPのレスポンス的には200と400しか返さなかったと記憶しています。もしかしたら201と404くらいは追加であったかも。

でもそれくらい貧弱で、たまーにエラーでもhttp的には200を返したりします。なので、APIのレスポンスは result というkeyを信じる事にしましょう。

result indicates the outcome of the command. A value of 0 means success while any non-zero value designates an error or at least a failure to complete the requested action. Currently 1 is used as a generic error, 2 means that a command is not supported and 3 means that the requested operation was completed, but the requested object was not found.

とドキュメントにも記載があるので。

ログの話

APIレスポンスの話の際に、ログが充実していると記載しました。ログのメッセージ自体はリファレンス にありますがKeaのログのフォーマットと、ISC DHCPのログのフォーマットを比較しておきます。

ISC

ISC DHCPDHCPプロトコルのメッセージに沿ったログの出力をしています。ぱっと見たときはわかりやすいのですが、Keaと見比べると異常系のログはなぜ?という情報が少なく思えます。

#具体例
Dec 11 10:35:31 isc-dhcp-server dhcpd: DHCPACK on 192.168.0.55 to xx:xx:xx:xx:xx:xx via eth0
# 説明
日付 ホスト名 dhpcd: DHCPメッセージ on ipアドレス to macaddress via インターフェース

Kea

keaの内部の動作に沿ったログの出力をしています。以下のパターンの場合は、メッセージマニュアル ページで DHCP4_BUFFER_RECEIVED を調べるとログの出力の理由がわかるようになっています。また内部のコンポーネントのどこからメッセージが出力されたか?は kea-dhcp4.packets管理者リファレンス・マニュアル で調べるとわかるようになっています。

#具体例
2017-12-10 22:12:15.972 DEBUG [kea-dhcp4.packets/1] DHCP4_BUFFER_RECEIVED received buffer from 0.0.0.0:68 to 255.255.255.255:67 over interface ens224
#説明
日付 ログレベル [ログの出力元] メッセージ(大文字の箇所) 詳細(大文字以降)

Keaを検証して、良いサーバーだと思えた箇所とまとめ

まとめに入っていこうと思います。Keaを検証してよいと思えた点は、以下だと思いってます。

ここまでで、APIサーバーとしてこまった箇所をいくつもあげてしまいましたが、web apiが生えて利便性は確実に高まったと思っています。設定変更のためにサーバーにログインして設定ファイルを書き換えて... と言った仕事を減らすことがより簡単に可能になると思います。また将来的には、そのAPIを活用してIPAM等との連携も視野に入れているようです。(そこらへんは後編で書くつもりです。)

運用の自動化、効率化とは別の側面を考えると (前篇で問題としてあげていた) ISC DHCPから Kea DHCPへの乗り換えというのがあると思っています。その際に効果を発揮してくるのが、ドキュメント類の充実具合です。どのようなサーバーよりKeaのドキュメントは充実していると思うので、開発する際はお手本にしたいと思えるくらい充実しています。

そのメッセージリファレンスが活躍するのはログ出力を眺めているときで、Keaではサーバーの内部挙動に合わせたログ出力になっています。設計段階からログ出力とメッセージリファレンスを突き合わせることで内部がどの様に動いたかを提示しやすくする様に考えているはずで、困ったときは大体メッセージリファレンスと再現するか?の検証で事が足ります。ISCとKEAで開発会社が同じだけ合って、困りどころがよくわかっているなぁと感心してしまいます。

ということで、将来的にはDHCPを置き換えるであろう、Keaの話しの中編を投稿させていただきました。

プログラムは3度作り直されるというのを過去に何処かで読んだ事があります。そこには 荒削りなプログラム -> 機能満載で使いづらいプログラム -> 洗練されたプログラム という流れをたどると書いてあったと記憶しています。 ISC DHCP -> BIND10 -> Kea という形を経て、確実に良いサーバーになっていると思うので、DHCPを構築運用している方はKeaを試してみるべきだと思います。

明日の話し

まず個人的な話をするとこの記事の後では、個人的には統計情報APIや有料hook, 開発のマイルストーンなど、 前編、中編で拾えなかった話を後編として落穂拾いをしていきます。

アドベントカレンダー的な話しをすると、明日は @Ken-Moriizumi さんの 「KONGでニフクラスクリプトもチームもマネジメントする話」 という記事です。

たぶん https://github.com/Kong/kong のことだと思いますが、マイクロサービス向けのAPIゲートウェイとのことで、APIゲートウェイの話しがどのようにしてチームマネージメントにまで繋がるか?が個人的には気になるところです。

KONGのアイコンがめっちゃかっこいい。どうでも良いですが、動物続き(keaはニュージーランドの高山に住むオウムの名前って書いてありました。)な事に気が付きました。

引き続き、 富士通クラウドテクノロジーズ Advent Calendar 2017 をチェックしていただければと思います。

よろしくお願いいたします。

せっかく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を使ってゴニョる必要があったところまでは辿り着かなかったものの、wgetsmtpって出来るのかなぁ?と思っていた
      • writeupを見る限り通常の利用方法の範囲では無理そう
  • automatic_door
    • .htaccessを仕込んでphpを動作させ、任意のコマンドをOS上で実行するところまでは行けた
    • そのあと /flag_x をきちんと調査するのを怠がって変なコマンドを流したら、新規でファイルをアップロードできなくなってタイムアップ
      • ここらへんCTF慣れしていない弱さがでたと思った。

感想

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

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

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

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自体が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 では、自分が追記したルールは削除されないことを確認している