我应该使用 Sleep() 还是直接拒绝它们

发布于 2024-11-26 15:21:08 字数 346 浏览 1 评论 0原文

我正在实施一个延迟系统,以便任何我认为滥用的 IP 都会通过 Sleep() 自动获得增量延迟。

我的问题是,如果攻击者在延迟的情况下不断打开新实例,这是否会导致 CPU 使用率增加,从而杀死我的网站?或者 sleep() 命令使用最少的 CPU/内存,并且不会对小脚本造成太大负担。我不想断然否认他们,因为我宁愿他们不以明显的方式了解限制,但愿意听听我为什么应该这样做。

[请不要讨论为什么我认为小网站上的 IP 滥用,原因如下:我最近构建了一个脚本,cURL 是一个页面和一个页面。返回信息给用户,我注意到一些 IP 向我的愚蠢的小脚本发送垃圾邮件。过于频繁的卷曲有时会使我的结果无法从服务器即时轮询中获得,并且合法用户的结果会被欺骗。 ]

Im implementing a delay system so that any IP i deem abusive will automatically get an incremental delay via Sleep().

My question is, will this result in added CPU usage and thus kill my site anyways if the attacker just keeps opening new instances while being delayed? Or is the sleep() command use minimal CPU/memory and wont be much of a burden on a small script. I dont wish to flat out deny them as i'd rather they not know about the limit in an obvious way, but willing to hear why i should.

[ Please no discussion on why im deeming an IP abusive on a small site, cause heres why: I recently built a script that cURL's a page & returns information to the user and i noticed a few IP's spamming my stupid little script. cURLing too often sometimes renders my results unobtainable from the server im polling and legitimate users get screwed out of their results. ]

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

躲猫猫 2024-12-03 15:21:08

睡眠不使用任何尚未被接受调用的进程使用的 CPU 或内存。

实现 sleep() 时您将面临的问题是,当攻击者站点等待您的睡眠超时时,您最终将耗尽文件描述符,然后您的站点将出现在任何其他尝试连接的人面前。

这是一个典型的 DDoS 场景 - 攻击者实际上并没有尝试闯入您的计算机(他们也可能尝试这样做,但这是一个不同的故事),而是他们试图通过耗尽您拥有的所有资源来损害您的网站,可以是带宽、文件描述符、处理线程等——当您的其中一项资源用完时,您的网站似乎已关闭,尽管您的服务器实际上并未关闭。

这里唯一真正的防御措施是要么不接受呼叫,要么使用动态防火墙配置来过滤呼叫,或者使用路由器/防火墙盒来执行相同的操作,但远离服务器。

The sleep does not use any CPU or Memory which is not already used by the process accepting the call.

The problem you will face with implementing sleep() is that you will eventually run out of file descriptors while the attacker site around waiting for your sleep to time out, and then your site will appear to be down to any other people who tries to connect.

This is a classical DDoS scenario -- the attacker do not actually try to break into your machine (they may also try to do that, but that is a different storry) instead they are trying to harm your site by using up every resource you have, being either bandwidth, file descriptors, thread for processing etc. -- and when one of your resources are used up, then you site appears to be down although your server is not actually down.

The only real defense here is to either not accept the calls, or to have a dynamic firewall configuration which filters out calls -- or a router/firewall box which does the same but off your server.

又怨 2024-12-03 15:21:08

我认为这个问题是系统周围可能有大量休眠线程。如果您发现滥用行为,请立即发回错误并进行处理。

我对你的方法的担心是重复滥用者的超时时间长达几个小时。即使它们不使用 CPU,它们的线程也会保留很长时间。除了 CPU 之外,还有其他资源需要记住。

I think the issue with this would be that you could potentially have a LARGE number of sleeping threads laying around the system. If you detect your abuse, immediately send back an error and be done with it.

My worry with your method is repeat abusers that get their timeout up to several hours. You'll have their threads sticking around for a long time even though they aren't using the CPU. There are other resources to keep in mind besides just CPU.

最美不过初阳 2024-12-03 15:21:08

Sleep() 是一个在特定时间内“阻止”执行的函数。它不等于:

while (x<1000000);

因为这会导致 100% CPU 使用率。它只是将进程置于操作系统中的“阻塞”状态,然后在计时器到时后将进程恢复到“就绪”状态。

但请记住,PHP 的默认超时时间为 30 秒。我不确定“Sleep()”是否符合这一点(我会怀疑它,因为它是系统调用而不是脚本)

您的主机可能不喜欢您有这么多“阻止”进程,所以要小心。

编辑:根据 睡眠时间是否计入执行时间限制?< /a>,正如我所料,“Sleep()”似乎不受“最大执行时间”(在 Linux 下)的影响。显然在 Windows 下确实如此。

Sleep() is a function that "blocks" execution for a specific amount of time. It isn't the equivalent of:

while (x<1000000);

As that would cause 100% CPU usage. It simply puts the process into a "Blocked" state in the Operating System and then puts the process back into the "Ready" state after the timer is up.

Keep in mind, though, that PHP has a default of 30-second timeout. I'm not sure if "Sleep()" conforms to that or not (I would doubt it since its a system call instead of script)

Your host may not like you having so many "Blocked" processes, so be careful of that.

EDIT: According to Does sleep time count for execution time limit?, it would appear that "Sleep()" is not affected by "max execution time" (under Linux), as I expected. Apparently it does under Windows.

幽梦紫曦~ 2024-12-03 15:21:08

如果你正在做我也尝试过的事情,我想你就会摆脱困境。

我的身份验证脚本构建了类似于阿特伍德的禁止地狱的想法。 SessionID 被捕获在 RAM 中并在每次页面调用时轮换。如果不满足条件,我会对该特定会话进行记分标记。三点之后,我开始在它们的执行中添加 sleep() 调用。限制是可变的,但我选择了 3 秒作为一个满意的数字。

通过身份验证,攻击者依靠每秒执行一定次数的尝试来使其值得进行攻击。如果这是他们的焦点,那么引入睡眠会使系统看起来比实际速度慢,在我看来,这将使其不那么值得攻击。

如果你放慢他们的脚步,而不是直截了当地告诉他们“不”,那么你看起来不太有吸引力的机会就会稍微大一些。

话虽如此,它是通过某种“类型”的混淆实现的安全性,所以你不能太依赖它。这只是我整体食谱中的另一个因素:)

If you are doing what I also tried, I think you're going to be in the clear.

My authentication script built out something similar to Atwood's hellbanning idea. SessionIDs were captured in RAM and rotated on every page call. If conditions weren't met, I would flag that particular Session with a demerit. After three, I began adding sleep() calls to their executions. The limit was variable, but I settled on 3 seconds as a happy number.

With authentication, the attacker relies on performing a certain number of attempts per second to make it worth their while to attack. If this is their focal point, introducing sleep makes the system look slower than it really is, which in my opinion will make it less desirable to attack.

If you slow them down instead of flat out telling them no, you stand a slightly more reasonable chance of looking less attractive.

That being said, it is security through a "type" of obfuscation, so you can't really rely on it too terribly much. Its just another factor in my overall recipe :)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文