Cyclic series of blocked connections hanging network

[Steven_Prester]

I'm having an issue with a cyclic series of blocked connections. I'm not sure this is the right place to ask this question, or if I should even ask.  Since I'm not industry-experienced yet I use a licensed GAIA appliance on my home network without a support contract, I've never bothered anyone at this level.  However I'm at a loss as to what's happening on my network, and without some understanding, I'm not going to be able to resolve the issue. If there is a better place to ask this question please point me there.  If I'm out of line, say so.

I'm not necessarily asking to have the problem solved for me, but to help me understand the dynamic so I can solve it. This started happening two evenings ago where the firewall is blocking the traffic shown in the attached screenshots. At times this gets so intense it functions like a DOS attack. 

The first pic is of the blocked connections, the second is active connections, and the third is active devices on the network. 

The 100.72.0.2 is attempting to contact an IANA Root Server at 224.0.0.18, and is on the same subnet as my WAN IP (100.72.0.85).

My LAN gateway is 192.168.2.0, and 192.168.2.4 is a WD MyCloud EX2 (installed a Jan/2019 FW update yesterday after reading about vulnerabilities - nothing changed) that is using NetBIOS and getting accepted at 192.168.2.255. It's also making UDP connections to an external IP address that ICANN returns null when I run a reverse IP lookup.

The 0.0.0.0 trying to connect to 255.255.255.255 simply baffles me.

This 730 NGTP WiFi appliance will not operate dual-band, therefore I have my old SG640 bridged to its LAN on 192.168.2.1 so that I can utilize 2.4 MHz WiFi. Firewall and WAN are turned off on the SG640.

[PhoneBoy · Accepted solution]

First, the 730 is an SMB and SMP‌ product, so this post should go in the appropriate space.

Second, there's nothing in these logs that is particularly unusual.

Maybe the volume of these packets is creating an issue.

Creating explicit rules that don't log the traffic below might help.

224.0.0.18 is a multicast address associated with Virtual Router Redundancy Protocol.

Your ISP is likely using it to provide redundancy for the default route.

These are not directed at you, but your 730 is receiving them.

You can safely ignore/not log these.

If your WD MyCloud EX2 supports SMB/Windows filesharing, then seeing traffic sent to the broadcast address (.255) from it is perfectly normal and not worth logging.

As for your WD MyCloud EX2 reaching out and touching the Internet, you should contact them to find out why it's doing it.

0.0.0.0 contacting 255.255.255.255 is the first packet in a DHCP exchange.

Most likely, you're seeing traffic from everyone else who shares the same segment as you on your ISP.

These packets can be safely ignored (and not logged).

[Steven_Prester]

Dameon,

I appreciate your reply and I will follow your directives. I don’t care to use the MyCloud except for local storage so I will see what I have to do to cut its access.

I don’t frequently check my logs but over the past couple weeks I’ve had interruptions in service, so when I looked I recognized these were not previously being logged.

That these requests are normal, or at least acceptable, and are now being logged, tells me something probably changed in a FW update.

I’ve been on Allo Comm fiber for the past year and have been forced to reboot the router maybe twice. However, I’ve recently had issues with WiFi (most of my connections are copper) dropping out, and that’s required a reboot of the 720.

I’ll se if I can relocate this post and if not I’ll remove it. Thank you.

[PhoneBoy]

I moved the post already, no action on your part required. 

WiFi "dropping out" is definitely a different issue than your initial description of the issue implied.

That, in theory, would not be caused by externally received traffic.

FWIW the current version of firmware is R77.20.85 (990172731), though I believe a new build is planned shortly.

If you don't have a support agreement in place, you won't be able to download from our support site, though the device should eventually be offered the latest firmware in the WebUI.

[Steven_Prester]

Yes, I just seen that you moved it. No, I wasn’t implying I thought the WiFi was related to what’s happening in the logs. I guess I was just explaining what got me poking around.

I’ve had 3 licensed, CP SMB appliances since 2011 and I’m now in the 2nd year of a 3-yr license on this 730. I guess what I mean is I have blade subscriptions, but no support agreement.

Honestly, over the past 8 years I’ve had no significant issues, peace of mind and a clean network. I would never go back to a consumer-level routing device.

[PhoneBoy]

If you bought a 3 year blade subscription for the SMB appliances, you also have a support contact.

That's what your UserCenter account says you have.

This means you should be able to access UserCenter and download the latest firmware.

See: R77.20.85 for Small and Medium Business Appliances 

[Steven_Prester]

I’m on R77.20.81 (990172541). I’m assuming this will auto update sometime soon.

[Steven_Prester]

I have successfully quelled everything but the 0.0.0.0 to 255.255.255.255.

My rules are in the 2nd screenshot. Any thought on why I’m not silencing this request?

[PhoneBoy]

Change the source in Rule 5 to Any.

[Steven_Prester]

That worked. It’s now interesting to coherently visualize the remaining traffic.

What qualifies any given “Accept“ traffic to get logged? Do I want to be logging traffic such as a Dropbox data sync between clients? Where should I draw the line for logging presumably legitimate internal network traffic on a private network?

When the security log is crammed with legit or extraneous traffic it seems to me it renders the log rather useless for looking at the real-time health of the network. I realize I can search the log but that still isn’t the same as seeing real-time patterns of traffic that may be causing issues.

I’m also wondering what a balanced approach would be as I begin to deploy a significant number of custom IoT devices.

I’m assuming Cyber Security Evangelism is concerned with the health of the internet as IoT devices proliferate in the hands of the Cyber laity. I’m retired from Healthcare IT consulting (software) where I was never responsible for the network, yet I know enough to have a healthy respect for cyber security, and it genuinely concerns me there can become so many unsecured nooks and crannies.

If this question is out of the scope of our discussion, can you point me to a place where it would be in scope?

[PhoneBoy]

Certainly all of this stuff is "in scope."

Maybe not in this space, but it's related to this discussion, so it's fine.

If you're troubleshooting issues, logging can be your friend

That said, too much logging makes it harder to see what's actually going on.

Historically, I've "accepted and not logged" things like:

• SMB traffic to the LAN broadcast segment
• DHCP-related traffic
• VRRP-related traffic

But to make a general statement that everyone shouldn't log these things ignores many factors that may be relevant in some circumstances.

That said, for an end-user consumer, that advice is probably reasonable.

In your network, you might find other things that are "noise" that can be safely not logged.

Generally speaking, the few IoT devices I do have are mostly on a seperate WiFi network from my end users.

Chromecasts and other "streaming media" devices are a little more difficult to do that with since they need another device from the local network to say what streams to it. 

I would heavily log what these devices do at first and turn the logging down as you are comfortable with what they're doing.

[Steven_Prester]

Again, just what I was looking for.

Much appreciated.

Get Outlook for iOS<https://aka.ms/o0ukef>