mirror of https://github.com/OISF/suricata
doc/userguide: new 3rd party section, add bluecoat
Add Symantec SSLV (bluecoat) doc to new 3rd party section for documenting integrating Suricata with 3rd party tools.pull/3704/head
parent
398133b6ce
commit
f1c83c3308
@ -0,0 +1,6 @@
|
||||
3rd Party Integration
|
||||
=====================
|
||||
|
||||
.. toctree::
|
||||
|
||||
symantec-sslv
|
@ -0,0 +1,90 @@
|
||||
Symantec SSL Visibility (BlueCoat)
|
||||
==================================
|
||||
|
||||
As Suricata itself cannot decrypt SSL/TLS traffic, some organizations use
|
||||
a decryption product to handle this. This document will offer some advice
|
||||
on using Suricata with the Symantec SSL Visibility appliance (formerly
|
||||
known as BlueCoat).
|
||||
|
||||
|
||||
Appliance Software Version
|
||||
--------------------------
|
||||
|
||||
The appliance comes with two major software version options. The 3.x and 4.x
|
||||
series. Suricata works best with the 4.x series.
|
||||
|
||||
TLS1.3 is only properly supported in the 4.x version of the appliance
|
||||
software.
|
||||
|
||||
|
||||
Magic Markers
|
||||
-------------
|
||||
|
||||
The appliance has an indicator that data is decrypted. This is done using
|
||||
a special magic source MAC address, or using a special VLAN header. Since
|
||||
Suricata can use VLANs as part of flow tracking, it is recommended to use
|
||||
the source MAC method.
|
||||
|
||||
In the 3.x version of the software these markers are always there, the
|
||||
config just allows setting which type will be used. In the 4.x software the
|
||||
markers are optional.
|
||||
|
||||
|
||||
TCP handling
|
||||
------------
|
||||
|
||||
In the 3.x software, a bit of care is required in TCP stream reassembly
|
||||
handling in Suricata. The decrypted traffic is presented to the IDS as
|
||||
TCP data packets, that are not ack'd as regularly as would be expected
|
||||
in a regular TCP session. A large TCP window is used to not violate the
|
||||
TCP specs. Since in IDS mode Suricata waits for ACKs for much of its
|
||||
processing, this can lead to delays in detection and logging, as well
|
||||
as increased resource usage due to increased data buffering.
|
||||
|
||||
To avoid this, enable the 'stream.inline' mode, which processed data
|
||||
segments as they come in without waiting for the ACKs.
|
||||
|
||||
The 4.x software sends more regular ACKs and does not need any special
|
||||
handling on the Suricata side.
|
||||
|
||||
|
||||
TLS matching in Suricata
|
||||
------------------------
|
||||
|
||||
The appliance takes care of the TLS handling and decryption, presenting
|
||||
only the decrypted data to Suricata. This means that Suricata will not
|
||||
see the TLS handshake. As a consequence of this, Suricata cannot inspect
|
||||
the TLS handshake or otherwise process it. This means that for decrypted
|
||||
TLS sessions, Suricata will not do any TLS keyword inspection (such as
|
||||
fingerprint matching and ja3), TLS logging or TLS certificate extraction.
|
||||
|
||||
If it is important to match on and/or log such information as well, the
|
||||
appliance facilities for matching and logging themselves will have to be
|
||||
used.
|
||||
|
||||
For TLS traffic where the appliance security policy does not lead to
|
||||
decryption of the traffic, the TLS handshake is presented to Suricata
|
||||
for analysis and logging.
|
||||
|
||||
IPS
|
||||
---
|
||||
|
||||
When using Suricata in IPS mode with the appliance, some things will
|
||||
have to be considered:
|
||||
|
||||
* if Suricata DROPs a packet in the decrypted traffic, this will be seen
|
||||
by the appliance after which it will trigger a RST session teardown.
|
||||
|
||||
* if a packet takes more than one second to process, it will automatically
|
||||
be considered a DROP by the appliance. This should not happen in normal
|
||||
traffic, but with very inefficient Lua scripts this could perhaps
|
||||
happen. The appliance can also be configured to wait for 5 seconds.
|
||||
|
||||
* When using the Suricata 'replace' keyword to modify data, be aware
|
||||
that the 3.x appliance software will not pass the modification on to
|
||||
the destination so this will not have any effect. The 4.x appliance
|
||||
software does support passing on modifications that were made to the
|
||||
unencrypted text, by default this feature is disabled but you can
|
||||
enable it if you want modifications to be passed on to the destination
|
||||
in the re-encrypted stream. Due to how Suricata works, the size of
|
||||
the payloads cannot be changed.
|
Loading…
Reference in New Issue