Monthly Archives: March 2019

Making files immutable in FreeBSD

freebsd

Occasionally, it’s necessary or desirable to make files immutable. For instance, your /etc/resolv.conf file might be being overwritten by your provider’s DHCP settings and you wish to use DNS servers other than those that are being set by your provider.

To determine if your /etc/resolv.conf file is immutable or not, use the following command:

ls -lo /etc/resolv.conf

The result will look like this if the file is mutable:

-rw-r--r--  1 root  wheel  - 38 Mar 25 13:58 /etc/resolv.conf

Or, the result will look like this is the file is immutable (notice the schg):

-rw-r--r--  1 root  wheel  schg 38 Mar 25 13:58 /etc/resolv.conf

To add the immutable flag to a file, use the following command:

chflags schg /path/to/your/file

To remove the immutable flag to a file, use the following command:

chflags noschg /path/to/your/file

Caveat: chflags does not work inside a jail. All flags must be set from the host server.

Adding the “last commit” line back into your Junos RANCID commits

juniper, rancid

As of RANCID 3.7, an annoying change was made by the authors of RANCID. The “last commit” line was removed from Junos-based device diiffs.

http://www.shrubbery.net/pipermail/rancid-announce/2017-September/000031.html

junos.pm: filter cycling & useless last commit config line

This wasn’t a switch that we could easily turn on or off, depending on your preference either. We had to dig through the code to re-enable this “useless” feature.

Find your junos.pm file and comment out the following line:

next if (/^## last commit: /i);

The “last commit” line will be present again upon your next RANCID run.

For another valuable RANCID tip, check out another article we wrote.

Using Let’s Encrypt on FreeBSD

encryption, freebsd, security

Basic commands for installing and using Let’s Encrypt on FreeBSD

Installing Certbot

Install certbot using packages for Python 2.7:

pkg install py27-certbot

Install certbot using packages for Python 3.7:

pkg install py37-certbot

Before Using Let’s Encrypt for the First Time

Create your /usr/local/etc/letsencrypt/letsencrypt.ini file

rsa-key-size = 4096
server = https://acme-v02.api.letsencrypt.org/directory
email = email@domain.tld
text = True
agree-tos = True
renew-by-default = True
authenticator = standalone

Now, you must register your account

certbot register

Creating a Certificate

The standalone server is the easiest way to authenticate, but often requires you to stop your web server to do so. If this is an option for you, then I’d recommend doing this as it only takes a few seconds as long as you’re properly prepared. Otherwise, use the webroot method which is likely your only option in a production environment. I use webroot, as per the configuration file above.

Create your certificate as follows:

certbot certonly -c /usr/local/etc/letsencrypt/letsencrypt.ini -d domain.tld -d www.domain.tld

Time to Renew

certbot manages your domains and you are not required to renew each individually. Instead, you can simply issue the following command:

certbot renew

Deleting a Domain

In order to delete a certificate, you must know the certificate name, which is usually the domain name. But, to verify, run the following command:

certbot certificates

The results should resemble the following:

certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: domain.tld
    Domains: domain.tld www.domain.tld
    Expiry Date: 2019-06-16 18:12:08+00:00 (VALID: 89 days)
    Certificate Path: /usr/local/etc/letsencrypt/live/domain.tld/fullchain.pem
    Private Key Path: /usr/local/etc/letsencrypt/live/domain.tld/privkey.pem

To delete that certificate, you would type the following:

certbot delete --cert-name domain.tld

These companies allow weak, or weaker, passwords and should be ashamed of themselves

security

The following list of sites, which is far from incomplete, should be ashamed of themselves for bad security policies:

Justification: I realize that a 20-character password is far more secure than what 99.99999% of the population use on a daily basis. However, this is just plain lazy. To put it into perspective, altering an SQL database password column from 20 to 128 could be as simple as this:

ALTER TABLE users MODIFY password varchar(128);

This would allow any encrypted hash to be stored, without consideration of characters. A sane limit to the number of characters, in my opinion, is 128.

There’s an interesting post written on another blog that talks about password cracking. Estimating Password Cracking Times

** SPG allowed up to 64 char, but after the August 13th, 2018 program merger, those with stronger passwords were required to significantly downgrade their security