wordpressのログインアタック (ブルートフォース攻撃) の阻止

普通の対策では認証をさせないだけなのでアクセスは減らず,サーバーのパフォーマンス低下は避けられない。
以下はwp-login.phpへのアクセス自体を阻止する対策。

WordPressの自動更新にも対応

.htaccess に追加

# END WordPress の下に

 redirect 301 /wp-login.php /new-login.php  

nginxなら default.conf に

 rewrite ^/wp-login.php /new-login.php permanent; 

wp-login.php を new-login.php に別名コピー

ファイルを開いてwp-login.php → new-login.phpに全置換

new-login.phpの<?php 以下に追加

session_start();
  if(!isset($_SESSION['任意文字'])){ 
     echo '<h1>404 Not Found<hr></h1>';
   exit;
}

if($_SESSION['任意文字']!="てきとうなひらがな"){
    echo '<h1>404 Not Found<hr></h1>';
    exit;
}

[logon.php] ← セッションを作るためのダミーのログインファイル

 <?php
  session_start(); //セッション開始

  $_SESSION["任意文字"]="てきとうなひらがな";
 ?>

  <a href="new-login.php"> 秘密のログインへ </a>

普通に/wp-admin/ や /wp-login.php でログインしようとすると 404 Not Found になる。
ダミーで作った /login.php からならログインできる。

Graph returned an error: Can’t Load URL: The domain of this URL isn’t included in the app’s domains.

Facebook のOAUTH認証がまた変わるらしい

3月には、以下の[有効なOAuthリダイレクトURI]フィールドに記載されていないURIからの呼び出しを無効化するセキュリティアップデートがアプリ設定に適用されます。
このアップデートはプラットフォームで見つかった悪意あるアクティビティに対応するためのものです。リダイレクトURIに新しい制限モードを追加することで、アプリやウェブサイトを保護できます。
詳しくはこちら


「リダイレクトURIに制限モード」をはいにする

警告は消える

ログインすると Graph returned an error: Can’t Load URL: The domain of this URL isn’t included in the app’s domains.・・・・・

OAuthリダイレクトURIをgetAccessToken関数呼び出しの引数として追加して解決

   //アクセストークンを取得する
        $accessToken = $helper->getAccessToken("https://www.examplex.com/callback");

botによるDOS攻撃、特定ファイルへの連続アクセスをipブロックにて遮断

access.log により moodle/calendar/set.php への不正規アクセスを確認 ユーザーエージェントは “MJ12bot”

ipsetを利用することで、IPアドレスの集合を簡単に管理することができる。
iptables を実行しなくて済むので早速入れた。

# yum install ipset 

セットの作成

接続拒否IPの集合”BLACKLIST”を作成

# ipset create BLACKLIST hash:net

プログラムフロー

moodle/calendar/set.php 先頭へ追記


    $uaip = $_SERVER['REMOTE_ADDR'];//ipを取得
	$ua = $_SERVER['HTTP_USER_AGENT'];// ユーザエージェントを取得
	if(	strpos($ua, 'MJ12bot') !== false ){
		http_response_code( 301 ) ;
		header( "Location: ../../abcdef/iptables.php?uaip=$uaip" ) ;
		exit;
	}

../../abcdef/iptables.php 新規作成 (場所はどこでもいい)


<?php 
	$file='/var/www/deny_ip';
	$getparam=htmlspecialchars($_GET['uaip']);

	file_put_contents($file,$getparam,FILE_APPEND | LOCK_EX);
?>

/var/www/deny_ip には MJ12botがアクセスしてきたipアドレスが書き込まれていく

/root/iptables.sh シェルスクリプト作成


	#!/bin/bash

# 拒否IPリストに記載されたIPからのアクセスを拒否する
if [ -s /var/www/deny_ip ]; then
    for ip in `cat /var/www/deny_ip`
    do
        ipset add BLACKLIST $ip
    done
fi
: > /var/www/deny_ip

cron で5分おきに実行 vi /etc/crontab


	 */5  *  *  *  * root sh /root/iptables.sh

cron log確認 tail -f /var/log/cron

ipset list BLACKLIST


	Name: BLACKLIST
	Type: hash:net
	Header: family inet hashsize 1024 maxelem 65536 
	Size in memory: 17008
	References: 1
	Members:
	158.69.254.103    ←これが拒否IP

VPS(centOS6)のfirewall

  1. セキュリティグループ
    主に管理パネルなどで許可する(許可していなくてもポートスキャンはLISTENになるので注意)
  2. SELinux
    扱いが厄介なので普通のコンテンツ提供だけならOFFでいいと思う。
  3. TCP Wrapper
    特定のIPからのアクセスを許可(# vi /etc/hosts.allow)、不許可する(vi /etc/hosts.deny)
  4. iptables
    ホストレベルのFirewall(#  iptables –list)

たいてい80番以外は塞がれている

国外リスト
国外アクセス拒否リスト

ランサムウェア予防と対策

予防は一般的なマルウェア感染と同じ

  1. メールの添付ファイルは開かない → 送り主に電話で確認
  2. メールに書いてあるURLは開かない → 開きたかったらJavascriptは無効にしておく
  3. ブラウザアップデート、ウィルス定義更新は起動時に確認しておく

対策

ファイルのバックアップ
ソフト的に自動バックアップ、差分バックアップを毎日
※ここで注意すべきはバックアップ媒体を接続しっぱなしにしないこと。
RAIDなどでハード的なリアルタイムバックアップは意味が無い

被害にあった場合の対処

Ransomware_file_lock_type[1]

  1. とりあえず複合できないか自分で試す。
  2. 腕に覚えがある人に見積もりしてもらう。
  3. IPAに相談

情報セキュリティ 27年秋午後1 解説

27年秋  問1

設問1

可用性: 販売チャネルの大部分を担い、常時稼働が必要なため

完全性: 投資家に正確な財務情報、会社情報を提供するため

(2つ別別のものを書かせたい意図がある)

 

設問3   

  b.  ANY   c. 遮断 (3つとも同じはないと思って時間をかけたが、全部遮断だった)
 d.cookie e. 遮断
  f. Multipart g. 遮断

(4) WAFと同じ権限でHTTPが動作することの問題
    必要最小限権限で動作させる (権限とくれば必要最小限)

 

(5) WAFのルールが正確に動作することを検証し改善できる・

正解 → 販売機会損失などのビジネスチャンスを逃さずに誤検知の検証ができる

※ フォールスポジティブ or フォールスネガティブ とくれば 誤検知検証

 

27年秋  問2

設問1

 ☓Kシステムの管理者 → ◎Y社管理者 (問題文中にどこにも出てこない。出ている管理者から選べ!)

 

設問2 作業対象のサーバーにだけアクセスできるように

☓FW1 → 「S社PC」 から 「管理サーバー」へのみ  (実際に設定するのはFW1のIPになるはずだが)

設問3

2案ではS社PCにシステムをインストールする必要が無いため

正解例 → 委託先PCへインストールするプログラムの資産管理をする必要がないため。

要はS社の資産だから管理が及びにくいということだろう

 

 

27年秋  問3

設問3

(1) 3,4 だけ ,5, 6はローカルからの許可なので攻撃ではない

(2)②ポリシを満たしてないことが判明
   正解は5 (すべてのサービスを許可している必要はない)

   また、サービスを満たすように2つ

   1 ファイル共有
   2 リモートデスクトップ

 

設問4 どのような攻撃を防ぐか?

(a) サーブレットコンテナの管理画面に対するインターネットからの不正アクセス

 

(b)自動的にログインを行う OS の仕様を利用した,他のサーバへの侵入

(確かに問題文に書いてあるが、認証にはベーシック認証と書いているのでつじつまがあわない、と思って調べてみたら、ActiveDirectoryと連携するIISの認証機能でシングルサインオンでいけるらしい)

 

xmlrpc.php へのアタック対策 Apache & nginx

xmlrpc.php はwordpressのファイルで、管理画面以外から投稿を受け入れる機能があるファイル。
このファイルを狙ったアタックを検知した。
xmlrpc

このファイルへのアクセスはデフォルトでこんな感じ
urlbarxmlaccess

 

プラグインで防ぐ方法もあるようだが、htaccessでできる

  <Files "xmlrpc.php">
  order deny,allow
  deny from all
  </Files>

対策後のログ

  46.235.9.240.static.teknikdata.com - - [09/Mar/2016:19:16:41 +0900] "POST /xmlrpc.php HTTP/1.1" 200 441 "-" "Mozilla/5.0 
46.235.9.240.static.teknikdata.com - - [09/Mar/2016:19:21:11 +0900] "POST /xmlrpc.php HTTP/1.1" 404 18208 "-" "Mozilla/5.0 

HTTPレスポンスが200から404に変わった。
見てみると
xml404
アタックも止まった。うまく行ったようだ。

 

以下は nginxの場合 

confファイルに追加して再起動]


#access denyed
location = /xmlrpc.php {
deny all;
access_log off;
error_log off;
}
#複数ファイルならこう
location ~ (/xmlrpc.php|/moodle/calendar/set.php|/moodle/calendar/view.php)$ {

wordpressのログインアタック (ブルートフォース攻撃)

GoogleAnalyticsの最近のアクセス状況。
GoogleAnalytics

不自然なアクセス数の増減からログを調べたところこんなかんじだった。


logatt1

こいつのWhois情報
logatt2

とりあえずhtaccessであちこちブロック deny from 排除したいIPアドレス
logatt3

投稿の作者名がIDと同じなのはマズイ。名には日本語を入れるといい.
そして、ブログ上の表示名を日本語の表記にする。

プラグインも入れておけ Limit Login Attempts

それでも効果ないならこれをwp-login.php先頭のほうに追加。”てきとうなひらがな”をセッション変数に格納するphpファイルを作って、wp-login.phpにリンクを貼っておく。これで効果覿面

session_start();
if(!isset($_SESSION['任意文字'])){
    echo '<h1>404 Not Found<hr></h1>';
    exit;
}
if($_SESSION['任意文字']!="てきとうなひらがな"){
    echo '<h1>404 Not Found<hr></h1>';
    exit;
}


もっと設置が楽な方法として、wp-adminディレクトリにBsic認証を設置する方法がある