皆さん、こんにちは。

業務改善を行う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・業務コンサルタント、高橋です。

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

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

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

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

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

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

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

これが今日の本題です。

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

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

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

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

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

皆さん、こんにちは。

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

またしてもApple（アップル）をかたるフィッシングメールが拡散していますので、今日はそれをご紹介します。

Appleをかたるフィッシングメール

まず、実際に送られてくるものはこのような内容です。

件名：あなたのApple IDのセキュリティ質問を再設定してください。

本文：安全のため、このApple IDはすでにロックされました。

あなたのApple IDはwindows PCのiCloudにログインしたりダウンロードしたりする操作があったとAppleゲームのセキュリティチームは発見しました。

日付と時間：2017/10/10

iCloudバージョン：6.2.2.35

IP：***.***.***.***（岐阜）

あなたのアカウントの安全性を守るために、セキュリティ質問を再設定して頂くことが必要です。再設定された後、たとえあなたのApple IDとパスワード及び元のセキュリティ情報を知っているとしても、それを使用することができません。

この問題を解決するにはこちら

IPの部分を***.***.***.***にしているのは、記載のIPアドレスを調べると、問題ないと思われる大手企業グループ系が所持しているIPアドレスでしたので、あえて記載していません。

また、最後の『こちら』の部分が偽のサイトへ誘導するためのリンクが貼られています（リンク先からさらにリダイレクトしている感じ）。

このメールの誘導先に行ってしまった場合、Apple IDなどのアカウント情報や個人情報が詐取される可能性があり、警視庁サイバー犯罪対策課も注意を促しています。

間違ってもリンクをクリックして誘導先に行かないよう、くれぐれもご注意ください。

皆さん、こんにちは。

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

JPCERTコーディネーションセンター（JPCERT/CC）は昨日、DDoS攻撃の停止と引き換えに金銭を要求する脅迫メールを受け取った企業などの報告が複数出ていることを公表しました。

これは数ヵ月前にも類似のものがあり、JPCERT/CCでは注意喚起を行っています。

DDoS攻撃のおさらい

DoS攻撃とは、サーバの負荷や通信量を増加させ、サーバのサービスを低下させることを目的とした攻撃のことを言い、DDoS攻撃とは、DoS攻撃をさらに悪質化させ、攻撃元を分散させたもののことを言います。

この攻撃元を分散したDDoS攻撃は最も防御が難しい攻撃と言われており、今までに多くのサーバが被害にあっています。

DDoS攻撃への対応策

こういったDDoS攻撃は攻撃元が分散していることもあり、対策が講じにくいものではあります。

しかし、何も行わないわけにはいかなくなりますから、次にことを行ってみると良いです。

１．DDoS攻撃が発生した際の対応を再確認しておく

２．管理しているサーバやルータなどが踏み台とならないよう、適切な設定を行う

３．海外からのアクセスを拒否してしまう

　　ただし、これは日本国内向けだけをサービス対象としている場合に限ります。

４．同一IPからのアクセス回数を制限する

　　場合によっては拒否する

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

また、以前お伝えした通り、DDoS攻撃はIoT機器全体が踏み台にされる可能性があります。

これらを踏まえ、予めIoT機器に対して適切な設定を行っておかなければいけません。

意識の欠如がさらなる被害を生む、つまり他へ迷惑をかけることにもなります。

皆さん、こんにちは。

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

冒頭にお書きしたことは実際にお客様にて起きたことで、お客様が契約されている共有型のレンタルサーバにおいて他のユーザーがウイルス感染の可能性のあるメールを配信したことによって、あるスパムデータベースに誤登録されてしまった事例です。

そこで今日は、自社のドメインや契約しているサーバのIPアドレスがスパムデータベースに誤登録されてしまった時の対処法をご紹介します。

前提として、Spamhaus（スパムハウス）プロジェクトやCBLにブラックリスト入りしてしまった場合を想定してみます。

Spamhausの誤登録解除法

１．下記のURLにアクセスし、ドメインやIPアドレスがブラックリスト入りしているか調査します。

https://www.spamhaus.org/lookup/

２．ドメイン、もしくはIPアドレスを入力して『Lookup』ボタンをクリックします。

（調査ですので問題のない時に行っても大丈夫です。）

３．ブラックリスト入りしていた場合、以下のような結果が出ます。

example.com（もしくはIPアドレス） is listed in the SBL/DBL/PBL/XBL

（ブラックリスト入りしていなければ、example.com（もしくはIPアドレス） is not listed in the SBL/DBL/PBL/XBL）

４．ドメイン名などが表示されますので、それをクリックして『Removal from』へ移動します。

５．必要事項を入力して解除申請を行います。

（IPアドレスでCBLのブラックリスト入りした場合などは、当該サイトへ移動した後、最下部に解除申請のリンクが表示されます。）

概ね以上のような流れで解除申請は可能です。

ただし、ご自身ではよくわからない場合などは契約会社に相談して対処してもらことをお勧めします。

注：ブラックリストの解除には数時間かかる場合があります。

追伸：現在、迷惑メールや不正アクセス対策として、各企業やプロバイダーなどが、監視機関のデータベースを元に排除判定を行うことがあります。

そのため、共有型のレンタルサーバなどが一部のユーザーの過失などによってスパムデータベースに登録されてしまうことがあります。

しかし、このセグメント分割に対して間違った認識をしている人もいます。

皆さん、こんにちは。

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

今日は、企業間の担当者同士にあった会話の中で耳を疑うような内容のものをご紹介します。

それはこんな内容です。

TCP/IP印刷に対する間違った認識

A氏：『新しく別のセグメントでネットワークを追加したのですが、そちらのセグメントにあるプリンタに印刷させてもらって良いでしょうか。』

B氏：『プリンタを使う分には構いませんが、TCP/IP印刷は同一セグメント内でしか印刷できないですよ。』

A氏：『いえ、別のセグメントに対しても印刷はできます。念のため社内でもテストをしてきましたので。』

B氏：『そんなことはあり得ませんよ。それは間違っていますね。』

A氏：『では、印刷の許可だけもらえれば結構です。』

こんな感じの会話なのですが、これはどちらが正解かというと、Aさんは正しくBさんは間違いです。

ちなみに、とあるプリンタを製造しているメーカーのサポートセンターのオペレーターもB氏と同じことを言っていたようなので驚きです。

別セグメントへのTCP/IP印刷

この会話が行われたところのネットワーク構成は下記のような構成です。

B氏構築のネットワークセグメント：192.168.1.0/24

同ルータLAN側IP：192.168.1.1（デフォルトゲートウェイ）

同セグメント内のプリンタIP：192.168.1.100

A氏構築のネットワークセグメント：192.168.2.0/24

同ルータWAN側IP：192.168.1.200、デフォルトゲートウェイとDNS IP：192.168.1.1

同ルータLAN側IP：192.168.11.1

同クライアント：DHCP自動取得

こんな感じのネットワーク構成になっているのですが、A氏が構築したネットワーククライアントからは下記のようにプリンタを設定します。

プリンタポートをStandard TCP/IPとし、プリンタのIPアドレスに192.168.1.100を設定します。

それ以外は、プロトコルでLPRを選択してLPRのキュー名を入れるか、Rawを選択してポート番号に9100などを設定するかです。

この設定で基本的には192.168.2.0のセグメントにあるクライアントから192.168.1.0のセグメントにあるプリンタ192.168.1.100に印刷を行うことができます。

もしこれで印刷できないとすれば、プリンタの置かれているセグメントにあるルータの設定としてプライバシーセパレート（ネットワーク分離）をしている可能性があります。

その場合はその機能をOFFにしないと印刷することができません。

ご参考までに。