О сервере бедном замолвите слово - 2

Статья "О сервере бедном замолвите слово…" ("КТ" #406) вызвала большой интерес читателей, поэтому я решил продолжить эту тему - тем более что кроме 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. Да, помните, я говорил в начале статьи, что если взломан ³ один сервис, то могут быть взломаны и все остальные? Сейчас я докажу это!

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

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

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

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

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

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

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

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

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

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

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

[i41738]