So why is Netflix hitting me with Dradis?
-
@johnpoz said in So why is Netflix hitting me with Dradis?:
Do you think my devices where actually on when I did those sniffs? They were off - or like most such devices these days standby, power save - not actually "off"
You are for sure are not the first person to come screaming the sky is falling the first time they see something they do not understand and first thing they jump to is oh my gawd - they are doing something bad. While I am not a fan of hard coded DNS,
I know they are sleeping not actually off. Still, see no reason for Dradis to be considered a normal DNS call, hard coded or not, right?
No I am not a bot, thank you very much. I like how you accuse me of being a person saying the sky is falling and then next post agree I'm a bot.... anyways, back on topic.
Nobody is making this a global conspiracy. I don't care what rule or what DNS. The question is still open, why is ANYTHING on my netowrk pinging Dradis from ANYONE? Indeed just trying to learn and I think anything involving a penetration tester is a good question.
Updates don't come from the Dradis server. The problem here is not 8.8.8.8, it's the Dradis call followed by other packets that triggered shellcode rules, then stopped (suspicious for an automated service, right?) only after I started blocking. I have year(s) of data on these devices and have not seen them do anything like this.
I also have an update. My Lubuntu laptop triggered one of the shellcode rules (1:649, 1:650. or 1:12798, on vacation but I think it was 12798). This was one of, if not the last one (shellcode) before a few days of quiet (as of Saturday, no clue since, vacation). This did not correspond to an update. I will confirm the exact details, and whether they have restarted, later.
-
@ssullivan556 said in So why is Netflix hitting me with Dradis?:
No I am not a bot, thank yo
The exchange John and I had about a bot was regarding a now-deleted comment made by what seemed like a spam poster. At no point were we referring to you as a bot or an LLM or anything like that.
But since I pushed back on him a little bit, I now feel a little obligated to do the same to you—if only in the spirit of fairness:
He is quite right that you need to take what you're seeing with an extremely large dose of skepticism.
There is lots to be said about publically available (as opposed to custom written) IDS/IPS rulesets, like the Snort rules or the Emerging Threats rules. They are very, very prone to false positives because they are, by their very nature, designed to identify extremely surreptitious activity. They 'hit' on legitimate traffic many, many times over the number of times they identify actually suspicious network activity.
IDS/IPS is about as far from 'set it and forget it' as network security tools go. So-called 'threat hunters' or cybersecurity analysts or whatever they're called now get paid to spend their entire days fine-tooth combing large enterprise networks for needle-in-a-haystack packets, and come up with literally nothing of any actual, real concern the vast majority of the time. It's not that they don't find anything suspicious per se. But upon more careful inspection beyond what IDS/IPS rules can identify in the literal bits of packet streams, it's true that nearly 9.9 times out of there's no actual network 'intrusion.'
The rules that 'hit' in your OP are not necessarily indicative of suspicious activity (if not not even likely).
The PROTOCOL-DNS rule seems to be looking for packet streams of DNS answers containing hostnames of a certain length—nothing to do with the actual domain being queried itself (for which pfBlockerNG is a better tool anyway, and which you should use to block that Netflix domain, or, even better, a regex block for the string "dradis"). Only the actual text of the rule could confirm what it's 'looking' for.
And the INDICATOR-SHELLCODE rule—since this post is already quite long, I'll simply say I agree with John that there's an all-but-certain likelihood that those are false positives.
The most important part about using IDS/IPS is truly understanding why a rule 'hits' in the first place. Going further, the goal might even be to start writing your own custom rules, based on your own fundings. Sometimes legitimate packet streams contain what are otherwise legitimate 'indicators of compromise' (i.e., a false positive). And things can obviously go the other way too, and malicious activity is missed even by well-tailored custom rules.
@ssullivan556 said in So why is Netflix hitting me with Dradis?:
Indeed just trying to learn
This is the best reason I can think of to be trying to deploy IDS/IPS on a home network.
-
You must also realize that some privacy rights that we have as Americans are not awarded to citizens of other nations. Again a lot of devices come from nations where such actions are not seen as abusive. CCPA and GDPR are non existent in other countries. Snort is very complex and many smart tv systems auto update quite often. TP-Link is another example of a company that creates code within products that by our standards seems invasive. Zosi security products for camera systems were also sending data to a cloud system in china, it was simply a data sovernity issue. Just block your concerns or get a non smart TV.
-
@JonathanLee It looks like it's the Neflix app itself triggering these rules, even though "dradis" is in the address those are known Netflix addresses. Netflix does send traffic for things like tracking, network condition checks, preloading previews etc at times even if you're not using the app. Does not look like it's anything malicious however.
-
@aivxtla another app that does scans like that is Xbox games my sons Roblox and others before they connect do a huge port scan all the time
-
@tinfoilmatt said in So why is Netflix hitting me with Dradis?:
@ssullivan556 said in So why is Netflix hitting me with Dradis?:
No I am not a bot, thank yo
The exchange John and I had about a bot was regarding a now-deleted comment made by what seemed like a spam poster. At no point were we referring to you as a bot or an LLM or anything like that.
But since I pushed back on him a little bit, I now feel a little obligated to do the same to you—if only in the spirit of fairness:
He is quite right that you need to take what you're seeing with an extremely large dose of skepticism.
There is lots to be said about publically available (as opposed to custom written) IDS/IPS rulesets, like the Snort rules or the Emerging Threats rules. They are very, very prone to false positives because they are, by their very nature, designed to identify extremely surreptitious activity. They 'hit' on legitimate traffic many, many times over the number of times they identify actually suspicious network activity.
IDS/IPS is about as far from 'set it and forget it' as network security tools go. So-called 'threat hunters' or cybersecurity analysts or whatever they're called now get paid to spend their entire days fine-tooth combing large enterprise networks for needle-in-a-haystack packets, and come up with literally nothing of any actual, real concern the vast majority of the time. It's not that they don't find anything suspicious per se. But upon more careful inspection beyond what IDS/IPS rules can identify in the literal bits of packet streams, it's true that nearly 9.9 times out of there's no actual network 'intrusion.'
The rules that 'hit' in your OP are not necessarily indicative of suspicious activity (if not not even likely).
The PROTOCOL-DNS rule seems to be looking for packet streams of DNS answers containing hostnames of a certain length—nothing to do with the actual domain being queried itself (for which pfBlockerNG is a better tool anyway, and which you should use to block that Netflix domain, or, even better, a regex block for the string "dradis"). Only the actual text of the rule could confirm what it's 'looking' for.
And the INDICATOR-SHELLCODE rule—since this post is already quite long, I'll simply say I agree with John that there's an all-but-certain likelihood that those are false positives.
The most important part about using IDS/IPS is truly understanding why a rule 'hits' in the first place. Going further, the goal might even be to start writing your own custom rules, based on your own fundings. Sometimes legitimate packet streams contain what are otherwise legitimate 'indicators of compromise' (i.e., a false positive). And things can obviously go the other way too, and malicious activity is missed even by well-tailored custom rules.
@ssullivan556 said in So why is Netflix hitting me with Dradis?:
Indeed just trying to learn
This is the best reason I can think of to be trying to deploy IDS/IPS on a home network.
Thank you for clarifying. I had a whitelist, and it got wiped. It did not include anything like this.
Since we are playing hardabll now:
OK, skepticism active. Why. Dradis. Ever? Ad tracking? Seriously? How deep do these f***s need to go?"based on my own findings" laughable. Why do these rules exist if they can call Dradis and still be written off as a false positive? WHY UNREQUESTED SHELLCODE???
-
@tinfoilmatt said in So why is Netflix hitting me with Dradis?:
But since I pushed back on him a little bit, I now feel a little obligated to do the same to you—if only in the spirit of fairness:
Good, please convince me this is nothing to worry about. Dradis tho?
-
@ssullivan556 said in So why is Netflix hitting me with Dradis?:
Dradis tho?
maybe they are fans of battlestar glactica ;)
-
@ssullivan556 said in So why is Netflix hitting me with Dradis?:
please convince me this is nothing to worry about.
Nobody's here to try to convince you of anything, buddy.
-
You showed an Ethernet packet, received from 8.8.8.8, as some device, your 10.0.0.34, has asked it a question : What is the A record (the IP) of :
There is no payload, the entire packet is shown.
Every single bit is defined - I looked them all up. Imho, Seems 100 % legit to me, and there no place for malicious scripts = series of bytes ;) This is a DNS packet : there are no 'spare' bits left !
The DNS question was "CNAME" pointing to a CNAME pointing to a CNAME" ... etc, snort might say :
yeah, true, there was a long answer (4 IPs !) but nothing seems out of order here.
Consider this :
What happens if a MacDondalds in Honk Kong serves one totally rotten hamburger to one client ?
Ok, that one client will be having a hard time. Food poisoning isn't a joke.
But there will be more then one victims : there will be thousands of victims : the MacDonalds share holders, as this one hamburger event will trigger our social networks doing there one and only thing : spreading the bad news. The MacDo stock market will plunge ... Share holder will suffer.
What I mean : Netflix won't try to do 'nasty' things with the one and only packet that is visible for the entire planet : a DNS packet.
I don't think Neflix prepares malicious DNS replies for you or some one else. Not because they want to protect you (they probably don't care about you, there are in it for your $ or €, that's all) but Netflix really (like REALLY !) wants to protect the share holders. So they won't start a low bud DNS spoof or whatever attack that everybody can find out in mere seconds, as this will a short path to a total company collapse, they have to much to lose.
After all, can your 'data' be worth more as entire (their) stock market value ?If netflix want to take control of your TV, and why stop there, everything in your local network, they will code their app that 'lives' in your TV with nasty capabilities. The app will talk over TLS with 'home'. And from then on, Squid, snort etc won't detect anything.
Netflix uses SHTS, so their TLS traffic can not be MITM'ed.To make the story short : we, "the small ones", are protected by the the big ones, as we all have this one powerful weapon : our $ (or €). Without it, they are gone.
Btw : not implying that my 'answer' (rambling ?) is the answer, just my thoughts.
-
@Gertjan said in So why is Netflix hitting me with Dradis?:
You showed an Ethernet packet, received from 8.8.8.8, as some device, your 10.0.0.34, has asked it a question : What is the A record (the IP) of :
There is no payload, the entire packet is shown.
Every single bit is defined - I looked them all up. Imho, Seems 100 % legit to me, and there no place for malicious scripts = series of bytes ;) This is a DNS packet : there are no 'spare' bits left !
The DNS question was "CNAME" pointing to a CNAME pointing to a CNAME" ... etc, snort might say :
yeah, true, there was a long answer (4 IPs !) but nothing seems out of order here.
Thanks for digging into it! I would not expect malicious code in the DNS request either. My only concern about this packet was why any app on my TV would want to know the ip of any Dradis server. As Tinfolmatt mentioned, this may be their teams doing white hat activities. This is the best-case scenario in my mind, but there can also be bad actors within companies. I also understand that Netflix itself would not risk getting caught doing malicious things in the open, but here we are, my TV requested this dradis server. I guess I will be finding out how their customer support services are next week. If it is white hat activities, they should want to admit it since it is indeed all about protecting shareholders, and this is not a great look.
-
We cancelled Netflix because of their outdated approach to IPv6 tunnel brokers. They treat anyone using an IPv6 tunnel—such as Hurricane Electric—as if they're using a VPN to bypass restrictions. Other major streaming platforms don’t have this issue, and their networking teams clearly have a better grasp of modern IPv6 deployments. If Netflix can’t keep up, we’re more than happy to spend our money elsewhere.
-
@JonathanLee Just reiterating, the Netflix app was never even opened since the factory reset (unrelated, a few days before this packet), let alone logged into an account (I don't have one myself)
-
@ssullivan556 because they use that fqdn in their service domain name as CNAME that points to another fqdn, and so on. That you think because they have dradis in their domain name its doing something nefarious is beyond ridiculous
;; QUESTION SECTION:
;nrdp25.appboot.netflix.com. IN A;; ANSWER SECTION:
nrdp25.appboot.netflix.com. 111 IN CNAME appboot.dradis.netflix.com.
appboot.dradis.netflix.com. 57 IN CNAME appboot.us-west-2.origin.prodaa.netflix.com.
appboot.us-west-2.origin.prodaa.netflix.com. 57 IN A 34.217.204.82
appboot.us-west-2.origin.prodaa.netflix.com. 57 IN A 44.234.6.167
appboot.us-west-2.origin.prodaa.netflix.com. 57 IN A 52.89.219.164You are chasing ghosts here.
-
@johnpoz Now this actually makes sense. Thank you. In other words, the TV asked "hey, what are the addresses for apps on Netflix" and 8.8.8.8 said "here are ALL the apps you can choose from" and we do not know from this what my device continued to use. I guess I need to spend some time with ntop if I really want to know.
Nowhere did I claim to know a lot about how IP works, was just looking for an explanation to learn more.
-
@ssullivan556 which is why we are here - glad we got it sorted.
It could be checking for updates to apps It could be checking for update for its own os, it could be checking that it can talk to Google..
Could be saying here I am a new instance - it could be doing all sorts of things - but what your DNS was just that is was looking for specific fqdn, and dradis just happened to be part of the fqdn they are using, in this case just as a cname to point it elsewhere.
As to why dradis in the in the fqdn - maybe who came up with was a fan of bsg, maybe it hits one of their servers using dradis to log traffic? But it sure wasn't scanning you are doing any sort of pen test - you show a query to 8.8.8.8 on normal DNS port 53.
-
Keep in mind that most smart-TV platforms update their apps automatically, whether you use them or not. It’s similar to the Microsoft Store on Windows, which updates apps you never open.
I’ve also developed a personal bias against Netflix because of how aggressively they react to any IPv6 tunnel broker. After dealing with endless workarounds—forcing IPv4 DNS, custom DNS entries, and other bypass methods—I finally got fed up and switched to Apple TV for a while. Most of the other major streaming services don’t seem to care at all about Hurricane Electric IPv6 tunnels, but Netflix is extremely strict.
It’s also important to understand that many streaming apps use containerized instances that spin up temporarily for DRM and security, then self-delete when they’re done. Because of that, the platforms want everything locked down and up to date, even if you haven’t logged in. They want the application to be fully ready—and fully secure—for the moment you do decide to use it.
