Uploaded image for project: 'VCL'
  1. VCL
  2. VCL-1102

rules and chains are not being removed with older versions of firewalld

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 2.5
    • Fix Version/s: None
    • Component/s: vcld (backend)
    • Labels:
      None
    • Environment:

      Description

      I had a CentOS 7.0 reservation and noticed someone pecking from a Chinese IP:

      Jun 26 13:32:39 centos7 sshd[5413]: Failed password for invalid user root from [CHINESE IP] port 44276 ssh2

       This shouldn't be possible if the firewall is configured correctly.  VCL limits access to the reservation user's IP address once they connect.

      The problem was that the vcl-reserved chain was still present after I logged in and the request state was inuse.  This chain should have been deleted.  This is a security problem because the vcl-reserved chain is what is used to temporarily open access from any remote IP address.

      Once a user connection is detected, the code adds another vcl-post_load with IP restricted rules and deletes the vcl-reserved chain.  Based on the vcld.log output, the VCL code appears to have done this:

      firewalld.pm:remove_direct_chain_rules|369|removed direct rule from 'vcl-reserved' chain in
      'filter' table on vclv99-68: '0 --jump ACCEPT --protocol tcp --match comment --comment 'VCL: allow traffic from any IP address to connect meth
      od ports during reserved stage of reservation 3527645 (2018-06-26 15:03:35)' --match tcp --dport 22'

      firewalld.pm:delete_chain|440|deleted 'vcl-reserved' chain in 'filter' table on <VM>

      The previous commands use the --permanent argument, so afterwards the code runs firewall-cmd --reload to enact the saved, permanent the configuration:

      firewalld.pm:save_configuration|261|reloaded firewalld configuration on vclv99-101

      As an added check, the code makes sure no lines got left in direct.xml: 

      no lines were pruned from /etc/firewalld/direct.xml matching pattern: 'filter.*jump\s+vcl-reserved'

       

      So, it looks like the code is doing things correctly.  I then tried to manually ran the commands as root:

      iptables -nL

      Chain vcl-reserved (1 references)
      target prot opt source destination
      ACCEPT tcp – 0.0.0.0/0 0.0.0.0/0 /* VCL: allow traffic from any IP address to connect method ports during reserved stage of reservation 3527645 (2018-06-26 15:03:35) */ tcp dpt:22

       

      firewall-cmd --permanent --direct --remove-rule ipv4 filter vcl-reserved 0 --jump ACCEPT --protocol tcp --match comment --comment 'VCL: allow traffic from any IP address to connect method ports during reserved stage of reservation 3527645 (2018-06-26 15:03:35)' --match tcp --dport 22

      success

      firewall-cmd --reload

      success

      Still there:

      iptables -nL

      Chain vcl-reserved (1 references)
      target prot opt source destination
      ACCEPT tcp – 0.0.0.0/0 0.0.0.0/0 /* VCL: allow traffic from any IP address to connect method ports during reserved stage of reservation 3527645 (2018-06-26 15:03:35) */ tcp dpt:22

      Try --complete-reload:

      firewall-cmd --complete-reload

      success

      Still there:

      iptables -nL

      Chain vcl-reserved (1 references)
      target prot opt source destination
      ACCEPT tcp – 0.0.0.0/0 0.0.0.0/0 /* VCL: allow traffic from any IP address to connect method ports during reserved stage of reservation 3527645 (2018-06-26 15:03:35) */ tcp dpt:22

      Restart service: 
      systemctl restart firewalld

      iptables -nL
      vcl-reserved rule is gone.

       

      This was an old 7.0 version of CentOS.  I tried a revision of the same image that had been updated to CentOS 7.3 and it behaved differently, not exhibiting this problem.  The vcl-reserved chain had been removed during the vcld steps.

      So, it seems as though firewall-cmd --reload isn't sufficient for some older versions of firewalld.  The code needs to be extended with additional checks.  If the chain still exists after attempts to delete it seemed to be successful, the firewalld service should be restarted.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              arkurth Andrew Kurth
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated: