【干货】日志管理与分析(二)–日志分析与报告

2019-08-07 16,625
接《日志管理与分析(一)--日志收集及来源》最后部分简单日志分析,人工审核的局限性,人工日志审核无法随着日志文件尺寸的增大而伸缩,面对大量日志的产生,人工审核明显大大降低了效率,所以衍生出了很多开源以及商业化的日志分析工具。


1
日志分析和收集工具



1.1日志分析工具

上面提到,linux本身内建一些日志分析工具,如gerp、awk、tail。以及windows带的日志记录功能。随着日志尺寸的增长和环境的发展,这些工具可能只适合于取证。

企业中集中日志记录信息,使你能够关联整个环境中的日志,从而方便实现PCI DSS、HIPAA和SOX等收集与分析依从性需求。有些免费的工具可以帮助你在环境中集中日志记录信息。

1.2用户集中化日志分析的实用工具

Syslog:

syslog是目前最为普遍的跨平台日志记录解决方案。上面已经提到,不在叙述。

Rsyslog:

Rsyslog是另一种开源选择,在许多linux发布版本中可以免费使用。

  • Rsyslog是Redhat和Fedora Linux系统的默认日志记录器,对于安装了大量Redhat的企业是更为自然的选择。

  • Rsyslog增加了对Hadoop的支持。为了增强日志挖掘的安全能力而迁移到Hadoop的企业能够用到这一功能集成Rsyslog。

Snare:

windows系统在windows事件日志中记录大量有价值的信息,遗憾的是,事件日志是windows专利技术,对syslog风格的消息没有原生支持。Syslog-ng和rsyslog有付费的选项,可以从windows系统读取事件日志信息。但是Snare是另一个免费的替代方案。

要采用Snare Windows代理通过syslog发送事件日志,你必须在代理安装后进行一些小的调整。安装之后,进行网络配置,并进行如下修改:

  • 将目标端口设置为默认的syslog端口514。

  • 启用syslog报头。

1.3日志分析专业工具

前面提到的日志分析的基本工具,下面介绍的某些工具允许你实时生成事件报警,生成帮助你实现依从性的摘要报告。

1.3.1 OSSEC


OSSEC是一款开源的多平台的入侵检测系统,可以运行于Windows,Linux, OpenBSD/FreeBSD, 以及 MacOS等操作系统中。包括了日志分析,全面检测,root-kit检测。作为一款HIDS,OSSEC应该被安装在一台实施监控的系统中。另外有时候不需要安装完全版本的OSSEC,如果有多台电脑都安装了OSSEC,那么就可以采用客户端/服务器模式来运行。客户机通过客户端程序将数据发回到服务器端进行分析。

1.3.2 OSSIM

OSSIM即开源安全信息管理系统(OPEN SOURCESECURITY INFORMATION MANAGEMENT),是一个非常流行和完整的开源安全架构体系。OSSIM通过将开源产品进行集成,从而提供一种能够实现安全监控功能的基础平台。它的目的是提供一种集中式、有企业的、能够更好地进行监测和显示的框架式系统。

笔者之前曾基于OSSIM写过两篇操作技术文章,可作为参考:

OSSIM操作实践:https://www.secpulse.com/archives/67350.html

OSSIM分布式安装实践:https://www.secpulse.com/archives/67514.html

1.3.3 其他值得考虑的分析工具

logstash

LogStash由JRuby语言编写,基于消息(message-based)的简单架构,并运行在Java虚拟机(JVM)上。不同于分离的代理端(agent)或主机端(server),LogStash可配置单一的代理端(agent)与其它开源软件结合,以实现不同的功能。

说到搜索,logstash带有一个web界面,搜索和展示所有日志。

 

 Logsurfer

Logsurfer是一个实时监控系统log的进程,并且会在发生事件的时候按照配置文件中的相关配置上报消息或者执行操作。它跟我们熟知的Swatch相似,并且是基于Swatch的,但是它也提供了一系列swatch不支持的更高级的功能。

Logsurfer能够将相关的log分类管理--比如当一个系统自启动的时候会创建很多的logmessages。在这种情况下,logsurfer可以将这些启动时候的messages放到一个分组里,并且将这些消息通过一个独立的Email消息发送给系统管理员管理的项目名为“主机xx已经重启“的分组。Swatch则不能完成这个需求。

Logsurfer是用C语言写的,这使得它非常的效率,一个重要的原因是是现场会产生大量的log traffic。我曾经使用logsurfer在一个log服务器每天记录超过50W条记录,logsurfer可以一直保持这个load运行,且没有任何问题。Swacth,在其他的方面,是基于perl实现的,而且即使是很小的log traffic也可能存在问题。

 

flume

Flume是Cloudera提供的一个高可用的,高可靠的,分布式的海量日志采集、聚合和传输的系统,Flume支持在日志系统中定制各类数据发送方,用于收集数据;同时,Flume提供对数据进行简单处理,并写到各种数据接受方(可定制)的能力。

当前Flume有两个版本Flume 0.9X版本的统称Flume-og,Flume1.X版本的统称Flume-ng。由于Flume-ng经过重大重构,与Flume-og有很大不同,使用时请注意区分。

日志收集

Flume最早是Cloudera提供的日志收集系统,目前是Apache下的一个孵化项目,Flume支持在日志系统中定制各类数据发送方,用于收集数据。

数据处理

Flume提供对数据进行简单处理,并写到各种数据接受方(可定制)的能力 。Flume提供了从console(控制台)、RPC(Thrift-RPC)、text(文件)、tail(UNIX tail)、syslog(syslog日志系统),支持TCP和UDP等2种模式),exec(命令执行)等数据源上收集数据的能力。

针对实时数据分析,可以使用:

flume-ng+Kafka+Storm

1.4商业化日志工具

安全业界领先企业有许多杰出的日志分析和保存解决方案,涵盖了从可以自行购买运行的解决方案到允许你将日常日志管理外包给第三方提供商的日志管理服务的范围。

1.4.1 Splunk

Splunk是一个商业化产品,Splunk允许你收集日志,用于取证和关联,也能根据需要进一步调查或者采取行动的事件类型,生成实时警报。Splunk与众不同的地方是它支持广泛的日志源、审核活动的实时仪表盘、可自定义报告和仪表盘以及有助于将Splunk集成到安全基础设施的供应商支持API。

1.4.2 NetlQ Sentinel

NetlQ Sentinel和前面讨论的OSSIM类似,不仅是日志管理和分析产品,而应该归入SIEM的类别。Sentinel包含了异常检测和身份管理信息,作为处理事故响应和事件取证的额外来源。NetlQ Sentinel的企业版可以为企业提供完整的安全信息管理工具。

1.4.3 IBM q1Labs

QRadar是来自IBM的日志管理解决方案。QRadar有广泛的日志源支持,以及广泛的搜索和报告功能。QRadar与众不同的特点之一是它可以为许多当前依从性框架对报告进行调整,支持如下审计:

·支付卡行业数据安全标准

·北美店里可靠性公司

·健康保险隐私及责任法案

·Sarbanes-Oxley和联邦信息安全管理法案

1.4.4 Loggly
Loggly是一个云日志提供商,你的日志数据将被存储在云中。该产品支持上面提到的很多数据源,Loggly的关键特征是为保存日志,而在环境中安装的附件硬件有限,需要由其他人维护和升级你的日志系统。

1.5外包、构建或者购买

在许多公司中,安全和日志管理不是核心竞争力,是从事业务所需的成本而非收入来源,多年来发生的一些引人注目的安全事故已经加强了安全性低下会付出代价的意识。让企业意识到,如果不选择正确的系统,或者没有足够的资源来监控系统,可能会付出很高昂的代价,也可能造成业务损失。

日志管理和日志分析系统应该接受和环境中任何关键IT系统一样的认真评估,才能做出购买、构建或者外包的决策。在许多情况下,购买和构建、购买和外包相结合,可能比提供单一方法更能够满足企业的需求。

1.5.1 构建一个解决方案

由于开源日志管理解决方案的存在,以及对针对环境和需求定制和调整解决方案的渴望,许多企业选择构建日志管理解决方案。在许多情况下,这种方法使企业可以从现有的资源和有限的成本开始。与此相关,有一些优势和风险:

优势:

  • 你能得到适用于环境的一个系统和解决方案。

  • 你可以完成商业化或者开源解决方案中无法找到的功能,因为在许多环境下,你可以修改和更新系统的代码。

  • 你可以选择和设计系统的平台、工具和过程。

  • 获取系统的先期成本有限

风险:
  • 你拥有系统,必须为系统维护和持续满足依从性标准的任何更新分配资源和事件。

  • 没有第三方支持,你就是支持人员。

  • 如果构建该系统的关键人物离开公司,你能够雇佣、保留和训练员工继续维持该系统吗

  • 系统是否能够处理来自企业各系统的日志,是否能够随着企业的成长而扩展。
1.5.2购买

许多企业认为,构建日志管理系统过于费时,如果系统开发不是公司的核心竞争力,它们也可能没有资源投入到这些系统的构建和维护中。较大的企业还需要与供应商的支持,以保证正常运行时间和法律需求。基于开源产品自行开发的解决方案通常无法满足支持和法律需求。下面是购买日志管理系统所应该考虑的:

优势:

  • “付现自运”—付款之后,你就能获得一个日志管理和分析需求的解决方案。

  • 订购的解决方案支持广泛的日志来源和格式。

  • 支持协议通常包含正常运行时间和问题响应时间的服务协议。

  • 产品更新和改进,包括满足依从性标准更改的更新。

  • 可能购买服务和现场帮助,协助安排系统和训练内部人员。

风险:

  • 除了初始系统成本之外,你现在将得到一个系统,需要雇佣或者训练员工安装和使用它,你的企业应该考虑这对当前业务优先顺序的影响,以及初始系统成本之外的预算约束和持续的人员保存及教育成本。

  • 你的企业有没有这样的员工,具备学习、使用和最大限度发挥所购系统的作用的技能?

  • 系统中存在缺口,不能支持环境中安装的应用程序,或者与依从性需求相关的过程。

  • 供应商成熟度、寿命和企业在未来更换供应商的风险。
1.5.3外包

许多企业发展,在自身没有能力或者资源构建或者运营/维护所购买的解决方案时,外包是更好的替代方案。外包使得企业能够满足环境中运营的系统的正常运行时间、支持和法律需求。下面是外包需要考虑的问题:

优势:

  • 由别人去负责企业内的日志管理日常任务和依从性需求。这解放了你的资源,以便于专注于其他核心业务。

  • 外包限制了基础设施占用,外包供应商托管企业中安装的基础设施。

  • 投入日志管理和审核日志日常活动及其他依从性需求的人员较少。

风险

  • 由别人去负责你的问题,他们可能没有适合你的环境或者依从性需求的背景。

  • 系统可能有缺口,不能支持环境中安装的应用程序,或者与依从性需求相关的过程。

  • 企业失去了对其数据的控制,如果托管在企业外部,就会存在丢失数据的风险,在未来难以切换日志管理提供商。

  • 企业的数据量可能给供给商带来挑战,在向企业外传输数据时,可能影响你的系统SLA。

  • 访问日志数据可能受限于供应商提供的API和在线数据保存时间。

1.5.4需要思考的问题

研究工具和解决方案时,考虑如下问题。

1)你是否收集和聚合了来自网络上所有数据源的全部日志数据?

2)日志是否安全地传输和保存。

3)打包的报告是否适合你的需求?你能够创建必要的报告,快速组织收集的日志数据吗?

4)你能在日志的任何内容上设置报警吗?

5)你是否每天查看日志数据,系统是否有能力聚合情报或者减少这些活动耗费的时间?你是否能证明自己有执行这项功能的工具,可以报告谁在何时审核了日志?

6)你是否能够对特定的数据执行快读、针对性的搜索?

7)你能够建立日志数据上下文,并在组织范围内进行关联,用于取证和其他运营任务吗?

8)你是否能够轻松地证明安全、变更管理和访问控制策略正在使用中且保持更新?

9)你是否能安全地与其他应用程序及用户共享日志数据?

 

2
报告和总结



任何查看日志数据的人都知道,只查看原始日志没有什么作用。但是,大部分日志分析最终都涉及查看一定时期内特定系统集的日志数据总结—报告。我们分析的数据越多,就必须进行越多的总结和聚合。

确实,总结和报告是日志分析的支柱:根据日志生成的按国家排列的主要攻击、身份认证失败最多的用户和其他报告,是大部分人考虑日志分析时最常想到的。商业化的日志分析和SIEM工具也更多地查看报告而非原始日志数据。

总结很有效,并减少了你需要查看的数据量,但是在总结中我们杀死了数据,这有可能丢失有用的信息;此外,数据可能因为我们选用的总结类型而被丢失,例如,如果你关注10大用户,不要忘记排名倒数前10的用户可能也很有趣。

2.1 定义最佳报告

报告在日志分析中用途广泛,因此报告的可能种类很多。

最重要的报告类别如下:

1)  身份认证和授权报告。

2)  系统和数据变更报告。

3)  网络活动报告。

4)  资源访问报告。

5)  恶意软件活动报告。

6)  故障和关键错误报告。

2.2 身份认证和授权报告

这些报告识别以各种不同权限级别(身份认证)访问各个系统的企图(无论是成功还是失败),以及特定权限用户的活动,以及使用特权功能(授权)的企图。

重要性

身份认证是控制现代系统访问权限的主要关卡和手段。从简单的密码到令牌以及加密机制,审核整个企业的身份认证活动是关键的安全性活动之一。

具体报告

这个类别的关键报告有:

  • 按照用户、系统、业务单位列出的所有失败和成功登录:这可能是一个或者多个显示不同系统、访问方法(本地或远程)和用户的成功及失败登录的报告。这种报告的价值在于,它要求你不能仅仅记录成功或者失败的登录,而是对两者都有记录。

  • 禁用/服务/不存在/默认/挂起账户的登录企图(成功,失败):这种报告覆盖对不应该访问的账户和服务的访问企图。不管失败还是成功,对安全专业人士来说都是有趣的。

  • 下班时间/“休息”时间的所有登陆:和上面的报告类似,这种活动通常在访问成功时特别令人感兴趣。但是,对这种事件必须加以调查,尤其是在系统管理员全天候工作的环境中。

  • 用户在试图登陆的不同系统中身份认证失败的计数:这种聚合报告检测账户扫描,在这种扫描中,单一机器检查许多系统上的同一个账户或者不同账户,和老式“主机扫描”有些类似。

  • VPN身份认证和其他远程访问登陆(成功,失败):所有登陆企图在合适的场合下都是令人感兴趣的,而通过VPN或者其他远程连接方法进行的远程登陆尝试就更为有趣,应该小心跟踪。

  • 特权账户访问(成功,失败):根用户或者管理员登陆、su命令的使用、Run As命令使用以及其他平台和系统上的等级操作都必须加以考虑,因为特权用户造成的破坏一般比常规用户严重很多。

多次登陆失败之后,同一个账户登陆成功:这种报告需要基于规则(SIEM风格)的关联来生成,但是跟踪多次失败后的成功连接明显令人感兴趣,因为它几乎总是说明有人企图猜测登陆证书。

2.3 变更报告

这些报告识别各种系统和安全的关键变更—配置文件、账户、监管和敏感数据以及系统或者应用程序的其他组件。

重要性

对信息系统的未授权变更导致许多代价沉重的崩溃、数据丢失和安全事故。除此之外,攻击者往往修改你的系统,以便在未来能够访问。勤勉地跟踪变更还将改进你的整个IT运营状况。

具体报告

这个类别的关键报告有:

  • 用户和组的添加/变更/删除:攻击者常常添加新的账户,然后在访问之后删除。这些活动应该在授权方式下进行。

  • 管理员/特权组中账户的添加:对管理员账户和其他特权用户的变更应该在账户变更的跟踪列表中排在首位。

  • 密码变更和重置—由用户进行以及由管理员进行:密码变更通常和新账户的创建一样重要。这些操作可以由用户进行,也可以由管理员进行。此外,这种报告可以用于确定授权的密码变更是否按照策略的安排进行。

  • 网络服务的添加/变更/删除;允许网络连接的新服务可能向附加的攻击开放你的网络,它们常常是攻击者进行的。

  • 对系统文件(二进制文件、配置)的变更:对系统文件(如二进制文件和配置文件)的变更,不管是偶然、计划还是恶意的,都需要小心跟踪。

  • 对其他关键文件的变更:除了二进制可执行文件和配置文件之外,各种系统可能有不同的关键文件,对这些文件的访问也要跟踪。

  • 文件访问权限的变更:危险变更的变种之一是文件权限的变更;如果没有考虑到这种变更,它们可能造成敏感数据的丢失。

  • 对敏感文件的变更:或者对敏感文档的下载/复制。

  • 系统、应用程序、用户进行的应用程序安装和更新(成功、失败):各系统的所有应用程序安装和更新必须记录日志,至少,这些日志在事故响应中很有用。

2.4 网络活动报告

这些报告识别各个系统的可疑和有潜在危险的网络活动,以及需要为常见法规跟踪的活动。

重要性

网络是信息资产威胁的主要来源。显然,网络也是从现代组织中窃取信息资产的主要途径。

具体报告

这一类别的关键报告有:

  • 按照系统、连接数量、用户、宽带、独特目标技术列出的所有来自内部和DMZ系统的出站连接:对环境中的出站连接的信息有多种切片方式,但是主要的精华都一样:跟踪从你的网络连接到外接的用户,是检测入侵和破坏以及恶意软件(还有滥用网络权限的用户)的方法。

  • 在下班时间内部和DMZ系统的所有出站连接:使用防火墙和Web代理日志,人们可以得到上述报告更有针对性的版本,只跟踪非正常时段内的出站访问。

  • 传输的最大文件(入站、出站)或者传输字节最大的会话:这两种报告都使组织能够跟踪露骨的数据窃取和宽带滥用。

  • 向外部网站上传web文件:根据代理日志,人们可以跟踪被上传到外部网站的文件,以及作为web邮件附件的文件。

  • 按照内容类别(exe、dll、scr、upx等)和协议(HTTP、IM等)分类的所有文件下载:跟踪从web进入环境的文件也很重要,可以通过跟踪不同协议和方法的文件来完成。

  • 使用许多不同协议/端口的内部系统:虽然没有可靠的方法能够知道来自合法内部系统的恶意软件活动,但是突然开始通过许多新端口和协议“交流”已经被看作恶意活动的一个征兆。

  • 最常成为多种NIDS、NIPS或者WAF警报源的内部系统:最有用的报告之一是跟踪生成许多不同类型的警报,像“圣诞树”一样的内部信息资产。

  • 按照用户名称、会话总字节数、会话计数、内部资源使用量分类的VPN网络活动:VPN的使用情况也应该跟踪,以便找出VPN访问和流量中的异常状况。

  • 内部系统使用P2P:虽然用户破坏AUP可能是这一工作的重点,但是P2P软件也涉及意外和恶意的数据窃取和丢失。

  • 无线网络活动:无线网络设备能够记录许多不同的事件,将他们作为前述的VPN和其他远程网络访问机制进行跟踪也很有用(包括用户名和windows名);有关无线数据的另一个有用的报告包括流氓AP检测和流氓AP关联日志。

  • 一段时期内的日志容量趋势:虽然这严格上不能算是网络活动报告,但是审核网络产生的日志容量极其有用,它可以作为日志数据的整体指标。

2.5 资源访问报告

这些报告识别整个组织各种系统、应用程序和数据库资源的访问模式,可以用于活动审计、趋势分析和事故检测。

重要性

资源访问的跟踪可以用于揭示内部人员违规使用甚至欺诈。它们在事故响应期间很有价值,可以用户确定攻击者访问和可能破坏或者修改的资源。此外,资源访问可以用于安全意外的目的,比如容量的规划和其他用途。

具体报告

这一类别的关键报告有:

  • 下班时间访问关键系统上的资源:类似于上面所提到的下班时间的网络访问和登录,这种报告可以用于跟踪在不寻常的时间在关键和受监管的系统上的访问和活动。

  • 被代理阻止访问禁用网站次数最多的内部用户、恶意来源等:这种多用途web访问报告可以用于从跟踪受害系统到数据泄露跟踪以及改进生产力等多种目的。

  • 文件,网络共享或者资源访问(成功、失败):这种报告只能用于特定的被审计资源;启用文件访问日志(windows)和系统调用日志(unix)总是会导致数据溢出。

  • 数据库主要用户:为了用于安全活动跟踪,这种报告必须排除已知的应用程序对数据库的访问;理想情况下,用户或者开发人员不能直接访问生产数据库。

  • 查询类型摘要:同样,排除已知的应用程序查询,能够将这种报告转化为异常检测工具,展示异常的数据库访问。

  • 所有特权数据库用于访问:和服务器及应用程序一样,所有特权用户活动应该加以记录并定期分析。

  • 执行Insert、Delete数据库命令的所有用户:除了跟踪应用程序和用户访问之外,单独跟踪可能毁坏数据的破坏性命令也很有意义;在这里,排除已知应用程序的查询是使用的方法。

  • 执行Create、Grant命令,更改数据库模式的所有用户:除了跟踪应用程序和用户访问之外,单独跟踪可能毁坏数据和更改数据库实例本身的破坏性命令也很有意义。

  • 数据库备份摘要:备份为从数据库提取大量数据从而实施数据窃取提供了一种情绪的方法:这种报告使你能够审核旧数据库的备份,捕获未经授权进行备份的人。

  • 向外发送附件最多的内部电子邮件地址:在许多电子邮件访问报告中,这种报告引人注目,它对于检测和调查内部人员的违规使用和数据窃取起到关键的作用。

  • 所有电子邮件附件内容的类型、大小和名称:类似于上一种报告,这种报告可用于跟踪信息信息,检测用户通过邮件发送敏感信息。

  • 所有发送电子邮件的内部系统(排除已知的电子邮件服务器):寻找环境中被垃圾邮件发送程序感染的系统的一种简单方法。

  • 日志访问摘要:记录日志,然后审核对日志的访问是法规的规定;这一基本报告应该排除你自己对日志数据的查看。

2.6 恶意软件活动报告

这些报告总结各种恶意软件活动与恶意软件可能相关的事件。

重要性

各种形式的恶意软件仍然是当今大型和小型企业所面临的主要威胁,虽然防病毒工具近年来已经加入了阻止恶意软件的功能,但是仍然必须使用其他信息来源(如日志)抵御恶意软件。

具体报告

这个类别的关键报告有:

  • 恶意软件检测趋势及结果:恶意软件检测的摘要或者趋势报告,还展示系统和结果(已经清除或者保留),这是一个好的起点。

  • 来自防病毒工具的仅检测事件:所有防恶意软件工具记录检测到恶意软件但没有清除(原因各异)的情况。这种记录下来的“保留”能够帮助许多组织避免大规模的破坏。

  • 所有防病毒保护故障:考虑到当今的恶意软件已经具备了与防病毒工具周旋的能力,所有的死机、检测引擎卸载、更新失败等都必须记入日志并进行审核。

  • 指向已知恶意IP地址的内部连接:人们可以使用这个极其有用的报告,利用日志(如防火墙或者其他设备的日志)和公开的IP地址黑名单,这种简单的方法能够避免组织中有价值的数据落入恶意软件运营者之手。

  • 最不常见的恶意软件类型:这个报告很好地揭示了企业中不寻常从而可能具有破坏性的恶意软件。

2.7 关键错误和故障报告

这些报告总结各种严重的错误和故障指示,这些指示往往在安全上有直接意义。

重要性

错误和故障日志消息往往提供安全威胁的早期指示,包括安全专用设备(如IDS何IPS系统)所没有捕捉到的高级威胁。注意不寻常的错误消息,在网络中出现可能具备破坏性的新威胁因素时常常能得到回报。

具体报告

这一类别的关键报告有:

  • 按照系统、应用程序、业务单位排列的关键错误。虽然在表面上没有安全意义,但是出现在日志中的各种错误消息(尤其是第一次出现)应该加以调查,因为它们往往提供恶意活动的早期指示;下一小节中的分析性报告可以非常有效地用在这类日志消息的管理中。

  • 系统和应用程序崩溃、关闭、重启:每当应用程序崩溃,由于失败的攻击或者其他原因,业务功能可能受到影响,不能将这些事件只当成可用性问题,而应该进行调查,找出攻击的非直接早期指示。

  • 备份故障时影响业务持续性并可能影响监管依从性的关键事件,此外,未授权备份(在这里指的是失败的尝试)可能是因为攻击者试图窃取数据而触发的。

  • 内存、磁盘、CPU和其他系统资源容量耗尽/达到极限:资源的高利用率往往是因为攻击者或者业务系统未授权使用所引起的,也可能是因为洪水攻击、拒绝服务或者暴力破解攻击。

基于所有日志数据创建每个人都能使用的报告列表是不可能的。不管依从性法规如何强制,创建这种列表的所有尝试都注定会失败。但是,拥有几乎每个人都应该使用的报告列表,并根据情况进行调整是很实用的做法。

 

往期精彩文章:

【资讯】程序猿的愤怒?有史以来 GitHub Star 数上涨最快的一个项目诞生

【干货】日志管理与分析(一)——日志收集及来源

【赠书】渗透实战指南——《sqlmap从入门到精通》

GitHub回应突然断供:身在美国不由己,无权提前通知预警

2019年上半年Web应用安全报告

网络安全学习方法论之体系的重要性

【热点】安全群炸了!《亲爱的,热爱的》竟用三行代码搞定服务器攻击

别不信,垃圾分类,正在曝光你的隐私


关注脉搏,有更多安全资讯及技术性文章在等你!

本文作者:Lemon

本文为安全脉搏专栏作者发布,转载请注明:https://www.secpulse.com/archives/110423.html

Tags:
评论  (0)
快来写下你的想法吧!

Lemon

文章数:34 积分: 607

安全问答社区

安全问答社区

脉搏官方公众号

脉搏公众号