---

■ Docker 基本操作 [Docker]

---

とりあえず help 眺める

asteroid:~ kunitake$ docker --help
Usage: docker [OPTIONS] COMMAND [arg...]

A self-sufficient runtime for linux containers.

Options:
〜以下略〜

やれることは、なかなか多そうだ。せっかくなので、以前買って積ん読になってた

Docker エキスパート養成読本
http://www.amazon.co.jp/dp/B010N105SC/

をつらつらと眺める。

docker run -it で、フォアグランドでの実行だよとのこと。

  -i, --interactive=false Keep STDIN open even if not attached
  -t, --tty=false Allocate a pseudo-TTY

なるほど。さっそく実行。

asteroid:~ kunitake$ docker run -it ubuntu:latest /bin/bash
Unable to find image 'ubuntu:latest' locally
latest: Pulling from ubuntu
83e4dde6b9cf: Pull complete
b670fb0c7ecd: Pull complete
29460ac93442: Pull complete
d2a0ecffe6fa: Already exists
ubuntu:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security.
Digest: sha256:cb90b1a107073ab3e17271e45a6177b23f548b44157d88d955b7e8bcdbcfd14a
Status: Downloaded newer image for ubuntu:latest
root@bb421f5e88b9:/# cat /etc/debian_version
jessie/sid
root@bb421f5e88b9:/# uname -a
Linux bb421f5e88b9 4.0.7-boot2docker #1 SMP Wed Jul 15 00:01:41 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
root@bb421f5e88b9:/# dpkg -l |lv
bash: lv: command not found
root@bb421f5e88b9:/# dpkg -l |wc -l
189

最初 docker pull ubuntu:latest やってなかったので、その場でダウンロード。思ったより展開が速い。

最新版に上げるには、再度 docker pull でいいのかな

asteroid:~ kunitake$ docker pull ubuntu:latest
latest: Pulling from ubuntu
83e4dde6b9cf: Already exists
b670fb0c7ecd: Already exists
29460ac93442: Already exists
d2a0ecffe6fa: Already exists
Digest: sha256:cb90b1a107073ab3e17271e45a6177b23f548b44157d88d955b7e8bcdbcfd14a
Status: Image is up to date for ubuntu:latest

当たり前なのかもしれないけど、ダウンロードし直すわけじゃなくて、ちゃんと差分をチェックしてくれる。

いま手元にダウンロードした docker image の一覧を表示してみる。

asteroid:~ kunitake$ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
ubuntu latest d2a0ecffe6fa 12 days ago 188.4 MB
hello-world latest 91c95931e552 3 months ago 910 B
busybox latest 8c2e06607696 3 months ago 2.433 MB

ついでに、nginx のイメージもダウンロード。

asteroid:~ kunitake$ docker pull nginx:latest
latest: Pulling from nginx
902b87aaaec9: Pull complete
9a61b6b1315e: Pull complete
aface2a79f55: Pull complete
5dd2638d10a1: Pull complete
97df1ddba09e: Pull complete
56c99fa886e8: Pull complete
cd27805ea89f: Pull complete
5e95ac0e9a79: Pull complete
9f36f81a1ccb: Pull complete
4c1809b04591: Pull complete
98c9ccd75644: Pull complete
6886fb5a9b8d: Already exists
nginx:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security.
Digest: sha256:a2b8bef3338643176198510fec71c18ceb7834e6f7c45b039ec6e963f43b4005
Status: Downloaded newer image for nginx:latest

これで、docker イメージが増えた。

asteroid:~ kunitake$ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
nginx latest 6886fb5a9b8d 4 days ago 132.9 MB
ubuntu latest d2a0ecffe6fa 12 days ago 188.4 MB
hello-world latest 91c95931e552 3 months ago 910 B
busybox latest 8c2e06607696 3 months ago 2.433 MB

コンテナをバックグラウンドで動かすには -d を使えとのこと。

  -d, --detach=false Run container in background and print container ID

実行後には、Dockerコンテナの CONTAINER ID が表示されるらしい。

asteroid:~kunitake$ docker run -d nginx:latest
26a716ed3fea632df0a732bc6f1fdcc524c7f53b1e3cd8749c990c46abd37725

複数同一イメージからコンテナを動かすためなのか、コンテナに名前も付けられるよとのこと。

--name= Assign a name to the container

早速やってみる

asteroid:~ kunitake$ docker run -d --name nginx1 nginx:latest
d485c78b6b3d265a5e2344bc936d0a4cf44637991009f9d03fce9d5a77dfd9d4

稼働中のコンテナを確認するには、ps コマンドを利用 (docker help で確認)

    ps List containers

稼働しているコンテナは２つのはず。

asteroid:~ kunitake$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d485c78b6b3d nginx:latest "nginx -g 'daemon of 5 seconds ago Up 3 seconds 80/tcp, 443/tcp nginx1
26a716ed3fea nginx:latest "nginx -g 'daemon of About a minute ago Up About a minute 80/tcp, 443/tcp gloomy_kowalevski

docker ps で表示される CONTAINER ID は、docker run で返ってくるものより短いですね。丸められてるっぽい。省略される前のIDも、UUIDっぽくもないなぁ……

なお、バックグラウンドで動作させているコンテナに接続するには、exec を利用する。

    exec Run a command in a running container

exec の引数には docker run の時の -it がそのまま同じ意味で利用可能。引数には、CONTAINER ID を指定。

asteroid:~ kunitake$ docker exec -it 26a716ed3fea /bin/bash
root@26a716ed3fea:/# which rpm
root@26a716ed3fea:/# which dpkg
/usr/bin/dpkg
root@26a716ed3fea:/# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
NAME="Debian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=debian
HOME_URL="http://www.debian.org/"
SUPPORT_URL="http://www.debian.org/support/"
BUG_REPORT_URL="https://bugs.debian.org/"
root@26a716ed3fea:/# touch 2015-07-22
root@26a716ed3fea:/# pwd
/
root@26a716ed3fea:/# exit
exit

動作上は、丸められたっぽい CONTAINER ID で十分みたい。ともあれ、もう一度接続してみて、確かに同じコンテナに接続できていることを確認。

asteroid:~ kunitake$ docker exec -it 26a716ed3fea /bin/bash
root@26a716ed3fea:/# ls -l /2015-07-22
-rw-r--r-- 1 root root 0 Jul 22 10:13 /2015-07-22
root@26a716ed3fea:/# date
Wed Jul 22 10:13:33 UTC 2015
root@26a716ed3fea:/# exit
exit

ちなみに、コンテナは稼働していなくてもそのコンテナを削除するまで、残ってる。停止状態にあるコンテナを表示するには "ps -a"を利用.

  -a, --all=false Show all containers (default shows just running)

docker ps -a を発行すると、バックグラウンドで稼働させているコンテナに加えて、停止中のコンテナも表示される。

asteroid:~ kunitake$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d485c78b6b3d nginx:latest "nginx -g 'daemon of 4 minutes ago Up 4 minutes 80/tcp, 443/tcp nginx1
26a716ed3fea nginx:latest "nginx -g 'daemon of 5 minutes ago Up 5 minutes 80/tcp, 443/tcp gloomy_kowalevski
bb421f5e88b9 ubuntu:latest "/bin/bash" 10 minutes ago Exited (130) 8 minutes ago goofy_elion
3a2860ca69e9 busybox "echo hello world" 29 hours ago Exited (0) 29 hours ago ecstatic_perlman
2d564b9c352e busybox "echo hello world" 29 hours ago Exited (0) 29 hours ago determined_bell
048cd248b560 hello-world "/hello" 2 days ago Exited (0) 2 days ago boring_elion
9fc6d72b1470 busybox "ls" 3 days ago Exited (0) 3 days ago mad_fermi
55c268f2ca5e hello-world "/hello" 3 days ago Exited (0) 3 days ago stupefied_carson
c757592271d0 hello-world "/hello" 3 days ago Exited (0) 3 days ago hungry_franklin
8883e0e9d689 hello-world "/hello" 3 days ago Exited (0) 3 days ago suspicious_tesla

削除するには docker rm

    rm Remove one or more containers

引数には、CONTAINER IDを指定。実際に消してみる。

asteroid:~ kunitake$ docker rm 8883e0e9d689
8883e0e9d689
asteroid:~ kunitake$ docker rm c757592271d0
c757592271d0
asteroid:~ kunitake$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d485c78b6b3d nginx:latest "nginx -g 'daemon of 5 minutes ago Up 5 minutes 80/tcp, 443/tcp nginx1
26a716ed3fea nginx:latest "nginx -g 'daemon of 6 minutes ago Up 6 minutes 80/tcp, 443/tcp gloomy_kowalevski
bb421f5e88b9 ubuntu:latest "/bin/bash" 12 minutes ago Exited (130) 9 minutes ago goofy_elion
3a2860ca69e9 busybox "echo hello world" 29 hours ago Exited (0) 29 hours ago ecstatic_perlman
2d564b9c352e busybox "echo hello world" 29 hours ago Exited (0) 29 hours ago determined_bell
048cd248b560 hello-world "/hello" 2 days ago Exited (0) 2 days ago boring_elion
9fc6d72b1470 busybox "ls" 3 days ago Exited (0) 3 days ago mad_fermi
55c268f2ca5e hello-world "/hello" 3 days ago Exited (0) 3 days ago stupefied_carson

確かに消えた。docker rmi で、DockerコンテナのベースになっているDockerイメージも消せるとのこと。

    rmi Remove one or more images

docker images で表示されていた hello-world を消してみる。引数には、CONTAINER ID ではなく、IMAGE ID を利用する。

asteroid:~ kunitake$ docker rmi 91c95931e552
Error response from daemon: Conflict, cannot delete 91c95931e552 because the container 048cd248b560 is using it, use -f to force
Error: failed to remove images: [91c95931e552]

稼働中/停止中のコンテナがあると、そのDockerコンテナの元となっているDockerイメージは消せないらしい。

どうせなので、さっき、マニュアルには、docker rm ではDockerコンテナを1つ以上消せるとあったので、同時に消してみる。

asteroid:~ kunitake$ docker rm 55c268f2ca5e 048cd248b560
55c268f2ca5e
048cd248b560
asteroid:~ kunitake$ docker rmi 91c95931e552
Untagged: hello-world:latest
Deleted: 91c95931e552b11604fea91c2f537284149ec32fff0f700a4769cfd31d7696ae
Deleted: a8219747be10611d65b7c693f48e7222c0bf54b5df8467d3f99003611afa1fd8
asteroid:~ kunitake$ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
nginx latest 6886fb5a9b8d 4 days ago 132.9 MB
ubuntu latest d2a0ecffe6fa 12 days ago 188.4 MB
busybox latest 8c2e06607696 3 months ago 2.433 MB

消えた。コマンド１発だけ動かすような Dockerコンテナでは、いちいちイメージを消すのは面倒ですが、"--rm"をつけると、自動的に消してくれるらしい。

asteroid:~ kunitake$ docker --rm run busybox:latest ls
flag provided but not defined: --rm
See 'docker --help'.

間違えた。docker run の引数として "--rm" がサポートされてるんだった。

asteroid:~ kunitake$ docker run --rm busybox:latest ls
bin
dev
etc
home
lib
lib64
linuxrc
media
mnt
opt
proc
root
run
sbin
sys
tmp
usr
var
asteroid:~ kunitake$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d485c78b6b3d nginx:latest "nginx -g 'daemon of 17 minutes ago Up 17 minutes 80/tcp, 443/tcp nginx1
26a716ed3fea nginx:latest "nginx -g 'daemon of 19 minutes ago Up 19 minutes 80/tcp, 443/tcp gloomy_kowalevski
bb421f5e88b9 ubuntu:latest "/bin/bash" 24 minutes ago Exited (130) 21 minutes ago goofy_elion
3a2860ca69e9 busybox "echo hello world" 30 hours ago Exited (0) 30 hours ago ecstatic_perlman
2d564b9c352e busybox "echo hello world" 30 hours ago Exited (0) 30 hours ago determined_bell
9fc6d72b1470 busybox "ls" 3 days ago Exited (0) 3 days ago mad_fermi
asteroid:~ kunitake$

たしかに、停止中のイメージは増えなかった。

---

---

---

■ OpenSSH に MaxAuthTries をバイパスできる脆弱性 [Security]

---

OpenSSHのバグにより攻撃者が短時間で数千のPW推測を可能に。ネットに公開されたsshアカウントのブルートフォースが可能に。通常はOpenSSHは3から6回のログイン試行しかできない。攻撃方法の詳細有り。公開鍵暗号鍵の利用が推奨http://t.co/yzmMfdYHWx

— 高梨陣平 (@jingbay) 2015, 7月 21

パスワードの総当りアタックが大変捗ります、という攻撃手法が見つかってしまったようです。

念のためこの攻撃が成功するか確認してみました。上記サイトにも書いてあるんですが、この攻撃が成功する前提として、 keyboard-interactive authentication が許可されてないとダメというのがあります。

具体的には /etc/ssh/sshd_config に

PasswordAuthentication yes
ChallengeResponseAuthentication yes

となっているときに、攻撃が成功するというものです。FreeBSD は ChallengeResponseAuthentication が標準で yes になっているので、標的となる可能性が高いようですが、CentOS/RHEL系は、ChallengeResponseAuthentication が標準で no なので、この攻撃は成功しないようです。

ということで、念のためサーバ設定を確認しておくことをお勧めします。一番はパスワード認証を許可しないことですね。もちろん

PasswordAuthentication no
ChallengeResponseAuthentication no

にする前に、公開鍵認証でログインできるようにしておかないと、ログインできなくなっちゃいますけど。

[追記]:

KbdInteractiveAuthentication
    Specifies whether to allow keyboard-interactive authentication. The argument
    to this keyword must be “yes” or “no”. The default is to use whatever value
    ChallengeResponseAuthentication is set to (by default “yes”).

KbdInteractiveAuthentication が個別に設定されている例もあるかも？

ChallengeResponseAuthentication no
KbdInteractiveAuthentication yes

では影響を受けず、

ChallengeResponseAuthentication yes
KbdInteractiveAuthentication no

なら、影響を受けるようです（結局 ChallengeResponseAuthentication 次第？ KbdInteractiveAuthentication の存在意義は……）

Reddit についてるコメントも参考になりますね。

OpenSSH keyboard-interactive authentication brute force vulnerability (MaxAuthTries bypass)
http://www.reddit.com/r/netsec/comments/3dnzcq/openssh_keyboardinteractive_authentication_brute/

[追記その２]:

1つ指摘頂きました。

@kunitake Linuxの場合チャレンジレスポンス認証はPAMを使うので、UsePAM yesも成功条件ですね。noにするとチャレンジレスポンス認証がコケちゃいますw

— no root, nobody (@togakushi) 2015, 7月 22

もうちょっと噛み砕いた情報が欲しい場合は、ozumaさんの

sshによるユーザ列挙攻撃"osueta"
http://d.hatena.ne.jp/ozuma/20140623/1403532516

内の、"ちょっと脱線：UsePAMとPasswordAuthentication" の部分が参考になります。

つまりは

ChallengeResponseAuthentication yes

の場合でも、UsePAM が no であれば、同じパスワードでのログイン不可となるので、攻撃に成功しないよということになります。より具体的には、ozumaさんが表にまとめられている通り、下記の３つのケースで成功しません。

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes

PasswordAuthentication no
ChallengeResponseAuthentication yes
UsePAM no

Also see: sshd_config(5)

---