ac3cloud / ript

Ript provides a clean Ruby DSL for describing firewall rules, and implements database migrations-like functionality for applying the rules
MIT License
107 stars 9 forks source link

Use rule comments in log messages #3

Open auxesis opened 11 years ago

auxesis commented 11 years ago

Right now we mandate users specify a comment when defining a rule, but we just throw away the comment.

We could use this comment in the log messages, so the following:

partition "keepalived" do
  label "primary lvs",   :address => "172.16.0.216"
  label "secondary lvs", :address => "172.16.0.217"
  label "fw multicast",  :address => "224.0.0.0/8"

  accept "keepalive chatter on the fw multicast", :log => true do
    protocols "vrrp"
    from      "primary lvs", "secondary lvs"
    to        "fw multicast"
  end
end

Would emit a rule that looks like this:

iptables --table filter --append keepalive-ac0ff33 --protocol vrrp --destination 224.0.0.0/8 --source 172.16.0.216 --jump LOG --log-prefix "keepalive chatter on the fw multicast"

This would make analysing packet filtering behaviour via logging much easier.

One small caveat: per the iptables documentation there is a character limit on --log-prefix

--log-prefix prefix
       Prefix log messages with the specified prefix; up to 29 letters long, and useful for distinguishing mes-
       sages in the logs.

So the argument would need to be trimmed like this:

--log-prefix "keepalive chatter on the fw m"
laminat0r commented 11 years ago

If we're accepting the traffic in question, then that's very much a debugging or auditing type option that you wouldn't want enabled by default... It'd be problematic to implement globally unless we apply some very strict rate-limiting to it (like max one per second? Even then it'd probably be a significant I/O increase).

For arbitrarily dropped traffic, sure - it makes sense to log that stuff.

auxesis commented 11 years ago

@laminat0r this would only be enabled if you did :log => true on a rule or a partition, so it wouldn't instantly burn us in production.

Agree it should only be used for debugging, and there should be suitable disclaimers in the documentation explaining the performance impact.

I think enabling --log-prefix by default is a good idea, but we could also provide an option to disable it (:debug => false?) if you want fast production logging.