Linux iptables или firewall

firewalld vs iptables — когда использовать который [закрыт]

Хотите улучшить этот вопрос? Обновите вопрос, чтобы ответить на него фактами и цитатами, отредактировав этот пост .

Закрыто 4 года назад .

TL; DR На новых установках сервера CentOS я должен использовать firewalld или просто отключить это и вернуться к использованию /etc/sysconfig/iptables ?

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

Я много знаю о iptables, но очень мало о firewalld.

На Fedora и RHEL / CentOS — традиционная конфигурация iptables была сделана в /etc/sysconfig/iptables . С firewalld, его конфигурация живет /etc/firewalld/ и представляет собой набор файлов XML. Fedora, похоже, движется в сторону firewalld в качестве замены этой устаревшей конфигурации. Я понимаю, что firewalld использует iptables под капотом, но у него также есть свой собственный интерфейс командной строки и формат файла конфигурации, как указано выше — это то, что я имею в виду в отношении использования одного против другого.

Есть ли конкретная конфигурация / сценарий, для которого лучше всего подходит каждый из них? В случае NetworkMangaer против сети, похоже, что хотя NetworkManager и задумывался как замена сетевых сценариев, из-за отсутствия поддержки сетевого моста и некоторых других вещей, многие люди просто не используют его в настройках сервера на все. Так что, похоже, существует общая концепция «использовать NetworkManager, если вы работаете в Linux desktop/gui , и сеть, если вы работаете на сервере». Это именно то, что я извлекаю из чтения различных постов, но оно, по крайней мере, дает руководство относительно того, как можно использовать эти вещи — по крайней мере, когда они находятся в своем текущем состоянии.

Но я делал то же самое с firewalld и просто выключал его и вместо этого использовал iptables. (Я почти всегда устанавливаю Linux на сервер, а не для настольного использования). Является ли firewalld эффективной заменой iptables, и я должен просто использовать это на всех новых системах?

Источник

Двенадцать советов по повышению безопасности Linux

Мы живём в опасное время: едва ли не каждый день обнаруживаются новые уязвимости, на их основе создают эксплойты, под ударом может оказаться и обычный домашний компьютер на Linux, и сервер, от которого зависит огромная организация.

Возможно, вы уделяете внимание безопасности и периодически обновляете систему, но обычно этого недостаточно. Поэтому сегодня мы поделимся двенадцатью советами по повышению безопасности Linux-систем на примере CentOS 7.

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

Для того, чтобы повысить безопасность системы, можно защитить консольный доступ к ней, ограничив root-пользователя в использовании определённых терминалов. Сделать это можно, задав терминалы, которые может использовать суперпользователь, в файле /etc/securetty .

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

Напоминания о смене пароля

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

Мы предлагаем вам два способа организации подобных напоминаний. Первый заключается в использовании команды chage , второй — в установке необходимых значений по умолчанию в /etc/login.defs .

Вызов команды chage выглядит так:

Тут мы используем ключ -M для того, чтобы установить срок истечения актуальности пароля в днях.

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

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

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

После установки этой программы, вы можете перейти в /etc/pam.d/system-auth и ввести примерно следующее:

Уведомления sudo

Команда sudo , с одной стороны, упрощает жизнь, а с другой, может стать причиной проблем с безопасностью Linux, которые могут привести к непоправимым последствиям. Настройки sudo хранятся в файле /etc/sudoers . С помощью этого файла можно запретить обычным пользователям выполнять некоторые команды от имени суперпользователя. Кроме того, можно сделать так, чтобы команда sudo отправляла электронное письмо при её использовании, добавив в вышеупомянутый файл следующее:

Также надо установить свойство mail_always в значение on :

Защита SSH

Если мы говорим о безопасности Linux, то нам стоит вспомнить и о службе SSH. SSH — это важная системная служба, она позволяет удалённо подключаться к системе, и иногда это — единственный способ спасти ситуацию, когда что-то идёт не так, поэтому об отключении SSH мы тут не говорим.

Тут мы используем CentOS 7, поэтому конфигурационный файл SSH можно найти по адресу etc/ssh/sshd_config . Сканеры или боты, которых используют атакующие, пытаются подключиться к SSH по используемому по умолчанию порту 22.

Распространена практика изменения стандартного порта SSH на другой, неиспользуемый порт, например, на 5555 . Порт SSH можно изменить, задав нужный номер порта в конфигурационном файле. Например, так:

Кроме того, можно ограничить вход по SSH для root-пользователя, изменив значение параметра PermitRootLogin на no :

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

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

Настроив эти параметры, вы можете увеличить время соединения:

Можно указать то, каким пользователям разрешено использовать SSH:

Разрешения можно назначать и на уровне групп:

Защита SSH с использованием Google Authenticator

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

Затем запустить её для проверки установки:

Так же нужно, чтобы приложение Google Authenticator было установлено на вашем телефоне.

Отредактируйте файл /etc/pam.d/sshd , добавив в него следующее:

Теперь осталось лишь сообщить обо всём этом SSH, добавив следующую строку в файл /etc/ssh/sshd_config :

Теперь перезапустите SSH:

Когда вы попытаетесь войти в систему с использованием SSH, вам предложат ввести код верификации. Как результат, теперь SSH-доступ к вашей системе защищён гораздо лучше, чем прежде.

Мониторинг файловой системы с помощью Tripwire

Tripwire — это замечательный инструмент для повышения безопасности Linux. Это — система обнаружения вторжений (HIDS).

Задача Tripwire заключается в том, чтобы отслеживать действия с файловой системой, следить за тем, кто меняет файлы, и когда происходят эти изменения.

Для того, чтобы установить Tripwire, нужен доступ к репозиторию EPEL. Это задача несложная, решить её можно следующими командами:

После установки репозитория EPEL, вы сможете установить и Tripwire:

Теперь создайте файл ключей:

Вам предложат ввести сложный пароль для файла ключей. После этого можно настроить Tripwire, внеся изменения в файл /etc/tripwire/twpol.txt . Работать с этим файлом несложно, так как каждая строка оснащена содержательным комментарием.

Когда настройка программы завершена, следует её инициализировать:

Инициализация, в ходе которой выполняется сканирование системы, займёт некоторое время, зависящее от размеров ваших файлов.

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

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

И вот ещё одна рекомендация, касающаяся Tripwire. Защитите файлы twpol.txt и twcfg.txt . Это повысит безопасность системы.

У Tripwire есть множество параметров и установок. Посмотреть справку по ней можно так:

Использование Firewalld

Firewalld — это замена для iptables , данная программа улучшает сетевую безопасность Linux. Firewalld позволяет вносить изменения в настройки, не останавливая текущие соединения. Файрвол работает как сервис, который позволяет добавлять и менять правила без перезапуска и использует сетевые зоны.

Для того, чтобы выяснить, работает ли в настоящий момент firewalld , введите следующую команду:

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

Каждая из этих зон имеет определённый уровень доверия.

Это значение можно обновить следующим образом:

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

Просмотреть список всех поддерживаемых служб можно следующей командой:

Затем можно добавлять в зону новые службы или убирать существующие:

Можно вывести сведения обо всех открытых портах в любой зоне:

Добавлять порты в зону и удалять их из неё можно так:

Можно настраивать и перенаправление портов:

Firewalld — это весьма продвинутый инструмент. Самое примечательное в нём то, что он может нормально работать, например, при внесении изменений в настройки, без перезапусков или остановок службы. Это отличает его от средства iptables , при работе с которым службу в похожих ситуациях нужно перезапускать.

Переход с firewalld на iptables

Некоторые предпочитают файрвол iptables файрволу firewalld . Если вы пользуетесь firewalld , но хотите вернуться к iptables , сделать это довольно просто.

Сначала отключите firewalld :

Затем установите iptables :

Теперь можно запустить службу iptables :

После всего этого перезагрузите компьютер.

Ограничение компиляторов

Атакующий может скомпилировать эксплойт на своём компьютере и выгрузить его на интересующий его сервер. Естественно, при таком подходе наличие компиляторов на сервере роли не играет. Однако, лучше ограничить компиляторы, если вы не используете их для работы, как происходит в большинстве современных систем управления серверами.

Для начала выведите список всех бинарных файлов компиляторов из пакетов, а затем установите для них разрешения:

Создайте новую группу:

Затем измените группу бинарных файлов компилятора:

И ещё одна важная вещь. Нужно изменить разрешения этих бинарных файлов:

Теперь любой пользователь, который попытается использовать gcc , получит сообщение об ошибке.

Предотвращение модификации файлов

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

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

Для того, чтобы сделать любой файл иммутабельным, воспользуйтесь командой chattr :

Атрибут иммутабельности можно удалить такой командой:

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

Управление SELinux с помощью aureport

Нередко система принудительного контроля доступа SELinux оказывается, по умолчанию, отключённой. Это не влияет на работоспособность системы, да и работать с SELinux довольно сложно. Однако, ради повышения безопасности, SELinux можно включить, а упростить управление этим механизмом можно, используя aureport .

Утилита aureport позволяет создавать отчёты на основе лог-файлов аудита.

Список исполняемых файлов можно вывести следующей командой:

Можно использовать aureport для создания полного отчёта об аутентификации:

Также можно вывести сведения о неудачных попытках аутентификации:

Или, возможно, сводку по удачным попыткам аутентификации:

Утилита aureport значительно упрощает работу с SELinux.

Использование sealert

В дополнение к aureport вы можете использовать хороший инструмент безопасности Linux, который называется sealert . Установить его можно так:

Теперь у нас есть средство, которое будет выдавать оповещения из файла /var/log/audit/audit.log и даст нам дополнительные сведения о проблемах, выявленных SELinux.

Использовать его можно так:

Самое интересное тут то, что в оповещениях можно найти советы о том, как решать соответствующие проблемы.

Итоги

Надеемся, приведённые здесь советы помогут вам сделать вашу установку Linux безопаснее. Однако, если речь идёт о защите информации, нельзя, применив те или иные меры, считать, что теперь вам ничто не угрожает. К любым программным средствам защиты всегда стоит добавлять бдительность и осторожность.

Уважаемые читатели! Знаете ли вы какие-нибудь простые, но неочевидные способы повышения безопасности Linux?

Источник

Настройка Linux-файрвола с помощью iptables в CentOS / RHEL 7

В этой статье мы покажем, как управлять файерволом Linux с помощью классическгого iptables вместо firewalld в CentOS / RHEL 7 для фильтрации входящего и исходящего трафика. В этой статье рассмотрена настройка iptables на CentOS 7 для фильтрации входящего трафика, на примере развернутого с нуля облачного виртуального сервера myserver01, доступного из Интернета.

Отключение firewalld в CentOS 7

В CentOS 7 для управления файрволом по умолчанию используется системная служба firewalld. Она предоставляет свой интерфейс, но в итоге также работает через утилиту iptables. При этом управление файроволом должно осуществляться либо через firewalld, либо напрямую через iptables.

firewalld не замена, а обертка вокруг iptables, пользоваться из этого можно тем, что больше нравится, или больше подходит в конкретных условиях. iptables более универсален, это базовый инструмент, но он немного сложнее в освоении. firewalld предоставляет более простой интерфейс, но, например, в CentOS 6 воспользоваться им не получится, да и для других дистрибутивов необходимо наличие нужных установочных пакетов. К тому же, если вы используете приложения, которые производят свои настройки в файрволе, они должны быть совместимы с firewalld (пример таких приложений docker, fail2ban).

Проверим статус firewalld и отключим его.

systemctl status firewalld

В выводе команды обведенная красным область со словом enabled, означает включенную автозагрузку, а область, обведенная желтым, со словом active, означает, что служба запущена.

Останавливаем службу и выключаем для нее автозагрузку:

systemctl stop firewalld
systemctl disable firewalld

Повторно проверяем статус:

Теперь вывод команды показывает disabled для автозагруки (выключена), и inactive означает, что служба выключена.

Синтаксис и правила iptables в CentOS/Red Hat

Iptables – это утилита, с помощью которой настраиваются правила для файрвола в Linux.

Iptables группирует правила файрвола в таблицах, основные это:

• Таблица filter – используется для фильтрации трафика, то есть разрешения и запрещения соединений
• Таблица nat – используется для преобразования адресов (NAT)
• Таблица mangle – прочие модификации заголовков ip пакетов.

Для начала проверим, что iptables установлен в системе(должен быть умолчанию):

Вывод команды показывает, что текущая установленная версия iptables – 1.4.21.

Работа с iptables в командной строке требует root привилегий, поэтому далее будем работать под пользователем root.

Чтобы вывести текущие правила, выполним команду:

iptables [-t таблица] -L [цепочка] [параметры]

Например, результат команды iptables -L, когда в таблицах еще не создано правил:

Рассмотрим вывод команды подробнее.

Таблица filter содержит три типа правил, так называемые chain(цепочки):

• INPUT – в этой цепочке обрабатываются входящие ip пакеты, предназначенные для самого хоста;
• OUTPUT – в этой цепочке обрабатываются исходящие ip пакеты от самого хоста;
• FORWARD – эта цепочка нужна для перенаправления ip пакетов. Используется, если вы хотите использовать сервер, как маршрутизатор.

Напротив каждой цепочки указана политика по умолчанию (policy), которая определяет, что нужно делать, в случае, если соединение не попало ни в одно из правил. Политика по умолчанию может принимать два значения и определяет сам подход к организации файрвола:

• ACCEPT – по умолчанию все соединения разрешены, правилами блокируются нежелательные соединения;
• DROP – по умолчанию все соединения запрещены, правилами разрешаются нужные соединения.

Создание правил фильтрации трафика в iptables

Фильтр iptables по интерфейсу

Начнем создавать правила. Синтаксис команды для добавления нового правила в конец указанной цепочки выглядит так:

iptables [-t таблица] -A -j

Для начала, разрешим трафик через локальный loopback интерфейс(127.0.0.1), что необходимо для работы некоторых приложений:

iptables -A INPUT -i lo -j ACCEPT

Разберем по порядку:

1. Мы указываем цепочку INPUT, т.е. правило будет применяться для входящих соединений.
2. Далее, используем ключ -i(—in-interface), чтобы определить входящий интерфейс, на который приходит ip пакет.
3. Завершаем команду ключом -j(—jump), определяющим действие, которое будет выполнено для всех ip пакетов, соответствующих критерию из пункта 2. В данном случае ACCEPT – разрешить соединение. Кроме того, к основным действиям с соединениями также относятся:
   • DROP – запретить соединение, источник соединения не информируется, ip пакет просто отбрасывается;
   • REJECT – запретить соединение, источник соединения информируется сообщением.

Фильтр iptables по порту, протоколу или IP адресу

Теперь добавим разрешающее правило для подключения к нашему Linux серверу по SSH на порт 22.

iptables -A INPUT -p tcp —dport 22 -j ACCEPT

В этом правиле критериями являются порт и протокол. Протокол (tcp, udp, icmp, all) задается ключом -p(—protocol), порт назначения (т.е. порт на который будут приходить ip пакеты к серверу) —dport.

Допустимо указывать диапазон портов через двоеточие, например

Если нам известны ip адреса клиентов, с которых мы будет подключаться к серверу, более безопасным будет разрешить доступ только с этих ip адресов. В этом случае, в критерии нужно добавить ключ –s(—src, —source), задающий ip адрес или подсеть источника соединения, например, таким правилом:

iptables -A INPUT -p tcp -s 94.41.174.122 —dport 22 -j ACCEPT

доступ на 22 порт будет разрешен только с ip адреса 94.41.174.122.

Частично разрешим icmp запросы, 3-х типов:

iptables -A INPUT -p icmp —icmp-type echo-request -j ACCEPT
iptables -A INPUT -p icmp —icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT -p icmp —icmp-type time-exceeded -j ACCEPT

Эти правила разрешают работу утилит ping, traceroute и позволяют работать механизму для определения MTU между двумя хостами.

Фильтр iptables по состоянию соединения

Для корректной работы потребуется создать правило, разрешающее уже установленные соединения:

iptables -A INPUT -m state —state ESTABLISHED,RELATED -j ACCEPT

Здесь в критерии используется ключ -m, для загрузки модуля state, который дает возможность определить текущее состояние ip пакета из возможных:

• NEW – относится к входящим ip пакетам, участвующим в установке соединения;
• ESTABLISHED и RELATED – относится к входящим ip пакетам, участвующим в уже установленных соединениях, или соединениях, инициированных из уже установленных(связанные соединения);
• INVALID — относится к входящим ip пакетам, если к ним не применимо ни одно из указанных выше состояний.

Задание политики iptables по умолчанию

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

iptables -P INPUT DROP

Включить логи iptables

Iptables позволяет записывать информацию о проходящих ip пакетах в системный журнал. Реализуется это с помощью специфичного действия LOG над соединением, после которого, ip пакет продолжает движение по цепочке нетронутым. Для примера, создадим правило, которое будет записывать в системный журнал все события соединений на порт 445 (tcp):

iptables -A INPUT -p tcp —dport 445 -j LOG —log-prefix «IN SMB DROP: «

здесь —log-prefix задает префикс для всех сообщений, логируемых нашим правилом. Это удобно, если у вас несколько разных правил логирования, или для дальнейшей программной обработки. Если теперь попробовать подключиться снаружи к нашему серверу на порт 445, например через telnet, в файле /var/log/messages появятся записи:

Разберем вывод:

• IN SMB DROP : префикс, который мы задали опцией —log-prefix
• IN=eth0 интерфейс, на который принят ip пакет, для исходящих соединений содержит пустое значение
• OUT= интерфейс, с которого отправлен ip пакет, для входящих соединений, содержит пустое значение
• MAC= соединенные вместе в следующем порядке: MAC-адрес назначения, MAC-адрес источника, EtherType — 08:00 соответствует IPv4.
• SRC= ip адрес источника, от которого отправлен ip пакет
• DST= ip адрес назначения, на который отправлен ip пакет
• LEN= размер ip пакета в байтах
• SPT= порт источника, от которого отправлен ip пакет
• DPT= порт назначения, на который отправлен ip пакет

Сохранение и восстановление правил фильтрации iptables

В заключении, настроим автозагрузку правил, после перезагрузки сервера. Для этого должен быть установлен пакет iptables-services и активирован сервис. Установим пакет через yum:

yum install iptables-services
systemctl enable iptables

Проверим статус службы iptables:

systemctl status iptables

Параметр автозагрузки установлен в enabled (включена), параметр active указывает, что служба запущена.

При загрузке сервис будет читать содержимое файла /etc/sysconfig/iptables, и восстанавливать сохраненные правила. Чтобы сохранить в него наши правила, воспользуемся командой:

Можно восстановить правила из файла командой:

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

В следующей статье мы покажем, как использовать iptables для создания NAT правил перенаправления трафика для шлюза-доступа на базе CentOS из / во внутренюю сеть организации.

Источник