突然消失するかもしれないブログ

”とつきえブログ”

カテゴリーアーカイブ: LinkStation

さよなら、HD-HGLAN・・・

自分を納得させるために、今、こうしてブログにつづっています。

かれこれ4年くらい使用してきたHD-HGLANがついに永眠してしまいました。

ハード的に死んだわけではなさそうでしたが、どうもソフト的にブリックさせてしまったようです。迂闊ですね。
(具体的な症状としては、HD-HGLANのファームウェアの復元が正常にできなくなってしまい、こうなると一切、手が出せなくなってしまうんですよね・・・。)

HD-HGLANはほぼノンストップで日々働き続けてくれました。

HD-HGLANとの付き合いは辛いことも多かったけど、わくわくして楽しかったことも多かったし、今となっては良い思い出です。

今の気持ちを表すとすれば「ありがとう」の一言に集約されると思います。

そして、今日から、主役が玄箱Proに移ります。

ところで、HD-HGLANをハックして使ってみた感想ですが、使い勝手の点では、残念ながらハックを前提としている正規の玄箱Proの方に軍配が上がると思います。

特に、シリアルコンソール(SCON-KIT/PRO)の存在は非常に大きなものだと思います。これなくしては自由なハックはありえません。

HD-HGLANでもハードウェアハックすればシリアルコンソールに対応できるとはいえ、素人にはかなり敷居が高いのも事実です。

やはり今後は、玄箱Proのような製品に主流が移っていくのでしょうかね。

P.S

http://buffalo.nas-central.org

どうやらこちらも復帰したみたいですね。よかったよかった。

玄箱ProをHD-HGLANの代わりにメインとして使ってみた

え~、もう後先何も考えずHD-HGLANの環境を壊してしまい、やむなく玄箱Proをメインの環境として使用せざるをえなくなったわけですが、第一印象として、処理が重い。

HD-HGLANで余裕でこなせていた同じことを玄箱Proでやらせると非常に重い。

例えば、Webブラウザ → 玄箱Pro(→polipo→squid3)をやらせるとWebブラウザの画面表示がいちいち突っかかる。

慣れの問題かもしれませんが、非常にストレスが溜まります。

ひょっとしてキャッシュデータが肥えていないせいとか。

確かにARM9ベースの玄箱Proの方がPowerPCベースのHD-HGLANより処理能力が低いのは確かなんですけど、消費電力が少ないってところを評価してあげないと酷ですかね。

linkstation/kuroboxの総本山”buffalo.nas-central.org”がシステムダウン中

これはえらいことになりました。

linkstation/kuroboxの総本山?”buffalo.nas-central.org“がシステムダウン中のようです。

これがbuffalo.nas-central.orgにアクセスすると表示されるメッセージ。

image

で、Freenode上にある#linkstationwikiって、IRCのチャネルのことですかね?

http://freenode.net/

う~ん、IRCは厳しいかも・・・。

基本的に、FreeLinkもWebinstallerもbuffalo.nas-central.orgに依存しているので、HD-HGLANに再インストールしようとしてもできなくなるという問題があります。

ちなみに、Debian lennyのアップグレードに失敗して、我が家のHD-HGLANも完全に環境が壊れてしまいました。なんと間の悪い・・・。

HD-HGLAN Debian etch環境でnicocache_nlがやたら異常終了する

これまで、HD-HGLAN Debian etch環境でnicocache_nlをインストールして、快適にニコキャッシュが使えていました。

ところが、最近、やたらnicocache_nlが異常終了するようになり、動画を1つみただけで、nicocache_nlのプロセスが異常終了で落ちてしまいます。

javaが落ちると、java独自のdumpやらcoreやらsnapを吐くのには感心しましたが、内容を見てもさっぱりわかりません。

で、思い当たることといえば、prelink -amRを実行してみたこと。

prelinkを実行する前から、nicocache_nlのプロセスが落ちることがあったので、そのせいとは思いにくいのですが、prelink -auで解除してみました。

prelink解除後、いくつか動画を見てみましたが、ひとまず落ちにくくなったような気がします。しばらく様子を見てみないとわかりませんが、prelinkって結構、危険なのかもしれません。

それと、PowerPC用のJavaですが、ibm-java-sdk-6.0-1.0-linux-ppc.tgzから、ibm-java-sdk-6.0-2.0-linux-ppc.tgzへ、微妙にバージョンアップしてますね。

入手先は、「IBM developer Works」のLinux — Downloadsから、Java SE Version 6の、32-bit iSeries/pSeriesを選択してダウンロードすればOKです。

詳しくは、過去のエントリーを参照。

玄箱ProのMTUを最適化する

ジャンボフレームの設定を行うと通信速度が改善されると思われるので、MTUの値を最適化してみました。

参考:玄箱の高速化

結論を先に書くと、

・周辺の機器がMTU値9000以上に対応していれば、玄箱ProではMTUを9000に設定すると読み込み速度はMAXになる。ただし、書き込み速度が犠牲になる。
(尚、MTUが1500、つまりジャンボフレームが無効だと読み込み速度が1/3程度になる。)

読み込みと書き込み速度のバランスをとると、MTUは5000前後がいい。

・読み込み速度だけ比べれば、玄箱ProとHD-HGLANはほぼ互角。
 (使用しているドライブの差が出るかもしれませんが)

・なぜか書き込み速度が読み込み速度の1/3以下しかで出ていない。
 (HD-HGLANだとそこまでひどくない)

<測定環境>

・ThinkPad T42(設定できるMTUの上限値は16128), CrystalDiskMark 2.2
・玄箱Pro Debian lenny化済み(設定できるMTUの上限値は9500)
・HD-HGLAN Debian etch化済み(設定できるMTUの上限値は7200)

<玄箱ProのMTU:ThinkPad T42のMTU=9500~9200:16128>

なぜか測定できず・・・。

玄箱Pro側では、以下のようなエラーが出まくります。

eth0: Received packet spread on multiple descriptors

玄箱Proにはsambaでアクセスできるのですが・・・。

<玄箱ProのMTU:ThinkPad T42のMTU=9100:16128>

なんか書き込みの方がめためたです・・・。

image

<玄箱ProのMTU:ThinkPad T42のMTU=9000:16128>

image

<玄箱ProのMTU:ThinkPad T42のMTU=8000:16128>

image

<玄箱ProのMTU:ThinkPad T42のMTU=7200:16128>

image

<玄箱ProのMTU:ThinkPad T42のMTU=6000:16128>

image

<玄箱ProのMTU:ThinkPad T42のMTU=5000:16128>

image

<玄箱ProのMTU:ThinkPad T42のMTU=4074:16128>

image

<玄箱ProのMTU:ThinkPad T42のMTU=1500:16128>

image

<参考:HD-HGLANのMTU:ThinkPad T42のMTU=7200:16128>

image

なんて骨体!

Debian etch化しているHD-HGLANで運用しているsquid3とNicoCache_nlがしばらく使っているとプロセスが落ちるという謎の現象が起きるので困っていました。

squid3経由でwebが見られなくなって、dmesgを見てみたところ、なんとメモリ不足でプロセスが落ちてたんですね。

で、freeで確かめてみると、なんと、swapが有効になってない・・・。

で、swapon /dev/(swapパーティションのあるデバイス名)を実行してみると、swaponにならない。

なっ、なんで?

cfdiskを実行してみると、swapタイプのパーティションはある。

mkswap /dev/(swapパーティションのあるデバイス名)

swapon /dev/(swapパーティションのあるデバイス名)

ようやくswapが有効になった。

そっ、それだけかよ!!

なんか猛烈な空虚感に襲われたのでした。

クラッカーに襲撃されてから、パニくりながら復旧したのでミスっちゃったのね。

 

 

LinkStation HD-HGLANのハードウェア構成 その1

HD-HGLAN上でlsusbを実行してみると以下のとおり。

前面のUSBポートにBluetoothのUSBアダプタ、背面に無線LANのUSBアダプタを接続している。

LinkStation:~# lsusb
Bus 003 Device 001: ID 1d6b:0001
Bus 002 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 002 Device 001: ID 1d6b:0001
Bus 001 Device 002: ID 0411:00da MelCo., Inc.
Bus 001 Device 001: ID 1d6b:0002

よく見てみると、Busから001~003の3つがあるが、物理的に接続できるUSBポートは2ポートしか用意されていない。

背面のUSBポートがBus 001、前面のUSBポートがBus 002のようだ。じゃあ残りのBus 003は?ということで、lspciを実行してみる。

LinkStation:~# lspci
0000:00:00.0 Host bridge: Motorola MPC8245 [Unity] (rev 14)
0000:00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
0000:00:0c.0 IDE interface: Silicon Image, Inc. (formerly CMD Technology Inc) PCI0680 Ultra ATA-133 Host Controller (rev 02)
0000:00:0e.0 USB Controller: NEC Corporation USB (rev 43)
0000:00:0e.1 USB Controller: NEC Corporation USB (rev 43)
0000:00:0e.2 USB Controller: NEC Corporation USB 2.0 (rev 04)

PCIバス上に、ホストブリッジ、イーサネットコントローラ、IDEインターフェース、USBコントローラが3つ?イマイチ良くわからない。

LinkStation HD-HGLANがFreeLink+webinstallerで完全復活!

不覚にもクラッカーにHD-HGLANをクラックされてしまったわけですが、FreeLink+webinstallerで完全復活しました。

汚染されているかもしれないHD-HGLANからHDDを取り出し、データをバックアップ。設定ファイル類などは自分が変更したところだけ抽出。プログラムなどのバイナリーデータは全て破棄しました。

気になる動画や静止画などのマルチメディアデータなどは、誤ってプログラムとして実行するなどがない限り実害はないだろうということでそのままコピー。バッファーオーバーフローなどの脆弱性を突かれたりすると怖いですが。

今回は、データのバックアップは大変だったものの、すべてDebianのapt-getに頼って環境を構築したので復旧はかなり楽でした。

外部からソースをとってきて自分でコンパイルしてインストールするよりもスマートというか、設定ファイルなどが統一的な場所に保存されているのでメンテナンスも楽です。なにより、自分で全て設定しようとするとものすごく手間がかかるので、敬遠しがちなソフトも簡単にインストールできるので、むしろ使い勝手はかなり良くなったような気がします。

時代はもう全てパッケージ管理で環境構築ですかね。どうしても必要なものだけ手動でインストールするだけというか。しこしこ自分でコンパイルしてインストールするのが馬鹿らしくなってきます。

Debian化したLinkStation HD-HGLANがクラックされる・・・

非常にショックな出来事なのですが、Debian化したLinkStation HD-HGLANが何者かによってクラックされました。

FreeLinkでDebian化して、apt-getでOpenSSHを導入し、デフォルトの設定のままインターネットに接続された無線LANアクセスポイントからLinkStationのOpenSSHのポートにポートフォワードしたのが原因と思われます。

FreeLinkを導入するとデフォルトのユーザ(root, linkstation)が作成されます。

Debian 4.0 Etchでは、apt-getでOpenSSHをインストールすると、プレインテキスト認証が許可されており、更にrootログインまで許可されているのです。見事にrootユーザが破られてました・・・。

rootユーザはともかく、linkstationユーザのデフォルトパスワードは自明ですから、linkstationユーザでログインし、sudoすると簡単にrootユーザを乗っ取れてしまうわけです。RSA認証のみ許可しておけばこんなことにはならなかったはずですが、運悪くプレインテキスト認証を許可していたため、まんまとやられてしまいました。

これまでの経緯を振り返ると、以下の通りです。

  • 第1段階)7/19(土)早朝。ある日突然、suコマンドでrootになれないことに気がつきました。この時点でLinkStationがクラッカーに犯されていることに気がつくべきでした。
    • てっきり、apt-get update, apt-get updateを実行したことによってrootユーザのパスワードが壊れた、書き換えられたからだと思いこんでいたのですが、浅はかでした。クラッカーがrootのパスワードを書き換えていたのです。
    • /var/log/auth.logを見ると7/19(土)9:57:13に初めてrootユーザでインターネット側からログインされたことがわかります。

Jul 19 09:57:13 LinkStation sshd[22847]: (pam_unix) session opened for user root by root(uid=0)
Jul 19 09:58:32 LinkStation sshd[23196]: (pam_unix) session opened for user root by root(uid=0)
Jul 19 17:28:23 LinkStation sshd[515]: (pam_unix) session opened for user root by (uid=0)
Jul 20 05:03:48 LinkStation sshd[2613]: (pam_unix) session opened for user root by root(uid=0)
Jul 20 05:08:54 LinkStation sshd[3192]: (pam_unix) session opened for user root by root(uid=0)
Jul 20 09:10:53 LinkStation sshd[4061]: (pam_unix) session opened for user root by root(uid=0)
Jul 20 22:55:52 LinkStation sshd[5765]: (pam_unix) session opened for user root by root(uid=0)
Jul 21 12:16:27 LinkStation sshd[6673]: (pam_unix) session opened for user root by root(uid=0)
Jul 21 12:27:32 LinkStation sshd[8751]: (pam_unix) session opened for user root by root(uid=0)
Jul 22 06:32:46 LinkStation sshd[11575]: (pam_unix) session opened for user root by root(uid=0)
Jul 22 06:41:44 LinkStation sshd[11766]: (pam_unix) session opened for user root by root(uid=0)
Jul 22 18:07:13 LinkStation sshd[11999]: (pam_unix) session opened for user root by root(uid=0)
Jul 22 18:33:49 LinkStation sshd[12193]: (pam_unix) session opened for user root by root(uid=0)
Jul 22 18:43:40 LinkStation sshd[12214]: (pam_unix) session opened for user root by root(uid=0)
Jul 22 18:47:36 LinkStation sshd[12300]: (pam_unix) session opened for user root by root(uid=0)
Jul 22 18:57:15 LinkStation sshd[12345]: (pam_unix) session opened for user root by root(uid=0)
Jul 22 21:51:58 LinkStation sshd[13237]: (pam_unix) session opened for user root by root(uid=0)
Jul 22 22:14:32 LinkStation sshd[14863]: (pam_unix) session opened for user root by root(uid=0)

  • 第2段階)7/22(火)深夜。
    • 突然、ウェブサーフィンが一切できなくなりました。よく見ると、LinkStationのイーサネットのLINK/ACTのLEDがものすごい勢いで点滅しており、大量のトラフィックを発生していました。topコマンドでみると、perl udp.plというコマンドを実行しています。このudp.plというのは、どうやらパスワードリストを持っており、手当たり次第にランダムでIPアドレスを生成して、ユーザ名とパスワードに脆弱性のあるホストを探しまくるクラック用のツールのようです。該当プロセスをkillして、大量のトラフィック発生が停止することを確認。
  • 最終段階)7/22(火)深夜。LinkStationの運用を停止。
    • クラッカーに何が仕組まれているかわからないので、LinkStationの運用を即時停止。

アクセスログが残っているようなので、だめもとで犯人追跡を行ってみました。

lastコマンドの実行結果。いろいろなホストからログインしていることがわかります。恐らくこれらのホストもクラックされてしまっているものと思われます。

root     pts/3        89.123.148.235   Tue Jul 22 22:14 – 23:04  (00:49)
root     pts/2        88-149-136-68.st Tue Jul 22 21:51 – down   (01:15)
root     pts/4        88-149-136-68.st Tue Jul 22 18:57 – 19:05  (00:08)
root     pts/3        88-149-136-68.st Tue Jul 22 18:47 – 21:01  (02:13)
root     pts/3        88-149-136-68.st Tue Jul 22 18:43 – 18:47  (00:03)
root     pts/2        88-149-136-68.st Tue Jul 22 18:33 – 20:45  (02:11)
root     pts/1        88-149-136-68.st Tue Jul 22 18:07 – 18:12  (00:05)
root     pts/1        88-149-136-68.st Tue Jul 22 06:41 – 08:58  (02:17)
root     pts/0        88-149-136-68.st Tue Jul 22 06:32 – 06:40  (00:07)
root     pts/1        125.76.236.39    Mon Jul 21 12:27 – 14:38  (02:11)
root     pts/0        125.76.236.39    Mon Jul 21 12:16 – 14:27  (02:11)
root     pts/0        202.63.215.34    Sun Jul 20 22:55 – 22:55  (00:00)
root     pts/0        213.190.208.30   Sun Jul 20 09:10 – 09:10  (00:00)
root     pts/1        host209-53-stati Sun Jul 20 05:08 – 05:14  (00:05)
root     pts/0        89.46.59.111     Sun Jul 20 05:03 – 07:15  (02:11)

で、クラッカーが何をやっていたのかをlastcommコマンドで調べてみました。

クラックしたホスト上で何かを実行しようとwgetを実行していることがわかります。

wget             S   X root     ??         0.99 secs Tue Jul 22 22:16
wget                   root     ??         0.08 secs Tue Jul 22 18:57
wget                   root     ??         0.14 secs Tue Jul 22 18:48
wget                   root     ??         0.72 secs Tue Jul 22 18:44
wget                   root     ??         0.02 secs Tue Jul 22 06:45
wget                   root     ??         0.04 secs Tue Jul 22 06:44
wget                   root     ??         0.04 secs Tue Jul 22 06:42
wget                   root     ??         0.03 secs Tue Jul 22 06:34

クラッカーがviでごにょごにょしてます。

vi               S     root     ??         1.44 secs Sun Jul 20 05:11
vi               S     root     ??         0.01 secs Sun Jul 20 05:11

で、/root/.nano_historyを見ると、viが使えるか試したようです。

LinkStation:~# less .nano_history
testing

/root/.bash_historyもとっておけば良かったのですが、わりと短いサイクルで古いログが消えていくようなので今となっては良くわかりませんが、サーバ内のファイルの改ざんや情報漏洩など、あまりたいしたことはされてないようです。

クラッカーがperl udp.plを動かし始めたのは7/22(火)になってからのようです。2.5時間ほど実行されていたことがわかります。

perl                 X root     ??       1330.08 secs Tue Jul 22 22:21
perl                 X root     ??       7877.76 secs Tue Jul 22 06:47

クラッカーがudp.pl以外に何かしようとしていたらしく、いかの残骸が/rootに残っていました。

  • psybnc.tar.gz(IRCでなりすまし接続を行うためのproxyサーバ)
  • unixcod.tgz(rootkit?)

unixcodがrootkitだとすると、かなり物騒なもんを仕込もうとしていたようです。

ということで、セキュリティについて勉強し直そうと思います。

nscd ネームサービスキャッシュデーモン

ネームサービスキャッシュデーモン nscd とは

ネームサービスキャッシュデーモン(nscd)はDNSやNISなどの一般的なネームサービスのデータベースを保持し、passwd、group、hostsファイルなどの情報をキャッシュする。

%d人のブロガーが「いいね」をつけました。