This is the second article on the UNIX Health Check blog that discusses security awareness.

This article is all about WiFi security, and the ability of others to scan WiFi network information. For the purpose of this article, we'll be using Kali Linux. In the first article we discussed setting up a Kali Linux Live USB environment for this purpose.

Kali Linux, generally regarded as the de facto standard package of tools used to facilitate penetration testing to secure data and voice networks, comes with many pre-installed tools. One of those tool-sets is AirCrack-ng, which is a complete suite of tools to assess WiFi network security. We'll be looking at and using some of these tools in this article.

To prepare, start up a computer with the Kali Linux Live USB operating system.

Also make sure that the computer has a functional wireless interface. For purposes of using the AirCrack-ng tools, a good wireless interface is required. Please note that not all wireless devices are the same. The capabilities of a wireless device differ very much on the chipset used within a wireless device. A good and relatively cheap wireless interface is the Alpha AWUS036NH, which comes with a USB interface that can easily be plugged into any computer. This particular WiFi USB device is capable of high transmit power, and also allows to be configured in so-called Master mode, allowing it to function as an Access Point, which we'll be using in future articles. A good overview of wireless devices and their capabilities can be found at https://wikidevi.com/wiki/Wireless_adapters/Chipset_table.

Once the Kali Live system has booted, investigate which wireless interfaces are available. Good tools for this purpose are airmon-ng and iwconfig:

# airmon-ng

PHY   Interface   Driver      Chipset

phy0  wlan0       iwlwifi     Intel Corporation Wireless 7260 (rev 73)
phy1  wlan1       rt2800usb   Ralink Technology, Corp. RT2870/RT3070
phy2  wlan2       rt2800usb   Ralink Technology, Corp. RT5370

# iwconfig
wlan0   IEEE 802.11  ESSID:off/any
        Mode:Managed  Access Point: Not-Associated   Tx-Power=22 dBm
        Retry short limit:7  RTS thr:off   Fragment thr:off
        Encryption key:off
        Power Management:off

wlan1   IEEE 802.11  ESSID:off/any
        Mode:Managed  Access Point: Not-Associated   Tx-Power=20 dBm
        Retry short  long limit:2  RTS thr:off   Fragment thr:off
        Encryption key:off
        Power Management:on

wlan2   IEEE 802.11  ESSID:off/any
        Mode:Managed  Access Point: Not-Associated   Tx-Power=20 dBm
        Retry short  long limit:2  RTS thr:off   Fragment thr:off
        Encryption key:off
        Power Management:off

# ifconfig wlan1 down
# iwconfig wlan1 mode monitor
# ifconfig wlan1 up
# iwconfig wlan1
wlan1   IEEE 802.11  Mode:Monitor  Frequency:2.462 GHz  Tx-Power=20 dBm
        Retry short  long limit:2  RTS thr:off   Fragment thr:off
        Power Management:off

# airmon-ng start wlan1

# airmon-ng check wlan1

# airmon-ng check kill

# systemctl status NetworkManager

# systemctl stop NetworkManager

[keyfile]
unmanaged-devices=mac:00:0f:60:01:07:4c

# systemctl restart NetworkManager

# airodump-ng wlan1

BSSID               PWR  Beacons  #Data  #/s  CH   MB   ENC  CIPHER  AUTH  ESSID
B0:26:80:83:79:C0   -28      248     40    0   6  195  WPA2    CCMP   PSK  attwifi

# airmon-ng --channel 6 --bssid B0:26:80:83:79:C0 wlan1

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.

# dd if=kali-linux-2018.3a-amd64.iso of=/dev/sdb bs=512k

# parted /dev/sda mkpart primary 4gb 8gb

# 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

# reboot

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

# openssl rand -base64 9

Red Hat provides you the opportunity to download a KVM guest image, that you can use within virt-manager to start immediately. This saves you the trouble and time of having to install the operating system.

However, the root password is not known, and so, it may be difficult to log in as root when using the KVM guest image provided by Red Hat.

Luckily, there is an easy solution to changing the root password on a KVM guest image.

Start by installing guestfish:

# yum -y install guestfish

# cd /var/lib/libvirt/images
# virt-customize -a rhel7.5.beta1.qcow2 --root-password password:PASSWORD

Whenever you have to connect through SSH to a lot of different servers, and you create a command for it like this:

# for h in $SERVER_LIST; do ssh $h "uptime"; done

The authenticity of host 'myserver (1.2.3.4)' can't be established.
RSA key fingerprint is .....
Are you sure you want to continue connecting (yes/no)?

ssh -oStrictHostKeyChecking=no $h uptime

Security Enhanced Linux, or short SELinux, is by default enabled on Red Hat Enterprise (and alike) Linux systems.

To determine the status of SELinux, simply run:

# sestatus

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=enforcing

SELINUX=permissive

A way to create a random password yourself is using a password generator. The pwmake is a command-line tool for generating random passwords that consist of all four groups of characters: uppercase, lowercase, digits and special characters.

The utility allows you to specify the number of entropy bits that are used to generate the password. The entropy is pulled from /dev/urandom. The minimum number of bits you can specify is 56, which is enough for passwords on systems and services where brute force attacks are rare. 64 bits is adequate for applications where the attacker does not have direct access to the password hash file (/etc/shadow). For situations when the attacker might obtain the direct access to the password hash or the password is used as an encryption key, 80 to 128 bits should be used. If you specify an invalid number of entropy bits, pwmake will use the default of bits.

To create a password of 128 bits, enter the following command:

# pwmake 128
*oLhezv@Hal7YmUM;Igqilur0N&

If you run into a system that you can't access, but is available on the network, and have no idea what type of system that is, then there are few tricks you can use to determine the type of system remotely.

The first one, is by looking at the TTL (Time To Live), when doing a ping to the system's IP address. For example, a ping to an AIX system may look like this:

# ping 10.11.12.82
PING 10.11.12.82 (10.11.12.82) 56(84) bytes of data.
64 bytes from 10.11.12.82 (10.11.12.82): icmp_seq=1 ttl=253 time=0.394 ms
...

# nmap -O -v 10.11.12.82 | grep OS
Initiating OS detection (try #1) against 10.11.12.82 (10.11.12.82)
OS details: IBM AIX 5.3
OS detection performed.

# snmpinfo -h 10.11.12.82 -m get -v sysDescr.0
sysDescr.0 = "IBM PowerPC CHRP Computer
Machine Type: 0x0800004c Processor id: 0000962CG400
Base Operating System Runtime AIX version: 06.01.0008.0015
TCP/IP Client Support  version: 06.01.0008.0015"

Here's how you can set up your /etc/profile in order to create a separate shell history file for each user and each login session. This is very useful when you need to know who exactly ran a specific command at a point in time. For Red Hat Linux, put the updates in either /etc/profile or /etc/bashrc.

Put this in /etc/profile on all servers:

# HISTFILE
# execute only if interactive
if [ -t 0 -a "${SHELL}" != "/bin/bsh" ]
then
 d=`date "+%H%M.%m%d%y"`
 t=`tty | cut -c6-`
 u=`who am i | awk '{print $1}'`
 w=`who -ms | awk '{print $NF}' | sed "s/(//g" | sed "s/)//g"`
 y=`tty | cut -c6- | sed "s/\//-/g"`
 mkdir $HOME/.history.$USER 2>/dev/null
 export HISTFILE=$HOME/.history.$USER/.sh_history.$USER.$u.$w.$y.$d
 find $HOME/.history.$USER/.s* -type f -ctime +91 -exec rm {} \; 2>/dev/null

 H=`uname -n | cut -f1 -d'.'`
 mywhoami=`whoami`
 if [ ${mywhoami} = "root" ] ; then
  PS1='${USER}@(${H}) ${PWD##/*/} # '
 else
  PS1='${USER}@(${H}) ${PWD##/*/} $ '
 fi
fi

# Time out after 60 minutes
# Use readonly if you don't want users to be able to change it.
# readonly TMOUT=3600
TMOUT=3600
export TMOUT

# Added for extended shell history
EXTENDED_HISTORY=ON

HISTTIMEFORMAT='%F %T '; export HISTTIMEFORMAT

# export HISTFILE=.sh_history.root.user.10.190.41.116.pts-4.1706.120210

# ksh "fc -t -10"

By default, when using sudo, the env_reset sudo option is enabled.

From the sudoers manual, about the env_reset sudo option:

This causes commands to be executed with a new, minimal environment. On AIX the environment is initialized with the contents of the /etc/environment file. The new environment contains the TERM, PATH, HOME, MAIL, SHELL, LOGNAME, USER, USERNAME and SUDO_* variables in addition to variables from the invoking process permitted by the env_check and env_keep options. This is effectively a whitelist for environment variables.

If, however, the env_reset option is disabled, any variables not explicitly denied by the env_check and env_delete options are inherited from the invoking process. In this case, env_check and env_delete behave like a blacklist. Since it is not possible to blacklist all potentially dangerous environment variables, use of the default env_reset behavior is encouraged.

In all cases, environment variables with a value beginning with () are removed as they could be interpreted as bash functions. The list of environment variables that sudo allows or denies is contained in the output of "sudo -V" when run as root.

So, what does this all mean? Well, it means that you should not use env_reset in the /etc/sudoers file.

First of all, if you would use:

Defaults env_reset

Defaults !env_reset

$ sudo tcpdump -i en12
tcpdump: bpf_load: genmajor failed: A file or directory in the path name does not exist.

User_Alias           UTCPDUMP = tim, john
Defaults:UTCPDUMP    !env_reset

Defaults env_keep += ODMDIR