Безопасность
Категория: Безопасность | Автор: admin | 11-06-2010, 17:44

Разработчики операционной системы UNIX не придавали особого значения вопросам защиты, и по этой причине ни одну из UNIX-систем нельзя сделать по-настоящему безопасной. На протяжении всей истории UNIX-систем их регулярно взламывают, портят, увечат, а также незаконно присваивают и модифицируют данные. С появлением сети Internet начался новый этап этой "холодной войны".

Кое-что для повышения надежности UNIX-системы, разумеется, сделать можно. Но полная нирвана безопасности все же недостижима, ибо в модели UNIX есть несколько фундаментальных изъянов, которые невозможно устранить.

  • ОС UNIX ориентирована прежде всего на удобство в применении, что отнюдь не предполагает естественность и простоту ее защиты. Эту систему разрабатывали исследователи для исследователей, и концепция UNIX заключается в обеспечении удобного манипулирования данными в сетевой многопользовательской среде.

  • Стратегия защиты в UNIX, по сути, предполагает всего два статуса пользователя: пользователь, не обладающий привилегиями, и суперпользователь. Такая возможность UNIX, как выполнение программ с установленным битом смены идентификатора пользователя, обеспечивает привилегированный доступ ко всем вычислительным ресурсам системы. При этом из-за незначительных огрехов в защите может быть поставлено под угрозу нормальное функционирование системы как таковой.

  • Большинство административных функций реализовано вне ядра, поэтому к ним можно без особого труда получить доступ с целью просмотра и внесения изменений. Это открывает широкое поле деятельности для хакеров.

Первое издание этой книги вышло в свет всего несколько месяцев спустя после появления в сети Internet знаменитого "червя" (1988 г.). Это событие, которое застало врасплох очень многие организации (в том числе и наш университет), получило широкую огласку. Тогда казалось, что Роберт Моррис-младший (Robert Morris, Jr.), автор программы-"червя", навлек страшнейшее бедствие на все сообщество Internet.

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

В системе защиты UNIX существует множество всем известных изъянов, которые никогда не будут устранены, и просчетов, которые одни производители устранили, а другие — нет. Помимо этого, многие организации на одну-две версии программного обеспечения отстают: либо по причине сложности локализации, либо потому, что они не заключили с поставщиком договор о сопровождении системы. Если производитель заткнул маленькую дырочку в системе защиты, это не означает, что окно для взлома исчезнет на следующий же день.

Раньше считалось, что по мере выявления и устранения брешей безопасность операционной системы UNIX будет непрерывно повышаться. Суровая реальность оказалась иной. Сложность системного программного обеспечения стремительно растет, хакерская деятельность все больше приобретает черты организованной преступности, компьютеры оказываются все более тесно связанными посредством сети Internet. Война переходит в новые измерения, и, похоже, победителей не будет.

Запомните такую формулу:

Безопасность = 1/(1,072 х Удобство)

 

Чем безопаснее система, тем труднее в ней работать пользователям.


Просмотров: 2385 | | Комментариев: 0
  Семь правил защиты
Категория: Безопасность | Автор: admin | 11-06-2010, 17:48

Эффективная система безопасности должна базироваться на здравом смысле. Она во многом напоминает борьбу с грызунами в доме. Вот семь правил, которые при этом следует соблюдать.

  • Не оставляйте на ночь на кухонном столе то, что может привлечь грызунов. Лучшие лакомства для них — сыр и масло.

  • Заткните все дыры, через которые грызуны обычно попадают в дом. Если они не залезут внутрь, то не смогут вас побеспокоить.

  • Позаботьтесь о том, чтобы в доме не было мест, где грызуны могли бы вывести потомство. Мыши любят устраивать гнезда в кучах тряпья.

  • Расставьте вдоль стен, в тех местах, где вы хотя бы раз видели мышь, мышеловки.

  • Каждый день проверяйте мышеловки, меняйте приманки и выбрасывайте дохлых грызунов. В заполненные мышеловки грызуны уже не попадают, в частности, из-за плохого запаха.

  • Избегайте ядовитых приманок. Отравленные грызуны могут навсегда остаться в стенах дома. Кроме того, есть риск, что отравится ваша собака. Лучше всего пользоваться традиционными мышеловками.

  • Заведите кота!

Этими же семью правилами (с незначительными корректировками) можно с успехом руководствоваться при организации защиты UNIX-систем. Вот как они звучат применительно к UNIX.

  • Не оставляйте без присмотра файлы, которые могут представлять интерес для хакеров и не в меру любопытных сослуживцев. Коммерческие тайны, персональные досье, бухгалтерские ведомости, результаты выборов и т.д. — за всем этим нужен глаз да глаз. Гораздо надежнее зашифровать данные, чем просто пытаться предотвратить к ним несанкционированный доступ.

В организации должен существовать порядок работы с секретной информацией. Некоторые рекомендации по этому поводу даны в главе 27 и документе RFC2196.

  • Затыкайте "дырки", через которые хакеры могут получить доступ к системе. Читайте бюллетени фирм-производителей и списки рассылки по вопросам защиты, чтобы своевременно узнавать о выходе "заплат". Отключите ненужные сервисы.

  • Сделайте так, чтобы в системе не было мест, где хакеры могли бы закрепиться. Хакеры часто вламываются в одну систему, а затем используют ее как базу для операций по взлому других систем. Анонимные FTP-каталоги с возможностью записи, групповые учетные записи, учетные записи с плохо подобранными паролями — вот основные уязвимые места.

  • Устанавливайте ловушки для обнаружения фактов или попыток вторже­ния. Такие средства, как tripwire, tcpd и crack (описаны в параграфе 21.7), помогут предупредить возможные проблемы.

  • Следите за отчетами, которые генерируются этими программами. Незна­чительная проблема, проигнорированная в отчете, к моменту получения следующего отчета может перерасти в катастрофу.

  • Учитесь защищать UNIX-системы своими силами. Иначе вам не изба­виться от различного рода высокооплачиваемых "консультантов" по вопросам безопасности, которые будут пугать вас и ваших руководителей леденящими душу рассказами о том, насколько беззащитны ваши системы. Такие специалисты обучены грамотно доказывать, почему вам нужно вложить "всего" 50000$ в обеспечение полной безопасности системы.

К сожалению, после таких благодетелей внутри системы часто остаются дохлые мыши, из-за которых производительность работы пользователей падает до нуля. Так что защита системы должна базироваться на традиционных технологиях и здравом смысле.

  • Постоянно следите за тем, не появились ли отклонения от нормального хода работы системы. Обращайте внимание на все необычное, например на непонятные журнальные сообщения или изменение характера исполь­зования какой-либо учетной записи (резкое усиление активности, работа в необычное время, работа во время отпуска владельца учетной записи).

Просмотров: 2461 | | Комментариев: 0
  Слабые места в системе безопасности
Категория: Безопасность | Автор: admin | 11-06-2010, 17:51

В последующих параграфах рассматриваются некоторые наиболее распространенные проблемы, связанные с безопасностью UNIX-систем, и стандартные контрмеры, позволяющие избежать этих проблем. Но прежде чем погрузиться в детали, необходимо взглянуть на ситуацию в целом и определить основные источники неприятностей.

  • Человеческий фактор. Пользователи (и администраторы) системы часто являются ее слабейшим звеном. Например, компания America Online печально прославилась тем, что ее многократно атаковали хакеры, притворявшиеся служащими компании. Они посылали письма потенциальным жертвам с просьбой выслать пароли для "системного теста" или "плановой проверки учетной записи". Наивные пользователи часто выполняли такие просьбы (некоторые до сих пор так делают). Есть масса разновидностей подобного шарлатанства. Одна из задач системного администратора состоит в обучении пользователей правилам техники безопасности. Многие пользователи, начиная работать в Internet, часто не подозревают, сколько там всякого жулья. Научите их выбирать хорошие пароли и хранить их, а главное — никогда не общаться с незнакомцами! Не забудьте в своих наставлениях упомянуть об неэлектронных средствах коммуникации: в умелых руках телефон тоже может оказаться опасным оружием.
  • Ошибки в программах. За много лет в программном обеспечении UNIX (включая сторонние программы, как коммерческие, так и бесплатные) было выявлено несметное число ошибок, связанных с безопасностью. Используя незаметные программистские просчеты или архитектурные зависимости, хакерам удавалось манипулировать системой по своему усмотрению. Что может сделать в этом случае администратор? Немногое, по крайней мере до тех пор, пока ошибка не будет выявлена, а разработчик не исправит ее или не выпустит "заплату". Быть в курсе последних событий — святая обязанность администратора.


Просмотров: 2537 | Подробнее... | Комментариев: 0
  Проблемы защиты файла /etc/passwd
Категория: Безопасность | Автор: admin | 11-06-2010, 18:02

В файле /etc/passwd (в некоторых системах также в файле /etc/shadow) содержатся сведения о том, кто может входить в систему и что он при этом имеет право в ней делать. Такой файл следует рассматривать как передовую линию защиты системы от захватчиков. Его нужно вести с особой тщательностью, стараясь не допускать ошибок и не загромождать устаревшими данными.

Во FreeBSD файл /etc/passwd генерируется на основании файла /etc/master.passwd и не должен редактироваться напрямую. Тем не менее не помешает в одинаковой мере защищать оба файла. О файле /etc/master.passwd рассказывалось в параграфе 6.2.

Проверка и выбор паролей

Регулярно (желательно каждый день) проверяйте, все ли учетные записи имеют пароль. В элементах файла /etc/passwd, содержащих описания псевдопользователей наподобие daemon (такие псевдопользователи являются владельцами некоторых системных файлов, но они никогда не регистрируются в системе), в поле пароля должна стоять звездочка (*). Она не соответствует ни одному паролю и, таким образом, предотвратит использование учетной записи.

Просмотров: 4541 | Подробнее... | Комментариев: 0
  Программы с установленным битом смены идентификатора пользователя
Категория: Безопасность | Автор: admin | 11-06-2010, 18:05

Программы, которые запускаются с измененным идентификатором пользователя, особенно те, для которых установлен идентификатор пользователя root, являются источником проблем, связанных с безопасностью системы. Теоретически команды с установленным битом SUID (Set User ID — смена идентификатора пользователя), поставляемые вместе с операционной системой, являются безопасными. Тем не менее огрехи в защите обнаруживались в прошлом и, несомненно, будут обнаруживаться в будущем.

Самый надежный способ уменьшения количества проблем, вызванных сменой идентификатора, — это сведение к минимуму числа программ с установленным битом SUID. Подумайте дважды, прежде чем инсталлировать такую программу, и вообще избегайте задания этого бита в собственных программах.

Особенно подвержены всякого рода проблемам сценарии интерпретатора команд. Они автоматически ставят систему под угрозу. Интерпретаторы допускают множество способов настройки, поэтому их легко обмануть. Интерпретатор, запускаемый для выполнения сценария, не всегда читает пользовательские файлы конфигурации, но есть и другие способы воздействия на него: посредством пользовательских переменных среды, содержимого текущего каталога, способа вызова сценария и т.д.

Не существуют правила, гласящего, что программы с установленным битом SUID должны запускаться от имени суперпользователя. Если нужно всего лишь ограничить доступ к файлу или базе данных, достаточно добавить в файл /etc/passwd псевдопользователя, единственное назначение которого будет заключаться во владении требуемыми ресурсами. Следуйте обычным соглашениям о добавлении псевдопользователей: используйте низкое значение UID, поставьте в поле пароля звездочку и сделайте начальным каталогом псевдопользователя каталог /dev/null.

Большинство систем позволяет отключать выполнение программ с установленными битами SUID и SGID (Set Group ID — смена идентификатора группы) в отдельных файловых системах с помощью опции -о nosuid команды mount. Чаще всего это файловые системы, содержащие начальные каталоги пользователей или смонтированные из ненадежных доменов.


Просмотров: 2653 | Подробнее... | Комментариев: 0


 
Логин
Пароль
 

 
Locations of visitors to this page