IT - Yano's digital garage

メールアドレス偽装による「なりすましメール」と高をくくっていたのだが、たまにチェックしてたらSPFをPASSしているものが目につくようになってきた。問題のメールそのものは確認できないので微妙だが、踏み台リレーにされているような形跡も確認できない事から送信元IPアドレスが詐称されている可能性が考えられる。

名前やメールアドレスよりは難易度は高いものの、その筋の知識があればIPアドレス詐称は容易にできてしまい、いずれも完全に防ぐ事が難しいので、電子署名によるDKIMを導入することに。

というわけで、OpenDKIMをインストール。参考までOpenDMARCはチェックする側の方だ。

ドメインは複数あるものの、メール送受信で使っているのはほぼほぼbravotouring.comだけなので、シングルドメインの設定。

root@vps:~# apt install opendkim opendkim-tools
root@vps:~# mkdir /etc/opendkim
root@vps:~# mkdir /etc/opendkim/key
root@vps:~# mkdir /etc/opendkim/key/bravotouring.com
root@vps:~# opendkim-genkey -D /etc/opendkim/key/bravotouring.com/ -d bravotouring.com -s default
root@vps:~# chown -R opendkim:opendkim /etc/opendkim/key
root@vps:~# cat << '_EOF_' >> /etc/opendkim.conf
Domain                bravotouring.com
KeyFile               /etc/opendkim/key/bravotouring.com/default.private
Selector              default
Canonicalization      simple
Mode                  sv
SubDomains            no
ADSPAction            continue
_EOF_
root@vps:~# cat << '_EOF_' >> /etc/default/opendkim
SOCKET="inet:8891@localhost"
_EOF_
root@vps:~# service opendkim restart
root@vps:~# vi /etc/postfix/main.cf
root@vps:~# cat << '_EOF_' >> /etc/postfix/main.cf
milter_default_action = accept
non_smtpd_milters = $smtpd_milters
smtpd_milters = inet:localhost:8891
_EOF_
root@vps:~# postfix check
root@vps:~# service postfix reload
root@vps:~# postconf | egrep 'milter_default_action|non_smtpd_milters|smtpd_milters'
root@vps:~# vi /etc/opendkim/key/bravotouring.com/default.txt /etc/nsd/zones/bravotouring.com.zone
～～ zoneファイルに_domainkey公開鍵のTXTレコードを追加 ～～
root@vps:~# nsd-control reload
root@vps:~#

最終的にgmailのアドレス宛に送信して

2020年度上半期決算も終え、いよいよ下半期スタート。

という秋の朝を揺るがしたショッキングなニュース。

システム障害の経緯について東証は、午前7時4分ごろ、「arrowhead」（アローヘッド）と呼ばれる株式売買システムの内部に2台あるストレージシステム「共有ディスク装置」の1号機に異常が発生したと説明する。異常の原因は装置のメモリ故障という。　通常であれば1号機に異常が発生しても2号機に自動的に切り替わる設定になっているはずだったが、何らかの理由で切り替わらなかったとしている。この結果として、arrowheadの情報配信処理や売買監視システムに異常が発生したことから、午前8時54分にネットワークを遮断し、取引を停止したとしている。　東証は2019年11月にarrowheadを刷新したばかり。現システムの稼働から1年足らずで今回の障害が発生した。メモリの故障や切り替えが動作しなかった原因については、システム開発元の富士通とともに原因を究明するとしている。

との事。

何らかの理由が気になるが、取り敢えず、慌てて午後から再開して各方面に無駄な混乱を招くよりは潔く終日全取引を停止したのは好判断だったと思う。

参照

NHKニュース https://www3.nhk.or.jp/news/

【動画解説】東京証券取引所全銘柄の取り引きを停止 2020年10月1日
東証システムトラブル宮原社長らが陳謝 2020年10月1日

ITmedia NEWS https://www.itmedia.co.jp/news/

東証、全銘柄の売買を停止　相場情報配信の障害で 2020年10月1日
東証、全取引を終日停止　システム障害の復旧めど立たず 2020年10月1日
東証の障害、原因は「機器故障とバックアップへの切り替え失敗」 2020年10月1日
東証、システム障害で謝罪　詳細な経緯説明、当面は「人的監視」で対応 2020年10月1日

日本取引所グループ https://www.jpx.co.jp/

障害に伴う売買の停止について【第4報・終日売買停止】 2020年10月1日

Wikipedia https://ja.wikipedia.org/wiki/

東京証券取引所

ASRock H97 Pro4にXeon E3-1265L v3を載せたHaswell。

先月Ubuntu 20.04 Serverに入替えたのだが、時間がずれている？事に気づいたらタイムゾーンがJSTになっていなかった。

GUIならばいざしらず、CUIだとどうすんだ？というわけで、ググるとtimedatectlだとあっさりわかり、万事解決。

root@haswell:~# ll
total 44
drwx------  4 root root  4096 Oct  1 07:59 ./
drwxr-xr-x 20 root root  4096 Sep 24 02:08 ../
-rw-------  1 root root   630 Sep 24 06:48 .bash_history
-rw-r--r--  1 root root  3106 Dec  5  2019 .bashrc
-rw-r--r--  1 root root   161 Dec  5  2019 .profile
drwxr-xr-x  3 root root  4096 Sep 24 02:18 snap/
drwx------  2 root root  4096 Sep 24 02:17 .ssh/
-rw-------  1 root root 13436 **Oct  1 07:59** .viminfo
root@haswell:~# date
Thu 01 Oct 2020 08:20:21 AM UTC
root@haswell:~# `timedatectl`
               Local time: Thu 2020-10-01 08:20:32 UTC
           Universal time: Thu 2020-10-01 08:20:32 UTC
                 RTC time: Thu 2020-10-01 08:20:32
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
root@haswell:~#
root@haswell:~# `timedatectl set-timezone Asia/Tokyo`
root@haswell:~# `timedatectl`
               Local time: Thu 2020-10-01 17:20:46 JST
           Universal time: Thu 2020-10-01 08:20:46 UTC
                 RTC time: Thu 2020-10-01 08:20:46
                Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
root@haswell:~# date
Thu 01 Oct 2020 05:20:51 PM JST
root@haswell:~#

参照

Server World https://www.server-world.info/

楽天モバイルが5Gサービス開始月額2980円で自社エリアは使い放題 — ITmedia Mobile記事より

楽天モバイルが9月30日付けで5Gサービスの開始と、注目の5G対応新料金プラン「Rakuten UN-LIMIT V（ファイブ）」を発表。

まさかの5G対応分の料金上乗せなしで『月額2980円の料金そのまま』、他キャリアの割引料金と比較しても半額以下というのはインパクト大だ。

当然ながら5Gサービス自体は他社同様にミニマムスタート。auへのローミングも対象外なのは折り込み済みなので、実際に5Gが使えるのはまだまだ先の話だが、8月には自宅周辺まで楽天回線エリアになってたので意外と早いのかもな～。

参照

ITmedia Mobile https://www.itmedia.co.jp/mobile/

楽天モバイル https://mobile.rakuten.co.jp/

Wikipedia https://ja.wikipedia.org/wiki/

先週発行した「マイナンバーカード」。

…の利用者証明用電子証明書更新手続き。

呑気に「昼過ぎなら多少空いているかな～」と出掛けたところ、13時50分の受付で40人待ち。

手続完了まで2時間かかると言われた金曜日の倍以上の人数で、呼び出しまで一人3分としても2時間かかる計算だ。

受付票のQRコードから福岡市東区市民課窓口混雑状況案内にアクセスしWebブラウザで呼び出し状況が確認できる事がわかったので、一旦帰宅。

呼び出しのタイミングを見計らって15時半に再度出動し、状況を説明して確認を依頼したところ、7月26日の申請において「電子証明書不要」にチェックが入っていた事が判明。どうやら**「署名用電子証明書」と混同した"うっかりさん"は自分の方だった**と判明。f(^^;;

ていうか、マイナンバーカード交付申請時に

マイナポイントの手続のためには、利用者証明用電子証明書が必要となります。

というのがわからないので、もちょっとアピールした方がいいと思うよ。

そもそも電子証明書自体は役所で入れたり消したりできるので、カード申請時の事前チェックなんて不要なはず。しかも、交付時に役所の窓口で子どもの分まで暗証番号を書いているので気を利かせて気付いてくれれば助かったのだが、毎日何百人も相手にしてたらそんな余裕も無いのだろう。ご愁傷さまだ。

参照

福岡市東区 https://www.city.fukuoka.lg.jp/higashiku/

市民課窓口混雑状況案内

マイナンバーカード総合サイト https://www.kojinbango-card.go.jp/

公的個人認証サービスポータルサイト https://www.jpki.go.jp/

電子証明書のご用意

Wikipedia https://ja.wikipedia.org/wiki/

7月26日に申請した「マイナンバーカード」。

…の交付通知書が16日に到着。

15歳未満の未成年者の方の予約・申込については、法定代理人が行うことができます。

という事から子どもの分も申請したのだが、受け取りには本人を連れて行かなくてはならないという事が判明し、結局家族5人で区役所に出向く羽目に。

翌週だと連休明けで混雑は必至だろうと金曜日の夕方に出向いたのだが、それでも17人待ちで交付完了まで2時間ほどかかると宣告された。

まぁ、小一時間ほど筥崎宮周辺をウロウロし、後半は待合スペースでYouTubeを観せて暇つぶしつつ、無事に交付完了。

ちなみに東区役所は楽天回線エリアだが、1Fの市民課フロアでは楽天回線のBand3(1.7GHz)ではなくauローミングのBand18(800MHz)を掴んでいたものの、電波強度が足りず通信不可。auモデルのXperia XZ3やiPhone SEはしっかり通信できてたので、なんで？と思ったらBand1(2GHz)を掴んでいた。

で、本日マイナポイント登録してみたところ、子どもたちの分は