Uploaded image for project: 'MariaDB MaxScale'
  1. MariaDB MaxScale
  2. MXS-3207

Dbfwfilter Wildcard Handling not Documented Correctly

    XMLWordPrintable

Details

    • MXS-SPRINT-116

    Description

      MariaDB and MaxScale appear to handle resolving/attributing source IP/hostnames differently. This can be fine as this can enable MaxScale to offer more fine-grained control than MariaDB. However, we need to verify this is operating as intended. Secondarily, there may be an issue with MaxScale's dbfwfilter when using wildcards for IPv6 addresses.

      Observed Behavior

      Setup is MariaDB and MaxScale on the same server. MariaDb running on port 3360 and MaxScale on port 3370. MariaDB has two users configured-

      test@1.2.3.4
      test@1.test.com

      Here are sample tcpdump s from remote connections to each-

      tcpdump -i any port 3360 and src 1.test.com -vvv -X -s0 -q -tttt
      tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
      2020-09-24 07:52:26.928643 IP (tos 0x0, ttl 58, id 39239, offset 0, flags [DF], proto TCP (6), length 48)
      1.test.com.31771 > 2.test.com.xss-port: tcp 0
       
      tcpdump -i any port 3370 and src 1.test.com -vvv -X -s0 -q -tttt
      tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
      2020-09-24 07:50:52.262367 IP (tos 0x0, ttl 58, id 31166, offset 0, flags [DF], proto TCP (6), length 48)
      1.test.com.31441 > 2.test.com.rtmp-port: tcp 0

      Note both connections use proto TCP (6).

      In spite of this, MariaDB accepts the connection and its authentication. Meanwhile, MaxScale sees this-

      2020-09-24 07:50:52 info : (1) Started Read-Write-Service client session [1] for 'test' from ::ffff:1.2.3.4

      This necessitates handling IPv6 separately, at least for dbfwfilter. This would be fine, except for MaxScale failing to recognize IPv6 addresses when wild cards are invovled. Here is the rule which worked-

      users test@::ffff:1.2.3.4 match any rules block_select block_insert block_update block_delete block_drop block_alter block_create block_load

      Here are examples of rules with wildcards which did not work-

      users test@::ffff:%1.2.3.4 match any rules block_select block_insert block_update block_delete block_drop block_alter block_create block_load

      users test@%1.2.3.4 match any rules block_select block_insert block_update block_delete block_drop block_alter block_create block_load

      users test@%:1:2:3:4 match any rules block_select block_insert block_update block_delete block_drop block_alter block_create block_load

      users test@%1:2:3:4 match any rules block_select block_insert block_update block_delete block_drop block_alter block_create block_load

      Questions to Answer

      1. Should MariaDB and MaxScale see and resolve incoming source addresses the same way?
      2. Does dbfwfilter intend to filter based on observed source address or based on resolved source address (context- current rule formatting is identical to MariaDB user authentication, suggesting dbfwfilter will map connection attempts to user@host combinations exactly as MariaDB does- is this intended? Or is it intended dbfwfilter uses regex to match the specific IP/hostname a connection presents?)
      3. Why are wildcards and IPv6 not working? Is this a known deficiency, a bug, or a configuration issue (ex- should % be placed or arranged differently)?

      Attachments

        Activity

          People

            markus makela markus makela
            rob.schwyzer@mariadb.com Rob Schwyzer
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.