talosintelligence.com domain requests
-
I am getting a crazy amount of talosintelligence.com domain requests, around 16k per day and these aren't just happening during CRON updates but all of the time, does anyone know what is causing this?
You can check this yourself by going to pfblockerng - reports - DNS reply or DNS reply stats.
On mine it's querying this domain constantly and I can't find what setting is causing it.
-
@bigjohns97 said in talosintelligence.com domain requests:
talosintelligence.com
That is a cisco site
-
@johnpoz Thanks,
I did go to the website and noticed it was for ip reputation however when I disable all ip reputation options it still queries 24/7 not just during CRON jobs.
I was wondering why it would be using that domain all the time and not just during CRON updates.
-
I have no idea what your running... But the link to download IP blacklists from there is different
https://snort-org-site.s3.amazonaws.com/
As to why would you could be getting thousands of queries, is because its not resolving because it blocked - so some script running might not be able to finish and just continues to run..
-
@johnpoz thanks,
It does seem to be resolving, I am about to get to the website as well as seeing the proper ip response in the DNS reply tab so I don't think it is a blocking issue. There has to be something else hitting that domain that is outside the CRON update job, I have no idea how to track something like this down but the queries are coming from localhost so I do think it's some process running.
I am running 2.5.x development as well as the beta version of pfblockerng with python.
-
Are you redirecting queries to for other dns to loopback?
-
@johnpoz I am but I don't see this query coming from my LAN when I do packet captures on the LAN interface looking for port 53 activity.
-
Well that only has a ttl of 300 seconds.. So if something it talking to it, that could account for say like 288 queries in a 24 hour period.. But not 16k, unless what is doing the queries has no cache?
-
@johnpoz I even set min ttl to 3600, I know don't shame me :) and it shows the proper ttl count down on the queries but that is the cool thing about dns replies tab is it shows everything even if it is cache hits.
I am just wondering what option that is enabling this and if anyone else is seeing this on their install.
-
Well I am not seeing anything like that at all.
But I don't use pfblocker to look for lists like that. I only use a few lists and all either custom or geo IP lists.
Not going to shame you about the 3600 min ttl, I do the same thing - I hate these 300 second ttls and even worse some that are 60 seconds.
-
@johnpoz Yeah I get a lot of heat online when I tell people I do this, all kinds of lectures about what the DNS owner intended.
I just got tired of all of these cloud services setting 1 minute TTL's and hammering my WAN link with DNS traffic.
Anyways, hopefully someone can chime in on what is causing these DNS requests.
-
Yeah its not really good practice to mess with TTLs.. But then again its not good practice to set ttls to like 60 seconds either ;) Unless you were in the middle of a transition..
Common practice for when moving NS for example, or getting ready to change something for example would be to trim down the ttl to very small number as you get closer and closer to the actual change. So then when the change happens it happens very quickly. Then as it takes effect and all working you would ramp the ttl back up to something sane.
To be honest, many of these dns services site default to very low values - and they charge based upon number of queries. So wouldn't put it past them to try and get number of queries up higher to get more money.
The ones that bug me are the iot devices looking for something.. And they don't have any local cache anyway.. So like everytime they need to check something they have to do another query.. Which might be like every freaking minute anyway. But atleast I can cache is locally vs having to do an external query for it every 5 freaking minutes.
I have yet to find any issue with setting a 1 hour min ttl, other than a drastic reduction in number of external lookups.
edit: But then again I understand how dns works, and if having some sort of problem I would know exactly where to look, and validate it against authoritative NS for whatever, etc. I wouldn't suggest normal users adjust such settings.. So I could see how someone with out actual real world experience in crazy low ttls and how to deal with them might just state best practice.. Which back in the day, no you shouldn't mess with ttls like that.. But then again 10 years ago you wouldn't find services setting 60 second ttls ;) Nor did we have a shit ton of iot devices with no local dns cache trying to ping home to some fqdn every freaking minute ;)
edit2: example just 1 of the fqdn my thermostat looks for every freaking minute
Because it doesn't have a freaking local cache!! And its also just cname that points to place, that has a 60 second TTL..
So this 1 device could create a crazy amount of dns
;; ANSWER SECTION: ic3messaging.cloudapp.net. 60 IN A 13.84.163.27 -
@johnpoz said in talosintelligence.com domain requests:
Yeah its not really good practice to mess with TTLs.. But then again its not good practice to set ttls to like 60 seconds either ;) Unless you were in the middle of a transition..
Common practice for when moving NS for example, or getting ready to change something for example would be to trim down the ttl to very small number as you get closer and closer to the actual change. So then when the change happens it happens very quickly. Then as it takes effect and all working you would ramp the ttl back up to something sane.
To be honest, many of these dns services site default to very low values - and they charge based upon number of queries. So wouldn't put it past them to try and get number of queries up higher to get more money.
The ones that bug me are the iot devices looking for something.. And they don't have any local cache anyway.. So like everytime they need to check something they have to do another query.. Which might be like every freaking minute anyway. But atleast I can cache is locally vs having to do an external query for it every 5 freaking minutes.
I have yet to find any issue with setting a 1 hour min ttl, other than a drastic reduction in number of external lookups.
edit: But then again I understand how dns works, and if having some sort of problem I would know exactly where to look, and validate it against authoritative NS for whatever, etc. I wouldn't suggest normal users adjust such settings.. So I could see how someone with out actual real world experience in crazy low ttls and how to deal with them might just state best practice.. Which back in the day, no you shouldn't mess with ttls like that.. But then again 10 years ago you wouldn't find services setting 60 second ttls ;) Nor did we have a shit ton of iot devices with no local dns cache trying to ping home to some fqdn every freaking minute ;)
edit2: example just 1 of the fqdn my thermostat looks for every freaking minute
Because it doesn't have a freaking local cache!! And its also just cname that points to place, that has a 60 second TTL..
So this 1 device could create a crazy amount of dns
;; ANSWER SECTION: ic3messaging.cloudapp.net. 60 IN A 13.84.163.27Yep, I had a robot vacuum that was doing the same thing, it was so bad someone wrote a firmware for it and provided instructions on how to hack it so it would stop calling home, it didn't respect the TTL at all. BTW I was doing the same thing when I was running PiHole as well.
-
@bigjohns97 said in talosintelligence.com domain requests:
it was so bad someone wrote a firmware for it
Nice!! Yeah some of this iot stuff is just horrible.. I have some smart power switches that use a uk ntp pool to sync time with.. Even though have the US model, and these companies are suppose to get their own vendor fqdn if they want to use the ntp pool.
So I setup host override to just point that to my local ntp server, because they don't honor what you hand out via dhcp, etc..
How much extra ram or coding would it take to just run a local cache.. I mean they are only looking for handful of fqdn.. Not a big issue say if you had 1 or 2 devices doing such nonsense. But when you start having 30 and 40 devices in a home all doing this nonsense - it becomes crazy very quickly. I have like 8 smart bulbs, and 5 or so smart switches, and then stuff like rokus and tvs, and all other kinds of iot stuff.. All doing queries for something every freaking minute.. To be honest I could see how some of these shitty implementations of caching ns on most of your soho routers could have issues with the number of queries that can build up..
-
I ended up resolving this issue by completely deleting the feed that was pointing to this domain, disabling the feed did not help, this is what has caused me so much time as I figured disabling the feed wouldn't query the domain but I guess the cron job still goes through and checks for an update even though it doesn't apply it.
Anyways deleting this list from my ipv4 pri1 lists kept the domain from querying over and over again and now my dns reply report is nice a clean again.
-
@bigjohns97 said in talosintelligence.com domain requests:
deleting this list from my ipv4 pri1
What list specifically - a fqdn is not a list to be downloaded what was the full url?
-
@johnpoz It was the Talos feed
https://www.talosintelligence.com/feeds/ip-filter.blf
I had also found some threads that were pointing to updating that URL to another one that worked better.
https://www.reddit.com/r/pfBlockerNG/comments/ibllbk/talos_ip_list_url/
And BTW I thought I had this fixed by running an out of band CRON as a test but looking at it again this morning I see this in my DNS replies again and don't even have the list defined, so obviously more work to do.
-
that url redirects to here
https://snort-org-site.s3.amazonaws.com/production/document_files/files/000/001/238/original/ip_filter.blf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIXACIED2SPMSC7GA%2F20200930%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20200930T125635Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Signature=ee8d075152fa77b1fbdec3f88502b35c40c9ca02472fb513251307db4dc2c382
I would guess has something to do with how they are doing the redirection?
first it redirects to here
https://snort.org/downloads/ip-block-listand then from there it redirects to that long url posted above... Looks to be a big mess if you ask me.. So yeah sure could see why some automated system could run into issues or a loop. Especially if using something like curl that might not be able to follow redirection.. Depending on how its done, etc.
-
@johnpoz Yeah I just don't get it, I deleted this feed yesterday and ran CRON and no hits in the reply list, and then I check again this morning and it's back, I don't know where it's defined at this point.
I am going to re-add it from the list again and reboot and see if it comes back
reboot is the only thing I know to make the queries stop once they start...
killing my uptime stats :)
Re-adding it under the original URL in the published feeds list doesn't solve the issue either.
I am at a loss of next steps :(
-
Added it and then removed it again and rebooted and something else is calling this domain and it's not through a feed, so I guess I am back where I started.
If anyone has any idea where this is coming from I am willing to disable something to test.
