Adding denied sessions to session table

Blocking the packets of a denied session can take more CPU processing resources than passing the traffic through. By putting denied sessions in the session table, they can be kept track of in the same way that allowed session are so that the FortiGate unit does not have to reassess whether or not to deny each of the packets on an individual basis. If the session is denied all packets of that session are also denied.

 
In order to configure this to take place you will need to configure 2 CLI settings.

ses-denied-traffic

This setting determines whether or not the firmware includes denied session in the session table. The default of this setting is “disable” so it needs to be enabled.

block-session-timer

This setting sets the length of time, in seconds, that the session is kept in the table. The range is from 1 to 300 seconds. The longer the session is in the table the less potential for impact on the CPU but the greater the amount of memory taken up holding the information in the table.
 
The following is an example configuration:
 
config sys settings 
  set ses-denied-traffic enable
  end
config system global 
  set block-session-timer 60
  end

Caveat

It is worth noting that this feature’s primary function is to mitigate stress on the FortiGate’s resources from sessions that have been classified as “unwanted”, for lack of a better term. The scope of what the setting can handle does not include a full on assault by a Denial of Service type of attack. Protection from that sort of malicious attack is provided by DoS policies.

Bruce Davis

Bruce Davis

Technical Writer at Fortinet
Bruce has been working with computers, and related technology, since before the World Wide Web was a thing. He has worked in system and network administration. He has even dabbled in technical support. He has made the switch to technical writing as part of his deep, dark and dastardly plan to make the arcane machinations of IT technology more easily understood by the poor folks who use it. That, and the voices in his head told him it was good idea. Never argue with the voices in your head. People will start to stare.
Bruce Davis

Latest posts by Bruce Davis (see all)

Share this recipe:

Facebooktwittergoogle_pluslinkedin

Leave a comment:

Before commenting, please read the site's comment policy. Only questions related to documentation will be answered. For other concerns, please contact Fortinet support.

  • Yasushi

    The command above should read like this:
    config system settings
    set ses-denied-traffic enable
    end
    config system global
    set block-session-timer 60
    end
    However, this technology does not work at all. The reason is that if you consider TCP sessions, the source port is subject to a constant change. So, if someone tries to connect to a resource not allowed according to the firewall policy, FortiGate checks the five tuples (Source IP, Source Port, Destination IP, Destination Port, and IP Protocol), and because it is the source port which will be changed with every SYN packet, FortiGate will continuously check the policy rather than the session table. So, you will not benefit from this feature at all. This is the sad truth.

    • Bruce Davis

      You were right about the syntax. I somehow missed the changing of the context for the settings.
      However, you may want to recheck, your premise that the source port is changed with every packet sent. I was taught that the source port was determined at the beginning of a session and remained consistent throughout the session; the 5 tuples being stored in the session table. This way, the overhead of the initial handshake is not carried on through for the whole of the communication. Admittedly, a new session will generate a new source port, but initiating a new session is resources and effort spent on the other end of the connection and this this feature was designed as a means of mitigating the strain on the CPU rather than a security measure.

    • Bruce Davis

      Sorry for the delay in responding. I thought that I had submitted a response when I made the changes to the post. Further proof that I am not infallible, no matter how much I wish it was different.

      Yasushi, you were correct about the settings. However, I might suggest a different perspective on the topic of whether or not the technology works. When I was taught networking, it was explained to me that the source port didn’t change with every packet, but remained constant for the duration of the session. Checking the session table will prevent the need for checking the policy until a new session can be set up. While it is true that there is nothing here to prevent another session from being started at a latter point, the primary objective of this particular feature is to mitigate the load on the systems resources. During the wait for the new session, the FortiGate gets a break from analyzing traffic from that source. Setting up a new session will be a load on the resources of the initiating entity; maybe enough that they will stop bothering after a few tries that do not bring them the results they want.

      • Yasushi

        Hi Bruce,

        if you could share your email address, I could give you information not intended for the public. You could try to find me at LinkedIn, as I am one of the specialist of another firewall vendor. I would like to contribute in improving FortiGate.

        Cheers,
        Yasushi

        • Bruce Davis

          The best way to get information, in a non public format, to the technical documentation team is to use the techdoc@fortinet.com email address rather than a specific user’s email address.

  • Abdulaziz Alatar

    Hello, Thank you but how can see state table before and after apply this feature.
    and i want ask you about stateless and stateful ,a fortigate work statful but can test enable stateless ?
    is there another article about this ?

    • Bruce Davis

      Abdulaziz,

      I don’t know of any existing articles that address specifically what you are referring to as there isn’t as much of a demand for that level of knowledge on the topic, though it may be worth considering putting one out.

      As for the ability to see the session table, there are some diagnostic commands that may be what you are looking for, though they are normally only intended for the developers and for troubleshooting specific issues. In the CLI command tree they are under diagnose sys (or system) session. The syntax for specific commands can be found at http://wiki.diagnose.fortinet.com. However, you may want to work with some members of TAC while using these commands until you are familiar with them. Working with the diagnostic system is not always intuitive.

      • Abdulaziz Alatar

        thanks

      • Abdulaziz Alatar

        Apologize for the delay in reply, duplicate threads in a very large reader makes the status of severe boredom in handbook.
        And it contains in-depth information theory without clear examples

  • Vathek

    Thanks for this explainer. It fleshed it out a bit more.