Suricata on SELKS7/Docker will not detect TLS/SSL state

[michal25]

Is there an existing issue for this?

• [X] I have searched the existing issues

Current Behavior

This signature is not working on some SELKS7/Docker installations:

alert tls any any -> any any (msg:"TLS server_hello"; classtype:protocol-command-decode; ssl_state:server_hello; sid:200012; rev:1;)

But, the TLS packet i regulary logged in the pcap.file and wireshark shows the TLS state OK.

Maybe some performance problems on the Suricata/Decoder side?

root@suricata:~# docker exec suricata suricata --build-info This is Suricata version 7.0.1-dev (becb8cefc 2023-08-11) Features: NFQ PCAP_SET_BUFF AF_PACKET HAVE_PACKET_FANOUT LIBCAP_NG LIBNET1.1 HAVE_HTP_URI_NORMALIZE_HOOK PCRE_JIT HAVE_NSS HTTP2_DECOMPRESSION HAVE_LUA HAVE_LIBJANSSON TLS TLS_C11 MAGIC RUST SIMD support: SSE_4_2 SSE_4_1 SSE_3 Atomic intrinsics: 1 2 4 8 16 byte(s) 64-bits, Little-endian architecture GCC version 11.3.1 20221121 (Red Hat 11.3.1-4), C version 201112 compiled with _FORTIFY_SOURCE=0 L1 cache line size (CLS)=64 thread local storage method: _Thread_local compiled with LibHTP v0.5.45, linked against LibHTP v0.5.45

Suricata Configuration: AF_PACKET support: yes AF_XDP support: no DPDK support: yes eBPF support: yes XDP support: yes PF_RING support: no NFQueue support: yes NFLOG support: no IPFW support: no Netmap support: no DAG enabled: no Napatech enabled: no WinDivert enabled: no

Unix socket enabled: yes Detection enabled: yes

Libmagic support: yes libjansson support: yes hiredis support: yes hiredis async with libevent: yes PCRE jit: yes LUA support: yes libluajit: no GeoIP2 support: yes Non-bundled htp: no Hyperscan support: yes Libnet support: yes liblz4 support: yes Landlock support: yes

Rust support: yes Rust strict mode: no Rust compiler path: /usr/bin/rustc Rust compiler version: rustc 1.66.1 (90743e729 2023-01-10) (Red Hat 1.66.1-2.el9_2) Cargo path: /usr/bin/cargo Cargo version: cargo 1.66.1

Python support: yes Python path: /usr/bin/python3 Install suricatactl: yes Install suricatasc: yes Install suricata-update: yes

Profiling enabled: no Profiling locks enabled: no Profiling rules enabled: no

Plugin support (experimental): yes DPDK Bond PMD: no

Development settings: Coccinelle / spatch: no Unit tests enabled: no Debug output enabled: no Debug validation enabled: no Fuzz targets enabled: no

Generic build parameters: Installation prefix: /usr Configuration directory: /etc/suricata/ Log directory: /var/log/suricata/

--prefix /usr --sysconfdir /etc --localstatedir /var --datarootdir /usr/share

Host: x86_64-pc-linux-gnu Compiler: gcc (exec name) / g++ (real) GCC Protect enabled: no GCC march native enabled: no GCC Profile enabled: no Position Independent Executable enabled: no CFLAGS -g -O2 -fPIC -std=c11 -I/usr/include/dpdk -include rte_config.h -march=corei7 -I${srcdir}/../rust/gen -I${srcdir}/../rust/dist PCAP_CFLAGS
SECCFLAGS

Expected Behavior

No response

Steps To Reproduce

No response

Docker version

Docker version 24.0.5, build ced0996

Docker version

docker-compose version 1.29.2, build unknown

OS Version

Description: Ubuntu 22.04.3 LTS

Content of the environnement File

COMPOSE_PROJECT_NAME=selks INTERFACES= -i enp2s0f1 ELASTIC_MEMORY=8G LOGSTASH_MEMORY=8G SCIRIUS_SECRET_KEY=WWazeZtZPpqNIq5VZIWvkb2wUIw3nAr6Al9n63U3Bk4 PWD=${PWD}

Version of SELKS

commit a030b9acbef9e846cfd247fef9c8ac8c1794c6a8 (HEAD -> master, origin/master, origin/HEAD) Author: Eric Leblond el@stamus-networks.com Date: Mon Jul 31 19:08:48 2023 +0200

Revert "docker: improve docker compose check further by using `--short`"

This reverts commit 2db7e0be16e2572ccd7c47acef9451f7343e77ae.

It seems to break during some QA tests.

Anything else?

No response

[pevma]

Is the signature loading ok - in other words it is shown as loaded and active in the signatures tab ?

[michal25]

Yes, the signature is loading OK and it is shown as active.

Dne 21. 08. 23 v 15:19 Peter Manev napsal(a):

Is the signature loading ok - in other words it is shown as loaded and active in the signatures tab ?

— Reply to this email directly, view it on GitHub https://github.com/StamusNetworks/SELKS/issues/449#issuecomment-1686316081, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGUNEJSB3T77646R2MMELLXWNN43ANCNFSM6AAAAAA3VUHRKA. You are receiving this because you authored the thread.Message ID: @.***>

-- Ing. Michal Vymazal Senior Cyber Security Architect

Linux Services CEO

@.*** www.linuxservices.cz Home Computer

LinkedIn profile https://www.linkedin.com/in/linuxservices/

This mail can't contain any virus. I'm using only Open Source software.

[pevma]

Is it possible to share a pcap privately ?

[michal25]

No problem.

Dne 21. 08. 23 v 17:51 Peter Manev napsal(a):

Is it possible to share a pcap privately ?

— Reply to this email directly, view it on GitHub https://github.com/StamusNetworks/SELKS/issues/449#issuecomment-1686587166, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGUNENPL7RAB6YM7M3N3HDXWN7XPANCNFSM6AAAAAA3VUHRKA. You are receiving this because you authored the thread.Message ID: @.***>

-- Ing. Michal Vymazal Senior Cyber Security Architect

Linux Services CEO

@.*** www.linuxservices.cz Home Computer

LinkedIn profile https://www.linkedin.com/in/linuxservices/

This mail can't contain any virus. I'm using only Open Source software.

[michal25]

Some more info for this case. This signature works OK: alert tls any any -> any any (msg:"TLS client_hello"; classtype:protocol-command-decode; ssl_state:client_hello; sid:200013; rev:1;)

and

suricata.yaml/selks6-addin.yaml

tls:
      enabled: yes
      detection-ports:
        dp: 443

encryption-handling: default

[pevma]

You also mention this is specific to Ubuntu LTS only , correct ?

[michal25]

At this time, this case is specific only to current SELKS7/Suricata Docker installation on Ubuntu 22.04 LTS 64 bit server edition.

[michal25]

Some more info for this case:

root@suricata:~# ethtool -k enp2s0f1|grep tcp tcp-segmentation-offload: off tx-tcp-segmentation: off tx-tcp-ecn-segmentation: off tx-tcp-mangleid-segmentation: off tx-tcp6-segmentation: off

And - very interesting: This signature

alert tls any any -> any any (msg:"TLS store certificate"; classtype:protocol-command-decode; tls.store; sid:200055; rev:1;)

Causes output in the main dashboard (so TLS certificate detected), but no TLS certificates stored on the HDD. The yaml configuration looks this>

` # output module to store certificates chain to disk

• tls-store: enabled: yes certs-log-dir: certs # directory to store the certificates files `

[pevma]

Is the directory certs present and there?
Also the storing is working on other OSes too or not ?

[michal25]

The directory certs exists, on the other installations tls.store works good.

root@suricata:/opt/SELKS/docker/containers-data/suricata/logs# ls -l total 98154424 drwxr-x--- 2 994 994 6 Aug 26 21:02 certs -rw-r--r-- 1 994 994 21292768010 Aug 29 19:27 eve.json -rw-r--r-- 1 994 994 31700640258 Aug 29 04:02 eve.json.1 -rw-r--r-- 1 994 994 37134236715 Aug 28 04:01 eve.json.2 -rw-r--r-- 1 994 994 9831763500 Aug 27 04:01 eve.json.3 drwxr-xr-x 2 994 994 2134016 Aug 29 19:27 fpc -rw-r--r-- 1 994 994 0 Aug 27 19:57 http.log.1 -rw-r--r-- 1 994 994 0 Aug 26 21:02 http.log.2 -rw-r--r-- 1 994 994 71090710 Aug 29 19:27 stats.log -rw-r--r-- 1 994 994 104119736 Aug 29 04:02 stats.log.1 -rw-r--r-- 1 994 994 96782456 Aug 28 04:01 stats.log.2 -rw-r--r-- 1 994 994 26598910 Aug 27 04:01 stats.log.3 -rw-r--r-- 1 994 994 31956 Aug 29 04:02 suricata.log.1 -rw-r--r-- 1 994 994 116513 Aug 28 04:01 suricata.log.2 -rw-r--r-- 1 994 994 94342 Aug 27 04:01 suricata.log.3 -rw-r--r-- 1 994 994 90927 Aug 29 19:17 tls.log -rw-r--r-- 1 994 994 120407 Aug 28 23:36 tls.log.1 -rw-r--r-- 1 994 994 82409 Aug 28 00:09 tls.log.2 -rw-r--r-- 1 994 994 1768 Aug 26 23:25 tls.log.3

[pevma]

ok so this problem is also related to just LTS Ubuntu. Wondering if it is docker version or some sys locking issue related ?

[michal25]

Look on this:

alert tls any any -> any any (msg:"TLS client_hello"; classtype:protocol-command-decode; ssl_state:client_hello; sid:200013; rev:1;)

Signature works (screenshot attached), but

Here is the output from tls.log file: 08/29/2023-19:07:16.456174 2001:0718:0007:0204:70f7:75b4:4753:98fc:61918 -> 2620:0149:0af0:0000:0000:0000:0000:0010:443 TLS: SNI='apple.com' VERSION='UNDETERMINED' 08/29/2023-19:11:10.493954 2001:0718:0007:0204:3dfc:d32d:17fc:d9ee:64002 -> 2620:0149:0af0:0000:0000:0000:0000:0010:443 TLS: SNI='icloud.com' VERSION='UNDETERMINED' 08/29/2023-19:11:11.490224 2001:0718:0007:0204:3dfc:d32d:17fc:d9ee:64003 -> 2620:0149:0af0:0000:0000:0000:0000:0010:443 TLS: SNI='apple.com' VERSION='UNDETERMINED'

But, this output is "crippled" because, normal output (from working installation) looks different (next post).

[michal25]

tls.log example from working installation:

08/29/2023-19:22:56.195643 212.158.157.51:57032 -> 175.181.102.98:8444 TLS: VERSION='TLS 1.3' 08/29/2023-19:22:58.279795 212.158.157.53:58719 -> 13.89.178.27:443 TLS: Subject='C=US, ST=WA, L=Redmond, O=Microsoft, OU=WSE, CN=.events.data.microsoft.com' Issue rdn='C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Secure Server CA 2011' SHA1='bf:5c:0d:44:3d:f1:99:bf:72:cd:64:51:e8:d6:6a:b7:cc:9d:b1:5e' SNI='v20.events.data.microsoft.com' SERIAL='33:00:00:02:48:89:C0:D0:B1:46:68:69:EC:00:00:00:00:02:48' VERSION='TLS 1.2' NOTBEFORE='2023-05-25T20:00:20' NOTAFTER='202 4-08-25T20:00:20' 08/29/2023-19:22:59.382380 212.158.157.51:57035 -> 59.13.77.15:8444 TLS: VERSION='TLS 1.3' 08/29/2023-19:23:00.719975 212.158.157.51:57037 -> 81.129.114.65:8444 TLS: VERSION='TLS 1.3' 08/29/2023-19:23:02.333034 212.158.157.51:57039 -> 93.103.184.54:8444 TLS: VERSION='TLS 1.3' 08/29/2023-19:23:03.295371 212.158.157.51:57040 -> 13.107.42.16:443 TLS: Subject='C=US, ST=WA, L=Redmond, O=Microsoft Corporation, CN=.config.skype.com' Issuerdn=' C=US, O=Microsoft Corporation, CN=Microsoft Azure TLS Issuing CA 05' SHA1='5f:cf:a3:2c:f5:ff:40:46:67:ad:e2:08:f8:8b:ca:50:ff:6f:2f:90' SNI='config.edge.skype.com' S ERIAL='33:00:BB:57:39:5E:2C:BB:DF:01:56:52:DF:00:00:00:BB:57:39' VERSION='TLS 1.2' NOTBEFORE='2023-06-20T16:15:16' NOTAFTER='2024-06-14T16:15:16'

[pevma]

What about the TLS log records from suricata (event_type:tls) - you can see those in the SN-TLS Kibana dashboard.

[michal25]

I can see the recorded TLS log records from working signature

alert tls any any -> any any (msg:"TLS client_hello"; classtype:protocol-command-decode; ssl_state:client_hello; sid:200013; rev:1;)

BUT TLS VERSION='UNDETERMINED'

[pevma]

ok , that data is in the pcap you shared earlier , correct ?

[michal25]

Exactly.

Now, I inspected Arkime functionality and Arkime detects the TLS traffic correctly from the pcap files ...

[michal25]

[michal25]

I changed the configuration file in this way: ` suricata.yaml/selks6-addin.yaml

tls: enabled: yes detection-ports: dp: 443, 993, 2224, 5022, 5223, 5555, 5989, 9080, 38881

encryption-handling: default `

But, no effect.

[michal25]

It seems the two sides of the connection are in different VLANs (id 9 and id 902) and hence we do not generate the events.

You can disable that behaviour you can simply switch it to "false" in th eyaml then restart the suricata docker:
https://github.com/OISF/suricata/blob/master/suricata.yaml.in#L1438  

Please mark the issue as resolved after you confirm it is working.  

YES In suricata.yaml I set this:

vlan: use-for-tracking: false And now, I can see the TLS signatures working and detecting the TLS traffic.

[pevma]

Thanks for confirming!