AppScan v10.0.7.28135 安装破解
HCL AppScan(原名IBM Security AppScan)是原IBM的Rational软件部门的一组网络安全测试和监控工具,2019年被HCL技术公司收购。AppScan旨在在开发过程中对Web应用程序的安全漏洞进行测试。
HCL AppScan(原名IBM Security AppScan)是原IBM的Rational软件部门的一组网络安全测试和监控工具,2019年被HCL技术公司收购。AppScan旨在在开发过程中对Web应用程序的安全漏洞进行测试。
Acunetix Web Vulnerability Scanner(简称AWVS)是一款知名的网络漏洞扫描工具,它通过网络爬虫测试你的网站安全,检测流行安全漏洞。
一个 Logstash 管道(pipeline) 至少要包含 2 个组件: input
及 output
,可以包含可选组件 filter
[2]
input
- 负责从数据源获取数据filter
- 负责按照配置修改数据output
- 负责将数据写入目标存储,如 Elasticsearch$ sudo rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch |
运行 Logstash 后,可以使用最基本的 Logstash Pipeline 测试 Logstash 运行是否正常
/usr/share/logstash/bin/logstash -e 'input { stdin { } } output { stdout {} }' |
-e
- 选项用来在 command line 中指定配置
运行之后在 shell 中输入内容,Logstash 会为数据添加元数据后输出到 stdout
,表明 Logstash 运行正常
hello world |
logstash
服务默认端口 5044
Elasticsearch 是一个开源的搜索引擎,建立在一个全文搜索引擎库 Apache Lucene [1] 基础之上。 Lucene 可以说是当下最先进、高性能、全功能的搜索引擎库 — 无论是开源还是私有。
但是 Lucene 仅仅只是一个库。为了充分发挥其功能,你需要使用 Java 并将 Lucene 直接集成到应用程序中。 更糟糕的是,您可能需要获得信息检索学位才能了解其工作原理。Lucene 非常 复杂。 [1]
Elasticsearch 也是使用 Java 编写的,它的内部使用 Lucene 做索引与搜索,但是它的目的是使全文检索变得简单, 通过隐藏 Lucene 的复杂性,取而代之的提供一套简单一致的 RESTful API。
然而,Elasticsearch 不仅仅是 Lucene,并且也不仅仅只是一个全文搜索引擎。 它可以被下面这样准确的形容:
Elasticsearch 将所有的功能打包成一个单独的服务,这样你可以通过程序与它提供的简单的 RESTful API 进行通信, 可以使用自己喜欢的编程语言充当 web 客户端,甚至可以使用命令行(去充当这个客户端)。
Elasticsearch 是 面向文档 的,意味着它存储整个对象或 文档。Elasticsearch 不仅存储文档,而且 索引 每个文档的内容,使之可以被检索。在 Elasticsearch 中,我们对文档进行索引、检索、排序和过滤—而不是对行列数据。这是一种完全不同的思考数据的方式,也是 Elasticsearch 能支持复杂全文检索的原因。 [2]
Elasticsearch 使用 JSON 作为文档的序列化格式 [2]
elasticsearch 主要使用以下端口
9200
- elasticsearch 服务的监听端口,客户端访问 9200 和 Elasticsearch 进行通信。9300
- 集群中的节点通过 9300 端口彼此通信,如果这个端口没有开,节点将无法形成一个集群Elasticsearch 的主要配置文件为,配置文件路径可以用环境变量 ES_PATH_CONF
指定。 [8]
elasticsearch.yml
jvm.options
log4j2.properties
Elasticsearch 已经有了
很好
的默认值,特别是涉及到性能相关的配置或者选项。 如果你有疑问,最好就不要动它。我们已经目睹了数十个因为错误的设置而导致毁灭的集群, 因为它的管理者总认为改动一个配置或者选项就可以带来 100 倍的提升。 [8]
配置文件格式支持 YAML 和 扁平 格式 [8]
YAML 格式示例
path: |
扁平 格式示例
path.data: /var/lib/elasticsearch |
Elasticsearch 默认启动的集群名字叫 elasticsearch
。生产环境中建议修改集群名称,防止其他使用默认集群名称的节点意外加入集群 [8]
同样,最好也修改你的节点名字。就像你现在可能发现的那样, Elasticsearch 会在节点启动的时候随机给它指定一个名字。你可能会觉得这很有趣,但是当凌晨 3 点钟的时候, 你还在尝试回忆哪台物理机是 Tagak the Leopard Lord 的时候,你就不觉得有趣了。
更重要的是,这些名字是在启动的时候产生的,每次启动节点, 它都会得到一个新的名字。这会使日志变得很混乱,因为所有节点的名称都是不断变化的。 [8]
cluster.name: elasticsearch |
监听接口相关配置
# 多网卡情况下,建议指定 IP 地址,以防止集群使用网络不通的 IP。# |
策略使用 HCL 或是 JSON 语法编写,描述了一个人类用户或是应用程序允许访问 Vault 中哪些路径。[1]
命令格式
$ vault policy write policy-name policy-file.hcl |
以下示例创建一个只读策略
$ cat readonly_policy.hcl |
更新策略使用和创建策略一样的命令,使用的是已有的策略名
$ vault policy list |
读取策略内容
$ vault policy read readonly_policy |
使用以下命令在创建 token 时附加策略,否则创建的 token 默认关联当前身份(如 token)的策略
$ vault token create -policy=readonly_policy -policy=logs |
关联策略时,如果关联的策略不存在,创建 token 只会给出相关策略不存在的 warnning,创建 token 不会失败
使用新建的 token 登陆并尝试更新相关键
$ vault login |
读取键,可以看到只能读取键值,无法写入
$ vault kv list |
下载已经编译好的 redis6-cluster 安装文件
wget https://s.csms.tech/redis6-cluster.tar |
本示例安装 3 master 3 slave 的 redis cluster,假设使用端口为 7380-7385。数据存放路径为 /data/redis/7380
,日志路径为 /data/logs/redis-cluster/7380/
,其他端口的 redis 服务配置以此类推,主要是修改对应端口。
创建服务启动需要的数据目录及日志目录
for i in 1 2 3 4 5 0 ; do mkdir -p /data/redis/738${i} ; done |
7380 服务使用如下配置文件
bind 0.0.0.0 |
若要根据以上 7380 端口的服务配置文件复制出其他服务端口的配置文件,可以参考以下命令
cp 7380.conf 7381.conf |
分别启动服务(7380-7385)
/usr/local/redis6-cluster/src/redis-server /usr/local/redis6-cluster/7380.conf |
Key/Value
机密引擎是一个通用的键值存储,用于在 Vault 使用的物理存储中存储任意秘密。该后端可以以两种模式之一运行 [1]
kv v1
- 可以将其配置为存储密钥的单个值,只有最近写入的值会被保存下来kv v2
- 开启版本控制并存储每个键的一定数量版本的值。默认保留 10 个版本的值。Version 1 的 KV Secret Engine 相比 v2 版本,有以下限制:
vault kv
的 metadata
、patch
命令vault kv put
写入的值会覆盖之前的内容,即只保存了最后一次写入的值。启用 version 1 的 kv 存储,没有 -version
选项时默认开启 version 1 版本的 kv:
$ vault secrets enable -version=1 kv |
与其他 Secret Engine 不同,kv 机密引擎不会强制执行 TTL 过期。即使设置了
ttl
,kv Secret Engine 也不会自行删除数据。 [1]
$ vault kv put kv/mycorp/mydepartment/myproject/myapp/myapp-api/config db_type=mysql |
$ vault secrets list |
$ vault kv get kv/mycorp/mydepartment/myproject/myapp/myapp-api/config |
以上输出中,键 kv/mycorp/mydepartment/myproject/myapp/myapp-api/config
的内容为 db_port=3306
,之前写入的其他数据被覆盖,只保留有最后一个写入
$ vault kv delete kv/mycorp/mydepartment/myproject/myapp/myapp-api/config |
下载 需要的版本
wget https://get.helm.sh/helm-v3.10.0-linux-amd64.tar.gz |
解压
tar -xf helm-v3.10.0-linux-amd64.tar.gz |
在解压目中找到 helm
程序,移动到需要的目录中
cp linux-amd64/helm /usr/local/bin/ |
验证
$ helm version |
helm ls |
$ helm ls -A |
$ helm repo ls |
搜索/查看可用的 repo
$ helm search repo hashicorp/vault |
查看可用的 releases
$ helm search repo hashicorp/vault -l |
$ helm install vault hashicorp/vault --version 0.25.0 |
Vault 的架构图如下 [1]
从以上架构图可以看到,几乎所有的 Vault 组件都被统称为 Barrier
(屏障)
Vault 架构可以大体分为三个部分: [7]
Sotrage Backend
- 存储后端Barrier
- 屏障层HTTPS API
- API 接口Storage Backend
- Vault 自身不存储数据,因此需要一个存储后端(Storage Backend
),存储后端对 Vault 来说是不受信任的,只用来存储加密数据。 [8]
Initialization
- Vault 在首次启动时需要初始化(Initialization
),这一步会生成一个 Master Key
(加密密钥)用于加密数据,只有加密完成的数据才能保存到 Storage Backend
Unseal
- Vault 启动后,因为不知道 Master Key
(加密密钥)所以无法解密数据(可以访问 Storage Backend
上的数据),这种状态被称为 Sealed
(已封印),在能解封(Unseal
)数据之前,Vault 无法进行任何操作。Unseal
是获取 Master Key
明文的过程,通过 Master Key
可以解密 Encryption Key
从而可以解密存储的数据 [6]
Master Key
- Encryption Key
(用来加密存储的数据,加密密钥和加密数据被一同存储) 是被 Master Key
(主密钥) 保护(加密),必须提供 Master Key
,Vault 才能解密出 Encryption Key
,从而完成数据解密操作。Master Key
与其他 Vault 数据被存放在一起,但使用另一种机制进行加密:解封密钥 ,解封密钥默认使用 沙米尔密钥分割算法 生成 Key Shares
[9]
Key Shares
- 默认情况下,Vault 使用 沙米尔密钥分割算法 将 Master Key
的解封密钥分割成五个 Key Shares
(分割密钥),必须要提供其中任意的三个 Key Shares
才能重建 Master Key
,以完成 Unseal
(解封)操作
Key Shares
(分割密钥)的总数,以及重建Master Key
(主密钥)最少需要的分割密钥数量,都是可以调整的。 沙米尔密钥分割算法 也可以关闭,这样主密钥将被直接提供给管理员,管理员可直接使用它进行解封操作。
在解密出 Encryption Key
后,Vault 就可以处理客户端请求了。 HTTPS API 请求进入后的整个流程都由 Vault Core
管理,Core
会强制进行 ACL 检查,并确保 Audit logging
(审计日志)完成记录。
客户端首次连接 Vault 时,需要首先完成身份认证,Vault 的 Auth Method
模块有很多的身份认证方法可选
user/password
、云服务商
、ldap
等,在创建用户的时候,需要为用户绑定 Policy
,给予适合的权限public/private keys
、token
、kubernetes
、jwt
等身份验证请求经 Core
转发给 Auth Method
进行认证,Auth Method
判定请求身份是否有效并返回关联的策略(ACL Policies
)的列表。
ACL Policies
由 Policy Store
负责管理与存储,Core
负责进行 ACL 检查,ACl 的默认行为是 Deny
,意味着除非明确配置 ACL Policy
允许某项操作,否则该操作将被拒绝。
在通过 Auth Method
进行认证,并返回了没有问题的 ACL Policies
后,Token Store
会生成并管理一个新的 Token
,这个 凭证 会返回给客户端,用于客户端后续请求的身份信息。Token
都存在一个 lease
(租期)。Token
关联了相关的 ACL Policies
,这些策略将被用于验证请求的权限。
请求经过验证后,将被路由到 Secret Engine
,如果 Secret Engine
返回了一个 secret
,Core
将其注册到 Expiration Manager
,并给它附件一个 Lease ID
,Lease ID
被客户端用于更新(renew
)或者吊销(revoke
)它得到的 secret
。如果客户端允许租约(lease
) 到期,Expiration Manager
将自动吊销(revoke
) 这个 secret
Secret Engine
是保存、生成或者加密数据的组件,非常灵活。有的 Secret Engin
只是单纯的存储与读取数据,比如 kv
(键值存储)就可以看作一个加密的 Redis。而其他的 Secret Engine
则可能连接到其他的服务并按需生成动态凭证等。
$ yum whatprovides ip |
rpm
查询已安装文件来自哪个安装包
$ rpm -qf /sbin/ip |
如果只下载安装包而不进行安装,可以使用 yumdownloader
命令,此命令来自安装包 yum-utils
,如果不存在可以安装 yum-utils
。
yumdownloader <package-name> |
以上下载指定的安装包而不安装,安装包会下载到当前目录
解决方法
修改对应 yum
源的配置文件,将其中的配置 gpgcheck=1
改为 gpgcheck=0
,以此跳过 key 验证
Prometheus 抓取 Nginx 运行时指标,主要有以下方法:
stub_status
页面 (需要 with-http_stub_status_module
模块支持) 暴露出了一些 Nginx 运行时的指标,较为简单,在 Prometheus 中对应的 Metrics 也少。nginx_exporter
主要就是获取 stub_status
中内建的指标。nginx-vts-exporter
监控 Nginx 更多的指标,但 nginx-vts-exporter
依赖于 Nginx 编译安装是添加的第三方模块 nginx-module-vts
来实现,指标更为丰富。建议使用此种监控方式。Nginx 安装了 nginx-module-vts
后,可以通过以下配置暴露运行时的指标
vhost_traffic_status_zone; |
重启 Nginx 后,访问 http://localhost:8081/status
即可查看到 Nginx 运行时的指标
wget https://github.com/hnlq715/nginx-vts-exporter/releases/download/v0.10.3/nginx-vts-exporter-0.10.3.linux-amd64.tar.gz |
创建 systemd
管理配置文件 /usr/lib/systemd/system/nginx-vts-exporter.service
|
启动服务,默认监听端口为 9913
systemctl enable --now nginx-vts-exporter |
浏览器访问 localhost:9913/metrics
即可看到 nginx-vts-exporter
暴露出来的 Metrics
之后 Prometheus 可通过 9913
端口抓取监控数据。
AlertManager 是一个专门用于实现告警的工具,可以实现接收 Prometheus 或其它应用发出的告警信息,并对这些告警信息进行 分组、抑制 以及 静默 等操作,然后通过 路由 的方式,根据不同的告警规则配置,分发到不同的告警路由策略中。 [1]
AlertManager 常用的功能主要有:
本文部署配置基于 K8S 上安装 Prometheus 并监控 K8S 集群
在名为 prometheus-server-conf
的 ConfigMap
中为 AlertManager 创建配置文件 alertmanager.yml
,并将其挂载到 AlertManager 容器中
global: |
使用为 Prometheus 创建的 PVC 作为 AlertManager 的持久存储,参考以下配置部署 AlertManager
apiVersion: apps/v1 |
部署成功后,从 AlertManager 的域名访问,可以看到 AlertManager 的 web UI
如上图所示,在每个数据中心部署单独的 Prometheus Server,用于采集当前数据中心监控数据。并由一个中心的 Prometheus Server 负责聚合多个数据中心的监控数据。这一特性在 Promthues 中称为 Federation (联邦集群)。
Prometheus Federation (联邦集群)的核心在于每一个 Prometheus Server 都包含一个用于获取当前实例中监控样本的接口 /federate
。对于中心 Prometheus Server 而言,无论是从其他的 Prometheus 实例还是 Exporter 实例中获取数据实际上并没有任何差异。
以下配置示例在中心 Prometheus Server 配置其抓取其他 Prometheus Server 的指标,必须至少有一个 match
配置,以指定要抓取的目标 Prometheus Server 的 Job 名称,可以使用正则表达式匹配抓取任务
scrape_configs: |
__name__
是 Prometheus 特殊的预定义标签,表示指标的名称
使用以下配置采集目标 Prometheus Server 的所有指标
params:
'match[]':
- '{job=~".*"}'
cAdvisor 是 Goolgle 开发的用来监控容器运行指标的工具,使用 Go 语言开发。Kubelet 集成了 cAdvisor 来监控采集 Pod 中的容器的运行指标。 [1]
可以直接使用 vAdvisor 配合 Prometheus 来监控 Docker/Containerd 容器运行指标,并配合 Prometheus 及 Grafana 进行图形展示或告警
下载二进制包,即可直接运行程序
wget https://github.com/google/cadvisor/releases/download/v0.47.0/cadvisor-v0.47.0-linux-amd64 |
运行之后,默认监听 8080
端口,启动后访问 UI : http://localhost:8080
。Prometheus 会读取 http://localhost:8080/metrics
暴露的指标。
在 cAdvisor
主机节点中可以使用以下命令列出收集到的指标
curl localhost:8080/metrics |
cAdvisor
的指标 container_last_seen
记录了最后一次检测到容器运行时的时间 (Gauge
),如果容器停止运行,这个值会停留在最后一次观察到容器运行的时间,可以通过此指标,使用以下表达式来监控容器是否在运行
container_last_seen - container_last_seen offset 1m == 0 |
执行以下命令安装 Go 环境
wget https://go.dev/dl/go1.14.15.linux-amd64.tar.gz |
执行 go
命令
$ go version |
安装后执行 go
报错
-bash: /usr/local/go/bin/go: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory |
问题原因 为下载的 go
与运行的目标系统不兼容,比如下载了 x86
的安装包,安装到了 64 位的 OS 上。
服务器环境信息说明
服务器 | IP | 配置 | 用途 |
---|---|---|---|
ceph-node-1 |
10.111.30.100 | centos 7 6.3.8-1 2c 3G 50G |
cephadm 节点monitor daemon |
ceph-node-2 |
10.111.30.110 | centos 7 6.3.8-1 2c 5G 50G |
|
ceph-node-3 |
10.111.30.120 | centos 7 6.3.8-1 2c 5G 50G |
本文档使用 cephadm
安装 Ceph Cluster,使用 cephadm
会首先在 Ceph Cluster 的第一个节点上安装第一个 monitor daemon
,安装时 monitor daemon
必须指定和集群通信的 IP 地址。 [3]
需要提前配置好集群节点服务器的主机名,并安装 Python 3、Docker。安装集群时,会自动安装 chrony
用来做时间同步
配置节点防火墙,允许节点之间网络互通
使用 curl
安装最新版本 [1]
CEPH_RELEASE=17.2.6 |
将 cephadm
安装到主机系统,Centos 7 未提供最新版本的 repo
./cephadm add-repo --release octopus |
检查安装后的 cephadm
命令路径
$ which cephadm |
Ceph 可以提供(实现)的存储方式包括:
Ceph 是一个分布式的存储系统,非常灵活,若需要扩容,只需要向集群增加节点(服务器)即可,其存储的数据采用多副本的方式进行存储,生产环境中,至少需要存 3 份副本。
包含常用工具:
Xshell 7.0.0
使用参考
fiddler-linux.zip
使用参考
Fiddler Everywhere 4.2.1
cwrsync_6.2.4_x64_free
使用参考
FileZilla_3.62.2_win64
openvpn-connect-3.3.7.2979_signed
VMware-workstation-full-17.0.0-20800274
CentOS-7-x86_64-Minimal-2207-02
Python 3.10.12 编译后的安装文件(Python-3.10.12.installed.tar
),可以 安装依赖 后,解压直接使用
HttpCanary
可以使用 shell 命令:
$ openssl rand -base64 |
具体示例,生成 8 位随机字符串
$ openssl rand -base64 8 |