Forem: Enoch Amachundi Agbu

Securing MariaDB Server

Enoch Amachundi Agbu — Wed, 02 Jul 2025 11:01:18 +0000

A step-by-step practical guide to creating secure user accounts, managing privileges, and enabling advanced audit logging in MariaDB Sever.

In today’s threat landscape, databases are prime targets. Whether it’s an insider threat or an external breach attempt, controlling who can access your database and monitoring their actions is essential for any Cybersecurity Analyst.

This project walks through a real-world simulation of how to:

Create and manage users in MariaDB server.
Apply the principle of least privilege.
Restrict remote access to the MariaDB server.
Enable advanced audit logging.
Review and analyse logs for security incident detection.

By combining proactive access control with reactive audit strategies, this project demonstrates how a cybersecurity analyst can secure critical systems and generate forensic-ready reports.

Ensure the MariaDB Server is up and running. Read How to set up Chinook Database on MariaDB on how to start, stop, enable and disable the MariaDB server.

Step 1: Setup and Import Chinook Database.

If you have the MariaDB Server or MySQL Server already set up, you can skip to Step 2; otherwise, read the article How to set up Chinook Database on MariaDB to implement the Step 1, where you will install the MariaDB Server, download and import the Chinook database.

Step 2: Create Users and assign Permissions.

The SQL statement

SHOW DATABASES;

will display all the databases in the MariaDB server. The 1st arrow points to the Database column, and within the column is the list of preinstalled databases that come with the MariaDB server, which hold important files and configuration settings.

The following databases, information_schema, mysql, performance_schema and sys are all default databases that come pre-installed with the MariaDB server. They contain important files and configurations like user privileges related to the MariaDB server.

STEP 3: Log in to MariaDB.

First, view the list of existing users who can access and manage the databases in the MariaDB server, but note that only users with root privileges can view the list. This will give the admin or root user an overview of the users currently authorised to access the MariaDB server.

In the second command, we added authentication_strings to retrieve more detailed information as pointed to by the 2nd arrow. You can specify more columns, like the password that you wish to retrieve.

The query

SELECT User, Host FROM mysql.user;

will display all users, including any user you created. Notice we have a user called root on the localhost as pointed to by the 1st arrow.

Note that mysql is the database name while user is the table name found inside the mysql database, hence the reason we used mysql.user.

You can switch back to the mysql database using the query

USE mysql;

and view the tables in the mysql database using

SHOW TABLES;

then run

SELECT User, Host FROM user;

to display all the users.

From the screenshot below, notice that we did not use FROM mysql.user but just FROM user, this is because we are currently inside the desired database mysql as pointed by the 1st arrow and the 2nd arrow points to the user table inside the mysql database.

STEP 4: Create New User.

The following commands

CREATE USER 'firstuser'@'localhost' IDENTIFIED by firstpassword;

CREATE USER 'seconduser'@'%' IDENTIFIED by secondpassword;

CREATE USER 'testinguser'@'%' IDENTIFIED by testingpassword;

will create new users and will be recognised by the password you provide.

The query CREATE USER will create a new user called firstuser on the localhost and assigned the password firstpassword. The same applies to others.

These users are created for the Chinook database ONLY, as you can see, it is the Chinook database that is currently mounted while creating the users.

The @’localhost' in the query ‘firstuser’@’localhost' means firstuser can only connect to the database from the local machine.

The @’%’ in the query ‘seconduser’@’%’ will allow seconduser to connect to the database from ANY host/machine.

Use the query

DROP USER 'testing'@'%';

to remove the testinguser.

To verify if testinguser has been dropped, query

SELECT User, Host, password FROM mysql.user;

The 1st arrow points to the authorised users, but the testinguser has been removed or dropped and deleted the user and all associated permissions. The 2nd arrow points to the columns in the user table we specified in the query. The 3rd arrow points to the hashed password for the remaining new users we created.

The string *826954EC52E6900DB7AC23C8151ED1A5F8E85715 is a hashed representation of the user's password, stored in an encrypted format for security.

In MariaDB, passwords are hashed using algorithms like SHA-1 or SHA-2 before being saved in the mysql.user table. This protects the actual password, ensuring that only the hash, which is computationally difficult to reverse, is stored. This approach enhances database security by keeping users' real passwords hidden.

STEP 5: Grant Permissions to the Users.

We can grant specific privileges to users of specific databases.

The following queries

GRANT ALL PRIVILEGES ON Chinook.* TO 'firstuser'@'localhost';

GRANT ALL PRIVILEGES ON *.* TO 'thirduser'@'localhost';

GRANT SELECT, INSERT, UPDATE ON Chinook.* TO 'seconduser'@'%';

FLUSH PRIVILEGES;

will grant ALL privileges to the firstuser for ONLY the Chinook database as pointed to by the 1st arrow. The second query will grant ALL permissions to the thirduser for ALL databases in the MariaDB server as pointed to by the 2nd arrow. The *.* means all databases in the MariaDB server. The third query grants limited permissions (SELECT, INSERT, UPDATE) to the seconduser for the Chinook database, pointed to by the 3rd arrow.

The query FLUSH PRIVILEGES will apply the changes made as pointed to by the 4th arrow.

We can view users’ privileges in MariaDB by querying the information_schema.user_privileges table. The query

SELECT * FROM information_schema.user_privileges
WHERE GRANTEE = 'thirduser'@'localhost';

will show privileges assigned to the thirduser.

information_schema is the database name and user_privileges is the table name, hence the information_schema.user_privileges. Feel free to mount the information_schema database and view its tables and table columns.

NOTE: The user_privileges provides a server-wide permission view and not a database-specific permission. Therefore, the query above will output the global privileges assigned to users across the MariaDB server, not tied to any specific database.

Or we could view all users' privileges in the MariaDB server like this.

SELECT * FROM information_schema.user_privileges;

The GRANTEE column lists all the users.

The USAGE privilege means that the user has no specific or explicit privileges granted at the level being queried (i.e. server-wide or global), other than the ability to connect to the database. This is often seen when a new user is created but hasn’t been assigned any particular privileges like SELECT, INSERT, UPDATE or ALL PRIVILEGES. The USAGE privilege effectively allows login access without granting any permissions to interact with or modify database content as pointed to by the 1st arrow.

Notice that we granted ALL PRIVILEGES to the firstuser for Chinook database, but from the screenshot above under the GRANTEE, the ‘firstuser’@’localhost privilege_type is showing USAGE, this is because the firstuser have no explicit privileges granted for this level, which is for the entire databases or MariaDB server, it privileges were specifically for the Chinook database and not for all the databases (server-wide) in the MariaDB server. But the thirduser was granted ALL PRIVILEGES for all databases (server-wide) in the MariaDB server. If we want to view user privileges specific to a database, use the SCHEMA_PRIVILEGES table instead of the USER_PRIVILEGES table. This will be demonstrated shortly below.

The IS_GRANTABLE column in the user_privileges table indicates whether a user can grant a specific privilege to other users, as pointed to by the 2nd arrow. If IS_GRANTABLE is set to YES, it means the user can grant that particular privilege to others as pointed to by 4th arrow. If it’s NO, the user can use the privilege but cannot pass it on, as pointed to by the 3rd arrow.

This is controlled by the GRANT OPTION privilege in MariaDB, which allows a user to grant their privileges to others.

Hence, from the output above, we can see that the ‘mysql’@’localhost' user can assign privileges to other users, meanwhile ‘thirduser’@’localhost' cannot because its IS_GRATABLE value is NO for each privilege.

The SCHEMA_PRIVILEGES and USER_PRIVILEGES tables in information_schema database serve different purposes.

SCHEMA_PRIVILEGES: Contains privileges specific to individual databases (schemas). It details permissions granted to users or roles for operations on a database, including GRANTOR, PRIVILEGE_TYPE, and IS_GRANTABLE.
USER_PRIVILEGES: Provides a broader view of global privileges assigned to users across the server, not tied to any specific database. It reflects permissions like SUPER, CREATE USER, or server-wide privileges.

Use SCHEMA_PRIVILEGES for database-specific queries and USER_PRIVILEGES for server-wide permission analysis. The term SCHEMA is referred to as DATABASE, therefore, SCHEMA_PRIVILEGES means database privileges. The query

SELECT * 
FROM information_schema.SCHEMA_PRIVILEGES
WHERE GRANTEE = 'firstuser'@'localhost' AND TABLE_SCHEMA = 'Chinook';

will return the firstuser database privileges associated with the Chinook database.

Mount and explore the information_schema database.
The SHOW DATABASES displays all databases in the MariaDB server. The 1st and 2nd arrows point to two important default or preinstalled databases that come with the MariaDB server.

The query

USE information_schema;

will mount the database on the MariaDB server as pointed to by the 1st arrow.

SHOW TABLES;

will display all the tables in the information_schema database as pointed to by the 2nd arrow. The 3rd arrow points to the USER_PRIVILEGES, which is one of many tables in the database.

Explore the other databases and their tables to see other MariaDB server files and configuration settings. For example, the mysql database has tables like user, and db that you can explore.

information_schema Database: This is a virtual database that provides metadata about the database server. It stores information about databases, tables, columns, data types, privileges, constraints, and other schema-related details. Tables in information_schema database are dynamically generated views, not stored on disk.

mysql Database: This is a system database containing user accounts, privileges, roles, and other essential system configurations. It stores tables like mysql.user for user accounts, mysql.dbfor database privileges, andmysql.tables_priv` for table-level privileges, among others.

Step 6: Revoking Users' Permissions.

Before we revoke the firstuser permissions, let's have a view of the firstuser permissions by querying
SELECT * FROM SCHEMA_PRIVILEGES WHERE GRANTEE = 'firstuser'@'localhost';
The 1st arrow points to the users column and 2nd arrow points to the privileges with the SELECT privilege appearing first in the column.

The query
REVOKE SELECT ON Chinook.* FROM ‘firstuser’@'localhost';
Will only revoke the SELECT permission. As pointed out by the 2nd arrow, the SELECT privilege is no longer available.

Meanwhile, the query:
`
REVOKE ALL PRIVILEGES, GRANT OPTION FROM firstuser@localhost;

FLUSH PRIVILEGES;
`
will revoke all privileges that have been granted to the firstuser on the Chinook database. As pointed to by the 1st and 2nd arrow, the firstuser is not seen among the user list because all its privileges have been revoked.

This ensures the user can no longer perform any actions like SELECT, INSERT, etc., and cannot grant privileges to others.

Explanation:

REVOKE: Is the SQL command used to take away privileges.
SELECT: Is the specific privilege being revoked.
ON Chinook.*: Targeting all tables (*) in the Chinook database.
FROM firstuser@localhost: This specifies the user and host combination.

After revoking, it’s good practice to flush privileges so changes take effect FLUSH PRIVILEGES;

Let's grant all the privileges back to firstuser and then view all users' privileges to confirm it. Run the two sets of queries separately as shown in the screenshot.
`
GRANT ALL PRIVILEGES ON Chinook.*
TO firstuser@localhost;

SELECT * FROM SCHEMA_PRIVILEGES;
`

As shown above, the firstuser have been granted all privileges again.

STEP 7: Test the New Users.

From the screenshot above in STEP 3, we have assigned ALL PRIVILEGES to thirduser for all databases in the MariaDB server, so let's log out and log in as thirduser.

The command exit or EXIT will terminate the database console and return to the Linux console as pointed to by the 1st arrow. The command
sudo mariadb -u thirdsuer -p;
will log in as the thirduser after passing its password as pointed to by the 2nd arrow.

Now we are logged in as the thirduser. Since the thirduser has ALL PRIVILEGES with server-wide or global privileges scope, let's run a SELECT command on the Chinook database.

Everything works fine as the thirduser was able to log in and run queries as expected.

Step 8: Harden and Enable Logging for Detection & Analysis.

Let's edit the 50-server.cnf file and configure any desired security settings of our choice. But let's first understand the contents of this file, and this is very important.

In the 50-server.cnf file or any MariaDB/MySQL config file, settings are grouped under sections as pointed to by the 1st, 2nd and 3rd arrow, each identified by a header in square brackets, like [mysqld]. Each section applies to a specific component or version.

Here's a quick breakdown:

[server]: This applies to all server-type programs (e.g., mysqld, mysqld_safe, mariadbd, mongod etc.). It is used to apply or share generic settings across all server modes. It is often used as a global section.
[mysqld]: This section applies only to the main MariaDB/MySQL server daemon (mysqld). It is where you typically define ports, data directory, logging, connection limits, SQL modes, and buffer sizes, among other settings. This is the most important section for database server behaviour, and in this project, this is where most of our configuration settings will be applied.
[embedded]: This applies to the embedded MariaDB library (libmysqld). It is used when MariaDB is embedded inside an application (a rare use case).
[mariadb]: This applies specifically to MariaDB server instances (not the generic MySQL). The settings here will override [mysqld] if both sections define the same setting. This section is used when you want MariaDB-specific tuning.
[mariadb-10.6]: This applies only to MariaDB version 10.6 and below. It is useful when running multiple MariaDB versions on the same machine or preparing version-specific tuning. This will override both [mariadb] and [mysqld] for that version.

What is a daemon in Linux?

A daemon, pronounced day-mon is a background process that runs without direct user interaction and starts automatically at boot time or when needed. It performs ongoing system or service tasks quietly.

Examples of daemons:

mysqld: Runs the MariaDB/MySQL database server.
sshd: Handles SSH connections.
httpd or nginx: Runs a web server.
crond: Runs scheduled tasks (cron jobs).
systemd: Controls startup and background services.

Basic characteristics of a daemon are: It runs in the background, it has a name ending in d (like mysqld, sshd), it is usually started by init/systemd or a service manager, and does not have a graphical interface.

In MariaDB context, the MariaDB daemon is mysqld. It waits for database connections, and processes queries, manages users, reads config files, etc. We interact with it indirectly via the mysql command-line client.

The screenshot below shows the path/directory to the 50-server.cnf file, where we can apply configuration settings for MariaDB. The 1st arrow points to the directory inside the mysql directory, and the 2nd arrow points to the 50-server.cnf file inside the mariadb.conf.d directory.

Therefore, log out of the database and edit the 50-server.cnf file by running:
sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf

At the moment, notice the mysql directory is currently empty with no files or directories as pointed to by the arrow below.

Open the 50-server.cnf file and provide your sudo password for authentication.

The 1st arrow points to the file currently opened, and the 2nd arrow points to a brief description about the file and its contents.

Within the [mysqld] section, restrict MariaDB to only localhost connections. Look for where bind-address is commented and remove the # symbol before it. If the configuration setting cannot be found, type it:
bind-address = 127.0.0.1
Also, disable symbolic-links. In Linux, a symbolic link (or symlink) is like a shortcut or pointer to another file or directory. Within the [mysqld] group insert:
symbolic-links=0

Auditing actions taken by a MariaDB user is a crucial step in database security. This can be achieved by analysing query logs, enabling the audit plugin, or using MariaDB's general or slow query log, depending on the setup.

While still in the 50-server.cnf file, inside the [mysqld] section as pointed to by the 1st arrow, insert the configuration settings below. But where any settings are already written and commented, you do not have to rewrite them, just uncomment the configurations by erasing the hash symbol #.
general_log = 1 general_log_file = /var/log/mysql/query.log
Note that this configuration setting only records/captures users' logging activities.

Then, restart the MariaDB Server by running the command below:
sudo systemctl restart mariadb

After editing the 50-server.cnf file and restarted the mariadb server, let's confirm the query.log file is created in the /var/log/mysql/ directory. The query.log` file has been created as pointed out by the 1st arrow.

Let’s log in as the seconduser and perform some activities by querying the Chinook database.

Notice that currently there is no single activity recorded in the query.log file about the seconduser yet, when we run the query

grep seconduser /var/log/mysql/query.log

as no output was returned, as pointed out by the arrow below.

I will provide two wrong passwords and finally log in with the correct password for the seconduser, perform some queries and let's find out if it will be captured in the query.log file.

Let's exit the database and view the query.log file to confirm if the seconduser logging activities were captured. As pointed out by the 1st and 2nd arrows directly at the logging time, access was denied because I entered the wrong password. But the third attempt, as pointed out by 3rd arrow, the seconduser successfully logged in.

Use the grep command to search for activity performed by the seconduser.

grep seconduser /var/log/mysql/query.log

Or to get a real-time view

sudo tail -f /var/log/mysql/query.log | grep seconduser

This will show what queries were executed, on what database/table, timestamps (if configured), login and logout events.

The general log can grow quickly because it logs everything. Avoid keeping it on in production for long periods. It's best used for auditing user activity, debugging application-database interactions, security investigations (e.g., detecting SQL injections or misuse).

Enable MariaDB Audit Plugin (Advanced Audit Logging).

If not already installed, you can enable the MariaDB Audit Plugin for deeper auditing.

INSTALL SONAME 'server_audit'

As pointed out by the 1st arrow, the query was successfully executed. After the installation, run

SHOW PLUGINS

to view the list of all plugins as pointed to by the 2nd, 3rd and 4th arrow.

SONAME stands for Shared Object Name .so. In MariaDB/MySQL, SONAME refers to a shared library (.so file) that extends the server's functionality, often through plugins.

Configure the plugin by editing the file /etc/mysql/mariadb.conf.d/50-server.cnf and insert within the [mysqld] section, the configuration settings below as pointed to by the 1st arrow.

server_audit_logging=ON
server_audit_events=CONNECT,QUERY
server_audit_excl_users=mysql
server_audit_file_path=/var/log/mysql/audit.log

Then, restart MariaDB by running sudo systemctl restart mariadb.

Now we will get detailed logs of all queries and connections made by all users logged in to MariaDB.

Review the Audit Logs.

Notice that when we extract the firstuser activities from the audit.log file, it returns nothing as pointed to by the 1st arrow, because since the creation of the audit.log we have yet to perform any activities as the firstuser.

Log in as firstuser and provide the firstuser password as pointed to by the 1st arrow. I deliberately provided a wrong password and was denied access as pointed to by the 2nd arrow.

We finally logged in and performed some queries like showing the databases on the MariaDB Server as pointed out by 1st arrow, and mounting the Chinook database on the server as pointed out by 2nd arrow.

Run the command below to extract the firstuser activities from the audit.log file.

less /var/log/mysql/audit.log

Or use filters:

grep firstuser /var/log/mysql/audit.log

The 1st arrow points to the first failed login attempt I tried earlier above. The 2nd arrow points to when we successfully logged in. The 3rd arrow points to when the firstuser run the query SHOW DATABASES. The 4th arrow points to when the firstuser mounted the Chinook database (i.e when the Chinook database was selected). The last arrow points to when the firstuser exited the database.

The audit file presents you with the timestamp, hostname, username and the query executed by a user.

Generate a Report (Optional).

You can create a structured report of the user’s actions by running :

grep 'firstuser' /var/log/mysql/query.log > firstuser_activity.log

The 1st arrow below points to the file created from the command above, which contains the firstuser activities or footprint in the MariaDB Server.

Auditing user actions is vital for Accountability, Threat hunting, Forensics after incidents, and Security compliance.

Summary.

By the end of this project, you will have enabled logging and monitoring, practised log forensics and system auditing.

LinkedIn Article.

Securing MariaDB Server

Connect with me.

🔗 LinkedIn

🔗 X

Set up Chinook Database on MariaDB Server.

Enoch Amachundi Agbu — Fri, 27 Jun 2025 08:15:58 +0000

This project provides a step-by-step guide to installing Chinook Database on a MariaDB Server.

The Chinook Database is a sample database widely used for learning, practising SQL, and testing database management tools. It is commonly used in tutorials, technical interviews, and courses that teach SQL querying, database normalisation, and relational database design.

What Is Inside the Chinook Database?

The Chinook database mimics a digital media store. It contains data about music, customers, and purchases, structured to reflect real-world business scenarios.

This is a step-by-step guide to installing the Chinook Database on a MariaDB server.

In the screenshots, the Linux commands and SQL statements are highlighted in yellow colour for clarity and effective comprehension.

MariaDB was originally developed as a fork of MySQL, and it shares a high degree of compatibility, including its command-line interface. In many Linux distributions, when you install MariaDB, the command to start the MariaDB shell is still mysql for compatibility and familiarity, even though we are using MariaDB. However, you can often also use mariadb instead of mysql in the terminal. Both commands typically work interchangeably for MariaDB on most systems.

Step 1: Install MariaDB Server on Linux.

The 1st arrow points to the username agbuenoch, and the 2nd arrow points to the host or the machine DESKTOP-H57G709, the user agbuenoch is currently logged in.

The command

sudo apt update

is used to run an update on our Ubuntu Linux distro, and this is highly recommended to do from time to time to have updated versions, patches and security features that are released.

The command

sudo apt install mariadb-server

will install the MariaDB server on our machine/host. The MariaDB server is a Relational Database Management System (RDBMS) that will host our Chinook database. You will be notified of the storage space to be used as pointed to by 1st arrow. If you wish to continue, enter yes, i.e. y as pointed to by 2nd arrow. The 3rd arrow points to the download progress in percentage.

After installing MariaDB, start and enable the MariaDB server. The command

sudo systemctl start mariadb

will start the MariaDB server. You will be prompted to enter your password to be able to run the specified command and start the server as pointed to by the 1st arrow. For any wrong password you enter, you will be prompted to re-enter the password as pointed to by the 2nd arrow. If successful, you will be redirected to the next prompt as pointed to by the 4th arrow.

Always remember to start the MariaDB server if you previously stopped it.

The command

sudo systemctl enable mariadb

will enable the MariaDB server. The 1st arrow below points to the successful execution message.

You can stop and disable the MariaDB server by running the command below, respectively.

sudo systemctl stop mariadb

sudo systemctl disable mariadb

STEP 2: Secure the MariaDB Server.

Run the command

sudo mysql_secure_installation

to secure and provide settings for the MariaDB server we installed.

The 1st arrow points to the prompts requesting the root user's agbuenoch password. But if you have no password for the root user, just press the Enter key on your keyboard.

The 2nd arrow points to the prompt that says Setting root user password or unix_socket can be used to secure access to the MariaDB server. In the scenario below, I already have a root user password set up, and this is recognised; for this reason, I declined to set up a unix_socket authentication by answering no, i.e. n. You will be prompted to provide the password before you can log in as a root user to the MariaDB server.

The 3rd arrow points to the prompt asking if I want to change/update my already existing root user password, therefore I answer the prompt question with no, i.e. n. I do not want to change it.

The screenshot below is the continuation of the screenshot immediately above. From the screenshot below, the 1st arrow points to the prompt asking if we want to remove the default anonymous user that comes preinstalled with the MariaDB server. Because this installation is for a production environment setting, the database administrator will be responsible for creating and adding new users. Let’s answer with yes, i.e. y to remove the anonymous user.

The 2nd arrow points to the prompts asking to disallow root login remotely. If we disallow root login remotely, the root user can only log in to the database locally, which is highly recommended for security reasons and will reduce the attack surface. The root user's remote login can be allowed for troubleshooting or other valid reasons so that the root user can log in to the database from any host/machine.

The 3rd arrow points to the prompt asking to remove the test database and access to it, and we agreed to remove it by inputting yes, i.e. y.

We then agreed to reload the privilege table to affect all the settings, as this is pointed to by the 4th arrow. We got a success message below confirming that our MariaDB server is now secure and can only be accessed by authorised users.

STEP 3: Download the Chinook Database SQL Script for MySQL.

Download the Chinook_MySql.sql file, as the MariaDB server is compatible with MySQL SQL scripts, using the command wget to download it directly from the command line.

The command wget is followed by the web address URL where the Chinook_MySql.sql file is located. The arrow below points to the download progress and afterwards shows that the file has been saved as shown with the underline in red.

This is how to get the web address for the Chinook_MySql.sql:
Click on the Chinook Database GitHub Repository and follow the screenshot below. Click just once on the file that the green-coloured arrow points to.

At the top right-hand corner, click on Raw.

You will be presented with the Chinook_MySql.sql raw file. Highlight the URL in the web browser address bar as shown below, highlighted in yellow and copy it.

You will be presented with the Chinook_MySql.sql raw file. Highlight the URL in the web browser address bar as shown below, highlighted in yellow and copy it.

Paste the URL immediately after the wget command on the Linux console, as illustrated above.

STEP 4: Log in to MariaDB.

When prompted for a password, enter your root password. If it was the unix_socket authentication you chose, provide the required details as expected.

The command

sudo mariadb

or

sudo mariadb -u root -p

can be used to log in to the MariaDB server. Because we previously secured the database, you are prompted to enter a password as pointed to by the 1st arrow. If the authentication is successful, you will be granted access to the MariaDB server as pointed to by the 2nd and 3rd arrows. The 2nd arrow points to the Relational Database Management System (RDBMS) we are using, which is MariaDB and the 3rd arrow points to the current Database residing in the MariaDB server, at this stage no database has been mounted on the MariaDB server, which is why you see the [(none)].

STEP 5: Create a new Database for Chinook (OPTIONAL).

Create a new database called Chinook. Then switch to the new database Chinook, by so doing, the [(none)] will be replaced by Chinook. Make sure the new database name we are creating matches the exact name of the database found in the Chinook_MySql.sql file.

Let’s take a look at the file and have a look at what I mean. From this screenshot, click on the file pointed by the green arrow below.

The 1st arrow points to the SQL statement

DROP DATABASE IF EXISTS `Chinook`;

This will replace and overwrite any existing database with the exact database name Chinook when we upload the SQL file to our MariaDB server. But note that this SQL statement is CONDITIONAL, it will only run if there is a database named Chinook found in the MariaDB server; otherwise, it will not execute but jump to the next line of the statement. Therefore, the Chinook database we will create will be replaced or dropped as a result of this line of SQL statement. In essence, the Chinook database in the Chinook_MySql.sql file will replace the empty Chinook database we are going to create.

The 2nd arrow points to

CREATE DATABASE `Chinook`

If the CONDITIONAL SQL statement above did not execute, a new database Chinook will be created.

The 3rd arrow points to

CREATE TABLE `Album`

This statement will create a new table called Album and populate the table with values as specified inside the parentheses ( … ). When you scroll down, you will see more of the other statements that will build the Chinook database for us.

Before creating the Chinook database and loading the Chinook_MySql.sql file, we run the statement

SHOW DATABASES;

to view the current databases in the MariaDB server. The 1st arrow points to the Database column, and within the column is the list of preinstalled databases that come with the MariaDB server, which hold important files and configuration settings.

The command

CREATE DATABASE Chinook;

will create a new database, Chinook. The database was created successfully, and we got the message Query OK as pointed to by the 1st arrow. If we execute the command

SHOW DATABASES;

We can now see the newly created database Chinook in the MariaDB server as pointed to by the 2nd arrow.

Mount the Chinook database by executing

USE Chinook;

If successfully mounted, we got the message Database changed, i.e. from [(none)] to Chinook as pointed to by the 3rd arrow. View the tables in the Chinook database by executing

SHOW TABLES;

Note that the Chinook database we created is empty; it has no tables. This is why when we execute SHOW TABLES; we get the message Empty set (0.001 sec) as pointed to by the 4th arrow. We will later upload the Chinook_MySql.sql file to the Chinook database and populate the Chinook database with tables and values in the next step below.

STEP 6: Load the Chinook SQL Script into MariaDB.

We need to exit the database first before loading the Chinook_MySql.sql file to the MariaDB server. The command EXIT; will log you out of the MariaDB server. The 1st arrow points that we are logged out, i.e. Bye. The 2nd and 3rd arrows point to the username and hostname, respectively. The 4th arrows point to the $ symbol, which connotes a regular user where whereas the # symbol connotes a root user.

Load the Chinook_MySql.sql file we downloaded above. First, log in to the MariaDB using

sudo mariadb;

The command :

sudo mariadb -u root -p Chinook < Chinook_MySql.sql

will upload the file to the Chinook database we created above. But note that the empty Chinook database we created will be dropped and replaced by the database named Chinook specified inside the Chinook_MySql.sql file. As pointed to by the 1st arrow, you are prompted to enter the root user password for the sudo privilege; meanwhile, the 2nd arrow points to the prompt requesting the root user password for the MariaDB server. Remember from above that a root user password was recognised when I wanted to secure access to the MariaDB Server, and I chose to use the root user password over unix_socket authentication. Therefore, because I am logging into the MariaDB server as a root user, this means I will enter the same password for the root user.

The 3rd arrow points to the command SHOW DATABASE, which will list all databases within the MariaDB server as pointed to by the 4th arrow. The Chinook database is the database we created earlier, which is now replaced with the Chinook database created in the Chinook_MySql.sql file.

information_schema, mysql, performance_schema and sys are all default databases that come pre-installed with the MariaDB server. They contain important files and configurations like user privileges related to the MariaDB server.

We can skip STEP 5 and continue from STEP 6. We will still achieve the same result, this is because when we load the Chinook_MySql.sql file, it will automatically create the new database Chinook with all the tables inside. On this premise, below is how to load the Chinook_MySql.sql file if you decided to skip the step of creating the Chinook database yourself.

The command

sudo mariadb -u -p < Chinook_MySql.sql

will load the SQL script and will automatically create a database named Chinook. Notice that we did NOT insert or pass a database name before the less-than symbol <. The next arrow on the screenshot below shows that the Chinook database has been created automatically as a result of uploading the SQL script Chinook_MySql.sql file.

STEP 7: Verify the Installation.

After showing the databases, mount the Chinook database into the MariaDB server to start querying it.

The command

USE Chinook;

will mount the Chinook database. The database has been changed as pointed to by the 1st arrow.

The command

SHOW TABLES;

will list tables in the Chinook database we just mounted. The 2nd arrow points to the column named Tables_in_Chinook. The 3rd arrow points to the names of the tables inside the Chinook database, like Album, Artist and Track, among others.

Notice that the SQL statement SHOW TABLE now displays the list of tables in the Chinook database, meanwhile, before the Chinook_MySql.sql file was uploaded into the Chinook database we created, no tables were inside the Chinook database as shown above In step 5, the last screenshot pointed out by the 4th arrow, which reads Empty set (0.001 sec).

Run the following SQL statement for each of the tables inside the Chinook database to view the columns in each table.

SELECT * FROM <The table name>.

For example:

SELECT * FROM Album;

STEP 8: Stop and Disable the Database:

We can stop the MariaDB server and prevent it from starting automatically on subsequent system boots. This implies that we must start the server each time we boot our local device. Let’s exit back to the Linux console and run the commands shown below.

The command

sudo systemctl stop mariadb

will stop the MariaDB server, while the command

sudo systemctl disable mariadb

will disable the server. You can check the status of the server by executing

sudo systemctl status mariadb

You must restart the database again before you can access and query it, as demonstrated at the beginning of the article. Let’s see what happens when you attempt to access the database without starting it.

As pointed out by the 2nd arrow, you will get an error because the server was stopped, as shown in the screenshot above. Therefore, you will have to start the server before accessing it.

The command

sudo systemctl start mariadb

will start the server, hence when we run sudo mariadb, we can access it as pointed to by the 1st arrow.

Summary:

This setup provides a complete local environment for practising SQL on the Chinook database using a MariaDB server and Linux Bash.

LinkedIn Article.

How to set up “Chinook Database” on MariaDB Server using Linux Bash

Connect with me.

🔗 LinkedIn

🔗 X

Analyse Packets with Wireshark.

Enoch Amachundi Agbu — Mon, 23 Jun 2025 09:28:09 +0000

This project opens a packet capture (.pcap) file and explores the basic Wireshark Graphical User Interface. It opens a detailed view of a single packet and explores how to examine the various protocol and data layers inside a network packet. It applies filters to TCP packet data to search for specific payload text data.

Step 1: Explore data with Wireshark.

Let’s open a network packet capture file called sample as pointed to by the 2nd arrow, which contains data captured from a system that made web requests to a site. We need to open this data with Wireshark to get an overview of how the data is presented in the application.

Wireshark is already installed on Windows, as indicated by the 1st arrow. To open the packet capture file, double-click the sample file, as shown by the 2nd arrow below on the Windows desktop. This will start Wireshark. Note that the sample packet capture file has a .pcap file extension, which is hidden by default in Windows Explorer and the desktop view.

After we double-click the sample pcap file, the Wireshark window below will be displayed. Many network packet traffic is listed, so we will apply filters to find the information needed.

The area pointed to by the 1st arrow is the filter text box used to filter and select intended network traffic. As pointed out by the 2nd arrow, you can scroll up and down the Wireshark interface to view more network traffic.

Scroll down the packet list until a packet is listed where the info column starts with the words Echo (ping) request as pointed to by the 1st arrow. The 2nd arrow points to the ICMP Protocol contained in the traffic.

Let us look at common Protocol Names and their meaning.

ARP (Address Resolution Protocol) --> used to map IP addresses to MAC addresses.
IP (Internet Protocol) --> used for routing and addressing packets.
TCP (Transmission Control Protocol) --> used for reliable data transport.
UDP (User Datagram Protocol) --> used for faster, connectionless transport.
DNS (Domain Name System) --> This protocol translates domain names to IPs.
HTTP/HTTPS (HyperText Transfer Protocol Secure) --> use in web traffic for regular and secure browser/server communication.
ICMP (Internet Control Message Protocol) --> used in ping and traceroute.
TLS (Transport Layer Security) --> used for encrypted communication.
SSH (Secure SHell) --> used to connect to a system remotely (Secure remote login).
FTP (File Transfer Protocol) --> used for file transfers between client and server.
SMTP (Simple Mail Transfer Protocol)--> Used in email delivery or sending email, but not for receiving email.
IMAP (Internet Message Access Protocol) --> used to retrieve emails from a mail server to your device (computer, phone, or app), but not for sending email.
POP3 (Post Office Protocol v3) --> This is also used to retrieve emails from a mail server to your device, but not for sending email.

Step 2: Apply a basic Wireshark filter and inspect a packet.

An overview of the key property columns listed for each packet:

No.: The index number of the packet in this packet capture file.
Time: The timestamp of the packet.
Source: The source IP address. The IP address from which the traffic emanates.
Destination: The destination IP address. The IP address where the traffic is expected to go.
Protocol: This is the protocol contained in the packet.
Length: The total length of the packet.
Info: Some information about the data in the packet (the payload) as interpreted by Wireshark.

The 1st arrow points to the name of the file currently opened in Wireshark. The 2nd arrow points to the filter text box. Inside the filter text box, we can run queries as pointed to by the 3rd arrow to return, extract, or filter network traffic. When the filter text box turnspinkafter inputting the query, as shown below, it means the command/query entered is wrong. The queryip.addressis a bad syntax. But when thefilter text boxturnsgreenafter inputting the query, it means that the syntax is correct. For example, instead ofip.address, the correct syntax isip-addr`.

The 4th arrow points to the packets columns starting from No all the way to Info. Click on x as pointed to by the 6th arrow to cancel the query you entered, or click on the Apply Display Filter symbol as pointed to by the 5th arrow to run/execute the query entered.

Enter the query below to filter for traffic associated with the specified IP address, i.e 142.250.1.139.
wireshark ip.addr == 142.250.1.139
Press ENTER or click the Apply display filter icon located at the end of the filter text box. Because the filter/query syntax is correct, the filter text box turns green as shown below.

The details pane is located at the bottom portion of the main Wireshark window, as pointed to by the first and second arrows. This can be opened in a completely separate window when you double-click a particular packet from the main Wireshark window.

The above details pane can also be accessed in a new window by double-clicking a packet. The upper section of the window below contains subtrees where Wireshark will provide you with an analysis of the various parts of the network packet. As illustrated below, the upper section of the window, as indicated by the first arrow, contains subtrees (e.g. Frame, Ethernet II, Internet Protocol Version 4 and Transmission Control Protocol) where Wireshark will provide you with an analysis of the various parts of the network packet. The lower section of the window, as indicated by the second arrow, contains the raw packet data displayed in hexadecimal and ASCII text. There is also placeholder text for fields where the character data does not apply, as indicated by the dot .

Double-click any of the subtrees in the upper section to have a detailed view of all information about the data packet.

Double-click the Frame subtree to view details about the overall network packet, or frame, including the frame length and the arrival time of the packet. At this level, we are viewing information about the entire packet of data.

Double-click Frame again to collapse the subtree, and then double-click the Ethernet II subtree. This item contains details about the packet at the Ethernet level, including the source and destination MAC addresses and the type of internal protocol that the Ethernet packet contains.

Double-click Ethernet II again to collapse that subtree and then double-click the Internet Protocol Version 4 subtree. This provides packet data about the Internet Protocol (IP) data contained in the Ethernet packet. It contains information such as the source and destination IP addresses and the Internal Protocol (for example, TCP or UDP), which is carried inside the IP packet. The Internet Protocol Version 4 subtree is Internet Protocol Version 4 (IPv4). The third subtree label reflects the protocol. The source and destination IP addresses shown here match the source and destination IP addresses in the summary display for this packet in the main Wireshark window.

Double-click Internet Protocol Version 4 again to collapse that subtree, and then double-click the Transmission Control Protocol subtree. This provides detailed information about the TCP packet, including the source and destination TCP ports, the TCP sequence numbers, and the TCP flags.

Step 3: Use filters to select packets.

We will use filters to analyse specific network packets based on where the packets come from or where they are sent to. We will explore how to select packets using either their physical Ethernet Media Access Control (MAC) address or their Internet Protocol (IP) address.

Filter traffic for a specific source IP address only.
wireshark ip.src == 142.250.1.139
A filtered list is returned with fewer entries than before. It contains only packets that came from 142.250.1.139 as pointed to by the 2nd arrow. Notice that all the IPs under the Source column match the IP we filtered in the filter text box.

Next, let's filter to select traffic for a specific destination IP address only.
wireshark ip.dst == 142.250.1.1399
A filtered list is returned that contains only packets that were sent to 142.250.1.139 as pointed to by the 2nd arrow. Notice that all the IPs under the Destination column match the IP we filtered in the filter text box, as pointed to by the 1st arrow.

Enter the following filter to select traffic to or from a specific Ethernet MAC address. This filters traffic related to one MAC address, regardless of the other protocols involved.
wireshark eth.addr == 42:01:ac:15:e0:02
Double-click the first packet in the list as pointed to by the 2nd arrow. Double-click the Ethernet II subtree if it is not already open as pointed to by the 3rd arrow. The MAC address you specified in the filter is listed as either the source or destination address in the expanded Ethernet II subtree; in this case, it is listed as the source address as pointed to by the 4th arrow.

Double-click the Internet Protocol Version 4 subtree to expand it as pointed to by the 1st arrow and scroll down until the Time to Live and Protocol fields appear as pointed to by the 2nd arrow.

Always double-click a subtree that is already open to close or collapse it.

Step 4: Use filters to explore DNS packets.

We will use filters to select and examine DNS traffic. Once you have selected sample DNS traffic, we will drill down into the protocol to examine how the DNS packet data contains both Queries (names of internet sites that are being looked up) and Answers (IP addresses that are being sent back by a DNS server when a name is successfully resolved).

Enter the following filter to select UDP port 53 traffic. DNS traffic uses UDP port 53, so this will list traffic related to DNS queries and responses only. Enter this into the Apply a display filter... text box immediately above the list of packets.
wireshark udp.port == 53
Click on the first packet as pointed to by the 2nd arrow to highlight it, or we can double-click the first packet in the list to open the detailed packet window. Notice that the Protocol column contains only DNS, just as described in the filter text box.

Scroll down and double-click the Domain Name System (query) subtree as pointed to by the 1st arrow to expand it. You will notice that the name of the website that was queried is opensource.google.com, as indicated by the 2nd and 3rd arrow.

Let us again double-click the fourth packet in the list as pointed to by the 1st arrow to open the detailed packet window.

Scroll down and double-click the Domain Name System (query) subtree to expand it. Click Answers as pointed by the first arrow, which is in the Domain Name System (query) subtree. The Answers data includes the names that were queried (opensource.google.com) as pointed to by the 2nd arrow and the IP addresses that are associated with the names, as pointed to by the 3rd arrow. The 4th arrow points to the time it takes to look up the name.

Step 5: Use filters to explore TCP packets.

We will use additional filters to select and examine TCP packets. We will learn how to search for text that is present in payload data contained inside network packets. This will locate packets based on something such as a name or some other text that is of interest to us.

Enter the query below to select TCP port 80 traffic.
wireshark tcp.port == 80
TCP port 80 is the default port that is associated with web traffic. Click the first packet in the list as pointed to by the 2nd arrow. The Destination IP address of this packet is 169.254.169.254. The 3rd arrow points to the detailed pane of the selected traffic, which comprises of subtrees.

In the detail pane, we will look up the Time to Live value as pointed to by the 2nd arrow, Header Length as pointed to by the 1st arrow, and Destination Address of the packet as pointed to by the 3rd arrow specified in the Internet Protocol Version 4 subtree.

and the Frame Length as pointed to by the 2nd arrow specified in the Frame subtree of the packet subtree in the detailed pane as pointed to by the 1st arrow.

Let's also enter the query below to select TCP packet data that contains specific text data.
wireshark tcp contains "curl"
Click the Hypertext Transfer Protocol subtree in the detailed pane as pointed to by the 2nd arrow. The 3rd arrow points to the user-agent, which contains the text curl.

Seeing curl in the User-Agent string during a security investigation or analysis indicates that a request to the server was made using the curl command-line tool, not a standard web browser like Chrome or Firefox. Attackers, researchers, or bots often use curl in scripts to send automated requests. Sometimes, the curl is often used to bypass browser protections, headers, or cookies.

The curl command-line tool is used for both legitimate and malicious purposes. Therefore, the context used matters a lot. For example, check if curl requests are hitting sensitive endpoints like /login, /admin, etc.

Summary.

This article describes the process of analysing network packet data using Wireshark. It begins with opening a packet capture file (.pcap) in Wireshark and exploring the basic Graphical User Interface. We then guide through applying filters to select specific packets based on criteria such as IP address, MAC address, or protocol.

It also explains how to inspect individual packets in detail, showing how to examine different protocol layers (Ethernet, IP, TCP) and their data. It further demonstrates how to filter and inspect specific types of traffic, like DNS or TCP traffic, and how to search for specific text within packet payloads.

GitHub Repository: https://github.com/agbuenoch/analyse-packets-with-wireshark

Connect with me.

🔗 LinkedIn
🔗 X

Analyse Packets with tcpdump.

Enoch Amachundi Agbu — Fri, 20 Jun 2025 06:35:11 +0000

This project used the command-line tool tcpdump to capture and analyse live network traffic from a Linux virtual machine. It identifies network interfaces to capture network packet data. It uses tcpdump to filter live network traffic and capture network traffic using tcpdump. Lastly, it filters the captured packet data.

Step 1: Identify Network Interfaces.

Run pwd to print the current working directory as pointed to by the 1st arrow. To list all files and directories in the current working directory, run ls -l, which lists all the directory contents, as pointed to by the 2nd arrow. There is only one file sample.pcap in the /home/analyst directory.

We must first of all identify the network interfaces that can be used to capture network packet data. Run the command

sudo ifconfig

to identify the available interfaces. The 1st and 2nd arrows point to the eth0 and lo network interfaces, respectively. The Ethernet network interface is identified by the entry with the eth prefix.

Alternatively, we can use tcpdump to identify the interface options available for packet capture.

sudo tcpdump -D

This command may be useful on systems that do not include the ifconfig command. The screenshot below lists all available network interfaces we can use to capture packets, as pointed out by the arrow. The network interfaces include eth0, any, lo, nflog, nfqueue. Notice that eth0 and any network interfaces are up and running.

tcpdump = This is a command-line packet capture tool.
-D = This will display a numbered list of all available interfaces.

What does the "any" interface mean?
The "any" interface is neither a physical nor a virtual network adapter. It is a special pseudo-interface used by tcpdump to listen on all available interfaces simultaneously.

When you are not sure which interface traffic will come through (e.g., eth0, wlan0, lo), you can use:

sudo tcpdump -i any

This will capture traffic across all interfaces, such as:

eth0: Ethernet
wlan0: Wireless
lo: Loopback
docker0 or br-xxxx: Docker or bridge interfaces

The limitation is, it cannot capture the link-layer header (e.g., Ethernet headers). So, if you need to inspect Ethernet frames, use a specific interface (e.g., -i eth0) instead. Another limitation is that you won’t see MAC addresses when capturing on any interface.

Example:

sudo tcpdump -i any port 80

This captures all HTTP traffic on all interfaces. This is great for general network monitoring or troubleshooting.

Step 2: Inspect the network traffic of a network interface with tcpdump.

The command-line tool tcpdump is used to filter live network packet traffic on an interface. Let us filter live network packet data from the eth0 interface with

sudo tcpdump -i eth0 -v -c5

Run tcpdump with the following options or flags:

-i eth0: Capture data specifically from the eth0 interface.
-v: Display detailed packet data.
-c5: Capture 5 packets of data.

Let's take a detailed look at the packet information that this command has returned. Five packets were captured as pointed to by the numbered arrows, with each packet starting with a time stamp (in Hours, Minutes, and Seconds, e.g. 06:37:28.000526), followed by the protocol type, IP.

At the start of the packet output, tcpdump reported that it was listening on the eth0 interface, and it provided information on the link type and the capture size in bytes:

Looking at the first packet, which is highlighted in Red-Orange as pointed to by the 1st arrow, the first field is the packet's timestamp, followed by the protocol type, IP. The verbose option, -v, has provided more details about the IP packet fields, such as TOS, TTL, offset, flags, internal protocol type (in this case, TCP (6)), and the length of the outer IP packet in bytes:

The specific details about these fields are beyond the scope of this article. But you should know that these are properties that relate to the IP network packet.

In the next section, the data shows the systems that are communicating with each other:

By default, tcpdump will convert IP addresses into names, as in the screenshot. The name of your Linux virtual machine, also included in the command prompt, appears here as the source for one packet and the destination for the second packet. In your live data, the name will be a different set of letters and numbers.

The direction of the arrow > indicates the direction of the traffic flow in this packet. Each system name includes a suffix with the port number (.5000 in the screenshot), which is used by the source and the destination systems for this packet.

The remaining data filters the header data for the inner TCP packet:

The flags field identifies TCP flags. In this case, the P represents the push flag, and the period . indicates it's an ACK flag. This means the packet is pushing out data.

The next field is the TCP checksum value, which is used for detecting errors in the data.

This section also includes the sequence and acknowledgement numbers, the window win size, and the length of the inner TCP packet in bytes.

Step 3: Capture network traffic with tcpdump.

Let's use tcpdump to save the captured network data to a packet capture file.

In the previous command, we used tcpdump to stream all network traffic. Here, we will use a filter and other tcpdump configuration options to save a small sample that contains only web TCP port 80 network packet data.

Capture packet data into a file called networktraffic.pcap using:

sudo tcpdump -i eth0 -nn -c9 port 80 -w networktraffic.pcap &

Press the ENTER key to get your command prompt back after running this command. Let us first of all run ls -l to list out the files and directories currently in the home directory, as pointed out by the 1st arrow, there is only sample.pcap. This command runs in the background, but some output text will appear in your terminal as pointed to by the 2nd arrow.

This command will run tcpdump in the background with the following options:

-i eth0: Capture data from the eth0 interface.
-nn: Do not attempt to resolve IP addresses or ports to names. This is best practice from a security perspective, as the lookup data may not be valid. It also prevents malicious actors from being alerted to an investigation.
-c9: Capture 9 packets of data and then exit.
port 80: Filter only port 80 traffic. This is the default HTTP port.
-w networktraffic.pcap: Save the captured data to the named file.
&: This is an instruction to the Bash shell to run the command in the background.

Notice that the networktraffic.pcap file has been created as pointed to by the 3rd arrow above, but the file at this stage is empty because we have not currently generated any web traffic that will be captured into the file; this is why the value of networktraffic.pcap file length is currentlyemptyorzero 0, circled inyellow. Remember, the command above is an instruction for web traffic (port 80) to be captured from theeth0network interface intonetworktraffic.pcap` file.

Use curl to generate some HTTP (port 80) traffic. When the curl command
curl kc7cyber.com

is used like this to open a website; it generates some HTTP (TCP port 80) traffic that can be captured as pointed to by the 4th arrow.

To verify that packet data has been captured after running curl kc7cyber.com, run the command ls -l capture.pcap and this will return the output pointed to by the fifth arrow above, but notice that the value zero 0 circled in yellow colour as pointed to by the third arrow has now changed to 977 circled in blue colour, this implies that the command curl kc7cyber.com generated some HTTP (port 80) traffic and was captured into our networktraffic.pcap file that is running in the background:

Step 4: Filter the captured packet data.

Let's use tcpdump to filter data from the packet capture file we saved previously in Step 3 above.

Use the tcpdump command, this time without the option -v, i.e. verbose.
sudo tcpdump -nn -r networktraffic.pcap

to filter the packet header data from the networktraffic.pcap capture file. You will notice that no detailed information about IP is presented here, and the output return is a bit less compared to when we use the -v option/flag. As pointed to by the 1st arrow, tcpdump is reading the packets from the packets saved in networktraffic.pcap.

This command will run tcpdump with the following options:

-nn: Disable port and protocol name lookup.
-r: Read capture data from the named file, i.e. networktraffic.pcap.

If the -v option was included, it would have displayed detailed packet data.

You must specify the -nn switch again here, as you want to make sure tcpdump does not perform name lookups of either IP addresses or ports, since this can alert threat actors.

Use the tcpdump command
bash sudo tcpdump -nn -r capture.pcap -X

to filter the extended packet data as pointed to by the 3rd arrow from the networktraffic.pcap capture file.

This command will run tcpdump with the following options:

-nn: Disable port and protocol name lookup.
-r: Read capture data from the named file i.e networktraffic.pcap.
-X: Display the hexadecimal and ASCII output format packet data. Security analysts can analyse hexadecimal and ASCII output to detect patterns or anomalies during malware analysis or forensic analysis.

Hexadecimal, also known as hex or base 16, uses 16 symbols to represent values, including the digits 0-9 and letters A, B, C, D, E, and F. American Standard Code for Information Interchange (ASCII) is a character encoding standard that uses a set of characters to represent text in digital form.

Summary.

This article explains how to use the network protocol analyser command line tool tcpdump to capture and analyse network traffic. First, we identify a network interface, then use tcpdump to filter and capture live network traffic. We explain the tcpdump command and its options, and how to interpret the output. Lastly, we explain how to save captured network data to a file and filter the data.

GitHub Repository: https://github.com/agbuenoch/analyse-packets-with-tcpdump

Connect with me.

🔗 LinkedIn
🔗 X

Kali Linux Users Account Management.

Enoch Amachundi Agbu — Mon, 16 Jun 2025 09:58:23 +0000

This project implements how to securely manage user accounts in Kali, including changing login credentials, creating new users, switching between shells and users, renaming users, deleting users, and locking/unlocking passwords and login shells.

User account management is a foundational skill for anyone working with Kali Linux, whether you're a cybersecurity student, penetration tester, or ethical hacker. This project explores how to securely manage user accounts in Kali, from creating and renaming users to disabling logins and deleting users. While Kali is built for offensive security, proper user control is essential to maintain a secure and organised environment.

Step 1: How to Change Login Credentials.

The default username and password that come preinstalled with the Kali Linux pre-built image are kali and kali, respectively. Let's change the password to something more secure while we maintain the username kali.

Open the Kali Linux terminal by clicking on the terminal as pointed to by the 1st arrow. The username and host/machine name is kali and kali as pointed to by the 2nd and 3rd arrow, respectively. Run whoami to check/view the current user logged in as pointed to by the 4th arrow.

Run passwd to change the kali username password by providing the current password and then the new password. The 5th arrow points out that the password was changed successfully.

The password for the kali username is now changed from kali to the new password we provided.

Check if the current user can elevate to root privileges.

Run either the commands id or groups, or groups kali. You'll see something like this below as pointed to by the 1st arrow:

uid=1000(kali) gid=1000(kali) groups=1000(kali),27(sudo)

Where:

uid=0 refers to a root user.
uid=1000 and above refers to a regular user. But if sudo appears in the groups as pointed to by the 2nd arrow, it means this regular user can elevate its privileges, i.e it can use the sudo command and operate with root privileges.

Step 2: Create New Users.

Let's view the current list of all users before we create new ones. Run ls /home to print out a list of all users in this Kali Linux system. As pointed out by the 1st arrow, there is currently only one user, which is kali.

Alternatively, we can run cat /etc/passwd to view detailed user information like the group and shells they belong to, compared to just listing the username as shown above. In Kali Linux, like all Linux distributions, all local users are listed in the system file.

The path /etc/passwd contains the list of all users. This file contains a record of every user account on the system. From the screenshot below, the 1st arrow points to three user account root, daemon, and bin. As underlined, the root user's home directory is /root and uses zsh as its login shell (this is one among many shell types like bash, fsh, and ksh). Where you see /nologin means that the user's login shell has been locked or disabled and cannot log in to the system.

The 2nd arrow points to another user called kali, the 3rd and 4th arrows point to the kali home directory and default login shell, respectively.

Each user is on a separate line with fields separated by colons : in this format below.

username : password : UID : GID : comment : home_directory : login_shell

The table below explains the components of the kali username information above as pointed to by the 2nd, 3rd and 4th arrows.

| Fields | Descriptions |
|------------|------------------|
| kali | Username |
| x | Password placeholder (actual password is in /etc/shadow) |
| 1000 | UID (If user ID = 0, it’s a root user, if ID=1000+ it’s a normal/regular user), 1000 GID (Group ID) |
| ,,, | Description/Comment (optional) |
| /home/kali | Home directory |
| /bin/zsh | Default login shell |

NOTE: Kali recently switched its default shell from bash to zsh to give users more power and flexibility.

You can switch between shells at any time.
Let's use the demouser to switch between the shells. Run echo $SHELL to view the demouser login shell as pointed to by the 1st arrow. Run chsh -s /bin/zsh to change the demouser login shell from bash to zsh as pointed to by the 2nd arrow, and you will be prompted for the demouser password.

To apply the changes, log out from the demouser as pointed by the 3rd arrow. The 4th arrow points to kali user after logging out from the demouser. Let’s log back in to demouser as pointed to by the 5th arrow. The 6th arrow points to the demouser currently logged in. Run echo $SHELL again to view that the shell has been changed successfully as pointed to by the 7th arrow

Currently, the demouser login shell is zsh as pointed to by the 1st arrow. Run chsh -s /bin/bash to change the shell to bash, the rest of the steps are similar to the steps just explained above. Logout by running exit and re-log in to the demouser, run echo $SHELL to confirm the changes have been applied.

Where Are Passwords Stored?
Passwords are not stored in /etc/passwd for security. Instead, they’re kept in /etc/shadow, readable only by the root user. To view it, run sudo cat /etc/shadow, you’ll see encrypted password hashes.

Therefore, let's create two new users, demouser and adminuser and add adminuser to the sudo group, making it an admin/super user. By this, adminuser can use the sudo command and root user privileges. Ensure the usernames are spelt in lowercase letters.

Run sudo adduser <username> to create a new user. Each new user created would be assigned a User ID (UID) and Group ID (GID) ranging between 1000 and 59999, as pointed to by the 1st arrow. A home directory of /home/<username> would be created for the new user as pointed to by the 2nd arrow. You will be prompted to set a password for the user as pointed to by the 3rd arrow. You have other information like the user's full name, which is optional, and you can press the ENTER key as pointed to by the 4th arrow to skip each entry.

For every new user created, a group bearing the same name as the username will be created, and the new user will be added to that group and also to an additional group called users. Therefore, demouser is added to a group called demouser and users, as pointed to by the 5th and 6th arrows, respectively.

Apply the same step above to create adminuser, and notice that adminuser is added to a group called adminuser and users, as pointed to by the 5th arrow and 6th arrows, respectively.

Run sudo cat /etc/passwd to view the two new users we created above. The 1st arrow points to the users we created, and the underlined /bash is the default login shell for the users.

From the screenshot below, we are currently operating as kali user. Run echo $SHELL to view the user login shell, which is zsh as pointed to by the 1st arrow.

The 2nd and 3rd arrows point to all the groups user kali is a member of, among the groups is sudo, which means user kali can switch to a root user capability.

The 4th and 5th arrows point to the groups demouser is a member of. Because sudo is not listed, the user demouser cannot use sudo command or switch to a root user capability.

The 6th and 7th arrows point to the groups the adminuser is a member of. At the moment, it cannot assume a root capability or privileges because it does not belong to the sudo group. Notice that the group called sudo is not listed among the groups.

Alternatively, you can run the command groups to see all the groups the current user kali belongs to, as pointed to by the 1st arrow.

Let’s make adminuser a root user. This will enable the adminuser to be able to assume a super/root user capability, which is to be able to run the sudo command, so let's add the adminuser to the sudo group. As pointed by the 1st arrow, provide the password of the user kali running the sudo command.

After adding adminuser to the sudo group, run groups adminuser, notice the sudo group have been added to the list of groups it belongs to, as pointed to by the 2nd arrow.

Command Breakdown:
sudo means run the command as a superuser (admin privileges).

usermod stands for user modify – it lets you change user account settings.

-a means append (don’t remove them from other groups). -G means Group (you’re specifying the group(s) the user should belong to).

sudo The group you're adding the user to — on Debian-based systems like Kali, the sudo group permits its members to run sudo commands.

adminuser This is the username of the account you're giving sudo access to.

Step 3: Switch between users.

Run the command su - <username> to switch between users. You'll be prompted for that user’s password. The dash - loads the user’s full environment (like their shell settings).

Run the command sudo su - or sudo -i to switch from any user that has root privileges to the default root user (which always appears in red).

But switching to the default root user from a regular user who does not have root privileges (i.e does not belong to the sudo group), just run su -, and you will be required to provide the default root user password, which by default does not exist unless you set it. Therefore, we will stick to this command: sudo su - or sudo -i instead.

To switch to a default root user, you will be prompted for the current user password and NOT the default root user password because it has no password set by default.

Let's switch to the user called root (i.e the default root user). As pointed to by the 1st arrow, you’ll be prompted for the kali user's password, not root's password (because root may not have a password set by default). A super/root privilege is required, hence, we must use sudo to run su -, as shown below. And because the user kali belongs to the sudo group, the sudo command can be used by the kali user.

After switching to the default root user, run the pwd to print the working directory, which is now /root as pointed to by the 2nd arrow.

To switch back to a regular user, run su - <username>, as pointed to by the 4th arrow, we are back to the kali user.

By default, Kali does not enable the default root account with a password anymore. Therefore, if you try switching to default root user by running the command su - as pointed out by the 1st arrow, you will be asked for the `default root user password as pointed out by the 2nd arrow, which is NOT enabled by default. Therefore, the authentication will fail as pointed out by the 3rd arrow, since there is no password previously set for it.

We can manually set the default root user password using sudo passwd root, You’ll be prompted to enter and confirm a new root password. After that, we can switch to the default root user by running su - without using sudo. But this is not recommended for daily use. The best practice is to use sudo with a regular user instead of logging in as root directly, for security and auditing.

On this premise, because the kali user has sudo privileges (belongs to the sudo group), for best security practice, we will use sudo to switch or log in to the default root user by running sudo su -

So far, from the users we created, we can only switch to the default root user from the kali and adminuser users using sudo because they belong to the sudo group.

But once we've set a password for the default root account (which is not recommended), we can absolutely use just su - command from any regular user account to switch to the default root user.

If you’re logged in as one user and want to go back to your previous user session, just run exit to log out or su - <username> without logging out from the current user session. The-` loads the user’s full environment (like their shell settings).

Alternatively, you can switch to the default root user with sudo -i as pointed to by the 1st arrow. After providing the current user password, we are logged in as the root user, which appears in red. Exit the default root user by running exit as pointed to by the 2nd arrow.

Let's verify that the adminuser now has sudo privileges. As pointed out by the 1st arrow, switch to the adminuser. Remember that adminuser is a regular user who can elevate to root user/privilege. Therefore, if you run just whoami, it will return the regular username adminuser as pointed to by the 2nd and 3rd arrows. The command pwd will print the current working directory as pointed out by the 4th arrow. Meanwhile, if you run sudo whoami, it will return the root username as pointed to by the 5th arrow. Therefore, it is confirmed that adminuser can elevate to a root user/privileges.

Remember the user kali is a regular user as pointed to by the 2nd arrow, who is also a member of sudo group as pointed to by the 1st arrow, which means it can elevate to a root user/privileges as pointed to by the 3rd arrow, just like the adminuser we created above.

Let’s try using a root user privilege like running the command sudo with a user that is NOT in a sudo group, like demouser.

Switch to the demouser as pointed to by the 1st arrow. We run pwd to see the current user we are operating as, pointed to by the 2nd arrow. The 3rd arrow points to the group demouser is a member of; notice sudo is not listed. As pointed out by the 4th arrow, we tried using sudo command but because the current user demouser is not a member of the sudo group, we get the warning message pointed to by the 5th arrow.

Step 4: Renaming a user.

We can change the adminuser name to something else, but it involves more than just renaming the user. We also need to update the home directory and permissions properly to avoid login issues.

Let’s go step-by-step to safely rename the adminuser to myadmin.

⚠️ Important: Don’t do this while logged in as the adminuser user. First, create another temporary admin user called tmpadmin, and log in as tmpadmin to perform the renaming.

Create a new user, tmpadmin, following the same steps as done in Step 2 above. The tmpadmin user will be placed inside both the tmpadmin and users groups as pointed to by the 3rd and 7th arrows.

After creating the new user, tmpadmin, run sudo cat /etc/passwd to verify the user adminuser is listed as pointed to by the 1st arrow with the home directory and default login shell underlined.

The tmpadmin created above is a regular user; let's add it to the sudo group so that it can be able to run the sudo command and elevate to root user/privileges. Run sudo usermod -aG sudo tmpadmin as pointed to by the 1st arrow. Notice that sudo is now listed among the groups, tmpadmin is a member of, as pointed to by the 2nd arrow.

Let’s run whoami and pwd to show the adminuser username and home directory, respectively, before renaming. First, let’s switch to the adminuser as pointed to by the 1st arrow to provide its password. We have successfully switched to the adminuser as pointed to by the 2nd arrow. Because adminuser is a regular user and can elevate to a root user/privileges, when you run whoami and sudo whoami, it will return the username adminuser (i.e the regular username) and root (i.e the root username) respectively as pointed to by the 3rd and 4th arrow. pwd will print the regular username adminuser working directory as pointed to by the 5th arrow.

Completely log out from the adminuser by running exit as pointed to by the 1st arrow, before switching or logging in to tmpadmin. Run ls /home to print out all the current users on the Kali Linux system as pointed to by the 2nd arrow. Let’s log in to the temporary admin we created, tmpadmin, as pointed to by the 3rd arrow. Notice we switch to tmpadmin using su - tmpadmin without using the sudo command, this is because the tmpadmin, unlike the default root user that came with Kali Linux, has a password set for it when we were creating it. After running the command, we are prompted for the tmpadmin password. As pointed out by the 4th and 5th arrow, run whoami and sudo whoami to view the regular and root username, which are tmpadmin and root, respectively.

The goal is to rename the underlined username adminuser pointed to by the 2nd arrow to myadmin and move/rename the home directory from /home/adminuser to /home/myadmin.

Run sudo usermod -l myadmin adminuser to rename the username adminuser to myadmin as pointed to by the 1st arrow. Run sudo mv /home/adminuser /home/myadmin to move the username adminuser's home directory /home/adminuser to myadmin's home directory /home/myadmin as pointed to by the 2nd arrow, and update the home directory Info for the user by running sudo usermod -d /home/myadmin -m myadmin as pointed to by the 3rd arrow.

-d = new home directory.
-m = move contents from the old home.

After applying all the changes, verify everything works. Run ls /home to list all the usernames. As pointed out by the 1st arrow, the adminuser has been renamed to myadmin as shown underlined. The command id <username> confirmed all the changes have been applied correctly, as shown underlined and pointed to by the 2nd arrow.

Run exit to log out from tmpadmin as pointed to by the 1st arrow, this returns us to the previous user session, which is kali as pointed to by the A arrow, since it was from kali we previously moved to tmpadmin. Log in to myadmin as pointed to by the 2nd arrow, the B arrow shows we are now logged in as myadmin. Run whoami to confirm the username adminuser has changed to myadmin and sudo whoami to ensure it still returns root as pointed to by the 3rd and 4th arrow, respectively. Run pwd as pointed to by the 5th arrow to confirm the home directory has also been moved/renamed to /home/myadmin.

Step 5: Delete a user.

Let’s remove or delete the temporary admin user, tmpadmin, that we created above in Step 4.

Run sudo deluser --remove-home <username> to delete any specified user. The 1st arrow points to the info removing the tmpadmin user. Run ls /home to list all users, and as pointed to by the 2nd arrow, the tmpadmin user is no longer listed.

Reboot to Apply all the Changes.

Run sudo reboot and wait for a few seconds to reboot the system as pointed to by the 1st arrow.

Step 6: Lock a user.

Locking a user account in Linux (including Kali) prevents a user from logging in, without deleting the user or their files. This is useful for suspending access temporarily.

Run sudo usermod -L <username> to lock/disable a user account/password. This will prepend an exclamation mark ! to the password hash in /etc/shadow.

Let's view the /etc/shadow before locking the demouser account. We are currently operating as a Kali user. Run the command sudo cat/etc/shadow and provide the sudo password for Kali, as pointed to by the first arrow, to view hashed passwords for all users. The 2nd arrow points to the demouser's hashed password. Notice there is no exclamation mark ! placed at the beginning of the hashed password in field 2, immediately after kali: in field 1.

Let us have a peek at a sample entry format from /etc/shadow

username : $id$hashed-password : lastchg : min : max : warn : inactive : expire : reserved

View: step6A3

View: step6A4

Field	Description
username	The login name of the user (e.g., kali)
hashed-password	The user's hashed password.
lastchg	Days since January 1, 1970, that the password was last changed (e.g., 20432 days)
min	Minimum number of days between password changes (e.g., 0)
max	Maximum number of days the password is valid (e.g., 99999 = 273 years = "never expire")
warn	Number of days before the password expires that the user gets warned (e.g., 7 days)
inactive	Days after the password expires before the account is disabled (blank or -1 means disabled immediately)
expire	Days since Jan 1, 1970, when the account will be disabled (blank = never expires)
reserved	Reserved for future use (usually empty)

Password Field Special Cases (Field 2):

$6$...: Encrypted password (SHA-512 hash)
!: Account is locked
*: No password set (This cannot be used for login)
: A blank space means the password login is disabled

Run sudo usermod -L <username> or sudo passwd -l <username> to lock the demouser. Note that if you use the latter option, you will receive a response that the passwd: password changed, which means the user has been locked. After executing the command as pointed to by the 1st arrow, if successful, you will be directed to the next prompt.

After locking the user, notice the exclamation mark ! placed at the beginning of the hashed password as pointed to by the 2nd arrow.

Because the demouser password has been locked, it cannot log in to the system as pointed to by the 2nd arrow.

Though the demouser password has been locked, its login shell is still operational, which is why, with a root user privilege as pointed to by the 1st arrow, you can bypass and log in to the demouser account. As pointed out by the 2nd arrow, we successfully log in to the demouser account directly without providing a password. Look at Step 7 below on how to completely disable any user login shell to completely disable anyone from logging in to a particular user account.

A root user can bypass and log in directly to any (both root and regular) user account, EXCEPT if the login shell of the user is disabled; otherwise, the root user will only be authenticated to provide its own root user password to prove it's a root user.

To Unlock the User.

Run the command sudo usermod -U <username> or sudo passwd -u <username>

Note that if you use the latter option, you will receive a response that the passwd: password changed, which means the user has been unlocked. If the unlocking command is executed successfully as pointed to by the 1st arrow, you will be directed to the next prompt.

As pointed out by the 2nd arrow below, the exclamation mark ! has been removed; therefore, the demouser has been unlocked.

Check User Password Status.
Run the command pointed to by the 1st arrow. The option/flag -l will list the account ageing information.

Run the command sudo change -l as pointed to by the 1st arrow to view a user's password status. The option/flag -l will list the account ageing information.

Notes:

Locking does not affect processes already running under that user.
If you're using key-based authentication (SSH), locking the password/user account might not stop the user from logging in — you'll need to disable their shell or revoke their SSH key too.

Step 7: Disable a User's Shell in Kali/Linux.

Disabling a user’s shell is a smart way to block interactive logins, even if they use SSH with key-based authentication. This method is especially useful in hardening systems or disabling dormant accounts without deleting them.

Option 1: Set Shell to /usr/sbin/nologin (Preferred method).

Run the command
` sudo cat /etc/passwd `
As pointed out by the 1st arrow, to view all users. The 2nd arrow points to the demouser and the demouser login shell bash, is underlined.

The command
` sudo usermod -s /usr/sbin/nologin <username> `
will disable the demouser login shell as pointed to by the 1st arrow. Run the command sudo cat /etc/passwd to view the users list again. As pointed to by the 3rd arrow, the demouser login shell has changed from /bin/bash to /usr/sbin/nologin, hence demouser cannot use or log in to its login shell bash.

Because the demouser login shell /usr/sbin/nologin has been disabled, it cannot log in to the system as pointed to by the 2nd arrow.

Not even a root user can access or log in to the demouser account as pointed to by the 3rd and 4th arrow below, because the login shell - bash has been completely disabled.

Option 2: Set Shell to /bin/false (Alternative method)

Run the command
` sudo usermod -s /bin/false <username> `
As pointed by the 1st arrow to disable the login shell. If successful, you will be directed to the next prompt, where we run a command as pointed to by the 2nd arrow to view the list of all users.

The 3rd arrow in the screenshot below points to the demouser, and the demouser's login shell /bin/bash changed to /bin/false, shown underlined. After locking the demouser, try switching to the demouser as pointed to by the 4th arrow to provide the demouser password, you can see the log in or switching fails because we were redirected back to the kali user as pointed to by the 5th arrow, and NOT demouser as expected. Not even the root user can log in, just as demonstrated in Option 1 above, because the login shell has been set to false.

To Re-enable Login.
Run the command
` sudo usermod -s /bin/bash <username> `
to unlock the demouser as pointed to by the 6th arrow, and run sudo cat /etc/passwd to print the list of all users as pointed to by the 7th arrow to confirm it. The 8th arrow points to the demouser and shows that its login shell has changed from /bin/false to /bin/bash.

We can now log in or switch to the demouser account.

GitHub Repository: https://github.com/agbuenoch/kali-linux-users-account-management

Connect with me.

🔗 LinkedIn
🔗 X

Ubuntu Server Security Hardening with Ubuntu Security Guide (USG).

Enoch Amachundi Agbu — Fri, 13 Jun 2025 09:52:59 +0000

In this Project Cybersecurity Home Lab: Installs Ubuntu Server On VMware Workstation Pro, I walked through installing Ubuntu Server on VMware Workstation Pro. This project will guide you through the fundamental steps to secure the Ubuntu server before using it for log analysis, Wazuh management, or as a monitored endpoint.

The Centre for Internet Security (CIS) benchmark has provided hundreds of configuration recommendations, but manually hardening and auditing a Linux system can be tedious and error-prone.

Ubuntu Security Guide (USG) is a new and automated cybersecurity tool available with Ubuntu 20.04 LTS. It is part of Ubuntu Pro Service and installed using the “Ubuntu Pro client.” With USG, hardening an Ubuntu system becomes much easier. USG is used to harden and audit Ubuntu systems to check if they are still compliant with the CIS Benchmark.

The Ubuntu Pro client is a tool designed to automate access to Ubuntu Pro services like Extended Security Maintenance (ESM), Ubuntu Security Guide (USG), Federal Information Processing Standards (FIPS), and more.

It is recommended to apply the security hardening on a freshly installed Ubuntu and not on a production system.

Pre-requisite: You must have or enable Ubuntu Pro as a prerequisite for using Ubuntu Security Guide (USG), this is because USG is one of the services of “Ubuntu Pro”.

When you need help on how to install any command in Bash, and you have no idea how to do it, just type:
<command name>
or
<command name> --help
Replace <command name> with the actual command you want to install and press ENTER. The terminal will provide you with the official/appropriate name and command to install it.

Step 1: Register for Ubuntu Pro and attach it to your Ubuntu Server.

Go to: https://ubuntu.com/pro/subscribe
Sign in or create a free Ubuntu One account.
Generate your free personal-use token (valid for up to 5 machines).
Copy the token. This is used when attaching Ubuntu Pro to the Ubuntu server.

The above step has been explicitly explained in the project Cybersecurity Home Lab: Installs Ubuntu Server On VMware Workstation Pro.

Step 2: Update and Upgrade Your System.

Run the green command to update and upgrade the Ubuntu server. As the arrow indicates, provide the Ubuntu server user password.

Step 3: Install “Ubuntu Pro Client”.

The Ubuntu Pro client is a command-line utility (pro) that connects your Ubuntu machine to Ubuntu Pro services like Extended Security Maintenance (ESM), Compliance tools like USG (Ubuntu Security Guide), Federal Information Processing Standards (FIPS) 140-2 certified cryptographic modules (for enterprise/government compliance), and more.

Run the command in green and provide the Ubuntu server user password when prompted, as pointed to by the 1st arrow. The 2nd, 3rd and 4th arrows point to the sequential steps for the installation of the Ubuntu Pro Client.

After it successfully installs the pro command-line tool. Let's verify/confirm that the pro command is installed in our terminal.

As pointed out by the 1st arrow, if the command is installed, the terminal will present you with the usage guide on how to use the command, and other vital information about the command as pointed to by the 2nd arrow.

Step 4: Verify and view all Ubuntu Pro Services.

Let's view all the Ubuntu Pro services that Ubuntu Pro clients can access by running the command in green. As pointed to by the 1st arrow, the esm-apps service is enabled (This was done by completing Step 1 above), which offers the Ubuntu system an extended 10+ years of security maintenance. The USG service is currently disabled as pointed to by the 2nd arrow. The 3rd arrow shows how to enable any of the Ubuntu Pro services, which can be achieved by using the Ubuntu Pro client (i.e pro command). This must be enabled so that we can use the service to perform an audit and fix our Ubuntu system following the CIS benchmark security. The 4th arrow points to the statement that we are using or subscribed to Ubuntu Pro on this Ubuntu system.

Ensure esm and usg are available or enabled.

Step 5: Enable and install the USG Tool.

From the screenshot above, you can see that the usg Ubuntu Pro service is disabled as pointed to by the 2nd arrow. Let’s enable the usg service.

Run the command in green, and provide the Ubuntu server user password when prompted, as pointed to by the 1st arrow. The 2nd arrow points to the statement that confirms USG (Ubuntu Security Guide) is enabled.

This will enable the Ubuntu Security Guide (USG) utility. Checking the Ubuntu Pro Services again this time shows that the USG service is enabled as pointed to by the arrows below.

But I do not currently have the usg command installed yet on my Ubuntu server terminal, this will result in an error if you try to use the command.

Let’s first confirm if the “usg” command is NOT installed. As pointed to by the 1st arrow, the command is not found; meanwhile, the 2nd arrow points to the statement that provides the command to install the intended command, i.e usg.

Run the command in green to install the “usg” command. As pointed by the 1st arrow, provide the Ubuntu server password when prompted.

Let’s verify it is installed. As pointed by the 1st and 2nd arrow, the usage and additional information provided about the usg command imply that it is installed.

Step 6: Audit Your Ubuntu Server Against CIS Benchmark.

Run the command in green to audit the Ubuntu server system against the CIS security benchmark. This process will take a couple of minutes to perform the system audit.

Each audit is presented as Title, Rule, and Result. The audit result for each rule will either be pass or fail, as shown below.

After it successfully performed the audit, the audit report can be found in the path I highlighted in yellow. Note also that the report is given in two formats, as .html and .XML, as pointed to by the 1st and 2nd arrow.

Step 7: Access and open the Audit Report.

The /var/lib/ directory is owned by system services, so most subfolders require sudo or completely switch to a root user for you to be able to access the subfolders in /var/lib, where the audit and fix reports are saved.

Let's temporarily switch to a root user and navigate to the /usg/ folder by running cd /var/lib/usg/ to view our audit reports, which are highlighted in yellow and pink below. Type exit to switch back to a regular user at any time.

A regular user prompt is signified with a dollar sign $ as pointed to by the 1st arrow. When we switch to a root user by running sudo -i, the prompt symbol changes to a hash sign # as pointed by the 3rd arrow. When we try to print the working directory pwd, you can see that it is /root as pointed by the 2nd arrow.

Alternatively, we can copy all the reports to the home directory for easier viewing without switching to the root user. We can then work with it later or copy the files from the home directory to our host machine. Since I am logged in as a root user, there is no need to use sudo in the command below.

cp /var/lib/usg/*.* ~/

The * means all file names with zero or more characters length, followed by a period ., and then all file extensions with zero or more characters length. This will copy all files that are in the /var/lib/usg/ folder that satisfy the regular expression *.*

The ~/ means home directory (in my case, it is /home/agbuenoch). Navigate to the home directory, and you will see all the files copied from the /var/lib/usg/ directory in the home directory.

The 1st arrow points to the dollar sign $, implying we are currently operating as a regular user. Run whoami to print out the current username as pointed to by the 2nd arrow. The command pwd will print the current directory of the regular user, which is pointed to by the 3rd arrow.

The command sudo -i will switch the regular user to the root user as pointed to by the arrow immediately below the line where we run the sudo command. The hash symbol pointed to by the 4th arrow indicates we are now operating as the root user, and when you run pwd, it prints out that we are in the root directory, as pointed out by the 5th arrow.

Still operating as the root user, we change the directory to /var/lib/usg/, and we run ls -l to print out all files and directories within the current directory /var/lib/usg/. The 6th arrow points to the files residing in the /usg/ directory.

The command cp ./*.* ~/ copied all the files *.* from the current directory ./ to the home directory ~/. Run exit to log out the root user as pointed to by the 7th arrow, back to the regular user as pointed to by the 8th arrow, which now shows a dollar sign. At this point, we run whoami and pwd, and it prints the regular username agbuenoch and current directory /home/agbuenoch pointed by the 9th arrow, respectively.

Therefore, when we run ls -l, we can see the files we copied from /var/lib/usg/ as the root user in the home directory as pointed to by the 10th arrow.

Option A: How to view the .html file audit report.

Ubuntu Server is CLI-based; it does not have a GUI (Graphical User Interface) or a DISPLAY environment to launch GUI apps. To view the report, both files .html and .xml can be copied to the host machine (the computer running VMware) or to another Windows client virtual machine.

The two audit report files generated are pointed to by the 1st and 2nd arrows.

If you have a Windows Subsystem for Linux (WSL) running on a Windows client machine, with SSH installed and enabled, run the command below on your Ubuntu server terminal to copy the .html and .xml file report to the Windows client machine so you can view it in a browser.

sudo scp /ubuntu-server/path/to/filename <WSL-username>@<WSL-ip>:"/mnt/c/Users/windows-nameofuser/.../destination/"

The article: File Sharing using scp and rsync explains how to copy/share files between an Ubuntu server and a Windows client machine.

After running the command, you will be authenticated to provide the source system (Ubuntu server VM) user password as pointed to by the 1st arrow. You will also be authenticated against the Windows client machine (the destination system) you want to copy to, as pointed to by the 2nd arrow. The .html file was successfully copied to the Windows client machine as pointed to by the 3rd arrow and the 4th arrow, showing that the file was copied 100%.

Voila! The USG report file copied to the Windows client machine desktop is opened from the desktop as pointed to by the 1st arrow, using the Chrome browser.

Scroll through to view the security checks that passed and/or failed, including other security statistics. The 1st arrow points to the target system that was audited, and the 2nd arrow points to the username that performed the audit.

Scrolling further down is the compliance and scoring. The Ubuntu server failed to satisfy the conditions of 124 rules. 224 conditions rules were passed, and 124 failed, with a 70.87% pass rate as pointed by the 4th arrow. This report will be compared with the subsequent report generated after applying the CIS benchmark security.

Option B: How to view the `.xml` file audit report.

The .xml file can be copied to and viewed on the host machine with any browser or code editor like VS Code Studio or Sublime. To copy the .xml file, run exactly the above command shown in the screenshot above, replacing the .html file name with the .xml file name.

Viewing the .xml file in VS Code.

You can view the .xml file right in the Ubuntu server terminal like any text file, although it may look unreadable/unorganised.

Scroll through the file neatly by using the “less” command, press ENTER to keep reading through each page, and press CTRL+Z to opt out of the reading.

After running the command above, below is a snippet of the .xml file contents.

Step 8: Apply CIS Benchmark Fixes Automatically.

HIGHLY RECOMMENDED: Before applying the CIS benchmark security hardening, it's best to back up your virtual machine (VM) or take a snapshot. We will take a snapshot of the VM. While your Ubuntu server is running, follow the marked arrows sequentially to take a snapshot of the server. This is important because you can easily roll back to your Ubuntu server stable version/state in the event you break something or get stuck somewhere in your server.

Provide a snapshot name of your choice as pointed by the 1st arrow.

To revert to any of your snapshots, follow the sequence of the arrows below and click on the name of the snapshot you want to revert to. The 3rd arrow points to the name of a snapshot I created.

We have saved the current state of the freshly installed Ubuntu server using a snapshot. Let’s apply the security recommendations:

Run the command in green, and provide the Ubuntu server password as pointed to by the 1st arrow for authentication before the CIS benchmark is applied. Before the CIS benchmark security is fixed/applied, the system will always be audited first, as pointed out by the 2nd arrow. Each time you run the command to fix/apply the CIS benchmark, an audit must first be carried out. If you read along to the second line of the line pointed to by the 2nd arrow, you will see --results followed by a path; this is where the audit report will be saved.

The 1st arrow points to just a part of the audit carried out. After successfully auditing the system, the CIS benchmark will be applied. The 1st, 2nd and 3rd arrows point to the system files that will get executed to implement the CIS benchmark security. The 4th arrow points to the commencement of the fixing process, starting with the first one remediating rule 1/402 down until it remediates 402/402.

The USG fix is done as pointed to by the 1st arrow.

After remediating rule 402/402, reboot the system to complete the process, as pointed to by the 2nd arrow. Perform another audit as pointed to by the 3rd arrow, after you have applied the CIS benchmark security. This will help to compare whether the security hardening has improved.

Run sudo reboot to reboot the server as shown in the screenshot below.

This fix process will: Harden SSH settings, configure file permissions, disable unnecessary services, apply password policies, and more. The Ubuntu server security is hardened and stricter now, as pointed out by the 1st arrow.

Step 9: Re-audit After Reboot.

After reboot, rerun the audit, and compare the audit report with the previous report generated before applying the CIS benchmark security hardening:

Before running the audit, let's check and mark the audit report generated earlier, before we applied the CIS benchmark security above in Step 8. The 1st and 2nd arrows point to the audit report generated from the last audit we performed in Step 6. The other reports you see were generated when we ran the fix command to apply the CIS benchmark security. I have run the fix command multiple times, which is why you can see multiple reports there. Remember, each time we apply the CIS benchmark, an audit is first performed before the fix.

Run sudo usg audit cis_level1_server to check the compliance scores after we have fixed/applied the CIS benchmark security.

Currently, we are operating as the root user, as pointed to by the 1st arrow. Run exit to log out from the root user pointed to by the 2nd arrow. The 3rd arrow points to the dollar sign $, meaning a regular user.

After running the audit command, the 4th arrow points to the flag/option --result, meanwhile the 5th arrow points to the path/directory where the result is stored /var/lib/usg/, the .xml file is the file name containing the audit report.

Just as shown above, once the audit is complete, the 1st arrow points that the audit is complete and shows us where to find the audit report as pointed to by the 2nd and 3rd arrows.

To access the audit report, we need root user privileges. Run sudo -i to switch to the root user. We navigate to the /var/lib/usg/ directory and ls -l out the path contents. The 1st and 2nd arrows point to the audit report (.html and .xml) just generated.

Run the command pointed to by the 1st arrow to copy the .html file pointed to by the 2nd arrow to the home directory so that we can access it anytime without root user privileges.

After we have successfully copied the file to the home directory. Let's copy the file to a Windows client machine so that we can view the .html file.

Using a different approach, from the Windows Subsystem for Linux (WSL) running on the Windows client machine, SSH into the Ubuntu server VM, and copy the .html file in the home directory to the Windows client machine desktop folder/path.

To remotely SSH connect to the Ubuntu server, run:

ssh <Ubuntu-server-username>@<Ubuntu-server-ip>

You will be required to enter the remote machine (Ubuntu server VM) password to be able to connect to it. I have successfully remotely connected to the Ubuntu server, so I run whoami to print the Ubuntu server username as pointed out by 1st arrow, pwd to print the current directory as pointed out by 2nd arrow, and ls -l to list the directory contents as pointed out by 3rd arrow. The 4th arrow points to the command (spanning two lines) that will copy the .html file from the remote machine (Ubuntu server VM) home directory to the Windows client machine desktop path. You will provide the destination system (Windows client machine) password to authenticate you to copy to the machine, as pointed out by the 5th arrow. The 6th and 7th arrows point to the file successfully copied to the Windows client machine.

Let’s confirm that the compliance score has improved. Below is a snippet of the audit report before we applied the CIS benchmark security, with just a 70.87% success rate and 124 rule results failed.

Meanwhile, here is the audit report after applying the CIS benchmark security. There is a clear improvement compared to the initial report, where only 9 rule conditions failed.

The 1st arrow points to the target system audited, the 2nd arrow points to the username that performed the audit.

The post-hardening audit results show significantly improved CIS Level 1 Server Benchmark compliance, with only 9 rules, results that failed and a 92.24% success rate.

GitHub Repository: https://github.com/agbuenoch/security-hardening-with-ubuntu-security-guide-USG"

Connect with me.

🔗 LinkedIn
🔗 X

File Sharing using scp and rsync.

Enoch Amachundi Agbu — Mon, 09 Jun 2025 12:35:23 +0000

One essential requirement for building a powerful home cybersecurity lab is the ability to securely and efficiently transfer files between your Ubuntu Server VM and your Windows client machine.

This project implemented two methods to transfer files, all from the Ubuntu server VM terminal, covering:

SCP (Secure Copy over SSH)
Rsync (Fast file sync)

IMPORTANT:

For best security practices, use virtual machines for the Ubuntu Server and Windows Client Machines.
Ensure the systems have a means of authenticating users, that is username and password for login to the systems. This is because, during file sharing, you will be prompted to provide both the source and destination system passwords.
SSH and rsync must be installed and enabled on the two systems that intend to share/copy files.
To confirm if a command/tool is installed on a Linux terminal, type commandName or commandName --version or commandName> --help, if it returns the version or usage information, it means that the command/tool is installed, otherwise it will output that the command <commandName> not found or is not recognise, and it will provide you with the command to install that specific command/tool.
When copying files, always include the file extension when writing file names, for example myfile.html, packet.pcap, test.txt etc.
Disable your SSH service when not in use.
Anything inside the symbol <> is a placeholder; replace it, including the symbol, with your system's values or argument.

Step 1: Settings/Configurations of “SSH and rsync” on Ubuntu Server VM.

First, view the IP address of your Ubuntu server VM. Look for an entry under the inet section usually for the interface eth0, or ens33. This will show the IP address pointed to by the 1st and 2nd arrows.

Run ssh --version to verify SSH is installed. The usage information is returned, which means SSH is already installed on the Ubuntu server VM as pointed to by the 2nd arrow.

In an instance where a command is not yet installed, the terminal will not return the version/usage information, and it will provide you with a guide or command to install the specific command. For example, Wireshark is not yet installed, as pointed to by the 1st arrow. The 2nd arrow points to the command provided by the terminal to install the Wireshark tool.

Let's verify that “rsync” is installed on our Ubuntu server VM. As pointed out by the 1st arrow, the command returned the version and usage information.

We can also verify the status of the SSH service, as pointed out by the 2nd arrow below, the “SSH” service on the Ubuntu server VM is enabled and actively running.

Unlike “SSH” as shown above, “rsync” does not need to be enabled or running as a service (daemon) to work for file copying. So you can ignore the rsync “inactive (dead)” service status as pointed to by the 1st arrow, and use “rsync” normally for all your file transfer tasks.

The rsync service shows inactive (dead) because by default, the rsync service (daemon mode) is not automatically used unless we configure it explicitly with a valid rsyncd.conf file and start it as a daemon.

Verify SSH access to see if we can SSH into the Ubuntu server VM manually. You will be prompted for the Ubuntu server VM password as pointed to by the 1st arrow. If successful, you will get a “Welcome to Ubuntu ...” message as underlined below.

Run: ssh <Ubuntu_Username>@<Ubuntu_IPv4>

We have ensured SSH is enabled/installed on the Ubuntu server VM, and “rsync” is also installed.

Step 2: Settings/Configurations of “SSH and rsync” on Windows Client Machine.

The Windows client machine is also required to have an SSH server installed and running. Therefore, let's install “SSH” on the Windows client machine and ensure “rsync” (via WSL) is also installed.

OPTION A: Using Windows Subsystem for Linux (WSL) (PREFERRED/RECOMMENDED).

We will be using WSL alongside the Ubuntu server VM terminal for a seamless, consistent Linux environment for file sharing and copying, with full access to Linux tools like “rsync”, as well as integration with the Windows system. This will help keep everything simple and efficient.

If you do not have Windows Subsystem for Linux (WSL) installed in your Windows client machine, run the command pointed to by the 1st arrow using PowerShell to begin the download of “Ubuntu”, but if you already have WSL, skip the WSL installation step to the next step. The 2nd arrow points to the downloading progress of “Ubuntu”, which is currently at 1.5% as shown below.

After successfully installing the WSL (Ubuntu), search for “Ubuntu or Terminal” on your Windows client machine and open it. By default, you will be presented with the PowerShell interface first. Click on the caret symbol for a drop-down of other shells and click on “Ubuntu” as pointed to by the 1st and 2nd arrows, respectively.

Install SSH (A package that contains both openssh-client and openssh-server) on the WSL using the command pointed to by the 1st arrow, to enable WSL to accept both inbound and outbound SSH connections.

Let's now verify if “SSH” and “rsync” are installed. Run the command pointed to by the 1st arrow, “SSH” usage information is returned, therefore it is installed.

Run the command pointed to by the 1st arrow; it is verified that rsync is installed, hence the return of the version and usage information as pointed to by the 2nd arrow.

But if the “rsync” command is not installed, run the command pointed to by the 1st arrow to install it. Enter your user password as pointed out by the 2nd arrow. I already have rsync installed as pointed out by the 3rd arrow.

Therefore, we now have both SSH and rsync installed on both the Ubuntu server VM and the Windows client machine (via WSL).

WSL Path Conventions:
Windows drives are mounted inside WSL at /mnt/, for example:

The Windows path/directory C:\Users\YourName\Downloads\ Is written in WSL as /mnt/c/Users/YourName/Downloads/

Also, if you are copying/sharing files to a Windows client machine from Ubuntu server VM terminal using the SSH and rsync running on the WSL, use the Linux path convention for Windows client machine which is /mnt/c/ and NOT C:/ because in this scenario we are NOT using the “SSH” running directly on the Windows client machine through Powershell but the “SSH” running on WSL.

The file will land in the Windows client machine filesystem C:\..., but the connection goes through the Linux environment of WSL.

From the screenshot below, I want to access the Windows client machine C:\ drive from the WSL. I changed the directory to /mnt/c/ as underlined below. I listed the files and directory as pointed to by the 2nd arrow. The lists are long, so pass the ls -l output to head -n 4 to print four lines of the output.

You can run similar commands on both the Ubuntu server VM terminal and the WSL running on the Windows machine.
Another alternative for using the Windows Subsystem for Linux (WSL) described above is to install Cygwin or Git Bash; they both have “rsync” included. Cygwin provide “Linux feelings” on Windows client machines just like WSL; it provides Windows client machines with similar Linux functionality, but note that this does not mean you can run Linux native apps on Windows. But NOTE that WSL provide more complete/native Linux-like capabilities on Windows machines compared to Cygwin's lightweight/limited capabilities.

Gather WSL details.

Let's check for the WSL username using the command pointed to by the 1st arrow. The 2nd arrow points to the username returned.

Check for the WSL IP address. Run the command pointed to by the 1st arrow to view the IPv4 address pointed to by the 3rd arrow of your network interface pointed to by the 2nd arrow.

Take notes of these details, they will be required when we want to copy or share a file with another system.

OPTION B: Using PowerShell (OPTIONAL).

“rsync” cannot be directly installed using PowerShell; it will have to be installed using the WSL, just as demonstrated above. Unlike rsync, even without the WSL, SSH can be installed directly on a Windows client machine and used to share/copy files with remote systems. This is why it is recommended to use WSL, which can enable the use of both SSH and rsync.

Let's enable SSH directly on the Windows client machine. Open a PowerShell on your Windows client machine and run the commands below as pointed to by the 1st arrow, as an administrator:

Installing OpenSSH client, made for outbound SSH connections to remote systems.

Installing OpenSSH server, made for inbound SSH connections from remote systems.

The Openssh-client and Openssh-server have been successfully installed as pointed to by the arrows below.

We would set the Openssh server to automatically start each time we boot our system. Run the command pointed out by the 1st arrow to show the current status of the server, which is “Stopped” as pointed out by the 2nd arrow. Run the command pointed out by the 3rd arrow to automatically start the Openssh server each time we boot the system. The command pointed out by the 4th arrow will start the Openssh server. When we view the Openssh server this time using the command pointed to by the 5th arrow, the status has changed to “Running” as pointed to by the 6th arrow.

IMPORTANT:

Stop-Service sshd =>Run this command to stop the openssh server.

Start-Service sshd =>Run this command to start the openssh server.

Get the Windows Client Machine details.

Note down these details, it will be required when sharing/copying files with another system.

When you run the command ipconfig in Windows PowerShell, you may see multiple IPv4 addresses—especially if you have:

WiFi and Ethernet (wired) connections
VPNs (like OpenVPN, NordVPN), or
Virtual network adapters (VMware, VirtualBox, WSL).

Pick the IP based on your network setup:

If you are connected via WiFi: Use the IP under Wireless LAN adapter Wi-Fi. Example: 192.168.1.100
If connected via Ethernet (via a cable): Use the IP under Ethernet adapter Ethernet. Example: 10.0.0.5
Ignore these IPs:172.x.x.x (usually Windows Subsystem Linux–WSL or Docker). 192.168.152.1 (VMware NAT interface—only for VM-internal traffic). These IPs are NOT used for the transfer/sharing of files.

Therefore, let's find the Windows client machine IPs. Run the command pointed to by the 1st arrow. The 2nd, 3rd and 4th arrows point to other available network interface adapters.

I am connected via WiFi as underlined below. If the file sharing/copying will be directly with the Windows client machine (NOT via WSL), the IPv4 address under it shall be used.

Verify Connectivity:

From your Ubuntu VM terminal, ping the chosen Windows client machine IP as pointed to by the 1st arrow. If ping succeeds, this is the correct IP. If ping fails: Try another IPv4 address from the list. As pointed out by the 2nd arrow, we have successfully pinged the Windows IP.

NOTE: VMware Network Mode.

Bridged: Your VM shares the host’s WiFi/Ethernet IP (e.g., 192.168.1.100).
NAT: Your VM gets a separate IP (e.g., 192.168.152.x), but the host’s IP is still 192.168.1.100.

Check the Windows client username:

Run the command pointed to by the 1st arrow. Your Windows client machine username will be returned as underlined and pointed to by the 2nd arrow.

Verify “SSH” Connectivity to the Windows Client Machine:
From the Ubuntu VM terminal, let's verify we can SSH into the Windows client machine after we have enabled the OpenSSH server and identified the Windows client machine's IP. If your username has a space in it, remember to wrap it in a quote as demonstrated below. Run the command pointed to by the 1st arrow and provide the Windows client machine password, i.e the machine you want to remotely connect to.

Voila, we are remotely connected to the Windows client machine, as shown below. You have total and complete control of the Windows client machine remotely, directly through the command prompt. As pointed out by the 3rd arrow, the prompt has changed from the Ubuntu server prompt $ to a Windows command prompt >.

To disconnect from the remote Windows client machine, run the command pointed to by the 1st arrow. Immediately, the connection to the Windows client machine closed as pointed to by the 2nd arrow. We are back to the Ubuntu server VM terminal as pointed to by the 3rd, 4th and 5th arrows.

We are now set and ready to share/copy files between the Ubuntu server VM and the Windows client machine. We can decide to share/copy files to the Windows machine via WSL (using the SSH server running on the WSL) or directly to the Windows machine (using the SSH server running on the Windows client machine installed through PowerShell).

Step 3: Copy Files using "scp".

IMPORTANT:

All commands will be run/executed from the Ubuntu server VM terminal for both copying from the Ubuntu server VM to the Windows client machine and copying from the Windows client machine to the Ubuntu server VM.
Ensure both SSH and rsync are installed on the WSL and SSH on the Windows client machine (through PowerShell).
If your username or a file path/directory has a space in it, ensure you enclose it with a double quotation mark like this: "agbu enoch amachundi" or "C:\\Users\\Agbu Enoch Amachundi" or "/mnt/c/Users/Agbu Enoch Amachundi".
The Windows C:\ drive is located at /mnt/c/ on the WSL or any Linux machine. For example, file path in Windows client machine:- C:\\Users\\Agbu Enoch Amachundi\\. The equivalent file path in Linnux machine will be: "/mnt/c/Users/Agbu Enoch Amachundi/"
Copying/sharing files between the Ubuntu server VM and the Windows client machine is best recommended to use Windows Subsystem for Linux (WSL) running on the Windows machine, while SSH and/or rsync are installed/running on WSL.

OPTION A: Copy from Ubuntu server VM to Windows client machine via WSL.

sudo scp /ubuntu-server/path/to/filename <WSL-username>@<WSL-ip>:"/mnt/c/Users/windows-nameofuser/.../destination/"

Run the command highlighted in green on the screenshot. I already have these files residing in my Ubuntu server's current directory.

After running the command in green to copy the file, provide your Ubuntu server password as pointed to by the 1st arrow, also provide the password for the WLS user as pointed to by the 2nd arrow. The 3rd arrow points to the file being copied, and the 4th arrow points to the progress percentage of the copied file. It was copied to the Windows client machine via the WSL 100%.

scp Is the command used to copy the file.

/ubuntu-server/path/to/filename Is the source path.

<WSL-username>@<WSL-ip>:"/mnt/c/Users/windows-nameofuser/.../destination/ Is the destination path.

OPTION B: Copy file from Ubuntu server VM directly to Windows machine (NOT via WSL):

sudo scp /ubuntu-server/path/to/filename <windows-username>@<windows-ip>:"C:\\Users\\windows-nameofuser\\...\\destination\\"

We will copy a file directly to a Windows client machine (not through WSL) via OpenSSH installed on Windows using PowerShell, just as demonstrated in OPTION B of Step 2:

The first command in green lists out the files and directories in the current folder, among which are two files we shall be copying, as pointed to by the 1st and 2nd arrows.

You will be authenticated to provide a password for both the source system Ubuntu server and the destination system Windows client machine you intend to copy to, as pointed to by the 3rd and 5th arrow. The 6th arrow shows the files were 100% copied.

./*.* Means, from the current path/directory ./, copy all files with zero or more character length *, followed by a dot . and then extension (e.g .html, .txt) having zero or more character length *.

Note: The file transfer is directly with the native Windows client machine; therefore, the Windows machine path convention of C:\ must be strictly followed. One of the double backwards slashes is made to escape the other backwards slash because the Windows path is enclosed within a quotation mark.

Voila, we have successfully and securely copied the two files to our Windows client machine.

OPTION C: Copy file from Windows client machine (via WSL) to Ubuntu server VM.

sudo scp <WSL-username>@<WSL-ip>:"/mnt/c/Users/windows-nameofuser/.../filename" /ubuntu-server/path/to/destination

Let's copy the file ARP+Storm.pcap to the Ubuntu server VM's current path/directory ./.

Provide the password for the WSL user as pointed to by the 2nd arrow. The 3rd and 4th arrows point to the file name and the percentage of the file copied, respectively.

The 5th arrow shows that the file has been successfully copied to the Ubuntu server by listing all the files in the current path.

Therefore:

<WSL-username>@<WSL-ip>:"/mnt/c/Users/windows-nameofuser/.../filename" Is the source path.

/ubuntu-server/path/to/destination Is the destination path.

Step 4: Copy files using "rsync" (Remote SYNCchronisation).

rsync refers to "Remote SYNChronization". This is similar to the scp command; replace the scp command with the rsync command.

OPTION I: Copy from Ubuntu server VM to Windows machine via WSL.

sudo rsync -avz /ubuntu-server/path/to/filename <WSL-username>@<WSL-ip>:"/mnt/c/Users/windows-nameofuser/.../destination/"

Copy the file pointed to by the 1st arrow from the Ubuntu server to the Windows client machine using the rsync.

We break the command into two lines by using the backslash \ as pointed to by the 4th arrow, then press Enter. Provide the Ubuntu server user password as pointed to by the 2nd arrow. We have successfully copied the file to the Windows client machine using rsync, as pointed out by the 3rd arrow, we are provided with additional details regarding the copying of the files, including size and speed.

The -avz are options (also called "flags") we passed to rsync, and they control how the file transfer happens.

-a Archive mode. It preserves important file properties (permissions, timestamps, symbolic links, etc.). It ensures the copied file is a true replica of the original.

-v Verbose. It makes the command show you more details during the transfer. You’ll see what files are being copied in real-time, which is helpful for monitoring.

-z Compression. This compresses file data during transfer. Especially useful for transferring over a network (like Ubuntu VM to WSL) to speed up the process, especially for large files.

OPTION II: Copy file from Ubuntu server VM directly to Windows machine (NOT via WSL).

First of all, rsync is a Linux Tool. You cannot directly rsync from Ubuntu to a pure native Windows client machine without some Linux-like layer WSL or Cygwin, on the Windows side. Therefore, this option is not achievable, except you directly install rsync on the native Windows client machine (which is rare and can be very complicated).

To prove to you that rsync is not running on a native Windows client machine, let's type the rsync command on PowerShell, as pointed by the 2nd and 3rd arrow, the command rsync is not recognised as a command in the PowerShell.

I deliberately brought out this OPTION II, so you can understand when and where scp and rsync can be used.

OPTION III: Copy file from Windows machine (via WSL) to Ubuntu server VM.

sudo rsync -avz <WSL-username>@<WSL-ip>:"/mnt/c/Users/windows-nameofuser/.../filename" /ubuntu-server/path/to/destination

Let’s copy a file testing.html from the Windows client machine via the WSL to the Ubuntu server VM at the current directory/path ./ as pointed to by the 2nd arrow.

Provide the WSL user password as pointed to by the 3rd arrow. The 4th arrow points to the copied file details during transit.

The 5th arrow points to the copied file after successfully copying it to the Ubuntu server VM.

NOTE: The OPTION III worked because WSL is standing as an intermediary between the Windows client machine and the Ubuntu server VM, and because WSL is an Ubuntu system, rsync was installed and can be used to communicate with another Linux system (Ubuntu server VM).

Which Method to Use?

For one-time transfers: scp.
For large files: rsync

GitHub Repository: https://github.com/agbuenoch/file-sharing-using-scp-and-rsync

Connect with me.

🔗 LinkedIn
🔗 X

Cybersecurity Home Lab: Installs Ubuntu Server On VMware Workstation Pro.

Enoch Amachundi Agbu — Wed, 04 Jun 2025 13:19:06 +0000

Installing Ubuntu Server "Installer Image" On VMware Workstation Pro.

This project documents the step-by-step process of downloading and installing the Ubuntu Server Installer Image on VMware Workstation Pro virtualisation tool, to perform log analysis and monitoring.

Project Overview

Component	Purpose
VMware Workstation Pro	Virtualization platform.
Ubuntu Server (`ISO` file)	Server OS for SIEM and log analysis tools, as a base for detection tools like Wazuh, ELK, and Splunk.

This project walks you through how to manually download and install Ubuntu Server Installer Image, an .iso file to create an Ubuntu server VM and specify its basic settings and configurations in VMware Workstation Pro.

Step 1: Download the Ubuntu Server Installer Image.

Click Ubuntu Server to download the installer image for Ubuntu 24.04.2 LTS. LTS stands for Long-Term Support, which means five years of free security and maintenance updates, extended to 10 years with Ubuntu Pro if enabled. This means Ubuntu Pro delivers 10 years of expanded security coverage on top of Ubuntu’s Long Term Support (LTS) commitment, in addition to management and compliance tooling. After installing the installer image, we will enable Ubuntu Pro, which is free for personal use.

NOTE: The arrows are sequentially numbered for easy understanding of the sequential steps to follow. Some of the directions the arrow points at are not links, but just to draw your attention to key observables.

The download will start immediately after you click on the download button, and you will be redirected to the page below.

While the download is in progress, scroll downward and click on Get Ubuntu Pro, or you can visit the Ubuntu Pro website here to register for free. Click on the “Get Ubuntu Pro” as pointed to by the 3rd arrow.

Click on “Get Ubuntu Pro Now” as pointed to by the 3rd arrow.

Check the “Myself” button as pointed to by the 1st arrow and click on “Register” as pointed to by the 2nd arrow.

If you don't have an account, check the first button; otherwise, check the second button as pointed to by the 1st and 2nd arrows respectively, and provide your details accordingly.

After you sign in, copy down the “Token” pointed to by the 3rd arrow; we will use it to upgrade the Ubuntu server to “Ubuntu Pro” when we successfully create the Ubuntu server on the VMware Workstation Pro. The 4th arrow points to the command we should use to enable Ubuntu Pro.

If you subsequently want to view your Token, visit ubuntu.com and click on "Sign in" at the top right-hand corner of the home page, and you will be redirected to the Ubuntu One Account Page. If this is the first time you're visiting ubuntu.com, you will be prompted with the cookie pop-up below, You can accept by clicking “Accept all and visit site” or choose to manage your preference by clicking the “Manage your tracker settings”.

You will be redirected to the page below. Provide your login details and click on “Log in”.

Click the "Yes, log me in"

Suppose you previously “Accepted the cookie pop-up”, the next time you click on "Log in", you won't be asked to enter your username and password again. In that case, you will be redirected to the screenshot immediately above, and you can click on the “Yes, log me in” because the cookie saved your login details and remembered you.

You have successfully logged in. You will then be redirected to this page, click on the “caret” symbol and click on the “Ubuntu Pro dashboard” as pointed to by the 1st and 2nd arrows, respectively.

Step 2: Open VMware Workstation and Create a New Ubuntu VM

Because the Ubuntu Server Installer Image is an .iso file, click on “Create a New Virtual Machine” as pointed to by the arrow. Follow the remaining installation process using the arrows as a guide.

The path to the downloaded .iso file is automatically detected, but if you changed the location, you can click on "Browse" as pointed to by the 2nd arrow to the new location where you kept the .iso file.

If you prefer to install the operating system later after creating the Ubuntu Server Virtual Machine, you can alternatively choose to check the button as pointed to by the 3rd arrow; otherwise, stick to the default selection as pointed to by the 1st arrow.

Give the Ubuntu server a name of your choice as pointed to by the 1st arrow; you will be guided on acceptable syntax for your choice of names, for example, the use of upper case letters is not allowed.

You can also choose to change the location where the VM should reside by clicking on the "Browse" button as pointed to by the 2nd arrow; otherwise, click "Next".

As pointed out by the 1st arrow, assign the disk size; 20GB is the minimum size recommended.

Click on the “Customise Hardware” as pointed to by the 1st arrow only if you want to change any settings or configuration. Changes can still be made even after the installation.

When you click on “Finish”, you will be presented with the VM interface shown below. The 1st arrow points to the “Play/start” button used for powering the VM. Click on the “caret” symbol for other options like “Suspend, and Restart” buttons. You can edit the VM settings/configurations by clicking on the link pointed to by the 3rd arrow.

Step 3: Start the Ubuntu Server

From the screenshot above, start the Ubuntu server by clicking on the green play button pointed by the first or second arrow.

NOTE:

The arrows in the screenshots provided in the Step 3 are not in sequential order. I will explain each one of them that is necessary.
Use the mouse to scroll up and down the VM interface, using the scroll bar.
At this stage, you will start navigating between your native machine/host and the Ubuntu server VM. On your native machine keyboard, press “Ctrl G” or move the mouse cursor directly inside the VM and click inside it, to move/direct your keyboard input into the VM, this will enable you to interact with the VM directly using the keyboard which is very important especially at this installation process of starting the Ubuntu Server for the first time. While the keyboard focus is on the VM, press Ctrl Alt or move the mouse to click anywhere outside the VM, to move/direct the keyboard input out of the VM to the native machine.
Always scroll downward to accept the setting you have checked or selected. I used arrows to point to the scroll bar at the extreme right side of the window.

Press Ctrl G to direct keyboard input to the VM, and press "Enter" on your keyboard to activate the highlighted choice as pointed to by the 1st arrow. Do this for all other ones.

If you want to change your keyboard layout from the default one detected “[English US]” you can move the mouse to “Identify Keyboard” and press Enter on your keyboard, as pointed to by the 2nd arrow, otherwise just scrow down and press Enter when the mouse is on “Done”.

Suppose you chose to “Identify Keyboard”. In that case, you will be asked a couple of questions, which I sample just two screenshots below, answer them accordingly, and your keyboard layout will be automatically detected.

After the keyboard layout settings, the next steps follows. Move the mouse to activate/select the "Ubuntu Server" as pointed to by the 3rd arrow. The X inside the parentheses means it has been selected or activated, scroll downward as pointed to by the 2nd arrow, direct the mouse input back to the VM, ensure the mouse is active on “Done”, and press Enter.

In the "Network configuration", scroll downward and press Enter while on "TBD"

Skip the proxy configuration, scroll down, and press Enter while on the “Done” button.

Scroll downward and press Enter.

Select “Use an entire disk” as pointed to by the 2nd arrow. The X means it is selected.

You will be presented with the storage configuration summary, scroll down and press Enter when you are active on the “Done” button.

You will be prompted to click on “Continue”

The next is “Profile Configuration”, provide the following details to sign up for login into the Ubuntu server after the installation. Use the "Tab" key on your keyboard to move from one row to another after entering the values.

Select the “Skip Ubuntu Pro setup for now” and scroll down the cursor to “continue” and press Enter.

Select the “Install OpenSSH server” as pointed to by the arrow below. Ensure you see X appear inside the bracket, scroll down and press Enter on “Done”.

The installation process will begin; this will take a considerable number of hours, depending on your native machine specifications. The higher RAM and processor cores you have, the faster the installation process.

When you are running out of battery or internet connectivity at any stage of the installation especially this stage, I recommend you do not shut down your system or “power off” the VM or exit the VMware Workstation Pro, you should put your system on “sleep” mode and wake it up later when you have internet connections or charged your battery, to continue the installation process. Just remember, this process can take a while.

Now "shut down” the Ubuntu server. Click on the “caret” symbol as pointed by the 1st arrow, you will see “Shut Down Guest” as pointed to by the 2nd arrow, click on it.

After you shut down the VM, you will see the VM interface shown below, click on the "CD/DVD (SATA)", so that we can detach the .iso file installation directory from our native machine.

As pointed out by the 1st arrow, uncheck the “Connect at power on” button. Checked the “Use physical drive” as pointed to by the 2nd arrow. Click on the “caret” symbol pointed to by the 3rd arrow and select “Auto detect”, scroll down as pointed to by the 4th arrow and click on “ok”.

Now, “Power on” the Ubuntu server again by clicking on the green power button right in the VM interface. This time, the server will not load directly from the .iso file on our local machine. This will also take a while, just as indicated on the screenshot below.

You will be prompted to log in to the Ubuntu server using the signup details provided during the installation process above in “Profile Configuration”. Enter your username as pointed to by the 1st arrow, press “Enter” on your keyboard and enter the password as pointed to by the 2nd arrow.

Voila! We have successfully logged in to the Ubuntu server and received a welcome message to “Ubuntu 24.04.2 LTS”. The 3rd arrow points to the message that says ESM - i.e Extended Security Maintenance is not enable. This is referring to the “Ubuntu Pro” and we will enable this feature in the next step so that we can receive additional future security updates up to 10+ years. After the welcome message and other additional information, we are presented with a “Prompt” to interact with the Ubuntu server. Let's explain the entire components of the “Prompt”. The 4th arrow points to the username, i.e the user currently logged in to the server. The 5th arrow points to the host/machine name, which is “ubuntu-server”; this is the name given to this Ubuntu server VM. The 6th arrow points to the dollar sign $, which refers to a normal user with less privileges. If this were an administrator or super user, the symbol or sign would be a hash sign #, which means the logged-in user would have a root user privilege.

Step 4: Enable Ubuntu-Pro

Copy the token assigned to you when registering for “Ubuntu Pro” as demonstrated above, and run the command shown below. You will be required to provide a password for the user who is currently logged in to this server, this is to ensure the command is run by an authorized user.

As pointed out by the arrow below, our Extended Security Maintenance - ESM is now enabled, which implies that the “Ubuntu Pro” is now enabled and attached to our Ubuntu server.

GitHub Repository: https://github.com/agbuenoch/cybersecurity-home-lab

Connect with me.

🔗 LinkedIn
🔗 X

Cybersecurity Home-Lab: Installs Kali Linux and VMware Workstation Pro.

Enoch Amachundi Agbu — Wed, 04 Jun 2025 11:34:32 +0000

Installing Kali Linux "Pre-Built Image" and VMware Workstation Pro.

This project documents the step-by-step process of setting up a Cybersecurity Home Lab by downloading and installing Kali-Linux Pre-Built Image, on VMware Workstation Pro virtualisation tool, to simulate attacks.

Project Overview

Component	Purpose
VMware Workstation Pro	Virtualization platform.
Kali Linux (`OVA` file - Pre-Built Image)	Offensive security and pentesting, for penetration testing and vulnerability scanning.

Virtualisation is the process of creating a virtual version of computing environments, such as operating systems, servers, and networks, on a single physical machine. It enables users to run multiple systems simultaneously, making it an essential tool for testing, development, and cybersecurity labs.

VMware Workstation Pro is a powerful virtualisation software that allows users to run multiple virtual machines on a single physical system. It's widely used by IT professionals, developers, and cybersecurity analysts to simulate real-world environments without needing separate hardware.

Kali Linux is a Debian-based Linux distribution specifically designed for penetration testing and ethical hacking. Pre-loaded with hundreds of security tools, it’s a go-to OS for cybersecurity professionals and learners aiming to test vulnerabilities, perform digital forensics, and learn offensive security techniques in a controlled environment.

As of November 11, 2024, VMware Workstation Pro is free for personal use, which implies that a license key is no longer required during installation. The company “BROADCOM” completed the acquisition of VMware on November 22, 2023. VMware Workstation Pro became part of Broadcom's software portfolio at that time.

STEP 1: Log in to the Broadcom support website

Sign up or sign in to the Broadcom Support Portal. If you already have an account, click on "Login"; otherwise, click on "Register" as pointed to by the second and first arrow, respectively.

Assuming you are registering for the first time, fill in your information as shown below. You are expected to enter the text from the image pointed to by the 2nd arrow into the box below it, pointed to by the 3rd arrow. If you are unsure about the text, you have the option to click on the speaker to hear the text read out loud as pointed to by the 4th arrow. You can also click the refresh button to change the given text as pointed to by the 5th arrow. Click on Next and follow through with the signup process.

After signing up successfully, log in to the portal.

STEP 2: Download VMware Workstation.

After logging in, you will be directed to the home page shown below:

The 1st arrow points to your registered name, showing you are logged in. Click on either of the links pointed to by the 2nd arrow and click on “VMware Cloud Foundation”, next click on “My Downloads”.

Click “HERE” pointed to by the 2nd arrow in the screenshot below.

Search by typing VMware Workstation inside the search bar as pointed to by the 1st arrow and click on Show Results. The matched results will be displayed, click on the VMware Workstation Pro as pointed to by the 3rd arrow.

Two operating systems versions of the VMware Workstation Pro are displayed, pointed to by the two arrows; choose the one that corresponds to your operating system. We are selecting the Windows OS version.

Click on the "caret" pointed to by the 1st arrow to expand the Windows OS “VMware Workstation Pro” version. Click on the latest version as pointed to by the 2nd arrow.

Click on the download button to start downloading VMware Workstation Pro.

Step 3: Install the VMware Workstation

Check your download folder or whichever location you specified for your downloads, and right-click on the executable file, click Run as Administrator

Follow through the remaining installation process using the arrows shown in the screenshots below.

I recommend you check the box pointed to by the 1st arrow, so you can be able to access your VMware Workstation Pro through the native computer Command Prompt. You can choose to change the default installation location by clicking on the Change button pointed to by the 3rd arrow and specifying your desired path/location. Click on Next after that.

Check the boxes and click on Next.

Step 4: Download the Kali Linux “pre-built image”.

We can use a Pre-built image (.7z archive) or an Installer image (.iso file) to run virtual machines on VMware Workstations. We are focusing on downloading the pre-built image. The Installer image has the most tedious installation process, where you have much control to specify installation settings.

Visit Kali Platforms, click on the Virtual Machine box as pointed to by an arrow. A Pre-built Image VM is an existing virtual machine, we can quickly start the VM immediately after we download it without going through any installation and configuration settings.

Because we are using the VMware virtualisation platform, click on the VMware download button as pointed to by the 1st arrow, with the actual download size of 3.2G written just beside it. You can see that besides VMware, there are other virtualisation platforms like Oracle VirtualBox. The download starts immediately you click on it. After that, locate the downloaded archived file and unzip it. Right-click on the file and click on "Extract File".

Step 5: Open the Kali Linux (pre-built image) in VMware Workstation Pro.

Double-click on the “VMware Workstation Pro” shortcut to open it. Remember the Kali Linux “pre-built image” is an existing Virtual Machine; on this premise, click on the “Open a virtual machine” and locate the extracted file unzipped above.

Locate the extracted file, double click on it to automatically open it, or select it and click on open to open it on VMware Workstation Pro.

After opening the Kali-Linux Pre-built Image, you will be presented with the interface shown below. The 1st arrow points to the virtual machine name, the 2nd arrow points to the machine state, which is currently “powered off”. The two 3rd arrows point to the start button, You can click on the ‘caret’ symbol right beside the green button to view and use other options like “shutdown, suspend, or restart” the VM. The VM settings can be edited and also upgraded as pointed to by the 4th arrow. The 5th arrow points to the device information regarding Memory and processors allocated, among others, which are all subject to change using the "Edit virtual machine settings" pointed to by the 4th arrow. The 6th arrow points to all open tabs, where we have the “Home” and “kali-linux-2025.1a-vmware-amd64” tabs.

Click on the Start button as shown above, and enter the default username and password of “kali” to log in to the Kali Linux VM.

Voila, we have successfully logged in to the Kali Linux VM.

We have successfully downloaded and installed both Kali Linux pre-built images and VMware Workstation Pro, and opened Kali Linux VM on VMware Workstation.

NOTE:

Alternatively to the Kali Linux pre-built image, you can choose to download and use the Kali Linux Installer Images instead, as shown below. The Kali Linux Installer Images enable you to create the Kali Linux VM from scratch, where you are responsible for specifying all the system configurations and settings, such as RAM allocation and storage location, among others.

Click on Recommended, and you will be directed to the download page shown below. Select your system processor architecture, where x86_64 refers to the traditional 64-bit processor architecture commonly found in most PCs, while Apple Silicon (ARM64) is Apple's proprietary 64-bit processor architecture used in newer Mac computers.

The Installer Image is an .iso file, used to create virtual machines. After the download, open the VMware workstation, click on Create a New Virtual Machine and locate where the .iso file is downloaded and select it. Follow the on-screen prompts to proceed with the rest of the installations and settings. The default selections during the installation, in most cases, should work fine.

GitHub Repository: https://github.com/agbuenoch/cybersecurity-home-lab

Connect with me.

🔗 LinkedIn

🔗 X

Forem: Enoch Amachundi Agbu

Securing MariaDB Server

Step 1: Setup and Import Chinook Database.

Step 2: Create Users and assign Permissions.

STEP 3: Log in to MariaDB.

STEP 4: Create New User.

STEP 5: Grant Permissions to the Users.

Step 6: Revoking Users' Permissions.

STEP 7: Test the New Users.

Step 8: Harden and Enable Logging for Detection & Analysis.

What is a daemon in Linux?

Enable MariaDB Audit Plugin (Advanced Audit Logging).

Review the Audit Logs.

Generate a Report (Optional).

Summary.

LinkedIn Article.

Connect with me.

Set up Chinook Database on MariaDB Server.

Step 1: Install MariaDB Server on Linux.

STEP 2: Secure the MariaDB Server.

STEP 3: Download the Chinook Database SQL Script for MySQL.

STEP 4: Log in to MariaDB.

STEP 5: Create a new Database for Chinook (OPTIONAL).

STEP 6: Load the Chinook SQL Script into MariaDB.

STEP 7: Verify the Installation.

STEP 8: Stop and Disable the Database:

Summary:

LinkedIn Article.

Connect with me.

Analyse Packets with Wireshark.

Step 1: Explore data with Wireshark.

Step 2: Apply a basic Wireshark filter and inspect a packet.

Step 3: Use filters to select packets.

Step 4: Use filters to explore DNS packets.

Step 5: Use filters to explore TCP packets.

Summary.

Connect with me.

Analyse Packets with tcpdump.

Step 1: Identify Network Interfaces.

Step 2: Inspect the network traffic of a network interface with tcpdump.

Step 3: Capture network traffic with tcpdump.

Step 4: Filter the captured packet data.

Summary.

Connect with me.

Kali Linux Users Account Management.

Step 1: How to Change Login Credentials.

Step 2: Create New Users.

Step 3: Switch between users.

Step 4: Renaming a user.

Step 5: Delete a user.

Step 6: Lock a user.

Step 7: Disable a User's Shell in Kali/Linux.

Option 1: Set Shell to /usr/sbin/nologin (Preferred method).

Option 2: Set Shell to /bin/false (Alternative method)

Connect with me.

Ubuntu Server Security Hardening with Ubuntu Security Guide (USG).

Step 1: Register for Ubuntu Pro and attach it to your Ubuntu Server.

Step 2: Update and Upgrade Your System.

Step 3: Install “Ubuntu Pro Client”.

Step 4: Verify and view all Ubuntu Pro Services.

Step 5: Enable and install the USG Tool.

Step 6: Audit Your Ubuntu Server Against CIS Benchmark.

Step 7: Access and open the Audit Report.

Option A: How to view the .html file audit report.

Option B: How to view the .xml file audit report.

Step 8: Apply CIS Benchmark Fixes Automatically.

Step 9: Re-audit After Reboot.

Connect with me.

File Sharing using scp and rsync.

Step 1: Settings/Configurations of “SSH and rsync” on Ubuntu Server VM.

Step 2: Settings/Configurations of “SSH and rsync” on Windows Client Machine.

OPTION A: Using Windows Subsystem for Linux (WSL) (PREFERRED/RECOMMENDED).

OPTION B: Using PowerShell (OPTIONAL).

Step 3: Copy Files using "scp".

OPTION A: Copy from Ubuntu server VM to Windows client machine via WSL.

OPTION B: Copy file from Ubuntu server VM directly to Windows machine (NOT via WSL):

OPTION C: Copy file from Windows client machine (via WSL) to Ubuntu server VM.

Step 4: Copy files using "rsync" (Remote SYNCchronisation).

OPTION I: Copy from Ubuntu server VM to Windows machine via WSL.

OPTION II: Copy file from Ubuntu server VM directly to Windows machine (NOT via WSL).

Option B: How to view the `.xml` file audit report.