List of Linux [Baldanders.info]

glibc: __nss_hostname_digits_dots() の脆弱性について

2015-01-31T09:00:00+00:00

ふぅ。やっと仕事が一段落したんで溜まった宿題を片付けていくか。

バッファオーバーフローが発見された関数は__nss_hostname_digits_dots()だが、ユーザランドのソフトウェアからはgethostbyname()などの関数を呼び出すことでこの関数が実行される。このため、gethostbynameをGetHOSTbynameともじって「GHOST」と命名されている。
Qualysの研究者によると、2013年の時点でこの脆弱性を発見して、glibc-2.17とglibc-2.18の間において修正を行っているが、当時はセキュリティに関わるリスクとしては認識されていなかったため、長期サポートの対象となっているバージョンのLinuxディストリビューションではこの脆弱性が修正されることなく残り続けているという。

Linuxできわめて重大で危険な脆弱性「GHOST」を確認より

NVD ではこの脆弱性の CVSS 値を 10.0（AV:N/AC:L/Au:N/C:C/I:C/A:C）と評価している。脆弱性を報告した Qualys では

The gethostbyname*() functions are obsolete; with the advent of IPv6, recent applications use getaddrinfo() instead.

via GHOST: glibc gethostbyname buffer overflow

としていて，実際に影響のあるアプリケーションは多くないと見ているようだ（Exim を運用しているサーバは早急に対応が必要）。こちらはトレンドマイクロの記事。

すべてのアプリケーションが等しく危険にさらされているわけではありません。この脆弱性の攻撃において攻撃者が利用できるのは4バイトもしくは 8バイトのエクスプロイトコードであり、実行できることは非常に限られています。この攻撃に利用できるバイト数は OS が 32ビット版か 64ビット版かで異なります。追加のコードは、変更可能なポインタに参照されるアドレスに攻撃者が脆弱性とは別の方法で書き込んで置かなければなりません。また、apache や postfix、OpenSSH など、多くの有名アプリケーションがこの脆弱性の影響を受けないことも確認されています。これまでのところ、トレンドマイクロでは、Web攻撃に利用される可能性のある感染媒体を確認しておらず、そのため攻撃の可能性はかなり低いものと考えられます。

Linuxに存在する脆弱性「GHOST」、システム管理者は落ち着いて対処をより

対策としては glibc-2.18 （以上）にアップデートすればよい。 glibc を取り込んでいるアプリケーションについては再コンパイルが必要かもしれない。更新を確実に反映させるには再起動が必要。したがって，特にサーバは，きちんと計画した上で更新を行う必要がある。（慌てるなんとかは貰いが少ない）

対象のシステムが今回の脆弱性に該当しているかわからない場合は，以下の検証コードをコンパイル・実行すると良い。

via GHOST: glibc gethostbyname buffer overflow

GitHub でも公開されているので参考にどうぞ。

気をつけるべきはルータやスイッチなどのファームウェアだろう（特に古いもの）。 JVN に日本製品の情報があるので注意すること。（つっても殆ど無いけど）

とりあえず，こんなとこかな。今回は，最初こそ騒がれたものの（私もびっくりした），だんだんトーンダウンしていくプロセスが面白い。まぁ，こういうこともあるよね。

「さくらの VPS」に Scientific Linux をインストールする

2011-10-09T09:00:00+00:00

実はしばらく前から「自宅サーバのクラウド化」計画を進行中で（ここのところ中断していたが），「さくらの VPS」を契約して現自宅サーバの中身を移行しようと考えている。なにせ現行の自宅サーバは1999年製のふっるいデスクトップ機で，メモリと HDD 容量は若干強化してあるものの，いつ壊れてもおかしくないし，壊れても替えの部品はもう手に入らないだろうし。あとはまぁ時流に乗って「さくらの VPS」を使ってみたいなってのもあって。

ただ「さくらの VPS」の標準 OS は CentOS 5 で若干古い気もしてたので，「Scientific Linux とかサポートしてくれないかなぁ」と思ってたら本当にサポートしてくれた。

「さくらのVPS」にて「Scientific Linux」提供開始のお知らせ

ちうわけで，覚え書きとして Scientific Linux のインストールからセットアップの最初のところまで書いておく。

Scientific Linux のインストールは VPS コントロールパネルの「OS再インストール」から「カスタムOSインストールへ」のリンク先へ行くと OS が選択できる。今回は Scientific Linux 6 x86_64 を選択した（インストール後に確認したら正確には 6.1 らしい）。特に理由はない。標準 OS が CentOS 5.5 x86_64 なのでアーキテクチャを合わせてみたというだけだ。

インストールの前に JRE がインストール済みで（Firefox の場合は） Java Plug-in が有効になっていることを確認すること。私はこれでちょっとハマった。 JRE はインストール済みだったのだが SSL/TLS 脆弱性の回避のために Java Plug-in を無効にしていたのだ。気づかないままいつまで経っても VNC が起動しないので「おかしいなぁ」と思ってたり。

インストールの開始が表示されたらネットワーク情報（IP アドレス・サブネットマスク・DNS サーバのアドレス）をメモしておいて VNC コンソールを起動する。 VPS コントロールパネルの「リモートコンソール」から「VNCコンソールを開く」のリンク先へ行くとコンソールが開く。以降の操作は以下のマニュアルページを参照すれば問題ない（失敗しても「OS再インストール」からやり直せるのでご安心を）。

Scientific Linux 6｜カスタムOSインストールガイド

全て終了して仮想サーバを「起動」したら ssh で root にログインしてみる。ログイン出来ればインストール成功である。

以降はインストール後のセットアップについて。セキュリティ上の大事な部分だけ説明する。なお操作にあたって以下のページを参考にした。

まずは adduser, passwd コマンドで新しいユーザ（ここでは hogehoge）の登録とパスワードの設定を行う。

# useradd hogehoge
# passwd hogehoge

後にパスワード認証を無効にするとはいえ，パスワードは十分長くて複雑なもの（巷にあるパスワードジェネレータを使うとよい）を選ぶこと。パスワードを覚えられない場合は（使わないパスワードは覚えられないものだが）， KeePass 等のパスワード管理ツールを使うとよいだろう，ってみんなやってるか。

次に作成したユーザでログインし， ssh の公開鍵を設定する。 ~/.ssh （700）ディレクトリを作成しそこに公開鍵情報を記述した authorized_keys （600）ファイルを入れる。公開鍵認証でログインできることを確認した後， root に移って /etc/ssh/sshd_config を編集する。

ポートを 22 から変更する（なるべく大きな値）
PermitRootLogin no
PasswordAuthentication no

その後 sshd を再起動する。

# service sshd restart

これで ssh での root のログインとパスワード認証を無効にできる。 ssh のポートを変更するのは単純なポートスキャン（22番を ssh のポートとして狙い撃ちしてくる）から逃れるためだ。

ここでシステムのアップデートをしておく。

# yum update

といっても現時点では全て最新になってるみたいなので何もアップデートされなかったけど。

次に sudo の設定をする。

# usermod -G wheel hogehoge

更に visudo を起動し，以下のコメント部分を外す。

# %wheel  ALL=(ALL)       ALL
  ↓
%wheel  ALL=(ALL)       ALL

以降の操作は root 以外のユーザ（ここでは hogehoge）で sudo コマンドを使って行うことができる。ついでに ~/.bash_profile に /sbin:/usr/sbin:/usr/local/sbin のパスを追加しておく。

次は iptables の設定である。 /etc/sysconfig/iptables を用意する。中身は，例えばこんな感じ。

*filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :RH-Firewall-1-INPUT - [0:0]

-A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -p icmp –icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p 50 -j ACCEPT -A RH-Firewall-1-INPUT -p 51 -j ACCEPT -A RH-Firewall-1-INPUT -p udp –dport 5353 -d 224.0.0.251 -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp –dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp –dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

SSH, HTTP

-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport xxxxx -j ACCEPT -A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT

-A RH-Firewall-1-INPUT -j REJECT –reject-with icmp-host-prohibited

COMMIT

（COMMIT の後ろには改行コードを入れないこと）

xxxxx には ssh のポート番号が入る。他には80番（http）も許可している。それぞれの使用環境に合わせて調整すればいいだろう。 /etc/sysconfig/iptables を設定したら以下のコマンドで再起動する。

$ sudo /etc/rc.d/init.d/iptables restart

記述が正しければうまく再起動するはずである。

最後にログ監視の設定をする。ログ監視には logwatch をインストールする。

$ sudo yum install logwatch

インストールができたら /etc/logwatch/conf/logwatch.conf に報告先のメールアドレスを追記する。

MailTo = hogehoge@exsamle.com

これでメールアドレス宛に毎日報告が届くはずである。ちなみに「さくらの VPS」のお試し期間中はメール機能が使えないのでご注意を。

ところで NTP はどうなってるのかなぁ，と思って /etc/ntp.conf を覗いてみたら ntp1.sakura.ad.jp を参照してるみたい。ためしに ntpq コマンドを打ってみたら以下のようになった。

$ sudo ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ntp1.sakura.ad. .GPS.            1 u    6   64  377    8.532   -0.040   0.108

GPS ？なのか？

とりあえず，今回はここまで。