Effective Web Server Protection

Effective Web Server Protection

A post about possible controls offered by FortiOS in order to tighten your web server security. Indeed, I'm currently using a mixture of features in order to possibly secure (to the best of my own disabilities) this very own web server you're on right now.

The 1st feature set I'm using is what I refer to as Reverse Web Filtering, by that allowing only the served up FQDN's on my inbound policies. Here is a view of my current Reverse Web Filtering profile:

Hence, this profile will allow only the listed FQDN amongst which the ghost.reverside.ch entry. On the entry highlighted in red above, I'm here letting through anyone coming with a direct IP address (for a later catch). All the rest is blocked.

Indeed, Static URL filters takes precedence over the IPS Engine which comes at a later stage within the FortiOS inspection phases. The regular expression \d+\.\d+\.\d+\.\d+ configured above will hence let connectivity pass further in the occurrence of a direct IP address being requested part of an HTTP(s) connection request. (Please note that the RegEx above isn't perfect I'm afraid... Although, after some testing's it seemed to me as the most predictable in terms of behaviors. If you have something better, please share)

Consequently, requests using IP address as their target host value will be caught up at the IPS Engine level, this using a simple custom-made signature:

F-SBID( --attack_id 1413; --name Match_NO_FQDN_SSL.custom; --protocol tcp; --service http; --flow from_client; --parsed_type http_get; --pattern !.reverside.ch; --no_case; --context host; )

Here, I'm matching anyone NOT coming with the sentence ".reverside.ch" within an HTTP GET request.

Of course, to be effective, the above IPS signature need SSL interception enabled on your NGFW policy. Hence, SSL deciphering happening at the FortiOS/vDOM layer.

Below you'll find a log summary of a blocked attempt at directly connecting toward the mapped WAN IP address:

A connection which appears to be an attempt at probing for OWA presence... Undoubtedly, 99.9% of any attempt at directly connecting at the IP level appears to be probing, noise and/or malicious attempts in general. Hence why, if not coming with a proper FQDN, I'm ruling this out.

Another advantage of getting this caught at the IPS Engine level is that you can thereafter quarantine such offenders and by that deny them connectivity altogether. In my deployment, I'm looping such bans and add them within a personal threat list which is constantly updated amongst any FortiGate devices under my control. You can find more information about this process in a former ghost post here.

Finally, the above mentioned threat list is available online and hourly updated in the occurrence of new denials. You can find it here:


A special mention to my friend LB for his assistance and the brilliant idea of passing IP only requests further toward the IPS Engine =)

In the hope you found this useful.

Image Credits: Eden by Wojtek Fus --> https://wojtekfus.com/

Show Comments