Mailing List Archive

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@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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-bba
>

Hi Frank,

Unicast Reverse Path Forwarding might achieve what you are trying to do.

I'll the links explain it better than I can :)

http://en.wikipedia.org/wiki/URPF
http://www.cisco.com/en/US/docs/ios/12_1t/12_1t2/feature/guide/rpf_plus.html

Now might be a good time to start doing some reading about VRF, even if you don't implement it straight away.



regards,
Tony.

--- On Sun, 1/2/09, Frank Bulk <frnkblk@iname.com> wrote:

> From: Frank Bulk <frnkblk@iname.com>
> Subject: [cisco-bba] ACLs on Virtual-Access templates
> To: cisco-bba@puck.nether.net
> Date: Sunday, 1 February, 2009, 8:35 AM
> 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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-bba




_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

Yes, I think it's all on. Here's some output on my own connection. I
didn't have to drop my PPPoE link for it to show up.



Perhaps the ACL has precedence over the uRPF, and that's why I'm seeing it
logged and blocked there instead of via uRPF?



Router#sh user | inc fbulk

Vi3.72 fbulk PPPoE - b.c.d.e

Router#sh run int vi3.72

Building configuration...



Current configuration : 153 bytes

!

interface Virtual-Access3.72

ip access-group 125 in

ip verify unicast source reachable-via rx

ip tcp adjust-mss 1452

no snmp trap link-status

end



Router#sh int Vi3.72 configuration

Virtual-Access3.72 is a PPP over Ethernet link (sub)interface



Derived configuration : 292 bytes

!

interface Virtual-Access3.72

ip unnumbered Loopback11

ip access-group 125 in

ip verify unicast source reachable-via rx

ip tcp adjust-mss 1452

peer default ip address dhcp

no snmp trap link-status

ppp mtu adaptive

ppp authentication pap

ppp ipcp dns a.b.c.d e.f.g.h

end



Router#sh ip interface Vi3.72

Virtual-Access3.72 is up, line protocol is up

Interface is unnumbered. Using address of Loopback11 (b.c.d.1)

Broadcast address is 255.255.255.255

Peer address is b.c.d.e

MTU is 1492 bytes

Helper address is not set

Directed broadcast forwarding is disabled

Outgoing access list is not set

Inbound access list is 125

Proxy ARP is enabled

Local Proxy ARP is disabled

Security level is default

Split horizon is enabled

ICMP redirects are always sent

ICMP unreachables are always sent

ICMP mask replies are never sent

IP fast switching is enabled

IP Flow switching is disabled

IP CEF switching is enabled

IP CEF switching turbo vector

IP CEF turbo switching turbo vector

IP multicast fast switching is enabled

IP multicast distributed fast switching is disabled

IP route-cache flags are Fast, CEF

Router Discovery is disabled

IP output packet accounting is disabled

IP access violation accounting is disabled

TCP/IP header compression is disabled

RTP/IP header compression is disabled

Probe proxy name replies are disabled

Policy routing is disabled

Network address translation is disabled

WCCP Redirect outbound is disabled

WCCP Redirect inbound is disabled

WCCP Redirect exclude is disabled

BGP Policy Mapping is disabled

Input features: Access List, uRPF, TCP Adjust MSS

Output features: TCP Adjust MSS

IP verify source reachable-via RX

0 verification drops

0 suppressed verification drops

0 verification drop-rate

Router#





From: Arie Vayner [mailto:arievayner@gmail.com]
Sent: Saturday, January 31, 2009 3:49 PM
To: Frank Bulk
Cc: cisco-bba@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@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

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@gmail.com]
Sent: Saturday, January 31, 2009 3:49 PM
To: Frank Bulk
Cc: cisco-bba@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@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

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@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@gmail.com]
> *Sent:* Saturday, January 31, 2009 3:49 PM
> *To:* Frank Bulk
> *Cc:* cisco-bba@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@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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-bba
>
>
>

On Sat, Jan 31, 2009 at 10:58:49PM -0600, Frank Bulk 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.

log-input instead of log on the deny line of access-list 125 which matches
the spoofed traffic?

For uRPF hits you already included the show int output which includes the
counter which increments on each drop. i
Not checked how easily monitorable those are, but...
http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_urpf_mib.html
implies that are least some of the RPF information is exposed via SNMP in
recentish code. (I wonder if those appear if you use no virtual-template snmp
for scalabilty).

--
Euan Galloway
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

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@gmail.com]
Sent: Sunday, February 01, 2009 1:19 AM
To: Frank Bulk
Cc: cisco-bba@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@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@gmail.com]
Sent: Saturday, January 31, 2009 3:49 PM
To: Frank Bulk
Cc: cisco-bba@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@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

Yes, that did the trick, thanks. Listing the ATM port and vp/vc wouldn't
hurt, either, though. =)

I'm not interesting in monitoring uRPF hits via SNMP at this time, though --
I'm looking to get the specificity of uRPF to block spoofed source traffic
and leave my inbound ACL on the Virtual-Template for block RFC1918 traffic,
but as I posted just a few minutes ago, that ACL doesn't seem to be working.

Frank

-----Original Message-----
From: cisco-bba-bounces@puck.nether.net
[mailto:cisco-bba-bounces@puck.nether.net] On Behalf Of Euan Galloway
Sent: Sunday, February 01, 2009 10:24 AM
To: cisco-bba@puck.nether.net
Subject: Re: [cisco-bba] ACLs on Virtual-Access templates

On Sat, Jan 31, 2009 at 10:58:49PM -0600, Frank Bulk 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.

log-input instead of log on the deny line of access-list 125 which matches
the spoofed traffic?

For uRPF hits you already included the show int output which includes the
counter which increments on each drop. i
Not checked how easily monitorable those are, but...
http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_urpf_mi
b.html
implies that are least some of the RPF information is exposed via SNMP in
recentish code. (I wonder if those appear if you use no virtual-template
snmp
for scalabilty).

--
Euan Galloway
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

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#wp1013117

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@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@gmail.com]
> *Sent:* Sunday, February 01, 2009 1:19 AM
>
> *To:* Frank Bulk
> *Cc:* cisco-bba@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@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@gmail.com]
> *Sent:* Saturday, January 31, 2009 3:49 PM
> *To:* Frank Bulk
> *Cc:* cisco-bba@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@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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-bba
>
>
>
>
>

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@gmail.com]
Sent: Tuesday, February 03, 2009 2:02 AM
To: Frank Bulk
Cc: cisco-bba@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@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@gmail.com]
Sent: Sunday, February 01, 2009 1:19 AM


To: Frank Bulk
Cc: cisco-bba@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@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@gmail.com]
Sent: Saturday, January 31, 2009 3:49 PM
To: Frank Bulk
Cc: cisco-bba@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@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba