这是一个关于JS Bin的故事。我以前讲过 JS Bin 的一个故事，这是 b 面：阴暗面。但请记住我与您分享的所有内容，JS Bin 是运行时间最长的实时 pastebin，而且它哪儿也去不了。它将继续运行并为其用户提供服务。哪怕是渣男。
这个故事分为 5 个部分，在连续几天内发布。
- 第 1 部分：DDoS 的开始
- 第 2 部分：垃圾邮件
- 第 3 部分：注册用户肆虐
- 第 4 部分：成本
- 第 5 部分：警察
背景故事
我主要在布莱顿的卧室外工作（因为我们的公寓很小），同时仍在伦敦与其他设计师和开发人员一起全职工作。 jQuery 还是个新东西，我经常被书面英语问到为什么有些代码不起作用（解释通常缺少 实际 代码！）。
我知道我需要一些包含代码的东西，它可以将问题减少到最小的形式，这样我就可以进行调查。
JS Bin 于 2008 年 9 月 推出，作为我需要查看带有交互式组件的 pastebin 的解决方案。
它被发布在 Ajaxian 上并获得了良好的反响。我还开始通过回答 Stack Overflow 问题和链接到 JS Bin 中的现场演示来播种它。时至今日，这种方法取得了巨大的成功——尤其是当 Stack Overflow 继续创建他们自己的实时 pastebin 支持时（尽管恕我直言，它看起来像是一个糟糕的 jsfiddle 实现）。
第一天的概念很简单：您可以匿名创建一个网页供任何人查看和编辑（创建一个新的“快照”）。
最初使用 2 个 PHP 文件（ sandbox.php 和 index.php ）和一个非常简单的 MySQL 数据库进行大约 4 小时的破解。随着时间的推移，它会变得更加复杂，具有更多的功能——大部分隐藏在一个非常时尚的设计中（ 丹尼霍普 ）。
多年来，JS Bin 不断成长。我经历了几次重大重写，现在选择了基于 AWS 架构的 Node 作为后端（尽管仍然是 MySQL）。
不知何故，JS Bin 是第一个遭受真正虐待的人，但我知道 jsfiddle 近年来受到了相当大的抨击。我不确定 CodePen 是否真的有很多，如果有任何滥用（ 可能 是因为它是街区的新手）。
这是一个故事，而不是一个快乐的故事，讲述了一些试验和磨难，这些试验和磨难让我的小开源项目口中有毒。
还请记住，在这些故事中，我是唯一的系统管理员，我的知识虽然可行，但却是有限的——就像我口袋里的硬币一样，所以 没有 负载平衡器和重型哨兵机器来保护我的系统免受攻击疯狂。这 只是 我。
第 1 部分：DDoS 的开始
我不记得在此之前我是否看到过任何关于 JS Bin 的滥用，但在 2012 年 4 月下旬，我收到一封电子邮件，要求我注意：
当时我正在出差并举办研讨会，垃圾箱删除是一项手动工作，但我尽快调查并删除了垃圾箱（今天它解析为 404）。
bin 是 脚本小子的 天堂：输入目标的 URL，它会重复创建对目标的图像请求。事实上，这种页面多年来是很多事件的根源。
困扰我的事情是： 为什么他们把这个托管在 JS Bin 上？他们必须共享一个链接，为什么不共享一个 HTML 文件呢？
这意味着 JS Bin 不会被夹在中间。 ¯\ (ツ) /¯
另一种 DDoS：愚蠢的自我攻击
谢天谢地，自攻是在 JS Bin 转移到 Node 之后 发生的，否则我不确定它是否能存活下来。
但事实上，JS Bin 在这些攻击中并不总是保持冷静。 自我攻击？ 是的。这是脚本小子页面请求 URL 的时候，但该页面没有对 URL 进行任何验证，并且由于需要很少的脑细胞来策划攻击，一些白痴会省略前面的“http:/ /”参与他们的攻击。
结果？他们开始附加像 http://jsbin.com/abcef/some-site-the-user-hates.com 这样的 URL——它实际上确实通过了 JS Bin 的子系统。
有时，并非总是如此，但有时会导致这种情况，那就是它变得非常毛茸茸的时候......
“总是在他们睡觉的时候罢工……”
好吧，所以这可能不是什么秘密咒语，即屁股帽子总是在系统管理员睡觉时进行攻击，实际上可能是因为我住在英国，所以大多数攻击都发生在中美洲中午时间......所以是的，我在睡觉，然后醒来（早上 6 点左右）在 Twitter 上看到 JS Bin 无法访问的报告。
当大多数对您投入灵魂的产品的@replies 是：狗屎已经击中粉丝时，这真是令人沮丧！
当有无穷无尽的狗屎供应时
我实际上有一本关于何时发生这种情况的 操作手册 。当 JS Bin 受到猛烈攻击时，无论攻击是什么样子。大多数情况下，解决方案是重启 JS Bin。但是，它也往往来自一些特定的 IP 地址。
当 JS Bin 机器上的 CPU 运行过高（持续数秒）时，我也会收到 AWS CloudWatch 警报。针对节点进程（是的......单个进程）的持续命中流量导致进程不断“忙碌”，即高 CPU 率，所以我 收到 警报。
因此，Runbook 将扫描访问日志的最新 200 行（左右），并吐出唯一 IP 及其命中数。从那里开始，将对地址进行
iptable
处理（即阻止 IP 地址）。
一天晚上变得 如此糟糕 ，以至于我不得不在 cronjob 中编写一个脚本，该脚本会反复扫描日志以查找任何命中 JS Bin 的 IP，而不是某个任意数字，并且它会禁止它们。
它确实解决了这个问题。它还随机屏蔽了很多很多热衷于通过 Twitter 和 GitHub 问题让我知道的普通用户（这是一件好事，我不是在抱怨 - 只是让他们陷入交火中很糟糕） .
fail2ban
最终我开始使用 fail2ban 来保护我的机器免受来自特定 IP 地址的重复攻击。自从 2014 年底左右安装以来，它大大减少了这种性质的攻击。
不幸的副作用是它也阻止了 JS Bin 的课堂使用，因为 JS Bin 一直 发送 XHR 写入，fail2ban 看到这一切都来自单个 IP，并继续阻止渴望的年轻班级学习。
在这种情况下，班级可以通过任何可能的渠道取得联系，我已经手动将他们的 IP 地址列入白名单。我知道这让一些人出局了，但遗憾的是，这是我不得不付出的代价。
无效的
我添加到 JS Bin 的另一个技巧是，输出呈现到的 iframe 被强制解析为
http://null.jsbin.com
，这反过来返回
204
（这是通过注入
base
标记完成的进入预览）。
这个微小的变化也减少了大量的请求，特别是当用户将占位符图像放入他们的容器中时，容器会在每次按键时自动重新呈现。预览可能会加载 10 张空白图像，但“空白”实际上意味着它没有来源，这意味着它正在命中 JS Bin。
现在，输出简单地解析为 null.jsbin.com，使用 nginx 响应并且从不触及 JS Bin。
回来看第 2 部分：处理各种形式的垃圾邮件的尝试！
