共 21 篇相关文章
这篇讲的是Petya和NotPetya这两个名字相似、利用方式也相似（均利用永恒之蓝漏洞）的勒索病毒，其内在实现到底有何关键不同。作者从五个具体的技术点切入，为读者进行了一次清晰的“法医式”对比。 两者最细微但关键的区别始于加密使用的XOR密钥：Petya用的是0x37，而NotPetya换成了0x07。随后，在病毒的核心部分Mini-Kernel中，NotPetya移除了那个标志性的红色骷髅显示模块。启动感染第二阶段的方式也不同，Petya调用NtRaiseHardError API强制重启，NotPetya则直接执行了shutdown命令。因此，在最终的表现上，Petya会显示骷髅，NotPetya则不会。它们最后展示的勒索信息文案也完全不同。 文章最后，作者也给出了一个务实的安全建议：面对此类攻击，确保拥有独立的离线数据备份，比支付赎金可靠得多。
这篇讲的是MySQL在关键业务中如何确保数据安全，作者指出单靠数据库应用层面远不够，必须构建从网络、系统到逻辑层的多维度防御体系。 文章详细拆解了四个层面的实操策略。在最基础的网络与系统层，建议包括将MySQL服务器严格限制在内网、设置防火墙白名单、修改默认端口与密码策略，以及将操作日志集中远传。在逻辑应用层，重点在于防范XSS、SQL注入等常见攻击，并对数据库连接凭据进行加密处理。而在MySQL数据库层，文章提出启用safe-update防止误删、延长binlog保存期以便审计、精细划分账户权限（如用UPDATE替代DELETE），以及利用触发器和审计插件进行防护。 最后作者强调，真正的安全是技术机制与全员安全意识的结合。这些建议具体可落地，涵盖了从基础加固到纵深防御的多个关键点，为企业制定自身安全规范提供了清晰的检查清单。
备份是数据保护的最后一道防线，但如果备份集本身没有防护，泄露的风险同样存在。这篇文章从这个角度出发，讲解了如何为Oracle RMAN备份集加上密码锁，实现加密存储。 作者从数据安全的现实威胁切入，指出RMAN备份集若被窃取，其数据风险等同于生产库被入侵。解决方案是利用RMAN在10.2及以上企业版中提供的`set encryption`命令，在备份过程中直接设置加密密码。文章详细演示了从配置加密算法（支持AES128/AES256等）到执行加密备份的完整步骤，并特别提醒：加密仅对`backupset`有效，`copy`方式不支持；若需备份到带库，则必须使用Oracle Secure Backup。 最具说服力的部分是实操验证。作者创建了测试表空间和数据，进行了加密备份，随后模拟数据文件丢失并尝试恢复。结果显示，在不知道密码的情况下恢复会报错；即使设置错误密码也无法成功。只有使用正确的密码才能顺利完成恢复，这直观地证明了加密机制的有效性。 整篇文章实操性强，不仅提供了命令行的具体操作，更通过正反验证让读者清晰看到加密带来的保护效果，对于关注数据库备份安全性的DBA来说，是一个直接可落地的加固方案。
这篇文章从近期界面、罗辑思维、中国企业家三起引发关注的版权道歉事件切入，深入探讨了数字时代版权的实际操作困境与可能出路。 作者首先厘清了版权（即著作权）的十七项具体权利，并指出其核心在于保护作品而非思想，且财产权可能已从原作者手中转让。文章的核心论证在于：传统版权体系是建立在“内容与介质不可分离”的现实上的，而数字化使得内容复制与传播的成本趋近于零，这导致整个体系的可操作性日益脆弱。在文字领域，严格维权的商业成本极高且效果有限。 对此，作者引用了互联网法律学者劳伦斯·莱斯格的观点，倡导一种更符合互联网精神的“创作共用”（CC）原则，即创作者可自主选择对他人开放部分权利。他以自身实践为例：对自己的文章，他欢迎署名转载，以此促进传播；而对他人的文章，他则坚持注明出处、仅作摘要并链接原文，以示尊重。文章最终主张，在保障人身权的前提下，创作者或许可以对自己“宽松”，对他人“严谨”，因为传播本身才是数字时代的核心要义。
在PHP开发中，数据库密码等配置信息如果直接硬编码在代码里，一旦代码仓库需要共享给第三方审查或合作开发，就会带来泄露风险。作者从这个常见的安全与协作矛盾出发，介绍了如何将敏感信息从代码中剥离出去。 核心方案是利用服务器环境来承载这些配置。一种常见做法是通过Nginx的`fastcgi_param`指令进行映射，代码中通过`$_SERVER`变量来读取。另一种方案是通过php-fpm的`env`指令设置，同样存放在`$_SERVER`中。文章特别指出，`env`配置必须写在php-fpm的主配置文件`php-fpm.conf`里才能生效。有经验的开发者（如@Laruence）也提示，使用Nginx方案会在每次请求时传输这些参数，可能带来开销，因此通过php-fpm或专用扩展（如hidef）来处理可能更为高效。 最终，通过将敏感信息从代码中剥离，代码变得更加干净，也更容易管理。剩下的安全职责转移到了服务器配置文件的权限控制上，而这通常比管理代码仓库的访问权限要简单得多。文章也顺带提到了一种兼容命令行环境的通用脚本思路。
这篇讲解SSH基础知识的文章，从“什么是SSH”直接切入，梳理了这项安全协议从诞生到普及的简要历程，重点则落在了实际操作与安全原理上。 文章系统梳理了SSH的核心用法：从最基础的远程登录命令，到端口参数修改。它详细拆解了SSH保障安全的关键——公钥加密验证流程，并分别阐述了两种登录方式：“口令登录”与“公钥登录”。对于后者，文章不仅解释了免密原理，还一步步指导读者如何生成密钥对、使用`ssh-copy-id`上传公钥，以及如何排查服务端配置问题。 特别值得注意的是，文中对公钥指纹验证、`known_hosts`文件的作用，以及`authorized_keys`文件的具体操作都有细致说明。这些细节对于理解SSH建立信任链的过程至关重要，也为实际配置提供了清晰路线图。对于需要安全远程管理的开发者或运维人员，这是一篇扎实的入门指南。
这篇讲的是如何给Perl程序源码加上一层保护，防止被直接查看。作者从保护SSH密钥和商业程序源码的现实需求出发，介绍了一种基于`Filter`模块的轻量级加密方案。 核心思路是在Perl解释器前插入一个“过滤器”：通过`use`一个自定义模块，在源代码被解析前先进行解密。这类似于PHP中的Zend加密机制。文章详细演示了具体实施步骤：首先下载并解压`Filter`模块，然后需要修改两个关键文件——加密程序`encrypt`和解密端的C代码`decrypt.xs`，在其中设置统一的加密密钥（字符）。使用这个定制好的程序对你的`.pl`文件进行加密，生成后的文件外观已不可读，但功能完全正常。 这个方案的巧妙之处在于，加密与解密使用同一套自定义密钥逻辑。部署时，只需在目标服务器上安装好包含了你修改过的`decrypt.xs`所编译出的so文件的`Filter`模块。由于最终的解密逻辑被编译成了二进制的so文件，密钥不会直接暴露，从而在一定程度上保证了源码的安全性。文章还附带了一个用于验证或还原的反解程序，完成了从加密到部署再到可能的调试的完整闭环。
这篇讲的是如何为Linux系统配置SSH无密钥登录，从而替代传统的密码验证方式。文章首先点明了SSH因RSA/DSA加密算法带来的安全性优势，这是其能取代telnet的关键背景。核心内容则聚焦于实操：通过ssh-keygen生成一对密钥，将公钥拷贝至远程机器的指定位置并设置正确权限（600），即可实现免密登录。 作者还特别指出，在完成基础配置后，用户可以进一步在sshd_config中关闭密码验证，将系统从基于密码的登录方式切换为更安全的密钥验证。整个过程步骤清晰，强调了权限设置这个容易出错的细节。对于需要频繁进行服务器管理运维的开发者和管理员来说，这套方法能有效提升工作效率与系统安全性。
作者遇到一个棘手问题：一个新上线的PHP脚本在并发20个请求时，Apache响应时间急剧飙升，但服务器CPU、内存等各项指标却完全正常。脚本使用了Mcrypt扩展进行加密操作。 问题的根源藏在一个看似不起眼的函数调用里：`mcrypt_create_iv`。作者发现，当未显式指定参数时，该函数在Linux下默认使用`/dev/random`来生成初始化向量。而`/dev/random`的工作原理是依赖系统的中断事件来积累熵池（随机性来源）。在并发请求较多、但系统本身又不够繁忙、中断产生不足的情况下，进程就会阻塞等待足够的随机数可用，从而导致整体响应缓慢，这正是“服务器指标正常但响应慢”的诡异现象。 解决办法是，在调用时显式指定使用`/dev/urandom`作为随机源，即添加`MCRYPT_DEV_URANDOM`参数。因为`/dev/urandom`不依赖系统中断，能够持续提供随机数。修改后，高并发下的延迟问题立即消失。 作者也补充了背景：PHP之所以默认选择可能阻塞的`/dev/random`，是因为理论上`/dev/urandom`在极端情况下可能被预测，安全性在设计上有细微的取舍。这也提醒我们，在查阅官方文档时，下方的用户评论往往藏着解决实际“坑”的关键线索。
作者从古希腊几何学中“可公度线段”的概念出发，讲述了数论中一系列精妙思想的演进。文章首先通过欧几里得求最大公度单位的直观例子，自然引出“辗转相除法”这一核心算法，并证明其效率。随后，以正方形边长与对角线不可公度的发现为例，揭示了无理数在古希腊时期就已出现的历史趣闻。 作者进而将话题转向数论中更深入的概念——互质与中国剩余定理。文中用生活中的公交车班次例子，生动解释了互质与最小公倍数的关系，并引出了《孙子算经》中的经典问题，展示了中国剩余定理的雏形与魅力。 这篇长文并非对教科书内容的简单复述，而是作者基于为《程序员》杂志撰写文章时积累的大量素材与个人思考，重新梳理的一条连贯知识脉络。他以牺牲部分严谨性为代价，力求用更直观、可读的方式，展现从古典数论走向现代公钥加密（如RSA算法）的奇妙旅程。
这篇讲的是如何保护即时通讯的隐私，作者从“我们每天的聊天真的安全吗”这个疑问出发。文章指出，即便使用了主流通讯工具，聊天记录仍可能因设备失窃、云端同步或服务商访问而泄露，而且我们发出的“消息发给谁、何时在线”这类元数据，也常被忽视地收集和分析。 作者的核心方案是分层次加固：首先，推荐采用经过独立审计的端到端加密协议（如Signal协议），确保只有通信双方能解密内容；其次，深入探讨了如何对抗元数据泄露，例如通过洋葱路由或使用能最小化元数据收集的App；最后，文章没有停留在工具推荐，而是提供了具体的设备设置指南，比如关闭云备份、启用应用锁、管理密钥与安全号码验证等实操步骤。 这篇文章的结论很明确：隐私保护不是单一开关，而是涵盖工具选择、设置习惯和安全意识的多层防御体系。它没有停留在理论层面，而是给了读者一份从聊天软件到手机系统都可逐步落实的检查清单，帮助我们在数字交流中守住私密空间。
这篇笔记从公共网络的不安全性切入，探讨了加密服务的基础原理。作者指出，在Internet等公共网络上，通信容易被未授权第三方读取或修改，而加密技术提供了关键保护：它不仅能防止数据泄露，还能检测篡改，从而在非安全信道上建立安全通信。 文章具体说明了加密的工作流程：使用加密算法对数据进行加密，然后以密文形式传输，预定接收方再进行解密。例如，即使第三方截获了加密数据，破解也极为困难，这确保了信息的机密性和完整性。笔记强调，加密通过这一机制，为现代网络通信奠定了安全基础，是抵御常见威胁的实用手段。 通过这篇学习笔记，读者可以快速掌握加密的核心概念和实际作用，为理解更复杂的安全协议或应用场景如VPN、HTTPS等提供起点。
这篇文章聚焦于近期频发的密码安全事件，特别是 CSDN 密码泄露事件以及安全公司公布的常见密码清单，以此为切入点探讨一个普遍却容易被忽视的议题。 作者从“密码是第一道安全防线”这一常识出发，揭示了现实与理想的差距。核心观点在于，尽管密码至关重要，但在实践中从用户到系统管理者往往都重视不足。文章具体分析了用户层面弱密码泛滥、习惯重复使用，以及系统层面可能存在的明文存储或加密不当等常见问题，指出了这些行为带来的连锁风险。 读完这篇文章，一个直接的启发是：密码安全并非只是一个“知道了就好”的概念，它需要被落实为具体的、可执行的习惯——无论是为用户设置强制复杂策略，还是作为个人，为不同服务使用唯一的高强度密码。它促使我们审视自己和组织内那些“看似安全，实则脆弱”的第一道锁。
这篇讲的是作者从CSDN明文密码泄露事件出发，对数据库密码的安全存储与验证进行的一次系统性思考。他没有停留在指责，而是顺着问题深入挖掘：为什么简单的哈希不够安全？常见的加盐、慢哈希等方案各自有什么优劣？ 作者对比了多种验证方法，最终提出了一套他认为相对安全且可行的组合方案，核心在于采用加盐哈希、并结合慢哈希算法来有效抵御彩虹表和暴力破解。文章并未止步于通用方案，更结合MySQL的认证插件机制，提出了对其当前验证流程的改进设想，让讨论落到了具体的实现层面。 对于开发者而言，这篇文章的价值不仅在于提供了密码存储的技术清单，更展现了一种从实际安全事件中提炼改进思路的方法论——如何将一次泄露危机，转化为加固自身系统安全的具体行动。
这篇讲的是CSDN用户数据库泄露传闻引发的一场安全质疑。作者从自己结束一天机房工作后的视角切入，面对不断涌入的询问——“CSDN是不是明文保存密码？数据库安全吗？”——决定对这个广受关注的事件做出公开说明。 文章的核心直指一个关键的技术事实与行业痛点：用户密码的存储方式。作者没有回避争议，而是以此为契机，解释了在事件背景下，密码以明文存储所蕴含的巨大风险，以及一个安全的系统应该采用的正确实践。这不仅是一次对传闻的澄清，更是一堂面向广大开发者和用户的安全警示课。 从这篇回应中，读者能获得的启发是双重的：对于普通用户，它提醒了在不同网站使用相同弱密码的潜在危险；对于技术从业者，它则强调了在系统设计之初就贯彻安全规范（如密码加盐哈希存储）的绝对必要性，因为事后补救的代价和信誉损失往往是巨大的。
这篇讲的是如何在浏览器中对cookie进行加密来增强数据安全。cookie在网络应用中虽方便存储数据，但也常面临安全威胁，比如跨站脚本（XSS）攻击可能导致敏感信息泄露。作者从这一背景问题出发，介绍了一种浏览器端的加密方案，核心思路是利用前端JavaScript和Web Crypto API，在客户端直接对cookie内容进行加密处理。 文章详细说明了加密过程的实现步骤：首先，选择合适的加密算法如AES-GCM，确保数据的机密性和完整性；其次，讨论了密钥管理策略，包括如何安全生成和存储密钥，避免密钥暴露风险。通过实际代码示例，展示了在读写cookie时如何无缝集成加解密操作，使得加密对开发者透明。这种方案的效果在于，即使cookie被拦截或窃取，攻击者也
这篇讲的是电子邮件地址如何避免被垃圾邮件爬虫抓取的问题。作者从自己的亲身经历出发，提到早在七八年前，自己的hotmail邮箱每天会收到数千封垃圾邮件，即使到现在，经过过滤每天仍约有40封漏网之鱼。这引出了一个现实矛盾：我们既希望在网页上公开邮箱方便联系，又不想被爬虫肆意收割。 文章指出，核心思路是像“搞乱代码”那样，对邮箱地址进行一定程度的混淆处理，让它对真人可读，但让自动爬虫程序难以识别。作者以自己的CoolShell博客实践为例，说明这种方法能有效减轻垃圾邮件负担。尽管文章没有展开具体技术细节，但它点明了一种简单有效的防护思路，对于需要公开联系方式的个人博客或网站维护者来说，具有直接的参考价值。
这篇讲的是一个常被忽视但实用的Shell脚本保护方案——shc。作者从一个具体的需求出发：当你的Shell脚本需要交付给他人使用，但又不想暴露内部逻辑或敏感信息时，该怎么办？ 核心方案是使用shc工具。它能把纯文本的Shell脚本，直接转换成一个编译后的二进制可执行文件。这个过程不仅实现了代码的“加密”（实际是混淆和二进制化），更重要的是，它改变了脚本的形态，使得直接阅读源码变得困难。 不过，文章也点明了这种方法的定位。它更适合用于分发包含复杂逻辑或商业价值的脚本，作为一种基础的代码保护手段。需要注意的是，它提供的并非是密码学意义上的强加密，主要是防止代码被轻易查看和修改。对于更高级别的保护需求，可能需要结合其他方案。这为开发者在脚本分发时提供了一个直接、轻量的选项。
这篇讲的是一个从Discuz中挖出来的PHP加密解密函数，特别适合需要时效性控制的场景。作者从实际应用出发，点明了它在单点登录令牌传递、生成临时密码等需求中的实用价值。文章最核心的亮点在于，这个函数支持一个类似“过期时间”的参数，加密后的字符串在指定时间后就能自动失效，这为很多短时验证逻辑提供了便捷的解决方案。比起普通的加密函数，这种可控的有效期机制让它更贴合业务安全需求。
这篇讲的是作者如何从一份经典的开源代码出发，打造适合自己的本地代理服务。代码基础来自SUZUKI Hisao编写的Tiny HTTP Proxy，这是一个轻量级但功能完整的HTTP代理示例。 作者没有停留在简单复制，而是针对实际需求，重点进行了两项关键改造。虽然具体修改细节需要在文中探寻，但这两点调整指向了让代理在本地环境中运行得更贴手、更可控的核心目标。 这种“站在巨人肩膀上做定制”的思路很常见，也很有价值。它避免了从零开始的重复造轮子，又通过针对性的修改解决了特定场景下的痛点。如果你正在寻找一个可改造的代理模板，或者对HTTP代理的工作机制感兴趣，这篇文章提供了一个从参考到实践的清晰路径。
