Реферат Исследование уровня безопасности операционной системы Linux
Работа добавлена на сайт bukvasha.net: 2015-10-28Поможем написать учебную работу
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
от 25%
Подписываем
договор
Содержание
Введение............................................................................................... 8
1. Основные понятия компьютерной безопасности.... 10
2. Локальная и сетевая безопасность Linux..................... 15
2.1. Пользователи и пароли................................................................ 18
2.2. Особенности файловой системы Linux........................................ 24
2.2.1. Права доступа........................................................................ 24
2.2.2. Атрибуты файлов................................................................... 29
2.2.3. Механизм квот....................................................................... 33
2.3. Библиотека PAM.......................................................................... 36
2.4. Брандмауэр................................................................................... 48
2.5. Удаленное управление.................................................................. 57
3. Средства усиления безопасности в Linux..................... 63
3.1. Linux ACLs.................................................................................... 63
3.2. LIDS.............................................................................................. 65
3.3. AIDE............................................................................................. 71
4. Техника безопасности............................................................ 74
Заключение....................................................................................... 80
Список литературы...................................................................... 82
Приложение....................................................................................... 83
Введение
Постоянно растущий интерес к безопасности различных сетевых ОС, а в особенности к UNIX-подобным системам, как раз и побудил меня выбрать именно эту тему работы. Проблема информационной безопасности, начиная с момента появления необходимости в ней, постоянно тревожит умы сотни тысяч людей, заставляя их совершенствовать средства ее обеспечения. По проблемам безопасности информационных систем написано очень много книг и статей, каждый день выходят очерки, в которых сообщается о новых продуктах, совершенствовании существующих систем безопасности, описываются по шагам методы защиты от различных вторжений, методы устранения их последствий. Эта тема постоянно развивается, и интерес к ней никогда не угаснет. Проблема информационной безопасности будет актуальной до тех пор, пока существует информация, которую необходимо оградить от постороннего глаза.
Задачей данной работы является обзор средств как стандартных, так и не совсем, которые предоставляет операционная система Linux для безопасного функционирования, безопасной работы пользователей, а также сохранности конфиденциальной информации, для хранения которой эта ОС может использоваться. В работе затрагиваются не только вопросы, имеющие непосредственное отношение к безопасности ОС Linux. Поскольку Linux - сетевая ОС, и основным ее назначением является работа в сети, было бы неправильным не затронуть вопросы сетевой безопасности.
Работа поделена на четыре части: первая часть является теоретическим обзором основных терминов компьютерной безопасности; во второй части рассматриваются аспекты локальной и сетевой безопасности системы; третья часть является обзором дополнительных средств, предоставляемых разработчиками мира UNIX для контроля, регистрации и предотвращения угроз безопасности ОС Linux и четвертая часть представляет собой дополнительный раздел, в котором рассматривается техника безопасной работы с персональным компьютером и монитором.
1. Основные понятия компьютерной безопасности
У различных категорий людей слово «безопасность» вызывает свои ассоциации. Имеется множество разновидностей этого термина, которые связаны с различными сферами деятельности человека. Например, государственная безопасность или безопасность жизнедеятельности, политическая или строительная безопасность. Вообще таких разновидностей большое количество, в каждом случае к этому термину предъявляются специфические для конкретного рода деятельности требования, отличные от всех остальных. Обобщенное же определение термина «безопасность» можно сформулировать так: безопасность – это набор средств и требований, направленных на предотвращение запрещенных действий, выполнение которых может привести к нежелательным последствиям.
Термин «информационная безопасность» появился сравнительно недавно, с развитием вычислительной техники и ЭВМ. Информационная безопасность включает в себя кроме безопасности используемого программного обеспечения, также безопасность аппаратных средств, безопасность каналов связи и многое другое.
Под безопасностью же операционной системы понимается помимо безопасности самого ядра операционной системы еще и безопасность программного обеспечения, установленного на ней. Другими словами, безопасность операционной системы – это комплекс мер, направленных на предотвращение действий со стороны пользователя или других программ, которые могут привести к нарушению нормального функционирования операционной системы.
Если есть запрет, появится и человек, который попытается его нарушить! С развитием информационных технологий и внедрением компьютера практически во все сферы деятельности появились люди, так называемые «кракеры» (от англ. cracker – «взломщик компьютерных сетей и программ»), которые различными ухищрениями и нестандартными методами пытаются с целью собственной выгоды получить несанкционированный доступ к информации, которая для них не предназначена. Порой это приводит к плачевным последствиям для владельца этой информации. Тогда и возникла потребность в борьбе с «информационными вредителями». Были разработаны целые комплексы программ для усиления информационной безопасности и борьбы с кракерами. А поскольку любым электронно-вычислительным комплексом управляет определенная ОС, то, соответственно, для обеспечения безопасности системы в целом необходимо позаботиться о безопасности самой ОС.
Каждый производитель по-своему взглянул на безопасность своей ОС. В итоге одни системы оказались достаточно защищенными, защиту других обойти было не просто, а третьи оказались практически беззащитными перед взломщиками. Степень защищенности ОС Linux – еще одной UNIX-подобной ОС реального времени, рассматривается в этой работе.
Изучая безопасность ОС, нельзя не коснуться теории компьютерной безопасности. Теория компьютерной безопасности оперирует тремя основными понятиями: угроза, уязвимость и атака.
Угроза безопасности компьютерной системы – это потенциально возможное происшествие, которое может оказать нежелательное воздействие на саму систему (такое, как перезагрузка, зависание), а также на информацию, находящуюся в ней (удаление, порча файлов и так далее).
Уязвимость компьютерной системы – это такая неудачная или не совсем корректная ее характеристика, которая представляет возможным возникновение угрозы. Уязвимости как раз и являются причиной возникновения неприятных ситуаций.
К уязвимостям можно отнести следующие состояния информационных систем:
1. Несовершенство используемого программного обеспечения
Программное обеспечение написано человеком, а человек склонен допускать ошибки. При создании программного продукта проследить все связи и возможные ошибки практически невозможно, даже когда над проектом работает большое количество людей. Создатели программных продуктов стараются как можно лучше оптимизировать код программы и избавить его от ошибок, но, тем не менее, предусмотреть все возможные ситуации не представляется возможным. Иногда такие недоработки не несут никаких критических последствий для самой программы или данных, которыми она оперирует, но бывает, что они позволяют использовать программу в целях, отличных от тех, для которых она создавалась первоначально, иногда с очень серьезными последствиями (порча данных, например). Такие недоработки в программе обычно называют «дырами».
Еще существует такое понятие, как «люк». Люком называют специальные комбинации действий над программой, которые позволяют обойти некоторые этапы выполнения. Обычно люки используются программистами при разработке и тестировании программ с целью обхода уже проверенных блоков и в конце должны «закрываться», то есть программный код, отвечающий за люк, должен быть удален из готовой программы. Но то, что должно, делается не всегда. Программист попросту может забыть про люк, в результате люк остается в готовой программе и может представлять угрозу для правильного выполнения.
2. Неправильная настройка программного обеспечения
Безопасность системы во многом зависит от правильной настройки программного обеспечения, установленного в ней. За правильную настройку программ, установленных на пользовательском компьютере, отвечает сам пользователь компьютера (обычно, его владелец), за правильную настройку программ и сервисов, работающих на специализированном компьютере, обслуживающем запросы пользователей (сервере), отвечает администратор. В обоих случаях эти лица несут полную ответственность за сохранность данных и нормальное функционирование программ на обслуживаемом компьютере. От того, насколько правильно настроено то или иное программное обеспечение, может зависеть, получит злоумышленник доступ к компьютеру или нет.
Атака на компьютерную систему – это алгоритм действий, с помощью которых может быть осуществлен поиск уязвимостей и их использование с целью осуществления угрозы.
Существуют три основных вида угроз:
· Угрозы раскрытия
· Угрозы целостности
· Угрозы отказа в обслуживании
Угроза раскрытия заключается в том, что информация становится известной тому, кому не следовало бы ее знать. В терминах компьютерной безопасности угроза раскрытия имеет место всякий раз, когда получен доступ к некоторой конфиденциальной информации, хранящейся в вычислительной системе или передаваемой от одной системы к другой. Иногда вместо слова "раскрытие" используются термины "кража" или "утечка".
Угроза целостности включает в себя любое умышленное изменение (модификацию или даже удаление) данных, хранящихся в вычислительной системе или передаваемых из одной системы в другую. Обычно считается, что угрозе раскрытия подвержены в большей степени государственные структуры, а угрозе целостности - деловые или коммерческие.
Угроза отказа в обслуживании возникает всякий раз, когда в результате некоторых действий блокируется доступ к некоторому ресурсу вычислительной системы. Реально блокирование может быть постоянным, чтобы запрашиваемый ресурс никогда не был получен, или оно может вызвать только задержку запрашиваемого ресурса, достаточно долгую для того, чтобы он стал бесполезным. В таких случаях говорят, что ресурс исчерпан.
Вывод.
В этой главе был осуществлен обзор основных терминов компьютерной безопасности, рассмотрены такие понятия, как угроза безопасности, уязвимость системы, атака на систему, описаны основные виды атак.
2. Локальная и сетевая безопасность Linux
Linux является сетевой ОС, поэтому провести четкую границу между локальной и сетевой безопасностью очень сложно. Но, поскольку компьютер, на котором установлена ОС Linux, может выступать как в качестве пользовательского компьютера, так и в качестве сервера, подключение его к сети не гарантируется. При отсутствии сети неуместно говорить о сетевой безопасности, потому что сетевой угрозы в принципе не существует. Следовательно, разделение общей безопасности системы на две составляющие вполне целесообразно.
Учитывая все это, можно сделать вывод, что локальная безопасность является обязательной практически в любом случае, кроме тех, когда к компьютеру имеет доступ только один человек – его владелец. Сетевая же безопасность является актуальной только в том случае, когда компьютер с установленной на нем Linux имеет выход в сеть. Сетевая безопасность является дополняющим звеном локальной безопасности, которые вместе определяют общую безопасность системы в целом. В принципе, локальную безопасность можно считать последним барьером в общей безопасности системы.
Локальная безопасность – это правила, меры и усилия, направленные на защиту системы изнутри, от локальных пользователей.
ОС Linux является полноценной многопользовательской системой с простой и распределенной архитектурой. Архитектура ОС Linux приведена на рисунке 2.1.
Рис. 2.1. Структура операционной системы Linux
Linux является многопользовательской системой, и тот факт, что в систему могут иметь одновременный доступ огромное число людей, как доверенных, так и нет, представляется более чем очевидным.
Зачем же необходимо обезопасить систему от локальных пользователей?
Для ответа на этот вопрос сначала рассмотрим, что представляется возможным пользователю, который имеет доступ в систему.
- После входа в систему пользователю выделяется определенная часть машинных ресурсов (дискового пространства, оперативной памяти, процессорного времени и так далее). Хорошо, если ОС изначально настроена на правильное разделение ресурсов. А если нет? Достаточно одному пользователю запустить пару-тройку «тяжелых» программ, как время ожидания для других программ даже на мощной машине может выйти за грань допустимого.
- Существуют программы, которые должен запускать только суперпользователь (пользователь root). Обычно с помощью этих программ осуществляется настройка системных параметров операционной системы, неправильная конфигурация которых может отрицательно отразиться на ее работоспособности. Случайный запуск такой программы обычным пользователем может привести к фатальным последствиям для всей системы в целом.
- «Гуляя» по дереву каталогов на жестком диске, пользователь может попасть в ту часть, в которой ему быть не положено (например, в каталог, где хранятся файлы других пользователей). Личные файлы каждого пользователя должны быть доступны ему и только ему, если, конечно, он сам не решит иначе.
Перечисленные примеры – это лишь малая часть. Иногда, даже сам этого не осознавая, неопытный пользователь может представлять потенциальную угрозу, если ему предоставить неограниченные права. К тому же сама порядочность пользователя – это роскошь, которую в современном мире может себе позволить не каждый.
Теперь рассмотрим, какие же средства предоставляет система Linux для обеспечения локальной безопасности.
2.1. Пользователи и пароли
Пользователь – это человек, пользующийся ресурсами и возможностями, которые ему предоставляет тот или иной сервис. Пользователь не обязан знать все аспекты функционирования этих сервисов, все, что ему необходимо знать – это как пользоваться ими.
В Linux каждый пользователь имеет свой уникальный числовой идентификатор, по которому он идентифицируется в системе. Этому идентификатору для более удобной работы соответствует имя пользователя. Например, для привилегированного пользователя root зарезервирован нулевой идентификатор.
Все имена пользователей Linux и соответствующие им идентификаторы хранятся в специальном файле passwd. Этот файл располагается в каталоге etc, который, в свою очередь, находится в корневом каталоге системы /. Файл имеет обычную текстовую форму.
Пример файла пользовательских имен passwd.
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
Каждая запись в этом файле разделена двоеточиями на 7 частей:
1. Имя пользователя. Это поле содержит имя пользователя. Для операционной системы не важно, какое имя имеет пользователь, система ориентируется на идентификатор, а имя играет, пожалуй, только информационное значение для человека, работающего в системе.
2. Поле пароля. Это поле в ранних версиях Linux содержало зашифрованный пароль, а теперь, когда была введена технология теневых паролей, в этом поле просто ставится x. Практического применения это поле не имеет.
3. Идентификатор пользователя (UID). В системе Linux каждый пользователь имеет уникальный идентификационный номер, который однозначно определяет его в системе. Этот номер используется в различных целях, например, при установке прав доступа на файлы. Права доступа будут рассмотрены в следующем разделе.
4. Идентификатор группы, к которой принадлежит этот пользователь (GID). Концепция групп будет рассмотрена в следующих разделах.
5. Поле комментария. В этом поле может храниться любая дополнительная информация о пользователе, например, его полное имя.
6. Полный путь к домашнему каталогу пользователя. В ОС Linux для каждого пользователя создается его домашний каталог, в котором он может хранить свои документы. Обычно эти каталоги располагаются в директории /home корневого каталога и по умолчанию имеют имена владельцев.
7. Путь к командной оболочке. Последнее поле содержит полный путь к рабочей оболочке пользователя (по умолчанию такой оболочкой является bash). Эта оболочка запускается, когда пользователь проходит процедуру аутентификации. В целях безопасности для системных пользователей в этом поле очень часто ставится /sbin/nologin. В приведенном примере пользователь bin имеет как раз такое значение в поле командного интерпретатора. Сама по себе программа nologin не является оболочкой, единственное ее назначение – не допустить вход в систему. Поэтому при попытке входа под именем пользователя, у которого в качестве рабочей оболочки установлена /sbin/nologin, ничего не происходит. Обычно такой подход используется при создании пользователей, которые являются системными, то есть от имени которых выполняются какие-то действия внутри системы. А поскольку таким пользователям не нужна рабочая оболочка, хорошим решением, с точки зрения безопасности, будет установка поля оболочки в /sbin/nologin. Еще одним распространенным решением в таких ситуациях является установка этого поля в значение /bin/false. Как известно, в Linux, да и в большинстве других операционных систем, успешное завершение программы определяется типом возвращаемого значения. Если возвращается нулевое значение, выполнение программы прошло успешно, если ненулевое – в процессе выполнения программы возникли ошибки. На основе возвращаемого значения система аутентификации делает вывод о том, пройдена ли аутентификация успешно или она «провалилась». false – программа, которая независимо от внешних факторов всегда возвращает значение, отличное от нуля, что в данном случае означает возникновение ошибок при запуске оболочки, и управление снова возвращается системе аутентификации.
При входе в систему программа, предоставляющая доступ, производит чтение информации о пользователях как раз из файла passwd. Право на запись в этот файл имеет только привилегированный пользователь root, читать же его могут все пользователи системы (права доступа описываются в разделе «Особенности файловой системы Linux»).
Этот файл никогда не редактируется вручную, хотя, в принципе, это вполне допустимо. Обычно для редактирования файла пользователей используют специальные программы: useradd, usermod и userdel.
Программа добавления useradd позволяет добавить нового пользователя в систему. Для управления процессом создания пользователя эта программа может принимать различные параметры в командной строке. Например, параметр –s задает используемый пользователем shell, а параметр –g – группу, к которой принадлежит создаваемый пользователь. Помимо добавления записи о пользователе в файл /etc/passwd, программа useradd создает домашний каталог пользователя, который по умолчанию должен размещаться в директории /home. Путь к пользовательскому каталогу может быть определен с помощью параметра –d, за которым следует полный путь от корневого каталога до каталога пользователя.
Программа usermod позволяет изменять такие параметры, как рабочая оболочка пользователя, домашний каталог, группа, идентификатор пользователя и так далее.
Нетрудно догадаться, что выполняет программа userdel. Она удаляет пользователя из системы. Подробная информация об этих программах содержится в соответствующих man-руководствах.
Имя пользователя не является секретной информацией, и его могут без проблем узнать другие пользователи системы. Но в таком случае должна существовать опасность входа одного пользователя под именем другого. Однако этого не происходит. Используется такое понятие, как аутентификация.
Аутентификация – это установление подлинности пользователя, то есть установление факта того, что пользователь с таким именем является именно тем, за кого себя выдает.
Для аутентификации в ОС Linux используется уже давно проверенное и доказавшее свою надежность средство – пароль.
Пароль – это набор символов (секретное слово), известный только его владельцу и используемый для удостоверения его подлинности.
Каждый пользователь в системе имеет свой собственный пароль. Наличие пароля – необходимая составляющая политики безопасности пользователей Linux. Пароль является как бы пропуском пользователя в систему. Без пароля, зная только имя пользователя, проникнуть в систему невозможно.
Пароли хранятся в отдельном файле /etc/shadow. В ранних версиях Linux имена и пароли пользователей хранились в одном файле /etc/passwd. Но практика показала, что для обеспечения более надежной защиты паролей необходимо создание отдельного файла для их хранения. Таким образом, технология выделения отдельного файла shadow для хранения паролей получила название технологии «теневых паролей».
Пример файла и его структура приведены ниже.
root:$1$pOy8fNrf$uOh/dQlI03BMIdEAhWrE.0:12369:0:99999:7:::
bin:*:12245:0:99999:7:::
daemon:*:12245:0:99999:7:::
sync:*:12245:0:99999:7:::
Файл shadow, как и файл passwd, разделен на несколько частей двоеточиями:
1. Имя пользователя. Это поле просто дублируется из файла passwd.
2. Хэш пароля. Пароль в Linux никогда не хранится в открытом виде, в отличие от имени пользователя. При установке пароля до сохранения его в файле он шифруется по специальному алгоритму. По умолчанию таким алгоритмом является алгоритм одностороннего шифрования DES (Data Encryption Standard). Использование одностороннего алгоритма шифрования исключает возможность расшифровки пароля.
Остальные поля содержат различную служебную информацию.
Файл паролей имеет права только на чтение и только для суперпользователя (права доступа описываются в разделе «Особенности файловой системы Linux»). Его содержимое является недоступным для рядовых пользователей, таким образом, исключается возможность раскрытия зашифрованного пароля.
Для изменения пароля в Linux изначально включена специальная программа passwd. В качестве параметра в командной строке она получает имя пользователя и при запуске требует ввода пароля для этого пользователя. При вводе в целях безопасности пароль не отображается на экране монитора, существует очень высокая вероятность допустить ошибку, особенно когда пароль состоит из цифр и символов различного регистра. Поэтому ввод пароля осуществляется 2 раза для проверки правильности ввода. После подтверждения пароль шифруется и сохраняется в файле /etc/shadow.
При входе в систему процедурой получения имени и пароля пользователя управляет программа mingetty. mingetty – это программа, выдающая приглашение для ввода имени пользователя и пароля на виртуальную консоль. После ее запуска на экране монитора появляется строка-приглашение ко вводу имени и пароля пользователя. После ввода имени и пароля программа передает управление программе login. login – это программа-посредник, которая осуществляет проверку существования, корректности и соответствия имени пользователя и его пароля в системе. Пароль с помощью механизмов аутентификации шифруется и сравнивается с хэшем из файла. После успешного завершения процедуры аутентификации программа login запускает системную оболочку для взаимодействия пользователя с операционной системой, так называемый shell (от англ. shell – «оболочка»). Путь к исполняемому файлу shell указывается в последнем седьмом поле записи файла passwd. Обычно по умолчанию используется bash (Bourne Shell). Выдается приглашение ко вводу команд с символом # или $ в конце (по умолчанию символ # используется в приглашении суперпользователя, а символ $ - в приглашении обычного пользователя). С этого момента система готова принимать от пользователя команды на выполнение.
Для более удобного управления доступом к ресурсам в Linux все пользователи объединяются в группы. В данном случае группа – это множество пользователей, объединенных по каким-либо критериям.
К какой группе принадлежит пользователь, говорит 4 поле регистрационной записи в файле passwd. Наличие групп позволяет создать гибкую политику безопасности, основанную на разделении доступа к ресурсам. Значение групп для разделения доступа более подробно описывается в разделе «Особенности файловой системы Linux».
Практическое применение рассмотренной информации приводится в приложении в примере 1.
2.2. Особенности файловой системы Linux
Для организации и постоянного хранения информации на различных ее носителях ОС использует так называемую файловую систему.
Файловая система – это методы и структуры данных, которые используются ОС для хранения файлов на диске или в его разделе.
У каждой ОС имеется своя файловая система, отличная от всех других. От надежности, эффективности и безопасности работы файловой системы во многом зависит качество функционирования ОС в целом.
В настоящее время во всех дистрибутивах ОС Linux для хранения информации активно используется файловая система ext2 (The Second Extended File System). Ext2 является файловой системой с богатыми функциональными возможностями, а тот факт, что ext2 была разработана специально для Linux, уже говорит о необходимости присутствия в ней средств контроля и безопасности.
Основные характеристики файловой системы ext2:максимальный объем файловой системы – 4 Тбайт; максимальная длина файла – 2 Гбайт; максимальная длина имени файла – 255 символов; присутствует поддержка трех ячеек времени изменения файла; также имеется возможность расширения файловой системы; присутствуют механизмы защиты информации и возможность изменять размер блока.
2.2.1. Права доступа
Рассмотрим ситуацию, когда пользователь А для хранения очень важных документов использует свой домашний каталог. Информация, хранящаяся в документах, является строго конфиденциальной, а по сему никто, кроме ее владельца, не должен получить к ней доступ. Пользователь В просто из любопытства, а может и со злобными намерениями, сделал попытку получить содержимое этих документов. Результатом попытки явилась ошибка с описанием ‘permission denied’ (‘доступ запрещен’). Появлением ошибки послужило отсутствие у пользователя B прав на чтение документов, принадлежащих пользователю А. Из приведенного примера можно сделать вывод, что права доступа позволяют ограничить доступ к определенной информации, или, проще говоря, оградить некоторую информацию от определенных пользователей.
Концепция файловой политики безопасности Linux строится на том, что любой файл системы имеет 3 категории владельцев: собственно владельца файла или, проще говоря, его создателя, какую-либо группу пользователей, в которую чаще всего входит владелец файла, и всех остальных. Таким образом, привилегированный пользователь или владелец файла, поскольку только он имеют возможность изменять права доступа, может построить политику файловой безопасности, определяя права отдельно для владельца файла, для группы пользователей и для всех остальных пользователей системы.
Права доступа к файлу или каталогу описываются тремя восьмеричными цифрами, самая левая из которых – права доступа владельца, средняя – права группы, правая – права доступа для всех остальных. Каждая из этих восьмеричных цифр представляет собой битовую маску из 3-х бит. Эти биты отвечают за право на чтение, запись и исполнение файла или каталога. Если бит установлен в 1 – операция разрешена, если в 0 – запрещена.
Для различных типов файлов значения прав доступа немного отличаются.
Право на чтение файла позволяет пользователю читать содержимое файла. Для каталога установка права на чтение позволяет читать файлы, находящиеся в этом каталоге.
Право на запись файла позволяет пользователю изменять его содержимое. Для каталога - создавать файлы внутри каталога.
Право на выполнение для файла позволяет запускать файл на выполнение в качестве программы. Для каталога установка этого права дает возможность пользователю входить в каталог и просматривать его содержимое.
Какие права доступа определены для каждого файла, можно узнать, набрав в терминале команду ls с ключом –l:
[root@app tmpdir]# ls –l
lrwxrwxrwx 1 root users 86 Фев 7 19:49 linkfile -> myfile
drwxr-xr-x 1 root users 4096 Фев 7 19:49 lnk
-rwxr----- 1 anotheruser users 97 Фев 7 19:48 myfile1
-rw-rw-r-- 1 root users 84 Фев 7 19:45 myfile2
В первой колонке представлены права доступа к файлу. Эта колонка содержит 10 символов. Первый из них слева говорит о том, к какому типу принадлежит файл, то есть является ли он файлом, каталогом, ссылкой и так далее. Далее слева направо представлены права доступа соответственно для владельца, для группы, и в конце – для всех остальных. Вторая колонка отображает количество жестких ссылок для этого файла. Третья указывает на имя владельца файла, четвертая – на имя группы-владельца, пятая колонка – размер файла, шестая – дата создания файла, седьмая - имя файла.
Как видно из примера, linkfile является символической ссылкой на файл myfile. Об этом говорит буква l в самой левой части колонки прав доступа. Для символических ссылок задание прав доступа возможно, но вряд ли имеет смысл. Дело в том, что символическая ссылка указывает на файл, который имеет свои права доступа, поэтому при доступе по символической ссылке проверяются права конечного файла. Файл lnk является каталогом, о чем говорит буква d в поле прав доступа. Поле владельца говорит о том, что владельцем каталога является пользователь root, а группа-владелец – users. Владелец имеет право на чтение файлов в каталоге, запись файлов и чтение содержимого каталога. Буква r (от слова Read) говорит о возможности для данного пользователя выполнять операции чтения файлов каталога, буква w (от слова Write) – о возможности записи файлов в каталог, последняя буква x (от слова eXecute) дает право на просмотр содержимого каталога. Пользователи, входящие в группу users, имеют право только на чтение файлов этого каталога и на получение его содержимого (буквы r и x), право на запись файлов в этот каталог у них отсутствует. Все остальные пользователи имеют те же права доступа, что и группа-владелец. Последние два файла myfile1 и myfile2 являются обычными файлами. Файл myfile2 имеет права чтения и записи для владельца (пользователя root) и группы users, все остальные имеют право только читать файл. Файл myfile1 имеет права на чтение, запись и выполнение для владельца, коим в данном случае является пользователь anotheruser. Группа users имеет право только на чтение этого файла, а все остальные пользователи вообще не могут выполнять какие-либо действия с этим файлом.
Изменение прав доступа к файлу осуществляется при помощи стандартной системной команды chmod. Права доступа при вызове команды могут задаваться как битовой маской в десятичном представлении, так и при помощи символов. Подробно использование этой команды описано на соответствующей man-странице.
Помимо прав доступа существуют так называемые модификаторы доступа. К модификаторам доступа относятся Sticky bit, SUID и SGID.
Sticky
bit (
S). Для файлов установка этого модификатора в современных дистрибутивах потеряла свое значение. Установка Sticky bit для каталога позволяет пользователю записывать файлы в этот каталог, но удалять из этого каталога он может только те файлы, владельцем которых он является, или в том случае, если ему явно заданы права записи.
SUID (
s). Если файлу установлен модификатор доступа SUID и файл исполняемый, то файл при запуске на выполнение получает не права пользователя, запустившего его, а права владельца файла. Такие приемы используются для того, чтобы пользователь мог работать с некоторыми системными файлами, владельцем которых является привилегированный пользователь. К примеру, для того, чтобы пользователь мог самостоятельно изменить свой пароль при помощи программы passwd, у этой программы, владельцем которой является пользователь root, должен быть установлен бит SUID, поскольку она работает с файлом shadow, модификацию которого имеет право производить только пользователь root.
SGID (
s). Если файл имеет модификатор доступа SGID, то это аналогично установке бита SUID, только вместо владельца файла используется группа, которой принадлежит файл. В случае установки SGID для каталога файлы, содержащиеся в этом каталоге, будут иметь установки группы такие же, как у каталога.
[root@app mydir]# ls –l
-rwsr--r-x 1 anotheruser users 97 Фев 7 19:48 myfile1
В приведенном примере видно, что файл myfile1 имеет установленный бит SUID. При запуске файла любым пользователем системы (права на выполнение установлены для всех) файл будет выполнять действия от имени его владельца, в данном случае от имени пользователя anotheruser.
Модификаторы доступа при правильном использовании представляют очень мощное и гибкое средство. С другой стороны, неправильная настройка системы с использованием этих модификаторов может свести все действия по обеспечению безопасности к нулю. Особенно опасной представляется ситуация, когда тот же SUID установлен на исполняемый файл, принадлежащий привилегированному пользователю. При выполнении файла запустивший его пользователь получает право выполнять операции, доступные только пользователю root. Если даже файл не выполняет никаких системных операций и не работает с системными файлами, неправильное его использование может привести к очень неприятным последствиям.
Практическое применение рассмотренной информации приводится в приложении в примере 2.
2.2.2. Атрибуты файлов
В файловой структуре операционной системы всегда есть файлы, которые не должны изменяться в процессе функционирования системы, например, исполняемые файлы или файлы, которые должны быть откорректированы только однажды при настройке системы и не должны изменяться впоследствии, примером могут служить конфигурационные файлы. Есть и такие, которые могут быть дополнены, но не могут быть удалены или перезаписаны. Наличие средств, гарантирующих выполнение перечисленных условий, позволяет очень сильно повысить безопасность файловой системы, сохранив первоначальную целостность данных при различных типах атак.
Начиная с версии ядра 1.1, в файловой системе Linux помимо прав доступа присутствует поддержка расширенных атрибутов файлов. В последних версиях ядра 2.4 присутствует поддержка следующих атрибутов:
· Atime (
A). Каждый раз, когда система обращается к файлу, происходит изменение ячейки времени последнего обращения к файлу. Установка атрибута atime позволяет избежать обновления времени последнего обращения и увеличить производительность файловой системы, особенно в тех случаях, когда обращения к файлам происходят очень часто. Однако, отсутствие времени последней модификации файла представляет угрозу изменения файла без последующей регистрации этого действия, что может угрожать безопасности.
· Sync (
S). Установка атрибута sync позволяет сразу фиксировать все изменения, происходящие с файлом, на жестком диске синхронно с процессом, который осуществляет эти изменения. Это обеспечивает более безопасную работу, но может также снизить производительность из-за прямой постоянной записи на диск.
· Append (
a). Этот атрибут позволяет открывать файл только с целью его дополнения. Усечение или перезапись файла запрещается. Для каталога установка этого атрибута означает, что удалять файлы, содержащиеся в этом каталоге, запрещено, хотя создание новых и модификация существующих возможны.
· Immutable (
i). Файл с установленным атрибутом immutable не может подвергаться никаким изменениям вообще. Если установить этот атрибут для каталога, процессы смогут модифицировать файлы, находящиеся в нем, но не смогут создавать или удалять файлы. Для обеспечения безопасности имеет большое значение.
· No
Dump (
d). Установка атрибута no dump дает указание процессу, осуществляющему создание дампа, игнорировать этот файл и не включать его в создание резервной копии.
· Compress (
c). Этот атрибут позволяет производить прозрачное сжатие файлов перед записью их на диск. При доступе к файлу он декомпрессируется и конечному процессу представляется уже в нормальном виде.
· Secure
Deletion (
s). Если этот атрибут установлен, то при удалении файла все блоки, в которых он располагался, заполняются нулями, то есть производится полное удаление файла, а не только его дескриптора.
· Undelete (
u). При удалении файла с этим атрибутом система сохраняет все блоки файла на диске, что позволяет при желании восстановить удаленный файл.
Последние версии ядер, начиная с 2.4, игнорируют значения последних трех атрибутов: compress, secure deletion и undelete. Разработчики посчитали, что их дальнейшее использование не имеет смысла.
Для изменения и просмотра установленных атрибутов в стандартный системный пакет Linux входят две программы chattr и lsattr. Первая позволяет изменять атрибуты, добавлять или снимать их, вторая позволяет получить список установленных атрибутов. Пример работы программы lsattr показан ниже.
[root@app tmpdir]# lsattr myfile*
---i---------- myfile
----a--------- myfile1
В примере первый файл имеет установленный атрибут immutable, второй – атрибут atime. Подробно использование программ lsattr и chattr описывается в соответствующих man-руководствах.
При определенных условиях процессы, выполняемые от имени привилегированного пользователя, могут игнорировать эти атрибуты. С другой стороны, атрибуты ext2 учитываются некоторыми системными вызовами, такими как sys_open() для открытия файла или sys_truncate() для его отсечения, причем вне зависимости от идентификатора пользователя, вызываемого их процесса и прочих условий. Например, присутствие флага immutable в дескрипторе файла приводит к тому, что системные вызовы, касающиеся модификации файлов, просто перестают работать вне зависимости от других условий. Наличие данных атрибутов и специальных режимов работы ядра в Linux позволяет просто и эффективно укрощать абсолютные возможности, которыми обладает привилегированный пользователь. Цель комплексной настройки заключается в том, чтобы атрибуты накладывали ограничения для всех процессов независимо от их прав доступа и уровня привилегий. Они могут служить в качестве эффективной низкоуровневой защиты против атак на любой привилегированный процесс, в котором могут присутствовать какие-либо неизвестные уязвимости.
Однако, сама политика безопасности, построенная на установке атрибутов типа immutable и append, является только одной стороной монеты. Хотя эти атрибуты и предотвратят изменение защищенных ими файлов даже со стороны процессов, которые выполняются от имени привилегированного пользователя, в обычных обстоятельствах пользователь root все равно может убрать эти флаги и продолжить работу с файлами уже без этих атрибутов. Другими словами, ничто не мешает программе, исполняемой от имени пользователя root, перед началом работы выполнить проверку файла на наличие этих атрибутов и просто их отменить.
Дополняющим компонентом, или второй стороной монеты, можно считать специальные возможности ядер 2.4, позволяющие конфигурировать систему в режиме полной защиты файлов с атрибутами immutable и append до момента перезагрузки в однопользовательский режим. Для установки этих и множества других параметров ядра используется программа lcap (Linux Kernel Capabilities Bounding Set Editor).
Пример использования lcap
[root@app /]# lcap CAP_LINUX_IMMUTABLE
[root@app /]# lcap CAP_SYS_RAWIO
Первый вызов lcap с параметром CAP_LINUX_IMMUTABLE отменяет возможность у привилегированных процессов снимать флаги immutable и append. Второй вызов с параметром CAP_SYS_RAWIO запрещает низкоуровневый доступ к блочным устройствам, таким как диски, для предотвращения прямого доступа к файлам.
После того, как с помощью lcap был изменен какой-либо параметр ядра, его повторное изменение возможно только после перезагрузки системы. Эта особенность дает уверенность в том, что в системе не смогут незаметно производиться изменения без получения физического доступа и перезагрузки в однопользовательский режим.
Подробную документацию по программе lcap можно найти в соответствующих man-руководствах.
Практическое применение рассмотренной информации приводится в приложении в примере 3.
2.2.3. Механизм квот
Пожалуй, каждый администратор многопользовательской системы знаком с понятием «дисковой квоты». Попробуем разобраться, что же это такое, и какое отношение это понятие имеет к безопасности системы.
Дисковая квота – заранее определенное, фиксированное количество блоков дискового пространства и/или количество файловых дескрипторов, выделяемое каждому пользователю или группе пользователей для работы и хранения данных.
Использование дисковых квот позволяет ограничивать два аспекта дискового пространства: количество файловых дескрипторов, другими словами, количество файлов, которое может быть создано пользователем или группой пользователей, и часть от всего объема диска, которую может использовать пользователь или группа для хранения своих файлов. Идея состоит в том, чтобы определить для каждого пользователя или группы определенную часть от общего объема диска, чтобы ни при каких условиях пользователь не смог превысить тот объем используемой дисковой памяти, который ему выделен. Таким образом, устраняется проблема переполнения диска или нехватки дискового пространства для других пользователей и процессов.
Концепция разделения дискового пространства оперирует тремя понятиями: мягкое ограничение (soft limit), жесткое ограничение (hard limit) и период отсрочки (grace period).
Мягкое ограничение определяет максимальный размер дискового пространства, который может быть занят данными определенного пользователя или группы пользователей.
Ж
есткое ограничение работает, только если установлен период отсрочки grace period.
Если период отсрочки установлен в значение, отличное от нуля, то, когда занятый объем превышает объем мягкого ограничения, пользователю выдается сообщение, что его дисковое пространство на исходе. Если пользователь игнорирует это предупреждение и его дисковая квота продолжает превышать значение мягкого ограничения, то по истечении периода отсрочки дисковая квота считается исчерпанной. При этом обязательно должно быть установлено жесткое ограничение. Жесткое ограничение является абсолютным максимумом использования пространства файловой системы пользователем.
Управление механизмом квот осуществляет ядро операционной системы. В последних версиях Linux в стандартное ядро, идущее в дистрибутиве, поддержка квот включена по умолчанию. Если же производится сборка нового ядра, поддержку квот необходимо включить явно. Включение поддержки механизма квот осуществляется установкой параметра Quota Support (CONFIG_QUOTA) в разделе FileSystems при конфигурировании ядра до процесса сборки. Если такого параметра в ядре нет, это означает, что данная версия ядра не поддерживает механизм квот. В этом случае для поддержки квот на ядро необходимо наложить «заплатку» - специальное дополнение в стандартный код ядра. Заплатку можно загрузить с Интернета.
Поддержка квот распространяется на логический раздел диска и указывается при его монтировании. Для монтирования раздела используется файл /etc/fstab, в котором и задаются параметры, указывающие на использование квот. Это параметры usrquota и grpquota.
Для управления и настройки дисковых квот используется пакет quota. В современных дистрибутивах Linux этот пакет входит в стандартную поставку, но можно загрузить последнюю версию с Интернета.
На момент написания работы последней стабильной версией пакета quota была версия 3.11. Далее перечислены основные программы пакета quota-3.11, необходимые для настройки механизма квот:
quota – программа позволяет отображать текущее состояние механизма квот. По умолчанию отображается только квота пользователя, запустившего программу на выполнение. Эту программу может запускать любой пользователь системы.
convertquota – программа производит перевод файлов quota.user и quota.group в файлы aquota.user и aquota.group. Файлы quota.user и quota.group являются файлами пользовательских квот старого формата. Начиная с версии ядра 2.4.0, в Linux используется новый формат дисковых квот, который обладает, в отличие от старой версии, следующими преимуществами:
- поддержка 32-битных идентификаторов пользователей (UID);
- установка квоты для привилегированного пользователя;
- установка дисковой квоты в байтах (в старой версии единицей дисковой квоты служил килобайт);
- поддержка дисковой квоты для журналируемой файловой системы ReiserFS.
Для настройки новой версии механизма квот используются файлы aquota.user и aquota.group. Проще говоря, программа convertquota позволяет перевести файлы настройки квот из старого формата в новый, тем самым позволяя перейти к использованию новой версии с минимальной перенастройкой системы.
edquota – программа является редактором пользовательских квот. При вызове этой программы запускается текстовый редактор, установленный по умолчанию в системе. В этом редакторе можно сделать необходимые изменения в файле дисковой квоты.
qout – программа выводит статистику в килобайтах по пользовательским квотам для конкретной файловой системы. На момент написания работы программа quot, входящая в пакет версии 3.11, поддерживала только файловую системы XFS.
quotacheck – программа для проверки целостности дисковой квоты. При интенсивной работе механизма квот в файловой системе могут возникать различные неточности, связанные с использованием дискового пространства пользователей. Программа quotacheck проводит проверку файловой системы, определяя размер доступного и занятого пространства, производит построение таблицы текущего использования дискового пространства и сравнивает полученные данные с записями в файле дисковой квоты. Если имеются какие-то несоответствия, эти несоответствия устраняются путем исправления неверных значений в файлах дисковой квоты.
quotaon – программа для включения пользовательских квот на указанной файловой системе. До использования этой программы необходимо для требуемой файловой системы установить параметр usrquota и/или grpquota в файле /etc/fstab.
quotaoff – программа для выключения пользовательских квот на указанной файловой системе.
repquota – программа для вывода статистики по использованию дискового пространства для указанной файловой системы.
setquota – программа для редактирования пользовательских квот в режиме командной строки.
warnquota – программа для информирования пользователей о том, что их дисковое пространство на исходе. Информирование происходит путем посылки предупреждающего сообщения по электронной почте.
Более подробная информация о программах пакета quota может быть получена из соответствующих man-руководств.
Практическое применение рассмотренной информации приводится в приложении в примере 4.
2.3. Библиотека PAM
PAM (Pluggable Authentication Modules) – подгружаемые модули аутентификации. PAM является набором динамически подключаемых модулей, с помощью которых привилегированный пользователь может выбирать, как приложение должно осуществлять процесс аутентификации. Такая технология оказалась очень полезна, особенно при появлении различных методов аутентификации пользователя в системе. Эта технология имеет два основных преимущества. Первым преимуществом является модульность приложений, поддерживающих PAM. Это означает, что для приложения, поддерживающего PAM, появляется возможность изменить механизм аутентификации пользователей без перекомпиляции программы, как говорят «на ходу», достаточно изменить конфигурационный файл PAM. Второе преимущество использования PAM заключается в том, что администратор системы получает полную свободу в выборе схемы аутентификации для каждого отдельного приложения, причем эта схема может быть достаточно сложной и состоящей из нескольких этапов. Единственным неотъемлемым требованием для использования PAM является наличие изначально встроенных в приложение функций работы с библиотекой PAM. Сейчас практически все популярные программные продукты имеют встроенную поддержку PAM.
Рис. 2.3.1 Структурная схема взаимодействия приложения и библиотеки PAM
На рисунке 2.3.1 наглядно показано, как происходит взаимодействие некого приложения А с библиотекой PAM. Приложение взаимодействует с библиотекой PAM, причем приложению неизвестно, какие алгоритмы аутентификации используются при проверке подлинности пользователя. Все операции по аутентификации, то есть шифрование пароля и его проверку, производит библиотека PAM. Библиотека Linux-PAM (в середине рисунка) производит чтение параметров аутентификации приложения А из конфигурационного файла и загружает необходимые модули в память. Затем загруженные модули попадают в одну из четырех управляющих групп (расположенных в нижней части рисунка посередине) и помещаются туда в порядке появления их в конфигурационном файле (сначала модуль а в группу auth, за ним b и так далее). Эти модули при вызове библиотекой Linux-PAM выполняют различные задачи аутентификации для приложения А. Для передачи текстовой информации, запрашиваемой у пользователя, может быть использована встроенная функция обмена.
Все модули PAM по умолчанию располагаются в каталоге /lib/security, а конфигурационные файлы PAM – в каталоге /etc/pam.d. Имя каждого конфигурационного файла, расположенного в каталоге /etc/pam.d, совпадает с именем приложения, использующего его. Например, для программы login полный путь к конфигурационному файлу PAM будет иметь вид /etc/pam.d/login. Содержимое этого файла может иметь следующий вид:
#%PAM-1.0
auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_stack.so service=system-auth
auth required /lib/security/pam_nologin.so
account required /lib/security/pam_stack.so service=system-auth
password required /lib/security/pam_stack.so service=system-auth
session required /lib/security/pam_stack.so service=system-auth
session required /lib/security/pam_limits.so
session optional /lib/security/pam_console.so
Каждая строчка файла означает, что для удачной аутентификации пользователь должен пройти через указанный модуль. Формат строки любого конфигурационного файла PAM имеет вид:
тип_модуля флаг_контроля путь_к_модулю параметры_модуля
Все модули библиотеки PAM по функциональному признаку делятся на четыре типа:
auth – этот тип модулей позволяет осуществлять два аспекта аутентификации. Во-первых, он выполняет саму аутентификацию, то есть устанавливает факт того, что пользователь действительно тот, за кого себя выдает. Это может быть запрос пароля или другие методы идентификации. Во-вторых, модуль может разрешить членство в группе (независимо от файла групп пользователей group) или определить другие привилегии, основываясь на информации о пользователе.
account – этот тип модулей выполняет функции, не связанные с аутентификацией напрямую. Обычно он используется для разрешения или запрещения доступа в зависимости от определенных условий, таких как время дня, количество пользователей, одновременно запросивших ресурс, различные параметры системы и так далее.
sessions – в основном этот тип используется для определения дополнительных действий, которые необходимо выполнить до или после предоставления сервиса пользователю. Сюда можно отнести протоколирование действий по открытию определенных файлов, монтирование каталогов, удаление временных файлов и так далее.
password – этот последний тип необходим для обновления опознавательного признака (например, того же самого пароля), который идентифицирует пользователя.
Наличие четырех управляющих типов говорит о том, что сама технология аутентификации с использованием библиотеки PAM способна предоставить не только «голый» способ установления подлинности пользователя, а еще и широкий спектр дополнительных возможностей по защите системы и предоставлению доступа к сервисам.
Флаг контроля определяет, как система будет себя вести при удачном или неудачном прохождении соответствующего модуля. Поскольку модули запускаются один за другим, то специальной расстановкой флагов можно определить значимость каждого из них. В качестве флагов могут быть использованы четыре ключевых слова:
required – этот флаг определяет, что для удачной аутентификации в целом необходимо успешное прохождение соответствующего модуля. Если при прохождении этого модуля система получила отказ, процесс аутентификации продолжается до тех пор, пока все модули не будут обработаны, и только потом выдается сообщение об ошибке.
requisite – эффект действия этого флага тот же, что и флага required, с одним различием: при получении отказа управление сразу возвращается приложению, прохождение остальных модулей не производится.
sufficient – весь процесс аутентификации считается успешным, если работа модуля с этим флагом была успешной и проверка на предшествующих модулях с флагом required не провалилась. Если работа модуля с этим флагом была неудачной, это не считается фатальной ошибкой.
optional – успешность модуля с этим флагом является необязательной и его использование не критично для аутентификации.
Путь к модулю содержит строку полного пути к модулю в файловой системе. Все модули хранятся в каталоге /lib/security, поэтому, например, путь к модулю pam_limits будет выглядеть как /lib/security/pam_limits.so.
Параметры модуля являются индивидуальным для каждого модуля и описываются в документации модуля.
Помимо основных конфигурационных файлов некоторые модули используют дополнительные файлы конфигурации, находящиеся в каталоге /etc/security. Каждый файл в этом каталоге предназначен для конкретной группы настроек:
time.
conf – в этом файле можно ограничить время доступа пользователей с различных терминалов к различным сервисам. Эти настройки использует модуль pam_time, поэтому для вступления в силу временных ограничений необходимо добавить модуль pam_time в конфигурационный файл приложения, на которое должны распространяться эти ограничения.
pam_
env.
conf – с помощью этого файла можно ограничить возможность изменения некоторых переменных среды пользователями. Этот файл используется модулем pam_env.
limits.
conf – этот файл дает возможность ограничить размер core-файла, максимально допустимый размер файла, максимальное количество одновременно открытых файлов, запущенных процессов, количество одновременно открытых пользовательских сессий и так далее. Используется модулем pam_limits.
access.
conf – с помощью этого файла можно определить различные параметры входа пользователя в систему, например, с каких компьютеров пользователь имеет доступ в систему. Этот конфигурационный файл используется модулем pam_access.
group.
conf – в этом файле можно указать, к какой группе будет принадлежать процесс, запущенный пользователем в определенное время с определенного терминала. Файл читается модулями pam_time и pam_group.
console.
perms – в этом файле имеется возможность указать права, назначаемые привилегированным пользователям при входе в систему и возвращаемые консоли при его выходе. Файл используется модулем pam_console.
Как уже неоднократно упоминалось, все модули располагаются в каталоге /lib/security. Кратко рассмотрим, какие модули входят в стандартный пакет PAM, и какие функции выполняет каждый из них:
| Название модуля | Тип модуля | Описание |
| pam_ cracklib | password | Позволяет проверять пароль на стойкость, не является ли он, например, словом из словаря и т. д. В основном используется программами, задающими пароли. К полезным параметрам относятся: retry=N – задает количество попыток на исправление ошибки; diffok=N – определяет минимальное количество символов, которое должно быть изменено при смене пароля; minlen=N – задает минимальный размер пароля в символах; dcredit=N ucredit=N lcredit=N ocredit=N – задает минимальное количество цифр, строчных, прописных букв и других символов, которые должны присутствовать в пароле. |
| pam_deny | любой | Основное назначение этого модуля – запрет доступа при любых условиях. |
| pam_env | auth | Контролирует сохранность переменных среды. С помощью параметра conffile=S можно указать файл конфигурации, отличный от стандартного. |
| pam_ftp | auth | Предназначен для организации анонимного доступа. Получив в качестве имени пользователя последовательность ‘anonymous’, модуль в качестве пароля требует строку, похожую на почтовый адрес. К полезным параметрам относятся: users=XXX, XXX, … - разрешает анонимный вход для пользователей из этого списка; ignore – позволяет не обращать внимания, похож ли пароль на почтовый адрес. |
| pam_group | auth | Определяет группу-владельца процесса, запущенного аутентифицированным пользователем. |
| pam_lastlog | auth | Сообщает о месте и времени входа в систему. Для протоколирования используется файл wtmp, находящийся в каталоге /var/log . К полезным параметрам можно отнести: nodate noterm nohost silent – позволяют не выводить в сообщении дату, терминал, адрес машины или вообще ничего не записывать в файл; never – предоставляет возможность выдачи приветствия пользователя, впервые вошедшего в систему. |
| pam_limits | session | Позволяет задавать ограничения для пользователя на размер файлов, число одновременно открытых дескрипторов и т. д. Имеет параметр conf=S для указания альтернативного конфигурационного файла. |
| pam_listfile | auth | Предназначен для организации доступа на основе конфигурационных файлов наподобие /etc/ftpaccess. Возможные паарметры: onerr=succeed | fail – задает возвращаемое значение в случае неудачного поиска; sence=allow | deny – задает возвращаемое значение в случае удачного поиска; file=filename – позволяет указать имя файла со списком; item=user | tty | rhost | ruser | group | shell – определяет тип элементов в списке. Например, значение item=user означает, что в файле содержится список имен пользователей, имеющих возможность входа в систему. |
| pam_mail | auth | Позволяет уведомлять пользователя о вновь пришедшей почте. Полезные параметры: dir=S – указывает путь к каталогу почтовых очередей; noenv – отменяет установку переменной среды MAIL; close – разрешает уведомлять о новых письмах в почтовых ящиках пользователей с аннулированными бюджетами; nopen – запрещает вывод какой-либо почтовой информации для вновь заведенного бюджета. |
| pam_nologin | auth | Если файл /etc/nologin существует, в систему может войти только привилегированный пользователь root, остальным же при попытке входа выдается содержимое этого файла. |
| pam_permit | любой | Этот модуль дает доступ при любых условиях. Необдуманное использование этого модуля весьма опасно! |
| pam_ pwdb | любой | Замещает модули серии pam_unix. Этот модуль использует интерфейс библиотеки libpwdb, предназначенный для работы с пользовательскими базами данных, что повышает независимость системы аутентификации от способа хранения пользовательских данных. Полезные параметры: nullok – разрешает использование пустых паролей; md5 shadow bigcrypt – указывает используемые алгоритмы шифрования паролей. |
| pam_radius | session | Позволяет осуществлять аутентификацию через сервер RADIUS. |
| pam_rhosts_auth | auth | Механизм работы этого модуля основывается на анализе содержимого файлов hosts.equiv и .rhosts, используемых для аутентификации такими службами, как rlogin и rsh. Полезные параметры: no_hosts_equiv – позволяет игнорировать содержимое файла hosts.equiv; no_rhosts - позволяет игнорировать содержимое файла .rhosts; suppress – позволяет избежать запись малозначительных сообщений в системный журнал, в частности, при использовании флага sufficient. |
| pam_root_ok | auth | Позволяет организовать доступ привилегированного пользователя к сервису, минуя процедуру ввода пароля. Пользователь допускается к сервису, только если его системный идентификатор равен нулю (то есть привилегированный пользователь root). |
| pam_securetty | auth | Позволяет учитывать файл /etc/securetty. В файле /etc/securetty указаны терминалы, с которых привилегированный пользователь имеет доступ в систему. |
| pam_time | account | Накладывает временные ограничения на доступ в систему. |
| pam_warn | auth, password | Производит записи в системных журналах при определенных действиях. |
| pam_wheel | auth | Этот модуль позволяет получить права привилегированного пользователя только пользователям определенной группы. Полезные параметры: group=XXX – задает группу, пользователи которой имеют возможность получить права пользователя root; deny – этот параметр инвертирует действие модуля, другими словами, он запрещает изменение прав на права пользователя root для указанной группы; trust – избавляет пользователей указанной группы от необходимости ввода пароля при смене идентификатора на нулевой. |
Возможно также создание собственных PAM-модулей на основе готовых шаблонов, что позволяет быстро получить необходимый метод аутентификации без особых усилий. Более подробную информацию о модулях и библиотеке PAM можно найти в документации, поставляемой вместе с пакетом. Практическое применение рассмотренной информации приводится в приложении в примере 5.
2.4. Брандмауэр
Локальная безопасность – необходимая составляющая общей безопасности системы. Она позволяет устранить угрозу локального взлома. Однако, при работе компьютера в сети возникает еще один тип угрозы – сетевой. Для устранения сетевой угрозы, как и для локальной, существуют свои средства и методы. Одним таким средством, наиболее важным и практически необходимым при построении сетевой системы безопасности является брандмауэр.
Брандмауэр, он же сетевой экран, он же firewall (с англ. «огненная стена») - это система или группа систем, реализующих правила управления доступом между двумя сетями. Фактические средства, с помощью которых это достигается, весьма различны, но в принципе брандмауэр можно рассматривать как пару механизмов: один для блокирования передачи информации, а другой – для пропуска информации. Некоторые брандмауэры уделяют больше внимания блокировке передачи информации, другие – ее пропуску. Некоторые брандмауэры пропускают только сообщения электронной почты, тем самым защищая сеть от любых атак, кроме атак на почтовую службу. Другие брандмауэры обеспечивают менее строгую защиту и блокируют лишь службы, определенно угрожающие безопасности. Обычно брандмауэры конфигурируются для защиты от неавторизованной интерактивной регистрации из внешнего мира. Именно это, больше, чем все остальное, помогает предотвратить проникновение взломщиков в компьютеры внутренней сети. Более развитые брандмауэры блокируют передачу информации извне в защищаемую сеть, разрешая при этом внутренним пользователям свободно взаимодействовать с внешним миром.
Схема сетевого запроса на сервер с установленным брандмауэром показана на рисунке 2.4.1.
Рис. 2.4.1. Пошаговая схема выполнения сетевого запроса с установлением соединения к ОС Linux
Ядро ОС Linux версии 2.4 и более поздних имеет встроенный межсетевой экран netfilter, который располагает следующими возможностями:
· позволяет осуществлять фильтрацию входящих, исходящих и транзитных пакетов, основываясь на содержании заголовка пакета, типе пакета, определяющего его состояние в соединении (первый пакет установления соединения, пакет синхронизации, пакет завершения сеанса), IP адресе компьютера-отправителя и компьютера-получателя, MAC адресе отправителя и получателя и так далее.
· позволяет осуществлять трансляцию сетевых адресов NAT (Network Address Translation) и подмену портов NPT (Network Port Translation). Действие NAT заключается в подмене IP адреса компьютера-отправителя или компьютера-получателя на указанный. В большинстве случаев эта возможность используется для организации обмена информацией между двумя сетями, имеющими разные диапазоны IP адресов. Действие NPT аналогично NAT с тем различием, что в последнем производится подмена порта приложения вместо IP адреса.
· позволяет менять специальные поля заголовка пакета, такие как TOS (Type Of Service), TTL (Time To Live) и так далее, что предоставляет расширенные возможности для управления процессом маршрутизации.
Вся логическая структура экрана netfilter строится на понятиях цепочек, таблиц и правил доступа.
Цепочка – определенный набор правил управления доступом. Попадая в цепочку, пакет проходит все ее правила, начиная с самого первого. Каждое правило имеет критерий и действие. Если пакет попадает под критерий правила, то с пакетом производится действие, определенное для этого правила.
Таблица – это набор цепочек. Таблицы делятся по функциональному назначению и определяют действия, которые разрешено выполнять в правилах цепочек этих таблиц.
Netfilter содержит только три таблицы:
mangle – эта таблица используется для внесения изменений в заголовки пакетов. Примером может служить изменение поля TTL, TOS или MARK. Таблица имеет пять цепочек: PREROUTING, POSTROUTING, INPUT, OUTPUT и FORWARD. Цепочка PREROUTING используется для внесения изменений на входе в брандмауэр, перед принятием решения о маршрутизации. Цепочка POSTROUTING используется для внесения изменений на выходе из брандмауэра уже после принятия решения о маршрутизации. Цепочка INPUT используется для внесения изменений в пакеты перед тем, как они будут переданы локальному приложению внутри брандмауэра. Цепочка OUTPUT используется для внесения изменений в пакеты, поступающие от приложений внутри брандмауэра. И, наконец, цепочка FORWARD используется для внесения изменений в транзитные пакеты после первого принятия решения о маршрутизации, но перед последним принятием решения о маршрутизации. Использование таблицы для других целей, нежели изменения заголовка пакета, является недопустимым.
nat – эта таблица используется для преобразования сетевых адресов, именуемого также NAT, и подмены портов NPT. Через эту таблицу проходит только первый пакет из всего потока данных соединения. Преобразование адресов автоматически применяется ко всем последующим пакетам. Эта таблица содержит три заранее определенные цепочки. Цепочка PREROUTING используется для внесения изменений в пакеты на входе в брандмауэр. Цепочка OUTPUT используется для преобразования адресов в пакетах, созданных приложениями внутри брандмауэра, перед принятием решения о маршрутизации. И последняя третья цепочка в этой таблице – POSTROUTING, которая используется для преобразования пакетов перед отправкой их в сеть. Эта таблица должна использоваться только для преобразования адресов и портов в пакете.
filter – эта таблица используется главным образом для фильтрации пакетов. Таблица имеет три встроенных цепочки. Первая – FORWARD, используемая для фильтрации пакетов, не адресованных серверу, на котором установлен брандмауэр, то есть идущих транзитом через него. Цепочку INPUT проходят пакеты, которые предназначены локальным приложениям сервера. И цепочка OUTPUT используется для фильтрации исходящих пакетов, сгенерированных приложениями на сервере с брандмауэром.
Структурная схема брандмауэра netfilter показана на рисунке 2.4.2.
Рис. 2.4.2. Структурная организация брандмауэра
Для того, чтобы брандмауэр выполнял те функции, которые на него возлагаются, для комплексной сетевой защиты необходимо, чтобы все пакеты, приходящие по сети и уходящие в сеть, проходили через него. Если же это правило не соблюдается, или соблюдается частично, то все действия, направленные на создание безопасного сервера с использованием брандмауэра, будут бесполезны. Если существует хоть малейшая вероятность, что брандмауэр можно обойти, эта возможность обязательно рано или поздно будет использована взломщиками. В Linux брандмауэр является частью ядра, а поскольку все операции при работе с сетью контролирует ядро, гарантию того, что все сетевые пакеты пройдут через него, можно считать практически стопроцентной.
Следуя рисунку 2.4.2, рассмотрим, какой путь совершает пакет, прежде чем достичь места назначения. Попадая на сервер, пакет сначала проходит цепочки PREROUTING таблиц mangle и nat. Затем, в зависимости от того, кому адресован пакет, его направление может меняться. Если пакет адресован локальному процессу сервера, после маршрутизации он попадает в цепочки INPUT таблиц mangle и filter. Если ему удается успешно пройти эти цепочки, пакет достигает локального процесса. Ответ локального процесса перед отправкой проходит сначала цепочку OUTPUT всех трех таблиц, и, если пакет не был отфильтрован, он попадает в заключительную цепочку POSTROUTING таблиц mangle и nat. После этого пакет покидает сервер.
Если же пакет адресован другому компьютеру, то есть является транзитным, то после маршрутизации он попадает в цепочку FORWARD таблиц mangle и filter, в которой осуществляются все необходимые действия по управлению доступом для всех транзитных пакетов. Далее, как и пакет локального процесса, перед отправкой в сеть транзитный пакет проходит через цепочки POSTROUTING таблиц mangle и nat.
Этих трех таблиц с заранее закрепленным функциональным назначением вполне достаточно для реализации всех перечисленных ранее возможностей. Количество таблиц является определенным и не может быть изменено ни при каких условиях. При настройке брандмауэра в таблицы могут быть добавлены другие цепочки в дополнение к уже существующим, что позволяет создавать более гибкую систему управления доступом, нежели просто добавление правил в заранее определенные цепочки. В отличие от цепочек, созданных администратором, системные цепочки INPUT, OUTPUT, FORWARD, PREROUTING и POSTROUTING не могут быть удалены ни при каких условиях.
Для настройки и управления брандмауэром в составе ОС Linux поставляется программный пакет iptables. Этот пакет помимо файлов документации и модулей, подгружаемых в ядро и используемых для осуществления фильтрации по различным критериям, включает следующие исполняемые файлы:
iptables – основная программа пакета, с помощью которой производится манипулирование правилами в цепочках. Эта программа позволяет совершать с правилами и пользовательскими цепочками все доступные действия.
iptables-save – программа, которая позволяет сохранять все текущие правила в одном файле для последующего их восстановления. По умолчанию этим файлом является /etc/sysconfig/iptables. В файле /etc/sysconfig/iptables хранится вся конфигурация брандмауэра и из этого файла она считывается при загрузке системы.
iptables-restore – эта программа позволяет считывать правила и цепочки, сохраненные ранее программой iptables-save. По умолчанию эта программа пытается загрузить файл /etc/sysconfig/iptables, если он существует.
Более подробная информация о программном пакете iptables содержится в файлах документации, а также в соответствующих man-руководствах.
Практическое применение рассмотренной информации приводится в приложении в примере 6.
2.5. Удаленное управление
Потребность в удаленном управлении возникла с момента появления сети и систем, которые необходимо было администрировать на расстоянии.
Чтобы лучше представить, в чем заключается удобство от использования программ удаленного управления, возьмем простой пример. Организация имеет свой собственный сервер, на котором располагается почтовая система и почтовые ящики всех сотрудников организации. Организация арендует помещение на двадцатом этаже высотного здания, в котором помимо нее функционирует еще десяток-другой таких же организаций. В этом здании имеется специализированное подвальное помещение с хорошо организованной системой охлаждения, в котором располагаются коммуникационные средства, системы связи и сервера. Сервер рассматриваемой организации также располагается в этом помещении. За работоспособностью сервера следит специальное лицо, выполняющее функции администратора сети, которое помимо этого выполняет необходимые изменения в конфигурации предоставляемых сервисов. А теперь представим, какие действия необходимо совершить администратору, если, например, какому-то пользователю почтовой системы нужно поменять пароль. При отсутствии удаленного управления администратор вынужден каждый раз спускаться с двадцатого этажа в подвальное помещение, открывать локальную консоль на сервере и, выполнив необходимые действия, возвращаться обратно. В принципе, ситуация не такая уж безвыходная. А если организация арендует сервер в другой стране или на другом континенте?
В таких случаях идеальным решением является организация полнофункционального управления сервером посредством сетевого доступа. Существует несколько очень распространенных протоколов удаленного администрирования, позволяющих управлять системой посредством сети. Самым старым и самым распространенным, но в то же время самым небезопасным, является протокол Telnet. Это самый первый протокол удаленного взаимодействия, появившийся на заре развития вычислительных сетей, когда проблеме безопасности при передаче информации не уделялось практически никакого внимания. При передаче информации по протоколу Telnet все данные передаются в открытом незашифрованном виде, в том числе имена и пароли пользователей. Любой, даже малоопытный в компьютерных делах, пользователь, имея программу под общим названием network sniffer (с англ. «сетевой анализатор пакетов»), может получить имя и пароль при передаче их по сети.
Помимо протокола Telnet в UNIX-системах существует целое семейство так называемых r-программ. К ним относятся rsh, rlogin (начальная буква r трактуется как remote) и другие, позволяющие производить различные операции, связанные с удаленным администрированием. Однако уровень безопасности при использовании r-программ, как и уровень безопасности при использовании Telnet, также оставляет желать лучшего.
Существует еще один протокол для управления некоторыми параметрами системы и получения информации о ней. Это протокол SNMP (Simple Network Management Protocol). Протокол SNMP имеет ограниченный спектр возможностей и не лишен тех же недостатков в плане безопасности, что и протокол Telnet.
Эти протоколы могут служить хорошим решением для таких локальных сетей, где требования, предъявляемые к безопасности, являются не очень высокими. Однако, при передаче данных по такой сети, как Интернет, где пакет, прежде чем достичь адресата, проходит несколько небезопасных узлов, их использование может служить потенциальной угрозой безопасности и основной причиной успешного проникновения в систему.
На сегодняшний день одним из самых распространенных и безопасных протоколов удаленного администрирования, использующих шифрование при передаче данных, является протокол SSH (Secure SHell). Рассмотрим поподробнее, в чем же состоит преимущество протокола SSH перед другими протоколами удаленного управления.
Протокол SSH появился в 1995 году и с самого начала в основу была положена идея создания средства организации безопасного доступа к компьютерам при работе по небезопасным каналам связи, таким как сеть Интернет. В протоколе SSH для организации безопасного доступа применяется процедура аутентификации с использованием асимметричного шифрования с открытым ключом. Это обеспечивает более высокую безопасность, чем при использовании симметричного шифрования, хотя и порождает дополнительную вычислительную нагрузку. При последующем обмене данными применяется уже симметричное шифрование, более экономичное в смысле затрат процессорного времени. Также SSH поддерживает возможность работы с уже упомянутым протоколом Telnet, безопасную работу по протоколу графического уровня X11, благодаря возможности перенаправления соответствующих данных по надежным SSH-каналам, предоставляет безопасную замену многим r-программам UNIX, с которыми традиционно связаны проблемы обеспечения безопасности.
Проект стандарта SSH описывает протоколы SSH и состоит из нескольких документов, которые описывают общую архитектуру протокола, а также протоколы трех уровней: протокол транспортного уровня, протокол аутентификации и протокол соединения. Их задача - обеспечивать безопасную сетевую службу наподобие Telnet поверх небезопасной сети.
Протокол транспортного уровня обеспечивает аутентификацию сервера, конфиденциальность и целостность. Протокол аутентификации обеспечивает аутентификацию клиента для сервера. Наконец, протокол соединения SSH мультиплексирует безопасный шифруемый канал, представляя его в виде нескольких логических каналов, которые используются для различных целей или различных видов служб. Помимо этого протокол транспортного уровня предусматривает возможность сжатия данных, что является бесспорным преимуществом по сравнению с протоколом Telnet при передаче данных по низкоскоростному каналу. Протокол транспортного уровня работает поверх соединения TCP/IP, в свою очередь протокол аутентификации работает поверх протокола транспортного уровня, а протокол соединения – поверх протокола аутентификации. В итоге получается жесткая взаимосвязь протоколов, обеспечивая в сумме наиболее безопасную и эффективную передачу данных.
С целью повышения безопасности в протоколе SSH осуществляется не только аутентификация клиента для сервера, к которому обращается клиент, но и аутентификация сервера клиентом - другими словами, происходит аутентификация обеих сторон. Клиент шлет запрос на обслуживание в первый раз, когда устанавливается безопасное соединение транспортного уровня SSH. Второй запрос направляется уже после завершения аутентификации клиента.
В дистрибутивах Linux и в большинстве UNIX-подобных ОС возможность работы по протоколу SSH предоставляет бесплатный и свободно-распространяемый программный продукт OpenSSH, в который включены как серверная программа, так и клиентское приложение. Настройка программ пакета OpenSSH осуществляется отчасти при установке пакета, некоторая настройка производится посредством изменения в конфигурационных файлах.
При установке пакета из исходных файлов при запуске программы конфигурирования configure можно задать целый ряд ключей. В частности, можно указать, какие методы шифрования сеанса будут использованы при работе SSH: IDEA, DES, тройной DES, ARCFOUR и BLOWFISH. По умолчанию основным является алгоритм IDEA, использующий 128-разрядные ключи. Если он исключен соответствующим ключом, основным алгоритмом становится 3DES - трехкратное последовательное DES-шифрование c 56-разрядным ключом. Можно выделить также метод BLOWFISH, который при той же длине ключа (от 32 до 448 разрядов) работает быстрее IDEA и DES. Можно задать также замену стандартных команд rlogin и rsh соответствующими одноименными модулями из дистрибутива SSH. Тогда для соединений будет использоваться протокол SSH, конечно, если удаленный компьютер его поддерживает. В противном случае после предупреждения будет осуществлен переход к обычным r-средствам. Все возможные ключи конфигурационной программы можно узнать из документации, идущей с дистрибутивом, или запуском программы с ключом –help.
По умолчанию, если путь не был изменен ключом конфигурационной программы, файлы конфигурации OpenSSH при установке помещаются в каталог /usr/local/etc/ssh. После установки этот каталог содержит несколько конфигурационных файлов, основными из которых являются файлы конфигурации sshd_config и ssh_config серверной и клиентской частей соответственно. Эти файлы имеют формат
<параметр> <значение>
и могут быть использованы для установки таких параметров работы, как, например, необходимость использования аутентификации сервера на базе имени компьютера, аутентификации пользователя с помощью пароля, протокол какой версии SSH (на сегодня существует две основные версии: SSH версии 1.0 и SSH версии 2.0) необходимо использовать при обмене информацией. Для серверной программы в конфигурационном файле sshd_config существует возможность указать, на каком порту демон sshd будет принимать соединения (по умолчанию для этой цели используется порт с номером 22), а также на какой IP адрес должны приходить запросы. Все параметры конфигурационных файлов очень подробно описаны в документации, поставляемой с пакетом OpenSSH.
Практическое применение рассмотренной информации приводится в приложении в примере 7.
Вывод.
В этой главе работы были рассмотрены основные средства безопасности, которыми располагает ОС Linux. В первой части главы приводится описание средств обеспечения локальной безопасности, то есть без учета подключения компьютера с ОС Linux к сети. Вторая часть ориентирована на проблемы обеспечения сетевой безопасности. Первая часть освещает основные возможности файловой системы ext2, приводится описание программ изменения прав доступа и владельца файла chmod и chown, подробно рассматриваются атрибуты файлов, программы работы с атрибутами chattr и lsattr. В дополнение ко всему приводится описание пакета lcap для настройки некоторых параметров ядра ОС. Далее рассматривается концепция пользовательских дисковых квот, пакет для работы с пользовательскими квотами quota. В последнем разделе, посвященном локальной безопасности, приводится современная технология аутентификации с использованием библиотеки PAM, рассматриваются ее возможности, приводится перечень модулей, входящих в эту библиотеку, и их описание. Подробно рассматривается формат конфигурационных файлов PAM. Во второй части главы рассматривается принцип защиты системы от сетевого вмешательства посредством межсетевого экрана netfilter, описывается алгоритм функционирования межсетевого экрана, рассматривается концепция построения правил фильтрации. Далее приводится общий обзор протоколов удаленного администрирования и большое внимание уделяется протоколу ассиметричного шифрования SSH, рассматриваются принципы работы этого протокола, его назначение и основные характеристики.
3. Средства усиления безопасности в Linux
Помимо стандартных средств организации безопасной работы Linux существует огромное количество дополнительного системного программного обеспечения, позволяющего расширить возможности стандартных средств и добавить новые, более гибкие и приспособленные к специфическим условиям. В большинстве случаев стандартные средства Linux позволяют добиться необходимого уровня защиты. Но бывают ситуации, когда к системе предъявляются повышенные требования, и стандартных средств обеспечения безопасности может оказаться недостаточно. В таких случаях простым решением может служить использование дополнительных программных пакетов.
3.1. Linux ACLs
Иногда в процессе работы администратор сервера может столкнуться с проблемой правильной установки прав доступа. Например, возникла ситуация, когда на один файл необходимо установить право на чтение трем пользователям разных групп и право на чтение и выполнение для пользователя четвертой группы. Решение этой проблемы стандартными средствами является достаточно сложной задачей. Права доступа в Linux задаются девятью битами, что предполагает установку прав только для пользователя-владельца, группы-владельца и всех остальных. Какие-либо дополнительные возможности по установке прав доступа к файлу в стандартной конфигурации ОС Linux отсутствуют. В результате для решения задачи может потребоваться внесение пользователей в общие группы или создание дополнительных групп, что является не всегда приемлемым и помимо всего прочего создает дополнительные проблемы управления.
Оптимальным решением в ситуации такого рода может послужить программная разработка Linux ACLs.
Linux ACLs (Access Control Lists) – это набор заплаток для ядра операционной системы и приложений для работы с файловой системой и несколько дополнительных программ, дающих возможность устанавливать права доступа к файлам не только для пользователя-владельца и группы-владельца файла, но и для любого пользователя и группы.
Linux ACLs использует расширенные атрибуты для хранения данных о правах доступа к файлам пользователей и групп. Список расширенного контроля доступа существует для каждого файла в системе и состоит из шести компонентов. Первые три являются копией стандартных прав доступа к файлу. Они содержаться в единственном экземпляре в ACL и есть у каждого файла в системе:
· ACL_USER_OBJ – режим доступа к файлу пользователя-владельца;
· ACL_GROUP_OBJ – режим доступа к файлу группы-владельца;
· ACL_OTHER – режим доступа к файлу остальных пользователей.
Следующие два компонента устанавливаются для каждого файла в отдельности и могут присутствовать в ACL в нескольких экземплярах:
· ACL_USER – содержит UID и режим доступа к файлу пользователя, которому установлены права, отличные от основных. На каждого пользователя со своими правами на данный файл хранится отдельная запись. Не может существовать более одной записи на одного и того же пользователя;
· ACL_GROUP – содержит те же самые данные, что и ACL_USER, но для группы пользователей;
· ACL_MASK – маска действующих прав доступа для расширенного режима.
При установке дополнительных прав доступа присваивается значение и элементу ACL_MASK.
Каталоги также могут иметь список контроля доступа по умолчанию. В отличие от основного ACL, он действует на создаваемые внутри данного каталога файлы и каталоги. При создании файла внутри такого каталога файл получает ACL, равный ACL по умолчанию этого каталога.
Для использования Linux ACLs необходимо получить на сайте разработчика пакет Linux ACLs и заплатки к ядру ОС Linux и некоторым программам системного окружения. Сначала необходимо наложить заплатку на исходные файлы ядра, чтобы получить поддержку листов доступа, затем собрать ядро с поддержкой расширенных атрибутов и листов контроля доступа. После сборки ядра с поддержкой листов доступа нужно наложить заплатки на некоторые системные программы и пересобрать их. Далее необходимо собрать пакет приложений ACL, который тоже находится на сайте разработчика. С помощью приложений этого пакета производится управление расширенными правами доступа. Весь процесс установки Linux ACLs, начиная наложением заплаток и заканчивая сборкой пакета ACL, подробно описан в документации программного пакета.
После включения в системе поддержки Linux ACLs манипулирование расширенными атрибутами производится с помощью двух программ, входящих в пакет ACL – getfacl и setfacl. Первая программа позволяет получить информацию о расширенных правах доступа файла. Вторая производит изменение этих прав доступа. Синтаксис командных строк этих программ подробно описан в соответствующих man-руководствах пакета.
3.2. LIDS
LIDS (Linux Intrusion Detection/Defence System) – система обнаружения и защиты от вторжения. Эта система представляет собой дополнение к ядру операционной системы Linux, добавляющее дополнительные возможности для увеличения безопасности операционной системы. LIDS позволяет запретить или ограничить доступ к файлам, памяти, устройствам, сетевым интерфейсам и запущенным приложениям привилегированному пользователю, что дает возможность надежно оградить даже взломанную операционную систему от дальнейшего вмешательства.
В отличие от других средств защиты операционной системы Linux, эту систему невозможно отключить, не зная пароля администратора LIDS, который в зашифрованном виде хранится в специальном файле, видимом только программой администрирования LIDS. Таким же образом защищены и конфигурационные файлы LIDS. Помимо этого система имеет одно очень существенное преимущество: зная пароль администратора LIDS, систему можно отключить только с локальной консоли компьютера.
Для того, чтобы установить LIDS, необходимо включить поддержку этой системы в ядре, что требует наложения заплаток на исходные файлы ядра и включение возможностей LIDS при конфигурировании ядра до его сборки. После включения в ядре поддержки LIDS станет доступным список параметров LIDS. Также пакет LIDS включает программы для настройки этой системы.
После установки LIDS в каталоге /etc появится каталог lids, содержащий следующие конфигурационные файлы:
lids.cap – этот файл предназначен для хранения текущих значений установок способностей.
lids.net – файл предназначен для настройки отправки электронных сообщений системой LIDS.
lids.pw – в этом файле записан в зашифрованном виде пароль администратора. Изменять этот файл можно только с помощью программы lidsadm пакета LIDS.
lids.conf – этот файл содержит текущие установки правил доступа. Изменять этот файл может только программа lidsadm.
При установке различных ограничений LIDS использует так называемые способности.
Способность – это возможность программ совершать какие-либо действия.
Все способности устанавливаются в файле /etc/lids/lids.cap. Этот файл имеет следующий формат:
[ + | - ] <номер>:<способность>
“+” включает соответствующую способность, а “–“ выключает ее.
номер – порядковый номер способности.
способность – наименование способности.
Редактирование файла /etc/lids/lids.cap можно производить с помощью любого текстового редактора. Включение способностей влияет на все программы без исключения, а выключение влияет на все программы, кроме тех, которым напрямую указана данная способность с помощью правил доступа lidsadm.
После установки файл /etc/lids/lids.cap содержит включенными следующие способности:
· CAP_CHOWN – устанавливает способность программ изменять владельца и группу-владельца файла;
· CAP_DAC_OVERRIDE – разрешает программам, запускаемым привилегированным пользователем, не принимать во внимание режимы доступа к файлам. При отключении этой способности пользователь root теряет возможность изменять файлы, если ему напрямую не заданы права доступа;
· CAP_DAC_READ_SEARCH – определяет то же самое, что и CAP_DAC_OVERRIDE, только в данном случае ограничение распространяется только на каталоги;
· CAP_FOWNER – разрешает операции с файлами, когда владелец файла должен совпадать с пользователем, совершающим операцию;
· CAP_FSETID – разрешает установку бит SUID и SGID на файлах, не принадлежащих пользователю root;
· CAP_KILL – разрешает процессам привилегированного пользователя уничтожать другие процессы;
· CAP_SETGID, CAP_SETUID – управляет способностью программ привилегированного пользователя изменять группу и пользователя, под которыми работает программа;
· CAP_SETPCAP – позволяет программам менять способности;
· CAP_LINUX_IMMUTABLE – управляет способностью снимать расширенные атрибуты immutable и append с файлов;
· CAP_NET_BIND_SERVICE – разрешает программам, выполняющимся не от имени пользователя root, использовать сетевой порт ниже 1024;
· CAP_NET_BROADCAST – управляет способностью программ рассылать широковещательные пакеты;
· CAP_NET_ADMIN – параметр управляет большим количеством различных способностей: конфигурирование сетевых интерфейсов, изменение правил брандмауэра, изменение таблиц маршрутизации и других способностей, связанных с сетевыми настройками Linux;
· CAP_NET_RAW – управляет способностью программ использовать гнезда;
· CAP_IPC_LOCK – управляет способностью процессов привилегированного пользователя блокировать сегменты разделяемой памяти;
· CAP_IPC_OWNER – управляет доступом программ пользователя root к ресурсам межпроцессорного взаимодействия процессов, не принадлежащих пользователю root;
· CAP_SYS_MODULE – управляет способностью загружать модули ядра;
· CAP_SYS_RAWIO – управляет низкоуровневым доступом на чтение/запись к таким устройствам, как /dev/mem, /dev/kmem, /dev/port, /dev/hd*, /dev/sd*;
· CAP_SYS_CHROOT – управляет способностью устанавливать корневой каталог для текущей командной оболочки;
· CAP_SYS_PTRACE – позволяет программам использовать вызов функции ptrace(), которая позволяет процессу-родителю управлять выполнением процессов-потомков;
· CAP_SYS_PACCT – управляет способностью конфигурировать учет процессов;
· CAP_SYS_ADMIN – управляет множеством способностей: управление устройством /dev/random, создание новых устройств, конфигурирование дисковых квот, настройка работы klogd, установка доменного имени компьютера, сброс кэша, монтирование и размонтирование дисков, включение и отключение раздела виртуальной памяти, установка параметров последовательных портов и многое другое;
· CAP_SYS_BOOT – управляет способностью перезагружать систему;
· CAP_SYS_NICE – управляет способностью изменять приоритет процессов, не принадлежащих привилегированному пользователю;
· CAP_SYS_RESOURCE – управляет способностью изменять предельные значения использования ресурсов системы: дисковые квоты, зарезервированное пространство на разделах с файловой системой ext2, максимальное количество консольных программ и так далее;
· CAP_SYS_TIME – управляет способностью изменять системное время;
· CAP_SYS_TTY_CONFIG – управляет способностью изменять настройки устройств tty;
· CAP_HIDDEN – управляет способностью программ становится невидимыми в списке выполняемых процессов. Не влияет на все программы;
· CAP_INIT_KILL – управляет способностью уничтожать процессы-потомки процесса init;
Для вступления в действие способностей, необходимо сразу после загрузки системы и запуска всех сервисов выполнить команду
lidsadm –I
Эта команда обычно записывается в один из файлов сценариев, выполняемых при загрузке системы.
Помимо способностей система LIDS позволяет задавать правила доступа к дисковым ресурсам. Все управление LIDS осуществляется с помощью программы lidsadm. Эта программа способна работать в двух режимах: режиме настройки правил доступа и режиме ввода команд администрирования. Все установки правил доступа находятся в файле /etc/lids/lids.conf. Для их просмотра необходимо запустить программу lidsadm с параметром –L.
[root@app /]# lidsadm –L
LIST
Subject ACCESS TYPE Object
-------------------------------------------------------------
Any File READ /sbin
Any File READ /bin
Any File READ /boot
Any File READ /lib
Any File READ /usr
Any File DENY /etc/shadow
/bin/login READ /etc/shadow
/bin/su READ /etc/shadow
Any File APPEND /var/log
Any File WRITE /var/log/wtmp
…
Правила доступа состоят из трех элементов: субъекта, объекта и цели. Объектом является любой файл или каталог, на который должны действовать правила доступа и защита LIDS. Если в качестве объекта указан каталог, то все файлы в нем и вложенные подкаталоги с их файлами автоматически становятся объектами.
Субъектом является любая защищенная программа, которой дают доступ к защищаемому объекту. Поэтому, прежде чем использовать программу в качестве субъекта, ее саму надо защитить средствами LIDS, применив к ней правила доступа как к объекту. Если субъект не указан, субъектом является любая программа.
Целью является тип доступа субъекта к объекту. Существуют следующие типы доступа:
· READ – доступ на чтение;
· WRITE – доступ на запись;
· DENY – запрет на какой-либо доступ вообще;
· APPEND – открытие только для записи в конец файла;
· IGNORE – игнорирование защиты.
Построение прав доступа подробно описано в соответствующих файлах документации и man-руководствах.
3.3. AIDE
AIDE (Advanced Intrusion Detection Environment) – расширенное окружение обнаружения вторжений. Основное назначение программного продукта AIDE – обнаружения изменения файлов, их атрибутов, прав доступа, пользователей владельцев, размера, количества ссылок на файл и других параметров, которые присущи файлу в Linux.
Программный пакет AIDE создает базу данных всех файлов, перечисленных в основном конфигурационном файле программы aide.conf. В базу помимо стандартных атрибутов файла записывается также криптографическая контрольная сумма или хэш каждого файла, вычисленных с использованием одного или комбинации следующих алгоритмов шифрования: SHA1, MD5, RMD160, TIGER.
Сразу после установки и настройки необходимых сервисов и программ, но перед подключением системы к сети, администратор должен создать базу AIDE. Это база будет содержать информацию о файлах в их первоначальном виде. Обычно к контролируемым файлам относятся все бинарные файлы, исполняемые файлы, конфигурационные файлы системы и программ, заголовочные файлы, файлы исходного кода и другие файлы, изменение которых после установки практически не производится.
Для создания базы данных программа aide запускается с параметром –init.
[root@gw /]# aide –init
После создания базы ее необходимо переместить в безопасное место, где привилегированный пользователь root имеет ограниченный доступ или не имеет доступа вообще. Наилучшим решением будет запись базы на какой-либо съемный носитель информации, который без особых проблем можно подключить к системе в любой момент.
Проверка целостности файлов производится вызовом программы aide с параметром –check.
[root@gw /]# aide –check
Программа выполняет чтение файлов на диске и производит сравнение с данными из базы данных. Отчет о проведенной проверке тут же выводится на экран.
Программный пакет AIDE может служить хорошим дополнением к базовой защите в качестве средства профилактики, однако использование этого продукта в качестве основной системы защиты нежелательно. Помимо того, что взломщик может изменить саму базу данных AIDE, если сможет получить к ней доступ, он так же может произвести изменение файла с сохранением основных его атрибутов. Естественно, подделать контрольную сумму файла после его изменения – нелегкая задача, но все же осуществимая.
Вывод.
Данная глава посвящена дополнительному программному обеспечению, расширяющему стандартные возможности систем Linux в плане безопасности. В первой части главы рассматривается программный пакет Linux ACLs, листы доступа на основе расширенных атрибутов, программы getfacl и setfacl для работы с расширенными правами доступа. Вторая часть посвящена системе обнаружения и защиты от вторжения LIDS, описываются возможности ядер 2.4 и принципы работы LIDS на основе этих атрибутов. Также приводится формат конфигурационных файлов этой системы. Заключительный раздел посвящен расширенному окружению обнаружения вторжений AIDE, описывается назначение, принцип работы и основы конфигурирования.
4. Техника безопасности
Этот раздел является дополнением к основной дипломной работе. В этом разделе рассматриваются некоторые аспекты безопасной работы на компьютере.
Среди различных физических факторов окружающей среды, которые могут оказывать неблагоприятное воздействие на человека и биологические объекты, большую сложность представляют электромагнитные поля неионизирующей природы, особенно относящиеся к радиочастотному излучению. Здесь неприемлем замкнутый цикл производства без выброса загрязняющего фактора в окружающую среду, поскольку используется уникальная способность радиоволн распространяться на далекие расстояния. По этой же причине неприемлемо и экранирование излучения и замена токсического фактора на другой, менее токсический фактор. Неизбежность воздействия электромагнитного излучения на население и окружающую живую природу стало данью современному техническому прогрессу и все более широкому применению телевидения и радиовещания, радиосвязи и радиолокации, использования СВЧ-излучающих приборов и так далее. И хотя возможна определенная канализация излучения, уменьшающая нежелательное облучение населения, и регламентация во время работ излучающих устройств, дальнейший технический прогресс все же повышает вероятность воздействия электромагнитного излучения на человека.
На возможность неблагоприятного влияния на организм человека электромагнитных полей было обращено внимание еще в конце 40-х годов. В результате обследования людей, работающих в условиях воздействия электромагнитных полей значительной интенсивности, было показано, что наиболее чувствительными к данному воздействию является нервная и сердечно-сосудистая система. Описаны изменения кроветворения, нарушения со стороны эндокринной системы, метаболических процессов, заболевания органов зрения. Было установлено, что клинические проявления воздействия радиоволн наиболее часто характеризуются астеническими и вегетативными реакциями.
В условиях длительного профессионального облучения с периодическим повышением предельно допустимых уровней у части людей отмечали функциональные перемены в органах пищеварения, выражающиеся в изменении секреции и кислотности желудочного сока, а также в явлениях дискинезии кишечника.
При длительном профессиональном облучении выявлены также функциональные сдвиги со стороны эндокринной системы: повышение функциональной активности щитовидной железы, изменение характера сахарной кривой и так далее.
В последние годы появляются сообщения о возможности индукции электромагнитного излучения злокачественных заболеваний. Еще немногочисленные данные все же говорят, что наибольшее число случаев приходится на опухоли кроветворных тканей и в частности на лейкоз. Это становится общей закономерностью канцерогенного эффекта при воздействии на организм человека и животных физических факторов различной природы и в ряде других случаев.
Мониторы персональных компьютеров используют в процессе повседневной деятельности миллионы служащих во всем мире. Компьютеризация в нашей стране принимает широкий размах, и многие сотни тысяч людей проводят большую часть рабочего дня перед экраном дисплея. Наряду с признанием несомненной пользы применение компьютерной техники вызывает у пользователей персональных компьютеров беспокойство за свое здоровье.
Имеются статистические данные, согласно которым лица, работающие с персональным компьютером, более беспокойны, подозрительны, чаще избегают общения, а также недоверчивы, раздражительны, склонны к повышенной самооценке, высокомерны, фиксируют внимание на неудачах.
Крупнейшими источниками электромагнитных излучений являются радио- и телевизионные средства связи и обработки информации, радиолокационные и навигационные средства, лазерные системы, воздушные линии электропередач.
Серьезного внимания заслуживают вопросы гигиенической оценки уровней электромагнитного излучения, которым подвергаются лица, работающие в зоне действия излучений, но не связанные с обслуживанием радиотехнических устройств. По данным американского Агентства по охране окружающей среды около 1% человеческой популяции подвергаются воздействию электромагнитного излучения интенсивностью более 1мкВт/см2. При этом наибольшие значения интенсивности были зафиксированы в высотных зданиях, особенно на уровнях, соответствующих уровням размещения антенных систем.
К сожалению, вредное воздействие электромагнитного излучения связано не только с источниками широкомасштабного излучения. Известно, что магнитное поле возникает вокруг любого предмета, работающего на электрическом поле. А это практически любой прибор, сопровождающий нас в быту (даже электрические часы).
Дисплеи персональных компьютеров, выполненные на электронно-лучевых трубках, являются потенциальными источниками мягкого рентгеновского, ультрафиолетового, инфракрасного, видимого, радиочастотного, сверх- и низкочастотного электромагнитного излучения.
Последствия регулярной работы с компьютером без применения защитных средств:
· заболевания органов зрения (60% пользователей);
· болезни сердечно-сосудистой системы (60%);
· заболевания желудочно-кишечного тракта (40%);
· кожные заболевания (10%);
· различные опухоли.
Особенно опасно электромагнитное излучение компьютера для детей и беременных женщин. Установлено, что у беременных женщин, работающих на компьютерах с дисплеями на электронно-лучевых трубках, с 90-процентной вероятностью в 1,5 раза чаще случаются выкидыши и в 2,5 раза чаще появляются на свет дети с врожденными пороками.
Некоторые допустимые уровни электромагнитных полей приведены в таблице 4.1.
Таблица 4.1. Предельно допустимые уровни электромагнитных полей при круглосуточном непрерывном излучении
| Метрическое подразделение диапазона | Частоты | Длины волн | Предельно Допустимый Уровень |
| Километровые волны, низкие частоты Гектометровые волны, средние частоты Декаметровые волны, высокие частоты Метровые волны, Очень высокие частоты Дециметровые волны, Ультравысокие волны Сантиметровые волны, Сверхвысокие частоты | 30-330 кГц 0,3-3 МГц 3-30 МГц 30-300 МГц 300-3000 МГц 3-30 ГГц | 10-1 км 1-0,1 км 100-10 м 10-1 м 1-0,1 м 10-1 см | 25 В/м 15 В/м 10 В/м 3 В/м 10 мквт/см2 10 мквт/см2 |
Персональные компьютеры заняли прочное место в деятельности многих людей. Сейчас уже невозможно представить полноценную трудовую деятельность на предприятиях, в частном бизнесе, да и в процессе обучения без персонального компьютера. Но все это не может не вызывать обеспокоенности в отношении их вредного влияния на состояние здоровья пользователей. Недооценка особенностей работы с дисплеями, помимо снижения надежности и эффективности работы с ними, приводит к существенным проблемам со здоровьем.
Рекомендуется, например, чтобы экран дисплея находился от глаз пользователя на расстоянии не ближе, чем 50-70 см.
Режимы труда и отдыха при работе с персональным компьютером зависят от категории трудовой деятельности.
Все работы с персональным компьютером делятся на три категории:
· Эпизодическое считывание и ввод информации не более 2 часов за 8-часовую рабочую смену.
· Считывание информации или творческая работа не более 4 часов за 8-часовую смену.
· Считывание информации или творческая работа более 4 часов за 8-часовую смену.
Продолжительность непрерывной работы с персональным компьютером не должна превышать 2 часов.
Если в помещении эксплуатируется более одного компьютера, то следует учесть, что на пользователя одного компьютера могут воздействовать излучения от других персональных компьютеров, в первую очередь со стороны боковых, а также и задней стенки монитора. Учитывая, что от излучения со стороны экрана монитора можно защитить применением специальных фильтров, необходимо, чтобы пользователь размещался от боковых и задних стенок других дисплеев на расстоянии не менее одного метра.
На мониторы рекомендуется устанавливать защитные фильтры класса полной защиты (Total Shield), которые обеспечивают практически полную защиту от вредных воздействий монитора в электромагнитном спектре и позволяют уменьшить блик от электронно-лучевой трубки, а также повысить читаемость символов.
Вывод.
В этой главе работы рассматриваются аспекты безопасной работы за компьютером, большей частью глава посвящена электромагнитному излучению электронно-лучевых трубок, используемых в мониторах. В главе приводится описание видов излучений, нормативные значения этого излучения при различных режимах работы за компьютером, а также методы и средства, позволяющие свести к минимуму риск облучения при работе за компьютером.
Заключение
В данной работе был выполнен обзор средств безопасности, которыми располагает операционная система Linux для безопасного функционирования как в качестве пользовательской системы, так и в качестве сервера.
В работе были рассмотрены следующие темы:
· Обзор основных терминов компьютерной безопасности, угроза безопасности, уязвимость системы, атака на систему, рассмотрены основные виды атак;
· Пользовательские записи в Linux, добавление и удаление пользователей, изменение регистрационных записей, структура файла пользовательских регистрационных записей passwd, структура файла паролей shadow, программы управления пользовательскими записями useradd, usermod и userdel, программа установки пароля пользователя passwd, пример безопасной настройки системы путем удаления ненужных регистрационных записей;
· Возможности файловой системы ext2, права доступа, программы изменения прав доступа и владельца файла chmod и chown, атрибуты файлов, программы работы с атрибутами chattr и lsattr, пакет lcap, пользовательские дисковые квоты, пакет для работы с дисковыми квотами quota, пример безопасной настройки системы с помощью прав доступа, расширенных атрибутов и дисковых квот;
· Библиотека PAM, ее возможности, методы ограничения ресурсов с помощью PAM, перечень модулей PAM и их описание, формат конфигурационных файлов PAM, пример безопасной настройки системы с использованием ограничения ресурсов;
· Безопасность на уровне ядра, межсетевой экран netfilter, обзор возможностей брандмауэра netfilter, программный пакет iptables, использование iptables для настройки брандмауэра Linux, пример безопасной настройки межсетевого экрана для работы в небезопасной сети;
· Удаленное управление, протоколы Telnet, rsh, SNMP, описание протокола SSH, программный продукт OpenSSH, описание конфигурационного файла демона sshd, пример настройки безопасного сервера SSH;
· Программный пакет Linux ACLs, листы доступа на основе расширенных атрибутов, программы getfacl и setfacl;
· Система обнаружения и защиты от вторжения LIDS, возможности ядер 2.4, формат конфигурационных файлов LIDS;
· Расширенное окружение обнаружения вторжений AIDE, назначение, принцип работы.
· Излучение монитора, нормативные значения электромагнитных полей для нормальной работы пользователей за компьютером, а также средства и методы уменьшения отрицательного воздействия электромагнитного излучения на организм человека.
Помимо теоретической части к каждому разделу в приложении приводится пример практического применения рассмотренного материала. Все примеры, приведенные в работе, были опробованы в реальных условиях и успешно реализованы на серверах Узбекского внешнеэкономического информационно-коммерческого центра «Узинкомцентр» при Агентстве внешних экономических связей Республики Узбекистан. На момент защиты работы мной были проинсталлированы и настроены семь серверов на базе ОС Linux, четверо из них являются серверами общего назначения, остальные трое – специализированные сервера с ограниченным набором функций. Пять серверов успешно функционируют по сей день. Двое упразднены за ненадобностью.
Список литературы
1. Linux. Алексей Стахнов, издательство «БХВ-Петербург», Санкт-Петербург, 2002.
2. Техническая электронная документация по операционной системе Linux.
Приложение
ПРИМЕР 1.
Исходные данные: ОС Linux RedHat 7.3 без графической оболочки. Назначение – маршрутизатор.
Задача: удалить неиспользуемые регистрационные записи и добавить три записи. Необходимо добавить пользователей anna и pavel, а также одного пользователя с именем systemuser для системных нужд.
Реализация.
Изначально файл пользовательских регистрационных записей может иметь следующий вид:
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
news:x:9:13:news:/etc/news:
uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
gopher:x:13:30:gopher:/var/gopher:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
rpm:x:37:37::/var/lib/rpm:/bin/bash
В зависимости от установленных программ, содержание этого файла может отличаться от приведенного.
Из соображений безопасности следует удалить следующие неиспользуемые в данной конфигурации сервера системные записи: adm, lp, shutdown, halt, news, operator, games, gopher, ftp. Системная запись lp используется только в том случае, если к компьютеру подключен принтер. Настраиваемый компьютер выполняет функции маршрутизатора, следовательно эта регистрационная запись является лишней. Записи shutdown и halt позволяют обычным программам выключать компьютер, что для сервера является только дополнительной брешью в безопасности. Записи news, gopher и ftp используется в том случае, если сервер выполняет функции службы новостей, сервера GOPHER или FTP-сервера. Учетная запись games используется программами графического интерфейса, а поскольку последний отсутствует на маршрутизаторе, эта учетная запись тоже является лишней.
Для удаления пользователей необходимо для каждой учетной записи выполнить команду
userdel <имя_пользователя>
В реализации это будет выглядеть так:
[root@gw /]# userdel adm
[root@gw /]# userdel lp
[root@gw /]# userdel shutdown
[root@gw /]# userdel halt
[root@gw /]# userdel news
[root@gw /]# userdel operator
[root@gw /]# userdel games
[root@gw /]# userdel gopher
[root@gw /]# userdel ftp
Первая часть поставленной задачи выполнена. Далее необходимо добавить указанных пользователей.
[root@gw /]# useradd –m –s /bin/bash –c ‘Normal User’ –d /home/pavel –g users pavel
[root@gw /]# useradd –m –s /bin/bash –c ‘Normal User’ –d /home/pavel –g users anna
[root@gw /]# useradd –r –s /sbin/nologin –c ‘System User’ –d /var/empty systemuser
Приведенные команды создают в системе указанных пользователей, однако, для входа в систему обычным пользователям дополнительно ко всему следует задать еще и пароль. Это выполняют приведенные ниже команды.
[root@gw /]# passwd anna
Changing password for user anna.
New password: <ввод_пароля>
Retype new password: <повтор_ввода_пароля>
passwd: all authentication tokens updated successfully.
[root@gw /]# passwd pavel
Changing password for user pavel.
New password: <ввод_пароля>
Retype new password: <повтор_ввода_пароля>
passwd: all authentication tokens updated successfully.
В результате произведенных действий система будет содержать все необходимые для нормального функционирования системные регистрационные записи, а также двух пользователей anna и pavel, которые смогут заходить и работать в системе.
ПРИМЕР 2.
Исходные данные: ОС Linux RedHat 7.3 без графической оболочки. Назначение – сервер приложений. Программное обеспечение – web-сервер Apache, FTP-сервер Proftpd. Web-сервер выполняется от имени системного пользователя nobody, FTP-сервер – от имени системного пользователя ftpuser. Оба пользователя входят в группу nogroup. На сервере работает web-портал, имеющий распределенную структуру. Весь портал делится на 2 части: администрируемую часть – динамические данные и неадминистрируемую часть – статические данные или оболочка. Администрирование динамической части может осуществляться как с помощью протокола FTP, так и с помощью специально разработанного web-интерфейса. Статические данные может изменять только привилегированный пользователь и только с помощью терминального доступа.
Задача: настройка защищенной конфигурации web-портала с использованием средств разграничения прав доступа.
Реализация.
Допустим, что все файлы объекта защиты, то есть web-портала, находятся в директории /www. В свою очередь, директория /www содержит каталоги ftp и html: первый – для хранения и доступа к файлам по FTP протоколу, второй – для доступа к файлам по протоколу HTTP. Для обеспечения эффективной защиты файлы, находящиеся в каталоге /www, должны иметь доступ только на чтение для пользователей nobody и ftpuser. Файлы, находящиеся в каталоге /www/ftp, должны быть доступны на чтение и на запись как пользователю ftpuser, так и пользователю nobody. В свою очередь, файлы каталога /www/html должны быть доступны только пользователю nobody и с правами только на чтение. Привилегированный пользователь всегда имеет право на чтение и на запись, независимо от прав доступа, установленных для файла.
Учитывая, что оба пользователя nobody и ftpuser принадлежат одной группе nogroup, права на каталог /www могут быть установлены следующим образом:
[root@app /]# chmod 050 /www
[root@app /]# chown root:nogroup /www
[root@app /]# ls –l
…
d---r-x--- 1 root nogroup 4096 Фев 7 19:48 www
…
Первая команда устанавливает права только на чтение и вход в каталог для пользователей группы-владельца каталога. Вторая команда меняет группу-владельца каталога на группу nogroup. Третья команда позволяет просмотреть сделанные изменения. Как видно из результата выполнения третьей команды, каталог www теперь имеет права доступа для группы только на чтение и вход, для пользователя-владельца и всех остальных какие-либо права отсутствуют вообще.
Теперь, когда доступ в каталог www имеют оба системных пользователя, необходимо разграничить права на внутренние каталоги www.
[root@app www]# chown –R ftpuser:nogroup /www/ftp
[root@app www]# chmod –R o-rwx /www/ftp
[root@app www]# chmod –R ug+rw /www/ftp
[root@app www]# chown –R nobody:root /www/html
[root@app www]# chmod –R go-rwx /www/html
[root@app www]# chmod –R u+r /www/html
[root@app www]# ls –l /www
drwxrwx--- 1 ftpuser nogroup 4096 Фев 7 19:55 ftp
dr-x------ 1 nobody root 4096 Фев 7 20:01 html
Первая команда меняет группу-владельца и пользователя-владельца для каталога ftp, вторая – отменяет все права на операции с файлами для всех остальных, третья – добавляет права на чтение и запись для пользователя-владельца и группы-владельца. Ключ –R позволяет рекурсивно изменить параметры у текущего каталога и всех подкаталогов и файлов, хранящихся в нем. Следующая команда “chown –R nobody:root /www/html” позволяет изменить пользователя-владельца для каталога html и всех его подкаталогов и файлов на пользователя nobody. Команда “chmod –R go-rwx /www/html” отменяет все права для группы-владельца и всех остальных. Далее команда “chmod –R u+r /www/html” устанавливает права только на чтение для пользователя-владельца. Последняя команда выводит результат выполненных операций на экран. Задача выполнена!
Следует сделать маленькое замечание: все вышеприведенное верно только в том случае, если маска создания файла по умолчанию при создании каталогов и файлов была определена как 022 (umask 022). В противном случае действия, которые необходимо предпринять для установки необходимых прав доступа, зависят от конкретных настроек системы.
ПРИМЕР 3.
Исходные данные: ОС Linux RedHat 7.3 без графической оболочки. Программное обеспечение – пакет lcap. В данном случае функциональное назначение сервера существенной роли не играет.
Задача: произвести настройку комплексной защиты сервера с использованием расширенных атрибутов (в частности, с помощью атрибута immutable).
Реализация.
Для реализации поставленной задачи необходимо изначально определить, какие файлы в процессе работы могут быть изменены, а какие могут быть изменены только в специальном режиме, например, только в режиме профилактики или обновлении программного обеспечения. В данном случае специальный режим предполагает перевод системы в однопользовательский режим работы.
В общем случае, в обычных условиях содержимое следующих каталогов изменяться не должно, или может изменяться, но достаточно редко:
/boot /etc – в окончательно настроенной системе содержимое этих каталогов изменяться не должно. За редким исключением содержимое каталога /etc может меняться при перенастройке каких-либо программ или сервисов.
/bin – каталог содержит исполняемые файлы, которые могут быть изменены, удалены или добавлены только при обновлении программного обеспечения.
/sbin – в каталоге хранятся исполняемые файлы системных программ, большинство из которых доступно на выполнение только привилегированному пользователю и также не должно изменяться во время работы системы.
/lib – каталог системных библиотек, которые также могут быть изменены только при обновлении программных продуктов.
Следующие команды позволяют установить атрибут immutable для вышеперечисленных директорий и для всех файлов, находящихся в них.
[root@app /]# chattr –R +i /boot /etc /bin /sbin /lib
[root@app /]# lsattr
---i---------- ./boot
…
---i---------- ./etc
-------------- ./root
---i---------- ./bin
-------------- ./initrd
---i---------- ./lib
…
---i---------- ./sbin
Параметр –R как и в предыдущих примерах используется для рекурсивной установки атрибута для всех файлов и каталогов, расположенных ниже в иерархии.
Каталог /usr имеет свою собственную иерархию. В этой иерархии следующие каталоги должны иметь установленный флаг immutable:
/usr/bin /usr/sbin /usr/lib /usr/local/bin /usr/local/sbin /usr/local/lib – перечисленные каталоги имеют то же значение, что и одноименные каталоги корневой иерархии.
/usr/include /usr/local/include – оба каталога содержит заголовочные файлы для компилируемых программ. Заголовочные файлы не должны изменяться ни при каких условиях, ну разве только тогда, когда компьютер используется для разработки программного обеспечения и в заголовочные файлы вносятся изменения.
[root@app /]# chattr –R +i /usr/bin /usr/sbin /usr/lib /usr/include
[root@app /]# lsattr /usr
-------------- /usr/lost+found
---i---------- /usr/bin
---i---------- /usr/lib
-------------- /usr/libexec
---i---------- /usr/sbin
…
---i---------- /usr/include
-------------- /usr/local
---i---------- /usr/src
…
В завершение всех операций можно выполнить программу lcap с параметрами CAP_LINUX_IMMUTABLE и CAP_SYS_RAWIO:
[root@app /]# lcap CAP_LINUX_IMMUTABLE
[root@app /]# lcap CAP_SYS_RAWIO
Также необходимо установить запуск этой команды в стартовые сценарии, чтобы они выполнялись при каждой загрузке системы.
Приведенный пример, опять же, является не всегда применимым, все зависит от конкретной конфигурации системы и конкретных условий ее эксплуатации.
ПРИМЕР 4.
Исходные данные: ОС Linux RedHat 7.3 без графической оболочки. Назначение - сервер приложений. Программное обеспечение – ядро версии 2.4.20, собранное с поддержкой пользовательских квот, пакет quota-3.11. Для пользовательских каталогов выделен отдельный раздел /dev/hda3 объемом 25 Гбайт, смонтированный в директории /home.
Задача: организовать разделение дискового пространства между пользователями с использованием механизма квот. Каждому пользователю необходимо выделить по 10 Мбайт дискового пространства с максимальным количеством возможных файлов – 1000.
Реализация.
Пользовательские квоты распространяются на отдельный раздел жесткого диска и активизируются при загрузке системы. Для включения поддержки квот необходимо в файле /etc/fstab для раздела /home добавить параметр usrquota или grpquota, или оба этих параметра, если нужна поддержка квоты для пользователей и групп одновременно. В данном случае для реализации поставленной задачи необходим только параметр usrquota.
Строка файла /etc/fstab, относящаяся к разделу /home, после изменения может иметь следующий вид:
/dev/hda3 /home ext2 default,usrquota 1 2
Поскольку версии ядер начиная с ветки 2.4 поддерживают новый формат пользовательских квот, который обладает некоторыми преимуществами перед старой версией, использование новой версии будет намного целесообразнее. Вся последующая настройка производится с этим учетом.
Для активации пользовательских квот необходимо перезагрузить систему. При загрузке необходимо выполнить проверку квотируемого раздела, что можно сделать запуском программы quotacheck, а также включить механизм квот выполнением программы quotaon. Эти обе программы имеют множество параметров командной строки, о которых можно узнать из man-руководств, входящих в пакет quota. Стандартная строка запуска этих программ, которая подходит для большинства систем, может иметь вид:
quotacheck –aug
quotaon –aug
Параметр командной строки –a сообщает программе, что необходимо выполнить проверку всех файловых систем, перечисленных в файле fstab, на которых включена поддержка квот, и которые не являются файловыми системами NFS. Параметр –u указывает выполнить проверку квот для пользователей на разделах, перечисленных в файле /etc/mtab. Файл /etc/mtab модифицируется при монтировании и размонтировании любой файловой системы и содержит все файловые системы, смонтированные на текущий момент. Параметр –g выполняет ту же функцию, что и параметр –u, но только для групп. Последний параметр не имеет значения, если квота включена только для пользователей, но, чтобы в дальнейшем при изменении конфигурации не возникало проблем, рекомендую добавлять этот параметр.
Желательно сделать так, чтобы механизм квот активировался сразу после монтирования файловых систем. Монтирование файловых систем при запуске Linux RedHat выполняется в файле /etc/rc.d/init.d/rc.sysinit. В том же файле сразу после монтирования следует код, который запускает программы quotacheck и quoaton с указанными параметрами, если они присутствуют в системе. Следовательно, для Linux RedHat добавлять код запуска программ не нужно, поскольку он уже присутствует по умолчанию. Для других версий ОС Linux этот код, возможно, придется добавлять вручную.
Во время загрузки системы программа quotacheck выполнит проверку файловых систем с включенными квотами на наличие файлов квот и, если файлы отсутствуют, quotacheck создаст их в корневом каталоге этой файловой системы. В данном случае в каталоге /home появится файл aquota.user, в котором будет храниться информация о пользовательских квотах.
Далее, используя программу setquota, необходимо выполнить настройку квот для каждого пользователя, имеющего домашний каталог в разделе /home. Это можно сделать командой:
[root@app /]# setquota –u <имя_пользователя> 10240 0 1000 0 /dev/hda3
Приведенная команда установит ограничение дискового пространства в 10 Мбайт с максимальным количеством возможных файлов – 1000 для указанного пользователя. Для пользователя anna эта команда будет иметь вид:
[root@app /]# setquota –u anna 10240 0 1000 0 /dev/hda3
Если квота остальных пользователей должна быть идентична приведенной, что как раз и требуется для реализации, квоту пользователя anna можно использовать как шаблон. Далее при создании квоты для пользователя igor параметры квотирования пользователя anna просто копируются:
[root@app /]# setquota –u –p anna igor /dev/hda3
В результате выполнения команды пользователь igor получает те же настройки квоты, что и пользователь anna, в данном случае ему выделяется 10 Мбайт на хранение 1000 файлов. Вышеприведенную команду необходимо выполнить для всех пользователей системы.
Просмотр сделанных настроек позволяет выполнить программа repquota. Вызов этой программы с параметрами –a выводит достаточно удобочитаемый подробный отчет по всем файловым системам с включенной поддержкой квот.
[root@app /]# repquota -a
*** Report for user quotas on device /dev/hda3
Block grace time: 00:00; Inode grace time: 00:00
Block limits File limits
User used soft hard grace used soft hard grace
----------------------------------------------------------------
...
anna -- 4 2097152 0 1 0 0
igor -- 4 2097152 0 1 0 0
...
Для обеспечения надежности работы механизма квот, необходимо время от времени производить проверку целостности файла aquota.user на предмет наличия ошибок. Для этой цели можно использовать программу-планировщик cron, которая является стандартной практически для всех версий ОС Linux. На момент проверки файловой системы рекомендуется отключить поддержку механизма квот для этой файловой системы во избежание повреждений. Для этого перед запуском quotacheck необходимо выполнить программу quotaoff. Выполнение указанной последовательности можно реализовать, создав отдельный исполняемый файл, например /usr/sbin/chkquota, который может иметь следующее содержание:
#!/bin/bash
# Turn off quotas
quotaoff –aug
# Check quotas
quotacheck –aug
# Turn on quotas
quotaon –aug
Тогда строка запуска проверки квот в конфигурационном файле /etc/crontab программы cron может выглядеть следующим образом:
0 3 * * 0 root /usr/sbin/chkquota
Эта конфигурация позволяет выполнять проверку квот каждое воскресенье в три часа ночи. Для более детального ознакомления с форматом файла /etc/crontab существуют man-руководства, включенные в пакет cron.
ПРИМЕР 5.
Исходные данные: ОС Linux RedHat 7.3 без графической оболочки. Назначение - сервер приложений. Программное обеспечение – библиотека pam-0.75-32.
Задача: настроить ограничения ресурсов, используемых в процессе работы, для пользователей группы users. Необходимо ограничить количество одновременно запущенных процессов до 20, количество одновременно открытых файлов до 30 и запретить создание каких-либо файлов ядра.
Реализация.
Ограничением ресурсов занимается модуль pam_limits. Этот модуль использует файл конфигурации /etc/security/limits.conf, в котором и задаются необходимые параметры ограничения. Файл состоит из строк, каждая из которых определяет ограничение на определенный вид ресурса. Формат строки следующий:
<субъект_ограничения> <тип> <объект_ограничения> <значение>
Субъектом ограничения может быть либо одиночный пользователь, либо группа, которая определяется добавлением знака @ перед ее именем, либо значок *, означающий, что ограничение должно распространяться на всех без исключения. Для реализации задачи субъектом ограничения будет служить слово @users.
Тип ресурса может быть либо soft, либо hard. Значение soft задает мягкое ограничение на использование указанного ресурса, а значение hard определяет жесткое или абсолютное предельное значение использования ресурса. Для реализации задачи лучше всего будет указать жесткое ограничение на все виды ресурсов.
Объект ограничения указывает, на какой вид ресурса распространяется это ограничение. Для реализации задачи в качестве ограничиваемых объектов необходимо указать следующие параметры:
nproc – количество одновременно запущенных процессов. Должно иметь значение 20.
nofile – количество одновременно открытых файлов. Должно быть установлено в 30.
core – размер файла ядра. Для запрета на создание файлов ядра значение этого параметра должно быть установлено в 0.
В результате файл /etc/security/limits.conf будет иметь вид:
@users hard nproc 20
@users hard nofile 30
@users hard core 0
Для того, чтобы активизировать ограничение ресурсов для конкретного приложения, вызов модуля pam_limits необходимо добавить в соответствующий файл сценария библиотеки PAM. Для локального входа пользователей этим приложением является программа login, которая имеет одноименный файл сценария в каталоге /etc/pam.d. После модификации файл /etc/pam.d/login может выглядеть следующим образом:
#%PAM-1.0
auth required pam_securetty.so
auth required pam_stack.so service=system-auth
auth required pam_nologin.so
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth
session required pam_stack.so service=system-auth
session optional pam_console.so
session required pam_limits.so
Последняя строка предписывает библиотеке PAM использовать модуль pam_limits, причем успешное прохождение через этот модуля является необходимым для успешного завершения процесса аутентификации в целом.
Для терминального доступа по протоколу ssh вызов модуля pam_limits необходимо также добавить в файл /etc/pam.d/sshd. В итоге этот файл может быть таким:
#%PAM-1.0
auth required pam_stack.so service=system-auth
auth required pam_nologin.so
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth
session required pam_stack.so service=system-auth
session optional pam_console.so
session required pam_limits.so
При такой конфигурации как локальный, так и удаленный доступ для пользователей группы users будет иметь ограничения на указанные ресурсы.
ПРИМЕР 6.
Исходные данные: ОС Linux RedHat 7.3 без графической оболочки. Назначение - маршрутизатор. Программное обеспечение – iptables-1.2.5, ядро версии 2.4.22, собранное с поддержкой netfilter и iptables. На сервере установлены три сетевые карты. С помощью двух сетевых карт под символическими именами eth0 и eth1 сервер связывает две локальные TCP/IP сети с различными диапазонами IP адресов. Первая сеть имеет адрес 192.168.0.0, вторая – 192.168.1.0, обе сети имеют маску 255.255.255.0. Сетевая карта eth0 имеет IP адрес 192.168.0.1, а eth1 – 192.168.1.1. Третья сетевая карта с символическим именем eth2 имеет реальный сетевой адрес 144.333.333.333 обеспечивает выход в Интернет.
Задача: настроить межсетевой экран с повышенными требованиями к безопасности. Из сети Интернет необходимо открыть доступ к HTTP-серверу, почтовой службе, функционирующей по протоколу SMTP, серверу имен DNS, а также терминальный доступ по протоколу SSH. Компьютеры обеих локальных сетей помимо перечисленных сервисов должны иметь возможность получать почту с локального сервера посредством протокола POP3. Также необходимо обеспечить обмен информацией между компьютерами двух локальных сетей, обеспечить выход компьютеров сети 192.168.0.0 в Интернет, а из сети 192.168.1.0 – только компьютерам с IP адресами 192.168.1.30 и 192.168.1.45.
Реализация.
Чтобы маршрутизатор функционировал в качестве шлюза, в ядре необходимо поменять значение переменной ip_forward. Это можно сделать командой приведенной далее, а чтобы эта переменная устанавливалась в 1 при загрузке, необходимо в файле /etc/sysctl.conf найти и раскомментировать, если она закомментирована, строку вида “net.ipv4.ip_forward = 0” и изменить значение 0 в этой строке на 1. Если же такой строки нет, ее необходимо добавить. Таким образом, маршрутизатор получает указание работать в качестве шлюза, то есть обрабатывать пакеты, пришедшие из сети и не адресованные локальным процессам, в соответствии с заранее заданной таблицей маршрутизации. Включение этой функции необходимо для обеспечения доступа в сеть Интернет из двух локальных сетей.
[root@app /]# echo 1 > /proc/sys/net/ipv4/ip_forward
Далее приводится последовательность действий, которые необходимо выполнить, чтобы построить требуемую конфигурацию брандмауэра.
[root@app /]# /sbin/iptables –t filter -P INPUT DROP
[root@app /]# /sbin/iptables –t filter -P OUTPUT DROP
[root@app /]# /sbin/iptables –t filter -P FORWARD DROP
Параметр командной строки –Р позволяет установить политику действия по умолчанию для всех пакетов, которые не попали ни под один критерий в правилах INPUT, OUTPUT и FORWARD. Действие DROP означает, что пакет должен быть уничтожен, если ни одно правило цепочки ему не соответствует. Параметр –t указывает, над какой таблицей производится действие. Если этот параметр не указан, используется таблица filter, поэтому использование этого параметра в данном случае не обязательно.
Для распределения нагрузки и простоты в управлении можно создать в таблице filter дополнительные цепочки с разным функциональным назначением.
[root@app /]# /sbin/iptables -N bad_tcp_packets
[root@app /]# /sbin/iptables -N allowed
[root@app /]# /sbin/iptables -N tcp_packets
[root@app /]# /sbin/iptables -N udp_packets
[root@app /]# /sbin/iptables -N icmp_packets
Цепочка bad_tcp_packets предназначена для отфильтровывания пакетов с "неправильными" заголовками. Здесь отфильтровываются все пакеты, которые распознаются как NEW, то есть пакеты, открывающие новое соединение, но не являются SYN пакетами, то есть часть пакета, ответственная за синхронизацию, отсутствует, а так же обрабатываются SYN/ACK-пакеты, имеющие статус NEW. Эта цепочка может быть использована для защиты от вторжения и сканирования портов.
[root@app /]# /sbin/iptables -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset
[root@app /]# /sbin/iptables -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "New not syn:"
[root@app /]# /sbin/iptables -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP
Цепочка tcp_packets является фильтром сетевых сервисов. Именно в этой цепочке будет осуществляться фильтрация tcp-соединений по критерию запрашиваемого сервиса. В качестве такого критерия используется порт, на который приходят запросы на обслуживание. Для того, чтобы только пользователи локальной сети смогли получать почту, в последних двух правилах в качестве дополнительного критерия фильтрации используются символические имена сетевых интерфейсов локальных сетей. В качестве действия пакет посылается в цепочку allowed для последующей проверки более низкого уровня.
[root@app /]# /sbin/iptables -A tcp_packets -p TCP --dport 22 -j allowed
[root@app /]# /sbin/iptables -A tcp_packets -p TCP --dport 25 -j allowed
[root@app /]# /sbin/iptables -A tcp_packets -p TCP --dport 80 -j allowed
[root@app /]# /sbin/iptables -A tcp_packets -p TCP –i eth0 --dport 110 -j allowed
[root@app /]# /sbin/iptables -A tcp_packets -p TCP –i eth1--dport 110 -j allowed
Цепочка allowed используется для дополнительной фильтрации tcp пакетов, прошедших цепочку tcp_packets и разрешенных в ней. Первое правило проверяет, установлен ли в заголовке пакета бит SYN, то есть, является ли пакет первым пакетом установления соединения. Такие пакеты считаются разрешенными и пропускаются. Второе правило проверяет состояние пакета, и если оно либо ESTABLISHED, либо RELATED, то пакет разрешается. Эти состояния присваиваются пакетам, когда соединение уже установлено и ведется обмен данными. Последнее правило просто сбрасывает все остальные пакеты, не попавшие под первые два правила.
[root@app /]# /sbin/iptables -A allowed -p TCP --syn -j ACCEPT
[root@app /]# /sbin/iptables -A allowed -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
[root@app /]# /sbin/iptables -A allowed -p TCP -j DROP
Цепочка udp_packets имеет ту же функцию, что и цепочка tcp_packets, с единственным отличием – в этой цепочке производится фильтрация udp-соединений. Сервис DNS использует как раз протокол UDP для обмена информацией, поэтому правило, которое будет разрешать пакеты DNS, необходимо добавить именно в эту цепочку.
[root@app /]# /sbin/iptables -A udp_packets -p UDP --dport 53 -j ACCEPT
Цепочка icmp_packets предназначена для фильтрации icmp-пакетов. Для нормального функционирования сервера Linux в сети достаточно разрешение только двух типов сообщений: ICMP Echo Request и Time Exceeded.
[root@app /]# /sbin/iptables -A icmp_packets -p ICMP --icmp-type 8 -j ACCEPT
[root@app /]# /sbin/iptables -A icmp_packets -p ICMP --icmp-type 11 -j ACCEPT
Еще раз хочу заметить, что по умолчанию без использования параметра –t все действия производятся в таблице filter.
Теперь перейдем к заполнению основных системных таблиц. Начнем с входящей цепочки INPUT таблицы filter.
[root@app /]# /sbin/iptables -A INPUT -p tcp -j bad_tcp_packets
[root@app /]# /sbin/iptables -A INPUT -i lo –s 127.0.0.0/8 -j ACCEPT
[root@app /]# /sbin/iptables -A INPUT -i lo -s 192.168.0.1 -j ACCEPT
[root@app /]# /sbin/iptables -A INPUT -i lo -s 192.168.1.1 -j ACCEPT
[root@app /]# /sbin/iptables -A INPUT -i lo -s 144.333.333.333 -j ACCEPT
[root@app /]# /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
[root@app /]# /sbin/iptables -A INPUT –p TCP -j tcp_packets
[root@app /]# /sbin/iptables -A INPUT -p UDP -j udp_packets
[root@app /]# /sbin/iptables -A INPUT -p ICMP -j icmp_packets
[root@app /]# /sbin/iptables -A INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG --log-level DEBUG --log-prefix "IPT INPUT packet died: "
Сначала все пакеты должны пройти через цепочку bad_tcp_packets на предмет неправильного заголовка. Далее необходимо принять все пакеты, пришедшие со всех адресов сетевых карт через локальный интерфейс. Такие пакеты могут посылать только локальные приложения, поэтому для их нормального функционирования необходимо пропускать эти пакеты беспрепятственно. Затем следует правило определяющее состояние пакета. Если пакет находится в одном из двух состояний (RELATED или ESTABLISHED), то он тоже беспрепятственно разрешается. Дело в том, что настройка брандмауэра подразумевает 99-процентную достоверность фильтрации приходящих запросов, поэтому, если соединение было разрешено на этапе установления, то при последующем обмене информацией критерии сервиса не проверяются, что позволяет немного увеличить скорость обработки и уменьшить нагрузку на сервер.
Если пакет не удовлетворяет ни одному из перечисленных условий, далее следуют правила, в которых пакет классифицируется по типу используемого протокола. Пакеты протоколов TCP, UDP и ICMP попадают в одноименные цепочки для их фильтрации по типу запрашиваемого сервиса. Если пакет проходит одну из этих цепочек, и к нему не было применено действие ACCEPT, то есть пакет не является запросом к разрешенному сервису, сначала происходит запись параметров запроса в журнальный файл (действие LOG), а затем применяется политика по умолчанию цепочки INPUT, то есть пакет просто уничтожается.
[root@app /]# /sbin/iptables -A FORWARD -p tcp -j bad_tcp_packets
[root@app /]# /sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
[root@app /]# /sbin/iptables -A FORWARD -i eth0 –s 192.168.0.0/24 -j ACCEPT
[root@app /]# /sbin/iptables -A FORWARD -i eth1 –s 192.168.1.30 -j ACCEPT
[root@app /]# /sbin/iptables -A FORWARD -i eth1 –s 192.168.1.45 -j ACCEPT
[root@app /]# /sbin/iptables -A FORWARD -m limit --limit 3/minute --limit-burst 3 -j LOG --log-level DEBUG --log-prefix "IPT FORWARD packet died: "
Аналогично цепочке INPUT, пакеты, проходящие транзитом, сначала фильтруются на предмет неправильного заголовка с помощью таблицы bad_tcp_packets. Пакеты уже установленного соединения разрешаются без дополнительных проверок. Далее все пакеты, пришедшие с интерфейса eth0, через который к серверу подключена сеть 192.168.0.0, разрешаются, что позволяет всем пользователям сети 192.168.0.0 работать в Интернет. Однако, перед этим необходимо настроить NAT, что и будет сделано дальше.
[root@app /]# /sbin/iptables -t nat -A POSTROUTING -o eth2 -j SNAT --to-source 144.333.333.333
Приведенная команда добавляет в цепочку POSTROUTING таблицы nat правило, которое меняет адрес-источник у пакета, покидающего сервер через интерфейс eth2, то есть пакета, который должен быть отправлен в сеть Интернет, на адрес интерфейса сервера. В результате компьютер, у которого нет реального адреса в сети Интернет, получает возможность посредством локального сервера обмениваться информацией с любым сервером в Интернете.
[root@app /]# /sbin/iptables -A OUTPUT -p tcp -j bad_tcp_packets
[root@app /]# /sbin/iptables -A OUTPUT -s 127.0.0.0/8 -j ACCEPT
[root@app /]# /sbin/iptables -A OUTPUT -s 192.168.0.1 -j ACCEPT
[root@app /]# /sbin/iptables -A OUTPUT -s 192.168.1.1 -j ACCEPT
[root@app /]# /sbin/iptables -A OUTPUT -s 144.333.333.333 -j ACCEPT
[root@app /]# /sbin/iptables -A OUTPUT -m limit --limit 3/minute --limit-burst 3 -j LOG --log-level DEBUG --log-prefix "IPT OUTPUT packet died: "
Для цепочки OUTPUT необходимо указать, с каких IP адресов разрешать пакеты. Здесь должны быть перечислены все адреса, которые присвоены сетевым картам сервера.
В конце созданные правила необходимо сохранить командой
[root@app /]# /sbin/iptables-save > /etc/sysconfig/iptables
В дальнейшем при загрузке сервера эти правила автоматически будут загружены в ядро.
На этом настройку брандмауэра можно считать оконченной.
ПРИМЕР 7.
Исходные данные: ОС Linux RedHat 7.3 без графической оболочки. Назначение – маршрутизатор. Программное обеспечение – пакет OpenSSH-3.6.1p2.
Задача: выполнить безопасную настройку сервиса SSH с учетом уязвимостей в версии SSH 1.0.
Реализация.
Версия 1.0 протокола SSH имеет уязвимость, которая позволяет при определенных условиях получить доступ с правами привилегированного пользователя. Версия 2.0 от этой недоработки в системе безопасности избавлена, поэтому ее использование будет самым оптимальным решением. Настройка сервиса SSH по молчанию позволяет использовать обе версии протокола, выбор осуществляется в зависимости от того, какой протокол поддерживает клиентская программа. Чтобы явно запретить использование протокола версии 1.0, необходимо в файл конфигурации sshd_config внести следующую строку
Protocol 2
Эта строка указывает демону sshd использовать только протокол версии 2.0. В противном случае, если клиент запросит разрешение на открытие сеанса с использованием протокола 1.0, запрос будет отвергнут.
OpenSSH версии 3.6 и некоторых более ранних версий имеет специальный параметр UsePrivilegeSeparation, который позволяет запускать процесс sshd от имени аутентифицированного пользователя. После того, как пользователь успешно прошел аутентификацию, основной процесс sshd, запущенный от имени привилегированного пользователя, передает управление дополнительному процессу sshd, который выполняется уже от имени аутентифицированного пользователя. Такая технология позволяет добиться более высокого уровня безопасности по сравнению с предыдущими версиями пакета OpenSSH, в которых доступ пользователей контролировался процессом, запущенным с правами пользователя root. Конфигурация демона по умолчанию уже использует этот параметр, однако в некоторых более ранних версиях этот параметр выключен. Для активации разделения пользовательских привилегий в файл sshd_config необходимо добавить строку
UsePrivilegeSeparation yes
Если сборка пакет производилась из исходных файлов, для настройки разделения привилегий необходимо совершить несколько дополнительных операций. Эти операции хорошо документированы и последовательность их выполнения в документации по установке пакета OpenSSH расписана практически по шагам.
Чтобы ограничить доступ привилегированному пользователю, можно использовать параметр PermitRootLogin. Установка этого параметра в значение
PermitRootLogin no
не позволит пользователю root получить доступ к удаленному терминалу. Получение привилегий пользователя root в таком случае можно будет осуществить только запуском команды su.
Для настройки ограничения доступа существуют также параметры AllowGroups, DenyGroups и AllowUsers, DenyUsers для разрешения и запрета на доступ определенным группам и пользователям соответственно. Например, для запрета доступа всем группам пользователей кроме пользователей группы wheel, конфигурационный файл должен содержать такие строки
DenyGroups *
AllowGroups wheel
Для усиления уровня безопасности можно поменять еще два параметра. Значения этих параметров по умолчанию являются приемлемыми для большинства систем и их изменение в данном случае большой роли не играет. Параметр MaxStartups позволяет задать максимальное количество одновременно запущенных процессов демона sshd, другими словами, этот параметр определяет максимальное количество одновременно подключенных пользователей. По умолчанию ограничение на количество пользователей равно 10. Если в систему должен иметь доступ только администратор и еще пара человек обслуживающего персонала, этот параметр можно выставить в значение 5. Параметр LoginGraceTime определяет период времени, в течение которого, начиная с момента установления соединения, должна быть осуществлена аутентификация пользователя. По умолчанию это значение равно 2 минутам. Если в течение этого времени пользователь не пройдет аутентификацию, серверная сторона просто закроет соединение. Если администрирование производится из локальной сети, для аутентификации может быть достаточно 30 секунд, если же существует хотя бы вероятность, что доступ будет осуществляться через низкоскоростное соединение, например, посредством телефонного соединения, имеет смысл выставить это значение в 60 секунд минимум.
Далее приводится часть конфигурационного файла, сформированная с учетом всего вышеуказанного
…
Protocol 2
UsePrivilegeSeparation yes
PermitRootLogin no
MaxStartups 5
LoginGraceTime 30
…
Сервис SSH изначально настроен с максимальными требованиями к безопасности, поэтому изменение каких-либо дополнительных настроек для стандартной конфигурации не требуется. Изменения могут потребоваться лишь в том случае, если к работе сервиса предъявляются особые требования.
Исходные данные: ОС Linux RedHat 7.3 без графической оболочки. Назначение - сервер приложений. Программное обеспечение – библиотека pam-0.75-32.
Задача: настроить ограничения ресурсов, используемых в процессе работы, для пользователей группы users. Необходимо ограничить количество одновременно запущенных процессов до 20, количество одновременно открытых файлов до 30 и запретить создание каких-либо файлов ядра.
Реализация.
Ограничением ресурсов занимается модуль pam_limits. Этот модуль использует файл конфигурации /etc/security/limits.conf, в котором и задаются необходимые параметры ограничения. Файл состоит из строк, каждая из которых определяет ограничение на определенный вид ресурса. Формат строки следующий:
<субъект_ограничения> <тип> <объект_ограничения> <значение>
Субъектом ограничения может быть либо одиночный пользователь, либо группа, которая определяется добавлением знака @ перед ее именем, либо значок *, означающий, что ограничение должно распространяться на всех без исключения. Для реализации задачи субъектом ограничения будет служить слово @users.
Тип ресурса может быть либо soft, либо hard. Значение soft задает мягкое ограничение на использование указанного ресурса, а значение hard определяет жесткое или абсолютное предельное значение использования ресурса. Для реализации задачи лучше всего будет указать жесткое ограничение на все виды ресурсов.
Объект ограничения указывает, на какой вид ресурса распространяется это ограничение. Для реализации задачи в качестве ограничиваемых объектов необходимо указать следующие параметры:
nproc – количество одновременно запущенных процессов. Должно иметь значение 20.
nofile – количество одновременно открытых файлов. Должно быть установлено в 30.
core – размер файла ядра. Для запрета на создание файлов ядра значение этого параметра должно быть установлено в 0.
В результате файл /etc/security/limits.conf будет иметь вид:
@users hard nproc 20
@users hard nofile 30
@users hard core 0
Для того, чтобы активизировать ограничение ресурсов для конкретного приложения, вызов модуля pam_limits необходимо добавить в соответствующий файл сценария библиотеки PAM. Для локального входа пользователей этим приложением является программа login, которая имеет одноименный файл сценария в каталоге /etc/pam.d. После модификации файл /etc/pam.d/login может выглядеть следующим образом:
#%PAM-1.0
auth required pam_securetty.so
auth required pam_stack.so service=system-auth
auth required pam_nologin.so
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth
session required pam_stack.so service=system-auth
session optional pam_console.so
session required pam_limits.so
Последняя строка предписывает библиотеке PAM использовать модуль pam_limits, причем успешное прохождение через этот модуля является необходимым для успешного завершения процесса аутентификации в целом.
Для терминального доступа по протоколу ssh вызов модуля pam_limits необходимо также добавить в файл /etc/pam.d/sshd. В итоге этот файл может быть таким:
#%PAM-1.0
auth required pam_stack.so service=system-auth
auth required pam_nologin.so
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth
session required pam_stack.so service=system-auth
session optional pam_console.so
session required pam_limits.so
При такой конфигурации как локальный, так и удаленный доступ для пользователей группы users будет иметь ограничения на указанные ресурсы.
ПРИМЕР 6.
Исходные данные: ОС Linux RedHat 7.3 без графической оболочки. Назначение - маршрутизатор. Программное обеспечение – iptables-1.2.5, ядро версии 2.4.22, собранное с поддержкой netfilter и iptables. На сервере установлены три сетевые карты. С помощью двух сетевых карт под символическими именами eth0 и eth1 сервер связывает две локальные TCP/IP сети с различными диапазонами IP адресов. Первая сеть имеет адрес 192.168.0.0, вторая – 192.168.1.0, обе сети имеют маску 255.255.255.0. Сетевая карта eth0 имеет IP адрес 192.168.0.1, а eth1 – 192.168.1.1. Третья сетевая карта с символическим именем eth2 имеет реальный сетевой адрес 144.333.333.333 обеспечивает выход в Интернет.
Задача: настроить межсетевой экран с повышенными требованиями к безопасности. Из сети Интернет необходимо открыть доступ к HTTP-серверу, почтовой службе, функционирующей по протоколу SMTP, серверу имен DNS, а также терминальный доступ по протоколу SSH. Компьютеры обеих локальных сетей помимо перечисленных сервисов должны иметь возможность получать почту с локального сервера посредством протокола POP3. Также необходимо обеспечить обмен информацией между компьютерами двух локальных сетей, обеспечить выход компьютеров сети 192.168.0.0 в Интернет, а из сети 192.168.1.0 – только компьютерам с IP адресами 192.168.1.30 и 192.168.1.45.
Реализация.
Чтобы маршрутизатор функционировал в качестве шлюза, в ядре необходимо поменять значение переменной ip_forward. Это можно сделать командой приведенной далее, а чтобы эта переменная устанавливалась в 1 при загрузке, необходимо в файле /etc/sysctl.conf найти и раскомментировать, если она закомментирована, строку вида “net.ipv4.ip_forward = 0” и изменить значение 0 в этой строке на 1. Если же такой строки нет, ее необходимо добавить. Таким образом, маршрутизатор получает указание работать в качестве шлюза, то есть обрабатывать пакеты, пришедшие из сети и не адресованные локальным процессам, в соответствии с заранее заданной таблицей маршрутизации. Включение этой функции необходимо для обеспечения доступа в сеть Интернет из двух локальных сетей.
[root@app /]# echo 1 > /proc/sys/net/ipv4/ip_forward
Далее приводится последовательность действий, которые необходимо выполнить, чтобы построить требуемую конфигурацию брандмауэра.
[root@app /]# /sbin/iptables –t filter -P INPUT DROP
[root@app /]# /sbin/iptables –t filter -P OUTPUT DROP
[root@app /]# /sbin/iptables –t filter -P FORWARD DROP
Параметр командной строки –Р позволяет установить политику действия по умолчанию для всех пакетов, которые не попали ни под один критерий в правилах INPUT, OUTPUT и FORWARD. Действие DROP означает, что пакет должен быть уничтожен, если ни одно правило цепочки ему не соответствует. Параметр –t указывает, над какой таблицей производится действие. Если этот параметр не указан, используется таблица filter, поэтому использование этого параметра в данном случае не обязательно.
Для распределения нагрузки и простоты в управлении можно создать в таблице filter дополнительные цепочки с разным функциональным назначением.
[root@app /]# /sbin/iptables -N bad_tcp_packets
[root@app /]# /sbin/iptables -N allowed
[root@app /]# /sbin/iptables -N tcp_packets
[root@app /]# /sbin/iptables -N udp_packets
[root@app /]# /sbin/iptables -N icmp_packets
Цепочка bad_tcp_packets предназначена для отфильтровывания пакетов с "неправильными" заголовками. Здесь отфильтровываются все пакеты, которые распознаются как NEW, то есть пакеты, открывающие новое соединение, но не являются SYN пакетами, то есть часть пакета, ответственная за синхронизацию, отсутствует, а так же обрабатываются SYN/ACK-пакеты, имеющие статус NEW. Эта цепочка может быть использована для защиты от вторжения и сканирования портов.
[root@app /]# /sbin/iptables -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset
[root@app /]# /sbin/iptables -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "New not syn:"
[root@app /]# /sbin/iptables -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP
Цепочка tcp_packets является фильтром сетевых сервисов. Именно в этой цепочке будет осуществляться фильтрация tcp-соединений по критерию запрашиваемого сервиса. В качестве такого критерия используется порт, на который приходят запросы на обслуживание. Для того, чтобы только пользователи локальной сети смогли получать почту, в последних двух правилах в качестве дополнительного критерия фильтрации используются символические имена сетевых интерфейсов локальных сетей. В качестве действия пакет посылается в цепочку allowed для последующей проверки более низкого уровня.
[root@app /]# /sbin/iptables -A tcp_packets -p TCP --dport 22 -j allowed
[root@app /]# /sbin/iptables -A tcp_packets -p TCP --dport 25 -j allowed
[root@app /]# /sbin/iptables -A tcp_packets -p TCP --dport 80 -j allowed
[root@app /]# /sbin/iptables -A tcp_packets -p TCP –i eth0 --dport 110 -j allowed
[root@app /]# /sbin/iptables -A tcp_packets -p TCP –i eth1--dport 110 -j allowed
Цепочка allowed используется для дополнительной фильтрации tcp пакетов, прошедших цепочку tcp_packets и разрешенных в ней. Первое правило проверяет, установлен ли в заголовке пакета бит SYN, то есть, является ли пакет первым пакетом установления соединения. Такие пакеты считаются разрешенными и пропускаются. Второе правило проверяет состояние пакета, и если оно либо ESTABLISHED, либо RELATED, то пакет разрешается. Эти состояния присваиваются пакетам, когда соединение уже установлено и ведется обмен данными. Последнее правило просто сбрасывает все остальные пакеты, не попавшие под первые два правила.
[root@app /]# /sbin/iptables -A allowed -p TCP --syn -j ACCEPT
[root@app /]# /sbin/iptables -A allowed -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
[root@app /]# /sbin/iptables -A allowed -p TCP -j DROP
Цепочка udp_packets имеет ту же функцию, что и цепочка tcp_packets, с единственным отличием – в этой цепочке производится фильтрация udp-соединений. Сервис DNS использует как раз протокол UDP для обмена информацией, поэтому правило, которое будет разрешать пакеты DNS, необходимо добавить именно в эту цепочку.
[root@app /]# /sbin/iptables -A udp_packets -p UDP --dport 53 -j ACCEPT
Цепочка icmp_packets предназначена для фильтрации icmp-пакетов. Для нормального функционирования сервера Linux в сети достаточно разрешение только двух типов сообщений: ICMP Echo Request и Time Exceeded.
[root@app /]# /sbin/iptables -A icmp_packets -p ICMP --icmp-type 8 -j ACCEPT
[root@app /]# /sbin/iptables -A icmp_packets -p ICMP --icmp-type 11 -j ACCEPT
Еще раз хочу заметить, что по умолчанию без использования параметра –t все действия производятся в таблице filter.
Теперь перейдем к заполнению основных системных таблиц. Начнем с входящей цепочки INPUT таблицы filter.
[root@app /]# /sbin/iptables -A INPUT -p tcp -j bad_tcp_packets
[root@app /]# /sbin/iptables -A INPUT -i lo –s 127.0.0.0/8 -j ACCEPT
[root@app /]# /sbin/iptables -A INPUT -i lo -s 192.168.0.1 -j ACCEPT
[root@app /]# /sbin/iptables -A INPUT -i lo -s 192.168.1.1 -j ACCEPT
[root@app /]# /sbin/iptables -A INPUT -i lo -s 144.333.333.333 -j ACCEPT
[root@app /]# /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
[root@app /]# /sbin/iptables -A INPUT –p TCP -j tcp_packets
[root@app /]# /sbin/iptables -A INPUT -p UDP -j udp_packets
[root@app /]# /sbin/iptables -A INPUT -p ICMP -j icmp_packets
[root@app /]# /sbin/iptables -A INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG --log-level DEBUG --log-prefix "IPT INPUT packet died: "
Сначала все пакеты должны пройти через цепочку bad_tcp_packets на предмет неправильного заголовка. Далее необходимо принять все пакеты, пришедшие со всех адресов сетевых карт через локальный интерфейс. Такие пакеты могут посылать только локальные приложения, поэтому для их нормального функционирования необходимо пропускать эти пакеты беспрепятственно. Затем следует правило определяющее состояние пакета. Если пакет находится в одном из двух состояний (RELATED или ESTABLISHED), то он тоже беспрепятственно разрешается. Дело в том, что настройка брандмауэра подразумевает 99-процентную достоверность фильтрации приходящих запросов, поэтому, если соединение было разрешено на этапе установления, то при последующем обмене информацией критерии сервиса не проверяются, что позволяет немного увеличить скорость обработки и уменьшить нагрузку на сервер.
Если пакет не удовлетворяет ни одному из перечисленных условий, далее следуют правила, в которых пакет классифицируется по типу используемого протокола. Пакеты протоколов TCP, UDP и ICMP попадают в одноименные цепочки для их фильтрации по типу запрашиваемого сервиса. Если пакет проходит одну из этих цепочек, и к нему не было применено действие ACCEPT, то есть пакет не является запросом к разрешенному сервису, сначала происходит запись параметров запроса в журнальный файл (действие LOG), а затем применяется политика по умолчанию цепочки INPUT, то есть пакет просто уничтожается.
[root@app /]# /sbin/iptables -A FORWARD -p tcp -j bad_tcp_packets
[root@app /]# /sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
[root@app /]# /sbin/iptables -A FORWARD -i eth0 –s 192.168.0.0/24 -j ACCEPT
[root@app /]# /sbin/iptables -A FORWARD -i eth1 –s 192.168.1.30 -j ACCEPT
[root@app /]# /sbin/iptables -A FORWARD -i eth1 –s 192.168.1.45 -j ACCEPT
[root@app /]# /sbin/iptables -A FORWARD -m limit --limit 3/minute --limit-burst 3 -j LOG --log-level DEBUG --log-prefix "IPT FORWARD packet died: "
Аналогично цепочке INPUT, пакеты, проходящие транзитом, сначала фильтруются на предмет неправильного заголовка с помощью таблицы bad_tcp_packets. Пакеты уже установленного соединения разрешаются без дополнительных проверок. Далее все пакеты, пришедшие с интерфейса eth0, через который к серверу подключена сеть 192.168.0.0, разрешаются, что позволяет всем пользователям сети 192.168.0.0 работать в Интернет. Однако, перед этим необходимо настроить NAT, что и будет сделано дальше.
[root@app /]# /sbin/iptables -t nat -A POSTROUTING -o eth2 -j SNAT --to-source 144.333.333.333
Приведенная команда добавляет в цепочку POSTROUTING таблицы nat правило, которое меняет адрес-источник у пакета, покидающего сервер через интерфейс eth2, то есть пакета, который должен быть отправлен в сеть Интернет, на адрес интерфейса сервера. В результате компьютер, у которого нет реального адреса в сети Интернет, получает возможность посредством локального сервера обмениваться информацией с любым сервером в Интернете.
[root@app /]# /sbin/iptables -A OUTPUT -p tcp -j bad_tcp_packets
[root@app /]# /sbin/iptables -A OUTPUT -s 127.0.0.0/8 -j ACCEPT
[root@app /]# /sbin/iptables -A OUTPUT -s 192.168.0.1 -j ACCEPT
[root@app /]# /sbin/iptables -A OUTPUT -s 192.168.1.1 -j ACCEPT
[root@app /]# /sbin/iptables -A OUTPUT -s 144.333.333.333 -j ACCEPT
[root@app /]# /sbin/iptables -A OUTPUT -m limit --limit 3/minute --limit-burst 3 -j LOG --log-level DEBUG --log-prefix "IPT OUTPUT packet died: "
Для цепочки OUTPUT необходимо указать, с каких IP адресов разрешать пакеты. Здесь должны быть перечислены все адреса, которые присвоены сетевым картам сервера.
В конце созданные правила необходимо сохранить командой
[root@app /]# /sbin/iptables-save > /etc/sysconfig/iptables
В дальнейшем при загрузке сервера эти правила автоматически будут загружены в ядро.
На этом настройку брандмауэра можно считать оконченной.
ПРИМЕР 7.
Исходные данные: ОС Linux RedHat 7.3 без графической оболочки. Назначение – маршрутизатор. Программное обеспечение – пакет OpenSSH-3.6.1p2.
Задача: выполнить безопасную настройку сервиса SSH с учетом уязвимостей в версии SSH 1.0.
Реализация.
Версия 1.0 протокола SSH имеет уязвимость, которая позволяет при определенных условиях получить доступ с правами привилегированного пользователя. Версия 2.0 от этой недоработки в системе безопасности избавлена, поэтому ее использование будет самым оптимальным решением. Настройка сервиса SSH по молчанию позволяет использовать обе версии протокола, выбор осуществляется в зависимости от того, какой протокол поддерживает клиентская программа. Чтобы явно запретить использование протокола версии 1.0, необходимо в файл конфигурации sshd_config внести следующую строку
Protocol 2
Эта строка указывает демону sshd использовать только протокол версии 2.0. В противном случае, если клиент запросит разрешение на открытие сеанса с использованием протокола 1.0, запрос будет отвергнут.
OpenSSH версии 3.6 и некоторых более ранних версий имеет специальный параметр UsePrivilegeSeparation, который позволяет запускать процесс sshd от имени аутентифицированного пользователя. После того, как пользователь успешно прошел аутентификацию, основной процесс sshd, запущенный от имени привилегированного пользователя, передает управление дополнительному процессу sshd, который выполняется уже от имени аутентифицированного пользователя. Такая технология позволяет добиться более высокого уровня безопасности по сравнению с предыдущими версиями пакета OpenSSH, в которых доступ пользователей контролировался процессом, запущенным с правами пользователя root. Конфигурация демона по умолчанию уже использует этот параметр, однако в некоторых более ранних версиях этот параметр выключен. Для активации разделения пользовательских привилегий в файл sshd_config необходимо добавить строку
UsePrivilegeSeparation yes
Если сборка пакет производилась из исходных файлов, для настройки разделения привилегий необходимо совершить несколько дополнительных операций. Эти операции хорошо документированы и последовательность их выполнения в документации по установке пакета OpenSSH расписана практически по шагам.
Чтобы ограничить доступ привилегированному пользователю, можно использовать параметр PermitRootLogin. Установка этого параметра в значение
PermitRootLogin no
не позволит пользователю root получить доступ к удаленному терминалу. Получение привилегий пользователя root в таком случае можно будет осуществить только запуском команды su.
Для настройки ограничения доступа существуют также параметры AllowGroups, DenyGroups и AllowUsers, DenyUsers для разрешения и запрета на доступ определенным группам и пользователям соответственно. Например, для запрета доступа всем группам пользователей кроме пользователей группы wheel, конфигурационный файл должен содержать такие строки
DenyGroups *
AllowGroups wheel
Для усиления уровня безопасности можно поменять еще два параметра. Значения этих параметров по умолчанию являются приемлемыми для большинства систем и их изменение в данном случае большой роли не играет. Параметр MaxStartups позволяет задать максимальное количество одновременно запущенных процессов демона sshd, другими словами, этот параметр определяет максимальное количество одновременно подключенных пользователей. По умолчанию ограничение на количество пользователей равно 10. Если в систему должен иметь доступ только администратор и еще пара человек обслуживающего персонала, этот параметр можно выставить в значение 5. Параметр LoginGraceTime определяет период времени, в течение которого, начиная с момента установления соединения, должна быть осуществлена аутентификация пользователя. По умолчанию это значение равно 2 минутам. Если в течение этого времени пользователь не пройдет аутентификацию, серверная сторона просто закроет соединение. Если администрирование производится из локальной сети, для аутентификации может быть достаточно 30 секунд, если же существует хотя бы вероятность, что доступ будет осуществляться через низкоскоростное соединение, например, посредством телефонного соединения, имеет смысл выставить это значение в 60 секунд минимум.
Далее приводится часть конфигурационного файла, сформированная с учетом всего вышеуказанного
…
Protocol 2
UsePrivilegeSeparation yes
PermitRootLogin no
MaxStartups 5
LoginGraceTime 30
…
Сервис SSH изначально настроен с максимальными требованиями к безопасности, поэтому изменение каких-либо дополнительных настроек для стандартной конфигурации не требуется. Изменения могут потребоваться лишь в том случае, если к работе сервиса предъявляются особые требования.
