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.
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.
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 setup.sh script on Ubuntu.
While setting up your device on the ThreatSTOP website use the public IP address of the VM that will run the setup.sh and ts-fort.pl 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 http://www.threatstop.com/cgi-bin/validip.pl 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:
Optionally, you can filter the logs to only include the forwarding traffic
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:
- Create a couple of example addresses, one for allow and one for block, create allow and block address groups with the respective example address in them.
- Create the policies using them.
To do this:
From the GUI create example addresses (for example,TSBlockAddress and TSAllowAddress) using known good and bad IP addresses. A good value to allow is 22.214.171.124 and a good value to block is 126.96.36.199 (both addresses are controlled by ThreatSTOP). Go to Firewall Objects > Addresses then click on Create New to add an address.
Legacy customers will want to maintain the IP address 188.8.131.52. This IP address, while unsupported, will prevent customers with older versions of ThreatSTOP to operate uninterrupted until they are able to update their configurations.
Once you have created the addresses, your address list should look similar to the image to the right.
Having created the example addresses go to Groups and click on Create New to add the relevant address groups (that is, TS-SetupAllow and TS-SetupBlock)
Once you have created the groups your group list should look (partially) like this:
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
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.
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.
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 threatstop.com and, if not, that it can reach other places such as google.com. 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.
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.
ThreatSTOP fails to block access to places it shouldIf 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)
ThreatSTOP blocks access to places it shouldn'tAlthough 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.
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:
If crontab is correctly setup there should be a line with a number, some asterisks and then the following command:
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:
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:
Stop the VM from updating the firewall by deleting the user crontab:
- Remove the ThreatSTOP address groups from the polices using them (or delete the policies completely)
- Delete the ThreatSTOP address groups (TSBlock-(number) and TSAllow-(number))
- Delete the ThreatSTOP addresses (TSb(number) and TSa(number))