标签: 信息安全

  • 卡巴斯基 HIPS 设置

    新版的卡巴斯基 UI 发生了一些变化,对照卡饭论坛上的描述,记录一下新版卡巴斯基的 HIPS 设置。

    「自动执行推荐操作」的位置发生了变化,新版设置在程序主界面左下角齿轮状设置按钮-安全设置-高级设置-排除项和检测到对象时的操作

    「应用程序控制」名称发生了变化,新版叫「入侵防御」,可以点击程序主界面左侧「安全」,在这个栏目下找到。也可以从设置-安全设置-高级保护-入侵防御找到。

    原文提到的低信誉组,在新版中显示的是「低限制」组。各个设置的名称还是一样的,没有变化。

    在「文件和系统注册表」下,写入删除设置为「拒绝」并「记录事件」,读取创建设置为「询问」。

    在「权限」下,运行代码注入、读取其他进程的内存、执行底层磁盘访问、运行底层文件系统访问、关闭 Microsoft Windows、访问账户设置、访问网络摄像头、访问录音设备、隐藏的网络访问和使用浏览器命令行设置为「拒绝」并「记录事件」,启动设置为「允许」,其他的设置为「询问」。新版这里没有出现 KLDriver,如果有应该也是「拒绝」并「记录事件」。

    Chrome 低限制特殊设置

    要让 Chrome 正常工作,需要在「文件和系统注册表」下把读取写入创建都设置成「允许」,在「权限」下把启动其他进程停止其他进程暂停其他进程和线程运行代码注入读取其他进程的内存重复的内部进程句柄修改其他进程的内存使用浏览器命令行设置成「允许」。

    FireFox 低限制特殊设置

    要让 FireFox 正常工作,需要在「权限」下把运行代码注入读取其他进程的内存使用浏览器命令行设置成「允许」。

    雅思哥机考软件低限制特殊设置

    要让雅思哥机考软件正常工作,需要在「文件和系统注册表」把安全设置下的 SystemServices1SystemServices2写入设置为「允许」,把系统服务下的 Services_ImagePathServices_ParametersHost_path写入设置为「允许」。

    雅思哥机考软件卡巴斯基 HIPS 设置
    雅思哥机考软件卡巴斯基 HIPS 设置

    WeGame 低限制特殊设置

    要让 WeGame 正常工作,需要把 wegame.exe 和 launcher.exe「文件和系统注册表」的安全设置系统服务写入设置为「允许」。

    WeGame 卡巴斯基 HIPS 设置

    需要把 pallas.exe 和 rail.exe「权限」的读取其他进程的内存设置为「允许」。

  • 电脑和手机哪个更安全?

    虽然和用户有很大关系,但总体上来看在安全性方面,桌面设备(电脑)的上限更高、下限更低,移动设备(手机)的上限更低、下限更高。

    传统桌面设备的操作系统在安全方面做得并不好,这可能与桌面设备最初面向的用户有关。在电脑进入千家万户之前,计算机设备主要作为专业领域的生产工具被使用,设备本身用途单一,而且操作者也接受过一定的培训,所以人们没怎么专门在桌面设备的安全设计上花费过多精力。桌面设备给了使用者更多的自由,这看似是一件好事,但也带来一些隐患 —— 桌面设备的程序有很强大的能力。不知道你有没有注意过,在桌面设备上哪怕是记事本这样一个程序都能对你的全部文件进行读写操作。这意味着只要有一个程序出了问题,你所有的文件可能都要完蛋。(还记得敲诈了很多人的加密勒索病毒吗?)此外,很多桌面程序都有一些需要管理员权限的组件,以管理员身份运行的程序拥有对桌面操作系统的完全控制权,不受限制的权限让这些程序变得更加危险。

    与传统桌面操作系统不同,安卓、 iOS 这类现代移动设备操作系统在设计之初就考 虑了更多的安全问题。不像桌面操作系统的程序能操作用户所有文件,在移动设备操作系统中,应用程序被隔离开来,运行在一个个“沙箱”里,大多数情况下只能操作各自的文件。如果“沙箱”正常工作,哪怕是病毒一样的恶意程序也无法更改其他应用的文件,更不要说篡改设备操作系统了。此外,代码签名、安全芯片以及常态化漏洞防范措施都使得现代移动设备操作系统更加难以入侵,大大提高了系统的安全下限。不过尽管如此,移动设备还是存在过于依赖供应商的问题,沙箱也并非总是好用。假如你使用 T 公司的 W 软件聊天,如果 W 软件被攻破,虽然有沙箱限制保护了其他部分,但是在 W 软件聊天的记录、收发的文件却难以幸免。所以在移动设备上你很大程度要信任、依赖供应商,无论是应用软件作者还是操作系统开发者又或者是设备生产厂商,你都需要把一部分安全责任托付给他们。然而现实中可以信赖的供应商非常有限,这就让移动设备的安全上限被拉低,用户即便有专业知识和能力也难防被供应商拖后腿。

    不过对于大部分普通人而言,能正确安全地使用桌面设备并不简单,在威胁模型合适的条件下,移动设备的安全性或许更具优势。

  • 认证和加密的区别

    使用电脑、手机等设备时经常会遇到需要输入密码的情况,比如开机后需要输入密码,登录网站需要输入用户名和密码,打开一些压缩包时也会被提示需要密码。虽然都是一串字符,但在不同场景下密码的用途并不总是一样的。有的密码是用来“认证”的,而另一些密码则是用来“加密”(或“解密”)的。理解这两者之间的区别有助于认识到这些密码在保护信息的过程中如何发挥作用。

    “认证”用途的密码现在已经非常常见,这些密码的作用是证明身份,往往还需要和其他信息(如用户名、手机号等)一起使用。各种登录场景下的密码往往就是“认证”用的。来看一个例子,假如张三刚换了手机,要在新手机上登录微信。首先他需要输入自己的微信号,来让微信知道稍后应该显示发给张三的消息,而不会把应该由李四接收的消息显示到张三的手机上。但微信怎么能够确认这个输入了张三微信号的人就真的是张三,而不是其他人呢?如果不加确认仅凭微信号就允许登录,那么其他人就能使用张三的微信号、查看张三的消息或者给张三的联系人以张三的身份发消息,这显然是非常危险的。张三需要一种方式来证明自己就是这个微信号的主人,而密码就可以作为这种证明方式。张三输入注册微信号时设置的密码,微信进行比对,如果两者相符,那么微信便可以认为张三就是这个微信号的主人,于是允许登录。这便是密码的“认证”用途。

    除了“认证”,密码还能被用来“加密”(或“解密”)信息,一般创建或者打开压缩包时输入的密码就是用来加解密的。“加密”用途的密码往往要配合某种加密算法(可以简单把算法理解为“计算方法”的缩写)一起使用,以便将来能够把加密过的信息解密出来。下面来看一个假想的例子,为了简单起见,假设需要加密的信息(明文)和用来加密的密码都是整数,而使用的加密算法是把这两个整数相加得到结果(密文),相应的解密方法就是用“密文”减去“密码”得到“明文”。比如把信息(明文)2024使用这个算法加密,设置密码为123456,那么加密得到的结果(密文)就是125480。对于一个不知道这里使用的密码和加密算法的人来说,从密文125480无法得知原来的明文是2024,因此“加密”过程保护了信息(明文)2024。即便公开了加密算法,在没有密码123456的情况下,也无法仅从密文125480就确切知道明文是2024。而如果同时知道密码和加密算法,就能从加密后的信息(密文)125480得到原来的信息(明文)2024。这便是密码的“加密”用途。

    可以看到,密码在“认证”和“加密”过程中有着不同的作用。在“认证”过程中,密码只是作为一种事先约定好的口令来证明身份。身份证明可以通过很多方式完成,比如通过相貌、指纹、DNA等生物信息或通过身份证、护照、驾驶证等凭据信息。信息本身并不被“认证”密码直接保护,保护实际是由信息保管者提供的。而在“加密”过程中,密码直接参与到密文的生成过程中,和加密算法一起,对信息起着直接的保护作用,这里的保护来自数学和密码学。

  • 网盘同步不等于备份

    像 Dropbox, Google Drive, iCloud Drive, OneDrive 和坚果云这样的网盘主要提供同步服务,但却也常被视作文件备份的选项,一些用户甚至把这种同步盘作为了唯一的备份选项,混淆了网盘同步和备份的概念。这种混淆对于保障数据安全会产生负面影响。

    Dropbox, Google Drive, iCloud Drive, OneDrive 和坚果云这样的网盘,主要功能是把电脑或手机上的某一目录同步到网盘中,使文件能够在多个设备上访问或修改。比如,早上起来你在家里的电脑上构思了一篇文章,这份文档放在同步盘中;到了办公室你突然有了新的灵感,于是拿出手机对同步盘上的这份文档进行修改;下班回家后打开电脑,你在手机上修改后的文档已经被同步盘同步到你的电脑中,虽然文档还在电脑上同样的位置,但当你打开文档时看到的是在手机上修改后的版本,而不是早上最初构思的文章。对于同步盘可以这么说:“同步”是用户购买的主要功能,而“存储”(网盘空间容量)只是同步所需要的一个条件而已。(网盘传输流量是同步盘的另一个收费维度,但并不是所有产品都对流量收费。)

    虽然同步盘能让用户随时随地访问、修改文件,但这种方式对于备份而言并不理想。一方面,同步盘的价格在网盘中一般都比较贵,国内用户将 iCloud Drive 或坚果云的费用与其他网盘进行比较即可看到明显差距。另一方面,由于同步盘的特性,对文件的删除和修改都会被同步,这意味着无论是用户操作失误还是攻击者恶意删改都可能会导致多台设备上的数据永久丢失;虽然几乎所有的同步盘都提供了回收站和版本记录这样的功能,但这些功能大多只能缓解用户操作失误带来的损失,几乎都没有抵御攻击者恶意删改的能力。仅基于这两个方面,网盘同步就不适合被用作主要的备份方式。

    那么应该如何备份才好?在国内面向个人用户的市场上,我还没有看到理想的备份产品。个人用户目前只能考虑采取一些通行的备份策略来防止数据遗失。

  • 使用 CDN 之后正确获取访客真实 IP 的方法

    网络上大多数教程给出的方法都是通过修改程序代码,直接取 X-Forwarded-For 等请求标头的值替换原来 REMOTE_ADDR 变量的值作为原 IP,这种做法有很大的安全隐患

    安全隐患

    根据 RFC 3875 文件,REMOTE_ADDR 变量的值必须为发送请求到服务器的客户端的网络地址。在实践中 REMOTE_ADDR 变量的值往往由服务器直接设置为发送请求的客户端网络地址,而不是由客户端提供,因此其真实性有保证。

    与 REMOTE_ADDR 变量不同,X-Forwarded-For 请求标头的值不是由服务器直接决定,可以由客户端自行设置,实践中一般由代理服务器在转发请求时设置。因为 X-Forwarded-For 请求标头的值可能被客户端伪造,所以不应该轻易相信其真实性

    由于 REMOTE_ADDR 变量的值和 X-Forwarded-For 请求标头的值具有不同的可信度,使用低可信度 X-Forwarded-For 请求标头的值去替换高可信度 REMOTE_ADDR 变量的值便会产生不可忽视的安全隐患。比如,攻击者可以通过伪造 X-Forwarded-For 请求标头来绕过基于 IP 的频率限制、访问控制。更进一步,攻击者还可以构造具有危害性 X-Forwarded-For 请求标头来对服务器进行多种攻击,例如注入恶意代码进行 XSS 攻击就是一种可能的行为。

    正确做法

    在使用 X-Forwarded-For 请求标头的值之前应该确保其内容可信。因为 X-Forwarded-For 请求标头一般由代理服务器添加,所以至少应该先确认请求来自可信的代理服务器才可使用 X-Forwarded-For 标头的值。

    对于使用 CDN 的网站,如果服务器是 nginx,那么在 ngx_http_realip_module 模块的帮助下这一过程将会十分简单。只需编辑相应的 nginx 配置文件,在其中的 http、server 或 location 段,使用 set_real_ip_from 指定可信代理服务器地址(即 CDN 节点的地址),然后使用 real_ip_header 指明一个请求标头(即 X-Forwarded-For 标头),保存并重载 nginx 使配置生效。这样 nginx 收到请求后会检查请求的 REMOTE_ADDR 是否与 set_real_ip_from 相符,如果相符,nginx 会用 real_ip_header 对应标头的值替换 REMOTE_ADDR 原有的值,后端程序只需要正常使用 REMOTE_ADDR 的值即可。这种做法一般不需要改变后端程序。

    参考资料