From: Ricardo Ferreira (ricardo.ferreira@quadcomm.com.br)
Date: Mon Jun 28 2004 - 14:25:56 GMT-3
OK I see the issue clear than ever... but how to check if a valid adress is
spoofed or not in advance....
Should we check the source of such route.... I think that is possible only
if you trust the source of the route what is perfectly feasible with BGP...
but for routes only not for general IP packets....Is there any way of doing
this....
----- Original Message -----
From: "ccie2be" <ccie2be@nyc.rr.com>
To: "Ricardo Ferreira" <ricardo.ferreira@quadcomm.com.br>; "Richard
Dumoulin" <richard.dumoulin@vanco.es>; "Group Study"
<ccielab@groupstudy.com>
Sent: Monday, June 28, 2004 2:15 PM
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.
> > >
> > **********************************************************************
> > >
> > >
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:51 GMT-3