Главная
страница 1 ... страница 56страница 57страница 58страница 59страница 60

21.6Проблемы защиты /etc/passwd и /etc/shadow


Очень часто источником неприятностей является плохое управление паролями. В файлах /etc/passwd и /etc/shadow содержатся данные о том, кто может входить в систему и что он при этом имеет право в ней делать. Эти файлы представляют собой передовую линию защиты системы от захватчиков. Их нужно вести с особой тщательностью, стараясь не допускать ошибок и не загромождать файлы устаревшими данными.

Проверка и выбор паролей

Регулярно (желательно каждый день) проверяйте, все ли учетные записи имеют пароль. В записях файла /etc/shadow (или /etc/passwd, если в системе не используются скрытые пароли), содержащих описания псевдопользователей наподобие daemon (такие пользователи являются владельцами некоторых системных файлов, но, естественно, никогда не регистрируются в системе), в поле пароля должна стоять звездочка (*). Она не соответствует ни одному паролю и, таким образом, предотвращает использование учетной записи. Существует несколько специализированных программных пакетов, осуществляющих проверку файла /etc/shadow на предмет наличия проблем, связанных с безопасностью, хотя для поиска пустых паролей вполне достаточно и такой команды:

perl -F: -ane 'print if not $F[1];' /etc/shadow

Сценарий, выполняющий эту проверку и направляющий по электронной почте результаты администратору, можно запускать с помощью демона cron. Дополнительно обезопасьте себя с помощью сценария, который будет ежедневно сверять файл /etc/passwd с его версией за предыдущий день (это позволяет делать команда diff) и сообщать о выявленных различи-ях• Это даст возможность контролировать правомерность внесенных изменений.

Доступ к файлам /etc/passwd и /etc/group следует организовать так, чтобы их могли читать все пользователи, но право записи имел только пользователь root. Если в системе имеется файл /etc/shadow, он должен быть недоступен рядовым пользователям.

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

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

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

В некоторых системах (в зависимости от используемых библиотек аутентификации) значащими являются лишь первые 8 символов пароля. Остальные просто игнорируют (DES).


21.6.1Скрытые пароли


Каждая запись файла /etc/passwd состоит из семи полей. Второе поле содержит строку, которая представляет собой зашифрованный пароль пользователя. Для того чтобы могли работать такие команды, как ls и ей подобные, файл /etc/passwd должен быть открыт для чтения. Следовательно, зашифрованная строка пароля доступна всем пользователям системы Злоумышленнику ничего не стоит представить в зашифрованном виде целый сло-варь или отдельные слова и провести сравнение с указанным полем во всех записях файла /etc/passwd. При совпадении сравниваемых элементов злоумышленник получает пароль.

Насколько это опасно? В 80-е гг. существовал по крайней мере один способ очень быстрой расшифровки паролей, но рядовому хакеру приходилось довольствоваться библиотечной функцией crypt() Для шифрования слов из словаря с целью их последующего сравнения. В то время "быстродействующий" компьютер мог выполнять порядка нескольких сотен операций шифрования в секунду. В 1998 г. Джон Гилмор (John Gilmore) из организации Electronic Frontier Foundation и шифровальщик Пол Кошер (Paul Kocher) взломали 56-разрядный ключ DES методом "грубой силы" за 56 часов. Последние исследования показывают, что с помощью специализированного компьютера стоимостью 1млн. долларов можно взломать любой 56-разрядный ключ DES за считанные часы.

Из этих далеко не обнадеживающих подсчетов вытекает настоятельная необходимость в ограничении доступа пользователей к зашифрованным строкам паролей. Самый распространенный способ — поместить пароли в отдельный файл, доступный только суперпользователю, а остальную часть файла /etc/passwd оставить без изменений. Файл, содержащий информацию о паролях, называется файлом скрытых паролей (/etc/shadow). "большинстве дистрибутивов Linux этот файл используется по умолчанию.

Групповые и совместно используемые Учетные записи

Опасно, если учетная запись используется несколькими людьми. Групповые регистрационые имена (например, guest или demo) представляют собой удобную лазейку для хакеров, поэтому применять их не следует.

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

Во многих организациях учетная запись root является групповой. Это слишком опасно! Рекомендуем контролировать предоставление прав суперпользователя с помощью утилиты sudo.

21.6.2Устаревание паролей


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

А вот пароль пользователя root следует модифицировать регулярно. При вводе он должен легко "скатываться" с пальцев, чтобы его трудно было определить, следя за движением пальцев по клавиатуре. В нашей организации многие администраторы работают с утилитой sudo, не вводя пароль суперпользователя напрямую, но к его выбору мы все равно относимся с особой ответственностью.

Пользовательские интерпретаторы команд

Не используйте сценарии как средство для неконтролируемой (беспарольной) регистрации в системе. Вход в систему без пароля допустимо разрешать только для прогона небольших неинтерактивных утилит, таких как date, sync или lpq.

Привилегированные учетные записи

Единственная отличительная черта пользователя root состоит в том, что его идентификатор равен 0. Поскольку в файле /etc/passwd может быть несколько записей с таким идентификатором, то существует и несколько способов входа в систему в качестве суперпользователя.

Один из способов, который хакеры, получив доступ к интерпретатору команд суперпользователя, широко применяют для открытия "черного хода", — редактирование файла /etc/passwd посредством ввода в него новых учетных записей с идентификатор пользователя, равным 0. Поскольку такие команды, как who и w, работают с регистрационным именем, хранящимся в файле /var/run/utmp, а не с идентификатором владельца регистрационного интерпретатора, они не в состоянии разоблачить хакера, который выглядит как рядовой пользователь, хотя на самом деле зарегистрирован в системе в качестве суперпользователя.

Спасением от этого вероломства является мини-сценарий, подобный тому, который используется для поиска учетных записей, не имеющих пароля:

perl -F: -ane 'print if not $F[2];' /etc/passwd

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

Программы с установленным битом смены идентификатора пользователя

Программы, выполняемые с установленным битом SUID (Set User ID — смена иден тификатора пользователя), являются источником проблем для безопасности системы, особенно если речь идет о получении привилегий суперпользователя. Такие программы, поставляемые вместе с Linux, являются безопасными, по крайней мере теоретически. Тем не менее огрехи в защите обнаруживались в прошлом и, несомненно, будут обнаруживаться в будущем.

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

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

Нет правила, требующего, чтобы программы с установленным битом SUID запускались от имени суперпользователя. Если нужно всего лишь ограничить доступ к файлу или базе данных, достаточно добавить в файл /etc/passwd псевдопользователя, единственное назначение которого будет заключаться во владении нужными ресурсами. Следуйте обычным соглашениям о добавлении псевдопользователей: используйте низкое значение UID, поставьте в поле пароля звездочку и сделайте начальным каталогом псевдопользова- теля каталог /dev/null.

Выполнение программ с установленными битами SUID и SGID (Set Group ID — смена идентификатора группы) можно отключать в отдельных файловых системах с помощью опции -о nosuid команды mount. Хорошими кандидатами на это являются файловые системы, содержащие начальные каталоги пользователей или смонтированные из ненажных административных доменов.

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

Для обнаружения таких программ вполне подойдет и простая команда find, например:

/usr/bin/find / -user root -perm -4000 -print| \

/bin/mail -s "Setuid root files" netadmin

В данном случае пользователю netadmin по электронной почте посылается список всех файлов принадлежащих пользователю root и имеющих установленный бит SUID.

Специальные права доступа

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

Файл устройства /dev/kmem позволяет получить доступ к виртуальному адресному пространству ядра. Его используют программы (например, ps), которые работают со структурами данных ядра. Право чтения указанного файла должно предоставляться только его владельцу и членам соответствующей группы и никому больше. Если необходимо получить доступ к этому файлу из определенной программы, то для нее должен быть установлен идентификатор группы, которой принадлежит файл (обычно это kmem), и бит SGID.

Раньше некоторые поставщики беззаботно выпускали дистрибутивы, в которых файл

/dev/kmem был открыт для чтения. Это создавало серьезную угрозу для безопасности сис- темы, потому что опытный программист, получив доступ к данным и буферам ядра мог

найти там не зашифрованные пароли. Если в вашей системе файл/dev/kmem могут читать все пользователи, немедленно исправьте этот промах. Правда, после таких изменений может оказаться, что некоторые программы перестанут работать. В этом случае следует поступить так, как говорилось в предыдущем абзаце.

Файлы /etc/passwd и /etc/group должны быть доступны для записи только владельцу

(пользователю root) и его группе. Режим доступа в данном случае — 644. Для файла /etc/shadow режим доступа равен 640, т.е. он вообще недоступен рядовым пользователям. Все эти файлы должны принадлежать какой-нибудь системной группе (обычно это root), Чтобы пользователи, не имея права записи в файлы /etc/passwd и /etc/shadow, могли изменять свои пароли, команда passwd (владельцем которой является пользователь root) выполняется с установленным битом SUID.

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

При настройке анонимного FTP-сервера в каталог ~ftp/etc/passwd обычно копируется усеченный файл паролей, чтобы правильно работала команда ls. He забудьте удалить из файла зашифрованные строки паролей.

Еще один потенциальный источник проблем — файлы устройств для разделов жесткого диска. Наличие права чтения или записи такого файла равнозначно наличию аналогичных прав для любого элемента файловой системы этого раздела. Право чтения/записи должен иметь только суперпользователь. Члены группы иногда могут получать право чтения с целью выполнения резервного копирования. Прав доступа для категории "прочие быть не должно.

Сюидные программы

Сюидная программа -- это программа, которая исполняется с правами (uid) не запустившего ее пользователя, а того, кому принадлежит файл программы. Реже используется смена идентификатора группы ("эсгидная программа" -- "sgid program").

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

"ls -l", вместо символа "x" в правах владельца стоит "s":

bobby:~% ls -l /usr/X11R6/bin/nxterm

-rws--x--x 1 root root 127668 Aug 4 1998 /usr/X11R6/bin/nxterm bobby:~% _

Сюидные программы используются в тех случаях, когда для выполнения некоей операции требуются права "root". В основном это требуется для авторизации и для доступа к неким файлам/ресурсам, недоступным обычному пользователю.

Примерами сюидных программ являются rlogin (права нужны для создания сокета с номером порта < 1024), passwd (для записи в файл /etc/passwd или для чтения/записи /etc/shadow), xterm/nxterm (для получения устройства виртуального терминала), x11amp (для получения realtime-приоритета).

Вообще говоря, в настоящее время сюидность считается одной из самых неудачных (или, по крайней мере, самых неудачно реализованных) концепций в UNIX®. Программ, которым реально требуется сюидность, не так уж много.

Замечание

Возникает вопрос: если сюидность -- неудачная концепция, то как же надо было делать? Ответ -- т.н. "capabilities", или отдельные права на выполнение отдельных операций (вместо "всемогущего" root). Концепция "capabilities" введена стандартом POSIX.1e и поддерживается в ядрах Linux начиная с 2.2. Документация на эту тему есть по адресу

http://www.kernel.org/pub/linux/libs/security/linux-privs/ зеркало в России -- http://www.ru.kernel.org/pub/linux/libs/security/linux-privs/

Одно из применений сюидности при взломе -- непосредственно после взлома создать root- сюидную программу, позволяющую интерактивно вводить команды (на эту роль хорошо подходит любой shell), или же запускающую shell с правами "root".

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

Как управлять атрибутом setuid

Поскольку атрибут setuid входит в права доступа файла, то для манипуляций с ним используется команда chmod. Для установки этого атрибута служит команда

chmod u+s файл

(избегайте этого!), а для удаления --

chmod u-s файл

Атрибут setgid отличается тем, что символ "s" отображается вместо "x" в правах доступа группы, а не владельца:

bobby:~% ls -l /usr/bin/man

-rwxr-sr-x 1 root man 31756 Sep 5 1998 /usr/bin/man bobby:~% _

Для его установки/удаления команде chmod указывается "g+s" и "g-s" соответственно.

Поиск сюидных программ

Для поиска имеющихся на диске сюидных программ используется команда find. Команда

find / -type f -perm -u+s

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

find / -type f '(' -perm -u+s -o -perm -g+s ')'

Чтобы сразу выдать листинг найденных файлов, подойдет команда

find / -type f '(' -perm -u+s -o -perm -g+s ')' -exec ls -ld '{}' ';'

Поиск сюидных программ следует выполнять, естественно, как пользователь "root".

Дистанционная регистрация сообщений

Система Syslog позволяет записывать журнальную информацию о процессах ядра и пользовательских процессах в файл, рассылать эту информацию группе пользователей или передавать на другой компьютер сети. Рассмотрите вопрос о выделении защищенного компьютера, который будет служить центральной регистрационной станцией и выдавать сообщения о нарушении защиты (регистрируются от имени средства auth) на старый матричный принтер. Скормите ему рулон бумаги. Это не позвоолит хакерам заметать следы путем перезаписи и удаления журнальных файлов.

Защищенные терминалы

Linux можно настроить так, чтобы пользователю root разрешалось регистрироваться в системе только с определенных, "защищенных" терминалов. Рекомендуется запрещать привилегированный вход в систему по таким каналам, как модемы и сетевые псевдотерминалы.

Защищенные каналы обычно задаются в виде списка TTY-устройств в файле/etc/securetty. Можно также назначить непривилегированным пользователям разрешенные для них терминалы (файл /etc/security/access.conf) и разрешенное время работы в системе (файл

/etc/security/time.conf).

Безопасность и NIS

Эти слова можно поставить рядом разве что в заголовке. NIS (Network Information Service — сетевая информационная служба) представляет собой разработанную компанией Sun систему распространения баз данных, которой многие организации пользуются для ведения и рассылки таких файлов, как /etc/group, /etc/passwd и /etc/hosts. К сожалению, ошибочна уже сама лежащая в основе этой системы идея "легкого доступа к информации", поэтому NIS является лакомым кусочком для хакеров. В пришедшей на смену NIS системе NIS+ сделана лишь робкая попытка устранить присущие NIS проблемы защиты информации, поэтому лучше вообще не использовать ни одну из версий этой системы.

Более безопасный и надежный способ рассылки указанных файлов — создать учетную

запись наподобие netadmin и помещать последние копии файлов в каталог ~netadmin. После этого на каждом клиентском компьютере необходимо с помощью демона cron периодически запускать сценарий, предназначенный для копирования (с помощью утилиты scp), проверки и инсталляции файлов. Утилита scp является частью пакета SSH.

В настоящее время в крупных сетях используются для централизованного управления досупом службы на базе Kerberos, LDAP и т.п.

Безопасность и NFS

NFS представляет собой удобное средство доступа к файлам по сети, потому является источником серьезным угроз для безопасности. Ее можно использовать в качестве тренажера для проверки брешей, существующих или когда-либо существовавших в UNIX®.

Изначально в NFS не были предусмотрены никакие средства защиты — такова цена, которую пользователи вынуждены были платить за удобство работы. К счастью, в Linux имеются средства защиты, позволяющие решить многие традиционные проблемы NFS. Доступ к томам NFS предоставляют записи файла /etc/exports. В нем перечислены сетевые имена (или IP-адреса) компьютеров, которым разрешен доступ к файловым системам сервера. Конечно, о должной степени безопасности говорить не приходится, так как сервер не проверяет подлинность клиентов. Подменить идентификаторы клиента не так уж сложно, поэтому доверять такому способу взаимодействия нельзя. Но меры предосторожности следует соблюдать в полном объеме: файловые системы должны экспортироваться только проверенным клиентам. Следите за тем, чтобы случайно не сделать файловую систему общедоступной.

Ограничить число узлов, которые имеют доступ к сетевым файловым системам, можно с помощью пакета TCP-оболочек. Мы рекомендуем отредактировать файл /etc/hosts.deny так, чтобы доступ к демону portmap был закрыт для всех. Если нужно ослабить ограничение для отдельных узлов или подсетей, редактируйте файл /etc/hosts.allow. В записях portmap этих файлов должны указываться только IP-адреса, поскольку для поиска сетевых имен может понадобиться доступ к демону portmap, вследствие чего возникнет цикл.

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

При наличии брандмауэра заблокируйте доступ к TCP- и UDP-портам 2049, которые используются протоколом NFS. Кроме того, необходимо перекрыть доступ к демону portmap, который обычно прослушивает TCP- и UDP-порты 111. За всеми этими предосторожностями не стоит также забывать правило, обычно подразумеваемое неявно: сетевые файловые системы не должны экспортироваться на нелокальные компьютеры.

С помощью команды showmount -е можно узнать, какие файловые системы экспортируются и кому именно, Для каждой экспортируемой файловой системы необходимо задать список управления доступом, все имена компьютеров в котором должны быть полностью определенными.

Безопасность и sendmail

Программа sendmail представляет собой целую сетевую систему, многие компоненты которой выполняются с правами суперпользователя. Вследствие этого она часто становилась мишенью для хакеров, и со временем в ней обнаружились многочисленные уязвимые места. Поэтому следует пользоваться только самой новой версией про-граммы. К выпуску очередных версий чаще всего приводят как раз проблемы безопасности так что ошибки, очевидно, есть во всех версиях sendmail, кроме самой последней (в ней они либо еще не обнаружены, либо скоро будут исправлены). Свежие новости можно узнать на Web-узле www. sendmail. org.

Безопасность и резервное копирование

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

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

Вирусы


Когда заходит речь о компьютерной безопасности, то первым делом вспоминаются вирусы. Принято говорить, что у Linux есть большое преимущество перед Dos/Windows: в Linux вирусов практически не существует.

Это не совсем так, вирусы как бы есть, но их почти никто не видел.

Основная причина этого заключается в ограничении прав доступа: в UNIX® у программ просто нет возможности писать что угодно, куда угодно и когда угодно, что является необходимым условием для существования и распространения вирусов. Даже если какой- нибудь пользователь случайно и подхватит некую "зловредную" программу, то обычно максимум, что она сможет сделать -- это испортить файлы самого пользователя, на операционную систему же это никак не повлияет.

Кроме того, хотя во многих UNIX® и существуют некоторые "дыры" в защите, разнообразие систем делает создание программ, использующих эти дыры, крайне трудоемкой задачей. Даже разные версии/дистрибутивы Linux на одной и той же платформе Intel x86 могут отличаться столь сильно, что "нехорошая" программа попросту зайдет в тупик и не сможет ничего сделать.

В принципе, в UNIX® могут существовать "черви" -- программы, самостоятельно распространяющиеся по сети и заражающие компьютеры. Однако их разработка является не менее трудоемкой задачей, и количество известных червей крайне мало.

Даже знаменитый "Червь Морриса", который в ноябре 1988 года поразил большое количество систем в США, заражал лишь компьютеры двух типов. В настоящее же время многообразие систем несравненно выше, а таких огромных дыр в защите, какие существовали в конце 80-х, практически не осталось. (Подробно почитать про Червь Морриса можно по адресу http://www.msnbc.com/news/209745.asp.)

Таким образом, большинство атак на UNIX®-системы производится не автоматическими средствами, а требует участия человека.

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

Троянские кони — это программы, назначение которых полностью противоречит тому, чего от них ожидают. В качестве примера можно привести программу turkey, которая когда-то распространялась в Usenet. Она обещала нарисовать на экране терминала индейку, а на самом деле удаляла файлы из начальных каталогов доверчивых пользователей.

Учитывая количество нападений, которые сообщество Linux пережило за последние годы, остается удивляться малому числу инцидентов с троянскими конями. По сути, нам неизвестен ни один задокументированный случай обнаружения программы, которая:



  • претендовала бы на полезное применение;

  • не распространялась как часть операционной системы;

  • предоставлялась в виде исходных текстов;

  • была широко распространена и при этом специально содержала злонамеренный код или умышленно обходила меха-низмы защиты операционной системы.

Таким положением вещей мы обязаны законопослушному сообществу пользователей Internet. Наиболее очевидные проблемы, связанные с безопасностью, быстро выявляются и широко обсуждаются. Злонамеренные программы не задерживаются на популярных серверах сети Internet. Можете быть уверены: любая программа, у авторов которой были нечистые намерения, будет выявлена и проанализирована в Internet. Если перед инсталляцией какой-нибудь программы нужно узнать ее "репутацию", просто введите имя программы в любимой поисковой системе.

Общие рекомендации по защите.

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

Физическая безопасность системы

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


  • поставить все security fixes от вендоров вашего дистрибутива

  • отключить все ненужные сервисы

  • проверьте как сервисы, запускаемые из (x)inetd так и standalone, запускаемые из

  • стартовых скриптов.

  • настроить syslogd для копирования важных сообщений на другую машину

Хранение копии файлов журналов на отдельной системе (доступ к которой, конечно, должен быть максимально ограничен) позволит иметь журнал, который не был изменен вломщиком, заметавшим следы, если взлом все-таки произошел. С другой стороны, syslogd обычно использует UDP для доставки сообщений, что не позволяет гарантировать, полноту журнала на протоколирующей системе. Кроме того, это открывает широкие возможности для спуфинга сообщений и DoS с целью переполнения файловой системы, где хранятся файлы журналов.

Таким образом, может оказаться необходимым рассмотреть модифицированные версии syslogd (например, syslog-ng), позволяющие использовать протокол tcp для доставки сообщений и позволяющие выполнять их электронную подпись. Это особенно важно, если сообщения доставляются через глобальные сети.

отказаться от использования протоколов с слабой авторизацией в первую очередь это относится к так называемым r-командам: rlogin, rsh, rcp - соответствующие сервисы следует отключить или заменить на аналоги с более стойкой аутентификацией (Kerberized или ssh). Если r-команды вам таки необходимы (например, для работы с cisco, которая ssh не понимает), используйте TCP Wrappers (man tcpd). Кроме того, не стоит применять без необходимости telnet, POP3, отключите так же plain-text аутентификацию в IMAP, либо туннелируйте эти протоколы в SSL.

производить проверку изменений файлов

Для дистрибутивов, основанных на RPM, частично помогает rpm -Va, однако лучше использовать специализированные программные пакеты, такие как Tripwire (http://www.tripwire.org/) или или Aide (http://www.cs.tut.fi/~rammer/aide.html). Применение такого ПО позволит своевременно обнаружить изменения в конфигурационных файлах или установку "троянских коней".

Использовать антивирусные программы и программы сканирования системы на предмет наличия rootkit (http://www.rootkit.nl, http://www.chkrootkit.org) .

произвести тотальный chroot для всех возможных сервисов

в первую очередь, это касается Apache (описание тут) и BIND (описание тут), если вы пользуетесь ими. Однако, я рекомендую вам помещать в chroot все ваши сервисы предоставляемые пользователям через Internet.

Модифицировать систему безопасности

документация и патчи OpenWall под стандартное ядро ищите на http://www.openwall.com/linux/, обратите внимание, что производитель вашего дистрибутива, возможно, уже включил этот патч в свое ядро. Так же очень интересными возможностями обладает GrSecurity, SELinux, AppArmor.

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

Постоянное наблюдение

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

Взломали! Что делать?

Во-первых, Don't panic! :) Не вы первый, не вы последний. Во-вторых, постарайтесь определить для себя, какие действия вы должны предпринять. В-третьих, записывайте все, что вы сделали - это поможет на досуге сесть, разобраться и сделать выводы.

Теперь подробней.

Идентифицируйте проблему

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

Традиционно, для сохранения контроля над взломанной системой, взломщики устанавливают т.н. rootkit - набор программ (и иногда - модулей ядра), которые скрывают факт взлома от системного администратора, обеспечивают доступ к системе, или позволяют расширить привелегии атакующего. Если у вас возникло подозрение, что в системе установлен rootkit, попробуйте проверить ОС с помощью chkrootkit. Так же проверьте целостность файлов с помощью Tripwire/Aide (см. так же п. 1.1).

Приступайте к решению проблемы

Не забудьте записывать все происходящее. Если вы решили понаблюдать за взломщиком, отдавайте себе отчет, что он может это обнаружить и постараться уничтожить все следы. Убедитесь, что он не использует ваши сервера как трамплин для новых атак. Будет очень неприятно оказаться вовлеченным в DDoS или обнаружить у себя склад эксплоитов или вареза (хотя, кому как, конечно :) ). Повторю прописную истину, что если вы следите за взломщиком командой, не надо пользоваться e-mail для координации своих действий. Если у вас нет желания и сил проводить расследование, переустановите OS с дистрибутива, восстановите данные из резервных копий (у вас ведь есть резервные копии? :) ) и перечитайте данный FAQ для повышения ее защищенности.

Заключение

Это очень краткое изложение основ безопасной эксплуатации систем Linux. Ограничиваться только этими знаниями будет опасной ошибкой. Изучение безопасности – сложный, долгий и кропотливый процесс. Дальнейшее изучение этой темы продолжится в рамках специального курса.


<< предыдущая страница   следующая страница >>
Смотрите также:
1 Изучение unix® (Linux) 5 1 Человеко-машинные системы 6
5003.83kb.
60 стр.
Различия между unix и Linux
110.44kb.
1 стр.
Особенности Linux
38.09kb.
1 стр.
RH253 Сетевые службы Red Hat Linux и администрирование безопасности Описание курса
45.49kb.
1 стр.
Unix-подобные операционные системы, характеристики, особенности, разновидности
40.07kb.
1 стр.
2. операционная система linux 2 Общая структура 2
1003.22kb.
9 стр.
Программы повышения квалификации ункит 8-10 «Администрирование unix(Linux/bsd) сервера»
10.61kb.
1 стр.
Экзаменационные вопросы с комментариями
13.34kb.
1 стр.
Вопросы к экзамену по дисциплине «Многопользовательские операционные системы»
14.61kb.
1 стр.
Практикум n 8 Изучение файловой системы оc unix по курсу «Операционные системы»
202.58kb.
1 стр.
Методические указания к лабораторной работе Сетевые утилиты в ос windows и unix/Linux. Тестирование стека tcp/ip рига 2004
146.22kb.
1 стр.
Интерфейс командной строки
206.87kb.
1 стр.