Obviously having to wait for an attack to be successful, then responding by blocking the source IP is not a good long term strategy so I’ve made changes to Apache to fix this.

     I added a QoS module to Apache and configured it to mitigate this type of attack in the future, actually this type or another where the full request isn’t sent tying up processes.

     Either way there is now a limit on connections per IP that will prevent one attacker from tying up the entire server, and timeouts on connections that are stalled or sending below a threshold (presently sent to 500 characters / second).

     This should mitigate this type of slow http attack in the future.

     We had a denial of service attack against our web server this morning which consisted of someone initiating more than 400 requests from a very slow connection.  This had the effect of launching 400 workers that just backed up a large amount of data in queue because the connection was too slow to receive the data.

     These were all coming from one IP address rather than a BotNet (which would have been ineffective for this type of attack as it would have had the bandwidth to absorb the traffic). The offending IP address has been blocked.

There will be a meeting of and for Eskimo North users on December 19th, 2015, at 2PM at Spiro’s on Aurora.  Hope to see you there!

     Today I noticed we were getting a bunch of requests like this:

     What these are is a hack that attempts to bash usernames and passwords against xmlrpc.php in WordPress to try to hack WordPress accounts.

     To counter this, and generally afford a number of other worthwhile security improvements in WordPress, I recommend installing the “All In One WP Security” security plug-in on your WordPress site and in the WP Security settings under firewall, enable block access to xmlrpc.php unless you have a plugin that requires this.  There are many other useful options in this plugin you may wish to enable as well.

     If you experience any problem with the forum sign-up, please shoot me an e-mail with the details.

     In the last week or so I’ve seen a significant increase in the number of virus containing e-mails arriving which means there is some new Windows virus going around that is not yet in clamav’s viral database.

     It would appear this new virus is attempting to hack accounts because we’ve also seen a large corresponding increase in invalid authentication attempts.

     If you run Windows please make sure your anti-virus database is up to date and run full system scans from time to time.

     If you do not have MalwareBytes anti-malware software installed, I strongly recommend it as about 97% of the malware I’ve ever been infected with, it has found.  Second to that Kaspersky is also good but heavy weight demanding a lot of resources.

     These are our crawl stats for October and November:

     Our website is about 99% WordPress based and 100% SSL encrypted, so these stats represent really worst case speeds since it is both interpreted PHP code and encrypted, also most of our site uses only fragment and SQL caching and not overall page caching because of it’s dynamic nature.

     In this two month interval our absolute worst response time was 310ms and average 124ms.  This is with each users PHP code running under it’s own UID, so security was not compromised to achieve this fast response.

     I have put a great deal of effort and resources into optimizing web response times because it provides the end user with the best possible web experience, one where he or she pushes the button and the page is instantly there.  I’ve read that Google rewards sites which average less than 200ms latency with higher rankings in the search results.  Having your site hosted here will help your rankings.

     I challenge anyone who has websites hosted elsewhere that are PHP based and https encrypted to compare your Google crawl stat results to sites hosted here.

     I apologize for the brief interruption around 5:15PM lasting approximately two minutes.  The web interface on our router at the co-location facility died and I was unable to get the web server on the router to restart without a reboot.

Bob O’Brien requested Notepad++ be installed on our shell servers.

Notepad++ is Windows only, however after doing some research I found out two good things:

1) Others report that it does run under wine.
2) There is a Linux clone called notepadqq.

I will chase down notepadqq and get it installed.

Since Wine installed software is installed per-user, to use the Windows version you will need to install it in your wine directory here. To do this, connect with a graphical client such as X2Go, fire up Firefox, go to the Notepad++ site, and download and run installer.exe.

The Linux version, notepadqq, is presently installed on Ubuntu, Debian, Centos7, Scientific7, OpenSuse, and Fedora.

The libraries are too old on Shellx and Scientific to install notepadqq on those systems however notepad++ is known to run under the version of Wine that exists on those boxes so if you want to install and run the Windows version, you can do that.

There does not seem to be a version available for Mint Jessie yet.