Ironically, I recently had to do just this. I had to reset WordPress admin password on a backup copy of an archived website, for which I had long forgotten the password. Since it was not a live site but only a local copy (i.e., running on localhost), I could not do the email reset. However, the stored password is hashed, so how is this supposed to work?

Fortunately, WPBeginner filled in the missing pieces on doing a password reset on a WordPress site running only on localhost:

Do you want to reset WordPress admin password on localhost? In this tutorial we will show you how to easily reset WordPress admin password on localhost.

Source: How to Reset WordPress Admin Password on Localhost

Summary write-up comparing Seafile vs ownCloud, both are online cloud storage platforms (can be hosted on a LAN or a public server). However, digging into it, I have security concerns around ownCloud. Would I put my finance information out there using it? Looks like it might not be such a grand idea.

Source: Seafile vs ownCloud: Comparison and Review

Keeping tabs on your server is very important. Being able to drill down and determine the cause is just as necessary. However, the tools to determine it can seem elusive.

I was happy to discover a new resource in InMotion Hosting and their article “Create server load monitoring bash script“. I immediately set about putting this script on a server that was giving me some issues. It also allowed me to experiment with some server caching and see how well it worked out.

I still find DigitalOcean’s documentation to be among the best, but InMotion Hosting has a nice stash of it as well.

Don’t ring the ‘dorbell’; no one’s home.

Gerald-G-Police-man

I was looking through my logwatch log one day, and I came across some of the strangest looking hits I’ve ever seen.

/Ringing.at.your.dorbell!: 1 Time(s)

Looking at the original other_vhosts_access.log file, I saw:

www.johndstech.com:80 125.25.26.121 - - [12/Jul/2015:10:30:31 -0600] "GET /Ringing.at.your.dorbell! HTTP/1.0" 404 31386 "http://google.com/search?q=2+guys+1+horse" "x00_-gawa.sa.pilipinas.2015"

My first thought was that it was some sort of strange joke, but it occurred again the next day, and so it became obvious it was something worth looking into. As it turns out, this is an attempt at exploiting the shellshock vulnerability. Script kiddies aren’t too bright, so they just copy and paste old vulnerabilities and try over and over again. So, how best to block stupid URLs like this?

I could have elected to block the traffic by referrer, but weighing the pros and cons of this came down on the con side for me. After all, the referrer isn’t necessarily what I want to block, and the skepticism.us link already points out two of them. No, I want to block stupid URLs, not the referrer.

Well, a little research came up with ModSecurity, aka mod_security. It seemed like the ideal choice, and it uses Apache syntax and config files. So, I proceeded to implement it and hit a wall — hard. I banged my head here, and I banged my head there, but all I got was a headache.

That’s because I was wasting my time, at least a couple of hours. It turns out to not be so WordPress friendly. That actually makes little sense, since the examples almost always consist of using a PHP test script to block a MySQL injection! The work around is to exclude the WordPress directories! That makes absolutely no sense when WordPress is the main platform!

So, I was without a means to block stupid URLs. Fail2ban blocks IP addresses, but only after failed access attempts, particularly bad logins. However, it turns out that there still are a couple of rather reactive alternatives.

Method 1: Iptables

The best seems to be to use iptables. Granted, that is a little intimidating, but fortunately there are plenty of examples on the web.

The best one I’ve seen so far is “Linux : using iptables string-matching filter to block vulnerability scanners” at SpamCle@ner. It is easy to follow, although I’ll admit I only followed the first part of it. The downsides they point out is that it will always filter port 80, but since I use ufw and other stuff that seems like a minor downside, and “it can cause errors (“false positive”)“, which seems very unlikely for the type of junk we are talking about here.

On the upside, this blocks the traffic before it even hits the Apache server. On the downside, you have to find a way to save it, else the rules disappear upon a server reboot.

There is a workaround for this, and it involves installing iptables-persistent. Read up on this and how to save the iptables at “Saving Iptables Firewall Rules Permanently“.

2. Ban repetitive stuff from logs

If you want a lower quality type after the fact sort of ban, you could also implement a script that does some of the repetitive blocking for you. For example:

#!/bin/bash
echo "Must run as root!"
LOGFILE="/some/path/to/idiot.log"

banhttp()
{
   for II in $(grep "$1" /var/log/apache2/*.log | cut -d' ' -f2 | sort -u)
   do
      ufw insert 5 deny from "$II" >> "$LOGFILE"
      echo "$II" >> "$LOGFILE"
   done
}

banwp()
{
   for II in $(grep "$1" /var/log/auth.log | cut -d' ' -f11 | sort -u)
   do
      ufw insert 5 deny from "$II" >> "$LOGFILE"
      echo "$II" >> "$LOGFILE"
   done
}

for JJ in 'POST /xmlrpc.php' '/Diagnostics.asp' '/Ringing.at.your.dorbell!' \
'/wiki/Five_Weird_Tricks_for_Stair' '/wiki/What_You_Need_to_Understand_About_Cardio_Training'
do
   banhttp "$JJ"
done

for JJ in 'PaigeBiehl3540' 'Sabina27Y002' 'FrancineSmith23'
do
   banwp "$JJ"
done

In theory, this latter method might be easier to maintain for newbies, but over time I suspect that this could become unwieldy. OTOH, it requires no direct fiddling with iptables, saving them, etc.

In reality, the best approach might be a hybrid one. Some of the more obvious could go into iptables directly, especially when they are so common that you are blocking stupid stuff every day and/or they are obvious hacking attempts. Some of the less serious stupid stuff could just go into the script which will block IPs that keep banging on links that don’t exist, never have existed and just plain are tiring to look at.

 

 

 

Spammers and hackers can cause all sorts of problems, so here is how to block visitors by their referrer using Apache.

Rfc1394-2-Barricades-barriers

The other day, I was investigating some 500 errors on a WordPress site. Even if you are not a webmaster, you might realize that 500 errors are never a good thing. Upon closer inspection, I noticed that the errors were coming from different IP addresses, but they shared one of two common referrers.
Continue reading “How To Block Web Traffic by Referrer in Apache”

Tired of getting probed? Here is one way to automatically add probing sites to ufw.

tone_and_probe

It sometimes seems that there isn’t a range of IP addresses that isn’t filled with idiots who have no life. They are sleaze who won’t go out and earn an honest living. Running a website requires vigilance, and I’ve learned the hard way that you cannot outsource this to some company that throws up some hardware but won’t lift a finger to help you resolve real issues. However, being vigilant shouldn’t mean that you don’t have any more of a life than the idiots who are out causing problems.

Logwatch is a very useful utility for summarizing, analyzing and reporting issues found in various logs on the system. It simplifies everything because you would otherwise be sifting through dozens, literally, of log files on the system looking for problems.

One of the useful features is that it looks for website probing. It doesn’t seem to catch everything, but it catches enough that if it reports on it, you should act on it and not delay. You could, of course, manually block the IP addresses it reports as a probe, and I did that for some time, but it is a continuous process.  Continuous, monotonous tasks are exactly the sort of thing computers were made for, so why not automate as much as is reasonable and leave only the more difficult things in the log for human eyes?  After all, if it is reporting on it, it is egregious enough of an activity to block the IP either individually or within a given range.

So, I wrote a script that could parse the input and email the resulting file. Instead of calling sendmail, then, you tell logwatch to “email” the output through this script, which I called logwatchproc.bash, which will take care of the rest.

I should mention that if you follow DigitalOcean’s instructions in the Logwatch link above, make a note of a couple of things:

It is bad form to ever modify distributed config files. They have a tendency to get overwritten. Furthermore, it turns out it won’t even have the expected behavior. Be sure to:

  1. mkdir /var/cache/logwatch
    cp /usr/share/logwatch/default.conf/logwatch.conf /etc/logwatch/conf/

    Then, you can edit the file in /etc/logwatch/conf comfortably.

  2. Change the line:
    mailer = "/usr/sbin/sendmail -t"

    to

    mailer = "/usr/bin/logwatchproc"

Next, you will want to create the file. I recommend putting it in the home directory of an account used for maintenance (which means not in root’s home), and then linking the file into /usr/bin.

Use your favorite linux (not DOS/Windows, unless you want problems) editor and paste this into it:

#!/bin/bash

[ $# -ge 1 -a -f "$1" ] && input="$1" || input="-"
MYBASE="/home/NameOfUser" # Preferably, whatever user you use for maintenance
LOGMAIL="${MYBASE}/logwatchmail.tmp"
LOGLOG="${MYBASE}/logwatchproc.log"
PROBEFILE="${MYBASE}/probesites.txt"
TODAY=$(date)
echo "=========" >> "${LOGLOG}"
echo "${TODAY}" >> "${LOGLOG}"
# Save it first
cat $input > "${LOGMAIL}"
# Email it before something happens
cat "${LOGMAIL}" | sendmail -t
sleep 30
NUMSITES="$(grep probed ${LOGMAIL} | cut -d' ' -f5 )"
echo "NUMSITES = ${NUMSITES}" | tee -a "${LOGLOG}"
if [ "${NUMSITES}." = "." ]
then
	NUMSITES=0
fi
if [ ${NUMSITES} -gt 0 ]
then
	grep probed -A "$NUMSITES" "${LOGMAIL}" | tail -"$NUMSITES" > "${PROBEFILE}"

	for II in $(cat "${PROBEFILE}")
	do
		echo "$II" >> "${LOGLOG}"
		ufw insert 3 deny from "$II"  >> "${LOGLOG}"
	done
else
	echo "No further actions needed." >> "${LOGLOG}"
fi

Be sure to change “NameOfUser” to the maintenance account login name, and save it in a convenient location in that accou nt’s home directory, ex: /home/NameOfUser/bin, for testing. Notice as well that I use “ufw insert 3” to keep it near the top (so it doesn’t interfere with later ALLOW commands). If you have any allows at the top you don’t want to overwrite, be sure to adjust this as necessary.

Next, make a symbolic link to it:

ln -s /home/NameOfUser/bin/logwatchproc.bash /usr/bin/logwatchproc

You can test it manually by calling /etc/cron.daily/00logwatch as root. Initially, you might want to test using the sudo command, but it is better to do an “su -” and change to root for final testing, as environment variables can really affect bash significantly.

That’s it!

Some critical #WordPress #SecurityUpdates went out yesterday, so its best to update now.

Blue WordPress logo
Blue WordPress logo

The title pretty much says it all. According to WordPress.org article “WordPress 4.2.1 Security Release“, “This is a critical security release for all previous versions.” Details about the vulnerability were released shortly after the update went out, so there isn’t any time to waste.

WordPress has started doing automatic updates in the last couple of major releases, but I noticed one site had not yet updated. It would be a very good idea to go out and check all of your sites.

Tightening up on #WebsiteSecurity should be the next priority for your #WordPress site.

If your WordPress site has been up more than 2 hours, you’ve probably already collected a bunch of spam attempts.  There are several tools out there to help you out with spammers and hackers, but few do better in protecting against the former category, IMO, than Anti-Spam by CleanTalk.  Straight up, it is not free, but they have a short demo period that will likely impress you.  On top of that, it is only $8.00 per year. Continue reading “Tighten Security to Finish WordPress Site Migration”

Forget installing Dovecot, Postfix, blah, blah, blah, just do it.

At least twice I read about how to not setup an email server using iRedMail because you need to learn the innards of your server.  Given the intracacies of email and all that can go wrong, it makes a certain amount of sense.  Normally, I would agree with that advice.

Here’s the problem: I tried four different sets of instructions claiming to get you up and running with Postfix, Dovecot and SpamAssassin, and not a single one worked!  I mean, these were detailed by the step instructions, yet I constantly hit a roadblock somewhere where I could not attach to the server at all from outside (if I got that far, which one set of instructions did not).

Just follow “How To Install iRedMail On Ubuntu 12.04 x64“.  I followed it, and there really is only one problem on it in that he has you define the domain in mydestination and the virtual domains both.  One comment on Howtoforge‘s article “Error: Postfix – do not list domain example.com in BOTH mydestination and virtual_mailbox_domains” states that making mydestination to be “localhost” only fixed that error.

So many options!   #CreateADigitalOceanDroplet without a lot of fuss for #WordPress.

Creating a WordPress droplet on Digital Ocean is not hard. In fact, it is downright easy. That is, the actual creation of it is. Deciding how to create it took me longer than actually doing it, as I found myself creating it, messing up, destroying it, recreating it, and so on.  Once out the door, however, it wasn’t all that difficult.
Continue reading “Creating a WordPress Droplet on DigitalOcean”