Антихакинг в сети. Трюки

АНТИХАКИНГ В СЕТИ. ТРЮКИ Эндрю Локхарт Москва - Санкт-Петербург - Нижний Новгород - Воронеж Новосибирск - Ростов-на-До...

Author: Локхарт Э.

5 downloads 175 Views 55MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

АНТИХАКИНГ В СЕТИ. ТРЮКИ Эндрю Локхарт

Москва - Санкт-Петербург - Нижний Новгород - Воронеж Новосибирск - Ростов-на-Дону - Екатеринбург - Самара Киев Харьков - Минск 2005

ББК 32.988.02-018-07 УДК 681.324 Л73

Л73

Локхарт Э. Антихакинг в сети. Трюки. — СПб.: Питер, 2005. — 296 с: ил. ISBN 5-469-00385-Х Интернет является не только наиболее удобным средством совместной работы, но и потенциально опасной средой. При работе в Сети ваши компьютеры могут подвергнуться атаке из любой точки планеты. Каждый день хакеры используют для рассылки спама, организации распределенных атак или иных незаконных действий обнаруженные уязвимые системы. В книге рассматриваются сто методов, которые могут помочь защитить вашу сеть от вторжения. Эти методики используются многими экспертами для защиты своих компьютеров в самых напряженных условиях работы. Книга рассчитана на пользователей с опытом работы в сети Интернет, но будет интересна всем, кто заботится о своей информационной безопасности.

ББК 32.988.02-018-07 УДК 681.324

Права на издание получены по соглашению с O'Reilly. Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав. Информация, содержащаяся в данной книге, получена из источников, рассматриваемых издательством как надежные. Тем не менее, имея в виду возможные человеческие или технические ошибки, издательство не может гарантировать абсолютную точность и полноту приводимых сведений и не несет ответственности за возможные ошибки, связанные с использованием книги.

ISBN 0596006438 (англ.) ISBN 5-469-00385-Х

© 2004 O'Reilly Media, Inc. © Перевод на русский язык ЗАО Издательский дом «Питер», 2005 © Издание на русском языке, оформление ЗАО Издательский дом «Питер», 2005

краткое содержание Об авторе

10

Вступление

13

Глава 1. Защита узла Unix

18

Глава 2. Безопасность узла Windows

. . .

Глава 3. Сетевая безопасность

63 82

Глава 4. Протоколирование

149

Глава 5. Наблюдение и выявление тенденций

171

Глава 6. Защита каналов

191

Глава 7. Обнаружение сетевого зторжения

234

Глава 8. Восстановление и ответные действия

280

Алфавитный указатель

293

Содержание Об авторе

10

Соавторы

10

Благодарности

11


13

Почему книга называется «Антихакинг в сети. Трюки»?

13

Структура книги

14

Соглашения, используемые в этой книге

15

Использование материалов книги

16

Как связаться с автором

16

От издательства

17

Глава 1. Защита узла Unix Трюк № 1. Защита точек монтирования

18 18

Трюк № 2 . Сканирование SUID-и SGID-программ

20

Трюк№3. Сканирование World-и Group-Writable-каталогов

22

Трюк № 4. Создание гибких иерархий разрешений с использованием ACL . . . 22 Трюк № 5. Защита протоколов от посторонних

25

Трюк № 6. Делегирование роли администратора

27

Трюк № 7. Автоматизация проверки зашифрованной подписи

29

Трюк № 8. Проверка наличия «слушающих» служб

31

Трюк № 9. Предотвращение привязки службы к интерфейсу

34

Трюк № 10. Ограничение службы с помощью окружения «песочницы»

35

Трюк № 1 1 . Использование proftp с MySQL

38

Трюк № 12. Предотвращение атак, направленных на повреждение стека . . . 41 Трюк № 13. Блокировка ядра с помощью grsecurlty

42

Трюк № 14. Ограничение приложений с помощью grsecurlty

46

Трюк № 15. Ограничение системных вызовов с помощью Systrace

49

Трюк № 16. Автоматизированное создание политики Systrace

52

Трюк № 17. Управление доступом с помощью РАМ

54

Трюк № 18. Среда ограниченной оболочки

58

Трюк № 19. Ограничение ресурсов пользователя и группы

60

Трюк № 20. Автоматизация обновления системы . . .

61

Содержание


7

63

Трюк № 2 1 . Проверка серверов и используемых обновлений 63 Трюк № 22. Получение списка отк эытых файлов и владеющих ими процессов 68 Трюк №23. Список запущенных служб и открытых портов 70 Трюк № 24. Включение аудита Трюк №25. Защита журналов событий

71 73

Трюк №26. Изменение максимальных размеров файлов протоколов Трюк №27. Отключение стандартных общих ресурсов . . . . Трюк № 28. Зашифровывание папки Temp Трюк № 29. Очистка файла подкачки при отключении Трюк № 30. Ограничение доступа пользователя к приложениям

73 75 76 77 79

Глава 3. Сетевая безопасность Трюк № 3 1 . Обнаружение ARP-спуфинга Трюк №32. Создайте статическую ARP-таблицу Трюк № 33. Межсетевой экран Netfilter Трюк №34. Межсетевой экран PaoketFilter ОС OpenBSD Трюк № 35. Создание шлюза с проверкой полномочий Трюк №36. Межсетевой экран в Windows Трюк № 37. Держите сеть изолированной Трюк № 38. Проверьте ваш межсетевой экран Трюк № 39. МАС-фильтрация с помощью Netfilter Трюк №40. Блокировка «снятия отпечатков пальцев» ОС Трюк № 4 1 . Обман программ удаленного определения ОС Трюк №42. Ведите учет объектов сети Трюк № 43. Проверка надежности сети Трюк №44. Синхронизация серверных часов Трюк № 45. Создание собственного сертификата полномочий Трюк № 46. Распространение СА среди клиентов Трюк №47. Шифрование IMAP и POP с помощью SSL Трюк №48. Настройка SMTP с TLS Трюк № 49. Удаленное обнаружение Ethernet-анализатора Трюк №50. Установка Apache с S3L и suEXEC Трюк № 5 1 . Защитите BIND Трюк № 52. Безопасность MySQL Трюк № 53. SFS в Unix


82 82 85 86 90 96 98 102 103 105 107 109 113 115 121 123 126 127 129 . 132 136 140 142 145

149

Трюк № 54. Запуск централизованного syslog-сервера

149

Трюк № 55. Управление syslog

151

8

Содержание Трюк № 56. Интеграция Windows в инфраструктуру syslog

153

Трюк № 57. Автоматическое обобщение протоколов

159

Трюк №58. Автоматическое наблюдение за протоколами

161

Трюк № 59. Обобщение протоколов с удаленных сайтов

163

Трюк № 60. Протоколирование деятельности пользователя за счет учета процессов

168


171

Трюк № 6 1 . Наблюдение за работоспособностью

. 172

Трюк №62. Графическое изображение тенденций

179

Трюк № 63. Использование ntop для получения статистики работы сети в реальном масштабе времени Трюк №64. Аудит сетевого трафика

181 .183

Трюк № 65. Накопление статистики с помощью правил межсетевого экрана . 186 Трюк № 66. Удаленный анализ


187

191

Трюк №67. Настройка IPsec в ОС Linux

191

Трюк №68. Настройка IPsec в ОС FreeBSD

194

Трюк №69. Настройка IPsec в ОС OpenBSD

197

Трюк № 70. Организация канала РРТР

199

Трюк № 7 1 . Адаптивное шифрование с помощью FreeS/WAN

203

Трюк №72. Перенаправление и шифрование трафика с помощью SSH

. . . 204

Трюк № 73. Быстрая регистрация в системе с помощью ключей SSH-клиента 206 Трюк № 74. Squid-прокси по SSH

208

Трюк №75. Использование SSH в качестве SOCKS-прокси

210

Трюк №76. Шифрование и создание канала для трафика с помощью SSL . . 213 Трюк № 77. Канальные соединения внутри HTTP

215

Трюк №78. Создание канала с помощью VTun и SSH

217

Трюк №79. Автоматический генератор vtund.conf

221

Трюк № 80. Создание кроссплатформной VPN .

226

Трюк № 8 1 . Канал РРР

231

Глава 7. Обнаружение сетевого вторжения

234

Трюк № 82. Обнаружение вторжения с помощью Snort

234

Трюк № 83. Отслеживайте сигналы тревоги

238

Трюк № 84. Наблюдение в реальном режиме времени

241

Трюк № 85. Управление датчиками

247

Трюк № 86. Создание собственных правил Snort

253

Содержание

9

Трюк № 87. Предотвращение и сдерживание вторжений с помощью Snortjnline

257

Трюк № 88. Автоматизированная динамическая фильтрация пакетов с помощью SnortSam

260

Трюк № 89. Обнаружение аномального поведения

263

Трюк № 90. Автоматическое обновление правил Snort

264

Трюк № 9 1 . Создайте сеть распределенных датчиков-невидимок

265

Трюк № 92. Использование Snort в высокопроизводительной среде с Barnyard

, 267

Трюк № 93. Обнаружение и предотвращение вторжений в web-приложения

269

Трюк № 94. Имитация сети с уязвимыми узлами

274

Трюк № 95. Запись деятельности «приманки»

277


280

Трюк № 96. Образ смонтированной файловой системы

280

Трюк № 97. Проверка целостности файлов и поиск скомпрометированных файлов

282

Трюк №98. Поиск скомпрометированных пакетов с помощью RPM Трюк № 99. Проверка наличия «набора суперпользователя» Трюк № 100. Поиск владельца сети

Алфавитный указатель

. . . . . 286 288 290

293

Об авторе Эндрю Локхарт (Andrew Lockhart) родился в Южной Каролине, но сейчас живет в северной части штата Колорадо, где постигает «черную магию» аудита дизассемблированных исполняемых файлов, пытаясь спасти их от смерти. Он имеет степень бакалавра наук в области компьютеров, которую получил еще в Государственном университете штата Колорадо (Colorado State University), и занимается консультированием по вопросам безопасности малого бизнеса. Основное место работы — компания Fortune 100. В свободное время он принимает участие в проекте Snort-Wireless (http://snort-wireless.org), который нацелен на добавление в популярную систему обнаружения сетевого вторжения с открытым кодом (Snort) возможности эффективной работы в беспроводных сетях.

Соавторы Представленные далее люди принимали участие в создании этой книги, предоставив свои приемы работы, рукописи и вдохновение: • Октэй Элтюнерджил (Oktay Altunergil) — основатель проекта Free Linux CD (http://www.freelinuxcd.org), участвующий также в поддержке сайта TurkPHP.com (турецкого портала РНР). Основная работа — системный администратор и РНР-программист. • Майкл Д. (Мик) Бауэр (Michael D. (Mick) Bauer) (http://mick.wjremonkeys.org) — ведущий колонки «Paranoid Penguin», посвященной безопасности, в Linux Journal. Днем он работает, защищая компьютерные сети банков от незваных посетителей. • Шуйлер Эрл (Schuyler Erie) (http://nocat.net) — разработчик в Free Software и активный сторонник свободно распространяемого программного обеспечения. Область его интересов охватывает совместную работу по составлению карт, беспроводные сети, программное обеспечение для социальных и политических изменений, а также семантику Сети. Шуйлер — ведущий разработчик NoCatAuth — адаптивного портала для беспроводных сетей с открытым исходным текстом. • Боб Флик (Bob Fleck) (http://www.securesoftware.com) является директором службы безопасности компании Secure Software. Он консультирует по вопросам разработки систем безопасности и безопасности в беспроводных сетях, а также является соавтором книги «802.11 Security» (издательство O'Reilly). Результаты его самых последний исследований по вопросам защиты системы Bluetooth можно найти на сайте http://bluetooth.shmoo.com.

Благодарности

11

• Роб Фликингер (Rob Flickenger) (http://nocat.net) — автор и редактор серии книг, посвященных защите от взлома (издательство O'Reilly). В настоящее время он досконально изучает возможности защиты от взлома в различных проектах, а также занимается продвижением сообщества беспроводных сетей. •

Майкл Лукас (Michael Lucas) (http://www.blackhelicopters.org/~mwlucas) живет в доме с привидениями в Детройте (штат Мичиган) со своей женой Лиз, разными грызунами и множеством рыб. Он любит поспорить; был библиотекарем и консультантом по вопросам безопасности, а сейчас работает конструктором сетей и системным администратором в Great Lakes Technologies Group. Он автор книг «ОС Absolute BSD», «Absolute OpenBSD» и «Cisco Routers», изданных в Desperate. В настоящее время (на момент написания данной книги — примеч. ред.) готовит книгу о NetBSD.

• Мэт Мэссир (Matt Messier) (http://www.securesoftware.com) является директором по проектированию в Secure Software и авторитетным лицом в вопросах безопасности, программированием занимается около двух десятков лет. Помимо соавторства в работе над книгами «Secure Programming Cookbook for C and C++» и «Network Security with OpenSSL» (издательство O'Reilly), Мэт является соавтором книг «Safe С String Library (SafeStr)», «XXL», «RATS» и «EGADS». • Иван Ристик (Ivan Ristic) (http://www.modsecurity.org) — специалист по безопасности в Сети и автор модуля mod_security — механизма обнаружения вторжения и его предотвращения для web-приложений с открытым исходным кодом. Он является членом комитета OASIS Web Application Security Technical Committee, в котором занимается разработкой стандартов защиты web-приложений. • Джон Вига (John Viega) (http://www.securesoftware.com/) — основатель и главный технолог компании Secure Software. Он также является соавтором нескольких книг по безопасности программного обеспечения, включая «Secure Programming Cookbook for C and C++» (издательство O'Reilly) и «Building Secure Software» (издательство Addison-Wesley). Джон отвечает за множество существующих средств защиты программного обеспечения и является автором Mailman (менеджер рассылки GNU).

Благодарности Сначала я должен поблагодарить знаменитую DJ Jackalope (известную также под именем Karen) за одобрение, поддержку и понимание, высказанные ею в ходе написания мной этой книги. Без нее я томился бы в унынии и вряд ли смог завершить свой труд.

12

Об авторе

Мне хотелось бы поблагодарить Нэта Торкингтона (Nat Torkington), который свел меня с Робом, неустрашимым (и настойчивым) редактором этой книги, а также моих родителей, которые верили в меня и позволяли в детстве разбираться с компьютерами и делать разные глупости, например читать журнал «Phrack»1. Если бы не это, возможно, я сейчас занимался бы чем-то совершенно иным.

Популярный журнал хакерской направленности (компьютеры и телефония). 17 ноября 2005 года ему исполнится 20 лет.

Вступление Нигде понятие «хакер» не истолковывается так неверно, как в сфере сетевой безопасности. И это понятно, поскольку специалисты по сетевой безопасности для проверки надежности своих сетей используют те же инструменты, которые могут применяться для запуска атаки на любую машину в Интернете. Разница между проверкой, законно проводимой системным администратором в отношении собственных машин, и взломом системы, направленным на получение несанкционированного доступа, определяется по большей части не методиками или инструментами, а преследуемой целью. Как и любая мощная часть технологии, средства безопасности по своей сути не являются «плохими» или «хорошими» — это всецело зависит от того, как они используются. Любой молоток может использоваться и для строительства стен, и для их разборки. Разница между «плохими» и «хорошими» хакерами также заключается не в средствах и технологиях, которые они используют, а в их намерениях. Разница едва различима, но очень важна. «Хорошие» хакеры выясняют, что представляет собой существующая система безопасности, и делают это с исследовательскими целями, чтобы знать, как можно разрушить такие системы. «Плохие» хакеры (более точно называемые кракерами (взломщиками)) преследуют цель получить те же знания, не уважая труд людей, которые построили эти системы или атакуемые серверы. Они используют полученные знания для разрушения этих систем с личными целями, зачастую с ущербом для систем, в которые им удалось проникнуть. Конечно же, книги об отважных технограбителях международного масштаба или прокуренных гениях с ноутбуками продаются лучше, чем книги об инженерах, обеспечивающих безопасность сетей. Поэтому понятие «хакерство» имеет в популярной прессе негативную репутацию. Так называют людей, которые взламывают системы или наносят им вред, используя компьютер в качестве оружия. Однако среди людей, занимающихся решением проблем компьютерной безопасности, понятие «взлом» используется в качестве названия быстрого «чернового» либо искусного способа их решения. Понятие «хакер» используется как комплимент при обращении к творческой личности, имеющей техническую хватку, позволяющую выполнить любую задачу в компьютерной области.

Почему книга называется «Антихакинг в сети. Трюки»? В этой книге описываются около ста мощнейших методик обеспечения безопасности. Здесь демонстрируются эффективные методы защиты серверов и сетей от искусных обходных атак. В издании приведены примеры обнаружения присутствия сетевых «злоумышленников», методы защиты ваших сетей и данных на

14


основе шифров с высокой криптоустойчивостью и даже методики закладки «ловушек» для потенциальных кракеров. Мы рассмотрим наиболее важные инструменты защиты, а также оптимальные методы их использования для обнаружения реальной полезной информации о том, что происходит в сети.

Структура книги Хотя каждый взлом индивидуален и не похож на другой, эта книга обобщает их различные варианты, используя перекрестные ссылки. Если вы найдете ссылку на что-либо интересное при обсуждении одного варианта взлома, то можете спокойно пропустить его и перейти к другому (так же как при серфинге в Интернете). Книга разделена на несколько глав, в которых рассматриваются следующие вопросы: • Глава 1. Защита узла Unix. Как известно, ОС Unix была предназначена для совместного использования информации, но не для ее защиты. Сейчас, когда в современных операционных системах средства защиты информации интегрируются непосредственно в любой сервер, эта старая истина больше не верна. Были разработаны новые функции программ и ядра, обеспечивающие более высокую степень контроля, чем обеспечивали Unix-подобные операционные системы. В первой главе демонстрируются передовые технологии повышения «прочности» Linux-, FreeBSD- и OpenBSD-серверов. • Глава 2. Безопасность узла Windows. Операционная система Windows используется в качестве серверной платформы в большинстве организаций. А поскольку именно она является основным объектом атак, администрирование таких систем может потребовать больших усилий. Эта глава охватывает множество моментов, упускаемых администраторами Windows, в частности ужесточение разрешений, аудит деятельности всех систем и исключение «дыр» в системе безопасности, имеющихся при стандартной установке Windows. • Глава 3. Сетевая безопасность. Независимо от установленной на сервере операционной системы, при подключении сети к Интернету в качестве связного используется протокол TCP/IP. Сетевые протоколы могут быть взломаны несколькими мощными и необычными способами, что приводит к возникновению широкого спектра проблем — от простого отказа в обслуживании до несанкционированного доступа со всеми привилегиями. В этой главе продемонстрированы некоторые средства и методики, используемые для атак на серверы средствами самой сети, а также методы предотвращения этих атак. • Глава 4. Протоколирование. Администраторы сетевой безопасности полностью зависят от качества протоколирования. При недостаточном объеме протоколирования вторжение может остаться незамеченным. При чрезмерном протоколировании атаки могут затеряться в потоке бесполезной информации. В четвертой главе показано, как обеспечить баланс информации, обеспечивающей все потребности администратора, за счет автоматического сбора, обработки и защиты системных журналов.

Соглашения, используемые в этой книге

15

• Глава 5. Наблюдение и выявление тенденций. Несмотря на полезность протоколирования событий системы и сканирования сети, они представляют один из результатов обработки информации, относящийся только к моменту, в который была произведена запись. Без хронологического исследования функционирования сети невозможно определить базис, относительно которого определяется, что является нормой, а какие действия вызывают сомнение. В этой главе представлен ряд инструментов и методов наблюдения за сетью и службами в течение длительного времени. Такое наблюдение позволяет изучить тенденции, которые помогут в перспективном планировании и позволят навскидку сказать: «Что-то не так». • Глава 6. Защита каналов. Как можно обеспечить безопасность связи по такому ненадежному (в плане защиты информации) каналу, как Интернет? Ответ на этот вопрос всецело зависит от методик криптоустойчивого шифрования и проверки полномочий. В этой главе вы узнаете, как реализовать мощные VPN-технологии, включая IPSec, PPTP и OpenVPN. Здесь также представлены технологии таких служб защиты, как SSL, SSH, и другие средства устойчивого кодирования. • Глава 7. Обнаружение сетевого вторжения. Как узнать, что в какой-то момент ваша сеть подвергается атаке? В то время как протоколирование событий и хронологическая статистика позволяют увидеть, что произошло что-то неординарное, существуют средства, предназначенные для оповещения (либо выполнения ответного действия) сразу при обнаружении атаки. Данная глава посвящена очень популярному инструменту NIDS tool Snort и представляет множество методик и надстроек, раскрывающих весь потенциал этого средства. Здесь вы также найдете способы настройки собственной «honeypot»-ce™ для привлечения и введения в заблуждение взломщиков системы. • Глава 8. Восстановление и ответные действия. Даже самый компетентный и внимательный администратор иногда может столкнуться с фактом проникновения в систему. Эта глава содержит предложения по проверке целостности системы, сохранения улик для последующего анализа и выслеживания лица, отсылающего нежелательный сетевой трафик.

Соглашения, используемые в этой книге В этой книге используются следующие типографские соглашения. Курсив

Так выделяются новые понятия

Моноширинный шрифт

Используется для выделения команд, параметров, ключей, переменных, атрибутов, клавиш, функций, типов, классов, пространств имен, методов, модулей, свойств, значений, объектов, событий, обработчиков событий, XML- и HTML-тегов, URL, адресов электронной почты, имен файлов, расширений файлов, путей, каталогов, демонов, программ и Unix-утилит макросов, содержимого файлов или выходных результатов выполнения команд

Моноширинный полужирный шрифт

Представлен текст, который должен быть заменен пользовательскими параметрами

IB


Использование материалов книги Эта книга призвана помочь вам выполнить свою работу. В общем случае представленный в книге программный код можно использовать в ваших программах или документации. Нет необходимости связываться с нами для получения разрешения, за исключением тех случаев, когда вы воспроизводите значительную часть кода. Например, написание программы, использующей несколько фрагментов кода, приведенного в этой книге, разрешения не требует. Продажа или иное распространение примеров — только с нашего разрешения. Ответ на вопросы путем цитирования выдержек из книги или примеров разрешения не требует. Включение значительной части текста этой книги в вашу документацию требует нашего разрешения. Мы не настаиваем на указании авторства, но будем благодарны за это. Указание авторства обычно состоит в приведении заголовка, сведений об авторе, издателе и ISBN-кода, например: «Network Security Hacks by Andrew Lockhart. Copyright 2004 O'Reilly Media, Inc., 0-596-00643-8». Если предполагается и дальнейшее использование примеров этой книги за пределами представленных здесь полномочий, не постесняйтесь связаться с нами по электронной почте: [email protected].

Как связаться с автором Ваши комментарии и вопросы, касающиеся данной книги, направляйте по адресу издателя: O'Reilly & Associates 1005 Gravenstein Highway North Sebastopol, CA 95472 (800) 998-9938 (в США или Канаде) (707) 829-0515 (для международной или местной связи) (707) 829-0104 (факс) Этой книге посвящен web-сайт, содержащий список опечаток1 и дополнительную информацию. Этот сайт расположен по адресу: http://www.oreilly.com/catalog/netsechacks Комментарии и вопросы, касающиеся технической стороны, направляйте по адресу: [email protected] Дополнительную информацию о книгах, конференциях, исследовательских центрах и сети O'Reilly Network вы можете найти на сайте: Список опечаток в оригинальном издании. — Примеч. ред.

От издательства

17

http://www.oreilly.com Загорелись взломом? Для изучения всех книг серии «Hacks books» в онлайновом режиме или для содействия в разработке будущих тем посетите адрес: http://hacks.oreilly.com

От издательства Ваши замечания, предложения и вопросы отправляйте по адресу электронной почты [email protected] (издательство «Питер», компьютерная редакция). Мы будем рады узнать ваше мнение! Подробную информацию о наших книгах вы найдете на web-сайте издательства: http://www.piter.com.

Г Л А В А

Понятие «работа в сети» относится ко всему, что соединяет компьютеры, поэтому компьютерная сеть не может быть более защищенной, чем компьютеры, входящие в нее. Один ненадежный узел может доставить множество проблем всей сети, поскольку если он находится под контролем противника, то может действовать как инструмент разведки либо являться плацдармом для атак. Межсетевые экраны (брандмауэры), определение вторжения и другие расширенные мероприятия защиты бесполезны, если ваши серверы представляют собой легко компрометируемые сервисы (службы). Прежде чем перейти к обеспечению безопасности, относящейся к сетевой части, сначала необходимо гарантировать, что машины, за которые вы отвечаете, максимально защищены. Эта глава предлагает множество способов сокращения рисков, связанных со службами Unix-системы. И хотя каждый из рассматриваемых трюков индивидуален, было бы желательно прочитать всю главу целиком. Если вы реализуете мероприятия защиты лишь одного типа, то в конце концов придете к тому, что вся ваша подготовка будет полностью низвергнута, как только атакующий поймет, как ее обойти. Как и Форт Нокс1, который не может быть защищен просто дверью с обычным засовом, так и одна функция защиты не сможет полностью защитить ваши серверы. Количество необходимых средств защиты должно возрастать пропорционально ценности того, что необходимо защитить. Как гласит старая поговорка: «Защита — это не имя существительное, это — глагол». Защита — это активный процесс, который должен вестись непрерывно и постоянно совершенствоваться. Защитить машину одним действием можно, лишь отключив ее. Учитывая это, рассматривайте предлагаемые технологии как начальный этап построения защищенного сервера, удовлетворяющего вашим потребностям.

Защита точек монтирования Используйте параметры команды mount, чтобы не увеличивать риск появления незваных гостей.

Основной способ взаимодействия с Unix-машиной — через файловую систему. Следовательно, когда нарушитель получил доступ к системе, желательно ограничить его возможности оперировать доступными ему файлами. Одним из Один из крупнейших военных гарнизонов армии США.

Трюк № 1. Защита точек монтирования

19

способов достичь этого является использование ограничивающих параметров монтирования. Параметр команды mount — это флаг, управляющий доступом к файловой системе. Он передается программному коду ядра операционной системы в момент подключения файловой системы. Параметры монтирования могут применяться для того, чтобы файлы не были использованы как узлы устройств (device nodes), что, в свою очередь, исключит возможность исполнения двоичного кода и отменит действие SUID-бита (с помощью флагов nodev, noexec и nosuid). С использованием параметра го файловые системы могут монтироваться доступными только для чтения. Эти параметры указываются в командной строке запуском команды mount с флагом -о. Например, если имеется отдельный раздел для каталога /tmp, то есть третий раздел первого IDE жесткого диска, вы можете смонтировать его с помощью следующей команды: # mount -о nodev,noexec,nosuid /dev/hda3 /tmp

Аналогично для /etc/fstab это будет выглядеть следующим образом: /dev/hda3/tmp ext3 defaults,nodev,noexec,nosuid 1 2 Внимательно изучив требования к разбиению носителя на множество файловых систем, вы можете использовать параметры монтирования для увеличения объема работы, которую предстоит выполнить взломщику для проникновения в систему. Самый быстрый способ сделать это — распределить дерево каталогов на области, в которые можно записывать (для нормального функционирования системы), и области, для которых операция записи не нужна. Флаг «только для чтения» можно использовать в отношении любой части файловой системы, в которой содержание меняется редко. Хорошим кандидатом для этого может быть каталог /usr в зависимости от того, насколько часто обновляется системное программное обеспечение. Понятно, что многие каталоги (такие, как /home) должны монтироваться с возможностью записи и чтения. Однако маловероятно, чтобы обычным пользователям многопользовательских систем понадобилась возможность запуска двоичных файлов SUID или создания файлов устройств в собственном домашнем каталоге. Следовательно, для размещения домашних каталогов пользователей могли бы создаваться отдельные файловые системы, монтируемые с обоими параметрами, nodev и nosuid. Кроме того, если вы определили, что пользователям не надо выполнять программы, хранящиеся в домашних каталогах, можно дополнительно использовать параметр noexec. Аналогичная ситуация возникает и с каталогами /tmp и /var, для которых крайне маловероятно, что какому-то процессу понадобится выполнить двоичные SUID- или He-SUID-файлы или обратиться к файлам устройств. Это усложняет для атакующего возможность установки «троянского коня» в общих каталогах, которыми являются /tmp и домашний каталог пользователя. Взломщик может установить программу, но не сможет запустить ее на выполнение при наличии или в отсутствие соответствующим образом установленных разрядов chmod.

20


Обратите внимание на то, что работа служб, запущенных в окружении chrootO (трюк № 10), может быть нарушена, если параметр nodev указан для файловой системы, запущенной под chroot. Вот почему узлы устройств, такие как /dev/log и /dev/null, должны быть доступны в окружении chroot(). Существует несколько способов, с помощью которых взломщик все же может обойти ограничения монтирования. Например, параметр поехес в операционной системе (ОС) Linux может быть не охвачен использованием /lib/ld-linux.so для выполнения двоичных файлов, находящихся в таких файловых системах. На первый взгляд кажется, что такое поведение можно исправить, сделав Id-linux.so неисполняемым, но из-за этого неисполняемыми станут все динамически подключаемые двоичные файлы. Поэтому если только все программы, на которые вы полагаетесь, являются статически подключаемыми (что, вероятно, не так), то параметр поехес малопригоден в Linux. Помимо этого, взломщик, который уже обладает root-привилегиями, без труда справится с файловыми системами, смонтированными со специальными параметрами, поскольку зачастую он сразу же сможет их перемонтировать командой remount с параметром -о. Но за счет использования флагов монтирования вы можете легко ограничить возможности атак, доступных недружелюбному пользователю, пока он не получил привилегии корневого каталога.

Потенциальным способом для пользователя повысить уровень привилегий в системе является исследование уязвимости SUID- и SGID-программ. SUID и SGID используются законно в тех случаях, когда программам требуются специальные разрешения, превосходящие разрешения пользователя, запускающего их. Одной из таких программ является passwd. Она позволяет пользователю изменять пароль, но одновременно не позволяет ему изменять системный файл паролей. Вот почему она должна запускаться с root-привилегиями. Таким образом, если у программы установлен разряд SUID, это означает, что она может выполняться с привилегиями владельца файла программы. А когда установлен разряд SGID, программа будет выполнена с привилегиями владельца группы файлов. Результат выполнения команды 1 s -1 в отношении двоичного файла, у которого установлен разряд SUID, будет выглядеть следующим образом: -r-s--x--x I root root 16336 Feb 13 2003 /usr/bin/passwd Обратите внимание: разряд выполнения (х) теперь имеет значение s, которое указывает, что это SUID-файл. К сожалению, неверно созданные двоичные SUID- или SGID-файлы могут быть использованы для быстрого и простого повышения привилегий пользователя.

Трюк № 2. Сканирование SUID- и SGID-программ

21

Кроме того, взломщик, который уже получил root-полномочия, может спрятать SUID-файлы по всей вашей системе, чтобы оставить лазейку для последующего доступа. Это вынуждает нас сканировать систему на наличие двоичных SUIDили SGID-файлов. Это простая задача и она может быть выполнена с помощью такой команды: # find / $ -perm -4000 -о -perm -2000 $ -type f -exec Is -la {} \;

Необходимо учесть один важный момент: является SUID-программа сценарием ядра или исполняемым файлом. Позже для кого-то может не составить труда изменить безвредный сценарий, превратив его в лазейку. Большинство операционных систем будет игнорировать любые SUID- или SGID-разряды в сценариях ядра, но, если вы хотите найти все SUID- и SGID-сценарии в системе, измените аргумент -exec в предыдущей команде и добавьте канал, так чтобы команда выглядела следующим образом: # find / $ -perm -4000 -о -perm -2000 $ \

-type f -exec file {} \; | grep -v ELF

Теперь при обнаружении любого SUID- или SGID-файла будет запускаться команда file, которая определяет тип исследуемого файла. Если он является исполняемым, его проверит grep, в противном случае он будет выведен на экран с соответствующим сообщением. Большинство операционных систем использует ELF-формат исполняемых файлов, но если вы пользуетесь операционной системой, которая этого не делает (старые версии Linux, использующие a.out, и AIX, использующие XCOFF), то вам придется заменить ELF в предыдущей команде grep двоичным форматом, используемым вашей операционной системой. Если вы точно не знаете, что ищете, запустите команду fi le в отношении любого двоичного исполняемого файла, и она выдаст строку, которую вы искали. Вот пример выполнения команды file в отношении двоичного файла в ОС Mac OS X: $ f i l e /bin/sh /bin/sh: Mach-0 executable ppc Следующим шагом вперед является создание с помощью с г on очереди команд для запуска один раз в день и перенаправления результатов ее выполнения в файл. Например, представленный далее вариант использования crontab должен сканировать файлы, у которых установлен разряд SUID ил,и SGID, сравнивать текущий список со списком, полученным днем ранее, а затем отправлять электронное сообщение о различиях между ними владельцу crontab (все это должно вводиться одной строкой): 0 4 * * * find / $ -perm -4000 -о -perm -2000 $ -type f \ > /var/log/sidlog.new && d i f f /var/log/sidlog.new /var/log/sidlog && mv /var/log/sidlog.new /var/log/sidlog В этом примере текущий список SUID- и SGID-файлов сохраняется в /var/log/sidlog.

22


Сканирование World№3 и Group-Writable-каталогов

ТРЮК

Быстрое сканирование каталогов с неопределенными разрешениями.

World- и Group-Writable-каталоги создают проблему: если пользователи системы не установили необходимым образом umask, они по неосторожности создают небезопасные файлы, полностью лишенные защиты от вторжения. Учитывая это, было бы неплохо отыскать каталоги с неопределенными разрешениями. Так же, как и сканирование SUID- и SGID-программ (трюк № 2), эту задачу можно выполнить с помощью команды fi nd: # find / -type d $ -perm -g+w -o -perm -o+w $ -exec Is -lad {} \; У любого каталога, который окажется в выходном списке, установлен sticky-разряд, что отмечено символом t в разрядах разрешения каталога. World-Writable-каталог, у которого установлен sticky-разряд, гарантирует, что, хотя создавать в нем файлы может любой человек, он не сможет удалить или изменить их. Если в выходном списке указан каталог, у которого sticky-разряд не установлен, решите, должен ли он действительно быть World-Writable либо в этой ситуации лучше использовать группы или ACL (трюк № 4). Если каталог действительно должен быть World-Writable, установите его sticky-разряд с помощью команды chmod +t. Для получения списка каталогов, у которых sticky-разряд не установлен, выполните команду # find / -type d $ -perm -g+w -о -perm -o+w $ \ -not -perm -a+t -exec Is -lad {} \;

При использовании системы, создающей уникальные группы для каждого пользователя (то есть когда создание пользователя andrew приводит к созданию группы andrew, используемой в качестве первичной группы), можно изменить команды так, чтобы они не сканировали Group-Writable-каталоги. (В противном случае вы получите огромный неудобный список.) Для этого запустите команду без раздела -perm -g+w.

Создание гибких иерархий разрешений №4 с использованием ACL

ТРЮК

Когда Unix-разрешений не хватает, используйте ACL.

Практически всегда традиционная для Unix система файловых разрешений в полной мере удовлетворяет всем требованиям безопасности. Но в среде с обширными связями, где доступ к файлам должно получать множество людей, эта схема может стать неуклюжей. Списки управления доступом (Access control lists, ACL) (иногда называемые «аклес») — это относительно новая функция операционной системы Linux, с некоторых пор доступная также в ОС FreeBSD и Solaris. Хотя ACL не обладают наследственной способностью добавлять безопасность системе,

Трюк № 4. Создание гибких иерархий разрешений с использованием ACL

23

они снижают сложность управления разрешениями. ACL обеспечивают новый способ применения разрешений в отношении файлов и каталогов, не прибегая к созданию излишних групп. ACL хранятся в метаданных файловой системы как расширенные атрибуты. Как следует из имени, ACL позволяют определять списки, как предоставляющие, так и запрещающие доступ к определенному файлу, основываясь на представленном критерии. Однако ACL вовсе не отказываются от традиционной системы разрешений. ACL могут указываться как для пользователей, так и для групп и по-прежнему подразделяются на сферы чтения, записи и выполнения. Кроме того, список управления может быть определен для любого пользователя или группы, не относящихся к любому из ACL-списков пользователя или группы, практически как «другие» разряды режима файла. Списки управления доступом также имеют то, что называется ACL-маской, действующей как маска разрешений для всех ACL, которые специально ссылаются на пользователя или группу. Это подобно команде umask, но с некоторыми отличиями. Например, если установить ACL-маску в г--, то любые ACL-списки, относящиеся к определенному пользователю или группе и более свободные в плане ограничений (то есть rw-), в действительности становятся г--. Каталог также может содержать ACL по умолчанию, который указывает исходные ACL файлов и подкаталогов, создаваемых в нем. Для изменения или удаления ACL используется команда setfacl, в которой после параметра -т следует ACL-спецификация и имя файла либо список имен файлов. Удаляется ACL с помощью параметра -х и указанием конкретного ACL или списка ACL. Существуют три общие формы ACL: одна — для пользователей, вторая — для групп и третья — для остальных. Давайте их рассмотрим: # ACL пользователя u:[user]:<mode> # ACL группы g:[group]:<mode> # Прочие ACL о:<mode> Обратите внимание на то, что в ACL пользователя и группы действительные имена пользователя и группы, к которым относится ACL, являются необязательными. Если они опущены, то этот ACL будет применяться к базовому ACL, который определяется разрядами режима файла. Следовательно, при изменении ACL будут изменены и разряды режима, и наоборот. Создайте файл и измените его базовый ACL:

Как можно заметить, список ACL можно получить с помощью команды getfacl. Эта команда очень проста и имеет лишь несколько параметров. Наиболее полезным является параметр -R, который рекурсивно выводит ACL и работает практически так же, как Is -R.

Т Р Ю К

№5

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

Действия взломщика, выполняемые в ходе внедрения, скорее всего, будут запечатлены в различных системных протоколах (журналах). Это хорошая «зацепка» для аудита, и ее необходимо защитить. Без надежных протоколов было бы очень сложно понять, как взломщик проник в систему или откуда была произведена атака. Эта информация является ключевой для анализа инцидента и используется в ходе общения участвующих в нем сторон (трюк № 100). Однако если попытка взлома оказалась успешной и нарушитель получил root-полномочия, что остановит его от удаления следов своих действий? Вот когда атрибуты файла спасают положение (или хотя бы облегчают его). В Linux- и BSD-системах имеется возможность присваивать файлам и каталогам дополнительные атрибуты. В этом состоит отличие от стандартной схемы разрешений Unix, в которой атрибуты, определенные для файла, применяются глобально ко всем пользователям системы и влияют на доступ к файлам на более низком уровне, чем разрешения файлов и ACL (см. трюк № 4). В Linux просмотреть и изменить атрибуты, установленные для определенного файла, можно с помощью команд Isattr и chattr соответственно. В BSD-системах для просмотра используется команда Is -To, а для изменения — команда chflags. На момент написания этих строк атрибуты файлов в Linux доступны только при использовании файловых систем ext2 и ext3. Также существуют обновления ядра, обеспечивающие поддержку атрибутов в XFS и rei serfs. Одним из полезных атрибутов файла протокола является append-only (только добавление). Когда установлен этот атрибут, файл невозможно удалить, допускается только добавление записей в конец файла. Для установки флага append-only в ОС Linux выполните команду . # chattr +а имя_файла

26


В BSD-системах используется следующая команда: # chflags sappnd имя_файла

Вот как работает атрибут +а (создаем файл и устанавливаем атрибут): # touch /var/log/logfile # echo "append-only not set" > /var/log/logfile # chattr +a /var/log/logfile # echo "append-only set" > /var/log/logfile bash: /var/log/logfile: Operation not permitted Вторая попытка записи была неудачной, поскольку привела к перезаписи файла. Однако добавление в конец файла по-прежнему возможно: # echo "appending to file" » /var/log/logfile # cat /var/log/logfile append-only not set appending to f i l e Очевидно, что взломщик, уже получивший root-полномочия, может понять, что используются атрибуты файла, и просто удалит атрибут append-only из протоколов с помощью команды chattr -а. Чтобы не допустить этого, необходимо отключить возможность удаления этого атрибута. Для этого в ОС Linux воспользуйтесь механизмом capabilities, а в BSD-системах — функцией securelevel. Модель capabilities (мандат) в Linux разделяет привилегии, предоставляемые «всемогущей» учетной записи root, и позволяет избирательно отключать их. Для предотвращения возможности удаления атрибута необходимо удалить мандат CAP__LINUX_IMMUTABLE. Когда в работающей системе этот мандат активен, допускается модификация атрибутов. Для модификации набора мандатов, имеющихся в системе, используется простая утилита leap (http://packetstormsecurity.org/ linux/admin/lcap-0.0.3.tar.bz2). Для распаковки и компиляции этого средства выполните команду # tar xvfj lcap-0.0.3.tar.bz2 && cd lcap-0.0.3 && make После этого для отключения возможности модификации атрибута append-only выполните:

# ./leap CAP_LINUX_IMMUTABLE # ./leap CAP_SYS_RAWIO Первая команда удаляет возможность изменения флага append-only, а вторая — мандат выполнения «сырого» ввода-вывода I/O). Это требуется для чтобы устройству, к ру» представленные re.local). IMMUTABLE. каталогам длязащищаемые незваного Дляна /dev/mem того котором Для ранее чтобы гостя, удаления файлы икоманды /dev/kmem, они избежать пытающегося нерасполагаются. этой могли в проблем сценарий возможности которые модифицироваться восстановить с (raw могли загрузки остальными Этона также бы этапе системы предоставлять мандат предотвращает доступом сценариями загрузки (то CAP_LINUX_ добавьте кесть блочному «амбразузагрузки, доступ в того, /etc/ две

Трюк № 6. Делегирование роли администратора

27

необходимо убедиться, что удаление мандатов в общем порядке загрузки выполняется позже. После того как leap удаляет мандаты ядра, они могут быть восстановлены только перезагрузкой системы. BSD-системы реализуют эту же возможность с помощью securelevels. Securelevels — это переменная ядра, которая может устанавливаться для отключения некоторой функциональности. Установка securelevels в 1 аналогична удалению двух только что рассмотренных мандатов Linux. После того как securelevels присвоено значение более 0, его невозможно понизить. По умолчанию OpenBSD в многопользовательском режиме устанавливает secure! evel в 1. Во FreeBSD securelevel устанавливается в 1 по умолчанию. Для изменения такого поведения добавьте в /etc/sysctl.conf следующую строку: kern.securelevel =1 Прежде чем сделать это, необходимо учесть, что установка флагов append-only на протоколах, скорее всего, вызовет неудачное выполнение сценариев системы хранения протоколов. Однако реализация этой возможности значительно повышает безопасность аудита, который является неоценимым при доказывании любых событий.

Делегирование роли администратора Позвольте другим выполнять вашу работу, не предоставляя им root-полномочия.

Утилита sudo поможет делегировать некоторые системные полномочия другим людям, не предоставляя им root-доступ. Команды уполномоченного пользователя (после ввода им своего текущего пароля) выполняет исполняемый root-файл setuid. Для редактирования списка пользователей, которые могут вызывать sudo, выполните команду /usr/sbin/visudo (имя root-полномочия). По умолчанию sudo-список утилиты выглядит примерно так: root ALL=(ALL) ALL К сожалению, многие системные администраторы стремятся использовать эту запись как шаблон и односторонне предоставляют неограниченный доступ остальным администраторам: root ALL=(ALL) ALL rob ALL=(ALL) ALL jim ALL=(ALL) ALL david ALL=(ALL) ALL Поскольку существует возможность предоставить root-доступ, не предоставляя root-пароль, такой метод действительно полезен, но только в тех случаях, когда полностью доверяешь всем пользователям sudo. При правильном конфигурировании утилита sudo обеспечивает потрясающую гибкость предоставления доступа к любому количеству команд, запускаемых от имени произвольного UID.

28


Синтаксис строки sudo: Пользователь Машина=(эффективный пользователь) команда

Первый параметр определяет пользователя sudo. Следующий параметр — узел, для которого этот sudo-элемент является действительным. Такое уточнение позволяет использовать одну sudo-конфигурацию на множестве машин. Предположим, что имеется разработчик, которому необходимо предоставить root-доступ только на машине разработки, но ни на одном из серверов: peter beta.oreillynet.conHALL) ALL Справа (в скобках) указывается эффективный пользователь, который может запускать определенные команды. Это очень удобно при предоставлении кому-либо возможности выполнения программного кода в качестве пользователя, не являющегося root-пользователем: peter lists.oreillynet.conHmailman) ALL И наконец, последний параметр позволяет указать все команды, которые может запускать этот пользователь: david ns.oreillynet.com=(bind) /usr/sbin/rndc./usr/sbin/named Если вы заметили, что вам приходится указывать слишком большой список команд (либо пользователей и машин), то можете воспользоваться синтаксисом псевдонимов sudo. Псевдоним (Alias) может использоваться на месте представляемого им элемента в любой строке sudo-конфигурации: User_Alias ADMINS=rob,jim,david User_Ali as WEBMASTERS=peter,nancy Runas_Ali as DAEMONS=bi nd,www,smmsp.i red Host_Alias WEBSERVERS=www.orei1lynet.com,www.orei1ly.com,www.per1.com Cmnd_Alias PROCS=/bin/kill,/bin/killall,/usr/bin/skill,/usr/bin/top Cmnd_A1ias APACHE=/usr/local/apache/bin/apachectl WEBMASTERS WEBSERVERS=(www) APACHE ADMINS ALL=(DAEMONS) ALL Кроме того, есть возможность вместо перечисления пользователей указывать системные группы, что позволяет любому пользователю, относящемуся к данной группе, выполнять определенные для нее команды. Перед названием группы просто необходимо добавить символ %: Uwwwadmin WEBSERVERS=(www) APACHE Теперь любой пользователь, входящий в группу wwwadmin, может выполнить apachectl как пользователь www любой машины, являющейся web-сервером. Одной из очень полезных функций является флаг NOPASSWD:. При его наличии перед выполнением команды пользователю не придется вводить пароль rob ALL=(ALL) NOPASSWD: PROCS Такая команда позволит пользователю rob, не вводя пароль, выполнять команды kill, kill all, skill и top на любой машине в качестве любого пользователя.

Трюк № 7. Автоматизация проверки зашифрованной подписи

29

И в заключение отметим, что sudo может стать удобной альтернативой для su по запуску команд при начальной загрузке без системных гс-файлов: (cd /usr/local/mysql; sudo -u mysql ./bin/safe_mysqld &) sudo -u www /usr/local/apache/bin/apachectl start Для того чтобы это работало при загрузке системы, должна присутствовать строка по умолчанию: ALL=(ALL) ALL. Используйте утилиту sudo, принимая обычные меры предосторожности, относящиеся к двоичным файлам setuid, особенно если вы позволяете sudo запускать интерактивные команды (например, редакторы) или любые компиляторы и интерпретаторы. Необходимо учитывать, что sudo-пользователь может запускать обычные команды, как и обычный пользователь. В большинстве случаев это не является проблемой, и тем не менее желательно избегать предоставления неоправданно большого доступа к root-привилегиям. Роб Фликипгер (Rob Flickenger)

Автоматизация проверки зашифрованной подписи Используйте сценарии и сервер ключей для автоматизации рутинной работы по проверке подлинности программного обеспечения.

Один из основных моментов обеспечения безопасности вашей системы — ознакомление с устанавливаемым программным обеспечением. Как правило, для внимательного изучения исходного кода всего устанавливаемого программного обеспечения не хватает времени, знаний или ресурсов. Однако проверка того, что компилируемые и устанавливаемые программы — это именно то, что подразумевал их автор, может занять много времени, которое расходуется на предотвращение широкомасштабного распространения «троянских коней». Ряд главнейших программных продуктов (tcpdump, LibPCap, Sendmail и OpenSSH) имеет версии, хотя и редко встречающиеся, содержащие «троянов». Поскольку это одно из популярных направлений атак, проверка их наличия в программном обеспечении является критически важной. Почему это является проблемой? К несчастью, проверка программы перед установкой требует лишь небольших усилий. То ли из-за лени, то ли по невежеству многие системные администраторы упускают этот критический этап. Это является классическим примером «ложной» лени, которая впоследствии может привести к необходимости выполнять значительно больший объем работ. Решить эту проблему очень сложно, поскольку это требует совместной работы программистов и распространителей. Кроме того, лень мешает и здесь: длительное время программные продукты вообще не имели подписи, позволяющей проверить загруженный программный код. Зачастую подписи доступны вместе с исходным кодом, но для проверки последнего необходимо отыскать на сайте открытый ключ, используемый для создания подписи. После нахождения открытого ключа его необходимо загрузить, проверить подлинность, добавить его в «связку ключей» и затем проверить подпись программного кода.

30


Вот как выглядит проверка подписи web-сервера Apache версии 1.3.28 с помощью GnuPG (http://www.gnupg.org): # gpg -import KEYS # gpg -verify apachej..3.28.tar.gz.asc apache_l.3.28.tar.gz gpg: Signature made Wed Jul 16 13:42:54 2003 PDT using DSA key ID 08C975E5 gpg: Good signature from "Jim Jagielski <[email protected]>" gpg: aka "Jim Jagielski <[email protected]>" gpg: aka "Jim Jagielski <[email protected]>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Fingerprint: 8B39 757B 1D8A 994D F243 3ED5 8B3A 601F 08C9 75E5 Как можно заметить, процедура проверки очень проста, но в спешке этот шаг обычно упускается. Вот где полезен рассматриваемый трюк. Используется лишь небольшой сценарий и то, что известно как сервер ключей, а это уменьшает число шагов проверки. Сервер ключей — это часть инфраструктуры криптографии с открытыми ключами, позволяющая извлекать ключи от третьей стороны, пользующейся доверием. Отличной функцией GnuPG является возможность обращения к серверам ключей за идентификаторами ключей, а также загрузки результатов в локальную «связку ключей». Чтобы разобраться, какой идентификатор ключа запрашивать, мы полагаемся на тот факт, что сообщение об ошибке, генерируемое GnuPG, при попытке проверить подписи сообщит нам, какой идентификатор ключа невозможно найти локально. В предыдущем примере, если ключ, который нужен GnuPG, перед выполнением проверки подписи не был импортирован, появится подобное сообщение: gpg: Signature made Wed Jul 16 13:42:54 2003 PDT using DSA key ID 08C975E5 gpg: Can't check signature: public key not found Представленный далее сценарий извлекает пользу из этого сообщения: #!/bin/sh VENDOR_KEYRING=vendors.gpg KEYSERVER=search.keyserver.net KEYID="Ox4gpg --verify $1 $2 2>&1 | grep 'key ID1 | awk '{print $ N F } 1 N " gpg --no-default-keyring --keyring $VENDOR_KEYRING --recv-key \ --keyserver $KEYSERVER $KEYID gpg --keyring $VENDOR_KEYRING --verify $1 $2 Первая строка сценария указывает «связку ключей», в которой должен храниться результат, полученный с сервера ключей. Можно использовать файл pubring.gpg (который для GnuGP является «связкой» по умолчанию), но использование отдельного файла облегчит управление открытыми ключами. Вторая строка сценария указывает, к какому серверу ключей произойдет обращение (сценарий использует search.keyserver.net; еще одним подходящим сервером является pgp.mit.edu). Третья строка пытается (в данном случае — неудачно) проверить подпись, не


31

проконсультировавшись с сервером ключей. Далее GnuPG использует идентификатор ключа, указанный в сообщении об ошибке, добавляет спереди an Ох для того, чтобы в следующей строке обратиться к серверу ключей. И наконец, GnuPG пытается проверить подпись и указывает «связку ключей», в которой должен храниться ключ. Этот сценарий сокращает процесс проверки, избавляя от необходимости поиска и импорта открытого ключа, использованного для генерации подписи. Возвращаясь к примеру проверки исходного кода Apache 1.3.28, можно заметить, что удобнее проверять достоверность пакета следующим образом: # check-sig apachej..3.28.tar.gz.asc apachej.. 3.28. tar. gz gpg: requesting key 08C975E5 from HKP keyserver search.keyserver.net gpg: key 08С975Б5: public key imported gpg: Total number processed: 1 gpg: imported: 1 gpg: Warning: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: Signature made Wed Jul 16 13:42:54 2003 PDT using DSA key ID 08C975E5 gpg: Good signature from "Jim Jagielski <[email protected]>" gpg: aka "Jim Jagielski <[email protected]>" gpg: aka "Jim Jagielski <[email protected]>" gpg: checking the trustdb gpg: no ultimately trusted keys found gpg: WARNING: This key is not c e r t i f i e d with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Fingerprint: 8B39 757B 1D8A 994D F243 3ED5 8B3A 601F 08C9 75E5

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

ТРЮК

№8

Проверка наличия «слушающих» служб Найдите ненужные службы-«слушатели» и возможные «потайные двери» в систему.

Сразу после установки свежей операционной системы необходимо проверить запущенные службы и удалить из процесса загрузки все ненужные службы. Можно использовать сканер портов (такой, как nmap (трюк № 42)) и запустить его для проверки узла, но если его нет, то вам придется подключить свою свежую (и, вероятно, незащищенную) машину к сети и загрузить сканер портов. Кроме того, необходимо учитывать, что nmap может быть обманут, если система использует правила межсетевого экрана (firewall). Если установлены четкие правила, служба может остаться совершенно незаметной для nmap, пока совпадает какое-либо условие (например, IP-адрес). Когда имеется доступ к самому ядру сервера, вероятно, более эффективным будет найти открытые порты с помощью

32


программ, установленных вместе с операционной системой. Одной из них является netstat — программа, выводящая сведения и статистику, относящуюся к работе сети. Для получения списка «слушающих» портов и связанных с ними процессов под Linux выполните: # netstat -luntp Active Internet connections (only Proto Recv-Q Send-Q Local Address tcp 0 0 0.0.0.0:22 udp 0 0 0.0.0.0:68

servers) Foreign Address State PID/Program name 0.0.0.0:* LISTEN 1679/sshd 0.0.0.0:* 1766/dhclient

По этому результату можно увидеть, что машина, вероятно, является рабочей станцией, поскольку для удаленного доступа она имеет лишь DHCP-клиент, запущенный совместно с SSH-демоном. Используемые порты перечислены после двоеточия в столбце Local Address (локальный адрес) (22 — для sshd и 68 — для dhclient). Отсутствие каких-либо еще «слушающих» процессов говорит о том, что это, скорее всего, рабочая станция, а не сетевой сервер. К сожалению, BSD-версия утилиты netstat не дает нам список процессов и идентификаторы процессов (PID), владеющих «слушающим» портом. Тем не менее netstat в BSD все-таки полезна для вывода списка «слушающих» портов вашей системы. Для получения списка «слушающих» портов во FreeBSD запустите команду # netstat -a -n | egrep 'Proto|LISTEN1 Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 *.587 *.* LISTEN tcp4 0 0 *.25 *.* LISTEN tcp4 0 0 *.22 *.* LISTEN tcp4 0 0 *.993 *.* LISTEN tcp4 0 0 *.143 *.* LISTEN tcp4 0 0 *.53 *.* LISTEN В столбце локального адреса снова перечислены используемые порты. Многие опытные системные администраторы помнят распространенные номера портов популярных служб и видят, что на этом сервере запущены SSH-, SMTP-, DNS-, IMAP- и IMAP+SSL-службы. Если вы все же сомневаетесь, какая служба обычно запускается на данном порте, то либо исключите ключ -п из команды netstat (он заставляет эту утилиту использовать имена, но при просмотре DNS-адресов выполнение может занять значительно больше времени), либо вручную просмотрите файл /etc/services: # grep -w 993 /etc/servicesimaps 993/udp # imap4 protocol over TLS/SSL imaps 993/tcp # imap4 protocol over TLS/SSL Обратите также внимание на то, что, в отличие от результата выполнения netstat в Linux, мы не получаем PID самих демонов. Помимо этого не перечислены UDP-порты для DNS. Для вывода UDP-сокетов необходимо в аргумент egrep добавить udp4, придав ему следующий вид: 'Proto|LISTEN|udp4'. Однако


33

из-за особенностей работы UDP не все UDP-сокеты обязательно будут связаны с процессами-демонами. В ОС FreeBSD существует другая команда, позволяющая получить необходимые сведения. Команда sockstat выполняет только малую часть того, что «умеет» netstat, и предоставляет сведения только о доменных сокетах Unix и Интернет-сокетах. Для получения списка «слушающих» портов и связанных с ними процессов запустите команду

И опять же видно, что запущены sshd-, SMTP-, DNS-, ШАР- и IMAP+SSL-службы, но теперь мы знаем процессы, владеющие сокетами, плюс их PID. Сейчас можно видеть, что IMAP-службы были порождены от inetd, а не от отдельных демонов и что работу SMTP и DNS обеспечивают sendmail и named. Для большинства прочих Unix-подобных ОС можно воспользоваться утилитой Isof (http://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/lsof/). Название Isof получено сокращением от «list open files» (список открытых файлов), и, как явствует из имени, утилита позволяет выводить список всех файлов, открытых в системе, с добавлением процессов и PID их открывших. Поскольку сокеты и файлы в Linux работают одинаково, Isof может использоваться для просмотра списка открытых сокетов (параметр -i). Для получения списка «слушающих» портов и процессов, владеющих ими, выполните команду # Isof -i -n | egrep 'COMMAND|LISTEN1 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE TCP TCP TCP TCP TCP TCP

NAME *:domain (LISTEN) *:imap (LISTEN) *:imaps (LISTEN) *:ssh (LISTEN) *:smtp (LISTEN) ^-submission (LISTEN)

Для вывода UDP-сокетов можно изменить аргумент egrep. Однако на этот раз вместо udp4 нужно использовать уточнение UDP, и аргумент примет следующий вид: C ' OMMAND| LISTEN |UDP'. Как упоминалось ранее, не все UDP-сокеты обязательно будут связаны с процессами-демонами. 2 Зак. 1103

34


Предотвращение привязки службы к интерфейсу Пускай служба не «слушает» порт, а выполняет на нем функции межсетевого экрана.

Иногда может возникнуть желание ограничить службу прослушиванием только определенного интерфейса. Например, Apache (трюк № 50) может быть настроен на прослушивание не всех доступных интерфейсов, а только определенного интерфейса. Этого можно добиться также с помощью директивы Listen, помещаемой в файл настройки с указанием IP-адреса интерфейса: Listen 192.168.0.23:80 При использовании элементов Virtual Host интерфейсы привязки можно указывать на основе виртуальных узлов: У вас даже могут быть службы, которые «слушают» TCP-порт, но не должны этого делать. Серверы баз данных, такие как MySQL, зачастую работают совместно с Apache и при этом, как правило, устанавливаются на одном сервере. Соединения, приходящие с той же машины, на которой установлен MySQL, используют для связи сокеты домена в файловой системе. Таким образом выясняется отсутствие необходимости в том, чтобы MySQL «слушал» ТСР-сокет. Для этого необходимо либо использовать при запуске MySQL параметр --skip-networking, либо указать его в разделе [mysqld] файла my.cnf: [mysqld] skip-networking Еще одной программой, которую можно найти «слушающей» порт, является XII server (по умолчанию «слушает» порт 6000). Этот порт традиционно используется для того, чтобы удаленные клиенты подключались к XII-серверу с тем, чтобы получать собственное окно, а также доступ к клавиатурному вводу и перемещению мыши. Однако после появления SSH и Xll-перенаправления в этом больше нет необходимости. Когда XII-перенаправление включено в ssh, любой клиент, которому необходимо подключиться к Xll-серверу, получит канал через SSH-coединение, и для этого вовсе не нужно «прослушивать» TCP-порт. Для того чтобы сервер X Windows прекратил «прослушивание» этого порта, необходимо всего лишь добавить в команду, используемую для запуска сервера, параметр -nol isten tcp. Это может оказаться довольно сложным: определение файла, управляющего запуском сервера, может быть очень трудоемкой задачей. Обычно необходимые команды можно найти в /etc/X11. При использовании gdm откройте файл gdm.conf и найдите подобную команду: command=/usr/XHR6/bin/X


35

После этого просто добавьте в конец строки -nolisten tcp. При использовании xdm найдите файл под названием Xservers и поищите в нем строку, подобную следующей: :0 local /usr/XHR6/bin/X -nolisten tcp Кроме того, если вы не используете управляемый дисплей, а для старта XI1-сервера используете команду startx или аналогичную, то можно просто добавить -nolisten tcp в конец команды startx. Чтобы гарантировать передачу параметра в процесс XII-сервера, укажите его через несколько дефисов: $ startx -- -nolisten tcp После старта XII запустите терминал и с помощью lsof или netstat (трюк № 8) просмотрите «слушателей». Порт 6000 теперь никто не должен слушать.

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

Иногда своевременной установки новейших обновлений недостаточно для предотвращения проникновения в систему. Зачастую новый способ прорыва долго циркулирует в частных кругах, до того как будет издано его официальное обновление. В течение этого времени ваши серверы остаются открытыми перед неожиданной атакой. Учитывая это, разумно принять превентивные меры по смягчению возможных последствий деятельности скомпрометированной службы. Один из способов достичь этого — запуск службы в окружении «песочницы» (sandbox environment). В идеальном случае скомпрометированная служба нанесет минимальный вред производительности системы. Большинство систем, использующих Unix и Unix-подобные ОС, включают определенный тип системного вызова или иной механизм организации «песочницы», предлагающий различные уровни изоляции между узлом и этой «песочницей». Менее сдерживающей и простой в настройке является среда, создаваемая командой chrootC), которая доступна практически во всех Unix-подобных ОС. Помимо 1 chrootC), ОС FreeBSD включает еще один механизм, называемый jail О , который имеет больше ограничений. С помощью команды chrootO2 очень легко меняется корневой каталог процесса и всех его наследников. Несмотря на то что это очень мощная функция, существует множество противопоказаний для ее использования. Самое главное: у всего, что исполняется в «песочнице», не должно быть возможности изменить свой EUID (effective UID) на 0, соответствующий UID корневого каталога. Естественно, это подразумевает, что вы не собираетесь запускать в «тюрьме» ничего от 1 2

Буквальный перевод: тюрьма Сокращение от change root — сменить корень.

36


имени root. Если атакующий получит root-полномочия в «песочнице», то все усилия напрасны. Хотя он не сможет напрямик прорвать окружение «песочницы», но это не удержит его от запуска функции в адресном пространстве используемого процесса, что позволит прорваться в систему. Существует множество способов взлома «песочницы» chrootО. Однако все они основываются на возможности получения root-полномочий внутри этой «песочницы». Ахиллесовой пятой сИгооШявляется возможность получения UID 0 в «песочнице». Существует ряд служб, поддерживающих среды chrootO за счет вызова этой функции из самой программы, но многие службы этого не позволяют. Для запуска таких служб внутри «песочницы» необходимо использовать команду chroot. Эта команда просто вызывает chrootO с первым аргументом командной строки и пытается выполнить программу, указанную в качестве второго аргумента. Если программа является статически связанным двоичным файлом, все, что необходимо сделать, — это скопировать программу в любое место внутри окружения «песочницы». Но если программа является динамически связываемой, то в окружение необходимо скопировать все поддерживающие ее библиотеки. В качестве примера рассмотрим запуск bash в среде chrootO. Сначала попробуем запустить chroot без копирования библиотек, необходимых bash: # mkdir -p /chroot_test/bin # ср /bin/bash /chroot_test/bin/ # chroot /chroot_test /bin/bash chroot: /bin/bash: No such f i l e or directory

Понятно, что для работы bash требуются библиотеки, которые можно найти с помощью команды Idd. После копирования библиотек снова попытаемся запустить chroot: # Idd /bin/bash libtermcap.so.2 => /lib/libtermcap.so.2 (0x4001a000) libdl.so.2 => /lib/libdl.so.2 (0x4001e000) libc.so.6 => /lib/tls/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) # mkdir -p chroot_test/lib/tls && \ > (cd /lib: \ > cp libtermcap.so.2 libdl.so.2 ld-linux.so.2 /chroot_test/lib: \ > cd tls: cp libc.so.6 /chroot_test/lib/tls) # chroot /chroot_test /bin/bash bash-2.05b# bash-2.05b# echo /* /bin /lib Настройка chroot-среды в основном состоит из попыток и ошибок при получении разрешений и приведении в порядок всех зависимых библиотек. Рассмотрите последствия помещения и других программ (таких как mknod или mount) в chroot-окружение. Если бы это было возможно, то атакующий мог бы создать узлы устройств (device nodes) для непосредственного доступа к памяти или перемонтировать файловую систему, что привело бы к прорыву «песочницы»


37

и получению полного контроля над всей системой. Эту угрозу можно уменьшить, поместив каталог на файловую систему, монтируемую с параметрами, запрещающими использование файлов-устройств (device files) (трюк № 1), хотя это не всегда приемлемо. Желательно в chroot-каталоге иметь максимально возможное количество файлов и каталогов, принадлежащих root и доступных для записи только root, что сделает невозможным для процессов изменить любой из поддерживаемых файлов (к таким файлам относятся библиотеки и файлы настройки). В общем случае лучше иметь наиболее сильно ограничивающие разрешения и ослаблять их только в случае необходимости (например, если разрешения мешают нормальной работе демона). Наилучшими кандидатами для chroot-среды являются службы, которым вообще не нужны root-полномочия. Например, MySQL по умолчанию «слушает» удаленные подключения на 3306-м порте. Поскольку номер порта больше 1024, демон mysqld может запускаться без root-привилегий, что позволит избежать риска быть использованным для получения root-доступа. Другие демоны, которым нужны root-привилегии, могут иметь параметр, позволяющий сбрасывать эти привилегии после завершения всех операций, для которых требуется root-доступ (например, привязки к порту с номером меньше 1024), но необходимо особое внимание, чтобы программа корректно сбрасывала полномочия. Если программа для сброса привилегий вместо setuidC) использует seteuidC), то по-прежнему сохраняется возможность получения root-доступа, которую может использовать атакующий. Специально изучите советы по обеспечению безопасности программ, которые запускаются только с root-привилегиями. Может показаться, что если не помещать компиляторы, оболочки или такие утилиты, как mknod, в окружение «песочницы», то их можно защитить в случае компрометации root-ограниченной среды. На самом деле атакующий может достичь такой же функциональности, сменив код из системы вызовов (/bin/sh) на вызов любой другой функции из библиотеки языка С или любой желаемый системный вызов. Если смонтировать файловую систему, которую программа из chrootокружения запускает с использованием флага «только для чтения» (см. трюк № 1), это осложнит для атакующего установку собственного программного кода, но по-прежнему не станет броней. Если демон, который надо запустить в окружении, не удовлетворяет рассматриваемым ранее условиям, вам, вероятно, захочется использовать более мощный механизм «песочницы». Один из таких механизмов доступен в ОС FreeBSD и реализуется он с помощью системного вызова jai 1 (). Этот вызов обеспечивает значительно больше ограничений при изоляции среды «песочницы» от основной системы и предоставляет дополнительные возможности, например назначение узлу IP-адресов виртуальных интерфейсов. Используя эту возможность, можно создать полностью виртуальный сервер либо просто запустить одну службу в среде «песочницы». Так же, как и в случае с chrootO, система имеет команду jail, которая использует системный вызов jail О. Базовая форма этой команды: jail new root hostname ipaddr command


Использование proftp с MySQL Убедитесь, что при использовании рассматриваемых подстроек операционная система вашей базы данных работает самым эффективным образом.

Proftpd — это мощный FTP-демон, синтаксис которого очень напоминает Apache. Он имеет огромное количество функций, недоступных в большинстве FTP-демонов, включая отношения и виртуальный хостинг, и обладает блочной структурой, позволяющей создавать собственные модули. Одним из модулей является mod_sql, позволяющий proftpd использовать базу данных SQL в качестве источника идентификации на серверной стороне. В настоящее время mod_sql поддерживают MySQL и PostgreSQL. Он является хорошим вариантом блокировки доступа к серверу, когда прибывающие пользователи идентифицируются в отношении базы данных (и, следовательно, не требуют наличия действительной учетной записи на сервере). В этом трюке мы будем использовать proftpd для проверки подлинности базы данных MySQL.

40


Строка SQLAuthTypes позволяет создавать пользователей с паролями, хранимыми в стандартном формате шифрования ОС Unix, либо функцией PASSWORD О mysql. Учтите, что при протоколировании деятельности mod_sql пароль может быть представлен в виде открытого текста, поэтому сделайте протокол недоступным для посторонних. Как указано, строка SQLAuthTypes не позволяет использовать пустые пароли. Если необходимо отключить ввод паролей, добавьте ключевое слово empty. Строки SQLMinUserGID и SQLMinUserUID указывают минимальное значение идентификатора пользователя или группы, которым proftpd разрешит регистрацию. Разумно установить это значение больше 0 (чтобы запретить регистрацию в системе с root-полномочиями), но оно должно быть как можно меньшим, чтобы обеспечить необходимые разрешения для файловой системы. В нашей системе имеются пользователь и группа с именем www, для которых uid и gid установлены равными 111. Поскольку нам необходимо обеспечить возможность регистрации в системе web-дизайнеров, в качестве минимальных значений указано 111. В заключение можно создать пользователей в БД. Представленная далее команда создает пользователя jimbo с эффективными правами пользователя www/www и переносит его после регистрации в системе в каталог /usr/local/apache/htdocs/: mysql -e "insert into users values ('jimbo' ,PASSWORD(' sHHH'), ' И Г , \ '11Г, Vusr/local/apache/htdocs','/bin/bash 1 );" proftpd Пароль для пользователя jimbo перед сохранением шифруется с помощью функции PASSWORDC) mysql. Строка /bin/bash передана в proftpd для передачи директиве Requi reVal idShel 1. Это не приводит к предоставлению пользователю jimbo действительного доступа к оболочке. В данный момент должна быть возможность запустить proftpd и зарегистрироваться в системе как пользователь jimbo с паролем sHHH. Если возникли проблемы с подключением, попробуйте запустить proftpd в фоновом режиме с включением режима отладки: # proftpd -n -d 5 Просмотрите сообщения, появляющиеся в ходе подключения, и вы сможете найти источник проблем. Опираясь на свой опыт, могу сказать, что почти всегда сбой возникает из-за неверной настройки proftpd.conf, как правило, относящейся к разрешениям. Модуль mod_sql может использоваться значительно шире. Можно подключать его к существующей mysql-БД со случайными именами таблиц, протоколировать все операции в БД, изменять поиск пользователей с помощью произвольного выражения WHERE и т. п. СМОТРИ ТАКЖЕ Домашняя страница модуля mod_sql располагается по адресу: http://www. lastditcheffort.org/~aah/proftpd/mod_sql/. Домашняя страница модуля proftpd: http://www.proftpd.org/. Роб Фликингер (Rob Flickenger) «Linux Server Hacks» («Трюки сервера Linux»)

Трюк № 12. Предотвращение атак, направленных на повреждение стека

41

Предотвращение атак, направленных на повреждение стека Научитесь предотвращать атаки переполнения буфера стека.

В С и C++ локальные переменные хранятся в области памяти, называемой стеком. Сведения, касающиеся управления последовательностью выполнения программы (flow of a program), также обслуживаются стеком. Если массив размещается в стеке, а затем стек переполняется (то есть в массив помещается значений больше, чем может вместить выделенное пространство), атакующий может перезаписать сведения управления последовательностью выполнения программы (поток программы). Такой тип атаки зачастую называется крушением стека (stack-smashing attack). Такие атаки представляют собой серьезную проблему, поскольку безвредная служба (web-сервер или FTP-сервер) может выполнять непредсказуемые команды. Уже разработано несколько технологий, позволяющих защитить программы от подобного рода атак. Некоторые из них реализованы в компиляторе, например ProPolice (http://www.trl.jbm.com/projects/security/ssp/) или альтернативный вариант Stackguard (http://www.immunix.org/stackguard.html) версии GCC, Другие являются динамическим решением, действующим во время работы сервера, например LibSafe (http://www.research.avayalabs.com/project/libsafe/). И хотя перекомпиляция исходного текста программы наносит сокрушительный удар по атаке переполнения буфера, решения времени выполнения (runtime solutions) позволяют защитить программы в тех случаях, когда исходный код недоступен либо перекомпиляция просто невозможна. Все решения уровня компилятора работают примерно одинаково, хотя в реализациях имеются и некоторые различия. Их работа основана на помещении в стек между информацией управления потоком и локальными переменными так называемой «канарейки» (некоторого произвольного значения). Программный код, который обычно генерируется компилятором для возврата из функции, изменяется таким образом, чтобы он выполнял проверку значения «канарейки» в стеке. Если это значение не совпадает с ожидаемым, то программа немедленно завершается. Идея использования «канарейки» основана на том, что атакующему для перезаписи информации управления потоком необходимо провести атаку на стек, «перезаписав» «канарейку». Атакующий не сможет предсказать совершенно случайного значения «канарейки» и, следовательно, не сможет использовать ее в данных для «крушения» стека. Когда программа распространяется в форме исходного текста, разработчик программы не может гарантировать использование StackGuard или ProPolice, поскольку они не являются стандартными расширениями компилятора GCC. Их использование лежит на совести лица, выполняющего компиляцию. Для Linux-систем технология LibSafe (от Avaya Labs) реализована независимо от компилятора, но она использует динамический загрузчик, предварительно

42


загружающий динамические библиотеки для каждого исполняемого файла. Использование LibSafe не требует исходного кода защищаемой программы и может разворачиваться по всей системе. LibSafe заменяет реализации некоторых стандартных функций, уязвимость которых от переполнения буфера известна (gets(), strcpy() и scanf()). Замена реализаций пытается вычислить максимально возможный размер статически выделяемого буфера, используемого в качестве буфера назначения при записи, с помощью встроенной функции GCC, возвращающей адрес указателя фрейма. Этот адрес обычно является первым блоком информации в стеке, следующим за локальными переменными. Если будет предпринята попытка записать больше, чем расчетный размер буфера, программа будет завершена. К сожалению, с подходом, используемым в LibSafe, связано несколько проблем. Во-первых, невозможно точно вычислить размер буфера. Самое лучшее, что можно сделать, — это ограничить размер буфера от начала буфера до указателя фрейма. Во-вторых, защита LibSafe не будет работать с программами, которые были откомпилированы GCC с флагом -fomit-frame-pointer. Выполненная компилятором оптимизация не помещает в стек указатель фрейма. Несмотря на относительную бесполезность, такая оптимизация популярна у программистов. И наконец, LibSafe не будет работать в отношении двоичных SUID-файлов без статического связывания или аналогичной уловки. Помимо обеспечения защиты от обычных атак взлома стека, новейшие версии LibSafe могут противостоять некоторым атакам, основанным на искажении формата строки (format-string attacks). Защита от таких атак требует доступа к указателю фрейма, поскольку она пытается отфильтровать аргументы, не являющиеся ни указателями на «кучу» (heap), ни указателями на локальные переменные в стеке. Помимо использования решений в пространстве пользователя (user-space solutions), вы можете предпочесть обновить ядро, сделав стек неисполняемым и добавив функцию обнаружения атак переполнения буфера (трюк № 13).

Повышение стойкости Unix-системы может быть довольно сложным процессом. Он обычно включает настройку всех служб, которые система должна запускать наиболее безопасным способом, а также блокировку системы для предотвращения локальных проникновений. Однако обеспечение безопасности запущенных служб не связано с защитой остальной системы и ее неизвестных слабых мест. К счастью, хотя ядро Linux и предоставляет несколько функций превентивной защиты системы, существуют обновления, помогающие системному администратору в полной мере реализовать их. Одним из таких обновлений является grsecurity (http://www.grsecurity.net).

Трюк № 13. Блокировка ядра с помощью grsecurity

43

Grsecurity входит в состав обновления OpenWall (http://www.openwall.com) для серий 2.4.x ядра Linux. Это обновление добавляет такие функции, как неисполняемый стек, улучшение защиты файловой системы, ограничение доступа к /ргос, а также ограничение доступа к ресурсам. Эти функции помогают защитить систему от атак, основанных на переполнении буфера стека, атак на файловую систему, включая «соревнование» файлов в каталоге /temp. Теперь пользователь может просматривать только свои процессы, а доступ к ресурсам за счет выполнения большего числа проверок ограничен. С момента появления обновление grsecurity значительно разрослось, вобрав в себя множество функций, которых не было в обновлении OpenWall. Теперь Grsecurity включает дополнительные варианты защиты адресного пространства, предотвращающие атаки переполнения буфера, а также улучшенные ограничения сред chrootO, jail, увеличенную степень случайности идентификаторов процессов и IP, а также расширение функций аудита, позволяющих отслеживать каждый процесс, выполняемый в системе. Grsecurity добавляет усовершенствованную систему ACL (access control list). Эта система может использоваться для ограничения привилегированных операций, которые могут выполняться отдельными процессами. Конфигурация ACL обрабатывается с помощью утилиты gradm. Если вы уже установили на машине grsecurity, то можете спокойно перейти к трюку № 14. Для компиляции ядра с grsecurity необходимо загрузить обновление (исправление), соответствующее версии ядра, и применить его с помощью утилиты исправления (patch). Например, если установлена ОС Linux 2.4.24, это делается с помощью команд: # cd /usr/src/linux-2.4.24 # patch -pi < ~andrew/grsecurity-1.9.13-2.4.24.patch При выполнении команды в каждой строке будет выводиться результат обновления каждого файла исходного кода ядра. По завершении выполнения необходимо убедиться в том, что обновление прошло без ошибок, о чем свидетельствует отсутствие файлов с расширением .rej. Они создаются программой patch при невозможности выполнения исправления. Проверка наличия этих файлов выполняется командой # find ./ -name \*.rej При наличии «отклоненных» (rejected) файлов их список будет выведен на экран. После успешного выполнения обновления вы просто вернетесь в командную строку оболочки. После завершения обновления настройка ядра на использование функций grsecurity осуществляется с помощью команд make config в текстовом приглашении командной строки, make menuconfig в curses-based-интерфейсе или make xconfig при использовании графического интерфейса (GUI), основанного на Тк. Если вы пошли путем использования графического интерфейса, то, воспользовавшись командой make xconfig, вы увидите диалоговое окно, представленное на рис. 1.1. При запуске make config или make menuconfig параметры ядра будут иметь те же имена, что и пункты меню, описываемые далее в этом примере. Для настройки функций grsecurity, которые будут доступны в ядре, щелкните на одноименной кнопке. После этого появится диалоговое окно (рис. 1.2).

44


Рис. 1.2. Диалоговое окно настройки grsecurity

Для включения grsecurity щелкните на переключателе у. После этого в раскрывающемся списке Security Level (Уровень безопасности) можно выбрать предварительно определенный набор функций или значение Custom (Пользовательский) и с помощью меню определить необходимые функции. Выбор значения Low (Низкий) достаточно безопасен для любой системы и не должен влиять на нормальную работу программного обеспечения. Использование этой настройки включает ограничение связывания в каталогах с режимом 1777. Это предотвращает так называемое состояние гонок в каталоге /temp, используемое для проникновения за счет следования только символическим ссылкам на файлы, которыми владеет процесс. Аналогично, пользователи, находящиеся в каталоге с разрешением 1777, не смогут записывать в FIFO, которым они не владеют.

Трюк № 13. Блокировка ядра с помощью grsecurity

45

Помимо задания строгих ограничений, касающихся символьных ссылок и FIFO, настройка Low повышает случайность номеров, назначаемых идентификаторам процессов и IP. Это помогает предотвратить атаки с использованием методик удаленного определения типа ОС, установленного на машине (трюк № 40), а также усложняет предсказание номера идентификатора процесса определенной программы. Низкий уровень безопасности также заставляет программы, использующие перенаправление chrootO, изменять их текущий рабочий каталог после вызова chrootO на /. Иначе, если программа оставит свой рабочий каталог вне chroot-среды, это может использоваться для взлома «песочницы». Использование уровня безопасности Low отменяет для всех пользователей, за исключением root, возможность запуска утилиты dmesg, позволяющей просмотреть последние сообщения ядра. Уровень Medium (Средний) включает те же ограничения, что и уровень Low, но делает более безопасными «песочницы», созданные на основе chrootO. Возможности монтирования файловых систем, вызова chrootO, записи переменных sysctl или создания узлов устройств (device nodes) в среде «песочницы» ограниченны, что в значительной степени снижает риски, связанные с запуском службы в «песочнице» ОС Linux. Кроме того, ТСР-порты источника станут произвольными, будут протоколироваться неудачные вызовы forkO, изменения системного времени и ошибки сегментации. Использование уровня Medium ограничит общий доступ к /ргос, сохранив его только для привилегированных пользователей. Процессы пользователей будут скрыты от других пользователей, и будет запрещена запись в /dev/kmem, /dev/mem и /dev/port. При запущенном ядре обновление root-средств в нем станет более сложным. Размещение адресного пространства процесса в памяти станет случайным, что усложнит проведение атак переполнения буфера (buffer overrun attacks). По этой причине сведения о размещении процесса в адресном пространстве будут удалены из /ргос. Из-за ограничений, введенных для /ргос, вам придется запустить свой identd-демон от имени учетной записи, относящейся к группе привилегированных пользователей. В документации grsecurity указывается, что ни одна из этих функций не повлияет на работу вашего программного обеспечения, за исключением очень старого и написанного не совсем корректно. Для включения почти всех функций grsecurity необходимо включить уровень безопасности High (Высокий). Наряду с функциями, предоставляемыми более низкими уровнями, этот уровень обеспечивает дополнительные ограничения /ргос за счет предоставления доступа к информации об устройствах и процессоре только пользователям, являющимся членами группы привилегированных пользователей. Ограничена также среда «песочницы» за счет отключения у chmod возможности устанавливать разряд SUID или SGID. Кроме того, приложениям, запущенным в такой среде, запрещается добавлять загружаемые модули, выполнять операции «сырого» ввода-вывода, настраивать сетевые устройства, выполнять перезагрузку системы, модифицировать неизменные файлы (immutable files) или изменять системное время. Выбор этого уровня безопасности приведет также к произвольному размещению в памяти стека ядра для предотвращения успешной реализации атак переполнения буфера ядра. Кроме того, идентификаторы ядра будут скрыты (это значительно усложнит установку в запущенное ядро кода так называемых «троянских коней»), а операции монтирования, перемонтирования и демонтирования будут протоколироваться.

4В


Выбор степени безопасности High активизирует программный код функции РаХ, которая обеспечивает функционирование неисполняемых страниц памяти. Это позволяет защититься от различных атак переполнения буфера, поскольку любой код, помещенный в стек путем перезапуска (overrun), выполняться не будет. Тем не менее по-прежнему сохраняется возможность использовать уязвимость переполнения буфера программы, хотя из-за произвольного расположения процесса в адресном пространстве сделать это очень сложно. На архитектуре х86 РаХ ведет к некоторому снижению производительности, хотя и минимальному. Кроме того, некоторые программы (такие, как XFree86, wine и виртуальные машины Java) ожидают, что адресное пространство, возвращаемое вызовом malloc( ), будет исполняемым. К сожалению, РаХ изменяет такое поведение, что может привести к невозможности работы этих и других программ. К счастью, с помощью утилиты chpax (http://chpax.grsecurity.net) РаХ можно отключить для конкретной программы. Для этого используется подобная команда: # chpax -ps /usr/bin/java Существуют и другие программы, которые используют специальные функции GCC, например trampoline. Это позволяет программисту определять небольшую функцию внутри другой функции, так чтобы эта функция выполнялась только в пределах той функции, в которой она определена. К сожалению, GCC помещает программный код функции trampoline в стек, поэтому РаХ нарушает работу программ, которые полагаются на нее. Но РаХ с помощью утилиты chpax с ключом -Е может эмулировать функцию trampoline. Если вас не устраивает набор функций, предлагаемый рассмотренными уровнями безопасности, можно выбрать вариант Custom (Пользовательский) и включить только необходимые вам функции. После установки определенного уровня безопасности или выбора набора функций перекомпилируйте ядро и модули обычным образом: # make dep clean && make bzlmage # make modules && make modules_install Далее перезагрузите ядро. Помимо включенных ограничений ядра, теперь можно воспользоваться утилитой gradm для настройки ACL системы (см. трюк № 14). Необходимо отметить, что grsecurity — это сложная, но крайне полезная модификация ядра Linux. Дополнительные сведения об установке и о настройке обновления можно найти в документации, размещенной на странице http://www. grsecurity.net/papers.php.

Ограничение приложений с помощью grsecurity Используйте возможности Linux и ACL-списки grsecurity для ограничения приложений.

После установки обновления grsecurity можно воспользоваться гибкой системой ACL (помимо функций, предоставляемых непосредственно grsecurity) для

Трюк № 14. Ограничение приложений с помощью grsecurity

47

дальнейшего ограничения привилегированных приложений на вашей системе. Если вы сразу обратились к этому трюку и не знакомы с grsecurity, сначала изучите трюк № 13. Для ограничения определенного приложения необходимо использовать утилиту gradm, которую можно загрузить с основного сайта grsecurity (http://www. grsecurity.net). Ее компиляция и установка осуществляются традиционным способом: распакуйте дистрибутив, перейдите в созданный при этом каталог и запустите make && make install. При этом gradm будет установлена в /sbin, создан каталог /etc/grsec, содержащий ACL по умолчанию, и установлена документация. После установки утилиты необходимо создать пароль для идентификации в ядре. Это делается с использованием ключа -Р утилиты gradm: # gradm -P

Setting up grsecurity ACL password Password: Re-enter Password: Password written to /etc/grsec/pw. Для активизации ACL-системы обновления grsecurity выполните команду

# /sbin/gradm -E По окончании настройки ACL можно добавить соответствующую команду в конец файла запуска системы (/etc/rc.local). По умолчанию ACL, установленная в /etc/grsec/acl, довольно ограниченна, поэтому вам захочется создать ACL для двоичных файлов системы и служб. Например, после включения ACL-системы утилита ifconfig не сможет изменять характеристики интерфейса даже при запуске root-пользователем: # /sbin/ifconfig ethO:1 192.168.0.59 up SIOCSIFADDR: Permission denied SIOCSIFFLAGS: Permission denied SIOCSIFFLAGS: Permission denied Самый простой способ настройки ACL для конкретной команды — указать, что вы хотите использовать режим обучения grsecurity, а не указывать вручную каждый ACL. Если ACL-система уже активирована, ее необходимо временно исключить из вашей оболочки (shell), запустив команду gradm -а. После этого вы сможете обратиться к файлам /etc/grsec; в противном случае этот каталог будет скрыт от вас. Добавьте в /etc/grsec/acl следующий элемент: /sbin/ifconfig lo {

/

/etc/grsec -CAP_ALL

h

h

} Это почти самый строгий из возможных ACL, поскольку он скрывает корневой каталог от процесса и удаляет все привилегии, которые ему могут понадобиться. Параметр 1о рядом с двоичным файлом, к которому применяется ACL,

48


указывает на использование режима обучения и на перекрытие ACL по умолчанию. После завершения редактирования ACL необходимо перезагрузить grsecurity с помощью команды gradm -R. Теперь снова попробуйте использовать команду ifconfig: # /sbin/ifconfig ethO:1 192.168.0.59 up # /sbin/ifconfig ethO:l ethO:l

Link encap:Ethernet HWaddr 00:ОС:29:E2:2B:C1 inet addr:192.168.0.59 Beast: 192.168.0.255 Mask-.255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:l Interrupt:10 Base address:0xl0e0

Помимо успешного выполнения этой команды, grsecurity создаст записи в протоколе обучения. На основе этого протокола можно сгенерировать ACL для определенной программы: # gradm -a Password: # gradm -L -0 stdout /sbin/ifconfig о { /usr/share/locale/locale.alias r /usr/lib/locale/locale-archive r /usr/lib/gconv/gconv-modules.cache r /proc/net/unix r /proc/net/dev r /proc/net r /lib/ld-2.3.2.so x /Iib/i686/libc-2.3.2.so rx /etc/Id.so.cache r /sbin/ifconfig x /etc/grsec h / h -CAP_ALL +CAP_NET_ADMIN }

Теперь можно заменить обучающий ACL для /sbin/ifconfig в /etc/grsec/acl приведенным ранее, и ifconfig должна работать. Этой же методикой можно воспользоваться в отношении любой программы, для функционирования которой необходимы специальные разрешения. Просто попробуйте выполнить с этой программой все, что необходимо сделать для того, чтобы режим обучения grsecurity смог обнаружить, какие системные вызовы требуются для работы программы или какие файлы открываются. Использование grsecurity для блокировки соединений на первый взгляд может показаться очень трудоемкой задачей, но в конечном счете будет создана система, дающая каждому процессу только те разрешения, которые ему нужны для работы, — ни больше ни меньше. При необходимости построить надежно защищенную платформу grsecurity может обеспечить точечное управление практически всем, что может сделать система.


49

Ограничение системных вызовов с помощью Systrace Оградите программы от выполнения задач, которые они выполнять не должны.

Наиболее впечатляющей новинкой в ОС NetBSD и OpenBSD является systrace — диспетчер доступа к системным вызовам. С помощью systrace системный администратор может указать, какие системные вызовы может использовать конкретная программа и как эти вызовы могут выполняться. Разумное использование systrace в значительной степени сокращает риски, исходящие от некорректно написанных или взламывающих (разрушающих) программ. Политики systrace позволяют ограничить деятельность пользователя совершенно независимо от разрешений Unix. Имеется возможность даже определить ошибки, возвращаемые системными вызовами при запрете доступа, что позволит программам завершаться более корректно. Использование systrace требует практического понимания сути системных вызовов, а также функциональных возможностей программы, которые они определяют. Прежде всего, разберемся в том, что представляет собой системный вызов. Системный вызов — это функция, позволяющая вам общаться с ядром операционной системы. Если вы хотите выделить память, открыть TCP/IP-порт или выполнить операцию записи/чтения диска, необходимо использовать системные вызовы. Системные вызовы описаны в разделе 2 справочной системы (manpages). Unix поддерживает также широкое разнообразие библиотечных вызовов языка С. Их иногда путают с системными вызовами, но фактически они — лишь стандартизированные процедуры, которые можно использовать в программах. Например, можно написать функцию, вычисляющую квадратные корни в программе, но невозможно написать функцию, выделяющую память на основе системного вызова. Если есть сомнения, является ли конкретная функция системным вызовом или библиотечной функцией С, обращайтесь к справочной системе. Можно встретить случайные системные вызовы, описания которых нет в документации, например break О. Для идентификации таких вызовов приходится углубляться в ресурсы (в частности, break О — очень давний системный вызов, который используется в libc, но не программистами; видимо, поэтому он и не представлен в справочной системе). Systrace запрещает все действия, не разрешенные явно, протоколируя в syslog все отклонения. Если запущенная под systrace программа имеет проблемы, вы увидите, какой системный вызов хочет использовать программа, и должны решить, стоит ли добавить его в политику, перенастроить программу или оставить ошибку. В systrace можно выделить ряд важных компонентов: политики, средства генерации политик, средства управления доступом в ходе выполнения и интерфейс

SO


системного администратора, работающий в реальном времени. В этом трюке мы кратко рассмотрим политики, а в трюке № 16 — прочие средства systrace. Документация manpage systrace(1) содержит полное описание синтаксиса, используемого для описания политик, но проще рассмотреть несколько примеров работающих политик и лишь затем вникнуть в подробности синтаксиса. Поскольку вопросы безопасности named недавно были предметом рассмотрения, давайте познакомимся с политикой, которую OpenBSD 3.2 использует в отношении named. Перед рассмотрением политики познакомимся с общими требованиями доступа к системе, предъявляемыми демоном сервера имен (named). Переносы зон и крупные запросы осуществляются через 53-й порт TCP, в то время как основные службы поиска доступны через 53-й порт UDP. OpenBSD по умолчанию изолирует демон named в /var/named, протоколируя все события в /var/log/messages. Файл политики, usr_sbin_named, содержит лишь несколько элементов, позволяющих обращаться за пределы 53-го порта и выполнять запись в системный протокол. Вот начало этого файла: # Policy for named that uses named user and chroots to /var/named # This policy works for the default configuration of named. Policy: /usr/sbin/named. Emulation: native Выражение Policy указывает полный путь к программе, для которой предназначена эта политика. Невозможно обмануть systrace, указав то же имя программы где-либо в другом месте системы. Элемент Emulation указывает, к какому ABI относится эта политика. Не забывайте, что BSD-системы «открывают» ABI для различных операционных систем. Теоретически, systrace может управлять доступом к системным вызовам для любого ABI, хотя в данный момент поддерживаются только «родные» и двоичные файлы Linux. Остальные строки определяют разнообразие системных вызовов, которые можно или нельзя использовать программе. Политика для named содержит 73 строки правил. В общем виде они выглядят так: native-accept: permit Когда /usr/sbin/named пытается использовать системный вызов acceptO для принятия соединения через сокет под «родным» ABI, это разрешается (permit). Остальные правила значительно более строгие. Вот пример для bind О — системного вызова, позволяющего программе запросить подключение к ТСР/1Р-порту: native-bind: sockaddr match "inet-*:53" then permit sockaddr — это имя аргумента, получаемого системным вызовом acceptO. Ключевое слово match указывает systrace на необходимость сравнения данной переменной со строкой inet-*:53 (в соответствии со стандартными правилами сравнения шаблонов). Таким образом, если переменная sockaddr соответствует строке inet-*:53, то соединение принимается. Эта программа может привязываться


51

к 53-му порту как по протоколу TCP, так и по UDP. Если атакующий осуществил взлом с использованием make named, подключившись к порту с высоким номером, данная политика systrace сделает этот взлом нерабочим. На первый взгляд это выглядит неверным: native-chdir: filename eq "/" then permit native-chdir: filename eq "/namedb" then permit Ключевое слово eq сравнивает одну строку с другой и требует точного совпадения. Если программа пытается перейти в корневой каталог или каталог /namedb, то systrace препятствовать этому не будет. Зачем разрешать доступ named к корневому каталогу? Вот зачем: native-chroot: filename eq "/var/named" then permit Системный вызов native chrootO можно использовать для того, чтобы назначить корневым каталог /var/named, и никакой иной. В данный момент каталог /namedb на самом деле является каталогом /var/named/namedb. Мы также знаем, что named регистрируется в syslog. Для этого ему понадобится доступ к /dev/log: native-connect: sockaddr eq "/dev/log" then permit Эта программа может использовать системный вызов native connect О для общения с /dev/log, и только с /dev/log. Это устройство соединения из другого места поддерживать не будет. Кроме того, можно увидеть несколько элементов для системных вызовов, которых не существует: native-fsread: filename eq "/" then permit native-fsread: filename eq "/dev/arandom" then permit native-fsread: filename eq "/etc/group" then permit Systrace присваивает псевдонимы некоторым системным вызовам с очень схожими функциями в файле groups. Такое поведение можно отключить с помощью параметра командной строки и использовать только указанные системные вызовы, но во многих случаях эти псевдонимы очень полезны и значительно расширяют политики. Двумя такими псевдонимами являются fsread и fswrite. Команда fsread является псевдонимом для statO, istatO, read! ink О и access О под native ABI и Linux ABI. Команда fswrite — псевдоним для unl ink О, mkdir() и rmdi r() в native ABI и Linux ABI. Системный вызов open О может использоваться как для чтения, так и для записи файла. В качестве его псевдонима в зависимости от вызова может использоваться как fsread, так и fswrite. Таким образом, named может выполнять чтение некоторых файлов /etc, выводить список содержимого корневого каталога и обращаться к файлу groups. Systrace поддерживает два необязательных ключевых слова, помещаемых в конце выражения политики: errorcode и log. Errorcode — это ошибка, возвращаемая при попытке программы обратиться к данному системному вызову. Программы будут по-разному реагировать на полученную ошибку. Реакция named на ошибку «permission denied» будет отличаться от реакции на ошибку «out of memory».

52


Полный список кодов ошибок вы можете просмотреть с помощью справки errno manpage. Используйте наименование ошибки, а не код ошибки. Например, вот возвращение ошибки о несуществующем файле: filename sub "<non-existent filename>" then deny[enoent] Если в конце выражения политики поместить слово log, то успешное выполнение системных вызовов будет протоколироваться. Например, если необходимо протоколировать каждое подключение named к 53-му порту, то выражение политики для вызова bind О должно выглядеть так: native-bind: sockaddr match "inet-*:53" then permit log При желании правила также можно отсортировать по идентификатору пользователя или группы, например: native-setgid: gid eq "70" then permit Мы лишь поверхностно ознакомились с некоторыми правилами. Подробное описание грамматики systrace можно найти в тексте справочного сообщения, получаемого при помощи команды manpage systrace. Создание политик значительно упрощает автоматизированный режим systrace (см. трюк № 16). Исходная статья, на которой основан данный трюк, располагается на сайте http://www.onlamp.eom/pub/a/bsd/2003/01 /30/Big_Scary_Daemons. html. Майкл Лукас (Michael Lucas)

Автоматизированное создание политики Systrace Пускай за вас поработает автоматический режим Systrace.

В неправдоподобно идеальном случае системный администратор должен изучить исходный программный код каждого приложения, устанавливаемого на его систему, и вручную создать политики доступа к системным вызовам, полагаясь на собственное понимание каждой функции приложения. Практически никто из системных администраторов не имеет времени для такой работы. К счастью, systrace имеет средство генерации политик с учетом всех системных вызовов, выполняемых приложением. Рассмотрим данный способ создания политики для inetd. Для включения автоматического режима используется ключ -А с указанием полного пути к необходимой программе: # systrace -A /usr/sbin/inetd Для передачи флагов в inetd добавьте их в конец командной строки. После этого используйте программу, для которой разрабатывается политика. На данной системе открыты службы ident, daytime и time, поэтому запустите программы, использующие эти службы. Для запуска запросов ident запустите IRC-клиент и для обращения к службам времени обратитесь с помощью telnet

Трюк № 16. Автоматизированное создание политики Systrace

53

к 13-му и 37-му портам. После того как были проверены возможности inetd, выключите его. Демон inetd не имеет управляющей программы, поэтому его работа завершается с помощью команды kill и идентификатора процесса. Проверка списка процессов показывает нам два процесса: # ps -ax | grep inet 24421 ?? Ixs 0:00.00 /usr/sbin/jnetd 12929 ?? Is 0:00.01 systrace -A /usr/sbin/inetd He «убивайте» процесс systrace (в данном случае PID 12929). У него имеется информация обо всех системных вызовах, выполненных inetd. Завершите работу процесса inetd (PID 24421), и процесс systrace завершится нормальным образом. Теперь найдите в домашнем каталоге подкаталог .systrace, содержащий заготовку systrace-политики для inetd. He забывайте о том, что политики помещаются в файлы, имя которых составлено из полного пути к программе, в котором косые черты заменены знаком подчеркивания. Вот результат выполнения команды Is: # Is .systrace us r_li bexec_i dentd

us r_sbin_i netd

systrace создал две политики, а не одну. Помимо ожидавшейся политики для /usr/ sbin/inetd, создана политика для /usr/libexec/identd. Так произошло из-за того, что inetd службы времени реализует внутренне (самостоятельно), a ident для запросов службы вызывает отдельную программу. Поскольку inetd порождает identd, программа systrace также захватила системные вызовы identd. Изучая политику, можно разобраться, что же действительно делает программа. Просмотрите каждый системный вызов, используемый программой, и решите, как можно ограничить дальнейший доступ. Как правило, политики, сгенерированные автоматически, приходится еще больше ограничивать. Однако они являются хорошим отправным моментом. Применение политики к программе подобно созданию политики. Просто запустите программу в качестве аргумента systrace с использованием ключа -а: # systrace -a /usr/sbin/inetd Если программа попытается выполнить системные вызовы, не перечисленные в ней, они завершатся неудачей. Это может привести к непредсказуемому поведению программы. Сведения о неудачных попытках systrace записывает в /var/ log/messages. Для редактирования политики просто добавьте необходимое выражение в конец списка правил. Разумеется, это можно сделать вручную, но systrace имеет средство, позволяющее редактировать политики в реальном времени, прямо при выполнении системного вызова. Это отличный вариант для использования в центре сетевых операций, где лицо, ответственное за мониторинг сети, также будет заниматься просмотром системных вызовов и привлекать внимание соответствующего персонала. С помощью ключа -р можно указать программу, за которой необходимо наблюдать. Это называется присоединением к программе.

54


Например, раньше мы видели два процесса, относящиеся к inetd. Один из них является самим процессом inetd, а другой — systrace-процессом, управляющим inetd. Подключитесь к процессу systrace, а не к действительной программе (это должен быть PID 12929) и в качестве аргумента укажите полный путь к управляемой программе: # systrace -p 12929 /usr/sbin/inetd Вроде ничего не случилось. Но когда программа попытается сделать несанкционированный системный вызов, откроется GUI. Будут предоставлены следующие варианты: разрешить/запретить выполнение системного вызова, а также всегда разрешать/всегда запрещать его выполнение. Выполнение программы будет приостановлено до принятия решения, однако решение необходимо принимать быстрей. Обратите внимание на то, что эти изменения относятся только к выполняемому в текущий момент процессу. При перезапуске программы необходимо также запускать и присоединяемый монитор systrace, а любые изменения, установленные в мониторе, будут сброшены. Для того чтобы изменения стали постоянными, их необходимо добавить в политику. Оригинальная статья, на которой основан этот трюк, размещена на сайте http://www.onlamp.eom/pub/a/bsd/2003/01/30/ Big_Scary_Daemons.html. Майкл Лукас (Michael Lucas)

Ш

Управление доступом с помощью РАМ Четко определите, когда и откуда могут обращаться пользователи к вашей системе.

При традиционной Unix-аутентификации нет слишком большой детализации ограничения входа пользователей в систему. Например, как определить узлы, с которых пользователи не должны регистрироваться на ваших серверах? Первым желанием может быть настроить TCP-оболочки или правила межсетевого экрана (трюки № 33 и 34). А что делать, если требуется некоторым пользователям разрешить регистрироваться с определенных узлов, а другим — запретить? А если требуется запретить одним пользователям регистрироваться в определенный промежуток времени (во время ежедневного обслуживания системы), но в то же время — разрешить другим (администраторам)? Для того чтобы это работало со всеми службами, которые могут быть запущены в системе, традиционно приходится обновить каждую из них для обеспечения этой функциональности. Вот где пригодится РАМ. РАМ (сокращение от pluggable authentication modules; буквально — подключаемые модули идентификации) обеспечивает именно такой вид функциональности (и даже больше) без необходимости исправления (patch) всех служб. Практически всегда РАМ существовал для Linux, FreeBSD и Solaris и сейчас является стандартным компонентом традиционных функций идентификации этих платформ. В настоящее время РАМ поддерживаются многие службы, которым требуется аутентификация.


55

Модули настраиваются «пакетом» для всех служб непосредственно в ходе идентификации, выполняемой от начала до успешного завершения проверок доступа. Можно построить пользовательский «пакет» для любой службы, создав в /etc/ pam.d файл с именем соответствующей службы. Если требуется обеспечить еще большую степень детализации доступа, то с помощью модуля pam_stack можно включить весь «пакет модулей». Это позволяет указать другой внешний файл, содержащий «пакет». Если служба не имеет собственного файла в /etc/pam.d, то она по умолчанию будет использовать «пакет», указанный в /etc/pam.d/other. При настройке службы доступны несколько типов элементов-записей. Эти типы позволяют указывать, должен ли модуль обеспечивать идентификацию, управление доступом, управление правилами смены паролей, установлением и завершением сеанса. Сейчас нас интересует только один тип: account. Элемент этого типа позволяет указывать модули, которые будут управлять доступом к идентифицируемым учетным записям. Помимо специфичных для службы конфигурационных файлов, некоторые модули имеют дополнительную настроечную информацию, размещенную в файлах каталога /etc/security. В этом трюке мы рассмотрим самые полезные модули этого типа: pam_access и pam_time. Модуль pam_access позволяет ограничить место, откуда пользователь или группа может зарегистрироваться в системе. Для его использования необходимо сначала настроить службу, с которой будет использоваться этот модуль. Это можно сделать с помощью файла службы в каталоге /etc/pam.d. Вот пример того, как может выглядеть файл /etc/pam.d/login в версии Red Hat 9: ЙРАМ-l.ri

pam_securetty.so pam_stack.so service=system-auth pamjiologin.so pam_stack.so service=system-auth pam_stack.so service=system-auth pam_stack.so service=system-auth pam_console.so

Обратите внимание на использование модуля pam_stack. Он осуществляет включение «пакета», содержащегося в файле system-auth. Давайте рассмотрим и содержание /etc/pam.d/system-auth: «РАМ-1.0

# This file is auto-generated. # User changes will be destroyed the next time authconfig is run. /lib/security/$ISA/pam_env.so /lib/security/$ISA/pam_unix.so likeauth nullok /lib/security/$ISA/pam_deny.so /lib/security/$ISA/pam_unix.so /lib/security/$ISA/pam_cracklib.so retry=3 type= /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow /lib/security/$ISA/pam_deny.so /lib/security/$ISA/pam_limits.so /lib/security/$ISA/pam_unix.so

56


Для добавления модуля pam_access в службу login можно было добавить дополнительную учетную запись в конфигурационный файл login, который, конечно же, лишь разрешал использование этого модуля для службы login. В качестве альтернативы модуль можно добавить в файл system-auth, который разрешал бы его использование для большинства РАМ-совместимых служб системы. Для добавления pam_access в службу login (или другие службы) просто включите подобную строку в конфигурационный файл после существующих элементов:

account

required

pam_access.so

После того как мы разрешили использование модуля pam_access для наших служб, для управления поведением модуля можно изменить /etc/security/access.conf. Каждый элемент в этом файле может указывать пользователей, группы и имена узлов, к которым относится эта запись, а также разрешение/запрещение удаленного/локального доступа. При вызове модуля pam_access элементом конфигурационного файла службы он будет построчно просматривать access.conf. При первом же совпадении поиск будет остановлен. Таким образом, для того чтобы ничего не было пропущено, в начало необходимо помещать более специфичные элементы, после которых можно помещать более общие. Общая форма записей в файле access.conf: permission : users : origins где permission может быть + или -. Значение этого параметра указывает, предоставляется или запрещается доступ соответственно. Параметр users используется для перечисления пользователей или групп (разделяются пробелами). Для упрощения списка пользователей можно использовать формат user@host, где host — это локальное имя узла машины, с которой будет осуществляться регистрация в системе. Такой формат позволит использовать один конфигурационный файл на множестве машин с сохранением логики правил в отношении всех машин. Параметр origins сравнивается с индивидуальным признаком попытки доступа. Индивидуальным признаком могут служить имена узлов, а для локального доступа может использоваться специальное ключевое слово LOCAL. Вместо явного указания пользователей, групп или признаков можно использовать ключевые слова ALL и EXCEPT. Вот пример блокировки пользователя andrew (Ой! Это я!) с узла colossus: - : andrew : colossus До сих пор мы рассматривали, как ограничить место, откуда пользователь сможет зарегистрироваться в системе. А как настроить модуль РАМ на ограничение диапазона времени, в который возможна регистрация? Для настройки модуля pam_time необходимо отредактировать файл /etc/security/time.conf. Формат записей этого файла благодаря возможности использования операторов NOT (!), AND (&) и OR (|) более гибкий, чем у файла access.conf. Общая форма записей в файле time.conf: servi ces;devi ces;users;ti mes


57

Параметр services указывает, в отношении какой РАМ-совместимой службы действует ограничение. Полный список таких служб можно узнать, просмотрев каталог/etc/pam.d. Например, вот содержание /etc/pam.d в версии RedHat ОС Linux: $ Is -I /etc/pam.d authconfig chfn chsh halt internet-druid kbdrate login neat other passwd poweroff PPP reboot redhat-config-mouse redhat-config-network redhat-config-network-cmd redhat-config-network-druid rhn_register setup smtp sshd su sudo system-auth up2date up2date-config up2date-nox vlock Для того чтобы pam_time использовался с любой из этих служб, в файл, расположенный в /etc/pam.d, необходимо добавить такую строку: account

required

/lib/security/$ISA/pam_time.so

Параметр devices указывает терминал, с которого будет произведено обращение к службе. Для регистрации с консоли используется значение ! ttyp*, которое указывает на все TTY-устройства, за исключением псевдо-TTY. Если необходимо, чтобы запись влияла только на удаленную регистрацию, то укажите ttyp*. Для распространения ограничения записи на всех пользователей (консоль, удаленный и XII) введите tty*. В качестве значений параметра users можно указывать одного пользователя либо список пользователей, отделяя одного от другого символом |. Параметр times используется для указания времени, в течение которого действует правило. Перед временным диапазоном указывается двухбуквенное сокращение, соответствующее дню недели. Допустимые сокращения: Mo, Tu, We, Th, Fr, Sa и Su.

58


Для удобства можно использовать сокращения Wk (рабочие дни), Wd (выходные) и А1 (все дни недели). Эти три сокращения обычно расширяются на набор дней, из которых состоит данный период. Важно отметить, что повторяющиеся дни вычитаются из набора дней, к которым применяется правило (например, WkSu равносильно указанию Sa). Временной диапазон указывается в 24-часовом формате без двоеточия, с дефисом в качестве разделителя (например, 0630-1345 соответствует периоду времени с 6:30 до 13:45) Если требуется запретить пользователю andrew доступ с локальной консоли по выходным и в будни в нерабочее время, введите: system-auth;!ttyp*;andrew;Wkl700-0800|WdOOOO-2400 Если требуется ограничить возможность удаленной регистрации с SSH во время обслуживания системы, выполняющегося с 19:00 пятницы до 7:00 субботы, но разрешить регистрацию для sysadmin, введите: sshchttyp*;!andrew;Frl900-0700 Как можно отметить, благодаря использованию логических операторов можно задавать любые интервалы. Просто не забудьте при создании записей в /etc/security/ time.conf настроить файл службы в /etc/pam.d на использование модуля pam_time.

Среда ограниченной оболочки Иногда среда «песочницы» (см. трюк № 10) превосходит ваши требования. Если необходимо создать ограниченную среду для группы пользователей, позволив им лишь запускать определенные команды, необходимо продублировать все библиотеки и двоичные файлы этих команд для каждого пользователя. Вот где ограниченные оболочки (restricted shells) могут быть полезны. Многие оболочки имеют такую возможность, которая вызывается запуском оболочки с ключом -г. Хотя эта процедура не так безопасна, как основанная на системных вызовах среда «песочницы», работает она нормально, если вы считаете, что пользователи не имеют злого умысла, но могут быть не в меру любопытны. Некоторые из известных возможностей ограниченных оболочек — это возможность запретить смену каталога программой, разрешая выполнение команды только по абсолютному пути, и запрет выполнения команд в подкаталогах. Помимо введения этих ограничений отключаются все операторы перенаправления, которые могут использоваться в командной строке. При этом ограничить список команд, которые может выполнить пользователь, можно просто: выбрав, какие команды должны быть доступны, и сделав на них символические ссылки внутри домашнего каталога пользователя. Если требуется выполнять лишь ряд команд, то можно создать сценарии, принадлежащие определенному пользователю. Эти сценарии будут выполняться в неограниченной среде, но будут недоступны для редактирования в этой среде самим пользователем.

Трюк № 18. Среда ограниченной оболочки

S9


60

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

Ш

Ограничение ресурсов пользователя и группы Убедитесь, что «жадный» до ресурсов пользователь не нарушит работу системы.

Становится не до смеха, когда по злому умыслу либо из-за непреднамеренной ошибки пользователь, расходуя слишком много оперативной памяти или времени центрального процессора, заставляет систему работать очень медленно. Одним из популярных методов ограничения использования ресурсов является команда ulimit. Этот метод основан на ограничении оболочкой своих дочерних процессов, и его очень сложно использовать, когда требуется предоставить различный уровень ограничения отдельным пользователям или группам. Более гибким является способ с применением РАМ-модуля pamjimits. На тех системах, где установлен pamjimits, он уже имеет предварительные настройки. Необходимо лишь правильно настроить /etc/security/limits.conf. Конфигурационный файл limits.conf содержит однострочные записи, описывающие отдельный тип ограничений для пользователя или группы. Общий формат записей этого файла следующий: domain

type

resource

value

Параметр domain определяет, к кому применяется данное ограничение. Отдельный пользователь может быть указан по имени, а перед именем группы необходимо поставить символ @. Помимо этого, может использоваться групповой символ *, указывающий на применение данного ограничения ко всем, кроме root. Параметр type указывает тип ограничения («мягкое» или «жесткое»). «Мягкое» ограничение может быть увеличено пользователем, в то время как «жесткое» может менять только root-пользователь. В разделе resource могут указываться различные типы ресурсов. Основными из них являются cpu, memlock, nproc и fsize. Они позволяют указывать использование процессора, памяти, количество процессов и размер файлов соответственно. Процессорное время выражается в минутах, размеры — в килобайтах. Еще одним значением является maxlogins, оно задает максимальное количество разрешенных одновременных регистрации в системе.

Автоматизация обновления системы Своевременно устраняйте «дыры» в системе безопасности для предотвращения проникновения.

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

62


считают это напрасной тратой времени и сил, что не способствует выполнению основной функции системы. Приоритетным становится требование руководства повысить производительность системы, поэтому ее поддержание в обновленном состоянии зачастую откладывается в долгий ящик. Обновление системы может быть очень скучным и отнимающим много времени занятием, если не использовать сценарии автоматизации. К счастью, большинство дистрибутивов Linux позволяет загружать пакеты обновления непосредственно со стандартного адреса в сети. Можно наблюдать за появлением обновлений на этом ресурсе, что позволяет автоматически определять и загружать новые обновления сразу, как только они появятся. Для демонстрации этой возможности на базе RPM-дистрибутива воспользуемся инструментом AutoRPM (http://www.autorpm.org). AutoRPM — это мощный Perl-сценарий, позволяющий обнаруживать изменения на FTP-сайтах. Этот сценарий может автоматически обнаружить, загрузить и установить измененные пакеты либо оповестить о необходимости сделать это. Помимо просмотра отдельных FTP-сайтов, можно просматривать пул «зеркал» сайтов, чтобы гарантировать получение обновлений, невзирая на загрузку одного FTPсервера. Эта функция очень полезна потому, что AutoRPM учитывает, сколько попыток обращения к определенному FTP-серверу было предпринято. На основе этого составляется внутренний рейтинг серверов. Для установки AutoRPM загрузите из Сети свежий пакет и установите его: # rpm -ivh autorpm-3.3-l.noarch.rpm ХОТЯ AutoRPM имеется и в tar-архиве, но его установка более сложна, чем с помощью традиционных make и make install, поэтому рекомендуется устанавливать этот сценарий из RPM-пакета. По умолчанию AutoRPM настраивается на наблюдение обновленных пакетов для версии Red Hat ОС Linux. При желании можно настроить наблюдение за любым хранилищем файлов, например, версий SuSe или Mandrake.

Г Л А В А

В этой главе представлены некоторые способы обеспечения обновления и безопасности системы Windows, позволяющие сделать сеть более защищенной. Хотя многие насмехаются над ОС Windows и ее системой безопасности, эту систему можно довольно легко сделать совершенно безопасной. Одна из основных причин, по которым Windows заслужила репутацию «дырявой», заключается в неверном администрировании. Появляющиеся в последнее время потоки «червей» и вирусные атаки, захватывающие множество сетей, подтверждают это. Большинство проблем возникает из-за «упрощенного» администрирования, которое обеспечивается самой ОС Windows и полностью освобождает администратора от отслеживания внутренней работы среды, тем самым вырывая возможность управления из его рук. Эта глава является в некоторой степени лекарством, показывающим, как необходимо определять, что же на самом деле делает сервер. Хотя это знакомо системным администраторам Unix, получение сведений об открытых портах и запущенных сервисах зачастую является новым для администраторов Windows. Кроме того, в этой главе вы узнаете, как отключить такие функции Windows, как автоматическое предоставление в общий доступ всех файлов и усечение файлов протоколирования. Вы также узнаете, как включить функции аудита и протоколирования Windows, что позволит на ранней стадии отследить нарушения в системе безопасности (не ожидая телефонного звонка от рассерженного человека, подвергшегося исходящей из вашей сети атаке, приводящей к отказу в обслуживании).

Проверка серверов и используемых обновлений Убедитесь, что на ваши Windows-серверы установлены самые свежие обновления и исправления.

Поддержание сетей Unix на уровне современных требований является довольно сложной задачей, однако в ОС Windows она еще более трудоемка. Недостаток надежных встроенных сценариев и возможностей удаленного доступа делает ОС Windows неудобной для автоматизации. Тем не менее, перед тем как пробовать обновить систему, сначала необходимо выяснить, какие обновления в ней уже выполнены. Иначе вы можете впустую потратить силы и время, выполняя об-

64


новление, которое совершенно не требуется. Очевидно, что с увеличением количества обслуживаемых систем эта проблема становится все более сложной. Избежать излишних усилий ручного обновления систем можно, используя средство HFNetChk, которое изначально являлось автономной программой, разработанной компанией Shavlik Technologies. Теперь эта программа входит в состав анализатора Baseline Security Analyzer компании Microsoft (http://download.microsoft.com/download/8/ e/e/8ee73487-4d36-4f7f-92f2-2bdc5c5385b3/mbsasetup.msi) и становится доступной после запуска из командной строки интерфейса mbsacli.exe. HFNetChk может проверять не только статус Windows Server 2003 and Windows XP/ 2000/NT, но и то, были ли выполнены критические обновления IIS, SQL Server, Exchange Server, Media Player и Internet Explorer. Хотя эта программа только проверяет статус обновления системы, а не выполняет ее обновление, она является незаменимым сберегающим время инструментом. HFNetChk работает за счет загрузки подписанного и сжатого XML-файла от компании Microsoft, содержащего сведения обо всех существующих на текущий момент обновлениях. В файле содержатся контрольные суммы и версии файлов, которые обрабатываются в ходе каждого обновления, а также ключи реестра, обновляемые в ходе каждого обновления. В нем имеется также и другая значимая дополнительная информация. В ходе сканирования системы HFNetChk сначала проверяет ключи реестра, связанные с большинством обновлений, доступных для текущей конфигурации системы. Если какие-либо из ключей пропущены или не соответствуют содержанию XML-файла, будет установлен флаг необходимости их обновления. Если ключ существует и его содержание соответствует XML-файлу, то HFNetChk проверит наличие указанного файла, а также его версию и контрольную сумму. В случае несовпадения контрольной суммы будет установлен флаг необходимости обновления. Все флаги необходимости обновления будут выведены в отчете вместе со ссылками на пункт базы Microsoft Knowledge Base, содержащей дополнительные сведения о необходимом обновлении. Для установки HFNetChk сначала необходимо загрузить и установить Baseline Security Analyzer. Для запуска HFNetChk в режиме командной строки необходимо указать каталог, созданный в ходе установки (по умолчанию C:\Program Flles\ Microsoft Baseline Security Analyzer). Для проверки необходимости обновления локальной системы выполните команду С:\> Program FilesVMicrosoft Baseline Security Analyzer> mbsacli /hf Microsoft Baseline Security Analyzer Version 1.1.1

Powered by HFNetChk Technology - Version 3.82.0.1 Copyright (C) Shavlik Technologies. 2001-2003 Developed for Microsoft by Shavlik Technologies, LLC [email protected] (www.shavlik.com) Please use the -v switch to view details for Patch NOT Found, Warning and Note messages

Трюк № 21. Проверка серверов и используемых обновлений

В первом столбце указан результат неудачной проверки определенного обновления. Во втором столбце указано, какое именно обновление выполнено неудачно, а в третьем — номер пункта в базе знаний Microsoft Knowledge Base (http://support.microsoft.com), в котором содержится дополнительная информация о проблеме, исправляемой определенным обновлением. Если вы хотите узнать больше о конкретной неудачной проверке, команду необходимо запускать с ключом -у. Вот результат выполнения предыдущей команды, но с использованием этого ключа:


* WINDOWS XP SP1 Information All necessary hotfixes have been applied. * INTERNET EXPLORER 6 SP1 Information All necessary hotfixes have been applied. * WINDOWS MEDIA PLAYER FOR WINDOWS XP SP1 Information All necessary hotfixes have been applied. При сканировании локальной системы требуются полномочия администратора. При сканировании удаленной машины требуются полномочия администратора удаленной машины. Существует несколько вариантов сканирования удаленных компьютеров. Для сканирования одиночной удаленной системы в качестве значения ключа -h должно быть указано NetBIOS-имя. Точно так же в качестве значения ключа -1 может быть указан IP-адрес системы. Например, для сканирования машины PLUNDER с другой машины можно использовать любую из представленных команд: mbsacli /hf -h PLUNDER mbsacli /hf -i 192.168.0.65 Обратите внимание на то, что помимо привилегий администратора удаленной машины необходимо, чтобы были доступны стандартные общедоступные ресурсы (трюк № 27). Если стандартные общедоступные административные ресурсы отключены, то HFNetChk не сможет должным образом проверить файлы удаленной системы и, следовательно, не сможет определить, какие обновления были использованы. Проверку нескольких систем можно выполнить несколькими способами. При использовании параметра -fh можно указать файл, содержащий до 256 NetBIOS-имен ра mbsacli (по можность с IP-адресами -годному можно /hfс в-r помощью указывать строке) 192.168.1.123 от 192.168.1.13 систем, диапазон параметра -которые до 192.168.1.172 IP-адресов. 192.168.1.172 -fip указать будут проверены. Например, IP-адреса. используется для Аналогично А сканирования сследующая помощью имеется параметкоманда: систем воз-


Все параметры очень удобны, и их можно использовать в любом сочетании. Помимо указания удаленной системы по NetBIOS-имени или IP-адресу, с помощью параметра -d можно сканировать системы по имени домена, а с помощью параметра -п можно выполнить сканирование всего сегмента локальной сети. При сканировании систем, выполняемом с личной рабочей станции, могут пригодиться параметры -и и -р. При обращении к удаленной системе они позволяют сразу указывать имя пользователя и пароль. Эти ключи особенно полезны, если вы обычно входите в систему, не используя учетную запись администратора. Конечно же, указанная в параметре -и учетная запись должна иметь привилегии администратора удаленной системы. При сканировании большого количества систем удобен также параметр -t. Он позволяет указывать число потоков, используемых сканером. Увеличение количества потоков обычно приводит к повышению скорости сканирования. Допускаются значения от 1 до 128; по умолчанию — 64. При сканировании более одной машины на экран «вываливается» огромное количество данных. Параметр -f позволяет указать файл, где будут храниться результаты сканирования, которые можно позже просмотреть с помощью обычного текстового редактора. HFNetChk — очень гибкий инструмент, который может использоваться для довольно быстрой проверки необходимости обновления системы на множестве машин. Эта программа особенно полезна при появлении нового «червя», когда вам необходимо убедиться, что все ваши системы имеют свежее обновление, защищающее от воздействия этого «червя».

СОВЕТ См. также Microsoft Network Security Hotfix Checker (Hfnetchk.exe) Tool: Knowledge Base Article 303215, на http://support.microsoft.com/default.aspx?scid= kb;EN-US;303215. Frequently Asked Questions about the Microsoft Network Security Hotfix Checker (Hfnetchk.exe) Tool: Knowledge Base Article 305385, на http:// support.microsoft.com/default.aspx?scid=kb;EN-US;305385.

Получение списка открытых файлов и владеющих ими процессов Поиск подозрительной активности путем наблюдения за доступом к файлам.

Предположим, вы просматриваете в менеджере задач список процессов, не запуская на рабочей станции посторонних задач, и замечаете процесс, который раньше не видели. Что теперь надо делать? Если у вас установлена не ОС Windows, можно проконтролировать деятельность процесса, просмотрев файлы, которые он открывает. К сожалению, Windows не позволяет сделать это. Компания Sysinternals разработала отличный инструмент под названием Handle, который можно бесплатно загрузить с адреса: http://www.sysinternals.com/ntw2k/ freeware/handle.shtml. Программа Handle очень похожа на Isof (см. трюк № 8), но

Трюк № 22. Получение списка открытых файлов и владеющих ими процессов

69

она может выводить список оперативных ресурсов различных типов, включая потоки, события и семафоры. Кроме того, эта программа выводит открытые ключи реестра и IOCompletion-структуры. Запуск Handle из командной строки без параметров представит список всех открытых дескрипторов файлов. Для того чтобы узнать, какие процессы обращаются к определенному файлу в данный момент, можно указать имя конкретного файла: С:\> handle имя файла Если же необходимо просмотреть лишь список файлов, открываемых определенным процессом, например Internet Explorer, то команда будет выглядеть так: С:\> handle -p iexplore Handle v2.10 Copyright (С) 1997-2003 Mark Russinovich Sysinternals - www.sysinternals.com


70

758: File C:\WINNT\system32\iepeers.dll 75с: File C:\Documents and Settings\ahdrew\Desktop 770: Section \BaseNamedObjects\RotHintTable If you want to f i n d the Internet Explorer process that owns a resource with a partial name of handle, you could type: C:\> handle -p iexplore handle Handle v2.10 Copyright (C) 1997-2003 Mark Russinovich Sysinternals - www.sysinternals.com IEXPLORE.EXE pid: 1396 C:\Documents and Settings\andrew\Local Settings\ Проверьте средствами Temporary Windows Internet службы, Files\Content.IE5\HlEZGFSH\ к которым handled].htm можно обращаться извне.

Ш

Список запущенных служб и открытых портов

Кроме того, для просмотра всех типов ресурсов можно воспользоваться параметUnix-a. позволяет быстро просто просмотреть порты, номожет как этоодновресделать ром Handle — оченьимощное средство, и воткрытые командной строке в Windows? Программа FPort различных компании параметров Foundstone для (http://www.foundstone.com/ менно указываться несколько быстрого поиска именresources/index_resources.htm) но того, который необходим. так же проста и быстра, как старый добрый netstat. FPort имеет несколько параметров, определяющих в основном сортировку результатов. Например, если необходимо отсортировать результат по имени приложения, необходимо использовать параметр /а; по номеру идентификатора процесса — /i. Хотя у FPort не так много функций, как у netstat, эта программа действительно выполняет свою работу. Для получения списка всех портов, открытых в данный момент в системе, просто введите команду fport. При необходимости отсортировать список по номеру порта используйте ключ /р: С:\> fport /p

FPort v2.0 - TCP/IP Process to Port Mapper Copyright 2000 by Foundstone. Inc. http://www.foundstone.com

Трюк № 24. Включение аудита

71

Обратите внимание на то, что здесь представлены некоторые процессы (navapw32, putty и IEXPLORE), которые выглядят не как службы. Они оказались в выходном списке из-за того, что FPort выводит все открытые порты, а не только порты, для которых запущены процессы-«слушатели». Несмотря на то что программа FPort не столь мощна, как некоторые команды, доступные в других операционных системах, все равно она — надежное, быстрое и простое в использовании средство, являющееся хорошим дополнением Windows.

Включение аудита Протоколируйте подозрительную активность для облегчения установления факта вторжения.

Windows 2000 обладает очень мощными функциями протоколирования, но, к сожалению, по умолчанию все они отключены. В Windows 2003 это исправлено включением ряда функций по умолчанию, но все же разумно проверить, что отслеживается именно то, что необходимо. С помощью имеющихся возможностей можно наблюдать за неудачными попытками входа в сеть, отслеживать события управления учетными записями, доступа к файлам, использование привилегий и т. п. Можно также протоколировать изменение политик безопасности и все системные события. Для включения аудита в любой из перечисленных областей найдите значок Средства администрирования (Administrative Tools) панели инструментов и дважды щелкните на нем. После этого найдите значок Локальная

72


политика безопасности (Local Security Policy) и дважды щелкните на нем. Раскройте узел дерева Локальные политики (Local Policies) (рис. 2.1).

Рис. 2 . 1 . Настройки политики аудита в модуле настроек локальной безопасности

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

Рис. 2.2. Диалоговое окно аудита событий входа в систему

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

Трюк № 26. Изменение максимальных размеров файлов протоколов

73

Защита журналов событий Системные протоколы не должны искажаться.

Windows имеет очень мощные возможности протоколирования. К сожалению, по умолчанию журнал событий не защищен от несанкционированного доступа или изменения. Несмотря на то что события просматриваются с помощью Event Viewer, журнал событий представляет собой обычный файл, такой же, как и остальные. Для их защиты достаточно лишь найти эти файлы и применить к ним соответствующие списки ACL. Если только расположение файлов не было изменено с помощью реестра, то они должны находиться в каталоге %SystemRoot%\system32\config. С журналом приложения, безопасности и системным протоколом сопоставлены файлы AppEvent.Evt, SecEvent.Evt и SysEvent.Evt соответственно. Для ограничения доступа к ним только с помощью учетной записи администратора примените к ним ACL. Это можно сделать с помощью диалогового окна свойств файла. Перейдя на вкладку Безопасность (Security), удалите на ней всех пользователей и группы, за исключением Administrators и SYSTEM.

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

С точки зрения безопасности журналы — это самый важный актив, хранящийся на сервере. Как-никак, без протоколов вы никогда не узнаете, пытался ли кто-то получить доступ к вашей машине. Следовательно, обязательным требованием является полнота протоколирования. Пытаться обнаружить источник инцидента с помощью протокола, в котором пропущены записи, все равно что вообще не иметь протокола. Одной из проблем является то, что по умолчанию максимальный размер файла установлен 512 Кбайт. Для его изменения откройте панель управления Средства администрирования (Administrative Tools) и откройте окно Просмотр событий (Event Viewer) (рис. 2.3). После этого выделите в левой панели этого окна один из файлов протокола и щелкните на нем правой кнопкой мыши. В контекстном меню выберите пункт Свойства (Properties) (рис. 2.4). Найдите текстовое поле Максимальный размер протокола (Maximum log size). Новый размер можно задать вручную или с помощью стрелок, расположенных справа от поля. Размер должен быть не менее 1 Мбайт и определяется тем, как часто вы собираетесь просматривать и архивировать протоколы. Учтите, что, хотя слишком большой размер файлов протоколов никак не сказывается на быстродействии машины, работа утилиты Просмотр событий (Event Viewer) с большими файлами будет замедленной.

74


Рис. 2.З. Окно Просмотр событий (Event Viewer)

Рис. 2.4. Свойства протокола безопасности

Трюк № 27. Отключение стандартных общих ресурсов

75

Находясь на этой вкладке, можно также изменить поведение протокола при достижении им максимального размера. По умолчанию записи журнала, сделанные более семи дней назад, заменяются новыми. Рекомендуется увеличить это значение до 31 дня. Кроме того, можно отключить автоматическую перезапись, но очистку протокола придется производить вручную.

Ш

Отключение стандартных общих ресурсов Остановите совместное использование ваших файлов во всем мире!

По умолчанию Windows разрешает совместный доступ к каждому логическому диску (С$ для диска С:), а также открывает другой общий ресурс — ADMIN$ для каталога %SystemRoot% (то есть C:\WINNT). Хотя они доступны только администраторам, рекомендуется отключить эти общие ресурсы, поскольку они представляют собой потенциальную «дыру» в системе безопасности. Для отключения этих ресурсов откройте реестр, запустив файл regedit.exe. Найдите в реестре ключ HKey_Local_Machine\SYSTEM\CurrentControlSet\Services\ lanmanserver\ parameters. Если вы работаете на рабочей станции Windows 2000, то добавьте ключ AutoShareWks типа DWORD со значением 0 (рис. 2.5), щелкнув Правка • Создать • Параметр DWORD (Edit • New • DWORD). Для Windows 2000 Server добавьте параметр AutoShareServer со значением 0. После завершения редактирования реестра перезагрузите Windows.

Рис. 2.5. Добавление ключа AutoShareWks в реестр

76


После перезагрузки Windows можно убедиться (с помощью команды net share), что стандартных общих ресурсов больше не существует:

Перед этим необходимо убедиться, что отключение общих ресурсов не скажется негативно на вашем окружении. Отсутствие этих ресурсов приведет к тому, что некоторые средства управления системой, такие как HFNetChk (трюк № 21) или System Management Server, работать не будут. Это происходит из-за того, что подобное программное обеспечение основано на удаленном доступе к открытым административным ресурсам, которые используются для обращения к содержанию системных дисков.

Многие Windows-приложения в ходе работы создают промежуточные/временные файлы. Как правило, эти файлы хранятся во временном каталоге, расположенном в settings-каталоге текущего пользователя. Почти всегда эти файлы становятся глобально доступными (world-readable) и не всегда удаляются по завершении работы приложения. Вам понравится, если текстовый процессор оставит копию последнего документа для того, кто проникнет в систему? Не здорово, правда? Одним из способов противостоять данной ситуации является шифрование каталога временных файлов. Для этого откройте окно Проводника Windows и перейдите в каталог C:\Documents and Settings\\1_оса1 Settings. Здесь вы найдете подкаталог с именем Temp. Именно в нем хранятся временные файлы. Щелкните правой кнопкой на этом подкаталоге и откройте диалоговое окно свойств. Перейдите на вкладку Общие (General) и щелкните на кнопке Дополнительно (Advanced). Это приведет к открытию диалогового окна Дополнительные атрибуты (Advanced Attributes) (рис. 2.6). Здесь можно задать шифрование каталога. Установите флажок Шифровать содержимое (Encrypt contents to secure data) и щелкните на кнопке ОК. После этого щелкните на кнопке Применить (Apply). Появится еще одно диалоговое окно (рис. 2.7), уточняющее, хотите ли вы применить рекурсивное шифрование. Для рекурсивного применения шифрования выберите параметр Применить изменения к каталогу и его подкаталогами и файлам (Apply changes to this folder, subfolders and files). При этом, если вы никогда ранее не выполняли шифрование файлов, автоматически будет создана пара публичных ключей. В противном случае Windows будет использовать созданные ранее ключи. В ходе декодирования ОС Windows убеждается, что частные ключи хранятся в памяти ядра, не

Трюк № 29. Очистка файла подкачки при отключении

77

имеющей постраничной организации, так что ключ дешифрации никогда не попадет в файл страничной памяти (файл подкачки). К сожалению, используемый алгоритм шифрования (DESX) является лишь слегка усовершенствованным DES и никогда не будет столь же криптоустойчивым, как 3DES. Однако для шифрования временных файлов он вполне подходит. Если необходимо выполнять шифрование других файлов, желательно использовать средства сторонних производителей, такие как GnuPG (http://www.gnupg.org).

Рис. 2.6. Диалоговое окно дополнительных атрибутов папки Temp

Рис. 2.7. Подтвердите выбор шифрования и сделайте его рекурсивным

Ш

Очистка файла подкачки при отключении Предотвращайте утечку информации с помощью автоматической очистки файла подкачки при выключении.

Система управления виртуальной памятью (Virtual memory management, VMM) — прекрасная штука. Она защищает программы друг от друга и позволяет им пользоваться объемом памяти, который превосходит объем физический памяти,

78


установленной в системе. Для реализации этого VMM использует то, что называется страничным файлом (своп-файлом, файлом подкачки). По мере запуска все большего числа программ объем физической памяти исчерпывается. При этом диспетчер памяти находит реже используемый участок памяти, относящийся к программам, которые в данный момент не проявляют никакой активности, и записывает его на жесткий диск (то есть в виртуальную память). Этот процесс называется подкачкой. Однако у этого процесса имеется один существенный недостаток: если запущена программа, обрабатывающая конфиденциальную информацию в «своем» пространстве памяти, то эта информация может оказаться на диске. Хорошо, если запущена операционная система и существуют средства защиты, предотвращающие возможность чтения файла подкачки, но как быть в случае, если эта система отключена или производится перезагрузка компьютера в другую операционную систему? Вот где становится необходимым данный трюк. Все, что необходимо сделать, — это попросить операционную систему при выключении заполнить файл подкачки нулями. Учтите, что это не сработает, если отключение производится извлечением сетевого кабеля из розетки или система выключается неверно; описываемая перезапись возможна только при корректном выключении компьютера. Для включения этой функции Windows необходимо внести изменения в системный реестр. Для этого откройте реестр и найдите ключ HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management (рис. 2.8).

Рис. 2.8. Ключ реестра, отвечающий за управление памятью

Найдите параметр ClearPageFileAtShutdown в правой панели и измените его значение на 1. Для того чтобы изменение вступило в силу, перезагрузите Windows, и те-

Трюк № 30. Ограничение доступа пользователя к приложениям

79

перь перед выключением компьютера ваш своп-файл будет очищаться. Единственный побочный эффект от использования этой функции заключается в том, что выключение Windows теперь будет занимать больше времени. Однако это очень сильно зависит от аппаратного обеспечения (то есть от чипсета контроллера диска, скорости вращения диска, скорости процессора и т. п.), что определяет длительность записи нулей в файл подкачки.

Ограничение доступа пользователя к приложениям Защитите пользователей от запуска потенциально опасных приложений.

Обеспечение невозможности для пользователей запускать определенные приложения не очень важно при администрировании собственной рабочей станции. Но когда вы имеете дело с обычными пользователями, работающими в сетевой среде предприятия, необходимо оградить их от запуска «подлых» программ. К таким программам относятся приложения, которые могут нарушить работу операционной системы, создают «дыры» в системе безопасности и даже организуют атаки на другие компьютеры вашей сети. Существует пара способов ограничения доступа пользователей к приложениям. Во-первых, можно изменить ACL для конкретной программы таким образом, что пользователи не смогут запустить ее. Например, предположим, что на компьютере пользователя для проведения диагностики установлена программа, являющаяся сетевым анализатором (sniffer). Эта программа полезна для администратора, а обычному пользователю она не нужна. Оградить его от запуска этой программы можно удалением разрешения на ее выполнение для группы Users. Для этого найдите исполняемый файл программы и щелкните на нем правой кнопкой. В контекстном меню выберите пункт Свойства (Properties) (рис. 2.9). Теперь перейдите на вкладку Безопасность (Security) и в списке, расположенном в верхней части вкладки, выберите группу Users (рис. 2.10). Установите флажок Отказать (Deny), относящийся к пункту Запись и выполнение (Read & Execute). После щелчка на кнопке Применить (Apply) ни один член группы Users не сможет запустить эту программу. Во-вторых, можно также изменить ACL каталога, в котором находится программа, лишив возможности чтения. Такой подход может оказаться полезным; если все средства администрирования находятся в одном каталоге, он позволяет ограничить доступ к ним с помощью всего одной операции. Если используется версия Windows для терминального сервера, то существует еще одна альтернатива использованию ACL. Если у вас установлен Windows 2000 resource kit, то можно, используя входящую в него программу AppSec, отключить доступ к программам всего лишь несколькими щелчками. Для этого запустите AppSec, и после загрузки программы вам будет представлен список программ. Если программа, запуск которой вы хотите запретить терминальным пользователям,


имеется в списке, то просто щелкните на переключателе Недоступен (Disabled). Например, запуск cmd.exe можно запретить, как показано на рис. 2.11.

Рис. 2.9. Диалоговое окно свойств программы ethereal.exe

Рис. 2.10. Вкладка Безопасность диалогового окна свойств программы ethereal.exe

Трюк № 30. Ограничение доступа пользователя к приложениям

81

Рис. 2 . 1 1 . Ограничение использования cmd.exe

Если необходимого приложения в списке нет, щелкните на кнопке Добавить (Add) и укажите это приложение. После внесения изменений щелкните на кнопке Выход (Exit). Для того чтобы изменения вступили в силу, необходимо, чтобы все пользователи завершили сеанс работы с терминальным сервером.

ГЛАВА

3

Сетевая безопасность Трюки № 31-53 По мере того как мы все больше полагаемся на связь посредством массовых сетей, все более важными становятся стабильность и надежность этих сетей. Мир бизнеса одобрил информационные технологии, помогающие упорядочить процессы, повысить их продуктивность и снизить стоимость. Таким образом, IT-подразделение является ключевым звеном многих компаний. По этой причине в случае бедствия (природного или цифрового), которое зачастую прерывает выполнение сетевых операций, многие предприятия просто прекращают свою деятельность. Вместе с тем всеобщее признание Интернета в качестве глобальной среды общения вывело компьютеры из сферы бизнеса и академического мира и .приблизило к частной жизни, в которой сеть используется не просто для развлечения, а для поддержания связи с родными и близкими. Хотя в целом эта книга посвящена сетевой безопасности, содержащаяся в ней информация распространяется и на другие сферы. Как-никак, сеть — это просто средство соединения машин и серверов. Однако данная глава посвящена в основном безопасности и целостности самой сети. Мы научимся обнаруживать и предотвращать некоторые типы спуфинга (spoofing attacks), который может использоваться для подрыва стержневой целостности Ethernet-сетей, использующих протокол TCP/IP, на самом нижнем уровне. В этой главе мы подробно рассмотрим применение межсетевых экранов (брандмауэров) (firewalls) с различными целями: от экранизации сетей, основанной на портах, до фильтрации МАС-адресов, — а также познакомимся с созданием шлюза, который будет проверять полномочия машин, основываясь на данных учетных записей. Хотя сетевая разведка и не несет прямой угрозы сети, она обычно предшествует атаке. В этой главе мы узнаем, как обмануть тех, кто пытается собирать информацию об узлах вашей сети, а также рассмотрим способы обнаружения «подслушивателей», проводящих мониторинг сети в поисках лакомого кусочка информации.

Обнаружение ARP-спуфинга Проверьте, не представляется ли кто-нибудь вашим сервером.

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

Трюк № 3 1 . Обнаружение ARP-спуфинга

может перехватить и протоколировать трафик, направляемый другому узлу, либо обмануть цодключившихся клиентов и перехватить конфиденциальную информацию. Спуфинг1 узла наносит особенно серьезный ущерб IP-сетям, поскольку открывает широкие ворота для атак. Одной из технологий спуфинга узла в IP-сети является спуфипг протокола разрешения адресов (Address Resolution Protocol, ARP). ARP-спуфинг ограничен локальным сегментом сети и действует за счет использования способа, с помощью которого IP-адреса транслируются в аппаратные Ethernet-адреса. При отправлении IP-пакета от одного узла к другому в одном и том же физическом сегменте IP-адрес назначения должен транслироваться в МАС-адрес. МЛС-адрес — это аппаратный адрес Ethernet-карты, включенной в сеть. Для этой трансляции используется протокол разрешения адресов. Когда узлу требуется узнать Ethernet-адрес другого узла, он посылает широковещательную структуру, которая выглядит примерно так: 01:20:14.833350 arp who-has 192.168.0.66 tell 192.168.0.62 Эта структура называется ARP-запросом. При отправке его на широковещательный адрес этот запрос должны увидеть все Ethernet-устройства локального сегмента. Машина, которая удовлетворяет условиям запроса, отвечает: 01:20:14.833421 arp reply 192.168.0.66 is-at 0:0:dl:If:3f:fl Поскольку ARP-запрос уже содержит МАС-адрес отправителя, получатель может отправить отклик без выполнения еще одного ARP-запроса. К сожалению, большим недостатком ARP является то, что этот протокол не проверяет состояние (stateless). Это означает, что он не отслеживает отклики на посланные запросы и может принимать ответы даже без отправки запроса. Если кто-либо захочет принимать трафик, предназначенный другому узлу, он может посылать фальшивые ARP-отклики, определяющие соответствие выбранного IP-адреса их собственному МАС-адресу. Машины, получившие ложные ARP-ответы, не могут отличить их от истинных и начинают отправлять пакеты на МАС-адрес атакующего. Еще один побочный эффект такого поведения ARP-протокола заключается в том, что ARP-таблицы обычно используют результаты выполнения только последнего запроса. Для того чтобы продолжать использовать неверные IP-адреса, взломщику достаточно заполнить узел ARP-ответами, перезаписывающими законные ARP-ответы исходного узла. Такой тип атаки называется искажением ARP-кэша. Некоторые средства, такие как Ettercap (http://ettercap.sourceforge.net), Dsniff (http:// www.monkey.org/~dugsong/dsniff/) и Hunt (http://lln.fsid.cvut.cz/~kra/), применяют подобные технологии как для «вынюхивания» в коммутируемых сетях, так и для атаки «посредника». Конечно же, эта технология может быть применена к любым двум узлам коммутируемого сегмента, включая локальный шлюз по умолчанию. Для двунаправленного перехвата трафика между узлами А и В атакующий узел С может исказить ARP-кэш узла А, сделав так, чтобы он думал, что IP-адрес узла Получение доступа обманным путем (ситуация, когда пользователь пытается соединиться с сервером, proxy-сервером или брандмауэром, используя ложный IP-адрес).

84


В соответствует МАС-адресу узла С. После этого он искажает ARP-кэш узла В, чтобы тот считал, что IP-адрес узла А соответствует МАС-адресу узла С. К счастью, существуют методы обнаружения именно такого поведения как в совместно используемом, так и в коммутируемом Ethernet-сегменте. Одна из программ, которая поможет сделать это, — Arpwatch (ftp://ftp.ee.lbl.gov/arpwatch.tar.gz). Она выполняет мониторинг интерфейса в произвольном режиме и периодически записывает MAC/IP-пары. При обнаружении аномального поведения, например изменения одной из известных MAC/IP-пар, программа отправляет в системный протокол сигнал тревоги. Эта программа очень эффективна в совместно используемой сети, применяющей концентратор, поскольку одна машина может просматривать весь ARP-трафик. Однако в коммутируемых сетях эта программа не работает по причине однонаправленности ARP-ответа. Для достижения высокого уровня обнаружения в коммутируемой среде Arpwatch должна устанавливаться на максимальное количество машин. И все-таки вы не сможете со 100 %-ной достоверностью сказать, какой из узлов атакующий избрал в качестве своей цели. Многие современные коммутаторы позволяют определить «наблюдающий» порт, который может видеть трафик всех остальных портов. Если у вас имеется такой коммутатор, вы можете установить сервер на этот порт и просто запустить на нем Arpwatch. После загрузки Arpwatch из Интернета его можно откомпилировать и установить обычным образом, запустив # ./configure && make && make install При запуске Arpwatch на машине со множеством интерфейсов (сетевых адаптеров) необходимый интерфейс можно указать в командной строке. Это делается с помощью параметра -i: arpwatch -i iface Как только Arpwatch начнет изучать MAC/IP-пары вашей сети, вы увидите в протоколе записи, подобные этой: Nov 1 00:39:08 zul arpwatch: new station'192.168.0.65 0:50:ba:85:85:ca При изменении MAC/IP-пары вы увидите: Nov 1 01:03:23 zul arpwatch: changed ethernet address 192.168.0.65 0:e0:81:3:d8:8e (0:50:ba:85:85:ca)

Nov 1 01:03:23 zul arpwatch: flip flop 192.168.0.65 0:50:ba:85:85:ca (0:e0:81:3:d8:8e) Nov 1 01:03:25 zul arpwatch: flip flop 192.168.0.65 0:e0:81:3:d8:8e (0:50:ba:85:85:ca) В данном случае первая запись — от первого принятого ложного ARP-ответа, а две последующие записи возникли из-за состояния гонок между ложным и правильным ответами. Для облегчения работы с несколькими Arpwatch в коммутируемой среде можно посылать сообщения протоколирования в центральный системный журнал (трюк № 54), собирая все результаты в одном месте. Однако из-за того, что компьютеры могут находиться под воздействием атак, подобных той, что обнаруживает Arpwatch, на сервере с системным журналом, а также на всех узлах, на которых установлена Arpwatch, разумнее использовать статические записи ARP-таблиц (трюк № 32).

Трюк № 32. Создайте статическую ARP-таблицу

85

Создайте статическую ARP-таблицу Для борьбы со спуфингом и прочей разрушительной деятельностью используйте статические записи ARP-таблиц.

Как мы только что видели (трюк № 31), если кто-либо исказит ARP-таблицу машин вашей сети, то он сможет натворить много бед. Мы узнали, как распознать вторжение, но как предотвратить его? Одним из способов предотвратить появление неприятных последствий вторжения в сеть является создание статических записей ARP-таблиц для всех устройств локального сегмента сети. После этого ядро будет игнорировать ARP-ответы с любого IP-адреса и будет использовать только указанные МАС-адреса. Для этого можно воспользоваться командой агр, позволяющей непосредственно манипулировать записями ARP-таблиц ядра. Одна статическая запись добавляется командой агр -s ip-адрес mac-адрес Если известно, что IP-адресу 192.168.0.65 соответствует МАС-адрес 00:50:ВА:85: 85:СА, то команда должна выглядеть следующим образом: # агр -s 192.168.0.65 00:50:Ьа:85:85:са Процесс выполнения множества записей может занять много времени. Для большей эффективности необходимо добавить запись для каждого устройства сети на каждый узел, позволяющий создавать ARP-таблицы. К счастью, большинство версий команды агр в качестве входных параметров для создания статических записей могут использовать файл. В Linux это реализуется с помощью ключа -f. Необходимо лишь сгенерировать файл, содержащий пары MAC- и IP-адресов, который потом можно скопировать на все узлы сети. Для упрощения этой операции можно использовать черновой сценарий на языке Perl:

#! /usr/bin/perl #

# gen_ethers. pi


Этот сценарий поочередно «прозванивает» (ping) IP-адреса из определенного диапазона. В результате в ARP-таблице машины будет представлен каждый активный IP-адрес. После «прозвонки» IP-адресов сценарий просматривает ARP-таблицу и распечатывает пары MAC/IP-адресов в формате, удобном для помещения их в файл. Этот сценарий написан для Linux, но будет работать и в других Unix-подобных ОС. Например, если необходимо сгенерировать файл для всех IP-адресов от 192.168.1.1 до 192.168.1.255 и сохранить результаты в /etc/ethers, то необходимо выполнить следующий сценарий: # ./gen_ethers 192.168.1.1 192.168.1.255 > /etc/ethers При использовании агрс ключом -f для создания статических записей автоматически используется файл /etc/ethers, однако можно указать и любой другой. Например, для сохранения записей в /root/arp_entries команда будет выглядеть так: # arp -f /root/arp_entries Этот сценарий не является идеальным, но он может сэкономить много времени. После того как создан файл с парами MAC/IP-адресов, его можно скопировать на другие узлы и добавить команду агр в сценарий загрузки системы для его автоматического выполнения при загрузке. Основной недостаток этого метода заключается в том, что на момент исполнения сценария все устройства сети уже должны быть включены, в противном случае они не будут внесены в список. Кроме того, при частой смене машин в сети придется переделывать и заново распространять файл, что может занять больше времени, чем позволяет выиграть сам метод. Но этот способ надежно защищает от атак с искажением ARP серверы и устройства, которые не меняют свои IP- и МАС-адреса.

Межсетевой экран IMetfilter Защитите вашу сеть с помощью мощных встроенных функций межсетевого экрана ОС Linux.

Linux давно уже имеет возможность фильтрации пакетов, и сама эта ОС появилась, как только появились понятия «мощность» и «гибкость». Первое поколение программного кода фильтрации пакетов называлось ipfw (сокращение от IP firewall) и обеспечивало базовые возможности фильтрации. Из-за того что программа ipfw перестала соответствовать все более делающимся конфигурациям, в настоящее время она используется очень редко. Программа второго

Трюк № 33. Межсетевой экран Netfilter

87

поколения IP-фильтрации называлась IP chains. Она является значительно усовершенствованной ipfw и по-прежнему находит широкое применение. Программа новейшего поколения называется Netfilter. Она управляется командой iptables, используется исключительно с 2.4.x и последующими версиями ядра. Хотя Netfilter является компонентом ядра, a iptables — средством настройки пользователя, эти два понятия зачастую используются для обозначения одного и того же процесса. Важной концепцией Netfilter является цепочка, которая состоит из списков правил, применяемых к пакетам, когда они вводятся в систему, проходят по ней или покидают ее. Ядро определяет три цепочки, используемые по умолчанию, но имеется возможность определять новые цепочки правил и связывать их с ранее определенными цепочками. Цепочка INPUT применяется к пакетам, получаемым локальной системой или предназначенным для нее. Цепочка OUTPUT применяется к пакетам, передаваемым локальной системой. И наконец, цепочка FORWARD применяется всякий раз, когда пакет переправляется системой из одного сетевого интерфейса (сетевого адаптера) в другой, когда система выполняет роль маршрутизатора пакетов или шлюза, а также во всех случаях, когда пакеты не исходят из этой системы и не предназначены ей. Команда iptables используется для внесения изменений в цепочки и наборы правил Netfilter. Можно создать новую цепь, удалить существующую цепь или список правил в цепи, подавить цепь (то есть удалить все правила в цепи), а также установить для цепочки действие по умолчанию. Iptables также позволяет добавлять правила в цепочку, удалять и заменять их. Перед тем как рассматривать примеры правил, необходимо установить для цепочек поведение по умолчанию. Для этого воспользуемся параметром -Р, который определяет «политику»: # iptables -P INPUT DROP # iptables -P FORWARD DROP Это гарантирует, что через межсетевой экран смогут пройти только пакеты, удовлетворяющие указанной последовательности правил. При относительно малом числе служб, предоставляемых сетью, значительно проще явно указать все типы разрешенного трафика, чем указывать весь трафик, который необходимо запретить. Обратите внимание на то, что для цепочки OUTPUT политика по умолчанию не определена; так сделано для того, чтобы трафик за пределами межсетевого экрана обрабатывался стандартным способом. Согласно политике по умолчанию, установленной для DROP, указывается, что действительно разрешено. Это то место, где необходимо определить, какие службы должны быть доступны для внешнего мира. Что касается прочих примеров, мы разберемся, что ethO является внешним интерфейсом нашего межсетевого экрана, a eth1 — внутренним. В нашей сети имеется web-сервер (192.168.1.20), почтовый сервер (192.168.1.21) и DNS-сервер (192.168.1.18) — минимальный набор для нормальной работы сервера в Сети.


Трюк № 33. Межсетевой экран Netfilter

Первое правило разрешает передавать в нашей сети трафик, предназначенный для DNS-сервера, а второе разрешает передачу ответов от DNS-сервера за пределы сети. Для чего нужны аргументы -m state и --state? Эти два параметра позволяют воспользоваться процессором инспекции пакетоц с проверкой состояния (stateful packet-inspection engine) программы Netfilter. Использование этих параметров сообщает Netfilter, что мы хотим разрешить новое соединение для IP-назначения и указанной пары портов. При действии этих правил принимается запускающий пакет (triggering packet), и информация из него вводится в таблицу состояния. Теперь необходимо указать, что мы хотим разрешить любой исходящий трафик, связанный с этими соединениями, добавив следующее правило: # iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT Единственное, что еще нужно сделать, — разделить трафик от машин за пределами межсетевого экрана, который позволит общаться с внешним миром. Для этого необходимо определить следующее правило: # iptables -A FORWARD -m state --state NEW -i ethl -j ACCEPT Это правило вводит любое исходящее соединение из внутренней сети в таблицу состояния. Оно работает за счет поиска соответствий пакетов, поступающих на внутренний интерфейс межсетевого экрана и создающих новые соединения. Если в межсетевом экране включить несколько интерфейсов, то для внутреннего интерфейса придется использовать логический оператор NOT (то есть -i ! ethO). Теперь любой трафик, поступающий на межсетевой экран через внутренний интерфейс, соответствующий исходящему соединению, благодаря предыдущему правилу будет приниматься, поскольку это правило поместит это соединение в таблицу состояния. В этих примерах порядок ввода правил не важен. Поскольку мы оперируем с политикой отказа по умолчанию (DENY), то все наши правила имеют указатель ACCEPT. Однако если в качестве аргумента параметра -j использовать указатель DROP или REJECT, то придется быть более внимательным, чтобы гарантировать, что порядок ввода правил приведет к желаемому результату. Не забывайте, что при прохождении цепочки правил всегда запускается первое правило, которому соответствует пакет, поэтому порядок правил иногда может быть критически важным. Необходимо отметить также, что порядок правил при некоторых условиях может повлиять на производительность. Например, представленное ранее правило, совпадающее с состояниями ESTABLISHED и RELATED, должно указываться перед любыми другими правилами, поскольку оно будет совпадать значительно чаще, чем любое из правил, которое соответствует только новым соединениям. Помещение правила вперед предотвращает дальнейшее прохождение пакетов, уже связанных с соединением, по остальной части цепочки правил в поисках соответствия. Для завершения настройки межсетевого экрана необходимо разрешить перенаправление пакетов. Выполните команду # echo 1 > /proc/sys/net/ipv4/ip_forward

90


Она заставляет ядро пересылать при необходимости пакеты между интерфейсами. Для того чтобы эта операция выполнялась автоматически в ходе загрузки системы, добавьте в /etc/sysctl.conf следующую строку: net.ipv4.ip_forward=l Если ОС не поддерживает /etc/sysctl.conf, то эту команду можно поместить в один из rc-сценариев загрузки (например, в /etc/rc.local). Еще одним полезным параметром ядра является rpfilter, который помогает предотвратить 1Р-спуфинг. Он разрешает верификацию адреса источника путем проверки того, что IP-адрес любого пакета доступен через ожидаемый сетевой интерфейс. Разрешение осуществляется с помощью следующей команды: # echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter Почти так же, как мы разрешали IP-перенаправление, мы можем разрешить верификацию адреса источника, отредактировав /etc/sysctl.conf в поддерживающей его системе либо внеся изменения в re.local. Для включения rp_filter добавьте в sysctl.conf следующую строку: net.ipv4.conf.all.rp_fi1ter-1 Для сохранения всех правил их необходимо либо записать в сценарий ядра, либо использовать обычный способ распространения Linux. В ОС Red Hat это выполняется командой # /sbin/service iptables save Это сохранит все текущие активные правила фильтрации в /etc/sysconfig/iptables. Для выполнения этой же операции в Debian отредактируйте /etc/default/iptables и установите set enabl e_i ptabl es_i ni td=true. После этого запустите команду # /etc/init.d/iptables save_active После перезагрузки машины конфигурация iptables будет автоматически восстановлена.

МежсетевойэкранPacketFilterOCOpenBSD Используйте для защиты сети функции межсетевой фильтрации ОС OpenBSD.

PacketFilter (обычно называемый PF) — это система межсетевой фильтрации, доступная в ОС OpenBSD. Хотя это относительно новое усовершенствование ОС, система уже превосходит IPFilter (которой она пришла на смену) своими возможностями и удобством использования. PF имеет многие функции Netfilter. И хотя Netfilter более проста в плане расширения (с помощью модулей), PF превосходит ее возможностями нормализации трафика и расширенными функциями протоколирования. Для подключения к основной части PF необходимо использовать команду pfctl. В отличие от команды iptables, используемой для управления Netfilter в ОС Linux,

Трюк № 34. Межсетевой экран PacketFilter ОС OpenBSD

91

эта команда не используется для указания отдельных правил. Вместо этого она использует собственную конфигурацию и язык определения правил. Настраивается PF с помощью файла /etc/pf.conf. Язык определения правил очень мощный, удобный и простой в использовании. Файл pf.conf имеет семь разделов, в каждом из которых содержится определенный тип правил. Использование всех разделов не является обязательным; если определенный тип правил не требуется, этот раздел может быть просто исключен из файла. Первый раздел предназначен для макросов. В нем можно указать переменные, которые будут содержать как отдельные значения, так и список значений, используемых в последующих разделах файла настройки. Так же как переменные окружения или идентификатор языка программирования, имя макроса должно начинаться с буквы и может содержать цифры и знак подчеркивания. Вот примеры макросов: EXTJF="deO" INTJF=Mdel" RFC1918="{ 192.168.0.0/16. 172.16.0.0/12, 10.0.0.0/8 }" Обращение к макросу осуществляется добавлением к его имени префикса $: block drop quick on $EXTJF from any to SRFC1918 Во втором разделе хранятся таблицы IP-адресов, используемые в последующих правилах. Применение таблиц для перечисления IP-адресов гораздо быстрее дает нужный эффект, чем применение макросов, особенно если IP-адресов много, поскольку используемый в правиле макрос расширяется на несколько правил, каждое из которых соответствует одному значению, содержащемуся в макросе. При использовании же таблицы расширение добавляет только одно правило. Вместо использования макроса в предыдущем примере можно определить таблицу, содержащую ^маршрутизируемые RFC 1918 IP-адреса: table const { 192.168.0.0/16. 172.16.0.0/12. 10.0.0.0/8 } Ключевое слово const гарантирует, что после создания таблица не может быть изменена. Таблицы указываются в правиле в том же порядке, в котором они создавались: block drop quick on $EXT_IF from any to С помощью ключевого слова f i 1 e можно загрузить список IP-адресов: table <spammers> f i l e "/etc/spammers.table" Если вы решите не использовать ключевое слово const, то сохранится возможность добавлять адреса в таблицу: pfctl -t spammers -T add 10.1.1.1 Кроме того, адреса можно и удалять: pfctl -t spammers -T delete 10.1.1.1

92


Для вывода содержания таблицы можно запустить команду pfctl -t spammers -T show Помимо IP-адресов, могут использоваться имена узлов. В этом случае в таблицу будут помещены все действительные адреса, возвращаемые распознавателем (resolver). Следующий раздел файла настройки содержит параметры, влияющие на поведение PF. Изменением параметров можно управлять тайм-аутами (временем ожидания) сеансов, тайм-аутами дефрагментации, преобразованиями таблицы состояний, коллекцией статистики и т. д. Параметры указываются с использованием ключевого слова set. Количество параметров слишком велико для обсуждения во всех подробностях, поэтому мы рассмотрим самые необходимые и полезные. Одним из наиболее важных параметров является block-policy (политика блокировки). Этот параметр указывает поведение по умолчанию ключевого слова block. При значении drop будет сбрасывать совпадающие пакеты без предупреждения. Кроме того, может использоваться значение return, при котором соответствующие правилу пакеты будут генерировать TCP-сброс либо не достигающий ICMP пакет в зависимости от того, является ли запускающий пакет TCP или UDP. Это подобно указателю REJECT в Netfilter ОС Linux. Например, для того чтобы PF по умолчанию сбрасывал пакеты без предупреждения, добавьте в /etc/pf.conf подобную строку:

set block-policy drop Помимо установки политики блокировки для интерфейса может накапливаться дополнительная статистика (количество пакетов и байтов). Чтобы включить эту функцию для определенного интерфейса, добавьте в файл настройки строку, подобную следующей: set loginterface deO Одновременно может собираться статистика только для одного интерфейса. Если накопление статистики не требуется, имя интерфейса можно заменить ключевым словом попе. Для более эффективного использования «оживленной» сети можно изменить значения тайм-аутов сеансов. Установка более низкого значения поможет повысить производительность межсетевого экрана в сетях с большим трафиком, но за счет сброса действительно простаивающих соединений. Для установки тайм-аута (в секундах) поместите в /etc/pf.conf подобную строку:

set timeout interval 20 При такой установке любое TCP-соединение, которое простаивает более 20 с, будет автоматически сброшено. PF также может оптимизировать производительность аппаратного обеспечения на низком уровне, корректируя использование памяти в зависимости от

Трюк №*34. Межсетевой экран PacketFilter ОС OpenBSD

количества одновременно хранимых состояний либо от количества фрагментов, которые могут размещаться в памяти для повторной сборки. Например, установив количество состояний равным 2000, а количество элементов, используемых восстановителем фрагментов, — 15 000, в файл pf.conf необходимо поместить: set limit states 20000 set limit frags 15000 Можно также указать эти настройки в одной строке: set limit { states 20000, frags 15000 } Двигаясь дальше, можно увидеть, что в следующем разделе представлены правила нормализации трафика. Правила этого типа гарантируют, что пакеты, передаваемые через межсетевой экран, удовлетворяют критерию независимо от фрагментации, IP-идентификаторов, минимального времени жизни TTL и других атрибутов TCP-дейтаграммы. Правила этого раздела имеют префикс в виде ключевого слова scrub. В общем случае помещение этого ключевого слова полезно. Однако при необходимости можно достичь еще большей детализации, указывая, что необходимо нормализовать и как выполнить нормализацию. Поскольку имеется возможность использовать общий синтаксис правил фильтрации PF для определения типов пакетов, которые будут соответствовать scrub-правилу, мы в большей степени сможем нормализовать пакеты. Одна из наиболее интересных возможностей заключается в случайном распределении всех IP-идентификаторов в пакетах, выходящих из сети во внешний мир. Это гарантирует, что пассивные методы определения операционной системы, основанные на IP-идентификаторах, потерпят неудачу, пытаясь распознать операционную систему сети, защищенной межсетевым экраном. Так как эти методы опираются на анализ того, как узловая операционная система осуществляет инкрементацию IP-идентификаторов в исходящих пакетах, а наш межсетевой экран гарантирует, что все идентификаторы в пакетах, выходящих из сети, совершенно случайны, то очень сложно найти их совпадение с известным шаблоном ОС. Это также поможет предотвратить перечисление машин в среде, транслирующей сетевые адреса (network address translated, NAT). При использовании обычных IP-идентификаторов кто-либо за пределами сети может выполнить статистический анализ идентификаторов, выпускаемых NAT-шлюзом, для под, счета числа машин в частной сети. Использование случайных IP-идентификаторов позволяет избежать подобного типа атак. Для разрешения генерации в интерфейсе случайных IP-идентификаторов поместите в файл /etc/pf.conf следующую строку: scrub out on deO all random-id Кроме того, директиву scrub можно использовать для повторного воссоединения дефрагментированных пакетов перед перенаправлением их к пункту назначения. Это поможет предотвратить «ускользание» специально фрагментированных пакетов (например, накладывающихся) от систем обнаружения вторжения, расположенных с внешней стороны межсетевого экрана.

94


Для включения повторной сборки фрагментов во всех интерфейсах просто поместите в файл настройки строку scrub fragment reassemble Если есть желание ограничить воссоединение только одним интерфейсом, можно заменить ее следующей: scrub in on deO all fragment reassemble Это включит воссоединение фрагментов в интерфейсе deO. Следующие два раздела файла pf .conf определяют формирование очередей пакетов и трансляцию адресов, но, поскольку этот трюк посвящен фильтрации пакетов, мы их пропустим и окажемся перед последним разделом. Он содержит действительные правила фильтрации пакетов. В общем случае синтаксис правила фильтрации выглядит так: action direction [log] [quick] on int [af] [proto protocol] \ from src_addr [port src_port] to dst_addr [port dst_port] \ [tcpjlags] [state] В PF правило может иметь только два действия: block (блокировка) и pass (пропуск). Как говорилось ранее, политика блокировки влияет на поведение самой блокировки. Однако оно может быть изменено указанием действия в определенном правиле, например block drop или block return. Кроме того, может использоваться команда block return-icmp, которая по умолчанию возвращает сообщение о недостижимости ICMP. ICMP-тип также может указывать, в каком случае будет возвращен такой тип ICMP-сообщения. В большинстве случаев мы начинаем с политики отказа (deny policy). При этом можно позже добавить правило, разрешающее определенный трафик через межсетевой экран. Для настройки политики отказа по умолчанию для всех интерфейсов поместите в /etc/pf.conf строку block all Теперь можно добавить правила, разрешающие трафик через межсетевой экран. Сначала надо снять фильтрацию с интерфейса обратной связи. Для этого будем использовать правило pass quick on loO all Обратите внимание на использование ключевого слова quick. Обычно PF продолжает обрабатывать список правил, даже если уже найдено правило, позволяющее передать пакет для того, чтобы проверить, не существует ли далее в файле конфигурации более строгого правила, которое сбросит пакет. Использование ключевого слова quick изменяет это поведение и приводит к остановке обработки пакета при соответствии правилу, а также предпринимает указанное действие. При осторожном использовании это может в значительной степени повысить производительность набора правил.

Трюк № 34. Межсетевой экран PacketFilter ОС OpenBSD

95

Для защиты внешних узлов от спуфинга внешних адресов можно использовать ключевое слово anti spoof: antispoof quick for $INT_IF inet Далее нам необходимо блокировать любые пакеты со входа или выхода внешнего интерфейса, имеющего немарш рутазируемый IP-адрес RFC 1918. Такие пакеты, если не указаны позднее явно, будут «отловлены» нашей политикой отказа (deny policy). Однако если использовать правило, специально соответствующее этим пакетам, и использовать ключевое слово quick, мы сможем повысить производительность добавлением следующего правила: block drop quick on $EXT_IF from any to Если необходимо сделать так, чтобы трафик нашей сети предназначался для webсервера с адресом 192.168.1.20, то необходимо использовать следующее правило: pass in on $EXT_IF proto tcp from any to 192.168.1.20 port 80 \ modulate state flags S/SA Это позволит пакетам попадать на 80-й TCP-порт на сервере 192.168.1.20, только если они установят новое соединение (так как установлен флаг SYN) и введут соединение в таблицу состояния. Ключевое слово modulate гарантирует, что для сессии будет сгенерирован высококачественный начальный порядковый номер (initial sequence number), который важен, если операционная система, используемая на любом конце соединения, использует неудовлетворительный алгоритм генерации ISN. Подобным образом для передачи трафика на сервер и от сервера электронной почты, имеющего адрес 192.168.1.21, можно воспользоваться следующим правилом: pass in on $EXT_IF proto tcp from any to 192.168.1.21 \ port { smtp. рорЗ. imap2, imaps } modulate state flags S/SA

Обратите внимание на то, что в правиле может указываться несколько портов, разделенных запятыми и заключенных в фигурные скобки. Кроме того, можно использовать имя службы (определенной в /etc/services), а не указывать номер порта службы. Для включения трафика к DNS-серзеру, имеющему адрес 192.168.1.18, необходимо добавить следующее правило: pass in on $EXT_IF proto tcp from any to 192.168.1.18 port 53 \ modulate state flags S/SA При этом межсетевой экран по-прежнему осуществляет блокировку UDP DNSтрафика. Для его включения добавьте следующее правило: pass in on $EXT__IF proto udp from any to 192.168.1.18 port 53 \ keep state Обратите внимание на то, что, хотя это правило для UDP-пакетов, мы все равно используем ключевое слово state. В этом случае PF будет отслеживать соединение, используя IP-адреса источника и пункта назначения, а также пары портов.

96


Поскольку UDP-дейтаграммы не содержат последовательного номера, ключевое слово modulate не применяется. Вместо этого используется слово keep state, которое определяет, как указать инспекцию состояния, когда ISN не модулируются. Кроме того, UDP-дейтаграммы не содержат флагов; мы их просто опускаем. Теперь можно разрешить, чтобы соединение, инициируемое из внешней сети, проходило через межсетевой экран. Для этого необходимо добавить следующие правила, разрешающие трафик во внутреннем интерфейсе межсетевого экрана: pass pass pass pass

in on $INT_IF from $INT__IF:network to any out on $INT_IF from any to $INT_IF:network out on $EXT_IF proto tcp all modulate state flags S/SA out on $EXT_IF proto { icmp, udp } all keep state

Как видим, OpenBSD имеет очень мощную и гибкую систему разделения сетей. В ней имеется слишком много возможностей и функций, которые мы здесь рассмотреть не можем. Дополнительную информацию можно найти в удобной документации по PF, находящейся в сети или в справке pf.conf manpage.

Создание шлюза с проверкой полномочий Используйте PF, чтобы не допустить в сеть пользователей, не подтвердивших своих полномочий.

Шлюзы межсетевой защиты традиционно использовались для блокировки трафика от определенных служб или машин. Вместо просмотра IP-адресов и номеров портов, шлюз с проверкой полномочий позволяет регулировать двусторонний трафик от машин, основываясь на мандате1 пользователя. При использовании такого шлюза пользователь должен зарегистрироваться в сети и удостоверить свои полномочия для того, чтобы шлюз предоставил ему доступ к защищаемой сети. Это может быть полезно во многих случаях, например при ограничении интернет-доступа или ограничении доступа через беспроводный сегмент сети. При использовании ОС OpenBSD версии 3.1 такую функциональность можно реализовать за счет использования PF и ядра authpf. Использование authpf также дает возможность проводить аудит, протоколируя имена пользователей, входящих в сеть, создаваемые IP-адреса, а также время их входа в сеть и выхода из нее. Для включения проверки полномочий с помощью authpf необходимо на шлюзе создать учетную запись для каждого пользователя. Укажите в качестве ядра /usr/sbin/authpf и не забудьте добавить authpf в /etc/shells в качестве действительного ядра. Когда пользователь входит в систему через SSH, authpf получает имя пользователя и IP-адрес через окружение. После этого считывается файл шаблона, содержащий NAT и правила фильтрации, и к нему применяются имя пользователя и IP-адрес. После этого результирующие правила добавляются в исполняемую конфигурацию. При выходе пользователя из системы (то есть при вводе 1

Учетная запись с параметрами доступа пользователя, сформированными после его успешной аутентификации.

Трюк № 35. Создание шлюза с проверкой полномочий

97

Ctrl+C) созданные правила выгружаются из текущего набора правил. Ориентированный на пользователя шаблон authpf ищет правило в файле /etc/authpf/users/ $USER/authpf.rules. Глобальные шаблоны правил хранятся в /etc/authpf/authpf.rules. Записи NAT также хранятся в файле authpf. nat, расположенном в одном из этих каталогов. Когда для пользователя, который уже прошел проверку полномочий, существует шаблон, он полностью замещает глобальные правила, а не добавляется к ним. При загрузке шаблона authpf «раскроет» макрос $user_ip в IP-адрес текущего пользователя, например: pass in quick on wiO proto { tcp. udp } from $user_ip to any \ keep state flags S/SA Это конкретное правило будет пропускать весь трафик беспроводного интерфейса с только что проверенного IP-адреса пользователя. Такой подход работает хорошо при использовании политики отказа по умолчанию, согласно которой с IP-адреса, прошедшего проверку полномочий, разрешаются только начальное SSH-соединение со шлюзом и DNS. Можно ввести еще больше ограничений и разрешить через шлюз только HTTP-, DNS-трафик и трафик электронной почты: pass in quick on wiO proto tcp from $user_ip to any \ port { smtp, www, https, рорЗ. pop3s, imap, imaps } \ keep state flags S/SA pass in quick on wiO proto udp from $user_ip to any port domain После создания файла шаблона необходимо предоставить точку входа в pf.conf для правил, которые authpf с помощью PF будет создавать для оценки. Эти точки входа добавляются в pf.conf с помощью различных вариаций ключевого слова anchor: nat-anchor authpf rdr-anchor authpf binat-anchor authpf anchor authpf Обратите внимание на то, что каждый указатель (anchor) должен добавляться в раздел, к которому он применяется, — нельзя просто поместить его в конце или в начале pf.conf. Таким образом, записи nat-anchor, rdr-anchor и binat-anchor должны находиться в разделе трансляции адреса файла pf.conf. Точно так же записи указателей, применяемые только к правилам фильтрации, должны добавляться в раздел фильтрации. Теперь при регистрации в шлюзе пользователь увидит сообщение: Hello, andrew. You are authenticated from host "192.168.0.61" Кроме того, пользователь увидит содержание файла /etc/authpf/authpf.message, если он существует и доступен. Если проверить /var/log/daemon, вы также должны увидеть длинное сообщение, аналогичное сообщениям, выводимым при входе и выходе пользователя: Dec 3 22:36:31 zul authpf[15058]: allowing 192.168.0.61, \ user andrew 4 Зак. 1103


Dec 3 22:47:21 zul authpf[15058]: removed 192.168.0.61. \ user andrew- duration 650 seconds

Обратите внимание на то, что любой пользователь, имеющий локальную учетную запись, с тех пор как он присутствует в /etc/shells, может изменить свое ядро на authpf. Если требуется запретить это изменение, можно создать файл с именем пользователя и поместить его в каталог /etc/authpf/banned. Содержание этого файла будет выводиться при регистрации пользователя в шлюзе. Кроме того, можно явно разрешить работу пользователей, перечислив их имена (по одному в строке) в /etc/authpf/authpf.allow. Однако любые запрещения, указанные в /etc/ authpf/banned, имеют преимущество перед записями в authpf.allow. Поскольку для определения того, когда будут выгружены правила, относящиеся к конкретному пользователю, authpf полагается на SSH-сеанс, при настройке тайм-аутов соединений SSH-демона необходимо быть очень внимательным. Тайм-ауты должны заканчиваться настолько быстро, чтобы отменять доступ, как только это становится возможным при «устаревании» соединения. Это поможет также предотвратить соединения с системами, находящимися с внешней стороны шлюза, удерживая их открытыми в ходе проведения ARP-спуфинг-атак. Заставить OpenSSH противостоять этому можно добавлением следующих строк в sshd_config: ClientAlivelnterval 15 ClientAliveCountMax 3 Это гарантирует, что SSH-демон будет посылать клиенту запрос на отклик через 15 с после получения от клиента последних данных. Параметр ClientAliveCountMax указывает, что этот процесс будет повторяться 3 раза и в случае отсутствия отклика клиент будет отключен. Таким образом, клиент будет отключен через 45 с после того, как перестанет отвечать. Эти «дежурные» пакеты посылаются автоматически клиентским программным обеспечением SSH и не требуют никакого вмешательства со стороны пользователя. Authpf является очень мощным средством благодаря своей гибкости и интеграции с PF — «родной» системой межсетевого разделения ОС OpenBSD. Она проста в настройке и минимально загружает систему, поскольку полагается на SSH и саму операционную систему при проверке полномочий и управлении сеансами.

Межсетевой экран в Windows Да, Windows тоже можно использовать в качестве межсетевого экрана.

Возможно, вы не знали, но Windows имеет очень качественный встроенный межсетевой экран. Для его запуска необходимо открыть консоль управления (Microsoft Management Console, MMC). Это можно сделать с помощью диалогового окна Выполнить (Run), введя в нем mmc и щелкнув на кнопке ОК. После загрузки консоли вы увидите окно, подобное представленному на рис. 3.1.

Трюк № 36. Межсетевой экран в Windows

Рис. 3 . 1 . Консоль управления Windows

Щелкните на меню Консоль (Console) и выберите пункт Добавить/Удалить оснастку (Add/Remove Snap-in). Далее будет представлено диалоговое окно, имеющее кнопку Добавить (Add). После щелчка на этой кнопке появится окно со списком доступных оснасток. Прокрутите список и найдите в нем пункт Управление политикой безопасности (IP Security Policy Management) (рис. 3.2).

Рис. З.2. Добавление оснастки IP Security Policy Management

Щелкните на кнопке Добавить (Add). Появится диалоговое окно, уточняющее, чем должна управлять оснастка — локальным компьютером или доменом. Определитесь, хотите ли вы применять настройки фильтра только к локальному компьютеру или ко всему домену, и щелкните на кнопке Готово (Finish). Щелкните на кнопке Закрыть (Close) в диалоговом окне выбора оснастки (см. рис. 3.2). Теперь оснастка IP Security Policies должна быть указана в окне добавления оснасток (рис. 3.3). Щелкните на кнопке ОК для возврата в исходное окно консоли управления. Перед настройкой правил межсетевого экрана необходимо создать для них блок действий. Для этого щелкните правой кнопкой на значке IP Security Policies и выберите пункт Управление списком IP-фильтров и действиями фильтра (Manage IP

100


filter lists and filter actions). После открытия окна перейдите на вкладку Управление действиями фильтра (Manage Filter Actions) (рис. 3.4).

Рис. 3.3. Диалоговое окно добавления оснастки с загруженной оснасткой IP Security Policies

Ш1

Рис. З.4. Вкладка Управление действиями фильтра (Manage Filter Actions)

Если флажок Использовать мастер добавления (Use Add Wizard) не установлен, установите его. Щелкните на кнопке Добавить (Add), а после открытия диалогового окна мастера — на кнопке Далее (Next). После этого в качестве имени нового действия фильтра введите Block. В качестве описания введите: Блокировка доступа или что-либо подобное. После заполнения полей щелкните на кнопке Далее. Затем выберите переключатель Block и снова щелкните на кнопке Далее. После этого щелкните на кнопке Готово (Finish).Tenepb новое действие фильтра должно быть представлено в окне добавления оснастки (см. рис. 3.3). Сейчас можно щелкнуть на кнопке Закрыть (Close).

Трюк № 36. Межсетевой экран в Windows

101

После этого можно приступить к настройке правил межсетевого экрана. Щелкните правой кнопкой на значке политики безопасности и выберите пункт Создать политику IP-безопасности (Create IP Security Policy). Это приведет к включению мастера. Щелкните на кнопке Далее и заполните поля Имя и Описание (в обоих полях можно ввести FireWal 1). После заполнения полей щелкните на кнопке Далее. Теперь должен появиться флажок Активировать правило отклика по умолчанию (Activate the default response rule). Сбросьте этот флажок и щелкните на кнопке Далее. После этого щелкните на кнопке Готово. Должно появиться диалоговое окно свойств межсетевого экрана (рис. 3.5).

Рис. З.5. Диалоговое окно свойств межсетевого экрана

Для создания нового правила фильтрации сбросьте флажок Использовать мастер добавления (Use Add Wizard) и щелкните на кнопке Добавить. Появится диалоговое окно, представленное на рис. 3.6.

I IP Filter Ш

Tumel Setting ' ] Солпас(юпType ] F3ter Action

Рис. 3.6. Добавление нового правила

102


Для выбора необходимого IP-адреса щелкните на кнопке Добавить на вкладке Список IP-фильтров (IP Filter List). Это также позволит определить порты и протоколы. Если после выбора IP-адресов и портов вы захотите применить новое правило, перейдите на вкладку Действие фильтра (Filter Action) и выберите необходимое действие.

Держите сеть изолированной Используйте исходящую фильтрацию для сдерживания атак и утечки информации из сети.

Вы, вероятно, знакомы с концепцией межсетевого экранирования (firewalling) для блокировки трафика, поступающего в сеть. А какая выгода от фильтрации исходящего трафика? Например, что случится, если кто-либо прорвался на узел вашей сети и использует его в качестве платформы для атаки других сетей? Что если «червь» тем или иным образом поселился в сети и пытается инфицировать узлы Интернета? В лучшем случае вы будете получать телефонные звонки и электронные сообщения от рассерженных пользователей. К счастью, фильтрация исходящего трафика (исходящее фильтрование) помогает сдерживать такое разрушительное поведение. Исходящее фильтрование не только защитит других от атак, исходящих из вашей сети, но и усилит политики использования сети, а также гарантированно предотвратит утечку информации из вашей сети в Интернет. В большинстве случаев исходящая фильтрация столь же важна, как и фильтрация на входе. Основные руководящие принципы обеспечения исходящей фильтрации такие же, как и определяющие правила входной фильтрации, — устройства должны делать только то, для чего они предназначены, то есть почтовому серверу должно быть разрешено только обслуживать и передавать почту, web-серверу — обслуживать web-контент, а DNS-сервер должен обслуживать только DNS-запросы и т. д. Для гарантии того, что используется именно эта политика, необходимо более тщательно сдерживать упоминавшиеся ранее угрозы. Там, где это возможно, необходимо заставить клиентов пользоваться услугами внутренних служб, а не интернет-сервисов. Например, при наличии в сети собственного DNS-сервера необходимо отменить для клиентов возможность обработки имен узлов при помощи внешних DNS-серверов. Если у клиентов будет такая возможность, то существует риск, что при разрешении имени внутреннего узла через внешний DNS-сервер они «раскроют» имена внутренних узлов посторонним лицам. Например, в ОС OpenBSD это ограничение реализуется с помощью следующего правила: rdr on $INT_IF inet proto { tcp, udp } from $INT_IF:network to any port 53 -> $DNS_SERVER port 53 Конечно же, необходимо в макросе INTJF указать интерфейс, взаимодействующий с внутренней сетью, а в DNS_SERVER — IP-адрес внутреннего DNS-сервера. Аналогично, если имеется внутренний почтовый сервер, то почта компании не должна «ходить» по Интернету. Вы же не хотите, чтобы сотрудники имели возможность подключаться к серверам за пределами сети?

Трюк № 38. Проверьте ваш межсетевой экран

103

Достигается это использованием подобного правила: rdr on $INT_IF inet proto tcp from $INT_IF:network to any port 25 -> $SMTP_HOST port 25 Исходящая фильтрация помогает также предотвратить IP-спуфинг на внешнем интерфейсе, находящемся на границе сети. Можно проверить, что пакеты, покидающие вашу сеть, имеют адрес источника, попадающий в ваше адресное пространство. За счет фильтрации остального трафика вы сможете гарантировать, что любая атака типа «IP-спуфинг», выполняемая из вашей сети или маршрутизируемая через нее, будет сброшена до того, как пакеты покинут сеть.

Проверьте ваш межсетевой экран Проверьте, действительно ли межсетевой экран работает так, как вы хотели.

Итак, вы настроили межсетевой экран и выполнили поверхностное тестирование его работы. А вы проверили, что он может блокировать все, для чего предназначен? Вы не сделали этого, поскольку думали, что все и так хорошо, а проверка займет слишком много времени. К счастью, существует ftester (http:// ftester.sourceforge.net) — бесплатное средство для выполнения расширенного тестирования межсетевого экрана. Ftester состоит из трех сценариев на языке Perl. Сценарий ftest используется для генерации специальных пакетов, структура которых определяется в файле настройки (ftest.conf). Если требуется проверить, как межсетевой экран ведет себя с входящим трафиком, необходимо запустить этот сценарий на машине, находящейся за пределами проверяемой сети. Если необходимо проверить, как межсетевой экран ведет себя в отношении исходящего трафика, на машине, входящей в защищаемую сеть, нужно также запустить ftest. Еще один сценарий «слушает», как пакеты, введенные с помощью ftestd, проходят через межсетевой экран. Этот сценарий должен запускаться на машине внутри защищаемой сети, если вы проверяете межсетевой экран на проникновение извне. При проверке исходящего трафика этот сценарий необходимо запускать на внешнем по отношению к сети компьютере. Оба этих сценария ведут протоколирование посланных и полученных пакетов. После запуска теста их протоколы можно сравнить с помощью сценария freport, что позволит быстро определить, какие пакеты смогли преодолеть межсетевой экран. Для использования Ftester вам понадобятся модули Net::RawlP, Net::PcapUtils, NetPacket Perl, а также Net::Pcap, если он еще не установлен, поскольку от него зависит модуль Net::PcapUtils. Если доступен модуль CPAN Perl, то вы можете установить необходимые модули с помощью следующих команд: # perl -MCPAN -e "install Net::RawIP" # perl -MCPAN -e "install Net: :Pcap(Jtils" # perl -MCPAN -e "install NetPacket"

104


После того как модули станут доступными в системе, необходимо создать файл настройки, указывающий ftest, какие пакеты необходимо генерировать. Общая форма TCP- и UDP-пакета в ftest.conf выглядит следующим образом: source addr:source port:dest addr:dest port:flags:proto:tos где source addr и source port — IP-адрес и порт источника, a dest addr и dest port — адрес и порт получателя. Имеется возможность указать диапазон адресов в формате «нижний/верхний» либо с использованием CIDR-нотации. Диапазоны портов могут указываться в формате «нижний/верхний». В поле flags указываются настройки пакета. Действительными значениями для этого поля являются S для SYN, А для АСК, Р для PSH, U для URG, R для RST и F для FIN. Поле proto указывает используемый протокол (TCP или UDP), a tos — число для настройки Туpe-of-Service (ToS) в IP-заголовке. Иногда маршрутизаторы используют содержание этого поля для принятия решения о приоритете трафика. Дополнительную информацию о поле ToS можно найти в документе RFC 791 (http://www.ietf.org/rfc/rfcO791.txt), определяющем IP (Internet Protocol). Аналогично определяются ICMP-пакеты. Вот их общая форма: source addr:: dest addr:: :ICMP: type-.code Основным различием между двумя формами является отсутствие номеров портов и флагов в последнем. Так сделано из-за того, что ICMP не использует номера портов и флаги. Вместо этого он использует типы и коды, поэтому сюда добавлены поля type и code. В настоящее время существует более 20 типов ICMP. Вам должны быть знакомы некоторые из них: типы, используемые утилитами ping, echo (тип 8) и echo reply (тип 0), либо тип, используемый командой traceroute (тип 30). ICMP-коды по своей сути являются уточнением ICMP-типов. Не все ICMP-типы имеют связанные с ними ICMP-коды, хотя ориентировочно последние имеют тот же номер, что и тип. Дополнительную информацию об ICMP-типах и кодах можно найти в соглашении IANA (см. http://www.iana.org/assignments/ icmp-parameters). Вот содержание файла ftest.conf, который настроен на проверку всех непривилегированных TCP-портов на машине с IP-адресом 10.1.1.1: 192.168.1.10:1025:10.1.1.1:1-1025:S:TCP:О stop_si gnal=192.168.1.10:1025:10.1.1.1:22:S:TCP:О Stop__signa 1 задает полезную нагрузку пакета и сообщает ftestd, что проверка завершена. Перед запуском ftest необходимо запустить ftestd: # ./ftestd -1 ethO Теперь запускаем ftest: # ./ftest -f ftest.conf При этом будет создан файл протокола с именем ftest.log, содержащий сведения о каждом посланном пакете. Когда ftestd получает сигнал остановки, он прекра-

Трюк № 39. МАС-фильтрация с помощью Netfilter

105

щает работу. После завершения работы в протоколе (ftestd.log) можно найти прошедшие пакеты. Далее можно скопировать протоколы на одну машину и сравнить их с помощью freport. При использовании представленного ранее файла настройки и при разрешенном SSH-, SMPTP- и HTTP-трафике отчет должен выглядеть примерно так: # ./freport ftest.log ftestd.log Authorized packets:

1 - 192.168.1.10:1025 > 10.1.1.1:1 S TCP 0 2 - 192.168.1.10:1025 > 10.1.1.1:2 S TCP 0 3 - 192.168.1.10:1025 > 10.1.1.1:3 S TCP 0 При использовании межсетевого экрана с проверкой состояния (stateful firewall) также можно указать пакеты, имеющие флаг, отличающийся от SYN. Например, если в предыдущем примере вместо SYN использовать АСК или другой флаг, то он будет сброшен межсетевым экраном, поскольку для инициации соединения используются только пакеты с флагом SYN. Разумно запускать ftest всякий раз после внесения изменений в межсетевой экран либо периодически — для того, чтобы проверить правильность его работы. Поскольку сложный набор правил межсетевого экрана усложняет предсказание его поведения, ftest точно покажет, какой тип трафика разрешен.

МАС-фильтрация с помощью Netfilter

Не допускайте в сеть нежелательные машины, проверяя МАС-адрес.

Фильтрация МАС-адресов (Media Access Control, MAC) — это хорошо известный метод защиты беспроводных сетей. Этот тип фильтрации основан на принципе отказа по умолчанию: специально указываются узлы, которым разрешено соединение, остальные — не допускаются. МАС-адрес — это уникальное 48-разрядное число, которое присваивается каждому производимому Ethernet-устройству, включая устройства стандарта 802.11. Это число обычно записывается как шесть 8-разрядных шестнадцатеричных чисел, разделенных двоеточиями.

106


В дополнение к «родной» системе фильтрации IP-пакетов Netfilter Linux может осуществлять также фильтрацию МАС-адресов. Несмотря на то что точки беспроводного доступа, присутствующие на современном рынке, поддерживают ее, существует множество старых точек, которые этого не делают. МАС-фильтрация важна и в том случае, если ваша точка доступа сама по себе является Linux-машиной, использующей карты беспроводного доступа. Если межсетевой экран на основе Linux уже настроен, для включения его работы на МАС-уровне потребуется выполнить небольшие изменения. Фильтрация МАС-адресов с использованием jptables очень похожа на IP-фильтрацию и настолько же проста. Представленный далее пример показывает, как разрешить конкретный МАС-адрес, если политика межсетевого экрана настроена на DROP (см. трюк № 33): iptables -A FORWARD -m state --state NEW \ -m mac --mac-source 00:DE:AD:BE:EF:00 -j ACCEPT Эта команда разрешает любой трафик, отправляемый из сетевого интерфейса с адресом 00:DE:AD:BE:EF:00. Использование подобных правил совместно с политикой отказа по умолчанию позволяет создавать «белый список» МАС-адресов, которые смогут проходить через шлюз. Для создания «черного списка» можно использовать политику разрешения по умолчанию PI изменить МАС-адрес, соответствующий конечному правилу, на DENY (отказ). Это все очень просто, если вы заранее знаете МАС-адреса, для которых собираетесь создавать правила, а что делать, если они иеизвестны? Если имеется доступ к системе, то МАС-адрес интерфейса можно найти с помощью команды ifconfig: $ ifconfig ethO ethO Link encap:Ethernet HWaddr OO:OC:29:E2:2B:C1 inet addr:192.168.0.41 Beast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:132893 errors:0 dropped:0 overruns:0 frame:0 TX packets:17007 errors:0 dropped:0 overruns:0 carrier:0 col 1isions:0 txqueuelen:100 RX bytes:46050011 (43.9 Mb) TX bytes:1601488 (1.5 Mb) Interrupt:10 Base address:0xl0e0 Здесь представлен МАС-адрес этого интерфейса — 00:0С:29:Е2:2В:С1. Результат выполнения команды ifconfig в других операционных системах может несколько отличаться от представленного, но в некоторой степени они все похожи (пример приведен для Linux). Удаленное определение МАС-адреса системы немного сложней и может выполняться с помощью команд агр и ping. Например, для просмотра МАС-адреса, соответствующего IP-адресу 192.168.0.61, необходимо выполнить команды: $ ping -с 1 192.168.0.61 $ /sbin/arp 192.168.0.61 | awk '{print $3}' либо воспользоваться следующим сценарием: #!/bin/sh ping -с $1 >/dev/null &&'/sbin/arp $1 | awk '{print $3}' \ | grep -v Hwaddress

Трюк № 40. Блокировка «снятия отпечатков пальцев» ОС

107

При реализации МАС-фильтрации учтите, что она не защищает «от дурака». При некоторых обстоятельствах не очень сложно изменить МАС-адрес, который используется интерфейсной картой (сетевым адаптером), просто «попросив» об этом драйвер. Также существует возможность с помощью необработанных (raw) сокетов канального уровня отправлять фреймы канального уровня, содержащие фальшивый МАС-адрес. Таким образом, фильтрация МАС-адреса может рассматриваться как дополнительная мера, которую можно использовать для защиты среды. Эта фильтрация больше похожа на табличку «Вход воспрещен», чем на надежный дверной запор.

Блокировка «снятия отпечатков пальцев» ОС Поддерживайте в отношении посторонних принцип «необходимого знания»1 о вашей ОС.

Одним из наиболее лакомых для атакующего кусочков информации, который можно добыть в ходе сетевой разведки, является тип операционной системы на каждой выявленной при сканировании машине. С точки зрения взломщика, очень полезно разгадать, какие уязвимые места имеет система и какими ее изъянами можно воспользоваться. Совместно со знаниями об открытых портах, найденных в ходе сканирования, эта информация может использоваться в разрушительных целях. Использование RPC для SPARC Solaris, скорее всего, не сработает в ОС х86 Linux — программный код для демона portmap специфичен в каждой из этих систем, использующих различные процессорные архитектуры. Взломщик, вооруженный знаниями о конкретной серверной платформе, может очень эффективно использовать методики, которые позволят ему получить более высокий уровень доступа, не тратя время на перебор методов, которые не работают. Конечно, лица, выполняющие сетевую разведку, могли бы просто подключиться к любой службе, обнаруженной в ходе сканирования портов, и посмотреть, какая ОС используется на удаленной системе. Такой подход сработает, поскольку многие демоны, такие как Sendmail, Telnet и даже FTP, охотно сообщают операционную систему, в которой работают, а также номер своей версии. Несмотря на то что этот метод совершенно прост и ясен, в настоящее время он рассматривается как оставляющий следы, поскольку с помощью файлов протокола не составляет никакого труда «вычислить» любого, кто подключался к системе. Кроме того, многие службы могут быть настроены на сокрытие этой важной информации. В ответ на это было разработано множество усовершенствованных методов, не требующих для определения типа ОС полного подключения к целевой системе. Они основаны на «странностях» TCP/IP-стека операционной системы узла и его поведении при отклике на определенные типы пакетов. Из-за того что разные операционные системы по-разному откликаются на эти пакеты, можно 1

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

108


с большой степенью вероятности «угадывать», на какой ОС основана работа конкретного сервера, не оставляя следов в файлах протокола. К счастью, «пробные» пакеты могут блокироваться межсетевым экраном, что расстраивает попытки определить ОС этим способом. Одним из наиболее известных средств определения типа ОС является программа Nmap (http://www.insecure.org/nmap/), позволяющая не только определять тип ОС, запущенной на удаленной системе, но и выполнять различные типы сканирования портов. Определение ОС производится запуском программы Nmap с ключом -0. Вот результат сканирования системы OpenBSD 3.3: # nmap -0 puffy Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-12-02 19:14 MST Interesting ports on puffy (192.168.0.42): (The 1653 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 13/tcp open daytime 22/tcp open ssh 37/tcp open time 113/tcp open auth Device type: general purpose Running: OpenBSD 3.X OS details: OpenBSD 3.0 or 3.3 Nmap run completed -- 1 IP address (1 host up) scanned in 24.873 seconds Для пресечения попыток сканирования с помощью Nmap можно использовать правила межсетевого экрана, блокирующие пакеты, используемые для зондирования ОС. Их легко обнаружить, поскольку некоторые из них имеют недействительные сочетания TCP-флагов. Ряд тестов, проводимых Nmap, невозможно блокировать с помощью PF, лишь добавив правила блокировки, но их можно перехватить, используя фильтрацию с проверкой состояния или применяя для набора правил политику отказа по умолчанию. Такие меры необходимы из-за того, что тесты используют TCP-параметры, которые невозможно выделить с помощью PF. Для блокировки попыток снять «отпечатки пальцев» в ОС OpenBSD можно использовать подобные правила (в файле /etc/pf.conf): set block-policy return block block block block block block

in in in in in in

log log log log log log

quick proto tcp flags FUP/WEUAPRSF quick proto tcp flags WEUAPRSF/WEUAPRSF quick proto tcp flags SRAFU/WEUAPRSF quick proto tcp flags /WEUAPRSF quick proto tcp flags SR/SR quick proto tcp flags SF/SF

Этот прием также имеет побочный эффект протоколирования всех попыток в отношении интерфейса pflogO. Даже если мы не можем блокировать все проверки с помощью Nmap, то можем протоколировать хотя бы наиболее неординарные попытки и, возможно, нейтрализовать их, представив неполную картину поведе-

PU (Resp=YXDF=NXTOS=0XIPLEN=38%RIPTL=134%RID=E^RIPCK=F^UCK-E%ULEN-134%DAT=E) Nmap run completed -- 1 IP address (1 host up) scanned in 27.028 seconds

Как видим, на этот раз попытка оказалась неудачной. А если вы чувствуете, что этого может оказаться недостаточно? Что если вы действительно хотели бы использовать прием, после которого атакующий будет уверен, что сервер работает под совершенно иной ОС? Например, было бы полезно настроить «приманку» (трюк № 94), отпугивающую негодяев от критических серверов. Если вам пока смешно, читайте дальше.

Обман программ удаленного определения ОС

Не позволяйте удаленно определять тип вашей ОС, изменив облик TCP/IP-стека

Еще один метод, являющийся преградой на пути попыток удаленного управления, — изменение поведения TCP/IP-стека и эмулирование работы другой ОС. Возможно, это кажется сложным, но в Linux реализуется очень просто: внесением

110


изменения в ядро с помощью программного кода проекта IP Personality (http:// ippersonality.sourceforge.net). Этот код расширяет встроенную систему межсетевого экрана (Netfilter), а также ее пользовательский интерфейс — команду iptables. Для настройки IP Personality загрузите из Сети пакет, соответствующий вашему ядру. Если подходящий пакет найти не удается, посетите страничку обновлений компании SourceForge (http://sourceforge.net/tracker/?group_id=7557&atid=307557), на которой можно найти самые свежие обновления. Для корректировки ядра распакуйте исходный код IP Personality и перейдите в каталог, содержащий исходный текст ядра, после чего запустите команду # cd /usr/src/linux # patch -pi < \ ../ippersonality-20020819-2.4.19/patches/ippersonality-20020819-linux-2.4.19.diff При использовании обновления, загруженного со страницы обновлений (patches page), просто подставьте его в команду выполнения обновления. Для проверки успешности обновления запустите команду # find ./ -name \*.rej При верном выполнении обновления эта команда не должна найти ни одного файла. Теперь ядро исправлено, и необходимо настроить в нем поддержку IP Personality. Как упоминалось в описании трюка «Блокировка ядра с помощью grsecurity» (см. трюк № 13), запуск команд make xconfig, make menuconfig или даже make config при нахождении в каталоге исходного кода ядра позволяет настроить само ядро. Независимо от выбранного вами метода меню параметров не изменится. Прежде всего, убедитесь, что взведен флажок Prompt for development and/or incomplete code/drivers (Предупреждать о разработке и/или незавершенности кода/драйверов) в разделе Code maturity level options (Параметры уровня готовности кода). В разделе Networking Options (Параметры сети) найдите и установите параметр Netfilter Configuration (Конфигурация Netfilter). Список, выводимый командой make xconfig, представлен на рис. 3.7. Найдите параметр с подписью «IP Personality Support» и выберите либо у для статической компиляции его в ядро, либо m для создания динамически загружаемого модуля. После настройки поддержки IP Personality сохраните конфигурацию. Теперь откомпилируйте ядро и модули, а затем установите их с помощью подобных команд: # make dep && make clean # make bzlmage && make modules # cp arch/i386/boot/bzlmage /boot/vmlinuz # make modules_install Теперь перезагрузите новое ядро. Помимо исправления ядра, необходимо также скорректировать пользовательскую часть Netfilter — команду iptables. Для этого посетите web-сайт Netfilter (http://www.netfilter.org) и загрузите версию, соответствующую версии пакета IP Personality. Например, для версии Netfilter Version 1.2.2 необходимо использовать команду iptables, входящую в состав ippersonality-20020819-2.4.19.tar.gz.

111

Трюк № 4 1 . Обман программ удаленного определения ОС

ХЖ

|

t*ext

|

JPrev

Рис. З.7. Включение поддержки IP Personality

1

После загрузки и распаковки необходимой версии ее необходимо скорректировать с помощью программы исправления, входящей в состав пакета IP Personality, после чего скомпоновать и установить обычным способом: # tar xfj iptables-1.2.2.tar.bz2 # cd iptables-1.2.2 # patch -pi < \ ../ippersonality-20020819-2.4.19/patches/ippersonality-20020427-iptables-\ 1.2.2.diff patching file pers/Makefile patching file pers/example.conf patching f i l e pers/1ibipt_PERS.с patching f i l e pers/pers.h patching f i l e pers/pers.l patching f i l e pers/pers.y patching f i l e pers/pers_asm.c patching f i l e pers/perscc.c # make KERNEL_DIR=/usr/src/linux && make i n s t a l l

При этом б^дет установлена обновленная версия команды iptables, которая поддерживает библиотеки и справочник manpage, располагающийся в иерархии /usr/local. Если вы хотите изменить заданные по умолчанию каталоги, можно отредактировать Makefile и изменить значения макросов BINDIR, LIBDIR, MANDIR и INCDIR. Проверьте, соответствует ли значение KERNEL_DIR каталогу, содержащему исходный код построенного ранее ядра.

Трюк № 42. Ведите учет объектов сети

113

111/tcp open rpcbind 139/tcp open netbios-ssn 505/tcp open mailbox-lm 631/tcp open ipp Device type: general purpose Running: Apple Mac OS 9.X OS details: Apple Mac OS 9 - 9.1 Uptime 3.095 days (since Tue Dec 9 16:19:55 2003) Nmap run completed -- 1 IP address (1 host up) scanned in 5.274 seconds

Ведите учет объектов сети

Конечно же, можно эмулировать и другиеустройства ОС, которые не предусмотрены С помощью Nmap отслеживайте и службы вашей сети. пакетом IP Personality. Все, что нужно сделать для этого, — скопировать файл «отпечатков пальцев» операционной системы утилитой Nmap (nmap-os-fingerprints), мы построить видели присобственный рассмотрениифайл трюка «Блокировка «снятия отпечатков аКак затем настройки IP Personality для любойпальОС, ОС» знает (см. трюк оцев» которой Nmap.№ 40), Nmap (http://www.insecure.org/nmap/), это бесплатное средство, которое может использоваться для выполнения различного типа сканирования сетей. Обычно Nmap рассматривается как программа, которая используется для различного рода сетевой разведки или подготовки к атаке. Но, как и все мощные средства, Nmap может использоваться не только для нарушения работы сетей. Например, простое сканирование TCP-подключений может выполняться без наличия root-привилегий: $ nmap rigel Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-12-15 17:42 MST Interesting ports on rigel (192.168.0.61): (The 1595 ports scanned but not shown below are in state: filtered)

114


Nmap run completed -- 1 IP address (1 host up) scanned in 75.992 seconds Проверять состояние собственных машин крайне полезно. Возможно, вы догадались, что это сканирование было выполнено на Solaris-машине. Nmap может также сканировать диапазоны IP-адресов, указанных в CIDR-нотации: nmap 192.168.0.1-254 nmap 192,168.0.0/24 Nmap может предоставить еще больше сведений, если будет запущена с root-привилегиями. В этом случае при использовании флага -0 могут использоваться специальные пакеты, позволяющие определить ОС на удаленной машине. Кроме того, с помощью флага -sS можно выполнять полуоткрытое TCP-сканирование. При этом Nmap посылает на удаленный узел SYN-пакет и ожидает приема от него АСКпакета. Если получен АСК, значит, порт открыт. В этом состоит отличие такого сканирования от нормального трехэтапного ТСР-«рукопожатия», при котором клиент посылает SYN-пакет, а затем отправляет обратно на сервер полученный от него начальный АСК-пакет. Взломщики обычно используют эту возможность для того, чтобы избежать попадания в протокол удаленной машины. Попробуйте сами: # nmap -sS -0 rigel Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) Interesting ports on rigel.nnc (192.168.0.61): (The 1578 ports scanned but not shown below are in state: filtered)

Трюк № 43. Проверка надежности сети

115

Remote operating system guess: Solaris 9 Beta through Release on SPARC Uptime 44.051 days (since Sat Nov 1 16:41:50 2003) Nmap run completed -- 1 IP address (1 host up) scanned in 166 seconds При возможности определения ОС Nmap подтвердила, что операционной системой является Solaris, но теперь известно, что это, скорее всего, девятая версия, выполняемая на SPARC-процессоре. Одна из мощнейших функций, которая может помочь в отслеживании работы сети, — это возможность вывода результатов в XML. Она активизируется с помощью ключа -оХ: # nmap -sS -0 -оХ scandata.xml rigel

Эта функция особенно полезна при сканировании диапазона IP-адресов по всей сети, поскольку с ее помощью можно собрать все сведения в один XML-файл, который затем можно анализировать и добавить в базу данных. Вот как представлен в XML один открытый порт: <port protocol="tcp" portid="22"> <state state="open" /> <service name="ssh" method="table" conf="3" /> Nmap — очень мощное средство. При выводе результатов в XML, написании небольшого сценария и использовании базы данных вы можете создать более серьезное средство, которое будет наблюдать за появлением в сети несанкционированных служб и машин.

Ш

Проверка надежности сети

Используйте Nessus для быстрого и простого сканирования сети служб, уязвимых для атак.

Как администратор сети вы должны знать не только узлы и запущенные на них службы, но и устойчивы ли эти службы к атакам. Если Nmap (см. трюк № 40) может лишь показать машины и порты, доступные в сети, то сканер безопасности, такой как Nessus (http://www.nessus.org), может сказать, устойчивы ли машины к известным посягательствам.

116


В отличие от обычного сканера портов, сканер безопасности сначала находит «слушающие» службы, а затем подключается к ним и пытается выполнить в отношении них все известные ему действия. После этого сканер фиксирует успешность попыток и продолжает работать, пока не протестирует все доступные службы. Ключевое преимущество программы заключается в том, что вы сразу узнаете, устоит ли система против самых распространенных посягательств и сможет ли она противостоять атаке. Если хватит смелости, то установите Nessus вводом следующей команды: $ lynx -source http://install.nessus.org | sh Это полностью автоматизированная установка, но не самая рациональная, поскольку вы не знаете, что же будет выполняться на вашей системе, пока действительно не запустите Nessus. Более разумный способ установки с сохранением преимуществ автоматического установщика — загрузить сценарий nessus-installer.sh и вручную запустить его. После этого нужно уточнить, куда произвести установку (по умолчанию — /usr/local), у вас также будет запрошен root-пароль. Сценарий создаст временное SUID-ядро, которое будет доступно только с помощью учетной записи пользователя. Сначала это может вызвать тревогу, но вам будет сообщено имя файла этого ядра, поэтому вы сможете убедиться, что оно на самом деле доступно только вам и будет удалено по завершении установки. Установив Nessus, необходимо создать для него пользователя (он несколько отличается от пользователя Unix). Поскольку Nessus использует клиент-серверную модель, необходимо сгенерировать сертификат, позволяющий зашифровать все соединения. Для создания нового Nessus-пользователя запустите nessus-adduser. Вам будет предложено указать имя и пароль. Для создания сертификата запустите nessus-mkcert либо, если у вас имеется собственный сертификат полномочий (Certificate Authority, CA) (трюк № 45), можно воспользоваться им. При использовании собственного СА необходимо отредактировать nessus.conf, указав в нем, где искать СА-сертификат и сгенерированный ключ. Обычно файл настройки располагается в /etc или /usr/local/etc. Для указания местоположения СА-сертификата добавьте подобные строки: cert_fiIe=/etc/ssl/nessus.key key_fi1e=/etc/ssl/nessus.crt ca_fi1e=/etc/ssl/ca.crt Если вы сгенерировали пару «сертификат/ключ» и использовали пароль, этот пароль можно указывать следующим образом: pem_password=mypassword После выполнения всех подготовительных мероприятий можно запустить демон Nessus. Это наиболее важная операция, в ходе которой Nessus действительно будет сканировать узлы сети. Запуск можно провести следующей командой: # /usr/local/sbin/nessusd -D


117

Теперь можно запустить Nessus-клиент и подключить его к серверу. Существует несколько доступных клиентов, включая интерфейс командной строки, приложение XII и Windows-клиент. Здесь представлен вид в интерфейсе XII. Запуск клиента производится просто вводом nessus. После этого появится окно, подобное представленному на рис. 3.8. t:; О О

\ Nessus Setup

Рис. 3.8. Установка Nessus-клиента

В окне требуется заполнить необходимые сведения о пользователе и щелкнуть на кнопке Login (Вход). После этого откроется диалоговое окно, позволяющее проверить сведения, содержащиеся в сертификаторе сервера. Для выбора типов сканирования слабых мест в системе защиты перейдите на вкладку Plugins (Надстройки) (рис. 3.9). В верхней панели можно включить или отключить различные типы сканирования, а в нижней — отключить отдельные проверки на уязвимость, относящиеся к выбранному в верхней панели типу. Необходимо отметить, что перечисленные в нижней панели проверки, помеченные восклицательным знаком, потенциально могут привести к крушению сервера, к которому будут применены. Если вы хотите разрешить все проверки', кроме этих, щелкните на кнопке Enable all but dangerous plugins (Разрешить все, кроме опасных). Если вы запускаете Nessus на некритичной машине, можно оставить эти варианты сканирования включенными.

118


но вас предупредили! Некоторые типы проверок можно отключить, если только вы не сканируете группу машин с большим разнообразием служб. В противном случае Nessus потратит лишнее время на сканирование служб, которые не запущены. Например, если вы хотите сканировать Solaris-систему, то смело можете отключить надстройки CGI abuses, CISCO, Windows, Peer-To-Peer File Sharing, Backdoors, Firewalls, Windows User Management и Netware.

Рис. З.9. Выбор надстроек Nessus

Для более полного тестирования служб нужно предоставить Nessus учетные сведения о различных службах. Таким образом, Nessus сможет действительно зарегистрироваться в проверяемой службе и иметь такой же доступ, как и обычный пользователь. Используемые в работе Nessus учетные записи указываются на вкладке Prefs (Предпочтения) (рис. 3.10).


119

Рис. 3.10. Вкладка Prefs

Кроме того, можно указать использование грубого подбора регистрационных данных (brute-force logins) для сканируемых служб. Это может быть хорошим тестом не только для самой службы, но и для системы обнаружения вторжения (intrusion detection system, IDS) (трюк № 82), а также системных протоколов. Вкладка Scan options (Параметры сканирования) позволяет указать порядок сканирования портов. Лучше не изменять значения по умолчанию большинства этих настроек, если только вы не заметили, что Nessus обходит обнаружение сканируемых узлов. Например, по умолчанию Nessus настроен на полное сканирование TCP-соединения и «прозвонку» (ping) удаленного сканируемого узла. Такое поведение можно изменить с помощью вкладки Scan options, установив SYN scans вместо TCP connect и отключив PING. Для указания проверяемых узлов используется вкладка Target selection (Выбор цели).

120


После завершения этой операции запустите сканирование, щелкнув на кнопке Start the scan (Пуск сканирования), расположенной в нижней части окна. Теперь откроется окно, представленное на рис. 3.11. В данном случае Nessus выполняет сканирование Solaris-машины.

Рис. 3 . 1 1 . Выполнение проверки на уязвимость

Результат сканирования представлен на рис. 3.12.

Рис. 3.12. Результат сканирования

Трюк № 44. Синхронизация серверных часов

121

Для сканирования множества подсетей их необходимо указать на панели Subnet (Подсеть). Все узлы, входящие в выбранную подсеть, появятся на панели Host (Узел). Аналогично, при выделении узла в панели Port (Порт) появится список открытых портов. Их можно выделять для просмотра предупреждений, примечаний и возможных «дыр» в безопасности, независимо от выбранного порта. Просмотреть дополнительные сведения о проблемных портах можно с помощью панели Severity (Серьезность). Не поднимайте тревогу, увидев большое количество примечаний и предупреждений. В основном они информируют о запущенных службах и сообщают, является ли служба потенциально уязвимой. «Дыры» в системе безопасности более серьезны и обязательно должны устраняться. Для сохранения отчета щелкните на кнопке Save report (Сохранить отчет). Nessus позволяет сохранять отчет в различных форматах. Если вы хотите позже снова просмотреть отчет в Nessus, необходимо выбрать его собственный формат (NBE). Сохраненные в этом формате отчеты загружаются с помощью кнопки Load report (Загрузить отчет), расположенной в основном окне клиента. Кроме того, отчет можно сохранить в форматах XML, HTML, ASCII и даже LaTeX. И хотя Nmap является чемпионом по определению узлов и портов, Nessus идет еще дальше и демонстрирует уязвимость служб к известным атакам. Конечно же, постоянно «всплывают» все новые типы посягательств, поэтому необходимо периодически обновлять надстройки Nessus, поддерживая их актуальность. С помощью Nessus можно защитить собственные службы от попыток «плохих парней» проникнуть в них.

Синхронизация серверных часов Анализ протоколов упрощается, если время в сети синхронизировано.

Соотнесение событий, происшедших на нескольких серверах, может стать трудным занятием, если между часами машин существует расхождение. Поддержание синхронности часов может сохранить много времени при анализе протоколов маршрутизатора, межсетевого экрана или узла после компрометации или при разрешении ежедневных сетевых осложнений. К счастью, синхронизации машин легко добиться с помощью NTP — Network Time Protocol (протокол сетевого времени). NTP — это равноправный протокол, предназначенный для обеспечения вторичной точности между часами узлов. Дистрибутив, в котором содержатся демон синхронизации, а также вспомогательные средства, можно загрузить с адреса: http://www.ntp.org/downloads.html. Хотя обычно NTP входит в состав различных версий Linux, FreeBSD и OpenBSD в качестве дополнительного пакета или порта, он может быть установлен в системе, поэтому проверьте ваш дистрибутив или дерево портов: не установлен ли он уже. Если его нет в варианте вашей ОС, вы можете загрузить и откомпилировать его самостоятельно.

122


Настройка ntpd в качестве клиента очень проста. Однако сначала необходимо проверить, существует ли локальный сервер времени в вашей сети или у вашего провайдера Интернета. Если нет, его необходимо найти. Не волнуйтесь, список общедоступных серверов времени имеется на странице http://www.eecis.udel.edu/ ~mills/ntp/servers.html. При поиске сервера вам придется столкнуться с новым термином — stratum (ступень) (например, stratum 1 или stratum 2). Это ссылка на иерархию сервера в общей NTP-инфраструктуре. Сервер stratum 1 — это, как правило, машина, имеющая прямой доступ к источнику временной синхронизации, например к GPS или сигналу атомных часов, выполняющих обновление демона, запущенного на этой машине. Серверы stratum 2 синхронизируются по серверам stratum 1. Использование серверов второго уровня позволяет снизить нагрузку на серверы первого уровня, но все равно обеспечивает достаточный для наших целей уровень точности. Помимо прочего, необходимо искать серверы, которые географически располагаются как можно ближе к вам. Учитывая изложенное, давайте найдем несколько NTP-серверов (если один откажет, рационально использовать два и более). Я живу в Колорадо, поэтому, связавшись со списком серверов второго уровня (http://www.eecis.udel.edu/~mills/ntp/ clock2a.html), я нашел два варианта: # US CO ntpl.linuxmedialabs.com Location: Linux Media Labs LLC. Colorado Springs, CO Service Area: US Synchronization: NTP Secondary (stratum 2), i686/Linux Access Policy: open access Contact: [email protected] Note: ntpl is an alias and the IP address may change, please use DNS # US CO ntpl.tummy.com Location: tummy.com, ltd., Fort Collins, CO Service Area: US Synchronization: NTP Secondary (stratum 2), i686/Linux Access Policy: open access. Contact: [email protected] Note: ntpl is an alias and the IP address may change, please use DNS. Since they're both listed as open access, I can just add them to /etc/ntp.conf: server ntpl.linuxmedialabs.com server ntpl.tummy.com Кроме того, ntpd может автоматически корректировать определенный сдвиг частоты часов вашей машины. Это делается путем изучения среднего смещения в ходе получения сообщения о синхронизации. Для включения этой функции добавьте в ntp.conf подобную строчку: d r i f t f i l e /etc/ntp.drift Конечно, при условии, что вы держите все настроечные ntpd-файлы в /etc/ntp, то следует использовать /etc/ntp/ntp.drift. Вот и все, просто добавьте ntpd в сценарий запуска, запустите его — и все готово.

Трюк № 45. Создание собственного сертификата полномочий

123

Создание собственного сертификата полномочий Выпишите собственный сертификат полномочий для использования его при шифровании в сети.

Считается, что SSL-сертификаты обычно используются для защиты соединений по протоколу HTTP. Однако они полезны также как средство проверки достоверности и как средство начального обмена ключами для множества других служб, которым требуется шифрование, таких как POP и ШАР (трюк № 47), SMTP (трюк № 48), IPsec (глава 6) и, конечно же, SSL-каналы (трюк № 76). Для самого эффективного использования SSL необходимо правильно управлять собственными сертификатами. Если SSL-клиент хочет проверить подлинность SSL-сервера, сертификат, используемый сервером, должен быть подписан сертификатом полномочий (Certificate Authority, CA), который уже подтвержден клиентом. Существуют хорошо известные СА (такие, как Thawte и VeriSign), которые при проверке полномочий играют роль официальной, доверительной третьей стороны. Они участвуют в подписании SSL-сертификатов, которые используются на сайтах, содержащих важнейшую информацию (номера учетных записей или пароли). Если SSL-сертификат сайта подписан заслуживающим доверие «авторитетным источником», то, по-видимому, существует возможность проверить достоверность сервера, предоставив мандат этого сертификата. Однако самоподписанных (self-signed) сертификатов обычно достаточно для получения всех преимуществ обеспечения безопасности, предоставляемой SSL, за исключением приложений электронной коммерции. Но даже самоподписанный сертификат должен быть подписан «авторитетным источником», который признается клиентом. OpenSSL (бесплатная реализация SSL) прекрасно подходит для генерации всего, что необходимо для выпуска собственного С А. Утилита CA.pl значительно упрощает этот процесс. В представленных далее примерах то, что выделено жирным шрифтом, вы должны вводить сами. При необходимости также необходимо вводить пароль (набор на экране не дублируется). Для учреждения нового СА-сертификата сначала измените на mjsc/ каталог, в который установлен OpenSSL (/System/Library/OpenSSL/ под OpenBSD; /usr/ssl/ или /usr/local/ssl/ на большинстве Linux-систем). После этого воспользуйтесь следующими командами: $./CA.pl -newca СА certificate filename (or enter to create) Making CA certificate ... Generating a 1024 bit RSA private key

124


Открытый ключ для нового С А содержится в файле cacert.pem, а закрытый ключ — в private/cakey.pem. Теперь частный ключ можно использовать для подписи других SSL-сертификатов. По умолчанию CA.pl создает ключи со сроком годности 1 год. Для изменения этого поведения отредактируйте CA.pl и измените строку $DAYS="-days 365": Кроме того, можно вовсе отказаться от использования CA.pl и сгенерировать частный и публичный ключи вручную с помощью команды $ openssl req -new -x509 -keyout cakey.pem -out \ cakey.pem -days 3650 Эта команда создаст пару ключей со сроком годности 10 лет, который также можно изменить с помощью ключа -days. Кроме того, вы могли бы изменить разрешение частного ключа на 600, для того чтобы его никто не смог прочитать. 1

Вас попросят ввести сведения, которые будут включены в запрос на сертификат. То, что вы введете, называется отличительным именем (Distinguished Name, DN). Существует лишь несколько полей, но некоторые из них можно оставить незаполненными. Для некоторых полей существуют значения по умолчанию. Если ввести «.», то поле останется пустым.

Трюк № 45. Создание собственного сертификата полномочий

125

До сих пор мы занимались лишь созданием СА. Для действительного создания ключей, которые можно использовать в службах, необходимо создать запрос на подпись сертификата и ключ. Опять же, это можно сделать с помощью CA.pl. Сначала создадим запрос на подпись сертификата: $ ./CA.pl -newreq-nodes Generating a 1024 bit RSA private key

Теперь таким же образом вы можете устанавливать ключи для каждого сервера, который должен предоставлять SSL-защищенную службу. Это проще сделать, если выделить отдельную рабочую станцию для обслуживания СА и всех файлов, связанных с ним. Не забудьте распространить свой СА-сертификат во все программы, к которым требуется доверие (трюк № 46).

Распространение СА среди клиентов Убедитесь, что все ваши клиенты доверяют новому СА.

После создания СА (см. трюк № 45) любой сертификат, подписанный вашим С А, будет вызывать доверие в любой программе, доверяющей вашему СА. Для установления этого доверия необходимо распространить СА-сертификат во все программы, которые должны доверять ему. Это могут быть почтовый клиент, установки IPsec либо web-браузер. Поскольку SSL использует криптографию с открытым ключом, нет необходимости держать публичный ключ в секрете. Его можно просто установить на web-сервере и загрузить всем клиентам по открытому HTTP. Так как инструкции по установке СА-сертификата различаются для

Трюк № 47. Шифрование 1МАР и POP с помощью SSL

127

каждой программы, далее мы рассмотрим быстрый и простой способ установки СА на web-браузеры. Существует два формата, в которых браузеры могут воспринимать новые сертификаты: pern и der. Сертификаты der можно сгенерировать из существующего pern с помощью одной openssl-команды: $ openssl x509 -in demoCA/cacert.pem -outform DER -out cacert.der Также добавьте в файл conf/mime.types сервера Apache следующую строку: application/x-x509-ca-cert

der pem crt

Теперь, для того чтобы изменения вступили в силу, перезагрузите Apache. Сейчас можно поместить оба файла, cacert.der и demoCA/cacert.pem, на web-сервер, и клиенты смогут установить новый сертификат, просто щелкнув на ссылке. Ранние версии Netscape воспринимали только pem-формат, а в свежих версиях воспринимаются оба. В Internet Explorer все как раз наоборот: ранние версии воспринимали только der-формат, новые — оба. Остальные браузеры обычно воспринимают по одному формату. При загрузке нового СА в браузер появится диалоговое окно, уточняющее, хотите ли вы продолжить. Все, что необходимо сделать, — это подтвердить принятие сертификата. Теперь SSL-сертификат, подписанный вашим СА, будет восприниматься без предупреждения пользователя. Учтите, что СА воспринимается непросто. Если в браузере вы приняли новый СА, лучше доверять ему полностью — вредоносный менеджер СА мог бы подписать все типы сертификатов, которым вы не доверяете, но браузер никогда не пожалуется (поскольку вы потребовали дшеряэт» импортируемым СА). Будьте очень осторожны с теми, кто расширяет доверие при использовании SSL-браузеров. Лучше проверить СА-кэш браузера, чтобы уточнить, кому определено доверие по умолчанию. Например, вы слышали о том, что AOL/Time Warner имеет свой собственный СА? A GTE? Или VISA? СА-сертификаты всех этих компаний (и многих других) поставляются с версией Netscape 7.0 для Linux и все они являются доверенными полномочиями для web-сайта, электронной почты и надстроек приложений по умолчанию. Учитывайте это при посещении SSL-сайтов: если полномочия по умолчанию подписали сетевое содержание, то ваш браузер будет доверять им, не запрашивая подтверждения у оператора. Если вы цените безопасность браузера (и безопасность всей клиентской машины), то возьмите за правило просматривать отношения доверительных СА. Роб Фликитер (Rob Flickenger) «Трюки Linux-сервера» («Linux Server Hacks»)

Шифрование 1МАР и POP с помощью SSL Защитите электронную почту от посторонних глаз с помощью РОРи IMAP-паролей.

Размещение электронной почты на ШАР-сервере — это самый разумный вариант, когда необходимо иметь возможность обращаться к ней из разных мест. В отличие от POP, протокол IMAP хранит всю почту и любые создаваемые папки на

128


сервере, поэтому вы можете обращаться к любой своей корреспонденции независимо от используемого почтового клиента (программы обмена почтой). Можно даже воспользоваться web-интерфейсом, что делает почту доступной практически с любой машины, имеющей браузер и соединение с Интернетом. Но, скорее всего, при этом вам придется пройти через ненадежные сети. Как защитить пароль электронной почты и саму почту от нежелательных посягательств? Конечно же, с помощью шифрования! Если у вас уже установлен ШАР- или POP-демон, не имеющий возможности использовать SSL в чистом виде, то можно воспользоваться stunnel (см. трюк № 76), чтобы создать оболочку для службы в виде SSL-канала. Если вы начинаете «с нуля», то можете насладиться выбором демона, имеющего SSL-подержку, скомпилированную непосредственно в двоичный файл. Одним из демонов, которые изначально поддерживают SSL, является демон University of Washington's I MAP, известный также под именем UW-IMAP (http://www. washington.edu/imap/). IMAP-демон включен в пакет установки программного обеспечения IMAP. Для компиляции и установки ШАР-демона загрузите из Сети tar-архив и запустите команды: $ tar xfz imap.tar.Z $ cd imap-2002e $ make lnp SSLDIR=/usr SSLCERTS=/usr/share/ssl/certs Аргумент Makefile указывает, для системы какого типа идет компоновка. В нашем случае lnp — это сокращение от Linux-PAM. Другими популярными системами являются bsf — FreeBSD, bso — OpenBSD, osx — Mac OS X, sol — Solaris и gso — Solaris with GCC. Переменная SSLDIR используется для установки базового каталога для установки OpenSSL. По умолчанию Makefile настроен на использование каталога /usr/local/ssl с помещением библиотек в /usr/local/ssl/lib, а заголовочных файлов — в /usr/local/ssl/include. Если OpenSSL установлена вместе с операционной системой и вы хотите продолжить ее эксплуатировать, необходимо использовать SSLDIfWusr (как в примере). Переменная SSLCERTS применяется для указания демонам imapd и popd местонахождения SSL-сертификатов. Если компиляция прервется с ошибками, найдите сообщение, подобное этому: In file included from /usr/include/openssl/ssl.h:179. from osdep.c:218: /usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory In file included from /usr/include/openssl/ssl.h:179. from osdep.c:218: Это означает, что компилятор не может найти заголовочные файлы системы Kerberos, что является распространенной проблемой в новых версиях Red Hat Linux. Ошибка возникает по причине того, что файлы расположены в каталоге /usr/kerberos/include, нестандартном для системы.

Настройка SMTP с TLS Защитите находящуюся в пути почту ваших клиентов от подсматривания.

Если вы настроили шифрование POP и ШАР (см. трюк № 47), входящая почта ваших клиентов будет защищена от тех, кто проникнет на серверы, а что происходит с защитой исходящей почты? Защитить исходящую почту можно настройкой 5 Зак. 1103

1

Системная программа пересылки электронных почтовых отправлений.

Трюк № 48. Настройка SMTP с TLS

131

какой сертификат и ключ необходимо использовать, когда он действует в качестве сервера (то есть получает почту от MUA или другого почтового сервера). Последние две строки указывают Sendmail, какие сертификат и ключ необходимо использовать, когда он действует в качестве клиента (то есть передает почту на другой почтовый сервер). Обычно после этого можно заново скомпоновать sendmail.cf, введя make sendmai 1 .cf при нахождении в каталоге /etc/mail. Теперь выполните kill sendmail и перезапустите его. После перезапуска проверьте правильность установки TLS, подключившись к нему: # telnet local host smtp Trying 127.0.0.1... Connected to local host.. Escape character is I A J \ 220 mail.example.com ESMTP Sendmail 8.12.9/8.12.9; Sun, 11 Jan 2004 12:07:43 -0800 (PST) ehlo localhost 250-mail.example.com Hello IDENT:614ZhaGP3Qczqknqm/KdTFGsrBe2SCYC(?localhost [127.0.0.1], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH DIGEST-MD5 CRAM-MD5 250-STARTTLS 250-DELIVERBY 250 HELP QUIT 221 2.0.0 mail.example.com closing connection Connection closed by foreign host. Когда Sendmail передает почту другому почтовому серверу, поддерживающему TLS, почта будет шифроваться. Теперь все, что необходимо сделать, — настроить почтового клиента на использование TLS при подключении к почтовому серверу, после чего почта пользователей будет защищена на всем пути до МТА. У нас не хватит места рассматривать каждый из существующих МТА, поскольку почти все они поддерживают несколько вариантов TLS. Если запустить Exim (http://www.exjm.org) или Courier (http://www.courier-mta.org), то вы сможете построить TLS-поддержку прямо «с иголочки». Postfix (http://www.postfix.org) имеет TLS-поддержку и предназначен для совместного использования с Cyrus-SASL (см. раздел HOWTO на http://postfix.state-of-mind.de/patrick.koetter/smtpauth/). Qmail имеет на http://inoa.net/qmail-tls/ обновление RFC 2487 (TLS). Когда TLSподдержка имеется практически у всех МТА-агентов и почтовых клиентов, нет никаких оснований отправлять почту в «открытом» виде.

132


Удаленное обнаружение Ethernet-анализатора Обнаружьте потенциальных «шпионов» в сети и не доверяйте скомпрометированным машинам.

Ethernet-анализаторы (sniffers) — один из самых мощных инструментов в арсенале защиты сети. Однако в «плохих» руках они могут стать весьма серьезной угрозой безопасности сети. Анализаторы могут быть как внутренними, так и злонамеренными внешними нарушителями, но тем не менее после обнаружения системы они, скоре всего, приступают к анализу («вынюхиванию») локальной сети. Такая сетевая разведка помогает этим «шпионам» находить следующую цель или просто собирать лакомые кусочки информации (например, имена и пароли пользователей, адреса электронной почты и другие важные сведения). Еще не так давно было распространенно мнение, что только Ethernet-сети с совместно используемой средой (shared-medium) уязвимы перед анализаторами. Эти сети использовали центральный концентратор, который осуществлял повторное вещание каждого передаваемого пакета на каждый порт концентратора. При таком типе настройки каждый фрейм, посылаемый любым узлом сети, принимался каждым узлом локального сегмента сети. После этого каждый сетевой адаптер узла (интерфейс) быстро проверял, является ли он пунктом назначения. Если нет, то фрейм отвергался, если да, то фрейм проходил через стек сетевого протокола и обрабатывался приложением. По этой причине анализ трафика другой сети был довольно простым делом. Поскольку весь трафик попадал на каждую систему, надо было лишь отключить проверку, выполняемую сетевым адаптером, и система получала доступ к трафику, предназначенному для других. Обычно это называлось переводом сетевого адаптера в беспорядочный режим1 и выполнялось привилегированным пользователем. Со временем широкое распространение получили коммутируемые (switched) Ethernet-сети, и совместно используемая среда больше не применяется. Таким образом, исчез основной источник проблемы. В отличие от концентраторов, Ethernet-коммутаторы отправляют трафик только на то устройство, которому он предназначен. Для этого при прохождении трафика коммутатор изучает, какому выходному порту соответствует МАС-адрес сетевого устройства. Когда коммутатор видит Ethernet-фрейм с определенным МАС-адресом пункта назначения, он просматривает, какой порт коммутатора ему соответствует, и направляет фрейм только на этот порт. При этом коммутатор эффективно создает виртуальное соединение между отправляющей и принимающей станциями каждый раз при передаче фрейма по сети. Таким образом, фрейм увидит только та машина, которой он предназначен. И все бы хорошо, но некоторые аспекты Ethernet-спецификации и TCP/IP могут вызвать проблемы. Одна из проблем заключается в том, что коммутатор может 1

Состояние, в котором сетевой адаптер обнаруживает в сети все фреймы вне зависимости от их конечного адреса.

Трюк № 49. Удаленное обнаружение Ethernet-анализатора

133

запоминать только ограниченное количество МАС-адресов. Максимальное же их число зачастую может быть на несколько порядков больше, чем число портов, имеющихся в коммутаторе, позволяющих подключаться к последующей иерархии. Для эффективной работы каждый коммутатор должен запоминать МАС-адреса, доступные с других коммутаторов. Например, у вас имеется коммутатор на 24 порта (коммутатор А), к которому подключено 23 машины, а к 24-му порту подключен другой коммутатор. Этот коммутатор (коммутатор В) имеет 48 портов, к 47 из которых подключены машины. В этом случае коммутатор А будет изучать МАОадреса 47 систем на коммутаторе В и ассоциировать их с 24-м портом, а коммутатор В будет изучать МАС-адреса 23 систем, подключенных к коммутатору А, и связывать их с 48-м портом. Даже если средний коммутатор может запомнить несколько тысяч МАС-адресов, по-прежнему сохраняется возможность переполнения таблицы адресов, вызванного генерацией большого объема трафика с ложными МАС-адресами. Такая тактика желанна для злонамеренного пользователя, поскольку многие коммутаторы при переполнении таблицы МАС-адресов вернутся к поведению, характерному для концентраторов. Как только такое произойдет, сеть перестанет отличаться от сегмента совместно используемой среды. После этого вредитель сможет анализировать сеть, переведя свой сетевой адаптер в «беспорядочный режим». К счастью, для того чтобы такой подход сработал, сеть необходимо заполнить фиктивным трафиком, который может быть пассивно отмечен, например, средством Arpwatch (см. трюк № 31). Создание потока пар MAC- и IP-адресов приведет к тому, что Arpwatch заполнит системный протокол. При своевременном просмотре протоколов эту атаку будет невозможно не заметить. Как упоминалось в трюке «Обнаружение ARP-спуфинга» (см. трюк № 31), Arpwatch также может определить искажения в ARP-таблице. Это делает его эффективным средством обнаружения двух самых распространенных типов ARP-атак: переполнения ARP и искажения ARP. Еще один способ наблюдения за коммутируемыми сетями заключается в изменении МАС-адресов сетевых адаптеров Ethernet в анализируемой системе. В Linux и множестве других Unix-подобных ОС это можно сделать с помощью команды ifconfig: # /sbin/ifconfig ethl ethl Link encap:Ethernet HWaddr 00:EO:81:03:D8:8F BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 col 1isions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:11 Base address:0xlc80 # /sbin/ifconfig ethO hw ether 00:DE:AD:BE:EF:00 # /sbin/ifconfig ethl ethl Link encap .-Ethernet HWaddr 00:DE:AD:BE:EF:00 BROADCAST MULTICAST MTU:1500 Metric:l RX packets:0 errors:0 dropped:0 overruns:0 frame:0

134

Глава 3. Сетевая безопасность ТХ packets:0 errors:0 dropped:0 overruns:0 carrier;0 collision$:0 txqueuelen:100

RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:11 Base address:0xlc80 Основная цель этой операции — обмануть коммутатор и заставить его отправлять трафик на два различных узла сегмента. Иногда это делается «на авось», поскольку различные коммутаторы ведут себя по-разному, когда в сети обнаруживаются два одинаковых МАС-адреса. Коммутатор может переслать трафик на оба порта, непредсказуемо распределить трафик между ними, вообще прекратить передачу трафика или сгенерировать ошибку. Все эти методы обнаруживаются и блокируются коммутаторами с более развитой системой управления, которые позволяют указать, какие МАС-адреса допустимы для каждого отдельного порта. Эта функция иногда называется защитой порта (port security). Однако даже если взломщик не станет прибегать к этим методам, он по-прежнему может собирать крупицы сведений, просто переключив сетевой адаптер в «беспорядочный режим». Например, широковещательный трафик DHCP- и ARP-запросов все так же будет посылаться на все порты коммутатора. Этот трафик не очень легко обнаружить, если только вы не знакомы с инфраструктурой. Одним из средств, помогающих обнаружить сетевые адаптеры, работающие в «беспорядочном режиме» как в коммутируемых, так и в некоммутируемых сетях, является sniffdet (http://sniffdet.sourceforge.net). Для средства, которое служит только одной цели, sniffdet является многосторонним, так как может обнаруживать «шпионов» различными способами. Основное отличие sniffdet от средств типа Arpwatch заключается в том, что sniffdet ищет «разведчиков» активно, то есть если предполагается, что на машине запущен анализатор, то можно запустить sniffdet и задать проверку режима адаптера именно на этой машине. Для компоновки и установки sniffdet необходимо иметь библиотеку инжекции пакетов libnet (http://www.packetfactory.net/projects/libnet/). Обязательно загрузите последнюю версию 1.0.x, поскольку libnet версии 1.1 несовместима с программами, написанными для версий 1.0.x. Для компиляции libnet распакуйте исходный код и перейдите в каталог, созданный при распаковке. После этого запустите команду $ ./configure && make После завершения компиляции получите root-полномочия и введите make install. Компоновка sniffdet также обычна. Как и при установке libnet, необходимо распаковать исходный дистрибутив и перейти в созданный каталог, после этого скомпоновать и установить его. Sniffdet имеет несколько методов определения того, что целевая машина работает в качестве анализатора («вынюхивателя»). Однако только два из них будут работать с повторяющимися и предсказуемыми результатами — ARP- и DNS-тесты. ARP-тест основан на том, как стек протокола «вынюхивающей» системы поступает с ARP-запросами, находясь в «беспорядочном режиме».

Трюк № 49. Удаленное обнаружение Ethernet-анализатора

135

При запуске этого теста sniffdet отправляет ARP-запрос на целевую машину. Этот запрос имеет неверные МАС-адреса источника и пункта назначения, но использует верный IP-адрес проверяемой машины. Если целевая машина находится в «беспорядочном режиме», ARP-запрос с ложным МАС-адресом пройдет через стек протокола, и эта машина пошлет отклик. Если машина не в «беспорядочном режиме», то этот запрос будет спокойно сброшен. Такой метод эффективен как в коммутируемых, так и в некоммутируемых сетях. Давайте рассмотрим, как sniffdet с машины colossus (192.168.0.64) сканирует sirius (192.168.0.2) (две машины, находящиеся в одной коммутируемой сети). Вот результат выполнения sniffdet в отношении sirius: colossus # sniffdet -i ethO -t arp sirius Sniffdet Report Generated on: Wed Dec 31 03:49:28 2003 Tests Results for target sirius Test: ARP Test (single host)Check if target replies a bogus ARP request (with wrong MAC) Validation: OK Started on: Wed Dec 31 03:49:08 2003 Finished on: Wed Dec 31 03:49:28 2003 Bytes Sent: 252 Bytes Received: 0 Packets Sent: 6 Packets Received: 0 RESULT: NEGATIVE

136


Number of valid tests: #1 Number of tests with positive result: #1 DNS-тест работает подобным образом, особенно в сетях с совместно используемой средой (на основе концентраторов либо в беспроводных сетях). Однако он основан на разрешении имен, включенном у «вынюхивателя». При выполнении DNS-теста sniffdet посылает лавину пакетов, содержащих IP-адрес, не используемый в данной сети. Если разрешение имен включено, то «шпион» попытается выполнить обратный поиск с целью определения имени узла, соответствующего этому IP-адресу. А поскольку эти адреса не существуют, sniffdet определит, что целевая машина, просматривающая DNS-запросы, находится в «беспорядочном режиме». Этот тест может выполняться так же, как и ARP-тест, но вместо ключа -t arp используется -t dns.

Установка Apache с SSL и suEXEC Помогите обеспечить безопасность web-приложений, установив mod_ssl и suEXEC.

Безопасность web-сервера является очень важной проблемой современности, особенно если учесть, что возникает все большее количество вариантов использования Сети. При использовании любого web-приложения, которое должно проверять достоверность информации или ограничивать доступ к ней, требуется внимательно отнестись к установке web-сервера с SSL-функциями. Без SSL любые сведения, подтверждающие полномочия пользователей, посылаемые на web-сервер, отправляются в открытом режиме и могут быть просмотрены «шпионом». Если у вас уже используется Apache, то с помощью mod_ssl (http://www.modssl.org) можно просто добавить возможности SSL. Кроме того, если web-сервер предоставляет динамическое содержание множеству пользователей, можно обеспечить suEXEC-функциональность. С помощью

Трюк № 50. Установка Apache с SSL и suEXEC

137

suEXEC web-сервер выполняет серверные сценарии как владеющий ими пользователь, а не от имени учетной записи, под которой запущен web-сервер. В противном случае любой пользователь мог бы создавать сценарии и запускать код от имени учетной записи, под которой запущен web-сервер. Это очень плохо, особенно на многопользовательском web-сервере. Если не просматривать созданные сценарии перед их запуском,„пользователи могут написать программный код, позволяющий им обращаться к данным других пользователей или к другой важной информации, такой как учетные записи и пароли баз данных. Для компиляции Apache с mod_ssl загрузите из Сети исходный дистрибутив mod_ssl для используемой версии Apache. (Если вы не хотите добавлять mod_ssl в существующее дерево Apache, необходимо также загрузить и распаковать дистрибутив Apache.) После этого распакуйте mod_ssl и перейдите в созданный им каталог. Затем запустите подобную команду: # ./configure \ --with-apache=../apache_l.3.29 \ --with-ssl=SYSTEM \ --prefix=/usr/local/apache \ --enable-module=most \ --enable-module=mmap_static \ --enable-module=so \ --enable-shared=ssl \ --disable-rule=SSL_COMPAT \ --server-uid=www \ --server-gid=www \ --enable-suexec \ --suexec-caller=www \ --suexec-uidmin=500 \ --suexec-gidmin=500

' •

Эта команда скорректирует дерево исходного кода Apache предоставляемыми mod_ssl расширениями и настроит Apache на процесс компоновки. Для компоновки Apache вам, вероятно, придется изменить ряд параметров. Путь, указанный в ключе --with-apache, должен указывать на каталог, содержащий исходный код Apache необходимой версии. Кроме того, если необходимо использовать еще не установленную версию OpenSSL, укажите необходимость размещения ее дерева компоновки в ключе --with-ssl. Ключи --server-uid и --server-gid используются для указания пользователей или групп, которые могут запускать web-сервер. По умолчанию Apache подчиняется учетной записи nobody (никто). Однако мноще программы, настройки которых позволяют сбрасывать привилегии, также по умолчанию подчиняются учетной записи nobody. Если в конце концов вы примете значения по умолчанию для всех программ, то эта учетная запись станет самой привилегированной. Поэтому рекомендуется создать отдельную учетную запись для каждой программы, которая имеет такую возможность. Остальные параметры предназначены для настройки suEXEC. Для обеспечения suEXEC-функциональности при выполнении сценариев пользователя Apache

138


использует программу-оболочку SUID. Перед тем как разрешить выполнение программы эта оболочка выполняет ряд проверок. Одним из проверяемых элементов является UID вызывающего процесса. Если он не соответствует учетной записи, указанной в ключе --suexec-caller, то выполнение пользовательского сценария прерывается. Поскольку suEXEC-оболочка вызывается web-сервером, этот параметр должен иметь то же значение, что и --server-uid. Кроме того, поскольку наиболее привилегированные учетные записи и группы системы обычно имеют UID и GID меньше определенного значения, то suEXEC-оболочка проверит: не меньше ли этого порога UID или GID вызывающего процесса. Для того чтобы это работало, необходимо указать соответствующее значение системы. В данном примере Apache и mod_ssl компонуются на системе Red Hat, в которой UID и GID обычных пользователей и групп начинаются со значения 500. В дополнение к этим проверкам suEXEC выполняет множество других проверок: доступен ли сценарий для записи только его владельцу, не является ли владелец root-пользователем, не является ли сценарий SUID или SGID. По завершении настройки сценария укажите каталог, который содержит исходный код Apache, и запустите команды make и make install. Можно запустить make certificates, если хотите сгенерировать SSL-сертификат для проверки установки. Для генерации запроса на подпись сертификата с помощью коммерческого СА либо собственного СА можно запустить make certificate TYPE=custom (см. трюк № 45). После установки Apache его можно запустить с помощью команды # /usr/local/apache/bin/apachectl startssl Если необходимо запустить Apache без SSL, выполните команду # /usr/local/apache/bin/apacectl start Проверить работу suEXEC можно с помощью команды # grep suexec /usr/local/apache/logs/errorjog [Thu Jan 1 16:48:17 2004] [notice] suEXEC mechanism enabled (wrapper: /usr/local/apache/bin/suexec) А теперь для разрешения использования CGI-сценариев из пользовательских каталогов добавьте элемент Directory, аналогичный следующему: AllowOverride Filelnfo AuthConfig Limit Options MultiViews Indexes SymLinksIfOwnerMatch Includes ExecCGI Order allow.deny Allow from all Order deny,allow Deny from all

140


за счет того, что Apache вызывает специальную SUID-оболочку (например, /usr/ local/apache/bin/suexec), которая может вызываться только процессом Apache. Если вы стремитесь к обеспечению компромисса безопасность/производительность при использовании suEXEC, а необходимость запуска Perl-сценария по-прежнему сохраняется, то это можно реализовать с помощью стандартного CGI-интерфейса. С помощью этого интерфейса, помимо Perl, можно запускать и PHP-программы, но для этого необходимо создать библиотеку php и указать ее в качестве интерпретатора во всех PHP-сценариях, которые должны выполняться с помощью suEXEC. Сценарии можно запускать и с помощью модуля mod_perl или mod_php, поместив их вне каталогов, в которых будет работать suEXEC.

ЗащититеBIND Заблокируйте установку BIND, чтобы избежать потенциальных проблем безопасности.

Из-за того что BIND не слишком преуспела в обеспечении безопасности, при ее использовании вам, вероятно, придется приложить немало усилий для соответствующей настройки. Один из способов сделать работу BIND несколько безопасней — это запустить ее в среде «песочницы»1. Это очень просто реализуется с последними версиями BIND, поскольку они изначально поддерживают запуск непривилегированным пользователем с помощью команды chroot(). Все, что необходимо сделать, — это настроить каталог, который предполагается использовать в chrootO, а затем изменить команду, используемую для запуска группы named, от имени которой будет осуществляться запуск. Для начала создайте пользователя и группу, от имени которой будет осуществляться запуск (то есть named). Для подготовки среды «песочницы» необходимо создать соответствующую структуру каталогов. Создать каталоги для такой среды в /named_chroot можно с помощью команд: # mkdir /named_chroot # cd /named_chroot # mkdir -p dev etc/namedb/slave var/run После этого необходимо скопировать каталоги named.conf и namedb в «песочницу»: # ср /etc/named.conf /named_chroot/etc # cp -a /var/namedb/* /named_chroot/etc/namedb

Предполагается, что файлы зоны (zone files) хранятся в /var/namedb. Если BIND настраивается в качестве вторичного DNS-сервера, то каталог /named_chroot/etc/ namedb/slave необходимо сделать доступным для записи, чтобы named мог обновлять содержащиеся в нем записи при переносе домена с главного DNS-узла. Это можно сделать с помощью подобной команды: # chown -R named:named /named chroot/etc/namedb/slave 1

Механизм обеспечения безопасности, Предусматривающий изоляцию на время выполнения загружаемого кода в ограниченную среду — «песочницу» (sandbox).

142


Если вы не хотите глобально ограничивать зональные переносы и вместо этого хотите указать узлы, на которые разрешен перенос по принципу «зона на зону», поместите раздел разрешения переноса (allow-transfer section) внутри раздела зон (zone section). Перед тем как попытаться воспользоваться уязвимостью BIND, атакующий сначала уточняет версию BIND, подключившись к серверам имен и выполнив запрос версии. Поскольку вам никогда не приходится запрашивать версию у сервера имен, то можно изменить отклик, посылаемый запрашивающему. Для этого добавьте значение версии в раздел параметров (options section) файла named.conf, например: version "SuperHappy DNS vl.5"; Обратите внимание на то, что на самом деле это не обеспечивает дополнительную безопасность, но если вы хотите рекламировать на весь мир используемое программное обеспечение, то можете не пользоваться данной технологией. СМ. ТАКЖЕ Раздел «Securing BIND» книги «Building Secure Servers with Linux», написанной Michael D. Bauer (издательство O'Reilly).

БезопасностьMySQL Основные действия по защите MySQL.

MySQL (http://www.mysql.com) — одна из самых популярных в настоящее время систем баз данных с открытым исходным кодом. Зачастую она используется совместно с web-сервером Apache и языком сценариев РНР, позволяя создавать динамические веб-страницы. В то же время MySQL —часть программного обеспечения сложной структуры, и ей часто приходится взаимодействовать локально или удаленно с разнообразными программами, поэтому для ее защиты должны предприниматься самые эффективные специальные меры. К некоторым действиям по защите можно отнести запуск MySQL в среде с помощью команды chroot (см. трюк № 10), запуск ее от имени nonroot-пользователя и отключение возможности в MySQL загружать данные из локальных файлов. К счастью, реализовать любой из этих методов не так сложно, как может показаться сразу. Для начала рассмотрим использование команды chrootO. Создайте пользователя и группу для запуска MySQL. После этого загрузите исходный дистрибутив MySQL, распакуйте его и перейдите в созданный им каталог. Запустите команду по компоновке MySQL и настройте ее структуру каталогов для выполнения команды chroot О: $ ./configure --prefix=/mysql --with-mysqld-Idf1ags=-al 1 -static && make При этом MySQL будет размещен в /mysql и статически связан с mysqld. Это значительно облегчит настройку структуры каталогов, поскольку в нее не придется

Трюк № 52. Безопасность MySQL

143

копировать дополнительные библиотеки. По завершении компиляции получите полномочия root и запустите команды установки MySQL: # make install DESTDIR=/mysql_chroot && In -s /mysql_chroot/mysql /mysql # scripts/mysql_install_db Первая команда устанавливает MySQL, но вместо /mysql она поместит файлы в /mysql_chroot/mysql. Кроме того, она создаст символическую ссылку (symbolic link) из этого каталога в /mysql, что значительно упростит администрирование MySQL. Вторая команда создает базу данных по умолчанию. Если бы перед запуском этой команды не была создана символическая ссылка, то выполнение сценария mysql_install_db завершилось бы неудачей (он ожидает размещения MySQL в /mysql). To же самое произошло бы и с другими программами и сценариями, поэтому создание символической ссылки значительно упрощает жизнь. Теперь для корректной работы MySQL необходимо настроить необходимые разрешения каталога. Для этого выполните следующие команды: # chown -R root:mysql /mysql # chown -R mysql /mysql/var Запустим MySQL: # /mysql /bin/mysqld_safe&

144 Глава 3. Сетевая безопасность А сейчас попробуем запустить mysqld в chroot-среде: # /usr/sbin/chroot /mysql_chroot /mysql/1ibexec/mysqld -u 100 Здесь UID пользователя, от имени которого запускается mysqld, указывается в параметре -и. Он должен соответствовать UID созданного ранее пользователя. Для упрощения управления можно изменить сценарий mysqld_safe на chroot mysqld. Это выполняется путем поиска строк, в которых вызывается mysqld, и замены их командами с использованием программы chroot. Для этого откройте /mysql/bin/mysqld_safe и найдите подобный блок строк: if test -z "$args" then $NOHUP_NICENESS $ledir/$MYSQLD $defaults \ --basedir=$MY_BASEDIR_VERSION \ --datadir=$DATADIR $USER_OPTION \ --pid-file=$pid_file --skip-locking »[mysqld] $err_log 2>&1 # локальных Замените Теперь if сервера. chroot/tmp/mysql MySQL-программ Кроме Вероятно, else then ffi test /mysql/bi i eval $NOHUP_NI $ledir/$MYSQLD --datadir=$DATADIR --basedir=$MYJASEDIRJERSION --pid-file=$pid_file --basedir=$MY_BASEDIR_VERSION --datadir=$DATADIR --pid-file=$pid_file того, -z можно Например, "SNOHUPJICENESS "$NOHUP_NI его "$args" вы n/mysqld_safe файлов. C можно ENESS следующим захотите запустить .sock CENESS указывать /usr/sbin/chroot $defaults создать Sdefaults вДля для /etc/my.cnf $USER_OPTION $USER_OPTI $USER_OPTI отключить --user=100 /usr/^bin/chroot $ledir/$MYSQLD этого MySQL --skip-locking того, блоком: --skip-locking отдельный \егочтобы вO ввручную. раздел с\Nразделе упомощью /mysql_chroot \\MySQL файл не$defaults $args »приходилось /mysql_chroot [client] my.conf $err_log возможность сценария-оболочки » $err_log $err_log \файла можно для 2>&1 My каждый \ /mysql_chroot/etc/my.cnf указать 2>&1" 2>&1" SQL-утилит загружать раз socket mysqld_safe: при данные и =MySQLзапуске /mysql_ из

Трюк № 53, SFS в Unix

145

необходимо добавить set-variable=l ocal -i nf i 1е=0. Это приведет к отключению команды LOAD DATA LOCAL INFILE. Кроме того, ее можно отключить из командной строки с помощью параметра --local-infile=0.

SFSвUnix Используйте SFS для обеспечения безопасности удаленных файловых систем.

При использовании Unix-систем и совместной работе с файлами в сети вы, скорее всего, применяете NFS. Однако при этом возникает множество проблем безопасности, касающихся не только отдельных реализаций, но и структуры самого протокола. Например, если пользователь может подставить ложный IP-адрес и смонтировать общий NFS-ресурс, предназначенный только для определенного компьютера, то он получит root-доступ ко всем файлам, расположенным на этом ресурсе. Кроме того, NFS применяет секретные дескрипторы файлов, используемые при каждом файловом запросе. Поскольку NFS не шифрует свой трафик, то взломщик может довольно легко опознать дескрипторы. При правильном опознании он, по существу,'может получить полный root-доступ к удаленной файловой системе. SFS (http://www.fs.net) (Self-certifying File System) устраняет все эти проблемы, применяя совершенно иную философию. NFS построена на принципе возможности (необходимости) доверия в сети. SFS с самого начала разрабатывалась с учетом предположения, что никто в сети не имеет доверия, пока он явно не подтвердит свою аутентичность. Для реализации этого принципа SFS использует открытые ключи как на клиентской, так и на серверной стороне. Они используются для проверки идентичности серверов и клиентов, а также для управления доступом на серверной стороне. Один из приятных побочных эффектов столь сильного шифрования заключается в том, что SFS обеспечивает более четкий уровень контроля доступа, чем NFS. При использовании NFS существует ограничение на количество узлов, которые можно подключить или не подключить к данной файловой системе. Для предоставления доступа к SFS-серверу пользователь должен создать пару ключей, а затем подтвердить их достоверность, зарегистрировавшись на SFS-сервере вручную. Компоновка SFS может потребовать много дискового пространства. Перед попыткой скомпоновать SFS убедитесь, что в файловой системе, где будет компилироваться SFS, имеется не менее 550 Мбайт свободного дискового пространства. Также необходимо убедиться в том, что у вас установлена GMP (http:// www.swox.com/gmp/) (GNU multiple precision) — библиотека математики с многократно увеличенной точностью. Перед компоновкой SFS для SFS-демона необходимо создать пользователя и группу. По умолчанию и группа и пользователь называются sfs. Если вы хотите изменить это имя, его необходимо указать в качестве параметра настроечного сценария.

148


Помимо этого, если уже имеется пара ключей на другом сервере, можно ввести sfskey user@otherserver. Это приведет к извлечению ключа с удаленной машины и регистрации его на сервере, на котором вы только что зарегистрировались. После регистрации ключа на сервере можно зарегистрироваться на SFS-сервере с другой машины. Это делается также с помощью программы sfskey: $ sfskey login [email protected] Passphrase for [email protected]/1024: SFS Login as [email protected] Now try to access the remote server: $ cd /Sfs/@colossus.nnc,fd82m36uwxj6m3q8tawp56ztgsvu7g77 $ Is home Как можно отметить, SFS — очень мощное средство совместного использования файлов в сети и даже в Интернете. Оно не только обеспечивает безопасность, но и предоставляет уникальный и универсальный способ обращения к удаленному узлу и его экспортированной файловой системе. На SFS-сервер можно даже поместить домашний каталог, просто связавшись с универсальным именем пути экспортированной файловой системы /home.

Г Л А В А

Протоколирование Трюки № 54-60 Протоколирование — очень важный аспект поддержания безопасности сети, поскольку протоколы помогают во всем: от предупреждения о подготавливаемой атаке до отладки сетевых проблем. После инцидента протоколы помогают отследить, каким образом проник взломщик, изучить, какие машины подверглись атаке, и устранить эту «дыру» в системе безопасности. Кроме того, протоколы помогают отследить источник атаки, что позволяет идентифицировать «незваного гостя» и предпринять законные действия в отношении него. Короче говоря, файлы протоколов ценятся на вес золота. Раз так, то степень их защиты должна быть не меньше, чем у другой информации, хранящейся на сервере (например, у схемы вашего «вечного двигателя»). Эта глава в основном посвящена различным вариантам настройки удаленного протоколирования: настройке простой централизованной программы syslogd, с помощью которой протоколируется работа всех серверов, настройке Windows-машины на отправку сведений в syslogd и программы syslog-ng, собирающей протоколы с удаленных сайтов по защищенному TCP-соединению. Применяя эти методы, вы гарантируете, что протоколы безопасно размещены на предназначенном для них сервере, на котором выполняется минимальный набор служб, что, в свою очередь, снижает риск их изменения. Что же делать с протоколами после того, как все они собраны в одном месте? В этой главе рассматриваются способы обобщения протоколов в простые для прочтения и восприятия отчеты, с помощью которых легко опознать самую необходимую информацию. Этот способ вам может показаться недостаточно оперативным. Однако мы также изучим, как настроить генерацию сигналов тревоги в реальном масштабе времени при возникновении критического события. Немедленная реакция на событие (а не на его окончание, зафиксированное в отчете, который вы прочтете на следующее утро) может сэкономить несколько часов работы.

Запуск централизованного syslog-сервера Обеспечьте защиту протоколов от взломщиков, храня их на удаленной машине.

После того как «незваный гость» вошел в одну из ваших систем, как узнать, когда это произошло и было ли вообще? Конечно же, проверкой протоколов. А что если нарушитель изменил протоколы? В этом случае вам поможет централизованное

150


протоколирование. Если атакующему удалось проникнуть на машину, но факт проникновения фиксируется не на этой машине, ему будет очень сложно скрыть следы. Помимо обеспечения дополнительного уровня защиты, просто очень удобно просматривать протоколы машин всей сети, когда они находятся в одном месте. Для быстрой настройки централизованного syslog-сервера просто запустите программу syslogd с ключом, задающим «прослушивание» сообщений от удаленной машины по UDP-порту. В ОС Linux это делается с помощью параметра -г: # /usr/sbin/syslogd -m 0 -г В GC FreeBSD запустите syslogd без параметра -s: # /usr/sbin/syslogd Параметр -s в FreeBSD запрещает «прослушивание» удаленных соединений. Программа syslogd ОС FreeBSD также позволяет указать, с каких узлов будут восприниматься сообщения. Для установки этого ограничения воспользуйтесь параметром -а, имеющим следующие формы: ipaddr/mask[:service] domainC:service] *domain[:service] Первая форма позволяет указывать отдельный IP-адрес или группу IP-адресов с помощью соответствующей маски. Параметр service позволяет указать UDP-порт источника. Если ничего не указывать, то по умолчанию используется порт 514, который специально предназначен для службы протоколирования. Следующие две формы позволяют ограничить доступ к определенному доменному имени, что определяется обратной подстановкой IP-адреса соединяющегося узла. Отличие третьего варианта от второго состоит в использовании группового символа *, указывающего на то, что могут подключаться все машины домена. ОС OpenBSD для прослушивания удаленных соединений использует параметр -и: # /usr/sbin/syslogd -a /var/empty/dev/log -и A syslogd ОС Solaris использует ключ -Т: # /usr/sbin/syslogd -T Теперь настроим клиентов. Если вы хотите пересылать весь трафик протоколирования с любой машины на центральный узел протоколов, просто поместите следующее выражение в файл /etc/syslog.conf: *.*

-

@loghost

Это выражение можно сделать единственной строкой файла настройки, и тогда сообщения будут протоколироваться только на удаленном узле. Если же добавить выражение в существующий файл, то протокол будет храниться как локально, так и удаленно.

Трюк № 55. Управление syslog

151

Недостатком удаленного протоколирования является отсутствие в большинстве ОС проверки полномочий или управления доступом при обращении к центральному узлу протоколов. Некоторую степень защиты могут обеспечить межсетевые экраны, ограждая от тех, кто способен подорвать инфраструктуру протоколирования, однако тот, кто уже получил доступ к локальной сети, может выдать свое подключение за иное и обойти любые правила межсетевого экрана. Если вы считаете, что это относится к вашей сети, обратитесь к трюку «Обобщение протоколов с удаленных сайтов» (трюк № 59), в котором рассматривается один из методов настройки удаленного протоколирования с использованием идентификации с помощью открытых ключей и соединений с SSL-шифрованием.

Управлениеsyslog Заставьте syslog работать больше и вы будете тратить меньше времени на просмотр огромных файлов протоколов.

Стандартная установка syslog в большинстве дистрибутивов не очень удачно фильтрует в отдельные файлы информацию различных классов. Если в /var/log/ messages представлено великое множество всяких сообщений от Sendmail, sudo, BIND и других системных служб, то вам, вероятно, надо пересмотреть файл /etc/syslog.conf. Существует ряд критериев и приоритетов, по которым syslog может выполнять фильтрацию. В качестве критериев (facilities) могут выступать: auth, auth-priv, cron, daemon, kern, lpr, mail, news, syslog, user, uucp и 1осаЮ-1оса17. Каждый критерий может иметь один из восьми приоритетов (priorities): debug, info, notice, warning^ err, crit, alert и emerg. Обратите внимание: приложения самостоятельно принимают решение о том, в какой критерий и с каким приоритетом необходимо фиксировать событие (лучше, когда возможность сделать это они предоставляют вам), поэтому они могут выполнить протоколирование не так, как ожидалось. Вот пример /etc/syslog.conf, который пытается «перетасовать» места протоколирования: auth.warning mail.err kern,* cron.crit *.err;mail.none *.info;auth.none:mail.none •

/var/log/auth /var/log/maillog /var/log/kernel /var/log/cron /var/log/syslog /var/log/messages

#*.=debug

/var/log/debug

localO.info local 1.err

/var/log/cluster /var/log/spamerica

Все строки в этом примере будут протоколировать указанный (или выше) приоритет в соответствующий файл. Специальный приоритет попе заставляет syslog вообще не учитывать указанный критерий. Критерии с localO no 1оса17 предназначены

152


для использования вашими собственными программами, однако они также могут оказаться полезными. Например, файл /var/log/spamerica заполняется сообщениями locaM.err (или выше), генерируемыми в ходе обработки спама. Очень здорово хранить эти сообщения отдельно от стандартного протокола доставки почты (в /var/log/maillog). Строка, помеченная как комментарий (*.=debug), полезна для отладки служб, выполняемых демоном. Она заставляет syslog более точно протоколировать лишь сообщения с приоритетом debug для любого критерия и обычно не должна запускаться (если только вы не желаете заполнить диски протоколами отладки). Еще один подход: протоколировать отладочную информацию в буфере, организованном по принципу fifo. В этом случае протоколы отладки не занимают места и пропадают сразу, как только специальный процесс «просмотрит» их. Для протоколирования в буфер fifo сначала создайте его в файловой системе: # mkfifo -m 0664 /var/1од/debug После этого усовершенствуйте строку отладки в syslog.conf, добавив символ |: *.=debug

|/var/log/debug

Теперь отладочная информация всегда будет протоколироваться в fifo и просматриваться с помощью команды, подобной -f /var/log/debug. Fifo также удобен, если необходим процесс, непрерывно просматривающий все системные сообщения и в случае необходимости извещающий вас по электронной почте о критических системных сообщениях. Попробуйте создать fifo /var/log/monitor и добавьте в syslog.conf подобное правило: *.*

|/var/log/monitor

Теперь каждое сообщение (с любым приоритетом) передается в fifo /var/log/ monitor, и любой процесс, просматривающий его, сможет соответствующим образом реагировать, вовсе не занимая дискового пространства. MARK WHO? Вы заметили в /var/log/messages группу строк: • Dec 29 18:33:35 catlin -- MARK -Dec 29 18:53:35 catlin -- MARK -Dec 29 19:13:35 catlin - MARK Dec 29 19:33:35 catlin -- MARK -Dec 29 19:53:35 catlin -- MARK -Dec 29 20:13:35 catlin -- MARK -Dec 29 20:33:35 catlin ~ MARK -Dec 29 20:53:35 catlin -- MARK Dec 29 21:13:35 catlin -- MARK -Они сгенерированы функцией mark программы syslog в качестве «контакта» с системой, что позволяет (теоретически) зафиксировать внезапную «смерть» syslog. В большинстве случаев строки служат лишь для заполнения файлов протоколов, и, если у вас нет проблем с syslog, они совершенно не нужны. Для выключения этой функции передайте в syslogd ключ -т 0 (после предварительного прекращения работы любого запущенного syslogd): # killall syslogd; /usr/sbin/syslogd -m 0

Трюк № 56. Интеграция Windows в инфраструктуру syslog

153

Если все эти пустяки с критериями и приоритетами добивают вас, вы не одиноки. Эти примеры представлены для систем, по умолчанию включающих демон syslogd. Если имеется возможность установить новый syslogd, то, скорее всего, вы обратитесь к syslog-ng. Эта новая реализация syslogd имеет множество новых функций и позволяет осуществлять фильтрацию более гибко. Некоторые из возможностей syslog-ng мы рассмотрим в трюке «Обобщение протоколов удаленных сайтов» (см. трюк № 59). Роб Фликингер (Rob Flickenger)

ИнтеграцияWindows в инфраструктуру syslog Отслеживайте работу Windows-узлов распространенным в Unix способом. Довольно тяжело проверять все вкладки Event Logs (программа Журнал регистрации событий) на всех Windows-узлах, но это еще сложнее сделать, если вы отдаете предпочтение Unix. ОС Unix хранит протоколы в виде обычных текстовых файлов, которые легко найти с помощью обычных команд. Этот прием совершенно отличается от работы с двоичными файлами протокола в Windows, которые можно просмотреть только с помощью Event Logs. Было бы здорово, если бы Windows-машина работала так же, как используемые вами Unix-машины. Кто-то уже подумал об этом и написал бесплатную службу Windows, позволяющую добиться этого. NTsyslog (http://ntsyslog.sourceforge.net/) — свободно распространяемая служба, создана для Windows и позволяет выполнять удаленное протоколирование в syslogd. Для установки просто загрузите ее и разархивируйте ZIP-файл, после чего скопируйте файлы NTSyslogCtrl.exe и ntsyslog.exe в каталог %SystemRoot%\sys\em32. Для запуска службы в режиме командной строки выполните следующую команду: С:\> ntsyslog - i n s t a l l Для проверки работы службы откройте элемент Администрирование (Administrative Tools) панели управления Windows и дважды щелкните на значке Службы (Services). Прокрутите список и найдите службу NTsyslog (рис. 4.1). По умолчанию NTsyslog устанавливает себя и запускается с использованием учетной записи LocalSystem, имеющей полный доступ к ресурсам локального узла. Очевидно, что это — не оптимальная конфигурация, поскольку NTsyslog должен иметь доступ только к Event Log и ни к чему более. Существующее положение можно изменить, дважды щелкнув на строке NTsyslog в списке служб (см. рис. 4.1). При этом откроется диалоговое окно Свойства (Properties). Перед этим желательно специально для службы NTsyslog создать учетную запись, имеющую только необходимые для этой службы привилегии. Для этого вернитесь в окно службы администрирования и дважды щелкните на значке Управление (Computer Management). После щелчка на значке Локальные пользователи и группы (Local Users and Groups) окно станет подобным окну, представленному на рис. 4.2.

154


Рис. 4 . 1 . NTsyslog в списке служб

Рис. 4.2. Элемент Computer Management с папкой Users

Щелкните правой кнопкой на папке Users, затем на кнопке Новый пользователь (New). В появившемся диалоговом окне необходимо ввести сведения о новом пользователе (рис. 4.3). Теперь необходимо предоставить новому пользователю права, необходимые для выполнения задачи. В окне Администрирование (Administrative Tools) найдите


155

значок Локальная политика безопасности (Local Security Policy) и дважды щелкните на папке Назначение прав пользователя (User Rights Assignment), расположенной в левой части окна (рис. 4.4).

Рис. 4.З. Создание нового пользователя для NTsyslog

Рис. 4.4. Назначение прав пользователя

156


Необходимое нам право называется Управление аудитом и протоколом безопасности (Manage auditing and security log). Найдите его в списке политик и дважды щелкните на нем (рис. 4.5).

Рис. 4.5. Установка права Manage auditing and security log

Щелкните на кнопке Добавить (Add), выберите в списке имя пользователя и щелкните на кнопке ОК. Теперь у нас имеется учетная запись, которой мы присвоили соответствующее право доступа, и сейчас можно вернуться в окно служб и дважды щелкнуть на службе Ntsyslog для открытия окна ее свойств. Перейдите на вкладку Регистрация (Log On) (рис. 4.6). Щелкните на переключателе Эта учетная запись (This account) для включения кнопки Просмотр (Browse). Найдите и выберите созданную учетную запись, а затем щелкните на кнопке ОК. Теперь имя учетной записи должно оказаться в текстовом поле справа от переключателя Эта учетная запись (This account). Укажите определенный для созданной учетной записи пароль и подтвердите его. После щелчка на кнопке Применить (Apply) появится диалоговое окно, подтверждающее, что учетной записи предоставлено право Регистрироваться как служба (Log On As A Service). Щелкните на кнопке ОК, а затем в окне свойств перейдите на вкладку Общие (General). Для запуска службы от имени созданного пользователя щелкните на кнопке Пуск (Start). Если появится сообщение об ошибке, то вам необходимо изменить ACL для файла ntsyslog.exe и добавить в новую учетную запись разрешения Read и Execute. Теперь с помощью программы настройки установите параметры NTsyslog. Необходимо указать, на какой syslogd (первичный или вторичный) отправлять сообщения, а также типы событий и их деление по категориям и серьезности, принятые в syslog. Из этого окна также можно запустить и остановить службу NTsyslog. Программа настройки запускается с помощью файла NTSyslogCtrl.exe. Ее окно показано на рис. 4.7.


1S7

Рис. 4.6. Вкладка Регистрация (Log On) окна свойств

Рис. 4.7. Программа настройки NTSyslog

Для запуска службы щелкните на кнопке Start Service, для остановки — на кнопке Stop Service. Щелчок на кнопке Syslog Daemons откроет диалоговое окно, представленное на рис. 4.8. Все совершенно ясно. Просто выберите узел, на который вы хотите войти, и, если имеется вторичный узел syslog, поместите его имя в соответствующее поле.

158


Рис. 4.8. Указание первичного и архивного серверов syslog

Наиболее сложная часть конфигурирования — настройка отображения типов событий Event Log, но даже это можно легко сделать. В раскрывающемся списке (см. рис. 4.7) выберите необходимый журнал: События приложений (Application), События безопасности (Security) или Системные события (System Event). Для настройки выбранного журнала щелкните на кнопке EventLog. При выборе протокола событий безопасности после щелчка на этой кнопке вы увидите окно, подобное представленному на рис. 4.9.

Рис. 4 . 9 . Отображение элементов журнала событий безопасности в категории syslog

Для разрешения перенаправления событий определенного типа установите возле них флажок. С помощью раскрывающихся списков можно также настроить серьезность и категорию каждого типа событий. Поскольку это протокол безопасности, необходимо выбрать категорию security или auth. Для определения серьезности события выберите что-либо созвучное типу журнала Windows. Например, для типа Информация (Information) я выбрал (4)security/auth1 и (6)information. Однако можно выбирать категорию и серьезность, не используемые любым из Unix-серверов, и заставить syslogd записывать все Windows-события в обычный

Трюк № 57. Автоматическое обобщение протоколов

159

отдельный файл. Конечно же, при использовании syslog-ng (см. трюк № 59) можно использовать любую категорию на выбор и выполнять фильтрацию Windowsузлов по IP-адресу. После настройки попробуйте несколько раз войти в систему и выйти с неверным паролем для того, чтобы убедиться, что все работает. Если это так, то вы увидите подобные сообщения об ошибках: Oct 29 17:19:04 plunder security[failure] 529 NT AUTHORITY\\SYSTEM Logon Failure: Reason:Unknown user name or bad password User Name:andrew Domain: PLUNDER Logon Type:2 Logon Process:User32 Authentication Package:Negotiate Workstation Name:PLUNDER Одним из самых больших достоинств результата проделанной работы является возможность использовать для наблюдения за Windows-системами мощные и гибкие средства ОС Unix.

Автоматическое обобщение протоколов Не занимайтесь поиском иголки в стоге сена. Если протоколируется работа практически всех служб и узлов сети, то вы, без сомнения, потонете в море информации. Один из способов удержаться на плаву — обобщение протоколов (вывод общего результата). Эта задача значительно упрощается при использовании средства logwatch (http://www.logwatch.org). Утилита logwatch анализирует системные протоколы за указанный период времени и автоматически составляет отчеты. Эта программа может запускаться с помощью сгоп и отправлять результат по электронной почте. Logwatch доступна в большинстве дистрибутивов Red Hat ОС Linux. Кроме того, ее RPM-пакеты можно загрузить с web-сайта проекта с использованием основанного на RPM дистрибутива Linux. Для компиляции logwatch из исходного кода загрузите пакет исходного кода. Поскольку здесь имеется сценарий, компилировать ничего не надо, поэтому установка этой программы заключается в копировании сценария в каталог. Установка выполняется подобными командами: # tar xfz logwatch-5.0.tar.gz # cd logwatch-5.0 # mkdir /etc/1og.d # cp -R conf lib scripts /etc/1og.d Можно также установить справочную систему и для повышения удобства создать ссылку из сценария logwatch.pl на /usr/sbin/logwatch: # cp logwatch.8 /usr/share/man/man8 # (cd /usr/sbin && \ In -s ../../etc/log.d/scripts/logwatch.pi logwatch)

пПппппппиппппТГпТГТГТГпТГпп

LOgWdLCN

tHO

иТГппПКУипТГиппипЛппипТГиииТГ

Если имеется каталог /etc/cron.daily, можно создать символическую ссылку из сценария logwatch.pl на /etc/cron.daily/logwatch.pl, и сценарий будет запускаться ежедневно. Альтернативно можно создать элемент в crontab корневого каталога, что позволит модифицировать поведение logwatch, указывая параметры в командной строке. Например, с помощью параметра -mailto можно изменить электронный адрес, на который высылаются отчеты. По умолчанию они отправляются на локальный root. Logwatch поддерживает большинство стандартных файлов протокола безо всякой дополнительной настройки, но можно добавить поддержку файлов любых типов. Для этого необходимо создать структуру группы протоколов для нового типа файлов в каталоге /etc/log.d/conf/logfiles. Этот файл должен содержать лишь элемент, указывающий файл протокола для этой службы, и элемент, определяющий шаблон универсализации1 файловых имен любых архивированных файлов протоколов этой службы. Например, если имеется служба myservice, то необходимо создать /etc/log.d/conf/logfiles/myservice.conf со следующим содержанием: LogFile = /var/log/myservice Archive = /var/log/myservice.* Далее необходимо создать файл определения службы. Он должен быть назван /etc/log.d/conf/services/myservjce.conf и должен содержать следующую строку: LogFile = myservice И наконец, logwatch — это лишь каркас для генерации итогового отчета, поэтому необходимо создать сценарий в /etc/log.d/scripts/services с именем myservice. Программа logwatch при выполнении отбрасывает все временные элементы протоколов 1

Замена реальных символов в имени и расширении универсальными с целью распространения действия спецификации на определенные типы файлов.

Трюк № 58. Автоматическое наблюдение за протоколами

161

и передает остальные части записей через стандартный ввод в сценарий myservice. Следовательно, сценарий должен выполнять считывание из стандартного ввода, а также разбор соответствующих сведений и записывать результат в стандартный вывод. Это лишь общий принцип работы программы logwatch в вашей системе. Дополнительную информацию можно найти в HOWTO-Make-Filter, входящем в состав дистрибутива logwatch.

Автоматическое наблюдение за протоколами Используйте swatch для информирования в случае возникновения проблем. Автоматически генерируемое обобщение файлов протоколов позволяет быть в курсе событий в системах и в сети, но, если вы хотите узнавать о событиях сразу же при их возникновении, надо использовать иное средство. Одним из средств, которые помогают получать сигнал тревоги в реальном времени, является swatch (http://swatch.sourceforge.net) (сокращение от Simple Watcher — буквальный перевод — простой наблюдатель). Swatch — это настраиваемый обозреватель файлов протокола, который наблюдает за файлом, ожидая возникновения задаваемых пользователем событий, и отправляет сигнал тревоги. Наблюдатель состоит из программы на языке Perl, файла настройки и библиотеки действий, предпринимаемых при обнаружении запускающего события в наблюдаемом файле. Для установки swatch загрузите из Сети пакет, распакуйте его и перейдите в созданный им каталог. После этого запустите команды # perl Makefile.PL # make && make install Перед компоновкой swatch необходимо, чтобы были установлены модули Date::Calc, Date::Parse, File:"Tail и Time::HiRes Perl CPAN. Если при запуске команды perl Makefile.PL вы получите сообщение об ошибке, то необходимо установить следующие модули: Warning: prerequisite Date::Calc 0 not found. Warning: prerequisite Date::Parse 0 not found. Warning: prerequisite Time::HiRes 1.12 not found. Writing Makefile for swatch Если модуль CPAN языка Perl уже установлен, то просто выполните следующие команды: # perl -MCPAN -e "install Date::Calc" # perl -MCPAN -e "install Date::Parse" # perl -MCPAN -e "Time::HiRes" 6 Зак. 1103

162


По умолчанию swatch ищет свой файл настройки .swatchrc в текущем домашнем каталоге. Этот файл содержит так называемые регулярные выражения (regular expressions), которые ищут в наблюдаемом файле. При желании использовать другой файл настройки сообщите о нем swatch с помощью параметра командной строки -с. Например, для использования /etc/swatch/messages.conf для наблюдения за /var/log/messages программа swatch должна вызываться следующей командой: # swatch -с /etc/swatch/messages.conf -t /var/log/messages Общий формат элементов файла настройки: watchfor // 1действие2~] [действиеЗ]

Кроме того, можно игнорировать особые сообщения протокола, соответствующие регулярным выражениям, используя ключевое слово ignore //.

Имеется возможность указывать несколько регулярных выражений, разделяя их символом |. Программа swatch очень гибка в настройке предпринимаемых действий, запускаемых при совпадении строк и регулярных выражений. К наиболее полезным действиям, которые можно указывать в файле .swatchrc, относятся echo, write, exec, mail, pipe и throttle. Действие echo просто выводит соответствующую строку в консоль; дополнительно можно указать используемый при этом текстовой режим. Текст может выводиться жирным шрифтом, подчеркнутым, мигающим, негативным или определенного цвета. Например, для того чтобы совпадающая строка выводилась красным мигающим текстом, необходимо указать следующее действие: echo blink,red Действие write аналогично действию echo, за исключением того, что оно не поддерживает текстовые режимы. Однако вывод может осуществляться на заданный пользователем TTY: write user:user2:... Действие exec позволяет выполнить любую команду: exec Для передачи всей соответствующей строки в исполняемую команду можно использовать переменные $0 и $*, $1 — для передачи первого поля строки, $2 — второго и т. д. Поэтому если необходимо передать только второе и третье поля совпавшей строки в команду mycommand, то действие необходимо задать так: exec "mycommand $2 $3" Действие mail особенно полезно в тех случаях, когда имеется сотовый телефон или пейджер, способный принимать почтовые и текстовые сообщения. При

Трюк № 59. Обобщение протоколов с удаленных сайтов

'

163

использовании действия mail можно указать сколько угодно получателей и тему сообщения. Swatch пошлет строку, совпавшую с регулярным выражением, на эти адреса. Вот общая форма этого действия: maiI addresses-address:address2:

subject=mysubject

При использовании действия mail избегайте использования символа @ в адресе электронной почты (то есть вместо @ необходимо использовать \@). Также избегайте использования пробелов в теме сообщения (им должен предшествовать символ \). Помимо действия exec, программа swatch может выполнять внешние команды с помощью действия pipe. Единственным различием является то, что вместо передачи аргументов командной строки swatch выполнит команду и по конвейеру передаст в нее совпавшую строку. Для использования этого действия просто поместите ключевое слово pipe перед командой, которую хотите использовать. Для повышения производительности можно использовать параметр keep_open, оставляющий конвейер открытым до завершения работы swatch или для выполнения последующего действия pipe: pipe mycommand.keep_open Одна из проблем выполнения команд или отправки сообщения при нахождении указанной строки в сообщении протокола заключается в том, что иногда одно и то же сообщение протокола может генерироваться снова и снова очень часто. Очевидно, что в этом случае вам не хотелось бы получить 100 сообщений за 10 минут. Для решения этой проблемы swatch предлагает использовать действие throttle. Оно позволяет подавлять определенное сообщение или несколько сообщений, соответствующих регулярным выражениям, появляющимся в указанный период времени. Общая форма действия throttle: throttle h:m:s Действие throttle будет подавляться на основе контекста сообщения по умолчанию. Если бы вам хотелось подавить действия на основе регулярного выражения, необходимо добавить а , use= регулярное_выражение в конец throttle-выражения. Swatch является невероятно полезным средством, но для создания файла настройки может потребоваться некоторое время. Самый лучший способ узнать, что необходимо искать, — это просмотреть файлы протокола и выбрать те действия, за которыми вы хотели бы наблюдать более пристально.

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

При выполнении задачи по наблюдению за деятельностью локальной сети зачастую не придается должного значения наблюдению за протоколами удаленного сайта или совместно расположенного сервера. Традиционные возможности syslog

164


можно было бы использовать /для отправки сведений протоколирования с удаленной сети или систем, но, поскольку syslog-демон для общения с удаленными системами использует протокол UDP, это не является идеальным решением. UDP не обеспечивает надежность связи, что ведет к риску потери части сведений. Помимо этого, традиционный syslog-демон не имеет средств шифрования отправляемого трафика, поэтому сообщения могут просматриваться любым, кто имеет доступ к промежуточным сетям. Для того чтобы обойти эту проблему, необходимо найти замену syslog-демону. На эту роль подходит syslog-ng (http:// www.balabit.com/products/syslogjig/). Syslog-ng не только является полнофункциональной заменой традиционного syslog-демоиа, но и добавляет гибкие возможности фильтрации сообщений, а также поддержку протоколирования работы удаленных систем по TCP (помимо стандартного UDP). Имея поддержку протокола TCP для безопасной пересылки протоколов по «ненадежным» сетям, можно применять stunnel или ssh. Для компоновки syslog-ng, помимо пакета непосредственно syslog-ng, необходим пакет библиотек libol (http://www.balabit.com/downloads/syslog-ng/libol/). После загрузки из Сети этих пакетов распакуйте их и скомпонуйте libol: $ tar xfz libol-0.3.9.tar.gz $ cd libol-0.3.9 $ ./configure && make При компоновке syslog-ng его можно статически связать с libol, чтобы исключить необходимость установки библиотеки целиком. А сейчас скомпонуем syslog-ng: $ tar xfz syslog-ng-1.5.26.tar.gz $ cd syslog-ng-1.5.26 $ ./configure --with-libol=../libol-0.3.9 $ make Если есть желание скомпилировать поддержку ТСР-оболочек, добавьте в сценарий настройки флаг --enable-tcp-wrapper. После завершения компиляции получите полномочия root и выполните команду make install. Это приведет к установке двоичного файла syslog-ng и справочника manpages. Для настройки демона создайте каталог /usr/local/etc/syslog-ng, а затем в нем создайте файл syslog-ng.conf. Для начала можно использовать один из примеров файлов настройки из каталога doc. Существует пять типов элементов syslog-ng.conf, каждый из которых начинается со специального ключевого слова. Элемент options (параметры) позволяет подстроить поведение демона, например, как часто демон будет выполнять синхронизацию протоколов на диске и будет ли демон автоматически создавать каталоги. Элементы source (источник) указывают, откуда собирать протоколы. В качестве источника могут выступать Unix-, TCP- или UDP-сокеты, файлы и конвейеры. Элементы destination (назначение) позволяют указывать места, куда sysiog-ng может посылать протоколы. Это могут быть файлы, конвейеры, Unix-, TCP- или UDP-сокеты, печатающие устройства или программы. Элементы sources и destinations объединяются с помощью фильтров (с помощью ключевого слова filter), что позволяет выделять категории syslog и уровни протоколирования.

168


Обратите внимание на то, что макрос $HOST используется вместо имени каталога. При таком использовании элемента destination заблаговременно создайте этот каталог либо воспользуйтесь элементом option со значением create_dirs( ): options { create_dirs(yes); }; Макросы syslog-ng — это очень мощная функция. Например, если необходимо разделить протоколы по имени узла PI дате, можно использовать следующее назначение: destination fbsdjnessages { file(n/var/log/$HOST/$YEAR.$MONTH.$DAY/messagesM); }: Можно комбинировать удаленные источники с соответствующими назначениями для поступающих из сети протоколов так же, как вы делали это при настройке syslog-ng для локального протоколирования — просто указанием удаленного источника с соответствующими назначением и фильтрами. Еще с помощью syslog-ng можно собирать протоколы с нескольких удаленных узлов, а затем пересылать их все другому демону syslog-ng. Это можно сделать комбинированием удаленных источников и удаленных назначений в одном элементе log: log { source(r_src); destination(loghost); }: Поскольку syslog-ng использует TCP-порты, то для защиты трафика между демонами syslog-ng можно воспользоваться любым зашифрованным каналом. Для создания надежного канала между серверами можно воспользоваться SSH-nepeнаправлением порта (трюк № 72) или stunnel (см. трюк № 76). За счет ограничения соединений на «слушающем порте» для включения только local host (с помощью правил межсетевого экрана; см. трюк № 33 и трюк № 34) можно исключить возможность подделки элементов журнала и предотвратить атаки типа «отказ в обслуживании». Протоколы серверов содержат серьезную информацию, необходимую для работы администратора. Использование новых средств и сильного шифрования позволит сберечь важные данные из журналов от посторонних глаз.

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

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

Трюк № 60. Протоколирование деятельности пользователя

169

170


Для обобщения учетных сведений можно использовать команду sa. По умолчанию она выводит все команды, найденные в протоколах учета, а также то, сколько раз они выполнялись:

# sa 14 7 2 14 14 44

0.04ге О.ОЗге' 63.90re 34.02re О.ОЗге 0.02re

О.ОЗср О.ОЗср O.Olcp O.Olcp O.Olcp O.Olcp

Oavio Oavio Oavio Oavio Oavio Oavio

1297k 422k 983k 959k 1132k 432k

troff lastcomm info less grotty gunzip

Для вывода статистики с фильтрацией по имени пользователя используется ключ -и:

Время от времени можно внимательно изучать результат выполнения этих команд для поиска подозрительной деятельности, например выполнения вредоносных команд или увеличения времени использования процессора.

Г Л А В А

Наблюдение и выявление тенденций Трюки № 61-66 Значимость надежных системных протоколов переоценить невозможно, но все же их можно рассматривать лишь как вступление к книге о том, что произошло в сети. Когда случается что-то неординарное, событие просто заносится в соответствующий файл, где и ожидает, когда человек заметит его и предпримет ответные действия. Журналы имеют ценность лишь в том случае, если их кто-то действительно читает. Файлы протоколов постоянно пополняют объем информации, которую большинство администраторов «перемалывают» каждый день, в то же время некоторые из них могут оставаться непрочитанными дни и недели. И ситуация лишь ухудшается, если файлы протоколов «завалены» незначащей информацией. Например, крик о помощи от перегруженного почтового сервера запросто может быть потерян, если он находится среди неопасных записей о неудачных попытках рассылки спама. Зачастую протоколы используются как ресурс, помогающий разобраться в том, «что произошло» при крахе системы, а не для отслеживания того, «что же происходит сейчас». Еще одна важная характеристика записей журнала заключается в том, что они показывают лишь «точечный снимок» системы в определенный момент времени. Не имея хронологии производительности, довольно сложно уловить разницу между обычным сетевым трафиком, DoS-атакой и посещением группой читателей какого-либо популярного блога, на котором был указан адрес искомого ресурса. Из отчета можно узнать, сколько раз переполнялся раздел /var. А как просмотреть использование этого раздела во времени? Буфер почты работает медленно из-за одного невнимательного к другим пользователя, или это часть атаки, проводимой злоумышленником? А может, это просто общая тенденция, вызванная попыткой обслуживать слишком много пользователей при наличии очень маленького диска? В этой главе описывается несколько методов отслеживания во времени работоспособности служб и ресурсов. Вместо просмотра журналов лучше, чтобы система сама предупреждала о проблеме, и только в том случае, если проблема действительно существует. Здесь также предлагается несколько способов распознавания тенденций изменения сетевого трафика, основанных на наблюдении за общим потоком и представлении его в виде графика. Вы, наверное, представляете, как выглядит усредненный исходящий Интернет-трафик, но какую часть из этого

172


трафика составляет HTTP, а какую — SMTP? Вы можете приблизительно представить интенсивность использования каждого сервера сети, но что если вы хотите разделить трафик по протоколу? Из этой главы вы узнаете, как это сделать.

Наблюдение за работоспособностью Для учета работы сети используйте Nagios.

Поскольку удаленный злоумышленник может разрушить службу, в которую он вламывается, или вызвать повышенную загрузку центрального процессора, требуется наблюдение за службами, запущенными в сети. Просматривать открытые порты (например, с помощью Nmap (см. трюк № 42)) недостаточно. Машина может отвечать на TCP-запросы, но служба может оставаться недоступной (или, что хуже, может быть заменена совершенно другой программой!). Одним из средств, позволяющих проверить службы, является Nagios (http://www.nagios.org). Nagios — это приложение наблюдения за сетью, которое следит не только за службами, выполняемыми на узле сети, но и за ресурсами всего узла. Оно позволяет отслеживать использование процессора, памяти, а также запущенные процессы, файлы протоколов и т. д. При возникновении проблем оно может известить об этом, послав сообщение на адрес электронной почты, пейджер либо иным способом. Общее состояние сети можно проверить с помощью web-интерфейса. Nagios может расширяться за счет API-интерфейса надстроек. Для установки Nagios загрузите из Сети дистрибутив, распакуйте и перейдите в созданный при этом каталог: $ tar xfz nagios-1.l.tar.gz $ cd nagios-1.1 Перед запуском сценария настройки необходимо создать пользователя и группу для запуска Nagios (например, nagios). После этого запустите сценарий настройки: $ ./configure --with-nagios-user=nagios --with-nagios-grp=nagios Это приведет к установке Nagios в /usr/local/nagios. Как и обычно, это поведение можно изменить с помощью ключа --prefix. По завершении работы сценария настройки выполните компиляцию Nagios запуском команды make all. После этого получите root-полномочия и запустите make install. Кроме того, с помощью команды make install-init можно установить сценарии инициализации Nagios. Если теперь заглянуть в каталог /usr/local/nagios, то в нем можно увидеть четыре подкаталога. Каталог bin содержит один файл, nagios, являющийся основой пакета. Именно он выполняет мониторинг. Каталог sbin содержит CGI-сценарии, используемые при обращении к программе по web-интерфейсу. В каталоге share находятся HTML-файлы и документация. И наконец, в каталоге var приложение Nagios будет сохранять полученные в ходе работы сведения. Для использования Nagios потребуется парочка настроечных файлов. Эти файлы помещаются в каталог etc, который создается при выполнении команды

Трюк № 61. Наблюдение за работоспособностью

173

install-config. Эта команда также создает пример каждого файла настройки и помещает их в каталог etc. На этом установка Nagios завершена. Однако в таком состоянии это приложение не очень полезно по причине отсутствия действительных приложений наблюдения. Эти приложения, проверяющие правильность функционирования конкретной наблюдаемой службы, называются надстройками (plug-ins). Nagios имеет стандартный набор надстроек, но их необходимо отдельно загружать из Сети и устанавливать. Загрузите свежий набор надстроек и разархивируйте его. После этого необходимо запустить имеющийся сценарий настройки, выполняющий подготовку пакета и компиляцию в вашей системе. Можно отметить, что установка надстроек производится так же, как и установка самой программы Nagios. Для компиляции надстроек выполните подобные команды: $ ./configure --prefix=/usr/local/nagios \ --with-nagios-user=nagios --with-nagis-grp=nagios $ make all В ходе выполнения сценария возможно появление предупреждений об отсутствии программ или модулей языка Perl. Все нормально, если только упоминаемые приложения не нужны для наблюдения за службой. После завершения компиляции получите root-полномочия и выполните команду make install. Надстройки будут установлены в подкаталог libexec (например, в /usr/local/nagios/libexec). Существует несколько правил, которым должны удовлетворять все надстройки. Все надстройки имеют параметр --help, выводящий сведения об этой надстройке и ее работе. Это очень полезно, особенно когда вы пытаетесь наблюдать за новой надстройкой, которой ранее не пользовались. Например, для того чтобы знать, как работает надстройка check_ssh, запустите команду $ /usr/local/nagios/1ibexec/check_ssh check_ssh (nagios-plugins 1.4.Oalphal) 1.13 The nagios plugins come with ABSOLUTELY NO WARRANTY. You may redistribute copies of the plugins under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. Copyright (c) 1999 Remi Paulmier Copyright (c) 2000-2003 Nagios Plugin Development Team •Try to connect to SSH server at specified server and port Usage: check_ssh [-46] [-t ] [-p <port>] check_ssh (-h | --help) for detailed help check_ssh (-V | --version) for version information Options: -h. --help Print detailed help screen

Трюк № 61. Наблюдение за работоспособностью

175

правильность путей, указанных в этом файле. Имеется один параметр, который стоит изменить: check_external_commands, по умолчанию он имеет значение 0. Если вы имеете возможность запускать команды непосредственно из web-интерфейса, необходимо указать значение 1. В зависимости от сетевого окружения это может создать допустимый риск для системы безопасности. В файле cgi.cfg указываются имена пользователей, которым позволено запускать внешние команды. Для запуска Nagios необходимо модифицировать и остальные файлы настройки. Наблюдение за службами настраивается очень просто. Для облегчения можно использовать режим подробного вывода Nagios: # /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg Эта команда обрабатывает файлы настройки и сообщает о любых ошибках. Исправляйте ошибки по одной, повторно запуская эту же команду для поиска следующей ошибки. В целях проверки лучше отключить в файлах настройки определения всех узлов и служб, а файлы использовать лишь в качестве шаблонов для собственных узлов и служб. Большинство файлов можно оставить без изменения, но удалить те, которые можно создать «с нуля»: hosts.cfg services.cfg contacts.cfg contactgroups.cfg hostgroups.cfg Начните с определения наблюдаемого узла. Сначала необходимо добавить определение узла и настроить некоторые его параметры. Допускается добавление неограниченного количества узлов, но для простоты мы укажем только один. Вот содержание файла hosts.cfg: # Generic host definition template define host{ # The name of this host template - referenced i name generic-host n other host definitions, used for template recursion/resolution # Host notifications are enabled noti fi cati ons_enabled 1 # Host event handler is enabled event_handler_enabled 1 # Flap detection is enabled f1ap_detecti on_enabled 1 # Process performance data prpcess_perf_data 1 # Retain status information across program restarts retai n_status_i nformation 1 # Retain non-status information across program restarts retai n_nonstatus_informati on 1 # DONT'REGISTER THIS DEFINITION - ITS NOT A REAL HOST, # JUST A TEMPLATE! register 0

# Service definition define service! # Name of service template to use use generic-service hostjiame freeli nuxcd.org service_description PING is_volatile 0 check_period 24x7 max_check_attempts 3 normal_check_interval 5120 службы вещать кой Вcontact_groups noti check_command retry_check_interval } этом «прозвонки» fi cati о(которая файле возникновении on_i on_peri on_opti nterval настроено check_pi названа flcd-admins сod onsсервера 24x7 1с.г ng!100.0.20%!500.0,60% HTTP) наблюдение проблем. и извещает будет Второе запроверять, администратора двумя определение службами. работает об наблюдает Определение увеличении ли web-сервер, за статистивремени первой и из-

Трюк № 62. Графическое изображение тенденций

179

отклика или увеличении потерь пакетов. Здесь используются команды check_ http и checkjDing,-которые были помещены в каталог libexec в ходе установки. Познакомьтесь, пожалуйста, и с другими надстройками. Они настраиваются аналогичным образом. По завершении настройки последний раз запустите Nagios с ключом -v для того, чтобы убедиться в отсутствии ошибок. После этого с помощью ключа -d запустите ее как демон: # /usr/local/nagios/bin/nagios -d /usr/local/nagios/etc/nagios.cfg Вот и все. Дайте Nagios пару минут для того, чтобы сгенерировать данные, после этого укажите в web-браузере адрес машины и просмотрите работу программы.

Графическое изображение тенденций С помощью RRDtool можно сгенерировать практически любую диаграмму.

Возможно, вы знакомы с графическим изображением пропускной способности, созданным с помощью таких средств, как MRTG. Иметь графическое изображение пропускной способности сети полезно с точки зрения безопасности, поскольку оно помогает заметить ее аномальное поведение. Наличие хронологии типичного использования сети позволяет судить о том, что в ней происходит. Это позволяет упростить обнаружение DoS-атаки на ваш сайт и определить, не используется ли какая-нибудь из машин вашей сети в качестве склада краденного программного обеспечения (Warez depot). RRDtool (http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/) обеспечивает функциональность, аналогичную MRTG, но более гибко. По сути, программа RRDtool — это средство хранения данных в базе данных общего назначения, не меняющей своего размера. RRD — это сокращение от термина round-robin database — циклическая БД, являющаяся особым типом БД, обеспечивающей фиксированное число записей за счет того, что самые старые записи постоянно замещаются самыми свежими. RRDtool имеет возможность составлять диаграммы на основе данных, хранящихся в циклической БД. Самое распространенное использование RRDtool — для создания красивых диаграмм пропускной способности. Это легко достигается совместным использованием RRDtool и snmpget — утилиты, которая с помощью snmp опрашивает устройства. Сначала необходимо создать циклическую БД подобной командой: $ rrdtool create zul.rrd --start N \ DS:deO_in:COUNTER:600:U:U \ DS:deOj)Ut:COUNTER:600:U:U \ RRA:AVERAGE:0.5:1:600 \ RRA:AVERAGE:0.5:6:700 \ RRA:AVERAGE:0.5:24:775 \ RRA:AVERAGE:0.5:288:797 \

17*00 " * 17:10 | Щ deo In H deO out

17:20

17?30 *

17*40

* 17:*50

Рис. 5 . 1 . Диаграмма, сгенерированная RRDtool

Значение -3600 в команде указывает RRDtool, что вы хотите получить диаграмму на основе данных, собранных за последний час (1 ч = 3600 с). Аналогично, если необходим график за целый день, можно указать значение -86 400. Но это только начало. После сбора данных из различных источников можно объединить их в одном графике, который визуально даст больше информации. На рис. 5.2 одновременно представлены графики относительного исходящего использования

Трюк № 63. Использование ntop для получения статистики работы сети

181

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

Рис. 5.2. Графики для нескольких серверов на одной диаграмме

Можно отметить, что RRDtool — очень удобное средство. Все, что надо для него сделать, — это сказать, сколько данных необходимо хранить, а затем настроить несколько методов сбора данных через определенное время. После этого в любой удобный момент можно построить диаграмму.

Ш

Использование ntop для получения статистики работы сети в реальном масштабе времени Смотрите, кто и чем занимается в вашей сети с помощью ntop.

Если вам нужна сетевая статистика в реальном масштабе времени, обратитесь к прекрасному средству ntop (http://www.ntop.org). Это полномасштабный анализатор протокола, имеющий web-интерфейс клиентской части, поддерживающий SSL и возможность составления диаграмм. К сожалению, ntop совсем не маленький (точный размер требуемых ресурсов определяется в зависимости от размера сети и объема сетевого трафика), но он дает полную картину того, кто с кем общается в сети. Ntop должен изначально запускаться от имени root (для переброски сетевых интерфейсов в «беспорядочный режим», чтобы иметь возможность перехватывать пакеты), но впоследствии понижает свои привилегии до привилегий указанного вами пользователя. Если вы решили запускать ntop на длительный период времени, было бы разумно запускать его на специально выделенном для наблюдения

Трюк № 64. Аудит сетевого трафика

183

Рис. 5.3. Вывод статистики узла с помощью web-интерфейса ntop I В то время как tcpdump и Ethereal делают подробный интерактивный анализ сетевого трафика, ntop предоставляет ценную статистическую информацию с помощью простого в использовании web-интерфейса. При правильной установке и разумной блокировке ntop вполне может стать любимым средством анализа сети. Роб Фликингер (Rob Flickenger) «Трюки Linux-сервера» («Linux Server Hacks»)

Аудит сетевого трафика Воспользуйтесь программой Argus для наблюдения за сетью. Было бы неплохо полностью фиксировать все, что происходит в сети. Полное протоколирование помогает отслеживать проблемы и просто бесценно при инциденте в системе безопасности, но оно будет занимать очень много места. Решением этой проблемы является не хранение самих данных, а протоколирование целых пакетов. Это можно сделать с помощью программы Argus (http://www.qosient.com/argus/).

184


Argus (Audit Record Generation and Utilization System) — система генерации и использования записей аудита. Это средство может различным образом протоколировать сетевые транзакции и даже регистрировать значения производительности для каждого соединения, которое оно видит. Argus содержит также ряд утилит, которые могут выполнять запросы к протоколам, позволяя извлекать из них необходимую информацию. Эти средства позволяют на основе файла протокола Argus генерировать отчеты в таких форматах, как ASCII, RMON и XML. Для доступа к файлу собственного протокола Argus предоставляет Perl-интерфейс, что позволяет создавать пользовательские сценарии для обработки собранных данных. Для установки Argus сначала загрузите из Сети дистрибутив и распакуйте его. После этого перейдите в созданный при этом каталог: $ tar xfz argus-2.0.5.tar.gz $ cd argus-2.0.5 Для компиляции Argus запустите команду $ ./configure && make После завершения компиляции можно установить Argus, получив root-полномочия и выполнив команду # make install Для получения представления о работе приложения Argus запустите его и позвольте собрать данные: # argus -d -e Nhostnamev -w /tmp/arguslog Эта команда запустит Argus в режиме демона, протокол работы которого будет записан в /tmp/argus. Через некоторое время выполните запрос с помощью команды га. Она выведет ASCII-представление пакетов, которые запротоколировал Argus: $ га -г /tmp/arguslog 12 Jan 04 05:42:48 udp 12 Jan 04 05:43:09 udp 12 Jan 04 05:43:15 udp 12.Jan 04 05:43:28 lie 12 Jan 04 05:43:28 nvl 12 Jan 04 05:43:28 lie 12 Jan 04 05:43:28 lie 12 Jan 04 05:44:19 udp 12 Jan 04 05:43:34 udp 12 Jan 04 05:44:08 arp 12 Jan 04 05:44:08 udp 12 Jan 04 05:44:15 udp 12 Jan 04 05:45:06 udp 12 Jan 04 05:40:26 man 12 Jan 04 05:44:28 nvl 12 Jan 04 05:44:28 lie

plunder.nnc.netbios-ns -> 192.168.0.255.netbios-ns INT 192.168.0.250.snmptrap -> 255.255.255.255.snmptrap INT print.nnc.netbios-dgm -> 192.168.0.255.netbios-dgm INT 0:cO:2:57:98:79.nul1 -> Broadcast.null INT 0:c0:2:57:98:79 -> Broadcast INT 0:c0:2:57:98:79.nul1 -> Broadcast.null INT 0:c0:2:57:98:79.nul1 -> Broadcast.null INT kryten.nnc.56581 -> 255.255.255.255.2222 TIM sunder.nnc.netbios-ns -> 192.168.0.255.netbios-ns INT plunder.nnc who-has sirius.nnc INT plunder.nnc.netbios-ns -> 192.168.0.255.netbios-ns INT print.nnc.netbios-dgm -> 192.168.0.255.netbios-dgm INT sunder.nnc.netbios-dgm -> 192.168.0.255.netbios-dgm TIM pkts 734 bytes 75574 drops 0 CON 0:c0:2:57:98:79 -> Broadcast INT 0:c0:2:57:98:79.nul1 -> Broadcast.null INT

186 Глава 5. Наблюдение и выявление тенденций <ExtFlow> <Metrics SrcCount = "24" DstCount = "17" SrcBytes = "2112" DstBytes = "2258" SrcAppBytes = "528" DstAppBytes = "1136" /> Сбор статистики можно доверить межсетевому экрану.

Накопление статистики с помощью правил межсетевого экрана

Как отметить, Argus отслеживает больше информации, чем было бы при Еслиможно вам необходимо накопить статистические данные о сетевом трафике, но генерации отчета с помощью га. Вот где основное преимущество Argus! Эта вас пугает настройка SNMP, не стоит отчаиваться. Сделать это позволяет пропрограмма хранит большое количество информации о сетевом трафике, занимая граммная реализация межсетевого экрана в операционной системе. Например, очень мало места. Помимо этого, Argus может преобразовать эту информацию при использовании ОС Linux можно запустить следующую команду iptables вдля различные форматы (например, XML),способности что упрощает создание приложений, оценки использования пропускной определенной машиной, «понимающих» эти данные. трафик которой проходит через межсетевой экран:

Для накопления статистики использования входной и выходной пропускной способности для трафика, проходящего через межсетевой экран, здесь производится оценка счетчиков пакетов и счетчиков байтов, связанных с каждым правилом iptables. Для этого сначала определяется цепочка KRYTEN, названная в честь узла, для которого накапливается статистика. Эта цепочка содержит безусловное правило, которое используется для быстрого суммирования (add) используемой пропускной способности. Для классификации используемой пропускной способности создана еще одна цепочка, KRYTENJN. Она содержит лишь одно правило,

Трюк № 66. Удаленный анализ

187

которое вызывает безусловный переход к цепочке KRYTEN при измерении входного потока. Аналогично, цепочка KRYTEN_OUT подсчитывает исходящую пропускную способность, а затем осуществляет безусловный переход к цепочке KRYTEN. И наконец, правила добавляются в цепочку FORWARD, которая в зависимости от направления движения пакета пересылает его в соответствующую цепочку. После применения этих правил можно увидеть суммарное использование пропускной способности (отдельно входной и выходной) узла kryten с помощью следующей команды: # iptables -vx -L KRYTEN Chain kryten (2 references) pkts bytes target prot opt in out 442 46340 ACCEPT all -- any any

source destination anywhere anywhere

Выполнив анализ поля bytes и воспользовавшись утилитой RRDtool, можно построить диаграмму (трюк № 62): # iptables -vx -L KRYTEN | egrep -v 'Chain|pkts' | awk '{print $2}' Для оценки использования отдельно входной и выходной пропускной способности здесь необходимо заменить KRYTEN на KRYTENJN или KRYTEN_OUT соответственно. Конечно же, можно не ограничиваться критерием сбора статистики только для одного узла. Накапливать статистику можно для любого объекта, для которого можно создать iptables-правило, включая порты, МАС-адреса, и практически для всего, что передается по сети.

Удаленный анализ Удаленное наблюдение за сетью возможно с помощью rpcapd.

Если вы когда-либо наблюдали за сетевым трафиком из другого сегмента сети и использовали такой графический анализатор протокола, как Ethereal (http:// www.ethereal.com), то вы представляете, сколько это отнимает времени. Сначала необходимо выполнить перехват данных, после этого зайти на рабочую станцию, с которой запущен анализатор, и загрузить в него файл. Это создает реальную проблему из-за увеличения времени между выполнением эксперимента и просмотром результата. Таким образом, диагностика и устранение сетевых проблем занимают времени больше, чем должны. Одним из средств решения этой проблемы является rpcapd — программа, входящая в состав WinPcap (http://wjnpcap.polito.it). Программа rpcapd — это демон, который наблюдает за сетевыми интерфейсами в «беспорядочном режиме» и отправляет собранные данные на анализатор, запущенный на удаленной машине. Запустить rpcapd можно из командной строки или как службу. Для запуска rpcapd можно использовать ключ -п, позволяющий запускать демон без аутентификации.

Трюк № 66. Удаленный анализ

189

Для получения имени устройства с помощью WinDump просто запустите его с флагом -D: C:\Program Files\WinPcap>windump -D l.\Device\NPF_{EE07A5AE-4D19-4118-97CE-3BF656CD718F} (NDIS 5.0 driver) Получить имя можно также с помощью Ethereal, перейдя в меню Capture и щелкнув на кнопке Start. После этого откроется диалоговое окно, в котором перечислены все доступные в системе сетевые адаптеры (рис. 5.4). Имя устройства (device name) в этом списке — это то имя, которое необходимо указать при подключении к rpcapd с удаленной системы.

Рис. 5.4. Диалоговое окно Ethereal Capture Options

При подключении к удаленной машине с помощью любимого анализатора портов поместите имя сетевого интерфейса, за которым вы хотите наблюдать, после грсар и имени узла: rpcap://plunder/\Device\NPF_{EE07A5AE-4D19-4118-97CE-3BF656CD718F}

190


Пример использования Ethereal представлен на рис. 5.5.

Рис. 5.5. Источник удаленного захвата в Ethereal

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

ГЛАВА

6

Защита каналов Трюки № 67-81 Небезопасные компьютерные сети (такие, как Интернет и общедоступные беспроводные сети) являются враждебной средой, но их можно несколько «укротить». Балансируя между шифрованием и некоторыми приемами инкапсуляции, можно построить более надежные сети, независимо от используемой глобальной сети, даже если она полна негодяев, пытающихся посмотреть или по-другому использовать ваши данные. Эта глава в основном посвящена настройке безопасности и шифрованию сетей, которые не вызывают доверия. Некоторые трюки сконцентрированы в основном на обеспечении безопасности и шифровании транспортного механизма, в других рассматривается создание безопасных виртуальных частных сетей (virtual private network, VPN). При чтении этой главы вы познакомитесь с настройкой шифрованных соединений на основе IPsec в различных ОС, с созданием интерфейсов частных сетей, которые пользуются каналом зашифрованного соединения, а также с тем, как перенаправить TCP-соединения по зашифрованному каналу. Кроме того, будет рассмотрена настройка кросс-платформенных VPN-решений. Прелесть большинства из представленных трюков заключается в том, что после их изучения вы сможете комбинировать и сопоставлять решения шифрования на транспортном уровне с различными подходами к организации частных сетей, наиболее полно удовлетворяющих вашим требованиям. При этом можно построить широкомасштабную мощную частную сеть, использующую в качестве инфраструктуры Интернет. Эти методики можно реализовать на любом уровне: от организации связи между двумя офисами до построения полностью маршрутизируемой частной сети предприятия, основанной на сети Интернет.

Настройка IPsec в ОС Linux Обеспечьте безопасность трафика в Linux с помощью FreeS/WAN.

Наиболее популярным способом конфигурирования IPsec в Linux является использование пакета FreeS/WAN (http://www.freeswan.org). FreeS/WAN состоит из двух компонентов: KerneL IP Security (KLIPS) и pluto. KLIPS — это программный код ядра, который осуществляет действительное шифрование и дешифрование данных. Кроме того, он управляет базой данных политик безопасности (Security Policy Database, SPD). Pluto — это пользовательский демон, который предназначен для согласования с IKE.

192


В процессе компоновки FreeS/WAN создаются новое ядро и необходимые для управления утилиты. Загрузите с web-сайта проекта наиболее свежий исходный код и распакуйте его в /usr/src. FreeS/WAN поставляется с обширной документацией, позволяющей подстроить систему под ваши нужды. Компонент ядра может быть установлен как загружаемый модуль ядра либо статически откомпилирован непосредственно в ядро. Для компиляции FreeS/WAN на вашей машине должен быть установлен исходный код ядра. В ходе компиляции будет запущена утилита настройки ядра. Это — нормальное явление. Откомпилируйте FreeS/WAN, используя метод выбора настройки ядра (на основе меню или XII). По завершении компиляции установите ядро и пользовательские утилиты в соответствии с документацией FreeS/WAN (использованием команды make install с суффиксами). Настройка FreeS/WAN осуществляется с помощью двух файлов, /etc/ipsec.conf и /etc/ipsec.secrets. Область применения приведенных в этом трюке примеров очень ограниченна — они предназначены для использования только в беспроводной сети. СМОТРИ ТАКЖЕ Документация (manpages) для этих файлов достаточно информативна и охватывает более сложные требования установления связи. Еще одним великолепным источником дополнительной информации является книга «Building Linux Virtual Private Networks» («Построение виртуальных частных сетей в Linux»), авторами которой являются Олег Колесников (Oleg Kolesnikov) и Брайан Хэч (Brian Hatch) (издательство New Riders).

Файл ipsec.conf разбивает VPN-соединение на так называемые правый и левый сегменты. Разница между ними лишь в логическом разделении. Левый сегмент может быть внутренней или внешней сетью. Она позволяет использовать один и тот же файл настройки на обоих концах VPN-канала типа «сеть-в-сеть». К сожалению, в нашем случае между настройками клиента и настройками шлюза существуют различия. Файл содержит раздел настройки (config) и раздел соединения (conn). В разделе настройки указываются основные параметры IPsec, такие как доступные интерфейсы и специальные директивы, передаваемые в pluto. Раздел соединения описывает различные соединения, которые допустимы в VPN. Существует глобальный раздел соединения (conn %default), в котором указываются общие для обоих разделов значения, такие как время жизни (lifetime) ключа и способ обмена ключами. В представленном далее ipsec.conf на вашем шлюзе шифруется вся информация для Интернета с конечной точкой VPN: # /etc/ipsec.conf # установка параметров настройки config setup interfaces=Udefaultroute # отладочные параметры. Установите в "all" для получения подробной информации klipsdebug=none plutodebug=none # стандартная настройка Pluto plutoload=Usearch

НастройкаIPsecвОСFreeBSD Для безопасности трафика во FreeBSD используйте встроенную в эту ОС поддержку IPsec. Использование IPsec с IKE в ОС FreeBSD требует включения IPsec в ядро и установки пользовательской программы (racoon), для того чтобы добиться согласованности с IKE. Необходимо убедиться, что ядро скомпилировано при использовании следующих параметров:

Если это не так, то вам необходимо определить их, а затем скомпоновать и установить ядро. После этого выполните перезагрузку системы, чтобы проверить ее работоспособность. Racoon может устанавливаться с использованием сетевого раздела дерева портов либо загрузкой с адреса: ftp://ftp.kame.net/pub/kame/misc/. Установите racoon в соответствии с инструкцией, представленной в дистрибутиве. На стороне клиента сначала необходимо настроить racoon. Пример файла racoon.conf необходимо подстроить под собственные требования: path include "/usr/local/etc/racoon" ; path pre_shared_key "/usr/local/etc/racoon/psk.txt" ; remote anonymous { exchange_mode aggressive,main: my_identifier user_fqdn "[email protected]": • lifetime time 1 hour; initial contact on;

Stop) # Delete the MAC address from the ARP table echo 'stopping racoon' killall racoon *) # Standard usage statement echo "Usage: 4basename $0 4 {start|stop}" >&2 esac exit 0 Убедитесь, что файл является исполняемым, с помощью следующей команды: # быть разрешений пользуемым Файл chmoдоступен d/usr/local/etc/racoon/psk.txt 755 /usr/local/etc/rc.d/racoon.sh «секретом» racoon для чтения работать (shared-secret) только не будет. содержит root-пользователю. этот Дляфайл ваши IPsec-соединения содержит мандаты. Привашу неверной Этот сидентификацию совместно файл установке должен ис-

Трюк № 69. Настройка IPsec в ОС OpenBSD

197

Загрузите SPD с помощью команды setkey -f gateway.spd. Проверьте записи SPD с помощью параметра spddump в setkey. В данный момент должна быть возможность «прозвонить» клиента через шлюз. Он может принять пакет или два для завершения VPN-согласования, но непрерывное соединение устанавливается позже. Если возможность «прозвонки» отсутствует, проверьте наличие ошибок или предупреждений в протоколе.

Настройка IPsec в ОС OpenBSD Обеспечьте безопасность трафика в OpenBSD.

Настройка IPsec в OpenBSD значительно проще, поскольку она уже скомпилирована в ядро, поставляется с каждым выпуском ОС и доступна по умолчанию. Все, что остается, — это создать соответствующие файлы /etc/isakmpd/isakmpd.conf и /etc/isakmpd/isakmpd.policy, после чего запустить isakmpd (демон управления ключами IPsec). Исчерпывающая документация ОС OpenBSD и примеры файлов настройки еще больше упрощают задачу. Прежде всего необходимо поместить в /etc/isakmpd/isakmpd.policy что-то подобное следующей команде: KeyNote-Version: 2 Authorizes "POLICY" Licensees: "passphrase:mypassword" Conditions: app_domain — "IPsec policy" && esp_present == "yes" && esp_enc_alg == "aes" && esp_auth_alg =s= "hmac-sha" -> "true": Это определит пароль для использования IPsec-соединения. Теперь необходимо отредактировать файл /etc/isakmpd/isakmpd.conf, который должен содержать следующее: [General] Listen-on= Shared-SADB=

192.168.1.1 Defined

[Phase 1] Default* #Default=

ISAKMP-peer-remote ISAKMP-peer-remote-aggressive

[Phase 2] Passive-Connections=IPsec-local-remote [ISAKMP-peer-remote] Phase= Transport= Local-address= Configuration= Authenti cation=

1 udp 192.168.1.1 Default-main-mode mypassword

198


Такая конфигурация позволит подключаться с паролем mypassword. После настройки файлов необходимо запустить isakmpd: # /5Ып/15актрс1я

Для того чтобы isakmpd запускался при каждой загрузке системы, необходимо изменить /etc/rc.conf.local (или создать его, если он отсутствует) и добавить в него строку isakmpd_flags="" И все. Как обычно, если возникли проблемы подключения канала, проверьте протоколы системы.


199

Организация канала РРТР VPN-доступ легко и быстро устанавливается с помощью протокола Point-to-Point Tunneling Protocol.

Использование протокола Point-to-Point Tunneling Protocol1 (РРТР), как правило, означает автоматическое установление каналов РРР (трюк № 81) без необходимости вручную запускать РРР-демон на удаленной машине. Основное преимущество использования РРТР заключается в том, что Windows и Mac OS X изначально поддерживают создание VPN-соединения и предоставляют простые в использовании пользовательские интерфейсы для настройки соединений на пользовательской стороне. Таким образом, VPN-решение можно обеспечить, не прилагая со стороны пользователя больших усилий. Для настройки серверной стороны можно использовать РоРТоР (http://www. poptop.org) — РРТР-сервер с открытым исходным кодом. Создадим очень простую РРТР VPN-сеть с минимальными усилиями: загрузите дистрибутив из Сети, распакуйте его и перейдите в созданный при распаковке каталог. После этого необходимо запустить команду $ ./configure && make Далее получите полномочия root и установите РоРТоР: # make install Установленный при этом демон РоРТоР называется pptpd. Теперь необходимо создать файл настройки этого демона (/etc/pptpd.conf) и файл параметров, с которыми он будет использоваться: option /etc/ppp/options.pptpd localip 10.0.0.1 remoteip 10.0.0.2-100 Его содержимое определяет IP-адрес локального конца РРТР-соединения как 10.0.0.1 и создает пул адресов, которые будут динамически выделяться клиентам (10.0.0.2-100). После создания файла pptpd.conf должны использоваться адреса из диапазона, используемого внутренней сетью. Кроме того, этот файл определяет для pptpd настройку РРР-интерфейса, предусматривающую использование при запуске файла /etc/ppp/options.pptpd. В противном случае будут использованы заданные по умолчанию настройки (/etc/ppp/options), которые вряд ли вас удовлетворят. Создадим самостоятельно упомянутый ранее файл /etc/ppp/options.pptpd: lock name pptpd auth 1

Сетевая технология, которая поддерживает многопротокольные виртуальные частные сети (VPN), позволяя удаленным пользователям безопасно обращаться к корпоративным сетям с помощью коммутируемого соединения, предоставляемого поставщиком услуг Интернета (ISP), или с помощью непосредственного соединения с Интернетом.


200

Эти параметры обычно заставляют pppd использовать аутентификацию (auth) и указывают, что элементы файла /etc/ppp/chap-secrets соответствуют этому экземпляру pppd (имя pptpd). Поэтому для завершения настройки аутентификации pptpd в файле /etc/ppp/chap-secrets необходимо создать элемент для каждого клиента. Вот пример такого элемента, позволяющего пользователю с именем andrew подключаться с использованием пароля mypassword с любого удаленного IP-адреса: # Secrets for authentication using CHAP # client server secret andrew pptpd mypassword

IP addresses *

pptpd в поле сервера должно быть заменено любым пользователем, указанным в директиве name файла /etc/ppp/options.pptpd (если не используется pptpd). Можно ввести ограничение количества клиентов, перечислив список их IP-адресов. Теперь, когда сделана базовая настройка РоРТоР, можно попробовать подключиться к нему с использованием Windows-машины. Перейдите в папку Network Connections (Сетевые подключения) и щелкните на значке Create a new connection (Новое соединение) (это верно для Windows XP; в Windows 2000 найдите значок Make New Connection). Появится диалоговое окно (рис. 6.1).

Рис. 6 . 1 . Мастер создания нового соединения в Windows XP

Щелкните на кнопке Далее (Next) и выберите переключатель Подключиться к сети (Connect to the network at my workplace) (рис. 6.2). После этого щелкните на кнопке Далее и выберите переключатель Подключение к виртуальной частной сети (Virtual Private Network connection) (рис. 6.3).


201

Рис. 6.З. Выбор VPN-соединения

Щелкните на кнопке Далее и укажите наименование нового соединения (например, РоРТоР Test). Еще раз щелкните на кнопке Далее и введите внешний IP-адрес сервера, на котором выполняется pptpd. Щелкните на кнопке Далее и затем на кнопке Готово (Finish). Появится диалоговое окно регистрации (рис. 6.4). Перед вводом имени и пароля, указанных в файле /etc/ppp/chap-secrets, необходимо щелкнуть на кнопке Параметры (Properties) и перейти на вкладку Безопасность (Security). Найдите на ней флажок Требуется шифрование данных (Require data encryption) и сбросьте его (рис. 6.5). Теперь щелкните на кнопке ОК для ввода регистрационной информации, а также на кнопке Подключиться (Connect). Через несколько секунд вы будете подключены

202


к РРТР-серверу, и вам будет присвоен IP-адрес, выбранный из указанного пула адресов. Теперь можно проверить новое соединение, «прозвонив» удаленную сторону канала. При активном РРТР-соединении весь трафик, покидающий клиентскую сторону, будет шифроваться и отправляться на РоРТоР-сервер. Отсюда трафик пойдет к месту назначения.

Рис. 6.5. Изменение свойств системы безопасности

Трюк № 7 1 . Адаптивное шифрование с помощью FreeS/WAN

203

Адаптивное шифрование с помощью FreeS/WAN Используйте FreeS/WAN и записи DNS TXT для автоматического создания шифрованного соединения между машинами.

Одной из наиболее интересных функций, поддерживаемых FreeS/WAN (трюк № 67), является адаптивное шифрование. Оно позволяет явно шифровать трафик между двумя узлами, поддерживающими этот вид шифрования. Для этого каждый узел должен иметь открытый ключ; специально сгенерированный для использования с FreeS/WAN. Позже этот ключ может быть сохранен в записи DNS TXT этого узла. Когда узел желает инициировать шифрованное соединение с другим узлом, он с помощью DNS должен найти открытый ключ этого узла и инициировать соединение. Для начала сгенерируем ключ для каждого узла, который будет использовать эту функцию. Это можно сделать с помощью команды # ipsec newhostkey --output /tmp/*hostname* .key Теперь необходимо добавить содержимое файла, который был создан этой командой, в /etc/ipsec.secrets: # cat /tmp/xhostname* .key » /etc/ipsec.secrets Далее необходимо сгенерировать ТХТ-запись для помещения ее в DNS-зону. Это можно сделать с помощью подобной команды: # ipsec showhostkey --txt @colossus.nnc ; RSA 2192 bits colossus Mon Jan 12 03:02:07 2004 IN TXT "X-IPsec-Server(10)[email protected]" " AQ0R7rM7ZMBXu2ej/lvtzhNnMayZ01jwVHUyAIubTKpd/PyTMogJBAdbb3I0xzGLaxadPGfiqPN2AQn7 6zLIsYFMJnoMbBTDY/2xKlX/pWFRUUIHzJUqCBIijVWEMLNrIhdZbeils5/MgYIPaX20UL+yAdxV4RUU 3JJQhV7adVzQqEmdaNUnCjZ0vZG6m4zv6dGR0rVEZmJFP54v6WhckYfqSkQu3zkctfFgzJ/rMTB6Y38y 0byBg2HuWZMtWr M 8VrTQqi7IGGHK+mWk+wSoXer3iFD7JxRTzP0xLk6ihAJMibtKna3j7QP9ZHG0nm7NZ/L5M9VpK+Rfe+e vUUMUTfAtSdlpus2BIeXGWcPfz6rw305H9" А теперь добавьте эту запись в зону и перезагрузите ее. Проверить правильность работы DNS можно с помощью команды # ipsec verify Checking your system to see if IPsec got installed and started correctly Version check and ipsec on-path [OK] Checking for KLIPS support in kernel [OK] Checking for RSA private key (/etc/ipsec.secrets) [OK] Checking that pluto is running [OK] DNS checks. Looking for TXT in forward map: colossus [OK] Does the machine have at least one non-private address [OK] Перезапустите FreeS/WAN с п о м о щ ь ю команды # /etc/init.d/ipsec restart

Перенаправление и шифрование трафика с помощью SSH Обеспечьте защиту сетевого трафика произвольного порта с помощью перенаправления порта.

Помимо удаленного доступа к ядру и выполнения команд, OpenSSH позволяет осуществлять перенаправление произвольного TCP-порта на противоположный конец соединения. Это чрезвычайно удобно для защиты трафика электронной почты, содержимого web-сайтов и другого трафика, который необходимо сохранить в неприкосновенности (по крайней мере, на протяжении канала до противоположной стороны). SSH осуществляет локальное перенаправление за счет привязки локального порта, выполнения шифрования и отправки зашифрованных данных удаленной стороне SSH-соединения. После чего выполняются их дешифрование и отправка на указанный удаленный узел и порт. Запуск SSH-канала осуществляется с помощью ключа -L (сокращение от Local): # ssh -f -N -L 110:я7. Введите строку -L, как если бы вы находились в режиме командной строки, например: rob@catlin:~$ rob@catlin:~$ -С (it doesn't echo) ssh> -L8080:local host:80 Forwarding port. 4. Текущее ядро перенаправит локальный порт 8000 на 80-й порт узла catlin, как если бы вы ввели его на первом месте. Имеется возможность с помощью ключа -д разрешить другим (удаленным) клиентам подключаться к перенаправленному порту. Если вы прошли процедуру регистрации на удаленном шлюзе, выполняющем роль NAT для частной сети, то используйте команду $ ssh -f -g -N -L8000:local host:80 10.42.4.6

206


5. Это произведет перенаправление всех соединений с 8000-го порта шлюза на 80-й порт внутреннего узла 10.42.4.6. Если шлюз имеет «живой» Интернет-адрес, то это позволит любому пользователю Сети подключиться к web-серверу на 10.42.4.6, как если бы он был запущен на 8000-м порте шлюза. 6. Еще один достойный внимания момент: перенаправляемый узел не должен быть локальным узлом. Он должен быть любым узлом, с которым подключаемая машина может обращаться напрямик. Например, для перенаправления локального 5150-го порта на web-сервер, находящийся где-то во внутренней сети, попробуйте выполнить команду $ ssh -f -N -L5150:intranet.insider.nocat:80 gateway.nocat.net 7. Полагая, что вы запускаете частный домен с именем .nocat, а его шлюз .nocat.net также подключен к частной сети, весь трафик для 5150-го порта удаленной системы будет обязательно перенаправляться на intranet.insider.nocat:80. Адрес intranet.insider.nocat не должен разрешаться DNS для удаленной системы. Его поиск не выполняется, пока установлено соединение с gateway.nocat.net, а потом этот поиск выполняет данный шлюз. Для безопасного поиска этого сайта с удаленной системы попробуйте подключиться к http://localhost:5150/. Роб Фликингер (Rob Flickenger) «Трюки Linux-сервера» («Linux Sewer Hacks»)

Быстрая регистрация в системе с помощью ключей SSH-клиента Используйте SSH-ключи вместо парольной идентификации для ускорения автоматической регистрации в системе.

Если вы являетесь администратором нескольких машин, возможность быстрого перехода к другому ядру на любом сервере является очень важной. Необходимость ввода ssh my. server. сот (после чего вводится пароль) не только утомительна, но и мешает сконцентрироваться. Необходимость внезапно переключаться с вопроса «В чем проблема?» на «Как войти?», а затем на «Что же дальше?» вызвала преждевременное старение уже не одного администратора. Это является цифровым эквивалентом маразматической фразы: «А зачем я пришел в эту комнату?» Во всяком случае, чем больше усилий затрачивается на регистрацию в системе, тем меньше сил останется на решение проблемы. Последние версии SSH предлагают безопасную альтернативу многократному вводу пароля: обмен открытым ключом. В рассматриваемых далее примерах предполагается использование OpenSSHv3.4pl или более свежих версий. Для применения открытого ключа с SSH-сервером сначала необходимо сгенерировать пару ключей, открытый и закрытый (секретный): $ ssh-keygen -t rsa Для создания DSA-ключей можно воспользоваться ключом -t dsa либо -t rsal, если вы используете RSA Protocol vl. (Как вам не стыдно использовать первую

Трюк № 73. Быстрая регистрация в системе с помощью ключей SSH-клиента

207

версию! При первой же возможности переходите на вторую!) Желательно использовать RSA-ключи, поскольку с DSA-ключами бывают проблемы, хотя они используются очень редко. После ввода команды вы увидите следующее: Generating public/private rsa key pair. Enter f i l e in which to save the key (/home/rob/.ssh/id_rsa): Просто нажмите клавишу Enter. После этого будет запрошена идентификационная фраза1 (passphrase); затем дважды нажмите клавишу Enter (но прочитайте следующий раздел, «Соображения безопасности»). Вот как должен выглядеть результат: Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/rob/.ssh/id_rsa. Your public key has been saved in /home/rob/.ssh/id_rsa.pub. The key fingerprint is: a6:5c:c3:eb:18:94:0b:06:al:a6:29:58:fa:80:0a:bc rob@loca1 host Создано два файла, ~/.ssh/id_rsa и ~/-ssh/id_rsa.pub. Для использования этой пары ключей на сервере попробуйте выполнить команду $ cat .ssh/id_rsa.pub | \ ssh server "mkdir .ssh && chmod 0700 .ssh && cat > .ssh/authorized_keys2" Конечно же, подставьте вместо server имя вашего сервера. Теперь для автоматической регистрации без ввода пароля достаточно просто ввести ssh sewer. Да, для SCP также будет использоваться эта пара ключей. Если это не работает, проверьте разрешения файла для ~/.ssh/* и sewer.-/.ssh/\ Секретный ключ (id_rsa) должен быть в режиме 0600 (и находиться только на локальной машине), а все остальное должно быть в режиме 0655 или лучше. Кроме того, требуется, чтобы домашний каталог на сервере был в режиме 755 или лучше. Если группа имеет разрешение writable, любой член группы, владеющей домашним каталогом, может удалить ~/.ssh, даже если группа не имеет разрешения writable в отношении ~/.ssh. На первый взгляд это незаметно, но если они смогут сделать это, то смогут создать собственный ~/.ssh и файл authorlzed_keys2, который может содержать любые ключи. К счастью, SSH-демон перехватит этот запрос и откажет в идентификации по открытому ключу, пока разрешения не будут исправлены.

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

208


(или всех) машинах? Вы когда-нибудь использовали этот пароль в сомнительных случаях (на web-сайте, на личной машине, которая не совсем совершенна, либо с SSH-клиентом на машине, которой не можете управлять)? Наверняка, любая из этих ситуаций для вас не нова; в этом случае SSH-ключ с такими же настройками сделает практически невозможным получение несанкционированного доступа к вашей сети (конечно же, если секретный ключ хранится в безопасном месте). Еще одним способом сохранения равновесия между простотой использования и безопасностью является применение идентификационной фразы (passphrase) в вашем ключе, но для управления ключами используйте SSH-агента. При запуске агента будет однократно запрошена идентификационная фраза, которая будет сохранена в кэш-памяти до момента уничтожения (kill) агента. Некоторые люди доходят до того, что хранят SSH-ключи на съемных носителях (например, на USB флеш-карте) и постоянно носят их с собой. Однако если вы выбрали использование SSH-ключей, то сразу поймете, что они являются очень полезной альтернативой традиционным паролям. Роб Фликипгер (Rob Flickenger) «Трюки Linux-сервера» («Linux Server Hacks»)

Squid-прокси no SSH Защитите web-трафик от посторонних глаз и увеличьте производительность этого процесса.

Squid (http://www.squid-cache.org) обычно используется как НТТР-акселератор. Это большой, хорошо управляемый и полноценный кэширующий HTTP прокси-сервер, находящий применение на множестве коммерческих платформ. Помимо прочего, squid предоставляется бесплатно с открытым исходным кодом. Поскольку все его функции реализуются с помощью одного TCP-порта, squid является идеальным кандидатом для создания SSH-канала. Это не только помогает обезопасить web-браузер при использовании беспроводных сетей, но и ускоряет работу браузера. Сначала выберите сервер, на котором будет помещаться squid-кэш. Обычно это Linux- или BSD-машина в локальной проводной сети, хотя squid также может работать в Windows под Cygwin (http://www.cygwin.com/). Необходима быстрая связь с кэшем, поэтому размещение его на удаленном конце модемного соединения — плохая идея (если только вам не нравится симуляция Интернета образца 1995 года). В домашней сети это, как правило, та же машина, что используется в качестве межсетевого экрана или DNS-сервера. К счастью, для одновременного обслуживания нескольких пользователей squid не предъявляет больших системных требований, поэтому вполне можно воспользоваться блоком, на котором исполняются и другие службы. Полное описание установки squid выходит за рамки рассматриваемого трюка, так как настройка его очень сложна. Убедитесь в наличии у вас прав доступа и установите пароль для интерфейса обслуживания. Если имеются проблемы

Трюк № 74. Squid-прокси по SSH

209

с запуском, изучите страничку Дженифер Весперман (Jennifer Vesperman) «Installing and Configuring Squid» («Установка и настройка Squid»), расположенную по адресу: http://linux.oreillynet.eom/pub/a/linux/2001/07/26/squid.html. После установки и запуска squid по умолчанию привязывается к 3128-му ТСР-порту. После этого необходимо проверить его вручную, настроив НТТР-прокси на сервер. Например, предположим, что сервер является proxy.example.com. В браузере Mozilla выберите Preferences • Advanced • Proxies (Предпочтения • Дополнительно • Прокси) (рис. 6.6).

Рис. 6.6. Проверка squid с использованием HTTP Proxy

Введите proxy.example.com в качестве узла HTTP Proxy и 3128 — в качестве порта. Щелкните на кнопке ОК и попробуйте загрузить какую-нибудь web-страницу. Вы сразу же увидите ее. Если появится ошибка Access Denied (Доступ запрещен), проверьте строки http^access в файле squid.conf и при необходимости перезапустите squid. При нормальной работе squid необходимо лишь перенаправить ваше соединение с ним через SSH. Настройте локальный «слушатель» на 3128-й порт и выполните перенаправление на proxy.example.com:3128:

rob@caligula:~$ ssh -L 3128:local host:3128 proxy.example.com -f -N Это настроит SSH-канал и автоматически переведет его в фоновый режим работы. Далее измените в настройках браузера узел HTTP Proxy на local host и перезагрузите web-страницу. Поскольку SSH-канал запущен, web-трафик будет зашифрован на всем пути до proxy.example.com, где он будет расшифрован и отправлен в Интернет.

210


Самым большим преимуществом этой методики (по сравнению с использованием прокси SSH SOCKS 4 (трюк № 75)) является то, что использование НТТР-прокси поддерживают практически все браузеры, a SOCKS 4 — далеко не все. В ОС Mac OS X поддержка НТТР-прокси встроена в саму ОС. Это означает, что любое приложение будет явно использовать настройки прокси. Обратите внимание на то, что НТТР-прокси имеют те же проблемы с DNS, что и SOCKS 4. Обычно squid-прокси используется из локальной сети, поэтому не приходится вникать в проблему шизофрении DNS. И хотя теоретически squid может запускаться везде (даже за пределами удаленного межсетевого экрана), изучите примечание о работе DNS «Использование SSH в качестве SOCKS-npoкси» (см. трюк № 75). Запуск squid практически не требует подготовки, но он может обезопасить и ускорить web-трафик в беспроводной среде. Конечно же, squid сможет одновременно поддерживать столько беспроводных пользователей, сколько вы захотите, поэтому убедитесь в корректности настроек всех обычных беспроводных пользователей и обеспечьте защиту web-трафика. Роб Фликингер (Rob Flickenger) «Трюки беспроводной сети» («Wireless Hacks»)

Использование SSH в качестве SOCKS-прокси Защитите web-трафик с помощью VPN-функциональности, встроенной в SSH.

В поисках наилучшего и самого совершенного способа защиты беспроводных сетей многие люди упускают самую полезную функцию SSH: ключ -D. Этот простой ключ скрыт в конце документации системы SSH. Вот цитата из этой документации: -D port Specifies a local "dynamic" application-level port forwarding. This works by allocating a socket to listen to port on the local side, and whenever a connection is made to this port, the connection is forwarded over the secure channel, and the application protocol is then used to determine where to connect to from the remote machine. Currently the SOCKS 4 protocol is supported, and SSH will act as a SOCKS 4 server. Only root can forward privileged ports. Dynamic port forwardings can also be specified in the configuration file. («Определяет локальное, «динамическое» перенаправление порта на уровне приложения. Работает путем размещения сокета для «прослушивания» порта на локальной стороне. При подключении к этому порту соединение пересылается по защищенному каналу, и для определения места подключения с удаленной машины используется протокол приложения. В настоящее время используется протокол SOCKS 4, a SSH выступает в роли SOCKS 4-сервера. Привилегированный порт может перенаправлять только root-пользователь. Динамическое перенаправление порта также может указываться в файле настройки».)

Трюк № 75. Использование SSH в качестве SOCKS-прокси

211

Если у вас имеется программное обеспечение, совместимое с SOCKS 4, это обеспечивает крайне полезную возможность: можно получить действительно зашифрованный прокси-сервер на любой машине, на которой имеется SSH. Для этого не надо ничего устанавливать дополнительно ни на вашей машине, ни на удаленном сервере. Так же как и при SSH-перенаправлении порта (см. трюк № 72), ключ -D вызывает привязку к определенному локальному порту и шифрацию любого трафика этого порта, превращая его в канал с выполнением дешифрации на другой стороне. Например, для настройки SOCKS 4-прокси с локального порта 8080 на удаленную систему введите rob@caligula:~$ ssh -D 8080 remZote Вот и все, что для этого надо. Теперь просто укажите local host: 8080 в качестве SOCKS 4-прокси в своем приложении, и все соединения приложения будут осуществляться по зашифрованному каналу. Например, для настройки SOCKS-прокси в Mozilla выберите Preferences • Advanced • Proxies (Предпочтения • Дополнительно • Прокси) (рис. 6.7).

Рис. 6.7. Настройка прокси в Mozilla

Выберите переключатель Manual proxy configuration (Ручная настройка прокси) и в качестве имени SOCKS-узла введите local host. Также введите номер порта, который вы указали в ключе -D, и проверьте установку переключателя SOCKSv4. Щелкните на кнопке ОК. Весь трафик, генерируемый Mozilla, теперь шифруется и выглядит как исходящий от удаленной машины, на которой вы зарегистрировались с помощью SSH. Любой, кто прослушивает беспроводной трафик, теперь

212


видит огромный зашифрованный SSH-поток, но действительные данные хорошо защищены. Важный момент, который необходимо помнить: SOCKS 4 не имеет «родной» поддержки DNS-трафика. Этим вызваны два побочных эффекта, которые необходимо учитывать при использовании его для защиты беспроводных передач. Прежде всего, DNS-запросы по-прежнему отправляются в открытом виде. Это означает, что любой, кто прослушивает, сможет увидеть наименования просматриваемых вами сайтов, хотя действительные URL и данные остаются спрятанными. Это совсем небольшой риск, но его все равно необходимо учитывать. Кроме того, по-прежнему используется локальный DNS-сервер, но трафик исходит от удаленного конца прокси. Это может вызвать интересный (и нежелательный) побочный эффект при попытке обратиться к ресурсам частной сети. В качестве иллюстрации выявления трудноуловимых проблем рассмотрим корпоративную сеть с web-сервером intranet.example.com. Он использует частный адрес 192.168.1.10, но доступен из Интернета через перенаправляющий межсетевой экран. DNS-сервер для intranet.example.com обычно отправляет ответы с различными IP-адресами в зависимости от того, откуда пришел запрос, используя возможность просмотра в BIND 9. При поступлении запроса из Интернета имеется возможность обратиться к intranet.example.com с помощью IP-адреса 208.201.239.36, который за пределами межсетевого экрана является действительным адресом. Теперь представим, что вы используете только что рассмотренный пример SOCKS-прокси, а в качестве удаленной системы выступает машина, расположенная за пределами корпоративного межсетевого экрана. В качестве IP-адреса intranet.mybusiness.com DNS-сервер вернет 208.201.239.36 (поскольку вы запрашиваете имя из-за межсетевого экрана). Но HTTP-запрос действительно поступает с удаленной системы и пытается обратиться к адресу 208.201.239.36. Как обойти эту DNS-шизофрению? Простой способ избавиться от этой проблемы заключается в использовании на вашей машине локального файла узлов. Добавьте в /etc/hosts (или в соответствующий вашей ОС файл) следующий элемент: 192.168.1.10

intranet.example.com

Кроме того, вы имеете возможность перечислить любое количество узлов, обращение к которым возможно только с внутренней стороны корпоративного межсетевого экрана. При попытке найти один из этих сайтов до обращения к DNS выполняется обращение к файлу локальных узлов (hosts), что приводит к использованию частного IP-адреса. Поскольку этот запрос действительно был послан с удаленной системы, он без проблем найдет внутренний сервер. Аналогично, отклики, приходящие обратно на SOCKS-прокси удаленной системы, шифруются и перенаправляются по SSH-каналу, после чего появляются в браузере, как будто они пришли из Интернета. В ближайшей версии SSH планируется ввести поддержку SOCKS 5, что сделает возможным канальное DNS-разрешение. Это особенно понравится пользователям

Трюк № 76. Шифрование и создание канала для трафика с помощью SSL

213

Mac OS X, поскольку в этой ОС уже имеется поддержка SOCKS 5. Когда SSH будет поддерживать SOCKS 5, каждое OS Х-приложение сможет автоматически воспользоваться преимуществами socks-прокси, зашифрованными SSH. Тем временем нам пока приходится обходиться зашифрованными НТТР-прокси (трюк № 74). Роб Фликингер (Rob Flickenger) «Трюки беспроводной среды» («Wireless Hacks»)

Шифрование и создание канала для трафика с помощью SSL Используйте stunnel для обеспечения SSL-шифрования любой сетевой службы.

Stunnel (http://www.stunnel.org) — это мощная и удобная программа, которая с помощью SSL шифрует трафик любого TCP-порта. Она образует канал, практически так же, как SSH, предоставляя для этого локальный порт. Программа шифрует трафик, посылаемый на этот порт, направляет его удаленной системе, дешифрует трафик и направляет его на локальный порт системы. Stunnel также может обеспечить явную SSL-поддержку для inetd-совместимых служб. Для установки stunnel просто выполните команду ./configure из каталога, который создан при распаковке загруженного из Сети архива. Поскольку stunnel для работы требуется OpenSSL (http://www.openssl.org), то сначала загрузите и установите OpenSSL Если вы хотите откомпилировать stunnel с поддержкой ТСР-оболочек или установить OpenSSL в нестандартное место, то необходимо воспользоваться параметром --with-tcp-wrappers или --with-ssl. Например, для настройки stunnel с поддержкой TCP-оболочек при установке OpenSSL в /opt/ выполните $ ./configure --with-tcp-wrappers --with-ssl=/opt/openssl После запуска этого сценария для действительной компиляции stunnel необходимо выполнить команду make. После этого будет предложено создать самоподписанный сертификат. Этот сертификат будет не только самоподписанным, но и срок его действия будет ограничен одним годом. Если вас это не устраивает, создайте собственный сертификат и Certificate Authority (см. трюк № 45). До версии 3.x программы stunnel имелась возможность настраивать все параметры из командной строки. В версиях 4.x и выше используется файл настройки stunnel.conf. Пример этого файла обычно можно найти в /etc/stunnel/stunnel. conf-sample или /usr/local/etc/stunnel/stunnel.conf-sample. Давайте рассмотрим базовую форму файла настройки, указывающего перенаправление локального порта на удаленный порт. Клиентская сторона: pi d = client = yes [<server port>] accept = connect = :<server port>

214 Глава 6. Защита каналов The server side: cert = /etc/stunnel/stunnel.pem pid client = no [] accept = <server port> connect = Можно использовать стандартный файл настройки или выбрать иной файл. В первом случае stunnel запускается безо всяких аргументов. В противном случае следует указать необходимый файл настройки в качестве первого аргумента. При имеющейся сейчас настройке программа способна подключиться к (перенаправляемому порту) на клиентской стороне. После этого stunnel зашифрует трафик, получаемый с этого порта, и отправит его на <server port> (серверный порт) удаленной стороны, указанной в (адрес удаленной стороны). На удаленной системе stunnel дешифрует полученный на указанный порт трафик и направит его программе, которая «слушает» на удаленной системе. Эквивалентная команда перенаправления портов в SSH могла бы выглядеть так: ssh -f -N -L :: \ Если есть желание указать PID файла, можно настроить переменную pid для любого файла. Однако если полностью пропустить переменную pid, то stunnel попытается на основе настроек, использовавшихся при компиляции, создать либо /var/run/ stunnel.pid, либо /usr/local/var/run/stunnel.pid (то есть $prefix/var/run/stunnel.pid). Помимо предоставления SSH-подобного перенаправления портов, stunnel также может использоваться для добавления SSL-возможностей в inetd-подобные службы. Это идеально подходит для внедрения SSL в электронную почту или другие сервисы, не обладающие «родной» SSL-функциональностью. Вот элемент inetd.conf для SWAT (средства настройки Samba с web-интерфейсом): swat stream tcp nowait.400 root /usr/local/samba/bin/swat swat Для добавления SSL-поддержки в SWAT сначала необходимо создать файл настройки для stunnel. Давайте назовем его swat.conf и поместим в /etc/stunnel: cert = /etc/stunnel/swat.pem exec = /usr/local/samba/bin/swat execargs = swat Затем изменим элемент inetd.conf следующим образом: swat stream tcp nowait.400 root /usr/sbin/stunnel stunnel \ /etc/stunnel/swat.conf Теперь можно безопасно обращаться к SWAT с помощью любимого браузера, поддерживающего SSL.

Трюк № 77. Канальные соединения внутри HTTP

215

В качестве альтернативного варианта можно вообще покончить с inetd и заставить stunnel «слушать» соединения клиентов, а затем порождать подпроцесс от самого процесса службы. Для этого создайте файл настройки с подобным содержанием: cert = /etc/stunnel/swat.pern [swat] accept = 901 exec - /usr/local/samba/bin/swat execargs = swat После этого запустите stunnel с указанием пути к этому файлу: # stunnel /etc/stunnel/swat.conf Кроме того, эту программу можно запускать во время загрузки, поместив предыдущую команду в сценарий запуска (то есть в /etc/rc.local). Stunnel — очень мощное средство: оно может не только перенаправлять соединения по зашифрованному каналу, но и использоваться для добавления SSLвозможностей в распространенные службы. Это особенно удобно, когда уже существуют клиенты с SSL-поддержкой. Таким образом, на серверной стороне достаточно использовать лишь stunnel, которая обеспечивает шифрование службы без необходимости установки дополнительного программного обеспечения.

Канальные соединения внутри HTTP Прорыв через «строгие» межсетевые экраны с помощью httptunnel.

Если вы когда-либо были в пути и оказывались там, где единственным средством общения с внешним миром являлся невероятно «строгий» межсетевой экран, вы, вероятно, представляете страдания при попытке добиться чего-либо, кроме отправки/получения электронной почты и общего просмотра web-страниц. На помощь приходит httptunnel (http://www.nocrew.org/software/httptunnel.html). Эта программа позволяет организовать канал по HTTP-протоколу для произвольного соединения с удаленным узлом. Это особенно полезно в упомянутом случае, когда web-доступ разрешен, а остальные службы запрещены. Конечно же, можно воспользоваться различным каналообразующим программным обеспечением и настроить его на использование 80-го порта, но что делать, если межсетевой экран на самом деле является web-прокси? Это приблизительно то же, что межсетевой экран на уровне приложения, способного принимать только действительные HTTP-запросы. К счастью, с этим хорошо справляется httptunnel. Для компиляции httptunnel загрузите архив и запустите команды configure и make: $ tar xfz httptunnel-3.3.tar.gz $ cd httptunnel-3.3 $ ./configure && make

Трюк № 78. Создание канала с помощью VTun и SSH

217

--proxy-authorization, позволяющий для идентификации указать имя и пароль. Вот как они используются: htc -P myproxy:8000 -A andrew:mypassword -F 22 colossus:80 Если порт, который «слушает» прокси, является стандартным портом web-npoкси (8080), то прокси можно указать с помощью IP-адреса или имени узла.

Создание канала с помощью VTun и SSH Свяжите две сети с помощью VTun и одного SSH-соединения.

VTun — это пользовательский сервер канала, позволяющий обеспечить для сети канал, связывающий ее с другой сетью с помощью универсального канального драйвера ядра (tun). Зашифрованный канал, такой как Vtun, позволяет организовать роуминг беспроводных клиентов для защиты всего их 1Р-трафика за счет криптоустойчивого шифрования. Канал обычно запускается под Linux, BSD и Mac OS X. Примеры, приведенные в этой главе, предполагают использование ОС Linux. Описанная далее процедура позволит узлу с частным IP-адресом (10.42.4.6) создавать новый канал с реальным, живым маршрутизируемым IP-адресом (208.201.239.33), работающим так, как будто здесь нет частной сети. Это достигается установлением канала, сбросом маршрута по умолчанию и добавлением нового маршрута по умолчанию через другой конец канала. Для начала рассмотрим существующую конфигурацию сети (до организации канала): root@client:~# ifconfig eth2 eth2 Link encap:Ethernet HWaddr 00:02:2D:2A:27:EA inet addr:10.42.3.2 Bcast:10.42.3.63 Mask:255.255.255.192 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:662 errors:0 dropped:0 overruns:0 frame:0 TX packets:733 errors:0 dropped:0 overruns:0 carrier:0 collisionsrO txqueue!en:100 RX bytes:105616 (103.1 Kb) TX bytes:74259 (72.5 Kb) Interrupt:3 Base address:0x100 root@c1ient:~# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.42.3.0 * 255.255.255.192 U 0 0 0 eth2 loopback * 255.0.0.0 U 0 0 0 1o default 10.42.3.1 0.0.0.0 UG 0 0 0 eth2 Как видим, локальная сеть использует адрес 10.42.3.0-26, IP — 10.42.3.2, а шлюз по умолчанию — 10.42.3.1. Этот шлюз обеспечивает трансляцию сетевого адреса

Трюк № 79. Автоматический генератор vtund.conf

221

Этот метод работает отлично, если вы позволяете VTun использовать криптоустойчивое шифрование, а на удаленной стороне нет взлома. Нет ничего страшного в применении его на машинах, подключенных к Интернету. Для использования VTun поверх SSH (положившись на обеспечиваемые SSH идентификацию и шифрование) просто перенаправьте 5000-й порт клиента на 5000-й порт сервера: root@client:~# ssh -f -N -с blowfish -С -L5000:localhost:5000 server root@client:~# vtund -p home localhost root@client:~# traceroute -n yahoo.com traceroute to yahoo.com (64.58.79.230). 30 hops max, 40 byte packets 1 208.201.239.32 24.715 ms 31.713 ms 29.519 ms 2 208.201.239.1 28.389 ms 36.247 ms 28.879 ms 3 208.201.224.194 48.777 ms 28.602 ms 44.024 ms 4 208.201.224.5 38.788 ms 35.608 ms 35.72 ms 5 206.24.221.217 37.729 ms 38.821 ms 43.489 ms 6 206.24.210.62 39.577 ms 43.784 ms 34.711 ms 7 206.24.226.103 110.761 ms 111.246 ms 117.15 ms 8 206.24.238.57 112.569 ms 113.2 ms 111.773 ms 9 206.24.238.26 111.466 ms 123.051 ms 118.58 ms 10 216.109.66.132 113.79 ms 119.143 ms 109.934 ms 11 216.33.98.19 111.948 ms 117.959 ms 122.269 ms 12 216.35.210.126 113.472 ms 111.129 ms 118.079 ms 13 64.58.77.41 110.923 ms 110.733 ms 115.22 ms Для того чтобы предотвратить нежелательное подключение к vtund по 5000-му порту сервера, добавьте правило netfilter для сброса соединений из внешнего мира: root@server:~# iptables -A INPUT -t f i l t e r -i ethO \ -p tcp --dport 5000 -j DROP Это разрешит прохождение локальных соединений (поскольку они используют цепь обратной связи), а для установления соединения они потребуют SSH-канал к серверу. Как можно отметить, это крайне удобное средство. Помимо предоставления живого IP-адреса машинам, находящимся после NAT, можно эффективным образом связывать две сети, если между ними имеется одно SSH-соединение (исходящее с любой стороны). Если вы затрудняетесь или вам лень настроить vtund.conf и вы не хотите разбираться в том, что необходимо изменить при настройке этого файла на клиентской стороне, обратитесь к автоматическому генератору vtund.conf (трюк № 79). Роб Фликипгер (Rob Flickenger) «Трюки Linux-сервера» («Linux Sewer Hacks»)

Если вы только что изучили трюк № 78, то вам будет приятно узнать, что представленный далее сценарий позволит автоматически сгенерировать файл vtund.conf для клиентской стороны.

222


Если вы не изучили предыдущий трюк (или никогда не использовали VTun), то вернитесь к нему и изучите, перед тем как взяться за этот Perl-сценарий. По существу, предлагается отбросить метод проб и ошибок при изменении таблицы маршрутизации на клиентской стороне за счет определения шлюза по умолчанию и автоматизированного построения на клиентской стороне файла vtund.conf. Для настройки сценария загляните в раздел Configuration (Настройка). Первая строка, $Config, содержит адреса, порт и секрет, которые мы использовали в трюке VTun. Вторая строка является примером того, как производится добавление. Запустить этот сценарий можно, либо вызвав его как vtundconf home, либо установив $TunnelName на этот сценарий, но все же лучше создать символические ссылки на этот сценарий: # In -s vtundconf home # In -s vtundconf tunnel2 После этого можно сгенерировать vtund.conf, вызвав непосредственно символическую ссылку: # vtundconf home > /usr/local/etc/vtund.conf Может возникнуть вопрос: почему приходится прибегать к таким сложностям для создания сценария генерации vtund.conf в одном месте? После того как настройки установлены, их никогда не приходится менять, правильно? Да, обычно так и есть. Но представьте переносной компьютер с Linux, который в течение дня работает во множестве различных сетей (DSL-линия дома, Ethernet — на работе и беспроводное соединение — в близлежащем кафе). При однократном запуске vtundconf во всех этих местах вы постоянно будете иметь работающую конфигурацию, даже если IP-адрес и шлюз по умолчанию назначаются DHCP. Это значительно упрощает получение и быстрый запуск живого маршрутизируемого IP-адреса независимо от топологии локальной сети. Между прочим, VTun нормально работает в ОС Linux, FreeBSD, Mac OS X, Solaris и др. Сохраните этот файл под именем vtundconf и запускайте его в «новой» беспроводной сети для генерации соответствующего vtund.conf «на лету»: #!/usr/bin/perl -w

#

# vtund wrapper in need of a better name. # # (c)2002 Schuyler Erie & Rob Flickenger # ################ CONFIGURATION # If Tunnel Name is blank, the wrapper will look at @ARGV or $0. # # Config is TunnelName, Local IP, RemotelP. TunnelHost, TunnelPort, Secret # my STunnelName = "";

8 Зак. 1103

226


Роб Фликингер (Rob Flickenger) «Трюки Linux-сервера» («Linux Server Hacks»)

Создание VPN может оказаться очень сложным, особенно когда клиенты работают на различных платформах. Довольно часто бывает невозможно организовать одну реализацию VPN для всех. В качестве администратора вам придется попробовать сделать несколько VPN-реализаций для работы на всех платформах, которые необходимо поддерживать, что может стать кошмаром. К счастью, кто-то уже заполнил вакуум кроссплатформных VPN и написал OpenVPN (http://openvpn.sourceforge.net). Эта программа поддерживает Linux, Solaris, OpenBSD, FreeBSD, NetBSD, Mac OS X и Windows 2000/XP. OpenVPN достигает своей цели за счет обеспечения всего шифрования, управления ключами и настройки соединений в одном пользовательском демоне, оставив работу по обеспечению действительного туннелирования операционной системе узла.

Трюк № 80. Создание кроссплатформной VPN

227

Для создания канала OpenVPN использует виртуальные устройства операционной системы (TUN или ТАР). Эти устройства экспортируют интерфейс виртуальной сети, который впоследствии используется для обеспечения интерфейса «pointto-point» между узлами, входящими в VPN, и управляется процессом openvpn. Вместо трафика, отправляемого или получаемого этими устройствами, он получает трафик из пользовательского приложения или отправляет его этому приложению. При этом данные, посылаемые на виртуальное устройство, переправляются в программу openvpn, которая шифрует их и отправляет openvpn-процессу, запущенному на удаленной стороне VPN-линии. При приеме данных на удаленной стороне процесс openvpn дешифрует их и переправляет на виртуальное устройство этой машины. Далее этот пакет обрабатывается так же, как и в случае получения его через любой физический интерфейс. OpenVPN использует SSL и полагается на библиотеку OpenSSL (http://www.openssl. org) в вопросах обеспечения шифрования, идентификации и проверки сертификатов. Создаваемые OpenVPN каналы могут как использовать предварительно распределенные статические ключи, так и воспользоваться преимуществами динамического выделения ключей и цифровых сертификатов TSL. Поскольку OpenVPN использует OpenSSL, она может поддерживать любой шифр, поддерживаемый OpenSSL Основное преимущество здесь заключается в том, что OpenVPN сможет явно поддерживать любой новый шифр, который будет добавлен в дистрибутив OpenSSL. При использовании ОС Windows все, что необходимо сделать, — это загрузить из Сети установщик и настроить OpenVPN. На всех остальных платформах необходимо предварительно скомпилировать саму OpenVPN. Перед компиляцией и установкой OpenVPN убедитесь, что OpenSSL уже установлена. Также необходимо установить библиотеку архивирования LZO (http://www.oberhumer.com/ opensource/lzo/). Использование LZO-сжатия позволяет более эффективно использовать полосу пропускания и при некоторых условиях даже значительно повысить производительность соединения с Интернетом. Для компиляции и установки OpenVPN загрузите архив и введите $ tar xfz openvpn-1.5.0.tar.gz $ cd openvpn-1.5.0 $ ./configure && make Если вы установили LZO-библиотеки и заголовочные файлы, например, в /usr/lib и /usr/include, то вам необходимо использовать параметры --with-lzo-headers и --with-lzo-lib. Например, если вы установили LZO в подкаталог каталога /usr/ local, то необходимо запустить настроечный сценарий: $ ./configure --with-lzo-headers=/usr/local/include \ --with-lzo-1ib=/usr/1ocal/lib Если этот сценарий не может найти LZO-библиотеки и заголовочные файлы, то он выведет предупреждение, подобное этому: LZO library and headers not found. LZO library available from http://www.oberhumer.com/opensource/lzo/ configure: error: Or try ./configure --disable-lzo

230


Главная особенность этого файла заключается в том, что в нем используются параметры remote и tis-client. Также переставлены аргументы в параметре ifconfig, и в файле используются открытый и секретный ключи узла kryten. Для включения компрессии добавьте в оба файла настройки параметр comp-lzo. И наконец, создайте сценарии openvpn.up и openvpn.down на обоих концах канала. Эти сценарии устанавливают и сбрасывают действительные маршруты и прочие сетевые атрибуты. Сценарий openvpn.up выполняется при установке VPN-соединения. На узле kryten он выглядит так: #!/bin/sh /sbin/route add -net 10.0.0.0- gw $5 netmask 255.255.255.0 Он устанавливает маршрут, указывая операционной системе, что весь трафик, предназначенный для сети 10/24, необходимо отправлять на удаленную сторону нашего VPN-соединения. Отсюда он будет маршрутизироваться на интерфейс узла zul, которому назначен адрес из диапазона 10...24. $5 в этом сценарии будет замещен IP-адресом, используемым удаленной стороной канала. Помимо добавления маршрута, в этом сценарии можно настроить nameservers (серверы имен) для сети, помещаемой в канал. Если не требуется ничего необычного, сценарий openvpn.down на kryten является пустым, поскольку маршрут автоматически сбрасывается ядром при завершении соединения. Для zul не надо устанавливать дополнительные маршруты, поскольку уже имеется маршрут в сеть, в которую включен канал kryten. Помимо этого, поскольку tunO на zul является элементом линии «точка — точка» между самим узлом и kryten, нет необходимости добавлять маршрут для передачи трафика на kryten: маршрут узла kryten будет создан на основании связи «точка — точка». В сценарии openvpn.up на узле zul должен присутствовать следующий элемент: #!/bin/sh arp -s $5 00:00:dl:lf:3f:fl permanent pub Это заставит zul отвечать на ARP-запросы с kryten, поскольку иначе ARP-трафик не сможет достичь kryten. Такой тип настройки известен как «ARP-прокси». В данном примере на zul установлена ОС OpenBSD. При использовании ОС Linux просто удалите в ARP-команде ключевое слово permanent. Опять же, $5 будет заменен IP-адресом, используемым на удаленной стороне соединения, которой является kryten. Сценарий openvpn.down на zul просто удаляет элемент ARP-таблицы: #!/bin/sh arp -d kryten К сожалению, поскольку сценарий запускается с использованием параметра down файла настройки, не передающего аргумент, сообщающий, с каким IP-адресом


231

необходимо иметь дело, приходится явно указывать IP-адрес или имя узла, удаляемого из ARP-таблицы. Сейчас надо лишь позаботиться о межсетевом экране. Необходимо разрешить трафик, поступающий с устройства tunO, а также с 5000-го UDP-порта. Теперь вы готовы запустить openvpn на обеих сторонах с помощью следующей команды: # openvpn --config /etc/openvpn/openvpn.conf --daemon Настройка OpenVPN под Windows еще проще. Просто запустите программу установки, и все, что необходимо, будет настроено автоматически. Будут установлены OpenSSL, ТШЧДАР-драйвер и сама OpenVPN. Расширение .ovpn будет связано с OpenVPN. Просто поместите настроечную информацию в файл .ovpn, дважды щелкните на нем и можете приступать к работе. Все дополнительные параметры представлены на web-сайте OpenVPN.

Канал РРР Для создания безопасной VPN используйте РРР и SSH.

При создании VPN или канального соединения приходится выбирать из очень большого количества параметров. Может быть, вы и не знаете, но все программное обеспечение, необходимое для создания VPN, а именно РРР-1 и SSH-демоны, вероятно, уже установлено на Unix-машине. Наверно, вы уже использовали РРР для подключения к Интернету через коммутируемое соединение, поэтому вас удивляет: как тот же РРР может работать через SSH? Да, когда РРР использовался совместно с модемом, он общался с ним через то, что операционная система представляла как TTY-интерфейс, являющийся обычным оконечным устройством. РРР-демон на вашей стороне мог посылать вывод на TTY, который операционная система могла отправлять модему и по телефонной сети удаленной стороне, где те же действия выполнялись в обратном порядке. Терминалы, используемые для запуска команд оболочки (например, console, xterm), используют псевдоТТУ-интерфейсы, работающие аналогично TTY. Из-за этого РРР-демоны также могут работать через псевдоТТУ. Поэтому последовательные TTY могут быть заменены псевдоТТУ, но по-прежнему требуется способ связи локального псевдоТТУ с удаленным. Вот здесь и понадобится SSH. Создать действительное РРР-соединение можно всего лишь одной командой. Например, если на локальной стороне вы хотите использовать IP 10.1.1.20, а на удаленной — 10.1.1.1, то можно запустить следующую команду: # /usr/sbin/pppd updetach noauth silent nodeflate \ pty "/usr/bin/ssh root@colossus /usr/sbin/pppd nodetach notty noauth" \ Сокращение от «point-to-point protocol» — протокол передачи от точки к точке.


233

отдельного пользователя для регистрации на удаленной машине и запуска pppd. Однако pppd должен запускаться с полномочиями root, поэтому придется использовать sudo (трюк № 6). К тому же можно разрешить встроенное сжатие SSH, добавив ключ -с в команду ssh. В некоторых случаях SSH-сжатие может значительно повысить скорость связи. Для закрытия канала просто уничтожьте порожденный pppd процесс ssh. Хотя сочетание РРР и SSH может оказаться не столь стабильным и полноценным, как настоящая VPN-реализация, и даже закончиться неудачей, оно может помочь создать настоящую зашифрованную сеть без установки дополнительного программного обеспечения.

СМОТРИ ТАКЖЕ Раздел «Creating a VPN with РРР and SSH» в книге «Virtual Private Networks» (2-е издание) — авторы Charlie Scott, Paul Wolfe и Mike Erwin (издательство O'Reilly).

Г Л А В А

Обнаружение сетевого вторжения Трюки № 82-9S Одними из типов средств, выдвинувшихся в последние годы на передний план, являются системы обнаружения сетевого вторжения (network intrusion detection systems, NIDS). Эти системы размещаются в сети и наблюдают за трафиком до тех пор, пока не обнаружат подозрительное поведение, после чего проявляются и сообщают об этом. NIDS являются отличным средством для совместной работы с журналами (протоколами), поскольку зачастую могут заметить атаку до того, как она достигнет предполагаемой цели и отразится в протоколах. В настоящее время существует два основных типа NIDS. К первому типу относятся системы, способные обнаруживать вторжение по наличию в трафике определенных байтовых штампов, характерных для известных атак. NIDS, работающие по этому принципу, известны как системы обнаружения вторжения на основе подписи. Вторым типом являются системы статистического мониторинга. Системы этого тина наблюдают за трафиком, но вместо поиска определенного штампа, или «подписи», они накапливают статистическую хронолргию передаваемых в сети пакетов и извещают о появлении пакетов, «выпадающих» из обобщенного шаблона. NIDS, использующие этот метод, называются системами обнаружения вторжения на основе аномалий. В этой главе мы рассмотрим, как настраивается Snort — система обнаружения по «подписи». Также мы изучим, как настроить совместную работу Snort и SPADE, которая добавляет в Snort возможности определения аномалий. Здесь же будут продемонстрированы и другие приложения, помогающие наблюдать за уже установленными NIE)S и управлять ими. В конце главы вы прочтете, как настроить систему, которая с точки зрения злоумышленника выглядит уязвимой, но на самом деле спокойно ожидает и наблюдает за тем, что он пытается сделать. Такие системы называются приманкой (honeypots). Несколько последних трюков покажут, как наблюдать за незваным гостем, одураченным и пойманным ею.

Обнаружениевторжения спомощьюSnort Используйте самую мощную (и бесплатную) NIDS.

Просмотр протоколов может далеко увести вас от обнаружения вторжения. А если протоколы сгенерированы скомпрометированной службой, то добро пожаловать в самый ужасный кошмар системного администратора: протоколам верить нельзя.

Трюк № 82. Обнаружение вторжения с помощью Snort

235

Вот где требуется NIDS! Системы обнаружения предупредят вас о вторжении в момент осуществления самой попытки. Неоспоримым лидером среди систем обнаружения с открытым исходным кодом является Snort (http://www.snort.org). Столь мощной Snort делает возможность расширения с помощью надстроек и препроцессоров. Они позволяют расширять Snort в любом направлении. Следовательно, вы больше ни от кого не зависите в плане определения правил, предотвращающих новые взломы. Имея базовое представление о TCP/IP, вы можете быстро и легко написать собственные правила. Это, пожалуй, самая важная особенность Snort, поскольку новые атаки изобретаются постоянно. Кроме того, Snort имеет очень удобный механизм отчетов, позволяющий отправлять сигналы тревоги в syslogd, в обычные файлы и даже в базы данных. Для компиляции и установки Snort версии «plain-vanilla» загрузите из Сети последнюю версию и распакуйте ее. Запустите сценарий настройки, а затем команду make: $ ./configure && make После этого получите полномочия root и выполните # make install Обратите внимание на то, что все заголовочные файлы и библиотеки для libpcap (http://www.tcpdump.org) должны быть установлены до компоновки Snort, иначе компиляция завершится неудачей. Кроме того, для указания компилятору местонахождения библиотек и заголовочных файлов необходимо использовать параметры --with-libpcap-includes и --with-libpcap-libraries. Однако их можно применять только в случае нестандартной установки библиотек (не в подкаталоги каталога /usr или /usr/local). Например, если libpcap установлена в /opt, то необходимо использовать следующую команду: $ ./configure --with-1ibpcap-includes=/opt/include\ --wi th-1i bpcap-1i bra ri es=/opt/1i b Snort имеет возможность отвечать узлу, который запустил (активизировал) одно из правил. Эта возможность называется гибким откликом. Чтобы включить ее, необходимо использовать параметр --enable-flexresp, для работы которого требуется библиотека инжекции пакетов (packet injection library) libnet (http:// www.packetfactory.net/projects/libnet/). Убедившись в том, что этот пакет установлен, для указания его местоположения воспользуйтесь ключами --with-1 ibnet-includes и --with-libnet-libraries. Если необходимо добавить возможность отправки предупреждений в БД, необходимо воспользоваться ключами --with-mysql, --with-postgresql либо --with-oracle. Для просмотра полного списка параметров настройки введите ./configure --help. После установки проверьте работу Snort в режиме анализа (sniffer mode). Вы сразу же увидите следующий трафик: # ./snort -evi ethO Running in packet dump mode

Трюк № 82. Обнаружение вторжения с помощью Snort 237 HOME_NET can also be automatically set to the network address of a particular interface by setting the variable to $ethO_ADDRESS. In this particular case. $ethO_ADDRESS sets it to the network address of ethO. The EXTERNAL_NET variable allows you to explicitly specify IP addresses and networks that are not a part of HOME_NET. Unless a subset of HOME_NET is considered hostile, you can just keep the default value, which is any. Остальные переменные, относящиеся к IP-адресам или сетевым диапазонам (DNS_SERVERS, SMTP_SERVERS, HTTP_SERVERS, SQLJERVERS и TELNET_SERVERS), по умолчанию имеют значение $HOME_NET. Эти переменные используются в наборе правил, который имеется в дистрибутиве Snort, и могут применяться для «тонкой» настройки поведения правил. Например, правила, относящиеся к SMTP-атакам, используют переменную SMTP_SERVERS для фильтрации трафика, который фактически не относится к этому правилу. Подстройка этих переменных не только приводит к более точной генерации сигналов тревоги и уменьшению ложных срабатываний, но и повышает производительность. Еще одной важной переменной является RULE_PATH, которая используется в конфигурационном файле для добавления наборов правил. Пример конфигурационного файла устанавливает для нее значение ../, но для совместимости с предыдущими примерами она должна иметь значение ./rules, поскольку snort.conf и каталог rules находятся в каталоге /usr/local/etc/snort. Следующий раздел конфигурационного файла позволяет настраивать встроенные препроцессоры Snort. Они способны делать все: от сборки (восстановления) фрагментированных пакетов до декодирования HTTP-трафика с целью обнаружения сканирования портов. В большинстве случаев достаточно настройки по умолчанию. Однако если необходимо изменить любую из настроек, то все параметры препроцессоров можно найти в описании конфигурационного файла. Если при компиляции была задана поддержка баз данных, то необходимо разрешить работу надстройки вывода в БД (database output), позволяющей Snort сохранять любые генерируемые сигналы в БД. Включается она в конфигурационном файле подобной строкой: output database: log. mysql, user=snort password=snortpass dbname=SNORT \ host=dbserver output database: alert mysql, user=snort password=snortpass dbname=SNORT \ host=dbserver Первая строка настраивает в Snort отправку в БД сведений, генерируемых правилами, определяющими действия протоколирования (log action). Вторая строка отправляет в БД сведения, генерируемые правилами, определяющими действия по тревоге (alert action). Дополнительные сведения о различиях между действиями протоколирования и действиями по тревоге приведены в трюке № 86. Если вы собираетесь использовать Snort совместно с БД, то необходимо создать новую БД и, может быть, новую учетную запись пользователя этой БД. В каталоге

238


contrib исходного кода Snort имеются сценарии создания баз данных поддерживаемых типов: create_mssql, createjnysql, create_oracle.sql и create_postgresql. При использовании MySQL БД с необходимыми таблицами создается следующей командой: # mysql SNORT -p < ./contrib/createjnysql Остальная часть конфигурационного файла в основном посвящена правилам «подписей», используемых Snort при наблюдении за трафиком. Эти правила разделены на категории и хранятся в отдельных файлах, а активизируются с помощью директивы include. Для проверки (или в сети с ненапряженным трафиком) вполне достаточно настроек по умолчанию, но желательно просмотреть эти правила и решить, какие категории действительно вам нужны, а какие — нет. Теперь, когда вся сложная работа по настройке выполнена, надо проверить файл snort.conf подобной командой: # snort -T -с /usr/local/etc/snort/snort.conf В результате ее выполнения будет выведен отчет обо всех обнаруженных ошибках. При отсутствии ошибок запустите Snort командой # snort -Dd -z est -c /usr/local/etc/snort/snort.conf Два флага (-d и -с) уже использовались ранее (для декодирования пакетов и использования указанного конфигурационного файла соответственно), а два других — новые. Флаг -D заставляет Snort вывести сообщение о запуске, а затем перейти в фоновый режим. Аргумент -z est заставляет надстройку препроцессора streams игнорировать ТСР-пакеты, не относящиеся к установленным сеансам, что уменьшает чувствительность системы к спуф-атакам и, конечно же, к DoS-атакам. Полезными являются также параметры -и й'-g, позволяющие Snort сбрасывать свои привилегии и запускаться указанным пользователем или группой. Это особенно полезно при совместном использовании с параметром -t, который с помощью вызова chroot() поместит Snort в указанный вами каталог. Теперь можно приступать к просмотру протоколов, появляющихся в /var/log/snort. СМОТРИ ТАКЖЕ Глава 11 «Simple Intrusion Detection Techniques» книги «Building Secure Servers with Linux», написанной Michael D. Bauer (издательство O'Reilly).

Отслеживайте сигналы тревоги Используйте ACID для работы с журналами (протоколами) систем обнаружения вторжения.

После настройки Snort на протоколирование сведений в БД (см. трюк № 82) вы можете прийти к выводу, что вам сложно справиться с обработкой всех генерируемых

Трюк № 83. Отслеживайте сигналы тревоги

239

данных. Очень загруженные и привлекающие внимание сайты могут генерировать огромное количество предупреждений, которые зачастую необходимо отбрасывать. Одним из способов облегчения этой работы является установка ACID (http://acidlab.sourceforge.net). ACID (сокращение от Analysis Console for Intrusion Databases (консоль анализа БД вторжений)) — это web-интейфейс для БД, содержащих сигналы тревоги, поступившие от систем обнаружения вторжений. Он имеет возможность выполнять поиск сигналов по определенному критерию (по подписи, времени обнаружения, по адресу и порту, а также по контексту «полезной нагрузки» пакета или по значениям флагов). ACID может выводить пакеты, которые привели к генерации сигнала тревоги, а также декодировать в них сведения 3-го и 4-го уровня. ACID также обладает функциями управления сигналами тревоги, позволяющими группировать сигналы по направленности, удалять изученные или ложные сигналы, отправлять сигналы по электронной почте или архивировать их в другой БД. ACID также обеспечивает различную статистику сигналов тревоги: хронологическую, по датчику, который их сгенерировал, по подписи. Кроме того, предоставляется статистика пакетов (протокол, адрес или порт). Для установки ACID прежде всего понадобится web-сервер и работающая инсталляция РНР (например, Apache и mod_php), а также инсталляция Snort, настроенная на подключение к БД (например, MySQL). Нужны будут также парочка PHP-библиотек: для абстракций БД — ADODB (http://php.weblogs.com/adodb), а для создания графики — либо PHPIot (http://www.phplot.com), либо JPGraph (http:// www.aditus.nu/jpgraph). После загрузки из Сети этих пакетов распакуйте их в каталог, который будет использоваться для выполнения PHP-контекста на web-сервере. Перейдите в каталог, который был создан при распаковке ACID (то есть в ./acid), и отредактируйте файл acid_conf.php. В нем необходимо указать, где найти ADODB и JPGraph, а также как подключиться к БД Snort: $Dblib_path = \ ./adodb"; SDbtype = "mysql": $alert_dbname - "SNORT": $alert_host = "local host": $alert_port = ""; $alert_user="snort": $alert_password = "snortpass"; При этом ACID будет вести поиск кода ADODB в каталоге adodb, находящемся на одном уровне с каталогом acid. Помимо этого, ACID будет подключаться к БД MySQL (с именем SNORT), размещенной на локальной машине, что не требует указания номера порта. Если необходимо подключиться к БД, расположенной в другой системе, требуется указать порт 3389, который для MySQL является портом по умолчанию. Дополнительно можно настроить архив БД для ACID с помощью переменных, аналогичных переменным, использовавшимся для настройки БД сигналов тревоги:

240


Рис. 7 . 1 . Страница настройки ACID

Перед использованием ACID необходимо создать несколько таблиц. Щелкните на кнопке Create ACID AG. После этого вы увидите сообщение о создании таблиц. Для таблицы событий лучше создать индексы, если это не было сделано во время настройки. Индексы значительно повышают скорость выполнения запросов в больших таблицах, чуть-чуть увеличивая использование дискового пространства. Щелкните на ссылке Ноте для перехода к основной странице ACID (рис. 7.2). Интерфейс ACID не требует никаких объяснений. Основная таблица имеет достаточно ссылок, позволяющих просматривать БД в различных представлениях: например, с выводом списка IP-адресов источника и пункта назначения, связанных с сигналом тревоги, а также номера портов.


241

Рис. 7.2. Основная страница ACID

Ш

Наблюдение в реальном режиме времени Используйте расширенный GUI Sguil для регулярного наблюдения и анализа IDS-событий.

Решающим моментом анализа IDS-событий является возможность временного сопоставления (корреляции) всех данных аудита из различных источников для определения точного источника опасности и принятия мер по ее предотвращению. Сюда может относиться все: от простого поиска в БД схожих сигналов тревоги до просмотра обмена пакетов в TCP-потоке. Здесь вам поможет Sguil (http://sguil.sourceforge.net) (сокращение от Snort GUI for Lamerz). Удивительно, но Sguil произносится как «эс-гуил» (созвучно «эс-кью-эл»). Sguil — это графическая консоль анализа, написанная в Тс1Дк. Она объединяет в себе мощь таких средств, как Ethereal (http://www.ethereal.com), TcpFlow (http:// www.circlemud.org/~jelson/software/tcpflow/) и препроцессоры сканирования портов 9 Зак. 1103

242


и декодирования TCP-потоков. Это позволяет свести воедино все данные из этих источников. Sguil использует модель «клиент — сервер» и состоит из трех частей: надстройки для Barnyard (op_guil), сервера (sguild) и клиента (sguil.tk). Агенты устанавливаются на каждом датчике вашей NDIS, используемом для возврата сведений на sguil-сервер. Сервер занимается сбором информации и определением временного соотношения всех сведений от всех агентов-датчиков, а также обработкой информации и идентификацией запросов от GUI-клиентов. Для начала необходимо загрузить с сайта проекта дистрибутив Sguil и распаковать его. Будет создан каталог, имя которого состоит из наименования и версии пакета (например, sguil-О.З.О). Первым шагом по настройке Sguil является создание БД MySQL для хранения информации. Кроме того, необходимо создать учетную запись пользователя, с помощью которой можно обращаться к этой БД: $ mysql -u root -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 546 to server version: 3.23.55 Type 'help;1 or '\h' for help. Type '\c' to clear the buffer. mysql> CREATE DATABASE SGUIL; Query OK, 1 row affected (0.00 sec) mysql> GRANT SELECT.INSERT,UPDATE,DELETE ON SGUIL.* \ TO sguil IDENTIFIED BY 'sguilpass1; Query OK, 0 rows affected (0.06 sec) mysql> FLUSH PRIVILEGES; Query OK, 0 rows affected (0.06 sec) mysql> Теперь необходимо создать таблицы. Для этого найдите файл create_sguildb.sql. Он должен располагаться в подкаталоге server/sql_scripts каталога, куда был распакован дистрибутив Sguil. Этот файл перенаправляется на вход команды $ mysql -u root -p SGUIL < create_sguildb.sql Для работы потребуется несколько Tcl-пакетов. Первый из них — Tclx (http:// tclx.sourceforge.net) — содержит расширения библиотек для Tel. Второй — mysqltcl (http://www.xdobry.de/mysqltcl/). Оба пакета должны быть установлены с помощью стандартной процедуры ./configure && make install. Правильность их установки можно проверить с помощью следующих команд: $ tcl tcl>package require Tclx 8.3 tcl>package require mysqltcl 2.40 tcl>

244


Рис. 7.3. Диалоговое окно регистрации Sguil

Введите сведения, указанные при создании пользователя, и щелкните на ОК. После этого откроется окно, представленное на рис. 7.4.

Рис. 7.4. Диалоговое окно без датчиков


245

Поскольку датчиков наблюдения еще нет, щелкните на кнопке Exit (Выход). Необходимые обновления можно найти в подкаталоге sensor/snort_mods/2_0/ дистрибутива Sguil. Теперь перейдите в каталог, содержащий исходный код Snort, перейдите в подкаталог src/preprocessors и выполните обновление с помощью spp_portscan.c и spp_stream4.c:

После этого откомпилируйте Snort как обычно (см. трюк № 82). Далее включите препроцессоры portscan и stream4 в файл snort.conf:

Первая строка включает препроцессор portscan и заставляет его запускать сигнал тревоги «сканирование портов», если будет обнаружена попытка одного узла подключиться к четырем различным портам в течение трехсекундного интервала. Свой протокол препроцессор сканирования портов хранит в /var/log/snort/portscans. Последнее поле в строке — наименование датчика. Вторая строка активизирует препроцессор stream4, включая в нем обнаружение скрытого сканирования портов, и указывает не генерировать сигнал тревоги при взаимном наложении ТСР-дейтаграмм. Здесь также указывается место хранения протокола этого препроцессора. Кроме того, в Snort необходимо настроить единый (унифицированный) выходной формат, поскольку для обработки протоколов сигналов тревоги и протоколов событий необходимо использовать Barnyard:

Далее создайте элемент в crontab для входящего в комплект Sguil сценария log_ packets.sh. Он (сценарий) запускает единственный экземпляр Snort для протоколирования пакетов. Эта строчка в crontab будет каждый час повторно запускать экземпляр Snort: 00 0-23/1 * * * /usr/local/bin/log_packets.sh restart Придется изменить переменные в начале сценария в соответствии с вашими потребностями. Эти переменные указывают, где найти двоичный файл Snort (SNORT_ PATH), где размещать протокол пакетов (LOG_DIR), какой сетевой интерфейс анализировать (INTERFACE), а также задают параметры командной строки (OPTIONS). Обратите особое внимание на переменную OPTIONS. В ней можно указать, от имени

246


каких пользователей или групп будет запускаться Snort; по умолчанию приложение работать не будет, пока не будут созданы пользователь Sguil и группа. Кроме того, установив переменную FILTER в значение BPF, можно указать, какой трафик не протоколируется (например, tcpdump-style). После этого необходимо скомпилировать и установить Barnyard (трюк № 92), но запустить лишь этап конфигурирования. Выполните обновление с помощью надстройки вывода op_sguil, поставляемой вместе с Sguil. Для этого скопируйте sensor/ bamyard_mods/op_sguil.* в каталог output-plugins в дереве исходного кода Barnyard: $ cd ~/barnyard-0Л.О/src/output-plugins $ ср -/sguil-0.3.0/sensor/barnyard_mods/op_sguiI.* . Теперь измените Makefile этого каталога, добавив op_sguil .с и op_sguil .h в переменную 1 ibop_a_SOURCES и op_sguil'.o в переменную libop_a_OBJECTS. Перейдем к корректировке файла op_plugbase.c, в котором необходимо найти строку #include "op_acid_db.h" Ниже нее добавьте еще одну строку, так чтобы получилось: #inc1ude "op_acid_db.h" #include "op_sguil.h" Теперь найдите строку AcidDbOpInit(

);

и добавьте под ней еще одну строку, чтобы они выглядели так: AcidDbOpIniK SguilOpInitC

): );

Теперь запустите make из текущего каталога; после завершения перейдите в основной каталог исходного дистрибутива и выполните команду make i n s t a l l . Для настройки Barnyard на использование надстройки вывода Sguil добавьте в barnyard.conf подобную строчку: output sguil: mysql. sensor_id 0. database SGUIL, server localhost, user sguil, sguilpass, sguildjiost localhost, sguild_port 7736 Теперь можно запустить Barnyard как обычно. После этого необходимо настроить сценарий агента датчика (sensor_agent.tcl), который можно найти в каталоге sensor дистрибутива. Перед запуском этого сценария необходимо подстроить несколько переменных под конкретные условия: set SERVERJOST localhost set SERVER_PORT 7736 set HOSTNAME gw-extO set PORTSCAN_DIR /var/log/snort/portscans set SSN_DIR /var/log/snort/ssnjogs set WATCHJHR /var/log/snort


247

Переменные PORTSCAN_DIR и SSN_DIR должны указывать на каталоги, в которые помещаются протоколы препроцессоров portscan и stream4. Теперь необходимо лишь настроить xscriptd на той системе, на которой установлен sguild. Этот сценарий отвечает за сбор пакетов, поступающих от каждого датчика, извлечение запрашиваемой информации, а затем отправку ее в GUI клиента. Перед его запуском необходимо также скорректировать некоторые переменные:

set LOCALSENSOR 1 set LOCAL_LOG_DIR /var/log/snort/archive set REMOTE_LOG_DIR /var/log/snort/dailylogs При запуске xscriptd на том же узле, на котором находится датчик, установите LOCALSENSOR в 1, в противном случае — в 0. Переменная LOCAL_LOG_DIR определяет, где xscriptd будет архивировать данные, полученные после опроса датчика, REMOTE_ LOG_DIR определяет, где на удаленном узле xscriptd будет искать пакеты. При установке xscriptd на узел, на котором нет агента датчика, необходимо настроить ключи SSH-клиента (см. трюк № 73), для того чтобы он мог получать данные от датчиков. Кроме того, на узле, на котором располагается xscriptd, должны быть установлены tcpflow (http://www.circlemud.org/~jelson/software/tcpflow/) и pOf (http:// www.stearns.org/pOf/). После того как все настроено, запустите sguild и xscriptd с помощью подобных команд: # sguild -0 /usr/l.ib/tls 1.4/1 ibt 1 s 1.4.so # xscriptd -0 /usr/lib/tlsl.4/libtlsl.4.so Если SSL не используется, то -0 /usr/1 ib/tlsl.4/1 ibtlsi.4.so в представленных командах можно опустить. В противном случае аргумент -0 должен точно указывать местонахождение библиотеки libtls в системе. Можно отметить, что подготовка Sguil к запуску является непростой задачей, но результат того стоит. После того как все будет запущено, вы получите прекрасную возможность четко представлять, что происходит в сети. Sguil одновременно выводит данные из нескольких источников, давая полное представление о том, что невозможно увидеть лишь просматривая протоколы NIDS.

Управление датчиками Используйте web-интерфейс SnortCenter для управления датчиками NIDS. Управление IDS-датчиками и отслеживание всех генерируемых ими сигналов тревоги может стать обременительной задачей, а при наличии нескольких датчиков — вообще трудно выполнимой. Одним из способов объединить все задачи управления IDS в одном приложении является SnortCenter (http://users.pandora.be/larc/) — система управления для Snort. SnortCenter состоит из консоли, основанной на web-интерфейсе, и агентов датчиков, запускаемых на каждой машине, входящей в инфраструктуру NIDS. Это позволяет объединить все задачи наблюдения и управления в одной программе,

248


которая помогает быстрее выполнять работу. SnortCenter имеет собственную схему идентификации и поддерживает зашифрованную связь между консолью и отдельными агентами датчиков. Это позволяет обновлять Snort-правила на множестве датчиков или создавать собственные правила и безопасно доставлять их датчикам. SnortCenter также позволяет удаленно запускать или останавливать датчики. Для наблюдения за сигналами тревоги SnortCenter может интегрироваться с ACID (трюк № 83). Сначала необходимо установить консоль управления SnortCenter на web-сервер, имеющий как поддержку РНР, так и доступ к серверу баз данных MySQL, где SnortCenter будет хранить БД конфигурации. Для установки консоли управления загрузите дистрибутив со страницы http://users.pandora.be/larc/download/ и распакуйте его. При этом будет создан каталог www (не распаковывайте в уже существующий одноименный каталог!), в который будут помещены РНР-сценарии SnortCenter, графика и SQL-схемы. После этого скопируйте содержимое каталога www в подходящее место в корневом каталоге документов web-сервера, например: # tar xfz snortcenter-vl.O-RCl.tar.gz # ср -R www /var/www/htdocs/snortcenter

Для обеспечения связи SnortCenter с БД необходимо также установить ADODB (http://php.weblogs.com/adodb). Это PHP-пакет, обеспечивающий абстрактное функционирование БД. После загрузки из Сети ADODB-кода распакуйте его в корневой каталог документов (например, в /var/www/htdocs). Помимо этого необходимо установить curl (http://curl.haxx.se). Загрузите дистрибутив, распакуйте его и запустите ./configure && make install. В качестве альтернативного варианта он может поставляться в составе вашей операционной системы (версия Red Hat ОС Linux имеет RPM curl, а в BSD-системах он включен в дерево портов). После того как все выполнено, необходимо уточнить config.php приложения SnortCenter (то есть файл /var/www/htdocs/snortcenter/config.php), указав в перечисленных далее переменных значения, соответствующие вашим условиям: $DBlib_path = и../adodb/": SDBtype = "mysql"; $DB_dbname = "SNORTCENTER"; $DB_host = "localhost"; $DB_port = "•'; $DB_user = "snortcenter": $DB_password = "snortcenterpass"; Shi dden_key_num =1823701983719312; Такая настройка укажет SnortCenter, что ADODB-код надо искать в каталоге adodb, расположенном в том же уровне, что и SnortCenter. Кроме того, SnortCenter должен подключаться к располагающейся на локальной машине БД MySQL с наименованием SNORTCENTER, используя имя snortcenter и пароль snortcenterpass. Поскольку подключение к MySQL-серверу происходит на локальной машине, нет необходимости указывать номер порта. При подключении к БД, установленной на другой системе, необходимо указать 3389-й порт, являющийся для MySQL


249

Рис. 7.5. Страница регистрации SnortCenter

Введите имя и пароль по умолчанию и щелкните на кнопке Login. После чего откроется страница, представленная на рис. 7.6.

250


Рис. 7.6. Основная начальная страница SnortCenter

Сейчас точно можно сказать о том, что консоль управления установлена верно, и теперь можно устанавливать агентов. Но перед этим необходимо изменить пароль для учетной записи администратора. Для этого щелкните на кнопке Admin и выберите пункт меню User Administration. Страница примет вид, представленный на рис. 7.7.

Рис. 7.7. Страница со списком пользователей SnortCenter

Щелчок на значке, расположенном слева от имени пользователя, откроет страницу, подобную представленной на рис. 7.8. На ней можно изменить данные учетной записи, включая пароль. Теперь можно перейти к настройке агента датчика (вот только сейчас!). Агенты датчиков SnortCenter написаны на языке Perl и для связи с консолью управления по зашифрованному каналу требуют наличия модуля Net::SSLeay. Если установлен модуль CPAN (относящийся к Perl), то установка Net::SSLeay выполняется командой

# perl -MCPAN -e "install Net::SSLeay" Для установки программного кода агента его сначала необходимо распаковать. При распаковке будет создан каталог sensor, в который будет помещен весь код агента. Скопируйте этот каталог в надежное постоянное место, например:

# tar xfz /tmp/snortcenter-agent-vl.O-RCl.tar.gz # ср -R sensor /usr/local/snortcenter

251


T h e

S e n s o r

U n l e s s

d

e

f

a

u

l

C

o

n

f

i

g

t

s f

u s e s

A g e n t

y o u

w a n t

t o

p

l

s

a

c

e

p

e

a

r

a

t

e

d

t h e m

i

i n

r

e

a

c

o

t

o

r

i

t

h

e

r

o

r

t

c

e

s

f

d

i

r

n

t

e

o

r

e

c

t

r

/

c

c

o

o

r

n

y

f

i

,

g

u

r

y o u

a

t

i

o

c a n

n

j

f

i

l

u

s

t

e

s

a

a n d

c

c

e

p

l

t

o

g

t

h

f

i

l

e

s

.

e

. i

l

e

d

i

r

e

c

t

o

r

y

[

/

u

s

r

/

l

o

c

a

l

/

s

n

e

o

n

f

]

:

Этот сценарий уточнит у вас некоторую информацию: каталог конфигурационного файла агента и каталог протокола, полный путь к библиотеке Perl (например, /usr/bin/perl), а также расположение двоичных файлов и правил Snort. Кроме того, будут уточнены операционная система, порт и IP-адрес, который должен «прослушивать» агент (по умолчанию 2525-й TCP-порт), а также IP-адреса, по которым можно подключаться к агенту. После получения всей информации сценарий запустит агента на указанном в конфигурационном файле порте. Теперь можно проверить работу агента, обратившись к нему с помощью

252


web-браузера (используйте протокол https, а не http). После ввода регистрационной информации, содержащейся в сценарии настройки, вы должны увидеть страницу, подобную представленной на рис. 7.9.

Рис, 7.10. Добавление агента датчика

Введите те же сведения, которые были указаны при выполнении сценария настройки, и щелкните на кнопке Save. Базовую конфигурацию датчика можно «протолкнуть» в датчик, выбрав Admin • Import/Update Rules • Update from Internet (Администрирование • Импорт/Обновление правил • Обновить через интернет). После этого вернитесь к списку датчиков, щелкнув Sensor Consoles • View Sensors • Push hyperlink for the sensor (Управление сенсорами • Показать сенсоры • Передать сенсору гиперссылку). Для запуска Snort в отношении конкретного датчика щелкните на ссылке Start (рис. 7.11).


253

Теперь можно настроить датчик с помощью меню Sensor Config и Resources. После того как создана удовлетворяющая вас конфигурация, она может «проталкиваться» необходимым датчикам с помощью пункта Push.

Рис. 7 . 1 1 . Список датчиков SnortCenter после запуска датчика

Одной из ярких особенностей Snort является собственный процессор правил. Процессор правил имеет расширенный язык, позволяющий писать собственные правила, учитывающие особенности конкретной сети. Правило Snort можно разделить на две части: заголовок и параметры. Заголовок содержит выполняемое действие, протокол, к которому применяется правило, а также адреса и порты исходного пункта и пункта назначения. Параметры правила позволяют создавать связанное с правилом пояснительное сообщение, а также проверять различные атрибуты пакетов с использованием довольно большой библиотеки надстроек Snort. Вот общая форма правила: action proto src_ip src_port direction dst_ip dst_port (options) При поступлении пакета его IP-адреса и порты отправителя и получателя сравниваются со значениями, указанными в правилах. Если они совпадают, то с пакетом сравниваются параметры. Если в результате этих сравнений обнаруживается совпадение, то предпринимается указанное действие. Snort предлагает несколько встроенных действий, которые можно использовать в правилах. Для упрощения протоколирования совпадающих пакетов используется действие log. Действие alert, помимо протоколирования пакета, генерирует сигнал тревоги указанным в конфигурационном файле или в командной строке способом. Очень приятная возможность Snort заключается в том, что можно иметь

254


довольно общие правила, а затем создать из них исключение, написав еще одно правило, использующее действие pass. Это особенно удобно при использовании имеющихся в Snort правил, но часто приводит к получению неверного результата. В таких случаях риска для системы безопасности нет, просто нужно написать для них pass-правило. Два последних встроенных действия правил, activate и dynamic, используются вместе для динамического изменения набора правил Snort в ходе выполнения. Правила, использующие действие dynamic, подобны log-правилам, за исключением того, что будут приниматься во внимание только после разрешения правилом activate. Snort заставляет использовать параметры правил activates и activated_by, для того чтобы знать, какие dynamic-правила разрешить, после того как сработает activate-правило. Кроме того, dynamic-правила требуют использования параметра count для ограничения количества записываемых правилом пакетов. Например, если вы хотите начать запись пакетов после того, как будет замечено «ненормальное» использование SSH-демона на машине 192.168.1.21, необходимо использовать подобную пару правил: activate tcp any any -> 192.168.1.21 22 (content:"Vbin/sh"; activates:!; \ msg:"Possible SSH buffer overflow"; ) dynamic tcp any any -> 192.168.1.21 22 (activated_by:l; count:100;) Эти два правила не обеспечивают полную «защиту от дурака», но если кто-либо запустит код оболочки в отношении SSH-демона, то, скорее всего, он отправит строку /bin/sh в открытом виде, чтобы породить подпроцесс оболочки на атакуемой системе. Кроме того, поскольку SSH зашифрован, такая строка не могла быть послана при обычных обстоятельствах. После того как сработает первое правило, оно активизирует второе, которое запишет 100 пакетов, а затем остановится. Это полезно в тех случаях, когда необходимо пресечь попытку взломщика загрузить или установить так называемый root kit (набор суперпользователя) с первых же пакетов, а также если нужно быстрее проанализировать скомпрометированную систему. Кроме того, помимо встроенных действий, имеется возможность определить пользовательские действия правил. Это делается с помощью ключевого слова ruletype: ruletype redalert { type alert output alert_syslog: LOG_AUTH LOG_ALERT output database: log, mysql. user=snort dbname=snort host=localhost

} Это действие указывает, что приложение Snort должно вести себя так же, как при выполнении действия alert, но что сигнал тревоги должен быть послан демону syslog, а пакеты должны протоколироваться в базу данных. При определении действия можно использовать любую из надстроек вывода Snort так же, как при настройке их в качестве основного варианта вывода. Механизм обнаружения Snort поддерживает несколько протоколов. Поле proto используется для указания протокола, к которому относится ваше правило. Допустимыми значениями являются i p, i cmp, tcp и udp.


255

Следующее поле в правиле используется для указания IP-адресов и портов исходного пункта и пункта назначения, а также направления перемещения пакетов. Snort воспринимает один IP-адрес или список адресов. При задании списка адреса разделяются запятыми, а весь список заключается в квадратные скобки: [192.168.1.1,192.168.1.45,10.1.1.24] Пробелов в списке быть не должно! Можно указать диапазон адресов в CIDR-HOтации и даже включить диапазон в список. Кроме того, разрешается использование логического оператора NOT в отношении IP-адреса или диапазона, указывающего исключение из правила. Так же как и в случае с IP-адресами, Snort воспринимает как отдельные порты, так и диапазон портов. При указании диапазона в качестве разделителя используется двоеточие. Например, вот как указываются все порты с 1-го по 1024-й: 1:1024 К номерам портов также можно применять оператор NOT, допускается указание диапазона без верхней или нижней границы. Например, для проверки всех портов выше 1024-го укажите: 1024: Аналогично, все порты до 1024-го можно указать так: :1024 Если IP-адрес и номер порта не критичны, то можно указать any (любой). Поле direction используется для указания того, какой IP-адрес и порт являются пунктом отправления, а какая пара IP-адреса и порта — пунктом назначения. В ранних версиях Snort в качестве значений можно было использовать операторы -> и any any (msg:"Traffic from 192.168.1.35":)

256


В строчном значении должны отсутствовать любые кавычки. Синтаксический анализатор в Snort очень простой PI не поддерживает эти символы. Еще одним полезным параметром является content. Он позволяет находить пакеты по последовательности символов или шестнадцатеричных значений. При поиске строчного значения его необходимо просто поместить в кавычки. При поиске без учета регистра необходимо добавить уточнение nocase; в конце всех параметров. При поиске последовательности шестнадцатеричных чисел их необходимо поместить между символами |. Это правило сработает, если «увидит» число 0x90: alert tcp any any -> any any (msg:"Possible exploit"; content:"|90|";) Это цифровое значение является шестнадцатеричным эквивалентом инструкции NOP, используемой в х8б-архитектуре, и зачастую встречается в коде взлома, поскольку облегчает запись при выполнении атаки переполнения буфера. Параметры offset и depth могут использоваться совместно с параметром content для ограничения нагрузки при выполнении контекстного поиска в разделе данных, они точнее указывают диапазон байтов, в которых будет выполняться поиск. Если необходимо ограничить поиск инструкции NOP в разделе данных пакета между 40-м и 75-м байтом, то предыдущее правило необходимо изменить следующим образом: alert tcp any any -> any any (msg:"Possible exploit": content:"|90|"; offset:40: depth:75;)

\

Можно выполнять поиск пакетов, в которых отсутствует указанная последовательность, установив в начале символ !. Кроме того, большая часть «полезной нагрузки» кода оболочки может быть слишком большой по сравнению с обычным количеством данных, переносимых пакетом в определенную службу. С помощью параметра dsize можно проверить размер данных «полезной нагрузки» в пакете. Этот параметр получает в качестве аргумента число. Помимо этого, с помощью операторов > и < можно указать верхний или нижний предел соответственно, например: alert tcp any any -> any any (msg:"Possible exploit"; content:"|90|"; offset:40; depth:75; dsize: >6000;)

\

В отличие от предыдущего примера, данному правилу будут соответствовать пакеты, у которых (помимо остальных условий) размер данных «полезной нагрузки» превышает 6000 байт. Для проверки TCP-флагов пакетов Snort предоставляет параметр flags. Он полезен для обнаружения сканирования портов, во время которого используются недействительные сочетания флагов. Например, это правило обнаружит сканирование, когда одновременно будут установлены флаги SYN и FIN: alert any any -> any any (flags: SF,12; msg: "Possible SYN FIN scan";)

Трюк № 87. Предотвращение и сдерживание вторжений с помощью Snortjnline 257

Действительными значениями флагов являются S для SYN, F для FIN, R для RST, P для PSH, А для АСК и U для URG. Кроме того, Snort позволяет проверять состояние двух зарезервированных разрядов-флагов, указанных значением 1 или 2. Указав значение 0, можно установить соответствие пакету, вообще не содержащему флагов. Помимо этого, параметр f I ags воспринимает несколько операторов. Перед указываемыми значениями можно добавлять +, * или ! для соответствия одним флагам плюс другим, любым флагам и всем, кроме указанных, соответственно. Прекрасно, что в Snort имеется множество надстроек, которые могут использоваться в правилах в параметре options. Упомянутые здесь параметры являются лишь «затравкой» для изучения всех остальных. Если вам необходимо определить более сложные правила, обратитесь к полной документации Snort, в которой параметры подробно описываются и приводятся примеры их использования. Документацию для Snort можно найти на http://www.snort.org/docs/writing_rules/.

Предотвращение и сдерживание вторжений с помощью Snortjnline Для предотвращения вторжений или для их остановки в случае обнаружения установите на межсетевой экран Snortjnline.

Было бы здорово, если бы NIDS могли не только обнаруживать вторжение, но и предпринимать что-либо для его нейтрализации. Хорошо, если бы они могли остановить проникновение на атакуемый узел, но еще лучше, если бы они блокировали весь сетевой трафик, распространяющий атаку. Это можно сделать с помощью Snortjnline (http://snort-inline.sf.net). Snortjnline — это обновление (patch) для Snort, позволяющее прочитывать данные из очереди Netfilter в ядре Linux, что обеспечивает эффективную интеграцию Snort в этот межсетевой экран. При этом не только обнаруживается вторжение, но и принимается решение: сбросить пакеты или перенаправить их на другой узел (с помощью Libnet). Конечно же, это требует перекомпиляции ядра с поддержкой IP-очереди (IP queue) статически либо в качестве отдельного модуля. Проверить наличие этого модуля можно с помощью команды $ locate ip_queue.o /usr/src/linux-2.4.20-8/net/ipv4/netfilter/ip_queue.o /usr/src/1 i nux-2.4.20-8/net/i pv4/netf i 1 t e r / . i p__queue. о. f 1 ags /lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ip_queue.o

В данном случае последняя строка свидетельствует о наличии модуля. Если модуля нет, необходимо проверить, существует ли файл /proc/net/ip_queue. Если найти модуль не удается, а файл существует, то поддержка IP-очереди скомпилирована в ядро статически. Если и файла нет, то необходимо включить его в ядро и перекомпилировать.

258


Помимо поддержки IP-очереди, для работы Snortjnline требуется также libipq. Это библиотека, которая входит в состав Netfilter и используется приложениями для подключения к очереди Netfilter. Проверка наличия этой библиотеки осуществляется командой $ locate libipq /usr/include/libipq.h /lib/libipq.a Если результат будет отрицательный, значит, libipq не установлена. Для установки необходимо загрузить исходный текст iptables с сайта Netfilter (http:// www.netfilter.org). Порядок компиляции рассматривался в трюке № 41. После компиляции запустите make instal I -dev. Помимо этой библиотеки, необходима также библиотека инжекции пакетов libnet (http://www.packetfactory.net/projects/libnet/). Для установки libnet просто загрузите из Сети исходный дистрибутив, распакуйте его и выполните с правами root команду run ./configure && make install. Теперь, когда все подготовлено, можно скомпилировать Snortjnline. Сначала загрузите и распакуйте дистрибутив, а затем перейдите в созданный при этом каталог и выполните команду $ ./configure --enable-inline && make Также можно указать параметры конфигурирования, которые обычно используются для Snort, поскольку в основе Snortjnline по-прежнему остается Snort. He стоит поднимать тревогу, если компиляция прервется со следующей ошибкой: gcc -DHAVE_CONFIG_H - I . - I . - I . . / . . - I . . / . . -I../../src -I../../src/sfutil -I/usr/include/pcap -I../.,/src/output-plugins -I../../src/detection-plugins -I../../src/preprocessors -I../../src/preprocessors/flow -I../../src/preprocessors/ portscan -I../../src/preprocessors/flow/int-snort -I../../src/preprocessors/ Httplnspect/include -I/usr/include/pcre -I/usr/local/include -g -02 -Wall -DGIDS -DJSDJOURCE -D_BSD_SOURCE -D_ JAVORJSD -DHAVE_NET_ETHERNET_H -DLIBNET_LIL_ ENDIAN -c 4 test -f 'spo_alert_fast.c' || echo \/"spo_alert_fast.c In f i l e included from /usr/include/linux/netfilter_ipv4/ip_queue.h:10, from /usг/i nciude/1i bi pq.h:37, from ../../src/inline.h:8, from ../.,/src/snort.h:38, from spo_alert_fast.c:51: /usr/include/linux/if.h:59: redefinition of 4struct ifmap1 /usr/include/linux/if.h:77: redefinition of 'struct ifreq1 /usr/include/linux/if.h:126: redefinition of 'struct ifconf make[3]: *** [spo_alert_fast.o] Error 1 make[3]: Leaving directory 7home/andrew/snort_inline-2.1.0/src/output-plugins' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory Vhome/andrew/snort_inline-2.1.0/src' make[l]: *** [all-recursive] Error 1 make[l]: Leaving directory 7home/andrew/snortjnline-2.1.0' make: *** [all] Error 2

Трюк № 87. Предотвращение и сдерживание вторжений с помощью Snortjnline 259 Это вызвано тем, что /usr/include/linux/netfilter_ipv4/ip_queue.h включает (including) /usr/include/linux/lf.h, а не /usr/include/net/if.h (я сам столкнулся с этим). Для того чтобы обойти эту проблему, просто исправьте ip_queue.h и измените строчку в начале файла #include на #include Для продолжения компиляции с того места, где мы остановились, просто введите make либо запустите компиляцию заново: $ make clean && make После завершения компиляции получите root-полномочия и введите make install. Теперь необходимо настроить Snortjnline, так же как если бы вы конфигурировали Snort. Однако, если вы хотите получать лишь оповещения, рекомендуется запускать отдельный экземпляр Snort, а для настройки правил межсетевого крана запускать только Snortjnline. Помимо того что Snort теперь захватывает пакеты от Netfilter, а не от libpcap, обновление добавляет в него три новых типа правил: drop, sdrop и reject. Тип drop будет сбрасывать пакеты, запустившие правило без уведомления отправляющего узла (так же, как DROP в iptables), выполняя лишь протоколирование. Тип sdrop аналогичен предыдущему, но выполняется без протоколирования. Использование типа reject приводит к блокировке «враждебного» пакета, но с уведомлением отправляющей стороны с помощью TCP RST либо сообщением о невозможности доставки ICMP — в зависимости от типа протокола, используемого пакетом, запустившим правило: TCP либо UDP соответственно. Новый параметр правил, добавленный за счет обновления Snortjnline, позволяет заменять любое содержание пакета любым значением. Единственное требование к замене: длина замещения должна быть равна длине замещаемого потока байтов. Это реализуется с помощью параметра replace, используемого совместно с параметром content. Snortjnline запускается так же, как и Snort, хотя обновление Snortjnline добавило новый ключ командной строки -Q, заставляющий использовать IP-очередь, а не libpcap. Этот ключ используется для включения inline-режима. Все, что осталось сделать перед действительным запуском в inline-режиме, — настроить в ядре отправку пакетов в IP-очереди. Это делается с помощью команды iptables: # # # #

iptables iptables iptables iptables

-F -A INPUT -j QUEUE -A OUTPUT -j QUEUE -A FORWARD -j QUEUE

Это приведет к «проталкиванию» всего приходящего, отправляемого или проходящего трафика в IP-очередь, из которой Snortjnline будет считывать пакеты. Теперь можно запустить Snortjnline (только не забудьте указать ключ -Q): # snort inline -Qvc /etc/snort/snort inline.conf

260


Если вы выполняете удаленное администрирование машины, то захотите запускать Snortjnline до включения правил QUEUE, поскольку теперь передавать пакеты назад и вперед будет Snortjnline. В противном случае удаленная регистрация будет сброшена, как только будут активизированы правила iptables. Если BVF действительно так хочется, заставьте правила с QUEUE игнорировать пакеты, поступающие с определенного IP-адреса или диапазона адресов.

Автоматизированная динамическая фильтрация пакетов с помощью SnortSam Используйте SnortSam для предотвращения вторжения путем включения правил динамической фильтрации, останавливающей атаку.

Альтернативой запуску Snort на межсетевом экране и активизации правил фильтрации на машине, на которой он установлен (трюк № 87), является Snort, сообщающий, какие правила фильтрации должны использоваться при обнаружении внедрения на внешнем сетевом экране. Для этого используется SnortSam (http:// www.snortsam.net). SnortSam использует архитектуру надстроек Snort и расширяет ее возможностью уведомлять внешний межсетевой экран, который затем динамически применяет правила фильтрации для остановки находящихся в процессе реализации атак. В отличие от обновления Snortjnline, которое сильно зависит от ОС Linux, SnortSam поддерживает широкое разнообразие межсетевых экранов, таких как Checkpoint, Cisco, Netscreen, Firebox, pf ОС OpenBSD и даже ipchains- и iptables-интерфейсы к Netfilter в ОС Linux. SnortSam состоит из двух компонентов: надстройки Snort и демона. Для установки SnortSam сначала загрузите из Сети дистрибутив и распакуйте его. Перейдя в созданный при этом каталог, выполните команду $ sh makesnortsam.sh При этом будет скомпонован двоичный файл snortsam, который необходимо скопировать в подходящее место (например, в /usr/bin или /usr/local/bin). Теперь загрузите из Сети обновление для Snort (можно найти на том же сайте, что и SnortSam). После этого распакуйте его: $ tar xvfz snortsam-patch.tar.gz NOTE patchsnort.sh patchsnort.sh.asc snortpatch8 snortpatch8.asc snortpatch9 snortpatch9.asc snortpatchb snortpatchb.asc

Трюк № 88. Автоматизированная динамическая фильтрация пакетов 261 Далее запустите patchsnort.sh и укажите каталог, в котором находится исходный программный код Snort: $ sh patchsnort.sh snort-2.0.5 Patching Snort version 2.0... patching file spo_alert_fwsam.c patching file spo_alert_fwsam.h patching file twofish.c patching file twofish.h patching file plugbase.c Hunk #1 succeeded at 29 with fuzz 2 (offset -73 lines). Hunk #2 succeeded at 639 with fuzz 2 (offset 77 lines). Patching Makefiles... Done А теперь скомпилируйте Snort как обычно (см. трюк № 82). Перед запуском SnortSam необходимо создать конфигурационный файл. Синтаксис его крайне прост, но содержит несколько параметров, поэтому мы рассмотрим лишь часть из них. Одним из наиболее полезных параметров является accept, который сообщает о возможности подключения SnortSam к Snort-датчикам. Аргументами этого параметра могут быть диапазон адресов в CIDR-формате, имя узла или отдельный IP-адрес. Также можно сразу указать пароль. Если пароль не был указан, то будет использован пароль, указанный в параметре defaultkey. Например, если необходимо допустить все узлы из сети 192.168.1.0/24 с паролем qwi jybo, то в конфигурационный файл можно поместить подобную строку: \ accept 192.168.1.0/24, qwijybo Для указания нескольких узлов необходимо использовать несколько accept-записей. Другим полезным параметром является dontblock. Он позволяет создавать «белый список» узлов и сетей, которые SnortSam не будет блокировать. В качестве аргументов этого параметра могут использоваться имена узлов, отдельные IPи CIDR-адреса. Для указания различных узлов также необходимо использовать несколько dontblock-записей. Для повышения производительности SnortSam можно воспользоваться параметром skipinterval. Он позволяет указать SnortSam интервал, в течение которого не надо повторно генерировать одинаковые запросы блокировки. Это гарантирует, что SnortSam не будет снова и снова сообщать межсетевому экрану о блокировании одного и того же IP-адреса. В качестве аргумента skipinterval воспринимает одно параметром ему как никающие Вероятно, запуск изменять числовое вам при программы, logfile, правила значение захочется этомкоторый ошибки. межсетевого блокировка — вести количество заставит Параметр учет действий иэкрана. снятие SnortSam секунд имеетДля SnortSam, блокировки ожидания. единственный протоколировать этого поскольку можно запросов, аргумент, воспользоваться такие выа позволили также события, который воз-

262


является именем файла, куда будет записываться протокол. Указанный файл будет создан в /var/log. Полезными параметрами являются также daemon и bindip. Первый заставляет SnortSam перейти в фоновый режим и работать как демон. Аргументы не требуются. Параметр bindip позволяет указать IP-адрес, который необходимо «прослушивать», что полезно, когда машина, на которой запущен SnortSam, имеет несколько доступных адресов. Например, для того чтобы SnortSam «слушал» только адрес 192.168.1.15, необходимо использовать следующую строку: bindip 192.168.1.15 К тому же по умолчанию SnortSam «слушает» 898-й порт, но его можно изменить с помощью параметра port. После определения параметров необходимо указать, с каким межсетевым экраном связываться и как это сделать. Для использования SnortSam с экраном Checkpoint Ffwexec или fwsamW-1 можно воспользоваться ключевым словом fwexec или fwsam. Ключевое слово fwexec используется в тех случаях, когда необходимо запустить SnortSam на узле, на котором установлен межсетевой экран, a fwsam — когда необходимо связаться с удаленным межсетевым экраном. Ключевое слово fwexec получает в качестве единственного аргумента полный путь к исполняемому файлу fw, в то время как fwsam — имя узла или IP-адрес межсетевого экрана. К тому же необходимо изменить файл fwopsec.conf на межсетевом экране, добавив в него строку

sam_server port 1813 Для применения SnortSam с межсетевым экраном PIX необходимо использовать ключевое слово pix и указать IP-адрес, а также пароли Telnet и разрешенного режима, например: pix 192.16.1.2 telnetpw enablepw Если же межсетевой экран настроен на идентификацию пользователя, вместо Telnet-пароля можно использовать пару user/password (пользователь/пароль). Для того чтобы SnortSam работал с PF ОС OpenBSD или iptables ОС Linux, необходимо использовать ключевое слово pf или iptables. Для базового использования достаточно указать интерфейс, на котором необходимо блокировать пакеты. Для настройки Snort-стороны необходимо добавить надстройку выхода alert_ fwsam к уже используемой надстройке вывода. Этой надстройке нужно указать имя узла и (необязательно) порт, к которому необходимо подключиться, а также пароль. Если SnortSam использует порт по умолчанию, номер порта здесь указывать не надо, например: output alert_fwsam: firewai1/mypassword firewa!12:1025/mypassword Обратите внимание на то, что имеется возможность указать несколько интерфейсов, на которые SnortSam будет посылать запросы на блокировку, разделяя их пробелами. Любые правила, с помощью которых будет запускаться правило

Трюк № 89. Обнаружение аномального поведения

2ВЗ

межсетевого экрана, должны использовать параметр fwsam. Этот параметр в качестве аргумента узнает, что блокировать и как долго. Для блокирования источника пакета, который вызвал тревогу, используется значение src, для блокировки пункта назначения — dst. Если необходимо блокировать и отправителя и получателя, то указывается значение either. Для определения длительности можно использовать число с указанием модификатора, определяющего единицы измерения (например, seconds, minutes, hours, days, weeks, months или years), а для указания неопределенно длительного периода используется значение 0. Например, для блокирования на 5 минут адреса отправителя пакетов, которые вызывают срабатывание правила, в правило необходимо добавить следующие параметры: fwsam: src, 5 minutes: Теперь, когда все настроено, запустите SnortSam подобной командой: # snortsam /usr/local/etc/snortsam.conf Конечно же, вам необходимо подставить полный путь к конфигурационному файлу, если он находится не в каталоге /usr/local/etc/snortsam.conf. Дополнительные сведения об использовании SnortSam с другими межсетевыми экранами можно найти в README-файлах, входящих в дистрибутив.

Обнаружение аномального поведения Обнаружить атаки и вторжения можно в результате наблюдения за «отклонением» трафика относительно обычного содержания.

Большинство NIDS наблюдают за сетью, выполняя поиск специфических проявлений атак. Еще один способ обнаружения вторжения заключается в накоплении статистики обычного трафика сети и подачи сигнала тревоги при обнаружении отклонений от усредненной нормы. Одной из систем обнаружения вторжения такого типа является Spade (http://www.silicondefense.com/software/spice/). Spade (сокращение от Statistical Anomaly Detection Engine1) — это видоизмененная версия Snort, функциональность которой расширена в область обнаружения вторжения на основе аномального поведения трафика. Препроцессор Spade использует Snort для наблюдения за сетью и в дальнейшем строит вероятностные таблицы, основываясь на отмеченном трафике. После этого таблица используется для генерации для каждого пакета оценочного значения отклонения в диапазоне от 0 до 1 (где 0 — совершенно нормально, 1 — абсолютно ненормально). Установка Spade очень проста. Просто загрузите дистрибутив из Сети, распакуйте его и перейдите в созданный при этом каталог. После этого выполните обновление программного кода Snort с помощью команды $ make SNORTBASE=../snort-2.0.5 1

Механизм обнаружения статистической аномалии.

2Б4


Разумеется, если дерево каталогов исходного кода Snort находится не в ./snort-2.0.5, необходимо указать точный путь. Теперь перейдите в каталог, содержащий исходный код Snort, откомпилируйте и установите его обычным способом (см. трюк № 82). После этого необходимо сконфигурировать Snort и Spade. Здесь имеется два варианта: настройка использования лишь функции Spade либо совместная работа Snort и Spade. Для первого из этих вариантов в качестве отправного пункта необходимо использовать файл spade.conf, размещенный в дистрибутиве Spade. Большинство предлагаемых значений нас устраивают. Однако в переменной SPADEDIR необходимо определить, в отношении какого каталога Snort имеет права записи и чтения. В нем Spade будет сохранять различные протоколы и значения контрольных точек, поэтому при перезапуске Snort таблица вероятностей не потеряется, например: var SPADEDIR /var/log/snort/spade Для Spade важно знать, какая сеть является «домашней». Определить это можно с помощью следующей записи в конфигурационном файле: peprocessor spade-homenet: 192.168.1.0/24 Можно указать несколько сетей, разделив их двоеточиями и заключив весь список в квадратные скобки. Если требуется обеспечить совместную работу Snort и Spade и сохранить обычную функциональность Snort, то файл spade.conf необходимо включить в файл snort.conf: include spade.conf Запустите Snort, как это делалось ранее. Теперь Spade при обнаружении аномального поведения будет отправлять свой вывод в любую сконфигурированную надстройку вывода. Это сработает в тех случаях, когда значение отклонения конкретного пакета составляет 0,8-0,9 (в зависимости от типа пакета). Любые сигналы тревоги, сгенерированные Spade, будут иметь предлог Spade и содержать описание отклонения пакета от нормы и значение этого отклонения.

Если имеется лишь небольшое количество IDS-датчиков, то поддержание правил Snort «свежими» является довольно простой задачей. Однако по мере увеличения количества датчиков все усложняется. К счастью, с помощью Oinkmaster (http://oinkmaster.sourceforge.net/news.shtml) имеется возможность автоматически обновлять правила. Oinkmaster — это Perl-сценарий, который умеет не только загружать из Сети новые правила Snort, но и модифицировать их в соответствии с указанными правилами либо выборочно удалять. Это полезно при более точной подстройке стандартных

Трюк № 9 1 . Создайте сеть распределенных датчиков-невидимок

265

правил под среду либо при отключении правил, вызывающих слишком много ложных срабатываний. Для установки Oinkmaster просто загрузите дистрибутив и распакуйте его, после чего скопируйте файл oinkmaster.pl из созданного каталога в подходящее место. Кроме того, необходимо скопировать файл oinkmaster.conf в /etc или в /usr/ local/etc. Входящий в дистрибутив файл oinkmaster.conf содержит множество комментариев, объясняющих назначение каждого параметра. Oinkmaster особенно полезен в тех случаях, когда необходимо обновить правила, но в существующий набор правил входят «лишние» правила или правила, которые уже отключены помещением перед ними символа комментария. Для того чтобы Oinkmaster автоматически отключил эти правила, воспользуйтесь директивой disablesid, в которой указывается идентификатор правила, которое необходимо отключить. Например, вы получаете множество ICMP-дейтаграмм с невозможностью доставки в сети и определили, что не хотите получать сигналы тревоги, когда Snort обнаруживает такой тип трафика. Поэтому вы решили «закомментировать» это правило в файле icmp. rules: # alert icmp any any -> any any (msg:"ICMP Destination Unreachable (Communication Administratively Prohibited)"; itype: 3; icode: 13; sid;485; classtype:mi sc-acti vity: rev:2;) В данном случае это единственное правило, поэтому можно легко вернуться назад и снять знак комментария после обновления правил, но эта задача становится крайне сложной, если это было сделано с несколькими десятками других правил. Если используется Oinkmaster, то помещение представленной далее строки в oinkmaster.conf отключит предыдущее правило в ходе замены всех правил новыми с сайта snort.org: disablesid 485 Когда захотите обновить правила, запустите oinkmaster.pl и укажите, где находятся правила, которые необходимо обновить: # oinkmaster.pl -о /etc/snort/rules

Теперь нет необходимости запоминать, какие правила были отключены.

Создайте сеть распределенных датчиков-невидимок Спрячьте IDS-датчики от атак, сохранив возможность обращаться к их данным.

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

266


и собранных ими данных. Одним из способов сделать это является перевод их в режим «невидимок». Для этого просто не настраивайте IP-адрес сетевого интерфейса, с которого IDS будет собирать данные. Это можно сделать выбором интерфейса без указания IP-адреса: # tcpdump -i ethl tcpdump: bind: Network is down # ifconfig ethl up promise # ifconfig ethl ethl Link encap:Ethernet HWaddr 00:DE:AD:BE:EF:00 UP BROADCAST PROMISC MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 col 1isionsrO txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:11 Base address:0xlc80 # /usr/sbin/tepdump -i ethl tcpdump: WARNING: ethl: no IPv4 address assigned tcpdump: listening on ethl После выбора интерфейса просто запустите IDS (см. трюк № 82). IDS запустится как обычно, но, поскольку отсутствует возможность непосредственного доступа к машине, ее будет очень сложно атаковать. Так же как и потенциальные атакующие, вы не будете иметь удаленного доступа к машине. Следовательно, для удаленного управления датчиком необходимо вставить второй сетевой интерфейс. Конечно же, если подключить его в ту же сеть, за которой наблюдает IDS-датчик, то подключение сетевого интерфейса без IP-адреса полностью потеряет смысл. Необходимо создать отдельную сеть для управления IDS-датчиками, чтобы трафик остался изолированным. Эту сеть можно подключить к удаленно доступной сети и использовать «строгий» межсетевой экран. Еще один способ обращения к системному блоку заключается в использовании альтернативного канала, такого как последовательный порт, подключенный к другой машине, имеющей сетевое подключение. Просто запустите консоль на этом последовательном порте и обеспечьте надежную защиту второй машины. Можно также подключиться по модему к специальной телефонной линии либо, что еще лучше, к незарегистрированному расширению офисной РВХ1 (Private Branch eXchange). В зависимости от ситуации использование консоли для удаленного доступа является простейшим и наиболее безопасным методом. Какой бы метод вы ни избрали для удаленного доступа, решение должно учитывать повышение защиты и неудобство доступа к машине. Защита практически всегда связана с противоречием между удобством и доверием. 1

Телефонная система для частного пользования.

Трюк № 92. Использование Snort в высокопроизводительной среде с Barnyard

267

Использование Snort в высокопроизводительной среде с Barnyard Разъедините выход Snort для того, чтобы эта программа поспевала за пакетами.

Snort подходит для наблюдения за небольшими сетями или сетями с малым трафиком, но без дополнительной поддержки она плохо масштабируется. Проблема не в самом механизме обнаружения пакетов, она вызвана тем, что Snort является однопотоковым приложением. Из-за этого при возникновении протоколируемого события оно должно сначала отправить сигнал тревоги или сделать запись в протокол, а лишь затем вернуться к просмотру входящего потока данных. Это не очень критично, если необходимо просто выполнить запись в файл, но при протоколировании в базу данных, которая может попросить Snort подождать завершения вставки довольно длительное время, может стать проблемой, особенно если БД находится на удаленном сервере. Для решения этой проблемы было создано другое приложение — Barnyard (http:// www.snort.org/dl/barnyard/). Функционально Barnyard — это эквивалент выходных надстроек Snort, «свернутых» в одну программу с внешним интерфейсом, осуществляющим чтение из сгенерированных Snort файлов и последующую пересылку в ту же БД или иное место, куда выполняет протоколирование Snort. Единственным недостатком Barnyard является ограниченная поддержка БД: поддерживается только MySQL, в то время как Snort поддерживает вывод в MySQL, PostgreSQL, Oracle и ODBC. После загрузки и распаковки Barnyard перейдите в созданный при этом каталог и запустите сценарий конфигурирования: $ ./configure --enable-mysql После компиляции Barnyard это обеспечит поддержку MySQL. Если вы установили библиотеки MySQL и поместили файлы в нестандартное место (то есть не в качестве подкаталога /usr или /usr/local), то это место необходимо указать с помощью параметров --with-mysql-includes и --with-mysql-libraries. После выполнения сценария конфигурирования можно с помощью команды make скомпилировать Barnyard. После завершения компиляции получите root-полномочия и выполните команду make install. Перед использованием Barnyard необходимо настроить Snort на использование единого формата вывода. Это двоичный формат, который включает как сигнал тревоги, так и данные о пакете, который вызвал тревогу. Он должен быть тем единственным типом, который понимает Barnyard. Для настройки Snort на использование единого формата как для сигналов тревоги, так и для протоколируемых событий добавьте подобные строки в конфигурационный файл Snort (то есть в /etc/snort/snort.conf или /usr/local/etc/snort/snort.conf):

268


output alertjjnified: filename snort.alert, limit 128 output logjjnified: filename snort.log, limit 128 Указанные здесь filenames — это базовые имена файлов, в которые Snort будет записывать свою информацию о сигналах тревоги и протоколируемых событиях. При записи в файл в конец базового имени будет добавлена текущая временная метка Unix. Кроме того, размер этих файлов будет не более 128 Мбайт. Теперь необходимо создать конфигурационный файл для Barnyard. Для того чтобы Barnyard запускался в режиме демона и автоматически переводил себя в фоновый режим, добавьте в конфигурационный файл строку config daemon Если вы собираетесь выполнять протоколирование в БД для последующего использования ACID (см. трюк № 83), необходимо добавить также подобные строки: config hostname: colossus config interface: ethO Они определяют имя машины, на которой запускается Barnyard, и интерфейс, с которого Snort считывает пакеты. Далее необходимо указать Barnyard считывание унифицированных файлов протокола. Задайте для событий тревоги processor dp_alert или, если вы хотите обрабатывать события протокола, processor dpjog Обратите внимание на то, что Barnyard может обрабатывать лишь один тип событий. Поэтому если требуется обрабатывать оба типа событий, то запустите по одному экземпляру Barnyard для каждого типа. Осталось только определить, куда Barnyard должен отправлять данные. Если есть желание использовать режим быстрой тревоги (fast alert mode), генерирующий однострочные сокращенные сигналы тревоги, используйте надстройку вывода alert_fast: output alertjfast: fast_alerts.log А если вы хотите, чтобы Barnyard генерировал ASCII-пакеты, содержащие унифицированные протоколы, можно использовать следующую строку: output log_dump: ascii_dump.log Для того чтобы Barnyard осуществлял вывод в syslog-демон, используйте надстройку alert_syslog, так же как в snort.conf. Например, если хотите отправлять данные локальному syslogd, используя при этом функцию auth и уровень протоколирования alert log, то добавьте следующую строку: output alert_syslog: LOG_AUTH LOG_ALERT А если протоколирование осуществляется на удаленном сервере, то добавьте output alert_syslog: hostname=loghost, LOG_AUTH LOG_ALERT


269

Из данных унифицированного протокола Barnyard также может создавать файлы Рсар-формата. Это полезно для последующего анализа данных с помощью такого средства, как Ethereal. Для задания этой функции воспользуйтесь надстройкой log_pcap: output log_pcap: alerts.рсар И наконец, Barnyard может выводить данные в БД, используя надстройку alert_ acid_db для протоколирования событий тревоги, a log_acid_db — для протоколирования событий протокола. Например, использование представленной далее строки приведет к отправке сигналов тревоги в БД MySQL с именем SNORT, расположенной на dbserver, для обращения к которому используется имя пользователя snort: output alert_acid_db: mysql. sensoMd 0, database SNORT, server dbserver, user snort Параметр sensoMd — это датчик, назначенный ACID для конкретного экземпляра Snort. Идентификатор датчика можно узнать, щелкнув на ссылке Sensors на основной странице ACID (см. трюк № 83), после чего будет выведен список датчиков, которые в данный момент работают с ACID. Надстройка log_acid_db аналогична alert_acid_db, за исключением того, что она не использует параметр sensor_id: output log__acid_db: mysql, database SNORT, server dbserver, user snort, detail full Запустить Barnyard можно с помощью представленной далее команды, если конфигурационные файлы Snort хранятся в /etc/snort, а протоколы — в /var/log/snort: # barnyard -f snort.alert Разумеется, что snort.alert использовался при конфигурировании надстройки alert_unified. Если конфигурационные файлы Snort хранятся не в /etc/snort, то вы должны указать расположение всех файлов, необходимых Barnyard, запустив подобную команду: # barnyard -с /usr/local/etc/snort/barnyard.conf \ -g /usr/local/etc/snort/gen-msg.map \ -s /usr/local/etc/snort/sid-msg.map -f snort.alert

Если для хранения протоколов Snort используется не /var/log/snort, то этот каталог необходимо указать с помощью параметра -d. Поздравляем! При запущенной программе Barnyard вы сможете обрабатывать большие объемы трафика, не сбрасывая некоторые события и не пропуская ни одного пакета.

Обнаружение и предотвращение вторжений в web-приложения Защитите web-сервер и динамическое содержание от проникновения.

Обнаружение вторжений, основанных на использовании распространенных протоколов и служб, — это задача, для которой удачно подходят системы обнаружения

270


вторжения. Однако из-за усложнения web-приложений и появления атак, от которых они уязвимы, очень сложно обнаружить вторжение без множества ложных срабатываний. Особенно верно это для приложений, использующих SSL, поскольку, для того чтобы NIDS смогла обратиться к расшифрованному трафику, приходится преодолевать множество сложностей. Одним из способов решить эти проблемы является интеграция системы обнаружения вторжения непосредственно в сам web-сервер. Что и делает mod_security (http://www.modsecurity.org) в отношении популярного web-сервера Apache (http://www.apache.org). Как можно догадаться из названия, mod_security — это модуль, повышающий безопасность (в данном случае web-сервера Apache) за счет предоставления возможности фильтрации запросов и выполнения каких-либо действий, основанных на правилах, указанных для определенного пользователя. Кроме того, mod_security выполняет несколько обоснованных проверок, которые нормализуют запросы, поступающие на web-сервер. При оптимальной настройке правил mod_security может оказаться эффективным в пресечении попыток просмотра каталогов, атак межсайтовых сценариев, атак SQL-инжекции и атак переполнения буфера. Для установки модуля загрузите дистрибутив и распакуйте его. Если вы хотите установить его как DSO (то есть в виде модуля), то воспользуйтесь утилитой apxs. Сначала перейдите в каталог, соответствующий используемой версии Apache (apache 1 или apache2), и запустите команду # apxs -cia mod_security.c Команда выполнит компиляцию mod_security и настроит Apache на загрузку этого модуля в ходе начальной загрузки. Если необходимо скомпилировать mod_security статически, то придется перекомпоновать Apache. При использовании Apache 1.x его можно статически скомпилировать, скопировав файл mod_security.c в каталог src/modules/extra дерева исходных текстов Apache. После этого запустить сценарий конфигурирования Apache со следующими параметрами: --activate-module=src/modules/extra/mod_securi ty --enable-module=security Теперь, когда mod_security установлен, его необходимо включить. Для этого поместите в файл httpd.conf следующие строки: SecFiiterEngine On Это приведет к включению функции нормализации запросов для всех запросов, поступающих на данный web-сервер. Можно также включить этот модуль только для динамического содержания, установив в переменной SecFilterEngine значение DynamicOnly. После того как модуль mod_security будет включен, он начнет перехватывать все запросы, поступающие на web-сервер, и выполнять несколько проверок перед передачей через определенные пользователем фильт-


271

ры, после чего запросы будут либо обслужены, либо отвергнуты. В ходе этих проверок mod_security преобразует несколько типов «хитрых» последовательностей символов в более распространенную форму. Так, последовательности // и /./ будут преобразованы в /, а для Windows символ \ будет преобразован в /. Кроме того, будут декодированы символы URL-шифрования. Помимо этих проверок, mod_security также будет настроен на сканирование «полезной нагрузки» POST-запросов и проверку достоверности URL- и Unicode-кодировки, содержащихся в запросах. Для включения этих функций добавьте в httpd.conf строки: SecFiIterScanPOST On SecFi1terCheckURLEncodi ng On SecFi HerCheckUnicodeEncoding On URL-кодирование позволяет при отправке запроса шифровать входящие в него символы с помощью шестнадцатеричных значений (используя лишь цифры с О до 9 и символы от А до F), перед которыми стоит символ %. Когда включена проверка достоверности URL-кодирования, mod_security просто убеждается, что символы URL-шифра не нарушают систему шестнадцатеричного шифрования. При выполнении проверки Unicode mod_security в основном выполняет такую же проверку: убеждается, что строчное значение в Unicode является действительным. Проверка Unicode нужна в тех случаях, когда web-сервер запущен на операционной системе, поддерживающей Unicode, или его используют web-приложения. Для предотвращения атак переполнением буфера можно ограничить размер строки запроса. Например, для того чтобы строка запроса содержала только печатаемые символы, добавьте в httpd.conf следующую строку: SecFi UerForceByteRange 32 126 С помощью ключевых слов SecFi "I ter и SecFi I terSel ecti ve могут быть созданы пользовательские фильтры. SecFi Her может использоваться для поиска строки запроса, a SecFi I terSel ecti ve — в тех случаях, когда вы хотите фильтровать запросы, основанные на значении внешней переменной web-сервера. Оба ключевых слова могут воспринимать обычные выражения. Далее представлены правила фильтрации, позволяющие предотвратить некоторые распространенные атаки. Данное правило будет отфильтровывать запросы, содержащие символьную последовательность ..//: SecFilter "\.\./" Даже если web-сервер будет корректно воспринимать ..// и запрещать доступ, если это приводит к разрешению каталога, выходящего за пределы корневого каталога документов, это может не сработать для сценариев или приложений, работающих на web-сервере. Представленное правило как раз и предотвращает обработку подобных запросов.

Трюк № 93. Обнаружение и предотвращение вторжений в у\/еЬ-пр:*ложения

273

слова log и pass, которые указывают действие, предпринимаемое при срабатывании правила. В данном случае, когда содержимое запроса совпадет с данным правилом, запрос будет занесен в протокол ошибок Apache, а затем он поступит на дальнейшую обработку web-сервером. Если в правиле действие не определено, то будет выполнено действие по умолчанию. Определение действия по умолчанию осуществляется следующим образом: SecFiIterDefaultAction "deny.1og.status:500" При такой настройке web-сервер будет отвергать все запросы, совпадающие с правилами фильтра, в которых не указано действие. Кроме того, они будут протоколироваться, а затем перенаправляться на страницу состояния (status page) HTTP 500, которая проинформирует клиента о возникновении внутренней ошибки сервера. Можно также определить следующие действия: allow, которое аналогично pass, но останавливает проверку другими фильтрами; redirect, которое перенаправляет клиента на произвольный URL; exec, которое выполняет внешний двоичный файл или сценарий; chain, которое позволяет указывать оператор AND между правилами. Помимо фильтрации, mod_security предоставляет отличные возможности аудита, позволяя сохранять посланный на сервер запрос в протоколе целиком. Для включения такого протоколирования добавьте в httpd.conf следующие строки: SecAuditEngine On SecAuditLog logs/audit_log Однако при этом будут протоколироваться все запросы, поступающие на webсервер. Очевидно, что довольно быстро будет сгенерирован большой объем информации. Для того чтобы протоколировались только запросы, совпадающие с правилами, установите переменную SecAuditEngine в RelevantOnly. В качестве альтернативы можно установить эту переменную в DynamicOrRelevant, что приведет к протоколированию запросов к динамическому содержанию или запросов, совпадающих с правилами фильтра. Как и большинство директив конфигурирования Apache, директивы конфигурирования mod_security можно помещать в тег , что позволяет указывать индивидуальную конфигурацию для определенных сценариев или структуры каталогов. Модуль mod_security — это очень мощное средство защиты web-приложений, но он не должен замещать действительную проверку достоверности входных значений приложения или другие средства защиты кода. Если это возможно, лучше отдельно реализовать эти методы в качестве дополнения к таким средствам, как mod_security. СМОТРИ ТАКЖЕ «Introducing mod_security»: http://www.onlamp.eom/pub/a/apache/2003/11/26/mod_ security.html и «Mod_security Reference Manual v1.7.4»: http://www.modsecurity.org/ documentation/modsecurity-manual-1.7.4.pdf.

10 Зак. 1103

274 ТРЮК

№94


Имитация сети с уязвимыми узлами Используйте honeyd для предоставления потенциальным взломщикам возможности погоняться за призраками.

Как утверждает поговорка, на сахар слетается больше мух, чем на уксус. (Раньше я не понимал эту поговорку: ну кому надо привлекать мух?) В нашем случае «приманка» используется для притягивания «мух» Интернета: проказников, использующих сценарии, и подражателей хакерам, которые в свободное время не находят более достойного занятия чем сканировать уязвимость узлов и пытаться атаковать их. «Приманка» имитирует запуск на сервере уязвимых служб, а на самом деле собирает сведения об атакующих, которые думают, что они умнее. Собираетесь ли вы имитировать один или тысячу уязвимых узлов, в любом случае honeyd (http://www.honeyd.org) сведет эту работу к редактированию конфигурационного файла и запуску демона. Демон honeyd может изображать тысячи узлов одновременно и позволит для каждого узла указать операционную систему, которая будет «определена» при сканировании типа операционной системы такими средствами, как Nmap (см. трюк № 42). Каждая система, имитируемая honeyd, будет «видна» как полноценный узел сети. Помимо создания узлов, откликающихся на команды ping и traceroute, honeyd позволяет указывать, какие службы будут имитироваться на каждом узле. Для эмуляции службы могут использоваться простые сценарии, но honeyd может использоваться как прокси и перенаправлять запросы для обслуживания их другим узлам. Для нормальной работы honeyd требует выполнения нескольких условий. До компоновки honeyd должны быть установлены libevent (http://www.monkey.org/~provos/ libevent/), libdnet (http://libdnet.sourceforge.net) и libpcap (http://www.tcpdump.org). Они легко устанавливаются загрузкой из Сети, распаковкой и выполнением стандартной процедуры установки ./configure && make i n s t a l l . Установив эти библиотеки, аналогично установите и honeyd. После этого скопируйте сценарии имитации служб из дистрибутива в более подходящее место (например, в /usr/ local/share/honeyd/scripts). Существует лишь несколько сценариев, которые поставляются вместе с honeyd, а дополнительные сценарии можно загрузить с платной страницы http://www.citi.umich.edU/u/provos/honeyd/contrib.html. После установки honeyd необходимо создать конфигурационный файл, определяющий типы имитируемых операционных систем и служб, а также IP-адреса, которые будет сообщать honeyd. Для начала создайте несколько заготовок ОС: ### Windows computers create windows-web set windows-web personality "MS Windows2000 Professional RC1/W2K Advance Server Beta3" set windows-web default tcp action reset set windows-web default udp action reset add windows-web tcp port 80 "perl scripts/win2k/iisemulator-0.95

/iisemul8.pl" add windows-web tcp port 139 open add windows-web tcp port 137 open

27В



277

250-ETRN 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-8bitmime 250-BINARYMIME 250-CHUNKING 250-VRFY 250-X-EXPS GSSAPI NTLM LOGIN 250-X-EXPS40GIN 250-AUTH GSSAPI NTLM LOGIN 250-AUTH=LOGIN 250-X-LINK2STATE 250-XEXCH50} 250 OK Очень эффективно на первый взгляд, не так ли? Если захотелось бы подключить некоторые реальные службы, с которыми «играл» бы атакующий, то для перенаправления любого порта на узел, расположенный на другой машине, необхоФиксируйте все, что происходит с вашей «приманкой». димо использовать ключевое слово proxy. Например, следующая команда будет перенаправлять SSH-запросы от нашего воображаемого Linux-узла на машину сПосле адресом того192.168.1.100: как атакующий попался на «приманку» и получил к ней доступ, важadd linux tcp port 22 proxy 192.168.0.100:22 но отследить всю его деятельность на этой машине. Пристально изучая ее, можПомимо запуска сценариев имитации служб, honeyd может ограничивать входную но не только определить цели незваного гостя, но и изучить новые технологии и выходную пропускную способность и даже замедлять доступ к определенной компрометации системы, которыми пользовался злоумышленник для получения службе. Этот прием может использоваться для «связывания» ресурсов спамеров доступа. Если вам не интересно, что пытался сделать атакующий, тогда зачем за счет удержания «видимо открытым» постового ретранслятора. Предоставляеставить «приманку»? мые honeyd возможности ограничены только вашей фантазией и временем, котоОдин самыхпотратить эффективных методовсетей-«мухоловок». отслеживания каждого пакета и дейстрое выизможете на создание вия — использование средств наблюдения, имеющихся в ядре. При этом можно наблюдать практически все, что делает атакующий, даже если для защиты своих данных или сетевого подключения он использует шифрование. Одним из

Запись деятельности «приманки»

278


средств наблюдения за «приманкой» на уровне ядра является Sebek (http://www. honeynet.org/tools/sebek/). Sebek — это загружаемый модуль ядра для Linux и Solaris, перехватывающий ключевые системные вызовы в ядре и наблюдающий за интересующей его информацией. После этого он передает данные «слушающему» серверу и скрывает наличие передачи из локальной системы. На самом деле Sebek состоит из двух модулей. Первый, sebek.o, действительно наблюдает. А второй модуль, cleaner.o, служит для обеспечения скрытности работы первого. Для компоновки модулей на ОС Linux сначала убедитесь в том, что /usr/src/ linux-2.4 содержит исходный код ядра, для которого вы собираетесь скомпилировать модули. Затем либо распакуйте исходный код ядра в этот каталог, либо установите символическую ссылку на существующее дерево исходного кода ядра. После этого загрузите из Сети исходный дистрибутив, распакуйте его и скомпонуйте обычным образом: $ ./configure $ make При этом будет создан tar-архив, содержащий модули ядра и сценарий установщика. Скопируйте этот архив в «приманку», чтобы завершить установку. Вот что оказалось внутри: $ tar tf sebek-1inux-2.1.4-bin.tar sebek-linux-2.1.4-bin/ sebek-1 inux-2.1.4-bin/sebek.о sebek- linux-2.1.4-bin/cleaner.o sebek-linux-2.1.4-bin/sbk_install.sh Перед установкой модулей на «приманке» необходимо изменить сценарий sbk__ install.sh и несколько переменных, указывающих sebek.o, куда отправлять собранную информацию. Этими переменными являются DESTINATION_MAC, DESTINATION_IP, SOURCE_PORT и DESTINATION_PORT. Они должны указывать на Sebek-сервер, созданием которого мы займемся чуть позже. DESTINATION_PORT должен быть одинаков для всех «приманок», которые вы собираетесь использовать. Кроме того, переменная MAG I C_VAL также должна иметь одинаковое значение для всех «приманок». Эта переменная совместно с DESTINATIONPORT используется для сокрытия трафика от любой «приманки». Если необходимо, чтобы Sebek собирал с «приманки» только информацию о действиях, то установите переменную KEYSTROKE_ONLY в 1. Теперь запустите на «приманке» сценарий: # sh sbk_install.sh Installing Sebek: sebek.o installed successfully cleaner.o installed successfully cleaner.o removed successfully После того как Sebek установлен, удалите архив и файлы установки. Присутствие этих файлов в системе будет совершенно ясно указывать, что это — «приманка», и может отпугнуть злоумышленников.


279

Существует два варианта приема данных от Sebek. Самый простой — запустить Sebek-сервер, который будет улавливать информацию и автоматически извлекать ее для вас. Если вы предпочитаете собирать данные вручную, то можете использовать анализатор на узле, который вы указали в сценарии sbkjnstall.sh, а позже с помощью специальной утилиты извлечения данных Sebek «вытягивать» данные из хранилища пакетов. Для установки сервера загрузите его дистрибутив из Сети, распакуйте его, перейдите в созданный при этом каталог и запустите команду $ ./configure && make После завершения компиляции получите root-полномочия и запустите make install. При этом будут установлены sbk_extract, sbk_ksjog.pl и sbkjjpload.pl. Для извлечения сведений из «приманки» используется sbk_extract. Его можно запустить в режиме анализатора (sniffer mode), задав параметры -i и -р, указывающие, какой интерфейс «слушать» и какой порт назначения искать соответственно. Если хотите обрабатывать пакеты, уже перехваченные с помощью средств перехвата пакетов, для указания размещения файла-хранилища пакетов используйте ключ -f. После извлечения данных просмотр действий атакующего осуществляется с помощью sbk_ks_log.pl. Sebek имеет также дополнительный web-интерфейс, использующий РНР и MySQL, что позволяет выполнять более сложные запросы о собранных данных. Помимо протоколирования нажатий клавиш, web-интерфейс может извлекать файлы, которые были загружены на «приманку». Сценарий sbk_upload.pl загружает протоколы в web-интерфейс. Установка web-интерфейса довольно сложна и требует наличия сервера Apache, PHP и БД MySQL 4. Дополнительные сведения можно получить на домашней страничке Sebek, расположенной по адресу: http://www.honeynet.org/tools/sebek/.

ГЛАВА

8

Восстановление и ответные действия Трюки № 96-100 Восстановление системы после инцидента и ответная реакция — это очень обширная тема. Существует множество мнений о том, какие методы и действия, предпринимаемые после обнаружения вторжения, считать правильными. Так же как и споры, касающиеся использования vi или emacs, Linux против Windows и BSD-версий — против всех остальных, в компьютерных кругах идет крупный спор о предпочтительности «чистого выключения» перед «выключением из розетки». Целую книгу можно написать о проблеме восстановления после инцидента и реакции на него, поскольку принимать во внимание приходится много вещей и здесь не существует хорошо отлаженной процедуры. Учитывая это, в данной главе мы не претендуем на создание руководства к действию, которого необходимо придерживаться при столкновении с инцидентом, но здесь мы рассмотрим, как выполнять операции, которые вы решили предпринять в случае реального вторжения. При прочтении этой главы вы научитесь создавать образ файловой системы для использования его в ходе судебного разбирательства инцидента, познакомитесь с методами проверки неприкосновенности файлов и некоторыми соображениями о быстром определении владельцев IP-адресов.

Образ смонтированной файловой системы Сделайте побайтную копию диска системы для судебного анализа.

Перед форматированием и переустановкой операционной системы на недавно скомпрометированной машине вы должны потратить некоторое время для создания дубликатов всех данных, хранимых на этой системе. Наличие точной копии содержания системы важно не толькр для расследования прорыва, это может оказаться полезным для будущего судебного преследования. Прежде всего необходимо убедиться в том, что двоичные файлы md5sum, dd и fdisk сохранились в неприкосновенности (вы запускаете Tripwire (трюк № 97) либо заново устанавливаете RPM-пакеты (трюк № 98), правильно?). После того как вы начали сомневаться в целостности системы, на чем вы остановились? Могли быть запущены скрытые процессы, ожидавшие регистрации root в консоли и готовые удалить любые признаки прорыва. Более того, могут быть

Трюк № 96. Образ смонтированной файловой системы

281

установлены сценарии, которые запускаются при выключении системы и удаляют записи протоколов и любые файлы, которые могут использоваться в качестве обвинения. После того как вы обнаружили, что, скорее всего, машина скомпрометирована, вам захочется просто выключить ее (да, просто отключить!) и перезагрузиться с альтернативной среды. Воспользуйтесь загрузочным компактдиском или другим жестким диском, на котором установлена надежная копия операционной системы. При этом нет никакого сомнения, что система запускается с известного состояния, исключающего возможность наличия скрытых процессов, которые могут испортить данные еще до их копирования. Недостатком этой процедуры является очевидное уничтожение любых свидетельств выполнения программ или хранения данных на RAM-диске. Однако велика вероятность того, что взломщик установил другую «потайную дверь», которая сохраняется даже при перезагрузке, а эти изменения, скорее всего, сохранятся на диске. Для побайтного, копирования дисков используется команда dd. Но перед копированием надо вычислить контрольную сумму диска, для того чтобы проверить, является ли копия содержания диска точной копией. Для подсчета контрольной суммы раздела, для которого мы собираемся сделать образ, запустите следующую команду: # md5sum /dev/hda2 > /tmp/hda2.md5 В этом случае указывается второй раздел первого IDE-диска на Linux-системе. После этого наступает время создать образ диска: # dd if=/dev/hda of=/tmp/hda.img Обратите внимание на то, что в /tmp должно быть достаточно места для размещения копии всего жесткого диска /dev/hda. Это означает, что /tmp не должен быть RAM-диском и не должен находиться на /dev/hda. Запись должна выполняться на другой диск. Почему необходим образ всего диска целиком? Если создать образ лишь одного раздела, точной копии диска не получится. Атакующий мог хранить сведения за пределами этого раздела, и они не будут скопированы, если вы скопируете только сам раздел. В любом случае мы всегда можем восстановить образ раздела, если имеем образ всего диска. Для того чтобы создать отдельные образы разделов, потребуется немного дополнительной информации. Запустите fdisk для уточнения смещений и размеров каждого раздела. Для получения смещения конкретного раздела (в секторах) запустите команду # fdisk -I -u /dev/hda Disk /dev/hda: 4294 MB, 4294967296 bytes 255 heads. 63 sectors/track, 522 cylinders, total 8388608 sectors Units = sectors of 1 * 512 = 512 bytes Device Boot Start /dev/hdal * 63 /dev/hda2 208845 /dev/hda3 7341705

End 208844 7341704 8385929

Blocks 104391 3566430 522112+

Id 83 83 82

System Linux Linux Linux swap

282


Сохраните эту информацию для последующего использования, например, если позже вы захотите сделать отдельные образы разделов. ПГРТТРПК тчпятплм гЬямя-п^пяч татпппгп ПЯЯЛРТТЯ*

Обратите внимание на то, что параметр count выполняет некоторые математические вычисления: размер раздела — это место размещения последнего блока (7341704) минус место размещения первого блока (208845). Убедитесь, что параметр bs соответствует размеру блока, сообщенному программой fdisk (обычно 512, но лучше это проверить). В заключение подсчитаем контрольную сумму для файла-образа, а затем сравним ее с полученным ранее значением: # md5sum hda2.img > /tmp/hda2.img.md5 && diff /tmp/hda2.md5 /tmp/hda2.img.md5 Точное соответствие контрольной суммы образа контрольной сумме действительного раздела свидетельствует о безошибочности копии. Теперь мы можем восстановить исходную машину и просмотреть эту копию на досуге.

Проверка целостности файлов и поиск №97 скомпрометированных файлов Т Р Ю К

Tripwire позволит найти скомпрометированные файлы и проверить целостность файлов.

Одним из средств, которое поможет обнаружить вторжение на узел, а также установить, что случилось после этого факта, является Tripwire (http://sourceforge.net/ projects/tripwire). Tripwire относится к средствам проверки целостности файлов. Программа позволяет обнаружить повреждение файлов системы. Это очень важно, поскольку взломщики, получившие доступ к системе, для заметания следов и сохранения возможности доступа зачастую устанавливают то что называется root kit (набор суперпользователя). Реализуется это за счет изменения ключевых утилит операционной системы, таких как ps, Is, а также других программ, которые могут обеспечить наличие программы-«лазейки». Как правило, в этом случае подразумевается, что эти файлы исправлены таким образом, что при работе не будут сообщать об активности определенного процесса или о присутствии определенных файлов в системе. Взломщики также могут модифицировать системную программу вычисления контрольной суммы MD5 (например, md5 или md5sum), чтобы она всегда выдавала корректные контрольные суммы всех замещенных исполняемых файлов. Поскольку проверка контрольной суммы является основным способом обнаружения изменений файлов, становится понятно, что нужен иной метод проверки. Здесь на помощь и приходит Tripwire. Эта программа сохраняет «снимки» файлов, находящихся в известном состоянии, и для нахождения различий периодически

Трюк № 97. Проверка целостности файлов и поиск файлов

283

сравнивает файлы с их «снимками». С помощью «снимков» Tripwire может отслеживать изменения размера файла, inode-номера, разрешений, а также содержания файла. Помимо этого, Tripwire шифрует и подписывает свои собственные файлы, чтобы обнаружить их изменение. Tripwire опирается на два основных компонента: политику и БД. Политика определяет список всех файлов и каталогов, для которых Tripwire должен сделать «снимки», учитывая правила идентификации нарушения (то есть неожиданного изменения). Например, простая политика может трактовать любые изменения в /root, /sbin, /bin и /lib как нарушение. База данных Tripwire, собственно, и содержит «снимки» файловых систем, созданные с учетом политики. После завершения установки в любой момент можно сравнить файловые системы с их «снимками», получив отчет обо всех различиях. Помимо политики и БД, Tripwire имеет конфигурационные настройки, которые хранятся в файле, управляющем глобальными аспектами ее поведения. Например, эта конфигурация указывает размещение БД, файла политики и исполняемого файла Tripwire. Для защиты собственных файлов Tripwire использует два ключа шифрования. Ключ сайта (site key) защищает файл политики PI конфигурационный файл, а локальный ключ (local key) защищает БД и сгенерированные отчеты. Несколько машин с одинаковыми политикой и конфигурацией могут совместно использовать ключ сайта, но для БД и отчетов каждая машина должна иметь свой локальный ключ. При использовании Tripwire необходимо учитывать, что в ней используется метод проверки целостности, ориентированный на пакетную обработку, который предоставляет взломщику удобный момент для изменения файла после выполнения законного изменения и до следующей проверки целостности. Измененный файл будет помечен, что будет законно (поскольку стало известно, что файл изменен), и, вероятно, в качестве подтверждения законности его изменения будет сброшен флаг. Поэтому обновлять «снимки» Tripwire необходимо как можно чаще. Не выполнив этого, вы должны отметить точное время изменения файла, чтобы затем сравнить со временем изменения, указанным в отчете. Tripwire имеется в последних версиях Red Hat и FreeBSD. Однако если вы используете другую ОС, то придется скомпилировать ее из исходного программного кода. Загрузите из Сети пакет исходного кода и распакуйте его. После этого проверьте, имеется ли символическая ссылка из /usr/bin/gmake на /usr/bin/make. (Только в Linux всегда имеется make GNU. Tripwire явно ищет gmake, но в большинстве Linux-систем он называется просто make.) Если ее нет, создайте ее. Необходимо также проверить полный набор подкаталогов в /usr/share/man. Для помещения справочной системы (документации) Tripwire необходимы подкаталоги man4, тап5 и тап8. В тех системах, где их нет, установщик создаст файлы с именами этих каталогов, но не сможет создать каталоги, чтобы поместить в них соответствующие файлы. Например, вместо каталога /usr/man/man4, в который должны быть помещены необходимые страницы документации (manual pages),

284


будет создан файл с таким же именем. Теперь перейдите из рабочего каталога в корневой каталог исходного кода Tripwire (то есть в ./tripwire-2.3.1-2) и изучите файлы README и INSTALL Они небольшие, но очень важные. И наконец, перейдите в каталог src дерева исходного кода (то есть в ./tripwire2.3.1-2/src) и в файле src/Makefile выполните все необходимые изменения в определениях переменных. Убедитесь, что с соответствующего определения SYSPRE снят символ комментария (SYSPRE - i686-pc-linux или SYSPRE = sparc-linux и т. п.). Теперь можно выполнить компиляцию. Поскольку вы еще находитесь в каталоге src, введите следующую команду: $ make release После завершения компиляции запустите $ cd .. $ ср . / i n s t a l l / i n s t a l l . c f g . $ ср . / i n t a l l / i n s t a l l . s h Теперь откройте install.cfg в любимом текстовом редакторе для тонкой подстройки конфигурационных переменных. Поскольку пути по умолчанию, скорее всего, нам подойдут, необходимо проверить лишь раздел Mail Options, в котором изначально указывается, куда Tripwire должен направлять свои протоколы. Обратите внимание на то, что позже эти настройки можно изменить. Если вы установили TWMAILMETHOD=SENDMAIL и указали значение для TWMAILPROGRAM, то Tripwire будет использовать указанного почтового клиента (по умолчанию sendmai!) для доставки отчетов локальным пользователям или группам. Если вместо этого вы установили TWMAILMETHOD=SMTP и определили значения TWSMTPHOST и TWSMTPPORT, то Tripwire будет отправлять свои отчеты на внешний электронный адрес через указанные SMTP-сервер и SMTP-порт. После завершения редактирования install.cfg пора установить Tripwire. Находясь в каталоге исходного текста Tripwire, введите # sh ./install.sh У вас будут уточнены пароль сайта и локальный пароль: первый будет защищать конфигурационный файл и файл политики, а второй — БД и отчеты Tripwire. Это позволяет использовать одну политику для нескольких узлов, обеспечивая централизацию управления политикой Tripwire, но распределение ответственности за управление БД и генерацию отчета. Если Tripwire будет использоваться лишь на одном узле, то в качестве обоих паролей можно задать одинаковое строчное значение. В любом случае используйте надежную идентификационную фразу (passphrase), состоящую из сочетания строчных и прописных букв, знаков пунктуации (включая пробел) и цифр. При установке Tripwire (из пакета исполняемых файлов либо после самостоятельной компиляции) будет создан конфигурационный файл /etc/tripwire/tw.cfg. Его невозможно редактировать, поскольку он является зашифрованным двоич-

Трюк № 97. Проверка целостности файлов и поиск файлов

285

ным файлом, но для удобства в /etc/tripwire должна быть помещена открытая текстовая версия его содержимого — twcfg.txt. Если ее нет, то создать этот файл можно с помощью команды # twadmin --print-cfgfile > /etc/tripwire/twcfg.txt Отредактировав этот файл, можно внести изменения в настройки, использовавшиеся при установке Tripwire, а также изменить место, в котором Tripwire будет искать свою БД. Это делается с помощью переменной DBFILE. Интересным использованием является указание в этой переменной каталога, находящегося в каталоге /mnt. После этого, когда БД будет создана, вы можете скопировать ее на компакт-диск, а при необходимости проверить целостность и снова смонтировать его. После завершения редактирования конфигурационного файла его можно закодировать с помощью следующей команды: # twadmin --create-cfgfile --site-keyfile ./site.key twcfg.txt После этого необходимо удалить файл twcfg.txt. Инициализация БД Tripwire выполняется командой # tripwire --init Поскольку используется установленный по умолчанию файл политики, вероятно, появятся сообщения об ошибках, относящиеся к файлам и каталогам, которые не найдены. Это некритичные ошибки, и БД будет проинициализирована. Для того чтобы избавиться от этих ошибок, можно изменить политику и удалить файлы, которые считаются пропущенными. Сначала необходимо расшифровать файл политики в обычный текстовый формат. Для этого используется команда # twadmin --print-polfile > twpol.txt Далее пометьте как комментарий файлы, о которых сообщается как о пропущенных. Вероятно, придется посмотреть весь этот файл и определить, есть ли здесь файлы, которые вы хотели бы внести в список. Например, желательно проверять все SUID-файлы системы (см. трюк № 2). Язык файла политики Tripwire позволяет создавать более сложные конструкции, чем просто указание по одному файлу в строке. Дополнительную информацию об использовании некоторых особенностей можно найти в документации twpolicy(4) manpage. После изменения политики необходимо обновить БД Tripwire: # tripwire --update-policy twpol.txt Для проверки выполните команду # tripwire --check При этом на экран будет выведен отчет, копия которого будет помещена в /var/ lib/tripwire/report. Если необходимо, чтобы Tripwire автоматически отправлял отчет по электронной почте указанным в настройках получателям, добавьте

286


--email-report в конец команды. Просмотреть отчет можно с.помощью команды twprint, например: # twprint --print-report --twrfile \ /var/lib/tripwire/report/colossus-20040102-205528.twr И наконец, чтобы согласовать изменения, о которых сообщает Tripwire с помощью своей БД, запустите в отношении нее подобную команду: # tripwire --update --twrfile \ /var/lib/tripwire/report/colossus-20040102-205528.twr Для регулярности проверки можно запускать Tripwire по расписанию (с помощью планировщика задач). Помимо сохранения БД в безопасном месте, например на компакт-диске, можно создать резервные копии конфигурации, политики и ключей. В противном случае вы не сможете проверить целостность, если кто-либо (случайно или намеренно) удалит их. СМОТРИ ТАКЖЕ Дополнительную информацию можно найти в документации twpolicy (4) и в разделе «Using Tripwire» книги «Building Secure Servers with Linux», написанной Michael D. Bauer (издательство O'Reilly).

Поиск скомпрометированных пакетов с помощью RPM Проверьте установленные файлы операционной системы с помощью RPM-дистрибутива.

Предположим, что установлен факт взлома и необходимо разобраться, какие файлы (или все) были изменены взломщиком, но программа Tripwire не была задействована. Не все потеряно, если в качестве системы управления пакетами используется RPM. Не будучи столь мощным, как Tripwire, RPM может оказаться полезным для определения степени компрометации системы. RPM сохраняет МБ5-подписи для всех когда-либо установленных файлов. Можно использовать эту особенность для сверки пакетов на системе с БД их подписей. Помимо контрольных сумм MD5, также можно сравнить размер файла, пользователя, группу и время модификации со значениями, хранимыми в БД RPM. Для проверки одного пакета выполните rpm -V пакет

Если взломщик изменил какой-либо из двоичных файлов, то, скорее всего, одним из них будет файл ps. Давайте рассмотрим его подпись: # which ps /bin/ps # rpm -V >pm -qf /bin/psv S.5....T /bin/ps Здесь видно, что S, 5 и Т, соответствующие размеру файла, контрольной сумме и времени модификации файла, с момента установки были изменены — это

Трюк № 98. Поиск скомпрометированных пакетов с помощью RPM

287

очень плохо. Обратите внимание на то, что выводиться будет информация только о тех файлах, сведения в которых не соответствуют сведениям в БД пакетов. Если необходимо проверить все пакеты системы, можно использовать традиционный rpm-параметр -а, указывающий на все пакеты: # rpm -Va S.5....T /bin/ps S.5 Т с /etc/pam.d/system-auth S.5 Т с /etc/security/access.conf S.5 Т с /etc/pam.d/login S.5 Т с /etc/red/re.local S.5 T с /etc/sysconfig/pcmcia • Т с /etc/libuser.conf S.5....T с /etc/ldap.conf Т с /etc/mail/sendmail.cf S.5 T с /etc/sysconfig/fhn/up2date-uuid Т с /etc/yp.conf S.5....Т /usr/bin/md5sum .......Т с /etc/krb5.conf Существуют и другие параметры, которые могут быть использованы для ограничения проверяемых атрибутов файла. Наиболее полезными из них являются -nouser, -nogroup, -nomtime и -nomode. Они могут использоваться для подавления большого объема вывода, связанного с изменениями конфигурационных файлов. Обратите внимание на то, что, если границы проверки не сужены с помощью параметров командной строки, желательно перенаправить вывод в файл. Запуск rpm -Va безо всяких дополнительных параметров может вызвать вывод очень большого объема данных, связанных с изменениями конфигурационных файлов и пр. Все бы хорошо, но здесь не учитывается факт, что тот, кто скомпрометировал систему, может также скомпрометировать и БД RPM. В этом случае все равно можно использовать RPM, но, для того чтобы проверить установленные файлы, необходимо иметь файл и пакет, из которого он установлен. Наихудший сценарий событий — это когда скомпрометирован сам двоичный файл rpm. Однако сложно точно утверждать это, пока вы не загрузитесь из альтернативной среды. В этом случае для проверки пакетов необходимо найти безопасный двоичный файл rpm. Сначала найдите наименование пакета, к которому относится файл. Это можно сделать с помощью команды rpm -qf имя_файла После этого найдите местоположение пакета в дистрибутиве либо загрузите его из Интернета. А теперь сравните установленные файлы с информацией в пакете с помощью такой команды: rpm -Vp пакет файл

288


RPM может использоваться во множестве случаев, в том числе при проверке целостности системных файлов. Но не стоит полагаться только на эту систему. Вместо нее должны использоваться Tripwire (см. трюк № 97) или AIDE (http:// sourceforge.net/projects/aide).

Проверка наличия «набора суперпользователя» Используйте chkrootkit для определения степени компрометации системы.

Если имеется предположение, что система скомпрометирована, разумно проверить наличие так называемого набора суперпользователя (root kits), который может быть установлен злоумышленником. «Набор суперпользователя» — это комплект программ, которые обычно устанавливаются взломщиком, скомпрометировавшим учетную запись root. Эти программы помогают взломщику «замести следы», а также упростить в дальнейшем вход в систему. Для этого root kits иногда оставляют в системе запущенные процессы, что позволяет взломщику легко вернуться обратно без ведома администратора. Это означает, что некоторые системные двоичные файлы (такие, как ps, Is и netstat) должны быть модифицированы «набором суперпользователя» так, чтобы они не позволяли обнаруживать запущенные взломщиком процессы, обеспечивающие «тайный вход». К сожалению, «наборов суперпользователя» существует так много, что просто не хватит времени, чтобы распознать их и найти вручную. Сценарии, подобные chkrootkit (http://www.chkrootkit.org), сделают эту работу автоматически. Помимо определения до 50 различных «наборов суперпользователя», chkrootkit в состоянии обнаружить сетевые интерфейсы, находящиеся в «беспорядочном режиме», а также измененные lastlog- и wtmp-файлы. Эти файлы содержат дату и время регистрации пользователя в системе и выхода из нее, а если они изменены, то это свидетельствует о «работе» взломщика. Кроме того, chkrootkit выполняет проверки для обнаружения «наборов суперпользователя», основанных на модулях ядра. Эти проверки выполняются с помощью программы на языке С, вызываемой основным сценарием chkrootkit. Установить chkrootkit и периодически запускать его — не совсем правильный подход, поскольку злоумышленник может просто найти его и изменить таким образом, что сценарий не будет обнаруживать его присутствия. Лучше скомпилировать chkrootkit и поместить на съемный носитель. Для компиляции загрузите из Сети дистрибутив и распакуйте его, после чего перейдите в созданный каталог и введите make sense. Для запуска chkrootkit достаточно ввести ./chkrootkit в каталоге, в котором он скомпонован. После этого он будет выводить каждую выполненную проверку и ее результаты:

Трюк № 99. Проверка наличия «набора суперпользователя»

289

# ./chrootkit ROOTDIR is V Checking v amd'... not found Checking 'basename'... not infected Checking ' b i f f . . . not found Checking v c h f n ' . . . not infected Checking 'chsh 1 ... not infected Checking 4 c r o n ' . . . not infected Checking v d a t e ' . . . not infected Checking v d u ' . . . not infected Checking 4 dirname'... not infected Checking N echo'... not infected Checking N egrep'... not infected Checking 4 env'... not infected Checking v f i n d ' . . . not infected Checking 4 f i n g e r d ' . . . not found Checking N gpm'... not infected Checking 4 g r e p ' . . . not infected Checking v hdparm'... not infected Checking 4 s u ' . . . not infected

Это не интересно, поскольку машина еще не инфицирована. Chkrootkit можно запускать с дисков, смонтированных на другой машине; просто с помощью ключа -г укажите точку подключения для раздела, например: # ./chrootkit -г /mnt/hda2_image

Поскольку chkrootkit зависит от нескольких системных двоичных файлов, то перед запуском рассматриваемого сценария желательно проверить их (с помощью Tripwire (см. трюк № 97) или RPM (см. трюк № 98)). Этими двоичными файлами являются awk, cut, egrep, find, head, id, Is, netstat, ps, strings, sed и uname. Однако, если имеются надежные резервные копии, вы можете с помощью ключа -р просто указать путь к ним. Например, если вы скопировали файлы на CD-ROMдиск, а затем смонтировали его в /mnt/cdrom, можно воспользоваться следующей командой: # ./chrootkit -p /mnt/cdrom Можно добавить и другие пути, разделив их символом :. Вместо поддержки отдельной копии каждого из упомянутых двоичных файлов вы можете хранить статически скомпилированную копию BusyBox (http://www.busybox.net). BusyBox, предназначенная для встроенных систем, может выполнять функции более 200 распространенных двоичных файлов, что достигается использованием крошечного двоичного файла с символическими ссылками. Дискета, компакт-диск или USB-флеш-карта (с включенным переключателем «только для чтения») с chkrootkit и статической BusyBox могут оказаться быстрым и удобным средством проверки целостности системы.

290


Поиск владельца сети Отследите контакты сети с помощью БД WHOIS.

Просматривая протоколы IDS, можно заметить много странного трафика, поступающего из другой сети, подключенной через Интернет. При просмотре IP-адреса в DNS он разрешается как, например, dhcp-103.badguydomain.com. С кем связаться, чтобы он помог отследить человека, отправляющего такой трафик? Вероятно, вы уже знаете, что для нахождения контактной информации о владельцах доменных имен Интернета можно использовать команду whois. Если вы еще не пользовались ею, то просто введите whois1: $ whois badguydomain.com Registrant: Dewey Cheatum Registered through: GoDaddy.com Domain Name: BADGUYD0MAIN.COM Domain servers in listed order: PARK13.SECURESERVER.NET PARK14.SECURESERVER.NET For complete domain details go to: http://whoi s.godaddy.com К сожалению, эта запись whois не столь полезна, какой могла бы быть. Обычно здесь перечисляются контактные сведения об администраторах и технических службах, дополненные телефонными номерами и адресами электронной почты. Очевидно, что godaddy.com предоставляет эти сведения только по web-интерфейсу, чтобы избежать спама. Но если в качестве имени лица, зарегистрировавшего домен, указано Dewey Cheatum2, насколько верной является остальная информация о домене? Хотя при регистрации домена необходимо указывать достоверную информацию, могу сказать, по своему опыту, что использование whois помогает отследить лишь честных людей. Поскольку такой подход вам не помог, что еще можно сделать? Можно снова использовать whois, но для определения регистра номеров блока IP-адресов, в который входит «раздражающий» адрес. Регистры номеров — это элементы, с которыми должен зарегистрироваться владелец большого блока IP-адресов и которые должен разделить в соответствии с географическим местоположением. Основная сложность заключается в отборе для запроса верного регистра, но лучше всех справляется с этим WHOIS-сервер ARIN (American Registry for Internet Numbers) — он сообщит верный регистр, если IP-адрес не найден в его БД. 1

Буквальный перевод: «кто это»? Буквальный перевод: искаженное «наивный мошенник».

292


Здесь мы видим, что теперь имеется контактный телефон и электронный адрес. Скорее всего, это данные провайдера Интернета, которыми воспользовался злоумышленник. Теперь у вас есть контактная информация того, кто должен сказать, кто скрывается под именем badguydomajn.com. Вы можете известить его о наблюдаемом подозрительном трафике и разрешить ситуацию. Между прочим, при запросе некоторых новых TLD (таких, как .us, .biz, .info и т. п.) с помощью whois могут возникнуть проблемы. Одним из наиболее правильных вариантов автоматического поиска whois-сервера является использование whois-прокси на geektools.com. Он автоматически перенаправит запросы соответствующему whois-серверу, основываясь на запрашиваемом TLD. Я указываю в моем профиле .profile представленный далее псевдоним, чтобы всегда использовать прокси geektools.com: alias whois='whois -h whois.geektools.com1 Теперь, когда я запускаю whois из командной строки, мне не надо помнить адрес одного whois-сервера. Парни на geektools имеют и другие отличные средства, облегчающие работу системного администратора. Познакомьтесь с ними на http://geektools.com. Роб Фликипгер (Rob Flickenger)

Алфавитный указатель А Access control lists, 22 ACID, 238 ACL, 43, 73 ACL-мас'ка, 23 ARP, 83 ARP-запрос, 83 * effective UID, 35 Ethernet-анализаторы, 132 F FreeS/WAN, 191,203 • IDS-датчики, 265 M МАС-адрес, 83, 105 MySQL, 142 "• NIDS, 234 D

' PacketFilter, 90 РАМ, 54 PID, 32 Р root kit, 282 RPM-дистрибутив, 286

SSH-ключи, 206 SSL-сертификат, 123 SSL-шифрование, 213 stack-smashing attack, 41 sticky-разряд, 22 suEXEC-функционалыюсть, 136 j ТСР-дейтаграмма, 93 у VPN-доступ, 199 VTun, 217 w

web-интерфейс ACID, 239 SnortCcnter, 247 * автоматизированное создание политики, 52 автоматическая генерация файлов, 221 анализ IDS-событий, 241 атака SQL-инжекции, 272 кросс-сайтовых сценариев, 272 атаки переполнения буфера стека, 41 аудит включение, 71 настройка политик, 72 аудит сетевого трафика, 183

Б с SFS, 145 Sguil, 241 Snort препроцессор, 237 Snort_inline, 257 SOCKS 4, 211 SSH, 204 SSH-агент, 208

база данных политик безопасности, 191 безопасность BIND, 140 MySQL, 142 удаленных файловых систем, 145 безопасность web-приложений, 136 библиотека инжекции пакетов libnet, 235, 258

294 библиотечные вызовы, 49 блокировка ядра, 42 п временные файлы шифрование каталога, 76 мг „ вывод списка оперативных ресурсов, 69

г

, генерирование диаграмм, лпг 179 ^ ОО£гибкий отклик, 235

Д делегирование роли администратора, 27 динамическая фильтрация пакетов, 260 ' единый формат вывода, 267

Ж

Алфавитный указатель накопление статистики, 186 настройка IPsec в Linux, 191 в OpcnBSD, 197 во F r e e B S D >

1 9 4

u

л ОА

настройка почтового агента, 130

•обнаружение аномального поведения, rj -. __ обновление ОС Windows, 63 „ обновление правил Snort, 264 обобщение протоколов, 159 ограничение доступа, 79 ограниченные оболочки, 58 ограничение системных вызовов, 49 отказ по умолчанию, 105 отключение общих ресурсов, 75

263

П

журналы событий защита, 73 изменение размеров файлов, 73

«песочница», 35 побайтная копия диска, 280 подкачка 78

3

подключаемые модули идентификации, 54 поток программы, 41 предотвращение вторжении 1 , в web-приложения, 269 (лгл^ препроцессоры, 237 «приманка», 234, 277 приоритеты, 151 присоединение к программе, 53 проверка зашифрованной подписи, 29 проверка целостности файлов, 282 программа Argus, 183 Arpwatch, 84 Barnyard, 267 chkrootkit, 288 F p o r t JQ , ' ,ло ftester, 103

защита , о/ порта, 134 «с протоколов, 25 точек монтирования, 18 электронной почты, 127 И идентификаторы процессов, 32 искажение ARP-кэша, 83 исследование уязвимости, 20 исходящая фильтрация, 102 •# коммутатор, 132 концентратор, 132 кроссплатформная VPN, 226 мл крушение стека, 41 М межсетевой экран PacketFilter, 90 межсетевой экран Windows, 98 " • набор суперпользователя, 282, 288 надстройка вывода в БД, 237

grsecunty, 42 Handle, 68 HFNetChk, 64 honeyd, 274 httptunnel, 215 logwatch, 159 Nagios, 172 Nessus, 115

Алфавитный указатель программы (продолжение) netstat, 32 ' о хт Nmap, 108 ntopi

l g l

NTsyslog 153 Oinkmaster, 264 OpenVPN, 226 passwd, 20 proftpd, 38 грсара, 187 RRDtool, 179 Sebek, 278 .г, 1 л о / sniffdet, 134 о . 235 SnortSam 260 Spade, 263 Squid, 208 Stunnel, 213 sudo, 27 swatch, 161 syslogd, 150 критерии фильтрации, 151 1 лп, syslog-ng, 164 systrace, 49 Tripwire, 282 фильтрации IP chains 87 ipfw, 86 Netfilter, 87 просмотр открытых портов, 70 протокол РРТР, 199 протокол разрешения адресов, 83 протокол сетевого времени, 121 протоколирование, 149 событий протокола, 269 событии тревоги, 269 процессор правил, 253 псевдоним, Р разряд SGID, 20 SUID 20 регистр номеров, 290 регулярные выражения, 162 режим быстрой тревоги, 268

295 С оп связка ключей,о 30

сервер ключей, 30 сертификат полномочий, 123 символическая ссылка, 143 система обнаружения сетевого вторжения, 234 на основе аномалий, 234 на О С Н О ве подписи, 234 системный вызов, 49 < и* сканер безопасности, 115 сканирование нескольких систем, 67 сканирование удаленных компьютеров, 67 скомпрометированные файлы, 282 списки управления доступом, 22 спуфинг, 83 протокола разрешения адресов, 83 с т е к > 41 страничный файл, 78 ,оо ступень, 122 J У , удаленное наблюдение за сетью, 187 универсализация файловых имен, 160 У ч е т процессов, 168 ф файл подкачки очистка, 78 фильтрация МАС-адресов, 105 формат р^оп 9RQ Ц централизованное протоколирование, 150 циклическая БД, 179 Щ шифрование с помощью SSH, 204 шифрование каталога временных файлов, 76

Антихакинг в сети. Трюки

Recommend Documents