Библиотека сайта rus-linux.net
5. Безопасность файлов и файловой системы
Несколько минут подготовки и прогнозного планирования прежде чем открыть вашу систему Интернету может помочь защитить как ее, так имеющиеся в ней данные.
- Нет ни одной причины, по которой нужно было бы разрешать запуск SUID/SGID программ из пользовательских домашних каталогов. Для тех разделов, в которые разрешена запись не только администратору, в /etc/fstab поставьте опцию `nosuid'. Вы также можете захотеть использовать `nodev' и `noexec' для домашних каталогов, а также /var, которые запретят выполнение программ и создание символьных и блочных устройств, которые и так никогда не нужны.
- Если вы экспортируете файловые системы используя NFS, обязательно отконфигурируйте /etc/exports с максимально возможными ограничениями. Это означает не использовать символы подстановки (wildcards), не разрешать запись администратору удаленной системы, а также монтирование с правами "только чтение" где только возможно.
- Настройте umask создания файлов для ваших пользователей настолько ограничивающей насколько это возможно. Общеупотребительными являются 022, 033, и наиболее ограничивающая 077, и добавьте все это к /etc/profile.
- Установите лимит использования файловой системы вместо разрешения
неограниченного использования, что установлено по умолчанию. Вы
можете контролировать лимиты каждого пользователя используя специальный
модуль лимитов ресурсов PAM и /etc/pam.d/limits.conf. Например, лимиты
для группы `users' могут выглядеть следующим образом:
@users hard core 0 @users hard nproc 50 @users hard rss 5000Это запрещает создание core файлов, ограничение количества процессов значением 50, и ограничение использования памяти 5МВ на пользователя.
- Файлы /var/log/wtmp и /var/run/utmp содержат записи регистрации для
всех пользователей в вашей системе. Их накопление должно поддерживаться
постоянно, поскольку их можно использовать для определения когда и откуда
пользователь (или потенциальный взломщик) вошел в вашу систему. Эти
файлы должны иметь маску прав доступа 644, чтобы не нарушать нормальной
работы системы.
- Для предотвращения случайного удаления или перезаписи файлов, которые
должны быть защищены, можно использовать имунный бит. Он также предотвращает
создание кем бы то ни было символьной связи на этот файл, что является
одним из методов атаки с целью удаления /etc/passwd или /etc/shadow.
Смотри руководство по chattr(1) для более детальной информации об
имунном (immutable) бите.
- SUID и SGID файлы в вашей системе являются потенциальными носителями
риска вашей безопасности, поэтому должны быть под постоянным и тщательным
наблюдением. Поскольку эти программы предоставляют специальные привилегии
пользователям, которые запускают их, необходимо убедиться, что небезопасные
программы не установлены. Любимым приемом кракеров является разработка
программ с SUID "root", и затем оставлять их в системе как "черный ход"
для получения доступа в следующий раз, даже если изначально использованная
"дыра" уже и будет закрыта.
Найдите все SUID/SGID программы в вашей системе и посмотрите, что они из себя представляют, таким образом вы будете знать, что любое изменение в них является индикатором возможного взлома. Чтобы найти все SUID/SGID программы в вашей системе используйте следующую команду:
Вы можете дискриминативно убрать все SUID или SGID права для всех подозрительных программ используя chmod(1), а затем поставить обратно, если вы будете абсолютно уверены в необходимости этого.root# find / -type f \( -perm -04000 -o -perm -02000 \) - Файлы с разрешенными для всех правами записи, особенно системные файлы, могут
быть "дырой" в безопасности, если взломщик получит доступ к вашей
системе и изменит их. Кроме того опасны каталоги с разрешенными
для всех правами на запись, поскольку они позволяют взломщику по желанию
добавлять или удалять файлы. Для обнаружения в вашей системе всех файлов
с разрешенными для всех правами записи выполните следующую команду:
и убедитесь, что вы действительно знаете, почему в эти файлы разрешена запись. В условиях нормальной работы только для некоторых файлов будет разрешена запись, включая некоторые из /dev и символьные ссылки.root# find / -perm -2 -print - Файлы без владельца также могут быть индикатором внедрения в вашу
систему взломщика. Файлы без владельца или с таковым без принадлежности
к какой-либо группе можно обнаружить с помощью команды:
root# find / -nouser -o -nogroup -print - Обнаружение файлов .rhosts должно быть вашей регулярной обязаностью как
системного администратора, поскольку эти файлы ни в коем случае не
должны быть в вашей системе. Помните, взломщику нужен только один
небезопасный счет для возможного получения доступа ко всей вашей сети.
Вы можете обнаружить все файлы .rhosts в вашей системе с помощью команды:
root# find /home -name .rhosts -print - И наконец, перед тем как изменить права доступа каких-либо системных
файлов, убедитесь, что вы понимаете, что делаете. Никогда не изменяйте
права доступа файла только потому, что это является простым способом
заставить что-то работать. Прежде чем изменять, всегда определяйте,
почему файл имеет именно такие права доступа.
5.1 Установки umask
Команду umask можно использовать для определения режима создания файлов в вашей системе, принимаемого по умолчанию. Она представляет битовое дополнение до желаемого значения режима файла. Если файлы создаются без какого-либо специального набора прав доступа, то можно случайно разрешить чтение или запись тому, кто не должен иметь таких прав. Типично принятыми umask являются 022, 027 и 077, которые наиболее ограничивающие. Нормальным будет установить значение umask в /etc/profile, так чтобы оно применялось ко всем пользователям в системе. Например, вы можете иметь строку подобную следующей:
# Значение umask по умолчанию для всех пользователей
umask 033
Если вы используете Red Hat и придерживаетесь их схемы создания ID пользователя и группы (собственная группа пользователя), то для значения umask необходимо использовать только 002. Это из-за того, что настройки по умолчанию определяют одного пользователя на группу.
5.2 Права доступа файла
Важно убедиться, что ваши системные файлы закрыты для случайного редактирования пользователями и группами, которые не должны выполнять таких действий.
UNIX разделяет контроль доступа к файлам и каталогам по трем принадлежностям: владелец, группа, все остальные. Существует всегда один владелец, любое количество членов группы и еще все остальные.
Быстрое объяснение прав доступа в unix:
Собственность - Какой пользователь(ли) и группа(ы) удерживает контроль установок прав вершины (node) и родителя вершины.
Права доступа - Назначаемые или переназначаемые в битовом выражении установки, которые разрешают некоторый тип доступа к собственности. Права доступа к каталогам могут иметь отличающиеся значения от оных у файлов, содержащихся в них.
Чтение:
- Возможность просмотра содержимого файла
- Возможность чтения каталога
Запись:
- Возможность добавить или изменить файл
- Возможность удалять или перемещать файлы в каталоге
Выполнение:
- Возможность запуска программы или скрипта оболочки (shell script)
- Возможность поиска в каталоге, в комбинации с правом чтения
- Save Text Attribute: (Для каталогов)
sticky бит также имеет отличное значение применимо к каталогам. Если sticky бит установлен для каталога, то пользователь может удалять только те файлы, владельцем которых он является, или к которым ему явно заданы права записи, несмотря на то, что ему разрешена запись в этот каталог. Это сделано для каталогов подобных /tmp, в которые разрешена запись всем, но в которых нежелательно разрешать любому пользователю удалять файлы от нечего делать. sticky бит видно как 't' в полном режиме отображения содержимого каталога. (long listing).
- SUID Attribute: (Для файлов)
Описывает set-user-id права на файл. Если права доступа set-user-id установлены во "владелец" и файл исполняемый, то процесс, который запускает его, получает доступ к системным ресурсам основываясь на правах пользователя, который создал этот процесс. Во многих случаях это является причиной возникновения 'buffer overflow'.
- SGID Attribute: (Для файлов)
Если установлен в правах доступа "группы", этот бит контролирует "set group id" статус файла. При этом он работает также как и SUID, только задействована при этом группа, а не отдельный пользователь.
- SGID Attribute: (Для каталогов)
Если вы установите SGID бит для каталога (командой "chmod g+s directory"), то файлы содержащиеся в этом каталоге будут иметь установки группы такие, как у каталога.
Вы - Владелец файла
Группа - Группа, к которой вы принадлежите
Остальные - Любой в системе, кто не является владельцем либо членом группы
Пример файла:
-rw-r--r-- 1 kevin users 114 Aug 28 1997 .zlogin
1й бит - каталог? (нет)
2й бит - чтение владельцем? (да, для kevin)
3й бит - запись владельцем? (да, для kevin)
4й бит - выполнение владельцем? (нет)
5й бит - чтение группой? (да, для users)
6й бит - запись группой? (нет)
7й бит - выполнение группой? (нет)
8й бит - чтение остальными? (да, для остальных)
9й бит - запись остальными? (нет)
10й бит - выполнение остальными? (нет)
Следующие строчки являются примером минимальных установок прав, которые требуются для предоставления описанного доступа. Вы можете захотеть предоставить больше прав, чем приведено, но здесь описано, что эти минимальные права на файл разрешают:
-r-------- Разрешают чтение файла владельцем
--w------- Разрешают владельцу изменение или удаление файла
---x------ Владелец может выполнять эту программу, но не скрипты
командного интерпретатора, которые еще нуждаются в правах
на чтение
---s------ Будет выполняться с эффективным пользовательским ID = владелец
-------s-- Будет выполняться с эффективным пользовательским ID = группа
-rw------T Не обновлять "последнего времени изменения". Обычно используется
для swap файлов
---t------ Не действует. (прежде sticky бит)
drwxr-xr-x 3 kevin users 512 Sep 19 13:47 .public_html/
1й бит - каталог? (да, содержит много файлов)
2й бит - чтение владельцем? (да, для kevin)
3й бит - запись владельцем? (да, для kevin)
4й бит - выполнение владельцем? (да, для kevin)
5й бит - чтение группой? (да, для users)
6й бит - запись группой? (нет)
7й бит - выполнение группой? (да, для users)
8й бит - чтение остальными? (да, для остальных)
9й бит - запись остальными? (нет)
10й бит - выполнение остальными? (да, для остальных)
Следующие строчки являются примером минимальных установок прав, которые требуются для предоставления описанного доступа. Вы можете захотеть предоставить больше прав, чем приведено, но здесь описано, что эти минимальные права на файл разрешают:
dr-------- Можно просмотреть содержание, но нельзя прочесть атрибуты файла
d--x------ Можно войти в каталог, а также использовать его в полной записи
файла (т.е. с путем к нему)
dr-x------ Владелец может теперь просмотреть атрибуты файла
d-wx------ Файлы теперь можно создавать/удалять, даже если каталог
не текущий
d------x-t Предотвращает файлы от удаления остальными с правами записи.
Используется для /tmp
d---s--s-- Никаких действий
Системные конфигурационные файлы (обычно в /etc) имеют обычно режим 640 (что означает -rw-r-----) и являются собственностью администратора. В зависимости от требований безопасности в вашей системе, вы можете изменить эти установки. Никогда не предоставляйте возможности записи в системные файлы для "группы" или "остальных". Некоторые конфигурационные файлы, включая /etc/shadow, должны разрешать чтение только администратору, а каталоги в /etc должны по крайней мере быть недоступны другим.
- SUID Shell Scripts
SUID скрипты командного интерпретаторa являются также риском безопасности, по этой причине ядро не обслуживает их. Независимо от вашего мнения о том насколько безопасным является скрипт, он может быть переделан для выдачи взломщику оболочки администратора.
5.3 Проверка целостности с помощью Tripwire
Другим хорошим способом обнаружить локальные (а также сетевые) атаки на вашу систему является использование тестеров целестности (integrity checkers) подобных Tripwire. Tripwire вычисляет контрольные суммы для всех важных бинарных и конфигурационных файлов в вашей системе и сравнивает их с предыдущими, хорошо известными, из базы данных. Таким образом любые изменения в файлах будут замечены.
Хорошей идеей будет записать tripwire на дискету, а затем установить на нее защиту от записи. Таким образом взломщик не сможет подделать tripwire или изменить базу данных. Как только вы установили tripwire будет неплохо включить в свои обязанности администратора безопасности проверку с помощью него на предмет каких-либо изменений.
Вы можете даже добавить в список задач crontab запуск tripwire c вашей дискеты каждую ночь и посылку результатов вам по почте утром. Что-то наподобие этого:
# установить получателя
MAILTO=kevin
# запустить tripwire
15 05 * * * root /usr/local/adm/tcheck/tripwire
Tripwire может быть всевышним в обнаружении взломщиков еще до того, как вы заметите их. Как только в системе появится некоторое количество измененных файлов, вы должны понимать, что имеет место деятельность взломщика, и знать, что делать вам самим.
5.4 "Троянские кони"
Термин "Троянский Конь" взят из великого творения Гомера. Идея состоит в том, что вы создаете программу, который чем-либо привлекателен, и каким-либо способом заставляете других людей скачать ее и запустить как администратор. Затем, пока они не разобрались, вы можете разрушить их систему. Пока они думают, что программа, которую они только-что вытянули, делает одну вещь (и может даже очень хорошо), она также разрушает их систему безопасности.
Вы должны быть очень внимательны при установке новых программ на вашу машину. RedHat предоставляет MD5 контрольные суммы и PGP ключи для RPM файлов, так что вы можете проверить действительно ли вы инсталируете реальные продукты. Другие дистрибутивы имеют подобные методы. Вы никогда не должны запускать из под администратора бинарники, для которых у вас нет исходников, или о которых вы ничего не слышали! Немногие взломщики имеют желание выложить на всеобщее обозрение исходный код.
Также может быть общим совет брать исходники некоторых программ с их реальных дистрибутивных серверов. Если программу нужно запускать из под администратора, проверьте исходный код сами или дайте на проверку тому, кому вы доверяете.
Next Previous Contents