Posts

Showing posts with the label Hardening

CCE and Configuration Baselines: Standardizing How Systems Are Hardened

Common Configuration Enumeration assigns a unique identifier to a specific security configuration setting, so that "the password history requirement on this operating system" means the same thing across every tool, benchmark, and report that references it. It is the configuration equivalent of what CVE does for vulnerabilities, and the distinction between the two is the concept most worth getting straight. CCE versus CVE A CVE identifies a flaw in software — a defect the vendor must fix and you must patch. You did not cause it and you cannot configure it away. A CCE identifies a configuration setting you control. Nothing is defective; the software is working as designed, and the question is whether your chosen setting is the secure one. The remedy is a configuration change rather than a patch. That difference drives different processes. Vulnerabilities flow through patch management with testing and change windows. Configuration findings flow through baseline management...

Hardening a LAMP Stack: The Four Layers and What Each One Gets Wrong

LAMP — Linux, Apache, MySQL and PHP — still runs an enormous share of the web, and it is the stack most commonly deployed by someone following a tutorial. Every layer ships with defaults suited to getting something working quickly, and the gap between working and secure is where the incidents come from. What each layer does Linux is the operating system, providing the process, filesystem and network foundation. Apache receives HTTP requests, serves static files and hands dynamic requests to the application. MySQL or MariaDB stores the data. PHP executes the application code. Requests flow through all four, and a weakness at any layer is a weakness in the whole stack. The variants — nginx in place of Apache, PostgreSQL in place of MySQL, Python or Perl in place of PHP — change the components and not the reasoning. Linux Run each service as its own unprivileged account, never root, so a compromise of one is bounded. Set filesystem permissions so the web ...

Windows Privilege Escalation: The Misconfigurations That Get Exploited

An attacker who lands on a Windows host almost never arrives as an administrator. Privilege escalation is how they get there, and the overwhelming majority of real escalations exploit configuration rather than a kernel vulnerability. That is good news for defenders, because configuration is auditable. Service misconfigurations Unquoted service paths. A service whose executable path contains spaces and is not enclosed in quotes causes Windows to try each space-delimited prefix in turn, appending .exe . A path such as C:\Program Files\My App\service.exe makes Windows try C:\Program.exe first. If a low-privileged user can write to one of those locations, they place a file there and it runs with the service's privileges at next start. Weak service permissions. If a standard user can modify a service's configuration, they can point its binary path at anything and restart it. The service runs as SYSTEM, so the escalation is immediate and requires no exploit at all. Weak file...

DISA STIGs: Severity Categories, SRGs, and Working Through a Checklist

Security Technical Implementation Guides are hardening standards published by the Defense Information Systems Agency. They are mandatory for US Department of Defense systems, and they are used well beyond that because they are free, detailed, and maintained — for many products a STIG is the most thorough public hardening guidance available. What is in one A STIG covers one product or product family: an operating system version, a database, a browser, a network operating system, an application server. Inside are individual requirements, each with a stable identifier, a severity category, a statement of the requirement and why it exists, an explicit check procedure describing how to determine compliance, and an explicit fix procedure describing how to remediate. The check-and-fix pairing is what distinguishes STIGs from most hardening guidance. A requirement is not a suggestion to "restrict access" — it is a specific command to run, a specific expected output, and a specif...

Kiosk Escape: Breaking Out of Locked-Down Sessions, and How to Prevent It

A kiosk is a system running one application in a restricted session — a self-service terminal, a check-in screen, a public catalogue, a digital sign. The restriction is usually implemented inside the application, and that is the flaw: an attacker who reaches anything outside the application's own interface is out, because nothing below it was locked down. How escapes happen The techniques are unglamorous and consistent, and they all exploit the same gap. Dialog boxes. Any feature that opens a file picker, a print dialog, a save-as window or a help browser hands the user a file system interface. From a file dialog it is frequently possible to browse the disk, rename or launch files, and in some cases type a path that opens a command prompt. Print-to-file, "open containing folder" and attachment handling are the recurring routes. Keyboard shortcuts. Task manager, run dialog, accessibility features, window switching, and the shortcuts that invoke system utilities. A ...

ASLR, DEP and Stack Canaries: The Exploit Mitigations and Their Limits

Memory corruption vulnerabilities still exist, and yet exploiting them reliably is far harder than it was twenty years ago. That change came from a stack of mitigations, each addressing one step an exploit must complete. None of them fix the underlying bug — they make the bug expensive to turn into code execution. What an exploit has to achieve Understanding the mitigations requires understanding the steps. A classic stack overflow overwrites a return address so that when the function returns, execution jumps to attacker-chosen code. To succeed, the attacker needs to overwrite the right memory, needs somewhere to put code or something useful to jump to, and needs to know the address of that thing. Each mitigation removes one of those. Stack canaries A random value placed between local variables and the saved return address. Before returning, the function checks it is unchanged; if a linear overflow has overwritten the return address, it has overwritten the canary too, and t...

TLS Configuration: Protocol Versions, Cipher Suites and What to Disable

TLS configuration is one of the few security tasks where the correct answer is short, well documented and still frequently got wrong — usually because a server was configured years ago and nobody revisited it. Protocol versions SSL 2.0 and 3.0 are long dead and must be disabled. TLS 1.0 and 1.1 are deprecated, removed from browsers, and disallowed by most compliance regimes. TLS 1.2 remains widely required for compatibility and is acceptable when configured with modern cipher suites. TLS 1.3 is the current version and is a substantial simplification: it removes every weak option rather than making them configurable, mandates forward secrecy, encrypts more of the handshake, and completes in fewer round trips. That design decision is the interesting one. TLS 1.2 is secure if configured correctly , and most vulnerabilities of the last decade exploited options it permitted. TLS 1.3 removes the ability to configure it wrongly, which is a stronger guarantee than documentation. ...

Switch Port Hardening: The Layer 2 Controls, in One Checklist

Layer 2 attacks are almost all defeated by configuration that takes minutes and is almost never applied. This is the consolidated list — each control, the specific attack it stops, and where it belongs. Treat it as the access switch template. Port security Limits how many MAC addresses a port may learn. An access port serving one workstation needs one, or two where an IP phone passes traffic through. Stops: MAC flooding, which fills the switch's address table so it fails open and floods frames to every port, turning a switch into a hub — the attack under MAC flooding . Also constrains casual MAC spoofing and unauthorized devices. Configure: a low maximum, sticky learning so the address is recorded automatically, and a violation action of shutdown with timed error-disable recovery. PortFast with BPDU Guard PortFast skips the spanning tree listening and learning states so a host gets a working link immediately. BPDU Guard shuts the port down if any bridge protocol da...

TPM: Measured Boot, Key Sealing, and What the Chip Actually Does

A Trusted Platform Module is a small dedicated chip — or a firmware equivalent — that stores keys and records what the system loaded as it started. It does not encrypt your disk or run your applications. It holds secrets in a place software cannot read them, and it attests to the state of the machine, and everything useful follows from those two capabilities. Platform Configuration Registers The mechanism behind measured boot, and the concept worth understanding properly. As the system starts, each stage measures the next before handing control to it — hashing the firmware, the boot loader, the kernel and its configuration — and extends the result into a Platform Configuration Register. Extending means the new value is combined with the existing one and the result stored, so a register accumulates a hash chain of everything measured into it. That chain cannot be rewound or set to an arbitrary value. Software can extend a register; it cannot reset one, and t...

Port Knocking and Single Packet Authorization: Obscurity With Limits

Port knocking keeps a service's port closed until a client connects to a predefined sequence of other ports. The firewall watches for that sequence from a source address and, when it sees it, opens the real port to that address for a short window. To a scanner, the service simply does not exist. How it works A daemon watches firewall logs or the packet stream for connection attempts. A client sends connection attempts to, say, three specific ports in a specific order — the attempts are refused, which is fine, because the point is only that they were observed. On recognizing the sequence from a source address, the daemon adds a temporary firewall rule permitting that address to reach the protected port. The client then connects normally and authenticates as usual. The rule expires after a timeout or when the session ends. The knock sequence is not authentication for the service. It is a precondition for the port being reachable at all, and the service's own authentication s...

Web Server Hardening: The Findings a Baseline Scan Always Returns

Run a baseline web server scan against almost any deployment and the same categories come back. None of them are sophisticated, all of them are configuration rather than code, and together they account for a large share of the easy wins in a web application assessment. Knowing the list is worth more than knowing any particular tool. Default and leftover content Installation leaves things behind: default index pages that confirm the server software and version, sample applications and scripts, documentation directories, test pages, and administrative interfaces reachable at predictable paths. Deployment adds more — backup files created while editing a configuration, files with editor suffixes, archives left in the web root, and version control directories published along with the application. A .git directory served over HTTP hands an attacker the entire source history, and it appears in real assessments regularly. The fix is a deployment process that publishes only intended ...

CMS Security: Why Content Management Sites Keep Getting Compromised

Content management systems run an enormous share of the web, and they are compromised at a rate out of proportion to their share. The reason is not that the core software is unusually weak — it is the ecosystem around it, and the fact that most installations are administered by someone whose job is not administration. Plugins and themes, not core Core CMS software is widely scrutinised, patched quickly, and in most cases updates itself. Serious core vulnerabilities are rare. Plugins and themes are the opposite. A typical site runs a dozen or more, written by different authors of varying skill, many maintained by one unpaid person, and a substantial share abandoned entirely. They run with full application privileges and frequently full database access, so a vulnerability in the smallest of them is a vulnerability in the site. The recurring failure modes are ordinary: missing authorization checks on administrative endpoints, unvalidated input reaching the database, unrestricted...

Exposed Remote Access: Why SSH and RDP on the Internet Get Compromised

Internet-facing remote access services are one of the two leading initial access vectors in real incidents, alongside phishing. The reason is unglamorous: a management service reachable from anywhere is continuously attacked by automated tooling, and it only has to be wrong once. What actually happens to an exposed service Put an SSH or RDP service on a public address and authentication attempts begin within minutes — not because anyone targeted you, but because internet-wide scanning identifies every listening service continuously, and lists of responsive hosts are traded and reused. The discovery side of this is covered under internet-wide scanning . The attempts are automated and patient. Common usernames paired with common passwords, credentials from breach dumps, and default vendor account names, delivered slowly enough from enough distinct addresses that per-source rate limits never trigger. Success comes from a small number of predictable weaknesses: a default or uncha...

SELinux: Mandatory Access Control, Contexts, and Enforcing Mode

SELinux enforces access rules that the file owner cannot change and that root cannot casually override. That single property — policy set by the system rather than by the resource owner — is what makes it mandatory access control, and it is the distinction the exam is testing when SELinux appears. Discretionary versus mandatory Standard Linux permissions are discretionary: the owner of a file decides who may read or write it, and root may do anything. That model works until a process is compromised, at which point the attacker inherits everything that process was allowed to do — which, for a service running as root, is everything. Mandatory access control adds a second layer that the process cannot negotiate with. A system-wide policy states which subject types may perform which operations on which object types, and the kernel enforces it regardless of ownership or user identity. A compromised web server confined by policy can read its document root and open its l...

Jump Servers and Bastion Hosts: Controlling the Path Into a Zone

A jump server is the single controlled path between one security zone and another. Administrators connect to it, and from there to the systems they manage; nothing else is permitted to cross. The value is not the server itself — it is that a broad, unmanageable set of access paths is reduced to one that can be hardened, logged and reviewed. What it is for Without one, every administrator's workstation needs a route to every managed system. That is an enormous number of paths, each of which must be permitted by firewall rules and each of which is an entry point if the workstation is compromised — and a workstation runs a browser and an email client, which is exactly where compromise begins. Concentrating access means one set of rules, one place to enforce multi-factor authentication, one audit trail, and one host to patch and monitor properly. It also enforces a boundary that is otherwise theoretical: if the only route into the production segment is through the jump host,...

Amplification Attacks: How Not to Become Someone Else’s Weapon

Most discussion of amplification attacks is written from the victim's point of view. This one is written from the other side: the servers doing the amplifying belong to ordinary organizations who have no idea they are participating, and the controls that stop it are entirely within their reach. The two ingredients Spoofing makes it possible. The attacker sends requests with the victim's address as the source, so every response goes to the victim rather than back to the attacker. This works only because many networks still forward packets whose source address does not belong to them. Amplification makes it efficient. Certain services return a response far larger than the request that triggered it. The ratio between the two is the amplification factor , and it is what turns an attacker's modest upstream bandwidth into hundreds of times as much traffic at the victim. The attacker's cost is therefore tiny, their address is never exposed, and the traffic arrives at th...