AnsweredAssumed Answered

Bypassing IPS Protections - MySQL

Question asked by Michael Horne on Nov 5, 2018
Latest reply on Nov 8, 2018 by Michael Horne



I am a bit of the Threat Protection / IPS newbie.  I have done a bit of a search for this issue, but I do not find something matching


There is a service definition for MySQL that matches TCP port 3306. We have an SAP application that is also using TCP port 3306, but not for MySQL.  This was triggering an IPS event that was in "prevent" and was blocking the traffic:


IPS Event

Note: I have managed to enter a global exception for the destination server so that the action is only "detect".


I would like to have no MySQL traffic to be able to use TCP port 3306 without triggering this protection. I cannot directly create an exception like I have for other IPS protection based on source and destination etc. I get the following:



The protection details in the log do not provide any helpful information about what is actually being triggered:


The only IPS protection that I find that seems to match is "General Settings"



When I look at the details of this protection, the only thing I can do is to change the port associated with MySQL:



I could change port associated with MySQL for the IPS, but I do not want to do this for three reason:

  1. I might want the IPS to detect SQL traffic when it is suing the default port.
  2. Changing the port, will just move the same problem to a different port, that might eventually block another application.
  3. This doesn't seem like the "best practices" solution to the problem.


It appears to me that the IPS is assuming the traffic is MySQL based on the TCP port and the applying a protocol analysis / validation based on this.


For this application I have a known / single source and a known / single destination and ideally I would like to disable this protection for this particular source / destination pair.


The only IPS protection that might match this is call "non compliant MySQL".



I do no know if adding a protection for this will help or not. If this was the IPS protection was involved. I would have expected the original log message would have mentioned this in the protection details.


At the moment I have added an exception for the destination server as the "protected Scope" that has an action of "Detect", but as I cannot match the protection "My SQL - General Settings", I have had to set "Detect" for all IPS detections for the destination host.