Guest User!

You are not Sophos Staff.

Thread Info
  • Locked Locked
  • Replies 3 replies
  • Subscribers 6 subscribers
  • Views 4447 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Fixing UTM, Topic #1, Documenting the hidden firewall impact of the proxies

DouglasFoster

This is the first in a planned series of posts about the neglected problems with UTM, leading to a proposed solution to those problems.  It would appear that Sophos has despaired of fixing what they bought from Astaro, and XG Firewall is the evidence of that despair.   I am reluctant to embrace that despair, in part because I don't want to deal with the pain of transitioning to a different product, and in part because I don't believe the problems should be unsolvable.

I see these significant unsolved problems

  • The proxies make secret changes to firewall configuration, changes which are neither visualized in the GUI nor adequately documented in the manual.   The first responsibility for the vendor of a security product is to provide enough information for a competent person to read the documentation and use the administrative tools to configure the product securely.   I do not believe the UTM documentation and GUI meet that criterion.
  • Because the proxy changes are invisible, they are not directly modifiable.
  • Because the proxy changes are given precedence, it is easy to create configurations that inadvertently produce an insecure configuration.
  • Because there is no unified framework for presenting the current configuration, Sophos has no framework for designing a packet simulator to model the behavior of that framework.

My goal is to present many of the critical elements of the UTM configuration in the syntax of firewall rules:   

  • Source IP+Port,
  • Target IP+Port,
  • Action,
  • Priority.   

Currently, the implemented firewall actions are Allow and Deny.   For purpose of creating a unified model, let's define an action called "Proxy Evaluate", where the allow/block decision is delegated to the proxy, if the packet complies with the Source and Target criteria.   How could the existing UTM behavior be represented using this approach?  (Note: the initial goal is to document current behavior, not to discuss how it might be redesigned.)

The priority will have to be a negative number, because the proxy priorities precede any of the current automatic or manual firewall rules.  Consequently, I have assigned arbitrary negative priority numbers to indicate relative ordering.

Please help to complete the list, as I do not use RED or AP devices, and I may have mistakes elsewhere.

SMTP Proxy Enabled:
SourceIP: <any>, Source Port <any>
Target Address: <Any UTM Address>, Target Ports: 25, 465, & 587
Action: Proxy Evaluate (SMTP), Priority: -1

Transparent FTP Proxy Enabled:
Source IP: <Transparent FTP Proxy Allowed Network List>, Source Port: <any>
Target Address: <any>, Target Port: 21
Action: Proxy Evaluate (Transparent FTP),
Priority: -2

Transparent Web Proxy Enabled (one for each Filter Profile):
Source IP: <Filter Action Allowed Network List>, Source Port: <any>
Target Address: <any>, Target Ports: 80 & 443
Action: Proxy Evaluate (Transparent Web),
Priority: -3 and lower

WAF Enabled (one for each unique virtual webserver IP address/port pair):
SourceIP: <any>, Source Port <any>,
Target Address <Virtual Webserver Address>, Target Ports: <configured port, often 443>,
Action: Proxy Evaluate (WAF),
Priority: -50 and lower

Standard Web Proxy Enabled:
Source IP: <Any>, Source Port: <Any>,
Target IP: <Any UTM Address>, Target Port: <as configured, 8080 default>
Action: Proxy Evaluate (Standard Web),
Priority: <-100 and lower>

Standard FTP Proxy Enabled:
Source IP: <Any>, Source Port: <Any>,
Target IP: <Any UTM Address>, Target Port: <as configured, 2121 default>
Action: Proxy Evaluate (Standard FTP),
Priority: <-200>

I would argue that presenting this type of information as "Virtual Automatic Firewall Rules" would be valuable, even if the "rules" are unmodifiable phantom objects that exist only for purposes of the user interface.

I have ideas for refining this model to reflect more of the sophistication within the product, including NAT, Country Blocking, and additional aspects of Standard Proxy.   I will hold those refinements for a follow-on topic.   The first step is to get the complete list of virtual firewall rules documented correctly.   Please help.

 



This thread was automatically locked due to age.

  • Hi Douglas,

    I'm reading this post with interest as I agree with a lot of points you are making. For me (and I would say others too), the UTM is a bit of a learning curve when it comes to the proxies.

    And the first one that got me was the web proxy. Coming from other products, I think most users would set up their SNATs, DNATS etc etc only to realise later that they aren't needed because the UTM takes care of it with proxies. The first question people tend to ask themselves is "How the hell is traffic getting through when there are no fw rules set?"

    The answer is being that the proxies are off-loading them. It's interesting that the UTM can run without any firewall rules set. Load it up, enable the web filtering and off you go assuming you have an internet connection of course and NAT etc is setup. Enable the SMTP proxy and the UTM is accepting mail etc.

    And it can get complicated with inter vlan traffic too ie the web proxy transparently allowing traffic between vlans etc.

    I generally set the UTM up in reverse now with the FW rules coming at the end as opposed to the beginning. I shy away from the fw automatic rules as I prefer to know what they are doing.

    Would I like it to be more granular? Yes..... and I take it from reading the above, you are suggesting that the FW rules are evaluated first and if the rule is matched, it is then offloaded to the targeted proxy?

    I'd go along with that as it brings it into line with other products. If you separate the functions ie firewalls and proxies, in most corporate environments, you would have the firewall at the edge which then offloads the incoming web traffic to the proxy and in reverse, web traffic hits the proxy and then the firewall.

    Maybe the UTM works it's magic and does this in the background? But I'd still like further control eg only enable the proxy on 1 IP address etc and I'd certainly like to see the visible FW rules at the front of the UTM with a rule that allows you to allow/deny traffic to the targeted proxy.

  • in reply to Louis-M

    The problem now is that Sophos has to preserve the status quo for existing configurations, so the new design has to start from what we have, then add flexibility.

     So I am hoping to get the proxy entry paths visible now and repositionable and modifiable later.  But you cannot reposition or modify an object that is invisible.  Once it is visible and configurable, an odd architecture becomes a great architecture.

  • Hey Douglas,

    Thank you for taking the time to write this very detailed and valuable series. You've provided great points and ideas for our development team. 

    I'll go ahead and tag some members of the UTM team so they can have a read.

    Appreciate the feedback.

      

    Cheers,
    Karlos

    Karlos
    Community Support Engineer | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'This helped me' link.
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?

Unfiltered HTML