最佳实践:Syslog、WMI、Windows日志、FTP、SFTP、SCP、NetFlo

　　最佳实践:Syslog、WMI、Windows日志、FTP、SFTP、SCP、NetFlo

　　Syslog采集

协议简介

　　在类 Unix 操作系统上，syslog 广泛用于系统日志记录。Syslog 日志消息可以记录在本地文件中或通过网络发送到接收 syslog 的服务器。网络传输采用UDP协议，端口号514。接收syslog的服务器可以将多个设备的syslog消息统一存储起来，也可以解析其中的内容进行相应的处理。常见的应用场景有网管工具、安全管理系统、日志审计系统等。

　　一个完整的syslog日志包括程序模块（Facility）、严重性（Severity或Level）、时间、主机名或IP、进程名、进程ID和生成日志的文本。在类Unix操作系统上，可以根据Facility和Severity的组合来决定需要记录什么样的日志消息，记录到哪里，是否需要发送到接收syslog的服务器等。由于由于 syslog 的简单性和灵活性，syslog 不再局限于类 Unix 主机的日志记录。任何需要记录和发送日志的场景都可以使用syslog。

　　长期以来，没有一个标准来规范syslog的格式，导致syslog的格式非常随意。在最坏的情况下，根本没有格式化，导致程序无法解析 syslog 消息，而是将其视为字符串。

　　在 2001 年定义的 RFC3164 中，描述了 BSD syslog 协议。

　　但本规范的很多内容并不是强制性的，往往是“建议”或“约定”，而且由于本规范发布时间较晚，所以很多设备并不符合或不完全符合本规范。

　　约定发送syslog的设备为Device，转发syslog的设备为Relay，接收syslog的设备为Collector。Relay本身也可以将自己的syslog发送给Collector，此时它充当了一个Device。中继也只能转发部分接收到的系统日志消息。这时，它同时充当了 Relay 和 Collector 的角色。

　　syslog 消息发送到 Collector 的 UDP 端口 514，接收方不需要响应。RFC3164 建议 Device 也使用 514 作为源端口。规定syslog消息的UDP包不能超过1024字节，全部由可打印字符组成。一条完整的syslog消息由3部分组成，分别是PRI、HEADER和MSG。大多数系统日志收录

PRI 和 MSG 部分，而 HEADER 可能不收录

。

　　系统日志服务器

　　Syslog服务器是专门部署的应用系统。它用于采集

网络中每个节点的系统日志。这些收到的日志一般称为原创

日志；然后将原创

日志根据一些格式化模板进行格式化，翻译成易于识别的格式，最后通过图形界面显示。

　　1、日志集中管理，无需登录每台设备，查询方便。

　　2. 对原创

日志进行格式化，并将其翻译成易于识别的格式，以便于解读。

　　3、可以根据日志内容设置告警规则，进行告警。

　　4. 为没有硬盘的设备提供长期存储日志的方法。

　　BSD 系统日志格式

　　10 月 9 日 22:33:20 hlfedora auditd[1787]：审计守护进程正在退出。

　　其中“”为PRI部分，“Oct 9 22:33:20 hlfedora”为HEADER部分，“auditd[1787]: the audit daemon is exiting.” 是味精部分。

　　PRI 部分

　　PRI 部分由括在尖括号中的数字组成。这个数字包括程序模块（Facility）和严重性（Severity）。这个数字是通过将 Facility 乘以 8，然后加上 Severity 得到的。取值范围（0~191）。

　　优先级=设施*8+严重性

　　也就是说，如果把这个数转换成二进制，低3位代表Severity，剩下的高位右移3位代表Facility的值。

　　设施

　　数字代码工具

　　 0 kernel messages 系统内核消息。

1 user-level messages 用户进程。

2 mail system 邮件日志。

3 system daemons 某些守护进程产生的日志。

4 security/authorization messages (note 1) 用户认证时产生的日志，如login命令、su命令。

5 messages generated internally by syslogd syslogd产生的内部消息

6 line printer subsystem 与打印机活动有关。

7 network news subsystem 网络新闻传输协议(nntp)产生的消息。

8 UUCP subsystem UUCP子系统。

9 clock daemon (note 2) 时钟守护进程

10 security/authorization messages (note 1) 用户认证时产生的日志，如login命令、su命令。

11 FTP daemon ftp守护进程

12 NTP subsystem 网络时间协议(ntp)产生的消息。

13 log audit (note 1)

14 log alert (note 1)

15 clock daemon (note 2)

16 local use 0 (local0)

17 local use 1 (local1)

18 local use 2 (local2)

19 local use 3 (local3)

20 local use 4 (local4)

21 local use 5 (local5)

22 local use 6 (local6)

23 local use 7 (local7)

　　syslog这个facility早期是为Unix操作系统定义的，只是预留了User(1), Local0~7(16~23)给其他程序使用。

　　严重性

　　数字代码严重性

　　 0 Emergency: system is unusable 紧急情况 ——造成严重错误导致系统不可用，该日志被传送到日志服务器。

1 Alert: action must be taken immediately 告警 ——警报信息，需要通知管理员，该日志被传送到日志服务器。

2 Critical: critical conditions 严重 ——严重错误信息，例如硬盘错误，可能会阻碍程序的部分功能。

3 Error: error conditions 错误 ——一般错误消息。

4 Warning: warning conditions 警告 ——所有攻击行为以及非授权访问（除通信日志外）。

5 Notice: normal but significant condition 通知 ——管理员操作，不是错误，但是可能需要处理。

6 Informational: informational messages 信息 ——通用性消息，一般用来提供有用信息。

7 Debug: debug-level messages 调试 ——调试程序产生的信息。

　　标题部分（可选）

　　HEADER 部分包括两个字段，时间和主机名（或 IP）。

　　时间紧跟在 PRI 之后，没有空格，并且必须采用“Mmm dd hh:mm:ss”格式，不包括年份。如果“日”的数字为1~9，则前面补一个空格（即月后有两个空格），而“时”、“分”、“秒”则补“0” “ 在前。月值包括：

　　一月、二月、三月、四月、五月、六月、七月、八月、九月、十月、十一月、十二月。

　　时间后跟一个空格，然后是主机名或IP地址，主机名不能收录

域名部分。

　　由于有些系统需要长期归档日志，而time字段不收录

年份，所以一些非标准的syslog格式收录

年份，例如：

　　8 月 24 日 05:34:00 CST 1987 mymachine myproc[10]: %% 是时候做点事情了。%% 成分：Mix=OK，Jelly=OK # Devices：Mixer=OK，Jelly_Injector=OK，Frier=OK # Transport：Conveyer1=OK，Conveyer2=OK # %%

　　这将导致解析器将“CST”视为主机名，并将以“1987”开头的部分视为 MSG 部分。面对这种问题，解析程序可能会做很多容错处理，或者自定义解析多种syslog格式，而不仅仅是标准格式。

　　信息部分

　　HEADER 部分后跟一个空格，然后是 MSG 部分。

　　一些系统日志没有 HEADER 部分。此时，MSG 部分紧跟在 PRI 之后，中间没有空格。

　　MSG部分分为两部分，TAG和Content。TAG 部分是可选的。

　　10 月 9 日 22:33:20 hlfedora auditd[1787]：审计守护进程正在退出。

　　auditd[1787]是TAG部分，收录

进程名和进程PID。不需要PID，此时也没有方括号。

　　有时进程PID甚至不是一个数字，比如“root-1787”，解析程序要做好容错准备。

　　TAG后面的Content部分用冒号隔开，这部分内容由应用自定义。

　　WMI

　　Windows 日志记录简介

　　Windows操作系统在其运行生命周期中会记录大量的日志信息，包括：Windows事件日志（Event Log）、Windows服务器系统IIS日志、FTP日志、Exchange Server邮件服务、MS SQL Server数据库日志等。当处理突发事件，客户需要提供可追溯性，而这些日志信息在取证和溯源中起着重要的作用。

　　Windows 事件日志文件实际上以特定的数据结构存储内容，包括有关系统、安全和应用程序的记录。每个记录事件的数据结构收录

9个元素（可以理解为数据库中的字段）：日期/时间、事件类型、用户、计算机、事件ID、来源、类别、描述、数据等信息。应急响应工程师可以使用日志取证来了解计算机上发生的特定行为。

　　Windows系统自带一个工具叫Event Viewer，可以用来查看和分析所有的Windows系统日志。运行 eventvwr 可以快速打开事件查看器。使用此工具，您可以看到系统日志分为两类：Windows 日志以及应用程序和服务日志。

　　系统内置的三个核心日志文件（System、Security、Application）的默认大小为20480KB（20MB）。当记录的事件数据超过20MB时，系统默认会优先覆盖过期的日志记录。其他应用程序和服务日志的默认最大大小为 1024KB。如果超过最大限制，将首先覆盖过期的日志记录。

　　Windows日志类型

　　系统日志

　　系统日志收录

Windows 系统组件记录的事件。例如，在启动期间未能加载驱动程序或其他系统组件将记录在系统日志中。系统组件记录的事件类型由 Windows 预先确定。

　　默认位置：%SystemRoot%\System32\Winevt\Logs\System.evtx

　　应用日志

　　应用程序日志收录

应用程序或程序记录的事件。例如，数据库程序可以在应用程序日志中记录文件错误。程序开发人员决定记录哪些事件。

　　默认位置：%SystemRoot%\System32\Winevt\Logs\Application.evtx

　　安全日志

　　安全日志收录

诸如有效和无效登录尝试之类的事件，以及与资源使用相关的事件，例如创建、打开或删除文件或其他对象。管理员可以指定在安全日志中记录哪些事件。例如，如果启用了登录审核，系统的登录尝试将记录在安全日志中。

　　默认位置：%SystemRoot%\System32\Winevt\Logs\Security.evtx

　　应用程序和服务日志

　　微软

　　Microsoft 文件夹收录

200 多个类别的 Microsoft 内置事件日志。只有部分机型默认开启记录功能，如远程桌面客户端连接、无线网络、有线网络、设备安装等相关日志。

　　默认位置：%SystemRoot%\System32\Winevt\Logs 目录中以 Microsoft-Windows 开头的文件名

　　微软办公室警报

　　Microsoft Office应用程序（包括Word/Excel/PowerPoint等）的各种警告信息，收录

了用户对文档进行操作时发生的各种行为，记录了文件名、路径等信息。

　　默认位置：%SystemRoot%\System32\Winevt\Logs\OAerts.evtx

　　Windows PowerShell

　　Windows 内置 PowerShell 应用程序的日志信息。

　　默认位置：%SystemRoot%\System32\Winevt\Logs\Windows PowerShell.evtx

　　IE浏览器

　　IE浏览器应用的日志信息默认是不开启的，需要通过组策略进行配置。

　　默认位置：%SystemRoot%\System32\Winevt\Logs\Internet Explorer.evtx

　　Windows 事件类型/级别

　　Windows事件日志中有五种事件类型，所有的事件都必须有这五种事件类型中的一种，而且只能有一种。五种事件类型分为：

　　信息：信息事件是指应用程序、驱动程序或服务成功运行的事件。警告（Warning）：警告事件指的是一个不直接、不重大，但会引发未来问题的问题。例如，当磁盘空间不足或找不到打印机时，会记录“警告”事件。错误：错误事件是指用户应该注意的重要问题。错误事件通常是指功能和数据丢失。例如，如果一个服务不能作为系统引导被加载，它就会产生一个错误事件。成功审计（Success audit）：成功审计安全访问尝试，主要是安全日志，记录用户登录/注销、对象访问、权限使用、账户管理、策略变更、详细跟踪、目录服务访问、帐户登录事件，例如所有成功登录系统的事件都被记录为“成功审核”事件。失败审计：失败的审计安全登录尝试，例如用户试图访问网络驱动器失败，将被记录为失败审计事件。Windows 事件属性

　　Windows 事件日志属性如下：

　　属性名称描述

　　事件 ID 标识特定事件类型的数字。描述的第一行通常收录

事件类型的名称。例如，6005 是事件日志服务启动时发生的事件的 ID。此类事件描述的第一行是“事件日志服务已启动”。产品支持代表可以使用事件 ID 和源来解决系统问题。

　　源 记录事件的软件，可以是程序名称（例如“SQL Server”）或系统组件或更大的程序（例如驱动程序名称）。例如，“Elnkii”表示 EtherLink II 驱动程序。

　　级别 事件严重性的分类，系统和应用程序日志中可能出现以下事件严重性级别：开始了。警告：表示如果不采取任何措施可能会影响服务器或导致更严重问题的问题。错误：表示发生了问题，这可能会影响触发事件的应用程序或组件之外的功能。Critical：表示发生故障，导致触发该事件的应用程序或组件可能无法自动恢复。安全日志中可能出现以下事件严重级别： 审核成功：表示用户权限行使成功。审核失败：表示用户提权失败。这些类别在事件查看器的正常列表视图中由符号表示。

　　用户 发生事件的用户的名称。如果事件实际上是由服务器进程引起的，则此名称是客户端 ID，如果没有模拟发生，则此名称是主 ID。安全日志条目收录

主要 ID 和模拟 ID（如果适用）。当服务器允许一个进程采用另一个进程的安全属性时，就会发生模拟

　　操作代码收录

一个数值，该数值标识在活动或应用程序引发事件时正在执行的活动中的点。例如，初始化或关闭

　　记录事件的日志的名称

　　任务类用于表示事件发布者的子组件或活动。

　　关键字 一组可用于过滤或搜索事件的类别或标签。示例包括“网络”、“安全”或“找不到资源”

　　计算机 发生事件的计算机的名称。计算机名称通常是本地计算机的名称，但也可能是转发事件的计算机名称，也可能是名称更改前的本地计算机名称

　　日期和时间 记录事件的日期和时间

　　常用的事件 ID

　　Windows 日志使用事件 ID 来识别发生的特定操作。

　　事件 ID 说明

　　1102 清理审计日志

　　4624 账号登录成功

　　4625 帐号登录失败。

　　4634 账号注销成功

　　4647 用户发起的注销

　　4672 使用超级用户（如管理员）登录。

　　4720 创建用户

　　4726 删除用户

　　4732 成员被添加到启用安全的本地组

　　4733 成员已从启用安全的本地组中删除

　　4688 创建新进程

　　

" />

　　4689 结束进程

　　每个成功的登录事件都会标记一个登录类型，不同的登录类型代表不同的方法：

　　登录类型说明

　　2 交互式登录（Interactive） 用户在本地登录。

　　3 网络（Network） 最常见的情况是连接到共享文件夹或共享打印机时。

　　4 批处理（Batch） 通常表示启动一个定时任务。

　　5 服务（Service） 每个服务都被配置为在特定的用户帐户下运行。

　　7 解锁（Unlock） 解锁屏幕保护程序。

　　8 网络明文（NetworkCleartext） 登录密码在网络上以明文形式传输，如FTP。

　　9 新凭证（NewCredentials） 使用带有/Netonly参数的RUNAS命令来运行一个程序。

　　10 远程交互，(RemoteInteractive) 通过终端服务、远程桌面或远程协助访问计算机。

　　11 CachedInteractive 以域用户身份登录，没有域控制器可用

　　WMI简介

　　WMI即Windows Managerment Instrumentation（Windows管理规范），是Windows中的一项核心管理技术。WMI 提供了一种统一的机制来访问范围广泛的 Windows 管理数据和方法。WMI 通过脚本、C++ 程序接口、.Net 类（系统管理）和命令行工具 (WMIC) 提供对这些信息的访问。WMI 的功能还包括事件、远程、查询、查看、调度和实施用户扩展等。可以理解为Windows提供了一个api来操作Windows系统。

　　简而言之，用户可以使用 WMI 来管理本地和远程计算机。

　　WMI架构

　　WMI 架构由三个主要层组成：

　　托管资源和提供者

　　托管资源是使用 WMI 公开和管理的任何逻辑或物理组件。可以使用 WMI 管理的 Windows 资源包括：计算机系统、磁盘、*敏*感*词*设备、事件日志、文件、文件夹、文件系统、网络组件、操作系统子系统、性能计数器、打印机、进程、注册表设置、安全、服务、共享、 SAM 用户和组、Active Directory、Windows Installer、Windows Driver Mode (WDM) 设备驱动程序、SNMP 管理信息库 (MIB) 数据等。

　　WMI 托管资源通过提供程序与 WMI 通信。

　　提供者是一个 COM 接口，它监视一个或多个托管对象。充当 WMI 和托管资源之间的中介。提供程序代表消费者应用程序和脚本向 WMI 管理的资源请求信息并向其发送命令。

　　WMI 基础设施

　　WMI 基础结构是 Windows 系统的一个系统组件。它收录

两个模块：WMI服务（WMI service，Winmgmt）和收录

WMI Core的WMI Repository（WMI存储库）。

　　WMI 存储库是通过 WMI 命名空间（WMI Namespace）来组织的。系统启动时，WMI服务会创建WMI命名空间，如root\default、root\cimv2、root\subscription，并会在这些命名空间中预置一些WMI类定义信息。其他命名空间是在操作系统或产品调用相关的 WMI 提供程序（WMI Provider）时创建的。简而言之，WMI 存储库是一个存储WMI 静态数据的存储空间。

　　WMI 服务充当 WMi 提供程序、管理应用程序和 WMI 存储库之间的协调器。一般来说，它是通过一个共享服务进程Svchost来完成工作的。当第一个管理应用程序启动与 WMI 命名空间的连接时，WMI 服务将启动。当管理应用程序不再调用 WMI 时，WMI 服务将关闭或进入低内存状态。如上图所示，WMI服务和上层应用程序是通过COM接口实现的。当应用程序通过接口向WMI发起请求时，WMI会判断该请求请求的是静态数据还是动态数据。

　　WMI 用户

　　WMI 使用者是与 WMI 基础结构交互的管理应用程序或脚本。管理应用程序可以通过调用 WMI 的 COM API 或 WMI 的脚本 API 来查询、枚举数据、运行提供程序方法或订阅事件。

　　WQL语句查询

　　WQL是WMI中的查询语言，全称是WMI查询语言。WQL的语法格式与SQL相同，但需要注意的是，这些语句不能直接在命令行中执行。

　　执行任何 WMI 查询时，默认命名空间 ROOT\CIMV2 被隐式使用，除非明确提供。

　　查询分为三类：

　　实例查询

　　实例查询是最常见的 WQL 查询，用于获取 WMI 对象的实例。

　　SELECT [cLASS PROPERTY NAME | *] FROM [CLASS NAME]

//查询正在运行的进程的可执行文件中包含Chrome的结果

SELECT * FROM Win32_Process WHERE Name LIKE "%chrome%"

　　事件查询

　　事件查询提供了触发事件类的报警机制。由 WMI 事件注册机制使用，例如 WMI 对象的创建、修改或删除。事件分为内部事件和外部事件。

　　SELECT [Class property name|*] from [INTRINSIC CLASS NAME] WITHIN [POLLING IINTERVAL]

SELECT [Class property name|*] FROM [EXTRINSIC CLASS NAME]

//插入时的事件查询触发器

SELECT * FROM Win32_VolumeChangeEvent WHERE EventType = 2

//交互式用户登录的事件查询触发器

SELECT * FROM __InstanceCreationEvent WITHIN 15 WHERE TargetInstance ISA 'Win32_LogonSession' AND TargetInstance.LogonType = 2

　　模式查询

　　模式查询用于检索类定义（而不是类实例）和模式关联。类提供者在注册时使用模式查询来指定它们支持的类。

　　SELECT [Class property name|*] FROM [Meta_Class

//查询所有以Win32开头的WMI类

SELECT * FROM Meta_Class WHERE __Class LIKE "Win32%"

　　文件传输协议

　　介绍

　　FTP（File Transfer Protocol）是一个多通道协议，也就是说FTP协议有多个端口与外界进行通信，工作模式包括FTP服务器和FTP客户端。默认情况下，使用 TCP 端口 20 和 21，端口 20 用于数据传输，端口 21 用于控制连接。

　　主要功能是供用户上传和下载文件。

　　工作方式

　　控制连接

　　当客户端与FTP服务器建立文件上传下载连接时，首先向服务器的TCP 21端口发起连接建立请求，FTP服务器收到客户端的请求完成连接的建立

　　数据连接

　　客户端与ftp服务器建立连接后，就可以进行数据传输了。传输文件的过程称为ftp数据连接。

　　ftp数据连接分为主动传输和被动传输两种传输方式，主动和被动均由服务器引用。

　　客户端通过任意端口N（N>1024）向服务器的ftp端口（默认为21）发送连接请求，服务器收到连接并建立命令链接。当需要传输数据时，客户端在命令链接上使用PORT命令告诉服务器，客户端生成的端口为N+1。于是服务端从20端口向客户端的N+1端口发送连接请求，建立上传下载文件的数据传输链路

　　这里要说明一下为什么客户端端口是N+1，因为当客户端与服务端建立控制连接服务时，服务端的21端口连接到N端口，N端口被占用，所以使用N+1端口与服务器通信 20端口建立数据连接服务

　　客户端通过任意端口N（N>1024）向服务器的ftp端口（默认21）发送连接请求，*敏*感*词*端口N+1。服务器接收客户端请求并建立命令链接。当需要传输数据时，服务器在命令链接上使用PASV命令告诉客户端服务器随机生成的端口P（P>1024）。然后客户端通过N+1端口向服务器的P端口发送连接请求，建立数据链路，用于传输数据。

　　被动模式和主动模式的区别在于客户端发起数据连接。在主动模式下，客户端在命令通道上建立连接后，服务器会发起与客户端的数据连接。在被动模式下，命令通道建立后，客户端向服务器发起数据连接。

　　由于这种差异，可以得出两者的优缺点。例如，主动模式有利于管理FTP服务器，因为它只需要打开21端口的“准入”和20端口的“允许”，但由于服务器连接到客户端的随机端口，客户端可能会触发防火墙，甚至直接被防火墙拦截。相反，被动模式有利于管理客户端。

　　SFTP简介

　　SFTP，称为安全文件传输协议。SSH File Transfer Protocol 的缩写，SFTP 和 FTP 的语法和功能几乎相同，但 FTP 与 SFTP 没有任何关系。SFTP是SSH的内置协议，也就是说只要启动了ssh服务器，无需额外安装就可以使用sftp（SFTP是SSH的一部分。），它的默认端口和SSH一样是22。

　　FTP和SFTP的区别 SCP简介

　　Linux scp 命令用于在Linux 之间复制文件和目录。scp是secure copy的缩写，scp是linux系统下基于ssh登录的安全远程文件复制命令。也就是说只要启动了ssh服务器，scp就可以使用，不需要额外安装。它的默认端口和 SSH 一样是 22。

　　除了在远程服务器之间复制文件的特殊情况外，scp 会首先解析命令行参数，然后打开一个到远程服务器的连接。然后可以通过这个连接连接另一个scp进程，这个进程的运行模式可以是源模式（source）也可以是汇模式（sink）。

　　来源：协议信息由文本和二进制数据混合而成。

　　普通文件：协议消息的类型、文件权限位、长度和文件名将以文本形式发送。二进制文件：在二进制数据传输之前，可能有更多的文本信息需要传输。源端会等待宿端的响应，直到响应后才会传输下一个协议文本。在发送完最后一个协议文本后，源端会发送一个大小为零的字符'\0'，表示实际文件传输的开始。当接收到文件时，*敏*感*词*将向源发送一个'\0'。

　　*敏*感*词*：来自源的每条消息和每个传输的文件都需要来自*敏*感*词*的确认和响应。sink 会返回三个确认消息：0（正常）、1（警告）或 2（严重错误，将中断连接）。消息 1 和 2 后面可以跟一个字符串和一个换行符，这将显示在 scp 源上。无论字符串是否为空，都需要换行符。

　　ssh知识

　　SSH 是一种协议标准，其目的是实现安全的远程登录和其他安全的网络服务。

　　SSH 的工作原理

　　对称加密是指加密和解密使用同一组密钥。

　　客户：

　　服务器：

　　对称加密加密强度高，不易破解。但在实际应用过程中，我们不得不面对一个棘手的问题：如何安全地保存密钥？特别是考虑到客户端数量庞大，很难保证密钥不泄露。一旦客户端密钥被盗，整个系统的安全性将不复存在。为了解决这个问题，非对称加密应运而生。非对称加密有两个密钥：“公钥”和“私钥”。

　　两种密钥的特点：公钥加密的密文只能用对应的私钥解密。从公钥推断出私钥的可能性很小

　　非对称加密方案登录流程：

　　私钥是服务器端唯一的，保证即使客户端的登录信息在网络传输过程中被盗，也没有私钥可以解密，保证了数据的安全，充分利用了非对称加密的特点。

　　这样肯定安全吗？

　　上面的过程会出现一个问题：客户端如何保证收到的公钥就是目标服务器呢？，如果攻击者中途拦截了Client的登录请求，将自己的公钥发送给它，Client就使用攻击者的公钥加密数据。攻击者收到加密信息后，用自己的私钥解密。攻击者不会窃取Client的登录信息吗？这称为中间人攻击

　　SSH 中如何解决这个问题？

　　基于密码的身份验证

　　从上面的描述可以看出，问题是如何对服务器的公钥进行认证呢？https中可以通过CA进行公证，但是SSH的publish key和private key是自己生成的，不能公证。公钥只能由客户端自己确认。通常首次登录时，系统会出现如下提示信息：

　　The authenticity of host 'ssh-server.example.com (12.18.429.21)' can't be established.

RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.

Are you sure you want to continue connecting (yes/no)?

　　上述信息说：无法确认主机（12.18.429.21）的真实性，但其公钥指纹是已知的。你想继续连接吗？

　　之所以用指纹代替密钥，是因为密钥太长（RSA算法生成的公钥有1024位），直接比较比较困难。因此，将公钥哈希生成一个128位的指纹，方便比对。

　　如果输入 yes，将出现以下消息：

　　Warning: Permanently added 'ssh-server.example.com,12.18.429.21' (RSA) to the list of known hosts.

Password: (enter password)

　　主机已经确认并添加到文件known_hosts中，接下来需要输入密码，后续流程如图1-3所示。

　　2. 基于公钥认证

　　在上面介绍的登录过程中，可以发现每次登录都要输入密码，非常麻烦。SSH提供了另一种可以避免输入密码过程的登录方式：公钥登录。过程如下：

　　SCP命令说明

　　### linux的scp命令可以在linux服务器之间复制文件和目录。

scp [参数] [原路径] [目标路径]

### 当前服务器传输文件：目录之间

scp -r /opt /mnt

### 远程服务器传输文件：远程传输

scp -r /opt root@192.168.88.77:/mnt

### 从远程服务端复制到当前客户端

scp root@192.168.88.67:/opt/zook.sh /mnt/

### 从指定的服务端复制到指定的客户端

scp -r root@192.168.88.67:/opt root@192.168.88.77:/mnt/

　　参数说明

　　-1 强制 scp 命令使用协议 ssh1

　　-2 -2 强制 scp 命令使用协议 ssh2

　　-4 -4 强制 scp 命令仅使用 IPv4 寻址

　　-6 -6 强制 scp 命令仅使用 IPv6 寻址

　　-B -B 使用批处理模式（在传输过程中不询问传输密码或短语）

　　-C -C 启用压缩。（将 -C 标志传递给 ssh，这会打开压缩）

　　-p -p 保留原文件的修改时间、访问时间和访问权限。

　　-q -q 不显示传输进度条。

　　-r -r 递归复制整个目录。

　　-v -v 以详细模式显示输出。scp 和 ssh(1) 将显示整个过程的调试信息。此信息用于调试连接、身份验证和配置问题。

　　-c -c cipher 用密码加密数据传输，这个选项会直接传给ssh。

　　-F -F ssh_config 指定一个备用的ssh配置文件，这个参数直接传递给ssh。

　　-i -i identity_file 从指定文件中读取用于传输的密钥文件，该参数直接传递给ssh。

　　-l -l limit 限制用户可以使用的带宽，单位为Kbit/s。

　　-o -o ssh_option 如果你习惯使用ssh_config(5)中的参数传递方式，

　　-P -P port 注意是大写的P，port是用来指定数据传输的端口号。

　　-S -S program 指定用于加密传输的程序。该程序必须了解 ssh(1) 选项。

　　FTP、SFTP、SCP都可以用来传输文件，主要区别是

　　网流简介

　　Netflow技术最早由Cisco的Darren Kerr和Barry Bruins于1996年发明，并于同年5月注册为美国专利，专利号为6,243,667。Netflow技术最早应用于网络设备，加速数据交换，可以同时实现对高速转发的IP数据流（Flow）的测量和统计。经过多年的技术演进，Netflow原有的数据交换加速功能已经逐步由网络设备中的专用ASIC芯片实现，对通过网络设备的IP数据流量进行统计统计的功能也更加成熟，成为公认的作为当今互联网领域IP/MPLS流量分析、统计和计费最重要的行业标准。

　　NetFlow 版本如何工作数据导入

　　NetFlow采用标准交换方式处理数据流的第一个IP包数据，并生成NetFlow缓存

　　然后执行两个功能：

　　同样的流程，直接从缓存中读取，不经过表缓存，同样进行统计

　　NetFlow 使用七个元组来区分每个 Flow：

　　SIP+DIP+SPORT+DPORT +Layer 3 协议类型 + TOS byte() + 路由器或交换机接口

　　源IP地址+源端口号+目的IP地址+目的端口号+协议类型+服务类型+输入接口

　　Netflow通过识别流的信息，将流添加到缓存中。随着流的数量增加，缓存中的条目也随之增加，因此需要一种缓存维护机制来清除一些过期的流。指定流超时的方式：

　　空闲超过指定的空闲时间长度 长连接会话强制超时 缓冲空间耗尽触发的强制超时 TCP FIN/RST 触发的超时。数据输出

　　Netflow的数据导出是一种使用UDP的主动推送机制。

　　Netflow封装的格式是header + 每个流的详细记录。

　　NetFlow 的使用

　　使用Netflow技术监控网络上的IP Flow信息

　　IP流信息可以回答用户（5W1H）的以下问题：

　　采集

的 netflow 流量信息可以帮助：

　　JMS简介

　　JMS是Java消息服务（Java Message Service）应用程序编程接口。它是 Java 平台中面向消息的中间件 (MOM) 的 API。它用于在两个应用程序之间或在分布式系统中发送消息以进行异步通信。Java Message Service 是一个与特定平台无关的 API，大多数 MOM 提供者都提供对 JMS 的支持。即java消息操作标准API。

　　发展历程

　　由于历史原因，JMS 为发送和接收提供了四组可选的接口信息。

　　所有接口都在 javax.jms 包中。

　　

" />

　　JMS的组成

　　JMS Provider（提供者）实现了JMS接口规范的消息中间件，即MQ服务器

　　JMS Producer（生产者）创建和发送JMS消息的客户端应用

　　JMS Consumer（消费者）接收和处理 JMS 消息的客户端应用程序

　　JMS Message（消息）消息由消息头、消息属性和消息体组成

　　JMS Queue（消息队列）保存消息的地方，用于点对点的消息模型

　　JMS Topic（消息主题） 保存消息的地方，以及发布和订阅的消息模型

　　JMS消息模型点对点消息模型（Point-to-Point）

　　消息提供者和消息消费者通过先进先出队列提供消息消费者，消息消费者主动从队列中拉取数据。

　　该消息模型的特点：

　　一个。每条消息只有一个消费者。一旦消息被消费，它就不再在消息队列中。

　　b. 提供者和消费者之间没有时间依赖性，也就是说，当提供者发送消息时，无论消费者是否运行，都不会影响正在发送到队列中的消息。

　　C。每条消息只会传递给一个消费者。一个队列上可能有多个消费者在*敏*感*词*，但是每个队列中的消息只能被队列中的一个消费者消费。

　　d. 有一系列消息。队列按照消息服务器将消息放入队列的顺序将消息传递给消费者。消费时，它们将从队列的头部移除（除非使用消息优先级）。

　　e. 消费者成功接收到消息后，需要成功响应队列。

　　发布/订阅消息模型（Publish/Subscribe）

　　发布-订阅模型是一种基于消息传递的模型。发布-订阅模型可以有各种不同的订阅者。临时订阅者只有在主动收听主题时才会收到消息，而持久订阅者会收听主题的所有消息，即使当前订阅者不可用且离线。

　　该消息模型的特点：

　　一个。每条消息可以有多个消费者。

　　b. 发布者和订阅者之间存在时间依赖性。对于一个主题的订阅者，它必须先创建订阅者才能消费发布者的消息，并且只能在订阅时间之后才能消费消息；

　　C。JMS 允许订阅者创建持久订阅。这样即使订阅者宕机恢复后，仍然可以接收到生产者宕机期间发布的消息。

　　d. 每条消息都被传递给多个称为订阅者的消息消费者。

　　F。消息被推送给消费者。

　　JMS API 接口

　　#### 经典 API

　　ConnectionFactory 客户端用来创建连接的管理对象；可以通过 JNDI 查找 ConnectionFactory 对象。

　　连接 客户端和 JMS 提供者之间的活动连接。

　　Session 用于发送和接收消息的单线程上下文

　　Session 创建的 Destination Queue 或 Topic 对象。

　　MessageProducer是Session创建的对象，用于向Queue或Topic发送消息。

　　MessageCosumer 是 Session 创建的对象，用于接收来自 Queue 或 Topic 的消息。

　　消息 消费者和生产者之间传输的数据。

　　MessageListener 是一个消息*敏*感*词*器。消费者在注册消息*敏*感*词*器时，当有消息到达时，会调用该接口的onMessage方法。

　　简化的API

　　简化API提供与传统API相同的消息功能，但需要的接口更少，使用更方便。简化API提供的主要接口如下：

　　ConnectionFactory：客户端用来创建连接的托管对象，传统的API也使用这个接口。

　　JMSContext：客户端和 JMS 提供者之间的活动连接，以及用于发送和接收消息的单线程上下文。

　　JMSProducer：JMSContext创建的对象，用于向Queue或Topic发送消息。

　　JMSConsumer：JMSContext创建的对象，用于接收Queue或Topic中的消息

　　在简化的 API 中，一个 JMSContext 对象封装了传统 API 中 Connection 和 Session 对象的行为。

　　JMS消息

　　JMS 消息由三部分组成：消息头、消息属性和消息体。

　　标头

　　消息头收录

消息的设置信息，如：投递目的地（topic、partation）、消息的唯一消息ID（一般JMS会自动生成，也可以由生产者主动生成）

　　发送JMSDestination消息的目的地主要有Queue和Topic，两者都是Destination的实现。

　　JMSDeliveryMode：消息传输模式，有两种模式：持久模式和非持久模式；消息服务器宕机重启后持久化消息不会丢失，非持久化消息会丢失。设置为持久化，保证消息的可靠性。Queue中的消息默认是持久化的，Topic中的消息默认是非持久化的。

　　JMSExpiration：消息的过期时间，默认永不过期。如果为MessageProducer对象设置了timeToLive属性值，或者在调用MessageProducer.send()时指定了timeToLive的值，消息将在timeToLive之后过期；如果timeToLive的值设置为0，则永不过期，消息也可以通过设置JMSExpiration属性值来指定这条消息的过期时间。消息发送后，如果消息过期后还没有被消费，就会被清空。

　　JMSPriority消息的优先级有0-9十级，0-4为普通消息，5-9为紧急消息。JMS并不要求MQ严格按照这十个优先级发送消息，但必须保证紧急消息先于普通消息到达目的地。默认消息优先级为 4 级。

　　JMSMessageID 每条消息的唯一标识，默认由MQ生成，也可以自定义。

　　JMSTimestamp 发送消息的时间。

　　与 JMSCorrelationID 关联的消息 ID 通常在需要返回消息时使用。

　　JMSReplyTo消息回复的目的地，它的值是一个Topic或Queue，由发送者设置，但接收者可以决定是否响应。

　　JMSRedelivered 消息是否重复发送。如果之前发送过消息，则需要将该属性的值设置为true；客户端可以根据该属性的值确认消息是否重复发送，避免重复处理。

　　JMSType消息类型，包括TextMessage、BytesMessage、MapMessage、StreamMessage和ObjectMessage。

　　邮件正文

　　消息传输的内容

　　消息属性

　　消息属性可以看作是对消息头的补充。消息属性按类型分为标准属性（以JMSX为前缀）、消息组件定义属性（以JMS_为前缀）、应用程序定义属性。自定义属性不应以前两个为前缀。标准的 JMSX 属性如下：

　　JMS的可靠性

　　JMS提供持久化/ack确认机制/事务保证消息的可靠性（防止消息丢失，消息重复消费）

　　坚持

　　事务

　　ACK确认机制

　　1. automatic ack消费者自动ack

　　2.手动ack需要手动提交ack信息

　　3. 对多个消费者可以签名的消息进行重复签到

　　ActiveMQ简介

　　ActiveMQ™ 是最流行的开源、多协议、基于 Java 的消息传递服务器。它支持行业标准协议，因此用户可以在广泛的语言和平台上获得客户选择的好处。可以使用 C、C++、Python、.Net 等建立连接。使用无处不在的 AMQP 协议集成您的多平台应用程序。使用 STOMP 通过 websockets 在 web 应用程序之间交换消息。

　　官方网站：

　　使用步骤

　　1 创建连接工厂

　　2 创建连接

　　3 开始连接

　　4 建立会话

　　5 创建队列

　　6 创建生产者

　　7 创建消息

　　8 发送消息

　　9 次提交

　　编写生产者类

　　import org.apache.activemq.ActiveMQConnectionFactory;

import javax.jms.*;

public class ActiveMQProducter {

public static void main(String[] args) throws Exception{

// 连接工厂

// 使用默认用户名、密码、路径

// 因为：底层实现：final String defaultURL = "tcp://" + DEFAULT_BROKER_HOST + ":" + DEFAULT_BROKER_PORT;

// 所以：路径 tcp://host:61616

//1 创建连接工厂

ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory();

//2 创建连接

Connection connection = connectionFactory.createConnection();

//3 打开连接

connection.start();

//4 创建会话

//第一个参数：是否开启事务

//第二个参数：消息是否自动确认

Session session = connection.createSession(true, Session.AUTO_ACKNOWLEDGE);

//创建队列

Queue queue = session.createQueue("hello20181119");

//5 创建生产者

MessageProducer producer = session.createProducer(queue);

//6 创建消息

Message message = session.createTextMessage("helloworld");

//7 发送消息

producer.send(message);

//8 关闭消息

session.commit();

producer.close();

session.close();

connection.close();

System.out.println("消息生产成功");

}

}

　　写消费者

　　 import org.apache.activemq.ActiveMQConnectionFactory;

import javax.jms.*;

public class ActiveMQConsumer {

public static void main(String[] args) throws Exception {

//创建连接工厂

ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory();

//创建连接

Connection connection = connectionFactory.createConnection();

//开启连接

connection.start();

//创建会话

/** 第一个参数，是否使用事务

如果设置true，操作消息队列后，必须使用 session.commit();

如果设置false，操作消息队列后，不使用session.commit();

*/

Session session = connection.createSession(true, Session.AUTO_ACKNOWLEDGE);

//创建队列

Queue queue = session.createQueue("hello20181119");

//创建消费者

MessageConsumer consumer = session.createConsumer(queue);

while(true){

//失效时间，如果10秒内没有收到新的消息，说明没有消息存在，此时可以退出当前循环

TextMessage message = (TextMessage) consumer.receive(10000);

if(message!=null){

System.out.println(message.getText());

}else {

break;

}

}

//关闭连接

session.commit();

session.close();

connection.close();

System.out.println("消费结束0");

}

}

　　总结:直击痛点，详解 K8s 日志采集最佳实践

　　作者| 元一阿里云存储服务技术专家

　　导读：上一篇主要介绍了Kubernetes日志输出的一些注意事项。日志输出的最终目的是为了统一采集

和分析。在Kubernetes中，日志采集的方式与普通虚拟机有很大不同，相对的实现难度和部署成本也略高。但是，如果使用得当，它比传统方法自动化程度更高，运维成本更低。本文是日志记录系列的第 4 篇。

　　第一篇：《K8s日志系统构建中的6个典型问题，你遇到了几个？》“

　　第二篇：《一文看懂K8s日志系统的设计与实践》

　　第三篇：《解决K8s中日志输出问题的9个技巧》

　　Kubernetes 日志采集难点

　　在 Kubernetes 中，日志采集

比传统的虚拟机和物理机要复杂得多。最根本的原因是Kubernetes屏蔽了底层的异常，提供了更细粒度的资源调度，向上提供了一个稳定动态的环境。因此，日志采集面临着更丰富、更动态的环境，需要考虑的点也更多。

　　例如：

　　采集方式：主动或被动

　　日志采集方式分为被动采集和主动推送。在K8s中，被动采集

一般分为两种方式：Sidecar和DaemonSet。主动推送包括DockerEngine推送和业务直写。

　　把它们加起来：

　　各种采集方式的详细对比如下：

　　日志输出：标准输出或文件

　　与虚拟机/物理机不同，K8s 容器提供标准输出和文件。在容器中，标准输出直接将日志输出到stdout或stderr，DockerEngine接管stdout和stderr文件描述符，收到日志后根据DockerEngine配置的LogDriver规则进行处理；日志打印到文件的方式和虚拟机/物理机基本类似，只是日志可以使用不同的存储方式，比如默认存储、EmptyDir、HostVolume、NFS等。

　　

" />

　　虽然Docker官方推荐使用Stdout打印日志，但需要注意：这个推荐是基于容器只作为简单应用的场景。在实际业务场景中，我们还是建议大家尽量使用文件。主要原因有以下几点：

　　因此，我们建议线上应用使用文件方式输出日志。stdout仅用于单功能应用或部分K8s系统/运维组件。

　　CICD 集成：日志操作员

　　Kubernetes 提供了标准化的业务部署方式。您可以通过yaml（K8s API）声明路由规则、暴露服务、挂载存储、运行服务、定义伸缩规则等，因此Kubernetes很容易与CICD系统集成。日志采集也是运维监控流程的重要环节。业务上线后的所有日志都要实时采集。

　　原来的方式是发布后手动部署日志采集逻辑。这种方式需要人工干预，违背了CICD自动化的目的。为了实现自动化，有人开始基于日志采集的API/SDK封装一个自动部署的服务。然后通过CICD的webhook来触发调用，但是这种方式的开发成本非常高。

　　在 Kubernetes 中，集成日志最标准的方式是将一个新的资源注册到 Kubernetes 系统中，并以 Operator（CRD）的形式进行管理和维护。这样CICD系统不需要额外开发，只需要在部署到Kubernetes系统时添加日志相关的配置即可。

　　Kubernetes 日志采集方案

　　早在 Kubernetes 出现之前，我们就开始针对容器环境开发日志采集

方案。随着K8s的逐渐稳定，我们开始将很多业务迁移到K8s平台上，所以我们也在之前的基础上开发了一套K8s上的日志。采集

计划。主要功能有：

　　安装日志采集组件

　　目前，该采集

解决方案已向公众开放。我们提供了Helm安装包，其中包括Logtail的DaemonSet、AliyunlogConfig的CRD语句、CRD Controller。安装后可以直接使用DaemonSet采集

和CRD配置。安装方法如下：

　　启用阿里云Kubernetes集群后，可以勾选Install，这样在创建集群时会自动安装上述组件。如果激活时没有安装，可以手动安装；如果是自建Kubernetes，无论是在阿里云上还是在其他云上还是线下，也可以使用这个采集方案。具体安装方法参考自建Kubernetes Install。

　　以上组件安装完成后，Logtail和对应的Controller会在集群中运行，但这些组件默认不会采集

任何日志，需要配置日志采集

规则来采集

指定Pod的各种日志。

　　采集规则配置：环境变量或CRD

　　除了在日志服务控制台手动配置之外，Kubernetes 还支持两种额外的配置方式：环境变量和CRD。

　　该方法易于部署，学习成本低，易于使用；但是它支持的配置规则很少，很多高级配置（比如解析方式、过滤方式、黑白名单等）都不支持，而且这种声明方式不支持修改/删除，每次修改实际上都是创建一个新的集合配置，历史采集配置需要手动清理，否则会造成资源浪费。

　　

" />

　　例如下面的例子是部署一个容器的标准输出的采集

，定义了Stdout和Stderr都需要采集

，排除环境变量中收录

COLLEXT_STDOUT_FLAG:false的容器。

　　基于CRD的配置方式，以Kubernetes标准扩展资源的方式进行管理，支持完整的增删改查配置语义，支持各种高级配置。这是我们强烈推荐的集合配置方法。

　　采集规则推荐配置方式

　　在实际应用场景中，DaemonSet 或DaemonSet 与Sidecar 结合使用。DaemonSet的优点是资源利用率高，但是存在一个问题，DaemonSet的所有Logtail共享全局配置，单个Logtail配置支持有上限。因此，无法支持具有大量应用程序的集群。

　　以上是我们给出的推荐配置方式。核心思想是：

　　实践一——中小型集群

　　绝大多数 Kubernetes 集群都是中小型的。中小型集群没有明确的定义。一般应用数量小于500个，节点数量小于1000个。没有功能清晰的Kubernetes平台运维。这个场景的应用数量不会特别多，DaemonSet可以支持所有的集合配置：

　　练习 2 - 大集群

　　一些用作PaaS平台的大型/超大型集群，一般业务在1000个以上，节点规模也在1000个以上。有专门的Kubernetes平台运维人员。这种场景下，应用数量没有限制，DaemonSet无法支持。所以必须使用Sidecar的方式。总体规划如下：

　　有一个阿里团队需要你！

　　云原生应用平台诚邀Kubernetes/容器/Serverless/应用交付技术专家（P7-P8）加盟。

　　简历投递：xining.zj AT。

　　“阿里云原生专注于微服务、Serverless、容器、Service Mesh等技术领域，关注流行的云原生技术趋势，进行云原生*敏*感*词*落地，是最懂云原生开发者的技术圈。”