Gubin Systems

Если вы видите у себя ошибку

A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent

то ее причины в следующем:

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

Поэтому для исправления ошибки рекомендуется:

• проверить диск на ошибки.
• почистить диск, если места мало или подготовить новый, более вместительный.
• увеличить лимит виртуальной машины (тот же виртуальный жесткий диск например).

Сжатие базы данных

USE databasename;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE databasename 
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (databasename_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE databasename 
SET RECOVERY FULL;
GO

Проверка брокера

--Проверка брокера
select is_broker_enabled from sys.databases where name = DB_NAME()

--Проверка MASTER KEY
SELECT d.is_master_key_encrypted_by_server
FROM sys.databases AS d
WHERE d.name = DB_NAME()

Включение брокера

--включить брокера
    DECLARE @S NVARCHAR(4000) 
    SET @S = 'ALTER DATABASE [' + DB_NAME() + '] SET SINGLE_USER WITH ROLLBACK IMMEDIATE' 
    EXEC (@S) 
    SET @S = 'BEGIN TRY ALTER DATABASE [' + DB_NAME() + '] SET ENABLE_BROKER END TRY BEGIN CATCH ALTER DATABASE [' + DB_NAME() + '] SET NEW_BROKER END CATCH' 
    EXEC (@S) 
    SET @S = 'ALTER DATABASE [' + DB_NAME() + '] SET MULTI_USER' 
    EXEC (@S) 
    SET @S = 'ALTER AUTHORIZATION ON DATABASE::[' + DB_NAME() + '] TO [sa]' 
    EXEC (@S) 
    SET @S = 'IF NOT EXISTS(SELECT TOP 1 1 FROM SYS.SYMMETRIC_KEYS WHERE NAME LIKE ''%MASTERKEY%'') CREATE MASTER KEY ENCRYPTION BY PASSWORD = ''Pa$$w0rd'''
    EXEC (@S) 
GO 

-- дропнуть и создать заново мастер ключ
DROP MASTER KEY 
GO 
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Pa$$w0rd' 
GO
Состояние suspect - починка
alter database БД set EMERGENCY, SINGLE_USER
dbcc checkdb('БД', REPAIR_ALLOW_DATA_LOSS)
dbcc checkdb('БД', REPAIR_REBUILD)
alter database БД set ONLINE, MULTI_USER

Один из самых важных критериев надежности информационной системы — безопасность систем управления базами данных (сокращенно СУБД). Атаки, направленные на нее, в большинстве случаев критические, потому что могут частично либо полностью нарушить работоспособность системы. Поскольку крупные организации формировали свою инфраструктуру давным-давно и обновление на новые версии программного обеспечения вызывает у них «большие» проблемы, самыми распространенными версиями до сих пор остаются Microsoft SQL Server 2005 и Microsoft SQL Server 2008.

Как злоумышленник взламывает базу

Первое, что начинает делать злоумышленник — это собирать информацию о сервисах, расположенных на сервере жертвы. Самое главное, что нужно знать для поиска Microsoft SQL Server — номера портов, которые он слушает. А слушает он порты 1433 (TCP) и 1434 (UDP). Чтобы проверить, имеется ли MS SQL на компьютере жертвы, необходимо его просканировать. Для этого можно использовать утилиту NMAP со скриптом ms-sql-info. Запускаться сканирование будет примерно так:

Подбор пароля

Допустим, СУБД на сервере обнаружена. Теперь стоит задача получить к ней доступ. И тут хакер встречает первое препятствие в виде аутентификации. Вообще, Microsoft SQL сервер поддерживает два вида аутентификации:

• Windows Authentification — доверительное соединение, при котором Microsoft SQL Server принимает учетную запись пользователя, предполагая, что она уже проверена на уровне операционной системы.
• Смешанный режим — аутентификация средствами Microsoft SQL Server + Windows Authentification.

По умолчанию используется первый режим аутентификации, а смешанный режим активируется отдельно. На практике же довольно трудно встретить базу без смешанного режима — он более гибок.

Обычно на данном этапе хакер не имеет доступа в корпоративную сеть, тем самым использовать аутентификацию посредством Windows не может. Но поскольку найден открытый порт с Microsoft SQL, то хакер пытается побрутить (подобрать пароль) административной учетной записи sa, стандартной для смешанного режима. Для автоматизации процесса используется модуль утилиты Metasploit под названием mssql_login:

msf > use auxiliary/scanner/mssql/mssql_login
msf auxiliary(mssql_login) > set RHOSTS 172.6.2.104
RHOSTS => 172.16.2.104
msf auxiliary(mssql_login) > set PASS_FILE /root/Desktop/pass.txt
[*] 172.16.2.104:1433 - MSSQL - Starting authentification scanner.
[*] 172.16.2.104:1433 - LOGIN FAILED: WORKSTATION\sa:admin (Incorrect:)
[*] 172.16.2.104:1433 - LOGIN FAILED: WORKSTATION\sa:qwerty (Incorrect:)
[*] 172.16.2.104:1433 - LOGIN FAILED: WORKSTATION\sa:toor (Incorrect:)
[*] 172.16.2.104:1433 - LOGIN SUCCESSFUL: WORKSTATION\sa:root
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

В случае удачного подбора пароля хакер подключается к базе. Далее сценарий прост — включаем хранимую процедуру, позволяющую выполнять команды на уровне операционной системы, и закачиваем на сервер Meterpreter shell.
Сессия Meterpreter создается и злоумышленник получает полный контроль к базе и не только. Под контроль попадают файлы, мышь и клавиатура, а также другие системные функции.

Защита баз данных

Под защитой баз данных здесь понимается способ предотвратить несанкционированный доступ к информации, хранимой в таблицах. Защита исходного кода форм и модулей не рассматривается.
Данный способ защиты позволяет установить пароль на открытие БД, для всех пользователей. Для его создания необходимо открыть БД в «монопольном» режиме и выбрать пункт меню
Сервис / Защита / Задать пароль базы данных

Для работы с такой базой данных в Microsoft Access потребуется вводить пароль. Вот пример работы с файлом БД, используя DAO или ADO.


Это самый ненадежный способ защиты баз данных. Существует достаточное количество бесплатных и платных утилит, отображающих пароль. В том числе доступны исходные коды на языке Visual Basic, позволяющие прочитать такой пароль.
Существуют другие — более безопасные — методы защиты, но мы здесь о них говорить не будем — это заняло бы слишком много времени.

Ответственность за взлом баз данных

Статья 272 Уголовного кодекса Российской Федерации подразумевает ответственность за неправомерный доступ к государственным информационным системам и (или) содержащимся в них государственным информационным ресурсам, причем для наступления уголовной ответственности необходимо будет, чтобы такой «взлом» повлек уничтожение, блокирование, модификацию либо копирование информации, нарушение функционирования государственной информационной системы.
Те же деяния, совершенные группой лиц по предварительному сговору или организованной группой либо лицом, имеющим доступ к государственным информационным системам, в том числе функционирующим в составе критически важных объектов, и (или) содержащимся в них государственным информационным ресурсам в силу его служебного положения, должны наказываться лишением свободы на срок от 3 до 7 лет.

Заключение

В заключение необходимо отметить, что любая компания, обрабатывающая большие объемы информации в базах данных (БД), может столкнуться с хищением конфиденциальных сведений. Для проведения атак на информационные системы злоумышленники используют широкий спектр «технологий» — DDoS атаки, получение несанкционированного доступа путем компрометации учетных записей пользователей, вредоносное программное обеспечение различных типов, взлом службы доменных имен и прочие. Значительную долю (более 30% по данным портала hackmageddon.com) успешных внешних атак на информационные системы были проведены при помощи SQL-инъекций (громкие «взломы» последнего времени — атаки на базы данных пользователей Facebook, LinkedIn, банков) от которых пострадали не только миллионы пользователей, но и репутация компаний. были проведены при помощи SQL инъекций. Поэтому важным вопросом остается защита баз, а также помощь специалистов для противодействия взломам.

Полная ошибка выглядит так:

Ошибка транзакции SQL: текущая транзакция не может быть зафиксирована и не может поддерживать операции, которые записываются в файл журнала.

Ошибку поймал при работе с БД клиента. Сделал следующее: проверил БД через DBCC, затем переиндексировал БД, а затем поменял XACT_ABORT.

SET XACT_ABORT OFF

Последнее помогло.