Solved

Logging allowed/blocked traffic on Cisco ASA Firewall

Posted on 2014-09-29
3
4,878 Views
Last Modified: 2014-10-28
When you enable logging on a global access rule on a cisco ASA firewall, you should see all traffic that is matching the rule in the logs, or are there any limitations? (for example, for blocked/allowed traffic or for traffic destined to the firewall itself)

I Added a test rule (rule 1 in rule base) on our ASA and I Telnet to a random destination port to the IP address of the firewall's interface, but I cannot see tha traffic in logs. I Also tried to filter the logs using the rule ID, but I dont see anything. However, I can see the packets when I do a packet capture. am I missing something?

thanks,
0
Comment
Question by:Harrris
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
3 Comments
 
LVL 64

Accepted Solution

by:
btan earned 500 total points
ID: 40351390
Good to check these out

Access List Activity Logging - http://www.ciscopress.com/articles/article.asp?p=424447&seqNum=3

Here are rules of thumb to follow when choosing a severity level:
If only firewall error conditions should be recorded and no one will regularly view the message logs, choose severity level 3 (errors).
If you are primarily interested in seeing how traffic is being filtered by the firewall access lists, choose severity level 4 (warnings).
If you need an audit trail of firewall users and their activity, choose severity level 5 (notifications).
If you will be using a firewall log analysis application, you should choose severity level 6 (informational). This is the only level that produces messages about connections that are created, as well as the time and data volume usage.
If you need to use any debug command to troubleshoot something on the firewall, choose a destination with severity level 7 (debugging). You can use the logging debug-trace command to force debug output to be sent to a logging destination for later review. All Syslog messages containing debug output use message ID 711001 at a default severity level of 7.

By default, logging message 106023 (default severity level 4, warnings) is generated when a deny access list entry is matched with a traffic flow. Only the overall ACL is listed in the message, with no reference to the actual denying ACL entry

Each unique traffic flow that is denied by an ACE configured for logging is added to a cached list of tracked flows. This usually isn't a problem unless something like a denial-of-service attack causes a very large number of flows to be denied and tracked.

The firewall limits the maximum number of denied flows it tracks. By default, the maximum number is based on the available firewall memory: 4096 (64 MB or more), 1024 (16 MB or more), or 256 (less than 16 MB).

You can change this to a lower maximum number of flows by specifying n (1 to the default maximum). When the maximum number of tracked flows is reached, the firewall generates logging message 106101. By default, this message is limited to appearing only every 300 seconds (5 minutes). You can change the alert interval to seconds (1 to 3600 seconds).

in summary, when you enable logging, if a packet matches the access rule, the ASA creates a flow entry to track the number of packets received within a specific interval. The ASA generates a system log message at the first hit and at the end of each interval, identifying the total number of hits during the interval and reporting the time of the last hit.

The ASApane displays the hit count information in the “last rule hit” row. To view the rule hit count and timestamp, chooseConfiguration > Firewall > Advanced > ACL Manager, and hover the mouse pointer over a cell in the ACL Manager table.

http://www.cisco.com/c/en/us/td/docs/security/asa/asa91/asdm71/firewall/asdm_71_firewall_config/access_rules.html#pgfId-1274679
0
 
LVL 3

Expert Comment

by:Johneil1
ID: 40408374
very well put btan.
0

Featured Post

2017 Webroot Threat Report

MSPs: Get the facts you need to protect your clients.
The 2017 Webroot Threat Report provides a uniquely insightful global view into the analysis and discoveries made by the Webroot® Threat Intelligence Platform to provide insights on key trends and risks as seen by our users.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

For months I had no idea how to 'discover' the IP address of the other end of a link (without asking someone who knows), and it drove me batty. Think about it. You can't use Cisco Discovery Protocol (CDP) because it's not implemented on the ASAs.…
You deserve ‘straight talk’ from your cloud provider about your risk, your costs, security, uptime and the processes that are in place to protect your mission-critical applications.
As a trusted technology advisor to your customers you are likely getting the daily question of, ‘should I put this in the cloud?’ As customer demands for cloud services increases, companies will see a shift from traditional buying patterns to new…
Both in life and business – not all partnerships are created equal. Spend 30 short minutes with us to learn:   • Key questions to ask when considering a partnership to accelerate your business into the cloud • Pitfalls and mistakes other partners…

632 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question