Posts on Barton Bytes

How to Fix Aruba Clearpass Virtual Machine Losing IP Address on Restart

Thu, 12 Oct 2023 10:52:05 -0700

Resolve Aruba Clearpass 10.8 on Hyper-V Losing It’s IP Address After Being Shut Down

We were running Aruba Clearpass version 10.8 as a Hyper-V virtual machine when we encountered the following problem: after the VM was shut down or restarted, the Clearpass server would lose it’s IP address, and it would have to be manually re-added.

This caused some serious issues when it came to syncing, because for some reason, our Clearpass subscriber couldn’t connect to the publisher, and so would refuse to add the IP address. This would necessitate rolling the subscriber back to a previous snapshot in order to restore the IP address.

I found some community support threads about the issue, but the suggested fixes weren’t working. Finally I figured out that the suggested steps had to be done in a very specific order.

Here are the steps I took to fix the issue of Aruba Clearpass losing it’s management IP address:

Drop subscribers from the publisher
Shut down Clearpass virtual machine
Delete the Hyper-V network interfaces on the virtual machine and re-add them
Start the VM and configure the management IP address
Shut down the VM and change the network interfaces from Dynamic to Static under “Advanced Features”
Start the VM and configure the management IP address
Run the following command: system refresh-network
Restart the VM one last time

After doing the tasks in this specific order, our Aruba Clearpass virtual machines stopped losing their IP address on shutdown.

SPF Record Configuration

Sun, 27 Aug 2023 15:07:05 -0700

Title: Mastering SPF Record Configuration: A Step-by-Step Guide

In today’s digital landscape, email authentication has become a critical aspect of cybersecurity. Among the various techniques, SPF (Sender Policy Framework) stands out as an essential tool to prevent email spoofing and phishing attacks. By configuring SPF records correctly, you can safeguard your domain’s reputation and ensure that your legitimate emails reach their intended recipients. In this guide, we’ll take you through the process of configuring an SPF record step by step.

What is SPF?

Sender Policy Framework (SPF) is an email authentication protocol that helps verify whether the sender of an email is authorized to send messages on behalf of a specific domain. It works by specifying which IP addresses or servers are allowed to send emails from your domain. When an email server receives a message, it checks the SPF record to determine if the sending server is allowed to send on behalf of the domain.

Step-by-Step Guide to Configuring SPF Records:

Step 1: Understand Your Email Infrastructure

Before configuring an SPF record, it’s important to understand your email infrastructure. Identify all the servers, services, and third-party applications that send emails from your domain. This could include your main email server, marketing automation platforms, and customer support tools.

Step 2: Create Your SPF Record

Log in to Your DNS Hosting Provider: Access your domain’s DNS settings through your hosting provider’s control panel.
Navigate to SPF Settings: Look for an option to manage DNS records or add SPF records. This might be labeled as “DNS Management,” “DNS Records,” or “Zone Editor.”
Create a New SPF Record: Add a new TXT record. The Name/Host field can be left blank or set to “@” to signify your root domain.
Configure the SPF Syntax: The SPF record is defined using a simple syntax. It typically begins with “v=spf1” (version 1 of the SPF protocol). After that, you specify the allowed sending mechanisms:
- IP Addresses: You can include specific IP addresses or ranges that are authorized to send emails on your behalf. For example: “ip4:192.168.1.1” or “ip6:2001:db8::1”.
- Include Mechanism: If you’re using third-party services to send emails, they might provide you with an include mechanism. For example: “include:_spf.example.com”.
- All Mechanism: You might conclude your SPF record with “-all”, which means that all other servers not explicitly mentioned are not allowed to send emails from your domain.
Putting It Together: Your SPF record might look something like this:
```
v=spf1 ip4:192.168.1.1 include:_spf.example.com -all
```
Save the Record: Once you’ve entered the SPF syntax, save the DNS record.

Step 3: Monitor and Test

After configuring your SPF record, it’s important to monitor its effectiveness and test its functionality:

Use SPF Testing Tools: There are online SPF testing tools available that can help you validate your SPF record’s correctness. These tools simulate how receiving mail servers will interpret your SPF record.
Observe Email Delivery: Keep an eye on your email delivery after implementing the SPF record. If configured incorrectly, it might lead to email delivery issues. Make sure your legitimate emails are reaching recipients as expected.

Conclusion: Secure Your Domain with SPF

Configuring an SPF record is a crucial step in bolstering your domain’s email authentication and preventing unauthorized senders from using your domain name for phishing or spam. By following this step-by-step guide, you can establish a strong foundation for email security and ensure that your legitimate communications are trusted by email providers. Remember that email authentication is an ongoing process, and it’s important to regularly review and update your SPF record as your email infrastructure evolves.

How to Configure CoreDNS for DNS Over TLS

Tue, 07 Jan 2020 21:59:57 -0800

CoreDNS makes DNS-over-TLS easy to implement

In this tutorial, we’re going to run CoreDNS in Docker containers. One container will listen for standard DNS queries on port 53, and it will resolve these queries using DNS-over-TLS upstream. Another container will listen for DNS-over-TLS queries on port 853, and will resolve these queries using standard DNS.

I’m going to assume that you have an intermediate DNS server, like a Pi-Hole, which will cache responses and filter out ads. We’ll set everything up so that your Pi-Hole will forward queries to the container that encrypts our upstream queries using DNS-over-TLS, and the container that listens for DoT will forward queries to our Pi-Hole for filtering.

I would highly recommend running these containers on an x86_64 machine, since it will be much simpler than trying to run them on an ARM machine like a Raspberry Pi. This guide will not work on a Raspberry Pi: you’ll need to make some tweaks to get it functional.

To start, make sure that both Docker and docker-compose are installed on your system. You can learn how to install Docker here.

And, assuming that you’re on a Debian-based machine:

sudo apt install -y docker-compose

Now, let’s clone the repository that contains some config files we’ll use:

git clone https://github.com/gdbarton/simple-coredns-tls.git && cd simple-coredns-tls

Let’s look through the config files and verify that everything is accurate for your purposes.

First, the coreconfig-up file. You can change the upstream server if you’d like, or lengthen the cache if you’re not using a Pi-Hole:

. {
forward . tls://9.9.9.9 tls://149.112.112.112 {
tls_servername dns.quad9.net
health_check 10s
}
cache 60
}

Now the coreconfig-down file. Make sure to change the ‘forward’ address to that of your Pi-Hole (or any other standard DNS server):

tls://.:853 {
tls /etc/coredns/cert.pem /etc/coredns/key.pem /etc/coredns/ca.pem
forward . 192.168.0.2:53
log
}

You’ll notice that the coreconfig-down contains a cert, key, and CA. You can follow a guide like this to make one, or you can generate it using the configure.sh file that I provided (must be run with sudo). You can hit Enter on all of the prompts without entering any information.

If you don’t use my configure.sh script, make sure you move the coreconfig files and the three .pem files into the /etc/coredns directory, and that they all have the correct names.

Finally, check the docker-compose.yml file. If you’re running CoreDNS on the same server as another DNS server, you’ll need to change the two 53s before the colons (on lines 6 and 7) to a different number, like 5553:

version: "3"
services:
 forwarder:
 image: "coredns/coredns"
 ports:
 - "53:53/udp"
 - "53:53"
 volumes:
 - "/etc/coredns/:/etc/coredns/"
 command: -conf /etc/coredns/coreconfig-up
 restart: always
 container_name: coredns_up

 listener:
 image: "coredns/coredns"
 ports:
 - "853:853"
 volumes:
 - "/etc/coredns/:/etc/coredns/"
 command: -conf /etc/coredns/coreconfig-down
 restart: always
 container_name: coredns_down

Once everything is verified and in the right place, we can bring up the containers:

docker-compose up -d

Verify That It Works

We need to start by installing the program kdig, which will let us test our new DNS containers. On Debian, run:

sudo apt install -y knot-dnsutils

Let’s verify that the forwarder is resolving DNS queries. From your client machine or Pi-hole, run this:

kdig @IP -p PORT yahoo.jp

…where IP is the IPv4 address of your CoreDNS machine, and PORT is the leftmost port you listed in the docker-compose file for the forwarder container.

If the DNS resolves correctly, we can point all of the machines on our network to the CoreDNS forwarder. In the Pi-hole web GUI, hit Settings on the left, followed by DNS at the top. Under Upstream DNS Servers Custom 1, enter the IP address and port of your CoreDNS forwarder (the same IP and port we used in our dig command above):

Finally, we need to test the listener container. Again from your client machine or Pi-hole, run a kdig command:

kdig @IP +tls example.com

You can configure DNS-over-TLS on your client by using a program like dnsproxy

If both of your kdig commands return addresses, then congratulations, your CoreDNS containers are working properly!

Create a Free Website With Github Pages and Hugo

Fri, 26 Jul 2019 16:52:25 -0700

A quick guide to writing and hosting a website for $0 in cost

Making your own website may seem like a lost art, but it’s easier than ever to create a free, no-strings-attached website.

We’ll be using the Hugo static site generator, which allows us to write Markdown that gets translated into HTML/CSS. Our generated HTML/CSS get stored into a git repository on Github. Github Pages will make this repository available as a fully-fledged website, complete with HTTPS and the option to add a custom domain name. We’ll go through the process step-by-step.

Installing Hugo and Starting Our Project

I’ll be assuming that you’re using Debian GNU/Linux. Everything should be able to be done on Linux, Windows, and OS X, but specific commands and configurations will vary.

To begin, install Hugo server from your distro’s repositories:

sudo apt install hugo -y

You can also download the binaries, which are likely a more recent version, from the Hugo Github repo.

Navigate to the directory where we want to store our project, and then run this command:

hugo new site yoursitename && cd yoursitename

Now, we need to add a theme. Let’s go with the Hyde-Y theme from Enten. Navigate into the themes directory of your project, and then clone the theme into this directory, using the following commands:

cd themes && git clone https://github.com/enten/hyde-y.git

Now, we need to edit our config.toml file to tell it our domain name and which theme to use. Here’s what mine looks like:

At this point, we can check out what our site look like. From our project’s root directory, run hugo server. Open up a web browser and go to http://localhost:1313

Hmm, that doesn’t look quite right. Each Hugo theme is slightly different, and this one expects files at both data/Menu.toml and data/FootMenu.toml, as well as some extra settings in config.toml. Assuming we don’t cancel hugo server while we edit and save those files, the web page in our browser will automatically update with our changes.

Much better! Let’s add one post before we share our website with the world. From the project root, run

mkdir content/post && hugo new content/post/"Welcome to My New Blog.md"

Add whatever text you’d like, and make sure to switch Draft: true to Draft: false. Here’s what my post looks like:

If you’ve been checking out your site while running hugo server, you may have noticed that your links, like About, lead to a ‘404 not found’ message. We can create this page in the same way we made the post, by running:

hugo new about.md

The About page is created under content/. Like with our post, make sure to switch it to Draft: false.

Github Pages

Awesome! We’re done making our website, but no one can see it until we deploy using Github pages. Obviously, you want a Github account. On the Github website, create a repository named your_github_username.github.io. Clone this repo into the root of our Hugo site. Then, run the following:

hugo -d your_github_username.github.io

cd into that same repo, then commit & push.

After that, then… just kidding! That’s it; you’re done. Wait a few minutes, and your website will be online at http://your_github_username.github.io . From here, you can enable HTTPS, add a custom domain name, and make new posts on your blog!

Tmux for Beginners

Fri, 21 Dec 2018 11:22:27 -0800

A quick intro to using and configuring tmux

Tmux, short for Terminal Multiplexer, is a wonderful program that many Linux novices are unfortunately unaware of. Learning how to use Tmux will greatly improve your comfort and efficacy at the command line.

If you’re running Linux, Tmux should be available from your distribution’s repositories. On Debian / Ubuntu, you can run $ sudo apt install tmux -y to install.

Configuration

$ vim ~/.tmux.conf

The following is my own tmux.conf file. If you want to pull the file, here’s the direct link:

https://bartonbytes.com/tmux.conf

set-option -g prefix C-q
# alt prefix:
#set-option -g prefix C-e
unbind C-b
# rebind split pane commands
bind | split-window -h
bind - split-window -v
unbind '"'
unbind %
# move status bar to top of terminal
set-option -g status-position top
# set background to cyan
set-option -g status-bg cyan
# alt color:
#set-option -g status-bg red
#set-option -g status-fg white
# set current window background to yellow
set-window-option -g window-status-current-style bg=yellow
# alt color:
#set-window-option -g window-status-current-bg black
# increase history limit
set-option -g history-limit 500
# increase status message display time to 2 seconds
set-option -g display-time 2000
# set base index to 1 (instead of 0)
set-option -g base-index 1
set-window-option -g pane-base-index 1
# 256 color terminal
set -g default-terminal "screen-256color"
# add "control + r" keybinding to reload tmux config
unbind r
bind r source-file ~/.tmux.conf \; display "RE- RE- RELOADED!!!"

The config file allows comments prefaced by the pound sign. My comments explain what each line does, but I’ll explain a bit more.

By default, the preface to each Tmux command is Control-b. I prefer Control-q, but you should set this to whatever is most comfortable for you, since you’ll be using it a lot.

The status-bg option sets the color of the Tmux status bar. The status-fg option sets the color of the text- by default, this is black. The window-status-current-bg sets the color of the current window, so it should be something that contrasts well with the status-bg.

The final option sets our reload command. This means that we can hit Control-q + Control-r to reload Tmux after editing our config, rather than quitting and restarting.

You’ll notice that I have a few commented-out lines marked “alt”. These are the configs that I use on servers that I ssh into. If we use the same prefix key on both machines, we’d have to hit Control-q twice before entering a command for the server, which is annoying. It’s also nice to use different colors so that we can easily tell the difference between each session.

My config file only touches on a couple of the available options. For more inspiration, there are plenty of config file examples available online. Do a web search for “.tmux.conf” or “tmux configuration” to find some.

Important Commands

After starting Tmux, our terminal will look like this:

This is our first window. We know that it’s currently active because the background is highlighted in a different color. We can run an arbitrary command here- let’s run htop, so that we can keep track of our resource usage. Then, we should make a new window. This is done by hitting our prefix + c. For us, that means C-q + c (remember, capital C refers to the control key).

We can switch to a different window by hitting the prefix + # of the window. Since our htop window is window number 1, we should hit C-q + 1 to switch back to it.

Now, we should see this:

Yeah, this is neat and all, but how do I split up my terminal so I can do stuff side-by-side like all those cool Linux power users?? Don’t worry, that’s also easy, especially since we changed our default commands to make them easier to remember.

To split a window horizontally into two panes, hit C-q + | - that’s the pipe character, probably located above your enter key. To split vertically, hit C-q + - - that’s the dash key, between zero and the = sign.

To switch back and forth between panes, hit the prefix plus an arrow key, the arrow key being the direction of the pane that we want to switch to. For example, after splitting horizontally, we can hit C-q + Left to switch back to the left pane. Try switching back and forth between your panes.

Once we’ve split a window, we can also adjust the sizes of each pane. To do so, hold down the prefix (C-q) while hitting the arrow key of the direction we want to move the pane. Try doing this a few times.

We can make our window look something like below. The top right program is tmux clock. The bottom right is cmatrix, which is likely in your distro’s repository.

To close a single pane, use C-q + x while inside the pane. To kill the whole window, use C-q + &.

Try killing the two panes on the right. Now, kill the whole window.

You’ll notice that our second window is still Window 2. If we open a new window using C-q + c, it will place itself in the lowest available position- in this case, Window 1. Until then, there simply won’t be any Window 1.

To kill all of our current tmux sessions and exit tmux, simply enter the command

$ tmux kill-server

For more commands, check out this useful site. You can also refer to the Tmux manual; just run $ man tmux

Using Tmux Remotely

Start off by running Tmux on our local host. Now, SSH into our remote server. Install Tmux and create a .tmux.conf file, just like we did before. I highly recommend uncommenting my “alt” options, and commenting out the relevant older options. Now, we can finally start Tmux on our remote host. Our terminal will look something like this:

Cool, our remote Tmux session is nested inside of our local session. I can hit C-q + c to open up a new window on my local machine, or C-e + c to open up a new window on my remote machine. If I use C-q + 1 to switch to a different window than my SSH session, then hitting C-e + anything won’t have any effect, since we’re not focused on the remote Tmux session any more.

If we forgot to edit our config file, and used the same one on both machines, we might be a bit confused. Since both of our Tmux sessions have the same prefix, we’ll have to enter it twice to pass through to the inside Tmux session. In order to open a new window in our remote session, we’d have to hit C-q + C-q + c. Our terminal would also look something like this:

We can still use Tmux like this, but it’s a lot simpler if we use different configurations on each machine.

So, we’ve made sure to change our config, and we’ve done some work in our remote session, but now we have to take a break. With Tmux, it’s easy to save our session and return to it later.

In our remote session, we can run the following command:

$ tmux detach-client

We can now exit our SSH session and re-connect later. To start up our saved Tmux session, we enter:

$ tmux attach-session -t 0

Notice that the session numbering began at zero. By default, the window numbering also begins at zero, but we changed this to one in our config file because the 1 key is easier to reach than the 0 key.

As you might have guessed, we can have more than one session running at a time. To create a new session, run the following while not inside a Tmux session:

$ tmux new-session

We can see the name of our current session on the far right side of the status bar. It will be located between two square brackets []. Although sessions will default to being named a number, incrementing from zero, we can also set our own names by using the -s flag:

$ tmux new-session -s name

Here’s what this new session would look like:

We can detach and re-attach this session the same way we did with session 0.

If you forget what you’ve named your previous sessions, don’t worry. You can find them with this:

$ tmux list-sessions

Killing a session is easy too. If you’re inside the session that you want to kill it’s as simple as

$ tmux kill-session

If we want to kill a different session, use the -t flag:

$ tmux kill-session -t name

To kill all sessions at once, we can simply kill the server:

$ tmux kill-server

This is all you need to take advantage of Tmux, but there are many more commands and configuration options available. If you’re interested in a more detailed introduction, I highly recommend the book Getting Started with Tmux by Victor Quinn.

Configure Pi Hole for DNS Over TLS

Thu, 02 Aug 2018 22:22:11 -0700

Protect your DNS traffic from snooping with DoT

Pi-hole is a wonderful program for both technical and non-technical users to run a local DNS caching server, allowing you to block malicious and ad-serving domains. One of the fundamental flaws of DNS is the lack of encryption or integrity, which allows your ISP to snoop DNS traffic or spoof a DNS response. DNS-over-TLS will not completely solve these problems (see the end of this tutorial), but it provides a step in the right direction. Let’s get started.

Pi-hole uses a fork of dnsmasq as it’s DNS server. To use DoT, we will actually need to run an additional DNS server, Unbound, that provides this feature. (If you want to use CoreDNS instead, check out my other guide) To install on a Debian-based system, run the following:

sudo apt install -y unbound dnsutils

Once installed, run the following command to grab a configuration file:

sudo wget https://bartonbytes.com/pihole.txt -O /etc/unbound/conf.d/pihole.conf

Here’s a link to the file, and a copy of the contents here:

## DNS Over TLS, Simple ENCRYPTED recursive caching DNS, TCP port 853
## unbound.conf -- original at https://calomel.org/unbound\_dns.html
## tweaks by bartonbytes.com
server:
access-control: 127.0.0.0/8 allow
cache-max-ttl: 14400
cache-min-ttl: 600
do-tcp: yes
hide-identity: yes
hide-version: yes
interface: 127.0.0.1
minimal-responses: yes
prefetch: yes
qname-minimisation: yes
rrset-roundrobin: yes
ssl-upstream: yes
use-caps-for-id: yes
verbosity: 1
port: 5533
#
forward-zone:
name: "."
forward-addr: 9.9.9.9@853 # quad9.net primary
forward-addr: 1.1.1.1@853 # cloudflare primary
forward-addr: 149.112.112.112@853 # quad9.net secondary
forward-addr: 1.0.0.1@853 # cloudflare secondary

You’ll notice that this DNS server is configured to be accessible only on the local machine. It will open up port 5533. The config file includes the Quad9 and Cloudflare upstream DNS servers, which you can change or add to if necessary.

Make sure that Unbound is running:

sudo systemctl restart unbound && sudo systemctl enable unbound

To test that Unbound can fulfill your DNS requests, run the following dig command:

dig @127.0.0.1 example.com -p 5533

Now, we need to tell Pi-hole’s dnsmasq to use this local port as it’s upstream DNS server. In the GUI, go to Settings -> DNS, and set a custom IPv4 server with the value 127.0.0.1#5533

Now we must restart Pi-hole:

sudo systemctl restart pihole-FTL

… and voila! The upstream DNS requests sent from your Pi-hole will be encrypted using TLS.

As mentioned earlier, DNS-over-TLS is not a perfect solution to your privacy concerns. No matter how you protect your DNS traffic, the name of the websites that you visit will still be visible in the SNI of your HTTPS traffic, allowing your ISP (and any other intermediary) to view it. DoT somewhat protects integrity by preventing intermediaries from manipulating your DNS requests or their responses. However, you are still trusting the upstream DNS server- in our case, Quad9 and Cloudflare- to provide the correct responses.

Another option to secure DNS traffic is DNS-over-HTTPS. I chose DoT because the cloudflared program would not work on my Raspberry Pi 1 Model B+. DoH has the advantage of being harder to block or detect, because the DNS traffic is encapsulated inside of HTTPS traffic destined for port 443. This is also a slight disadvantage due to the additional traffic overhead of the HTTPS headers, which makes DoH somewhat slower than DoT.