# 334.2 Network Intrusion Detection **Weight:** 4 **Description:** Candidates should be familiar with the use and configuration of network security scanning, network monitoring and network intrusion detection software. This includes updating and maintaining the security scanners. **Key Knowledge Areas:** * Implement bandwidth usage monitoring * Configure and use Snort, including rule management * Configure and use OpenVAS, including NASL **Partial list of the used files, terms and utilities:** * ntop * snort * snort-stat * pulledpork.pl * /etc/snort/\* * openvas-adduser * openvas-rmuser * openvas-nvt-sync * openvassd * openvas-mkcert * openvas-feed-update * /etc/openvas/\* ## Network Monitoring ### ntop ntop is the best tool to see network usage in a way similar to what top command does for processes i.e. it is network traffic monitoring software. You can see network status, protocol wise distribution of traffic for UDP, TCP, DNS, HTTP and other protocols. ntop is a hybrid layer 2 / layer 3 network monitor, that is by default it uses the layer 2 Media Access Control (MAC) addresses AND the layer 3 tcp/ip addresses. ntop is capable of associating the two, so that ip and non-ip traffic (e.g. arp, rarp) are combined for a complete picture of network activity. The `ntop` command may be used for basic administration tasks or to launch the ntop daemon

Access web console by http://host:portnumber/

ntop is a network probe that shows in interactive mode, it displays the network status on the user’s terminal. It also has a Web mode. In Web mode, it acts as a Web server, creating a HTML dump of the network status. {% hint style="danger" %} ntop is currently replaced by **ntopng** {% endhint %} examples:
ntop CommandDescription
/usr/sbin/ntop -ASet ntop admin user password
ntop --set-admin-password=NewP@$$setting new admin password
ntop -P /etc/ntop -w4242 -d

run ntop as daemon with /etc/ntop config files serving at port number 4242.

The -W option enables the port on which we want to access ntop through our web browser. If you don't specify this option, the default port is 3000.

The -d option enables ntop in daemon mode.

{% hint style="info" %} **ntopng** ntopng is the next generation version of the original ntop, a network traffic probe that monitors network usage. ntopng is based on libpcap and it has been written in a portable way in order to virtually run on every Unix platform, MacOSX and on Windows as well. {% endhint %} {% hint style="info" %} **cacti** Cacti is **an open-source network monitoring tool** that uses the Simple Network Management Protocol (SNMP) to monitor network traffic and bandwidth utilization of network devices such as routers and switches. It is more General purpose than ntop. {% endhint %} ## Working with Snort ### What is snort? Snort is the foremost Open Source **I**ntrusion **P**revention **S**ystem (**IPS**) in the world. Snort IPS uses a series of rules that help define malicious network activity and uses those rules to find packets that match against them and generates alerts for users. Snort can be deployed inline to stop these packets, as well. Snort has three primary uses: * As a **packet sniffer** like tcpdump, * as a **packet logger** — which is useful for network traffic debugging, * or it can be used as a full-blown **network** **i**ntrusion **p**revention **s**ystem. Snort can be downloaded and configured for personal and business use alike. ### Installing Snort At one time, installing Snort was a lengthy manual process. It wasn’t difficult, but there were a lot of steps and it was easy to miss one out. The major Linux distributions have made things simpler by making Snort available from their software repositories. > The versions in the repositories sometimes lag behind the latest version that is available on the Snort website. If you want to, you can download and [install from source](https://www.snort.org/#get-started). As long as you have the latest *rules*, it doesn’t matter too much if your Snort isn’t the latest and greatest—as long as it isn’t ancient. Red Hat based Linux distribution users can download the Snort package from and then install it by running the following command, where <*Version*> must be replaced with the current version that you downloaded. ``` [root@rocky8 ~]# wget https://www.snort.org/downloads/snort/snort-2.9.20-1.centos.x86_64.rpm [root@rocky8 ~]# yum install snort-2.9.20-1.centos.x86_64.rpm Last metadata expiration check: 2:58:16 ago on Fri 09 Sep 2022 08:53:58 AM +0430. Dependencies resolved. ======================================================================================================================================================= Package Architecture Version Repository Size ======================================================================================================================================================= Installing: snort x86_64 1:2.9.20-1 @commandline 4.6 M Installing dependencies: compat-openssl10 x86_64 1:1.0.2o-4.el8_6 appstream 1.1 M daq x86_64 2.0.6-9.el8 epel 88 k libnsl x86_64 2.28-189.5.el8_6 baseos 101 k Transaction Summary ======================================================================================================================================================= Install 4 Packages Total size: 5.9 M Total download size: 1.3 M Installed size: 24 M Is this ok [y/N]: y . . . ``` {% hint style="info" %} Snort 2.9 introduces the **DAQ**, or **D**ata **A**c**q**uisition library, for packet I/O. The DAQ replaces direct calls to `libpcap` functions with an abstraction layer that facilitates operation on a variety of hardware and software interfaces without requiring changes to Snort. {% endhint %} ### Configuring Snort Snort configuration file is **`/etc/snort/snort.conf`**. Before getting started, Debian users must follow the steps mentioned in the following. Other distro users can continue reading from the /etc/snort/snort.conf file edition. {% hint style="info" %} **Note for Debian users:** Debian Linux overwrites some network settings in the Snort default configuration file. Under the /etc/snort directory, there is the ***/etc/snort/snort.debian.conf*** file from where the Debian network settings are imported. If you are a Debian user, run the following code: `vim /etc/snort/snort.debian.conf` Check that all the information in this configuration file is correct including the CIDR address, network device, etc. ![](/files/wXCL2IVXU5IxHROcFk0X) Save the file. Let’s start configuring the Snort. {% endhint %} ### /etc/snort/\* ``` [root@rocky8 ~]# ls -l /etc/snort/ total 236 -rw-r--r--. 1 root root 3757 Apr 20 18:45 classification.config -rw-r--r--. 1 root root 33339 Apr 20 18:45 gen-msg.map -rw-r--r--. 1 root root 687 Apr 20 18:45 reference.config drwxr-xr-x. 2 root root 6 May 24 09:10 rules -rw-r--r--. 1 root root 26812 May 24 09:10 snort.conf -rw-r--r--. 1 root root 2335 Apr 20 18:45 threshold.conf -rw-r--r--. 1 root root 160606 Apr 20 18:45 unicode.map ``` #### /etc/snort/snort.conf Snort has a big configuration file ``` [root@rocky8 ~]# cat /etc/snort/snort.conf | wc -l 689 ``` ``` ################################################### # This file contains a sample snort configuration. # You should take the following steps to create your own custom configuration: # # 1) Set the network variables. # 2) Configure the decoder # 3) Configure the base detection engine # 4) Configure dynamic loaded libraries # 5) Configure preprocessors # 6) Configure output plugins # 7) Customize your rule set # 8) Customize preprocessor and decoder rule set # 9) Customize shared object rule set ################################################### ``` and we just mention some important sections of that here. Check your network configuration and scroll down. ``` # Setup the network addresses you are protecting ipvar HOME_NET any # Set up the external network addresses. Leave as "any" in most situations ipvar EXTERNAL_NET any # List of DNS servers on your network ipvar DNS_SERVERS $HOME_NET # List of SMTP servers on your network ipvar SMTP_SERVERS $HOME_NET ``` Define the ports that you want to be monitored. ``` # List of ports you run web servers on portvar HTTP_PORTS [80,81,311,383,591,593,901,1220,1414,1741,1830,2301,2381,2809,3037,3128,3702,4343,4848,5250,6988,7000,7001,7144,7145,7510,7777,7779,8000,8008,8014,8028,8080,8085,8088,8090,8118,8123,8180,8181,8243,8280,8300,8800,8888,8899,9000,9060,9080,9090,9091,9443,9999,11371,34443,34444,41080,50002,55555] # List of ports you want to look for SHELLCODE on. portvar SHELLCODE_PORTS !80 # List of ports you might see oracle attacks on portvar ORACLE_PORTS 1024: # List of ports you want to look for SSH connections on: portvar SSH_PORTS 22 # List of ports you run ftp servers on portvar FTP_PORTS [21,2100,3535] ``` ### Snort Rules {% hint style="info" %} #### What is a Snort rule? Rules are a different methodology for performing detection, which bring the advantage of 0-day detection to the table. Unlike signatures, rules are based on detecting the actual vulnerability, not an exploit or a unique piece of data. Developing a rule requires an acute understanding of how the vulnerability actually works. {% endhint %} Snort rules are enabled or disabled by commenting or uncommenting lines in the `/etc/snort/snort.conf` file. But the rules are stored in the `/etc/snort/rules` file. > To enable or disable the rules, open the `/etc/snort/snort.conf` with a text editor. Rules are located at the end of the file. When you reach the end of the file, you will see a list of rules for different purposes. Uncomment the rules that you want to enable and comment the rules that you want to disable. For example, to detect the traffic related to DOS attacks, uncomment the DOS rule. Or uncomment the FTP rule to monitor ports 21. ``` [root@rocky8 ~]# vim /etc/snort/snort.conf ``` ``` . . . include $RULE_PATH/ddos.rules include $RULE_PATH/dns.rules include $RULE_PATH/dos.rules include $RULE_PATH/experimental.rules include $RULE_PATH/exploit-kit.rules include $RULE_PATH/exploit.rules include $RULE_PATH/file-executable.rules include $RULE_PATH/file-flash.rules include $RULE_PATH/file-identify.rules include $RULE_PATH/file-image.rules include $RULE_PATH/file-multimedia.rules include $RULE_PATH/file-office.rules include $RULE_PATH/file-other.rules include $RULE_PATH/file-pdf.rules include $RULE_PATH/finger.rules include $RULE_PATH/ftp.rules . . ``` okey kets take a look at rules: ``` [root@rocky8 ~]# cd /etc/snort/rules/ [root@rocky8 rules]# ll total 0 ``` as you can see, by default there is no rule , let get comunity rules: ``` wget https://www.snort.org/downloads/community/community-rules.tar.gz -O community-rules.tar.gz ``` ``` tar -xvzf community-rules.tar.gz -C /etc/snort/rules ``` and now: ``` [root@rocky8 rules]# ll total 336 drwxr-xr-x. 2 1210 wheel 119 Sep 15 19:27 community-rules -rw-r--r--. 1 root root 341250 Sep 15 19:27 community-rules.tar.gz [root@rocky8 rules]# cd community-rules/ [root@rocky8 community-rules]# ll total 2336 -rw-r--r--. 1 1210 wheel 7834 Nov 9 2018 AUTHORS -rw-r--r--. 1 1210 wheel 1812522 Sep 15 19:27 community.rules -rw-r--r--. 1 1210 wheel 15127 Mar 20 2013 LICENSE -rw-r--r--. 1 1210 wheel 492280 Sep 15 19:27 sid-msg.map -rw-r--r--. 1 1210 wheel 30249 Apr 25 18:51 snort.conf -rw-r--r--. 1 1210 wheel 21084 Feb 25 2021 VRT-License.txt ``` there are tons of rules, try vim `community.rules` . ``` . alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"MALWARE-CNC Win.Trojan.OilRig variant outbound connection"; flow:to_server,established; content:"/khc?"; depth:5; http_uri; pcre:"/\x2fkhc\x3f[A-F0-9]{3,84}$/U"; metadata:impact_flag red, policy balanced-ips drop, policy max-detect-ips drop, policy security-ips drop, ruleset community, service http; reference:url,www.virustotal.com/#/file/055b7607848777634b2b17a5c51da7949829ff88084c3cb30bcb3e58aae5d8e9; classtype:attempted-user; sid:47899; rev:2;) alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"MALWARE-CNC Win.Trojan.OilRig variant outbound connection"; flow:to_server,established; content:"/pser?"; depth:6; http_uri; pcre:"/\x2fpser\x3f[A-F0-9]{3,84}(BBZ|BBY)/U"; metadata:impact_flag red, policy balanced-ips drop, policy max-detect-ips drop, policy security-ips drop, ruleset community, service http; reference:url,www.virustotal.com/#/file/055b7607848777634b2b17a5c51da7949829ff88084c3cb30bcb3e58aae5d8e9; classtype:attempted-user; sid:47900; rev:2;) alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"MALWARE-CNC Win.Trojan.MSDownloader variant outbound connection"; flow:to_server,established; content:"MS_D0wnl0ad3r"; fast_pattern:only; http_header; metadata:impact_flag red, policy balanced-ips drop, policy max-detect-ips drop, policy security-ips drop, ruleset community, service http; reference:url,www.virustotal.com/#/file/c3c5d7961381c202c98badc7ff0739b4f381c10b4e76d153ad2a978118a4b505/detection; classtype:trojan-activity; sid:47934; rev:1;) . . ``` #### Rules Syntax Snort Rules are made up of two primary components: The Rule Header and The Rule Option:

The header is the part prior to the parenthesis. The Options are enclosed in the parenthesis.

**Rule Header**\ **alert** — Rule action. Snort will generate an alert when the set condition is met.\ **any** — Source IP. (If you use “any” Snort will look at all sources.)\ **any** — Source port. (If you use “any” Snort will look at all ports.)\ \&#xNAN;**->** — Direction. From source to destination.\ **any** — Destination IP. Snort will look at all destinations on the protected network.\ **any** — Destination port. Snort will look at all ports on the protected network. **Rule Options**\ **msg:”ICMP test”** — Snort will include this message with the alert.\ **rev:1** — Revision number. This option allows for easier rule maintenance.\ **classtype:icmp-event** — Categorizes the rule as an “icmp-event”, one of the predefined Snort categories. This option helps with rule organization. If we want to look at requests from a particular target, what should we do? It’s simple. Just replace “any” to the desired IP or port. For example a Snort rule; ``` alert tcp 192.168.x.x any -> $HOME_NET 21 (msg:”FTP connection attempt”; sid:1000002; rev:1;) ``` **note:** Snort rule options are separated from each other using a semicolon. {% hint style="success" %} take a look at bottom of this page for additional notes and information about snort rules. {% endhint %} In here *$HOME\_NET is defined* in snort.conf. > Read more article about that *how to write a Snort rules file for secure network and how to design a Snort architecture.* #### Keeping the Snort Rules Updated Snort contains two main types of rules: **community rules** developed by the Snort community and **official rules**. You can always update the community rules by default. But to update the official rules, you need an Oink Code – a code which allows you to download the latest rule (visit : )
After registering, confirm the account from your email and login to the Snort site. On the dashboard left side menu, press OinkCode and you will see your code.
``` https://www.snort.org/rules/snortrules-snapshot-.tar.gz?oinkcode= ``` the result url would be something like this: ``` https://www.snort.org/rules/snortrules-snapshot-29151.tar.gz?oinkcode=15e4f48aab11b956bb27801172720f2be9f3686d ``` > You can create a cron script to download and extract the rules to the proper directory. ### snort commands
snortIf you run snort without any parameters you can think of it like tcpdump. It would dump bunch of network traffic for you.
snort -DIt is also possible to run snort as a daemon and it would actively monitor our networks and analyze it based on rules we have installed.
snort-stat

snort-stat is a small script that generates a nice statistic on the port scans that were detected by snort and reported via /var/log/snort/alert . The output of this script is mailed to the user confgured in the /etc/snort/snort.

*note: might not present in the latest snort releases

## OpenVas and NASL #### What is OpenVas? The **Open** **V**ulnerability **A**ssessment **S**ystem, known more commonly as **OpenVAS**, is a suite of tools that work together to run tests against client computers using a database of known exploits and weaknesses. The goal is to learn about how well your servers are guarded against known attack vectors. Its capabilities include unauthenticated and authenticated testing, various high-level and low-level internet and industrial protocols, performance tuning for large-scale scans and a powerful internal programming language to implement any type of vulnerability test.
{% hint style="info" %} OpenVAS has been developed and driven forward by the company **Greenbone Networks** since 2006. As part of the commercial vulnerability management product family Greenbone Enterprise Appliance, the scanner forms the **Greenbone Community Edition** together with other open-source modules. {% endhint %} The scanner is supported by a "feed" with vulnerability tests that has a long history and is updated daily. This Greenbone Community Feed includes more than 50,000 vulnerability tests and compliance checks. {% hint style="info" %} #### installing OpenVas The required installation steps are different based on your operating system. note: in RedHat distributions selinux must be disabled in order to use openvas! {% endhint %} **note:** The **openvassd** program is the daemon for the openvas scanner. ## Administering OpenVAS ### updating the OpenVAS (GVM) Feeds Sometimes the config does not work as expected in OpenVAS so you will need to update the feeds. ### openvas-feed-sync Here are the three feeds to be updated: 
#1) GVMD DATA
openvas-feed-sync --type GVMD_DATA

#2)SCAP DATA
openvas-feed-sync --type SCAP

#3)CERT DATA
openvas-feed-sync --type CERT
Also, to update the feeds eventually, just type in `gvm-feed-update -h` . ### Keeping up to date on threats: The OpenVAS Security Scanner performs several security checks, each of them being coded as an external plugin coded in **NASL**. As new security holes are published every day, new plugins appear on the OpenVAS site ([www.openvas.org](http://www.openvas.org)). {% hint style="info" %} **What is NASL?** The **N**essus **A**ttack **S**cripting **L**anguage, usually referred to as **NASL**, is a scripting language that is used by vulnerability scanners like **Nessus** and **OpenVAS**. With NASL specific attacks can be automated, based on known vulnerabilities. Tens of thousands of plugins have been written in NASL for Nessus and OpenVAS. Files that are written in this language usually get the file extension **.nasl**. For the exploitation of a zero day attack it is possible for an end user of Nessus or OpenVAS to write custom code in NASL which is executed by these vulnerability scanners. {% endhint %} ### openvas-nvt-sync The script **`openvas-nvt-sync`** (or `greenbone-nvt-sync` )will fetch all new and updated security checks and install them at the proper location. Once this is done it will send a signal to the OpenVAS Scanner, openvassd(8) so that the new **NVT**s are loaded and considered for new security scans. The OpenVAS Scanner performs several security checks. These are called **N**etwork **V**ulnerability **T**ests (**NVT**s) and are mostly implemented in the programming language **NASL**. {% hint style="info" %} Requires restarting openvas-scanner(8) or send a SIGHUP to its main process. {% endhint %} **note:** Host should have access to rsync.openvas.org using the rsync protocol (TCP/UDP port 873). ### /etc/openvas/openvassd.conf The OpenVas has an ordinary configuration file: ``` # Configuration file of the OpenVAS Security Scanner # Every line starting with a '#' is a comment [Misc] # Path to the security checks folder: plugins_folder = /var/lib/gvm/plugins # Path to OpenVAS caching folder: cache_folder = /var/cache/gvm # Path to OpenVAS include directories: # (multiple entries are separated with colon ':') include_folders = /var/lib/gvm/plugins # Maximum number of simultaneous hosts tested : max_hosts = 30 # Maximum number of simultaneous checks against each host tested : max_checks = 10 # Niceness. If set to 'yes', openvassd will renice itself to 10. be_nice = no # Log file (or 'syslog') : logfile = /var/log/gvm/openvassd.log # Shall we log every details of the attack ? (disk intensive) log_whole_attack = no # Log the name of the plugins that are loaded by the server ? log_plugins_name_at_load = no # Dump file for debugging output, use `-' for stdout dumpfile = /var/log/gvm/openvassd.dump # Rules file : rules = /etc/gvm/openvassd.rules # CGI paths to check for (cgi-bin:/cgi-aws:/ can do) cgi_path = /cgi-bin:/scripts # Range of the ports the port scanners will scan : # 'default' means that OpenVAS will scan ports found in its # services file. port_range = default # Optimize the test (recommended) : optimize_test = yes # Optimization : # Read timeout for the sockets of the tests : checks_read_timeout = 5 # Ports against which two plugins should not be run simultaneously : # non_simult_ports = Services/www, 139, Services/finger non_simult_ports = 139, 445 # Maximum lifetime of a plugin (in seconds) : plugins_timeout = 320 # Safe checks rely on banner grabbing : safe_checks = yes # Automatically activate the plugins that are depended on auto_enable_dependencies = yes # Do not echo data from plugins which have been automatically enabled silent_dependencies = no # Designate hosts by MAC address, not IP address (useful for DHCP networks) use_mac_addr = no #--- Knowledge base saving (can be configured by the client) : # Save the knowledge base on disk : save_knowledge_base = no # Restore the KB for each test : kb_restore = no # Only test hosts whose KB we do not have : only_test_hosts_whose_kb_we_dont_have = no # Only test hosts whose KB we already have : only_test_hosts_whose_kb_we_have = no # KB test replay : kb_dont_replay_scanners = no kb_dont_replay_info_gathering = no kb_dont_replay_attacks = no kb_dont_replay_denials = no kb_max_age = 864000 #--- end of the KB section # If this option is set, OpenVAS will not scan a network incrementally # (10.0.0.1, then 10.0.0.2, 10.0.0.3 and so on..) but will attempt to # slice the workload throughout the whole network (ie: it will scan # 10.0.0.1, then 10.0.0.127, then 10.0.0.2, then 10.0.0.128 and so on... slice_network_addresses = no # Should consider all the NASL scripts as being signed ? (unsafe if set to 'yes') nasl_no_signature_check = yes #Certificates cert_file=@@OPENVAS_CERT@@/CA/servercert.pem key_file=@@OPENVAS_CERT@@/private/CA/serverkey.pem ca_file=@@OPENVAS_CERT@@/CA/cacert.pem # If you decide to protect your private key with a password, # uncomment and change next line # pem_password=password # If you want to force the use of a client certificate, uncomment next line # force_pubkey_auth = yes #end. db_address=/var/run/redis/redis.sock db_address=/var/run/redis/redis.sock ``` ### Securing Scanner Communication: The OpenVAS Scanner protects its communication with clients by using SSL. SSL requires the scanner to present a certificate to the client. The client can optionally present a certificate to the scanner. ### openvas-mkcert The **OpenVAS Security Scanner** protects the communication between the client and the scanner by using SSL. SSL requires the scanner to present a certificate to the client, and the client can optionally present a certificate to the scanner. This script **`openvas-mkcert`** creates a certificate authority (if none exists already) and generates the scanner certificate.
CommandeDescription
openvas-mkcert -q

quickly generate a new certificate, without asking any question.

The -q option will not prompt for input and select defaults.

openvas-mkcert -fforce over writing of already existing certificate files
that's all. . additional notes: {% hint style="info" %} **Snort Rules** as we mentioned above Snort Rules are made up of two primary components: * The Rule Header * and The Rule Option. Snort Rule Template: **\[action]\[protocol]\[sourceIP]\[sourceport] -> \[destIP]\[destport] ( \[Rule options] )** The header is the part prior to the parenthesis. The Options are enclosed in the parenthesis. ## Rule Header Format: action Action to take (option) The rule action tells Snort what to do when it finds a packet that matches the rule criteria (usually alert). **`Actions`**`:` * **alert** — Generate an alert based on configuration and log packet * **pass** — Do not intercept * **log** — Log packet * **activate** — Alert and turn on dynamic rule * **dynamic** — A rule that may only be enabled by activate * **reject** — Drop packet, log packet, and send TCP reset on TCP connections and ICPM port unreachable for UDP connections * **drop** — Drop packet * **sdrop** — Drop packet and do not log **`protocol`**: Type of traffic. There are four protocols that Snort currently analyzes for suspicious behavior: TCP, UDP, ICMP, and IP. *Source address(es)* * [x] Traffic source address(es). May be variable or literal. *Source port(s)* * [x] Traffic source port(s). * [x] May be variable or literal. **->** * [x] Direction operator * [x] The direction operator -> indicates the orientation of the traffic to which the rule applies. *Destination address(es)* * [x] Traffic destination address(es). May be variable or literal. *Destination port(s)* * [x] Traffic destination port(s). May be variable or literal. ### ### **Rule Options** Snort rule options are separated from each other using a semicolon. Rule option keywords are separated from their arguments with a colon. There are two types of rule option: **General** and **Detection**. #### #### ***General Rule Options*** **Message** A meaningful message typically includes what the rule is detecting. It is a simple text string. **Flow** For the rule to fire, specifies which direction the network traffic is going. Used in conjunction with TCP stream reassembly. It allows rules to only apply to certain directions of the traffic flow. **Reference** Allows rules to include references to external sources of information (such as a URL). **Classtype** How Snort shares what the effect of a successful attack would be. **sid/rev** The snort id is a unique identifier for each rule. This information allows output plugins to identify rules easily and should be used with the rev (revision) keyword. #### #### ***Detection Rule Options:*** **Content** Allows the user to set rules that search for specific content in the packet payload and trigger response based on that data. May contain mixed text and binary data. **distance/offset** Allow the rule writer to specify where to start searching relative to the beginning of the payload or the beginning of a content match. **within/depth** Allow the write rule to specify how far forward to search relative to the end of a previous content match and, once that content match is found, how far to search for it. **PCRE** Allows rules to be written using Perl compatible regular expressions which allows for more complex matches than simple content matches. Byte test. Allows a rule to test a number of bytes against a specific value in binary. {% endhint %} . . . resources: . --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://borosan.gitbook.io/lpic3-exam-guide/334.2-network-intrusion-detection.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.