TCP Accepted Layer 7 Query in Rest API

Product Questions
#1

I am currently working on extracting the Layer 7 details for a specific Tag and the extract is working well, accept for I want to combine the data from tcp accepted IP and tcp accepted layer 7, so I assumed perhaps incorrectly that I could use the IP address as a Key in the Post for /metrics/Total however it did not seem to generate results, is this because the IP Address is not a key when working with the tcp_app_detail metric_catalog.

If it isn’t is there a way that I can look up what the available keys are, as they are listed in the Catalog.

The post I am making:
{
“from”: -604800000,
“until”: 0,
“metric_category”: “tcp_app_detail”,
“metric_specs”: [
{
“name”: “accepted”,
“key1”: “IP Address”
}
],
“object_type”: “device”,
“object_ids”: [
001,
002
],
“cycle”: “auto”
}

The Response;
{
“cycle”: “1hr”,
“node_id”: 4,
“clock”: 1669658400000,
“from”: 1669053600000,
“until”: 1669658400000,
“stats”: [
{
“oid”: -1,
“time”: 1669658400000,
“duration”: 608400000,
“values”: [
[]
]
}
]
}

#2

Hi Steven, great questions! I would be interested in knowing more about what you’re doing, as there may be other built-in, or custom options.

When using keys, it is filtering on the detail metrics for that specific base metric.

e.g. with your tcp_app_detail example, if you POST with no key filtering:

{
    "cycle": "auto",
    "from": "-1d",
    "metric_category": "tcp_app_detail",
    "metric_specs": [
        {
            "name": "accepted"
        }
    ],
    "object_ids": [
        1,
        2,
        3
    ],
    "object_type": "device",
    "until": 0
}

In the response, under values, there are string or ip values which you would filter on.

{
  "cycle": "5min",
  "node_id": 0,
  "clock": 1669703400000,
  "from": 1669617000000,
  "until": 1669703400000,
  "stats": [
    {
      "oid": -1,
      "time": 1669703400000,
      "duration": 86700000,
      "values": [
        [
          {
            "key": {
              "key_type": "string",
              "str": "tcp:42004"
            },
            "vtype": "count",
            "value": 1
          },

Those unfiltered API requests are also good way to explore beyond the metric catalog. Another way is Dashboarding the metric in a chart, it provides a similar view without needing to make test API calls, that can be a good place to get ideas on what metric values your environment is generating that you’d like to filter on.

e.g. key filter request for tcp_app_detail:

    "metric_specs": [
        {
            "name": "accepted",
            "key1": "tcp:42004"
        }

You can also regex here which can be quite useful for broader filtering, e.g. “key1”: “/kerberos/”

#3

Hi @girardo thanks for your response.

So in answer to your question I am already using tcp_app_detail to retrieve the ports accepted by the devices.

But what I was aiming for was to include the IP Address/Device that the connection originated from.

The aim was to build a model of what applications (All of our devices where possible are tagged with the application from our CMDB) are talking to each other and on what port to start refining our firewall rule base.

I did experiment with conversations in dashboards just now, but that did not give any results I would of expected.

Maybe there is another way I can do this I just haven’t found it yet.

#4

Thank you, that makes sense.

Have you looked at Activity Maps? You could create an Activity Map using the Device Group matching the Tag as the source. Then either use that as a visual representation, or query the saved activity map from API.

That Activity Map API query gets a lot of what you’re looking for in response, showing peers and protocols. It will also give you all the ExtraHop Device API IDs in the from<->to conversation, which makes it a good first query target.

Many options from there, could do something like use all the returned Device IDs, and iterate through them to your other desired API calls for metric queries, device queries, etc…gathering all the information locally which is not normally returned in any one specific endpoint query.

Conversely, you could build a Trigger, assign it to the Tagged device group, and code it to commit a custom device metric. application metric, or a custom record, that concatenates the specific data sets you want. Some saved record queries using the built-in record types may work as well.

links in case helpful,

Please let me know what you think, Happy New Year!