Archy's Blog

I've recently stumbled upon this problem that hosts cannot be registered in FreeIPA in the usual provisioning workflow for no obvious reason.  In my case, it was caused by the Realm Setting where the realm was not written in capital letters. [archy@katello ~]$ hammer realm info --name 'archyslife.lan' Id: 1 Name: archyslife.lan Realm proxy id: 1 Realm type: FreeIPA Locations: HomeLab Organizations: archyslife Created at: 2020/11/19 18:07:28 Updated at: 2020/11/19 18:07:30 The fix was fairly simple since everything necessary was updating the name to all caps. [archy@katello ~]$ hammer realm update --new-name 'ARCHYSLIFE.LAN' Id: 1 Name: ARCHYSLIFE.LAN Realm proxy id: 1 Realm type: FreeIPA Locations: HomeLab Organizations: archyslife Created at: 2020/11/19 18:07:28 Updated at: 2020/11/24 11:45:26 The provisioning workflow should now work as expected with...

If there's some problem regarding any network-facing services, it can be useful to capture the traffic of the server's interfaces. A nice graphical environment for analyzing these traffic-dumps is Wireshark. First, make sure tcpdump is installed on your server: Note: yum is symlinked on CentOS 8 so this command will work. [archy@server ~]$ sudo yum -y install tcpdump Now that tcpdump is installed, you can start capturing traffic. [archy@server ~]$ sudo tcpdump -i eth0 -nn -c 10000 -Z $(whoami) -w tcpdump_$(date +%Y-%m-%d).pcapng 'dst net 172.31.10.0/24' -i the interface of the server from which to capture traffic -nn disables name resolution for ip addresses and ports -c specifies the number of packages before the capture is stopped automatically -Z specifies the user which will be the owner of the captured file -w specifies the file to which the capture should be written The last argument will be the filter expression, in my case 'dst net 172.31.10.0/24' ...

In one of my previous posts, I've mentioned locking down SSHD in terms of Algorithms, MACs, and Ciphers for the connection. This config is intended to work on larger fleets of servers and I'll not go into obscurity, meaning I will not change the SSH Port to something else.  However, these are probably the most important settings to change for a larger fleet of servers. Protocol Versions Let's start with the first setting, pinning the protocol to version 2: [archy@ansible01 ~]$ sudo vim /etc/ssh/sshd_config Protocol 2 Ciphers, Algorithms, and MACs  At the time of writing this (11/2020), the first algorithms tend to be the most secure, and the second mentioned ones tend to be focused on compatibility. If you are using an updated ssh-client, it should always pick the first. [archy@ansible01 ~]$ sudo vim /etc/ssh/sshd_config KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256 Ciphers chacha20-poly1305@openssh.com,aes256-ctr MACs hmac-s...

Since I use SSH relatively frequently for remote connections as well as configuration management (Ansible), I prefer to secure it as well as I can.  Securing SSH might be a topic for another day. This time I'll only go into ensuring that only selected Ciphers, MACs, and Algorithms are allowed and how to verify that changes are successful. First of all, let's build up a small inventory using nmap: [23:07:36 - archy@stealth-falcon ~]$ nmap -sV -p 22 -open 172.31.10.0/24 A brief explanation of the arguments: -sV: will probe open ports and try to determine the service's version. -p: This specifies the port or port range to scan. I'll be going for one port only. --open: This will only print out hosts where the port is actually open. Now that we know what we're working with, let's configure the Ciphers, Algorithms, and MACs to lock down ssh. Depending on the number of servers you have, I recommend using the config management tool of your choice, be it ansible, pupp...