Network Security
system security Linux network
system security Linux network The romanticized image of the digital nomad – a laptop on a sun-drenched balcony – rarely accounts for the actual friction of maintaining a professional development environment on the move. . The friction is amplified with Linux. We are looking for a setup that respects our kernel configurations, handles volatile network handovers, and maintains a strict security posture without the hand-holding of a consumer-grade OS – so, put simply, more than just a laptop and a sunny deck. The hardware is...
May 26, 2026
Server Securityopen-source Linux administration
open-source Linux administration Cron has existed in Unix and Linux environments for decades, handling backups, cleanup scripts, patching jobs, log rotation, monitoring tasks, and other maintenance work that administrators do not want to run manually. Most Linux servers rely on it constantly, which is exactly why attackers continue abusing it for persistence after a system has already been compromised. . Persistence through cron is not complicated. Attackers do not need a rootkit or advanced malware framework to maintain...
May 25, 2026
Vendors/Productssecurity breach linux
security breach linux A major internal repository breach at GitHub has exposed a critical and overlooked blind spot in Linux supply chain security. Kernel exploits, exposed SSH services, weak firewall rules, and vulnerable daemons dominated the Linux threat model for years, and in many environments, they still matter. But recent supply-chain incidents involving GitHub ecosystems, npm packages, and malicious developer tooling point somewhere else entirely: the developer workstation. . The breach matters because...
May 21, 2026
Security Trends access control multi-tenant
access control multi-tenant Linux administrators often face an ugly choice in the cloud: prioritize convenience and cost-efficiency by sharing infrastructure, or sacrifice those benefits for the sake of total isolation. Most modern Linux workloads don't live on their own private servers anymore. They live in shared environments like Kubernetes clusters, where multiple teams and services run side-by-side. It sounds efficient, and it usually is. . But cloud isolation isn't as ironclad as it looks on the diagram. If you...
May 21, 2026
Vendors/Productsincident response cloud security
incident response cloud security Managed Extended Detection and Response (MXDR) has become one of the most sought-after security services in the enterprise market — and with good reason. It promises the holy grail: broad visibility across endpoints, network, cloud, email, and identity, combined with the 24/7 human expertise most organizations simply cannot build in-house. . However, the rapid growth of the market has produced a wide range of providers whose capabilities vary considerably beneath the surface. Choosing the...
May 19, 2026
Refine news
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security news
We found -3 articles for you...
77
security advisoryhashingGPGLinux Integrity Verification: SHA256 and GPG Checks Explained
Linux treats anything pulled from outside the system as untrusted until it is checked, and that expectation shapes how files move through real environments. . A SHA256 checksum verifies the data arrived intact, and an MD5 checksum still appears in older workflows that never entirely shifted away from it. Authenticity is a separate question that depends on the correct GPG key, which is why attackers often target signature files and the checksum references stored beside them. Verification settles into routine once it becomes clear how easily mirrors drift and how often metadata falls out of sync. Distro documentation from Ubuntu, Oracle, and others leans on the same idea because the ecosystem changes under normal load. The GPG Linux steps confirm the source, the hashing confirms the integrity, and both sit in the middle of everyday administration instead of at the edges. Workflows follow a simple pattern. Download the file, check the hash, confirm the signature, then trust the result. Deep in that process is where checksums in Linux matter most, since the system depends on both signals aligning and not just one. Everything in this piece centers on that theme of integrity and authenticity as non-negotiable parts of Linux verification. The following section steps back to explain why these checks exist before showing how they work, since the reasoning drives the workflow that follows. Why Integrity Verification Is a Required Step in Linux Workflows Integrity asks whether a file arrives unchanged, while authenticity checks who actually produced it. GPG Linux handles that second piece because identity is the part adversaries tend to blur. Distros carry both signals since mirrors drift and metadata falls out of sync under normal load. A small mismatch can move through a routine update without making noise. That’s why the ecosystem leans on “trust after verify,” even when the task feels ordinary. A SHA256 checksum answers the integrity question up front by proving the content didn’tshift in transit. The pattern behind the baseline checks used across major distros reflects that same idea: confirm the data before anything else. Authenticity finishes the job by tying the file back to its real publisher, a principle that shows up in the signature methods many distros rely on for release images. Both layers matter because distributed systems drift more than people expect. And that sets up the next piece: how SHA256 actually works when these checks move from theory into daily administration. Using SHA256 Checksums to Confirm File Integrity The SHA256 checksum ends up carrying most of the weight in integrity work because it shows, cleanly, whether an ISO or package is the same one the publisher released. Distros settled on it long ago since shorter hashes collide under strain and don’t stand up well once the ecosystem starts shifting around them. Most mismatches come from ordinary issues—mirrors drifting, downloads dropping a few kilobytes, metadata lagging just enough to cause trouble. You see it immediately in the comparison. And that’s why SHA256 files sit right beside the ISOs instead of living deeper in the mirror. Running the check means producing your own SHA256 checksum and lining it up with the value the publisher posted, nothing more clever than that. The behavior of the standard tool follows the same rhythm we rely on everywhere else in this workflow. Generate the hash and read the difference if one shows up. A drift between the two means the file changed somewhere on the path, even if it looks completely normal on disk. A checksum calculator can help in a pinch, though most environments lean on the built-ins because they’re already in place. It fits the broader habit in checksums in Linux, where integrity is treated as a direct signal rather than a guess built on trust. A clean match tells you the file survived the handoff intact. And at this point, most users want to see what that looks like in real use, since the next section steps into the hands-on side,where the commands actually matter. SHA256 Check Example (Direct Commands + Expected Output) A SHA256 checksum check starts with a single command that tells you whether the file survived the download intact. It’s the quickest way to see if an ISO or package matches what the publisher released. Most admins read it almost unconsciously. One line in, the result is already clear. $ sha256sum file.iso e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 file.iso A clean match against the posted value means the file’s solid. Any drift — even one character — points to a mirror hiccup or a partial download. That’s usually enough to stop and pull the file again rather than trying to work around it. Shows how quickly these checks surface small problems. Automated checks make this easier when you’re dealing with more than one file. The reference list carries every hash the publisher expects, and the -c flag reads through it without any manual comparison. $ sha256sum -c SHA256SUMS file.iso: OK file2.iso: FAILED Entries marked “OK” line up with the publisher’s hash. Anything marked “FAILED” changed on the way in, even if the file looks fine in the directory. It behaves like a built-in checksum calculator, but anchored to the distro’s own list so the results stay honest. SHA256 is the preferred layer in modern systems, but plenty of Linux users still run into MD5 in older workflows that never fully moved on. That’s the legacy integrity layer, and it’s next because environments built years apart often sit side by side. When MD5 Checksums Still Appear in Linux Environments The MD5 checksum tends to surface in older environments where the tooling hasn’t moved forward. It sits in the same legacy space as SHA1, mostly because both still help with simple consistency checks on shared storage and long-lived archives. They’re fine for spotting accidental corruption. They’re not fine for security. And that’s why anything coming fromoutside the network shifts to stronger hashing without debate. $ md5sum file.iso d41d8cd98f00b204e9800998ecf8427e file.iso That line gives you a quick read on whether the transfer succeeded, the same shape as SHA256, but far easier to collide. A clean MD5 file checksum still has value when you’re just checking that a hand-off inside the environment didn’t break the data. What it can’t do is prove where the file came from. Shows the limit built into the design. Teams usually keep MD5 for internal movements and use MD5 checksum comparisons when the risk is low. SHA256 takes over once the file crosses any boundary that involves trust, since the old hashes can’t defend against intentional tampering. It’s the same theme running through all of this: integrity helps, but it can’t stand alone. And that’s why the workflow steps toward authenticity next, where GPG fills the role that hashing can’t touch. Confirming Authenticity with GPG Keys (Authenticity Layer) Checksums handle integrity, but they never confirm who produced the file. That’s where the GPG key comes in, since Linux treats the signature on the checksum file as the real source of truth. It’s the layer that stops tampered checksum lists, forged images, and quiet edits that would slip past hashing alone. Most package systems build this directly into their trust model, a pattern reflected in the broader work around signature validation across major distros. And it’s the second half of verification, the part that integrity can’t reach. A GPG key binds the reference back to its publisher, which is why Linux leans on signatures to authenticate anything pulled from outside the environment. The behavior described in common GPG Linux signature checks mirrors this: read the signature, confirm the key, then treat the checksum file as trustworthy only if the match holds. It’s the same logic behind everyday package installs, even if users rarely notice it running. You also see the idea echoed in work that explainshow digital signatures prevent tampering, such as the reasoning behind PGP validation. Shows how easily an unchecked checksum list could be swapped without this layer in place. Managing keys usually starts with adding a GPG key or generating a local key when the environment needs its own signing identity. Listing trusted keys with GPG list keys tells you who the system already trusts, which matters when you’re verifying files from unfamiliar mirrors. And for anyone who needs deeper detail, the mechanics behind publisher identity are explained in the broader view of how signatures authenticate the origin of a file, as seen in our own GPG guide . The important part here is simple enough: authenticity closes the gap that hashing leaves open. And now both layers can be combined into the workflow that follows. GPG Verification Workflow (Import → List → Verify) A clean verification run starts with retrieving the signing key, either from a keyserver or by importing it directly. Both paths matter since different mirrors publish keys in different formats. Once the key is present, GPG list keys shows the trust entries already on the system, the quick way to confirm the fingerprint you expect is actually there. If the fingerprint doesn’t match the one the publisher posts, the key can’t be trusted at all. That’s the quiet risk most people forget to check. $ gpg --recv-keys $ gpg --import publisher-key.asc $ gpg --list-keys With a verified key in place, the signature check completes the chain. The command reads the signature file, verifies the key, and confirms the reference came from the correct publisher. GPG Linux follows the same rhythm across distros: the identity check first, then the file validation. A clean result means the reference hasn’t been touched. Anything else stops the workflow immediately. $ gpg --verify SHA256SUMS.gpg SHA256SUMS That wraps up the authenticity side. The hash shows the file didn’t change, and the signature shows who released it. Now,both layers can work together across the whole workflow, tying integrity and authenticity into a single path. Step-by-Step: How to Verify a Linux Download Using SHA256 and GPG The full workflow starts before the checks even run. A file comes down first, then the SHA256 reference, then the signature that proves the reference came from the right source. That’s the shape most distros rely on because the SHA256 checksum handles integrity while the GPG key handles identity. Each one answers a different question. And both need to line up before the file is trusted. The integrity pass lands first. Running sha256sum file.iso prints the local value, and comparing it with the posted hash tells you whether the download survived the handoff intact. A valid SHA256 checksum gives you confidence in the data itself. A mismatch usually means corruption or drift, not something malicious, but it still stops the workflow. Shows how quickly small faults surface. $ sha256sum file.iso file.iso The authenticity pass comes next. gpg --verify SHA256SUMS.gpg SHA256SUMS reads the signature, checks the key, and confirms the reference file wasn’t altered. That same logic applies whether the publisher uses a long-standing signing identity or something newer, like a project’s GitHub GPG key. A clean verification means the reference file is genuine. Anything else halts the chain immediately. $ gpg --verify SHA256SUMS.gpg SHA256SUMS Some environments still publish an MD5 checksum for legacy tooling, but it plays a supporting role at best. It won’t confirm identity and shouldn’t be used to trust anything external. This unified workflow—hash first, signature second—is what Linux admins rely on every day. And for anyone who wants a deeper look at why these hashes matter, the fundamentals sit in our broader work on the meaning behind a checksum, reflected in the idea behind our checksum breakdown . The next section covers what happens when the signals don’t match, because drift still showsup even when you do everything right. What to Do If Verification Fails Most failures trace back to something unremarkable. A SHA256 checksum mismatch usually comes from mirror drift, an interrupted transfer, or stale metadata that didn’t keep pace with the latest build. Shows how easily small faults ripple through distributed systems. None of these failures proves malware is involved, but they do mean the file can’t be trusted yet. The first move is simple: re-download the file, confirm the reference, and check the signature again. If the mismatch repeats, switch mirrors or wait for the repository to settle. That’s the point where admins decide whether to pause or proceed, because forcing a broken match forward rarely ends well. And the behavior fits the broader pattern in checksums in Linux, where integrity depends on how well the environment stays in sync. These failures tie back to the quiet shifts that happen in real infrastructure, the slow drift that affects both hashes and signatures over time. You see the same idea in the way we talk about system drift in Linux , where small inconsistencies build until something breaks. And with that in mind, the next section pulls everything into a quick-reference summary so the full workflow is easy to revisit. Quick Reference: Linux Integrity Verification Commands This table keeps the core commands in one place, the same ones admins reach for when they need a quick read on a file’s trustworthiness. The idea hasn’t changed since the intro: hashing shows what the file is, signatures show where it came from, and neither stands on its own. A single SHA256 or MD5 checksum catches drift and corruption, while the signature confirms the source. That split sits at the center of everyday work, even if it feels routine. Purpose Command What it Shows Generate a SHA256 hash sha256sum file.iso Verifies the content stayed intact. Generate an MD5 file checksum md5sum file.iso Catches internal corruption, nothing more. Compare a batch of SHA256 values sha256sum -c SHA256SUMS Mark each entry clean or altered. Import a signing key gpg --import publisher.asc Loads the identity needed for trust decisions. Retrieve a remote key gpg --recv-keys Pulls a key from a server, the same pattern used for a project’s GitHub GPG key. View trusted identities gpg --list-keys Shows which keys the system already trusts. Verify a reference file gpg --verify SHA256SUMS.gpg SHA256SUMS Confirms the source behind the posted hashes. Use a checksum calculator Varies by distro Helpful for quick checks, though most teams stay with the CLI. Everything here folds back into the same workflow: integrity first, authenticity right behind it. The commands look simple, but they’re what keep downloads trustworthy when mirrors drift and metadata slips out of sync. Frequently Asked Questions A few questions come up any time someone starts working with integrity and authenticity checks in Linux. These are the ones admins tend to hit first. How do I verify a SHA256 checksum on Linux? You run sha256sum file.iso and compare that value with the one the publisher posts. The match tells you the file arrived intact, nothing hidden underneath. One character off means the download drifted somewhere along the path. And that’s usually all you need before deciding whether to replace the file or keep moving. Why does GPG verification fail? It fails when the key on your system doesn’t match the fingerprint the publisher provides. The signature can’t stand on its own without that match, so the chain breaks early. Most of the time, it’s a missing key or a mistaken import from the wrong source. Shows how identity problems reveal themselves long before thefile ever gets involved. What’s the difference between SHA256 and MD5 in Linux? SHA256 is collision-resistant and built for real integrity checks. MD5 lives on in older tooling, where it only catches accidental corruption and is not tied to trust. They serve different purposes even though they look similar at a glance. And that split becomes obvious the moment you rely on hashing for anything outside your own network. How can I check the fingerprint of a GPG key in Linux? gpg --list-keys prints the fingerprint straight from your machine, and that’s the value that actually matters. You match it against the fingerprint the publisher releases, not anything floating around a mirror or forum. If they don’t line up, the key can’t anchor a signature at all. It’s a quiet check, but it’s the one that catches a substituted or malicious key before it settles in. Why do some distros still provide MD5 checksums? Mainly to keep older systems and long-stored archives from breaking. An MD5 line still works for quick consistency checks even though it can’t prove where a file came from. That’s why it sits on the edges now instead of in front of anything important. And it shows how long legacy workflows stay alive in real infrastructure. Final Thoughts: Keeping Linux Integrity Checks Predictable Integrity and authenticity only work when they’re part of the daily rhythm, not reserved for exceptional cases. A quick SHA256 checksum gives you the first signal, and the matching GPG key closes the loop by confirming who actually released the file. The whole workflow stays light because each command answers a narrow question, and Linux leans on that simplicity to keep trust predictable in environments that shift more than we notice. Older tools like the MD5 checksum still appear in legacy workflows, but they sit on the edges now. Shows how the ecosystem evolves while keeping enough of the past around to remain compatible. Most of this comes down to habit. Run the hash, read thesignature, and treat mismatches as warnings instead of noise. The system assumes nothing is safe until it’s verified, and that assumption holds up nicely once you’ve seen how easily mirrors drift or metadata slips out of sync. These checks fit into everyday work because they don’t ask for much, just attention to the signals already there. And that’s the thread running through all checksums in Linux, supported by the trust model built into GPG Linux, closing the loop between what the file is and who it came from. . A SHA256 checksum verifies the data arrived intact, and an MD5 checksum still appears in older workf. linux, treats, anything, pulled, outside, system, untrusted, until, checked. . MaK Ulac
Nov 21, 2025
•
Server Security
83
security advisoryremote accessthreatCERT/CC: CA-2002-28 Critical: Sendmail Trojan Horse Remote Access
The CERT/CC has received confirmation that some copies of the source code for the Sendmail package were modified by an intruder to contain a Trojan horse. Sites that employ, redistribute, or mirror the Sendmail package should immediately verify the integrity of their distribution. . .. The CERT/CC has received confirmation that some copies of the source code for the Sendmail package were modified by an intruder to contain a Trojan horse. Sites that employ, redistribute, or mirror the Sendmail package should immediately verify the integrity of their distribution . CERT ® Advisory CA-2002-28 Trojan Horse Sendmail Distribution Original release date: October 08, 2002 Last revised: -- Source: CERT/CC A complete revision history is at the end of this file. Overview The CERT/CC has received confirmation that some copies of the source code for the Sendmail package were modified by an intruder to contain a Trojan horse. Sites that employ, redistribute, or mirror the Sendmail package should immediately verify the integrity of their distribution. I. Description The CERT/CC has received confirmation that some copies of the source code for the Sendmail package have been modified by an intruder to contain a Trojan horse. The following files were modified to include the malicious code: sendmail.8.12.6.tar.Z sendmail.8.12.6.tar.gz These files began to appear in downloads from the FTP server ftp.sendmail.org on or around September 28, 2002. The Sendmail development team disabled the compromised FTP server on October 6, 2002 at approximately 22:15 PDT. It does not appear that copies downloaded via HTTP contained the Trojan horse; however, the CERT/CC encourages users who may have downloaded the source code via HTTP during this time period to take the steps outlined in the Solution section as a precautionary measure. The Trojan horse versions of Sendmail contain malicious code that is run during the process of building the software. This code forks a process that connects to a fixedremote server on 6667/tcp. This forked process allows the intruder to open a shell running in the context of the user who built the Sendmail software. There is no evidence that the process is persistent after a reboot of the compromised system. However, a subsequent build of the Trojan horse Sendmail package will re-establish the backdoor process. II. Impact An intruder operating from the remote address specified in the malicious code can gain unauthorized remote access to any host that compiled a version of Sendmail from this Trojan horse version of the source code. The level of access would be that of the user who compiled the source code. It is important to understand that the compromise is to the system that is used to build the Sendmail software and not to the systems that run the Sendmail daemon. Because the compromised system creates a tunnel to the intruder-controlled system, the intruder may have a path through network access controls. III. Solution Obtain an authentic version of Sendmail The primary distribution site for Sendmail is https://www.proofpoint.com/us/products/email-protection/open-source-email-solution Sites that mirror the Sendmail source code are encouraged to verify the integrity of their sources. Verify software authenticity We strongly encourage sites that recently downloaded a copy of the Sendmail distribution to verify the authenticity of their distribution, regardless of where it was obtained. Furthermore, we encourage users to inspect any and all software that may have been downloaded from the compromised site. Note that it is not sufficient to rely on the timestamps or sizes of the file when trying to determine whether or not you have a copy of the Trojan horse version. Verify PGP signatures The Sendmail source distribution is cryptographically signed with the following PGP key: pub 1024R/678C0A03 2001-12-18 Sendmail Signing Key/2002 Key fingerprint = 7B 02 F4 AA FC C0 22 DA 47 3E 2A 9A 9B 35 22 45 The Trojan horse copydid not include an updated PGP signature, so attempts to verify its integrity would have failed. The sendmail.org staff has verified that the Trojan horse copies did indeed fail PGP signature checks. Verify MD5 checksums In the absence of PGP, you can use the following MD5 checksums to verify the integrity of your Sendmail source code distribution: Correct versions: 73e18ea78b2386b774963c8472cbd309 sendmail.8.12.6.tar.gz cebe3fa43731b315908f44889d9d2137 sendmail.8.12.6.tar.Z 8b9c78122044f4e4744fc447eeafef34 sendmail.8.12.6.tar.sig As a matter of good security practice, the CERT/CC encourages users to verify, whenever possible, the integrity of downloaded software. For more information, see /about/divisions/cert/index.cfm Employ egress filtering Egress filtering manages the flow of traffic as it leaves a network under your administrative control. In the case of the Trojan horse Sendmail distribution, employing egress filtering can help prevent systems on your network from connecting to the remote intruder-controlled system. Blocking outbound TCP connections to port 6667 from your network reduces the risk of internal compromised machines communicating with the remote system. Build software as an unprivileged user Sites are encouraged to build software from source code as an unprivileged, non-root user on the system. This can lessen the immediate impact of Trojan horse software. Compiling software that contains Trojan horses as the root user results in a compromise that is much more difficult to reliably recover from than if the Trojan horse is executed as a normal, unprivileged user on the system. Recovering from a system compromise If you believe a system under your administrative control has been compromised, please follow the steps outlined in Steps for Recovering from a UNIX or NT System Compromise Reporting The CERT/CC is interested in receiving reports of this activity. If machines under your administrative control are compromised, please send mailto
Oct 08, 2002
•
Hacks/Cracks
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Discover faster search, smarter navigation, and deeper Linux security insights. Read More