Будет ли это правило iptables принимать весь трафик, делая другие мои правила бесполезными?

Question

Я адаптировал эту конфигурацию iptables от кого-то другого и пытаюсь выяснить, делает ли он то, что я хочу. Предполагается, что он будет работать на сервере coreos с несколькими контейнерами Docker и функционировать как веб-сервер.

Так что порты 80 и 443 должны быть открыты, трафик icmp разрешен, и мне нужен доступ ssh. Я ограничил скорость SSH и поставил его на другой порт, и трафик по умолчанию отбрасывается. Насколько я могу сказать, это все хорошо. Однако одно правило, которое я не понимаю: -A INPUT -i eth1 -j ACCEPT . Я полагаю, что это правило существует для того, чтобы контейнеры докера могли общаться друг с другом.

Но разве это правило не откроет весь интерфейс к www? Что именно делает это правило? Нужно ли это для докера, или я могу опустить это?

Это весь конфиг:

  *filter
  :INPUT DROP [0:0]
  :FORWARD DROP [0:0]
  :OUTPUT ACCEPT [0:0]

  # Loopback interface
  -A INPUT -i lo -j ACCEPT

  # What does this rule do exactly? Do I need it?
  -A INPUT -i eth1 -j ACCEPT

  # Already established connections
  -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

  # Web services
  -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
  -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

  # Rate limit SSH
  -A INPUT -p tcp --dport 2233 -m state --state NEW -m recent --set --name SSH
  -A INPUT -p tcp --dport 2233 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
  -A INPUT -p tcp --dport 2233 -m state --state NEW -j ACCEPT

  # ICMP traffic
  -A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
  -A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
  -A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
  COMMIT

Вывод ip route list

default via {ip here}.64.1 dev eth0  proto static
10.18.0.0/16 dev eth0  proto kernel  scope link  src 10.18.0.5
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1
{ip here}.64.0/18 dev eth0  proto kernel  scope link  src {ip here}.86.198

Связанные с:

• https://serverfault.com/questions/705192/iptables-rule-set-so-that-a-docker-container-can-access-a-service-on-a-host-ip
• https://www.jimmycuadra.com/posts/securing-coreos-with-iptables/
• https://gist.github.com/jimmycuadra/fe79ae8857f3f0d0cae1
• https://gist.github.com/socketwiz/d6fe23d19180a1ad8b5a

Answer 1

Из таблицы маршрутизации кажется, что у вас нет интерфейса eth1 , что довольно странно для маршрутизатора.

Обычная конфигурация для маршрутизатора: один интерфейс (eth0) подключен к внешнему миру, другой интерфейс (eth1) - это ваша локальная сеть. Тогда правила iptables имеют смысл: они строго контролируют ввод на интерфейсе eth0, в то время как они позволяют всему течь внутри вашей локальной сети. Однако, чтобы это работало, вам также понадобятся:

iptables -A FORWARD -j ACCEPT 
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Без первого, который категорически противоречит вашей политике (:FORWARD DROP [0:0]), сотрудники вашей локальной сети никогда не смогут общаться с внешним миром; второй также позволяет ПК внутри вашей локальной сети общаться с внешним миром, перезаписывая адрес источника ваших пакетов на адрес внешнего интерфейса вашего маршрутизатора, что позволит возвращать ответы, а затем ваш маршрутизатор принимает заботиться автоматически об отправке ответного пакета предполагаемому получателю. Если вы не хотите, чтобы ПК в вашей локальной сети общались с миром, вы можете отказаться от обоих правил.

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

Как действовать, зависит от того, чего вы хотите достичь.