TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Discouraging the use of web application firewalls

231 点作者 b8超过 1 年前

42 条评论

theideaofcoffee超过 1 年前
People will stop deploying WAFs when the compliance standards are rewritten to not require them. They are prominent in lots of installations because the box ticking exercise of compliance frameworks, namely PCI or HIPAA, require a WAF-like component to reach compliance. It took long enough for them to be written in that now everyone knows they need one. It will be even longer for them to be phased out, and no one with risk assessors wants to be the first to remove them. Too much risk they say, regardless of how strenuously the tech component say they're unneeded.
评论 #38255318 未加载
评论 #38255357 未加载
评论 #38255400 未加载
评论 #38257152 未加载
parl_match超过 1 年前
A few counters to this:<p>First off, most large applications need something on the edge to help deal with volumetric attacks. If you&#x27;ve already got something there, adding a light WAF engine isn&#x27;t exactly a huge ask. It&#x27;s (almost) free.<p>Also, WAFs let you &quot;fast patch&quot; against vulnerabilities. The Log4j example the author gives as a negative is actually a positive. Your vendor can help prevent you from being attacked while you have time to respond. Those rules given in the example are bad, for sure, and probably have false positives - but, a few days of a slightly higher rate of false positives while you patch is probably worth it to most organizations.<p>Lastly, WAFs let you increase &quot;risk scores&quot; of requests and IPs, which lets you turn up captchas and other roadblocks against malicious IPs. This raises the bar from the floor to somewhere about knee height. Not a lot, but one more thing for an attacker to have to step over.<p>I do agree, though, that people treat WAFs as a magic solution or make them really heavy. Against application attacks, I view them as a tool of medium importance. Also, there are also better and worse vendors out there. Personally, in a WAF, I view &quot;less as more&quot;.<p>The more rules and complexity, the more problems you&#x27;re going to have. Adding rules should be temporary, and there&#x27;s very few reasons to have blocking rulesets for long running issues.
评论 #38256476 未加载
评论 #38270249 未加载
sbarre超过 1 年前
Most large companies have too many developers and too many teams to expect&#x2F;assume that each team will do the right thing for security when putting something in production on the public Internet.<p>Why? Because most software developers are bad at security (I said <i>most</i> not all).<p>So yes do all the things at the bottom of this article! Teach security-by-design to all your teams. Make sure they know what OWASP is at least. Make sure you test all the things. Either own or rent red teams.<p>But if you&#x27;re a big enough company, you probably <i>also</i> need something centralized like a WAF, because you want defense in depth.<p>WAFs are far from perfect, but in my experience they are better than not having one in 2023.
评论 #38256141 未加载
joshchaney超过 1 年前
I think WAF is really a bigger set of tools now (bot protection, IP reputation, L7 DDoS&#x2F;rate limiting, API restrictions) than just signatures. Virtual patching is also incredibly important and there&#x27;s really no other security tool that gives you the granularity to restrict something like the values of some param on a specific path of your app, but only when some cookie exists.<p>I don&#x27;t think the performance concerns here are accurate. I think these days most people are using vendors own cloud infra (Akamai, Cloudflare, F5, Imperva, etc), but even if you are using WAF on-prem, F5 and Imperva sell purpose built hardware that have no problem handling tons of requests. Most WAF&#x27;s also have weighted signatures these days and won&#x27;t just fire on ${jndi. &quot;${jndi&quot; might give 5pts, while &quot;org.apache.*&quot; gives another 5, and maybe their threshold is set for 10 for blocking.<p>I have plenty of issues with WAF&#x27;s and I would invest a lot more in developer training, but I think they still have their place.
hn_throwaway_99超过 1 年前
Hallelujah. Also, with many single-phase apps, WAFs don&#x27;t make any sense - the HTML&#x2F;CSS content is just served statically, so the potential vulnerabilities are in the API, which IMO is much easier to harden. Without going into too much of a tangent, this is one reason I&#x27;m a big fan of GraphQL. It&#x27;s strong typing and support for custom scalar types means malformed content gets rejected before it even gets to your code. For example, most injection attacks require the use of some &quot;special&quot; characters like &lt; or ;, but many field types have no need to support those characters, so instead of just typing &quot;strings&quot; everywhere, you can have things like Email or Date or SSN or Name scalar types that are more restrictive in the characters they allow.
评论 #38255353 未加载
评论 #38256954 未加载
评论 #38256298 未加载
allanrbo超过 1 年前
I think of WAFs as an extra safety net. Defense in depth.<p>The author complained about the performance cost of WAFs in general, but not all WAFs have be structured like ModSecurity. They could for example be based on something like <a href="https:&#x2F;&#x2F;github.com&#x2F;intel&#x2F;hyperscan">https:&#x2F;&#x2F;github.com&#x2F;intel&#x2F;hyperscan</a> and perf is at a very different level.
评论 #38256391 未加载
评论 #38257526 未加载
RajT88超过 1 年前
I cannot argue with this too much. A WAF will protect you from unsophisticated attackers - at great cost.<p>In my group, I am considered to be the WAF SME. Enough that I wrote a training course to get into ruleset tuning.<p>What I see a lot is customers who are security-focused demanding &quot;OWASP Top 10&quot; protection and then, somehow, not understanding that it is not 10 rules you enable on the WAF. These are people often with application security and other credentials.<p>Most people I have seen running WAF&#x27;s are in &quot;Set it and forget it&quot; mode. Tune the rules until it no longer blocks legitimate traffic and call it a day. I think few really understand what it is, and the why of using them.<p>Another funny anecdote: I had one of these customers talk about how amazing Akamai WAF was, because it never had false positives. Never? Really? That looks like a red flag to me, but they were not concerned.
评论 #38263207 未加载
throwawaaarrgh超过 1 年前
Show me an alternative that I can deploy despite developers having both the lack of knowledge and complete indifference of security. They don&#x27;t care and they aren&#x27;t forced to conform to any security standards, so a WAF is literally the only thing I can do to try to improve things. I can&#x27;t rewrite all their code for them. Management hears about a WAF and makes that a requirement and moves on.<p>If software development was a professional trade group, we could make membership require security training, and industry standards for ensuring security. But that&#x27;ll never happen. It would mean them giving themselves more work to do, and we all know how lazy devs are.
评论 #38256354 未加载
ppierald超过 1 年前
A few points.<p>PCI-DSS does not mandate the use of a WAF. It is one of two ways you can fulfill requirement 6.5 or 6.6. WAF + OWASP Top Ten ruleset is typically easier to get evidence for your auditor, but you can show that continuous scanning using a DAST scanning engine to meet requirements.<p>I would have a WAF installed with very few highly tuned rules against mostly SQLi. Why? Because the damage of letting that through and praying that the developer or web-app framework does it right are significant. The rules for SQLi are pretty easy to get right and dropping that traffic before it gets to your web server is a reasonable thing.<p>I would have a WAF installed with no rules too. It is nice to have something there where you can drop in a Log4J rule and get protection relatively quickly for attacks of that nature. There have been a number of these over the years and a small performance penalty seems worth the big picture safety net.<p>I am against the pricey models that the cloud vendors push. WAF can get expensive. They typically are bundled with other cloud services, but hey, if you&#x27;ve gotten that far, you are probably outsourcing most things to the cloud provider anyway.<p>I do not like WAF pragmatically because it lets the developer off the hook in many ways. There is something there doing their work for them and another reason for some developers to not understand or care about the security of their applications. Something else will do it for me whether I know this or not.
KronisLV超过 1 年前
There was a point in the article about WAFs being quite slow, in particular the article talks about Nginx with ModSecurity.<p>However, some benchmarks from <i>a while ago</i> suggested that Nginx performs worse with ModSecurity than Apache does in a similar configuration: <a href="https:&#x2F;&#x2F;blog.litespeedtech.com&#x2F;2019&#x2F;12&#x2F;02&#x2F;modsecurity-performance-apache-nginx-litespeed&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;blog.litespeedtech.com&#x2F;2019&#x2F;12&#x2F;02&#x2F;modsecurity-perfor...</a><p>Seems like Coraza also has some more recent benchmarks, since from what I can tell they more or less aim to replace ModSecurity in some regards: <a href="https:&#x2F;&#x2F;coraza.io&#x2F;docs&#x2F;reference&#x2F;benchmarks&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;coraza.io&#x2F;docs&#x2F;reference&#x2F;benchmarks&#x2F;</a><p>I wonder whether anyone has undertaken the effort to compare the performance of the self-hosted WAF options in 2023, or at least in the past few years.<p>Personally, I think the performance tradeoff might sometimes be worth it if security does indeed improve, the Swiss cheese model (defense in depth) and all that: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Swiss_cheese_model" rel="nofollow noreferrer">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Swiss_cheese_model</a>
elevation超过 1 年前
Bit by a WAF this week. A client needed to enable web payments and selected a lesser known payment processor with slightly lower fees? I built an integration test to submit test payment card along with a fake name and a real address. The request failed with no diagnostic information. My request looked well formed according to the docs so I raised an issue with support.<p>Weeks later, they got back to me. It turned out the payment processor&#x27;s WAF was rejecting my submission because the street name contained the word &quot;Union&quot;, and the WAF was sanitizing input fields by rejecting any SQL syntax, despite the lack of control sequences. Napkin math suggests their WAF would reject payments from 1% of the US population on the basis of their street or city name. This is a hidden tax on top of their nominal processing fees!<p>Best practice also means the WAF is probably also configured to accept vendor security updates, silently introducing even more rejection criteria.<p>The love of compliance is the root of many types of evil.
asylteltine超过 1 年前
These are pretty weak arguments. Making nice graphics in games also increases frame times therefore we shouldn’t make nice graphics? Yeah wafs will slow down network requests the question is <i>does that matter?</i><p>The answer is no. The argument about cap1 is also extremely weak. It was a bad incident but it’s a single example of a waf being a vector and most of the damage was caused by IAM misconfiguration.
评论 #38256129 未加载
1nd1ansumm3r超过 1 年前
Nicely written and the author clearly has more experience than myself. I did, however, get hit with a data breach via SQL injection, and everyone I spoke to (not vendors or sales folks) seemed to agree that a WAF would have blocked the attack outright.
评论 #38255386 未加载
yabones超过 1 年前
I&#x27;ve found that the most effective way to secure a webserver is to just block any IP that pounds on the default vhost by IP. No WAF, no fuss.<p>After a few months of building up a denylist, I get almost zero hits from scanners and spambots.<p><a href="https:&#x2F;&#x2F;gist.github.com&#x2F;noahbailey&#x2F;474922b752ee733d639c91e271992507#file-blocklist_nginx-sh" rel="nofollow noreferrer">https:&#x2F;&#x2F;gist.github.com&#x2F;noahbailey&#x2F;474922b752ee733d639c91e27...</a><p><a href="https:&#x2F;&#x2F;nbailey.ca&#x2F;post&#x2F;block-scanners&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;nbailey.ca&#x2F;post&#x2F;block-scanners&#x2F;</a>
troyvit超过 1 年前
&gt; Now I&#x27;ll admit these ideas are quite broad<p>Ayup. Especially for small teams working with large piles of software (lookin&#x27; at you WordPress) that are insecure out of the box. The ideas are also constrained mainly to fixing SQL injections, which are only an aspect of security.<p>* Isolate components in case of a breach That&#x27;s great but it doesn&#x27;t fix a breach, it just limits the scope. Better than nothing but if a WAF stops the breach from happening ...?<p>* Immutability Cool for those teams that have control of their entire infrastructure. However this also only solves those cases that are caused by mutability.<p>* Static analysis to look for stuff like devs forgetting to use prepared statements. Definitely! Sure! But again, if you&#x27;re using a piece of software off the shelf a lot of that is out of your hands.<p>* Restricting API endpoints to limit access to necessary tables Another great idea if you are in control of your software. Hacking into a fairly large project like WordPress to effect these changes (if they aren&#x27;t already) would require a large team and a ton of maintenance. Basically it&#x27;d be a fork.<p>Do any of these help against a DDOS, or even accidental DOS caused by search spam? Nah, but a WAF at the edge stops the latter in its tracks. I&#x27;m not saying a WAF is a panacea for all ills, and yeah I bet a rethink would mean better-built web app firewalls, but discouraging their use would cripple most of the long-tail of the web and honestly that&#x27;s where all the cool stuff is anyway.
评论 #38257544 未加载
sebazzz超过 1 年前
&gt; Imagine how slow the web would be if every piece of JavaScript needed to be analyzed by hundreds of regexes before being executed!<p>Well, there is super duper secure mode in Edge that disables the JIT - so there&#x27;s that. It also enables CET. <a href="https:&#x2F;&#x2F;microsoftedge.github.io&#x2F;edgevr&#x2F;posts&#x2F;Super-Duper-Secure-Mode&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;microsoftedge.github.io&#x2F;edgevr&#x2F;posts&#x2F;Super-Duper-Sec...</a>
评论 #38255562 未加载
jauntywundrkind超过 1 年前
There&#x27;s so much excusing away while things will be bad, for a long time, but that doesn&#x27;t seem particularly hacker-ful. I&#x27;m glad those views are represented, but as many HN threads the status quo is again decidedly notably business-as-usual in-defense-of-meh.<p>That said, I do think front end routers are just taking over. Kubernetes Gateway API is <i>the</i> front end API, hard fought for &amp; iterated again and again and again, to become a baseline set of expectations that&#x27;s basically great. Having a front end that can compose routes is so so so good &amp; powerful, needed to be standardized, and this seems far &amp; away like what is happening.<p>I tend to agree that we have too often in the past intermediated our services. It wasn&#x27;t even a firewall, but my org used to basically out of habit put an nginx in each container in front of node. No one knew why, no one could conjecture what for, but we just let it roll. WAF is that kind of thoughtless mindless zombie nonsense.
tehalex超过 1 年前
Agree for our apps.<p>However, for 3rd party code we run&#x2F;host but don&#x27;t really own I see value to a WAF. For example, we unfortunately run WordPress, and I don&#x27;t have time to manually audit all of the stupid plugins people want to be installed beyond a checker for known vulnerabilities, so a WAF is some comfort&#x2F;protection.
评论 #38256084 未加载
unethical_ban超过 1 年前
This is like saying &quot;Don&#x27;t have a network-based firewall, because Google figured out zero-trust&quot;.<p>There are absolutely ways to do things that we should look to for inspiration, but the harsh reality is that legacy software, legacy teams and regulations mean we must (and often should) continue using security-team-maintained chokepoints for Internet-exposed services.<p>If there were to become some standard API gateway tool that is clearly auditable, with obvious IAM&#x2F;permissions to specific database sections for each API call, then maybe that could be used in lieu of a WAF. The point is, regulators and Infosec need to have a tool or process in-line (physically, like a WAF or firewall) or procedurally (such as analysis and checkpoints in a CI deployment) to ensure a business application is secure.
hermannj314超过 1 年前
So a WAF is something you deploy to man-in-the-middle your own traffic, but it is ok because &quot;you kind of know the guy in the middle&quot;?<p>Please inspect all my HTTPS traffic, I terminated SSL, so you are free to modify the HTTP, no one will know, we trust you completely!<p>Why is this a good idea exactly?
评论 #38256170 未加载
评论 #38256629 未加载
lousken超过 1 年前
I don&#x27;t see issues with WAF. Sure, it takes some time to set up so that you have &lt;0.01% false positives but it filters out tons of robot attacks and other garbage. As backend does not have to deal with it, things like server errors almost vanished and I think it&#x27;s a good tool - just like having a firewall. Of course you should not overdo it with the rules and check the logs once in a while (just like with SIEM).<p>I do however have issues stupid CAPTCHAs like Cloudflare has that even humans can&#x27;t pass through when using a privacy oriented browser. Sites should serve visitors and not the other way around.
nokya超过 1 年前
Writing all of this and concluding with a recommendation to use static analyzers feels like a joke. So we shouldn&#x27;t use a tool that scans for known bad vectors but use a tool that...scans for known bad vectors instead?<p>Yeah, sure.
评论 #38261833 未加载
amanzi超过 1 年前
I&#x27;ve fought against WAFs in the past, but in govt departments, they are often a check-box in your security checklist that must be checked. I&#x27;ve even had to fight a security guy telling me I needed two WAFs because he wasn&#x27;t convinced the first WAF was good enough (because it was a managed service and the vendor didn&#x27;t want to share the specific configuration.)<p>In saying that, there are definitely use-cases where a WAF is required - especially if you have a legacy app on an older code-base that needs to be exposed to the internet.
sebazzz超过 1 年前
This sounds so much like music to my ears. Where I work a WAF is mandatory, Azure Application Gateway in our instance, and they enable ALL of the rules because the outsourced colleagues they follow the rules set by infosec like sheep. The consequences are that many requests are blocked as a false positive.<p>Completely legitimate requests, like for instance an OpenID redirect from Azure AD (Microsoft Online) login to the application. They then get blocked by the SQL Injection rules in AAG. So user friendly.<p>At one point we were seriously considering base64 encoding all request bodies from javascript before sending them to the server and decoding them there - just to get around this bullshit.
评论 #38256349 未加载
JoeSpaghettio超过 1 年前
So there are a few issues with this, WAFs do have their uses, generally speaking yes rules based on regexes looking for sql injection are silly. But they do have their useses. For example tarrgeted blocking, <a href="https:&#x2F;&#x2F;confluence.atlassian.com&#x2F;security&#x2F;cve-2023-22515-privilege-escalation-vulnerability-in-confluence-data-center-and-server-1295682276.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;confluence.atlassian.com&#x2F;security&#x2F;cve-2023-22515-pri...</a> . While waiting for the patch, a WAF can quickly block all requests to the &#x2F;setup endpoint.<p>I would also say that static analysis as a panacea for SQL Injection is laughable. SAST tools have a hard time finding sql injection in code. As they quickly loose track of user controlled data. They almost always create false positives &#x2F; false negatives when Parameterised queries are used incorrectly. For example when user controlled data gets into the SQL query rather than the parameter of a paremeterised query. And that completely ignores SQL Injection attacks that do not occur within your code directly, but in libraries you are using.
评论 #38255522 未加载
lemmsjid超过 1 年前
To me this blog post doesn&#x27;t fully make its case, though has many good points and is a good read.<p>I think my main logical objection is that the alternative best practices at the end of the article were all security best practices before WAFs existed. Which makes me ask the question, why did WAFs come into existence in the first place? Did the founders of those companies convince customers they needed them without those customers actually need them?<p>I think not. In the years before WAFs existed, I was in the position more than once of being in an organization whose web application security footprint had grown to the point where we ended up writing a home-grown version of a WAF. E.g. adding an interception layer that would analyze inputs and outputs for typical security violations.<p>Why? Well, first because it started to give us a sense of the types of attacks that people were trying to use. Second, because the types of mitigations mentioned by the author of this blog post aren&#x27;t the whole story. You can audit that your entire system avoids SQL injection attacks via stored procedures, then your company buys another company with a code base that fails such audits. Or someone attacks by leveraging your caching layer which stores and sends back unaudited key-value pairs. Perhaps (this has happened to me) a bug gets introduced into the deployment system, and the code that forces authentication is not shipped, and the calling code doesn&#x27;t properly fail when the auth checking code isn&#x27;t in there. A real head slapper in hindsight.<p>I do like the best practice of process isolation around APIs, and only allowing APIs to have the privileges they require, but in practice, if there are hundreds of APIs undergoing frequent changes, the complexity of managing that becomes a security risk in and of itself, because the ACL rules are deeply complicated.<p>Relying solely on a WAF seems like a bad practice. But also relying only on secure design philosophy is a practice with plenty of historical failures.<p>So if the point of the article is that WAFs breed complacency, I agree with that! But if a WAF is used as an analysis, auditing, and fast-response layer, alongside following secure design principles, then I&#x27;d say that based on personal experience, if WAFs didn&#x27;t exist, people would write home grown ones with their own sets of flaws.
kabigon超过 1 年前
I get it and the points made here are valid but, the reality is that the teams deploying the WAF + infra and the team writing the insecure&#x2F;secure code are different teams with different roadmaps. We have to deploy a WAF because the developers are not writing this magical unicorn code that follows all security best practices and gets refactored once a week. There are vulnerabilities, issues etc. that need to be addressed just like any app. SO yes, WAF is necessary.
raincom超过 1 年前
Large companies have WAFPlus-as-a-service(load balancing +WAF+ SSO: any team can provision one and put their app behind a WAF. Is there any alternative to replace that?
评论 #38255525 未加载
mschuster91超过 1 年前
I don&#x27;t see the world as black-and-white as the author does.<p>The thing is, as soon as you&#x27;re reachable from the Internet, you will get <i>bombarded</i> by crap. Skiddies just blasting every IP they can with Wordpress exploits, log4j exploits, whatever. People DDoSing you for the lulz or for ransom. A WAF and CDN - personally I like what AWS has to offer - is basically a tool that&#x27;s (unfortunately) required to be on the Internet these days.
thedougd超过 1 年前
I never saw much discussion as to why Capital One’s IAM role for their WAF gave broad access to a number of S3 buckets. That SSRF attack should have resulted in the exposure of the WAF logs, at worst.<p>Who wrote the policy? Was it a centralized IAM team? Does a centralized IAM team make for more granular or more one size fits all IAM policies?
cratermoon超过 1 年前
How do teams that deploy and maintain WAFs separate the signals from the noise. The constant door-knocking and buzz of credential-stuffing attacks, probes, and so forth that any API or web application gets generates a flood of data, most of it worthless. How do opsec people detect and address real threats meaningfully?
andrewstuart超过 1 年前
The argument in this post seems to be not against WAFs, but against poorly written and slow WAFs.
dang超过 1 年前
Related ongoing thread:<p><i>We&#x27;ve learned nothing from the SolarWinds hack</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=38255923">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=38255923</a> - Nov 2023 (74 comments)
salzig超过 1 年前
How do you handle requests with obvious malicious intend like „&#x2F;wp-admin&#x2F;„ on a Java service?<p>Do you ignore these kind of mass&#x2F;spam requests? Do you block those requests? I‘m curious.
评论 #38256993 未加载
评论 #38257313 未加载
c0balt超过 1 年前
WAFs are a good way of masking some issues but they tend to not help against more sophisticated attackers, as in a bit more sophisticated than just using metasploit.
RicoElectrico超过 1 年前
We all know how enterprise software vendors oversell and underdeliver. I can only imagine ITsec products in particular being even worse.
评论 #38255348 未加载
评论 #38255490 未加载
Ekaros超过 1 年前
WAFs are also bring on risks that are not considered. At least in scenarios where things get logged and no one considers how they are sanitized. And then there is also GDPR in Europe.<p>Lot of these issues could be avoided by good API design. But if you need WAF you might not be doing that... So you end up passing tokens as parameters and they end up in logs. Then again if someone has access to them they probably also have other access. But it still is often forgotten aspect.
mike_hock超过 1 年前
Belongs on the security snakeoil shelf right next to sudo and fail2ban.
ThomasBb超过 1 年前
Feels like you could replace WAF with DLP, EDR or most any other 3 letter abbreviation... Or indeed bike helmets. Vendor push + industry ‘best practice’ tribal knowledge is tough to resist.
zsoltkacsandi超过 1 年前
Here is my opinion: WAF is a tool, use it where it makes sense. Don’t use it where it doesn’t make sense.<p>I’ve seen many use cases where deploying a WAF solution was completely reasonable and the problem couldn’t have been solved in the application code. And let’s not forget often you have to run applications that were written by other companies, and you still need an additional layer of security.<p>—-<p>These “stop using X” articles are really pointless (and boring). They also misguide the people who have less experience in a particular field.
评论 #38255951 未加载
rickreynoldssf超过 1 年前
A simple &quot;WAF&quot; can be implemented without hardware or anything overly complex by doing just a three things that will eliminate most malicious traffic.<p>• Block all traffic from AWS, Azure, etc. yeah, you&#x27;ll loose some traffic from some VPNs and maybe you care and if so, this suggestion isn&#x27;t for you.<p>• Verify the traffic saying it&#x27;s GoogleBot, BingBot or DuckBot are really from those sources. All three provide a list of valid IPs accessible via a REST endpoint to match incoming IPs against. Block Yandex etc. There is likely no good for you coming from a Russian or Chinese search engine indexing you.<p>• Make sure the browser versions in the User Agent aren&#x27;t like 5 years old. That&#x27;s a great indicator of a bot.
评论 #38256439 未加载
vasdae超过 1 年前
I work with PHP and I think WAFs are potentially useful (and potentially problematic).