[トラブルレポート] サーバーコマンドで打ってはいけないファイル名 「./.*」

error-102075_1280
LINEで送る
Share on GREE
Share on LinkedIn

サーバー設定を行っている時に、root権限でユーザー管理を行う事は少なくないと思う。

そんな時に犯しやすいミスを体験したので、ご報告です。

状況

サービスサーバーの構築を行なっている時に発生した事象です。
サーバーのOSはdebianで、とあるバックアップバッチを外部サーバーから実行する時に、www-data権限で受付ないといけなかったので、ユーザーアカウントwww-dataに対して、鍵登録を行う作業をしていました。

やりたかった内容

www-dataアカウントのrootディレクトリである。
/var/www/
に対して、
.ssh/authorized_keys
ファイルを設置して鍵を登録するという内容でした。

事象

作業したのは、別のメンバーなんですが、このサーバーで外部監視エラーが発生し始めました。

とりあえず、アラートの発生しているサーバーに対してpingコマンドを叩いてみるとちゃんと反応があり、サーバーが生きていることは確認できた。

この外部監視はsshコマンドを使って内部データを取得するモノだったので、sshアクセスを試みたトコロ、全てのアカウントでアクセスが出来ないことを確認。

nmapでポートが空いているか調べてみたが、22番ポートは空いている事も確認。でもログインできない・・・

一体何が起きているか全く不明でした。

作業していたメンバーに聞いても、/var/www/.ssh/authorized_keysファイルを設置しただけだという。

現地へ向かって確認

sshログインできないので、現地へ向かって確認するしかないので、仕方なく、IDCへ直行した。

僕の経験上、想定できる原因は、

・sshd_confを書き換えてしまって、どこかのタイミングでrestartされてしまった。
・/etc/passwdファイルが壊れてしまった。

という事ぐらいしか思い浮かびませんでした。

原因が判明!!

現地で、調べてみたところ、sshアクセスを行なったトコロ、

という階層のparmissionが権限を持っていないというエラーが出力されていたので、確認したところ、この階層がwww-data権限になってました。
別サーバーで確認したところ、rootになっているのが正解です。

いったいどういう原因でこんな原因になったのか調査してみました。

ちなみに、/var/を含む以下のディレクトリが全てwww-data権限に変更されていました。

とりあえず、作業をしていたrootユーザーのhistoryを調査してみたところ、違和感のあるコマンドがあったので、調査してみた。

上記を実行すると、何故か/var以下が全てwww-data権限に、ファイルとフォルダが書き換えられてします。

初めは何故そんな結果になるのかがわからなかったのだが、lsコマンドを叩いてみて、理解できた。

どうやら、「.ssh」を対象にしようと思って、「.*」というファイル名でひっかけようとしたところ、「.」と「..」も引っかかってしまったというのが原因だったようです。

そして、意図しないシステムファイルの権限まで変更してしまい、今回のトラブルになってしまったようです。

今回の事象を回避できたポイントとしては、作業を行なった対象ファイルをlsコマンドでちゃんと事前確認するか、行なった後で、システムファイルに変更されていないか確認する以外にはありませんでした。

ピンポイントでの確認としては、
/var/run/sshd
階層の権限がrootになっている事を確認しましょう。

やってはいけないポイント

システムファイルである「.」で始まるファイルやディレクトリに対して「.*」という指定をすると、2階層上まで全てが実行されてしまうという認識を行い、ちゃんとファイル・フォルダ名で指定する事を認識して置く以外にはありません。
面倒臭がらずに、ちゃんと階層名を打ち込む事が重要ですね。
「tab」キーを使ってでもいいので、確実に打ち込みましょう。

知らずにバッチファイルなど作ってしまったらと考えたらぞっとしますね。

まとめ

こういった知らないとトラブルになるコマンドなどはまだまだありそうです。
サーバーエンジニアを調査して、メモって行きたいと思います。

知ってる人いたら、教えてください。

Leave a Reply

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です


*