confluence漏洞CVE-2021-26084处理 0x0 风险问题 参考注入代码： https://github.com/0xf4n9x/CVE-2021-26084 https://github.com/h3v0x/CVE-2021-26084_Confluence/ 注入POC： python3 POC.py -u "https://wiki.xxx.com" -e pwd 回显结果: [+] https://wiki.xxx.com/pages/createpage-entervariables.action?SpaceKey=x is vulnerable! /home/wiki/confluence/bin 0x1 防护措施 http://blog.nsfocus.net/atlassian-confluence/

nginx post body太大导致的异常 0x00 问题现象 用户端浏览器有如下报错： 500 Internal Server Error http code 500，但upstream后端未明显报错，那么可以确定是nginx错误，在nginx日志中看到到如下内容，猜测是文件太大而nginx设置的buffer太小出错 2022/01/25 09:51:47 [crit] 17901#0: *635241 open() "/usr/local/tengine/client_body_temp/0000001322" failed (13: Permission denied), client: 172.16.xx.xx, server: xxx.xxx.org.cn, request: "POST /whhscy/api/fileupload/services/upload HTTP/1.1", host: "xxx.xxx.org.cn", referrer: "https://xxx.xxx.org.cn/whhscy/SCHSJC/app/hsjc.app/miniprogram/index.mpg?:embedded=true&:drillPage=%2FSCHSJC%2Fapp%2Fhsjc.app%2Fminiprogram%2Frccy%2Frycydj_new_2.spg%3Fhyfs%3D1000%26:newData%3Dtrue%26pageCache%3DcreatePage%26cydd%3D%25E4%25B8%259C%25E8%25A5%25BF%25E6%25B9%2596%25E5%258C%25BA%25E7%258E%25AF%25E6%25B9%2596%25E4%25B8%25AD%25E8%25B7%25AF90%25E5%258F%25B7%26cyrq%3D20220125%26ssrq%3D7%26sglydw%3D4201190029221%26jcjgdm%3D420103010%26jcjgmc%3D%25E6%25AD%25A6%25E6%25B1%2589%25E8%2589%25BE%25E8%25BF%25AA%25E5%25BA%25B7%25E5%258C%25BB%25E5%25AD%25A6%25E6%25A3%2580%25E9%25AA%258C%25E6%2589%2580%25E6%259C%2589%25E9%2599%2590%25E5%2585%25AC%25E5%258F%25B8%26bblx%3D57%26bllx%3D9%26cyrw%3DCY006487%26cydw%3D4201190029221" 0x01 排查解决 这个问题直接原因就是因为客户端的post body太大，超过nginx配置的buffer大小，然后写入临时文件时又没有权限导致，有几个解决方案 解决buffer太小的问题，使得body可以存储在buffer中，但很多时候无法精准的控制用户的最大body大小，并且过大的值在高并发下必定会占用更多内存 解决文件夹权限问题，使得buffer不足得时候文件能否写入临时目录中，也可以规避此问题，一般可以设置nginx的启动user root，或者修改此文件夹权限

使用parted来分区超过2T的磁盘 问题现状 在mbr类型分区表中会使用16字节来表示分区的扇区大小，这最大只能表示2T的空间大小，一般单分区如果不超过2T使用fdisk来操作是足够的，但在单分区需要超过2T的场景下，就要使用gpt类型分区表了，它支持更多主分区个数和更大的分区大小，但fdisk对于gpt支持比较有限，无法很好的帮助我们完成分区，所以要借助其他工具完成 处理方法 使用parted来分区 parted /dev/sdb mklabel GPT mkpart primary 0% 100% quit partprobe mkfs.ext4 /dev/sdb1

升级openssh后机器无法登录 问题背景 物理机，系统为Centos7，升级默认的openssh为openssh-8.8p1版本，升级步骤与以前一致 问题现象 与其他若干机器使用批量命令同时升级后，只测试了几台机器都可以正常登录就没管了，几个小时后被告知有两台物理机使用普通用户和root用户均无法登录 排查解决 首先排除了端口问题，因为客户端是能ssh，只是登录提示密码错误，但也能肯定密码是没有修改过。怀疑是ip有冲突导致登录错了机器，云平台通过kvm检查了ip等配置后否定了，这两台机器ping网关之类的不会掉包并且机器接入的网络存储服务都正常。 继续排查了openssh的配置文件，也无任何错误，于是从日志入手，而/var/log/secure内的记录寥寥无几，又查看/var/log/messages，这回有了收获，通过测试登录终于有了明显的报错信息 Could not get shadow information for user 根据报错内容猜测是密码或者密码文件有问题，但也能确定是没有人为修改过的，检查了 /etc/passwd,/etc/shadow,/etc/shadow- 几个文件内容权限等也无异常。但有了线索终于可以向百度求助了，搜索一下才知道原来是selinux没有关闭导致的，顺利解决！ 感想 此次事件有以下几个经验： 虽然同时批量安装升级openssh，但基础环境不同还是可能导致出现问题 selinux这个东西太烦了，必须要在以后的各种维护操作之前确认已关闭

curl -d数据太长的问题 0x1 问题背景 在一次使用curl对图片的base64发送post请求时报错 /usr/bin/curl: Argument list too long 0x2 原因分析 简单的查了下，说是curl在命令行中传递base64内容就会这样，根本原因有兴趣再去了解 0x3 如何解决 curl支持读取文件内容，所以把文件作为参数即可: curl -X POST -d @filename.txt https://website.com/path 使用以下方式也可: echo "{\"images\": [\"$data\"]}" | \ curl -H "Content-Type:application/json" -X POST --data @- -X POST 'https://website.com/path'