Firewalls and the use of "any"

iamme4eva

Hello,

Another throw away line in the OCG that I have a question about....

You should avoid using "any" when configuring a firewall and all ports / IP's should be stated.

Good theory, but how does that account for randomly chosen source ports for TCP connections?

I can't predict the source port my PC will use when it opens a TCP session to somewhere.

Also, what about the internet? There are more webservers in the world than I can count on one hand - how do I write an ACL, without using any, to allow access to the internet?

Am I just taking this too literally?

docrice

I'm assuming you're talking about an ASA, so based on that...

You have to be careful with the any keyword. Let's say you have your typical three-zone topology with an outside, DMZ, and inside. If your server in the DMZ needs access to the Internet on TCP port 80 for some reason but don't want it to be able to initiate connections to the inside network, you have to be really conscious how that keyword will get interpreted by the ASA. If your server is 10.1.1.22 and your inside network uses RFC 1918 ranges...

object-group network private-nets
network-object 10.0.0.0 255.0.0.0
network-object 172.16.0.0 255.240.0.0
network-object 192.168.0.0 255.255.0.0
exit

access-list dmz-stuff extended deny ip host 10.1.1.22 object-group private-nets log notification
access-list dmz-stuff extended permit tcp host 10.1.1.22 gt 1023 any eq 80

There's more you can add to that object-group, obviously, but that's just an example. If you didn't have the first deny statement, your server could initiate traffic to the inside network which would be bad if the server were compromised and was used as a pivoting point in an intrusion scenario.

The source ports are almost always greater than 1023. There are some exceptions like NTP which some operating systems use a source port of 123.

On the other hand, if your inside hosts should ONLY access a given domain, let's say www.example.com, you can write a FQDN rule (requires ASA version 8.4.2 or later):

object network www.example.com
fqdn www.example.com
exit

access-list gotointernetz extended permit tcp 192.168.6.0 255.255.255.0 gt 1023 object www.example.com eq 80

The ASA will need to be able to resolve names as well. This gets a bit tricky since many popular websites leverage CDNs and the DNS TTLs for their name resolution might be under a minute. With the frequent potential change of IPs from one minute to the next, the firewall at one moment might think the external host resolves to x while the internal client resolves to y and there's a mismatch. For those situations, a proxy would be a better fit.

There are often cases where any needs to be used, but bear in mind that if you use it the firewall will allow access to the Internet ... and anything else. any literally means anything, meaning if you use it for the target address, the firewall will essentially disregard the destination field value at byte offset 16 in the IP header.

gorebrush

Wouldn't one be just using "inspect" which opens up ports outbound as and when?

Generally this is allowed from internal "trusted" interfaces.

iamme4eva

Thanks guys. I think it makes sense. Hopefully it will fit it better as I carry on reading!

I'm finding the CCNA:Sec really hard to keep motivated. It's really dry, and just when as subject looks like it might be interesting, it's glossed over. Plus, I'm not all that interested in using CCP, which seems to be heavily focussed on. Hopefully the CCNP will be better!

veritas_libertas

I know how you feel. I'm finding it hard to get into as well. VERY broad and not that deep.

Cyanic

iamme4eva wrote: »

Good theory, but how does that account for randomly chosen source ports for TCP connections?

I can't predict the source port my PC will use when it opens a TCP session to somewhere.

You don't have to account for the return traffic in your rules if you are using a stateful firewall like the ASA.

When the firewall accepts that first packet of the connection, the return/source port is part of the information added to the connection table.

ANY statements are completely normal and are used all production firewalls I have ever seen, mostly for destination IP. For instance you may want all internal hosts the ability to talk http/https to the internet. Any (no pun) rule needs to be formed with care, ANY is very useful and has its place.

Zartanasaurus

All IPs/ports should be explicit when easily known or categorized.

Example, you have an ACL that allows anyone to get to your webserver.

permit ip any host 1.1.1.1 eq 80
permit ip any host 1.1.1.1 eq 443

is better than

permit ip any host 1.1.1.1 {the tcp/udp port destination of any is implied here}

So it's not that you should never use any. You'll have lots of rules with any, just limit them when feasible.