[Oisf-users] Analysis of SSL-decrpyted traffic

[Federico Foschini]

Hello Nelson thank you for your insights.

The inbound case obviously is the more interesting one since you can
inspect all inbound attacks hitting your servers.
Unfortunately it seems the way to go for all firewall vendors is to sell
the client SSL inspection as the holy grail to solve all security problems.
I agree with you that is not so useful but some of our clients have it
enabled so analyzing the traffic on suricata would be useful to me.

Also I read that ET is planning to release some signature specifically for
TLS-inspected traffic.

However I did some testing and it looks like that if I’m only sniffing from
the firewall interface everything is working fine. The issue starts when
I’m sniffing both from the mirror port on the switch and on the firewall
with this configuration:

af-packet:
  - interface: enp4s0
    threads: 2
    cluster-id: 1
    cluster-type: cluster_flow
    defrag: yes # To use the ring feature of AF_PACKET, set 'use-mmap' to yes
    use-mmap: yes
    tpacket-v3: yes
  - interface: enp3s0
    threads: 2
    cluster-id: 2
    cluster-type: cluster_flow
    defrag: yes # To use the ring feature of AF_PACKET, set 'use-mmap' to yes
    use-mmap: yes
    tpacket-v3: yes

enp4s0 is the firewall mirror port and enp3s0 is the switch.

All traffic mirrored from the switch is processed while the one from the
firewall is not. When doing an SSL connection in Zeek I can see the SSL
encrypted flow mirrored from the switch and also the HTTP decrypted traffic
from the firewall. In suricata I see only the SSL encrypted traffic.

Il giorno mar 25 feb 2020 alle ore 20:04 Cooper F. Nelson <cnelson at ucsd.edu>
ha scritto:

> Have you tried logging http to file, to ensure that suricata is decoding
> it?
>
> Have you tried enabling the http-events rules?
>
> https://github.com/OISF/suricata/blob/master/rules/http-events.rules
>
> In my personal experience, I haven't seen any evidence of malicious
> behavior over tls from common sources (trusted domains/IPs) to our
> clients.  This is based on cross-referencing EDR alerts with suricata.  We
> sinkhole bad IPs and domains automatically, which will stop the bulk of
> these attacks entirely from 'known bad' sources.  I have observed malicious
> activity inbound over tls to servers, however.
>
> For malware that uses tls, like Dridex, the EmergingThreats team will
> release signatures for the certificates, so you may actually be losing
> visibility by decoding the traffic.  I'm not sure if they have sigs to
> detect the decoded CnC traffic for malware families that utilize tls.
>
> -Coop
> On 2/25/2020 8:53 AM, Federico Foschini wrote:
>
> Hello,
> I’ve configured my firewall to mirror SSL-decrypted traffic to a server in
> which I’m running suricata 5.0
>
> I cannot trigger any alert on this type of traffic, even if using zeek or
> wireshark I can clearly see that the traffic is HTTP (but on port 443).
>
> In suricata.yaml I’ve added port 443 in HTTP_PORTS variable:
>
> port-groups:
>     HTTP_PORTS: "[80,81,311,383, 443, ...]"
>
> --
> Cooper Nelson
> Network Security Analyst
> UCSD ITS Security Teamcnelson at ucsd.edu x41042
>
>

-- 
Federico Foschini.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20200226/43f560cd/attachment-0001.html>