security

WordPress passwords and brute force

From the man himself:

Here’s what I would recommend: If you still use “admin” as a username on your blog, change it, use a strong password, if you’re on WP.com turn on two-factor authentication, and of course make sure you’re up-to-date on the latest version of WordPress. Do this and you’ll be ahead of 99% of sites out there and probably never have a problem. Most other advice isn’t great — supposedly this botnet has over 90,000 IP addresses, so an IP limiting or login throttling plugin isn’t going to be great (they could try from a different IP a second for 24 hours).

WordPress version check

With all the news of brute force attacks against WordPress, I thought I’d at least update the installations running on my servers. Since there are quite a few instances of WordPress on some of them, I was in need of some automated way to check the installed version, hence – the WordPress version check script.

I have some really old versions that I wouldn’t update automatically, so that functionality is not in the script yet (hopefully in the future). But as they say, knowing the problem is half of the solution or something like that.

If you don’t like mine, build your own, using WordPress.org API.

Accessing current username in sudo scripts on CentOS

I got a bit of a puzzle at work today. I had a script that was executed as another user via sudo, but I wanted to access the original username in the script, to know who was executing it. Sudoers manual suggest working with “Defaults env_keep“. Looking into the /etc/sudoers, I noticed that $USERNAME variable was whitelisted (in line #3 below):

Defaults env_reset
Defaults env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS"
Defaults env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
Defaults env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
Defaults env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
Defaults env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"

So, I tried to use the $USERNAME variable in my script but it was coming up with empty results. That made me look deeper into default Bash initialization, and I found out that $USERNAME variable setup wasn’t a part of it. However, $LOGNAME was (in /etc/profile). I think, so few people actually use it that nobody noticed or bothered about it until now. Anyway, the solution now was obvious – simply add $LOGNAME variable to the sudo white list. Appending this line to the above env_keep ones did the job:

Defaults    env_keep += "LOGNAME"

There. In hopes it will help future generations…

P.S.: All that happened on a more or less default installation of CentOS 6.3, but I’m sure other Red Hat based distributions have a similar issue.

P.P.S.: If your script is ALWAYS invoked via sudo, also have a look at $SUDO_UID, $SUDO_GID, and $SUDO_USER variables.

SSH dynamic black list

Slashdot runs the post on how bots are now trying higher ports for SSH password guessing. This is not a problem for those who do key-based authentication, but for those who have to have password authentication enabled, there is plenty of good advice in the comments to the post. One of the comments provides this handy iptables-based dynamic black list:

iptables --new-chain SSHTHROTTLE
iptables --append SSHTHROTTLE --match recent --name bad_actors --update --seconds 86400 --jump DROP
iptables --append SSHTHROTTLE --match hashlimit --hashlimit-name ssh_throttle --hashlimit-upto 5/hour --hashlimit-mode srcip --hashlimit-burst 2 --jump ACCEPT
iptables --append SSHTHROTTLE --match recent --name bad_actors --set --jump DROP
iptables --append INPUT --in-interface ext+ --proto tcp --match conntrack --ctstate NEW --dport 22 --syn --jump SSHTHROTTLE

I haven’t tried it out myself yet, but I’m saving it here for the next time I have a server with password-based authentication SSH.