Server relocation, which involves moving your physical or virtual servers from an old location to a new location without causing significant downtime, data loss, or shutdown, can be tedious and error prone.
As an IT professional responsible for server relocation and firewall management, you play a crucial role in ensuring smooth and secure server relocation.
But how do you know which rules need to be changed? What is the most efficient and secure way to ensure connectivity? Ensuring a smooth transition requires careful planning and a contingency plan that accounts that ensures minimal downtime.
Relocating an Unnecessary, Old, or New Server
You have two choices on where to start: the firewall rule base or the traffic logs. The rule base has one obvious advantage in that it’s smaller. However, it may be challenging to figure out which rules are relevant, particularly if you’re the only IT staff in-house assigned to be the project manager.
Often, the server will not be referenced explicitly, so you need to check every rule manually. This could be tricky, mainly if your rule base has been growing for a few years and has had multiple administrators. Rule shadowing complicates things even more, which can cause tedious work, especially double-check each rule change.
The other alternative is reviewing firewall traffic logs. You can create a new rule base by identifying the traffic to and from the server over a reasonable period.
Please note that you do not need to worry about shadows; this method will enable you to build a very accurate policy that does not include many overly permissive rules. The downside of this is that you must analyze many logs.
How far do you return to ensure you’ve covered all legitimate uses? 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.
Ensure Accurate Server Relocation
Whichever way you go, here are some things to look out for:
- Over-permissive rules. Though they provide a quick fix, hackers may use them as attack vectors later.
- Access currently allowed and not required. Unnecessary access can introduce potential risks.
- Implicit connectivity. This one seems excessive but could be essential for business continuity and network connectivity, among a host of other factors.
If you have Tufin SecureTrack+, use the Automatic Policy Generator (APG) to prepare for server relocation, fun APG on firewall logs from or to the server going back a year. It will generate a set of rules that allow the actual server access during that period.
You should review it to ensure no rules stem from malicious traffic, such as a port scan (even if it runs slowly over several days), a conifer 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.
After the relocation, you can use the rule and object usage report to clean up the obsolete access rules.
Conclusion
As IT staff (or movers of servers as I like to call them) we know all too well the ramifications of data loss, downtime, and especially shutdown when we don’t properly execute server relocation. Although time-consuming and error-prone, through Tufin, you can protect data centers, and old sites and new sites alike.
To learn more about how Tufin ensures a smooth transition during server relocation and server moves, book a demo with one of our sales engineers.
We’ll cover everything from data center relocation and data backup to server functionality and protecting server equipment and new data centers.
Don't miss out on more Tufin blogs
Subscribe to our weekly blog digest