V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
Peanut666
V2EX  ›  问与答

请问如何写 iptables 规则来过滤运营商 HTTP 劫持?

  •  2
     
  •   Peanut666 · 2016-08-08 16:39:00 +08:00 · 6062 次点击
    这是一个创建于 3034 天前的主题,其中的信息可能已经有所发展或是发生改变。
    坐标四川移动光纤, DNS 已经全局走 SS 过滤了移动运营商的 53 端口的 DNS 劫持。因为经常用国内网站,所以全局 SS 不现实。
    目前存在的问题是京东、华为商城等网站有运营商 HTTP 劫持到返利链接,多次投诉工信部都没有效果,因此想求助大家写个 iptables 规则来过滤 HTTP 劫持,我放在 Openwrt 路由器上。

    已经用 wireshark 抓取了两次劫持的过程,
    京东劫持 https://www.cloudshark.org/captures/46d552c3e33b
    华为商城 https://www.cloudshark.org/captures/aca094df243a

    麻烦大家帮忙分析一下伪造的劫持包特征,帮我写个 iptables 规则,感谢大家!

    对了,感谢 @KCheshireCat 的思路,可惜我不会写 iptables 规则,就放在这里一下:
    [其实可以用 Wireshark 来观察 tcp 连接被劫持的情况
    像移动的劫持都是抢答带 ACK , FIN , PSH 标志的 http 302 封包,把你的页面或者 JS 脚本劫持走。
    而正常的 http 302 应答包通常并不会同时标记这 3 个标志位。
    可以朝这个方向考虑,写成 iptables 规则就是
    iptables -A FORWARD -p tcp -m tcp --sport 80 -m u32 --u32 "0>>22&60@10&25=25&&0>>22&60@9>>2&60@0=0x48545450&&0>>22&60@9>>2&60@8=0x20333032" -j DROP
    虽然可能会有误杀,但是劫持是再也没看到过]
    我试过这个规则,针对四川移动的劫持无效。

    看了这篇文章,也是关于流量劫持的
    https://security.tencent.com/index.php/blog/msg/81
    我也想试试攻击源定位,但是不会用XCAP构造被侦听的数据包(也就是直接发出访问京东首页的HTTP请求TCP包,不需要三次握手)多次发送,如果有朋友懂的话,麻烦指导我一下,感谢!
    23 条回复    2016-09-02 01:05:30 +08:00
    kttde
        1
    kttde  
       2016-08-08 16:44:19 +08:00   ❤️ 1
    可以从 ttl 值这方面入手
    Peanut666
        2
    Peanut666  
    OP
       2016-08-08 16:46:45 +08:00
    @kttde 是的,我分析了下,伪造的包 TTL 不确定是 64 还是 51
    kttde
        3
    kttde  
       2016-08-08 17:07:57 +08:00   ❤️ 1
    jd 解析的 IP 地址是 117.131.205.1,那么这个 ip 发给你的第 1 个包的 ttl 值就是真的,Wireshark 序号 5,7,10,11,13 中,5 是最先发的 ttl 值是 51,10 和 11 的 ttl 值都是 74,13 序号往后走的 ttl 值都是 51,那么序号 10 和 11 就是假包,屏蔽 117.131.205.1 发过来的数据包 ttl 值是 74 的就可以了
    gamexg
        4
    gamexg  
       2016-08-08 17:24:39 +08:00   ❤️ 1
    Peanut666
        5
    Peanut666  
    OP
       2016-08-08 17:27:05 +08:00
    @kttde 谢谢分析,我看了下华为的劫持包是 ttl 值 73 ,再请教一下,按 ttl 来的屏蔽规则如何写呢?
    Peanut666
        6
    Peanut666  
    OP
       2016-08-08 17:30:31 +08:00
    @gamexg 谢谢,我看了下,不知道怎么用起来,囧
    KCheshireCat
        7
    KCheshireCat  
       2016-08-08 21:09:36 +08:00   ❤️ 2
    这个劫持设备发了两个包,两个例子抢答包 ttl 分别是 73,74

    一个是 ACK 标志位的并没有携带数据的纯确认包,作用是确认收到了客户端 GET 请求

    然后还有一个就是抢答包了,他的标记位是 PSH,ACK.这个包其实已经包含了前面那个包的功能

    这个包没有标记 FIN,而 PSH 在 TCP 里常用,不能成为明显的特征

    看 IP 头和 TCP 头也没有什么畸形构造,TTL 是个特征但不安定,应该放在最后考虑

    这里其实可以思考 IP 头,TCP 头容易成为特征是因为有规范,定长

    而劫持设备发送的劫持包通常是预先设置好模板然后填入不同变量,所以可以看作是定长的头部



    红框内就是预计可以匹配的部分,让我选的话我会考虑匹配 Set-Cookie: apxlp=1;

    然后我们看看抢答的正文



    绿色的是设置初始变量,

    红色是修改原有 cookie 的到期时间为 1970 年 1 月 1 日零点+1s,而 UNIX 认为 1970 年 1 月 1 日 0 点是时间纪元,并越过了 apxlp=1 这条没有处理

    蓝色就是执行跳转的部分了使用 meta 节点做立即跳转,然后对 apple 设备做了特殊对待

    使用 Set-Cookie: apxlp=1;作为关键词匹配



    匹配成功

    对应的 iptables 规则

    iptables -A FORWARD -p tcp -m tcp --sport 80 -m u32 --u32 "130=0x5365742d&&134=0x436f6f6b&&138=0x69653a20&&142=0x6170786c&&146=0x703d313b" -j DROP

    最后是关于 TTL 的

    目前现代系统常见的初始 TTL 值一般是 64,128,256 这 3 种

    观察握手时 TTL 可以发现两方到达 TTL 都小于 64,推测初始 TTL 为 64

    而劫持包的 TTL 为 73 左右,初始 TTL 不可能是 64

    那么要用 TTL 作为特征过滤可以参考这样

    iptables -A FORWARD -s 117.78.34.197 -p tcp -m tcp --sport 80 -m ttl --ttl-gt 70 -m ttl --ttl-lt 80 -j DROP
    iptables -A FORWARD -s 117.131.205.1 -p tcp -m tcp --sport 80 -m ttl --ttl-gt 70 -m ttl --ttl-lt 80 -j DROP

    然而如果服务器使用了 CDN 那么 IP 很可能会变动,但不限制来源 IP,很可能会误伤

    以上规则均未做验证,不保证有效
    bdbai
        8
    bdbai  
       2016-08-08 21:38:09 +08:00 via Android
    为什么不直接投诉运营商呢。变着法子治标不治本啊。
    mdzz
        9
    mdzz  
       2016-08-08 21:44:26 +08:00
    向广告商投诉试试
    Peanut666
        10
    Peanut666  
    OP
       2016-08-08 22:37:48 +08:00 via Android
    @bdbai 看开头,我写了,多次投诉工信部都没有效果。。。
    Peanut666
        11
    Peanut666  
    OP
       2016-08-08 22:38:37 +08:00 via Android
    @KCheshireCat 感谢分析,我回头试试!!
    Peanut666
        12
    Peanut666  
    OP
       2016-08-08 22:39:30 +08:00 via Android
    @mdzz 我给广告商 linktech 发邮件投诉了,居然不理我 T_T
    bdbai
        13
    bdbai  
       2016-08-08 23:17:38 +08:00 via Android
    @Peanut666 投诉工信部之前你也应该先投诉运营商的。
    Peanut666
        14
    Peanut666  
    OP
       2016-08-08 23:44:45 +08:00 via Android
    @bdbai 运营商是投诉了滴,但是他们说不知道怎么回事儿→_→装疯卖傻,没办法。
    bdbai
        15
    bdbai  
       2016-08-09 00:09:55 +08:00 via Android
    @Peanut666 沟通技巧问题😂我开始也这样,直接让他们找领导就解决了。
    falcon05
        16
    falcon05  
       2016-08-09 06:40:49 +08:00 via iPhone
    我也是被联通劫持了, http 请求会在 body 结尾加段广告 js, 还好特征比较简单,用 iptables 配合 privoxy 过滤掉了
    songw123
        17
    songw123  
       2016-08-09 09:39:42 +08:00
    我在广东电信网内,也遇到京东之类被劫持到领克特或者亿起发的情况,测试了非常多的办法,最后选择了直接 DNS 切到阿里公共 DNS , 223.5.5.5 ,只有他们家的公共 DNS 没有被污染,其他家的都被污染,不清楚你那边情况如何,供参考
    Peanut666
        18
    Peanut666  
    OP
       2016-08-09 12:56:04 +08:00
    @songw123 我试过各种 DNS 了,但这种不是 DNS 劫持哟,比 DNS 劫持还难搞的 HTTP 劫持。
    kttde
        19
    kttde  
       2016-08-09 21:43:27 +08:00   ❤️ 1
    ttl 过滤
    然而如果服务器使用了 CDN 那么 IP 很可能会变动,但不限制来源 IP,很可能会误伤

    这一点比较好解决,直接指定 hosts 域名 ip ,电商网站最多 20 到 30 个,一般只劫持首页
    Peanut666
        20
    Peanut666  
    OP
       2016-08-10 00:00:39 +08:00
    @kttde 好的,谢谢
    CloudnuY
        21
    CloudnuY  
       2016-08-31 17:12:26 +08:00
    @KCheshireCat 多谢,学习了,之前用 wireshark 拦截到抢答包,和请求包的 ID 是一样样的,真实的数据包会被丢弃。 TTL 测的多次多日都是 146 ,用 scapy 从 ttl=1 往上游发包不管是多少都没有链路劫持服务器的响应,劫持的广告服务器 IP 变动极大,各种云服务器都有。

    这种情况可否直不限制 IP 直接 drop 掉所有 ttl=146 的包呢?
    KCheshireCat
        22
    KCheshireCat  
       2016-08-31 22:18:22 +08:00
    @CloudnuY

    就 146 来说真的没有其他特征了可以这么尝试,因为常见的 TTL 初始值比 146 大的也就 256 了,

    而通常不会有这么多跳路由来把 256 减到 146.

    并且 256 也是 64,128,256 这 3 者里面比较不常见的.
    CloudnuY
        23
    CloudnuY  
       2016-09-02 01:05:30 +08:00
    @KCheshireCat 多谢回复!这几天我试一下直接 drop 这个看看效果
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1754 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 16:39 · PVG 00:39 · LAX 08:39 · JFK 11:39
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.