インターネットプロバイダ 下り200Mbpsプラン まとめ

55000円キャッシュバックのためだけに、OCNに入ったが、

違約金9000円を払ってでも、他社に乗り換えた方がお得であることが判明したため、

乗換を検討した時の調査結果をメモしておく。

 

うちのマンションは、回線が下り最大200Mbpsのものであるため、

ISPも下り200Mbpsプランがある会社の中から探した。

もちろんベストエフォートのため、OCNでは100Mすら出たことはない。。

夜間23時~25時には、1Mを切ることもしばしば。。

次のプロバイダでも期待はしないでおこう。

 

まず、200Mbpsプランがある会社は以下のサイトで表示されるのは、7社のみ。

光回線 | プロバイダー光ファイバー,東日本エリア,200Mbps,マンションタイプ,初年度実質月額料金,順比較 | RBB TODAY

ま、そんなものだろうと、この7社から探すこととした。

 

①月額費用(税抜)、②乗換特典、③最低利用期間

  • GMO  ①530円、②6か月無料、③なし
  • hi-ho    ①890円、②35か月間は月額450円、③2年
  • BIGLOBE ①900円、②不明、③2年
  • 楽天    ①950円、 ②14か月無料、③3年
  • Sonet  ①900円、②1万ポイント、③不明
  • ぷらら   ①800円、②3か月無料、③不明

 

結果、GMOにした。

理由は、月額費用が安いのと、最低利用期間がないというのに魅かれた。

特に最低利用期間を設けないのはとても良心的だと思う。

3年にしている楽天や、一見して最低利用期間がわからないページの作りになっている会社は論外。

 

 

参考ページ

 

 

 

MySQL InnoDB データ圧縮機能 COMPRESSED

MySQL InnoDB データ圧縮機能 COMPRESSEDについて

詳しいサイトまとめ

 

実践ハイパフォーマンスMySQL 第3版

実践ハイパフォーマンスMySQL 第3版

 

 

DNSキャッシュポイズニング攻撃 確認 対策 まとめ

JPRSから緊急の注意喚起がされて、少し焦ったのでメモ。

  (緊急)キャッシュポイズニング攻撃の危険性増加に伴うDNSサーバーの設定再確認について(2014年4月15日公開)

 

→最近、カミンスキー型攻撃手法のDNSキャッシュポイズニング攻撃が日本で増えているため、注意されたし。とのこと。

 

ミンスキー型攻撃とはなんぞ??

→2008年7月にカミンスキーさんが明らかにしたポイズニングの手法。

 それまでのキャッシュポイズニングと異なり、

 ①攻撃目標となる名前に対し連続・繰り返し攻撃が可能で、

 ②一部実装では既存のキャッシュが上書きされるため、

   目標に対し、効率的に攻撃できてしまうらしい。

 参照:http://jprs.jp/related-info/guide/009.pdf

 

対策は?

ソースポートランダマイゼーション

DNSで使用するUDPポート番号をランダム化すること。

 

確認方法は?

①確認サイトを使う。

 ・Web-based DNS Randomness Test | DNS-OARC

  「Test My DNS」ボタンを押し、すべて「GREAT」ならOKとのこと。

   ※ただし、記事作成時点で、実行したが、応答なし。。

 

②BINDのnamed.confの設定値を見る。

 

 具体的には、named.confにおいて下記の設定例のように、

    1)query-source/query-source-v6が設定されている行が存在する
    2)かつ、portによりポート番号が明示的に指定されている

  場合、該当する行を削除し、namedを再起動する必要があります。

  (不適切な設定例)
    query-source address * port 53;
    query-source-v6 address * port 53;

その他、NW機器についても掲載されていたが、

詳細はベンダーまでとのことだった。。

2. ネットワーク機器における不適切なポートの再変換

  ファイアーウォールやルーターなど、ネットワーク機器におけるネットワー  クアドレス変換(NAT)機能の不適切な実装により、キャッシュDNSサーバー で実施したソースポートランダマイゼーションが無効にされてしまう場合が あることが判明しています。

 

  この場合、該当するネットワーク機器の設定変更やファームウェアの更新、 リプレースなどの対応が必要になります。

各機器における具体的な対応方法 については、各ネットワーク機器のベンダーにお問い合わせください。

 

 

 

MySQL 5.6 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.XXXXXX' at position XXXXXXXXX

VM上のスレーブをコピーして、スレーブ2を作成。

スレーブ2のホスト名およびIPアドレス、my.cnfのserver-idを変更後、

mysqlを起動したら、

以下のエラーが止まらない事象が発生して小一時間はまったので、対処方法をメモ。

 

[Note] Slave: received end packet from server, apparent master shutdown:
[Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.XXXXXX' at position XXXXXXXXX
[Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.

対処:スレーブ2 data_dir内のauto.cnfを削除。

   →auto.cnf内のserver-uuidが重複していたらしい。。

 

 

実践ハイパフォーマンスMySQL 第3版

実践ハイパフォーマンスMySQL 第3版

 

 

CentOS SSHログインを公開鍵認証で行うための手順

VPSサーバ(CentOS 6.4)へのSSHログインを

パスワード認証ではなく、公開鍵認証で行えるようにした。

その手順をメモ。

 

■公開鍵・秘密鍵のキーペアを作成

VPSサーバに今までどおりパスワード認証でログイン

② 以下のとおり、ssh-keygenコマンド実行。

 

[testuser@vps tmp]$ ssh-keygen -t rsa

Generating public/private rsa key pair.

Enter file in which to save the key (/home/testuser/.ssh/id_rsa): (Enterキー押下)

Created directory '/home/testuser/.ssh'.

Enter passphrase (empty for no passphrase): (任意のパスフレーズ入力)

Enter same passphrase again:(任意のパスフレーズ入力)

Your identification has been saved in /home/testuser/.ssh/id_rsa.

Your public key has been saved in /home/testuser/.ssh/id_rsa.pub.

 

→~/.ssh配下に「id_rsa(秘密鍵)」と「id_rsa.pub(公開鍵)」が作成される。

③ mv ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys

 

秘密鍵SSHクライアントPCへ配置

①サーバで作成された「id_rsa(秘密鍵)」を

 SSHクライアント上の~/.ssh配下に配置。

②(任意) 秘密鍵パスフレーズを解除。

 openssl rsa -in id_rsa -out id_rsa

 

 

パスワード認証を無効にし、公開鍵認証のみ有効とすることも可能なようだが、

会社PCからもVPSへアクセスする場合もあるため、

パスワード認証は無効にしていない。

 

 

以下のサイトを参考にさせていただきました。

http://www.websec-room.com/2014/01/18/1647