From: "Vladimir V. Kratenko" To: Subject: Security vs security Date: Thu, 29 Apr 1999 21:12:13 +0400 Уважаемый Павел! Ваша статья "Безопасность против безопасности" безусловно интересна. Многие из затронутых Вами вопросов должны направить администраторов безопасности сетей на поиск возможных противоречий при организации защиты сети. Однако, по существу, многие из поднятых Вами аспектов безопасности лежат скорее в области религии (!), чем в области науки. "Религией" я называю веру в существование неких событий, хотя и имеющих отражение в реальной действительности, но не поддающихся разумному контролю с точки зрения безопасности. 1. Позвольте привести выдержку из вашей статьи: "История компьютерной безопасности полна примеров... в противоречие с требованиями безопасности, и безопасность проигрывала." Собственно в этом корень проблемы. Стремление объять необъятное, воплотить в своей системе все новшества современной технологии (читай, максимум сервиса) лежит в основе атак "отказ в обслуживании". Именно, атаки типа "отказ в обслуживании" и лежат в области религии. По-существу, атака "отказ в обслуживании" основана на неспособности (вызванной проблемами производительности, нерационального администрирования и т.п.) системы обеспечивать заявленную производительность сервиса. Т.е. этим я хочу сказать, что речь идет не об уязвимости механизмов защиты системы, а о несбалансированности взаимных требований по производительности (но не безопасности) и уровню предоставляемого сервиса. Несмотря на то, что это может показаться перефразированием вашего подхода, это однюдь не одно и то же. 2. "...лицо, ответственное за это, имеет возможность настроить систему на больший или меньший уровень защищенности, но часто жертвует безопасностью в угоду тому же удобству пользователей..." Это "лицо" в первую очередь жертвует безопасностью в угоду себе, а не пользователям (либо в угоду собственному кошельку). В подтверждение этой мысли приведу Ваш "Пример 3. Новый "нюк" (nuke) - система аудита Windows NT." Рекомендации ВМФ США выглядят как раз не здравомыслием, а глупостью (предпочтение менее опасной угрозы более опасной). Не случайно вы упоминаете "ленивого, но педантичного администратора". С точки зрения безопасности его можно скорее назвать "ленивым, педантичным, но неглупым оператором". Лень в данном случае заключается в том, что администратор может настолько забросить свою систему, что в его отсутствие произойдет переполнение журнала безопасности. Существуют разумные способы баланса подробности аудита, размера журнала безопасности и периодичности его очистки. А вот потеря жизненно важных событий безопасности во многих системах является недопустимой. Пойдем далее. Приводимый пример 3 содержит неточности и противоречия, в отношении которых можно заметить следующее: а) Утилита C2Config представляет из себя настройку системы точно таким же образом, как она производилась при проведении тестовых испытаний и не более. б) Windows NT 4.0 никогда не была сертифицирована на уровень защиты C2. в) Какой к шуту хакер? Забыли? Нет никакой сети! 3. Пример 1 удачен. Слава Богу, что в других "несертифицированных для сети" осях этот вопрос решается по другому. 4. Пример 2 явно неудачен. Неслучайно, пользователь при смене пароля вводит старый. Новый хэш шифруется старым. Пример с SYSCON показателен, но это частный случай, как говорят американцы "bad security practice". Смена паролей обязательна для защищенных систем, во избежание накопления информации при "brute force" атаках, подглядывании через плечо и т.д. Вообще, чем длиннее пароль, тем реже можно его менять. 5. Пример из области религии (см. выше). Существуют простейшие меры - воспитание пользователей, и более дорогие, но эффективные - магнитные карты, идентификаторы, PIN коды, биосистемы и пр. Зачем убеждать пользователей (тем более администраторов), что 6-символьные пароли эффективнее 8-символьных? 6. Пример 5 вообще полная ерунда. С точки зрения системы шифрования, "хорошие" и "плохие" пакеты - это одна песня. Если уровень производительности системы не позволяет справляться с "плохим" трафиком, часть которого система отсеивает "по внешнему виду", то он (уровень) и подавно не справится с "хорошим трафиком" такой же интенсивности. Поэтому, пример, который побудил Вас написать эту статью, по сути, является единственным приведенным примером "противоречий между защитными механизмами одного модуля системы и другого, влияний защиты от некоторого класса угроз на успешность осуществления других". Все же я почти согласен с Вашим итогом "Просто при каждом решении, направленным на борьбу с некоторой угрозой, надо тщательно проанализировать, как это решение скажется на других угрозах.", если бы Вы не трактовали понятие угрозы столь широко. Хотя, конечно, паранойа - не самое вредное заболевание для администратора безопасности. :))) Сам такой. :))) Стоило заметить, что существуют продуманные, эффективные способы осуществления безопасности, но ВСЕ они включают комплексный подход и ВСЕ они дорогого стоят (не обязательно в денежном выражении). Возможности самих по себе операционных систем сильно ограничены, иначе их стоимость достигала бы заоблачных высот. Но это уже другая тема. Главное, что ваша статья прорежет дополнительные извилины в головах администраторов систем. Искренне Ваш, Владимир Кратенко.