Here I attach both the pcap of the ok case and the failed one, because I have noticed that for the ok case when retrying the download, this is completed.
ok_case.pcap (104.4 KB)
failing_case.pcap (250.4 KB)
Here I attach both the pcap of the ok case and the failed one, because I have noticed that for the ok case when retrying the download, this is completed.
ok_case.pcap (104.4 KB)
failing_case.pcap (250.4 KB)
This is interesting. The one that isnât successfully blocked is blocked at first. You can see the retransmissions at the end of the stream here:
Then Firefox finds that the stream timed out and retries, fetching only the missing data. For this it uses byte-ranges support. This is currently not supported by Suricata, but in development.
I will momentarily use this option:
drop IP any any -> any any (msg:"Malicious file detected"; content:"GET"; http_method; content:"www.example.com"; uricontent:"/examples/malware_sample.exe"; priority:1; sid:1; rev:2;)
One other thing to try is to use xbits
to drop the byte-range 206 response. This would look something like:
alert http any any -> any any (msg:"File stored: EXE"; fileext:"exe"; filestore; sid:1; rev:1;)
# Drop file based on hash and tag the IP-Pair for an hour.
drop http any any -> any any (msg:"Malicious file detected"; filesha256:/etc/suricata/blacklist.sha-2; xbits:set, blocked_http, track ip_pair, expire 3600; sid:2; rev:2;)
# drop 206 response for the IP-Pair in which we already dropped before.
drop http any any -> any any (msg:"Block 206 response for IPPair"; content:"206"; http_stat_code; xbits:isset, blocked_http, track ip_pair; priority:1; sid:3; rev:1;)
Yes, with this the file drop works perfectly after retry download. To perform this test, I had to pause the download the first time to give the filesha256 rule time to run, otherwise, as we already knew, the file ends up downloaded
I donât understand the pausing requirement. I thought before we had established that the initial download passes the file except for the last chunk of data. That is then dropped, but as firefox retries with byte-range support it is able to download the last missing part. Are you saying this is incorrect?
If so, can you share another pcap to show how it is passed through?
No, what Iâm trying to say is that in the pcap everything seems to be correct, but in practice, the rule âBlock 206 Response for IPPairâ works, but the âMalicious file detectedâ rule as I said previously only works with very small files (76K), and sometimes not even that, and it is that by the time the log of this rule is shown (in fast.log) the file has finished downloading a few seconds before, that is why the pause test, to allow time for rules to run.
What do your libhtp settings look like in your suricata.yaml
?
libhtp:
default-config:
personality: IDS
# Can be specified in kb, mb, gb. Just a number indicates
# it's in bytes.
request-body-limit: 100kb
response-body-limit: 100kb
By default the body is tracked for max 100KiB
. Can you try setting it to 0
(unlimited)?
With this now if everything works !!!
Thank you very much for everything.
Here I share the summary of all the elements present in the answers that were necessary for the solution:
(1) Suricata version: 5.0.2
(2) In the configuration file: suricata.yaml
file-store:
version: 2
enabled: yes
#dir: filestore
#write-fileinfo: no
#force-filestore: no
stream-depth: 0
libhtp:
default-config:
personality: IDS
request-body-limit: 0
response-body-limit: 0
(3) Rules:
alert http any any -> any any (msg:"File stored: EXE"; fileext:"exe"; filestore; sid:1; rev:1;)
drop http any any -> any any (msg:"Malicious file detected"; filesha256:/etc/suricata/blacklist.sha-2; xbits:set, blocked_http, track ip_pair, expire 3600; sid:2; rev:2;)
drop http any any -> any any (msg:"Block 206 response for IPPair"; content:"206"; http_stat_code; xbits:isset, blocked_http, track ip_pair; priority:1; sid:3; rev:1;)
Thanks for everything one more time.
Great, thanks for your patience and the nice summary