SSH

共 23 篇文章。

作弊条:SSH 的 ProxyJump 跳板服务

• Cheatsheets

问题

有些环境中,SSH 服务器可能无法从 Internet 直接访问(例如,SSH 服务器可能使用的是一个私有 IP地址,或是 Internet 服务提供商没有提供 IPv6 服务,而 SSH 服务器只提供 IPv6 服务)。

考虑到 SSH 已经进行了相互认证(连接时客户端会验证服务器的公钥是否与已知公钥,例如 ~/.ssh/known_hosts,或是通过 DNSsec 发布的 SSHFP RR 匹配;服务器端则会验证用户是否能证明自己拥有与授权公钥对应的私钥),因此比较常见的解决方法便是使用 VPN、在防火墙上穿孔,或是使用代理服务器。

由于 SSH 自身也提供了许多转发功能,因此如果中间的跳板服务器也提供 SSH 服务,便可以使用这些跳转服务器直接作为代理服务器来用。与前面那些传统方法相比,这样做的优点是避免了安装额外的软件,也不需要特别指定端口。

阅读全文… ( 本文约 1419 字,阅读大致需要 3 分钟 )

用 FIDO key 来做 SSH key

• Security

OpenSSH 8.2 中新增了 FIDO/U2F 支持。它支持两种密钥对类型: ecdsa-sk 和 ed25519-sk。需要注意的是并非所有的 FIDO Security Key都实现了 ed25519-sk 的硬件支持:例如,截至2022年,Titan Security Key 就不支持 ed25519-sk。

使用 FIDO key 的 SSH key 在使用上和之前的 SSH key 类似,主要的区别在于在登录时系统会确认用户是否在机器旁边(通常是碰一下 FIDO key),这可以显著地改善安全性:与之前的 SSH key 不同的是,即使机器上的 U2F/FIDO SSH key 私钥文件被攻击者获得,在没有硬件 FIDO key 的情况下也无法使用这个私钥。对于对方同时能获得私钥文件和物理访问的情况,参见 xkcd/538,就不要跟扳手过不去了。

阅读全文… ( 本文约 718 字,阅读大致需要 2 分钟 )

还是得提高知识水平

• Security

📜 freebsd-update 目前已进入维护状态并可能在后续 FreeBSD 版本中逐步被替换掉。

今天搞了一个 大新闻。如果你用BIND并且今天之前没打过补丁的话,请读到这里为止,立即去补吧。

我觉得还是得提高知识水平。做 freebsd-update 补丁的时候,赫然发现修改的文件中有一个不认识的:

阅读全文… ( 本文约 400 字,阅读大致需要 1 分钟 )

FreeBSD.org 这次的入侵事件

• Postmortem

我回国之前, FreeBSD 安全团队内部正在准备一项重要的安全公告,不过这次不是由于 FreeBSD 的代码本身,而是由于 FreeBSD 项目集群中的一部分受到了入侵。这份公告后来于 11 月 17 日正式 发表。

阅读全文… ( 本文约 1152 字,阅读大致需要 3 分钟 )

在服务器上用gpg-agent

• Security

上回书说到通道服务器的问题。在 /etc/csh.cshrc 中添加下列内容,可令系统同时启动 gpg-agent 和 ssh-agent:

1
2
3
4
5
6
7
setenv SSH_AUTH_SOCK    /dev/null/nonexistent
if ("${TERM}" != "su") then
        [ -e ~/.gpg-agent.csh ] && source ~/.gpg-agent.csh >& /dev/null
        echo UPDATESTARTUPTTY | /usr/local/bin/gpg-connect-agent >& /dev/null || /usr/local/bin/gpg-agent --daemon --ignore-cache-for-signing >& ~/.gpg-agent.csh && source ~/.gpg-agent.csh >& /dev/null
        [ -e ~/.ssh-agent.csh ] && source ~/.ssh-agent.csh >& /dev/null
        [ -e ${SSH_AUTH_SOCK} ] || ssh-agent -c -t 20m >& ~/.ssh-agent.csh && source ~/.ssh-agent.csh >& /dev/null
endif

启动 gpg-agent 的作用是在一段时间内不用重新输入 gpg 的密码。

阅读全文… ( 本文约 412 字,阅读大致需要 1 分钟 )

ZFS的自动化备份

• Data Management

主任说:

冗余不做,日子甭过;备份不做,十恶不赦。

以前一直是每天手动给自己的新服务器做备份,最近找时间写了一套脚本来自动完成这个事情。

脚本没啥复杂的,大体的思路是这样:

  1. 在源上根据日期命名生成一份新的快照;
  2. 将上次备份机器收到的快照和新快照之间的差异 pipe 给 xz,然后再把结果pipe给ssh(使用key验证),传到备份机上;
  3. 备份机解压缩、zfs receive之后,如果成功,ssh到源系统上记录自己拿到的那个新的快照日期;

由于是通过 Internet (从AS6939送到AS33651)传递快照,所以使用了压缩。用ssh来完成传输的考虑主要是因为它能够做到互相验证身份。

阅读全文… ( 本文约 704 字,阅读大致需要 2 分钟 )

在服务器上运行的 ssh-agent

• Security

之前 @quakelee 提的一个问题(通道上登录第二台机器作为跳板登录第三台机器,但不把ssh私钥传到中间那台机器上)。如果shell是csh,在 ~/.cshrc 中加入:

source ~/auth.csh
[ -e ${SSH_AUTH_SOCK} ] || ssh-agent -t 15m -c > ~/auth.csh && source ~/auth.csh

然后所有的 csh 就可以使用同一个ssh agent了。

阅读全文… ( 本文约 294 字,阅读大致需要 1 分钟 )

安全:该做什么和不该做什么

• Security

很多事情都有Do’s and Don’ts,这里试着整理一下与安全有关的。

本文版权所有 © 2010 Xin LI delphij@FreeBSD.org 保留所有权利;非商业转载请注明出处 https://blog.delphij.net/, 谢绝商业转载。

安全不能建立在"别人不知道"的基础上

“别人不知道"是一种非常常见的安全 假象,举例来说,一种自己设计的山寨加密算法、一个系统中一般人不知道的位置等等,都属于这一类。

将安全建立在"别人不知道"的基础上是非常危险的。首先它会给设计者和用户带来"安全"的幻像,这会直接导致与系统交互的人放松警惕;其次,这样的设计往往留有"后门”,甚至是设计者不知道的后门(因为往往他们并不对这类设计进行充分的、专业的审计),容易被攻击者利用;最后,这种做法存在第三方泄密问题,即,使用这种系统的人,需要提防设计系统的人被其他人买通并泄漏一些秘密的情况。

延缓攻击的手段不能用来阻挡攻击

有许多延缓攻击的手段,例如改变服务的端口(比较常见的如将 ssh 改为 tcp/22 以外的端口),或禁止服务程序显示自己的版本等等,或仅仅简单地启用防火墙,这些手段起到的作用只是延缓攻击,而不应作为一种安全屏障。对于多层次式的安全设计来说,采取这些措施有助于提高检测到入侵的机会,但是它们本身并不会提高安全性。

与前一种情况类似,这种做法也只是让管理员放松警惕。例如以 ssh 为例,有人认为将端口改为一个非知名端口可以避免相关的攻击,但事实是,攻击者依然可以利用 ssh 实现或协议设计中存在的一些漏洞来攻破系统。拥有特定资源的攻击者甚至不需要直接对目标系统实施攻击。在较复杂的攻击手段中,包括简单的 port knocking 一类的保护手法,都可以使用类似分组重放这样的方法来逐步攻破。

采用层次式的安全设计

所谓层次式的安全设计,说的是在一套安全系统中包含不同层次的、存在层次式监控关系的安全结构。例如,将本地包含执行文件的那些文件系统通过一定的方式导出给监控网段的机器,就可以让那些机器在攻击者不知情,或至少不太容易注意到的情况下对入侵进行检测;通过将一些重要日志发到以不同的访问控制机制,甚至不同网络协议的记录设备上,则可以有效地检测入侵者的入侵行为,并为日后的分析留下更多的有用信息。

层次式安全在现实中也有应用。例如产品的质检,除了制造商自己进行的质量控制之外,有时分销商或政府也会进行一些抽样的检查。我们注意到,这些设计中的一个重要的特点是在不同的系统中使用不同的访问控制逻辑。例如,日志服务器必须从特定的客户端,甚至只能从某些隔离的内网登录。此时,延缓攻击的手段可以作为它的一项辅助设施,即其目的并不是阻止攻击,而是吸引攻击者在攻击目标上花费更多的时间,从而帮助入侵检测机制更容易地检测这些攻击。

不要轻信任何东西,包括X.509证书

安全系统的设计者必须对安全有全面的理解和认知。有一句很著名的话叫做 In God we trust, all others must submit an X.509 Certificate,需要注意的是,这里说的是 must submit,并没有说 submit 了就可以 trust 了。

和前面所说的层次式安全设计类似,我们的一个基本假定应该是,一个安全系统中的任何参与者,无论是用户还是计算机或程序,都是可能存在弱点的。安全系统,或用户,都不应轻信任何东西,例如,在特权隔离 (Privilege Separation) 这样一种设计中,特权进程除了完成那个非特权的子进程的请求之外,还有一个任务是维护一个"理性状态机"(Sanity DFA),这个状态机的作用是检测非特权进程的异常状况,如果发生这样的情况,则特权进程有拒绝提供服务,并杀掉非特权进程的责任。作为用户,对于系统给出的响应,除了验证对方的证书之外,也应有常识性的了解和适当的判断。

阅读全文… ( 本文约 3699 字,阅读大致需要 8 分钟 )

实现安全的三种途径

• Security

回国的时候和 康神 及端木吃饭的时候聊起过这个话题,这里整理出来。

实现安全有三种主要的手法:基于隐蔽的安全(或者,基于假象的安全)、基于默认配置的安全和基于设计的安全。

基于假象的安全很容易理解,也很容易实现。举一个简单的例子,在一片西瓜地前面戳一块牌子,说这块西瓜地里有一个西瓜里面注射了剧毒。

可以想象,由于信息的不对称(不知道是哪个西瓜有毒,或者根本就没有西瓜有毒),试图偷西瓜的人就会有所忌惮—-如果偷走的西瓜含有剧毒,那么这个西瓜是没办法吃的。然而,这样做有至少三个很致命的弱点:首先,为了实现最大化的利益,很可能瓜地的主人并不真的注射剧毒(或者反过来说,把偷瓜的人毒死并不是他的目的,他的目的是尽可能地保护瓜不被偷);其次,即使瓜地的主人真的只给一个西瓜注射了剧毒,那么如果有人偷了那个西瓜并且死掉,那么知道这件事的人就可以冲过来直接把所有的西瓜偷走;最后,一个以牙还牙的小偷,很可能会在牌子上留下这么一段话:现在有两个了……

简单地说,基于假象或隐蔽的安全,建立在"别人不知道其机制"的基础上。这样的做法有时能够在一定程度上延缓攻击,但并不能使攻击的成功率降低。将弱点隐蔽这种方法成本比较低,例如,把门钥匙放在门框上、将知名服务端口如ssh(tcp/22)转到不知名端口如tcp/12580上、port knocking技术,以及国内银行常用的Active X插件等等。然而,假象终归是假象,这些方法都不能真正改善系统的安全性。这类做法,充其量只能作为没有其他更好的办法时候的一种临时 workaround,而不能带来长久的安全。

第二种做法,也就是基于默认配置的安全,是一类非常常见的策略。这种做法通常与其他安全机制合并使用。简单地说,采用这种策略的系统,在其出厂的时候是没有暴露在外的弱点的,例如它可能只开启了非常少量,甚至完全不开启任何服务,随后,管理员可以根据需要进行配置来开放一些需要的服务。

阅读全文… ( 本文约 1515 字,阅读大致需要 4 分钟 )