О СЕРВЕРЕ БЕДНОМ ЗАМОЛВИТЕ СЛОВО – II

Автор: Internet Maniac aka Алексей Павленко.

Скажи мне свой IP, и я скажу, кто ты...

Статья "О сервере бедном замолвите слово..." вызвала большой интерес читателей, поэтому я решил продолжить эту тему – тем более что кроме Web-серверов есть еще и сервера баз данных...

Итак, у вас есть сервер под управлением Windows NT (2000). Как вы, наверное, знаете, под этой операционной системой могут работать различные типы серверов: Web, почтовые, файловые, печати, баз данных. Microsoft настоятельно рекомендует для каждой из перечисленных задач использовать отдельные компьютеры, а еще лучше два (три, четыре...). Для большинства организаций это неприемлемо, поэтому все сервисы очень часто можно найти на одном мощном сервере – таким образом уменьшается стоимость использования системы. Но, как известно, у любой медали две стороны, и вот на второй стороне этой медали находится как раз проблема безопасности. Ведь если хакер взломает один сервис, то велика вероятность, что он получит доступ и ко всем остальным.

После эпидемии вирусов Code Red, Code Red 2 и Nimda надежность Web-сервера IIS (Internet Information Services) от Microsoft была поставлена под большой и жирный знак вопроса. По всему миру огромное количество компьютеров стало уязвимо не на словах, а на деле. Пусть софтверный гигант бьет себя пяткой в грудь и говорит, что их Web-сервер самый популярный и поэтому в нем нашли столько много багов... Как эта популярность набрана, говорить, наверное, не надо – ровно так же, как было и с Internet Explorer. Если вам надо поставить что-то серверное, то часто без установленного IIS это сделать просто нельзя. Да и про популярность можно поспорить, по крайней мере в России. Хорошо лишь, что после нашествия вирусов все-таки (наконец!!!) администраторы стали устанавливать заплатки. Ладно, если вам нравится IIS (как мне, например), используйте его на здоровье, но – будьте бдительны!

Какая фирма обходится без баз данных? Ведь при их применении гораздо удобнее и быстрее вести учет сотрудников, аудит средств и многое другое. В качестве сервера баз данных чаще всего используют MS SQL Server, Oracle, Interbase, My SQL. Раз мы уже договорились, что у нас компьютер работает под управлением Windows, то глупо было бы предположить, что базы данных работают под My SQL. Конечно же, для этого используется MS SQL Server! Хороший продукт, мне нравится, и если вы подумали, что я сразу начну рассказывать о его взломе, то вы ошибаетесь. Лично я не слышал про способы его "опускания". Хотя... есть все же одна штука... Ладно, уговорили, записывайте.

Аутентификация пользователей в MS SQL Server возможна двумя путями: используя логин из Windows и/или конкретную учетную запись, созданную специально для базы данных. Первый вариант предоставляет пользователю больше удобств. Зная имя и пароль в базе данных, можно делать в домене все, что доступно данному пользователю. Или наоборот – если вы прописаны в домене, то можете получить доступ к данным из БД, причем очень велика вероятность того, что администратор не обрезал права доступа. А вероятность того, что в базе данных хранится много секретной или в крайнем случае конфиденциальной информации, ничуть не меньше....

А зная пароль администратора, можно вообще горы сдвигать! Так вот, вся пугающая прелесть MS SQL Server в том, что по умолчанию после установки заводится учетная запись sa – это и есть администратор. Догадываетесь, какова длина его пароля? Ноль символов! Обычно все дальнейшие действия с базой данных администратор проводит через заход под своим именем из домена, а про sa все забывают. Если, конечно, вообще знали...

Таким образом, любой человек, имеющий доступ к серверу, может делать с базой всё, что угодно. Добавлять пользователей БД, менять им пароли, читать данные, удалять, изменять... Главное хорошо знать язык построения запросов SQL. Да, помните, я говорил в начале статьи, что если взломан один сервис, то могут быть взломаны и все остальные? Сейчас я докажу это!

Попробуйте подсоединиться к серверу баз данных и выполнить следующий код:

use master
exec xp_cmdshell 'dir /O c:\'

Рис. 1. Получение структуры каталогов на удаленном сервере

Да-да-да, не удивляйтесь, через сервер БД можно получить доступ к командной строке. Для этого служит хранимая процедура xp_cmdshell. Какую потенциальную опасность это несет, я и говорить не буду – просто вспомните про net.exe, route.exe, format.exe... Да мало ли добра лежит в winnt\system32! К тому же и в самом SQL есть большое количество полезных команд и хранимых процедур. Больше всего мне понравилась одна, видимо, оставленная Microsoft специально для хакеров – напишешь shutdown, и сервер перезагрузится. Лепота... В общем, имея доступ к командной строке с правами администратора, имеешь [доступ ко] все[му].

Рис. 2. Меняем пароль администратора БД

Есть одно большое НО. Чтобы подсоединиться к серверу, надо либо самому оказаться в его локальной сети, либо же "застать" оный в Интернете. Второе, по логике, должно быть вообще недопустимым – ведь даже если пароль администратора неизвестен, его можно подобрать, и очень легко – поверьте моему опыту. Однако зачем такие сложности? Вспомните еще раз про две стороны медали. Например, у организации есть сервер баз данных. Через некоторое время руководство захотело иметь свой представительский Web-сервер. Второй компьютер покупать жалко, поэтому на первый поставили дополнительно Web-сервер и купили IP-адрес. Ура! Работает и первое, и второе. Про то, что база данных становится доступной извне, никто и не думает...

Итак, если найден компьютер с IIS, то всегда есть и шанс наличия MS SQL Server. Приблизительных процентов подобного соотношения приводить не буду, расскажу лишь маленькую историю.

Меня с моим приятелем, работающим в провайдерской конторе, давно интересовал вопрос о соотношении использования различных Web-серверов. Несомненно, есть всевозможные независимые статистические данные, но они часто противоречат друг другу. Однажды товарищ быстренько написал программу на Perl, которая проверяет наличие Web-сервера на удаленном компьютере и определяет его название. За неделю поисков было найдено довольно много компьютеров, и оказалось, что IIS в мире все-таки используется, и он не сильно  отстал от Apache. А из всего объема просканированных компьютеров Web-сервера были установлены только на 0,5%.

Рис. 3. Статистика использования Web-серверов в мире

Получив список адресов, где стоял IIS, я решил ради любопытства проверить их прочность. Запустив свой любимый LANguard Network Scanner (см. "О сервере бедном замолвите слово"), я стал смотреть, что, собственно, у кого открыто. Уже на третьем компьютере я обнаружил MS SQL. "А почему бы и нет?" – подумалось мне, и, запустив Query Analyzer и введя адрес + sa, я нажал Enter. В тот час пинг был быстрый и через несколько секунд глаза у меня разбежались от названий баз данных, к которым я получил доступ. Почти в каждой хранилось около сотни имен пользователей, их электронные и реальные адреса, даты рождений и, конечно, пароли. Немного побродив по таблицам, я отсоединился и забыл адрес. Даже ничего не стирал и приветов не оставлял. Я хоть и хакер, но безобидный...

Вообще же, чрезвычайно весело лазить через удаленный компьютер по чужой локальной сети, подключать сетевые диски с музыкой, а потом выполнять на них что-то типа "start z:\zemfira.mp3". То-то пользователи удивяться, когда на заблокированном сервере внезапно начнет играть музыка... А есть еще командочка net send *, когда всем пользователям домена приходит сообщение от их же сервера. В общем, развлекайся – не хочу!

Рис. 4. Отправка сообщения всем пользователем удаленного домена

Шутки в сторону. Теперь задумайтесь, что можно сделать, если подходить к поиску информации осознанно. Если находить заказчиков и продавать им данные – получается промышленный шпионаж, и доступен он... практически каждому! Не надо заканчивать спецкурсы и учиться в закрытых структурах. Продвинутый школьник или студент сделает все "за таблеточку, за монеточку". Страшно.

Но всего этого можно избежать. Прислушаемся к советам Microsoft и хотя бы базу данных установим на дополнительном компьютере, не имеющем выхода в Интернет. При надобности будем обращаться к данным на другом компьютере через клиентское программное обеспечение. Пусть у нас есть, к примеру, Интернет-магазин. Можно предложить такую схему: CGI-скрипт на Web-сервере посылает запросы на сервер баз данных, используя специальную облегченную учетную запись пользователя, имеющего доступ только к таблицам магазина. Чтобы максимально защитить структуру базы, можно вместо посылки готовых запросов вызывать хранимые процедуры сервера БД. Если наш Интернет-магазин как-либо взломают, то достаточно лишь поменять пароль пользователя магазина и возможность потенциального доступа к другим таблицам сервера исчезнет. К тому же, если вызывать хранимые процедуры, то можно гораздо более независимо написать сам Интернет-магазин, да и данные он будет получать быстрее.

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

Ну а если вы уверены в своей безопасности – дайте мне свой IP, и я постараюсь проверить ее. Об оплате поговорим потом.