[opensourcedex]

suricata is a free, open source network security project written in C and released under GPL-2.0. It has 6,646 GitHub stars, 1,769 forks and 86 open issues, and was last pushed 15 hours ago. On this registry it ranks #5 of 8 tracked projects in Network Security, with 5 head-to-head comparisons available.

What is suricata?

Suricata is a network Intrusion Detection System (IDS), Intrusion Prevention System (IPS) and Network Security Monitoring (NSM) engine developed by the OISF and the Suricata community, released under GPL-2.0 and written in C, for security teams that need to detect, block and record activity on the networks they operate.

What it is

Suricata is a single engine that covers three jobs that are often handled by separate products. It performs intrusion detection, intrusion prevention and network security monitoring, and it is developed by the Open Information Security Foundation together with the Suricata community. The project lives in the network security ecosystem alongside the wider set of cybersecurity and threat-hunting tools, and the repository is maintained under the OISF organisation on GitHub under GPL-2.0. It is a substantial C codebase with a long history of releases and an active pool of contributors.

The concrete problem it solves is the fragmentation that comes from running one tool to watch traffic, a second to block it and a third to retain and analyse it. Suricata brings those three roles into one engine that can be deployed in the mode the operator needs at that point. That consolidation matters operationally: the project treats its input as untrusted by default, and the README is explicit that mishandling that input has serious consequences. In IPS mode a crash may knock a network offline, while in passive mode a compromise of the IDS may lead to loss of critical and confidential data. Missed detection, in turn, may allow an undetected compromise of the network.

Key capabilities

  • Runs as an intrusion detection system, an intrusion prevention system and a network security monitoring engine from the same codebase.
  • Processes pcap files for replay-based testing and retrospective analysis of captured traffic.
  • Performs traffic replay based IDS and IPS tests, including multi-gigabit replay runs.
  • Handles large pcap collection processing, in the multi-terabyte range.
  • Validates logging output, and supports unix socket testing for runtime interaction.
  • Runs static code analysis with cppcheck and scan-build, and runtime code analysis with valgrind, AddressSanitizer and LeakSanitizer.
  • Applies pcap based fuzz testing using ASAN and LSAN, and submits builds to the Coverity Scan program.

Who uses it and how

  • Network defenders running it inline in IPS mode, where a crash can take a network offline and change control therefore matters.
  • Security teams running it passively as an IDS, accepting that the sensor itself is often directly reachable by an attacker and must be protected accordingly.
  • Threat-hunting and network-monitoring teams that need retained traffic and logging rather than only live alerts.
  • Analysts working over large pcap collections in the multi-terabyte range for investigation and review.
  • Contributors and downstream packagers validating changes against multi-gigabit traffic replay before anything reaches production.

Getting started

The README does not carry install commands; it points to the Installation Guide at https://docs.suricata.io/en/latest/install.html, with the home page at https://suricata.io and user support at the Suricata forum.

How it compares

No list of paid products that Suricata replaces is provided in the facts, and no comparable tools are named either, so on the available evidence it stands alone in this registry rather than being positioned against commercial alternatives.

When to use it — and when not to

Choose Suricata when the network is the thing being defended and the team is willing to own an engine that inspects untrusted traffic, including the operational risk that an inline failure affects connectivity. Do not choose it if the requirement is a managed, turnkey service with no packet-level operation involved, or if the team cannot absorb a C codebase and its update cycle. The honest limitation is in the documentation itself: the README is written for contributors, not operators, with no install steps, and contribution is deliberately slow because QA runs extensive build, analysis, fuzzing and replay suites that take hours to overnight, with Coverity submissions capped at one per day.

project readme (upstream, from github) — read inline

Suricata

Fuzzing Status codecov

Introduction

Suricata is a network IDS, IPS and NSM engine developed by the OISF and the Suricata community.

Resources

Contributing

We're happily taking patches and other contributions. Please see our Contribution Process 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. GitHub-CI based checks. This runs automatically when a pull request is made.
  2. Review by devs from the team and community
  3. QA runs from private QA setups. These are private due to the nature of the test traffic.

Overview of Suricata's QA steps

OISF team members are able to submit builds to our private QA setup. It will run a series of build tests and a regression suite to confirm no existing features break.

The final QA runs takes a few hours minimally, and generally runs overnight. 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, AddressSanitizer, LeakSanitizer
  • regression tests for past bugs
  • output validation of logging
  • unix socket testing
  • pcap based fuzz testing using ASAN and LSAN
  • traffic replay based IDS and IPS tests

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)
  • 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, 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 GitHub-CI checks 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 too 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.io/about/open-source/ and http://suricata.io/about/contribution-agreement/

Frequently asked questions

Is suricata free to use?

suricata is open source under the GPL-2.0 licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does suricata do?

Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine developed by the OISF and the Suricata comm

What is suricata written in?

suricata is primarily written in C. Its source is publicly available at https://github.com/OISF/suricata, and it has 6,646 GitHub stars.