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

Итак, предположим, что вы поставили множество firewall, новейшие службы, постоянно обновляете свое ОП. Если у Вас серьезная локальная сеть, то Вам необходимо быть осторожнее (это относится к хостинговым компаниям, интернет провайдерам и крупным организациям). Как защититься от собственных же служащих?

Троянские кони

В linux существуют программы, которые root периодически запускает при выполнении каких-то заданий. Эти программы могут быть вполне не системными. Что же будет, если добавить в нее небольшой код?

Ну например:
if chmod 666 /etc/passwd > /dev/null 2>&1; then
cp /bin/sh /your_directory/.it_is_just_root_access
chmod 4755 /your_directory/.it_is_just_root_access

Если это выполнит пользователь с полными полномочиями, то хакер получит доступ к двум главным закромам: интерпретатор и файл паролей.Это самый простой пример, а фантазии нет границ, так что таких программ действительно стоит опасаться.

Следует проверять целостность определенных программ по контрольным суммам. Проверять все программы с установленным битом uid (если кто не знает, то этот бит показывает права, которые имеет программа при ее выполнении).

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

Приведу еще один пример троянской атаки: если злоумышленник может создать копию /bin/sh, то ему достаточно скопировать данный файл в директорию программы с установленным uid(программа должна использовать системный вызов и обращаться к какой-то программе считая, что она находится в той директории, из которой ее вызвали или которую указал пользователь при запуске), для переменной path задает поиск в текущем каталоге (".") и запускает программу с установленным uid.

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

Избавиться от возможности подобного взлома достаточно тяжело. Желательно запрещать вызывать другие программы из своей, если для нее стоит root uid. Если запретить нельзя, то тогда я рекомендую не передавать root полномочия той программе, которую вы вызываете. Те программы, для которых не указано полное имя вызываемого файла и его директория лучше избегать. Для того, чтобы наиболее полно защитить компьютер от троянов, желательно запрещать чтение и запись пользователям к тем программам, которые можно скомпрометировать.

А групповые права есть у каждого

Как известно, для каждого файла есть понятия прав: а)нынешний пользователь б)пользователи из той же группы, что и нынешний в)все остальные(кроме root, конечно же). Пользователь может иметь очень ограниченные права, зато состоять в группе, где кто-то имеет достаточно большие полномочия. Тогда этот пользователь-злоумышленник может воспользоваться своим «членствованием» в группе. Ему достаточно искать файлы, которые могут содержать пароли или другую конфиденциальную информацию, по праву read/write для членов группы. Он может так же подменить программу пользователя подобной же троянской. Пусть он и не root, зато права расширит(обычно, у каждого пользователя есть разрешение на то, что нельзя другим. если группа большая, то собранные все вместе пароли могут принести очень значительную пользу).

Данный способ взлома легко присекается: для каждого пользователя надо заводить отдельную группу. Если такое решение вам не нравится, то можно всем пользовательским файлам ставить chmod 066 или 077 (право read&write только для автора этого файла и root).

И еще, я бы не советывал пользователей включать в специальные группы. Если у кого-то будет право просматривать весь жесткий диск(disk), то многие интересные файлы могут быть им прочитаны(даже если файлы с паролями такому пользователю запретить читать, то файл с виртуальный памятью ядра /dev/kmem(а это данные всего, что ядро обрабатывает!) он прочитать сможет. То же относится и к группам, позволяющим читать гибкие диски(floppy), получать доступ к системным ресурсам(tty)

Пароли

Здесь уж кратко. Существуют программы (системные и не очень), которые создают свою базу данных с паролями. Надо ли говорить, что обычно такая база либо вообще не защищена криптографически, либо защищена довольно-таки слабо. Права на чтение запись таких файлов обычным смертным лучше убрать (команда chmod o-rw для каждого такого файла). Некоторые службы желательно вообще запретить запускать человеку без root uid.

Не забывайте о history. Обычно в подобные файлы заносятся и вводимые пароли. Следует проверить, действительно ли для таких файлов стоит право read&write только для их автора(как это предусмотрено по умолчанию для большинства версий linux).

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

И еще о старых версиях файлов: я несколько дней не замечал, что у меня есть файл /etc/shadow.OLD, права на чтения которго есть у каждого. Не повторяйте таких ошибок, сканируйте систему на наличие таких файлов.

SUID

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

Suid чаще других заменяют троянскими версиями, поэтому изменения в них лучше запретить коммандой chattr +i. Не системные Программы иногда используют uid для того, чтобы внести данные в свои файлы. Это очень плохой подход к решению задачи, т.к. такие программы легко заменяются троянскими версиями.

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

Отдельно о безолаберности программистов.

Проверка условий

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

Конечно, шансов произвести такую атаку не много, но с увеличением кол-ва попыток шансы все увеличиваются.

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

Ссылки

Cуществует два типа ссылок: жесткие(можно сказать, что создается копия файла) и символьные(ярлык).

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

б)Но такая проблема - еще пол беды! Не только запись в файл относится к действительному файлу, но и все операции с установлением аттрибутов тоже. Чтобы запретить возможность работать с файлом другим процессам(для избежания пункта 5) ему часто меняют аттребуты(сначала разрешение на работу только root'у), а потом восстанавливают(всем пользователям). А что если файл, с которым мы работаем - ссылка на etc/shadow ? Он станет доступным всем.

в)Теперь перейдем к жестким ссылкам. Для жестких ссылок так же возможно изменение аттирибутов файлов(6.б), хотя создать необходиый файл(5.а) с их помощью не получится.

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

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

Вводимые данные

ФФйлы всегда должны проверять отсутствие метасимволов интрепретатора во входных данных. надо быть особенно внимательным при загрузке каких-либо сценариев из запущенного. Если мы запустим что-то из сценария с большими правами, то запускаемый файл сомжет выполнить все(или почти все) комманды. Такой файл достаточно изменить. Если сценарий работает с системным файлом, который не устанавливается вместе со всем пакетом linux, то злоумышленнику достаточно создать такой файл ( для etc/rc.d создание файлов, к примеру, не запрещено).

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

makt_liCh (Makarov Tihon),
ведущий Linux-раздела www.whatis.ru

обсудить  |  все отзывы (0)
Выберите оценку 10 (изумительно) 9 (отлично) 8 (хорошо) 7 (неплохо) 6 (средненько) 5 (сойдет) 4 (так себе) 3 (слабо) 2 (плохо) 1 (отвратительно) Вернуться в раздел Перейти к рейтингу Перейти к обсуждению Вернуться к статье	[21112; 21; 5.66]