I've been monitoring the "Threat Events" filter on the LEM (v6.3) and am trying to figure out the what/why/how of what I'm seeing. Its supposedly logging IP traffic detected by our Meraki access points from random external source IPs to other random external destination IPs, none of which are related to our network. These source and destination IPs are different each time. If anyone could take a look at these screenshots below and has any idea what might be going on, please let me know! Thanks

134.63.89.179 is owned by an ISP called Tektronix in Beaverton, Oregon. This seems to match an entry on the current EmergingThreats black list: 134.62.0.0/15 (as of Jan 27, 2017) That mask covers from 134.62.0.0 to 134.63.255.255, so it's possible that the blacklist is over-broad. (Or maybe the Earth Defense Alliance is blacklisted [Bonus points for getting the reference])

107.113.28.33 is owned by AT&T Wireless in "United States." I don't see that range on the blacklist.

It's hard to say without more information, but it appears that you have an AT&T customer on your wi-fi hitting a potentially bad IP.

Thanks curtisi. That one example kind of makes sense, but most of them don't. For example, the source 101.193.65.161 is Asia Pacific Network with destination 201.94.92.90 which is Uruguay. It doesn't make sense as to why our Meraki wireless access points would be logging such random traffic. There's also no consistency to the logs either, no repeating IP addresses whatsoever.

I'm going to open a ticket with Meraki about this since I'm really scratching my head here.

Perhaps the Meraki is parsing packets destined for its own MAC address at layer 2, but at layer 3 the IP's are intentionally wrong/changed? Not sure how else the packet would make it to the Meraki interface.

The link below has a little info about Threat Intelligence Feed, and it also has 2 links at the bottom to more details on TIF. It's a daily updated list of known bad public IP's and the video shows how to use the built-in monitor filter to see more info on recent incidents, such as the public IP that was blocked. Since this info is updated daily and volatile, it may not be feasible to track down why each IP was blocked, but it may be a good idea to cross reference the internal IP's on your network that were affected and make sure you don't have any open tickets internally that might indicate a need to quickly remove that node from your network!

Actions

More Like This

Retrieving data ...

SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 130,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process. Learn more today by joining.