Re: Logging denied spoofed packets

From: Ricardo Ferreira (ricardo.ferreira@quadcomm.com.br)
Date: Mon Jun 28 2004 - 13:55:30 GMT-3


Sorry for asking this but if u want to log spoofed addresses doesn't that
mean the incoming packet source address is one of your own subnet address
space... So if I have to log anyhting denied can I also to put an
access-list that denies any incoming traffic with source address as part of
my own subnet....or is my understanding of spoofing wrong. Pls clarify....

----- Original Message -----
From: "ccie2be" <ccie2be@nyc.rr.com>
To: "Richard Dumoulin" <richard.dumoulin@vanco.es>; "Group Study"
<ccielab@groupstudy.com>
Sent: Monday, June 28, 2004 12:50 PM
Subject: Re: Logging denied spoofed packets

> MessageHey Richard,
>
> I used to trust my powers of deduction, but not anymore. Too many times,
it
> turned out that what I deduced ended up not working as I expected and then
> biting me in the butt. Now, I don't have much of a butt anymore and lots
of
> gray hairs as well :-)
>
> Apparently, my logic and that of the IOS developers don't always coincide.
>
> Thanks for your help.
>
> Tim
> ----- Original Message -----
> From: Richard Dumoulin
> To: ccie2be ; Group Study
> Sent: Monday, June 28, 2004 11:26 AM
> Subject: RE: Logging denied spoofed packets
>
>
> "However, that doesn't really address the issue I'm trying to figure
out"
> --> I thought that by understanding how things work you would deduct the
> solution. So if there are any errors in my undertsanding of RPF I would
> appreciate the comments :)
>
> If you don't know the spoofed ip addresses then just put a deny any with
the
> keyword log ?
>
> --Richard
> -----Original Message-----
> From: ccie2be [mailto:ccie2be@nyc.rr.com]
> Sent: lunes, 28 de junio de 2004 17:20
> To: Richard Dumoulin; Group Study
> Subject: Re: Logging denied spoofed packets
>
>
> Thanks Richard for getting back to me. However, that doesn't really
> address the issue I'm trying to figure out.
>
> The key issue is how to LOG spoofed packets and, of course, deny them.
>
> So, the question is what should the acl look like given the fact that
I
> don't know in advanced what source addresses are spoofed?
> ----- Original Message -----
> From: Richard Dumoulin
> To: ccie2be ; Group Study
> Sent: Monday, June 28, 2004 10:57 AM
> Subject: RE: Logging denied spoofed packets
>
>
> With the acl mentioned below, only packets with source address not
> present in the routing table or coming through the wrong interface will be
> denied.
>
> The RPF works like this:
> If source present in the routing and coming from the right
interface,
> then pass
> If source coming through the wrong interface then have a look at the
> acl. If permitted by the acl, then pass. If not permitted then deny.
>
> If source not present in the routing table, then check acl etc ...
>
> This is how I think it works,
>
> --Richard
>
> -----Original Message-----
> From: ccie2be [mailto:ccie2be@nyc.rr.com]
> Sent: lunes, 28 de junio de 2004 16:21
> To: Group Study
> Subject: Logging denied spoofed packets
>
>
>
> Hi guys,
>
> When using the ip verify unicast reverse-path <acl> commands, I want
to
> deny only spoofed packet but also log the denied spoofed packets.
>
> According to the documentation,
>
> Enables Unicast RPF on the interface. Use the list option to
identify an
> access list. If the access list denies network access, spoofed packets are
> dropped at the interface. If the access list permits network access,
spoofed
> packets are forwarded to the destination address. Forwarded packets are
> counted in the interface statistics. If the access list includes the
logging
> option, information about the spoofed packets is logged to the log server.
>
> Based on these requirements, what should the acl look like?
>
>
>
>
> If I create an acl which denies all packets (ie. 0.0.0.0/32), does
that
> deny all packets or only spoofed packets?
>
>
>
>
> TIA, Tim
>
>



This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:51 GMT-3