某高校の入試申請で話題になってたメールサーバーのこととか

神奈川県の高校入試出願システムで障害、志願者のGmailにメール届かず – 現在は解消

神奈川県下の中学三年生は約7万3千人。予備のメールアカウントも登録しているから、全員に一度にメールを送信しようとすると、約15万通のメールを一度に送信しうるメールサーバーという話になる。

件のメールサーバーではMXテーブルにIPアドレスを指定していたことが原因で、SPFやDKIMが機能していない。その状態で大量のメールを送信したためレピュテーション(評価)が低下、不正中継サーバーと判断されて、メールを拒否されるようになった。Googleが制限しているためメールを受信出来ないという表現は確かにその通りだが、不正メール対策として正しく設定していないメールサーバーからのメールを受信しないのはGoogleに限らず多くのベンダーで行っている基本的な対策だ。正しく設定出来ていなかったメールサーバー側が全面的に悪い。

では正しく設定出来ていたら問題無くメールを送れたかというと、実は送信出来なくなった可能性が高い。新規にドメインを取得して間もなかったり、普段より極端に多くのメールを送信した場合にも、レピュテーション(評価)が低下する。これはSPFやDKIMによる認証が行われるようになる以前から行われていた不正中継対策だ。

もし独自にメールサーバーを立てるなら、ユーザーの利用が集中しないように利用開始時期を分散させつつ、レピュテーション(評価)の状態を確認しながらメールの送信数を調整、時間当たりに送信するメールを少しづつ増やしていく必要がある。運用に常に人を張り付けて微調整が必要になる。そもそも1~2月だけ大量のメールを配信するというのはレピュテーション(評価)を下げやすいので、年間通してメールを送り続けるような仕組みまで考えておく事を求められる。

実際には上記のような運用は手間がかかるし、バッドノウハウの塊なので経験がないものが実施するのは難しい。そこで通常は大量のメール送信を代行する、メール配信事業者に頼むことになる。

1月~3月だけ数十万通のメールを送信するシステムで、自前のメールサーバーから配信しようとしている時点で、発注者側にも受注者側にも適切に設計を出来るIT知識が無かったことがうかがわれる話だったりする。

参考:Google メール送信者のガイドライン

MNPで携帯電話を乗っ取りSMS認証を突破される

さっきまで使えてたスマホ、通話音が…しない 勝手に解約されたかも 被害男性の証言

偽造運転免許証をもちいて携帯電話のMNPを申込みんで携帯電話を乗っ取り、オンラインバンクのSMS認証を突破されてしまうという問題が多数発生しているらしい。記事の中でも「パスワードを使い回さないなど、やはり個人の対策が重要だ」と書かれているとおり、一番の問題はパスワードを適切に管理出来て居なかった事にある。

SMSを使用した多要素認証は、NIST(米国立標準技術研究所)でも条件付き推奨としている。推奨するための条件は、「他の認証方式と併用すること」「代替の認証方法を用意すること」「危険性の評価し公表すること」三つだ。SMSは電話会社での管理が適切である事を前提としており、技術的あるいは社会的方法で容易に突破されうる事が分かっているからだ。

SMSは攻撃に弱い認証方法であるという前提を理解して、正しくパスワードによる認証を使う事が大事です。「サービス毎に異なるパスワードを使う」「パスワードはランダムな文字列にする」「前述二つを実施するのはパスワード管理ツール無しでは無理なので、適当なツールを利用する」の三点をしっかりまもろう。

そしてエンジニアもSMS認証は弱いと言う事をちゃんと認識してサービスを設計しよう。

Stable Diffusion+Windows 10+AMD GPUの環境で動かす

Stable DiffusionをWindows 10とAMD GPU上で動作させている記事、Running Stable Diffusion on Windows with an AMD GPUを見つけたので、実践。以下は作成してみたサンプル。

stable_diffusion_sample

事前準備

まずは実行環境を確認。
・メモリ6GB以上のAMD GPU
・Pythonの3.7、3.8、3.9、3.10がインストールされている
・Gitがインストールされている。
・Hugging Face(Stable Diffusionの学習済みモデルを公開している)のアカウント
・6GBの学習モデルをダウンロード&変換する勇気

と言うわけでPythonのインストール。PythonはMicrosoft StoreからPython 3.10をインストールしてしまうのが手がかからない。

続いてGitのインストール。私はVisual Studioと一緒にインストールされてしまっているが、単独でインストールするならGit for Windowsをインストールするのが良いかと思う。

さらにHugging Faceにユーザー登録する。ユーザー登録自体は無料。

インストール作業

ますはインストール先となるフォルダを作成する。私はD:\stable-diffusionにした。インストールには15GB程度の空き容量が必要になるはずなので、十分に空きのあるドライブを選ぶこと。PowerShellからコマンドプロンプトを開いて、インストール先フォルダに移動します。

Microsoft’s DirectMLに対応したOnnx runtimeをhttps://aiinfra.visualstudio.com/PublicPackages/_artifacts/feed/ORT-Nightlyからonnxruntime-directmlをダウンロードする。ダウンロードするランタイムはPythonのバージョンによって異なる。Python 3.10.xをインストールしているなら、cp310(onnxruntime_directml-1.12.0-cp310-cp310-win_amd64.whl)をダウンロードする。

コマンドプロンプトまたはPowerShellのプロンプトを開いて以下のコマンドを実行。

python -m venv ./virtualenv
./virtualenv/Scripts/Activate.ps1 または virtualenv\Scripts\activate.bat
pip install diffusers==0.3.0
pip install transformers
pip install onnxruntime
pip install protobuf<3.20.x
pip install onnx
pip install pathToYourDownloadedFile/ort_nightly_whatever_version_you_got.whl --force-reinstall

Stable Diffusionの学習済みモデルをダウンロードするには、ライセンス条項に同意する必要があります。ライセンス条項を確認した上で、Hugging Faceのhttps://huggingface.co/CompVis/stable-diffusion-v1-4のページにアクセスして、「 have read the License and agree with its terms」にチェックをして、Access Repositoryをクリック。

Hugging FaceのAccess Tokenを発行する必要があります。Hugging FaceのWEBページ右上のユーザーアイコンから「Settings→Access Tokens」に進み、Access Tokenを発行します。

プロンプトから以下のコマンドを実行します。

huggingface-cli.exe login

Token:とプロンプトが表示されるので、先ほど発行したAccess Tokenを入力します。「Your token has been saved to ~」と表示されれば大丈夫です。

Stable DiffusionをOnnixに変換するためのスクリプトを「https://raw.githubusercontent.com/huggingface/diffusers/main/scripts/convert_stable_diffusion_checkpoint_to_onnx.py」からダウンロードします。

以下のコマンドを実行します。

python convert_stable_diffusion_checkpoint_to_onnx.py --model_path="CompVis/stable-diffusion-v1-4" --output_path="./stable_diffusion_onnx"

学習モデルのダウンロードと変換に数時間かかります。気長に待ってください。

試しに画像を生成してみます。以下の内容をtext2img.pyとして保存して、プロンプトから実行してみてください。output.pngが無事に生成されればインストール成功です。

from diffusers import StableDiffusionOnnxPipeline
pipe = StableDiffusionOnnxPipeline.from_pretrained("./stable_diffusion_onnx", provider="DmlExecutionProvider")

prompt = "A happy celebrating robot on a mountaintop, happy, landscape, dramatic lighting, art by artgerm greg rutkowski alphonse mucha, 4k uhd'"

image = pipe(prompt).images[0] 
image.save("output.png")

生成する画像サイズや、反復計算する回数などのパラメータを指定する事もできます。それらを指定する場合には以下のコードを参考に書き換えてください。

from diffusers import StableDiffusionOnnxPipeline
import numpy as np

def get_latents_from_seed(seed: int, width: int, height:int) -> np.ndarray:
    # 1 is batch size
    latents_shape = (1, 4, height // 8, width // 8)
    # Gotta use numpy instead of torch, because torch's randn() doesn't support DML
    rng = np.random.default_rng(seed)
    image_latents = rng.standard_normal(latents_shape).astype(np.float32)
    return image_latents

pipe = StableDiffusionOnnxPipeline.from_pretrained("./stable_diffusion_onnx", provider="DmlExecutionProvider")
"""
prompt: Union[str, List[str]],
height: Optional[int] = 512,
width: Optional[int] = 512,
num_inference_steps: Optional[int] = 50,
guidance_scale: Optional[float] = 7.5, # This is also sometimes called the CFG value
eta: Optional[float] = 0.0,
latents: Optional[np.ndarray] = None,
output_type: Optional[str] = "pil",
"""

seed = 50033
# Generate our own latents so that we can provide a seed.
latents = get_latents_from_seed(seed, 512, 512)
prompt = "A happy celebrating robot on a mountaintop, happy, landscape, dramatic lighting, art by artgerm greg rutkowski alphonse mucha, 4k uhd"
image = pipe(prompt, num_inference_steps=25, guidance_scale=13, latents=latents).images[0]
image.save("output.png")

制限

この時点ではいくつかの制限があります。

生成画像解像度の制約

512×512以上の解像度の画像を生成することが出来ません。これはOnnixの制約です。より高解像度の画像が必要な場合には、waifu2xなどの超解像AIを併用するなどの工夫が必要です。

NSFW(職場閲覧注意)による制約

真っ黒な画像を生成することが頻繁にあります。標準で組み込まれているNSFW(職場閲覧注意)フィルタにブロックされていることが原因です。以下の様に1行追加する事でNSFWを無効に出来るようですが、Stable Diffusionの利用規約上NSFWを無効にして生成した画像の公開は慎重に行いましょう。NSFWを無効にすると相当に高速になるという副次的効果もあるようです。

pipe = StableDiffusionOnnxPipeline.from_pretrained("./stable_diffusion_onnx", device_map="auto", provider="DmlExecutionProvider", max_memory=max_memory_mapping)
pipe.safety_checker = lambda images, **kwargs: (images, [False] * len(images))

その他、細かなHackは続編のStable Diffusion Updatesに・・・・

PPAP問題はパスワードをメールで送るのを止めても解決しない

PPAP(パスワード付きZIPファイルと、そのパスワードを別送する)が無意味どころか、むしろ危険を増している事がようやく認識されるにいたった。だが、もう一つの問題、そもそもZIP2.0暗号方式を使って暗号化することの無意味さが知れ渡っていないようだ。

ZIP2.0暗号方式には計算量的脆弱性があり、比較的少ない計算量で総当たり攻撃をおこなえることが知られています。ハイエンドGPU(RTX 2080Ti 価格20万円程度)を4枚搭載したパソコンを使用すれば、15桁のパスワードでも15時間程度で解読できてしまう事が報告されています。ということは文字数を増やして16文字にすれば56日となるかというと、これ以上パスワードの文字数を増やしても解読に変わる時間は延びません。内部的に96bit(15文字程度)の状態しか持てないため、これ以上パスワードを長くしても意味が無いのです。

ZIP形式のファイルはこの問題を解決するために、今ではAES方式暗号に対応しています。ですが、Windowsが標準ではAES方式のZIPファイルに対応していないために、利便性を優先してZIP2.0を使用する事が常態化しています。セキュリティは利便性とのトレードオフになる事が度々ありますが、利便性を優先して実効性のない暗号方式を採用し、そのために無駄な作業や別の危険を増やすのは本末転倒でしょう。

暗号化したファイルのパスワードをメール以外・・・例えば電話で伝えるのは進歩です。でもZIP2.0形式を使い続けるなら、そこに実効性はありません。利便性と実効性を考えたなら、素直に暗号化などせずに添付して送るのが一番良いでしょう。

ではどうすれば良いのでしょうか?私がお勧めするのはメールを使用しない事です。メールの根本的なセキュリティ問題は認証機能が無い事にあります。そこで認証機能のしっかりしているSNSなり、Google Drive等のストレージサービスなりを経由して送るわけです。この時使用するサービスは、出来ればデータを受け取る側に用意して貰うことが重要です。アップロードする場所を指定するやりとりの中で、重要なデータを送る前に相互に認証を行う事ができます。

セキュリティ上、メールサーバーはどんなサービスを利用すべきか。

業務上使用しているメールサーバーのセキュリティについて考慮したことがあるだろうか?実態として問題なく利用できるメールサービスは限られている。

セキュリティ上、パスワード漏洩等のインシデント発生時に被害の程度や範囲を特定する必要がある。このためには最低限でもPOP/IMAP/SMTP/WebMailの認証ログを閲覧し不正な接続の有無や接続元を特定する必要がある。だが実態として認証ログを閲覧出来る事が明記されているメールサービスは少ない。

サービスを提供する事業者は第三者間の電気通信を中継している都合、電気通信事業者とてし法律の制約を受ける。そこには通信の秘密を守る義務が含まれており、通信相手の接続元などの情報を提供することが出来ないためだ。

自社でメールサーバーを運用するのであれば、電気通信事業法上の制約を受けることなくログを閲覧出来る。かといってメールサーバーの運用には多くのノウハウがあり、中小企業でメールサーバーを運用できる技術者を確保する事は難しい。

以下にセキュリティ上の認証ログを閲覧出来るメールサービスを例示しておく。色々と探したのだが、三つしか見つけることが出来なかった。

Google Workspace
Microsoft 365
カゴヤ・ジャパン株式会社 メール専用サーバ

番外として下記も紹介しておく。認証ログを閲覧する事は出来ないが、代わりに接続元IPアドレスを制限する事が出来る。境界型セキュリティで安全を担保する前提であれば、接続元IPアドレスを制限したり、代理サーバーを介在させたりすることで、同様の要件を満たす事はできる。
WebArenaメールホスティング

Excelのパスワードを解除する方法

Excelのパスワードを解除する裏技を求めて、当WEBに来る方が少なくない。 「ブックの保護を強制的に解除する」は保護をすることで安全に隠せている気になっている記事への警告の意味で書いたので、パスワードが分からなくて困っている人へと補足情報を載せておこうと思う。

避けては通れない法律的な話し

まず法律的なことを覚えておいて欲しい。

何らかの方法でパスワードを調べたり、調べたパスワードを保管したりする行為は「不正アクセス行為の禁止等に関する法律」に抵触し、刑事罰の対象となる。例えファイルの中味を閲覧しなかったとしても、パスワードを調べたり、保管しているだけで処罰の対象となる。

裏技などを使ってパスワード(技術的利用制限手段)を迂回したりする行為は「著作権法」に抵触し、これまた刑事罰の対象となる。 著作権侵害の多くは親告罪だが、技術的利用制限手段の回避は非親告罪となる。

また裏技をつかってパスワード (技術的利用制限手段) を迂回するためのツールを提供する行為は「不正競争防止法」に抵触する。平成30年からはツールを提供するだけではなく、依頼を受けて役務を提供する事も処罰の対象となる。

以上のような法律があるので、いくら探しても「パスワードを解除して欲しい」という依頼を受けてくれる人は見つからない。Excelのファイルを解析してパスワードを解除するようなツールも見つからない。仮に技術的かつ予算的に可能であっても、家族や親友からの依頼でも無い限り、リスクが大きすぎて受けられないのだ。

とはいえ、パスワードが分からなくて途方に暮れている様もよく分かる。解決方法はただひとつしかない。技術的な知識と、法律的な知識を自ら身につけ、自らの手で作業するしかないのだ。

裏技による迂回方法

ブックやシートの保護パスワードや、VBAのソースコード閲覧パスワードなどは裏技的な方法で解除できる。実際に解除する方法は「Excel の各種パスワードを突破する方法まとめ」に良くまとまっている。新たに追記することはしない。

読み取りパスワードの解除

読み取りパスワードだけは総当たりで解除するしかない。だが、辞書に載っているような単語だけであるとか、あるいは6~7文字程度のパスワードであれば、解除できなくもない。

パスワードの解析によく使われるのは「John the Ripper password cracker」と言うツールだ。

私の使っている20万程度のパソコンでもGPUを使うと3,000パスフレーズ/秒程度のスピードで解析を進めてくれる。英数だけで構成される5文字程度のパスワードなら、最悪でも60時間程度で解析が終わる計算になる。辞書に載っているような単語、十万語程度を対象とするならば、数分で終わってしまう。

最高スペックのGPUを使うなら1桁程度は早くなる。IaaSで高速なサーバを複数台レンタルするなら2桁程度は早くなる 。6文字程度のパスワードなら総当たりでも 数日程度で 割り出すことが出来るし、そのために発生する費用は10万円にもみたない。

Postscript #1

そんな分けだからパスワードの分からなくなったファイルのことはキッパリと諦めて、ファイルをゼロから作り直すことを第一選択肢として考えたほうが良い。

Postscript #2

いまどき7文字程度のパスワードしか設定していないのは、実効性が無いので止めておいたほうが良い。無駄な仕事を増やしているだけに過ぎない。

DELLのセキュリティー事件簿

元記事:実態調査が示すセキュリティー事故の最新動向

DELLのもうちょっと良い事例は無かったのだろうか?
インシデント(セキュリティー事故)が発生するのは仕方ないにしても、あまりにも稚拙な対策が混じっていて失笑を禁じ得ない。

CASE1、CASE2・倫理観低下が招いた事故

論理感等という曖昧なものに原因を求めてはならない。分からない言語のメールだからそれを無視したり、業務効率向上の為のチャットソフト利用を拒絶する事が、論理感の高い行動とは言わないだろう。

根本的な原因は、恐らくはリスクのある外部サービス利用に対する過度な制限や、外部サービス利用承認プロセスの不備、ネットワーク利用状況の監視体制の不備にあると推測する。下手な利用制限がかかっていなければメジャーな翻訳サイトを避けて稚拙な翻訳サイトを使ったり、適切な監視がなされていればチャットソフトの利用に気がつかないと言うことはないからだ。

制限、許可、監視のバランスがとれていないことが根本の原因にあるなかで、制限だけを増やすのは問題の解決には至らない。制限を回避する新たな方法を編み出すようになり、従業員との信頼関係が損なわれる結果が目に見える。

CASE3・CASE4・ランサムウェアに感染

そもそもバックアップを取れていないことが致命的に問題だ。バックアップがとれていればデータが失われても1日分程度の話しであり、データを失うと言う致命的事態には陥らない。バックアップは一般ユーザーの権限ではアクセス出来ない(最低限で書き込めない)場所に、過去4~5日分(気がついたときには上書きされていたら意味が無いので、夏期休業などの最長休業期間より長い日数分)をバックアップしていれば良い。

標的型メールを模倣する訓練において開封率の低下を目指すことに意味は無い。本来なら開封した場合のエスカレーションが確実に行われることや、開封によって感染したことをセキュリティ監視チームが発見できる事が重要になる。なぜなら100人中1人でも開封すれば被害に繋がるし、またどんなに訓練を重ねたところで、文面などから完璧に不正なメールを判断するのは不可能に近いからだ。

CASE6・CASE7・基本的な対策を怠った

CASE6のすべてのPCのOSを最新に するのは確かに必要な処置だろう。だが起こった問題「商談情報を撮影して個人のPCにメールで送ったりしていた」に対する対策としては「機密情報の撮影を禁止」と言うルールを設けただけである。いかにルールを作っても、ルールが守られていることを監視監督する等の運用面が苫なわなければ、仕事のためにルールを無視する事が必ず起こる。

CASE6の根本的な原因は、メールの送信先や送信元に対する監視が機能していない事にある。個人で取得していると思われるメールに対する送信だけでも監視していたなら、問題が発生する前に警告する事が出来たはずだ。

CASE7についてはログが無い以上、今後調査が進展する可能性もない。「漏洩した情報を特定できない」という報告をする以外にない。

セキュリティ上、クラウドサービスを業務に使ってはならないとき・・・

「オンプレミスに比較して、クラウドはセキュリティが心配・・・」と言うユーザーに対して「クラウドベンダーと御社とどっちのセキュリティが上だと思ってるの?」というのは昔から良く話しとして見かける。実はクラウドサービスのセキュリティで気をつけるべき視点がひとつある。インシデント発生時に速やかな対応が可能か否かだ。

一流のクラウドベンダーならユーザー側に起因するインシデント発生時の対応も考慮されている。だが、二流三流のクラウドベンダーとなるとかなり怪しい。ユーザー側の原因でインシデントが発生した時に、影響範囲特定に必要なログ等の提供を受けられない可能性がかなり高い。例えば以下のシナリオのような状況が考えられる。

インシデントシナリオ#1
自社のWEBサービスがSQLインジェクション攻撃を受けた。この場合は影響範囲の調査にデータベースサーバの監査ログが重要な役割を果たす。もしこの時、ベンダーの提供するデータベースが他のユーザー企業とインスタンスを共有している場合、監査ログには他のユーザー企業の発行するSQL文まで含まれてしまう。ベンダー企業が監査ログをユーザー企業ごとに分割するような対策を事前に取ってない限り、迅速な対応は期待できない。

インシデントシナリオ#2
メールアカウントのユーザーIDとパスワードが漏洩して第三者が閲覧した可能性がある。この場合にはメールサーバーの認証ログを閲覧して、不自然なな時間帯や接続元からの認証、認証エラーの有無を確認したい。もしこの時、ベンダーの提供するデータベースが他のユーザー企業とインスタンスを共有している場合、そこには他のユーザー企業のログも含まれている。さらには通信事業者には通信の秘密を守る義務が課せられている。通信時間帯や接続元IPアドレスは通信の秘密に含まれるため、頑なに開示してもらえない可能性がある。こうなると被害届をだして事件化しないと、影響範囲の特定も出来なくなってしまう。

無論、きちんとしたベンダーは回答を用意している。AWS AuroraDBやSQL Azureには監査ログの機能がある。オブジェクトストレージのS3はアクセスログを提供している。GSuiteやOffice365も認証ログを提供している。

対して国内ベンダーに目を向けると、大手ベンダーでもその辺りがかなり弱い。

例えばさくらインターネットがS3互換としているオブジェクトストレージにはアクセスログの機能が無い。

あるいはNTT Communicationのメールホスティングサービスにはメールの送信ログに対する検索機能はあるが、認証ログの提供はない。法的な問題もあるので提供が難しいのは分かるが、せめて認証成功のログ程度はないとインシデント発生時に対応出来ない。

ベンダーの多くは電気通信事業者として「通信の秘密」に関する義務をおっている。何時何処と通信をおこなったかは「通信の秘密」に含まれるため、電気通信事業者としては安易にログを開示する事は出来ない。ユーザー企業に公開できるのは、ユーザー企業の管理下にあるシステムのログだけになるが、事前に準備を整えていない限り共有部分のログ提供には時間がかかる。

クラウドサービスを採用するにあたっては、セキュリティ監査に耐えるだけのログ出力機能があるか否かは確認した方が良い。もしそれらのログ出力機能が無く、インシデント発生時に相応の対応が必要なら、契約に調査対応への協力義務を盛り込む程度のことは検討しなてくはならない。

※クラウドベンダーの対応状況は2019年9月時点のもの

不要になったホームページの閉鎖のしかた

不要になったホームページを閉鎖する手順を記した良記事。
ドメイントラブルを防ぐ、Webサイトを正しく閉鎖する方法

一時期にはキャンペーンサイトなど安易に期間限定でドメインを取得してしまうWEBサイトが多数あったが、最近は問題点が知れ渡ったのか大分減ってきた。取得してしまったドメインを方々に迷惑を掛けることなく、キチンと止めるのはとても面倒なのである。

まとめるとこんな感じ。
1.閉鎖したドメインで一定期間は閉鎖の案内を表示するか、あるいは新URLへの転送を行う。
2.HTTPリファラーをモニタリングして、可能な限りリンク元URLに対して変更依頼を行う。
3.閉鎖するドメインへのアクセスがほぼ無くなったのを確認した後にWEBサーバーを廃止。
4.WEBサーバ廃止後はDNSからレコードを削除。
5.WEBサイトを閉鎖した後もドメインは更新し続け手放さないのが理想。

NICTがIoT機器に無差別侵入し調査へ・・・

総務省 IoT機器に無差別侵入し調査へ 前例ない調査に懸念も」の記事を受けてIT業界にまたも激震が広がってる。「通信のブロック」 「coinhive検挙」 「ダウンロード違法化」と立て続けで、流石に辟易してくる。

あわてて条文など内容を確認したが、下記のようなことらしい。

法改正によってNICTを不正アクセス防止法の規制対象外にした。
NICTは第三者のID/PASSWORDを使って機器にログインする事、機器にログインした後その機器を操作すること、その機器を踏み台にしてさらに別の機器へのログインを試みることが出来るようにした。
電気通信事業者にはNICTから通達のあったIPアドレスを使用しているユーザーに対して警告する義務が追加された。

この法改正により、NICTは日本国内に設置されているインターネット上から接続出来る脆弱なパスワードが設定されている機器を調査する業務を行い、脆弱な機器を使っているユーザーには通信事業者を通じて連絡が来ると言うことのようだ。

法文を読むに、ブルートフォースなどにより機器にログインした後、その端末を操作して踏み台にし、LAN内の機器にまでログインして操作ことを許可しているように読み取れる。単にパスワードの調査だけではなく、より踏み込んだ調査が行われる可能性もあるようだ。

すでに調査はスタートしていて、11/14までにポートスキャンによる事前調査を終えている。スキャン対象となっているのはポート22(SSH)、ポート23(TELNET)、ポート80(HTTP)で接続時に表示されるバナー情報から機器情報を得ている。

この事前調査に使用したとされるIPアドレスはWhoISを見る限りNICT管理下のものなので、きちんとNICT管理下で行われているようだ。どこぞの業者に委託してて委託先業者から漏洩・・・と行ったことはひとまず心配しなくても大丈夫だろう。

ただ今回計画されている調査の有効性には疑問を感じる。

日本国内のインターネット接続環境は、BBルーターを介した接続になっていることが多く、ルーターの設定を意図的に変更してポートフォワードの設定をしない限り、設置した機器がインターネットから直接アクセス可能になる事は殆ど無い。かといってインターネットから直接アクセス出来ないなら、標準のパスワードのままでも安心出来るのかというと、危険である事は変わらない。

例えば僕ならLAN内のIoT機器にログインを試みるアプリケーションをメールに添付して送り込むといったことを普通に思いつく。この手のアプリケーションはウィルス対策ソフトに検出される事もまずない。多層防御がきっちりなされていない場合、 狙い通りにLAN内のIoT機器に侵入して設定を変更してしまうだろう。

今回計画されている調査は、インターネットから直接接続は出来ないが、LAN内に存在する脆弱なパスワードが設定されたIoT機器に対しては有効ではない。インターネットからは接続出来ないが脆弱なパスワードが設定されたIoT機器は、今回の調査対象よりも桁違いに多いはずだ。

ここまで強硬な手段を執る前に、公共性の高い事業者や規模の大きい事業者に対して、脆弱性診断を受けることを義務づけるとか、より有効な方法があっただろう。
なぜこんな方法にいきついたのか、大きな疑問を感じる。

なにはともあれ、アクティブサイバーディフェンスを法制化して国主導で行うというのは、他の先進国でも類例が無いのではなかろうか?国が個人の端末に勝手にログインする事の善し悪しを議論したり、国民のコンセンサスを得る前に、 良くも悪くも 世界最先端をいくセキュリティ体制が走りはじめてしまった事になる。

参考URL:
IT Research Art:NICT法改正と不正アクセス禁止法
NICT:日本国内でインターネットに接続されたIoT機器等に関する事前調査の実施について
総務省:国会提出法案