Bug #4016
openfilesize with filestore store empty files
Description
Hi!
I have configured suricata with the following filestore options:
- file-store:
version: 2
enabled: yes
dir: filestore
write-fileinfo: yes
force-hash: [sha1, md5]
And I have added the following rule to store ZIP files when the file size is smaller than 3 MB:
alert http any any -> any any (msg:"ZIP < 3MB filestore"; fileext:"zip"; filesize:<3MB; filestore; sid:5; rev:1;)
When i test it with a pcap, the rule generate an alert and file info and file are stored:
# ls -ltrh filestore/7a/7a523db62d17643f7ea0839928fc7891a821471b799acd98f5361cb96476f36b* -rw-r--r--. 1 root root 947 oct 6 18:20 filestore/7a/7a523db62d17643f7ea0839928fc7891a821471b799acd98f5361cb96476f36b.1598688683.1.json -rw-r--r--. 1 root root 0 oct 6 18:20 filestore/7a/7a523db62d17643f7ea0839928fc7891a821471b799acd98f5361cb96476f36b
But.. the file is empty, as you can see in the previous size..
If i delete filesize keyword from the rule, and test it again, the file is stored correctly:
# ls -ltrh filestore/7a/7a523db62d17643f7ea0839928fc7891a821471b799acd98f5361cb96476f36b* -rw-r--r--. 1 root root 946 oct 6 18:23 filestore/7a/7a523db62d17643f7ea0839928fc7891a821471b799acd98f5361cb96476f36b.1598688683.1.json -rw-r--r--. 1 root root 100K oct 6 18:23 filestore/7a/7a523db62d17643f7ea0839928fc7891a821471b799acd98f5361cb96476f36b
How can i correct this issue?
There is some feature i have to enable with filesize keyword?
Is it a bug?
thanks a lote for your help!
Updated by pepe llopis about 4 years ago
pepe llopis wrote:
Hi!
I have configured suricata with the following filestore options:
- file-store:
version: 2
enabled: yes
dir: filestore
write-fileinfo: yes
force-hash: [sha1, md5]And I have added the following rule to store ZIP files when the file size is smaller than 3 MB:
alert http any any -> any any (msg:"ZIP < 3MB filestore"; fileext:"zip"; filesize:<3MB; filestore; sid:5; rev:1;)
When i test it with a pcap, the rule generate an alert and file info and file are stored:
- ls
ltrh filestore/7a/7a523db62d17643f7ea0839928fc7891a821471b799acd98f5361cb96476f36b*. 1 root root 947 oct 6 18:20 filestore/7a/7a523db62d17643f7ea0839928fc7891a821471b799acd98f5361cb96476f36b.1598688683.1.json
-rw-r--r-rw-r--r-. 1 root root 0 oct 6 18:20 filestore/7a/7a523db62d17643f7ea0839928fc7891a821471b799acd98f5361cb96476f36bBut.. the file is empty, as you can see in the previous size..
If i delete filesize keyword from the rule, and test it again, the file is stored correctly:
- ls
ltrh filestore/7a/7a523db62d17643f7ea0839928fc7891a821471b799acd98f5361cb96476f36b*. 1 root root 946 oct 6 18:23 filestore/7a/7a523db62d17643f7ea0839928fc7891a821471b799acd98f5361cb96476f36b.1598688683.1.json
-rw-r--r-rw-r--r-. 1 root root 100K oct 6 18:23 filestore/7a/7a523db62d17643f7ea0839928fc7891a821471b799acd98f5361cb96476f36bHow can i correct this issue?
There is some feature i have to enable with filesize keyword?
Is it a bug?thanks a lote for your help!
Nobody has this problem? :S
Updated by Andreas Herz over 1 year ago
- Related to Bug #5868: filestore: not saving files when filestore enabled by rule matching on file_data (instead saves 0 bytes) added
Updated by Andreas Herz over 1 year ago
Sorry for the late response, but we got another issue that sounds like the same as yours. Can you retest with Suricata 7.0 RC1 for example?
Also can you share a pcap with your case so we could reproduce it?
Updated by Philippe Antoine 6 months ago
- Assignee set to Community Ticket
- Label Needs Suricata-Verify test added