Container Registry に自分の作ったDockerイメージをpushする

cloud.google.com プライベートなDockerコンテナレジストリが欲しかったので使ってみた。

  1. gcloudコマンドのセットアップを終える
  2. gcloud auth configure-dockerでDocker Registryの認証をする
  3. 下記コマンドでビルド済みのイメージ名にタグ付けをする
$ docker tag [任意のイメージ名] gcr.io/[プロジェクトID]/[イメージ名]:[バージョン]
  1. 下記コマンドでContainer RegistryにDocker イメージを push
$ docker push gcr.io/[プロジェクト名]/[イメージ名]:[バージョン]

これで作ったDockerイメージのContainer Registryへpush完了

Ingressのヘルスチェックに対応する

tl;dr

  • "/"パスへのHTTPリクエストに対し200ステータスを返すように実装すればよい

Ingress のヘルスチェック

GKEでIngressを使っていた所ヘルスチェックをうまく通過しない。 色々と調べたところIngressのヘルスチェックはreadinessProbe.httpGetを指定しないと、デフォルトでは"/"パスにHTTP GETリクエストを送信し200ステータスが帰ってこない場合は対象ポッドが動作していないとみなすみたい。 https://github.com/kubernetes/ingress-gce/issues/42

readinessProbe.httpGetを指定しても別に良かったが、"/"パスは使っていないし、どうせヘルスチェック用にyamlを書き足しAPIのエンドポイントを作るのだったら、"/"へのリクエストに200返すようなコードを書いておけばいいだろうと思い、下記のGolangコードをエンドポイントに追加して対応した。

package main

import (
    "net/http"

    "github.com/labstack/echo"
    "github.com/labstack/echo/middleware"
)

func main() {
    e := echo.New()

    e.Use(middleware.Logger())
    e.Use(middleware.Recover())

    e.GET("/", func(c echo.Context) error {
        return c.String(http.StatusOK, "OK")
    })

    e.Logger.Fatal(e.Start(":8080"))
}

参考

Ingressというよりk8sの話だが、ヘルスチェックについては下記ドキュメントが参考になった - https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/ - https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

Practical Binary Analysisの演習用環境をDockerで作った

三行で

  1. Practical Binary Analysis はリバースエンジニアリング入門にはうってつけの本
  2. 基本的な演習環境はVMで配布されている
  3. Dockerで環境を作るときはバージョンを指定しよう

概要

Practical Binary Analysisはモダンなバイナリ解析について学ぶことができる本。 目次は下記の通り。

Chapter 1: Anatomy of a Binary
Chapter 2: The ELF Format
Chapter 3: The PE Format: A Brief Introduction
Chapter 4: Building a Binary Loader Using libbfd

Part II: Binary Analysis Fundamentals

Chapter 5: Basic Binary Analysis In Linux
Chapter 6: Disassembly and Binary Analysis Fundamentals
Chapter 7: Simple Code Injection Techniques for ELF

Part III: Advanced Binary Analysis

Chapter 8: Customizing Disassembly
Chapter 9: Binary Instrumentation
Chapter 10: Principles of Dynamic Taint Analysis
Chapter 11: Practical Dynamic Taint Analysis with libdft
Chapter 12: Principles of Symbolic Execution
Chapter 13: Practical Symbolic Execution with Triton

Part IV: Appendices

Appendix A: A Crash Course on x86 Assembly
Appendix B: Implementing PT_NOTE Overwriting Using libelf
Appendix C: List of Binary Analysis Tools
Appendix D: Further Reading

基礎的なディスアセンブラを実装したり、テイント解析やシンボリック実行をやったりと、今からリバースエンジニアリングをするなら抑えておきたい点を実装して手を動かしながら体系的に学ぶことができる。

実行環境について

そんなPractical Binary Analysisは演習用の実行環境としてVMを配布している。 別にVMでもいいのだが、単純にコードを参照したいくらいの時だと少し実行速度が遅い... なので特段VMでないといけないような処理以外はDockerで実行しようと思い至った。 少しググった所、Practical Binary Analysisの演習用環境をDockerで作っている人がいたので、その環境を利用。

https://github.com/wilvk/practical-binary

しかしこのコンテナ、RUN apt-get -y install gcc-4.9 g++-4.9を実行する際に下記エラーを出力しビルドが失敗してしまう。

Package g++-4.9 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

RUN add-apt-repository -y ppa:ubuntu-toolchain-r/testを実行しているのになぜ...? ググるとこれはUbuntu 18.04に起因しているっぽい https://askubuntu.com/questions/1036108/install-gcc-4-9-at-ubuntu-18-04 DockerFileを改めて見ると最初の行でUbuntuのバージョンを指定していない。

FROM ubuntu
RUN apt-get update
RUN apt-get -y install software-properties-common
RUN add-apt-repository -y ppa:ubuntu-toolchain-r/test
RUN apt-get update
RUN apt-get -y install gcc-4.9 g++-4.9
RUN update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.9 60 --slave /usr/bin/g++ g++ /usr/bin/g++-4.9
RUN apt-get -y install build-essential
RUN apt-get -y install libc6-dbg gdb valgrind
RUN apt-get -y install binutils-dev
RUN apt-get -y install strace
RUN apt-get -y install ltrace
RUN apt-get -y install vim-common
CMD ["/bin/bash"]

そのためUbuntu 18.04をダウンロードしてきてしまいビルドが失敗してしまう。 なのでUbuntuのバージョンを16.04に指定すると、失敗せずビルドすることができる。

FROM ubuntu:16.04
RUN apt-get update
RUN apt-get -y install software-properties-common
RUN add-apt-repository -y ppa:ubuntu-toolchain-r/test
RUN apt-get update
RUN apt-get -y install gcc-4.9 g++-4.9
RUN update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.9 60 --slave /usr/bin/g++ g++ /usr/bin/g++-4.9
RUN apt-get -y install build-essential
RUN apt-get -y install libc6-dbg gdb valgrind
RUN apt-get -y install binutils-dev
RUN apt-get -y install strace
RUN apt-get -y install ltrace
RUN apt-get -y install vim-common
CMD ["/bin/bash"]

https://github.com/famasoon/practical-binary/ にコミットしておいた。 これで、とりあえずコードを見ながら軽く動作させる環境のできあがり。

おわりに

https://practicalbinaryanalysis.com/Running Code Samples on Windows and Other Platformsの所でカーネル4.4以降だとうまく動作しないとか、そんな時のためのUbuntu 16.04 用カーネルダウングレードの仕方とかが載っているが、その時は適宜VMで演習をするなり環境を構築すればよいと思っているので問題なし。 という訳で環境を整えたのでリバースエンジニアリングをこれからやっていく(続く...?)

minikubeのダウンロードが途中で止まる

問題

タイトル通りminikubeを利用しようとしたところisoファイルのダウンロードで止まってしまう。

環境

macOS上で実行しているminikube v1.0.0

~ ❯❯❯ uname -a
Darwin DoenoMBP 18.2.0 Darwin Kernel Version 18.2.0: Fri Oct  5 19:41:49 PDT 2018; root:xnu-4903.221.2~2/RELEASE_X86_64 x86_64

~ ❯❯❯ minikube version                                                                       
minikube version: v1.0.0

~ ❯❯❯ minikube start --kubernetes-version=v1.11.3
There is a newer version of minikube available (v1.0.1).  Download it here:
https://github.com/kubernetes/minikube/releases/tag/v1.0.1

To disable this notification, run the following:
minikube config set WantUpdateNotification false
😄  minikube v1.0.0 on darwin (amd64)
💥  Kubernetes downgrade is not supported, will continue to use v1.14.0
🤹  Downloading Kubernetes v1.14.0 images in the background ...
🔥  Creating virtualbox VM (CPUs=2, Memory=2048MB, Disk=20000MB) ...
💿  Downloading Minikube ISO ...
 1.97 MB / 142.88 MB [>-----------------------------------------]   1.38% 28m14s

毎回2%くらいダウンロードしたあたりでハングしてしまう。

対策

GitHubのissueをみる限り既知の問題のようでワークアラウンドが出ている。 Hung downloading ISO (network contention with image pull) #4035 minikube start時に--cache-images=falseオプションをつけて問題を回避する。

minikube start --cache-images=false

自分の環境だとこれで正常にisoがダウンロードできるようになった。 上記GitHubのissueを見る限り、このバグに対応するコードをv1.0.1に盛り込む予定っぽいので今後のバージョンアップに期待。