Using Firepower logs for uncommon and overseen purposes

It is often overlooked that a Firepower sensor is capable of very rich logging of a lot of interesting metrics. These can beside the normal SecOps use-cases also provide valuable insight into the health of your infrastructure. You just need to tap into the dataflow.

In an earlier article I described how a simple Elasticsearch, Logstash and Kibana) ELK stack can be setup. I will use this setup throughout this article as well to describe interesting cases. FMC could of course also be used, but many operations teams already uses a seperate logging tool such as the ELK stack.

Are my web front-end working properly?

One of the most common indications of something is wrong with a web front-end is when the HTTP responses codes from the servers is starting to produce codes like 5xx. Below is a reference table with the common ranges of HTTP response codes.

1xx: InformationalCommunicates transfer protocol-level information.
2xx: SuccessIndicates that the client’s request was accepted successfully.
3xx: RedirectionIndicates that the client must take some additional action in order to complete their request.
4xx: Client ErrorThis category of error status codes points the finger at clients.
5xx: Server ErrorThe server takes responsibility for these error status codes.

The Firepower records all HTTP response codes that it sees and send these to our logging solution. Thus we can simply track this particular field with a filter for inbound only traffic.

With this representation I can see which servers are responding with different HTTP response codes.

A graph representation of over time development of the count of different error codes would be nice to have for internal system monitor (all graphical widgets can be exported from Kibana as xframes or similar). If as sudden spike begins to appear with error codes some preemptive research could be warranted.

A graph representation of over time development of the count of different HTTP response codes.

When we have pinpointed some 5xx or other interesseting non-200 codes we can drill into the concrete log message itself and see which URI ressource is misbehaving.

HTTP codes 401 and 403 are also highly interesting to monitor as these represent “unauthorized” and “forbidden”. If you start seeing these it could be an indicator of an attack or as the very least a client misconfiguration.

Am I using deprecated SSL crypto?

Old versions of SSL are both vulnerable and more insecure. Which is often why it pointed out by internal and external auditors that old versions are not sanctioned nor permitted.

Pie chart showcasing the SSL versions used on the internal servers and ciphers used

Also the ciphers used in the SSL protocol are of interest as this goes to the strength of the encryption.

Pie chart showcasing the SSL versions used on the internal servers and ciphers used

More over we can also get a view as to the health state of the certificates being used. It is generally unwise to used non-valid certificates (even if it is easier for internal system use). If you see ANY non-valid certificate being served to outside users from your servers it is a sign of misconfiguration at best.

SSL status distribution

What kind of users are connecting to my services?

The Firepower logs the user-agent field from the HTTP headers. This indicates which kind of client is connecting to our services, and thus also makes it possible for us to optimize as appropriate.

Distribution of User-Agents connecting to the web servers

It is also very interesting to see where the users of our services are located in the world. We can map this in Kibana as we have the GeoIP data associated with each log.

Using the Geo IP attributes we can map all external connecting users to countries. It could be filtered down for each individual service.

Do I have misconfigurations internally?

From experience a lot of user troubles with timeouts and sluggishness is due to systems timing out internally due to misconfigured host names in various code.

Firepower logs a lot of data coming from DNS queries and this can also be easily formatted and viewed at.

DNS relevant logs from the Firepower system

Most (arguably) interesting is the NXDOMAIN DNS response, as this indicates failures in the DNS resolution. It is furthermore a prime indicator of malware infection as these tend to use DGA (domain generating algorithms) which generate a lot of non-resolvable DNS requests. It will often show up as a spike as below.

DNS responses over time

Another place to look for misconfigurations are also in the IPS threat logs as a misconfigured system will often behave as a compromised one. Look for excessive amount of ‘false positives’ IPS alarms as these tend to be not-so-false-positives with regards to configuration.


As showcased above there is a lot of often untapped potential in the Cisco Firepower logs as these are very detailed and feature rich. I have illustrated some different use-cases here but many additional ones (most bandwidth consuming users, internal behavior analytics, servers not being utilized etc) can most likely also be thought out by others.

See the appendix of this post for a list of different fields indexed from the Firepower logs.

Be the first to comment on "Using Firepower logs for uncommon and overseen purposes"

Leave a comment

Your email address will not be published.