You can also see the « community_id »: « 1:ETRbv54GHTVCayHTUR5OIovK4gh2= » in the output, which is the community feed ID you configured in the /etc/suricata/suricata.yaml file. In this tutorial, you will learn how Suricata signatures are structured and some important options that are commonly used in most rules. Once you`re comfortable understanding the structure and fields of a signature, you can write your own signatures that you can combine with a firewall to alert you to the most suspicious traffic to your servers without having to use other external rule sets. In this tutorial, you configured Suricata to block suspicious network traffic using built-in IPS mode. You have also added custom signatures to inspect and block SSH, HTTP, and TLS traffic on non-default ports. To tie this together, you`ve also added firewall rules that route traffic through Suricata for processing. The first two INPUT and OUTPUT rules are used to bypass Suricata so that you can connect to your server via SSH even when Suricata is not running. Without these rules, a false or overly broad signature could block your SSH access. Also, when Suricata is stopped, all traffic is sent to the NFQUEUE target and then deleted because Suricata is not running. The implicit priority of the signature is 2 because this is the value assigned to the incorrect-unknown class type in /etc/suricata/classification.config. If you want to override the default priority for a class type, you can add the priority:n option to a signature, where n is a value between 1 and 255. This warning would not be as useful because it does not contain a message about the package or a classification type. To add additional information to an alert and match more specific criteria, Suricata rules have an Options section where you can specify a number of additional parameters for a signature.
alert: Instructs Suricata to report this behavior as a warning (this is required in the rules created for the STA). Now run the following kill command to notify your Suricata process ($(pidof suricata)) to update the rules without restarting. If you want to examine full signatures that contain many more options than those described in this tutorial, browse the files in the /etc/suricata/rules directory. If there is a field in a rule that you want to learn more about, the Suricata rule documentation is the authoritative resource for the meaning of each option and its possible values. Find and edit the rule in your /etc/suricata/rules/suricata.rules file to use the drop action if you included the signature. Otherwise, add the rule to your /etc/suricata/rules/local.rules file. If you create your own signatures, the range 1000000-199999999 is reserved for custom rules. Suricata`s built-in rules range from 2200000-2299999. Other SID zones are documented on the SID Assignment for New Threats page. Note: If you ran suricata-update in the required tutorial, you may have more than 30,000 signatures in your suricata.rules file.
To add the required rules for Suricata to UFW, you must directly edit the firewall files in /etc/ufw/before.rules and /etc/ufw/before6.rules. Replace your server`s public IP address with 203.0.113.5 and 2604:a880:cad:d0::d usually c8:4001/64. If you are not using IPv6, you can ignore adding this signature in this and subsequent rules. If you convert each signature to deletion or rejection, you risk blocking legitimate access to your network or servers. Instead, leave the rules in suricata.rules for now and add your custom signatures to local.rules. Suricata continues to generate alerts for suspicious traffic described by signatures in suricata.rules when running in IPS mode. At this point, you will receive a No rules file that matches the template error message, like the one below, when you try to start and use your Suricata service. This error message indicates that there is no rule set for Suricata. The -T flag tells Suricata to run in both test and top-down mode. Both modes have stricter rules for matching packets and are less likely to become false positives. The first tutorial in this series explains how to install and configure Suricata.
If you`ve completed this tutorial, you`ve also learned how to download and update Suricata rule sets and review logs for suspicious activity alerts. However, the rules you downloaded in this tutorial are numerous and cover many different protocols, applications, and attack vectors that may not be relevant to your network and servers. If you are using iptables, you can insert these rules directly using the iptables and ip6tables commands. However, you must ensure that the rules are persistent in restarts by using a tool such as iptables-persistent persistent. Finally, run the suricata-update command again to load the newly selected rule set. You can always add custom signatures to this local.rules file, depending on your network and applications. For example, if you want to warn non-default ports on HTTP traffic, you can use the following signatures: 5. Run the following command to install suricata on your system. Below you can see a small part of the list.
Note a rule set name from which you want Suricata to retrieve rule sets. This tutorial retrieves the rule sets and/open for demonstration (step three). Note: If you are using a different firewall, you must adapt these rules to the format expected by your firewall. At this point in the tutorial, you have configured Suricata to run in IPS mode and your network traffic is sent to Suricata by default. You can restart your server at any time and your Suricata and firewall rules are persistent. Once you are satisfied with the signatures that you have created or inserted using the suricata-update tool, you can proceed to the next step, where you change the default action for your alert or active traffic log signatures. Run the following suricata command to verify changes to the Suricata configuration file (-c /etc/suricata/suricata.yaml). The command also displays all validation messages (-v). Note: Signatures can also use a non-directional marker that corresponds to traffic in both directions. However, the Suricata documentation on directional markers points out that most rules use the right arrow >. In this tutorial, you learned how to install and configure Suricata with rule sets to protect your network.
You also tested whether the rule sets work by driving traffic to your network. There`s a lot more to learn about Suricata rules that support RegEx parsing, protocol-specific parsing (just like uricontent for HTTP), searching for binary (non-text) data using hexadecimal byte values, and more. If you want to know more, you can start here. When you use firewalld, the following rules route traffic to Suricata: The suricata-update command retrieves rule sets from many providers, including free and commercial providers. Previous tutorials in this series explained how to install and configure Suricata and how to understand signatures. If you want to create and insert your own signatures, you must edit the Suricata /etc/suricata/suricata.yaml file to add it. Each Suricata signature requires a unique signature ID (sid). If two rules have the same sid (in the following example output, it is sid:10000000), Suricata does not start and instead generates an error similar to the following: 6. Once the installation is complete, run the systemctl status command below to check the status of the suricata service. Open your /etc/suricata/rules/local.rules file with nano or your favorite editor and change the warning action at the beginning of each line of the drop file: A full explanation of how to use each option in a Suricata rule is beyond the scope of this tutorial. The Suricata rules documentation starting with section 6.2 describes each keyword option in detail.
Repeat the above step for all signatures in /etc/suricata/rules/suricata.rules that you want to convert to delete or reject mode. 2. Next, run the add-apt-repository command to add the PPA repository managed by the Open Information Security Foundation (OISF).