Farsight's Advanced Exchange Access: The Missing Manual

← Blog Home



Farsight’s 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. This article explains some of the less documented AXA features and options.

Before reading this article, it is recommended to be familiar with AXA basics and related technologies. To brush up, the following Farsight Security Blog articles are recommended reading:

AXA Subscriber Tools

Farsight freely provides several end-user tools to stream AXA data. They are:

  • sratool/radtool: The AXA Swiss Army knives, used to test / debug SRA or RAD connections and stream presentation format AXA watch hits (sratool) or AXA anomaly hits (radtool).
  • sratunnel/radtunnel: The AXA workhorses, used to tunnel binary SIE data.
  • axamd_client: Convenience tool that is a RESTful client and doubles as a Python extension library, used to stream AXA hits formatted as JSON blobs.

Many of the features and options we’ll be discussing are isomorphic amongst all of the tools and examples will be given where appropriate.

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 understands both IPv4 and IPv6 address types.

  • DNS Watches: used to express interest in SIE messages containing a specified hostname, domain, or wildcard.

  • Channel Watches: used to express interest in SIE messages from an entire 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.

When connected to a RAD server, watch tags can be reused. This is because anomaly modules are designed to be able to use multiple watches per invocation. This is accomplished by “bundling” together watches under a single 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, are in the CIDR block 192.168.0/24, or are in the *.farsightsecurity.com domain.


The end-user specifies a unique tag per watch:

$ sratool
sra> connect ...
sra> 1 watch ip=
sra> 2 watch ip=192.168.0/24
sra> 3 watch dns=*.farsightsecurity.com
sra> channel 204 on


With sratunnel, tags are generated internally so the end-user only needs to specify the -w option and the assets above:

$ sratunnel -w ip= -w ip=192.168.0/24 -w dns=\*.farsightsecurity.com -s ... -o ... -c 204


With axamd_client, tags are also internally generated so the invocation is similar to sratunnel’s:

$ axamd_client --watches ip= ip=192.168.0/24 dns=\*.farsightsecurity.com --channels 204
AXA Watch Examples: RAD

The end-user wishes to invoke the domain_sentry service (which is delivered through RAD) and ensure the DNS name www.farsightsecurity.com always has the A record and the AAAA record 2620:11c:f004:0:0:0:0:104.


The end-user specifies the watches as in the sratool example above, but notice this time the watches are bundled using the same tag. This is to let the RAD server know that “all of these watches are to be used with the domain_sentry service invocation with the same tag”.

$ radtool
rad> connect ...
rad> 1 watch ip=
rad> 1 watch ip=2620:11c:f004:0:0:0:0:104
rad> 1 watch dns=www.farsightsecurity.com
rad> 1 anomaly domain_sentry types=a,aaaa


With radtunnel, tags are generated internally so the end-user only needs to specify the -w option and the IP asset as above.

$ radtunnel -w ip= -w ip=2620:11c:f004:0:0:0:0:104 -w dns=www.farsightsecurity.com -s ... -o ...


With axamd_client, as above, tags are also generated internally:

$ axamd_client --watches ip= ip=192.168.0/24 dns=www.farsightsecurity.com --anomalies domain_sentry types=a,aaaa

Rate Limiting

Rate limiting is used to limit the rate of incoming AXA messages as emitted from the server to the client. While it works for both SRA and RAD, it is primarily useful for high bitrate SIE channels such as the Passive DNS Channel Package channels and 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.


With sratool, the end-user has the option to receive rate limit loss reports. As such, she specifies a rate limit value of 10 and a 5 second interval between server rate limit reports:

$ sratool
sra> connect ...
sra> rate 10 5
    10 per second; current value=0
    5 seconds between reports
sra> 1 watch ch=204
sra> channel 204 on
    missed 0 input packets, dropped 0 for congestion,
    dropped 57911 for rate limit, filtered 72417
    since 2016/10/11 14:25:32


With sratunnel (or radtunnel), rate limiting is specified as a simple command line option:

$ sratunnel -r 10 -w ch=204 -s ... -o ... -c 204


With axamd_client, like sratunnel, rate limiting is specified as a command line option:

$ axamd_client --rate-limit 10 --watches ch=204 --channels 204

Loss reports are not available with sratunnel, radtunnel, or axamd_client.


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 50% sample of the messages its watches catch. Enabling sampling with any of the tools is quite straightforward.


$ sratool
sra> connect ...
sra> sample 50
* OPTION sample 50.00%


$ sratunnel -m 50 -s ...


$ axamd_client --sample-rate 50 ...

TCP Buffer Sizing

AXA allows the end-user to get or set the TCP send buffer size used by the server. As described here, these buffers serve to accumulate outgoing data that the 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 your application respectively. 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 presumably with the goal of optimizing network performance. As an aside, these options do not directly adjust the TCP window size.

Note that internally TCP actually allocates twice the size of the buffer requested (using the extra space for administrative purposes and internal kernel stuff. This is why when you set a value, AXA returns to you a buffer size that is twice the size you requested. The minimum size is 1024 and the maximum is 262142. Only sratool and radtool support this option for TCP-based connections.


With sratool, getting and setting the window size is easy:

$ sratool
sra> connect ...
sra> window
* OPTION bufsize=262142
sra> window 8192
* OPTION bufsize=16384


AXA has a series of server-side packet counters used to track traffic totals. They are fully described in Farsight’s Advanced Exchange Access Internals: Understanding Accounting.


Requesting accounting totals with sratool:

$ sratool
sra> connect ...
sra> acct
* OK ACCOUNTING total-filtered=113564 total-missed=0 total-collected=0 total-sent=1 total-ratelimited=0 total-congested=0


With sratunnel, accounting totals can be synchronously emitted to stdout every five seconds with the following:

$ sratunnel -d -A 5 -s ...
ACCOUNTING total-filtered=4247 total-missed=0 total-collected=0 total-sent=1356 total-ratelimited=0 total-congested=817

(The -d option enables debug mode which is required to see accounting output.)


With axamd_client, accounting totals are sent by default every 60 seconds. This value is tunable using the --report-interval option:

axamd_client --report-interval 10 ...
{"tag":"*","op":"OK","orig_op":"ACCOUNTING","str":"total-filtered=2912 total-missed=0 total-collected=2912 total-sent=0 total-ratelimited=0 total-congested=0"}

Commands File

Both sratool and radtool provide a convenience option that enables the end-user to specify commands to run prior to command invocation. This feature provides the end-user with a simple mechanism to script commonly used commands. A commands file is a text file with valid newline-delimited sratool or radtool commands.

A common example is to script the connection procedure. In the following example, we setup a commands file that will connect to a RAD server and list the anomaly modules we are provisioned for:

cat > radtool.cmd
connect tls:user@axa-server,1022
list anomalies
$ radtool -c radtool.cmd
* HELLO radd version 1.4.1 axa-server AXA protocol 1
      * domain_sentry        [10/10]
      * brand_sentry         [5/5]

The output of the list anomalies command presents the end-user with the list of currently provisioned anomaly modules as well as the number of available domains and IP prefixes for domain_sentry and the number of available brands for brand_sentry.

Mike Schiffman is a personal packet shopper for Farsight Security, Inc.

← Blog Home

Protect against cybercriminal activity in real-time.

Request demo

Email: sales@farsightsecurity.com Phone: +1-650-489-7919