Packets going to something called "Omegle" - Pedophile ring?

Just curious can Wyze employee Private Message to Travega?? for the request.

1 Like

As asked for the clarification because your previous post mentioned US-only traffic in terms of video streaming; your post implied that even v2 cams send registration info to China.

Sorry if that made you confused. :slight_smile: Hope my answer above clarified it. Thanks for double checking!

1 Like

…so, troll? Outside agitator? Consarn you, @travega!  theolds_1

Apologies, the case is on going. Nothing conclusive so far so I can’t comment further at this point.

That “proxy” method is a hack. it’s not proper packet analysis as it 1) it only works with changes you have to make on the 3rd party tool (like set a proxy machine/port) 1) only works with http 2) only works with traffic you can proxy. (for example UDP packets where listed in the traffic dentified which fiddler cannot capture) a proper packet analysis tool is needed

Yep it sure is. Which is why I clearly stated that Fiddler was ONE of the tools I use, not the only tool I use. Sheesh everyone zeroed in on Fiddler and ignored every other tool I use. So go ahead let’s get it over with, go down my list and tell me all the reasons each tool I or others, use is wrong, incorrect, dumb, not right, stupid, inefficient, worst tool since whatever.

When you are investigating a network issue it’s common to look at different aspects, parts, pieces, components, etc with a variety of tools. Not all tools are used in all cases, or even appropriate in all cases. My answer was addressed at an incorrect statement not saying the answer was applicable in this situation.

Well well well… Since @travega refuses to provide the requested information, we should [Mod Edit] lock this thread, and move on with life.

[Mod Edit] succeeded in getting everyone riled up…

MOD NOTE: Post edited to conform to the Community Guidelines.

Sometimes We Disagree

Sometimes we will disagree on topics. You may even think that the other person is outright wrong! That’s just part of being human talking to other humans. But when you respond, remember to criticize ideas, not people . Please avoid:

  • Name-calling
  • Ad hominem attacks (personal attacks instead of discussing content of a post)
  • Responding to a post’s tone instead of its actual content
  • Knee-jerk contradiction

Always Be Civil
Nothing sabotages a healthy conversation like rudeness:

  • Be civil. Don’t post anything that a reasonable person would consider offensive, abusive,

You looked up the wrong globalaxs. GlobalAXS is a former name of M247 - a major Internet services company in UK. See this page: http://www.as9009.net/ and then this https://m247.com/ You’ll still the name ‘globalaxs’ all over the 'net referring to what is now M247.

That makes a lot more sense.

Sigh, and I read the whole thread. Should have known it was a wild rabbit hole the moment I saw “high fidelity” network. Actually, I did know. Guess I was just bored. :slight_smile:

6 Likes

This is like black-boxing images or beeping-out audio. I’m sure I’m imagining more provocative stuff than mateo orginaly “said.” :wink:

2 Likes

Yeah, apparently suggesting that trolls be removed is worse for the “community” than the trolls themselves…

Peace out…

1 Like

Apologies if this is causing frustration. I have no intention to troll anyone here. I’m doing the best I can to understand the situation and hoping it’s nothing for my kids’ sake. Please feel free to ignore this thread if it’s irritating you but do please stay if you feel you can add value or learn from this situation.

What I know so far is that Ubiquiti does not store the IP addresses or timestamps alongside DPI logs. As @Rockslice mentioned DPI classification rules are stored in a proprietary format on the USG. I don’t know where the DPI logs themselves are stored. I dumped a bunch of log files but I see no matching mac addresses or any reference to the “Omegle” cat_id (128). If anyone know where they are please share.

Ubiquiti claim that it’s very unlikely traffic in a vlan can get erroneously attributed to client in other vlans. Not to say it’s impossible but they have never seen it happen before.

I have run tcpdumps for tcp and udp traffic from the USG and see no reference to any IP addresses related to any services other than Wowrack, OVH, globalaxs and 10.123.102.12 (??) - see short snapshot attached. So, from what I can assume is that suspect traffic has stopped; is buried in the reems of logs currently being analysed; has been erroneously labelled and erroneously attributed by Unifi USG; or the packets sent configs to numerous IM services along with a bunch of decoys for “unknown” services to intercept packets from the cams…??? Don’t know how I will conclude any of these possibilities at this point but hoping between here and others I have helping out I can get something definitive.

I’ve attached screenies of the Unifi DPI dashboard associated with the macs of the cams. And also screenies of the cam device info screen from the Wyze app with corresponding mac addresses for cross reference sake - risky sharing mac addresses but likely I won’t use the cams again.

https://drive.google.com/file/d/18YipxCBOt--Blo08PbKD05ZJxItKnWpP/view
https://drive.google.com/file/d/1iz-9jhAaIhcpb-99PCuQSbLVVvr6pfuF/view?usp=sharing

2 Likes

Sigh. There is nothing in what you’ve provided that indicates traffic went anywhere untoward. Nada. All you have is a purported “deep packet inspection” record from your MAC address, but that’s just your vendor trying to classify what’s IN the packet, not where it’s going! (“actual data contents in the IP packet, in some cases even encrypted traffic”)

It has simply misclassified them. It doesn’t have much to go on and is making dumb pattern matching guesses against whatever is in a little packet, based on what it thinks related application traffic looks like. It’s a wild guess, a shot in the dark, a pretense of accuracy. It’s a false alarm. Don’t worry about it. :slight_smile:

" Starting from the v1.7.0 EdgeOS firmware release, Deep Packet Inspection (DPI) and Traffic Analysis are supported on EdgeRouters. Compared to traditional packet analysis tools which only give a glimpse of packet information such as port number and IP address, DPI is used to analyze and report the actual data contents in the IP packet, in some cases even encrypted traffic. When enabled, the DPI engine drills down to the core of the packet, collecting and reporting information at the Application-layer, such as traffic volume of a particular application used by the host."

2 Likes

As I stated way back early in this thread - not an issue.

@Customer provides another great and succinct analysis.

Admittedly, I was bored and so downloaded the mp4 … and the packet capture to analyze in Wireshark [1], [3].

From the video (the original screenshot did not show), we can see the packets for a specific MAC address … and it ONLY shows up to about 45 records.

Here’s the hilarious part - it shows 4-5-6 “analyzed” packets of:
“instant messaging”
… all of those packets ONE AFTER THE OTHER, but from different “sources” [2]

I suspect the “Wyze-side analysis” is taking a long time because they have lawyers involved, burning through cash.

The OP is one of those who has what they believe to have an “advanced hardware and software” product, but doesn’t have the analytics to “make sense of the data”.

Someone remind me to not buy this “high fidelity home network” product : )
.
.
[1] There are those who think Wireshark is a dinosaur of some sort, even though we network engineers use it all the time

[2]
Screenshot_20200530_114109

[3]
IP Address 37.120.216.214
inetnum: 37.120.216.0 - 37.120.216.255
netname: M247-LTD-NewYork
descr: M247 LTD New York Infrastructure
country: US
geoloc: 40.7175544 -74.0083725
admin-c: NYC-RIPE
tech-c: NYC-RIPE
status: ASSIGNED PA
mnt-by: SDAT-MNT
mnt-routes: GLOBALAXS-MNT
mnt-domains: GLOBALAXS-MNTvvv

IP Address 209.90.225.252
NetRange: 209.90.224.0 - 209.90.239.255
CIDR: 209.90.224.0/20
NetName: WORLDLINK-2
NetHandle: NET-209-90-224-0-1
Parent: NET209 (NET-209-0-0-0-0)
NetType: Direct Allocation
OriginAS: AS27323
Organization: Wowrack.com (WOWTEC-1)
RegDate: 2006-01-20
Updated: 2015-11-09
Ref: https://rdap.arin.net/registry/ip/209.90.224.0
OrgName: Wowrack.com
OrgId: WOWTEC-1

IP Address 89.100.154.228
inetnum: 89.100.142.0 - 89.100.155.255
netname: VM-IE
descr: Residential DHCP
descr: Virgin Media Ireland
country: IE
admin-c: DH2529-RIPE
tech-c: DH2529-RIPE
status: ASSIGNED PA
mnt-by: VM-IE-MNT
created: 2017-10-27T09:34:28Z
last-modified: 2017-10-27T09:34:28Z
source: RIPE
person: Denis Hanley
address: UPC Ireland
address: LEDP
address: Enterprise Development Park
address: Roxboro Road
address: Limerick

IP Address 10.123.102.12
NetRange: 10.0.0.0 - 10.255.255.255
CIDR: 10.0.0.0/8
NetName: PRIVATE-ADDRESS-ABLK-RFC1918-IANA-RESERVED
NetHandle: NET-10-0-0-0-1
Parent: ()
NetType: IANA Special Use
Organization: Internet Assigned Numbers Authority (IANA)
Updated: 2013-08-30
Comment: These addresses are in use by many millions of independently

1 Like

Nice add, @myswtest . Is it persuasive to you other geeks (used fondly)? I don’t have the chops to judge.

What’s your current take:

  • Case closed, not an issue.
  • Yet to be determined, shelter-in-place.

0 voters

I have read the entire thread:

  • Yes
  • No

0 voters

The tip off to me was calling a social network a “pedophile” ring. Pedo’s are well known to ALL social networks. Facebook and Twitter chief among them. There is more child porn on Facebook than anywhere else I am aware of.

So to specifically say what they did with no evidence of sexual traffic or intent in this situation was done to attract attention and ONLY to attract attention.

An “unnamed” insurance company was unwittingly hosting terabytes of underage porn on their servers and cooperated with investigators when it was discovered. An creep of a network engineer was the culprit. It happens more than most people realize.

2 Likes