And-rey

Рейтинг
78
Регистрация
01.04.2012

Подцепил заразу на разрабатываемый сайт... 2-ой день гавно-IP стучится в wp-login.php каждые 40 сек. Главное сайт в разработке, вообще полупустой) Закрыт от поиска в роботсе через "Disallow: / " но открыт для обзора заказчиком, и тем кто "наткнётся" случаем, не суть...

Отключил плагин Limit Login Attempts (меж прочим для пару-тройки брутоботов он не так уж и подгружает весь WP, отсеивая нечесть).. и пытаюсь заткнуть заразу парвкой .htaccess - там по IP бота заблокировал, так теперь растёт размер файлов access_log и error_log и график "нагрузки" на сервер.

А что если подобные бото-IP перенаправлять вообще в другое русло залогиниться :

SetEnvIf REMOTE_ADDR 192.12.131.1 REDIR="redir"
RewriteCond %{REDIR} redir
RewriteRule ^/$ https://accounts.google.com

Задача "Определить плагину, пускать на сайт того кто более 3-5 раз бьёт пароли неверные" - занимает много вычислений и ресурсов? Там же с 3 неверных обращений блокируется IP бота... Немного заинтересуюсь от чего возникнет нагрузка спустя 3 попыток, если потом вредный IP заблокирован?

П.с. а если организовать проверку по IP который логинится неверно 3 раза в обход всего WP? Или я так и не понял... это речь идёт о Dos-атаке прямо в корень - site.ru или конкретно в адрес site.ru/wp-login.php ?! =>

Все заходы из поисковика гугла идут мне на главную страницу. И дальше никуда. т.е. тупо "просматривают" одну страницу.

(/ru/forum/comment/12274096)

Примочка для .htaccess по отшвыриванию заходов с прокси-серверов:

RewriteEngine on

RewriteCond %{HTTP:VIA} !^$ [OR]

RewriteCond %{HTTP:FORWARDED} !^$ [OR]

RewriteCond %{HTTP:USERAGENT_VIA} !^$ [OR]

RewriteCond %{HTTP:X_FORWARDED_FOR} !^$ [OR]

RewriteCond %{HTTP:PROXY_CONNECTION} !^$ [OR]

RewriteCond %{HTTP:XPROXY_CONNECTION} !^$ [OR]

RewriteCond %{HTTP:HTTP_PC_REMOTE_ADDR} !^$ [OR]

RewriteCond %{HTTP:HTTP_CLIENT_IP} !^$

RewriteRule ^(.*)$ — [F]

Мож поможет как-то. Хотя слетит доступ и для нормального посетителя, если он из под прокси в инете...

Ну и для конкретного IP(например 213.171.204.130 ) только такие варианты блокировок:

<Limit GET POST>

order allow,deny
deny from 213.171.204.130
allow from all
</Limit>

Order allow,deny
Deny from 213.171.204.130
Allow from all

SetEnvIf REMOTE_ADDR 213.171.204.130 REDIR="redir"
RewriteCond %{REDIR} redir
RewriteRule ^/$ http://google.com

p.s. ...да, а как там с отзывами по плагинам для WP - Stealth Login Page или Limit Login Attempts... помогают ли в случаях таких атак?!

Офигеть, вчера никаких апов движка не было, а сегодня - вперёд. И чего, тут же баги повылазили... А смысл обновляться сразу же? Можно и месяц обождать, пусть дыры и косяки поддержка лотает. Ведь на скорость загрузки сайта это никак не повлияет. Что нового можно увидеть/ожидать от 3.7,... то что они рекомендуют длину пароля, новую локализацию и процесс обновления?! имхо...

Изменения внесены только в файлы readme.html и wp-config-sample.php,

))

Я в свой роботс уже как год не заглядывал... Мож покритикуете, или для себя чё нового высмыкните:

User-agent: *
Allow: */uploads
Disallow: /cgi-bin
Disallow: /wp-
Disallow: */feed
Disallow: *?s=
Disallow: *?attachment_id=
Disallow: *?file_id=
Disallow: *?stats_author
Disallow: *?all_comments
Disallow: *?post_type=func
Disallow: /id_date
Disallow: /count.php?
Disallow: /function-cat
Disallow: /function-tag
Disallow: /template-tags
Disallow: /artictag
Disallow: /articles
Disallow: /profile

Честно говоря, эта тема о правильном роботс будет вечно=) Что я только туда не ставил, почитаешь где в блоге или на форуме... добавишь/изменишь строки. А сайт как был в необходимом индексе, так и сидит. Если позиции не устраивают - так это только seo.

Пользуясь случаем, а есть ли ресурс, определяющий все возможные комбинации открываемости страниц, ну и соответственно определяющий возможные дубли?

=))

Что сам код PHP... +своевременные include, минимальные запросы к БД, кеширование на РНР, что сама структура таблиц БД - всё это влияет на скорость генерации html-страниц, отдаваемые клиенту. Наличие графики в шаблоне (фон, шапка, футер) и скорость хостера - аналогично влияет на скорость загрузки.

Но если выпали страницы из ПС - то это уже seo... недокрученная под требования ПС-ов внутренняя оптимизация или копипаст контента, что там еще - самое последнее АГС-фильтры на домен) Прогоните через мерилки скорости загрузки сайтов ,если сами шлёпаете "движок".

П.С. Я пару лет назад убил полгода для написания типа-движка на связке PHP+MySQL.. лайт-вариант для сайтов-визиток. Бросил это дело, как ни крути а доля правды есть: "Зачем изобретать велосипед (WP и Джумла)", если он уже есть и отточен до более чем желаемого функционала и поддержки )

А проверял ли кто "стойкость" плагинов Stealth Login Page или Limit Login Attempts при такой "атаки" на сайты WP... именно на путь wp-login?! Спасают ли они от левого бота?

...PHP и БД, похоже код не нравится поисковикам...Сам код работает прекрасно, но для поисковиков он явно дефектный...

Доброго времени! Извиняюсь что сюда пишу, но думаю актуально так речь о пагинации... Или минизаголовок: "И снова о плагине навигации WP-PageNavi " =)

Перерыл ряд блогов, описывающих данный плагин, но у многих в комментариях после обзора статьи.. проблема навигации на главной так и не решилась: не листается навигация при клике по номеру страниц (стиль-формат как на многих сайтах 1 2 3 4 ... Далее>>) Т.е. нажимаем "2" или "Далее>>" но так и остаёмся на прежней странице с последними 4-6 постами (вывод на главной последних записей)

Причина кроется в несовместимости шаблонов под WP, что есть в сети... под реализацию пагинации любых страниц сайта. В каждом по-своему организован вывод запроса через query_posts() и в итоге то страницу категорий не листает плагин, то записи одно автора или страницу поиск... Ко мне обратились помочь решить проблему с навигацией на главной, но так и не понял в чём подвох:

если плагин WP-PageNavi видит ссылку вида site.ru/рубрика_такая/page/2 , то без проблем листает следующую страницу... а если на главной находимся, то ссылки в пагинации для главной site.ru/page/2 уже не понимает и стоим на месте =(

Пробовал ряд конструкций прописывать под query_posts():

$paged = (get_query_var('paged')) ? get_query_var('paged') : 1;

query_posts($query_string . "showposts=2&amp;paged=$paged");

$cat_query = ''; 

if ( !empty($blog_cats) ) $cat_query = '&cat=' . implode(",", $blog_cats);
else echo '<!-- blog category is not selected -->'; ?>
<?php
$paged = is_front_page() ? get_query_var( 'page' ) : get_query_var( 'paged' );
?>
<?php query_posts($query_string . "showposts=4&paged=" . $paged . $cat_query); ?>

query_posts( array( 'cat' => 8, 'paged' => get_query_var('paged') ) );

query_posts( array( 'cat' => 8, 'paged' => get_query_var('page') ) );

и в итоге ничего не срабатывает для листания на главной ... Рубрики, Страница с поиском, Записи автора - работает, а главная нет... Вот код из шаблона, который пытаюсь заставить работать:

if ( is_home() ){

$args=array(
'showposts' => (int) get_option('askit_homepage_posts'),
'paged' => $paged
);
if ( ( isset( $_GET['homeq'] ) && $_GET['homeq'] == 'recent' ) || !isset( $_GET['homeq'] ) ) {
$args['category__not_in'] = (int) get_option('askit_exlcats_recent');
}
if ( isset( $_GET['homeq'] ) && $_GET['homeq'] == 'popular' ) {
$args['orderby'] = 'comment_count';
}
if ( isset( $_GET['homeq'] ) && $_GET['homeq'] == 'random' ) {
$args['orderby'] = 'rand';
}
$args = apply_filters( 'et_home_query', $args, isset( $_GET['homeq'] ) ? $_GET['homeq'] : '' );

query_posts($args);

}
Кто подскажет что туда подставить/заменить, чтобы на главной заработала навигация,?

domen7, я заказчику объяснил на примере цен, которые в рег.ру висят... такая тематика дорого стоит. Благодарю за указанный вами диапазон, сориентировали в стоимости, если здесь на форуме приобрести.. Дело за клиентом на счёт оплаты

П.С. Рассмотрю подходящие имена на домены ниразу не использовавшихся, но приближённые к вышеуказанным мною тэгам (антиквариат и т.д.)

Всего: 439