Re: Assistance with Security design
The key essence to security, and I know it sounds clichéd, is to know how the underlying environment works and behaves. Once you managed to reach that level it'll be a little easier to asses the security risks involved (which will take years; before I started using FreeBSD (now approx. 1.5 years ago) I was already quite fluent with Postfix, Dovecot and Apache administration, yet even I pick up new traits from time to time).
Also; one step at a time.
For example; you may enhance your security by using SSHGuard to shield yourself from login attempts, and using the security.bsd.see_other_uids kernel configuration setting (so that unprivileged user accounts can see each others running processes) may also help to further enhance this.
But what happens if you both activate the kernel configuration (by editing /etc/sysctl.conf and rebooting for example) and install SSHGuard, only to end up with a failed installation? Is this a problem with SSHGuard, or a problem with your system or perhaps could it be that you shouldn't be using the security.bsd.see_other_uids setting in the first place?
Other than that it's very hard to give advice based on security because most of all there isn't a "one size fits all" kind of solution.
Alas; things which quite work out for me where security is concerned...
I always build the base OS myself; the source tree is kept on all my servers and mounted read only. Not more secure per definition of course but this will make it harder on possible involved third parties to gain more control over my system. Further more it also gives me a good insight into the OS itself, for me acts as part of a fail save (if it builds then its reasonable to assume that it'll most likely boot).
Software such as Dovecot, Postfix and others also gets build (using the Ports collection) and is obviously also specifically configured. I don't use third party front-end systems to configure my servers (not fully) but most of it was done by hand. This gives me more control and because all my servers are nearly fully identical where configuration is concerned this also saves me time because I can share (parts of) my configuration across different servers.
Always document the stuff you did and keep that documentation on both a safe as well as easy to reach place. If you don't work on a certain part of the system (because it simply works as expected) then it shouldn't come as a surprise that you might eventually forget the details on how it all worked. That can be a problem if you need to work on such a section several months or years later. Remember: "Nah, I'll discover how it worked eventually and will get it going again" ... that's usually not the best recipe if you want to maintain a certain security standard (also see my first point).
And if applicable: come up with your own (specific) ways to secure your system instead of merely relying on predefined solutions.
It's the classic problem: a lot of people may choose to use 'Product X' for a more enhanced security based on the good reputation and the high standing quality which that software product has. But on the other side of the medal now comes the risk that due to its popularity most of the 'bad guys' will also know this piece of software and will know how to target it. Whether or not that might work isn't relevant here; the point I'm trying to make here is that you are making a target of yourself. For good or bad is impossible to say of course.
Sometimes (but be very careful here) it is possible that you may actually increase your security by not using 'Product X', even though it might actually improve on things.
But you have to be careful with that of course...
Example: On one of my more popular websites I used to run Wordpress with a lot of security measures in place. It worked pretty well, maintenance was relatively simple, but I kept getting dozens and dozens of post attempts where those posts obviously were attempts to spam the system. Even though these were pages where there was no "reply" option available.
The reason for that was simple: the bots recognized a Wordpress setup and thus started targeting known URL's which are normally used to post reactions. All neatly automated.
So on that same website, but another part of it, I set up a guestbook. With the distinct difference that I had programmed this critter myself using ASP.NET. Had your usual fail saves; a check that contents was supplied, a (brief) check for valid e-mail addresses and a CAPTCHA system. But not a pre-made CAPTCHA which everyone can download and install by point and clicking in Visual Studio. Instead it was a relatively simple CAPTCHA system which I had designed by myself.
Result? No spam attempts what so ever. The spammers came across a system which they didn't recognize (thus couldn't anticipate for) and the customized CAPTCHA also posed a problem because who is going to build an automation for one single CAPTCHA setting which is most likely found on one place on the entire internet?
So in this particular example I actually benefited from not using Wordpress where security was concerned, even though Wordpress is a pretty decent environment.
Alas; your mileage may vary as they say. But these are the key elements which I always keep in mind.