精华内容
下载资源
问答
  • 2019-03-04 21:39:10

    Windows常见安全事件日志ID汇总,供大家参考,希望可以帮到大家。

    ID安全事件信息
    1100事件记录服务已关闭
    1101审计事件已被运输中断。
    1102审核日志已清除
    1104安全日志现已满
    1105事件日志自动备份
    1108事件日志记录服务遇到错误
    4608Windows正在启动
    4609Windows正在关闭
    4610本地安全机构已加载身份验证包
    4611已向本地安全机构注册了受信任的登录进程
    4612为审计消息排队分配的内部资源已经用尽,导致一些审计丢失。
    4614安全帐户管理器已加载通知包。
    4615LPC端口使用无效
    4616系统时间已更改。
    4618已发生受监视的安全事件模式
    4621管理员从CrashOnAuditFail恢复了系统
    4622本地安全机构已加载安全包。
    4624帐户已成功登录
    4625帐户无法登录
    4626用户/设备声明信息
    4627集团会员信息。
    4634帐户已注销
    4646IKE
    DoS防护模式已启动
    4647用户启动了注销
    4648使用显式凭据尝试登录
    4649检测到重播攻击
    4650建立了IPsec主模式安全关联
    4651建立了IPsec主模式安全关联
    4652IPsec主模式协商失败
    4653IPsec主模式协商失败
    4654IPsec快速模式协商失败
    4655IPsec主模式安全关联已结束
    4656请求了对象的句柄
    4657注册表值已修改
    4658对象的句柄已关闭
    4659请求删除对象的句柄
    4660对象已删除
    4661请求了对象的句柄
    4662对对象执行了操作
    4663尝试访问对象
    4664试图创建一个硬链接
    4665尝试创建应用程序客户端上下文。
    4666应用程序尝试了一个操作
    4667应用程序客户端上下文已删除
    4668应用程序已初始化
    4670对象的权限已更改
    4671应用程序试图通过TBS访问被阻止的序号
    4672分配给新登录的特权
    4673特权服务被召唤
    4674尝试对特权对象执行操作
    4675SID被过滤掉了
    4688已经创建了一个新流程
    4689一个过程已经退出
    4690尝试复制对象的句柄
    4691请求间接访问对象
    4692尝试备份数据保护主密钥
    4693尝试恢复数据保护主密钥
    4694试图保护可审计的受保护数据
    4695尝试不受保护的可审计受保护数据
    4696主要令牌已分配给进程
    4697系统中安装了一项服务
    4698已创建计划任务
    4699计划任务已删除
    4700已启用计划任务
    4701计划任务已禁用
    4702计划任务已更新
    4703令牌权已经调整
    4704已分配用户权限
    4705用户权限已被删除
    4706为域创建了新的信任
    4707已删除对域的信任
    4709IPsec服务已启动
    4710IPsec服务已禁用
    4711PAStore引擎(1%)
    4712IPsec服务遇到了潜在的严重故障
    4713Kerberos策略已更改
    4714加密数据恢复策略已更改
    4715对象的审核策略(SACL)已更改
    4716可信域信息已被修改
    4717系统安全访问权限已授予帐户
    4718系统安全访问已从帐户中删除
    4719系统审核策略已更改
    4720已创建用户帐户
    4722用户帐户已启用
    4723尝试更改帐户的密码
    4724尝试重置帐户密码
    4725用户帐户已被禁用
    4726用户帐户已删除
    4727已创建启用安全性的全局组
    4728已将成员添加到启用安全性的全局组中
    4729成员已从启用安全性的全局组中删除
    4730已删除启用安全性的全局组
    4731已创建启用安全性的本地组
    4732已将成员添加到启用安全性的本地组
    4733成员已从启用安全性的本地组中删除
    4734已删除已启用安全性的本地组
    4735已启用安全性的本地组已更改
    4737启用安全性的全局组已更改
    4738用户帐户已更改
    4739域策略已更改
    4740用户帐户已被锁定
    4741已创建计算机帐户
    4742计算机帐户已更改
    4743计算机帐户已删除
    4744已创建禁用安全性的本地组
    4745已禁用安全性的本地组已更改
    4746已将成员添加到已禁用安全性的本地组
    4747已从安全性已禁用的本地组中删除成员
    4748已删除安全性已禁用的本地组
    4749已创建一个禁用安全性的全局组
    4750已禁用安全性的全局组已更改
    4751已将成员添加到已禁用安全性的全局组中
    4752成员已从禁用安全性的全局组中删除
    4753已删除安全性已禁用的全局组
    4754已创建启用安全性的通用组
    4755启用安全性的通用组已更改
    4756已将成员添加到启用安全性的通用组中
    4757成员已从启用安全性的通用组中删除
    4758已删除启用安全性的通用组
    4759创建了一个安全禁用的通用组
    4760安全性已禁用的通用组已更改
    4761已将成员添加到已禁用安全性的通用组中
    4762成员已从禁用安全性的通用组中删除
    4763已删除安全性已禁用的通用组
    4764组类型已更改
    4765SID历史记录已添加到帐户中
    4766尝试将SID历史记录添加到帐户失败
    4767用户帐户已解锁
    4768请求了Kerberos身份验证票证(TGT)
    4769请求了Kerberos服务票证
    4770更新了Kerberos服务票证
    4771Kerberos预身份验证失败
    4772Kerberos身份验证票证请求失败
    4773Kerberos服务票证请求失败
    4774已映射帐户以进行登录
    4775无法映射帐户以进行登录
    4776域控制器尝试验证帐户的凭据
    4777域控制器无法验证帐户的凭据
    4778会话重新连接到Window
    Station
    4779会话已与Window
    Station断开连接
    4780ACL是在作为管理员组成员的帐户上设置的
    4781帐户名称已更改
    4782密码哈希帐户被访问
    4783创建了一个基本应用程序组
    4784基本应用程序组已更改
    4785成员已添加到基本应用程序组
    4786成员已从基本应用程序组中删除
    4787非成员已添加到基本应用程序组
    4788从基本应用程序组中删除了非成员。
    4789基本应用程序组已删除
    4790已创建LDAP查询组
    4791基本应用程序组已更改
    4792LDAP查询组已删除
    4793密码策略检查API已被调用
    4794尝试设置目录服务还原模式管理员密码
    4797试图查询帐户是否存在空白密码
    4798枚举了用户的本地组成员身份。
    4799已枚举启用安全性的本地组成员身份
    4800工作站已锁定
    4801工作站已解锁
    4802屏幕保护程序被调用
    4803屏幕保护程序被解雇了
    4816RPC在解密传入消息时检测到完整性违规
    4817对象的审核设置已更改。
    4818建议的中央访问策略不授予与当前中央访问策略相同的访问权限
    4819计算机上的中央访问策略已更改
    4820Kerberos票证授予票证(TGT)被拒绝,因为该设备不符合访问控制限制
    4821Kerberos服务票证被拒绝,因为用户,设备或两者都不符合访问控制限制
    4822NTLM身份验证失败,因为该帐户是受保护用户组的成员
    4823NTLM身份验证失败,因为需要访问控制限制
    4824使用DES或RC4进行Kerberos预身份验证失败,因为该帐户是受保护用户组的成员
    4825用户被拒绝访问远程桌面。默认情况下,仅当用户是Remote
    Desktop Users组或Administrators组的成员时才允许用户进行连接
    4826加载引导配置数据
    4830SID历史记录已从帐户中删除
    4864检测到名称空间冲突
    4865添加了受信任的林信息条目
    4866已删除受信任的林信息条目
    4867已修改受信任的林信息条目
    4868证书管理器拒绝了挂起的证书请求
    4869证书服务收到重新提交的证书请求
    4870证书服务撤销了证书
    4871证书服务收到发布证书吊销列表(CRL)的请求
    4872证书服务发布证书吊销列表(CRL)
    4873证书申请延期已更改
    4874一个或多个证书请求属性已更改。
    4875证书服务收到关闭请求
    4876证书服务备份已启动
    4877证书服务备份已完成
    4878证书服务还原已开始
    4879证书服务恢复已完成
    4880证书服务已启动
    4881证书服务已停止
    4882证书服务的安全权限已更改
    4883证书服务检索到存档密钥
    4884证书服务将证书导入其数据库
    4885证书服务的审核筛选器已更改
    4886证书服务收到证书请求
    4887证书服务批准了证书请求并颁发了证书
    4888证书服务拒绝了证书请求
    4889证书服务将证书请求的状态设置为挂起
    4890证书服务的证书管理器设置已更改。
    4891证书服务中的配置条目已更改
    4892证书服务的属性已更改
    4893证书服务存档密钥
    4894证书服务导入并存档了一个密钥
    4895证书服务将CA证书发布到Active
    Directory域服务
    4896已从证书数据库中删除一行或多行
    4897启用角色分离
    4898证书服务加载了一个模板
    4899证书服务模板已更新
    4900证书服务模板安全性已更新
    4902已创建每用户审核策略表
    4904尝试注册安全事件源
    4905尝试取消注册安全事件源
    4906CrashOnAuditFail值已更改
    4907对象的审核设置已更改
    4908特殊组登录表已修改
    4909TBS的本地策略设置已更改
    4910TBS的组策略设置已更改
    4911对象的资源属性已更改
    4912每用户审核策略已更改
    4913对象的中央访问策略已更改
    4928建立了Active
    Directory副本源命名上下文
    4929已删除Active
    Directory副本源命名上下文
    4930已修改Active
    Directory副本源命名上下文
    4931已修改Active
    Directory副本目标命名上下文
    4932已开始同步Active
    Directory命名上下文的副本
    4933Active
    Directory命名上下文的副本的同步已结束
    4934已复制Active
    Directory对象的属性
    4935复制失败开始
    4936复制失败结束
    4937从副本中删除了一个延迟对象
    4944Windows防火墙启动时,以下策略处于活动状态
    4945Windows防火墙启动时列出了规则
    4946已对Windows防火墙例外列表进行了更改。增加了一条规则
    4947已对Windows防火墙例外列表进行了更改。规则被修改了
    4948已对Windows防火墙例外列表进行了更改。规则已删除
    4949Windows防火墙设置已恢复为默认值
    4950Windows防火墙设置已更改
    4951规则已被忽略,因为Windows防火墙无法识别其主要版本号
    4952已忽略规则的某些部分,因为Windows防火墙无法识别其次要版本号
    4953Windows防火墙已忽略规则,因为它无法解析规则
    4954Windows防火墙组策略设置已更改。已应用新设置
    4956Windows防火墙已更改活动配置文件
    4957Windows防火墙未应用以下规则
    4958Windows防火墙未应用以下规则,因为该规则引用了此计算机上未配置的项目
    4960IPsec丢弃了未通过完整性检查的入站数据包
    4961IPsec丢弃了重放检查失败的入站数据包
    4962IPsec丢弃了重放检查失败的入站数据包
    4963IPsec丢弃了应该受到保护的入站明文数据包
    4964特殊组已分配给新登录
    4965IPsec从远程计算机收到一个包含不正确的安全参数索引(SPI)的数据包。
    4976在主模式协商期间,IPsec收到无效的协商数据包。
    4977在快速模式协商期间,IPsec收到无效的协商数据包。
    4978在扩展模式协商期间,IPsec收到无效的协商数据包。
    4979建立了IPsec主模式和扩展模式安全关联。
    4980建立了IPsec主模式和扩展模式安全关联
    4981建立了IPsec主模式和扩展模式安全关联
    4982建立了IPsec主模式和扩展模式安全关联
    4983IPsec扩展模式协商失败
    4984IPsec扩展模式协商失败
    4985交易状态已发生变化
    5024Windows防火墙服务已成功启动
    5025Windows防火墙服务已停止
    5027Windows防火墙服务无法从本地存储中检索安全策略
    5028Windows防火墙服务无法解析新的安全策略。
    5029Windows防火墙服务无法初始化驱动程序
    5030Windows防火墙服务无法启动
    5031Windows防火墙服务阻止应用程序接受网络上的传入连接。
    5032Windows防火墙无法通知用户它阻止应用程序接受网络上的传入连接
    5033Windows防火墙驱动程序已成功启动
    5034Windows防火墙驱动程序已停止
    5035Windows防火墙驱动程序无法启动
    5037Windows防火墙驱动程序检测到严重的运行时错 终止
    5038代码完整性确定文件的图像哈希无效
    5039注册表项已虚拟化。
    5040已对IPsec设置进行了更改。添加了身份验证集。
    5041已对IPsec设置进行了更改。身份验证集已修改
    5042已对IPsec设置进行了更改。身份验证集已删除
    5043已对IPsec设置进行了更改。添加了连接安全规则
    5044已对IPsec设置进行了更改。连接安全规则已修改
    5045已对IPsec设置进行了更改。连接安全规则已删除
    5046已对IPsec设置进行了更改。添加了加密集
    5047已对IPsec设置进行了更改。加密集已被修改
    5048已对IPsec设置进行了更改。加密集已删除
    5049IPsec安全关联已删除
    5050尝试使用对INetFwProfile.FirewallEnabled的调用以编程方式禁用Windows防火墙(FALSE
    5051文件已虚拟化
    5056进行了密码自检
    5057加密原语操作失败
    5058密钥文件操作
    5059密钥迁移操作
    5060验证操作失败
    5061加密操作
    5062进行了内核模式加密自检
    5063尝试了加密提供程序操作
    5064尝试了加密上下文操作
    5065尝试了加密上下文修改
    5066尝试了加密功能操作
    5067尝试了加密功能修改
    5068尝试了加密函数提供程序操作
    5069尝试了加密函数属性操作
    5070尝试了加密函数属性操作
    5071Microsoft密钥分发服务拒绝密钥访问
    5120OCSP响应程序服务已启动
    5121OCSP响应程序服务已停止
    5122OCSP响应程序服务中的配置条目已更改
    5123OCSP响应程序服务中的配置条目已更改
    5124在OCSP
    Responder Service上更新了安全设置
    5125请求已提交给OCSP
    Responder Service
    5126签名证书由OCSP
    Responder Service自动更新
    5127OCSP吊销提供商成功更新了吊销信息
    5136目录服务对象已修改
    5137已创建目录服务对象
    5138目录服务对象已取消删除
    5139已移动目录服务对象
    5140访问了网络共享对象
    5141目录服务对象已删除
    5142添加了网络共享对象。
    5143网络共享对象已被修改
    5144网络共享对象已删除。
    5145检查网络共享对象以查看是否可以向客户端授予所需的访问权限
    5146Windows筛选平台已阻止数据包
    5147限制性更强的Windows筛选平台筛选器阻止了数据包
    5148Windows过滤平台检测到DoS攻击并进入防御模式; 与此攻击相关的数据包将被丢弃。
    5149DoS攻击已经消退,正常处理正在恢复。
    5150Windows筛选平台已阻止数据包。
    5151限制性更强的Windows筛选平台筛选器阻止了数据包。
    5152Windows筛选平台阻止了数据包
    5153限制性更强的Windows筛选平台筛选器阻止了数据包
    5154Windows过滤平台允许应用程序或服务在端口上侦听传入连接
    5155Windows筛选平台已阻止应用程序或服务侦听端口上的传入连接
    5156Windows筛选平台允许连接
    5157Windows筛选平台已阻止连接
    5158Windows筛选平台允许绑定到本地端口
    5159Windows筛选平台已阻止绑定到本地端口
    5168SMB
    / SMB2的Spn检查失败。
    5169目录服务对象已修改
    5170在后台清理任务期间修改了目录服务对象
    5376已备份凭据管理器凭据
    5377Credential
    Manager凭据已从备份还原
    5378策略不允许请求的凭据委派
    5440Windows筛选平台基本筛选引擎启动时出现以下callout
    5441Windows筛选平台基本筛选引擎启动时存在以下筛选器
    5442Windows筛选平台基本筛选引擎启动时,存在以下提供程序
    5443Windows筛选平台基本筛选引擎启动时,存在以下提供程序上下文
    5444Windows筛选平台基本筛选引擎启动时,存在以下子层
    5446Windows筛选平台标注已更改
    5447Windows筛选平台筛选器已更改
    5448Windows筛选平台提供程序已更改
    5449Windows筛选平台提供程序上下文已更改
    5450Windows筛选平台子层已更改
    5451建立了IPsec快速模式安全关联
    5452IPsec快速模式安全关联已结束
    5453与远程计算机的IPsec协商失败,因为未启动IKE和AuthIP
    IPsec密钥模块(IKEEXT)服务
    5456PAStore引擎在计算机上应用了Active
    Directory存储IPsec策略
    5457PAStore引擎无法在计算机上应用Active
    Directory存储IPsec策略
    5458PAStore引擎在计算机上应用了Active
    Directory存储IPsec策略的本地缓存副本
    5459PAStore引擎无法在计算机上应用Active
    Directory存储IPsec策略的本地缓存副本
    5460PAStore引擎在计算机上应用了本地注册表存储IPsec策略
    5461PAStore引擎无法在计算机上应用本地注册表存储IPsec策略
    5462PAStore引擎无法在计算机上应用某些活动IPsec策略规则
    5463PAStore引擎轮询活动IPsec策略的更改并检测不到任何更改
    5464PAStore引擎轮询活动IPsec策略的更改,检测到更改并将其应用于IPsec服务
    5465PAStore
    Engine收到强制重新加载IPsec策略的控件并成功处理控件
    5466PAStore引擎轮询Active
    Directory IPsec策略的更改,确定无法访问Active Directory,并将使用Active Directory
    IPsec策略的缓存副本
    5467PAStore引擎轮询Active
    Directory IPsec策略的更改,确定可以访问Active Directory,并且未找到对策略的更改
    5468PAStore引擎轮询Active
    Directory IPsec策略的更改,确定可以访问Active Directory,找到策略更改并应用这些更改
    5471PAStore引擎在计算机上加载了本地存储IPsec策略
    5472PAStore引擎无法在计算机上加载本地存储IPsec策略
    5473PAStore引擎在计算机上加载了目录存储IPsec策略
    5474PAStore引擎无法在计算机上加载目录存储IPsec策略
    5477PAStore引擎无法添加快速模式过滤器
    5478IPsec服务已成功启动
    5479IPsec服务已成功关闭
    5480IPsec服务无法获取计算机上的完整网络接口列表
    5483IPsec服务无法初始化RPC服务器。无法启动IPsec服务
    5484IPsec服务遇到严重故障并已关闭
    5485IPsec服务无法在网络接口的即插即用事件上处理某些IPsec筛选器
    5632已请求对无线网络进行身份验证
    5633已请求对有线网络进行身份验证
    5712尝试了远程过程调用(RPC)
    5888COM
    +目录中的对象已被修改
    5889从COM
    +目录中删除了一个对象
    5890一个对象已添加到COM
    +目录中
    6144组策略对象中的安全策略已成功应用
    6145处理组策略对象中的安全策略时发生一个或多个错误
    6272网络策略服务器授予用户访问权限
    6273网络策略服务器拒绝访问用户
    6274网络策略服务器放弃了对用户的请求
    6275网络策略服务器放弃了用户的记帐请求
    6276网络策略服务器隔离了用户
    6277网络策略服务器授予用户访问权限,但由于主机未满足定义的健康策略而将其置于试用期
    6278网络策略服务器授予用户完全访问权限,因为主机符合定义的健康策略
    6279由于重复失败的身份验证尝试,网络策略服务器锁定了用户帐户
    6280网络策略服务器解锁了用户帐户
    6281代码完整性确定图像文件的页面哈希值无效...
    6400BranchCache:在发现内容可用性时收到格式错误的响应。
    6401BranchCache:从对等方收到无效数据。数据被丢弃。
    6402BranchCache:提供数据的托管缓存的消息格式不正确。
    6403BranchCache:托管缓存发送了对客户端消息的错误格式化响应以提供数据。
    6404BranchCache:无法使用配置的SSL证书对托管缓存进行身份验证。
    6405BranchCache:发生了事件ID%1的%2个实例。
    6406%1注册到Windows防火墙以控制以下过滤:
    64071%
    6408已注册的产品%1失败,Windows防火墙现在正在控制%2的过滤。
    6409BranchCache:无法解析服务连接点对象
    6410代码完整性确定文件不满足加载到进程中的安全性要求。这可能是由于使用共享部分或其他问题
    6416系统识别出新的外部设备。
    6417FIPS模式加密自检成功
    6418FIPS模式加密自检失败
    6419发出了禁用设备的请求
    6420设备已禁用
    6421已发出请求以启用设备
    6422设备已启用
    6423系统策略禁止安装此设备
    6424在事先被政策禁止之后,允许安装此设备
    8191最高系统定义的审计消息值
    更多相关内容
  • 网络安全应急响应----11、日志分析

    千次阅读 2022-03-16 07:01:45
    Windows日志记录着Windows系统中硬件、软件和系统问题的信息,同时还可以监视系统中发生的事件,掌握计算机在特定时间的状态,以及了解用户的各种操作行为,并且包括有关系统、安全、应用程序的记录。 Windows系统...



    一、Windows日志

    Windows日志记录着Windows系统中硬件、软件和系统问题的信息,同时还可以监视系统中发生的事件,掌握计算机在特定时间的状态,以及了解用户的各种操作行为,并且包括有关系统、安全、应用程序的记录。

    Windows系统之后,日志文件通常分为系统日志(SysEvent) 、应用程序日志(AppEvent) 和安全日志(SecEvent)3种:
    在这里插入图片描述

    系统日志:
    记录操作系统组件产生的事件,主要包括驱动程序、系统组件和应用软件的崩溃及数据。Vista/Win7/Win8/ /Win10/Server 2008/Server 2012默认位置为:C:WINDOWS\system32\winevt\Logs\System.evtx
    应用程序日志:
    包含由应用程序或系统程序记录的事件,主要记录程序运行方面的事件。Vista/Win7/Win8/ /Win10/ Server 2008/Server 2012默认位置为:C:\WINDOWS\system32\winevt\Logs\Application.evtx
    安全日志:
    记录系统的安全审计事件,包含各种类型的登录日志、对象访问日志、进程追踪日志、特权使用、账号管理、策略变更、系统事件。Vista/Win7/Win8/ /Win10/Server 2008/Server 2012默认位置为C:\WINDOWS\system32\winevt\L .ogs\Security.evtx安全日志是应急响应中需要重点关注的,可基于安全日志对系统和应用程序日志进行排查。

    在日志文件中所有事件只能拥有其中的一个事件级别,具体的事件级别如下:
    1、信息事件:指应用程序、驱动程序或服务的成功操作事件。
    2、警告事件:指不是直接的、主要的,但会导致将来问题发生的事件。如当磁盘空间不足或未找到打印机时,都会记录一个“警告”事件。
    3、错误事件:指用户应该知道的重要问题,通常是功能和数据的丢失。如一个服务不能作为系统引导被加载,就会产生一个错误事件。
    4、成功审核(Success audit):表示成功的审核安全访问尝试,主要是指安全性日志,包括用户的登录/注销、对象访问、特权使用、账户管理、策略更改、详细跟踪、目录服务访问、账户登录等事件,其中所有成功登录的系统都会被记录为“成功审核”事件。
    5、失败审核(Failure audit) :表示失败的审核安全登录尝试,如用户试图访问网络驱动器失败,该尝试就会被作为失败审核事件记录下来。
    在这里插入图片描述
    不同的事件(EVENT ID) 代表了不同的意义,一些常见的安全事件说明如下表。

    事件ID说明
    4624登录成功
    4625登录失败
    4634注销成功
    4647用户启动的注销
    4672使用超级用户(如管理员)进行登录
    4720创建用户

    每个成功登录的事件都会标记一个登录类型,不同登录类型代表不同的方式,具体说明如下表:

    登录类型描述说明
    2交互式登录(Interactive)用户在本地进行登录
    3网络( Network)最常见的情况是连接到共享文件夹或共享打印机
    4批处理( Batch)通常表明某计划任务启动
    5服务(Service)每种服务都被配置在某个特定的用户账号下运行
    7解锁(Unlock)屏保解锁
    8网络明文(Network Cleartext)登录的密码在网络上是通过明文传输的,如FTP
    9新凭证(New Credentials)使用带Netonly参数的RUNAS命令运行一个程序
    10远程交互(Remote Interactive)通过终端服务、远程桌面或远程协助访问计算机
    11缓存交互(Cached Interactive)以一个域用户登录而又没有域控制器可用

    Windows日志分析思路:攻击者在对系统进行攻击后,可能会在操作系统上添加用户,远程登录后会安装一些木马,这时候我们首先查看是否创建了用户,然后查看该用户是否成功登录,再次查看用户什么时间注销。基于这个时间段,排查系统日志,查看安装了哪些程序。可通过在事件查看器中搜索具体的事件ID,然后对攻击者行为进行判断。

    二、Linux日志

    目前新版本的Linux系统的日志系统都是rsyslog的,rsyslog是syslog的多线程增强版,其配置信息位于/etc/rsyslog.conf
    syslog主要是用来提供日志记录功能的,Linux系统内核和许多程序都会产生各种错误信息、警告信息和其他的提示信息,而syslog服务就会将这些信息写到日志文件中,方便我们后续查看分析。syslog可以根据日志的类别和优先级将日志保存到不同的文件中,日志的优先级别数字等级越小,其优先级越高,消息也越重要。

    日志优先级别英文单词中文说明
    级别英文单词中文释义说明
    0EMERG紧急导致主机系统不可用
    1ALERT警告必须马上采取措施解决问题
    2CRIT严重比较严重的情况
    3ERR错误运行出现错误
    4WARNING提醒可能影响系统功能,是需要提醒用户的重要事件
    5NOTICE注意不会影响正常功能,但是需要注意的事件
    6INFO信息一般信息
    7DEBUG调试程序或系统的调试信息等

    在Linux中常见的日志文件,默认配置下,日志文件通常保存在/var/log目录下:
    在这里插入图片描述

    日志文件说明
    /var/log/cron记录系统定时任务的相关日志
    /var/log/cups记录打印信息的日志
    /var/log/dmesg记录系统在开机时内核自检的信息,也可以使用dmesg命令直接查看
    /var/log/mailog记录邮件信息
    /var/log/message记录Linux系统中绝大多数的重要信息,在系统出现问题时,首先要检查的就是这个日志文件
    /var/log/btmp记录错误登录日志。这个文件是二进制的,不能直接使用vi查看,而要使用lastb命令
    /var/log/lastlog记录系统中所有用户最后一次登录时间的日志。这个文件是二进制的,不能直接使用vi查看,而要使用lastlog 命令
    /var/log/wtmp永久记录所有用户的登录、注销信息,同时记录系统的启动、重启、关机事件。这个文件是二进制的,不能直接使用vi查看,而要使用last命令
    /var/log/utmp记录当前已经登录的用户信息,会随着用户的登录和注销不断变化,只记录当前登录用户的信息。这个文件不能直接使用vi查看,而要使用w、who、users 等命令
    /var/log/secure或者/var/log/auth.log记录验证和授权方面的信息,只要涉及账号和密码的程序都会记录,如SSH登录、su切换用户、sudo授权,以及添加用户和修改用户密码都会记录在这个日志文件中,为了方便查阅,可以把内核信息与其他信息分开,单独保存到一个独立的日志文件中。

    在应急响应日志排查中,需要重点分析的日志:/var/run/utmp、/var/log/lastlog、/var/log/wtmp、/var/log/btmp 、/var/log/secure、软件安装日志等。

    1、/var/run/utmp日志
    记录当前已经登录的用户信息,会随着用户的登录和注销不断变化,只记录当前登录用户的信息。这个文件不能直接使用vi查看,而要使用w、who、users 等命令。
    在这里插入图片描述

    w命令:查询utmp文件,并显示当前系统中每个用户和它所运行的进程信息。
    who命令:查询utmp文件,并报告当前登录的每个用户。Who命令的默认输出包括用户名、终端类型、登录日期及远程主机。
    users命令:用单独的一行打印出当前登录的用户,每个显示的用户名对应一个登录会话。如果一个用户有不止一个登录会话,其用户名将显示相同的次数。

    2、/var/log/lastlog”日志
    记录系统中所有用户最后一次登录时间的日志。这个文件是二进制的,不能直接使用vi查看,而要使用lastlog 命令。
    在这里插入图片描述

    3、/var/log/wtmp 日志
    永久记录所有用户的登录、注销信息,同时记录系统的启动、重启、关机事件。这个文件是二进制的,不能直接使用vi查看,而要使用last命令。
    在这里插入图片描述

    4、/var/log/btmp日志
    记录错误登录日志。这个文件是二进制的,不能直接使用vi查看,而要使用lastb命令。如果该日志文件过大可以清空。
    在这里插入图片描述

    5、/var/log/auth.log 日志
    记录验证和授权方面的信息,只要涉及账号和密码的程序都会记录,如SSH登录、su切换用户、sudo授权,以及添加用户和修改用户密码都会记录在这个日志文件中,为了方便查阅,可以把内核信息与其他信息分开,单独保存到一个独立的日志文件中。
    在这里插入图片描述

    6、软件安装日志
    在应急响应过程中,软件安装日志也是需要排查的内容,如“/var/log/yum.log或“/var/log/
    yum.log-时间”中会显示yum安装的日志,“ /root/install.log"中存储了安装在系统中的软件包
    及其版本信息;“/root/ install.log.syslog”中存储了安装过程中留下的事件记录。

    7、自带的日志查看程序
    在这里插入图片描述

    我们在找到相关日志之后,信息量是非常巨大的,此时可以通过关键字的方法定位我们具体需要查找的内容,Linux下主要是利用Shell命令对安全日志进行分析。

    三、Web日志

    Web日志会记录用户对Web页面的访问操作行为。我们可以从日志中分析出在什么时间、有哪些IP地址访问了网站中的什么资源、访问是否成功等。同时Web日志也记录了攻击者的一些信息,如攻击者IP、攻击语句。通过对日志进行大量的分析就可以追踪溯源。

    3.1、IIS中间件日志

    IIS它主要用来解析ASP、ASA、CER这3种文件格式的文件,也可结合环境资源包解析PHP等。IIS是一种Web (网页)服务组件,其中包括Web服务器、FTP服务器、NNTP服务器和SMTP服务器,分别用于网页浏览、文件传输、新闻服务和邮件发送等,不同IIS日志的默认目录不一样,也可自定义。
    IIS日 志文件的格式为“ex+年份的末两位数字+月份+日期”,文件后缀是.log,如2022年3月24日的日志生成文件是“ex220324.log”,默认为按天数生成。
    IIS每条日志的格式由data、time、c-ip、cs-method、cs-uri-stem、 s-port、s-ip、cs(User-Agent)、sc-status、sc-bytes、cs-bytes组成。

    date发出请求时的日期。
    time发出请求时的时间。
    c-ip客户端IP地址。
    cs-method请求中使用的HTTP方法,如GET方法和POST方法。
    cs-uri-stemURI资源, 记录作为操作目标的统一资源标识符,即访问的页面文件。
    s-port为服务配置的服务器端口号。
    s-ip服务器的IP地址。
    cs(User-Agent)用户代理,包括客户端浏览器、操作系统等情况。
    sc-status协议状态,记录HTTP状态代码,其中,200表示成功,403表示没有权限,404表示找不到该页面。
    sc-bytes服务器发送的字节数。
    cs-bytes服务器接收的字节数。

    3.2、Apache中间件日志

    安装Apache后,Apache的配置文件“httpd.conf”中存在着两个可调配的日志文件,这两个日志文件分别是访问日志access_log/access.log和错误日志error_log/error.log。如果使用SSL服务,则可能存在ssl_access_log、ssl_error_log、ssl_request_log这3种日志文件。
    日志文件的路径根据安装方式不同,其位置也不一样,一般是在Apache安装目录的logs子目录中,日志文件路径可根据实际安装情况在Apache的配置文件中进行查找。
    在应急响应中,重点关注的是访问日志,访问日志access_ log 记录了所有对Web服务器的访问活动。
    示例如下:
    127.0.0.1 - - [08/Jun/2021:11:43:08 +0800] "GET /sqli-labs/index.html_files/freemind2html.css HTTP/1.1" 200 1335

    参数说明
    远程主机IP表示访问网站的是谁。
    空白(E- mail)为了避免用户的邮箱被垃圾邮件骚扰,使用–取代。
    空白(登录名)用于记录浏览者进行身份验证时提供的名字。
    请求时间用方括号包围,采用“公用日志格式”或“标准英文格式”。时间信息最后的+0800表示服务器所处时区位于UTC之后的8小时。
    方法资源协议表示服务器收到的是一个什么样的请求。该项信息的典型格式是“METHOD RESOURCE PROTOCOL”。
    状态代码请求是否成功,或者遇到了什么样的错误。大多数时候,这项值为200,它表示服务器已经成功响应浏览器的请求。
    发送字节数发送给客户端的总字节数,可说明传输是否被打断(该数值是否和文件的大小相同)。

    3.3、Tomcat中间件日志

    Tomcat对应日志的配置文件是Tomcat目录下的/conf/logging.properties。Tomcat默认有四类日志,分别是catalina、localhost、 manager、 host-manager。 Tomcat的日志类别也可以进行自定义。

    catalina.out表示标准输出(stdout) 和标准出错(stderr) ,所有输出到这两个位置时都会进入catalina.out,这里包含Tomcat运行自己输出的日志,以及应用里向console输出的日志。
    catalina.yyyy-MM-dd.log表示Tomcat自 己运行的一些日志,这些日志还会输出到catalina.out,但是应用向console输出的日志就不会输出到这个日志文件中,它包含Tomcat 的启动和暂停时的运行日志,和catalina.out的内容不一样。
    localhost.yyyy-MM-dd.log主要应用初始化(listener、 filter、 servlet) 未处理的异常后被Tomcat捕获而输出的日志。它也是包含Tomcat的启动和暂停的运行日志,但它没有catalina.yyy-MM-dd.log日志的记录全,只是部分日志。
    localhost_access_log.yyy-MM-dd.txt是访问Tomcat的日志,对请求地址、路径、时间、协议和状态码都有记录。
    host-manager.yyy-MM-dd.log存放Tomcat自带manager项目的日志信息。
    manager.yyyy-MM-dd.log:Tomcat manager项目专有的日志文件。

    3.4、Weblogic

    在默认配置情况下,WebLogic会有3种日志,分别是access log、Server log和domain log
    WebLogic 8.x和WebLogic 9及其以后版本目录区别如下:
    WebLogic 8.x版本:
    access log在:$MW_HOME\user_projects\domains\<domain_name>\<server_name>\access.log"
    server log在:$MW_HOME\user_ projects\domains\<domain_name>\<server_ name>\<server_name>.log" ;
    domain logz在:$MW_HOME\user_projects\domains\<domain_name>\<domain_name>.log

    WebLogic 9及其以后版本:
    access log在:$MW_HOME\user_projects\domains\<domain_name>\servers\<server_name>\logs\access.log
    server log在:$MW_HOME\user_projects\domains\<domain_name>\servers\<server_name>\logs\<server_name>.log
    domain logz在:$MW_HOME\user_projects\domains\<domain_name>\servers\<adminserver_name>\logs\<domain_name>.log

    $MW_HOMEWebLogic的安装目录;
    <domain_name>域的实际名称,是在创建域时指定的;
    <server_ name>是Server的实际名称,是在创建Server时指定的;
    <adminserver_ name>是管理服务器的实际名称,是在创建Admin Server时指定的。

    3.5、Nginx中间件日志

    Nginx中间件日志分为两种:访问日志和错误日志access.log、error.log,默认情况下,access.log日志会放在Nginx安装路径的logs目录中,如果通过yum源安装Nginx,那么access.log的默认路径为/var/log/nginx/access.log。也可以自定义日志文件的路径。

    展开全文
  • 1 服务器安全巡检 服务器基本信息 计算机名 应用类型 IP 地址 MAC地址 OS版本 硬件状态检查 系统信息灯状态 硬盘指示灯状态 系统安全检查 杀毒软件运行状态 检查杀毒软件病毒库定义是否更新 病毒和木马检查 检查...
  • 服务器安全巡检 服务器基本信息 计算机名 应用类型 IP 地址 MAC地址 OS版本 硬件状态检查 系统信息灯状态 硬盘指示灯状态 系统安全检查 杀毒软件运行状态 检查杀毒软件病毒库定义是否更新 病毒和木马检查 检查系统...
  • Web日志安全分析浅谈

    千次阅读 2018-10-18 14:07:52
    所谓有价值的地方就有江湖,网站被恶意黑客攻击的频率和网站的价值一般成正比趋势,即使网站价值相对较小,也会面对“脚本小子”的恶意测试攻击或者躺枪于各种大范围漏洞扫描器,正如安全行业的一句话:“世界上只有...

    一、为什么需要对日志进行分析?

    随着Web技术不断发展,Web被应用得越来越广泛,所谓有价值的地方就有江湖,网站被恶意黑客攻击的频率和网站的价值一般成正比趋势,即使网站价值相对较小,也会面对“脚本小子”的恶意测试攻击或者躺枪于各种大范围漏洞扫描器,正如安全行业的一句话:“世界上只有两种人,一种是知道自己被黑了的,另外一种是被黑了还不知道的”

    此时对网站的日志分析就显得特别重要,作为网站管理运维等人员如不能实时的了解服务器的安全状况,则必定会成为“被黑了还不知道的”那一类人,从而造成损失,当然还有一个场景是已经因为黑客攻击造成经济损失,此时我们也会进行日志分析等各种应急措施尽量挽回损失,简而言之日志分析最直接明显的两个目的,一为网站安全自检查,了解服务器上正在发生的安全事件,二为应急事件中的分析取证。

    二、如何进行日志分析?

    在说如何进行分析之前,我们先来了解一下Web服务器中产生的日志是什么样子.我们以Nginx容器为例:

    随机抽取一条日志:

    61.144.119.65 - - [29/May/2017:22:01:32 +0800] "GET /page/1 HTTP/1.1" 200 6403 "http://www.baidu.com" "Scrapy/1.1.2 (+http://scrapy.org)"

    作为Web开发或者运维人员,可能对图中的日志信息比较熟悉,如果对日志不那么熟悉也没关系,我们可以查看Nginx中关于日志格式的配置,查看nginx.conf配置文件:

    可以看到日志格式为:

    remote_addr - remote_user [time_local] "request" 'status body_bytes_sent "http_referer" 'http_user_agent" "$http_x_forwarded_for"';

    翻译过来即为:远程IP – 远程用户  服务器时间 请求主体 响应状态 响应体大小 请求来源 客户端信息 客户端代理IP

    通过以上信息,我们可以得知服务器会记录来自客户端的每一个请求,其中有大量来自正常用户的请求,当然也包括来自恶意攻击者的请求,那么我们如何区分正常请求和恶意攻击请求呢?站在攻击者的角度,攻击者对网站进行渗透时,其中包含大量的扫描请求和执行恶意操作的请求,而这两者在日志中都有各自的特征,如扫描请求会访问大量不存在的地址,在日志中体现则为大量的响应状态码为404,而不同的恶意请求都有各自相应的特征,如当有人对服务器进行SQL注入漏洞探测时:

                                                                                                                       (图中以"select"为关键字进行过滤)

    聪明的你肯定想到了,如果此时加上时间条件,状态码等条件就能查询到最近可能成功的SQL注入攻击了,当然实际情况中,仅仅只依靠状态码来判断攻击是否成功是不可行的,因为很多时候请求的确成功了,但并不能代表攻击也成功了,如请求一个静态页面或者图片,会产生这样一个请求:/logo.png?attack=test';select//1//from/**/1,此时请求状态码为200,但是此注入攻击并没有得到执行,实际情况中,还会有更多情况导致产生此类的噪声数据。

    抛开这类情况不谈,我们来说说在一般应急响应场景中我们分析日志的常规办法。

    在常规应急响应常见中,一般客户会有这几种被黑情况:

    1.带宽被占满,导致网站响应速度变慢,用户无法正常访问

    2.造成已知经济损失,客户被恶意转账、对账发现金额无端流失

    3.网站被篡改或者添加暗链,常见为黑客黑页、博彩链接等

    ..........

    对于这些情况,按照经验,我们会先建议对已知被黑的服务器进行断网,然后开始进行日志分析操作。假设我们面对的是一个相对初级的黑客,一般我们直接到服务器检查是否存有明显的webshell即可。检查方式也很简单:

    1.搜索最近一周被创建、更新的脚本文件
    2.根据网站所用语言,搜索对应webshell文件常见的关键字

    找到webshell后门文件后,通过查看日志中谁访问了webshell,然后得出攻击者IP,再通过IP提取出攻击者所有请求进行分析

    如果不出意外,可能我们得到类似这样一个日志结果:(为清晰呈现攻击路径,此日志为人工撰造)

    eg:

    00:01  GET http://localhost/index.php 9.9.9.9  200  [正常请求]
    00:02  GET http://localhost/index.php?id=1' 9.9.9.9 500  [疑似攻击]
    00:05  GET http://localhost/index.php?id=1' and 1=user() or ''=' 9.9.9.9  500  [确认攻击] 00:07 GET http://localhost/index.php?id=1' and 1=(select top 1 name from userinfo) or ''=' 9.9.9.9 500 [确认攻击] 00:09 GET http://localhost/index.php?id=1' and 1=(select top 1 pass from userinfo) or ''=' 9.9.9.9 500 [确认攻击] 00:10  GET http://localhost/admin/ 9.9.9.9 404 [疑似攻击]
    00:12  GET http://localhost/login.php 9.9.9.9 404 [疑似攻击] 00:13  GET http://localhost/admin.php 9.9.9.9 404 [疑似攻击]
    00:14  GET http://localhost/manager/ 9.9.9.9  404 [疑似攻击]
    00:15  GET http://localhost/admin_login.php 9.9.9.9 404 [疑似攻击]
    00:15  GET http://localhost/guanli/ 9.9.9.9 200 [疑似攻击]
    00:18  POST http://localhost/guanli/ 9.9.9.9 200 [疑似攻击]
    00:20  GET http://localhost/main.php 9.9.9.9 200 [疑似攻击]
    00:20  POST http://localhost/upload.php 9.9.9.9 200 [疑似攻击]
    00:23  POST http://localhost/webshell.php 9.9.9.9 200 [确认攻击] 00:25  POST http://localhost/webshell.php 9.9.9.9 200 [确认攻击] 00:26  POST http://localhost/webshell.php 9.9.9.9 200 [确认攻击]

    首先我们通过找到后门文件“webshell.php”,得知攻击者IP为9.9.9.9,然后提取了此IP所有请求,从这些请求可以清楚看出攻击者从00:01访问网站首页,然后使用了单引号对网站进行SQL注入探测,然后利用报错注入的方式得到了用户名和密码,随后扫描到了管理后台进入了登录进了网站后台上传了webshell文件进行了一些恶意操作。

    从以上分析我们可以得出,/index.php这个页面存在SQL注入漏洞,后台地址为/guanli.php,/upload.php可直接上传webshell
    那么很容易就能得出补救方法,修复注入漏洞、更改管理员密码、对文件上传进行限制、限制上传目录的执行权限、删除webshell。

    三、日志分析中存在的难题

    看完上一节可能大家会觉得原来日志分析这么简单,不过熟悉Web安全的人可能会知道,关于日志的安全分析如果真有如此简单那就太轻松了。其实实际情况中的日志分析,需要分析人员有大量的安全经验,即使是刚才上节中简单的日志分析,可能存在各种多变的情况导致提高我们分析溯源的难度。

    对于日志的安全分析,可能会有如下几个问题,不知道各位可否想过。

    1.日志中POST数据是不记录的,所以攻击者如果找到的漏洞点为POST请求,那么刚刚上面的注入请求就不会在日志中体现

    2.状态码虽然表示了响应状态,但是存在多种不可信情况,如服务器配置自定义状态码。
    如在我经验中,客户服务器配置网站应用所有页面状态码皆为200,用页面内容来决定响应,或者说服务器配置了302跳转,用302到一个内容为“不存在页面”(你可以尝试用curl访问http://www.baidu.com/test.php看看响应体)

    3.攻击者可能使用多个代理IP,假如我是一个恶意攻击者,为了避免日后攻击被溯源、IP被定位,会使用大量的代理IP从而增加分析的难度(淘宝上,一万代理IP才不到10块钱,就不说代理IP可以采集免费的了)
    如果一个攻击者使用了大量不同的IP进行攻击,那么使用上面的方法可能就无法进行攻击行为溯源了

    4.无恶意webshell访问记录,刚才我们采用的方法是通过“webshell”这个文件名从日志中找到恶意行为,如果分析过程中我们没有找到这么一个恶意webshell访问,又该从何入手寻找攻击者的攻击路径呢?

    5.分析过程中我们还使用恶意行为关键字来对日志进行匹配,假设攻击者避开了我们的关键字进行攻击?比如使用了各种编码,16进制、Base64等等编码,再加上攻击者使用了代理IP使我们漏掉了分析中攻击者发起的比较重要的攻击请求

    6.APT攻击,攻击者分不同时间段进行攻击,导致时间上无法对应出整个攻击行为

    7.日志数据噪声(这词我也不知道用得对不对)上文提到过,攻击者可能会使用扫描器进行大量的扫描,此时日志中存在大量扫描行为,此类行为同样会被恶意行为关键字匹配出,但是此类请求我们无法得知是否成功扫描到漏洞,可能也无法得知这些请求是扫描器发出的,扫描器可使用代理IP、可进行分时策略、可伪造客户端特征、可伪造请求来源或伪造成爬虫。此时我们从匹配出的海量恶意请求中很难得出哪些请求攻击成功了

    四、日志分析工程化之路 [探索篇]

    (上一节留下的坑我们留到最后讨论[因为我也觉得比较头疼],我们现在来讨论一点让人轻松的~)

    曾经有运维的人员问我们公司的大神,该如何分析日志?

    大神回答了三个字:“用命令”

    因为站在安全经验丰富的人角度来看,的确用命令足矣,可是对于安全经验不那么丰富的人来说,可能就不知道从何入手了。但是即使身为一个安全从业人员,我也觉得用命令太过耗时耗力(还有那么多有趣的事情和伟大的事情没做呐,当然还要节约出一点时光来嗨嗨嗨呀,难道每次分析日志我们都用命令一个个给一点点分析?)

    于是,聪明的黑客们就想到了,将这些步骤流程写成工具,让工具来帮我们分析日志,当然我也想到了,可是在我造这么一个轮子之前,我习惯性的到各大网站上先翻一翻,看看有没有人实现过,还真让我找到一些,见FAQ区域。

    我以“Web安全日志分析”为关键字,百度&Google了一番,发现并没有找到自己觉得不错的日志分析工具,难道安全行业就没有大牛写个优秀的日志分析工具出来?年轻时的我如此想到,后来我发现并非如此,而是稍微优秀一点的都跑去做产品了,于是我转战搜寻关于日志安全分析产品,通过各种方式也让我找到了几个,如下:

    1. 首先是推广做得比较好的:日志易

     

    日志易确实像它推广视频里所说的:“国内领先的海量日志搜索分析产品”

    前段时间,有客户联系到我们,说他们买了日志易的产品,但是其中对安全的监控比较缺乏,让我们能不能在日志易的基础上添加一些安全规则,建立安全告警,他们要投放到大屏幕,然后来实时监控各个服务器的安全状态。然后我就大概看了一遍日志易的产品,安全方面的分析,基本为0.

    但是日志易确实有几个优点:

    1.日志采集方面相对成熟,已经能针对多种日志格式解析并结构化,还支持用户自定义日志格的辅助解析

    2.海量日志存储相对完善,可接收来自各个客户端的日志,Saas服务成熟,能对接各大云主机

    3.搜索方面技术优秀,千亿级别数据索引只需60秒(但是,我要的安全分析啊,其他的再成熟,也始终是个不错的日志分析平台而已,我要的是安全分析、安全分析、安全分析[重要的话说三遍])

    补:(后来我发现,日志易其实有在安全方面进行分析,但是这个如图这个结果,并没有让我觉得眼前一亮,而且其中还有大量的误报)

    2. 看到一个稍微像那么回事的产品:安全易

    他们推广做得不那么好,所以在我一开始的搜索中,并没有从搜索引擎找到它,这个产品是可以免费注册并试用的,于是我迫不及待注册了一个账号进去看看,如图:

    当我试用过安全易这个产品之后,提取出了他们在关于安全方面所做的统计列表,如下:

    1.威胁时序图

    2.疑似威胁分析

    3.疑似威胁漏报分析

    4.威胁访问流量

    5.威胁流量占比

    6.境外威胁来源国家(地区)统计

    7.境内威胁来源城市统计

    8.威胁严重度

    9.威胁响应分析

    10.恶意IP

    11.恶意URL分析

    12.威胁类型分析 

    13.威胁类型分布

    14.威胁分类计数

    15.威胁来源热力图

    16.威胁总数

    17.威胁日志占比

    结果似乎挺丰富,至少比我们开始使用命令和工具得到的结果更为丰富,其实在看到这个产品之前,我们内部就尝试使用过各种方法实现过其中大部分视图结果,但是似乎还是缺少点什么 —— 攻击行为溯源,也就是我们在第二节中对日志进行简单的分析的过程,得到攻击者的整个攻击路径已经攻击者执行的恶意操作。不过想要将这个过程工程化,难度可比如上17个统计视图大多了,难在哪里?请回看第三节..
    虽然安全易的产品并没有满足我对日志分析中的想法,但是也不能说它毫无价值,相反这款产品能辅助运维人员更有效率的监控、检查服务器上的安全事件,甚至他们不用懂得太多的安全知识也能帮助企业更有效率的发现、解决安全问题

     

    五、日志分析工程化之路 [实践篇]

     

    在了解了很多分析日志的工具后,也尝试过自己折腾出一个方便分析日志的工具,以便以日常工作中的应急响应场景

    记得是在半年前左右,我的思路是这样的:

    1.首先确认日志结构

    我在Mysql中建立了如下结构的一张表来存储日志:

    日志字段

    请求时间

    服务器名称

    客户端IP

    请求方法

    请求资源

    服务器端口

    服务器IP

    浏览器信息

    响应状态码

    请求来源

    响应长度

    请求协议

    2.给Web攻击进行分类

    攻击类型表

    攻击类型名称

    危险等级

    攻击/扫描

    3.建立攻击规则表对应不同的攻击类型

    攻击规则表

    攻击规则正则表达式

    攻击发生的位置

    攻击规则对应的攻击类型ID

    此时不得不说一下当时日志是怎么入库的,不知道大家是否知道awk命令

    echo "aa bb cc" | awk -F '{print $1}'

    我们对日志采用了类似的方式,通过空格分割,然后生成出Mysql中可用的insert语句

    大约为:INSERT INTO web_log VALUES ($1,$3,$4,…),至于你说其中列数是如何对应到Mysql里的表结构的,我们当时是人工核对的,为每一个不同的日志文件进行人工对应..(可想而知这活工作量多大)

    扯回正题,当我们入库完毕后有了这么三张数据表,聪明的童鞋可能已经知道下一步要干什么的,那就是拿着安全规则正则表达式去逐条匹配日志表里面的日志

    然后得到结果:

    攻击日志ID

    攻击类型ID

    攻击规则ID

    最后我们只需要写SQL语句,就能轻松统计各个攻击类型都分别有多少攻击请求了,如图:

    最后我们思考了从各个角度来进行查询,得到了如下以下列表中的结果:

     

    1.网站受攻击次数排名

    2.网站高危请求排名

    3.网站攻击者数量排名

    4.网站受攻击页面排名

    5.可疑文件排行

    6.被攻击时间统计

    7.攻击来源分布

    8.高危攻击者排行

    9.攻击者攻击次数排行

    10.网站危险系数排行

    11.攻击者数量统计

    12.各站点攻击者数量统计

    13.各扫描器占比

    14.使用扫描器攻击者统计

    由于这是一次针对多个(70+)站点的分析,所以只需突显安全趋势即可,在此次日志分析中,还并未涉及到溯源取证

    记得当时我们是用SQL语句查询出结果,然后将数据填入Execl,然后进行图标生成,整个日志分析的过程,从日志原文件到入库到匹配到统计到出数据最后到Execl出统计图表基本都需要人工参与

    对了,上几张图瞧瞧吧

     

    (篇幅原因,其他统计图不贴上来了)

    可以看出,我们仅仅只是采用了一些安全攻击规则来对日志进行匹配就已经得到了不错的结果,虽然整个过程有点漫长,但是得到的这一份日志分析报告是具有实际意义和价值的,它可以帮我们发现哪些站点受到的攻击行为最多,那一类攻击最为频繁,哪些站点风险系数较高,网站管理和运维人员可以通过这份报告,来着重检查危险系数较高的请求和危险系数较高的站点,从而大大提高效率。

    但是日志分析工(lan)程(duo)化(hua)之路到此结束了吗?不,远远没有。

     

    六、日志分析工程化之路 [进阶篇]

     

    有没有觉得像上面那样折腾太累了,虽然确实能得到一个还不错的结果。于是开始找寻一个较好的日志分析方案,最后采用了开源日志分析平台ELK,ELK分别为:

    Elasticsearch 开源分布式搜索引擎

    Logstash 对日志进行收集、过滤并存储到Elasticsearch或其他数据库

    Kibana 对日志分析友好的Web界面,可对Elasticsearch中的数据进行汇总、分析、查询

    因为它开源、免费、高可配,所以是很多初创企业作为日志分析使用率最高的日志分析平台

    当理清楚ELK的搭建方式和使用流程后,我们用ELK实现了一遍第五节中的日志分析

    流程大概如下:

    1.编写Logstash配置文件

    2.将攻击规则应用于logstash的filter插件

    3.利用载入了安全分析插件后的logstash进行日志导入

    4.查询分析结果

    5.利用Kibana进行统计、可视化

    到这里,所得结果已经比“HanSight瀚思”安全易这个产品的结果更为丰富了~ ,但是日志安全分析之路远远没有结束,最重要也最具有价值的那部分还没有得到实现 —— 攻击行为溯源。

    七、日志安全分析攻击溯源之路 [探索篇]

    故技重施,我搜寻了和攻击溯源有关的相关信息,发现国内基本寥寥无几。

    最后发现其实现难度较大,倒是听说过某些甲方内部安全团队有尝试实现过,但至今未要到产品实现的效果图,不过最后倒是被我找到某安全公司有一个类似的产品,虽然是以硬件方式实现的流量监控,从而获取到日志进行分析。这里提一句,通过硬件方式获取流量从而可以记录并分析整个请求包和响应包,这可比从日志文件中拿到的信息全面多了,从而将日志溯源分析降低了一个难度,不过某些优秀的分析思路还是值得学习的,先上几张产品效果图:

    (图1)

    (图2)

    (图3)

    由于图1中的分析已经实现,这里暂且不谈。我们看图2中的攻击溯源,这好像正是我们需要的效果。
    第一个信息不难理解,三个中国的IP发起了含有攻击特征的请求,他们的客户端信息(userAgent)分别为Linux/Win7/MacOs

    第二个信息据我经验应该是他们内部有一个IP库,每个IP是否为代理IP,所处什么机房都有相应的记录,或者调用了IP位置查询接口,从而判断IP是否为代理IP、机房IP、个人上网出口IP,继而判定未使用跳板主机

    第三个信息为攻击者第一次访问站点,从图中却到看到jsky的字样,竭思为一款Web漏洞扫描器,而根据我的经验来看,扫描器第一个请求不应该是访问一个txt文件而是应该请求主页从而判断网站是否能正常请求,所以这里我猜测应该是从时间链或者IP上断掉的线索,从而导致对攻击者的入站第一个请求误判,不过误判入站请求这个倒是对分析的影响不是特别大

    第四、第五、第六个信息应该分别为访问了后台地址、对后台进行了爆破攻击、使用常见漏洞或CMS等通用漏洞对应用进行了攻击,除了后台访问成功之外,爆破攻击、应用攻击均为成功。因为此攻击溯源分析通过硬件方式实现,猜想应该是判断了响应体中是否包含各种登录成功的迹象,而应用攻击则判断响应中是否存在关于数据库、服务器的敏感信息,如不存在则视为攻击未成功

    第七个信息展示出了攻击者总共发起了79166次注入攻击,且对服务器已经造成了影响,但是从效果图中看来,此溯源并没有具体展示对哪台哪个应用攻击成功造成了影响,故断定为综合判断,可能存在一定误报率,判断方式可通过响应体中的敏感信息、响应平均大小等方式判断已攻击成功的概率

    对于图3中的效果,开始觉得结果丰富,意义深远,但是细看发现结果丰富大多来源于相关数据丰富。

    综上所诉,此攻击溯源产品利用了两个优势得出了比常规分析日志方法中更有价值的结果

    1.请求和响应数据完整,能进行更大维度的日志分析

    2.安全关联库较多,能关联出更为丰富的信息

    如下为产品中引用的关联库:

    1. 全球IPV4信息知识库,包括该IP对应的国家地区、对应的操作系统详情、浏览器信息、电话、域名等等。并对全球IP地址实时监控,通过开放的端口、协议以及其历史记录,作为数据模型进行预处理。

    2. 全球虚拟空间商的IP地址库,如果访问者属于该范围内,则初步可以判定为跳板IP。

    3. 全球域名库,包括两亿多个域名的详细信息,并且实时监控域名动向,包括域名对应的IP地址和端口变化情况,打造即时的基于域名与IP的新型判断技术,通过该方式可以初步判断是否为C&C服务器、黑客跳板服务器。

    4. 黑客互联网信息库,全球部署了几千台蜜罐系统,实时收集互联网上全球黑客动向。

    5.独有的黑客IP库,对黑客经常登录的网站进行监控、对全球的恶意IP实时获取。

    6. 黑客工具指纹库,收集了所有公开的(部分私有的)黑客工具指纹,当攻击者对网站进行攻击时,可以根据使用的黑客工具对黑客的地区、组织做初步判断。

    7. 黑客攻击手法库,收集了大量黑客攻击手法,以此来定位对应的黑客或组织。

    8. 其他互联网安全厂商资源,该系统会充分利用互联网各种资源,比如联动50余款杀毒软件,共同检测服务器木马程序。

    9. 永久记录黑客攻击的所有日志,为攻击取证溯源提供详细依据。

     

    八、日志安全分析攻击溯源之路 [构想篇]

     

    我也希望我在这一节能写出关于溯源的实践篇,然而事实是到目前为止,我也没有太好的办法来解决在传统日志分析中第三节中提到的问题,期间也做过一些尝试,得到的结果并不怎么尽人意,当然之后也会不断尝试利用优秀的思路来尝试进行攻击溯源分析。由于还并未很好的实现攻击溯源分析,下面只讨论一些可行思路(部分思路来源于行业大牛、国内外论文资料)

    通过前几节,我们已经知道了我们分析日志的目的,攻击溯源的目的和其意义与价值

    这里简短概括一下:

    一、实时监控正在发生的安全事件、安全趋势

    二、还原攻击者行为

          1.从何时开始攻击

          2.攻击所利用的工具、手法、漏洞

          3.攻击是否成功,是否已经造成损失和危害

    三、发现风险、捕获漏洞、修复漏洞、恶意行为取证

    在传统日志分析过程中,想要实现以上效果,那么就不得不面对第三节中提到的问题,这里回顾一下:

    1.POST数据不记录导致分析结果不准确

    其实在服务器端,运维管理人员可自行配置记录POST数据,但是这里说的是默认不记录的情况,所以配置记录POST数据暂且不提。

    其实我觉得要从不完整的信息中,分析得到一个肯定的答案,我觉得这从逻辑上就不可行。但是我们可以折中实现,尽量向肯定的答案靠近,即使得到一个90%肯定的答案,那也合乎我们想要的结果。

    在常规日志分析中,虽然POST数据不被记录,但是这些“不完整信息”依然能给我们我们提供线索。

    如通过响应大小、响应时间、前后请求关联、POST地址词义分析、状态码等等依然能为我们的分析提供依据,如某个请求在日志中的出现次数占访问总数30%以上,且响应大小平均值为2kb,突然某一天这个请求的响应值为10kb,且发起请求的IP曾被攻击特征匹配出过,那么可以80%的怀疑此请求可能存在异常,如攻击者使用了联合注入查询了大量数据到页面,当然这里只是举例,实际情况可能存在误报。

    2.状态码不可信

    对于那些自行设置响应状态的,明明404却302的,明明500却要200的(~~我能说这种我想拖出去打死么- -,~~) PS:其实设置自定义状态码是别人的正常需求。

     因为状态码不可信了,我们必须从其他方面入手来获取可信线索,虽然要付出点代价。

     我的思路是,对于不同的攻击行为,我们应该定义不同的响应规则,如攻击规则命中的为网站备份文件,那么应该判断请求大小必须超过1k-5k,如攻击者发起/wwwroot.rar这种攻击请求,按照常理如果状态码为200,那么本来应该被定性为成功的攻击行为,但是因为状态码不可信,我们可以转而通过响应大小来判断,因为按照常规逻辑,备份文件一般都不止只有几kb大小,如攻击者发起Bool注入请求则应该通过判断多个注入攻击请求的规律,Bool注入通常页面是一大一小一大一小这种规律,如攻击者发起联合注入攻击,则页面响应大小会异常于多部分正常页面响应大小,如果攻击者发起延时注入请求,则页面响应时间则会和延时注入payload中的响应相近,但是这需要分析攻击payload并提取其中的延时秒数来和日志中的响应时间进行比较误差值,当然,这里只是尝试思路,实际可行率有待实践。

    3.攻击者使用多个代理IP导致无法构成整个攻击路径

    假设同一攻击者发起的每个请求都来自不同的IP,此时即使攻击规则命中了攻击者所有请求,也无法还原攻击者的攻击路径,此时我们只能另寻他法。虽然攻击者使用了多个IP,但是假设攻击者不足够心细,此时你可以通过攻击时间段、请求频率、客户端信息(Ua)、攻击手法、攻击工具(请求主体和请求来源和客户端信息中可能暴露工具特征。如sqlmap注入时留下的referer)

    4.无恶意webshell访问记录

    常规分析中,我们通过找到后门文件,从而利用这一线索得知攻击者IP继而得知攻击者所有请求,但是如果我们并没有找到webshell,又该用什么作为分析的入口线索呢?

    利用尽可能全面的攻击规则对日志进行匹配,通过IP分组聚合,提取发起过攻击请求的所有IP,再通过得到的IP反查所有请求,再配合其他方法检测提取出的所有请求中的可疑请求

    5.编码避开关键字匹配

    关于编码、加密问题,我也曾尝试过,但是实际最后发现除了URL编码以外,其他的编码是无法随意使用的,因为一个被加密或编码后的请求,服务器是无法正确接收和处理的,除非应用本身请求就是加密或编码的。且一般加密或编码出现在日志里通常都是配合其他函数实现的,如Char()、toHexString()、Ascii()..

    6.APT分时段攻击

    如果同一攻击者的攻击行为分别来源不同的时间,比如攻击者花一周时间进行“踩点”,然后他就停止了行为,过了一周后再继续利用所得信息进行攻击行为,此时因为行为链被断开了一周,我们可能无法很明显的通过时间维度来定位攻击者的攻击路径。我目前的想法是,给攻击力路径定义模型,就拿在前面讲到的常规日志分析举例,那么攻击路径模型可定义为:访问主页>探测注入>利用注入>扫描后台>进入后台>上传webshell>通过webshell执行恶意操作。

    其中每一个都可以理解一种行为,而每种行为都有相应的特征或者规则。比如主页链接一般在日志中占比较大,且通常路径为index.html、index.php、index.aspx,那么符合这两个规则则视为访问主页,而在探测注入行为中,一般会出现探测的payload,如时间注入会匹配以下规则:

    .(BENCHMARK(.)).*.(WAITFOR.DELAY).*.(SLEEP(.).*.(THENDBMS_PIPE.RECEIVE_MESSAGE).

    Bool注入

    .*and.*(>|=|<).*
    .*or.*(>|=|<).*
    .*xor.*(>|=|<).*

    联合注入:

    .*(order.*by).*
    .*(union.*select).*
    .*(union.*all.*select).*
    .*(union.*select.*from).*

    显错注入:

    .*('|"|\)).*
    .*(extractvalue\(.*\)).*
    .*(floor\(.*\)).*
    .*(updatexml\(.*\)).*

    利用注入则会体现出更完整,带有目的性的攻击请求,我们以同理制定规则即可,如查询当前数据库名、查询版本信息、查询数据库表名、列名则会出现database、version、table_name、column_nam(不同数据库存在不同差异,这里仅举例)。

    扫描后台则会产生大量的404请求,且请求较为频繁,请求特征通常为/admin、/guanli、/login.php、/administrator。

    对于是否进入后台,我认为假如一个疑似后台访问的链接被频繁请求,且每次响应大小都不相同,我则认为这是已经进入了后台,但是也有可能是网站管理员正在后台进行操作的,这暂且不谈。

    关于上传webshell,这个比较难得到较准确的信息,因为我们没有POST数据,无法知道上传的内容是什么,但是我们可以通过反推法,先利用webshell访问特征进行匹配,找到可能为webshell的访问地址,然后以时间为条件往前匹配包含上传特征的请求,如果成功匹配到了存在上传特征,那么可将其视为攻击路径中的“上传webshell”行为。

    至于“通过webshell执行恶意操作”,可以简单定义为webshell地址被请求多次,且响应大小大多数都不相同,当我们对以上每种行为都建立对应的规则之后,然后按照攻击路径模型到日志中进行匹配,攻击路径模型可能有多个

    这是一个相对常规的攻击路径:

    访问主页>探测注入>利用注入>扫描后台>进入后台>上传webshell>通过webshell执行恶意操作

    可能还会有:

    访问主页>爬虫特征>扫描敏感信息>扫描识别CMS特征>利用已知组件漏洞进行攻击>执行恶意代码>获取webshell>通过webshell执行恶意操作。

    扫描路径>扫描到后台>疑似进入后台>上传webshell>通过webshell执行恶意操作。

    ..

    当我们用多个类似这样的攻击路径模型对日志进行匹配时,可能在同一个模型中可能会命中多次相同的行为特征,此时我需要做一个排查工作,通过IP、客户端特征、攻击手法、攻击payload相似度等等进行排除掉非同一攻击者的行为,尽可能得到一条准确的攻击路径。

    我们通过一整个攻击路径来定义攻击,从而即使攻击者分时段进行攻击,行为也会被列入到攻击路径中

    通过这样方式,也许能实现自动化展示出攻击者的攻击路径,但是具体可行率、准确度还有待进一步实践后确认。

    7.日志噪声数据

    通常,除了攻击者恶意构造的攻击之外,日志中还包含大量的扫描器发出的请求,此类请求同样包含一些攻击特征,但是多半都为无效的攻击,那么我们如何从大量的扫描攻击请求中判断出哪些请求较为可疑,可能攻击已经成功呢?我所认为的方法目前有两种,一种是给每种攻击方法定义成功的特征,如延时注入可通过判断日志中的响应时间,联合注入可通过与正常请求比较响应大小,Bool注入可通过页面响应大小的规律,当然实际情况中,这种做法得到的结果可能是存在误报的。第二种办法就是通过二次请求,通过重放攻击者的请求,定义攻击payload可能会返回的结果,通过重放攻击请求获取响应之后进行判断,其实这里已经类似扫描器,只是攻击请求来自于日志,这种方法可能对服务器造成二次伤害,一般情况下不可取,且已经脱离日志分析的范畴。

    九、日志安全分析之更好的选择

    回到那个最基本的问题,如何从日志中区分正常请求和攻击请求?

    可能做过安全的人都会想到:用关键字匹配呀。

    对,关键字匹配,因为这的确是简单直接可见的办法,用我们已知的安全知识,把每一种攻击手法定义出对应的攻击规则,然而对日志进行匹配,但Web技术更新速度飞快,可能某一天就出现了规则之外的攻击手法,导致我们无法从日志中分析出这些行为。

    其实从接触日志分析这个领域开始,我就想过一个问题?有没有一种算法,可以自动的计算哪些是正常的,哪些是不正常的呢?然而思索很久,也尝试过一些办法,比如尝试过使用统计,按照请求的相似度进行归并,统计出一些“冷门”请求,后来发现其实这样做虽然有点效果,但是还是会漏掉很多请求,且存在大量无用请求。
    后来又思索了一种办法,能不能对用户的网站产生的请求建立一个白名单,然后不在白名单内的请求皆为异常请求。这种做法效果倒是更好了一点,可是如何自动化建立白名单又成为了一个问题?如果我们手动对网站请求建立一个单独的白名单,那么一旦站点较多,建立白名单这个工作量又会巨大,但是如果只有单个站点,手工建立这样一个白名单是有意义的,因为这样就能统计所有的异常请求甚至未知的攻击行为。

    后来我发现其实我最初的想法其实是一个正确的思路,用统计的方法来区分正常和异常请求,只不过我在最开始实现的时候认为的是:某个URL被访问的次数越少,那么次请求为可疑。

    更好的思路是:正常总是基本相似 异常却各有各的异常(来源:http://www.91ri.org/16614.html

    文中关于此理论已经讲得很详细,这里简单描述一下实现方法:

    搜集大量正常请求,为每个请求的所有参数的值定义正常模型
          通过Waf或者攻击规则来剔除所有发起过攻击请求的IP,从而得到所有来自用户的正常请求,将每个正常请求构造出对应的正常模型,比如:
          http://test.com/index.php?id=123
          http://test.com/index.php?id=124
          http://test.com/index.php?id=125
          那么关于此请求的正常模型则为 [N,N,N],不匹配此模型的请求则为异常请求。

    当对日志中的请求建立完正常的模型,通过正常模型来匹配找出所有不符合模型的请求时,发现效果的确不错,漏报较少,不过实践中发现另一个问题,那便是数据的清洗,我们能否建立对应的模型,取决于对日志数据的理解,如果在数据前期提取时,我们无法准确的提取哪些是请求地址那些为请求参数可能无法对某个请求建立正常模型

    关于此理论已经有人写出了Demo实现,地址:https://github.com/SparkSharly/Sharly

     

    十、日志安全分析总结问答

    1.日志分析有哪些用途?

    感知可能正在发生的攻击,从而规避存在的安全风险

    应急响应,还原攻击者的攻击路径,从而挽回已经造成的损失

    分析安全趋势,从较大的角度观察攻击者更“关心”哪些系统

    分析安全漏洞,发现已知或位置攻击方法,从日志中发现应用0day、Nday

    ..

    2.有哪些方法可找出日志中的攻击行为?

    攻击规则匹配,通过正则匹配日志中的攻击请求

    统计方法,统计请求出现次数,次数少于同类请求平均次数则为异常请求

    白名单模式,为正常请求建立白名单,不在名单范围内则为异常请求

    HMM模型,类似于白名单,不同点在于可对正常请求自动化建立模型,从而通过正常模型找出不匹配者则为异常请求

    3.日志分析有哪些商业和非商业工具/平台?

    工具:

    LogForensics 腾讯实验室

    https://security.tencent.com/index.php/opensource/detail/15

    北风飘然@金乌网络安全实验室

    http://www.freebuf.com/sectool/126698.html

    网络ID为piaox的安全从业人员:

    http://www.freebuf.com/sectool/110644.html

    网络ID:SecSky

    http://www.freebuf.com/sectool/8982.html

    网络ID:鬼魅羊羔    

    http://www.freebuf.com/articles/web/96675.html

     

    平台(商业项目):

    Splunk  >> 机器数据引擎 

    赛克蓝德 >> SeciLog

    优特捷信息技术 >> 日志易

    HanSight瀚思 >> 安全易

    百泉众合数据科技 >>LogInsight

    江南天安 >> 彩虹WEB攻击溯源平台

    开源项目:

    elk :   https://www.elastic.co

    scribe :https://github.com/facebook/scribe

    chukwa:http://incubator.apache.org/chukwa/

    kafka:http://sna-projects.com/kafka/

    Flume:https://github.com/cloudera/flume/

    4.有哪些方法适合分析攻击是否成功?

    Kill Chain Model

     

    十一、扩展阅读

    http://netsecurity.51cto.com/art/201506/478622.htm

    http://www.freebuf.com/articles/web/86406.html

    https://wenku.baidu.com/view/f41356138bd63186bdebbca8.html

    http://www.freebuf.com/articles/web/96675.html

    http://dongxicheng.org/search-engine/log-systems/

    http://www.361way.com/scribe-chukwa-kafka-flume/4119.html

    http://www.jianshu.com/p/942d1beb7fdd

    https://xianzhi.aliyun.com/forum/attachment/big_size/WAF%E6%98%AF%E6%97%B6%E5%80%99%E8%B7%9F%E6%AD%A3%E5%88%99%E8%A1%A8%E8%BE%BE%E5%BC%8F%E8%AF%B4%E5%86%8D%E8%A7%81.pdf

    http://techshow.ctrip.com/archives/1042.html

    http://www.ixueshu.com/document/b33cf4addda2a27e318947a18e7f9386.html

    http://www.ixueshu.com/document/602ef355997f4aec.html

    http://xueshu.baidu.com/s?wd=paperuri%3A%288b49643ad2a4ba7ea2d4cf46e366188d%29&filter=sc_long_sign&tn=SE_xueshusource_2kduw22v&sc_vurl=http%3A%2F%2Fwww.doc88.com%2Fp-0157694572004.html&ie=utf-8&sc_us=16365123920770356600    ;

    十二、结束语

    在安全领域中,防护为一个体系,感知风险和应急响应仅仅只算安全体系中的两个环节。而想要尽可能更好的实现这两个环节,单凭从日志中分析数据是远远不够的。

    至于未来或许我们可以将日志分析和Waf、RASP、等其他安全产品进行联动,还可以将Web日志、系统日志、数据库日志等各种其他日志进行关联从而分析更准确、更具有价值的信息。

    日志分析本质为数据分析,而数据驱动安全必定是未来的趋势。

    关于日志分析还有很远的路要走,目前国内还并没有发现较为优秀的产品,日志数据中存在的价值还有待进一步挖掘。

     

     

     

     

     

     

     

     

     

     

     

    展开全文
  • PAGE 2 PAGE 1 服务器安全巡检 服务器基本信息 计算机名 应用类型 IP地址 MAC地址 OS版本 硬件状态检查 系统信息灯状态 硬盘指示灯状态 系统安全检查 杀毒软件运行状态 检查杀毒软件病毒库定义是否更新 病毒和木马...
  • 系统已经安装了最新的安全补丁二、本地安全策略检查选项及风险等级1.引入库2.读入数据总结 一、windows基线检查选项及风险等级 1.系统已安装最新的service pack Windows 10 的后续服务更新采用update,从win8开始...

    提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档


    注意

    1.实验环境

    以下设置为windows 信息安全等级保护(等保2.0)安全配置核查,需要在windows server或windows pro操作系统中进行。本文环境为windows server2012虚拟机和windows10 专业版。

    2.准备设置

    ①输入如下命令,按回车或点击确定按钮,就会打开桌面图标设置功能。
    rundll32.exe shell32.dll,Control_RunDLL desk.cpl,,0
    在这里插入图片描述
    ②在桌面图标设置功能中,勾选的图标就会显示在桌面上,没有勾选的图标则不会显示在桌面上,完成后如图所示:
    在这里插入图片描述

    一、windows基线检查

    1.系统已安装最新的service pack

    2.系统已经安装了最新的安全补丁

    打开控制面板->系统和安全->windows更新,检车是否有可用更新。
    在这里插入图片描述

    二、本地安全策略检查

    1.密码策略

    打开开始菜单,选择应用“管理工具”,选择“本地安全策略”,左侧"安全设置"栏中依次点开"账户策略"——“密码策略”。进行如下操作:
    ①双击“密码必须符合复杂性要求”,选择启用;
    ②双击“密码长度的最小值”,设置为(8个字符)
    ③双击“密码最短使用期限”,设置为(1天)
    ④双击“密码最长使用期限”,设置为(90天)
    ⑤双击“强制密码历史”,设置为(24个)避免用户更改口令时使用以前使用过的口令,可以防止密码泄露
    ⑥双击“用可还原的加密来存储密码”,设置为禁用
    设置完成如下图所示:
    在这里插入图片描述

    2.账户锁定策略

    继续点开“密码策略”下方的“账户锁定策略”,进行如下操作:
    ①首先修改“账户锁定阈值”为(3次无效登录),弹出框选确定
    ②设置:账户锁定时间(15分钟)重置账户锁定计数器(15分钟之后),设置完成如下:
    在这里插入图片描述

    3.审核策略

    在左侧"安全设置"栏中依次点开"本地策略"——“审核策略”。进行如下操作:
    ①审核策略更改(成功或失败)
    ②审核登录事件(成功或失败)
    ③审核对象访问(失败)【用于跟踪特定用户对特定文件的访问】
    ④审核过程跟踪(可选)【每次跟踪一个用户启动,停止或改变一个进程,该事件日志将会增长的非常快,建议仅在决定必要时才使用】
    ⑤审核目录服务访问(未定义)【仅域控制器才需要审计目录服务访问】
    ⑥审核特权使用(失败)【用户跟踪用户对超出赋予权限的使用】
    ⑦审核系统事件(成功和失败)【系统事件审核相当关键,包括启动和关闭计算机,或其他与安全相关的事件】
    ⑧审核账户登录事件(成功和失败)
    ⑨审核账户管理(成功和失败)【用户跟踪账号的创建、改名、用户组的创建和改名,以及账号口令的更改等】

    设置完成结果如下:
    在这里插入图片描述

    4.安全选项

    继续点开“本地策略”下方的“安全选项”,找到“账户:来宾状态”,确认其状态为(已禁用)
    在这里插入图片描述

    5.事件查看器

    在开始菜单的“windows管理工具”中,我们可以找到’事件查看器‘
    ①唤出"事件查看器"程序窗口,选择左侧"事件查看器(本地)→Windows 日志"文件夹,点击引用程序。

    在这里插入图片描述
    ②在此界面下点击工具栏"操作"标签,弹出下拉菜单选择"属性"项,修改“达到日志大小时”按需要覆盖事件日志(登录保持方式)和安全日志的最大占用空间(80MB或81920KB),点击确定。如下图所示:
    在这里插入图片描述

    三、安全选项检查

    继续在开始菜单->“管理工具”->“本地安全策略”->’‘本地策略’’->安全选项中,找到以下相关的若干策略,检查如下设置:

    1.Microsoft网络服务器

    ①当登录时间用完时自动注销用户(启用)【可以避免用户在不适合的时间登录到系统,或者用户登录到系统后忘记退出登录】
    ②在挂起会话之前所需的空闲时间(小于等于30分钟)
    ③发送未加密的密码到第三方SMB服务器(禁用)

    2.故障恢复控制台

    ①允许对所有驱动器和文件夹进行软盘复制和访问(禁用)
    【windows2000控制台恢复的另一个特性是它禁止访问硬盘启动器上的所有文件和目录。它仅允许访问每个卷的根目录和systemroot%目录及子目录,即便这样,它还限制不允许把硬盘启动器上的文件复制到软盘上】
    ②允许自动系统管理级登录(禁用)
    【恢复控制台是windows2000的一个新特性,它在一个不能启动的系统上给出一个受限的命令行访问界面。该特性可能会导致任何可以重启系统的人绕过账号口令限制和其他安全设置而访问系统】

    3.关机

    ①清除虚拟内存页面文件(禁用)
    ②允许系统在未登陆前关机(禁用)
    在这里插入图片描述

    4.交互式登陆

    ①不显示上次的用户名(启用)
    ②不需要按ctrl+alt+delete组合件(禁用)
    ③可被缓存的前次登陆个数(域控制器不可用的情况下)(0)
    在这里插入图片描述

    5.账户

    重命名系统管理员账户(除了Administrator的其他名称)
    在这里插入图片描述

    四、注册表检查

    按ctrl+R调出系统的运行页面,在其中输入regedit,如图:
    在这里插入图片描述
    点下确认后,我们可以看到注册表的编辑页面。左侧有许多可以折叠伸展的条目,那些都是注册表的目录。
    在这里插入图片描述

    1.禁止自动登陆

    【自动登陆会将用户名和口令以明文的形式保存在注册表中】
    ①在左侧栏中选择HKEY_LOCAL_MACHINE的条目,点它前面的小三角,可以把它展开。在展开的条目中再展开System的条目。依次找到System\ControlSet001\Control\NetworkProvider项,并点击这个NetworkProvider项将其打开,如下图所示:
     在这里插入图片描述
    ②在右边的窗口单击右键,新建一个DWORE值命名为DisableDefaultPasswords,并把把这个新建的DisableDefaultPasswords值改为1,改完后点确定就可以了,如图;
    在这里插入图片描述

    在这里插入图片描述
    在这里插入图片描述

    2.禁止CD自动运行:

    【防止CD上可能的恶意程序被自动运行】
    ①依次点击展开\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services,选中下方cdrom。
    在这里插入图片描述

    ②在右侧找到并双击打开Start,修改数值数据为4,点击确定
    在这里插入图片描述
    ③重启电脑,这样光驱就隐藏了,如果需要恢复,同样的操作修改数值数据为1即可

    3.删除服务器上的管理员共享:

    【每个windowsNT/2000机器在安装后都默认存在“管理员共享”,它们被限制只允许管理员使用,但是它们会在网络上以Admin$、c $ 等来暴露每个卷的根目录和%systemroot%目录】
    依次点击展开HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\,选中下方Parameters。点击右侧空白新建,类型为(REG_DWORD),命名为AutoShareServer,值为0。如下图所示:
    在这里插入图片描述

    4.帮助防止碎片包攻击

    依次点击展开HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip,点击Parameters,新建EnablePMTUDiscovery,类型为(REG_DWORD),值为1。
    在这里插入图片描述

    5.防止SYN Flood攻击

    依次点击展开HKEY_LOCAL_MACHINE\CurrentControlSet\Services,点击Tcpip,新建SynAttackProtect,类型为(REG_DWORD),值为2。
    在这里插入图片描述

    6.SYN攻击保护

    【管理TCP半开sockets的最大数目】
    依次点击展开HKEY_LOCAL_MACHINE\CurrentControlSet\Services\Tcpip,点击Parameter,新建TcpMaxHalfOpen,类型为(REG_DWORD),值为100或500。
    在这里插入图片描述

    五、其他检查选项及风险等级

    1.禁止某些服务

    win+R打开运行,输入Services.msc,打开服务设置,依次设置以下服务:
    1 Alerter-禁止
    【Alerter服务通常用于进程间发送信息,比如执行打印作业。它也用于和Messenger服务连接来在网络中的计算机间发送同样的信息】
    2 Clipbook-禁止
    【Clipbook服务用于在网络上的机器间共享剪贴板上的信息。大多数情况下用户没有必要和其他机器共享这种信息】
    3 Computer Browser-禁止
    【Computer Browser服务用于跟踪网络上一个域内的机器。它允许用户通过网上邻居来发现其不知道确切名称的共享资源。不幸的是它可以不通过任何授权就允许任何人浏览】
    在这里插入图片描述

    4 Internet Connection Sharing-禁止
    在这里插入图片描述

    5 Messenger-禁止
    6 Remote Registry Service-禁止
    在这里插入图片描述

    7 Routing and Remote Access-禁止
    在这里插入图片描述

    8 Simple MailTrasfer Protocol(SMTP)-禁止
    【该服务是IIS的一部分,应该被禁止或完全删除】
    9 Simple Network Management Protocol(SNMP)Services-禁止
    10 Simple Network Management Protocol(SNMP) Trap-禁止
    11 Telnet-禁止
    12 World Wide Web Publishing Service-禁止

    2.转换磁盘格式

    【NTFS文件系统具有更好的安全性,提供了强大的访问控制机制】
    电脑磁盘一般是FAT32格式的,将所有的磁盘卷转换为NTFS格式的步骤如下。
    ①点击开始菜单,在搜索框中输入CMD命令并以管理员身份运行cmd.exe程序。
    ②输入命令convert c:/fs:ntfs 然后回车,将c盘转换为NTFS格式
    在这里插入图片描述
    ③转换后查看磁盘属性可以验证:

    在这里插入图片描述

    六、个人版防火墙和防病毒软件的检查

    1.第三方防火墙检查

    1 已经安装第三方个人版防火墙
    2 已经安装防病毒软件
    3 防病毒软件的特征码和检查引擎已经更新到最新
    进入控制面板->添加或删除程序,查看是否安装有防病毒软件。同时打开防病毒软件控制面板,查看病毒码更新日期。
    如已安装防病毒软件,则病毒码更新时间不早于1个月,各系统病毒码升级时间要求参见各系统相关规定。
    4 防病毒软件已设置自动更新

    2.查看异常服务或端口

    1 不存在异常端口(netstat -an)(netstat -anb)
    在这里插入图片描述

    2 不存在异常服务(net start)
    在这里插入图片描述

    3 注册表的自动运行项中不存在异常程序HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
    在这里插入图片描述

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
    在这里插入图片描述

    4 系统中不存在异常系统账号
    5 打开杀毒软件的杀毒历史记录,不存在没被清除的病毒

    3.用户权限分配

    打开开始菜单->“管理工具”->“本地安全策略”->’‘本地策略’’->用户权限分配,进行以下操作:
    1 从远端系统强制关机只指派给Administrators组
    在这里插入图片描述

    2 关闭系统仅指派给Administrators组
    3 取得文件或其他对象的所有权仅指派给Administrators
    在这里插入图片描述

    4 配置指定授权用户允许本地登录此计算机
    在这里插入图片描述

    4.本地组策略管理

    同时按下键盘上的WIN键+R键打开运行窗口,在运行窗口中输入gpedit.msc,按回车键打开即可打开本地组策略编辑器。
    5 在组策略中,只允许授权账号从网络访问(包括网络共享等,但不包括终端服务)此计算机
    在这里插入图片描述

    6 启动windows系统的IP安全机制(IPSec)或网络连接上的TCP\IP筛选
    7 启用windows xp和windows2003自带的防火墙。根据业务需要限定允许访问网络的应用程序和允许远程登录该设备的IP地址范围
    8 设置带密码的屏幕保护程序,并将时间设定为5分钟
    进入“控制面板->显示->屏幕保护程序”
    9 对于windows xp sp2及windows2003对windows操作系统程序和服务启用系统自带的DEP功能(数据执行保护),防止在受保护内存位置运行有害代码
    10 如需启用SNMP服务,则修改默认的SNMP Community String设置
    打开“控制面板”,打开“管理工具”中的“服务”,找到“SNMP Service”,单击右键打开“属性”面板中的“安全”选项卡,在这个配置界面中,查看community strings,是否已改,而不是默认的“public”。
    11 如需启用IIS服务,则将IIS升级到最新补丁

    展开全文
  • 日志中的用户隐私安全

    千次阅读 2020-01-16 10:49:49
    对于敏捷团队,安全卡应该提到比业务卡更高的优先级,同样需要放在backlog里面进行track,需要kick off、deskcheck,需要一个正经的流程或者仪式感强化成员的意识:安全卡和业务卡、Bug卡都是项目交付中的一等公民。...
  • 日志系统之HBase日志存储设计优化

    万次阅读 2015-06-13 15:08:27
    本文探讨了基于HBase的日志存储原先自建索引存在的问题,展开分析了rowKey优化、索引优化等相关的优化策略。
  • 【Linux学习】安全基线配置检查

    千次阅读 2018-12-14 21:54:10
    Linux服务器安全运维 1、删除特殊用户和用户组 Linux在系统安装完后,会默认安装很多不必要的用户和用户组,如果不需要这些用户或用户组,应删除它们,因为账户越多,越不安全。 Linux系统中可删除的默认用户和...
  • 最佳日志管理工具:51个有用的日志管理、监视、分析等工具 痛苦的纯文本日志管理日子一去不复返了。虽然纯文本数据在某些情况下仍然很有用,但是在进行扩展分析以收集有洞察力的基础设施数据并改进代码质量时,寻找...
  • 数据库的安全

    千次阅读 2022-03-19 20:46:52
    就整个信息系统的安全而言,数据的安全是最重要的。数据库系统的安全性在技术上依赖于两种方式: 1)DBMS本身提供的用户身份识别、视图、权限控制和审计等管理措施 2)由应用程序实现对数据库的访问控制和管理 应用...
  • 日志服务保留时间

    千次阅读 2021-08-12 06:50:28
    日志服务保留时间 内容精选换一换执行一个MapReduce应用会产生两种类型日志文件:作业日志和任务日志。作业日志由MRApplicationMaster产生,详细记录了作业启动时间、运行时间,每个任务启动时间、运行时间、Counter...
  • 非常感谢举办方让我们学到了新知识,DataCon也是我比较喜欢和推荐的大数据安全比赛,这篇文章2020年10月就进了我的草稿箱,但由于小珞珞刚出生,所以今天才发表,希望对您有所帮助!感恩同行,不负青春。
  • 《娜璋带你读论文》系列主要是督促自己...这篇文章将详细介绍和总结基于溯源图的APT攻击检测安全顶会内容,花了作者一个多月时间。希望这篇文章对您有所帮助,这些大佬是真的值得我们去学习,献上小弟的膝盖~fighting!
  • ftp服务器日志解析

    千次阅读 2021-05-11 16:46:50
    FTP服务器日志解析FTP是老牌的文件传输协议,在网络中应用非常广泛。本节就Vsftp服务器的日志进行重点讨论,在本书的FTP多级跳案例中就会涉及到本节学到的知识。在Redhat Linux系统下Vsftp的配置文件在/etc/vsftp/...
  • 打印日志是一门艺术,但长期被开发同学所忽视。日志就像车辆保险,没人愿意为保险付钱,但是一旦出了问题都又想有保险可用。我们打印日志的时候都很随意,可是用的时候会吐槽各种 SB 包括自己!写好每一条日志吧,与...
  • 互联网用户日志留存技术标准

    千次阅读 2021-01-13 03:44:00
    项目序号(与检查笔录依据和罚则检查内容检查方法检查标准(黑色粗体字表示非强制要求)序号对应)(1)依据记录并留存用户(1)注册信息(1)注册信息《互联网安全保护注册信息通过日志留存设备检查是否能将单位用户身份①...
  • MYSQL数据库日志

    千次阅读 2020-08-29 11:11:20
    目录 1.日志介绍 2. 日志作用 3. 日志分类 Mysql数据库日志 4 .日志讲解 ...一、innodb引擎中的redo/undo log是什么 ...动态检查点 对比 1.日志介绍 数据库都具有事务日志,用于记录所有事务以及每个事务对数据
  • web攻击日志分析之入门指南

    千次阅读 2022-04-18 16:16:44
    作为一名管理员,理解如何从安全的角度来分析日志真的很重要。 这篇文章内容包括了日志分析的一些基础知识,可以解决上述需求。 0x01 准备 出于演示目的,我进行以下设置。 Apache 服务器 预安装在Kali Linux ...
  • MySQL安全你不知道的事

    万次阅读 多人点赞 2020-11-30 11:35:49
    总结 安全存在于系统的方方面面,涉及安全的都是大事,今天主要聊的是MySQL安全的那些事,主要包括MySQL服务器安全,数据库安全以及数据安全,聊完之后发现安全的东西还蛮多,这些能够让我们对MySQL安全有更加深刻...
  • java代码审查检查表

    千次阅读 2016-02-29 14:58:24
    java代码审查检查表 重要性 激活 级别 检查项 总计       命名       重要   20 命名规则是否与所采用的规范保持一致?   ...
  • Web安全工程师长成技能

    万次阅读 2017-03-18 11:31:53
    职位描述: ...跟踪最新漏洞信息,进行业务产品的安全检查。 职位要求: 熟悉主流的Web安全技术,包括SQL注入、XSS、CSRF、一句话木马等安全风险; 熟悉国内外主流安全产品和工具,如:Nessus、Nmap、
  • 日常工作检查表-----Check List

    万次阅读 2013-08-08 15:50:10
    2、支付系统中,出于安全的考虑,会在应用和第三方环境之间,有一道墙,所有应用对于第三方的访问,需要通过一台机器转发(NGINX转发、RINETD转发之类),如果之前没有考虑到,则上线时就会有麻烦。 3、Nginx设置...
  • 信息安全期末题库

    千次阅读 2021-12-25 11:29:15
    物理安全 物理安全是指为了保证信息系统安全可靠运行,确保信息系统在对信息进行采集、处理、传输、存储的过程中,不致受到人为或自然因素的危害而使信息丢失、泄露或破坏,对计算机设备、设施、环境人员、系统等...
  • 运维必备——ELK日志分析系统

    千次阅读 多人点赞 2021-03-30 08:45:10
    目录一、ELK日志分析系统概述(1 一、ELK日志分析系统概述 (1 日志分析是运维工程师解决系统故障、发现问题的主要手段
  • Java安全编程需要考虑的问题

    千次阅读 2021-12-06 22:07:41
    这篇文章简要讨论了Java安全编程需要考虑的若干问题,通过对这些问题的深入理解,能够帮助我们在实际编码过程中避免出现安全相关的问题,从而提高代码质量。 由于时间关系,没有给出每个场景的示例代码,仅说明了该...
  • 提示:文章写完后,目录可以自动生成,如何生成可参考...禁用LOCAL INFILE六、数据库安全基线检查1.删除'test'数据库 | 服务配置2.禁用symbolic-links选项 | 服务配置3.确保配置了log-error选项 | 安全审计 实验准备
  •   系统日志是记录系统硬件检查、内核动作、软件启动、用户动作等各项信息的文件。通过系统日志可以判断系统健康状态、检测系统问题、查找攻击证据等。  Linux系统中的日志服务   较老的系统日志主要由syslog...
  • 信息网络安全设备

    千次阅读 2020-06-21 13:05:53
    现代云服务实施以后,大部分用户转向谷歌、阿里、华为等云服务集成商,应用服务已经很少涉及基础硬件设备相关方面的内容,然而信息安全也因不断丰富的网络应用被提到了一个前所未有的高度,本文粗略回顾信息安全中的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 141,953
精华内容 56,781
关键字:

安全动态日志检查表