阅读原文

跳转微信打开

儿童节快乐，快乐的我遭遇了不开心，电脑硬盘损坏！部分自己写的重要文档丢失（本身由于最近家庭原因停更了，所以停

儿童节快乐，快乐的我遭遇了不开心，电脑硬盘损坏！部分自己写的重要文档丢失（本身由于最近家庭原因停更了，所以停更更长时间！）

阅读原文

跳转微信打开

记录使用SonarQube实现DevSecOps中代码扫描的经历

# 解决依赖，SonarQube7.9必须是java11才可以运行yum install java-11-openjdk.x86_64 java-11-openjdk-devel.x86_64 -y
# 安装PG数据库，新版本已经不支持MySQL了wget https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpmrpm -ivh pgdg-redhat-repo-latest.noarch.rpmyum install postgresql10.x86_64 postgresql10-server.x86_64 postgresql10-libs.x86_64 postgresql10-libs.x86_64 postgresql-jdbc.noarch -y
# 初始化PG/usr/pgsql-10/bin/postgresql-10-setup initdb
# 允许本机连接vim /var/lib/pgsql/10/data/pg_hba.conf
# 启动PGsystemctl enable postgresql-10.servicesystemctl start postgresql-10.service
# 配置PGsu - postgrespsql

# 将template1取消设置为模板UPDATE pg_database SET datistemplate = FALSE WHERE datname = 'template1';
# 删除template1DROP DATABASE template1;
# 重新创建template1，并设置默认编码CREATE DATABASE template1 WITH TEMPLATE = template0 ENCODING = 'UTF8';
# 将template1重新设置为模板UPDATE pg_database SET datistemplate = TRUE WHERE datname = 'template1';
# 创建用户create user sonarqube with password 'sonarqube';alter role sonarqube login;
# 创建数据库create database sonarqube encoding='UTF8' owner sonarqube;

# 创建用户useradd sonarqubepasswd sonarqubesu - sonarqube
# 安装SonarQubewget https://binaries.sonarsource.com/Distribution/sonarqube/sonarqube-8.0.zipunzip sonarqube-8.0.zip && cd sonarqube-8.0
# 修改配置文件vim /home/sonarqube/sonarqube-8.0/conf/sonar.properties

sonar.jdbc.username=sonarqubesonar.jdbc.password=sonarqubesonar.jdbc.url=jdbc:postgresql://127.0.0.1/sonarqube

# 配置Java版本# 由于8.0需要Java11，但是安装PG10的时候系统会默认安装Java1.8，所以需要配置Java地址vim /home/sonarqube/sonarqube-8.0/conf/wrapper.conf

# 我是yum安装的java11，如果大家是配置或者编译的需要使用对应的java地址wrapper.java.command=/usr/lib/jvm/java-11-openjdk-11.0.6.10-1.el7_7.x86_64/bin/java

# 启动服务./bin/linux-x86-64/sonar.sh start访问：http://10.10.10.12:9000，账号密码：admin/admin。

• 报错信息如下：

[1]: max file descriptors [4096] for elasticsearch process is too low, increase to at least [65535][2]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

• 解决方案如下：

vim /etc/sysctl.conf

# 添加如下内容vm.max_map_count=655360

# 立即生效sysctl -p
vim /etc/security/limits.conf

# 添加如下内容*       soft    nofile  65536*       hard    nofile  65536
# limits不需要重启，但是需要重新登录

# 下载SonarScannerwget https://binaries.sonarsource.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-4.2.0.1873-linux.zip
unzip sonar-scanner-cli-4.2.0.1873-linux.zip -d /home/sonarqube/

1. 在SonarQube管理⻚面创建一个Token：68bec86cee8ec9a9ad8621592670c9939e6ba71e

2. 执行扫描

/home/sonarqube/sonar-scanner-4.2.0.1873-linux/bin/sonar-scanner -Dsonar.host.url=http://127.0.0.1:9000 -Dsonar.login=68bec86cee8ec9a9ad8621592670c9939e6ba71e -Dsonar.projectKey=java-sec-code_scanner -Dsonar.java.binaries=/home/sonarqube/projects/java-sec-code

• 在应用市场中下载安装

• 在GitHub下载jar文件放置到SonarQube的插件目录中

mvn clean package -DskipTests
/home/sonarqube/sonar-scanner-4.2.0.1873-linux/bin/sonar-scanner -Dsonar.host.url=http://127.0.0.1:9000 -Dsonar.login=68bec86cee8ec9a9ad8621592670c9939e6ba71e -Dsonar.projectKey=java-sec-code_findbugs -Dsonar.java.binaries=/home/sonarqube/projects/java-sec-code

# 不更新漏洞库执行扫描/home/sonarqube/dependency-check/bin/dependency-check.sh -n
# 只更新漏洞库库，不执行扫描/home/sonarqube/dependency-check/bin/dependency-check.sh --updateonly
# 使用代理更新漏洞库/home/sonarqube/dependency-check/bin/dependency-check.sh --updateonly --proxyserver host --proxyport port
# 编译项目mvn clean package -DskipTests
# 生成xml报告/home/sonarqube/dependency-check/bin/dependency-check.sh -s /home/sonarqube/projects/java-sec-code/target/java-sec-code-1.0.0.jar -f XML -o /home/sonarqube/reports/java-sec-code-report.xml
# 在5.3.2 版本中，小B遇到了一个坑就是第一项执行DependencyCheck时，当执行到 Central Analyzer 分析时非常缓慢（由于网络原因导致的），可以使用--disableCentral禁用，但是官方文档中不推荐禁用，所以只能在执行是使用代理或调整网络来解决
# 生成html报告/home/sonarqube/dependency-check/bin/dependency-check.sh -s /home/sonarqube/projects/java-sec-code/target/java-sec-code-1.0.0.jar -f HTML -o /home/sonarqube/reports/java-sec-code-report.html
# 将报告导入SonarQube并执行SonarScanner扫描，这里我们使用的是FindBugs Security Audit审计规则/home/sonarqube/sonar-scanner-4.2.0.1873-linux/bin/sonar-scanner -Dsonar.host.url=http://127.0.0.1:9000 -Dsonar.login=68bec86cee8ec9a9ad8621592670c9939e6ba71e -Dsonar.projectKey=java-sec-code_dependency -Dsonar.java.binaries=/home/sonarqube/projects/java-sec-code -Dsonar.dependencyCheck.reportPath=/home/sonarqube/reports/java-sec-code-report.xml -Dsonar.dependencyCheck.htmlReportPath=/home/sonarqube/reports/java-sec-code-report.html

stages:  - sast
sast:  stage:sast  script:    - mvn clean package -DskipTests # 编译项目    - mkdir $PWD/reports # 创建报告目录    - /home/gitlab-runner/dependency-check/bin/dependency-check.sh -s $PWD/ -f XML -o $PWD/reports/dependency-check-report.xml # 执行扫描，并生成xml报告    - /home/gitlab-runner/dependency-check/bin/dependency-check.sh -s $PWD/ -f HTML -o $PWD/reports/dependency-check-report.html # 执行扫描，并生成html报告    - sonar-scanner -Dsonar.host.url=http://10.10.10.12:9000 -Dsonar.login=token -Dsonar.projectKey=$CI_PROJECT_NAME:$CI_COMMIT_REF_NAME -Dsonar.java.binaries=$PWD -Dsonar.dependencyCheck.reportPath=$PWD/reports/dependency-check-report.xml -Dsonar.dependencyCheck.htmlReportPath=$PWD/reports/dependency-check-report.html # 执行扫描，并将报告传输给SonarQube  tags:    - security

import requests
def get_vul(project_name):    url = "http://172.16.26.13:9000/api/issues/search?project=%s&types=VULNERABILITY" % project_name    vulnerability_number = requests.get(url,auth=('admin','admin')).json()['paging']['total']
    for row in requests.get(url,auth=('admin','admin')).json()['issues']:        if row['status'] == "OPEN":            if row['severity'] == "MAJOR" or row['severity'] == "CRITICAL" or row['severity'] == "BLOCKER":                alarm_data = ""            else:                pass        else:            pass
    print("漏洞数量: ", vulnerability_number)

if __name__ == '__main__':    project_name = "java-sec-code_dependency"    get_vul(project_name)

• 使用阿里云RDS，新版本不支持MySQL了可以使用阿里云的PostgreSQL。

sonar.jdbc.url=jdbc:mysql://address:3306/sonar?useUnicode=true&characterEncoding=utf8

ERROR: Unable to load component class org.sonar.scanner.report.MetadataPublisherERROR: Caused by: Unable to load component class org.sonar.scanner.rule.QualityProfiles

• SonarQube之gitlab-plugin配合gitlab-ci完成每次commit代码检测：https://blog.csdn.net/aixiao yang168/article/details/78115646

• gitlab-ci/cd Dependency依赖扫描两种方式(五)：https://www.linuxea.com/1837.html

阅读原文

跳转微信打开

这一天小B正在晒太阳，突然接到了老板的电话，要求对M公司进行一次内部全员邮件钓⻥测试，试图找出那些安全意识薄弱的员工。根据老板的要求，小B开始了这次的有趣的钓⻥之旅。

• 需要控制目标PC或在目标PC植入后⻔或木⻢等信息；
• 只需要收集目标的个人信息；

以邮件主题进行分类

• 企业内部通知
• 人事变动通知：冒充行政部⻔发送人事变动的相关邮件，利用邮件中的附件进行钓⻥；
• 薪资/奖金通知：同上
• 安全警告：冒充IT类部⻔发送内部安全警告的相关邮件，利用邮件中的附件或链接进行钓⻥；
• 企业内部活动
• 优惠活动：以企业名义给员工发送一些优惠活动，让用户报名参与进行钓⻥；
• 聚餐活动：以聚餐报名为主题进行钓⻥；
• 员工信息变更：冒充IT部⻔发送员工个人信息(密码、手机号)已过期或失效需要更新进行钓⻥；
• 社会实事关注：比如最近的新型冠状病毒

由于没有开发资源，并且小B的目的是获取内部员工的信息，所以选择了实事相关的调查问卷来作为本地邮件主题。由于没有开发，小B找了一个开源的调查问卷系统：LimeSurvey(https://www.limesurvey.org/)部署方案使用Apache+MariaDB+PHP即可，我这里简单记录了一下：

# 部署环境是:Centos7.4 最小化安装# LimeSurvey需要PHP5.5 以上的版本，但是Centos7默认的是5.4版本，所以需要更改PHP的源 yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpmyum install yum-utils -yyum-config-manager --enable remi-php56
# 安装依赖环境yum install httpd.x86_64 mariadb-server.x86_64 mariadb.x86_64 mariadb-libs.x86_64 php.x86_64 php-fpm.x86_64 php-mysql.x86_64 php-mbstring.x86_64 php-ldap.x86_64 php- xmlrpc.x86_64 php-xml.x86_64 php-gd.x86_64 php-imap.x86_64 -y
# 最后将下载的压缩包放置到网站目录，并开启防火墙与关闭SELinux即可。 

• Gophish：https://getgophish.com/

  (PS.小B也写过相关的文章：https://bloodzer0.github.io/ossa/infrastructure-security/network-security/office-network-security/gophish/)

• Swaks：https://www.jetmore.org/john/code/swaks/

  (PS.小B也写过：https://mp.weixin.qq.com/s/2xhTg6HhgnFMA7jexgg3AA本文中关于SPF绕过的部分写的有误，后期小B会更新一下)

• mail_fishing：https://github.com/SecurityPaper/mail_fishing

这里不作过多的描述了，为了方便后期使用脚本自定义发送，所以小B选择的是Swaks。选择好工具以后我们就需要来构造我们的邮件了。

 ./swaks --to yyfortest@126.com --from sender_user@126.com --ehlo 126.com --h-From "OA <oa@126.com>" --data test.txt --server smtp.126.com --au sendder_user@126.com --ap sender_user_pass

 ./swaks --to yyfortest@126.com --from oa@126.com --ehlo 126.com --h-From "OA <oa@126.com>" --data test.txt --server mail.smtp2go.com --au smtp2go_user --ap smtp2go_user_pass

#!/usr/bin/env python3 # -*- coding: utf-8 -*-
# @Time: 2020/4/20 10:25 上午 # @Author: bloodzer0# @File : send_email.py
import os
email_tmp = []# 发件人文件for email in open('user_email.txt','r').readlines():    email_tmp.append(email.strip())# 发送邮件的内容email_old = open('test.txt','r+') content = email_old.readlines() email_old.close()
for send_email in email_tmp:    write_file = open('test.txt', 'w')    write_file.writelines("To: <%s>" % send_email + '\n' + "".join(content[1:]))     write_file.close()    command = './swaks --to %s --from oa@126.com --ehlo 126.com --h-From "OA<oa@126.com>" --data test.txt --server mail.smtp2go.com -p 2525 --au smtp2go_user --ap smtp2go_user_pass' % send_email    print(command)    # os.popen(command)

在本次测试中，我们的调查问卷系统可以辅助，或者自己编写⻚面将录入的数据写入数据库。

识别钓⻥邮件：

1. 看发件人地址(有的时候看到的是表象，发件人是公司内部地址也不一定真实)；

2. 看邮件标题；

3. 看正文措辞；

4. 看正文目的；

1. 安装杀毒软件；

2. 个人信息要保密，填写前请人为核对是否属于内部要求；

3. 邮箱账号需要启用双因素校验，即使密码丢了也不怕；

4. 重要的邮件请即时从邮件服务器删除，保存到本地；

5. 不要轻信发件人地址中的"显示名"、不要轻易点开陌生邮件中的链接与附件、不要放松对"熟人"邮件的警惕、不要使用公共场所的网络执行敏感操作、不要将敏感信息发布到互联网；

1. 及时报告给IT团队；

2. 及时修改密码；

3. 隔离网络；

4. 进行一次全盘杀毒；

钓⻥邮件模板：https://github.com/SimplySecurity/SimplyTemplate

阅读原文

跳转微信打开

云IDC是时下的热点，关于企业在使用云IDC时遇到的安全痛点与解决方案，让我们一起来探讨。

互联网数据中心（IDC）属于互联网基础设施范畴的一个细分领域。为企业、金融机构等提供一个存放服务器的空间场所，随着科技技术的发展，IDC也经历了一个又一个的里程碑，如下图是：摘自《美国数据中心建设发展历程分析情况》

• IaaS（基础设施即服务）：消费者通过Internet可以从完善的计算机基础设施获得服务，这类服务称为基础设施即服务，基于Internet的服务（如存储和数据库）是IaaS的一部分。

• PaaS（平台即服务）：PaaS提供了用户可以访问的完整或部分的应用程序开发。

• SaaS（软件即服务）：SaaS则提供了完整的可直接使用的应用程序，比如通过Internet管理企业资源。

• 云控制台访问凭证，此类凭证用于我们通过Internet访问云控制台，在这其中又存在两个小类：

• 主账号：拥有其下所有资源和企业级分布式应用服务的所有操作权限。

• 子账号：主账号通过创建子账号，避免用户间共享密钥，按需给子账号分配权限。

• AccessKey：访问密钥AccessKey（AK）用于程序方式调用云服务API（主账号与子账号都有AccessKey）。

• 分散的地区：在使用传统IDC机房的时候，中小型企业可能只有1~3机房，但是我们在使用云IDC时面临的地域就会变得更多，上述提到的4种架构都会形成不同的地域IDC分布，给我们管理云资产带来不便。

• 多样的类型：云上的产品的细分类给我们提供了使用便捷的同时也带来了资产管理的难题，多样的类型导致我们在进行管理的时候需要处理的数据源更多，不同数据源的字段、属性也不一致也会造成统一采集的困难。

• 不同的维度：在这里需要提到的一个系统就是CMDB，可能对于很多企业来讲CMDB的维护都是做的很一般或者做不到资产的实时管理。这个问题在中小型企业就更为常⻅，他们可能都没有CMDB或者是非常简易的CMDB。并且运维与安全对于CMDB数据的细粒度要求是不一致的，很难将两者合二为一，更多的做法是各行其事，数据互补。最后在安全做黑盒的云资产管理时云平台自身会对黑盒的方式进行一些拦截从而造成一些资产收集的误报以及漏报，这些问题我们都会在下面的解决方案中提到。

• 云控制台有哪些用户可以访问?

• 主账号是否存在共享使用?（有多少企业是所有运维直接共用主账号进行管理）

• 子账号是否存在共享使用?（云控制台用户是否将自己的账号共享给其他用户）

• 子账号是否有⻆色权限以外的权限?

• 灰度账号是否处于活跃状态?（离职员工的账号是否及时清理）

• AccessKey是否拥有过高的权限?

• ............

• 服务器资源哪些用户可以访问?

• 谁拥有服务器上的特权账户?

• 统一单点登录以外的账号?

• 云资产对互联网或办公网络的访问控制策略（RDS是否允许互联网直接访问?核心服务器是否允许互联网直接访问?）

• 不同类型云资产之间的访问控制策略（RDS对ECS的访问控制策略）

• 相同类型不同属性云资产的访问控制策略（生产环境与测试环境的访问控制）

• 胡乱的资产分组：生产与测试处于同一VPC;

• 成吨的网络攻击：由于云IDC的开放性，所以每天会面临成吨的访问控制扫描、漏洞扫描、Web扫描等;

• 分散的补丁管理：如果企业没有统一资产管理系统或者服务器未使用域环境，那么我们在安装补丁时也会遇到麻烦;

1. 通过内部通讯工具的接口获取用户原始数据，并且采集通讯工具中的用户属性;

2. 利用云API管理云控制台账户，根据用户属性决定是否需要创建或删除云控制台账户;

3. 与内部的跳板机打通，根据用户属性决定是否需要创建登录或删除资产访问账户;

1. 黑盒资产管理：以扫描的形式发现资产（masscan+nmap+nessus等），通过将扫描结果进行数据处理后入库然后以CMDB的形式展示。但是在这个阶段中会由于云平台的拦截产生误报与漏报，所以这里的资产管理数据我们还需要更进一步的处理。

2. 白盒资产管理（利用云API），之前小B也分析过对应的文章：

   https://bloodzer0.github.io/ossa/other-security-branch/asset-management/asset-acquisition/

   

3. 利用主机入侵检测Agent采集数据，不论是前面的黑盒方式或利用API的方式，我们获取到的数据在细粒度上都达不到安全后期的要求，所以利用主机入侵检测的Agent可以获取更详细的信息，但是由于这个层面需要对底层开发有着足够深厚的了解，这也是小B未实现的原因。但是小B也实践过开源的主机入侵检测系统（OSSEC）采集信息完善安全的CMDB，效果也是很不错的。

1. 制定访问控制策略与管理流程：访问控制难题不仅仅是一个通过技术就能解决的，首先我们需要制定好访问控制策略，在制定策略之前我们需要梳理我们的主体（使用者）与客体（资源），在评估主体的需求后制定出策略，访问控制策略一定要依据最小权限原则。制定好策略只是一个起始点，后期策略的管理也至关重要，在这其中小B是通过以IT流程的形式进行策略变更管理。

2. 制定好策略以后我们需要实现策略控制，在这里对于凭证的访问控制，主要是通过云控制台管理进行。对于资产的管理主要是利用安全组来实现的，安全组可能并不具备攻击防护能力，但是具备良好的访问控制策略。在安全组实现访问控制的时候，会遇到一个大坑，就是当我们的IDC数量越来越多时，我们管理就会变的更加困难。所以如果前期就有这样的安全意识是最好的，后期就会需要我们逐一的去调整已有的策略。

   

3. 定期审计访问控制策略是否合理，这里提一点的就是，我们的策略审计最好是以实践的方式进行审计。通过将审计策略拉取到本地（API是可以拉取的，云控制台也可以导出）然后根据策略的内容去实践策略是否有效。

阅读原文

跳转微信打开

Swaks：Swiss Army Knife SMTP （SMTP界的瑞士军刀）利用它我们可以操作SMTP协议报文。

日常不稳定更新系列

Swaks：Swiss Army Knife SMTP （SMTP界的瑞士军刀）利用它我们可以操作SMTP协议报文。

Swaks官网地址：https://www.jetmore.org/john/code/swaks/

Swaks GitHub地址：https://github.com/jetmore/swaks

1

Swaks安装

直接使用二进制文件

wget https://www.jetmore.org/john/code/swaks/files/swaks-20190914.0.tar.gztar -xf swaks-20190914.0.tar.gzcd swaks-20190914.0/# 执行./swaks
# git clone https://github.com/jetmore/swaks.git

macOS安装Swaks

brew install swaks

Kali自带Swaks

2

Swaks使用

# 测试邮件服务器连通性./swaks --to email_user@domain_1
# 发件人邮箱--from email_user@domain_2
# 伪造邮件头--ehlo domain_2

测试126邮箱

# 直接发送成功，见下图./swaks --to yyfortest@126.com
# 伪造发件人不成功，但是在执行命令的返回中显示是成功的./swaks --to yyfortest@126.com --from pentest@126.com --ehlo 126.com

swaks_1

使用邮件托管平台

smtp2go：https://support.smtp2go.com/hc/en-gb 注册一个免费的账户可以发送1000封邮件

./swaks --to yyfortest@126.com --from root@126.com --ehlo 126.com --server mail.smtp2go.com -p 2525 --au username --ap password

此时邮件发送成功，但是可以看到邮件中会显示由xx服务器代发。

swaks_2

加载附件

./swaks --to yyfortest@126.com --from root@126.com --ehlo 126.com --attach 1.txt --server mail.smtp2go.com -p 2525 --au username --ap password

swaks_3

3

所谓的绕过SPF

看了一些关于绕过SPF的，其实就是--from后面的参数与--server后面的参数保持一致，如下：

./swaks --to receiver@domain1 --from sender@domain2 --ehlo domain1 --server domain2 -p 2525 --au username --ap password

原理就是：接收方在收到邮件时会获取发件邮件服务器的IP，然后校验发件人的IP是否在发件邮件服务的IP列表中。有点拗口，通俗理解就是发件人的后缀需要与发件邮件服务器一致或是被包含关系。

4

Refer

关于伪造邮件的简单研究：https://hex.moe/p/4878b295/

Swaks伪造邮件：https://payloads.online/archivers/2019-05-09/1

Swaks绕过SPF验证进行邮件伪造：https://www.cnblogs.com/backlion/p/10842676.html

阅读原文

跳转微信打开

Genymotion默认使用的是x86的架构，安装ARM架构的APP时会报错，可以使用该工具进行解决。

日常不稳定更新系列

Genymotion_ARM_Translation：https://github.com/m9rco/Genymotion_ARM_Translation

Genymotion默认使用的是x86的架构，安装ARM架构的APP时会报错如下：

genymotion_ram_1

我这里的模拟器版本为：

genymotion_ram_2

在提供的转换器地址下载6.0版本进行安装转换

# push文件到模拟器中adb push Downloads/Genymotion-ARM-Translation_for_6.0.zip /sdcard
# 进入模拟器adb shell
# 执行安装sh /system/bin/flash-archive.sh /sdcard/Genymotion-ARM-Translation_for_6.0.zip
# 退出模拟器exit
# 重启模拟器adb reboot

这个时候再重新安装APP即可成功：

genymotion_ram_3

APP也可以正常使用

genymotion_ram_4

阅读原文

跳转微信打开

PESecurity：一个PowerShell的模块，用来检查EXE/DLL文件编译选项。

日常不稳定更新系列

PESecurity GitHub地址：https://github.com/NetSPI/PESecurity

一个Powershell的模块，用来检查EXE/DLL文件编译选项，包括：ASLR, DEP, SafeSEH, StrongNaming, Authenticode。

Import-Module .\Get-PESecurity.psm1Get-PESecurity -file "file_path"Get-PESecurity -directory "dir_path"

bianyi_check_1

阅读原文

跳转微信打开

sigcheck：分析CS应用程序需要检查应用程序是否被签名，常用于CS程序安全测试中。

日常不稳定更新系列

sigcheck官网地址：https://docs.microsoft.com/en-us/sysinternals/downloads/sigcheck

分析CS应用程序需要检查应用程序是否被签名，常用于CS程序安全测试中。小B找了两个例子：一个是没有签名的文件，一个签名的文件：

sigcheck_1

sigcheck_2

当然sigcheck还支持对整个目录进行签名检查：

sigcheck_3

阅读原文

跳转微信打开

在之前的系列中，小B完成了日志分析平台的实现，也接入了各种日志源，做好了这些前期工作，接下来就是真正利用平台实现分析并体现日志价值的时候了。

本系列故事纯属虚构，如有雷同纯属巧合

在之前的系列中，小B完成了日志分析平台的实现，也接入了各种日志源，做好了这些前期工作，接下来就是真正利用平台实现分析并体现日志价值的时候了。

日志分析价值

在安全日志分析的大场景中，我们都是根据不同场景下的特征来进行分析，我们以主机安全场景特征判断为例：

通过对这些场景的思路整理，我们可以发现识别攻击场景的方式大致包括：关键字匹配、统计分析、聚合分析、关联分析。这四种分析方式在前面的文章中我们也提到过，大家有兴趣可以翻看历史文章进行查看。

熟悉ES的朋友都应该知道（如果不熟悉的建议阅读几遍ES的官方文档）它支持上述的关联分析之外的所有分析方式，那么我们就可以使用ES的这些查询语句来实现我们的安全日志分析，下文我分享了几个安全日志分析的具体案例：

demo1:常见的Web攻击

普通的Web攻击在日志分析中的分析方式与WAF识别攻击相似，都是通过正则表达式或者关键字匹配的方式来实现，ES中存在很多相关的查询语句，我们来体验一下：

• match匹配

• 利用bool方式进行复合查询

可以看到的是，我们使用match来进行查找时，需要对关键字进行优化，否则会出现无法找到的情况。那么如何解决这个问题呢？ES中其实还提供了通配符（Wildcard）与正则表达式查询

• 通配符查询

• 正则表达式查询：正则表达式匹配的方式与通配符类似，但是正则表达式支持更复杂的模式进行查询。

对于正则匹配我们还有一种方式就是使用logstash，jeary曾经在https://github.com/anbai-inc/AttackFilter实现了。

我们可以利用此种模式对常见的Web攻击进行分析，需要的就是我们收集常见的关键字：

值得一提的是，以正则或者查询的方式去做安全分析都不适合做实时的分析拦截，因为数据量很大的时候查询很费时间，而如果使用Logstash Grok更是可能将日志分析平台搞挂。

demo2:统计与聚合

对常见API的聚合统计分析，根据访问API的IP进行排序：查询5分钟内访问api_path的数据，并根据remote_addr进行聚合排序。

{
    "size": 0,
    "query": {
    "bool": {
        "must": [
        {"term": {
            "request_api.keyword": {
            "value": "api_path"
            }
        }}
        ],
        "filter": {
        "range": {
            "@timestamp": {
            "gte": "now-5m",
            "lte": "now"
            }
        }
        }
    }
    },
    "aggs": {
    "ip_count": {
        "terms": {
        "field": "remote_addr.keyword",
        "size": 1000000
        }
    }
    }
}

完整的demo我放在了GitHub上：https://github.com/bloodzer0/python_es_aggs

• 嵌套聚合

ElastAlert分析模式

ElastALert GitHub地址：https://github.com/Yelp/elastalert/

elastalert支持多样的规则类型：https://elastalert.readthedocs.io/en/latest/ruletypes.html#rule-types

本文写的很仓促，很多东西都没有完整的去写。由于工作变更的原因，没有时间去折腾这个系列了，所以今天就算是写个结尾。后续应该会开个新的系列，但是更多偏向于乙方的东西！对于日志分析系列的虎头蛇尾，小B也很抱歉，后期在有精力的时候，我会把一些之前在甲方企业中实践的内容分享出来。主要是如下这幅图的内容：

- REFER -

《19个很有用的ES查询语句》：https://n3xtchen.github.io/n3xtchen/elasticsearch/2017/07/05/elasticsearch-23-useful-query-example

- HISTORY -

《日志分析系列(一)：介绍篇》

《日志分析系列(二)：平台实现篇》

《日志分析系列(外传一)：Nginx透过代理获取真实客户端IP》

《日志分析系列(外传二)：Nginx日志统一化》

《日志分析系列(外传三)：平台安全性》

阅读原文

跳转微信打开

小B接到一个渗透测试任务，由于很久没有从乙方视⻆执行渗透测试的他决定先梳理一下自己的思路。

前期沟通

技术测试

报告输出

refer

• ATT&CK针对云上环境入侵手法的总结:https://attack.mitre.org/matrices/enterprise/cloud/

• 针对AWS入侵框架:https://github.com/RhinoSecurityLabs/pacu

阅读原文

跳转微信打开

总结一下遇到挖矿时应该如何做应急响应与溯源分析。

背景：总结一下遇到挖矿时应该如何做应急响应与溯源分析。

1.挖矿特征分析

当服务器或PC处于什么样的状态时，我们可以判定为被挖矿。通常来说，当我们的服务器或PC资源(CPU)使用率接近或超过100%，并持续高居不下导致服务器或PC操作延缓，我们就可以判定被挖矿。常见挖矿其它特征如下：

• 服务器或PC访问[过]不受信任的地址，这些地址包括：主机、IP、域名。这是由于大部分挖矿都需要从一个不受信任的地址下载初始化程序，而不受信任的来源主要是：第三方情报结构，企业内部历史数据沉淀。
• 服务器或PC新增异常或恶意文件、进程或服务，并且大部分异常文件保存在服务器或PC的TMP目录中。
• 服务器或PC的定时任务发生变更。

2.挖矿应急响应流程

PS：在整个处理挖矿的应急响应过程中，我们应该严格执行做好记录与备份工作。包括对分析过程中的命令、分析的文件都做好记录与备份。

这里的流程是一个最简化的流程，通常对于小B来说完整的流程包括：

2.1 确认告警是否属于挖矿

通常我们都是通过告警的形式得知服务器或PC被挖矿。这个时候我们首先需要判断告警是否属于误报，如果不是误报那么需要确认告警是否真的属于恶意挖矿，如果不属于需要丢到其它的应急响应流程中，如果属于挖矿就需要进行后续的处理。

下面是一些常见的确认挖矿方法：

2.1.1 Windows确认挖矿

• 使用图形化界面分析确认

  a. 打开任务管理器：Ctrl + Alt + Delete 快捷键 或者 win + r 快捷键，输入 taskmgr；

  b. 在任务管理器中找到资源管理器；

  c. 通过资源管理器找到占用CPU资源较高的服务或进程，获取其PID信息；

  d. 利用获取的PID信息在任务管理器中的详细信息一栏中找到对应的程序，右键打开文件位置，获取异常文件目录；

  e. 进入到异常文件目录中，对文件进行分析，确认是否属于挖矿程序；

• 使用命令分析确认：打开终端或powershell：win + r 快捷键，输入 cmd

# 获取所有进程详情并将结果输出到tmp.txt文件
wmic process get caption,commandline /value >> tmp.txt
# 获取单一进程详情
wmic process where caption=”svchost.exe” get caption,commandline /value
# 获取子进程的父进程信息
wmic process where Name="svchost.exe" get ParentProcessID

• 使用第三方工具分析确认：各有千秋，大家自己选择。
• Process Monitor：无需安装
• Process Hacker：无需安装
• 火绒剑：需安装，界面展示更友好(个人意见)

2.1.2 Linux确认挖矿

a. 使用top命令查看系统性能，找出消耗资源较高的进程PID；

b. 根据获取的PID信息利用ps -ef -p PID命令找出系统进程详细信息；

c. 根据进程详细信息定位到文件位置，进入文件位置进行文件分析，确认是否属于挖矿程序。

# 除了top之外，还有很多比较好用的一些Linux命令
uptime # 查看机器的负载情况
vmstat 1 # 每秒输出一次系统核心指标
mpstat -P ALL 1 # 每秒显示所有CPU的占用情况
pidstat 1 # 每秒输出一次CPU的占用率
iostat -xz 1 # 每秒输出一次磁盘IO
# 在使用ps时，需要注意一些ps的参数

2.2 确认挖矿后的清理工作

当我们通过2.1确认服务器或PC属于被挖矿后，我们需要执行清理工作。当然了关于不同应急响应人员在执行2.2与2.3这两步时顺序可能不太一样，在小B看来没什么区别，如果先分析再删除，更多是为了不破坏被攻击的环境方便溯源；但是如果我们在整个过程中做好完整的备份与记录，先删除再分析也OK。

下面是一些常见的清理挖矿方法：

2.2.1 Windows清理挖矿

在2.1.1小节确认挖矿程序后，先对挖矿程序进行备份。然后先关闭对应的服务与进程，再删除对应的定时任务，最后删除对应的文件。在删除文件之后，反向再查询一遍定时任务、进程与服务，最好是在间隔一定时间段后再复查一次。

在Windows中通常使用图形界面进行操作，所以就不废话了。

2.2.2 Linux清理挖矿

Linux中在确认挖矿以后，也同样需要备份挖矿程序，再执行响应的操作。

• 停止服务：systemctl stop *.service；
• 杀掉进程：kill 9 PID，很多时候不光杀掉一个进程；
• 删除文件：rm -fr abnormal_file，删除文件时可以使用find / -name abnormal_file查找出系统中所有的恶意文件；
• 清理定时任务：crontab -e；

与Windows相同的是在删除完成后我们需要反向操作一次与间隔一定时间后再复查一次是否清理干净。

2.3 为什么会被挖矿（溯源）？

2.3.1 用户分析

主要分析用户的新增、修改(用户属性的修改)、删除、登录，以及两类用户：特权用户和可登录用户。

• Linux：分析用户除了使用命令之外，还可以使用系统日志和安全设备日志进行分析。

cat /etc/passwd # 查看用户信息
awk -F ":" '{ if($3==0)print $1 }' /etc/passwd # 查看特权账户
awk -F ":" '{ print $1,$7 }' /etc/passwd | grep -E "/bin/bash*" # 查看可登陆用户
# 除此之外Linux还有很多查看用户登录信息的命令
lastlog
users
w # w -s
who # who | cut -d' ' -f1 | sort | uniq
whoami

• Windows：分析用户可以使用图形化界面：控制面板 --> 用户账户，也可以通过命令行进行分析，对于Windows要分析历史登录用户信息需要从系统事件日志或安全设备日志着手，我这边没有发现有效的命令，大家知道可以私我。

net user # 查看用户，值得注意的是，如果攻击者添加一个类似username$的用户，使用net user命令查看不到
net localgroup administrators # 查看属于管理员组用户，使用此命令可以看到类似username$的用户
query user # 查询当前登录用户

2.3.2 端口与网络连接分析

在分析端口与网络连接时有2个点需要注意，一是系统开放给互联网的端口并不一定真实开放了，需要考虑是否有防火墙等因素的存在，如果有我们还需要分析防火墙的规则；二是攻击者可能不一定是通过被挖矿服务器攻入，也可能是通过局域网内部其他机器侵入。

• Linux：分析端口与网络连接可以使用命令，还可以使用第三方工具tcpdump与网络流量监控设备等。

netstat -tulnp # 查看系统的udp与tcp连接

• Windows：分析端口与网络连接可以使用命令，也可以使用第三方工具windump、wireshark等。

netstat -ano | find "ACK"
netstat -ano -p tcp | findstr "LISTENING"

2.3.3 定时任务分析

分析定时任务需要注意不同目录、不同用户下的定时任务。

• Linux

# 查看crontab目录中所有文件
cat /etc/cron.*/*
cat /etc/crontab
# 查看不同用户的定时任务
crontab -u username -l
# 通过定时任务日志进行分析
cat /var/log/cron*

• Windows：对于Windows中的定时任务，一般有两种形态：一是图形化界面管理工具 --> 任务计划程序(PS：2008之后任务计划程序不在控制面板中了，而是在管理工具中) ；二是BAT文件。前者打开即可查看，后者需要找到对应的文件进行查看。

2.3.4 启动项分析

• Linux

# 查看所有已启动服务
systemctl list-units --type=service
# 查看服务启动项
systemctl list-unit-files | grep enabled

• Windows：对于Windows的启动项有两种形式分析
• win + r，输入shell:startup 查看。
• 注册表启动项：：win + r，输入regedit，找到HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run查看

2.3.5 历史命令分析

历史命令分析一般只可以在Linux上进行分析，并且要保证历史执行命令以日志形式存储到统一日志分析平台中，否则历史命令容易被攻击者清除，并且如果攻击者未登陆服务器(以webshell的形式)执行命令也记录不到攻击者执行的命令。

2.3.6 日志分析

溯源很多程度依赖日志分析，不论是 Windows Server 或者是 Linux Server ，我们都需要从日志中提取攻击者的攻击路径，是通过暴力破解服务还是通过应用层服务进入都可以从日志中找到痕迹，这里不做太多的叙述，大家有兴趣可以读一下公众号heysec的日志分析系列，关于分析的文章后续会陆续放出。

特定说一下的是Linux下的日志可以通过 awk、grep、sed 等命令直接进行分析，在文末的Refer中我有引入一些比较好的文章大家可以查看；对于Windows查看事件日志可以在图形化界面直接查看 win + r，输入eventvwr 或者 控制面板 --> 系统和安全 --> 查看事件日志 。

2.3.7 病毒木马等分析

• Webshell：可以使用免费的一些工具对系统网站目录进行排查与分析。
• Linux：相对Windows来说，Linux的病毒木马较少，主要是分析是否有rootkit，可以使用chkrootkit与rkhunter检查后门或rootkit信息。
• Windows：Windows有很多的恶意病毒查杀软件，包括上文中提到的火绒也可以进行分析。

分析方法还可以查找系统特定目录最近一段时间被修改或访问过的文件。

2.3.8 通过挖矿程序分析

在找到挖矿程序之后，首先我们可以分析挖矿程序在服务器或PC做的操作，这有助于帮助我们清理挖矿程序；其次我们还可以得到几个基本信息，利用这些信息我们也可以对其进行溯源。大部分的挖矿程序都是脚本文件可以直接使用文本编辑器进行分析，仅有少部分的挖矿程序需要用到类似WinHex等专业的文本工具。

• 挖矿程序运行用户，比如运用Confluence用户运行挖矿程序，很可能意味着我们服务器上的Confluence被攻陷了。
• 挖矿程序自身特征：名称、矿池或钱包地址。

2.3.9 模拟攻击

通过模拟攻击者入侵的方式，对目标进行以获取权限的多维度渗透，一般耗时比较久不到万不得已一般不推荐使用。主要包括：端口扫描、暴力破解、GetWebShell、RCE、未授权访问等主流的获取权限方式。

2.3.10 其他信息

• 服务器或PC补丁安装信息；
• 服务器或PC运行服务版本信息；
• …………

2.4 对被攻陷目标进行安全加固

其实做加固，大部分情况都是如下三种：

1. 打补丁或升级版本：不论是系统、应用程序、服务组件等都应该使用不含有已知高危漏洞的版本；
2. 关端口或者通过防火墙做访问控制策略；
3. 购买安全防护产品：IDS、IPS、Firewalls等；

2.5 举一反三内部排查

当我们完成了以上所有步骤后，我们还有件事情待做，这也是很多应急响应程序中忽视的一步，就是通过当前的整个过程去排查内部服务器或PC是否还有被挖矿的情况。也许没有被挖矿的情况但服务器或PC存在被攻击的可能性也是我们需要去排查的。

做完这一步，整个挖矿的应急响应流程也就基本结束了，写好报告进行汇报就是最后的收尾工作了！

3.常见的挖矿附链接

一般挖矿的攻击者是不会去找一些复杂的入侵手段的，目前市面上比较多的挖矿都是未授权访问和RCE漏洞，所以大家平时在对内部服务器或PC进行扫描或者测试的时候需要额外注意这类型的漏洞，以及在分析的时候也可以多向这个思路靠近。

阅读原文

跳转微信打开

本文将分享一个RocketMQ的漏洞从发现到自动化利用的实践过程，最后也将安利一个开源的神器Arthas(阿尔萨斯)。本文技术含金量不高，但也希望读者能从中有所收获。

1.1 架构简图

1.2 如何运行RocketMQ

1.3 可视化管理界面：rocketmq-console

java -Xmx512m -Xms512m -jar rocketmq-console-ng-1.0.0.jar --server.port=8081
--rocketmq.config.namesrvAddr="10.13.32.203:9876" --auth.username=admin --auth.password=admin

1.4 消息存储

${rocketmq.home}/store/consumequeue/${topicName}/${queueId}/${fileName}

1.5 构造一个生产者

2.1 像黑客一样思考

The specified topic[../../../fuzz2019] contains illegal characters, allowing only ^[%|a-zA-Z0-9_-]+$

2.2 想办法进行POC验证

1. 使用IDE工具调试功能，通过下断点动态修改内存中Topic值。
2. 下载源码修改检查逻辑后，编译新的rocketmq-client包导入使用。
3. 使用JAVA Agent技术，运行时修改对象的值。

broker/src/main/java/org/apache/rocketmq/broker/processor/AbstractSendMessageProcessor.java

1. 不能覆盖已存在的文件夹，因为服务端检查会认为已经存在该文件夹，然后直接存放在其下面。
2. 不能控制生成任意的文件和文件内容

具体存储路径为：$HOME/store/consumequeue/{topic}/{queueId}/{fileName}。同样consumequeue文件采取定长设计，每一个条目共20个字节，分别为8字节的commitlog物理偏移量、4字节的消息长度、8字节tag hashcode，单个文件由30W个条目组成，可以像数组一样随机访问每一个条目，每个ConsumeQueue文件大小约5.72M

3.1 编写用于Hook 替换的目标Class

3.2 编写agent代理

@Override
public byte[] transform(ClassLoader loader, String className, Class<?> classBeingRedefined, ProtectionDomain protectionDomain, byte[] classfileBuffer) throws IllegalClassFormatException {
    System.out.println("[transform] hotswap class name :" + className);
    if ("org/apache/rocketmq/client/Validators".equalsIgnoreCase(className)){ //如果是目标类，则进行替换。
        byte[] bytes = fileToBytes(new File("/Users/CFHB/DevTools/rocketmq-master/client/target/classes/org/apache/rocketmq/client/Validators.class"));
        return bytes;
    }else{
        return null; // 返回null,表示不修改
    }

org/apache/rocketmq/client/Validators

maven clean
maven package
maven install

3.3 编写测试热更新代码

3.4 编写RocketMQ的生产者，发送payload

3.5 测试效果

4.1 官方发布4.6.1修复

4.2 安全实践

• 推荐使用最新版本，RocketMQ 4.6.1（已修复）
• rocketmq-client使用4.6.0以上版本（fastjson已升级到1.2.61）
• 禁止使用ROOT权限启用RocketMQ服务端和消费端
• 禁止自动创建topic，必须将autoCreateTopicEnableRocketMQ设置为false. 修改Broker配置文件，broker.properties，添加一项autoCreateTopicEnable=false.
• 配置ACL，开启用户身份认证。修改RocketMQ的默认端口9876为不常用端口，防止被扫描发现。

5.1 GitHub地址：

5.2 Arthas可以做什么？

• 这个类从哪个 jar 包加载的？为什么会报各种类相关的 Exception？
• 我改的代码为什么没有执行到？难道是我没 commit？分支搞错了？
• 遇到问题无法在线上 debug，难道只能通过加日志再重新发布吗？
• 线上遇到某个用户的数据处理有问题，但线上同样无法 debug，线下无法重现！
• 是否有一个全局视角来查看系统的运行状况？
• 有什么办法可以监控到JVM的实时运行状态？
• 怎么快速定位应用的热点，生成火焰图？

5.3 怎么使用

• 启动命令： java -jar arthas-boot.jar

• sc 命令

  

• watch命令

  

• sm命令

  

• jad命令

  

5.4 热更新-实例：bypass Rocketmq-client限制

1. java -jar arthas-boot.jar --telnet-port 9996 --http-port -1
2. jad --source-only org.apache.rocketmq.client.Validators > /tmp/Validators.java
3. vim /tmp/Validators.java, 注释掉check处代码
4. sc -d *Validators | grep classLoaderHash
5. mc -c 2a139a55 /tmp/Validators.java -d /tmp
6. redefine /tmp/org/apache/rocketmq/client/Validators.class

5.5 辅助发现SQL注入漏洞

• 类：java.sql.PreparedStatement 函数：prepareStatement 参数sql
• 类：java.sql.Statement 函数：executeQuery 参数 sql

5.6 取证冰蝎

 插播一则小广告

base：成都 or  深圳

招聘：安全攻防、安全研究

WeChatID：lc10516

阅读原文

跳转微信打开

本系列故事纯属虚构，如有雷同纯属巧合小B在实现了统一日志分析平台后，想到的第一个问题就是平台的安全性，用于安

小B在实现了统一日志分析平台后，想到的第一个问题就是平台的安全性，用于安全分析的平台被攻击成功，那么小B将颜面扫地还可能被扫地出门。所以小B认证分析了平台可能存在的安全风险：

• 平台产品自身的安全漏洞(解决方案：及时安装补丁或升级版本)；

• 数据泄露：在采集存储使用等过程中造成的数据泄露问题(解决方案：加密)；

• 未授权访问：平台无任何访问控制措施导致未授权访问(解决方案：见后文)；

对于平台的安全性，小B觉得首要的是使用没有已知漏洞的产品版本，其次就是添加访问控制。对于小B的日志分析平台，其中有这么几个地方需要额外注意：ES与Kibana的安全性、Kafka的安全性。

通用访问控制实现

# 如果操作系统是Centos系列7以上版本，推荐使用
# 保护Kafka与Zookeeper
# 只允许Kafka的机器访问ZK，这种方法也是最有效防护ZK未授权访问导致信息泄露的办法
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.10.10.9" port port="2181" protocol="tcp" accept'
# 只允许Beats机器访问Kafka
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.10.10.0/24" port port="9092" protocol="tcp" accept'
# 只允许办公网络IP访问Kibana
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="182.*.*.107" port port="5601" protocol="tcp" accept'
# 如果白名单IP比较分散，可以使用firewall结合ipset，关于ipset的使用大家就自行百度吧！
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source ipset="ipset_name" port port="9092" protocol="tcp" accept'

Elastic安全性

# 停止Kibana与elasticsearch服务
systemctl stop kibana.service
systemctl stop elasticsearch.service
# 创建es证书颁发机构
/usr/share/elasticsearch/bin/elasticsearch-certutil ca
# 创建es集群通信证书
/usr/share/elasticsearch/bin/elasticsearch-certutil cert --ca /etc/elasticsearch/elastic-stack-ca.p12

# 修改证书权限
chmod 644 /etc/elasticsearch/elastic-certificates.p12
# 修改配置文件
vim /etc/elasticsearch/elasticsearch.yml
# 在文件末尾添加如下内容

xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: /etc/elasticsearch/elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: /etc/elasticsearch/elastic-certificates.p12

# 如果配置了证书密码
# /usr/share/elasticsearch/bin/elasticsearch-keystore add xpack.security.transport.ssl.keystore.secure_password
# /usr/share/elasticsearch/bin/elasticsearch-keystore add xpack.security.transport.ssl.truststore.secure_password
# 启动Elasticsearch服务
systemctl start elasticsearch.service
# 创建账号密码
/usr/share/elasticsearch/bin/elasticsearch-setup-passwords interactive

• elastic：超级用户
• apm_system：使用APM时的用户
• kibana：用来连接ES的用户
• logstash_system：使用Logstash时的用户
• beats_system：使用Beats时的用户
• remote_monitoring_user：收集和存储监控信息的用户

# 修改kibana配置文件
vim /etc/kibana/kibana.yml
# 在文件末尾添加如下内容

elasticsearch.username: "kibana"
elasticsearch.password: "kibana"

# 启动kibana
systemctl start kibana.service
# 使用elastc账户登录kibana

• 方法一：使用Nginx Proxy实现

# 安装认证模块
yum install httpd-tools.x86_64 -y
# 创建认证账号
htpasswd -cm /etc/nginx/kibana-user kibana
# 配置nginx
vim /etc/nginx/nginx.conf

server {
        listen       80;
        server_name  kibana;
        auth_basic      "Restricted Access";
        auth_basic_user_file    /opt/nginx/conf/kibana-user;
        #charset koi8-r;
        #access_log  logs/host.access.log  main;
        location / {
            proxy_pass http://10.10.10.9:5601;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';
            proxy_set_header Host $host;
            proxy_cache_bypass $http_upgrade;
        }
    }

• 方法二：使用Nginx Lua实现

• SearchGuard：http://docs.search-guard.com/latest/index (来自小B朋友的用后感：不稳定、插件容易出问题)
• Shield：https://www.elastic.co/guide/en/shield/current/index.html (没有使用过不做评论)

Kafka与Zookeeper安全性

• TLS：提供加密，是否能解决未授权访问？未知。
• SASL：只针对客户端连接访问，无法解决Zookeeper未授权访问；
• ACL：只针对节点内的授权，无法解决Zookeeper未授权访问；

• 存放Broker节点的配置信息和controller节点的配置信息；
• 监听父节点的子节点列表来进行controller的选举；
• partition信息的存储；

1. 修改Zookeeper的配置文件，加入官网提供的配置文件

vim /opt/zookeeper-3.4.14/conf/zoo.cfg
# 在文件末尾添加如下内容

# 打开SASL开关
quorum.auth.enableSasl=true
# 打开Client-to-Server authentication
authProvider.1=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
quorum.cnxn.threads.size=20
# 认证模式使用SASL
requireClientAuthScheme=sasl

2. 创建Zookeeper的认证文件

vim /opt/zookeeper-3.4.14/conf/zookeeper-server.conf
# 创建一个用户名为kafka，密码为123456的用户信息

Server {
    org.apache.zookeeper.server.auth.DigestLoginModule required
    user_kafka="123456";
};

3. 修改Zookeeper运行的环境变量

vim /opt/zookeeper-3.4.14/bin/zkServer.sh
# 在140行，nohup后面加入运行的环境变量

# 原文 nohup "$JAVA" "-Dzookeeper.log.dir=${ZOO_LOG_DIR}" "-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
# 添加 -DJava.security.auth.login.config信息
nohup "$JAVA" "-Djava.security.auth.login.config=/opt/zookeeper-3.4.14/conf/zookeeper-server.conf" "-Dzookeeper.log.dir=${ZOO_LOG_DIR}" "-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \

4. 启动Zookeeper验证SASL是否配置成功

# 启动服务端
/opt/zookeeper-3.4.14/bin/zkServer.sh start
# 使用客户端连接
/opt/zookeeper-3.4.14/bin/zkCli.sh

5. 创建客户端认证文件

vim /opt/zookeeper-3.4.14/conf/zookeeper-client.conf

Client {
    org.apache.zookeeper.server.auth.DigestLoginModule required
    username="kafka"
    password="12345";
};

1. 在上面我们已经配置好了Zookeeper的SASL了，这里我们直接进行Kafka的SASL配置

# 首先修改Kafka服务端配置文件，启动SASL/PLAIN认证
vim /opt/kafka_2.11-2.3.1/config/server.properties

# PLAIN是SASL的一种认证方式，PLAINTEXT是通信过程是明文，不加密。
listeners=SASL_PLAINTEXT://10.10.10.9:9092
# 启用的认证模式PLAIN，也可使用GSSAPI
sasl.enabled.mechanisms=PLAIN
# kafka broker之间也需要使用PLAIN方式认证，也可使用GSSAPI
sasl.mechanism.inter.broker.protocol=PLAIN
# 通信为明文。如果需要使用SSL加密通信，则使用SASL_SSL，不过需要配置证书
security.inter.broker.protocol=SASL_PLAINTEXT

2. 创建一个Kafka的认证文件

vim /opt/kafka_2.11-2.3.1/config/kafka.conf
# kafkaServer为KafkaServer的SASL
# Client是Kafka用来连接Zookeeper的配置，如果不配置Client，会提示WARN不会报错，原理在上面已经解释过了

KafkaServer {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    username="kafka_user"
    password="kafka_pass"
    user_producer="producer"
    user_consumer="consumer";
};
Client {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    username="kafka"
    password="123456";
};

3. 修改Kafka运行的环境变量

vim /opt/kafka_2.11-2.3.1/bin/kafka-run-class.sh
# 找到KAKFA_OPTS

if [ -z "$KAFKA_OPTS" ]; then
  KAFKA_OPTS="-Djava.security.auth.login.config=/opt/kafka_2.11-2.3.1/config/kafka.conf"
fi

4. 启动Kafka并测试Kafka认证

# 启动Kafka服务
/opt/kafka_2.11-2.3.1/bin/kafka-server-start.sh -daemon /opt/kafka_2.11-2.3.1/config/server.properties
# 启动Kafka Producer测试是否能使用Kafka，记住先创建一个system-messages的topic
/opt/kafka_2.11-2.3.1/bin/kafka-console-producer.sh --broker-list 10.10.10.9:9092 --topic system-messages

5. 配置Kafka Client SASL认证

# 首先是修改Producer的配置文件
vim /opt/kafka_2.11-2.3.1/config/producer.properties
# 在文件末尾添加如下内容
# 如果不添加还是不能使用

security.protocol=SASL_PLAINTEXT
sasl.mechanism=PLAIN

# 其次是创建Kafka认证的文件，我这里Kafka CLient与Server是同一台，所以配置文件我写在同一个文件中
vim /opt/kafka_2.11-2.3.1/config/kafka.conf
# 在文件末尾添加如下内容

KafkaClient {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    username="producer"
    password="producer";
};

6. Kafka客户端配置完成后，我们再来测试

# 切记，必须制定producer的配置文件
/opt/kafka_2.11-2.3.1/bin/kafka-console-producer.sh --broker-list 10.10.10.9:9092 --topic system-messages

7. 与Producer一样的配置Consumer。如果你与小B一样使用的是一个配置文件就不用重复配置了，如果不是记得配置，并且需要指定运行环境变量。

1. 首先是Filebeat成为Kafka的Producer

vim /etc/filebeat/filebeat.yml

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/test.log
output.kafka:
  hosts: ["10.10.10.9:9092"]
  topic: "test"
  username: "producer"
  password: "producer"

2. 其次就是Logstash成为Kafka的Consumer

vim /etc/logstash/conf.d/kafka.conf

input {
	kafka {
		bootstrap_servers => "10.10.10.9:9092"
		security_protocol => "SASL_PLAINTEXT"
		sasl_mechanism => "PLAIN"
		jaas_path => "/etc/logstash/kafka-client-jaas.conf"
		topics => ["test"]
	}
}
output {
    stdout {}
}

# 配置Kafka的Client信息
vim /etc/logstash/kafka-client-jaas.conf

KafkaClient {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    username="consumer"
    password="consumer";
};

 

- HISTORY -

《日志分析系列(一)：介绍篇》

《日志分析系列(二)：平台实现篇》

《日志分析系列(外传一)：Nginx透过代理获取真实客户端IP》

《日志分析系列(外传二)：Nginx日志统一化》

阅读原文

跳转微信打开

本系列故事纯属虚构，如有雷同纯属巧合平台实现前的说明小B在给老板汇报了"统一日志分析平台"项目后，老板拍板立

本系列故事纯属虚构，如有雷同纯属巧合

平台实现前的说明

小B在给老板汇报了"统一日志分析平台"项目后，老板拍板立即开始做，争取下一次能及时发现攻击并且追踪攻击者。于是小B开始分析了市面上商业与开源的日志分析平台架构，大家都神似如下图：

知道了架构如何，接下来的关键就是每层之间选择什么样的产品了。关于如何选择，小B推荐了几个方面：

• 已有架构：避免基础能力的重复，使用目前IT基础框架中已有的东西。假设运维已经有一套ELK，就没有必要重复搭建，只需要与之结合优化数据源与增加安全分析场景即可。
• 技术实力：负责统一日志分析平台人员的技能栈。
• 产品自身优劣：不同产品有各自最适用的场景，所以选择合理产品是核心依据。

小B在选择产品时，参考了一些些资料(见参考资料)。

在经过一番对比之后，小B最终选择了以下产品来实现统一日志分析平台：

下面就容小B细细道来实现统一日志分析平台的那些心酸历程：(如果大家尝试复现小B的统一日志分析平台，请优先阅读踩坑记录，在文章末尾)

小B的统一日志分析平台结构(简易版，实际要复杂的多，这里只是一个Demo环境)：

搭建过程，我就不一一描述了，搭建自己可以查询相关产品的安装文档或者：

https://bloodzer0.github.io/ossa

实现日志采集处理与展示

>>>>

服务器日志

首先关注的是服务器上的日志，Q公司所有的服务器都是Linux(Centos7.x)，极大的减少了小B的工作：

服务器日志采集

• /var/log/audit/audit.log：审计日志，跟用户相关的日志。
• /var/log/cron：记录与系统定时任务相关的日志。
• /var/log/messages：记录系统中主要信息的日志。
• /var/log/secure：记录验证和授权方面信息的日志，如：ssh登录、su切换用户、sudo授权等。
• /var/log/yum.log：记录yum安装软件信息。

关于服务器日志采集filebeat提供了两种采集方法：

• 方法一：直接写配置文件采集：vim /etc/filebeat/filebeat.yml。
• 方法二：使用filebeat模块来收集，使用模块收集也是我们本次采用的方法。因为使用模块内置了pipeline可以解析服务器日志，并且在Kibana中提供了很多图表，减少我们的工作时间。备注：这里有坑，详情请看踩坑0x02

# 首先在我们的测试服务器上安装filebeat
rpm -ivh filebeat-7.4.1-x86_64.rpm
# 修改filebeat配置文件中的ES和Kibana地址，并初始化filebeat
vim /etc/filebeat/filebeat.yml

setup.kibana:
  host: "10.10.10.9:5601"
  
output.elasticsearch:
  hosts: ["10.10.10.9:9200"]

# 初始化filebeat
filebeat setup
# 启动filebeat模块
filebeat modules enable system
filebeat modules enable auditd
# 初始化filebeat模块的pipelines
filebeat setup --pipelines --modules system
filebeat setup --pipelines --modules auditd
# 修改system模块中日志文件路径
vim /etc/filebeat/modules.d/system.yml

- module: system
  syslog:
    enabled: true
    var.paths: ["/var/log/messages"]
  auth:
    enabled: true
    var.paths: ["/var/log/secure"]

# 修改audit模块中日志文件路径
vim /etc/filebeat/modules.d/auditd.yml

- module: auditd
  log:
    enabled: true
    var.paths: ["/var/log/audit/audit.log"]

# 修改filebeat配置文件中输出 为Kafka
vim /etc/filebeat/filebeat.yml

# output.elasticsearch:
#   hosts: ["10.10.10.9:9200"]
output.kafka:
  hosts: ["10.10.10.9:9092"]
  topics:
    # 这里的含义：当存在@metadata.pipeline字段时(这个字段是使用module默认生成的字段)，topic命名为%{[service.type]}-%{[fileset.name]}
    # 在这里推荐大家，如果不想使用我这种命名方式，可以使用kafka消费者查看详细信息，从信息中获取字段来命名
    - topic: '%{[service.type]}-%{[fileset.name]}'
      when.has_fields: ["@metadata.pipeline"]

# 测试配置文件
filebeat test config -c /etc/filebeat/filebeat.yml
# 启动filebeat
filebeat -e

一旦filebeat开始工作，我们就可以看到在kafka服务器上新增了三个topic：

这里我使用kafka消费topic查看日志消息内容，大家使用不同命名格式时也可以从这里获取。甚至可以在每一个topic的名称中包含客户端信息。

接下来我们需要使用logstash接受kafka的消息，并输出到ES中。需要注意的是，由于我们使用的是filebeat采集并且在ES与Kibana的配置中也是使用filebeat开头的template信息，所以我们输出的index前缀不要轻易修改，可以在中间添加我们需要的信息。

# 创建Logstash配置文件
vim /etc/logstash/conf.d/system.conf

input {
    kafka {
        bootstrap_servers => "10.10.10.9:9092"
        topics => ["system-auth","system-syslog","auditd-log"]
        codec => json
    }
}
output {
    if [@metadata][pipeline] and [@metadata][topic] == "auditd-log" {
        elasticsearch {
            hosts => ["10.10.10.9:9200"]
            index => "%{[@metadata][beat]}-%{[@metadata][version]}-audit-log-%{+YYYY.MM.dd}"
            pipeline => "%{[@metadata][pipeline]}"
        }
    }
    else if [@metadata][pipeline] and [@metadata][topic] == "system-syslog" {
        elasticsearch {
            hosts => ["10.10.10.9:9200"]
            index => "%{[@metadata][beat]}-%{[@metadata][version]}-system-syslog-%{+YYYY.MM.dd}"
            pipeline => "%{[@metadata][pipeline]}"
        }
    }
    
    # **********
}

# 启动Logstash
/usr/share/logstash/bin/logstash -f /etc/logstash/conf.d
# 查看Kibana中的索引信息

服务器日志展示

当一切完成后，我们可以在Kibana的Dashboard中查看默认配置好的图表：

总结一下： 对于服务器日志的收集处理小B觉得，如果你后续还考虑接入入侵检测与防护系统的日志的话，对于服务器日志这块相对可以忽略部分，因为这里能够分析处理的日志内容在入侵检测与防护日志中也能体现。

>>>>

Web日志

Q公司使用的Web服务器是Nginx，所以只需要对日志统一化，就很好处理

Web日志采集

• 方式一：使用Filebeat Module，但是如果自定义了日志格式，需要修改Filebeat的pipeline规则：vim /usr/share/filebeat/module/nginx/access/ingest/default.json
• 方式二：自己写Pattern解析，我们这里使用此种方法。

# 首先修改采集端filebeat的配置
vim /etc/filebeat/filebeat.yml

filebeat.inputs:
- type: log
  paths:
    - /opt/nginx/logs/access.log
  fields:
    nginx: access
  json.keys_under_root: true
  json.overwrite_keys: true
output.kafka:
  hosts: ["10.10.10.9:9092"]
  topics:
    - topic: '%{[service.type]}-%{[fileset.name]}'
      when.has_fields: ["@metadata.pipeline"]
    - topic: 'nginx-access'
      when.has_fields: ["fields.nginx"]

# 修改Logstash配置
vim /etc/logstash/conf.d/nginx.conf

input {
    kafka {
        bootstrap_servers => "10.10.10.9:9092"
        topics => ["nginx-access"]
        codec => json
    }
}
output {
	if [fields][nginx] == "access" {
        elasticsearch {
            hosts => ["10.10.10.9:9200"]
            index => "nginx-access-%{+YYYY.MM.dd}"
        }
    }
}

Web日志展示

总结一下： Web服务的日志很多时候是我们关注的重点，这里只是展示了采集与简单处理，在后续的分析篇中会提到更多关于Web日志的分析技巧。

>>>>

堡垒机日志

堡垒机日志采集

Q公司使用的堡垒机是开源JumpServer，版本信息是：1.5.4-2，JumpServer的相关信息在MySQL中，需要分析可以将结果从MySQL中获取，对于JumpServer日志分析也有两种方法：

• 写定时SQL将结果导出到文件中，在使用filebeat从文件中读取。
• 直接使用logstash jdbc input plugin，远程获取，我们这里使用此种方法(此种方法是没有使用到filebeat的)。

# 配置jumpserver Logstash采集
vim /etc/logstash/conf.d/jumpserver.conf

input {
  jdbc {
    jdbc_driver_library => "/usr/share/logstash/logstash-core/lib/jars/mysql-connector-java-5.1.36.jar"
    jdbc_driver_class => "com.mysql.jdbc.Driver"
    jdbc_paging_enabled => "true"
    jdbc_connection_string => "jdbc:mysql://10.10.10.6:3306/jumpserver"
    jdbc_user => "root"
    jdbc_password => "root"
    schedule => "*/1 * * * *"
    statement => "select * from terminal_session where date_start >= SUBDATE(now(),interval 481 minute)"
    type => "terminal_session"
  }
  jdbc {
    jdbc_driver_library => "/usr/share/logstash/logstash-core/lib/jars/mysql-connector-java-5.1.36.jar"
    jdbc_driver_class => "com.mysql.jdbc.Driver"
    jdbc_paging_enabled => "true"
    jdbc_connection_string => "jdbc:mysql://10.10.10.6:3306/jumpserver"
    jdbc_user => "root"
    jdbc_password => "root"
    schedule => "*/1 * * * *"
    statement => "select id,user,asset,system_user,input,session,timestamp,org_id from terminal_command where FROM_UNIXTIME(timestamp) >= SUBDATE(now(),interval 1 minute);"
    type => "terminal_command"
  }
}
output {
    if [type] == "terminal_session" {
        elasticsearch {
            hosts => ["10.10.10.9:9200"]
            index => "jumpserver-session-%{+YYYY.MM.dd}"
        }
    }
    else if [type] == "terminal_command" {
        elasticsearch {
            hosts => ["10.10.10.9:9200"]
            index => "jumpserver-command-%{+YYYY.MM.dd}"
        }
    }
}

堡垒机日志展示

总结一下： 对于堡垒机或者其他网络运维设备的日志，我们更多时候是将日志统一到日志平台中，然后进行展开的深入分析，包括：

• 异常的登录时间、地址位置、用户信息；
• 异常的操作行为等等；

这些都将在后续的分析中慢慢放出来。

>>>>

入侵检测系统日志

对于入侵检测系统，这里介绍两种开源的系统：Bro(Zeek)与Wazuh，前者在Elastic 7.x版本之后以SIEM形式提供支持，Wazuh自身可以与Elastic集成。所以这里也介绍两种入侵检测系统的日志收集处理展示方式：

使用Elastic SIEM

• 安装Bro网络入侵检测系统

# 安装依赖
yum install cmake.x86_64 gcc.x86_64 gcc-c++.x86_64 flex.x86_64 bison.x86_64 libpcap.x86_64 libpcap-devel.x86_64 openssl-devel.x86_64 python-devel.x86_64 swig.x86_64 zlib-devel.x86_64 -y
# 配置yum源
wget http://download.opensuse.org/repositories/network:bro/CentOS_7/network:bro.repo -O /etc/yum.repos.d/network:bro.repo
yum install bro.x86_64 -y
# 配置环境变量
echo 'export PATH=/opt/bro/bin:$PATH' >> /etc/profile
source /etc/profile

• 修改Bro的日志格式

vim /opt/bro/share/bro/site/local.bro

# 在文件末尾添加
@load tuning/json-logs
redef LogAscii::json_timestamps = JSON::TS_ISO8601;
redef LogAscii::use_json = T;

• 启动bro进行监控，启动前请修改配置文件(百度获取)

• 收集Bro日志到Elastic SIEM

# 启动zeek模块，执行这里时需要将output.kafka注释，还原output.elasticsearch
filebeat setup --pipelines --modules zeek
# 如果你已经执行初始化就不用重复执行了
filebeat -e
# Filebeat的配置文件与收集系统日志一致，只需要修改logstash的配置文件的input中的topic内容

input {
    kafka {
        bootstrap_servers => "10.10.10.9:9092"
        topics => ["system-auth","system-syslog","auditd-log","zeek-connection","zeek-dns","zeek-http","zeek-files"]
        codec => json
    }
}
# output内容不用变换，只需要替换条件即可

使用Wazuh+Elastic

关于Wazuh安装过程，我这里就不重复补充了，唯一说明一下是：在Filebeat的新版本中(没有具体测试从哪个版本开始)不支持多个output，所以我们这里还是output到kafka再到ES中。

• 修改filebeat的配置文件：vim /etc/filebeat/filebeat.yml

filebeat.modules:
  - module: wazuh
    alerts:
      enabled: true
    archives:
      enabled: false
setup.template.json.enabled: true
setup.template.json.path: '/etc/filebeat/wazuh-template.json'
setup.template.json.name: 'wazuh'
setup.template.overwrite: true
setup.ilm.enabled: false
output.kafka:
  hosts: ["10.10.10.9:9092"]
  topics:
    - topic: '%{[service.type]}-%{[fileset.name]}'
      when.has_fields: ["@metadata.pipeline"]

• 修改logstash配置文件：vim /etc/logstash/conf.d/wazuh.conf

input {
    kafka {
        bootstrap_servers => "10.10.10.9:9092"
        topics => ["wazuh-alert"]
        codec => json
    }
}
output {
    if [@metadata][pipeline] and [@metadata][topic] == "auditd-log" {
        elasticsearch {
            hosts => ["10.10.10.9:9200"]
            index => "wazuh-alerts-3.x-%{+YYYY.MM.dd}"
        }
    }
}

总结一下： 对于入侵检测与防护系统、WAF、防火墙等安全设备的日志，我们更多是收集日志做展示，需要基础的分析，因为日志自身本就是经过分析的，我们需要做的是对这些日志进行深入挖掘。

在本篇的平台实现就先到这里了，大致体现了几种不同类型的：收集方式 --> 存储 --> 展示 。因为篇幅原因不想写的太冗长影响阅读。后续还会有一些番外传：

• 利用大数据处理日志信息；
• 基于Elastic的监控报警系统；
• 统一日志分析平台的安全性；

踩坑记录

对于踩坑，最好的帮助就是多搜索，多看看官方的说明文档，所有的问题都会迎刃而解。

0x01 Filebeat output.kafka无法输出数据

必须在filebeat的客户端机器上配置域名解析：vim /etc/hosts

10.10.10.9      big_data

0x02 Logstash解析系统日志失败

如果大家使用Logstash自带的解析规则，在某些情况下会出现解析系统日志失败的情况，原因是因为：系统主机名包含下划线时会解析失败，我们来看一下Logstash中关于主机名部分的解析规则：vim /usr/share/logstash/vendor/bundle/jruby/2.5.0/gems/logstash-patterns-core-4.1.2/patterns/grok-patterns

此时的配置在出现下划线时就不能被正确解析

所以如果我们要使用，需要修改成如下图所示

# 将 HOSTNAME \b(?:[0-9A-Za-z][0-9A-Za-z-]{0,62})(?:\.(?:[0-9A-Za-z][0-9A-Za-z-]{0,62}))*(\.?|\b) 修改为
HOSTNAME \b(?:[0-9A-Za-z][0-9A-Za-z_-]{0,62})(?:\.(?:[0-9A-Za-z][0-9A-Za-z_-]{0,62}))*(\.?|\b) # 注意看两者多了两个下划线

如果使用Filebeat的模块，也会出现这个问题。

0x03 Logstash使用jdbc input

/usr/share/logstash/bin/logstash-plugin install logstash-input-jdbc
wget https://repo1.maven.org/maven2/mysql/mysql-connector-java/5.1.36/mysql-connector-java-5.1.36.jar -O /usr/share/logstash/logstash-core/lib/jars/mysql-connector-java-5.1.36.jar
chown logstash:logstash /usr/share/logstash/logstash-core/lib/jars/mysql-connector-java-5.1.36.jar
chmod 644 /usr/share/logstash/logstash-core/lib/jars/mysql-connector-java-5.1.36.jar

0x04 Kibana无法加载Wazuh-API配置页面

错误图：

原因分析：对比了官方的安装文档，如果在安装Kibana的插件时，使用root用户，那么就会报错。是因为使用root用户安装插件导致插件中的版本文件丢失。

解决方案：

sudo -u kibana /usr/share/kibana/bin/kibana-plugin install https://packages.wazuh.com/wazuhapp/wazuhapp-3.10.2_7.4.1.zip

 

阅读原文

跳转微信打开

本系列中的故事纯属虚构，如有雷同实属巧合

本系列故事纯属虚构，如有雷同纯属巧合

为了完成对Nginx服务器的日志分析，小B对Q公司的Nginx日志做了统一化要求。下面是小B在统一化过程中遇到的一些知识点：

Nginx日志与字段解析

Q公司的Nginx版本信息是：1.17.6，使用编译安装，安装过程如下：

yum install zlib-devel.x86_64 zlib.x86_64 openssl.x86_64 openssl-devel.x86_64 pcre-devel.x86_64 -y
# 安装lua支持，后续的response_body需要# 这里有坑，解决方案见最后wget http://luajit.org/download/LuaJIT-2.0.5.tar.gztar -xf LuaJIT-2.0.5.tar.gz -C /opt/ && cd /opt/LuaJIT-2.0.5/make install PREFIX=/usr/local/luajit
echo 'export LUAJIT_LIB=/usr/local/luajit/lib' >> /etc/profileecho 'export LUAJIT_INC=/usr/local/luajit/include/luajit-2.0' >> /etc/profilesource /etc/profile
# 下载ngx_devel_kitwget https://github.com/simpl/ngx_devel_kit/archive/v0.3.1.tar.gztar -xf v0.3.1.tar.gz -C /opt/
# 下载lua-nginx-module# 这里有坑，解决方案见最后wget https://github.com/openresty/lua-nginx-module/archive/v0.10.15.tar.gztar -xf v0.10.15.tar.gz -C /opt/
# 下载nginxwget https://nginx.org/download/nginx-1.17.6.tar.gztar -xf nginx-1.17.6.tar.gz && cd nginx-1.17.6/
# 安装nginx./configure --prefix=/opt/nginx --with-http_realip_module --with-http_ssl_module --with-pcre --with-ld-opt=-Wl,-rpath,/usr/local/luajit/lib --add-module=/opt/lua-nginx-module-0.10.15 --add-module=/opt/ngx_devel_kit-0.3.1
make -j2 && make install

• Nginx原始日志格式：vim /opt/nginx/conf/nginx.conf

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '                      '$status $body_bytes_sent "$http_referer" '                      '"$http_user_agent" "$http_x_forwarded_for"';
    access_log  logs/access.log  main;

• 原始Nginx的日志为：tail -n 1 -f /opt/nginx/logs/access.log

10.10.10.1 - - [18/Dec/2019:13:27:27 +0800] "GET / HTTP/1.1" 200 612 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.79 Safari/537.36" "-"

>>>>  Nginx日志字段解析

首先小B需要弄明白Nginx日志中每个字段的含义：

>>>>  Nginx获取body信息

在Q公司目前的架构中，使用GET传递参数的方式已经很少了，为了了解攻击者是否在body中嵌入攻击payload以及了解攻击者获取到了什么结果，小B需要采集body的日志信息。

打印request_body

打印request_body有两种方式：一种是使用nginx的模块；另外一种是使用lua编写脚本，如果需要限制nginx收集request_body的长度，最好使用后者。

• 使用nginx ngx_http_core模块采集request_body

ngx_http_core模块官网地址 http://nginx.org/en/docs/http/ngx_http_core_module.html 中有一段关于采集request_body的说明，内容如下：

The variable’s value is made available in locations processed by the proxy_pass, fastcgi_pass, uwsgi_pass, and scgi_pass directives when the request body was read to a memory buffer.

# 首先修改配置文件，我这里采集的日志只有request_body字段vim /opt/nginx/conf/nginx.conf

    log_format  main    $request_body;
    access_log  logs/access.log  main;
        location / {            root   /opt/nginx/html;            # 以下为添加内容            fastcgi_pass 127.0.0.1:9000;            fastcgi_index index.php;            fastcgi_param SCRIPT_FILENAME       $document_root$fastcgi_script_name;            include fastcgi_params;        }

此时Nginx的日志为：

使用ngx_http_core模块收集日志有没有办法限制request_body的长度呢？其实是有的。

在nginx配置文件中的http{}里面添加client_max_body_size 1k;即可。

但是这个配置是不允许用户上传超过1K大小的body内容，如果用户需要上传图片，业务可能就无法正常运行，所以不推荐使用此种方法。

我们在这里测试一下ngx_http_core的内容限制：

# 我这里使用1024个A来测试，我的配置是否有效curl -XPOST "http://10.10.10.13/test.php?id=123" -H "X-Forwarded-For: 10.10.10.5" -H "Referer: http://10.10.10.13" --data "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

此时Nginx正常打印出了request_body。

# 如果我们超过1024个字节，就会报错，注意1024个A后面有一个1curl -XPOST "http://10.10.10.13/test.php?id=123" -H "X-Forwarded-For: 10.10.10.5" -H "Referer: http://10.10.10.13" --data "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1"

此时Nginx无法打印request_body。

• 使用lua编写脚本采集request_body

# 修改nginx的配置文件vim /opt/nginx/conf/nginx.conf

    log_format  main    $request_body_head;
    access_log  logs/access.log  main;
        location / {            root   /opt/nginx/html;            # 以下为添加内容            set $request_body_head      "";            content_by_lua_block {                ngx.req.read_body()                local   req_body = ngx.req.get_body_data()                # 这里的1000代表我们截取request_body的长度，不要取的太长，否则容易导致日志过大                ngx.var.request_body_head =  req_body:sub(1,1000)            }        }

此时Nginx的日志为：

打印response_body

对于response_body我们只有使用lua编写脚本来采集。

• 修改nginx的配置：vim /opt/nginx/conf/nginx.conf

    server {        listen       80;        server_name  localhost;        # 以下为添加内容        lua_need_request_body   on;        set $response_body      "";        body_filter_by_lua      '            # 这里的1000就代表截取response_body的长度，不要取的太长，否则容易导致日志过大            local       response_body = string.sub(ngx.arg[1],1,1000)            ngx.ctx.buffered =  (ngx.ctx.buffered or "")        ..      response_body            if ngx.arg[2] then                ngx.var.response_body = ngx.ctx.buffered            end            ';    }

此时Nginx的日志为：

request_body与response_body如果在上传文件或者下载文件时，内容会很大，采集全部内容需要考虑对系统、Nginx性能和日志存储等方面的影响。如果采集的body内容太短，也会导致采取不到我们想要的信息，所以根据业务取一个合理阈值。

>>>>  nginx-->syslog-->logstash

小B在测试中与朋友交流得知，可以将nginx日志直接传输到logstash中而不落盘，但是这种方法传输的日志不可靠，并且会对nginx产生性能影响，可以在测试的时候使用。

• nginx配置文件：vim /opt/nginx/conf/nginx.conf

    log_format  logstash  '$remote_addr - $remote_user [$time_local] "$request" '                          '$status $body_bytes_sent "$http_referer" '                          '"$http_user_agent" "$http_x_forwarded_for"';    # access_log  logs/access.log  main;    access_log  syslog:server=127.0.0.1:514,nohostname,tag=nginx_access logstash;

• logstash配置文件：vim /etc/logstash/conf.d/nginx.conf

input {    udp {        host => "127.0.0.1"        port => 514    }}output {    stdout {}}

• 执行logstash，并查看效果：/usr/share/logstash/bin/logstash -f /etc/logstash/conf.d

统一Nginx日志格式

在完成了调研之后，小B就开始统一所有的日志字段了，为了方便后续查询分析操作，小B决定所有的字段采用JSON格式存盘，并且添加了运维、安全、研发都关注的字段。

• 修改配置文件：vim /opt/nginx/conf/nginx.conf

# 完整的nginx配置
worker_processes  1;events {    worker_connections  1024;}
http {    include       mime.types;    default_type  application/octet-stream;    log_format main     escape=json '{'                                        '"timestamp": $time_local '                                        '"remote_addr": $remote_addr '                                        '"remote_user": "$remote_user '                                        '"request_method": $request_method '                                        '"request_uri": "$request_uri" '                                        '"request_protocol": "$server_protocol" '                                        '"request_length": $request_length '                                        '"request_time": $request_time '                                        '"request_body_head": "$request_body_head" '                                        '"response_status": $status '                                        '"body_bytes_sent": $body_bytes_sent '                                        '"bytes_sent": $bytes_sent '                                        '"response_body": "$response_body" '                                        '"http_referer": "$http_referer" '                                        '"http_user_agent": "$http_user_agent" '                                        '"http_x_forwarded_for": "$http_x_forwarded_for" '                                        '"http_host": "$http_host" '                                        '"server_name": "$server_name" '                                        '"upstream_addr": "$upstream_addr" '                                        '"upstream_status": $upstream_status'                                        '}';                                            access_log  logs/access.log  main;    sendfile        on;    keepalive_timeout  65;        server {        listen       80;        server_name  localhost;      lua_need_request_body   on;      set $response_body      "";      body_filter_by_lua      '          local       response_body = string.sub(ngx.arg[1],1,1000)          ngx.ctx.buffered =  (ngx.ctx.buffered or "")        ..      response_body          if ngx.arg[2] then            ngx.var.response_body = ngx.ctx.buffered          end      ';
        location /lua {          root  html;          index  index.html;          set $request_body_head      "";          content_by_lua_block {            ngx.req.read_body()            local   req_body = ngx.req.get_body_data()            ngx.var.request_body_head =  req_body:sub(1,1000)          }        }
        error_page   500 502 503 504  /50x.html;        location = /50x.html {            root   html;        }    }}

此时Nginx的日志为：

>>>>  小结一下

• 对于timestamp参数，可以不使用time_local而使用time_iso8601。
• 如果运维对于网络的性能有要求，可以考虑使用$tcpinfo_rtt, $tcpinfo_rttvar, $tcpinfo_snd_cwnd, $tcpinfo_rcv_space这些参数可能需要我们给nginx添加其他模块。

踩坑记录

>>>>  启动nginx报错

• 由于luajit导致的报错

nginx: [alert] detected a LuaJIT version which is not OpenResty's; many optimizations will be disabled and performance will be compromised (see https://github.com/openresty/luajit2 for OpenResty's LuaJIT or, even better, consider using the OpenResty releases from https://openresty.org/en/download.html)

解决方案：卸载原有的luajit

wget https://github.com/openresty/luajit2/archive/v2.1-20190912.tar.gztar -xf v2.1-20190912.tar.gz && cd luajit2-2.1-20190912/make install PREFIX=/usr/local/luajit
echo 'export LUAJIT_LIB=/usr/local/luajit/lib' >> /etc/profileecho 'export LUAJIT_INC=/usr/local/luajit/include/luajit-2.1' >> /etc/profilesource /etc/profile

• 由于lua-nginx-module导致的报错

nginx: [error] lua_load_resty_core failed to load the resty.core module from https://github.com/openresty/lua-resty-core; ensure you are using an OpenResty release from https://openresty.org/en/download.html (rc: 2, reason: module 'resty.core' not found:

解决方案：不要使用v0.10.15，使用14就没有问题了

wget https://github.com/openresty/lua-nginx-module/archive/v0.10.14.tar.gztar -xf v0.10.14.tar.gz -C /opt/
# 安装nginx./configure --prefix=/opt/nginx --with-http_realip_module --with-http_ssl_module --with-pcre --with-ld-opt=-Wl,-rpath,/usr/local/luajit/lib --add-module=/opt/lua-nginx-module-0.10.14 --add-module=/opt/ngx_devel_kit-0.3.1
make -j2 && make install

 

- 参考资料 -

《Nginx安装Lua支持》：http://1t.click/b6ru

《Nginx安装lua-nginx-module》：http://1t.click/b6tw

- HISTORY -

《日志分析系列(一)：介绍篇》

《日志分析系列(外传一)：Nginx透过代理获取真实客户端IP》

阅读原文

跳转微信打开

小B是Q公司的安全攻城狮，最近Q公司不太平，出现了好几次的安全攻击事件。可在事后小B却找不到被攻击的真正原因，于是领导下命令给小B，必须做到对攻击事件的检测与溯源，不然就可以卷铺盖回家了。

本系列故事纯属虚构，如有雷同实属巧合

小B是Q公司的安全攻城狮，最近Q公司不太平，出现了好几次的安全攻击事件。可在事后小B却找不到被攻击的真正原因，于是领导下命令给小B，必须做到对攻击事件的检测与溯源，不然就可以卷铺盖回家了。

听到此话的小B冷汗连连，找到最近几次攻击的记录文档，认真剖析未发现真相的原因，总结如下：

• 系统未记录日志：部分系统无日志信息可用。
• 日志信息无备份：日志被攻击者删除，或因存储空间不够被删除，无备份日志可用。
• 采集维度不详细：日志格式为默认配置，不够详细，不能从中提取太多有效价值信息。
• 采集信息不准确：类似IP等用户识别维度信息不准确，不能定位到攻击者。
• 记录结果不统一：相同字段在不同的日志中类型不统一，无法进行日志关联。

找到了原因，小B就知晓了要想解决这些问题，就必须实现统一日志分析平台。拥有了这个平台，那么在下一次面对攻击时就不会那么两眼一抹黑了。

小B说目的

建设统一日志分析平台，小B需要先向领导汇报得到领导的支持。首要就是向领导说明搭建统一日志分析平台的目的。

日志分析在企业内部是一项很基础的核心技术，不光运用在安全团队中，还运用在IT研发团队、业务团队中。不同的是目的：

• 从安全来看：安全团队提取日志分析主要是为了发现未知安全事件、对已知的安全事件进行溯源分析。还有另外一个很重要的目的是国家层面的监管合规要求。
• 从IT研发来看：企业内部的非安全技术团队做日志分析主要也是为了发现位置问题、分析已知问题，主要集中在：系统监控、APM(APM包含了研发团队关注的所有监控项)。
• 从业务来看：业务团队对于日志分析的需求，更多集中在风险控制、运营推广、用户画像、网站画像等方面。

日志躺在硬盘中毫无价值，通过日志分析技术能实现日志信息的价值化。日志价值体现程度越高，也能变相反映公司的技术实力。

日志分析的更新换代

日志分析并不是一项新颖的技术了，虽然现在有人给它换了很多新衣。但是对于只有较小安全团队的公司来说，不要追求高大上的地图炮，需要的是实际解决问题的思路或工具，哪怕是一段只有20行的命令脚本都可以。从古至今，小B将日志分析经历划分成了4个时代：

石器时代： 这个时代大家在做日志分析的时候更多依靠的是Excel、终端命令(awk、grep、sort、uniq、wc等)。在这里推荐大家阅读 Web日志安全分析技巧 与 Web日志安全分析浅谈(https://xz.aliyun.com/t/1121)，其中提到了关于使用命令来进行安全分析的案例。

铁器时代： 这个时代大家在做日志分析的时候更多依靠的是脚本工具(自写工具)、简易交互式工具(logwatch、logparser)等。

工业时代： 这个时代大家在做日志分析的时候相比前两个时代已经有了太多的进步了，各种开源、免费、付费的软件可供选择，比如：Elastic系列、Splunk、ArcSight等等。

未来时代： 这个时代大家在做日志分析的时候我不知道会用到什么，但是从目前来看，机器学习、人工智能应该是核心之一。

小B是这么认为的：不论我们处在哪个时代，过去的思路与工具都有着不可替代之处。因为那是一个时代经历了优胜劣汰之后留下的优秀产物，本质上新时代的产品也是经历史长河演变而来。(内心OS：有小部分的工具或系统是辣鸡的，大家慎用！)

如何实现统一日志分析平台

>>>>

统一日志分析架构

实现统一日志分析平台在不同企业中各不相同。主要表现在：平台对企业的适用性、企业自身的技术能力、技术团队对产品的优劣选择不同等。但是核心的架构基本还是如下图所示：

>>>>

实现统一日志分析难点

• 难度1：技术难点
• 复杂的网络环境如何来采集信息？
• 繁杂的日志类型如何定义统一解析规则？
• TB甚至PB级别的日志如何快速查询？
• 地图炮无用什么才是最好的展示方式？
• 每天被报警打晕，如何自救？
• 难度2：人，主要体现在没有良好的沟通撕逼撕不过。
• 推动力度不够：老板不重视或伪重视；
• 推动阻力太大：别人是老板，你是工程师

小B作为一个安全工程师，理所当然的认为安全是最重要的(其实这是错误的)，但是小B也会灵活变通勾兑IT研发团队、业务团队一起推动，人多力量大。虽然大家的分析目的不一致，但是统一日志分析平台架构是大家都需要的。

>>>>

安全场景下的分析思路

如果硬要给安全场景分类的话，小B会分为：已知场景和未知场景。在已知场景中，我们常用的分析手法包括：基于正则表达式分析、基于统计聚合分析、基于关联分析；在未知场景中，我们使用的分析方法主要是数据挖掘，从数据中挖掘未知的东西。

基于正则表达式分析

此类的分析方法主要适用于常见带有特征的攻击场景，比如：

• 特定Payload场景：SQL注入、XSS、Bypass WAF等，可以总结为基于规则库进行分析；
• 特定关键字场景：爬虫(特定UA、Cookie等)；

基于统计与聚合分析

此类的分析方法是：尽可能在不同维度下进行统计与聚合，根据统计聚合结果挖掘有价值的信息。最常见的就是分析场景就是：单位时间内的某个客户端对某个服务端的操作信息。

基于关联分析

此类的分析方法，需要有一定的基础数据，通过关联分析来举一反三，比如

• 与外部情报关联分析：企业可以购买威胁情报(微步、威胁猎人)来关联内部的日志数据从而发现风险，比如：通过购买恶意域名情报，然后通过办公网出口流量与日志分析看是否有访问记录，如果有就可能代表内部有人中了木马或病毒。
• 与内部情报关联分析：以前面分析技术得到的结果作为依据标准来进行关联分析发现其他风险，比如：找到了一个恶意的用户IP，然后在日志分析系统中查找该IP的其它行为，说不定有意外收获，在IP这个维度要注意IP自身的属性信息。

数据挖掘分析

• 异常场景分析：通过聚类、分类等数据挖掘方法分析单点异常、上下文异常、集体异常等。
• 未知场景分析：通过机器学习算法识别0Day、Bypass技巧等。

日志分析的思路：思考各种场景，合理利用已有信息与可获取信息从而让信息产生价值。

>>>>

优化日志平台

统一日志分析平台不是简单的有一套系统，做个大屏biubiubiu就完事了的。搭建日志分析平台是一项集技术、沟通撕逼、运营的老大难项目，50%的人死在了起点、30%的人死在了中途、15%的人死在了成功的前一步，只有5%的人做好了这个平台。

日志分析坑太多，如果领导支持人力与财力，就可以考虑买一套产品再有人来维护是最好的状态！如果领导不支持人力与财力，算了吧！利用运维的东西做一做也挺好。

统一日志分析平台的工作在小B看来可以简单分为2个阶段：

1. 平台实现：日志规范化 --> 日志采集 --> 日志存储 --> 日志分析 --> 日志展示 --> 告警实现，在这些部分中，小B认为日志规范化是很重要的一步，因为这个步骤是牵扯到与其他团队的配合最多的一步，尽可能的把要做的工作集中一次性完成(虽然这是不可能的)。
2. 平台优化：这个阶段是对平台实现中的每一个步骤进行优化。

对于平台优化又可以简单细分为(小B能想到的就这么多)：

• 规范优化
• 日志种类优化：系统、服务、应用、业务等日志都需要采集；
• 日志字段优化：采集尽可能多且有用的信息；
• 日志格式优化：从TXT到JSON(从JSON到Protocol Buffer)；
• 采集优化：从Rsyslog到Logstash、从Logstash到Flume、Filebeat(主要是对客户端系统性能影响优化)；
• 传输优化：从无到有的消息队列、从不可靠传输(UDP)到可靠传输(TCP)、从无加密到加密(SSL)；
• 存储优化：从文本存储到数据库存储、从数据库存储到分布式文件系统；
• 分析优化：从单一场景到多场景、从经验之谈到数据分析技巧；
• 展示优化：从地图炮到直观安全风险展示、从单一到丰富；
• 告警优化：从每天报警不断到分级别告警、从单一告警方式到多层次告警；
• 架构优化：从单机到集群、从单集群到分布式集群；

关键是：持续运营，能力沉淀、数据沉淀

以上就是小B给领导汇报关于统一日志分析平台立项报告中的一些关键点了。

也许是因为开篇吧，十分不好写！日志分析这个话题以小B目前的水平也很难写的深入，大家将就看一下。

☞ 下一篇：小B就要开始实现统一日志分析平台了！

阅读原文

跳转微信打开