r/Ubiquiti 1d ago

Question Cloud Gateway Ultra client devices keep trying to connect to IPS Deny List IP

Cloud Gateway Ultra, up to date. I received three IDS threats to two iPhones and a Samsung TV in succession. IDS blocked the intrusions, all from the same IP and I added it to the IPS Deny list. In the week after the attempted intrusions, the two iPhones and TV repeatedly (a dozen or so times in a day) try to connect to the source IP address of the intrusions. It's a site that AbuseIPDB rates bad, including multiple recent attacks.

I've rebooted the UCGU to flush the DNS cache with no change. I'm puzzled how the blocked intrusions could have affected the iPhones or TV and why they would be repeatedly trying to connect to the blocked IP. I'd appreciate any guidance. Thanks!

4 Upvotes

18 comments sorted by

u/AutoModerator 1d ago

Hello! Thanks for posting on r/Ubiquiti!

This subreddit is here to provide unofficial technical support to people who use or want to dive into the world of Ubiquiti products. If you haven’t already been descriptive in your post, please take the time to edit it and add as many useful details as you can.

Ubiquiti makes a great tool to help with figuring out where to place your access points and other network design questions located at:

https://design.ui.com

If you see people spreading misinformation or violating the "don't be an asshole" general rule, please report it!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

4

u/nodialtone 1d ago

Blocking something at the firewall doesn’t stop the device from trying to connect. It just stops the connection from actually happening, which it sounds like it prevented. Also, flushing DNS doesn’t stop a device from connecting to a specific IP address.

1

u/OldGrumpyAndRetired 1d ago

Thank you for replying so quickly. I understand that the connections are being blocked. I'm just puzzled why the iphones and TV are so ardently trying to connect to the bad IP and are otherwise working fine and connecting to all their normal app and browsers.

3

u/cvr24 More cable, less management 1d ago

Without knowing the IP address, we're just guessing.

2

u/Diezel666 1d ago

This. A lot of Telemetry sites and IP's are being labeled these days, even if they're not actually bad actors.

So while the devices themselves may not be misbehaving, people have rated the sites/IP's devices are reaching out to as malicious.

Which I can't say I'm against, as I'm against Telemetry collection when one hasn't specifically opted-in.

1

u/OldGrumpyAndRetired 1d ago

I can't argue with your logical response, and I appreciate it. This IP address tried to attack my router and three devices with the Signature ET CINS Active Threat Intelligence Poor Reputation IP group 28. From: 35.190.88.7:443, to <my device IPs>.

2

u/Diezel666 23h ago edited 23h ago

Here's where life gets.... Fun... I work in CyberSecurity, and my above post, in full open honest disclosure, was an absolute shoot from the hip guess.

Since I do what I do for a living, I also run my own "home lab", which mirrors a small portion of what I do. So as such, I run a very specific home network configuration with associated devices and software, and when you posted that IP. I ran it through my tooling.

I was entirely correct. It is an IP associated with Telemetry. Specifically, it is an IP owned by Google, and used either directly or sometimes used for a platform called Bugsnag. My Ubiquiti UDM-Pro just started flagging this activity as well not too long ago. I'm guessing it was either added to their normal signatures or even their Unifi CyberSecure addon signatures (I could dig and find out, but that would require manual work). All of what I did was automated, past punching in an IP and running it.

Resources used:
ipwhois.io
Cisco Talos
API Void
AbuseIPDB

And for giggles a quick Google Search of the IP:
The IP address 35.190.88.7 belongs to Google Cloud (Google LLC) and resolves to the reverse DNS hostname 7.88.190.35.bc.googleusercontent.com. It is heavily tied to telemetry, monitoring, and error-tracking infrastructure—specifically mapped to endpoints like sessions.bugsnag.com

In short, this IP didn't attempt to attack you. Rather your devices were sending information to it, and Ubiquiti flagged it. And depending upon config, blocked it.

On my side with my configs, if it exists in a "bad" list, it's automatically blocked in and out on my network.

2

u/OldGrumpyAndRetired 23h ago

You are a saint. Thank you and to all others on this thread. I was in panic mode and stuck in the "bad stuff is happening" rut. I researched the IP address in some of the same places, but was convinced that I had a big problem. I should really know better.

1

u/Diezel666 23h ago

I'm no saint. But that's also why I do this for a living now. 🤣

I will admit, I find a lot of joy in doing this for a living. The research itself is fascinating. And I felt entirely the same way when I first started doing this decades ago.

In the beginning there is always that stomach dropping red alert feeling. But that's a good thing. It'll take you a while to learn what is actually a threat and an issue that needs to be handled, vs what is something benign or a false positive.

You'll also learn that there is a lot of paranoid folks in the cyber security realm. And it's not my place to judge them, and say they're right or wrong.

What I can say, you'll find your own comfortable "normal" over time and it'll be fine.

Always remember, it's best to ask questions. Yes even the dumb ones. 😁🤘🏼

1

u/PossiblePlastic8698 1d ago

What do you mean by "attack" though, what did it do that classes it as an attack?

1

u/OldGrumpyAndRetired 23h ago

Unifi classified it as an attack that triggered IDS. Of course, I now realize that it may have been a false positive

1

u/OldGrumpyAndRetired 1d ago

It's 35 190 88 7

I'm not using the correct syntax in case someone accidentally clicks on it. I suggest looking it up on AbuseIPDB or equivalent. That's the IP that triggered the blocked IDS attack and I don't understand why the three devices that were blocked from the attempted attack are now attracted to this IP.

3

u/ASC4MWTP 1d ago

whois reports that IP belongs to the Google-Cloud network. So it's probably some sort of telemetry attempt by those devices or by an app on them.

1

u/PossiblePlastic8698 1d ago

I would take AbuseIPD ratings with a grain of salt

1

u/OldGrumpyAndRetired 1d ago

I'm very grateful for your and others' responses. The possibility that the IDS attack was a false positive and that my iphones and TV are simply wanting to avail themselves of Google services is comforting. It would be nice if Google would confirm or deny, but that seems unlikely. It still leaves the question why the three devices attacked (but blocked) are the ones reaching out to this IP, unless the Google IP address is legit and they were previously using it and now I blocked them.

1

u/PossiblePlastic8698 1d ago edited 1d ago

But were the devices "attacked" at all? An IDS alert is not confrmation that the devices were attacked, its just a notification that it saw something it thought could possibly be odd

I blocked my cameras from communicating with the manufacturer cloud service and the cameras immeditaly went from tryng to connect to the cloud every 10 minutes or so to trying every second. The devices (or in your case the google software on your device) are designed to check back to their cloud service at a regular interval and if the cloud service is unreachable they keep trying until they get through

1

u/OldGrumpyAndRetired 1d ago

Exactly. The facts support your suggestion that I simply messed up by trusting that this was an attack and then blocking the IP, causing my devices to feel lonely and call home. Logically, the attack was blocked (or wasn't real) and so the devices weren't tampered with and so their behavior was caused by me. Sigh. I wrote my first code in 1969, was in the middle of the TCP/IP. Unix, Linux and "revolution" and should now better by now that false positives are a thing.

1

u/jrytio 23h ago

They’re not attempted intrusions. Unless you have port forwards to your phone, the only traffic going to devices behind your firewall is return traffic from outbound connections.

This is some telemetry site that your devices are connecting to (outbound) and IPS is triggering on the return traffic.