[cisco-bba] ACLs on Virtual-Access templates
Frank Bulk
frnkblk at iname.com
Tue Feb 3 09:58:11 EST 2009
Arie:
Thanks for confirming that ACLs run first.
I do have the ACL applied:
interface Virtual-Template1
mtu 1492
ip unnumbered Loopback11
ip verify unicast source reachable-via rx 126
ip mtu 1492
ip tcp adjust-mss 1452
no logging event link-status
peer default ip address dhcp
ppp mtu adaptive
ppp authentication pap
ppp ipcp dns a.b.c.d e.f.g.h
end
access-list 126 deny ip any any log
but it's not logging.
Does anyone else have uRPF applied to a Virtual-Template and have logging
working?
Frank
From: Arie Vayner [mailto:arievayner at gmail.com]
Sent: Tuesday, February 03, 2009 2:02 AM
To: Frank Bulk
Cc: cisco-bba at puck.nether.net
Subject: Re: [cisco-bba] ACLs on Virtual-Access templates
Frank,
I checked and ingress ACL is the 1st feature evaluated, so it makes sense.
For logging, I think the feature is there.
Take a look in the command reference for uRPF:
http://www.cisco.com/en/US/docs/ios/ipswitch/command/reference/isw_i1.html#w
p1013117
It has this text:
Unicast RPF events can be logged by specifying the logging option for the
ACL entries used by the Unicast Reverse Path Forwarding command. Log
information can be used to gather information about the attack, such as
source address, time, and so on.
So you should specify an ACL on the uRPF config with the log entry for any
relevant entries. Anything you permit on the ACL will be an exception to
uRPF. Anything denied would be dropped if uRPF fails (and only then).
Arie
On Tue, Feb 3, 2009 at 9:31 AM, Frank Bulk <frnkblk at iname.com> wrote:
Arie:
I did some hunting around and the only stuff I did see showed that uRPF is
processed before ACLs, so I'm a bit confused in that regard. If you can
verify, that would be appreciated.
Using some debug commands I did identify a PPPoA connection that was
spoofing traffic. I removed off the inbound ACL on the Virtual-Template and
I see that the strict uRPF is working:
Router#sh ip interface Vi1.1120 | inc verif
IP verify source reachable-via RX
214 verification drops
0 suppressed verification drops
0 verification drop-rate
Today I tried adding logging to uRPF:
interface Virtual-Template1
mtu 1492
ip unnumbered Loopback11
ip verify unicast source reachable-via rx 126
ip mtu 1492
ip tcp adjust-mss 1452
no logging event link-status
peer default ip address dhcp
ppp mtu adaptive
ppp authentication pap
ppp ipcp dns a.b.c.d e.f.g.h
end
access-list 126 deny ip any any log
Unfortunately, it does not appear to be logging anything. There's no 126
lines, and I know that there's spoofed traffic coming through. I re-applied
my inbound ACL on the Virtual-Template, and I immediately saw this:
Feb 3 01:27:45.326 CST: %SEC-6-IPACCESSLOGP: list 125 denied tcp
10.0.0.2(53070) -> 189.92.5.249(16016), 1 packet
Feb 3 01:27:46.482 CST: %SEC-6-IPACCESSLOGP: list 125 denied tcp
10.0.0.2(52461) -> 24.82.113.224(22019), 1 packet
It's strange.
In regards to how I would like ACL-based logs to be documented; here's a
typical log entry:
Jan 31 15:23:21 a.b.c.d 38279: Jan 31 15:23:20.964 CST: %SEC-6-IPACCESSLOGP:
list 125 denied udp 80.212.149.228(55190) -> 192.168.0.0(19427), 1 packet
Jan 31 15:23:32 a.b.c.d 38287: Jan 31 15:23:31.476 CST: %SEC-6-IPACCESSLOGP:
list 125 denied tcp 222.172.244.3(2047) -> 192.168.0.0(19427), 1 packet
Jan 31 15:23:33 a.b.c.d 38288: Jan 31 15:23:32.784 CST: %SEC-6-IPACCESSLOGP:
list 125 denied udp 151.48.173.200(25235) -> 192.168.0.0(19427), 1 packet
Jan 31 15:23:36 a.b.c.d 38290: Jan 31 15:23:34.884 CST: %SEC-6-IPACCESSLOGP:
list 125 denied udp 58.108.93.71(13502) -> 192.168.0.0(19427), 1 packet
The feature request would be to log the interfaces, something like this:
Jan 31 15:23:21 a.b.c.d 38279: Jan 31 15:23:20.964 CST: %SEC-6-IPACCESSLOGP:
list 125 denied udp 80.212.149.228(55190) [ATM4/0.100 1/405 Vi1.1120] ->
192.168.0.0(19427) [Fa0/1], 1 packet
Jan 31 15:23:21 e.f.g.g 38281: Jan 31 15:23:21.123 CST: %SEC-6-IPACCESSLOGP:
list 125 denied udp 199.120.70.3(55190) [Fa0/1] -> 192.168.0.0(19427)
[ATM4/0.100 1/899 Vi1.923], 1 packet
Regards,
Frank
From: Arie Vayner [mailto:arievayner at gmail.com]
Sent: Sunday, February 01, 2009 1:19 AM
To: Frank Bulk
Cc: cisco-bba at puck.nether.net
Subject: Re: [cisco-bba] ACLs on Virtual-Access templates
Frank,
So, just to be sure - if you remove the ACL, does uRPF work as it should?
I would assume (I don't have the time right now to make sure) that the ACL
is evaluated before as it is part of the ingress packet processing, while
uRPF is done later (close to the time when you also do a route lookup).
Therefore, it would make sense for the ACL to take precedence.
With regards to the log message, can you show me some example of what you
actually get? I can then try and see if we can file an enhancement request.
Thanks
Arie
On Sun, Feb 1, 2009 at 6:58 AM, Frank Bulk <frnkblk at iname.com> wrote:
Just to add to that, is there a way that the Virtual-interface that's doing
the spoofing can be identified? The log entries for the ACL hits don't show
anything but the spoofed IP, but I don't know which connection is doing it.
Perhaps it's one PPPoA/E connection that's generating those spoofed packets.
Frank
From: Arie Vayner [mailto:arievayner at gmail.com]
Sent: Saturday, January 31, 2009 3:49 PM
To: Frank Bulk
Cc: cisco-bba at puck.nether.net
Subject: Re: [cisco-bba] ACLs on Virtual-Access templates
Frank,
uRFP should be the right way to block packets from the client as a source...
After you connect, do you see the uRPF feature enabled on the Virtual-Access
(show run interface and show ip interface)?
Arie
On Sat, Jan 31, 2009 at 11:35 PM, Frank Bulk <frnkblk at iname.com> wrote:
Is there a way to build an ACL on a Virtual-Access template such that the
connection can only use the IP address given to it by IPCP?
I applied strict uRPF to the Virtual-Access template, but that didn't stop
this kind of traffic:
Jan 31 15:23:21 a.b.c.d 38279: Jan 31 15:23:20.964 CST: %SEC-6-IPACCESSLOGP:
list 125 denied udp 80.212.149.228(55190) -> 192.168.0.0(19427), 1 packet
Jan 31 15:23:32 a.b.c.d 38287: Jan 31 15:23:31.476 CST: %SEC-6-IPACCESSLOGP:
list 125 denied tcp 222.172.244.3(2047) -> 192.168.0.0(19427), 1 packet
Jan 31 15:23:33 a.b.c.d 38288: Jan 31 15:23:32.784 CST: %SEC-6-IPACCESSLOGP:
list 125 denied udp 151.48.173.200(25235) -> 192.168.0.0(19427), 1 packet
Jan 31 15:23:36 a.b.c.d 38290: Jan 31 15:23:34.884 CST: %SEC-6-IPACCESSLOGP:
list 125 denied udp 58.108.93.71(13502) -> 192.168.0.0(19427), 1 packet
Those source IPs aren't mine, and are targeting an RFC1918 address. I'm
blocking traffic originating from my PPPoA/E customers that use a source IP
address outside my netblock or are targeting an RFC198 address using an
inbound ACL on the Virtual-Access template, but it doesn't stop a a customer
from spoofing their neighbor's IP address.
I've had a basic ACL in place on our internet-facing Ethernet port (Cisco
7206VXR with NPE-400) for a long time, but I didn't having anything in place
to block RFC 1918 addresses. I could have applied the rules to the ACL on
the Ethernet interface, but I've been told to apply an ACL as close as
possible to the source of the traffic.
To further complicate matters, I also use this router to route RFC 1918
space for corporate needs. I keep that "separate" by using source-based
routing, but that didn't prevent PPPoA/E customers from sending a packet to
the RFC 1918 space, even if the return packet never got back to them.
Perhaps I should use a VRF for handling corporate, traffic, except that I've
never done that before and I would need to spend some time learning.
Frank
_______________________________________________
cisco-bba mailing list
cisco-bba at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-bba/attachments/20090203/c1c88b6b/attachment-0001.html>
More information about the cisco-bba
mailing list