The problem is tricky–we must leave FTP and SSH open to the entire world, but at the same time be selective on what we black list.   How do you make that determination?  Strictly on bad login credentials?

We could, but that would mean that we’d inadvertently lock out real users.  A better solution we found has to do with timing connection attempts.   With IPTables, we can keep a counter based upon source IP–and track how many new socket attempts are made within a certain span of time.     For instance, if we detect the IP address 1.2.3.4 making 5 connection attempts within 60 seconds, there is a darn good chance it isn’t someone mistyping a password.

Here is how we did it, based upon another script we found out in the Internets:

#!/bin/bash
/sbin/iptables -N SSH
/sbin/iptables -N SSH_BLACKLIST
/sbin/iptables -A SSH_BLACKLIST -m recent --name SSH_COUNTER --set -j LOG --log-level warn --log-prefix "Blocked: "
/sbin/iptables -A SSH_BLACKLIST -j REJECT
/sbin/iptables -A SSH -m recent --name SSH_COUNTER --update --seconds 300 -j REJECT
/sbin/iptables -A SSH -m recent --name SSH --rcheck --seconds 60 --hitcount 5 -j SSH_BLACKLIST
/sbin/iptables -A SSH -m recent --name SSH --rcheck --seconds 2 -j LOG --log-level warn --log-prefix "Added: "
/sbin/iptables -A SSH -m recent --name SSH --update --seconds 2 -j REJECT
/sbin/iptables -A SSH -m recent --name SSH_COUNTER --remove -j LOG --log-level warn --log-prefix "Removed: "
/sbin/iptables -A SSH -m recent --name SSH --set -j ACCEPT
/sbin/iptables -A INPUT -m state --state NEW -p tcp -m tcp --dport 22 -j SSH

This creates two new tables, SSH and SSH_BLACKLIST.   Upon the intial connection attempt, the IP is added to the SSH_COUNTER counter.   If the same IP address is seen again within 60 seconds, it is duly noted–however no action is taken until the hitcount reaches 5.   In that case, the rules jump to the SSH_BLACKLIST table, it is logged, and subsequent connections from that IP are dropped for 5 minutes until things calm down.   In order to do this for FTP, just rename the targets as appropriate and change the target port to 21 on the last line.

The nice thing about this set up is that it is auto-cleaning.  After 5 minutes of no activity, the counter forgets about the IP address and things return to normal.   We’ve found that this is just enough protection to drastically reduce bruteforce attempts, yet not get in the way of normal usage by our customers.  Over time, this has become our favorite technique and we’ve begun to implement it on any Internet-facing machine with open SSH ports.

http://www.thelinuxfix.com/blog/2008/10/24/trixbox-vpns-and-the-20-second-issue/

Unfortunately our new rack didn’t make it there as fast as I did, so I ended up staging the equipment for deployment by the collocation facility.

While I was there however, I ended up racking equipment for three new customers–and now the existing TLF rack is completely full. We still have about 4U left, but are using 79% of both 30 amp circuits–which is too close for comfort (nominal states 80% maxiumum).

Bottom line though is that the time was right for a new rack purchase… now the goal is to fill that one up!

Here’s the picture I took right before I left on Saturday night.

A big component of this is the shared server hosting stuff which is now all handled under H-Sphere–an all encompassing control panel, distribution, and load-management system. The super cool thing is that it reduces management in a huge way allowing TLF to sell really nice shared sever hosting for super-cheap, like $4.50/mo. Go sign up!

TLF also been enlisted as an official domain registrar, as well as a reseller for Comodo–meaning TLF is now a one-stop shop. You just visit that control panel and you’re off and running.

The next phase is to get our VPS stuff finished up and migrate the rest of the internal TLF stuff to the new VMware server, freeing up the old one for customer VM’s.I can almost see the light at the end of the tunnel!

The basic specs are as follows:

• VMWare Host: Dell PowerEdge 1950 (dual quad core, 8 gigs RAM)
• NFS Cluster: Two Dell PowerEdge 860s (single quad core, 4 gigs RAM each)
• Networking: Dell PowerConnect 5324
• Centralized storage: EonStor A24F-R2224
• Internal DRAC on each node for cluster fencing (not ideal, read below).
• All the VMDKs are stored on an NFS mount from the cluster.

Through quite a bit of experimentation and trial and error, I have it running pretty solid. Some of the key points:

1. Used RedHat EL 5 all the way around, with the related GFS/RHCS packages
2. Mounted GFS on the NFS nodes with noatime,noquota for some minor speed improvements.
3. NFS4 and TCP for everything. Makes failover to the other node more reliable.
4. Use ‘hard’ mounts on the VMWare server, use timeo=600,retrans=2 in your options. This allows TCP to handle transmission delays during a failover versus NFS.
5. On the export side, craft your /etc/exports so that each has a matching ‘fsid=’ for every export. This gets around stale handles.
6. Use the GFS/shared storage/floating IP technique as documented in the Cluster NFS Cookbook versus managed NFS (read why below).
7. Bonded the NICs on the NFS nodes for higher throughput (in our case they will be exporting to more than one server when in production, so this was necessary).
8. Spanning tree algorithm delays on the PowerConnect can get you in trouble with a fencing loop in a two-node setup. During a reboot situation one of the nodes, the NICs come up quicker during Linux sysinit than they do on the switch. Thus, Linux thinks the interface should be reachable (when it’s not) and when fenced attempts to initalize, it cannot reach the other node and consequently fences that one. Solution is to either add “LINKDELAY” to /etc/sysconfig/network or just disable spanning tree on the switch.

I intially tried the managed NFS setup in Cluster Suite (check the cookbook), however there are two major problems. At this time, managed NFS appears to be set up to use NFSv2 and v3 only, as there is no opportunity to modify the export options via Cluster Suite. Also, there are timing delays with how Cluster Suite manages the NFS daemons…

Of course, during a failover speed is of the essence. So, when I had this rig configured for managed NFS failover, I was experiencing 12+ second delays in failover. Why?

Well, it turns out RedHat has a sleep command in /usr/share/cluster/ip.sh (the virtual IP management script) that adds 10 seconds to the failver so NFSD can clear its cache (!?). Pretty hackish, and results in an unacceptable delay during a failovers. Unfortunately if you’re running managed NFS, there’s no real way around this unless you want to risk corruption of NFSD going down without flushing its cache to disk.

I found this in the Cluster Project FAQ. With the ’sleep 10′ command gone, failover is much, much quicker. As long as you’re doing the GFS thing versus the managed NFS setup this works quite nicely and fast enough that VMWare doesn’t seem to know the better of what is going on.

Performance-wise, it’s pretty darn good. I have a dedicated PowerConnect 5324 for use as an “ethernet SAN” to interconnect the NFS nodes, and VMWare Server. That being said, 20 concurrent lightly loaded VMs results in nothing abnormal in terms of performance or reliability. In fact, it’s hard to tell the difference from local disk–even during a failover. The NIC being used for “front-end” access to the VMWare Server Console even seems to experience more traffic than the NFS one according to the PowerConnect’s interface reports, though that leaves me a bit skeptical.

I would have been interesting to see if the TOE (TCP Offload Engine) equipped on the 1950’s NetExtremeII NICs would have made a performance improvment, but it works in Windows 2003 only. Bummer.

Another “gotcha” to watch for is using RAC cards on the servers for fencing purposes. In most cases it works fine however when power is lost to the entire server, the DRAC goes down with it and becomes unreachable. This leaves the surviving node stuck trying to fence the dead one, and failover never occurs. A better option would be to use a managable PDU (which we’ll do ultimately).

Bottom line it seems to work very well in almost all failure situations I’ve tested it in. The only time I was able to make it fail (badly) was to yank the power cord out of one of the cluster nodes, and have the entire cluster crunch to a halt, due to the problem I mentioned above. I did this while installing X Windows on 50% of the VMs to simulate a lot of NFS write activity.

After bringing the entire cluster back up manually, the only damage was a corrupt RPM DB on one of the VMs. The others came back up fine after a fsck on boot. Not bad!

After my testing, I’m confident this set up will work in a production environment. If you wish to do try the same, ensure your testing plan includes every possible outage situation you can fathom. Weird/odd stuff can come up (for example the spanning tree thing) and of course it is far better to nail those down in R&D than in production!

I’m loading up a PowerEdge 860 running CentOS5 with Dell’s OpenManage Server Agents (OMSA). On reboot, I receive a udev error about ‘dataeng.hotplug’ not being able to exec early in the system init.

After scratching my head for a few–it hit me: it’s because I have /opt on a separate filesystem as root (/), which isn’t available while udev is initializing. Sure enough, in /etc/udev/rules.d, there’s an entry for Dell’s openmange stuff pointing to a shell script in /opt/dell.

Anyway, if you run into that just place the OMSA install on the root filesystem versus a submounted one and your problem wil disappear. You could also just copy that script out and place it somewhere more appropriate–like /sbin–and modify that udev rules entry.

With great flexibility comes weirdness at times! Dell probably shouldn’t have a sysinit level script running from a filesystem that is probably submounted by sysadmins 50% of the time.