(IT) 【注意喚起】件名:「セキュリティ警告 」なるメール

すでにJPCERTでも注意喚起がなされている迷惑メールの件。
まあ、ただの迷惑メールなんで、その存在がどうとか、アドレスの流出経路は?みたいな話しもあるけど、大抵は取引先からダダ漏れだったりする。オレの過去記事
(IT) 【注意喚起】Gmail(Google Apps)をターゲットにしたスパム
を参照のこと。

内容的に情報システム担当者へ転送しづらかったり、ちょっと控えたくなる内容の迷惑メールがもろもろのフィルターを通り抜けて一般利用者へ到達する事例。
FromとToが同一で、「あなたの恥ずかしい姿を会社中にばらすよ?」という内容。
これ、一種の踏み絵で、「いやいや、そんな恥ずかしい姿撮られるはずがない」と毅然と対応できるかどうかを判定できる。
悪意のあるスクリプトがしこまれていたり、添付ファイルがあるわけではなく、ただ単にビットコイン払え、みたいな不正請求はがきと同じレベル。
機械翻訳っぽい日本語で、不自然だし。一見して迷惑メールとわかる内容。
現状、弊社では受信時のフィルタで検疫しているが、何通ががもれてしまった。
お知り合い各位も、「こういうメールが到着したら、正しくエスカレーションされるか?」という観点で自社の利用者の意識チェックをしてもらえれば、と。

<<<問題のメール>>>
<From:>
自分のメールアドレス

<To:>
自分のメールアドレス

<Subject:>
セキュリティ警告

<body:>
こんにちは、(自分のドメイン)の親愛なるユーザー。
あなたのデバイスに1つのRATソフトウェアをインストールしました。
この瞬間、あなたのメールアカウントはハッキングされています(今、私はあなたのアカウントにアクセスできます)。
あなたのシステムからすべての機密情報をダウンロードしました。私はいくつかの証拠を得ました。
私が発見した最も興味深い瞬間は、あなたのマスターベーションのビデオ記録です。

私はポルノサイトに自分のウイルスを投稿し、それをあなたのオペレーティングシステムにインストールしました。
ポルノビデオの再生ボタンをクリックすると、その瞬間に私のトロイの木馬があなたのデバイスにダウンロードされました。
インストール後、フロントカメラは自慰行為のたびにビデオを撮影します。さらに、ソフトウェアは選択したビデオと同期します。

今のところ、ソフトウェアはソーシャルネットワークと電子メールアドレスからすべての連絡先情報を収集しています。
収集したすべてのデータを消去する必要がある場合は、BTC(暗号化通貨)で550ドルを送ってください。
これは私のBitcoinウォレットです: 19rq65nR7FqvEgeq3r8YmHGupsUvnD3pmD
この手紙を読み終えてから48時間経っています。

あなたの取引後、私はあなたのすべてのデータを消去します。
さもなければ、私はあなたのいたずらを伴うビデオをあなたのすべての同僚や友人に送ります!

そして今後はもっと注意してください!
唯一の安全なサイトにアクセスしてください!
さようなら!

(IT) サマータイムは勘弁してくれ

サマータイムがなんでダメなのか、システム屋視点で。

「朝7時に起きてるオレが5時に起きるわけだろ」とか「18時に仕事終わるはずが16時に終わるわけだろ」的な標準時とサマータイムの差が嫌だみたいな感想はどうでもいい。まじでどうでもいい。2日目以降は通常の24時間サイクルなんだから、問題ないことに気がつけよと思う。太陽の傾きが健康に及ぼす被害があるかもしれないけど、そんなもん気にしなくていいって、前例はたくさんあると思うよ(未検証)。
でもね、システム屋視点で何がいやか書いておく。いや、ほら、検証に何年もかかるみたいなざっくりした批判がIT屋の総意みたいに取られても面白くないんでね。
要するに「できない」んじゃなくて、最初から(設計段階から)言っといてくれれば、ちゃんと動くように作れるのに、短い期間で後から対応するのが不可能なだけ。

2020年の5月のある日、日本にサマータイムが導入されたとしましょう。
5月下旬のある日、未明の「一般生活に影響がないと思われる早朝」のタイミングで導入されるとする。
深夜1時59分59秒の次に4時00分00秒が来る、と仮定しましょうか。
そうするとこの日は2時台と3時台の時刻が存在しないわけですよ。
ということは、まず、毎晩2時台とか3時台に取得することにしてるバックアップを実施するトリガーがないわけです。
サマータイムが導入されて何か起こるかわからない日のデータのバックアップ取れないことになるわけ。
その日だけ早めにバックアップすればいい?いやだから、1時台までにいろんな処理が終わったあとで2時台にバックアップしてるわけで、バックアップだけ早い時間にやればいいわけではないのはわかりますよね?データの更新終わってなくて前日のバックアップと同じデータのバックアップが取れてしまっても意味ないっしょ?全部の処理をちょっとずつ前倒しするの?その動作確認する?まじで?そこの再設計と検証が大変なんだよって話だよ。単一のシステムではなく、いろんなシステムが処理をして、翌朝の決済とか配送の処理してるのに、2時間たりなかったら、処理終わらないかもじゃん!誰が責任取ってくれんのよ、これ。

いや、神業的処理でサマータイム導入時を乗り切った俺たちの次の関門はサマータイムをやめる日。
深夜3時59分59秒の次に2時00分00秒が来るのかよ。その日2回めの2時台と3時台かよ。ふつーにバッチまわったら、重複処理になるだろう。お客様へ同じ商品2個届くよ。在庫足りなくなって自動発注かかるよ。それ、返品来るよね。おいー、まじかーってなるでしょ。1回めの3時台にパスワード変更したら、2回目の2時台はそのパスワードでログインできるべき?1回目の3時台のお客さんの方が2回めの2時台のお客さんの方が先だってこと、どうやってシステムに理解させればいいんだろう?これを起こさないように手配して実装してテストすんのか。あ、でも2回めの2時代の注文は全部ナシにしてはいかんわけだしうおー、気が狂いそうだ。
#あ、その2時間はサービス止めちゃえばいいのか(悪魔のささやき)。

∴サマータイム導入に反対です

(IT) viエディター

1980年代でも、CPUをシェアして使うという考え方は一般的だった。
汎用機もUNIXも一台も「ホスト」にダム端末と言われていたグリーン
一色のディスプレイをもつ端末がたくさん繋がれており、操作する人は
時々まわってくるCPUの順番で処理を許された。
こんなやつ。

CPUは文字の入力、プログラムの実行、コンパイルなど様々な処理に
対して「時々まわってくるもの」だった。ヒナがたくさんいる親鳥が
一斉に口を開けてピーピー言ってるヒナに順番に餌を与えるように。

オレの最初の端末もSun4-330にRS232cで接続されたtty端末だった。
いまでは/dev/tty0とかは、マルチウインドウの1枚のウインドウに割当
られているが、当時はダム端末の一台に割り当てられていた。
config.sysやautoexec.betを書いていた世代だったので、.cshrcや.loginを
書くことには抵抗がなかった。
当然、.cshrcも.loginもviで編集せざるを得なかったわけである。

だから、カーソルを移動するだけでCPUを使うのは、時間の無駄だった。
スクリーンは10行ほどスクロールすると動きを止め、数秒後にまたスクロール
した(感覚には個人差があります)。
viはそんな時代に開発されているので、いかにすくないキータッチで目的の
編集ができるかを主眼に開発されていると行っても過言ではなかった。
「カーソルを行末へ移動する」「カーソルを最終行へ移動する」などは
「$」と「G」に割当られているし、10行ヤンク(コピー)してペーストも
「10yy」と「p」で実現される。文字列の検索も置換も秀逸だ。

ながながと書いたのは、若い人も是非viを修得して欲しいということ。
サーバー管理でよくあることは、とあるプロセスがメモリを食いつぶして
今にも息絶えそうなサーバーにログインさえできれば、問題のプロセスの
設定ファイルを書き直して、プロセスの再起動をする、というようなことが
できる。設定ファイルをftpで落としてきてローカルのメモ帳で直して再度
アップロードするなんてするなら、ftpdも動いてないといけないし、ポート
も開いてないかもしれない。

以前から採用の面接の時、「エディターはviです」という子は贔屓するように
しているのはナイショだ。

(IT) Apple関連ドメインのメールがblockされたら

しばらく前に個人で管理しているメールサーバーで発生してたんだけど、今日は会社のメールサーバーでも発生してたので、blogにまとめておく。

Apple社のサービスで使ってるドメイン(me.comとかicloud.com)へのメールが届いてないんだけど、と相談されたら大抵これ、という解決策。
Apple社が自社サービスのメールサーバーの受信フィルタで使っている「proofpoint」というサービスがあって、こいつがある日、急に送信元のIPアドレスに従ってメールをブロックする。その基準はわからない。
ブロックされたらそのIPアドレスのサーバーを使っているドメインからme.comとかicloud.com宛のメールが届かなくなる。
/var/mail/maillog に対応策がログとして残っているので、それを実施。
logの内容はこんな;

Apr 11 06:14:46 smtp_server_name postfix/smtp[ID]: B7E93A****: to=<hogehoge@icloud.com>, relay=mx3.mail.icloud.com[17.172.34.64]:25, delay=2, delays=0.12/0.01/1.3/0.55, dsn=5.7.0, status=bounced (host mx3.mail.icloud.com[17.172.34.64] said: 550 5.7.0 Blocked – see https://support.proofpoint.com/dnsbl-lookup.cgi?ip=IP_ADDRESS (in reply to MAIL FROM command))

(smtp_server_name=自分のSMTPサーバーの名前、 IP_ADDRESS=自分のSMTPサーバーのグローバルIPアドレス)

要は「ブロックしたからなんとかしたけりゃここのサイトにおいで」と。
ログにある https://support.proofpoint.com/dnsbl-lookup.cgi?ip= へ行って自分のSMTPサーバーのグローバルIPアドレスを入力し、「ロボットではありません」にチェックを入れて「LOOKUP IP」ボタンを押す。

ブロックされてない場合はこんなだが、

ブロックされてた場合はこんな。

なので、名前とアドレスと(あれば)会社名を入力し、「ブロック解除お願いします」と日本語でもいいので、入力の上、「SUBMIT」ボタンを押す。審査中はこんな画面だけど、1時間前後でブロックが解除され、最初のブロックされてない画面になる。

一度解除されても、またブロックされているケースもあるので、注意が必要。

(IT) docomoドメインへのML配信エラー対応

いくつかのドメインのメールサーバーをAWS上で運用している。
どのドメインもSPFのみならず、DKIMやDMARCにも対応させて
一応なんとか運用している。
しかし、4月の中旬くらいからどうやらdocomo.ne.jpのメールサーバーの
仕様が変わったらしく、Mailmanを使ったMLの配信でbounceが発生する
ようになった。

/var/log/mailman/bouce の例としてはこんな。

date (ID) processing 3 queued bounces
date (ID) ml_name: aaa@docomo.ne.jp current bounce score: 2.0
date (ID) ml_name: bbb@docomo.ne.jp current bounce score: 2.0
date (ID) ml_name: ccc@docomo.ne.jp current bounce score: 2.0
date (ID) processing 3 queued bounces
date (ID) ml_name: aaa@docomo.ne.jp already scored a bounce for date 23-May-2018
date (ID) ml_name: bbb@docomo.ne.jp already scored a bounce for date 23-May-2018
date (ID) ml_name : ccc@docomo.ne.jp already scored a bounce for date 23-May-2018

これ、全部のメールがbounceしているわけではなくて、
i.softbank.jpから発信されて、当該ドメインのメールサーバーで
ML宛に配信されたメールがbounceするのだった。
正確にはaaa,bbb,cccの3人への配信がbnounceしていると書いてあるが、
実は、bbbとcccには実は届いていて、aaaにだけ届いていない。

同じタイミングの/var/log/maillogはこんな。

date server_name postfix/smtp[PID]: ID: to=<ccc@docomo.ne.jp>, relay=mfsmax.docomo.ne.jp[203.138.180.112]:25, delay=0.24, delays=0.09/0.01/0.03/0.11, dsn=5.0.0, status=bounced (host mfsmax.docomo.ne.jp[203.138.180.112] said: 550 Unknown user aaa@docomo.ne.jp (in reply to end of DATA command))
date server_name postfix/smtp[PID]: ID: to=<bbb@docomo.ne.jp>, relay=mfsmax.docomo.ne.jp[203.138.180.112]:25, delay=0.24, delays=0.09/0.01/0.03/0.11, dsn=5.0.0, status=bounced (host mfsmax.docomo.ne.jp[203.138.180.112] said: 550 Unknown user aaa@docomo.ne.jp (in reply to end of DATA command))
date server_name postfix/smtp[PID]: ID: to=<aaa@docomo.ne.jp>, relay=mfsmax.docomo.ne.jp[203.138.180.112]:25, delay=0.24, delays=0.09/0.01/0.03/0.11, dsn=5.0.0, status=bounced (host mfsmax.docomo.ne.jp[203.138.180.112] said: 550 Unknown user aaa@docomo.ne.jp (in reply to end of DATA command))

maillogではaaaで拒否しているからbbbにもcccにも届いてないよ、って
ログだから、bounceファイルでもbounce処理していることが載っている
のだが、前述の通り実際にはbbbとcccには配信されている。

よって、bbbとcccをaaaの影響から外すために、全てのメールを
個別配信する設定に変更した。Mailmanはデフォルトでは同一
ドメインには、一度のセッションで複数のアドレスへ送っている
ようで、それが今回の問題の原因のようだった。

/etc/mailman/mm_cfg.py の最終行に以下の記述を追記。

VERP_PROBES = Yes
VERP_PASSWORD_REMINDERS = Yes
VERP_PERSONALIZED_DELIVERIES = Yes
OWNERS_CAN_ENABLE_PERSONALIZATION = Yes

これで管理コンソールの「普通配送」のところに個別配信の
メニューが追加され「いいえ・はい・完全個人別配信」が選択できる。
完全個人別配信とすると、本文に名前を入れるなどのカスタマイズが
できるが、今回はそこまでしないので、「はい」を選択。

結果として、maillog上でもmailman/bounce上でも配信エラーは
aaaだけとなった。
aaaに配信されていないという根本原因は不明なままだが、とりあえず
他のメンバーがバウンス回数が多くて配信停止になるというリスクは
回避できたはずだ。

参考ページ:Mailman日本語情報「サイト管理の手引」