Closed clmssz closed 1 year ago
In theory, user.uid -1
means that there is no thread information associated with the event; basically (see here: https://github.com/falcosecurity/libs/blob/master/userspace/libsinsp/filterchecks.cpp#L4781): evt->get_thread_info()
is NULL. In fact, uid is obtained from the event threadinfo:
case TYPE_UID:
RETURN_EXTRACT_VAR(tinfo->m_uid);
I don't really know how that could happen on inbound_outbound
macro (that expands to events:
evt.type in (accept,listen,connect) and evt.dir=<)
.
Can you print thread.tid
too in your rule and report back its value?
Mar 3 08:48:37 redacted-hostname falco: {"output":"08:48:37.630357321: Notice New SSH Connection (command=<NA> connection=x.x.x.x:50046->x.x.x.x:22 user=<NA> user_loginuid=-1 uid=4294967295 thread=7286)","priority":"Notice","rule":"New SSH Connection","source":"syscall","tags":["mitre_remote_service","network"],"time":"2022-03-03T08:48:37.630357321Z", "output_fields": {"evt.time":1646297317630357321,"fd.name":"x.x.x.x:50046->x.x.x.x:22","proc.cmdline":"<NA>","thread.tid":7286,"user.loginuid":-1,"user.name":null,"user.uid":4294967295}}
Mar 3 08:48:37 redacted-hostname falco[15001]: % Total % Received % Xferd Average Speed Time Time Time Current
Mar 3 08:48:37 redacted-hostname falco[15001]: Dload Upload Total Spent Left Speed
Mar 3 08:48:37 redacted-hostname falco[15001]: #015 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0#015 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0#015100 172 0 2 100 170 13 1133 --:--:-- --:--:-- --:--:-- 1139
root 7286 0.0 0.0 72304 5844 ? Ss Feb16 0:00 /usr/sbin/sshd -D
So, we got a valid and actually correct thread id. Nice! I will try to reproduce the issue! ;)
Hello! I just failed to reproduce this issue with the following setup:
%user.name, %user.loginuid, %user.uid
Do you have any additional configs that could be relevant? Thanks!
Hi @andreabonanno, we use OSlogin on GCP vm's, it adds pam configurations, maybe it's a lead ? https://cloud.google.com/compute/docs/oslogin
Hey @clmssz, are you able to reproduce this in the newly-released Falco 0.32 too?
Please be aware of https://github.com/falcosecurity/falco/issues/2048
I'll follow up after the 0.32 patch @jasondellaluce
The issue still occurs in v0.32.1:
Hi! This is expected since we are not able to extract users and groups list from containers. Me and @loresuso are working on a solution involving accessing the overlayfs of the containers to read /etc/pwd and /etc/group. Hopefully 0.33 will fix this one too!
I'll keep you posted :)
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stale
Hi! This is expected since we are not able to extract users and groups list from containers. Me and @loresuso are working on a solution involving accessing the overlayfs of the containers to read /etc/pwd and /etc/group. Hopefully 0.33 will fix this one too!
Hi @FedeDP I tried v0.33 and unfortunately the issue is still there:
Hi! Yes, you won't believe it but we are working on another approach to solve the issue: https://github.com/falcosecurity/libs/pull/677 Hopefully this will be the best solution. @deepskyblue86
@FedeDP This sounds good, do you know when this will be implemented or in which version?
Hi! Falco 0.34 will surely have this feature. I am not sure if we will make a 0.33.1 patch release for this one (and perhaps some more fixes). Let's say that you can expect the fixed version by the end of january for sure; if you are lucky enough, even before through a Falco patch release :)
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stale
Hello every one even im facing same issue, im not able to fetch user.
12:29:34.022226956: Notice Ingress remote file copy tool launched in container (user=<NA> user_loginuid=-1 command=curl -o /dev/null -w %{http_code} --max-time 3 -XGET -g -s -k -u elastic-internal-probe: http://127.0.0.1:9200/ pid=363194 parent_process=bash
@manojdeshmukh45 which version do you use?
is this still an issue?
No Andrea, It get fixed using new version and I used custom-rules which override the old rules. its working goog.
On Tue, Jul 18, 2023 at 3:48 AM Andrea Terzolo @.***> wrote:
is this still an issue?
— Reply to this email directly, view it on GitHub https://github.com/falcosecurity/falco/issues/1921#issuecomment-1638965064, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIRWHSDN5UBFY6HCERSGLCDXQW237ANCNFSM5PXTN5XA . You are receiving this because you were mentioned.Message ID: @.***>
--
Thanks & Regards
Manoj Deshmukh
Cybersecurity Analyst
CEH Practical v12 | CompTIA CySA+
/close
@FedeDP: Closing this issue.
Metadatas are empty for %user.name %user.loginuid %user.uid in a rule detecting SSH connections. Also at the first occurrence, proc.cmdline is empty, then not
rule lies in
falco_local_rules.yaml
macros are the one from the default rulesetOn a @FedeDP suggestion I tried
%user.uid
and it yields4294967295
(-1)Cloud provider or hardware configuration: GCP Ubuntu 18.04.6 LTS
Installation method:
https://github.com/juju4/ansible-falco (Packages)
There are no containers involved in this test, it's installed directly on the VM