If you have a WordPress site here, please install the plugin “WP Fail2ban“. This plugin will generate a syslog entry for failed logins for which I have created fail2ban rules and will lock out the IP address of anyone attempting a brute force password attack. Please note this is WP Fail2ban by Charles Lecklider and not WordPress Fail2Ban by Wireflare. The former has been tested and confirmed working. The latter may work but I have not tested it.
Also, if you protect part of your site with HTTP authentication, I have created rules that will pick up multiple password guesses and ban those as well.
I’ve wanted to do some things here that require authentication of users on the web. Things like a web based spam filter configuration control and other tweaks, user profiles, chat, a calendar that shares with a Unix desktop that could also work on portable devices, stuff like this requires knowing who the user is with certainty because we don’t want some stranger tweaking your account.
Tonight I finally got Unix authentication to work on the web. This opens up a plethora of security issues because http is a connectionless protocol and hypothetically someone could mash thousands of guesses a second at user accounts without some facilities in place to stop that and I’m still working on those things. But I did get the thing fundamentally working. It does so without exposing the shadow password to the web server.
The documentation for mod_authnz_external is entirely broken in that it does not work in a <Directory> context as suggested by the instructions but does work with <Location>. Not that it matters because actually I’m going to use a form based authentication when all is said and done because I don’t want the browsers caching peoples passwords or to have to beat the daemon to death calling it for each page request.
Apache (the web server software) has been upgraded to 2.4.16. This mostly fixes some potential security issues, most of which could be used to crash the server as opposed to privilege escalation.
This upgrade should not have any operational impacts other than to eliminate potential denial of service vulnerabilities.
I will be taking the web server down tonight or early tomorrow morning for about 20 minutes to image the system.
Just wanted to throw a short word out regarding Lorn Richey for Shoreline City Council. Like myself, Lorn Richey is opposed to the radical rezoning and fast tracking of the plan to turn Shoreline into an urban wasteland destroying neighborhoods to make property developers rich.
If you’ve had it with Shoreline City Councils refusal to listen to their constituents, here is your chance to toss at least one of these criminals out on their ass and replace them with someone that sympathizes with long term residents desire to have their neighborhoods remain the suburban quiet neighborhoods they used to be. There is nothing to be gained by turning Shoreline into Seattle II.
I have just added a new page to the Support section under Remote Desktops (it is a pull down menu in the Support section), entitled, “Using Windows Remote Desktop Connection” that shows how to connect to one of our shell servers graphically using the remote desktop protocol connection software that is packaged with every Windows system.
Using Remote Desktop to connect will provide a graphical login allowing you access to a remote desktop and graphical applications but it will not provide sound or remote printing. X2Go provides these as well as a much higher performance encrypted session.
Using Remote Desktop does not require the installation of any additional software on a Windows system and thus is well suited to situations where you don’t own or have the necessary privileges to install software on a Windows system, or where you just need to get started fast.
The denial of service attack ended before we were able to determine the source or nature. It was odd in that it neither saturated bandwidth or CPU according to the router statistics but still slowed things down. I’m working on configuring more detailed logging to hopefully gain a better understanding if it reoccurs.
Things are slow right now because someone has launched a denial of service attack on our site which is sucking up a lot of bandwidth and router CPU. We are working with our co-location provider to block it.
The “eskimo.com” shell server is restored. I’m on my way back to the office.
The eskimo.com shell server is down again. This time it’s not entirely crashed but in a state where the kernel is getting CPU and it responds to pings but user space programs are not. This is an old 4.1.4 SunOS bug that happens only on multiple CPU machines.
I will be out of here for a while between post office run and a run down to the co-location facility. If I don’t answer please leave a message and I will call you upon my return.