IPS signatures categories confusion

[marypoppins]

Dear All,

I would like to make different ips security policies for different services (accepted by the appropriate firewall policies), however I have a confusion with signature categories. First I thought that for the https web services it is enough to make an ips sensor that includes the https from the protocol entries when editing the signatures filter, but I found something strange.
Before when I used an ips policy including every signatures I found a line in my fortianalyzer, that shows "action:dropped, service:HTTPS, attack name: Bladabindi.Botnet". Then I checked this attack name in fortigate ips signatures and in the protocol section it only shows TCP, but not HTTPS. I think this means if I only add the HTTPS protocols to my custom ips filter, this attack is not checked.

My question how should I make custom ips sensors for different protocols (an ips for http, an other to all email protocols) in order to not leave out any relevant signatures?

thank you

chr

[Cajuntank]

Have a look at this best practice link for IPS (https://community.fortinet.com/t5/FortiGate/Technical-Tip-IPs-best-practices/ta-p/198360), it will give you some examples for https and email, but the gist is, you can filter based on your environment, so if you have a windows web server that listens only on port 443 (HTTPS) for example and you don't care about the low severity ones, then your filter would look something like this:

Same type of filtering can be applied for an internal email server sensor making sure your include whatever protocols you are serving (i.e... SMTP, POP3, IMAP)

[marypoppins]

Thank you for reply.
It is strange: the default ips filter includes three severity levels from the middle orange category. This includes 9451 signatures from all (9861). If I add more filters to these that will not narrow the signature numbers. So it seems that those three severities includes most signatures, so maybe it should leave out in your example (your suggested best practices doesn't include severities if I see well).

Now the picture is a little cleaner, however the TCP categories confuses me. In your link in the "Protect-VOIP-IPS"
there are four main sections: protocols, os and on top of these two rules. It is ok.
The rule id 47088 is the SIP.Register.Brute.Force which protocol category is UDP and SIP, while the SIP is already in the bottom protocol filter section, this separate one has a specific rate settings, so it is to add it again.
But rule id 46575 (Linux.Kernel.TCP.Segment.Out.Of.Order.Processing.DoS)  has only the TCP protocol category, and it is not included other sections.
The TCP protocols category itself includes 9364 signatures, so it is include the most of signatures (like severities from the orange category up), and it seems to add TCP protocol category to a filter bad idea if you want to narrow the number of signatures. (in the link includes only one sig. from these tcp category, which seems reasonable)
But TCP has some signatures which can be worth to add a filter, because no other protocol category includes that.
How can know which ones not included in my filters, but should be added to? I don't want to leave out any signatures, (even if that has high severity), but want to narrow the signature list.

So it is unclear how to make a filter, which includes the most relevant and only those signatures.
Thank you

[marypoppins]

OK, it is clear now, that not only the protocol category exists, but there are os, target categories also, which includes the appropriate  TCP only signatures....

A new question:
I would like to protect an email server. Should the filter include the client target as well (because of the vulnerabilities transfer via email) or it is already includes the smtp,pop,imap protocol filters?

If I choose the server, smtp, pop, imap categories those are protect only the server as an attack target, or it is also includes protection for client that maybe attacked in the email transit traffic?

thank you

[Cajuntank · Accepted solution]

You define the sensor based on the flow of traffic you are trying to protect, so for example (and this is purely all example based), if this is a email server you are trying to protect, then that sensor would be filtered accordingly with whatever target (Server or Client), Severity (information, low, medium, high, critical), Protocol (SMTP, POP3, IMAP, etc...), OS (Linux, Windows, etc...), Application (Ipswitch, MS Exchange, SendMail, etc...)...don't know what email server you have, or what OS it's on, or totality of protocols it's providing (maybe this is also serving users email via a web interface, so HTTP and HTTPS might also need to be added for this sensor), etc...

So after creating this custom sensor, you would place that sensor on the flow of traffic incoming to that server, so typically this is a WAN to LAN (or DMZ if your server resides in that zone) and I normally will do a proxy based policy as I want the utmost accuracy in inspection on that traffic (you sacrifice some speed for more accuracy with proxy). If you are concerned about protection for your client, that would be a different traffic policy incoming to your clients and thus a different custom sensor (i.e... client instead of server, maybe you only care about high and medium severity issues, maybe you clients only make secure SMTP requests, maybe these are macOS clients, etc...) you get my point. But on this traffic flow, maybe you want speed over more accurate inspection, so that policy would be flow based. 

[marypoppins]

Thank you for helping me!