在 RouterOS 中配置 MSS Clamping 解决部分网站图片无法加载的问题

发表评论
  • 协议: IPv4 & IPv6

现象

  • 手机访问阿里系应用有问题，如支付宝、淘宝、盒马，加载很久，也可能很久也加载不出来
  • 开代理科学上网后正常，但按理说大多请求应该还是走的 Direct 规则
  • 怀疑是 IPv6 的问题，于是起了 SmartDNS 的 force-AAAA-SOA yes，BAN 掉了所有的 v6 解析后，有所改善！

PMTU黑洞

换成自己用 RouterOS 拨号之后，经常发现有的图片加载不出来，是因为在RouterOS中没有正确配置MTU及MSS，导致部分包被丢弃，也就是传说中的 PMTU 黑洞。

最常见的就是微信公众号图片、淘宝预览图、B站预览图始终加载不出来。

所谓 MTU，指的是一条链路上可以通过的三层数据包的最大尺寸（包含 IP 包头）。以太网默认的 MTU 是 1500 字节。但是从我的设备到目标服务器之间的路径上可能存在 MTU 小于 1500 的链路，那么这条路径上最小的 MTU，就是整条链路的 Path MTU（PMTU）。

路由器在转发包的时候，如果包的大小超过了 MTU，那么这个包会被分片（fragmentation）。而终端设备在发包时，也可以设置 DF 标志位（Don’t Fragment）来告诉路由器不要对这个包分片，此时如果这个包大小超过了 MTU，那么路由器就会丢掉这个包，并回复一条 ICMP Fragmentation Needed 消息。发送者收到这个消息后，下次就会发送小一点的包。这个过程叫做 PMTU 发现（PMTU Discovery）。

但是互联网中有大量的设备因为各种原因，会配置为不回应 ICMP Fragmentation Needed 消息，这使得大小超过 MTU 的包会被无声地丢掉，直到 TCP 协议发现超时丢包并进行重传。这种情况就是 PMTU黑洞。

此外，IPv6 包不支持分片，换句话说就是所有 IPv6 数据包全都带有 DF 标记。中间的路由器在遇到尺寸大于 MTU 的包的时候，应该回应 ICMPv6 Packet Too Big 消息，而同样的，由于各种原因，某些中间设备可能会直接丢掉这个包而不返回这条消息，直到 TCP 协议发现超时而进行重传。

为什么用光猫或者硬路由拨号就没有这个问题

多数家用路由器默认开启了一个叫 MSS Clamping 的功能。这是针对 PMTU 黑洞的一个 workaround，简单来说就是在 TCP 握手时，服务器会通过一个字段告知客户端它愿意接收的 TCP 包的最大尺寸，这样客户端就可以限制自己发送的包的大小，保证不会超出服务端要求的尺寸。

解决

配置routeros防火墙的mangle表

/ip/firewall/mangle
add action=change-mss chain=forward comment="IPv4 MSS clamp to PMTU" \
    new-mss=clamp-to-pmtu out-interface="<你的PPPoE出口>" passthrough=yes \
    protocol=tcp tcp-flags=syn

/ipv6/firewall/mangle
add action=change-mss chain=forward comment="IPv6 MSS clamp to PMTU" \
    new-mss=clamp-to-pmtu out-interface="<你的PPPoE出口>" passthrough=yes \
    protocol=tcp tcp-flags=syn

参考

Redis安全基线汇总

发表评论

检查项

禁止使用root用户启动 | 访问控制
禁止监听在公网 | 访问控制
打开保护模式 | 访问控制
限制redis 配置文件访问权限 | 文件权限
修改默认6379端口 | 服务配置
禁用或者重命名危险命令 | 入侵防范
开启redis密码认证,并设置高复杂度密码 | 身份鉴别
版本存在安全漏洞 | 入侵防范
Redis未授权访问 | 身份鉴别

继续阅读 →

wazuh采集sysmon日志

发表评论

agent.conf

在服务器agent.conf文件中添加以下内容

<agent_config>
  <localfile>
    <location>Microsoft-Windows-Sysmon/Operational</location>
    <log_format>eventchannel</log_format>
  </localfile>
</agent_config>

docker安装的wazuh，agent配置文件在 `wazuh.manager` 容器中。

ossec.conf

将logall_json修改为yes，如下：

<logall_json>yes</logall_json>

docker安装的wazuh，agent配置文件在 `wazuh.manager` 容器中。

修改上述两项后重启wazuh-manager服务

filebeat.yml

修改filebeat配置文件，修改内容如下：

...
filebeat.modules:
 - module: wazuh
  alerts:
   enabled: true
  archives:
   enabled: true
...

重启filebeat

service filebeat restart

测试filebeat输出

filebeat test output

添加Index Patterns

在WUI中，Management -> Stack Management -> Index Patterns

添加wazuh-archives-*的Patterns

添加完后，可以在Discover中看到客户端的sysmon日志。

添加IP黑名单

开始接收sysmon日志后，日志存储量会无限增大，需要对发送过来的源地址进行限制。

如果使用docker安装，需要在docker-compose.yml中，添加privileged，不添加的话无法在容器中启动iptables，如下：

services:
  wazuh.manager:
    image: wazuh/wazuh-manager:4.8.0
    hostname: wazuh.manager
    restart: always
    privileged: true       #添加
    ports:
      - "1514:1514"
      - "1515:1515"
      - "514:514/udp"
      - "55000:55000"

构建好docker容器后，在`wazuh.manager`容器中安装iptables，并添加目的端口为1514的黑名单即可，如下：

# apt update
# apt install iptables
# iptables -I INPUT -s x.x.x.x -p tcp --dport 1514 -j DROP
# iptables-save

 

 

 

nmap探测存活主机

发表评论

nmap是所有安全爱好者应该熟练掌握的扫描工具，本篇介绍其在扫描大网络空间时的用法。

为什么要扫描大网络空间呢？ 有这样的情形：

  1. 内网渗透   攻击者单点突破，进入内网后，需进一步扩大成果，可以先扫描整个私有网络空间，发现哪些主机是有利用价值的，例如10.1.1.1/8, 172.16.1.1/12, 192.168.1.1/16
  2. 全网扫描

扫描一个巨大的网络空间，我们最关心的是效率问题，即时间成本。 在足够迅速的前提下，宁可牺牲掉一些准确性。

扫描的基本思路是高并发地ping：

nmap -v -sn -PE -n --min-hostgroup 1024 --min-parallelism 1024 -oX nmap_output.xml www.lijiejie.com/16

继续阅读 →

谷歌商店下载APK

发表评论
网站 直连 说明
https://android-apk.app/ 否 可搜索，可下载历史版本
https://apkpure.com/cn/ 否 可搜索，可下载历史版本
https://apkcombo.com/apk-downloader/ 否 可搜索，可下载历史版本
https://androidappsapk.co/ 否 可搜索，可下载历史版本
https://apk.support/apk-downloader 否 需要自己输入应用地址，解析的是Google下载地址
https://apps.evozi.com/apk-downloader/ 否 需要自己输入应用地址
https://apkhome.net/ 是 可搜索，但版本不一，有的APK文件十分可疑
https://www.apkmirror.com/ 否 可搜索，可下载历史版本
https://androidapksfree.com 否 可搜索，可下载历史版本
https://www.apkhere.com/ 否 不是很全，有很多破解的APP
https://www.apk4fun.com/ 否
https://www.aptoide.com/ 否
https://www.apkmonk.com/ 否
https://cn.uptodown.com/android 否
https://www.9apps.com/ 否
https://download.cnet.com/android/ 否
https://apkmos.com/ 是 不全

继续阅读 →

hash批量查询VirusTotal

发表评论

virustotal-search.py  用于批量搜索VirusTotal的hash值

virustotal-submit.py  用于向VirusTotal提交文件

官方博客（virustotal-search v0.1.4） 基于python2

官方博客（virustotal-search v0.1.5） 基于python2

GitHub版本（virustotal-search v0.1.6） 基于python3

如何使用：

获取VirusTotal API KEY（免费API每分钟允许4次请求，每天允许500次查询，每月15.50 K次查询）

VirusTotal API KEY 获取地址

获取后，修改脚本中的VIRUSTOTAL_API2_KEY变量，或在运行脚本时，使用 -k 选项指定API KEY

VIRUSTOTAL_API2_KEY = 'xxxx0d4d0784d2b457f40a6xxxx3b678064c1edxxxxxfed17f2e57948afxxxxx'

在sha256.txt中包存需要查询的hash值后执行

python virustotal-search.py sha256.txt -o out.csv

执行后，在当前目录会生成out.csv文件，csv文件默认以;作为分隔符。指定分隔符使用 -s 选项

 

MikroTik PCC多线叠加+ospf+ovpn

发表评论

RouterOS V6.47.7

ROS可以进行的负载均衡配置及特点如下：

ECMP(Equal-Cost Multi-path):
ECMP是通过在route列表添加多网关的静态路由，然后由路由协议建立劢态的多线路由。这种负载均衡有个缺点，缺点就是每十分钟内核会重新均衡线路，使一些连接会被指定到其他路线，出现频繁掉线的情况。
NTH:
NTH是采用第N次链接的负载均衡，它不仅可以实现基于IP的负载均衡，同时还能实现对端口负载均衡和对nat指定有序的访问。这样基本实现了不掉线的真正负载均衡。但是NTH存在着一个弊端，就是在某些对IP要求严格的网站会反复要求验证。比如，网银！这样我们需要通过策略将一些IP或者端口指定走固定的线路出去，从而避开网站繁琐的验证。
PCC（Per connection classified）：
PCC是通过判断源地址或者目的地址、源端口或者目的端口对数据迚行分类来实现负载均衡，对每个连接迚行分类大多保持了连续性，这样大大弥补了NTH的不足。

继续阅读 →

iproute2在openwrt中实现策略路由

发表评论

安装ip-full

opkg install ip-full

新增路由表

id:252（1-252可用），name:wifi2zt

id:251,name:ovpn2ta

id:250,name:bg

echo "252 wifi2zt" >> /etc/iproute2/rt_tables
echo "251 ovpn2ta" >> /etc/iproute2/rt_tables
echo "250 bg" >> /etc/iproute2/rt_tables

为新建的路由表指定路由

ip route add 0.0.0.0/0 via 10.49.160.1 table wifi2zt
ip route add 0.0.0.0/0 via 172.16.21.254 table ovpn2ta
ip route add 0.0.0.0/0 via 192.168.170.1 table bg

添加策略路由

ip rule add from 192.168.171.0/24 table wifi2zt #源IP为192.168.171.0/24，添加到wifi2zt表，使用网关：10.49.160.1
ip rule add from 192.168.170.0/24 table ovpn2ta #源IP为192.168.170.0/24，添加到ovpn2ta表，使用网关：172.16.21.254
ip rule add to 192.168.169.0/24 table bg #目的IP为192.168.169.0/24，添加到bg表，使用网关：192.168.170.1

查看路由表及清空路由表

root@LEDE:/etc/iproute2# ip route list table ovpn2ta   #查看ovpn2ta表
default via 172.16.21.254 dev tun0
root@LEDE:/etc/iproute2#


root@LEDE:/etc/iproute2# ip rule list  #查看策略
0: from all lookup local
32740: from all to 192.168.168.0/24 lookup ovpn2ta
32741: from all to 192.168.169.0/24 lookup ovpn2ta
32742: from all to 192.168.170.0/24 lookup bg
32763: from all lookup main
32764: from all lookup default
root@LEDE:/etc/iproute2#


root@LEDE:/etc/iproute2# ip route flush table bg  #清空路由表