给大家的福利
零基础入门
对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。
同时每个成长路线对应的板块都有配套的视频提供：
因篇幅有限，仅展示部分资料
需要体系化学习资料的朋友，可以加我V获取：vip204888 （备注网络安全）
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
| — | — |
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | $ lscgroup | tee cgroup.a $ diff cgroup.b cgroup.a 4a5 > net_cls,net_prio:/xyxy 12a14 > pids:/user.slice/user-0.slice/session-c9.scope/xyxy 121a124 > cpuset:/xyxy 129a133 > blkio:/user.slice/user-0.slice/session-c9.scope/xyxy 242a247 > cpu,cpuacct:/user.slice/user-0.slice/session-c9.scope/xyxy 352a358 > freezer:/xyxy 360a367 > devices:/user.slice/user-0.slice/session-c9.scope/xyxy 470a478 > hugetlb:/xyxy 478a487 > memory:/user.slice/user-0.slice/session-c9.scope/xyxy 588a598 > perf_event:/xyxy |
可以看到容器创建之后系统上多了一些 cgroup，并且它们的 parent 目录是我们的 sh 所在的 cgroup.
cgroup 可以控制进程所能使用的内存，cpu 等资源。
在容器的 cgroup 中也可以加入更多的进程。
首先使用 runc 查看一下进程的 pid：
| 1 2 3 | $ runc ps xyxy UID PID PPID C STIME TTY TIME CMD root 713 703 0 15:40 ? 00:00:00 sh |
然后查看这个 cgroup 下面有哪些进程：
| 1 2 | $ cat /sys/fs/cgroup/memory/user.slice/user-0.slice/session-c9.scope/xyxy/tasks 713 |
发现只有这一个。
下面通过容器的 exec 命令加入一个新的进程到这个 cgroup 中：
| 1 | $ runc exec xyxy /bin/top -b |
然后再次查看是否有新的 cgroup 生成：
| 1 2 | $ lscgroup |
输出为空，说明没有新的 cgroup 生成。
然后通过查看原来的 cgroup，可以确认新的进程 top 被加入到了原来的 cgroup 中。
| 1 2 3 | $ cat /sys/fs/cgroup/memory/user.slice/user-0.slice/session-c9.scope/xyxy/tasks 713 5126 |
总结：当一个新的 container 创建的时候，容器会为每种资源创建一个 cgroup 来限制容器可以使用的资源。
| 1 2 3 4 5 6 7 8 9 | $ ls /sys/fs/[[cgroup]]/*/user.slice/user-0.slice/session-c9.scope/xyxy/tasks /sys/fs/[[cgroup]]/blkio/user.slice/user-0.slice/session-c9.scope/xyxy/tasks /sys/fs/[[cgroup]]/cpu,cpuacct/user.slice/user-0.slice/session-c9.scope/xyxy/tasks /sys/fs/[[cgroup]]/cpu/user.slice/user-0.slice/session-c9.scope/xyxy/tasks /sys/fs/[[cgroup]]/cpuacct/user.slice/user-0.slice/session-c9.scope/xyxy/tasks /sys/fs/[[cgroup]]/devices/user.slice/user-0.slice/session-c9.scope/xyxy/tasks /sys/fs/[[cgroup]]/memory/user.slice/user-0.slice/session-c9.scope/xyxy/tasks /sys/fs/[[cgroup]]/pids/user.slice/user-0.slice/session-c9.scope/xyxy/tasks /sys/fs/[[cgroup]]/systemd/user.slice/user-0.slice/session-c9.scope/xyxy/tasks |
那么如何通过 cgroup 来对资源限制呢？
默认情况下的容器是不限制资源的，比如说内存，默认情况下是 9223372036854771712：
| 1 2 | $ cat /sys/fs/cgroup/memory/user.slice/user-0.slice/session-c9.scope/xyxy/memory.limit_in_bytes 9223372036854771712 |
要限制一个容器使用的内存大小，只需要将限制写入到这个文件里面去就可以了：
| 1 | $ echo 100000000 > /sys/fs/cgroup/memory/user.slice/user-0.slice/session-c9.scope/xyxy/memory.limit_in_bytes |
内存是一个非弹性的资源，不像是 CPU 和 IO，如果资源压力很大，程序不会直接退出，可能会运行慢一些，然后再资源缓解的时候恢复。对于内存来说，如果程序无法申请出来需要的内存的话，就会直接退出（或者 pause，取决于 memory.oom_control 的设置）。
上面这种修改 cgroup 限制的方法，其实就是 runc 在做的事情。但是使用 runc 我们不应该直接去改 cgroup，而是应该修改 config.json ，然后 runc 帮我们去配置 cgroup。
修改方法是在 linux.resources 下面添加：
| 1 2 3 4 | “memory”: { “limit”: 100000000, “reservation”: 200000 } |
然后 runc 启动之后可以查看 cgroup 限制。
我们可以验证 runc 的资源限制是通过 cgroup 来实现的，通过修改内存限制到一个很小的值（比如10000）让容器无法启动而报错：
| 1 2 | $ runc run xyxy container_linux.go:475: starting container process caused “process_linux.go:434: container init caused “process_linux.go:400: setting [[cgroup]] config for procHooks process caused \“failed to write 1000000 to memory.limit_in_bytes: write /sys/fs/[[cgroup]]/memory/user.slice/user-0.slice/session-c9.scope/xyxy/memory.limit_in_bytes: device or resource busy\””” |
从错误日志可以看到，cgroup 的限制文件无法写入。可以确认底层就是 cgroup.
4. Linux Capabilities
Capabilities 也是 Linux 提供的功能，可以在用户有 root 权限的同时，限制 root 使用某些权限。
先准备好一个容器，带有 Libcap，这里我们还是直接使用 docker 安装好然后导出。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | root@vagrant:/home/vagrant# docker run -it alpine sh -c ‘apk add -U libcap; capsh --print’; Unable to find image ‘alpine:latest’ locally latest: Pulling from library/alpine ca3cd42a7c95: Pull complete Digest: sha256:ec14c7992a97fc11425907e908340c6c3d6ff602f5f13d899e6b7027c9b4133a Status: Downloaded newer image for alpine:latest fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/main/x86_64/APKINDEX.tar.gz fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/community/x86_64/APKINDEX.tar.gz (1/1) Installing libcap (2.46-r0) Executing busybox-1.32.1-r5.trigger OK: 6 MiB in 15 packages Current: cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=eip Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap Ambient set = Current IAB: 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 Securebits: 00/0x0/1’b0 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),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video) Guessed mode: UNCERTAIN (0) |
然后将这个 docker 容器导出到 runc 的 rootfs:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | root@vagrant:/home/vagrant# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES root@vagrant:/home/vagrant# docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 5aad51652320 alpine “sh -c 'apk add -U l…” About a minute ago Exited (0) About a minute ago angry_lamarr 9b463bcb9712 busybox “sh” 20 hours ago Created lucid_yonath 7eced2fbadb0 hello-world “/hello” 20 hours ago Exited (0) 20 hours ago friendly_cori root@vagrant:/home/vagrant# docker export 5aad51652320 |
最后生成一个 spec：
| 1 2 3 4 5 6 | root@vagrant:/home/vagrant# mkdir test_cap root@vagrant:/home/vagrant# mv rootfs/ test_cap/ root@vagrant:/home/vagrant# cd test_cap/ root@vagrant:/home/vagrant/test_cap# runc spec root@vagrant:/home/vagrant/test_cap# ls config.json rootfs |
然后进入到容器里面验证，会发现在容器里面无法修改 hostname，即使已经是 root 了也不行：
| 1 2 3 4 5 | root@vagrant:/home/vagrant/test_cap# runc run mycap / # id uid=0(root) gid=0(root) / # hostname xintao.local hostname: sethostname: Operation not permitted |
这是因为，修改 hostname 需要 CAP_SYS_ADMIN 权限，即使是 root 也需要。
我们可以将 CAP_SYS_ADMIN 加入到 init 进程的 capabilities 的 bounding permitted effective list 中。
修改 capabilities 为以下内容：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 | “capabilities”: { “bounding”: [ “CAP_AUDIT_WRITE”, “CAP_KILL”, “CAP_SYS_ADMIN”, “CAP_NET_BIND_SERVICE” ], “effective”: [ “CAP_AUDIT_WRITE”, “CAP_SYS_ADMIN”, “CAP_KILL”, “CAP_NET_BIND_SERVICE” ], “inheritable”: [ “CAP_AUDIT_WRITE”, “CAP_KILL”, “CAP_NET_BIND_SERVICE” ], “permitted”: [ “CAP_AUDIT_WRITE”, “CAP_SYS_ADMIN”, “CAP_KILL”, “CAP_NET_BIND_SERVICE” ], “ambient”: [ “CAP_AUDIT_WRITE”, “CAP_KILL”, “CAP_NET_BIND_SERVICE” ] }, |
然后重新开启一个容器进去测试，发现就可以修改 hostname 了。
| 1 2 3 4 | root@vagrant:/home/vagrant/test_cap# runc exec -t mycap sh / # hostname xintao.local / # hostname xintao.local |
查看 Capability
要使用 pscap ，首先要安装 libcap-ng-utils，然后可以查看刚刚打开的那两个容器的 capabilities:
| 1 2 3 | root@vagrant:/home/vagrant# pscap |
可以看到一个有 sys_admin ，一个没有。
除了修改 config.json 来添加 capabilities，也可以在 exec 的时候直接通过命令行参数 --cap 来要求 additional caps.
| 1 | # runc exec --cap CAP_SYS_ADMIN xyxyx /bin/hostname cool |
在容器中，可以通过 capsh 命令查看 capability:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | / # capsh --print Current: cap_kill,cap_net_bind_service,cap_audit_write=eip cap_sys_admin+ep Bounding set =cap_kill,cap_net_bind_service,cap_sys_admin,cap_audit_write Ambient set =cap_kill,cap_net_bind_service,cap_audit_write Current IAB: !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_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 Securebits: 00/0x0/1’b0 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= Guessed mode: UNCERTAIN (0) |
可看到 Current 和 Bounding 里面有 cap_sys_admin。+ep 的意思是它们也在 effective 和 permitted 中。
5. 文件系统的隔离
在容器中只能看到容器里面的文件，而不能看到 host 上面的文件（不map的情况下），做到了隔离。
Linux 使用 tree 的形式组织文件系统，最底层叫做 rootfs, 一般由发行版提供，mount 到 / 。然后其他的文件系统 mount 到 / 下面。比如，可以将一个外部的 USB 设备 mount 到 /data 下面。
mount(2)是用来 mount 文件的系统的 syscall。当系统启动的时候，init 进程就会做一些初始化的 mount。
所有的进程都有自己的 mount table，但是大多数情况下都指向了同一个地方，init process 的 mount table。
但是其实可以从 parent 进程继承过来之后，再做一些改变。这样只会影响到它自己。这就是 mount namespace。如果 mount namespace 下面有任何进程修改了 mount table，其他的进程也会受到影响。所以当你在shell mount 一个 usb 设备的时候，GUI 的 file explorer 也会看到这个设备。
Mount Namespace
一般来说应用在启动的时候不会修改 mount namespace. 比如现在在我的虚拟机中，就有以下的 mount namespace:
| 1 2 3 4 5 6 7 | root@vagrant:/home/vagrant# cinf |
现在启动一个 container，可以看到有了新的 mount namespace：
| 1 2 3 4 5 6 7 8 | root@vagrant:/home/vagrant# cinf |
| 1 2 3 4 5 6 7 8 9 10 11 12 | root@vagrant:/home/vagrant# cinf -namespace 4026532185 PID PPID NAME CMD NTHREADS CGROUPS STATE 14013 14003 sh sh 1 12:blkio:/user.slice/yoyo S (sleeping) 11:pids:/user.slice/user-1000.slice/session-35.scope/yoyo 10:devices:/user.slice/yoyo 9:cpu,cpuacct:/user.slice/yoyo 8:memory:/user.slice/user-1000.slice/session-35.scope/yoyo 7:net_cls,net_prio:/yoyo 6:rdma:/ 5:cpuset:/yoyo 4:freezer:/yoyo 3:hugetlb:/yoyo 2:perf_event:/yoyo 1:name=systemd:/user.slice/user-1000.slice/session-35.scope/yoyo 0::/user.slice/user-1000.slice/session-35.scope |
在 host 进程上查看 mount info：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 | root@vagrant:/home/vagrant# cat /proc/14013/mounts |
可以看到这个进程的 / mount 到了 /dev/mapper/vagrant-root 上。
在 host 机器上，查看 mount，会发现这个设备同样 mount 在了 / 上。
| 1 2 | root@vagrant:/home/vagrant# mount |
所以这里就有了问题：为什么 container 的 rootfs 会和 host 的 rootfs 是一样的呢？这是否意味着 contianer 能读写 host 的文件了呢？contianer 的 rootfs 不应该是 runc 的 pwd 里面的 rootfs 吗？
我们可以看下 container 里面的 / 到底是什么。
在 container 里面查看 / 的 inode number:
| 1 2 | / # ls -di . 2883749 . |
然后看下 Host 上运行 runc 所在的 pwd 下面的 rootfs：
| 1 2 | root@vagrant:/home/vagrant/test_cap/rootfs# ls -id /home/vagrant/test_cap/rootfs 2883749 /home/vagrant/test_cap/rootfs |
可以看到，容器里面的 / 确实就是 host 上的 rootfs。
但是他们是怎么做到都 mount 到 /dev/mapper/vagrant-root 的呢？
这里的 “jail” 其实是 privot_root 提供的。它可以改变 process 的运行时的 rootfs. 相关代码可以查看这里。这个 idea 其实来自于 lxc。
chroot
要做到文件系统的隔离，其实并不一定需要创建一个新的 mount namespace 和 privot_root 来进行文件系统的隔离，可以直接使用 chroot(2) 来 jail 容器进程。chroot 并没有改变任何 mount table，它只是让进程的 / 看起来就是一个指定的目录。
关于 chroot 和 privot_root 的对比可以参考这里。
简单来说，privot_root 更加彻底和安全。
如果在 runc 使用 chroot，只需要将 {“type”:”mount”} 删掉即可。
也可以删掉这部分，这是为 privot_root 准备的。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | - “maskedPaths”: [ - “/proc/kcore”, - “/proc/latency_stats”, - “/proc/timer_list”, - “/proc/timer_stats”, - “/proc/sched_debug”, - “/sys/firmware”, - “/proc/scsi” - ], - “readonlyPaths”: [ - “/proc/asound”, - “/proc/bus”, - “/proc/fs”, - “/proc/irq”, - “/proc/sys”, - “/proc/sysrq-trigger” ] |
然后创建一个新的容器，发现依然不能读写 rootfs 之外的东西。
Bind Mount
Linux 支持 bind mount. 就是可以将一个文件目录同时 mount 到多个地方。这样，我们就可以实现在 host 和 container 之间共享文件了。
在 config.json 中作出以下修改：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | diff --git a/config.json b/config.json index 25a3154…13ae9bf 100644 — a/config.json +++ b/config.json @@ -129,6 +129,11 @@ “relatime”, “ro” ] + }, + { + “destination”: “/my_workspace”, + “type”: “bind”, + “source”: “worksapce_host”, + “options” : [“bind”] |
这样， host 上面的 /home/vagrant/test_cap/workspace_host 就会和容器中的 /my_workspace 同步了。可以在 host 上面执行：
| 1 | root@vagrant:/home/vagrant/test_cap# echo hello > workspace_host/world |
然后在 container 里面：
| 1 2 | # cat /myworkspace/world hello |
Bind 不仅可以用来 mount host 的目录，还可以用来 mount host 上面的 device file。比如可以将 host 的 UBS 设备 mount 到 container 中。
Docker Volume
Volume 是 docker 中的概念，OCI 中并没有定义。
本质上它仍然是一个 mount，可以理解为是 docker 帮你管理好这个 mount，你只要通过命令行告诉 docker 要 mount 的东西就好了。
6. User and root
User 和 permission 是 Linux 上面几乎最古老的权限系统了。工作原理简要如下：
- 系统有很多 users 和 groups
- 每个文件属于一个 owner 和一个 group
- 每一个进程属于一个 user 和多个 groups
- 结合以上三点，每一个文件都有一个 mode，标志了针对三种不同类型的进程的权限控制: owner, group 和 other.
注意 kernel 只关心 uid 和 guid，user name 和 group name 只是给用户看的。
执行容器内进程的 uid
config.json 文件中的 User 字段可以指定容器的进程以什么 uid 来运行，默认是 0，即 root。这个字段不是必须的，如果删去，依然是以 uid=0 运行。
| 1 2 | $ id uid=0(root) gid=0(root) |
在 host 上，uid 也是 0：
| 1 2 3 | $ runc ps xyxy UID PID PPID C STIME TTY TIME CMD root 15223 15212 0 07:55 pts/0 00:00:00 sh |
不推荐使用 root 来跑容器。但是好在默认我们的容器进程还受 capability 的限制。不像 host 的 root 一样有很多权限。
但是仍然推荐使用一个非 root 用户来运行容器的进程。通过修改 config.json 的 uid/guid 可以控制。
| 1 2 3 4 | “user”: { “uid”: 1000, “gid”: 1000 }, |
然后在容器中可以看到 uid 已经变成 1000 了。
| 1 2 | $ id uid=1000 gid=1000 |
在 host 上可以看到进程的 uid 已经不是 root 了：
| 1 2 3 | $ runc ps xyxy UID PID PPID C STIME TTY TIME CMD vagrant 15348 15336 0 11:12 pts/0 00:00:00 sh |
创建容器的时候默认不会创建 user namespace。
使用 User namespace 进行 UID/GID mapping
接下来我们创建一个单独的 user namespace.
在开始之前我们先看下 host 上现有的 user namespace:
| 1 2 | $ cinf |
然后通过修改 config.json 来启用 user namespace. 首先在 namespaces 下面添加 user 来启用，然后添加一个 uid/guid mapping：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | + }, + { + “type”: “user” + } + ], + “uidMappings”: [ + { + “containerID”: 0, + “hostID”: 1000, + “size”: 32000 + } + ], + “gidMappings”: [ + { + “containerID”: 0, + “hostID”: 1000, + “size”: 32000 } |
然后重新运行容器，再次查看 user namespace:
| 1 2 3 | $ cinf |
在容器里面，我们看到 uid=1000：
| 1 2 | $ id uid=1000 gid=1000 |
但是在 host 上，这个进程的 pid=2000：
| 1 2 3 | $ runc ps xyxy UID PID PPID C STIME TTY TIME CMD 2000 15438 15426 0 11:19 pts/0 00:00:00 sh |
这就是 uid/gid mapping 的作用，通过 /proc 文件也可以查看 mapping 的设置：
| 1 2 | $ cat /proc/15438/uid_map 0 1000 32000 |
通过设置容器内的进程的 uid，我们就可以控制他们对于文件的权限。比如如果文件的 owner 是 root，我们可以通过设置 uid 来让容器内的进程不可读这个文件。
一般不推荐使用 root 运行容器的进程，如果一定要用的话，使用 user namespace 将它隔离出去。
在同一个容器内运行多个进程的场景中，也可以通过 user namespace 来单独控制容器内的进程。
7. 网络
在网络方面，OCI Runtime Spec 只做了创建和假如 network namespace, 其他的工作需要通过 hooks 完成，需要用户在容器的运行时的不同的阶段来进行自定义。
使用默认的 config.json ，就只有一个 loop device ，没有 eth0 ，所以也就不能连接到容器外面的网络。但是我们可以通过 netns 作为 hook 来提供网络。
首先，在宿主机上，下载 netns 到 /usr/local/bin 中。因为 hooks 在 host 中执行，所以这些 Binary 要放在 host 中而不是容器中，容器的 rootfs 不需要任何东西。
| 1 2 3 4 5 6 7 8 9 10 11 12 | # Export the sha256sum for verification. $ export NETNS_SHA256=“8a3a48183ed5182a0619b18f05ef42ba5c4c3e3e499a2e2cb33787bd7fbdaa5c” # Download and check the sha256sum. $ curl -fSL “https://github.com/genuinetools/netns/releases/download/v0.5.3/netns-linux-amd64” -o “/usr/local/bin/netns” \ && echo “${NETNS_SHA256} /usr/local/bin/netns” |
使用 netns 设置 bridge network
在 config.json 中作出如下修改，除了 hooks，还需要 CAP_NET_RAW capability, 这样我们才可以在容器中使用 ping。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 | binchen@m:~/container/runc$ git diff diff --git a/config.json b/config.json index 25a3154…d1c0fb2 100644 — a/config.json +++ b/config.json @@ -18,12 +18,16 @@ “bounding”: [ “CAP_AUDIT_WRITE”, “CAP_KILL”, - “CAP_NET_BIND_SERVICE” + “CAP_NET_BIND_SERVICE”, + “CAP_NET_RAW” ], “effective”: [ “CAP_AUDIT_WRITE”, “CAP_KILL”, - “CAP_NET_BIND_SERVICE” + “CAP_NET_BIND_SERVICE”, + “CAP_NET_RAW” ], “inheritable”: [ “CAP_AUDIT_WRITE”, @@ -33,7 +37,9 @@ “permitted”: [ “CAP_AUDIT_WRITE”, “CAP_KILL”, - “CAP_NET_BIND_SERVICE” + “CAP_NET_BIND_SERVICE”, + “CAP_NET_RAW” ], “ambient”: [ “CAP_AUDIT_WRITE”, @@ -131,6 +137,16 @@ ] } ], + + “hooks”: + { + “prestart”: [ + { + “path”: “/usr/local/bin/netns” + } + ] + }, + “linux”: { “resources”: { “devices”: [ |
然后再启动一个新的容器。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | root@vagrant:/home/vagrant/test_cap# runc run xyxy / # ifconfig eth0 Link encap:Ethernet HWaddr EA:8B:9D:06:61:E5 inet addr:172.19.0.2 Bcast:172.19.255.255 Mask:255.255.0.0 inet6 addr: fe80::e88b:9dff:fe06:61e5/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:10 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:880 (880.0 B) TX bytes:570 (570.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) |
可以看到除了 loop 之外，有了一个 eth0 device.
也可以 ping 了：
| 1 2 3 4 | / # ping 216.58.199.68 PING 216.58.199.68 (216.58.199.68): 56 data bytes 64 bytes from 216.58.199.68: seq=0 ttl=55 time=18.382 ms 64 bytes from 216.58.199.68: seq=1 ttl=55 time=17.936 ms |
Bridge, Veth, Route and iptable/NAT
当一个 hook 创建的时候，container runtime 会将 container 的 state 传给 hook，包括 container的 pid, namespace 等。然后 hook（在这里就是 netns ）就会通过这个 pid 来找到 network namespace，然后 netns 会做以下几件事：
- 创建一个 linux bridge，默认的名字是
netns0，并且设置MASQUERADErule； - 创建一个 veth pair，一端连接
netns0，另一端连接 container network namespace, 名字在 container 里面是eth0; - 给 container 里面的
eth0分配一个 ip，然后设置 route table.
bridge and interfaces
netns0 创建的时候有两个 interfaces，名字是 netnsv0-$(containerPid)：（brctl 需要通过 apt install bridge-utils 安装）
| 1 2 3 4 | $ brctl show netns0 bridge name bridge id STP enabled interfaces netns0 8000.f2df1fb10980 no netnsv0-8179 netnsv0-10577 |
netnsv0-8179 是 veth pair 其中的一个，连接 bridge，另一个 endpoint 是 container 中的。
vthe pair
在 host 中，netnsv0-8179 的 index 是7：
| 1 2 3 | $ ethtool -S netnsv0-8179 NIC statistics: peer_ifindex: 7 |
然后在 container 中，etch0 的 index 也是7.
| 1 2 3 4 5 6 7 8 9 10 11 12 13 | / # ip a 1: lo: mtu 65536 qdisc noqueue qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 7: eth0@if8: mtu 1500 qdisc noqueue qlen 1000 link/ether 8e:f3:5c:d8:ca:2b brd ff:ff:ff:ff:ff:ff inet 172.19.0.2/16 brd 172.19.255.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::8cf3:5cff:fed8:ca2b/64 scope link valid_lft forever preferred_lft forever |
所以可以确认容器里面的 eth0 和 host 的 netnsv0-8179 是一对 pair。
同理可以确认 netnsv0-10577 是和 container 10577 中的 eth0 是一对 pair。
到这里我们知道容器是如何和 host 通过 veth pair 搭建 bridge 的。有了 network interfaces，还需要 route table 和 iptables.
Route Table
container 里面的 routing table 如下：
| 1 2 3 4 5 | / # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 172.19.0.1 0.0.0.0 UG 0 0 0 eth0 172.19.0.0 * 255.255.0.0 U 0 0 0 eth0 |
可以看到所有的流量都从 eth0 到 gateway, 即 bridge netns0：
| 1 2 | / # ip route get 216.58.199.68 from 172.19.0.2 216.58.199.68 from 172.19.0.2 via 172.19.0.1 dev eth0 |
在 host 上：
| 1 2 3 4 5 6 7 | $ route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192-168-1-1 0.0.0.0 UG 0 0 0 wlan0 172.19.0.0 * 255.255.0.0 U 0 0 0 netns0 192.168.1.0 * 255.255.255.0 U 9 0 0 wlan0 192.168.122.0 * 255.255.255.0 U 0 0 0 virbr0 |
以及：
| 1 2 3 | $ ip route get 216.58.199.68 from 172.19.0.1 216.58.199.68 from 172.19.0.1 via 192.168.1.1 dev wlan0 cache |
192.168.1.1 是 home route，一个真实的 bridge.
总结起来，ping 的时候，从 container 中，包会从 netns 的 virtual bridge netns ，发送到一个真正的 route gateway，然后到外网去。
iptable/nat
netns 做的另一个事情是设置 MASQUERADE，这样所有从 container 发出去的包（source是 172.19.0.0/16 ）都会被 NAT，这样外面只会看到这个包是从 host 来的，而不知道是否来自于一个 container，只能看到 host 的 IP。
| 1 2 3 4 | # sudo iptables -t nat --list Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all – 172.19.0.0/16 anywhere |
如何自学黑客&网络安全
黑客零基础入门学习路线&规划
初级黑客
1、网络安全理论知识（2天）
①了解行业相关背景，前景，确定发展方向。
②学习网络安全相关法律法规。
③网络安全运营的概念。
④等保简介、等保规定、流程和规范。（非常重要）
2、渗透测试基础（一周）
①渗透测试的流程、分类、标准
②信息收集技术：主动/被动信息搜集、Nmap工具、Google Hacking
③漏洞扫描、漏洞利用、原理，利用方法、工具（MSF）、绕过IDS和反病毒侦察
④主机攻防演练：MS17-010、MS08-067、MS10-046、MS12-20等
3、操作系统基础（一周）
①Windows系统常见功能和命令
②Kali Linux系统常见功能和命令
③操作系统安全（系统入侵排查/系统加固基础）
4、计算机网络基础（一周）
①计算机网络基础、协议和架构
②网络通信原理、OSI模型、数据转发流程
③常见协议解析（HTTP、TCP/IP、ARP等）
④网络攻击技术与网络安全防御技术
⑤Web漏洞原理与防御：主动/被动攻击、DDOS攻击、CVE漏洞复现
5、数据库基础操作（2天）
①数据库基础
②SQL语言基础
③数据库安全加固
6、Web渗透（1周）
①HTML、CSS和JavaScript简介
②OWASP Top10
③Web漏洞扫描工具
④Web渗透工具：Nmap、BurpSuite、SQLMap、其他（菜刀、漏扫等）
恭喜你，如果学到这里，你基本可以从事一份网络安全相关的工作，比如渗透测试、Web 渗透、安全服务、安全分析等岗位；如果等保模块学的好，还可以从事等保工程师。薪资区间6k-15k
到此为止，大概1个月的时间。你已经成为了一名“脚本小子”。那么你还想往下探索吗？
如果你想要入坑黑客&网络安全，笔者给大家准备了一份：282G全网最全的网络安全资料包评论区留言即可领取！
7、脚本编程（初级/中级/高级）
在网络安全领域。是否具备编程能力是“脚本小子”和真正黑客的本质区别。在实际的渗透测试过程中，面对复杂多变的网络环境，当常用工具不能满足实际需求的时候，往往需要对现有工具进行扩展，或者编写符合我们要求的工具、自动化脚本，这个时候就需要具备一定的编程能力。在分秒必争的CTF竞赛中，想要高效地使用自制的脚本工具来实现各种目的，更是需要拥有编程能力.
如果你零基础入门，笔者建议选择脚本语言Python/PHP/Go/Java中的一种，对常用库进行编程学习；搭建开发环境和选择IDE,PHP环境推荐Wamp和XAMPP， IDE强烈推荐Sublime；·Python编程学习，学习内容包含：语法、正则、文件、 网络、多线程等常用库，推荐《Python核心编程》，不要看完；·用Python编写漏洞的exp,然后写一个简单的网络爬虫；·PHP基本语法学习并书写一个简单的博客系统；熟悉MVC架构，并试着学习一个PHP框架或者Python框架 (可选)；·了解Bootstrap的布局或者CSS。
8、超级黑客
这部分内容对零基础的同学来说还比较遥远，就不展开细说了，附上学习路线。
网络安全工程师企业级学习路线
如图片过大被平台压缩导致看不清的话，评论区点赞和评论区留言获取吧。我都会回复的
视频配套资料&国内外网安书籍、文档&工具
需要体系化学习资料的朋友，可以加我V获取：vip204888 （备注网络安全）
当然除了有配套的视频，同时也为大家整理了各种文档和书籍资料&工具，并且已经帮大家分好类了。
一些笔者自己买的、其他平台白嫖不到的视频教程。
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
5204
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
