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!