System Design and Build Policy
System builds are the heart and soul of any systems administrators agenda. It is also our bread and butter, rents are due salvation. I'm publishing system builds that I feel will help you in turn I am sure you'll help me cover my goals and keep me going as a system administrator for your next builds as well.
I have rules, policies, processes and procedures that I would like for you to read before you start using the services of this site.
Basic Rules and Policies.
1. Do not claim this build information as your own. It may be similar to something you are building but it will not be 100%. Give credit to who deserves the credit.
2. Do not cut corners. I will spell out the details but if you don't read every word then the end results are all about you and your lack of attention to detail. That or you didn't use Google translate correctly.
3. Ask before you assume.
4. Pay very close attention when I say "I Advise" or "I Suggest" it means one thing and one thing only, please do not take these notes lightly and never skip reading my advertisements. I'll be the first to report if something is globally wrong with this build. (No single person is perfect and groups can only have a 98.9% max record unless they are out of a comic book.)
5. Link to as many sections as you need when you are advertising your services or promoting your network.
6. READ ALL RESOURCES.
7. If you profit from this information or save money be sure to give 10 to 30% of that savings to my PayPal account.
8. If you are a business owner, corporation that needs a Systems Administrator feel free to contact me. I work with groups and will always speak my mind regarding builds, configurations, process and procedures. Not to mention I'm a big Policy Editor fan.
9. Encryption: As of 1/1/2015 I started researching best practices which methods of communications could be used when on a micro enterprise budget. I have found that TLS 1.0 is supported on most all servers and firewalls. Even if version 1.2 is the newest we can do much of our work within the TLS 1.0 versions. This means we can use a self-sign certificate on our server or our firewall that will allow encrypted connections and encrypted content even if the certificate is wrong or bad. You'll apply for a TLS / SSL certificate one day but to get you moving it is not completely required to make valid TLS connections.
All servers and sites that I manage and develop will be moving toward a full TLS / SSL environment based on budgeting. First is email encryption then will be https connection which are a lower priority than communication like email services.
Enforcing Security is very difficult but by standards we should be using some type of communications security at all times. With all the talk about securing your website with HTTPS we should think that the little meta data someone would collect from what sites you visit is a fraction of what someone could learn about you from reading your emails.
TLS Encryption is in itself a path to allow "ALL" online "VALID" email servers a chance to protect their users.
When I say ALL,
- TLS is a protocol offered in nearly all major software vendors of email servers and many firewalls offer TLS connection policy rules.
When I say VALID,
- Spam Bots, Spam Marketing companies change so often their domain names and IPs it would not be cost effective for them to use any type of TLS connection in my opinion. This would make your server even less likely to receive spam due to the TLS settings you have to DENY ALL non TLS connections.
Maybe what some say about email servers not supporting TLS is true. SmarterMail supports it but you can't force it to use it all the time. Why have TLS if the connecting client or server can just send plain traffic?
I own a Watchguard Firewall which supports TLS 1.0, it should be supporting 1.2 as well but that might be later in an update. What I do know is I can create a rule that forces Client and Server to always use TLS or not to connect. Now I have faith that my server will not connect to another server without the TLS connection.
If you communicate with a Bank or anyone that you want to have a private communications with you need to make sure your connection is secure. If your Server to Server connection is not secure then anyone on any DNS between you and the end email server can have your email at anytime.
How do you know if your connection is secured and encrypted? You need to test the email you are sending to. I've tested Regions.Com my bank that uses Google Email Servers, TLS Connections and Security is enforced. That should mean my email is encrypted between my server and the end Google server.
It's easy to work with TLS and simple to configure. The only issue is everyone has to do it or traffic will not be 100%.
I'm doing my part, I'll start sending out notices to those that are using unsecured email servers as traffic sources.
Review: When you send email to us it's forced to be encrypted between your email server and our email server.
When we send email to you it's again encrypted between our email server and your server.
If the TLS connection is not configured correctly or a server is not allowing a TLS connection the email will not be sent. It's just that simple, you're protected by our server seeing it might be possible for someone in the middle to read the message.
Email is Encrypted before sending and needs to be on both ends.
So we have Forced TLS connections on both incoming and outgoing. That insures we have a Secured Connection.
This does not mean someone can't read your emails while standing behind you or someone that can access your emails like a manager using exchange services or an IT person.
It does not mean someone can't pull them off of a backup drive and read your emails.
Once the email arrives in your inbox security is gone. Unless you do a few extra steps.
What can you do to better your email communications security?
Setup your email service with a company that allows TLS. Make sure you know if your business can handle forced TLS or not. Just remember one thing, if it's not Forced to be encrypted it will be insecure. There is no in between here. It's either On or Off.
- FORCED TLS is what you might like to start with.
The start using PGP Email encryption software and applications on your desktops, servers, mobile devices and laptops.
- PGP is Pretty Good Privacy and the developer has a story you might want to read.
Best to encrypt than not and passing a key is easy if you do it by the book.
What else can you do?
- Delete emails that contain personal information and then be sure to empty your trash or purge the folder.
Our servers archive every 3 months. That means your email is zipped and stored off the frontend server. No need to hole years of emails.
- Delete your Sent Items!
Just like your inbox your Sent Items or Sent Folder will have information you don't need to hold onto for a long period of time.
- Archive and Password protect your archive on a file level.
Having a username and password to your Google Drive doesn't mean your files are protected. Make sure when you store any archive file that has personal information in it you password protect the archive.
- Use Hard Drive Encryption such as Bitlocker.
When you store data be sure you have your drives encrypted so they can only be accessed by your computer and you.
Nearly all the items I've listed have articles I have written showing you how to do this.
Now here's the biggest punch in the gut I can give you...
I've had this setup for 3 years and when I have people setup their emails I tell them, if they can't send to a person and the email comes back send it to me. I will then manually send an unsecured email asking them to change to Google.Com, Yahoo.Com, Hotmail.Com or MySmallCloud.Com because we all use TLS and it's OK to FORCE IT ON according to those that allow my FORCED TLS CONNECTION ONLY server! Thank you Google, Yahoo and Hotmail for keeping my members email safe in transit.
What does that say about your email provider and service provider?
You might not need to force all communications over TLS but if it was offered and a standard part of your email I would bet you would say, "Why Not"?