2015-03-30 5 views
1

Попытка перейти от старого разрешить, запретить, заказать синтаксис для нового, чтобы защитить раздел администрирования WordPress, но я не могу распознать его IP.Apache 2.4 Требовать, чтобы ip не работал

Это мой файл .htaccess содержится в папке /wp-admin.

ErrorDocument 401 default 
ErrorDocument 403 default 

# Disallow access for everyone except these IPs 
<RequireAny> 
    Require ip 50.153.218.4 
</RequireAny> 

# Allow plugin access to admin-ajax.php around password protection 
<Files admin-ajax.php> 
    <RequireAll> 
     Require all granted 
    </RequireAll> 
</Files> 

И это то, что я имею в .htaccess в корне под WordPress мод Информация переписывания.

# Protect WordPress 
ErrorDocument 401 default 
ErrorDocument 403 default 

<Files wp-login.php> 
    <RequireAny> 
     Require ip 50.153.218.4 
    </RequireAny> 
</Files> 

Но я просто продолжаю получать запрещенную ошибку 403. Когда я добавляю Require All Granted под IP, он отлично работает, но открывает его каждому пользователю. Кажется, что apache просто не читает мой ip правильно? Кто-нибудь знает, что я делаю неправильно?

+2

_ «Кажется, что apache просто не читает мой ip правильно?» _ - ну, вы что-то отметили, какой IP-адрес используется для ваших запросов? Может быть, соединение осуществляется через IPv6 вместо IPv4 или что-то еще? – CBroe

+0

@CBroe Я проверил свой IP-адрес в PHP и журналах Apache, и кажется правильным, так что часть не кажется проблемой. – zen

+0

так, он работает со старым синтаксисом «deny from all, allow ...»? –

ответ

3

Ваш синтаксис выглядит отлично для меня.

Единственная причина, по которой я могу думать, что apache может не правильно считывать IP-адрес пользователя, если вы находитесь за прокси-сервером или балансировщиком нагрузки. Если это так, вы должны использовать X-Forwarded-For вместо ip. В PHP вы можете подтвердить, находитесь ли вы за прокси-сервером, сравнивая $_SERVER['REMOTE_ADDR'] и $_SERVER['HTTP_X_FORWARDED_FOR'].

Если это не проблема, возможно, вам повезло найти ответ на ServerFault.

Я могу предложить вам некоторые обходные пути. Самым простым решением может быть использование одного из нескольких WordPress security plugins, которые позволяют ограничить доступ к серверу по IP-адресу.

Кроме того, в вашей теме или в виде плагина вы можете реализовать этот же тип логики аутентификации:

add_action('init', function() { 
    $allowed_ips = array('50.153.218.4'); 
    if(is_admin() || $GLOBALS['pagenow'] == 'wp-login.php') { 
     if(!DOING_AJAX && !in_array($_SERVER['REMOTE_ADDR'], $allowed_ips)) { 
      wp_die('', 'Forbidden' array(
       'response' => 403 
      )); 
     } 
    } 
}); 

Update: Из комментариев она выглядит как есть прокси участие. Это должны работы:

ErrorDocument 401 default 
ErrorDocument 403 default 

SetEnvIF X-Forwarded-For "50.153.218.4" AllowIP 

# Disallow access for everyone except these IPs 
<RequireAny> 
    Require env AllowIP 
</RequireAny> 

# Allow plugin access to admin-ajax.php around password protection 
<Files admin-ajax.php> 
    <RequireAll> 
     Require all granted 
    </RequireAll> 
</Files> 

и

# Protect WordPress 
ErrorDocument 401 default 
ErrorDocument 403 default 

SetEnvIF X-Forwarded-For "50.153.218.4" AllowIP 

<Files wp-login.php> 
    <RequireAny> 
     Require env AllowIP 
    </RequireAny> 
</Files> 

Вы также должны быть в состоянии использовать подобный метод с использованием "Allow, Deny" синтаксис.

+0

Я использую Cloudflare для CDN и обратного прокси-сервера nginx для повышения скорости, поэтому один из них должен его вызывать. Хотя у меня были оба до того, как я обновился до нового apache и, похоже, работал тогда. Я действительно подтвердил, что 'REMOTE_ADDR' и 'HTTP_X_FORWARDED_FOR' не совпадают. Знаете ли вы, что это не так? Я бы предпочел сделать это через apache, чем PHP, поскольку он, вероятно, будет более безопасным и быстрым.Я пробовал несколько плагинов безопасности WordPress, но все они в конечном итоге терпят неудачу или все еще добавляют слишком большую нагрузку на сервер в случае грубых атак. – zen

+0

@zen Это должен быть обратный прокси. Обратный прокси находится между веб-сервером и пользователем. Все ваши запросы на самом деле поступают из прокси-сервера, поэтому IP-адрес, который вы видите, является прокси-сервером. CDN не вызовет такого рода проблемы. Странно, что до обновления это не было проблемой. Это может иметь какое-то отношение к настройке apache для учета обратного прокси. Если вам интересно, я бы спросил у ServerFault. –

+0

Благодарим за редактирование. Я буду отмечать этот правильный ответ, так как это хорошее решение на данный момент. – zen