linux - Will this iptables rule accept all traffic, making my other rules useless?

I've adapted this iptables configuration from someone else, and am trying to figure out whether it's doing what I want it to. It is supposed to run on a coreos server, with several docker containers, and function as a webserver.

So ports 80 and 443 should be open, icmp traffic is allowed and I need ssh access. I've rate limited ssh and put it on a different port and traffic is dropped by default. As far as I can tell it's all good. However one rule I don't understand: -A INPUT -i eth1 -j ACCEPT. I believe this rule is there to allow docker containers to talk to eachother.

But will that rule not open up the entire interface to the www? What does this rule do exactly? Do I need it for docker, or can I omit it?

This is the entire config:

  *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

Output of 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

Related:

Answer

From your routing table, it appears you have no eth1 interface, which is quite strange, for a router.

The normal configuration for a router is: one interface (eth0) connected to the outer world, another interface (eth1) is your LAN. Then the iptables rules make sense: they strictly control input on interface eth0, while they allow everything to flow inside your LAN. For this to work, however, you will also need:

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

Without the first one, which flatly contradicts your policy (:FORWARD DROP [0:0]) pcs inside your LAN will never be able to talk to the outside world; the second one also makes it possible for pcs inside your LAN to talk to the outside world, by rewriting the source address of your packets to that of the outer interface of your router, which will allow replies to come back, and then your router takes care automagically of sending the reply packet to its intended recipient. If you do not wish pcs on your LAN to talk to the world, you can drop both rules.

As your set of rules and your interfaces stand instead, since there is no eth1 interface (and hence no LAN), the rule you are fretting about is utterly useless. The rules simply make the current pc a well-policed one, with some services accessible from outside, but without performing the functions generally associated with a router, i.e. NAT and firewall for your LAN.

How to proceed depends on what you are aiming to achieve.