Comments 30
location / {
if ( $request_uri ~* /wp-login.php) {
....
Что это за лапша?!
Почему не
location /wp-login.php {
limit_req zone=login burst=4;
proxy_pass http://backend:8080;
<...>
}
В примере с Nginx можно защитить любую подстроку, не зная наперед в корне или подкаталоге она располагается. Этим конфигурационным файлом не только wordpress закрыть можно.
И да, наверное стоило в конфигурационном примере для haproxy сделать так же, воспользовавшись path_sub вместо path_beg.
И да, наверное стоило в конфигурационном примере для haproxy сделать так же, воспользовавшись path_sub вместо path_beg.
Я спрашивал зачем там if
wiki.nginx.org/IfIsEvil
wiki.nginx.org/IfIsEvil
Если расскажите как иначе подружить location ~* с proxy_pass, буду очень благодарен.
savostin прав. Вам следует убрать if и сделать, основываясь на вырезке из документации
так (привожу пример из своей работающей на nginx-1.6.2 конфигурации, приведите сами к своей):
Если location задан регулярным выражением.
В этом случае директиву следует указывать без URI.
так (привожу пример из своей работающей на nginx-1.6.2 конфигурации, приведите сами к своей):
upstream oldsites {
server 127.0.0.1:8081;
}
location ~* \.php$ {
try_files $uri =404;
proxy_pass http://oldsites;
}
Очень интересно, спасибо! Обязательно попробую на стенде.
Директиву proxy_pass без URI следует указывать всегда, когда подмена URI не требуется. Чтобы потом проблем не было.
Есть разница даже между:
и
В последнем случае осуществляется дополнительная обработка, помимо бессмысленной замены "/" на "/", также происходит декодирование всего URI. Но документацию же мало кто читает внимательно, поэтому последняя конструкция весьма распространена.
Есть разница даже между:
location / {
proxy_pass http://backend;
}
и
location / {
proxy_pass http://backend/;
}
В последнем случае осуществляется дополнительная обработка, помимо бессмысленной замены "/" на "/", также происходит декодирование всего URI. Но документацию же мало кто читает внимательно, поэтому последняя конструкция весьма распространена.
Спасибо! Пост исправлен. If'ов в конф. файле больше нет.
Я упустил момент, в котором nginx начал позволять использовать proxy_pass в location ~*. Только что проверил на тестовом стенде, 1.6.2 спокойно это переваривает. Люблю сообщество как раз за такие вещи!
Я упустил момент, в котором nginx начал позволять использовать proxy_pass в location ~*. Только что проверил на тестовом стенде, 1.6.2 спокойно это переваривает. Люблю сообщество как раз за такие вещи!
Тут фокус в том и заключается, что для location ~* нельзя указать proxy_path напрямую.
а зачем там ~*?
ответил в комментарии выше.
Неа, не ответили.
Вам в данном случае не нужен в location regexp, вообще.
Вам в данном случае не нужен в location regexp, вообще.
Право, эта дискуссия ставит меня в тупик.
Попробую объяснить более абстрактно. Предположим, у нас есть веб-сервер Apache (или группа веб серверов), что обслуживает, опять же предположим, домашние странички пользователей: /~username1 и /~username2. Перед ним установлен Nginx. У обоих (в общем случае N) пользователей установлена популярная CMS cmsname. У username1 в корне, у username2 в подкаталоге /superblog/. За авторизацию пусть отвечает login.php.
Конфигурацией вида location ~* /login.php мы с легкостью поймаем обе формы авторизации. Ваш же пример /location login.php — не сработает ни у одного из пользователей.
Попробую объяснить более абстрактно. Предположим, у нас есть веб-сервер Apache (или группа веб серверов), что обслуживает, опять же предположим, домашние странички пользователей: /~username1 и /~username2. Перед ним установлен Nginx. У обоих (в общем случае N) пользователей установлена популярная CMS cmsname. У username1 в корне, у username2 в подкаталоге /superblog/. За авторизацию пусть отвечает login.php.
Конфигурацией вида location ~* /login.php мы с легкостью поймаем обе формы авторизации. Ваш же пример /location login.php — не сработает ни у одного из пользователей.
Т.е. у Вас site.com/username1/login.php и site.com/username2/login.php?
Если честно, мало где встречал такую конфигурацию.
Если честно, мало где встречал такую конфигурацию.
Зачем используется регулярное выражение. Выше вам сказали, что достаточно будет префиксной строки. location login.php будет пойман в любой директории.
http://nginx.org/ru/docs/http/ngx_http_core_module.html#location
http://nginx.org/ru/docs/http/ngx_http_core_module.html#location
Пост исправлен. If'ов в конф. файле больше нет.
Я упустил момент, в котором nginx начал позволять использовать proxy_pass в location ~*. Однако, как подсказали в комментариях и я только что проверил на тестовом стенде, 1.6.2 спокойно это переваривает. Люблю сообщество как раз за такие вещи!
Я упустил момент, в котором nginx начал позволять использовать proxy_pass в location ~*. Однако, как подсказали в комментариях и я только что проверил на тестовом стенде, 1.6.2 спокойно это переваривает. Люблю сообщество как раз за такие вещи!
На мой взгляд у вордпресса проблем с безопасностью больше по темкам/плагинам, а не с брутфорсом…
Это только за январь
Это только за январь
За такой nginx.conf обычно приговаривают к расстрелу. =) Смотреть: events.yandex.ru/lib/talks/2392/
Если расскажите как иначе подружить location ~* с proxy_pass, буду очень благодарен.
А в чем проблема?
location ~* /wp-login.php {
proxy_pass http://backend:8080;
}
Ха! Видимо уже ни в чем. На стенде заработало. Спасибо!
На одной из более ранних версий nginx оно не срабатывало. Вот, правда, не помню на чем именно — на proxy_pass или на limit_req
Дополню-ка пост:)
На одной из более ранних версий nginx оно не срабатывало. Вот, правда, не помню на чем именно — на proxy_pass или на limit_req
Дополню-ка пост:)
На одной из более ранних версий nginx оно не срабатывало.Вы видимо один из первых пользователей nginx? =)
nginx.org/ru/CHANGES.ru
Изменения в nginx 0.1.25 19.03.2005
...
*) Добавление: директива proxy_pass может использоваться в location,
заданных регулярным выражением.
Директива же
limit_req могла использоваться в любых location всегда.
А можно как-то защитить от брутфорса http-auth?
У меня этим занимается fail2ban, например, его тоже можно влёт настроить, причем для всех сайтов шаред хостинга, и сразу для многих cms, дописав нужный путь в правило фильтра.
Задача может быть реализована в Nginx с помощью модуля ngx_http_limit_req_module [1], выступающем в роли фронт-энда к Apache или веб-сервера FastCGI.
Подскажите пожалуйста, как задача может быть реализована при использовании nginx в качестве nginx: т.е. статика + php-fpm через fastcgi_pass?
Уточню, как быть с цепочками:
— всё ли верно?
location ~* /wp-login.php {
limit_req zone=login burst=4;
fastcgi_pass unix:/var/php-fpm.sock;
}
location ~ \.php?$ {
fastcgi_pass unix:/var/php-fpm.sock;
}
— всё ли верно?
Да, все так. В данном случае совершенно неважно, куда дальше идет трафик — на Апач или на fcgi-сокет: limit_eq действует на определенную секцию «location»
Да, это здорово.
Но ведь после секции «location ~* /wp-login.php»
стоит секция с более общим регулярным выражением, которое включает в себя и файл wp-login.php — «location ~ \.php?$»
Могу ошибаться — но разве секция location с RegEx срабатывает только при первом совпадении с RequestedURI? Мне кажется — с каждым. Нет?
В этом и озадаченность.
Но ведь после секции «location ~* /wp-login.php»
стоит секция с более общим регулярным выражением, которое включает в себя и файл wp-login.php — «location ~ \.php?$»
Могу ошибаться — но разве секция location с RegEx срабатывает только при первом совпадении с RequestedURI? Мне кажется — с каждым. Нет?
В этом и озадаченность.
Sign up to leave a comment.
Ограничение количества попыток ввода пароля в веб-форме авторизации при помощи Nginx или HAProxy на примере WordPress