连长 's Blog

安全、渗透、红蓝对抗。潜心研究、切勿浮躁。{写什么PHP/Python/Java? 转GO多好!}

红蓝对抗之组一个安全的网

渗透测试 0 评

@Author 众安天下-凤凰安全实验室-连长

@Email [email protected]

@Date 2020年05月05日

文章辣鸡,未经同意禁止转载谢谢

0x00 说明

你还在裸奔连接的c2或者cs服务器端吗?你还在毫无危机感认为别人根本日不穿你?你还在觉得防守队都是沙雕?别骂了~ 有句老话,叫做小心驶得万年车,毕竟现在很多大佬都在甲方养老,相反真正工作在一线(乙方)的人水平层次不齐,知不知道何时形成现在这种局面,我也很心痛,毕竟我也是这群菜鸡中的其中一位。

红蓝对抗其实是一个对抗的过程,防守方不仅仅是将的你ip封锁就完事了的,还想这怎么溯源你这黑阔。部署蜜罐、分析日志、反向渗透、快速响应、快速处理等等。其实就是想着找出你的行为来对应人,在当代环境下很多东西都是透明可查,难免年少轻狂的时候在网上留下一些敏感信息。

其实很多黑阔,在你渗透的时候或者你在准备信息收集的时候,目标都在偷偷的收集的一些有关于你的一些信息,方便怎么商量来日川像你这样的黑阔。有些防守方会偷偷的去放一些隐藏好的后门,比如xxvpn客户端,某某json接口等等,甚至还会收集的你mac地址等等电脑的基本的信息,在日志里面对应你这个黑阔。其实攻击方的所有相关人员都是攻击手,但却缺少 防守队员,简称(Security personnel) 像很多电影演的那样,每一个干大事的团队里都有一个身手比较的好的特种队员。负责保护团队的成员,又像辅助又像奶妈。。(扯远了。。)。该队的职责应该是保障攻击队的队员的网络通畅性和上网匿名性,以及电脑安全以及人身安全问题,人身安全问题可能听起来比较扯,有很多东西你用不到可能觉得无所谓,因为现在hw慢慢增加了线下的一些操作,人保安也不是吃屎的,虽然打架是违法的,但是咱也不能光该揍啊。所以我觉得跟应该注重攻击队的防守,而非攻击的攻击能力(虽然攻击是核心的,很矛盾....),毕竟自己被日穿可不是什么好事,毕竟你在攻击的时候都忘记伪装你自己,一方面是正规授权养成的坏习惯,一方面可能也是因为懒。不仅连累自己还连累队友简称(猪队友),还可能泄露一些敏感信息,比如你的lozhao你的工具0day。

你在渗透目标的同时防守方可能也在渗透你,如果碰到比较强的防守方,可能你连还手的机会都木有,瞬间被日穿。 我的思路就是将防守方的思路搬到我攻击方来使用,达到攻守兼备的效果。本期讲的就是组网,毕竟红蓝不是一个人的游戏,讲的是团队配合的结果,不能因为一个人犯错导致整个团队翻车。下几期可能会写,组一个蜜罐网,假诱饵恶心防守方,假0day的shellcode方式。来搞一些自作聪明的防守小哥哥。还有可能会说说怎么识别蜜罐,和浏览器一些电脑基本信息的。如果你觉得此篇文章对你很有帮助也可赞赏,不是强制的,不喜欢也能发表自己的看法,毕竟我觉得我写的很辣鸡。

0x01 思路以及工具介绍

网上有很多v皮恩的方案,很多,但都是要经过服务端的v皮恩,而且服务端被日川了所有的客户端都受影响。比较蛋疼。

介绍一下 一个新的工具 nebula
Nebula是slack开源的一款p2p网络工具,可以用以建立跨越NAT、彼此互联的Overlay Network。

这个工具虽然刚刚开源,但它已经被运用在slack内部的网络中有两年时间了,同时,其使用的Noise协议为流量加密提供了良好的支持。该工具使用MIT协议授权,并使用Go语言编写。

为了满足内部加密、分区隔离以及其他操作的需求, Slack 开发了可扩展的覆盖网络(Overlay Network)工具 Nebula. 覆盖网络是一种创建在互联网之上的网络, 覆盖网络中的节点, 可通过虚拟或是逻辑相连接。Nebula 让 Slack 能够无缝地连接位在世界各地的计算机, 目前支持在 Linux, OSX 和 Windows,甚至 Slack 也正在开发 iOS 版本。

那怎么证明他是p2p的网呢?

我建立了个小型的星云网络并且搞了四个节点进行了测试:在谷歌云托管的灯塔(lighthouse)节点 和在公司的办公网的三个节点。我们的两个成员节点(nat0和nat1)在办公室的主LAN上,第三个成员节点doublenat在单独的子网中,连接在节点nat0后面。
无需太多测试即可确认是p2p的网。在从nat1到doublenat的iperf3网络速度测试中,有674Mbps的吞吐量,这清楚地说明数据包没有通过灯塔发送 ,该灯塔位于香港的谷歌数据中心。

对比传统的有什么优点?

  • 对比传统式V皮恩,速度上有一定的提升,至少大家都是直连的状态。
  • 对比传统式V皮恩,访问子网的任意一台机器时都会穿越服务器端。而Nebula就不需要长时间穿越。
  • 对比传统式V皮恩,安全方面得到很好的提升,采用最新的加密方式加密。要破解基本上不可能,所以说点和点之间的通信,在没有key的情况下,被劫持解密的几率很小。
  • 对比传统式V皮恩,传统式你是直连到服务端然后经服务器在到目标的客户端,这样费时费力。而且你发起的ip连接都是有日志,Nebula可以定义多个灯塔,可能服务端连接的是一个ip,但渗透时用的ip又是另外一个ip,这样就撇清了你和主节点的关系。相当于中转下。
  • 对比传统式V皮恩,部署超简单,几乎比wg部署还方便,只需要配置好配置文件和证书上传运行即可。
  • Nebula 自带有很好的控制系统,后面我会将到。
  • 配置简单对“服务器”性能要求不高管理简便

对比传统的有什么缺点?

  • 网络性能上会受影响,因为采用最新型加密方式Noise,性能可能远远不如wg,但是做红蓝,第一考虑的就是安全。为了安全牺牲一点性能也无伤大雅。
  • 目前没有比较完善的移动端。这是是比较蛋疼的。
  • windows需要安装openvpn的驱动。这是比较蛋疼的。而且需要网络管理才能跑,就冲这点,你就放弃吧这套东西部署在渗透目标的上面吧。
  • 没有完善的配置文档,新手配置起来费劲,因为这东西出现的时间较短,可能还存在一些安全问题和功能上的bug。
  • Nebula需要提前写明节点的对应关系,这条后期会给解决方案。

0x02开始搭建

Nebula网络非常简单,只有两种节点类型:

  • 标准的「用户节点」,可以在「灯塔节点」的引导下与其他节点通过P2P相连。
  • 「灯塔节点」是必须具备公网IP地址和开放端口的服务器,负责协调客户端之间的发现和通讯。

至于搭建的服务器可以使用支持BTC够买的主机商,毕竟钱是可以溯源的,前期搭建可以用跳板机进行连接。

一、创建CA证书

证书的创建需要几个字段:

  • -groups: 该CA证书签发的子证书可以使用哪些组,这些组可以方便地配置防火墙策略。
  • -ips:该CA证书适用的IP地址段。
  • -name:该CA的名称。

下面二种方案二选一,看你自己了。

生成普通的证书
生成主证书 CA, 后面所有节点证书都是这个主证书签名的

# 生成一个机构名为 nebula test 的主证书
# 当前目录下会产生两个文件 ca.crt 主密钥的证书, ca.key 主密钥的私钥

./nebula-cert ca -name "red team test"

签署 lighthouse 节点证书

# 生成一个名为 lighthouse1, ip 为 10.10.88.1/24 节点
# 产生两个文件 lighthouse1.crt lighthouse1 的证书, lighthouse1.key 私钥

# 只要修改参数 name, ip 就可以生成 lighthouse2 证书了 

./nebula-cert sign -name "lighthouse1" -ip "10.10.88.1/24"
./nebula-cert sign -name "lighthouse2" -ip "10.10.88.2/24"

生成特殊的证书
Nebula通过将ip地址和路由等信息嵌入到证书文件,可以实现只需要证书和一个固定的配置文件即可加入网络。CA证书的创建可直接使用nebula-cert创建:

nebula-cert ca -groups admin,users,server,router,ix,uestc,client -ips 172.20.158.128/26,172.20.168.128/25 -name "NIACNET Networking CA"

执行该步骤后,会在目录下生成ca.crt(证书)和ca.key(密钥)。

二、创建用户证书

如果没有指定参数,nebula-cert将默认使用本目录的ca.crt/ca.key。

有以下几个参数:

  • -group:该证书所属的设备流量将被归为哪些组。
  • -ip:IP地址将被嵌入在证书中,这增加了网络的稳定性,除非配置错误,否则不太可能出现IP地址冲突的状况,同时也能够在不同的用户端使用相同的配置模板,同时也便于大规模部署。
  • -name:名称是可以随便取的,但我依然按照域名来写。
  • (可选)-subnets:该节点可以通过本参数被指定为Nebula网络的出口,与其他网络互联。在这里,为了与DN42互联,我指定了172.20.0.0/14。

以下是某个「灯塔节点」的配置。可以有多个灯塔一次类推

./nebula-cert sign -name "team1" -ip "10.10.88.50/24" -groups "user,server"
./nebula-cert sign -name "team2" -ip "10.10.88.51/24" -groups "user,server"
./nebula-cert sign -name "team3" -ip "10.10.88.52/24" -groups "user,server"

它也会在目录下生成一个与-name相匹配的.crt和.key文件。
-w555

三、配置文件详解

配置文件也有参照的类型,https://github.com/slackhq/nebula/blob/master/examples/config.yml
对应写。

1、PKI

指定CA和用户证书。

pki:
   ca: /etc/nebula/ca.crt
   cert: /etc/nebula/charles-laptop.nia.crt
   key: /etc/nebula/charles-laptop.nia.key

2、静态主机映射

一开始Nebula并不知道该如何寻找主机,这里可以进行映射关系的建立。这时候需要将设定好的「灯塔节点」主机对应的Nebula地址和公网地址/端口填进来,以便于首次连接并寻找新的节点。

static_host_map:
   "172.20.168.129": ["xxx.xxx.xxx.xxx:4242"]

3、灯塔

如果需要将某个节点指定为「灯塔节点」,将am_lighthouse改为true即可。

同时,它也内建了一个DNS服务,可以方便快速地查找主机。但由于NIACNET将与DN42互联,有时候需要添加一些额外的记录,在此场景下关闭内置的DNS。

hosts是需要被指定为「灯塔节点」的Nebula地址,如果本身就是「灯塔节点」,则此处留空。

lighthouse:
   am_lighthouse: false
   #serve_dns: false
   #dns:
     #host: 0.0.0.0
     #port: 53
   interval: 60
   hosts:
     - "172.20.168.129"

4、端口

侦听的端口和地址,通常侦听0.0.0.0及使用4242端口。你可以可以修改端口,比如443,1721

listen:
   host: 0.0.0.0
   port: 4242

5、打洞

如果设备位于NAT及防火墙后,则需要打洞,打开punchy将定期发送报文,有助于维持隧道的稳定建立。

punchy_back则是反向打洞,使用此功能后,另一方在收到建立连接的请求后,将会再反向发送一次请求。这有利于在打洞困难的完全锥形NAT下进行隧道的建立。

punchy: true
punch_back: true

6、加密

其实在完全用于国内节点的网络中,高强度的加密意义不大,这里使用了默认的chachapoly加密。

cipher: chachapoly

7、本地网段

定义本地网段的好处在于能够快速地找到用以建立连接的最快的路径,这适用于设备处于同一个局域网内。

local_range: "10.0.0.0/8"

8、隧道

隧道可以选择tap和tun两种,这里我选择了tun,同时将drop_local_broadcast和drop_multicast关闭,以便于接收到广播和多播。

由于不同节点的网络环境各不相同,MTU将使用较为保守的1300,而Nebula也同时提供了对不同路由的MTU选项。

unsafe_routes是非常重要的功能,它提供了网络对外的出口路由,通过via指定一个证书内包含subnets字段的节点,Nebula在启动时便会自动地配置好相应的路由表,这里我选择某一个节点,将其接入到DN42网络。

tun:
   dev: nia0
   drop_local_broadcast: false
   drop_multicast: false
   tx_queue: 500
   mtu: 1300
   routes:
     #- mtu: 8800
     #  route: 10.0.0.0/16
   unsafe_routes:
      - route: 172.20.0.0/14
        via: 172.20.168.131
        mtu: 1300

9、防火墙与安全组

防火墙的默认设置看起来并不需要太大的更改:

firewall:
   conntrack:
     tcp_timeout: 120h
     udp_timeout: 3m
     default_timeout: 10m
     max_connections: 100000

而对于出站流量,通常是全部允许的。

outbound:
     - port: any
       proto: any
       host: any

而对于入站流量,icmp是建议被打开的(方便进行ping等操作),而groups参数可以填入仅希望证书中带有哪些组的客户端能够访问。此外也可以指定CA、IP或者名称。

  inbound:
    - port: any
      proto: icmp
      host: any

    - port: 443
      proto: tcp
      groups:
        - users

10、除此之外…

Nebula还具有这些功能:

与prometheus、graphite等工具配合记录网络信息。
内置的ssh服务端,用以查看网络状态和维护节点配置。

11、systemd服务

在Arch系发行版下,我创建一个Nebula的systemd服务,它被放置在/etc/systemd/system/nebula.service,相应的配置文件则在/etc/nebula/config.yml。

[Unit]
Description=Nebula Network
Wants=basic.target
After=basic.target network.target

[Service]
SyslogIdentifier=nebula
StandardOutput=syslog
StandardError=syslog
ExecReload=/bin/kill -HUP $MAINPID
ExecStart=/usr/bin/nebula -config /etc/nebula/config.yml
Restart=always

[Install]
WantedBy=multi-user.target

12、路由

理论上讲Nebua网络不存在多跳的路由,但是在某些状况下(完全锥形NAT和垃圾运营商),必须有中转节点来进行转发。

欲达到这样的目的,需要在每个节点上单独配置自己的unsafe_routes,然后在中转节点开启转发功能并配置路由。

13、优化

Nebula使用的UDP协议有时候会被运营商QoS所限制甚至掐断,为了应对这一问题,可以考虑使用udp2raw来对udp包进行伪造。

如果你的vps主机对udp包qos比较严重我建议加上 udp2raw来把udp流量伪装成tcp绕过限制。

自此,NIACNET国内网络的基本框架便已搭建好了,只需要再增加DNS、CA服务器等即可成为一个基本能用的内部局域网络。

0x03 搭建之路

-w738
谷歌云上开三台机器分别是
-w685

一、lighthouse和node端生成

wget https://github.com/slackhq/nebula/releases/download/v1.2.0/nebula-linux-amd64.tar.gz 
tar -zxvf nebula-linux-amd64.tar.gz 

./nebula-cert sign -name "lighthouse1" -ip "10.10.88.1/24"
./nebula-cert sign -name "lighthouse2" -ip "10.10.88.2/24"

./nebula-cert sign -name "team1" -ip "10.10.88.50/24" -groups "user,server"
./nebula-cert sign -name "team2" -ip "10.10.88.51/24" -groups "user,server"
./nebula-cert sign -name "team3" -ip "10.10.88.52/24" -groups "user,server"

-w623

其中的ca.key 很重要需要妥善保管,否则全部翻车。
将lighthouse的各个配置文件考到个节点机器然后

对应:lighthouse1.cat、lighthouse1.key > lighthouse1
对应:lighthouse2.cat、lighthouse2.key > lighthouse2
参照下面的配置文件进行更改

1、lighthouse 配置文件

# pki 修改证书文件位置
pki:
  ca: ${nebula_home}/ca.crt
  # 对应节点修改即可
  cert: ${nebula_home}/lighthouse1.crt
  key: ${nebula_home}/lighthouse1.key

static_host_map:
  "10.10.88.1": ["lighthouse1.example.com:4242"]
  "10.10.88.2": ["lighthouse2.example.com:4242"]

lighthouse:
  # lighthouse 节点为 true
  am_lighthouse: true
  #serve_dns: false
  interval: 60
  # hosts is a list of lighthouse hosts this node should report to and query from
  # IMPORTANT: THIS SHOULD BE EMPTY ON LIGHTHOUSE NODES

# lighthouse 节点不要配置该项
#  hosts:
#    - "192.168.100.1"

listen:
  host: 0.0.0.0
  port: 4242
  #batch: 64
  #read_buffer: 10485760
  #write_buffer: 10485760

# 开启强力打洞
punchy: true
punch_back: true

# Nebula security group configuration
firewall:
  conntrack:
    tcp_timeout: 120h
    udp_timeout: 3m
    default_timeout: 10m
    max_connections: 100000

  outbound:
    # Allow all outbound traffic from this node
    - port: any
      proto: any
      host: any

  inbound:
    # Allow icmp between any nebula hosts
    - port: any
      proto: icmp
      host: any

    # 节点间允许所有通讯
    - port: any
      proto: any
      cidr: "10.10.88.1/24"

把配置文件拷贝到到每个lighthouse执行。

./nebula -config config.yml

-w1271
得到 没报错证明lighthouse 运行正常。

2、node节点端

所有 攻击端和服务端其实也可以分组,隔离谁只能访问谁。出于某种原因我就不演示了。

2.1、攻击端 Linux

假设 team1 是攻击队某台cs服务器。
下载主程序,吧第一次生成的证书和key拷贝进去
-w665
然后编辑配置文件

配置文件

# pki 修改成对应证书即可
pki:
  ca: /root/ca.crt
  # 对应节点修改即可
  cert: /root/team1.crt
  key: /root/team1.key

  #黑名单是一份我们将拒绝与之交谈的证书指纹列表 
  #blacklist:
  #  - c99d4e650533b92061b09918e838a5a0a6aaee21eed1d12fd937682865936c72

# 告诉 nebula 有公网 ip 的对应关系, 特别是 lighthouse 节点公网 ip, 
# 普通节点有公网 ip 也可以配置, 就免去 nat 打洞查找了
static_host_map:
  "10.10.88.2": ["lighthouse2.example.com:4242"]
  


lighthouse:
  # 普通节点为 false
  am_lighthouse: false
  #serve_dns: false
  interval: 60
  # hosts is a list of lighthouse hosts this node should report to and query from
  # IMPORTANT: THIS SHOULD BE EMPTY ON LIGHTHOUSE NODES

# 普通节点要配置该项, 列出知道的 lighthouse 节点
  hosts:
    - "10.10.88.2"

listen:
  host: 0.0.0.0
  port: 4242
  #batch: 64
  #read_buffer: 10485760
  #write_buffer: 10485760

# 开启强力打洞
punchy: true
punch_back: true

# Nebula security group configuration
firewall:
  conntrack:
    tcp_timeout: 120h
    udp_timeout: 3m
    default_timeout: 10m
    max_connections: 100000

  outbound:
    # Allow all outbound traffic from this node
    - port: any
      proto: any
      host: any

  inbound:
    # Allow icmp between any nebula hosts
    - port: any
      proto: icmp
      host: any

    # 节点间允许所有通讯
    - port: any
      proto: any
      cidr: "10.10.88.1/24"

`
./nebula -config config.yml
ping 10.10.88.1
ping 10.10.88.2
`

注意这里的 static_host_map 和攻击队的用并不同。 这里有个坑,
就是在不同的static_host_map情况下必须ping 下所有的 static_host_map 服务器,否则无法建立nat。

2.2、攻击端 MAC

假设 team3 是攻击队人员,使用的电脑为mac电脑。
-w586
运行前需要管理员运行该客户端,并且允许允许否则跑不起来。

配置文件

# pki 修改成对应证书即可
pki:
  ca: /nebula-test/ca.crt
  # 对应节点修改即可
  cert: /nebula-test/team3.crt
  key: /nebula-test/team3.key

  #黑名单是一份我们将拒绝与之交谈的证书指纹列表 
  #blacklist:
  #  - c99d4e650533b92061b09918e838a5a0a6aaee21eed1d12fd937682865936c72

# 告诉 nebula 有公网 ip 的对应关系, 特别是 lighthouse 节点公网 ip, 
# 普通节点有公网 ip 也可以配置, 就免去 nat 打洞查找了
static_host_map:
  "10.10.88.1": ["lighthouse1.example.com:4242"]
  
lighthouse:
  # 普通节点为 false
  am_lighthouse: false
  #serve_dns: false
  interval: 60
  # hosts is a list of lighthouse hosts this node should report to and query from
  # IMPORTANT: THIS SHOULD BE EMPTY ON LIGHTHOUSE NODES

# 普通节点要配置该项, 列出知道的 lighthouse 节点
  hosts:
    - "10.10.88.1"

listen:
  host: 0.0.0.0
  port: 4242
  #batch: 64
  #read_buffer: 10485760
  #write_buffer: 10485760

# 开启强力打洞
punchy: true
punch_back: true


# Nebula security group configuration
firewall:
  conntrack:
    tcp_timeout: 120h
    udp_timeout: 3m
    default_timeout: 10m
    max_connections: 100000

  outbound:
    # Allow all outbound traffic from this node
    - port: any
      proto: any
      host: any

  inbound:
    # Allow icmp between any nebula hosts
    - port: any
      proto: icmp
      host: any

    # 节点间允许所有通讯
    - port: any
      proto: any
      cidr: "10.10.88.1/24"
2.3、攻击端 windows

下载releases win的版本.
配置如上,拷贝配置文件,我就不一一演示了 时间问题。
安装TAP驱动 openvpn驱动地址

已经有装过 openvpn 的可能会碰到多个 vpn 占用一个 tap 的问题
https://michlstechblog.info/blog/openvpn-connect-to-multiple-vpns-on-windows/这篇文章解决问题。

0x04、结尾

既然你能看到这里证明你对自身的安全有高度的重视,我也是随便写写,文中可能会有错别字,或者措辞不清的地方,还请各位大佬,大牛,黑客、白帽子、大哥,大姐指出来,小弟虚心受教,圈子浮躁,轻喷。
首先是利益无关,只是自己突然想到,然后近期又在研究,然后看了一下iplc,所以就想用自己的服务器折腾玩玩,纯粹玩玩而已的啊,建议大家不要轻易尝试,毕竟在中间建立隧道的过程中,虽然有这个加密,但端口暴露和流量模型是铁定能被监控到的。如果用在非法上面翻车是迟早的事。请自重。。。。
以下都是不正经言论和不正经测试,找点事情玩玩而已。
如果不想使用此方案也可以参照我的另一篇文章
黑阔的自建中转轻松玩落地隐藏行踪+出国留学
-w877
可以看到 我ping 其中一个节点,还有丢包的现象
-w453
因为他们是直连的 p2p网络,快不快或者丢不丢包处决于你本地的访问目标快不快。

linux 端位于日本的cs 服务器。和mac端 位于北京某个地方的攻击队菜鸡。
互相通讯 完全是直连没有问题。
-w659

-w437
p2p直连没毛病, 这比你去直连 cs机器要好吧啊。而且是用其他ip发起的。要溯源还是有点难度的。就算目标节点被渗透暴露的也只是当前节点服务器,而非暴露的所有灯塔服务器。这也有点跳板的意思。

好今天就说到这,下集就是讲怎么样来,真正的利用起来这个一整套的东西。

0x05、参考

0x7f.cc

arstechnica.com

runtime.pw

https://github.com/slackhq/nebula

lianzhang.org

发表评论
撰写评论