皆さん、こんにちは。

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

今日は昨日の続きになります。

『Apache 2.4』では『アクセス制御』の記述方法が『Apache 2.2』から大きく変更されていますので、昨日に続き、今日はいくつかの記述方法をお伝えします。

Apache2.4でのアクセス制御サンプル

＜すべての要求を拒否する＞

これだけは昨日の投稿でも書きましたが念のため。

（Apache 2.2）

Order deny,allow
Deny from all

（Apache 2.4）

Require all denied

＜すべての要求を許可する＞

（Apache 2.2）

Order allow,deny
Allow from all

（Apache 2.4）

Require all granted

＜IPを指定する場合＞

（Apache 2.2）

・許可：Allow from 192.168.0.1

・拒否：Deny form 192.168.0.1

（Apache 2.4）

・許可：Require ip 192.168.0.1

・拒否：Require not ip 192.168.0.1

＜環境変数を利用する場合＞

（Apache 2.2）

SetEnvIf User-Agent “Googlebot” Allowbot
Allow from env=Allowbot

（Apache 2.4）

SetEnvIf User-Agent “Googlebot” Allowbot
Require env Allowbot

こんな感じになります。

少しまとめてみると『Apache 2.4』では以下のようになります。

・すべてを許可：Require all granted

・すべてを拒否：Require all denied

・個別指定で許可：Require ip 192.168.0.1 / Require host example.com / Require env example

・個別指定で拒否：Require not ip 192.168.0.1 / Require not host example.com / Require not env example

＜条件ディレクティブ＞

今まで記述したものに加え、『Apache 2.4』では以下の『ディレクティブ』を使って条件を指定できます。

・RequireAll：すべての条件にマッチすれば許可

・RequireAny：条件に一つでもマッチすれば許可

・RequireNone：条件に一つでもマッチすれば拒否

例えば、Basic認証でIPアドレスも条件に加えた場合、

<RequireAll>
Require user admin
Require ip 192.168.0.1
</RequireAll>

（AuthUserFile、AuthGroupFile、AuthName、AuthTypeなどはApache 2.2と同じです。）

といった感じになります。

ご参考までに。

皆さん、こんにちは。

業務改善を行う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におけるメールの制御によっては相手にメールが届かないケースが出てきたりします。

そしてこの先、信頼できない証明書はホワイトリストから削除されます。

皆さん、こんにちは。

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

今朝の報道によると、GoogleのブラウザChromeは、バージョン61のリリースをもって、中国の認証局（CA）であるWoSignとその子会社StartComが発行するデジタル証明書への信頼を取り消すことを警告しています。

では、何に影響があるのでしょうか？

Chrome61からStartComの証明書が拒否される

日本国内において影響がありそうなのはStartComの方で、無料で使えるデジタル証明書もあることから一部のユーザーが使用している可能性があります。

そして、もしこのStartComの証明書を使い続けた場合、Chrome61がリリースされた段階で『安全ではないもの』として扱われます。

これは、WoSignとStartComの両社が関与した事例の中で、認証局（CA）に期待される高い水準を維持していない内容の事例があり、以前からChromeにおいて段階的に信頼を取り消しつつあったものです。

（現在は2016年10月21日以前発行の証明書のみ信頼しているとのこと。）

この影響は、ブラウザにおいて『安全ではないもの』として扱われる以上、そのサイトへの信頼が損なわれることになります。

単純に言えばイメージダウンになるということです。

従って、もしこれらの証明書を使用しているのであれば、早急に証明書の差し替えを行うべきでしょう。

参考記事：『グーグルに信頼されない証明書』

皆さん、こんにちは。

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

以前にご紹介した記事の中では、GeoIPやGeo Liteを使って海外からのアクセスを拒否する方法を書きました。

今日は、それらが使えない場合などにおける他の方法をお伝えします。

海外からのアクセスをIPアドレスでブロック

日本国内向けに公開しているウェブサイトにおいても、海外から迷惑なアクセスが多発することがあります。

特に、WordPressなどのCMS（Content Management System/コンテンツマネジメントシステム）を使っているウェブサイトにおいてはそれが目立ちます。

このような場合、アクセス元のIPアドレスを個別で指定するのではなく、サブネットマスクを付けて一定範囲を指定する方が効果があります。

例えば、アクセス元のIPアドレスが10.8.6.4だったとした場合に、以下のように.htaccessに記述します。

order allow,deny

allow from all
deny from 10.8.6.0/24

そうすると、10.8.6.0-10.8.6.255（256個のIPアドレス）の範囲をブロックすることができます。

これが、

order allow,deny

allow from all
deny from 10.8.6.0/16

であれば、10.8.0.0-10.8.255.255（65536個のIPアドレス）の範囲をブロックすることができます。

ただし、これらは事前にIPアドレスのデータベースなどにて調べる必要があります。

その調べた結果がすべてブロックしたい国のIPアドレスであれば大丈夫です。

※　サブネットマスクの計算は、インターネット上にサブネットマスク計算のサイトが公開されていますので、それを使うと簡単にできます。

皆さん、こんにちは。

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

先日投稿したGoogle Analyticsでのスパムの記事の最後に、『Google Analyticsにてフィルタリングする方法とは別の方法もありますが、それはまたの機会にお伝えできればと思います。』とお書きしました。

今日はそれを取り上げてみたいと思います。

海外からのアクセスをブロックする

海外からのアクセスをブロックしたい場合、Google Analyticsなどのアクセス解析上でのフィルタリングだけではなく、そもそものアクセスを拒否してしまう方法もあります。

それには.htaccessなどの中に少々アクセス制限を加えることになります。

例えば、ロシアと中国からのアクセスを拒否したい場合の例として、以下のように記述します。

GeoIPEnable On
GeoIPDBFile /path/to/GeoIP.dat
SetEnvIf GEOIP_COUNTRY_CODE CN BlockCountry
SetEnvIf GEOIP_COUNTRY_CODE RU BlockCountry
Deny from env=BlockCountry

ただし、これはGeoIPという位置情報を取得するためのモジュールがサーバにインストールされている場合に限ります。

これが使えない場合、Geo Liteという同じようなモジュールなら使える場合があります。

その場合は以下のように記述します。

SetEnvIf MM_COUNTRY_CODE CN BlockCountry
SetEnvIf MM_COUNTRY_CODE RU BlockCountry
Deny from env=BlockCountry

また、これらのいずれも使えない場合にはIPアドレスをブロックするか、もしくは許可するIPアドレスだけを記述することなら大半のレンタルサーバにて可能です。

プロキシ経由などのアクセス

しかし、これらの方法は一定の効果はあっても完全ではありません。

CN（中国）やRU（ロシア）などの国コードにはIPアドレスが紐づいており、それらの物理的な場所が第三国になっていた場合もあったりしますし、プロキシ経由にてアクセスされてしまえばアクセスは可能になってしまいますので、ある一定レベルのものを制御するという認識の下で行った方が良いかもしれません。