FortiOS 6.2 Security Best Practice

Security

  • Use NTP to synchronize time on the FortiGate and the core network systems, such as email servers, web servers, and logging services.
  • Enable log rules to match corporate policy. For example, log administration authentication events and access to systems from untrusted interfaces.
  • Minimize adhoc changes to live systems, if possible, to minimize interruptions to the network. When not possible, create backup configurations and implement sound audit systems using FortiAnalyzer and FortiManager.
  • If you only need to allow access to a system on a specific port, limit the access by creating the strictest rule possible.

FortiOS 6.2 Firewall Best Practice

Firewall

  • Be careful when disabling or deleting firewall settings. Changes that you make to the firewall configuration using the GUI or CLI are saved and activated immediately.
  • Arrange firewall policies in the policy list from more specific to more general. The firewall searches for a matching policy starting from the top of the policy list and working down. For example, a very general policy matches all connection attempts. When you create exceptions to a general policy, you must add them to the policy list above the general policy.
  • Avoid using the All selection for the source and destination addresses. Use addresses or address groups. l If you remove all policies from the firewall, there are no policy matches and all connections are dropped. l If possible, avoid port ranges on services for security reasons.
  • The settings for a firewall policy should be as specific as possible. Do not use 0.0.0.0 as an address. Do not use Any as a service. Use subnets or specific IP addresses for source and destination addresses and use individual services or service groups.
  • Use a 32-bit subnet mask when creating a single host address (for example, 255.255.255.255).
  • Use logging on a policy only when necessary and be aware of the performance impact. For example, you may want to log all dropped connections but can choose to use this sparingly by sampling traffic data rather than have it continually storing log information you may not use.
  • It is possible to use security policies based on ‘any’ interface. However, for better granularity and stricter security, explicit interfaces are recommended.
  • Use the comment field to input management data, for example: who requested the rule, who authorized it, etc.
  • Avoid FQDN addresses if possible, unless they are internal. It can cause a performance impact on DNS queries and security impact from DNS spoofing.
  • For non vlan interfaces, use zones (even if you have only one single interface for members) to allow: l An explicit name of the interface to use in security policies (‘internal’ is more explicit than ‘port10’).
  • A split between the physical port and its function to allow port remapping (for instance moving from a 1G interface to a 10G interface) or to facilitate configuration translation, as performed during hardware upgrades.

FortiOS 6.2 – Firmware Best Practices

Firmware

Firmware upgrading and downgrading sounds pretty simple, anyone can do it, right? The mark of a professional is not that they can do something correctly, or even do it correctly over and over again. A professional works in such a way that, if anything goes wrong they are prepared and able to quickly get things back to normal. Firmware updates can go wrong just like anything else. So a real professional does things in a way that minimizes their risk and follows some best practices, as listed below.

Firmware change management

Consider the following five points when performing firmware upgrades, not only in FortiOS but in general. This applies to pretty much any change you have to do in a production environment.

Understanding the new version first

Before attempting any changes in production, first make sure you set up a laboratory where you can freely play with the new features, and understand them with enough time and no pressure. Read the Release Notes, Manuals, and other documentation like presentations, videos, or podcasts about the new version.

You are ready to explain the need for an upgrade once you understand:

l The differences and the enhancements between the new version and the previous version(s). l The impact of the upgrade on customers and the users of the operating platform. l The known limitations that might affect your environment. l The potential risks when performing the upgrade. l The licensing changes that may apply.

Have a valid reason to upgrade

The reason can NOT be “Because I want to have the latest version”. The reason has to be explained in terms of business, technical, and/or operational improvement.

Affirmative answers to the following questions are valid reasons to upgrade:

  • Does the new version have a feature that helps to ensure compliance?
  • Does the new version have an enhancement that allows 40% decrease (40% improvement) on the time to perform a certain operation?
  • Does the new feature correct a known defect/bug found on a previous version that affects the company business/operations?
  • Will the new version allow your organization to deploy new services that will help to gain new customers or increase loyalty of existing ones? l Is the vendor cutting support for the version your organization is currently using?

If the best reason to upgrade is “Because the new features seem to be cool” or “Because I want to have the latest version”, a little more understanding and planning may be necessary.

Prepare an upgrade plan

If you choose to upgrade because you found a valid reason to do so, make sure you create a plan that covers business, technical, and operational aspects of the upgrade:

Business:

Proper planning and justification for an upgrade should be proportional to how critical the system is to the business.

  • Make sure you can clearly articulate the benefits of the upgrade in business terms (time, money, and efficiency). l Understand the business processes that will be affected by the change.
  • Make sure the upgrade maintenance window is not close to a business-critical process (such as quarterly or monthly business closure).
  • Obtain executive and operational approval for the maintenance window. The approval must come from the owners of ALL the systems/information affected by the upgrade, not only from those that own the system being upgraded.

The approval must be done in a formal (written or e-mail) form.

Technical and operational:

  • Re-read the Release Notes for the technology you are upgrading. Supported hardware models, upgrade paths, and known limitations should be clearly understood.
  • Make sure your upgrade maintenance window does not overlap with any other maintenance window on your infrastructure.
  • If you have any premium support offer (such as TAM, Premium Support), do a capacity planning exercise to ensure the new firmware/software version does not take more hardware resources than you currently have.
  • Create a backup, whether or not you have scheduled backups. Create a new fresh backup. l Obtain offline copies of both the currently installed firmware and the new version.
  • Create a list of systems with inter-dependencies to the system you are upgrading. For example, if you are upgrading a FortiGate; understand the impact on any FortiAP, FortiAuthenticator, FortiToken, FortiManager, or FortiAnalyzer you have on your environment. l Ensure you have a list of adjacent devices to the upgrading platform and have administrative access to them, just in case you need to do some troubleshooting. Are you upgrading FortiWeb? Make sure you can administratively access the Web Applications. Are you upgrading a FortiGate? Make sure you can administratively access the surrounding switches and routers.
  • Have a step-by-step plan on how to perform and test the upgrade. You want to make sure you think of the worst situation before it happens, and have predefined courses of action, instead of thinking under pressure when something already went wrong.
  • Define a set of tests (that include critical business applications that should be working) to make sure the upgrade went fine. If any test does not go well, define which ones mandate a rollback and which ones can be tolerated for further troubleshooting. This set of tests should be run before and after the upgrade to compare results, and they should be the same.
  • Define a clear rollback plan. If something goes wrong with the upgrade or the tests, the rollback plan will help you get your environment back to a known and operational status. The plan must clearly state the conditions under which the rollback will be started.
  • Declare configuration freezes. A little bit before and after the upgrade. The idea is to reduce the amount of variables to take into consideration if something goes wrong.
  • Perform a “Quality Assurance” upgrade. Grab a copy of the production configuration, load it on a non-production box and execute the upgrade there to see if there are any issues on the process. Then adjust your plan according to the results you obtained.
  • Have a list of information elements to be gathered if something goes wrong. This ensures that, even if the upgrade fails, you will collect enough information so you can troubleshoot the issue without needing to repeat the problem. Get help from Fortinet Support if you need to check what else could be missing on your list.
  • Define a test monitoring period after the change was completed. Even if the upgrade went smoothly, something could still go wrong. Make sure you monitor the upgraded system for at least one business cycle. Business cycles may be a week, a month, or a quarter, depending on your organization’s business priorities.

Execute the upgrade plan

Execution of an upgrade is just as key as planning.

Once you are performing the upgrade, the pressure will rise and stress might peak. This is why you should stick to the plan you created with a cool head.

Resist the temptation to take decisions while performing the upgrade, as your judgment will be clouded by the stress of the moment, even if a new decision seems to be “obvious” at such time. If your plan says you should rollback, then execute the rollback despite the potential “We-can-fix-this-very-quickly” mentality.

While performing the upgrade, make sure all the involved components are permanently monitored before, during, and after the upgrade, either via monitoring systems, SNMP alerts, or at least with tools like a ping. Critical resources like CPU, memory, network, and/or disk utilization must also be constantly monitored.

To avoid misunderstandings, when performing the tests for each critical application defined on the planning, make sure there are formal notifications on the results for each user area, service, system, and/or application tested.

Regardless if you have to rollback or not, if a problem occurs, make sure you gather as much information about the problem as possible, so you can later place a Support ticket to find a solution.

Last but not least, document the upgrade:

  • Enable your terminal emulation program to leave trace of all the commands executed and all the output generated. If you are performing steps via GUI, consider using a video capture tool to document it. l Document any command or change performed over the adjacent/interdependent systems. Make sure they are acknowledged by the relevant administrators
  • Document any deviations performed over the upgrade plan. This is planned-versus-actual.

Learn more about change management

Change Management and Change Control are huge knowledge areas in the field of Information Systems and Computer/Network Security.

This document is by no means a comprehensive list on what you should do when performing an upgrade, with either

Fortinet or any other technology. It is merely a list of important things you should take into consideration when

performing upgrades which are the result of years of experience dealing with changes on critical environments, as it is common that security devices are protecting critical applications and processes.

There are vast resources on the topic: books, public white papers, blog entries, etc. If you search the Internet for the “Change Control Best Practices” or “Change Management Best Practices” you will get many interesting documents.

Performing a firmware upgrade

Upgrading a firewall is something that should be compared to upgrading the operating system on your computer. It’s not to be taken lightly! You want to make sure everything is backed up and you have some options available if things go awry. Assuming it all seems to work you also want a list of things to do in order to confirm everything is working properly. Finally, you need enough time to do it. All really simple stuff, but what does this mean in relation to upgrading your FortiGate? It means, you follow these simple steps:

  1. Backup and store old configuration (full configuration backup from CLI).

Digging into this a little, step 1 is easy to understand. Do a full backup of your old configuration. This is all part of your disaster recovery plan. If the upgrade fails in some way you need to make sure you can get the Firewall back up and running. The best way to do this is to get it back to a state where you know what the behavior was. For more information, refer to Performing a configuration backup on page 18.

  1. Have copy of old firmware available.

Step 2, is also part of your disaster recovery. If the upgrade fails you might be able to switch the active partition. But as a Professional, you need to be prepared for the worst case scenario where you can’t do that. Which means you’ll need your old firmware.

  1. Have disaster recovery option on standby — especially if remote.

Step 3, is your plan for what to do in the event of a critical failure. As we’re talking FortiGate this means that your firewall doesn’t come back after the upgrade. What this means is that you need to be able to get to the console port in order to find out why. Maybe it’s DHCP and the IP changed, maybe the OS is corrupt, who knows? Get to the console and find out.

There could be a simple fix. If there’s not, then be prepared for a format and TFTP reload.

  1. Read the release notes, including the upgrade path and bug information.

Step 4, READ THE RELEASE NOTES. They contain all kinds of information, known bugs, fixed bugs even upgrade issues like lost configuration settings. Not all upgrade information is ever contained in any products release notes. That does not mean they are devoid of good/useful information. Read them, digest them, then a few days later read them again.

  1. Double check everything.

Step 5, do a double check of everything. Is your TFTP server working, does your console connection function, is there anything in the release notes that could impact your upgrade procedure, do you have your configuration backed up? Make sure you’ve done everything.

Step 6, do the upgrade. Doing an upgrade doesn’t take very long, a few minutes (less a lot of times) but make sure you schedule enough time for it. At the end of the day an upgrade can succeed or fail. If it succeeds you want some time to check/confirm that any important features you have are working (VPNs etc). If it fails you’ll need time to sort things out.

Performing a firmware downgrade

Just like upgrading, you need to make sure it’s done properly. While similar, the steps are somewhat different since there are other pitfalls in this case.

  1. Locate pre-upgrade configuration file.

Step 1 is very important. This is why, when you upgrade you make a backup of your old configuration and save it. If you don’t, then you’ll need to rebuild manually.

  1. Have copy of old firmware available.

Step 2 is fairly obvious. Even with devices that have multiple partitions and your downgrade process is simply going to be to switch the active partition, this could go wrong. In which case, you may be without Internet access. A professional has a plan for when things go wrong.

  1. Have disaster recovery option on standby — especially if remote.

Step 3 is no different from before. Hopefully you don’t need to format the unit, but be prepared for that, just in case.

  1. Read the release notes — is a downgrade possible, or necessary?

Step 4, once again, is to READ THE RELEASE NOTES. In this case, you will need to do this for the version you are on, and the version you are downgrading too, and everything in between (if you are going back multiple major releases or patches). Maybe the OS switched from 32 to 64 bits somewhere between the two firmware releases. In order to make sure you don’t get nailed by something like that you need to check the upgrade and downgrade information in every major release and patch, as it may have a direct impact on your options.

  1. Double check everything.
  2. Downgrade — all settings, except those needed for access, are lost.

Step 5 and 6 are the same as before. Double check everything, then downgrade.

  1. Restore pre-upgrade configuration.

Step 7 is new. Obviously most settings are lost when you downgrade so in order to get back up and running you will need to restore your old configuration file.

Performing a configuration backup

Once you configure the FortiGate unit and it is working correctly, it is extremely important that you backup the configuration. In some cases, you may need to reset the FortiGate unit to factory defaults or perform a TFTP upload of the firmware, which will erase the existing configuration. In these instances, the configuration on the device will have to be recreated, unless a backup can be used to restore it.

It is also recommended that once any further changes are made that you backup the configuration immediately, to ensure you have the most current configuration available. Also, ensure you backup the configuration before upgrading the FortiGate unit’s firmware. Should anything happen during the upgrade that changes the configuration, you can easily restore the saved configuration.

Always backup the configuration and store it on the management computer or off-site. You have the option to save the configuration file to various locations including the local PC, USB key, FTP and TFTP site.The latter two are configurable through the CLI only.

If you have VDOMs, you can back up the configuration of the entire FortiGate unit or only a specific VDOM. Note that if you are using FortiManager or FortiCloud, full backups are performed and the option to backup individual VDOMs will not appear.

To back up the FortiGate configuration – GUI:

  1. Go to Dashboard.
  2. On the System Information widget, select Backup next to System Configuration.
  3. Select to backup to your Local PC or to a USB Disk.

The USB Disk option will be grayed out if no USB drive is inserted in the USB port. You can also backup to the FortiManager using the CLI.

  1. If VDOMs are enabled, select to backup the entire FortiGate configuration (Full Config) or only a specific VDOM configuration (VDOM Config).
  2. If backing up a VDOM configuration, select the VDOM name from the list.
  3. Select Encrypt configuration file.

Encryption must be enabled on the backup file to back up VPN certificates.

  1. Enter a password and enter it again to confirm it. You will need this password to restore the file.
  2. Select Backup.
  3. The web browser will prompt you for a location to save the configuration file. The configuration file will have a .conf extension.

To back up the FortiGate configuration – CLI:

execute backup config management-station <comment>

… or …

execute backup config usb <backup_filename> [<backup_password>] … or for FTP (note that port number, username are optional depending on the FTP site)… execute backup config ftp <backup_filename> <ftp_server> [<port>] [<user_name>] [<password>]

… or for TFTP … execute backup config tftp <backup_filename> <tftp_servers> <password> Use the same commands to backup a VDOM configuration by first entering the commands:

config vdom edit <vdom_name>

Backing up a configuration file using SCP

You can use secure copy protocol (SCP) to download the configuration file from the FortiGate unit as an alternative method of backing up the configuration file or an individual VDOM configuration file. This is done by enabling SCP for and administrator account and enabling SSH on a port used by the SCP client application to connect to the FortiGate unit. SCP is enabled using the CLI commands:

config system global set admin-scp enable end

Use the same commands to backup a VDOM configuration by first entering the commands:

config global

set admin-scp enable

end config vdom

edit <vdom_name>

 

FortiOS 6.2 Best Practices

General considerations

  1. For security purposes, NAT mode is preferred because all of the internal or DMZ networks can have secure private addresses. NAT mode policies use network address translation to hide the addresses in a more secure zone from users in a less secure zone.
  2. Use virtual domains (VDOMs) to group related interfaces or VLAN subinterfaces. Using VDOMs will partition networks and create added security by limiting the scope of threats.
  3. Use transparent mode when a network is complex and does not allow for changes in the IP addressing scheme.

System and performance

By implementing the following best practices for system and performance, you will ensure maximum efficiency of your FortiGate device. Be sure to read everything carefully, particularly the section that concerns shutting down the FortiGate system, in order to avoid potential hardware issues.

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. l Log only necessary traffic. The writing of logs, especially if to an internal hard disk, slows down performance. l 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. l Keep VDOMs to a minimum. On low-end FortiGate units, avoid using them if possible. l Avoid traffic shaping if you need maximum performance. Traffic shaping, by definition, slows down traffic.

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 – GUI:

  1. Go to Dashboard.
  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.

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.

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. l 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? l 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 a simple mistake to break an RJ-45 connector or damage a fiber) l Do I have space in the rack for the new equipment? l 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.

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.

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.

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.

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.

FSSO Examples and troubleshooting

Examples and troubleshooting

This chapter provides an example of a FortiGate unit providing authenticated access to the Internet for both Windows network users and local users. The following topics are included in this section:

l Firewall authentication example l LDAP dial-in using member-attribute example l RADIUS SSO example l Troubleshooting

Firewall authentication example

Example configuration

Overview

In this example, there is a Windows network connected to Port 2 on the FortiGate unit and another LAN, Network_1, connected to Port 3.

All Windows network users authenticate when they logon to their network. Members of the Engineering and Sales groups can access the Internet without entering their authentication credentials again. The example assumes that the Fortinet Single Sign On (FSSO) has already been installed and configured on the domain controller.

LAN users who belong to the Internet_users group can access the Internet after entering their username and password to authenticate. This example shows only two users, User1 is authenticated by a password stored on the FortiGate unit, User2 is authenticated on an external authentication server. Both of these users are referred to as local users because the user account is created on the FortiGate unit.

Creating a locally-authenticated user account

User1 is authenticated by a password stored on the FortiGate unit. It is very simple to create this type of account.

To create a local user – web-based manager:

  1. Go to User & Device > User Definition and select Create New.
  2. Follow the User Creation Wizard, entering the following information and then select Create:
User Type Local User
User Name User1
Password hardtoguess
Email Address

SMS

(optional)
Enable Select.

To create a local user – CLI:

config user local edit user1 set type password set passwd hardtoguess

end

Creating a RADIUS-authenticated user account

To authenticate users using an external authentication server, you must first configure the FortiGate unit to access the server.

To configure the remote authentication server – web-based manager:

  1. Go to User & Device > RADIUS Servers and select Create New.
  2. Enter the following information and select OK:
Name OurRADIUSsrv
Primary Server Name/IP 10.11.101.15
Primary Server Secret OurSecret
Authentication Scheme Select Use Default Authentication Scheme.

To configure the remote authentication server – CLI:

config user radius edit OurRADIUSsrv set server 10.11.102.15 set secret OurSecret

Firewall authentication

set auth-type auto

end

Creation of the user account is similar to the locally-authenticated account, except that you specify the RADIUS authentication server instead of the user’s password.

To configure a remote user – web-based manager:

  1. Go to User & Device > User Definition and select Create New.
  2. Follow the User Creation Wizard, entering the following information and then select Create:
User Type Remote RADIUS User
User Name User2
RADIUS server OurRADIUSsrv
Email Address

SMS

(optional)
Enable Select

To configure a remote user – CLI:

config user local edit User2 set name User2 set type radius

set radius-server OurRADIUSsrv

end

Creating user groups

There are two user groups: an FSSO user group for FSSO users and a firewall user group for other users. It is not possible to combine these two types of users in the same user group.

Creating the FSSO user group

For this example, assume that FSSO has already been set up on the Windows network and that it uses Advanced mode, meaning that it uses LDAP to access user group information. You need to

  • configure LDAP access to the Windows AD global catalog l specify the collector agent that sends user logon information to the FortiGate unit l select Windows user groups to monitor
  • select and add the Engineering and Sales groups to an FSSO user group

To configure LDAP for FSSO – web-based manager:

  1. Go to User & Device > LDAP Servers and select Create New.
  2. Enter the following information:
Name ADserver
Server Name / IP 10.11.101.160
Distinguished Name dc=office,dc=example,dc=com
Bind Type Regular
User DN cn=FSSO_Admin,cn=users,dc=office,dc=example,dc=com
Password Enter a secure password.
  1. Leave other fields at their default values.
  2. Select OK.

To configure LDAP for FSSO – CLI”

config user ldap edit “ADserver” set server “10.11.101.160”

set dn “cn=users,dc=office,dc=example,dc=com”

set type regular

set username “cn=administrator,cn=users,dc=office,dc=example,dc=com” set password set_a_secure_password

next

end

To specify the collector agent for FSSO – web-based manager:

  1. Go to Security Fabric > Fabric Connectors and select Create New.
  2. Under SSO/Identity, select Fortinet Single Sign-On Agent.
  3. Enter a Name (in this example, WinGroups) for the Windows AD server. This name appears in the list of Windows AD servers when you create user groups.
  4. Enter the Server IP/Name (in this example, 10.11.101.160) and Password (in this example, fortinet_canada) of the server where this agent is installed. Maximum name length is 63 characters. For the collector agent, passwords are only required only if you configured the agent to require authenticated access. If the TCP port used for FSSO is not the default, 8000, you can change the setting in the CLI using the config user fsso See Examples and troubleshooting on page 203.
  5. Set Collector Agent AD access mode to Advanced, and select the LDAP Server (in this example, ADserver) you configured previously. See Examples and troubleshooting on page 203.
  6. Select the Users or Groups or Organizational Units tab to select the users, groups, OU that you want to monitor.
  7. Select OK.

To specify the collector agent for FSSO – CLI:

config user fsso edit “WinGroups” set ldap-server “ADserver” set password ENC

G7GQV7NEqilCM9jKmVmJJFVvhQ2+wtNEe9T0iYA5Sa+EqT2J8zhOrbkJFDr0RmY3c4LaoXdsoBczA

1dONmcGfthTxxwGsigzGpbJdC71spFlQYtj set server “10.11.101.160” end

Firewall authentication

To create the FSSO_Internet-users user group – web-based manager:

  1. Go to User & Device > User Groups and select Create New.
  2. Enter the following information and then select OK:
Name FSSO_Internet_users
Type Fortinet Single Sign-On (FSSO)
Members Engineering, Sales

To create the FSSO_Internet-users user group – CLI:

config user group edit FSSO_Internet_users set group-type fsso-service

set member CN=Engineering,cn=users,dc=office,dc=example,dc=com

CN=Sales,cn=users,dc=office,dc=example,dc=com end

Creating the firewall user group

The non-FSSO users need a user group too. In this example, only two users are shown, but additional members can be added easily.

To create the firewall user group – web-based manager:

  1. Go to User & Device > User Groups and select Create New.
  2. Enter the following information and then select OK:
Name Internet_users
Type Firewall
Members User1, User2

To create the firewall user group – CLI:

config user group edit Internet_users set group-type firewall set member User1 User2

end

Defining policy addresses

  1. Go to Policy & Objects > Addresses.
  2. Create the following addresses:
Address Name Internal_net
Type Subnet
Subnet / IP Range 10.11.102.0/24
Interface Port 3
Address Name Windows_net
Type Subnet
Subnet / IP Range 10.11.101.0/24
Interface Port 2

Creating security policies

Two security policies are needed: one for firewall group who connect through port3 and one for FSSO group who connect through port2.

To create a security policy for FSSO authentication – web-based manager:

  1. Go to Policy & Objects > IPv4 Policy and select Create New.
  2. Enter the following information:
Incoming Interface Port2
Source Address Windows_net
Source User(s) FSSO_Internet_users
Outgoing Interface Port1
Destination Address all
Schedule always
Service ALL
NAT ON
Security Profiles Optionally, enable security profiles.
  1. Select OK.

To create a security policy for FSSO authentication – CLI:

config firewall policy edit 0 set srcintf port2 set dstintf port1 set srcaddr Windows_net set dstaddr all

LDAP dial-in using member-attribute

set action accept set groups FSSO_Internet_users set schedule always set service ANY set nat enable

end

To create a security policy for local user authentication – web-based manager:

  1. Go to Policy & Objects > IPv4 Policy and select Create New.
  2. Enter the following information:
Incoming Interface Port3
Source Address Internal_net
Source User(s) Internet_users
Outgoing Interface Port1
Destination Address all
Schedule always
Service ALL
NAT ON
Security Profiles Optionally, enable security profiles.
  1. Select OK.

To create a security policy for local user authentication – CLI:

config firewall policy edit 0 set srcintf port3 set dstintf port1 set srcaddr internal_net set dstaddr all set action accept set schedule always set groups Internet_users set service ANY set nat enable

end

LDAP dial-in using member-attribute example

In this example, users defined in MicroSoft Windows Active Directory (AD) are allowed to set up a VPN connection simply based on an attribute that is set to TRUE, instead of based on their user group. In AD the “Allow Dialin” property is activated in the user properties, and this sets the msNPAllowDialin attribute to “TRUE”.

 

LDAP dial-in using member-attribute example

This same procedure can be used for other member attributes, as your system requires.

To accomplish this with a FortiGate unit, member-attribute must be set. This can only be accomplished through the CLI – the option is not available through the web-based manager.

Before configuring the FortiGate unit, ensure the AD server has the msNPAllowDialin attribute set to “TRUE” for the users in question. If not, those users will not be able to authenticate.

To configure user LDAP member-attribute settings – CLI:

config user ldap edit “ldap_server” set server “192.168.201.3” set cnid “sAMAccountName” set dn “DC=fortilabanz,DC=com,DC=au” set type regular

set username “fortigate@sample.com” set password ****** set member-attr “msNPAllowDialin”

next

end

To configure LDAP group settings – CLI:

config user group edit “ldap_grp” set member “ldap” config match edit 1 set server-name “ldap” set group-name “TRUE”

next

end

next

end

Once these settings are in place, users that are a member of the ldap user group will be able to authenticate.

To ensure your settings are correct, here is the sample output from a diag debug command that shows the authentication process.

When the “Allow Dial-in” attribute is set to “TRUE” the following will likely be in the output:

get_member_of_groups-Get the memberOf groups. get_member_of_groups- attr=’msNPAllowDialin’, found 1 values

get_member_of_groups-val[0]=’TRUE’ fnbamd_ldap_get_result-Auth accepted fnbamd_ldap_get_result-Going to DONE state res=0

fnbamd_auth_poll_ldap-Result for ldap svr 192.168.201.3 is SUCCESS fnbamd_auth_poll_ldap-Passed group matching

If the attribute is not set but it is expected, the following will likely be in the output:

get_member_of_groups-Get the memberOf groups. get_member_of_groups- attr=’msNPAllowDialin’, found 1 values

get_member_of_groups-val[0]=’FALSE’ fnbamd_ldap_get_result-Auth accepted fnbamd_ldap_get_result-Going to DONE state res=0

fnbamd_auth_poll_ldap-Result for ldap svr 192.168.201.3 is SUCCESS fnbamd_auth_poll_ldap-Failed group matching

The only difference between these two outputs is the last line which is either passed or failed based on if the member-attribute is set to the expected value or not.

RADIUS SSO example

A common RADIUS SSO topology involves a medium sized company network of users connecting to the Internet through the FortiGate unit, and authenticating with a RADIUS server. RADIUS SSO authentication was selected because it is fast and relatively easy to configure.

This section includes:

l Assumptions l Topology l Configuring RADIUS l Configuring FortiGate regular and RADIUS SSO security policies l Testing

Assumptions

  • VDOMs are not enabled. l The admin super_admin administrator account will be used for all FortiGate unit configuration. l Any other devices on the network do not affect the topology of this example, and therefore are not included. l Anywhere settings are not described, they are assumed to be default values. l A RADIUS server is installed on a server or FortiAuthenticator unit and uses default attributes.
  • BGP is used for any dynamic routing. l Authentication event logging under Log & Report has been configured.

Topology

Example.com has an office with 20 users on the internal network. These users need access to the Internet to do their jobs. The office network is protected by a FortiGate-60C unit with access to the Internet through the wan1 interface, the user network on the internal interface, and all the servers are on the DMZ interface. This includes an Ubuntu Linux server running FreeRADIUS. For this example only two users will be configured — Pat Lee with an account name plee, or plee@example.com, and Kelly Green with an account name kgreen, or kgreen@example.com.

RADIUS SSO topology

Configuring RADIUS

Configuring RADIUS includes configuring the RADIUS server such as FreeRADIUS, a radius client on user’s computers, and configuring users in the system. For this example the two users will be Pat Lee, and Kelly Green. They belong to a group called exampledotcom_employees. When it is all configured, the RADIUS daemon needs to started.

The users have a RADIUS client installed on their PCs that allows them to authenticate through the RADIUS server.

FreeRADIUS can be found on the freeradius.org website. For any problems installing FreeRADIUS, see the FreeRADIUS documentation.

Configuring FortiGate interfaces

Before configuring the RADIUS SSO security policy, configure FortiGate interfaces. This includes defining a DHCP server for the internal network as this type of network typically uses DHCP. The wan1 and dmz interfaces are assigned static IP addresses and do not need a DHCP server.

FortiGate interfaces used in this example

Interface Subnet Act as DHCP Server Devices
wan1 172.20.120.141 No Internet Service Provider
dmz 10.11.101.100 No Servers, including RADIUS server
internal 10.11.102.100 Yes: x.x.x.110-.250 Internal user network

To configure FortiGate interfaces – web-based manager:

  1. Go to Network > Interfaces.
  2. Select wan1 to edit.
  3. Enter the following information and select OK.
Alias Internet
Addressing Mode Manual
IP/Network Mask 172.20.120.141/255.255.255.0
Administrative Access HTTPS, SSH
Enable DHCP Server Not selected
Comments Internet
Administrative Status Up
  1. Select dmz to edit.
  2. Enter the following information and select OK.
Alias Servers
Addressing Mode Manual
IP/Network Mask 10.11.101.100/255.255.255.0
Administrative Access HTTPS, SSH, PING, SNMP
Enable DHCP Server Not selected
Listen for RADIUS

Accounting Messages

Select
Comments Servers
Administrative Status Up
  1. Select internal to edit.
  2. Enter the following information and select OK.
Alias Internal network
Addressing Mode Manual
IP/Network Mask 10.11.102.100/255.255.255.0
Administrative Access HTTPS, SSH, PING
Enable DHCP Server Select
Address Range 10.11.102.110 – 10.11.102.250
Netmask 255.255.255.0
Default Gateway Same as Interface IP
DNS Server Same as System DNS
Comments Internal network
Administrative Status Up

Configuring a RADIUS SSO agent on the FortiGate unit

To create a RADIUS SSO agent:

  1. Go to Security Fabric > Fabric Connectors and select Create New.
  2. Under SSO/Identity, select RADIUS Single Sign-On Agent.
  3. Enter a name for the RSSO Agent.
  4. Enable Use RADIUS Shared Secret and enter the RADIUS server’s shared secret.
  5. Enable Send RADIUS Responses.
  6. Select OK.

Creating a RADIUS SSO user group

To define a local user group for RADIUS SSO:

  1. Go to User & Device > User Groups and select Create New.
  2. Enter a Name for the user group.
  3. In Type, select RADIUS Single Sign-On (RSSO).
  4. In RADIUS Attribute Value, enter the name of the RADIUS user group this local user group represents.
  5. Select OK.

Configuring FortiGate regular and RADIUS SSO security policies

With the RADIUS server and FortiGate interfaces configured, security policies can be configured. This includes both RADIUS SSO and regular policies, as well as addresses and address groups. All policies require NAT to be enabled.

Security policies required for RADIUS SSO

Seq. No. From -> To Type Schedule Description
1 internal -> wan1 RADIUS SSO business hours Authenticate outgoing user traffic.
2 internal -> wan1 regular always Allow essential network services and VoIP.
3 dmz -> wan1 regular always Allow servers to access Internet.
Seq. No. From -> To Type Schedule Description
4 internal ->

dmz

regular always Allow users to access servers.
5 any -> any deny always Implicit policy denying all traffic that hasn’t been matched.

The RADIUS SSO policy must be placed at the top of the policy list so it is matched first. The only exception to this is if you have a policy to deny access to a list of banned users. In this case, that policy must go at the top so the RADIUS SSO does not mistakenly match a banned user or IP address.

This section includes:

l Schedules, address groups, and services groups l Configuring regular security policies l Configuring RADIUS SSO security policy

Schedules, address groups, and services groups

This section lists the lists that need to be configured before security policies are created. Creating these lists is straight forward, so the essential information has been provided here but not step by step instructions. For more information on firewall related details, see

Schedules

Only one schedule needs to be configured — business_hours. This is a fairly standard Monday to Friday 8am to 5pm schedule, or whatever days and hours covers standard work hours at the company.

Address groups

The following address groups need to be configured before the security policies.

Address Group Name Interface Address range included
internal_network internal 10.11.102.110 to 10.11.102.250
company_servers dmz 10.11.101.110 to 10.11.101.250

Service groups

The following service groups need to be configured before the security policies. Note that the services listed are suggestions and may include more or less as required.

Service Group Name Interface Description of services to be included
essential_network_services internal Any network protocols required for normal network operation such as DNS, NTP, BGP.
essential_server_services dmz All the protocols required by the company servers such as BGP, HTTP, HTTPS, FTP, IMAP, POP3, SMTP, IKE, SQL, MYSQL, NTP, TRACEROUTE, SOCKs, and SNMP.
user_services internal Any protocols required by users HTTP, HTTP, FTP,

The following security policy configurations are basic and only include logging, and default AV and IPS.

Configuring regular security policies

Regular security policies allow or deny access for non-RADIUS SSO traffic. This is essential as there are network services—such as DNS, NTP, and FortiGuard—that require access to the Internet.

To configure regular security policies – web-based manager:

  1. Go to Policy & Objects > IPv4 Policy, and select Create New.
  2. Enter the following information, and select OK.
Incoming Interface Internal
Source Address internal_network
Outgoing Interface wan1
Destination Address all
Schedule always
Service essential_network_services
Action ACCEPT
NAT ON
Security Profiles ON: AntiVirus, IPS
Log Allowed Traffic ON
Comments Essential network services
  1. Select Create New, enter the following information, and select OK.
Incoming Interface   dmz
Source Address company_servers
Outgoing Interface wan1
Destination Address all
Schedule always
Service essential_server_services
Action ACCEPT
NAT ON
Security Profiles ON: AntiVirus, IPS
Log Allowed Traffic enable
Comments Company servers accessing the Internet
  1. Select Create New, enter the following information, and select OK.
Incoming Interface Internal
Source Address internal_network
Outgoing Interface dmz
Destination Address company_servers
Schedule always
Service all
Action ACCEPT
NAT ON
Security Profiles ON: AntiVirus, IPS
Log Allowed Traffic enable
Comments Access company servers

Configuring RADIUS SSO security policy

The RADIUS SSO policy allows access for members of specific RADIUS groups.

To configure RADIUS SSO security policy:

  1. Go to Policy & Objects > IPv4 Policy.
  2. Select Create New.
  3. Enter the following information:
Incoming Interface Internal
Source Address internal_network
Source User(s) Select the user groups you created for RSSO.
Outgoing Interface wan1
Destination Address all
Schedule business_hours
Service ALL
Action ACCEPT
NAT ON
Security Profiles ON: AntiVirus, Web Filter, IPS, and Email Filter. In each case, select the default profile.
  1. Select OK.
  2. To ensure an RSSO-related policy is matched first, the policy should be placed higher in the security policy list than more general policies for the same interfaces.
  3. Select OK.

Testing

Once configured, a user only needs to log on to their PC using their RADIUS account. After that when they attempt to access an Internet website, the FortiGate unit will use their session information to get their RADIUS information. Once the user is verified, they are allowed access to the website.

To test the configuration perform the following steps:

  1. Have user ‘plee’ logon to their PC, and try to access an Internet website.
  2. The FortiGate unit will contact the RADUS server for user plee’s information. Once confirmed, plee will have access to the website.

Each step generates log entries that enable you to verify that each step was successful.

  1. If a step is unsuccessful, confirm that your configuration is correct.

 

Troubleshooting

RADIUS SSO test

Troubleshooting

In the web-based manager, a good tool for troubleshooting is the packet counter column on the security policy page at Policy & Objects > IPv4 Policy. This column displays the number of packets that have passed through this security policy. Its value when you are troubleshooting is that when you are testing your configuration (end to end connectivity, user authentication, policy use) watching the packet count for an increase confirms any other methods you may be using for troubleshooting. It provides the key of which policy is allowing the traffic, useful information if you expect a user to require authentication and it never happens.

This section addresses how to get more information from the CLI about users and user authentication attempts to help troubleshoot failed authentication attempts. diag firewall iprope list

Shows the IP that the computer connected from. This is useful to confirm authorization and VPN settings.

diag firewall iprope clear

Clear all authorized users from the current list. Useful to force users to re-authenticate after system or group changes. However, this command may easily result in many users having to re-authenticate, so use carefully.

diag rsso query ip diag rsso query rsso-key

Queries the RSSO database.