昨今、インターネットサービスを展開する上でセキュリティ対策が危急の課題となっております。
セキュリティ対策は様々な手法がありますが、いずれもコストがかかる割に世界中から四六時中不正アクセスされる不安はぬぐえません。また狡猾な手口も次々に生み出されています。

多くのハッキング行為が海外からもたらされているという事実がある中、弊社では「そのホームページは全世界に展開する必要があるんでしょうか？」という着目から、思い切ってアクセス元ネットワークを日本国に限定しサービスの防衛力を高めるソリューションを提供します。

相対的にIT治安の良い日本国にアクセスを限定することによって、リスクが低減され万が一違法行為が行われた場合でも国内法が適用されるので、原因特定に有効となります。

お問い合わせ先はこちらになります。

株式会社進角
代表取締役 藤本 信
http://www.shinkaku.co.jp/
03-3780-2952
info@shinkaku.jp

最近特定国家からの不正アクセスが増えているようです。
このような技術が必要になること自体あまり望むべきことではないのですが、万が一自社サービスが著しく毀損されるようなサイバー攻撃が発生した場合に備えて、防衛手段をシミュレーションしておいても損は無いでしょう。

この例は専用サーバやVPSなどで一般的に用いられているiptablesというファイアウォールを用いた国別フィルタリング方法です。

1. IPアドレスリストを入手する
   $ wget http://ftp.apnic.net/stats/apnic/delegated-apnic-latest
   
   
2. IPアドレスリストから特定の国を抽出
   $ grep "apnic|XX|ipv4" < delegated-apnic-latest > list_country
   ※ XXが2ケタの国識別コード
   
   
3. ネットワークアドレスを抽出して成型
   $ cat list_country | awk 'BEGIN { FS = "|"; OFMT = "%d"; for (i = 0; i < 32; i++) { pow[32 - i] = 2 ^ i } } { for (j in pow) { if ($5 == pow[j]) print $4 "/" j } }' > list_nwaddr
   
   
4. 管理者権限になる
   $ su
   #
   
   
5. いざ実行
   # while read line;
   do /sbin/iptables -I INPUT -s $line -j DROP;
   done < list_nwaddr
   

 この手順はシームレスにアクセス拒否設定まで行ったものですが、実際の適用には十分な検証とリカバリー策を講じる必要があります。

サーバやネットワーク機器を新設したり交換した際、設定に問題が無いのに通信できない事がありますが、この様なトラブル原因のひとつとして"ARPキャッシュ"が考えられます。

いわゆるインターネット（TCP/IP）における通信設定ではIPアドレスやネットワークアドレスが重要ですが、実際ハードに近いレベルでの通信には"MACアドレス"で機器の識別が行われています。MACアドレスはルータやNICやWiFiなどのネットワークデバイスが持っている一意なIDです。

PCやサーバおよびL2以上の"インテリジェント"と呼ばれているネットワーク機器は通信の高速化（オーバーヘッド削減）の為にこのMACアドレスとIPアドレスの対応データを一定時間キャッシュする機能があります。このキャッシュデータが古い状態で残っているとIPアドレスが同様でも異なる機器を接続した場合に"一定時間"通信が出来なくなる事象が起きます。

したがって場合によってはこのARPキャッシュを強制的にフラッシュする必要があります。

ちなみにWindowsやLinuxでARPキャッシュを確認する方法は以下のコマンドになります。
arp　-a

これを強制的にフラッシュする場合は以下のコマンドでIPアドレスに対応したMACアドレスを消去できます。
arp -d XXX.XXX.XXX.XXX
例えば上位のルータを交換した場合などにPC側でこのような操作が必要になります。

ネットワーク機器側においても同様のキャッシュ管理機能があるのでGUIあるいはCLIでキャッシュをフラッシュする操作が可能になっています。なおデータセンターでサーバやネットワーク機器を運用している場合は上位機器を管理しているオペレータに依頼が必要な場合もあります。

ARPキャッシュ問題は概ね"一刻を争う状況"で発生しがちなのでチェックポイントとして知っていた方が良いと思います。

フレッツ光をベースとしたインターネット回線をiDCなどで使用する場合、企業向けで高品質な"ビジネス"では実質100Mbpsが上限だったのですが、ここ数年の間にギガ帯域が使用できる"光ネクストビジネス"をベースとしたサービスが出てきたようなので調査してみました。

フレッツの競合にあたるUSEN参考
http://www.gate02.ne.jp/networkservice/ba

IP16までなら抜群に安い

すこしタイトルが大げさかな。

要するにWebサービスを実際に行うサーバとDNSサーバを共通にしている構成は、起こりうる障害に対する危機感に欠けていると思います。

説明しますと、例えばWebサーバに障害が発生し修復のめどが立たない場合、急きょ代替のサーバを立てることがあります。

その際に障害を起こしたサーバ自身がDNSも兼ねていると、ゾーン情報が容易には書き換えできない状態なので、代替サーバへIPアドレスを容易に切り替えることができません。そこでドメイン管理会社のWhois情報を書き換えて一旦新しいDNSを再構成するというロスが生じます。

このロスは、数分から数時間に設定されているDNSのTTL（有効時間）とは異なり、数日を要する場合があって深刻なサービスの毀損となる可能性があります。

したがって危機意識と経験値のあるエンジニアは極力WebサーバとDNSを兼ねるような構成は執ることはありません。