(In this article we continue using Pop!_OS Linux, in our example Series)
Do you like this topic? I'd like to hear from you and what you think/like to see.
Leave a comment/send a message/email.
Most of this can be applied on any Linux system.
(Support options listed on frontpage/bottom of post [if you would like to] )
GETTING STARTED: FILE INTEGRITY
Let's talk a bit more about checking file integrity. It's an essential topic each user should have some grasp of to avoid corrupted/malicious software. Especially if you ever download from unknown sources. Or, want to do a comparison to cross check against official sources.
Why? If you download a file (especially something run as root, or worse yet, an iso image installed as a permanent operating system), and do not check this file against its official given checksum, you run the risk of running/installing something malicious.
In other circumstances, if you frequently use a shared network (ie: public WiFi) and the file were replaced in transit, that file could come with the similar risk of malicious modification.
TIP: Packages signed with GPG keys provide another way to check the integrity of a provided package and ensure it matches the developer's package.
CHECKSUMS
Some of you may have had a taste of this subject watching my recent video geared toward introducing Pop!_OS Linux to beginners. "How to safely download & check integrity/install Pop!_OS", starting with (the most important segment) checking our Pop!_OS Linux image file's checksum integrity.
What Is A Checksum?
A Checksum algorithm is an integrity hash function. Running a file against this algorithm provides our checksum hash. When we check, we are running that file through an algorithm. The output reveals a unique fingerprint.
Commonly Seen: SHA1 and SHA256, MD5.
TIP: SHA256 / SHA512 is a more "secure"/proven cryptographic hash than SHA1
The Key Point: If a file is modified at any point, that file no longer returns the same checksum it had before the modification.
See screenshot down below for our first simple example: changing data inside a file creates a change in the checksum. We start out with 2 files: matching internal contents.
Then, for the before/after example, we slightly change one file's contents.
We record checksums before and after the file content change (in our screenshot example below)
(for observational comparison - screenshot as a teaching tool).
TOOLS
For the following examples, we will typically see/use 2 common commands:
sha1sum and sha256sum.
One checks SHA1, the other, checks SHA256. Commonly provided with Linux images and software (as well as other certificates of authenticity)
These commands can be used as follows:
sha1sum FileToCheck.img
sha256sum FileToCheck.img
The file provider (ie: developers) supplies a checksum. The output from the above command will reveal a unique checksum depending on the content inside the file.
TIP: When possible, source checksum from separate server from the download itself. This may mean using a mirror for the download, and official source for the checksum.
Why? This would require simultaneous takeovers of download mirror location and checksum server.
See Below Example Before/After File Change:
In the above screenshot, we use 2 very simple files to make this easier to understand.
test1 and test2 files both contain "test1" as their file content.
Observe in the (centered) red rectangle, running "sha256sum test1" and "sha256sum test2" both revealing the exact same checksum (since file contents are identical): 3cd203ac11340842055a6de561c9d69ca4493e912bd4c3c440c80711e16d5aee
This is because both file contents match exactly: copies of one another.
Did You Know? This checksum is maintained no matter what outside particulars may change (ie: name of file).
The checksum will only change if the file's internal contents change.
Directly below the matching checksums, I issue "echo "1" >> test2", a command that adds a 1 to the end of test2 file. You don't need to understand the entire command, only know it adds a change to the "test2" comparison file.
Then we compare the checksums once again in the bottom of the screenshot. The checksums have clearly changed.
TIP: Package managers have built in checksum checking. This is something you won't need to perform when using apt (Debian based) or pacman (Arch based).
Outside this, anytime you download a new Linux image file, or other file, it is a good idea to make a checksum comparison.
Next up we use debsums and rdebsums to automate checking checksum integrity per package, and on the entire system. Read on to learn how, with examples/screenshots.
EASY PACKAGE CHECKSUM INTEGRITY TRICKS + MORE
What about checking entire filesystem for malicious changes?
We can do this too!
Meet rdebsums:
(rdebsums / debsums both for Debian and other Debian based operating systems like Ubuntu or Pop!_OS)NOTE:
rdebsums allows you to check a package and all its dependencies (packages associated with it).
EXAMPLE: CHECKING INSTALLED PACKAGE INTEGRITY
In the above example simply entering "rdebsums tor" checks the entire tor package and all its dependencies.
Check any individual packages by substituting the command/package where you see tor above.
Why It's Helpful: This command is helpful when you want to check important packages. Tor is one that needs full confidence. Any other package can be used in place.
CHECKING ENTIRE SYSTEM
debsums
Wouldn't it be time consuming to check on each package, individually?
Time consuming is optional on the Linux commandline. π
We can do just about anything, and automate it (for later) using the magic of the Linux shell commandline...
FIRST
EXAMPLE OF "debsums" RAN ALONE:
We can do something using the magic of the Linux commandline in the example below:
OPTION: SHOW ONLY MODIFIED FILES
Linux Beginner Recommendation: Want to learn very basic Linux commands? See Here.
After that, check out the Linux cheatsheet command I created to help remind you of common commands, anytime you need it, Here.
Next up: Beginner guide to bash scripting. Learn to automate anything you can dream: HERE.
In the above link we go through some basics on bash scripting, and off the cuff write our first service: an automatic upgrade service for debian based systems (you can substitute apt with pacman commands for an arch based setup.
In the example above, we save loads of time. We use a "pipe" or "|" symbol to send/filter the debsums command over to the grep command.
In this example, the command "debsums -a | grep -v OK" does the following (in order):
"debsums -a" checks all files (normally listing each individually).
The "|" sends debsums filter into next command (grep)
"grep -v OK" filters the "debsums -a" output to only show all lines WITHOUT "OK" in them.
Instead of seeing the entire output of debsums -a (including both the "OK" or checks out checksum and the "FAILED", or modified checksums, we use a simple combination to show us ONLY the modified or potentially malicious files (aka "FAILED").
Just because we have some files that say FAILED, doesn't mean there is anything malicious going on.
In fact you likely changed many of these "FAILED" files yourself (if config files).
But it certainly can helps narrow down your target files during a self audit.
It is the binaries you should pay especially close attention to.
HOW TO TELL IF FILE IS BINARY OR CONFIG FILE?
Try the 'file' command to display the type of file you are looking at:file -i -s /Directory/fileHere
After trying this, what do you find? Are you seeing anything concerning? Have you inspected any of the "FAILED" results for anomalies?
Let me know in the comments. π
Thoughts, comments and any questions welcome below.
π Thank you for Sharing this (Telegram/Social media + everywhere).
----------------------------------------------------------------------
π ANONYMOUS GITEA (.onion): Books, Code/Scripts, Wiki, more (make a repository)
π PASTEBIN (.onion): options- password protect, zk-256bit, "Burn After Reading" + more
----------------------------------------------------------------------
SUPPORT OPTIONS (If you like to):
π²CASHAPP
βππ Politictech (BMAC Memberships (monthly supporter option)
π EXTRAS: Unique extra Services (get something back for your support)
π³ Politictech Main Page: (info + current Crypto)
----------------------------------------------------------------------
FOLLOW:
βπMASTODON
π¦ TWITTER
π PEERTUBE
π BITCHUTE
π ODYSEE
---------------------------------------------------------------------
β CONTACT
-------------------------------------------------------------------------
THANK YOU for Sharing this, Liking, and Subscribing.
-------------------------------------------------------------------------
If you aren't registered for Odysee I'd love to see you over there.
Use my invite link: https://odysee.com/$invite/@RTP
--------------------------------------------------------------------------