Войти
Безопасность Unix относится к средствам защиты a Unix или Unix-подобная операционная система. Безопасная среда достигается не только за счет концепции дизайна этих операционных систем, но и за счет бдительных действий пользователей и администраторов.
Основной функцией безопасности в этих системах являются разрешения файловой системы. Все файлы в типичной файловой системе Unix имеют набор разрешений, обеспечивающих различный доступ к файлу.
Права доступа к файлу обычно устанавливаются с помощью команды chmod и просматриваются с помощью команды ls. Например:
-r-xr-xr-x 1 root wheel 745720 8 сентября 2002 / bin / sh
Разрешения Unix разрешают доступ к файлу разным пользователям. Разные группы пользователей имеют разные права доступа к файлу.
Более продвинутые файловые системы Unix включают концепцию списка контроля доступа, которая позволяет предоставлять разрешения нескольким пользователям или группам. Список управления доступом может использоваться для предоставления разрешений дополнительным отдельным пользователям или группам. Например:
/ pvr [u :: rwx, g :: rx, o :: rx / u :: rwx, u: sue: rwx, g :: rx, m :: rwx, o: : rx]
В этом примере, который взят из команды в операционной системе Linux, пользователю sue предоставляется разрешение на запись в каталог / pvr.
Пользователи операционных систем в стиле Unix часто принадлежат к управляемым группам с определенными правами доступа. Это позволяет группировать пользователей по уровню доступа к этой системе. Многие реализации Unix добавляют дополнительный уровень безопасности, требуя, чтобы пользователь был членом группы пользовательских привилегий wheel для доступа к команде su. 101>
Большинство Unix и Unix-подобных систем имеют учетную запись или группу, которая позволяет пользователю получить полный контроль над системой, часто известную как учетная запись root. Если доступ к этой учетной записи получает нежелательный пользователь, это приводит к полному нарушению работы системы. Однако учетная запись root необходима для административных целей, и по вышеуказанным причинам безопасности учетная запись root редко используется для повседневных целей (чаще используется программа sudo ), поэтому использование учетной записи root может быть под более пристальным наблюдением.
Корневой доступ «как он должен быть» может быть визуализирован теми, кто знаком с историями о Супермене, используя следующую аналогию :
В Unix есть много инструментов, которые могут улучшить безопасность при правильном использовании пользователями и администраторами.
Выбор надежного пароля и его правильная защита, вероятно, самые важные вещи, которые пользователь может сделать для повышения безопасности Unix. В системах Unix основная информация о пользователях хранится в файле /etc/passwd . Этот файл отслеживает пользователей, зарегистрированных в системе, и их основные определения. Пароли, а точнее хеш пароля, тоже могут храниться там же. Записи в / etc / passwdзанимают ровно одну строку каждая и имеют следующий вид:
псевдоним: пароль_хеш: UserID: GroupID: Complete_Name: home_dir: shell_bin
Пример:
xfze: $$ 1zuW2nX3sslp3qJm9MYDdglEApAc36r /: 1000: 100: Даниэль Эрнесто Ортис Коста: / home / xfze: / bin / bash
Поскольку все пользователи должны иметь доступ для чтения к файл / etc / passwdдля выполнения многих общих задач (ls -l / homeбудет использовать / etc / passwd, например, для сопоставления UID с именами входа), любой может также прочитать хэши паролей других пользователей. Чтобы решить эту проблему, был создан файл /etc/shadow для хранения хэшей паролей, и только root имел доступ для чтения. При дублировании пароля второе поле (хэш пароля ) заменяется символом «x», который сообщает системе, что необходимо получить соответствующий пароль пользователя через файл / etc / shadow.
Файл / etc / shadowчасто содержит значения только для первых двух полей:
xfze: $$ 1zuW2nX3sslp3qJm9MYDdglEApAc36r / :::::
Остальные поля в файле / etc / shadowвключают:
Эти поля могут использоваться для повышения безопасности Unix путем применения политики безопасности паролей.
Администраторы должны немедленно удалить старые учетные записи.
Операционные системы, как и все программное обеспечение, могут содержать ошибки в нуждаются в исправлении или могут быть расширены за счет добавления новых функций. Безопасное исправление операционной системы требует, чтобы программное обеспечение было получено из надежного источника и не подвергалось изменениям с момента его упаковки. Общие методы проверки того, что исправления операционной системы не были изменены, включают использование криптографического хэша, такого как контрольная сумма на основе MD5, или использование носителей только для чтения.
С точки зрения безопасности, конкретный метод упаковки, такой как формат диспетчера пакетов RPM, первоначально из Red Hat Linux, не так важен, как использование функций, которые убедиться в целостности самой заплатки.
Исходные дистрибутивы включают возможность проверки кода на подозрительное содержимое. Недостаток, отсутствие сопутствующего криптографического хеш-значения, заключается в том, что пользователь должен иметь возможность самостоятельно выполнять анализ безопасности кода.
Дистрибутивы Linux, которые используют формат диспетчера пакетов RPM для обеспечения базовой функциональности и обновлений программного обеспечения, используют MD5 и GPG для обеспечения целостности содержимого. Хеш-значения упакованы в файл RPM и проверяются при установке пакета.
Linux Дистрибутивы, которые используют Debian формат пакета.deb для обеспечения базовой функциональности и обновлений программного обеспечения, используют GPG подписи для обеспечения целостности содержимого. Подпись вычисляется при создании пакета и проверяется позже при установке пакета.
Независимо от поставщика или распространения, все дистрибутивы программного обеспечения должны обеспечивать механизм проверки того, что программное обеспечение является законным и не было изменено с момента его первоначальной упаковки.
Ненужное системное программное обеспечение не следует устанавливать или настраивать в системе. Программное обеспечение, которое больше не требуется, следует по возможности полностью удалить.
Команды inetd и xinetd действуют как суперсерверы для различных сетевых протоколов, таких как rlogin, telnet и ftp.
Отключение ненужных служб
Этот подход обычно называется проактивной безопасностью. Есть некоторые операционные системы, которые по умолчанию защищены. Среди прочего, бесплатные варианты BSD (FreeBSD, NetBSD и OpenBSD ) являются проактивно безопасными. Например, вывод netstat на рабочей станции NetBSD 3.0 четко описывает эту технику:
$ netstat -a Активные Интернет-соединения (включая серверы) Proto Recv-Q Send-Q Локальный адрес Состояние внешнего адреса tcp 0 0 localhost.smtp *. * LISTEN tcp 0 0 *.ssh *. * LISTEN Активные соединения Internet6 (включая серверы) Proto Recv-Q Send-Q Локальный адрес Внешний адрес (состояние) tcp6 0 0 localhost.smtp *. * LISTEN tcp6 0 0 *.ssh *. * LISTEN Активные сокеты домена UNIX Адрес Тип Recv-Q Send-Q Inode Conn Refs Nextref Addr c0d10d80 dgram 0 0 0 c0cd8680 0 c0cb7000 ->/ var / run / log c0cb7000 dgram 0 0 0 c0cd8680 0 0 ->/ var / run / log c0cd8680 dgram 0 0 cb9639e8 0 c0d10d80 0 / var / run / log
Следующий пример из системы BSD
$ sockstat -4 КОМАНДА ПОЛЬЗОВАТЕЛЯ PID FD PROTO ЛОКАЛЬНЫЙ АДРЕС ИНОСТРАННЫЙ АДРЕС root sendmail 569 4 tcp localhost. smtp *. * root sshd 593 4 tcp *.ssh *. *
Показывает, что на этом компьютере только служба SSH прослушивает общедоступный сетевой интерфейс компьютера. sendmail прослушивает только интерфейс loopback . Доступ к службе можно дополнительно ограничить с помощью межсетевого экрана.
Безопасность файловой системы в UNIX и Unix-подобные системы основаны на 9 битах прав доступа, установочных битах идентификатора пользователя и группы и на липком бите , всего 12 бит. Эти разрешения применяются почти одинаково ко всем объектам файловой системы, таким как файлы, каталоги и устройства.
9 битов разрешения разделены на три группы по три бита в каждой. Первая группа описывает разрешения владельца файла, вторая группа описывает разрешения группы, связанной с владельцем файла или каталогом, содержащим файл, а третья группа описывает разрешения, связанные с любым процессом, у которого нет того же пользователя. ID как файла. Каждая группа из трех битов содержит бит, указывающий, что предоставлен доступ на чтение, запись или выполнение. В случае каталогов доступ на выполнение интерпретируется как разрешение на поиск имени файла в каталоге.
Установленные биты идентификатора пользователя и набора идентификаторов группы, обычно сокращенно обозначаемые как set-UID и set-GID, соответственно, используются для изменения идентификатора процесса, который выполняет файл с установленным одним или обоими этими битами. Файл с установленным битом разрешения set-UID заставит процесс, выполняющий этот файл, временно переключить эффективный идентификатор пользователя на идентификатор владельца файла. Файл с установленным битом разрешения set-GID заставит процесс, выполняющий этот файл, временно переключить эффективный идентификатор группы на идентификатор группы файлов. Затем процесс может чередовать эффективный идентификатор пользователя или группы, который он унаследовал из файла, и реальный идентификатор пользователя или группы, который он унаследовал, когда пользователь вошел в систему. Это обеспечивает механизм, с помощью которого процесс может ограничивать права доступа, которыми он обладает, теми областями кода, которые требуют этих прав доступа. Это форма техники безопасности, известная как разделение привилегий, которая улучшает безопасность программы за счет ограничения непреднамеренных или нежелательных действий процессов.
Каталог, имеющий установленный бит разрешения set-GID, приведет к тому, что вновь созданный файл будет иметь начальное значение группы файлов, равное группе файлов каталога. Это обеспечивает механизм, посредством которого подсистема, такая как почтовая подсистема системы, может создавать файлы, которые имеют общее значение группы файлов, так что процессы set-GID в этой подсистеме затем могут читать или записывать файл.
Бит залипания, формально известный как сохранение текста в битах подкачки, получил свое название от своей первоначальной цели. Первоначально липкий бит заставлял начальный образ памяти процесса сохраняться как непрерывный образ на диске, который использовался для хранения реальных страниц памяти, когда они не использовались. Это улучшило производительность часто выполняемых команд, сделав исходный образ памяти доступным. Современные системы UNIX больше не выполняют эту функцию, когда бит установлен, но, тем не менее, имя сохраняется. В случае файлов бит залипания может использоваться системой для указания стиля блокировки файла, который должен выполняться. В случае каталогов липкий бит предотвращает удаление файла в этом каталоге любым процессом, кроме того, который имеет привилегии суперпользователя или тот, у которого есть эффективный идентификатор пользователя владельца файла. Бит залипания чаще всего используется в общедоступных каталогах, таких как различные каталоги временного рабочего пространства в системе.
Root squash - это специальное отображение удаленного суперпользователя (root) при использовании (локальный пользователь совпадает с удаленным пользователем). В корневом сквоше клиентский uid 0 (root) отображается на 65534 (никто). Это в первую очередь функция NFS, но может быть доступна и в других системах.
Root squash - это метод аннулирования повышения привилегий на клиентском компьютере с помощью исполняемых файлов suid Setuid. Без корневого сквоша злоумышленник может сгенерировать на сервере двоичные файлы suid, которые будут выполняться от имени пользователя root на другом клиенте, даже если пользователь клиента не имеет привилегий суперпользователя. Следовательно, он защищает клиентские машины от других злонамеренных клиентов. Он не защищает клиентов от злонамеренного сервера (где root может генерировать двоичные файлы suid), а также не защищает файлы любого пользователя, кроме root (поскольку злонамеренные клиенты могут выдавать себя за любого пользователя).
SELinux - это набор расширений ядра для более точного управления доступом, строго определяющий, как и каким образом файлы, папки, сетевые порты и другие ресурсы могут быть доступны для ограниченного процесса. Эта система в основном используется для ограничения процессов (базы данных, сервера), а не пользователей. Он также может ограничивать процессы, выполняемые от имени пользователя root. В других дистрибутивах используются аналогичные альтернативы, такие как AppArmor.
Unix-подобные операционные системы невосприимчивы к большинству вирусов Microsoft Windows, поскольку двоичные файлы, созданные для работы в Windows, обычно не работают на других платформах.. Однако многие системы, подобные Unix, предоставляют клиентам Microsoft Windows услуги хранения файлов, например, с помощью программного обеспечения Samba, и могут непреднамеренно стать хранилищем вирусов, хранимых пользователями. Серверы Unix обычно действуют как агенты передачи почты ; как следствие; электронное сканирование на вирусы часто устанавливается. Сканер вирусов ClamAV доступен в виде исходного кода и может использоваться для сканирования файловых систем Unix на наличие вирусов, заражающих другие операционные системы.
Существуют вирусы и черви, нацеленные на Unix-подобные операционные системы. Фактически, первый компьютерный червь - червь Морриса - был нацелен на системы Unix.
Сетевой межсетевой экран защищает системы и сети от сетевых угроз, которые существуют на противоположной стороне межсетевого экрана. Брандмауэры могут блокировать доступ только к внутренним службам, нежелательным пользователям и в некоторых случаях фильтровать сетевой трафик по содержимому.
iptables - текущий пользовательский интерфейс для взаимодействия с функциями ядра Linux netfilter. Он заменил ipchains. Другие Unix подобные операционные системы могут предоставлять свои собственные встроенные функции, и существуют другие брандмауэры с открытым исходным кодом. Более подробная информация об iptables содержится в другом месте. Здесь содержится краткое обсуждение, чтобы описать, как iptables можно использовать для настройки межсетевого экрана Linux.
netfilter предоставляет фильтр пакетов с полным состоянием, который можно настроить в соответствии с сетевым интерфейсом, протоколом, адресом источника и / или получателя, порт источника и / или назначения и состояние пакета. Сетевой пакет проходит несколько цепочек между моментом его получения сетевым интерфейсом и моментом, когда он принят хостом или переадресован другому хосту. Общие цепочки: ВХОД, ВЫХОД и ВПЕРЕД . Цепочка INPUT просматривается для всех пакетов по мере их получения сетевым интерфейсом, независимо от того, должны ли они быть приняты хостом или перенаправлены на другой хост. Цепочка OUTPUT просматривается для всех пакетов, поскольку они передаются через сетевой интерфейс. Цепочка FORWARD проходит для тех пакетов, которые маршрутизируются через хост от одного сетевого интерфейса к другому, например, в случае многосетевой системы (системы с более чем одним физическим сетевым интерфейсом).
Каждая из встроенных цепочек имеет политику по умолчанию, которая определяет, какие действия предпринимаются для пакета, который достигает конца цепочки. Обход пакета заканчивается, когда правило соответствует пакету и имеет действие ACCEPT, DROP, REJECT или RETURN .
Самый простой Межсетевой экран iptables состоит из правил для каждой желаемой службы, за которыми следует правило, указывающее, что любые пакеты, достигающие этого правила, отбрасываются. Например, система, которая разрешает только входящий почтовый трафик, будет иметь правило, которое принимает соединения через порт SMTP, а затем отбрасывает другие. Требуется правило, указывающее, что все установленные соединения также разрешены, чтобы исходящие соединения получали ответы от других систем.
В следующем примере показан простой фильтр пакетов для цепочки INPUT для описанного выше примера:
Цепочка INPUT (policy DROP 0 пакетов, 0 байт) pkts bytes target prot opt in source destination 0 0 ACCEPT all - любой, где угодно, где угодно, состояние ESTABLISHED 0 0 ACCEPT tcp - любой, где угодно, где угодно tcp dpt: smtp 0 0 LOG all - любой, где угодно, где угодно, предупреждение уровня журнала 0 0 DROP all - любой, где угодно и где угодно
Добавление явного действия DROP гарантирует, что пакеты будут отброшены, если политика по умолчанию цепочки INPUT случайно будет изменено на ACCEPT .
В цепочке OUTPUT меньше необходимости, и политику по умолчанию для цепочки OUTPUT можно безопасно установить на ПРИНЯТЬ . В некоторых случаях может быть желательно, чтобы межсетевой экран ограничивал определенные исходящие соединения определенным набором утвержденных систем. Это известно как исходящая фильтрация и может использоваться для предотвращения проникновения вирусов в брандмауэре в другие системы. Например, политикой сети может быть ограничение исходящих подключений электронной почты к отдельным авторизованным серверам электронной почты как способ борьбы со спамом электронной почты. Это может быть достигнуто с помощью следующего примера:
ВЫВОД цепочки (policy ACCEPT) pkts bytes target prot opt in source destination 0 0 DROP tcp - любой любой! Сервер в любом месте tcp dpt: smtp
Нет необходимости включать какие-либо другие правила в этот пример, так как политика по умолчанию для цепочки OUTPUT - ACCEPT . Это правило предполагает, что хост, который действует как брандмауэр, не будет сам отправлять электронную почту, например, на почтовый сервер. Это хорошее предположение, поскольку обычно система межсетевого экрана содержит минимальный объем системного кода, необходимый для работы в качестве межсетевого экрана.
Более строгая цепочка OUTPUT будет содержать разрешающие (ACCEPT ) записи для тех служб, к которым можно получить доступ за пределами межсетевого экрана, а затем ограничительные (DROP ) политика для самой сети.
Безопасная сетевая связь:
Анализ пакетов :
Атаки:
 | В Викиучебниках есть книга по темам: Безопасность вычислений UNIX |
 | Викиверситет содержит обучающие ресурсы по безопасности Unix |
