Protocol decoders are used by IDP to check protocol integrity and protocol contextual information by looking for anomalies and ensuring that RFC standards are met. An anomaly can be any part of a protocol, such as the header, message body, or other individual fields that deviate from RFC standards for that protocol. For example, in the case of SMTP, if SMTP MAIL TO precedes SMTP HELO, that is an anomaly in the SMTP protocol.
When protocol contextual information is available, protocol decoders check for attacks within those contexts. For example, for SMTP, if an e-mail is sent to user@company.com, user@company.com is the contextual information and SMTP MAIL TO is the context. By using protocol contextual data, rather than the entire packet, for attack detection, protocol decoders improve overall performance and accuracy.
If there is a policy configured with a rule that matches the protocol decoder check for SMTP, the rule triggers and the appropriate action is taken.
This section contains the following topics:
The IDP module ships with a preconfigured set of protocol decoders. These protocol decoders have default settings for various protocol-specific contextual checks they perform. You can use these defaults or you can tune them to meet your site’s specific needs. To display the list of available protocol decoders, enter the following command:
For a more detailed view of the current set of protocol decoders and their default context values, you can view the detector-capabilities.xml file located in the /var/db/idpd/sec-download folder on the device. When you download a new security package, you also receive this file which lists current protocols and default decoder context values.
The configuration instructions in this section provide a tunable context configuration example for one protocol decoder, FTP.
To configure protocol decoder tunables, refer to the following information:
- user@host # set security idp sensor-configuration detector
protocol-name ftp tunable-name ftp_failed_logins tunable-value 4
- user@host # set security idp sensor-configuration detector
protocol-name ftp tunable-name ftp_failed_flags tunable value 1
- user@host # set security idp sensor-configuration detector
protocol-name ftp tunable-name ftp_line_length tunable-value 1024
- user@host # set security idp sensor-configuration detector
protocol-name ftp tunable-name ftp_password_length tunable-value 64
- user@host # set security idp sensor-configuration detector
protocol-name ftp tunable-name ftp_sitestring_length tunable-value 512
- user@host # set security idp sensor-configuration detector
protocol-name ftp tunable-name ftp_username_length tunable-value 32
When a new security package is received, it contains attack definitions and a detector. In any given version of a security package, the attack definitions correspond to the capabilities of the included detector. When policy aging is disabled on the device (see the reset-on-policy command in the JUNOS Software CLI Reference for policy aging commands), only one policy is in effect at any given time. But if policy aging is enabled and there is a policy update, the existing policy is not unloaded when the new policy is loaded. Therefore, both policies can be in effect on the device. In this case, all existing sessions will continue to be inspected by existing policies and new sessions are inspected with new policies. Once all the existing sessions using the older policy have terminated or expired, the older policy is then unloaded.
When a policy is loaded, it is also associated with a detector. If the new policy being loaded has an associated detector that matches the detector already in use by the existing policy, the new detector is not loaded and both policies use a single associated detector. But if the new detector does not match the current detector, the new detector is loaded along with the new policy. In this case, each loaded policy will then use its own associated detector for attack detection.
Note that a maximum of two detectors can be loaded at any given time. If two detectors are already loaded (by two or more policies), and loading a new policy requires also loading a new detector, then at least one of the loaded detectors must be unloaded before the new detector can be loaded. Before a detector is unloaded, all policies that use the corresponding detector are unloaded as well.
You can view the current policy and corresponding detector version by entering the following command:
