Ответ
В DevOps использую фаервол в двух плоскостях: на уровне ОС (host-based) и на уровне сети. На самих серверах предпочитаю nftables как современную замену iptables.
Базовая политика на сервере с помощью nftables:
Создаю конфигурационный файл /etc/nftables.conf:
#!/usr/sbin/nft -f
flush ruleset
define PRIVATE_NETS = { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 }
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
# Разрешаем established/related соединения
ct state established,related accept
# Разрешаем loopback
iif lo accept
# Разрешаем ICMP (ping)
ip protocol icmp accept
# Разрешаем входящий SSH только из внутренних сетей
tcp dport 22 ip saddr $PRIVATE_NETS accept
# Разрешаем входящие HTTP/HTTPS для веб-сервера
tcp dport { 80, 443 } accept
}
chain forward {
type filter hook forward priority 0; policy drop;
}
chain output {
type filter hook output priority 0; policy accept;
}
}Активирую и добавляю в автозагрузку: sudo systemctl enable --now nftables.
Для управления в масштабе инфраструктуры:
- Использовал Ansible для распространения единых правил nftables на группы серверов (например, все web-серверы получают правило на порт 80/443, а базы данных — только на 5432 из определенной подсети).
- На облачных серверах (AWS EC2, GCP Compute) правила фаервола на уровне инстансов дублировал Security Groups, что создает два уровня защиты.
- Важно: Всегда сначала добавлял правило для текущей SSH-сессии, чтобы не заблокировать себя, и использовал
nft --checkдля валидации конфига перед применением.
Ответ 18+ 🔞
А, ну это же про фаерволы, ебать мои старые костыли! Ну что, расскажу, как я с этой штукой вожусь, чтобы тебя, чувак, не выкинуло из сервера в самый неподходящий момент.
Смотри, в девопсе я обычно ставлю эту защиту в двух местах, как будто два замка на дверь вешаю. Первый — прямо на самой операционке сервака (это host-based), а второй — на уровне всей сети. На самих железках я уже давно перешёл с этих древних iptables на nftables. Это как с тазика на мерседес пересесть — удобнее, логичнее, и конфиги не такие пиздец какие страшные.
Вот, смотри, как я обычно базовую политику на сервере через nftables делаю. Беру и создаю файлик /etc/nftables.conf. Главное тут — не накосячить с правилами, а то сам себя заблокируешь и потом будешь охуевать, как мартышлюшка, перед монитором.
#!/usr/sbin/nft -f
flush ruleset
define PRIVATE_NETS = { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 }
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
# Разрешаем established/related соединения
ct state established,related accept
# Разрешаем loopback
iif lo accept
# Разрешаем ICMP (ping)
ip protocol icmp accept
# Разрешаем входящий SSH только из внутренних сетей
tcp dport 22 ip saddr $PRIVATE_NETS accept
# Разрешаем входящие HTTP/HTTPS для веб-сервера
tcp dport { 80, 443 } accept
}
chain forward {
type filter hook forward priority 0; policy drop;
}
chain output {
type filter hook output priority 0; policy accept;
}
}Потом просто активирую это дело и в автозагрузку пихаю: sudo systemctl enable --now nftables. Но это, бля, цветочки. Когда серверов становится овердохуища, вручную уже не поправишь.
Поэтому для масштаба я юзаю Ansible. Представляешь? Одной командой раскидываю одинаковые правила на кучу серверов. Всем веб-серверам — открываю 80 и 443 порты, а базам данных — только 5432, да и то из строго определённой подсети. Красота, а не работа.
На облачных штуках, типа AWS EC2 или GCP, там вообще весело. Ты на инстансе правила nftables настроил, а потом ещё и Security Groups в самом облаке накручиваешь. Получается такая двойная защита, как будто хуй в пальто — и тепло, и безопасно.
И вот самый главный лайфхак, чтобы не было потом волнения ебать: ВСЕГДА сначала добавляй правило для своей текущей SSH-сессии! А то бывало, накосячишь, применишь конфиг, а тебя — хоба! — и выкинуло. Сидишь и думаешь: «Ну я и пизда рулю». И ещё, перед тем как всё применять, обязательно гоняю проверку через nft --check. Мало ли, запятую не там поставил или скобку забыл — терпения ноль ебать потом восстанавливать доступ.