IT関連知識の備忘録

検疫ネットワーク的なもの(2)　素人お断りの内容です。

2022-03-22T23:29:58+09:00

・前回の検証の目的は、インターネットは既存のネットワークを利用するが、既存のネットワーク機器との相互通信はできない別のネットワークを作るというもの。言い換えると、あるPCがウィルス感染を疑われるとき、社内ネットワークに影響を及ばさずに、インターネットが必要なOS・ウィルス対策ソフトの更新やクラウドスキャンも行える環境を準備するというもの。

・お金がかけられるなら、自動でPCの安全性を確認の上、社内LANに接続してくれる「検疫ネットワーク」という手段があることも紹介した。一般家庭で使用するようなルータで、有線・無線の区別なく、セパレーター機能を実現できれば、当初の目的は果たせる。

・情報漏えい防止などは、普段から対策を講じていることが前提であるので、今回は議論していません。検疫的ネットワークのインターネットは、OSとウィルス対策ソフトの更新およびウィルス対策ソフトのクラウド機能（最新のAIを使った検索や駆除）を利用するためです。漫然とインターネットを使った業務を継続するためではありません。PCの検疫に限定するための工夫は別途行ってください。

・今回は、そのような、堂々巡りの議論を仕掛けてくる方ではなく、意義のある質問をされた方に答えさせていただきます。

・前回のパケットフィルタの設定に関して、IPv4だけではなくIPv6の通信も、分離した2つのネットワーク間で遮断されるのかという話です。実は前回使用した家庭用ルータは非常に古いものですが、Ipv6パススルー機能があります。つまりこの機能を有効にしない限り、検疫的ネットワークのWAN側つまり既存のネットワークと検疫ネットワークの間のV6通信は遮断されます。以下の図を見てください。「フレッツIPv6サービス対応機能」が現在の設定で「使用しない」になっている。

このとき既存のネットワークにあるWindows10のPCと検疫的ネットワークにあるWindows10で相互にリンクローカルIPv6アドレスに対してのpingが通らないことを確認しました。その後、上記画面で、設定をクリックして、以下のような状態（現在の設定：使用する）になったあと、pingを使った疎通試験が通るようになりました。Windows10のpingコマンドはv6アドレスに対応しています。pingコマンドの引数となるIPv6アドレスは％とそれ以降の数値を除いたものとなります。

・IPv6パススルーの機能は、メーカや機種により仕様が異なり、設定方法も異なるためお使いの機器のマニュアルを確認の上、操作を行ってください。

・検証に使用した家庭用ルータのパケットフィルタの最終画面です。検疫的ネットワーク側から既存ネットワークのルータ(192.168.1.1)の設定も変更できない状態です。

検疫ネットワーク的なもの（ネットワークの基礎知識が必要です）

2022-03-17T23:48:22+09:00

・「検疫ネットワーク」については、IPAの試験を受けた人は、ある程度聞き慣れた言葉として認識していると思われる。・マルウェアに感染したかもしくは感染した疑いのあるPCだけ社内のネットワークから隔離して、別のネットワークにつなぐことかなと思われたら、ほぼ正解である。

・出張等で持ち歩いていたPCを社内のネットワークに有線もしくは無線接続するときに、まず検疫サーバ（セキュリティソフトやOSの更新を配信し、各端末に適用したり、ウィルススキャンをさせたりする）とだけ通信できる状態にし、検疫が完了したら、社内ネットワークと通信できるIPアドレスをPC(端末）に払い出す。

・以上の作業を自動的に行う仕組みを、「検疫ネットワーク」といい、認証機能のあるスイッチや無線APとRADIUSサーバと検疫サーバなどを組み合わせた、セキュリティ製品あるいはセキュリティサービスとして様々なベンダーから販売されている。かなり高価なシステムである。

・小規模なオフィスなどでは導入が難しいことは間違いない。家庭用ルータを使って、インターネットだけを共用し、社内LANにつないでいる他の端末とは相互に通信できない仕組みを作ろうと思い検証した。OSやセキュリティソフトの更新、クラウドを使ったスキャンの実行にはインターネットだけが利用できればいい。（プライバシーあるいはポート）セパレータ（機能）という用語が思い浮かぶなら、それですよ。

・すでにウィルスに感染しているPCをインターネットにつなげることは、情報漏えいの可能性があるので、あくまで検証ということで、ご理解ください。「検疫ネットワーク的」は社内LANとの間の通信をできないようにするだけで、インターネット間はただのルータです。本格的に行うなら、検疫作業に必要なURLやドメインのみへの通信のみを許可するようにプロキシサーバを構成し、「検疫ネットワーク的なもの」のルータと対象PCの間に設置することが必要です。

・UTM（IPS）などのセキュリティゲートウェイがすでにあるなら、それらのセキュリティ機能を利用できるように検疫ネットワーウ的なルータを設置するというのも手ですが、ウィルスに感染したPCの情報漏えいをブロックできるかは、自己責任で調べて、判断してください。

・検疫ネットワーク的な仕組みのルータの設定は、社内ネットワークとは異なるネットワークアドレスを設定します。WAN側は社内ネットワークのIPアドレスの一つを自動または手動で割当。LAN側は異なるセグメントとします。以下の事例では、社内LANが192.168.1.0/24のネットワークで、インターネットに接続する際のDG(デフォルトゲートウェイ）は192.168.1.1です。検疫ネットワーク的なネットワークは192.168.11.0/24で、そのDGは、192.168.11.1です。

・あとは、今回追加した家庭用無線ルータのパケットフィルタを以下の図のIPフィルタ登録情報のように設定します。社内LANの元からあるルータの設定ではないので、注意してください。メーカ・機種が違う場合は適宜マニュアルを見ながら設定します。リストの上下の順番は同じにしないとうまく動きません。上から条件に合うものを適用していくイメージです。

・リスト４番めは必須ですが、社内LANから検疫ネットワークへの通信ができるようにルーティングされていなければ、リスト３番めは不要ですが。今回は、２つのネットワーク間の相互通信を確認するため、一旦ルーティング設定をしたので、必要でした。また、リスト２番目は社内LANのルータの設定を確認する必要があり入れていますが、運用開始後は削除したほうがいいです。通過させるべきパケットの宛先と送信元のIPアドレスを考えればその理由はわかると思います。社内LANのUTM等を利用する場合は、ご自身で、許可が必要なパケットの宛先と送信元のIPアドレスがどのようになるかを考慮して工夫してください。

※２つのネットワークでインターネットが利用できること、ping コマンドで２つのネットワーク間で相互に通信できないことを確認する。以上です。

EMOTETなどスパムメール対策（不完全版　適宜補完要　素人お断りです）

2022-03-11T11:30:05+09:00

メールサーバを自分で管理している場合とYahooやGoogleなどのフリーメールおよびISPの管理するメールサーバを使っている場合と対策する部分は異なります。

（受信側対策例）
・スパムメール（前回までの迷惑メール、詐欺メール、なりすましメールという表現を統一）を送りつけている送信元IPアドレスは偽装が困難(絶対できないとは言えない）なため、メールサーバを管理している場合は、メールサーバの方でそのIPアドレス自体をブロックする。これはメールソフトやエンドポイントセキュリティツール、UTM等のブラックリストに登録するというものではありません（素人お断りなので説明はしません）。Googleやマイクロソフトのメールサーバが行っている方法で、スパム情報を集めている団体のブラックリストなどを使って、スパム送信元IPアドレス自体を受信側サーバで拒否するものです。これは、自社ドメインを持っていて、メールサーバも自社専用である場合に可能と思われます。

・スパムやウィルスの自動チェックを利用する。これについてはサーバ・社内のUTMなどのネットワーク・セキュリティ装置・個々のPC端末のどのレベルでも行えます。各ベンダーに相談しましょう。IT要員の仕事です。

・「エモテットやその他のスパムメールの事例を周知し、開かない・・・・・・」といったことは当たり前なので、割愛します。絶えず添付ファイルを送り合っている業者や取引先とはSMIMEをつかった送信者自体のデジタル署名を検証する仕組みを構築しましょう。送信者本来のサーバを経由したスパムメールでも防ぎ得る可能性があります。送信者と受信者のPC間でメールのなりすましや改ざんがないことを検証可能です。送信者のPC自体を操られた場合はどうにもなりませんが・・・
・PC自体のウィルス対策をきっちりとしましょう。

（送信側対策例）
・ドメインを取得しているサービスの管理画面からDNSサーバに最低限SPFレコードを追加して、受信者側のメールサーバが送信者ドメイン認証を利用できるようにします。自社メールアドレスからフリーメールなどにテスト送信し、ヘッダーを確認すれば設定できているか確認できます。YahooやGoogle、マイクロソフトの受信側メールサーバはSPFやDKIMなどにも対応しています。
詳しくはドメインを取得、サーバを借りているホスティング業者に相談してください。社内のIT要員の仕事です。

・複数のドメインでメールサーバというかそのIPアドレスを共用している場合は、すでに上記設定はできていると思われるので、メールの送受信テストで確認しましょう。この場合は社員のメールアドレスとログイン情報（PW）をしっかり管理しましょう。漏洩が疑われたときはPWやメールアドレス自体の変更を検討しましょう。メールアカウント自体を乗っ取られると、送受信のスレッドも盗み取られるため、エモテットの拡散以外にもいろいろな被害を受けると思います。

・WEBメールで２要素認証を利用できる場合は、IDとPWのみで認証できるOutlook等メールクライアントを管理画面で利用できないようにし、WEBブラウザでの利用のみにしましょう。POPやIMAPを無効にするという操作や信頼性の低いアプリを使えないようにする設定はフリーメールの管理画面でもできます。メールソフトの初期設定とも永久におさらばです。半永久的にメール本文などを残したいときはPDF化して、相手ごとや日付別のフォルダに整理したりして文書のような管理の方法を取ります。

・受信側対策例ともかぶりますが、ネットワーク・セキュリティ装置レベルや各PCレベルで送信時にも自動ウィルスチェックをする。PCを不正操作されないように、端末（エンドポイント）のセキュリティ対策もしっかりしましょう。重要な取引相手とはSMIMEやPGPなどのデジタル署名の検証で相手を確かめ合う仕組みを構築しましょう。

※以上は完全版ではありません。ご自身でも様々な対策を考え、実行してください。そうして、前回紹介したようなスパムメールの送信者になったりや送信者と思われたりする事態を防ぐようにしましょう。

なりすまし（詐欺）メールを見分ける（２）

2022-03-09T23:57:44+09:00

・SPFに対応した受信側サーバはエンベロープFROMのドメインの権威DNSサーバのSPFレコードをしらべ、そのドメインで許容されている送信側のメールサーバのIPアドレス（複数ある場合もある）を確認し、実際に受信側メールサーバとの接続を確立した送信側のメールサーバのIPアドレスを照合し、一致する場合はpass、不一致の場合はfailとする。

・受信側サーバとクライアント（送信側サーバ）は３ウェイハンドシェイクで接続を確立するため、IPアドレスを偽装してメールを送信しようとしても、戻りのパケットを受け取れず、接続が確立できない。したがって、接続元（クライアント）IPアドレスは偽装できないというのがSPFの有効性の根拠である。

・なりすましたいドメインの権威DNSサーバのSPFレコードを書き換えるか、受信側のキャッシュDNSサーバをインジェクションしたり、本来のメールサーバダウンさせて、すり替わることができれば、SPFを無力化できるかもしれないが、ミッション・インポッシブル的なことになる。

・お約束のなりすましメールのヘッダの実例をお見せします。OCNはSPFの判定のみとなっているようです。以下の実例ですが、EMOTETの被害にあって、情報を盗まれたり、本来のメールサーバを乗っ取られ、なりすましメールの発信元になっている可能性あるので、ヘッダーにあるIPアドレスやドメインに対しては悪意をいだかないようにしてください。あなたの会社のドメインやメールサーバも以下のように悪用されている可能性もあります。なりすましメールや詐欺メールの被害を防ぐために事例を示しているだけです。送られてきたメールは間違いなく悪意があるが、ヘッダー解析して判明した送信者が攻撃者か被害者かはもっと詳しく調べないとわかりません。国や企業に雇われたホワイトハッカーなどの仕事です。

１.SPFがpass。
SPFレコードに記載のあるメールサーバのIPアドレスとメールを送信してきたサーバのIPアドレスが一致するので、ドメインとメールサーバは同一の所有者である可能性は高いが、ドメイン(.cn)の国名（中華人民共和国）とメールを送信してきたサーバのIPアドレスの割当は別の国（シンガポール）です。権威DNSサーバのコントロールも奪取されているということでしょうか。「えきねっと」さんの本当のドメインはeki-net.comなので、勝手に名乗られているだけです。

件名：【重要】えきねっとアカウントの自動退会処理について
差出人：えきねっと「JR東日本」

２.SPFがnone。
エンベロープFROMのドメインを調べると北米のホスティング業者がオークションにだしているドメインでした。メールの送信元IPアドレスの割当は、別の国です。SPFレコードをコンテンツサーバ（権威サーバ）に設定しないと、メールサーバは乗っ取られていないのに、ドメインを詐称され、迷惑メールやなりすましメールの送り主にされ、自社とは関係ないという言い訳も難しくなります。ホスティング業者でレンタルしている権威DNSサーバに送信者ドメイン認証の設定を行いましょう。勝手に名乗られているAmazonさんに落ち度はありません。

件名：Amazonプライム会費のお支払い方法に問題があります、支払方法を更新する
差出人：Amazon

３.spfがfail。
エンベロープFROMと表向きの差出人のメールアドレスは＠の前は違いますが、ドメインはどちらもmercari.jpです。ただし、送信者ドメイン認証であるSPFはfailなので、メール送信者はメルカリではありません。送信元IPアドレスの割り振りは中華人民共和国のものですが、サーバが乗っ取られているだけかもしれません。このIPアドレスが攻撃者かEMOTETなどの被害者かヘッダの情報だけではわからないので注意してください。このメールの送信元IPアドレスはメルカリがメールサーバで使っているものとは一致しないと言うことが、メールの受信者が確認することができる状態になっているということが重要で、SPFが有効に働いている実例として挙げておきます。

件名：【重要なお知らせ】mercari ご利用確認のお願い [メールコード M*********7]
差出人：メルカリ

なりすまし（詐欺）メールを見分ける（１）

2022-03-08T22:53:43+09:00

・筆者は、OCNのメールアドレスを持っているので、結構なりすましメールが集まってくるので、次回、そのヘッダーを実例として出したいと思います。

・GmailやOutlook.comだと迷惑メール（広告メール）は届きますが、なりすましメールはほとんど受信トレイに入りません。日本と外国の思想の違いで、日本のメールプロバイダはメールが怪しくても届けないと、届かないと文句を言われるので、受信サーバが受け付けます。どうするかは自己責任で決めてね。

・外国の場合は、送信側メールアドレスやメールサーバがブロック（ブラック）リストにある場合は無条件に拒否・受信しません。送信側サーバには拒否の理由をエラーコードで伝え、送信者にはエラーメールが届きます。暗黙理にブロックリストにないメールアドレス、送信サーバを使ってくださいと言っています。ただ、日本のISPやホスティングサービスも無視しているわけではなく、迷惑メール対策できるようにツールを用意している場合があります。

・OCNメール（WEBメール）の場合、「迷惑メール自動判定」というものが用意されています。OCNメールにログインし、設定から次の画像のように「迷惑メール自動判定」が有効な状態に設定します。ヘッダーに、[X-OCN-SPAM-CHECK: 100.00%]といった記述が入るようなります。迷惑メール度を表していて、それが100％だと確実に迷惑メールということです。さらに件名の先頭に[meiwaku]というラベルをつけられるので、迷惑メールの識別や自動仕分けがしやすくなります。

・ヘッダーを解析すると、なりすましメールと思われるものも[meiwaku]がついていないときがありましたが、２回めに同じメールが来たときには[meiwaku]がついたので、見逃しもあるのかもしれません。それでも、メールの自動仕分けで、件名に[meiwaku]がついているときは「迷惑メール」フォルダに移動するルールを作ると、受信トレイが驚くほどスッキリします。

・外国と日本のメールチェックの違いは、まだあります。外国、特にアメリカは迷惑メールもしくはウィルスメールのどちらかの判定が出た場合、もう片方のチェックは省略するということです。

・迷惑メールと判定したメールの添付ファイルなどを開いて、ウィルスに感染しても、ただの間抜けと思われます。またウィルスメールとして判定されているのに、迷惑メールじゃないかもしれないとか言いません。日本人は２つ機能があるなら両方チェックするのが当たり前と思ってしまいますが、外国では無駄な時間やコストがかかると考え、どちらかの判定を受けたメールは躊躇なく削除して当たり前ということです。

なりすましメールの仕様？について

2022-03-07T00:17:43+09:00

・EMOTET（エモテット）感染等によって、なりすまし対象のメールアドレスのパスワードを含む送受信のための設定値やアドレス帳、スレッド（なりすましメールの送り先とのやり取りがわかるメール本文）が、なりすましメールを送信する攻撃者に知られたとき。

・送信者が実際に使用しているメールサーバを経由してなりすましメールが送られる。この場合、メールヘッダ等にも不審なところがなく自然であり、当然、送信者ドメイン認証もPASSする。なりすまされた相手がパスワードを変更するなどして、攻撃者が本来のメールサーバにアクセスできなくなるまでは、迷惑メールフィルターも効かない可能性が高い。

・返信や転送を装ったりして送られるので、タイムリーな本文だと、業務上、添付ファイルも開かざるを得ないと思ってしまう。本文に不自然な日本語がないかとか、知られた文例に似ているなどの判断をする。AIを使った判定が可能かもしれないが、確実ではない。送信者に、電話などメール以外の手段で確認するしかない。

・攻撃者が本来のメールサーバにアクセスできなくなっても、攻撃者のサーバーから、実際の送信者のメールアドレスを装ったなりすましメールが送られる。この場合は送信者ドメイン認証が通らない。pass以外の値を取ることが多い。値ごとの意味を簡単に説明する。

・none：受信側サーバは送信者ドメイン認証に対応しているが、送信者の権威DNSサーバのTXTレコードにはSPFに関する記述がなく、検証できない。

・fail や hard fail、soft fail: 受信側サーバに接続してきた送信側サーバのアドレスが送信者ドメインの権威DNSサーバに記述されたメールサーバのIPアドレスと異なる。

・Received-SPF や　DKIMといった送信者ドメイン認証の要素がヘッダーにない。受信側サーバが送信者ドメイン認証に対応していない

※エンベロープFROM（封筒の差出人）のドメイン自体を攻撃者が用意、送信者ドメイン認証に必要な仕組みを整え、その権威DNSサーバに登録されたメールサーバからメールを送信するときは、矛盾がないので、Passとなるので注意が必要。この場合、エンベロープFROMがメールFROMとはかけ離れていることが多い。

※メールFROM（本文というか表向きの差出人）とエンベロープFROM（封筒の差出人）が一致しなくてもルール違反ではないため、メールとしては成立する。メールFROMは相手の知っているメールアドレスを詐称し、エンベロープFROMは送信者ドメイン認証の対象となるため、詐称しないことが多い。エンベロープFROMが知らない不審なメールアドレスであれば、そのメールは開かないほうがいい。

ブラウザのログイン情報の管理について

2022-03-06T00:07:32+09:00

・２回にわたって、WEBで出回っている情報から、WEBブラウザに保存された、利用サイトのログイン情報（IDやパスワード）のエクスポート・インポートの話をした。PCの新旧入れ替え時に重宝する手段ではあるが、以下のような話を聞いた。

・従業員が仕事に使っているホスティングサービスのWEBメールだが、会社用のメールアドレスを共用しているので、管理者というか経営者が従業員にパスワードを入れさせないというかパスワードを教えないように、PCのセットアップ時に自分が入力し、ブラウザに記憶させているそうである。

・ブラウザに保存されたログイン情報をエクスポートしたり、目視で確認するときに必要なパスワードはPCにサインインするときのパスワードとわかったが、従業員もそのパスワードは知っているので、自分のやっていたことは無意味であるとの仰せである。GoogleやMicrosoftに文句を言いたいようである。

・IDとパスワードのみで認証を行うという自体、セキュリティレベルが低く、通常はワンタイムパスワードや指紋などの生体認証および端末認証（クライアント証明書等）を併用してもらったほうがいい。そうすれば、万が一パスワードが漏洩しても、社員以外（OTPや生体認証の場合）もしくは社外（端末認証の場合）からの不正アクセスは防げる。

・EMOTETの再流行の兆しがある。ブラウザのログイン情報も抜かれてしまう可能性があるので、IDやパスワードのみでアクセスできるサイトの認証方法の見直しをしたほうがいい。通常、Outlookなどのメールクライアントを使用した場合、メールサーバとの認証はIDとパスワードしか使わないのもEMOTETでメールが悪用される理由でもある。

・EMOTET感染後の処置で、メールのパスワードを変えるようにいわれるのも、攻撃者にそれ以上、メールサーバにアクセスさせないため。ただし、変更したパスワードをEMOTET関連のマルウェアを駆除できていないPCに設定してはいけない。

・パスワード変更後も本来のメールサーバを経由しないなりすましメールは送信されるが、受信側メールサーバが送信者ドメイン認証（SPF、DKIM、Sender ID）に対応していて、なりすまされる側が権威DNSサーバのTXTレコードに送信者ドメイン認証に必要な情報を記述していれば、受信側でなりすましメールを機械的に振り分けることが可能になる（Outlookはヘッダー情報の内容で仕分けルールを作ることが可能）。

・メールサーバやDNSサーバの設定方法がわからない場合は、メールプロバイダ（ホスティング業者など）に問い合わせたり、該当するマニュアルを確認すること（PCの設定ではありません）。

ブラウザのログイン情報の管理について（インポート編）

2022-03-05T00:51:37+09:00

・CSVファイルに抽出されたログイン情報はChromeとMicrosoft Edgeが同一の形式で４つのカラム（name,url,username,password）からなる。Firefoxの場合はもっと複雑で９つのカラム（url,username,password,httpRealm,formActionOrigin,guid,timeCreated,timeLastUsed,timePasswordChanged）からなる。

【Microsoft Edge】CSVファイルのインポートのボタンは、現在は秘匿されておらず、エクスポートと並んで配置されている。edge://settings/passwordを開いて「保存されたパスワード」の右の３つの点のボタンをクリックし、「パスワードのインポート」をクリック。

【Firefox】以下の参考サイトを探したので、確認してみたい。
　　　https://websetnet.net/ja/how-to-import-passwords-into-firefox-from-a-csv-file/

　アドレスバーにabout:configを入れてEnter。
「設定名を検索」でsignon.management.page.fileImport.enabledをFalse からtrueに変更する。

about:logins をアドレスバーに入れてEnter。右上の点が３つあるボタンをクリックすると、「ファイルからインポート」というメニューが出現する。

【Google Chrome】多くのサイトで様々な方法が紹介されているので、ご自身で検索してみてください。すべてのプラットフォームで使えるDevToolsを使った一時的な、ログイン情報（CSVファイル）インポート機能の有効化がおすすめ。Google Chromeの最新バージョンでも再現できました。

・GoogleChromeのアドレスバーに　chrome://settings/passwords　を入力し、Enter。
・「保存されたパスワード」の右の３つの点をクリック。「パスワードをエクスポート」を右クリックして「検証」をクリック。下の図のように、このボタンのコードが青く反転して選択されるので、その上のコードの赤い線で囲んだ文字”hidden”を削除する。一時的に「パスワードをエクスポート」と並んで「インポート」ボタンが表示される。ページを開き直すと、もとに戻るので、設定を戻す必要もないです。

・こんなに簡単に重要なパスワードがインポート・エクスポートできるので、業務で使用するPCから会社のアカウントの情報が抜かれるのは困ると思われた管理者の人がいるかもしれません。

・Windowsの場合を例とすると、標準ユーザ（PCの操作はできるが、ソフトをインストールしたり、PCの重要な設定を変えようとすると管理者アカウントのパスワードを求められる)にしかサインインできない状態で使用しているユーザは、ログイン情報のエクスポート・インポートはできないようにしておかないといけないです。ただし、現時点ではどのようにすれば、そのように規制をかけられるかは不明です。

・業務で社員などに使用させているPCにMicrosoftアカウントでサインインさせたり、管理者ユーザでサインインさせている自体がおかしいので、まず、その点を改めましょう。PCの管理者と使用者は別の人でないといけないのです。

・人を雇うよりずっと安価なサポートセンター（社外サポートデスク）と契約して、PCやIT機器を管理する技術系社員を不要として、採用しなかったり、解雇するような会社があります。そんな会社に限って、情報漏洩などのセキュリティインシデントを起こします。
・社内でしっかりとしたIT要員を確保し、PCやIT機器を正しく管理し、経営者がその状況を把握し、その成果を実感できれば、最高です。それでも、社外サポートデスクと契約する場合は、社内のIT要員の相談先としての役割を果たせるような高度な技術や専門性を持ったところと契約することが重要です。そうしなければ、日本でITやセキュリティの技術者が不足しているという状況は全く改善しないでしょう。
・追記として、社内のIT要員は会社で利用しているPCやその他の機器やインターネット・サービス・プロバイダやホスティングサービス等のサポートセンターとやり取りもするので、広範囲な知識を要します。それを普通の業務しか知らない社員にやらせるというのは、無理がありますし、相手のサポートセンターも説明等に無駄な時間を要しますし、状況が正確に把握できなければ間違った回答しか得られないということも起こります。無意味な負荷や混雑の原因です。

ブラウザのログイン情報の管理について（エクスポート編）

2022-02-27T23:26:20+09:00

・今回のお題は、新旧PCの入れ替え時、ブラウザに保存された、IDやPWを一括してインポート・エクスポートするというもの。WEB上で検索して、参考になるサイトを見つけて、実際にやってみること。ブラウザはMicrosoft EdgeとFirefox、Google Chromeの３種類。

・エクスポートは比較的に簡単で、各ブラウザで以下のアドレスを開くと画面が開く。

【Firefox】　　about:logins をアドレスバーに入れてEnter。右上の点が３つあるボタンをクリックすると、「ログイン情報をエクスポート」というのがある。

【Google Chrome】　　chrome://settings/passwords　をアドレスバーに入れてEnter。薄い文字「保存したパスワード」の右にある３つの点のボタンをクリックし、「パスワードをエクスポート」をクリック

【Microsoft Edge】　　　edge://settings/passwords　をアドレスバーに入れて、Enter。「保存されたパスワード」の右の「検索パスワード」の更に右の３つの点のボタンをクリックし、「パスワードのエクスポート」をクリック。

※ブラウザに保存されたパスワードを個別に確認したり、一括でエクスポートする際はWindowsセキュリティの画面で、Windowsの場合は、PCにサインインするときのIDとパスワード（もしくはPIN）が必要となる。LinuxもUbuntuやDebian系などはMacと同じキーチェイン（PCにサインインするパスワードとは限らない）だったりする。

注意する点は、エクスポートされたファイルはただのCSVファイルで、パスワードが丸見えであること。バックアップする場合はPWや指紋認証による鍵をかけられるUSBメモリなどに保存すべきである。

何故か、インポートについては、ブラウザの設定では、メニューの中に存在していなかったり、隠されている場合がある。次回参考サイトとともに紹介します。

※各ブラウザには同期の機能があり、サイトのログイン情報やブックマーク（お気に入り）をマイクロソフトアカウント、Googleアカウント、Firefoxアカウントと関連付けることができ、各サイトのログイン情報は他の端末などに簡単に移行できるが、CSVを使ったログイン情報のエクスポート・インポートは、そういったアカウントとは関係なくID・PWを管理したい場合に重宝する。

WSL（Windows Subsystem of Linux）の導入

2021-11-28T19:28:50+09:00

・WindowsのPCを使用しながら、Linuxのツールを同時に使用できるのは、非常に便利である。
拙者が作成中のホームページ「ITの経絡秘孔図的ななにか」（工事中）にCUI（Command User Interface）を使ったネットワークやセキュリティの問題に取り組む手法の解説を盛り込もうと思っている。

・1台のノートPCで、WindowsとLinux（CUIのみでも）が使用できれば、仕事が捗る。デュアルブート環境やVertualBoxやVMWare、Hyper-Vといったスーパーバイザーを用いて、GUIも含めて、WindowsとLinuxを共存させてもいいが、Windows10（Home/Pro)で手間がかからず使用できるWSLは最有力候補である。他の方法に比べてPCの負荷も少ないと思われる。

・とりあえず、intel Core i5を搭載したPC１台とCore 2 Duoを搭載したPC２台で検証を行ってみた。３台の大きな違いは、i5の方はUEFI、Core2DuoがレガシーBIOSのシステムであることである。WSLを使用するにはUEFIやレガシーBIOSでCPUの「仮想化」を有効にしないといけないが、操作が異なる。WEB上にたくさん情報あるので、それは割愛する。

・タスクマネージャを詳細表示に切り替えて、「パフォーマンス」タブのCPUの表示項目にある「仮想化：」の右が「有効」になっていればWSLを使用する準備は整っている。コマンドプロンプトで以下のように実行する。ディストリビューションはUbuntuを選択した。

wsl --install -d Ubuntu

・i5はWindows10Proだが、Core2Duoの方はHomeとProの２種類。WIndows10のバージョンがi5は21H1、Core2Duoは２台とも手動で21H2にしたもの。

・私なりのこだわりだが、WIndows10以降は、まず、PCごとに異なるMSアカウント用いてセットアップし、Microsoft officeなど主要なソフトをインストール・認証する。ただし、メール設定などは行わない（通常の使用は行わないから不要）。その後、その他のアカウントでローカルアカウント（用途により標準ユーザにしたり管理者にしたりする）を作成し、通常はローカルアカウントで運用する。OneDrive等の利用は、アプリごとにMSアカウントにサインインする方法を使用する。メンテナンス時のみMSアカウントを使用してサインインする。

・このこだわりのおかげか、Windows10で大きなトラブルになったことがない。WSLも３台とも何の問題なく使用できるようになった。Ubuntuをインストールしたが、初期はnet-toolsが入っておらず、arpやifconfigが効かなくて驚いた程度。ところが知人のPCでは、wslコマンドでUbuntuインストール時、以下のようなエラーでWSLを使えないという。CPUの仮想化は有効にできているとのこと。

Installing, this may take a few minutes...
WslRegisterDistribution failed with error: 0x80370102
Error: 0x80370102 ??????????????????????????????????????

Press any key to continue...

・知人のPCはユーザアカウントが１つで、MSアカウントのみだった。私と同じように、追加でローカルアカウント（標準ユーザ）を作成してもらい、そのアカウントでサインインしてWSLを問題なくインストール・実行できた。その他のトラブルシューティングは以下を参照ください。

https://docs.microsoft.com/ja-jp/windows/wsl/troubleshooting