AWS集群容器auditlog之falco

admin 2025年5月7日11:22:54评论3 views字数 6804阅读22分40秒阅读模式

最近在做内部的安全检查,发现我们内部的服务似乎并没有配置容器内的auditlog,只有基于k8s的操作日志,那这样就有点太无感啦,只要出现新的0day,黑客攻击进来后,几乎梭哈,并且我还得不到任何消息。

这不行,作为卑微的安全选手,不能让自己更加的被动呀,于是乎就有了本文。一般云上都会集成一些付费的auditlog,很显然这并不适合我,毕竟安全没有预算。。。

AWS集群容器auditlog之falco

通过一阵操作,终于让我遇到了对的它(falco),开源的爸爸,而且和云的集成也很完善,啥话不说就是干。关于falco这里就不做细述,大哥们可以直接看官方文档,细的一批(https://falco.org/docs/concepts/outputs/forwarding/)。

添加repo
helm repo add falcosecurity https://falcosecurity.github.io/chartshelm repo update
下载falco
helm install --replace falco --namespace falco --create-namespace --set tty=true falcosecurity/falco

操作极其简单,这样就直接在falco的命名空间创建了falco,现在已经在使用falco自带的规则对集群容器的行为进行监听,很显然我要的并不是哪些默认的规则,而是定制化的(好在falco规则定义这一块也简单的一批),上规则,如下。

customRules:  monitor_file.yaml: |-    - rule: Sensitive file accessed      desc: Detects when a sensitive file like /etc/shadow or /etc/passwd is accessed      condition>        evt.type in (open, openat) and        fd.name in ("/etc/shadow", "/root/.ssh/authorized_keys") and         fd.name != "<NA>" and         k8s.pod.name != "<NA>" and         proc.name != "ps" and         not proc.name in (check_docker_of, network_problem, instance_expire, check_inodes.sh, check_pid_press, cron, crond, mv, php, cilium-agent, GameServer, apache2, dateand         user.name != "<NA>"      output: >        Sensitive file accessed (user=%user.name command=%proc.cmdline file=%fd.name container=%container.id %container.info)      priority: WARNING      tags: [filesystem, sensitive]  monitor_suspicious_command_execution.yaml: |-    - rule: Detect Suspicious Reconnaissance Commands      desc: Detect execution of reconnaissance commands like whoami, id, uname, ifconfig.      condition>        evt.type = execve and        (proc.cmdline = "whoami" or proc.cmdline = "id" or proc.cmdline = "pwd" or proc.cmdline startswith "uname" or        proc.cmdline startswith "ifconfig" or proc.cmdline startswith "ip a" or        proc.cmdline startswith "netstat" or proc.cmdline startswith "cat /etc/passwd")      output: >        Suspicious command executed (user=%user.name command=%proc.cmdline container=%container.id %container.info)      priority: WARNING      tags: [reconnaissance, execution, attack]  process_injection.yaml: |-    - rule: Detect Process Injection      desc: Detect attempts to inject code into running processes      condition>        evt.type in (ptrace, process_vm_writev) and        proc.name != "falco"      output: >        Process injection attempt detected (pid=%proc.pid user=%user.name command=%proc.cmdline container=%container.id %container.info)      priority: WARNING      tags: [process, injection]  escape_attempts.yaml: |-    - rule: Detect Container Escape Attempts      desc: Detect attempts to escape container boundaries      condition>        evt.type = execve and         container.id != host and         proc.name in (nsenter, docker, runc, lxc-start, lxc-attach, mount, kubectl, crictl)      output: >        Container escape attempt detected (user=%user.name command=%proc.cmdline container=%container.id %container.info)      priority: WARNING      tags: [container, escape]  unauthorized_privileged_command_execution.yaml: |-    - rule: Unauthorized Privileged Command Execution      desc: Detect non-root users executing privileged commands (e.g., chmod 777, sudo)      condition>        evt.type = execve and        (proc.cmdline contains "chmod 777" or proc.cmdline contains "chmod +x" or proc.cmdline contains "chmod a+x" or proc.cmdline startswith "sudo")      output: >        Unauthorized privileged command execution detected (user=%user.name command=%proc.cmdline, container=%container.id %container.info)      priority: WARNING      tags: [privilege, execution]  kernel_module_loading.yaml: |-    - rule: Kernel Module Loading      desc: Detect attempts to load kernel modules (often used in rootkits)      condition>        evt.type = execve and        proc.cmdline startswith "insmod"      output: >        Kernel module loaded (command=%proc.cmdline user=%user.name, container=%container.id %container.info)      priority: WARNING      tags: [kernel, security]  malicious_outbound_connection.yaml: |-    - rule: Detect Malicious Outbound Connection      desc: Detect processes attempting to connect to known malicious IP addresses or domains      condition>        evt.type = connect and        fd.l4proto = tcp and        not fd.sip in (127.0.0.1, ::1and        (proc.cmdline contains "malicious" or proc.cmdline contains "botnet" or proc.cmdline contains "phishing" or proc.cmdline contains "legit" or proc.cmdline contains "attack" or proc.cmdline contains "suspicious" or proc.cmdline contains ".top" or proc.cmdline contains ".xyz")      output: >        Malicious outbound connection detected (process=%proc.name command=%proc.cmdline user=%user.name destination=%fd.name, container=%container.id %container.info)      priority: WARNING      tags: [network, malicious]  monitor_ssh_login.yaml: |-    - rule: Monitor SSH Login      desc: Detect SSH login events by monitoring sshd authentication logs      condition>        evt.type = "execve" and        proc.name = "sshd" and        proc.cmdline contains "sshd:" and        not proc.cmdline contains "[listener]"      output: >        SSH login detected (user=%user.name command=%proc.cmdline destination=%fd.name, container=%container.id %container.info)      priority: WARNING      tags: [ssh, authentication, login]tolerations:  - operator: Exists

然后更新一下falco的配置即可,更新命令如下。

helm upgrade --namespace falco falco falcosecurity/falco --set tty=true -f falco_custom_rules.yaml

到这里容器的行为记录基本已完成(只需要后续根据实际情况再对规则进行优化即可),这里开始最后一个步骤搭一个板子,方便查看。

falco的输出集成了很多,可以直接将日志输出到s3 也可以输出到cloudwatch,这里因为要搭板子,cloudwatch会相对方便一些,那就直接输出到cloudwatch,修改falco配置文件,添加如下代码

falcosidekick:  enabled: true  config:    aws:      cloudwatchlogs:        loggroup: /aws/cloudtrail/falco_logs        logstream: falco_logs_stream      rolearn: ${falco_role_arn}

有日志了,然后使用terraform搭建一个板子即可,主要代码如下。

resource "aws_cloudwatch_log_group" "falco_log_group" {  name              = "/aws/cloudtrail/falco_logs"  retention_in_days = 30  # 日志保留30天(可选)  tags = {    Environment = "production"    Application = "FalcoMonitor"  }}resource "aws_cloudwatch_log_stream" "falco_log_stream" {  name           = "falco_logs_stream"  log_group_name = aws_cloudwatch_log_group.falco_log_group.name}resource "aws_cloudwatch_dashboard" "falco_dashboard" {  dashboard_name = "Falco-Security-Dashboard"  depends_on = [aws_cloudwatch_log_group.falco_log_group]  dashboard_body = jsonencode({    widgets = [      {        type  = "log"        x     = 0        y     = 0        width = 24        height = 6        properties = {          region        = "ap-northeast-1"           view          = "bar"          title         = "Falco Security Events Over Time"          query         = "SOURCE '/aws/cloudtrail/falco_logs'|filter rule in ["Sensitive file accessed"]n| stats count(*) as event_count by bin(1d), rulen| sort @timestamp desc"        }      },      {        type  = "log"        x     = 0        y     = 6        width = 24        height = 6        properties = {          region        = "ap-northeast-1"           view          = "table"          title         = "Falco Security Distribution"          query         = "SOURCE '/aws/cloudtrail/falco_logs'|filter rule in ["Sensitive file accessed"]n| stats count(*) as event_count by bin(7d), rule, output_fields.proc.cmdline, output_fields.k8s.pod.namen| sort @timestamp desc"        }      }     ]  })}

到这里就结束收工啦,这下终于稍微舒服一点点了。

AWS集群容器auditlog之falco

原文始发于微信公众号(安全无界):AWS集群容器auditlog之falco

免责声明:文章中涉及的程序(方法)可能带有攻击性,仅供安全研究与教学之用,读者将其信息做其他用途,由读者承担全部法律及连带责任,本站不承担任何法律及连带责任;如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截,联系方式见首页),望知悉。
  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2025年5月7日11:22:54
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   AWS集群容器auditlog之falcohttps://cn-sec.com/archives/4035546.html
                  免责声明:文章中涉及的程序(方法)可能带有攻击性,仅供安全研究与教学之用,读者将其信息做其他用途,由读者承担全部法律及连带责任,本站不承担任何法律及连带责任;如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截,联系方式见首页),望知悉.

发表评论

匿名网友 填写信息