(IT) AWSでメールサーバー立てててspamhaus.org使ってると受け取ったメールを全部SPAM扱いされる

もう、メール送信サーバーを自前で運用するなんて、面倒くさいだけで何のメリットもないけど、意地と趣味で続けていたりする。合計6ドメイン、3サーバーでメールサーバーの運用をしている。全部AWS上のpostfixだ。
今日の昼頃、そのうちの一つのメールサーバーで運用しているメーリングリリストへ送信できないよーというメッセージを頂いた。エラーの内容がわからなかったのと受け取ったのが出先だったので、エラーメール転送してくださいとだけ返信して、帰宅後に対応を開始した。
とりあえず、サーバーにログインしてログをみると、確かにエラーになっている。

Nov 3 11:04:39 ip-10-0-1-97 postfix/smtpd[23376]: NOQUEUE: reject: RCPT from 送信元サーバー[IPアドレス]: 554 5.7.1 Service unavailable; Client host [IPアドレス] blocked using zen.spamhaus.org; Error: open resolver; https://www.spamhaus.org/returnc/pub/[AWSのパブリックIPアドレス]; from=<送信元アドレス> to=<送信先アドレス> proto=ESMTP helo=<送信元サーバー名>

spamhausとは、無料のブラックリスト判定サービス。サーバーの設定で「spamhausがSPAMと判定しているサーバーから来たメールは問答無用で拒否する」という設定ができるもの。
最初あんまりちゃんと読まないで、自分のサーバーがブラックリスト登録されたんだと思いこんで、解除依頼すればいいんだろうとたかをくくっていた。そう、なぜかブラックリストに追加されて解除依頼は過去にも経験があったからだ。
spamhaus.orgのブラックリスト確認ページへ行って、自分のメールサーバーのIPアドレスやドメインを入れても問題ないと出る。

なんでだ?
ログをもう一度よく見てみると、SPAM判定されているのは送信者側のサーバーのようだし、リンクされているのはAWSのRoute53(DNS)のIPアドレスのブロック確認ページだ。天下のGmail様から来たメールも見事におはじきになっておられる。どういうこったー?
こういう時はtwitter検索で同じ症状の人を探すのが近道。というわけで、見事に原因にたどり着けた。
9月22日に
AWSから無料でspamhaus使ってるメールサーバーには全部SPAMって答えるよ、さもなければ有料サービスにお入りなさい」と書かれた告知がリリースされているを発見。君か。10月18日から順次適用とな。オレが管理している3サーバーでは、11/1適用が1台、11/3適用が1台、残る1台は未適用という感じだったが、これから順次適用されていくと思うので、該当する管理者は対応を急いだ方がいい。
具体的な対応としては、/etc/postfix/main.cfに書かれているこのエントリーの「eject_rbl_client sbl.spamhaus.org」という部分を削除し、適切なspamチェッカーを設定すればOK。ようするにspamhausを使わなくすること。

smtpd_client_restrictions = (もろもろの許可設定),reject_rbl_client sbl.spamhaus.org,

念のためpostifixやその他のモジュール(DKIMとかdovecotとか)を再起動して復旧となる。
早く気がつけてよかった。死活監視では気が付けない問題なので、利用者からの問い合わせじゃないと気が付けない。
同じ症状で困っている人に向けてblogにしておいた。

(IT) Big-IPがやられたけど、仮想化してたから速攻でリカバーできた話

サーバセンターなんかで赤くて丸いf5と書かれた筐体を見たことがある人も多いはず(普通見ないかw)。

いまいる会社でもファイヤーウオールとロードバランサーで使ってるわけで。この会社の事例紹介でも取り上げてもらった。
ご存知の通り、紹介されるといろんなサービスがあっ(以下自粛)
採用したのはaws上(クラウド上)で動くVE(Virtual Edition)版ではあるものの、令和の時代にあっても、多くの企業や行政ではリアルな筐体でBig-IPを採用しているところは多い(はずだ)。
で、この日本だけではなく、世界でシェアをもつファイヤーウオールに脆弱性が発見された。
例えば、Windows10に脆弱性が見つかって攻撃されても、パソコンの中に入っている一人か二人分の個人的なデータ漏えいする可能性があるだけ(シゴト用のパソコンでサーバーへのログイン情報とかが記録されていたらその限りではないけどね)。しかし、一般的なWebサーバーは、「そいつ(ファイヤーウオール)が守ってくれるから、(一般的なことはするにしても)特別な防御をしなくてもいいよね?」という前提で、インターネットに直で出しているサーバーよりも安心感を持って設定してあるわけ。そこへもってきて、ファイヤーウオールに脆弱性があるってことは、みんなが頼りにしてたそいつに弱点があって、何ならログインされて、踏み台にされたら、壁の内側を荒らされ放題(技術的にはかなり高度な知識と経験がいるけど)になる可能性があるわけよ。もう、インフラ屋からすればオカルトそのもの(怖)。
一般的な「セキュリティ」の考え方としては、「可能性がある」時点で、「やられてしまった」と捉えて対応しないと、大変なことになる「可能性がある」ので、対応必須というのが常識なわけで。
というわけで我々も対応開始。業界的にいうと、「お祭りがはじまった」状態なわけだ。

セキュリティ上の問題で、当該のファイヤーウオールがどんな状態だったかは詳しく書けないけど、少なくともこの脆弱性をついた攻撃はゼロ回じゃなかったことだけは確かだと観測された。だって、前述の通り「この会社はf5のマシン使ってまっせー!」ってインターネット上に書いてあるんだから、ここの事例集に載ってる会社にはとりあえず攻撃してみるのが正しい「悪意のある人」の行動。
ということはもう、可能性があるわけだから、やられちまった前提で対応を開始。
とりあえず、メーカーが推奨しているようなネットワーク上の設定はすぐに実施したが、問題は機器の再構築。
オンプレでリアルの筐体を使っている会社はマシンをネットワークから外し、初期化して、ゼロからインストールして、それまで実施してきたシグネチャの適用を全部順番にしないといけない。それはそれは気の遠くなるような作業で、ベンダーさんに頼んでも何百万円もかかって何日いや何ヶ月かかるかもしれない。
しかしオレが担当しているファイヤーウオールは仮想化といって、クラウド上で構築されているので、毎日その機器の状態を「スナップショット」という形式でバックアップしている。なので、攻撃が開始された前日のスナップショットから復元することで、数時間で安全な状態に復帰できる、はずだった。スナップショットからの復帰については大きな問題はなかった。2台が並行して動いていて片方が死んでももう片方がすべてのトラフィックを捌ける設定となっており、リソース的に問題ないことも実験済だった。この機能を利用して、1台づつネットから隔離して復元してネットに復帰させれば、全体のネットワークを止めず、業務影響なく対応できるはずだった。
ところがネットワーク内の他のサーバーで数台、片方のファイヤウオールからの応答がないと動作に支障をきたす設定となってるものがあり、1台をネットから外すといくつかの部署で悲鳴があがる状況で、一台ずつ設定の確認と変更を実施したので、そこで時間がかかってしまった。
2日間にわたるお祭りも、そんな小さなトラブルもありながら、なんとか完了できた。何ヶ月もかかる可能性があるオペレーションが2日でできたし、追加のコストもなく完了したのは、スタッフやベンダーさんの緊張感を持ったオペレーションのたまものではあるわけだが、もう一つの手柄は「Big-IPをaws上のスナップショットから復元させる機能をメーカーであるf5に実現させた」男の存在だ。
VE版の出始めの頃、f5社はスナップショットからの復元は正式にサポートしていなかった。おいおい、f5さん、ソフトウエアの会社になると宣言している割には、むっちゃハード寄りというかオンプレ前提の話じゃないっすか、それ。VE版なんだからスナップショットからの復元をサポートしてくれよ、と強行に申し入れをして、結果サポートを勝ち取った。あれから3年以上経った日に、あの交渉が活きたということ。インフラを守るというのはこういうこと、と思ったよ。当時f5と直談判してくれた同僚に本当に感謝している。

(IT) 老害のAWS+CentOS7+Apache2.4など

NTT-ComさんのCloud-nは日本リージョンができる前からユーザーだった。
なんと言ってもネットワーク費用が固定というところがキモ。
できたての頃からエバンジェリストの林さんからの推薦もあって、まずは
個人のサイトからスタート。その後、法人でも契約したけど、その行方は
担当にまかせるとして、個人サイトは先日、引っ越しを余儀なくされた
USリージョンでも移行があるということで、これはマニュアル通りの
移行でなんとかなった。
今度はUSリージョン撤退ってことで、日本リージョンへの移行の案内は
あったものの、今のシゴトからすれば、AWS一択なわけで、そっちへ
移行することにした。

個人のドメイン(shirao.netとryoshr.net)はメールとWeb(blog)の
サーバーが一台にまとめてあった。まあ、安いからね。
今回はメールとWebのサーバーを分けよう、というアイディア。

とりあえず、自前の知識で、AWSのCentOS7上にqmailのインストールを
はじめてみたものの、あちこちでスタックして無理っぽい。
まあ、qmailのインストールといえば、オレが最初にやった時はgccの
コンパイルするところからだったんだぜ。
yumなんて魔法のツールがないころな。
ライブラリが足りないと、東京理科大のsun用のftpサイトから落としたりな。
最初にqmailいれたの、Sun SPARCだったなあ。
で、今回はセキュリティパッチだのtcp wrapperだのqmailの開発当時は
想定してなかったことをフォローするためにいろいろ手順があるんだが、
CentOS7+qmailという組み合わせの情報がほとんどない。
学生時代からのツレのけんちゃんの「いまからqmail?」というつっこみを
きっかけにpostfixへ切り替え。
そしたら、なんだよ、むっちゃ楽ちんやんけ。virtualという名前のファイルの
いじり方さえ覚えちまえば、どうにでもなりそう。Webで管理するツールも
あるらしいし(オレは使わないけど)。
というわけで、実家のじじばばも使っているshirao.netのメールサーバーの
移行はその後はかんたんに完了。Rout53にしといたのも勝因。

つづいてWordpressの移行。
メールサーバーの時もそうだったけど、CenOS7の最初のユーザーって「centos」
なんだよ。「es2-user」じゃないの。EC2でインスタンス作ったのに、ログインできない。
なんでーと思って、会社の同僚に聞いたら、教えてくれた。

SELinuxをまず無効にするのは、学習してた。でもそのあとrebootするのが常識らしく。
vsftpdが立ち上がらず苦労したのはrebootしてなかったからだったようだ。

続いて苦労したのはmysqlのデータの移行。
新しいサーバーは最新のmysql5.7。5.6まではコマンドでrootユーザーのパスワードが
変更できたのに、このバージョンではその「優しいモード(mysql_safe)」がなくなっている。
よくよくしらべると、/var/log/mysqld.logを見て、先頭の方にある
[Note] A temporary password is ・・・の行にパスワードが書いてあるという
Webに辿り着くのに半日以上使うなど。

mysqlでバックアップしたデータを新サーバーで戻したら、あとはwordpress関連の
ファイルをごっそりコピーしたら、blogの移行は完了。
これもDNSをRoute53にしてたから、切り戻しも考えやすかったしね。

よしよしと思ってたら、pluginのアップデイトにftpdが必要。
お約束のvsftpdをインストールしたが立ち上がらない。
一日以上費やしたあげく、あきらめて再起動したら何事もなく立ち上がった。
SELinuxを無効にしてからrebootしてないとよくある現象らしく。

というわけで、ようやくサーバーの引っ越しを完了。
現在smallインスタンスだけど、遅くなったら大きくしようかな、と。

Spesial Thanks to : @tamatamarock

(IT) iPhoneを機種変したらAWSにログインできなくなった

AWSのサービスコンソールにIAMでログインするのに仮想MFAデバイスとして
iPhoneのAuthenticatorを登録してあった。
itunes_authenticator

そんなことはすっかり忘れてた頃に先日iPhoneを機種変したんだった。
たまたまAWSから請求書が来たタイミングで気になることがあって、
サービスコンソールにログインしようと。
新しいiPhoneにも入れてあったAuthenticatorを使ってコード表示させて
コードを入力してもこんな画面。
Auth_Erro

うーん、そのままは使えないのな。
何回かやってもダメだったので、ページ上の「Contact us」ボタンをポチッと。
(実はこのボタン押したの2回目(告白))
予想通り、英語で電話がかかって来たので、英語のできる同僚に頼んで、
日本語でかけ直してくれ、と言ってもらった。

どうやってもログインできない中、ふと手元にマウスとして使ってた旧iPhoneが(笑)
mouse_iphone
そこに入ってたアプリのコードで無事ログインできた。(早く気付けよ)

IAMコンソールでデバイスを削除。
Delet_device

新しいiPhoneを登録。
スクリーンショット 2015-11-05 14.04.28

無事登録完了して、ログインもできた。
スクリーンショット 2015-11-05 14.05.41

たまにしかコンソールに入らない怠け者管理者は、機種変の前にMFA登録したデバイスの
削除をしておくことをお忘れなく。

と、ここまで書いたトコロで、日本語でAWSサポートさんから電話(笑)
すみません、おかげ様でなんとかなりまして、といいつつ、旧端末がなかった場合は
どうなりますかと聞いてみたら、電話で確認が取れたらAWSさん側でデバイス削除の
オペレーションをしてくれる、とのこと。
英語でかかってくる一発目の電話に耐えられるなら、何もしなくても大丈夫かもw。