From: ccienj (ccienj@hotmail.com)
Date: Mon Jun 28 2004 - 14:20:47 GMT-3
To catch only the spoofed addresses, an ACL denying internal network
addresses can be applied to egress interface with log or log input option.
For example if 172.16.1.0/24 is LAN network an ACL on serial with deny ip
172.16.1.0/24 any and ip unicast rpf commands will do the job.
----- Original Message -----
From: "Richard Dumoulin" <richard.dumoulin@vanco.es>
To: "ccie2be" <ccie2be@nyc.rr.com>; "Group Study" <ccielab@groupstudy.com>
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 <mailto:richard.dumoulin@vanco.es>
> To: ccie2be <mailto:ccie2be@nyc.rr.com> ; Group
> <mailto:ccielab@groupstudy.com> 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 <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 <http://shop.groupstudy.com>
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
> <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