Книга
← К списку книгЗагрузка разделов…
активнаАктивные записи участвуют в каталоге и синках. Неактивная книга скрыта, но не удалена из базы.
Книга
Глава 1. Защита узлаUnix18
Глава 2. Безопасность узла Windows . . .63
Глава 3. Сетевая безопасность82
Глава 4. Протоколирование149
Глава 5. Наблюдение и выявление тенденций171
Глава 6. Защита каналов191
Глава 7. Обнаружение сетевого зторжения234
Глава 8. Восстановление и ответные действия280
Алфавитный указатель293
Содержание
Об авторе10
Соавторы10
Благодарности11
Вступление13
Почему книга называется «Антихакинг в сети. Трюки»?13
Структура книги14
Соглашения, используемые в этойкниге15
Использование материалов книги16
Как связаться с автором16
От издательства17
Глава 1. Защита узла Unix18
Трюк № 1. Защита точек монтирования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
Трюк №11 . Использование proftp с MySQL38
Трюк № 12. Предотвращение атак, направленных на повреждениестека ... 41
Трюк № 13. Блокировка ядра с помощью grsecurlty42
Трюк № 14. Ограничение приложений с помощью grsecurlty46
Трюк № 15. Ограничение системных вызовов с помощью Systrace49
Трюк № 16. Автоматизированное создание политики Systrace52
Трюк № 17. Управление доступом с помощью РАМ54
Трюк № 18. Среда ограниченной оболочки58
Трюк № 19. Ограничение ресурсов пользователя и группы60
Трюк № 20. Автоматизация обновления системы . . .61
Глава 2. Безопасность узла Windows63
Трюк №21 . Проверка серверов и используемых обновлений63
Трюк № 22. Получение списка отк эытых файлов и владеющих ими процессов 68
Трюк №23. Список запущенных служб и открытых портов70
Трюк № 24. Включение аудита71
Трюк №25. Защита журналов событий73
Трюк №26. Изменение максимальных размеров файлов протоколов73
Трюк №27. Отключение стандартных общих ресурсов 75
Трюк № 28. Зашифровывание папки Temp76
Трюк № 29. Очистка файла подкачки при отключении77
Трюк № 30. Ограничение доступа пользователя к приложениям79
Глава 3. Сетевая безопасность82
Трюк №31 . Обнаружение ARP-спуфинга82
Трюк №32. Создайте статическую ARP-таблицу85
Трюк № 33. Межсетевой экран Netfilter86
Трюк №34. Межсетевой экран PaoketFilter ОС OpenBSD90
Трюк № 35. Создание шлюза с проверкой полномочий96
Трюк №36. Межсетевой экран в Windows98
Трюк № 37. Держите сеть изолированной102
Трюк № 38. Проверьте ваш межсетевой экран103
Трюк № 39. МАС-фильтрация с помощью Netfilter105
Трюк №40. Блокировка «снятия отпечатков пальцев» ОС107
Трюк №41 . Обман программ удаленного определения ОС109
Трюк №42. Ведите учет объектов сети113
Трюк № 43. Проверка надежности сети115
Трюк №44. Синхронизация серверных часов121
Трюк № 45. Создание собственного сертификата полномочий123
Трюк № 46. Распространение СА среди клиентов126
Трюк №47. Шифрование IMAP и POP с помощью SSL127
Трюк №48. Настройка SMTP с TLS129
Трюк № 49. Удаленное обнаружение Ethernet-анализатора. 132
Трюк №50. Установка Apache с S3L и suEXEC136
Трюк №51. Защитите BIND140
Трюк № 52. Безопасность MySQL142
Трюк № 53. SFS в Unix145
Глава 4. Протоколирование149
Трюк № 54. Запуск централизованного syslog-сервера149
Трюк № 55. Управление syslog151
Трюк № 56. Интеграция Windows в инфраструктуру syslog153
Трюк № 57. Автоматическое обобщение протоколов159
Трюк №58. Автоматическое наблюдение за протоколами161
Трюк № 59. Обобщение протоколов с удаленных сайтов163
Трюк № 60. Протоколирование деятельности пользователя за счет учета процессов168
Глава 5. Наблюдение и выявление тенденций171
Трюк №61 . Наблюдение за работоспособностью. 172
Трюк №62. Графическое изображение тенденций179
Трюк № 63. Использование ntop для получения статистики работы сети в реальном масштабе времени181
Трюк №64. Аудит сетевого трафика.183
Трюк № 65. Накопление статистики с помощью правил межсетевого экрана . 186
Трюк № 66. Удаленный анализ187
Глава6.Защитаканалов191
Трюк №67. Настройка IPsec в ОС Linux191
Трюк №68. Настройка IPsec в ОС FreeBSD194
Трюк №69. Настройка IPsec в ОС OpenBSD197
Трюк № 70. Организация канала РРТР199
Трюк №71 . Адаптивное шифрование с помощью FreeS/WAN203
Трюк №72. Перенаправление и шифрование трафика с помощью SSH . . . 204
Трюк № 73. Быстрая регистрация в системе с помощью ключей SSH-клиента 206
Трюк № 74. Squid-прокси по SSH208
Трюк №75. Использование SSH в качестве SOCKS-прокси210
Трюк №76. Шифрование и создание канала для трафика с помощью SSL . . 213
Трюк № 77. Канальные соединения внутри HTTP215
Трюк №78. Создание канала с помощью VTun и SSH217
Трюк №79. Автоматический генератор vtund.conf221
Трюк № 80. Создание кроссплатформной VPN .226
Трюк №81 . Канал РРР231
Глава7.Обнаружениесетевоговторжения234
Трюк № 82. Обнаружение вторжения с помощью Snort234
Трюк № 83. Отслеживайте сигналы тревоги238
Трюк № 84. Наблюдение в реальном режиме времени241
Трюк № 85. Управление датчиками247
Трюк № 86. Создание собственных правил Snort253
Трюк № 87. Предотвращение и сдерживание вторжений с помощью Snortjnline257
Трюк № 88. Автоматизированная динамическая фильтрация пакетов с помощью SnortSam260
Трюк № 89. Обнаружение аномального поведения263
Трюк № 90. Автоматическое обновление правил Snort264
Трюк №91 . Создайте сеть распределенных датчиков-невидимок265
Трюк № 92. Использование Snort в высокопроизводительной среде с Barnyard, 267
Трюк № 93. Обнаружение и предотвращение вторжений в web-приложения 269
Трюк № 94. Имитация сети с уязвимыми узлами274
Трюк № 95. Запись деятельности «приманки»277
Глава8. Восстановление и ответные действия280
Трюк № 96. Образ смонтированной файловой системы280
Трюк № 97. Проверка целостности файлов и поиск скомпрометированных файлов282
Трюк №98. Поиск скомпрометированных пакетов с помощью RPM 286
Трюк № 99. Проверка наличия «набора суперпользователя»288
Трюк № 100. Поиск владельца сети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), участвующий также в поддержке сайта Turk- PHP.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.
Роб Фликингер (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) за одобрение, поддержку и понимание, высказанные ею в ходе написания мной этой книги. Без нее я томился бы в унынии и вряд ли смог завершить свой труд.
Мне хотелось бы поблагодарить Нэта Торкингтона (Nat Torkington), который свел меня с Робом, неустрашимым (и настойчивым) редактором этой книги, а также моих родителей, которые верили в меня и позволяли в детстве разбираться с компьютерами и делать разные глупости, например читать журнал «Phrack»1. Если бы не это, возможно, я сейчас занимался бы чем-то совершенно иным.
Популярный журнал хакерской направленности (компьютеры и телефония). 17 ноября 2005 года ему исполнится 20 лет.
Вступление
Нигде понятие «хакер» не истолковывается так неверно, как в сфере сетевой безопасности. И это понятно, поскольку специалисты по сетевой безопасности для проверки надежности своих сетей используют те же инструменты, которые могут применяться для запуска атаки на любую машину в Интернете. Разница между проверкой, законно проводимой системным администратором в отношении собственных машин, и взломом системы, направленным на получение несанкционированного доступа, определяется по большей части не методиками или инструментами, а преследуемой целью. Как и любая мощная часть технологии, средства безопасности по своей сути не являются «плохими» или «хорошими» — это всецело зависит от того, как они используются. Любой молоток может использоваться и для строительства стен, и для их разборки.
Разница между «плохими» и «хорошими» хакерами также заключается не в средствах и технологиях, которые они используют, а в их намерениях. Разница едва различима, но очень важна. «Хорошие» хакеры выясняют, что представляет собой существующая система безопасности, и делают это с исследовательскими целями, чтобы знать, как можно разрушить такие системы. «Плохие» хакеры (более точно называемые кракерами (взломщиками)) преследуют цель получить те же знания, не уважая труд людей, которые построили эти системы или атакуемые серверы. Они используют полученные знания для разрушения этих систем с личными целями, зачастую с ущербом для систем, в которые им удалось проникнуть.
Конечно же, книги об отважных технограбителях международного масштаба или прокуренных гениях с ноутбуками продаются лучше, чем книги об инженерах, обеспечивающих безопасность сетей. Поэтому понятие «хакерство» имеет в популярной прессе негативную репутацию. Так называют людей, которые взламывают системы или наносят им вред, используя компьютер в качестве оружия. Однако среди людей, занимающихся решением проблем компьютерной безопасности, понятие «взлом» используется в качестве названия быстрого «чернового» либо искусного способа их решения. Понятие «хакер» используется как комплимент при обращении к творческой личности, имеющей техническую хватку, позволяющую выполнить любую задачу в компьютерной области.
Почему книга называется «Антихакинг в сети. Трюки»?
В этой книге описываются около ста мощнейших методик обеспечения безопасности. Здесь демонстрируются эффективные методы защиты серверов и сетей от искусных обходных атак. В издании приведены примеры обнаружения присутствия сетевых «злоумышленников», методы защиты ваших сетей и данных на
основе шифров с высокой криптоустойчивостью и даже методики закладки «ловушек» для потенциальных кракеров. Мы рассмотрим наиболее важные инструменты защиты, а также оптимальные методы их использования для обнаружения реальной полезной информации о том, что происходит в сети.
Структура книги
Хотя каждый взлом индивидуален и не похож на другой, эта книга обобщает их различные варианты, используя перекрестные ссылки. Если вы найдете ссылку на что-либо интересное при обсуждении одного варианта взлома, то можете спокойно пропустить его и перейти к другому (так же как при серфинге в Интернете). Книга разделена на несколько глав, в которых рассматриваются следующие вопросы:
Глава 1. Защита узла Unix. Как известно, ОС Unix была предназначена для совместного использования информации, но не для ее защиты. Сейчас, когда в современных операционных системах средства защиты информации интегрируются непосредственно в любой сервер, эта старая истина больше не верна. Были разработаны новые функции программ и ядра, обеспечивающие более высокую степень контроля, чем обеспечивали Unix-подобные операционные системы. В первой главе демонстрируются передовые технологии повышения «прочности» Linux-, FreeBSD- и OpenBSD-серверов.
Глава 2. Безопасность узла Windows. Операционная система Windows используется в качестве серверной платформы в большинстве организаций. А поскольку именно она является основным объектом атак, администрирование таких систем может потребовать больших усилий. Эта глава охватывает множество моментов, упускаемых администраторами Windows, в частности ужесточение разрешений, аудит деятельности всех систем и исключение «дыр» в системе безопасности, имеющихся при стандартной установке Windows.
Глава 3. Сетевая безопасность. Независимо от установленной на сервере операционной системы, при подключении сети к Интернету в качестве связного используется протокол TCP/IP. Сетевые протоколы могут быть взломаны несколькими мощными и необычными способами, что приводит к возникновению широкого спектра проблем — от простого отказа в обслуживании до несанкционированного доступа со всеми привилегиями. В этой главе продемонстрированы некоторые средства и методики, используемые для атак на серверы средствами самой сети, а также методы предотвращения этих атак.
Глава 4. Протоколирование. Администраторы сетевой безопасности полностью зависят от качества протоколирования. При недостаточном объеме протоколирования вторжение может остаться незамеченным. При чрезмерном протоколировании атаки могут затеряться в потоке бесполезной информации. В четвертой главе показано, как обеспечить баланс информации, обеспечивающей все потребности администратора, за счет автоматического сбора, обработки и защиты системных журналов.
1515Соглашения, используемые в этой книге
15
15
Глава 5. Наблюдение и выявление тенденций. Несмотря на полезность протоколирования событий системы и сканирования сети, они представляют один из результатов обработки информации, относящийся только к моменту, в который была произведена запись. Без хронологического исследования функционирования сети невозможно определить базис, относительно которого определяется, что является нормой, а какие действия вызывают сомнение. В этой главе представлен ряд инструментов и методов наблюдения за сетью и службами в течение длительного времени. Такое наблюдение позволяет изучить тенденции, которые помогут в перспективном планировании и позволят навскидку сказать: «Что-то не так».
Глава 6. Защита каналов. Как можно обеспечить безопасность связи по такому ненадежному (в плане защиты информации) каналу, как Интернет? Ответ на этот вопрос всецело зависит от методик криптоустойчивого шифрования и проверки полномочий. В этой главе вы узнаете, как реализовать мощные VPN-технологии, включая IPSec, PPTP и OpenVPN. Здесь также представлены технологии таких служб защиты, как SSL, SSH, и другие средства устойчивого кодирования.
Глава 7. Обнаружение сетевого вторжения. Как узнать, что в какой-то момент ваша сеть подвергается атаке? В то время как протоколирование событий и хронологическая статистика позволяют увидеть, что произошло что-то неординарное, существуют средства, предназначенные для оповещения (либо выполнения ответного действия) сразу при обнаружении атаки. Данная глава посвящена очень популярному инструменту NIDS tool Snort и представляет множество методик и надстроек, раскрывающих весь потенциал этого средства. Здесь вы также найдете способы настройки собственной «honeypot»-ce™ для привлечения и введения в заблуждение взломщиков системы.
Глава 8. Восстановление и ответные действия. Даже самый компетентный и внимательный администратор иногда может столкнуться с фактом проникновения в систему. Эта глава содержит предложения по проверке целостности системы, сохранения улик для последующего анализа и выслеживания лица, отсылающего нежелательный сетевой трафик.
Соглашения, используемые в этой книге
В этой книге используются следующие типографские соглашения.
КурсивТак выделяются новые понятия
Моноширинный шрифтМоноширинный шрифтМоноширинный полужирный шрифтМоноширинный полужирный шрифтИспользуется для выделения команд, параметров, ключей, пере- менных,атрибутов, клавиш,функций,типов,классов, пространств имен, методов, модулей, свойств, значений, объектов, событий, обработчиков событий, XML- и HTML-тегов, URL, адресов электронной почты, имен файлов, расширений файлов, путей, каталогов, демонов, программ и Unix-утилитмакросов, содержимого файлов или выходных результатов выполнения команд
Моноширинный шрифт
Моноширинный шрифт
Моноширинный полужирный шрифт
Моноширинный полужирный шрифт
Представлен текст, который должен быть заменен пользовательскими параметрами
Использование материалов книги
Эта книга призвана помочь вам выполнить свою работу. В общем случае представленный в книге программный код можно использовать в ваших программах или документации. Нет необходимости связываться с нами для получения разрешения, за исключением тех случаев, когда вы воспроизводите значительную часть кода. Например, написание программы, использующей несколько фрагментов кода, приведенного в этой книге, разрешения не требует. Продажа или иное распространение примеров — только с нашего разрешения. Ответ на вопросы путем цитирования выдержек из книги или примеров разрешения не требует. Включение значительной части текста этой книги в вашу документацию требует нашего разрешения.
Мы не настаиваем на указании авторства, но будем благодарны за это. Указание авторства обычно состоит в приведении заголовка, сведений об авторе, издателе и ISBN-кода, например: «Network Security Hacks by Andrew Lockhart. Copyright 2004 O'Reilly Media, Inc., 0-596-00643-8».
Если предполагается и дальнейшее использование примеров этой книги за пределами представленных здесь полномочий, не постесняйтесь связаться с нами по электронной почте: permissions@oreilly.com.
Как связаться с автором
Ваши комментарии и вопросы, касающиеся данной книги, направляйте по адресу издателя:
O'Reilly & Associates
1005 Gravenstein Highway North
Sebastopol, CA 95472
998-9938 (в США или Канаде)
829-0515 (для международной или местной связи)
829-0104 (факс)
Этой книге посвящен web-сайт, содержащий список опечаток1 и дополнительную информацию. Этот сайт расположен по адресу:
http://www.oreilly.com/catalog/netsechacks
Комментарии и вопросы, касающиеся технической стороны, направляйте по адресу:
bookquestions@oreilly.com
Дополнительную информацию о книгах, конференциях, исследовательских центрах и сети O'Reilly Network вы можете найти на сайте:
Список опечаток в оригинальном издании. — Примеч. ред.
От издательства17
http://www.oreilly.com
Загорелись взломом? Для изучения всех книг серии «Hacks books» в онлайновом режиме или для содействия в разработке будущих тем посетите адрес:
http://hacks.oreilly.com
От издательства
Ваши замечания, предложения и вопросы отправляйте по адресу электронной почты comp@piter.com (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
Подробную информацию о наших книгах вы найдете на web-сайте издательства:
http://www.piter.com.
ГЛАВА
Защита узла Unix
Трюки Ns 1-20
Понятие «работа в сети» относится ко всему, что соединяет компьютеры, поэтому компьютерная сеть не может быть более защищенной, чем компьютеры, входящие в нее. Один ненадежный узел может доставить множество проблем всей сети, поскольку если он находится под контролем противника, то может действовать как инструмент разведки либо являться плацдармом для атак. Межсетевые экраны (брандмауэры), определение вторжения и другие расширенные мероприятия защиты бесполезны, если ваши серверы представляют собой легко компрометируемые сервисы (службы). Прежде чем перейти к обеспечению безопасности, относящейся к сетевой части, сначала необходимо гарантировать, что машины, за которые вы отвечаете, максимально защищены.
Эта глава предлагает множество способов сокращения рисков, связанных со службами Unix-системы. И хотя каждый из рассматриваемых трюков индивидуален, было бы желательно прочитать всю главу целиком. Если вы реализуете мероприятия защиты лишь одного типа, то в конце концов придете к тому, что вся ваша подготовка будет полностью низвергнута, как только атакующий поймет, как ее обойти. Как и Форт Нокс1, который не может быть защищен просто дверью с обычным засовом, так и одна функция защиты не сможет полностью защитить ваши серверы. Количество необходимых средств защиты должно возрастать пропорционально ценности того, что необходимо защитить.
Как гласит старая поговорка: «Защита — это не имя существительное, это — глагол». Защита — это активный процесс, который должен вестись непрерывно и постоянно совершенствоваться. Защитить машину одним действием можно, лишь отключив ее. Учитывая это, рассматривайте предлагаемые технологии как начальный этап построения защищенного сервера, удовлетворяющего вашим потребностям.
Защита точек монтирования
Используйте параметры команды mount, чтобы не увеличивать риск появления незваных гостей.
Основной способ взаимодействия с Unix-машиной — через файловую систему. Следовательно, когда нарушитель получил доступ к системе, желательно ограничить его возможности оперировать доступными ему файлами. Одним из
Один из крупнейших военных гарнизонов армии США.
способов достичь этого является использование ограничивающих параметров монтирования.
Параметр команды 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.
Обратите внимание на то, что работа служб, запущенных в окружении chrootO (трюк № 10), может быть нарушена, если параметр nodev указан для файловой системы, запущенной под chroot. Вот почему узлы устройств, такие как /dev/log и /dev/null, должны быть доступны в окружении chroot().
Существует несколько способов, с помощью которых взломщик все же может обойти ограничения монтирования. Например, параметр поехес в операционной системе (ОС) Linux может быть не охвачен использованием /lib/ld-linux.so для выполнения двоичных файлов, находящихся в таких файловых системах. На первый взгляд кажется, что такое поведение можно исправить, сделав Id-linux.so неисполняемым, но из-за этого неисполняемыми станут все динамически подключаемые двоичные файлы. Поэтому если только все программы, на которые вы полагаетесь, являются статически подключаемыми (что, вероятно, не так), то параметр поехес малопригоден в Linux. Помимо этого, взломщик, который уже обладает root-привилегиями, без труда справится с файловыми системами, смонтированными со специальными параметрами, поскольку зачастую он сразу же сможет их перемонтировать командой remount с параметром -о. Но за счет использования флагов монтирования вы можете легко ограничить возможности атак, доступных недружелюбному пользователю, пока он не получил привилегии корневого каталога.
ТРЮКMs 2ТРЮКMs 2Сканирование SUID- и SGlD-программ
ТРЮК
Ms 2
ТРЮК
Ms 2
Быстрая проверка на наличие программ-лазеек и программ, исследующих корневой каталог.
Потенциальным способом для пользователя повысить уровень привилегий в системе является исследование уязвимости 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-файлы могут быть использованы для быстрого и простого повышения привилегий пользователя.
Кроме того, взломщик, который уже получил 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:
$ file /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 &&
diff /var/log/sidlog.new /var/log/sidlog &&
mv /var/log/sidlog.new /var/log/sidlog
В этом примере текущий список SUID- и SGID-файлов сохраняется в /var/log/sidlog.
ТРЮК№3ТРЮК№3Сканирование World-
ТРЮК№3
ТРЮК№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ТРЮК№4Создание гибких иерархий разрешений с использованием ACL
ТРЮК№4
ТРЮК№4
Когда Unix-разрешений не хватает, используйте ACL.
Практически всегда традиционная для Unix система файловых разрешений в полной мере удовлетворяет всем требованиям безопасности. Но в среде с обширными связями, где доступ к файлам должно получать множество людей, эта схема может стать неуклюжей. Списки управления доступом (Access control lists, ACL) (иногда называемые «аклес») — это относительно новая функция операционной системы Linux, с некоторых пор доступная также в ОС FreeBSD и Solaris. Хотя ACL не обладают наследственной способностью добавлять безопасность системе,
они снижают сложность управления разрешениями. 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:
$ touch myfile
$ Is -1 myfile
-rw-rw-r-- 1 andrew andrew0 Oct 13 15:57 myfile
$ setfacl -m u::---,g::---.o:--- myfile
$ Is -1 myfile
- 1andrew andrew0 Oct 13 15:57 myfile
Данный пример показывает, что можно перечислить несколько ACL, разделив их запятыми. Кроме того, можно указывать ACL для произвольного числа пользователей и групп: $ touch foo $ setfacl -m u:jlope:rwx.g:wine:rwx ,o:--- foo $ getfacl foo # file: foo # owner: andrew # group: andrew user::rw- user;jlope:rwx group::--- group:wine:rwx mask::rwx other::---
Теперь если изменить маску на г--, то ACL для jlope и wine получат атрибут г--: $ setfacl -m m:r-- foo $ getfacl foo # file: foo # owner: andrew # group: andrew user;:rw- user:jlope:rwx#effective:r--
group::--- group:wine:rwx#effective:r--
mask:: T’other: :---
Как упоминалось ранее, каталоги могут иметь стандартные ACL (ACL по умолчанию), которые автоматически применяются к файлам, созданным в этом каталоге. Стандартные ACL устанавливаются присоединением d: к ACL, который вы хотите настроить: $ mkdir mydir $ setfacl -m d:u:jlope:rwx mydir $ getfacl mydir # file: mydir # owner: andrew # group: andrew user::rwx group:: — other::--- default:user::rwx defaul t:user:jl ope:rwx default-.group::--- defaul t:mask::rwx default:other::--- $ touch mydir/bar
$ getfacl mydir/bar
file: mydir/bar
owner: andrew
group: andrew
user::rw-
user:jlope:rwx#effective:rw-
group::---
mask::rw-
other::---
Как можно заметить, список ACL можно получить с помощью команды getfacl. Эта команда очень проста и имеет лишь несколько параметров. Наиболее полезным является параметр -R, который рекурсивно выводит ACL и работает практически так же, как Is -R.
ТРЮК№5ТРЮК№5Защита протоколов от посторонних
ТРЮК
№5
ТРЮК
№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 +а имя_файла
В 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 file
26Глава 1. Защита узла Unix
В 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 file
Очевидно, что взломщик, уже получивший 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, а вторая —
необходимо убедиться, что удаление мандатов в общем порядке загрузки выполняется позже. После того как 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.
Синтаксис строки 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 на любой машине в качестве любого пользователя.
И в заключение отметим, что 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)
ТРЮК№7ТРЮК№7Автоматизация проверки зашифрованной подписи
ТРЮК
№7
ТРЮК
№7
Используйте сценарии и сервер ключей для автоматизации рутинной работы по проверке подлинности программного обеспечения.
Один из основных моментов обеспечения безопасности вашей системы — ознакомление с устанавливаемым программным обеспечением. Как правило, для внимательного изучения исходного кода всего устанавливаемого программного обеспечения не хватает времени, знаний или ресурсов. Однако проверка того, что компилируемые и устанавливаемые программы — это именно то, что подразумевал их автор, может занять много времени, которое расходуется на предотвращение широкомасштабного распространения «троянских коней». Ряд главнейших программных продуктов (tcpdump, LibPCap, Sendmail и OpenSSH) имеет версии, хотя и редко встречающиеся, содержащие «троянов». Поскольку это одно из популярных направлений атак, проверка их наличия в программном обеспечении является критически важной. Почему это является проблемой? К несчастью, проверка программы перед установкой требует лишь небольших усилий. То ли из-за лени, то ли по невежеству многие системные администраторы упускают этот критический этап. Это является классическим примером «ложной» лени, которая впоследствии может привести к необходимости выполнять значительно больший объем работ. Решить эту проблему очень сложно, поскольку это требует совместной работы программистов и распространителей. Кроме того, лень мешает и здесь: длительное время программные продукты вообще не имели подписи, позволяющей проверить загруженный программный код. Зачастую подписи доступны вместе с исходным кодом, но для проверки последнего необходимо отыскать на сайте открытый ключ, используемый для создания подписи. После нахождения открытого ключа его необходимо загрузить, проверить подлинность, добавить его в «связку ключей» и затем проверить подпись программного кода.
Вот как выглядит проверка подписи 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 <jim@zend.com>"
gpg:aka "Jim Jagielski <jim@apache.org>"
gpg:aka "Jim Jagielski <jim@jaguNET.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:There iss 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$22>&1 | grep'keyID1|awk'{print$NF}1N"
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). Третья строка пытается (в данном случае — неудачно) проверить подпись, не
проконсультировавшись с сервером ключей. Далее 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 fPDT using DSA key ID 08C975E5
gpg: Good signature from "Jim Jagielski <jim@zend.com>"
gpg:aka "Jim Jagielski <jim@apache.org>"
gpg:aka "Jim Jagielski <jim@jaguNET.com>"
gpg: checking the trustdb
gpg: no ultimately trusted keys found
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
С помощью этого маленького и простого сценария сокращается как количество выполняемых шагов, так и необходимое для их выполнения время. Использование сценариев должно помочь вам быть ленивым в хорошем смысле: выполнять больше работы, но с меньшими усилиями.
ТРЮК№8ТРЮК№8Проверка наличия «слушающих» служб
ТРЮК№8
ТРЮК№8
Найдите ненужные службы-«слушатели» и возможные «потайные двери» в систему.
Сразу после установки свежей операционной системы необходимо проверить запущенные службы и удалить из процесса загрузки все ненужные службы. Можно использовать сканер портов (такой, как nmap (трюк № 42)) и запустить его для проверки узла, но если его нет, то вам придется подключить свою свежую (и, вероятно, незащищенную) машину к сети и загрузить сканер портов. Кроме того, необходимо учитывать, что nmap может быть обманут, если система использует правила межсетевого экрана (firewall). Если установлены четкие правила, служба может остаться совершенно незаметной для nmap, пока совпадает какое-либо условие (например, IP-адрес). Когда имеется доступ к самому ядру сервера, вероятно, более эффективным будет найти открытые порты с помощью
программ, установленных вместе с операционной системой. Одной из них является netstat — программа, выводящая сведения и статистику, относящуюся к работе сети.
Для получения списка «слушающих» портов и связанных с ними процессов под Linux выполните:
netstat -luntp
Active Internet connections (only servers)
Proto Recv-QSend-QLocal AddressForeign AddressStatePID/Program name
tcp 000.0.0.0:220.0.0.0:*LISTEN1679/sshd
udp 000.0.0.0:680.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 *.* I LISTEN
tcp4 0 0 *.53 *.* LISTEN
В столбце локального адреса снова перечислены используемые порты. Многие опытные системные администраторы помнят распространенные номера портов популярных служб и видят, что на этом сервере запущены SSH-, SMTP-, DNS-, IMAP- и IMAP+SSL-службы. Если вы все же сомневаетесь, какая служба обычно запускается на данном порте, то либо исключите ключ -п из команды netstat (он заставляет эту утилиту использовать имена, но при просмотре DNS-адресов выполнение может занять значительно больше времени), либо вручную просмотрите файл /etc/services:
grep -w 993 /etc/servicesimaps993/udp# imap4 protocol over TLS/SSL
imaps993/tcp # imap4 protocol over TLS/SSL
Обратите также внимание на то, что, в отличие от результата выполнения netstat в Linux, мы не получаем PID самих демонов. Помимо этого не перечислены UDP-порты для DNS. Для вывода UDP-сокетов необходимо в аргумент egrep добавить udp4, придав ему следующий вид: 'Proto|LISTEN|udp4'. Однако
из-за особенностей работы UDP не все UDP-сокеты обязательно будут связаны с процессами-демонами.
В ОС FreeBSD существует другая команда, позволяющая получить необходимые сведения. Команда sockstat выполняет только малую часть того, что «умеет» netstat, и предоставляет сведения только о доменных сокетах Unix и Интернет-сокетах. Для получения списка «слушающих» портов и связанных с ними процессов запустите команду
# sockstat -4 -1
USER
COMMAND
PID
FD PROTO
LOCAL ADDRESS
FOREIGN ADDRESS
root
sendmail
1141
4 tcp4
*:25
*.*
root
sendmail
1141
5 tcp4
*:587
*.*
root
sshd
1138
3 tcp4
*:22
*. *
root
inetd
1133
4 tcp4
*:143
*.*
root •
inetd
1133
5 tcp4
*:993
*.*
named
named
1127
20 tcp4
*:53
*.*
named
named
1127
21 udp4
*:53
*. *
named
named
1127
22 udp4
*;1351
*. *
И опять же видно, что запущены 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
NAME
named
1127
named
20u
IPv4
0xeb401dc0
oto
TCP
*:domain (LISTEN)
inetd
1133
root
4u
IPv4
0xeb401ba0
oto
TCP
*:imap (LISTEN)
inetd
1133
root
5u
IPv4
0xeb401980
oto
TCP
*:imaps (LISTEN)
sshd
1138
root
3u
IPv4
0xeb401760
oto
TCP
*:ssh (LISTEN)
sendmail
1141
root
• 4u
IPv4
0xeb41b7e0
oto
TCP
*:smtp (LISTEN)
sendmail
1141
root
5u
IPv4
0xeb438fa0
oto
TCP
A-submission (LISTEN)
Для вывода UDP-сокетов можно изменить аргумент egrep. Однако на этот раз вместо udp4 нужно использовать уточнение UDP, и аргумент примет следующий вид: C'OMMAND| LISTEN |UDP'. Как упоминалось ранее, не все UDP-сокеты обязательно будут связаны с процессами-демонами.
Предотвращение привязки службы к интерфейсу
Пускай служба не «слушает» порт, а выполняет на нем функции межсетевого экрана.
Иногда может возникнуть желание ограничить службу прослушиванием только определенного интерфейса. Например, Apache (трюк № 50) может быть настроен на прослушивание не всех доступных интерфейсов, а только определенного интерфейса. Этого можно добиться также с помощью директивы Listen, помещаемой в файл настройки с указанием IP-адреса интерфейса:
Listen 192.168.0.23:80
При использовании элементов Virtual Host интерфейсы привязки можно указывать на основе виртуальных узлов:
<VirtualHost 192.168.0.23>
</VirtualHost>
У вас даже могут быть службы, которые «слушают» 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
После этого просто добавьте в конец строки -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 теперь никто не должен слушать.
ТРЮКNs 10ТРЮКNs 10Ограничение службы с помощью окружения «песочницы»
ТРЮК
Ns 10
ТРЮК
Ns 10
Ограничьте возможное повреждение системы, изолировав службы.
Иногда своевременной установки новейших обновлений недостаточно для предотвращения проникновения в систему. Зачастую новый способ прорыва долго циркулирует в частных кругах, до того как будет издано его официальное обновление. В течение этого времени ваши серверы остаются открытыми перед неожиданной атакой. Учитывая это, разумно принять превентивные меры по смягчению возможных последствий деятельности скомпрометированной службы. Один из способов достичь этого — запуск службы в окружении «песочницы» (sandbox environment). В идеальном случае скомпрометированная служба нанесет минимальный вред производительности системы.
Большинство систем, использующих Unix и Unix-подобные ОС, включают определенный тип системного вызова или иной механизм организации «песочницы», предлагающий различные уровни изоляции между узлом и этой «песочницей». Менее сдерживающей и простой в настройке является среда, создаваемая командой chrootC), которая доступна практически во всех Unix-подобных ОС. Помимо chrootC), ОС FreeBSD включает еще один механизм, называемый jail О, который имеет больше ограничений.
С помощью команды chrootO очень легко меняется корневой каталог процесса и всех его наследников. Несмотря на то что это очень мощная функция, существует множество противопоказаний для ее использования. Самое главное: у всего, что исполняется в «песочнице», не должно быть возможности изменить свой EUID (effective UID) на 0, соответствующий UID корневого каталога. Естественно, это подразумевает, что вы не собираетесь запускать в «тюрьме» ничего от
имени root. Если атакующий получит root-полномочия в «песочнице», то все усилия напрасны. Хотя он не сможет напрямик прорвать окружение «песочницы», но это не удержит его от запуска функции в адресном пространстве используемого процесса, что позволит прорваться в систему. Существует множество способов взлома «песочницы» chrootО. Однако все они основываются на возможности получения root-полномочий внутри этой «песочницы». Ахиллесовой пятой сИгооШявляется возможность получения UID 0 в «песочнице».
Существует ряд служб, поддерживающих среды chrootO за счет вызова этой функции из самой программы, но многие службы этого не позволяют. Для запуска таких служб внутри «песочницы» необходимо использовать команду chroot. Эта команда просто вызывает chrootO с первым аргументом командной строки и пытается выполнить программу, указанную в качестве второго аргумента. Если программа является статически связанным двоичным файлом, все, что необходимо сделать, — это скопировать программу в любое место внутри окружения «песочницы». Но если программа является динамически связываемой, то в окружение необходимо скопировать все поддерживающие ее библиотеки.
В качестве примера рассмотрим запуск bash в среде chrootO. Сначала попробуем запустить chroot без копирования библиотек, необходимых bash:
I mkdir -p /chroot_test/bin
ср /bin/bash /chroot_test/bin/
chroot /chroot_test /bin/bash
chroot: /bin/bash: No such file 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) для непосредственного доступа к памяти или перемонтировать файловую систему, что привело бы к прорыву «песочницы»
и получению полного контроля над всей системой. Эту угрозу можно уменьшить, поместив каталог на файловую систему, монтируемую с параметрами, запрещающими использование файлов-устройств (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
где Ipaddr — это IP-адрес машины, на которой запускается jail. Попробуйте запустить оболочку внутри «тюрьмы» (jail):
mkdir -р /Ja1l_test/biп
ср /bin/sh /jail_test/sh
jail /jail_test jail_test 192.168.0.40 /bin/sh
echo /* /bin
В данном случае нет необходимости копировать какие-либо библиотеки, поскольку /bin/sh в ОС FreeBSD статистически связан.
Вместе с тем существует возможность создать «тюрьму», которая может функционировать как практически полноценный виртуальный сервер с собственным IP-адресом. Для этого в основном требуется компоновка FreeBSD из исходного кода с указанием каталога jail в качестве места назначения установки.
Это делается с помощью следующих команд:
mkdir /jail_test
cd /usr/src
make world DESTDIR=/jail_test
cd /etc && make distribution DESTDIR=/jai1 test -DNO_MAKEDEV_RUN
cd /jail_test/dev && sh MAKEDEV jail
cd /jail_test && In -s dev/null kernel
Однако если вы планируете запускать в «тюрьме» только одну службу, то это явный перебор. Обратите внимание на то, что на практике для нормальной работы большинства демонов вполне достаточно создать узлы устройств /dev/null и /dev/log.
ТРЮК№ 11ТРЮК№ 11Использование proftp с MySQL
ТРЮК
№ 11
ТРЮК
№ 11
Убедитесь, что при использовании рассматриваемых подстроекоперационная система вашей базы данных работает самым эффективным образом.
Proftpd — это мощный FTP-демон, синтаксис которого очень напоминает Apache. Он имеет огромное количество функций, недоступных в большинстве FTP-демонов, включая отношения и виртуальный хостинг, и обладает блочной структурой, позволяющей создавать собственные модули.
Одним из модулей является mod_sql, позволяющий proftpd использовать базу данных SQL в качестве источника идентификации на серверной стороне. В настоящее время mod_sql поддерживают MySQL и PostgreSQL. Он является хорошим вариантом блокировки доступа к серверу, когда прибывающие пользователи идентифицируются в отношении базы данных (и, следовательно, не требуют наличия действительной учетной записи на сервере). В этом трюке мы будем использовать proftpd для проверки подлинности базы данных MySQL.
Прежде всего загрузите из Сети и скомпонуйте исходный код proftpd и mod_sql:
~$ bzcat proftpd-1.2.6.tar.bz2 | tar xf -
~/proftpd-1.2.6/contrib$ tar zvxf ../../mod_sql-4.08.tar.gz
-/proftpd-1.2.6/contrib$ cd ..
-/proftpd-1.2.6$ ./configure --with-modules=mod_sql:mod_sql_mysql \
--wi th -1nc1udes=/usr/1 oca 1/mysql/include/ \
--wi th-1ibraries=/usr/1 oca 1/mysql/1ib/
(Естественно, если путь установки my SQL отличается от /usr/local/mysql/, подставьте иной.) Теперь скомпонуйте код и установите его:
rob@catlin:~/proftpd-1.2.6$ make && sudo make install
Далее создайте базу данных для использования proftpd (полагая, что mysql уже установлен и запущен):
$ mysqladmin create proftpd
После этого разрешите к ней доступ из proftpd «только для чтения»:
$ mysql -е "grant select on proftpd.* to proftpd@loca 1 host \ identified by 'secret':"
Создайте в базе данных две таблицы по следующей схеме:
CREATE TABLE users (
userid varchar(30) NOT NULL default ".
password varchar(30) NOT NULL default ".
uid int(ll) default NULL.
gid int(ll) default NULL.
homedir varchar(255) default NULL.
shell varchar(255) default NULL.
UNIQUE KEY uid (uid).
UNIQUE KEY userid (userid) ) TYPE=MyISAM:
CREATE TABLE groups (
groupname varchar(30) NOT NULL default ".
gid int(ll) NOT NULL default 'O'.
members varchar(255) default NULL ) TYPE=MyISAM;
Самый быстрый способ создания таблиц — сохранить эту схему в файл с именем proftpd.schema и запустить команды mysql proftpd < proftpd.schema.
Теперь необходимо указать proftpd, что эту базу данных необходимо использовать для идентификации. Добавьте в /usr/local/etc/proftpd.conf следующие строки: SQLConnectlnfo proftpd proftpd secret SQLAuthTypes crypt backend SQLMinUserGID 111 SQLMinUserUID 111
Строка SQLConnectlnfo извлекает из БД пароль пользователя. Кроме того, БД можно разместить на другом узле (даже на другом порте) подобным образом:
SQLConnectlnfo proftpd@dbhost:5678 somebody somepassword
Строка 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/bash1);" 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»)
ТРЮКNs 12ТРЮКNs 12Предотвращение атак, направленных на повреждение стека
ТРЮК
Ns 12
ТРЮК
Ns 12
Научитесь предотвращать атаки переполнения буфера стека.
В С и 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) реализована независимо от компилятора, но она использует динамический загрузчик, предварительно
загружающий динамические библиотеки для каждого исполняемого файла. Использование LibSafe не требует исходного кода защищаемой программы и может разворачиваться по всей системе.
LibSafe заменяет реализации некоторых стандартных функций, уязвимость которых от переполнения буфера известна (gets(), strcpy() и scanf()). Замена реализаций пытается вычислить максимально возможный размер статически выделяемого буфера, используемого в качестве буфера назначения при записи, с помощью встроенной функции GCC, возвращающей адрес указателя фрейма. Этот адрес обычно является первым блоком информации в стеке, следующим за локальными переменными. Если будет предпринята попытка записать больше, чем расчетный размер буфера, программа будет завершена.
К сожалению, с подходом, используемым в LibSafe, связано несколько проблем. Во-первых, невозможно точно вычислить размер буфера. Самое лучшее, что можно сделать, — это ограничить размер буфера от начала буфера до указателя фрейма. Во-вторых, защита LibSafe не будет работать с программами, которые были откомпилированы GCC с флагом -fomit-frame-pointer. Выполненная компилятором оптимизация не помещает в стек указатель фрейма. Несмотря на относительную бесполезность, такая оптимизация популярна у программистов. И наконец, LibSafe не будет работать в отношении двоичных SUID-файлов без статического связывания или аналогичной уловки.
Помимо обеспечения защиты от обычных атак взлома стека, новейшие версии LibSafe могут противостоять некоторым атакам, основанным на искажении формата строки (format-string attacks). Защита от таких атак требует доступа к указателю фрейма, поскольку она пытается отфильтровать аргументы, не являющиеся ни указателями на «кучу» (heap), ни указателями на локальные переменные в стеке.
Помимо использования решений в пространстве пользователя (user-space solutions), вы можете предпочесть обновить ядро, сделав стек неисполняемым и добавив функцию обнаружения атак переполнения буфера (трюк № 13).
ТРЮК№ 13ТРЮК№ 13Блокировка ядра с помощью grsecurity
ТРЮК
№ 13
ТРЮК
№ 13
Укрепите систему с помощью обновления ядра grsecurity.
Повышение стойкости Unix-системы может быть довольно сложным процессом. Он обычно включает настройку всех служб, которые система должна запускать наиболее безопасным способом, а также блокировку системы для предотвращения локальных проникновений. Однако обеспечение безопасности запущенных служб не связано с защитой остальной системы и ее неизвестных слабых мест. К счастью, хотя ядро Linux и предоставляет несколько функций превентивной защиты системы, существуют обновления, помогающие системному администратору в полной мере реализовать их. Одним из таких обновлений является grsecurity (http://www.grsecurity.net).
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
ipatch -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).
\ Linux Kernel Configuration
Code maturity level options
Fusion MPT device support
Sound
Loadable module support
IEEE 1394 (HreVAre) support (EXPERIMENTAL) |
USB support
Processor type and features|
120 device support
Bkietooth support|
General setup
Network device support
Kernel hacking
Memory Technology Devices (MID) '
Amateur Radio support
Cryptographic opbons
Parallttl port support
IrDA (mfranxl) supimrt
Library routines
Plug and Play configuration
ISDN subsystem
Grsecurity
Block devices
Old CD-ROM drivers (not SCSI, not IDE)
MulU-iievice support (RAID and LVM) |
Input core support
Networking options
Character devices
Save and Exit
Telephony Supportj
Multimedia devices
Quit WUioul Saving1
ATMDUMFMZRU. tUfipoH
fie systems
Load Configuration from Hie |
SCSI support
Console drivers
Store Configuration to File 1
Рис. 1.1. Настройка ядра Linux после обновления grsecurity
Рис. 1.2. Диалоговое окно настройки grsecurity
Для включения grsecurity щелкните на переключателе у. После этого в раскрывающемся списке Security Level (Уровень безопасности) можно выбрать предварительно определенный набор функций или значение Custom (Пользовательский) и с помощью меню определить необходимые функции.
Выбор значения Low (Низкий) достаточно безопасен для любой системы и не должен влиять на нормальную работу программного обеспечения. Использование этой настройки включает ограничение связывания в каталогах с режимом 1777. Это предотвращает так называемое состояние гонок в каталоге /temp, используемое для проникновения за счет следования только символическим ссылкам на файлы, которыми владеет процесс. Аналогично, пользователи, находящиеся в каталоге с разрешением 1777, не смогут записывать в FIFO, которым они не владеют.
Помимо задания строгих ограничений, касающихся символьных ссылок и 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) или изменять системное время. Выбор этого уровня безопасности приведет также к произвольному размещению в памяти стека ядра для предотвращения успешной реализации атак переполнения буфера ядра. Кроме того, идентификаторы ядра будут скрыты (это значительно усложнит установку в запущенное ядро кода так называемых «троянских коней»), а операции монтирования, перемонтирования и демонтирования будут протоколироваться.
Выбор степени безопасности 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) для
дальнейшего ограничения привилегированных приложений на вашей системе. Если вы сразу обратились к этому трюку и не знакомы с 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 {
/h
/etc/grsech
-CAP_ALL
}
Это почти самый строгий из возможных ACL, поскольку он скрывает корневой каталог от процесса и удаляет все привилегии, которые ему могут понадобиться. Параметр 1о рядом с двоичным файлом, к которому применяется ACL,
указывает на использование режима обучения и на перекрытие ACL по умолчанию. После завершения редактирования ACL необходимо перезагрузить grsecurity с помощью команды gradm -R. Теперь снова попробуйте использовать команду ifconfig:
/sbin/ifconfig ethO:1 192.168.0.59 up
/sbin/ifconfig ethO:l
ethO:lLink 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 1BROADCAST RUNNING MULTICAST MTU:1500 Metric:l
Interrupt:10 Base address:0xl0e0
Помимо успешного выполнения этой команды, grsecurity создаст записи в протоколе обучения. На основе этого протокола можно сгенерировать ACL для определенной программы:
gradm -a
Password:
gradm -L -0 stdout
/sbin/ifconfi g о {
/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 может обеспечить точечное управление практически всем, что может сделать система.
ТРЮК№ 15ТРЮК№ 15Ограничение системных вызовов с помощью Systrace
ТРЮК
№ 15
ТРЮК
№ 15
Оградите программы от выполнения задач, которые они выполнять не должны.
Наиболее впечатляющей новинкой в ОС NetBSD и OpenBSD является systrace — диспетчер доступа к системным вызовам. С помощью systrace системный администратор может указать, какие системные вызовы может использовать конкретная программа и как эти вызовы могут выполняться. Разумное использование systrace в значительной степени сокращает риски, исходящие от некорректно написанных или взламывающих (разрушающих) программ. Политики systrace позволяют ограничить деятельность пользователя совершенно независимо от разрешений Unix. Имеется возможность даже определить ошибки, возвращаемые системными вызовами при запрете доступа, что позволит программам завершаться более корректно. Использование systrace требует практического понимания сути системных вызовов, а также функциональных возможностей программы, которые они определяют.
Прежде всего, разберемся в том, что представляет собой системный вызов. Системный вызов — это функция, позволяющая вам общаться с ядром операционной системы. Если вы хотите выделить память, открыть TCP/IP-порт или выполнить операцию записи/чтения диска, необходимо использовать системные вызовы. Системные вызовы описаны в разделе 2 справочной системы (manpages).
Unix поддерживает также широкое разнообразие библиотечных вызовов языка С. Их иногда путают с системными вызовами, но фактически они — лишь стандартизированные процедуры, которые можно использовать в программах. Например, можно написать функцию, вычисляющую квадратные корни в программе, но невозможно написать функцию, выделяющую память на основе системного вызова. Если есть сомнения, является ли конкретная функция системным вызовом или библиотечной функцией С, обращайтесь к справочной системе.
Можно встретить случайные системные вызовы, описания которых нет в документации, например break О. Для идентификации таких вызовов приходится углубляться в ресурсы (в частности, break О — очень давний системный вызов, который используется в libc, но не программистами; видимо, поэтому он и не представлен в справочной системе).
Systrace запрещает все действия, не разрешенные явно, протоколируя в syslog все отклонения. Если запущенная под systrace программа имеет проблемы, вы увидите, какой системный вызов хочет использовать программа, и должны решить, стоит ли добавить его в политику, перенастроить программу или оставить ошибку.
В systrace можно выделить ряд важных компонентов: политики, средства генерации политик, средства управления доступом в ходе выполнения и интерфейс
системного администратора, работающий в реальном времени. В этом трюке мы кратко рассмотрим политики, а в трюке № 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-го порта и выполнять запись в системный протокол. Вот начало этого файла:
f 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, то соединение принимается. Эта программа может привязываться
к 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».
Полный список кодов ошибок вы можете просмотреть с помощью справки 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)
ТРЮК№ 16ТРЮК№ 16Автоматизированное создание политики Systrace
ТРЮК
№ 16
ТРЮК
№ 16
Пускай за вас поработает автоматический режим Systrace.
В неправдоподобно идеальном случае системный администратор должен изучить исходный программный код каждого приложения, устанавливаемого на его систему, и вручную создать политики доступа к системным вызовам, полагаясь на собственное понимание каждой функции приложения. Практически никто из системных администраторов не имеет времени для такой работы.
К счастью, systrace имеет средство генерации политик с учетом всех системных вызовов, выполняемых приложением. Рассмотрим данный способ создания политики для inetd. Для включения автоматического режима используется ключ -А с указанием полного пути к необходимой программе:
systrace -A /usr/sbin/inetd
Для передачи флагов в inetd добавьте их в конец командной строки.
После этого используйте программу, для которой разрабатывается политика. На данной системе открыты службы ident, daytime и time, поэтому запустите программы, использующие эти службы. Для запуска запросов ident запустите IRC-клиент и для обращения к службам времени обратитесь с помощью telnet
к 13-му и 37-му портам. После того как были проверены возможности inetd, выключите его. Демон inetd не имеет управляющей программы, поэтому его работа завершается с помощью команды kill и идентификатора процесса. Проверка списка процессов показывает нам два процесса:
ps -ax | grep inet
24421 ?? : Ixs0:00.00 /usr/sbin/jnetd
12929 ?? iIs0:00.01 systrace -A /usr/sbin/inetd
He «убивайте» процесс systrace (в данном случае PID 12929). У него имеется информация обо всех системных вызовах, выполненных inetd. Завершите работу процесса inetd (PID 24421), и процесс systrace завершится нормальным образом. Теперь найдите в домашнем каталоге подкаталог .systrace, содержащий заготовку systrace-политики для inetd. He забывайте о том, что политики помещаются в файлы, имя которых составлено из полного пути к программе, в котором косые черты заменены знаком подчеркивания. Вот результат выполнения команды Is:
#iIs .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 имеет средство, позволяющее редактировать политики в реальном времени, прямо при выполнении системного вызова. Это отличный вариант для использования в центре сетевых операций, где лицо, ответственное за мониторинг сети, также будет заниматься просмотром системных вызовов и привлекать внимание соответствующего персонала. С помощью ключа -р можно указать программу, за которой необходимо наблюдать. Это называется присоединением к программе.
Например, раньше мы видели два процесса, относящиеся к 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)
ТРЮК№ 17ТРЮК№ 17Управление доступом с помощью РАМ
ТРЮК
№ 17
ТРЮК
№ 17
ШШдоступом с помощьюдоступом с помощьюЧетко определите, когда и откуда могут обращаться пользователи к вашей системе.
Ш
Ш
доступом с помощью
доступом с помощью
к вашей системе.к вашей системе.Четко определите, когда и откуда могут обращаться пользователи
к вашей системе.
к вашей системе.
При традиционной Unix-аутентификации нет слишком большой детализации
ограничения входа пользователей в систему. Например, как определить узлы,
с которых пользователи не должны регистрироваться на ваших серверах? Первым желанием может быть настроить TCP-оболочки или правила межсетевого экрана (трюки № 33 и 34). А что делать, если требуется некоторым пользователям разрешить регистрироваться с определенных узлов, а другим — запретить? А если требуется запретить одним пользователям регистрироваться в определенный промежуток времени (во время ежедневного обслуживания системы), но в то же время — разрешить другим (администраторам)? Для того чтобы это работало со всеми службами, которые могут быть запущены в системе, традиционно приходится обновить каждую из них для обеспечения этой функциональности. Вот где пригодится РАМ.
РАМ (сокращение от pluggable authentication modules; буквально — подключаемые модули идентификации) обеспечивает именно такой вид функциональности (и даже больше) без необходимости исправления (patch) всех служб. Практически всегда РАМ существовал для Linux, FreeBSD и Solaris и сейчас является стандартным компонентом традиционных функций идентификации этих платформ. В настоящее время РАМ поддерживаются многие службы, которым требуется аутентификация.
Модули настраиваются «пакетом» для всех служб непосредственно в ходе идентификации, выполняемой от начала до успешного завершения проверок доступа. Можно построить пользовательский «пакет» для любой службы, создав в /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
auth
required
pam_securetty.so
auth
required
pam_stack.so service=system-auth
auth
required
pamjiologin.so
account
required
pam_stack.so service=system-auth
password
required
pam_stack.so service=system-auth
session
required
pam_stack.so service=system-auth
session
optional
pam_console.so
Обратите внимание на использование модуля pam_stack. Он осуществляет включение «пакета», содержащегося в файле system-auth. Давайте рассмотрим и содержание /etc/pam.d/system-auth:
auth
required
/lib/security/$ISA/pam_env.so
auth
sufficient
/lib/security/$ISA/pam_unix.so likeauth nullok
auth
required
/lib/security/$ISA/pam_deny.so
account
required
/lib/security/$ISA/pam_unix.so
password
required
/lib/security/$ISA/pam_cracklib.so retry=3 type=
password
sufficient
/lib/security/$ISA/pam_unix.so nullok use_authtok
md5 shadow
password
required
/lib/security/$ISA/pam_deny.so
session
required
/lib/security/$ISA/pam_limits.so
session
required
/lib/security/$ISA/pam_unix.so
«РАМ-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
Для добавления модуля 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:
services;devices;users;times
Параметр services указывает, в отношении какой РАМ-совместимой службы действует ограничение. Полный список таких служб можно узнать, просмотрев ката- лог/etc/pam.d. Например, вот содержание /etc/pam.d в версии RedHat ОС Linux: $ 1 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, необходимо добавить такую строку: accountrequired/lib/security/$ISA/pam_time.so
Параметр devices указывает терминал, с которого будет произведено обращение к службе. Для регистрации с консоли используется значение ! ttyp*, которое указывает на все TTY-устройства, за исключением псевдо-TTY. Если необходимо, чтобы запись влияла только на удаленную регистрацию, то укажите ttyp*. Для распространения ограничения записи на всех пользователей (консоль, удаленный и XII) введите tty*.
В качестве значений параметра users можно указывать одного пользователя либо список пользователей, отделяя одного от другого символом |. Параметр times используется для указания времени, в течение которого действует правило. Перед временным диапазоном указывается двухбуквенное сокращение, соответствующее дню недели. Допустимые сокращения: Mo, Tu, We, Th, Fr, Sa и Su.
Для удобства можно использовать сокращения 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) могут быть полезны. Многие оболочки имеют такую возможность, которая вызывается запуском оболочки с ключом -г. Хотя эта процедура не так безопасна, как основанная на системных вызовах среда «песочницы», работает она нормально, если вы считаете, что пользователи не имеют злого умысла, но могут быть не в меру любопытны.
Некоторые из известных возможностей ограниченных оболочек — это возможность запретить смену каталога программой, разрешая выполнение команды только по абсолютному пути, и запрет выполнения команд в подкаталогах. Помимо введения этих ограничений отключаются все операторы перенаправления, которые могут использоваться в командной строке. При этом ограничить список команд, которые может выполнить пользователь, можно просто: выбрав, какие команды должны быть доступны, и сделав на них символические ссылки внутри домашнего каталога пользователя. Если требуется выполнять лишь ряд команд, то можно создать сценарии, принадлежащие определенному пользователю. Эти сценарии будут выполняться в неограниченной среде, но будут недоступны для редактирования в этой среде самим пользователем.
Давайте попробуем запустить ограниченную оболочку и посмотрим, что выйдет:
$ bash -r
bash: SHELL: readonly variable
bash: PATH: readonly variable
bash-2.05b$ Is
bash: Is: No such file or directory
bash-2.05b$ /bin/ls
bash: /sbin/ls: restricted: cannot specify "/' in command
names
bash-2.05b$ exit $ In -s /bin/ls . $ bash -r bash-2.05b$ Is -la
total 24 drwx 2andrew
andrew
4096
Oct
20
08
01
drwxr-xr-x 4 root
root
4096
Oct
20
14
16
-rw 1andrew
andrew
18
Oct
20
08
00
.bash history
-rw-r--r--1 andrew
andrew
24
Oct
20
14
16
.bash logout
-rw-r--r--1 andrew
andrew
197
Oct
20
07
59
.bash profile
-rw-r--r--1 andrew
andrew
127
Oct
20
07
57
.bashrc
1rwxrwxrwx 1 andrew
andrew
7
Oct
20
08
01
Is -> /bin/ls
Ограниченный вариант команды ksh предоставляет иные возможности запуска сценариев и двоичных файлов, располагающихся в каталоге, указанном в вашем PATH, который должен быть настроен до входа в оболочку:
$ rksh
$ Is -la total 24 drwx
2
andrew
andrew
4096
Oct
20
08:01 .
drwxr-xr-x
4
root
root
4096
Oct
20
14:16 ..
1
andrew
andrew
18
Oct
20
08:00 .bash history
-rw-r--r--
1
andrew
andrew
24
Oct
20
14:16 .bash logout
-rw-r--r--
1
andrew
andrew
197
Oct
20
07:59 .bash profile
-rw-r--r--
1
andrew
andrew
127
Oct
20
07:57 .bashrc
1rwxrwxrwx $ which Is /bin/ls $ exit
1
andrew
andrew
7
Oct
20
08:01 Is -> /bin/ls
Это работает из-за того, что файл /bin присутствовал в РАТК до вызова ksh. А те перь давайте изменим РАТК и снова запустим rksh:
$ export РАТН=.
$ /bin/rksh
$ /Ып/ls
/bin/rksh: /bin/ls: restricted
$ exit
$ In -s /bin/ls .
$ Is -la
total 24
drwx2 andrew andrew 4096 Oct 20 08:01 .
drwxr-xr-x
4 root
root
4096 Oct 20 14:16 ..
- rw
1 andrew
andrew
18 Oct 20 08:00 .bash history
-rw-r--r--
1 andrew
andrew
24 Oct 20 14:16 .bashjogout
-rw-r--r--
1 andrew
andrew
197 Oct 20 07:59 .bash profile
-rw-r--Г--
1 andrew
andrew
127 Oct 20 07:57 .bashrc
1rwxrwxrwx
1 andrew
andrew
7 Oct 20 08:01 Is -> /bin/ls
Настройки ограничения оболочки очень просты, тем не менее они предоставляют минимально ограниченный доступ. Ограниченные оболочки не в силах противостоять явным взломщикам, но несколько усложняют враждебную деятельность.
Ограничение ресурсов пользователя и группы
Убедитесь, что «жадный» до ресурсов пользователь не нарушит работу системы.
Становится не до смеха, когда по злому умыслу либо из-за непреднамеренной ошибки пользователь, расходуя слишком много оперативной памяти или времени центрального процессора, заставляет систему работать очень медленно. Одним из популярных методов ограничения использования ресурсов является команда ulimit. Этот метод основан на ограничении оболочкой своих дочерних процессов, и его очень сложно использовать, когда требуется предоставить различный уровень ограничения отдельным пользователям или группам. Более гибким является способ с применением РАМ-модуля pamjimits.
На тех системах, где установлен pamjimits, он уже имеет предварительные настройки. Необходимо лишь правильно настроить /etc/security/limits.conf.
Конфигурационный файл limits.conf содержит однострочные записи, описывающие отдельный тип ограничений для пользователя или группы. Общий формат записей этого файла следующий:
domain type resource value
Параметр domain определяет, к кому применяется данное ограничение. Отдельный пользователь может быть указан по имени, а перед именем группы необходимо поставить символ @. Помимо этого, может использоваться групповой символ *, указывающий на применение данного ограничения ко всем, кроме root. Параметр type указывает тип ограничения («мягкое» или «жесткое»). «Мягкое» ограничение может быть увеличено пользователем, в то время как «жесткое» может менять только root-пользователь. В разделе resource могут указываться различные типы ресурсов. Основными из них являются cpu, memlock, nproc и fsize. Они позволяют указывать использование процессора, памяти, количество процессов и размер файлов соответственно. Процессорное время выражается в минутах, размеры — в килобайтах. Еще одним значением является maxlogins, оно задает максимальное количество разрешенных одновременных регистрации в системе.
ТРЮК№20ТРЮК№20Автоматизация обновления системы
ТРЮК№20
ТРЮК№20
Своевременно устраняйте «дыры» в системе безопасности для предотвращения проникновения.
Периодическое обновление системы и исправление ее недочетов — это один из основных шагов, предпринимаемых для защиты вашей системы от использования только что найденных уязвимых мест системы безопасности. К сожалению, решение этих задач обычно откладывается и предпочтение отдается «экстренным» проблемам, таким как тонкая настройка производительности, обслуживание аппаратного и отладка программного обеспечения. Некоторые администраторы
Невозможно изменить ограничение. Операция запрещена.
считают это напрасной тратой времени и сил, что не способствует выполнению основной функции системы. Приоритетным становится требование руководства повысить производительность системы, поэтому ее поддержание в обновленном состоянии зачастую откладывается в долгий ящик.
Обновление системы может быть очень скучным и отнимающим много времени занятием, если не использовать сценарии автоматизации. К счастью, большинство дистрибутивов 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
Трюки № 21-30
В этой главе представлены некоторые способы обеспечения обновления и безопасности системы Windows, позволяющие сделать сеть более защищенной. Хотя многие насмехаются над ОС Windows и ее системой безопасности, эту систему можно довольно легко сделать совершенно безопасной.
Одна из основных причин, по которым Windows заслужила репутацию «дырявой», заключается в неверном администрировании. Появляющиеся в последнее время потоки «червей» и вирусные атаки, захватывающие множество сетей, подтверждают это. Большинство проблем возникает из-за «упрощенного» администрирования, которое обеспечивается самой ОС Windows и полностью освобождает администратора от отслеживания внутренней работы среды, тем самым вырывая возможность управления из его рук.
Эта глава является в некоторой степени лекарством, показывающим, как необходимо определять, что же на самом деле делает сервер. Хотя это знакомо системным администраторам Unix, получение сведений об открытых портах и запущенных сервисах зачастую является новым для администраторов Windows. Кроме того, в этой главе вы узнаете, как отключить такие функции Windows, как автоматическое предоставление в общий доступ всех файлов и усечение файлов протоколирования. Вы также узнаете, как включить функции аудита и протоколирования Windows, что позволит на ранней стадии отследить нарушения в системе безопасности (не ожидая телефонного звонка от рассерженного человека, подвергшегося исходящей из вашей сети атаке, приводящей к отказу в обслуживании).
Проверка серверов и используемых обновлений
Убедитесь, что на ваши Windows-серверы установлены самые свежие обновления и исправления.
Поддержание сетей Unix на уровне современных требований является довольно сложной задачей, однако в ОС Windows она еще более трудоемка. Недостаток надежных встроенных сценариев и возможностей удаленного доступа делает ОС Windows неудобной для автоматизации. Тем не менее, перед тем как пробовать обновить систему, сначала необходимо выяснить, какие обновления в ней уже выполнены. Иначе вы можете впустую потратить силы и время, выполняя об-
новление, которое совершенно не требуется. Очевидно, что с увеличением количества обслуживаемых систем эта проблема становится все более сложной. Избежать излишних усилий ручного обновления систем можно, используя средство 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
Version1 ]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 info@shavlik.com (www.shavlik.com)
Please use the -v switch to view details for Patch NOT Found, Warning and Note messages
Трюк № 21 . Проверка серверов и используемых обновлений
Attempting to get cab from http://go.microsoft.com/fwlink/?LinkId=16932
XML successfully loaded.
Scanning PLUNDER
Done scanning PLUNDER
PLUNDER(192.168.0.65)
* WINDOWS XP SP1
Note
MS02-008
317244
Warning
MS02-055
323255
Note
MS03-008
814078
■ Note
MS03-030
819696
Patch NOT Found
MS03-041
823182
Patch NOT Found
MS03-044
825119
Patch NOT Found
MS03-045
824141
Patch NOT Found
MS03-049
828035
Note
MS03-051
813360
* INTERNET EXPLORER 6 SP1
Patch NOT Found MS03-048824145
* WINDOWS MEDIA PLAYER FOR WINDOWS XP SP1
Information•
All necessary hotfixes have been applied.
В первом столбце указан результат неудачной проверки определенного обновления. Во втором столбце указано, какое именно обновление выполнено неудачно, а в третьем — номер пункта в базе знаний Microsoft Knowledge Base (http://support.microsoft.com), в котором содержится дополнительная информация о проблеме, исправляемой определенным обновлением.
Если вы хотите узнать больше о конкретной неудачной проверке, команду необходимо запускать с ключом -у. Вот результат выполнения предыдущей команды, но с использованием этого ключа:
Scanning PLUNDER
Done scanning PLUNDER
PLUNDER!192.168.0.65)
* WINDOWS XP SP1
3 3« 1103
NoteMS02-0O8317244
Please refer to 0306460 for a detailed explanation.
Warning MS02-055■ 323255
File C:\WIND0WS\system32\hhctrl.ocx has a file version [5.2.3735.0] greater than what is expected [5.2.3669.0]
NoteMS03-008814078
Please referto0306460 foradetailedexplanation.
NoteMS03-030819696
Please referto0306460 foradetailedexplanation.
Patch NOT FoundMS03-041823182
File C:\WIND0WS\system32\cryptui.dll has a file version [5.131.2600.1106] that is less than what is expected [5.131.2600.1243].
Patch NOT Found MS03-044825119
File C:\WINDOWS\system32\itircl.dll has a file version [5.2.3644.0] that is less than what is expected [5.2.3790.80].
Patch NOT Found MS03-045824141
File C:\WINDOWS\system32\user32.dll has a file version [5.1.2600.1134] that is less than what is expected [5.1.2600.1255].
Patch NOT Found MS03-049828035
File C:\WIND0WS\system32\msgsvc.dll has a file version [5.1.2600.0] that is less than what is expected [5.1.2600.1309].
NoteMS03-051813360
Please refer to 0306460 for a detailed explanation.
* INTERNET EXPLORER 6 SP1
Patch NOT Found MS03-048824145
The registry key **SOFTWARE\Microsoft\Internet ExplorerXActiveX
Compatibility\[69DEAF94-AF66-llD3-BEC0-00105AA9B6AE}** does not exist. It is required for this patch to be considered installe»
* WINDOWS MEDIA PLAYER FOR WINDOWS XP SP1
Information
All necessary hotfixes have been applied.
* 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-имен рm(смпаоbIож-Psгaо-нcадмоlдiнсоротж/емьhснуfасомв-пуrиксота1морз9тоыо2щк.в1еаь96)тю28ь.с.1идп6.си18ат2.ар1е3па.м1ам3з-еоктднор1от9аIо2P1р-.91-fыаi26pд.е81р.у6б1е8к.ус1.адо17зу.в21та.7тпН2ьраIоипPвср-епиародмелрнеьеырзсу.аед.АтлсАняяаслсколпагеинодчмиунроюощщвиьааюмняеиепкятаосрмяиаасмвнтоедетзма-:
Все параметры очень удобны, и их можно использовать в любом сочетании.
Помимо указания удаленной системы по NetBIOS-имени или IP-адресу, с помощью параметра -d можно сканировать системы по имени домена, а с помощью параметра -п можно выполнить сканирование всего сегмента локальной сети.
При сканировании систем, выполняемом с личной рабочей станции, могут пригодиться параметры -и и -р. При обращении к удаленной системе они позволяют сразу указывать имя пользователя и пароль. Эти ключи особенно полезны, если вы обычно входите в систему, не используя учетную запись администратора. Конечно же, указанная в параметре -и учетная запись должна иметь привилегии администратора удаленной системы.
При сканировании большого количества систем удобен также параметр -t. Он позволяет указывать число потоков, используемых сканером. Увеличение количества потоков обычно приводит к повышению скорости сканирования. Допускаются значения от 1 до 128; по умолчанию — 64.
При сканировании более одной машины на экран «вываливается» огромное количество данных. Параметр -f позволяет указать файл, где будут храниться результаты сканирования, которые можно позже просмотреть с помощью обычного текстового редактора.
HFNetChk — очень гибкий инструмент, который может использоваться для довольно быстрой проверки необходимости обновления системы на множестве машин. Эта программа особенно полезна при появлении нового «червя», когда вам необходимо убедиться, что все ваши системы имеют свежее обновление, защищающее от воздействия этого «червя».
СОВЕТ
См. также Microsoft Network Security Hotfix Checker (Hfnetchk.exe) Tool: Know- л ledge 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.
ТРЮК№22ТРЮК№22Получение списка открытых файлов и владеющих ими процессов
ТРЮК
№22
ТРЮК
№22
Поиск подозрительной активности путем наблюдения за доступом к файлам.
Предположим, вы просматриваете в менеджере задач список процессов, не запуская на рабочей станции посторонних задач, и замечаете процесс, который раньше не видели. Что теперь надо делать? Если у вас установлена не ОС Windows, можно проконтролировать деятельность процесса, просмотрев файлы, которые он открывает. К сожалению, Windows не позволяет сделать это.
Компания Sysinternals разработала отличный инструмент под названием Handle, который можно бесплатно загрузить с адреса: http://www.sysinternals.com/ntw2k/ freeware/handle.shtml. Программа Handle очень похожа на Isof (см. трюк № 8), но
она может выводить список оперативных ресурсов различных типов, включая потоки, события и семафоры. Кроме того, эта программа выводит открытые ключи реестра и IOCompletion-структуры.
Запуск Handle из командной строки без параметров представит список всех открытых дескрипторов файлов. Для того чтобы узнать, какие процессы обращаются к определенному файлу в данный момент, можно указать имя конкретного файла: С:\> handle имя файла
Если же необходимо просмотреть лишь список файлов, открываемых определенным процессом, например Internet Explorer, то команда будет выглядеть так:
С:\> handle -p iexplore
Handle v2.10
Copyright (С) 1997-2003 Mark Russinovich
Sysinternals - www.sysinternals.com
IEXPLORE.EXE pid:
688 PLUNDER\andrew
98: Section
\BaseNamedObjects\MTXCOMM MEMORY MAPPED FILE
9c: Section
\BaseNamedObjects\MtxWndList
12c: Section
\BaseNamedObjects\ R 0000000000d4 SMem
18c: File
C:\Documents and Settings\andrew\Local SettingsXTemporary Internet Files\Content.IE5\index.dat
198: Section
\BaseNamedObjects\C:_Documents and Settings_andrew_Local
Settings_Temporary Internet Files_Content.IE5_ index.dat 3194880
laO: File
C:\Documents and Settings\andrew\Cookies\index.dat
la8: File
C:\Documents and SettingsXandrewXLocal SettingsXHistoryX
Hi story.IE5\index.dat
lac: Section
\BaseNamedObjects\C:_Documents and Settings_andrew_Local Settings History History.IE5 index.dat 245760
lb8: Section
\BaseNamedObjects\C:_Documents and Settings_andrew_ Cookies index.dat 81920
228: Section
XBaseNamedObjectsXUr1ZonesSM andrew
2a4: Section
XBaseNamedObjectsXSENS Information Cache
540: File
C:\Documents and SettingsXandrewXApplication DataXMicrosoftX SystemCertificatesXMy
574: File
C:\Documents and SettingsXAll UsersXDesktop
5b4: Section
XBaseNamedObjectsXmmGlobalPnpInfo
5cc: File
C:\WINNT\system32\mshtml.tlb
614: Section
XBaseNamedObjectsXWDMAUD Callbacks
640: File
C:\WINNT\system32\MacromedXFlash\Flash.ocx
648: File
C:\WINNT\system32\STDOLE2.TLB
6a4: File
\Dfs
6b4: File
C:\Documents and SettingsXandrewXDesktop
6c8: File
C:\Documents and Settings\andrew\Local SettingsX Temporary Internet FilesXContent.IE5\Q5USFST0\ softwareDownloadIndextU.htm.
70c: Section
\BaseNamedObjects\MSIMGSIZECacheMap
758:FileC:\WINNT\system32\iepeers.dll
75c:FileC:\Documents and Settings\andrew\Desktop
770:Section\BaseNamedObjects\RotHintTable
If you want to find 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 SettingsX Temporary Internet Files\Content.IE5\H1EZGFSH\ handle[l].htm
758: File75с: File770: Section758: File75с: File770: SectionC:\WINNT\system32\iepeers.dll
758: File
75с: File
770: Section
758: File
75с: File
770: Section
C:\Documents and Settings\ahdrew\Desktop \BaseNamedObjects\RotHintTable
If you want to find the Internet Explorer process that owns a resource with
a partial name of handle, you could type: C:\> handle -p iexplore handle
(0CС) п19и97с-20о03к Mзaаrk пRуusщsinoеviнchных служб
Esи- wоwтwpкi.sdрy:sы1n3e9т6rnыasCх.c:\oDпmocоumрeтntоs вand Settings\andrew\Local Settings\
Проверьте средстваTмeиmWpoirnadryowIsntсeлrуnжeбtыF,iкleкsо\Cтоoрnыteмnt.IE5\HlEZGFSH\
можнообращатьсяиhзaвnнdеl.ed].htm
Кроме того, для просмотра всех типов ресурсов можно воспользоваться парамет-
рUоnмix-пa.озHвaоnлdяlеeт—быосчтерноьимпорщонсотое псреодссмтовтор,еитьвокткормыантыднеопйорстыро, кнеомкоажкеэттодсндоевлратеь- мв еWннinоdуoкwаsз?ывПартьосгряанмемсакоFлPькorоt ркаозмлипчаниыих пFаoрuаnмdеsтtрoоnвeд(лhяttpб:ы//сwтрwоwг.оfoпuоnиdsсtкoаneи.cмoеmн-/ нreоsoтuоrгcоe,sк/iоnтdоeрxыrйesнoеuоrбcхesо.дhиtmм.) так же проста и быстра, как старый добрый 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
Pid
Process
Port
Proto Path
432
svchost
-> 135
TCP C:\WINNT\system32\svchost.exe
8
System
-> 139
TCP
8
System
-> 445
TCP
672
MSTask
-> 1025
TCP C:\WINNT\system32\MSTask.exe
8
System
-> 1028
TCP
8
System
-> 1031
TCP
1116
navapw32
-> 1035
TCP C:\PR0GRA-l\N0RT0N-l\navapw32.exe
788
svchost
-> 1551
TCP C:\WINNT\system32\svchost.exe
788
svchost
-> 1553
TCP C:\WINNT\system32\svchost.exe
788
svchost
-> 1558
TCP C:\WINNT\system32\svchost.exe
1328
svchost
-> 1565
TCP C:\WINNT\System32\svchost.exe
8
System
-> 1860
TCP
1580
putty
-> 3134
TCP C:\WINNT\putty.exe
772
WinVNC
-> 5800
TCP C:\Program Files\TightVNC\WinVNC.exe
772
WinVNC
-> 5900
TCP C:\Program Files\TightVNC\WinVNC.exe
432
svchost
-> 135
UDP C:\WINNT\system32\svchost.exe
8
System
-> 137
UDP
8
System
-> 138
UDP
8
System
-> 445
UDP
256
Isass
-> 500
UDP C:\WlNNT\system32\lsass.exe
244
services
-> 1027
UDP C:\WINNT\system32\services.exe
688
IEXPLORE
-> 2204
UDP C:\Program Files\Internet Explored IEXPLORE.EXE
1396
IEXPLORE
-> 3104
UDP C:\Program Files\Internet Explorer\ IEXPLORE.EXE
256
Isass
-> 4500
UDP C:\WINNT\system32\lsass.exe
Обратите внимание на то, что здесь представлены некоторые процессы (navapw32, putty и IEXPLORE), которые выглядят не как службы. Они оказались в выходном списке из-за того, что FPort выводит все открытые порты, а не только порты, для которых запущены процессы-«слушатели».
Несмотря на то что программа FPort не столь мощна, как некоторые команды, доступные в других операционных системах, все равно она — надежное, быстрое и простое в использовании средство, являющееся хорошим дополнением Windows.
ТРЮКNa 24ТРЮКNa 24Включение аудита
ТРЮК
Na 24
ТРЮК
Na 24
Протоколируйте подозрительнуюактивность для облегчения установления факта вторжения.
Windows 2000 обладает очень мощными функциями протоколирования, но, к сожалению, по умолчанию все они отключены. В Windows 2003 это исправлено включением ряда функций по умолчанию, но все же разумно проверить, что отслеживается именно то, что необходимо. С помощью имеющихся возможностей можно наблюдать за неудачными попытками входа в сеть, отслеживать события управления учетными записями, доступа к файлам, использование привилегий и т. п. Можно также протоколировать изменение политик безопасности и все системные события. Для включения аудита в любой из перечисленных областей найдите значок Средства администрирования (Administrative Tools) панели инструментов и дважды щелкните на нем. После этого найдите значок Локальная
политика безопасности (Local Security Policy) и дважды щелкните на нем. Раскройте узел дерева Локальные политики (Local Policies) (рис. 2.1).
Рис. 2.1 . Настройки политики аудита в модуле настроек локальной безопасности
Теперь можно перейти к любой политике и проверить включение протоколирования успешного или неудачного события. Это можно сделать, дважды щелкнув в правой части окна на политике, которую вы хотите изменить. После этого откроется диалоговое окно, подобное окну, представленному на рис. 2.2.
Рис. 2.2. Диалоговое окно аудита событий входа в систему
Если оставить аудит отключенным, то протоколирование выполняться не будет, поэтому необходимо включить аудит всех политик. После включения аудита для конкретной политики необходимо просматривать пункты журнала событий при возникновении конкретного события аудита. Например, после включения аудита регистрации в системе необходимо просматривать журнал событий безопасности системы, в котором будут отражаться успешные и неудачные попытки.
ТРЮК№25ТРЮК№25Защита журналов событий
ТРЮК
№25
ТРЮК
№25
Системные протоколы не должны искажаться.
Windows имеет очень мощные возможности протоколирования. К сожалению, по умолчанию журнал событий не защищен от несанкционированного доступа или изменения. Несмотря на то что события просматриваются с помощью Event Viewer, журнал событий представляет собой обычный файл, такой же, как и остальные. Для их защиты достаточно лишь найти эти файлы и применить к ним соответствующие списки ACL. Если только расположение файлов не было изменено с помощью реестра, то они должны находиться в каталоге %SystemRoot%\system32\config.
С журналом приложения, безопасности и системным протоколом сопоставлены файлы AppEvent.Evt, SecEvent.Evt и SysEvent.Evt соответственно. Для ограничения доступа к ним только с помощью учетной записи администратора примените к ним ACL. Это можно сделать с помощью диалогового окна свойств файла. Перейдя на вкладку Безопасность (Security), удалите на ней всех пользователей и группы, за исключением Administrators и SYSTEM.
ТРЮК№ 26ТРЮК№ 26Изменение максимальных размеров файлов протоколов
ТРЮК
№ 26
ТРЮК
№ 26
Измените свойства протоколированиятакимобразом, чтобы журналы представляли полную картину происшествия.
С точки зрения безопасности журналы — это самый важный актив, хранящийся на сервере. Как-никак, без протоколов вы никогда не узнаете, пытался ли кто-то получить доступ к вашей машине. Следовательно, обязательным требованием является полнота протоколирования. Пытаться обнаружить источник инцидента с помощью протокола, в котором пропущены записи, все равно что вообще не иметь протокола.
Одной из проблем является то, что по умолчанию максимальный размер файла установлен 512 Кбайт. Для его изменения откройте панель управления Средства администрирования (Administrative Tools) и откройте окно Просмотр событий (Event Viewer) (рис. 2.3).
После этого выделите в левой панели этого окна один из файлов протокола и щелкните на нем правой кнопкой мыши. В контекстном меню выберите пункт Свойства (Properties) (рис. 2.4).
Найдите текстовое поле Максимальный размер протокола (Maximum log size). Новый размер можно задать вручную или с помощью стрелок, расположенных справа от поля. Размер должен быть не менее 1 Мбайт и определяется тем, как часто вы собираетесь просматривать и архивировать протоколы. Учтите, что, хотя слишком большой размер файлов протоколов никак не сказывается на быстродействии машины, работа утилиты Просмотр событий (Event Viewer) с большими файлами будет замедленной.
Рис. 2.З. Окно Просмотр событий (Event Viewer)
Рис. 2.4. Свойства протокола безопасности
Находясь на этой вкладке, можно также изменить поведение протокола при достижении им максимального размера. По умолчанию записи журнала, сделанные более семи дней назад, заменяются новыми. Рекомендуется увеличить это значение до 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 в реестрРис. 2.5. Добавление ключа AutoShareWks в реестр
Рис. 2.5. Добавление ключа AutoShareWks в реестр
Рис. 2.5. Добавление ключа AutoShareWks в реестр
После перезагрузки Windows можно убедиться (с помощью команды net share), что стандартных общих ресурсов больше не существует:
C:\>net share
Share name ResourceRemark
IPC$ Remote IRC The command completed successfully.
Перед этим необходимо убедиться, что отключение общих ресурсов не скажется негативно на вашем окружении. Отсутствие этих ресурсов приведет к тому, что некоторые средства управления системой, такие как HFNetChk (трюк № 21) или System Management Server, работать не будут. Это происходит из-за того, что подобное программное обеспечение основано на удаленном доступе к открытым административным ресурсам, которые используются для обращения к содержанию системных дисков.
ТРЮК№28ТРЮК№28
ТРЮК
№28
ТРЮК
№28
Многие Windows-приложения в ходе работы создают промежуточные/временные файлы. Как правило, эти файлы хранятся во временном каталоге, расположенном в settings-каталоге текущего пользователя. Почти всегда эти файлы становятся глобально доступными (world-readable) и не всегда удаляются по завершении работы приложения. Вам понравится, если текстовый процессор оставит копию последнего документа для того, кто проникнет в систему? Не здорово, правда? Одним из способов противостоять данной ситуации является шифрование каталога временных файлов. Для этого откройте окно Проводника Windows и перейдите в каталог C:\Documents and Settings\<HMfl пользователя>\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 убеждается, что частные ключи хранятся в памяти ядра, не
имеющей постраничной организации, так что ключ дешифрации никогда не попадет в файл страничной памяти (файл подкачки). К сожалению, используемый алгоритм шифрования (DESX) является лишь слегка усовершенствованным DES и никогда не будет столь же криптоустойчивым, как 3DES. Однако для шифрования временных файлов он вполне подходит. Если необходимо выполнять шифрование других файлов, желательно использовать средства сторонних производителей, такие как GnuPG (http://www.gnupg.org).
Рис. 2.6. Диалоговое окно дополнительных атрибутов папки TempРис. 2.6. Диалоговое окно дополнительных атрибутов папки TempРис. 2.7. Подтвердите выбор шифрования и сделайте его рекурсивнымРис. 2.7. Подтвердите выбор шифрования и сделайте его рекурсивным
Рис. 2.6. Диалоговое окно дополнительных атрибутов папки Temp
Рис. 2.6. Диалоговое окно дополнительных атрибутов папки Temp
Рис. 2.7. Подтвердите выбор шифрования и сделайте его рекурсивным
Рис. 2.7. Подтвердите выбор шифрования и сделайте его рекурсивным
P D III- 25P D III- 25Очистка файла подкачки при отключении
P D I
II- 25
P D I
II- 25
Предотвращайте утечку информации с помощью автоматической очистки файла подкачки при выключении.
Система управления виртуальной памятью (Virtual memory management, VMM) — прекрасная штука. Она защищает программы друг от друга и позволяет им пользоваться объемом памяти, который превосходит объем физический памяти,
установленной в системе. Для реализации этого VMM использует то, что называется страничным файлом (своп-файлом, файлом подкачки).
По мере запуска все большего числа программ объем физической памяти исчерпывается. При этом диспетчер памяти находит реже используемый участок памяти, относящийся к программам, которые в данный момент не проявляют никакой активности, и записывает его на жесткий диск (то есть в виртуальную память). Этот процесс называется подкачкой.
Однако у этого процесса имеется один существенный недостаток: если запущена программа, обрабатывающая конфиденциальную информацию в «своем» пространстве памяти, то эта информация может оказаться на диске. Хорошо, если запущена операционная система и существуют средства защиты, предотвращающие возможность чтения файла подкачки, но как быть в случае, если эта система отключена или производится перезагрузка компьютера в другую операционную систему?
Вот где становится необходимым данный трюк. Все, что необходимо сделать, — это попросить операционную систему при выключении заполнить файл подкачки нулями. Учтите, что это не сработает, если отключение производится извлечением сетевого кабеля из розетки или система выключается неверно; описываемая перезапись возможна только при корректном выключении компьютера.
Для включения этой функции Windows необходимо внести изменения в системный реестр. Для этого откройте реестр и найдите ключ HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management (рис. 2.8).
Рис. 2.8. Ключ реестра, отвечающий за управление памятью
Найдите параметр ClearPageFileAtShutdown в правой панели и измените его значение на 1. Для того чтобы изменение вступило в силу, перезагрузите Windows, и те-
перь перед выключением компьютера ваш своп-файл будет очищаться. Единственный побочный эффект от использования этой функции заключается в том, что выключение Windows теперь будет занимать больше времени. Однако это очень сильно зависит от аппаратного обеспечения (то есть от чипсета контроллера диска, скорости вращения диска, скорости процессора и т. п.), что определяет длительность записи нулей в файл подкачки.
ТРЮКNs 30ТРЮКNs 30Ограничение доступа пользователя к приложениям
ТРЮК
Ns 30
ТРЮК
Ns 30
Защитите пользователей от запуска потенциально опасных приложений.
Обеспечение невозможности для пользователей запускать определенные приложения не очень важно при администрировании собственной рабочей станции. Но когда вы имеете дело с обычными пользователями, работающими в сетевой среде предприятия, необходимо оградить их от запуска «подлых» программ. К таким программам относятся приложения, которые могут нарушить работу операционной системы, создают «дыры» в системе безопасности и даже организуют атаки на другие компьютеры вашей сети.
Существует пара способов ограничения доступа пользователей к приложениям. Во-первых, можно изменить 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
Рис. 2.11 . Ограничениеиспользованияcmd.exe
Если необходимого приложения в списке нет, щелкните на кнопке Добавить (Add) и укажите это приложение. После внесения изменений щелкните на кнопке Выход (Exit). Для того чтобы изменения вступили в силу, необходимо, чтобы все пользователи завершили сеанс работы с терминальным сервером.
ГЛАВА 3
Сетевая безопасность
Трюки№31-53
По мере того как мы все больше полагаемся на связь посредством массовых сетей, все более важными становятся стабильность и надежность этих сетей. Мир бизнеса одобрил информационные технологии, помогающие упорядочить процессы, повысить их продуктивность и снизить стоимость. Таким образом, IT-подразделение является ключевым звеном многих компаний. По этой причине в случае бедствия (природного или цифрового), которое зачастую прерывает выполнение сетевых операций, многие предприятия просто прекращают свою деятельность. Вместе с тем всеобщее признание Интернета в качестве глобальной среды общения вывело компьютеры из сферы бизнеса и академического мира и .приблизило к частной жизни, в которой сеть используется не просто для развлечения, а для поддержания связи с родными и близкими.
Хотя в целом эта книга посвящена сетевой безопасности, содержащаяся в ней информация распространяется и на другие сферы. Как-никак, сеть — это просто средство соединения машин и серверов. Однако данная глава посвящена в основном безопасности и целостности самой сети. Мы научимся обнаруживать и предотвращать некоторые типы спуфинга (spoofing attacks), который может использоваться для подрыва стержневой целостности Ethernet-сетей, использующих протокол TCP/IP, на самом нижнем уровне. В этой главе мы подробно рассмотрим применение межсетевых экранов (брандмауэров) (firewalls) с различными целями: от экранизации сетей, основанной на портах, до фильтрации МАС-адресов, — а также познакомимся с созданием шлюза, который будет проверять полномочия машин, основываясь на данных учетных записей.
Хотя сетевая разведка и не несет прямой угрозы сети, она обычно предшествует атаке. В этой главе мы узнаем, как обмануть тех, кто пытается собирать информацию об узлах вашей сети, а также рассмотрим способы обнаружения «подслуши- вателей», проводящих мониторинг сети в поисках лакомого кусочка информации.
ТРЮК№ 31ТРЮК№ 31Обнаружение ARP-спуфинга
ТРЮК№ 31
ТРЮК№ 31
Проверьте, не представляется ли кто-нибудь вашим сервером.
Одной из крупнейших угроз компьютерным сетям являются мошеннические системы, притворяющиеся узлом, которому доверяют. Кто-либо, успешно представившийся другим узлом, может сделать много неприятных вещей. Например, он
может перехватить и протоколировать трафик, направляемый другому узлу, либо обмануть цодключившихся клиентов и перехватить конфиденциальную информацию. Спуфинг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-адрес).
В соответствует МАС-адресу узла С. После этого он искажает 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 1install
При запуске 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)
Nov1 01:03:23zularpwatch:flipflop 1192.168.0.650:50:ba:85:85:ca(0:e0:81:3:d8:8e)
Nov1 01:03:25zularpwatch:flipflop 1192.168.0.650:e0:81:3:d8:8e(0:50:ba:85:85:ca)
В данном случае первая запись — от первого принятого ложного ARP-ответа, а две последующие записи возникли из-за состояния гонок между ложным и правильным ответами.
Для облегчения работы с несколькими Arpwatch в коммутируемой среде можно посылать сообщения протоколирования в центральный системный журнал (трюк № 54), собирая все результаты в одном месте. Однако из-за того, что компьютеры могут находиться под воздействием атак, подобных той, что обнаруживает Arpwatch, на сервере с системным журналом, а также на всех узлах, на которых установлена Arpwatch, разумнее использовать статические записи ARP-таблиц (трюк № 32).
8585Трюк № 32. Создайте статическую ARP-таблицу
85
85
ТРЮКNs 32ТРЮКNs 32Создайте статическую ARP-таблицу
ТРЮК
Ns 32
ТРЮК
Ns 32
Для борьбы со спуфингом и прочей разрушительной деятельностью используйте статические записи 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 <1тогц ip> <to ip>
#
my ($start_l. $start_2. $start_3. $start_4) = sp!1t(/\./. $ARGV[O]. 4);
my (Send 1. $end_2. $end_3. $end_4) - spTit(/V/. $ARGV[1], 4):
my $ARP_CMD-"/sb7n/arp -n":
for(my $oct_l - $start_l: Soct_l <- Send_l && $oct_l <- 255: $oct_l++ ){ for(my $oct_2 - $start_2: $oct_2 <- $end_2 && $oct_2 <- 255: $oct_2++){ for(my $oct_3 - $start_3: $oct_3 <- $end_3 && $oct_3 <- 255: $oct_3++){ for(my $oct_4 - $start_4: $oct_4 <- $end_4 && $oct_4 < 255: $oct_4++){ systemCping -c 1 -W 1 $oct_l.$oct_2.$oct_3.$oct_4 > /dev/null 2>&1")-.
my $ether_addr - "$ARP_CMD $oct_l.$oct_2.$oct_3.$oct_4 | egrep
'HWaddress|(incomplete?' | awk '(print \$3}":
chomp($ether_addr):
if(length($ether_addr) — 17){
print("$ether_addr\t$oct_l.$oct 2.$oct_3.$oct_4\n"):
)
}
} }
Этот сценарий поочередно «прозванивает» (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 перестала соответствовать все более делающимся конфигурациям, в настоящее время она используется очень редко. Программа второго
поколения 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) — минимальный набор для нормальной работы сервера в Сети.
Однако перед определением правил необходимо отменить фильтрацию в интерфейсе обратной связи (loopback interface):
iptables -Р INPUT -1 lo -j ACCEPT
iptables -P OUTPUT -o lo -j ACCEPT
Теперь зададим правило, позволяющее пропускать трафик. Сначала укажем правило, разрешающее прохождение трафика по 80-му TCP-порту — стандартному порту для web-серверов — для свободной передачи его web-серверу сквозь межсетевой экран:
iptables -A FORWARD -m state --state NEW -p tep \
d 192.168.1.20 -dport 80 -j ACCEPT
А теперь то же самое сделаем для почтового сервера, который для протокола SMTP использует 25-й ТСР-порт:
iptables -A FORWARD -m state --state NEW -p tep \
d 192.168.1.21 --dport 25 -j ACCEPT
Дополнительно необходимо разрешить удаленный POP3-, IMAP- и IMAP+SSL- доступ:
POP3
# iptables -A FORWARD -m state --state NEW -p
tep
\
-d 192.168.1.21 --dport
110 -j ACCEPT
IMAP
# iptables -A FORWARD -m
state --state NEW -p
tep
\
-d 192.168.1.21 --dport
143 -j ACCEPT
IMAP+SSL
# iptables -A FORWARD -m
state --state NEW -p
top
\
-d 192.168.1.21 --dport
993 -j ACCEPT
В отличие от других служб, DNS может использовать как TCP, так и 53-й UDP-порт:
iptables -A FORWARD -m state --state NEW -р tep \
d 192.168.1.21 --dport 53 -j ACCEPT
Поскольку мы используем стандартную политику отказа в доступе (DROP), использовать UDP для DNS довольно сложно из-за того, что наша политика основывается на использовании правил, отслеживающих состояние, a UDP — протокол без проверки состояния. В этом случае можно настроить DNS-сервер на формирование ответов, которые отправляются клиентам, применяющим UDP для запросов к серверу доменных имен, с использованием либо только TCP, либо только 53-го UDP-порта.
Если DNS-сервер настроен так, что отвечает клиентам с помощью 53-го UDP-nop- та, передача его трафика разрешается двумя следующими правилами:
iptables -A FORWARD -р udp -d 192.168.1.18 --dport 53 -j ACCEPT
iptables -A FORWARD -p udp -s 192.168.1.18 --sport 53 -j ACCEPT
Первое правило разрешает передавать в нашей сети трафик, предназначенный для 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
Она заставляет ядро пересылать при необходимости пакеты между интерфейсами. Для того чтобы эта операция выполнялась автоматически в ходе загрузки системы, добавьте в /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,
эта команда не используется для указания отдельных правил. Вместо этого она использует собственную конфигурацию и язык определения правил. Настраивается PF с помощью файла /etc/pf.conf. Язык определения правил очень мощный, удобный и простой в использовании. Файл pf.conf имеет семь разделов, в каждом из которых содержится определенный тип правил. Использование всех разделов не является обязательным; если определенный тип правил не требуется, этот раздел может быть просто исключен из файла.
Первый раздел предназначен для макросов. В нем можно указать переменные, которые будут содержать как отдельные значения, так и список значений, используемых в последующих разделах файла настройки. Так же как переменные окружения или идентификатор языка программирования, имя макроса должно начинаться с буквы и может содержать цифры и знак подчеркивания.
Вот примеры макросов:
EXTJF="deO"
INTJF=Mdel"
RFC1918="{ 1192.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 <rfcl918> 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 <rfcl918>
С помощью ключевого слова f ii 1 e можно загрузить список IP-адресов:
table <spammers> file "/etc/spammers.table"
Если вы решите не использовать ключевое слово const, то сохранится возможность добавлять адреса в таблицу:
pfctl -t spammers -T add 110.1.1.1
Кроме того, адреса можно и удалять:
pfctl -t spammers -T delete 10.1.1.1
Для вывода содержания таблицы можно запустить команду
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 также может оптимизировать производительность аппаратного обеспечения на низком уровне, корректируя использование памяти в зависимости от
количества одновременно хранимых состояний либо от количества фрагментов, которые могут размещаться в памяти для повторной сборки. Например, установив количество состояний равным 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 можно использовать для повторного воссоединения дефрагментированных пакетов перед перенаправлением их к пункту назначения. Это поможет предотвратить «ускользание» специально фрагментированных пакетов (например, накладывающихся) от систем обнаружения вторжения, расположенных с внешней стороны межсетевого экрана.
Для включения повторной сборки фрагментов во всех интерфейсах просто поместите в файл настройки строку
scrub fragment reassemble
Если есть желание ограничить воссоединение только одним интерфейсом, можно заменить ее следующей:
scrub in on deO all fragment reassemble
Это включит воссоединение фрагментов в интерфейсе deO.
Следующие два раздела файла pf .conf определяют формирование очередей пакетов и трансляцию адресов, но, поскольку этот трюк посвящен фильтрации пакетов, мы их пропустим и окажемся перед последним разделом. Он содержит действительные правила фильтрации пакетов. В общем случае синтаксис правила фильтрации выглядит так:
action direction 1 [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 изменяет это поведение и приводит к остановке обработки пакета при соответствии правилу, а также предпринимает указанное действие. При осторожном использовании это может в значительной степени повысить производительность набора правил.
Для защиты внешних узлов от спуфинга внешних адресов можно использовать ключевое слово anti spoof:
antispoof quick for $INT_IF inet
Далее нам необходимо блокировать любые пакеты со входа или выхода внешнего интерфейса, имеющего немаршрутазируемый IP-адрес RFC 1918. Такие пакеты, если не указаны позднее явно, будут «отловлены» нашей политикой отказа (deny policy). Однако если использовать правило, специально соответствующее этим пакетам, и использовать ключевое слово quick, мы сможем повысить производительность добавлением следующего правила:
block drop quick on $EXTIF from any to <rfcl918>
Если необходимо сделать так, чтобы трафик нашей сети предназначался для web- сервера с адресом 192.168.1.20, то необходимо использовать следующее правило: pass in on $EXTIF 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 $EXTIF 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 $EXTIF proto tcp from any to 192.168.1.18 port 53 \
modulate state flags S/SA
При этом межсетевой экран по-прежнему осуществляет блокировку UDP DNS- трафика. Для его включения добавьте следующее правило:
pass in on $EXTIF proto udp from any to 192.168.1.18 port 53 \
keep state
Обратите внимание на то, что, хотя это правило для UDP-пакетов, мы все равно используем ключевое слово state. В этом случае PF будет отслеживать соединение, используя IP-адреса источника и пункта назначения, а также пары портов.
Поскольку UDP-дейтаграммы не содержат последовательного номера, ключевое слово modulate не применяется. Вместо этого используется слово keep state, которое определяет, как указать инспекцию состояния, когда ISN не модулируются. Кроме того, UDP-дейтаграммы не содержат флагов; мы их просто опускаем. Теперь можно разрешить, чтобы соединение, инициируемое из внешней сети, проходило через межсетевой экран. Для этого необходимо добавить следующие правила, разрешающие трафик во внутреннем интерфейсе межсетевого экрана: pass in on $INT IF from $INT _ IF:network to any pass out on $INT ] IF from any to $INT _IF:network pass outon$EXT _ IF prototcp allmodulate stateflagsS/SA
pass outon$EXTIF proto{ icmp,udp } all keepstate
Как видим, OpenBSD имеет очень мощную и гибкую систему разделения сетей. В ней имеется слишком много возможностей и функций, которые мы здесь рассмотреть не можем. Дополнительную информацию можно найти в удобной документации по PF, находящейся в сети или в справке pf.conf manpage.
Создание шлюза с проверкой полномочий
Используйте PF, чтобы не допустить в сеть пользователей, не подтвердивших своих полномочий.
Шлюзы межсетевой защиты традиционно использовались для блокировки трафика от определенных служб или машин. Вместо просмотра IP-адресов и номеров портов, шлюз с проверкой полномочий позволяет регулировать двусторонний трафик от машин, основываясь на мандате пользователя. При использовании такого шлюза пользователь должен зарегистрироваться в сети и удостоверить свои полномочия для того, чтобы шлюз предоставил ему доступ к защищаемой сети. Это может быть полезно во многих случаях, например при ограничении интернет-доступа или ограничении доступа через беспроводный сегмент сети.
При использовании ОС OpenBSD версии 3.1 такую функциональность можно реализовать за счет использования PF и ядра authpf. Использование authpf также дает возможность проводить аудит, протоколируя имена пользователей, входящих в сеть, создаваемые IP-адреса, а также время их входа в сеть и выхода из нее. Для включения проверки полномочий с помощью authpf необходимо на шлюзе создать учетную запись для каждого пользователя. Укажите в качестве ядра /usr/sbin/authpf и не забудьте добавить authpf в /etc/shells в качестве действительного ядра. Когда пользователь входит в систему через SSH, authpf получает имя пользователя и IP-адрес через окружение. После этого считывается файл шаблона, содержащий NAT и правила фильтрации, и к нему применяются имя пользователя и IP-адрес. После этого результирующие правила добавляются в исполняемую конфигурацию. При выходе пользователя из системы (то есть при вводе
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
Dec 3 22:47:21 zul authpf[15058]: removed 192.168.0.61. \
user andrew- duration 650 seconds
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 и саму операционную систему при проверке полномочий и управлении сеансами.
ТРЮКMs 36ТРЮКMs 36МежсетевойэкранвWindows
ТРЮК
Ms 36
ТРЮК
Ms 36
Да, Windows тоже можно использовать в качестве межсетевого экрана.
Возможно, вы не знали, но Windows имеет очень качественный встроенный межсетевой экран. Для его запуска необходимо открыть консоль управления (Microsoft Management Console, MMC). Это можно сделать с помощью диалогового окна Выполнить (Run), введя в нем mmc и щелкнув на кнопке ОК. После загрузки консоли вы увидите окно, подобное представленному на рис. 3.1.
Рис. 3.1 . Консоль управления WindowsРис. 3.1 . Консоль управления Windows
Рис. 3.1 . Консоль управления Windows
Рис. 3.1 . Консоль управления Windows
Щелкните на меню Консоль (Console) и выберите пункт Добавить/Удалить оснастку (Add/Remove Snap-in). Далее будет представлено диалоговое окно, имеющее кнопку Добавить (Add). После щелчка на этой кнопке появится окно со списком доступных оснасток. Прокрутите список и найдите в нем пункт Управление политикой безопасности (IP Security Policy Management) (рис. 3.2).
I Vendor Microsoft CorporationI Vendor Microsoft CorporationAdd Standalone SiAdd Standalone SiAvailable Standalone Snap nsAvailable Standalone Snap nsCloseCloseMicrosoft CorporationMicrosoft Corporation. In,Microsoft CorporationMicrosoft Corporation. In,Microsoft CorporationMicrosoft Corporation HighG round Systems. Inc.Microsoft CorporationMicrosoft Corporation HighG round Systems. Inc.Internet Protocol Security (IPSec) Administration Manage IPSec poic*s lor secure commurxcecn with other computesInternet Protocol Security (IPSec) Administration Manage IPSec poic*s lor secure commurxcecn with other computes2 Is* to Web AddressLocal Uses and Grocers 0 Peformance Logs and Alerts ^ Removable Storage Management2 Is* to Web AddressLocal Uses and Grocers 0 Peformance Logs and Alerts ^ Removable Storage ManagementSnap-n^Fax Sevice ManagementLJFoldeDFronlPage Serve Extensions Group PolicyЙ Indexing SeviceSnap-n^Fax Sevice ManagementLJFoldeDFronlPage Serve Extensions Group PolicyЙ Indexing Sevice
I Vendor Microsoft Corporation
I Vendor Microsoft Corporation
Add Standalone Si
Add Standalone Si
Available Standalone Snap ns
Available Standalone Snap ns
Close
Close
Microsoft Corporation
Microsoft Corporation. In,
Microsoft Corporation
Microsoft Corporation. In,
Microsoft Corporation
Microsoft Corporation HighG round Systems. Inc.
Microsoft Corporation
Microsoft Corporation HighG round Systems. Inc.
Internet Protocol Security (IPSec) Administration Manage IPSec poic*s lor secure commurxcecn with other computes
Internet Protocol Security (IPSec) Administration Manage IPSec poic*s lor secure commurxcecn with other computes
2 Is* to Web Address
Local Uses and Grocers 0 Peformance Logs and Alerts ^ Removable Storage Management
2 Is* to Web Address
Local Uses and Grocers 0 Peformance Logs and Alerts ^ Removable Storage Management
Snap-n
^Fax Sevice Management
LJFolde
DFronlPage Serve Extensions Group Policy
Й Indexing Sevice
Snap-n
^Fax Sevice Management
LJFolde
DFronlPage Serve Extensions Group Policy
Й Indexing Sevice
Рис. З.2. Добавление оснастки IP Security Policy Management
Щелкните на кнопке Добавить (Add). Появится диалоговое окно, уточняющее, чем должна управлять оснастка — локальным компьютером или доменом. Определитесь, хотите ли вы применять настройки фильтра только к локальному компьютеру или ко всему домену, и щелкните на кнопке Готово (Finish). Щелкните на кнопке Закрыть (Close) в диалоговом окне выбора оснастки (см. рис. 3.2). Теперь оснастка IP Security Policies должна быть указана в окне добавления оснасток (рис. 3.3). Щелкните на кнопке ОК для возврата в исходное окно консоли управления.
Перед настройкой правил межсетевого экрана необходимо создать для них блок действий. Для этого щелкните правой кнопкой на значке IP Security Policies и выберите пункт Управление списком IP-фильтров и действиями фильтра (Manage IP
filter lists and filter actions). После открытия окна перейдите на вкладку Управление действиями фильтра (Manage Filter Actions) (рис. 3.4).
Рис. 3.3. Диалоговое окно добавления оснастки с загруженной оснасткой IP Security Policies
Рис. З.4. Вкладка Управление действиями фильтра (Manage Filter Actions)
Если флажок Использовать мастер добавления (Use Add Wizard) не установлен, установите его. Щелкните на кнопке Добавить (Add), а после открытия диалогового окна мастера — на кнопке Далее (Next). После этого в качестве имени нового действия фильтра введите Block. В качестве описания введите: Блокировка доступа или что-либо подобное. После заполнения полей щелкните на кнопке Далее. Затем выберите переключатель Block и снова щелкните на кнопке Далее. После этого щелкните на кнопке Готово (Finish).Tenepb новое действие фильтра должно быть представлено в окне добавления оснастки (см. рис. 3.3). Сейчас можно щелкнуть на кнопке Закрыть (Close).
После этого можно приступить к настройке правил межсетевого экрана. Щелкните правой кнопкой на значке политики безопасности и выберите пункт Создать политику IP-безопасности (Create IP Security Policy). Это приведет к включению мастера. Щелкните на кнопке Далее и заполните поля Имя и Описание (в обоих полях можно ввести FireWal 1). После заполнения полей щелкните на кнопке Далее. Теперь должен появиться флажок Активировать правило отклика по умолчанию (Activate the default response rule). Сбросьте этот флажок и щелкните на кнопке Далее. После этого щелкните на кнопке Готово. Должно появиться диалоговое окно свойств межсетевого экрана (рис. 3.5).
Рис. З.5. Диалоговое окно свойств межсетевого экрана
Для создания нового правила фильтрации сбросьте флажок Использовать мастер добавления (Use Add Wizard) и щелкните на кнопке Добавить. Появится диалоговое окно, представленное на рис. 3.6.
Рис. 3.6. Добавление нового правила
Для выбора необходимого IP-адреса щелкните на кнопке Добавить на вкладке Список IP-фильтров (IP Filter List). Это также позволит определить порты и протоколы. Если после выбора IP-адресов и портов вы захотите применить новое правило, перейдите на вкладку Действие фильтра (Filter Action) и выберите необходимое действие.
ТРЮК№37ТРЮК№37Держите сеть изолированной
ТРЮК
№37
ТРЮК
№37
Используйте исходящую фильтрацию для сдерживания атак и утечки информации из сети.
Вы, вероятно, знакомы с концепцией межсетевого экранирования (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-сервера.
Аналогично, если имеется внутренний почтовый сервер, то почта компании не должна «ходить» по Интернету. Вы же не хотите, чтобы сотрудники имели возможность подключаться к серверам за пределами сети?
Достигается это использованием подобного правила:
rdr on $INT_IF inet proto tcp from $INT_IF:network to any port 25 -> $SMTPHOST port 25
Исходящая фильтрация помогает также предотвратить IP-спуфинг на внешнем интерфейсе, находящемся на границе сети. Можно проверить, что пакеты, покидающие вашу сеть, имеют адрес источника, попадающий в ваше адресное пространство. За счет фильтрации остального трафика вы сможете гарантировать, что любая атака типа «IP-спуфинг», выполняемая из вашей сети или маршрутизируемая через нее, будет сброшена до того, как пакеты покинут сеть.
ТРЮК№ 38ТРЮК№ 38Проверьте ваш межсетевой экран
ТРЮК
№ 38
ТРЮК
№ 38
Проверьте, действительно ли межсетевой экран работает так, как вы хотели.
Итак, вы настроили межсетевой экран и выполнили поверхностное тестирование его работы. А вы проверили, что он может блокировать все, для чего предназначен? Вы не сделали этого, поскольку думали, что все и так хорошо, а проверка займет слишком много времени. К счастью, существует 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"
После того как модули станут доступными в системе, необходимо создать файл настройки, указывающий 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:
1025:10.1.1.1:1-1025:S:TCP:О
stop_signal=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 получает сигнал остановки, он прекра-
щает работу. После завершения работы в протоколе (ftestd.log) можно найти прошедшие пакеты. Далее можно скопировать протоколы на одну машину и сравнить их с помощью freport. При использовании представленного ранее файла настройки и при разрешенном SSH-, SMPTP- и HTTP-трафике отчет должен
выглядеть примерно так:
# ./freport ftest.log ftestd.log
Authorized packets:
22 -192.168.1.10:1025>10.1.1.1:22STCP0
25 -192.168.1.10:1025>10.1.1.1:25STCP0
80 -192.168.1.10:1025>10.1.1.1:80STCP0
Modified packets (probably NAT):
Filtered or dropped packets
1 -192.168.1.10:1025>10.1.1.1:1STCP0
2 -192.168.1.10:1025>10.1.1.1:2STCP0
3 -192.168.1.10:1025>10.1.1.1:3STCP0
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 всякий раз после внесения изменений в межсетевой эк-
ран либо периодически — для того, чтобы проверить правильность его работы.
его поведеего поведеПоскольку сложный набор правил межсетевого экрана усложняет предсказаниеПоскольку сложный набор правил межсетевого экрана усложняет предсказаниеНе допускайте в сеть нежелательные машины, проверяя МАС-адрес.Не допускайте в сеть нежелательные машины, проверяя МАС-адрес.
его поведе
его поведе
Поскольку сложный набор правил межсетевого экрана усложняет предсказание
Поскольку сложный набор правил межсетевого экрана усложняет предсказание
Не допускайте в сеть нежелательные машины, проверяя МАС-адрес.
Не допускайте в сеть нежелательные машины, проверяя МАС-адрес.
Фильтрация МАС-адресов (Media Access Control, MAC) — это хорошо известный метод защиты беспроводных сетей. Этот тип фильтрации основан на принципе отказа по умолчанию: специально указываются узлы, которым разрешено соединение, остальные — не допускаются. МАС-адрес — это уникальное 48-разряд- ное число, которое присваивается каждому производимому Ethernet-устройству, включая устройства стандарта 802.11. Это число обычно записывается как шесть 8-разрядных шестнадцатеричных чисел, разделенных двоеточиями.
В дополнение к «родной» системе фильтрации 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. Использование подобных правил совместно с политикой отказа по умолчанию позволяет создавать «белый список» МАС-адресов, которые смогут проходить через шлюз. Для создания «черного списка» можно использовать политику разрешения по умолчаниюI PI изменить МАС-адрес, соответствующий конечному правилу, на DENY (отказ).
Это все очень просто, если вы заранее знаете МАС-адреса, для которых собираетесь создавать правила, а что делать, если они иеизвестны? Если имеется доступ к системе, то МАС-адрес интерфейса можно найти сI помощью команды1 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.
Например, для I просмотра МАС-адреса, I соответствующего 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 $11 | awk '{print $3}' \
| grep -v Hwaddress
При реализации МАС-фильтрации учтите, что она не защищает «от дурака». При некоторых обстоятельствах не очень сложно изменить МАС-адрес, который используется интерфейсной картой (сетевым адаптером), просто «попросив» об этом драйвер. Также существует возможность с помощью необработанных (raw) сокетов канального уровня отправлять фреймы канального уровня, содержащие фальшивый МАС-адрес. Таким образом, фильтрация МАС-адреса может рассматриваться как дополнительная мера, которую можно использовать для защиты среды. Эта фильтрация больше похожа на табличку «Вход воспрещен», чем на надежный дверной запор.
ТРЮК№ 40ТРЮК№ 40Блокировка «снятия отпечатков пальцев» ОС
ТРЮК
№ 40
ТРЮК
№ 40
Поддерживайте в отношении посторонних принцип «необходимого знания» о вашей ОС.
Одним из наиболее лакомых для атакующего кусочков информации, который можно добыть в ходе сетевой разведки, является тип операционной системы на каждой выявленной при сканировании машине. С точки зрения взломщика, очень полезно разгадать, какие уязвимые места имеет система и какими ее изъянами можно воспользоваться. Совместно со знаниями об открытых портах, найденных в ходе сканирования, эта информация может использоваться в разрушительных целях. Использование RPC для SPARC Solaris, скорее всего, не сработает в ОС х86 Linux — программный код для демона portmap специфичен в каждой из этих систем, использующих различные процессорные архитектуры. Взломщик, вооруженный знаниями о конкретной серверной платформе, может очень эффективно использовать методики, которые позволят ему получить более высокий уровень доступа, не тратя время на перебор методов, которые не работают.
Конечно, лица, выполняющие сетевую разведку, могли бы просто подключиться к любой службе, обнаруженной в ходе сканирования портов, и посмотреть, какая ОС используется на удаленной системе. Такой подход сработает, поскольку многие демоны, такие как Sendmail, Telnet и даже FTP, охотно сообщают операционную систему, в которой работают, а также номер своей версии. Несмотря на то что этот метод совершенно прост и ясен, в настоящее время он рассматривается как оставляющий следы, поскольку с помощью файлов протокола не составляет никакого труда «вычислить» любого, кто подключался к системе. Кроме того, многие службы могут быть настроены на сокрытие этой важной информации. В ответ на это было разработано множество усовершенствованных методов, не требующих для определения типа ОС полного подключения к целевой системе. Они основаны на «странностях» TCP/IP-стека операционной системы узла и его поведении при отклике на определенные типы пакетов. Из-за того что разные операционные системы по-разному откликаются на эти пакеты, можно
с большой степенью вероятности «угадывать», на какой ОС основана работа конкретного сервера, не оставляя следов в файлах протокола. К счастью, «пробные» пакеты могут блокироваться межсетевым экраном, что расстраивает попытки определить ОС этим способом.
Одним из наиболее известных средств определения типа ОС является программа 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 1 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 I IP address ((1 I host up) scanned in 24.873 seconds
Для пресечения попыток сканирования с помощью Nmap можно использовать правила межсетевого экрана, блокирующие пакеты, используемые для зондирования ОС. Их легко (обнаружить, поскольку некоторые из них имеют недействительные сочетания TCP-флагов. Ряд тестов, Jпроводимых Nmap, невозможно блокировать с помощью PF, лишь добавив правила блокировки, но их можно перехватить, используя фильтрацию с проверкой состояния или применяя для набора правил политику отказа по умолчанию. Такие меры необходимы из-за того, что тесты используют TCP-параметры, которые невозможно выделить с помощью PF.
Для блокировки попыток снять «отпечатки пальцев» в ОС OpenBSD можно использовать подобные правила (в файле /etc/pf.conf):
set block-policy return
block in log quick proto tcp fflags F FUP/WEUAPRSF
block in log quick proto t tcpf flags WEUAPRSF/WEUAPRSF
block in log quick I proto tcp f flagsS SRAFU/WEUAPRSF
block in log quick proto tcp flags /WEUAPRSF
block in log quick proto tcp flags SR/SR
block in log quick proto tcp flags SF/SF
Этот прием также имеет побочный эффект протоколирования всех попыток в отношении интерфейса pflogO. Даже если мы не можем блокировать все проверки с помощью Nmap, то можем протоколировать хотя бы наиболее неординарные попытки и, возможно, iнейтрализовать их, :представив неполную картину поведе-
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Как видим, на этот раз попытка оказалась неудачной. А если вы чувствуете, что этого может оказаться недостаточно? Что если вы действительно хотели бы ис-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Как видим, на этот раз попытка оказалась неудачной. А если вы чувствуете, что этого может оказаться недостаточно? Что если вы действительно хотели бы ис-
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
Как видим, на этот раз попытка оказалась неудачной. А если вы чувствуете, что этого может оказаться недостаточно? Что если вы действительно хотели бы ис-
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), отпугивающую негодяев от критических серверов. Если вам пока смешно, читайте дальше.
ТРЮКNo 41ТРЮКNo 41Обман программ удаленного определения ОС
ТРЮК
No 41
ТРЮК
No 41
Не позволяйте удаленно определять тип вашей ОС, изменив облик TCP/IP-стека
Еще один метод, являющийся преградой на пути попыток удаленного управления, — изменение поведения TCP/IP-стека и эмулирование работы другой ОС. Возможно, это кажется сложным, но в Linux реализуется очень просто: внесением
изменения в ядро с помощью программного кода проекта 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.
||||t*extt*extХЖХЖJPrevJPrev11Рис. З.7. Включение поддержки IP PersonalityРис. З.7. Включение поддержки IP Personality
|
|
|
|
t*ext
t*ext
ХЖ
ХЖ
JPrev
JPrev
1
1
Рис. З.7. Включение поддержки IP Personality
Рис. З.7. Включение поддержки IP Personality
После загрузки и распаковки необходимой версии ее необходимо скорректировать с помощью программы исправления, входящей в состав пакета IP Personality, после чего скомпоновать и установить обычным способом:
ttar xfj 1iptables-1.2.2.tar.bz2
cd 1iptables-1.2.2
patch -pi < \
../ippersonality-20020819-2.4.19/patches/ippersonality-20020427-iptables-\
diff
patching file pers/Makefile
patching file pers/example.conf
patching file pers/1ibipt_PERS.с
patching file pers/pers.h
patching file pers/pers.l
patching file pers/pers.y
patching file pers/pers_asm.c
patching file pers/perscc.c
make KERNEL_DIR=/usr/src/linux && make install
При этом б^дет установлена обновленная версия команды iptables, которая поддерживает библиотеки и справочник manpage, располагающийся в иерархии /usr/local. Если вы хотите изменить заданные по умолчанию каталоги, можно отредактировать Makefile и изменить значения макросов BINDIR, LIBDIR, MANDIR и INCDIR. Проверьте, соответствует ли значение KERNEL_DIR каталогу, содержащему исходный код построенного ранее ядра.
При использовании Red Hat Linux команду iptables можно заменить, то есть установить новые значения в макросах:
LIBDIR:=/lib
BINDIR:=/sbin
MANDIR:=/usr/share/man
INCDIR:=/usr/1nclude
Помимо запуска make install, вы можете также создать каталог для персональных настроечных файлов операционной системы. Эти файлы помещены в каталог samples/ в дистрибутиве IP Personality. Например, можно создать каталог /etc/ personalities и скопировать их в него.
Перед настройкой IP Personality попробуйте запустить Nmap в отношении какой-либо машины, чтобы проверить, какая ОС будет определена:
nmap -0 colossus
Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-12-12 18:36 MST
Interesting ports on colossus (192.168.0.64):
(The 1651 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
111/tcp open rpcbind
139/tcp open netbios-ssn
505/tcp open mail box-Im
631/tcp open ipp
Device type: general purpose
Running: Linux 2.4.X|2.5.X
OS details: Linux Kernel 2.4.0 - 2.5.20
Uptime 3.095 days (since Tue Dec 9 16:19:55 2003)
Nmap run completed -- 1 IP address (1 host up) scanned in 7.375 seconds
Если ваша машина имеет адрес 192.168.0.64 и вы хотите, чтобы она сообщала о том, что работает под Mac OS 9, то запустите команду iptables:
iptables -t mangle -A PREROUTING -d 192.168.0.64 -j PERS \
-tweak dst --local --conf /etc/personalities/macos9.conf
iptables -t mangle -A OUTPUT -s 192.168.0.64 -j PERS \
--tweak src --local --conf /etc/personalities/macos9.conf
Теперь снова запустите Nmap:
nmap -0 colossus
Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-12-12 18:47 MST
Interesting ports on colossus (192.168.0.64):
(The 1651 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp
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
111/tcp open rpcbind
139/tcp open netbios-ssn
505/tcp open mailbox-lm
631/tcp open ipp
Device type: general purpose
OS details: Apple Mac OS 9 - 9.1OS details: Apple Mac OS 9 - 9.1Uptime 3.09Uptime 3.09Running: Apple Mac OS 9.X
OS details: Apple Mac OS 9 - 9.1
OS details: Apple Mac OS 9 - 9.1
Uptime 3.09
Uptime 3.09
Nmap runКонечнIPоNmap runКонечнIPо5.274 seconds
Nmap run
КонечнIPо
Nmap run
КонечнIPо
жСе, пмоомжонщоьюэмNуmлиapроовтастльежиидврауйгтиееусОтрСо,йксоттвоариысел нуже бпыревдаушсемйостертеин.ы па- Personality. Все, что нужно сделать для этого, — скопировать файл «от-
печатков пальцев» операционной системы утилитой Nmap (nmap-os-fingerprints),
оцекво»тоОрСой» з(нсмае.ттNрюmкap№. 40), Nmap (http://www.insecure.org/nmap/), это бесплат-
ное средство, которое может использоваться для выполнения различного типа сканирования сетей. Обычно Nmap рассматривается как программа, которая используется для различного рода сетевой разведки или подготовки к атаке. Но, как и все мощные средства, Nmap может использоваться не только для нарушения работы сетей. Например, простое сканирование TCP-подключений может выполняться без наличия root-привилегий:
$ nmap rigel
(The 1595 ports scanned but not shown below are in state: filtered)
PORT
STATE
SERVICE.
7/tcp
open
echo
9/tcp
open
discard
13/tcp
open
daytime
19/tcp
open
chargen .
21/tcp
open
ftp
22/tcp
open
ssh
23/tcp
open
telnet
25/tcp
open
smtp
37/tcp
open
time
79/tcp
open
finger
111/tcp
open
rpcbind
512/tcp
open
exec
Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-12-15 17:42 MST
Interesting ports on rigel (192.168.0.61):
513/tcp
open
login
514/tcp
open
shell
587/tcp
open
submission
4045/tcp
open
lockd
7100/tcp
open
font-service
32771/tcp
open
sometimes-rpc5
32772/tcp
open
sometimes-rpc7
32773/tcp
open
sometimes-rpc9
32774/tcp
open
sometimes-rpcll
32775/tcp
open
sometimes-rpcl3
32776/tcp
open
sometimes-rpcl5
32777/tcp
open
sometimes-rpcl7
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 -s
S -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)
Port
State
Service
7/tcp
open
echo
9/tcp
open
discard
13/tcp
open
daytime
19/tcp
open
chargen
21/tcp
open
ftp
22/tcp
open
ssh
23/tcp
open
telnet
25/tcp
open
smtp
37/tcp
open
time
79/tcp
open
finger
111/tcp
open
sunrpc.
512/tcp
open
exec
513/tcp
open
login
514/tcp
open
shell
587/tcp
open
submission
7100/tcp
open
font-service
32771/tcp
open
sometimes-rpc5
32772/tcp
open
sometimes-rpc7
32773/tcp
open
• sometimes-rpc9
32774/tcp
open
sometimes-rpcll
32775/tcp
open
sometimes-rpcl3
32776/tcp
open
sometimes-rpcl5
32777/tcp
open
sometimes-rpcl7
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
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-файл, который затем можно анализировать и добавить в базу данных. Вот как пред-
Nmap — очень мощное средство. При выводе результатов в XML, написании небольшого сценария и использовании базы данных вы можете создать более серьезное средство, которое будет наблюдать за появлением в сети несанкционированных служб и машин.
Проверка надежности сети
Используйте Nessus для быстрого и простого сканирования сети служб, уязвимых для атак.
Как администратор сети вы должны знать не только узлы и запущенные на них службы, но и устойчивы ли эти службы к атакам. Если Nmap (см. трюк № 40) может лишь показать машины и порты, доступные в сети, то сканер безопасности, такой как Nessus (http://www.nessus.org), может сказать, устойчивы ли машины к известным посягательствам.
В отличие от обычного сканера портов, сканер безопасности сначала находит «слушающие» службы, а затем подключается к ним и пытается выполнить в отношении них все известные ему действия. После этого сканер фиксирует успешность попыток и продолжает работать, пока не протестирует все доступные службы. Ключевое преимущество программы заключается в том, что вы сразу узнаете, устоит ли система против самых распространенных посягательств и сможет ли она противостоять атаке.
Если хватит смелости, то установите 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
Теперь можно запустить Nessus-клиент и подключить его к серверу. Существует несколько доступных клиентов, включая интерфейс командной строки, приложение XII и Windows-клиент. Здесь представлен вид в интерфейсе XII. Запуск клиента производится просто вводом nessus. После этого появится окно, подобное представленному на рис. 3.8.
Рис. 3.8. Установка Nessus-клиента
В окне требуется заполнить необходимые сведения о пользователе и щелкнуть на кнопке Login (Вход). После этого откроется диалоговое окно, позволяющее проверить сведения, содержащиеся в сертификаторе сервера. Для выбора типов сканирования слабых мест в системе защиты перейдите на вкладку Plugins (Надстройки) (рис. 3.9).
В верхней панели можно включить или отключить различные типы сканирования, а в нижней — отключить отдельные проверки на уязвимость, относящиеся к выбранному в верхней панели типу. Необходимо отметить, что перечисленные в нижней панели проверки, помеченные восклицательным знаком, потенциально могут привести к крушению сервера, к которому будут применены. Если вы хотите разрешить все проверки', кроме этих, щелкните на кнопке Enable all but dangerous plugins (Разрешить все, кроме опасных). Если вы запускаете Nessus на некритичной машине, можно оставить эти варианты сканирования включенными.
но вас предупредили! Некоторые типы проверок можно отключить, если только вы не сканируете группу машин с большим разнообразием служб. В противном случае Nessus потратит лишнее время на сканирование служб, которые не запущены. Например, если вы хотите сканировать Solaris-систему, то смело можете отключить надстройки CGI abuses, CISCO, Windows, Peer-To-Peer File Sharing, Backdoors, Firewalls, Windows User Management и Netware.
ис.ис.надстроекнадстроек. .. .
ис.
ис.
надстроек
надстроек
. .
. .
Для более полного тестирования служб нужно предоставить Nessus учетные сведения о различных службах. Таким образом, Nessus сможет действительно зарегистрироваться в проверяемой службе и иметь такой же доступ, как и обычный пользователь. Используемые в работе Nessus учетные записи указываются на вкладке Prefs (Предпочтения) (рис. 3.10).
Рис. 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 (Выбор цели).
После завершения этой операции запустите сканирование, щелкнув на кнопке Start the scan (Пуск сканирования), расположенной в нижней части окна. Теперь откроется окно, представленное на рис. 3.11. В данном случае Nessus выполняет сканирование Solaris-машины.
Рис. 3.11 . Выполнение проверки науязвимость
Результат сканирования представлен на рис. 3.12.
Рис. 3.12. Результат сканирования
Для сканирования множества подсетей их необходимо указать на панели 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 в качестве дополнительного пакета или порта, он может быть установлен в системе, поэтому проверьте ваш дистрибутив или дерево портов: не установлен ли он уже. Если его нет в варианте вашей ОС, вы можете загрузить и откомпилировать его самостоятельно.
Настройка 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: ntp@linuxmedialabs.com
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: ntp@tummy.com
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 подобную строчку:
driftfile /etc/ntp.drift
Конечно, при условии, что вы держите все настроечные ntpd-файлы в /etc/ntp, то следует использовать /etc/ntp/ntp.drift.
Вот и все, просто добавьте ntpd в сценарий запуска, запустите его — и все готово.
ТРЮК№45ТРЮК№45Создание собственного сертификата полномочий
ТРЮК
№45
ТРЮК
№45
Выпишите собственный сертификат полномочий для использования его при шифровании в сети.
Считается, что 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
++++++
+4-*4-**
writing new private key to 1./demoCA/private/cakey.pem'
Enter PEM pass phrase:
Verifying - Enter РЕМ pass phrase
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN There are quite a few fields, but you can leave some blank
For some fields there will be a default value.
If you enter V. the field will be left blank.
Country Name (2 letter code) []:US
State or Province Name (full name) []:Colorado
Locality Name (eg. city) []:Denver
Organization Name (eg. company) []:NonExistant Enterprises
Organizational Unit Name (eg. section) []:IT Services
Common Name (eg. fully qualified host name) []:ca.nonexistantdomain.com
Email Address []:certadmin@nonexistantdomain.com
Обратите внимание на то, что не обязательно иметь root-полномочия, нужно лишь разрешение записи в отношении текущего каталога.
Поздравляем! Вы стали владельцем собственного Certificate Authority. Посмотрите:
$ Is -1 demoCA/
total 16
-rw-r--r--
1 andrew
andrew
1399
3 Dec 19
52 cacert.pem
drwxr-xr-x
2 andrew
andrew
68
3 Dec 19
49 certs
drwxr-xr-x
2 andrew
andrew
68
3 Dec 19
49 crl
-rw-r--r--
1 andrew
andrew
0
3 Dec 19
49 index.txt
drwxr-xr-x
2 andrew
andrew
68
3 Dec 19
49 newcerts
drwxr-xr-x
3 andrew
andrew
102
3 Dec 19
49 private
-rw-r--r--
1 andrew
andrew
3
3 Dec 19
49 serial
Открытый ключ для нового СА содержится в файле 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, для того чтобы его никто не смог прочитать.
До сих пор мы занимались лишь созданием СА. Для действительного создания ключей, которые можно использовать в службах, необходимо создать запрос на подпись сертификата и ключ. Опять же, это можно сделать с помощью CA.pl. Сначала создадим запрос на подпись сертификата:
$ ./CA.pl -newreq-nodes
Generating a 1024 bit RSA private key ...++++++■
++++++ writing new private key to 'newreq.pem'
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN There are quite a few fields but you can leave some blank For some fields there will be a default value.
If you enter '.’. the field will be left blank.■
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Colorado
Locality Name (eg. city) []:Denver
Organization Name (eg. company) [Internet Widgits Pty Ltd]:NonExistant Enterprises
Organizational Unit Name (eg. section) []:IT Services
Common Name (eg. YOUR name) []:mail.nonexistantdomain.com
Email Address []:postmaster@nonexistantdomain.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:NonExistant Enterprises
Request (and private key) is in newreq.pem
Если вы пожелаете зашифровать частный ключ, то вместо -newreq-nodes можно воспользоваться ключом -newreq. Однако при шифровании первичного ключа каждый раз при запуске службы вам придется вводить пароль. Если вы решите использовать незашифрованный частный ключ, будьте крайне внимательны к сохранению его в секрете, так как любой, кто сможет получить копию ключа, сможет представляться вашим сервером.
А теперь для генерации подписанного сертификата выполните:
$ ./CA.pl -sign
Using configuration from /System/Library/OpenSSL/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
' Serial Number: 1 (0x1).
Validity
Not Before: Dec 3 09:05:08 2003 GMT
Not After : Dec 3 09:05:08 2004 GMT
Теперь таким же образом вы можете устанавливать ключи для каждого сервера, который должен предоставлять SSL-защищенную службу. Это проще сделать, если выделить отдельную рабочую станцию для обслуживания СА и всех файлов, связанных с ним. Не забудьте распространить свой СА-сертификат во все программы, к которым требуется доверие (трюк № 46).Теперь таким же образом вы можете устанавливать ключи для каждого сервера, который должен предоставлять SSL-защищенную службу. Это проще сделать, если выделить отдельную рабочую станцию для обслуживания СА и всех файлов, связанных с ним. Не забудьте распространить свой СА-сертификат во все программы, к которым требуется доверие (трюк № 46).
Теперь таким же образом вы можете устанавливать ключи для каждого сервера, который должен предоставлять SSL-защищенную службу. Это проще сделать, если выделить отдельную рабочую станцию для обслуживания СА и всех файлов, связанных с ним. Не забудьте распространить свой СА-сертификат во все программы, к которым требуется доверие (трюк № 46).
Теперь таким же образом вы можете устанавливать ключи для каждого сервера, который должен предоставлять SSL-защищенную службу. Это проще сделать, если выделить отдельную рабочую станцию для обслуживания СА и всех файлов, связанных с ним. Не забудьте распространить свой СА-сертификат во все программы, к которым требуется доверие (трюк № 46).
ТРЮКNs 4GТРЮКNs 4GРаспространение СА среди клиентов
ТРЮК
Ns 4G
ТРЮК
Ns 4G
Убедитесь, что все ваши клиенты доверяют новому СА.
После создания СА (см. трюк № 45) любой сертификат, подписанный вашим СА, будет вызывать доверие в любой программе, доверяющей вашему СА. Для установления этого доверия необходимо распространить СА-сертификат во все программы, которые должны доверять ему. Это могут быть почтовый клиент, установки IPsec либо web-браузер. Поскольку SSL использует криптографию с открытым ключом, нет необходимости держать публичный ключ в секрете. Его можно просто установить на web-сервере и загрузить всем клиентам по открытому HTTP. Так как инструкции по установке СА-сертификата различаются для
каждой программы, далее мы рассмотрим быстрый и простой способ установки СА на 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 ServerHacks»)
ТРЮК№47ТРЮК№47Шифрование 1МАР и POP с помощью SSL
ТРЮК
№47
ТРЮК
№47
Защитите электронную почту от посторонних глаз с помощью РОРи IMAP-паролей.
Размещение электронной почты на ШАР-сервере — это самый разумный вариант, когда необходимо иметь возможность обращаться к ней из разных мест. В отличие от POP, протокол IMAP хранит всю почту и любые создаваемые папки на
сервере, поэтому вы можете обращаться к любой своей корреспонденции независимо от используемого почтового клиента (программы обмена почтой). Можно даже воспользоваться web-интерфейсом, что делает почту доступной практически с любой машины, имеющей браузер и соединение с Интернетом. Но, скорее всего, при этом вам придется пройти через ненадежные сети. Как защитить пароль электронной почты и саму почту от нежелательных посягательств? Конечно же, с помощью шифрования!
Если у вас уже установлен ШАР- или POP-демон, не имеющий возможности использовать SSL в чистом виде, то можно воспользоваться stunnel (см. трюк № 76), чтобы создать оболочку для службы в виде SSL-канала. Если вы начинаете «с нуля», то можете насладиться выбором демона, имеющего SSL-подержку, скомпилированную непосредственно в двоичный файл.
Одним из демонов, которые изначально поддерживают SSL, является демон University of Washington's I MAP, известный также под именем UW-IMAP (http://www. washington.edu/imap/). IMAP-демон включен в пакет установки программного обеспечения IMAP.
Для компиляции и установки ШАР-демона загрузите из Сети tar-архив и запустите команды:
$ttar 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 fil e 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
почтового агента* (Mail Transfer Agent, МТА) на использование шифрования на транспортном уровне (Transport Layer Security, TLS). Практически все современные почтовые клиенты поддерживают TLS, установка которого осуществляется с помощью флажка в настройках учетной записи клиента.
При использовании Sendmail наличие TLS-поддержки проверяется с помощью команды
$ sendmail -bt -dO.l
Эта команда выведет параметры, с которыми компилировался двоичный файл Sendmail. Если вы найдете строку, в которой имеется значение STARTTLS, то для работы TLS вам необходимо всего лишь представить дополнительную настроечную информацию. Если же такой строки нет, то придется перекомпилировать Sendmail.
Перед перекомпиляцией необходимо зайти в каталог, содержащий исходный код этой программы, и добавить в devtools/Site/site.config.m4 следующие строки:
APPENDDEF('conf_sendmai1_ENVDEF. '-DSTARTTLS') APPENDDEF('conf_sendmail_LIBS’, '-Issl -lerypto')
Если такого файла не существует, его необходимо создать. Процесс компоновки автоматически включит этот файл. Первая строка в этом примере приведет к компиляции TLS-поддержки в двоичный файл Sendmail, а вторая свяжет этот двоичный файл с файлами libssl.so и libcrypto.so.
После добавления этих строк перекомпилировать и переустановить Sendmail можно с помощью команды
./Build -с && ./Build install
Далее необходимо создать пару сертификат/ключ для использования их в Sendmail (см. трюк № 45), после чего перенастроить Sendmail на использование созданной пары. Это можно сделать редактированием файла, на основе которого сгенерирован файл sendmail.cf, который обычно располагается в /etc/mail/ sendmail.тс. После нахождения этого файла добавьте в него строки, подобные представленным далее (они указывают на СА-сертификат, а также на сгенерированную ранее пару сертификат/ключ):
define!'confCACERT_PATH‘. '/etc/mail/certs')
define!'confCACERT'. '/etc/та 11/certs/cacert.pern")
define!'confSERVER_CERT'. '/etc/mail/certs/cert.pem')
define!'confSERVER_KEY', '/etc/mail/certs/key.pem') define!'confCLIENT_CERT'. '/etc/mail/certs/cert.pem') define!'confCL IENTJCEY'. '/etc/mail/certs/key.pem')
Первая строка указывает Sendmail, где находится Certificate Authority, а вторая — где находится сам СА-сертификат. Следующие две строки указывают Sendmail,
какой сертификат и ключ необходимо использовать, когда он действует в качестве сервера (то есть получает почту от 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 IAJ\
220 mail.example.com ESMTP Sendmail 8.12.9/8.12.9; Sun, 11 Jan 2004 12:07:43
-0800 (PST)
ehlo localhost
250-ENHANCEDSTATUS250-ENHANCEDSTATUSCODCOD250-mail.example.com Hello IIDENT:614ZhaGP3Qczqknqm/KdTFGsrBe2SCYC(?localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUS
250-ENHANCEDSTATUS
COD
COD
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- поддержка имеется практически у всех МТА-агентов и почтовых клиентов, нет никаких оснований отправлять почту в «открытом» виде.
Удаленное обнаружение Ethernet-анализатора
Обнаружьте потенциальных «шпионов» в сети и не доверяйте скомпрометированным машинам.
Ethernet-анализаторы (sniffers) — один из самых мощных инструментов в арсенале защиты сети. Однако в «плохих» руках они могут стать весьма серьезной угрозой безопасности сети. Анализаторы могут быть как внутренними, так и злонамеренными внешними нарушителями, но тем не менее после обнаружения системы они, скоре всего, приступают к анализу («вынюхиванию») локальной сети. Такая сетевая разведка помогает этим «шпионам» находить следующую цель или просто собирать лакомые кусочки информации (например, имена и пароли пользователей, адреса электронной почты и другие важные сведения).
Еще не так давно было распространенно мнение, что только Ethernet-сети с совместно используемой средой (shared-medium) уязвимы перед анализаторами. Эти сети использовали центральный концентратор, который осуществлял повторное вещание каждого передаваемого пакета на каждый порт концентратора. При таком типе настройки каждый фрейм, посылаемый любым узлом сети, принимался каждым узлом локального сегмента сети. После этого каждый сетевой адаптер узла (интерфейс) быстро проверял, является ли он пунктом назначения. Если нет, то фрейм отвергался, если да, то фрейм проходил через стек сетевого протокола и обрабатывался приложением. По этой причине анализ трафика другой сети был довольно простым делом. Поскольку весь трафик попадал на каждую систему, надо было лишь отключить проверку, выполняемую сетевым адаптером, и система получала доступ к трафику, предназначенному для других. Обычно это называлось переводом сетевого адаптера в беспорядочный режим и выполнялось привилегированным пользователем.
Со временем широкое распространение получили коммутируемые (switched) Ethernet-сети, и совместно используемая среда больше не применяется. Таким образом, исчез основной источник проблемы. В отличие от концентраторов, Ethernet-коммутаторы отправляют трафик только на то устройство, которому он предназначен. Для этого при прохождении трафика коммутатор изучает, какому выходному порту соответствует МАС-адрес сетевого устройства. Когда коммутатор видит Ethernet-фрейм с определенным МАС-адресом пункта назначения, он просматривает, какой порт коммутатора ему соответствует, и направляет фрейм только на этот порт. При этом коммутатор эффективно создает виртуальное соединение между отправляющей и принимающей станциями каждый раз при передаче фрейма по сети. Таким образом, фрейм увидит только та машина, которой он предназначен.
И все бы хорошо, но некоторые аспекты Ethernet-спецификации и TCP/IP могут вызвать проблемы. Одна из проблем заключается в том, что коммутатор может
запоминать только ограниченное количество МАС-адресов. Максимальное же их число зачастую может быть на несколько порядков больше, чем число портов, имеющихся в коммутаторе, позволяющих подключаться к последующей иерархии. Для эффективной работы каждый коммутатор должен запоминать МАС-адреса, доступные с других коммутаторов. Например, у вас имеется коммутатор на 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
ethlLink 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 ethO1hw ether 00:DE:AD:BE:EF:00
/sbin/ifconfig ethl
ethlLink 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
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 col 11 sions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:11 Base address:0xlc80
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-запросами, находясь в «беспорядочном режиме».
При запуске этого теста 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
Number of valid tests: #1.
Number of tests with positive result: #0
А теперь запустим анализатор на sirius и снова выполним сканирование:
sirius # tcpdump -i leO arp
tcpdump: listening on leO
06:58:00.458836 arp who-has sirius.nnc tell colossus.nnc
06:58:00.458952 arp reply sirius.nnc is-at 8:0:20:81:a4:a3
06:58:00.466601 arp who-has sirius.nnc (ff:0:0:0:0:0) tell colossus.nnc
06:58:00.466928 arp reply sirius.nnc is-at 8:0:20:81:a4:a3
Вот результаты сканирования:
Sniffdet Report
Generated on; Wed Dec 31 06:58:01 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 06:58:00 2003
Finished on: Wed Dec 31 06:58:01 2003
Bytes Sent: 84
Bytes Received: 60
Packets Sent: 2
Packets Received: 1
RESULT: POSITIVE
Number of valid tests: #1
Number of tests with positive result: #1
Number of valid tests: #1
Number of tests with positive result: #1
DNS-тест работает подобным образом, особенно в сетях с совместно используемой средой (на основе концентраторов либо в беспроводных сетях). Однако он основан на разрешении имен, включенном у «вынюхивателя». При выполнении DNS-теста sniffdet посылает лавину пакетов, содержащих IP-адрес, не используемый в данной сети. Если разрешение имен включено, то «шпион» попытается выполнить обратный поиск с целью определения имени узла, соответствующего этому IP-адресу. А поскольку эти адреса не существуют, sniffdet определит, что целевая машина, просматривающая DNS-запросы, находится в «беспорядочном режиме».
Этот тест может выполняться так же, как и ARP-тест, но вместо ключа -t arp используется -t dns.
ТРЮК№50ТРЮК№50Установка Apache с SSL и suEXEC
ТРЮК
№50
ТРЮК
№50
Помогите обеспечить безопасность web-приложений, установив mod_ssl и suEXEC.
Безопасность web-сервера является очень важной проблемой современности, особенно если учесть, что возникает все большее количество вариантов использования Сети. При использовании любого web-приложения, которое должно проверять достоверность информации или ограничивать доступ к ней, требуется внимательно отнестись к установке web-сервера с SSL-функциями. Без SSL любые сведения, подтверждающие полномочия пользователей, посылаемые на web-сервер, отправляются в открытом режиме и могут быть просмотрены «шпионом». Если у вас уже используется Apache, то с помощью mod_ssl (http://www.modssl.org) можно просто добавить возможности SSL.
Кроме того, если web-сервер предоставляет динамическое содержание множеству пользователей, можно обеспечить suEXEC-функциональность. С помощью
suEXEC web-сервер выполняет серверные сценарии как владеющий ими пользователь, а не от имени учетной записи, под которой запущен web-сервер. В противном случае любой пользователь мог бы создавать сценарии и запускать код от имени учетной записи, под которой запущен web-сервер. Это очень плохо, особенно на многопользовательском web-сервере. Если не просматривать созданные сценарии перед их запуском,„пользователи могут написать программный код, позволяющий им обращаться к данным других пользователей или к другой важной информации, такой как учетные записи и пароли баз данных.
Для компиляции Apache с mod_ssl загрузите из Сети исходный дистрибутив mod_ssl для используемой версии Apache. (Если вы не хотите добавлять mod_ssl в существующее дерево Apache, необходимо также загрузить и распаковать дистрибутив Apache.) После этого распакуйте mod_ssl и перейдите в созданный им каталог. Затем запустите подобную команду:
./configure \
-with-apache=../apache_l.3.299\
-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
использует программу-оболочку 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, выполните команду
I/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, аналогичный следующему:
<Directory /home/*/public_html>
AllowOverride Filelnfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch Includes ExecCGI
<Limit GET POST OPTIONS PROPFIND>
Order allow.deny
Allow from all
</Limit>
<LimitExcept GET POST OPTIONS PROPFIND>
Order deny,allow
Deny from all
</LimitExcept>
</Directory>
Помимо этого для разрешения использования CGI-сценариев за пределами каталогов ScriptAlias добавьте следующую строчку:
AddHandler cgi-script .cgi
После этого можно перезапустить Apache:
/usr/local/apache/bin/apachectl restart
Теперь с помощью простого сценария, запускающего команду id, которая выводит сведения о запускающем ее пользователе, проверим suEXEC:
#!/b1n/sh
echo -е "Content-Type: text/plain\r\n\r\n" /usr/sbin/id
Поместите этот сценарий в каталог /usr/local/apache/cgi-bin, назовите его suexec- test.cgi и сделайте его исполняемым. Теперь введите URL сценария (то есть http://webserver/cgi-bin/suexec-test.cgi) в вашем web-браузере. Вы получите что-то подобное:
uid=80(www) gid=80(www) groups=80(ww)
Как видите, он выполнен тем же пользователем, который запустил web-браузер.
А теперь скопируем сценарий в пользовательский каталог public_html:
$ mkdir public_html && chmod 711 -/ ~/publ1c_html $ cp /usr/local/apache/cgi-bin/suexec-test.cgi .
После этого снова введите в браузере URL сценария (то есть http://webserver/ ~user/suexec-test.cgi). Теперь должно получиться что-то подобное:
uid=500(andrew) gid=500(andrew) groups=500(andrew)
Помимо обработки сценариев, располагающихся в личных каталогах пользователей, suEXEC позволяет выполнять на виртуальном узле сценарии от имени другого пользователя. Однако для этого необходимо создать все каталоги виртуального узла внутри корня документов wob-сервера (то есть /usr/local/apache/htdocs). При этом с помощью директив настройки User и Group в выражении VirtualHost можно установить, какие пользователь или группа будут исполнять этот сценарий, например:
<VirtualHost>
User myuser
Group mygroup
DocumentRoot /usr/local/apache/htdocs/mysite
</VirtualHost>
К сожалению, механизм suEXEC несовместим c mod_perl и mod_php, поскольку эти модули запускаются внутри самого процесса Apache, а не в качестве отдельных программ. Поскольку процесс Apache запускается как nonroot-пользователь, он не может изменить UID, под которым выполняется сценарий. SuEXEC работает
за счет того, что Apache вызывает специальную SUID-оболочку (например, /usr/ local/apache/bin/suexec), которая может вызываться только процессом Apache. Если вы стремитесь к обеспечению компромисса безопасность/производи- тельность при использовании suEXEC, а необходимость запуска Perl-сценария по-прежнему сохраняется, то это можно реализовать с помощью стандартного CGI-интерфейса. С помощью этого интерфейса, помимо Perl, можно запускать и PHP-программы, но для этого необходимо создать библиотеку php и указать ее в качестве интерпретатора во всех PHP-сценариях, которые должны выполняться с помощью suEXEC. Сценарии можно запускать и с помощью модуля mod_perl или mod_php, поместив их вне каталогов, в которых будет работать suEXEC.
ТРЮКNs 51ТРЮКNs 51ЗащититеBIND
ТРЮК
Ns 51
ТРЮК
Ns 51
Заблокируйте установку 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
После этого 1необходимо скопировать каталоги 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
Механизм обеспечения безопасности, Предусматривающий изоляцию на время выполнения загружаемого кода в ограниченную среду — «песочницу» (sandbox).
Помимо этого, named должен записывать файл идентификатора процесса (PID) в /named_chroot/var/run, поэтому этот каталог тоже необходимо сделать доступным для записи для пользователя named:
chown named:named /named_chroot/var/run
Теперь необходимо создать несколько файлов-устройств, к которым named сможет обращаться после вызова chroot():
cd /named_chroot/dev
Is -la /dev/null /dev/random
crw-rw-rw-1 rootroot1.3 Jan 302003 /dev/null
crw-r--r--1 rootroot1.8 Jan 302003 /dev/random
mknod null с 1 3
mknod random с 1 8
chmod 666 null random
Кроме того, необходимо скопировать файл временной зоны (time zone file) из /etc/localtime в /named_chroot/etc/localtime. К тому же named обычно использует /dev/log для связи своих протокольных сообщений с syslogd. Поскольку он находится вне «песочницы», то syslogd необходимо попросить создать сокет, чтобы процесс смог записать в него необходимую информацию. Для этого необходимо изменить команду запуска syslogd, добавив в нее -a /named_chroot/dev/log. Обычно существующий файл хранится в /etc.
Например, в ОС Linux версии Red Hat необходимо отредактировать /etc/sysconfig/ syslogd и заменить строку SYSLOGD_OPTIONS следующей:
SYSLOGD_OPTIONS="-m 0 -a /named_chroot/dev/log"
Если используется FreeBSD, то необходимо в файле /etc/rc.conf изменить строку syslogd_flags:
syslogd_flags="-s -a /named_chroot/dev/log"
После перезапуска syslogd в /named_chroot/dev должен появиться сокет протокола. Теперь для запуска named необходимо всего лишь выполнить команду
named -u named -t /named_chroot
Повысить безопасность инсталляции BIND можно ограничением зональных переносов на вспомогательный DNS-сервер и изменением отклика на запросы о версии BIND. Ограничение зональных переносов гарантирует, что случайный взломщик не сможет запросить список всех имен узлов для зон, управляемых серверами имен. Можно глобально ограничить зональные переносы для некоторых узлов, поместив разделы разрешения переноса в раздел параметров named.conf. Например, если необходимо ограничить переносы всех зон, обслуживаемых DNS-сервером, только на 192.168.1.20 и 192.168.1.21, можно использовать подобный раздел разрешения переносов:
allow-transfer {
192.168.1.20:
192.168.1.21:
Если вы не хотите глобально ограничивать зональные переносы и вместо этого хотите указать узлы, на которые разрешен перенос по принципу «зона на зону», поместите раздел разрешения переноса (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).
ТРЮК№52ТРЮК№52БезопасностьMySQL
ТРЮК
№52
ТРЮК
№52
Основные действия по защите 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. Это значительно облегчит настройку структуры каталогов, поскольку в нее не придется
копировать дополнительные библиотеки. По завершении компиляции получите полномочия 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&
Starting mysqld daemon with databases from /mysql/var # ps -aux | grep mysql | grep -v grep
root 10137 0.6 0.5 4156 744 pts/2 S 23 /mysql/bin/mysql d_safe
01 0
00 /bin/sh
mysql 10150 7.0 9.3 46224 11756 pts/2 S 23
01 0
00 [mysqld]
mysql 10151 0.0 9.3 46224 11756 pts/2 S 23
01 0
00 [mysqld]
mysql 10152 0.0 9.3 46224 11756 pts/2 S 23
010
00 [mysqld]
mysql 10153 0.0 9.3 46224 11756 pts/2 S 23
01 0
00 [mysqld]
mysql 10154 0.0 9.3 46224 11756 pts/2 S 23
01 0
00 [mysqld]
mysql 10155 0.3 9.3 46224 11756 pts/2 S 23
01 0
00 [mysqld]
mysql 10156 0.0 9.3 46224 11756 pts/2 S 23
01 0
00 [mysqld]
mysql 10157 0.0 9.3 46224 11756 pts/2 S 23
01 0
00 [mysqld]
mysql 10158 0.0 9.3 46224 11756 pts/2 S 23
01 0
00 [mysqld]
mysql 10159 0.0 9.3 46224 11756 pts/2 S 23 # /mysql/bin/mysqladmin shutdown 040103 23:02:45 mysqld ended
01 0
00 [mysqld]
[1]+ Done/mysql/bin/mysqld_safe
Теперь, когда мы знаем, что MySQL работает за пределами chroot-среды, можно создать дополнительные файлы и каталоги, необходимые для работы в chroot- среде:
mkdiг /mysql_chroot/tmp /mysql_chroot/dev
chmod 1777 /mysql_chroot/tmp
Is -1 /dev/null
erw-rw-rw- 1 root root 1.3 Jan 30 2003 /dev/null
mknod /mysql_chroot/dev/null с 1 3
А сейчас попробуем запустить mysqld в chroot-среде:
/usr/sbin/chroot /mysql_chroot /mysql/libexec/mysqld -u 100
Здесь UID пользователя, от имени которого запускается mysqld, указывается в параметре -и. Он должен соответствовать UID созданного ранее пользователя.
Для упрощения управления можно изменить сценарий mysqld_safe на chroot mysqld. Это выполняется путем поиска строк, в которых вызывается mysqld, и замены их командами с использованием программы chroot. Для этого откройте /mysql/bin/mysqld_safe и найдите подобный блок строк:
if test -z "Sargs"
then.
$NOHUP_NICENESS Sledir/SMYSQLO Sdefaults \
--based!r-$MY BASEDIR VERSION \
--datadir-SDATADIR $USER_OPTION \
--pid-file-$pid_file --skip-locking » $err_log 2>&1 else
eval "$NOHUP_NICENESS $1edir/$MYSQLD Sdefaults \
—based! r=$MY BASEDIR_VERSION \
--datadir-SDATADIR $USER_OPTION \
—pid-file-$pid_file --skip-locking Sargs » $err_log 2>&1" fi
Замените его следующим блоком:
if test -z "Sargs" then
$NOHUP_NICENESS /usr/sbin/chroot /mysql_chroot \ Sledir/SMYSQLO Sdefaults \
.—based!r=$MY_BASEDIR VERSION \
—datadir-SDATADIR $USER_OPTION \
--pid-file=$pid_file --skip-locking » Serrjog 2>&1 else
eval "$NOHUP_NICENESS /usr/^bin/chroot /mysql_chroot \
Sledir/SMYSQLO Sdefaults \
-based!r-$MY_BASEDIR_VERSION \
--datadir-SDATADIR $USER_OPTION \
—p!d-file-$pid_file --skip-locking Sargs » $err_log 2>&1" fi
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 \
л#iсcЗТMВКfhеоаерteffрrytмк/пhрioiоlelвmSаseоеoмe$еsQлenvрнNtyя-$v-реt/aьsO-aтlи-LtаebldнmpqтlHbpd.тa-мaоiilUaыоеzisп/prdНtгd"sP/оbea/хро-a$-Sеe-жNmidа"ffоMгNвdfni$rOiпфiiIонCrгiO=yымi/Yl=lraHlрEsHme$оrаS=eeоrq$UNсаиUMйgQ=$=зlyжPлEмDз$мD$алsL$SYе.аJнMANм"ppsхqDSоедпpoYIBiiTоClрувdCcуJAiddEAтуюd./Ek$DсSANикSDsuNIоffтвSДщdтaEаRsIiiиздfESReеfзDi/лrlSlдиDeSтlfы/eeSаeIяI$ьaмRsоtтUUcвRu-bт/ьS$/эM-JаSl-тVбuкitEumlтn-E-оsRлesоь-syR/гтyrоedюskcгkоSд/.OSr\кiOоеicikIh^е=QчPprIогpnOiObPлrT1и/p-о-LfвчoмTNьiI$0Nllтln-IтoOIOнв:M0oьloв/орсoNctYN\ыccрбарSckkуhйупзы/Qа\iiikчдmrnLо\зniMoфнеnDдggмyнoлеgуаsyоеt$люйq$»Sщd[е»aлl.Qmeп/ьrm$cf[gрmюLcy$eahsиylsrueriysqхeorlв.сrq»lcоntorоdцollstд]зеn$locимoнfge\hфмлgоадrоарroжл2сйж2oи>янlьl>&tлoянoо1M&а-gоgкс\1отаy/бу2ьжmSок>дQлаyз&ызаsо1Lqагчй"-lрткуьутcиржиhsаoалrmзocтиyoьkптsetрq/дtиeиlаd=tнMcз/нs/аmyamыпfSeyуеyQ:.sсcqLкиnlе-fз
необходимо добавить set-variable=l ocal -i nf i 1е=0. Это приведет к отключению команды LOAD DATA LOCAL INFILE. Кроме того, ее можно отключить из командной строки с помощью параметра --local-infile=0.
ТРЮК№53ТРЮК№53SFSвUnix
ТРЮК
№53
ТРЮК
№53
Используйте 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. Если вы хотите изменить это имя, его необходимо указать в качестве параметра настроечного сценария.
После подготовки системы компоновка SFS выполняется командой
$ ./configure && make
По завершении этого процесса получите root-полномочия и введите make install. Для изменения имени пользователя и группы укажите их в параметрах --with-sfsuser и --with-sfsgroup:
$ ./configure --with-sfsuser=nobody --with-sfsgroup=nobody
Построение SFS занимает довольно много времени, поэтому вы можете воспользоваться возможностью выпить чашку кофе, перекусить или даже пообедать, в зависимости от быстродействия вашей машины и объема оперативной памяти.
Созданную и установленную SFS необходимо проверить, подключившись к открытому серверу SFS-проекта. Это можно сделать, запустив демон SFS-клиента (sfscd), а затем изменив каталог, в котором будет смонтирован SFS-сервер:
sfscd
cd /sfs/@sfs.fs.net.uzwadtctbjb3dg596waiyru8cx5kb4an
Is
CONGRATULATIONS cvs piO reddy sfswww
cat CONGRATULATIONS
You have set up a working SFS client.
#
Sfscd автоматически создаст каталог /sfs и каталог для SFS-сервера. Обратите внимание на то, что SFS полагается на демон операционной системы portmap и монтировщик NFS. Они должны быть запущены перед запуском клиента. Для установки SFS-сервера сначала зарегистрируйтесь на вашем сервере и сгенерируйте пару частных ключей:
mkdir /etc/sfs
sfskey gen -P /etc/sfs/sfs_host_key
Sfskey попросит вас немножко постучать по клавишам для сбора случайных да- ных для генератора случайных чисел.
Теперь необходимо создать настроечный файл для sfssd (демон SFS-сервера). Для этого в /etc/sfs создайте файл sfsrwsd_config, где будут находиться настройки пространства имен файловой системы, которые SFS будет экспортировать на другие узлы. Если вы хотите экспортировать файловую систему /home, то файл настройки могли бы создать так:
Export /var/sfs/root /
Export /home /home
Далее необходимо создать каталоги /var/sfs/root и /var/sfs/home. После этого можно произвести NFS-экспорт, для того чтобы файловая система /home могла быть смонтирована в /var/sfs/root/home. После этого она будет повторно экспортирована демоном sfssd. NFS-экспорт нужен только для того, чтобы разрешить
монтирование с локального узла (localhost). Вот как выглядит /etc/exports для экспортирования /home:
/var/sfs/root localhost(rw)
/home localhost(rw)
Это файл экспорта для Linux. При запуске SFS-сервера в другой ОС (Solaris или OpenBSD), чтобы правильно добавить общие ресурсы, изучите справку mountd manpage для этой ОС. Теперь запустите NFS-сервер вашей операционной системы. После запуска NFS необходимо запустить sfssd. После попытки подключения к sfssd-серверу вы увидите в протоколе подобные сообщения:
Dec 12 12:29:14 colossus : sfssd: version 0.7.2. pid 3503
Dec 12 12:29:14 colossus : rexd: version 0.7.2. pid 3505
Dec 12 12:29:14 colossus : sfsauthd: version 0.7.2. pid 3506
Dec 12 12:29:14 colossus : rexd: serving
@colossus.nnc.fd82m36uwxj6m3q8tawp56ztgsvu7g77
Dec 12 12:29:14 colossus : rexd: spawning Zusr/local/1ib/sfs-0.7.2/ptyd
Dec 12 12:29:15 colossus rpc.mountd: authenticated mount request from localhost.localdomain:715 for /var/sfs/root (/var/sfs/root)
Dec 12 12:29:15 colossus rpc.mountd: authenticated mount request from localhost.localdomain:715 for /home (/home)
Dec 12 12:29:15 colossus : sfsauthd: serving
@colossus.nnc.fd82m36uwxj6m3q8tawp56ztgsvu7g77
Dec 12 12:29:16 colossus : sfsrwsd: version 0.7.2. pid 3507
Dec 12 12:29:16 colossus : sfsrwsd: serving
/sfs/@colossus.nnc.fd82m36uwxj6m3q8tawp56ztgsvu7g77
Последняя запись протокола указывает путь, который может использоваться пользователем для монтирования файловой системы. Перед монтированием любой файловой системы на ваш сервер пользователям необходимо создать пару ключей и зарегистрировать их на вашем сервере. Это можно сделать путем регистрации (входа) на сервере и запуском команды
$ sfskey register
sfskey: /home/andrew/.sfs/random_seed: No such file or directory
sfskey: creating directory /home/andrew/.sfs
sfskey: creating directory /home/andrew/.sfs/authkeys
/var/sfs/sockets/agent.sock: No such file or directory sfskey: sfsed not running, limiting sources of entropy Creating new key: andrew@colossus.nnc#l (Rabin)
Key Label: andrew@colossus.nnc#l
Enter passphrase:
Again:
sfskey needs secret bits with which to seed the random number generator.
Please type some random or unguessable text until you hear a beep: DONE
UNIX password:
colossus.nnc: New SRP key: andrew@colossus.nnc/1024
wrote key: /home/andrew/,sfs/authkeys/andrew@colossus.nnc#l
Помимо этого, если уже имеется пара ключей на другом сервере, можно ввести sfskey user@otherserver. Это приведет к извлечению ключа с удаленной машины и регистрации его на сервере, на котором вы только что зарегистрировались. После регистрации ключа на сервере можно зарегистрироваться на SFS-сервере с другой машины. Это делается также с помощью программы sfskey:
$ sfskey 1 login andrew@colossus.nnc
Passphrase for andrew@colossus.nnc/1024:
SFS Login as andrew@colossus.nnc
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-соединению. Применяя эти методы, вы гарантируете, что протоколы безопасно размещены на предназначенном для них сервере, на котором выполняется минимальный набор служб, что, в свою очередь, снижает риск их изменения. Что же делать с протоколами после того, как все они собраны в одном месте? В этой главе рассматриваются способы обобщения протоколов в простые для прочтения и восприятия отчеты, с помощью которых легко опознать самую необходимую информацию. Этот способ вам может показаться недостаточно оперативным. Однако мы также изучим, как настроить генерацию сигналов тревоги в реальном масштабе времени при возникновении критического события. Немедленная реакция на событие (а не на его окончание, зафиксированное в отчете, который вы прочтете на следующее утро) может сэкономить несколько часов работы.
ТРЮК№54ТРЮК№54Запуск централизованного syslog-сервера
ТРЮК
№54
ТРЮК
№54
Обеспечьте защиту протоколов от взломщиков, храня их на удаленной машине.
После того как «незваный гость» вошел в одну из ваших систем, как узнать, когда это произошло и было ли вообще? Конечно же, проверкой протоколов. А что если нарушитель изменил протоколы? В этом случае вам поможет централизованное
протоколирование. Если атакующему удалось проникнуть на машину, но факт проникновения фиксируется не на этой машине, ему будет очень сложно скрыть следы. Помимо обеспечения дополнительного уровня защиты, просто очень удобно просматривать протоколы машин всей сети, когда они находятся в одном месте.
Для быстрой настройки централизованного 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
**
**
Это выражение можно сделать единственной строкой файла настройки, и тогда сообщения будут протоколироваться только на удаленном узле. Если же добавить выражение в существующий файл, то протокол будет храниться как локально, так и удаленно.
Недостатком удаленного протоколирования является отсутствие в большинстве ОС проверки полномочий или управления доступом при обращении к центральному узлу протоколов. Некоторую степень защиты могут обеспечить межсетевые экраны, ограждая от тех, кто способен подорвать инфраструктуру протоколирования, однако тот, кто уже получил доступ к локальной сети, может выдать свое подключение за иное и обойти любые правила межсетевого экрана. Если вы считаете, что это относится к вашей сети, обратитесь к трюку «Обобщение протоколов с удаленных сайтов» (трюк № 59), в котором рассматривается один из методов настройки удаленного протоколирования с использованием идентификации с помощью открытых ключей и соединений с SSL-шифрованием.
ТРЮК№ 55ТРЮК№ 55Управлениеsyslog
ТРЮК
№ 55
ТРЮК
№ 55
Заставьте 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/var/log/auth
mail.err/var/log/maillog
kern,*/var/log/kernel
cron.crit/var/log/cron
*.err;mail.none/var/log/syslog
*.info;auth.none:mail.none •/var/log/messages
#*.=debug/var/log/debug
localO.info/var/log/cluster
local 1.err/var/log/spamerica
Все строки в этом примере будут протоколировать указанный (или выше) приоритет в соответствующий файл. Специальный приоритет попе заставляет syslog вообще не учитывать указанный критерий. Критерии с localO no 1оса17 предназначены
для использования вашими собственными программами, однако они также могут оказаться полезными. Например, файл /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, и любой процесс, просматривающий его, сможет соответствующим образом реагировать, вовсе не занимая дискового пространства.
MARKWHO?
Вы заметили в /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
Если все эти пустяки с критериями и приоритетами добивают вас, вы не одиноки. Эти примеры представлены для систем, по умолчанию включающих демон syslogd. Если имеется возможность установить новый syslogd, то, скорее всего, вы обратитесь к syslog-ng. Эта новая реализация syslogd имеет множество новых функций и позволяет осуществлять фильтрацию более гибко. Некоторые из возможностей syslog-ng мы рассмотрим в трюке «Обобщение протоколов удаленных сайтов» (см. трюк № 59).
Роб Фликингер (Rob Flickenger)
ТРЮК№56ТРЮК№56ИнтеграцияWindows в инфраструктуру syslog
ТРЮК
№56
ТРЮК
№56
Отслеживайте работу 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 -install
Для проверки работы службы откройте элемент Администрирование (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.
Рис. 4.1 . NTsyslog в списке служб
Рис. 4.2. Элемент Computer Management с папкой Users
Щелкните правой кнопкой на папке Users, затем на кнопке Новый пользователь (New). В появившемся диалоговом окне необходимо ввести сведения о новом пользователе (рис. 4.3).
Теперь необходимо предоставить новому пользователю права, необходимые для выполнения задачи. В окне Администрирование (Administrative Tools) найдите
значок Локальная политика безопасности (Local Security Policy) и дважды щелкните на папке Назначение прав пользователя (User Rights Assignment), расположенной в левой части окна (рис. 4.4).
Рис. 4.З. Создание нового пользователя для NTsyslog
Рис. 4.4. Назначение прав пользователя
Необходимое нам право называется Управление аудитом и протоколом безопасности (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.
QT-SSXE
General Log On | Recovery ] Dependencies ]
Log on as:
? k sssti
l~ Aky service to interact with desktop
This account.
You can enable or dusUe tbs service lot the liardwate profiles listed below
Ha-dw»e ProfileService
disabledisableРис. 4.6. Вкладка Регистрация (Log On) окна свойствРис. 4.6. Вкладка Регистрация (Log On) окна свойствРис. 4.7. Программа настройки NTSyslogРис. 4.7. Программа настройки NTSyslog;Enabled
disable
disable
Рис. 4.6. Вкладка Регистрация (Log On) окна свойств
Рис. 4.6. Вкладка Регистрация (Log On) окна свойств
Рис. 4.7. Программа настройки NTSyslog
Рис. 4.7. Программа настройки NTSyslog
Для запуска службы щелкните на кнопке Start Service, для остановки — на кнопке Stop Service. Щелчок на кнопке Syslog Daemons откроет диалоговое окно, представленное на рис. 4.8.
Все совершенно ясно. Просто выберите узел, на который вы хотите войти, и, если имеется вторичный узел syslog, поместите его имя в соответствующее поле.
Рис. 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-события в обычный
отдельный файл. Конечно же, при использовании 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.
ТРЮК№57ТРЮК№57Автоматическое обобщение протоколов
ТРЮК
№57
ТРЮК
№57
Не занимайтесь поиском иголки в стоге сена.
Если протоколируется работа практически всех служб и узлов сети, то вы, без сомнения, потонете в море информации. Один из способов удержаться на плаву — обобщение протоколов (вывод общего результата). Эта задача значительно упрощается при использовании средства 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 1 lib scripts /etc/1og.d
Можно также установить справочную систему и для повышения удобства создать ссылку из сценария I logwatch.pl нау/usr/sbin/logwatch:
cp logwatch.8 /usr/share/man/man8 # (cd /usr/sbin && \
In -s ../../etc/log.d/scripts/logwatch.pi logwatch)
пПппппппиппппТГпТГТГТГпТГппLOgWdLCNtHO иТГппПКУипТГиппипЛппипТГиииТГ
Если имеется каталог /etc/cron.daily, можно создать символическую ссылку из сценария logwatch.pl на /etc/cron.daily/logwatch.pl, и сценарий будет запускаться ежедневно. Альтернативно можно создать элемент в crontab корневого каталога, что позволит модифицировать поведение logwatch, указывая параметры в командной строке. Например, с помощью параметра -mailto можно изменить электронный адрес, на который высылаются отчеты. По умолчанию они отправляются на локальный root.
Logwatch поддерживает большинство стандартных файлов протокола безо всякой дополнительной настройки, но можно добавить поддержку файлов любых типов. Для этого необходимо создать структуру группы протоколов для нового типа файлов в каталоге /etc/log.d/conf/logfiles. Этот файл должен содержать лишь элемент, указывающий файл протокола для этой службы, и элемент, определяющий шаблон универсализации файловых имен любых архивированных файлов протоколов этой службы. Например, если имеется служба 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 при выполнении отбрасывает все временные элементы протоколов
и передает остальные части записей через стандартный ввод в сценарий myservice. Следовательно, сценарий должен выполнять считывание из стандартного ввода, а также разбор соответствующих сведений и записывать результат в стандартный вывод.
Это лишь общий принцип работы программы logwatch в вашей системе. Дополнительную информацию можно найти в HOWTO-Make-Filter, входящем в состав дистрибутива logwatch.
ТРЮК№58ТРЮК№58Автоматическое наблюдение за протоколами
ТРЮК
№58
ТРЮК
№58
Используйте 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. ЕслиJпри запуске команды perl Makefile.PL вы получите сообщение об ошибке, то1необходимо установить следующие модули:
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 "instal l Date::Parse"
perl -MCPAN -e "Time::HiRes"
6 Зак. 1103
По умолчанию swatch ищет свой файл настройки .swatchrc в текущем домашнем каталоге. Этот файл содержит так называемые регулярные выражения (regular expressions), которые ищут в наблюдаемом файле. При желании использовать другой файл настройки сообщите о нем swatch с помощью параметра командной строки -с. Например, для использования /etc/swatch/messages.conf для наблюдения за /var/log/messages программа swatch должна вызываться следующей командой:
# swatch -с //etc/swatch/messages.conf -t /var/log/messages
Общий формат элементов файла настройки:
watchfor/<регулярное_выражение>/
<действие1>
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 особенно полезно в тех случаях, когда имеется сотовый телефон или пейджер, способный принимать почтовые и текстовые сообщения. При
использовании действия 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 является невероятно полезным средством, но для создания файла настройки может потребоваться некоторое время. Самый лучший способ узнать, что необходимо искать, — это просмотреть файлы протокола и выбрать те действия, за которыми вы хотели бы наблюдать более пристально.
ТРЮК№ 59ТРЮК№ 59Обобщение протоколов с удаленных сайтов
ТРЮК
№ 59
ТРЮК
№ 59
Интегрируйте совместно или удаленно расположенные системы или сети в единую инфраструктуру протоколирования.
При выполнении задачи по наблюдению за деятельностью локальной сети зачастую не придается должного значения наблюдению за протоколами удаленного сайта или совместно расположенного сервера. Традиционные возможности syslog
можно было бы использовать /для отправки сведений протоколирования с удаленной сети или систем, но, поскольку 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 и уровни протоколирования.
И наконец, все эти элементы собираются в одном элементе log, что позволяет очень точно определить порядок протоколирования. Таким образом, можно произвольно комбинировать любые источники, выбирать уровни и категории, а затем направлять всю информацию в определенное место. Все это делает syslog-ng исключительно полезным средством протоколирования.
Для установки syslog-ng на удаленной стороне вместо syslog необходимо сначала «перевести» syslog.conf в эквивалентные элементы source, destination и log. Вот syslog.conf для ОС FreeBSD:
*.err:kern.debug:auth.notice:mail.crit/dev/console
*.notice:kern.debug:1pr.info:mai1.crit:news.err /var/1og/messages security.*/var/log/security
auth.info:authpriv.info/var/log/auth.log
mail.info/var/log/maillog
Ipr.info/var/log/lpd-errs
cron.*/var/log/cron
*.emerg*
Сначала надо настроить источник. В ОС FreeBSD /dev/log является ссылкой на /var/run/log. Следующий элемент source указывает syslog-ng, что чтение необходимо осуществлять из этого файла:
source sre { unix-dgram("/var/run/log"): internaK ): }:
В Linux необходимо определить Unix-поток и /dev/log:
source sre { unix-stream("/dev/log"): internaK ) }:
Элемент internaK) предназначен для сообщений, генерируемых самой программой syslog-ng. Обратите внимание на то, что в один элемент можно включать несколько источников. Далее добавьте элементы назначения (destination) для каждого действительного файла протокола:
destination console { fileC/dev/console"): }:
destination messages { file("/var/log/messages"): }:
destination security ( fileC/var/log/security"): }:
destination authlog { file("/var/log/auth.log"): }:
destination maillog { file("/var/log/maillog"); }:
destination Ipd-errs { file("/var/log/lpd-errs"): }:
destination cron { file("/var/log/cron"): }:
destination slip { file("/var/log/slip.log"): }:
destination ppp { file("/var/log/ppp.log"): }:
destination all users { userttyC’*"): }:
Помимо этих назначений можно указать еще один элемент destination для удаленного протоколирования в другой syslog-ng-процесс. Это можно сделать с помощью подобного выражения:
destination loghost { tcp("192.168.0.2" port(5140)): }:
В качестве порта может использоваться любой доступный ТСР-порт.
Определить фильтры очень просто. Можно создать один фильтр для каждой категории (facility) или уровня протоколирования (level) либо создать фильтры в соответствии с их использованием в syslog.conf. В последнем случае необходимо лишь указать один фильтр в каждом выражении log, но тем не менее и на это придется потратить некоторое время. Вот пример фильтра для категорий syslog: filter f_auth { facility(auth): }: filter f_authpriv { facility(authpriv): }:
■filter f_console { facility(console): }:
filter f_cron { facility(cron): }:
filter f_daemon { facility(daemon); }:
filter f_ftp { facility(ftp); }:
filter f_kern { facility(kern): }:
filter f_lpr { facility(lpr): }:
filter f_mail { facility(mail): }:
filter f_news { facility(news): }:
filter f_security { facility(security); }:
filter f_user { facility(user): }: filter f_uucp { facility(uucp): }:
а вот пример для уровней протоколирования:
filter f_emerg { level(emerg): }:
filter f_alert { level(alert..emerg): }:
filter f_crit { level(crit..emerg): ):
filter f_err { level(err..emerg): }:
filter f_warning { level(warning..emerg); ):
filter f_notice { level(notice..emerg): };
filter f_info { level(info..emerg): }: filter f_debug { level(debug..emerg): }:
Теперь можно комбинировать source с соответствующими элементами filter и destination в элементах log:
*.err;kern.debug:auth.notice:mail.crit/dev/console
log { source(src): filter(f_err); destination(console): }:
log { source(src); filter(f_kern); filter(f_debug): destination(console): }: log { source(src): filter(f_auth); filter(f_notice): destination(console): }: log { source(src); filter(f_mail); filter(f_crit); destination(console); };
*.notice:kern.debug:lpr.1nfo:mail.crit:news.err /var/log/messages log { source(src): filter(f_notice): destination(messages): }:
log { source(src): filter(f_kern): filter(f_debug): destination(messages): }: log { source(src): filter(f_lpr): filter(f_info): destination(messages): }: log { source(src): filter(f_mail): filter(f_crit): destination(messages); }: log { source(src); filter(f_news): filter(f_err): destination(messages): }:
/var/log/security/var/log/security# security.*
/var/log/security
/var/log/security
log { source(src): filter(f_security): destination(security): }:
auth.info:authpriv.info/var/log/auth.log
log { source(src): filter(f_auth): filter(fjnfo); destination(authlog): }:
log { source(src): f11ter(f_authpriv): filter(f_info): destination(authlog): }:
mail.info/var/log/maillog
log { source(src): filter(f_mail): filter(fjnfo): destination(maillog): }:
Ipr.info/var/log/lpd-errs
log { source(src): filter(f_lpr): filter(f_info): destination(lpd-errs): }:
cron.*/var/log/cron
log { source(src): filter(f_cron): destination(cron): };
*.emerg*
log { source(src): filter(f_emerg): destination(allosers): }:
Машина, которая будет получать протоколы, настраивается практически так же, как машина, которая использует syslogd. Для настройки syslog-ng на получение сообщений с удаленного узла необходимо указать элемент source:
source rsrc { tcp(ip("192.168.0.2") port(5140)); }:
В качестве альтернативного варианта можно помещать все протоколы с удаленных машин в то же место, которое используется для хранения локальных протоколов. Это не очень желательно, поскольку в этом случае управление системой может стать кошмаром, но может быть сделано за счет включения множества устройств-источников в элемент source, используемый для локальных протоколов: source src {
unix-dgram("/var/run/log"):
tcp(1p("192.168.0.2") port(5140)): internal( ):
}:
Теперь протоколы, собираемые с удаленных узлов, будут размещаться в произвольном месте, связанном с этим источником. Для того чтобы все протоколы с удаленных узлов помещались в отдельный файл с именем каждого узла в каталоге /var/log, необходимо указать следующее назначение:
destination r_all { file("/var/log/$HOST"): };
Syslog-ng «заменит» макрос SHOST именем узла посылающей протокол системы и создаст файл с таким же именем в /var/log. Соответствующий элемент log будет выглядеть так:
log { source(r_src); destination(r_all): }:
Но более удачным вариантом будет воссоздание всех файлов протоколов syslog-ng на одном центральном сервере. Например, destination для файла сообщений удаленной машины мог бы выглядеть так:
destination fbsd_messages { file("/var/log/$HOST/messages"); }:
Обратите внимание на то, что макрос $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) можно исключить возможность подделки элементов журнала и предотвратить атаки типа «отказ в обслуживании».
Протоколы серверов содержат серьезную информацию, необходимую для работы администратора. Использование новых средств и сильного шифрования позволит сберечь важные данные из журналов от посторонних глаз.
Протоколирование деятельности пользователя за счет учета процессов Выполняйте подробное контрольное отслеживание того, что делается на ваших системах.
Учет выполняемых процессов позволяет подробно отслеживать каждую программу и команду, запускаемую пользователем, а также длительность применения процессора и использование памяти. С точки зрения безопасности это означает, что системный администратор может собирать сведения о том, какую команду
и в какое время запустил пользователь. Это не только очень полезно для определения факта вторжения или компрометации локального root, но и может использоваться для выявления злого умысла в поведении обычных пользователей системы (вторжение не всегда происходит извне). Для включения учета процессов выполните такие команды:
mkdir 7var/account
touch /var/account/pacct && chmod 660 /var/account/pacct
/sbin/accton /var/account/pacct.
Кроме того, при использовании версий Red Hat и SuSE ОС Linux и при установленном пакете учета процессов (process accounting package) для включения учета процессов можно выполнить запускающий сценарий. В Red Hat попробуйте сделать так:
chkconfig psacct on
/sbin/service psacct start
В SuSE используйте следующие команды:
chkconfig acct on
/sbin/service acct start
Пакет учета процессов предоставляет несколько программ для обработки протоколируемых данных. Программа ас анализирует общее время соединения пользователей системы.
Запуск ее без параметров выводит количество часов, проведенных в системе текущим пользователем:
[andrew@colossus andrew]$ ас total 106.23
Если необходимо просмотреть время подключения всех пользователей, входивших в систему, воспользуйтесь ключом -р:
ас -р
root0.07
andrew106.05
total 106.12
Команда lastcomm позволяет найти вхождения в систему (регистрации) по имени пользователя, имени команды или терминалу:
# lastcomm andrew
Is
andrew
??
0.01
secs
Mon
Dec
15
05:58
rpmq
andrew
??
0.08
secs
Mon
Dec
15
05:58
sh
andrew
??
0.03
secs
Mon
Dec
15
05:44
gunzip
andrew
??
0.00
secs
Mon
Dec
15
05:44
# lastcomm bash
bash
F
andrew
??
0.00
secs
Mon
Dec
15
06:44
bash
F
root
stdout
0.01
secs
Mon
Dec
15
05:20
bash
F
root
stdout
0.00
secs
Mon
Dec
15
05:20
bash
F
andrew
??
0.00
secs
Mon
Dec
15
05:19
Для обобщения учетных сведений можно использовать команду sa. По умолчанию она выводит все команды, найденные в протоколах учета, а также то, сколько раз они выполнялись:
# sa
14
0.04ге
О.ОЗср
Oavio
1297k
troff
7
О.ОЗге'
О.ОЗср
Oavio
422k
lastcomm
2
63.90re
O.Olcp
Oavio
983k
info
14
34.02re
O.Olcp
Oavio
959k
less
14
О.ОЗге
O.Olcp
Oavio
1132k
grotty
44
0.02re
O.Olcp
Oavio
432k
gunzip
Для вывода статистики с фильтрацией по имени 1пользователя используется
ключ -и:
# sa -u
root
0.01 cpu
344k mem
0
io which
root
0.00 cpu
1094k mem
0
io bash
root
0.07 cpu
1434k mem
0
io rpmq
andrew
0.02 cpu
342k mem
0
io id
andrew
0.00 cpu
526k mem
0
io bash
andrew
0.01 cpu
526k mem
0
io bash
andrew.
0.03 cpu
378k mem
0
io grep
andrew
0.01 cpu
354k mem
0
io id
andrew
0.01 cpu
526k mem
0
io bash
andrew
0.00 cpu
340k mem
0
io hostname
Время от времени можно внимательно изучать результат выполнения этих команд для поиска подозрительной деятельности, например выполнения вредоносных команд или увеличения времени использования процессора.
ГЛАВА
Наблюдение и выявление тенденций
Трюки№61-66
Значимость надежных системных протоколов переоценить невозможно, но все же их можно рассматривать лишь как вступление к книге о том, что произошло в сети. Когда случается что-то неординарное, событие просто заносится в соответствующий файл, где и ожидает, когда человек заметит его и предпримет ответные действия. Журналы имеют ценность лишь в том случае, если их кто-то действительно читает. Файлы протоколов постоянно пополняют объем информации, которую большинство администраторов «перемалывают» каждый день, в то же время некоторые из них могут оставаться непрочитанными дни и недели. И ситуация лишь ухудшается, если файлы протоколов «завалены» незначащей информацией. Например, крик о помощи от перегруженного почтового сервера запросто может быть потерян, если он находится среди неопасных записей о неудачных попытках рассылки спама. Зачастую протоколы используются как ресурс, помогающий разобраться в том, «что произошло» при крахе системы, а не для отслеживания того, «что же происходит сейчас».
Еще одна важная характеристика записей журнала заключается в том, что они показывают лишь «точечный снимок» системы в определенный момент времени. Не имея хронологии производительности, довольно сложно уловить разницу между обычным сетевым трафиком, DoS-атакой и посещением группой читателей какого-либо популярного блога, на котором был указан адрес искомого ресурса. Из отчета можно узнать, сколько раз переполнялся раздел /var. А как просмотреть использование этого раздела во времени? Буфер почты работает медленно из-за одного невнимательного к другим пользователя, или это часть атаки, проводимой злоумышленником? А может, это просто общая тенденция, вызванная попыткой обслуживать слишком много пользователей при наличии очень маленького диска?
В этой главе описывается несколько методов отслеживания во времени работоспособности служб и ресурсов. Вместо просмотра журналов лучше, чтобы система сама предупреждала о проблеме, и только в том случае, если проблема действительно существует. Здесь также предлагается несколько способов распознавания тенденций изменения сетевого трафика, основанных на наблюдении за общим потоком и представлении его в виде графика. Вы, наверное, представляете, как выглядит усредненный исходящий Интернет-трафик, но какую часть из этого
трафика составляет HTTP, а какую — SMTP? Вы можете приблизительно представить интенсивность использования каждого сервера сети, но что если вы хотите разделить трафик по протоколу? Из этой главы вы узнаете, как это сделать.
ТРЮК№ 61ТРЮК№ 61Наблюдение за работоспособностью
ТРЮК№ 61
ТРЮК№ 61
Для учета работы сети используйте 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, который создается при выполнении команды
install-config. Эта команда также создает пример каждого файла настройки и помещает их в каталог etc.
На этом установка Nagios завершена. Однако в таком состоянии это приложение не очень полезно по причине отсутствия действительных приложений наблюдения. Эти приложения, проверяющие правильность функционирования конкретной наблюдаемой службы, называются надстройками (plug-ins). Nagios имеет стандартный набор надстроек, но их необходимо отдельно загружать из Сети и устанавливать.
Загрузите свежий набор надстроек и разархивируйте его. После этого необходимо запустить имеющийся сценарий настройки, выполняющий подготовку пакета и компиляцию в вашей системе. Можно отметить, что установка надстроек производится так же, как и установка самой программы Nagios. Для компиляции надстроек выполните подобные команды:
$ ./configure --prefix=/usr/local/nagios \
--with-nagios-user=nagios --with-nagis-grp=nagios
$ make al l
В ходе выполнения сценария возможно появление предупреждений об отсутствии программ или модулей языка 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 <remi@sinfomic.fr>
Copyright (c) 2000-2003 Nagios Plugin Development Team
<nagiosplug-devel(PIists.sourceforge.net>
•Try to connect to SSH server at specified server and port
Usage: check_ssh [[-46] [-t <timeout>] [-p <port>] <host> check_ssh (-h | --help) for detailed help check_ssh (-V | --version) for version information
Options:
h. --help
Print detailed help screen
V. --version
Print version information
H. --hostname=ADDRESS
Host name or IP Address
p. --port=INTEGER
Port number (default: 22)
4. --use-ipv4
Use IPv4 connection
6. --use-ipv6
Use IPv6 connection
t. --t1meout=INTEGER
Seconds before connection times out (default: 10)
v. --verbose
Show details for command-line debugging (Nagios may truncate output)
Send email to nagios-users@lists.sourceforge.net if you have questions regarding use of this software. To submit patches or suggest improvements, send email to nagiosplug-devel@lists.sourceforge.net
После того как установлены Nagios и надстройки, можно приступать к наблюдению за службами. Однако без правильной настройки Nagios даже не запустится. Для начала можно воспользоваться учетными файлами настройки:
$ cd /usr/local/nagios/etc
$ Is -1
cgi.cfg-sample
checkcommands.cfg-sampl e
contactgroups.cfg-sampl e
contacts.cfg-sample
dependencies.cfg-sample
escalations.cfg-sample
hostgroups.cfg- sample hosts.cfg-sample mi sccommands.cfg-sample nagios.cfg-sample resource.cfg-sample services.cfg-sample timeperiods.cfg-sample
Поскольку это лишь примеры, авторы Nagios добавили в конце имени каждого файла .cfg-sample. Сначала необходимо скопировать или переименовать каждый файл, оставив только .cfg. (Если не изменить имена файлов настройки, Nagios не сможет их найти.)
Можно либо переименовать каждый файл вручную, либо воспользоваться одной командой для всех файлов (вводиться она должна в одну строку):
for 1 in *cfg-sample: do mv $1 "echo $1 | \ sed -e s/cfg-sample/cfg/': done:
Главным файлом настройки является nagios.cfg. Практически все в нем необходимо оставить как есть: в процессе установки программы Nagios проверяется
правильность путей, указанных в этом файле. Имеется один параметр, который стоит изменить: 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
namegeneric-host
n other host definitions, used for template recursion/resolution
Host notifications are enabled
noti fi cati ons_enabled1
I Host event handler is enabled
event_handler_enabled1
Flap detection is enabled
f1ap_detecti on_enabled1
Process performance data
prpcess_perf_data1
Retain status information across program restarts
retai n_status_i nformation1
Retain non-status information across program restarts
retai n_nonstatus_informati on1
DONT'REGISTER THIS DEFINITION - ITS NOT A REAL HOST,
JUST A TEMPLATE!
register0
Host Definition define host{
Name of host template use
host_name alias
address
check_command max_check_attempts notificati on_i nterval notification_period notification_options
to use generic-host freelinuxcd.org
Free Linux CD Project Server www.freelinuxcd.org check-host-alive 10 120 24x7 d.u.r
Первый определенный узел является не реальным узлом, а лишь шаблоном (заготовкой), на основе которого выполняется определение настоящих узлов. Этот же механизм можно увидеть и в других файлах настройки. Он позволяет выполнять настройку на основе предопределенных наборов значений по умолчанию. При имеющихся настройках мы будет проверять работу только одного узла, www.freelinuxcd.org. Параметр host_name важен из-за того, что остальные файлы настройки будут обращаться к этому серверу по этому имени. Теперь узел необходимо добавить в hostgroup для того, чтобы приложение «знало», в какую контактную группу направлять извещения. Вот как должен выглядеть файл hostgroups.cfg:
define hostgroup{
hostgroup_name flcd-servers
aliasThe Free Linux CD Project Servers
contact_groups flcd-admins
membersfreelinuxcd.org
}
Здесь определена новая группа узлов (hostgroup) и определена ее связь с flcd- admins contact_group. Сейчас мы должны определить данную контактную группу в contactgroups.cfg:
define contactgroup{ contactgroup_name aliasmembersdefine contactgroup{ contactgroup_name aliasmembersflcd-adminsFreeLinuxCD.org Admins oktay. vertyflcd-adminsFreeLinuxCD.org Admins oktay. verty
define contactgroup{ contactgroup_name alias
members
define contactgroup{ contactgroup_name alias
members
flcd-admins
FreeLinuxCD.org Admins oktay. verty
flcd-admins
FreeLinuxCD.org Admins oktay. verty
В контактную группу flcd-admins contact_group входят два члена: oktay и verty. Такая настройка гарантирует, что в случае каких-либо происшествий на сервере, за который отвечает группа flcd-admins, будут извещены оба пользователя. Следующий шаг — настройка контактных сведений и предпочтений извещения для этих пользователей. Вот определение этих двух членов в contacts.cfg:
oktayOktay Altunergil 24x7oktayOktay Altunergil 24x7define contact{
oktay
Oktay Altunergil 24x7
oktay
Oktay Altunergil 24x7
contact_name
alias
service notification period
host_not1fIcati on_period servi cejiotifi cati on_options host_notification_options servi cejiotif 1cation_commands host_notification_commands emailpager }host_not1fIcati on_period servi cejiotifi cati on_options host_notification_options servi cejiotif 1cation_commands host_notification_commands emailpager }24x7
host_not1fIcati on_period servi cejiotifi cati on_options host_notification_options servi cejiotif 1cation_commands host_notification_commands email
pager }
host_not1fIcati on_period servi cejiotifi cati on_options host_notification_options servi cejiotif 1cation_commands host_notification_commands email
pager }
w.u.c.r
d.u.r
noti fy-by-emai1.notify-by-epager
host - not i fy - by - ema i 1.host -notify- by-epager oktay@freelinuxcd.org
lefine contact{ contact_name aliasservice_notification_period host_notifi cation_period service_notification_options host_notification_options service_notification_commands host_notification_commands email}lefine contact{ contact_name aliasservice_notification_period host_notifi cation_period service_notification_options host_notification_options service_notification_commands host_notification_commands email}VertyDavid 'Verty' Ky24x724x7w.u.c.rd.u.rnotify-by-emai1.notify-by-epagerhost-not1fy- by-ema i1 verty@flcd.orgVertyDavid 'Verty' Ky24x724x7w.u.c.rd.u.rnotify-by-emai1.notify-by-epagerhost-not1fy- by-ema i1 verty@flcd.orgdummypagenagios -admin@loca 1 host.localdoma i n
lefine contact{ contact_name alias
service_notification_period host_notifi cation_period service_notification_options host_notification_options service_notification_commands host_notification_commands email
}
lefine contact{ contact_name alias
service_notification_period host_notifi cation_period service_notification_options host_notification_options service_notification_commands host_notification_commands email
}
Verty
David 'Verty' Ky
24x7
24x7
w.u.c.r
d.u.r
notify-by-emai1.notify-by-epager
host-not1fy- by-ema i1 verty@flcd.org
Verty
David 'Verty' Ky
24x7
24x7
w.u.c.r
d.u.r
notify-by-emai1.notify-by-epager
host-not1fy- by-ema i1 verty@flcd.org
[омимо предоставления подробных контактных сведений о конкретном поль- эвателе, параметр contact_name в файле contacts.cfg также используется CGI-сце- ариями (при работе через web-интерфейс) для определения того, разрешен ли тому пользователю доступ к определенному ресурсу.
[осле того как узлы и контакты будут настроены, можно приступать к на- гройке наблюдения за отдельными службами сервера. Это делается с помощью 1айла services.cfg:
6 Generic service definition template
lefine service{
t The 'name' of this service template, referenced in other service definitions name generic-service
Active service checks are enabled
active_checks_enabled 1
Passive service checks are enabled/accepted
passive_checks_enabled 1
Active service checks should be parallelized
(disabling this can lead to major performance problems)
parallelize_check 1
We should obsess over this service (if necessary)
obsess_over_service 1
Default is to NOT check service 'freshness'
check_freshness 0
Service notifications are enabled
notiflcations_enabled 1
Service event handler is enabled
event_handler_enabled 1
Flap detection is enabled
flap_detection_enabled 1
Service definition define service!
Name of service template to use usegeneric-service
hostjiamefreeli nuxcd.org
service_descriptionPING
is_volatile0
check_period24x7
max_check_attempts 3
отклика или увеличении потерь пакетов. Здесь используются команды check_ http и checkjDing,-которые были помещены в каталог libexec в ходе установки. Познакомьтесь, пожалуйста, и с другими надстройками. Они настраиваются аналогичным образом.
По завершении настройки последний раз запустите Nagios с ключом -v для того, чтобы убедиться в отсутствии ошибок. После этого с помощью ключа -d запустите ее как демон:
/usr/local/nagios/bin/nagios -d /usr/local/nagios/etc/nagios.cfg
Вот и все. Дайте Nagios пару минут для того, чтобы сгенерировать данные, после этого укажите в web-браузере адрес машины и просмотрите работу программы.
ТРЮК№62ТРЮК№62Графическое изображение тенденций
ТРЮК
№62
ТРЮК
№62
С помощью 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 опрашивает устройства. Сначала необходимо создать циклическую БД подобной командой:
:CO:CO$ rrdtool create zul.rrd --start N \
:CO
:CO
DS:deOin: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 \
RRA:MAX:0.5:1:600 \
RRA:MAX:0.5:6:700 \
RRA:MAX:0.5:24:775 \
RRA:MAX:0.5:288:797
Эта команда создает БД, содержащую записи в двух отдельных счетчиках: deO in и deO out. Они будут хранить отчеты статистики сетевого интерфейса, собираемые каждые 5 минут с маршрутизатора SNMP-демоном. Кроме того, здесь имеется несколько нолей для автоматического усреднения.
Заполнить БД можно с помощью подобной команды:
$ rrdtool update zul.rrd NA
'snmpget -Oqv zul public interfaces.ifTable. if Entry,ifInOctets.4'A
‘snmpget -Oqv zul public interfaces.ifTable.ifEntry.ifOutOctets.4"
Эта команда запрашивает статистику ввода и вывода для интерфейса deO компьютера zul. Для того чтобы эта команда запускалась через каждые 5 минут, необходимо в crontab создать новый элемент, подобный следующему:
0-55/5 * * * * rrdtool update /home/andrew/rrdbs/zul .rrd N:‘snmpget -Oqv zul public interfaces.ifTable.ifEntry.ifInOctets.4':‘snmpget -Oqv zul public
i nterfaces.1fTable.1fEntry.1fOutOctets.4'
Однако можно использовать любые методы сбора данных. Для генерации диаграммы, основанной на данных за 1 час, необходимо выполнить подобную команду:
rrdtool graph zul_de0-hourly.png -t "Hourly Bandwidth" --start -3600 \
DEF:moctets-zul.rrd:de0_in:AVERAGE \
DEF:outoctets-zul.rrd:de0 out:AVERAGE \
AREA:inoctetS#00FF00:"de0~In" \
LINE1:outoctets#0000FF:"deO Out"
При этом вы получите изображение, подобное представленному на рис. 5.1.
17:0017:1017:201 7:301 7:401 7:50
□ deo in ■ deo Out
17*00 " * 17:1017:2017?30 * 17*40 * 17:*50
| Щ deo In H deO out
Рис. 5.1 . Диаграмма, сгенерированная RRDtool
Значение -3600 в команде указывает RRDtool, что вы хотите получить диаграмму на основе данных, собранных за последний час (1 ч = 3600 с). Аналогично, если необходим график за целый день, можно указать значение -86 400. Но это только начало. После сбора данных из различных источников можно объединить их в одном графике, который визуально даст больше информации. На рис. 5.2 одновременно представлены графики относительного исходящего использования
нескольких серверов и итогового среднего значения для всех серверов. Хотя изображение на рисунке черно-белое, на самом деле программой используются различные цвета для каждого сервера, что упрощает визуальное восприятие того, график пропускной способности какого сервера искривлен больше.
Рис. 5.2. Графики для нескольких серверов на одной диаграмме
Можно отметить, что RRDtool — очень удобное средство. Все, что надо для него сделать, — это сказать, сколько данных необходимо хранить, а затем настроить несколько методов сбора данных через определенное время. После этого в любой удобный момент можно построить диаграмму.
Ш
Использование ntop для получения статистики работы сети в реальном масштабе времени
Смотрите, кто и чем занимается в вашей сети с помощью ntop.
Если вам нужна сетевая статистика в реальном масштабе времени, обратитесь к прекрасному средству ntop (http://www.ntop.org). Это полномасштабный анализатор протокола, имеющий web-интерфейс клиентской части, поддерживающий SSL и возможность составления диаграмм. К сожалению, ntop совсем не маленький (точный размер требуемых ресурсов определяется в зависимости от размера сети и объема сетевого трафика), но он дает полную картину того, кто с кем общается в сети.
Ntop должен изначально запускаться от имени root (для переброски сетевых интерфейсов в «беспорядочный режим», чтобы иметь возможность перехватывать пакеты), но впоследствии понижает свои привилегии до привилегий указанного вами пользователя. Если вы решили запускать ntop на длительный период времени, было бы разумно запускать его на специально выделенном для наблюдения
блоке (совместно с другими службами — из соображений безопасности и обеспечения максимальной производительности).
Сейчас мы кратко познакомимся с установкой и запуском ntop. Сначала создайте пользователя и группу ntop:
groupadd ntop
useradd -c "ntop user" -d /usr/local/etc/ntop \
s /bi.n/true -g ntop ntop
После этого распакуйте и скомпонуйте ntop в соответствии с инструкциями, находящимися в файле docs/BUILD-NTOP.txt . Предполагается, что исходный код распакован в /usr/local/src/ntop-2.1.3/.
Создайте каталог для хранения базы данных отчетов:
mkdir /usr/local/etc/ntop
Обратите внимание на то, что владельцем его должен выступать root-, а не ntop-пользователь. Если хотите использовать SSL для HTTPS (вместо стандартного HTTP), то скопируйте стандартный SSL-ключ в /usr/local/etc/ntop. Исходя из того, что ntop распакован в /usr/local/src/ntop-2.1.3/, это можно сделать с помощью такой команды:
ср /usr/local/src/ntop-2.1.3/ntop/*pem /usr/local/etc/ntop
Обратите внимание на то, что стандартный SSL-ключ не будет построен с верным именем узла вашего сервера. Поэтому вы, вероятно, захотите сгенерировать собственный SSL-сертификат и пару ключей (см. трюк № 45). Теперь необходимо инициализировать базы данных ntop и установить пароль администратора:
# ntop -A -u ntop -Р
/usr/local/etc/ntop
21/Sep/2002 20:30:23
Initializing GDBM...
21/Sep/2002 20:30:23
Started thread (1026) for network packet analyser
21/Sep/2002 20:30:23
Started thread (2051) for idle hosts detection.
21/Sep/2002 20:30:23
Started thread (3076) for DNS address resolution.
21/Sep/2002 20:30:23
Started thread (4101) for address purge.
Please enter the password for the admin user:
Please enter the password again:
21/Sep/2002 20:30:29 Admin user password has been set.
А теперь запустите ntop как демон и SSL-сервер на любимом порте (на 4242, например):
ntop -u ntop -Р /usr/local/etc/ntop -W4242 -d
По умолчанию ntop также запускает стандартный HTTP-сервер на 3000-м порте. Надо очень внимательно отнестись к блокировке доступа к этим портам либо с помощью межсетевого экрана, либо с использованием правил iptables (см. трюк № 33).
Давайте запустим ntop, а затем подключимся к https://your.server.here:4242/. Вы получите всевозможные подробности о трафике в вашей сети (рис. 5.3).
Рис. 5.3. Вывод статистики узла с помощью web-интерфейса ntop I
В то время как tcpdump и Ethereal делают подробный интерактивный анализ сетевого трафика, ntop предоставляет ценную статистическую информацию с помощью простого в использовании web-интерфейса. При правильной установке и разумной блокировке ntop вполне может стать любимым средством анализа сети.
Роб Фликингер (Rob Flickenger) «Трюки Linux-сервера» («Linux Server Hacks»)
Аудит сетевого трафика
Воспользуйтесь программой Argus для наблюдения за сетью.
Было бы неплохо полностью фиксировать все, что происходит в сети. Полное протоколирование помогает отслеживать проблемы и просто бесценно при инциденте в системе безопасности, но оно будет занимать очень много места. Решением этой проблемы является не хранение самих данных, а протоколирование целых пакетов. Это можно сделать с помощью программы Argus (http://www.qosient.com/argus/).
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
12Jan0405:42:48udpplunder.nnc.netbios-ns -> 192.168.0.255.netbios-nsINT
12Jan0405:43:09udp192.168.0.250.snmptrap -> 255.255.255.255.snmptrapINT
12Jan0405:43:15udpprint.nnc.netbios-dgm -> 192.168.0.255.netbios-dgmINT
12.Jan0405:43:28lie0:cO:2:57:98:79.nul1 -> Broadcast.null INT
12Jan0405:43:28nvl0:c0:2:57:98:79 -> Broadcast INT
12Jan0405:43:28lie0:c0:2:57:98:79.nul1 -> Broadcast.null INT
12Jan0405:43:28lie0:c0:2:57:98:79.nul1 -> Broadcast.null INT
12Jan0405:44:19udpkryten.nnc.56581 -> 255.255.255.255.2222 TIM
12 Jan 04 05:43:34 udp sunder.nnc.netbios-ns -> 192.168.0.255.netbios-ns INT
12 Jan0405:44:08arpplunder.nnc who-has sirius.nnc INT
12 Jan0405:44:08udpplunder.nnc.netbios-ns -> 192.168.0.255.netbios-nsINT
12 Jan0405:44:15udpprint.nnc.netbios-dgm -> 192.168.0.255.netbios-dgmINT
12 Jan 04 05:45:06 udp sunder.nnc.netbios-dgm -> 192.168.0.255.netbios-dgm TIM
12 Jan0405:40:26manpkts 734 bytes 75574 drops 0 CON
12 Jan0405:44:28nvl0:c0:2:57:98:79 -> Broadcast INT
12 Jan 04 05:44:28 lie 0:c0:2:57:98:79.nul1 -> Broadcast.null INT
12 Jan 04 05:44:28 11с 0:СО:2:57:98:79.nu11 -> Broadcast.null INT
12 Jan 04 05:44:28 Ис O:CO:2:57-.98:79.null -> Broadcast.null INT
12 Jan 04 05:45:08 udp plunder.nnc.netbios-ns -> 192.168.0.255.netbios-ns INT
12 Jan 04 05:45:09 tcp kryten.nnc.54176 ?> colossus.nnc.ssh EST
12 Jan 04 05:45:15 udp print.nnc.netbios-dgm .-> 192.168.0.255.netbios-dgm INT
Это лишь несколько минут протоколирования одного узла, но информация хранится очень компактно. На самом деле в ходе тестирования установлено, что протоколы целого дня работы занимают 1,4 Мбайт!
Команда га также может использовать фильтры, подобные tcpdump, что позволяет запрашивать в протоколе пакеты, относящиеся к определенному узлу, протоколу, порту и другим характеристикам.
Например, если необходимо в протоколе запросить все пакеты, поступившие на узел с именем kryten или отправленные с него, то можно использовать такую команду:
$ га -г /tmp/argus - "host kryten"
12 Jan0409:26:34udpkryten.nnc.55689->255.255.255.255.2222 TIM
12 Jan0409:26:36tcpkryten.nnc.54176?>linux-vmm.nnc.sshEST
12 Jan0409:27:37tcpkryten.nnc.54176?>linux-vmm.nnc.sshEST
12 Jan0409:28:34udpkryten.nnc.55691-> 255.255.255.255.2222TIM
12 Jan0409:28:05icmpkryten.nnc <->linux-vmm.nnc ECO
12 Jan0409:28:06icmpkryten.nnc <->linux-vmm.nnc ECO
12 Jan0409:29:06tcpkryten.nnc.54176?>linux-vmm.nnc.sshEST
12 Jan0409:30:34udpkryten.nnc.55692-> 255.255.255.255.2222TIM
12 Jan0409:32:34udpkryten.nnc.55693-> 255.255.255.255.2222TIM
12 Jan0409:33:06tcpkryten.nnc.54176?>linux-vmm.nnc.sshEST
12 Jan0409:34:34udpkryten.nnc.55694-> 255.255.255.255.2222
12 Jan0409:53:44tcpkryten.nnc.54176?>linux-vmm.nnc.sshEST
С помощью параметра -w команды га с указанием файла, в который будут записываться результаты, можно сгенерировать новый файл протокола Argus, содержащий только результаты запроса.
Для представления результатов в формате XML используется утилита raxml. Ее использование аналогично использованию команды га. Например, вот первая запись, возвращаемая предыдущим запросом, для всех пакетов, соответствующих узлу с именем kryten:
$ raxml -г /tmp/arguslog - "host kryten"
<ArgusFlowRecord ArgusSourceld = "192.168.0.41" SequenceNumber = "3"
Cause = "Status" StartDate = "2004-01-12" StartTime = "09:25:26"
StartTimeusecs = "319091" LastDate = "2004-01-12"
LastTime = "09:25:32" LastTimeusecs * "521982"
Duration = "6.202891" TransRefNum = "0">
<MACAddrs SrcAddr = "0:a:95:c7:2b:10" DstAddr = "0:C:29:e2:2b:Cl" />
<Flow> <IP SrcIPAddr = "192.168.0.60" DstIPAddr = "192.168.0.41"
Proto = "tcp" Sport = "56060" Oport = "22" Ipld = "27b8" /> </Flow>
<FlowAttrs SrcTTL = "64" DstTTL = "64" SrcTOS = "10" DstTOS = "10" />
<ExtFlow> <TCPExtFlow TCPState - "EST" TCPOptions - "TIME"
SynAckuSecs = "0" AckOatauSecs - "0“ >
<TCPExtMetrics SrcTCPSeqBase - "4204580547"
SrcTCPAckBytes = "527" SrcTCPBytes - "528"
SrcTCPRetrans - "0” SrcTCPWin = "65535" SrcTCPFlags = "PA"
DstTCPSeqBase = "3077608383" DstTCPAckBytes = "1135“
DstTCPBytes - "992" DstTCPRetrans - "0" DstTCPWin - "9792"
OstTCPFlags - "PA" />
</TCPExtFlow>
</ExtFlow>
<Metrics SrcCount - "24" OstCount - "17" SrcBytes = "2112"
DstBytes - "2258" SrcAppBytes - "528" DstAppBytes - "1136" />
</ArgusFlowRecord>■
186Глава 5. Наблюдение и выявление тенденций
<ExtFlow> <TCPExtFlow TCPState = "ESI" TCPOptions = "TIME"
SynAckuSecs = "0" AckDatauSecs = "0" >
<TCPExtMetrics SrcTCPSeqBase = "4204580547"
SrcTCPAckBytes = "527" SrcTCPBytes = "528"
SrcTCPRetrans = "0" SrcTCPWin = "65535" SrcTCPFlags = "PA"
DstTCPSeqBase = "3077608383" DstTCPAckBytes = "1 135"
DstTCPBytes - "992" DstTCPRetrans = "0" DstTCPWin - "9792"
DstTCPFlags = "PA" />
КК<MetricsпSрrcаCoвuиnt л= "м24"е DжstсCoеunтt е= в"1о7г" оSrcBэyкtesр =ан"2а112"<MetricsпSрrcаCoвuиnt л= "м24"е DжstсCoеunтt е= в"1о7г" оSrcBэyкtesр =ан"2а112"На</кTCоPпExлtFlеowн>ие статистики с помощьюlow>
К
К
<MetricsпSрrcаCoвuиnt л= "м24"е DжstсCoеunтt е= в"1о7г" оSrcBэyкtesр =ан"2а112"
<MetricsпSрrcаCoвuиnt л= "м24"е DжstсCoеunтt е= в"1о7г" оSrcBэyкtesр =ан"2а112"
DstBytes = "2258" SrcAppBytes = "528" DstAppBytes = "1136" /> </ArgusFlowСRбeоcрoсrdт>атистики можно доверить межсетевому экрану.DstBytes = "2258" SrcAppBytes = "528" DstAppBytes = "1136" /> </ArgusFlowСRбeоcрoсrdт>атистики можно доверить межсетевому экрану.опчреиньимспалоольмзоевстаан.иПи оОмСимоLiэnтuоxгом, оAжrgнuоs змаопжуестиптрьеосблредазуоювщатуьюэткуомианнфдоурмipаtцabиlюes вдлряазолциечннкыиеифспоромльазтоыва(ниапярпирмоепру, сXкнMоLй),спчотосоубпнроосщтиаеотпсроезддеалнеиненопйримлаошжиениой, «тпроафнимкакюощтоирхо»йэтпиродхаондниыт еч.ерез межсетевой экран:опчреиньимспалоольмзоевстаан.иПи оОмСимоLiэnтuоxгом, оAжrgнuоs змаопжуестиптрьеосблредазуоювщатуьюэткуомианнфдоурмipаtцabиlюes вдлряазолциечннкыиеифспоромльазтоыва(ниапярпирмоепру, сXкнMоLй),спчотосоубпнроосщтиаеотпсроезддеалнеиненопйримлаошжиениой, «тпроафнимкакюощтоирхо»йэтпиродхаондниыт еч.ерез межсетевой экран:
DstBytes = "2258" SrcAppBytes = "528" DstAppBytes = "1136" /> </ArgusFlowСRбeоcрoсrdт>атистики можно доверить межсетевому экрану.
DstBytes = "2258" SrcAppBytes = "528" DstAppBytes = "1136" /> </ArgusFlowСRбeоcрoсrdт>атистики можно доверить межсетевому экрану.
опчреиньимспалоольмзоевстаан.иПи оОмСимоLiэnтuоxгом, оAжrgнuоs змаопжуестиптрьеосблредазуоювщатуьюэткуомианнфдоурмipаtцabиlюes вдлряазолциечннкыиеифспоромльазтоыва(ниапярпирмоепру, сXкнMоLй),спчотосоубпнроосщтиаеотпсроезддеалнеиненопйримлаошжиениой, «тпроафнимкакюощтоирхо»йэтпиродхаондниыт еч.ерез межсетевой экран:
опчреиньимспалоольмзоевстаан.иПи оОмСимоLiэnтuоxгом, оAжrgнuоs змаопжуестиптрьеосблредазуоювщатуьюэткуомианнфдоурмipаtцabиlюes вдлряазолциечннкыиеифспоромльазтоыва(ниапярпирмоепру, сXкнMоLй),спчотосоубпнроосщтиаеотпсроезддеалнеиненопйримлаошжиениой, «тпроафнимкакюощтоирхо»йэтпиродхаондниыт еч.ерез межсетевой экран:
# iptables -N KRYTEN && iptables -A KRYTEN -j ACCEPT
# iptables -N KRYTEN_IN && iptables -A KRYTEN_IN -j KRYTEN
# iptables -N KRYTEN_OUT && iptables -A KRYTEN_OUT -j KRYTEN
# iptables -A FORWARD -S 192.168.0.60 -j KRYTEN_OUT
# iptables -A FORWARD -d 192.168.0.60 -j KRYTEN_IN
Для накопления статистики использования входной и выходной пропускной
способности для трафика, проходящего через межсетевой экран, здесь производится оценка счетчиков пакетов и счетчиков байтов, связанных с каждым правилом iptables. Для этого сначала определяется цепочка KRYTEN, названная в честь узла, для которого накапливается статистика. Эта цепочка содержит безусловное правило, которое используется для быстрого суммирования (add) используемой пропускной способности. Для классификации используемой пропускной способности создана еще одна цепочка, KRYTENJN. Она содержит лишь одно правило,
которое вызывает безусловный переход к цепочке KRYTEN при измерении входного потока. Аналогично, цепочка KRYTEN_OUT подсчитывает исходящую пропускную способность, а затем осуществляет безусловный переход к цепочке KRYTEN. И наконец, правила добавляются в цепочку FORWARD, которая в зависимости от направления движения пакета пересылает его в соответствующую цепочку. После применения этих правил можно увидеть суммарное использование пропускной способности (отдельно входной и выходной) узла kryten с помощью следующей команды:
# iptables -vx -L KRYTEN
Chain kryten (2 references)
pktsbytestargetprotopt inoutsource destination
44246340ACCEPTall-- anyanyanywhere anywhere
Выполнив анализ поля bytes и воспользовавшись утилитой RRDtool, можно построить диаграмму (трюк № 62):
# iptables-vx-LKRYTEN| 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 можно использовать ключ -п, позволяющий запускать демон без аутентификации.
Используя этот параметр, вы можете наблюдать за потоком данных, создаваемым rpcapd с любой программой, использующей интерфейс захвата WinPcap. В противном случае в используемую программу должен быть добавлен специальный код, позволяющий rpcapd опознать ее. Поскольку параметр -п позволяет любому подключаться к демону rpcapd, используя параметр -1, можно задать список узлов (отделяемых друг от друга запятой), которым такое соединение разрешено.
Запуск из командной строки выполняется примерно так:
C:\Program Files\WinPcap>rpcapd -1 obsidian -n
Press CTRL + C to stop the server...
При запуске rpcapd в качестве службы настроечная информация берется из файла rpcapd.ini. Этот файл находится в том же каталоге, что и исполняемый файл, и создается запуском rpcapd с ключом -s.
Для создания rpcapd.ini выполните следующую команду:
C:\Program Files\WinPcap>rpcapd -1 obsidian -n -s rpcapd.ini
Press CTRL + C to stop the server...
Теперь нажмите сочетание клавиш CTRL+C и просмотрите содержание созданного файла:
C:\Program Files\WinPcap>type rpcapd.ini # Configuration file help.
# Hosts which are allowed to connect to this server (passive mode)
# Format: Passiveclient = <name or address>
PassiveClient = obsidian
# Hosts to which this server is trying to connect to (active mode) # Format: ActiveClient = <name or address>. <port | DEFAULT>
# Permit NULL authentication: YES or NOT
NullAuthPermit = YES
Для запуска этой службы необходимо либо воспользоваться приложением Службы (Services) панели управления, либо использовать утилиту net:
C:\Program Files\WinPcap>net start rpcapd
The Remote Packet Capture Protocol v.O (experimental) service was started successfully.
Теперь для подключения к демону требуется найти имя, используемое WinPcap для ссылки на сетевое устройство, за которым необходимо наблюдать. Для этого можно запустить либо WinDump (анализатор пакетов Windows из командной строки), либо Ethereal. WinDump можно загрузить с того же сайта, что и WinPcap.
Для получения имени устройства с помощью WinDump просто запустите его с флагом -D:
C:\Program Files\WinPcap>windump -D
l.\Device\NPF_{EE07A5AE-4D19-4118-97CE-3BF656CD718F} (NDIS 5.0driver)
Получить имя можно также с помощью Ethereal, перейдя в меню Capture и щелкнув на кнопке Start. После этого откроется диалоговое окно, в котором перечислены все доступные в системе сетевые адаптеры (рис. 5.4). Имя устройства (device name) в этом списке — это то имя, которое необходимо указать при подключении к rpcapd с удаленной системы.
Рис. 5.4. Диалоговое окно Ethereal Capture Options
При подключении к удаленной машине с помощью любимого анализатора портов поместите имя сетевого интерфейса, за которым вы хотите наблюдать, после грсар и имени узла:
rpcap://plunder/\Device\NPF_{EE07A5AE-4D19-4118-97CE-3BF656CD718F}
Пример использования Ethereal представлен на рис. 5.5.
Рис. 5.5. Источник удаленного захвата в Ethereal
При правильной настройке поток трафика с удаленной системы будет представлен в анализаторе так, как будто он захвачен с помощью локального интерфейса.
ГЛАВА 6
Защита каналов
Трюки № 67-81
Небезопасные компьютерные сети (такие, как Интернет и общедоступные беспроводные сети) являются враждебной средой, но их можно несколько «укротить». Балансируя между шифрованием и некоторыми приемами инкапсуляции, можно построить более надежные сети, независимо от используемой глобальной сети, даже если она полна негодяев, пытающихся посмотреть или по-другому использовать ваши данные. Эта глава в основном посвящена настройке безопасности и шифрованию сетей, которые не вызывают доверия. Некоторые трюки сконцентрированы в основном на обеспечении безопасности и шифровании транспортного механизма, в других рассматривается создание безопасных виртуальных частных сетей (virtual private network, VPN).
При чтении этой главы вы познакомитесь с настройкой шифрованных соединений на основе IPsec в различных ОС, с созданием интерфейсов частных сетей, которые пользуются каналом зашифрованного соединения, а также с тем, как перенаправить TCP-соединения по зашифрованному каналу. Кроме того, будет рассмотрена настройка кросс-платформенных VPN-решений. Прелесть большинства из представленных трюков заключается в том, что после их изучения вы сможете комбинировать и сопоставлять решения шифрования на транспортном уровне с различными подходами к организации частных сетей, наиболее полно удовлетворяющих вашим требованиям. При этом можно построить широкомасштабную мощную частную сеть, использующую в качестве инфраструктуры Интернет. Эти методики можно реализовать на любом уровне: от организации связи между двумя офисами до построения полностью маршрутизируемой частной сети предприятия, основанной на сети Интернет.
ТРЮКНа 67ТРЮКНа 67НастройкаIPsecвОСLinux
ТРЮК
На 67
ТРЮК
На 67
Обеспечьте безопасность трафика в 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.
В процессе компоновки 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:
#i/etc/ipsec.conf
установка параметров настройки config setup
interfaces=Udefaultroute
отладочные параметры. Установите в "all" для получения подробной информации klipsdebug=none plutodebug=none
стандартная настройка Pluto
plutoload=Usearch
plutostart=%search
гарантирует отсутствие проблем PMTU Discovery overridemtu=1443
установка настройки по умолчанию conn ^default
быть агрессивным в попытках повторного обмена ключами keyingtries=O
использовать IKE keyexchange=ike keyl1fe=12h
использовать общие секреты authby=secret
настройка VPN в Internet conn wireless_connectionl type=tunnel
левая - сторона клиента left-192.168.0.104
правая - шлюз Интернета
right=192.168.0.1
r1ghtsubnet=0.0.0.0/0
автоматическое установление соединения auto=start
Теперь добавьте в ipsec.secrets совместно используемый «секрет»:
192.168.0.104 192.168.0.1: PSK "supersecret"
Вот и все. После настройки шлюза попробуйте «прозвонить» (ping) шлюз по умолчанию. Pluto запустится автоматически и установит соединение. Если шлюз недоступен, просмотрите сообщения в журнале событий syslog на клиентской стороне и на шлюзе.
Настройка шлюза в значительной степени схожа с настройкой клиента. Если вы имеете представление о ipsec.conf, это не составит никакого труда. Нам придется внести лишь незначительные изменения. Если шлюз имеет более одной сетевой Ethernet-карты, то необходимо жестко настроить IPsec на использование конкретного сетевого интерфейса:
# assume internal ethernet interface is ethO interfaces="1psec0=eth0"
После этого необходимо будет добавить соединение для каждого внутреннего клиента. Это можно сделать различными способами в зависимости от масштабов сети; представленная далее настройка будет работать для умеренного количества клиентов:
conn wireless_connection2
type=tunnel
left-192.168.0.105
right=192.168.0.1
rightsubnet=0.0.0.0/0
auto=start
7 Зак 1103
НастройкаIPsecвОСFreeBSD Для безопасности трафика во FreeBSD используйте встроенную в эту ОС поддержку IPsec.
Использование IPsec с IKE в ОС FreeBSD требует включения IPsec в ядро и установки пользовательской программы (racoon), для того чтобы добиться согласованности с IKE.
Необходимо убедиться, что ядро скомпилировано при использовании следующих параметров:
options
IPSEC
#IP security.
options
IPSEC_ESP
#IP security (crypto: define w/ IPSEC)
options
<PSEC DEBUG
#debug for IP security
Если это не так, то вам необходимо определить их, а затем скомпоновать и установить ядро. После этого выполните перезагрузку системы, чтобы проверить ее работоспособность.
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 "userl@domain.com": • 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 $04 {start|stop}" >&2 esac exit 0
(в нашем случае — адрес электронной почты) и «секрет». Например, файл psk.txt может иметь следующее содержание:
userl@doma1n.com supersecret
И наконец, с помощью утилиты setkey, добавляющей записи в SPD ядра, необходимо установить политику безопасности. Создайте представленный далее файл client.spd, который можно загрузить утилитой setkey. Для данного варианта установки IP-адрес станции — 192.168.0.104, а адрес шлюза — 192.168.0.1:
spdadd 192.168.0.104/32 0.0.0.0/0 any -Р out ipsec \ esp/tunnel/192.168.0.104-192.168.0.1/requi re :
spdadd 0.0.0.0/0 192.168.0.104/32 any -P In Ipsec \ esp/tunnel /192.168.0.1-192.168.0.104/requ1 re :
Первый элемент создает политику безопасности, которая отправляет весь трафик в конечную точку VPN. Второй элемент создает политику безопасности, разрешающую весь трафик от конечной точки VPN. Обратите внимание на то, что такая конфигурация клиента не позволяет общаться ни с одним узлом локальной подсети, кроме VPN-шлюза. В беспроводной сети, где клиент является основной целью атаки, такое решение для рабочей станции, вероятно, является удачным.
Загрузите SPD, выполнив
setkey -f client.spd
Файл racoon.conf шлюза такой же, как и на стороне клиента. Он позволяет подключаться любому клиенту. Файл psk.txt должен содержать все идентификационные и совместно используемые «секреты» всех клиентов, которым разрешено подключение, например: userl@domain.comsupersecret
user2@domain.comevenmoresecret
user3@domain.comnotsosecret
Убедитесь также в том, что файл psk.txt доступен для прочтения только root-гюль- зователю. Запустите racoon и убедитесь в отсутствии ошибок. И в заключение настройте gateway.spd, который создаст SPD для каждого клиента. Приведенный далее пример предполагает наличие клиентов с адресами 192.168.0.10(4-6): # spdadd 0.0.0.0/0 192.168.0.104/32 any -Р out ipsec \ esp/tunnel/192.168.0.1-192.168.0.104/requi re :
spdadd 192.168.0.104/32 0.0.0.0/0 any -P in ipsec \
esp/tunnel/192.168.0.104-192.168.0.1/require :
spdadd 0.0.0.0/0 192.168.0.105/32 any -P in ipsec \
esp/tunnel/192.168.0.1-192.168.0.105/require :
spdadd 192.168.0.105/32 0.0.0.0/0 any -P out \
ipsec esp/tunnel/192.168.0.105-192.168.0.1/require :
spdadd 0.0.0.0/0 192.168.0.106/32 any -P in ipsec \
esp/tunnel/192.168.0.1-192.168.0.106/require :
spdadd 192.168.0.106/32 0.0.0.0/0 any -P out ipsec \
esp/tunnel/192.168.0.106-192.168.0.1/require :
Загрузите 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, который должен содержать
следующее:
192.168.1.1Defined192.168.1.1DefinedISAKMP-peer-remoteISAKMP-peer-remote[General] Listen-on= Shared-SADB=
192.168.1.1
Defined
192.168.1.1
Defined
ISAKMP-peer-remote
ISAKMP-peer-remote
[Phase 1] Default* #Default=
[Phase 2]
Passive-Connections=IPsec-local-remote
1 udp 192.168.1.1 Default-main-mode mypassword1 udp 192.168.1.1 Default-main-mode mypassword[ISAKMP-peer-remote] Phase=
1 udp 192.168.1.1 Default-main-mode mypassword
1 udp 192.168.1.1 Default-main-mode mypassword
Transport= Local-address=
Configuration=
Authenti cation=
[1SAKMP- peer- remote-aggressive]
Phase-
1
Transport-
udp
Local -address-
192.168.1.1
Configuration-
Defa u11-agg res s i ve-mode
Authentication-
mypassword
[IPsec-local-remote]
Phase-
2
ISAKMP-peer-
ISAKMP- peer- remote
Configuration-
Default-quick-mode
Local -ID-
Net-local
Remote- I D=
Net-remote
[Net-remote]
ID-type-
IPV4_ADDR
Address-
0.0.0.0
[Net-local]
ID-type-
IPV4_ADDR
Address-
0.0.0.0
[Default-main-mode]
DOI-
IPSEC
EXCHANGE_TYPE-
ID_PROT
Transforms-
3DES-SHA
[Defau11-aggres s1ve-mode]
DOI-
IPSEC
EXCHANGE_TYPE-
AGGRESSIVE
Transforms-
3DES-SHA-RSA
[Default-quick-mode]
DOI-
IPSEC
EXCHANGE_TYPE-
QUICK_MODE
Suites-
QM-ESP-AES-SHA-PFS-SUITE
Такая конфигурация позволит подключаться с паролем mypassword. После настройки файлов необходимо запустить isakmpd:
/5Ып/15актрс1я
Для того чтобы isakmpd запускался при каждой загрузке системы, необходимо изменить /etc/rc.conf.local (или создать его, если он отсутствует) и добавить в него строку
isakmpd_flags=""
И все. Как обычно, если возникли проблемы подключения канала, проверьте протоколы системы.
Организация канала РРТР
VPN-доступ легко и быстро устанавливается с помощью протокола Point-to-Point Tunneling Protocol.
Использование протокола Point-to-Point Tunneling Protocol (РРТР), как правило, означает автоматическое установление каналов РРР (трюк № 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
Эти параметры обычно заставляют pppd использовать аутентификацию (auth) и указывают, что элементы файла /etc/ppp/chap-secrets соответствуют этому экземпляру pppd (имя pptpd). Поэтому для завершения настройки аутентификации pptpd в файле /etc/ppp/chap-secrets необходимо создать элемент для каждого клиента. Вот пример такого элемента, позволяющего пользователю с именем andrew подключаться с использованием пароля mypassword с любого удаленного IP-адреса:
Secrets for authentication using CHAP
clientserver secretIP addresses
andrewpptpd I mypassword*
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).
Рис. 6.З. Выбор VPN-соединения
Щелкните на кнопке Далее и укажите наименование нового соединения (например, РоРТоР Test). Еще раз щелкните на кнопке Далее и введите внешний IP-адрес сервера, на котором выполняется pptpd. Щелкните на кнопке Далее и затем на кнопке Готово (Finish). Появится диалоговое окно регистрации (рис. 6.4).
Перед вводом имени и пароля, указанных в файле /etc/ppp/chap-secrets, необходимо щелкнуть на кнопке Параметры (Properties) и перейти на вкладку Безопасность (Security). Найдите на ней флажок Требуется шифрование данных (Require data encryption) и сбросьте его (рис. 6.5).
Теперь щелкните на кнопке ОК для ввода регистрационной информации, а также на кнопке Подключиться (Connect). Через несколько секунд вы будете подключены
к РРТР-серверу, и вам будет присвоен IP-адрес, выбранный из указанного пула адресов. Теперь можно проверить новое соединение, «прозвонив» удаленную сторону канала. При активном РРТР-соединении весь трафик, покидающий клиентскую сторону, будет шифроваться и отправляться на РоРТоР-сервер. Отсюда трафик пойдет к месту назначения.
Рис. 6.5. Изменение свойств системы безопасности
Адаптивное шифрование с помощью 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
INTXTI"X-IPsec-Server(10)=@colossus.nnc" "
AQ0R7rM7ZMBXu2ej/lvtzhNnMayZ01jwVHUyAIubTKpd/PyTMogJBAdbb3I0xzGLaxadPGfiqPN2AQn7 6zLIsYFMJnoMbBTDY/2xKlX/pWFRUUIHzJUqCBIijVWEMLNrIhdZbeils5/MgYIPaX20UL+yAdxV4RUU
CjZ0vZG6m
0byBg2HuWZMtWr
M8VrTQqi7IGGHK+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 с Iпомощью команды # /etc/init.d/ipsec restart
Теперь можно подключиться к любому узлу, поддерживающему адаптивное шифрование. А что делать, если другие узлы хотят подключиться к вам? Чтобы обеспечить эту возможность, необходимо создать ТХТ-запись вашей машины в обратной DNS-зоне. Для генерации такой записи выполните следующую команду:
ipsec showhostkey --txt 192.168.0.64
: RSA 2192 bits colossus Tue Jan 13 03:02:07 2004
IN TXT "X-IPsec-Server(10H92.168.0.64" "
AQOR7rM7ZMBXu2ej/lvtzhNnMayZOljwVHUyAlubTKpd/PyTMogJBAdbb3I0xzGLaxadPGfiqPN2AQn7 6zLIsYFMJnoMbBTDY/2xKlX/pWFRUUIHzJUqCBIijVWEMLNrlhdZbeils5/MgYIPaX20UL+yAdxV4RUU 3JJQhV7adVzQqEmdaNUnCjZ0vZG6m4zv6dGR0rVEZmJFP54v6WhckYfqSkQu3zkctfFgzJ/rMTB6Y38y 0byBg2HuWZMtWI"
"8VrTQqi 7IGGHK+mWk+wSoXer3i FD7JxRTzP0xlk6ihAJMi btKna3j7QP9ZHG0nm7NZ/L5M9VpK+Rfe+e vUUMUTfAtSdlpus2BIeXGWcPfz6rw305H9"
Добавьте эту запись в обратную зону вашей подсети, что позволит другим машинам инициировать адаптивное шифрование в отношении вашей машины. При использовании адаптивного шифрования весь трафик между узлами будет автоматически шифроваться, одновременно защищая все службы. Здорово, да?
ТРЮК№72ТРЮК№72Перенаправление и шифрование трафика с помощью SSH
ТРЮК
№72
ТРЮК
№72
Обеспечьте защиту сетевого трафика произвольного порта с помощью перенаправления порта.
Помимо удаленного доступа к ядру и выполнения команд, OpenSSH позволяет осуществлять перенаправление произвольного TCP-порта на противоположный конец соединения. Это чрезвычайно удобно для защиты трафика электронной почты, содержимого web-сайтов и другого трафика, который необходимо сохранить в неприкосновенности (по крайней мере, на протяжении канала до противоположной стороны).
SSH осуществляет локальное перенаправление за счет привязки локального порта, выполнения шифрования и отправки зашифрованных данных удаленной стороне SSH-соединения. После чего выполняются их дешифрование и отправка на указанный удаленный узел и порт. Запуск SSH-канала осуществляется с помощью ключа -L (сокращение от Local):
ssh -f -N -L 110:я7<э7 7/7OSt: 110 userQmailhost
Естественно, подставьте вместо user имя пользователя, а вместо mail host — имя или IP-адрес вашего почтового сервера. Обратите внимание на то, что для реализации этого примера требуется наличие root-полномочий, поскольку выполняется привязка к привилегированному порту (110-й порт используется РОРЗ). Кроме того, необходимо отключить любой локально запущенный демон РОРЗ (см. /etc/ inetd.conf), в противном случае он может повлиять на конечный результат.
Теперь для шифрования всего РОРЗ-трафика настройте почтового клиента на подключение к локальному 110-му порту. Он с удовольствием пообщается с mail host,
как будто соединен с ним непосредственно, но весь разговор будет зашифрован. В качестве альтернативы можно заставить SSH «слушать» порт с номером, большим 1024, что избавит от необходимости запускать его с полномочиями root. В этом случае также необходимо настроить почтового клиента на использование этого порта.
Ключ -f заставит SSH работать в фоновом режиме, а ключ -N — не выполнять команду на удаленной стороне (выполнять лишь ее перенаправление). Интересная особенность использования этого ключа заключается в том, что перенаправить порт можно, даже если вы не зарегистрировались на удаленном сервере. Однако, для того чтобы это сработало, предварительно установите опознавание этой учетной записи с использованием открытого ключа. Для включения сжатия можно использовать также ключ -s (если SSH-сервер поддерживает его). Это может значительно сократить время получения электронной почты. Кроме того, соединение можно еще более ускорить, используя blowfish-шифр, который, как правило, работает в 3 раза быстрее (по умолчанию). Для использования этого шифра введите -с blowfish. С помощью ключа -L можно указать желаемое количество линий при установлении соединения.
Для аналогичного перенаправления исходящей почты попробуйте такую команду:
#ssh-f-N -L iiO:/7?(377/?0S£:iio -L 2b-.mailhost:2b userQmailhost
Укажите в качестве исходящего узла электронной почты local host, и трафик электронной почты будет закодирован так же, как и на почтовом узле (mai lhost). Обычно это полезно только в том случае, если электронная почта ограничена внутренним узлом либо если вы не доверяете локальному сетевому соединению (как в большинстве беспроводных сетей). Очевидно, что, после того как почта покинет почтовый узел (mai lhost), она будет передаваться в открытом виде, если только вы не зашифровали сообщения с помощью такого средства, как рдр или дрд.
Если вы зарегистрировались на удаленном узле и быстро хотите перенаправить порт, сделайте следующее:
Нажмите клавишу Enter.
Нажмите Ctrl+C.
Должно появиться приглашение ssh>. Введите строку -L, как если бы вы находились в режиме командной строки, например:
rob@catlin:~$
rob@catlin:~$ -С(it doesn't echo)
ssh> -L8080:local host:80
Forwarding port.
Текущее ядро перенаправит локальный порт 8000 на 80-й порт узла catlin, как если бы вы ввели его на первом месте. Имеется возможность с помощью ключа -д разрешить другим (удаленным) клиентам подключаться к перенаправленному порту. Если вы прошли процедуру регистрации на удаленном шлюзе, выполняющем роль NAT для частной сети, то используйте команду
$ ssh -f -g -N -L8000:local host:80 10.42.4.6
Это произведет перенаправление всех соединений с 8000-го порта шлюза на 80-й порт внутреннего узла 10.42.4.6. Если шлюз имеет «живой» Интернет-адрес, то это позволит любому пользователю Сети подключиться к web-серверу на 10.42.4.6, как если бы он был запущен на 8000-м порте шлюза.
Еще один достойный внимания момент: перенаправляемый узел не должен быть локальным узлом. Он должен быть любым узлом, с которым подключаемая машина может обращаться напрямик. Например, для перенаправления локального 5150-го порта на web-сервер, находящийся где-то во внутренней сети, попробуйте выполнить команду
$ ssh -f -N -L5150:intranet.insider.nocat:80 gateway.nocat.net
Полагая, что вы запускаете частный домен с именем .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. (Как вам не стыдно использовать первую
версию! При первой же возможности переходите на вторую!) Желательно использовать RSA-ключи, поскольку с DSA-ключами бывают проблемы, хотя они используются очень редко. После ввода команды вы увидите следующее:
Generating public/private rsa key pair.
Enter file 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@loca1host
Создано два файла, ~/.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-доступа к машине? Как часто один и тот же пароль используется на различных
Многословный вариант пароля.
(или всех) машинах? Вы когда-нибудь использовали этот пароль в сомнительных случаях (на web-сайте, на личной машине, которая не совсем совершенна, либо с SSH-клиентом на машине, которой не можете управлять)? Наверняка, любая из этих ситуаций для вас не нова; в этом случае SSH-ключ с такими же настройками сделает практически невозможным получение несанкционированного доступа к вашей сети (конечно же, если секретный ключ хранится в безопасном месте).
Еще одним способом сохранения равновесия между простотой использования и безопасностью является применение идентификационной фразы (passphrase) в вашем ключе, но для управления ключами используйте SSH-агента. При запуске агента будет однократно запрошена идентификационная фраза, которая будет сохранена в кэш-памяти до момента уничтожения (kill) агента. Некоторые люди доходят до того, что хранят SSH-ключи на съемных носителях (например, на USB флеш-карте) и постоянно носят их с собой. Однако если вы выбрали использование SSH-ключей, то сразу поймете, что они являются очень полезной альтернативой традиционным паролям.
Роб Фликипгер (Rob Flickenger) «Трюки Linux-сервера» («Linux Server Hacks»)
Squid-проксиnoSSH
Защитите 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 выходит за рамки рассматриваемого трюка, так как настройка его очень сложна. Убедитесь в наличии у вас прав доступа и установите пароль для интерфейса обслуживания. Если имеются проблемы
с запуском, изучите страничку Дженифер Весперман (Jennifer Vesperman) «Install- ing 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, где он будет расшифрован и отправлен в Интернет.
Самым большим преимуществом этой методики (по сравнению с использованием прокси 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-пользователь. Динамическое перенаправление порта также может указываться в файле настройки».)
Если у вас имеется программное обеспечение, совместимое с 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. Любой, кто прослушивает беспроводной трафик, теперь
видит огромный зашифрованный 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-разрешение. Это особенно понравится пользователям
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.
Давайте рассмотрим базовую форму файла настройки, указывающего перенаправление локального порта на удаленный порт. Клиентская сторона: pid = client = yes
[<server port>]
accept = <forwarded port>
connect = <remote address>:<server port>
The server side:
cert = /etc/stunnel/stunnel.pem pid -
client - no
[«forwarded port>] accept = «server port> connect = «forwarded port>
214Глава 6. Защита каналов
The server side:
cert = /etc/stunnel/stunnel.pem pid -
client = no
[<forwarded port>]
accept = <server port>
connect = <forwarded port>
Можно использовать стандартный файл настройки или выбрать иной файл. В первом случае stunnel запускается безо всяких аргументов. В противном случае следует указать необходимый файл настройки в качестве первого аргумента. При имеющейся сейчас настройке программа способна подключиться к <forwarded port> (перенаправляемому порту) на клиентской стороне. После этого stunnel зашифрует трафик, получаемый с этого порта, и отправит его на <server port> (серверный порт) удаленной стороны, указанной в <remote address> (адрес удаленной стороны). На удаленной системе stunnel дешифрует полученный на указанный порт трафик и направит его программе, которая «слушает» <forwarded port> на удаленной системе.
Эквивалентная команда перенаправления портов в SSH могла бы выглядеть так: ssh -f -N -L <forwarded port>:<remote address>:<forwarded port> \<remote address> Если есть желание указать 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.
В качестве альтернативного варианта можно вообще покончить с inetd и заставить stunnel «слушать» соединения клиентов, а затем порождать подпроцесс от самого процесса службы. Для этого создайте файл настройки с подобным содержанием: cert = /etc/stunnel/swat.pern
[swat]
accept = 901
exec - /usr/local/samba/bin/swat execargs = swat
После этого запустите stunnelI с указанием пути к этому файлу:
# stunnel !/etc/stunnel/swat.conf
Кроме того, эту программу можно запускать во время загрузки, поместив предыдущую команду в сценарий запуска (то есть в /etc/rc.local).
Stunnel — очень мощное средство: оно может не только перенаправлять соединения по зашифрованному каналу, но и использоваться для добавления SSL- возможностей в распространенные службы. Это особенно удобно, когда уже существуют клиенты с SSL-поддержкой. Таким образом, на серверной стороне достаточно использовать лишь stunnel, которая обеспечивает шифрование службы без необходимости установки дополнительного программного обеспечения.
ТРЮКNs 77ТРЮКNs 77Канальные соединения внутри HTTP
ТРЮК
Ns 77
ТРЮК
Ns 77
Прорыв через «строгие» межсетевые экраны с помощью httptunnel.
Если вы когда-либо были в пути и оказывались там, где единственным средством общения с внешним миром являлся невероятно «строгий» межсетевой экран, вы, вероятно, представляете страдания при попытке добиться чего-либо, кроме отправки/получения электронной почты и общего просмотра web-страниц.
На помощь приходит httptunnel (http://www.nocrew.org/software/httptunnel.html). Эта программа позволяет организовать канал по HTTP-протоколу для произвольного соединения с удаленным узлом. Это особенно полезно в упомянутом случае, когда web-доступ разрешен, а остальные службы запрещены. Конечно же, можно воспользоваться различным каналообразующим программным обеспечением и настроить его на использование 80-го порта, но что делать, если межсетевой экран на самом деле является web-прокси? Это приблизительно то же, что межсетевой экран на уровне приложения, способного принимать только действительные HTTP-запросы. К счастью, с этим хорошо справляется httptunnel.
Для компиляции httptunnel загрузите архив и запустите команды configure и make:
$ tar xfz thttptunnel-3.3.tar.gz
$ cd httptunnel-3.3
$ ./configure && make
Установите его с помощью команды make install, которая поместит все файлы в подкаталог каталога /usr/local. При необходимости установки в иное место можно воспользоваться стандартным параметром --prefix-
Клиентская часть программы httptunnel называется htc, а сервер — hts. Как и SSH (см. трюк № 76), httptunnel может «прослушивать» локальный TCP-порт в ожидании соединения, перенаправлять получаемый трафик через этот порт на удаленный сервер, а затем дешифровать и перенаправлять трафик другому порту вне канала.
Попробуйте организовать канал SSH-соединения через HTTP. Запустите на сервере такую команду:
# hts -F localhost:22 80
А теперь на клиентской стороне запустите
# htc -F 2222 colossus:80
В этом случае colossus — удаленный сервер, и htc «слушает» порт 2222. Если локально нс запущен sshd, то можно использовать стандартный 22-й порт. При желании можно проверить, что htc «слушает» именно 2222-й порт, следующей командой: # /usr/sbin/lsof -1 | grep htc htc 2323 root 6u IPv4 0x02358a30 OtO TCP *:2222 (LISTEN)
А теперь проверим канал:
[andrew@kryten andrew]$ ssh -p 2222 local host andrew@localhost's password:
[andrew@colossus andrew]$
Перенаправлять соединение можно даже на машину, на которой не запущен hts. Для этого просто замените в hts-команде local host именем необходимого удаленного узла. Например, для перенаправления соединения на oceana.ingsoc.net вместо colossus запустите следующую команду:
# hts -F oceana.1ngsoc.net:22 80
Если любопытно посмотреть, как выглядит SSH-соединение через НТТР-прото- кол, взгляните на него с помощью анализатора пакетов. Вот начальный фрагмент TCP-потока, отправляемого клиентом на httptunnel-сервер:
POST /index.html?crap=1071364879 HTTP/1.1
Host: linux-vm:80
Content-Length: 102400 Connection: close
SSH-2.0-0penSSH_3.6.lpl+CAN-2003-0693
Если канал должен пройти через web-прокси, а прокси «прозрачен» и не требует идентификации, то дополнительной настройки не потребуется. Если прокси «непрозрачен», можно воспользоваться ключом -Р. Помимо этого, если требуется идентификация на прокси, можно использовать параметр -А или
--proxy-authorization, позволяющий для идентификации указать имя и пароль. Вот как они используются:
htc -P myproxy:8000 -A andrew:mypassword -F 22 colossus:80
Если порт, который «слушает» прокси, является стандартным портом web-npo- кси (8080), то прокси можно указать с помощью IP-адреса или имени узла.
ТРЮК№ 78ТРЮК№ 78СозданиеканаласпомощьюVTunиSSH
ТРЮК
№ 78
ТРЮК
№ 78
Свяжите две сети с помощью 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
Как видим, локальная lсеть использует адрес 10.42.3.0-26, IP — 10.42.3.2, а шлюз по умолчанию — I10.42.3.1. Этот шлюз обеспечивает трансляцию сетевого адреса
(network address translation, NAT) в Интернет. Вот как этот путь выглядит для yahoo.com:
root@cl1 ent:~# traceroute -n yahoo.com
traceroute to yahoo.com (64.58.79.230). 30 hops max. 40 byte packets
10.42.3.1 2.848 ms 2.304 ms 2.915 ms
209.204.179.1 16.654 ms 16.052 ms 19.224 ms
208.201.224.194 20.112 ms 20.863 ms 18.238 ms
208.201.224.5 213.466 ms 338.259 ms 357.7 ms
206.24.221.217 20.743 ms 23.504 ms 24.192 ms
206.24.210.62 22.379 ms 30.948 ms 54.475 ms
206.24.226.104 94.263 ms 94.192 ms 91.825 ms
206.24.238.61 97.107 ms 91.005 ms 91.133 ms
206.24.238.26 95.443 ms 98.846 ms 100.055 ms
216.109.66.7 92.133 ms 97.419 ms 94.22 ms
216.33.98.19 99.491 ms 94.661 ms 100.002 ms
216.35.210.126 97.945 ms 93.608 ms 95.347 ms
64.58.77.41 98.607 ms 99.588 ms 97.816 ms
В этом примере мы подключаемся к серверу канала в Интернете на 208.201.239.5. Он имеет два запасных живых IP-адреса (208.201.239.32 и 208.201.239.33), которые используются для туннелирования. Мы обращаемся к этой машине как к серверу, а локальная машина выполняет роль клиента. Теперь запустим канал (туннель). Для начала запустите драйвер tun на обеих машинах:
# modprobe tun
Ничего страшного, если этот драйвер не запустится при несовпадении версий ядра сервера и клиента. Для получения гарантированного результата используйте свежие и одинаковые (например, 2.4.20) версии на обеих машинах. На машине, являющейся сервером, сохраните представленные далее строки в файле /usr/ local/etc/vtund.conf:
options {
port 5000;
ifconfig /sbin/ifconfig:
route /sbin/route:
syslog auth:
}
default {
compress no:
speed 0:
home {
type tun;
proto tcp:
stat yes:
keepalive yes:
pass sHHH: # Password is REQUIRED.
up {
Ifconfig "^ 208.201.239.32 pointopoint 208.201.239.33":
program /sbin/агр "-Ds 208.201.239.33 %% pub":
program /sbin/агр "-Ds 208.201.239.33 ethO pub": route "add -net 10.42.0.0/16 gw 208.201.239.33": }:
down {
program /sbin/агр "-d 208.201.239.33 -1 XX";
program /sbin/агр "-d 208.201.239.33 -i ethO";
route "del -net 10.42.0.0/16 gw 208.201.239.33":
}
Запустите vtund-сервср:
rooWserver:-# vtund -s
Теперь необходимо создать файл vtund.conf для клиентской стороны. Снова сохраните приведенные далее строки в /usr/local/etc/vtund.conf:
options {
port 5000:
ifconfig /sbin/ifconfig:
route /sbin/route:
default {
compress no: speed 0;
}
home {
type tun:
proto tcp:
keepalive yes:
pass sHHH: # Password is REQUIRED.
up {
ifconfig "XX 208.201.239.33 pointopoint 208.201.239.32 arp";
route "add 208.201.239.5 gw 10.42.3.1":
route "del default":
route "add default gw 208.201.239.32": }:
down {
route "del default":
route "del 208.201.239.5 gw 10.42.3.1":
route "add default gw 10.42.3.1":
}:
}
И в заключение запустите на клиентской стороне
root@client:~# vtund -р home server
Установлен не только канал между клиентом и сервером, но и новый маршрут по умолчанию через другой конец канала. Взгляните, как выглядит маршрут до yahoo.com при наличии канала:
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.368 ms 28.019 ms 19.114 ms
2 208.201.239.1 21.677 ms 22.644 ms 23.489 ms
3 208.201.224.194 20.41 ms 22.997 ms 23.788 ms
4 208.201.224.5 26.496 ms 23.8 ms 25.752 ms
5 206.24.221.217 26.174 ms 28.077 ms 26.344 ms
6 206.24.210.62 26.484 ms 27.851 ms 25.015 ms
206.24.226.103 104.22 ms 114.278 ms 108.575 ms
206.24.238.57 99.978 ms 99.028 ms 100.976 ms
206.24.238.26 103.749 ms 101.416 ms 101.09 ms
216.109.66.132 102.426 ms 104.222 ms 98.675 ms
216.33.98.19 99.985 ms 99.618 ms 103.827 ms
216.35.210.126 104.075 ms 103.247 ms 106.398 ms
64.58.77.41 107.219 ms 106.285 ms 101.169 ms
Этот означает, что любой серверный процесс, запущенный у клиента, теперь полностью доступен из Интернета по IP-адресу 208.201.239.33. Все это происходит без внесения изменений (например, перенаправления порта) в работу шлюза 10.42.3.1. Вот как теперь выглядит канал со стороны клиента:
root@client:~# ifconfig tunO
tunO Link encap:Point-to-Point Protocol
inet addr.-208.201.239.33 P-t-P:208.201.239.32 Mask:255.255.255.255
UP POINTOPOINT RUNNING MULTICAST MTU:1500 Metric:1
RX packets:39 errors:0 dropped:0 overruns:0 frame:0
TX packets:39 errors:0 dropped:0 overruns:0 carri er:0 collisions:0 txqueuelen:10
RX bytes:2220 (2.1 Kb) TX bytes:1560 (1.5 Kb)
А вот как выглядит обновленная таблица маршрутизации (обратите внимание на то, что необходимо сохранить маршрут узла к IP-адресу сервера канала через старый шлюз по умолчанию, иначе трафик канала не сможет выйти): root@client:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
208.201.239.5 10.42.3.1 255.255.255.255 UGH 0 0 0 eth2
208.201.239.32 * 255.255.255.255 UH 0 0 0 tunO
0 * 255.255.255.192 U 0 0 0 eth2
0 * 255.255.255.192 U 0 0 0 ethO
loopback * 255.0.0.0 U 0 0 0 lo
default 208.201.239.32 0.0.0.0 UG 0 0 0 tunO
Для закрытия канала просто уничтожьте процесс vtund на стороне клиента. Это вернет все сетевые настройки в исходное состояние.
Этот метод работает отлично, если вы позволяете 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:~#1iptables -A INPUT -t filte r -i ethO \
-p tcp --dport 5000 -j DROP
Это разрешит прохождение локальных соединений (поскольку они используют цепь обратной связи), а для установления соединения они потребуют SSH-канал к серверу.
Как можно отметить, это крайне удобное средство. Помимо предоставления живого IP-адреса машинам, находящимся после NAT, можно эффективным образом связывать две сети, если между ними имеется одно SSH-соединение (исходящее с любой стороны).
Если вы затрудняетесь или вам лень настроить vtund.conf и вы не хотите разбираться в том, что необходимо изменить при настройке этого файла на клиентской стороне, обратитесь к автоматическому генератору vtund.conf (трюк № 79).
Роб Фликипгер (Rob Flickenger) «Трюки Linux-сервера» («Linux SewerHacks»)
Автоматический генератор vtund.conf
Сгенерируйте vtund.conf «на лету» для удовлетворения изменившимся сетевым условиям.
Если вы только что изучили трюк № 78, то вам будет приятно узнать, что представленный далее сценарий позволит автоматически сгенерировать файл vtund.conf для клиентской стороны.
Если вы не изучили предыдущий трюк (или никогда не использовали 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
IfTunnel Nameisblank,thewrapperwilllookat@ARGVor $0.
#
Config is TunnelName, Local IP, RemotelP. TunnelHost, TunnelPort, Secret #
my STunnelName = "";
my SConf1g= q{
home 208.201.239.33 208.201.239.32 208.201.239.5 5000 sHHH
tunnel2 10.0.1.10010.0.1.1192.168.1.46001 foobar
}:
################ MAIN PROGRAM BEGINS HERE
use POSIX 'tmpnam';
use 10::File;
use File::Basename:
use strict:
Where to find things...
#
$ENV{PATH} =
"/bin:/usr/bin:/usr/local/bin.7sbin:/usr/sbin:/usr/1ocal/[RETURN]sbin":
my $IP_Match = '((?:\d{1.3}\.){3}\d{1.3})':# match xxx.xxx.xxx.xxx
my Slfconfig = "ifconfig -a":
my SNetstat = "netstat -rn":
my SVtund = "/bin/echo":
my SDebug = 1:
Load the template from the data section.
#
my Stemplate = join( "", ):
Open a temp file -- adapted from Perl Cookbook. 1st Ed., sec. 7.5.
#
my ( Sfile. Sname ) = ("", ""):
Sname = tmpnam( )
until Sfile = 10: :File->new( Sname. O RDWR|O_CREAT|O_EXCL ):
END { unlink( Sname ) or warn "Can't remove temporary file Sname!\n": }
If no TunnelName is specified, use the first thing on the command line.
or if there isn't one. the basename of the script.
This allows users to symlink different tunnel names to the same script.
#
STunnelName ||= shift(@ARGV) || basename(SO):
die "Can’t determine tunnel config to use!\n" unless STunnelName:
Parse config.
#
my (SLocallP. SRemotelP. STunnelHost. STunnelPort. SSecret):
for (split(/\r*\n+/. SConfig)) {
my (Sconf. @vars) = grep( S_ ne "". split! /\s+/ )):
next if not Sconf or Sconf =- Z^\s*#/o: # skip blank lines, comments
if (Sconf eq STunnelName) {
(SLocallP. SRemotelP. STunnelHost. STunnelPort. SSecret) = @vars: last:
}
)
die "Can't determine configuration for TunnelName 'STunnelName'!\n" unless SRemotelP and STunnelHost and STunnelPort:
Find the default gateway.
#
my ( SGatewaylP. SExternalDevice ):
for (qx{ SNetstat }) {
In both Linux and BSD. the gateway is the next thing on the line.
and the interface is the last.
#
if ( /A!?:0.0.0.0|default)\s+!\S+)\s+.*?(\S+)\s*S/o ) {
SGatewaylP -SI:
SExternalDevice = $2: last;
}
die "Can't determine default gateway!\n" unless SGatewaylP and SExternalDevice:
Figure out the Local IP and LocalNetwork.
#
my ( SLocalNetwork ):
my ( Si face. Saddr. Sup. Snetwork. Smask ) = "":
sub compute_netmask {
(Saddr. Smask) = @_:
We have to mask Saddr with Smask because linux /sbin/route
complains if the network address doesn’t match the netmask.
#
my @ip = split! /V/, Saddr ):
my task = split! /V/. Smask ):
$1p[$_] = !$ip[$_] + 0) & !$mask[$_] + 0) for (O..$#ip):
Saddr = join!".". @ip):
return Saddr:
for (qx{ Slfconfig }) { last unless defined $_:
If we got a new device, stash the previous one (if any).
if ( /A([A\s:]+)/o ) {
if ( Si face eq SExternalDevice and Snetwork and Sup ) { SLocalNetwork = Snetwork: last:
Si face = $1:
Sup = 0:
}
8 Зак. 1103
default { compress no speed 0:
'mytunneT should really be 'basename $0' or some such
for automagic config selection
STunnelName {
type tun:
proto tcp:
keepalive yes:
pass SSecret:
up {
1fconf1g "%% SLocallP $PTP SRemotelP arp":
route "add STunnelHost SGW SGatewayIP":
route "delete default":
route "add default SGW SRemotelP":
route "add SNET SLocalNetwork SGW SGatewayIP":
}:
down {
Ifconfig "XX down":
route "delete default":
route "delete STunnelHost SGW SGatewayIP";
route "delete SNET SLocalNetwork":
route "add default SGW SGatewayIP":
}:
}
Роб Фликингер (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 достигает своей цели за счет обеспечения всего шифрования, управления ключами и настройки соединений в одном пользовательском демоне, оставив работу по обеспечению действительного туннелирования операционной системе узла.
Для создания канала OpenVPN использует виртуальные устройства операционной системы (TUN или ТАР). Эти устройства экспортируют интерфейс виртуальной сети, который впоследствии используется для обеспечения интерфейса «point- to-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 в1подкаталог каталога /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
Если сценарий нашел библиотеки, то результат будет подобным следующему: configure: checking for LZO Library and Header files...
checking Izolx.h usability... yes
checking Izolx.h presence... yes
checking for Izolx.h... yes
checking for lzolx_l_15_compress in -llzo... yes
Теперь можно установить OpenVPN, запустив традиционную команду make install. Если вы используете ОС Solaris или Mac OS X, то вам также необходимо установить TUN/TAP-драйвер. Остальные Unix-подобные ОС уже имеют его, а в Windows он будет добавлен программой установки. Исходный программный код драйвера для ОС Solaris можно получить со страницы проекта SourceForge (http:// vtun.sourceforge.net/tun/). Драйвер для Mac OS X имеется на http://chrisp.de/en/ projects/tunnel.html как в форме исходного текста, так и в виде исполняемого файла. После того как LZO, OpenSSL, TUN/TAP-драйвер и OpenVPN установлены, можно все проверить, настроив из командной строки элементарную VPN. На машине А (в этом примере — kryten) запустите команду
openvpn --remote zul --dev tunO --ifconfig 10.0.0.19 10.0.0.5
Команда, которую надо запустить на машине В (zul), очень похожа на предыдущую команду, за исключением перестановки аргументов в ключе -ifconfig:
openvpn --remote kryten --ifconfig 10.0.0.5 10.0.0.19
Первый IP-адрес — это локальная сторона канала, а второй — удаленная; вот почему необходимо поменять местами IP-адреса. После запуска этих команд появится предупреждение об использовании шифрования, а также несколько сообщений о состоянии. После запуска OpenVPN для просмотра настроенного канального устройства запустите ifconfig:
[andrew@kryten andrew]$ /sbin/ifconfig tunO tunO: flags=51<UP.P0INT0P0INT.RUNNING> mtu 1300
inet 10.0.0.19 --> 10.0.0.5 netmask Oxffffffff
Теперь попробуйте «прозвонить» удаленную машину по канальному IP-адресу: [andrew@kryten andrew]$ ping -с 4 10.0.0.5
PING 10.0.0.5 (10.0.0.5): 56 data bytes
64 bytes from 10.0.0.5: icmp_seq=0 ttl=255 time=0.864 ms
64 bytes from 10.0.0.5: icmp_seq=l ttl-255 time=1.012 ms
64 bytes from 10.0.0.5: 1cmp_seq=2 ttl=255 time=0.776 ms
64 bytes from 10.0.0.5: icmp_seq=3 tt1=255 time=0.825 ms
--- 10.0.0.5 ping statistics ---
4 packets transmitted. 4 packets received. Ofc packet loss round-trip min/avg/max = 0.776/0.869/1.012 ms
После того как мы убедились в правильной работе OpenVPN, нужно создать конфигурацию, которая более полезна в реальной жизни. Сначала необходимо создать SSL-сертификаты (см. трюк № 45) для каждой стороны соединения. После
этого необходимо создать настроечные файлы, а также сценарии настройки и демонтирования соединений для каждой стороны соединения.
Сначала рассмотрим настроечные файлы. В этих примерах узел zul будет шлюзом в частной сети, a kryten — внешним клиентом.
Настроечный файл для zul, который используется для связи с kryten, —/etc/ openvpn/openvpn.conf. Вот его содержание:
dev tunO
ifconfig 10.0.0.5 10.0.0.19
up /etc/openvpn/openvpn.up
down /etc/openvpn/openvpn.down tls-server
dh /etc/openvpn/dhl024.pem
ca /etc/ssl/ca.crt cert /etc/ssl/zul.crt key /etc/ssl/private/zul .key ping 15 verb 0
Параметры dev и ifconfig используются так же, как и в командной строке. Параметры up и down указывают сценарии, которые будут выполняться при установлении и прекращении VPN-соединения. Параметр tsi -server включает TLS-режим и указывает, что данная сторона соединения в ходе процесса ТЬ5-«рукопожа- тия» используется как сервер. Ключ dh указывает Diffie-Hellman-параметры, используемые при обмене ключами. Они зашифрованы в .РЕМ-файле и генерируются с помощью следующей команды:
# openssl dhparam -out dh!024.pem 1024
Последующие параметры касаются SSL-сертификатов. Параметр са указывает открытый сертификат Certificate Authority, a cert — открытый сертификат для использования на этой стороне соединения. Примерно так же параметр key указывает открытый ключ, соответствующий открытому сертификату. Для гарантии того, что VPN-канал не будет сброшен одним из промежуточных межсетевых экранов, осуществляющих фильтрацию с проверкой состояния, используется параметр ping. Его наличие приводит к тому, что OpenVPN выполняет «прозвонку» удаленного узла каждые п секунд для того, чтобы не истек тайм-аут для элементов канала в таблице состояния межсетевого экрана.
На узле kryten используется следующий файл настройки:
dev tunO remote zul ifconfig 10.0.0.19 10.0.0.5 up /etc/openvpn/openvpn.up down /etc/openvpn/openvpn.down tls-client ca /etc/ssl/ca.crt cert /etc/ssl/kryten.crt key /etc/ssl/private/kryten.key ping 15 verb 0
Главная особенность этого файла заключается в том, что в нем используются параметры 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-адресом
необходимо иметь дело, приходится явно указывать IP-адрес или имя узла, удаляемого из ARP-таблицы.
Сейчас надо лишь позаботиться о межсетевом экране. Необходимо разрешить трафик, поступающий с устройства tunO, а также с 5000-го UDP-порта.
Теперь вы готовы запустить openvpn на обеих сторонах с помощью следующей команды:
openvpn --config /etc/openvpn/openvpn.conf --daemon
Настройка OpenVPN под Windows еще проще. Просто запустите программу установки, и все, что необходимо, будет настроено автоматически. Будут установлены OpenSSL, ТШЧДАР-драйвер и сама OpenVPN. Расширение .ovpn будет связано с OpenVPN. Просто поместите настроечную информацию в файл .ovpn, дважды щелкните на нем и можете приступать к работе. Все дополнительные параметры представлены на web-сайте OpenVPN.
ТРЮК№ 81ТРЮК№ 81Канал РРР
ТРЮК№ 81
ТРЮК№ 81
Для создания безопасной 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» — протокол передачи от точки к точке.
ipparam 10.1.1.20:10.1.1.1 root@colossus's password: local IP address 10.1.1.20 remote IP address 10.1.1.1
Первая строка команды запускает pppd-процесс на локальной машине и заставляет его перейти в фоновый режим после установки соединения (updetach). Здесь же содержится указание не выполнять идентификацию (noauth) — SSH-де- мон уже выполняет надежную проверку. Команда pppd также отключает понижение компрессии (nodeflate). Вторая строка запускает программу и устанавливает связь с ней через стандартный ввод и вывод. Это используется для регистрации на удаленной машине и запуска там pppd. Наконец, в последней строке указываются локальный и удаленный IP-адреса, используемые в РРР-соеди- нении. После выполнения этой команды с помощью ifconfig можно увидеть РРР-интерфейс:
$ /sbin/ifconfig рррО
pppO Link encap:Point-to-Point Protocol
inet addr:10.1.1.20 P-t-P:10.1.1.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:58 errors:0 dropped:0 overruns:0 frame:0
TX packets:50 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3
RX bytes:5372 (5.2 Kb) TX bytes:6131 (5.9 Kb)
Теперь попробуйте «прозвонить» IP-адрес удаленной стороны:
$ ping 10.1.1.1
PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data.
64
bytes from 10.1.1.1: icmp_seq=l ttl=64
time=4.56 ms
64
bytes from 10.1.1.1: 1cmp_seq=2 ttl=64
time=4.53 ms
64
bytes from 10.1.1.1: icmp_seq=3 ttl=64
time=5.45 ms
64
bytes from 10.1.1.1: icmp_seq=4 ttl=64
time=4.51 ms
--- 10.1.1.1 ping statistics ---
4 packets transmitted. 4 received. OX packet loss, time 3025ms rtt min/avg/max/mdev = 4.511/4.765/5.451/0.399 ms
И наконец, завершающий тест — реальное использование канала:
$ ssh 10.1.1.1
The authenticity of host '10.1.1.1 (10.1.1.1)' can't be established.
RSA key fingerprint is 56:36:db:7a:02:8b:05:b2:4d:d4:dl:24:e9:4f:35:49.
Are you sure you want to continue connecting (yes/по)? yes
Warning: Permanently added '10.1.1.1' (RSA) to the list of known hosts.
andrew@10.1.1.rs password:
[andrew@colossus andrew]$
Перед тем как воспользоваться такой настройкой, если есть желание, можно сгенерировать ключи регистрации для использования с SSH (трюк № 73), что избавит от необходимости каждый раз вводить пароль. Кроме того, можно создать
отдельного пользователя для регистрации на удаленной машине и запуска 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). Несколько последних трюков покажут, как наблюдать за незваным гостем, одураченным и пойманным ею.
ТРЮК№ 82ТРЮК№ 82ОбнаружениевторженияспомощьюSnort
ТРЮК
№ 82
ТРЮК
№ 82
Используйте самую мощную (и бесплатную) NIDS.
Просмотр протоколов может далеко увести вас от обнаружения вторжения. А если протоколы сгенерированы скомпрометированной службой, то добро пожаловать в самый ужасный кошмар системного администратора: протоколам верить нельзя.
Вот где требуется 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
Log directory = /var/log/snort
Initializing Network Interface ethO
--== Initializing Snort —-- Initializing Output Plugins!
Decoding Ethernet on interface ethO
--== Initialization Complete —--
-*> Snort! <*-
Version 2.0.5 (Build 98)
By Martin Roesch (roesch@sourcefire.com. www.snort.org)
12/14-16:25:17.874711 0:A:95:C7:2B:10 -> O:C:29:E2:2B:C1 type:0x800 len:0x42
192.168.0.60:53179 -> 192.168.0.41:22 TCP TTL:64 T0S:0xl0 ID:56177 IpLen:20 DgmLen:52 DF
***A**** Seq: 0x67E53951 Ack: 0x2BA09FF7 Win: OxFFFF TcpLen: 32
TCP Options (3) => NOP NOP TS: 3426501948 469087
12/14-16:25:17.874828 O:C:29:E2:2B:C1 -> 0:A:95:C7:2B:10 type:0x800 len:0x252 192.168.0.41:22 -> 192.168.0.60:53179 TCP TTL:64 T0S:0xl0 ID:50923 IpLen:20 DgmLen:580 DF
***AP*** Seq: 0x2BA09FF7 Ack: 0x67E53951 Win: 0x2200 TcpLen: 32
TCP Options (3) -> NOP NOP TS: 469100 3426501948 =+=+=+=+=-b=+=4-=4-=-b=+=+=+=4-=+=+=+=+=+=+=+=+=4-=+=+=+=+=+=+=+=+=+=+=4-=+=+=+=+
В исходном дистрибутиве Snort в каталоге etc/ имеется несколько конфигурационных (настроечных) файлов, но при выполнении make install они не устанавливаются. Для их размещения необходимо создать подкаталог в /etc или /usr/local/etc и скопировать соответствующие файлы подобной командой:
# mkdir /usr/Тocal/etc/snort &&\ ср etc/[AMakefile]* /usr/local/etc/snort
Вероятно, туда же вам захочется скопировать и каталог rules.
Теперь необходимо отредактировать файл snort.conf. Пример этого файла содержит список переменных. Некоторые из них имеют значения по умолчанию, и у каждой переменной имеется комментарий, поясняющий ее назначение. Вот, в частности, две переменные:
var HOMEJET any
van EXTERNAL JET any
HOMEJET1 xxx.xxx.xxx.xxx/yy specifies which IP address spaces should be considered local. The default is set so that any IP address is included as part of the home network. Networks can be specified using CIDR notation (i.e.. xxx.xxx.xxx.xxx/yy). You can also specify multiple subnets and IP addresses by enclosing them in brackets and separating them with commas: var HOMEJET [10.1.1.0/24.192.168.1.0/24]
HOME_NET can also be automatically set to the network address of a particular interface by setting the variable to $ethO_AODRESS. 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.
Трюк № 82. Обнаружение вторжения с помощью Snort237
HOMENET 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 EXTERNALNET variable allows you to explicitly specify IP addresses and networks that are not a part of HOMENET. Unless a subset of HOMENET 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-трафика с целью
обнаружения сканирования портов. В большинстве случаев достаточно настройки по умолчанию. Однако если необходимо изменить любую из настроек,
то все параметры препроцессоров можно найти в описании конфигурацион-
ного файла.
Если при компиляции У была задана поддержка баз данных, то необходимо разре- nost= . r .. .
шить работу надстройки вывода в БД (database output), позволяющей Snort со-
output database: alert mysqi. user=snort■ passwdrd-snorlpa’ss dDname=SNQKT V
хранять любые генерируемые сигналы в БД. Включается она в конфигурацион-
ном файле подобной строкой:
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 совместно с БД, то необходимо создать новую БД и, может быть, новую учетную запись пользователя этой БД. В каталоге
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) вы можете прийти к выводу, что вам сложно справиться с обработкой всех генерируемых
данных. Очень загруженные и привлекающие внимание сайты могут генерировать огромное количество предупреждений, которые зачастую необходимо отбрасывать. Одним из способов облегчения этой работы является установка 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 с помощью переменных, аналогичных переменным, использовавшимся для настройки БД сигналов тревоги:
Jarchive_dbname
Jarchive_host
Jarchive_port
Jarchive_user
Jarchive_password
Для указания местоположения библиотек графики необходимо установить переменную JChartLib path. При использовании JPGraph 1.13 и распаковке ее в тот же каталог, в который распакован дистрибутив ACID, можно ввести
JChartLib_path - ".,/jpgraph-1.13/src“;
Поздравляю! С настройкой покончено. Теперь откройте web-браузер и укажите URL, соответствующий каталогу, в который вы распаковали ACID. Должна появиться страница настройки БД (рис. 7.1).
■I■IООQ’ GoogleQ’ GoogleRendezvous ▼ Apple -Mac Amazon eBay Yahoo! NewsRendezvous ▼ Apple -Mac Amazon eBay Yahoo! News
■I
■I
О
О
Q’ Google
Q’ Google
Rendezvous ▼ Apple -Mac Amazon eBay Yahoo! News
Rendezvous ▼ Apple -Mac Amazon eBay Yahoo! News
«° DB Setup«° DB SetupHomeSearch AG MaintenanceHomeSearch AG Maintenance[Back)[Back)
«° DB Setup
«° DB Setup
Home
Search AG Maintenance
Home
Search AG Maintenance
[Back)
[Back)
Operation |Operation |DescriptionDescriptionStatusStatusACID tablesACID tablesSearchIndexesSearchIndexesAdds tables to extend the Snort DB to support the ACID functionality (Optional) Adds indexes to the Snort DB to optimize the speed of the queriesAdds tables to extend the Snort DB to support the ACID functionality (Optional) Adds indexes to the Snort DB to optimize the speed of the queriesfCrtate ACID AC^DONE.fCrtate ACID AC^DONE.
Operation |
Operation |
Description
Description
Status
Status
ACID tables
ACID tables
Search
Indexes
Search
Indexes
Adds tables to extend the Snort DB to support the ACID functionality (Optional) Adds indexes to the Snort DB to optimize the speed of the queries
Adds tables to extend the Snort DB to support the ACID functionality (Optional) Adds indexes to the Snort DB to optimize the speed of the queries
fCrtate ACID AC^
DONE.
fCrtate ACID AC^
DONE.
[Loaded in 0 seconds]
Roman DanyllwRoman DanyllwAlrCERTAlrCERT
Roman Danyllw
Roman Danyllw
AlrCERT
AlrCERT
Рис.7.1 .СтраницанастройкиACID
Перед использованием ACID необходимо создать несколько таблиц. Щелкните на кнопке Create ACID AG. После этого вы увидите сообщение о создании таблиц. Для таблицы событий лучше создать индексы, если это не было сделано во время настройки. Индексы значительно повышают скорость выполнения запросов в больших таблицах, чуть-чуть увеличивая использование дискового пространства. Щелкните на ссылке Ноте для перехода к основной странице ACID (рис. 7.2).
Интерфейс ACID не требует никаких объяснений. Основная таблица имеет достаточно ссылок, позволяющих просматривать БД в различных представлениях: например, с выводом списка IP-адресов источника и пункта назначения, связанных с сигналом тревоги, а также номера портов.
Рис. 7.2. Основная страница ACIDРис. 7.2. Основная страница ACIDНаблюдение в реальном режиме времени Используйте расширенный GUI Sguil для регулярного наблюдения и анализа IDS-событий.
Рис. 7.2. Основная страница ACID
Рис. 7.2. Основная страница ACID
Решающим моментом анализа 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
и декодирования 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. Он должен располагаться в 1подкаталоге server/sql_scripts каталога, куда был распакован дистрибутив Sguil. Этот файл перенаправляется на вход команды
$ mysql -u root -p SGUIL < create_sguildb.sql
Для работы потребуетсяI несколько) Tcl-пакетов. Первый из них — Tclx (http:// tclx.sourceforge.net)) — содержит расширения библиотек для Tel. Второй — mysqltcl (http://www.xdobry.de/mysqltcl/).). Обаa пакета должныj быть установленыi с помощью стандартной процедуры ./configure && make iinstall. Правильность их установки можно проверить с помощью следующих команд:
$ tcl
tcl>package require Tclx
.3
tcl>package require mysqltcl
.40
tcl>
Если есть желание использовать SSL-шифрование трафика между GUI и сервером, то необходимо также установить пакет tcltls (http://sourceforge.net/projects/tls/). После установки его работа проверяется командой
$ tel
tcl>package require tls
1.41 tcl>
Теперь необходимо перейти к настройке sguild. Для начала необходимо создать каталог, подходящий для размещения конфигурационных файлов (например, /etc/sguild), затем скопировать в него файлы sguild.users, sguild.conf, sguild.queries и autocat.conf, например:
mkdir /etc/sguild
cd server
cp autocat.conf sguild.conf sguild.queries \ sguild.users /etc/sguild
Предполагается, что вы находитесь в каталоге, который создан при распаковке Sguil. Желательно скопировать сценарий sguild в более подходящий каталог, такой как /usr/local/sbin или подобный ему.
Теперь отредактируйте sguild.conf, указав порядок доступа к созданной вамп БД. Если вы использовали представленные ранее команды создания БД и пользователя, то переменным необходимо задать следующие значения:
set DBNAME SGUIL
set DBPASS sguilpass
set DBHOST local host
set DBPORT 3389
set OBUSER sguil
Помимо этого, sguild должен иметь доступ к правилам Snort, используемым на каждом датчике, для того чтобы сопоставлять их местоположение. Место поиска указывается sguild с помощью переменной RULESDIR. Например, для того чтобы sguild искал правила в /etc/snort/rules, введите
set RULESDIR /etc/snort/rules
Поскольку sguild необходимо найти правила для каждого наблюдаемого датчика, фактически необходимо указывать базовый каталог правил. При поиске правил на определенном узле в указанном каталоге будет просматриваться каталог с именем узла (например, правила для узла zul будут находиться в /etc/snort/rules/zul). При желании использовать SSL-шифрование sguild-трафика (что рекомендуется) необходимо создать SSL-ссртифнкат и пару ключей (см. трюк № 45). После этого поместите их в /etc/sguild/certs под именами sguild.key и sguild.pern.
Далее необходимо добавить пользователей, которые смогут обращаться к sguild из GUI Sguil. Для этого выполните:
sguild -adduser andrew
Please enter a passwd for andrew:
Retype passwd:
User 'andrew' added successfully
Теперь можно проверить сервер, подключившись к нему с помощью GUI-клиента. Все, что нужно сделать для этого, — отредактировать файл sguil.conf и изменить переменную SERVERHOST, указав машину, на которой установлен sguild. Кроме того, если хотите использовать SSL, необходимо изменить следующие переменные:
set OPENSSL 1
set TLS_PATH /usr/11b/tlsi.4/1ibtlsl.4. so
Теперь проверьте работу сервера и клиента, запустив sguil.tk. При этом должно открыться окно регистрации (рис. 7.3).
ООО i\ Snort CUI for Lamerz [sguil| - SGUIL-0.3.0•
Snort GUI for Lamerz [sgud]
Copyright (C) 2002 Robert (Bamtn) Visscher <bamo^>satx jrr.com>
This program is distributed under the terms of version 1.0 of theQ Public License See LICENSE OPL (or further details.
This program is distributed in the hope that И wiH be useful.
but WITHOUT ANY WARRANTY; without even the implied warranty ofMERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Please Legin
Username: :
Password: .
OkExit
Рис. 7.3. Диалоговое окно регистрации Sguil
Введите сведения, указанные при создании пользователя, и щелкните на ОК. После этого откроется окно, представленное на рис. 7.4.
Рис. 7.4. Диалоговое окно без датчиков
Поскольку датчиков наблюдения еще нет, щелкните на кнопке Exit (Выход). Необходимые обновления можно найти в подкаталоге sensor/snort_mods/2_0/ дистрибутива Sguil. Теперь перейдите в каталог, содержащий исходный код Snort, перейдите в подкаталог src/preprocessors и выполните обновление с помощью spp_portscan.c и spp_stream4.c:
$ cd -/snort-2.0.5/src/preprocessors
$ patch spp_portscan.c < \
-/sguil0.3.0/sensor/snort_mods/2_0/spp_portscan_sguil.patch patching file spp_portscan.c
$ patch spp_stream4.c < \
-/sgu11-0.3.0/sensor/snort_mods/2_0/spp_stream4_sgui1.patch
patching file spp_stream4.c
Hunk #9 succeeded at 988 (offset -5 lines).
Hunk #11 succeeded at 3324 (offset -5 lines).
Hunk #13 succeeded at 3674 (offset -5 lines).
После этого откомпилируйте Snort как обычно (см. трюк № 82). Далее включите препроцессоры portscan и stream4 в файл snort.conf:
preprocessor portscan: $HOME_NET 4 3 /var/log/snort/portscans gw-extO preprocessor stream4: detect_scans. disable_evasion_alerts. keepstats db \ /var/log/snort/ssn_logs
Первая строка включает препроцессор portscan и заставляет его запускать сигнал тревоги «сканирование портов», если будет обнаружена попытка одного узла подключиться к четырем различным портам в течение трехсекундного интервала. Свой протокол препроцессор сканирования портов хранит в /var/log/snort/portscans. Последнее поле в строке — наименование датчика. Вторая строка активизирует препроцессор stream4, включая в нем обнаружение скрытого сканирования портов, и указывает не генерировать сигнал тревоги при взаимном наложении ТСР-дей- таграмм. Здесь также указывается место хранения протокола этого препроцессора.
Кроме того, в Snort необходимо настроить единый (унифицированный) выходной формат, поскольку для обработки протоколов сигналов тревоги и протоколов событий необходимо использовать Barnyard:
output alert_unified: filename snort.alert, limit 128
output log_unified: filnemae snort.log. limit 128
Далее создайте элемент в 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. В ней можно указать, от имени
каких пользователей или групп будет запускаться 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_sguil1 .с и op_sguil1 .h в переменную 1 ibop_a_SOURCESI и 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 install. Для настройки Barnyard на использование надстройки 1вывода 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
Переменные 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/11ibt 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.
ТРЮК№ 85ТРЮК№ 85Управление датчиками
ТРЮК
№ 85
ТРЮК
№ 85
Используйте web-интерфейс SnortCenter для управления датчиками NIDS.
Управление IDS-датчиками и отслеживание всех генерируемых ими сигналов тревоги может стать обременительной задачей, а при наличии нескольких датчиков — вообще трудно выполнимой. Одним из способов объединить все задачи управления IDS в одном приложении является SnortCenter (http://users.pandora.be/larc/) — система управления для Snort.
SnortCenter состоит из консоли, основанной на web-интерфейсе, и агентов датчиков, запускаемых на каждой машине, входящей в инфраструктуру NIDS. Это позволяет объединить все задачи наблюдения и управления в одной программе,
которая помогает быстрее выполнять работу. 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
портом по умолчанию. В качестве значения переменной $hidden_key_num укажите случайный номер.
После редактирования config.php необходимо создать БД и установить для нее указанные ранее регистрационные имя и пароль:
$ mysql -u root -р mysql
Enter password:
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Welcome to the MySQL monitor. Commands end with : or \g.
Your MySQL connection id is 27 to server version: 3.23.55
Type 'help;' or ‘\h* for help. Type *\c" to clear the buffer.
mysql> create database SNORTCENTER:
Query OK. 1 row affected (0.01 sec)
mysql> GRANT SELECT.INSERT.UPDATE.DELETE ON SNORTCENTER.* TO \ snortcenter@loca1 host IDENTIFIED BY 1 snortcenterpass‘:
Query OK. 0 rows affected (0.00 sec)
mysql> FLUSH PRIVILEGES:
Query OK. 0 rows affected (0.02 sec)
mysql> Bye
Now create the database tables:
$ mysql -u root -p SNORTCENTER < snortcenter_db.mysql
Поздравляем! Пора испытать SnortCenter! Для этого введите URL, соответствующий месту установки в корневом каталоге документов (например, http:// example.com/snortcenter/) (рис. 7.5).
Рис. 7.5. Страница регистрации SnortCenter
Введите имя и пароль по умолчанию и щелкните на кнопке Login. После чего откроется страница, представленная на рис. 7.6.
Рис. 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
Рис. 7.8. Изменение пароля и адреса электронной почты администратора
После этого необходимо создать для датчика SSL-сертификат
cd /usr/local/snortcenter # mkdir conf
openssl req -new -x509 -days 3650 -nodes \
-out conf/sensor.pem -keyout conf/sensor.pem
либо сразу создать подписанный сертификат (см. трюк № 45).
Запустите сценарий настройки агента датчика:
sh setup.sh
****************************************************************************
* Welcome to the SnortCenter Sensor Agent setup script, version 1.0 RC1 * ****************************************************************************
Installing Sensor in /usr/local/snortcenter .
****************************************************************************
The Sensor Agent uses separate directories for configuration files and log files. Unless you want to place them in a other directory, you can just accept the defaults.
Config file directory [/usr/local/snortcenter/conf]:
The Sensor Agent uses separate directories for configuration files and log files.
Unless you want to place them in a other directory, you can just accept the
defaults.
Config file directory [/usr/local/snortcenter/conf]:
Этот сценарий уточнит у вас некоторую информацию: каталог конфигурационного файла агента и каталог протокола, полный путь к библиотеке Perl (например, /usr/bin/perl), а также расположение двоичных файлов и правил Snort. Кроме того, будут уточнены операционная система, порт и IP-адрес, который должен «прослушивать» агент (по умолчанию 2525-й TCP-порт), а также IP-адреса, по которым можно подключаться к агенту. После получения всей информации сценарий запустит агента на указанном в конфигурационном файле порте. Теперь можно проверить работу агента, обратившись к нему с помощью
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).
Теперь можно настроить датчик с помощью меню Sensor Config и Resources. После того как создана удовлетворяющая вас конфигурация, она может «проталкиваться» необходимым датчикам с помощью пункта Push.
Рис. 7.11 . Список датчиков SnortCenter после запуска датчикаРис. 7.11 . Список датчиков SnortCenter после запуска датчика
Рис. 7.11 . Список датчиков SnortCenter после запуска датчика
Рис. 7.11 . Список датчиков SnortCenter после запуска датчика
Создание собственных правил Snort
Настройте Snort под ваши требования с помощью процессора правил
Одной из ярких особенностей Snort является собственный процессор правил. Процессор правил имеет расширенный язык, позволяющий писать собственные правила, учитывающие особенности конкретной сети.
Правило Snort можно разделить на две части: заголовок и параметры. Заголовок содержит выполняемое действие, протокол, к которому применяется правило, а также адреса и порты исходного пункта и пункта назначения. Параметры правила позволяют создавать связанное с правилом пояснительное сообщение, а также проверять различные атрибуты пакетов с использованием довольно большой библиотеки надстроек Snort. Вот общая форма правила:
action proto src_ip src_port direction dst_ip dst_port (options)
При поступлении пакета его IP-адреса и порты отправителя и получателя сравниваются со значениями, указанными в правилах. Если они совпадают, то с пакетом сравниваются параметры. Если в результате этих сравнений обнаруживается совпадение, то предпринимается указанное действие.
Snort предлагает несколько встроенных действий, которые можно использовать в правилах. Для упрощения протоколирования совпадающих пакетов используется действие log. Действие alert, помимо протоколирования пакета, генерирует сигнал тревоги указанным в конфигурационном файле или в командной строке способом. Очень приятная возможность Snort заключается в том, что можно иметь
довольно общие правила, а затем создать из них исключение, написав еще одно правило, использующее действие 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. mysqi. user-snort dbname-snort host-localhost
output database: log, mysql. user=snort dbname=snort host=localhost
Это действие указывает, что приложение Snort должно вести себя так же, как при выполнении действия alert, но что сигнал тревоги должен быть послан демону syslog, а пакеты должны протоколироваться в базу данных. При определении действия можно использовать любую из надстроек вывода Snort так же, как при настройке их в качестве основного варианта вывода.
Механизм обнаружения Snort поддерживает несколько протоколов. Поле proto используется для указания протокола, к которому относится ваше правило. Допустимыми значениями являются i p, i cmp, tcp и udp.
Следующее поле в правиле используется для указания 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 в качестве значений можно было использовать операторы -> и <-. Однако оператор <- был заменен, поскольку, если поменять местами пары IP-адрес/порт, он становится равнозначен другому. Помимо знака -> имеется еще один. Значение <> указывает, что правило применяется в обоих направлениях. Это особенно полезно, когда используются log- или dynamic-правила, поскольку протоколируются обе стороны ТСР-потока.
Следующая часть правила состоит из параметров. Она позволяет указывать множество атрибутов, в отношении которых будет выполняться проверка. Каждый параметр реализуется надстройкой Snort. Когда срабатывает правило, определяющее параметр, для проверки пакета Snort запустит соответствующую этому параметру надстройку. Snort имеет более 40 надстроек — слишком много, чтобы рассматривать их подробно. Далее мы рассмотрим наиболее полезные из них. Самым мощным параметром является msg. Он позволяет указывать сообщения, которые будут протоколироваться в виде сигнала тревоги при обнаружении пакета, совпадающего с правилом. Без него многие сигналы тревоги не будут иметь смысла. Параметр в качестве аргумента имеет строчное значение, заключенное в кавычки. Например, следующее выражение определяет сообщение, генерируемое при обнаружении какого-либо трафика, исходящего с адреса 192.168.1.35:
alert tcp 192.168.1.35 any -> any any (msg:"Traffic from 192.168.1.35":)
В строчном значении должны отсутствовать любые кавычки. Синтаксический анализатор в 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";)
Действительными значениями флагов являются S для SYN, F для FIN, R для RST, P для PSH, А для АСК и U для URG. Кроме того, Snort позволяет проверять состояние двух зарезервированных разрядов-флагов, указанных значением 1 или 2. Указав значение 0, можно установить соответствие пакету, вообще не содержащему флагов. Помимо этого, параметр fI ags воспринимает несколько операторов. Перед указываемыми значениями можно добавлять +, * или ! для соответствия одним флагам плюс другим, любым флагам и всем, кроме указанных, соответственно.
Прекрасно, что в Snort имеется множество надстроек, которые могут использоваться в правилах в параметре options. Упомянутые здесь параметры являются лишь «затравкой» для изучения всех остальных. Если вам необходимо определить более сложные правила, обратитесь к полной документации Snort, в которой параметры подробно описываются и приводятся примеры их использования. Документацию для Snort можно найти на http://www.snort.org/docs/writing_rules/.
ТРЮК№87ТРЮК№87Предотвращение и сдерживание вторжений с помощью Snortjnline
ТРЮК
№87
ТРЮК
№87
Для предотвращения вторжений или для их остановки в случае обнаружения установите на межсетевой экран 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/ipv4/netf i1 ter/. i p__queue.о. f1 ags /lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ip_queue.o
В данном случае последняя строка свидетельствует о наличии модуля. Если модуля нет, необходимо проверить, существует ли файл /proc/net/ip_queue. Если найти модуль не удается, а файл существует, то поддержка IP-очереди скомпилирована в ядро статически. Если и файла нет, то необходимо включить его в ядро и перекомпилировать.
Помимо поддержки 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 .■1-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 4test -f 'spo_alert_fast.c' || echo \/"spo_alert_fast.c
In file included from I/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
Это вызвано тем, что /usr/include/linux/netfilter_ipv4/ip_queue.h включает (including) /usr/include/linux/lf.h, а не /usr/include/net/if.h (я сам столкнулся с этим). Для того чтобы обойти эту проблему, просто исправьте ip_queue.h и измените строчку в начале файла
#include <linux/if.h>
на
#include <net/if.h>
Для продолжения компиляции с того места, где мы остановились, просто введите 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 -F
iptables -A INPUT -j QUEUE
iptables -A OUTPUT -j QUEUE
iptables -A FORWARD -j QUEUE
Это приведет к «проталкиванию» всего приходящего, отправляемого или проходящего трафика в IP-очередь, из которой Snortjnline будет считывать пакеты. Теперь можно запустить Snortjnline (только не забудьте указать ключ -Q):
snort inline -Qvc /etc/snort/snort inline.conf
Если вы выполняете удаленное администрирование машины, то захотите запускать 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
Далее запустите 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
Трюк № 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 воспринимает
является именем файла, куда будет записываться протокол. Указанный файл будет создан в /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 будет посылать запросы на блокировку, разделяя их пробелами. Любые правила, с помощью которых будет запускаться правило
межсетевого экрана, должны использовать параметр 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 Engine) — это видоизмененная версия Snort, функциональность которой расширена в область обнаружения вторжения на основе аномального поведения трафика. Препроцессор Spade использует Snort для наблюдения за сетью и в дальнейшем строит вероятностные таблицы, основываясь на отмеченном трафике. После этого таблица используется для генерации для каждого пакета оценочного значения отклонения в диапазоне от 0 до 1 (где 0 — совершенно нормально, 1 — абсолютно ненормально).
Установка Spade очень проста. Просто загрузите дистрибутив из Сети, распакуйте его и перейдите в созданный при этом каталог. После этого выполните обновление программного кода Snort с помощью команды
$ make SNORTBASE=../snort-2.0.5
Разумеется, если дерево каталогов исходного кода 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 и содержать описание отклонения пакета от нормы и значение этого отклонения.
Автоматическое обновление правил Snort
Используйте Oinkmaster для поддержания актуальности правил Snort.
Если имеется лишь небольшое количество IDS-датчиков, то поддержание правил Snort «свежими» является довольно простой задачей. Однако по мере увеличения количества датчиков все усложняется. К счастью, с помощью Oinkmaster (http://oinkmaster.sourceforge.net/news.shtml) имеется возможность автоматически обновлять правила.
Oinkmaster — это Perl-сценарий, который умеет не только загружать из Сети новые правила Snort, но и модифицировать их в соответствии с указанными правилами либо выборочно удалять. Это полезно при более точной подстройке стандартных
правил под среду либо при отключении правил, вызывающих слишком много ложных срабатываний.
Для установки 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
Теперь нет необходимости запоминать, какие правила были отключены.
ТРЮК№ 31ТРЮК№ 31Создайте сеть распределенных датчиков-невидимок
ТРЮК
№ 31
ТРЮК
№ 31
Спрячьте IDS-датчики от атак, сохранив возможность обращаться к их данным.
IDS-датчики являются частью системы раннего обнаружения, которая может как сообщать об атаке, так и предоставлять улики для расследования произошедшего прорыва. Вы должны отдельно позаботиться о защите этих датчиков
и собранных ими данных. Одним из способов сделать это является перевод их в режим «невидимок».
Для этого просто не настраивайте IP-адрес сетевого интерфейса, с которого IDS будет собирать данные. Это можно сделать выбором интерфейса без указания IP-адреса:
tcpdump -i ethl
tcpdump: bind: Network is down
ifconfig ethl up promise
ifconfig ethl
ethlLink 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-датчиками, чтобы трафик остался изолированным. Эту сеть можно подключить к удаленно доступной сети и использовать «строгий» межсетевой экран.
Еще один способ обращения к системному блоку заключается в использовании альтернативного канала, такого как последовательный порт, подключенный к другой машине, имеющей сетевое подключение. Просто запустите консоль на этом последовательном порте и обеспечьте надежную защиту второй машины. Можно также подключиться по модему к специальной телефонной линии либо, что еще лучше, к незарегистрированному расширению офисной РВХ (Private Branch eXchange). В зависимости от ситуации использование консоли для удаленного доступа является простейшим и наиболее безопасным методом.
Какой бы метод вы ни избрали для удаленного доступа, решение должно учитывать повышение защиты и неудобство доступа к машине. Защита практически всегда связана с противоречием между удобством и доверием.
ТРЮК№92ТРЮК№92Использование Snort в высокопроизводительной среде с Barnyard
ТРЮК
№92
ТРЮК
№92
Разъедините выход 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):
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: LOGAUTH LOGALERT
А если протоколирование осуществляется на удаленном сервере, то добавьте
output alert_syslog: hostname=loghost, LOGAUTH LOGALERT
Из данных унифицированного протокола 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-сервер и динамическое содержание от проникновения.
Обнаружение вторжений, основанных на использовании распространенных протоколов и служб, — это задача, для которой удачно подходят системы обнаружения
вторжения. Однако из-за усложнения 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 1 ty
-enable-module=security
Теперь, когда mod_security установлен, его необходимо включить. Для этого поместите в файл httpd.conf следующие строки:
<IfModule mod_security.c>
SecFiiterEngine On
</IfModule>
Это приведет к включению функции нормализации запросов для всех запросов, поступающих на данный web-сервер. Можно также включить этот модуль только для динамического содержания, установив в переменной SecFilterEngine значение DynamicOnly. После того как модуль mod_security будет включен, он начнет перехватывать все запросы, поступающие на web-сервер, и выполнять несколько проверок перед передачей через определенные пользователем фильт-
ры, после чего запросы будут либо обслужены, либо отвергнуты. В ходе этих проверок mod_security преобразует несколько типов «хитрых» последовательностей символов в более распространенную форму. Так, последовательности // и /./ будут преобразованы в /, а для Windows символ \ будет преобразован в /. Кроме того, будут декодированы символы URL-шифрования. Помимо этих проверок, mod_security также будет настроен на сканирование «полезной нагрузки» POST-запросов и проверку достоверности URL- и Unicode-кодировки, содержащихся в запросах.
Для включения этих функций добавьте в httpd.conf строки:
SecFiIterScanPOST On
SecFi1terCheckURLEncodi ngOn
SecFiHerCheckUnicodeEncodingOn
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-сервере. Представленное правило как раз и предотвращает обработку подобных запросов.
Так называемые атаки кросс-сайтовых сценариев (Cross-site scripting, XSS) осуществляются за счет вставки в существующую страницу такого HTML- или Java- Script-сценария, который выполнится другим пользователем. Атаки могут использоваться для прочтения cookie сеанса пользователя, что позволяет получить полный доступ к сведениям о пользователе. Такие атаки могут предотвращаться за счет фильтрации mod_security запросов, содержащих JavaScript. Для запрета JavaScript в запросах используйте следующее правило:
SecFilter "<[[:space:)]*script"
Кроме того, можно отключить и HTML:
SecFilter "<(.|\n)+>"
Атаки SQL-инжекции подобны XSS-атакам, но атакующий изменяет переменную, используемую для SQL-запроса, таким образом, что получает возможность изменить произвольную SQL-команду. Для защиты от этого типа атак можно использовать следующее правило:
SecFilter "delete[[:space:]]+from"
SecFi1 ter " insert[[:space:]]+into"
SecFilter "select.+from"
Это правило предотвращает SQL-инжекцию в cookie с именем sessionid:
SecFilterSelective COOKIE_sessionid "!A(|[0-9]{1.9})$"
Если существует cookie с именем sessionid, запрос может быть выполнен только в том случае, если cookie содержит одну из девяти цифр (от 1 до 9).
Представленное далее правило требует наличия HTTP_USER_AGENT- и НТТР_ HOST-заголовков в каждом запросе:
SecFilterSelective "HTTP_USER_AGENT|HTTP_HOST" "А$"
Можно выполнять поиск множества переменных, разделяя их в списке символом |. Зачастую атакующий проводит «исследование» с использованием простых средств (даже Telnet) и не посылает все заголовки, как это делают браузеры. Такие запросы будут отклоняться, протоколироваться и отслеживаться.
Вот правило, отклоняющее отгрузку (отправку) файла:
SecFilterSelective "HTTP_CONTENT_TYPE" multipart/form-data
Это простая, но эффективная защита, отклоняющая запросы. Она основана на типе содержания, используемом в запросе на выгрузку (upload).
Следующее правило протоколирует запросы, не имеющие Accept-заголовка:
SecFilterSelective "НТТР_АССЕРТ" "А$" log.pass
«Ручные» запросы часто не содержат также HTTP-заголовков. Заголовок Keep- Alive является следующим хорошим кандидатом на проверку. Обратите внимание на то, что, помимо переменной и строки поиска, это правило содержит ключевые
слова 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 можно помещать в тег <Location>, что позволяет указывать индивидуальную конфигурацию для определенных сценариев или структуры каталогов.
Модуль 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.
ТРЮК№94ТРЮК№94Имитация сети с уязвимыми узлами
ТРЮК№94
ТРЮК№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 install. Установив эти библиотеки, аналогично установите и 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
add windows-web tcp port 5900 "sh scripts/win2k/vnc.sh"
add windows-web udp port 137 open
add windows-web udp port 135 open
create windows-xchng
set windows-xchng personality "MS Windows2000 Professional RC1/W2K Advance Server Beta3”
set windows-xchng default tcp action reset
set windows-xchng default udp action reset
add windows-xchng tcp port 25 "sh scripts/win2k/exchange-smtp.sh"
add windows-xchng tcp port 110 "sh scripts/win2k/exchange-pop3.sh"
add windows-xchng tcp port 119 "sh scripts/win2k/exchange-nntp.sh"
add windows-xchng tcp port 143 "sh scripts/win2k/exchange-imap.sh"
add windows-xchng tcp port 5900 "sh scripts/win2k/vnc.sh"
add windows-xchng tcp port 139 open
add windows-xchng tcp port 137 open
add windows-xchng udp port 137 open
add windows-xchng udp port 135 open
## Linux 2.4.x computer
create linux
set linux personality "Linux 2.4.7 (Х86)"
set linux default tcp action reset
set linux default udp action reset
add linux tcp port 110 "sh scripts/pop3.sh"
add linux tcp port 25 "sh scripts/smtp.sh"
add linux tcp port 21 "sh scripts/ftp.sh"
And then bind them to the IP addresses that you want to use:
bind 192.168.0.10 windows-web
bind 192.168.0.11 windows-xchng
bind 192.168.0.12 linux
Сохраните этот конфигурационный файл в надлежащем месте (например, в /usr/ local/share/honeyd/honeyd.conf). После этого запустите honeyd и arpd:
arpd 192.168.0.10-192.168.0.12
cd /usr/local/share/honeyd
honeyd -p nmap.prints -x xprobe2.conf -a nmap.assoc \
0 pf.os -f honeyd.conf
honeyd[5861): started with -p nmap.prints -x xprobe2.conf -a nmap.assoc -0 pf.os
f honeyd.conf
honeyd[5861]: listening on ethO: (arp or ip proto 47 or (ip )) and not ether src 00:0c:29:e2:2b:d
Honeyd starting as background process
Теперь попробуйте с помощью Nmap определить IP-адреса, обрабатываемые honeyd:
nmap -sS -sU -0 192.168.0.10-12
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Interesting ports on (192.168.0.10):
(The 3063 ports scanned but not shown below are in state:
closed)
PortStateService
80/tcpopenhttp
135/udpopenloc-srv
137/tcpopennetbios-ns
137/udpopennetbios-ns
139/tcpopennetbios-ssn
5900/tcpopenvnc
Remote operating system guess: MS Windows2000 Professional
Serve? Beta3
Uptime 2.698 days (since Sun Jan 11 03:52:35 2004)
RC1/W2K Advance
Interesting ports on (192.168.0.11):
(The 3060 ports scanned but not shown below are in state: PortStateService
25/tcpopensmtp
110/tcpopenpop-3
119/tcpopennntp
135/udpopenloc-srv
137/tcpopennetbios-ns
137/udpopennetbios-ns
139/tcpopennetbios-ssn
143/tcpopenimap2
5900/tcpopenvnc
closed)
Remote operating system guess: MS Windows2000 Professional
Server Beta3
Uptime 2.172 days (since Sun Jan 11 16:29:38 2004)
RC1/W2K Advance
Interesting ports on (192.168.0.12):
(The 1598 ports scanned but not shown below are in state: closed)
PortStateService
21/tcpopenftp
25/tcpopensmtp
110/tcpopenpop-3
Remote operating system guess: Linux 2.4.7 (X86)
Конечно же, вы видите, как honeyd обманул Nmap. А что произойдет при попьп • ке обратиться к одной из служб, которая якобы запущена? Попытайтесь подключиться к 25-му порту на ложном почтовом сервере Windows:
$ telnet 192.168.0.11 25
Trying 192.168.0.11...
Connected to 192.168.0.11.
Escape character is **]'.
220 bps-pc9.local.mynet Microsoft ESMTP MAIL Service. Version: 5.0.2195.5329 ready at Mon Jan 12 12:55:04 MST 2004
EHLO kryten
250 - bps-pc9.local.mynet Hello [kryten]
250-TURN
250-ATRN
250-ST7F
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSC0DES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-X-EXPS GSSAPI NTLM LOGIN 250-X-EXPS-LOGIN
250-AUTH GSSAPI NTLM LOGIN
250-AUTH-L0GIN 250-X-LINK2STATE
250-XEXCH50)
250 OK
277277Трюк № 95. Запись деятельности «приманки» 250-ETRN
277
277
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}
250OK
Очень эффективно на первый взгляд, не так ли? Если захотелось бы подклюй, то для пе- шине, необхо- команда будет
перенаправлять SSH-запросы от нашего воображаемого Linux-узла на машину
, важ-
Пн отследить всю ег омимо запуска сце но не только опредПн отследить всю ег омимо запуска сце но не только опредльно.сть .на. это: й машине. Пристально изимитации служб, honeyd может ограничи
Пн отследить всю ег омимо запуска сце но не только опред
Пн отследить всю ег омимо запуска сце но не только опред
и выходную пропускную способность и даже замедлять доступ к определенной компрометации системы, которыми пользовался злоумышленник для получения службе. Этот прием может использоваться для «связывания» ресурсов спамеров доступа. Если вам не интересно, что пытался сделать атакующий, тогда зачем за счет удержания «видимо открытым» постового ретранслятора. Предоставляе- ставить «приманку»?
мые honeyd возможности ограничены только вашей фантазией и временем, кото-
вия — использование средств наблюдения, имеющихся в ядре. При этом можно наблюдать практически все, что делает атакующий, даже если для защиты своих данных или сетевого подключения он использует шифрование. Одним из
средств наблюдения за «приманкой» на уровне ядра является Sebek (http://www. honeynet.org/tools/sebek/).
Sebek — это загружаемый модуль ядра для Linux и Solaris, перехватывающий ключевые системные вызовы в ядре и наблюдающий за интересующей его информацией. После этого он передает данные «слушающему» серверу и скрывает наличие передачи из локальной системы. На самом деле Sebek состоит из двух модулей. Первый, sebek.o, действительно наблюдает. А второй модуль, cleaner.o, служит для обеспечения скрытности работы первого.
Для компоновки модулей на ОС Linux сначала убедитесь в том, что /usr/src/ linux-2.4 содержит исходный код ядра, для которого вы собираетесь скомпилировать модули. Затем либо распакуйте исходный код ядра в этот каталог, либо установите символическую ссылку на существующее дерево исходного кода ядра. После этого загрузите из Сети исходный дистрибутив, распакуйте его и скомпонуйте обычным образом:
$ ./configure
$ make
При этом будет создан tar-архив, содержащий модули ядра и сценарий установщика. Скопируйте этот архив в «приманку», чтобы завершить установку.
Вот что оказалось внутри:
$ttarttf ssebek-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, DESTINATIONIP, SOURCE_PORT и DESTINATION_PORT. Они должны указывать на Sebek-сервер, созданием которого мы займемся чуть позже. DESTINATION_PORT должен быть одинаков для всех «приманок», которые вы собираетесь использовать. Кроме того, переменная MAG I CVAL также должна иметь одинаковое значение для всех «приманок». Эта переменная совместно с DESTINATIONPORT используется для сокрытия трафика от любой «приманки». Если необходимо, чтобы Sebek собирал с «приманки» только информацию о действиях, то установите переменную KEYSTROKEONLY в 1.
Теперь запустите на «приманке» сценарий:
sh sbk_install.sh
Installing Sebek:
sebek.o installed successfully
cleaner.o installed successfully
cleaner.o removed successfully
После того как Sebek установлен, удалите архив и файлы установки. Присутствие этих файлов в системе будет совершенно ясно указывать, что это — «приманка», и может отпугнуть злоумышленников.
Существует два варианта приема данных от 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 в консоли и готовые удалить любые признаки прорыва. Более того, могут быть
установлены сценарии, которые запускаются при выключении системы и удаляют записи протоколов и любые файлы, которые могут использоваться в качестве обвинения. После того как вы обнаружили, что, скорее всего, машина скомпрометирована, вам захочется просто выключить ее (да, просто отключить!) и перезагрузиться с альтернативной среды. Воспользуйтесь загрузочным компактдиском или другим жестким диском, на котором установлена надежная копия операционной системы. При этом нет никакого сомнения, что система запускается с известного состояния, исключающего возможность наличия скрытых процессов, которые могут испортить данные еще до их копирования. Недостатком этой процедуры является очевидное уничтожение любых свидетельств выполнения программ или хранения данных на 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
totaltotal8388608 sectors8388608 sectorsDisk /dev/hda: 4294 MB, 4294967296 bytes 255 heads. 63 sectors/track, 522 cylinders, Units = sectors of 1 * 512 = 512 bytes
total
total
8388608 sectors
8388608 sectors
Device Boot
Start
End
Blocks
Id
System
/dev/hdal
*
63
208844
104391
83
Linux
/dev/hda2
208845
7341704
3566430
83
Linux
/dev/hda3
7341705
8385929
522112+
82
Linux swap
Сохраните эту информацию для последующего использования, например, если позже вы захотите сделать отдельные образы разделов.
ПГРТТРПК тчпятплм гЬямя-п^пяч татпппгп ПЯЯЛРТТЯ*
dd if-hda.img of-hda2.1mg bs-512 skip-208845 count=$[7341704-208845] 7132859+0 records in 7132859+0 records out
Обратите внимание на то, что параметр count выполняет некоторые математические вычисления: размер раздела — это место размещения последнего блока (7341704) минус место размещения первого блока (208845). Убедитесь, что параметр bs соответствует размеру блока, сообщенному программой fdisk (обычно 512, но лучше это проверить). В заключение подсчитаем контрольную сумму для файла-образа, а затем сравним ее с полученным ранее значением:
md5sum hda2.img > /tmp/hda2.img.md5 && diff /tmp/hda2.md5 /tmp/hda2.img.md5
Точное соответствие контрольной суммы образа контрольной сумме действительного раздела свидетельствует о безошибочности копии. Теперь мы можем восстановить исходную машину и просмотреть эту копию на досуге.
ТРЮК№97ТРЮК№97Проверка целостности файлов и поиск скомпрометированных файлов
ТРЮК№97
ТРЮК№97
Tripwire позволит найти скомпрометированные файлы и проверить целостность файлов.
Одним из средств, которое поможет обнаружить вторжение на узел, а также установить, что случилось после этого факта, является Tripwire (http://sourceforge.net/ projects/tripwire).
Tripwire относится к средствам проверки целостности файлов. Программа позволяет обнаружить повреждение файлов системы. Это очень важно, поскольку взломщики, получившие доступ к системе, для заметания следов и сохранения возможности доступа зачастую устанавливают то что называется root kit (набор суперпользователя). Реализуется это за счет изменения ключевых утилит операционной системы, таких как ps, Is, а также других программ, которые могут обеспечить наличие программы-«лазейки». Как правило, в этом случае подразумевается, что эти файлы исправлены таким образом, что при работе не будут сообщать об активности определенного процесса или о присутствии определенных файлов в системе. Взломщики также могут модифицировать системную программу вычисления контрольной суммы MD5 (например, md5 или md5sum), чтобы она всегда выдавала корректные контрольные суммы всех замещенных исполняемых файлов. Поскольку проверка контрольной суммы является основным способом обнаружения изменений файлов, становится понятно, что нужен иной метод проверки.
Здесь на помощь и приходит Tripwire. Эта программа сохраняет «снимки» файлов, находящихся в известном состоянии, и для нахождения различий периодически
сравнивает файлы с их «снимками». С помощью «снимков» 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),
будет создан файл с таким же именем. Теперь перейдите из рабочего каталога в корневой каталог исходного кода Tripwire (то есть в ./tripwire-2.3.1-2) и изучите файлы README и INSTALL Они небольшие, но очень важные.
И наконец, перейдите в каталог src дерева исходного кода (то есть в ./tripwire- 2.3.1-2/src) и в файле src/Makefile выполните все необходимые изменения в определениях переменных. Убедитесь, что с соответствующего определения SYSPRE снят символ комментария (SYSPRE - i686-pc-linux или SYSPRE = sparc-linux и т. п.).
Теперь можно выполнить компиляцию. Поскольку вы еще находитесь в каталоге src, введите следующую команду:
$ make release
После завершения компиляции запустите
$ cd ..
$ ср ./install/install.cfg .
$ ср ./intall/install.sh
Теперь откройте 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. Его невозможно редактировать, поскольку он является зашифрованным двоич-
ным файлом, но для удобства в /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 автоматически отправлял отчет по электронной почте указанным в настройках получателям, добавьте
-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 по расписанию (с помощью планировщика задач). Помимо сохранения БД в безопасном месте, например на компакт-диске, можно создать резервные копии конфигурации, политики и ключей. В противном случае вы не сможете проверить целостность, если кто-либо (случайно или намеренно) удалит их.
СМОТРИ ТАКЖЕ
Поиск скомпПоиск скомпророетированныхетированныхпакетов с помощью RPMпакетов с помощью RPMДополнительную информацию можно найти в документации twpolicy (4) и в разделе «Using Tripwire» книги «Building Secure Servers with Linux», написанной Michael D. Bauer (издательство O'Reilly).
Поиск скомп
Поиск скомп
ро
ро
етированных
етированных
пакетов с помощью RPM
пакетов с помощью RPM
Проверьте установленные файлы операционной системы с помощью RPM-дистрибутива.
Предположим, что установлен факт взлома и необходимо разобраться, какие файлы (или все) были изменены взломщиком, но программа Tripwire не была задействована. Не все потеряно, если в качестве системы управления пакетами используется RPM. Не будучи столь мощным, как Tripwire, RPM может оказаться полезным для определения степени компрометации системы. RPM сохраняет МБ5-подписи для всех когда-либо установленных файлов. Можно использовать эту особенность для сверки пакетов на системе с БД их подписей. Помимо контрольных сумм MD5, также можно сравнить размер файла, пользователя, группу и время модификации со значениями, хранимыми в БД RPM. Для проверки одного пакета выполните
rpm -V пакет
Если взломщик изменил какой-либо из двоичных файлов, то, скорее всего, одним из них будет файл ps. Давайте рассмотрим его подпись:
which ps
/bin/ps
rpm -V >pm -qf /bin/psv
S.5T /bin/ps
Здесь видно, что S, 5 и Т, соответствующие размеру файла, контрольной сумме и времени модификации файла, с момента установки были изменены — это
очень плохо. Обратите внимание на то, что выводиться будет информация только о тех файлах, сведения в которых не соответствуют сведениям в БД пакетов.
Если необходимо проверить все пакеты системы, можно использовать традиционный 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.5T с /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 пакет файл
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 в каталоге, в котором он скомпонован. После этого он будет выводить каждую выполненную проверку и ее результаты:
# ./chrootkit
ROOTDIR 1 is V
Checking
vamd'...
not found
Checking
'basename'...
not infected
Checking
'biff..
. not
found
Checking
vchfn'..
. not
infected
Checking
'chsh1..
. not
infected
Checking
4cron'..
. not
infected
Checking
vdate'..
. not
infected
Checking
vdu'...
not infected
Checking
4dirname'... , I
not infected
Checking
Necho'..
. not
infected
Checking
Negrep'.
.. not infected
Checking
4env'...
not infected
Checking
vfind'..
. not
infected
Checking
4fingerd'...
not found
Checking
Ngpm'...
not
infected
Checking
4grep'..
. not
infected
Checking
vhdparm
'... not infected
Checking
4su'...
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 могут оказаться быстрым и удобным средством проверки целостности системы.
Поиск владельца сети
Отследите контакты сети с помощью БД WHOIS.
Просматривая протоколы IDS, можно заметить много странного трафика, поступающего из другой сети, подключенной через Интернет. При просмотре IP-адреса в DNS он разрешается как, например, dhcp-103.badguydomain.com. С кем связаться, чтобы он помог отследить человека, отправляющего такой трафик? Вероятно, вы уже знаете, что для нахождения контактной информации о владельцах доменных имен Интернета можно использовать команду whois. Если вы еще не пользовались ею, то просто введите whois:
$ 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://whois.godaddy.com
К сожалению, эта запись whois не столь полезна, какой могла бы быть. Обычно здесь перечисляются контактные сведения об администраторах и технических службах, дополненные телефонными номерами и адресами электронной почты. Очевидно, что godaddy.com предоставляет эти сведения только по web-интерфейсу, чтобы избежать спама. Но если в качестве имени лица, зарегистрировавшего домен, указано Dewey Cheatum2, насколько верной является остальная информация о домене? Хотя при регистрации домена необходимо указывать достоверную информацию, могу сказать, по своему опыту, что использование whois помогает отследить лишь честных людей.
Поскольку такой подход вам не помог, что еще можно сделать? Можно снова использовать whois, но для определения регистра номеров блока IP-адресов, в который входит «раздражающий» адрес. Регистры номеров — это элементы, с которыми должен зарегистрироваться владелец большого блока IP-адресов и которые должен разделить в соответствии с географическим местоположением. Основная сложность заключается в отборе для запроса верного регистра, но лучше всех справляется с этим WHOIS-сервер ARIN (American Registry for Internet Numbers) — он сообщит верный регистр, если IP-адрес не найден в его БД.
Учитывая это, давайте попытаемся выполнить запрос о «преступном» 1Р-адресе:
# whois -h whois.arin.net 208.201.239.103
[Querying whois.arin.net]
[whois.arin.net]
Final results obtained from whois.arin.net.
Results:
UUNET Technologies. Inc. UUNET1996B (NET-208-192-0-0-1)
208.192.0.0 - 208.255.255.255
SONIC.NET. INC. UU-208-201-224 (NET-208-201-224-0-1)
208.201.224.0 - 208.201.255.255
# ARIN WHOIS database, last updated 2004-01-18 19:15
# Enter ? for additional hints on searching ARIN’s WHOIS database.
Наш запрос вернет множество результатов, что происходит в тех случаях, когда владелец большого блока IP-адресов делегировал часть блока другой организации. В данном случае UUNET делегировала субблок Sonic.net.
Теперь адресуем запрос обработчику Sonic.net:
# whois -h whois.arin.net NET-208-201-224-0-1
Checking server [whois.arin.net]
Results:
OrgName:SONIC.NET. INC.
OrgID:SNIC
Address: 2260 Apollo Way
City:Santa Rosa
StateProv: CA
Postal Code: 95407
Country:US
Referral Server: rwhoi s://whois.sonic.net: 43
NetRange: 208.201.224.0 - 208.201.255.255
CIDR:208.201.224.0/19
NetName:UU-208-201-224
NetHandle: NET-208-201-224-0-1
Parent:NET-208-192-0-0-1
NetType:Reallocated
Comment:
RegDate:1996-09-12
Updated:2002-08-23
OrgTechHandle: NETW0144-ARIN
OrgTechName: Network Operations
OrgTechPhone: +1-707-522-1000
OrgTechEmail: noc@sonic.net
# ARIN WHOIS database, last updated 2004-01-18 19:15
# Enter ? for additional hints on searching ARIN's WHOIS database.
Здесь мы видим, что теперь имеется контактный телефон и электронный адрес. Скорее всего, это данные провайдера Интернета, которыми воспользовался злоумышленник. Теперь у вас есть контактная информация того, кто должен сказать, кто скрывается под именем 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
SSH-ключи, 206
SSL-сертификат, 123
SSL-шифрование, 213 stack-smashing attack, 41 sticky-разряд, 22 suEXEC-функционалыюсть, 136 j
*
ТСР-дейтаграмма, 93
effective UID, 35
Ethernet-анализаторы, 132
у
VPN-доступ, 199
F FreeS/WAN, 191,203
VTun, 217 w
•
IDS-датчики, 265
web-интерфейс ACID, 239 SnortCcnter, 247
M
МАС-адрес, 83, 105
MySQL, 142
*
автоматизированное создание политики, 52
"•
NIDS, 234
автоматическая генерация файлов, 221
анализ IDS-событий, 241
D '
атака
SQL-инжекции, 272
PacketFilter, 90
РАМ, 54
PID, 32
Р
кросс-сайтовых сценариев, 272
атаки переполнения буфера стека, 41 аудит
включение, 71
настройка политик, 72
root kit, 282
RPM-дистрибутив, 286
аудит сетевого трафика, 183
Б
с
база данных политик безопасности, 191
SFS, 145
Sguil, 241
Snort
препроцессор, 237
Snort_inline, 257
SOCKS 4, 211
SSH, 204
SSH-агент, 208
безопасность
BIND, 140
MySQL, 142
удаленных файловых систем, 145
безопасность web-приложений, 136 библиотека
инжекции пакетов
libnet, 235, 258
библиотечные вызовы, 49
блокировка ядра, 42
п
временные файлы
шимфг рование каталога, 76
вывод списка оперативных ресурсов, 6„9
г
ген^ерирование диаграмм, л1п7г,9
гибкий отклик, 235
Д
делегирование роли администратора, 27
динамическая фильтрация пакетов, 260
'
единый формат вывода, 267
Ж
журналы событий
защита, 73
изменение размеров файлов, 73
3
защита
порта, ,13о/4
протоколов, 2«с5
точек монтирования, 18
электронной почты, 127
И
идентификаторы процессов, 32
искажение ARP-кэша, 83
исследование уязвимости, 20
исходящая фильтрация, 102
•#
коммутатор, 132
концентратор, 132
кроссплатформная VPN, 226
крушение стека, 4м1л
М
межсетевой экран PacketFilter, 90
межсетевой экран Windows, 98
"•
набор суперпользователя, 282, 288
надстройка вывода в БД, 237
накопление статистики, 186 настройка IPsec в Linux, 191 в OpcnBSD, 197
во FreeBSD>194
настройu ка почтового агента, л1О3А0
•
обнаrрj ужение аномального поведения, 263 обновление О. С Windows, _6_3
обновление правил Snort, 264 обобщение протоколов, 159 ограничение доступа, 79 ограниченные оболочки, 58 ограничение системных вызовов, 49 отказ по умолчанию, 105 отключение общих ресурсов, 75
П
«песочница», 35 побайтная копия диска, 280 подкачка 78
подключаемые модули идентификации, 54 поток программы, 41 п1редотвращение вторжении
в we,b-приложен^ия, 269 препроцессоры, (2лг3л 7 «приманка», 234, 277 приоритеты, 151
присоединение к программе, 53 проверка зашифрованной подписи, 29 проверка целостности файлов, 282 программа
Argus, 183
Arpwatch, 84 Barnyard, 267 chkrootkit, 288 Fport JQ f,tester, 1,0л3о grsecunty, 42 Handle, 68 HFNetChk, 64 honeyd, 274 httptunnel, 215 logwatch, 159 Nagios, 172 Nessus, 115
связка ключей,о 3о0псервер ключей, 30сертификат полномочий, 123символическая ссылка, 143система обнаружения сетевоговторжения, 234на основе аномалий, 234на ОСНОве подписи, 234системный вызов, 49*сканер безопасности, 1и15сканирование нескольких систем, 67сканирование удаленных компьютеров, 67скомпрометированные файлы, 282списки управления доступом, 22спуфинг, 83протокола разрешения адресов, 8341стек>страничный файл, 78стJупень, ,12о2оУсвязка ключей,о 3о0псервер ключей, 30сертификат полномочий, 123символическая ссылка, 143система обнаружения сетевоговторжения, 234на основе аномалий, 234на ОСНОве подписи, 234системный вызов, 49*сканер безопасности, 1и15сканирование нескольких систем, 67сканирование удаленных компьютеров, 67скомпрометированные файлы, 282списки управления доступом, 22спуфинг, 83протокола разрешения адресов, 8341стек>страничный файл, 78стJупень, ,12о2оУ,удаленное наблюдение за сетью, 187универсализация файловых имен, 160Учет процессов, 168ф,удаленное наблюдение за сетью, 187универсализация файловых имен, 160Учет процессов, 168фЦцентрализованное протоколирование, 150циклическая БД, 179ЩЦцентрализованное протоколирование, 150циклическая БД, 179Щ
связка ключей,о 3о0п
сервер ключей, 30
сертификат полномочий, 123
символическая ссылка, 143
система обнаружения сетевого
вторжения, 234
на основе аномалий, 234
на ОСНОве подписи, 234
системный вызов, 49*
сканер безопасности, 1и15
сканирование нескольких систем, 67
сканирование удаленных компьютеров, 67
скомпрометированные файлы, 282
списки управления доступом, 22
спуфинг, 83
протокола разрешения адресов, 83
41
стек>
страничный файл, 78
стJупень, ,12о2о
У
связка ключей,о 3о0п
сервер ключей, 30
сертификат полномочий, 123
символическая ссылка, 143
система обнаружения сетевого
вторжения, 234
на основе аномалий, 234
на ОСНОве подписи, 234
системный вызов, 49*
сканер безопасности, 1и15
сканирование нескольких систем, 67
сканирование удаленных компьютеров, 67
скомпрометированные файлы, 282
списки управления доступом, 22
спуфинг, 83
протокола разрешения адресов, 83
41
стек>
страничный файл, 78
стJупень, ,12о2о
У
,
удаленное наблюдение за сетью, 187
универсализация файловых имен, 160
Учет процессов, 168
ф
,
удаленное наблюдение за сетью, 187
универсализация файловых имен, 160
Учет процессов, 168
ф
Ц
централизованное протоколирование, 150
циклическая БД, 179
Щ
Ц
централизованное протоколирование, 150
циклическая БД, 179
Щ
программы (продолжение) netstat, 32
хNт map, 10о8
ntopi lgl
NTsyslog 153
Oinkmaster, 264
OpenVPN, 226
passwd, 20
proftpd, 38
грсара, 187
RRDtool, 179
Sebek1, 278 /
sоni.fгf,d.et,23л153о4/
SnortSam 260
Spade, 263
Squid, 208
Stunnel, 213
sudo, 27
swatch, 161
syslogd, 150
критерии фильтрации, 151
syslog-ng, 1л6п4,
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
С
файл подкачки
очистка, 78
фильтрация МАС-адресов, 105 формат
р^оп 9RQ
шифрование
с помощью SSH, 204 шифрование каталога временных
файлов, 76
АНТИХАКИНГ В СЕТИ. ТРЮКИ
100 профессиональных примеров
O’REILLY
D^питерЭндрю Локхарт
АНТИХАКИНГВ СЕТИ.ТРЮКИ
Эндрю Локхарт
Москва - Санкт-Петербург - Нижний Новгород - ВоронежНовосибирск - Ростов-на-Дону - Екатеринбург - СамараКиев Харьков - Минск
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-ХISBN 0596006438 (англ.)ISBN 5-469-00385-Х© 2004 O'Reilly Media, Inc.
ISBN 0596006438 (англ.)
ISBN 5-469-00385-Х
ISBN 0596006438 (англ.)
ISBN 5-469-00385-Х
© Перевод на русский язык ЗАО Издательский дом «Питер», 2005
© Издание на русском языке, оформление ЗАО Издательский дом «Питер», 2005
краткое содержание
Об авторе10
Вступление13