From: Richard Dumoulin (richard.dumoulin@vanco.es)
Date: Mon Jun 28 2004 - 14:18:07 GMT-3
But "spoofed" addresses that are not part of your network are not "spoofed"
right ? :)
--Richard
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: lunes, 28 de junio de 2004 19:16
To: Ricardo Ferreira; Richard Dumoulin; Group Study
Subject: Re: Logging denied spoofed packets
Ricardo,
Yes, you can deny all the ip addresses of your network, but that doesn't
cover spoofed addresses that aren't part of your network.
----- Original Message -----
From: "Ricardo Ferreira" <ricardo.ferreira@quadcomm.com.br>
To: "ccie2be" <ccie2be@nyc.rr.com>; "Richard Dumoulin"
<richard.dumoulin@vanco.es>; "Group Study" <ccielab@groupstudy.com>
Sent: Monday, June 28, 2004 12:55 PM
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