so im trying to get suricata to detect and log an IP spoofing attempt, and this is the rule used:
alert tcp any any → any any (msg:“possible TCP spoofing attempt”;flags: A+; detection_filter: track by_dst, count 5, seconds 10; sid: 1000000;)
alert ip any any → any any (msg:“possible ip spoofing attempt”; src net 192.168.0.0/24; toclient; sid: 1000001;)
ive also tried alert ip any any → any any (iprep: ip-src, detected_source_address_type 10; sid: 1000002; msg: “Possible IP Spoofing Attempt”; ) and a few other variation
but the error i get is sudo suricata -c /etc/suricata/suricata.yaml -l /var/log/suricata -i ens33
11/7/2023 – 21:44:58 - - This is Suricata version 6.0.13 RELEASE running in SYSTEM mode
11/7/2023 – 21:45:29 - - [ERRCODE: SC_ERR_RULE_KEYWORD_UNKNOWN(102)] - unknown rule keyword ‘src net 192.168.0.0/24’.
11/7/2023 – 21:45:29 - - [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature “alert ip any any → any any (msg:“possible ip spoofing attempt”; src net 192.168.0.0/24; toclient; sid: 1000001;)” from file /etc/suricata/rules/spoofing.rules at line 2
11/7/2023 – 21:45:31 - - [ERRCODE: SC_WARN_POOR_RULE(276)] - rule 1000001: SYN-only to port(s) 80:80 w/o direction specified, disabling for toclient direction
11/7/2023 – 21:46:06 - - [ERRCODE: SC_ERR_INVALID_VALUE(130)] - fanout not supported by kernel: Kernel too old or cluster-id 99 already in use.
11/7/2023 – 21:46:06 - - all 1 packet processing threads, 4 management threads initialized, engine started.
can anyone help me on why this is rule is wrong?
btw: i already added the rule into the .yaml file
this is the method i used to test the alert, for i in range(5):
…: packet = IP(src=“192.168.198.10”, dst=“192.168.199.129”) /TCP()
…: send(packet)
using scapy in kali linux
Suricata doesn’t have a src rule keyword. IP address/port information is specified in the rule following the action keyword:
alert <protocol> <source-IP> <source-port> -> <destination-IP> <destination-port> (rule keywords; sid: <number>;)
Try
alert ip 192.168.0.0/24 any -> any any (...)
alright, the new rule i tested is alert ip 192.168.0.0/24 any → any any (msg:“possible ip spoofing attempt”; toclient; sid: 1000001;) but i still get the output sudo suricata -c /etc/suricata/suricata.yaml -l /var/log/suricata -i ens33
11/7/2023 – 21:57:46 - - This is Suricata version 6.0.13 RELEASE running in SYSTEM mode
11/7/2023 – 21:58:16 - - [ERRCODE: SC_ERR_RULE_KEYWORD_UNKNOWN(102)] - unknown rule keyword ‘toclient’.
11/7/2023 – 21:58:16 - - [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature “alert ip 192.168.0.0/24 any → any any (msg:“possible ip spoofing attempt”; toclient; sid: 1000001;)” from file /etc/suricata/rules/spoofing.rules at line 2
11/7/2023 – 21:58:18 - - [ERRCODE: SC_WARN_POOR_RULE(276)] - rule 1000001: SYN-only to port(s) 80:80 w/o direction specified, disabling for toclient direction
11/7/2023 – 21:58:52 - - [ERRCODE: SC_ERR_INVALID_VALUE(130)] - fanout not supported by kernel: Kernel too old or cluster-id 99 already in use.
11/7/2023 – 21:58:52 - - all 1 packet processing threads, 4 management threads initialized, engine started.
^C11/7/2023 – 21:58:55 - - Signal Received. Stopping engine.
11/7/2023 – 21:58:57 - - Stats for ‘ens33’: pkts: 24, drop: 0 (0.00%), invalid chksum: 0
so do i remove the toclient option in the rule?
Yes … toclient is not a rule keyword either.
We provide documentation to help with rule writing so if you continued to see SC_ERR_INVALID_SIGNATURE, you can check there also. We try to identify the issue with the rules.
The Suricata output you posted has some other issues SC_WARN_POOR_RULE and SC_ERR_INVALID_VALUE that need addressing.
alright thanks for your assistance, ive managed to fix the invalid signature and invalid value but do not know how to fix the warn poor rule… i have tried adding
directions:
into the suricata.yaml file but it doesnt work
Note that direction is implied outside of the rule keyword (parenthesized section) with alert source-ip source-port -> dest-ip dest-port.
to_client is a modifier of the flow keyword and thus only with tcp-based connections; here’s an example:
alert http any any -> any any (msg:"SURICATA HTTP Response invalid protocol"; flow:established,to_client; app-layer-event:http.response_invalid_protocol; flowint:http.anomaly.count,+,1; classtype:protocol-command-decode; sid:2221040; rev:1;)
ok might be another dumb question, but im trying to create a ruleset that detects packet tampering using statistical anomaly and flow anomalies,
alert tcp any any → any any (msg: “Possible TCP tampering if ACK or push flag detected and packet size larher than 500 within a period of time”; flags: AP; flowbits: set, anomaly_detected; dsize: >500; threshold: type threshold, track by_src, count 5, seconds 60; sid: 1000006;)
alert tcp any any → any any (msg: “Possible TCP flow anomaly if ACK or push flags detected within established flow with abnormal delay”; flags: AP; flow: established, to_server; detection_filter: track by_dst, count 2, seconds 30; sid: 1000007;)
the 2 rules in question.
and ive tested it using scapy and while the first rule works and gives an alert, the second rule doesnt.
code used to test:
first rule -
for i in range(5):
…: packet = IP(src=“192.168.199.110”, dst=“192.168.199.129”) / TCP(flags=“AP”) / Raw(load=“A” * 600)
…: send(packet)
second rule -
from scapy.all import *
…:
…: # Craft TCP packet with the desired flag combination and source/destination IP addresses
…: packet = IP(src=“192.168.199.120”, dst=“192.168.199.129”) / TCP(flags=“AP”)
…:
…: # Send the packet to establish the flow
…: send(packet)
…:
…: # Wait for a short period of time to allow the flow to be considered established
…: time.sleep(10)
…:
…: # Send additional packets within the established flow with the desired flag combination
…: for i in range(2):
…: send(packet)
…: time.sleep(4) edit: ive tried changing this to time.sleep(35) it still doesnt work
am i doing something really stupid as to why the second rule doesnt give an alert? like is my rule set incorrectly or is my method of testing wrong?
nevermind i managed to fix this
1 Like