Tag Archives: ssh

Technical

WP auto upgrade/plugin updates, file owners and CHOWN

This has been a vexing activity lately: attempting to perform WP auto-updates and plugin updates on multiple WP installations end in failure. I thought the problem simply came down to deleting or chmodding 777 the offending directories (such as upgrades and/or uploads). When that turned out to be an unwieldy and insecure proposition, I turned to what I suspected might be an FTP issue, by switching to ProFTP server. Still unsuccessful, I suspected an SSH issue–no dice. A file system method switch in wp-config for WP? Nope, not that either. Trying to install suExec for PHP? It was already enabled, and forcing a recompile nearly crashed my server.

In the end, what gave me a clue was the section on file permissions in the WP codex and some forum posts suggesting ownership changes. A handy phpinfo-type script such as <--!? php echo(exec("whoami")); --> dropped in the appropriate directories aided in identifying ownership of certain folders.

It turns out that since I’ve been using FileZilla SFTP with root (yes, I know it’s highly insecure) credentials, I’d been carelessly uploading WordPress folders and plugins with root ownership, causing havoc with the auto-update system. Since the affected folders weren’t owned by the user, the user could not use their own ftp credentials to update their WP installations. I would either see error messages such as not being able to download files to the upgrades folder or unable to create plugin directories–all because the user did not own those folders.

Unfortunately, FileZilla doesn’t have a mechanism to check ownership. It only permitted chmodding file permissions, as far as I could tell. This of course created even more of a mess because I was chmodding under root, not user.

I used shell access (e.g. PuTTy) to identify ownership. To list folders and file ownership in a directory:

ls -l folderpath

To change ownership of a folderpath:

chown -R username:usergroup folderpath

where -R applies changes recursively. For my dedicated server setup, username and usergroup happened to be the same (I did not set up user groups in Apache). In this instance, folderpath referred to the root directory where WordPress was installed. Incidentally, changing the ownership of the folders reset all of the directory permissions to 755, and file permissions to 644–exactly how I wanted them.

This may have also corrected my issue with PHP sessions (still testing) with Captcha logins and form submission. I enabled PHP sessions and restored directory permissions on the working Captcha folders to 755. Will continue to test this.

Also, be wary of changing ownership on public_html. One of my sites had user:user ownership on the folder, causing the website to be inaccessible. Chown-ing the public_html back to user:nobody fixed the issue.

Technical

Fail2Ban configs

I was fed up with all the dictionary attacks on POP3. So I decided to lookup configuring Fail2ban on that port.

First off, always remember to save your iptables: service iptables save

Next, I located the jail.local file saved under /etc/fail2ban. This file is a copy of the original /etc/fail2ban/jail.conf which I want to leave untouched.

Based on the following code, I will modify it to follow the current filters in my jail.local file. So that:

[courierauth]

enabled = true
port = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
filter = courierlogin
logpath = /var/log/mail.log

Will turn into this:

[pop3]
enabled = true
port = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
filter = courierlogin
action = iptables[name=POP3, port="smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s" protocol=tcp]
sendmail-whois[name=POP3, dest=anna@ffdepot.com, sender=fail2ban@ffdepot.com]
logpath = /var/log/maillog
maxretry = 3
ignoreip = 184.7.254.24 202.62.124.147 200.74.244.86 127.0.0.1

The newly revised code is enabled and scans the default mail ports. It creates a jail called POP3 and scans the appropriate mail log specified by logpath. The maxretry before banning is set to 3 tries. Fail2ban will then email the whois info of the IP to me, similar to what it does for SSH attempts today. The filter calls on /etc/fail2ban/filter.d/courierlogin.conf which contains the regex format which Fail2ban uses to scan mail log entries:

failregex = LOGIN FAILED, .*, ip=\[\]$

Once the jail.local file is saved, restart the Fail2ban server:


fail2ban-server -x
fail2ban-client reload
fail2ban-client status

Which responds with the corresponding number of jails, which includes one called POP3.

Afterwards, I reloaded my iptables again:

service iptables restart

Then to view the iptables: iptables -nL
Stay tuned this weekend to see if this new config pays off.

Technical

Unban me!

If you’ve found yourself unfortunate to lock yourself out of SSH and banning yourself from your own server via Fail2Ban, then here’s how to unban yourself:


iptables -L
look at the Chain fail2ban-ssh
notice the ip address to unban and count at which line number this is.
e.g.:
Chain fail2ban-ssh (1 references)
target prot opt source destination
DROP 0 -- 61.236.117.xxx anywhere
DROP 0 -- 61.236.117.yyy anywhere
RETURN 0 -- anywhere anywhere
execute the following command:
iptables -D fail2ban-ssh if you want to unban user 61.236.117.yyy use:
iptables -D fail2ban-ssh 2

Technical

Getting Fail2Ban to work

My first clue that Fail2Ban wasn’t working right: it wasn’t showing up in iptables -L.
Chain INPUT (policy ACCEPT)
target prot opt source destination
fail2ban-ssh tcp -- anywhere anywhere tcp dpt:ssh
Chain fail2ban-ssh (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere

My second clue: Fail2Ban wasn’t displaying the configuration I thought it had loaded. For example, my list of “ignoreips” wasn’t showing up when I tried to view it. Or it didn’t return the maxretry settings I had configured.

I tracked it down back to jail.local and determined that the SSH parser wasn’t actually enabled. So I uncommented the line and enabled it to “true”.
[ssh-iptables]
#enabled = false
enabled = true
filter = sshd

I also had to change it to look at the SSH log, which in CentOS is in /var/log/secure
logpath = /var/log/secure

Reloaded the config and checked the status of the daemon.
fail2ban-client reload
fail2ban-client status

Running properly, Fail2Ban creates a jail named ssh-iptables.

The only disappointment is that Fail2Ban does not ban retroactively. It only reviews new entries to determine bannable IPs.

The Fail2Ban command list helped me troubleshoot Fail2Ban. Running in interactive mode helped a great deal.

Technical

Hardening SSH/FTP

Or what I learned after reading the logs of brute force attacks on our server.

The logs issued by the Logwatch daemon on our server weren’t pretty…they told a grim tale of the attacks that besieged our server daily. I resolved to do something about it

Fail2ban proved to be an easy install. I just followed the instructions on the 2nd link given, ensuring that I configured a local jail.conf file to store my settings in. I’m not entirely clear on how to read/parse CIDR addresses, but I think I got it right regardless. One thing to remember that’s not listed here is to turn on iptables, if it isn’t already.

# /etc/init.d/iptables start

Now I have to determine if I can tie Fail2Ban to Logwatch.