Adding new services

The Fortinet solution will have a plethora of additional features compared to your previous vendor and it is very tempting to start switching them on but it is a good idea to wait and validate the new firewall as was previously configured before adding new functions as this simplifies testing and problem diagnosis. Finally complete the migration (don’t forget about the Plan Do Check Act Cycle) by adding any new services that were requested and learn about the multiple features you have available with the FortiGate appliance.

Going live and obtaining feedback

If testing and validation is successful at this point, you can migrate to the new firewall either by switching IP’s and removing the old devices or by changing the default gateway in DHCP. Once the firewall is in place, acceptance testing will of course need to be carried out and an iterative process of tuning undertaken to finalize the configuration.

Testing and validation

This is an important process and should be tested offline first wherever possible i.e. configure the policy in the lab or on a test network and verify that the required access permissions are being implemented. To really test the solution out, the FortiGate can be implemented on the live network with a different gateway IP and the selected user pointed to the new gateway. This allows a staged approach to migrating the new platform into the network ensuring that the process does not interrupt day to day operations

Object and policy migration

Whilst we have suggested some level of manual review is included in the policy migration, it can be useful to be able to automatically migrate simply between another vendor’s format and the FortiGate format. The FortiGate policy format is text based and can easily be cut and pasted into from other vendor formats however, responding to the high customer demand to migrate away from other vendors, Fortinet have released an automatic configuration migration tool at http://convert.fortinet.com to simplify this process. Supporting Cisco ACLs, PIX, ASA, Check Point, and Juniper, the Converter can securely upload and convert the policy into the Fortinet format.

Information gathering

It is always best practice to perform a full network audit prior to any migration. This should include:

• Full back up of all security systems (including switches, routers) in case a back-out needs to be performed.
• Physical and logical network diagram with visual audit Understanding exactly where cables run in the network and verifying they are all correctly labeled is essential to avoid mistakes and unnecessary downtime during the upgrade. Don’t overlook simple things such as:
• Do I have enough spare interfaces on my switches?
• Do I have the right fiber (single/multi mode) and right connectors (LC, FC, MTRJ, SC, ST)?
• Do I have spare cables? (in the heat of the moment, it is simple mistake to break an RJ-45 connector or damage a fiber)
• Do I have space in the rack for the new equipment?
• Do I have enough power sockets?

No matter how securely a FortiGate is configured in the network, it cannot help if it has been bypassed; visually checking where the device sits in the network in relation to other devices will ensure you are maintaining security and verify the network diagram is ‘as built’. Details of all networks including subnet masks should be documented at this point to ensure that the replacement device is configured with the correct information.

Migration

Network administrators are often reluctant to change firewall vendors due to the perception that the migration process is difficult. Indeed, there is no point hiding the fact that moving to a new vendor requires careful consideration. But concern over the potential pain of migration should not stand in the way of adopting new security technologies. The purpose of this chapter is to describe the best practices for performing such migrations and ultimately to ease the migration process itself.

Shutting down

Always shut down the FortiGate operating system properly before turning off the power switch to avoid potentially catastrophic hardware problems.

To power off the FortiGate unit – web-based manager:

1. Go to System > Status.

2. In the System Resources widget, select Shutdown.

To power off the FortiGate unit – CLI: execute shutdown

Once this has been done, you can safely turn off the power switch or disconnect the power cables from the power supply.

Performance

• Disable any management features you do not need. If you don’t need SSH or SNMP, disable them. SSH also provides another possibility for would-be hackers to infiltrate your FortiGate unit.
• Put the most used firewall rules to the top of the interface list.
• Log only necessary traffic. The writing of logs, especially if to an internal hard disk, slows down performance.
• Enable only the required application inspections.
• Keep alert systems to a minimum. If you send logs to a syslog server, you may not need SNMP or email alerts, making for redundant processing.
• Establish scheduled FortiGuard updates at a reasonable rate. Daily updates occurring every 4-5 hours are sufficient for most situations. In more heavy-traffic situations, schedule updates for the evening when more bandwidth can be available.
• Keep security profiles to a minimum. If you do not need a profile on a firewall rule, do not include it.
• Keep VDOMs to a minimum. On low-end FortiGate units, avoid using them if possible.
• Avoid traffic shaping if you need maximum performance. Traffic shaping, by definition, slows down traffic.