Рубрика: Защита и безопасность

Звонки с коротких мобильных номеров всегда озадачивают абонентов. Так как на экране не отображается имя контакта, а только неизвестные цифры. Подсознательно мы понимаем, что звонит не кто-нибудь из друзей. Скорее всего это какой-то сервис или служба. В этой статье вы узнаете, что это за номер 7333 и кто с него звонит.

Кто может звонить с номера 7333

Звонки абонентам с короткого номера 7333 поступают в сети Теле2. При это могут не только звонить, но и присылать сообщения SMS. Возможен также вариант, когда вам звонят с номера, который начинается на эти цифры. В этом случае на ваш телефон могут звонить абоненты Казахстана. Звонки, как правило, не являются регулярными. Но периодически могут поступать до тех пор, пока вы не откажитесь от них в личном кабинете своего оператора.

Если это короткий номер без дополнительных цифр и вы являетесь абонентом оператора Теле2, то скорее всего это сервис знакомств. Возможно кто-нибудь из ваших знакомых или друзей пытается связаться с вами или указал ваш телефон в данном сервисе.

Это может быть полезным: DIT_EMP пришло СМС о штрафе.

Что за служба знакомств по телефону 7333

У оператора Теле2 есть собственная услуга знакомства, которая доступна по номеру — 222. Но в нашем случае 7333 — это номер посредника, который арендовал его для своих нужд. У многих может возникнуть вопрос — откуда сервис узнал мой номер телефона. Тем более, что сами абоненты нигде не регистрировались и не предоставляли свои данные на сайтах знакомств.

Это не удивительно. Мы часто разбрасываемся собственными данными. Простой пример — в социальных сетях. Часто пользователи оставляют свои номера на государственных порталах. Вспомните, возможно вы регистрировались на сайт Госуслуг или подобных. Эти контакты могут быть доступны в ваших личных профилях, если вы не скрыли их в настройках.

Как запретить звонки с 7333

Для того, чтобы звонки с номера 7333 больше не поступали, вы можете создать USSD-команду. Она отменит доступ к вашему номеру на портале. Введите на своём смартфоне следующую комбинацию: *333*22*0#. И нажмите кнопку для вызова. Если вы поднимете трубку на входящий звонок, с вас деньги сниматься не будут. Но при использовании этого сервиса, в нём доступен платный контент и услуги. Здесь доступны:

• Открытие полного доступа к сервису — платная услуга;
• Платно также доступно внимательное изучение анкеты участника;
• При отправке сообщений или изображений понравившемуся вам человеку с вас также будет сниматься определенная сумма.

Чаще всего услуга является нежелательной, поэтому вы можете сразу воспользоваться комбинацией для её отключения.

Читайте также, 2317 что за номер.

Как еще можно запретить звонки

Для того, чтобы управлять своими услугами, воспользуйтесь личным кабинетом на сайте https://tele2.ru. Если вы ни разу не входили в ЛК:

1. Вам нужно выбрать ссылку на главной странице сайта «Войти в личный кабинет»;
   

   

2. Если вы хотите создать логин и пароль, выберите соответствующую вкладку при входе. Если нужно зайти только раз, чтобы отключить функцию, введите в поле свой номер мобильного телефона;

   

3. На ваш телефон будет отправлено SMS, в котором находятся символы условного кода для подтверждения. Введите его в следующем окне на сайте и нажмите кнопку «Войти»;
4. После входа на сайт вам нужно найти и открыть раздел «Расходы и платежи»;
5. Здесь выбираем «Управление подписками» и находим услугу «Знакомства»;

Для её деактивации вам нужно нажать на кнопку «Отключить». После этого звонки с номера 7333 поступать не будут. Поэтому важно знать, что это за номер 7333.

Что делать, если нет услуги «Знакомства» или она не отключается

Вы можете непосредственно связаться с оператором Теле2 и объяснить свою проблему. Вам будут даны рекомендации, как можно избавиться от звонков с 7333. Для этого наберите на виртуальной клавиатуре своего мобильного устройства номер 611. Далее укажите раздел «Услуги» и нажмите цифру для связи с оператором.

У вас есть возможность проверить, сколько стоят SMS на те или иные короткие номера в сети Теле2. Для этого нужно записать USSD-команду: *125*короткий номер#. В SMS вы получите информацию о стоимости звонков и СМС, связанных с этим номером.

Как заблокировать короткий номер 7333

Практически все российские мобильные операторы предоставляют специальную услуги для блокировки номеров. Теле2 не исключение. Но она также является платной. Хотя эта сумма является символической — 1 рубль в день. Чтобы ею воспользоваться, наберите команду *220*1*номер#. Все другие подробности можно получить на веб-странице оператора https://msk.tele2.ru/option/black-list.

Вы можете использовать бесплатные мобильные приложения, которые доступны для Android (Play Market) и iOS, iPhone (App Store). Перейдя в онлайн-магазин для устройства, можно ввести в строке поиска запрос «черный список», чтобы получить нужные приложения. Внимательно прочитайте его описание, отзывы, а также требования к вашему устройству. Загрузите и установите его, после чего внесите номер 7333 в список запрещенных.

Довольно давно на различных сайтах и форумах статьи и темы, в которых говорилось о многочисленных брутфорс-атаках на wordpress-сайты. Недавно пришлось столкнуться с этой заразой. :)

В данном посте хотелось бы рассказать о своём опыте борьбы с подбором пароля на сайтах, работающих на WordPress. Сразу отмечу, что все мои сайты работают на nginx + php-fpm.

В качестве инструкции в основу была взята одна статья. Однако, описанный рецепт пришлось немного модифицировать под специфику своих атакующих. :)

Настройка

Первым делом необходимо установить fail2ban. Это не должно вызвать трудностей.

aptitude install fail2ban

После чего в конец конфигурационного файла /etc/fail2ban/jail.conf добавляем следующее:

[nginx-wp-auth] enabled = true filter = nginx-wp-auth action = iptables-multiport[name=wp-auth, port="http,https"] logpath = /var/log/nginx/*.access.log maxretry = 3 bantime = 3600

В данном случае action будет блокировать доступ для нарушителей только по указанным протоколам и помечать их как wp-auth. В logpath указываем путь к логам.

Будут анализироваться все логи, типа example.com.access.log. Для логов сайтов на вордпресс можно задать особые имена, например, wordpress-example.com.access.log, чтобы анализировались только эти лог-файлы.

Максимальное число попыток авторизации для одного айпи — три. Время блокировки — час. Оба эти параметра можно подбирать в индивидуальном порядке.

Следующим шагом будет создание фильтра.

touch /etc/fail2ban/filter.d/nginx-wp-auth.conf

Во время этого действия у меня возникли сложности: пример из оригинальной статьи не работал. И его пришлось изменить. :)

[Definition] failregex = .*/wp-login.php HTTP/1.1" 200      .*/wp-login.php/ HTTP/1.1" 302      .*/wp-login.php HTTP/1.0" 200 ignoreregex = 

В первом параметры записаны все совпадения, которые следует искать в лог-файлах. Здесь нужно проанализировать запросы атакующих в логах вашего сервера и добавить все подозрительные, связанные с wp-login.php.

Второй параметр предназначен для исключений из первой строки. Он не потребуется и остаётся пустым.

Тестирование

После создания фильтра проверьте его работу командой:

fail2ban-regex /var/log/nginx/example.com.access.log /etc/fail2ban/filter.d/nginx-wp-auth.conf

Обнаруженные совпадения будут отображены в результатах теста. Например, так:

Running tests =============  Use regex file : /etc/fail2ban/filter.d/nginx-wp-auth.conf Use log file   : /var/log/nginx/***.ru.access.log   Results =======  Failregex |- Regular expressions: |  [1] .*/wp-login.php HTTP/1.1" 200 |  [2] .*/wp-login.php/ HTTP/1.1" 302 |  [3] .*/wp-login.php HTTP/1.0" 200 | `- Number of matches:    [1] 1 match(es)    [2] 0 match(es)    [3] 0 match(es)  Ignoreregex |- Regular expressions: | `- Number of matches:  Summary =======  Addresses found: [1]     192.99.186.30 (Fri Jul 04 07:29:20 2014) [2] [3]  Date template hits: 0 hit(s): MONTH Day Hour:Minute:Second 0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second Year 0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second 0 hit(s): Year/Month/Day Hour:Minute:Second 0 hit(s): Day/Month/Year Hour:Minute:Second 0 hit(s): Day/Month/Year Hour:Minute:Second 58 hit(s): Day/MONTH/Year:Hour:Minute:Second 0 hit(s): Month/Day/Year:Hour:Minute:Second 0 hit(s): Year-Month-Day Hour:Minute:Second 0 hit(s): Year.Month.Day Hour:Minute:Second 0 hit(s): Day-MONTH-Year Hour:Minute:Second[.Millisecond] 0 hit(s): Day-Month-Year Hour:Minute:Second 0 hit(s): TAI64N 0 hit(s): Epoch 0 hit(s): ISO 8601 0 hit(s): Hour:Minute:Second 0 hit(s):   Success, the total number of match is 1

Проверка журнала блокировок

Fail2ban будет записывать все производимые блокировки. При необходимости можно проверять лог-файл /var/log/fail2ban.log на их наличие.

grep WARNING /var/log/fail2ban.log

ClamAv неплохо справляется с поиском шеллов и вирусов на сайтах. Однажды он помог мне обнаружить залитый шелл на сайт с вордпресс. Проблема оказалась в каком-то плагине, но это уже выходит за рамки статьи. :)

Прежде всего нужно будет установить ClamAv:

aptitude install clamav

После установки обязательно обновите вирусные базы, напечатав в консоли команду freshclam. Отобразится результат обновления.

root@localhost:~# freshclam ClamAV update process started at Wed Jul 16 11:08:02 2014 main.cvd is up to date (version: 55, sigs: 2424225, f-level: 60, builder: neo) Downloading daily-19193.cdiff [100%] daily.cld updated (version: 19193, sigs: 1082296, f-level: 63, builder: neo) bytecode.cld is up to date (version: 242, sigs: 46, f-level: 63, builder: dgoddard) Database updated (3506567 signatures) from db.local.clamav.net (IP: 194.186.47.19)

По истечении процесса обновления, можно запустить сканирование. Команда проста:

clamscan -i -r /path/to/site

Ключ -i отображает в отчёте о проверке информацию только о заражённых файлах.

Ключ -r укажет сканеру, что нужно сканировать каталоги рекурсивно.

При использовании данной команды, результат сканирования будет отображён в консоли. Если файлов много, а следить за консолью нет времени (или желания :) ), то можно запустить сканирование в оболочке Screen.

В случае необходимости, установите его:

aptitude install screen

Запускается сканирование в этом случае следующим образом:

screen -A -m -d clamscan -i -r -l clamlog.txt

Ключи -A -m -d для screen запускают сессию свёрнутой. Для разворачивания окна screen используется команда screen -r.

Свернуть окно с процессом сканирования можно нажатием сочетания клавиш ctrl+a+d.

Ключ сканера -l, который запишет лог сканирования в текстовый файл, имя которого нужно указывать сразу после ключа. Информация о найденных уязвимостях не будет отображена на экране консоли при использовании screen, поскольку с завершением сканирования screen также завершает свою работу.

Можно также просканировать файлы из списка. Для этого нужно указать ключ -f и файл, содержащий список файлов для проверки.

Аутентификация в ssh по ключу имеет несколько преимуществ. Во-первых, удобство. У вас может быть несколько серверов и один ключ. Не нужно всякий раз вводить пароль от нужного сервера, что сэкономит время. Во-вторых, это безопасно. Вы сможете отключить аутентификацию по паролю и ssh будет защищён от брутфорса.

В этой статье разберём работу с Putty на Windows. Для неё есть удобная утилита — pgagent, способная загружаться автоматически при запуске ОС, и хранящая приватный ключ в памяти. Он может быть использован не только для Putty, но и для Filezilla.

Скачиваем дистрибутив Putty на свой компьютер и устанавливаем.

Генерируем публичный и приватный ключи

Для аутентификации понадобится пара ключей: публичный и приватный. Первый ключ можно закачать на любой сервер, к которому вам нужен доступ. Второй ключ следует беречь и никому не отдавать. Желательно защитить его паролем.

Сгенерируем пару ключей при помощи утилиты PuttyGen. Запустите её, параметры по-умолчанию оставьте: тип ключа ssh-2 rsa, длина 2048 бит.

Кликните по кнопке Generate, передвигайте мышь, пока ключ не будет готов.

Через пару мгновений ключи будут созданы. Копируем содержимое окошка «Public key for pasting into OpenSSH authorized_keys file:» и сохраняем на рабочем столе в текстовом документе mypublickey.txt. Это ваш публичный ключ в формате OpenSSH.

Придумайте хороший пароль для защиты приватного ключа и укажите его в полях Key Passphrase и Confirm Passphrase. Если кто-то получит ваш ключ, он не сможет воспользоваться им потому, что не будет знать пароль.

Но если вы не видите в этом необходимости, пароль можно не указывать. Приватный ключ, при этом, будет защищён хуже.

После этого кликаем по кнопке Save private key и указываем, где сохранить ключ.

Устанавливаем публичный ключ на сервер

Авторизуйтесь на сервере под именем нужного пользователя. В его домашней папке создайте каталог .ssh.

# mkdir ~/.ssh;chmod 0700 ~/.ssh

Затем в этой папке нужно будет создать файл для хранения авторизационных ключей — authorized_keys:

# touch ~/.ssh/authorized_keys;chmod 0600 ~/.ssh/authorized_keys

Помните о сохранённом на рабочем столе публичном ключе? Откройте текстовый файл, в котором мы его сохранили и скопируйте ключ полностью.

После чего на сервере откройте файл authorized_keys при помощи вашего любимого редактора (nano, например) и вставьте скопированный публичный ключ. Сохраните файл.

Эти же действия можно проделать при помощи sftp клиента. Filezilla отлично справится с задачей. Также создаём указанные папку и файл, редактируем и т.д.

Когда публичный ключ сохранён на сервере, самое время настроить putty agent.

Настройка putty agent и добавление в автозагрузку

Аутентификация может происходить и при помощи putty, если приватный ключ указать в соответствующей графе настроек. Однако, это неудобно, если нужно пользоваться ещё и sftp клиентом. Тогда лучше подгружать ключ при помощи putty agent: один раз запускаем pgagent и имеем доступ, когда пожелаем. Надо сменить ключ? Не проблема — меняем только в агенте и нигде больше. А чтобы каждый раз вручную не запускать агент, нужно сделать его загружаемым при включении Windows. :)

Для добавления pgagent в автозагрузку создайте ярлык для pgagent.exe. В свойствах ярлыка, в пункте «Объект» просто пропишите путь к каждому ключу, разделяя их пробелами.

"C:Program FilesPuTTYpageant.exe" S:folderkey.ppk S:folderkey2.ppk

Созданный ярлык нужно скопировать в папку автозагрузки. Для этого откройте меню Пуск, выберите Все программы, на папке Автозагрузка кликните правой кнопкой мыши, нажмите пункт «Открыть» в контекстном меню.

В эту папку переместите или скопируйте ярлык запуска pgagent. В итоге раздел Автозагрузка в меню Пуск должен выглядеть вот так.

Перезагрузите компьютер. Если все действия были сделаны правильно, в трее на панели задач будет отображаться иконка pgagent, при двойном клике по которой будет открываться основное окно приложения с загруженными ключами.

Обратите внимание, что если ваш ключ запаролен, то пароль необходимо будет указать в агенте сразу после авторизации в Windows. Пароль запрашивается только один раз после включения, до выхода из системы.

Проверка аутентификаци по ключу

Остаётся только проверить правильность аутентификации ssh по ключу. Запустите putty и подключитесь к любимому серверу.

Результат успешной аутентификации:

Authenticating with public key "something" from agent

Если же всё настроено неправильно, то будет выдано сообщение об ошибке и предложено напечатать пароль. :)

В современном мире шифрование данных является не просто прихотью, а прямой необходимостью. В частности — шифрование http трафика имеет огромное значение для всех сайтов, где производится обработка любых персональных данных. А также для защиты от mitm-атак.

Таким образом, использование Forward Secrecy на веб-серверах становится обязательным для каждого сайта, работающего по https протоколу и позволяет улучшить стойкость шифрования информации.

Forward secrecy можно соответствующим образом настроить в nginx.

Предположим, у вас есть какой-то сайт который должен поддерживать работу по https. Прежде всего необходимо создать ключ Диффи-Хеллмана.

# openssl dhparam -out /etc/nginx/ssl/dh-2048.pem 2048

И выставить соответствующие права доступа для него.

# chmod 0600 /etc/nginx/ssl/dh-2048.pem

Далее следует настроить nginx. Вот пример конфигурации для сайта, работающего на ssl.

server { server_name example.com; listen 80; listen 443 ssl; ssl_certificate /etc/nginx/ssl/example.com_crt.pem; ssl_certificate_key /etc/nginx/ssl/example.com_key.pem; ssl_dhparam ssl/dh-2048.pem; ssl_ciphers ECDH:DH:!ADH:!AECDH:!SEED:!DES:!3DES:!RC4:!NULL; ... }

Рассмотрим каждую переменную.

ssl_dhparam — путь к файлу с ключом Диффи-Хеллмана. Можно указать путь, относительно директории с конфигурационными файлами nginx.

ssl_ciphers — шифры, которые будут использоваться для ssl соединений. У меня указаны шифры, подобранные для prosody. Минимальная длина ключа составляет 128 бит. Все поддерживают forward secrecy.

После настройки nginx следует перезапустить командой service nginx restart.

Для тестирования настроек воспользуйтесь сервисом https://www.ssllabs.com/ssltest/index.html. В результатах теста, в параграфе «Protocol Details», должен быть вот такой результат:

Сегодня заглянул в access-лог одного сайта на вордпресс и обнаружил множество запросов подобного рода:

1.234.83.77 - - [05/Sep/2014:12:07:01 +0600] "POST /xmlrpc.php HTTP/1.1" 200 441 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; 125LA; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)" 1.234.83.77 - - [05/Sep/2014:12:07:01 +0600] "POST /xmlrpc.php HTTP/1.1" 200 441 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; 125LA; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)" 1.234.83.77 - - [05/Sep/2014:12:07:02 +0600] "POST /xmlrpc.php HTTP/1.1" 200 441 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; 125LA; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)" 1.234.83.77 - - [05/Sep/2014:12:07:02 +0600] "POST /xmlrpc.php HTTP/1.1" 200 441 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; 125LA; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)"

Судя по результатам гугления, есть какой-то эксплоит, связанный с этим файлом — xmlrpc.php. В одной статье на английском говорилось, как я понял, опираясь на свои плохие знания данного языка :), о возможности организовать подбор паролей. Правда, пока что я не заметил последствий, но лучше заранее принять меры. :)

Ранее была опубликована заметка о защите сайта на вордпресс от брутфорса. И этот вариант отлично подошёл и для сегодняшнего случая.

Единственный момент: нужно подкорректировать правила в соответствии с запросом. В статье приводился пример:

[Definition] failregex = .*/wp-login.php HTTP/1.1" 200       .*/wp-login.php/ HTTP/1.1" 302      .*/wp-login.php HTTP/1.0" 200 ignoreregex =

Данный список правил следует модифицировать так:

[Definition] failregex = .*/xmlrpc.php HTTP/1. ignoreregex =

Или добавить правило с новой строки в существующий список. Если защита была настроена ранее. После чего перезапустить fail2ban.

При этом, будет производится поиск любых запросов http 1.0 и http 1.1, с любым статус-кодом, полученным от сервера.

На моём сервере Postfix работает в качестве сервера исходящей почты, то есть только отправляет почту с сайтов. Естественно, открыт 25-ый порт. Но большую часть времени туда долбятся носом всякие боты, пытающиеся воспользоваться сервером, как открытым релеем. :) Естественно, у них ничего не получается, ибо настроены правила. Но логи засоряют.

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

Apr  8 21:15:20 omega postfix/smtpd[3075]: connect from unknown[189.158.233.139] Apr  8 21:15:21 omega postfix/smtpd[3075]: lost connection after UNKNOWN from unknown[189.158.233.139] Apr  8 21:15:21 omega postfix/smtpd[3075]: disconnect from unknown[189.158.233.139] Apr  8 21:16:00 omega postfix/smtpd[3075]: warning: hostname dsl-189-158-233-139-dyn.prod-infinitum.com.mx does not resolve to address 189.158.233.139: Name or service not known

Поскольку у меня также установлен fail2ban для борьбы с брутфорсом в блогах, то и решение нашлось довольно быстро. Этим и хочу поделиться с вами. :)

Прежде всего откройте конфигурационный файл фильтра для Postfix. Он находится в каталоге /etc/fail2ban/filter.d/postfix.conf. Найдите параметр failregex и с новой строки допишите следующее регулярное выражение:

^%(__prefix_line)sdisconnect from S+[]

Сохраните файл. Теперь проверьте регулярку командой:

fail2ban-regex /var/log/mail.log /etc/fail2ban/filter.d/postfix.conf

У меня в итоге выдало 100500 ip-адресов, в том числе и по стандартному правилу. :)

Последний шаг: откройте главный файл настроек — /etc/fail2ban/jail.conf. Найдите директиву [postfix] и включите фильтр.

enabled  = true

Перезапустите Fail2ban. На этом всё.

В последнее время fail2ban перестал нормально защищать от брутфорса на wordpress потому, что ip во всяком запросе уникальный и блокировать каждый адрес бессмысленно.

Раз такая ерунда, решил ограничить доступ к файлу wp-login.php по ip. Здесь есть один нюанс: для прописанного в конфигурационном файле nginx локейшена (location) нужно добавить обработчик скриптов, при использовании php-fpm.

В итоге, конструкция выглядит так:

server{ ... location ~* wp-login.php$ { allow 127.0.0.1; deny all; try_files $uri =404; fastcgi_pass unix:/run/php-www.sock; include fastcgi_params; fastcgi_param SCRIPT_FILENAME  $document_root$fastcgi_script_name; fastcgi_ignore_client_abort off; fastcgi_param PHP_VALUE "sendmail_path=/usr/sbin/sendmail -t -i -fmail@example.com"; fastcgi_param PHP_ADMIN_VALUE "open_basedir=/var/www/example.com/:/var/save_path/:/var/tmp_dir/"; } ... }

Теперь ботам выдаётся ошибка 403 вместо страницы авторизации. Только этот метод не слишком универсален — если на сайте есть регистрация пользователей, применить его не получится.

Но если вы — единственный пользователь, то можно подключить фантазию, и вместо доступа по ip сделать доступ по user-agent, по паролю…

Читая документацию веб-сервера nginx, наткнулся на интересный модуль под названием http referer module. Он позволяет блокировать доступ к сайту, либо его разделам, если в запросе отсутствует корректный заголовок referer.

Этот модуль можно применить для защиты админки любого сайта от брутфорса. Например, сайт работает на вордпресс, но блокировка доступа по ip будет неуместной, если на сайте есть зарегистрированные пользователи. Им же тоже надо аутентифицироваться, а собирать их ip — занятие бессмысленное. :)

Принцип работы прост: на сайте выводим ссылку на страницу входа wp-login.php, а в конфигурационном файле nginx задаём проверку запросов к wp-login.php и /wp-admin/ на наличие адреса нашего сайта в заголовке реферер.

Прежде всего создаём выделенный локейшн для нужных страниц. Например, так:

server{ ... location ~* (wp-login.php|wp-admin(.*))$ {  try_files $uri =404;  fastcgi_pass unix:/run/php-www.sock;  location ~ .php$ {   include fastcgi_params;   fastcgi_param SCRIPT_FILENAME  $document_root$fastcgi_script_name;   fastcgi_ignore_client_abort off;   fastcgi_param PHP_VALUE "sendmail_path=/usr/sbin/sendmail -t -i -fmail@example.com";   fastcgi_param PHP_ADMIN_VALUE "open_basedir=/var/www/example.com/:/var/save_path/:/var/tmp_dir/";  } } ... }

Как видим, тут указаны ещё и параметры обработки php скриптов (иначе указанные в локейшн скрипты не будут работать).

Конфигурацию модуля можно прописать сразу после location ~* (wp-login.php|wp-admin(.*))$ {.

Первая строка:

valid_referers server_names

Она указывает, что корректным полем referer должен считаться домен сайта.

А также прописываем проверочное условие. Если поле referer некорректно, сервер отобразит ошибку 403 (доступ запрещён).

if ($invalid_referer) {     return 403; }

В итоге конфигурация будет выглядеть так:

server{ ... location ~* (wp-login.php|wp-admin(.*))$ { valid_referers server_names if ($invalid_referer) {     return 403; } (параметры fastcgi) } ... }

Напоследок на сайте добавляем ссылку на страницу входа (wp-login.php или что-то там ещё). Если посетитель кликает по этой ссылке, то получает форму авторизации. Но если бот будет стучаться напрямую к этому файлу, то получит ошибку доступа.

Да, стоит отметить, что заголовок referer можно подделать. Но лично мне боты с корректно заполненным полем referer попадались очень редко и банились по ip. :) Так что этот метод может быть вполне уместен.