等保2.0二级Linux（安全通信网络）

网络架构 a应划分不同的网络区域，并按照方便管理和控制的原则为各网络区域分配地址； 查看系统设计方案，确定是否根据各部门的工作职能、重要性和所涉及信息的重要程度等因素划分了不同网段（VLAN或安全域）。 b应避免将重要网络区域部署在边界处，重要网络区域与其他网络区域之间应采取可靠的技术隔离手段。 检查网络拓扑图是否真是网络运行环境一致。

iOS 永久签名，详细使用指南，永不过期，完全免费，必看

TrollStore 永久签名工具，无需帐户，无需登录，无需证书，无需越狱，IPA 安装后永不过期，完全免费，使用简单方便。 TrollStore 本期内容，详细给大家介绍 TrollStore 相关内容。 TrollStore 如何安装，如何使用，使用技巧，一些常见问题和解决方法，一些注意事项等等。 本期目录： 一，关于原理。 二，关于 TrollStore。 三，TrollStore 目前的支持情况。 四，TrollStore 安装的主要步骤。 五，首先，安装安装器 TrollStore Helper。 六，然后，使用 TrollStore Helper 安装 TrollStore。 七，TrollStore 详细使用方法。 八，TrollStore 使用技巧。 九，TrollStore 常见问题和解决办法。 十，TrollStore 如何更新。 十一，TrollStore 如何降级。 十二，TrollStore 各版本更新包。 十三，TrollStore 的一些注意事项。 十四，介绍一下几个不同的图标。 十五，写在最后。 十六，本期资源获取。 本期适用平台 • iOS 关于原理 绕过签名漏洞 2022年7月2日， ZhouweiZhang 公开了利用漏洞绕过签名的方法，并且分享了详细的打包方法。 通过绕过签名的方法，安装应用后，可以永不过期。 绕过签名使用的漏洞是：CVE-2022-26766，CVE-2022-26763。这是由 Linus Henze 递交的漏洞， 这些漏洞，仅仅存在于 iOS […]

微信小程序被指违法违规收集个人信息

即点即用、少占内存的小程序真的安全吗？拒绝授权定位小程序却能获取位置坐标。明明拒绝了小程序获取自己的位置信息，后台还是能精准定位，今年6月有媒体实测发现↓ 如果关闭平台定位，小程序也无法定位；但一旦开启平台定位，无论用户是否授权，有些小程序就能够直接精准定位。 23%到76%的平台提供了隐私政策，其中只有不到四成的小程序提供了独立的隐私政策。例如某共享单车小程序在首次打开时，会申请获取个人的姓名、手机号、身份证号等个人信息，但小程序运营者本身并未提供任何隐私政策，或对收集上述信息的场景、用途及目的进行说明。 95%的样本小程序向用户模糊政策隐私，很容易导致用户忽略隐私政策，无法准确了解与个人主体权益相关的重要信息。 健身类、购物类、防疫类小程序存在收集与当时场景无关的个人信息的行为。 约有25%的样本小程序明文传输了个人信息。如共享单车、快递外卖类小程序会明文传输用户的精准地理位置信息；医疗健康类小程序会明文传输用户的健康档案信息，其中不乏用户的姓名、出生年月日以及药物过敏等相应的个人敏感信息。 目前各大小程序平台均为用户提供了关闭权限的功能，但94%的样本未向用户告知上述功能开放的途径，这可能会导致用户在使用完小程序后，仍将一部分权限持续开放给小程序使用。 在未向用户申请权限的情况下，某些小程序默认获取并使用了其关联小程序的用户信息，而用户无法关闭个人信息的授权功能。 建议将小程序这一新兴业态纳入个人信息保护管理范畴，参照 APP安全治理模式，针对小程序特点，研究制定个人信息安全保护规范，明确小程序与小程序平台之间的主体责任划分等，鼓励小程序运营者和平台运营者强化用户个人信息安全保护。

Docker运行报runc did not terminate successfully: exit status 127: unknown

问题现象： 执行docker-compose up -d 报错误： ERROR: for gitlab Cannot start service gitlab: failed to create shim task: OCI runtime create failed: unable to retrieve OCI runtime error (open /run/containerd/io.containerd.runtime.v2.task/moby/ea2ca9eebb54f609c8dd0083c802bd9d75f1755bfe6c72a38cf4a6a83df2bd11/log.json: no such file or directory): runc did not terminate successfully: exit status 127: unknown 解决办法： 有一句runc did not terminate successfully 执行runc命令 错误： runc: symbol lookup error: […]

使用官方脚本一键安装docker|安装docker-compose

安装docker 2023-03-07更新 不知道从什么时候开始官方脚本已经默认也安装了 docker compose,不需要后面的手动安装了 注意是 docker compose 而不是 docker-compose. 执行命令时候也没有这个杠 可在此命令后附带–mirror参数设置镜像源，以提高国内服务器下载docker的速度 若登录linux的用户不是root，则需要docker的用户加入 docker 用户组。 参考以下命令。 重新登录ssh终端，可执行以下命令测试是否正确安装docker docker run hello-world 正确安装的输出信息如下： 安装docker-compose 执行以下命令 注释： 记得授予权限 chmod +x ./docker-compose 移动到正确路径 mv ./docker-compose /usr/local/bin/docker-compose 执行 查看输出版本

等保2.0二级Linux（安全计算环境）

一、身份鉴别 a) 应对登录的用户进行身份标识和鉴别，身份标识具有唯一性， 身份鉴别信息具有复杂度要求并定期更换； 1)应核查用户在登录时是否采用了身份鉴别措施； 2)应核查用户列表确认用户身份标识是否具有唯一性； cat /etc/passwd，//查看命令结果，第三字段不存在相同数字、用户名不存在相同名 *第一个段用户名；第二个段密码标志；第三个字段用户ID（0代表超级用户）；第四个字段用户组ID；第五个字段用户字段说明；第六个字段用户根目录；第七个字段用户的命令解释器 *Linux用户分为三种：超级用户（root，UID=0）、普通用户（UID 500-60000)、伪用户（UID 1-499） 3）应核查用户配置信息或测试验证是否不存在空口令用户； /*以：为分隔，检查第二个字段是否为空，然后输出第二个字段为空的行*/ cat /etc/shadow | awk -F: ‘($2 == “” ) { print $1}’ cat /etc/shadow ①用户名②加密的密码：*代表帐号被锁定；!!表示这个密码已经过期。$1$ 表明是用MD5加密的；$2$ 是用Blowfish加密的；$5$ 是用 SHA-256加密的；$6$开头表明用SHA-512加密的；③上次更改密码的日期：表示的是从某个时刻起，到用户最后一次修改口令时的天数，时间起点对不同的系统可能不一样（参考1970年1月1日）。 时间计算命令：date -u -d “1970-01-01 UTC $((第三字段数据*86400 )) seconds”④最短密码期限（按天计算，0 = 无最短期限）, 两次修改口令之间所需的最小天数。⑤最长密码期限（按天计算）, 口令保持有效的最大天数⑥密码警告期限（按天计算，0 = 未指定警告）⑦密码非活动期限（按天计算），表示的是用户没有登录活动但账号仍能保持有效的最大天数⑧账号到期时间: 相应账号的生存期。期满后，该账号就不再是一个合法的账号，也就不能再用来登录了 ⑨ 预留字段 4）应核查用户鉴别信息是否具有复杂度要求； cat/etc/login.defs查看命令结果是否有设置密码长度，天数  // 查看命令结果是否有设置密码长度，复杂度。 PASS_MIN_DAYS（密码有效期的最小天数，默认值0） […]

DDOS攻击应急处理（1）

序言 DDOS大家都不陌生了，不管是在正常行业，还是灰色行业，各公司都在明争暗斗，此类攻击一直没停过，涉及到的勒索事件也很多。 遇到DDoS？ 当遇到DDOS攻击时，先不要慌，喝杯82年的雪碧冷静一下，沉着查看预警系统和各信息（你慌也没用，越慌幕后攻击者越开心） 状况？ 网站无法访问 初步处理？ 查看内存情况，查看是否有内存溢出： total=used+free，对于这几项，“shared / buffers / cached”是包含在used里面的。 查看cpu使用情况： 查看nginx使用情况： 强制关闭nginx： 这时候查看云平台，各项指标逐步恢复正常 再次启动nginx： 启动成功之后： 各项指标又开始飙升！ 马上看看nginx日志： 通过日志，可以看到会有大量异常访问记录 可以看到有几个地址被大量get请求，发现请求的地址是个图片链接，因为网站没设防盗链，从而被攻击。 来，我们去配置一下nginx： 找到了以下代码: 增加防盗链： 意思就是非指定网站对图片的访问，统一返回403 此时去看一下访问日志： 这时候非正常访问的都返回403了，应急处理工作告一段落。 微信公众号抽风 微信有个坑爹的问题，如果从微信端进入网站，日志里的UA就没有带域名，referer也是空的，这么说来，还得找其他方式解决这个问题。 找到另一个拦截点 还是分析nginx日志，看到攻击源浏览器内核都是Dalvik/2.1.0(谷歌的Android虚拟机) 或者 WeChat/6.7.2.34，那我是不是可以通过过滤这两种内核来达到拦截攻击的作用？ 把访问的内核过滤出来： 修改nginx配置，拦截特定浏览器内核访问： 保存配置后重启nginx，再次观察服务器指标，一段时间后依旧正常。 总结 通过把此次攻击转危为安，又加深了自己对网络安全的理解，要做的工作一定要提早做好，比如云平台设置下告警提醒，nginx或者tomcat的相关安全设置，IP白名单、缓存、并发量、IP连接数，每个企业环境不同，对应的设置数值也不能完全一样，但思路是通用的。