Tufin Firewall Expert Tip #1: Relocating a Server


An IT group needs to move a server and you need to update the firewall policy. The question is this: Which rules need to be changed? What is the fastest and safest way to get the job done?

You have two choices on where to start: the firewall rule base or the traffic logs. The rule base has one obvious advantage – it’s smaller. But it may be difficult to figure out which rules are relevant. Often the server will not be referenced explicitly, so you need to manually check every rule. This could be a tricky task, particularly if your rule base has been growing for a few years and has had multiple administrators. Rule shadowing complicates things even more.

The other alternative is reviewing firewall traffic logs. By identifying the traffic to and from the server over a reasonable period of time, you can create a new rule base. You do not need to worry about shadowing and potentially, this method will enable you to build a very accurate policy that does not include a lot of overly permissive rules. The downside is the large number of logs that must be analyzed. How far do you need to go back to make sure you’ve covered all legitimate use? One month? Three months? A year? What about your disaster recovery hot site traffic? Remember, you won’t have any logs for that unless you have tested your failover.

Whichever way you go, here are some things to look out for:

  • Creating over-permissive rules. Though they provide a quick fix, hackers may use them as attack vectors later on.
  • Access that is currently allowed and not really required.
  • Implicit connectivity that seems superfluous but could actually be essential for business continuity.

If you have Tufin SecureTrack™, try using the Automatic Policy Generator (APG) to prepare for server relocation. Run APG on firewall logs from or to the server going back a year. It will generate a set of rules that allows the actual server access that took place during that period.

You should review it to make sure there are no rules that stem from malicious traffic, such as a port scan, (even if it runs slowly over several days), a conficker virus or a generic botnet.Change the server’s address to the new one and implement the new rules on relevant firewalls above any potentially blocking rules – you can consult with SecureTrack’s Policy Analysis tool or the Policy Change Advisor in SecureChange™ Workflow. After the relocation is done, you can use the rule and object usage report to clean up the obsolete access rules.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: