Making files immutable in 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

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

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.6:

pkg install py36-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-v01.api.letsencrypt.org/directory
email = email@domain.tld
text = True
agree-tos = True
renew-by-default = True
authenticator = webroot

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 -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

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 64 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

Using the replace command in Junos

My ISP has the audacity to change my dynamic IP after only two years and I had to change my IP across many different systems. I found a command and worked out the regex to replace my IP across the entire Junos configuration in a single line. Here’s how:

replace pattern "172\.16\.1\.1" with "10.0.0.1"

I was able to change address books, firewall rules, security policies, prefix lists, etc, with a single command.

Junos packet capture on branch series SRXs

Performing a packet capture is easy to do on any Juniper branch series SRX.

Three sections of configuration are required: forwarding-options, interfaces and firewall. Examples are below:

set forwarding-options packet-capture file filename PCAP files 5 size 10m

set interfaces ge-0/0/0 unit 0 family inet filter input PCAP
set interfaces ge-0/0/0 unit 0 family inet filter output PCAP

set firewall filter PCAP term PCAP1 from source-address 172.16.0.0/12
set firewall filter PCAP term PCAP1 from destination-address 192.168.0.0/16
set firewall filter PCAP term PCAP1 then sample
set firewall filter PCAP term PCAP1 then accept
set firewall filter PCAP term PCAP2 from source-address 192.168.0.0/16
set firewall filter PCAP term PCAP2 from destination-address 172.16.0.0/12
set firewall filter PCAP term PCAP2 then sample
set firewall filter PCAP term PCAP2 then accept
set firewall filter PCAP term ALLOW-EVERYTHING-ELSE then accept

The result looks as such:

interfaces {
    fe-0/0/0 {
        unit 0 {
            family inet {
                filter {
                    input PCAP;
                    output PCAP;
                }
            }
        }
    }
}

forwarding-options {
    packet-capture {
        file filename PCAP files 5 size 10m;
    }
}

firewall {
    filter PCAP {
        term PCAP1 {
            from {
                source-address {
                    172.16.0.0/12;
                }
                destination-address {
                    192.168.0.0/16;
                }
            }
            then {
                sample;
                accept;
            }
        }
        term PCAP2 {
            from {
                source-address {
                    192.168.0.0/16;
                }
                destination-address {
                    172.16.0.0/12;
                }
            }
            then {
                sample;
                accept;
            }
        }
        term ALLOW-EVERYTHING-ELSE {
            then accept;
        }
    }
}

Alternatively, you can apply this filter on the loopback interface if you wish to capture all packets matching the filter criteria on all interfaces.

To read the PCAP file, simply enter into the shell and use tcpdump:

start shell
tcpdump -r /var/tmp/PCAP.fe-0.0.0

Default username for FreeBSD AWS AMIs

For most Linux flavours and *NIX variants, the username you will connect with is root. However, FreeBSD AMIs are different. Ignore what the EC2 instance dashboard tells you when looking for instructions on connecting, which will look something like this:

ssh -i "your-aws-key.pem" root@ec2-54-219-0-69.us-west-1.compute.amazonaws.com

Instead, you will want to change the username to ec2-user, as such:

ssh -i "your-aws-key.pem" ec2-user@ec2-54-219-0-69.us-west-1.compute.amazonaws.com

SSH to the ec2-user and then you can su to a passwordless root account.

Make sure you set a root password. It’s also a good idea to get rid of the ec2-user account, but create your own account and setup your SSH keys first.

Increasing the name width in Apache auto indexing

Truncated names in Apache auto indexing aren’t helpful at all. With people running displays at 5k, there’s little reason to have this as the default behaviour. Alas, it still is and probably will be until the end of time. That said, it’s easy to get around this.

In out-of-the-box Apache install, uncomment the following line:

Include etc/apache24/extra/httpd-autoindex.conf

In that file, look for the following line:

IndexOptions FancyIndexing HTMLTable VersionSort

We want to add the NameWidth option, as so:

IndexOptions FancyIndexing HTMLTable VersionSort NameWidth=*

Restart your browser and reload the page and you’ll notice a much improved experience.

Setting your Palo Alto Networks MGT IP via CLI

If you do not wish to use the default MGT IP of 192.168.1.1 with your new Palo Alto Networks device, you can set it via the command line interface (CLI) by following these couple steps:

Connect to the console port using the standard 9600 8-N-1.

At the login prompt use admin/admin as the default credentials:

PA-220 login: admin
Password: 

admin@PA-220> 

Enter configuration mode:

admin@PA-220> configure
Entering configuration mode
[edit]
admin@PA-220# 

Set the IP, gateway and DNS server:

admin@PA-220# set deviceconfig system ip-address 10.0.0.2 netmask 255.255.255.0 default-gateway 10.0.0.1 dns-setting servers primary 8.8.8.8

Then simply commit and you’re done.