SonicOS 7.0 Rules and Policies for Classic Mode
- SonicOS 7.0 Rules and Policies
- Access Rules
- Setting Firewall Access Rules
- About Connection Limiting
- Using Bandwidth Management with Access Rules
- Creating Access Rules
- Configuring Access Rules for IPv6
- Enabling and Disabling Access Rules
- Editing Access Rules
- Deleting Access Rules
- Restoring Access Rules to Default Settings
- Displaying Access Rules
- Displaying Access Rule Traffic Statistics
- Configuring Access Rules for NAT64
- Configuring Access Rules for a Zone
- Access Rules for DNS Proxy
- User Priority for Access Rules
- Access Rule Configuration Examples
- Setting Firewall Access Rules
- NAT Rules
- About NAT in SonicOS
- About NAT Load Balancing
- About NAT64
- About FQDN-based NAT
- About Source MAC Address Override
- Viewing NAT Policy Entries
- Adding or Editing NAT or NAT64 Rule Policies
- Deleting NAT Policies
- Creating NAT Rule Policies: Examples
- Creating a One-to-One NAT Policy for Inbound Traffic
- Creating a One-to-One NAT Policy for Outbound Traffic
- Inbound Port Address Translation via One-to-One NAT Policy
- Inbound Port Address Translation via WAN IP Address
- Creating a Many-to-One NAT Policy
- Creating a Many-to-Many NAT Policy
- Creating a One-to-Many NAT Load Balancing Policy
- Creating a NAT Load Balancing Policy for Two Web Servers
- Creating a WAN-to-WAN Access Rule for a NAT64 Policy
- DNS Doctoring
- Routing
- Content Filter Rules
- App Rules
- About App Rules
- Rules and Policies > App Rules
- Verifying App Rules Configuration
- App Rules Use Cases
- Creating a Regular Expression in a Match Object
- Policy-based Application Rules
- Logging Application Signature-based Policies
- Compliance Enforcement
- Server Protection
- Hosted Email Environments
- Email Control
- Web Browser Control
- HTTP Post Control
- Forbidden File Type Control
- ActiveX Control
- FTP Control
- Bandwidth Management
- Bypass DPI
- Custom Signature
- Reverse Shell Exploit Prevention
- Endpoint Rules
- SonicWall Support
Custom Signature
You can create a custom match object that matches any part of a packet if you want to control traffic that does not have a predefined object type in App Rules. This allows you to create a custom signature for any network protocol.
For instance, you can create a custom signature to match HTTP GET request packets. You might use this if you want to prevent Web browsing from your local area network.
To determine a unique identifier for a HTTP GET packet, you can use the Wireshark network protocol analyzer to view the packet header. For more information about using Wireshark, see Wireshark. In Wireshark, capture some packets that include the traffic you are interested in. In this case, you want to capture a HTTP GET request packet. You can use any Web browser to generate the HTTP GET request. HTTP GET Request Packet in Wireshark shows an HTTP GET request packet displayed by Wireshark.
To create a custom signature for a network protocol
- In the top pane of Wireshark, scroll down to find the
HTTP GET
packet -
Click on that line.
The packet is displayed in the two lower panes. For a SYN packet, the center pane provides a human-readable interpretation of the packet header, and the actual header bytes are displayed in hexadecimal in the lower pane.
-
In the center pane, expand the Hypertext Transfer Protocol section to see the packet payload.
-
Find the identifier that you want to reference in App Rules. In this case, the identifier is the
GET
command in the first three bytes. -
Click on the identifier to highlight the corresponding bytes in the lower pane.
-
You can determine the offset and the depth of the highlighted bytes in the lower pane.
- Offset indicates which byte in the packet to start matching against.
- Depth indicates the last byte to match.
Using an offset allows very specific matching and minimizes false positives. Decimal numbers are used rather than hexadecimal to calculate offset and depth.
When you calculate offset and depth, the first byte in the packet is counted as number one (not zero).
Offset and depth associated with a custom match object are calculated starting from the packet payload (the beginning of the TCP or UDP payload). In this case, the offset is 1 and the depth is 3.
-
Create a custom match object that uses this information.
-
In the Match Object Settings dialog, type a descriptive name for the object in the Object Name field.
-
Select Custom Object from the Match Object Type drop-down menu.
-
Select Enable Settings.
-
In the Offset field, type 1 (the starting byte of the identifier).
-
In the Depth text box, type 3 (the last byte of the identifier).
-
You can leave the Payload Size set to the default. The Payload Size is used to indicate the amount of data in the packet, but in this case we are only concerned with the packet header.
-
For Input Representation, click Hexadecimal.
-
In the Content text box, type the bytes as shown by Wireshark: 474554. Do not use spaces in hexadecimal content.
-
Use this match object in an App Rules policy.
-
In the Add App Rule dialog, type a descriptive Policy Name.
-
Select HTTP Client for the Policy Type.
-
In the Match Object Included drop-down menu, select the match object that you just defined.
-
Select a custom action or a default action such as Reset/Drop from the Action Object drop-down menu.
-
For the Connection Side, select Client Side.
-
You can also modify other settings. For more information about creating a policy, see Configuring an App Rules Policy.
-
Was This Article Helpful?
Help us to improve our support portal