You can directly use hostnames in zones. During startup, PNS automatically resolves these hostnames to /32
IP addresses, and updates them periodically to keep track of changes.
When using hostnames in zones, note the following considerations and warnings:
Ensure that your Domain Name Server (DNS) is reliable and continuously available. If you cannot depend on your DNS to resolve the hostnames, do not use hostnames in zones.
Do not use zones that include hostnames to deny access, that is, do not use such zones in DenyServices. If PNS cannot resolve a hostname, it will omit the hostname from the zone. If the zone contains a single hostname only (because you want to use it to restrict access to a specific site), and PNS cannot resolve that hostname, then the zone will be considered empty, therefore it will never match any connection. If you have a firewall rule that is more permissive than the DenyService restricting access to a zone containing an unresolvable hostname only, then this more permissive rule will take effect, permitting traffic you want to block. (For example, you create a rule that permits HTTP traffic to the Internet, and a DenyService to block HTTP traffic to example.com hostname. If PNS cannot resolve the example.com hostname, then the broader, more permissive rule will permit traffic to the example.com site.)
vela-zone-helper, besides maintaining zone address information, also enables the filtering and blocking of any, possibly illegitimate, so called 'bogus' IP addresses.
The filtering of the DNS-based zone IP addresses is activated by default in the configuration. The default level of filtering is set to the recommended value of 3, which indicates the following level of filtering:
Filtering level Filtering 0 No filtering takes place. 1 Filtering of invalid host addresses takes place: unspecified addresses ( 0.0.0.0/32
,::/128
).2 Filtering loopback address ranges takes place ( 127.0.0.0/8
,::1/128
).3 Filtering of private address ranges ( 192.168.0.0/16
,10.0.0.0/8
,172.16. 0.0/12
,fc00::/7
), link-local address ranges (169.254.0.0/16
,fe80::/10
) and multicast ranges (224.0.0.0/4
,ff00::/8
) takes place.Table 6.1. Filtering levels
If the level of filtering is required to be configured differently than the recommended value, it is possible to change it by command-line option, or in the vela-zone-helper configuration file with the help of the text editor. (Chapter 8, The Text editor plugin)
For details see the vela-zone-helper and the vela-zone-helper configuration file manual pages in Appendix C, PNS manual pages in Proxedo Network Security Suite 2 Reference Guide.
If the hostname is resolved to an IP address that is explicitly used in another zone, then PNS will use the rule with the explicit IP address. For example, you have a zone that includes the example.com hostname, another zone that includes the
192.168.100.1/32
IP address, and you have two different rules that use these zones (Rule_1 uses the hostname, Rule_2 the explicit IP address). If the example.com hostname is resolved to the 192.168.100.1 IP address, PNS will use Rule_2 instead of Rule_1.If more than one hostname is resolved to the same IP address, PNS ignores that specific IP address associated with more hostnames. Consequently, it is not possible to use a hostname in a zone if the server uses name-based virtual hosting.
Zones are global in PNS, and apply to all firewalls of the site, so carefully consider every modification of a zone, and its possible side-effects.
© 2021 BalaSys IT Security.
Send your comments to support@balasys.hu