Re: Aborting malicious requests

On Tue, 20 Mar 2018 13:03:09 + "Friscia, Michael" wrote: > This is great, thank you again, this is a huge jumpstart! Per NIST best practices, you should limit the HTML verbs that you allow. A very simple website can run on just GET and HEAD. Here is how you 444 websites trying to POST for ex

Re: Aborting malicious requests

This is great, thank you again, this is a huge jumpstart! ___ Michael Friscia Office of Communications Yale School of Medicine (203) 737-7932 - office (203) 931-5381 - mobile http://web.yale.edu On 3/19/18, 1:43 PM, "nginx on behalf

Re: Aborting malicious requests

On Mon, 19 Mar 2018 12:31:20 + "Friscia, Michael" wrote: > Just a thought before I start crafting one. I am creating a > location{} block with the intention of populating it with a ton of > requests I want to terminate immediately with a 444 response. Before > I start, I thought I’d ask to se

RE: Aborting malicious requests

Have you considered using something like mod_security to manage this sort of thing? From: nginx [mailto:nginx-boun...@nginx.org] On Behalf Of Friscia, Michael Sent: Monday, March 19, 2018 9:17 AM To: nginx@nginx.org Subject: [IE] Re: Aborting malicious requests Thank you Gary, I really

Re: Aborting malicious requests

Thank you Gary, I really appreciate you moving me in the right direction. Sent from my iPhone with all its odd spell checks On Mar 19, 2018, at 9:36 AM, Gary mailto:li...@lazygranch.com>> wrote: Your basic idea is right, but what you want to do is use a "map." I will follow up with more detail

Re: Aborting malicious requests

Your basic idea is right, but what you want to do is use a "map." I will follow up with more details when I can pull the code off my server. I 444 a number of services that I don't use. I have a script to find the IP addresses of those that trigger a 444 from access.log. If they come from a data