Suricata rule not detect

Rules
1

I set to use suricata.rules created with suricata-update and test.rules for testing.
The rules written in test.rules are as follows.

alert http any any -> any any (msg:"SQL Injection TEST"; flow:to_server; content:"union+select"; nocase; fast_pattern; classtype:attempted-recon; sid:0009833; rev:1;)
alert http any any -> any any (msg:"SQL Error Response TEST"; flow:to_client; http.response_body; content:"You have an error in your SQL syntax"; nocase; fast_pattern; classtype:successful-recon-limited; sid:0009834; rev:1;)

[test.rules]

DVWA was built on the target server (10.0.15.1) and SQL Injection was attempted. Below are the results of tcpdump and fast.log.

❯ sudo tcpdump -i eno2 host 10.0.15.51 and port 80 and 'tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno2, link-type EN10MB (Ethernet), capture size 262144 bytes
18:23:24.745187 IP 10.0.100.47.54120 > 10.0.15.51.http: Flags [P.], seq 2715230321:2715230993, ack 2344859543, win 2058, options [nop,nop,TS val 1457746562 ecr 3665391368], length 672: HTTP: GET /vulnerabilities/sqli/?id=1%27+union+select+user_id%2C+password%2C+avatar+from+users%3B+--&Submit=Submit HTTP/1.1
18:23:24.745187 IP 10.0.100.47.54120 > 10.0.15.51.http: Flags [P.], seq 0:672, ack 1, win 2058, options [nop,nop,TS val 1457746562 ecr 3665391368], length 672: HTTP: GET /vulnerabilities/sqli/?id=1%27+union+select+user_id%2C+password%2C+avatar+from+users%3B+--&Submit=Submit HTTP/1.1
18:23:24.838670 IP 10.0.100.47.54120 > 10.0.15.51.http: Flags [P.], seq 672:1300, ack 530, win 2050, options [nop,nop,TS val 1457746654 ecr 3665391382], length 628: HTTP: GET /favicon.ico HTTP/1.1
18:23:24.838670 IP 10.0.100.47.54120 > 10.0.15.51.http: Flags [P.], seq 672:1300, ack 530, win 2050, options [nop,nop,TS val 1457746654 ecr 3665391382], length 628: HTTP: GET /favicon.ico HTTP/1.1

[tcpdump result]

❯ sudo tail -f /log/suricata/fast.log | grep 10.0.15.51

[fast.log]

This is the rule setting in my suricata.yaml.

##
## Configure Suricata to load Suricata-Update managed rules.
##

default-rule-path: /etc/suricata/rules

rule-files:
  - test.rules
  - suricata.rules

##
## Auxiliary configuration files.
##

classification-file: /etc/suricata/classification.config
reference-config-file: /etc/suricata/reference.config
threshold-file: /etc/suricata/threshold.config

If suricata.rules is not used, it is normally detected.
I want to use both rules files.
How can I detect the rules in test.rules ?

2

Do you use enable.conf and add the sid(s) from test.rules in there?
Run suricata update (ensure that the sids are not duplicates from the rules sids in suricata.rules.

3

i no use enable.conf and sid is unique

4

Add the sid to /etc/suricata/enable.conf.
run suricata update
restart suricata

That should do the trick.

5

First of all, suricata-update does not refer to the rule I created.
I created the test.rules file and registered it directly in the rule-files of suricata.yaml.

Another thing I checked seems to be a problem with the rules I’ve created.

I tested by activating only the rules defined in test.rules.
After restarting suricata, it detects normally for a certain period of time, but after a period of time, the corresponding rule is not detected.

When suricata is executed including ET rules, it is detected well at first, but after a certain period of time, only the rules of test.rules are not detected.

My Server’s CPU and RAM are sufficient, and there are no Error or Warning logs in suricata.log.

6

I cannot spot anything wrong with your settings in suricata.yaml. Could you please

  1. Re-check the location of the rule files? Both of them must be in /etc/suricata/rules for Suricata to be able to detect them.
  2. Check for any typos in the file name mentioned in the configuration.

Also, could you please tell how are you deducing if Suricata is loading the rules or not?
Please check for a line like the following in your logs:

5/8/2021 -- 14:38:39 - <Info> - 1 rule files processed. 23096 rules successfully loaded, 0 rules failed

If you can see 2 files being loaded here, you might want to check if the rules would in fact match the traffic.

7

suricata.yaml (71.6 KB)
test.rules (400 Bytes)

The suricata.yaml and test.rules files are attached.

❯ sudo tcpdump -i eno2 host 10.0.15.51 and port 80 and 'tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno2, link-type EN10MB (Ethernet), capture size 262144 bytes
10:16:39.149535 IP 10.0.100.47.52267 > 10.0.15.51.http: Flags [P.], seq 645165058:645165730, ack 1686701862, win 2058, options [nop,nop,TS val 1418648088 ecr 3808956564], length 672: HTTP: GET /vulnerabilities/sqli/?id=1%27+union+select+user_id%2C+password%2C+avatar+from+users%3B+--&Submit=Submit HTTP/1.1
10:16:39.149535 IP 10.0.100.47.52267 > 10.0.15.51.http: Flags [P.], seq 0:672, ack 1, win 2058, options [nop,nop,TS val 1418648088 ecr 3808956564], length 672: HTTP: GET /vulnerabilities/sqli/?id=1%27+union+select+user_id%2C+password%2C+avatar+from+users%3B+--&Submit=Submit HTTP/1.1
10:16:39.232126 IP 10.0.100.47.52267 > 10.0.15.51.http: Flags [P.], seq 672:1300, ack 530, win 2050, options [nop,nop,TS val 1418648169 ecr 3808985759], length 628: HTTP: GET /favicon.ico HTTP/1.1
10:16:39.232162 IP 10.0.100.47.52267 > 10.0.15.51.http: Flags [P.], seq 672:1300, ack 530, win 2050, options [nop,nop,TS val 1418648169 ecr 3808985759], length 628: HTTP: GET /favicon.ico HTTP/1.1
10:16:44.235074 IP 10.0.100.47.52267 > 10.0.15.51.http: Flags [P.], seq 1300:1972, ack 2236, win 2048, options [nop,nop,TS val 1418653134 ecr 3808985836], length 672: HTTP: GET /vulnerabilities/sqli/?id=1%27+union+select+user_id%2C+password%2C+avatar+from+users%3B+--&Submit=Submit HTTP/1.1
10:16:44.235111 IP 10.0.100.47.52267 > 10.0.15.51.http: Flags [P.], seq 1300:1972, ack 2236, win *2048, options [nop,nop,TS val 1418653134 ecr 3808985836], length 672: HTTP: GET /vulnerabilities/sqli/?id=1%27+union+select+user_id%2C+password%2C+avatar+from+users%3B+--&Submit=Submit HTTP/1.1
10:16:44.363964 IP 10.0.100.47.52267 > 10.0.15.51.http: Flags [P.], seq 1972:2600, ack 2764, win 2048, options [nop,nop,TS val 1418653285 ecr 3808990825], length 628: HTTP: GET /favicon.ico HTTP/1.1
10:16:44.363964 IP 10.0.100.47.52267 > 10.0.15.51.http: Flags [P.], seq 1972:2600, ack 2764, win 2048, options [nop,nop,TS val 1418653285 ecr 3808990825], length 628: HTTP: GET /favicon.ico HTTP/1.1

[ tcpdump ]

❯ tail -f /log/suricata/fast.log | grep "10.0.15.51"

[fast.log]

HTTP requests including union+select string were sent to 10.0.15.51.

Although I can see 4 GET Requests in tcpdump.
Not detected in fast.log.

It is detected once or twice when checking the log, but it is not detected even if you send a request after that.

I use disable.conf, not enable.conf. The sid of the rule defined in test.rules is not included in disable.conf.

I guessed that it was not detected because of the fragment, I checked it with wireshark, and there was no fragment.

image 57
image 571769×508 228 KB

I tested the rule by directly designating the ip.
In this case, it showed normal detection.

alert http any any -> 10.0.15.51 any (msg:"SQL Injection TEST"; flow:to_server; content:"union+select"; nocase; fast_pattern; classtype:attempted-recon; sid:0009833; rev:1;)
alert http 10.0.15.51 any -> any any (msg:"SQL Error Response TEST"; flow:to_client; http.response_body; content:"You have an error in your SQL syntax"; nocase; fast_pattern; classtype:successful-recon-limited; sid:0009834; rev:1;)

❯ sudo tail -f /log/suricata/fast.log
08/06/2021-10:37:36.860938  [**] [1:2027865:4] ET INFO Observed DNS Query to .cloud TLD [**] [Classification: Potentially Bad Traffic] [Priority: 2] {UDP} 10.0.14.61:52916 -> 10.0.0.10:53
08/06/2021-10:37:36.861077  [**] [1:2027865:4] ET INFO Observed DNS Query to .cloud TLD [**] [Classification: Potentially Bad Traffic] [Priority: 2] {UDP} 10.0.14.61:61609 -> 10.0.0.10:53
08/06/2021-10:37:36.861078  [**] [1:2027865:4] ET INFO Observed DNS Query to .cloud TLD [**] [Classification: Potentially Bad Traffic] [Priority: 2] {UDP} 10.0.14.61:61609 -> 10.0.0.10:53
08/06/2021-10:37:36.861078  [**] [1:2027865:4] ET INFO Observed DNS Query to .cloud TLD [**] [Classification: Potentially Bad Traffic] [Priority: 2] {UDP} 10.0.14.61:61609 -> 10.0.0.10:53
08/06/2021-10:37:36.861078  [**] [1:2027865:4] ET INFO Observed DNS Query to .cloud TLD [**] [Classification: Potentially Bad Traffic] [Priority: 2] {UDP} 10.0.14.61:61609 -> 10.0.0.10:53
08/06/2021-10:37:57.828797  [**] [1:2018959:4] ET POLICY PE EXE or DLL Windows file download HTTP [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 23.203.135.145:80 -> 10.0.100.208:64696
08/06/2021-10:37:57.828797  [**] [1:2014819:3] ET INFO Packed Executable Download [**] [Classification: Misc activity] [Priority: 3] {TCP} 23.203.135.145:80 -> 10.0.100.208:64696
08/06/2021-10:37:58.659415  [**] [1:2001581:15] ET SCAN Behavioral Unusual Port 135 traffic Potential Scan or Infection [**] [Classification: Misc activity] [Priority: 3] {TCP} 10.0.15.49:56091 -> 10.0.100.162:135
08/06/2021-10:37:59.162146  [**] [1:2001569:15] ET SCAN Behavioral Unusual Port 445 traffic Potential Scan or Infection [**] [Classification: Misc activity] [Priority: 3] {TCP} 10.0.15.49:56091 -> 10.0.100.162:445
08/06/2021-10:37:59.410010  [**] [1:2001579:15] ET SCAN Behavioral Unusual Port 139 traffic Potential Scan or Infection [**] [Classification: Misc activity] [Priority: 3] {TCP} 10.0.15.49:56092 -> 10.0.100.56:139
08/06/2021-10:38:05.282031  [**] [1:9833:1] DHK SQL Injection TEST [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 10.0.100.47:52440 -> 10.0.15.51:80
08/06/2021-10:38:05.282031  [**] [1:9833:1] DHK SQL Injection TEST [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 10.0.100.47:52440 -> 10.0.15.51:80
08/06/2021-10:38:05.353676  [**] [1:9834:1] DHK SQL Error Response TEST [**] [Classification: Information Leak] [Priority: 2] {TCP} 10.0.15.51:80 -> 10.0.100.47:52440
08/06/2021-10:38:05.353676  [**] [1:9834:1] DHK SQL Error Response TEST [**] [Classification: Information Leak] [Priority: 2] {TCP} 10.0.15.51:80 -> 10.0.100.47:52440
08/06/2021-10:38:05.359875  [**] [1:9833:1] DHK SQL Injection TEST [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 10.0.100.47:52440 -> 10.0.15.51:80
08/06/2021-10:38:05.359875  [**] [1:9833:1] DHK SQL Injection TEST [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 10.0.100.47:52440 -> 10.0.15.51:80

It seems to be a problem with the suricata rule, is there a problematic part in my rule??

8

Could you try alert ip instead of alert http? Could be the case that http parsing is failing due to packet loss or the retransmissions.

You could also try http.uri; content:"union+select";

9

I have attached my rules above. I am using alert http.

alert http any any -> any any (msg:"SQL Injection TEST"; flow:to_server; content:"union+select"; nocase; fast_pattern; classtype:attempted-recon; sid:0009833; rev:1;)
alert http any any -> any any (msg:"SQL Error Response TEST"; flow:to_client; http.response_body; content:"You have an error in your SQL syntax"; nocase; fast_pattern; classtype:successful-recon-limited; sid:0009834; rev:1;)

After executing tcpdump, I sent HTTP Request and confirmed that there was a normal packet on tcpdump. Additionally, there was no fragment or packet loss.

10

Hi @headfish ,

Sorry for not checking in earlier (Shame on me), but did you manage to find a solution?