You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With v5.0.0 we introduced radns.1 ... This program represents a major use of argus's control plane capture capability, where control plane flows contain the complete contents of the control plane transaction. When configured, using the new argus.conf variable, any udp or tcp domain, or mdns flow will contain the complete contents of a DNS or mDNS transaction. Argus tracks DNS by adding the DNS transaction id to the flow key, so that each transaction is a unique network flow record.
radns.1 reads argus data from an argus-data source, and extracts and tracks DNS transaction data from the argus data records. Depending on where argus is deployed, this enables you to collect all the DNS query and response information from and endpoint, DNS server, or if deployed on an external network interface, all the DNS traffic for a complete enterprise.
DNS is an exploitable system that can cause quite a bit of problems. If an adversary subverts a sites DNS, it can steer traffic to any endpoint, anywhere, and masquerade as internal or external trusted sites. A simple way of detecting this condition is to track what DNS servers are active in your site and track what addresses are being returned to DNS clients in response to queries. If you generate this data from an endpoint, you get the best opportunity to realize that a DNS exploitation is being done against the node.
Once you can generate this data, you can enable a Private Passive DNS capability. Private in that you can collect, and maintain the database yourself, without sharing your DNS transactions with a third party.
radns.1 is a flow record labeler, and can be configured to label flow records with the dns names of the saddr and daddr addresses seen in the outer IP DSR of flow records. As a flow record labeler, it can be a stage in an argus data flow stream, enhancing real-time flow records with real-time DNS metadata.
radns.1 has a lot of features:
Parse user data buffers to extract dns transaction contents.
Maintain an in memory database of DNS name requests and responses by server.
Label records with DNS metadata.
Alarm / notify when new DNS servers and clients are observed.
Alarm / notify when a flow's IP addresses have not been queried.
Provide back channel query interface to query DNS resolution state.
Export a complete accounting of DNS queries and responses.
Parse DNS Data
radns.1 reads flow data either from a file or a real-time stream and parses out DNS transaction data. Without any options, it prints out DNS content like tcpdump.1.
Invocation
This call reads argus(8) data from an inputfile and prints the DNS transaction content as it is parsed from the argus(8) records.
This call reads argus(8) data from inputfile and uses the -q option to suppress DNS transaction reporting. radns(1) caches its DNS server, clients and transaction data in memory, and when finished reading data, resolve queries about the data.
In this example, it reads a days of data and looks up references to a specific DNS query, printing its output as json data.
The argus clients programs provide a number of programs designed to get more out of the radns.1 features. radnsdb.pl is a perl script that will take the output of radns.1 and manage a database table of the dns names and IP addresses resolved by DNS. This generates what we are referring to as 'Private Passive DNS'.
The tools can maintain two daily database schemas, one for names, and one for addresses.
The name schema is below. For each unique FQDN (fully qualified domain name ending with a dot), this schema contains strings that have start and last time referenced, the TLD, NLD, a string that lists the IPv4 and IPv6 addresses that were resolved for this address, the clients and the servers that requested and responded with this data, cname, ptr, and ns responses, etc ... seen. Users of this table query for a set FQDN, TLD or NLDs, can get quite a bit of good information.
mysql> desc dns_2024_07_20;
+--------+-----------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------+-----------------------+------+-----+---------+-------+
| name | varchar(128) | NO | PRI | NULL | |
| tld | varchar(64) | YES | | NULL | |
| nld | varchar(64) | YES | | NULL | |
| ref | int | YES | | NULL | |
| stime | double(18,6) unsigned | YES | | NULL | |
| ltime | double(18,6) unsigned | YES | | NULL | |
| addrs | text | YES | | NULL | |
| client | text | YES | | NULL | |
| server | text | YES | | NULL | |
| cname | text | YES | | NULL | |
| ptr | text | YES | | NULL | |
| ns | text | YES | | NULL | |
+--------+-----------------------+------+-----+---------+-------+
12 rows in set (0.00 sec)
The address schema is below. For each unique IPv4 or IPv6 addresses, the names attribute contains a JSON formatted string that contains the start and last time referenced, the authoritative, referrals, cnames, etc ... seen. Many of these fields are empty, and representing the data as JSON proved to be very beneficial for CGI Restful API use. Users of this table query for a set of IPv4 or IPv6 addresses, and should be prepared to process the JSON. Mysql has some json parsing capability, so if you're good you can really get a lot out of this schema.
mysql> desc dns_2024_07_20;
+-------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| addr | varchar(64) | NO | PRI | NULL | |
| names | text | YES | | NULL | |
+-------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
radns.1
With v5.0.0 we introduced radns.1 ... This program represents a major use of argus's control plane capture capability, where control plane flows contain the complete contents of the control plane transaction. When configured, using the new argus.conf variable, any udp or tcp domain, or mdns flow will contain the complete contents of a DNS or mDNS transaction. Argus tracks DNS by adding the DNS transaction id to the flow key, so that each transaction is a unique network flow record.
radns.1 reads argus data from an argus-data source, and extracts and tracks DNS transaction data from the argus data records. Depending on where argus is deployed, this enables you to collect all the DNS query and response information from and endpoint, DNS server, or if deployed on an external network interface, all the DNS traffic for a complete enterprise.
DNS is an exploitable system that can cause quite a bit of problems. If an adversary subverts a sites DNS, it can steer traffic to any endpoint, anywhere, and masquerade as internal or external trusted sites. A simple way of detecting this condition is to track what DNS servers are active in your site and track what addresses are being returned to DNS clients in response to queries. If you generate this data from an endpoint, you get the best opportunity to realize that a DNS exploitation is being done against the node.
Once you can generate this data, you can enable a Private Passive DNS capability. Private in that you can collect, and maintain the database yourself, without sharing your DNS transactions with a third party.
radns.1 is a flow record labeler, and can be configured to label flow records with the dns names of the saddr and daddr addresses seen in the outer IP DSR of flow records. As a flow record labeler, it can be a stage in an argus data flow stream, enhancing real-time flow records with real-time DNS metadata.
radns.1 has a lot of features:
Parse DNS Data
radns.1 reads flow data either from a file or a real-time stream and parses out DNS transaction data. Without any options, it prints out DNS content like tcpdump.1.
Invocation
This call reads argus(8) data from an inputfile and prints the DNS transaction content as it is parsed from the argus(8) records.
This call reads argus(8) data from inputfile and uses the -q option to suppress DNS transaction reporting. radns(1) caches its DNS server, clients and transaction data in memory, and when finished reading data, resolve queries about the data.
In this example, it reads a days of data and looks up references to a specific DNS query, printing its output as json data.
Database Support
The argus clients programs provide a number of programs designed to get more out of the radns.1 features. radnsdb.pl is a perl script that will take the output of radns.1 and manage a database table of the dns names and IP addresses resolved by DNS. This generates what we are referring to as 'Private Passive DNS'.
The tools can maintain two daily database schemas, one for names, and one for addresses.
The name schema is below. For each unique FQDN (fully qualified domain name ending with a dot), this schema contains strings that have start and last time referenced, the TLD, NLD, a string that lists the IPv4 and IPv6 addresses that were resolved for this address, the clients and the servers that requested and responded with this data, cname, ptr, and ns responses, etc ... seen. Users of this table query for a set FQDN, TLD or NLDs, can get quite a bit of good information.
The address schema is below. For each unique IPv4 or IPv6 addresses, the names attribute contains a JSON formatted string that contains the start and last time referenced, the authoritative, referrals, cnames, etc ... seen. Many of these fields are empty, and representing the data as JSON proved to be very beneficial for CGI Restful API use. Users of this table query for a set of IPv4 or IPv6 addresses, and should be prepared to process the JSON. Mysql has some json parsing capability, so if you're good you can really get a lot out of this schema.
Beta Was this translation helpful? Give feedback.
All reactions