Advanced USB discovery with usb-devices

If you’re working with USB devices a lot, Linux platform offers a great way to learn more about what you have connected to your system: usb-devices command.

Using usb-devices Command

Simply type usb-devices and enjoy the output. Below is an example from one of my virtual machines:

greys@mint:~ $ usb-devices
T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480 MxCh=15
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0002 Rev=04.15
S:  Manufacturer=Linux 4.15.0-54-generic ehci_hcd
S:  Product=EHCI Host Controller
S:  SerialNumber=0000:00:1d.7
C:  #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=203a ProdID=fffa Rev=01.00
S:  Manufacturer=Parallels
S:  Product=Virtual Printer (Print to PDF (Mac Desktop))
S:  SerialNumber=TAG11d87aca0
C:  #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=07(print) Sub=01 Prot=01 Driver=usblp

T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  9 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=203a ProdID=fffa Rev=01.00
S:  Manufacturer=Parallels
S:  Product=Virtual Printer (Brother HL-L5200DW series)
S:  SerialNumber=TAG1c8860e8b
C:  #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=07(print) Sub=01 Prot=01 Driver=usblp

Understanding usb-devices Output

There’s a lot of information there, but almost every line is useful.

First line confirms USB port location – system bus and port on it. It’s also a great way of seeing the speed of the port – 480Mbit suggests it’s a USB2 port:

T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  9 Spd=480 MxCh= 0

There’s a few lines documenting the device manufacturer and model name. Because it’s a virtual machine running on my Parallels Desktop software, manufacturer is reported as Parallels. But next line clarifies that this is actually the Brother laser printer from my home office network:

S:  Manufacturer=Parallels
S:  Product=Virtual Printer (Brother HL-L5200DW series)

There’s a line that I imagine will be more useful on laptops, reporting the power consumption reported for this USB port:

C:  #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=0mA

And last, but not least, is the line confirming device driver responsible for functionality of the USB device – should be very handy for troubleshooting:

I: If#= 0 Alt= 0 #EPs= 1 Cls=07(print) Sub=01 Prot=01 Driver=usblp

I’ll run this usb-devices command on my Dell XPS laptop with Ubuntu 19.10 soon and will share my findings.

systemd services Status

I’ve just learned by accident that it’s possible to run systemctl status without specifying a name of systemd service – this way you get the listing and status of all the services available in a neat tree structure.

SystemD services

As you may remember, startup services are no longer managed by /etc/init.d scripts in Linux. Instead systemd services are created – this is handy for both managing services and confirming their status (journalctl is great for showing latest status messages like error log).

Show systemd Services Status with systemctl

Run without any parameters, systemctl status command will show you a tree structure like this:

greys@sd-147674:~$ systemctl status
 ● sd-147674
     State: running
      Jobs: 0 queued
    Failed: 0 units
     Since: Sat 2019-11-23 08:45:20 CET; 1 months 20 days ago
    CGroup: /
            ├─user.slice
            │ └─user-1000.slice
            │   ├─[email protected]
            │   │ └─init.scope
            │   │   ├─19250 /lib/systemd/systemd --user
            │   │   └─19251 (sd-pam)
            │   └─session-1309.scope
            │     ├─19247 sshd: greys [priv]
            │     ├─19264 sshd: greys@pts/0
            │     ├─19265 -bash
            │     ├─19278 systemctl status
            │     └─19279 pager
            ├─init.scope
            │ └─1 /sbin/init
            └─system.slice
              ├─systemd-udevd.service
              │ └─361 /lib/systemd/systemd-udevd
              ├─cron.service
              │ └─541 /usr/sbin/cron -f
              ├─bind9.service
              │ └─587 /usr/sbin/named -u bind
              ├─systemd-journald.service
              │ └─345 /lib/systemd/systemd-journald
              ├─mdmonitor.service
              │ └─484 /sbin/mdadm --monitor --scan
              ├─ssh.service
              │ └─599 /usr/sbin/sshd -D
              ├─openntpd.service
              │ ├─634 /usr/sbin/ntpd -f /etc/openntpd/ntpd.conf
              │ ├─635 ntpd: ntp engine
              │ └─637 ntpd: dns engine
              ├─rsyslog.service
              │ └─542 /usr/sbin/rsyslogd -n -iNONE
...

In this output, you can see systemd service names like cron.server or ssh.service and then under them is the process name and numerical process ID that indicate the how each service is provided.

INTERESTING: Note how openNTPd.service is provided by 3 separate processes: ntpd and two other ntpd processes (NTP engine and DNS engine).

Confirm Actively Listening TCP Ports with lsof

I was researching SSH daemon configuration on my macOS Catalina system and realised that lsof is still the best tool for meaningfully confirming network ports that are LISTENed to.

What does it mean for port to LISTEN?

All the network services in Linux (and Windows, actually) operating systems start with the same basic pattern: some process is managing incoming network connections.

Nowadays most of network services are directly managing their own network connections – meaning service like SSH daemon or Apache web server are made available via main process (sshd or httpd in my examples) constantly running and waiting for incoming network connections on specific port. For SSH server, default port is 22. For web servers, default ports are 80 and 443.

When we say a port is LISTENing, it means there’s a process running on your system that’s monitoring this specific port. SSH is therefore listening on/for port 22, Apache (httpd) is listening for port 80 and possibly 443.

Meaningful TCP ports reporting vs Default

You may remember that netstat command shows network ports as well, but its implementations are sometimes limited to just confirming that a certain port is listened to, without helping us understand what process is doing that port listening:

greys@mcfly:~ $ netstat -na |grep LISTEN | grep 22
 tcp46      0      0  *.22000                *.*                    LISTEN
 tcp4       0      0  *.22                   *.*                    LISTEN
 tcp6       0      0  *.22                   *.*                    LISTEN

That’s why I prefer the lsof tool – it’s reporting processes information, which means any output you get is bound to contain processes numbers (PIDs) and most likely process names (binary names like sshd or httpd).

Use lsof to show listening TCP ports

lsof command has specific options for reporting processes with network activity: -iTCP will report TCP specific information, and -sTCP:LISTEN qualifier will filter just the processes that are listening for incoming connections on TCP ports (rather than client processes that only initiate outgoing network connections).

Don’t Forget to run lsof with sudo!

Normally lsof is super useful even with standard user privileges, but since I’m investigating a system service (SSH server), I have to run lsof as root. Otherwise lsof will report a list of network services, but hide the ones running above your standard user privilege level.

On modern Linux servers, lsof without sudo won’t show me anything:

greys@s2:~ $ lsof -iTCP -sTCP:LISTEN
greys@s2:~ $

My complete command to list all the services listening for incoming TCP connections in will therefore look like this (this is the macOS example):

greys@mcfly:~ $ sudo lsof -iTCP -sTCP:LISTEN
COMMAND     PID  USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
launchd       1  root    8u  IPv6 0xc37c60e6e93432f1      0t0  TCP *:ssh (LISTEN)
launchd       1  root    9u  IPv4 0xc37c60e6e934d8f1      0t0  TCP *:ssh (LISTEN)
launchd       1  root   10u  IPv6 0xc37c60e6e9343911      0t0  TCP *:rfb (LISTEN)
launchd       1  root   11u  IPv4 0xc37c60e6e934e2b9      0t0  TCP *:rfb (LISTEN)
launchd       1  root   21u  IPv6 0xc37c60e6e93432f1      0t0  TCP *:ssh (LISTEN)
launchd       1  root   24u  IPv4 0xc37c60e6e934d8f1      0t0  TCP *:ssh (LISTEN)
launchd       1  root   29u  IPv6 0xc37c60e6e9343911      0t0  TCP *:rfb (LISTEN)
launchd       1  root   32u  IPv4 0xc37c60e6e934e2b9      0t0  TCP *:rfb (LISTEN)
launchd       1  root   40u  IPv6 0xc37c60e6e9342cd1      0t0  TCP localhost:intu-ec-client (LISTEN)
launchd       1  root   46u  IPv6 0xc37c60e6e9342cd1      0t0  TCP localhost:intu-ec-client (LISTEN)
launchd       1  root   47u  IPv4 0xc37c60e6e934cf29      0t0  TCP localhost:intu-ec-client (LISTEN)
launchd       1  root   48u  IPv4 0xc37c60e6e934cf29      0t0  TCP localhost:intu-ec-client (LISTEN)
kdc         120  root    5u  IPv6 0xc37c60e6e93426b1      0t0  TCP *:kerberos (LISTEN)
kdc         120  root    7u  IPv4 0xc37c60e6e934f649      0t0  TCP *:kerberos (LISTEN)
rapportd    625 greys    4u  IPv4 0xc37c60e6ef7969d9      0t0  TCP *:49263 (LISTEN)
rapportd    625 greys    5u  IPv6 0xc37c60e6e9342091      0t0  TCP *:49263 (LISTEN)
ARDAgent    697 greys    9u  IPv6 0xc37c60e6e9341a71      0t0  TCP *:net-assistant (LISTEN)
Dropbox    1148 greys  128u  IPv4 0xc37c60e6eefd8561      0t0  TCP *:17500 (LISTEN)
Dropbox    1148 greys  129u  IPv6 0xc37c60e703f137b1      0t0  TCP *:17500 (LISTEN)
Dropbox    1148 greys  154u  IPv4 0xc37c60e6f88c09d9      0t0  TCP localhost:17603 (LISTEN)
Dropbox    1148 greys  168u  IPv4 0xc37c60e6f8940011      0t0  TCP localhost:17600 (LISTEN)
dynamicli  1204 greys    7u  IPv4 0xc37c60e6f908f9d9      0t0  TCP localhost:51456 (LISTEN)
dynamicli  1205 greys    7u  IPv4 0xc37c60e6f9a453a1      0t0  TCP localhost:51549 (LISTEN)
dynamicli  1205 greys   16u  IPv4 0xc37c60e6f9b0a8f1      0t0  TCP localhost:51551 (LISTEN)
com.docke  1341 greys    7u  IPv4 0xc37c60e6fa8222b9      0t0  TCP localhost:51725 (LISTEN)
com.docke  1345 greys   15u  IPv4 0xc37c60e6eefd7b99      0t0  TCP localhost:sun-sr-https (LISTEN)

Confirming what process is listening on a specific port

While we’re at it, here’s how the previous command can be modified to confirm a specific service listening on SSH port 22:

greys@mcfly:~ $ sudo lsof -iTCP -sTCP:LISTEN | grep ssh
 Password:
 launchd       1  root    8u  IPv6 0xc37c60e6e93432f1      0t0  TCP *:ssh (LISTEN)
 launchd       1  root    9u  IPv4 0xc37c60e6e934d8f1      0t0  TCP *:ssh (LISTEN)
 launchd       1  root   21u  IPv6 0xc37c60e6e93432f1      0t0  TCP *:ssh (LISTEN)
 launchd       1  root   24u  IPv4 0xc37c60e6e934d8f1      0t0  TCP *:ssh (LISTEN)

IMPORTANT: Note that because SSH is a standard service, lsof reports its name (ssh) rather than port number (22) in the last column of output. TCP *:ssh means process is listening for TCP port for SSH service.

I was expecting sshd, actually. But turns out remote access via SSH is managed by launchd process in recent macOS versions. Once someone logs in though, you’ll see sshd process spun up to manage the connection.

That’s it for today, hope you learned something new!

Protecting Directories with Sticky Bit

One of the least used and usually forgotten features in Linux/Unix filesystems, sticky bit is a great way to manage regular user access to a shared directory.

What is a sticky bit?

Sticky bit is a special flag that changes how a particular directory in Unix works. Without this flag, any user that has enough file permissions can remove or rename somebody else’s file in a directory. With sticky bit set, only the original owner of a file can remove or rename it – other users will get permission denied.

IMPORTANT: there’s also an even less popular scenario of using sticky bit for files – but I’ll explain it in a separate post.

How sticky bit for a directory looks

Here’s a directory I just created as myself on my laptop:

greys@maverick:~ $ ls -lad /tmp/try
drwxr-xr-x  2 greys  wheel  64 17 Dec 08:33 /tmp/try

I plan on sharing this directory with another user, called unixtutorial. So I’m opening permissions wide (warning! do this only for shared directories that contain no sensitive data):

greys@maverick:~ $ chmod a+rwx /tmp/try
greys@maverick:~ $ ls -lad /tmp/try
drwxrwxrwx  2 greys  wheel  64 17 Dec 08:33 /tmp/try

Let’s set the sticky bit for this /tmp/try directory:

greys@maverick:~ $ chmod +t /tmp/try

Here’s how it will look (note how last rwx in permissions changed to rwt – t is the sticky bit):

greys@maverick:~ $ ls -lad /tmp/try
drwxrwxrwt  2 greys  wheel  64 17 Dec 08:33 /tmp/try

How sticky bit works

I’m creating a file in the sticky-bit protected directrory /tmp/try that any user on my OS can access for read and write:

greys@maverick:~ $ touch /tmp/try/file1
greys@maverick:~ $ ls -lad /tmp/try/file1
-rw-r--r--  1 greys  wheel  0 17 Dec 08:34 /tmp/try/file1
greys@maverick:~ $ chmod 666 /tmp/try/file1
greys@maverick:~ $ ls -lad /tmp/try/file1
-rw-rw-rw-  1 greys  wheel  0 17 Dec 08:34 /tmp/try/file1

… but if I start another terminal session as user unixtutorial, I can’t remove this file even though rw- permissions should allow it:

unixtutorial@maverick:~ $ sudo su - unixtutorial
Password:
unixtutorial@maverick:~ $ cd /tmp/try
unixtutorial@maverick:/tmp/try $ rm /tmp/try/file1
rm: /tmp/try/file1: Permission denied

unixtutorial@maverick:/tmp/try $ ls -la /tmp/try/file1
 -rw-rw-rw-   1 greys  wheel    0 Dec 17 08:34 file1

If as my original user greys I remove the sticky bit from /tmp/try:

greys@maverick:~ $ chmod -t /tmp/try
greys@maverick:~ $ ls -ald /tmp/try
drwxrwxrwx  2 greys  wheel  64 17 Dec 08:36 /tmp/try

… I can now remove the file as another user:

unixtutorial@maverick:/tmp/try $ rm /tmp/try/file1
unixtutorial@maverick:/tmp/try $ ls -al /tmp/try/file1
ls: /tmp/try/file1: No such file or directory

Sticky Bit Clarifications

You can’t apply sticky bit to a user or group, as you would with other file access permissions. It works on a file or directory level, not user or group level.
This is invalid: chmod u+t

This is correct: chmod +t
Sticky bit only controls regular users – super user root can still remove any files in sticky-bit protected directories, even owned by other users

That’s it for today. Hope you have learned something new!

preserve-root flag for rm command

rm will warn you instead of removing everything in / recursively

rm command, the one used to delete files and directories, can be very dangerous if used with root privileges. It’s comforting to know that most modern rm implementations attempt to help you avoid a complete disaster (of deleting everything on your OS disk).

What preserve-root Flag Does

Default behaviour of rm command in Linux for quite some time, preserve-root flag means that if you attempt to recursively remove the root (/) directory you would get a warning:

greys@stream:/ $ rm -rf /
 rm: it is dangerous to operate recursively on '/'
 rm: use --no-preserve-root to override this failsafe

Why would this be dangerous? Because every directory and filesystem in Unix and Linux is mounted off root (/) path. So if you remove files/directories there recursively, you may wipe out your entire operating system (and quite a bit of mounted filesystems, if your’e really out of luck).

Now, I’m running this command as my own regular user in the example above. So even if rm wasn’t protecting me, I would still be unable to do any real harm to the OS due to core OS files being protected from accidental removal by regular users. But if I was running as root, it would have been really dangerous.

Why preserve-root is Really Useful

Of course, most of us would never consciously attempt removing everything under /, but here’s a very typical scenario that is quite common with beginners: using unitialised variables (empty values).

greys@stream:/ $ MYDIR=mydir
greys@stream:/ $ echo rm -rf /${MYDIR}
rm -rf /mydir
greys@stream:/ $ rm -rf /${MYDIR}

In this example above, I have a variable called MYDIR, which points to a directory. I’m runnign echo command first to verify what rm command will look like – and it seems correct, so I attempt it.

But if I forget to initialise the MYDIR variable, its value will be empty, meaning my command will become much more dangerous:

greys@stream:/ $ MYDIR=
greys@stream:/ $ echo rm -rf /${MYDIR}
rm -rf /
greys@stream:/ $ rm -rf /${MYDIR}
rm: it is dangerous to operate recursively on '/'
rm: use --no-preserve-root to override this failsafe

Show Process Limits Using /proc Filesystem

**Show process limits with /proc filesystem**

I think I mentioned the special /proc filesystem before, it’s available in Linux distros and helps you obtain system and process information via normal files created in a special structure. Today I’d like to show you another cool trick /proc has.

Show Process Info Using /proc

Just to remind you, here’s what I mean: on my Red Hat PC I have this sshd daemon process running:

root@redhat:/ # ps -aef | grep [o]penssh
 root      5130     1  0 Oct03 ?        00:00:00 /usr/sbin/sshd -D [email protected],[email protected],aes256-ctr,aes256-cbc,[email protected],aes128-ctr,aes128-cbc [email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha1,[email protected],hmac-sha2-512 -oGSSAPIKexAlgorithms=gss-gex-sha1-,gss-group14-sha1- [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1 -oHostKeyAlgorithms=rsa-sha2-256,ecdsa-sha2-nistp256,[email protected],ecdsa-sha2-nistp384,[email protected],rsa-sha2-512,ecdsa-sha2-nistp521,[email protected],ssh-ed25519,[email protected],ssh-rsa,[email protected] -oPubkeyAcceptedKeyTypes=rsa-sha2-256,ecdsa-sha2-nistp256,[email protected],ecdsa-sha2-nistp384,[email protected],rsa-sha2-512,ecdsa-sha2-nistp521,[email protected],ssh-ed25519,[email protected],ssh-rsa,[email protected]

So the sshd process ID (PID) is 5130. That means I can use /proc filesystem to learn quite a bit about the process:

root@redhat:/ # cd /proc/5130
root@redhat:/proc/5130 # ls
 attr        cmdline          environ  io         mem         ns             pagemap      sched      smaps_rollup  syscall        wchan
 autogroup   comm             exe      limits     mountinfo   numa_maps      patch_state  schedstat  stack         task
 auxv        coredump_filter  fd       loginuid   mounts      oom_adj        personality  sessionid  stat          timers
 cgroup      cpuset           fdinfo   map_files  mountstats  oom_score      projid_map   setgroups  statm         timerslack_ns
 clear_refs  cwd              gid_map  maps       net         oom_score_adj  root         smaps      status        uid_map

Each file or directory in this /proc/5130 location shows some information specific to this PID 5130.

For instance, if we list files in the fd directory there, we’ll see all the files and sockets open by sshd at the moment:

root@redhat:/proc/5130 # ls -al fd/*
 lr-x------. 1 root root 64 Oct  3 14:10 fd/0 -> /dev/null
 lrwx------. 1 root root 64 Oct  3 14:10 fd/1 -> 'socket:[39555]'
 lrwx------. 1 root root 64 Oct  3 14:10 fd/2 -> 'socket:[39555]'
 lr-x------. 1 root root 64 Oct  3 14:10 fd/3 -> /dev/urandom
 lr-x------. 1 root root 64 Oct  3 14:10 fd/4 -> /var/lib/sss/mc/passwd
 lrwx------. 1 root root 64 Oct  3 14:10 fd/5 -> 'socket:[45446]'
 lrwx------. 1 root root 64 Oct  3 14:10 fd/6 -> 'socket:[45450]'
 lr-x------. 1 root root 64 Oct  3 14:10 fd/7 -> /var/lib/sss/mc/group
 lrwx------. 1 root root 64 Oct  3 14:10 fd/8 -> 'socket:[45452]'

TODO: I’ll be sure to write a separate post on the /proc filesystem with more thorough walkthrough.

Show Process Limits Using /proc

One of the files in /proc subdirectories is file called limits, and it’s super useful for confirming the current OS limits applied to the process in question.

So for the sshd process with PID 5130, here’s what we can see:

root@redhat:/proc/5130 # cat limits
 Limit                     Soft Limit           Hard Limit           Units
 Max cpu time              unlimited            unlimited            seconds
 Max file size             unlimited            unlimited            bytes
 Max data size             unlimited            unlimited            bytes
 Max stack size            8388608              unlimited            bytes
 Max core file size        unlimited            unlimited            bytes
 Max resident set          unlimited            unlimited            bytes
 Max processes             127372               127372               processes
 Max open files            1024                 4096                 files
 Max locked memory         16777216             16777216             bytes
 Max address space         unlimited            unlimited            bytes
 Max file locks            unlimited            unlimited            locks
 Max pending signals       127372               127372               signals
 Max msgqueue size         819200               819200               bytes
 Max nice priority         0                    0
 Max realtime priority     0                    0
 Max realtime timeout      unlimited            unlimited            us

Basically, this confirms that I haven’t fine-tuned anything on this new desktop just yet – open files count of 1024 is small cause it’s not a server that requires serving multiple files simultaneously.

Hope you find this useful!

Attach Interface to Specific Firewall Zone in RHEL 8

One of the first things I had to do on my recently built RHEL 8 PC was to move the primary network interface from public (default) zone to home zone – to make sure any firewall ports I open stay private enough.

How To List Which Zones and Interfaces are Active

Using the get-active-zones option of the firewall-cmd command, it’s possible to confirm where eno1 interface is at the moment. It’s already in the home zone cause I made the update earlier:

root@redhat:~ # firewall-cmd --get-active-zones
home
  interfaces: eno1
libvirt
  interfaces: virbr0

Attach Interface to a Firewall Zone

Here’s how one can move specified interface into a zone we want:

root@redhat:~ # firewall-cmd --zone=home --change-interface=eno1
success

Just to show how it works, I’m going to move eno1 into public zone and back to home one:

root@redhat:~ # firewall-cmd --zone=public --change-interface=eno1
success
root@redhat:~ # firewall-cmd --get-active-zones
libvirt
  interfaces: virbr0
public
  interfaces: eno1

Making Sure Firewall Changes Are Permanent

Don’t forget that after confirming a working firewall configuration, you need to re-run the same command with permanent option – this will update necessary files to make sure your firewall changes can survive a reboot:

root@redhat:~ # firewall-cmd --zone=home --change-interface=eno1 --permanent
The interface is under control of NetworkManager, setting zone to 'home'.
success

That’s it for today. Am really enjoying RHEL 8 configuration and still have this feeling I barely scratch the surface with all the new improvements this Red Hat Enterprise Linux brings.

How To Show LUKS Passphrase Slots

As you might know, it’s possible to add multiple passphrases to the same LUKS encrypted filesystem. This means each one of these will allow you to decrypt and to mount your filesystem.

Show LUKS Key Slots

This is how you can check how many passphrases or file-based keys are currently in use for managing access to your encrypted filesystem:

root@rhel8:~ # cryptsetup luksDump /dev/rhel/06
 LUKS header information for /dev/rhel/06
 Version:           1
 Cipher name:       aes
 Cipher mode:       xts-plain64
 Hash spec:         sha256
 Payload offset:    4096
 MK bits:           512
 MK digest:         85 84 e1 49 0f c3 7f df 9b fd 62 a0 50 c9 2a 14 a8 86 a8 0e
 MK salt:           58 e4 20 ed ac 01 56 cf cb b7 77 1d c6 11 20 6f
                    4c f2 fd 3a c5 c3 d4 f0 64 41 84 4c f9 58 a2 2f
 MK iterations:     87614
 UUID:              9144c0fe-7758-47ac-886b-330ae8bfa096
 Key Slot 0: ENABLED
     Iterations:             1418912
     Salt:                   65 fd 6c 78 84 7d 1b ae d1 42 13 0b f3 4c f7 41
                             9b 5f d5 e3 6e c5 a2 ce 05 28 02 f1 9b 56 07 b9
     Key material offset:    8
     AF stripes:             4000
 Key Slot 1: DISABLED
 Key Slot 2: DISABLED
 Key Slot 3: DISABLED
 Key Slot 4: DISABLED
 Key Slot 5: DISABLED
 Key Slot 6: DISABLED
 Key Slot 7: DISABLED

As you can see, only Key Slot 0 is ENABLED and reporting some setup details. This means I’m only using one passphrase for my encrypted filesytem.

If and when I add more passphrases or encryption keys, they will be occupying next available slot, starting with key slot 1.

Confirm Firewall Configuration in RHEL 8

I’m fascinated by the improvements and new features in RHEL 8, plus it’s a primary distro used in most corporate environments – so expect to quite a number of posts related to it in the nearest future.

The default interface for managing firewalls in RHEL 8 is firewalld and specifically firewall-cmd command.

Show Active Zones in RHEL 8

There’s a concept of zones – security domains – in RHEL 8 firewalls. You assign each of available network interfaces on your Red Hat Enterprise Linux system to one or more of these domains.

That’s why the first step is to confirm these zones, to see which ones are actively managing access for each network device:

root@rhel8:~ # firewall-cmd --get-active-zones
home
  interfaces: enp2s0
libvirt
  interfaces: virbr0

List All Rules for Firewall Zone in RHEL 8

I’m interested in the primary physical network interface – enp2s0. It belongs to the home zone as per previous command, so that’s the zone we’ll list all the rules fore:

root@rhel8:~ # firewall-cmd --list-all --zone=home
home (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp2s0
  sources: 
  services: cockpit dhcpv6-client mdns samba-client ssh
  ports: 5901/tcp
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:

From the output below, I have highlighted additionally enabled ports – 5901 is the one for VNC client that allows me to access graphics desktop session on my RHEL 8 PC remotely.

That’s it for today! Thanks for stopping by and talk soon!

Skip Gathering Facts in Ansible

There are Ansible playbooks which depend on the most up-to-date information found on each node. That’s where fact gathering is a much needed help. But there are also simpler more predefined playbooks, which don’t need fact gathering and can therefore gain performance if no facts are collected.

Why Fact Gathering in Ansible Takes Time

Fact gathering means Ansible runs a number of commands to confirm the most recent values for important indicators and parameters.

Run against my freshly installed RHEL 8 based PC, this takes roughly 4 seconds. Part of this can be to how RHEL is configured (and that it’s still a work in progress), but part of this amount of time is defined by the sheer number of facts: more than 1000!

Typical Facts Collected By Ansible

This is not a complete list, I’m just giving you examples to indicate why facts collection may be time consuming:

hardware parameters of remote system
storage devices (types, models, sizes, capabilities)
filesystems and logical volume managers (objects, types, sizes)
OS distro information
network devices and full list of their capabilities
environment variables

Disable Fact Gathering in Ansible

Since I don’t really need to re-establish hardware specs or logical volumes layout of my RHEL 8 desktop every time I run some Ansible post-configuration, I decided to disable fact gathering and shave 4-5 sec at the start of each playbook run.

Simply specify this at the top of your Ansible playbook:

gather_facts: no

In on of my playbooks, this is how it looks:

---
- name: Baseline
  hosts: desktops
  gather_facts: no

This really made a noticeable difference. Have fun!

Advanced USB discovery with usb-devices

Using usb-devices Command

Understanding usb-devices Output

See Also

systemd services Status

SystemD services

Show systemd Services Status with systemctl

See Also

Confirm Actively Listening TCP Ports with lsof

What does it mean for port to LISTEN?

Meaningful TCP ports reporting vs Default

Use lsof to show listening TCP ports

Don’t Forget to run lsof with sudo!

Confirming what process is listening on a specific port

See Also

Protecting Directories with Sticky Bit

What is a sticky bit?

How sticky bit for a directory looks

How sticky bit works

Sticky Bit Clarifications

See Also

preserve-root flag for rm command

What preserve-root Flag Does

Why preserve-root is Really Useful

See Also

Show Process Limits Using /proc Filesystem

Show Process Info Using /proc

Show Process Limits Using /proc

See Also

Attach Interface to Specific Firewall Zone in RHEL 8

How To List Which Zones and Interfaces are Active

Attach Interface to a Firewall Zone

Making Sure Firewall Changes Are Permanent

See Also

How To Show LUKS Passphrase Slots

Show LUKS Key Slots

See Also

Confirm Firewall Configuration in RHEL 8

Show Active Zones in RHEL 8

List All Rules for Firewall Zone in RHEL 8

See Also

Skip Gathering Facts in Ansible

Why Fact Gathering in Ansible Takes Time

Typical Facts Collected By Ansible

Disable Fact Gathering in Ansible

See Also