Skip to content

きてるきてる

自宅サーバーのapache2ログを見ていたら、こんなのが残っていた。


- 77.79.212.111 - - [07/Aug/2013:23:09:13 +0900] "GET /phpmyadmin/ HTTP/1.1" 404 466 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- 77.79.212.111 - - [07/Aug/2013:23:09:14 +0900] "GET /phpMyAdmin/ HTTP/1.1" 404 467 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- 77.79.212.111 - - [07/Aug/2013:23:09:15 +0900] "GET /PMA/ HTTP/1.1" 404 462 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- 77.79.212.111 - - [07/Aug/2013:23:09:15 +0900] "GET /pma/ HTTP/1.1" 404 462 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- 77.79.212.111 - - [07/Aug/2013:23:09:16 +0900] "GET /admin/ HTTP/1.1" 404 463 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- 77.79.212.111 - - [07/Aug/2013:23:09:16 +0900] "GET /dbadmin/ HTTP/1.1" 404 464 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- 77.79.212.111 - - [07/Aug/2013:23:09:17 +0900] "GET /sql/ HTTP/1.1" 404 462 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- 77.79.212.111 - - [07/Aug/2013:23:09:18 +0900] "GET /mysql/ HTTP/1.1" 404 463 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- 77.79.212.111 - - [07/Aug/2013:23:09:18 +0900] "GET /myadmin/ HTTP/1.1" 404 464 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- 77.79.212.111 - - [07/Aug/2013:23:09:19 +0900] "GET /phpmyadmin2/ HTTP/1.1" 404 467 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- 77.79.212.111 - - [07/Aug/2013:23:09:20 +0900] "GET /phpMyAdmin2/ HTTP/1.1" 404 468 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- 77.79.212.111 - - [07/Aug/2013:23:09:20 +0900] "GET /phpMyAdmin-2/ HTTP/1.1" 404 469 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- 77.79.212.111 - - [07/Aug/2013:23:09:21 +0900] "GET /php-my-admin/ HTTP/1.1" 404 468 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- 77.79.212.111 - - [07/Aug/2013:23:09:22 +0900] "GET /sqlmanager/ HTTP/1.1" 404 467 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- 77.79.212.111 - - [07/Aug/2013:23:09:22 +0900] "GET /mysqlmanager/ HTTP/1.1" 404 469 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- 77.79.212.111 - - [07/Aug/2013:23:09:23 +0900] "GET /p/m/a/ HTTP/1.1" 404 463 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- 77.79.212.111 - - [07/Aug/2013:23:09:24 +0900] "GET /php-myadmin/ HTTP/1.1" 404 468 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- 77.79.212.111 - - [07/Aug/2013:23:09:24 +0900] "GET /phpmy-admin/ HTTP/1.1" 404 468 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- 77.79.212.111 - - [07/Aug/2013:23:09:25 +0900] "GET /webadmin/ HTTP/1.1" 404 465 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- 77.79.212.111 - - [07/Aug/2013:23:09:25 +0900] "GET /sqlweb/ HTTP/1.1" 404 463 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- 77.79.212.111 - - [07/Aug/2013:23:09:26 +0900] "GET /websql/ HTTP/1.1" 404 463 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- 77.79.212.111 - - [07/Aug/2013:23:09:27 +0900] "GET /webdb/ HTTP/1.1" 404 463 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- 77.79.212.111 - - [07/Aug/2013:23:09:27 +0900] "GET /mysqladmin/ HTTP/1.1" 404 467 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- 77.79.212.111 - - [07/Aug/2013:23:09:28 +0900] "GET /mysql-admin/ HTTP/1.1" 404 468 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"

これらは全て、phpMyAdminの脆弱性を狙った攻撃のための下調べをされた痕跡と思われる。phpMyAdminで使用している可能性のあるURLにアクセスを試み、phpMyAdminが使用されているかどうかを調べようとしているらしい。幸いなことに、私の下宿にあるサーバーではphpMyAdminを使用していない。上のログでも全てに404を返している。この様な下調べをしているということは、phpMyAdminを使用する場合、WEBサーバー上の置き場を容易に推測されない名前のディレクトリ下にするだけで、受ける攻撃を減らせる可能性あると思われる。

Posted 12 8月 2013 § ‡ ° Tagged: , ,

USBRH-FGを使ってCSV形式で自動的に記録する

　USB接続の温湿度計 (USBRH-FG)を購入してから約10日経った。測定データもそれなりに集まったので、気づいた点などを記したい。

　私の使用環境であるが、Raspberry Piのtype Bに繋いでいる。OSはRaspbian 3.6.1、使用ドライバはusbrh。インストール情報等はネットを探せばゴロゴロしてる。

　usbrhは、そのまま実行すると、

pi@SnakeLog ~ $ sudo usbrh
32.48 79.59

のように、温度 (摂氏)と湿度 (%)をそれぞれ単位なしのスペース区切りで出力する。-vをつけて実行した場合は、

pi@SnakeLog ~ $ sudo usbrh -v
Temperature: 32.50 C
Humidity: 79.64 %

となる。

　そこで、まずはusbrhを使って、定期的に温度と湿度を記録させるシェルスクリプトを作成した。最終的にRを使ってグラフを描くため、形式は.csvにする。ちなみに、私の環境ではsudoを付けないと値が取得できない。Rasbianではsudoをつけたコマンドが、デフォルトのユーザーpiでパスワードの入力を求められること無く実行できてしまう。

#!/bin/sh
### record date and temperature in csv format ###

dir="/home/pi/temperature"
data=`sudo usbrh | sed s/\ /,/g`
date=`date +"%H:%M"`
logfile=`date +"%Y%m%d"`
todaylog="${dir}/${logfile}.csv"
output="$date,$data"
echo $output >>$todaylog

　これをcronに登録して実行させると、20130802.csvというような名前のファイルに、

......
18:00,32.51,52.47
18:05,32.47,52.41
18:10,32.50,52.47
18:15,32.47,52.41
18:20,32.46,52.50
......

といった具合に記録がなされていく。私は5分間隔で実行させているので、毎日、288行の.csvファイルが1つ(約5.2KB)作られる計算になる。

　ところが、何日かこれを動かしていると、ときたまおかしな値が記録されているのに気づいた。

20130801.csv

......
20:15,-40.00,-4.25
......

20130806.csv

......
18:10,-40.00,-4.25
......

　今のところ、丸1日分のデータがある9日分で2回、つまり288*9=2592回のusbrhコマンド実行で、2回分の測定値がおかしくなっている。サンプルが2つしかないので確かなことは分からないが、2回とも記録されている温度・湿度の値が同じなので、何らかのエラーにより正常な値が取得できない場合、-40.00と-4.25という値が出力されるのだろか。明かにエラーと分かる値を吐いた時は前回のデータを複製するとか、スクリプトに処理を追加する必要がありそうだ。

Posted 07 8月 2013 § ‡ ° Tagged: , ,

たいしたことないぜまったく

ASCII.jp：あのバニラコーラが10年の時を経て復活！

　上の記事で紹介されていた、Coca-Cola Vanillaを飲んでみた。ASCII.jpの宣伝に流されて商品を購入してしまうというのも腹立たしいが、記事中に書かれていた、「甘過ぎっすわ！」「こんな甘いのよく飲めるね。」という記者のコメント、そして極めつけの最後の一文、

「かなり甘いので、甘いモノが苦手な人は注意しよう。」

これを読んでは引き下がれない。そう、私は激甘好きなのだ。普通の人が甘すぎて食べれない、というレベルのスイーツをこれまで幾つも食し、味わってきた。ただ、そんな私が過去に”激甘”認定したものはそう多くない。しかもその大半が、個人の手作りによるものだ（母親の作った砂糖がジャリジャリするアイスクリーム、自分で炊いたがザラメを入れすぎたぜんざい、等）。市販の菓子で、あるいは複数店舗展開している料理屋のデザートで、私が認める激甘なモノを見つけるのはそう簡単ではない。何といっても、私が激甘と感じるレベルというのは、人によっては気分が悪くなるレベル、無理をしないと食えないレベルなのである。あまりの甘さに喉が焼け付くような感覚を得、体内に流し込めば血糖値がグンッと上昇する、こうでなくては激甘とは呼べない。ちなみに私は幼少の頃より、コーヒーシュガーをポリポリ食べたり、あるいは5倍希釈用のカルピス原液を好んで舐めたり、はたまた和菓子用の黒蜜をボトルから直接飲んだり、と色々やってその度に母親から怒られていた。

　さて、前置きが長くなったが、Coca-Cola Vanillaの話に戻ろう。簡潔に述べると、これは大した甘さではない。通常のコカコーラに毛が生えた程度である。炭酸を完全に抜いて飲めば多少甘くも感じるだろうが、それでもおそらく激甘認定には至らないであろう。「甘すぎ」という評価こそ、甘すぎである。

　ではどんなものが激甘認定に相応しいだろうか、と考えてみると、飲料で言えばやはりカルピスが手軽である。本来5倍希釈すべきところを2～3倍にすればある程度甘くなる。飲料以外で言えば、王道は小豆餡＋黒蜜だと思う。あの絡みつくような甘さは病みつきになる。より簡単なのは明治の板チョコでハイミルクってやつをやわらかなる温度にして食べることだろうか。これもドロッとしたチョコレートの甘さが喉を熱くしてくれる。

Posted 06 8月 2013 § ‡ ° Tagged: , ,

安心・信頼・実績のFAS-NET

[2013/07/05]
　私が過去に所属していた団体([A]とする)がレンタルサーバーを借りているFAS-NETから、ウイルス感染の通知メールを受けた。要約すると以下の内容。

・ウイルスが発見されたのは、[A]が借りてるドメイン下に置かれたとある.cgiのファイルで、発見されたのは7/3。
・FAS-NETはサイトの公開用ディレクトリにあった全てのファイルを、非公開な別のディレクトリに移動した。
・FAS-NETは、FTPパスが流出している可能性を考慮し、FTPパスワードを変更、このメールにて新しいパスワードを通知する。

[2013/07/10]
　こちらからFAS-NETに問い合わせ。要約すると以下の内容。

・FTPパスの流出について確認するため、ログイン履歴の分かるログが欲しい。
・当方のサイトから被害を受けた可能性のあるアクセスについて把握するため、ウェブサーバーのログも欲しい。
・ウイルスの発見方法は？そのウイルスは同じサーバーの他アカウント下で発見されていないのか？

[2013/07/17]
　2013/07/10に問い合わせた内容に返信が無いので、再度送信。

[2013/07/18]
　FAS-NETから回答。要約すると以下の内容。

・該当のログはログローテーションで既に消えてしまった。
・ウイルス発見は、海外のサービス (http://www.cyscon.de/)からの通報。
・今回のウイルスは同一サーバー内では[A]のアカウント下だけで発見されている。

　……以上が大体の顛末。実際には[A]の担当者が多少とんちんかんな内容で途中途中問い合わせをしたりもしてる。今回の事の発端は、情報が限られているので予想するしかないが、[A]の使用していたアカウントのパスワードが外部に漏れて、cgiファイルが書き換えられ、ウイルス（悪質なページ）判定されるに至ったか、あるいは担当者の使用している端末がウイルスに侵され、書き換えられたローカルのファイルをそれと知らずにアップロードしてしまった、のどちらかだろうと思う（私は前者だと思うが）。[A]担当者のミスで、FAS-NETが隔離してくれたサーバー上のファイルを消してしまい、ウイルス判定された.cgiがどう改変されていたか確認不能になるなど、お世辞にもこちらの対応もよくなかったのだが、それにしても、今回の件に関するFAS-NETの対応には疑問を感じる。なぜ、ログを出せないのか、ということである。

　ログローテーション……、それは分かる。レンタルサーバーを運営していれば、サーバーは膨大な量のログを吐くだろう。それを永久に保存しておくことは難しい。一定期間経てばそりゃ消すだろう。とはいえ、今回の件について言えば、FAS-NETはウイルス発見の通知を海外から受け、それを[A]にもメールで知らせてきているのである。しかも、FTPログイン情報が第三者に流出している可能性を踏まえ、パスワードの変更まで行っている。私なら、というか普通なら、この時点で不正なアクセスがあった可能性について調査すべく、ログを洗い出し、保存しておくはずである。それをしないのは、サーバー管理者としておかしい。そしてログが消えるタイミング、これは環境によってデフォルトの値が違うし、意識的な設定もしていると思うのだが、これが2,3日後ということはまぁ無いだろう。普通、短くても1週間である。これより短いサイクルでサーバーからログを消すなら、ログはバックアップを取るはずである。今回の場合、ウイルス感染をFAS-NETが通知してきたのが7/5で、「ログをよこせ」とこちらから要求したのが5日後の7/10である。で、最終的にFAS-NETが「ログはもう消えちゃった」と返信をよこしたのは、最初の通知から13日後の7/18である。私が何を言いたいか、懸命な読者は気づくはずである。まぁ実際には、7/10に問い合わせた時と7/17に問い合わせたと時は、窓口（フォームとかアドレスとか）が違っていたし、7/10に問い合わせた時の窓口は、FAS-NETが推奨するものでは無かったのかもしれない。現場では、メールチェックといったアナログな過程でミスが起こることもままあるだろう。

　と、色々考慮しても、今回のFAS-NETの対応にはいろいろと不満がある。だって、FTPのパスワードが流出したかも知れないからパスワード変えといた、と言われたところで、今後同じことが起こる可能性があるのかどうか、まったく判別できないじゃないか。ログが手に入ったところでそれが分かるか、と言われるとまぁアレなのだが、例えばFTPログインが海外から、あるいはどっかのプロキシを通してなされていた場合、明らかに不正ログインされた痕跡と見ることができるわけだ。その日時と、パスワードを知っている人間の行動記録を辿れば、パスワードの流出の経緯についても推測が可能になるかもしれない。あるいは、パスワードを変更してからすぐにまた不正なアクセスや改竄がなされた場合は、犯人が身内にいるか、パスワードの通達経路に問題がある、と分かるわけだ。こういう断片的な情報すら、ログの開示がなされないと、一切分からないわけで、今後のこのサーバーを利用しつづけるのに不安が生じるのは当然であろう。

Posted 01 8月 2013 § ‡ ° Tagged: , ,

こんなに巡回してくれるとは光栄だな

　自宅サーバーでApacheのログが増えてるな、と思ったら、「へびろぐ」のせいだった。じゃあアクセスが増えてるのか、というと、人間によるアクセスではなく、ロボットだった。

- 209.85.238.182 - - [01/Aug/2013:05:16:17 +0900] "GET /snakelog/show.php?path=./cam/13/07/24/1510_480p.jpg HTTP/1.1" 200 1510 "-" "DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)"

とか、

- 119.235.237.19 - - [01/Aug/2013:05:10:19 +0900] "GET /snakelog/cam/13/07/10/0213_480p.jpg HTTP/1.1" 200 18690 "-" "Yeti/1.0 (NHN Corp.; http://help.naver.com/robots/)"

みたいなのが記録に残る。前者がGoogleによるもので、後者はNaverだ。へびろぐでは、1分に1ページのスピードでページが追加され、画像も追加される。そのため、頻繁にロボットが巡回してくるらしい。Googleのログだけで一週間に17000行、Naverの方は3000行分くらい。別にGoogleとNaverのロボットが無駄足を踏もうが構わんのだが、うちのサーバーに大量のログが残ってしまうこともあり、対策することにした。単純にrobots.txtを追加して、URLへの引数付与で自動生成されるページについては巡回を禁止した。

Posted 01 8月 2013 § ‡ ° Tagged: ,