皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

先日、ある方から連絡をいただき、過去の『別セグメントへのTCP/IP印刷』の件を思い出しました。

今回は、ずっと印刷できていたものが印刷できなくなってしまったという話しです。

別セグメントへの印刷ができなくなった

過去記事にもあるように、セグメントが異なるプリンタへの印刷は可能です。

ただし、条件があります。

プリンタの置かれているセグメントにあるルータの設定で『プライバシーセパレート（ネットワーク分離）』は『OFF』にしておかないといけません。

さて、本題に戻り、別セグメントへの印刷ができなくなってしまった件ですが、話しを聞いてみるとどうやらプリンタの置かれているセグメントのルータを交換したようなのです。

実際に設定を見たわけではないので何とも言えないですが、可能性的には以下のようなことが想定できます。

・別セグメントに置かれているプリンタのIPアドレスが変更された

ということになるかと思います。

ルータを交換した場合、クライアントからのアクセスやプリンタからの印刷チェックも当然行いますが、その際に他のセグメントからの印刷はチェックされずに作業を終えてしまったのでしょう。

この際、固定化されていたプリンタのIPアドレスが変更されたか、もしくはクライアントと同じDHCP取得にしてしまった可能性もあります。

ここで言えることとして、ルータなどを交換する場合にはネットワーク全体をチェックした上で行わなければいけないということです。

そうしないと、他部署や他業者が巻き添えになったり、他業者にサポート依頼をするために会社が余分な支出を強いられることにもなります。

大手企業が行うことも結構いい加減なものです。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

昨今、DNS（Domain Name System）インフラを狙った攻撃が増加していることを受け、ICANN（Internet Corporation for Assigned Names and Numbers/アイキャン）が『DNSSEC（Domain Name System Security Extensions）』の導入を呼び掛けています。

では、『DNSSEC』を導入することで何が変わるのでしょうか？

DNSSEC導入で防げるリスク

このDNSインフラの改ざん被害、米国土安全保障省も全省庁に警戒と緊急対策を指示しているほど深刻な問題です。

ではDNS情報の改ざんは検知できないのか？

『DNSSEC』を導入すればそういった改ざんは検知できます。

『DNSSEC』はデータに対してデジタル署名を行うことで改ざんを防ぐ技術ですから、その導入が進めば多くのDNS情報の改ざんが検知できることになります。

（※　すべての攻撃を防げるわけではありません。）

つまり、リスクを減らすことができるわけです。

この『DNSSEC』、日本においてはさらに遅れた状態になっています。

『DNSSEC』はドメインのレジストラとホスト、両方がそれに対応している必要があり、一部のレジストラにおいては有償オプションとして対応しているものの、ホスト側においてはなかなか対応に踏み切っているところは少ない状態にあります。

また、ユーザー側の認知度も低い状態です。

それらを考えると日本における普及はまだまだ時間がかかりそうですが、少しでも多くのレジストラやホスティング会社の対応、そしてユーザーの利用が進むことを願うばかりです。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

ウェブサイト（ホームページ）を公開している会社や店舗であれば、自社や自店のウェブサイト（ホームページ）にどれくらいのアクセスがあるのかが気になるところです。

しかし、その中に自社や自店からアクセスしたものも含めていては正確なアクセス数に大きな誤差が生じる場合があります。

WAN側のIPを定期的に見直す必要性

ウェブサイト（ホームページ）のアクセス解析を行う場合、多くはGoogleのAnalytics（アナリティクス）が使われていますが、それに何も設定をしなければ全てのアクセスが含まれてしまうため正確なアクセス数とは言えないことが多いのも事実です。

つまり、自社や自店の従業員・スタッフがアクセスした数まで含まれてしまうため、大幅にアクセス数が増えてしまっていることも考えられます。

これはAnalytics（アナリティクス）の管理上でフィルタリング設定を行うことで除外できますが、問題なのは自社や自店で契約しているインターネット回線のWAN側IPアドレスです。

どういうことかと言うと、中小・零細企業、小規模事業者の多くは固定IPアドレスの契約をすることは少なく、OCNやauなどのプロバイダから割り当てられる動的なIPアドレスを使用することになります。

これが今日の本題です。

プロバイダから割り当てられる動的なIPアドレスはある日突然変わることがあります。

例えば、プロバイダ側で設備メンテナンスがあったとか、影響する部分において障害が発生したとか、自社や自店付近などにおいて停電があったとかによる影響を受けます。

このような場合、自社や自店に設置されているルータはIPアドレスを取得し直すため、WAN側のIPアドレスが変わってしまうことがあるのです。

それ以外にも、セキュリティ的な観点から一定期間を経過すると割り当てているIPアドレスの割り当て直しを行うこともあり、WAN側のIPアドレスが変わってしまうのです。

これを把握しないまま放置していると当然ながらアクセス解析に影響しますので、定期的にWAN側のIPアドレスを確認し、変わっていたのであればAnalytics（アナリティクス）のフィルタ設定にて除外しているIPアドレスを変更してあげる必要性があります。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

迷惑メールは、事業者、個人を問わず無差別に送られてきますが、通常は普通のメールアドレス宛に送られてきます。

しかし、場合によってはこんなところからも送られてきたりします。

メールフォームからの迷惑メール

そうです。

タイトルの通り、お問い合わせ向けなどに用いられているメールフォームから迷惑行為を行ってくる場合もあったりします。

この場合は少々厄介です。

お問い合わせなどに使われるメールフォームの場合、メールの差出人は自社が管理しているメールアドレスから送られてくるようにすることが多いと思いますが、これは迷惑メールが送られてきたからといってブロックしてしまうわけにもいきません。

そこが厄介なところです。

では、どのように対処するか？

設置されているメールフォームをカスタマイズすることが可能であれば、ブロックリストをメールフォーム側に作ってしまうことです。

例えば、迷惑行為を行った側のIPアドレスを取得し、それをリスト化してブロックしてしまえば、自社側にて解除しない限りそのIPアドレスから迷惑行為を行うことをできないようにすることが可能です。

この方法の場合、お問い合わせの受付メールが送られてくる前にストップをかけられます。

つまり、送信ボタンを押した時点でIPアドレスのチェックが入り、実際にはメールが送られないようになるということです。

また、この迷惑行為が自社のターゲットではない国からのものである場合、単純にその国からのアクセスすべてをブロックしてしまうということでも良いでしょう。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

昨今、インターネットに接続されたIoT機器がサイバー攻撃を受ける被害が多発しています。

それを受けてと思われますが、NICT（国立研究開発法人情報通信研究機構）が事前調査を行うようです。

NICTによるIoT機器等の事前調査実施

国立研究開発法人情報通信研究機構（NICT）は、パスワード設定等に不備のあるIoT機器の調査等をNICTの業務に追加（５年間の時限措置）する「電気通信事業法及び国立研究開発法人情報通信研究機構法の一部を改正する法律」が今月1日に施行されたことを受け、同調査等の業務の実施（今年度内に開始予定）に向けた検討、準備を進めてまいります。
今後の具体的な検討にあたっては、日本国内でインターネットに接続されたIoT機器等につき、当該接続状況などの全体的な傾向、概数等を把握する必要があることから、ポート開放状況の把握など、現状に関して、事前の準備のための調査を実施することといたします。

このように、NICT（国立研究開発法人情報通信研究機構）が来週の14日から事前調査を実施するようです。

事前調査の内容としては、日本国内のIPv4アドレスを対象に、以下のポートスキャンが実施され、ポートの開放状態のアドレス数の規模などが調査されます。

・22Port/TCP（SSH）

・23Port/TCP（Telnet）

・80Port/TCP（HTTP）

・etc…

また、ポート開放状態のアドレスに対してバナー情報（機器自身が公開しているサービスの種類やバージョンなどを知らせるメッセージ）の取得を行い、サービス種類やバージョン情報、機器種別などの状況調査を行うとしています。

事前調査に使用されるIPアドレスは以下の通りです。

210.150.186.238

122.1.4.87
122.1.4.88

このIPアドレスから実施されます。

以上、ご参考までに。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

今朝、トレンドマイクロ社のあるコラムを読んでいたところ、『ビジネスメール詐欺』に関連したものが紹介されていましたので、今日はそれをお伝えします。

類似ドメインを使ったなりすまし詐欺

事業者の場合、メールを送信する際に『なりすまし』対策の一つとして『SPF（送信元メールサーバのIPアドレス確認）』、『DKIM（電子署名確認）』、『DMARC（SPFとDKIMの認証を利用した認証と処理宣言）』といったドメイン認証を用いていることが多いですが、それを逆手に取ったような事象が起きています。

それは、『類似ドメイン』を使った『なりすまし』詐欺です。

例えば、example.comというドメインがあったとします。

この『example.com』になりすましたい場合、偽物のドメインとして『exarnple.com』というドメインを使い、事業者へ『請求書』などのメールを送りつけます。

この例によるポイントは、exampleの『m（エム）』を『rn（アール・エヌ）』に変えて模倣されている、『模倣ドメイン』であることです。

確かに、パッと見た限りでは『rn（アール・エヌ）』が『m（エム）』に見えてしまいます。

そして、この模倣ドメインと『SPF』、『DKIM』、『DMARC』といったドメイン認証を組み合わせることで余計に本物であるかのように見えてしまいます。

理由は簡単です。

模倣ドメインは攻撃者側が所有しているドメインですから、『SPF』、『DKIM』、『DMARC』、いずれも正常に認証をPassさせることができるからです。

『m（エム）』と『rn（アール・エヌ）』以外にも、『0（ゼロ）』と『O（オー）』、『o（オー）』と『a（エイ）』、『S（エス）』と『5（ゴ）』などがだましの模倣ドメインに使われていたりします。

このような『なりすまし』に対しては、徹底した社内教育に加え、それらを検知するセキュリティの導入などにてリスクを軽減する必要があるとされています。

参考：『ビジネスメール詐欺：DMARCなどドメイン認証のすり抜けを狙った手口』

それは、コメント投稿へのスパム（迷惑）行為です。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

さて、冒頭に書いたコメント投稿に対するスパム行為、困ったもので終わることはありません。

また、そのコメントスパムの多くは海外からのものです。

では、このようなコメントスパムはどのように対処したら良いのでしょうか？

WordPressのコメントスパム対策

まず、対策方法の一つとして海外からのアクセスを制限してしまうという方法がありますが、これはあまりお勧めではありません。

スパム行為を行ってくる人であればVPNソフトを利用するなど、制限をすり抜けてくるような手法は簡単に行えるでしょうから制限をかけたことにならない可能性があります。

では、ここからお勧めなものをご紹介していきます。

※　前提として、スパムフィルターである『Akismet Anti-Spam』は海外に限らず有効的ですので、予め有効にしておくことがお勧めです。

では、その１です。

＜SiteGuard WP Pluginを使う＞

WordPressのプラグインとして、日本のJP-Secure（株式会社ジェイピー・セキュア）が提供しているWordPress向けのプラグインで、ログインページやコメント投稿に画像認証を追加する機能を搭載したものがあります。

画像認証には、『ひらがな』と『英数字』が選択できますので、『ひらがな』で設定しておけばそれなりの効果を発揮するはずです。

それ以外にも、管理ページへのアクセス制限、ログインページの変更、ログインのロック、ログインのアラート、XMLRPCの悪用防御など、複数の機能が搭載されていますので他の使い道もあります。

参考：SiteGuard WP Plugin紹介ページはこちら

次に、その２です。

＜Throws SPMA Awayを使う＞

これもWordPress向けのプラグインですが、前述のプラグインとは少々手法が異なります。

日本語を含むかどうかの日本語判定を行い、含まれていなければコメントそのものを無視（スルー）するため、ゴミ箱にすらコメントがプールされることがありません。

日本語以外のコメントは投稿を完全に無視したい場合に向いています。

それ以外にも、NGキーワード、リンク数、IPアドレスなどによる判定の設定も可能です。

参考：Throws SPAM Away

最後に、一つ注意事項があります。

『SiteGuard WP Plugin』と『Throws SPMA Away』の両方を使おうと思われた方、どちらか一つを選択された方が良いです。

双方のプラグインがぶつかる部分がありそうです。

具体的には、コメント欄で画像認証を入力せずに投稿してもエラーが表示されず、画面がスクロールします。

日本語でコメント投稿してもです。

コメント投稿時の処理そのものはWordPress本体のプログラムをどちらも使っていますので、そこでぶつかるはずです。

以上、海外からのコメントスパムに困っている方など、ご参考になれば幸いです。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

冒頭に書いた内容はある企業にて施されているメール送信に対する施策ですが（SPF、DKIM、DMARC）、この状態でも偽装されたメールは受信者に届いてしまうことはあります。

それは何故でしょうか？

DMARCの宣言が絶対ではない理由

まず、DMARCにはポリシーというものがあり、どのように対処通知を行うかの記述があります。

１．何もしない（none）

２．隔離（quarantine）

３．拒否（reject）

これにプラスして、どれくらいの割合でメールを評価するかの適用割合というものが記述されている場合もあります。

従って、DMARCによる宣言があるからと言って必ず偽装されたメールが受信者に届かないわけではありません。

（ポリシーの設定を『何もしない（none）』にしているケースはよくあります。）

また、DMARCにおいて『拒否（reject）』としている場合でも受信者に届くことはあります。

それは何故か？

受信者側のメールサーバーに委ねている部分があるからです。

DMARCは受信者側に対して通知（要求依頼）はするものの、それに対応する形で受信者側のメールサーバーが設定されていない場合はその通知は適用されません。

（適用しようがありません。）

これらのことを理由に、DMARCによる宣言があるからと言って偽装メールが絶対に届かないようになっているというわけではないのです。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

今日の記事ですが、中小・零細企業、小規模事業者において『DKIM』まで導入することは難しい（レンタルサーバが対応していない場合が多い）などの理由から、それが行えない前提として読んでください。

『DKIM』導入可能な場合においては下記の限りではありません。

さて、自社や自店のドメインが偽装されたメールなどに使われていたことを知っても、ある意味では八方塞がりになってしまう可能性があります。

それはどういった状態だと思いますか？

DMARCのポリシーは受信者の協力も必要

事業者が使っているドメインであれば、DNSのTXTレコードにSPF認証に関する記述が加えられていることは昨今においては普通のことと言えます。

逆に、記述がないのであれば追加しておくべきです。

例：example.com. IN TXT “v=spf1 ip4:***.***.***.*** include:example.com -all”

（***.***.***.***の部分はv4のIPアドレスが入ります。）

さて、このSPFに関する記述が入っている場合でDMARCの記述も追加されている場合、Appleなどはポシリーを『none（指定なし）』にしていますが、MicrosoftやGoogleは『reject（拒否）』にしています。

これ、受信者が転送処理などを行わずにストレートにメールを受信している場合においては『none（指定なし）』から『quarantine（隔離）』、『quarantine（隔離）』から『reject（拒否）』と、フィルター処理の割合を組み合わせながら段階的にポリシー変更を行っていけば良いですが、受信者が転送処理などを行っている場合、相手のサーバ設定によっては『none（指定なし）』から他に変更することで問題が生じます。

例えば、受信者が自動転送設定をしていた場合で、その際のIPアドレスの出力を転送元IPアドレスとしていた場合、送信元ドメインとそのIPアドレスが一致せず、SPF認証は『Pass』とならないため受信者がメールを受け取れない可能性が出てきます。

（DMARCのフィルター処理（PCT）の設定値にもよります。）

このような場合においては正直八方塞がりのような状態になります。

従って、受信者側に自動転送をやめてもらうか、受信者側に転送先メールアドレスを開示いただくか、何らかの協力をお願いすることになります。

（メールサーバの仕様を簡単に変更するわけにもいきませんので。）

まずは偽装されたメールが出回っていることをアナウンスすることからスタートですが、『全く関係のない消費者などが被害にあわない』、『自社や自店のドメインを傷つけない』ためには、最終的にはDMARCのポリシーを『reject（拒否）』にできる環境整備を行っていく必要性があるでしょう。

また、冒頭でも書きました通り、これを送信者側のみで解決しようとした場合は『DKIM』の導入が必要となります。

しかし、それはロシアから送られてきたレポートでした。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

私は普段、偽装メール（なりすまし）対策の一環としてSPFやDKIM、DMARCを使うことをお勧めしていますが、この偽装メール（なりすまし）は日本国内に限った話しではありません。

ロシアから届いたDMARCレポート

普段、DMARCレポートが届くのは現状Googleからのみであったのですが、ある日、ロシアからDMARCレポートが届きました。

その段階では、このロシアからのDMARCレポートそのものがスパムメールなのでは？と疑いをもち、メールのヘッダ情報などを調査しましたが問題は見受けられませんでした。

何かしっくりこず、セキュリティチェックを通してレポートファイルを確認したところ、どうやらロシアのIPアドレス宛にコーポレートドメインを偽装してメールが配信されたようでした。

前者の方はロシアでメールを含めたサービスを提供している企業で、その企業がDMARCレポートを配信する仕組みを取り入れていたことからコーポレートドメインのDMARCレポートが届いたということで、実際に問題な行為を行ったのは後者のIPアドレスを利用した者と考えられます。

このように、偽装メール（なりすまし）は日本国内宛にとどまらず海外宛にまで及んでいます。

現在、コーポレートドメインをはじめすべてのドメインに対してDMARCを採用しているのですが、メールに対する制御は『none：そのまま受信させる』のまま様子見をしていた状態でした。

今回のことを考えると、やはり『quarantine：隔離させる』か、『reject：受信を拒否する』に変更していくことになるでしょう。

これらに変更することで、受信者のメールサーバーに対して隔離、もしくは拒否を依頼することができますので被害を抑制することが可能です。

しかし、課題も残ります。

先日起きたケースとして、相手先がGmailなどに自動転送していた場合、Fromは送信元メールアドレスのままなであったものの、出力されるIPアドレスは転送元のIPアドレスでした。

（相手先の契約サーバーの仕様によって左右されます。）

このような場合はつじつまがあわないことになりますのでSPF認証は失敗となり、DMARCにおけるメールの制御によっては相手にメールが届かないケースが出てきたりします。