Настройка netfilter/iptables для подключения нескольких клиентов к одному соединению.
Давайте теперь рассмотрим наш Linux в качестве шлюза для локальной сети во внешнюю сеть Internet. Предположим, что интерфейс eth0 подключен к интернету и имеет IP 198.166.0.200, а интерфейс eth1 подключен к локальной сети и имеет IP 10.0.0.1. По умолчанию, в ядре Linux пересылка пакетов через цепочку FORWARD (пакетов, не предназначенных локальной системе) отключена. Чтобы включить данную функцию, необходимо задать значение 1 в файле /proc/sys/net/ipv4/ip_forward:
netfilter:~# echo 1 > /proc/sys/net/ipv4/ip_forward
Чтобы форвардинг пакетов сохранился после перезагрузки, необходимо в файле /etc/sysctl.conf раскомментировать (или просто добавить) строку net.ipv4.ip_forward=1.
Итак, у нас есть внешний адрес (198.166.0.200), в локальной сети имеется некоторое количество гипотетических клиентов, которые имеют адреса из диапазона локальной сети и посылают запросы во внешнюю сеть. Если эти клиенты будут отправлять во внешнюю сеть запросы через шлюз «как есть», без преобразования, то удаленный сервер не сможет на них ответить, т.к. обратным адресом будет получатель из «локальной сети». Для того, чтобы эта схема корректно работала, необходимо подменять адрес отправителя, на внешний адрес шлюза Linux. Это достигается за счет (маскарадинг) в , в .
netfilter:~# iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT netfilter:~# iptables -A FORWARD -m conntrack --ctstate NEW -i eth1 -s 10.0.0.1/24 -j ACCEPT netfilter:~# iptables -P FORWARD DROP netfilter:~# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Итак, по порядку сверху-вниз мы разрешаем уже установленные соединения в цепочке FORWARD, таблице filter, далее мы разрешаем устанавливать новые соединения в цепочке FORWARD, таблице filter, которые пришли с интерфейса eth1 и из сети 10.0.0.1/24. Все остальные пакеты, которые проходят через цепочку FORWARD — отбрасывать. Далее, выполняем маскирование (подмену адреса отправителя пакета в заголовках) всех пакетов, исходящих с интерфейса eth0.
Примечание. Есть некая общая рекомендация: использовать правило -j MASQUERADE для интерфейсов с динамически получаемым IP (например, по DHCP от провайдера). При статическом IP, -j MASQUERADE можно заменить на аналогичное -j SNAT —to-source IP_интерфейса_eth0. Кроме того, SNAT умеет «помнить» об установленных соединениях при кратковременной недоступности интерфейса. Сравнение MASQUERADE и SNAT в таблице:
Кроме указанных правил так же можно нужно добавить правила для фильтрации пакетов, предназначенных локальному хосту — как описано в . То есть добавить запрещающие и разрешающие правила для входящих и исходящих соединений:
netfilter:~# iptables -P INPUT DROP netfilter:~# iptables -P OUTPUT DROP netfilter:~# iptables -A INPUT -i lo -j ACCEPT netfilter:~# iptables -A OUTPUT -o lo -j ACCEPT netfilter:~# iptables -A INPUT -p icmp --icmp-type 0 -j ACCEPT netfilter:~# iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT netfilter:~# iptables -A OUTPUT -p icmp -j ACCEPT netfilter:~# cat /proc/sys/net/ipv4/ip_local_port_range 32768 61000 netfilter:~# iptables -A OUTPUT -p TCP --sport 32768:61000 -j ACCEPT netfilter:~# iptables -A OUTPUT -p UDP --sport 32768:61000 -j ACCEPT netfilter:~# iptables -A INPUT -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT netfilter:~# iptables -A INPUT -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT
В результате, если один из хостов локальной сети, например 10.0.0.2, попытается связаться с одним из интернет-хостов, например, 93.158.134.3 (ya.ru), при , их исходный адрес будет подменяться на внешний адрес шлюза в цепочке POSTROUTING таблице nat, то есть исходящий IP 10.0.0.2 будет заменен на 198.166.0.200. С точки зрения удаленного хоста (ya.ru), это будет выглядеть, как будто с ним связывается непосредственно сам шлюз. Когда же удаленный хост начнет ответную передачу данных, он будет адресовать их именно шлюзу, то есть 198.166.0.200. Однако, на шлюзе адрес назначения этих пакетов будет подменяться на 10.0.0.2, после чего пакеты будут передаваться настоящему получателю в локальной сети. Для такого обратного преобразования никаких дополнительных правил указывать не нужно — это будет делать все та же операция MASQUERADE, которая помнит какой хост из локальной сети отправил запрос и какому хосту необходимо вернуть пришедший ответ.
Примечание: желательно негласно принято, перед всеми командами iptables очищать цепочки, в которые будут добавляться правила:
netfilter:~# iptables -F ИМЯ_ЦЕПОЧКИ
Анализ сетевой активности на шлюзе в linux
В данной конфигурации шлюз может успешно функционировать. Но иногда хочется посмотреть, а что вообще на нем происходит. Например, кто-то занимает весь канал, интернет тормозит, а мы как слепые котята сидим и не видим ничего. Нужно какое-то средство для просмотра загрузки сети на шлюзе. И такое средство есть — программа iftop.
Она отсутствует в стандартном репозитории CentOS 7. Для ее установки необходимо подключить репозиторий epel:
# yum -y install epel-release
Устанавливаем iftop на CentOS 7:
# yum -y install iftop
Теперь мы можем смотреть загрузку сети на шлюзе в режиме реального времени. Чтобы увидеть сетевую активность, достаточно запустить iftop:
# iftop
По-умолчанию она слушает интерфейс eth0. Это внешний интерфейс шлюза, на нем все подключения будут отображены от имени самого шлюза и определить, кто же в сети занимает канал мы не сможем. Чтобы это увидеть, необходимо запустить просмотр сетевой активности на локальном интерфейсе. Сделать это не сложно, достаточно запустить iftop с параметром:
# iftop -i eth1 -P
Теперь уже гораздо интереснее. Я еще добавил параметр -P, который отображает порты, по которым проходят соединения. Посмотрим, кто больше всех загружает канал интернета:
В моем случае это пользователь с ip 192.168.10.98, на котором я запустил проверку скорости интернета с серверов Яндекса.
Если у вас не большая сеть и не много пользователей, то с помощью этой простой и эффективной утилиты вы сможете легко определить, кто, к примеру, качает торренты или чем-то еще загружает канал.
Сетевые настройки на сервере CentOS 7
Первый раз с сетевыми настройками сервера CentOS мы сталкиваемся, когда производим установку. На экране первоначальной настройки есть отдельный пункт, касающийся настройки сетевых интерфейсов:
Зайдя в него мы видим список подключенных сетевых карт. Каждую из них можно включить соответствующим ползунком (пункт 1 на картинке). При активировании интерфейса он автоматически получает настройки по dhcp. Результат работы dhcp можно посмотреть тут же. Если вас не устраивают эти настройки, их можно отредактировать, нажав configure
(пункт 3 на картинке). Здесь же можно задать hostname
(пункт 2 на картинке):
Открыв окно дополнительный настроек Ehernet, вы сможете изменить имя сетевого интерфейса, указать настройки IP (пункт 1 на картинке), выбрать ручные настройки
(пункт 2 на картинке), назначить ip адрес
(пункт 3 на картинке), установить dns сервер
(пункт 4 на картинке) и сохранить сетевые настройки (пункт 5 на картинке):
После выполнения остальных настроек начнется установка. После установки у вас будет сервер с указанными вами сетевыми настройками.
Теперь рассмотрим другую ситуацию. Сервер, а соответственно и конфигурацию сети, производили не вы, а теперь вам надо ее посмотреть либо изменить. В вашем распоряжении консоль сервера, в ней и будем работать. Если у вас установка производилась с дистрибутива minimal
, то при попытке посмотреть сетевые настройки с помощью команды ifconfig
в консоли вы увидите следующее:
Bash: ifconfig: command not found
или в русской версии:
Bash: ifconfig команда не найдена
Для работы с ifconfig и прочими сетевыми утилитами необходимо установить пакет net-tools
. Сделаем это:
# yum -y install net-tools.x86_64
Теперь можно увидеть настройки сети:
# ifconfig
eno16777728: flags=4163 mtu 1500
inet 192.168.159.129
RX packets 319 bytes 36709 (35.8 KiB)
TX packets 256 bytes 148817 (145.3 KiB)
lo: flags=73 mtu 65536
inet6::1 prefixlen 128 scopeid 0x10
RX packets 6 bytes 624 (624.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 6 bytes 624 (624.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Если у вас нет желания устанавливать дополнительный пакет, то можно воспользоваться более простой командой ip
с параметрами:
# ip addr
1: lo: mtu 65536 qdisc noqueue state UNKNOWN
inet 127.0.0.1/8 scope host lo
inet6::1/128 scope host
valid_lft forever preferred_lft forever
2: eno16777728: mtu 1500 qdisc pfifo_fast state UP qlen 1000
inet 192.168.159.129
/24 brd 192.168.159.255 scope global dynamic eno16777728
valid_lft 1709sec preferred_lft 1709sec
inet6 fe80::20c:29ff:fe7d:593f/64 scope link
valid_lft forever preferred_lft forever
По настройкам из этого файла мы получаем ip адрес по dhcp. Чтобы вручную прописать статический ip, приводим файл к следующему содержанию:
Мы изменили параметры:
BOOTPROTOс dhcp на noneDNS1 указали dns сервер IPADDR, настроили статический ip адрес PREFIX, указали маску подсети GATEWAY. настроили шлюз по-умолчанию
Чтобы изменения вступили в силу, необходимо перечитать сетевые настройки:
Restarting network (via systemctl):
Проверяем, применилась ли новая конфигурация сети:
# ifconfig:
eno16777728: flags=4163 mtu 1500
inet 192.168.159.129
netmask 255.255.255.0 broadcast 192.168.159.255
inet6 fe80::20c:29ff:fe7d:593f prefixlen 64 scopeid 0x20
ether 00:0c:29:7d:59:3f txqueuelen 1000 (Ethernet)
RX packets 672 bytes 71841 (70.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 572 bytes 290861 (284.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Все в порядке, новые настройки сетевого интерфейса установлены.
Как получить сетевые настройки по DHCP
Теперь рассмотрим обратную ситуацию. Допустим, у вас сетевая карта имеет какие-то настройки, установленные вручную. Но вы хотите, чтобы ваш компьютер получал настройки сети по dhcp в качестве клиента. Для этого вам нужно произвести операцию, обратную той, что мы делали раньше. То есть открываем файл /etc/sysconfig/network-scripts/ifcfg-eth0 и удаляем там строки с параметрами DNS, IPADDR, PREFIX, GATEWAY а в параметре BOOTPROTO указываем значение «dhcp»
. Сохраняем файл и перезапускаем сеть:
# /etc/init.d/network restart
Затем проверяем, получил ли наш client по dhcp настройки.
Создание правил фильтрации трафика в iptables
Фильтр iptables по интерфейсу
Начнем создавать правила. Синтаксис команды для добавления нового правила в конец указанной цепочки выглядит так:
Для начала, разрешим трафик через локальный loopback интерфейс(127.0.0.1), что необходимо для работы некоторых приложений:
Разберем по порядку:
- Мы указываем цепочку INPUT, т.е. правило будет применяться для входящих соединений.
- Далее, используем ключ -i(—in-interface), чтобы определить входящий интерфейс, на который приходит ip пакет.
- Завершаем команду ключом -j(—jump), определяющим действие, которое будет выполнено для всех ip пакетов, соответствующих критерию из пункта 2. В данном случае ACCEPT – разрешить соединение. Кроме того, к основным действиям с соединениями также относятся:
- DROP – запретить соединение, источник соединения не информируется, ip пакет просто отбрасывается;
- REJECT – запретить соединение, источник соединения информируется сообщением.
Фильтр iptables по порту, протоколу или IP адресу
Теперь добавим разрешающее правило для подключения к нашему Linux серверу по SSH на порт 22.
В этом правиле критериями являются порт и протокол. Протокол (tcp, udp, icmp, all) задается ключом -p(—protocol), порт назначения (т.е. порт на который будут приходить ip пакеты к серверу) —dport.
Примечание: если вы хотите использовать в критериях порт назначения или порт источник(—dport или —sport), то указывать протокол обязательно.
Допустимо указывать диапазон портов через двоеточие, например
Если нам известны ip адреса клиентов, с которых мы будет подключаться к серверу, более безопасным будет разрешить доступ только с этих ip адресов. В этом случае, в критерии нужно добавить ключ –s(—src, —source), задающий ip адрес или подсеть источника соединения, например, таким правилом:
доступ на 22 порт будет разрешен только с ip адреса 94.41.174.122.
Частично разрешим icmp запросы, 3-х типов:
Эти правила разрешают работу утилит ping, traceroute и позволяют работать механизму для определения MTU между двумя хостами.
Фильтр iptables по состоянию соединения
Для корректной работы потребуется создать правило, разрешающее уже установленные соединения:
Здесь в критерии используется ключ -m, для загрузки модуля state, который дает возможность определить текущее состояние ip пакета из возможных:
- NEW – относится к входящим ip пакетам, участвующим в установке соединения;
- ESTABLISHED и RELATED – относится к входящим ip пакетам, участвующим в уже установленных соединениях, или соединениях, инициированных из уже установленных(связанные соединения);
- INVALID — относится к входящим ip пакетам, если к ним не применимо ни одно из указанных выше состояний.
Задание политики iptables по умолчанию
Минимальный набор разрешающих правил для файрвола готов, осталось установить политику по умолчанию, запрещающую все входящие соединения, не соответствующие нашим правилам. Для этого в команде iptables служит ключ -P, устанавливает политику по умолчанию для заданной цепочки, в нашем случае:
Внимание: прежде чем использовать эту команду, необходимо убедиться, что ваши текущие правила разрешают вам подключиться к серверу, иначе вы просто заблокируете себе доступ!Посмотрим на результатурующую таблицу правил iptables, добавим ключ -v, чтобы показать более подробный вывод:
Включение логов
Во время настройки полезно включить логи, чтобы мониторить заблокированные пакеты и выяснять, почему отсутствует доступ к необходимым сервисам, которые мы вроде бы уже открыли. Я отправляю все заблокированные пакеты в отдельные цепочки (block_in, block_out, block_fw), соответствующие направлению трафика и маркирую в логах каждое направление. Так удобнее делать разбор полетов. Добавляем следующие правила в самый конец скрипта, перед сохранением настроек:
Все заблокированные пакеты вы сможете отследить в файле /var/log/messages.
После того, как закончите настройку, закомментируйте эти строки, отключив логирование. Обязательно стоит это сделать, так как логи очень быстро разрастаются. Практического смысла в хранении подобной информации лично я не вижу.
Отключить SELinux
Отключаем SELinux. Его использование и настройка отдельный разговор. Сейчас я не буду этим заниматься. Так что отключаем:
меняем значение
Чтобы изменения вступили в силу, можно перезагрузиться:
А если хотите без перезагрузки применить отключение SELinux, то выполните команду:
Постоянно получаю очень много критики на тему отключения SELinux. Я знаю, как он работает, умею его настраивать. Это реально не очень сложно и освоить не трудно. Это мой осознанный выбор, хотя иногда я его настраиваю. Мой формат работы с системой таков, что SELinux мне чаще всего не нужен, поэтому я не трачу на него время и в базовой настройке centos отключаю. Безопасность системы — комплексная работа, особенно в современном мире web разработки, где правят бал микросервисы и контейнеры. SELinux нишевый инструмент, которые нужен не всегда и не везде. Поэтому в данном статье ему не место. Кому нужно, будет отдельно включать SELinux и настраивать.
Открытие портов
Теперь немного расширим нашу конфигурацию и откроем в iptables порты для некоторых сервисов. Допустим, у нас работает веб-сервер и необходимо открыть к нему доступ из интернета. Добавляем правила для веб-трафика:
Было добавлено разрешение на входящие соединения по 80-му и 443-му портам, которые использует web сервер в своей работе.
Если у вас установлен почтовый сервер, то нужно разрешить на него входящие соединения по всем используемым портам:
Для корректной работы DNS сервера, нужно открыть UDP порт 53
И так далее. По аналогии можете открыть доступ для всех необходимых сервисов.
Автоматическое обновление системы
Для поддержания безопасности сервера на должном уровне необходимо как минимум своевременно его обновлять — как само ядро с системными утилитами, так и остальные пакеты. Можно делать это вручную, но для более эффективной работы лучше настроить автоматическое выполнение. Не обязательно именно устанавливать обновления автоматически, но как минимум проверять их появление. Я обычно придерживаюсь такой стратегии.
Yum-cron
Для автоматической проверки обновлений в Centos 7 нам поможет утилита yum-cron. Ставится она традиционно через yum из стандартного репозитория.
После установки yum-cron создается автоматическое задание на выполнение утилиты в /etc/cron.daily и /etc/cron.hourly. По-умолчанию, утилита скачивает найденные обновления, но не применяет их. Вместо этого, администратору на локальный почтовый ящик root отправляется уведомление об обновлениях. Дальше вы уже в ручном режиме заходите и решаете, устанавливать обновления или нет в удобное для вас время. Мне такой режим работы видится наиболее удобным, поэтому я не меняю эти настройки.
Dnf-automatic
Как я уже говорил ранее, в Centos 8 используется другой пакетный менеджер — dnf. Настройка обновления пакетов там выполняется через утилиту dnf-automatic. Поставим ее и настроим.
Управлением запуском по расписанию занимается уже не cron, а systemd своим встроенным планировщиком. Посмотреть таймеры автоматического запуска можно командой:
Если там нет ни одного задания, то добавить таймер можно вручную:
Дефолтный таймер настроен на запуск dnf-automatic через час после загрузки сервера и ежедневное повторение. Конфиг таймера живет тут — /etc/systemd/system/multi-user.target.wants/dnf-automatic.timer.
Конфиг для dnf-automatic живет в /etc/dnf/automatic.conf. По-умолчанию он только скачивает обновления, но не применят их. Конфиг хорошо прокомментирован, так что можете его настроить так, как пожелаете. Отдельных пояснений не требуется. Настраивайте обновление пакетов системы на свое усмотрение. Как я уже сказал, автоматически только качаю их. Установку всегда держу под контролем с ручным управлением.
3: Настройка Nginx для поддержки SSL
Итак, на данном этапе ключ и сертификат готовы. Теперь нужно отредактировать настройки Nginx.
В системе CentOS настройки Nginx по умолчанию плохо структурированы. Блок настроек HTTP находится в главном конфигурационном файле, а дополнительные настройки веб-сервер Nginx будет искать в каталоге /etc/nginx/conf.d, в файлах с расширением .conf.
Создайте в этом каталоге новый файл виртуального хоста (блока server) для обслуживания сертификата. Также можно настроить виртуальный хост по умолчанию для переадресации HTTP-запросов на HTTPS.
Виртуальный хост для TLS/SSL
Создайте и откройте файл ssl.conf в каталоге /etc/nginx/conf.d.
Добавьте в файл блок server. По умолчанию соединения TLS/SSL используют порт 443. Укажите этот номер в директиве listen. В server_name укажите доменное имя или IP-адрес сервера (значение директивы должно совпадать с тем, что вы указали ранее в Common Name). Затем добавьте строки ssl_certificate, ssl_certificate_key и ssl_dhparam и укажите в них пути к соответствующим файлам SSL.
Далее нужно определить дополнительные параметры SSL, которые обеспечивают безопасность сайта. Для этого обратимся к рекомендациям Remy van Elst на сайте Cipherli.st. Этот сайт предназначен для распространения простых и надёжных параметров шифрования для популярного программного обеспечения. Больше параметров для Nginx можно найти здесь.
Некоторые параметры можно откорректировать. Также нужно добавить DNS распознаватель для восходящего канала запросов (в руководстве для этого используется Google).
Также нужно ознакомиться с HTTP Strict Transport Security (HSTS)
Особое внимание уделите функции«preload». Это обеспечит повышенную безопасность, но может иметь далеко идущие последствия при случайном или неправильном включении/выключении
В данном руководстве мы не будем подгружать эти параметры.
Примечание: Поскольку сертификат является самоподписанным, SSL stapling не будет использоваться. Nginx выдаст предупреждение, отключит stapling для данного сертификата и продолжит работу.
Теперь добавьте остальные настройки Nginx. Список дополнительных настроек зависит от потребностей сайта. Просто скопируйте из блока location по умолчанию директивы, которые настраивают document root и включают поддержку страниц ошибок.
Сохраните и закройте файл. Теперь Nginx будет использовать SSL-сертификат для шифрования трафика. В настройках указаны только самые безопасные протоколы и шифры.
Примечание: Приведённый выше пример конфигурации будет обслуживать страницу Nginx по умолчанию.
Настройка редиректа с HTTP на HTTPS (опционально)
На данный момент Nginx поддерживает шифрованные (порт 443) и нешифрованные соединения (порт 80). То есть, сайт поддерживает шифрование, но использует его не во всех случаях. Однако из соображений безопасности рекомендуется использовать шифрование на постоянной основе
Особенно это важно при передаче конфиденциальных данных
К счастью, Nginx позволяет добавить в server-блок порта 80 по умолчанию специальные директивы редиректа. Для этого нужно просто добавить файл в каталог /etc/nginx/default.d.
Создайте новый файл ssl-redirect.conf и откройте его.
Добавьте в него строку:
Сохраните и закройте файл. Теперь все запросы, направленные на порт 80, будут переадресованы на порт 443, который поддерживает шифрование.
Настройка IPtables для web сервера на Unix/Linux
Изначально проверим настройки IPtables, следующей командой:
# iptables -vnL
Вот вывод данной программы (иптейблс):
так выглядит стандартный IPtables на CentOS
Если это чистый сервер и нужно его настроить с самого начала, то выполняем ряд действий. Для начала, выставляем цепочку INPUT на прием всех соединений ( разрешить все соединения):
# iptables --policy INPUT ACCEPT
Затираем все правила:
# iptables --flush
Давайте сделаем так, чтобы можно было получать уже открытые конекшены:
# iptables -A INPUT --match state --state ESTABLISHED,RELATED -j ACCEPT
Мы же не звери, и по этому, — даем возможность принимать соединения с 127.0.0.1 (локолхоста):
# iptables --append INPUT -i lo -j ACCEPT
Еси есть смысл ( логично разрешить), то разрешим ping на сервер ( для ICMP пакетов):
# iptables -A INPUT --protocol icmp --icmp-type any -j ACCEPT
Т.к на сервер нужно заходить, то пробрасываем 22-й порт ( порт для SSH):
# iptables -A INPUT -p tcp --dport 22 -j ACCEPT
Если имеются FTP на сервере, то пробросим:
# iptables -A INPUT -p tcp --dport 20 -j ACCEPT
И:
# iptables -A INPUT -p tcp --dport 21 -j ACCEPT
Т.к некоторые ФТП использую порты 30000-50000, то пробросим мы и их:
# iptables -A INPUT -p tcp --match tcp --dport 30000:50000 -j ACCEPT
После чего мы разрешим пользоваться http и https, которые используют 80 (8080) и 443-е порты:
Разрешаем доступ по 80-му порту.
# iptables -A INPUT -p tcp --dport 80 -j ACCEPT
Разрешаем доступ по 8080-му порту.
# iptables -I INPUT 1 -i eth0 -p tcp -m tcp --dport 8080 -m state --state NEW,ESTABLISHED -j ACCEPT
Разрешаем доступ по 443-му порту:
# iptables -A INPUT -p tcp --dport 443 -j ACCEPT
Или, если нужно пробросить все это дело для определенного интерфейса:
# iptables -I INPUT 1 -i eth0 -p tcp -m tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT # iptables -I INPUT 1 -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
Проверим что у нас вышло, работает ли у нас, а проверяем вот так:
# iptables -vnL
Настроенный iptables под веб сервер (открыты, 80, 8080 и 443 порты)
И напоследок, запретим все остальное:
# iptables --policy INPUT DROP
Сохраняем и перезапускаем IPtables, следующим образом:
# iptables-save > /root/IPTables.rules
ИЛИ:
# service iptables save
ВСЕ! На этом я завершаю свою тему «Настройка IPtables для web сервера на RedHat/CentOS/Fedora», так же Вы можете ознакомится еще и с таким полезным материалом:
Я в этой статье очень хорошо расписал что и как можно настроить, привел реальные примеры использования. По этому, если нужно и хотите реально обезопасить себя. прочитайте все что я Вам даю.
Спасибо за посещение https://linux-notes.org
Блокировка наиболее распространенных атак
Обычно хостинг-провайдеры предоставляют ненастроенные серверы – весь трафик разрешен. Но на всякий случай можно сбросить все правила фаервола:
Затем можно добавить несколько простых правил, которые отражают наиболее распространенные атаки и защищают сервер от скрипт-кидди. Конечно, IPTables вряд ли сможет защитить сервер от серьезной DDOS или подобных атак; но, по крайней мере, этот фаервол устранит сканирующих сеть ботов, которые рано или поздно начнут искать бреши в системе безопасности данного сервера. Для начала нужно заблокировать нулевые пакеты:
Теперь фаервол не будет принимать входящих пакетов с tcp-флагами. Нулевые пакеты, по сути, разведывательные. они используются, чтобы выяснить настройки сервера и определить его слабые места. Следующее правило отражает атаки syn-flood:
Во время атаки syn-flood злоумышленник создает новое соединение, но не устанавливает никаких флагов (SYN, ACK и т.д.). Все, что ему нужно – отнять ресурсы сервера. Такие пакеты принимать не стоит. Далее нужно защитить сервер от разведывательных пакетов XMAS:
Теперь сервер защищен от некоторых общих атак, которые ищут его уязвимости.
