共 43 篇相关文章
这篇讲的是老牌安全厂商卡巴斯基的故事，以及它在中国市场从辉煌到落寞的历程。文章从卡巴斯基近期终于推出免费版切入，回溯了这家源自前苏联技术背景的公司，如何与擅长互联网玩法的奇虎360从合作走向分道扬镳。 核心冲突在于两种商业哲学的对决。一边是以“免费是互联网的基因”为信条的360，通过免费策略快速获取用户，构建了全新的流量变现模型；另一边是坚信“没有免费的杀毒软件”、固守付费软件模式的卡巴斯基。作者指出，卡巴斯基对“软件”而非“服务”与“数据”的执着，使其错失了互联网与移动互联网时代占据用户场景的关键窗口。 文章的一个精彩论断是：**“固执和执着很多时候并不能完全地区隔，很多时候对于胜利者而言可以被称作执着，但对于失败者而言大多则被看作是固执。”** 这不仅是对卡巴斯基商业策略的点评，也引发了关于技术理想主义与市场生存法则的思考。对于技术从业者而言，它揭示了在技术变革期，选择哪种“企业基因”去适应趋势，有时比单纯的技术优劣更能决定命运。
这篇讲的是，作者从一次偶然发现入手，探究了WiFi万能钥匙这类软件背后令人不安的运作逻辑与潜在风险。 他发现，即便自己从未主动使用，手机的WiFi列表也可能被软件打上“一键免费连接”的提示。分析指出，软件的核心在于一个庞大的云端数据库，它通过获取用户设备上保存的明文或弱加密密码，将每个用户的1-10个WiFi信息（如MAC地址、密码）上传汇总。凭借数亿用户，这个数据库的规模相当惊人。 连接时，软件会申请位置权限，以缓存附近WiFi信息并可能用于广告投放。它主要通过三种方式尝试联网：利用更精准的MAC地址进行密码匹配、对弱口令（如常见数字组合）进行撞库，以及可能在后台静默尝试暴力破解。 文章强调，真正的隐患不止于网速变慢。一旦网络被具备技术能力的攻击者蹭上，他们可能进一步尝试破解路由器管理密码，从而在同一局域网内实施欺骗、投毒等控制手段。作者最后给出了一些实用建议，如为访客单独设置受限的WiFi子网络，或隐藏SSID广播，来防范这种“无感知”的蹭网行为。
这篇讲的是Linux系统面临的经典网络层攻击——SYN Flood。文章直接切入TCP协议固有的缺陷，解释了攻击者如何利用伪造的SYN包耗尽服务器的连接队列，从而瘫痪正常服务。理解了原理后，关键在于防御。文章没有停留在理论，而是给出了四种可立即操作的系统调优方案：通过调整`tcp_synack_retries`等参数减少无效等待，启用强大的SYN Cookie机制来抵御伪造包，适当扩大半连接队列容量，以及用iptables规则对异常流量进行限速。每条措施都附带了具体的`sysctl`或`iptables`命令，从内核参数到防火墙规则，覆盖了从缓解到防御的多层次思路。对于需要加固服务器网络安全的运维人员，这些直接可用的配置点很有参考价值。
你可能遇到过这样的怪事：输入正确的网址却跳到运营商广告页，或者明明翻了墙某些网站依然打不开。这些问题的共同根源往往是网络层面的DNS干扰。这篇技术讲解就厘清了其中两种最常见、但原理不同的手段：DNS劫持与DNS污染。 文章的核心在于对比。DNS劫持，可以理解为“结果被篡改”。它发生在DNS服务器层面，攻击者或运营商控制了服务器，直接修改了域名对应的IP地址。你的查询请求是真实的，但收到的回复是假的，导致你被引导到错误的网站。其典型症状是首次拨号上网时总会弹出运营商的门户页面。 而DNS污染，更像“过程被污染”。它利用DNS查询基于不可靠UDP协议的特点，在数据传输的途中进行拦截和伪装。当你的查询请求途经被监控的节点时，系统会提前伪造一个虚假的IP地址返回给你，根本无需你的请求到达真正的DNS服务器。这通常用于实现对特定境外网站的封锁。 因此，它们的应对策略也不同。对于DNS劫持，修改本地DNS服务器地址为公共DNS（如文章中列举的阿里DNS、114DNS等）是直接有效的解决方法。但对于工作在传输层的DNS污染，单纯更换DNS往往无效，通常需要借助VPN或远程解析等更复杂的方式。 文章不仅讲清了原理，还给出了从选择公共DNS到Windows系统下手动修改的完整操作指南，是一篇从现象认知到动手解决都很完整的实用科普。
这篇讲的是DDoS攻击的完整图景——从基础概念到实战工具。作者从“拒绝服务”和“分布式”这两个核心点出发，解释了攻击如何演变成依靠“僵尸网络”进行的协同作战。文章梳理了DDoS的发展史：早期只是黑客的炫技游戏，后来被宗教和商业组织用于勒索与报复，最终甚至成为国家级网络战争的武器，其中中国和美国是受灾最严重的地区。 在技术层面，文章将攻击方式归纳为四类：耗尽网络带宽的流量洪水、针对TCP连接表的SYN洪水、专门攻击DNS和Web服务的应用层攻击，以及混合多种手段的综合性攻击。特别提到随着僵尸网络小型化，慢速应用层攻击正成为新的趋势。文章还介绍了几款知名的开源工具，比如曾被广泛使用的低轨道离子炮（LOIC）和专门产生HTTP流量的HULK，让读者直观了解攻击的实现手段。 整体而言，这篇文章不仅解释了DDoS“是什么”，更通过攻击工具和态势分析展现了“如何发生”，对于理解当前网络空间中的流量型威胁提供了清晰的框架。
这篇讲的是HTTPS，但不是泛泛而谈。作者从iOS开发者普遍对安全不够重视的现状出发，指出即便是未越狱设备，网络安全依然是不可回避的课题。文章的核心，是厘清HTTPS并非什么新协议，其本质只是在HTTP之下增加了一层SSL/TLS加密。 最硬核的部分在于对SSL/TLS原理的拆解：它通过四次握手交换三个随机数来生成安全的“对话密钥”，并依赖数字证书体系（PKI）进行身份验证。文章用清晰的逻辑讲透了证书的签发与验证流程——接收端如何通过哈希对比和递归验证，最终追溯到操作系统内置的根CA。这解释了“为什么信任链的起点如此重要”。 在实现层面，文章没停留在理论。它具体展示了如何在iOS的NSURLConnection中处理证书验证回调，利用Security Framework的API完成Trust Object的评估。无论是使用系统默认验证，还是为自建证书等高安全场景进行更严格的本地匹配校验，都给出了可落地的代码思路。对于想用AFNetworking简化流程的开发者，也有明确的指引。 从概念辨析到原理图解，再到代码级实践，这篇文章提供了一条清晰的路径，帮助开发者完成从HTTP到HTTPS的安全升级。
这篇文章系统地梳理了SSL证书的六大分类，从最基础的DV域名型证书到企业级的OV、EV增强型证书，再到功能扩展的通配符、多域名及强制加密证书。它清晰地对比了各类证书在验证严格程度、包含信息、颁发周期和价格成本上的核心差异。例如，DV证书仅验证域名所有权，一两小时内即可签发，适合个人或中小网站快速启用加密；而OV和EV证书则需严格的企业身份审查，其中EV证书还会在浏览器地址栏直接显示公司名称，为金融机构等高要求场景提供最高级别的信任标识。对于拥有多个子域名或不同顶级域名的企业，通配符证书和多域名证书则分别提供了“一张证书保护所有子站”和“统一管理多个域名”的高效解决方案。文章不仅解释了技术定义，更通过适用对象的罗列，让读者能根据自身网站的性质、规模和安全需求，快速定位到最合适的证书类型，具有很强的实操参考价值。
这篇讲的是如何通过修改 MAC 地址来应对特定的网络管理策略。作者从学校环境下下载资源时，IP 乃至物理网卡 MAC 地址被封禁的常见困境出发，引出了解决这一问题的核心方法：使用一行命令临时更换 Mac 的 Wi-Fi 接口 MAC 地址。文中具体介绍了通过 `ifconfig` 与 `openssl` 命令随机生成并应用新地址的操作，同时点明了苹果在 iOS 8 上引入 MAC 地址随机化功能，用于在公共 Wi-Fi 环境下保护用户隐私的背景。 该方案的巧妙之处在于其极简性与临时性——一行命令即可生效，且无需复杂设置；由于未写入启动项，系统重启后便自动恢复真实地址，这既满足了临时绕过限制的需求，也保证了系统日常使用的纯净与稳定。对于需要在外使用公共网络的用户，作者也顺带提醒了搭配 VPN 的安全建议。
这篇文章讲的是2014年1月21日中国互联网大规模DNS瘫痪事件的技术剖析。作者从一个普通用户的视角出发，描述了当时所有网站都打不开的异常现象，并以通俗的“电话本”比喻，解释了DNS作为互联网基础设施的核心作用。 作者详细梳理了从用户输入网址到获得IP地址的正常DNS解析流程，并与当天故障时的实际流程进行对比：所有查询都直接返回了同一个错误IP（65.49.2.178），跳过了正常的层层解析步骤。通过分析，作者排除了全球根域名服务器自身出错的可能，将原因锁定在“DNS劫持”上——即有人伪造了根服务器的响应。 文章进一步通过追踪那个错误IP的历史关联信息，发现其与特定组织及“无界浏览器”等翻墙工具存在关联，并指出这种大规模、快速的劫持手法与GFW（防火长城）的运作机制高度一致，从而提出了事件可能由某墙导致的观点。整个分析过程层层递进，从现象描述到技术原理拆解，再到幕后推断，为读者提供了一次生动的网络故障排查案例。
这篇讲的是如何通过自建本地DNS服务器，来规避GFW对DNS查询的干扰，从而恢复部分网站的访问。文章首先解释了问题根源：GFW会拦截并污染常见的UDP协议DNS请求，导致解析结果错误。而一个有效的对策是利用TCP协议的DNS查询，因为它目前不易被干扰。 作者推荐的具体方案是，使用开源软件Unbound在本地搭建一个DNS服务器。该服务器监听本地，接收程序发出的UDP请求，并将其转换为TCP查询转发给上游公共DNS（如8.8.8.8），从而绕过污染。文章给出了在Windows系统上的详细配置步骤，包括安装、修改配置文件、重启服务，并最终将系统DNS指向本地127.0.0.1，操作性很强。 对于更进一步的安全需求，文章末尾还提到了一个升级思路：可以结合SSL加密，在境外服务器上部署Unbound作为上游，实现查询流量的端到端加密，提供了更彻底的解决方案。
这篇文章从360这家争议不断但产品屡屡成功的公司切入，分享了三个值得琢磨的产品思维。 第一，用户骂你，往往是对的。作者指出，用户即使对最简单的设置抱怨，也揭示了真实需求，而不是他们“智商有问题”。产品人的傲慢往往会掩盖真正的用户痛点。 第二，创新不止于发明，改进体验也是质变。文章以360和苹果为例，说明他们可能没有开创品类，但通过优化实用性赢得了用户。这种“实用性创新”是很多成功产品的共同特质。 第三，理解弱需求背后的强动机。很多时候用户明知不对仍会这么做，关键不是说教，而是设计更有效的方式来引导行为。这比单纯指出问题更考验产品设计。 虽然360这家公司本身争议不断，但文章提炼出的这些方法论——倾听抱怨、聚焦体验改进、洞察行为动机——确实点中了产品设计的一些要害。对于产品经理和开发者来说，这些来自实战的观察，比纯粹的理论更有嚼头。
这篇从马云关于互联网管制的言论切入，用数据梳理了中国互联网在“保护”下的真实处境。作者调出2006年的Alexa全球前十网站列表，其中中国网站占四席；而到了2013年，这一数字减至三家，且百度等头部站点的排名略有下滑。更关键的是，在这段时期里，海外榜单迅速纳入了Facebook、YouTube等新巨头，国内的新鲜血液却相对稀缺。 文章的核心观点是：GFW在屏蔽外部竞争、为国内企业提供“安全”发展环境的同时，也深刻塑造了中国互联网的基因。由于政治表达空间有限，大量的用户注意力和资本涌向了娱乐与情绪宣泄领域，而非深度信息获取。这导致中国互联网可能正走向一条“娱乐化”的道路，与更偏向信息与思考的美国互联网形成差异。作者将这称为一种“中国特色”，并预见其速度可能会因资本催化而加快。 这不仅仅是一次对政策与技术墙的讨论，更是对一个产业生态如何被无形力量重塑的观察。它提醒我们，任何技术干预都具有双面性，在获得短期庇护与独特发展模式的同时，也可能在某种程度上限定了长远的可能性和想象空间。
这篇讲解SSH基础知识的文章，从“什么是SSH”直接切入，梳理了这项安全协议从诞生到普及的简要历程，重点则落在了实际操作与安全原理上。 文章系统梳理了SSH的核心用法：从最基础的远程登录命令，到端口参数修改。它详细拆解了SSH保障安全的关键——公钥加密验证流程，并分别阐述了两种登录方式：“口令登录”与“公钥登录”。对于后者，文章不仅解释了免密原理，还一步步指导读者如何生成密钥对、使用`ssh-copy-id`上传公钥，以及如何排查服务端配置问题。 特别值得注意的是，文中对公钥指纹验证、`known_hosts`文件的作用，以及`authorized_keys`文件的具体操作都有细致说明。这些细节对于理解SSH建立信任链的过程至关重要，也为实际配置提供了清晰路线图。对于需要安全远程管理的开发者或运维人员，这是一篇扎实的入门指南。
这篇讲的是如何在Erlang的TCP服务器（基于gen_tcp）中，从底层实现上来限制单个数据包的大小，以防范潜在的安全风险和资源耗尽问题。 文章从两种包接收模式入手。对于同步接收（{active, false}），作者指出，当使用gen_tcp:recv时，实际上内核会为接收分配一个缓冲区。通过源码可以看到，这个缓冲区大小存在一个硬编码的上限：TCP_MAX_PACKET_SIZE（64MB），一旦请求超过此限制，就会直接返回ENOMEM错误。这可以看作是系统级的防线。 而对于更常见的异步消息投递（{active, true}），控制则发生在协议解析层面。通过inet:setopts设置的packet_size选项，会在数据解析时被检查。文章通过追踪tcp_remain等函数的源码揭示了这一机制：当解析器发现包头声明的长度超过了设定的psize值，这个数据包就会被判定为无效。 核心巧妙之处在于，这两种机制一个在缓冲区分配时卡住，一个在协议解析时拦截，共同构成了对包大小的纵深防御。文章通过解读底层C驱动代码，让读者清晰地看到这些看似简单的应用层选项是如何被严格实现的，对于需要定制或深入理解Erlang网络编程的开发者来说，提供了扎实的内部视角。
这篇讲的是作者——一位前阿里安全专家，受邀参加腾讯安全中心的一次闭门沙龙后的思考。文章从个人体验出发，回顾了腾讯长期低调却坚定的安全投入，比如早在“3Q大战”前，其安全负责人就提出“安全是保持竞争力的门槛”，且安全团队的声音能直达CTO张志东这样的最高层。 作者着重分析了腾讯TSRC（腾讯安全响应中心）的活跃运作：通过给报告漏洞的白帽子发放可观奖励，已吸引数百人参与。他进而指出，腾讯、阿里等公司正在有意识地搭建“漏洞提交-奖励”平台，这可能在未来几年改变行业格局——让白帽子能靠挖洞合法养活自己，从而减少漏洞流入黑产，促进安全行业繁荣。文章最后以个人感慨收尾，带着对行业未来的期待。
这篇报道揭秘了号称“地下黑客世界王者”的匿名人物V的惊人能力与行为准则。他个人掌控着包括运营商内部系统、基础设施服务、大量互联网行业在内的权限，并积累了高达13亿条的去重用户数据，实现了“大数据式黑站”。V曾长期监控一个女孩的全部网络活动，研究保安行为，甚至能定位手机、伪造短信、定向推送信息，其能力已如电影场景。 然而，V恪守古老黑客守则：不破坏、不牟利、保持观察。文章通过具体事例（如他用弱口令数据库查询、控制微博大号等）揭示了顶级黑客对现代网络体系构成的潜在威胁，以及他们可能拥有的巨大舆论影响力。作者最终借V之口传递一个核心观点：真正的强大黑客应致力于让社会听到真实的声音，而非作恶。在绝对的技术能力面前，道德成为唯一的约束。
这篇讲的是如何通过修改系统配置与Flash插件，彻底屏蔽优酷视频广告的“江湖秘笈”。 文章先回顾了经典的hosts屏蔽法被优酷用黑屏广告“反制”的历史，随后推出了一个更彻底的两步解决方案。第一步是基础操作，针对不同操作系统修改hosts文件，屏蔽广告服务器IP。文章的核心在于第二步：通过“欺骗Flash”来阻止黑屏。这需要用户找到浏览器Flash插件的本地存储目录（不同系统路径各异），删除名为“static.youku.com”的文件夹，并用一个同名的空文件取而代之，从而从根源上阻止了广告数据的加载。 整个方案思路清晰，实操性强，特别为Chrome用户在Linux、Mac和Windows系统上给出了详细的路径指引。虽然步骤稍显繁琐，但为希望获得纯净观影体验的用户提供了一个完整的“终极”技术路径。
这篇文章来自作者2008年的一个备忘录，他决定将这个关于 DDoS 攻击防御的早期想法电子化。文章探讨了一个在 IP 协议基础上的扩展技术，即“差分确定性数据包标记”，旨在帮助服务器在遭受 DDoS 攻击时识别攻击流量并定位来源。 他提出的方案核心在于，让网络边缘的接入路由器对经过的数据包 IP 头进行标记。利用一个关键假设——正常流量源 IP 与路由器接口 IP 通常仅在末尾若干位不同，路由器可以仅标记这些不同的位，而不是冗长的完整路径信息。算法中甚至用上了 IP 头里闲置的 IDENTIFICATION 字段来承载这些标记。 这一改进带来了几个实际好处：大部分正常数据包仅需一个包就能完成回溯，极大减轻了路由器计算负担，同时也避免了正常 IP 分片受到标记操作的影响。 当然，作者自己也坦言，这个想法创新有限，且需要在运营商全网部署，工程实现难度极高，因此当年并未发表。但它清晰地展示了一个从实际网络假设出发、优化现有协议以解决特定安全问题的技术思考过程。
这篇讲的是中国互联网史上一段颇有戏剧性的商业关系转折。作者从2006年阿里一封措辞激烈的公告切入——公告宣称旗下所有业务将“永远不和周鸿祎投资的公司合作”，起因是360安全卫士对阿里系产品“3721插件”的致命打击。然而五年后，淘宝却低调地与360展开了产品推广合作，让当年的“永远”二字显得有些尴尬。 文章没有止步于复述这段“打脸”历史，而是深入剖析了阿里态度转变背后的战略考量。作者排除了短期广告收入、交易安全需求等表面解释，将视角拉高到当时的电商竞争格局。他指出，随着腾讯以巨大的用户优势强势介入电商领域，阿里真正需要防范的是腾讯。而360恰好与腾讯交恶，拥有的浏览器和客户端流量不容小觑。 “敌人的敌人，可以争取成为朋友。”作者最终将阿里与360的破冰，比作中美建交初期的试探性合作。这个比喻精准地点明了商业世界中永恒的利益驱动：过去的恩怨在更大的战略威胁面前，往往需要被重新衡量。文章揭示了一个现实——在巨头博弈中，没有绝对的永恒盟友或敌人，只有不断变化的权衡与布局。
这篇讲的是周鸿祎在科技行业中的经典战役——3Q大战。作者从360与腾讯的激烈竞争出发，详细回顾了这场引发全网关注的软件冲突。事件背景是2010年，360推出隐私保护器指控腾讯QQ窥探用户隐私，腾讯则强制用户卸载360软件，导致用户电脑出现兼容性问题，甚至蓝屏死机，数亿用户被迫在两者间二选一。 文章核心观点指出，周鸿祎以“用户利益”为旗帜，巧妙利用舆论战，将技术竞争转化为公众事件。他通过社交媒体和媒体采访，不断放大腾讯的“垄断”行为，最终迫使腾讯在工信部的介入下妥协，双方恢复兼容。作者分析发现，这场战争不仅是产品之争，更是商业模式和用户心智的较量：360
