Последствия для безопасности восстановления резервной копии из неизвестного источника?

31

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

Вопрос 1 : Каковы потенциальные последствия восстановления резервной копии, которая вполне может быть вредоносной?

Вопрос 2 : Что вы можете сделать, чтобы защитить свой сервер / данные в других базах данных от воздействия восстановления потенциально вредоносной резервной копии? RESTORE VERIFYONLYКазалось бы, хороший первый шаг. Окончательный ответ, вероятно, заключается в «восстановлении базы данных в виртуальной машине с песочницей без доступа к внешнему миру», но давайте предположим, что эта опция не обсуждается. Что еще нужно сделать в этой ситуации?

Саймон Ригартс
источник
1
Даже если предположить, что восстановление только для данных (без хранимых процедур или чего-то подобного), может случиться много злых укусов. Предположим, что резервная копия предназначена для веб-приложения, содержащего пользовательскую таблицу с соответствующими уровнями разрешений. Злонамеренная резервная копия может предоставить доступ пользователям, у которых их не должно быть, и которые знают, что они могут сделать из этого.
Ли Райан
Очень странно, что никто не упомянул о потенциальном риске процедур или функций CLR. (больше не отключено по умолчанию)
ALZDBA

Ответы:

21

База данных может содержать вредоносный код, возможно, процедуру, которая собирается изменить пароль для входа в систему «sa» или удалить каждую базу данных. Однако я вижу, что причиной проблемы является то, что отдельный человек восстанавливает базу данных, а затем вручную выполняет любой код в этой базе данных. Это не будет выполняться каким-либо автоматическим способом.

В базе данных нет параметров, которые можно было бы применить, чтобы SQL Server автоматически выполнял некоторый бит кода в базе данных после восстановления его на сервере. Если бы это произошло, я бы ожидал, что Microsoft утратит сертификат Common Criteria для этого продукта. Это большая ошибка, которую я допустил в СУБД.

Шон Мелтон
источник
Если компонент Service Broker повторно включен как часть восстановления (используя WITH ENABLE_BROKERet al), тогда код может запускаться «автоматически». Очевидно, что реставратор не захочет использовать ни одну из этих опций, если безопасность вызывает беспокойство, но потенциально он может быть похоронен в приложении стороннего поставщика, где пользователь может его не увидеть.
Джон Зигель
Какой код можно выполнить через Service Broker? Я никогда не использую это или настраиваю это.
Шон Мелтон
Активация хранимых процедур. technet.microsoft.com/en-us/library/…
Джон Сигел
2
Может также сделать RESTORE HEADERONLY, чтобы увидеть, если в базе данных включено сдерживание. Если это так, и на сервере включена защита, пользователи смогут получить к нему доступ, если вы не предоставите им доступ к серверу. Это для SQL 2012 или новее, конечно. если на сервере не включена защита, а в базе данных в резервной копии она включена, восстановление завершится неудачей, поэтому, в основном, это проблема, только если она включена на сервере.
Роберт Л Дэвис
1
@JonSeigel Не думаю, что они сработают автоматически. ЧТО-ТО должно поместить сообщение в очередь, отправив его службе, поэтому в этой базе данных должно быть какое-то взаимодействие для вставки записи или запуска процедуры или чего-то еще. Очереди брокера не просто продолжают свои процедуры активации без какого-либо взаимодействия, они следят за сообщениями, которые будут отображаться в очереди.
JNK
11

Есть некоторые профилактические меры, которые вы могли бы сделать.

  1. Убедитесь, что никто, кроме одного системного администратора, не имеет доступа к восстановленной базе данных.
  2. Переведите БД в однопользовательский режим после завершения восстановления.
  3. Проверьте код внутри всех хранимых процедур и функций и триггеров внутри этой базы данных.
  4. Выполните dbcc checkdb, чтобы убедиться, что нет проблем с целостностью.
  5. Проверьте пользователей, которые раньше имели доступ к базе данных, и удалите их всех.
  6. Начните разрешать доступ, очень ограниченный определенными объектами, проверенными вами.

Как сказал Шон, код не будет выполняться сам по себе, если какая-то хранимая процедура, которая кажется vbalid, не имеет исполняемого кода другого вредоносного кода. Это причина проверки кода внутри каждого из них, прежде чем переходить в многопользовательский режим.

yrushka
источник
10

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

Конечно, это само по себе ничего не изменит - вирус вдруг не станет чувствительным, но если ваши пользователи попытаются получить доступ к файлу, они могут быть заражены. (Привет, я сказал, что достигал.) Я предполагаю сценарий, когда внешний хакер хочет получить вредоносное ПО в двери, и затем он отправляет электронное письмо Бобу в бухгалтерии, говоря: «Вот файл: \ sqlserver \ filetableshare \ myvirus.exe "- в этот момент он прошел через ваши брандмауэры без обнаружения, и теперь мы используем ваши внутренние антивирусные и антивирусные инструменты.

Брент Озар
источник
2
Вы также можете выразить это как «база данных содержит инструкции для нашего персонала, которые должны быть прочитаны и применены». Если они пойдут по злонамеренным инструкциям, они запустят ракеты по Москве. Это была бы обычная таблица varchar ina ... То же самое, если вы восстанавливаете двоичные файлы и приглашаете сотрудников запустить его без проверки источника, он у вас уже есть.
Ремус Русану
@RemusRusanu запускает ракеты по Москве, хахаха, здорово!
Брент Озар
Люблю перспективы социальной инженерии. Целевое электронное письмо с файлом .bak может быть очень заманчивым в зависимости от цели.
Макс Вернон
7

Восстановление VERIFYONLY может показаться хорошим первым шагом. Окончательный ответ, вероятно, заключается в «восстановлении базы данных в виртуальной машине с песочницей без доступа к внешнему миру», но давайте предположим, что эта опция не обсуждается. Что еще нужно сделать в этой ситуации?

Функция Restore verifyonly проверяет целостность базы данных, и НЕ БУДЕТ сообщать вам, содержит ли резервная копия вредоносный код или нет. RESTORE VERIFYONLY не пытается проверить структуру данных, содержащихся в томах резервных копий. Очень неприятно, что если резервное копирование происходит изнутри фирмы, где вы работаете, может быть злонамеренным, но если оно исходит от какой-то третьей стороны, вам нужно быть осторожным, как указал Шон.

Документация Microsoft Online гласит, что

• В целях безопасности мы не рекомендуем подключать или восстанавливать базы данных из неизвестных или ненадежных источников. Такие базы данных могут содержать вредоносный код, который может выполнять непреднамеренный код Transact-SQL или вызывать ошибки, изменяя схему или физическую структуру базы данных. Прежде чем использовать базу данных из неизвестного или ненадежного источника, запустите DBCC CHECKDB для базы данных на непроизводственном сервере, а также проверьте код, такой как хранимые процедуры или другой определенный пользователем код, в базе данных.

Shanky
источник
7

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

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

Джеймс Л
источник
Хорошая точка зрения. Я не обязательно хотел сосредоточиться на «действительной резервной копии, содержащей вредоносное ПО», сбой сервера SQL с помощью недопустимой резервной копии также является совершенно уместным ответом на вопрос «что может пойти не так?»
Саймон Райтс
5

Какой риск существует при восстановлении неизвестной базы данных из неизвестного источника? Никто.

Какой риск существует, если разрешить неизвестному приложению подключаться с использованием учетной записи sysadmin для подключения к этой базе данных и запуска кода? МНОГО! Если учетная запись приложения имеет права только в пределах базы данных и не имеет доступа на уровне сервера, то она ничего не может сделать вне базы данных. Это в основном сводится к правильной настройке инфраструктуры безопасности на сервере с самого начала.

mrdenny
источник
2

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

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

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

Фил Перри
источник
2

Существует не так много опасностей, за исключением некоторых далеко идущих, предложенных здесь. Как уже упоминалось, трудно выполнить автозапуск материала в самой резервной копии базы данных. Нужен какой-то внешний механизм запуска.

Получите старый ноутбук / настольный компьютер и ознакомительную версию программного обеспечения для вашей базы данных (SQLExpress), если лицензирование является проблемой. Скопируйте файл резервной копии на устройство, отключите сеть / беспроводную сеть и выполните восстановление. Тогда начинай копать. Потратьте столько времени, сколько вам нужно, потому что есть много мест, которые можно скрыть, большинство из них уже освещены в других сообщениях в этой теме.

Целостность вашего администратора базы данных и благополучие вашей производственной среды важнее любого приказа вышестоящего начальника.

Philippe
источник