BIOSがバージョンアップできているか確認したい dmidecode コマンド
背景
サーバのfirmware のバージョンアップをやった。バージョンアップツールにBIOSのバージョンアップも同梱されているっぽい。実際にバージョンが上がっていることを確認した。導入が2011年ごとのサーバだったので2015年とか2016年に上がっていればOK。 （どのベンダーの物理サーバかはぼかして書いてます）
コマンド
dmidecode コマンドを使う。 このコマンドはハードウェア情報を取得するためのコマンド。BIOSの情報ものってる。
コマンド実行結果
$ sudo dmidecode | grep -A 3 "BIOS Information"
BIOS Information
Vendor: HP
Version: P68
Release Date: 08/16/2015
OK good
コマンドがないんだけど？ を解決するwhereis コマンド
背景
CentOS 5系のサーバとかだとコマンドにいろいろパスが通ってなかったりする。 今までは mlocateパッケージを入れて、locateコマンドで探していたりした。
コマンド
whereis コマンドはコマンドとかのありかを教えてくれる便利コマンド。
どのパッケージに入っているの？ という話だが、 以下のようにrpmコマンドでファイルがどのパッケージに含まれるか見れる。
$ rpm -qf `which whereis` util-linux-2.13-0.47.el5
どうやら util-linuxというやつに入っているらしい。core groupに入っている。
使ってみると
$ whereis ifconfig ifconfig: /sbin/ifconfig /usr/share/man/man8/ifconfig.8.gz
MySQLで他のサーバからdataディレクトリコピーしてきたけど動かない（innodb_log_file_size設定）【問題と解決】
目次
背景
新たにMySQL Slaveサーバを構築したい。既存のSlaveサーバを一旦とめて、dataディレクトリごとコピーして配置。普段だったらmaster.infoとかも入っているし、すんなり動くが、今回はなんか動かなかった。
エラー
mysqld start時に以下のエラー
Starting MySQL.. ERROR! The server quit without updating PID file (/usr/local/mysql/data/seiga-s01b.pid).
対応
順に問題をつぶしていく。
- pidファイルが書けないのか？ Permissionがないとか？ => mysqlユーザになり、touchで該当箇所にファイル作成できる。
- errログがPermissionが原因ではけないとダメという事例も？ => mysqlユーザの持ち物になっててOK
- errorログをtail -fして起動してみる。error log に以下のエラーが出力されている。
InnoDB: Error: log file /usr/local/mysql/data/ib_logfile0 is of different size 0 268435456 bytes
問題はこれだな。ib_logfileはサイズと個数が設定と一致してないとダメだった。設定では128M, 実体は他のサーバから持ってきたので256Mになっていた。 削除して起動してやると問題なく起動。ib_logfileも新たに作成されている。
おわりに
前にファイル側ではなくて設定変更したときに公式ドキュメントに書いてあった知識が役にたった。 innodb_log_file_size の値を変えるときには、MySQLサーバ停止後にファイルを消して起動するべし、とのこと。
MySQL脆弱性 CVE-2016-6662 について (2016 09 13現在)
これは何
MySQLにリモートでコード実行される可能性のある脆弱性 CVE-2016-6662 が発覚。その概要と対応をまとめる。
目次
- これは何
- 目次
- 資料
- 対象バージョン
- ざっくり言うと？
- 設定ファイルが書き換えられるとなぜ攻撃になる？
- 今回の脆弱性
- my.cnfに追記する
- ファイルが無い状態から作る
- 対応方針案
資料
CVE-2016-6662 http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html
対象バージョン
2016 09 13日現在の全てのバージョン。 具体的に言うと、現時点での最新のバージョンの以下を含む、それ以前のバージョンに脆弱性が存在。
- 5.7.15
- 5.6.33
- 5.5.52
要するにパッチがまだない。 MySQL cloneの MariaDBとPerconaDBにも影響。
ざっくり言うと？
SQLインジェクションを使って、 my.cnf を上書きできる。 攻撃するには以下の条件が必要
- SQLインジェクションができること
- /etc/my.cnfがmysqlユーザから書き換えられるパーミッションになっていること または その他my.cnfの置けるディレクトリにmysqlユーザが書き込み権限があること
設定ファイルが書き換えられるとなぜ攻撃になる？
mysqld_safeがrootプロセスで起動して、mysqldプロセスがmysqlユーザに落として起動される。mysqld_safeのスクリプト（配置場所によるが、例えば /usr/local/mysql/bin/mysqld_safe）のset_malloc_lib()でshared library がmysqlサーバ起動前に読み込まれて--malloc-lib=LIB へセットされる。 設定ファイルを書き換えられるということは、この変数で読み込む値を my.cnfの [mysqld]か[mysqld_safe]セクションで好きに設定できるということ。そうすると、任意のライブラリ（任意コード）がmysqlサーバ起動時にroot権限でされる（mysqld_safe実行時なので）。 3.23.55以前のバージョンだと
SELECT 'malicious config entry' INTO OUTFILE '/var/lib/mysql/my.cnf'
このコマンドでファイルが作れて、設定ファイルとして読み込むことができる。ファイル作成の例としては /tmp/ 下に作成してみると
$ mysql -uroot -p -e "SELECT 'malicious config entry' INTO OUTFILE '/tmp/my_temp'" $ ls -ltr /tmp/my_temp -rw-rw-rw- 1 mysql mysql 23 Sep 13 16:50 /tmp/my_temp $ cat /tmp/my_temp malicious config entry
今はこの脆弱性は修正されている。MySQLは 0666 permissionsのファイル（というかotherに書き込み権限がある場合）を設定ファイルとして読み込まないようになっている。具体的には以下のエラーが出て読み込まない。
Warning: World-writable config file '/etc/my.cnf' is ignored
しかし、MySQL logging関数で出力されたファイルは 0660 になっているので、設定ファイルとして読み込むことができる。これが今回の問題
今回の脆弱性
my.cnfに追記する
仮に my.cnfが以下の様なmysqlユーザの持ち物だった場合(例えば以下のようなパーミッションだった場合)
root@debian:~/# ls -l /etc/my.cnf -rw-r--r-- 1 mysql mysql 72 Jul 28 17:20 /etc/my.cnf
以下の内容をファイルに追記できる。
mysql> set global general_log_file = '/etc/my.cnf';
mysql> set global general_log = on;
mysql> select '
'>
'> ; injected config entry
'>
'> [mysqld]
'> malloc_lib=/tmp/mysql_exploit_lib.so
'>
'> [separator]
'>
'> ';
mysql> set global general_log = off;
ファイルが無い状態から作る
/etc/ 以下にmy.cnfが無い場合には、/etc/ ディレクトリのパーミッションで縛られる。root かつ 0644 だったばあいには mysqlユーザは作ることができない。 どのようなファイルが作られるか、/tmp/以下で試してみる。この方法で作られたファイルは以下のようなPermissionになる 。
$ ls -ltr /tmp/my_temp.txt -rw-rw---- 1 mysql mysql 685074 Sep 13 16:33 /tmp/my_temp.txt
しかし、この脆弱性だけでは、my.cnfに loggingの最初の行（version情報など）が入ってしまい、設定ファイルとして機能しない。 さらに他の脆弱性 CVE-2016-6663 （2016 09 13現時点では詳細非公開） を使用すると、（余計な情報を消して？）FILE権限なしに、任意の内容を書き込むことができる。
一次対応策
MySQL 5.5だと以下のような設定ファイルが置ける 参考： http://dev.mysql.com/doc/refman/5.5/en/option-files.html
/etc/my.cnf Global options /etc/mysql/my.cnf Global options SYSCONFDIR/my.cnf Global options $MYSQL_HOME/my.cnf Server-specific options defaults-extra-file The file specified with --defaults-extra-file=file_name, if any ~/.my.cnf User-specific options
- /etc/my.cnf がmysqlユーザで書き込み権限がないこと（例えば rootで 0644 ）を確認する
- /usr/local/mysql 直下が mysqlユーザの書き込み権限がないこと （例えば以下のようになっていること。mysqlユーザはここにmy.cnfを配置できない）を確認する
$ ls -ltrd /usr/local/mysql/ drwxr-xr-x 13 root mysql 4096 Sep 13 17:27 /usr/local/mysql/
- ファイルを置く権限がある場合には、 root パーミッションで作った my.cnf をダミーとして置いておく。作成も上書きも出来ないように。
- /etc/mysql/ ディレクトリが存在しないことを確認する
- /etc/sysconfig/ が mysql ユーザの権限がないことを確認する
$ ls -ltrd /etc/sysconfig/ drwxr-xr-x. 7 root root 4096 Sep 13 17:17 /etc/sysconfig/
- extra fileとして /home/simainte/my.cnf がある場合はそれが root 0600 になっていることを確認する
- /home/mysql/ に root 0600 で my.cnfを配置しておく。または /home/mysql/ を削除する
根本対応
パッチはまだない。mysqld_safe で shared_libraryを読み込まないという手もある。
Vmware ESXi でVMホストのディスクが圧迫されてインスタンスが落ちる問題（原因と対策）
背景
バックアップ用DBを作るために、でかいディスクを持つ物理サーバの上にVmware ESXiをたてた。 DBに他のSlaveからデータをscpしてみたら途中で突然インスタンスが落ちた。起動もスナップショットの操作も出来ない状態。 インスタンスへのディスク割り当ては200G。メモリは８G割り当て。 scpしたファイルは40G程度で、開きVMホストの元の空き容量は30G程度だった。
原因
datastoreを更新してみると空きがほぼ０になっていた。 詳細なファイルを見てみると以下のようなファイルが大きかった。(ホスト名を hostnameとする)
- hostname.vmdk
- サイズは200G。このファイルはインスタンスのディスクの実体。
- hostname-49271ad6.vswp
- hostname-000001.vmdk, hostname-000002.vmdk
- vmware-1.log
- 合計で数M。今回の問題とは無関係なので略
対策
- メモリオーバーコミットをさせない。インスタンスのメモリ設定で「すべてのゲストメモリを予約（すべてロック）」設定を入れる。
- スナップショットを全部消す。そうするとredoログが吐かれないのでVMホストのディスク圧迫が起こらない。
コメント
スナップショットが取れないのは不便だが、物理マシンと同じだと思えばまあよし。 ある程度構築して本番投入するまではスナップショットを使って、ほとんど変更が無くなったらスナップショットを全部消すなどの運用でカバーできそう。
Dockerを立ち上げたいがホストOSのルーティングと衝突して上がらない件
背景
Scientific Linux 7.2 で、Dockerを立ち上げたときにエラーが出て上がらなかった。問題と解決。
エラーメッセージ
# docker daemon --debug
最後の行に以下のもの。
FATA[0001] Error starting daemon: Error initializing network controller: Error creating default "bridge" network: failed to allocate gateway (192.168.17.0): Address already in use
解決方法
（すでに解決して消えてしまったのでうろ覚えだが）もうちょっと前に 192.168.0.0/16のネットワークが割り当てられないみたいなエラーが出ていた。 ホストOSですでにそのネットワークに対してルーティングが入っていてDockerに割り当てることができなかった。Dockerはデフォルトでこのネットワークを使おうとする。指定したければ --bip=CIDR で指定すればよい。
172.16.0.0/12 もホストでルーティング入ってしまっていたが、使わないのでいったん落とす。
# ip route del 172.16.0.0/12
# docker daemon --debug -s overlay --bip=172.16.1.1/24
Bridge IPを指定してやる。ここで、どうもIPはdocker0というインターフェースに使うようで、それ経由でDocker界に疎通するっぽい。なので、ネットワークアドレスを指定するとこれまた割り当てられないよ！というエラーがでる。 参考までに、docker0インターフェース。
$ ifconfig
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.16.1.1 netmask 255.255.255.0 broadcast 0.0.0.0
RHEL(Scientific Linux)7系でrouting追加ができない件（問題と解決）
背景
殆ど初めてRHEL7系を使った。7系でRouting設定に微妙にはまったのでメモ。
問題
以下のコマンドで追加しようとしたらエラーがでた。
# ip route add 172.16.0.0/12 RTNETLINK answers: No such device
解決
インターフェース名を指定してあげなくちゃダメだった。
# ip route add 172.16.0.0/12 dev eth0
6系のrouteコマンド使った時には適当に疎通できるインターフェースを判別してやってくれた気がするけど。正直大体static-routesファイルや route-eth* に書いてしまってnetwork restartしてたりしたのでどうだったかははっきりしない。
