Unable to squelch ET POLICY Outbound MSSQL Connection to Standard port (1433)

272 views
Skip to first unread message

CrashOverride

unread,
Mar 23, 2017, 11:36:20 AM3/23/17
to security-onion
Hello all,
I have looked high and low to try to resolve this issue but I haven’t found anything that can lead me to an answer. So here is how my network is laid out:

Master Server
SGUIL, ELSA, etc.

Sensor 1
Interface 1
DMZ = 192.168.1.0/24
HOME_NET= [192.168.1.0/24]
EXTERNAL_NET= !$HOME_NET
Interface 2
Direct Traffic to Internet = 10.0.0.0/8
HOME_NET= [10.0.0.0/8]
EXTERNAL_NET= !$HOME_NET
Sensor 2
Interface 1
Internal traffic = 10.0.0.0/8
HOME_NET = [10.0.0.0/8]
EXTERNAL_NET = [10.0.0.0/8]

The issue is related to this message:
ET POLICY Outbound MSSQL Connection to Standard port (1433)

alert tcp $HOME_NET any -> $EXTERNAL_NET 1433 (msg:"ET POLICY Outbound MSSQL Connection to Standard port (1433)"; flow:to_server,established; content:"|12 01 00|"; depth:3; content:"|00 00 00 00 00 00 15 00 06 01 00 1b 00 01 02 00 1c 00|"; distance:1; within:18; content:"|03 00|"; distance:1; within:2; content:"|00 04 ff 08 00 01 55 00 00 00|"; distance:1; within:10; flowbits:set,ET.MSSQL; classtype:bad-unknown; sid:2013410; rev:4;)

We have clients on our Internal network that are in constant contact with our SQL server and as a result I am getting pummeled with events. I have tried to disable the alert using disablesid.conf on the Master Server and attempted to use rule-update to push the change with no luck. Further research suggested that due to the fact that the rule was “flow-bit” based I would need to disable all of the related flow-bit rules as well. I attempted this as well with no luck. I am literally lost as to how to disable this rule. Attempted to threshold it as well with no results so I am at a complete loss as to how to proceed. Any help is appreciated. Here is what I have attempted so far.

Disabledsid.conf
#ET POLICY Outbound MSSQL Connection to Standard port (1443)
1:2013410
#ET POLICY Outbound MSSQL Connection to Non-Standard Port - Likely Malware
1:2013409
#ET TROJAN Bancos.DV MSSQL CnC Connection Outbound
1:2013411

Local.rules
ipvar OVERACTIVE [10.0.0.0/8]

alert tcp $HOME_NET any -> !$OVERACTIVE 1433 (msg:"ET POLICY Outbound MSSQL Connection to Standard port (1433)"; flow:to_server,established; content:"|12 01 00|"; depth:3; content:"|00 00 00 00 00 00 15 00 06 01 00 1b 00 01 02 00 1c 00|"; distance:1; within:18; content:"|03 00|"; distance:1; within:2; content:"|00 04 ff 08 00 01 55 00 00 00|"; distance:1; within:10; flowbits:set,ET.MSSQL; classtype:bad-unknown; sid:1000100; rev:1;)

alert tcp $HOME_NET any -> !$OVERACTIVE !1433 (msg:"ET POLICY Outbound MSSQL Connection to Non-Standard Port - Likely Malware"; flow:to_server,established; content:"|12 01 00|"; depth:3; content:"|00 00 00 00 00 00 15 00 06 01 00 1b 00 01 02 00 1c 00|"; distance:1; within:18; content:"|03 00|"; distance:1; within:2; content:"|00 04 ff 08 00 01 55 00 00 00|"; distance:1; within:10; flowbits:set,ET.MSSQL; classtype:bad-unknown; sid:1000200; rev:1;)

alert tcp $HOME_NET any -> !$OVERACTIVE !1433 (msg:"ET TROJAN Bancos.DV MSSQL CnC Connection Outbound"; flow:to_server,establish

SNORT.CONF file for every interface
# Setup custom list for overactive alerts
ipvar OVERACTIVE [10.0.0.0/8]

Jeff H

unread,
Mar 23, 2017, 12:12:57 PM3/23/17
to securit...@googlegroups.com
Personally I would avoid trying to disable the rules, adding variables and/or modifying the rules and focus on suppressing via threshold.conf

What do your entry in threshold.conf for this rule look like? I have not run Security Onion in a master/sensor architecture, so I am not sure if this needs to be entered on each sensor individually or if it is entered on the master and then gets pushed out to the sensors. But it probably needs to be in threshold.conf for Sensor 1, interface 2 and Sensor 2, interface 1.

Not sure if this was a typo in your email, but your HOME_NET and EXTERNAL_NET on Sensor 2, interface 1 are both listed as 10.0.0.0/8, I expect this could cause some problems as well, maybe related to this.

It may also help in troubleshooting to identify where your SQL server is on the network, and where the client systems are that are generating the alerts.

Jeff


--
Follow Security Onion on Twitter!
https://twitter.com/securityonion
---
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onion+unsubscribe@googlegroups.com.
To post to this group, send email to security-onion@googlegroups.com.
Visit this group at https://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.

CrashOverride

unread,
Mar 23, 2017, 3:46:08 PM3/23/17
to security-onion
Hey Jeff,
Thanks for the reply,

I can understand the question about Sensor 2 Interface 1, but this is configured this way on purpose as to only monitoring important traffic that is on my internal network. I don’t suspect that this is the issue as the alert is firing repeatedly from this interface.

My effort to threshold the data was just an attempt to see if it would work. The reality is I don’t want to bog down the system with having to digest these alerts since there are so many of them. It is my understanding that thresholding will result in the alert not firing however, the sensor will still have to digest it and then discard it. I would much rather have the system treat it like normal traffic and pass it off as to not bog the system down.

And lastly the SQL server is on the Master server and the clients are spread throughout our network of 40 remote facilities.

I appreciate the help, please let me know if you have any other thoughts.
-Crash

Philip Plantamura

unread,
Mar 23, 2017, 5:12:48 PM3/23/17
to securit...@googlegroups.com
Crash,

Did you confirm the rules are getting disabled? It looks like another
ET rule with sid 2020569 is checking the ET.MSSQL flowbit, which might
prevent the rules that set it from being disabled. Try adding
1:2020569 to disablesid.conf as well, and re-running rule-update.
Confirm the rules are remarked afterwards with the command:

grep ET.MSSQL /etc/nsm/rules/downloaded.rules

Then, distribute to sensors with your standard method, e.g., salt or
rule-update on the sensors.

It's probably just a typo but, just to confirm, the file to modify is
/etc/nsm/pulledpork/disablesid.conf (not disabledsid.conf).

Another option is to use /etc/nsm/pulledpork/modifysid.conf to replace
$EXTERNAL_NET with !$OVERACTIVE on the noisy rules.

Phil
> --
> Follow Security Onion on Twitter!
> https://twitter.com/securityonion
> ---
> You received this message because you are subscribed to the Google Groups "security-onion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
> To post to this group, send email to securit...@googlegroups.com.
Message has been deleted

wubb...@gmail.com

unread,
Mar 24, 2017, 10:14:06 AM3/24/17
to security-onion
I agree adding it the alert ID to disablesid.conf seems to work for me.

If I'm not mistaken when Pull Pork runs to update your rules it will replace the commented out rules with the originals, with exception to /etc/nsm/rules/local.rules. Adding the SID to disablesid.conf will tell the Suricata or Snort not to load those rules.

Here's a link on how to mange rules within SecurityOnion. Add the SIDs /etc/nsm/pulledpork/disablesid.conf, and run "sudo service nsm restart", and you should be good.

https://github.com/Security-Onion-Solutions/security-onion/wiki/ManagingAlerts

wubb...@gmail.com

unread,
Mar 24, 2017, 10:22:33 AM3/24/17
to security-onion
Also, after adding you'll need to run to update the rule set:

sudo rule-update

CrashOverride

unread,
Mar 24, 2017, 2:46:43 PM3/24/17
to security-onion
Again thank you for the replies. Working the with advice provided I have added 1:2020569 to my disablesid.conf and ran grep ET.MSSQL /etc/nsm/rules/downloaded.rules (thanks for the query, by the way).

Here are the results:

alert tcp $HOME_NET any -> $EXTERNAL_NET !1433 (msg:"ET POLICY Outbound MSSQL Connection to Non-Standard Port - Likely Malware"; flow:to_server,established; content:"|12 01 00|"; depth:3; content:"|00 00 00 00 00 00 15 00 06 01 00 1b 00 01 02 00 1c 00|"; distance:1; within:18; content:"|03 00|"; distance:1; within:2; content:"|00 04 ff 08 00 01 55 00 00 00|"; distance:1; within:10; flowbits:set,ET.MSSQL; classtype:bad-unknown; sid:2013409; rev:3;)

alert tcp $HOME_NET any -> $EXTERNAL_NET 1433 (msg:"ET POLICY Outbound MSSQL Connection to Standard port (1433)"; flow:to_server,established; content:"|12 01 00|"; depth:3; content:"|00 00 00 00 00 00 15 00 06 01 00 1b 00 01 02 00 1c 00|"; distance:1; within:18; content:"|03 00|"; distance:1; within:2; content:"|00 04 ff 08 00 01 55 00 00 00|"; distance:1; within:10; flowbits:set,ET.MSSQL; classtype:bad-unknown; sid:2013410; rev:4;)

# alert tcp $HOME_NET any -> $EXTERNAL_NET !1433 (msg:"ET TROJAN Bancos.DV MSSQL CnC Connection Outbound"; flow:to_server,established; flowbits:isset,ET.MSSQL; content:"|49 00 B4 00 4D 00 20 00 54 00 48 00 45 00 20 00 4D 00 41 00 53 00 54 00 45 00 52 00|"; classtype:trojan-activity; sid:2013411; rev:1;)

# alert tcp $EXTERNAL_NET any -> $HOME_NET !1433 (msg:"ET TROJAN Unknown Trojan Downloading PE via MSSQL Connection to Non-Standard Port"; flow:from_server,established; flowbits:isset,ET.MSSQL; content:"MZ"; byte_jump:4,58,relative,little; content:"PE|00 00|"; distance:-64; within:4; reference:md5,754b48c57a00b7c9f0e0640166ac7bb5; classtype:trojan-activity; sid:2020569; rev:1;)

alert tcp $HOME_NET any -> !$OVERACTIVE 1433 (msg:"ET POLICY Outbound MSSQL Connection to Standard port (1433)"; flow:to_server,established; content:"|12 01 00|"; depth:3; content:"|00 00 00 00 00 00 15 00 06 01 00 1b 00 01 02 00 1c 00|"; distance:1; within:18; content:"|03 00|"; distance:1; within:2; content:"|00 04 ff 08 00 01 55 00 00 00|"; distance:1; within:10; flowbits:set,ET.MSSQL; classtype:bad-unknown; sid:1000100; rev:1;)

alert tcp $HOME_NET any -> !$OVERACTIVE !1433 (msg:"ET POLICY Outbound MSSQL Connection to Non-Standard Port - Likely Malware"; flow:to_server,established; content:"|12 01 00|"; depth:3; content:"|00 00 00 00 00 00 15 00 06 01 00 1b 00 01 02 00 1c 00|"; distance:1; within:18; content:"|03 00|"; distance:1; within:2; content:"|00 04 ff 08 00 01 55 00 00 00|"; distance:1; within:10; flowbits:set,ET.MSSQL; classtype:bad-unknown; sid:1000200; rev:1;)

alert tcp $HOME_NET any -> !$OVERACTIVE !1433 (msg:"ET TROJAN Bancos.DV MSSQL CnC Connection Outbound"; flow:to_server,established; flowbits:isset,ET.MSSQL; content:"|49 00 B4 00 4D 00 20 00 54 00 48 00 45 00 20 00 4D 00 41 00 53 00 54 00 45 00 52 00|"; classtype:trojan-activity; sid:1000300; rev:1;)

It appears that the offending rule is still not disabling. Based on other readings I attempted to change the rev or GID number of the offending rule in disablesid.conf.

Here is the latest disablesid.conf

#ET POLICY Outbound MSSQL Connection to Standard port (1443)

4:2013410


#ET POLICY Outbound MSSQL Connection to Non-Standard Port - Likely Malware

3:2013409


#ET TROJAN Bancos.DV MSSQL CnC Connection Outbound
1:2013411

#ET TROJAN Unknown Trojan Downloading PE va MSSQL Connection to Non-Standard Port
1:2020569

No change when I ran grep ET.MSSQL /etc/nsm/rules/downloaded.rules

alert tcp $HOME_NET any -> $EXTERNAL_NET !1433 (msg:"ET POLICY Outbound MSSQL Connection to Non-Standard Port - Likely Malware"; flow:to_server,established; content:"|12 01 00|"; depth:3; content:"|00 00 00 00 00 00 15 00 06 01 00 1b 00 01 02 00 1c 00|"; distance:1; within:18; content:"|03 00|"; distance:1; within:2; content:"|00 04 ff 08 00 01 55 00 00 00|"; distance:1; within:10; flowbits:set,ET.MSSQL; classtype:bad-unknown; sid:2013409; rev:3;)

alert tcp $HOME_NET any -> $EXTERNAL_NET 1433 (msg:"ET POLICY Outbound MSSQL Connection to Standard port (1433)"; flow:to_server,established; content:"|12 01 00|"; depth:3; content:"|00 00 00 00 00 00 15 00 06 01 00 1b 00 01 02 00 1c 00|"; distance:1; within:18; content:"|03 00|"; distance:1; within:2; content:"|00 04 ff 08 00 01 55 00 00 00|"; distance:1; within:10; flowbits:set,ET.MSSQL; classtype:bad-unknown; sid:2013410; rev:4;)

# alert tcp $HOME_NET any -> $EXTERNAL_NET !1433 (msg:"ET TROJAN Bancos.DV MSSQL CnC Connection Outbound"; flow:to_server,established; flowbits:isset,ET.MSSQL; content:"|49 00 B4 00 4D 00 20 00 54 00 48 00 45 00 20 00 4D 00 41 00 53 00 54 00 45 00 52 00|"; classtype:trojan-activity; sid:2013411; rev:1;)

# alert tcp $EXTERNAL_NET any -> $HOME_NET !1433 (msg:"ET TROJAN Unknown Trojan Downloading PE via MSSQL Connection to Non-Standard Port"; flow:from_server,established; flowbits:isset,ET.MSSQL; content:"MZ"; byte_jump:4,58,relative,little; content:"PE|00 00|"; distance:-64; within:4; reference:md5,754b48c57a00b7c9f0e0640166ac7bb5; classtype:trojan-activity; sid:2020569; rev:1;)


alert tcp $HOME_NET any -> !$OVERACTIVE 1433 (msg:"ET POLICY Outbound MSSQL Connection to Standard port (1433)"; flow:to_server,established; content:"|12 01 00|"; depth:3; content:"|00 00 00 00 00 00 15 00 06 01 00 1b 00 01 02 00 1c 00|"; distance:1; within:18; content:"|03 00|"; distance:1; within:2; content:"|00 04 ff 08 00 01 55 00 00 00|"; distance:1; within:10; flowbits:set,ET.MSSQL; classtype:bad-unknown; sid:1000100; rev:1;)

alert tcp $HOME_NET any -> !$OVERACTIVE !1433 (msg:"ET POLICY Outbound MSSQL Connection to Non-Standard Port - Likely Malware"; flow:to_server,established; content:"|12 01 00|"; depth:3; content:"|00 00 00 00 00 00 15 00 06 01 00 1b 00 01 02 00 1c 00|"; distance:1; within:18; content:"|03 00|"; distance:1; within:2; content:"|00 04 ff 08 00 01 55 00 00 00|"; distance:1; within:10; flowbits:set,ET.MSSQL; classtype:bad-unknown; sid:1000200; rev:1;)

alert tcp $HOME_NET any -> !$OVERACTIVE !1433 (msg:"ET TROJAN Bancos.DV MSSQL CnC Connection Outbound"; flow:to_server,established; flowbits:isset,ET.MSSQL; content:"|49 00 B4 00 4D 00 20 00 54 00 48 00 45 00 20 00 4D 00 41 00 53 00 54 00 45 00 52 00|"; classtype:trojan-activity; sid:1000300; rev:1;)

I even tried to modify the SID in the Modifysid.conf with no luck.
2013410 "$EXTERNAL_NET" "!$OVERACTIVE"

Still getting pounded with this ET POLICY Outbound MSSQL Connection to Standard port (1433) alert. I mean thousands upon thousands. This is so frustrating.

Any other thoughts?

CrashOverride

unread,
Mar 24, 2017, 3:32:56 PM3/24/17
to security-onion
--->FIXED<----

Hello all! This issue is now resolved. Thank you for helping me out. I have learned that listening to instructions is important. 😊

I went ahead and pulled out of the changes that I had made and then went back only added the following lines into disablesid.conf and it worked!
1:2013410
1:2013409
1:2013411
1:2020569

Whew!!! Now I must figure out how to configure my local rules to allow these to fire but only on true external traffic. Thanks again to everyone that helped me out. You guys rock out loud!

Philip Plantamura

unread,
Mar 24, 2017, 4:46:29 PM3/24/17
to securit...@googlegroups.com
Crash,
As an experiment, you could try something like:

1. Set the variable SQL_SERVERS in /etc/nsm/sensorname-interface/snort.conf.
ipvar SQL_SERVERS [192.168.14.33] #or whatever your SQL Server IP is.

2. Remark the four lines in disablesid.conf.
#1:2013410
#1:2013409
#1:2013411
#1:2020569

3. Add the following line to modifysid.conf:
2013410 "\$EXTERNAL_NET" "!\$SQL_SERVERS"

4. Run rule-update.
sudo rule-update

Phil

CrashOverride

unread,
Mar 27, 2017, 10:07:02 AM3/27/17
to security-onion
That is a great idea Phil! Let me give it a shot and I’ll let you know what the results are.

CrashOverride

unread,
Mar 30, 2017, 10:29:59 AM3/30/17
to security-onion
Hey there folks, I did go back and try Phil's idea. Turns out there is already a IPVAR for SQL servers. When I added my SQL servers to this variable the alerts stopped without the need to modify anything. So here is what I have learned, it is worth it to go ahead and define the SQL servers if you are monitoring internally. I seriously want to thank everyone involved for helping me get this resolved. You guys totally rock!
Talk you soon I'm sure,
-CrashOverride
Reply all
Reply to author
Forward
0 new messages