Перейти к содержимому 
Брандмауэр iptables и UFW контролируют, какие соединения веб-сервер принимает, а какие блокирует - это определяет поверхность атаки и неудачи. В этой практической статье я покажу четкие правила, безопасные настройки по умолчанию и проверенные команды для SSH, HTTP(S), баз данных, протоколирования, IPv6 и Docker - непосредственно применимые на продуктивных хостах.
Центральные пункты
Следующие ключевые моменты помогут мне быстро сориентироваться, прежде чем я приступлю к настройке.
- Ограничительный Начало: Запрет по умолчанию для входящих, открыто специально
- SSH Разрешить первым: не рисковать доступом
- UFW как интерфейс: простой синтаксис, iptables в фоновом режиме
- Ведение журнала активировать: Проверьте правила, распознайте атаки
- Настойчивость обеспечить: Поддерживать правила перезапуска
Основы: iptables и UFW с первого взгляда
Я полагаюсь на iptablesкогда мне нужен тонкий контроль над пакетами, цепочками и соответствиями. Я использую UFW, когда мне нужно быстро применить надежные правила, которые в итоге оказываются внутренними правилами iptables [1]. Это позволяет мне сочетать простые команды с мощью Linux netfilter, не теряясь в деталях. Для веб-серверов это означает: я создаю прозрачный фильтр перед Apache, Nginx или Node, чтобы к ним поступал только нужный трафик [2]. Такое разделение уменьшает площадь атаки и позволяет атакам чаще терпеть неудачу.
Оба инструмента дополняют друг друга, и я решаю, какой из них подходит для конкретной ситуации. UFW отличается удобством чтения, особенно на Ubuntu и Debian [3]. iptables предоставляет мне расширенные возможности, например, для NAT, специфических интерфейсов и сложных согласований. Важно: я лаконично документирую свои правила, чтобы потом было легко их поддерживать. Если вы хотите узнать больше о концепции безопасности, вы можете найти четкое введение здесь: Брандмауэр как защитный экран.
Запуск конфигурации: безопасная установка политик по умолчанию
Я начинаю с По умолчанию-Политики: блокировать входящие, разрешить исходящие. Так я предотвращаю непреднамеренный доступ к новым службам. Я всегда разрешаю loopback, чтобы внутренние процессы работали стабильно. Я принимаю существующие соединения, чтобы избежать отмены. Такая последовательность минимизирует ошибки при активации брандмауэра [2][5].
Я использую UFW для установки базы с помощью всего нескольких команд. Затем я детально проверяю состояние, чтобы сразу заметить ошибки ввода. Для особо чувствительных хостов я также ограничиваю исходящие порты. Это снижает риск утечки данных, если служба была взломана. Я часто использую следующие команды:
# UFW: правила по умолчанию
sudo ufw default deny incoming
sudo ufw default allow outgoing
# Альтернативная более строгая политика для исходящих сообщений
sudo ufw default deny outgoing
sudo ufw allow out 53
sudo ufw allow out 80
sudo ufw allow out 443
# Проверка состояния
sudo ufw status verbose
Фильтрация по состояниям: состояния и последовательность
Чистый поток посылок то увеличивается, то уменьшается Контрек заявляет.. Я принимаю установленные соединения первым, отбрасываю недействительные пакеты раньше и оставляю loopback открытым. Это снижает нагрузку и предотвращает побочные эффекты из-за позднего отбрасывания. Для iptables я намеренно задаю порядок:
# iptables: прочная основа
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Всегда разрешайте обратную петлю
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Разрешить существующие/ассоциированные соединения
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Раннее удаление недействительных пакетов
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
В UFW ESTABLISHED/RELATED уже учитываются внутри. Я также обращаю внимание на то, предпочитаю ли я DROP (без звука) или ОТКАЗАТЬСЯ (активный, более быстрый отказ). Для внутренних сетей я предпочитаю REJECT, в публичной сети обычно DROP.
Основные правила для веб-серверов: SSH, HTTP и HTTPS
Я включаю SSH сначала, иначе я легко заблокирую себя. Затем я разрешаю HTTP и HTTPS, чтобы веб-сервер был доступен. Я устанавливаю только те порты, которые мне действительно нужны. Позже я добавляю ограничение скорости или Fail2ban, чтобы пресечь грубые попытки входа. Я немедленно проверяю каждое изменение с помощью команд status или list.
Я использую простые команды для этого. UFW предлагает говорящие псевдонимы для веб-портов, что повышает удобочитаемость. С помощью iptables я могу задать точные порты и протоколы. После этого я сохраняю правила iptables, чтобы они пережили перезагрузку. Вот минимальные шаги:
# SSH
sudo ufw allow 22
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# HTTP/HTTPS
sudo ufw allow http
sudo ufw allow https
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
Безопасный SSH: Ограничивайте и открывайте выборочно
В дополнение к освобождению я гашу атаки с помощью Ограничение скорости или белых списков. UFW обеспечивает простую защиту:
# Ограничение скорости SSH (UFW)
sudo ufw limit 22/tcp comment "SSH Rate Limit"
Я устанавливаю более тонкие ограничения с помощью iptables. Это предотвращает массовое угадывание паролей, не исключая легитимных администраторов:
# SSH: ограничение количества попыток подключения к одному источнику
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --name SSH --set
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --name SSH --update --seconds 60 --hitcount 10 -j DROP
По возможности я разрешаю использовать SSH только с IP-адреса администраторов и работать с ключами SSH. Изменение портов не заменит безопасности, но может снизить уровень шума. Я документирую исключения и регулярно их проверяю.
Защита баз данных и ограничение источников IP-адресов
Я никогда не открываю порты баз данных глобально, а только местный или для определенных IP-адресов источника. Это не позволяет сканерам найти открытые порты MySQL, PostgreSQL или MongoDB. Для локальных приложений в качестве цели достаточно 127.0.0.1; я контролирую доступ внешних администраторов строго по IP. Я кратко документирую изменения, например, в серверной вики. Это экономит мне время во время аудита.
Я часто использую следующие примеры в проектах. Я заранее проверяю корректность каждого разрешенного IP. UFW позволяет использовать чистую нотацию "от-до", iptables реализует ту же логику технически. Я использую дополнительные разрешающие правила для временных окон обслуживания и удаляю их после этого. Это позволяет сохранить небольшой интерфейс:
# Только локально: MySQL
sudo ufw разрешить доступ с 127.0.0.1 на любой порт 3306
iptables -A INPUT -p tcp -s 127.0.0.1 --dport 3306 -j ACCEPT
# Разрешить один IP
sudo ufw allow from 203.0.113.10
iptables -A INPUT -s 203.0.113.10 -j ACCEPT
# Разрешить порт для определенного IP
sudo ufw allow с 10.1.2.3 на любой порт 4444
iptables -A INPUT -p tcp -s 10.1.2.3 --dport 4444 -j ACCEPT
# Блокировка известных злоумышленников
sudo ufw deny from 192.0.2.24
iptables -A INPUT -s 192.0.2.24 -j DROP
Чистая обработка протоколирования, интерфейсов и IPv6
Я включаю Ведение журнала для проверки правил и распознавания заметного трафика. Уровня "on" в UFW достаточно для большинства хостов, более высокие уровни я использую выборочно. Я анализирую журналы с помощью journalctl, fail2ban или инструментов SIEM. Это позволяет мне распознать закономерности в сканировании или попытках грубой силы. В случае обнаружения аномалий я оперативно корректирую правила [2].
Я часто привязываю правила к определенному Интерфейснапример eth0 в сетях общего пользования. Это предотвращает ненужное воздействие на внутренние сети. UFW может "разрешить вход через eth0 на любой порт 80", iptables использует -i для входных интерфейсов. Для IPv6 я проверяю активацию в /etc/default/ufw на "IPV6=yes" и использую ip6tables для собственных правил [2]. Такое разделение позволяет избежать проблем с двухстековыми хостами.
ICMP и ICMPv6: доступность без пробелов
Я оставляю необходимые ICMP-типов, чтобы обнаружение MTU пути, таймауты и диагностика работали. ICMP - это не враг, а ядро протокола IP. Я ограничиваю только чрезмерное эхо.
# IPv4: ограничение эха, разрешение важных типов ICMP
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 5/second --limit-burst 20 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
# UFW: Разрешить ICMP в целом (возможна тонкая настройка в before.rules)
sudo ufw allow in proto icmp
На сайте IPv6 ICMPv6 абсолютно необходим (Neighbour Discovery, Router Advertisement). Я разрешаю основные типы и ограничиваю эхо-запросы:
# IPv6 (ip6tables)
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type router-advertisement -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type neighbour-solicitation -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type neighbour-advertisement -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type echo-request -m limit --limit 5/second --limit-burst 20 -j ACCEPT
Правильно используйте ограничение исходящего потока и NAT/маскарадинг
Я ограничиваю исходящий трафик, когда Профиль риска и соответствия требованиям. Я разрешаю DNS и HTTPS и блокирую все остальное, кроме определенных целей. Это уменьшает количество утечек данных в случае взлома службы. Я создаю определенные исключения для приложений, требующих обновлений или API. Я четко документирую эти исключения и регулярно проверяю их.
Для настройки маршрутизации я использую NAT/Masquerading через UFW-Before-Rules или raw с помощью iptables. Я обращаю внимание на порядок цепочек, чтобы пакеты переписывались правильно. После изменений я тестирую соединение и задержки. Для производственных систем я планирую окно обслуживания и делаю резервные копии конфигурации. Это позволяет мне отслеживать сетевые пути [7].
Исходящие данные: системные службы и протоколы
При строгой политике исходящих сообщений я специально разрешаю DNS (53/udp), HTTPS (443/tcp) и, если требуется NTP (123/udp). Для почтовых серверов я добавляю 25/tcp и 587/tcp. Я не разрешаю доменные исключения на уровне пакетов, а использую прокси-серверы или логику приложения.
# UFW: типичные системные службы
sudo ufw allow out 123/udp # NTP
sudo ufw allow out 25/tcp # SMTP - только если почтовый сервер
sudo ufw allow out 587/tcp # Submission - только при необходимости
# iptables: определенное разрешение
iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 587 -j ACCEPT
Docker и брандмауэры: как избежать подводных камней
Docker устанавливает свой собственный iptables-правила, которые могут повлиять на мою политику. Поэтому я проверяю цепочки NAT и FORWARD после каждого запуска компа или демона. Я намеренно освобождаю открытые порты и избегаю "-p 0.0.0.0:PORT". Вместо этого я привязываю их к управляющему IP или обратному прокси. Так вектор атаки становится меньше и заметнее [1].
Я держу брандмауэры хостов активными, несмотря на Docker. Я также контролирую группы безопасности на уровне инфраструктуры, если это возможно. В случае конфликтов между UFW и Docker я использую документированные обходные пути или устанавливаю правила в DOCKER-USER. Важно четко распределить обязанности: хост всегда блокирует, контейнеры открываются только в явном виде. Такой порядок предотвращает неосознанные релизы.
# DOCKER-USER: применение глобальной политики хостов перед правилами Docker
iptables -N DOCKER-USER 2>/dev/null || true
iptables -I DOCKER-USER -s 192.0.2.24 -j DROP
iptables -A DOCKER-USER -j RETURN
Тонкие настройки UFW: Последовательность, профили и маршрутизируемый трафик
Когда важна точность, я использую "вставить", "пронумерованный" и профили приложений. Так я сохраняю чистоту последовательности правил и использую проверенные определения служб.
Последовательность управления #
sudo ufw insert 1 deny in from 198.51.100.0/24
# Нумерованный вид и целевое удаление
sudo ufw status numbered
sudo ufw delete 3
# Профили приложений (например, Nginx Full)
sudo ufw app list
sudo ufw app info "Nginx Full"
sudo ufw allow "Nginx Full"
# Блокируйте маршрутизируемый трафик по умолчанию (переадресация)
sudo ufw default deny routed
Более сложные исключения я храню в before.rules соответственно после.правила. Там я могу разместить тонкую настройку ICMP или точную настройку NAT, не теряя при этом читаемости стандартных правил.
Постоянные правила: Сохранение и восстановление
Правила UFW таковы постоянный и автоматически переносит перезагрузку. Это значительно упрощает администрирование на хостах Debian/Ubuntu. В iptables я сохраняю правила после изменений и восстанавливаю их при запуске. Для этого я использую iptables-save/restore или netfilter-persistent. Без этих шагов я теряю изменения после перезапуска [5].
Я проверяю устойчивость систематически: планирую перезагрузку, затем проверяю состояние. Если счетчики и цепочки верны, конфигурация надежна. Если правила отсутствуют, я исправляю путь загрузки в контексте init или systemd. Эта процедура позволяет избежать неожиданностей во время обслуживания. Документирование и резервное копирование файлов правил завершают процедуру.
# Debian/Ubuntu: Постоянство для iptables
sudo apt-get install -y iptables-persistent
sudo netfilter-persistent save
# Резервное копирование вручную
sudo iptables-save | sudo tee /etc/iptables/rules.v4
sudo ip6tables-save | sudo tee /etc/iptables/rules.v6
Восстановление # (если требуется)
sudo iptables-restore < /etc/iptables/rules.v4
sudo ip6tables-restore < /etc/iptables/rules.v6
Производительность и защита: ограничения, наборы и настройка ядра
Когда нагрузка велика, я уменьшаю количество элементов управления и использую целевые Ограничения по ставкам. Для больших списков блоков я работаю с ipset, чтобы сократить время поиска. Я также использую системные механизмы защиты:
# Содержит SYN-флуд (ядро)
sudo sysctl -w net.ipv4.tcp_syncookies=1
# Ограничьте скорость HTTP-соединений для каждого IP-адреса источника (пример)
iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW
-m hashlimit --hashlimit-name http_rate --hashlimit-above 50/second
--hashlimit-burst 100 --hashlimit-mode srcip -j DROP
Я сохраняю размер Стол для транспортировки с первого взгляда. При большом количестве одновременных подключений я увеличиваю nf_conntrack_max, но предварительно тестирую эффект.
Управление, испытания и предотвращение ошибок
Я ухожу SSH прежде чем активировать "запрет на входящие". Затем я проверяю со второй сессии, остается ли доступ стабильным. Я проверяю каждое новое правило с помощью "ufw status verbose" или "iptables -L -v". Это позволяет мне узнать счетчики попаданий и увидеть, попадают ли пакеты в ожидаемую цепочку. Перед внесением серьезных изменений я делаю резервную копию файлов брандмауэра.
Для обеспечения комплексной безопасности я сочетаю брандмауэр с мерами по укреплению системы. К ним относятся безопасные настройки SSH, управление исправлениями и минимальное количество служб. Мне нравится использовать практическое руководство в качестве контрольного списка: Упрочнение серверов для Linux. Я регулярно повторяю эти проверки и придерживаюсь установленных сроков обслуживания. Это позволяет поддерживать мои серверы в надежной форме.
Расширенные испытания и наблюдения
Я проверяю внешнее воздействие с помощью Сканирование портов из внешней сети и проверять открытые сокеты внутри сети. Я внимательно слежу за журналами в самом начале, чтобы распознать ложные выводы на ранних этапах.
Открытые розетки #
ss -lntup
# Компактный обзор iptables
sudo iptables -S
sudo iptables -L -v -n
# UFW: подробное состояние и журналы
sudo ufw status verbose
journalctl -k | grep -i ufw
# Внешняя проверка (с другого узла/сети)
nmap -Pn -p 22,80,443
Для изменений, связанных с высоким риском, я планирую Уровень резервного копирования включено. Я работаю в Screen/Tmux и, если необходимо, устанавливаю сброс по времени, если я заблокирую себя. После успешной проверки я снова отменяю действие отката.
# Пример: автоматическая деактивация в качестве аварийного якоря (используйте осторожно)
echo "ufw disable"| at now + 2 minutes
# Повторное удаление после успешной проверки: atrm
Сравнение хостинг-провайдеров: Фокус на интеграции брандмауэра
Для хостинга я полагаюсь на Безопасность близко к платформе. Настраиваемые политики, быстрое развертывание правил и хороший мониторинг приносят свои плоды. В текущих сравнениях webhoster.de впечатляет аккуратно интегрированными опциями брандмауэра и быстрой поддержкой. Те, кто предпочитает панельные настройки, получают четкие инструкции по Брандмауэр Plesk. В следующей таблице представлены основные критерии.
| Поставщик | Интеграция с брандмауэром | Производительность | Поддержка | Размещение |
|---|---|---|---|---|
| веб-сайт webhoster.de | индивидуальная конфигурация. | Очень высокий | топ | 1 |
| Провайдер B | Стандарт | высокий | хорошо | 2 |
| Провайдер C | Стандарт | хорошо | Удовлетворительно | 3 |
Практические примеры: От теста к производственному правилу
Я начинаю каждый набор правил в Экран или во втором сеансе SSH. Таким образом, я могу спастись в случае ошибки в работе. Только когда тестовый хост работает нормально, я применяю правила в производстве. Правила обратного пути и план отката обеспечивают мне дополнительную безопасность. В конце я лаконично документирую изменения в журнале изменений.
Я использую повторяющиеся строительные блоки для веб-серверов: разрешить SSH, разрешить HTTP/S, привязать внутренние порты локально, залогиниться, ограничить ICMP, заблокировать лишние протоколы. Затем я забочусь о правилах зеркалирования IPv6, чтобы не оставалось пробелов. Я всегда проверяю цепочки Docker отдельно, потому что они устанавливают собственные пути. Наконец, я подтверждаю доступ с помощью внешних проверок и мониторинга. Таким образом, интерфейс остается чистым и отслеживаемым [1][2].
Резюме для администраторов
С четким Правила и несколько команд, я надежно защищаю веб-серверы. Входящие порты по умолчанию запрещены, сначала SSH, затем HTTP/S - это стабильная основа. Порты баз данных только локально или через белый список, активное протоколирование, соблюдение IPv6, проверка цепочек docker. Постоянное хранение и регулярные тесты предотвращают неприятные сюрпризы. Такая рутина обеспечивает доступность сервисов и значительно снижает риски.
Независимо от того, использую ли я UFW или iptables напрямую, четкая и экономичная политика имеет решающее значение. Я кратко документирую, регулярно проверяю и свожу исключения к минимуму. Ограничение исходящих соединений останавливает ненужные подключения и ограничивает ущерб в случае компрометации. Благодаря практическому наблюдению за журналами я быстрее распознаю аномалии и реагирую соответствующим образом. Таким образом, веб-сервер становится устойчивым, а площадь атаки - небольшой.
