How to check what the 'hits' are on a firewall rule

Answered Question
Jul 18th, 2011

Hi All,

I need some assistance trying to see what the actual hits are on a specific ruleset on a ASA firewall.

We created a rule required by the server engineers for specific services and ports required. However they were still not able to access or login even though we added the specified ports.

We then created a rule below that matching the first rule but allowed ip/any and the service now works and we see lots of hits on the second ip/any rule.

How can we actually see what the hits are, like source and destination IP's, ports etc?

We do have a syslog server in the environment but this logs actual ASA logs, how do we see the hits on the actual rule?

Thanks

ZS

I have this problem too.
1 vote
Correct Answer by Anonymous about 4 years 1 week ago

No no, in the asdm you needed to select the debugging level, by default in cli, if you dont mention the logging level, it takes informational.

You can just give the command that i gave you in the CLI, that woudl set it to informational, or else use the logging level as 7, whihc is for debugging.

do a '?' after log option, it would make it clear.

-Varun

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
varrao Mon, 07/18/2011 - 07:06

Hi Zayed,

You can use the log option after the ACL:

something like this,

access-list test permit ip any any log interval 1

this will give you all the traffic hitting this acl, in the syslogs.

Thanks,

Varun

Zubair.Sayed_2 Mon, 07/18/2011 - 07:09

Thanks Varun.

I am using the ASDM, there is a logging option in the ASDM, however which option do I select as there are a few choices.

Secondly when I enable logging will this log to syslog server the events of a rule and what is hitting the rule?

varrao Mon, 07/18/2011 - 07:13

Hi Zubair,

What you can do is, go to te access-rule in the ASDM, right click on the ACL taht you have created, go to "show logg", the ASDM real-time log viewer window would pop up, there you can see what all traffic, for what ports is hitting the ACL. Then you can configure the ACL based on the ports on which teh request is arriving.

Hope this helps.

Varun

Zubair.Sayed_2 Mon, 07/18/2011 - 07:18

Varun.

I have tried that as well, that shows the actual ASA log not the rule. I apply a filter to the log and dont see any of the server IP's etc however I see my system IP that I use to remote to the ASA etc.

Jennifer Halim Mon, 07/18/2011 - 07:09

You will only see the hitcounts on the ACL if the traffic matches perfectly with the ACL.

The reason why allowed ip/any works is because the traffic might require multiple services and ports configured, and possibly there might be more ports required to be opened then what you have created initially.

To see what is actually passing through between a specific source and destination IP, I would suggest that you run a packet capture on the specific interface, create ACL to only match the specific souce and destination IP Address, and send the traffic through. The packet capture will show you everything that pass through the ASA between the specified souce and destination IP address, and you will be able to tell what other ports you might be missing.

Hope this helps.

Zubair.Sayed_2 Mon, 07/18/2011 - 07:12

Jennifer,

My thoughts exactly, we are not receiving complete information as to what ports and services are required. We tried packet capture as well. We managed to get it working but my question still remains as to how I see what the actual hits are on a rule, any rule for that matter.

Thanks

Z

Jennifer Halim Mon, 07/18/2011 - 07:16

As Varun advised earlier, you can add the "log" keywords on the ACL, and that will send a syslog message.

However, it will only log what you have configured on the ACL.

For example:

If your ACL says: permit tcp host x.x.x.x host y.y.y.y eq 3500

It will only give you hitcount and logs if the traffic that you are sending is exactly from host x.x.x.x to host y.y.y.y on TCP/3500.

If your ACL says: permit ip any any

Then it will give you hitcount on any source and any destination on any protocols.

Zubair.Sayed_2 Mon, 07/18/2011 - 07:21

Can I only apply logging to using the CLI?

I would like to apply the logging using the ASDM, I select logging and didnt see any syslog alerts.

These are the options available in the ASDM logging: default, alerts, emergency, critical, errors, warnings, notifications, informational, debugging...

varrao Mon, 07/18/2011 - 07:43

You would need to select the logging level as well, keep it to debugging and then you should be able to see it.

-Varun

Zubair.Sayed_2 Mon, 07/18/2011 - 07:45

Thanks Varun.

So I set the access-list rule to 'log' in the cli and set it to debugging?

Or can I just set the rule to 'debugging' in ASDM?

Correct Answer
varrao Mon, 07/18/2011 - 07:52

No no, in the asdm you needed to select the debugging level, by default in cli, if you dont mention the logging level, it takes informational.

You can just give the command that i gave you in the CLI, that woudl set it to informational, or else use the logging level as 7, whihc is for debugging.

do a '?' after log option, it would make it clear.

-Varun

Zubair.Sayed_2 Tue, 07/19/2011 - 00:41

Varun,.

I set the logging to debugging and received not 1 alert in syslog for the rule.

I still cant see what IP's are hitting the rule?

Jim Cook Tue, 12/31/2013 - 07:35

Hello,

I was having a similar issue and this thread led me in the right direction. I know it's probably a little late since this post was over 2 years ago but I wanted to share in case anyone else is stuck.

In ASDM I was able to right click the rule, check enable logging, and set the logging level to Debugging. I then set the logging level for syslog to debugging. On the rule I right clicked and selected "show log". From the real-time log view the rule marker automaticall populated in the filter by box (ex. 0xbad3f8d). I took this marker and searched through our syslog server for it. The entries with the marker matched the hits on the firewall.

I hope this helps!







Actions

This Discussion

Related Content