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

Firewall rules do not work as expected, so what are the workaronds?

I have had some unhappy surprises with traffic filtering not working as expected.   After reviewing some of the other material in this blog, I am beginning to understand.   What follows is a description of my current understanding.   Hopefully someone who is more knowledgeable can correct my errors, clarify my confusion, and affirm the assertions that are actually valid.

Even though this may get to a workable solution, it does not fully solve the problem that the device does not behave as most new users will expect it to behave, and as a result, there are likely to be many UTM installations will have allowed traffic which they do not intend to be allowed.

My current understanding:

When do Network Protection Firewall Rules apply?

  • Assume that Firewall Rules only apply to traffic passing through the UTM without any processing by other subsystems.
  • Fortunately, NAT rules apply even when Firewall Rule do not.   Therefore, creating DNAT rules to direct unwanted traffic to a dead-end address is a useful alternative for situations where Firewall Rules are ignored.   Remember that UTM allows USERS and GROUPS to be used in DNAT rules, so you should be able to block outbound traffic based on either of these methods:
    • User/group and destination IP, or
    • source IP and destination IP.    

How to limit Webserver Protection (WAF) site to specific IP addresses?

  • Use WAF Site Path Routing to specify Allow and/or Deny source addresses for each source path.

How to limit incoming SMTP traffic to the specific IP addresses intended for SMTP traffic?

  • Option 1:   Ignore the issue:
    • For all internal addresses, SMTP will be open by default but will return error 550 – Access denied.   This can be verified by testing with PortQry.
    • For all external addresses, SMTP will be open by default and will route to the SMTP proxy, at which point SMTP proxy logic applies.
  • Option 2:   Lock it down:
    • Create dead-end DNAT rules for every UTM address that exists but which should not accept SMTP traffic.
    • Create dead-end DNAT rules for every Source IP address range that you want to block from ever sending SMTP traffic to your published SMTP addresses.

How to prevent web proxy users from accessing web servers in specific IP address ranges?

  • Use a DNAT address to send traffic for specific outbound address ranges to a dead-end address. Web filtering does not have its own block/allow list based on IP address.

How to prevent web proxy users from access web servers with specific reverse DNS entries?

  • Create a regular expression and add it to the list to blocked site list within each profile. If the list is long and the number of profiles is large, this may get tedious.

What are my options for managing FTP?  (Short answer:   I don’t understand.)

  • Dead-end DNAT rules will probably be useful for FTP as well.
  • Some web sites will provide web links that redirect the user from http to ftp for file downloads. As far as I understand, UTM must be in transparent mode for these links to work at all.   The user cannot predict when or where this might happen, and has no ability to alter the link used.   Consequently, I have never tested non-transparent mode or “Both” mode.   I would be interested in comments.
  • The FTP Advanced tab has a box to specify Allowed Servers. My understanding is that this list only applies when using non-transparent mode, which seems to presume use of an FTP Client application.   There is not an equivalent Blocked Servers list.
  • The FTP Advanced tab also has a transparent mode skip list. I wonder whether the transparent proxy functions differently when used anonymously from a web browser or transparently from an FTP client application.
  • I have discovered that Google Chrome loses NTLM information when a web session switches from http to ftp, so web links that link to an ftp site will work in IE but fail in Chrome. One possible workaround is to create a Web Filtering exception to bypass authentication for URLs matching ftp://.   Naturally, this approach eliminates the ability to control FTP differently for different users, so it may not be tolerable for some sites.  If that is your situation, then users will have to be use a different browser or use one of the alternate authentication methods.

 How close does this come to truth?



This thread was automatically locked due to age.
Parents
  • A great idea to start a discussion on this, Douglas!  The parts up through and including SMTP look good.

    How to prevent web proxy users from accessing web servers in specific IP address ranges?

    • Use a DNAT address to send traffic for specific outbound address ranges to a dead-end address. Web filtering does not have its own block/allow list based on IP address.

    1. In Transparent mode, you can use the 'Transparent Mode Skiplist' with 'Allow HTTP/S traffic for listed hosts/nets' unchecked.  This allows/requires you to make normal firewall rules.  In Standard Mode, the solution would be different, but I don't understand why it would be advantageous to prevent access to "specific IP ranges" instead of to domains, URLs, etc.

    How to prevent web proxy users from access web servers with specific reverse DNS entries?

    • Create a regular expression and add it to the list to blocked site list within each profile. If the list is long and the number of profiles is large, this may get tedious.

    2. I don't understand how this is different from regular Web Filtering.

    What are my options for managing FTP?  (Short answer:   I don’t understand.)

    • Dead-end DNAT rules will probably be useful for FTP as well.
    • Some web sites will provide web links that redirect the user from http to ftp for file downloads. As far as I understand, UTM must be in transparent mode for these links to work at all.   The user cannot predict when or where this might happen, and has no ability to alter the link used.   Consequently, I have never tested non-transparent mode or “Both” mode.   I would be interested in comments.
    • The FTP Advanced tab has a box to specify Allowed Servers. My understanding is that this list only applies when using non-transparent mode, which seems to presume use of an FTP Client application.   There is not an equivalent Blocked Servers list.
    • The FTP Advanced tab also has a transparent mode skip list. I wonder whether the transparent proxy functions differently when used anonymously from a web browser or transparently from an FTP client application.
    • I have discovered that Google Chrome loses NTLM information when a web session switches from http to ftp, so web links that link to an ftp site will work in IE but fail in Chrome. One possible workaround is to create a Web Filtering exception to bypass authentication for URLs matching ftp://.   Naturally, this approach eliminates the ability to control FTP differently for different users, so it may not be tolerable for some sites.  If that is your situation, then users will have to be use a different browser or use one of the alternate authentication methods.

    3. Most of this has to do with how the FTP Proxy functions and how to configure it based on choices in Web Filtering and the use of an FTP client instead of discussing how to prevent access based on IP address.  I'm also confused here why we would need to use DNAT to block outbound requests.

    Cheers - Bob

  • Right now, my UTM is behind another firewall.   I had hoped it could become my only firewall, but when I started learning about some of these situations where firewall rules were not enforced, I started to panic that this was never viable.   You assured me that there were workarounds to all of the concerns, so read up on some of your references and then tried to begin a cookbook for all of the likely scenarios where firewall-like functions might be needed even though Firewall Rules were going to be bypassed.  I tried to apply dead-end DNAT rules everywhere that I thought firewall block rules might be desired, but I may have had some overkill.

    My firewall, the one in front of UTM, blocks a lot of things based on IP range, largely as a form of country blocking.  UTM's Country Blocking has never appealed to me because it seems impossible to define whether any specific IP address will be allowed or blocked, and once blocked there seemed to be no exception mechanism.   Then this issue with firewall rules added another complication.   If it is part of the firewall, then maybe country blocking will block too little rather than too much.  So I could benefit from clarification here.

    I really crave a packet simulation tool -- If a packet arrives at this interface with a specific source and destination address-protocol-port pair, how will it flow through the device?   Where will it get stopped?  Will the reply packet be accepted or rejected?

    I am not sure what I was thinking with reverse DNS and Web Filtering, apparently not very clearly.   I do wish UTM had reverse DNS filtering for EMail filteing, and it may be desirable for some blocks on Webserver Protection.  I have to agree that web filtering already has plenty of options for control based on URL, uisng simpler methods than my first post described.

    Doug

  • Packets are filtered

    1/. by proxy if enabled

    2/. by internal rules (created when using dnat/snat functions

    3/. by firewall rules in order down the page.

    4/. country blocking does work, but because not all websites are based in their country they will be allowed to pass eg, some .RU sites are based in the US and will therefore have a US IP address.

    5/. packets will be accepted, dropped or rejected by your filter configuration.

Reply
  • Packets are filtered

    1/. by proxy if enabled

    2/. by internal rules (created when using dnat/snat functions

    3/. by firewall rules in order down the page.

    4/. country blocking does work, but because not all websites are based in their country they will be allowed to pass eg, some .RU sites are based in the US and will therefore have a US IP address.

    5/. packets will be accepted, dropped or rejected by your filter configuration.

Children
No Data