База данных под прицелом
5c8b6e8c

к наиболее критичным информационным ресурсам


Сервера баз данных относятся к наиболее критичным информационным ресурсам и потому они должны размещаться на выделенном сервере, расположенным во внутренней корпоративной сети, огражденной маршрутизатором или брандмауэром. Взаимодействие с базами данных обычно осуществляется через WEB-сервер, находящийся внутри DMZ-зоны (см. статью о брандмауэрах).
Размещать сервер базы данных на одном узле с WEB-сервером категорически недопустимо не только по техническим, но и юридическим соображениям (законодательства многих стран диктуют свою политику обращения с конфиденциальными данными, особенно если эти данные хранят информацию о клиентах компании). Тем не менее, совмещение сервера БД с WEB-сервером – обычное дело, которым сегодня никого не удивишь. Экономия… мать ее так! Захватив управление WEB-сервером (а практически ни одному WEB-серверу не удалось избежать ошибок переполнения буфера и прочих дыр), атакующий получит доступ ко всем данным, хранящимся в базе!
Сервер БД, как и любой другой сервер, подвержен ошибкам проектирования среди которых доминируют переполняющиеся буфера, многие из которых позволяют атакующему захватывать управление удаленной машиной с наследованием администраторских привилегий. Яркий пример тому – уязвимость, обнаруженная в сервере MS SQL и ставшая причиной крупной вирусной эпидемии. Не избежал этой участи и MySQL. Версия 3.23.31 падала на запросах типа select a.AAAAAAA…AAAAAA.b, а на соответствующим образом подготовленных строках – передавала управление на shell-код, причем атаку можно было осуществить и через браузер, передав в URL что-то типа: script.php?index=a.(shell-code).b.
Однако, даже защищенный брандмауэром SQL-сервер, может быть атакован через уязвимый скрипт или нестойкий механизм аутентификации. Разумеется, мы не можем рассказать обо всех существующих атаках, но продемонстрировать пару-тройку излюбленных хакерских приемов – вполне в наших силах.

Содержание раздела