搞嵌入式 Linux 这么久我一直有个切身体会很多人把精力全放在驱动移植、内核编译、应用逻辑上安全这块基本属于能跑就行。但嵌入式设备恰恰是攻击者最喜欢的靶子——量大、分散、维护周期长、跑起来就没人管。我见过不止一台设备telnet 还开着root 密码是出厂默认防火墙规则全是 ACCEPT日志压根没开。被拉进僵尸网络、被当跳板、被拿去挖矿一点不冤。这篇内容我想把一套我实际在产线上落地过的嵌入式 Linux 系统级安全加固方案完整拆开讲一遍覆盖最小化裁剪、权限硬化、日志审计、轻量防火墙四个核心方向。文章最后还会把第 16 讲留下的思考题完整解析一遍。不管你是做网关、边缘计算盒子、工业控制器还是智能家居终端这套思路都适用。1. 嵌入式设备为什么成了安全短板威胁模型与加固主线在做任何安全操作之前先别急着敲命令。你得先想明白你的设备到底在防谁防什么想不清楚这一点后面做的所有加固都是在自我安慰。1.1 嵌入式系统面临的核心威胁与攻击路径嵌入式 Linux 设备面临的攻击路径我总结下来其实就四条。第一条是网络攻击。攻击者扫描开放端口利用默认口令、未修补的漏洞、不安全的服务比如旧的 telnet、弱 SSH 配置尝试进入系统。这条路径最通用成本最低很多僵尸网络的感染手段就是扫 23 端口、试 root/root、root/admin 这类弱口令。第二条是物理攻击。设备在用户手里用户拆开外壳接出串口通过 U-Boot 命令行修改启动参数或者直接把 flash 芯片读出来分析。别觉得拆壳是门槛对稍微有点动手能力的人来说这只是时间问题。第三条是供应链和部署攻击。镜像文件在生成、传输、烧录过程中被替换或篡改或者部署时运维人员把调试口开到了公网。这块更多是流程问题但单板层可以做校验和验签来兜底。第四条是应用漏洞利用。设备上跑的 Web 服务、云平台 SDK、协议解析组件比如 Modbus、MQTT、ONVIF 之类的库本身存在漏洞攻击者通过畸形报文或 payload 实现远程代码执行。这条路径在物联网设备上尤其常见。你要根据产品形态确定威胁模型。如果设备部署在可信内网网络攻击占比会低一些但也不能完全不设防——内网横向移动往往是攻击者最喜欢用的路径。如果设备是面向消费者、能直接被用户接触到的物理攻击就必须纳入设计考量。我见过不少团队做完网络加固就觉得万事大吉结果用户在串口上直接敲内核参数把 root shell 拿了出来前面的努力全部白费。1.2 加固体系的分层主线裁剪、硬化、审计、防火墙针对上面的威胁路径系统的加固工作可以收敛成四个层面的主线。我用一个表格把目标和手段先摆出来后面每一节再展开讲。层面对抗的威胁核心手段最小化裁剪攻击面过大、未知漏洞内核配置裁剪、rootfs 瘦身、服务收敛权限硬化提权、物理接触、未授权访问用户策略、文件权限、内核参数、只读挂载日志审计事后溯源缺失、异常无法发现syslog/auditd 配置、日志轮转与远程采集轻量防火墙网络攻击、异常访问nftables/iptables 默认拒绝、按白名单放行这四个维度不是我拍脑袋分的它们分别对应了攻击链上的四个环节减少入口、降低单点失陷后的影响、提升发现能力、增加横向移动成本。你单独做其中任何一项都有意义但要真正扛住实战攻击必须全部串起来。我见过有个产品只做了内核裁剪没做防火墙结果被扫到 8080 端口上的调试接口照样被打穿了。安全从来不是单点防御是纵深防御。2. 最小化裁剪把攻击面从源头压到最小最小化裁剪是我认为性价比最高的一步也是大多数嵌入式团队做得最糙的一步。很多人用的是 vendor 提供的默认 kernel defconfig一编出来啥都有各种不用的协议栈、文件系统、驱动模块全在里面。这不仅仅是体积和内存的问题更是攻击面的问题——每多一个编译进内核的子系统就多一份被漏洞覆盖的风险。2.1 内核配置裁剪按功能清单而非默认配置内核裁剪的第一步是先列功能清单再对着配置项逐个核对。别拿着默认配置删几个用不到的就结束正确做法是你得想清楚设备最终需要哪些功能然后把配置从这个清单反推出来。用一个实际例子说明我做一个工业数据采集网关CPU 是 i.MX6ULLCortex-A7 单核主要跑 Modbus TCP 采集、MQTT 上云、本地 Web 配置界面。内核配置裁剪时我遵循的原则是关闭不需要的协议栈IPv6 如果确实不用就关掉不过现在很多运营商网络和要求 IPv6,你要按需评估常用的比如CONFIG_IPV6测试环境用不到可以CONFIG_IPV6n。还有CONFIG_INET_DIAG这类诊断模块不是调试阶段就关了。关闭不需要的文件系统正常情况下嵌入式设备用squashfs、UBIFS、ext4就够了。vfat如果需要 U 盘升级就得保留不需要就关。CONFIG_FS_POSIX_ACL、CONFIG_FS_ENCRYPTION如果安全启动做了完整性校验加密这块单独考虑这些都按需。关闭不需要的驱动这是大头。一个默认 kernel 里驱动成百上千全编译出来既占空间又浪费时间。根据你的硬件原理图只开启外设对应驱动比如CONFIG_DRM没有显示输出就关、CONFIG_SOUND没音频就关、CONFIG_WIRELESS没 WiFi 就关。关闭调试接口CONFIG_DEBUG_FS、CONFIG_KPROBES、CONFIG_FTRACE、CONFIG_MAGIC_SYSRQ、CONFIG_DEVMEM、CONFIG_DEVKMEM这些都要评估。产品阶段 debugfs 我一般是关掉的CONFIG_STRICT_DEVMEM打开。CONFIG_KALLSYMS如果不需要内核符号给调试用也可以关掉这能让攻击者分析内核漏洞的难度大增。开启安全相关选项CONFIG_SECURITY、CONFIG_SECURITY_SELINUX或CONFIG_SECURITY_APPARMOR可以按需开启如果做完整性要求高的系统SELinux/AppArmor 是加分项但嵌入式下配置成本不低CONFIG_HARDENED_USERCOPY、CONFIG_SLAB_FREELIST_HARDENED、CONFIG_SLAB_FREELIST_RANDOM、CONFIG_RANDOMIZE_KSTACK_OFFSET这类内核自防护选项能开就开。裁剪后验证方式也很重要编译通过不等于能跑。我一般先做冒烟测试逐个测产品功能清单上的每一项再在目标板上跑一段压力测试。内核裁剪踩过最典型的坑是把某驱动编成模块而不是编进内核导致 rootfs 挂在很晚的阶段才加载模块起不来。所以如果这个功能是系统启动必须的比如网卡驱动、存储驱动必须y编进内核不能m。2.2 rootfs 瘦身BusyBox、库文件与符号裁剪rootfs 瘦身往往和内核裁剪同步进行。嵌入式领域用 BusyBox 是很主流的方案它把几十个常用命令行工具合并成了一个二进制大幅减少了体积和攻击面。但注意BusyBox 默认编译会带 applet很多你用不到的比如tftp、telnetd、httpd、ftpd一定要在配置里去禁用。默认开启意味着攻击者上传一个小文件就能跑起一个服务这是实实在在的风险。对于用户态动态库裁剪的核心是链接层面的优化。能用 musl 或 uClibc-ng 就别用 glibc前两者体积小得多攻击面也少一些。如果必须用 glibc记得 strip 掉符号表。用-ffunction-sections -fdata-sections -Wl,--gc-sections链接选项可以把用不到的 section 去掉实测体积能再小 10% 左右。还有一个容易忽略的点去掉 shell 和系统工具里默认安装的 setuid 位。BusyBox 安装到 target 之后逐个检查/bin/busybox和各个 applet 链接的权限位不要让ping、mount、su这些出现不合理的 setuid。在 BusyBox 里su、mount这类如果需要用建议用 sudo 或 capabilities 接管而不是直接给 setuid 权限。2.3 服务进程收敛默认不留多余端口与后门内核裁剪和文件系统瘦身只是静态层面动态层面的服务收敛同样关键。每开一个监听端口就相当于给攻击者开了一扇门。所以我一般对目标板上所有处于监听状态的服务做一个全量盘点netstat -tulnp # 或 ss -tulnp逐个看每个监听端口对应的是什么进程这个进程是不是产品必须的。常见的问题集中在调试服务没关telnetd、dropbear测试期开的 SSH、gdbserver产品出厂前必须全部清理。即使要留 SSH也要改端口、用密钥登录、禁止 root 密码登录。不必要的高危服务FTP、TFTP、NFS client/server、SMB这些在嵌入式设备上99%的情况不需要。开发期工具残留iperf、tcpdump这个可以留但要限制执行权限、nc、nmap等能删就删。nc是双刃剑攻击者一旦拿到 shell一个nc -e /bin/sh就能反弹 shell,所以我一般是直接从 rootfs 里去掉的。服务收敛之后下一步是默认策略转变让设备的默认策略从允许所有只禁已知风险改成拒绝所有只放行业务必须。这块要和防火墙配合后面第 5 节专门讲。3. 权限硬化用户体系与运行时防护很多人对权限硬化的理解还停留在改个密码、关个 telnet阶段但其实权限硬化要覆盖账号体系、文件系统挂载、内核运行时参数三个层面。三者缺一不可。3.1 账号体系收敛root 策略、SSH 与登录通道嵌入式设备最常见的配置是 root 密码弱口令或干脆不设密码。第一步就要把账号体系规整起来关闭不用的终端登录在/etc/inittab或 systemd 的serial-getty、getty配置里只保留你需要的串口 console调试口和虚拟终端。如果串口是生产测试口产品出厂后建议把 getty 关掉或改成需要认证。root 密码强策略如果产品形态必须有 root至少设置一个强密码并写入shadow文件且存放于只有 root 可读的分区或一次性写入启动参数安全存储区。不要把默认密码写在脚本里。限制 SSH 登录如果必须留 SSH配置PermitRootLogin prohibit-password、PasswordAuthentication no用密钥、限制允许登录的用户列表。但要注意密钥文件一旦丢失就是灾难建议在产线出厂时每个设备生成独立密钥对并安全存储公钥。清理 nologin 之外的 shell把/etc/passwd里所有非必需系统账号的 shell 都改成/sbin/nologin或/bin/false防止攻击者切换用户后获得可用 shell。禁用 root 直接登录后生产维护怎么办我的经验是给维护人员开一个普通用户账号通过sudo提权并且 sudo 配置里只放行确需的几条命令。这能在表面上增加一次认证的复杂度还能让审计日志里有明确的用户身份可追踪——用 root 直登日志里只能看到 root区分不出到底是哪个人。3.2 文件系统挂载与权限只读化是关键一步文件系统层面的硬化我建议直接采用只读 rootfs 独立可写数据分区的架构。这在嵌入式领域非常常见也是效果最显著的一层防护。具体做法是把/做成squashfs或只读挂载的 ext4如果 flash 支持把需要写入的目录比如/var、/etc、/home、应用缓存单独放到一个可写的分区或 overlayfs 中。这样攻击者即使拿到了 shell想往/usr/bin写个后门也写不进去只能在受限的可写区里折腾重启后还很可能丢。挂载选项上要注意这几个参数nodev不要在该分区上允许设备文件节点。可写分区挂载时加上防止攻击者创建块设备。nosuid不允许该分区上的 setuid 位生效。noexec禁止在该分区上执行二进制。注意应用本身如果装在可写分区就不适用了得自己权衡。ro只读固定不变的分区直接只读挂载。其实noexec有一个常见的坑我踩过不止一次如果你把/tmp挂成noexec有些安装包或脚本会在/tmp下执行二进制直接报Permission denied。所以在嵌入式里我会把/tmp做成tmpfs并且noexec但要确认应用的安装流程不需要在/tmp下执行程序否则会莫名踩坑。3.3 内核参数与运行时安全选项权限硬化还包含内核参数调整它们往往一句话就能生效但效果很实在。我常用的 sysctl 配置如下# 禁止 IP 转发除非你确实需要路由器功能 net.ipv4.ip_forward 0 # 禁止 ICMP 重定向防止路由欺骗 net.ipv4.conf.all.accept_redirects 0 net.ipv4.conf.default.accept_redirects 0 net.ipv4.conf.all.secure_redirects 0 net.ipv4.conf.default.secure_redirects 0 # 忽略广播 ping net.ipv4.icmp_echo_ignore_broadcasts 1 # 开启反向路径过滤防止 IP 欺骗 net.ipv4.conf.all.rp_filter 1 net.ipv4.conf.default.rp_filter 1 # 限制内核日志对普通用户的可见性 kernel.dmesg_restrict 1 # 限制 ptrace 范围防止调试器注入 kernel.yama.ptrace_scope 1 # 随机化内存映射地址 kernel.randomize_va_space 2如果设备上跑的服务不需要dmesg输出kernel.dmesg_restrict强烈建议打开。攻击者想通过内核日志获取内核地址布局绕过 KASLR的路就堵上了。kernel.yama.ptrace_scope也是嵌入式经常遗忘的——它是用户态防护里成本最小但效果很高的一招。另外U-Boot 阶段也要做防护。如果你不对物理攻击设防攻击者可以在 U-Boot 里改启动参数加init/bin/sh直接绕过 rootfs 的权限体系。我一般会在 U-Boot 里设置环境变量锁定setenv bootcmd后写回并且对 kernel 镜像做验签fitImage 校验 hash或者启动 secure boot 流程。这些是不是必须取决于你的威胁模型,但至少别把 U-Boot 的consolettyS0留成一个公开后门。4. 日志审计让每一次异常访问都留下痕迹日志审计这块嵌入式领域做得好的真的不多。很多设备上连 syslog 都没有出事后一查日志空的。日志审计不是为了出事之后给客户写报告用的它是你日常发现异常的主要手段。系统被入侵往往有大量早期信号只是没人看罢了。4.1 日志体系统设计syslog 与 busybox syslogd嵌入式系统日志组件主要有两套路线BusyBox 自带的 syslogd以及完整版的 rsyslog/syslog-ng。选型的核心是资源约束。BusyBox syslogd 的优势在于极轻CPU 和内存占用可以忽略不计。缺点是功能简单只支持按优先级写日志不支持按 program 或 tag 过滤远程转发也基本靠一句话配置不稳定。我一般用它做本地日志的兜底配置也简单/etc/syslog.conf *.info /var/log/messages authpriv.* /var/log/auth.log如果设备跑的是 systemdjournald 也是个选择它自带结构化字段、自动轮转还能通过journald的SystemMaxUse控制大小。但 journald 的二进制格式对单片机和极小内存设备并不友好如果你要跑嵌入式设备我更建议直接用传统的 syslog 到文件方案简单的grep就能分析便于后期集成日志采集。4.2 审计规则落地auditd 使用与实战配置要回答谁在什么时间做了什么syslog 往往不够精确这时候需要 Linux 的审计框架auditd。嵌入式设备上装 auditd 并不是奢侈它可以精确记录文件访问、系统调用、用户切换。一个典型的最小 auditd 配置# 记录所有 root 用户执行的命令 -a always,exit -F archb64 -F auid1000 -S execve # 记录 /etc/passwd 和 /etc/shadow 的写访问 -w /etc/passwd -p wa -k USER_MOD -w /etc/shadow -p wa -k USER_MOD # 记录关键配置目录 -w /etc/ -p wa -k ETC_CHANGE在嵌入式上开 auditd 有一个问题auditd进程占用一定的内存auditctl规则越多开销越大。如果你的设备内存只有 64MB那就别全量记录 execve只开文件访问的关键路径即可比如用户管理、网络配置、启动脚本这几个关键目录的wa权限。4.3 日志轮转、持久化与远程采集嵌入式设备重启是常态日志存在内存里tmpfs断电就没存在 flash 上又有磨损问题。我的经验是用两层方案日志实时缓存到 tmpfs速度快、不损伤 flash但断电丢失。定期 flush 到持久分区比如每 10 分钟把/var/log/messages同步到/data/log/下或者通过 logrotate 每天写一个文件到持久区。远程采集有条件的话最理想的做法是把日志实时转发到日志服务器。用 syslog 的ip:port语法就能实现或通过 MQTT 把安全告警不是全量日志上报到云端。logrotate 配置里要注意延长单个日志文件的保留周期但也要设置总大小上限。我一般这么配/var/log/messages { rotate 5 size 512K compress postrotate /bin/kill -HUP $(cat /var/run/syslogd.pid 2/dev/null) 2/dev/null endscript }如果设备有 RTC 和网络时间同步日志打出来的时间戳才真正有价值。没有准确时间日志审计基本废了一半。这一步也别忘了。4.4 日志审计的核心动作从日志里发现入侵线索配置完日志体系后关键的还在于人能不能坚持日常检查和应急排查。我习惯的做法是每天抓几个关键信号多次 SSH 登录失败grep Failed password /var/log/auth.log | wc -l非业务时间段的登录成功记录意外的网络连接ss -tunp查看异常外联未知的可执行文件出现在/tmp或/var/tmp下一旦发现异常日志就是第一现场。通过journalctl或传统 syslog 里的进程 PID、UID结合 auditd 记录的文件变更能快速还原攻击路径。没有审计日志的情况下这步根本无从谈起。5. 轻量防火墙默认拒绝才是真的拒绝最后一个维度是网络层防护也是大部分嵌入式工程师能最快上手的一块。但配上几个 iptables 规则和设计一个正确的防火墙策略之间差得很远。5.1 防火墙引擎选型iptables、nftables 还是内核 netfilter 直连嵌入式 Linux 下防火墙主要是 netfilter/iptables 体系。新内核3.13里 nftables 已经是主流推荐但在嵌入式领域 iptables 依然大量存在原因是很多老 SDK 用的内核版本较旧配套的 iptables 用户态工具更成熟。我做的项目一般遵循这个选型逻辑内核版本 4.x 且工具链支持优先 nftables。它语法更清晰、规则集更好维护、性能稍好还能避免 iptables 那一堆 legacy 兼容层的问题。老平台、老 SDK用 iptables-legacy但规则要写得克制。别追求花哨的 match够用就行。极小型设备比如没有独立防火墙需求仅做最基础的 DROP 策略直接通过 sysctl 开启net.ipv4.conf.all.rp_filter 内核网络参数然后用简单的 iptables 默认策略加两条规则即可。没必要引入繁重配置。5.2 默认策略与规则设计从允许所有到显式放行防火墙设计的第一原则是默认拒绝。也就是 INPUT、FORWARD、OUTPUT 链的默认策略全部 DROP然后一条条显式放行业务所需流量。举一个实际设备数据采集网关的 nftables 配置table inet filter { chain input { type filter hook input priority 0; policy drop; # 允许本机回环 iif lo accept # 允许已建立的连接及相关连接 ct state established,related accept # 允许 SSH 管理端口假设业务不需要从外网直接 SSH tcp dport 2222 ip saddr 192.168.1.0/24 accept # 允许 Modbus TCP 采集端口只限内网 tcp dport 502 ip saddr 192.168.1.0/24 accept # 允许 MQTT 上云端口 tcp dport 8883 accept # 其余全部拒之门外 log prefix DROP_INPUT: counter drop } chain forward { type filter hook forward priority 0; policy drop; } chain output { type filter hook output priority 0; policy drop; # 回环和已建立连接 oif lo accept ct state established,related accept # 允许外发 MQTT 连接 tcp dport 8883 accept # DNS 查询 udp dport 53 accept tcp dport 53 accept # NTP 时间同步 udp dport 123 accept } }需要特别注意的是 OUTPUT 链默认拒绝。很多人只敢对 INPUT 默认拒绝OUTPUT 完全放开。这样如果设备被种了木马木马还是可以随意外联。 OUTPUT 收敛后即使攻击者拿到了 shell他想要传输数据也会受到网络层限制必须折腾半天开洞而被审计日志发现的概率就大大提升。5.3 防火墙规则调试与常见自锁事故配防火墙最怕什么最怕把 SSH 规则写错导致远程连接的自己被锁在外面。我在这上面翻过车,那是在客户现场,改了一条 DROP 规则直接把管理连接干断,只能叫现场人员重启设备。后来我就学乖了总结了一套操作流程先把规则写成脚本文件比如/etc/nftables.conf或/etc/iptables.rules不要一边敲一边改线上规则。应用前先备份现有规则iptables-save /tmp/iptables.bak或nft list ruleset /tmp/nftables.bak。在测试环境完整跑一遍你的规则集确认放行的全通、拒绝的全拒。如果远程操作至少保留一个带外通道串口、IPMI或者设置一个定时任务在 5 分钟后自动恢复规则防止误锁。规则启用后逐项验证业务端口、管理通道、DNS、NTP 等是否正常。还有一个常见坑有些宽带路由器的网段会变化如果你的设备有双网口做桥接桥接模式下 iptables 规则跑到FORWARD链上而不是INPUT链你需要把容器的转发规则也明确加进去否则桥接流量就是裸奔的。这一点在做网关时尤其要小心。6. 第 16 讲课后思考题完整解析这次的第 16 讲我们讲的是嵌入式 Linux 安全加固的总体框架和威胁模型课后给大家留了几道思考题不少读者在留言区问了这里统一把解题思路完整梳理一遍。6.1 思考题一威胁建模与加固优先级题目一台面向家庭用户的智能摄像头主要功能是 RTSP 视频流、云平台接入、本地 SD 卡录像存储。请分析它面临的主要威胁并给出加固优先级。这道题考察的是威胁模型的实际落地核心要分清谁会攻击你、攻击能带来什么收益。智能摄像头普遍面临四类问题弱口令和漏洞导致直播流被劫持这是隐私问题也是最容易被媒体放大、导致产品口碑崩盘的问题。应该优先级最高。设备被拉入僵尸网络发起 DDoS这个近年非常常见Mirai 变种大量感染摄像头。对用户影响相对间接但威胁真实存在。物理接触后被提取录像和私钥涉及 SD 卡数据和设备密钥保护优先级中。云端账号体系被撞库或伪造涉及后端属于设计和流程问题。优先级建议排是远程弱口令/漏洞利用补默认密码强制修改、固件更新、僵尸网络防护补防火墙默认拒绝、关闭无关端口、最小化裁剪、物理攻击防护补SD 卡加密、flash 防读、云端账号问题补云端侧 MFA 等不属于单板加固重点。6.2 思考题二最小化裁剪的操作顺序题目开发一套基于 Buildroot 的网关系统请写出从默认配置到完成最小化裁剪的操作顺序。完整操作顺序可以这样列梳理产品功能需求确定必须的内核特性、设备驱动、用户态组件和业务进程。用 Buildroot 默认配置编译一遍生成一个基线固件确认能正常启动。运行make linux-menuconfig按功能清单裁剪内核关闭无用的协议、文件系统、驱动、调试选项并开启内核安全自防护选项。重新编译内核在目标板上跑冒烟测试一次不出问题也要逐个功能再验证直到所有功能仍然正常。用make busybox-menuconfig裁剪 BusyBox applet禁用 telnetd、tftp、httpd 等用不到的网络工具。清理 rootfs 里的开发工具、符号表、文档和静态库用size、du检查每个关键目录占用。检查最终镜像中的 SUID 文件逐个确认是否有存在的必要必要就换用 sudo/capability 方案。再跑一遍全量回归测试特别关注升级流程、恢复出厂、日志持久化这些与文件系统相关的功能。这道题的核心不是让你记住步骤而是理解裁剪必须基于需求清单而不是靠猜。凡是裁剪出来的东西都要有功能项的对应关系否则就有引入隐秘 bug 的风险。6.3 思考题三日志审计方案选型题目设备内存只有 64MBflash 256MB需要记录关键安全日志且实现远程审计。请选择日志方案并说明配置要点。这个资源约束下完整 rsyslog auditd 会偏重所以我的选择是 BusyBox syslogd timer 批量同步 远程 MQTT 告警私有协议。具体配置要点BusyBox syslogd 只做本地轻量记录-s 256限制单个文件大小避免 flash 被写满。关键模块如连接管理、用户登录、Web 管理通过自定义logger -t打 tag便于远端过滤。启用 logrotate按大小轮转保留 3 份压缩副本。通过一个轻量采集进程每 10 秒抓取最近新增日志用 MQTT 上报到安全中心可以只上报 WARN 以上级别减少流量。远端审计平台侧定期分析 MQTT 告警异常则通知运维。需要说明的是 auditd 是否引入取决于业务需求。如果对文件完整性有强诉求可以只在关键目录上做-w /etc的 audit 规则单独轮转不要全局开启。要保证 auditd 日志能写到持久区避免断电丢失。6.4 思考题四iptables/nftables 规则设计与沉默丢弃题目设备只运行一个业务监听 8081 端口和一个管理 SSH2222 端口只允许 10.0.0.0/8请设计 nftables 规则集并要求将非法访问做限速而不是简单丢弃。这道题的关键是限速而非盲丢。简单 DROP 会让攻击者每次都收到超时但不会增加他的扫描成本。更合理的做法是用limit配合日志超过阈值后加入 TEE/队列做进一步分析或干脆 drop这样既能发现扫描行为又不会影响正常流量。一个参考实现片段chain input { type filter hook input priority 0; policy drop; iif lo accept ct state established,related accept # 业务端口 8081 允许任意来源 tcp dport 8081 accept # 管理端口 2222 只允许内网并且限制每秒 3 个新连接 tcp dport 2222 ip saddr 10.0.0.0/8 accept # 对非法访问限速记录 ct state new limit rate 3/minute burst 5 accept log prefix NEW_CONN: counter # 其余丢弃 log prefix DROP_INPUT: counter drop }这里我故意把限速放在整体 drop 之前让正常的管理连接不受影响但异常来源因为命中 rate limit 会被直接 drop并记录日志。题目如果要求攻击者体验变差可以考虑在 drop 前加reject而不是静默丢弃但实际嵌入式设备上用drop更常见因为reject会暴露设备的防火墙存在同时可能造成扫描器更快确认端口状态。6.5 思考题五综合设计——把四个维度串起来题目请给出一个最小化裁剪 权限硬化 日志审计 防火墙协同工作的完整防护链路示例并说明每层防护如何兜住其他层的疏漏。这题是压轴的综合题需要打通所有模块。我以一个数据采集盒举例把四层防护串起来第一层最小化裁剪把网卡收包路径和协议栈的攻击面压到最小。这层做得好的话攻击者想通过畸形报文直接利用内核漏洞就很困难因为相关代码根本不在内核里。第二层权限硬化限制用户态权限的提升。即使攻击者通过某个应用漏洞获得了www-data或普通用户权限也无法轻易读取/etc/shadow、无法写/usr/bin、无法启动 setuid 程序提权链条被切断。只读 rootfs 在这里兜底让后门文件写不进系统目录。第三层日志审计记录异常行为。权限硬化不能保证一定防住提权但一旦攻击者开始扫描、试密码、改定时任务auditd 和 syslog 会留下痕迹。如果配合远程采集运维在几分钟内就能发现异常。第四层防火墙默认拒绝 OUTPUT 和 INPUT。即使攻击者拿到了 root shell想外联 C2 服务器也会被 OUTPUT 规则挡住想监听额外端口做反弹 shell 也会被 INPUT 策略限制这层兜住了前面所有防护失效后的横向移动。四层的关系是前面的防护减少被攻破的可能性后面的防护降低被攻破后的影响。单独哪一层都不是万能的组合起来才能形成纵深防御。这也是我对所有做嵌入式 Linux 产品的朋友的统一建议别信单一措施能保平安要把这四层做成默认配置写入产品的出厂基线里。到这里第 17 讲的内容全部分享完了。第 16 讲思考题的解析也覆盖到位如果你在题目里看到不同的设计选择只要你能说清楚当时威胁模型的假设条件那也完全成立。下一篇准备聊嵌入式 Linux 的固件签名与安全启动硬件实践这块和今天的权限硬化、最小化裁剪关系非常紧密到时候再见。 嵌入式Linux系统安全加固实战：裁剪、硬化、审计与防火墙
搞嵌入式 Linux 这么久我一直有个切身体会很多人把精力全放在驱动移植、内核编译、应用逻辑上安全这块基本属于能跑就行。但嵌入式设备恰恰是攻击者最喜欢的靶子——量大、分散、维护周期长、跑起来就没人管。我见过不止一台设备telnet 还开着root 密码是出厂默认防火墙规则全是 ACCEPT日志压根没开。被拉进僵尸网络、被当跳板、被拿去挖矿一点不冤。这篇内容我想把一套我实际在产线上落地过的嵌入式 Linux 系统级安全加固方案完整拆开讲一遍覆盖最小化裁剪、权限硬化、日志审计、轻量防火墙四个核心方向。文章最后还会把第 16 讲留下的思考题完整解析一遍。不管你是做网关、边缘计算盒子、工业控制器还是智能家居终端这套思路都适用。1. 嵌入式设备为什么成了安全短板威胁模型与加固主线在做任何安全操作之前先别急着敲命令。你得先想明白你的设备到底在防谁防什么想不清楚这一点后面做的所有加固都是在自我安慰。1.1 嵌入式系统面临的核心威胁与攻击路径嵌入式 Linux 设备面临的攻击路径我总结下来其实就四条。第一条是网络攻击。攻击者扫描开放端口利用默认口令、未修补的漏洞、不安全的服务比如旧的 telnet、弱 SSH 配置尝试进入系统。这条路径最通用成本最低很多僵尸网络的感染手段就是扫 23 端口、试 root/root、root/admin 这类弱口令。第二条是物理攻击。设备在用户手里用户拆开外壳接出串口通过 U-Boot 命令行修改启动参数或者直接把 flash 芯片读出来分析。别觉得拆壳是门槛对稍微有点动手能力的人来说这只是时间问题。第三条是供应链和部署攻击。镜像文件在生成、传输、烧录过程中被替换或篡改或者部署时运维人员把调试口开到了公网。这块更多是流程问题但单板层可以做校验和验签来兜底。第四条是应用漏洞利用。设备上跑的 Web 服务、云平台 SDK、协议解析组件比如 Modbus、MQTT、ONVIF 之类的库本身存在漏洞攻击者通过畸形报文或 payload 实现远程代码执行。这条路径在物联网设备上尤其常见。你要根据产品形态确定威胁模型。如果设备部署在可信内网网络攻击占比会低一些但也不能完全不设防——内网横向移动往往是攻击者最喜欢用的路径。如果设备是面向消费者、能直接被用户接触到的物理攻击就必须纳入设计考量。我见过不少团队做完网络加固就觉得万事大吉结果用户在串口上直接敲内核参数把 root shell 拿了出来前面的努力全部白费。1.2 加固体系的分层主线裁剪、硬化、审计、防火墙针对上面的威胁路径系统的加固工作可以收敛成四个层面的主线。我用一个表格把目标和手段先摆出来后面每一节再展开讲。层面对抗的威胁核心手段最小化裁剪攻击面过大、未知漏洞内核配置裁剪、rootfs 瘦身、服务收敛权限硬化提权、物理接触、未授权访问用户策略、文件权限、内核参数、只读挂载日志审计事后溯源缺失、异常无法发现syslog/auditd 配置、日志轮转与远程采集轻量防火墙网络攻击、异常访问nftables/iptables 默认拒绝、按白名单放行这四个维度不是我拍脑袋分的它们分别对应了攻击链上的四个环节减少入口、降低单点失陷后的影响、提升发现能力、增加横向移动成本。你单独做其中任何一项都有意义但要真正扛住实战攻击必须全部串起来。我见过有个产品只做了内核裁剪没做防火墙结果被扫到 8080 端口上的调试接口照样被打穿了。安全从来不是单点防御是纵深防御。2. 最小化裁剪把攻击面从源头压到最小最小化裁剪是我认为性价比最高的一步也是大多数嵌入式团队做得最糙的一步。很多人用的是 vendor 提供的默认 kernel defconfig一编出来啥都有各种不用的协议栈、文件系统、驱动模块全在里面。这不仅仅是体积和内存的问题更是攻击面的问题——每多一个编译进内核的子系统就多一份被漏洞覆盖的风险。2.1 内核配置裁剪按功能清单而非默认配置内核裁剪的第一步是先列功能清单再对着配置项逐个核对。别拿着默认配置删几个用不到的就结束正确做法是你得想清楚设备最终需要哪些功能然后把配置从这个清单反推出来。用一个实际例子说明我做一个工业数据采集网关CPU 是 i.MX6ULLCortex-A7 单核主要跑 Modbus TCP 采集、MQTT 上云、本地 Web 配置界面。内核配置裁剪时我遵循的原则是关闭不需要的协议栈IPv6 如果确实不用就关掉不过现在很多运营商网络和要求 IPv6,你要按需评估常用的比如CONFIG_IPV6测试环境用不到可以CONFIG_IPV6n。还有CONFIG_INET_DIAG这类诊断模块不是调试阶段就关了。关闭不需要的文件系统正常情况下嵌入式设备用squashfs、UBIFS、ext4就够了。vfat如果需要 U 盘升级就得保留不需要就关。CONFIG_FS_POSIX_ACL、CONFIG_FS_ENCRYPTION如果安全启动做了完整性校验加密这块单独考虑这些都按需。关闭不需要的驱动这是大头。一个默认 kernel 里驱动成百上千全编译出来既占空间又浪费时间。根据你的硬件原理图只开启外设对应驱动比如CONFIG_DRM没有显示输出就关、CONFIG_SOUND没音频就关、CONFIG_WIRELESS没 WiFi 就关。关闭调试接口CONFIG_DEBUG_FS、CONFIG_KPROBES、CONFIG_FTRACE、CONFIG_MAGIC_SYSRQ、CONFIG_DEVMEM、CONFIG_DEVKMEM这些都要评估。产品阶段 debugfs 我一般是关掉的CONFIG_STRICT_DEVMEM打开。CONFIG_KALLSYMS如果不需要内核符号给调试用也可以关掉这能让攻击者分析内核漏洞的难度大增。开启安全相关选项CONFIG_SECURITY、CONFIG_SECURITY_SELINUX或CONFIG_SECURITY_APPARMOR可以按需开启如果做完整性要求高的系统SELinux/AppArmor 是加分项但嵌入式下配置成本不低CONFIG_HARDENED_USERCOPY、CONFIG_SLAB_FREELIST_HARDENED、CONFIG_SLAB_FREELIST_RANDOM、CONFIG_RANDOMIZE_KSTACK_OFFSET这类内核自防护选项能开就开。裁剪后验证方式也很重要编译通过不等于能跑。我一般先做冒烟测试逐个测产品功能清单上的每一项再在目标板上跑一段压力测试。内核裁剪踩过最典型的坑是把某驱动编成模块而不是编进内核导致 rootfs 挂在很晚的阶段才加载模块起不来。所以如果这个功能是系统启动必须的比如网卡驱动、存储驱动必须y编进内核不能m。2.2 rootfs 瘦身BusyBox、库文件与符号裁剪rootfs 瘦身往往和内核裁剪同步进行。嵌入式领域用 BusyBox 是很主流的方案它把几十个常用命令行工具合并成了一个二进制大幅减少了体积和攻击面。但注意BusyBox 默认编译会带 applet很多你用不到的比如tftp、telnetd、httpd、ftpd一定要在配置里去禁用。默认开启意味着攻击者上传一个小文件就能跑起一个服务这是实实在在的风险。对于用户态动态库裁剪的核心是链接层面的优化。能用 musl 或 uClibc-ng 就别用 glibc前两者体积小得多攻击面也少一些。如果必须用 glibc记得 strip 掉符号表。用-ffunction-sections -fdata-sections -Wl,--gc-sections链接选项可以把用不到的 section 去掉实测体积能再小 10% 左右。还有一个容易忽略的点去掉 shell 和系统工具里默认安装的 setuid 位。BusyBox 安装到 target 之后逐个检查/bin/busybox和各个 applet 链接的权限位不要让ping、mount、su这些出现不合理的 setuid。在 BusyBox 里su、mount这类如果需要用建议用 sudo 或 capabilities 接管而不是直接给 setuid 权限。2.3 服务进程收敛默认不留多余端口与后门内核裁剪和文件系统瘦身只是静态层面动态层面的服务收敛同样关键。每开一个监听端口就相当于给攻击者开了一扇门。所以我一般对目标板上所有处于监听状态的服务做一个全量盘点netstat -tulnp # 或 ss -tulnp逐个看每个监听端口对应的是什么进程这个进程是不是产品必须的。常见的问题集中在调试服务没关telnetd、dropbear测试期开的 SSH、gdbserver产品出厂前必须全部清理。即使要留 SSH也要改端口、用密钥登录、禁止 root 密码登录。不必要的高危服务FTP、TFTP、NFS client/server、SMB这些在嵌入式设备上99%的情况不需要。开发期工具残留iperf、tcpdump这个可以留但要限制执行权限、nc、nmap等能删就删。nc是双刃剑攻击者一旦拿到 shell一个nc -e /bin/sh就能反弹 shell,所以我一般是直接从 rootfs 里去掉的。服务收敛之后下一步是默认策略转变让设备的默认策略从允许所有只禁已知风险改成拒绝所有只放行业务必须。这块要和防火墙配合后面第 5 节专门讲。3. 权限硬化用户体系与运行时防护很多人对权限硬化的理解还停留在改个密码、关个 telnet阶段但其实权限硬化要覆盖账号体系、文件系统挂载、内核运行时参数三个层面。三者缺一不可。3.1 账号体系收敛root 策略、SSH 与登录通道嵌入式设备最常见的配置是 root 密码弱口令或干脆不设密码。第一步就要把账号体系规整起来关闭不用的终端登录在/etc/inittab或 systemd 的serial-getty、getty配置里只保留你需要的串口 console调试口和虚拟终端。如果串口是生产测试口产品出厂后建议把 getty 关掉或改成需要认证。root 密码强策略如果产品形态必须有 root至少设置一个强密码并写入shadow文件且存放于只有 root 可读的分区或一次性写入启动参数安全存储区。不要把默认密码写在脚本里。限制 SSH 登录如果必须留 SSH配置PermitRootLogin prohibit-password、PasswordAuthentication no用密钥、限制允许登录的用户列表。但要注意密钥文件一旦丢失就是灾难建议在产线出厂时每个设备生成独立密钥对并安全存储公钥。清理 nologin 之外的 shell把/etc/passwd里所有非必需系统账号的 shell 都改成/sbin/nologin或/bin/false防止攻击者切换用户后获得可用 shell。禁用 root 直接登录后生产维护怎么办我的经验是给维护人员开一个普通用户账号通过sudo提权并且 sudo 配置里只放行确需的几条命令。这能在表面上增加一次认证的复杂度还能让审计日志里有明确的用户身份可追踪——用 root 直登日志里只能看到 root区分不出到底是哪个人。3.2 文件系统挂载与权限只读化是关键一步文件系统层面的硬化我建议直接采用只读 rootfs 独立可写数据分区的架构。这在嵌入式领域非常常见也是效果最显著的一层防护。具体做法是把/做成squashfs或只读挂载的 ext4如果 flash 支持把需要写入的目录比如/var、/etc、/home、应用缓存单独放到一个可写的分区或 overlayfs 中。这样攻击者即使拿到了 shell想往/usr/bin写个后门也写不进去只能在受限的可写区里折腾重启后还很可能丢。挂载选项上要注意这几个参数nodev不要在该分区上允许设备文件节点。可写分区挂载时加上防止攻击者创建块设备。nosuid不允许该分区上的 setuid 位生效。noexec禁止在该分区上执行二进制。注意应用本身如果装在可写分区就不适用了得自己权衡。ro只读固定不变的分区直接只读挂载。其实noexec有一个常见的坑我踩过不止一次如果你把/tmp挂成noexec有些安装包或脚本会在/tmp下执行二进制直接报Permission denied。所以在嵌入式里我会把/tmp做成tmpfs并且noexec但要确认应用的安装流程不需要在/tmp下执行程序否则会莫名踩坑。3.3 内核参数与运行时安全选项权限硬化还包含内核参数调整它们往往一句话就能生效但效果很实在。我常用的 sysctl 配置如下# 禁止 IP 转发除非你确实需要路由器功能 net.ipv4.ip_forward 0 # 禁止 ICMP 重定向防止路由欺骗 net.ipv4.conf.all.accept_redirects 0 net.ipv4.conf.default.accept_redirects 0 net.ipv4.conf.all.secure_redirects 0 net.ipv4.conf.default.secure_redirects 0 # 忽略广播 ping net.ipv4.icmp_echo_ignore_broadcasts 1 # 开启反向路径过滤防止 IP 欺骗 net.ipv4.conf.all.rp_filter 1 net.ipv4.conf.default.rp_filter 1 # 限制内核日志对普通用户的可见性 kernel.dmesg_restrict 1 # 限制 ptrace 范围防止调试器注入 kernel.yama.ptrace_scope 1 # 随机化内存映射地址 kernel.randomize_va_space 2如果设备上跑的服务不需要dmesg输出kernel.dmesg_restrict强烈建议打开。攻击者想通过内核日志获取内核地址布局绕过 KASLR的路就堵上了。kernel.yama.ptrace_scope也是嵌入式经常遗忘的——它是用户态防护里成本最小但效果很高的一招。另外U-Boot 阶段也要做防护。如果你不对物理攻击设防攻击者可以在 U-Boot 里改启动参数加init/bin/sh直接绕过 rootfs 的权限体系。我一般会在 U-Boot 里设置环境变量锁定setenv bootcmd后写回并且对 kernel 镜像做验签fitImage 校验 hash或者启动 secure boot 流程。这些是不是必须取决于你的威胁模型,但至少别把 U-Boot 的consolettyS0留成一个公开后门。4. 日志审计让每一次异常访问都留下痕迹日志审计这块嵌入式领域做得好的真的不多。很多设备上连 syslog 都没有出事后一查日志空的。日志审计不是为了出事之后给客户写报告用的它是你日常发现异常的主要手段。系统被入侵往往有大量早期信号只是没人看罢了。4.1 日志体系统设计syslog 与 busybox syslogd嵌入式系统日志组件主要有两套路线BusyBox 自带的 syslogd以及完整版的 rsyslog/syslog-ng。选型的核心是资源约束。BusyBox syslogd 的优势在于极轻CPU 和内存占用可以忽略不计。缺点是功能简单只支持按优先级写日志不支持按 program 或 tag 过滤远程转发也基本靠一句话配置不稳定。我一般用它做本地日志的兜底配置也简单/etc/syslog.conf *.info /var/log/messages authpriv.* /var/log/auth.log如果设备跑的是 systemdjournald 也是个选择它自带结构化字段、自动轮转还能通过journald的SystemMaxUse控制大小。但 journald 的二进制格式对单片机和极小内存设备并不友好如果你要跑嵌入式设备我更建议直接用传统的 syslog 到文件方案简单的grep就能分析便于后期集成日志采集。4.2 审计规则落地auditd 使用与实战配置要回答谁在什么时间做了什么syslog 往往不够精确这时候需要 Linux 的审计框架auditd。嵌入式设备上装 auditd 并不是奢侈它可以精确记录文件访问、系统调用、用户切换。一个典型的最小 auditd 配置# 记录所有 root 用户执行的命令 -a always,exit -F archb64 -F auid1000 -S execve # 记录 /etc/passwd 和 /etc/shadow 的写访问 -w /etc/passwd -p wa -k USER_MOD -w /etc/shadow -p wa -k USER_MOD # 记录关键配置目录 -w /etc/ -p wa -k ETC_CHANGE在嵌入式上开 auditd 有一个问题auditd进程占用一定的内存auditctl规则越多开销越大。如果你的设备内存只有 64MB那就别全量记录 execve只开文件访问的关键路径即可比如用户管理、网络配置、启动脚本这几个关键目录的wa权限。4.3 日志轮转、持久化与远程采集嵌入式设备重启是常态日志存在内存里tmpfs断电就没存在 flash 上又有磨损问题。我的经验是用两层方案日志实时缓存到 tmpfs速度快、不损伤 flash但断电丢失。定期 flush 到持久分区比如每 10 分钟把/var/log/messages同步到/data/log/下或者通过 logrotate 每天写一个文件到持久区。远程采集有条件的话最理想的做法是把日志实时转发到日志服务器。用 syslog 的ip:port语法就能实现或通过 MQTT 把安全告警不是全量日志上报到云端。logrotate 配置里要注意延长单个日志文件的保留周期但也要设置总大小上限。我一般这么配/var/log/messages { rotate 5 size 512K compress postrotate /bin/kill -HUP $(cat /var/run/syslogd.pid 2/dev/null) 2/dev/null endscript }如果设备有 RTC 和网络时间同步日志打出来的时间戳才真正有价值。没有准确时间日志审计基本废了一半。这一步也别忘了。4.4 日志审计的核心动作从日志里发现入侵线索配置完日志体系后关键的还在于人能不能坚持日常检查和应急排查。我习惯的做法是每天抓几个关键信号多次 SSH 登录失败grep Failed password /var/log/auth.log | wc -l非业务时间段的登录成功记录意外的网络连接ss -tunp查看异常外联未知的可执行文件出现在/tmp或/var/tmp下一旦发现异常日志就是第一现场。通过journalctl或传统 syslog 里的进程 PID、UID结合 auditd 记录的文件变更能快速还原攻击路径。没有审计日志的情况下这步根本无从谈起。5. 轻量防火墙默认拒绝才是真的拒绝最后一个维度是网络层防护也是大部分嵌入式工程师能最快上手的一块。但配上几个 iptables 规则和设计一个正确的防火墙策略之间差得很远。5.1 防火墙引擎选型iptables、nftables 还是内核 netfilter 直连嵌入式 Linux 下防火墙主要是 netfilter/iptables 体系。新内核3.13里 nftables 已经是主流推荐但在嵌入式领域 iptables 依然大量存在原因是很多老 SDK 用的内核版本较旧配套的 iptables 用户态工具更成熟。我做的项目一般遵循这个选型逻辑内核版本 4.x 且工具链支持优先 nftables。它语法更清晰、规则集更好维护、性能稍好还能避免 iptables 那一堆 legacy 兼容层的问题。老平台、老 SDK用 iptables-legacy但规则要写得克制。别追求花哨的 match够用就行。极小型设备比如没有独立防火墙需求仅做最基础的 DROP 策略直接通过 sysctl 开启net.ipv4.conf.all.rp_filter 内核网络参数然后用简单的 iptables 默认策略加两条规则即可。没必要引入繁重配置。5.2 默认策略与规则设计从允许所有到显式放行防火墙设计的第一原则是默认拒绝。也就是 INPUT、FORWARD、OUTPUT 链的默认策略全部 DROP然后一条条显式放行业务所需流量。举一个实际设备数据采集网关的 nftables 配置table inet filter { chain input { type filter hook input priority 0; policy drop; # 允许本机回环 iif lo accept # 允许已建立的连接及相关连接 ct state established,related accept # 允许 SSH 管理端口假设业务不需要从外网直接 SSH tcp dport 2222 ip saddr 192.168.1.0/24 accept # 允许 Modbus TCP 采集端口只限内网 tcp dport 502 ip saddr 192.168.1.0/24 accept # 允许 MQTT 上云端口 tcp dport 8883 accept # 其余全部拒之门外 log prefix DROP_INPUT: counter drop } chain forward { type filter hook forward priority 0; policy drop; } chain output { type filter hook output priority 0; policy drop; # 回环和已建立连接 oif lo accept ct state established,related accept # 允许外发 MQTT 连接 tcp dport 8883 accept # DNS 查询 udp dport 53 accept tcp dport 53 accept # NTP 时间同步 udp dport 123 accept } }需要特别注意的是 OUTPUT 链默认拒绝。很多人只敢对 INPUT 默认拒绝OUTPUT 完全放开。这样如果设备被种了木马木马还是可以随意外联。 OUTPUT 收敛后即使攻击者拿到了 shell他想要传输数据也会受到网络层限制必须折腾半天开洞而被审计日志发现的概率就大大提升。5.3 防火墙规则调试与常见自锁事故配防火墙最怕什么最怕把 SSH 规则写错导致远程连接的自己被锁在外面。我在这上面翻过车,那是在客户现场,改了一条 DROP 规则直接把管理连接干断,只能叫现场人员重启设备。后来我就学乖了总结了一套操作流程先把规则写成脚本文件比如/etc/nftables.conf或/etc/iptables.rules不要一边敲一边改线上规则。应用前先备份现有规则iptables-save /tmp/iptables.bak或nft list ruleset /tmp/nftables.bak。在测试环境完整跑一遍你的规则集确认放行的全通、拒绝的全拒。如果远程操作至少保留一个带外通道串口、IPMI或者设置一个定时任务在 5 分钟后自动恢复规则防止误锁。规则启用后逐项验证业务端口、管理通道、DNS、NTP 等是否正常。还有一个常见坑有些宽带路由器的网段会变化如果你的设备有双网口做桥接桥接模式下 iptables 规则跑到FORWARD链上而不是INPUT链你需要把容器的转发规则也明确加进去否则桥接流量就是裸奔的。这一点在做网关时尤其要小心。6. 第 16 讲课后思考题完整解析这次的第 16 讲我们讲的是嵌入式 Linux 安全加固的总体框架和威胁模型课后给大家留了几道思考题不少读者在留言区问了这里统一把解题思路完整梳理一遍。6.1 思考题一威胁建模与加固优先级题目一台面向家庭用户的智能摄像头主要功能是 RTSP 视频流、云平台接入、本地 SD 卡录像存储。请分析它面临的主要威胁并给出加固优先级。这道题考察的是威胁模型的实际落地核心要分清谁会攻击你、攻击能带来什么收益。智能摄像头普遍面临四类问题弱口令和漏洞导致直播流被劫持这是隐私问题也是最容易被媒体放大、导致产品口碑崩盘的问题。应该优先级最高。设备被拉入僵尸网络发起 DDoS这个近年非常常见Mirai 变种大量感染摄像头。对用户影响相对间接但威胁真实存在。物理接触后被提取录像和私钥涉及 SD 卡数据和设备密钥保护优先级中。云端账号体系被撞库或伪造涉及后端属于设计和流程问题。优先级建议排是远程弱口令/漏洞利用补默认密码强制修改、固件更新、僵尸网络防护补防火墙默认拒绝、关闭无关端口、最小化裁剪、物理攻击防护补SD 卡加密、flash 防读、云端账号问题补云端侧 MFA 等不属于单板加固重点。6.2 思考题二最小化裁剪的操作顺序题目开发一套基于 Buildroot 的网关系统请写出从默认配置到完成最小化裁剪的操作顺序。完整操作顺序可以这样列梳理产品功能需求确定必须的内核特性、设备驱动、用户态组件和业务进程。用 Buildroot 默认配置编译一遍生成一个基线固件确认能正常启动。运行make linux-menuconfig按功能清单裁剪内核关闭无用的协议、文件系统、驱动、调试选项并开启内核安全自防护选项。重新编译内核在目标板上跑冒烟测试一次不出问题也要逐个功能再验证直到所有功能仍然正常。用make busybox-menuconfig裁剪 BusyBox applet禁用 telnetd、tftp、httpd 等用不到的网络工具。清理 rootfs 里的开发工具、符号表、文档和静态库用size、du检查每个关键目录占用。检查最终镜像中的 SUID 文件逐个确认是否有存在的必要必要就换用 sudo/capability 方案。再跑一遍全量回归测试特别关注升级流程、恢复出厂、日志持久化这些与文件系统相关的功能。这道题的核心不是让你记住步骤而是理解裁剪必须基于需求清单而不是靠猜。凡是裁剪出来的东西都要有功能项的对应关系否则就有引入隐秘 bug 的风险。6.3 思考题三日志审计方案选型题目设备内存只有 64MBflash 256MB需要记录关键安全日志且实现远程审计。请选择日志方案并说明配置要点。这个资源约束下完整 rsyslog auditd 会偏重所以我的选择是 BusyBox syslogd timer 批量同步 远程 MQTT 告警私有协议。具体配置要点BusyBox syslogd 只做本地轻量记录-s 256限制单个文件大小避免 flash 被写满。关键模块如连接管理、用户登录、Web 管理通过自定义logger -t打 tag便于远端过滤。启用 logrotate按大小轮转保留 3 份压缩副本。通过一个轻量采集进程每 10 秒抓取最近新增日志用 MQTT 上报到安全中心可以只上报 WARN 以上级别减少流量。远端审计平台侧定期分析 MQTT 告警异常则通知运维。需要说明的是 auditd 是否引入取决于业务需求。如果对文件完整性有强诉求可以只在关键目录上做-w /etc的 audit 规则单独轮转不要全局开启。要保证 auditd 日志能写到持久区避免断电丢失。6.4 思考题四iptables/nftables 规则设计与沉默丢弃题目设备只运行一个业务监听 8081 端口和一个管理 SSH2222 端口只允许 10.0.0.0/8请设计 nftables 规则集并要求将非法访问做限速而不是简单丢弃。这道题的关键是限速而非盲丢。简单 DROP 会让攻击者每次都收到超时但不会增加他的扫描成本。更合理的做法是用limit配合日志超过阈值后加入 TEE/队列做进一步分析或干脆 drop这样既能发现扫描行为又不会影响正常流量。一个参考实现片段chain input { type filter hook input priority 0; policy drop; iif lo accept ct state established,related accept # 业务端口 8081 允许任意来源 tcp dport 8081 accept # 管理端口 2222 只允许内网并且限制每秒 3 个新连接 tcp dport 2222 ip saddr 10.0.0.0/8 accept # 对非法访问限速记录 ct state new limit rate 3/minute burst 5 accept log prefix NEW_CONN: counter # 其余丢弃 log prefix DROP_INPUT: counter drop }这里我故意把限速放在整体 drop 之前让正常的管理连接不受影响但异常来源因为命中 rate limit 会被直接 drop并记录日志。题目如果要求攻击者体验变差可以考虑在 drop 前加reject而不是静默丢弃但实际嵌入式设备上用drop更常见因为reject会暴露设备的防火墙存在同时可能造成扫描器更快确认端口状态。6.5 思考题五综合设计——把四个维度串起来题目请给出一个最小化裁剪 权限硬化 日志审计 防火墙协同工作的完整防护链路示例并说明每层防护如何兜住其他层的疏漏。这题是压轴的综合题需要打通所有模块。我以一个数据采集盒举例把四层防护串起来第一层最小化裁剪把网卡收包路径和协议栈的攻击面压到最小。这层做得好的话攻击者想通过畸形报文直接利用内核漏洞就很困难因为相关代码根本不在内核里。第二层权限硬化限制用户态权限的提升。即使攻击者通过某个应用漏洞获得了www-data或普通用户权限也无法轻易读取/etc/shadow、无法写/usr/bin、无法启动 setuid 程序提权链条被切断。只读 rootfs 在这里兜底让后门文件写不进系统目录。第三层日志审计记录异常行为。权限硬化不能保证一定防住提权但一旦攻击者开始扫描、试密码、改定时任务auditd 和 syslog 会留下痕迹。如果配合远程采集运维在几分钟内就能发现异常。第四层防火墙默认拒绝 OUTPUT 和 INPUT。即使攻击者拿到了 root shell想外联 C2 服务器也会被 OUTPUT 规则挡住想监听额外端口做反弹 shell 也会被 INPUT 策略限制这层兜住了前面所有防护失效后的横向移动。四层的关系是前面的防护减少被攻破的可能性后面的防护降低被攻破后的影响。单独哪一层都不是万能的组合起来才能形成纵深防御。这也是我对所有做嵌入式 Linux 产品的朋友的统一建议别信单一措施能保平安要把这四层做成默认配置写入产品的出厂基线里。到这里第 17 讲的内容全部分享完了。第 16 讲思考题的解析也覆盖到位如果你在题目里看到不同的设计选择只要你能说清楚当时威胁模型的假设条件那也完全成立。下一篇准备聊嵌入式 Linux 的固件签名与安全启动硬件实践这块和今天的权限硬化、最小化裁剪关系非常紧密到时候再见。