(IT) jcomのメールサーバーの行儀が悪い

shirao.netというドメインを20年くらい前に取得して、主にメールでつかっている。
メールサーバーも最初は当時の所属会社にひっそり置いたSunのマシンにqmailを入れて稼働を開始し、その後自宅のSun Ultra10で稼働させていたが、震災の計画停電のタイミングでawsへ移行した。いったんOCNのCloud-nに浮気をしたものの、USリージョン閉鎖に伴い再度awsに戻ってpostfix化したりして。業界の人ならわかると思うけど、自分でメールサーバーを運用するというのはもう、無駄でしかない。
メールを使うだけならGmailでええやんけ、が正解。自分のドメインも持ち込めるし。
自分でメールサーバーを運用していると、攻撃パターンとか迷惑メールのトレンドを肌で感じることができ、少なからずシゴトに活かせるので、面倒だが、好きでやってる感じかな。
実家の両親にも最初からこのドメインのアカウントを使わせていて、メーラーはOutlookを触らせず、最初はAl-Mail、最近ではThnderbirdを使わせている。

ここ一週間くらい、実家の母(84)から俺のアカウントにメールが届かないという事象が発生していた。

同じドメインで同じサーバーを使っている俺も父も何事もなく送受信できているにもかかわらず、だ。
ログを見てみると、こんな感じでrejectしてた。

予想されるストーリーはこんな感じ。
(1)Thunderbirdのアップデートか何かでshirao.netドメインのSMTPサーバーの設定が飛ぶ
(2)その後の送信時に、回線のグローバルIPからJCOM回線と想定され、SMTPサーバーにJCOMのデフォルトが設定される
(3)母から俺あてのメールはshirao.netの中で完結するのに、なぜかjcomのサーバーらしきサーバーから飛んで来る
(4)そのjcomらしきサーバーはomta0014.jcom.zaq.ne.jpという名前でくる。(0014の数字の部分はその時々で違う)
(5)omta????.jcom.zaq.ne.jpというサーバーは正引きでIPアドレスを引けない
(6)ホコリ高き(笑)我がサーバーは正引きできないサーバーからのメールを受け取らない
(7)親子の断絶が生まれる
(8)余談だが、母のお友達のjcomユーザーのメールもrejectしてるが、全部jcomが悪いからね

俺のGmailのアカウントだとメールが届くので、それを使って「ThunderbirdのSMTPサーバーの設定を確認してくれ」と伝えたが、結局どこをどう見ればいいのかわからんと言われ、俺もThundebirdユーザーじゃないので、見ないとわからんということで、クイックアシストすることに。

普通の人なら、スタート>Windowsアクセサリ>クイックアシスト、と言えば、2秒で行けると思うのだが、84歳は一筋縄ではいかない。スタートメニューがなんだ酷いことになってるらしく、Windowsアクセサリに到達できない。作戦変更して「スタートで右ボタン押して検索でkuikkuと打つ」を電話で128回叫んでようやくクイックアシストの「支援を受ける」ボタンに到達。ここまで30分。
クイックアシストで母PCの中をみたら、ThnderbirdのSMTPサーバーはやはり、jcomのデフォルトに変わっていたので、shirao.netの設定に変更。パスワードを設定するところがなかったんだが、テスト送信時に認証のパスワードを聞かれ、無事に設定終了。母PCから俺のアカウントへのメールが開通した。クイックアシストで入ったら10分で解決。昔は、千葉県北部まで足を運んでたが、このクイックアシストは便利だし、感染防止にも役立つな、これ。それにしても年寄りはなぜスタートメニューが酷いことになるんだろうか。確かに酷かったけど、そっとクイックアシストを閉じたなど。

とはいえ、正引きできないサーバーでメール送信してくるjcomのサーバー、ダメだと思うぞ。きっと、届いてないメールたくさんあると思うんだが、大手プロバイダだし、確信犯ってことなのかしら。設計間違えちゃったのかしら。

(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) 新手の攻撃がー

このblogのサーバー、というか、インスタンス死んでました。

シゴトを終え、「ああ、今日は久しぶりに正面玄関が開いてる時間に帰るなあ」と
思ってたら、無料の監視サービスから「お前のサーバー、返事してないよ」とアラート。

いや、だって、これから電車乗るし、何もできないよう、と思いながら、
電車の中からCloud-nのポータルへアクセスしてたけど、結局つながらず。
(パスワードがわからんかったw)

家に帰って、コンソールから再起動しても、すぐ死ぬ。
かくなるうえは、インスタンスを停止して100数えてから起動。
嵐は去った。

しかしこれ、何なんだろう。情報お待ちしてます。
attack20151019

(IT) サーバーの引越し

このblogの載ってるサーバーの引越しを実施。
自分のためのログ。

このblogのサーバーはNTT CommunicationsさんのCloud-nというサービスを使ってる。
たまたまエバンジェリストの林さんと知り合いになれたので、サービス開始
当初から使わせていただいているわけで。

3月上旬から「米国リージョン Compute(VLANタイプ)終了です」ってメール来てたんだね。
後から気がついたよ。メールに予告されている通り、4月1日にバツンとshutdownされた。
うーん、なんか、誰かがshutdownコマンド打ってるけど、なんだこれ?
もしかしてのっとられたか?と思ったけど、フツーにコンソールにアクセスできたので、
再起動だけしておいた。忙しかったしな。
ちょっとしてから知らない固定電話から着信。折り返したらNTT-Comの担当さんだった。
その電話でようやく事情を理解。ほんとすみませんでした。
移行ツールが用意されていたので、移行は楽チンなことを確認だけして、作業は後日とした。

雨の日曜日、作業を開始。

(1)旧サーバーのcrontabを編集。fetchmailでMyDNSにIP通知するのを停止。
→これは、新サーバーを立ち上げた時に勝手にDNSを書き換えないように。
(2)旧サーバーコンソールでサーバーを停止してテンプレート(AWSで言うところのAMI)を作成。
(3)テンプレートできたところで旧サーバーを再起動。
(4)移行ツールでテンプレートをVLANタイプからFLATタイプへコピー。
※ここのマニュアルがわかりづらくて、FLAT側のIDに入れるべきIDがどれかわからず
だいぶタイムロスした。
(5)VLANタイプ側のファイヤーウオール設定をFLATタイプ側のセキュリティグループに移す。
(6)FLATタイプ側でテンプレートを使って新サーバーを立ち上げ。
(7)新サーバー側で各種サービスの起動を確認。
(8)新サーバーでfetchmailを実行してMyDNSにIPアドレスを通知。
(9)MyDNS側でIPアドレスが変更されたことを確認。
(10)blog、mailのlogで新サーバーへトラフィックが向いたことを確認
(11)旧サーバーを停止。
(12)新サーバーで定期スナップショットの設定。

実質2時間程度かな。(4)のログインで時間使ってしまったのが悔やまれる。
Screenshot_05

—後日追記(2015.04.07)
マニュアルに追記されてた。
1.2. 事前に行っていただくこと
—後日追記ここまで

それにしても、OS入れて、いろんなモジュールいれて、CMSいれて、ってやってたら
こんな時間では済まないから、クラウドっつーか仮想化ってやっぱり便利。

ちなみに、今回のサーバーの停止とか再起動とかしつつ監視ツールの動作も確認できた。
UptimeRobotを使っているけど、以前までweb以外のサーバーは名前ではなくてIPアドレス
しか設定できなかったが、気がついたら名前で設定できるようになってた。
この監視ツールは無料だし、便利なので、お勧め。
Screenshot04

さて、次は2年前に勢いで取った.asiaドメインの更新をどうするか、が懸案。