The AXA User Guide
Farsight Security’s (now a part of DomainTools) Advanced Exchange Access (AXA) is a suite of tools and library code that brings the Security Information Exchange (SIE) directly to the end-user’s network.
SIE is a scalable and adaptable real-time data streaming and information sharing platform. SIE collects and provides access to more than 200,000 observations per-second of raw data from its global sensor network. Farsight also applies unique and proprietary methods for improving usability of the data, directly sharing the refined intelligence with SIE customers and DNSDB®, one of the world’s largest passive DNS (pDNS) databases.
The diverse set of data available from SIE includes the following and is relevant and useful for practitioners in various technology roles:
- Raw and processed passive DNS data
- Darknet/darkspace telescope data
- SPAM sources and URLs
- Phishing URLs and associated targeted brands
- Connection attempts from malware-infected systems (as seen by a sinkhole)
- Network traffic blocked by Intrusion Detection Systems (IDS) and firewall devices
Each unique set of data in SIE is known as a channel and the data acquired from a specific channel can be customized to meet the needs of each customer, enabling you to subscribe to and access only the channels needed to solve your problem. A channel in SIE may be the result of raw data analysis, or a subset of data from other channels.
The data available from SIE channel subscription packages includes:
- Raw Passive DNS: Real-time observations of DNS cache-miss traffic sent from DNS recursive resolvers on the Internet to authoritative name servers. The DNS information includes authoritative DNS data that various zone operators make available and responses from authoritative name servers to recursive resolver queries
- Value-Added Passive DNS: Real-time de-duplicated, filtered, and verified passive DNS (pDNS) data observed on the Internet
- Newly Observed Domains (NOD) and Newly Observed Hostnames (NOH): Real-time actionable insights for domains and hostnames, fully qualified domain names (FQDNs), when they are first successfully resolved on the Internet
- Base Channels: A collection of threat intelligence channels that provide access to honeypot data (darknet and spam) and botnet (e.g., Conficker) sinkhole data. The data also includes threat intelligence for phishing campaigns and log data for network traffic blocked by Intrusion Detection Systems (IDS) and firewall devices
- Premium Channels: A range of premium security-related feeds including malware metadata, IOCs and other telemetry. Subscribers consume the intelligence as real-time event flows rather than traditional batch transfers – which are inherently delayed
The SIE Channel Guide provides an overview of the channels available from SIE.
Advanced Exchange Access Toolkit
The Advanced Exchange Access (AXA) toolkit contains tools and a C library to bring Farsight’s real-time data and services directly from the Farsight Security Information Exchange (SIE) to the subscriber’s network edge.
AXA enables subscribers to connect to Farsight’s subscription-based SRA (SIE Remote Access) servers. These servers provide access to data and services built from Farsight’s SIE.
Contents of the Advanced Exchange Access Toolkit
Farsight freely provides several end-user tools to stream AXA data in the Advanced Exchange Access Toolkit. This distribution contains the following:
- sratool: A command-line tool used to connect to an SRA server, set watches, enable SIE channels, and stream data.
- sratunnel: A command-line tool that streams SIE data to the local network.
- libaxa: A C library providing an API for the AXA protocol including:
- connection instantiation/teardown
- message encapsulation/decapsulation
- watch parsing/loading
- control packet rate limits, sampling rates, window sizes, and many other AXA-specific functions
Many of the features and options we’ll be discussing are the same amongst all of the tools and examples will be given where appropriate.
Farsight SIE Remote Access
SIE Remote Access (SRA) is Farsight’s software solution to make SIE content available to remote users. SRA enables SIE channel traffic to be delivered through a TCP stream across the Internet. In order to reduce bandwidth, SRA provides subscribers with the ability to invoke a server-side filtering capability across a set of channels, selecting only that subset of records that match specific domain name / IP address search criteria.
The Advanced Exchange Access suite of tools and library code is the software that implements Farsight’s SRA service.
The AXA suite consists of two Unix command line tools and one C library developers can use to build custom SRA applications.
sratool
sratool is the AXA Swiss Army Knife. It is a versatile tool used to test, debug, or stream AXA connections. It connects to an SRA server, sends protocol messages and displays the responses. It can also tunnel SIE data like sratunnel does.
sratunnel
sratunnel transfers selected SIE data from the remote server to the local network. The connection to the server is created and restored, with binary exponential delays between retries.
sratunnel is the workhorse of the AXA family. It is used to transfer SIE data from the remote server to the local network. It is what Farsight uses for production deployment of SIE data to the customer. sratunnel can be thought of as a fast, efficient, and smart conduit for SIE data. Data goes in one end and sratunnel can emit the data into different output formats, including:
- NMSGs to a UDP port
- NMSGs to a TCP port
- NMSGs to a file
- pcap to a file
- pcap to a network interface
libaxa
libaxa is the C programming library that exposes the AXA API to the application programmer.
The AXA Protocol
The AXA protocol is documented in the section titled AXA Protocol in the README file found on the GitHub repository for the Farsight Advanced Exchange Access Toolkit.
AXA Limits
Some of the channels offered by the SIE network burst to an extremely high bitrate. AXA has two ways to deal with such network-hungry situations: optional filtering and loss-tolerance built into the protocol.
Filtering can take one of the following forms:
- Via the rate limit option to reduce the flow of ingress data to a certain number of packets per second.
- Via one or more IP-based or DNS-based “watches” to limit the flow of data to specific assets the subscriber wishes to observe.
Finally, AXA is a deliberately lossy protocol. If a subscriber requests more data than the network can carry, data overruns will occur. When this happens, loss markers are transmitted reliably within the AXA stream to inform the subscriber via the AXA accounting subsystem (see below). At this point, the subscriber’s possible mitigation strategies include:
- ask for less data via rate limiting
- increase network capacity and/or other host resources
- treat the SRA stream as a chunky and non-representative sample of the total SIE data
- pursue Direct Access to SIE
AXA Watches
In the AXA world, the way an end-user registers interest in an asset is through what’s known as a watch. These are fundamental building blocks of AXA sessions. In order to get anything done, an end-user must specify one or more watches to inform the AXA server what she is interested in seeing.
There are four different types of AXA watches, each is described below:
- IP Watches: used to express interest in SIE messages containing a specified IP address or CIDR block. AXA supports both IPv4 and IPv6 address types.
- DNS Watches: used to express interest in SIE messages containing a specified hostname, domain, or wildcard hostname.
- Channel Watches: used to express interest in all SIE messages from a given channel. This is useful to enable “the firehose” for a given channel and ask SRA to send everything from the specified channel rather than matching IP address information or DNS names. Only valid for SRA connections.
- Error watches: used to express interest in SIE messages that cannot be decoded by the server. Only valid for SRA connections and intended only for debugging.
Watches are referenced by tags. A tag is simply an arbitrary 16-bit integer label used to keep track of individual watches.
When connected to an SRA server, tags must be unique. Each watch will use a different tag.
Depending on the tool, tagging may be done explicitly by the end-user or implicitly, by the tool. Examples follow.
AXA Watch Examples: SRA
The following examples show how to watch for SIE messages on channel 204 containing the IP address 10.0.0.1, that are in the CIDR block 192.168.0/24, or that are in the *.farsightsecurity.com domain.
sratool
The end-user specifies a unique tag per watch:
$ sratool
sra> connect ...
sra> 1 watch ip=10.0.0.1
1 OK WATCH started
sra> 2 watch ip=192.168.0/24
2 OK WATCH started
sra> 3 watch dns=*.farsightsecurity.com
3 OK WATCH started
sra> channel 211 on
* OK CHANNEL ON/OFF channel ch211 on
...sratunnel
With sratunnel, tags are generated internally so the end-user only needs to specify the -w option and the assets above:
$ sratunnel -w ip=10.0.0.1 -w ip=192.168.0/24 -w dns=*.farsightsecurity.com -s ... -o ... -c 211SRA and AXA RESTful Interface
The Farsight Security Advanced Exchange Access (AXA) RESTful Interface adds a streaming HTTP interface on top of the AXA toolkit to enable developers of web-based applications to interface with Farsight Security’s SIE Remote Access (SRA) servers.
The SRA module facilitates the real time streaming of data from the Security Information Exchange (SIE) over HTTP using a RESTful API.
Access is controlled via an API key that is passed as the X-API-Key HTTP header.
The Farsight Security AXA RESTful Interface does not have any specific operating system requirements as it is delivered over a RESTful API. Farsight Security provides a convenience command line interface (CLI) tool that doubles as a Python extension module which is compatible with various modern operating systems. AXA REST requires HTTPS permitted outbound to axa-sie.domaintools.com. Subscribers must have purchased a service entitlement from Farsight Security and have been provisioned an API key.
SRA Internals
The SRA module facilitates the real time streaming of data from the SIE over HTTP using a RESTful API.
Channels
SRA requires the user to specify one or more SIE channels to stream. These are specified as an integer, for example `255`.
Watches
SRA requires the user to specify one or more IP watches and/or one or more DNS watches. These tell the server what to filter and send to the client. These are specified as ip=<address>{/CIDR} or dns=example.com, or dns=*.example.com.
Example: -w ip=192.253.0.0/16 -w dns=*.example.com
SRA Tutorial: Watch Newly Observed Domains
This tutorial assumes you’ve signed up to receive Farsight’s Newly Observed Domains (NOD) data feed to watch newly active domains and ensure your users don’t visit any newly minted – often malicious – domains. It shows you how to examine the Newly Observed Domains (NOD) feed in real time.
$ sratool
sra> conn ....
* HELLO srad v3.0.1 stage-sie-axa-1 supporting AXA protocols v1 to v2; currently using v1
* Using AXA protocol 2
* OK USER FSI-0410-10112 authorizedInvoke sratool, and use the connect command to establish a connection to the SRA server. The connection is managed via SSH, meaning all of the benefits conferred by the SSH protocol are available to sratool. Upon success, the client emits the hello string from the AXA_P_OP_HELLO message which was sent by the server and contains the server’s software version, name, and AXA protocol version.
sra> 1 watch ch=212
1 OK WATCH startedInform the server we want to watch SIE channel 212 traffic (this is the NOD channel). The server responds with the current watch status. The watch is the most fundamental sratool command. This is how sratool “signs up” to receive data from the SRA server. As its name implies, watch sets up a watch which is a low-level primitive that tells the SRA server that the client is interested in nmsg messages or IP packets that meet one of the following criteria:
- is to, from, or contains the specified address
- contains the specified domain name
- arrived on the specified SIE channel
- are SIE messages that could not be decoded
A watch is given a tag that is an integer label used to refer to the watch. An SRA server connection or session can have zero or more watches at a time and the user can add or delete watches as needed. Note that sratool allows only a single SRA connection at a time.
sra> count 5
Using the count command, we inform sratool we only want to see 5 packets. After this number is met, sratool will stop emitting packets to the screen (though traffic may still be flowing from server to client).
sra> channel 212 on
* OK CHANNEL ON/OFF channel ch212 onWith the channel command, enable channel 212 (NOD). The current channel status is printed. Another fundamental command to sratool is channel. Issued alone on the command-line, it will emit the entire list of available SIE channels for which the user is provisioned.
1 ch212 {"time":"2023-02-01 19:10:02.575703046","vname":"SIE","mname":"newdomain","source":"a1ba02cf","message":{"domain":"meurepetidor.ws.","time_seen":"2023-02-01 19:09:36","bailiwick":"ws.","rrname":"meurepetidor.ws.","rrclass":"IN","rrtype":"MX","rdata":["1 mail.hope-mail.com."],"keys":[],"new_rr":[]}}
1 ch212 {"time":"2023-02-01 19:10:03.920603701","vname":"SIE","mname":"newdomain","source":"a1ba02cf","message":{"domain":"aqrin.me.","time_seen":"2023-02-01 19:09:04","bailiwick":"me.","rrname":"aqrin.me.","rrclass":"IN","rrtype":"NS","rdata":["carlos.ns.cloudflare.com.","davina.ns.cloudflare.com."],"keys":[],"new_rr":[]}}
1 ch212 {"time":"2023-02-01 19:10:07.132796370","vname":"SIE","mname":"newdomain","source":"a1ba02cf","message":{"domain":"speedpaw.com.","time_seen":"2023-02-01 19:08:58","bailiwick":"com.","rrname":"speedpaw.com.","rrclass":"IN","rrtype":"NS","rdata":["liz.ns.cloudflare.com.","marty.ns.cloudflare.com."],"keys":[],"new_rr":[]}}
1 ch212 {"time":"2023-02-01 19:10:09.254487282","vname":"SIE","mname":"newdomain","source":"a1ba02cf","message":{"domain":"jacquelinepongmarketing.com.","time_seen":"2023-02-01 19:09:21","bailiwick":"com.","rrname":"jacquelinepongmarketing.com.","rrclass":"IN","rrtype":"NS","rdata":["ns1.bluehost.com.","ns2.bluehost.com."],"keys":[],"new_rr":[]}}
1 ch212 {"time":"2023-02-01 19:10:09.325774830","vname":"SIE","mname":"newdomain","source":"a1ba02cf","message":{"domain":"aashraymakkar.com.","time_seen":"2023-02-01 19:09:24","bailiwick":"com.","rrname":"aashraymakkar.com.","rrclass":"IN","rrtype":"NS","rdata":["ns2.wixdns.net.","ns3.wixdns.net."],"keys":[],"new_rr":[]}}
packet count limit exceeded
sratool emits 5 NOD packets as it receives then from the server. Once the packet count limit is reached, emission stops.
sra> count
packet printing stopped by count 97 packets agoIssuing the count command with no arguments prints the current count status. In this case, we find 1990 NOD packets have been streamed to the client, but since we exceeded our limit, they were not emitted to the screen.
SRA Tutorial 2: Counts And Limits
Continuing in the session above, let’s tweak a few knobs and press a few buttons.
> list watches
1 ch=ch212The list watches command prints all of the active watches. We’ve still got one going, we’re just not emitting any packets to the screen.
> 1 delete
1 OK STOP watch deletedWe delete the watch by referencing its tag with the delete command.
> rate
RATE LIMITS
unlimited per second; current value=307
10 seconds between reportsAnother handy command, rate allows us to query the rate limiter and control it. Currently, there is no rate limiting in play – packets will be emitted as quickly as they appear. For lower bandwidth channels, like NOD, this is might not be a problem. For the DNSDB channels, which are much higher bandwidth, we’ll want to limit the
rate at which those packets are sent by the server to sratool.
> rate 1
RATE LIMITS
1 per second; current value=2
10 seconds between reportsUsing the rate command, we set a rate limit of 1 packet per second. This will come in handy in the last part of the tutorial where we’ll examine DNSDB.
sratunnel Tutorial: Newly Observed Domains
Now that you know how to use the Newly Observed Domains (NOD) datafeed to watch newly active domains and ensure your users don’t visit any newly minted – often malicious – domains, we are going to show you how to to tunnel the data to your local network for bulk analysis.
To consume the data in this tutorial, you’ll need another Farsight’s nmsgtool utility. It is a deeply useful all-purpose tool for working with NMSGs (network messages). NMSG is the format Farsight uses to type, structure and package arbirtary data for transit. Much of Farsight’s data is packaged and delivered as NMSG. A detailed discussion of the NMSG suite will be covered in future blog series. For now it’s just important to understand that you can work with NMSGs using nmsgtool.
This tutorial will show you how to plumb the Newly Observed Domains (NOD) feed from SIE to your local network, in real time. Commands and their output are listed with discussion below.
$ sratunnel -s apikey:[email protected],PORT Invoke sratunnel. The -s option instructs the tool where and how to connect. The option string should look familiar, it’s the same one used with sratool with the same intent and results. Securely connect via SSH as sra-service to axa-sie.domaintools.com.
> -c 212The -c option sets the channel to stream. We want NOD, which is channel 212.
> -w ch=212 The -w option sets the watch : in this case, everything on channel 212.
> -o nmsg:udp:127.0.0.1,8430Finally, we specify -o, which tells sratunnel where to put the data it streams. In the case above, we’ve set NMSGs to localhost on port 8430 and that’s where we’ll find our output. Data is now flowing. Let’s have a look…
$ nmsgtool -l 127.0.0.1/8430 We use nmsgtool to connect to the loopback address on port 8430.
> -c 20000The -c option specifies a maximum count of payloads to capture.
> -o channel-212.txtThe -o option tells nmsgtool to write presentation output to a file.
$ head -8 channel-212.txtLet’s examine one entry.
[98] [2014-12-16 23:31:06.438992023] [2:5 SIE newdomain] [a1ba02cf] [] []
Each NMSG datagram contains a fixed-length header containing the message size, a UTC timestamp, the message type, a 32-bit source identifier and optional SIE operator and group codes (both empty in this case).
domain: befrenshee.com. The fresh new domain, hot off the press!
time_seen: 2014-12-16 23:28:19How fresh? At the time of this writing, that timestamp of when the domain was observed was just over two minutes old.
rrname: befrenshee.com.
rrclass: IN (1)
rrtype: NS (2)
rdata: ns67.domaincontrol.com.
rdata: ns68.domaincontrol.com.The DNS meta-data associated with the domain.
$ grep ^domain: channel-212.txt | awk '{print $2}' > NOD.txtManipulate the data however you see fit.
sratunnel Tutorial: Create a persistent connection to SIE
An example using sratunnel as a background process to stream nmsg messages from SIE Channel 255 (SIE Heartbeat Channel) to the loopback interface on port 8000.
- Invoke sratunnel with the following arguments.
$ sratunnel -s 'ssh:[email protected]' -c 255
-w ch=255 -o nmsg:udp:127.0.0.1,8000 &- Use tcpdump to confirm messages are being streamed.
$ sudo tcpdump -i lo -c 5 -nn port 8000
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
11:18:41.204425 IP 127.0.0.1.36707 > 127.0.0.1.8000: UDP, length 941
11:18:58.672776 IP 127.0.0.1.36707 > 127.0.0.1.8000: UDP, length 941
11:19:16.312962 IP 127.0.0.1.36707 > 127.0.0.1.8000: UDP, length 941
11:19:33.833821 IP 127.0.0.1.36707 > 127.0.0.1.8000: UDP, length 941
11:19:51.277784 IP 127.0.0.1.36707 > 127.0.0.1.8000: UDP, length 941
5 packets captured
10 packets received by filter
0 packets dropped by kernel- Bring the background process to the foreground.
$ fg- Kill the sratunnel process by pressing Control-C.
Process messages with nsmgtool
The nmsgtool program is a single tool for taking inputs from a variety of different inputs like data streams from the network, capturing data from network interfaces, reading data from files or even standard input and making NMSG payloads available to one or more outputs.
Viewing a stream of nmsg’s from sratunnel with nmsgtool
An example using sratunnel as a background process to stream nmsg messages from SIE Channel 255 (SIE Heartbeat Channel) to the loopback interface on port 8000; using nmsgtool to connect to the loopback interface and print the nmsg to the terminal in presentation format.
- Invoke sratunnel with the following arguments:
$ sratunnel -s 'ssh:[email protected]' -c 255 -w ch=255 -o nmsg:udp:127.0.0.1,8000 &- Invoke nmsgtool to connect to the loopback interface on port 8000, process three payloads and print the output to the terminal using the presentation format.
$ nmsgtool -l 127.0.0.1/8000 -c 3 -o -
[23] [2017-06-28 19:53:51.844574928] [1:11 base encode] [1ba02cfd] [] []
type: TEXT
payload: <BYTE ARRAY LEN=19>
[23] [2017-06-28 19:53:52.345241069] [1:11 base encode] [1ba02cfd] [] []
type: TEXT
payload: <BYTE ARRAY LEN=19>
[23] [2017-06-28 19:53:52.845875978] [1:11 base encode] [1ba02cfd] [] []
type: TEXT
payload: <BYTE ARRAY LEN=19>- Bring the background process to the foreground.
$ fg- Kill the sratunnel process by pressing Control-C.
srartunnel Tutorial: Saving a stream of nmsg’s from sratunnel with nmsgtool
An example using sratunnel as a background process to stream nmsg messages from SIE Channel 255 (SIE Heartbeat Channel) to the loopback interface on port 8000; using nmsgtool to connect to the loopback interface and saving the output to a rotating set of files using the nmsgtool kicker function.
- Invoke sratunnel with the following arguments:
$ sratunnel -s 'ssh:[email protected]' -c 255
-w ch=255 -o nmsg:udp:127.0.0.1,8000 &- Invoke nmsgtool to connect to the loopback interface on port 8000, save nmsg files to disk every sixty seconds as a background process.
$ nmsgtool -l 127.0.0.1/8000 -t 60 -k '/bin/true' -w ch255 &- List the saved files using ls.
$ ls -l
total 16
-rw-r--r-- 1 demo demo 5518 Jun 28 16:03
ch255.20170628.2002.1498698127.548592412.nmsg
-rw-r--r-- 1 demo demo 6436 Jun 28 16:04
ch255.20170628.2003.1498698180.574404303.nmsg- Read one of the files using nmsgtool and outputting the results to the terminal in JSON:
$ nmsgtool -r ch255.20170628.2003.1498698180.574404303.nmsg -J -
{"time":"2017-06-28 20:03:02.061745882","vname":"base",
"mname":"encode","source":"1ba02cfd",
"message":{"type":"TEXT","payload":"IkZTSSBTSUUgaGVhcnRiZWF0Ig=="}}
{"time":"2017-06-28 20:03:02.562045097","vname":"base",
"mname":"encode","source":"1ba02cfd",
"message":{"type":"TEXT","payload":"IkZTSSBTSUUgaGVhcnRiZWF0Ig=="}}
{"time":"2017-06-28 20:03:03.062705039","vname":"base",
"mname":"encode","source":"1ba02cfd",
"message":{"type":"TEXT","payload":"IkZTSSBTSUUgaGVhcnRiZWF0Ig=="}}- Bring the nmsgtool background process to the foreground.
$ fg- Kill the nmsgtool process by pressing Control-C.
- Bring the sratunnel background process to the foreground.
$ fg- Kill the sratunnel process by pressing Control-C.
sratool Tutorial: Stream SIE traffic
sratool is a test/debug/instructional command-line tool used to connect to an SRA server, set watches, enable SIE channels, and stream data.
This example uses sratool to emit five messages seen on SIE Channel 255 (SIE Heartbeat Channel):
$ sratool
sra> connect ssh:[email protected]: connect to an
SRA server using the SSH transport. SSH used its keyring to prove
the user's identity, so there was no 'password:' prompt. The
HELLO response from the remote end displays its version number
and the protocol level.
sra> count 5: instruct the sratool client to stop after five
messages are output.
sra> channel 255 on: instruct the remote end to listen to SIE
channel 255 which was OK'd by the server indicating that it is
provisioned for this channel according to the authentication and
authorization level.
sra> 1 watch ch=255: watch all content on channel 255 (with no
rate limiting or filtering).Accounting Messages
By default, sratool will return AXA accounting messages containing current counter statistics relevant to the current session. For more details on these packet counts, see the Accounting section below
Rate Limiting
Rate limiting is used to limit the rate of incoming AXA messages transmitted from the server to the client. While it works for both SRA, it is primarily useful for high bitrate SIE channels such as the DNS Errors channels.
Rate Limiting Examples
The end-user wishes to watch for all SIE messages on channel 204 (a channel with an average bandwidth of 21Mbps) but only wishes to receive (at most) 10 messages per second.
sratool
With sratool, the end-user has the option to receive rate limit loss reports. The example below specifies a rate limit value of 10 and a 5 second interval between server rate limit reports:
$ sratool
sra> connect ...
sra> rate 10 5
* OPTION RATE LIMIT
10 per second; current value=0
5 seconds between reports
sra> 1 watch ch=211
sra> channel 211 on
...
* MISSED
missed 0 input packets, dropped 0 for congestion,
dropped 57911 for rate limit, filtered 72417
since 2016/10/11 14:25:32sratunnel
With sratunnel, rate limiting is specified as a simple command line option:
$ sratunnel -r 10 -w ch=211 -s ... -o ... -c 211Sampling
Sampling is a way to statistically sample a percentage of messages from the server. For example, if a value of 50 is chosen, AXA will return a uniformly distributed random sample of 50% of the messages caught by watches. Enabling sampling with any of the tools is quite straightforward.
sratool
$ sratool
sra> connect ...
sra> sample 50
* OPTION sample 50.00%
...sratunnel
$ sratunnel -m 50 -s ...TCP Buffer Sizing
AXA allows the end-user to get or set the TCP send buffer size used by the server. These buffers serve to accumulate outgoing data that the network stack has not yet been able to put on the wire and data that has been received from the wire but not yet read by applications. In simpler terms, if you know what you’re doing, these options allow the end-user to adjust the size of the in-kernel TCP buffers to optimize network performance. As an aside, these options do not directly adjust the TCP window size (see TCP Windows and Window Scaling for more information).
Note that internally, TCP actually allocates twice the size of the buffer requested (using the extra space for internal purposes. This is why AXA returns a buffer size that is twice the size requested. The minimum size is 1024 and the maximum is 262142. Only sratool support this option for TCP-based connections.
sratool
With sratool, getting and setting the window size is easy:
$ sratool
sra> connect ...
sra> window
* OPTION bufsize=262142
sra> window 8192
* OPTION bufsize=16384Accounting
AXA has a series of server-side packet counters used to track traffic totals. This is the mechanism by which AXA tracks, logs, and communicates server-side packet information. This information is intended for users of SIE Remote Access (SRA).
What is Accounting?
Accounting is AXA’s way of keeping track of traffic totals. Server-side, AXA maintains a series of per-client packet counters (a full list is below). The AXA protocol message AXA_P_OP_ACCT sent from client to server is used to query this data. The feature is available from sratool via the acct command. It is also available from sratunnel via the -A command line option. Accounting messages are also logged server-side.
Accounting Glossary
The AXA accounting counters are described below.
- total-congested: Packets that were unable to be forwarded to the client due to connection issues, although it could also be client load (i.e., the connection isn’t removing data from the server fast enough, or the client isn’t reading and processing the data fast enough). Note that: high server load might increase total-missed, but it would generally decrease total-congested by throttling the input to the congested pipe / process.
- total-filtered: This is an SRA input counter. It measures packets/nmsgs that have been read on the input side (usually directly from the SIE network) and will be submitted to the filtering logic (i.e.: an AXA watch).
- total-missed: This is an SRA loss counter. It measures packets that the SRA server failed to receive on the input side either because the daemon was too busy or because they were lost during transit. This counter tracks NMSG and pcap-based loss.
- total-ratelimited: This measures packets that were dropped instead of being forwarded to the SRA client to comply with the rate limits specified for the client.
- total-sent: This measures packets that have been sent to an SRA client.
Accounting with sratool
Let’s have a look at a common sratool-based example. Here sratool is used to connect to an SRA server and a “firehose” watch is set for our popular DNS Changes channel.
$ sratool
sra> ch 214 on ; 1 wa ch=214
[watch hits omitted]This is left to run for approximately three minutes of wall clock time. Next, the output is paused and the accounting command is run.
sra> pause
* OK PAUSE output paused
sra> acct
* OK ACCOUNTING total-filtered=66360 total-missed=0 total-collected=0 total-sent=64912
total-ratelimited=0 total-congested=0- We see that 66,360 nmsg payloads were read from the SIE channel. For the watch set, this is a good approximation of the overall packet rate. Channel 214 has an average payload rate of approximately 340 payloads per second, and over this very small three minute window we observed ~369 packets/s.
- There were no missed packets. We expect there to be no packet loss on the SIE input side. If there were for such a low bandwidth channel, this would be indicative of server-side network fault or server overload.
- We see that 64,912 packets were sent from the SRA server to our sratool client. This is good and what we expected.
- Because there was no congestion or rate limiting, you may wonder why the number of sent packets is lower than the number of filtered packets. This is because when we stopped sending packets to the client, we didn’t stop the server from filtering them. SRA was still reading from the input channel but wasn’t forwarding any packets.
Accounting with sratunnel
Let’s have a look at another example, this time using sratunnel. Using the timeout utility, sratunnel is run for three minutes. It connects to the same SRA server and sets a firehose watch for the DNS Errors channel. Finally, the -A 180 -d option string instructs sratunnel to emit accounting statistics every 180 seconds, with the results are written to a file.
$ timeout 180 sratunnel -s tls:userm@sra-server,1021 -w "ch=220" -c 220 -A 180 -d
-o nmsg:file:test-220.nmsg
connecting to tls:userm@sra-server,1021
ACCOUNTING total-filtered=4183437 total-missed=44 total-collected=0 total-sent=84371
total-ratelimited=0 total-congested=4096266- This time, 4,183,437 packets were read from the SIE channel. Calculating as above, we find that this equates to approximately 23,241 payloads per second which is commensurate to channel 220’s higher average per second rate of ~24,000 payloads (it is sourced from our Passive DNS feed which has a per second payload rate of ~120,000).
- 44 packets were missed on the input side. This is a .001% rate of loss and well within acceptable limits.
- Only 84,371 packets were sent to the client. To understand why, we look at the congestion number.
- 4,096,266 packets were lost due to congestion. In this case, this high number is likely due to the fact that the client is located on the other side of the country from the SIE data center where the SRA server is located. Additionally, the client’s downstream Internet connection is just plain too slow to keep up with the high rate of channel 220.
AXA Requirements
Operating System
Linux, FreeBSD or other POSIX compliant operating systems.
Hardware
The minimum hardware requirements to get started with tools in the Advanced Exchange Access Toolkit are listed below. Depending on the amount of data being processed, the resources may need to be increased accordingly.
- 1 CPU
- 1 GB Memory
- 1 GB Disk
Network
Tools in the Advanced Exchange Access Toolkit require permitted outbound to axa-sie.domaintools.com and over TCP using port 22.
Service Entitlement
Subscribers must have purchased a SIE service entitlement from Farsight Security and have been provisioned access using a SSH key.
Installing Advanced Exchange Access Toolkit (axa-tools)
Debian
These instructions use Debian packages created, maintained and hosted by Farsight Security.
- Download the Farsight Apt signing key.
$ sudo wget -O /etc/apt/trusted.gpg.d/debian-farsightsec.gpg
https://dl.farsightsecurity.com/debian/archive.pubkey- Add the Farsight Debian repository.
$ echo "deb http://dl.farsightsecurity.com/debian bullseye-farsightsec main"
| sudo tee -a /etc/apt/sources.list.d/debian-farsightsec.list- Resynchronize the package index files.
$ sudo apt update- Install the Advanced Exchange Access Toolkit (axa-tools).
$ sudo apt install axa-toolsBuild from Source
See the section titled Building manually in the README file found on the GitHub repository for the Farsight Advanced Exchange Access Toolkit
Configuring Advanced Exchange Access with SSH
- At the time of provisioning you would have been asked to generate a SSH key pair used for authentication. The following steps will reference this key, make sure you reference the correct directory path when configuring the key.
$ ssh-keygen -t rsa -b 4096 -C farsight_security -f ~/.ssh/farsight_security- Create or edit the SSH config file with the following:
$ vim ~/.ssh/configAdd the following:
Host axa-sie.domaintools.com
IdentityFile ~/.ssh/farsight_securityInstalling nmsgtool
- If you have not already installed nmsgtool, install it via apt:
$ sudo apt install nmsgtool nmsg-msg-module-sie
