微慑信息网

业界快讯 第4页

关于这次Apache Log4j2漏洞 简单说几点

微慑管理员阅读(1950)

1、不是有请求就说明有漏洞,但是很可能是有漏洞,在没有授权的情况下不建议深入,直接报告官方,等官方确认是可行的

2、不是用了Log4j的都应用程序就一定有影响,但是大多数情况确实是受到影响,触发流程要具体看应用调用方式

3、rc1被绕过是说漏洞点确实可以被绕过,但是rc1已经默认了log4j2.formatMsgNoLookups为true 只要不是手贱那也没啥问题

4、目前主要攻击暴露面还是在事件型漏洞上,直接简单暴力提交参数就行,通用软件的暴露面正在路上

5、Log4j可以说无处不在,如果你短期不能确定排查哪些用了受漏洞影响,建议上waf等设备规则拦截,推荐使用我司创宇盾(提我可能可以打折)

6、攻击面可能设计到服务端甚至客户端,各种云,各种OS,所以需要做好长久战的准备时刻关注进展。tips:安卓不支持jndi

7、apache要背锅,就跟当年st2漏洞一样,官方直接就给出了exp!当然这次我觉得可能也算是开源软件的缺陷(缺少安全补丁推广普及时间空间)

8、这个漏洞必然会在历史上留名,毫不夸张的说只要你想道的互联网公司都会受到这个漏洞影响,这个也是一开始可能被低估的漏洞

特别报道 | 立刻排查!Apache Log4j2 远程代码执行漏洞!

微慑管理员阅读(3052)

12月9日,网上爆出Apache Log4j2 远程代码执行漏洞,目前漏洞PoC已在网上公开,由于Apache Log4j2广泛地应用在中间件、开发框架与Web应用中,该漏洞影响范围极广,建议广大用户立刻排查相关漏洞。

Log4j是一个基于Java的日志记录程序,Log4j2是Log4j的升级,重写了Log4j框架,并且引入了大量丰富的特性。该日志框架被大量用于业务系统开发,用来记录日志信息。大多数情况下,开发者可能会将用户输入导致的错误信息写入日志中。此次漏洞触发条件为只要外部用户输入的数据会被日志记录,即可造成远程代码执行。

复现结果如下:

图片

严重

受影响版本:

Apache Log4j 2.x <= 2.14.1

已知受影响应用及组件:

Apache Solr

Apache Flink

Apache Druid

srping-boot-strater-log4j2

1.Java应用是否引入 log4j-api , log4j-core 两个jar

2.若使用Maven打包,查看项目的pom.xml文件中是否存在groupId为org.apache.logging.log4j的依赖

3.若程序使用gradle打包,查看build.gradle编译配置文件,是否存在org.apache.logging.log4j相关依赖

4.通过监测相关流量或者日志中是否存在“${jndi:”等字符来发现可能的攻击行为

1.目前官方已公开修复代码,但尚未正式发布(升级时请提前做好备份)

https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2

2.可选择以下方案缓解:
a.设置 log4j2.formatMsgNoLookups=True

b.系统环境变量

FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS设置为true

c.禁止 log4j2 所在服务器外连

https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2

Apache Log4j2 远程代码执行漏洞 [更新影响范围]

微慑管理员阅读(2825)

『更新影响范围』

Apache Log4j2 是一款开源的 Java 日志记录工具,大量的业务框架都使用了该组件。此次漏洞是用于 Log4j2 提供的 lookup 功能造成的,该功能允许开发者通过一些协议去读取相应环境中的配置。但在实现的过程中,并未对输入进行严格的判断,从而造成漏洞的发生。

影响范围:Apache Log4j 2.x < 2.15.0-rc2

综合评估利用难度低,利用要求少,影响范围很大,且已经被黑客公开利用全网扫描,根据部里要求,需要紧急修复。

修复方案:

1、紧急缓解措施:

(1) 修改jvm参数 -Dlog4j2.formatMsgNoLookups=true
(2) 修改配置log4j2.formatMsgNoLookups=True
(3) 将系统环境变量 FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS 设置为 true

2.升级到最新版本:

请联系厂商获取修复后的官方版本:
https://github.com/apache/logging-log4j2
目前最新版本2.15.0-rc2

3.禁止使用log4j服务器外连,升级idk 11.0.1 8u191 7u201 6u211或更高版本。

请注意Apache Log4j2远程代码执行漏洞影响面广泛,深信服已有防护规则

微慑管理员阅读(3535)

漏洞名称 : Apache Log4j2远程代码执行漏洞

组件名称 : Apache Log4j2

影响版本 2.0 ≤ Apache Log4j <= 2.14.1

漏洞类型 : 远程代码执行

利用条件 :

1、用户认证:不需要用户认证
2、前置条件:默认配置
3、触发方式:远程

综合评价 : 

<综合评定利用难度>:容易,无需授权即可远程代码执行。

<综合评定威胁等级>:严重,能造成远程代码执行。


漏洞分析


组件介绍

Apache Log4j2是一款Java日志框架,是Log4j 的升级版。可以控制每一条日志的输出格式。通过定义每一条日志信息的级别,能够更加细致地控制日志的生成过程。


2 漏洞描述

2021年12月9日,深信服安全团队监测到一则Apache Log4j2组件存在远程代码执行漏洞的信息,并成功复现该漏洞。漏洞威胁等级:严重。


该漏洞是由于Apache Log4j2某些功能存在递归解析功能,攻击者可利用该漏洞在未授权的情况下,构造恶意数据进行远程代码执行攻击,最终获取服务器最高权限。


影响范围


Apache Log4j2广泛地应用在中间件、开发框架、Web应用中。漏洞危害性高,涉及用户量较大,导致漏洞影响力巨大。


目前受影响的Apache Log4j2版本:

2.0 ≤ Apache Log4j <= 2.14.1


解决方案


1 如何检测组件系统版本

打开项目的pom.xml文件,查看log4j-core的version字段

请注意Apache Log4j2远程代码执行漏洞影响面广泛,深信服已有防护规则


2 官方修复建议

当前官方已发布最新版本,建议受影响的用户及时更新升级到最新版本。链接如下:

https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc1


3 深信服解决方案

深信服下一代防火墙AF】可防御此漏洞, 建议用户将深信服下一代防火墙开启 IPS 防护策略,并更新最新安全防护规则,即可轻松抵御此严重风险。

深信服安全感知管理平台SIP】结合云端实时热点高危/紧急漏洞信息,可快速检出业务场景下的该漏洞,并可联动【深信服下一代防火墙AF】等产品实现对攻击者IP的封堵。


时间轴


2021/12/9  深信服监测到Apache Log4j2远程代码执行漏洞信息。 

2021/12/10  深信服千里目安全实验室复现该漏洞、并发布漏洞通告和解决方案。



点击阅读原文,及时关注并登录深信服智安全平台,可轻松查询漏洞相关解决方案。

请注意Apache Log4j2远程代码执行漏洞影响面广泛,深信服已有防护规则


深信服千里目安全实验室

请注意Apache Log4j2远程代码执行漏洞影响面广泛,深信服已有防护规则

深信服科技旗下安全实验室,致力于网络安全攻防技术的研究和积累,深度洞察未知网络安全威胁,解读前沿安全技术。

● 扫码关注我们


原文始发于微信公众号(深信服千里目安全实验室):请注意Apache Log4j2远程代码执行漏洞影响面广泛,深信服已有防护规则

Log4j2 研究之lookup

微慑管理员阅读(4170)

一個稱得上優秀的框架,必備的要素之一可以通過某種約定的格式讀取到所運行環境中的配置信息。本文中我們就來感受下log4j2實現此項功能時的精妙設計。

一 概述

“ Lookups provide a way to add values to the Log4j configuration at arbitrary places. They are a particular type of Plugin that implements the StrLookup interface. ”

以上內容複製於log4j2的官方文檔lookup – Office Site。其清晰地說明了lookup的主要功能就是提供另外一種方式以添加某些特殊的值到日誌中,以最大化鬆散耦合地提供可配置屬性供使用者以約定的格式進行調用。

二. 配置示例

以下列舉了兩個主要使用的位置;當然不僅僅如此,log4j2允許你在任何需要的地方使用約定格式來獲取環境中的指定配置信息。

<properties>
   <!-- 之後我們就可以以 ${logPath}來引用該屬性值  -->
  <property name="logPath">${sys:catalina.home}/xmlogs</property>
</properties>

<!– 這裏的${hostName} 是由log4j2默認提供的, 其值爲程序所在的服務器的主機名 –>
<!– 至於${thread:threadName}, 將是本次我們所提供一個自定義lookup示例 –>
<PatternLayout pattern=“[${hostName}];[${thread:threadName}];[%X{user}];[$${ctx:user}];[$${date:YYYY-MM/dd}]” />
关于log4j2的详细使用说明,请参看官网开发文档。

三. 分析

我们分析一下lookup机制,都会在什么地方级别的日志中出现。首先我们要了解一点日志等级,在log4j2中, 共有8个级别,按照从低到高为:ALL < TRACE < DEBUG < INFO < WARN < ERROR < FATAL < OFF。

  • All:最低等级的,用于打开所有日志记录.
  • Trace:是追踪,就是程序推进一下.
  • Debug:指出细粒度信息事件对调试应用程序是非常有帮助的.
  • Info:消息在粗粒度级别上突出强调应用程序的运行过程.
  • Warn:输出警告及warn以下级别的日志.
  • Error:输出错误信息日志.
  • Fatal:输出每个严重的错误事件将会导致应用程序的退出的日志.
  • All:最低等级的,用于打开所有日志记录.
  • Trace:是追踪,就是程序推进一下.
  • Debug:指出细粒度信息事件对调试应用程序是非常有帮助的.
  • Info:消息在粗粒度级别上突出强调应用程序的运行过程.
  • Warn:输出警告及warn以下级别的日志.
  • Error:输出错误信息日志.
  • Fatal:输出每个严重的错误事件将会导致应用程序的退出的日志.

程序会打印高于或等于所设置级别的日志,设置的日志等级越高,打印出来的日志就越少 。

详细代码可以看这里Log4j2 研究之lookup

也就是说,在不管什么级别的日志下都可以出发lookup。但是为什么有些级别的日志下却不可以触发呢?那是因为你的日志级别设置的太高,导致log4j根本就没打印日志内容。

org.apache.logging.log4j.core.pattern.MessagePatternConverter#format中,会按字符检测每条日志,一旦发现某条日志中包含$ {,则触发替换机制,也就是将表达式内的内容替换成真实的内容,其中config.getStrSubstitutor().replace(event, value)执行下一步替换操作,关键代码如图Log4j2 研究之lookup

org.apache.logging.log4j.core.lookup.StrSubstitutor#substitute(org.apache.logging.log4j.core.LogEvent, java.lang.StringBuilder, int, int, java.util.List<java.lang.String>)中,其实就是一个简单的字符串提取,然后找到lookup的内容并替换。函数的文档如下Log4j2 研究之lookup

Log4j2 研究之lookup

没啥说的,一个简单的字符串查找函数,学过数据结构的都会,不详细介绍了。

在函数的这个地方,执行变量解析,如图

Log4j2 研究之lookup

在这个函数,执行查找,也就是根据变量的协议,关键代码+文档如图Log4j2 研究之lookup

剩下就是一个简单的字符串查找函数,从字符串中提取类似于url的结构去解析,关键代码如下

Log4j2 研究之lookup

值得注意的是,log4j2支持很多协议,例如通过ldap查找变量,通过docker查找变量,详细参考这里https://www.docs4dev.com/docs/zh/log4j2/2.x/all/manual-lookups.html

代码结构如图

Log4j2 研究之lookup

由以上類層次結構圖可以看出

  1. log4j2提供不下十種獲取所運行環境配置信息的方式,基本能滿足實際運行環境中獲取各類配置信息的需求。
  2. 我們在自定義lookup時,可以根據自身需求自由選擇繼承自StrLookup,AbstractLookup,AbstractConfigurationAwareLookup等等來簡化我們的代碼。以上默認提供的各類lookup,其取值來源看官可以通過下面給出的引用鏈接中的第二個進行詳細的瞭解,我就不再在這裏贅述一遍了。

接下來我們來探索一些稍微深入的內容,以及一些細節性的內容。

  1. 作爲lookup對外門面的Interpolator是通過 log4j2中負責解析節點的PropertiesPlugin類來併入執行流程中的。具體源碼可以參見PropertiesPlugin.configureSubstitutor方法。其中注意的是,我們在中提供的屬性是以default的優先級提供給外界的。
  2. 作爲lookup對外門面的Interpolator,在其構造函數中載入了所有category值爲StrLookup.CATEGORY的plugin【即包括log4j2內置的(“org.apache.logging.log4j.core” package下的),也包括用戶自定義的(log4j2.xml文件中的 Configuration.packages 屬性值指示的package下的)】。
  3. Interpolator可以單獨使用,但某些值可能取不到。
  4. 獲取MDC中的內容,log4j2提供了兩種方式:$${ctx:user}或%X{user}。

 

原文始发于微信公众号(宽字节安全):Log4j2 研究之lookup

【漏洞预警】Apache Log4j 远程代码执行漏洞

微慑管理员阅读(4631)

2021年11月24日,阿里云安全团队向Apache官方报告了Apache Log4j2远程代码执行漏洞。

01

漏洞描述

Apache Log4j2是一款优秀的Java日志框架。2021年11月24日,阿里云安全团队向Apache官方报告了Apache Log4j2远程代码执行漏洞。由于Apache Log4j2某些功能存在递归解析功能,攻击者可直接构造恶意请求,触发远程代码执行漏洞。漏洞利用无需特殊配置,经阿里云安全团队验证,Apache Struts2、Apache Solr、Apache Druid、Apache Flink等均受影响。阿里云应急响应中心提醒 Apache Log4j2 用户尽快采取安全措施阻止漏洞攻击。

 

02

漏洞评级

 

Apache Log4j 远程代码执行漏洞 严重

 

【漏洞预警】Apache Log4j 远程代码执行漏洞

漏洞细节 漏洞PoC 漏洞EXP 在野利用
公开 公开 公开 存在

 

03

 

影响版本

 

Apache Log4j 2.x <= 2.14.1

 

04

安全建议

 

1、升级Apache Log4j2所有相关应用到最新的 log4j-2.15.0-rc1 版本,地址 https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc1

2、升级已知受影响的应用及组件,如srping-boot-strater-log4j2/Apache Solr/Apache Flink/Apache Druid

 

06

相关链接

 

https://help.aliyun.com/noticelist/articleid/1060971232.html

【漏洞预警】Apache Log4j 远程代码执行漏洞

原文始发于微信公众号(阿里云应急响应):【漏洞预警】Apache Log4j 远程代码执行漏洞

Log4j2 远程代码执行漏洞(附利用及临时修复办法)

微慑管理员阅读(20798)

// 边界无限漏洞风险提示

漏洞分析

Apache Log4j2是一个基于Java的日志记录工具。该工具重写了Log4j框架,并且引入了大量丰富的特性。该日志框架被大量用于业务系统开发,用来记录日志信息。大多数情况下,开发者可能会将用户输入导致的错误信息写入日志中。此次漏洞触发条件为只要外部用户输入的数据会被日志记录,即可造成远程代码执行。

经边界无限安全攻防团队研判后,认定该漏洞影响范围极广,漏洞危害极大

防团队已经成功复现此漏洞

漏洞风险提示|Log4j2 远程代码执行漏洞

影响判断方式,用户只需排查Java应用是否引入 log4j-api log4j-core 两个jar。若存在应用使用,极大可能会受到影响。

影响范围

Apache log4j2 在 2.0 至 2.14.1 版本受影响。

解决方案

1. 官方补丁 https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc1

2. 靖云甲应用安全防护模块默认防御此漏洞。

3.解决方案:
log4j2.formatMsgNoLookups=True
紧急方案就第一 网络拦截,第二防止外联,第三吧功能关了

参考资料

https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc1

靖云甲·云原生安全防护系统

靖云甲应用安全防护模块,将主动防御能力无缝融合至应用程序运行环境和开发语言中。通过对请求调用的关键函数进监听,结合应用上下文情景分析能力和强大的攻击检测引擎,可捕捉并拦截各种绕过流量检测的威胁攻击,来应对无处不在的应用漏洞与网络威胁,从而为应用程序提供全生命周期的动态安全保护。

联系方式:

邮箱:[email protected]

联系电话:010-84351519

原文始发于微信公众号(边界无限):漏洞风险提示|Log4j2 远程代码执行漏洞

GoDaddy 泄露 – 明文密码 – 1.2M 受影响

微慑管理员阅读(1621)

此处提供更新: GoDaddy Breach 扩大到 tsoHost、Media Temple、123Reg、Domain Factory、Heart Internet 和 Host Europe

今天早上,GoDaddy 披露,一名未知攻击者未经授权访问了用于配置公司托管 WordPress 站点的系统,影响了多达 120 万的 WordPress 客户。请注意,此数字不包括受此违规影响的那些网站的客户数量,并且一些 GoDaddy 客户的帐户中有多个托管 WordPress 网站。

根据 GoDaddy 向美国证券交易委员会提交的报告 [1],攻击者最初于 2021 年 9 月 6 日通过泄露的密码获得访问权限,并于 2021 年 11 月 17 日被发现,此时他们的访问权限被撤销。虽然该公司立即采取行动减轻损失,但攻击者有两个多月的时间来建立持久性,因此目前使用 GoDaddy 托管 WordPress 产品的任何人都应该假设妥协,直到他们确认情况并非如此。

GoDaddy 似乎将 sFTP 凭据存储为纯文本,或以可以反转为纯文本的格式。他们这样做而不是使用加盐哈希或公钥,这两者都被认为是 sFTP 的行业最佳实践。这允许攻击者直接访问密码凭据而无需破解它们。

根据他们提交给 SEC 的文件:“对于活跃客户,sFTP 和数据库用户名和密码被暴露了。

我们试图联系 GoDaddy 征求意见并确认我们的调查结果,但他们没有立即回复我们的评论请求。

攻击者可以访问什么?

SEC 文件表明,攻击者可以访问用户电子邮件地址和客户编号、在配置时设置的原始 WordPress 管理员密码以及 SSL 私钥。所有这些都可能对攻击者有用,但其中一项特别突出:

在 2021 年 9 月 6 日至 2021 年 11 月 17 日期间,攻击者可以访问活跃客户的 sFTP 和数据库用户名和密码。 

GoDaddy stored sFTP passwords in such a way that the plaintext versions of the passwords could be retrieved, rather than storing salted hashes of these passwords, or providing public key authentication, which are both industry best practices.

We confirmed this by accessing the user interface for GoDaddy Managed Hosting and were able to view our own password, shown in the screenshot below. When using public-key authentication or salted hashes, it is not possible to view your own password like this because the hosting provider simply does not have it.

You’ll also note that the system is using port 22, which is Secure File Transfer Protocol. There are several kinds of sFTP, and this confirms that they’re using sFTP via SSH, which is encrypted, and designed to be one of the most secure ways to transfer files. Storing plaintext passwords, or passwords in a reversible format for what is essentially an SSH connection is not a best practice.

GoDaddy appears to acknowledge that they stored database passwords as plaintext or in a reversible format. These are also retrievable via their user interface. Unfortunately storing database passwords as plaintext is quite normal in a WordPress setting, where the database password is stored in the wp-config.php file as text. What is more surprising, in this breach, is that the password that provides read/write access to the entire filesystem via sFTP is stored as plaintext.

What could an attacker do with this information?

While the SEC filing emphasizes the potential phishing risk posed by exposed email addresses and customer numbers, the risk posed by this is minimal compared to the potential impact of exposed sFTP and database passwords.

Although GoDaddy immediately reset the sFTP and Database passwords of all the impacted sites, the attacker had nearly a month and a half of access during which they could have taken over these sites by uploading malware or adding a malicious administrative user. Doing so would allow the attacker to maintain persistence and retain control of the sites even after the passwords were changed.

Additionally, with database access, the attacker would have had access to sensitive information, including website customer PII (personally identifiable information) stored on the databases of the impacted sites, and may have been able to extract the contents of all impacted databases in full. This includes information such as the password hashes stored in the WordPress user accounts databases of affected sites, and customer information from e-Commerce sites.

An attacker could similarly gain control on sites that had not changed their default admin password, but it would be simpler for them to simply use their sFTP and database access to do so.

On sites where the SSL private key was exposed, it could be possible for an attacker to decrypt traffic using the stolen SSL private key, provided they could successfully perform a man-in-the-middle (MITM) attack that intercepts encrypted traffic between a site visitor and an affected site.

What should I do if I have a GoDaddy Managed WordPress site?

GoDaddy will be reaching out to impacted customers over the next few days. In the meantime, given the severity of the issue and the data the attacker had access to, we recommend that all Managed WordPress users assume that they have been breached and perform the following actions:

  • If you’re running an e-commerce site, or store PII (personally identifiable information), and GoDaddy verifies that you have been breached, you may be required to notify your customers of the breach. Please research what the regulatory requirements are in your jurisdiction, and make sure you comply with those requirements.
  • Change all of your WordPress passwords, and if possible force a password reset for your WordPress users or customers. As the attacker had access to the password hashes in every impacted WordPress database, they could potentially crack and use those passwords on the impacted sites.
  • Change any reused passwords and advise your users or customers to do so as well. The attacker could potentially use credentials extracted from impacted sites to access any other services where the same password was used. For example, if one of your customers uses the same email and password on your site as they use for their Gmail account, that customer’s Gmail could be breached by the attacker once they crack that customer’s password.
  • Enable 2-factor authentication wherever possible. The Wordfence plugin provides this as a free feature for WordPress sites, and most other services provide an option for 2-factor authentication.
  • Check your site for unauthorized administrator accounts.
  • Scan your site for malware using a security scanner.
  • Check your site’s filesystem, including wp-content/plugins and wp-content/mu-plugins, for any unexpected plugins, or plugins that do not appear in the plugins menu, as it is possible to use legitimate plugins to maintain unauthorized access.
  • Be on the lookout for suspicious emails – phishing is still a risk, and an attacker could still use extracted emails and customer numbers to obtain further sensitive information from victims of this compromise.

Conclusion

The GoDaddy Managed WordPress data breach is likely to have far-reaching consequences. GoDaddy’s Managed WordPress offering makes up a significant portion of the WordPress ecosystem, and this affects not only site owners, but their customers. The SEC filing says that “Up to 1.2 million active and inactive Managed WordPress customers” were affected. Customers of those sites are most likely also affected, which makes the number of affected people much larger.

For the time being, anyone using GoDaddy’s Managed WordPress offering should assume their sites have been compromised until further information becomes available, and follow the steps we have provided in this article. We will update the article if more information becomes available.

References:

  1. GoDaddy SEC Report: https://www.sec.gov/Archives/edgar/data/1609711/000160971121000122/gddyblogpostnov222021.htm

Note: All product names, logos, and brands are property of their respective owners in the United States and/or other countries. All company, product, and service names used on this page are for identification purposes only. Use of these names, logos, and brands does not imply endorsement.

Did you enjoy this post? Share it!

最高法145号指导性案例“利剑”回击网络犯罪

微慑管理员阅读(1247)

转自:人民法院报 特别提示:凡本号注明“来源”或“转自”的作品均转载自媒体,版权归原作者及原出处所有。所分享内容为作者个人观点,仅供读者学习参考,不代表本号观点。如有异议,请联系删除。

近日,最高人民法院发布了第26批指导性案例,其中145号指导性案例《张竣杰等非法控制计算机信息系统案》无疑具有深远的影响:明确通过修改、增加计算机信息系统数据,对该计算机信息系统实施非法控制,但未造成系统功能实质性破坏或者不能正常运行的,不应当认定为破坏计算机信息系统罪,应当认定为非法控制计算机信息系统罪。

第一, 该指导性案例重新明确了刑法第286条第2款之犯罪构成,维护了罪名的统一性、稳定性。在该案例发布之前,司法实践中有观点认为,刑法第286条第2款未在罪状中加入限制性构成要件,因此本条款不要求行为人的犯罪行为必须造成本罪第1款或第3款中所规定的“造成计算机信息系统不能正常运行”、“影响计算机信息系统正常运行”等结果,而该指导性案例明确否定了该种观点,为统一罪名认识确立了基调。

第二, 该指导性案例再次明确了计算机犯罪保护的法益对象,限制了刑法第286条第2款的滥用。在计算机信息技术语境下,数据乃是计算机信息系统构成之基本元素,无论是计算机信息系统还是程序,都是由数据构成。

如果不对数据操作行为的性质、造成的后果加以区分,可能会导致本条款成为所有涉计算机类犯罪行为的兜底条款,不当扩大了该条款的适用范围。

而该指导性案例的出台,可谓是对这一问题的准确回应,其明确了计算机信息系统功能的完整性和正常运行状态是本罪保护的法益,而数据乃是行为人的犯罪行为客观对象,并非任意操作行为亦或是对任意数据实施犯罪行为都可以构成本罪。

刑法第286条第2款中,值得被刑法苛责的数据操作行为,应该限定于“增、删、改”,数据的性质应限定为与计算机信息系统完整性、正常运行状态相关的数据。

第三,该指导性案例明确了非法控制计算机信息系统罪与破坏计算机信息系统罪的适用问题。在实践中,多样化的计算机犯罪行为之间存在互相嵌套的可能性,而关于非法控制计算机信息系统罪与破坏计算机信息系统罪的竞合适用问题近年来已经在学界、实务界引发了巨大的争议。

该指导性案例的出台,为司法办案实践提供了重要的理论支持,明确了罪名适用的法律规范。不仅有效避免了滥用破坏计算机信息系统罪,也防止了非法控制计算机信息系统罪的空置。正确的罪名适用,也进一步彰显刑法罪责刑相适应原则。

第四,该指导性案例及时回应了网络犯罪热点问题,为打击网络犯罪提供了“利剑”。该指导性案例所呈现的案件事实正是网络黑灰产领域常见的流量劫持行为,其主要目的是为其他网络犯罪(如网络赌博、色情网站)提供引流、广告推广等帮助行为。

流量劫持行为不仅侵犯了计算机信息系统安全,也为网络犯罪提供了收入来源。该指导性案例详细地展示了犯罪行为样态及刑法应对之策,为准确、有效打击网络犯罪行为提供了良好的参照模板。

综上所述,该指导性案例准确区分了破坏计算机信息系统罪与非法控制计算机信息系统罪的界限,有利于依法打击计算机网络犯罪,维护网络安全秩序。该指导性案例所包含的主旨对深入理解相关罪名立法本意、办理此类案件具有十分重要的指导意义。

声明:转载此文是出于传递更多信息之目的。若有来源标注错误或侵犯了您的合法权益,请作者持权属证明与本网联系,我们将及时更正、删除,谢谢。 邮箱地址:[email protected]

Redis设置密码

微慑管理员阅读(1089)

Redis设置密码

设置密码有两种方式。

1. 命令行设置密码。

运行cmd切换到redis根目录,先启动服务端

>redis-server.exe

另开一个cmd切换到redis根目录,启动客户端

>redis-cli.exe -h 127.0.0.1 -p 6379

客户端使用config get requirepass命令查看密码

>config get requirepass
1)"requirepass"
2)""    //默认空

客户端使用config set requirepass yourpassword命令设置密码

>config set requirepass 123456
>OK

一旦设置密码,必须先验证通过密码,否则所有操作不可用

>config get requirepass
(error)NOAUTH Authentication required

使用auth password验证密码

>auth 123456
>OK
>config get requirepass
1)"requirepass"
2)"123456"

也可以退出重新登录

redis-cli.exe -h 127.0.0.1 -p 6379 -a 123456

命令行设置的密码在服务重启后失效,所以一般不使用这种方式。

2. 配置文件设置密码

在redis根目录下找到redis.windows.conf配置文件,搜索requirepass,找到注释密码行,添加密码如下:

# requirepass foobared
requirepass tenny     //注意,行前不能有空格

重启服务后,客户端重新登录后发现

>config get requirepass
1)"requirepass"
2)""

密码还是空?

网上查询后的办法:创建redis-server.exe 的快捷方式, 右键快捷方式属性,在目标后面增加redis.windows.conf, 这里就是关键,你虽然修改了.conf文件,但是exe却没有使用这个conf,所以我们需要手动指定一下exe按照修改后的conf运行,就OK了。

所以,这里我再一次重启redis服务(指定配置文件)

>redis-server.exe redis.windows.conf

客户端再重新登录,OK了。

>redis-cli.exe -h 127.0.0.1 -p 6379 -a 123456
>config get requirepass
1)"requirepass"
2)"123456"

疑问: redis目录下有两个配置文件redis.windows.conf和redis.windows-server.conf,看到网上有的人用前者有的人用后者,不清楚到底该用哪一个。看了下两个文件又没啥区别,个人就用前者了。

微慑信息网 专注工匠精神

微慑信息网-VulSee.com-关注前沿安全态势,聚合网络安全漏洞信息,分享安全文档案例

访问我们联系我们

登录

找回密码

注册