Page tree


The Fortinet firewall OS does not have the ability to run scripts that perform DNS resolution, therefore management of ThreatSTOP security must be done externally using a Linux server or VM that can connect to the firewall via SSH. ThreatSTOP provides scripts to manage ThreatSTOP on Fortinet and a Virtual appliance (VM). The VM queries for your ThreatSTOP policy and populates the policy to address groups on your firewall. The scripts are written in Perl and will only run in a UNIX environment. The VM will also create access logs from your Fortinet appliance and upload these logs to ThreatSTOP for processing and report generation.


  • If this is a new device, please allow up to 15 minutes for our systems to be updated.
  • We recommend using our VM appliance but if you have an existing Linux syslog server then that may be used.


Quick Setup

Cut and paste the following line into your CLI. Your device will then setup files and run the script to begin protecting your network.

curl -o ts-fortinet.tar.gz | tar xzvf ts-fortinet.tar.gz ; cd ts-fortinet; ./ -i '<Device IP>' -b <block list name>..threatstop.local -a <allow list name>..threatstop.local

Setting up ThreatSTOP on FortiGate devices does have a few prerequisites. The most important being the version of FortiOS currently installed on the Firewall. At this time only FortiOS 5.0 build 292 (GA Patch 9) is supported by ThreatSTOP. Additionally:

  • You should have a VMware environment or an existing Linux server with syslog-ng set up.
    We recommend that you download and install our preconfigured VM Appliance by following these instructions.
  • Verify that the appliance can connect to the Fortinet device via SSH. You don't need to actually login. You can type CTRL-C when the password prompt comes up.

    threatstop@tsclient:~$ ssh
    The authenticity of host '' can't be established.
    RSA key fingerprint is 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added '<IP Address>' (RSA) to the list of known hosts.
    user@<IP Address>'s password: ^C

  • You should also confirm that the appliance can also access/download files from the Internet. In particular you should check that your appliance can reach ThreatSTOP to do this enter the following command from a terminal behind the device:


  • The following command will download any missing Perl libraries that you will need to run the script on Ubuntu.

    sudo apt-get install libnet-cidr-lite-perl libnet-appliance-session-perl libnet-cidr-perl liblist-compare-perl libhttp-request-params-perl libexception-class-perl liblwp-protocol-https-perl libnet-ssleay-perl

While setting up your device on the ThreatSTOP website use the public IP address of the VM that will run the and scripts. The policy query must come from the same IP that is assigned to your device on the ThreatSTOP website. If you do not know the public IP address of that VM, go to from the VM. This will show you what IP address to use and whether that IP address is currently registered in our system.


Root credentials on the FortiGate device are necessary to fully setup ThreatSTOP. This is regardless of whether or not final installation will occur on a VDOM or the root of a device. If you do not have root credentials you will need to be granted these permissions to continue with the setup and configuration.


There are two things that need to be configured on the Fortinet device, logging (syslog) and the policy settings.

In order the get the logs from a Fortinet device, you will need to configure the device to send logs to the TS Appliance VM syslog server. You will need to do this from the Fortinet CLI. Once you have established a console or SSH session to the Fortinet you can configure it to send the logs:

threatstop@tsclient:~$ ssh <Device IP>

FGT80C # config log syslogd setting
FGT80C (setting) # set status enable
FGT80C (setting) # set server <Device IP>
FGT80C (setting) # set port 514
FGT80C (setting) # set facility local7
FGT80C (setting) # end

Optionally, you can filter the logs to only include the forwarding traffic

FGT80C # config log syslogd filter
FGT80C (setting) # set app-ctrl disable
FGT80C (setting) # set attack disable
FGT80C (setting) # set dlp disable
FGT80C (setting) # set email disable
FGT80C (setting) # set netscan disable
FGT80C (setting) # set virus disable
FGT80C (setting) # set web disable
FGT80C (setting) # end


Our script does not add or edit your firewall policies automatically. However you can specify address groups that are in the policies where you want the ThreatSTOP addresses to be added and then the script will add the ThreatSTOP addresses and address groups to those policies. In a simple ThreatSTOP deployment you will have two policies on the WAN (external) interfaces that allow and block traffic FROM addresses in the ThreatSTOP allow and block lists respectively, and two on each of the internal/DMZ interfaces that allow and block traffic TO addresses in the ThreatSTOP allow and block lists.

If you do not have these addresses, address groups, or policies already defined then you should manually create them. Typically the quickest way to do this is to:

  1. Create a couple of reference addresses, one for allow and one for block, then create allow and block address groups with the respective reference addresses in them.
  2. Create the policies using them.

To do this:

  1. From the GUI create two reference addresses by clicking Firewall Objects > Addresses > Create New (or Policy & ObjectsObjects > Addresses > Create New in VDOM systems). You will need to create two reference addresses named DNS and Sinister. Using the values and (both addresses are controlled by ThreatSTOP) as illustrated to the right, or copy and paste the data below:

    • Name: DNS

    • Subnet / IP Range:

    • Name: Sinister

    • Subnet / IP Range:


      Legacy customers will want to maintain the IP address This IP address, while unsupported, will prevent customers with older versions of ThreatSTOP to operate uninterrupted until they are able to update their configurations.

  2. Once you have created the addresses, your address list should look similar to the image to the right.

  3. Having created the example addresses click on the dropdown next to Create New and select Groups to add the relevant address groups (that is, TS-SetupAllow and TS-SetupBlock)

  4. Once you have created the groups your group list should look (partially) like this:

  5. Then go to Policies and add the relevant policies. As noted above you will need two policies on the WAN (external) interfaces that allow and block traffic FROM addresses in the ThreatSTOP allow and block lists respectively, and two on each of the internal/DMZ interfaces that allow and block traffic TO addresses in the ThreatSTOP allow and block lists. On interfaces where you have NAT configured remember to enable NAT on the allow policy. Once created your policy list should contain entries similar to:

Install the Script

On the VM you should run the following to download and setup the scripts

curl -o ts-fortinet.tar.gz | tar xzvf ts-fortinet.tar.gz ; cd ts-fortinet; ./ -i '<Device IP>' -b <block list name>..threatstop.local -a <allow list name>..threatstop.local

The installer will run through some checks to make sure all the installed modules are OK and then move on to the interactive portion. Change the following settings to match your environment.


You should check in the Fortinet Maximum Values document for the maximum number of addresses and addresses and address groups supported by your Fortinet firewall as you will be asked for these during setup. You should allow for some of your own addresses when answering the Maximum Addressess question. For example, if your firewall has a maximum of 10,000 addresses then you may want to choose 7500 so that you can have 2500 non-ThreatSTOP addresses.

 threatstop@tsclient:~/work/ts-fortinet$ ./
Welcome to the ThreatSTOP setup for Fortinet Controllers v2.10
At the first stage of setup process you will be given the chance
to specify a number of setup options. You can always change them
later by re-running setup script or by manually updating the
relevant entries in threatstop.conf file.
If a parameter had been previously configured its value will be shown
in [] on parameter request line. You can choose to re-use this value
by simply pressing enter.
For security reasons the preconfigured password parameter is not shown.
Instead if previous configuration exists it will appear as [******].
[INFO ] : Starting script v.2.10 execution
[INFO ] : Entering interactive stage.
Is your Fortigate Virtual Domain enabled (y/n)?:
[n] ==> y
Virtual Domain name:
[] ==> VDOM1
Please enter the block_list to use:
[] ==> <block list name>..threatstop.local
Please enter the allow_list to use:
[] ==> <allow list name>..threatstop.local
Please enter the external IP address of the Fortinet device:
[] ==> <Device IP>
Please enter port to use for DNS queries:
[53] ==>
Please enter the max number of IP addresses to process:
[10000] ==>
Please enter the max number of addresses permitted in one address group:
[] ==> 300
Please enter the internal IP address of the Fortinet device:
[] ==>
Please enter the username used to SSH to the Fortinet:
[] ==> admin
Please enter the SSH password (text is hidden):
[] ==> <password>
Please enter default ThreatSTOP allow group name [NOT TSallow-X]:
[] ==> TS-SetupAllow
Please enter default ThreatSTOP block group name:
[] ==> TS-SetupBlock
Chosen configuration parameters
Fortinet device external IP : <Device IP>
Fortinet device internal IP :
Username                    : admin
SSH password                : *******
ThreatSTOP block list       : <block list name>..threatstop.local
ThreatSTOP allow list       : <allow list name>..threatstop.local
Port                        : 53
Max policy size             : 10000
Max group  size             : 300
Allow default group         : TS-SetupAllow
Block default group         : TS-SetupBlock
Apply settings Y/N [Y] :
[INFO ] : Generating configuration file.
[INFO ] : Verifying network access to Fortinet device
[INFO ] : Establishing ssh conection.
We need to make sure that ssh authorized_keys are properly setup between your
machine and the Fortinet device.  Please wait for the ssh password prompt then
log onto the Fortinet device.  Immediately after, press enter.  This will end
the SSH session and bring you back into the setup script.
Please watch for possible ssh connection failures. If this happens, you will
need to resolve the issue before proceeding with the setup script.
admin@'s password:
FG100D3G14818722 #
[INFO ] : Network access OK.
[INFO ] : Prepare logrotation configuration.
We are about to start the system configuration process
A SUDO access password may be required.
[INFO ] : Restarting syslog-ng with new configuration.
[INFO ] : Setting up cron entries for automatic execution.
[INFO ] : Finished v.2.10 execution

Once these questions have been answered the script will copy files if required, test whether the appliance can download the block list from ThreatSTOP's DNS server and setup syslog-ng

You should verify that none of the changes have broken basic connectivity.

Virtual Domain (VDOM)

Virtual Domains are a function available to FortiGate users. They allow a FortiGate security gateway to be divided into multiple virtual devices, each operating as an independent device. This type of setup is completely optional and not all FortiGate users will use a VDOM setup. If you do not have VDOM configured for your device, simply enter N at the prompt. If you do have VDOM enabled enter Y and then enter the Virtual Domain Name at the following prompts. The number of VDOMs supported is limited by Fortinet, ThreatSTOP's service will support as many VDOMs as your setup has established, however the object limits are substantially lower than Fortinet's documentation provides. We recommend keeping about 2500 network objects – out of the global number of network objects – in reserve for non-ThreatSTOP objects. Also bear in mind that the global number is divided among all running VDOMs.

More information about VDOMs and their limitations can be found at:


This guide will help to troubleshooting four common problems, if you are confused or if these steps do not help then please contact ThreatSTOP support.

  1. ThreatSTOP rules do not get loaded

    The most likely reason is that you have not correctly entered the VM's IP address in the ThreatSTOP device definition page. You can verify whether the address the firewall uses is in our database by running the following from the command promt (SSH or console):


    You should see a simple result stating the device's IP address and whether it is in the database or not. Database updates are not instantaneous but take place every 15 minutes; so, if you have recently added or modified the firewall IP details, you may wish to wait about half an hour before checking this. If there is no response at all then verify by using the ping command that the firewall can reach and, if not, that it can reach other places such as If you have no connectivity to ThreatSTOP but do have connectivity elsewhere please contact ThreatSTOP support for further information about the status of the ThreatSTOP infrastructure.

    If the address is valid but there are still problems verify whether the blocklist addresses have been successfully downloaded. If the addresses have been properly downloaded you will see a number of addresses in the Fortinet address book similar to the image to the right.

    If that is not the case then you should run the update script manually with the DEBUG flag set to determine what the problem may be.

    threatstop@tsclient:~$ ~/ts-fortinet/ DEBUG

    If the problem is not obvious please contact ThreatSTOP support to help troubleshoot, however the most likely problem is that the the VM can no longer access our DNS servers, in which case the script will terminate with a message such as "No ThreatSTOP DNS reachable." Please ensure that you have not blocked DNS (port 53) routing through your firewall. If you confirm that the port is open (via ping, or the network diagnostic tool of your choice) that the problem is with our DNS then please contact ThreatSTOP support for guidance on how to use a backup DNS server or port and when the DNS will resume operation.

  2. ThreatSTOP fails to block access to places it should

    If you have ThreatSTOP's blocklists loaded on the firewall but nothing is being blocked, you should check that the policies are active on the interfaces you think they should be, and that they contain the automatically added ThreatSTOP address groups (called TSblock- for block lists)
  3. ThreatSTOP blocks access to places it shouldn't

    Although ThreatSTOP tries very hard to ensure that we have zero false positives in our standard lists, we do occasionally miss something. Please report the offending domain and IP addresses to ThreatSTOP support. Also please check in the log file that the IP addresses are indeed being blocked by the ThreatSTOP rules before contacting us.If you need to allow access to a location quickly then you should add the IP addresses to a user-defined allow list in the Policies & Lists Page on the ThreatSTOP portal. Note you should make sure that the policy you are using includes that allow list.
  4. No Logs Uploaded

    In many cases logging issues are related to issue 1. Above, if running the validip test described above is successful then you should verify that log enable is set appropriately in the current configuration (all ThreatSTOP firewall drop rules should have logging enabled in them).You should also confirm that the system's root crontab has been correctly modified. To check the root crontab do:

    sudo crontab -l

    If crontab is correctly setup there should be a line with a number, some asterisks and then the following command:

    sudo perl -e'exec q(/usr/sbin/logrotate -f /etc/logrotate.d/remotes.log) if (stat q(/var/log/remotes.log))[7]<100000;'

    You should also check that the log file /var/log/remotes.log is being updated by the firewall. If it's last changed date is not recent or it is 0 bytes in size then you may not have set up logging correctly on the firewall (see the Syslog section above).If other files in /var/ log have also not been updated recently then the problem could be that syslog has crashed. If so please execute the following command to restart the syslog daemon:

    sudo service syslog-ng restart

    If this problem persists please contact ThreatSTOP support for additional assistance.

Restore to Previous State

If you have run setup and applied the changes and wish to return to the pre-ThreatSTOP configuration then you should perform the following actions in the order presented:

  1. Stop the VM from updating the firewall by deleting the user crontab:

    crontab -r

  2. Remove the ThreatSTOP address groups from the polices using them (or delete the policies completely)
  3. Delete the ThreatSTOP address groups (TSBlock-(number) and TSAllow-(number))
  4. Delete the ThreatSTOP addresses (TSb(number) and TSa(number))