Category Archives: Technical

Technical

Connecting to console

Connecting to console using Remote Desktop via XP changed with the application of SP3. Either type in mstsc /admin or edit the RDP file to include the line “administrative session:i:1”. Generally, this applies to Windows OSes moving forward (Vista, Windows 7 and server flavors) and is most evident in server environments. For example, connecting to Windows 2K3 server will yield several open sessions unless an RDP session specifies the console session.

Also one can disallow Administrator logoff in a remote session via gpedit.msc in 2K3. Open the Group Policy snap-in, navigate to Computer Configuration > Administrative Templates > Terminal Services. There are several options under the Standard tab that one can modify to enable or disable user behavior during remote sessions.

Lastly, it’s important to note that under default RDP settings, users should be encouraged to “logoff” RDP sessions. Simply disconnecting sessions leaves applications open and risks data loss should another user remote in.

Technical

Unblocking brute force on WHM

I thought at the time it was a good idea to enable brute force sensitivity in WHM on the server. But apparently with the numerous attempts daily, I sometimes find that I am locked out unnecessarily. I had forgotten to whitelist my IPs so that I was inevitably included in the lockout.

Anywho, I learned that I would have to delete the cphulkd tables that contained the offending IPs before I could access my WHM again. Initially I tried disabling cPHulk using the following code, but to no avail:

/usr/local/cpanel/bin/cphulk_pam_ctl --disable

So I used PuTTy to SSH into the server and used MySQL to remove the blocked IP tables.

mysql> use cphulkd;

Expected result: Database changed.

mysql> DELETE FROM `brutes`;
mysql> DELETE FROM `logins
mysql> quit;

Consequently, I was able to get into WHM, enter the Security Center to modify cPHulk Brute Force Protection, and whitelist my IPs.

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.