★AWSの設定を間違ってつながらなくなったときの対処

設定を間違えて、AWS上のLinuxサーバにつながらなくなったときの対処方法です。私はiptables設定間違えたとき、この方法で復活できました。

繋がらないサーバの他にもう1個インスタンスを使います。繋がらないほうのサーバをtroublesv、救済用のサーバをrescuesvとします。当然のことながらrescuesvはつながる前提。なおrescuesvのほうは、電源いれっぱなしでも作業できるようです。

1.AWSコンソールのEC2設定にログインする

2.つながらなくなったインスタンス(troublesv)を電源off (どうせ繋がらないしブチる！)

3.左のメニューから「ボリューム」を選択

4.troublesvのHDDを選んで、ボリュームのデタッチを行う

5.救済用のサーバ(rescuesv)にボリュームをアタッチする (デバイス名が /dev/sdf のように表示されます)

6.rescuesvでマウント (# mount -t ext4 /dev/xvdf1 /mnt )

7.設定ミスを修正 (# vi /etc/sysconfig/iptables )

8.マウント解除 (# umount /mnt)

9.ボリュームのデタッチ

10.troublesv にボリュームをアタッチ。名前を /dev/xvda にする

11.電源いれれば復活！

なお、Elastic IP持っていたため (未使用として) トラブル対応の時間分だけ課金されます…orz

★AWS上でのiptables

私のサーバでは、一部のサービスをJP Regionからの接続に限るため、iptablesを使ってます。

EC2のセキュリティグループを使わない理由は…

$ sudo iptables -L -n | wc -l
4235

ルールの最大数はデフォルト50、申請しても250ですから、とても無理なのです。1つのインスタンスに複数のセキュリティグループ割り当てられるとはいえ、何かトラブルが起きそうな予感しかしないですし…

なんでそんなにルール数が多くなるかというと、APNICが公開しているIPの割当表から、JPだけを許可するルールを生成しているからですね。

TCP wrapperで行うことも考えたのですが、dovecot等のアプリが対応してなかったこと、逆引きはやろうと思えば.jpを名乗るのは容易いこと、で、今回はTCP Wrapper案はパスしました。

まあ、変換して INPUT rule を作るのは何のトラブルもなく…

トラブルは OUTPUT のほうで起きました。

今回サーバでは、ホントにサーバとしか使わないので、通常時にサーバ側からコネクション貼るのは SMTP のみです。(通常時以外でも、メンテ時に yum updateのコネクション程度です)。そこで

# sudo iptables -A OUTPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
# sudo iptables -P OUTPUT DROP

こうやって、sshが繋がることを確認。

再起動

……あれ？　繋がらない

昨日の日記のやりかたで、設定を戻して、iptables の設定をくまなく見てみる。何もない…

3way handshake の設定がきちんとできているか不安になってきました。OUTPUT の policy が ACCEPT だった時には動いていたので、INPUT のルールは間違っていない。ということは SYN を受け取って、ACK/SYN を返せていないのではないか、という疑問をいだきます。

こうやって設定すれば動くのかなぁ？

再起動

……繋がらない

(5ループほど略 orz)

iptables -A OUTPUT -j LOG してみたところ、判明しました。(送信側アドレス書き換えてます)

IN= OUT=eth0 SRC=123.456.78.90 DST=169.254.169.254 LEN=60 TOS=0x00 PREC=0x00 TTL=255 ID=40017 DF PROTO=TCP SPT=52896 DPT=80 WINDOW=26883 RES=0x00 SYN URGP=0

……何だよこのアドレス……

もちろん169.254なので LINKLOCAL-RFC3927-IANA-RESERVED です。Amazonが持っているに決まってます。

検索してみたところ、こんなヘルプページが見つかりました。

どうも、このIPアドレスに対してHTTP requestを行うと、何やらいろいろ情報が取れるようです。ドキュメントには取得だけが書いてありますが、そのほかの隠し仕様があるかはわかりません。

というわけで、予想です。

AWSの各インスタンスは、起動時に 169.254.169.254 にアクセスし、インスタンスの起動ビーコンを送っている。これが確認できたら、AWS側でFWをあける。ビーコンが確認できなければFWが閉じたままになるので、上記の試行で接続できなかった。

まあ、FWとしては正しい設定の気もします。(どこにもドキュメント無さそうなのが問題ではありますが。あるいは私の探し方が悪いか…)

実際に以下の設定を追加したら、きちんと起動され、sshも繋がるようになりました。(実際にはhttpsとsmtpも同時に許可設定しました)

# sudo iptables -A OUTPUT -p tcp --dport http -j ACCEPT

………何回もサーバ止めて再起動してたせいで、Elastic IP Addressの未使用期間として課金されました。助けてママン；；

★AWSその他の設定

なぜかrun-partsが設定されていない。 → 設定されてました。

/etc/cron.d/0hourly に cron.hourly のみが設定されていて、daily とか monthly とかの設定が無い。

0hourlyをコピって、実行日時とディレクトリ名を変えてやればおｋ

/etc/crontab ではなく /etc/anacrontab のほうに設定が…。cron.hourly の中で anacron 起動して、そいつが cron.daily 等を実行するという２段階設定になってました。

httpdの設定

Apache2.4が出てからかなり立つのに、いまだにデフォルトがApache2.2 でprefork MPMでした。互換性の意味で仕方ないのかしら…？

私はyumを使って2.4に入れ替えてしまった。/etc/httpd/conf.modules.d/00-mpm.conf を設定して、どのMPMを読み込むか決めることができます。

ちなみに2.2の場合でも、バイナリ自体は /usr/sbin/httpd.worker とか /usr/sbin/httpd.event とか出来ていて、/etc/sysconfig/httpd で切り替える形でした。

★AWSでrubygemsを動かす

tDiaryのCGI (要するにココ) を、旧サーバから新サーバ(AWS)にコピーしたら、動きませんでした。

cannot load such file -- json (LoadError)

こんなエラー。おかしいな…、と。だってJSONは、Ruby1.9以降で標準装備なはずなんです。

エラーが出ている行を探してみると

require 'json'

この行です。いたって普通のことをやってそう。

tDiaryのドキュメントにしたがって、bundle installしなおしても同じエラー。

ところが

$ ruby -e "require 'json'"

エラーなしです。

$ gem list | grep json
json (1.8.2)

存在します。

なのにエラー… (´・ω・｀)

はてさて、困りました。

こういうときは…

1日寝て別のことをやって過ごす！

..zZ .zZ .zZ .zZ .zZ

↓rubygem (ルビーの宝石)

……

はっ、こ、これは……だって日曜ですもんね！　おもちゃ買ってね！

さて、1回ディレクトリを全部消して、やりなおしてみても、同じ結果でした。

何が悪かったんでしょう。gem とか bundler とか調べてたら、こんなのに当たりました。

$ cat .bundle/config
---
BUNDLE_PATH: ".bundle"
BUNDLE_WITHOUT: development:test
BUNDLE_DISABLE_SHARED_GEMS: '1'

システムにインストールされてるgemは無視する設定です。

……

Amazon Linuxのほうでは

$ yum list installed | grep ruby | grep json
rubygem22-json.x86_64 1.8.2-1.39.amzn1 @amzn-main

というわけで、こいつgemです。

……

ファイルの実体のほうを調べてみたところ /usr/share/ruby/gems/2.2/gems/json-1.8.2/lib/json.rb にファイルは存在しました。

でもこれって、BUNDLE_DISABLE_SHARED_GEMS の設定があるから、読まれないんですよね。だから require 'json' でエラー…

というわけで、原因がわかったので対処します。

ここの tDiary だけなら Gemfile いじれば対処できる気はしますが、他に同様にrubyを使っているところで同様の対処は面倒くさい、そもそもAmazon Linuxでgccは標準で入っていない(yum install必要)、等の理由により、システム側に対策を入れてしまうことに。

$ cd /usr/share/ruby/2.2
$ sudo ln -s /usr/share/ruby/gems/2.2/gems/json-1.8.2/lib/json.rb .

これで tDiary 動きました。めでたしめでたし。

★複合機を装ったウイルスメールが来た

コニカミノルタ公式の注意喚起に似ているんですが、どうも新種なのか、動作が違う模様です。

ホントに複合機が乗っ取られたとかだったらどうしよう…

ちょい興味本位で解析してみましたが、最近よく見かけるダウンローダ型みたいです。以下の情報中、ドメイン名は example.com に変更しています。ヘッダの順番は入れ替えています。

Return-Path: <copier@mydomain.example.com>
From: <copier@mydomain.example.com>
To: <info@mydomain.example.com>

注意喚起にあるものと差出人が違います。info とかメールアドレス拒否れないから、こういうところに送るとかウザい…

Received-SPF: Fail (SPF fail - not authorized) identity=mailfrom; client-ip=123.456.78.90; helo=xxxxxxxxxxxxxxx; envelope-from=copier@mydomain.example.com; receiver=info@mydomain.example.com

もちろんSPF的にはアウトなので、これを拒否することは可能のようです。なお送信元の国はルーマニア(.ro) でした。

X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.98.7 at mail.mydomain.com

ClamAVでは検出出来ない模様。

Subject: Message from KMBT_C224

注意喚起にもあるとおりのSubjectです。

Date: Tue, 22 Mar 2016 20:05:08 +0300

+0300です。ルーマニアはUTC+2(DST UTC+3)なので、ルーマニアで中継されてると考えられます。

Message-ID: <12345678901234567890.copier@mydomain.example.com>

自ドメインのMessage IDがついているので、送信元では付加されなかった模様。

X-Mailer: KONICA MINOLTA bizhub C224
Content-Type: multipart/mixed; boundary="KONICA_MINOLTA_Internet_Fax_Boundary"

他に特徴的なヘッダはこれくらいでしょうか。

なお、C224 というのは実在する機器ですが、現行機種ではないようです。C224e が現行機種ですね。

添付ファイルは、注意喚起では doc 形式でしたが、ここが決定的に違います。私のところに添付されていたのは SKMBT_C96481894199133.zip という zip ファイル。

中身は EQM4830337106.js という JavaScript ファイルでした。js ファイルはデフォルトで Microsoft Windows Based Script Host に関連付けされていますので、ダブルクリックすると危険と思われます。(私は拡張子を txt に変更しました)

JavaScriptの中身は難読化されています。最近いくつか同様の JavaScript/zip の添付ファイルを受け取るのですが、同様の難読化をされていて、パターンマッチでウイルスチェックするのは難しいのかしら…？

今のところ確認できたものには function undeveloped(poseidon, economic) { という記載がありましたが、今後も同じかどうか不明です。

解析中…

Windows対象のダウンローダだった模様です。最近この手のダウンローダがよくやってきます(泣)　別のSubjectでも同種のものが来ています。

動作としては、ActiveXObjectを生成、とあるURL(function undevelopedの第一引数)をopen。ADODB.Stream を用いて引っ張ってきて、saveToFile を行う。セーブ先は ExpandEnvironmentStrings("%TEMP%") にファイル名(undevelopedの第2引数) をつなげたもの。

その後、実行、というものでした。

URLはインドのものでした。

JavaScriptの大半は無駄な文字。文字列に代入だけじゃなく、配列に対して splice みたいな無駄な文 (spliceした結果をどこにも代入せず捨てている) などもあり、解析をやりにくくしている模様。

ただ、生成ツールのできが悪いのか(笑)、スクリプトキディが生成ツールに入力するであろURLの文字列は、分散されておらず、undeveloped の第一引数のみの情報で URL を生成することができました。

一方 ActiveXObject 等の文字列は分散され、文字列や配列の計算で生成するようになっていました。

実際のURLのほうは法に触れるので、ダウンロード仕掛けてません。解析ここまで。

VirusTotalの結果、zipファイルウイルスあり

いっぽう、ダウンロード先のほうは、Kaspersky だけしかまだ対応してないようです。