ワンタイムパスワードとの2要素認証
このサーバーのBlogやメールサーバーへのログインをSSLクライアント証明書による認証に切り替えた話を書いた。
このとき今後の課題についてこんなことを書いた。
あと類似するところでSSHのログイン用の秘密鍵の管理も課題がある。
ローカルに配置するとその端末でしかログインできない、
かといってオンラインストレージにおくと流出の懸念なしとは言えない。
というわけで、SSHのログイン方法の見直しを行っていた。
オンラインストレージからの流出は本当に恐れるべきことなのかというのはある。
とはいえ、鍵データだけに依存する状況もよくない。
一応、鍵データを紛失したときのワークアラウンドとしては、VPSのコントロールパネルから操作するという方法がある。
これはsudoが効かなくなったときのワークアラウンドでもある。(コンソールではrootへのログインもできるので)
ただ、SSHのログインに使える「物」が、鍵データ以外にあってもよいと思う。
いろいろ調べて、いろいろ考えた結果、
鍵データ または Google認証システムのワンタイムパスワード+Linuxのパスワードというところに落ち着いた。
まず、SSHの鍵認証は単独でも十分に安全性が高いといってよいだろう。利便性も高い。
ただし、鍵データの管理に十分注意が必要なので、本来は鍵データはむやみやたらに持ち出さないだろうと。
鍵データを持っていない場合、あるいは紛失した場合の代替手段としては「物」と「知識」による2要素認証だろうと。
知識はLinux自体のパスワードでよいと思うが、物を何にするかは少し迷った。
住信SBIネット銀行のログインロック機能のように、端末操作を行った後、しばらく認証が通る方法も考えた。
ただ、SSHをどんなときに使うかと考えてみると、他のサービスが正しく動作していないときに使うことも多い。
そうなるとSSH単独で他のサービスに依存せずに動く方式がよいだろうと。
そこでGoogle認証システムである。
Googleとは付いているけど、Googleが開発したってだけで、Googleのサービスに依存して動くものではない。
Google認証システムはワンタイムパスワードを生成するアプリで、このアプリの入った端末はオフラインでもよい。
オープンソースのワンタイムパスワードのシステムとして普及したものである。
そこら辺にいくらでも導入方法は書いてあるが、ここにも書いておく。
SSHでGoogle認証システムを使う場合は、PAM認証のプラグインとして導入する。
yumでインストール出来なかったので、ソースコードでダウンロードしてきてインストールする。
google/google-authenticator-libpam (GitHub)
書いてある通りにビルドすると /usr/local/lib/security/ にインストールされるので、/etc/pam.d/sshdの先頭に次の一行を追加する。
auth requisite /usr/local/lib/security/pam_google_authenticator.so
これにより、Google認証システムによるワンタイムパスワード認証が通れば、従来のパスワード認証に進むということになる。
requisite を require にすると、失敗してもそれを隠して次に進む。
どちらがよいかは場合によるだろうが、今回はワンタイムパスワードでだめでしたとすぐわかる方がよいだろうと。
これでsshdのPAM認証がワンタイムパスワード+Linuxのパスワード認証 になったので、これを使う設定をsshd_configにする。
PasswordAuthentication no
ChallengeResponseAuthentication yes
UsePAM yes
パスワード認証とチャレンジレスポンス認証の両方を切ると鍵認証強制になるが、
チャレンジレスポンス認証を有効化した上で、PAM認証とすると、先ほど設定したPAMの認証が使えると。
あとは各ユーザーでGoogle認証システムの設定を行う。
$ google-authenticator -t -d -e 0 -r 2 -R 30 -w 2 -Q UTF8 -l "Libserver SSH"
Google認証システムの初期化にはQRコードを使うと便利なので、qrencodeをインストールしておく。
その上でこのコマンドを実行すると、コンソールに巨大なQRコードが表示される。
これをAndroidまたはiOSにインストールしたGoogle認証システムで読み取ると、
端末にワンタイムパスワードが出るので、これを確認に入力すれば、認証情報が~/.google_authenticatorに格納される。
いろいろオプションを付けたが、これを付けないといろんなことを聞かれるので。
"-t -d"は時間ベースのワンタイムパスワードで同一コードの再利用禁止、
"-e 0"は非常用コードなし、これはGoogle認証システムが使えないときのワークアラウンドは鍵認証と考えているから。
"-r 2 -R 30 "は30秒間に2回まで再試行可能、"-w 2"は最近2回(30秒ごと更新なので1分以内)のコードが有効、
"-Q UTF8"はUTF-8環境でのQRコード表示、-l オプションはGoogle認証システムでの表示名。
なお、QRコードが表示できない場合は、secret keyの文字をアプリに入れるか、相当するQRコードを作ればよい。
GoogleのQRコード生成用URLで生成してもよいが「キーがGoogleに漏れるから注意」と書かれている。
これで、あとは実際にSSHで使うだけ。
Using username "hidemaro".
Keyboard-interactive authentication prompts from server:
| Verification code: (ワンタイムパスワードを入力)
| Password: (Linuxのパスワードを入力)
End of keyboard-interactive prompts from server
まぁこんな感じですね。
この認証方式ってSFTPでも使えるのかなと、FileZillaの設定を見てみたら「インタラクティブ」てのがあるんですね。
これを選ぶと、対話的に2つのパスワードを聞いてくれる。
Pageantに鍵データを読み込んでいれば何もきかれずログイン成立となる。
以前はFileZillaで鍵認証するにはPageantで鍵データを読み込んだ状態で、ダミーのパスワードを設定してたものだが。
これが完了したところで、新しい鍵データを作って、改めて公開鍵を登録し直して、秘密鍵はローカル保存にした。
秘密鍵が使えないときは2要素認証で、Google認証システムが使えないときは鍵認証で、これで安心ですね。
一度ログインできれば、新しい鍵を登録することもできるし、
PAMつながりでもう1つ。
パスワード見直しの一環で、Linuxのパスワードも見直したが、けっこう長いパスワードになった。
ログインするときはよいが、sudoするたびにこの長いパスワードを入れるのはいやだ。
パスワードなしでsudoできるようにしてもよいが、ちょっとなぁと。
そこでsudo用のパスワードを別設定して、数字数桁のPINコードで認証するようにした。
pam_userdb.soというモジュールを使って、別に用意したパスワードデータベースで認証出来るようだ。
ただ、これの使用例を調べると、平文でパスワードをデータベースに格納しているので、それはおかしいだろうと。
$ echo "username" > db.in
$ perl -e "print crypt('xxxxxx',sprintf('\$6\$%08x',rand 0xFFFFFFFF)).\"\\n\"" >> db.in
# db_load -T -t hash -f db.in /etc/sudo_pw.db
ユーザー名とパスワードを交互に書いたテキストファイルを作って、/etc/sudo_pw.db のデータベースに格納するのだが、
pam_userdb.soではcryptされたパスワードを受け入れることも出来る。
じゃあ、どうやってcryptするのかって、perlのcrypt関数を使うのがよいだろうと。
引数の2つ目に暗号化方式とSaltを指定するのだが、"$6$xxxxxxxx"とすると、
SHA512方式(最近のLinuxでは標準)で、xxxxxxxxというSaltを付けて、1つ目の引数を暗号化するという意味になる。
Saltは乱数を16進数表記にすることで8文字作るようにした。こんなもんでいいでしょう。
その上で、/etc/pam.d/sudo にsudo時の認証方式を記載する。こちらはまっさらにして次の通り。
auth required pam_userdb.so crypt=crypt db=/etc/sudo_pw
account required pam_userdb.so crypt=crypt db=/etc/sudo_pw
session optional pam_keyinit.so revoke
password requisite pam_cracklib.so try_first_pass retry=3 type=
/etc/sudo_pwというデータベース(dbという拡張子がないことに注意)に、パスワードはcrypt形式で暗号化したので認証と。
keyinit.soはオリジナルの設定、pam_cracklib.soはinclude先のsystem-authにあったから書いたけど、意味があるかは知らない。
あと、sudo実行時に表示されるプロンプトに"password"って書いてあると勘違いしそうなので、
/etc/sudoers (visudoコマンドで編集する)でプロンプトを変更した。
Defaults passprompt="PIN for %u:"
これでPINを入力するように読めるからいいんじゃないかなと。
Author : Hidemaro
Date : 2019/11/30(Sat) 23:45
コンピュータ・インターネット | Comment | trackback (0)
大嘗宮を見る
今日は午後に休暇を取ってお出かけしていた。
メインの目的地は皇居、大嘗宮の一般公開ですね。
皇居もいろいろ門があるけど、この一般公開では坂下門から入ることになっている。
坂下門ってどこから行くのがよいのかと地図を見たが、うちからだと東京駅だった。
桜田門駅が一番近いのかな。それに次いで二重橋前駅、どちらもうちからは行きにくいのだが。
東京駅で降りると、大嘗宮一般公開へ行く人は丸の内南口を出てと放送が流れていた。
東京駅というと、高速バス乗り場としてやってくることが多く、そうなると八重洲側なのだが、
丸の内側にやってくることもあって、それが晴海通りのバスに乗る時。東京駅ってバス乗り場だったか。
それはさておき、東京駅を出て、行幸通りを進むと、同じ方向へ向かう人がぞろぞろと。
お堀を渡ると、ここからは国民公園「皇居外苑」ということで、環境省の名前で看板が立っていた。
それで突き当たると、順路は左に曲げられる。そして、大量のカラーコーンが並べられた皇居前広場へ。
今日は全体的にはスムーズに人が流れていて、行列をなすことはあまりなかったのだが、
休日などで人が集中したときは、この広場に行列をつくって調整するのだろう。
このカラーコーンには「警視庁」のシールが貼られ、警備にあたっているのは警視庁の警察官。
すなわち、東京都の職員と設備を使って、大量の見学者の整理を行っているということ。それもお役目かね。
入口では手荷物検査と金属探知機による検査がある。
手荷物検査は普段から皇居内の庭園に入る人には課されているものだが、
水筒を見つけたら「一口飲んで」と、やや厳重。
検査が終わったところに待ち合わせポイントがあった。グループでやってきたときに再集結するポイントなのか。
そして、坂下門から皇居の敷地内に入る。
坂下門を過ぎると、さっきまで警察官が多かったのは嘘のように落ち着いた雰囲気。
警察官らしきはいるのだが、皇宮警察本部の職員、敷地外の公共区域は警視庁、皇居内は皇宮警察という役割分担なのか。
皇居というのは、江戸城跡でもある。
今回、大嘗宮が建てられたのは本丸の中、普段は皇居東御苑として一般公開されているエリアである。
江戸城にとっての中心だったが、現在の皇居にとってはあまり重要でもないところなんだよね。
それゆえに一般公開されているわけだし、大嘗宮を建てるにもちょうどよかったということなのかなと。
かつての江戸城を感じながら、見学できるのはいいことだと思いますけどね。
それで大嘗宮である。やはりこのために作っただけあってピカピカ。
今どき木造建築といえば、寺社のように長く使われることを想定した作りのものを見慣れていたが、
大嘗宮は仮設ということで、やや荒削りな印象も受ける。それがいいんでしょうけどね。
それと特徴的なのが随所で使われている皮付きの丸太、黒木造りというスタイル。
あまり建造物では見ない使い方なので戸惑うが、いいアクセントにはなってますね。
けど、皮ごと使うということは、削って形を整えられないということなので、木の選定は難しいよね。
各所に設けられた黒木灯籠、皮付きの木材の組み合わせで作られ、細い木もうまく使っているように見える。
しかし、削らずに所望の太さで、まっすぐで、皮まで美しいという条件を揃えるのは難しそう。
加工度の低さゆえの難しさってのは多そうだなと思った。
大嘗宮の正面では写真撮影する人が折り重なり詰まっていた。
僕は写真を撮るのも惜しいと、あれこれと観察していたんだけどさ。
少し左右にずれると、まだ身動きは取れるのだが、真っ正面ではゆっくり進んでと呼びかけてもなかなか。
ここがこの大嘗宮公開の最大のボトルネックでしょうね。
大嘗宮の敷地を外周から見学するのだが、正面の見学ルートは狭く、さらに真っ正面はひどく詰まる。
逆に裏側は広場からゆっくり観察できる。正面で見学しようと思わない方がいいのかもしれない。
あと、今回取り入れられたプレハブ造の建物、儀式の中核をなす建物ではないが、
儀式をしているところから見えることもあって、他の建物と同じようにむしろ張りになっている。
ということで案外調和しているのだが、そうなると気になるのが白い屋根。
板葺き屋根と調和する色だとなおよし、とは思ったがそういう選択肢はなかったのかもしれない。
もともと儀式の周辺にはテントなどが多く(それは前回もそう)、写真で見るとその白い屋根が目立っちゃうんだよね。
儀式の中核に関わる部分は見せないとはもともと言っていたが、建物だけでもいろいろ学びはあった。
そこから、出口はまったく別の方向で平川門、ここは竹橋駅が近い。
ここから電車に乗ってやってきたのは上野公園である。
半日とはいえ、せっかく休暇を取るんだからと、夜間開館日の博物館にやってきたと。
ミュージアムシアターで正倉院についてのVR作品をやっているので、それを見つつ、博物館も見て回ろうと。
ミュージアムシアターは月・火はお休みで、16時開始が最終回(夜間開館日でも)ということで、
大嘗宮を見学してから行くにはちょうどいいんじゃないかと。
正倉院内部をVRで見せるという作品で、現物を見られないものを見せるという点ではよい題材。
今までミュージアムシアターは無料券で見るばかりだったが、今回は500円払って見た。
その後、さらに中央通りを下って、秋葉原界隈へ。
ソフマップでソフマップカードの返却をして(cf. ラクウルはいかなるものか)、
中古品の売り場を見ていたら掘り出し物を見つけたので買って、それで帰ってきた。
なにかと充実した金曜の午後でしたね。
Author : Hidemaro
Date : 2019/11/29(Fri) 23:54
日常 | Comment | trackback (0)
テレビ会議で操作をサポート
ここのところ、社外の試験場に出張している人がいる。
試験開始時はいろいろなトラブルが相次ぎ、当初の計画は早くも崩れたそうだが、
立て直しを図り、なんとか軌道に乗ったと思ったら、なにやらエラーが出たよう。
それで、社内にいるチームリーダーが、こんなことが起きてるんだけど、と相談に来るので、
話を聞くと、どうもエラーは誤爆っぽい。
エラーメッセージを送ってもらって、明らかに誤爆であることはわかった。
それで少し考えたが、設定を変更するとこのエラーを消すことができることに気づいた。
試験項目によってはエラーメッセージを切ることは許されないのだが、
チームリーダーに確認すると、必要な試験はもう終わったとのこと。じゃあ切ろう。
そのためには、試験対象のシステムの設定変更をしなければならないが、
問題は今日、試験場に出張している人は、この設定変更の経験がないということ。
担当者の1人には操作方法を教えたので、E-mailや電話で指示をしてもなんとかなりそうだったのだが、
あいにく今日は出張していないので、そこに期待することは出来ない。
そこでどうしたかというと、テレビ会議を使った。
業務用ノートPCにはインカメラが付いている。それを試験場に持ち出してますからね。
インカメラで、システムにつながっているコンピュータの画面を映してもらったのだ。
幸いにして、今回の試験室は狭く、おかげでLANケーブルを試験室内に引き延ばせて、
インカメラの画質でわかるかどうか心配だったが、操作画面を判別するには十分だった。
やはり画面を見ながら操作を指示すると、的確に指示ができて、これまで経験がない人でもなんとかなった。
コンピュータの画面をインカメラに映すなんて、まどろっこしいことをするんだな、
と思ったかも知れないが、操作用のコンピュータがインターネット接続を想定した設定になっていないんだよね。
社内ネットワークへは明確に接続できない設定なのだが、社外ならそこのポリシーさえ満たせればなんとでも。
ただ、長きにわたりネットワークから切り離され、セキュリティ対策がろくにされていないのと、
社内ネットワークに明確に接続できない理由の1つでもあるけど、
システム用にネットワーク関係の設定をカスタマイズしてるから、なかなか難しいかなぁと。
テレビ会議も慣れだなとは思った。
これでも、普段からインスタントメッセンジャーとして使っているソフトでテレビ会議ができるだけよくて、
以前はテレビ会議対応の会議室同士をつないでやるしかなく、ハードルが高かったようなことも聞いている。
今回みたいに出張先で急遽テレビ会議を開く方法はなかっただろう。
もちろん、現在でも高品質の会議をしたければ専用の会議室で、備え付けの専用システムを使うべきだが、
設定にかかる手間を考えれば、簡易な方法でも実用上問題ないという考えは普及していた。
こんな簡易なので、ちゃんと指示できるかなぁとは思ってたけど、案外いけますね。
Author : Hidemaro
Date : 2019/11/28(Thu) 23:09
コンピュータ・インターネット | Comment | trackback (0)
ラクウルはいかなるものか
僕はビックカメラの株主なのだが、株主向けの事業報告書にクーポンが付いていた。
クーポンというのは、ポイント割増(キャンペーンで時々配布してるのと同じようなもの)と、
もう1つが「ラクウル」の買取金額割増クーポンである。
この割増というのが定額の割増で、買取金額いくら以上とかいう制限はない。
株主向けとはいえ、大盤振る舞いだなと思った。
ラクウル はソフマップがやっている通信買取サービスである。
ソフマップがビックカメラの傘下に入ったのは2006年のことだそう。
ソフマップへ期待するところはいくつかあったんだろうけど、その筆頭が中古品の取扱なんじゃないか。
ビックカメラ内に中古品や音楽・ゲームソフトの取扱を中心とした店舗を出しているのはそういうことじゃないかと。
ソフマップに長年蓄積された中古品の買取・再商品化・販売のノウハウに期待するところは多いようだ。
ビックカメラグループの新しい通信買取サービス「ラクウル」がソフマップのサービスなのは必然である。
通信買取というと、ある程度の物量がないと送料負担が気になるところだが、ラクウルは送料無料という。
なんか条件とかないのと調べたけど、物量に関する条件は全くなさそう。
条件は160サイズの箱に収まることぐらいに見える。
手元になんか売れそうなものがあったかなとおもったが、映像ソフトが2本あった。
1つは以前、他の中古屋に売りにいったらあまりに安くて、売る気になれなかったもの。
もう1つは、今度中古屋にガサガサと持って行くなら持って行こうと思っていたもの。
同時期にPayPayモールの送料負担キャンペーンに乗じていろいろ売りにだしていたけど、
この2つは手間に対して割に合わないだろうと判断していたので、ラクウルというのはちょうどよかった。
というわけで、集荷依頼を出した。箱も無料で用意してくれるらしい。
申し込んだ翌々日、ヤマト運輸の人がやってきて、物を手づかみで持って行った。
てっきり空箱を持ってきて、玄関先で収納するのかと思ったが、集配車の中で詰めるんですかね。
ともあれ、そこからソフマップの浦安センターに運ばれ(近いのに翌々日着だった)、そこから査定。
査定完了になったのは申込みから1週間後、集荷・配送にかかった時間を考えると、まぁまぁ早いかな。
他の中古屋に売りにいったら安かったという商品は、そのときよりは高い値段が付いた。
もう1つは「買取対象外品」という扱いだった。
値段が付かないほど価値がないのか、そもそも取扱対象ではなかったのか。
真相はわからないが、返却してもらうほどのものではないので、そのまま承認とした。
ちなみに返却の送料も無料らしい。
クーポン割増分を除いても思ったよりは高かったが、買取総額の4割以上はクーポンっですからね。
ラクウルの買取金は、ビック買取マネーにすれば10%増し、現金振込だと手数料負担250円となっている。
ビック買取マネーってのは、かつての プールポイント → ソフマップ買取ポイント のことだよね。
ビックカメラ・ソフマップ・コジマのポイントカードは実店舗では相互に積算・使用ができるが、
買取ポイントはソフマップカード独自機能の状態が続いていた。
このたびビックカメラ・コジマにも展開されたことで、名前が変わったって話ですね。
僕はビックカメラにもソフマップにもポイントカードを持っているが、現在は基本的にビックカメラに積算している。
その考えからすれば、今回の買取金もビックカメラに積めばよさそうだが、後で書く理由によりソフマップに積んだ。
ビック買取マネーを使うにしても、銀行口座の確認が必要になっている。
その方法はなんと1円振込が成立するかどうか。この1円はソフマップからのプレゼントである。
実際に使ってみての感想だが、確かに送ればそれで終わりなのは楽。
ソフマップといえば、PC本体・周辺機器とゲーム・映像ソフト、ここは間違えなく強い。
ただ、ラクウルでは他の古物商とも提携していて、服飾品・ゴルフ用品・楽器・酒(!?)なんていうのも入っている。
家庭の不用品まとめて引き取りますというところで考えているようだ。
やはり、それぞれ実績のあるところと組んでいるのは安心感もあるんじゃないか。
買取金の払い出しがビック買取マネーでほぼ一択なのは気になるけど(ヤフオク・PayPayフリマのPayPayと比べるとね)、
ビックカメラの実店舗はいろいろなもの置いてるから、店に行けばなんとでもなるだろうし、
ソフマップカードのビック買取マネーに払い出せば、ソフマップの通販でも使えますので。
さて、ラクウルといえば、現在こんなキャンペーンをやっている。
ラクウルにソフマップカードを登録した上で、ソフマップカードを店舗に提出すると、
その種類に応じて1000～300ビック買取マネーが付与されるというもの。
ラクウルのウォレット機能は、ポイントカードを店頭で表示する機能を兼ねている。
なのでポイントカード代替というところをきっかけにして、ラクウルに触れてもらおうという意図もあるのではないかと。
僕の持っている青色のソフマップカードは500ビック買取マネーもらえるということで、今度東京に行ったらやろうと。
ソフマップでもビックカメラSuicaカードを呈示するようになって、引き出しの中にしまっていたのだが、
これを機に返却して、バーチャル化してしまおうと思う。
捨てずに引き出しの中にしまっていたのは、ソフマップの通販では依然として紐付いているからというのもある。
実店舗のポイントカードはどれか1つあれば相互に使えるが、通販のポイントは各社独立してるんだよね。
インターネットで申し込めば、即時ポイント交換できるので、通販だけ各社独立してるデメリットは薄れたが。
いずれにせよ、どうしてもポイントカードがいる理由はもはやない。
Author : Hidemaro
Date : 2019/11/27(Wed) 23:54
買い物・消費 | Comment | trackback (0)
メールサーバー間でSMTPS使うの?
メールサーバーに手を入れているときに、GmailではSMTPSで受信したか否かで表示が変わるらしい。
暗号化のアイコンの意味ということで書かれているが、
まず、緑色の鍵マークはS/MIMEで暗号化されているということで、これは明確な暗号化である。
ただ、S/MIMEによる暗号化をするには、送受信双方に電子証明書が必要なので、ほぼ使われていないかと。
赤色で鍵が破れた表示になっているのは、平文のSMTPで受信したメール。伝統的なE-mailですね。
その間に灰色の鍵マークがあるが、これはTLSで受信したということを指している。
鍵がかかった絵で描かれているので、Googleの認識はTLSで受信したメールは暗号化されているということらしい。
最初に「SMTPSで受信したか否かで」と書いたのは、あまり適切な書き方ではなかったね。
SMTPSはSSLによって暗号化されたSMTPプロトコルを表す言い方だった。
SMTP+SSL=SMTPSということで、SSLで暗号化されたHTTPSをHTTPSと書くのと同じ。
現在はSSLはTLSと言い方が変わっているので、TLSによって保護された――というのが正しい。
SMTPSと書いた場合、ポート465を使って、いきなりTLSで通信を開始するものを指すのが通常である。
一方で、SMTPは、途中からTLS通信への切り替えを行う STARTTLS というモードを備えている。
この場合、ポート587(サブミッションポート)あるいは、ポート25 でもTLSを使って通信内容を暗号化できる。
そもそも、SMTPはE-mailを他のサーバーに転送するプロトコルである。
ユーザーがプロバイダーのメールサーバーに転送するのも、そこからあて先のメールサーバーに転送するのも同じ。
これが迷惑メールの温床となっていたので、従来のポート25でのSMTPはメールサーバー間の転送のみに使い、
プロバイダーは一般ユーザーのポート25の使用を禁止して(OP25B)、
ユーザーがプロバイダーに接続するにはサブミッションポートという別ポートを使い、何らかの認証をするようにした。
SMTPでパスワード認証を行う SMTP-AUTH の場合、特に認証情報の暗号化の必要性も高いので、
SSL版サブミッションポートとしてポート465が使われることになったそうである。
もっとも、ポート587で必要によってSTARTTLSでTLSに切り替える方が標準的な方法らしいけどね。
必要によって切り替えるといっても、TLSに切り替えないと認証が通らず結局使えないことが多いと思うが。
というわけで、TLSによる暗号化をSMTPに適用するのは、ユーザーがメールを送信するためのものだと思っていた。
ただ、メールサーバー間の転送に使うポート25にSTARTTLSを適用することもできる。
Gmailのメールサーバーではポート25でもSTARTTLSを受け入れ、送信先のメールサーバーがTLS対応ならSTARTTLSを適用しているようである。
理屈上できるなぁとは気づいてたんだけど、実際にやってるところがあるとは、今まで知らなかった。
ましてやそれを一般ユーザーに向けて表示して、TLSが適用されなかった場合は警告的に表示しているとは。
僕がポート25へのSTARTTLSに懐疑的だったのは、メールサーバー間の暗号化は保証できるかもしれないが、
全てのメールサーバーがSTARTTLSに対応しているならともかく、対応していない方が多く、
TLS非対応のサーバーとはメールがやりとりできないとすると、とても使えたもんではない。
さらに、メールサーバーの前後の暗号化も明らかではなく、ここだけ暗号化しても意味はないんじゃないかと。
とはいえ、大昔のメールサーバーはメールサーバーをバケツリレーのように転送していたというけど、
現在はほとんどのE-mailのSMTPのフローは 送信者 → メールサーバー → メールサーバー の2段階で終わり。
送信者のクライアントがメールサーバーに接続するには、今はほとんどTLSが使われているだろう。
そう考えると、実用上は送信者から受信者のメールボックスまでずっと暗号化されてると見てよいと。
Gmailの表示の意図はそういうことなんじゃないか。
すでに、Let's Encryptでまともなサーバー証明書を持っていて、TLS自体はすでにポート465で使っている。
なので、Postfixに少し設定を加えるだけで対応できる。
まず、master.cf。
smtp inet n - n - - smtpd
-o smtpd_tls_security_level=may
smtps inet n - n - - smtpd
-o smtpd_tls_wrappermode=yes
-o smtpd_tls_ask_ccert=yes
-o smtpd_sasl_auth_enable=yes
SMTP(ポート25)はTLSの使用を"may"ということで、使いたければ使えるが必須ではないとする。
一方のSMTPS(ポート465)はさっき書いたようにクライアントの認証用なので、
最初からTLSで、クライアント証明書を要求、パスワード認証を有効という設定をしている。
クライアント証明書またはパスワード認証が成立しなければ、他メールサーバーへの転送を許可しない設定は別途している。
(基本はクライアント証明書での認証だが、互換性の問題でパスワード認証も併用、ただしパスワードはPostfix専用のものにした)
裏返せば、ポート25では認証が成立しないということなので、自分のサーバー宛のメールの受信のみできる。
逆に送信側の設定、こちらはmain.cf。
smtp_tls_CAfile = /etc/pki/tls/cert.pem
smtp_tls_security_level = may
smtp_から始まる設定は、SMTPクライアントとしてのPostfixの設定を表している。
そちらでTLSの使用について"may"としているということは、こちらも使える場合だけ使うと言うこと。
これを"encrypt", "verify"にすると、STARTTLS非対応のメールサーバーには送信できなくなる。
あと、CA証明書も必要なので、CentOSにバンドルされてるものを指定したけど、
実はTLSの使用について"may"の設定の場合、証明書の検証結果によらずTLSで接続して送っちゃうんだそうだ。
STARTTLS非対応のサーバーにも平文で送るぐらいだし、接続先は疑わしくともTLSで暗号化できるだけマシということか。
この設定をすると、Gmailに送ったとき、灰色の鍵マークで表示され、逆に受け取ったメールには、
Received: from mail-xxxxxxx.google.com (mail-xxxxxxx.google.com [xx.xx.xx.xx]) by hdmr.org (Postfix) with ESMTPS id xxxxxxxxxx
というヘッダがつき、ESMTPS ということで暗号化して受信されたことが確認出来る。
Thunderbirdで"hdmr.org (Postfix) with ESMTPS"をReceiveに含んでるとマーキングするという設定をして、
参考に見ているけど、届くメールの半分ぐらいがTLSを使ってるみたい。
(Receiveヘッダの偽造まで考えられた厳密な条件ではないので、参考程度の情報だが)
案外、普及してるもんだなと思ったけど、GmailがTLS対応の動機になってたのかもしれない。
あまり意味は無いかも知れないが、平文よりTLSの方がよいのはそうだろう。
現状、平文よりマシという程度の運用なので、STARTTLS対応にしたがために拒否されたということもあまりないだろう。
HTTPSだと証明書の証明期限切れとか起きてると、禍々しい警告が出てくるけど、
それはHTTPSへの期待度が高まった時代だからこそで、以前はここまでではなかったわけだし。
将来的にはどうかわからないけど、SMTPの古さを考えると、なかなか厳しいことも言えないような気はしますね。
Author : Hidemaro
Date : 2019/11/26(Tue) 23:52
コンピュータ・インターネット | Comment | trackback (0)
証明書は自動発行すれば良い
このサーバーのE-mailの認証にSSLクライアント証明書を使うようにしたという話を書いた。
証明書によって認証することで、パスワード認証に伴うリスクは軽減される。
それはよいのだが、秘密鍵の管理というところには少し課題がある。
これまで、証明書の有効期限は100年に設定して、証明書と秘密鍵をセットにしたPKCS#12形式にして、
それをオンラインストレージにおいて、適宜、端末にインポートして使っていた。
オンラインストレージは自分しかアクセス出来ないはずだし、PKCS#12形式のデータにはパスワードがかかっている。
とはいえ、このファイルが流出してパスワードを割られると、何があったかわからないまま認証されてしまう。
証明書発行も手動で手間がかかっていたので、自動化を試みることにした。
そのフローは次の通りである。
- WebサイトにLinuxのユーザー名・パスワードでログインする
- 登録されているE-mailアドレス(例えばGmail)にワンタイムパスワードを送る
- ワンタイムパスワードを確認して、秘密鍵・証明書をサーバーで作成する
- PKCS#12形式(ランダムなパスワードをかける)で端末にダウンロードして、証明書ストアに登録する
ユーザー名・パスワードで認証して、E-mailで2段階目の認証をするというのは、Googleの2段階認証に似てるかな。
Gmailのアカウントが乗っ取られなければ、Linuxのユーザー認証を突破されても助かると。
この程度やれば十分なんじゃないかね。
秘密鍵と証明書のセットはサーバー上で作成するが、作成後はまもなくパスワードロックされたPKCS#12形式にする。
パスワードは画面に表示されるので、これをコピーして、ダウンロードしたPKCS#12形式のデータに適用して端末に登録する。
そのPKCS#12形式のデータも10分後には消してしまえば、秘密鍵がサーバーから流出することはないだろう。
証明書に登録する情報だが、ユーザーを識別するCN(一般名)はE-mailアドレス、O(組織名)は氏名に固定している。
OU(部署名)には、その証明書を使用する端末名を書いて、どの証明書をどこに使っているかわかるようにしている。
それでOpenSSLの初期設定では、これらの情報の組み合わせ(DN)が一致する証明書は複数発行できない。
同じDNの証明書を発行するなら、以前使っていた証明書を失効させないといけない。
というわけで失効を管理する仕組みもWeb上に作ることにした。
こちらもLinuxのユーザー名・パスワードでログインして、ワンタイムパスワード認証をすると、
そのユーザーの証明書リストが表示され、証明書を選べば失効させられると。
失効証明書は毎日自動的に更新するようにした。
これを実現するには、認証局を管理するユーザーを作って、そこに認証局の管理をさせたり、
そのユーザーはLinuxのユーザー認証をできるようにしたり。
いろいろやるべきことはあったのだが、出来てしまえば証明書を簡単に作ったり消したりできるようになった。
証明書の有効期限も4ヶ月にした。
長いか短いかはいろいろ考えはあると思うが、時々更新しないと忘れるだろうというのもある。
課題としては、証明書が端末に紐付いていることは保証できないということ。
僕の運用では1つの証明書は1つの端末にしか入れないことにしてるけど、仕組み上は保証されていない。
このへん、ハードウェア(ICカードなど)に証明書を入れる方法は徹底されているわけだけど。
とはいえ、クライアント証明書を発行する方法は、そういう特別なハードウェアが必ずしもいらないのは長所ではあって、
そうじゃなければ個人で導入はとてもとてもと。
あと類似するところでSSHのログイン用の秘密鍵の管理も課題がある。
ローカルに配置するとその端末でしかログインできない、
かといってオンラインストレージにおくと流出の懸念なしとは言えない。
こっちの方がミッションクリティカルなので、さてどうしたもんかと。
まだ考え中ですね。
Author : Hidemaro
Date : 2019/11/25(Mon) 23:58
コンピュータ・インターネット | Comment | trackback (0)
缶詰を補充し忘れてた
昨日、パスワードを変更・不使用にするための作業をしていて、
半ば引きこもり状態だったこともあって、食材がほとんどなくなっていた。
それで朝食を食べようとしても、これといってないもんで、
それならと魚の缶詰のストックを見たら、残り1個になっていた。
実はこの缶詰、災害などに備えた備蓄品だったんですね。
ある時期にいろいろ揃えて、適宜使って補充することを想定していた。
ローリングストックですね。
ところが、この缶詰は消費ペースが遅く、補充することを忘れていたと。
他に備蓄品としては、レトルトパウチの おかゆ とペットボトルの水がある。
おかゆ はわりと消費されるものなので、補充もうまく回ってきた。
ペットボトルの水も普段は消費されないものだから困ったのだが、
ある時に500mLのペットボトルの水を箱でもらったので、
これなら普段から消費して補充されやすくなった。
普段は水筒を持って行ってるけど、泊まりがけの旅行のときなど水筒が持って行けないときは使うので。
缶詰も消費しないとなという思いだけはあって、時々食べてはいた。
ただ、年に1～2個とかそんなペースだから、補充することを忘れていたと。
というわけで、買い物に出かけたときに改めていくつか買い込んできた。
最近は魚の缶詰の人気も高まっているようで、スーパーでの扱いもよい。
日常的に魚を食べるには便利ということである。
確かにおいしいよね。しょっぱいのは気になるけど。
食卓に簡単に1品足せるので、もっと活用すべきだったということである。
そんな反省もしながら、数量買ったので、今度は1年で1回転させるぐらいは消費しよう。
Author : Hidemaro
Date : 2019/11/24(Sun) 23:50
買い物・消費 | Comment | trackback (0)
パスワードを没収されたので
以前、Yahoo!ショッピングの支払いでPayPayが使える設定にしたら、Yahoo!のパスワードを取り上げられてしまった。
これ、実際にやったことある人ならわかると思うけど、携帯電話回線にYahoo!アカウントが紐付くことで、
従来使っていたパスワードは無効化され、回線またはSMSから届くワンタイムパスワードで認証が行われるようになるのだ。
4500万人のユーザーに“パスワード”をやめさせたい――ヤフーが進める「もっと安全で簡単な認証」とは (ITmedia)
自宅の回線からYahoo!にログイン操作を行うときはSMSで届くワンタイムパスワードを入力するが、
携帯電話回線に接続しているスマートフォンだと、アカウントを確認するだけで認証が完了する。
これはSoftBankとY!mobileの回線に限ったことだと思うが、確かに便利ではある。
2要素認証の仕組みがセキュリティが重視されるサービスで普及している。
例えば、住信SBIネット銀行のログインだと、スマートフォンのアプリでロックを解除して(物)、IDとパスワードで認証(知識)という2要素を使っている。
パスワード流出のリスクを考えると、パスワードという知識に頼った認証はなかなか厳しい。
そこで2要素認証なのだが、これはこれで手間がかかるし、やっぱりパスワードもそれはそれで使う。
Yahoo!は電話回線につながったスマートフォンを持っていることを、唯一の認証手段とすることを推奨している。
スマートフォンなど物を使った認証は、パスワード流出リスクは低減されるが、紛失のリスクってのはある。
この点については、まずスマートフォンなど物に適切にロックをかけておくこと。
たった4桁のPINコードでも、スマートフォンを失ったときに少し破られなければよい。
そのうえで、紛失したら認証手段から外せばよいわけである。
実は物を使った認証というのは、スマートフォンに限った話でもない。
自分で運用しているサーバーの認証手段として SSHの公開鍵認証 と SSLクライアント証明書 がある。
どちらもファイルだけど、知識というよりは物だよね。デバイスに登録することもできるし。
このファイルにはパスワードがかけられているので、ファイルだけ入手してもそれだけで使えるわけではない。
その上で、紛失などあれば無効化することもできる。
Yahoo!にパスワードを没収されたことをきっかけにして、認証手段の取扱をいろいろ検討したが、
今まで使っていなかったパスワードマネージャーを使用して、パスワードの強化を図ることにした。
Googleパスワードマネージャーは、PC・AndroidのChromeブラウザで統合的にパスワードを管理できる。
これまでPCではFirefoxを使っていたが、Chromeへの移行に問題ないので、
全部Chromeに統一して、サービスごとにパスワードを設定するなら統合管理することにした。
その上で、他の認証手段と紐付けて、パスワードレスにできるのなら、それも活用することにした。
昨日・今日でおよそ120のサービスの認証手段を見直した。すさまじい数だな。
このうち、パスワードを唯一の認証手段とするものは85個ほど。
パスワード+スマートフォンの2要素認証が5個ほど、これもパスワードの管理が必要となる。
これらのパスワードはGoogleに管理してもらい、Chromeでは自動的に呼び出される。
ただし、全てがChromeで入力するパスワードとも限らず、アプリ画面へ入力するものもある。
そういう場合は、Chromeからパスワードマネージャーを呼び出して、コピペすることになる。
端末のロック解除操作(PINコードとか指紋認証)をするとパスワードのコピペが許される。
煩わしいとは思うのだが、厳重に管理されたGoogleアカウントで複雑なパスワードを保存する方がよいという判断。
この85個ほどのパスワードで唯一Googleに管理させていないのは、Google自身のパスワードだけ。
(Android端末やPCのChrome・Thunderbirdには常時紐付いているので、普段は入力することない)
残り30個ほどのサービスでは他のサービスを認証手段に使う。
Yahoo!もこの分類ですかね。Y!mobile回線への接続またはSMSを認証手段としているので。
Yahoo!IDを使った認証はおよそ10個、Twitter・Google・Facebookを使った認証が各5個前後。
変わり種では ねんきんネット の認証手段が マイナポータル、すなわちマイナンバーカードの証明書を使った認証にしたというのがある。
以前からFacebookに紐付いていたLINEのようなのもあるが、多くは今回新しく紐付けを行った。
ただ、紐付けを行うことでパスワードが抹消されるサービスはそう多くなくて、
従来の弱いパスワードを上書きするためにパスワード変更して、Chromeがパスワードを保持しているものも多い。
実際のところ、アプリでは他のサービス経由での認証には対応していないなんてのもあって、
結局、個別のパスワード認証になってしまっているのはある。
あと、既存のアカウントには紐付けできないものもあったり、メールアドレスが同じであるという条件があったり。
それとあわせて対策をしたのが、自分のサーバーで運用しているメールアカウントの認証強化である。
パスワード再設定時の連絡先がここになってたりするわけだから、ここの認証はとても重要である。
こちらはSSL証明書認証への移行構想は昔からあったが、いろいろ苦しみながらやっとこさできた。
Dovecotのバージョンを上げて、充実しているとは言えない資料を漁りながら実現できた。
Dovecot and Postfix client certificate authentication (Mortikia Blog)
僕が使っているメーラーはPCではMozilla Thunderbird、Androidでは K9 Mail だが、
どちらも証明書認証には対応しているので、マニアックな認証方法だが、実用上の問題はない。
これにより、サーバーの各種サービスへのログインはパスワードレス化されたはず。
(一部は互換性のためにパスワードを併用しているものもあるが、Linux自身のパスワードとは切り離した)
まだ、少し見直しが完了していないものもあるが、だいたいこんなもの。
しかし、パスワード再設定もだいぶしたけど、設定可能な桁数がとても短かったり、旧パスワードが平文で見えてたり、
見直しを進める中で桁数や文字種の条件は以前より緩和されているものもありましたね。
EX予約は以前は数字しか設定できなかった覚えがあるが、今はアルファベット含めて8桁まで行けるようになった。
制限が厳しいように見えるが、これは券売機で入力することがありうるから。
インターネット用と券売機用(カードとの2要素認証とも言える)で分けるのが正しいと思うが、以前よりマシにはなった。
サービスによってはパスワードの強度や流出リスクに課題があるなぁと。
そのリスクに対して、今回の対策を行うことで緩和はできたのかなと。
Chromeが自動入力してくれたり、Yahoo!やGoogle経由の認証になったり、
実質的なパスワードレス化がかなり進むことになる。
物の管理には一層の注意を払う必要はあるが、利便性は高まるなと思う。
Yahoo!にパスワードを没収されてから吹っ切れたというのはあるね。それでいいんだって。
Author : Hidemaro
Date : 2019/11/23(Sat) 23:50
コンピュータ・インターネット | Comment | trackback (0)
ゆうパケットの配達日数って
最近、PayPayフリマでゆうパケットを出荷していて、
相手に到着して、納品が確認されたら売上が確定するので、いつ到着するかは興味のあるところ。
それで追跡データをたびたび見ていたわけだが、
お届け日数で表示される日数より日数がかかることもあれば、逆に早いこともある。
まず、前提として、集配を担当する郵便局に持ち込んでいるので、
集荷されないまま取扱所に長時間放置されるということはない。
その点ではお届け日数に表示の額面通り見てもよいように思えるが、
この郵便局から仕分けを行う郵便局への便の都合、普通郵便は17時、ゆうパックは18時が当日分締め切りと書かれている。
ゆうパケットはどっちかわからないが、仕事が終わってから出荷するとせいぜい18時台、たいていは19時台である。
(当たり前のことながら、この時間に出荷できるのはゆうゆう窓口があるから)
というわけで、当日分締め切りより後に出した場合、翌日午前出荷と同じ扱いになるべきである。
17日の19時台出荷だと、午前・午後とも翌日配達の地域は、19日中になると考えるべきということ。
最近出荷した7個について集計すると、次の通りだった。
- 17時以前に出荷: 3個中1個は日数通り、2個は日数+1日
- 18時以降に出荷: 4個中3個は日数通り(翌日午前から起算)、1個は翌日午前からの日数-1日
17時以前に出荷で+1日というのは、いずれも関東圏なので翌日配達の地域なんだが、
翌朝に配達を担当する郵便局に到着しているのに1日留め置きというのが追跡から見えている。
末端の配達の都合でこういう遅延が起きるようだ。
18時以降に出荷の分は日数通りに届いていて、郵便局で1日留め置きのようなことは見えていない。
日数-1日となった1個は午前・午後とも翌々日配達の地域に19時出荷で、出荷日の翌々日に届いてしまったというもの。
当日分として仕分けを担当する郵便局に押し込めたのか、翌早朝から動き始めれば着いてしまったのか。
真相はわからないが、翌午前と同じはずだとは言っても、早く出荷すればそういうことも起きるようだ。
配達を受ける側の感想としては、郵便局の荷物の配達はさほど遅れない印象があった。
というのも、ヤマト運輸は所定の配達日数より1日余計にかかることはよく起きているから。
追跡データを見る限り、ベース店を通過してから、担当の営業所で配達されるまでに丸一日以上かかっていることが多く、
末端の配達が遅延しがちなのではないかと予想している。
佐川急便も年末の荷物が集中する時期に似たようなことが起きて、1日余計にかかっていたことがあった。
ただ、そのときぐらいだったかな。あとはちゃんと日数通りに届いていたんじゃないか。
このあたりの事情は地域により違うと思われる。
郵便局の配達が遅延しがちで、ヤマトは日数通りに来ると、僕と逆のことを言っている人も見たことがある。
末端の配達体制に依存するところが大きいということの表れなんじゃないか。
今回のゆうパケットの配達日数からもそういうところが読み取れる。
距離と配達日数は必ずしも対応しないということだね。
ヤマト運輸は末端の配達を早くするのは大変だと知っていたんじゃないか、
というのがクロネコDM便(旧:クロネコメール便)の配達日数で、これは近くても翌々日、400km圏より外は4日目と言っている。
確かにあまり急がないDMが主な目的とはいえ、通販の商品をこれで送ってくる業者もいる。
近くてもやたら日数がかかるというのは、末端の配達体制の違いが原因なんだろうと。
もちろん宅急便は早く配達するために相応にコストをかけてきたはずだが、近年は限界に達しつつあるのかなと。
一方の日本郵便の普通郵便・ゆうメールは、配達日数は発着地の距離が支配的かなと。
近ければちゃんと翌日に届く。遠くなると翌々日、3日後はあんまり見ないかな。
午前差し出しと午後差し出しで差が出やすいので、この辺も拠点間の配送時間が支配的であるところかなと。
定形郵便物は安いが、軽いので航空搭載されやすいらしく、案外そういうのが早いと。
逆に原則として航空輸送されないゆうパケットは、沖縄県など海路に時間がかかるところはむちゃくちゃ遅いけどね。
これまでの経験と今回の結果からすると、大手3社ならどこで配達されても……という感じですね。
うちの地域での荷物の配達だけみればヤマトは少し悪いが、拠点間の配送は早い印象はあるので、総合的に見て悪いとも言えない。
うちは集配を担当する郵便局が近いので、郵便局からの出荷が圧倒的に便利だし、
郵便を独占していることもあって、小型荷物は価格に対してサービスレベルが優れている。
(今回は送料はPayPayフリマ負担だったが、ヤフオク・PayPayフリマの出品者負担の送料では、ゆうパケットはネコポスより少し安い)
なので、今後も日本郵便が優先になるかなと思うけど、やってみるといろいろあるもんだね。
Author : Hidemaro
Date : 2019/11/22(Fri) 23:58
買い物・消費 | Comment | trackback (0)
同じ展示会に送り出すにしては
例年行っている展示会があって、去年は当時のチームリーダーに言われて、リーダーと2人で日を分けて行っていた。
そのチームリーダーが異動になったこともあって、今回は自分から提案することに。
今のチームリーダーも課長もあれこれ言うことなくOKしてくれたのだった。
展示会に行くんですよ、という話をしていたら、隣の課の人も行こうかなと言っていた。
僕が行くのとは違う日に行くんだけどね。
それで上司に提案しに行ったら、出張するならとあれこれ言われていたようで、
事前調査として、他のメンバーに現状の課題をヒアリングしに行ったり、
チームリーダーと展示会の内容を吟味して、受講するセミナーを決めていたり。
同じ展示会に人を送り出すのにずいぶんな差である。
同じ部内でも、課ごとにいろいろ違うという話はあるんだが、
うちの課は課長もメンバーもアイデアが湧く人が多いのか、あれこれ提案しがちな傾向はある。
全てが受け入れられるとは限らないが、上司が提案を後押しする傾向というのはある。
一方で、隣の課は課長もチームリーダーも心配性の人が多いのか知らんが、
仕事内容を注意深く見る傾向はあるような気がしていて、
それが展示会の出張前にあれこれ言われたところにもつながっているのかなと。
どっちがよいかはメンバーや仕事の特徴次第ですけどね。
うちの課のメンバーについて「御しがたい」というような感想を言っていた人もいましたしね。
確かにメンバーの実力を生かせるように、仕事の割当をするのは難しいかも知れないなぁと。
隣の課は、課長もチームリーダーも、この製品での豊富な経験があって、ノウハウの伝承に力が入っているように見える。
確かにメンバーにも継承されていて、僕にとっても頼りにしている部分は多い。
端から見ると心配性な上司だなぁと思うけど、手塩に掛けてメンバーを育てている面はあるんだろう。
あとは、これまでの実績ですかね。
展示会やセミナーへ出張すると、そのことについて部のメンバーに展開しているのだが、
他のメンバーからの反響もわりとあって、目の付け所には評価していただいているのかなと。
そうやって評価していただけているのだとすれば、それはありがたいことだが。
Author : Hidemaro
Date : 2019/11/21(Thu) 23:56
日常 | Comment | trackback (0)