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

Что за сервер баз данных то?

Cheers
Pete

наверное с триггером я погорячился все таки, т.к. быстрым гуглингом я не нашел способа в триггере вытянуть sql, который запускается в данном пайпе, видимо это невозможно ну да ладно.

всегда есть возможность решить задачу административными методами:

довабляем в messages:

включаем полные логи на iis сервере, следим за тем, что бы время между сиквелом и iis было синхронизировано, потом смотрим какие url привели к появлению записей в messages. Потом проводим тотальный аудит этих страниц.

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

Cheers
Pete

segggя же написал выше, что страницу добавления сообщения ВООБЩЕ убрали с сервера

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

Варианты:
1. Sql injection
2. прямой коннект к сиквелу снаружи
3. Чего то в коде.
4. Левый код на серваке, троян etc.
5. Магия

1 - вполне реально. методы борьбы: ставим поле DateCreated, профайлер, запускаем трейс на эту базу, trace output - file. Ждем. Когда появляется запись, смотрим в трейсе, какой сиквел полз на нашу базу во время, взятое из DateCreated. Думаем. Решаем.

2 - если у вас sql смотрит в интернет я боюсь, что помогать уже нечем. Надеюсь, что это не так. Варианты: зовем толкового арка или же сеньор программера с админом, закрываем sql для доступа снаружи, меняем всю архитектуру.

3 - осталась какая-то левая дыра в коде, которую и используют. Используя информацию полученную в 1, можно попробовать идентифицировать страницу по трейсу, и по логам iis в данное время.

4 - Хошь, не хошь, а 1 все равно придется делать. Дальше отлавливать процессы, курить логи и думать думать думать...

5 - всерьез этот ответ мы рассматривать не будем.

seggg
Хм... А что кромольного Вы видите в том, что SQL смотрит в Интернет? Вы знаете хоть одну дыру, позволяющую проникнуть в SQL? (не зная пароля).
Пароли у нас нормальные, так что подбор мало вероятен.


Слушайте, так че вы с самого начала не рассказали историю вот таким образом:

Народ, у нас SQL Server (какой сервис пак, кстати сказать) смотрит прямо в интернет. Недавно в одной из таблиц стали появлятся левые записи. Мы убрали asp страницы, через которые как мы думаем появляются эти записи, но записи все равно продолжают появляться...

Все бы посмеялись и разошлись и никто бы время не тратил...

segggB0rG:

Все бы посмеялись и разошлись и никто бы время не тратил...
Ну тогда можете посмеяться над всеми провайдерами, которые предоставляют хостинг на платформе Windows (включая и Гарант-парк, на котором хостится данный ресурс). Все они предоставяют доступ к SQL серверу снаружи. И не видят в этом ничего зазорного.

Нравятся мне такие "знатоки"... По существу ответить можете? Есть у Вас информация о дырах с помощью которых можно "взломать" SQL сервер?

Слушайте, вы что хотите узнать? Как вам решить проблему нарушения уровней доступа в вашу базу, или же как ломать sql server?

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

Если вы хотите узнать как ломать sql server, то сформулируйте свой вопрос и фффпоиск. Вашим образованием по этому вопросу я заниматься не буду из простых соображений, что нефикк ламерам это знать. Если найдете, значит ваше.

Что же до доступа к провайдерскому серваку, то оно обычно осущетвляется по защищенным каналам, по той простой причине, что в нормальном договоре с Data Center обычно оговаривается уронь защищенности приложения и его данных, в таком случае самому провайдеру не выгодно вывешивать сервак в открытый доступ. Вопросы есть?