Михаил Фленов СанктПетербург бхвпетербург 2010 удк 681 06 ббк 32. 973. 26018. 2 Ф69
 Скачать 3.69 Mb.
|
|
Глава 12 Мониторинг системы Первоначальная задача администратора — установить систему, правильно распределить права доступа и настроить все необходимые сервисы. После этого многие из них складывают ручки и начинают гонять монстров по кори- дорам виртуального мира Doom 3. Если вы являетесь таким администрато- ром , то рано или поздно ваш сервер будет взломан, потому что любая систе- ма требует наблюдения. Сервер же — как ребенок: любит, чтобы за ним наблюдали , иначе нашалит. Чтобы уменьшить вероятность проникновения в систему постороннего и обезопасить себя от недобросовестных пользователей вашей сети, нужно постоянно держать сервер под контролем. Большинство взломов происходит благодаря тому, что администраторы не успевают обновить какие-либо сер- висы и установить заплатки. Очень часто взломщики узнают об уязвимости раньше и начинают ломать все серверы с этой ошибкой, что попадаются на глаза. Хороший администратор может и должен найти информацию об уязвимости и сделать все необходимое для предотвращения любой атаки. Для этого дол- жен производиться регулярный мониторинг системы и поиск узких мест. Иногда хакеры проникают в систему, и долгое время находятся в ней, не проявляя видимой активности. Вы должны уметь найти таких мышек и обез- вредить их до того, как они смогут натворить что-либо печальное. Если взлом произошел, то ваша задача не просто восстановить работу, а пре- дотвратить повторное вмешательство. Я много раз видел людей, которые по- сле взлома просто восстанавливают удаленные файлы и продолжают зани- маться своими делами в надежде, что такое больше не повторится. Это ошибка , потому что хакер уже почувствовал себя безнаказанным и обяза- тельно вернется. Глава 12 360 К следующему его приходу вы должны быть готовы. Сделайте все возмож- ное , чтобы найти сведения о взломщике, о том, как он проникает на сервер, и постарайтесь блокировать атаку. Также просмотрите все последние бюлле- тени ошибок (BugTraq) в поисках информации о дырах в вашей версии ОС и установленных сервисах. Не будем дожидаться, когда злоумышленник проникнет в систему, и мы по- теряем сон. Давайте рассмотрим действия, которые можно произвести еще до взлома , когда система работает нормально. Это поможет повысить безопас- ность сервера. Все , о чем мы будем говорить в этой главе, необходимо делать и до проник- новения в систему, и после. Взломщики иногда оставляют потайные двери (например, устанавливают SUID-бит на программу, для которой он не дол- жен быть установлен), и вы должны регулярно сканировать систему на пред- мет безопасности описанными ниже методами. Особенно это касается новой системы (сразу после инсталляции и настройки), но такие проверки следует производить после обновления, добавления программ или сразу после взлома. 12.1. Автоматизированная проверка безопасности Практически каждый день специалисты по безопасности находят в разных системах недочеты и, откровенно говоря, дыры или даже пробоины. Весь этот перечень выкладывается в отчетах BugTraq на разных серверах. Я уже советовал посещать www.securityfocus.com, чтобы следить за новостями, и сейчас не отказываюсь от своих слов. Новинки действительно надо смот- реть на подобных серверах, но ведь есть еще ворох старых уязвимостей, ко- торые могли остаться незалатанными на сервере. Как же поступить с ними? Неужели придется качать все сплоиты и руками проверять каждую дыру? Конечно же, нет. Существует громадное количество программ для автомати- зации тестирования сервера на ошибки, и самые распространенные из них — это SATAN (сильно устаревший, но легендарный), Internet Scanner, NetSonar, CyberCop Scanner. Я не стану рекомендовать какую-нибудь определенную программу. Не суще- ствует такой утилиты, в которой была бы база абсолютно всех потенциаль- ных уязвимостей. Поэтому скачивайте все, что попадается под руку, и тести- руйте систему всеми доступными программами. Возможно, что-то вам и пригодится. Но обязательно обратите внимание на продукты компании Internet Security Systems (ISS, системы интернет-безопасности www.iss.net), потому что сканеры этой фирмы (Internet Scanner, Security Manager, System Мониторинг системы 361 Scanner и Database Scanner) используют все три метода сканирования, о ко- торых мы будем говорить чуть позже. На данный момент Internet Security Systems куплена корпорацией IBM и является ее подразделением. Компания Internet Security Systems разработала целый комплект утилит под общим названием SAFEsuite. В него входят не только компоненты проверки безопасности системы, но и модули выявления вторжения и оценки конфигу- рации основных серверных ОС. Сканеры безопасности похожи на антивирусы — защищают хорошо, но только от старых приемов. Любой новый метод взлома не будет обнаружен, пока вы не обновите программу. Поэтому я рекомендую не полагаться цели- ком и полностью на отчеты автоматизированного сканирования, а после ра- боты программы самостоятельно проверить наличие последних уязвимостей, описанных в каком-либо бюллетене ошибок (BugTraq). С помощью автоматизированного контроля очень хорошо производить пер- воначальную проверку, чтобы убедиться в отсутствии старых ляпсусов. Если ошибки найдены, то нужно обновить уязвимую программу, ОС или сервис, а также поискать на том же сайте www.securityfocus.com способ обезврежи- вания . Почти всегда вместе с описанием уязвимости дается вакцина, позво- ляющая залатать прореху в сервисе или ОС. Вакцину может предложить и программа сканирования, если в базе данных есть решение проблемы для данного случая. Почему даже после лучшего и самого полного сканирования нельзя быть уверенным , что уязвимостей нет? Помимо новых ошибок в сервере надо принимать во внимание еще и фактор конфигурации. На каждом сервере используются свои настройки, и при определенных условиях легко нахо- димая вручную уязвимость может остаться незаметной для автоматического сканирования . На сканер надейся, а сам не плошай. Так что продолжайте тес- тировать систему на известные вам ошибки самостоятельно. Каждый сканер использует свои способы и приемы, и если один из них не нашел ошибок, то другой может отыскать. Специалисты по безопасности любят приводить пример с квартирой. Допустим, вы пришли к другу и по- звонили в дверь, но никто не открыл. Это не значит, что дома никого нет, может хозяин не услышал звонок (находился в душе, в наушниках или про- сто громко орал песни), или звонок не сработал. Но если позвонить по теле- фону , который лежит в этот момент возле хозяина, то он возьмет трубку. Возможна и обратная ситуация, когда вы названиваете по телефону, но его не слышно , а на звонок в дверь домочадцы отреагируют. Так и при автоматическом сканировании: один сканер может позвонить по телефону , а другой — постучит в дверь. Они оба хороши, но в конкретных Глава 12 362 случаях при разных конфигурациях сканируемой машины могут быть полу- чены разные результаты. Существуют три метода автоматического определения уязвимости: сканиро- вание , зондирование и имитация. В первом случае сканер собирает информа- цию о сервере, проверяет порты, чтобы узнать, какие установлены сервисы/ демоны , и на их основе выдает отчет о потенциальных ошибках. Например, сканер может проверить сервер и увидеть на порту 21 работающую службу FTP. По строке приглашения (если она не была изменена), выдаваемой сер- вером при попытке подключения, можно определить его версию, которая сравнивается с базой данных. И если в базе присутствует уязвимость для данного сервера, то пользователю выдается соответствующее сообщение. Сканирование — далеко не самый точный процесс, потому что автоматическое определение легко обмануть, да и уязвимости может не быть. Некоторые по- грешности в сервисах проявляются только при определенных настройках, то есть при установленных вами параметрах ошибка не обнаружится. При зондировании сканер не обследует порты, а проверяет программы на наличие в них уязвимого кода. Этот процесс похож на работу антивируса, который просматривает программы на наличие кода вирусов. Ситуации по- хожи , но искомые объекты различны. Метод хорош, но одна и та же ошибка может встречаться в нескольких программах. И если код в них разный, то сканер ее не обнаружит. Во время имитации программа моделирует атаки из своей базы данных. Например , в FTP-сервере может возникнуть переполнение буфера при реали- зации определенной команды. Сканер не будет выявлять версию сервера, а попробует выполнить инструкцию. Конечно же, выявление ошибки приве- дет к зависанию, но вы точно будете знать о ее наличии или отсутствии. Имитация — самый долгий, но и самый надежный способ, потому что если программе удалось взломать какой-либо сервис, то и у хакера это получится. При установке нового FTP-сервера, который еще не известен сканерам, он будет опробован на уже известные ошибки других серверов. Очень часто программисты разных фирм допускают одни и те же промахи, а методом сканирования анализатор может не найти подобную уязвимость только пото- му , что для данной версии нет записей в базе данных. Когда проверяете систему, обязательно отключайте сетевые экраны. Если блокирован доступ, то сканер не протестирует нужный сервис. В этом слу- чае анализатор сообщит, что ошибок нет, но реально они могут быть. Ко- нечно же, это не критичные ошибки, если они под защитой сетевого экрана, но если хакер найдет потайной ход и обойдет Firewall, то уязвимость станет опасной Мониторинг системы 363 Дайте сканеру все необходимые права на доступ к тестируемой системе. Например , некоторые считают, что наиболее эффективно удаленное скани- рование , когда по сети имитируется атака. Это правильно, но сколько време- ни понадобится на проверку стойкости паролей для учетных записей? Очень много ! А сканирование файловой системы станет невозможным. Поэтому локальный контроль может дать более качественный результат. При дистанционном сканировании только производится попытка прорваться в сеть. Такой анализ может указать на стойкость защиты от нападения извне. Но по статистике большинство взломов происходит изнутри, когда зарегист- рированный пользователь поднимает свои права и тем самым получает дос- туп к запрещенной информации. Хакер тоже может получить какую-нибудь учетную запись с минимальным статусом и воспользоваться уязвимостями для повышения прав доступа. Поэтому сканирование должно происходить и дис- танционно , для обнаружения потайных дверей, и локально, для выявления оши- бок в конфигурации, с помощью которых можно изменить привилегии. Автоматические сканеры проверяют не только уязвимости ОС и ее сервисов, но и сложность пароля, и имена учетных записей. В анализаторах есть база наиболее часто используемых имен и паролей, и программа перебором про- веряет их. Если удалось проникнуть в систему, то выдается сообщение о слишком простом пароле. Обязательно замените его, потому что хакер мо- жет использовать тот же метод, и легко узнает параметры учетной записи. Анализаторы безопасности могут использовать как хакеры, так и админист- раторы . Но задачи у них разные. Первым нужно автоматическое выявление ошибок для последующего применения, а вторые используют анализ, чтобы закрыть уязвимости, причем для них желательно сделать это раньше, чем найдет и использует дыры хакер. В дальнейшем мы рассмотрим методы ручной проверки безопасности систе- мы и программы, упрощающие этот процесс. Что использовать? Я же сказал, что все. Вы должны проверять систему всеми возможными методами. Огра- ничившись только одним способом, вы рискуете что-то упустить и оставить потенциальную лазейку. 12.2. Закрываем SUID- и SGID- двери Как администратор или специалист по безопасности вы должны знать свою систему от и до. Мы уже говорили, что одной из проблем может стать бит SUID или SGID. Вы должны вычистить эти биты у всех программ, которыми не пользуетесь. Но как их найти? Для этого можно воспользоваться командой: find / \( -perm -02000 –o –perm -04000 \) -ls Глава 12 364 Эта директива найдет все файлы, у которых установлены права 02000 или 04000, что соответствует битам SUID и SGID. Выполнив команду, вы увидите на экране примерно следующий список: 130337 64 -rwsr-xr-x 1 root root 60104 Jul 29 2002 /bin/mount 130338 32 -rwsr-xr-x 1 root root 30664 Jul 29 2002 /bin/umount 130341 36 -rwsr-xr-x 1 root root 35040 Jul 19 2002 /bin/ping 130365 20 -rwsr-xr-x 1 root root 19072 Jul 10 2002 /bin/su Самое страшное, что все программы из этого списка принадлежат пользова- телю root и, значит, будут выполняться от его имени. В системе есть и файлы с SUID- и SGID-битом, выполняющиеся от имени других пользователей, но таких меньшинство. Если вы видите, что программа не используется вами, то ее стоит удалить или снять биты. Если таких программ, по вашему мнению, нет, то подумайте еще раз. Может, все-таки стоит от чего-то отказаться? Например, программа ping не является обязательной для сервера, и у нее бит SUID можно снять. Если и после корректировки привилегированных программ осталось все рав- но много, то советую для начала убрать бит со всех программ. Конечно же, тогда пользователи не смогут монтировать устройства или менять себе па- роль . Но нужно ли это им? Если уж возникнет острая необходимость, то все- гда можно вернуть им такую возможность, восстановив SUID-бит. А ведь можно сделать владельцем программы другую учетную запись, у которой будет меньше прав. Это сложно, а иногда и невозможно, реализовать, и придется вручную изменять разрешения, но это сделает ваш сон более спокойным. Почему необходимо регулярно проверять файлы на наличие SUID- или SGID-битов? Взломщики, проникая в систему, очень часто стремятся укре- питься в ней, спрятаться, и при этом иметь максимальные права. Для этого может использоваться простейший метод — установка SUID-бита на интер- претатор команд bash. В этом случае интерпретатор для любого пользователя будет выполнять команды с правами root, и взломщику для выполнения лю- бых действий достаточно находиться в системе с гостевыми правами. Следите за любыми появляющимися новыми программами с битами SUID или SGID и убирайте все, что вызывает подозрение. 12.3. Проверка конфигурации Мы рассмотрели достаточно много правил конфигурирования системы, и помнить все невозможно. Настройка системы — достаточно сложный про- цесс , во время которого очень легко ошибиться. Но так как есть определен- Мониторинг системы 365 ные правила конфигурирования, то есть и возможность автоматизировать проверку Как мы уже знаем, есть программы, которые могут проверять конфигурацию. Это должно происходить на компьютере локально. В настоящее время уже написано достаточно много утилит для автоматизации контроля. Некоторые из них устарели и давно не обновлялись, а какие-то появились недавно и еще только наращивают свою функциональность (количество проверок). 12.3.1. lsat Первая программа, с которой нам предстоит познакомиться — lsat. Ее исто- рия не слишком длинна, но за счет частого обновления возможности быстро выросли , а благодаря модульной архитектуре расширение функций происхо- дит легко и быстро. Программа lsat поставляется в исходных кодах, и найти ее можно по адресу usat.sourceforge.net. На момент написания этой книги была доступна вер- сия 0.9.7. К сожалению, она не обновлялась с конца 2008 года, но, тем не ме- нее , все равно может оказаться весьма полезной. Скачайте архив в свою до- машнюю директорию, и давайте вместе установим ее и попробуем использо- вать . На сайте доступны tgz- и zip-версия. Я рекомендую воспользоваться первой , потому что это родной архив для Linux, и он проще в использовании. Для установки выполните следующие команды: tar xzvf lsat-0.9.7.tgz ./lsat-0.9.7.tgz/configure ./lsat-0.9.7.tgz/make Первая директива распаковывает архив lsat-0.9.7.tgz. Имя файла может отли- чаться , если у вас другая версия программы. Вторая команда запускает кон- фигурирование , а третья собирает проект из исходных кодов в один испол- няемый файл. Для запуска программы на выполнение используйте следующую команду: ./lsat-0.9.7.tgz/lsat Теперь можно идти готовить кофе и медленно и печально его пить. Процесс тестирования системы занимает довольно много времени, особенно на сла- бых машинах. При запуске можно указать один из следующих ключей: -o имя файла — отчет записывать в указанный файл. По умолчанию отчет попадает в файл lsat.out; -v — выдавать подробный отчет; Глава 12 366 -s — не выдавать никаких сообщений на экран. Это удобно при выполне- нии команды через cron; -r — выполнять проверку контрольных сумм (это делается с помощью RPM). Это позволяет выявить незаконно измененные программы. Лучше всего lsat будет работать на Red Hat-подобных системах, потому что в нее встроена возможность работы с RPM-пакетами, которые являются от- личительной особенностью дистрибутива Red Hat Linux и его клонов. Во время проверки вы увидите примерно следующий текст на экране: Starting LSAT... Getting system information... Running modules... Running checkpkgs module... … Running checkx module... Running checkftp module... Finished. Check lsat.out for details. Don't forget to check your umask or file perms when modifying files on the system. Пока слова о безопасности отсутствуют. Только информация о том, что ска- нировалось . Все самое интересное после тестирования можно найти в файле ./lsat-0.9.2.tgz/lsat.out. Я прогнал эту программу на системе сразу после уста- новки и получил документ размером 190 Кбайт. Таким образом, есть над чем подумать и что изучить о вашей системе. В выходном файле вы найдете множество советов. Так, в самом начале можно увидеть рекомендации по пакетам, которые нужно удалить: **************************************** Please consider removing these packages. sendmail-8.11.6-15.asp portmap-4.0-41 bind-utils-9.2.1-1.asp nfs-utils-0.3.3-5 pidentd-3.0.14-5 sendmail-devel-8.11.6-15.asp sendmail-cf-8.11.6-15.asp ypbind-1.10-7 ypbind-1.10-7 Мониторинг системы 367 В самом деле, некоторые пакеты можно отнести к разряду не очень надеж- ных . Например, в программе sendmail регулярно находят ошибки, поэтому lsat предлагает его подчистить. В выходном файле мне очень понравилась надпись: Разработчик программы посчитал, что загрузка в графическом режиме хуже для безопасности. Действительно, это лишние программы и дополнительные проблемы . Текстовый режим не требует столько ресурсов, работает меньше программ , а значит, он быстрее и безопаснее. Если опуститься немного ниже, то вы увидите список всех файлов в системе с установленными битами SUID и SGID. При использовании программы lsat нет смысла самостоятельно заниматься поисками потенциально опасных программ Еще немного ниже идет список общедоступных файлов: **************************************** This is a list of world writable files /var/lib/texmf/ls-R /var/www/html/cache/archive/index.html /var/www/html/cache/categories/category.cgi /var/www/html/cache/categories/index.html /var/www/html/cache/download/download-2-1.cgi /var/www/html/cache/download/download-3-1.cgi /var/www/html/cache/download/download-4-1.cgi Это те файлы, которые имеют право изменять любые пользователи системы, даже с минимальными правами. В идеале таких записей вообще не должно быть . В любой файл должны иметь право писать только владельцы или, в крайнем случае, пользователи группы, но никак не все. Далее идет список файлов, в которые могут писать пользователи каких-либо групп . Проверьте, возможно, не всем файлам из этого списка нужно давать такой статус. Отчеты удобны и легко читаются, но в самом конце появляется ложка дегтя. Пусть она и небольшая, но она есть. Программа показывает изменения в файловой системе с момента последнего запуска. Вот тут разобраться с чем-либо очень сложно. Информация выводится практически в произволь- ном порядке, а ведь удобнее было разделить модификации по степени опасности . Например, удаленный или добавленный в разделе /tmp файл не так важен, потому что там изменения происходят тоннами каждые пять ми- нут . А вот все, что касается раздела /etc, намного опаснее, и это следовало бы выделять. |