Security Center - SID 1:16540

Solved
JessIT1
Building a reputation

Security Center - SID 1:16540

Getting a lot of these alerts from our main office's domain controller server and file server to a remote network.

It's causing their mapped network drive back to our office not to connect.

 

Microsoft Windows SMB2 client NetBufferList NULL entry remote code execution attempt

 

security center2.JPG

 

anyone else seeing this...

1 Accepted Solution
GiacomoS
Meraki Employee
Meraki Employee

Hey everyone,

 

Another follow up here, we have now rectified the categorisation and you can now safely remove the rule from the whitelist, if you have taken the step of whitelisting. 

 

Please keep in mind that it can take up to an hour for the changes to apply to the SNORT configuration.

 

Many thanks!

Giac

Please keep in mind that what I post here is my personal knowledge and opinion. Don't take anything I say for the Holy Grail, but try and see!
Appreciate who helps and be respectful of every opinion and every solution offered.
Share the love, especially the Meraki one!

View solution in original post

19 Replies 19
alemabrahao
Kind of a big deal
Kind of a big deal

 I would suggest you to contact the Support.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
JessIT1
Building a reputation

ok, yes i did open a case with support. I just know in the past some alerts were false positives, just wanted to see if anyone else is getting same alert.  thanks

JessIT1
Building a reputation

The Meraki logging the alerts is a MX67W running - 18.211.2

JessIT1
Building a reputation

Both source servers in the alerts are running Microsoft Windows Server 2022 Standard, so not sure if the snort explanation applies...

 

The SMB client in Microsoft Windows Server 2008 R2 and Windows 7 does not properly handle (1) SMBv1 and (2) SMBv2 response packets, which allows remote SMB servers and man-in-the-middle attackers to execute arbitrary code via a crafted packet that causes the client to read the entirety of the response, and then improperly interact with the Winsock Kernel (WSK), aka "SMB Client Message Size Vulnerability."

BJF
Conversationalist

Had the same issue this morning.  We have about 34 sites some which have no local servers or domain controllers.  So users were having issues both logging into computers and when logged in being able to access file shares maintained over tunneled connections.   Believe this was some IDS rule change which sparked traffic being classified this am.

JessIT1
Building a reputation

OK, thank you for confirming that. I do have a ticket open with Meraki support, I don’t want to whitelist these blocked alerts until I hear back from them but sounds like it’s a false positive..?

RaphaelL
Kind of a big deal
Kind of a big deal

Same here.  8420 pages of 100logs across my org.  Luckly for us we are running in IDS mode. 

JessIT1
Building a reputation

Ok. Meaning you are running in Prevention mode like we are where these actions are being blocked? Like I said in my previous reply to someone, this is still causing issues for us I just don’t want to whitelist until I know for sure it’s safe to do so. Thanks 

RaphaelL
Kind of a big deal
Kind of a big deal

We are in IDS mode ( Detection with the rule set Security ) so everything is logged and not blocked.  But we do see those logs. 

 

In your case you are in IPS mode ( Prevention ) so blocking stuff classified in your configured ruleset.  It looks like a false positive, but only Meraki / Snort will be able to confirm.

BJF
Conversationalist

Correct we were in prevention mode also which created the issues.  Yes, I've whitelisted the rule for time-being as the traffic is legit from the clients to servers.  It's not the first time we've had to do things like this to get production back up.

JessIT1
Building a reputation

I may have to allow for now too, Remote site needs access to our mapped drive.

ndjake
Conversationalist

Looks like we're seeing the same alerts in our org. I've just opened a ticket with support, but curious to know if anyone has gotten any feedback from their own support tickets. Luckily, this is at a small branch office so it's not impacting us too much at this point.

BJF
Conversationalist

No feedback from support at this point.  The CVE is older so I'm fairly confident it's a false-positive at this time.

JessIT1
Building a reputation

Response I got:  

Thank you for contacting Cisco Meraki support.
There is an issue with the new SNORT update and as a workaround for now, please whitelist the rule.

We are working to get this fixed as soon as possible. Thank you for your patience and co-operation.

mmenor-tig
New here

EDIT: Nevermind, I found it!

 

How do you remove it from the whitelist after Meraki fixes the rule?

JessIT1
Building a reputation

Go back into - Threat Protection / Intrusion Detection & Prevention / click X under Actions for the rule / save changes

GiacomoS
Meraki Employee
Meraki Employee

Hey Community,

 

Just wanted to update everyone here that this is an unfortunate false positive. We are working internally to ensure this is rectified as quickly as possible, but guidance at the moment is to whitelist the rule temporarily. 

 

We'll circle back once we have confirmation of a permanent fix being rolled out.

 

Many thanks!

Giac

 

[MOD NOTE: Marking this post as the "Solution" for visibility, even though the issue is not resolved.]

Please keep in mind that what I post here is my personal knowledge and opinion. Don't take anything I say for the Holy Grail, but try and see!
Appreciate who helps and be respectful of every opinion and every solution offered.
Share the love, especially the Meraki one!
GiacomoS
Meraki Employee
Meraki Employee

Hey everyone,

 

Another follow up here, we have now rectified the categorisation and you can now safely remove the rule from the whitelist, if you have taken the step of whitelisting. 

 

Please keep in mind that it can take up to an hour for the changes to apply to the SNORT configuration.

 

Many thanks!

Giac

Please keep in mind that what I post here is my personal knowledge and opinion. Don't take anything I say for the Holy Grail, but try and see!
Appreciate who helps and be respectful of every opinion and every solution offered.
Share the love, especially the Meraki one!
rweaver
Conversationalist

Thank you for providing the resolution status on this.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels