docs: sample of sphinx docs
@ -0,0 +1,2 @@
|
||||
!Makefile
|
||||
_build
|
@ -0,0 +1,192 @@
|
||||
# Makefile for Sphinx documentation
|
||||
#
|
||||
|
||||
# You can set these variables from the command line.
|
||||
SPHINXOPTS =
|
||||
SPHINXBUILD = sphinx-build
|
||||
PAPER =
|
||||
BUILDDIR = _build
|
||||
|
||||
# User-friendly check for sphinx-build
|
||||
ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1)
|
||||
$(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://sphinx-doc.org/)
|
||||
endif
|
||||
|
||||
# Internal variables.
|
||||
PAPEROPT_a4 = -D latex_paper_size=a4
|
||||
PAPEROPT_letter = -D latex_paper_size=letter
|
||||
ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
|
||||
# the i18n builder cannot share the environment and doctrees with the others
|
||||
I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
|
||||
|
||||
.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest coverage gettext
|
||||
|
||||
help:
|
||||
@echo "Please use \`make <target>' where <target> is one of"
|
||||
@echo " html to make standalone HTML files"
|
||||
@echo " dirhtml to make HTML files named index.html in directories"
|
||||
@echo " singlehtml to make a single large HTML file"
|
||||
@echo " pickle to make pickle files"
|
||||
@echo " json to make JSON files"
|
||||
@echo " htmlhelp to make HTML files and a HTML help project"
|
||||
@echo " qthelp to make HTML files and a qthelp project"
|
||||
@echo " applehelp to make an Apple Help Book"
|
||||
@echo " devhelp to make HTML files and a Devhelp project"
|
||||
@echo " epub to make an epub"
|
||||
@echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
|
||||
@echo " latexpdf to make LaTeX files and run them through pdflatex"
|
||||
@echo " latexpdfja to make LaTeX files and run them through platex/dvipdfmx"
|
||||
@echo " text to make text files"
|
||||
@echo " man to make manual pages"
|
||||
@echo " texinfo to make Texinfo files"
|
||||
@echo " info to make Texinfo files and run them through makeinfo"
|
||||
@echo " gettext to make PO message catalogs"
|
||||
@echo " changes to make an overview of all changed/added/deprecated items"
|
||||
@echo " xml to make Docutils-native XML files"
|
||||
@echo " pseudoxml to make pseudoxml-XML files for display purposes"
|
||||
@echo " linkcheck to check all external links for integrity"
|
||||
@echo " doctest to run all doctests embedded in the documentation (if enabled)"
|
||||
@echo " coverage to run coverage check of the documentation (if enabled)"
|
||||
|
||||
clean:
|
||||
rm -rf $(BUILDDIR)/*
|
||||
|
||||
html:
|
||||
$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
|
||||
@echo
|
||||
@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
|
||||
|
||||
dirhtml:
|
||||
$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
|
||||
@echo
|
||||
@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
|
||||
|
||||
singlehtml:
|
||||
$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
|
||||
@echo
|
||||
@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
|
||||
|
||||
pickle:
|
||||
$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
|
||||
@echo
|
||||
@echo "Build finished; now you can process the pickle files."
|
||||
|
||||
json:
|
||||
$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
|
||||
@echo
|
||||
@echo "Build finished; now you can process the JSON files."
|
||||
|
||||
htmlhelp:
|
||||
$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
|
||||
@echo
|
||||
@echo "Build finished; now you can run HTML Help Workshop with the" \
|
||||
".hhp project file in $(BUILDDIR)/htmlhelp."
|
||||
|
||||
qthelp:
|
||||
$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
|
||||
@echo
|
||||
@echo "Build finished; now you can run "qcollectiongenerator" with the" \
|
||||
".qhcp project file in $(BUILDDIR)/qthelp, like this:"
|
||||
@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/Suricata.qhcp"
|
||||
@echo "To view the help file:"
|
||||
@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/Suricata.qhc"
|
||||
|
||||
applehelp:
|
||||
$(SPHINXBUILD) -b applehelp $(ALLSPHINXOPTS) $(BUILDDIR)/applehelp
|
||||
@echo
|
||||
@echo "Build finished. The help book is in $(BUILDDIR)/applehelp."
|
||||
@echo "N.B. You won't be able to view it unless you put it in" \
|
||||
"~/Library/Documentation/Help or install it in your application" \
|
||||
"bundle."
|
||||
|
||||
devhelp:
|
||||
$(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
|
||||
@echo
|
||||
@echo "Build finished."
|
||||
@echo "To view the help file:"
|
||||
@echo "# mkdir -p $$HOME/.local/share/devhelp/Suricata"
|
||||
@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/Suricata"
|
||||
@echo "# devhelp"
|
||||
|
||||
epub:
|
||||
$(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
|
||||
@echo
|
||||
@echo "Build finished. The epub file is in $(BUILDDIR)/epub."
|
||||
|
||||
latex:
|
||||
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
|
||||
@echo
|
||||
@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
|
||||
@echo "Run \`make' in that directory to run these through (pdf)latex" \
|
||||
"(use \`make latexpdf' here to do that automatically)."
|
||||
|
||||
latexpdf:
|
||||
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
|
||||
@echo "Running LaTeX files through pdflatex..."
|
||||
$(MAKE) -C $(BUILDDIR)/latex all-pdf
|
||||
@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
|
||||
|
||||
latexpdfja:
|
||||
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
|
||||
@echo "Running LaTeX files through platex and dvipdfmx..."
|
||||
$(MAKE) -C $(BUILDDIR)/latex all-pdf-ja
|
||||
@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
|
||||
|
||||
text:
|
||||
$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
|
||||
@echo
|
||||
@echo "Build finished. The text files are in $(BUILDDIR)/text."
|
||||
|
||||
man:
|
||||
$(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
|
||||
@echo
|
||||
@echo "Build finished. The manual pages are in $(BUILDDIR)/man."
|
||||
|
||||
texinfo:
|
||||
$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
|
||||
@echo
|
||||
@echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
|
||||
@echo "Run \`make' in that directory to run these through makeinfo" \
|
||||
"(use \`make info' here to do that automatically)."
|
||||
|
||||
info:
|
||||
$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
|
||||
@echo "Running Texinfo files through makeinfo..."
|
||||
make -C $(BUILDDIR)/texinfo info
|
||||
@echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
|
||||
|
||||
gettext:
|
||||
$(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
|
||||
@echo
|
||||
@echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
|
||||
|
||||
changes:
|
||||
$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
|
||||
@echo
|
||||
@echo "The overview file is in $(BUILDDIR)/changes."
|
||||
|
||||
linkcheck:
|
||||
$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
|
||||
@echo
|
||||
@echo "Link check complete; look for any errors in the above output " \
|
||||
"or in $(BUILDDIR)/linkcheck/output.txt."
|
||||
|
||||
doctest:
|
||||
$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
|
||||
@echo "Testing of doctests in the sources finished, look at the " \
|
||||
"results in $(BUILDDIR)/doctest/output.txt."
|
||||
|
||||
coverage:
|
||||
$(SPHINXBUILD) -b coverage $(ALLSPHINXOPTS) $(BUILDDIR)/coverage
|
||||
@echo "Testing of coverage in the sources finished, look at the " \
|
||||
"results in $(BUILDDIR)/coverage/python.txt."
|
||||
|
||||
xml:
|
||||
$(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml
|
||||
@echo
|
||||
@echo "Build finished. The XML files are in $(BUILDDIR)/xml."
|
||||
|
||||
pseudoxml:
|
||||
$(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml
|
||||
@echo
|
||||
@echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml."
|
@ -0,0 +1,285 @@
|
||||
# -*- coding: utf-8 -*-
|
||||
#
|
||||
# Suricata documentation build configuration file, created by
|
||||
# sphinx-quickstart on Fri Nov 6 10:12:25 2015.
|
||||
#
|
||||
# This file is execfile()d with the current directory set to its
|
||||
# containing dir.
|
||||
#
|
||||
# Note that not all possible configuration values are present in this
|
||||
# autogenerated file.
|
||||
#
|
||||
# All configuration values have a default; values that are commented out
|
||||
# serve to show the default.
|
||||
|
||||
import sys
|
||||
import os
|
||||
import shlex
|
||||
|
||||
# If extensions (or modules to document with autodoc) are in another directory,
|
||||
# add these directories to sys.path here. If the directory is relative to the
|
||||
# documentation root, use os.path.abspath to make it absolute, like shown here.
|
||||
#sys.path.insert(0, os.path.abspath('.'))
|
||||
|
||||
# -- General configuration ------------------------------------------------
|
||||
|
||||
# If your documentation needs a minimal Sphinx version, state it here.
|
||||
#needs_sphinx = '1.0'
|
||||
|
||||
# Add any Sphinx extension module names here, as strings. They can be
|
||||
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
|
||||
# ones.
|
||||
extensions = []
|
||||
|
||||
# Add any paths that contain templates here, relative to this directory.
|
||||
templates_path = ['_templates']
|
||||
|
||||
# The suffix(es) of source filenames.
|
||||
# You can specify multiple suffix as a list of string:
|
||||
# source_suffix = ['.rst', '.md']
|
||||
source_suffix = '.rst'
|
||||
|
||||
# The encoding of source files.
|
||||
#source_encoding = 'utf-8-sig'
|
||||
|
||||
# The master toctree document.
|
||||
master_doc = 'index'
|
||||
|
||||
# General information about the project.
|
||||
project = u'Suricata'
|
||||
copyright = u'2015, OISF'
|
||||
author = u'OISF'
|
||||
|
||||
# The version info for the project you're documenting, acts as replacement for
|
||||
# |version| and |release|, also used in various other places throughout the
|
||||
# built documents.
|
||||
#
|
||||
# The short X.Y version.
|
||||
version = '2.1dev'
|
||||
# The full version, including alpha/beta/rc tags.
|
||||
release = '3.0dev'
|
||||
|
||||
# The language for content autogenerated by Sphinx. Refer to documentation
|
||||
# for a list of supported languages.
|
||||
#
|
||||
# This is also used if you do content translation via gettext catalogs.
|
||||
# Usually you set "language" from the command line for these cases.
|
||||
language = None
|
||||
|
||||
# There are two options for replacing |today|: either, you set today to some
|
||||
# non-false value, then it is used:
|
||||
#today = ''
|
||||
# Else, today_fmt is used as the format for a strftime call.
|
||||
#today_fmt = '%B %d, %Y'
|
||||
|
||||
# List of patterns, relative to source directory, that match files and
|
||||
# directories to ignore when looking for source files.
|
||||
exclude_patterns = ['_build']
|
||||
|
||||
# The reST default role (used for this markup: `text`) to use for all
|
||||
# documents.
|
||||
#default_role = None
|
||||
|
||||
# If true, '()' will be appended to :func: etc. cross-reference text.
|
||||
#add_function_parentheses = True
|
||||
|
||||
# If true, the current module name will be prepended to all description
|
||||
# unit titles (such as .. function::).
|
||||
#add_module_names = True
|
||||
|
||||
# If true, sectionauthor and moduleauthor directives will be shown in the
|
||||
# output. They are ignored by default.
|
||||
#show_authors = False
|
||||
|
||||
# The name of the Pygments (syntax highlighting) style to use.
|
||||
pygments_style = 'sphinx'
|
||||
|
||||
# A list of ignored prefixes for module index sorting.
|
||||
#modindex_common_prefix = []
|
||||
|
||||
# If true, keep warnings as "system message" paragraphs in the built documents.
|
||||
#keep_warnings = False
|
||||
|
||||
# If true, `todo` and `todoList` produce output, else they produce nothing.
|
||||
todo_include_todos = False
|
||||
|
||||
|
||||
# -- Options for HTML output ----------------------------------------------
|
||||
|
||||
# The theme to use for HTML and HTML Help pages. See the documentation for
|
||||
# a list of builtin themes.
|
||||
#html_theme = 'alabaster'
|
||||
html_theme = 'sphinx_rtd_theme'
|
||||
|
||||
# Theme options are theme-specific and customize the look and feel of a theme
|
||||
# further. For a list of options available for each theme, see the
|
||||
# documentation.
|
||||
#html_theme_options = {}
|
||||
|
||||
# Add any paths that contain custom themes here, relative to this directory.
|
||||
#html_theme_path = []
|
||||
|
||||
# The name for this set of Sphinx documents. If None, it defaults to
|
||||
# "<project> v<release> documentation".
|
||||
#html_title = None
|
||||
|
||||
# A shorter title for the navigation bar. Default is the same as html_title.
|
||||
#html_short_title = None
|
||||
|
||||
# The name of an image file (relative to this directory) to place at the top
|
||||
# of the sidebar.
|
||||
#html_logo = None
|
||||
|
||||
# The name of an image file (within the static path) to use as favicon of the
|
||||
# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
|
||||
# pixels large.
|
||||
#html_favicon = None
|
||||
|
||||
# Add any paths that contain custom static files (such as style sheets) here,
|
||||
# relative to this directory. They are copied after the builtin static files,
|
||||
# so a file named "default.css" will overwrite the builtin "default.css".
|
||||
html_static_path = ['_static']
|
||||
|
||||
# Add any extra paths that contain custom files (such as robots.txt or
|
||||
# .htaccess) here, relative to this directory. These files are copied
|
||||
# directly to the root of the documentation.
|
||||
#html_extra_path = []
|
||||
|
||||
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
|
||||
# using the given strftime format.
|
||||
#html_last_updated_fmt = '%b %d, %Y'
|
||||
|
||||
# If true, SmartyPants will be used to convert quotes and dashes to
|
||||
# typographically correct entities.
|
||||
#html_use_smartypants = True
|
||||
|
||||
# Custom sidebar templates, maps document names to template names.
|
||||
#html_sidebars = {}
|
||||
|
||||
# Additional templates that should be rendered to pages, maps page names to
|
||||
# template names.
|
||||
#html_additional_pages = {}
|
||||
|
||||
# If false, no module index is generated.
|
||||
#html_domain_indices = True
|
||||
|
||||
# If false, no index is generated.
|
||||
#html_use_index = True
|
||||
|
||||
# If true, the index is split into individual pages for each letter.
|
||||
#html_split_index = False
|
||||
|
||||
# If true, links to the reST sources are added to the pages.
|
||||
#html_show_sourcelink = True
|
||||
|
||||
# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
|
||||
#html_show_sphinx = True
|
||||
|
||||
# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
|
||||
#html_show_copyright = True
|
||||
|
||||
# If true, an OpenSearch description file will be output, and all pages will
|
||||
# contain a <link> tag referring to it. The value of this option must be the
|
||||
# base URL from which the finished HTML is served.
|
||||
#html_use_opensearch = ''
|
||||
|
||||
# This is the file name suffix for HTML files (e.g. ".xhtml").
|
||||
#html_file_suffix = None
|
||||
|
||||
# Language to be used for generating the HTML full-text search index.
|
||||
# Sphinx supports the following languages:
|
||||
# 'da', 'de', 'en', 'es', 'fi', 'fr', 'hu', 'it', 'ja'
|
||||
# 'nl', 'no', 'pt', 'ro', 'ru', 'sv', 'tr'
|
||||
#html_search_language = 'en'
|
||||
|
||||
# A dictionary with options for the search language support, empty by default.
|
||||
# Now only 'ja' uses this config value
|
||||
#html_search_options = {'type': 'default'}
|
||||
|
||||
# The name of a javascript file (relative to the configuration directory) that
|
||||
# implements a search results scorer. If empty, the default will be used.
|
||||
#html_search_scorer = 'scorer.js'
|
||||
|
||||
# Output file base name for HTML help builder.
|
||||
htmlhelp_basename = 'Suricatadoc'
|
||||
|
||||
# -- Options for LaTeX output ---------------------------------------------
|
||||
|
||||
latex_elements = {
|
||||
# The paper size ('letterpaper' or 'a4paper').
|
||||
#'papersize': 'letterpaper',
|
||||
|
||||
# The font size ('10pt', '11pt' or '12pt').
|
||||
#'pointsize': '10pt',
|
||||
|
||||
# Additional stuff for the LaTeX preamble.
|
||||
#'preamble': '',
|
||||
|
||||
# Latex figure (float) alignment
|
||||
#'figure_align': 'htbp',
|
||||
}
|
||||
|
||||
# Grouping the document tree into LaTeX files. List of tuples
|
||||
# (source start file, target name, title,
|
||||
# author, documentclass [howto, manual, or own class]).
|
||||
latex_documents = [
|
||||
(master_doc, 'Suricata.tex', u'Suricata Documentation',
|
||||
u'OISF', 'manual'),
|
||||
]
|
||||
|
||||
# The name of an image file (relative to this directory) to place at the top of
|
||||
# the title page.
|
||||
#latex_logo = None
|
||||
|
||||
# For "manual" documents, if this is true, then toplevel headings are parts,
|
||||
# not chapters.
|
||||
#latex_use_parts = False
|
||||
|
||||
# If true, show page references after internal links.
|
||||
#latex_show_pagerefs = False
|
||||
|
||||
# If true, show URL addresses after external links.
|
||||
#latex_show_urls = False
|
||||
|
||||
# Documents to append as an appendix to all manuals.
|
||||
#latex_appendices = []
|
||||
|
||||
# If false, no module index is generated.
|
||||
#latex_domain_indices = True
|
||||
|
||||
|
||||
# -- Options for manual page output ---------------------------------------
|
||||
|
||||
# One entry per manual page. List of tuples
|
||||
# (source start file, name, description, authors, manual section).
|
||||
man_pages = [
|
||||
(master_doc, 'suricata', u'Suricata Documentation',
|
||||
[author], 1)
|
||||
]
|
||||
|
||||
# If true, show URL addresses after external links.
|
||||
#man_show_urls = False
|
||||
|
||||
|
||||
# -- Options for Texinfo output -------------------------------------------
|
||||
|
||||
# Grouping the document tree into Texinfo files. List of tuples
|
||||
# (source start file, target name, title, author,
|
||||
# dir menu entry, description, category)
|
||||
texinfo_documents = [
|
||||
(master_doc, 'Suricata', u'Suricata Documentation',
|
||||
author, 'Suricata', 'One line description of project.',
|
||||
'Miscellaneous'),
|
||||
]
|
||||
|
||||
# Documents to append as an appendix to all manuals.
|
||||
#texinfo_appendices = []
|
||||
|
||||
# If false, no module index is generated.
|
||||
#texinfo_domain_indices = True
|
||||
|
||||
# How to display URL addresses: 'footnote', 'no', or 'inline'.
|
||||
#texinfo_show_urls = 'footnote'
|
||||
|
||||
# If true, do not generate a @detailmenu in the "Top" node's menu.
|
||||
#texinfo_no_detailmenu = False
|
@ -0,0 +1,4 @@
|
||||
Fast Pattern
|
||||
============
|
||||
|
||||
Just a place holder now to demontrate linking.
|
@ -0,0 +1,363 @@
|
||||
:tocdepth: 2
|
||||
|
||||
HTTP Keywords
|
||||
=============
|
||||
|
||||
There are additional content modifiers that can provide
|
||||
protocol-specific capabilities at the application layer (if you are
|
||||
unfamiliar with content modifiers, please visit the page [[Payload
|
||||
keywords]]). These keywords make sure the signature checks only
|
||||
specific parts of the network traffic. For instance, to check
|
||||
specifically on the request URI, cookies, or the HTTP request or
|
||||
response body, etc.
|
||||
|
||||
|
||||
Use ``http_method`` to match on the HTTP request method, ``http_uri``
|
||||
or ``http_raw_uri`` to match on the request URI, ``http_stat_code`` to
|
||||
match on the response status code and ``http_stat_msg`` to match on the
|
||||
response status message.
|
||||
|
||||
It is important to understand the structure of HTTP requests and
|
||||
responses. A simple example of a HTTP request and response follows:
|
||||
|
||||
HTTP request
|
||||
------------
|
||||
|
||||
::
|
||||
|
||||
GET /index.html HTTP/1.0\r\n
|
||||
|
||||
GET is a request **method**. Examples of methods are: GET, POST, PUT,
|
||||
HEAD, etc. The URI path is ``/index.html`` and the HTTP version is
|
||||
``HTTP/1.0``. Several HTTP versions have been used over the years; of
|
||||
the versions 0.9, 1.0 and 1.1, 1.0 and 1.1 are the most commonly used
|
||||
today.
|
||||
|
||||
HTTP response
|
||||
-------------
|
||||
|
||||
::
|
||||
|
||||
HTTP/1.0 200 OK\r\n
|
||||
<html>
|
||||
<title> some page </title>
|
||||
</HTML>
|
||||
|
||||
In this example, HTTP/1.0 is the HTTP version, 200 the response status
|
||||
code and OK the response status message.
|
||||
|
||||
Another more detailed example:
|
||||
|
||||
Request:
|
||||
|
||||
.. image:: http-keywords/request.png
|
||||
|
||||
Response:
|
||||
|
||||
.. image:: http-keywords/response1.png
|
||||
|
||||
Request:
|
||||
|
||||
.. image:: http-keywords/request2.png
|
||||
|
||||
Although cookies are sent in an HTTP header, you can not match on them
|
||||
with the ``http_header`` keyword. Cookies are matched with their own
|
||||
keyword, namely ``http_cookie``.
|
||||
|
||||
Each part of the table belongs to a so-called *buffer*. The HTTP
|
||||
method belongs to the method buffer, HTTP headers to the header buffer
|
||||
etc. A buffer is a specific portion of the request or response that
|
||||
Suricata extracts in memory for inspection.
|
||||
|
||||
All previous described keywords can be used in combination with a
|
||||
buffer in a signature. The keywords ``distance`` and ``within`` are
|
||||
relative modifiers, so they may only be used within the same
|
||||
buffer. You can not relate content matches against different buffers
|
||||
with relative modifiers.
|
||||
|
||||
http_method
|
||||
-----------
|
||||
|
||||
With the ``http_method`` content modifier, it is possible to match
|
||||
specifically and only on the HTTP method buffer. The keyword can be
|
||||
used in combination with all previously mentioned content modifiers
|
||||
such as: ``depth``, ``distance``, ``offset``, ``nocase`` and ``within``.
|
||||
|
||||
Methods are: **GET**, **POST**, **PUT**, **HEAD**, **DELETE**, **TRACE**,
|
||||
**OPTIONS**, **CONNECT** and **PATCH**.
|
||||
|
||||
Example of a method in a HTTP request:
|
||||
|
||||
.. image:: http-keywords/method2.png
|
||||
|
||||
Example of the purpose of method:
|
||||
|
||||
.. image:: http-keywords/method.png
|
||||
|
||||
.. image:: http-keywords/Legenda_rules.png
|
||||
|
||||
.. image:: http-keywords/method1.png
|
||||
|
||||
|
||||
http_uri and http_raw_uri
|
||||
-------------------------
|
||||
|
||||
With the ``http_uri`` and the ``http_raw_uri`` content modifiers, it
|
||||
is possible to match specifically and only on the request URI
|
||||
buffer. The keyword can be used in combination with all previously
|
||||
mentioned content modifiers like ``depth``, ``distance``, ``offset``,
|
||||
``nocase`` and ``within``.
|
||||
|
||||
To learn more about the difference between ``http_uri`` and
|
||||
``http_raw_uri``, please read the information about [[HTTP-uri
|
||||
normalization]].
|
||||
|
||||
Example of the URI in a HTTP request:
|
||||
|
||||
.. image:: http-keywords/uri1.png
|
||||
|
||||
Example of the purpose of ``http_uri``:
|
||||
|
||||
.. image:: http-keywords/uri.png
|
||||
|
||||
Example of the purpose of ``http_raw_uri``:
|
||||
|
||||
#.. image:: http-keywords/raw_uri.png
|
||||
|
||||
uricontent
|
||||
----------
|
||||
|
||||
The ``uricontent`` keyword has the exact same effect as the
|
||||
``http_uri`` content modifier. ``uricontent`` is a deprecated
|
||||
(although still supported) way to match specifically and only on the
|
||||
request URI buffer.
|
||||
|
||||
Example of ``uricontent``:
|
||||
|
||||
.. image:: http-keywords/uricontent.png
|
||||
|
||||
The difference between ``http_uri`` and ``uricontent`` is the syntax:
|
||||
|
||||
.. image:: http-keywords/uricontent1.png
|
||||
|
||||
.. image:: http-keywords/http_uri.png
|
||||
|
||||
When authoring new rules, it is recommended that the ``http_uri``
|
||||
content modifier be used rather than the deprecated ``uricontent``
|
||||
keyword.
|
||||
|
||||
http_header and http_raw_header
|
||||
-------------------------------
|
||||
|
||||
With the ``http_header`` content modifier, it is possible to match
|
||||
specifically and only on the HTTP header buffer. This contains all of
|
||||
the extracted headers in a single buffer, except for those indicated
|
||||
in the documentation that are not able to match by this buffer and
|
||||
have their own content modifier (e.g. ``http_cookie``). The modifier
|
||||
can be used in combination with all previously mentioned content
|
||||
modifiers, like ``depth``, ``distance``, ``offset``, ``nocase`` and
|
||||
``within``.
|
||||
|
||||
**Note**: the header buffer is *normalized*. Any trailing
|
||||
whitespace and tab characters are removed. See:
|
||||
http://lists.openinfosecfoundation.org/pipermail/oisf-users/2011-October/000935.html. Match
|
||||
on the ``http_raw_header`` buffer if you require the raw
|
||||
(non-normalized) headers.
|
||||
|
||||
Example of a header in a HTTP request:
|
||||
|
||||
.. image:: http-keywords/header.png
|
||||
|
||||
Example of the purpose of ``http_header``:
|
||||
|
||||
.. image:: http-keywords/header1.png
|
||||
|
||||
http_cookie
|
||||
-----------
|
||||
|
||||
With the ``http_cookie`` content modifier, it is possible to match
|
||||
specifically and only on the cookie buffer. The keyword can be used in
|
||||
combination with all previously mentioned content modifiers like
|
||||
``depth``, ``distance``, ``offset``, ``nocase`` and ``within``.
|
||||
|
||||
Note that cookies are passed in HTTP headers, but are extracted to a
|
||||
dedicated buffer and matched using their own specific content
|
||||
modifier.
|
||||
|
||||
Example of a cookie in a HTTP request:
|
||||
|
||||
.. image:: http-keywords/cookie.png
|
||||
|
||||
Example of the purpose of ``http_cookie``:
|
||||
|
||||
.. image:: http-keywords/cookie1.png
|
||||
|
||||
http_user_agent
|
||||
---------------
|
||||
|
||||
The ``http_user_agent`` content modifier is part of the HTTP request
|
||||
header. It makes it possible to match specifically on the value of the
|
||||
User-Agent header. It is normalized in the sense that it does not
|
||||
include the _"User-Agent: "_ header name and separator, nor does it
|
||||
contain the trailing carriage return and line feed (CRLF). The keyword
|
||||
can be used in combination with all previously mentioned content
|
||||
modifiers like ``depth``, ``distance``, ``offset``, ``nocase`` and
|
||||
``within``. Note that the ``pcre`` keyword can also inspect this
|
||||
buffer when using the ``/V`` modifier.
|
||||
|
||||
An analysis into the performance of ``http_user_agent``
|
||||
vs. ``http_header`` is found at:
|
||||
http://blog.inliniac.net/2012/07/09/suricata-http_user_agent-vs-http_header/
|
||||
|
||||
Normalization: leading spaces **are not** part of this buffer. So
|
||||
"User-Agent: \r\n" will result in an empty ``http_user_agent`` buffer.
|
||||
|
||||
Example of the User-Agent header in a HTTP request:
|
||||
|
||||
.. image:: http-keywords/user_agent.png
|
||||
|
||||
Example of the purpose of ``http_user_agent``:
|
||||
|
||||
.. image:: http-keywords/user_agent_match.png
|
||||
|
||||
http_client_body
|
||||
----------------
|
||||
|
||||
With the ``http_client_body`` content modifier, it is possible to
|
||||
match specifically and only on the HTTP request body. The keyword can
|
||||
be used in combination with all previously mentioned content modifiers
|
||||
like ``distance``, ``offset``, ``nocase``, ``within``, etc.
|
||||
|
||||
Example of ``http_client_body`` in a HTTP request:
|
||||
|
||||
.. image:: http-keywords/client_body.png
|
||||
|
||||
Example of the purpose of ``http_client_body``:
|
||||
|
||||
.. image:: http-keywords/client_body1.png
|
||||
|
||||
Note: how much of the request/client body is inspected is controlled
|
||||
in the [[suricata.yaml#Configure-Libhtp]], in the "libhtp" section,
|
||||
via the ``request-body-limit`` setting.
|
||||
|
||||
http_stat_code
|
||||
--------------
|
||||
|
||||
With the ``http_stat_code`` content modifier, it is possible to match
|
||||
specifically and only on the HTTP status code buffer. The keyword can
|
||||
be used in combination with all previously mentioned content modifiers
|
||||
like ``distance``, ``offset``, ``nocase``, ``within``, etc.
|
||||
|
||||
Example of ``http_stat_code`` in a HTTP response:
|
||||
|
||||
.. image:: http-keywords/stat_code.png
|
||||
|
||||
Example of the purpose of ``http_stat_code``:
|
||||
|
||||
.. image:: http-keywords/stat-code1.png
|
||||
|
||||
http_stat_msg
|
||||
-------------
|
||||
|
||||
With the ``http_stat_msg`` content modifier, it is possible to match
|
||||
specifically and only on the HTTP status message buffer. The keyword
|
||||
can be used in combination with all previously mentioned content
|
||||
modifiers like ``depth``, ``distance``, ``offset``, ``nocase`` and
|
||||
``within``.
|
||||
|
||||
Example of ``http_stat_msg`` in a HTTP response:
|
||||
|
||||
.. image:: http-keywords/stat_msg.png
|
||||
|
||||
Example of the purpose of ``http_stat_msg``:
|
||||
|
||||
.. image:: http-keywords/stat_msg_1.png
|
||||
|
||||
http_server_body
|
||||
----------------
|
||||
|
||||
With the ``http_server_body`` content modifier, it is possible to
|
||||
match specifically and only on the HTTP response body. The keyword can
|
||||
be used in combination with all previously mentioned content modifiers
|
||||
like ``distance``, ``offset``, ``nocase``, ``within``, etc. If the
|
||||
response body is *gzip* encoded, it is first uncompressed for
|
||||
inspection.
|
||||
|
||||
Note: how much of the response/server body is inspected is controlled
|
||||
in your [[suricata.yaml#Configure-Libhtp]], in the "libhtp" section,
|
||||
via the ``response-body-limit`` setting.
|
||||
|
||||
file_data
|
||||
---------
|
||||
|
||||
With ``file_data``, the HTTP response body is inspected, just like
|
||||
with ``http_server_body``. The ``file_data`` keyword works a bit
|
||||
differently from the normal content modifiers; when used in a rule,
|
||||
all content matches following it in the rule are affected (modified)
|
||||
by it.
|
||||
|
||||
Example::
|
||||
|
||||
alert http any any -> any any (file_data; content:"abc"; content:"xyz";)
|
||||
|
||||
.. image:: http-keywords/file_data.png
|
||||
|
||||
The ``file_data`` keyword affects all following content matches, until
|
||||
the ``pkt_data`` keyword is encountered or it reaches the end of the
|
||||
rule. This makes it a useful shortcut for applying many content
|
||||
matches to the HTTP response body, eliminating the need to modify each
|
||||
content match individually. If the response body is *gzip* encoded, it
|
||||
is first uncompressed for inspection.
|
||||
|
||||
Note: how much of the response/server body is inspected is controlled
|
||||
in your [[suricata.yaml#Configure-Libhtp]], in the "libhtp" section
|
||||
via the ``response-body-limit`` setting.
|
||||
|
||||
**NOTE:** In 2.0.x, ``file_data`` is only supported for HTTP server
|
||||
bodies (specified as flow direction **to_client**). Starting with
|
||||
2.1-dev and above, ``file_data`` is handled more intelligently
|
||||
per-protocol, supported with **to_server** for SMTP and **to_client**
|
||||
for HTTP.
|
||||
|
||||
urilen
|
||||
------
|
||||
|
||||
The ``urilen`` keyword is used to match on the length of the request
|
||||
URI. It is possible to use the ``<`` and ``>`` operators, which
|
||||
indicate respectively *smaller than* and *larger than*.
|
||||
|
||||
The format of ``urilen`` is::
|
||||
|
||||
urilen:3;
|
||||
|
||||
Other possibilities are::
|
||||
|
||||
urilen:1;
|
||||
urilen:>1;
|
||||
urilen:<10;
|
||||
urilen:10<>20; (bigger than 10, smaller than 20)
|
||||
|
||||
Example:
|
||||
|
||||
.. image:: http-keywords/urilen.png
|
||||
|
||||
Example of ``urilen`` in a signature:
|
||||
|
||||
.. image:: http-keywords/urilen1.png
|
||||
|
||||
You can specify whether the inspected URI buffer is either the
|
||||
normalized or the raw buffer by appending ``norm`` or ``raw``::
|
||||
|
||||
urilen:<5,raw;
|
||||
|
||||
pcre
|
||||
----
|
||||
|
||||
For information about the ``pcre`` keyword, check the [[pcre (Perl
|
||||
Compatible Regular Expressions)]] page.
|
||||
|
||||
fast_pattern
|
||||
------------
|
||||
|
||||
For information about the ``fast_pattern`` keyword, check the
|
||||
:doc:`fast-pattern` page.
|
After Width: | Height: | Size: 13 KiB |
After Width: | Height: | Size: 18 KiB |
After Width: | Height: | Size: 38 KiB |
After Width: | Height: | Size: 40 KiB |
After Width: | Height: | Size: 47 KiB |
After Width: | Height: | Size: 12 KiB |
After Width: | Height: | Size: 12 KiB |
After Width: | Height: | Size: 16 KiB |
After Width: | Height: | Size: 37 KiB |
After Width: | Height: | Size: 9.0 KiB |
After Width: | Height: | Size: 54 KiB |
After Width: | Height: | Size: 15 KiB |
After Width: | Height: | Size: 24 KiB |
After Width: | Height: | Size: 18 KiB |
After Width: | Height: | Size: 69 KiB |
After Width: | Height: | Size: 48 KiB |
After Width: | Height: | Size: 78 KiB |
After Width: | Height: | Size: 25 KiB |
After Width: | Height: | Size: 2.2 KiB |
After Width: | Height: | Size: 2.0 KiB |
After Width: | Height: | Size: 24 KiB |
After Width: | Height: | Size: 23 KiB |
After Width: | Height: | Size: 4.9 KiB |
After Width: | Height: | Size: 52 KiB |
After Width: | Height: | Size: 6.1 KiB |
After Width: | Height: | Size: 26 KiB |
After Width: | Height: | Size: 48 KiB |
After Width: | Height: | Size: 29 KiB |
After Width: | Height: | Size: 264 KiB |
@ -0,0 +1,20 @@
|
||||
.. Suricata documentation master file, created by
|
||||
sphinx-quickstart on Fri Nov 6 10:12:25 2015.
|
||||
You can adapt this file completely to your liking, but it should at least
|
||||
contain the root `toctree` directive.
|
||||
|
||||
Suricata User Guide
|
||||
===================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
|
||||
what-is-suricata
|
||||
rules
|
||||
|
||||
Indices and tables
|
||||
==================
|
||||
|
||||
* :ref:`genindex`
|
||||
* :ref:`modindex`
|
||||
* :ref:`search`
|
@ -0,0 +1,168 @@
|
||||
Meta-settings
|
||||
=============
|
||||
|
||||
Meta-settings have no effect on Suricata's inspection; they have an
|
||||
effect on the way Suricata reports events.
|
||||
|
||||
msg (message)
|
||||
-------------
|
||||
|
||||
The keyword msg gives more information about the signature and the
|
||||
possible alert. The first part shows the filename of the
|
||||
signature. It is a convention that part is written in uppercase
|
||||
characters.
|
||||
|
||||
The format of msg is::
|
||||
|
||||
msg: “...”;
|
||||
|
||||
Example::
|
||||
|
||||
msg:"ATTACK-RESPONSES 403 Forbidden";
|
||||
msg:"ET EXPLOIT SMB-DS DCERPC PnP bind attempt";
|
||||
|
||||
*It is a convention that msg is always the first keyword of a signature.*
|
||||
|
||||
Another example of msg in a signature:
|
||||
|
||||
alert tcp $HOME_NET any -> $EXTERNAL_NET any (**msg:"ET TROJAN Likely Bot Nick in IRC (USA +..)";** flow:established,to_server; content:"NICK "; depth:5; content:"USA"; within:10; reference:url,doc.emergingthreats.net/2008124; classtype:trojan-activity; sid:2008124; rev:5;)
|
||||
|
||||
In this example the red, bold-faced part is the msg.
|
||||
|
||||
Sid (signature id)
|
||||
------------------
|
||||
|
||||
The keyword sid gives every signature its own id. This id is stated
|
||||
with a number.
|
||||
|
||||
The format of sid is::
|
||||
|
||||
sid:123;
|
||||
|
||||
Example of sid in a signature:
|
||||
|
||||
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET TROJAN Likely Bot Nick in IRC (USA +..)"; flow:established,to_server; content:"NICK "; depth:5; content:"USA"; within:10; reference:url,doc.emergingthreats.net/2008124; classtype:trojan-activity; **sid:2008124;** rev:5;)
|
||||
|
||||
Rev (Revision)
|
||||
--------------
|
||||
|
||||
The sid keyword is almost every time accompanied by rev. Rev
|
||||
represents the version of the signature. If a signature is modified,
|
||||
the number of rev will be incremented by the signature writers.
|
||||
|
||||
The format of rev is::
|
||||
|
||||
rev:123;
|
||||
|
||||
*It is a convention that sid comes before rev, and both are the last of
|
||||
all keywords.*
|
||||
|
||||
Example of rev in a signature:
|
||||
|
||||
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET TROJAN Likely Bot Nick in IRC (USA +..)"; flow:established,to_server; content:"NICK "; depth:5; content:"USA"; within:10; reference:url,doc.emergingthreats.net/2008124; classtype:trojan-activity; sid:2008124; **rev:5;**)
|
||||
|
||||
Gid (group id)
|
||||
--------------
|
||||
|
||||
The gid keyword can be used to give different groups of signatures
|
||||
another id value (like in sid). Suricata uses by default gid 1. It is
|
||||
possible to modify this. It is not usual that it will be changed, and
|
||||
changing it has no technical implications. You can only notice it in
|
||||
the alert.
|
||||
|
||||
10/01/2014-05:14:43.926704 [**] [**1**:2016903:5] ET USER_AGENTS Suspicious User-Agent (DownloadMR) [**] [Classification: A Network Trojan was detected] [Priority: 1] {TCP} 192.168.81.10:1032 -> 95.211.39.161:80
|
||||
|
||||
This is an example from the fast.log. In the part [1:2008124:2], 1 is
|
||||
the gid (2008124 is the the sid and 2 the rev).
|
||||
|
||||
Classtype
|
||||
---------
|
||||
|
||||
The classtype keyword gives information about the classification of
|
||||
rules and alerts. It consists of a short name, a long name and a
|
||||
priority. It can tell for example whether a rule is just informational
|
||||
or is about a hack etcetera. For each classtype, the
|
||||
classification.config has a priority which will be used in the rule.
|
||||
|
||||
*It is a convention that classtype comes before sid and rev and after
|
||||
the rest of the keywords.*
|
||||
|
||||
Example classtype::
|
||||
|
||||
config classification: web-application-attack,Web Application Attack,1
|
||||
config classification: not-suspicious,Not Suspicious Traffic,3
|
||||
|
||||
============== =================================== ======================
|
||||
Signature classification.config Alert
|
||||
============== =================================== ======================
|
||||
web-attack web-attack, Web Application Attack, Web Application Attack
|
||||
priority:1
|
||||
not-suspicious not-suspicious, Not Suspiscious Not Suspicious Traffic
|
||||
Traffic, priority:3
|
||||
============== =================================== ======================
|
||||
|
||||
In the above table you see how classtype appears in signatures, the
|
||||
classification.config and the alert.
|
||||
|
||||
Another example of classtype in a signature:
|
||||
|
||||
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET TROJAN Likely Bot Nick in IRC (USA +..)" flow:established,to_server; content:"NICK "; depth:5; content:"USA"; within:10; reference:url,doc.emergingthreats.net/2008124; **classtype:trojan-activity;** sid:2008124; rev:5;)
|
||||
|
||||
Reference
|
||||
---------
|
||||
|
||||
The reference keywords direct to places where information about the
|
||||
signature and about the problem the signature tries to address, can be
|
||||
found. The reference keyword can appear multiple times in a signature.
|
||||
This keyword is meant for signature-writers and analysts who
|
||||
investigate why a signature has matched. It has the following format::
|
||||
|
||||
reference: url, www.info.nl
|
||||
|
||||
In this example url is the type of reference. After that comes the
|
||||
actual reference (notice here you can not use http before the url).
|
||||
|
||||
There are different types of references:
|
||||
|
||||
========= ===============================================
|
||||
system URL Prefix
|
||||
========= ===============================================
|
||||
bugtraq ``http://www.securityfocus.com/bid``
|
||||
cve ``http://cve.mitre.org/cgi-bin/cvename.cgi?name=``
|
||||
nessus ``http://cgi.nessus.org/plugins/dump.php3?id=``
|
||||
arachnids ``http://www.whitehats.com/info/IDS``
|
||||
mcafee ``http://vil.nai.com/vil/dispVirus.asp?virus_k=``
|
||||
url ``http://``
|
||||
========= ===============================================
|
||||
|
||||
*Note that ararchnids is no longer available but may still be
|
||||
encountered in signatures.*
|
||||
|
||||
For example bugtraq will be replaced by the full url::
|
||||
|
||||
reference: bugtraq, 123; http://www.securityfocus.com/bid
|
||||
|
||||
Example of reference in a signature:
|
||||
|
||||
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET TROJAN Likely Bot Nick in IRC (USA +..)" flow:established,to_server; content:"NICK "; depth:5; content:"USA"; within:10; **reference:url,doc.emergingthreats.net/2008124;** classtype:trojan-activity; sid:2008124; rev:5;)
|
||||
|
||||
Priority
|
||||
--------
|
||||
|
||||
The priority keyword comes with a mandatory numeric value which can
|
||||
range from 1 till 255. The numbers 1 to 4 are most often used.
|
||||
Signatures with a higher priority will be examined first. The highest
|
||||
priority is 1. Normally signatures have already a priority through
|
||||
class type. This can be overruled with the keyword priority. The
|
||||
format of priority is::
|
||||
|
||||
priority:1;
|
||||
|
||||
Metadata
|
||||
--------
|
||||
|
||||
Suricata ignores the words behind meta data.
|
||||
Suricata supports this keyword because it is part of the signature language.
|
||||
The format is::
|
||||
|
||||
metadata:...;
|
@ -0,0 +1,7 @@
|
||||
Payload Keywords
|
||||
================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
fast-pattern
|
@ -0,0 +1,10 @@
|
||||
Rules
|
||||
=====
|
||||
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
meta
|
||||
http-keywords
|
||||
payload-keywords
|
@ -0,0 +1,68 @@
|
||||
What is Suricata
|
||||
================
|
||||
|
||||
The Suricata Engine is an Open Source Next Generation Intrusion
|
||||
Detection and Prevention Engine. This engine is not intended to just
|
||||
replace or emulate the existing tools in the industry, but will bring
|
||||
new ideas and technologies to the field. The Suricata Engine and the
|
||||
HTP Library are available to use under the GPLv2.
|
||||
|
||||
|
||||
IDS/IPS
|
||||
-------
|
||||
|
||||
Suricata is a rule-based ID/PS engine that utilises externally
|
||||
developed rule sets to monitor network traffic and provide alerts to
|
||||
the system administrator when suspicious events occur. Designed to be
|
||||
compatible with existing network security components, Suricata
|
||||
features unified output functionality and pluggable library options to
|
||||
accept calls from other applications. The initial release of Suricata
|
||||
runs on a Linux 2.6 platform that supports inline and passive traffic
|
||||
monitoring configuration capable of handling multiple gigabit traffic
|
||||
levels. Linux 2.4 is supported with reduced configuration
|
||||
functionality, such as no inline option. Available under Version 2 of
|
||||
the General Public License, Suricata eliminates the ID/PS engine cost
|
||||
concerns while providing a scalable option for the most complex
|
||||
network security architectures.
|
||||
|
||||
|
||||
Multi-threading
|
||||
---------------
|
||||
|
||||
As a multi-threaded engine, Suricata offers increased speed and
|
||||
efficiency in network traffic analysis. In addition to hardware
|
||||
acceleration (with hardware and network card limitations), the engine
|
||||
is build to utilise the increased processing power offered by the
|
||||
latest multi-core CPU chip sets. Suricata is developed for ease of
|
||||
implementation and accompanied by a step-by-step getting started
|
||||
documentation and user manual.
|
||||
|
||||
Development and features
|
||||
------------------------
|
||||
|
||||
The goal of the Suricata Project Phase 1 was to have a distributable
|
||||
and functional ID/PS engine. The initial beta release was made
|
||||
available for download on January 1, 2010. The engine supports or
|
||||
provides the following functionality: the latest Snort VRT, Snort
|
||||
logging, rule language options, multi-threading, hardware acceleration
|
||||
(with hardware and network card dependencies/limitations), unified
|
||||
output enabling interaction with external log management systems,
|
||||
IPv6, rule-based IP reputation, library plug-ability for interaction
|
||||
with other applications, performance statistics output, and a simple
|
||||
and effective getting started user manual.
|
||||
|
||||
By engaging the open source community and the leading ID/PS rule set
|
||||
resources available, OISF has built the Suricata engine to simplify
|
||||
the process of maintaining optimum security levels. Through strategic
|
||||
partnerships, OISF is leveraging the expertise of Emerging Threats
|
||||
(www.emergingthreats.net) and other prominent resources in the
|
||||
industry to provide the most current and comprehensive rule sets
|
||||
available.
|
||||
|
||||
The HTP Library is an HTTP normaliser and parser written by Ivan
|
||||
Ristic of Mod Security fame for the OISF. This integrates and provides
|
||||
very advanced processing of HTTP streams for Suricata. The HTP library
|
||||
is required by the engine, but may also be used independently in a
|
||||
range of applications and tools.
|
||||
|
||||
[[Major Features|Next]]
|