Uploaded image for project: 'Modules'
  1. Modules
  2. MODULES-5268

firewall : Lack of source parameter danger

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: firewall
    • Labels:
      None
    • Environment:

      Linux

    • QA Risk Assessment:
      Needs Assessment

      Description

      Basic Info
      Module Version: 1.9
      Puppet Version: 4.10.4
      OS Name/Version: Debian 7/8/9

      We had an incident in our network, which was caused by a human mistake. Basically, what we had was something like:

      firewall { '123 Allow 192.168.1.0 access to Elastic':
        port => '9200',
        proto => 'tcp', 
        action => 'accept',
      }
      

      What was forgotten here, is the 'source' parameter. The result is that port 9200 is open for the whole world. As a result someone dropped/emptied the entire ElasticSearch database and a security incident was born.

      We have discussed this issue internally and came to the conclusion that it is an easy-to-make mistake to forget the source parameter, and something should be added to the module to prevent this mistake (eg. throw error or warning). We thought for example of making the source parameter required, so it has to be set to eg. '0.0.0.0/0' if you really want something open for the entire world.

      This turned out to be difficult to implement for us (with little Ruby knowledge), as the module seems to convert 0.0.0.0/0 to 'nill', and omit the source parameter when convertering to iptables rules. We got a little stuck there.

      So this is not a bug report perse, but an attempt to start a discussion about wether or not the source parameter should or should not be required and if so, how we can implement that.

      Desired Behavior:

      Discuss wether the source parameter should be required.

      Actual Behavior:

      Source parameter is optional.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              rudybroersma Rudy Broersma
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Zendesk Support