epic fail.part I
По сообщению РосБизнесКонсалтинг хакеры получили доступ к конфеденциальной информации на сервере службы ФСО. При близжайшем рассмотрении, оказалось, что это был сервер, где был установлен продукт Дозор-Джет, для которого я несколько лет назад разрабатывал серверную часть и некоторые утилиты по администрированию. Дозор-Джет среди прочих возможностей, осуществляет фильтрацию почтовых сообщений, предоставляет доступ системе поиска по сообщениям. При этом вся информация хранится в Oracle Database. Конечно СМИ в восторге, "взломан" сервер, предназначенный для обеспечения безопасности!
Однако, на основе опыта внедрения Дозора в нескольких организациях, я осмелюсь предположить, что взлома, как такового и не было. Было поразительное головотяпство, при котором после установки "забыли" убрать сервер с Дозор-Джет в ДМЗ. "Хакеры" нашли открытый ip адрес на котором отвечал web сервер, затем, скорее всего прочитав документацию, вошли с паролем по умолчанию. Если все так, как я предполагаю, доступ им удалось получить только к web-интерфейсу с тестовым набором e-mail сообщений. При переводе системы в production отдельно убеждались, что Дозор стоит в ДМЗ.
Конечно, если бы попались умники, они бы могли попробовать sql injection, но похоже, что на это ума уже не хватило. Кстати, насколько я могу вспомнить, защиты от sql injecttion в Дозоре не было, поскольку считалось, что к этой системе имеют доступ только доверенные персоны.
Рекомендованной конфигурацией являлась установка web интерфейса отдельно от СУБД. Как было сделано в вышеприведенном случае я конечно не знаю. Но если СУБД находилась на этом же сервере то появлялись возможности для более серьезного взлома.
Любое допущение в системе безопасности - есть дыра, а пароли по умолчанию - самая большая из них. В принципе и Oracle не сразу догадался закрывать (lock) пользователей по умолчанию (кажется только начиная с 9i). По вот этой ссылке утверждают, что всего за 2 дня удасться перебрать все 8 сивмольные комбинации, и без включения password policies рано или поздно пароль подберут . Кстати, в 11gR2 учетная запись будет автоматически заблокирована после 10 неудачных попыток.
Хорошей практикой является прослушивать только определенные подсети, выделенные для администрирования. К сожалению, в Listener можно вносить только конкретные адреса, для подсетей придется использвать cman. Да, и закрыть паролем Listener было бы также неплохо.
Если вы прочитали все вышепериведенное и не нашли для себя ничего нового, почему бы не прочитать про Oracle Database Firewall ? А если у Вас Solaris, то даже и вот это :)
Однако, на основе опыта внедрения Дозора в нескольких организациях, я осмелюсь предположить, что взлома, как такового и не было. Было поразительное головотяпство, при котором после установки "забыли" убрать сервер с Дозор-Джет в ДМЗ. "Хакеры" нашли открытый ip адрес на котором отвечал web сервер, затем, скорее всего прочитав документацию, вошли с паролем по умолчанию. Если все так, как я предполагаю, доступ им удалось получить только к web-интерфейсу с тестовым набором e-mail сообщений. При переводе системы в production отдельно убеждались, что Дозор стоит в ДМЗ.
Конечно, если бы попались умники, они бы могли попробовать sql injection, но похоже, что на это ума уже не хватило. Кстати, насколько я могу вспомнить, защиты от sql injecttion в Дозоре не было, поскольку считалось, что к этой системе имеют доступ только доверенные персоны.
Рекомендованной конфигурацией являлась установка web интерфейса отдельно от СУБД. Как было сделано в вышеприведенном случае я конечно не знаю. Но если СУБД находилась на этом же сервере то появлялись возможности для более серьезного взлома.
Любое допущение в системе безопасности - есть дыра, а пароли по умолчанию - самая большая из них. В принципе и Oracle не сразу догадался закрывать (lock) пользователей по умолчанию (кажется только начиная с 9i). По вот этой ссылке утверждают, что всего за 2 дня удасться перебрать все 8 сивмольные комбинации, и без включения password policies рано или поздно пароль подберут . Кстати, в 11gR2 учетная запись будет автоматически заблокирована после 10 неудачных попыток.
Хорошей практикой является прослушивать только определенные подсети, выделенные для администрирования. К сожалению, в Listener можно вносить только конкретные адреса, для подсетей придется использвать cman. Да, и закрыть паролем Listener было бы также неплохо.
Если вы прочитали все вышепериведенное и не нашли для себя ничего нового, почему бы не прочитать про Oracle Database Firewall ? А если у Вас Solaris, то даже и вот это :)
Невзламываемых систем вообще нет, причем самое слабое место, как всегда, люди.
ОтветитьУдалить:)
Вообще не все например, пользуются такими фичами как шифрование трафика по SQL*Net, а оно работает с незапамятных времен.
если ты пользуешься TCPS, то опцию ASO вкупе с EE, надеюсь, приобрёл?
ОтветитьУдалитьЕсли только это не наезд на сам Джет..
ОтветитьУдалить