Convert Figma logo to code with AI

OISF logosuricata

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

4,438
1,422
4,438
74

Top Related Projects

6,328

Zeek is a powerful network analysis framework that is much different from the typical IDS you may know.

3,759

Open Source Deep Packet Inspection Software Toolkit

Security Onion is a free and open platform for threat hunting, enterprise security monitoring, and log management. It includes our own interfaces for alerting, dashboards, hunting, PCAP, detections, and case management. It also includes other tools such as osquery, CyberChef, Elasticsearch, Logstash, Kibana, Suricata, and Zeek.

Quick Overview

Suricata is a high-performance Network IDS, IPS, and Network Security Monitoring engine. It is open-source and owned by the Open Information Security Foundation (OISF). Suricata provides real-time intrusion detection, inline intrusion prevention, and network security monitoring.

Pros

  • High performance and multi-threaded architecture
  • Supports both live traffic analysis and pcap file processing
  • Extensive rule language and compatibility with Snort rules
  • Active community and regular updates

Cons

  • Can be resource-intensive, especially with complex rule sets
  • Initial setup and configuration can be complex for beginners
  • False positives may occur, requiring fine-tuning of rules
  • Limited built-in reporting capabilities compared to some commercial solutions

Getting Started

To get started with Suricata:

  1. Install Suricata:

    sudo apt-get install suricata
    
  2. Update the rule set:

    sudo suricata-update
    
  3. Edit the configuration file:

    sudo nano /etc/suricata/suricata.yaml
    
  4. Start Suricata:

    sudo systemctl start suricata
    
  5. Check the status:

    sudo systemctl status suricata
    

For more detailed setup and usage instructions, refer to the official Suricata documentation.

Competitor Comparisons

6,328

Zeek is a powerful network analysis framework that is much different from the typical IDS you may know.

Pros of Zeek

  • More flexible and powerful scripting language for custom analysis
  • Better suited for in-depth network traffic analysis and behavioral detection
  • Provides rich, structured logs for easier data analysis and integration

Cons of Zeek

  • Steeper learning curve due to its unique scripting language
  • Generally requires more system resources than Suricata
  • Less focus on traditional signature-based detection

Code Comparison

Zeek script example:

event http_request(c: connection, method: string, original_uri: string,
                   unescaped_uri: string, version: string)
    {
    print fmt("HTTP request: %s %s", method, original_uri);
    }

Suricata rule example:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"HTTP request detected";
    flow:established,to_server; http.method; content:"GET"; 
    classtype:web-application-activity; sid:1000001; rev:1;)

Both examples demonstrate basic HTTP request detection, but Zeek's script offers more flexibility for custom analysis, while Suricata's rule focuses on signature-based detection.

3,759

Open Source Deep Packet Inspection Software Toolkit

Pros of nDPI

  • Lightweight and efficient, focusing solely on protocol detection
  • Easier to integrate into existing network monitoring tools
  • Supports a wide range of protocols, including encrypted ones

Cons of nDPI

  • Limited intrusion detection capabilities compared to Suricata
  • Less comprehensive security features and rule sets
  • Smaller community and fewer third-party integrations

Code Comparison

nDPI example (protocol detection):

struct ndpi_detection_module_struct *ndpi_struct;
ndpi_struct = ndpi_init_detection_module();
ndpi_set_protocol_detection_bitmask2(ndpi_struct, &all);

Suricata example (rule parsing):

SCClassConfInit();
SCClassConfLoadClassficationConfigFile(de_ctx, file);
SCClassConfAddClasstype(de_ctx, "trojan-activity", "Trojan Activity", 1, 1);

Both projects are open-source network analysis tools, but they serve different purposes. nDPI focuses on protocol identification, while Suricata is a full-featured intrusion detection system. nDPI is more suitable for integration into other tools, whereas Suricata provides a comprehensive security solution out of the box.

Security Onion is a free and open platform for threat hunting, enterprise security monitoring, and log management. It includes our own interfaces for alerting, dashboards, hunting, PCAP, detections, and case management. It also includes other tools such as osquery, CyberChef, Elasticsearch, Logstash, Kibana, Suricata, and Zeek.

Pros of Security Onion

  • Comprehensive security suite with multiple integrated tools
  • User-friendly interface for network security monitoring
  • Includes pre-configured dashboards and visualizations

Cons of Security Onion

  • Larger resource footprint due to multiple components
  • Steeper learning curve for new users
  • Less flexibility for custom deployments compared to standalone Suricata

Code Comparison

Suricata configuration example:

vars:
  address-groups:
    HOME_NET: "[192.168.0.0/16,10.0.0.0/8,172.16.0.0/12]"
    EXTERNAL_NET: "!$HOME_NET"

Security Onion configuration example:

INTERFACE=ens33
NSMSETUP=BASIC
USEPF=YES
ZEEKVERSION=ZEEK

While Suricata focuses on network intrusion detection rules, Security Onion's configuration involves setting up the entire monitoring environment, including network interfaces and component selection.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

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/