(IT) 新手の攻撃とその対策

<現象編>
先日(2015/10/19)の攻撃は、中国やマレーシアなどいろいろな国のマシンから
一斉に、このblogが乗ってるwebサーバーの「0jejhcec65c24dslii.com」と
いう名前のサイト(当然存在しない)の「#320」みたいなありもしない
ページ内リンクへのアクセスがしこたま来てた。
access_logはこんな感じ。

117.169.1.140 – – [19/Oct/2015:19:51:54 +0900] “GET /#101 HTTP/1.1” 500 263 “http://0jejhcec65c24dslii.com” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)”
177.99.87.146 – – [19/Oct/2015:19:52:07 +0900] “GET /#432 HTTP/1.1” 500 263 “http://0jejhcec65c24dslii.com” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)”
124.200.250.22 – – [19/Oct/2015:19:51:50 +0900] “GET /#22 HTTP/1.1” 500 263 “http://0jejhcec65c24dslii.com” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)”
114.26.14.87 – – [19/Oct/2015:19:52:07 +0900] “GET /#345 HTTP/1.1” 500 263 “http://0jejhcec65c24dslii.com” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)”
190.42.61.126 – – [19/Oct/2015:19:52:08 +0900] “GET /#326 HTTP/1.1” 500 263 “http://0jejhcec65c24dslii.com” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)”
91.121.153.214 – – [19/Oct/2015:19:51:54 +0900] “GET /#237 HTTP/1.0” 500 263 “http://0jejhcec65c24dslii.com” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)”
113.204.212.50 – – [19/Oct/2015:19:51:50 +0900] “GET /#225 HTTP/1.1” 500 263 “http://0jejhcec65c24dslii.com” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)”
117.169.6.138 – – [19/Oct/2015:19:51:39 +0900] “GET /#220 HTTP/1.1” 500 263 “http://0jejhcec65c24dslii.com” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)”

ログを更に見てみると、数分後にこんなエラーが1秒に1回出てた。
存在しないページ内リンク(アンカー)を探しに行くと、apacheの子プロセスが
起動されて、CPUやらメモリやらの資源を食い潰しているのか。

::1 – – [19/Oct/2015:19:55:01 +0900] “OPTIONS * HTTP/1.0” 200 – “-” “Apache/2.2.15 (CentOS) (internal dummy connection)”
::1 – – [19/Oct/2015:19:55:04 +0900] “OPTIONS * HTTP/1.0” 200 – “-” “Apache/2.2.15 (CentOS) (internal dummy connection)”
::1 – – [19/Oct/2015:19:55:04 +0900] “OPTIONS * HTTP/1.0” 200 – “-” “Apache/2.2.15 (CentOS) (internal dummy connection)”
::1 – – [19/Oct/2015:19:55:05 +0900] “OPTIONS * HTTP/1.0” 200 – “-” “Apache/2.2.15 (CentOS) (internal dummy connection)”
::1 – – [19/Oct/2015:19:55:06 +0900] “OPTIONS * HTTP/1.0” 200 – “-” “Apache/2.2.15 (CentOS) (internal dummy connection)”
::1 – – [19/Oct/2015:19:55:07 +0900] “OPTIONS * HTTP/1.0” 200 – “-” “Apache/2.2.15 (CentOS) (internal dummy connection)”
::1 – – [19/Oct/2015:19:55:08 +0900] “OPTIONS * HTTP/1.0” 200 – “-” “Apache/2.2.15 (CentOS) (internal dummy connection)”
::1 – – [19/Oct/2015:19:55:09 +0900] “OPTIONS * HTTP/1.0” 200 – “-” “Apache/2.2.15 (CentOS) (internal dummy connection)”
::1 – – [19/Oct/2015:19:55:10 +0900] “OPTIONS * HTTP/1.0” 200 – “-” “Apache/2.2.15 (CentOS) (internal dummy connection)”

error_logも一応確認したけど、あまりめぼしいものがなくて、タイムスタンプが
近いものとしては、こんなのだけかな。

[Mon Oct 19 19:53:01 2015] [error] server reached MaxClients setting, consider raising the MaxClients setting

<対策編>(Special Thanks to「インフラ部」)
(1)意図しない名前でアクセスされた場合、反応しないための記述。
httpd.confのVirtualHostの先頭にdummyエントリを追加。
今回の大量アクセスは、IPアドレスで到達するけど、ターゲットのサーバー名が
「0jejhcec65c24dslii.com」という存在しないサーバー名宛てに来てたので。

#
# Use name-based virtual hosting.
#
NameVirtualHost *:80
#
<VirtualHost _default_>
ServerName dummy
DocumentRoot /var/www/dummy
<Directory /var/www/dummy>
Order Allow,Deny
</Directory>
</VirtualHost>
<VirtualHost *:80>
    ServerAdmin “anonymous@hogehoge”
    DocumentRoot “/foo/bar”
    ServerName www.ryoshr.net
(続く・・・)

(2)「#」で始まるページ内リンクを動作させない。
.htaccessでもいいみたいけど、httpd.confに追記。

<VirtualHost *:80>
    ServerAdmin “anonymous@hogehoge”
    DocumentRoot “/foo/bar”
    ServerName www.ryoshr.net
    ErrorLog logs/hogehoge_error_log
    CustomLog logs/hogehoge_access_log combined
    RewriteEngine On
    RewriteCond %{THE_REQUEST} /#
    RewriteRule .* – [F,L]
</VirtualHost>

(3)その他パラメータを調整。
MaxClient値を半分に(256→128)
MaxRequestsPerChild値を2.5倍に(4000→10000)

(4)Fail2Banをインストール

間違ってたら、ご指摘ください。

(IT) オレ、Facebookでゲームしないから。(ブロックする方法)

もうね、カジュアルなやつでもゲームはまったくしないんですがね。
電車乗って見回すと、結構みんなゲームしてて驚くわけで。
(だから、おっさんの感覚は一般から遠のいてくんだよな、きっと)

そんなオレにもFacebookでゲームへの招待とか来るわけで。
先方がどういう操作をしたら送られるのか、何もしてないのに
勝手に送ってくるのかはよくわからない。

無視してれば、被害はないんだけど「同じゲームの招待が何回も
くるのがウザいんだよー💢」というあなたのために積極的な拒否と
してのブロックの方法を紹介。

お知らせのゲームへの招待を選択するとこんな画面になるよね。
お誘い

ここで拒否すれば、一応それで大丈夫なんだけど、別の人から
また送られて来るかもしれない。
そこで、検索して見つけてブロックしてやろうと。

キャンセルした後行くアプリの画面の検索枠の中で対象となる
ゲームの名前を検索。
検索

候補が出てくるので、そこから選んだらアプリの紹介ポップアップが
上がってくる。
ブロック

ここでブロック。

確認

ブロックを承認して完了。
お知らせ画面からも、招待が消えてることが確認できるはず。
あーさっぱりした。

(IT) 【注意喚起】Gmail(Google Apps)をターゲットにしたスパム

最近では会社のメールもGmailというかGoogleAppsにしているところ、多いよね。
学校もそうしているところもある。
(全然関係ないけど、京都大学のこういう事例があったのも理由になる?のか?)

そうすると、Gmailをターゲットにしたspamというかいたずらが来るので、
注意喚起の意味も込めてその手法と駆除手順を共有。
是非、身近な人に「この画面で『承認する』は押してはダメよ」と
お伝え頂ければと。

題名とか、見かけ上の差し出し人はいろいろだけど、こんなメール来る。
flipora_01

見かけ上は.co.jpで終わるアドレスから来ているように見えるけど、本当に
出して来てるのは info@flipora.com というアドレスということがわかる。
用心深い人なら、これを見ただけで、メールを削除するはず。

「知り合いから来てるし、なんか新しいSNSでも始めたのかな、
 あの人、そんなにネットに詳しそうになかったけど、ま、いいか」と
『承認する』を押しちゃううっかりさんもいるかと思う。じつは、これ、
『辞退する』を押してもその後の動作は同じ。
とあるSNSの会員登録画面へ飛ばされつつ、GmailかGoogleAppsを使ってる人の
場合は、こんなポップアップが開く。
どっちでもない人は、何もおきない。
(そのSNSに登録したらどうなるかは知らない)

Flipora_02

どんなうっかりさんでも、さすがにここで『許可』は押さないと思うんだが、
超超超うっかりさんは押しちゃうみたいね。
よく見て。

「メールのメッセージと設定の表示をこの相手に許可します」え?
「Googleでのユーザーの把握を許可します」いや、マジで?
「メールアドレスの表示を許可します」お、おう。
「アドレス帳や連絡先情報の管理を許可します」きゃーーーーっ!

絶対だめでしょ。
これ、『許可』した瞬間、そのアカウントのアドレス帳、全部持ってかれてます。
そこでゲットしたアドレス帳の中にあったアドレスに対して、また同じメールが
飛ぶわけです。

超超超うっかりさんはこう言います「いや、アタシ、アドレス帳使ってないから」
いやいやいや、Googleさんは一度でもメールを送受信した相手は、
勝手にアドレス帳に登録しちゃってるんですよ、奥さん。
だから、送受信履歴ももってかれてるわけですよ。
そっちの方が実績あるわけだから、
spam送るにはちょうどいいしな。
そしてまた拡散していくわけです。
持って行かれたアドレス帳に入ったアドレスに対して同じ招待メールが。
アドレス帳に登録者がたくさん入ってるMLが入ってたりしたら・・・、
背筋寒くなるよね。

寝ぼけ半分にうっかり押してしまったような記憶がうっすらある方は、この手順で。
(1)「Gmailのアカウントの管理」にアクセスし、
「接続済みのアプリとサイト」をクリック
アカウント管理

(2)「アプリを管理」をクリック
アプリを管理

(3)接続されているアプリやサイトの一覧が表示されるので、
「Friend Connect」や「Flipora – Connect with Friends」のような項目があった場合には
これを削除。
アプリの削除

ここ以外にもChrome,safari,IEなどのブラウザの拡張機能にFlipora関連のものがあれば削除、
PC本体にもFlipora関連のプログラムがあったら、削除。

ただ、これ、削除しても、とっくにアドレス帳は持ってかれてるので、
懺悔なさい。

(実害らしい実害がないのが唯一の救い)

(IT) WordPressターゲットにした攻撃を受けた

いや、このサーバーではなくて、仕事関係のね。
何か荒らされるとかそういうことでなくて、サーバーに負荷をかけ続けられて、
いずれは、サーバー上のDB(mysqld)とかWebサーバー(httpd)が耐えかねて
落ちる、ということになる。愉快犯なんだろうなあ。
WordPressのピンバック機能のためのプログラムxmlrpc.phpへの大量の
アクセスをして、サーバーを不安定に陥れよう、という攻撃(いたずら?)

どんな対策をしても攻撃というか大量アクセスは来るので、防ぎようはないんだけど、
当該のプログラム(xmlroc.php)の動作を制限するなどして、
「このサイトは攻撃しても無駄だ」と思わせてアクセスが減るのを待つしか
ないというのが、なんとも歯がゆいところだが。
対策は専門の方がたくさんエントリをかかれているので、それを参考に。
Google先生に「WordPress xmlrpc.php 対策」とか聞いてみればたくさん出てくる。

ちなみに攻撃の例がこれ。某サーバーのアクセスログ。
xmlrpc.php
これで大体、30秒分。これが延々と10メートルくらい続く。
まあ、よほど性能のいいサーバーでないと、程なく死ぬよね。

アクセス元は中国かとおもいきや、実はアメリカ。まあ、アメリカからもこういうの
多いのは確かなんだけどね。テキサス州ダラスだって。
Softlayerというクラウド業者のサーバーから来てる。
ちなみに、別の仕事の別のサーバーも同じアクセス元(微妙にIPは違うけど)だった。
ちゃんと調べてないけど、悪い事するには都合のいいサービスなのかもしれない。
Softlayerというところ。なんとIBM様とも提携なさっておられるとか。

気のつけようもないけど、対策だけはきっちりやっておいた方がいいですよ。
まずは、WordPress本体やPluginを最新に保つことは基本ですね。

(IT) 携帯水没!復旧の手順は。

ちょいちょいFacebookのタイムラインで携帯を水没させる人を見る。
オレもドラゴンボートが転覆して、スマートフォン2台を山下公園の
海に浸してダメにした経験がある。塩水だったので、このときは
復旧せず。

落ちた先の水に塩分がない、というか電解性がないなら、復旧の
可能性がないわけではない。
毎回メッセージしてたけど、ここに書いておけばいいことに気が付いた。

(1)とにかく電源を即off。
→内部に水分が残った常態で通電させるのがもっともダメ。
(2)外せるものはすべて外す。SIMカード、SDカード、バッテリー。
→内部からの水分の出口の確保をする意図。
(3)タオルに包んで振り回す。
→まずは強制的に水分を外に排出させる。
※この時、室伏のように回転さるが、投げないことが肝要。
(4)ドライヤーで乾かす。
(5)乾燥剤(シリカゲル)の中に一昼夜以上沈めて、さらに乾燥。
→お米も乾燥剤の代替品になるとのことなので、お米でも可。
(6)神に祈りながら電源投入。

絶対復旧するとは言えないが、復旧する確率は少しあがると思うよ。