Feature #1283
closed
Feature #549: Extract file attachments from emails
Feature #885: smtp file_data support
support for snort's file_data keyword
Added by john howard about 10 years ago.
Updated about 5 years ago.
Description
I'm running pfSense 2.1.5-RELEASE (amd64) on (nano) FreeBSD 8.3-RELEASE-p16 with Suricata 2.0.3 pkg v2.0.2 and snortrules-snapshot-2962.tar.gz with snort 'balanced' IPS rules. I'm seeing the following in my logs:
18/9/2014 -- 14:04:09 - <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - Can't use file_data with flow:to_server or from_client with http.
I'm processing 2 rule files (IPS balanced and GPL Community Rules) of which 6968 rules successfully loaded, 937 rules failed to load. 90% of those failures were of this file_data error type.
What's the current plan to have full support for the file_data keyword? I've got a number of rules that choke and die with:
[ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - "http_header" keyword seen with a sticky buffer still set. Reset sticky buffer with pkt_data before using the modifier.
Most of these are VRT rules, and it'd be nice if they played well with Suricata.
More importantly I have some rules failing with:
[ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - Can't use file_data with flow:to_server or from_client with http.
Using file_data with http + flow is generally pretty useful and support in 2.1 here would be great.
In 2.0.x file_data is only supported for http server bodies, which implies to_client. In 2.1, smtp support was added so that is to_server. No other protocols are supported yet.
Other than for non-supported protocols, what rules do you have are rejected?
Actually there's only one VRT rule that was tripping up on this that's not SMTP related:
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"VRT FILE-IDENTIFY JPEG file upload detected"; flow:to_server,established; file_data; content:"|FF D8 FF E1|"; depth:4; flowbits:set,file.jpeg; flowbits:noalert; metadata:service http; classtype:misc-activity; sid:35852; rev:1;)
I actually think I can disable this, but it seems like the idea is for uploads from external clients to:server, probably looking at a POST body or similar? It seems like http_client_body might be more applicable here anyway.
- Assignee set to OISF Dev
- Target version set to TBD
- Status changed from New to Closed
- Assignee deleted (
OISF Dev)
- Target version deleted (
TBD)
We support file_data for the protocols we do file tracking for. I'm considering this done.
Also available in: Atom
PDF