Fortigate is greate but not so great.

One of the limitations of FortiOS 2.8 is that each particular protection feature is configured globally and applied locally. So, you need to pick a bunch of options about how to configure each form of protection, in your case above attachment blocking and banned words, and the selectively apply them. You can't specify two or three different sets of file blocks and apply them separately.

So, what you have to do, is peel off the different type of traffic and treat them differently. So, with banned words, your first policy includes the vendors, and banned word protection is disabled so they can recieve "viagra", the second policy includes buyers, annd banned word protection is enabled, so "viagra" is blocked. So we accomplished that goal. But, if you wanted to instead block "warez' for the vendors, you couldn't do this if you had the protection disabled.

With the attachment blocking, no such luck, because you have a different set of blocks you want. Say, zip and gif blocked for one group and jpg and gif blocked for another. You have only one set of blocks to apply or not apply. So you can have one group that has a bunch of stuff blocked and another that doesn't, and that's as granular as you can get. About all you can do is have a good hard stare at it and perhaps realise that there are a few sites they nee to download such files from, and the rest can be blocked without incident. So you make a policy for those few websites with no attachment blocking and another one for the rest of the Internet. Keeping in mind attachment blocking isn't really a security measure as much as a way to reduce the load on the AV by dumping files outright by extension. and you're still scanning such things for viruses. Also, you can specify particular files explicitly such as iesetup.exe and let that through even if you're blocking .exe files.

So fine, those are some limitations. The good news is that lots of them go away in FortiOS 3.0. So the reason we have these limits is that they want to keep one table in memory for each type of protection, that's referred to by the policies. This is to keep it fast and tight inside the ASIC architecture. If they had 5 or 6 completely different set of IPS dispositions, for example, your memory on the 60 would be exhausted and you couldn't process content.

So what they've done in 3.0 is added extra columns to most of these tables. So for example, with banned words, they now have a score. Each matched word contributes a score. And in the protection profile, you define what threshold indicates a failure to pass. So you can have different behaviours on differerent protection profiles by tuning the scores for the banned words and the thresholds that cause them to activate the block. Thus different protection by policy/group is now possible.

Most critically, for IPS, in 2.8 you can only configure one set of attacks in terms of what's allowed, blocked, dropped, active, inactive, etc. So, you're forced to use the same set of these dispositions for incoming vs outgoing traffic, which isn't ideal. In 3.0, each individual attack (or, category of attacks if you like) can be assigned one of 5 severity levels. Then, in the protection profile that you apply to the policy, you specify which severities will be scanned or not scanned for. With a very small amount of work you can come up with a large number of custom sets of dispositions this way, by tuning the severity of the individual attacks to move them in and out of the corresponding protection profiles. This still is implemented as a single table in memory, but with the extra column and the extra lookup, you gain a very large amount of flexibility without compromising the performance of the box.

3.0 is a great evolutionary change for the FortiGate, look forward to it's public release shortly although I'd recommend letting a few maintenance releases go by before you put it on mission-critical production traffic.

-Russ.

Tanks russ,

They could apply the same concept to files exension too. Creae a column named GROUP (1-5)

So vendors would be blocked only for those files in the group 5 Buyers would be blocked fIN GROUPS 1,2,3 and so on.

Seems easy to implement and not at all heavy.

Marcello T.I only 2,3,4

It wouldn't surprise me to see that sort of thing in a later rev. of 3.0, since they're adding a "second column" concept to so many protections, or at least, they're moving granularity into the protection profile rather than the global config. But I think they dont' spend a lot of cycles thinking about attachment blocking in this form since it's such a basic functionality.

BTW you could probably also write a custom IPS definition to catch some of these and then leverage the IPS priority structure to get it in and out of your protection profile, but that's getting a bit advanced. :-)

-Russ.

russ wrote..

Specially for me ,I spent m whole life writing ERP/CRM systems, This last statement seems like ancient Greek for me.

Marcello

In the MR5 releases of 3.0, you can set up virtual domains. VDOMs can be thought of as organizational groups in a company and separate policies for each can be used. They all share the same global set of IPS, virus and content definitions to save on memory, and you can add to them and have them available in each VDOM. You can also assign different admins to each VDOM if there is a need. This way you can filter very effectively across multiple groups and allow different access for each. It's a little confusing at first and needs some polish, but should be very nice for the final release.