分类目录归档：随手一贴

安装的mysql8.0.40版本，在漏扫中出现一个漏洞提示openssl版本过低

# 系统自带的openssl链接库文件在/usr/lib64下
[root@localhost ~]# cd /usr/lib64/
[root@localhost lib64]# ll libcrypto*
lrwxrwxrwx 1 root root      18 Oct  1 09:38 libcrypto.so -> libcrypto.so.3.2.2
lrwxrwxrwx 1 root root      18 Oct  1 09:38 libcrypto.so.3 -> libcrypto.so.3.2.2
-rwxr-xr-x 1 root root 5435440 Oct  1 09:38 libcrypto.so.3.2.2

[root@localhost lib64]# ll libssl*
-rwxr-xr-x. 1 root root 449560 Sep 16 11:38 libssl3.so
lrwxrwxrwx  1 root root     15 Oct  1 09:38 libssl.so -> libssl.so.3.2.2
lrwxrwxrwx  1 root root     15 Oct  1 09:38 libssl.so.3 -> libssl.so.3.2.2
-rwxr-xr-x  1 root root 957480 Oct  1 09:38 libssl.so.3.2.2

# 查看mysql载入的动态链接库路径
[root@localhost lib64]# ldd /usr/local/mysql/bin/mysql | grep libcrypto
	libcrypto.so.3 => /usr/local/mysql/bin/../lib/private/libcrypto.so.3 (0x00007f59b5e00000)
[root@localhost lib64]# ldd /usr/local/mysql/bin/mysqld | grep -i "ssl"
	libssl.so.3 => /usr/local/mysql/bin/../lib/private/libssl.so.3 (0x00007fa5b1e00000)
	
可以看到都是用的mysql自带的库

[root@localhost lib64]# strings /usr/local/mysql/lib/private/libcrypto.so.3 | grep -i "OpenSSL"
OpenSSL 3.0.15 3 Sep 2024
自带的是3.0.15版本，所以漏扫提示此版本有漏洞

解决方法：
# 通过输出环境变量，让mysql去读系统自带的openssl
[root@localhost lib64]# export LD_LIBRARY_PATH=/usr/lib64:$LD_LIBRARY_PATH
[root@localhost lib64]# systemctl restart mysql

# 再次确认
[root@localhost lib64]# ldd /usr/local/mysql/bin/mysqld | grep -i "ssl"
	libssl.so.3 => /usr/lib64/libssl.so.3 (0x00007fe9b4f1a000)
[root@localhost lib64]# ldd /usr/local/mysql/bin/mysql | grep libcrypto
	libcrypto.so.3 => /usr/lib64/libcrypto.so.3 (0x00007f262d600000)

[root@localhost ~]# strings /usr/lib64/libcrypto.so.3 | grep -i "OpenSSL"
OpenSSL 3.2.2 4 Jun 2024

浏览器访问80时实际是通过apache反向代理的6000端口，netstat查看监听端口6000并没有监听，说明openproject的web服务并未启动。

通过手动启动查看是否有报错

root@rd:/opt/openproject# /usr/bin/openproject run web
=> Booting Puma
=> Rails 7.1.4.1 application starting in production 
=> Run `bin/rails server --help` for more startup options
A server is already running. Check /opt/openproject/tmp/pids/server.pid.
Exiting

提示已经在运行，实际是因为pid文件没有正确关闭删除，导致pid文件存在。
将其删除后再次启动。

root@rd:/opt/openproject# cd /opt/openproject/tmp/pids
root@rd:/opt/openproject/tmp/pids# ll
total 12
drwxrwxr-x 2 openproject openproject 4096 Dec  9 00:44 ./
drwxr-xr-x 6 openproject openproject 4096 Dec 11 01:47 ../
-rw-r--r-- 1 openproject openproject    4 Dec  9 00:44 server.pid
root@rd:/opt/openproject/tmp/pids# rm -f server.pid 

root@rd:/opt/openproject/tmp/pids# systemctl start openproject.service
systemctl start openproject-web-1.service
systemctl start openproject-web.service
systemctl start openproject-worker-1.service
systemctl start openproject-worker.service
root@rd:/opt/openproject/tmp/pids# ll
total 8
drwxrwxr-x 2 openproject openproject 4096 Dec 11 03:30 ./
drwxr-xr-x 6 openproject openproject 4096 Dec 11 01:47 ../

启动需要一定时间
root@rd:/opt/openproject/tmp/pids# ll
total 12
drwxrwxr-x 2 openproject openproject 4096 Dec 11 03:32 ./
drwxr-xr-x 6 openproject openproject 4096 Dec 11 01:47 ../
-rw-r--r-- 1 openproject openproject    4 Dec 11 03:32 server.pid
root@rd:/opt/openproject/tmp/pids# netstat -tnlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.1:45432         0.0.0.0:*               LISTEN      3179/postgres       
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      788/systemd-resolve 
tcp        0      0 127.0.0.1:11211         0.0.0.0:*               LISTEN      819/memcached       
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      891/sshd: /usr/sbin 
tcp        0      0 127.0.0.1:6000          0.0.0.0:*               LISTEN      6270/puma 6.4.3 (tc 
tcp        0      0 127.0.0.1:6011          0.0.0.0:*               LISTEN      6166/sshd: rd@pts/2 
tcp        0      0 127.0.0.1:6010          0.0.0.0:*               LISTEN      1219/sshd: rd@pts/0 
tcp6       0      0 ::1:6010                :::*                    LISTEN      1219/sshd: rd@pts/0 
tcp6       0      0 ::1:6011                :::*                    LISTEN      6166/sshd: rd@pts/2 
tcp6       0      0 :::80                   :::*                    LISTEN      993/apache2         
tcp6       0      0 :::22                   :::*                    LISTEN      891/sshd: /usr/sbin 
root@rd:/opt/openproject/tmp/pids# 

重装软件及重装系统都无法解决，最终发现安装QuickTime后解决。
Flash CS6 依赖 QuickTime 来支持部分图像和视频格式。
下载地址：https://softdown.365xiazai.com/20241107/2651/down/2024down/9/11/QuickTime7.79.80.95.exe

安装后重启软件。

未安装之前：
导入 – 导入到舞台 – 选择tga文件，则提示 读取文件时出现问题

直接打开tga文件则提示 意外的文件格式

# 拉取docker镜像
docker pull atlassian/jira-servicemanagement

# 启动容器
# 挂载server.xml文件的原因是容器内修改server.xml后重启容器会还原文件，映射出来后添加chattr +i防止容器还原文件
docker run -dit --name=jsm -v /home/dockermount/jsm/jsm_data:/var/atlassian/application-data/jira -v /home/dockermount/jsm/config/server.xml:/opt/atlassian/jira/conf/server.xml -p 28080:8080 atlassian/jira-servicemanagement

# 下载jdbc8版本驱动
# jdbc安装文档
https://confluence.atlassian.com/adminjiraserver/connecting-jira-applications-to-mysql-8-0-1018775461.html#ConnectingJiraapplicationstoMySQL8.0-driver

# jdbc下载
https://downloads.mysql.com/archives/c-j/
选择8版本，系统选择platform independent，下载tar.gz包，解压找到jar包传到服务器，然后cp到容器

# mysql驱动放入lib目录
docker cp mysql-connector-j-8.4.0.jar jsm:/opt/atlassian/jira/lib/

# 破解程序放到根目录下
docker cp atlassian-agent.jar jsm:/

# 这个要配置
echo 'export CATALINA_OPTS="-javaagent:/atlassian-agent.jar ${CATALINA_OPTS}"' >> /opt/atlassian/jira/bin/setenv.sh 

# 重启容器
浏览器访问 ip:28080 完成安装，最后会出现一个 服务器 ID

# 生成激活码
java -jar atlassian-agent.jar -d -p jsm -m test@test.com -n BAT -o IT -s xxxx-xxxx-xxxx-xxxx

# 破解插件	
java -jar atlassian-agent.jar -d -p "com.reliex.activitytimeline.cloud.atlassian.connect" -m test@test.com -n BAT -o IT -s xxxx-xxxx-xxxx-xxxx

atlassian-agent地址：
https://github.com/qinyuxin99/atlassian-agent/releases/

JIRA Software（通常指jira）Project Management Software
JIRA Service Management（jsm）改名前叫 JIRA Service Desk（jsd）

XHR是传统的数据请求方式，而 Fetch API 则代表了现代Web开发的新兴标准。

fetch和XMLHttpRequest（XHR）在处理跨域请求时的行为有所不同。

# fetch
fetch默认不发送OPTIONS请求。
如果需要发送OPTIONS请求，需要显式地创建一个OPTIONS请求并使用fetch发送。

# XMLHttpRequest (XHR)
XHR在跨域请求时浏览器会先发送OPTIONS请求，以检查服务器是否允许实际请求跨域访问资源。
这是浏览器的一种安全措施，确保服务器知道请求的方法、来源和头部是安全的。

预检请求（Preflight Request）：在实际的跨域请求之前，浏览器会首先发送一个 OPTIONS 请求，以检测服务器是否支持真实的跨域请求。
这个 OPTIONS 请求中会携带以下请求头信息：
Access-Control-Request-Headers：告知服务器实际请求可能携带的自定义请求头字段。
Access-Control-Request-Method：告知服务器实际请求所使用的 HTTP 方法。

服务端响应：
服务端需要设置响应头，以允许跨域请求。以下是一些关键的响应头字段
Access-Control-Allow-Methods： 返回服务端允许的请求方法，包括 GET、HEAD、PUT、PATCH、POST、DELETE 等。
Access-Control-Allow-Credentials：允许跨域携带 cookie（如果跨域请求需要携带 cookie，这个字段必须设置为 true）。
Access-Control-Allow-Origin： 允许跨域请求的域名，可以在服务端配置信任的域名白名单。
Access-Control-Allow-Headers: 允许跨域携带自定义请求头。

参考：https://www.cnblogs.com/magicg/p/13670213.html

########################################################################################

在配置 aws cloudfront 时要注意两种 “缓存键和源请求” 的区别！！！

这两个标头，需要被 CloudFront 正确的转发至 S3，才能使有 OPTIONS 的跨域成功被满足。然而恰巧两种「缓存键和源请求」对于处理这个标头的方式不同：

1. 使用 Cache policy and origin request policy (recommended)，缓存策略是 CachingOptimized、源请求策略 无。
这样的配置会让 CloudFront 过滤掉以上两个 Access-Control-* 标头。
参考基准：当使用 Cache policy and origin request policy，需参考文档 [1] 的表格，确认您需要转发的标头是否在表格中、且是否默认会被转发。
然而 Access-Control-* 属于表格中第一列「其他定义的标头」，行为会是：被过滤。

解决方式：使用「源请求策略」功能，选择「CORS-S3Origin」，配置完成后刷新缓存（失效）。

2. 使用 Legacy cache settings，也就是「旧缓存设置」，旧缓存设置的行为，如同表格 [1] 第一列「其他定义的标头」提到的，「旧缓存设置 会使 CloudFront 将标头转发到源」，因此您使用旧缓存设置的时候，不用额外多做配置就可以将 Access-Control-* 转发到源，使 OPTIONS 成功。

因此建议您当使用 Cache policy and origin request policy 时需要额外注意标头是否被转发，并使用「源请求策略」来放行特定标头，以 CORS 跨域来说选择「CORS-S3Origin」并清理下缓存即可让 OPTIONS 成功。
或者是直接使用「旧缓存设置」也可以达成您的需求。

文档1：https://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#request-custom-headers-behavior