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.
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:# yum install realmd oddjob oddjob-mkhomedir sssd # yum install adcli krb5-workstation samba-common-tools
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.# realm discover mydomain.local
To join the domain use the "realm join" command, for example:
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.# realm join -v - U user mydomain.local
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.
If you need to remove a non-root LVM based file system, it can be removed using the following steps. If the file system contains any data, then please make sure to take a backup of that data before proceeding with the following steps.
In this example, we will be deleting "u01lv" from volume group "oracle". The logical volume is mounted on mount point /u01.
As you can see, mount point /u01 is define don logical volume u01lv, and is 200 GB.# df /u01 | grep u01 /dev/ampper/oracle/u01lv 209612800 80946812 128665988 39% /u01 # lvs | grep u01 u01lv oracle -wi-ao---- 200.00g
Start off, by deleting the corresponding entry in /etc/fstab.
Then unmount the file system:# grep u01 /etc/fstab /dev/oracle/u01lv /u01 xfs defaults,noatime 0 0
Disable the logical volume:# umount /u01
Delete the logical volume:# lvchange -an /dev/oracle/u01lv
At this point, depending if this logical volume is defined on a disk within a volume group, you can, if the disk is now empty after removing the logical volume, also remove the disk from the volume group. First run the "pvs" command and check for an empty disk, such as:# lvremove /dev/oracle/u01lv
If the disk is empty, as seen as disk /dev/sdb in the example above, you can then remove it from the volume group:# pvs PV VG Fmt Attr PSize PFree /dev/sdb oracle lvm2 a-- <5.00t <5.00t
Or, if the logical volume removed from the volume group was the very last logical volume to remove, and the volume group is empty, you can also remove the volume group. Do so by disabling the volume group and removing it:# vgreduce oracle /dev/sdb
And then finally remove any physical volumes used, such as /dev/sdb:# vgchange -an oracle # vgremove oracle
# pvremove /dev/sdb
When an Etherchannel has been configured on AIX, using a primary and a backup adapter for failover purposes, it is possible to force a failover between these adapters.
To do this, first check what the currently active adapter is within the Etherchannel. For example, if the Etherchannel is called ent4, run:
As you can see, the Etherchannel is currently active on the backup adapter. To see the defined adapters for both primary and backup, run:# entstat -d ent4 | grep "Active channel" Active channel: backup adapter
Now, force it to fail over to the primary adapter:# lsattr -El ent4
Please note that it is best to run this command from the console, as you may temporarily lose network connectivity when the Etherhannel is failing over. You may also notice messages being logged in the error report by running the errpt command in the form of "ETHERCHANNEL FAILOVER".# /usr/lib/methods/ethchan_config -f ent4
Now run the entstat command again to determine the active channel:
# entstat -d ent4 | grep "Active channel" Active channel: primary channel
Topics: Red Hat / Linux, System Admin↑
XRDP
XRDP is an Open Source Remote Desktop Protocol server, very similar to what is used on Windows Server systems, but XRDP is meant for Linux. Once installed on Linux, you can set up a RDP (or Remote Desktop Connection) session from a Windows system directly to a Linux system.
Here's how you install and configure it on RHEL or CentOS 7:
First of all, we need to install the EPEL repository and XRDP server:
Next, we need to start and enable the service:# yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm # yum -y install xrdp
To check if its running, run:# systemctl start xrdp.service # systemctl enable xrdp.service
That's all. Now you can connect to your server from any Windows machine using RDP.# netstat -an | grep 3389 tcp 0 0 0.0.0.0:3389 0.0.0.0:* LISTEN
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.
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
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:
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.interface=wlan1 driver=nl80211 ssid=Google Starbucks hw_mode=g channel=4 macaddr_acl=0 ignore_broadcast_ssid=0
Save the file as hostapd.conf.
Within the same folder, start the Access Point:
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.# hostapd hostapd.conf
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:
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).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
Save the file. Next, we'll need to configure an IP address on the wireless interface wlan1, so clients can actually communicate to it:
Now start the DHCP server:# 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
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:# dnsmasq -C dnsmasq.conf -d
# 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
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:
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.# cat /var/lib/misc/dnsmasq.leases
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.
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.
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:
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.# airodump-ng wlan2
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:
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.# aireplay-ng -0 0 -a B0:26:80:83:79:C0 wlan2
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:
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.# aireplay-ng -0 0 -a B0:26:80:83:79:C0 -c 90:C1:15:1C:85:C0 wlan2
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.
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.
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:
Or:# ifconfig wlan2 down # iw reg set BO # iwconfig wlan2 txpower 30 # ifconfig wlan2 up
It may depend on the wireless device what transmit power is allowed, and what will work.# ifconfig wlan2 down # iw reg set GY # iwconfig wlan2 txpower 30 # ifconfig wlan2 up
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.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:
In the output above you can see there are 3 wireless devices. The first one, listed as phy0, is the internal WiFi device of the computer. The other two are using a USB driver, and are two USB WiFi devices that have been inserted. The Alpha AWUS036NH WiFi device is actually device phy2 in the output above.# 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
Now run "iwconfig":
# 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
The "iwconfig" command above provides us with some more information, for example, if the interface is associated with any Access Point (a.k.a. router), and what the transmit power (Tx-Power) of the device is currently set to. Similar information can be retrieved by running the "iw dev" command, however that command will also display the MAC address of each device.
For the purpose of these security articles, we have equipped the computer with 3 WiFi devices. The first device, wlan0, will be used to regularly connect to a working WiFi Access Point for Internet connectivity. The second interface, wlan1, will be used to monitor WiFi networks. And the third interface, wlan2, will be used in a later article to set up our own Access Point. Having several WiFi interfaces gives us the capability to do multiple things.
WiFi network traffic is similar to radio signals. One can simply tune in the "radio" to listen to what is going on. This is the main reason why using Open (non-encrypted) WiFi networks is a security risk. Yet, many people use Open WiFi networks frequently.
Similar to radio signals, the location of where you are listening, and the equipment used to listen to it, matters. The closer you are to an Access Point, the stronger and more reliable the signals are. Also, the better the WiFi network device, or the larger the antenna used, the more likely it is that you will receive a good signal.
To start listening to WiFi traffic, it is useful to set one of the WiFi interfaces into Monitor mode. The airodump-ng command, that we'll we using to monitor WiFi network traffic will set a device in monitor mode itself, so you won't have to do it yourself. But if you do wish to configure a WiFi interface in Monitor mode, you can do so as follows, for example, for WiFi interface wlan1:
# 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
In the output of the "iwconfig" command above, you can now see that the wlan1 interface is in Monitor mode, and that the frequency is set to 2.462 GHz (configured to listen to the 2.4 GHz WiFi band).
Another way of configuring a WiFi network interface in Monitor mode is by running:
However, when using the airmon-ng command, keep in mind that the interface used, in the example above: wlan1, will be renamed to wlan1mon.# airmon-ng start wlan1
When setting a WiFi network interface in Monitor mode, you may encounter a failure. If this happens, then most likely another process is using the WiFi network interface. To check this, run:
If you want to stop all the other processes using the wireless device, simply run:# airmon-ng check wlan1
A good example of a process using a wireless device is NetworkManger. By default, this process will be active on Kali Linux. To verify that, run:# airmon-ng check kill
You can stop NetworkManager, you can run:# systemctl status NetworkManager
If you wish to keep on using NetworkManager, but just have NetworkManager not managed a specific wireless device, then do the following:# systemctl stop NetworkManager
First determine the MAC address of the wireless device, by running "iw dev". Assuming that the MAC address of wireless device is 00:0f:60:01:07:4c, then add the following to the bottom of /etc/NetworkManager/NetworkManager.conf:
Then restart NetworkManager:[keyfile] unmanaged-devices=mac:00:0f:60:01:07:4c
From now on, NetworkManager will no longer manage the wireless device with MAC address 00:0f:60:01:07:4c, and you should not see any issues when running commands against the wireless device and having NetworkManager managing it at the same time.# systemctl restart NetworkManager
Now you can start monitoring the WiFi networks, by running:
The output shown by the airodump-ng command is divided in two parts. On the top you can see all the BSSIDs. These are the Access Points / routers found. For each BSSID, you'll see the MAC address of the Access Point, the transmit power (PWR), the channel it is transmitting on (CH), the encryption used (ENC) and the ESSID (The name of the WiFi network). At the bottom, you can see the clients, also called stations. These are devices, such as computers and phones connected to an Access Point, or when listed as "not associated", devices that are not connected to any Access Point, but looking to connect. If a device is connected to an Access Point, then it will list both the MAC address of the BSSID (Access Point) and that of the client (Station). In the left-most column you can see information about "Probes", meaning clients that probe for a certain WiFi network name.# airodump-ng wlan1
The airodump-ng command has some very useful commands, described in a lot of detail at https://www.aircrack-ng.org/doku.php?id=airodump-ng. For example, the "a" key can be used to cycle through different parts of the output, which may come in handy if there is too much information to fit on the screen. The "s" and "r" keys can be used to sort the output per column and the TAB key can be used to highlight/select specific BSSIDs.
A note about MAC addresses: The MAC address alone doesn't provide any information about what kind of device it is, but some information can be derived from the MAC address. A MAC address consists of 6 parts, divided by colons. The first 3 parts determine the vendor of the device. You can take these first three parts, and look up which vendor it is, for example by typing in these 3 parts at www.macvendors.com. For example, if you do so for MAC address B0:26:80:AA:CB:20, by taking the first three parts (BO:26:80) and enter that on www.macvendors.com, it will tell you it is a Cisco device. When retrieving MAC address vendor information, you may discover a lot of China-based vendors that manufactured the wireless devices in computers, phones and other devices. So, it may not always be immediately clear what type of device is using a certain MAC address.
At the top of the airodump-ng command you will notice that it cycles through all the channels constantly, which is the default behavior. This way it is scanning all channels for WiFi networks. If you wish to look at a specific Access Point (or BSSID), then copy the MAC address of that BSSID, and take a note of the channel it uses.
For example, in the top output you may see a line for an Access Point/BSSID as follows:
This means that a WiFi network with the name "attwifi" is running at channel 6, with MAC address B0:26:80:83:79:C0.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
To only look at this specific access point, start airmon-ng as follows:
So far for this article. At this point you have learned how to scan for WiFi networks using Kali Linux, and how to see all the different WiFi networks in the vicinity, and to see what clients (stations) are either associated to or probing for an Access Point.# 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.
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 https://docs.kali.org/downloading/kali-linux-live-usb-install and https://docs.kali.org/downloading/kali-linux-live-usb-persistence.
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 https://www.kali.org/downloads/. 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 https://sourceforge.net/projects/win32diskimager/. 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:
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".# dd if=kali-linux-2018.3a-amd64.iso of=/dev/sdb bs=512k
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:
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:# parted /dev/sda mkpart primary 4gb 8gb
Next, reboot the system, and boot the Kali Linux Live persistence option:# mkfs.ext3 -L persistence /dev/sda3 # e2label /dev/sda3 persistenceNow create a mount point, mount the new partition there, and then create the configuration file to enable persistence. Finally, unmount the partition:
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.# reboot
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 https://docs.kali.org/downloading/kali-linux-live-usb-persistence.
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
Number of results found: 470.
Displaying results: 21 - 30.
Displaying results: 21 - 30.
