Project

General

Profile

Actions

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 over 9 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
Effort:
Difficulty:
Label:

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.

Actions #1

Updated by Victor Julien over 9 years ago

  • Parent task set to #885
Actions #2

Updated by Duane Howard over 8 years ago

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.

Actions #3

Updated by Duane Howard over 8 years ago

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.

Actions #4

Updated by Victor Julien over 8 years ago

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?

Actions #5

Updated by Duane Howard over 8 years ago

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.

Actions #6

Updated by Andreas Herz over 8 years ago

  • Assignee set to OISF Dev
  • Target version set to TBD
Actions #7

Updated by Victor Julien over 4 years ago

  • 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.

Actions

Also available in: Atom PDF