Linux глазами хакера - Михаил Флёнов

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

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

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

Существует три метода автоматического определения уязвимости: сканирование, зондирование и имитация. В первом случае сканер собирает информацию о сервере, проверяет порты, чтобы узнать, какие установлены сервисы/демоны, и на основе их выдает отчет о потенциальных ошибках. Например, сканер может проверить сервер и увидеть на 21 порту работающую службу FTP. По строке приглашения (если она не была изменена), выдаваемой сервером при попытке подключения, можно определить его версию, которая сравнивается с базой данных. И если в базе есть уязвимость для данного сервера, то пользователю выдается соответствующее сообщение.

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

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

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

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

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

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

Дайте сканеру все необходимые права на доступ к тестируемой системе. Например, некоторые считают, что наиболее эффективно удаленное сканирование, когда по сети имитируется атака. Это правильно, но сколько времени понадобится на проверку стойкости паролей для учетных записей? Очень много! А сканирование реестра и файловой системы станет невозможным. Поэтому локальный контроль может дать более качественный результат.

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

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

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

В дальнейшем мы рассмотрим методы ручной проверки безопасности системы и программы, упрощающие этот процесс. Что использовать? Я же сказал, что все. Вы должны проверять систему всеми возможными методами. Ограничившись только одним способом, рискуете что-то упустить и оставить потенциальную лазейку.

12.2. Закрываем SUID- и SGID-двери

Как администратор или специалист по безопасности, вы должны знать свою систему от и до. Мы уже говорили, что одной из проблем может стать бит SUID или SGID. Вы должны вычистить все эти биты у программ, которыми не пользуетесь. Но как их найти? Для этого можно воспользоваться командой:

find / ( -perm -02000 -o -perm -04000 ) -ls

Эта директива найдет все файлы, у которых установлены права 02000 или 04000, что соответствует битам SUID и SGID. Выполнив команду, вы увидите на экране примерно следующий список:

130337 64 -rwsr-xr-x 1 root root 60104 Jul 29 2002 /bin/mount

133338 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, и взломщику для выполнения любых действий достаточно находиться в системе с гостевыми правами.

12.3. Проверка конфигурации

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

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