How to start, transition from NAT to WAF

When I started with the UTM, it was all NAT and no proxy. Now we rarely go near NAT and try to keep it as minimal as possible although we can't fully eliminate it.

For WAF:

1. Create the virtual server/s

2. Apply your own filter and add to it bit by bit whilst examining the logs. The aim is to lock it down as much as possible without issue.

Tactics:

• Initially, create the WAF on an internal-only IP+port address and set the operational mode to Monitor Only. 
  You can use a HOSTS file entry to ensure that your test PC connects to UTM instead of to the real webserver.   This allows you to test with known-good traffic.   
  A variant of this approach would be to create the WAF on an unused Internet IP+port address, but use Access Retrictions to ensure that the WAF site is only available from known-good source IP addresses.    After known-good testing, check the logs for [id 12345] entries, where 12345 represents a rule number that was tripped.  Add exceptions for those rules.
• When you are satisfied with your testing, change your configuration so that the NAT rule is removed and the WAF site assumes the IP and Port of the NAT.   You probably want to continue operating in Monitor mode for awhile. 
• Be aware that once the WAF site is publicly accessible, you wlll be unable to discern whether an alarm in the log file represents a threat correctly detected or a false positive.

My experience:

• I continue to see threats reported after going live, which I suspect are false positives.
• I see some threats that trigger "infrastructure" rules.   The GUI warns that these should not be disabled, so I do not.  Instead I disable strict rules.
• After culling out the suspected false positives, relatively few rules are actually enforced.   No one has been able to tell me how to avoid this trap.
• These things can always be enforced, and are significant benefits over NAT alone:
  • Source Path Routing, which prevents bypassing the intended flow of your website.
  • Source IP restrictions (Access Control / Allowed Networks), assuming that this type of restriction fits your business need.
  • UTM-level login with One-Time password and/or with Source IP restrictions.   
• UTM login permits a site-specific user list, so that unrelated accounts cannot be subject to password guessing attacks.  It also provides break-in evasion that blocks the IP temporarily, logs an event, and sends a notification email.
• If a site is accessible both internally and remotely, WAF with UTM login allows the remotely-accessible user list to be smaller then the internal (non-WAF) allowed user list.  It also provides a log file specifically for issues related to remote login.

Login management

• If both UTM and the real webserver require login, the goal should be to use Basic Authentication to ensure that the UTM login triggers an automatic login to the Real WebServer using the same account and password.     The code for implementing Basic Authentication is pretty easy, if you have source control over the real webserver.   (I found good example with a simple web search.)   Integrated login is not always achievable, but when it can be done it provides a better interface for the user and better audit control. 
• Obstacles to integrated login:
  • If UTM and the real webserver do not share a password subsystem, integrated login is probably a bad idea, as you will have too much difficulty keeping passwords synchronized.   (Before giving up, consider that UTM has multiple back-end authentication options, via Active Directory, LDAP, and RADIUS)
  • When the application is a third party product, modifying the website may void your vendor support. 
  • If the backend application cannot be configured or modified to use Basic Authentication, integrated login will also not work. 
• You also need to test to ensure that if the web browser is closed and reopened, the previous session cannot be resumed without credentials.  If this is possible, integrated authentication may make the risk even greater.