Have you tried enablind IP accounting for access violations? That should help in this case.
-- Marko Milivojevic - CCIE #18427 Senior Technical Instructor - IPexpert YES! We include 400 hours of REAL rack time with our Blended Learning Solution! Mailto: [email protected] Telephone: +1.810.326.1444 Fax: +1.810.454.0130 Web: http://www.ipexpert.com/ On Thu, Jul 8, 2010 at 18:01, Jimmy Larsson <[email protected]> wrote: > Maybe this is more an r/s-question. Anyone able to shed some light on this? > Short story: when blocking traffic on a router-interface with access-group > and the deny-statement has the log option, most of the blocked traffic is > logged with a periodic interval and does not include individual port > numbers. But my gut feeling is that sometimes the log output displays the > actual port-numers instead of zeros and I cant really define when and why. > Please see below. > Br Jimmy > > ---------- Forwarded message ---------- > From: Jimmy Larsson <[email protected]> > Date: 2010/7/8 > Subject: Re: [OSL | CCIE_Security] IOS interface access-list blocking what? > To: Pieter-Jan Nefkens <[email protected]> > Cc: OSL Security <[email protected]> > > > PJ! > You are so right. These log messages comes periodically. I left the console > untouched for a while and examined the output. It turns out that it logs > each every 5 minutes per src-dst-pair per protocol to summarize them. Look > at these entries and their time stamps: > *Jul 8 08:23:41.035: %SEC-6-IPACCESSLOGP: list FW denied udp > 192.168.1.203(0) -> 192.168.1.255(0), 10 packets > *Jul 8 08:28:41.035: %SEC-6-IPACCESSLOGP: list FW denied udp > 192.168.1.203(0) -> 192.168.1.255(0), 10 packets > *Jul 8 08:33:41.035: %SEC-6-IPACCESSLOGP: list FW denied udp > 192.168.1.203(0) -> 192.168.1.255(0), 10 packets > *Jul 8 08:23:41.035: %SEC-6-IPACCESSLOGP: list FW denied udp > 192.168.1.50(0) -> 255.255.255.255(0), 20 packets > *Jul 8 08:28:41.035: %SEC-6-IPACCESSLOGP: list FW denied udp > 192.168.1.50(0) -> 255.255.255.255(0), 20 packets > *Jul 8 08:33:41.035: %SEC-6-IPACCESSLOGP: list FW denied udp > 192.168.1.50(0) -> 255.255.255.255(0), 20 packets > *Jul 8 08:38:41.035: %SEC-6-IPACCESSLOGP: list FW denied udp > 192.168.1.50(0) -> 255.255.255.255(0), 20 packets > > I guess this can be tuned with the ip access-list log commands. I have tried > tweaking them abit but so far I havent been able to make the router log each > and every denied packet (which, i guess, is when we actually see individual > ports for each packet). > R1(config)#ip access-list log-update ? > threshold Set access-list logging threshold > R1(config)#ip access-list logging ? > hash-generation Enable syslog hash code generation > interval Set access list logging interval > Anyone? > > 2010/7/8 Pieter-Jan Nefkens <[email protected]> >> >> Hi jimmy, and others, >> A bit of guessing here, but you should be able to verify it.. >> Could it be, that just like the ips, the log messages are rate limited and >> are escalating on ip-level to reduce the number of log messages and thus not >> overload the router / control plane? Just like ips signatures can be >> summarized to limit the number of events? >> I mean, we have the option for rate-limiting the log messages, this could >> be an internal escalation sort of level to not log individual packets if >> there's too much logging, but escalates to source and destination ip >> address. >> You could test it with a router and start to generate more traffic.. >> Just an idea.. >> Pieter-Jan >> Sent from my iPad >> On 8 jul. 2010, at 08:59, Jimmy Larsson <[email protected]> wrote: >> >> I dont get it. A few minutes later my log entries starts to look like >> this: >> *Jul 8 07:03:40.147: %SEC-6-IPACCESSLOGP: list FW denied udp >> 192.168.1.51(1645) -> 192.168.1.61(1645), 1 packet >> *Jul 8 07:03:48.483: %SEC-6-IPACCESSLOGP: list FW denied udp >> 192.168.1.203(17500) -> 255.255.255.255(17500), 1 packet >> And this, the very same outside to inside telnet-attempt as in my last >> email: >> *Jul 8 07:05:11.691: %SEC-6-IPACCESSLOGP: list FW denied tcp >> 192.168.1.52(4229) -> 192.168.169.2(23), 1 packet >> Please help me explain why... >> /J >> 2010/7/8 Jimmy Larsson <[email protected]> >>> >>> Guys >>> How do you guys handle this situation? You have a router with an inbound >>> acl in outside interface that is blocking things: >>> interface FastEthernet0 >>> descr Outside interface >>> ip address 192.168.1.61 255.255.255.0 >>> ip access-group FW in >>> ! >>> ip access-list extended FW >>> deny ip any any log >>> ! >>> No inspection, no zbfw, nothing. The problem is that the log-entry in the >>> access-list doesnt show me enough details of what is being blocked. >>> A few examples: >>> Return traffic for outbound radius: >>> *Jul 8 06:55:41.035: %SEC-6-IPACCESSLOGP: list FW denied udp >>> 192.168.1.51(0) -> 192.168.1.255(0), 8 packets >>> Telnet traffic from outside host to inside router: >>> *Jul 8 06:56:56.567: %SEC-6-IPACCESSLOGP: list FW denied tcp >>> 192.168.1.52(0) -> 192.168.169.2(0), 1 packet >>> Garbage broadcast from a windows-host on outside: >>> *Jul 8 06:58:41.035: %SEC-6-IPACCESSLOGP: list FW denied udp >>> 192.168.1.50(0) -> 192.168.1.255(0), 11 packets >>> How do I find out port details about the blocked traffic so that I can >>> open them up (or not)? I know, it looks different when doing inspections. >>> /J >>> -- >>> ------- >>> Jimmy Larsson >>> Ryavagen 173 >>> s-26030 Vallakra >>> Sweden >>> http://blogg.kvistofta.nu >>> ------- >> >> >> >> -- >> ------- >> Jimmy Larsson >> Ryavagen 173 >> s-26030 Vallakra >> Sweden >> http://blogg.kvistofta.nu >> ------- >> >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com > > > > -- > ------- > Jimmy Larsson > Ryavagen 173 > s-26030 Vallakra > Sweden > http://blogg.kvistofta.nu > ------- > > > > -- > ------- > Jimmy Larsson > Ryavagen 173 > s-26030 Vallakra > Sweden > http://blogg.kvistofta.nu > ------- > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > > _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
