<html><head><style id="outgoing-font-settings">#response_container_BBPPID{font-family: initial; font-size:initial; color: initial;}</style></head><body style="background-color: rgb(255, 255, 255); background-image: initial; line-height: initial;"><div id="response_container_BBPPID" style="outline:none;" dir="auto" contenteditable="false"> <div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;">If your website doesn't need to be seen by bots, set up a firewall to block hosting companies, clouds, and VPS. Blocking AWS is easy since Amazon provides the IP space in a json format. You can go to bgp.he.net and enter a name of a hosting company and it will list the IP space. Finding Google cloud IP is more difficult. There are websites that document how to find such information. </div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;"><br></div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;">The reason I say to start at a basic firewall is firewalls are extremely CPU efficient. They do use a lot of memory since they create a database for the IP space and associated ports. However this IP space has not have eyeballs behind it. If you don't think you need to serve a bot, block it as this very low level. </div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;"><br></div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;">Anything you block with nginx will require nginx to interpret resource requests. That fires up a lot of machinery. You can use nginx maps to detect triggers such as you suggested with php and use the 444 return code which means return nothing. There are lists of shady user agents that you can block. By examining my 404 returns I have made a map of typical hacker triggers to find in the URI. They get a 444 return. You can block wget and curl in the maps. </div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;"><br></div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;">Periodically I feed all the 444 returns from the access log to a service which reports the associated host. If I find a hosting company, I add it to the blocking IP space in the firewall. I have so much IP space blocked already that I do this every two to three weeks. That only yields half a dozen companies to block. You will find a new IP CIDR for say Linode or some other VPS, and some shady cloud companies. </div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;"><br></div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;">If you trawl the web you can find services that will give you suspicious IPs to block. I will warn you however that if your firewall has a lot of CIDRs, adding a new IP forces the firewalls internal database to be edited (indexed?) which in turn uses significant CPU resources. </div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;"><br></div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;">Next up is a WAF (web application firewall) such as naxsi. I ran this for a while and wasn't impressed. Your mileage may vary. I found naxsi would trigger off of totally legitimate requests. If you use the nginx maps at least you control the triggers. </div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;"><br></div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;">Regarding FLASK, I use it on my desktop for some applications that I browse on local host. It seems easy to crash. I couldn't let this code face the internet. </div> <div name="BB10" id="response_div_spacer_BBPPID" dir="auto" style="width:100%;"> <br style="display:initial"></div> <div id="blackberry_signature_BBPPID" name="BB10" dir="auto"> <div id="_signaturePlaceholder_BBPPID" name="BB10" dir="auto"></div> </div></div><div id="_original_msg_header_BBPPID" dir="auto"> <table width="100%" style="border-spacing: 0px; display: table; outline: none;" contenteditable="false"><tbody><tr><td colspan="2" style="padding: initial; font-size: initial; text-align: initial;"> <div style="border-right: none; border-bottom: none; border-left: none; border-image: initial; border-top: 1pt solid rgb(181, 196, 223); padding: 3pt 0in 0in; font-family: Tahoma, "BB Alpha Sans", "Slate Pro"; font-size: 10pt;"> <div id="from"><b>From:</b> skip.montanaro@gmail.com</div><div id="sent"><b>Sent:</b> February 14, 2022 5:43 AM</div><div id="to"><b>To:</b> nginx@nginx.org</div><div id="reply_to"><b>Reply-to:</b> nginx@nginx.org</div><div id="subject"><b>Subject:</b> Obvious malware rejection module?</div></div></td></tr></tbody></table> <br> </div><!--start of _originalContent --><div name="BB10" dir="auto" style="background-image: initial; line-height: initial; outline: none;" contenteditable="false"><div dir="ltr"><div class="gmail_default" style="font-family:'arial' , sans-serif">I have a simple website with NGINX fronting Gunicorn and Flask. Of course, within minutes of it going live, I started to get obvious crap, probing for vulnerabilities. Nothing's gotten through yet, at least as far as I can tell. Even so, it would be nice if such malware-type requests were rejected by NGINX before they reach the backend.</div><div class="gmail_default" style="font-family:'arial' , sans-serif"><br></div><div class="gmail_default" style="font-family:'arial' , sans-serif">Is there a module for NGINX which implements something like a blackhole list similar to what you find on email servers, that is, offloading the acceptance or rejection of certain paths to a community-managed database? I scrolled through the list here:</div><div class="gmail_default" style="font-family:'arial' , sans-serif"><br></div><div class="gmail_default" style="font-family:'arial' , sans-serif"><a href="https://www.nginx.com/resources/wiki/modules/">https://www.nginx.com/resources/wiki/modules/</a><br></div><div class="gmail_default" style="font-family:'arial' , sans-serif"><br></div><div class="gmail_default" style="font-family:'arial' , sans-serif">but didn't see anything obvious. I could establish my own rewrite rules (and probably will) for some of the most egregious requests (anything ".php" would get dropped, for example), but was hoping something already existed.</div><div class="gmail_default" style="font-family:'arial' , sans-serif"><br></div><div class="gmail_default" style="font-family:'arial' , sans-serif">Thanks,</div><div class="gmail_default" style="font-family:'arial' , sans-serif"><br></div><div class="gmail_default" style="font-family:'arial' , sans-serif">Skip Montanaro</div><div class="gmail_default" style="font-family:'arial' , sans-serif"><br></div></div>
<!--end of _originalContent --></div></body></html>