25 ms·

I don't know about a particular product but I have seen people pull in data feeds into both Splunk and into Elk/Logstash instances in conjunction with DNS query

I don't know about a particular product but I have seen people pull in data feeds into both Splunk and into Elk/Logstash instances in conjunction with DNS query logging. So the SIEM's were just Splunk and Elk/Logstash. Splunk is very expensive. The DNS data-feeds were commercial and I can't recall which companies provided them but the folks at Splunk could likely tell you. Just beware of sales people. If you wanted some publicly sourced data try out the firehol [1] datasets. They could probably be used in conjunction with Suricata or Snort distributed to each DNS resolver. [1] - https://github.com/firehol/blocklist-ipsets https://github.com/firehol/blocklist-ipsets

m3047 4y ago
Author here. Thanks, but I'm using DNS-as-a-database not DNS-as-given-data. Distinguishing feature: The command line example is using a DNS proxy to query a redis database containing netflow information. It also utilizes DNS to query synthesized PTR records representing DNS-as-given-data (just not the data they want to give you most of the time). DNS is the database.
- LinuxBender 4y ago
  Ah so more like a Rbldnsd used in the RBL/RSL servers. I've run rbldnsd [1] as both a lookup for spammers/malware and as an authoritative server. Different data format than redis but same idea. [1] - https://github.com/spamhaus/rbldnsd https://github.com/spamhaus/rbldnsd
  - m3047 4y ago
    Yes, RBL is an example (I've worked for Vixie FWIW) of DNS-as-a-database. Another notorious example in the Indicator of Compromise sector is EDR (chiefly antivirus) software which uses the DNS to query the provenance of file hashes. The popular take on Redis is that it's good for caching. Well, the DNS is good for caching; Redis is good for a kind of caching that the DNS is not good at: write caching (if there is such a thing). Netflows are a good example: despite whatever measures you take, you're going to be writing the same flow artifact over and over (might as well increment a counter). It may never be queried (read). If it is read, it will probably be read a fair amount in a short period of time. Architecturally, you can have agents updating whatever you want in a Redis database; then when you need it... wherever you need it... you make a DNS query, separating read and write concerns. Put the Redis db close to the event source(s) instead of shipping all of it to a cloud. Agents are already being managed as fleets, so that's just current state of the art.

m3047 4y ago

Author here. Thanks, but I'm using DNS-as-a-database not DNS-as-given-data. Distinguishing feature: The command line example is using a DNS proxy to query a redis database containing netflow information. It also utilizes DNS to query synthesized PTR records representing DNS-as-given-data (just not the data they want to give you most of the time). DNS is the database.

LinuxBender 4y ago
Ah so more like a Rbldnsd used in the RBL/RSL servers. I've run rbldnsd [1] as both a lookup for spammers/malware and as an authoritative server. Different data format than redis but same idea. [1] - https://github.com/spamhaus/rbldnsd https://github.com/spamhaus/rbldnsd
- m3047 4y ago
  Yes, RBL is an example (I've worked for Vixie FWIW) of DNS-as-a-database. Another notorious example in the Indicator of Compromise sector is EDR (chiefly antivirus) software which uses the DNS to query the provenance of file hashes. The popular take on Redis is that it's good for caching. Well, the DNS is good for caching; Redis is good for a kind of caching that the DNS is not good at: write caching (if there is such a thing). Netflows are a good example: despite whatever measures you take, you're going to be writing the same flow artifact over and over (might as well increment a counter). It may never be queried (read). If it is read, it will probably be read a fair amount in a short period of time. Architecturally, you can have agents updating whatever you want in a Redis database; then when you need it... wherever you need it... you make a DNS query, separating read and write concerns. Put the Redis db close to the event source(s) instead of shipping all of it to a cloud. Agents are already being managed as fleets, so that's just current state of the art.