Cisco ASA 5510 Firewall Rules

The "permit ip any any" is the same as the implicit permit any.  They both provide the same functionality.

>Also, what are some ideas for other rules for my users going to the outside world. It seems like having these two default rules still won't protect a user from establishing a cummunication to an unwanted source.

I prefer to whitelist certain ports that users are allowed to access.  This should help against P2P and other applications that are undesired.  Adding a proxy server with content filtering is a nice addition to protect users from visiting malicious sites but this is in addition to the Firewall itself.

>One last question, there is an option for direction for each inside and outside rule sets, could I have an example in which you would utilize this?

You could apply an access-list outbound on the inside interface if you had a number of DMZ's on the Firewall and wanted to add a second level of protection from DMZ to inside.

For example:

If you allowed your DMZ hosts HTTP access to "any" destination, this would allow HTTP to the inside hosts as well from the DMZ.  You can make sure you put a deny to the inside subnets prior to the HTTP any rule in the DMZ access-list or you can use the outbound list on the inside to negate "misconfigurations".

Jfred - I'd like to add a couple of things, sorry if it steps on your answer.

dennis -
In regards to the in and out rules, in your example, the traffic from DMZ to Inside would be denied implicitly, if, the security level on the Inside is higher than that of the DMZ.  In that case, an inbound rule would have to be set on the Inside interface to allow the traffic in.  The reasoning for in and outbound rules you list I agree with but the use is more intentional, conditioned on the security level of the interfaces interacting.  Each ruleset (inside/outside/dmz and in/out) is applied independently without regard to any previous rules the traffic may have encountered.  The caveat, any any rules work best with traffic moving from a higher interface to a lower and are best left out of the mix when moving from lower to higher.

Beyond this, when looking at your rulesets approach them from the perspective of using inbound rules to deny traffic being unnecessarily processed.  In other words, identify the objects/ports/protocols that you want to allow and then kill everything else with deny any any log.  This way, what has to go can and what isn't going is killed prior to being processed.  The logging will help you with troubleshooting.  Regarding the interface out rules, use these as your filters/leak guards and traffic controls in response to any any or broad allow statements on other, higher security levelled interfaces.

Beyond this, utilizing the proxy can be a good idea, however, it may be worthwhile to consider licensing the content filtering abilities on the ASA itself.  Another item of interest I have seen recently is OpenDNS, a free DNS service which you can sub in for your outside/ISP resolvers.  You may want to check this out as well and see if it will work for you.

Hope it helps

Cheers

So basically if I were to deny one ip address and allow any any,  this will be the EXACTLY same as the implicit allow to any lesser network, BUT with this one blocked IP?

Yes.  Correct.

Thanks,  it made me nervous because testing this, I saw tons of hits for the allow any any rule, and before with the implicit i saw none.  The hits must not show for the default, but they ARE really there