So why is Netflix hitting me with Dradis?
-
@johnpoz said in So why is Netflix hitting me with Dradis?:
Or its just a simple DNS query and not some form of trying to sneak something into your network.
Which, again, is equal speculation on your part.
-
@tinfoilmatt Yeah I am just speculating that a dns query is just a dns query <rolleyes>
-
@johnpoz said in So why is Netflix hitting me with Dradis?:
@tinfoilmatt Yeah I am just speculating that a dns query is just a dns query <rolleyes>
Your attempts to manipulate my words reveal the strength of your position.
-
You could block that if you want, but when they can't talk they tend to get more chatty about it - asking more and more often, etc..
Also a noob here myself lol. That's pretty much like my Netgear router despite being in AP mode, pretty much spams 8.8.8.8/8.8.4.4 for connectivity checks, even though its DNS in its web interface is set to the pfsense firewall which in turn is set to Cloudflare and Quad9. When 8.8.8.8/8.8.4.4 got blocked as part of the DoH IP list in pfblockerng it became even more aggressive and I had a spam of block alerts like every 3-5 secs if not more often at times lol. If I recall something similar happened when I had "Chromecast with Google TV" dongles a few years ago, so I'm not surprised.
-
@aivxtla My devices hammer
connectivitycheck.gstatic.com,gsas.apple.com,bing.com,ngw.dvr163.com(a Chinese NVR), etc. all day long. It is what it is.On this point specifically (i.e., DNSBL and/or IPBL), make sure to configure logging such that these queries/packets are 'sinked'.
-
@tinfoilmatt said in So why is Netflix hitting me with Dradis?:
strength of your position.
So you're saying it is malicious then? an iot device doing queries to a hard coded public DNS server, to a domain dradis.netflix.com
-
@johnpoz OP's speculation that his TV querying a domain aliased to
appboot.dradis.netflix.comis potentially nefarious, is equally as speculative as your 'position' that it's not. -
@tinfoilmatt whatever - done here..
And the moon is not made of cheese is speculation the same as saying it is.
While mine is based on common sense and experience - his is based off what? His tinfoil hat.. He doesn't even understand the direction of the traffic flow..
-
@johnpoz said in So why is Netflix hitting me with Dradis?:
And the moon is not made of cheese is speculation the same as saying it is.
No. It's mostly rock. We've been there, and samples have come back.
If you simply want to call the person stupid for trying to understand and learn, then just have out and say it, John. You're not hiding it very well.
-
@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.
