Following up to my previous "Topic #1" essay, I am trying to present a model for describing what UTM does now, so that its behavior can be understood without secret knowledge, and by doing so, create a framework for fixing the problems created by the hidden configuration changes performed by the proxies. Initially, these can be "virtual automatic firewall rules", which represent the current reality for documentation purposes. Eventually, I would hope that the "virtual automatic" rules become rules that can be re-positioned and modified.
DNAT and Full NAT
Because DNAT-to-DeadEnd is the current "standard" for implementing an override to the proxy behavior, it is clear that DNAT processing must be integrated into a unified model. That can be accomplished using a firewall rule of the form:
Source IP+Port, Destination IP+Port, Action="Destination Rewrite (DNAT)", Priority=<value>
The DNAT configuration section would continue to define what the new destination becomes, but the "Virtual automatic firewall rule" indicates the conditions which will trigger the override. To reflect the current hard-coded event ordering, these DNAT placeholders would be given a system-assigned sequence number which precedes the virtual-automatic rule for Proxies.
Destination rewrite currently occurs very early in the packet evaluation, which is why it is useful for overriding proxy behavior. However, DNAT-to-DeadEnd depends on having an address which is never activated. To prevent destination-search overhead, the DeadEnd address also needs to be adjacent to an enabled UTM network segment. This leaves a security time bomb if someone utilizes that address in the future. The goal is to replace DNAT-to-DeadEnd with explicit DENY rules, as soon as the proposed virtual rules became actual rules that can be repositioned or modified.
Standard Proxies
Interestingly, Standard-Mode proxies also a "Destination Rewrite operation. Once a criterion is satisfied to invoke a standard proxy, the proxy extracts the target URL, resolves DNS to IP, and evaluates whether to allow or deny the packet. In the previous topic, I suggested a single Proxy Evaluate step to represent the standard proxy, but a better model is to break the proxy invocation into multiple steps:
Source IP, Source Port, Standard Proxy IP, Proxy Port, Action="Destination Rewrite (Standard Web)", Priority=-399
Source IP, Source Port, Destination URL IP, Destination Port, Action="Proxy Evaluate (Standard Web):FilterProfile1", Priority=-398
Source IP, Source Port, Destination URL IP, Destination Port, Action="Proxy Evaluate (Standard Web):FilterProfile2", Priority=-397
Source IP, Source Port, Destination URL IP, Destination Port, Action="Proxy Evaluate (Standard Web):FilterProfile3", Priority=-396
Source IP, Source Port, Destination URL IP, Destination Port, Action="Proxy Evaluate (Standard Web):FilterProfile4", Priority=-395
(A state-tracking flag should enforce the principle that the second step, "Proxy Evaluate (Standard Web)" only occurs for packets that have been processed by the first step of Destination Rewrite for the same proxy.)
In a future implementation, when the rules are more than phantom entries, it would be hoped that unconditional rules can be inserted into this sequence. One benefit is to provide firm boundaries against zone escalation.
Source IP, Source Port, Standard Proxy IP, Proxy Port, Action="Destination Rewrite (Standard Web)", Priority=-399
Internal IP, Source Port, Any Destination IP, Any Allowed Port, Action="Proxy Evaluate (Standard Web):FilterProfile1", Priority=-398
DMZ IP, Source Port, Internal IP, Any Port, Action=DENY, Priority=-397
DMZ IP, Source Port, Any Destination IP, Any Allowed Port, Action="Proxy Evaluate (Standard Web):FilterProfile2", Priority=-396
Guest Wifi IP, Source Port, Internal IP, Any Port, Action=DENY, Priority=-395
Guest Wifi IP, Source Port, DMZ IP, Any Port, Action=DENY, Priority=-394
Guest Wifi IP, Source Port, Any Destination IP, Any Allowed Port, Action="Proxy Evaluate (Standard Web):FilterProfile2", Priority=-393
This ensures that Guest WiFi and DMZ devices cannot use the proxy to leapfrog into a more secure zone. To achieve the same effect with the current implementation, the deny actions must be implemented within each relevant Filter Action. Every time that a Filter Profile or Filter Action is added to the configuration, it creates the opportunity for a configuration error to be introduced which permits zone escalation.
Country Blocking:
Country Blocking can be integrated into a unified model based on virtual-automatic firewall rules as well, using two new actions:
Source IP, Source Port, Destination IP or URL, Destination Port,Action="Country Blocking Exception", Priority=-350
Source IP, Source Port, Destination Country, Destination Port,Action="Country Blocking", Priority=-349
Source Country, Source Port, Destination IP, Destination Port,Action="Country Blocking", Priority=-348
In this context, Action="Country Blocking" represents a conditional block, which occurs as long as an exception state has not been previously granted to the packet. The "Country Blocking Exception" action sets that exception state.
Again, once the features are represented as firewall rules, so we have a framework for understanding how the product works now. With changes to make the virtual rules into real rules, we can make the product much more flexible to meet the actual configuration intent of the system managers who are trying to protect their networks with this product.
Source Rewrite:
The proxies replace the source address with a UTM address, except when using Full Transparent Web Proxy. SNAT and full NAT also replace the source address. For both types of substitutions, this occurs at the end of packet processing, after the decision has been made to allow the packet through the UTM,. As a result, it is not of major interest for security control, but it can be modeled in the same format as DNAT. The rules might look like this:
Source IP, Source Port, Destination IP, Destination Port,Action=Source Rewrite (DNAT), Priority=998
Source IP, Source Port, Destination IP, Destination Port,Action=Source Rewrite (Transparent Web), Priority=999
Conclusion:
1) I am proposing that the existing configuration be represented using virtual firewall rules using these new actions:
- Proxy Evaluate,
- Destination Rewrite,
- Country Blocking,
- Country Blocking Exception, and
- (optionally) Source Rewrite
2) Once the entire configuration can be modeled using firewall rules, it should be possible to design a Packet Flow Emulator which uses this model to explain whether a packet is allowed or denied.
3) Once the entire configuration can be modeled using firewall rules, it should be possible to begin making some of those rules modifiable or reconfigurable, to give flexibility to system managers and more importantly to fix UTM's vulnerability to configuration errors which permit zone escalation.
This thread was automatically locked due to age.
