I unexpectedly passed Apple’s Directory Services Integration and Administration v10.4 Exam this past weekend. That exam, combined with the Security Best Practices v10.4 Exam that I had passed earlier, gave me seven credits or enough credits to get my Apple Certified Systems Administrator certification.
I say “unexpected” because I hadn’t really expected to pass. I hadn’t studied for it, and I was using a voucher for a free exam that I’d received from the Apple Certification Alliance in exchange for filling out a long survey. Essentially, I was going to use this voucher for a cost-free practice exam, where I could figure out what was going to be on the exam and study accordingly. Then, after studying, I’d retake the test and pass it. Instead, surprise! Passed it on the first go.
It was a pleasant surprise, to say the least. I’ve been working towards this certification for the past couple of years, and now I’ve achieved it. I’ll be one of 14 listed ACSAs in Maryland and one of only 28 in Maryland, Virginia and the District of Columbia.
I struck out with APC after trying a few times and not succeeding. Fortunately, I was able to find XCache, a comparable PHP opcode cacher that had one big advantage: clearly written directions on how to install XCache on OS X. In my case, I was installing it on OX Server, instead of OS X, but it looks like the instructions work on Server as well. After installation, to avoid any glitches, I tried disabling wp-cache2. Speeds looked good after that, so I tried enabling wp-cache again. Performance actually went down when I enabled it, so I disabled wp-cache2 again. I think I’ll leave it disabled, and see what XCache can do on its own. So far, it’s definitely snappier.
Since it’s a quiet Saturday, and I lack things to do besides haunt my going-out-of-business local CompUSA, I decided to see if I could improve the dog-slowness of this blog’s loading. Happily, it looks like the answer is yes. Thanks to a WordPress plug-in called wp-cache2, it looks like some of the speed problems have been resolved. Now I just need to get APC running (hopefully, avoiding this problem and this pitfall) and this site should be in good shape.
If you’ve got SSH open to the outside Internet, you’ve probably been attacked multiple times (even without your knowledge) by Bad People attempting to hack your box via SSH. On 10.4.9, the log that records the attempts is /var/log/secure.log. The command to poll the log for the attack is:
sudo grep “failed to auth” /var/log/secure.log | sed “s/^.* user \(.*\)\.$/\1/” | sort | uniq -c | sort -nr
I won’t go into the details, but here’s the lessons from my own server’s scan:
1. Use good passwords for your accounts. At least seven characters and toss in some numbers or symbols.
2. Disable access to root via SSH (disabling the root account would be even better.)
3. Don’t give names such as “test” or “test3″ to your accounts. If you do, make sure the account password is really good.
4. If you’re on OS X Server, name your admin account something other than “admin”. If you must use “admin”, set access restrictions on SSH so that only non-admin accounts are accessible via SSH. You can always use su to change to the admin account once you’ve logged in.
Do I follow the four rules I just mentioned? Yep. Have I been hacked via SSH? Not yet, or at least not that I’m aware of.