]> git.ipfire.org Git - thirdparty/suricata.git/commitdiff
doc: Move IP reputation keyword to rules section
authorRalph Broenink <ralph@ralphbroenink.net>
Sat, 14 Oct 2017 10:29:05 +0000 (12:29 +0200)
committerVictor Julien <victor@inliniac.net>
Fri, 8 Dec 2017 10:32:09 +0000 (11:32 +0100)
doc/userguide/reputation/ipreputation/ip-reputation-format.rst
doc/userguide/reputation/ipreputation/ip-reputation.rst
doc/userguide/rules/differences-from-snort.rst
doc/userguide/rules/index.rst
doc/userguide/rules/ip-reputation-rules.rst [moved from doc/userguide/reputation/ipreputation/ip-reputation-rules.rst with 75% similarity]

index b6bf186a22a87dd4cee39adc2229f59d6b5aed70..af2249cdfbfbd5300130ff00ea7bb95e1ea46204 100644 (file)
@@ -1,7 +1,7 @@
 IP Reputation Format
 ====================
 
-Description of IP Reputation file formats. For the configuration see :doc:`ip-reputation-config` and :doc:`ip-reputation-rules` for the rule format.
+Description of IP Reputation file formats. For the configuration see :doc:`ip-reputation-config` and :doc:`/rules/ip-reputation-rules` for the rule format.
 
 Categories file
 ~~~~~~~~~~~~~~~
index edfc69a65a6934e15d72e52abbbd6c278aa68677..6798fd17115253c0e8e5891972aae3f087071565 100644 (file)
@@ -4,7 +4,6 @@ IP Reputation
 .. toctree::
 
    ip-reputation-config
-   ip-reputation-rules
    ip-reputation-format
 
 The purpose of the IP reputation component is the ranking of IP Addresses within the Suricata Engine.  It will collect, store, update and distribute reputation intelligence on IP Addresses.  The hub and spoke architecture will allows the central database (The Hub) to collect, store and compile updated IP reputation details that are then distributed to user-side sensor databases (Spokes) for inclusion in user security systems.  The reputation data update frequency and security action taken, is defined in the user security configuration.
@@ -12,4 +11,4 @@ The purpose of the IP reputation component is the ranking of IP Addresses within
 The intent of IP Reputation is to allow sharing of intelligence regarding a vast number of IP addresses. This can be positive or negative intelligence classified into a number of categories. The technical implementation requires three major efforts; engine integration, the hub that redistributes reputation, and the communication protocol between hubs and sensors.  The hub will have a number of responsibilities. This will be a separate module running on a separate system as any sensor. Most often it would run on a central database that all sensors already have communication with. It will be able to subscribe to one or more external feeds.   The local admin should be able to define the feeds to be subscribed to, provide authentication credentials if required, and give a weight to that feed. The weight can be an overall number or a by category weight. This will allow the admin to minimize the influence a feed has on their overall reputation if they distrust a particular category or feed, or trust another implicitly. Feeds can be configured to accept feedback or not and will report so on connect. The admin can override and choose not to give any feedback, but the sensor should report these to the Hub upstream on connect.  The hub will take all of these feeds and aggregate them into an average single score for each IP or IP Block, and then redistribute this data to all local sensors as configured. It should receive connections from sensors. The sensor will have to provide authentication and will provide feedback. The hub should redistribute that feedback from sensors to all other sensors as well as up to any feeds that accept feedback.  The hub should also have an API to allow outside statistical analysis to be done to the database and fed back in to the stream. For instance a local site may choose to change the reputation on all Russian IP blocks, etc.
 
 
-For more information about IP Reputation see :doc:`ip-reputation-config`, :doc:`ip-reputation-rules` and :doc:`ip-reputation-format`.
+For more information about IP Reputation see :doc:`ip-reputation-config`, :doc:`/rules/ip-reputation-rules` and :doc:`ip-reputation-format`.
index d684c3117fae5c28405cf598e39ccb6768c09193..1012717e338b674af040e2448b877d78483fe726 100644 (file)
@@ -385,7 +385,7 @@ IP Reputation and ``iprep`` Keyword
 
 -  :doc:`../reputation/index`
 -  :doc:`../reputation/ipreputation/ip-reputation-config`
--  :doc:`../reputation/ipreputation/ip-reputation-rules`
+-  :doc:`ip-reputation-rules`
 -  :doc:`../reputation/ipreputation/ip-reputation-format`
 -  `http://blog.inliniac.net/2012/11/21/ip-reputation-in-suricata/ <http://blog.inliniac.net/2012/11/21/ip-reputation-in-suricata/>`_
 
index 2b8924c15271368681455e2dc493f649ec09a6d5..6ddc079d9b94bef6c30910841cb3be1a6c70eaf1 100644 (file)
@@ -19,5 +19,6 @@ Suricata Rules
    app-layer
    xbits
    thresholding
+   ip-reputation-rules
    rule-lua-scripting
    differences-from-snort
similarity index 75%
rename from doc/userguide/reputation/ipreputation/ip-reputation-rules.rst
rename to doc/userguide/rules/ip-reputation-rules.rst
index 1808c98f15398b743ce27d9ced5d3273944f1488..f0b5f18d4f8615bd8795d1a8195ac923827b7eb5 100644 (file)
@@ -1,10 +1,12 @@
-IP Reputation Rules
-===================
+IP Reputation Keyword
+=====================
 
-IP Reputation can be used in rules through a new rule directive "iprep".
+IP Reputation can be used in rules through a new rule keyword "iprep".
+
+For more information about IP Reputation see :doc:`/reputation/ipreputation/ip-reputation-config` and :doc:`/reputation/ipreputation/ip-reputation-format`.
 
 iprep
-~~~~~
+-----
 
 The iprep directive matches on the IP reputation information for a host.
 
@@ -41,5 +43,3 @@ The "iprep" keyword is compatible to "IP-only" rules. This means that a rule lik
   alert ip any any -> any any (msg:"IPREP High Value CnC"; iprep:src,CnC,>,100; sid:1; rev:1;)
 
 will only be checked once per flow-direction.
-
-For more information about IP Reputation see :doc:`ip-reputation-config` and :doc:`ip-reputation-format`.