[MXS-3207] Dbfwfilter Wildcard Handling not Documented Correctly Created: 2020-09-25  Updated: 2021-09-30  Resolved: 2020-10-05

Status: Closed
Project: MariaDB MaxScale
Component/s: dbfwfilter, Documentation
Affects Version/s: 2.4.11
Fix Version/s: 2.3.21

Type: Bug Priority: Major
Reporter: Rob Schwyzer Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None
Environment:

CentOS


Sprint: 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)?


 Comments   
Comment by markus makela [ 2020-10-05 ]

In practice, the following are supported:

  • user@host
  • user@%
  • %@host

The dbfwfilter documentation does state, albeit not clearly, that partial wildcards aren't supported. The fact that the same character that MariaDB uses for wildcards is unfortunate and the limitation that it supports either a full match or a wildcard needs to be documented more clearly.

Comment by markus makela [ 2020-10-05 ]

Clarified the documentation on the dbfwfilter user definitions.

Generated at Thu Feb 08 04:19:44 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.