Комментарии 10
Это будет во второй части, но полезнее было бы добавить как hint к первой:
Когда мы начинаем контролировать аргументы, то функционал админки может пострадать.
Для этого есть небольшое решение:
надо лишь объявить две (по количеству проверок) переменные:
Следом добавить проверку авторизации средствами nginx:
Модифицировать участок, в котором мы проверяем
И ниже добавить код:
Что это даст? В случае работы из той части сайта где требуется авторизация
Когда мы начинаем контролировать аргументы, то функционал админки может пострадать.
Для этого есть небольшое решение:
надо лишь объявить две (по количеству проверок) переменные:
set $wploggedin 0;
set $wppostpass 0;
Следом добавить проверку авторизации средствами nginx:
if ($remote_user ~* "^ВАШ_auth_basic_ЛОГИН_$") {
set $wploggedin 1;
}
Модифицировать участок, в котором мы проверяем
$args
как:if ($args ~* "(attachment_id|media_category|attachment_category|select|eval|duplicate|base64|substring|preg_replace|create_function)") {
set $wpwrongargs 1;
}
И ниже добавить код:
set $wpresult $wploggedin$wpwrongargs;
if ($wpresult = 01) {
return 403;
}
Что это даст? В случае работы из той части сайта где требуется авторизация
auth_basic
(например /wp-admin/
) и использовании запрещенных аргументов переменная $wpresult
примет значение 11
и ошибки 403 не будет. В случае работы из публичных разделов сайта и обнаружении аргумента из «черного списка» переменная примет значение 01
, location
ее обработает и выдаст ошибку 403
.+2
Если вы закрываете wp-admin базовой аутентификацией то у вас перестанет работать AJAX, т.к. весь AJAX (включая анонимный) в WordPress работает через файл wp-admin/admin-ajax.php, есть также некоторые вещи, которые работают через wp-admin/admin-post.php.
+3
Спасибо за ваш комментарий, но в базовой версии wordpress я не увидел ни одного ajax обращения в network вкладке моего браузера, которое бы имело код 401 или выдало бы мне окно авторизации.
Единственное, если мне память не изменяет, то когда я поставил плагин MLA (media library assistant) и попробовал его встроенные галереи через
В принципе, если кто-то хочет позволить AJAX работать, то можно сделать символические ссылки по аналогии с
Я согласен, что это неудобно (заставляет анализировать работу плагинов, редактировать и понимать конфиги и логику nginx, работать по ssh и это не заведется на shared хостингах), но в качестве решения для «белого списка» это идеальный вариант. Для параноиков.
Единственное, если мне память не изменяет, то когда я поставил плагин MLA (media library assistant) и попробовал его встроенные галереи через
[mla-gallery]
, тут у меня запросило авторизацию.В принципе, если кто-то хочет позволить AJAX работать, то можно сделать символические ссылки по аналогии с
wp-login.php
, а в ngx_http_substitutions_filter_module
кроме html и xml выбрать еще и обработку JS-скриптов и нужную регулярку с admin-ajax.php
на admin-ajax-wp.php
(если мы его так назовем).Я согласен, что это неудобно (заставляет анализировать работу плагинов, редактировать и понимать конфиги и логику nginx, работать по ssh и это не заведется на shared хостингах), но в качестве решения для «белого списка» это идеальный вариант. Для параноиков.
-1
Базовая версия WordPress не использует AJAX на лицевой странице сайта, тем более анонимный. А вот многие темы и плагины используют, это события wp_ajax_* и wp_ajax_nopriv_* (для анонимных запросов). Если вы собираетесь читать и редактировать код плагинов и ядра, пытаться где-то изменить admin-ajax.php на другой файл, то желаю вам удачи, особенно с обновлениями.
Наиболее правильным решением будет открыть доступ к admin-ajax.php и admin-post.php (был еще какой-то файл связанный с TinyMCE на лице, вроде wp-mce-help.php).
Вообще если честно, то блокировка админки WordPress базовой аутентификацией это глупость. Куда надежнее использовать двух факторную аутентификацию, fail2ban или подобные утилиты, HTTPS и конечно же надежные пароли.
Также стоит отметить, что блокировка/удаление/переименование xmlrpc.php это тоже глупость, особенно когда вы попытаетесь воспользоваться внешними инструментами для работы с сайтом, включая официальные мобильные приложения.
Наиболее правильным решением будет открыть доступ к admin-ajax.php и admin-post.php (был еще какой-то файл связанный с TinyMCE на лице, вроде wp-mce-help.php).
Вообще если честно, то блокировка админки WordPress базовой аутентификацией это глупость. Куда надежнее использовать двух факторную аутентификацию, fail2ban или подобные утилиты, HTTPS и конечно же надежные пароли.
Также стоит отметить, что блокировка/удаление/переименование xmlrpc.php это тоже глупость, особенно когда вы попытаетесь воспользоваться внешними инструментами для работы с сайтом, включая официальные мобильные приложения.
+4
Добрый вечер.
Редактировать код я буду лишь в том случае, если ngx_http_substitutions_filter_module будет недостаточно. Но пока его (и моих в regexp) хватает, так что я правлю вывод на frontend'е.
Решение с fail2ban несомненноне затрагивает правку кода, но на мой взгляд куда удобнее закрыть авторизацию wordpress через auth_basic и «зеленый» https («белый» сертификат).
Теперь на счет https в целом и xmlrpc — в статье изначально используются примеры с https и изначально закрыт xmlrpc так как он мне просто не нужен (на чем я акцентирую внимание). Тем более последние проблемы у WP были как раз из-за него. Соответственно если я не использую удаленное ПО для WP, то я его закрываю, дабы не болтался, но не удаляю, так вреда от закрытого не будет.
TinyMCE — у меня стоит advanced версия и если она и делает ajax запросы, то ошибок я не вижу, так как я пишу заметки из админки, в которой я уже авторизован.
Надежные пароли — это несомненно важно, но них я не стал упоминать, так как у параноика по определению они надежные.
Редактировать код я буду лишь в том случае, если ngx_http_substitutions_filter_module будет недостаточно. Но пока его (и моих в regexp) хватает, так что я правлю вывод на frontend'е.
Решение с fail2ban несомненно
Теперь на счет https в целом и xmlrpc — в статье изначально используются примеры с https и изначально закрыт xmlrpc так как он мне просто не нужен (на чем я акцентирую внимание). Тем более последние проблемы у WP были как раз из-за него. Соответственно если я не использую удаленное ПО для WP, то я его закрываю, дабы не болтался, но не удаляю, так вреда от закрытого не будет.
TinyMCE — у меня стоит advanced версия и если она и делает ajax запросы, то ошибок я не вижу, так как я пишу заметки из админки, в которой я уже авторизован.
Надежные пароли — это несомненно важно, но них я не стал упоминать, так как у параноика по определению они надежные.
-2
Для параноиков — это wordpress.org/plugins/static-html-output-plugin/
Нет PHP — нет проблем.
Нет PHP — нет проблем.
0
У меня была идея делать
Конечно можно поставить внешний поиск, можно поставить внешние опросы, но пока нагрузка не велика и уязвимостей, которые могут преодолеть сей барьер, — я в логах не видел.
Скажу, что предшественником WP был немного рабочий вариант на SSI+ngx_http_substitutions_filter_module+bash, где заметки раскладывались по папочкам, оформлялись через ssi и subs nginx'а, а bash генерировал меню и теги.
Я проработал с этим «франкенштейном» месяц, и мои тараканы ликовали! Затем выключил поддомен и положил в ящик на 2 года, потому, что еще не совсем потерянный.
А WP пришел ко мне внезапно, и «голая» 4-ая версия показалась мне тем идеальным минимализмом, который мне нужен. Не как коммерческому ресурсу, а просто %мне%.
И, по причине того, как я поставил в своей священной обители порочный WP, я решил доесть яблоко до конца, и отказался от статической версии сайта и за это моя паранойя предала меня анафеме. И чтобы как-то искупить этот грех, я решил раскаяться и написать о том, что если вы уж и свернули на ту же скользкую дорогу, что и я, то делайте это правильно и не оступайтесь.
После всего случившегося со мной, оглядываться я меньше не стал, но в целом дышится легче.
wget -m -p -k https://example.com/
после каждой публикации, но в этом случае не будет работать встроенный поиск, опросы и не было бы этой статьи.Конечно можно поставить внешний поиск, можно поставить внешние опросы, но пока нагрузка не велика и уязвимостей, которые могут преодолеть сей барьер, — я в логах не видел.
Скажу, что предшественником WP был немного рабочий вариант на SSI+ngx_http_substitutions_filter_module+bash, где заметки раскладывались по папочкам, оформлялись через ssi и subs nginx'а, а bash генерировал меню и теги.
Я проработал с этим «франкенштейном» месяц, и мои тараканы ликовали! Затем выключил поддомен и положил в ящик на 2 года, потому, что еще не совсем потерянный.
А WP пришел ко мне внезапно, и «голая» 4-ая версия показалась мне тем идеальным минимализмом, который мне нужен. Не как коммерческому ресурсу, а просто %мне%.
И, по причине того, как я поставил в своей священной обители порочный WP, я решил доесть яблоко до конца, и отказался от статической версии сайта и за это моя паранойя предала меня анафеме. И чтобы как-то искупить этот грех, я решил раскаяться и написать о том, что если вы уж и свернули на ту же скользкую дорогу, что и я, то делайте это правильно и не оступайтесь.
После всего случившегося со мной, оглядываться я меньше не стал, но в целом дышится легче.
0
Если тянет к простому движку на шелле, формирующему сайт из обычных файлов в markdown — посмотрите на werc.cat-v.org/ (на нём работает группа сайтов cat-v.org/).
+1
Кстати, вот официальный док от Wordpress по настройке Nginx: codex.wordpress.org/Nginx
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
WordPress для параноиков, часть 1