Farsight's Advanced Exchange Access, part 2 of 3
By Mike Schiffman
This is the second article in a three-part blog series intended to introduce
and acquaint the user with Farsight's AXA suite of tools and library code. This
sratool and will show useful examples of how to invoke the
tool using common use cases. This article is not an exhaustive treatise on
sratool. For that, the reader is directed to the man page and the source code.
Farsight Advanced Exchange Access
First, a recap. When we last convened, you learned about Farsight Security's
fabled Security Internet Exchange (SIE) and the arcane magic used to remotely
consume it, the Advanced Exchange Access (AXA). Interest piqued, you mused
"how can I get me some of that?". Dear reader,
sratool is how you get you
some of that. Let's learn more.
The Swiss Army knife
sratool is the AXA Swiss Army knife. It is a versatile tool used to test,
debug, inspect, or stream AXA connections. In its most common invocation,
sratool connects to an SRA server, issues a few AXA protocol messages, and
displays the responses.
So let's get to it!
Tutorial 1: Watch Newly Observed Domains
As a stalwart protector of your organization's network you've already contacted Farsight sales and signed up to receive Farsight's Newly Observed Domains (NOD) datafeed to watch newly active domains and ensure your users don't visit any newly minted – often malicious – domains. This tutorial will show you, venturesome new Farsight datafeed subscriber, how to examine the Newly Observed Domains (NOD) feed in real time. Commands and their output are listed with discussion below.
1 $ sratool 2 > connect ssh:firstname.lastname@example.org 3 * HELLO srad version 0.2.5 sra-eft AXA protocol 1 4 > 1 watch ch=211 5 1 OK WATCH started 6 > count 5 7 > channel 211 on 8 * OK CHANNEL ON/OFF channel ch211 on 9 1 ch211 SIE newdomain 10 flyinghorse-colorado.com/A: flyinghorse-colorado.com 11 1 ch211 SIE newdomain 12 treatmentforboils.com/NS: treatmentforboils.com 13 1 ch211 SIE newdomain 14 servicedeck.com/NS: servicedeck.com 15 1 ch211 SIE newdomain 16 www.markenmacher.eu/A: markenmacher.eu 17 1 ch211 SIE newdomain 18 recruitniks.com/NS: recruitniks.com 19 packet count limit exceeded 20 > count 21 packet printing stopped by count 1990 packets ago
- Lines 1-3: Invoke
sratool, and use the
connectcommand 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_HELLOmessage which was sent by the server and contains the server's software version, name, and AXA protocol verison.
Lines 4-5: Inform the server we want to
watchSIE channel 211 traffic (this is the NOD channel). The server responds with the current watch status. The
watchis the most fundamental
sratoolcommand. This is how
sratool"signs up" to receive data from the SRA server. As its name implies,
watchsets 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
sratoolallows only a single SRA connection at a time.
- Line 6: Using the
countcommand, we inform
sratoolwe only want to see 5 packets. After this number is met,
sratoolwill stop emitting packets to the screen (though traffic may still be flowing from server to client).
- Lines 7-8: With the
channelcommand, enable channel 211 (NOD). The current channel status is printed. Another fundamental command to
channel. Issued alone on the command-line, it will emit the entire list of available SIE channels for which the user is provisioned.
- Lines 9-19:
sratoolemits 5 NOD packets as it receives then from the server. Once the packet count limit is reached, emission stops.
- Lines 20-21: Issuing the
countcommand 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.
Tutorial 2: counts and limits
Continuing in the session above, let's tweak a few knobs and press a few buttons.
22 > list watches 23 1 ch=ch211 24 > 1 delete 25 1 OK STOP watch deleted 26 > rate 27 RATE LIMITS 28 unlimited per second; current value=307 29 10 seconds between reports 30 > rate 1 31 RATE LIMITS 32 1 per second; current value=2 33 10 seconds between reports
- Lines 22-23: The
list watchescommand prints all of the active watches. We've still got one going, we're just not emitting any packets to the screen.
- Lines 24-25: We delete the watch by referencing its tag with the
- Lines 26-29: Another handy command,
rateallows 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
- Lines 30-33: Using the
ratecommand, 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.
Tutorial 3: watch for a specific domain in Farsight's passive DNS feed
As a bonus, let's peek at SIE channel 202 traffic, Farsight's raw passive DNS feed.
34 > 2 watch dns=*.github.com 35 2 OK WATCH started 36 > channel 202 on 37 * OK CHANNEL ON/OFF channel ch202 on 38 2 ch202 base dnsqr response UDP_QUERY_RESPONSE 39 188.8.131.52.53 > 184.108.40.206.17296 IP TTL=58 UDP 86 bytes 40 DNS: raw.github.com IN A qr aa NOERROR 1 ans, 0 auth, 0 add RRs 41 2 ch202 base dnsqr response UDP_QUERY_RESPONSE 42 220.127.116.11.53 > 18.104.22.168.64372 IP TTL=56 UDP 153 bytes 43 DNS: api.github.com IN A qr aa cd NOERROR 1 ans, 4 auth, 0 add RRs 44 2 ch202 base dnsqr response UDP_QUERY_RESPONSE 45 22.214.171.124.53 > 126.96.36.199.52707 IP TTL=58 UDP 89 bytes 46 DNS: malsup.github.com IN A qr aa NOERROR 1 ans, 0 auth, 0 add RRs 47 * MISSED 48 lost 0 input packets, dropped 0 for congestion, 49 121 for per sec limit 50 since 2014/12/08 17:29:38 51 2 ch202 base dnsqr response UDP_QUERY_RESPONSE 52 188.8.131.52.53 > 184.108.40.206.47116 IP TTL=58 UDP 149 bytes 53 DNS: github.com IN A qr aa NOERROR 1 ans, 4 auth, 0 add RRs
- Lines 34-35: We set another watch, this time we want to watch for the
wild card domain "*.github.com". Anything matching this domain will be
emitted, such as
- Lines 36-37: We turn on channel 202, Farsight's raw passive DNS channel.
- Lines 38-53: All domains matching the watch are emitted.
This should be enough to get you started! Next week, we'll cover
We learned how to invoke
sratool, issue some fundamental commands to turn on,
off, and control the flow of SIE data.
Our next and final installment in this introductory tutorial will be a
Mike Schiffman is a Senior Distributed Systems Engineer for Farsight Security, Inc.
Read the next part in this series: Farsight's Advanced Exchange Access, part 3 of 3