メインコンテンツに移動

リファラースパムなのか

事象

drupalのレポートをみていてふと気が付きました。

なんでcronが頻繁に実行されているのだろう?

詳細を見ると以下の通りです。
※発見時のものとは異なります。
詳細レポート

ホスト名はサーバのIPアドレスではありません。
ユーザーは匿名ユーザ(未認証ユーザ)です。

発見時の詳細レポートは1000件を超えたためDrupalからは消えてしまいました。
しかし、ウェブサーバのログにはしっかり残っています。

発見時の詳細ログにはリファラーにかなりの量のコードが書かれていました。
しかも、そのコードの中に気になるキーワードがありました。
それは「jsredir」です。
過去に世間を賑わせたマルウェア「JS/REDIR」と同じです。
そしてロシアのサイトyandex.ruから・・・
それが以下になります。(jsredirにヒットしたもののみ)
リファラー

全部で5件ヒットしました。そのうち2件がレスポンスコード200を返しています。
詳細レポートでみたのはこの2件のうちのどちらかでしょう。

これはリファラースパムなのか
それとも設定の脆弱性をついてcronを使いマルウェアを仕込まれてしまったのでしょうか
そうなるとユーザ情報が盗まれたりWeb改ざんされたりして、いろいろ悪用されてしまいます。

バックドアを作られてしまうと悪用する人たちの間でそのサーバの情報が共有され、彼らの用途で自由にサーバリソースを利用されてしまいます。
その影響を考えると無限です。

今回の事象は以下2点です。

  1. cronが外部から実行できているようにみえること
  2. リファラーにコードが埋め込まれていること

暫定的な対処

ウィルスチェック

clamavのセットアップはつい最近できたところでした。
スキャン中、リモートセッションが切断してしまうのとスキャンに時間がかかりすぎるのと、検出率がないよりまし程度なので、Sophosの無料版をインストールしました。

drupalルートを8月のウィルス定義データベースでスキャンした結果は、ウィルスは発見されませんでした。

アクセス制限

GeoIP(Lite)によるアクセス制限を追加しましたが、情報のないIPアドレスに対しては完全ではありません。

Fail2banを導入していますが、まだ動作テストが完了していません。

原因

原因はよくわかっていませんので推測しかできません。
疑わしいものからつぶしていくしかありません。

jQuery mmenu

ただ、200を返しているページはどちらもjQuery mmenuのページです。
mmenu自体になにかセキュリティーホールでもあるのでしょうか。
mmenuのキーワードにヒットしたサイトに攻撃をしかけているとも考えられます。

jQuery mmenuの記事にも書きましたが、jQueryのバージョンやmmenuのバージョンが古いものでないと動作しない寄贈モジュールがあります。
この場合、クロスサイトスクリプティング等の脆弱性のあるjQueryバージョンを使用している可能性があります。
攻撃者はそれを狙っているとも考えられます。

 

nginxの設定

当初、apacheで稼働させていましたが、その後、nginxをプロキシーにし、現在はnginxのみで稼働しています。
drupal用の設定は複雑で、authorize.php  cron.php  index.php  info.php  install.php  update.php  xmlrpc.phpのPHPがそれぞれうまく稼働できるようにしなければなりません。
※install.phpはインストール時に使用するものなので初回インストール時のみ

またClean URLが使えるようにもしないといけません。
しかし、実際には管理メニューからcron.phpのURLを指定して実行は動作しませんでしたし、update.phpもうまく動作していませんでした。

さらには、キャッシュ設定です。
ページへのアクセス速度を速くしたいわけですが、主に管理者ユーザ用ページと匿名ユーザ用ページがあります。
管理者ユーザ用ページはキャッシュしたくなかったのですが、どうもうまくいっていませんでした。

現在のdrupal用設定は未完成の状態でした。

WAF

nginxのWAFとして、naxsiを導入していますが、標準ルールのままでサイトにあったルールの作成などをしていませんし、ルールによりアクセスの制限もしていません。
そのため、WAFはない状態と同じです。

IDSとIPS

一時期はsnortを導入していましたが、これもWAF同様、定義ルールが重要になり、意図するルールを作成しなければなりません。
そのため、snortは稼働していてもルールは適用されていない状態でしたので検知はできません。
ファイル改ざん検知ができるようにしたいとも思っていました。

ウィルス対策ソフト

CentOS7にしてCentOS6のころとはいろいろ変更点があり、パッケージの構成が変わっているものがあります。
大きな変更点はsystemd対応になっている点です。
そのため、従来のパッケージ名にsystemdがふよされているものもインストールしないといけません。

Clamavをセットアップしましたが、うまくいきませんでした。
そのため、ウィルス対策ソフトは何も入れていない状態でした。

こういった、潜在的にあった不安が、今回の件で、より強い不安になっています。

判例には、乗っ取られたサーバによる被害の責任がサーバ管理者にあるとされたケースもあります。
悪用できるサーバの情報はアンダーグラウンドのサイトで共有されたりもしています。

放置していくとどんどん被害は広がります。
決して、他人事ではありません。

こういうのは実害が判明したときには遅いのですが、実害が把握できていないのも悩みの種です。

対策

nginxの設定変更

cron.phpやupdate.phpの対応を追記してみましたが、うまく動作しません。
キャッシュの制御も含め、さっぱりな部分もあるため、apacheに戻し、nginxをプロキシーとして使用するだけにしようか検討中です。

ログの保管

原因究明には正しい情報が必要です。
そのためにもログデータは確実に残しておくべきです。
今回、drupalの詳細レポートが件数により上書きされてしまったため、以下の対策をしました。

  1. syslogへ出力
  2. Noticeの出力抑止

drupalの管理画面から保管するログの件数は設定できますが、限りがあります。
ログがローテートされて消えないようsyslog(/var/log/secure)に出力するようにしました。

また、phpコードからNoticeメッセージが大量に出力されるため、ログ件数がすぐに上限に達してしまいます。
Noticeメッセージは開発環境やテスト環境では有益な情報を得ることもあるでしょうが、本番環境という点とあまりにも多すぎるために抑止しました。
php.iniのerror_reportsの設定を変更すればよいだけですが、PHPバージョンによって異なります。
.user.iniでは設定が変更されなかったのでsettings.phpに記述しました。

ファイル改ざん検知

Webサイト改ざんに備えてファイル改ざん検知ができるようにと考えていますが、現状、改ざんされていないという確証がなければ、この状態で導入してもあまり意味がありません。

リファラースパムであってほしいという思いがありますが、もしそうじゃなかったらどうしようという無限に想定できる危害にたいする責任のための不安との葛藤です。
リセットボタンをポチで瞬時にやり直せれば楽でいいのですが・・・

おわりに

こういうことは一人で悩むまえにまずしかるべきところに情報提供すべきだと思います。
何事も早期発見、早期対応が重要です。

以下の参考資料は一度目を通しておくことをお勧めします。

参考資料:IPAテクニカルウォッチ「ウェブサイト改ざんの脅威と対策」

Drupalバージョン