在 Azure 中使用 Docker 配置自动日志上传
本文介绍在 Azure 中使用 Ubuntu 或 CentOS 上的 Docker 在 Defender for Cloud Apps 中为连续报表配置自动上传日志的方法。
先决条件
开始之前,请确保您的环境满足以下要求:
要求 | 说明 |
---|---|
操作系统 | 以下项之一: - Ubuntu 14.04、16.04、18.04 和 20.04 - CentOS 7.2 或更高版本 |
磁盘空间 | 250 GB |
CPU 核心数 | 2 |
CPU 体系结构 | Intel 64 和 AMD 64 |
RAM | 4 GB |
防火墙配置 | 在网络要求中定义 |
按性能规划日志收集器
每个日志收集器每小时可以成功处理最多 10 个数据源高达为 50 GB 的日志容量。 日志收集过程中的主要瓶颈是:
网络带宽 - 网络带宽决定日志上传速度。
虚拟机的 I/O 性能 - 确定日志收集器磁盘写入日志的速度。 日志收集器具有内置的安全机制,用于监视日志到达的速率,并将其与上载速度进行比较。 如果出现拥塞情况,日志收集器将开始删除日志文件。 如果设置通常超过每小时 50 GB,建议在多个日志收集器之间拆分流量。
如果需要 10 个以上的数据源,建议在多个日志收集器之间拆分数据源。
定义数据源
在 Microsoft Defender Portal 中,选择设置 > Cloud Apps > Cloud Discovery > 自动日志上传。
在数据源选项卡中,为要从中上传日志的每个防火墙或代理服务器创建匹配的数据源:
选择“添加数据源”。
在添加数据源对话框中,输入数据源名称,然后选择“源”和“接收器”类型。
在选择源之前,请选择查看预期日志文件示例,并将日志与预期格式进行比较。 如果您的日志文件格式与此示例不匹配,则应将您的数据源添加为其他。
若要使用未列出的网络设备,请选择其他>客户日志格式或其他(仅手动)。 有关详细信息,请参阅使用自定义日志分析程序。
注意
与安全传输协议(FTPS 和 Syslog – TLS)集成通常需要其他设置或防火墙/代理。
对其日志可用于检测网络上流量的每个防火墙和代理服务器重复此过程。
建议您为每个网络设备设置一个专用数据源,使您能够分别监视每台设备的状态以进行调查,并在每台设备由不同用户段使用的情况下,浏览每台设备的“影子 IT 发现”。
创建日志收集器
在 Microsoft Defender Portal 中,选择设置 > Cloud Apps > Cloud Discovery > 自动日志上传。
在日志收集器选项卡上,选择添加日志收集器。
在创建日志收集器对话中,输入以下详细信息:
- 日志收集器的名称
- 主机 IP 地址,即用于部署此 Docker 的计算机的专用 IP 地址。 如果有解析主机名的 DNS 服务器或等同设备,计算机名称也可以替换主机 IP 地址。
然后选择数据源框以选择要连接到收集器的数据源,然后选择更新以保存更改。 每个日志收集器可以处理多个数据源。
创建日志收集器对话框显示进一步的部署详情,包括用于导入收集器配置的命令。 例如:
选择命令旁边的复制图标,将其复制到剪贴板。
创建日志收集器对话框中显示的详细信息因所选源和接收方类型而异。 例如,如果选择了 Syslog,对话框将包含有关 syslog 侦听器正在侦听的端口的详细信息。
复制屏幕上的内容并将其保存到本地,因为您在配置日志收集器与 Defender for Cloud Apps 通信时会用到它们。
选择导出将源配置导出到 CSV 文件,该文件描述如何在设备中配置日志导出。
提示
对于首次通过 FTP 发送日志数据的用户,我们建议更改 FTP 用户的密码。 有关详细信息,请参阅更改 FTP 密码。
在 Azure 中部署计算机
此过程介绍如何使用 Ubuntu 部署计算机。 其他平台的部署步骤略有不同。
在 Azure 环境中创建新的 Ubuntu 计算机。
计算机就绪后,打开端口:
在计算机视图中,转到“网络”,并通过双击它来选择相关接口。
转到“网络安全组”并选择相关的网络安全组。
转到入站安全规则并单击添加。
添加以下规则(在“高级”模式下):
名称 目标端口范围 协议 源 目标 caslogcollector_ftp 21 TCP Your appliance's IP address's subnet
任意 caslogcollector_ftp_passive 20000-20099 TCP Your appliance's IP address's subnet
任意 caslogcollector_syslogs_tcp 601-700 TCP Your appliance's IP address's subnet
任意 caslogcollector_syslogs_udp 514-600 UDP Your appliance's IP address's subnet
任意
有关详细信息,请参阅使用安全规则。
返回到计算机并单击“连接”以打开计算机上的终端。
使用
sudo -i
更改到根权限。如果接受软件许可证条款,请运行适用于你环境的命令,卸载旧版本并安装 Docker CE:
移除旧版本的 Docker:
yum erase docker docker-engine docker.io
安装 Docker 引擎的先决条件:
yum install -y yum-utils
添加 Docker 存储库:
yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo yum makecache
安装 Docker 引擎:
yum -y install docker-ce
启动 Docker
systemctl start docker systemctl enable docker
测试 Docker 安装:
docker run hello-world
运行之前从 创建日志收集器对话框复制的命令。 例如:
(echo db3a7c73eb7e91a0db53566c50bab7ed3a755607d90bb348c875825a7d1b2fce) | docker run --name MyLogCollector -p 21:21 -p 20000-20099:20000-20099 -e "PUBLICIP='192.168.1.1'" -e "PROXY=192.168.10.1:8080" -e "CONSOLE=mod244533.us.portal.cloudappsecurity.com" -e "COLLECTOR=MyLogCollector" --security-opt apparmor:unconfined --cap-add=SYS_ADMIN --restart unless-stopped -a stdin -i mcr.microsoft.com/mcas/logcollector starter
运行以下命令验证日志收集器是否正常工作:
Docker logs <collector_name>
。 应获得的结果是:成功完成!
配置网络设备本地设置
配置网络防火墙和代理,根据对话框指示定期将日志导出到 FTP 目录的专用 Syslog 端口。 例如:
BlueCoat_HQ - Destination path: \<<machine_name>>\BlueCoat_HQ\
在 Defender for Cloud Apps 中验证部署
检查日志收集器表中的收集器状态,确保状态为“已连接”。 如果状态为“已创建”,则可能表示未完成日志收集器的连接和分析。
例如:
也可以转到“治理日志”并验证日志是否会定期上传到门户。
或者,你也可以使用以下命令从 Docker 容器中检查日志收集器状态:
- 通过使用此命令登录到容器:
docker exec -it <Container Name> bash
- 使用此命令验证日志收集器状态:
collector_status -p
如果在部署期间遇到问题,请参阅 Cloud Discovery 疑难解答。
可选 - 创建自定义连续报表
验证日志是否将上传到 Defender for Cloud Apps,并且是否已生成了报表。 验证之后,创建自定义报表。 你可以基于 Microsoft Entra 用户组创建自定义发现报表。 例如,如果要查看市场营销部门的云使用情况,则使用导入用户组功能导入市场营销组。 然后创建此组的自定义报表。 还可以基于 IP 地址标记或 IP 地址范围自定义报表。
在 Microsoft Defender 门户中,选择“设置”。 然后选择“Cloud Apps”。
在“Cloud Discovery”下,选择“连续报表”。
单击“创建报表”按钮,然后填写各字段。
在“筛选器”下,可以按数据源、导入的用户组或 IP 地址标记和范围筛选数据。
注意
在连续报表上应用筛选器时,将包括所选内容,而不是排除。 例如,如果对特定用户组应用筛选器,则报表中仅包含该用户组。
删除日志收集器
如果有现有的日志收集器,并且想要在再次部署它之前将其移除,或者只是想移除它,请运行以下命令:
docker stop <collector_name>
docker rm <collector_name>
后续步骤
如果遇到任何问题,我们可以提供帮助。 要获取产品问题的帮助或支持,请开立支持票证。
反馈
https://aka.ms/ContentUserFeedback。
即将发布:在整个 2024 年,我们将逐步淘汰作为内容反馈机制的“GitHub 问题”,并将其取代为新的反馈系统。 有关详细信息,请参阅:提交和查看相关反馈