Безопасность в Linux / Хабр
В новой статье говорим про безопасность в Linux: как настроить и что важно учитывать в процессе. Дополнительно разбираем PAM и модули аутентификации, рассматриваем iptables.
За основу взят один из уроков нашего практического курса «Администрирование Linux Мега».
PAM: модули, флаги, sudoers
PAM — модульная система аутентификации пользователя. Программы могут попросить её произвести аутентификацию пользователя любым доступным методом и абстрагироваться от самого процесса. PAM сделает всё самостоятельно и отдаст результат программе.
PAM используется везде, где требуется аутентификация пользователя или проверка его прав. Например, при подключении через SSH или FTP, а также при повышении привилегий через команду sudo.
Модули PAM находятся в директории lib/security для старых операционных систем типа CentOS и в директории /usr/lib/x86_64-linux-gnu/security для современных ОС вроде последних релизов Ubuntu.
Конфигурационные файлы PAM — в директории /etc/pam.d.
Конфиги модулей — в директории /etc/security.
Типы модулей:
auth — аутентификация пользователя. Проверяют, точно ли пользователь является тем, за кого себя выдает.
account — проверка возможности доступа к серверу. Уточняют, может ли пользователь в данный момент получить доступ к сервису или службе.
password — обновление механизма аутентификации. Отвечают за обновление пароля пользователя.
session — действия при входе. Открываются и закрываются в рамках идентификации, блокируют действия пользователя и производят очистку после завершения его сессии.
Помимо модулей есть флаги контроля:
Required — указанный модуль должен успешно отработать. Остальные модули будут запущены при неудаче, исполнение продолжится по конфигу.
Requisite — указанный модуль должен успешно отработать. Остальные модули не будут запущены при неудаче, исполнение конфига тут же прекратится.
Sufficient — если указанный модель отработает успешно, весь сервис будет считаться доступным. При неудаче этого модуля будут выполняться следующие, стоящие в конфиге после него.
Optional — результат модуля не имеет значения, если этот модуль единственный.
Include — подключить содержимое другого конфига PAM.
Ещё есть sudoers — конфигурационные файлы, в которых описано, каким пользователям разрешено повышать свои привилегии при помощи команды sudo. В Linux-системах обычно действует правило, которое разрешает всем участникам группы voCentOS или sudo в Ubuntu повышать свои привилегии для любых действий.
Основный конфигурационный файл sudoers находится по пути /etc/sudoers, а дополнительные конфиги в /etc/sudoers.d/. Для редактирования правила sudo лучше использовать команду visudo. Она автоматически проверяет синтаксис, и, если там есть ошибки, тут же сообщает о них.
Меры защиты SSH-сервера
SSH-сервер — основная точка входа на сервер.
В целях безопасности вы можете закрыть его за VPN. Но для большей защиты рекомендуется предпринимать дополнительные меры:
Перевести с SSH на нестандартный порт — самая простая, но в то же время самая слабая мера защиты. Злоумышленник может просканировать ваш сервер на предмет открытых портов и выяснить, какой из них слушает SSH. С её помощью вы можете избавиться от бесконечного брутфорса, который преследует на стандартном 22-м порту.
Запретить вход под пользователем root параметром PermitRootLogin. Мера эффективна в сочетании с хорошо настроенной конфигурацией sudoers и SELinux, где у пользователей и их процессов нет доступа к опасным командам. Даже при входе злоумышленника на сервер он не сможет серьёзно навредить системе, так как это невозможно без root-прав.
Запретить вход по паролю параметром Password/Authentication в config-е SSH-сервера. Данная мера спасает от брутфорса и утечки паролей пользователей.
Если приватный ключ зашифрован паролем, взломать его практически невозможно, даже если код сольют.Настроить двухфакторную аутентификацию через SSH. Пользователь сможет подключиться к серверу только, если правильно введёт пароль, приватный ключ или одноразовый код, меняющийся каждые 30 секунд.
Если приватный ключ зашифрован паролем, взломать его практически невозможно, даже если код сольют.К сожалению, ни один из перечисленных серверов не даёт 100% гарантии защиты — почти везде есть уязвимости. Чтобы максимально обезопасить себя, рекомендуется применять все четыре способа. В сумме эти меры добавляют вашей системе очков прочности при взломе.
От теории к практике
Перейдём в терминал на Ubuntu и попробуем настроить двухфакторную аутентификацию через Google Authenticator. Для начала установим пакет apt install libpam-google-authenticator:
root@vm:/home/zaqwer# apt install libpam-google-authenticator
После запуска команды вам зададут несколько вопросов, которые позволят настроить двухфакторную аутентификацию на сервере:
1.
Хотите ли вы, чтобы аутентификация была основана на текущем времени? Ответ: да.
На экране отобразится QR-код — отсканируйте его через Google Authenticator на телефоне. В приложении добавится новый аккаунт и сгенерируется одноразовый пароль. В терминале появятся одноразовые emergency-коды на случай, если вы потеряете доступ к мобильному устройству.
2. Хотите ли вы создать файл с конфигом Google Authenticator для текущего пользователя. Ответ: да. Создастся файл /root/.google.authenticator.
3. Хотите ли вы, запретить несколько использований одного и того же токена аутентификации. Ответ: да. В противном случае по одному и тому же одноразовому коду можно будет войти несколько раз, а это небезопасно. Вы запрещаете многократное использование токена — теперь можно зайти в систему под одним пользователем не чаще, чем раз в 30 секунд до следующей генерации кода. И по умолчанию двухфакторная аутентификация может принять только 3 одноразовых кода: предыдущий код, текущий и следующий.
4. Хотите ли вы повысить количество принимаемых кодов до 17? Например, у вас будут храниться 8 предыдущих кодов, один текущий и ещё 8 будущих. Это не самая лучшая ситуация, поскольку у злоумышленника появляется огромный запас времени, чтобы завладеть кодом. Ответ: нет.
5. Хотите ли вы включить rate-limiting? Ответ: да. Это спасёт вас от брутфорса двухфакторной аутентификации.
Вы ответили на все вопросы, теперь займёмся SSH-сервером — сделаем так, чтобы он работал через Google Authenticator. Откройте файл /etc/pam.d/sshd для настройки PAM-модулей:
root@vm:/home/zaqwer# vim /etc/pam.d/sshd
Здесь уже есть какие-то настройки по умолчанию:
В конце файла допишите две строки. В первой тип модуля — auth required, имя модуля — pam_google_authenticator.so и параметр — nullok. Во второй тип модуля — auth required и модуль — pam_permit.so.
Затем перейдите в конфиг SSH-сервера:
root@vm:/home/zaqwer# vim /etc/ssh/sshd_config
И включите параметр ChallengeResponseAuthenticaton в yes (это нужно, чтобы у нас запросили одноразовый пароль):
Сохраните изменения и перезапустите SSH-сервер:
root@vm:/home/zaqwer# systemctl restart sshd
Теперь попробуем подключиться к серверу.
root@vm:/home/zaqwer# ip a
[zaqwer@archlinux~]$ ssh [email protected]
Видим, что нас всё ещё пускают без двухфакторной аутентификации. Это происходит, потому что настроен вход по ключу, а для SSH-аутентификации он перезаписывает все опции аутентификации по умолчанию. И считается, что ключа достаточно. Система предложит ввести одноразовый пароль только в том случае, если вы попытаетесь войти по паролю.
Теперь нужно сделать так, чтобы и при использовании ключа запрашивался разовый пароль. Для этого возвращаемся в конфиг SSH-сервера:
root@vm:/home/zaqwer# vim /etc/ssh/sshd_config
Добавляем метод AuthenticatonMethods и пишем в нём publickey, password publickey и keyboard-interactive:
Сохраняем изменения и выходим. У нас отвалилась аутентификация по ключу — теперь каждый будет запрашиваться пароль, даже если у нас есть SSH-ключ. Чтобы у нас не спрашивали пароль, если есть SSH-ключ, нужно ввести команду:
root@vm:/home/zaqwer# vim /etc/pam.
d/sshdИ закомментировать строчку:
Это позволит отключить стандартную unix-аутентификацию при доступе через SSH. Аутентификация будет происходит только средствами SSH-сервера, то есть при помощи ключа.
Перезапускаем SSH-сервер ещё раз, подключаемся обратно, и у нас запрашивают одноразовый пароль:
Вводим пароль одноразовый, но нас по какой-то причине не пускают. Чтобы разобраться, в чём проблема, идём в /var/log/auth.log — сюда пишутся данные об аутентификации. Видим, что PAM получил пустой пароль:
Идём в конфиг SSH-сервера:
root@vm:/home/zaqwer# vim /etc/ssh/sshd_config
И видим, что PermitRootLogin отключен:
Пишем PermitRootLogin yes, снова перезапускаем наш SSH-сервер и пробуем подключиться заново. Мы попадаем в систему по одноразовому паролю — отлично, всё работает.
Зададим пароль для root и попробуем раскомментировать строчку в PAM d, которую мы закомментировали, чтобы включить стандартную аутентификацию через средства unix:
root@vm:~# passwd New password Retype new password passwd: password updated successfully
Снова перезапустим sshd, разлогинимся и попробуем подключиться.
Теперь у нас спрашивают пароль:
Посмотрим в лог аутентификации:
root@vm:/home/zaqwer# tail -f /var/log/auth.log
Попробуем подключиться — вводим пароль и одноразовый код. Теперь нас впустили в систему.
И если мы посмотрим в log аутентификации, то увидим, что всё в порядке: мы вошли по паролю.
Iptables: что это и как работает
Iptables — это программа, которая компилирует и фильтрует трафик на сервере. С её помощью можно ограничить доступ к входящим портам или ограничить исходящий трафик по каким-то правилам. Она нужна, чтобы обеспечить безопасность на уровне сити и не оставлять открытых портов.
Конфигурация iptables состоит из цепочек правил. Все пакеты пропускаются через определенную для них последовательность цепочек и при прохождении пакетом цепочки к нему последовательно применяются все правила этой цепочки. Поэтому при использовании iptables стоит отключать другие межсетевые экраны, чтобы не случилась путаница с правилами.
Что важно помнить про iptables:
ограничивает доступ на уровне сети;
конфигурация состоит из цепочек правил;
управляется командой iptables.
Перейдём в терминал и узнаем, как iptables работает.
Посмотреть все текущие правила мы можем командой iptables-save:
root@vm:/home/zaqwer# iptables-save
Мы видим дефолтные цепочки, но не видим никаких правил:
Ещё один вариант, как посмотреть правила с их номерами строк и дополнительной информацией:
root@vm:/home/zaqwer# iptables --line-numbers -L -v -n
Сейчас нет правил ни в одной из цепочек, поэтому все поля пустые:
Начнём с добавления правила, которое будет разрешать все локальные подключения через интерфейс lo:
root@vm:/home/zaqwer# iptables -A INPUT -I lo -j ACCEPT
-A — чтобы добавить правила в конец цепочки;
INPUT — цепочка, в которую добавляем.
-i — чтобы указать интерфейс lo;
-j — чтобы указать, что дальше делать с трафиком;
ACCEPT — принимаем все подключения по локальной сети.
Запускаем и смотрим в правила:
Теперь разрешим icmp-пакеты, которые отправляются командой ping:
root@vm:/home/zaqwer# iptables -A INPUT -p icmp -j ACCEPT
Смотрим правила: теперь их два, как мы и хотели:
Подготовимся к тому, чтобы полностью запретить входящий трафик на сервер. Для этого нужно разрешить получение пакетов в соединениях, которые мы сами и установили:
root@vm:/home/zaqwer# iptables -A INPUT -m conntrack --ctstate ESTABLISHED, RELATED -j ACCEPT
-m — ключ, который определяет критерий, по которому мы идентифицируем пакеты;
сonntrack — этот самый критерий и подсистема ядра, которая отслеживает состояние сетевых соединений;
—ctstate — ключ, указывающий состояние соединений;
RELATED и ESTABLISHED — типы соединений.
Теперь откроем порты, начнём с SH:
root@vm:/home/zaqwer# iptables -A INPUT -m tcp -p tcp --dport 22 -j ACCEPT
—dport — ключ для указаний порта;
22 — порт, на котором работаем SH, поэтому я указываю 22 и –j ACCEPT.
Мы разрешили всё, что нужно. Теперь давайте запретим всё, что мы не разрешили:
root@vm:/home/zaqwer# iptables -A INPUT -p tcp -j REJECT
tcp — пакеты, которые мы ключом -j отправляем в цепочку REJECT.
Точно так же запретим протокол utp:
root@vm:/home/zaqwer# iptables -A INPUT -p utp -j REJECT
Проверим наш список правил:
Пятое и шестое правила запрещают нам входящие подключения, которые мы не разрешили.
Теперь поставим правило на определённую строку. Для этого:
меняем ключ -A, на ключ -I;
пишем цепочку и номер строки — INPUT 5;
указываем порт — 80;
добавляем ключ -s, если хотим разрешить порт только тем, кто пришёл из локальной сети;
указываем сеть, с которой будем принимать, — 192.168.0.0/24.
root@vm:/home/zaqwer# iptables -I INPUT 5 -m tcp --dport 80 -s 192.168.0.0/24 -j ACCEPT
Теперь пятое правило — это уже разрешение 80-го порта для нашей локальной сети.
Если понадобится удалить какое-то правило, воспользуйтесь командой iptables -D:
root@vm:/home/zaqwer# iptables -D INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 80 -j ACCEPT
На этом всё: мы обсудили, что модульная система аутентификации пользователя и где она используется, разобрали меры защиты SSH-сервера, а также рассказали об основных принципах работы iptables.
Базовая настройка безопасности Linux-систем | Помощь
В этом руководстве будут рассмотрены базовые аспекты защиты операционных систем Debian / Ubuntu, CentOS / Fedora от несанкционированного доступа: установка прав пользователей, управление аутентификацией при удаленном подключении, настройка firewall и другие. Материал написан для людей, минимально знакомых с администрированием Linux, но может быть полезен и более опытным пользователям как инструмент самопроверки.
Содержание:
- Автообновления безопасности
- Добавление пользователя с ограниченными правами
- Безопасное подключение через SSH
- Конфигурация Fail2Ban для защиты SSH-подключений
- Настройка firewall
- Добавление, изменение и удаление правил iptables
Автообновления безопасности
Поддержание версий ПО в актуальном состоянии – один из основных способ обеспечения безопасности любой операционной системы.
Обновления программного обеспечения, как правило, направлены не только на исправление обнаруженных багов, но и на устранение критических уязвимостей, ставших известными к моменту апдейта. Существуют аргументы за и против автоматических обновлений серверных ОС. По нашему мнению, риски сбоев в результате апдейтов можно свести к минимуму, если настроить систему только на автообновление безопасности. Тем не менее, решение зависит, в первую очередь, от специфики использования вами сервера.
Обратите внимание, что автоматические обновления применимы только в отношении пакетов, установленных из репозиториев, а не скомпилированных самостоятельно.
- Debian/Ubuntu используют пакет unattended upgrades для автоматических обновлений
- CentOS использует yum-cron
- В дистрибутиве Fedora используется dnf-automatic
Добавление пользователя с ограниченными правами
Если к моменту чтения этого материала вы все еще подключаетесь к вашему серверу от имени пользователя root, обращаем ваше внимание на то, что он имеет неограниченные права на выполнение любых команд, даже если они приводят к критическим системным ошибкам.
Рекомендуем создать пользователя с ограниченными правами и всегда работать через него. Задачи администрирования могут выполняться через sudo (substitute user and do) – временное повышение прав пользователя до уровня администратора.
Создание нового пользователя:
Debian/Ubuntu:
- Создайте пользователя, заменив 1cloud на желаемое имя и укажите пользовательский пароль в ответ на соответствующий запрос. Обратите внимание на то, что пароль вводится вслепую, т.е. вводимые символы не отображаются в командной строке. Для подтверждения введеного пароля используется клавиша Enter:
adduser 1cloud - Добавьте пользователя в группу sudo для наделения его правами суперпользователя:
adduser 1cloud sudo
Теперь вы можете подключаться к вашему серверу от имени нового пользователя. Для выполнения команд, требующих прав администратора, используйте префикс sudo.
Например:
sudo apt-get install htop
CentOS/Fedora:
- Создайте пользователя, заменив 1cloud на желаемое имя, и создайте пароль для его аккаунта:
useradd 1cloud && passwd 1cloud - Добавьте пользователя в группу wheel для передачи ему прав sudo:
usermod –aG wheel 1cloud
Безопасное подключение через SSH
По умолчанию, для подключения к хосту по SSH используется аутентификация по паролю. Но есть более безопасный способ – вход по паре криптографических ключей. В этом случае вместо пароля используется закрытый ключ, который гораздо более устойчив к подбору методом грубой силы (brute-force).
Давайте создадим пару ключей для нового пользователя и настроим сервер на запрет SSH-аутентификации по паролю.
- Генерация пары ключей для аутентификации:
Это действие должно выполняться на вашем локальном компьютере, а не на удаленном сервере. В процессе создания пары 4096-битных RSA ключей вам будет предложено указать пароль для доступа к ним. Вы можете оставить это поле пустым, но в таком случае не сможете использовать созданную пару ключей до сохранения ее в keychain-менеджер локального компьютера. Лучше защитить ваши ключи сложным паролем для обеспечения дополнительной безопасности.
Linux / MacOS:
Внимание! Если вы ранее уже сгенерировали пару RSA ключей, приведенная ниже команда перезапишет их, что может привести к потере доступа к другим хостам с использованием данных ключей. В случае наличия ранее созданных ключей, пропустите следующую команду. Для проверки наличия существующих ключей, выполните:ls ~/.ssh/id_rsa*Для генерации нового комплекта ключей введите:ssh-keygen –b 4096Windows:
Вы можете использовать утилиту PuTTY. Скачайте ее отсюда, распакуйте и запустите ssh-keygen.Выбираем ключ ssh-rsa и длину 2048 бит.
Жмем «Generate».Ключ готов, заполняем кодовую фразу и комментарий к нему. Сохраняем приватный ключ как mykey.ppk и публичный как id_rsa.pub
- Загрузка публичного ключа на сервер:
Замените 1cloud на имя пользователя-владельца ключа, а 1.1.1.1 на ip-адрес вашего сервера.
Linux:
С локального компьютера выполните:ssh-copy-id [email protected]
На сервере (войдя от имени пользователя-владельца ключа) выполните:mkdir –p ~/.ssh && sudo chmod –R 700 ~/.ssh/Затем введите в терминале локального компьютера Mac:scp ~/.ssh/id_rsa.pub [email protected]:~/.ssh/authorized_keysWindows:
Способ 1: Вы можете воспользоваться WinSCP. В окне входа введите ip-адрес вашего сервера, а также имя пользователя и пароль пользователя-владельца ключей. Нажмите Login.
При успешном подключении вы увидите две секции: слева список локальных файлов, справа – файлы на удаленном сервере. В левой секции выберите файл созданного открытого ключа и нажмите «Загрузить» (Upload) в верхней панели. Укажите директорию на сервере, в которую вы хотите сохранить файл, заменив 1cloud на имя вашего пользователя:/home/1cloud/.ssh/authorized_keysСпособ 2: Экспортируйте открытый ключ напрямую из PuTTY KeyGen в окно терминала Putty, в котором осуществлено подключение к удаленному серверу под соответствующим пользователем. Из этого терминала введите:mkdir ~/.ssh; nano ~/.ssh/authorized_keysПриведенная выше команда откроет пустой файл authorized_keys в текстовом редакторе. Скопируйте содержимое файла открытого ключа в созданный документ (обратите внимание, что вставка должна быть идентичной, одной строкой). Затем нажмите CTRL+X , Y , и Enter.
Редактирование прав доступа к загруженному ключу.
Последнее, что нужно сделать с загруженным ключом – предоставить требуемые разрешения. На сервере введите:sudo chmod 700 -R ~/.ssh && chmod 600 ~/.ssh/authorized_keysГруппа команд выше добавляет дополнительный уровень безопасности, запрещая другим пользователям доступ к файлу ключа. - Проверка соединения:
Отключитесь от сервера и повторно подключитесь к нему. Теперь вход должен осуществляться по сгенерированной паре ключей. Если при их создании вы указывали пароль – введите его в ответ на соответствующий запрос.
В процессе создания пары 4096-битных RSA ключей вам будет предложено указать пароль для доступа к ним. Вы можете оставить это поле пустым, но в таком случае не сможете использовать созданную пару ключей до сохранения ее в keychain-менеджер локального компьютера. Лучше защитить ваши ключи сложным паролем для обеспечения дополнительной безопасности.
Жмем «Generate».
Конфигурация службы SSH:
- Запрет ssh-подключения от имени root-пользователя:
Это действие приведет к приему сервером ssh-подключений от всех пользователей, кроме root. Для получения прав суперпользователя после подключения к серверу используйте sudo в начале команды или переключитесь на root-пользователя командой su – или sudo –s
На сервере откройте файл /etc/ssh/sshd_config
Найдите параметр PermitRootLogin и замените его значение на no: - Запрет ssh-аутентификации по паролю:
Это действие отключит ssh-подлючение через ввод пароля – теперь каждый пользователь должен будет использовать пару ключей.
Откройте файл /etc/ssh/sshd_config . В зависимости от Linux-дистрибутива, строка PasswordAuthentification может присутствовать в файле в закомментированном виде (# в начале строки) или отсутствовать – соответственно раскомментируйте или добавьте ее.
Команда для Debian/Ubuntu:nano /etc/ssh/sshd_configПримечание: В случае, если вы подключаетесь к серверу с большого количества разных устройств, вы можете оставить аутентификацию по паролю включенной – тогда вход сможет осуществляться как по ключам, так и по паролям пользователей.
...
PasswordAuthentication no - Перезапустите ssh-демон для применения конфигурации
- Если ваш дистрибутив Linux использует systemctl (CentOS 7, Debian 8, Fedora, Ubuntu 15.10 и старше):
sudo systemctl restart sshdЕсли дистрибутив использует System V или Upstart (CentOS 6, Debian 7, Ubuntu 14.04)sudo service ssh restart
Конфигурация Fail2Ban для защиты SSH-подключений:
Fail2Ban – утилита, блокирующая ssh-подключения с определенного ip-адреса при превышении установленного числа неверных попыток подключения с него.
Так как реальный пользователь обычно не нуждается более чем в трех попытках для ввода верного пароля (в случае с ssh-ключами редко требуется больше одной попытки), «забрасывание» сервера большим количеством запросов может быть попыткой несанкционированного доступа.
Fail2Ban может осуществлять мониторинг различных протоколов, включая SSH, HTTP, FTP и SMTP. При стандартных настройках утилиты контролируется только SSH, так как этот протокол является уязвимым (постоянный прием сервером ssh-подключений с любого ip-адреса).
Примечение: если вы используете Linux-сервер, предоставленный сервисом 1cloud.ru, то пакет Fail2Ban уже предустановлен и контролирует ssh-активность. Информацию об установке и дополнительной конфигурации Fail2Ban вы найдете здесь.
Настройка Firewall
Использование фаервола для блокирования нежелательного входящего трафика на сервере – важнейший инструмент повышения уровня защищенности системы. Фильтрация трафика предотвращает различные типы вторжений, особенно из-за пределов вашей локальной сети.
Рекомендуемый подход при настройке firewall – разрешить только действительно необходимый трафик и полностью запретить остальной.
Iptables – контроллер для netfilter, стандартного фрейморка фильтрации пакетов для Linux. Он включен в большинство дистрибутивов по умолчанию. Тем не менее, этот инструмент позиционируется, как средство расширенной настройки для опытных пользователей. К счастью, существует несколько дополнительных утилит, призванных упросить общение пользователя с iptables. Самые популярные из них: UFW для Debian/Ubuntu, FirewallD для Fedora. Возможно, эти решение являются более подходящими для реализации ваших задач.
В этой статье мы будем рассматривать настройку непосредственно самого iptables.
Просмотр действующих параметров iptables:
IPv4:
sudo iptables -L
IPv6:
sudo ip6tables -L
По умолчанию iptables разрешает все входящие, исходящие и переадресованные подключения:
Chain FORWARD (policy ACCEPT) Chain OUTPUT (policy ACCEPT)Chain INPUT (policy ACCEPT)
target prot opt source destination
target prot opt source destination
target prot opt source destination
Базовая конфигурация iptables:
Конкретные правила фаервола зависят от сервисов, используемых на вашем сервере.
Ниже приведен пример правил, подразумевающих использование вами веб-сервера. Прежде, чем применять правила iptables, спланируйте их исходя из вашей вашей конфигурации:
IPv4 (файл /tmp/v4):
# Allow ping. # Allow SSH connections. # Allow HTTP and HTTPS connections from anywhere # Allow inbound traffic from established connections. # Log what was incoming but denied (optional but useful). # Reject all other inbound. # Log any traffic that was sent to you # Reject all traffic forwarding. COMMIT*filter
# Allow all loopback (lo0) traffic and reject traffic
# to localhost that does not originate from lo0.
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -s 127.0.0.0/8 -j REJECT
-A INPUT -p icmp -m state --state NEW --icmp-type 8 -j ACCEPT
-A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
# (the normal ports for web servers).
-A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
-A INPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT
# This includes ICMP error returns.
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables_INPUT_denied: " --log-level 7
-A INPUT -j REJECT
# for forwarding (optional but useful).
-A FORWARD -m limit --limit 5/min -j LOG --log-prefix "iptables_FORWARD_denied: " --log-level 7
-A FORWARD -j REJECT
IPv6 (/tmp/v6):
# Allow all loopback (lo0) traffic and reject traffic # Allow ICMP # Allow HTTP and HTTPS connections from anywhere # Allow inbound traffic from established connections. # Log what was incoming but denied (optional but useful). # Reject all other inbound. # Log any traffic that was sent to you # Reject all traffic forwarding. COMMIT*filter
# to localhost that does not originate from lo0.
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -s ::1/128 -j REJECT
-A INPUT -p icmpv6 -j ACCEPT
# (the normal ports for web servers).
-A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
-A INPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "ip6tables_INPUT_denied: " --log-level 7
-A INPUT -j REJECT
# for forwarding (optional but useful).
-A FORWARD -m limit --limit 5/min -j LOG --log-prefix "ip6tables_FORWARD_denied: " --log-level 7
-A FORWARD -j REJECT
Применение приведенных выше правил на различных дистрибутивах Linux:
Arch Linux:
- Создайте файлы /etc/iptables/iptables.rules и /etc/iptables/ip6tables.rules . Вставьте правила из примеров выше (/tmp/v4 и /tmp/v4) в созданные документы соответственно.
- Импортируйте эти правила для немедленного применения iptables:
sudo iptables-restore < /etc/iptables/iptables. rulessudo ip6tables-restore < /etc/iptables/ip6tables.rules - По умолчанию в Arch iptables не запущен. Запустите его:
sudo systemctl start iptables && sudo systemctl start ip6tablessudo systemctl enable iptables && sudo systemctl enable ip6tables - Используйте конфигурацию pre-network.conf с ArchWiki чтобы iptables стартовал до подключения сервера к сети.
rulesCentOS / Fedora:
Примечание: применяемые правила хранятся в файлах /etc/sysconfig/iptables и /etc/sysconfig/ip6tables
В этих дистрибутивах FirewallD предлагается для управления правилами фаервола вместо непосредственного администрирования iptables.
CentOS 6 / Fedora 19 и ниже:
sudo service iptables save
sudo service ip6tables save
Создайте файлы /tmp/v4 и /tmp/v6.
Вставьте содержимое приведенных выше примеров (/tmp/v4 и /tmp/v6) в созданные документы.
Импортируйте правила из этих временных файлов:
sudo iptables-restore < /tmp/v4
sudo ip6tables-restore < /tmp/v6
Сохраните параметры.
CentOS 7 / Fedora 20 и выше:
Debian / Ubuntu:
Вы можете управлять iptables вручную или использовать утилиту UFW. Ниже рассмотрен первый вариант:
- Создайте файлы /tmp/v4 и /tmp/v6 . Вставьте содержимое приведенных выше примеров (/tmp/v4 и /tmp/v6) в созданные документы.
- Импортируйте добавленные правила для их немедленного применения:
sudo iptables-restore < /tmp/v4sudo ip6tables-restore < /tmp/v6 - Пакет iptables-persistent автоматизирует загрузку правил iptables при запуске Debian/Ubuntu сервера. Установите его из репозиториев:
sudo apt-get install iptables-persistentОтветьте yes в ответ на появляющиеся запросы о сохранении текущих правил фаервола.
Проверка правил iptables
Проверьте правила фаервола вашего сервера на применение внесенных изменений:
В результате должны отобразиться следующие правила:
IPv4:
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destinationChain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo any anywhere anywhere
0 0 REJECT all -- !lo any loopback/8 anywhere reject-with icmp-port-unreachable
0 0 ACCEPT icmp -- any any anywhere anywhere icmp destination-unreachable
0 0 ACCEPT icmp -- any any anywhere anywhere icmp echo-request
0 0 ACCEPT icmp -- any any anywhere anywhere icmp time-exceeded
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh state NEW
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:http state NEW
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:https state NEW
0 0 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
0 0 LOG all -- any any anywhere anywhere limit: avg 5/min burst 5 LOG level debug prefix "iptables_INPUT_denied: "
0 0 REJECT all -- any any anywhere anywhere reject-with icmp-port-unreachable
pkts bytes target prot opt in out source destination
0 0 LOG all -- any any anywhere anywhere limit: avg 5/min burst 5 LOG level debug prefix "iptables_FORWARD_denied: "
0 0 REJECT all -- any any anywhere anywhere reject-with icmp-port-unreachable
IPv6:
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all lo any anywhere anywhere
0 0 REJECT all !lo any localhost anywhere reject-with icmp6-port-unreachable
0 0 ACCEPT ipv6-icmp any any anywhere anywhere
0 0 ACCEPT tcp any any anywhere anywhere tcp dpt:http state NEW
0 0 ACCEPT tcp any any anywhere anywhere tcp dpt:https state NEW
0 0 ACCEPT all any any anywhere anywhere state RELATED,ESTABLISHED
0 0 LOG all any any anywhere anywhere limit: avg 5/min burst 5 LOG level debug prefix "ip6tables_INPUT_denied: "
0 0 REJECT all any any anywhere anywhere reject-with icmp6-port-unreachable
pkts bytes target prot opt in out source destination
0 0 LOG all any any anywhere anywhere limit: avg 5/min burst 5 LOG level debug prefix "ip6tables_FORWARD_denied: "
0 0 REJECT all any any anywhere anywhere reject-with icmp6-port-unreachable
pkts bytes target prot opt in out source destination
- Перезагрузите сервер:
sudo reboot - Введите эти команды для отображения действующих правил:
sudo iptables -vL
sudo ip6tables –vL
Теперь мы убедились в том, что добавленные правила firewall активны.
В дальнейшем при установке новых пакетов, требующих доступ к сети, не забудьте внести соответствующие изменения в конфигурацию iptables.
Добавление, изменение и удаление правил iptables
Правила iptables работают последовательно от первого к последнему. Это означает, что добавление новых правил не может осуществляться с помощью команд. iptables –A ip6tables –A Для этого необходимо использовать: iptables –I или ip6tables –I
Добавление правил:
Добавляемые правила должны размещаться в последовательном порядке с учетом других правил в цепочке. Для отображения нумерованного списка правил введите:
sudo iptables –L –line-numbers
Допустим, мы хотим добавить новое правило в приведенный выше пример (/tmp/v4) для разрешения входящих подключений на порту 8080 TCP. Добавим его на позицию 9 цепочки INPUT:
sudo iptables -I INPUT 9 -p tcp --dport 8080 -j ACCEPT
Замена правил:
Процедура замены правил очень похожа на их добавление, но для этого используется команда: iptables –R Предположим, вы хотите изменить параметр сохранения списка заблокированных подключений в лог с пяти записей в минуту до трех, а правило LOG находится на 11-й позиции цепочки INPUT.
Соответствующая команда будет выглядеть следующим образом:
sudo iptables -R INPUT 11 -m limit --limit 3/min -j LOG --log-prefix "iptables_INPUT_denied: " --log-level 7
Удаление правил:
Удаление правил iptables также происходит с указанием номера позиции удаляемого правила. Например, чтобы удалить параметр, который мы ранее добавляли (см. выше) для разрешения подключений на порту 8080 TCP, необходимо ввести команду:
sudo iptables -D INPUT 9
Важно: измененные правила не вступают в силу автоматически. Для их применения совершите действия в соответствии с процедурой, используемой для вашего дистрибутива Linux (см. пункт «Базовая конфигурация iptables»).
На этом базовую конфигурацию инструментов обеспечения безопасности вашего Linux-сервера можно считать завершенной, но тему нельзя считать исчерпанной – в наших будущих материалах мы будем рассматривать и другие способы повышения уровня безопасности Linux-систем.
P. S. Другие инструкции:
- Настройка SSH-ключей для подключения к Linux
- Настройка Linux-файрвола iptables: Руководство для начинающих
- Запуск команд в фоновом режиме
- Как изменить пароль администратора в Linux
Средняя оценка: 5,0, всего оценок: 20 Спасибо за Вашу оценку! К сожалению, проголосовать не получилось. Попробуйте позже
5 советов по началу работы с безопасностью серверов Linux
Опубликовано: 25 октября 2019 г. | | на Кен Хесс (выпускники Sudoer, Red Hat)
Изображение
«Полицейская безопасность» от JobsForFelonsHub под лицензией CC BY 2.0
Безопасность — популярная тема среди системных администраторов Linux. Каждый форум, который я читаю, каждая конференция, которую я посещаю, и каждая ИТ-ориентированная дискуссия, в которой я участвую, всегда обращаются к безопасности, а затем разговоры неизбежно обращаются к безопасности Linux.
Это мой опыт, и моя неспособность не подслушивать технические разговоры о Linux стала источником этой статьи. Это мои пять рекомендаций для начала более безопасной установки Linux прямо из коробки.
[Хотите попробовать Red Hat Enterprise Linux? Загрузите бесплатно сейчас.]
Минимум
Когда я устанавливаю Linux, я всегда устанавливаю самую маленькую возможную версию. Для CentOS или Red Hat Enterprise Linux это означает минимальную установку. Я предпочитаю начинать с малого, а затем добавлять то, что мне нужно, а не удалять то, что мне не нужно. Дополнительным преимуществом выбора минимальной установки является то, что размер системы также минимален. Дисковое пространство дешево, но кто хочет тратить дисковое пространство на лишние приложения, которые могут вернуться, чтобы преследовать нас позже с проблемами безопасности? Все, что мне нужно изначально, — это базовая установка с сервером SSH, чтобы я мог подключиться к нему и управлять им удаленно.
Я могу добавить все, что мне нужно, через DNF позже.
Серверы являются зонами без графического интерфейса пользователя
Если ваша система Linux будет жить как сервер, не устанавливайте графический интерфейс пользователя. Несколько человек спорят об этом. С точки зрения безопасности установка графического интерфейса, даже небольшого, требует множества дополнительных программных пакетов. Любой из них может быть подвержен проблемам безопасности. Некоторые пакеты с графическим интерфейсом могут открывать порты в вашей системе, что нежелательно, поскольку это действие увеличивает поверхность атаки. Наконец, производительность вашей системы может (будет) страдать от наличия графического интерфейса, потому что GUI потребляют много системных ресурсов.
Оставьте графический интерфейс на рабочем столе. Изучите командную строку.
Брандмауэры являются обязательными
В системах на базе Red Hat (Red Hat Enterprise Linux, Fedora и CentOS) firewalld является брандмауэром по умолчанию.
Используй это. Этот хост-брандмауэр защищает вашу систему от нежелательных вторжений через все порты, кроме тех, которые вы явно разрешили. Вы также можете выборочно ограничить исходящий трафик через брандмауэр.
Однако наиболее безопасным методом ограничения исходящего трафика является настройка внутреннего интернет-прокси-сервера и разрешение исходящего трафика только на эту систему. Вы также можете разрешить SSH-трафик в свою локальную подсеть, если вам нужно подключиться из одной системы в другую. Хост-брандмауэры могут вызывать разочарование при тестировании подключения между системами, особенно для вновь настроенных служб, но это стоит нескольких минут разочарования. Повесьте табличку прямо над вашим монитором (мониторами) в своей кабинке с надписью «ПРОВЕРЬТЕ БРАНДМАУЭР», и все будет в порядке.
SELinux стоит изучить
Ах, ненавистный и непонятый SELinux. Как правило, системные администраторы полностью отключают или удаляют SELinux, вместо того чтобы иметь дело с чрезвычайной тревогой, связанной с безопасностью, которую он вызывает.
Мой совет — оставить эту службу включенной, включенной и принудительной.
SELinux использует так называемый обязательный контроль доступа (или MAC), тогда как брандмауэры используют контроль доступа на основе правил, а стандартные разрешения *nix известны как дискреционный контроль доступа. Прежде чем отказаться от SELinux и отключить его, ознакомьтесь с документацией по его настройке. Поскольку в большинстве систем работает только небольшой набор служб, настройка не так уж и сложна, в отличие от опасности, связанной с тем, что эта служба не включена.
SELinux должен быть настроен особым образом, позволяющим маркировать файлы, настраивать их в контексте безопасности и пару раз перезагружать, чтобы все заработало. Прочтите документацию. SELinux, вопреки распространенному мнению, НЕ является брандмауэром (или его заменой), решением для защиты от вредоносных программ, заменой механизмов проверки подлинности, таких как многофакторная проверка подлинности, или панацеей безопасности, если только можно представить.
SELinux — это защита от повышения привилегий со стороны служб, работающих от имени пользователя root. Отключать, наверное, плохая идея. Правильное использование SELinux — это дополнительный уровень защиты, необходимый в наши дни передовых постоянных угроз и более умных вредоносных программ.
Удаленный вход в систему root — плохая идея
По умолчанию в системах на основе Red Hat пользователь root может войти удаленно через SSH. Я могу понять, почему эта функция установлена по умолчанию во вновь установленных системах, но ее следует отключить, как только система заработает и начнет работать, а учетные записи с доступом sudo будут созданы.
Отключение удаленного входа в систему root не позволяет злоумышленнику использовать методы грубой силы для подбора вашего пароля root. Попытки регистрируются, но не влияют на вашу безопасность, поскольку учетная запись root не может войти удаленно. А если у вас установлен сценарий или служба предотвращения вторжений, повторные попытки автоматически приводят к созданию нового правила DROP или созданию /etc/hosts. запись.
deny
Проверьте, включен ли удаленный вход в систему root:
$ sudo grep -i root /etc/ssh/sshd_config Разрешить RootLogin да # настройка "PermitRootLogin без пароля". #ChrootDirectory none
Если вы видите PermitRootLogin yes , пользователь root может войти удаленно через SSH. Отредактируйте файл /etc/ssh/sshd_config и поместите # , чтобы закомментировать строку, или измените yes на no . Перезапустите sshd служба для принятия новой конфигурации:
$ sudo systemctl перезапуск sshd.service
Пользователь root больше не сможет войти через SSH.
Подведение итогов
Прочитайте любой опрос за последние десять лет, и вы увидите, что безопасность является главным приоритетом или заботой системных администраторов. Сделайте своим приоритетом , чтобы защитить систему по крайней мере с помощью этих пяти советов, прежде чем ваши системы будут запущены в эксплуатацию.
Безопасность — это не то, что можно откладывать или расслабляться. Эти пять советов помогут вам создать более безопасную систему в сети и сделать вашу сеть более безопасным местом для работы.
Темы: Администрирование Linux Безопасность Linux. Отдел информационной безопасности составил списки CIS до наиболее важных шагов для ваших систем, уделив особое внимание проблемам конфигурации, уникальным для вычислительной среды Техасского университета в Остине.
Как пользоваться контрольным списком
Распечатайте контрольный список и отметьте каждый пункт, который вы выполнили, чтобы убедиться, что вы выполнили важные шаги для обеспечения безопасности вашего сервера. Управление информационной безопасности использует этот контрольный список во время оценки рисков как часть процесса проверки безопасности серверов.
Как читать контрольный список
Шаг – номер шага в процедуре. Если для этого шага имеется примечание UT , номер примечания соответствует номеру шага.
Чек (√) — администратор должен отметить его, когда заполнит эту часть.
To Do – Основные инструкции по усилению защиты соответствующей системы
CIS – Справочный номер в Центре интернет-безопасности Red Hat Enterprise Linux 7 Benchmark v1.1.0 . В документе CIS гораздо более подробно описывается, как выполнить каждый шаг.
UT Note – UT Note в нижней части страницы содержит дополнительные сведения о шаге для университетской вычислительной среды.
Cat I — Для систем, включающих Категория I данные , необходимые шаги обозначены ! символ. Все шаги рекомендуются.
Кат. II/III – Для систем, включающих Категория-II или -III данные , все шаги рекомендуются, а некоторые обязательны (обозначаются ! ).
Min Std – в этом столбце содержится ссылка на конкретное требование для университета в Минимальных стандартах безопасности для систем 9Документ 0092.
Информация о сервере
| MAC Address | |
|---|---|
| IP Address | |
| Machine Name | |
| Asset Tag | |
| Administrator Name | |
| Date |
Контрольный список
| Step | √ | To Do | CIS | UT Note | Cat I | Cat II/III | Min Std | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Подготовка и установка | 5 | 0154 | ||||||||||
| 1 | Если компьютер устанавливается впервые, защитите его от враждебного сетевого трафика, пока операционная система не будет установлена и защищена. | § | ! | ! | 4.5.1 | |||||||
| 2 | Установите пароль BIOS/прошивки. | ! | 4.5.1 | |||||||||
| 3 | Настройте порядок загрузки устройства, чтобы предотвратить несанкционированную загрузку с альтернативного носителя. Используйте последнюю возможную версию RHEL. | 1,7 | ! | ! | 4.5.2 | |||||||
| Filesystem Configuration | ||||||||||||
| 5 | Create a separate partition with the nodev, nosuid, and noexec options set for /tmp | 1.1.1- .4 | § | |||||||||
| 6 | .0155 | 1. 1.{5,7,8,9} | § | |||||||||
| 7 | Bind mount /var/tmp to /tmp | 1.1.6 | ||||||||||
| 9 | Set nodev, nosuid, and noexec options on /dev/shm | 1.1.14-.16 | ||||||||||
| 10 | Set sticky bit on all каталоги с доступом для записи во всем мире. Система0155 | |||||||||||
| 11 | Зарегистрируйтесь на сервере Red Hat, чтобы он мог получать системные обновления. | 1.2.1 | § | ! | ! | 4.5.2 | ||||||
| 12 | Установите ключ Red Hat GPG и включите gpgcheck. | 1.2.2-.3 | ||||||||||
| Secure Boot Settings | ||||||||||||
| 13 | Set user/group owner to root, and permissions чтение и запись только для root, в /boot/grub2/grub. cfg | 1.5.1-.2 | § | |||||||||
| 14 | Установить пароль загрузчика. | 1.5.3 | ||||||||||
| 15 | 9015 Снимите оконную систему X. шрифт | |||||||||||
| Process Hardening | ||||||||||||
| 17 | Restrict core dumps. | 1.6.1 | § | |||||||||
| 18 | Включить случайное размещение областей виртуальной памяти. | 1.6.2 | § | ! | ||||||||
| OS Hardening | ||||||||||||
| 19 | Remove legacy services (e. g., telnet-server; rsh, rlogin, rcp ; ypserv, ypbind; tftp, tftp-сервер; talk, talk-сервер). | 2.1.{1,3-10} | ! | ! | ||||||||
| 20 | Отключите все службы и приложения, запускаемые xinetd или inetd, которые не используются. | § | ! | ! | 4.5.4 | |||||||
| 21 | Если возможно, удалите xinetd. | 2.1.11 | § | ! | ||||||||
| 22 | Отключить устаревшие службы (например, chargen-dgram, chargen-stream, daytime-dgram, daytime-stream, echo-dgram, echo-stream, tcpmux-stream, tcpmux-stream). | 2.1.{12-18} | ! | ! | ||||||||
| 23 | Отключите или удалите службы сервера, которые не будут использоваться (например, FTP, DNS, LDAP, SMB, DHCP, NFS, SNMP и т. д.). | ! | 4.5.4 | |||||||||
| 24 | Установить umask демона. | 3.1 | ||||||||||
| Network Security and Firewall Configuration | ||||||||||||
| 25 | Ограничить подключения к службам, запущенным на хосте, только авторизованным пользователям службы через брандмауэры и другие технологии контроля доступа. | 4,7 | § | ! | ! | 4.5.5 | ||||||
| 26 | Отключить IP-переадресацию. | 4.1.1 | ||||||||||
| 27 | Отключить переадресацию отправки пакетов. | 4.1.2 | ||||||||||
| 28 | 9015 прием пакетов. | 4.2.1 | ||||||||||
| 29 | перенаправление | 4.2.2 | ||||||||||
| 30 | Включить игнорирование широковещательных запросов. | 4.2.5 | ||||||||||
| 31 | . | 4.2.6 | ||||||||||
| 32 | Включить файлы cookie TCP/SYN. | 4.2.8 | ||||||||||
| Remote Administration Via SSH | ||||||||||||
| 33 | Set SSH protocol to 2. | 6.2.1 | § | ! | ! | 4. 5.6 | ||||||
| 34 | Установите для уровня ведения журнала SSH значение INFO. | 6.2.2 | § | ! | ! | |||||||
| 35 | Отключить вход в систему SSH root. | 6.2.8 | § | |||||||||
| 36 | Задайте для разрешения пустых паролей SSH значение no. | 6.2.9 | ! | ! | ||||||||
| System Integrity and Intrusion Detection | ||||||||||||
| 37 | Install and configure AIDE. | 1.3.1-.2 | § | 1.4.1-6 | § | |||||||
| 39 | ||||||||||||
| 39 | ||||||||||||
| 39 | ||||||||||||
| § | ||||||||||||
| 40 | Настройка протокола сетевого времени (NTP). | 3,6 | § | ! | ||||||||
| 41 | Включить системный учет (аудит). | 5.2 | § | ! | 4.6.1 | |||||||
| 42 | Установите и настройте rsyslog. | 5.1.1-.4 | § | ! | ||||||||
| 43 | Все права администратора или root должны регистрироваться. | ! | 4.6.4 | |||||||||
| 44 | Настройте доставку журналов на отдельное устройство/службу (например, Splunk ). | 5.1.5 | § | |||||||||
| Files/Directory Permissions/Access | ||||||||||||
| 45 | Integrity checking of system учетные записи, членство в группах и связанные с ними привилегии должны быть включены и протестированы. | § | ! | 4.5.9 | ||||||||
| PAM Configuration | ||||||||||||
| 46 | Ensure that the configuration files for PAM, /etc /pam.d/* безопасны. | 6.3 | § | ! | ! | 4.5.12 | ||||||
| 47 | Обновите алгоритм хеширования паролей до SHA-512. | 6.3.1 | ! | |||||||||
| 48 | Установите требования к созданию пароля. | 6.3.2 | § | ! | ! | |||||||
| 49 | Ограничить вход root системной консолью. | 6.4 | § | |||||||||
| Warning Banners | ||||||||||||
| 50 | If network or physical access службы запущены, убедитесь, что отображается предупреждающий баннер университета. | 6.2.14, 8.1 | § | ! | ! | 4.5.10 | ||||||
| 51 | Если система разрешает вход через графический интерфейс пользователя, убедитесь, что перед входом в систему отображается предупреждающий баннер университета. | 8.3 | § | ! | ||||||||
| Рекомендации по защите от вирусов | ||||||||||||
| 52 | 9015-вирусное программное обеспечение и включите антивирусное программное обеспечение. | § | 4.3.1 | |||||||||
| 53 | ||||||||||||
| . | § | 4.3.3 | ||||||||||
| Additional Security Notes | ||||||||||||
| 54 | Systems will provide secure storage for Confidential (Category -I) Данные университета по мере необходимости. Безопасность может быть обеспечена такими средствами, как, помимо прочего, шифрование, управление доступом, аудит файловой системы, физическая защита носителя данных или любое их сочетание, если это будет сочтено целесообразным. |
UT Примечание: Приложение
В этом списке представлены конкретные задачи, связанные с вычислительной средой Техасского университета в Остине.
| 1 | Если другие альтернативы недоступны, это можно сделать, установив маршрутизатор/брандмауэр SOHO между сетью и защищаемым хостом. |
|---|---|
| 5 | Поскольку /tmp предназначен для записи всем пользователям, создание для него отдельного раздела может предотвратить исчерпание ресурсов. Параметр nodev запрещает пользователям создавать или использовать блочные или специальные символьные устройства. |
| 6 | Рекомендуется использовать несколько разделов для защиты от исчерпания ресурсов в случае заполнения раздела, а также для обеспечения возможности установки различных параметров для отдельных разделов для обеспечения повышенной безопасности (например, nodev, nosuid, noexec) . |
| 11 | Установите и используйте подключаемый модуль yum-security. yum install yum-security Чтобы получить список всех обновлений, имеющих отношение к безопасности, и получить код повторной проверки наличия обновлений безопасности, используйте: yum —security check-update Для применения обновлений, связанных с безопасностью, используйте: yum —security update |
| 13 | Установка прав пользователя/группы на root и разрешений на чтение и запись только для root рекомендуется для предотвращения просмотра или изменения параметров загрузки пользователями без полномочий root. |
| 15 | Простой способ отключить графический интерфейс — изменить уровень запуска по умолчанию. Отредактируйте файл /etc/inittab. Найдите строку, содержащую следующее: id:5:initdefault: Заменить «5» на «3». Затем строка будет выглядеть так: id:3:initdefault: |
| 17 | Дампы ядра предназначены для определения причины прерывания программы. Они могут содержать важные или конфиденциальные данные из памяти. Рекомендуется отключать или ограничивать дампы ядра. Система должна быть настроена таким образом, чтобы программы setuid не создавали дампы ядра. |
| 18 | Добавьте следующую строку в файл /etc/sysctl.conf: kernel.randomize_va_space = 2 |
| 20 | Отключите все службы xinetd, которые вам абсолютно не нужны, установив «indisable=yes». Настройка оболочек TCP для управления доступом. Ненужные службы можно отключить с помощью: $ sudo chkconfig off Чтобы проверить прослушиваемые службы, используйте: $ lsof \| grep ‘*:’ или $ sudo netstat \—tulp
Гораздо более подробная информация об услугах доступна в эталонных документах CIS. Например, команда ntsysv \—level 345 настраивает уровни выполнения 5, 010, 4 и . |
| 21 | Если службы xinetd не требуются, полностью отключите xinetd: остановка службы sudo xinetd; sudo chkconfig xinetd off |
| 25 | RHEL7 поставляется с firewalld, однако вместо него можно установить и использовать iptables. Это задокументировано по адресу: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.html Ниже приведен список некоторых ресурсов iptables: |
| 33 | If you decide to utilize SSH , the ISO highly recommends the following: |
| 34 | INFO — это базовый уровень ведения журнала, который фиксирует действия пользователя при входе в систему и выходе из нее. |
| 35 | Не разрешать вход root через SSH. Если root-доступ через SSH абсолютно необходим, попросите администраторов сначала пройти аутентификацию с помощью отдельной учетной записи, а затем использовать su или sudo. Это делается для предотвращения удаленных атак методом грубой силы на учетную запись пользователя root, а также для создания контрольного журнала действий администратора в случае компрометации. |
| 37 | За пользование Tripwire взимается лицензионный сбор. Консоль управления Tripwire может быть очень полезна для управления более сложными установками. AIDE — это бесплатный инструмент, доступный на SourceForge. SamHain — еще один бесплатный инструмент, как и OSSEC HIDS. |
| 38 | Существует множество ресурсов для понимания и настройки SELinux:
SELinux включен по умолчанию в системах RHEL, и его не следует отключать без крайней необходимости. |
| 39 | OSSEC — это бесплатная хост-система обнаружения вторжений с открытым исходным кодом, которая выполняет анализ журналов, проверку целостности файлов и обнаружение руткитов с оповещением в режиме реального времени для выявления вредоносной активности. Его можно получить по адресу http://www.ossec.net/. |
| 40 | ITS Networking управляет двумя серверами уровня 2 NTPv4 (NTP версии 4) для служб синхронизации сетевого времени для сетевых администраторов университетов . |
| 41 | Auditd отслеживает различные системные действия, такие как входы в систему, аутентификации, изменения учетных записей и отказы SELinux. |
| 42 | Rsyslog — это сторонний пакет, предназначенный для замены стандартного демона системного журнала. Бенчмарк CIS содержит несколько рекомендаций по настройке rsyslog. Некоторые преимущества rsyslog включают передачу журналов по протоколу TCP и поддержку шифрования данных журнала при передаче по сети. |
| 44 | Настоятельно рекомендуется, чтобы журналы отправлялись с любых устройств категории I в такую службу, как Splunk, которая, среди прочего, обеспечивает агрегирование журналов, обработку и мониторинг событий в реальном времени. Это помогает обеспечить сохранность и неизменность журналов в случае компрометации, а также позволяет выполнять упреждающий анализ журналов нескольких устройств. Лицензии Splunk доступны через ITS бесплатно. ITS также поддерживает централизованно управляемую службу Splunk, которую можно использовать. |
| 45 |
|
| 46 | . требуется pam_warn.so Предупреждение будет сообщать об оповещениях в системный журнал. |
| 48 | Чтобы требовать надежные пароли в соответствии с разделом 5. Для RHEL 6: В /etc/pam.d/system-auth добавьте или измените файл так, как требуется: пароль требуется PAM_CRACKLIB.SO RETRY = 3 DiFOK = 5 MINLEN = 8 LCREDIT = -1 DCREDIT = -1 OCREDIT = -1 Достаточный пароль PAM_UNIX. пароль требуется pam_deny.so пароль требуется pam_warn.so Для RHEL 7: В /etc/security/pwquality, add 9.000000002 difok = 5 minlen = 8 minclass = 1 maxrepeat = 0 maxclassrepeat = 0 lcredit = -1 uкредит = 0 dкредит = -1 oкредит |
| 49 | Убедитесь, что в файле безопасности терминала (например, /etc/securetty или /etc/ttys) запрещен привилегированный (корневой) доступ. В системе Red Hat это означает, что в этом файле нет виртуальных устройств (таких как /dev/pty*). |
| 50 | Текст официального предупреждающего баннера университета можно найти на веб-сайте ITS. Вы можете добавить на баннер локализованную информацию, если включен баннер университета. |
| 51 | Текст официального предупреждающего баннера университета можно найти на веб-сайте ITS. |
Параметр noexec запрещает пользователям запускать двоичные исполняемые файлы из /tmp. Параметр nosuid запрещает пользователям создавать файлы set userid в /tmp.
/etc/xinetd.d/*.
Можно использовать и другие уровни регистрации, но они могут генерировать больше шума. Уровень ведения журнала DEBUG не рекомендуется для рабочих серверов.
selinuxproject.org/page/Main_Page 
Эти записи могут помочь администраторам идентифицировать вредоносную активность или несанкционированный доступ.
18 Политики использования и безопасности информационных ресурсов:
D/SYSTEM-AUTH, добавьте или измените файл при необходимости для чтения: