Защита от хакеров корпоративных сетей
Шрифт:
Подумайте над следующим: без всякой помощи ваша почтовая программа знает, как расшифровать пароль и отослать его (или некоторую его форму). Как она это делает? Очевидно, она знает что-то, что не знает злоумышленник, по крайней мере сейчас. Программа или знает алгоритм раскодировки, который является одинаковым для каждой копии этой программы, или знает секретный ключ расшифровки пароля, который должен храниться на вашем компьютере.
В любом случае, если действительно украдены правильный файл или файлы, то у злоумышленника есть все для определения вашего пароля даже без попытки использовать его. Если это простое декодирование, то можно определить алгоритм с использованием эксперимента и догадки или дизассемблировать часть программы, реализующей этот алгоритм и определить его.
Если программа действительно использует шифрование, то в случае кражи нужного файла или файлов и это не является гарантией безопасности. Ведь если программа может расшифровать пароль, а все действия злоумышленника по его раскодировке ни к чему не привели, то ясно, что программа где-нибудь должна хранить ключ расшифровки. Злоумышленнику следует только удостовериться в том, что файл ключа расшифровки тоже украден.
Разве программа не могла потребовать, чтобы законный пользователь помнил ключ расшифровки? Могла, но тогда почему пароль клиента запоминается в первую очередь? Только для того, чтобы пользователь не вводил пароль постоянно.
Примечание
Этот закон используется в главе 6.
Приоткрывая завесу
Будьте бдительны!
Недавно усилился интерес к обсуждению совершенных атак для выяснения причин быстрого распространения злонамеренного программного кода и увеличения числа нападений. К счастью, большинство атак ориентировано на использование уже известных уязвимостей операционных систем и программ приложений. Например, в этом году многие атаки вируса Code Red и его модификаций были нацелены на уязвимости атакованных программных средств, известные в течение длительного времени. Грустно сознавать (и это смущает как с профессиональной, так и с личной точки зрения), что целый ряд сетевых администраторов и специалистов не смогли обеспечить работоспособность своих систем, своевременно исправляя найденные в них ошибки. Ни сколь угодно длительное обучение, ни подробная документация не сможет защитить ваши системы, если вы потеряете бдительность и перестанете поддерживать высокую квалификацию в области настройки своих систем.
Закон 10. Для того чтобы система начала претендовать на статус защищенной, она должна пройти независимый аудит безопасности
Писатели знают, что они не в состоянии качественно вычитать корректуру своей собственной работы. Программисты должны знать, что они не смогут протестировать на ошибки свои собственные программы. Большинство компаний, разрабатывающих программное обеспечение, понимая это, нанимают тестировщиков программного обеспечения. Они ищут ошибки в программах, которые препятствуют выполнению заявленных функций. Это называется функциональным тестированием.
Функциональное тестирование значительно отличается от тестирования безопасности, хотя на первый взгляд это близкие понятия. Оба тестирования ищут дефекты программ, правильно? И да, и нет. Тестирование безопасности требует гораздо более глубокого анализа программы и обычно включает экспертизу исходного кода программы. Функциональное тестирование проводится для гарантии того, что большой процент пользователей сможет эксплуатировать программу без жалоб. Защититься от среднего пользователя, случайно споткнувшегося на проблеме, намного легче, чем попытаться защититься от хорошо осведомленного хакера, пытающегося взломать программу любым доступным ему способом.
Даже без подробного обсуждения того, что собой представляет аудит безопасности, его необходимость очевидна. Сколько коммерческих средств подвергается проверке безопасности? Практически ни одно. Обычно даже те немногие, которые имеют хотя бы поверхностный обзор безопасности, считаются безопасными.
Заметьте, что этот закон содержит слово «начала». Аудит безопасности – только один шаг в процессе создания безопасных систем. Для того чтобы понять, что в защите систем программного обеспечения полно недостатков, достаточно лишь ознакомиться с архивами списка отчетов любой уязвимости. Более того, можно увидеть одни и те же ошибки, неоднократно допущенные различными производителями программного обеспечения. Ясно, что это относится к классу систем, не подвергавшихся аудиту даже в минимальном объеме.
Вероятно, OpenBSD представляет собой один из наиболее интересных примеров роли аудита в разработке более безопасной системы программного обеспечения. С самого начала в проекте OpenBSD, являющемся ответвлением от главного проекта NetBSD, было решено обратить особое внимание на вопросы безопасности. Команда разработчиков OpenBSD потратила пару лет, занимаясь аудитом исходного кода для поиска и устранения ошибок. Разработчики исправляли любые найденные ошибки независимо от того, относились они к безопасности или нет. При нахождении общей ошибки они возвращались назад и просматривали все исходные коды, чтобы убедиться в том, что подобная ошибка не была сделана где-нибудь еще.
В конечном результате OpenBSD часто считается одной из наиболее безопасных операционных систем. Часто, когда обнаруживается новая ошибка в операционных системах NetBSD или FreeBSD (другой вариант BSD систем), в аналогичных условиях признается неуязвимость OpenBSD. Иногда причиной подобной неуязвимости является решение выявленной в других системах проблемы (случайно) во время обычного процесса исправления всех ошибок. В других случаях недостаток системы защиты был ранее выявлен и устранен. И в этих случаях системы NetBSD и FreeBSD (если в их составе была та же самая часть программного кода) были уязвимы, потому что никто не просматривал базу данных новых исправлений ошибок в OpenBSD (все исправления в OpenBSD обнародованы).
Примечание
Этот закон используется в главах 4, 5, 8 и 9.
Закон 11. Безопасность нельзя обеспечить покровом тайны
В основе обеспечения безопасности покровом тайны (STO – «security through obscurity») лежит идея о том, что что-то безопасно только в силу своей неочевидности, отсутствия рекламы или интереса с чьей-либо стороны. Хорошим примером является новый Web-сервер. Предположим, что вы разрабатываете новый Web-сервер, доступный пользователям сети Интернет. Вы можете подумать, что поскольку вы еще не зарегистрировали имя службы имен доменов DNS и нет пока ссылок на новый Web-сервер, то можно отложить реализацию защитных мер компьютера до начала ввода в эксплуатацию Web-сервера.
Проблема заключается в том, что сканирование портов стало постоянным явлением в Интернете. В зависимости от вашей удачи обнаружение вашего Web-сервера, вероятнее всего, – вопрос нескольких дней или даже часов. Почему разрешено сканирование портов? В большинстве случаев сканирование портов вполне законно, и большинство Интернет-провайдеров ничего не будет предпринимать в ответ на ваше заявление о том, что у вас сканировали порты.
Что может произойти в результате сканирования портов? Огромное большинство систем и пакетов программ небезопасны после их установки на компьютер. Другими словами, если вы подключаетесь к Интернету, ваш компьютер может быть относительно легко взломан, если вы не предпримите активных действий по укреплению его безопасности. Большинство злоумышленников, сканирующих порты, ищут известные им уязвимости. Если они присущи вашей системе, то у злоумышленников найдется программа, которая скомпрометирует Web-сервер за секунды. Если удача сопутствует вам, вы обнаружите сканирование портов. Если нет, вы могли бы продолжать «защищать» хост и только позже выяснить, что злоумышленник оставил лазейку (backdoor), которую вы не смогли заблокировать, потому что к этому времени были скомпрометированы.