Topics: Security

Kali Linux Bootable USB drive

This is the first article in a series of security awareness articles. The first few articles will focus initially on WiFi security.

For the purposes of hacking, people often tend to use the Kali distribution of Linux, which is generally regarded as the de facto standard package of tools used to facilitate penetration testing to secure data and voice networks. It was developed by Mati Aharoni and Devon Kearns of Offensive Security.

This article will focus on creating a bootable USB drive containing Kali Linux, allowing one to boot up a computer from USB with Kali Linux. The original documentation can be found at and

For this article, you will need a Windows based computer and a USB drive of at least 8 GB.

Start of by downloading the 64 bit ISO image file from Select the very first 3 GB file, named "Kali Linux 64bit" for amd64 based systems, assuming you will be using a 64 bit computer. Then, insert a USB drive into the computer of at least 8 GB.

Download Win32 Disk Imager from Note that this tool doesn't work on Windows if you have a RAM disk and/or Encrypted disk configured on your system. If you do, then unmount these first. Use the Win32 Disk Imager tool to write the Kali ISO image file to the USB drive. Writing the ISO file takes a few minutes.

As an alternative, you can also download the ISO image file on a Linux system, and use the dd command to write the ISO image file to the USB drive. For example, assuming the USB device on Linux is /dev/sdb, and the ISO image file is called kali-linux-2018.3a-amd64.iso, run:
# dd if=kali-linux-2018.3a-amd64.iso of=/dev/sdb bs=512k
At this point, you can boot up Kali Linux from the USB drive. It may be necessary to change the boot order in the BIOS of the computer to boot from the USB drive (instead of the internal hard drive) first. The default password for the root user of Kali Linux is "toor".

What has been created at this point is an operating system that you can use normally. You will notice however, that once you shut down and restart Kali Linux, that any changes you have made, will be gone. This is due to it not having any persistent storage, and thus losing all the changes mades once the operating system has been shut down or restarted.

There is a way to create a persistent Kali Linux USB setup:

Fist, boot Kali Linux from the USB drive you have prepared above. Run "lsblk" to identify which drive the USB drive is, for example /dev/sda. By looking at the output of the lsblk command, you can see that about 3.7 GB is in use for two different partitions. We'll be creating an additional partition for the persistent storage. Just to be safe, we'll create a new partition of 4 GB, starting at a location 4 GB through 8 GB on the USB drive:
# parted /dev/sda mkpart primary 4gb 8gb
This will create a new partition called /dev/sda3. You can see this by running lsblk again. Next, create a file system on the new partition:
# mkfs.ext3 -L persistence /dev/sda3
# e2label /dev/sda3 persistence
Now create a mount point, mount the new partition there, and then create the configuration file to enable persistence. Finally, unmount the partition:
# mkdir -p /mnt/my_usb
# mount /dev/sda3 /mnt/my_usb
# echo "/ union" > /mnt/my_usb/persistence.conf
# umount /dev/sda3
Next, reboot the system, and boot the Kali Linux Live persistence option:
# reboot
From now on it will be possible to write to the file systems, and changes will be maintained. The downside of creating a persistent USB version of Kali Linux is however, that the OS becomes slower, because it is now writing to the USB drive, which isn't that fast as writes to memory.

There's also a method for creating an encrypted version of the persistent Kali Live Linux USB drive, which is described in more detail at

Topics: Red Hat

Preventing Gnome's initial setup

The first time a user logs into the default desktop (Gnome) for Red Hat version 7 based systems, they're prompted to set a language, add online accounts, and dropped into a help menu right from the start. While this might be nice for brand new users, it's certainly not ideal for everyone.

There is a very simple way to prevent this annoyance, by simple removing package gnome-initial-setup:

# yum -y erase gnome-inital-setup

Topics: Red Hat, Scripting

Bash scripting: SSH breaks out of while-loop

If you use a bash shell script that does an ssh command within a while-loop, you may encounter that the ssh command will break out of the while-loop, and that the script doesn't complete all the intended ssh commands. An example of a script is below:

# cat hostsfile
# cat script
cat hostsfile | while read server ; do
        echo $server
        ssh $server uptime
# ./script
 16:19:22 up 11 days, 22:30,  0 users,  load average: 0.00, 0.01, 0.05
As you can see in the example above; the script should run a ssh command for all files in the file "hostsfile". Instead, it stops after the first one.

This can be very easily resolved, by adding the "-n" option for the ssh command, as follows:
# cat script
cat hostsfile | while read server ; do
        echo $server
        ssh -n $server uptime
# ./script
 16:19:22 up 11 days, 22:30,  0 users,  load average: 0.00, 0.01, 0.05
 15:20:56 up 11 days, 22:32,  0 users,  load average: 0.00, 0.00, 0.00

Topics: Red Hat, Storage

Using tmp.mount

If you've ever looked at the /tmp file system on a RHEL system, you may have noticed that it is, by default, simply a folder in the root directory.

For example:

# df -h /tmp
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/centos-root  100G  4.6G   96G   5% /
The risk of having this is, that anyone can fill up the root file system, by writing temporary data to the /tmp folder, which is risky for system stability.

Red Hat Enterprise Linux 7 offers the ability to use /tmp as a mount point for a temporary file storage system (tmpfs), but unfortunately, it is not enabled by default.

When enabled, this temporary storage appears as a mounted file system, but stores its content in volatile memory instead of on a persistent storage device. And when using this, no files in /tmp are stored on the hard drive except when memory is low, in which case swap space is used. This also means that the contents of /tmp are not persisted across a reboot.

To enable this feature, execute the following commands:
# systemctl enable tmp.mount
# systemctl start tmp.mount
RHEL uses a default size of half the memory size for the in-memory /tmp file system. For example on a system with 16 GB of memory, an 8 GB /tmp file system is set up after enabling the tmp.mount feature:
# df -h /tmp
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/centos-root  100G   53G   48G  53% /
# systemctl enable tmp.mount
# systemctl start tmp.mount
# df -h /tmp
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           7.8G     0  7.8G   0% /tmp
By having this in place, it's no longer possible to fill up the root file system, when writing files and/or data to the /tmp file system. The downside, however, is that this uses memory, and when filling up the memory, may be using the swap space. As such, having a dedicated file system on disk for the /tmp folder is still the better solution.

Topics: Red Hat

Convert Red Hat Enterprise Linux to Oracle Linux

Why would you convert an existing Red Hat or CentOS system to Oracle Linux?

Well, there aren't huge advantages, but a few:

  • If you would like to use Oracle Linux technical support. Oracle Linux licensing is supposedly cheaper than that of Red Hat, but please do verify first, it that's the case for your organization as well.
  • Oracle Linux updates are more frequent than CentOS, but actually slower than Red Hat.
If you want the Oracle sales pitch, check here.

Oracle Linux is binary compatible with RHEL and with CentOS, so using your organization's existing applications should not be a problem on Oracle Linux.

When you've decided it's time to convert, then here's how to do it:

First, create a backup of your system and make sure the backup is successful. Don't skip this step.

Configure the Oracle Linux Yum repository (see:, for example for Red Hat version 7:
# cd /etc/yum.repos.d
# wget
Configure the Oracle Linux GPG Key (see:, for example for Red Hat version 7:
# wget \
-O /etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
# gpg --quiet --with-fingerprint /etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
Configure the Oracle pre-install package:
# yum install oracle-rdbms-server-12cR1-preinstall -y
Run a full update:
# yum update -y
# reboot
If you wish to convert a CentOS system to Oracle Linux, that can be done too, as follows:
# curl -O
# sh
Make sure all of the packages are synced up with the Oracle Linux repository:
# yum distro-sync
No need to reboot afterwards, however, it is recommended to do so, to make sure the system comes back up normally after a reboot.

Topics: Red Hat

Disable NUMA on RHEL version 7

This article is based on: and describes how to disable NUMA on a Red Hat version 7 based system.

Edit file /etc/default/grub, and add "numa=off" to the GRUB_CMDLINE_LINUX, for example:

GRUB_CMDLINE_LINUX="crashkernel=auto rhgb
quiet transparent_hugepage=never numa=off"
Rebuild the grub config:
# grub2-mkconfig -o /etc/grub2.cfg
Then reboot:
# reboot

Topics: AIX, Red Hat, Security

Generate a random password

The following command will generate a random password of 9 characters:

# openssl rand -base64 9

Topics: Red Hat, Storage

Setting up a Volume Group and File Systems on RHEL

This procedure describes how to set a new volume group and file systems on a Red Hat Enterprise Linux system.

First, we'll need to make sure that there is storage available on the system that can be allocated to a new volume group. For this purpose, run the lsblk command:

# lsblk | grep disk
In the output, for example, you may see:
# lsblk | grep disk
fd0       2:0      1    4K  0 disk
sda       8:0      0   60G  0 disk
sdb       8:16     0    5T  0 disk
In the example above, the system has two SCSI devices (that start with "sd"), called sda and sdb. Device sda is 60 GB, and device sdb is 5 TB.

Next, run this command:
# lsblk -a
It will provide you with a tree-like output showing all the disks available on the system, and any partitions (listed as "part") and logical volumes (listed as "lvm") configured on those disks. For the sake of this example, we'll assume that on device sdb there are no partitions and or logical volumes configured, and thus is available.

Also, for the sake of this example, we'll assume that we'll want to set up a few file systems for an Oracle environment, called /u01, /u02, /u03, /u04 and /u05, and that we'll want to have these file systems configured within a volume group called "oracle".

List the volume groups already configured on the system:
# vgs
Make sure there isn't already a volume group present that is called oracle.

Now, let's create a new volume group called oracle, using device sdb:
# vgcreate oracle /dev/sdb
  Physical volume "/dev/sdb" successfully created.
  Volume group "oracle" successfully created
We can now use the "vgs" and "pvs" commands to list the volume groups and the physical volumes on the system. Note in the output that you now can see that a volume group called "oracle" is present, and that disk /dev/sdb is configured in volume group "oracle".

Now create the logical volumes. A logical volume is required for us to create the file systems in later on. We'll be creating the following logical volumes:
  • u01lv of 100 GB for the use of the /u01 file system
  • u02lv of 1.5 TB for the use of the /u02 file system
  • u03lv of 1.5 TB for the use of the /u03 file system
  • u04lv of 1.5 TB for the use of the /u04 file system
  • u05lv of 300 GB for the use of the /u05 file system
Run the following commands to create the logical volumes. You may run the "lvs" command before, in between and after each command to see your progress.
# lvcreate -n u01lv -L 100G oracle
# lvcreate -n u02lv -L 1.5T oracle
# lvcreate -n u03lv -L 1.5T oracle
# lvcreate -n u04lv -L 1.5T oracle
# lvcreate -n u05lv -L 300G oracle
# lvs | grep oracle
  u01lv oracle -wi-a----- 100.00g
  u02lv oracle -wi-a-----   1.50t
  u03lv oracle -wi-a-----   1.50t
  u04lv oracle -wi-a-----   1.50t
  u05lv oracle -wi-a----- 300.00g
Now it's time to create the file systems. We'll be using the standard XFS type of file system:
# mkfs.xfs /dev/oracle/u01lv
# mkfs.xfs /dev/oracle/u02lv
# mkfs.xfs /dev/oracle/u03lv
# mkfs.xfs /dev/oracle/u04lv
# mkfs.xfs /dev/oracle/u05lv
And now that the file systems have been created on top of the logical volumes, we can mount the file systems. To ensure that file systems are mounted at the time that the system boots up, it's best to add the new file systems to file /etc/fstab. Add the following lines to that file:
/dev/oracle/u01lv      /u01     xfs      defaults,noatime 0 0
/dev/oracle/u02lv      /u02     xfs      defaults,noatime 0 0
/dev/oracle/u03lv      /u03     xfs      defaults,noatime 0 0
/dev/oracle/u04lv      /u04     xfs      defaults,noatime 0 0
/dev/oracle/u05lv      /u05     xfs      defaults,noatime 0 0
Make sure the folders of the mount points exist by creating them:
# mkdir /u01
# mkdir /u02
# mkdir /u03
# mkdir /u04
# mkdir /u05
Now mount all the file systems at once:
# mount -a
And then verify that the file systems are indeed present:
# df -h | grep u0
/dev/mapper/oracle-u01lv  100G   33M  100G   1% /u01
/dev/mapper/oracle-u02lv  1.5T   33M  1.5T   1% /u01
/dev/mapper/oracle-u03lv  1.5T   33M  1.5T   1% /u01
/dev/mapper/oracle-u04lv  1.5T   33M  1.5T   1% /u01
/dev/mapper/oracle-u05lv  300G   33M  300G   1% /u01
And that's it. The file systems have been created, and these file systems will persist during a system reboot.

Topics: Monitoring, Red Hat

Monitoring a log file through Systemd

The following procedure describes how you can continuously monitor a log file through the use of SystemD on Red Hat Enterprise Linux (or similar operating systems).

Let's say you want to receive an email when a certain string occurs in a log file. For example, if the string "error" occurs in file /var/log/messages.

First, create a script that does a tail of /var/log/messages and searches for that string:

# cat /usr/local/bin/monitor.bash

tail -fn0 /var/log/messages | while read line ; do
   echo "${line}" | grep -i "error" > /dev/null
   if [ $? = 0 ] ; then
      echo "${line}" | mailx -s "error in messages file"
You can run that script, and be done with it. But if that script somehow gets cancelled or killed, for example when the system is rebooted, then the monitoring of the log file stops as well. That's where the use of Systemd comes in.

Create a file in folder /etc/systemd/system, such as "monitor.service", and add the following:
Description=My monitor script

ExecStart=/bin/bash /usr/local/bin/monitor.bash

This file is a description of a service managed by Systemd, and it basically tells SystemD to run the script that we created earlier, and to restart it, in case it fails (that's what "Restart=always" is for).

Next, you'll have to tell Systemd that you made some changes:
# systemctl daemon-reload
Now you can start the newly defined service:
# systemctl start monitor.service
And after starting it, you can query the status:
# systemctl status monitor.service
monitor.service - My monitor script
   Loaded: loaded (/etc/systemd/system/monitor.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2018-10-03 12:12:28 CDT; 2s ago
 Main PID: 1832 (bash)
   CGroup: /system.slice/monitor.service
           ??1832 /bin/bash /usr/local/bin/monitor.bash
           ??1833 tail -fn0 /var/log/messages
           ??1834 /bin/bash /usr/local/bin/monitor.bash

Oct 03 12:12:28 enemigo systemd[1]: Started My monitor script.
Oct 03 12:12:28 enemigo systemd[1]: Starting My monitor script...
As you can see in the output above, both the monitor.bash script and the tail command are running. To test if the service is actually restarted, you can try killing the tail process or the monitor.bash script, and then check for the status again. You'll see it is restarted.

You may also want to test that the new monitor script indeed is working. Considering that /var/log/messages is a file written to through rsyslog, you can log an entry with the string "error" to that file as follows:
# logger error
Next, you should receive an email saying that an "error" occurrence was found in the messages file.

Finally, you'll want to make sure this new monitor service is restarted also when the system boots:
# systemctl enable monitor.service

Topics: AIX

How to Configure Sendmail not to Look up MX records

A default sendmail configuration will do DNS queries for MX records. It does this even when its setup to use a Mail Relay Server for sending mail out. This will cause mail to fail if its not able to lookup the MX record, for example when the SMTP relay server is not known in DNS.

Setting up sendmail not to query DNS for MX records when using a DS (Smart Relay) consists of using "[ ]" brackets around the hostname (or IP address) Mail Relay Server configured in the /etc/mail/

To do so, edit the sendmail configuration file:

# vi /etc/mail/
Search for the DS entry. For example:
Change it to:
Then save the configuration file, and refresh sendmail:
# refresh -s sendmail

Number of results found: 452.
Displaying results: 11 - 20.