A bit of a preface here, this is the inaugural post on this site, but I don't want to waste the first post (or even much of this space within that post) on meta stuff about what I want to do. That's all on the About page, which is linked here and in the menu (well, it will be there when I get around to writing that). The one thing that I will note is that these first few posts will probably come kind of quick, given that I've had some things sitting in the queue while I got this whole thing set up and after that, things will settle down. Hopefully this can be a once or twice a week thing. We'll see. With that out of the way, let's jump on in.
OK, I know I promised no meta stuff, but I couldn't resist just a bit. As a self-described "Security Guy", I'm obviously interested in security. When I consider projects like this site, my coding, or my email, I know that I could use services that others provide (often for free) and get them all hosted with minimal trouble, minimal ongoing maintenance, and some degree of assurance that other people are considering the risks so that I don't have to. I believe that it is incumbent upon all who have an interest in security, however, to avoid doing that when possible.
Don't get me wrong. For many use cases, outsourcing the hosting of these services is a great idea. Most people should not run their own servers and services where they can avoid it. For the most part, people don't set basic things up securely (like setting up SSH to disallow password logins) and I think I can count on one hand the number who I'd really trust to properly configure SMTP and IMAP. Even if they configure things properly at first, who really remembers to keep all of these things updated and stay on top of security issues and best practices? Heck, many people who are paid to handle these things don't stay on top of them.
Security people aren't most people, though. (Insert joke here.) We're not inherently better at running these services (and certainly aren't immune from configuring things in a vulnerable way), but I believe that there is a real value to be gained for people in the security field from this kind of practical experience.
They key here is doing it correctly. Don't just follow the "How-To" guide that provides the copy/paste commands to magically have these things set up. Install an OS. Secure the OS (seriously, do that right after the install, don't put that off). Figure out which packages provide the service you want. Search for recent vulnerabilities in those packages.
Once you've figured out which package to use, read the man pages for the application and its configuration files. Read at least two different sets of online instructions about how to set it up right. Consider if there were any options that you saw that sounded better than the ones presented in those instructions. Read the relevant RFCs to make sure you're not going to blatantly violate one of those. Re-read the man page several times as you write a config from scratch. Never give up and copy/paste an example config from a tutorial.
By the end of that process, you will know those packages inside and out and will have probably picked up a good bit about the administration of your OS of choice and the protocols in general. Now join some mailing lists for your OS and your chosen upstream packages. The security-related ones are good. For example, on OpenBSD, the `user@` and `misc@` lists are full of dumb questions, but also often the answers to those dumb questions, which will answer the dumb questions that you were still researching. Now it's up to you to keep an eye on those lists and keep your server/service up-to-date.
In addition to now knowing what you're doing, you've also got credibility when you tell people that they should be doing <X> to secure their <Y> server. Employees respect their bosses more when they feel like their boss could actually perform the tasks that they are directing the employee to do (there's actual research on that and we'll leave it as an exercise to the reader to find it). My wife argues with me that this is inefficient, and it very well may be (she's usually right about these things), but it doesn't stop it from being true. Security professionals who know how the servers are really run and configured can benefit from that same effect.
This rant^H^H^H^Hpost has been mostly for people who secure server-y things. As you can probably guess from that image above, we can apply this general practice to pretty much anything. It takes time, though, and for other things (like picking up <INSERT TRENDY FLAVOR-OF-THE-WEEK JS PACKAGE>) that lack truly solid documentation, it can take a lot more time and effort. That shouldn't stop you, though. If you want to truly have more depth and be able to better secure website frontends, APIs, desktop applications, BIOSes, your car, your smart toaster, or whatever: embrace the hacker spirit, and go play with things and learn how they work. Security as a profession requires us to be knowledgeable in so many subjects and, in my opinion, that's best gained through real hands-on experience.