中间人攻击(man-in-the-middle attack)：你和互联网中间的第三人
这篇从GitHub访问异常的事件谈起，具体解释了“中间人攻击”这一安全威胁。作者先用爱丽丝与鲍伯的通信故事，生动演示了攻击者如何在看似加密的通道中窃听并篡改信息，指出在公共Wi-Fi等场景下，密码和聊天记录都可能暴露。 文章进一步对比了主流浏览器对这类攻击的检测能力。现代浏览器在遇到伪造SSL证书时会持续发出醒目警告，而当时市场占有率很高的360安全浏览器，在第二次访问同一伪造站点时，竟弹出了“绿色网站认证”的提示，这与它的“安全”名称形成了鲜明反差。 作者基于此事件强调，中间人攻击具有隐蔽性和现实危害，那次针对GitHub的攻击就持续了约一小时。文章最后提供了一个可用于实时比对真假证书的工具，帮助读者在实践中加深理解。
苹果 Mac OS X 系统下锁屏的快捷键
作者发现了一个看似简单却被广泛误解的技术细节：Mac系统下锁屏快捷键。尽管在Windows上`Win+L`是常识，但许多Mac用户甚至网上教程都给出了复杂答案——或建议合上盖子，或引导创建脚本访问钥匙串，避开了直接回答。作者指出，这种“锁屏是Windows思维”的论调，反而让基础功能变得神秘化。 问题的根源在于，Mac默认未为“锁屏”提供类似Windows的全局快捷键，导致用户和内容创作者绕远路。文章的核心价值在于直接戳破这种信息差，给出最直接的解决方案：**同时按下`Control + Shift + Power (或Eject)`键**即可立即锁屏。这个组合键无需任何设置，真正做到了单手操作，堪比Windows的`Win+L`。 作者用略带调侃的语气批评了那些过度复杂化的回答，强调技术应当服务于效率。这篇短文提醒我们，在寻找技巧时，有时最简单的答案反而被忽视了。对于需要快速锁屏的Mac用户，记住这个快捷键组合就能解决问题，无需那些繁琐的教程。
彻底屏蔽优酷广告
这篇讲的是如何通过修改系统配置与Flash插件，彻底屏蔽优酷视频广告的“江湖秘笈”。 文章先回顾了经典的hosts屏蔽法被优酷用黑屏广告“反制”的历史，随后推出了一个更彻底的两步解决方案。第一步是基础操作，针对不同操作系统修改hosts文件，屏蔽广告服务器IP。文章的核心在于第二步：通过“欺骗Flash”来阻止黑屏。这需要用户找到浏览器Flash插件的本地存储目录（不同系统路径各异），删除名为“static.youku.com”的文件夹，并用一个同名的空文件取而代之，从而从根源上阻止了广告数据的加载。 整个方案思路清晰，实操性强，特别为Chrome用户在Linux、Mac和Windows系统上给出了详细的路径指引。虽然步骤稍显繁琐，但为希望获得纯净观影体验的用户提供了一个完整的“终极”技术路径。
设置ssh无密钥登录
这篇讲的是如何为Linux系统配置SSH无密钥登录，从而替代传统的密码验证方式。文章首先点明了SSH因RSA/DSA加密算法带来的安全性优势，这是其能取代telnet的关键背景。核心内容则聚焦于实操：通过ssh-keygen生成一对密钥，将公钥拷贝至远程机器的指定位置并设置正确权限（600），即可实现免密登录。 作者还特别指出，在完成基础配置后，用户可以进一步在sshd_config中关闭密码验证，将系统从基于密码的登录方式切换为更安全的密钥验证。整个过程步骤清晰，强调了权限设置这个容易出错的细节。对于需要频繁进行服务器管理运维的开发者和管理员来说，这套方法能有效提升工作效率与系统安全性。
linux 小技巧
这篇汇总了十个实用的Linux命令行与配置技巧，涵盖了日常运维中常见的安全加固、系统管理和故障预防场景。 文章内容非常具体，直接给出可操作的步骤。比如，它不仅告诉你用`pidof java`快速查进程号，还演示了如何修改`/etc/login.defs`来强制用户密码长度。在安全方面，技巧详细说明了怎样通过`/etc/pam.d/su`配置文件来限制`su`命令的使用权限，以及如何结合`/etc/hosts.allow`和`iptables`实现基于IP的SSH访问控制。 特别值得注意的是，文章包含了一些易被忽略但重要的配置，例如如何注释掉`inittab`文件中可能导致意外重启的`CTRL-ALT-DELETE`快捷键，以及为RedHat系统配置非正常关机后的自动磁盘检查。这些小技巧能有效提升系统的稳定性和安全性。对于经常与Linux服务器打交道的技术人员来说，这是一份可以随时查阅的实用备忘录。
数论的应用-RSA公钥算法
这篇讲的是RSA公钥算法背后的数学之美。作者从伟大的数学家欧拉切入，引出了现代非对称加密的基石——RSA算法。文章首先点明了对称加密的局限，随后介绍了1976年公钥密码思想的诞生，以及1977年RSA算法的正式提出。 核心部分，文章深入浅出地拆解了RSA所依赖的数论工具：欧拉函数用于计算与某数互质的数的个数，而欧拉定理（费马小定理的推广）则为算法的数学正确性提供了保证。随后，文章分步展示了RSA密钥生成与加解密的全过程：如何选取两个大素数p和q来构造模数n，并由此推导出公钥e和私钥d；以及如何用公钥加密、私钥解密。 为了让理论落地，文中还用了一个具体数字例子（M=52, p=17, q=11, e=7, d=23）演示了整个加密解密流程，让抽象公式变得清晰可感。最终，文章回归数学原理，简要说明了为何这样构造能实现解密的正确性。 整篇文章将深奥的数论概念与实际的密码学应用串联起来，展现了从纯理论到关键技术的奇妙旅程，让你理解为什么这个看似无用的数学分支，最终能成为守护互联网安全的隐形卫士。
Mcrypt响应慢的一个原因
作者遇到一个棘手问题：一个新上线的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`在极端情况下可能被预测，安全性在设计上有细微的取舍。这也提醒我们，在查阅官方文档时，下方的用户评论往往藏着解决实际“坑”的关键线索。
sshd+chrome+switchsharp翻墙
这篇讲的是如何在Linux系统下，通过SSH隧道结合Chrome浏览器的SwitchySharp插件，为团队成员快速搭建一条稳定的访问通道。作者从团队获得了一个付费SSH翻墙账号的背景出发，解决了此前免费账号质量不稳定、无法流畅访问Google、Twitter等网站的问题。 文章的核心方案分为三步。首先，利用`putty-tools`中的`plink`命令建立本地SOCKS代理，关键参数是`-D 127.0.0.1:7070`，并将其封装为可执行脚本`fan.sh`以便一键启动。其次，为Chrome浏览器安装代理切换插件`proxy-switchysharp`。最后，详细配置插件，设置代理类型为SOCKS5，并配置自动切换规则，例如通过正则`(google|facebook|twitter|youtube){1}`来区分哪些网址需要走代理。 完成上述配置后，只需运行脚本并启用SwitchySharp的“自动切换模式”，即可实现对目标站点的代理访问。整个过程清晰、可操作性强，为需要特定网络环境的开发者提供了一个轻量且有效的解决方案。
网址加密(URL加密)（RC4、PHP、密钥长度可变）
网址加密是一个常见需求，但作者发现网上很难找到现成的可用案例。他系统梳理了主流方案，指出Base64只是编码并非加密，且字符集不适合URL；自定义加密算法则违背了“安全寓于密钥”的现代密码学原则。 作者进一步对比了AES与RC4两种算法。AES虽然强大，但加密哪怕一个字节的结果也超过30字符，长度随输入增长过快，不适合加密长网址。而RC4在保证安全性和速度的同时，生成的密文长度要短得多，更适合URL场景。 最终，作者选择了RC4作为加密方案，并直接分享了PHP实现的完整类库与调用示例。他演示了如何通过密钥加密字符串并解密，让这份“缺失”的网址加密方案能直接用于实际项目。
网站密码存储方案比较
这篇讲的是在GPU算力飞速发展的今天，网站该如何安全地存储用户密码。作者对比了几种主流的不可逆加密方案。 传统的一次MD5或加盐的两次MD5方案，虽然使用广泛，但面对如今动辄超CPU数十倍算力的GPU集群，暴力破解已成可能，安全性堪忧。 文章重点分析了两种更安全的现代方案：PBKDF2和bcrypt。PBKDF2（如Django 1.4默认的实现）通过成千上万次迭代的HMAC-SHA256运算，大幅增加暴力破解的时间成本。bcrypt则在实现上更为简洁，但需注意它不支持超过55字符的密码。 作者指出，两者各有拥趸，没有绝对的优劣，选择取决于具体场景。文中提供了Django和PHP的PBKDF2实现代码，方便读者直接参考。对于正在构建用户系统的开发者来说，这是一份清晰实用的方案选型指南。
md5到md5破解的一些科普
这篇讲的是如何正确理解MD5这一经典哈希函数及其“被破解”事件。文章作者从MD5的多对一映射本质出发，解释了为何它是“不可逆”的，进而引出了密码学中关键的“碰撞”概念。 核心对比在于“无弱碰撞”与“无强碰撞”的区别。作者用生动的生日悖论说明，找到一对碰撞（强碰撞）的复杂度约为O(sqrt(m))，远低于遍历的O(m)，这为攻击提供了理论可能性。文章重点阐述了王小云教授的突破性贡献：她找到的算法能比生日攻击更快地构造出强碰撞，而非通过密文反推明文。这并不意味着MD5可以直接“解密”，而是破坏了它在验证文件完整性或数字签名时的可靠性基础。 后续提到的“预测大选”实验，正是利用了快速构造前缀碰撞的技术，以一种巧妙的方式展示了算法漏洞的实际应用。最终文章落脚于现实影响：尽管MD5在部分安全场景已弃用，但其漏洞提醒我们，从非官方渠道下载文件时，仅比对MD5值已不足以保证安全。
宽带网络运营商劫持网站的技术分析
这是一篇关于宽带运营商劫持用户网页流量的深度技术排查记录。作者从自家网络出现异常弹窗广告入手，发现无论访问大小网站，网页都会被远程注入 iframe，导致浏览器右下角弹出无关的 Flash 广告。 文章的核心在于技术分析过程。通过直接发送 HTTP 请求而非依赖浏览器缓存，作者捕获了被篡改的完整响应包，揭示了运营商如何用一个“空壳”页面加载原始网站并侧载第三方广告脚本。更进一步，作者通过 Whois 查询追踪到广告域名（istreamsche.com）指向北京集奥众和公司，并在联系客服时发现，连运营商自家技术人员的办公网络也未能幸免，将问题根源指向了上级运营商或高层决策。 面对这种普遍存在的“流量劫持”，文章给出了一个切实可行的用户端解决方案：通过浏览器插件（如 User Agent Switcher）清空或修改发送给网站的 User-Agent 标识。由于大部分网站不依赖此字段进行功能判断，该方法能有效绕过运营商的劫持规则，恢复干净的网页浏览。
跨越千年的RSA算法
作者从古希腊几何学中“可公度线段”的概念出发，讲述了数论中一系列精妙思想的演进。文章首先通过欧几里得求最大公度单位的直观例子，自然引出“辗转相除法”这一核心算法，并证明其效率。随后，以正方形边长与对角线不可公度的发现为例，揭示了无理数在古希腊时期就已出现的历史趣闻。 作者进而将话题转向数论中更深入的概念——互质与中国剩余定理。文中用生活中的公交车班次例子，生动解释了互质与最小公倍数的关系，并引出了《孙子算经》中的经典问题，展示了中国剩余定理的雏形与魅力。 这篇长文并非对教科书内容的简单复述，而是作者基于为《程序员》杂志撰写文章时积累的大量素材与个人思考，重新梳理的一条连贯知识脉络。他以牺牲部分严谨性为代价，力求用更直观、可读的方式，展现从古典数论走向现代公钥加密（如RSA算法）的奇妙旅程。
浅谈php web安全
这篇笔记从一位PHP开发者的实践出发，系统总结了Web安全开发中那些容易被忽略却至关重要的要点。作者强调，安全意识是开发者必备的素养，不能因项目内部或认为用户“善良”而放松警惕。 文章从基础的PHP安全配置讲起，比如关闭错误提示以避免信息泄露、禁用`register_globals`等危险功能。核心部分则深入数据验证，指出必须对用户输入进行严格校验，包括类型、长度和危险字符，并特别提醒了表单元素后端验证、字段名避免暴露等常见疏漏。 在防注入环节，作者详细演示了如何判断SQL注入漏洞，并列举了多种常见攻击手法，如万能密码、通过`union`语句猜解表结构等。针对防御，提供了从使用`intval()`处理数字参数，到结合`addslashes`等函数进行过滤的代码示例。此外，文章还简要涵盖了XSS、CSRF以及防盗链等其他常见Web攻击的防护思路。 整篇文章并非高深的理论，而是一份扎实的“避坑指南”，旨在帮助PHP开发者在编码阶段就植入安全基因，从根源上减少漏洞。
一个登陆认证系统
从代理项目《狂刃》的登录认证需求出发，作者描述了一个在时间压力下临时设计的简化认证协议。该协议基于HTTP，旨在为非Web应用在不安全信道上建立认证流程。核心设计包含游戏服务器（G）、认证平台（E）和客户端（C）三方交互：G生成一次性盐值（salt），C用用户密码对盐值进行加密签名后发送给E验证；E验证通过后，用相同算法生成发给G的认证令牌，最终由C转发给G完成双向确认。这种设计让G和E无需保持通信，只需预共享密码，降低了服务器状态管理的复杂度。 文章的重点落在实际部署中的一次“拍脑袋”引发的事故。合作方在未通知的情况下，使用作者用Lua快速编写的调试用认证服务器，对600人进行了压力测试。初期认证大面积失败，排查发现根因在于服务器的网络配置：该服务器配有电信和网通双线IP，而作者最初将服务绑定地址（bind address）默认设为127.0.0.1，合作方在部署时仅将其改为了服务器的其中一个IP，导致部分客户端无法连接。最终将绑定地址改为0.0.0.0才解决了问题。这个意外插曲揭示了一个常见陷阱：内部开发用的快速工具一旦被外部环境直接使用，其默认配置或简化实现可能成为隐形炸弹，即使核心逻辑（如作者后续补上的并发处理）经受住了压力，但外围配置的疏漏同样会导致生产事故。
国内团购网前端严重安全漏洞– 以满座网为案例分析
这篇讲的是作者以满座网为例，深入剖析了一个典型的前端安全漏洞。文章从日常技术排查出发，演示了如何利用浏览器开发工具（Firebug）和简单的jQuery命令，绕过团购页面对商品购买数量的前端限制。 作者发现，尽管网站前端代码设置了最多999件的购买上限，但这一限制仅存在于客户端。通过修改本地参数，理论上可以提交极大数量的订单。这个漏洞的根源在于“前端不信任后端，后端不信任前端”这一基本安全原则被忽视。仅依赖前端进行关键业务逻辑校验（如数量、价格），而缺乏后端的有效复核，为系统留下了风险。 案例的警示意义很直接：在Web 2.0时代，JavaScript和Ajax的便利不应以牺牲安全性为代价。对于涉及交易的系统，任何关键数据都必须在服务端进行严格校验。文章也借此提醒开发者，构建可靠的应用需要将安全成本纳入整体规划，不能心存侥幸。
一种抵御 DDoS 攻击的 IP 追踪技术
这篇文章来自作者2008年的一个备忘录，他决定将这个关于 DDoS 攻击防御的早期想法电子化。文章探讨了一个在 IP 协议基础上的扩展技术，即“差分确定性数据包标记”，旨在帮助服务器在遭受 DDoS 攻击时识别攻击流量并定位来源。 他提出的方案核心在于，让网络边缘的接入路由器对经过的数据包 IP 头进行标记。利用一个关键假设——正常流量源 IP 与路由器接口 IP 通常仅在末尾若干位不同，路由器可以仅标记这些不同的位，而不是冗长的完整路径信息。算法中甚至用上了 IP 头里闲置的 IDENTIFICATION 字段来承载这些标记。 这一改进带来了几个实际好处：大部分正常数据包仅需一个包就能完成回溯，极大减轻了路由器计算负担，同时也避免了正常 IP 分片受到标记操作的影响。 当然，作者自己也坦言，这个想法创新有限，且需要在运营商全网部署，工程实现难度极高，因此当年并未发表。但它清晰地展示了一个从实际网络假设出发、优化现有协议以解决特定安全问题的技术思考过程。
大佬与大话 之 阿里：绝不和360合作
这篇讲的是中国互联网史上一段颇有戏剧性的商业关系转折。作者从2006年阿里一封措辞激烈的公告切入——公告宣称旗下所有业务将“永远不和周鸿祎投资的公司合作”，起因是360安全卫士对阿里系产品“3721插件”的致命打击。然而五年后，淘宝却低调地与360展开了产品推广合作，让当年的“永远”二字显得有些尴尬。 文章没有止步于复述这段“打脸”历史，而是深入剖析了阿里态度转变背后的战略考量。作者排除了短期广告收入、交易安全需求等表面解释，将视角拉高到当时的电商竞争格局。他指出，随着腾讯以巨大的用户优势强势介入电商领域，阿里真正需要防范的是腾讯。而360恰好与腾讯交恶，拥有的浏览器和客户端流量不容小觑。 “敌人的敌人，可以争取成为朋友。”作者最终将阿里与360的破冰，比作中美建交初期的试探性合作。这个比喻精准地点明了商业世界中永恒的利益驱动：过去的恩怨在更大的战略威胁面前，往往需要被重新衡量。文章揭示了一个现实——在巨头博弈中，没有绝对的永恒盟友或敌人，只有不断变化的权衡与布局。
WordPress安全建议
这篇指南从WordPress高达50%的市场占有率出发，直接点明了一个现实：网站越受欢迎，越容易成为黑客的目标。它并非空谈理论，而是针对站长们普遍关心的安全问题，提供了一套从基础到进阶的实操建议。 核心方案围绕几个关键点展开：首先是加固访问入口，强烈建议摒弃默认的admin用户名，并搭配高强度随机密码。其次是保持系统更新与备份，强调每周检查版本更新，并使用插件或脚本定期备份数据库与文件，这是安全底线。 文章的重点在于推荐了几款实用的安全插件，如WordPress Firewall 2用于拦截常见攻击，BulletProof Security通过.htaccess强化防御，以及Better WP Security来隐藏常见漏洞。此外，它还提到了使用官方主题市场、配置CDN与SSL证书等辅助手段。 总的来说，文章汇集了一系列具体、可落地的安全配置方法和工具推荐。它清晰地传达了一个观点：虽然没有绝对的安全，但通过这一系列扎实的加固措施，能大幅度降低WordPress网站被入侵的风险。
anti spam杂谈
这篇讲的是邮件系统的垃圾过滤与论坛防灌水技术的内在联系。作者从一个比较有趣的角度切入，把这两个看似不同场景下的反垃圾实践放在一起对比讨论。 文章重点从技术层面展开，没有延伸到运营或法律等其他维度。你可以看到，邮件反垃圾主要依赖发件人信誉、内容特征（比如关键词、链接分析）和机器学习模型的动态学习，目标是在海量邮件中高精度识别并过滤垃圾邮件。而论坛防灌水更侧重于实时性，常用验证码、发帖频率限制、行为模式分析（比如短时间内重复发帖）等手段，更强调拦截的即时效果。 尽管目标一致（都是对抗垃圾信息），但两者在技术路径上各有侧重：邮件系统更注重长期、批量的模型准确率，而论坛则需要平衡用户体验与即时防护。这种对比能帮助读者理解，反垃圾策略如何根据不同的应用环境和攻击模式进行适配。