<html><head></head><body lang="en-US" style="background-color: rgb(255, 255, 255); line-height: initial;">                                                                                      <div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">I'm not sure the number of virtual hosts matters since each attack is individual. But if 500 vhosts meant say a hundred customers, I sure wouldn't want to deal with the false positives in your email. </div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">Much like setting up an IP firewall, you just can't load a bunch of rules someone else wrote and expect smooth sailing. When you write your own rule, you can debug it quickly. </div>                                                                                                                                     <div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br style="display:initial"></div>                                                                                                                                                                                                   <div style="font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"></div>                                                                                                                                                                                  <table width="100%" style="background-color:white;border-spacing:0px;"> <tbody><tr><td colspan="2" style="font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);">                           <div style="border-style: solid none none; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;">  <div><b>From: </b>Anoop Alias</div><div><b>Sent: </b>Monday, September 26, 2016 4:28 AM</div><div><b>To: </b>Nginx</div><div><b>Reply To: </b>nginx@nginx.org</div><div><b>Subject: </b>Re: performance hit in using too many if's</div></div></td></tr></tbody></table><div style="border-style: solid none none; border-top-color: rgb(186, 188, 209); border-top-width: 1pt; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);"></div><br><div id="_originalContent" style=""><div dir="ltr">Ok .. reiterating my original question.<div><br></div><div>Is the usage of if / map  in nginx config  more efficient than say naxsi ( or libmodsecurity )  for something like blocking SQL injection ?</div><div><br></div><div>For example, <a href="https://github.com/nbs-system/naxsi/blob/master/naxsi_config/naxsi_core.rules">https://github.com/nbs-system/naxsi/blob/master/naxsi_config/naxsi_core.rules</a></div><div>rules 1000-1099 - blockes sql injection attempt</div><div><br></div><div>So ..do (to a limited extent )</div><div><br></div><div><div>## Block SQL injections</div><div>    set $block_sql_injections 0;</div><div>    if ($query_string ~ "union.*select.*\(") {</div><div>        set $block_sql_injections 1;</div><div>   ............</div><div>   .....................</div><div>    if ($block_file_injections = 1) {</div><div>        return 403;</div><div>    }</div></div><div><br></div><div><br></div><div><br></div><div>From the point of application performance which one is better .. ? Performance for a shared hosting server with around 500 vhosts. </div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 26, 2016 at 3:39 PM,  <span dir="ltr"><<a href="mailto:lists@lazygranch.com" target="_blank">lists@lazygranch.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For one thing, I have trouble making fail2ban work. ;-)  I run sshguard, so the major port 22 hacking is covered. And that is continous.<br>
<br>
I don't know if fail2ban can read nginx logs. I thought you need to run swatch, which requires actual perl skill to set up.<br>
<br>
In any event, my 444 is harmless other than someone not getting a reply. I find hackers try to log into WordPress. I find Google trys to log into WordPress. My guess is maybe Google is trying to figure out if you run WordPress, while the hackers would dictionary search if you were actually running WordPress. In my case, I am not running WordPress, but anyone trying to log into it is suspicious. Blocking Google is bad. <br>
<br>
So I examine the IP addresses. If from a colo, VPS, etc. , they get a lifetime ban of the entire IP space. No eyeballs there, or if a VPN, they can just drop it. If the IP goes back to some ISP or occasionally Google, I figure who cares.<br>
<br>
WordPress isn't my only trigger. I've learned the words like the Chinese use for backup, which they search for. Of course "backup" is searched as well. I have maybe 30 triggers in the map. I also limit my verbs to "get" and "head" since I only serve static pages. Ask for php, you get 444. Use wget, curl, nutch, etc., get a 444. The bad referrals get a 404.<br>
<br>
Since whatever I consider to be hacking is blocked in real time, no problem to the server. I then use the scripts to look at the IPs I deem shady and see who they are. The list is like four or so unique IP addresses a day. Most go to ISPs, often mobile. So I just live with it. If I find a commercial site, I block the hosting company associated with that commercial site.<br>
<br>
When I ran Naxsi, it would trigger on words like update. I had to change all URLs with the word update in them to a non reserved word. Some triggers I couldn't even figure out. Thus I determined using the map modules and my own triggers to be a better plan.<br>
<br>
  Original Message  <br>
From: Alt<br>
Sent: Monday, September 26, 2016 1:43 AM<br>
<span class="im HOEnZb">To: <a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
Reply To: <a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
Subject: Re: performance hit in using too many if's<br>
<br>
</span><div class="HOEnZb"><div class="h5">Hello,<br>
<br>
I don't agree with Robert Paprocki: adding modules like naxsi or modsecurity<br>
to nginx is not a solution. They have bugs, performance hits, need patch<br>
when there's new versions of nginx,...<br>
<br>
gariac, you say you send 444 to hackers then use a script to display those.<br>
Why not use fail2ban to scan the logs and ban them for some time. But of<br>
course, fail2ban could also be a performance hit if you have tons of logs to<br>
scan :-(<br>
<br>
Posted at Nginx Forum: <a href="https://forum.nginx.org/read.php?2,269808,269848#msg-269848" rel="noreferrer" target="_blank">https://forum.nginx.org/read.<wbr>php?2,269808,269848#msg-269848</a><br>
<br>
______________________________<wbr>_________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx</a><br>
<br>
______________________________<wbr>_________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><b>Anoop P Alias</b> <div><br></div></div></div></div>
</div>
<br><!--end of _originalContent --></div></body></html>