UNIX Health Check

Entropy

If you run this command on Linux:

# cat /proc/sys/kernel/random/entropy_avail

it returns a number that indicates how much "entropy" is available to the kernel. But what exactly is "entropy", and what unit is this entropy measured in? What is it used for? You may have heard that a low number of entropy is not good. How low is "low" and what "bad" things will happen if it is? What's a good range for it to be at? How is it determined?

Entropy is similar to "randomness". A Linux system gathers "real" random numbers by keeping an eye on different events: network activity, hard drive rotation speeds, hardware random number generator (if available), key-clicks, and so on. If feeds those to the kernel entropy pool, which is used by /dev/random. Applications which use crypto functions, use /dev/random as their entropy source, or in other words, the randomness source.

If /dev/random runs out of available entropy, it's unable to serve out more randomness and the application waiting for the randomness may stall until more random bits are available. On Red Hat Enterprise Linux systems, you can see that RPM package rng-tools is installed, and that a rngd - random nubmer generator deamon - is active. This deamon feeds semi-random numbers from /dev/urandom to /dev/random in case /dev/random runs out of "real" entropy. On Ubuntu based systems, there is no rngd. If more entropy is needed you can install haveged, which can achieve the same. Note that haveged is not available for Red Hat Enterprise Linux based systems, because these systems already have rngd.

Some applications (such as applications using encryption) need random numbers. You can generate random numbers using an algorithm - but although these seem random in one sense they are totally predictable in another. For instance if I give you the digits 58209749445923078164062862089986280348253421170679, they look pretty random. But if you realize they are actually digits of PI, then you may know the next one is going to be 8.

For some applications this is okay, but for other applications (especially security related ones) people want genuine unpredictable randomness - which can't be generated by an algorithm (i.e. program), since that is by definition predictable. This is a problem in that your computer essentially is a program, so how can it possibly get genuine random numbers? The answer is by measuring genuinely random events from the outside world - for example gaps between your key strokes and using these to inject genuine randomness into the otherwise predictable random number generator. The "entropy pool" could be thought of as the store of this randomness which gets built up by the keystrokes (or whatever is being used) and drained by the generation of random numbers.

The value stored in /proc/sys/kernel/random/entropy_avail is the measure of bits currently available to be read from /dev/random. It takes time for the computer to read entropy from its environment. If you have 4096 bits of entropy available and you "cat /dev/random" you can expect to be able to read 512 bytes of entropy (4096 bits) before the file blocks while it waits for more entropy. For example, if you "cat /dev/random" your entropy will shrink to zero. At first you'll get 512 bytes of random garbage, but it will stop and little by little you'll see more random data trickle trough.

This is not how people should operate /dev/random though. Normally developers will read a small amount of data, like 128 bits, and use that to seed some kind of PRNG algorithm. It's polite to not read any more entropy from /dev/random than you need to, since it takes so long to build up entropy, and it is considered valuable. Thus if you drain it by carelessly catting the file like above, you'll cause other applications that need to read from /dev/random to block.

A good number of available entropy is usually between 2500 and 4096 bits. Entropy is considered to be low when it is below 1000.

Topics: Networking, Security ↑

Testing for open ports

Something every system administrator will have to do from time to time, is to test if a certain port is open and reachable over the network.

There are a few ways to go about doing that.

The most common way is to use the nc or ncat or netcat utility. It can easily be used to test a port on a system. For example, to test if port 22 (for ssh) is open on a remote system, run:

# nc -zv systemname 22

Replace "systemname" with the hostname or IP address of the system to be tested. You may also test it locally on a system, by using "localhost".

This will show something like this (if the port is open):

# nc -zv localhost 22
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to ::1:22.
Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.

The nc utility is part of the nmap-ncat RPM package, and can be installed as follows:

# yum -y install nmap-ncat

If installing this utility is not an option, you can also directly test the port, by running this:

# bash -c "</dev/tcp/cielo/22"

If that works, no output is show, and the return-code will be 0 (zero). If it doesn't work, because the port is closed, you'll see an error message, and the return-code will be 1 (one). For example:

# bash -c "</dev/tcp/localhost/23"
bash: connect: Connection refused
bash: /dev/tcp/localhost/23: Connection refused
# echo $?
1

Finally, one other method of testing for open ports, is by using telnet, if it is installed on the system. This can be done by specifying the hostname and the port to connect to:

$ telnet localhost 22
Trying ::1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.4

Topics: Security, System Admin ↑

Using a proxy for wget

If you need to use a proxy for wget, this can be configured as follows:

Either create a file $HOME/.wgetrc (for a specific user) or /etc/wgetrc (to set the proxy configuration for the entire system), and add in the following lines, while replacing the entries below with your HTTP proxy URL and port information:

# You can set the default proxies for Wget to use for http and https.
# They will override the value in the environment.
https_proxy = http://proxy.yoyodyne.com:3128
http_proxy = http://proxy.yoyodyne.com:3128

# If you do not want to use proxy at all, set this to off.
use_proxy = on

Alternatively, you may also use the -e option for wget:

# wget ... -e https_proxy=http://proxy.yoyodyne.com:3128 ...

Topics: Red Hat / Linux, Security ↑

Renew self-signed SSL Certificate

Should the root user receive emails from certwatch about expiring self-signed certificates, like these:

 ################# SSL Certificate Warning ################

  Certificate for hostname 'yourhost', in file (or by nickname):
     /etc/pki/tls/certs/localhost.crt

  The certificate needs to be renewed; this can be done
  using the 'genkey' program.

  Browsers will not be able to correctly connect to this
  web site using SSL until the certificate is renewed.

 ##########################################################
                                  Generated by certwatch(1)

Then, you can run the following command to renew this self-signed certificate for a new year:

# openssl req -new -days 365 -x509 -nodes -out /etc/pki/tls/certs/localhost.crt \ 
-keyout /etc/pki/tls/private/localhost.key

More complete instructions can be found here: http://stevejenkins.com/blog/2010/08/renewing-a-self-signed-ssl-certificate-on-fedoracentos

Topics: Red Hat / Linux, Security ↑

Resetting the Root Password of RHEL-7

In case you've ever forgotten the root password of a RHEL 7 system, here's a good description of how to change it:

https://access.redhat.com/solutions/918283

Topics: Red Hat / Linux, Security ↑

Discovering and joining identity domains on RHEL

The "realm discover" command returns complete domain configuration and a list of packages that must be installed for the system to enrolled in the domain.

The "realm join" command then sets up the local machine for use with a specified domain by configuring both the local system services and the entries in the identity domain. the process run by "realm join" follows these steps:

Running a discovery scan for the specified domain.
Automatic installation of the packages required to join the system to the domain.
This includes SSSD and the PAM home directory job packages. Note that the automatic installation of packages requires the PackageKit suite to be running. If PackageKit is disabled, the system prompts you for the missing packages, and you will be required to install them manually using the "yum" utility.
Joining the domain by creating an account entry for the system in the directory.
Creating the /etc/krb5.keytab host keytab file.
Configuring the domain in SSSD and restarting the service.
Enabling domain users for the system services in PAM configuration and the /etc/nsswicht.conf file.

To install the software manually, run:

# yum install realmd oddjob oddjob-mkhomedir sssd 
# yum install adcli krb5-workstation samba-common-tools

When run without any options, the "realm discover" command displays information about the default DNS domain. It is also possible to run a discovery for a specific domain, such as:

# realm discover mydomain.local

Before this works, make sure the system can access the domain controllers, such as the AD servers. You may have to add those to /etc/resolv.conf, as realmd will use DNS SRV lookups to find the domain controllers in the domain automatically.

To join the domain use the "realm join" command, for example:

# realm join -v - U user mydomain.local

By default, the join is performed as the domain administrator. For AD, the administrator is called "Administrator"; for IdM, it is called "admin". To connect as a different user, use the -U option, as was shown in the example above. When prompted for a password, type it in.

Once the join has been completed, use a separate user account to login to the system, to ensure that domain accounts work.

If you run into issue, make sure that the following ports are opened in the firewall, if present: 53, 389, 636, 88, 464, 3268, 3269 and 123.

For more details on joining a RHEL system to a domain, see: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/windows_integration_guide/realmd-domain.

Topics: Security ↑

Setting up an Access Point using hostapd

This is the fifth article in a series of articles on security awareness, focusing on WiFi security.

In this article, we'll be setting a (rogue) Access Point, which can be very useful for man-in-the-middle attacks.

What's needed?

A computer running Kali Linux. See: ali Linux Bootable USB drive.
A few wireless interfaces, preferably three. One will be used for regular Internet access. One will be used for monitoring WiFi traffic. And the last one will be used for the Access Point. For the purposes of having a good signal, a wireless device that has sufficient power and one that can be switched into managed mode is required. A device that is typically used for this purposes is the Alfa AWUS036NH (2.4 GHz only) or Alpha AWUS052NH (both 2.4 and 5 GHz bands).
Good knowledge on WiFi networks, as described in Scanning WiFi networks.

In this article we'll be setting up an Access Point. As you know, Access Points or routers transmit their WiFi network(s) with a SSID or network name. Some of these names can be very common. For example, in the USA, very common network names are "Google Starbucks" or "attwifi". Many people use these open networks provided by Starbucks and AT&T, and often have these WiFi networks saved onto their devices (phones and laptops) and set to connect automatically. We're going to exploit that to our advantage. Any device such as a phone or laptop that knows about a WiFi network, and has it set to connect automatically, will simply indeed connect automatically to the WiFi, if WiFi is turned on on the device, and if a WiFi network with that name is in range.

So, if you've once visited the local Starbucks and used their open and free WiFi hotspot, and saved that network onto your device and have it set to connect automatically (which quite often is the default behavior), and you then visit another Starbucks later on, your device will connect automatically. And that happens only based on the SSID or network name, which in the case of Starbucks is known "Google Starbucks". A hacker can exploit that by setting his/her own Access Point with the same name.

First step: Install the required software

For the rogue Access Point to work, we'll need 2 items:

hostapd - the Access Point software
dnsmasq - a DHCP server that will provide IP address to any clients

Start up the Kali Linux system, and once logged in as user root, connect the system using one of the WiFi interfaces to the Internet using an existing Wifi Network. You can do so by navigating to the top right of the screen and connect a WiFi network. You can of course, also use a cabled Internet connection.

Then, install the required software:

# apt-get update
# apt-get install dnsmasq hostapd

Step 2: Set up the Access Point

Fist figure out which wireless network device you will be using for the Access Point. Run the "iwconfig" command to see the available wireless network devices. Use a wireless network device that can be switched into Managed mode, and one that has sufficient power. You may even attempt to increase the transmit power, as described here. For this article, we'll assume the wireless network device we'll use for Access Point is wlan1. If you have trouble determining which wireless network device maps to which physical device, try unplugging any USB wireless network devices, and plugging them in one by one, and running "iwconfig" in between.

Set up the configuration file for "hostapd", which defines the Access Point:

interface=wlan1
driver=nl80211
ssid=Google Starbucks
hw_mode=g
channel=4
macaddr_acl=0
ignore_broadcast_ssid=0

In the example above, an Access Point is defined with the network name "Google Starbucks", and it will run on channel 4, using wireless network device wlan1.

Save the file as hostapd.conf.

Within the same folder, start the Access Point:

# hostapd hostapd.conf

If, at this point, you see any errors, then most likely, another process is keeping the wireless network device occupied, usually the Network Manager process. In this article it was already described how to exclude a wireless network device from being managed by NetworkManager. Follow these steps, and you'll see that hostapd can be run without any issues.

When hostapd is running, check on another computer or phone if you can indeed discover a wireless network with the SSID "Google Starbucks".

Setting up a DHCP server

For our Access Point to work, we'll need it to act as a DHCP server as well, by handing out IP addresses to clients that will connect to the Access Point. Without that, the clients won't be able to do anything. For this purpose, we'll be using dnsmasq.

Again, we're going to create a configuration file, this time called dnsmasq.conf. Open a new terminal window and create the file:

interface=wlan1
dhcp-range=192.168.2.2,192.168.2.230,255.255.255.0,12h
dhcp-option=3,192.168.2.1
dhcp-option=6,192.168.2.1
server=8.8.8.8
server=8.8.4.4
log-queries
log-dhcp
listen-address=127.0.0.1
listen-address=192.168.2.1

This configuration file will tell dnsmasq to use the wlan1 device, and start handing out IP addresses in the range of 192.168.2.2 through 192.168.2.230. It will set the subnet mask to 255.255.255.0. It will provide a DHCP lease of 12 hours (12h). We're setting up DNS servers as well by using Google's DNS servers 8.8.8.8 and 8.8.4.4. And we're going to log everything (which by default will be through rsyslog in /var/log/messages).

Save the file. Next, we'll need to configure an IP address on the wireless interface wlan1, so clients can actually communicate to it:

# ifconfig wlan1 up 192.168.2.1 netmask 255.255.255.0
# route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.2.1

Now start the DHCP server:

# dnsmasq -C dnsmasq.conf -d

You may be able to see what the DHCP server is doing by monitoring the screen, or in a separate terminal window, run a command like:

# tail -f /var/log/messages | grep dnsmasq

Next step: Forward traffic

We're not quite there yet. Clients can now discover a WiFI network, and can get an IP address assigned by our Access Point. But in order for the clients to not suspect anything, we'll need to provide Internet access. If you've configured Internet access on one of your wireless network devices, as described in the beginning of this article, then you can do that. Let's assume the wireless network device begin used for the Internet access is wlan0. So wlan0 provides the regular Internet connectivity and wlan1 is being used by the Access Point. If you need to identify which wireless network is used for the Internet access, run "iwconfig". That command will show you if a wireless network device is associated to any SSID/WiFi network, and if so, which one.

Now forward the traffic:

# iptables --table nat --append POSTROUTING --out-interface wlan0 -j MASQUERADE
# iptables --append FORWARD --in-interface wlan1 -j ACCEPT
# echo 1 > /proc/sys/net/ipv4/ip_forward

This will accept any network traffic from wlan1, and forward it to wlan0.

Next: Connect!

Now connect another device such as a phone or laptop to the wireless network called "Google Starbucks". It should connect normally and without any issues. In fact, you may even discover, if that device already knew about the Google Starbucks network, that it connected all by itself.

Next: Start monitoring

The Access Point has now been set up. The DHCP server is handing out IP addresses to any clients that connect, and Internet access is provided to any clients. Effectively, the Access Point now becomes the man-in-the-middle, and all network traffic will flow through the Access Point, and can be monitored. In the terminal screen running "hostapd", you can see if any clients connect. In the terminal window running "dnsmasq" you can see any clients that receive an IP address from the DHCP server, and any DNS queries that these clients do (these are also logged in /var/log/messages). Viewing the DNS queries of any clients will give you some idea of what the user is doing on their device. If you want to see what DHCP IP addresses have been assigned (or "leased") to clients, then run:

# cat /var/lib/misc/dnsmasq.leases

Now sit and wait for any clients to connect. Preferably do this in a location where many people stop by, such as your local coffee shop or a work location. You'll see more and more devices connect by themselves, especially if the location doesn't have any other open WiFi hotspots nearby. If you really want to start discovering what clients are doing, you can monitor their network traffic by running Wireshark, which can provide information about all network packets, but that's beyond the scope of this article.

Also, hostapd allows for multiple Access Points to be set up at the same time. So, if you wish to run two WiFi networks, such as "Google Starbucks" and "attwifi", you can do that too. But again, that's beyond the scope of this article. Should you need to discover what are common WiFi network names in your area, then in yet another terminal window, run the airodump-ng command as described in Scanning WiFi networks. In the bottom section of the output of airodump-ng you can see any client (or "station") information, and also see what names of WiFi networks these clients are probing for. This gives you a good idea about which wireless network names are commonly known on clients, and you can use that information when setting up the Access Point, by listing that network name (SSID) in the hostapd.conf configuration file for hostapd.

Finally: How to protect yourself from all this

You've now gotten a good idea of why using open networks might allow others to see what you're doing. The next obvious question will be: How do you protect yourself from this? Well, there are some options:

Do not use open WiFi networks/hotspots.
If you do use an open WiFi network/hotspot, then remain aware that others can see what you're doing, so hold off on checking your bank account or entering password anywhere.
Visit only websites that are secure - that are using "https:". This means any website traffic is encrypted, and can't be viewed, even when using a packet sniffer like Wireshark. Do not use any websites that are not secure (that are using "http:" instead of "https:".
If you do use an open WiFi network/hotspot, then make sure to disconnect afterwards, and to not have it set to connect automatically when in range.
Use a VPN when connected to a open WiFi network/hotspot. This will encrypt all your network traffic. Keep in mind though that DNS queries are never encrypted, and can still be seen by someone else.

Topics: Security ↑

WiFi jamming

This is the fourth article on the subject of wireless security, focusing on WiFi networks, and this article is about WiFi jamming. Which in fact, is not truly a form of jamming. A true WiFi jammer (such devices to exist) will disrupt or interfere the WiFi signal, making it impossible to reliably send data packets over the WiFi network. A hacker will not accomplish much with this, except that it will render the WiFi network unusable.

In this article, we'll be focusing on WiFi de-authentication. In the WiFi protocol, a special type of packet exists, which is called a de-authentication packet. We will be flooding the target Access Point with de-authentication packets. This will cause the target Access Point to disconnect the wireless clients from the network. So, in fact this "WiFi de-authentication attack" is a type of denial-of-service (DOS) attack. It isn't the actual jamming of radio frequencies.

The reason a hacker might do this, is to deny a client access to a specific Access Point. If the hacker sets up his/her own Access Point using the same WiFi network name (ESSID), then potentially the client may connect to that Access Point instead of the regular Access Point. And if that occurs, the hacker effectively becomes the man-in-the-middle, being able to monitor the clients network traffic. In a later tutorial we'll discuss how to set up your own Access Point using Kali Linux.

What you need to perform a WiFi de-authentication attack, is an installation of Kali Linux and a wireless device that is capable of running in Master mode, such as the Alpha AWUS036NH or TP-Link TL-WN722N.

Once you have started Kali Linux, it involves just 3 steps for the attack:

Enable monitor mode on your wireless interface.
Determine the MAC addresses of the target Access Point and client.
Send de-authentication packets to the Access Point to disconnect one or all clients.

Step 1: Enable monitor mode

Enabling monitor mode on a wireless device was already discussed in the previous article on scanning WiFi networks, so just to recap it here, for example if your wireless interface is called wlan2:

# ifconfig wlan2 down
# iwconfig wlan2 mode monitor
# ifconfig wlan2 up

Step 2: Determining the target MAC addresses

Also discussed in the previous article on scanning WiFi networks, run airodump-ng to discover the Access Points and any clients, for example by running:

# airodump-ng wlan2

In the output listed by the airodump-ng command, you'll see in the top section the MAC addresses of the Access Points available. In the bottom section, you may see any clients connected, and both the MAC addresses of the clients (or stations) and the Access Points (or BSSIDs) will be listed, if clients are indeed connected to an Access Point.

Step 3: Sending de-authentication packets

Once you have determined the MAC address of an Access Point/BSSID to target, for example B0:26:80:83:79:C0, you can flood the target with de-authentication packets, by simply running:

# aireplay-ng -0 0 -a B0:26:80:83:79:C0 wlan2

This will result in de-authenticating any client connected to the Access Point with MAC address B0:26:80:83:79:C0. The "-0 0" instructs aireplay-ng to use attack type 0 (de-authentication) for 0 amount of times (zero means infinite). While the attack is running this will render the WiFi network unusable.

You can also target a specific client connected to an Access Point, for example if the MAC address of the client is 90:C1:15:1C:85:C0:

# aireplay-ng -0 0 -a B0:26:80:83:79:C0 -c 90:C1:15:1C:85:C0 wlan2

This means the client can no longer connect to the Access Point, and maybe, especially if the client knows more wireless networks, it will then connect to a different wireless network.

If you simply want a client to de-authenticate 1 time, in the hopes of it connecting to a rogue Access Point that you have set up yourself, instead you can also use the option "-0 1", to just send 1 single de-authentication packet.

Topics: Security ↑

Increasing wireless transmit power

This is the third article on security awareness, still focusing on WiFi networks.

This article is about increasing the transmit power on a wireless network device within Linux.

For the purposes of having a good reception, and also for having the capability to transmit an adequate signal on a wireless network device, it is important to have the following:

A wireless network device with high power capability, a good antenna and the ability for the device to be configured in Master mode (in this mode it will be capable of transmitting information). A good example is the Alfa AWUS036NH, which is a 2000 mW device, comes with a 5 dBi antenna (which can be replaced easily with a larger one, such as a 9 dBi antenna, if better reception is required) and it comes with a chipset that allows it to be configured in Master mode.
A good location where other Access Points or clients can be sniffed (e.g. in between the client(s) and the Access Point), or where an Access Point will be useful to be set up for clients that will be accessing it.

Specifically, for setting up our own Access Point in a future article in this series, it can be useful to increase the transmit power of the device. By default this is usually set to 20 decibel (dB) or 22 dB. The transmit power is regulated and limited by local laws in countries. In many countries it is not allowed to transmit at higher levels. Some countries however do allow it, and it can be a simple matter of changing the country code for the device, to allow higher transmit power levels. For some more information on this topic, this is described in more detail here.

For example, for wireless device wlan2, you may see a transmit power of 20 dBm by running the "iwconfig" command:

# iwconfig wlan2
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

For higher levels, you may try changing the country code to either Bolivia (BO) or Guyana (GY), where higher transmit levels are allowed. For example, to change it to 30 decibel:

# ifconfig wlan2 down
# iw reg set BO 
# iwconfig wlan2 txpower 30
# ifconfig wlan2 up

Or:

# ifconfig wlan2 down
# iw reg set GY
# iwconfig wlan2 txpower 30
# ifconfig wlan2 up

It may depend on the wireless device what transmit power is allowed, and what will work.

After changing the transmit power, confirm the current setting by running "iwconfig" again:

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

Please note here that changing the transmit power to higher levels than allowed in your country, may mean you are breaking a local law, and thus is not advised. The information provided here is only for educational purposes, and can provide you insight into what a hacker might use.

Number of results found for topic Security: 45.
Displaying results: 1 - 10.

Order

No time to lose? Need to know what's wrong with
your UNIX system now? Then get started TODAY!