Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC/Preview: Filestore stream-depth fixes v2 #3265

Closed
wants to merge 4 commits into from

Conversation

glongo
Copy link
Contributor

@glongo glongo commented Mar 5, 2018

Make sure these boxes are signed before submitting your Pull Request -- thank you.

Link to redmine ticket:
https://redmine.openinfosecfoundation.org/issues/2264

Describe changes:

In the previous patchset, when a TX was flagged by file-store, at some point
the request or response body reassembled reaches its respective body limit,
so the chunk's len calculated by the line below is zero, which is cleary wrong:

len = hstate->cfg->request.body_limit - tx_ud->request_body.content_len_so_far;

This happens because a TX is flagged but then the stream depth value is not used
to determine the length of a chunk.
To calculate the correct length, when a TX is not flagged the body limit is used,
in the other case, when a TX is flagged, the stream depth value set is used.

While testing it, I have noticed that in case of file storing a file in TOSERVER direction,
if a file will be truncated its state will be closed, as you can see in the example below:

outputs.14.file-store.stream-depth = 50kb
app-layer.protocols.http.libhtp.default-config.request-body-limit = 20kb
# cat var/log/suricata/files/file.1.meta 
TIME:              03/05/2005-15:33:05.147818
PCAP PKT NUM:      11
SRC IP:            131.212.31.167
DST IP:            128.119.245.12
PROTO:             6
SRC PORT:          2096
DST PORT:          80
APP PROTO:         http
HTTP URI:          /ethereal-labs/lab3-1-reply.htm
HTTP HOST:         gaia.cs.umass.edu
HTTP REFERER:      http://gaia.cs.umass.edu/ethereal-labs/TCP-ethereal-file1.html
HTTP USER AGENT:   Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
FILENAME:          C:\\bchoi\\class\\CS4411-5651-Spr05\\Labs\\ethereal\\alice.txt
MAGIC:             <unknown>
STATE:             CLOSED
MD5:               cc170abc361e0107e73b01194ccf47c8
SHA1:              5064decf143bfb3f0c020921c43c11505b43495c
SHA256:            7f368df4207fbd9015038a32acab63040468898bfa0224c5c91eb136d419b9c1
SIZE:              50972

The file size is around ~150kb, and here even the size is less the state is set to CLOSED.

Attached files contains all the cases tested: stream_depth_tests.txt

PRScript output (if applicable):

Giuseppe Longo added 4 commits March 5, 2018 09:24
When a new tcp session is created, the reassemby_depth
value is set by stream_config.reassembly_depth but
it could happen that this value is updated later.
For instance, when filestore keyword is used
the function TcpSessionSetReassemblyDepth is called
to update it.

StreamTcpReassembleCheckDepth doesn't use the value updated,
which is represented by ssn->reassembly_depth, but use the old
one represented by stream_config.reassembly_depth.

As a result, reassembly_depth value pointed by ssn is not
considered when a stream is reassembled, and a stream can be
truncated because the wrong reassembly_depth value is used.

To fix this, TcpSessionSetReassemblyDepth now checks on
ssn->reassembly_depth instead of stream_config.reassembly_depth.

Ticket OISF#2264
When an app-layer parser is enabled, it could set its
own stream_depth value calling the API AppLayerParserSetStreamDepth.

Then, the function AppLayerParserPostStreamSetup will replace
the stream_depth value already set with stream_config.reassembly_depth.

To avoid overwriting, in AppLayerParserSetStreamDepth API a flag
will be set internally to specify that a value is already set.
If a signature contains the filestore keyword,
a file is truncated if its size is greater than
response-body-limit.
When file-store.stream-depth is set,
it should be considered when a file is stored
but in that case is ignored and the files stored
are truncated.
@glongo glongo requested review from norg and a team as code owners March 5, 2018 09:08
@@ -63,6 +63,15 @@ of the filename. For example, if the SHA256 hex string of an extracted
file starts with "f9bc6d..." the file we be placed in the directory
`filestore/f9`.

The size of a file that can be stored depends on ``file-store.stream-depth``,
if this value is reached a file can be truncated and not stored completely.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

f this value is reached , a file can be truncated and might not be stored completely

@glongo
Copy link
Contributor Author

glongo commented Mar 13, 2018

new PR: #3282

@glongo glongo closed this Mar 13, 2018
silentcreek added a commit to silentcreek/suricata that referenced this pull request Feb 3, 2020
Using the run-as configuration option with the nflog capture method
results in the following error during the startup of suricata:
[ERRCODE: SC_ERR_NFLOG_BIND(248)] - nflog_bind_pf() for AF_INET failed

This is because SCDropMainThreadCaps does not have any capabilities
defined for the nflog runmode (unlike other runmodes). Therefore, apply
the same capabilities to the nflog runmode that are already defined for
the nfqueue runmode. This has been confirmed to allow suricata start
and drop its privileges in the nflog runmode.

Fixes redmine issue OISF#3265.

Signed-off-by: Timo Sigurdsson <public_timo.s@silentcreek.de>
victorjulien pushed a commit to victorjulien/suricata that referenced this pull request Feb 10, 2020
Using the run-as configuration option with the nflog capture method
results in the following error during the startup of suricata:
[ERRCODE: SC_ERR_NFLOG_BIND(248)] - nflog_bind_pf() for AF_INET failed

This is because SCDropMainThreadCaps does not have any capabilities
defined for the nflog runmode (unlike other runmodes). Therefore, apply
the same capabilities to the nflog runmode that are already defined for
the nfqueue runmode. This has been confirmed to allow suricata start
and drop its privileges in the nflog runmode.

Fixes redmine issue OISF#3265.

Signed-off-by: Timo Sigurdsson <public_timo.s@silentcreek.de>
victorjulien pushed a commit to victorjulien/suricata that referenced this pull request Feb 11, 2020
Using the run-as configuration option with the nflog capture method
results in the following error during the startup of suricata:
[ERRCODE: SC_ERR_NFLOG_BIND(248)] - nflog_bind_pf() for AF_INET failed

This is because SCDropMainThreadCaps does not have any capabilities
defined for the nflog runmode (unlike other runmodes). Therefore, apply
the same capabilities to the nflog runmode that are already defined for
the nfqueue runmode. This has been confirmed to allow suricata start
and drop its privileges in the nflog runmode.

Fixes redmine issue OISF#3265.

Signed-off-by: Timo Sigurdsson <public_timo.s@silentcreek.de>
(cherry picked from commit 1262ecb)
victorjulien pushed a commit to victorjulien/suricata that referenced this pull request Feb 12, 2020
Using the run-as configuration option with the nflog capture method
results in the following error during the startup of suricata:
[ERRCODE: SC_ERR_NFLOG_BIND(248)] - nflog_bind_pf() for AF_INET failed

This is because SCDropMainThreadCaps does not have any capabilities
defined for the nflog runmode (unlike other runmodes). Therefore, apply
the same capabilities to the nflog runmode that are already defined for
the nfqueue runmode. This has been confirmed to allow suricata start
and drop its privileges in the nflog runmode.

Fixes redmine issue OISF#3265.

Signed-off-by: Timo Sigurdsson <public_timo.s@silentcreek.de>
(cherry picked from commit 1262ecb)
@glongo glongo deleted the stream-depth-v2 branch February 28, 2024 14:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants