From: Ricardo Ferreira (ricardo.ferreira@quadcomm.com.br)
Date: Mon Jun 28 2004 - 14:13:11 GMT-3
RE: Logging denied spoofed packetsTks Richard for the explanation. I have been
tracking this issue and testing so I just wanted to have this wrapped up....
Ricardo
----- Original Message -----
From: Richard Dumoulin
To: Ricardo Ferreira ; ccie2be ; Group Study
Sent: Monday, June 28, 2004 2:11 PM
Subject: RE: Logging denied spoofed packets
Yes you're right. But Tim stated that he did not know what the spoofed
addresses were, hence the deny any.
Suppose a packet with a source address inside your address space enters from
the outside. Then the rpf check fails. The next thing the router will do is
check whether or not the packet is permitted in the acl. Because the acl
denies everything, the packet will be dropped and a log will be created,
--Richard
-----Original Message-----
From: Ricardo Ferreira [mailto:ricardo.ferreira@quadcomm.com.br]
Sent: lunes, 28 de junio de 2004 18:56
To: ccie2be; Richard Dumoulin; Group Study
Subject: Re: Logging denied spoofed packets
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
>
>
_______________________________________________________________________
> Please help support GroupStudy by purchasing your study
> materials
from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
**********************************************************************
> Any opinions expressed in the email are those of the individual
> and
not
> necessarily the company. This email and any files transmitted with it
> are confidential and solely for the use of the intended recipient. If
> you are
not
> the intended recipient or the person responsible for delivering it to
> the intended recipient, be advised that you have received this email
> in error
and
> that any dissemination, distribution, copying or use is strictly
prohibited.
>
> If you have received this email in error, or if you are
> concerned
with
> the content of this email please e-mail to:
> e-security.support@vanco.co.uk
>
> The contents of an attachment to this e-mail may contain
> software viruses which could damage your own computer system. While
> the sender has taken every reasonable precaution to minimise this
> risk, we cannot accept liability for any damage which you sustain as a
> result of software
viruses.
> You should carry out your own virus checks before opening any
> attachments
to
> this e-mail.
>
**********************************************************************
>
> ______________________________________________________________________
> _
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:51 GMT-3