dns - support multiple requests before response - v2 #2386
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The advancement through the buffer was not taking into account the size of the length field resulting in the second request being detected as bad data.
Address the issue where a DNS response would not be logged when the traffic is like: - Request 1 - Request 2 - Response 1 - Response 2 which can happen on dual stack machines where the request for A and AAAA are sent out at the same time on the same UDP "session". A "window" is used to set the maximum number of outstanding responses before considering the olders lost.
|
I've added pcap tests for these to my verify repo: https://github.com/jasonish/suricata-verify/tree/master/dns-udp-double-request-response https://github.com/jasonish/suricata-verify/tree/master/dns-tcp-multirequest-buffer-1 |
This was referenced Oct 27, 2016
Merged
richi235
added a commit
to richi235/suricata
that referenced
this pull request
Jan 23, 2018
richi235
added a commit
to richi235/suricata
that referenced
this pull request
Jan 28, 2018
) Write permission on the logdir is necesarry to create new files in there, which is necesary after logrotation to continue logging. (use cases: exe.json and others) If suricata could open the log files but not create new ones it silently failed, not writing any logs after the first logrotation. This patch adds a check before priv drop and warns+exit()s if we will not be able to create new files after priv drop. If we won't drop privs we check if the current (and general) user will be able to create logfiles after log rotation. For details and discussion see: https://redmine.openinfosecfoundation.org/issues/2386
richi235
added a commit
to richi235/suricata
that referenced
this pull request
Feb 5, 2018
) Write permission on the logdir is necesarry to create new files in there, which is necesary after logrotation to continue logging. (use cases: exe.json and others) If suricata could open the log files but not create new ones it silently failed, not writing any logs after the first logrotation. This patch adds a check before priv drop and warns+exit()s if we will not be able to create new files after priv drop. If we won't drop privs we check if the current (and general) user will be able to create logfiles after log rotation. For details and discussion see: https://redmine.openinfosecfoundation.org/issues/2386
richi235
added a commit
to richi235/suricata
that referenced
this pull request
Feb 5, 2018
) Write permission on the logdir is necesarry to create new files in there, which is necesary after logrotation to continue logging. (use cases: exe.json and others) If suricata could open the log files but not create new ones it silently failed, not writing any logs after the first logrotation. This patch adds a check before priv drop and warns+exit()s if we will not be able to create new files after priv drop. If we won't drop privs we check if the current (and general) user will be able to create logfiles after log rotation. For details and discussion see: https://redmine.openinfosecfoundation.org/issues/2386
richi235
added a commit
to richi235/suricata
that referenced
this pull request
Feb 14, 2018
) Write permission on the logdir is necesarry to create new files in there, which is necesary after logrotation to continue logging. (use cases: exe.json and others) If suricata could open the log files but not create new ones it silently failed, not writing any logs after the first logrotation. This patch adds a check before priv drop and warns+exit()s if we will not be able to create new files after priv drop. If we won't drop privs we check if the current (and general) user will be able to create logfiles after log rotation. For details and discussion see: https://redmine.openinfosecfoundation.org/issues/2386
shivan1b
pushed a commit
to shivan1b/suricata
that referenced
this pull request
Oct 4, 2019
At the startup, if the default log dir provided either by command line options or suricat.yaml is not writable, the error comes quite later. This patch makes suricata exit if there is such an error in the beginning itself. Closes redmine ticket OISF#2386.
shivan1b
pushed a commit
to shivan1b/suricata
that referenced
this pull request
Oct 5, 2019
At the startup, if the default log dir provided either by command line options or suricat.yaml is not writable, the error comes quite later. This patch makes suricata exit if there is such an error in the beginning itself. Closes redmine ticket OISF#2386.
shivan1b
pushed a commit
to shivan1b/suricata
that referenced
this pull request
Oct 7, 2019
At the startup, if the default log dir provided either by command line options or suricat.yaml is not writable, the error comes quite later. This patch makes suricata exit if there is such an error in the beginning itself. Closes redmine ticket OISF#2386.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previous PR: #2380
Changes since last PR:
Prscript: