IDS blocking packets

[rhbirkelund]

Hey

I have an MX at a customer that seems to be blocking traffic to a MySQL server. It looks like the traffic is being blocked by IDS matching the Snort rule 1-3668 "MySQL client authentication bypass attempt". In this case however, it seems to be valid traffic, as it is a user accessing data within PowerBI. 

Aside from whitelisting the rule, what would be the best course of action to allow this traffic? According to the Snort rule, it has something to do with MySQL 4.1.x. Would it be to has the customer to upgrade they database? Or is there anything else we could do?

[Mloraditch]

I can't speak as someone who's experienced the issue, but presuming your customer's mysql version is vulnerable I would try and do that update as that version of MySQL is EXTREMELY old (Circa mid 2000s), although that could present other challenges.

If the version is newer and not vulnerable, I'd open a support case so they can at least analyze and forward over to snort to fine tune the rule as its presumably a false positive. In that case I'd also be ok with whitelisting it.

[rhbirkelund]

At least it is a possibility to upgrade the service, instead of white listing the rule.

[PhilipDAth]

Since it is expected, I would whitelist the IDS signature.

MySQL did a change a while ago that now requires passwords to be encrypted with sha2.  What's the bet it was related to a vulnerability that was found.

https://repost.aws/questions/QUWAfAVNWPT6mECbrJLLisYg/rds-mysql-native-password-is-deprecated-and-wi...

[rhbirkelund]

Wouldn’t whitelisting the rule risk allowing true positives?

[PhilipDAth]

Security that prevents the business from operating is a fail.  🙂

[rhbirkelund]

Correct, but punching a hole in the door, makes it less secure? 🤔

[PhilipDAth]

Yes, but it has to be balanced.  Otherwise, if you take it to the extreme, you'd disconnect the Internet to maximise security.  If security is so obstructive that it prevents the business from working, then it is useless.  It adds no value to the business.

In this case, the traffic is expected, known, and understood. I'm guessing they don't host any MySQL databases onsite, so the risk is not to the company, but to remote companies hosting MySQL databases.

[GIdenJoe]

I believe he is referring to the fact that if you whitelist the rule and a bad actor that could otherwise get through the L3/4 firewall due to his/her location in the network he could take advantage of that rule no longer being enforced.

I believe this issue has more to do with the fact that you can't be very granular with your policies on the MX.  It's either on or off for all flows passing through the appliance.  On an FTD for example you can apply a different IPS policy to a different access rule.  So you could whitelist the rule for A to B but still have it blocked from C to B.

[Brash]

If possible, absolutely have the customer upgrade MySQL.

As said above, that version is ancient.

If that's not feasible, it's likely whitelisting will be your only option.

And while not ideal, it's a risk that your customer will need to accept.

[KarstenI]

Unrelated to this problem, but it shows that IPS has false positives:

The MX-IPS (balanced) dropped traffic when I tried to add a Cisco ISE to Windows AD. Something triggered the Snort rule in this traffic.