Behind the Eyes

Category: Security

  • LetsEncrypt it!

    Hello, Quite a quick turnaround for blog posts and me. This one is going to be helpful for those of us that use Wildcard Certificates in our environment and found out that our SSL provider changed their policies based on industry standards, but now their certificates cost 200x more than they used to so we are moving to an opensource and free solution.

    For those of you that don’t know what the previous paragraph means, Google, and other major web site providers implemented that all communications on the Internet be secured. To do this, we use SSL or Secure Socket Layer certificates. These certificates verify and validate that the site you are on is the real one and any information that you provide on it will be encrypted and secure. SSL Certificate do this encrypting and signing to make sure everything is good. In the past, we used to have to spend $100’s, if not $1000’s (Like it did) to have this capability. LetsEncrypt came about to make this free and accessible to everyone. The downside is that the certificates are only valid for 90 days instead of a year, but you get what you pay for.

    I am moving to this model because my vendor of SSL, Digicert changed their model and now I can’t renew certificates without spending another $600 on top of the $5k I’ve already spent. So I am moving to LetsEncrypt.

    LetsEncrypt is a SSL company that uses a software package called certbot that can automatically create and install certificates that are trusted to systems.

    My DNS host provider, however, is not one of their partners. However, they do allow me to edit records on the fly, which is important since that is how LetsEncrypt verifies that you own the domain and won’t generate a certificate if you don’t. This means that I can’t automate the deployment or the generation, and I have to run the following command to update my certificates every 90 days. Some of my systems can be automated, which those, like this one that runs my web server, can. However, I do have some systems like my Virtual Center server or my Email server that use Wildcard or a single certificate to cover multiple servers. This blog will discuss how to do this, mainly so that in 90 days I can remember how to do this.

    So, on to how to do this.

    First, install certbot on a machine. Since I’m a Linux person, and I used Ubuntu, I installed this on my local machine:

    sudo apt update
sudo apt install letsencrypt

    This installs the base LetsEncrypt software with no plugins. Since my DNS provider does not have a plugin, I have to do this manually.

    I also had to add the wildcard, or “*” to my domain to prove I owned the domain, so I logged in to my DNS provider, and created an “A” record that pointed to my webserver with the *.lucaswilliams.net name. This will allow me to use this certificate on any of my server inside my lucaswilliams.net domain. Very useful for virtual server for VMware, email, and other servers that need HTTPS and SSL Certificates.

    Once I created the wildcard domain entry in my DNS record. I then went to the terminal on my Linux machine and typed the following:

    sudo certbot certonly --manual \
--preferred-challenges=dns \
--email user@domain.com \
--server https://acme-v02.api.letsencrypt.org/directory \
--agree-tos \
-d *.domain.com

    for the --server https://acme-v02.api.letsencrypt.org/directory line, you have to use this server to create the certificate as this is the only one that LetsEncrypt uses to for this requirement.

    After hitting enter to start the process, I was presented a prompt asking if I wanted to share my information and details about the certificate, which I replied “N” but if you want you can.

    The next prompt is the important one. It looks like the following:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name:

_acme-challenge.domain.com.

with the following value:

q12yr1dyFyrh143HHRTe42HH_hf#1d7&ewftgs8H

Before continuing, verify the TXT record has been deployed. Depending on the DNS
provider, this may take some time, from a few seconds to multiple minutes. You can
check if it has finished deploying with aid of online tools, such as the Google
Admin Toolbox: https://toolbox.googleapps.com/apps/dig/#TXT/_acme-challenge.domain.com.
Look for one or more bolded line(s) below the line ';ANSWER'. It should show the
value(s) you've just added.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue

    I then logged into my DNS provider and created this TXT record and then hit enter in the terminal to complete the key generation. LetsEncrypt verified the record and created my certificates in /etc/letsencrypt/live/domain.com. You will need ‘root’ access for the live directory, so I ran sudo -i to change to root user and access the certificates.

    I then copied the privekey.pem and fullchain.pem files to my servers and renamed them to what the system understands as the private key file and the certificate file.

    The biggest takeaway from this is that LetsEncrypt will let us create certificates for our systems for free, however, they only are valid for 90 days which means that we have to do this every 3 months. Some systems can be fully automated if their names don’t change or the certificate is used only for validation and verification of the site and name, but more complex certificates, like email verification and signature signing, this is the way to go for that.

    If any of you know of a better way of doing this, please let me know and I’ll share it and give you credit for the improvment!

  • Using UFW to secure a server

    Using UFW to secure a server

    Hello Everyone! Hope you’re doing well!

    So for the last few weeks, I have been dealing with a DoS attack happening against me. After spending a couple days with Comcast Network Engineers we finally figured out that my mail server was being attacked. Once we disabled the NIC on the server, Internet service would start up immediately and everything appeared to be working properly. Looking at the auth logs, I noticed that port 80 and port 22 were getting bombarded by the DoS attacks.

    Since the Comcast gateway has a poor firewall, I looked in to getting an upgraded PAN to meet my demand, but unfortunatly, that was going to set me back about $4k, and I looked at Untangle, but ran into configuration issues with the Comcast Gateway and my static IP’s.

    So, until I save my pennies to get the upgraded PAN I had to use ufw to block my attacks.

    UFW, or Uncomplicated Firewall, is the default Firewall for Ubuntu. Since my mail server is running Ubuntu, I decided to use this. And it is fairly easy to setup and use.

    First thing I noticed when being attacked is that specific Chinese IP addresses were attacking the server on port 22 and port 80, which are the SSH port and the unencrypted default web server port. So these were going to be the first ones that I setup, however, one thing to note is that when you enabled ufw, it blocks all traffic, which is a good thing really, however, when you rely on email for your job, blocking it all is not good. so I needed to find out what external ports I needed to have open to the public so that it would still work, and which ones I could have just available internally so that I can still work on the servers if I need to.

    First thing I did was look at what ports my server was sharing outside. I did this with the netstat command:

    netstat -an | more

    This command outputs all the interfaces and ports that the server is listening and communicating on. This also tells you who is connected to what service if they have an open session, so this command is pretty important if you are wanting to get into security.

    To make it easy, I needed imap, pop, smtp, ssh, http, https, and ldap.

    I also needed to know what can be internal only and what needs to be exposed to the public so that my email server can still get email.

    Here is what I came up with:

    PortsVisibility
    22 (SSH)Internal
    25 (SMTP)public
    443 (HTTPS)public
    993 IMAPpublic
    465 (SMTPS)public
    587 (SMTP Submission)public
    80 (HTTP)Internal
    110 (POP3)Internal
    143 IMAPInternal
    389 (LDAP)Internal
    995 (IMAPS)Public

    So, now that I have the required information, I can create the rules. They are as simple as doing the following command:

    sudo ufw allow from x.x.x.x/24 to any port 22

    This rule allowed only my internal IPv4 network to connect to the server. I did this for all internal addresses. I also added the specific email external IP address with a /32 to specify only the server could talk to itself on the internal ports. Might have been overkill, but better safe than sorry. For my public rules I did the following command:

    sudo ufw allow from any to any port 443

    This will also create IPv6 rules as well.

    If you accidently create a rule and it isn’t working properly, you can remove the rule by first looking up its number:

    sudo ufw status numbered

    and then:

    sudo ufw delete [rule #]

    Once everything is done, enable the firewall so that the rules will be applied:

    sudo ufw enable

    If you every need to stop the firewall, you can disable it by sudo ufw disable and it will go back to being unsecured.
    I still had to reboot the server after creating the rules and enabling the firewall since sessions were still open but after the reboot, I haven’t had any more issues and email still works. You can look at the syslog to see all the blocks, which is somewhat fullfilling.

    If you have any questions, or if you have any comments, please leave them below!
    Thanks!