novice 20 Posted October 20, 2018 Posted October 20, 2018 Any plans to give us option to use FQDN in firewall rules? Thanks!
itman 1,801 Posted October 20, 2018 Posted October 20, 2018 (edited) This is something that is not advisable: Quote Considerations The FQDN object is an address object, which means it's as good as referencing a Source Address or Destination Address in a security policy. Therefore, every 30 minutes, the Palo Alto Networks Firewall will do an FQDN Refresh, in which it does an NS lookup to the DNS server that's configured (Setup > Services). The firewall maps up to 10 IP addresses to that FQDN object. Make sure that this is the same server that your hosts are using. DNS malware can adversely affect a solution like this. Use this method only when using an IP address is not possible--don't use this type of object as part of a URL filtering policy. This can also be helpful to control other services that don’t relate to web browsing like ftp, ssh, or any other service. If the object also resolves to an IPv6 address, enable IPv6 Firewalling (Setup > Session). https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClHJCA0 In any case, it is not a feature that would be applicable to consumer based firewall solutions. Edited October 20, 2018 by itman
Daedalus 16 Posted October 20, 2018 Posted October 20, 2018 Maybe not advisable but I would very much welcome such a feature. I have had my firewall in interactive mode but for example Microsoft often only tell you the FQDN's that need's to be reachable instead of the IP ranges. So you keep editing the firewall rules.
itman 1,801 Posted October 20, 2018 Posted October 20, 2018 (edited) The below elaborates on why FQDN should not be used in firewall rules: Quote In general the problem with using a FQDN in ACL's is rooted in the fundamental problem: Your systems only see IP-addresses as the sources and destinations of network traffic. To use a FQDN your security system either needs to perform a reverse DNS lookup whenever traffic containing a new and unknown ip-address arrives to determine if that particular ip-address resolves to a white-listed FQDN. The problem with that, in addition to the fact that it can be slow, is that the owner of an ip-address can set any hostname name they want on a reverse DNS record, including one from domains that they don't own such as your white-listed domain... So that is both slow, unreliable and insecure. Alternatively systems could translate the FQDN to an ip-address in the background and effectively apply your policies to the ip-addresses the FQDN's resolve to, which will prevent the slow, unreliable and insecure reverse lookups, but that results in a different set of problems: the ip-address associated with a FQDN can be changed at any time by the owner of the domain, and how and when will the new IP-address replace the old one in your policies? a FQDN can even resolve to multiple ip-addresses... depending on your own ip-address, a FQDN may resolve to different (ranges of) IP-addresses so a policy based on the FQDN can't possibly match all actual ip-addresses... https://serverfault.com/questions/874525/how-to-permit-deny-traffic-based-on-domain-name-fqdn-rather-than-ip-address-in Edited October 20, 2018 by itman
novice 20 Posted October 20, 2018 Author Posted October 20, 2018 2 hours ago, itman said: In any case, it is not a feature that would be applicable to consumer based firewall solutions. OK, so what is the solution? Most of the software today use dynamic IP addressing , so is pointless to have rules based on IPs.
itman 1,801 Posted October 20, 2018 Posted October 20, 2018 5 hours ago, novice said: OK, so what is the solution? If you want to block access to domain names, the best way to do that is to use the existing URL block list in the Web Access section of Internet Protection. Wildcard capability exists there to allow you flexibility in specifying a broad range of generalized domain coverage. Note that Eset's Web Access protection now monitors all process Internet communication whereas in past versions only browser communication was monitored.
Recommended Posts