Avoid Sending DNS Queries, etc... for Non-Routable Addresses to Internet

[snowmizer]

While our security person was running scans we noticed millions of events looking for non-routable IPs being sent to the Internet from our ASA. I know this is happening because the IP doesn't exist in our network and the default route on the switch is sending traffic to the ASA.

Is there a way to keep traffic destined for a non-routable IP address (e.g. 10.0.0.1) that doesn't exist on the internal network from being sent to ASA and thus to the Internet? I've tried to figure out a way to do this but based on what I know I'm not sure how I can do this. We're running Catalyst 4506 (Sup 4) core switches with the ASA.

Also, am I correct that if the traffic is destined for a non-routable IP address the ASA will drop the traffic? Here's an example of a log record I'm seeing:

 %ASA-6-302016: Teardown UDP connection 116120627 for outside:10.100.116.4/111 to inside:10.10.10.50/52080 duration 0:10:01 bytes 40

I'm thinking that this connection got removed immediately but now that I look at it again I'm questioning if the connection was active for 10 minutes before it was torn down.

I guess I need to make sure that what I'm thinking is actually the case.

Thanks.

[Jon Marshall]

Firstly depending on the scan it may be this is not really an issue in normal operations ie. how often do your clients actually try to communicate with IPs not within the network.

In terms of stopping traffic on the 4500 there is a way but you need to careful.

If the 4500 is the last hop before the ASA and it has a default route pointing to the ASA then you can add a route to the 4500 ie.

ip route 10.0.0.0 255.0.0.0 null0

the above will drop traffic to any destination 10.x.x.x IPs that are unknown. It is a more specific route than your default so it will take precedence but only for 10.x.x.x IPs.

If you are not using any 10.x.x.x addressing for your clients it is relatively safe.

However if your internal network uses 10.x.x.x addressing (and it looks from the firewall log it does)  then you must make sure that for any internal 10.x.x.x subnets there is a route on the 4500 that is more specific than the above route otherwise traffic to and from internal clients could be dropped when it shouldn't be.

So the 4500 would need full routing information for all the internal subnets or if you were using summary addresses for WAN etc. these summaries would still need to be more specific than the above route.

Obviously i don't know your network or how the routing is setup etc. so i can't make any guarantees and if you do choose to implement it then you need to fully understand your current routing setup and how the above route interacts with that.

In terms of the firewall forwarding it, i am a bit out of date with the ASA so it may behave differently, but from my experience if you don't filter that traffic the firewall would simply forward any destination IP to it's next hop assuming it is using a default route. 

It probably won't get much further than that as 10.x.x.x is not routable on the internet but i wouldn't assume you firewall would automatically drop it.

So the alternative to using the route on the 4500 would be to add an inside acl to filter RFC 1918 private IP from being allowed through the firewall. But this would obviously not stop traffic actually going from the 4500 to the firewall.

Generally speaking it is considered good pratice to filter RFC 1918 IPs being sent from your network to the internet. If you own the upstream router you could do it there or on the firewall.

Jon

[snowmizer]

I decided that rather than mess up routing on the 4500s it would be safer to put in an ACL on the ASA inside interface to make sure that no traffic is allowed from the inside network to non-routable ranges. When I tested using "tracert 10.0.0.104" I see the denied log records for the ACL instead of all of the teardowns like I posted earlier.

I think this is doing what I want since I basically don't even want to see the traffic get out.

Thanks.