dnslog,dnslog漏洞

解决跨网QNAP的ddns无法正常工作的问题

问题：你懂的跨网情况下，QNAP威联通外网服务器得到的访问ip不是路由器ip，因此ddns的映射ip有误，无法正常工作。

解决步骤：

1. 记录路由器dnsmasq查询日志

root@LEDE:~# vi /etc/dnsmasq.conf

加入：

root@LEDE:~# /etc/init.d/dnsmasq restart

2. 获取QNAP api服务器的ip

在QNAP myQNAPcloud云服务 My DDNS管理界面中刷新ddns，QNAP发送api查询请求，在/tmp/dnslog.txt 中记下访问的cname域名和所有ip

写此篇时的cname：core2.api.myqnapcloud.com

对应ip：18.210.138.207? 34.196.214.117? 34.230.144.114? 52.200.64.231?54.152.194.22??54.209.14.111

2019.6.1对应ip变了：34.224.217.21 34.200.69.29 52.201.140.187 52.205.52.244 174.129.89.179 54.152.154.81

3. 白名单例外

把上述ip设置到白名单额外被忽略ip里

Log4j反弹shell

服务器到期的最后几个小时 先操作一波~

1:exp jar包 JNDI-Injection-Exploit

2:利用dnslog平台做初步验证

3:一台服务器作为反弹shell监听, 如果没有服务器可以去百度下NATappAPP、花生壳等做本机隐射

4:靶机平台百度搜一堆, 封神台、cftshow等

5:注意的坑:服务器端口需要开放, 服务器若是在阿里云、腾讯云直接装宝塔（作为一个PHP叼毛开发用宝塔是真香，商城中的各种环境，文件上传，开端口等~~~）

1: 先去dnslog获取一个地址,提交到cft练手(靶机)的平台,看是否存在Log4j日志漏洞

漏洞基于ldap协议 , 提交到靶场的平台。

提交后dns解析返回 ， 确定存在该漏洞。

1: 对bash -i 进行base64编码( )

2: 使用 JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar

3:利用ldap协议,生成的poc直接打

反弹shell:

网络安全工程师需要学什么？

1、了解各种SQL注入类型：报错注入、布尔盲注、时间盲注、DNSLog盲注、二次注入、宽字节注入、还有伪静态SQL注入

2、SQL XSS、XXE、SSRF命令执行等无回显，如何测试证明漏洞存在？

3、PHP代码审计常见危险函数测试思路防御方法你了解多少？

成为一个Web安全工程师需要扎实的基础，需要系统化的学习，更需要攻防模拟演练，从而培养独立完成项目实战的能力。不是懂一点皮毛就可以胜任的！

如果你能掌握安全漏洞高级利用方法与防御方法，熟练使用渗透测试工具的高级使用技巧，漏洞手工利用技巧，掌握对外网渗透和内网渗透技术，并掌握PHP代码审计，python安全脚本开发等技能，那么你才算是在Web安全行业小有所成了！

当然了，如果你入门网络安全，但是对技术又不太敏感，觉得自己很愚钝找不到好工作，其实也不用怕，之前提到网络安全里面包含了售前工程师，这个岗位需要对网络知识理论足够了解，也懂得相关的安全知识、安全标准，但是对技术要求不高，服务与各大企业薪酬也是很高的。

最后做总结，网络安全工程师需要学什么？了解网络基础和基本理论、操作系统、编程语言，然后入门Web安全，掌握了一定的网络安全技术后，再考虑以后的大职业方向。

由log4j远程执行漏洞说起

这几天让IT从业人员忙的不可开交的头等大事便是Log4j的远程执行漏洞了，我们先看一个简单的PoC：

先前往dnslog网站，申请一个子域名，假如是“subdomain.dnslog.cn”。

然后执行java Main ${jndi:ldap://subdomain.dnslog.cn/any}，我们在dnslog网站上刷新请求记录，便会看到申请的子域名被访问了。

如果你是一个开发者，你会知道我们的代码里面毫无疑问充斥着大量这种用法。如果你是一个安全人员，自然知道当恶意访问人员输入时可不只是访问个域名就完事，很有可能把主机密码就传到指定网站了。

那解决的办法在各大厂、安全公司等也已经公布了，无非以下几种：

WAF或防火墙规则，我们先不聊，这个大公司都会做，但并不能完全解除问题。

我们把升级JDK、升级logback、替换成logback以及移除log4j的JNDI相关类都可以看作类库升级。一方面，这些方案都需要一个应用一个应用去执行（甚至有些需要一个一个实例去处理），重复劳动，投入较大；另一方面，兼容性存疑，在升级前必然要做一定的回归测试。此处的兼容性，可以略举一些例子：比如代码里写死了log4j的实现类，而不是slf4j的api时，想要直接替换成logback就不现实。有人可能会说代码规范不允许，但他们忘了，规范和执行是2个相关的事情，但不是必然的因果关系。比如一些只做维护的老系统，存在时间比很多人工龄都长，还有一些是外包产商开发维护的系统，这种情况就是稳定重于一切。

其余几个都是修改配置，但其中略有差异。比如环境变量影响操作系统上所有的应用，如果某个应用JDK版本较高，又刚好需要这个特性，那么就容易产生bug了。修改PatternLayout容易遗漏，比如通常在自己应用的log4j配置文件，但也有可能内部框架做了封装，在jar包有配置，甚至在代码里做了配置。而在log4j2.component.properties添加配置同修改PatternLayout，也还是需要重新打包构建（除非有统一配置中心，并魔改log4j）。

综上来看，我们要避免开发人员修改、避免再次构建，只做重启的话，只能是修改环境变量或添加启动参数了。当然，每个公司有它自己的体系，某些时候大众意义的不好用对于它而言，反而是最简单的。比如，没有自动化（尤其是k8s）的公司，想要改启动参数，运维一个个实例去修改，那简直痛不欲生。

如果我们是log4j的开发人员，当产品经理提出一个需求，即碰到由“${”开头、“}”结尾的日志时，自动做替换，这个需求我们要不要做，怎么做。

刚入行的我是不会问要不要做的，只会想着怎么做，那自然是匹配、解析了。

有一定经验的我则会问这个需求为了解决什么问题，有没有比产品经理提的刚恰当的方式来解决（产品经理资历较浅，或者对产品不够熟悉时）。那我们可以看下log4j这个需求的提交记录最早可以追溯到2013年了，提交记录较多，可以通过代码反向推测需求：类似slf4j，将日志中的占位符替换成真实值，真实值可以延迟计算，计算来源支持扩展。

从代码看，目前已有的扩展包括ctx（日志事件的上下文）、date（日志事件产生的时间）、env（系统环境）、jndi（JNDI上下文获取）、map、sd（结构化事件类型中获取）、sys（系统属性）、web（从web.xml等取ServletContext）

需求是实现了，那还有吗？

如果是一个资深的研发人员就会问了，有预计的使用频率吗，如果使用频率非常高，性能就需要注意不能拖后腿；这个特性如果出现问题，需要关闭，最好能动态关闭；这个特性实际使用了多少次，耗时多少，报错多少；这个是否会在多线程环境下执行，这段代码是否线程安全；用户的输入能否对服务器产生破坏，保存后对其他用户是否产生安全问题。

在一个成熟的企业中，需要考虑诸如此类的问题。当然，很多东西可以模板化，减少开发人员心智，比如CI/CD实践中的自动化测试和DevSecOps。

为什么这次的影响这么大，因为它是基础库，比如dubbo、kafka、flink等很多框架和中间件都用到了它。同时，这从侧面说明log4j2是一个比较值得选取的日志库。

那回到技术选型，以日志为例，我们需要考虑哪些方面呢？

功能。功能是否契合企业需求，缺失功能是否在未来计划，或者扩展实现难度。如果功能都不满足，那自然pass。log4j、logback、log4j2都提供了将日志输出的功能，功能上都能满足，细节根据各企业自身情况而定了。

性能。性能自然是非常重要的，生产是没法debug的，只能通过日志来跟踪某一个事务的情况，如果日志耗时太多，TPS自然受影响，用户体验变差，还可能导致硬件成本上升。log4j2的性能就比logback要出色，logback比log4j要出色。

群众基础和易用性。如果没人会用，使用起来也困难，大概率很难被接受，也很难流行。文档是否介绍了架构设计，也有使用文档，文档是否支持多种语言（本土语言）。log4j2的配置就比较多，特别是想要较高性能时，配置更是复杂。

稳定性与活跃度。生产上使用，肯定要求稳，不可能三五天做一次修复升级。如果功能还未按计划完全实现，那么迭代升级过程中会碰到诸多问题，需要有较多的人提前使用反馈意见做改进，出现问题时，能够通过搜索引擎或其他社群解决。

开源协议。如果不开源，那么使用时心中便会有诸多不安，万一哪个地方有雷都不知道，出了问题，自己能解决的概率也极低。比如MySQL的双协议，要求要么交费，要么开源改动，不如Apache Licence等宽松，导致很多公司开始选择PostgreSQL。

生态。与企业的整套框架是否有冲突，开发流程上是否需要做额外的事情。比如很多框架用了log4j2，贸然引进logback，势必多出工作量来排除log4j2的依赖。比如开发流程工具只支持logback（当然这种场景基本没有），那么使用log4j2就需要再仔细想想了。

架构设计与代码质量。如果代码的架构设计较差，扩展性没设计好，那么企业内部做扩展（二次开发）时，只能修改代码，与源头分叉，后续几乎没法合并，无法反哺开源社区，企业内部后续升级也十分困难。如果代码质量太差，一步一坑，大家直接用脚投票的。

前瞻性。架构设计要有一定的前瞻性，以应对未来的变化。功能建设上也要有一定的前瞻性，实现、验证、上线三者之间还是需要一定时间的。比起等待，大部分人都是想我现在要。