custom rules to block TLDs
-
I was reading this topic (pihole), but want to use suricata to block the TLDs.
I found this rule in the existing rule set:
alert dns $HOME_NET any -> any any (msg:"ET DNS Query for .to TLD"; dns.query; content:".to"; endswith; fast_pattern; classtype:bad-unknown; sid:2027757; rev:5; metadata:affected_product Any, attack_target Client_Endpoint, created_at 2019_07_26, deployment Perimeter, former_category DNS, signature_severity Minor, updated_at 2020_09_17;)
looks like duplicating this rule in the custom.rules list, with the modified TLD should do the trick.
Question: What "sid" do I use for these rules, ensuring there are no conflicts with rules already in use, also future proof?
Also, I found this document, explaining how to create / add a rules file.
suricata.yaml content (no custom.rules entry):
default-rule-path: /usr/local/etc/suricata/suricata_47597_igc0/rules rule-files: - suricata.rules - flowbit-required.rules
but the file custom.rules (no content) already exists in the specified folder. Should I assume I don't need to add "- custom.rules" to the yaml file, e.g. will it be added as soon as custom.rules has content?
Thanks for your time and effort.
-
On pfSense, NEVER directly edit anything at the command-line. All configuration files are recreated from scratch each time Suricata is started or restarted within the GUI. pfSense packages store all of their configuration information inside a custom XML file and then write it out to any required *.conf or *.yaml files when starting. So any edits you make will be immediately overwritten.
You can easily add your own custom rules by going to the RULES tab for the interface, selecting Custom Rules in the Category drop-down, and then typing your rule in the text box. Click Save when done.
SIDs (signature IDs) must never be duplicated. Most folks start their custom rule SIDs up around 1 million to be sure they are out of scope of any commercial rules. So, start your SIDs with 1000xxx and you should be good.