ドラクエ10・FF14 の通信障害は国内ECサイトを狙ったDDoS攻撃?

ドラクエ10・FF14 の通信障害は国内ECサイトを狙ったDDoS攻撃?

5日にお客様からECサイトで尋常じゃない数カード決済の失敗が起きてるとのことでご連絡頂く。

確認してみると秒間3.4件、10分程インターバル置いて同じIPで連続数十件、IPを変えながらトータルで数百件以上決済ページにアクセスしている履歴が残っており、決済ページのエラー条件の設定を厳しく設定したり該当IPを弾く設定などして様子を見てますがその後攻撃は止んでいる模様。

ちょうどその期間NTTやKDDIなど上位ISPで大規模な接続障害でドラクエ10やFF14などのオンラインゲームなどがアクセスしずらい状態にあったのですが、今回攻撃してきたIPはどれも国内のもので、確証はないですが今回のお客さんのケースの様に国内のPCやサーバーを踏み台にして攻撃して国内のECサイトなんかを攻撃してるのではないかと推測します。

カード決済が通れば届いた商品を売リ裁く方法もあるかと思いますがそれだと受け取り先の住所で足が付くため、もしハッカーが払い戻し先の銀行を抑えているのであれば注文をキャンセルし払い戻しを受けて現金化を狙っている可能性もあるためECサイトを運用されている場合は念のためログを確認することをお勧めいたします。

#ドラクエ10 #FF14 #通信障害 #DDoS攻撃

jetpack

WordPress更新時に出る Allowed memory size エラーの解消法

WordPressへの更新時

Fatal error: Allowed memory size of  ~

のエラーが発生した場合、各サーバーで設定しているphpのメモリ上限(memory_limit )を超えてメモリを使おうとしている為にエラーが発生します。
場合によってはサイト全体がエラーとなり管理画面にも入れないようになってしまいます。

この症状解決方法は2つ

memory_limitを上げる

各サーバーによってPHPの設定を変更するにはphp.iniや.htaccessまたwp-config.phpなどを編集することによってmemory_limitの設定を行うことができます。

Fatal error: Allowed memory size of  許可されているメモリリミット bytes exhausted (tried to allocate 上限以上に使おうとしたメモリの量)

の様にエラーが出ますので上記の「上限以上に使おうとしたメモリの量」以上にmemory_limitを設定できれば解決します。

WordPressのブラグインを止めてみる。

ただmemory_limit既にサーバーの上限に達している場合は使用しているメモリを減らすしか方法がありません。
WordPressのプラグインにはプラグインごとの負荷を表示できるものがありますので、負荷が大きいもの(≒メモリ消費の大きいもの)を止めると改善できます。(Advanced Metricsタブを使用すればWordPressが使用しているメモリの使用量<Memory Usage>等も確認できます)

P3 - Plugin Performance Profiler の画面
プラグインの負荷が確認できる「P3」( Plugin Performance Profiler)プラグイン。 jetpackの負荷が高いことが確認できる

メジャーなプラグインではjetpackがダントツの負荷率なのでもしエラーで管理画面に入れない場合は試しにFTPで「/wp-content/plugins」の中の「jetpack」ディレクトリをリネームまたは削除するとエラーが解消されるかと思います。

今回はkagoyaの共用サーバ(memory_limit 80M )でWordpress 4.8–jaの更新時でこのエラーに遭遇。

Yahoo!ショッピングでFTPのアプロードが反映されない(2017年5月9日以降)

Yahoo!ショッピングでオプションサービスの「トリプル」を契約しFTPでページ更新を行っている場合、2017年5月9日からYahoo!ストア側のAOSSL(常時SSL)に関連して、htmlページやjsファイル内にAタグやimgタグなどにSSL通信ではない「http://」を含んだアドレスがある場合はストアエディタ上部にメッセージが表示され、リンクされているPDFファイルに記載されている箇所を修正する必要があります。

常時SSL(AOSSL)対応 修正対象一覧ダウンロード

もしこのメッセージが表示されている場合は該当するURLを含んだHTMLファイルなどをFTPでアップしても更新内容が反映されませんのでご注意ください。

出典 [AOSSL対応]トリプル入力制限実施のお知らせ

ECCUBE2.x(2.12.0~2.13.1)で「のし対応」プラグインが他のプラグインに干渉してしまうのラグインに干渉してしまう

ECCUBE2.x(2.12.0~2.13.1)で「のし対応」プラグインが他のプラグインに干渉してしまう

ECCUBE2での人気プラグインに「のし対応」プラグインhttp://www.ec-cube.net/products/detail.php?product_id=278)がありますが、商品購入の際のテンプレートを結構な感じで書き換えてしまうため他のプラグインが動かなくなったりします。
あとスマホ用のテンプレートもうまく動かなり、結局以下のような感じで対応しました。

  1. インストール済みの「のし対応プラグイン」のファイルをバックアップ:同プラグインを入れると以下のようにディレクトリ出来ます。
    dataフォルダ/downloads/plugin/GiftPaper

    ECCUBEの「data」フォルダ(※インストールのやり方でディレクトリ名やサーバー上のパスが変わります)以下にある「downloads」ディレクトリの中にプラグイン用のサブディレクトリが出来ており、今回は「のし対応プラグイン」の「GiftPaper」ディレクトリをFTPなどでローカルに落とします。

  2. GiftPaper.phpを書き換える:同プラグインの本体は「GiftPaper」ディレクトリ内の「GiftPaper.php」になります。
    こちらの414行あたりから

    function prefilterTransform(&$source, LC_Page_Ex $objPage, $filename) {
      $objTransform = new SC_Helper_Transform($source);
                                   以後省略

    の様にECCUBEデフォルトのテンプレートを書き換える処理が入ります。
    今回はスマホの表示がおかしい(のしの選択肢が出ない、選んでも確認画面に進めないなど)がありましたので、スマホのテンプレを書き換えている部分を修正しました。
    (ECCUBEでプラグインからデフォルトのテンプレを書き換える際には「SC_Helper_Transform(トランスフォーム)」)という機能を使って処理を行います。
    基本的にはJQueryで要素を書き換えたり追加する処理と同じです。詳細に関してはプラグイン作成のリファレンス(http://downloads.ec-cube.net/src/manual/12.0_plugin/plugin.pdf)の11ページあたりを参照してください。)
    以下のソースでは「//リプレイスでの対応」とあるようにテンプレートのある部分を「replaceElement」を使ってごっそり置き換える処理を行っています。(461行目)

     // 458行目辺り。お支払方法・お届け時間等の指定画面
     if(strpos($filename, "shopping/payment.tpl") !== false) {
     //リプレイスでの対応
     $objTransform->select('section#undercolumn')->replaceElement(file_get_contents($template_dir . 'shopping/plg_GiftPaper_payment_section_replace.tpl'));
     //$objTransform->select("section#undercolumn section.point_area", 0)->insertAfter(file_get_contents($template_dir . "shopping/plg_GiftPaper_payment_section.tpl"));
     }

    この「replaceElement」で置き換えているのが「GiftPaper」ディレクトリ内の「shopping/plg_GiftPaper_payment_section_replace.tpl」ファイルになりますが、他のプラグインが書き換えようとする際に必要な要素やセレクタ(idやclass)が含まれておらずテンプレートが書き換えられない為干渉が起こってしまう模様。
    なのでその下にコメントアウトしてある用意してある462行目

    $objTransform->select("section#undercolumn section.point_area", 0)->insertAfter(file_get_contents($template_dir . "shopping/plg_GiftPaper_payment_section.tpl"));

    のほうをコメントを取ってアクティブにします。(逆に461行目の部分はコメントアウトするか消します。)
    この部分ではデフォルトのテンプレートの「section#undercolumnのsection.point_area」の後に「GiftPaper」ディレクトリ内の「shopping/plg_GiftPaper_payment_section.tpl」を挿入するという処理ですので他のプラグインで干渉する心配がなくなります。

    うまく動かない場合はsection#undercolumn section.point_area のセレクタの部分が適切かどうか見直し、「GiftPaper」ディレクトリ内の「shopping/plg_GiftPaper_payment_section.tpl」も見直してもらうと大丈夫かと思います。

MODX Revolution (MODX 2.x) のアップデート手順

MODX Revolution (MODX 2.x) のアップデート手順は至ってシンプルです。

  1. バックアップ:phpmyadmin等を使ってDBのバックアップとFTPなどを使ってサーバ上のファイル類丸ごとバックアップします。
  2. 新しいバージョンのファイルで上書き:FTPなどを使って予めダウンロードしていた新しいバージョンのmodx 2.x のファイルを展開しFTPで上書きします。
    そののちブラウザでsetupページ

    http://ドメイン/setup

    にアクセスし、アップグレード作業を進めます。(この時すでにmodxがインストール済みの場合は自動的にアップデート関連のチェックが入って「次へ」のボタンを押すだけでアップデートが完了します。)
    その際注意が必要なのは2.2.x のバージョンから2.3.x、2.4.x、2.5.xなどそれ以上のバージョンにアップデートする際、2.2.0以降ででDBのフィールドが6つほど追加になっており、2.3.0、2.4.0、2.5.0のように各バージョンの最後が「.0」で終わるものでDBのフィールドが変更になっていることがほとんどの為

    2.2.x2.3.02.4.02.5.0

    のように段階的にバージョンアップする様にします。

  3. 念のため「キャッシュをクリア」のメニューでキャッシュをクリアし、各所動作確認を行います。
    この際Modx自体がフロントにAjaxを多用しているためブラウザ側のキャッシュもクリアしないとpackagemanager(パッケージマネージャー)が動かなくなったりします。

    もしキャッシュをクリアしてもうまく動かない場合は「エラーログ」メニューからエラーログを確認し、エラーがある場合は適時修正を行います。

以上バックアップ以外は基本的にFTPでファイルを上書きするだけなので問題が起こらなければ3~5分程度で完了する工程です。