Это похоже на фишинговую атаку, и в этом случае отправка ответа 404 связана с раскрытием уязвимости. К сожалению, это именно то, что делает IIS.
Я бы предпочел, чтобы эти парни даже не знали о существовании моего сервера.
Изменить: Конечно, как только TCP-соединение уже установлено, они знают, что что-то находится на этом порту. Было бы неплохо, если бы они не знали, что на другой стороне IIS
Когда вы говорите «случайные домены», вы имеете в виду имена хостов, верно? Не IP-адреса?
В первом случае имя хоста, по крайней мере теоретически, полностью не связано с фактическим IP-адресом сервера с точки зрения сервера. Каждый (ну, почти каждый) HTTP-запрос будет иметь HTTP-заголовок под названием «Хост», его очень легко смоделировать или «подделать». Выполните следующую команду
curl -H "Host: serverfault.com" http://www.google.com/
(Игнорировать вывод)
Эта команда заставляет серверы Google отвечать на запрос «serverfault.com», как если бы это был обычный виртуальный хост, который в случае Google выглядит так, как будто он указывает на файл, который перенаправляет на основной сайт Google.
Проще говоря, невозможно «заблокировать» эти запросы без того, чтобы ваш брандмауэр проанализировал каждый запрос, и это открывает целый мир других проблем. Ответ 404 или 403 правильный, 404 означает, что ресурс не существует на сервере, хотя обычно это относится к файлу, он может относиться и ко всему сайту.
Ваш сервер выбирает, отвечать или нет, основан (упрощенно) исключительно на целевом IP-адресе, а не на имени хоста. К тому времени, когда сервер начинает читать имя хоста, соединение уже установлено. Да, вы можете заставить его просто разорвать соединение, но ответ 404 - гораздо лучший вариант, потому что он официально сообщает клиенту, что ресурс не существует.