Самый простой способ - в настройках IIS прописать обработчиком ошибок 403.14, 404 и 405 требуемый aspx-файл. Правда будут проблемы с преобразованием входных параметров, т.к. в этом случае они несколько в кривом виде приходят.

Хорошо, не нравится простой способ - пишите ISAPI-фильтр для этого :).

Да, 404 ошибки мало будет.
Если это каталог, т.е. "/" в конце, то будет генериться

сорри, отправилось случайно...

...то будет генериться 403.14, а если метод POST, то 405 ошибка.

Dir1 или не должен существовать или если у него запрещен directory listing, то даже если он существует, можно этот же обработчик на 403.14 ошибку повесить.
POST ловится точно также, GET немного извращается, из имени первого параметра нужно вырезать лишнее. Выведите на тестовой странице список параметров и все будет ясно. В общем есть немного мороки, но все не так страшно.
Другими способами у вас ничего не выйдет. Или ловить ошибку обработчиком или перенаправлять запрос до того, как он дойдет до IIS, т.е. ISAPI-фильтром.
Первый вариант гораздо проще.
Ну или купите готовый коммерческий продукт такого типа.

Проблема больше не в логах, а в том, что в приложение url тоже приходит такой кривой, соответственно имя первого параметра GET-запроса будет 404;настоящий_урл_запрошенный пользователем. Она тоже решаемая, хотя и добавляет головной боли.

В принципе способ с обработчиком на типы файлов довольно здравый, но проблем с ним примерно столько же, сколько и с обработчиком ошибок.
1. Как правило, на коммерческих хостингах есть возможность перемапить обработчик ошибок, а вот с обработчиком типов файлов так не получится.
2. Действительно, нужно не забыть убрать маппинг с каталогов, в которых лежит все статическое (а если статическое вперемешку с требующим обработки?).
3. Если каталог существует, то обращение к нему, например /dir1, приведет или к выводу содержимого или к ошибке, а не к перехвату.

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

marina milanina
Выяснилось что 20% запросов идут к несуществующему .gif файлику, но поскольку для редиректа используется 404 обработчик, то каждый из таких запросов запускал обработчик.
А в обработчике был цикл по 30 достаточно сложным регулярным выражениям.


Тоже сталкивался с такой проблемой. У нас она решалась следующим образом - во-первых, резались расширения - gif, jpg, png, swf и т.п.
Во-вторых, в отдельный лог скидывались имена файлов, которые не найдены и не соответствуют ни одному разделу - такая информация довольно оперативно обнаруживалась.
От этой проблемы все равно полностью не избавиться, можно только свести ее к минимуму. Преднамеренными действиями можно все равно будет нагрузить сервер по самое не могу.
Например в случае обработчика на все файлы - если злоумышленник понаставил кучу кривых ссылок на картинки (например преднамеренно на несуществующие картинки в каталоге, на котором установлен обработчик)
А цикл(!) по 30(!) сложным регулярным выражениям - это не перебор? :)