Unexpected connect event before listen for openssl s_server using kmod driver

[dasflk]

Describe the bug
I am seeing unexpected evt.type=connect events when using the kmod driver.

The event is generated from a server-side process that appears to only listen for and accept inbound connections.

In this case, the process is started as a TLS server using openssl s_server. It should only listen for and accept inbound connections, but Falco reports a connect event before the corresponding listen event.

The reported socket fields also look inconsistent:

• evt.type is reported as connect, even though the process is acting as a server.
• fd.l4proto is reported as udp, even though openssl s_server is expected to use TCP/TLS.
• fd.is_server is true, which seems contradictory for a connect-style event.
• fd.rip / fd.sip contain unusual IPv6 addresses.
• evt.args contains addr=0.0.0.0:18300, which looks like a wildcard bind/listen address rather than a valid connect destination.
• The connect event is reported immediately before the corresponding listen event.

How to reproduce it

Generate a temporary self-signed certificate:

openssl req -x509 -newkey rsa:2048
-keyout /tmp/test.key
-out /tmp/test.crt
-days 1
-nodes
-subj "/CN=localhost"

Start a TLS server:

openssl s_server
-accept 18300
-cert /tmp/test.crt
-key /tmp/test.key

Expected behaviour

Since openssl s_server is acting as a server-side process, I expected Falco to report only the listen event for this operation.

I did not expect a connect event to be generated, because the process is not making an outbound connection.

The expected behaviour is that only the network_listen event is reported, not the preceding network_connect event.

I also expected the socket fields to be consistent with TCP/TLS, instead of being reported as fd.l4proto=udp.

Actual behaviour

Falco first reports a network_connect event:

{
"hostname": "localhost.localdomain",
"output_fields": {
"evt.args": "res=0 tuple=::ffff:127.0.0.1:60021->::200:477c:0:0:18300 fd=3(<6u>::ffff:127.0.0.1:60021->::200:477c:0:0:18300) addr=0.0.0.0:18300",
"evt.datetime": 1779843344280007287,
"evt.rawres": 0,
"evt.res": "SUCCESS",
"evt.time": 1779843344280007287,
"fd.cip": "::ffff:127.0.0.1",
"fd.cport": 60021,
"fd.is_server": true,
"fd.l4proto": "udp",
"fd.lip": "::ffff:127.0.0.1",
"fd.lport": 60021,
"fd.name": "::ffff:127.0.0.1:60021->::200:477c:0:0:18300",
"fd.rip": "::200:477c:0:0",
"fd.rport": 18300,
"fd.sip": "::200:477c:0:0",
"fd.sport": 18300,
"fd.type": "ipv6",
"fd.typechar": "6",
"proc.cmdline": "openssl s_server -accept 18300 -cert /tmp/test.crt -key /tmp/test.key",
"proc.exepath": "/usr/bin/openssl",
"proc.name": "openssl",
"proc.pid": 800803,
"proc.ppid": 798707
},
"priority": "Notice",
"rule": "network_connect",
"source": "syscall",
"time": "2026-05-27T00:55:44.280007287Z"
}

Immediately after that, Falco reports the corresponding network_listen event:

{
"hostname": "localhost.localdomain",
"output_fields": {
"evt.datetime": 1779843344280275511,
"evt.time": 1779843344280275511,
"fd.sip": "0.0.0.0",
"fd.sport": 18300,
"proc.exepath": "/usr/bin/openssl"
},
"priority": "Notice",
"rule": "network_listen",
"source": "syscall",
"time": "2026-05-27T00:55:44.280275511Z"
}

Rule used to capture the event:

• rule: network_connect
  desc: Collect outbound connect
  condition: >
  evt.type=connect
  and fd.typechar in (4, 6)
  and (fd.l4proto=tcp or fd.l4proto=udp)
  and not proc.exepath in (allowed_net_proc_exepath)
  and not is_whitelist_pipeline_process
  and not is_allowed_outbound_network
  and not is_allowed_outbound_port
  exceptions:
  - name: allowed_net_connect_caller_and_remote_port
  fields: [proc.exepath, fd.rip, fd.rport]
  comps: [=, =, =]
  values:
  - [/usr/sbin/rsyslogd, 10.10.10.10, 514]
  enabled: true
  output: >
  [NET_CONNECT][%evt.datetime]
  exe=%proc.exepath
  pname=%proc.name
  pid=%proc.pid
  ppid=%proc.ppid
  cmd=%proc.cmdline
  fd.name=%fd.name
  fd.type=%fd.type
  fd.typechar=%fd.typechar
  l4=%fd.l4proto
  is_server=%fd.is_server
  lip=%fd.lip
  lport=%fd.lport
  rip=%fd.rip
  rport=%fd.rport
  cip=%fd.cip
  cport=%fd.cport
  sip=%fd.sip
  sport=%fd.sport
  evt.res=%evt.res
  evt.rawres=%evt.rawres
  evt.args=%evt.args
  priority: NOTICE
  tags: [collect, network]

Screenshots

Environment

• Falco version:0.43.0

• System info: Linux version 4.18.0-553.el8_10.x86_64 (mockbuild@iad1-prod-build001.bld.equ.rockylinux.org) (gcc version 8.5.0 20210514 (Red Hat 8.5.0-22) (GCC)) Digwatch compiler #1 SMP Fri May 24 13:05:10 UTC 2024

• Cloud provider or hardware configuration: Not running on a cloud provider. Local test environment.
• OS: Rocky Linux 8.10

• Kernel: Linux version 4.18.0-553.el8_10.x86_64

• Installation method: RPM

• Driver: kmod
• Architecture: x86_64

Additional context
Similar events are also occurring periodically with sshd.

{
"hostname": "localhost.localdomain",
"output_fields": {
"evt.args": "res=0 tuple=::ffff:127.0.0.1:56452->::f648:1ca8:2b11:b318:22 fd=4(<6u>::ffff:127.0.0.1:56452->::f648:1ca8:2b11:b318:22) addr=0.0.0.0:22",
"evt.datetime": 1779785156943169782,
"evt.rawres": 0,
"evt.res": "SUCCESS",
"evt.time": 1779785156943169782,
"fd.cip": "::ffff:127.0.0.1",
"fd.cport": 56452,
"fd.is_server": true,
"fd.l4proto": "udp",
"fd.lip": "::ffff:127.0.0.1",
"fd.lport": 56452,
"fd.name": "::ffff:127.0.0.1:56452->::f648:1ca8:2b11:b318:22",
"fd.rip": "::f648:1ca8:2b11:b318",
"fd.rport": 22,
"fd.sip": "::f648:1ca8:2b11:b318",
"fd.sport": 22,
"fd.type": "ipv6",
"fd.typechar": "6",
"proc.cmdline": "sshd -D -oCiphers=aes256, ... ,rsa-sha2-512,ssh-rsa -R",
"proc.exepath": "/usr/sbin/sshd",
"proc.name": "sshd",
"proc.pid": 575653,
"proc.ppid": 783
},
"priority": "Notice",
"rule": "network_connect",
"source": "syscall",
"time": "2026-05-26T08:45:56.943169782Z"
}

It seems that there was a similar issue in the past:
#1835

This issue also occurs in a CentOS environment with Falco 0.39.2 installed with kmod.

Could my network_connect rule be incorrect?

Is there any way to prevent these connect events from being generated or reported?