Anti-spoofing ACL

I have an ethernet interface in a Cisco 7206 that I need a simple anti-spoofing ACL for.  There are 2 subnets bound to the interface - as an example
111.222.333.0/24   and   444.555.666.0/25
if I use access-list 10 permit 111.222.333.0
            access-list 10 permit 444.555.666.0
and apply it to the interface out,  I get unexpected results,  Can someone show me what the outbound acl for anti-spoofing should look like?

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Hi jackthetripper,
One of your masks is incorrect. I would also use an extended access-list :-

access-list 100 permit ip 111.222.333.0 any
access-list 100 permit ip 444.555.666.0 any
I would apply this to the inbound direction of the interface.
This will stop machines on this interface from being able to spoof IP addresses.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Here is my anti-spoofing access-list.  This is applied on the inbound direction on my outside interface.  Keep in mind this is only the anti-spoofing portion of my acl.

access-list 120 deny   ip any - specifically deny my local subnet
access-list 120 deny   ip any
access-list 120 deny   ip any
access-list 120 deny   ip any
access-list 120 deny   ip any
access-list 120 deny   ip host any
access-list 120 deny   ip host any
access-list 120 deny   ip any any log-input
rshooper76's answer is taking the anti spoofing from the other perspective of blocking users on the Internet from spoofing your IP range when connecting to you. My example stopped your machines from being able to spoof other machines on the internet.
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

Personal opinion only, but I like to keep things simple. It is easier for me to permit only what I want, and let the implied deny all take care of the rest. Example of acl that I use, applied "in" to the external interface:

ip access-list extended outside_in
  permit tcp any any established  <== prevents spoofing
  permit udp any eq domain any  <== need this always
  permit icmp any any echo-reply  <== optional
  permit icmp any any unreachable <== optional, but highly suggested
  permit icmp any any time-exceeded <== optional if you want to use traceroute
  deny ip any any log  <== be sure to get a good syslog server

The "log" keyword allows me to examine my syslog entries for recon attempts and other unwanted traffic. Without specifying the private IP ranges or anything else, they are automatically blocked. Keeping in mind that every line of an acl must be processed until a match is found, and every line of an acl is a potential performance hit, I like to keep it as simple as possible.
I use Unicast Reverse Path Forwarding (uRPF) for anti-spoofing most of the time instead of an access-list.  Although it usually works, I've had problems a few times.  However, it's easy to do... just apply one command to the interface.

interface dialer1
 ip verify unicast source reachable-via rx allow-default

A related question for lrmoore.  I used to do my access-lists liek you described, but I was told, by a Cisco tech, that explicitely blocking the non-routables was better.  I would rather setup what you described to prevent any performance issues.  What about the ip verify unicast reverse-path, is that a good anti-spoofing option.  I guess what I am saying is I would like to get more details on the proper way to do this.  If I need to create a new post for this I will, but I figure jackthetripper can use it as much as I can.
>I was told, by a Cisco tech,
Personal opinion, it's only because that's what the Cisco books teach.
Why would I need to explicitly deny that traffic when it is already implicitly denied?
My router configs always fail miserably using the RAT tool to "audit" the configs, because the RAT tool is built around NSA's Cisco router guidelines that were written years ago and held up as "the bible". Phooey..

Router Audit Tool (RAT):

NSA Guidelines:

I know that my access-list is as good as any. I see in my logs all the time where I've blocked DHCP broadcasts and all types of recon attempts, as well as some internal IP addresses. I do not explicitly deny any of the "recommended" traffic, because I simply don't explicitly PERMIT it.
There is a rule in designing Govt' networks/firewalls that states that all access is "deny by default, permit by exception" in both directions, which is exactly what I do.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.