LINUX.ORG.RU
решено Форум — Web-development  

Левые имена в access.log

 


0

1

Проверяя логи NGINX случайно заметил много обращений к серверу по неправильному имени сервера.
То есть вместо mysupersite.ru ко мне попадают запросы идущие на mysupersaite.ru, maisupersite и прочее.
Кто-то с большим количеством свободного времени реально наделал похожих имён на мой IP.
Вопросов 2
1) Зачем?
2) Как прекратить эти безобразия?
Конфиг такой:

server {
listen 80;
server_name mysupersite.ru;
location / {return 301 https://somesite.ru$request_uri;}
}


Так как Nginx матчит первую попавшуюся секцию server, в случае если нет точных совпадений, то посетители mysupersaite.ru в итоге попадают на мой https://mysupersite.ru.
И вроде бы ничего страшного, но я недоумеваю.

Пробовал выставить первой секцией
server {
      listen 80 default_server;
      return 444;
}


но это не помогло, всё равно при запросом curl'ом или браузером на неправильный домен попадаю на свой

★★★★★
← PhpBB 3.0.13-PL1 несколько шаблонов
Как правильнее со слешом «https://example.com/» или без «https://example.com» →

Нужно настроить default_server с настройками в духе

server {
  listen      80 default_server;
  server_name _;
  return      444;
}

2) Как прекратить эти безобразия?

Без доступа к домену устранить причину никак.

Я бы посоветовал задуматься зачем кому-то покупать за живые деньги схожие названия и прописывать их на ваш ip.

Явных причин я вижу две:

1. С целью перепродажи этих доменам вам же чуть позже;

2. Конкурентная борьба (вариантов реализаций тут несколько).

Deleted
()
Последнее исправление: Rainor (всего исправлений: 1)

А был-ли мальчик? В смысле домен. Домены по которым ломятся существуют? На кого зарегистрированы? Сколько таких доменов в логах? Откуда на них ломятся?

MrClon ★★★★★
()
Ответ на: комментарий от MrClon

Мальчик был, доменов порядка 200, проверил первые попавшиеся - существуют, зареганы на одного человека. UPD Есть версия что это обычные дела для чуваков из соседнего отдела, так что первый вопрос теряет интригу и интерес, и в приоритете второй вопрос

zolden ★★★★★
() автор топика
Последнее исправление: zolden (всего исправлений: 1)
Ответ на: комментарий от zolden

А, при изменении listen не работает -s reload, нужен было рестарт.
Теперь всё ок, всем спасибо

zolden ★★★★★
() автор топика

левые

Как же вы за надоели! «Астанавитесь»!

telikan ★
()
Ответ на: комментарий от zolden

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

MrClon ★★★★★
()

Чтобы по неправильным доменам и по гольному IP-шнику не выдавать свой контент, а возвращать 404, 403 или просто рвать соединение с помощью 444-го кода, нужно создать отдельную дефолтную server-конфигурацию. В Debian для этой цели логично использовать файл /etc/nginx/conf.d/default.conf - чтобы не мешать его с рабочими доменами в папке /etc/nginx/sites-enabled (не забывайте заглядывать в папку /etc/nginx/conf.d после установки в Debian nginx-пакета).

Ну и прописать там:

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    # SELF SIGNED CERT. 
    include snippets/sslcert_dev.conf;

    server_name _;

    access_log /var/log/nginx/default_access.log;
    error_log  /var/log/nginx/default_error.log;

    return 404;
    # ... or 403 or 444
}

Я, например, возвращаю 403-й код - после того, как столкнулся с циклическим тыканием какого-то бота при тупом обрыве соединения по коду 444.

vinvlad ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← PhpBB 3.0.13-PL1 несколько шаблонов
Web-development
Как правильнее со слешом «https://example.com/» или без «https://example.com» →