Защита от хакеров корпоративных сетей
Шрифт:
По большей части пользователи не осведомлены даже о существовании многочисленных проблем безопасности, не говоря уж о способах борьбы с ними. В результате неосведомленность публики и осведомленность хакеров привели к тому, что число удачных атак стало угрожающе расти.
Концепция полного раскрытия явилась попыткой решить эти проблемы. Люди, придерживающиеся данной концепции, обнародуют все детали обнаруженных ими проблем безопасности, что позволяет другим пользователям воссоздать проблемную ситуацию. Применение концепции полного раскрытия на практике имело следующие последствия.
• Прежде всего пользователи начали понимать, насколько ненадежны программные продукты, с которыми они работают.
• Во многих случаях время, в течение которого система оставалась уязвимой, было минимизировано, так как пользователи получили возможность самостоятельно тестировать свою систему в целях обнаружения проблем безопасности и быстро их устранять, вместо того чтобы ждать, пока это сделает производитель.
• Производители
• Вырос интерес к вопросам компьютерной безопасности в целом, так как теперь пользователи получили возможность учиться на ошибках других и самостоятельно искать уязвимые места различных приложений.
К сожалению, полное раскрытие имеет и отрицательную сторону. Публикация полной информации о проблемах безопасности не только позволяет действующим из лучших побуждений пользователям самостоятельно контролировать свою систему, но и дает возможность людям с менее благородными устремлениями искать уязвимые места чужих компьютеров. К сожалению, невозможно предоставлять информацию только благонамеренным лицам, поэтому одновременно происходит и обучение хакеров. Но предположим, что некоторые хакеры уже имеют доступ к информации о какой-либо уязвимости и распространяют эти сведения в своей среде. Тогда в любом случае, как с полным раскрытием, так и без него, хакеры осведомлены об этой уязвимости. По крайней мере, при полном раскрытии люди, заинтересованные в том, чтобы вовремя исправлять вновь обнаруженные изъяны, имеют шанс устранить уязвимость до того, как ею воспользуются злоумышленники.
Перед тем как сделать информацию о найденной уязвимости достоянием широкой общественности, рекомендуется связаться с производителем соответствующего программного обеспечения. В результате работа над исправлениями начнется примерно тогда же, когда пользователи узнают о существующих проблемах.
Даже в наши дни следует быть осторожным и позаботиться о том, чтобы информация об уязвимости не попала в руки злоумышленников, в то время как производитель с вашей помощью пытается решить проблему. Например, в июле 1999 года была обнаружена уязвимость службы rpc.cmsd в системе Sun Solaris. Есть подозрения, что один из вариантов использования этой уязвимости был придуман хорошо известной фирмой, специализирующейся в области компьютерной безопасности. Создавалось впечатление, что в процессе исследования этой уязвимости произошла утечка информации. Очевидно, что при таких обстоятельствах требовались особое внимание и осторожность, чтобы избежать преждевременного распространения сведений до тех пор, пока уязвимость не была устранена.
Приоткрывая завесу
Фирма Microsoft против полного раскрытия
В последнем квартале 2001 года после сообщения группы Gartner, предостерегающего против использования серверов Microsoft IIS из-за наличия многочисленных уязвимых мест, фирма Microsoft выразила свое недоверие концепции полного раскрытия. Прежде всего менеджер по безопасности фирмы Microsoft Скотт Капп (Scott Culp) написал едкую статью (www.microsoft.com/technet/treeview/default.asp?url=/ technet/columns/security/noarch.asp), в которой сравнил ее с криками «Пожар!» на театральной сцене (забыв, впрочем, указать, что в данном случае действительно происходит пожар).
Фирма Microsoft вступила в сговор с такими специализирующимися на безопасности компаниями, как Bindview, Foundstone, Guardent, @Stake и Internet Security Systems. Их объединяла общая цель – дискредитировать концепцию полного раскрытия. Вместо полного раскрытия они предложили действовать следующего образом: ввести 30-дневный буферный период, в течение которой обычные пользователи будут получать весьма неопределенную информацию о возможном возникновении проблем безопасности, в то время как члены коалиции (а также те, кто подписал соглашение об отказе от полного раскрытия) будут получать всю информацию о вновь обнаруженных уязвимостях. По истечении этого срока пользователи должны были получить более детальные сведения, но при этом предполагается, что публикация кода, использующего уязвимость, будет строго запрещена, чтобы исключить возможность его применения для атаки.
Объединение фирм планирует выпустить документ RFC с описанием нового порядка действий, согласно которому полное раскрытие будет запрещено, а сообщение о найденных уязвимостях следует направлять непосредственно производителю, не делая его достоянием широкой публики. Если этот документ будет одобрен проблемной группой проектирования Internet (Internet Engineering Task Force, IETF), с его помощью можно будет принудить независимых исследователей компьютерной безопасности следовать предписанной процедуре.
Так как в последние годы фирма Microsoft получила многочисленные негативные отзывы о безопасности разрабатываемых ими систем, которые закономерно последовали в результате успешной деятельности бесчисленных червей и компьютерных вирусов, вряд ли стоит удивляться, что они предлагают принять такой стандарт. В конце концов, если затруднить публикацию сведений об уязвимостях,
Справедливости ради стоит заметить, что выдвинутое фирмой Microsoft требование стандартизации процедуры отправки сообщений и ограничения немедленного распространения сведений о найденной уязвимости содержит рациональное зерно. Однако запрет на распространение определенной информации (например, кода, использующего уязвимость) и создание «закрытого общества» для обсуждения проблем компьютерной безопасности не служат интересам сообщества пользователей.
Когда и кому направить сообщение
Если вы хотите опубликовать сообщение о найденной вами уязвимости, необходимо определить, будет ли оно отправлено производителю или же вы сделаете его достоянием широкой публики. Также нужно проверить, достаточно ли собранной вами информации. Может оказаться, что нужно произвести дополнительные изыскания для более полного описания проблемы.
Кому направить сообщение о проблемах безопасности?
Обычно нелегко выбрать адресата, которому следует направить сообщение о проблемах безопасности, хотя вариантов и немного: вы можете проинформировать непосредственно производителя, выложить сведения в открытый форум или сразу опубликовать статью в средствах массовой информации. Проще всего сделать выбор, попытавшись понять, кто больше всего пострадает от обнаруженной вами уязвимости.
Предположим, вы обнаружили новую уязвимость некоего программного продукта или службы. Все уязвимости можно разделить на три категории в зависимости от того, в каких продуктах они находятся: это может быть узкоспециализированный (low-profile) продукт или служба, продукт или служба, рассчитанные на широкий круг пользователей (high profile), или же продукты или службы, работающие на различных платформах.
Рассмотрим подробные примеры для каждой из категорий.
• Примером узкоспециализированного продукта, рассчитанного на одну платформу, является приложение CD-Ex, предназначенное для извлечения цифровых звукозаписей. Оно используется в операционной системе Windows. Любая уязвимость этого приложения касается только его непосредственных пользователей. В таких случаях все возможные потери доходов грозят только тем, кто производит данный продукт или предоставляет данный сервис.
• Почтовый сервис Hotmail от Microsoft является примером сервиса, предназначенного для широкого использования, поскольку на этом сервисе находятся многочисленные учетные записи пользователей Интернета. Обнаруженные уязвимости окажут влияние на непосредственных потребителей данного сервиса, а если уязвимость позволяет спаммерам рассылать сообщения, то и на остальных пользователей Интернета. В данном случае использование уязвимости может нанести ущерб тем, кто предоставляет этот сервис, а также тем, кто этим сервисом пользуется.
• Примером продукта, работающего на различных платформах, является ядро Linux. Связанная с ним уязвимость касается всех пользователей, работающих с данным ядром. Также открытыми для атаки оказываются все приложения, запускаемые на этом ядре. В их число могут попасть брандмауэры и базы данных, содержащие секретную информацию. Исправление уязвимостей этого типа – очень сложное и дорогостоящее дело.
Примечание
Можно привести и другие примеры: я вовсе не хочу сказать, что именно эти продукты и сервисы являются особенно уязвимыми.
Если обнаруженная уязвимость находится в бесплатном сервисе электронной почты, таком как Hotmail, это затронет только пользователей данного сервиса. С другой стороны, если дефект обнаружен в ядре Linux, все пользователи этой операционной системы окажутся открытыми для атаки.
Вообще говоря, ваш выбор адресата сообщения об обнаруженной уязвимости должен определяться числом пользователей, которым может быть причинен ущерб. Вот список вариантов для каждой из категорий.
• Сообщение о найденной уязвимости узкоспециализированных продуктов или услуг следует отправлять производителю, а желательно также сообществу пользователей этого продукта или службы. Таким способом информируются только те, кому может принести вред найденная уязвимость. Остальные об этом не узнают и, соответственно, не станут тратить время и усилия на борьбу с дефектом, который их непосредственно не касается. Если брать приведенное в качестве примера приложение CD-Ex, то вряд ли стоит оповещать о найденной в нем уязвимости всех, кто занимается компьютерной безопасностью. Все равно большинство из этих специалистов не смогут ничем помочь в борьбе с уязвимостью конкретного приложения. Лучше направить их усилия на устранение проблем безопасности, относящихся к следующим двум категориям.