Suricata git repository maintained by the OISF
Switch branches/tags
suricata-4.1.0-rc2 suricata-4.1.0-rc1 suricata-4.1.0-beta1 suricata-4.0.5 suricata-4.0.4 suricata-4.0.3 suricata-4.0.2 suricata-4.0.1 suricata-4.0.0 suricata-4.0.0-rc2 suricata-4.0.0-rc1 suricata-4.0.0-beta1 suricata-3.2.5 suricata-3.2.4 suricata-3.2.3 suricata-3.2.2 suricata-3.2.1 suricata-3.2 suricata-3.2beta1 suricata-3.2RC1 suricata-3.1.4 suricata-3.1.3 suricata-3.1.2 suricata-3.1.1 suricata-3.1 suricata-3.1RC1 suricata-3.0.2 suricata-3.0.1 suricata-3.0.1RC1 suricata-3.0 suricata-3.0RC3 suricata-3.0RC2 suricata-3.0RC1 suricata-2.1beta4 suricata-2.1beta3 suricata-2.1beta2 suricata-2.1beta1 suricata-2.0.11 suricata-2.0.10 suricata-2.0.9 suricata-2.0.8 suricata-2.0.7 suricata-2.0.6 suricata-2.0.5 suricata-2.0.4 suricata-2.0.3 suricata-2.0.2 suricata-2.0.1 suricata-2.0.1rc1 suricata-2.0 suricata-2.0rc3 suricata-2.0rc2 suricata-2.0rc1 suricata-2.0beta2 suricata-2.0beta1 suricata-1.4.7 suricata-1.4.6 suricata-1.4.5 suricata-1.4.4 suricata-1.4.3 suricata-1.4.2 suricata-1.4.1 suricata-1.4 suricata-1.4rc1 suricata-1.4beta3 suricata-1.4beta2 suricata-1.4beta1 suricata-1.3.6 suricata-1.3.5 suricata-1.3.4 suricata-1.3.3 suricata-1.3.2 suricata-1.3.1 suricata-1.3 suricata-1.3rc1 suricata-1.3beta2 suricata-1.3beta1 suricata-1.2.1 suricata-1.2 suricata-1.2rc1 suricata-1.2beta1 suricata-1.1.1 suricata-1.1 suricata-1.1rc1 suricata-1.1beta3 suricata-1.1beta2 suricata-1.1beta1 suricata-1.0.5 suricata-1.0.4 suricata-1.0.3 suricata-1.0.2 suricata-1.0.1 suricata-1.0.0 suricata-0.8.2
Nothing to show
Clone or download
Permalink
Failed to load latest commit information.
.github github: codeowners syntax fixes Sep 30, 2017
benches Initial add of the files. Jul 28, 2009
contrib suri-graphite: add ouput to file option May 22, 2015
doc doc/flow: updates and cleanups to flow section Oct 17, 2018
ebpf ebpf: remove vlan_hdr alignement Mar 1, 2018
etc Sample systemd unit file for Suricata. Jul 24, 2017
lua lua output: Update example script to match style of user doc examples Mar 30, 2018
m4 prelude: update URL Oct 12, 2016
python source-pcap-file: delete when done (2417) Jul 13, 2018
qa qa/coccinelle: allow to run from non git directory May 4, 2018
rules smb: add smb-events.rules to dist Aug 2, 2018
rust rust/ike2: free destate on tx free Oct 16, 2018
scripts setup-app-layer: support tests in tests/ Sep 19, 2018
src cocci/detect: add flags check to SigTableElmt Oct 17, 2018
suricata-update suricata-update: bundle suricata update Mar 20, 2018
.gitignore suricata-update: bundle suricata update Mar 20, 2018
.travis.yml travis: update rust to 1.29.1, add auto & disabled tests Oct 8, 2018
COPYING GPL license sync with official gpl-2.0.txt Oct 8, 2015
ChangeLog changelog: update for 4.1rc2 Oct 16, 2018
LICENSE GPL license sync with official gpl-2.0.txt Oct 8, 2015
Makefile.am install-rules: use suricata-update if available May 3, 2018
Makefile.cvs Initial add of the files. Jul 28, 2009
README.md doc: README.md minor fixes Aug 31, 2018
acsite.m4 Added C99 defs/macros to acsite.m4 for CentOS Aug 24, 2009
appveyor.yml qa/appveyor: install libiconv-devel Mar 24, 2017
autogen.sh autogen/rust: remove Cargo.lock Jan 30, 2018
classification.config Added new classifications to classification.conf Oct 15, 2018
config.rpath Add file needed for some autotools version. Jul 17, 2013
configure.ac rust: enable by default Oct 8, 2018
doxygen.cfg doxygen: define UNITTESTS to generate test framework docs Apr 8, 2016
reference.config Update reference.config Jan 7, 2015
suricata.yaml.in eve/json: introduce community flow id Oct 11, 2018
threshold.config docs: replace redmine links and enforce https on oisf urls Feb 14, 2018

README.md

Suricata

Introduction

Suricata is a network IDS, IPS and NSM engine.

Installation

https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Suricata_Installation

User Guide

You can follow the Suricata user guide to get started.

Our deprecated (but still useful) user guide is also available.

Contributing

We're happily taking patches and other contributions. Please see https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Contributing for how to get started.

Suricata is a complex piece of software dealing with mostly untrusted input. Mishandling this input will have serious consequences:

  • in IPS mode a crash may knock a network offline;
  • in passive mode a compromise of the IDS may lead to loss of critical and confidential data;
  • missed detection may lead to undetected compromise of the network.

In other words, we think the stakes are pretty high, especially since in many common cases the IDS/IPS will be directly reachable by an attacker.

For this reason, we have developed a QA process that is quite extensive. A consequence is that contributing to Suricata can be a somewhat lengthy process.

On a high level, the steps are:

  1. Travis-CI based build & unit testing. This runs automatically when a pull request is made.

  2. Review by devs from the team and community

  3. QA runs

Overview of Suricata's QA steps

Trusted devs and core team members are able to submit builds to our (semi) public Buildbot instance. It will run a series of build tests and a regression suite to confirm no existing features break.

The final QA run takes a few hours minimally, and is started by Victor. It currently runs:

  • extensive build tests on different OS', compilers, optimization levels, configure features
  • static code analysis using cppcheck, scan-build
  • runtime code analysis using valgrind, DrMemory, AddressSanitizer, LeakSanitizer
  • regression tests for past bugs
  • output validation of logging
  • unix socket testing
  • pcap based fuzz testing using ASAN and LSAN

Next to these tests, based on the type of code change further tests can be run manually:

  • traffic replay testing (multi-gigabit)
  • large pcap collection processing (multi-terabytes)
  • AFL based fuzz testing (might take multiple days or even weeks)
  • pcap based performance testing
  • live performance testing
  • various other manual tests based on evaluation of the proposed changes

It's important to realize that almost all of the tests above are used as acceptance tests. If something fails, it's up to you to address this in your code.

One step of the QA is currently run post-merge. We submit builds to the Coverity Scan program. Due to limitations of this (free) service, we can submit once a day max. Of course it can happen that after the merge the community will find issues. For both cases we request you to help address the issues as they may come up.

FAQ

Q: Will you accept my PR?

A: That depends on a number of things, including the code quality. With new features it also depends on whether the team and/or the community think the feature is useful, how much it affects other code and features, the risk of performance regressions, etc.

Q: When will my PR be merged?

A: It depends, if it's a major feature or considered a high risk change, it will probably go into the next major version.

Q: Why was my PR closed?

A: As documented in the Suricata Github workflow here https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Github_work_flow, we expect a new pull request for every change.

Normally, the team (or community) will give feedback on a pull request after which it is expected to be replaced by an improved PR. So look at the comments. If you disagree with the comments we can still discuss them in the closed PR.

If the PR was closed without comments it's likely due to QA failure. If the Travis-CI check failed, the PR should be fixed right away. No need for a discussion about it, unless you believe the QA failure is incorrect.

Q: the compiler/code analyser/tool is wrong, what now?

A: To assist in the automation of the QA, we're not accepting warnings or errors to stay. In some cases this could mean that we add a suppression if the tool supports that (e.g. valgrind, DrMemory). Some warnings can be disabled. In some exceptional cases the only 'solution' is to refactor the code to work around a static code checker limitation false positive. While frustrating, we prefer this over leaving warnings in the output. Warnings tend to get ignored and then increase risk of hiding other warnings.

Q: I think your QA test is wrong

A: If you really think it is, we can discuss how to improve it. But don't come to this conclusion to quickly, more often it's the code that turns out to be wrong.

Q: do you require signing of a contributor license agreement?

A: Yes, we do this to keep the ownership of Suricata in one hand: the Open Information Security Foundation. See http://suricata-ids.org/about/open-source/ and http://suricata-ids.org/about/contribution-agreement/