ぷららメールサーバーがセキュリティ対策を実施

「ぷらら」からメールサーバーのセキュリティ強化を行う通知が来た。随分と急な話だ。


メールマニュアルのリンク先を確認してみたがどのようなセキュリティ強化策か解らない。
今までと何の変化も無い。


メール送信が出来なくなったら対策を考えれば良いかと放置していたら9月11日から開始と通告が来た。

通告されても、「セキュリティ強化」がどのような対策なのか何も記述されていない。

9月11日からセキュリティ強化を実施しましたと9月14日にメールで通知された。
「CRAM-MD5」を廃止すると記載されている。
最初から「書けよ！」


ホームページにも記載された
9月14日「更新」？
いつ記載されたんだい。8月25日の日時記載があるが25日には、探しても見つからなかった。


９月20日 PR-600MIの交換後、NVR510のsystemログを確認していたら「メール送信エラー」が発生している。
ドアフォンからのメール通知も止まっている。

NVR510のSystem log
2023/09/18 15:45:27: [MAIL] Create Service State(lua, ID: 6)
2023/09/18 15:45:27: [MAIL] [11]Create Task for Waiting Event(lua, ID: 6)
2023/09/18 15:45:27: [MAIL] Create Service State(mail, ID: 41)
2023/09/18 15:45:27: [MAIL] [11]Create task for Service waiting timer(ID: 41, 1 sec)
2023/09/18 15:45:28: [MAIL] [11]Mail Wait Service Is Timeout(mail: 1 sec)
2023/09/18 15:45:28: [MAIL] Create Service State(mail, ID: 42)
2023/09/18 15:45:28: [MAIL] [11]Create Task for Connecting Server(ID: 42)
2023/09/18 15:45:28: [MAIL] [11]Wait Connecting to Server...(0)
2023/09/18 15:45:28: [MAIL] [11]Connected Mail Service Server
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "220 msc14.plala.or.jp ESMTP server ready Mon, 18 Sep 2023 15:45:29 +0900"
2023/09/18 15:45:28: [MAIL] [11]Send Msg: "EHLO v6mail.plala.or.jp"
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "250-msc14.plala.or.jp"
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "250-AUTH=LOGIN PLAIN CRAM-MD5"
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "250-AUTH LOGIN PLAIN CRAM-MD5"
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "250-PIPELINING"
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "250-DSN"
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "250-8BITMIME"
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "250-STARTTLS"
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "250 SIZE 20971520"
2023/09/18 15:45:28: [MAIL] [11]Send Msg: "AUTH cram-md5"
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "334 PDIwMjMwOTE4MDY0NTI5LlNCRkYxNjI2My5tc2MxNC5wbGFsYS5vci5qcEB2Nm1haWwucGxhbGEub3IuanA+"
2023/09/18 15:45:28: [MAIL] [11]Send Msg: "c29tZW9uZUBzb21ld2hlcmUucGxhbGEub3IuanAgYzExNWExMjMzOWUyNTJmZDBkZDBhYjIzMGJjODAxOTE="
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "535 CRAM-MD5 not supported for someone@somewhere.plala.or.jp"
2023/09/18 15:45:28: [MAIL] Read Error(535 CRAM-MD5 not supported for someone@somewhere.plala.or.jp)
2023/09/18 15:45:28: [MAIL] [11]Mail SMTP Service Receive Error(28)
2023/09/18 15:45:28: [MAIL] [11]Send Msg: "QUIT"
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "221 msc14.plala.or.jp ESMTP server closing connection"
2023/09/18 15:45:28: [MAIL] [11]End Mail SMTP Process for Error
2023/09/18 15:45:28: [MAIL] [11]Close TCP(0)
2023/09/18 15:45:28: [MAIL] [11]Remove From Mail Service State List(mail:42)

AUTHで「LOGIN」「PLAIN」「CRAM-MD5」で認証しろと応答しているから「CRAM-MD5」で認証しようとすると「CRAM-MD5はサポートしていません」と。
何じゃこりゃ！

ぷららのIPv4メールサーバ、IPv6メールサーバーについてポート465/SSL、サブミッションポート587/startTLSについて確認してみた。

secure.plala.or.jp
$ echo -e "ehlo\nquit" | openssl s_client -4 -connect secure.plala.or.jp:465 -quiet -crlf 2>/dev/null
220 msc13.plala.or.jp ESMTP server ready Wed, 20 Sep 2023 15:14:39 +0900
250-msc13.plala.or.jp
250-AUTH=LOGIN PLAIN CRAM-MD5
250-AUTH LOGIN PLAIN CRAM-MD5
250-PIPELINING
250-DSN
250-8BITMIME
250 SIZE 20971520
221 msc13.plala.or.jp ESMTP server closing connection

$ echo -e "ehlo\nquit" | openssl s_client -6 -connect secure.plala.or.jp:465 -quiet -crlf 2>/dev/null
220 msc13.plala.or.jp ESMTP server ready Wed, 20 Sep 2023 15:14:49 +0900
250-msc13.plala.or.jp
250-AUTH=LOGIN PLAIN CRAM-MD5
250-AUTH LOGIN PLAIN CRAM-MD5
250-PIPELINING
250-DSN
250-8BITMIME
250 SIZE 20971520
221 msc13.plala.or.jp ESMTP server closing connection

$ echo -e "ehlo\nquit" | openssl s_client -4 -connect secure.plala.or.jp:587 -starttls smtp -quiet -crlf 2>/dev/null
250-msc14.plala.or.jp
250-AUTH=LOGIN PLAIN CRAM-MD5
250-AUTH LOGIN PLAIN CRAM-MD5
250-PIPELINING
250-DSN
250-8BITMIME
250 SIZE 20971520
221 msc14.plala.or.jp ESMTP server closing connection

$ echo -e "ehlo\nquit" | openssl s_client -6 -connect secure.plala.or.jp:587 -starttls smtp -quiet -crlf 2>/dev/null
250-msc14.plala.or.jp
250-AUTH=LOGIN PLAIN CRAM-MD5
250-AUTH LOGIN PLAIN CRAM-MD5
250-PIPELINING
250-DSN
250-8BITMIME
250 SIZE 20971520
221 msc14.plala.or.jp ESMTP server closing connection

secureサーバは、DNSにAAAAアドレスが設定されていない。macOSのopensslは、-6指定でも勝手に-4で接続してしまう。Debian10のopensslは、「No address associated with hostname connect:errno=22」となる。「V6mail」サーバーも確認してみた

v6mail.plala.or.jp
$ echo -e "ehlo\nquit" | openssl s_client -4 -connect v6mail.plala.or.jp:465 -quiet -crlf 2>/dev/null
220 msc14.plala.or.jp ESMTP server ready Wed, 20 Sep 2023 14:48:13 +0900
250-msc14.plala.or.jp
250-AUTH=LOGIN PLAIN CRAM-MD5
250-AUTH LOGIN PLAIN CRAM-MD5
250-PIPELINING
250-DSN
250-8BITMIME
250 SIZE 20971520
221 msc14.plala.or.jp ESMTP server closing connection

$ echo -e "ehlo\nquit" | openssl s_client -6 -connect v6mail.plala.or.jp:465 -quiet -crlf 2>/dev/null
220 msc14.plala.or.jp ESMTP server ready Wed, 20 Sep 2023 14:48:25 +0900
250-msc14.plala.or.jp
250-AUTH=LOGIN PLAIN CRAM-MD5
250-AUTH LOGIN PLAIN CRAM-MD5
250-PIPELINING
250-DSN
250-8BITMIME
250 SIZE 20971520
221 msc14.plala.or.jp ESMTP server closing connection

$ echo -e "ehlo\nquit" | openssl s_client -4 -connect v6mail.plala.or.jp:587 -starttls smtp -quiet -crlf 2>/dev/null
250-msc14.plala.or.jp
250-AUTH=LOGIN PLAIN CRAM-MD5
250-AUTH LOGIN PLAIN CRAM-MD5
250-PIPELINING
250-DSN
250-8BITMIME
250 SIZE 20971520
221 msc14.plala.or.jp ESMTP server closing connection

$ echo -e "ehlo\nquit" | openssl s_client -6 -connect v6mail.plala.or.jp:587 -starttls smtp -quiet -crlf 2>/dev/null
250-msc13.plala.or.jp
250-AUTH=LOGIN PLAIN CRAM-MD5
250-AUTH LOGIN PLAIN CRAM-MD5
250-PIPELINING
250-DSN
250-8BITMIME
250 SIZE 20971520
221 msc13.plala.or.jp ESMTP server closing connection

「secure」サーバーも「v6mail」サーバーも実態は同じようだ。

DNS
$ host v6mail.plala.or.jp
v6mail.plala.or.jp has address 60.36.166.240
v6mail.plala.or.jp has IPv6 address 2400:7800:0:502f::240

$ host secure.plala.or.jp
secure.plala.or.jp has address 60.36.166.237

secureサーバーもIPv6対応していますとアナウンスされているがDNSのAAAAにIPv6アドレスを設定していない。誰が使えるの！

サブミッションポート587に「startTLS」なしで接続（telnet接続）してみた

一応「LOGIN」とか「PLAIN」で接続出来そう。やってみた

auth login


auth plain


「セキュリティ強化」ならこれも廃止したら？と言いたいところだ。

（2023年9月26日 追記）
セキュリティ対策されたSMTP-AUTH CRAM-MD5の振舞

someone@somewhere.plala.or.jp（存在しないユーザーID）
WAYWAYWAY（適当なパスワード）
で応答すると当然Authentificationされない。

auth cram-md5
334 PDIwMjMwOTI1MjM1NzUzLkdNS1Q2NzczLm1zYzEyLnBsYWxhLm9yLmpwQG9wZW5zc2wuY2xpZW50Lm5ldD4=
c29tZW9uZUBzb21ld2hlcmUucGxhbGEub3IuanAgYzVmYTY3MzkwYWQ4MTlmYjhmZTg1YTQwODlmMWM1YTc=
535 Authentication failed
------------------------------------------
realuser@realserver.plala.or.jp（存在するユーザーID）
WAYWAYWAY（適当なパスワード）
で応答するとパスワードが適当でも認証された時と同じ応答が返される。

auth cram-md5
334 PDIwMjMwOTI1MjM1OTMxLlNKTFkxNjI2My5tc2MxNC5wbGFsYS5vci5qcEBvcGVuc3NsLmNsaWVudC5uZXQ+
cmVhbHVzZXJAcmVhbHNlcnZlci5wbGFsYS5vci5qcCAwNWY3YTUyYmZkZDk0MDkwM2Q3NTZhNjE5MWYzM2YxYg==
535 CRAM-MD5 not supported for realuser@realserver.plala.or.jp

「 ぷららメールサーバーがセキュリティ対策を実施」
「Panasonic ドアフォン VL-SWH705KLのメール通知が停止した」
「Panasonic ドアフォン VL-SWH705KLのメール通知が停止した-調査結果」
「Panasonic ドアフォン VL-SWH705KLのメール通知が停止した-調査結果#2」
「ぷららメールサーバーのセキュリティ対策とPanasonicドアフォンメール通知」

ひかり電話 HGW PR-600MI 電話インターフェースが落雷で障害

2023年9月15日（金曜日）東京周辺で落雷が発生した。雨と落雷で久々の停電が発生した。長く感じたが1分強程の停電だった。復電後も何回か瞬断が在ったがひかり電話とネットワーク機器は、UPS供給なので何事も無く動作を続けた。
9月16日（土曜日）ひかり電話に着信が在った。３回線の電話番号を3台の電話機で回線番号毎に鳴動する機器群が異なるよう設定している。が、鳴り方がおかしい。設定を確認したが設計通りだ。再起動を考えたがこの日はこのまま。
9月17日（日曜日）電話を使用したら、接続後に相手の声が小さく聞こえ、こちらの声が相手に届いていない様子。
PR-600MIの電話機#1からは、発信出来ない。着信は話中。電話機#2からは、発着信可能だが音声受話ができない。
NVR510経由のSIP接続回線も発着信可能だが音声受信ができない。

「0120-000113」へ携帯電話から問い合わせ。

PR-600MIの「アラーム」ランプが点灯しているため交換となった。




最短で翌日（9月18日午前中）配送で交換することになった。
クロネコヤマトで配送されてきた。
・PR-600MIの「メンテナンス」「設定値の保存＆復元」設定値を保存
・機器の取り外し（電源、電話線、ネットワークケーブル、TVアンテナ、光ファイバー）
・機器取り替え（電源ユニット共）
・機器設置（電源、電話線、ネットワークケーブル、TVアンテナ、光ファイバー）

今までは、NTTに連絡して交換した機器のmacアドレスを登録してもらう作業があったが
現在は、30分毎に自動で認識するようになっているとの事（最大で30分で認証ランプが点灯する）

11:28分に電源投入後のひかり電話登録待ち（ランプ点滅）となり、
11:30分に認証ランプ点灯、ひかり電話ランプ点灯

・PR-600MIに直接PCを接続し（DHCPでIPアドレス設定）
・ブラウザで「http://ntt.setup/」に接続し初期パスワードを設定
・「mac address」とIPv6アドレスをメモ
・「メンテナンス」「設定値の保存＆復元」で保存してあったファイルで設定を復元
PR-600MIの交換作業は終了
故障機材を返却梱包し、クロネコヤマトに集荷依頼の電話。
集荷完了。「機器の初期化」を忘れていた・・・

電話機能は復帰したが、インターネット接続が出来ない。IPv6のインターネット接続が出来ない。
macアドレスが変わったため、IPv6のEUI-64アドレスも変わる。
PR-600MI配下のルータにリンクローカルアドレスと共に設定されている。
PrefixDelegationの監視スクリプトなどに記載のEUI-64アドレスの変更も必要になった。
以上、想定内の設定変更を実施。

PR-600MI配布のPrefixが設計通りに配布されない。
自作の「RebindAllISC」スクリプトで設計に従ったPrefixDelegationが行われるはずなのだが・・・
原因の解明に2時間ほどかかってしまった・・・・

PR-600MIの初期パスワードを変更した事が原因だった。
スクリプトのhttpアクセスが認証で失敗していた。
PR-600MIのパスワード設定を戻して対応した。

落雷による障害発生の原因を推察してみた
ひかり電話の構成図

ひかり電話導入前の屋内配線をそのまま利用し、2階に設置してあるPR-600MIの「電話機1」から電話コンセントで1階の電話機（VE-GP03）へ接続。「電話機2」から電話FAX機（KX-PD102）へ接続。PR-600MIとNVR510をSIP接続しNVR510の「TEL2」に電話機（VE-GP50）が接続されている。
落雷時に屋外からの電話線を経由してサージ電圧が発生
屋外からの2対電話線のうち1対を2階と1階を接続するために利用している
数メートルの間2対ケーブルが撚られているのでサージ電圧が誘導されたものと考えられる
症状的にも「電話機1」に接続された電話機の状態がおかしかった。
屋外のNTT分岐点にSPDが挿入されているはずなのだが効果が無かったという事か？

PR-600MIへの変更前PR-S300SE導入時に「サンダーカット＜Ａー２＞」が付属してきた。電源（AC100V）と電話線間に接続するSPD。PR-600MIの電源に接続していたが電話線側は未使用だった。
アース線の設置が難しいが検討することにした。
使用していない屋外の電話線を屋内へのNTT分岐点で切断する事も検討する。

「ひかり電話 HGW PR-600MI 電話インターフェースが落雷で障害」
「ひかり電話 HGW PR-600MI 電話インターフェースが落雷で障害（対策）」
「ひかり電話 HGW PR-600MI 電話インターフェースが落雷で障害（分析）」
「ひかり電話 HGW PR-600MI 電話インターフェースが落雷で障害（分析2）」