[{"content":" TL;DR — In this guide, you will learn:\nHow to choose between GrapheneOS, a well-configured stock Android, and alternative custom ROMs. Which privacy-friendly apps to use as replacements for Google services. How to isolate tracker-heavy apps with Shelter and protect your network traffic with Tor. How to manage permissions, VPNs, and cloud storage securely. Summary To make Android more private, it is best to use GrapheneOS on a supported Pixel device, install fewer apps, restrict permissions and network access, isolate tracker-heavy apps into separate profiles, and download apps only from verifiable sources. While de-Googling improves privacy, it does not replace the need for regular updates, verified boot, and good operational security habits.\nYour smartphone knows everything about you: where you go, whom you talk to, and what you search for. Every day, apps installed on your Android device silently transmit your personal data to Google and dozens of third-party companies. This guide shows you how to take back control of your phone, eliminate your dependence on Google, and build a genuinely private mobile environment—all without sacrificing day-to-day usability.\nThis guide is open to improvements and suggestions. I will describe the setup that I believe offers the best balance between usability and privacy. Over time, I will expand the various sections and introduce alternatives for those who might prefer different apps or services. If you would like to offer suggestions or contribute, you can open a pull request on GitHub .\nThis guide covers Android in general; I have also written a guide specifically for GrapheneOS, which you can find here .\nOperating System In 2026, if you genuinely care about the balance between privacy and security, the practical hierarchy is: GrapheneOS on a supported Pixel \u0026gt; a recent, well-configured stock Android \u0026gt; alternative custom ROMs with an unlocked bootloader. LineageOS, CalyxOS, and similar projects are useful for extending device lifespan, gaining control, and removing Google services, but they should not be considered equivalent to GrapheneOS in terms of system hardening or hardware-level security guarantees.\nTherefore, I highly recommend using GrapheneOS if possible. If your device is not supported, LineageOS is a reasonable alternative, but you must accept significant trade-offs regarding verified boot, timely security patches, and protection against physical access attacks.\nThis guide is designed to offer a practical balance between security and privacy for everyday use. Procedures like rooting or leaving your bootloader unlocked permanently reduce a device\u0026rsquo;s security and are strongly discouraged.\nTo simplify the steps for installing LineageOS, here is a brief summary:\nUnlock the bootloader. Flash a custom recovery. Flash LineageOS . Re-lock the bootloader (if supported by your device and the ROM). Note: The base version of any ROM without Google apps is preferable for privacy, but it is important to weigh the usability trade-offs. While microG improves app compatibility, it is still a compromise. On GrapheneOS, if you genuinely need apps that depend on Google, it is far more secure to use sandboxed Google Play Services in a dedicated profile rather than relying on custom ROMs with system-level integrations.\nAt this point, you will have a fresh, newly installed operating system!\nSystem Tweaks and Setup To configure a privacy-oriented device, start by adjusting several operating system settings. While these options may vary depending on your device and ROM, here are the key recommendations:\nDisable Bluetooth and Location Services whenever they are not in use. Enable Lock-Screen Privacy by setting a strong PIN/passphrase and hiding notification content when the device is locked. Disable Telemetry and usage data sharing across the system. Enable Device Encryption if it is not active by default. Disable Unencrypted Cloud Backups (use local, encrypted backups instead). Decline Data Sharing and Crash Reporting whenever prompted by newly installed apps. Turn Off USB Debugging immediately after use (it is disabled by default), as leaving it active introduces major security vulnerabilities. We will cover managing individual app permissions later in this guide.\nApp Distribution Platforms Now that we have moved away from the Google ecosystem, we need alternative platforms to download and update apps. The primary recommendations are:\nObtainium : More of an app updater than a store, Obtainium acts like a package manager, allowing you to download and update apps directly from their official source releases (e.g., GitHub, GitLab, or F-Droid repositories). This provides excellent security and privacy by eliminating middleman repositories. Droid-ify : A modern, fast F-Droid client with a polished interface. It provides access to thousands of open-source applications, though you should be aware of F-Droid\u0026rsquo;s general security trade-offs (such as delayed updates and repository-signed keys). Sandboxed Google Play Store (GrapheneOS only): When proprietary apps or services that depend on Google are absolute necessities, the most secure approach is using GrapheneOS\u0026rsquo;s sandboxed Google Play Services. This runs Google services as standard, unprivileged apps without special system permissions. Aurora Store : An open-source frontend for the Google Play Store. It remains useful as a fallback for downloading proprietary apps, but it is increasingly unreliable due to Google rate-limiting anonymous accounts. Shelter [!WARNING] This step is optional. It is primarily useful if you want to create isolated \u0026ldquo;containers\u0026rdquo; on your device. Using Shelter has distinct pros and cons and should only be configured if you require a Work Profile. On Android 15 and later, the native Private Space feature is simpler for many use cases, while GrapheneOS\u0026rsquo;s secondary user profiles remain the most secure solution for strict compartmentalization.\nAfter configuring your app stores, you can download Shelter .\nShelter is an open-source application that leverages Android\u0026rsquo;s built-in Work Profile functionality to create an isolated sandbox environment on your device.\nImagine a table (your operating system) with two sealed boxes on it (your main profile and your Work Profile). These profiles run side-by-side but are isolated from one another. Note that if your base operating system is bloated with tracker-heavy pre-installed apps, using Shelter alone provides limited privacy. If you cannot install a clean ROM, consider using the Universal Android Debloater to disable invasive stock applications. (Warning: Disable the apps instead of uninstalling them to prevent bootloops or system corruption on encrypted devices.)\nWhen you open Shelter, it will guide you through setting up a Work Profile. Once active, the Shelter interface will display two sections:\nMain: Your primary profile, where you should keep open-source and trusted applications. Shelter (Work Profile): The isolated sandbox where you place invasive, closed-source, or tracker-heavy apps (such as social media and banking applications). Applications in the Work Profile are marked with a small briefcase badge to distinguish them from your main apps, and they run concurrently within your existing launcher. You can install apps in either profile using the following methods:\nCloning: Clone an existing app from one profile to the other via the Shelter interface. Profile-Specific Stores: Open a store (like Droid-ify/Obtainium in the clean profile, or Aurora/Play Store in the sandboxed profile) and download the app directly. Manual APK Installation: Install downloaded APKs directly within the desired profile. (Always prefer using a package manager or store to ensure easy updates). Because the two profiles are isolated, they do not share data by default. This means contacts, photos, and files are separate. While you can enable file sharing in Shelter\u0026rsquo;s settings, managing data across profiles requires some adjustment.\nManaging Your Threat Model Across Profiles With two isolated profiles, you can apply a distinct threat model to each:\nMain Profile (Clean \u0026amp; Open Source): Aim for maximum privacy and anonymity by routing all traffic through Tor and using DNSCrypt. Work Profile (Proprietary \u0026amp; Tracker-Heavy): Accept that these apps are linked to your real identity. Focus on reducing data leakage, blocking ads, and preventing background tracking. Configuring the Main Profile (Tor \u0026amp; DNSCrypt) To secure network traffic in your primary profile, download Invizible Pro . It redirects all system traffic through the Tor network and encrypts your DNS queries.\nOpen the app, tap the three dots in the top-right corner, and enable VPN Mode. Go to your Android system settings: Network \u0026amp; Internet → VPN → Invizible Pro (or gear icon next to it). Enable Always-on VPN and Block connections without VPN to prevent accidental data leaks outside the secure tunnel. Next, adjust these key settings within Invizible Pro:\nDNSCrypt Settings: Enable require_dnssec, nolog, and nofilter to ensure you connect only to secure, non-logging DNS servers. Fast Settings: Enable Start DNSCrypt on boot and Start Tor on boot so the protections start automatically. Common Settings: Enable all protections in the MITM attack detection section to protect against network snooping on public Wi-Fi. Firewall: Go to the firewall settings and block network access for all apps that do not require an active internet connection (e.g., gallery, keyboard, offline games). Configuring the Work Profile (Ad \u0026amp; Tracker Blocking) For the profile containing proprietary apps, you can use one of two approaches:\nCommercial VPN: Protect your traffic from your ISP while routing through a trusted provider (e.g., Mullvad, Proton VPN) that offers built-in ad/tracker filtering. Local Firewall/DNS Filter: Use tools like NetGuard, RethinkDNS, or NextDNS to block network access for specific apps and filter trackers locally without routing through a VPN server. The best option depends on whether you prefer a global VPN tunnel or fine-grained local firewall rules. You can read more in the VPN and Cloud sections .\nRecommended Applications Here are the primary applications recommended for a privacy-focused Android setup:\nHeliBoard : An open-source keyboard that is functionally identical to Gboard but operates entirely offline. Preventing your keyboard from sending keystrokes to online servers is a critical step for privacy. Cromite : A hardened, Chromium-based browser with ad-blocking built-in. Excellent alternatives include Brave and, on GrapheneOS, Vanadium. Avoid Firefox-based browsers on Android; they lack modern sandboxing features and present a much larger attack surface on mobile. When downloading the following apps, be mindful of which profile you install them in:\nAegis : An excellent, open-source, offline two-factor authenticator (2FA) to replace Google Authenticator or Authy. AntennaPod : A fully open-source podcast manager and player. Bitwarden : A secure, cross-platform password manager that supports end-to-end encryption and self-hosting. Crypto Prices : A tracker for cryptocurrency prices, serving as a private alternative to CoinMarketCap. Guerrilla Mail : An Android client for the Guerrilla Mail temporary email service, useful for avoiding spam. LibreTorrent : A lightweight, fast, and open-source torrent client. KeePassDX : A secure, offline password manager supporting the KeePass (.kdbx) format. Ideal if you prefer local control over cloud syncing. Molly : A hardened version of Signal with proprietary Google dependencies stripped out. Nekogram : A feature-rich Telegram client compiled without Google Play Services. Remember that Telegram does not enable end-to-end encryption (E2EE) by default in standard chats; use Signal/Molly or SimpleX for sensitive discussions. PipePipe : A frontend for YouTube, SoundCloud, and PeerTube, allowing you to watch videos without Google tracking. Nextcloud : A mobile client for Nextcloud, which is the gold standard for self-hosted cloud storage. OpenKeychain : An open-source implementation of OpenPGP, allowing you to manage encryption keys and sign/decrypt messages. BlueWallet : A secure, open-source Bitcoin wallet supporting both on-chain and Lightning Network transactions. SimpleLogin : An email aliasing service that creates decoy addresses. Emails sent to these aliases are forwarded to your real inbox, protecting your primary email from data breaches and tracking. Simple Crypto Widget : A home screen widget to display real-time Bitcoin prices. Tor Browser : The official Android browser from the Tor Project, built to access the onion network and prevent tracking. Voice : A clean, offline, open-source audiobook player. For more resources and recommendations, visit Privacy Guides or explore the curated categories in Droid-ify.\nEmail Clients and Providers Choosing the right email client and provider is a complex topic. If you are looking for a user-friendly service that requires minimal setup, Proton Mail is highly recommended. It offers one of the best balances between day-to-day usability and privacy.\nAlternatively, you can use Thunderbird as your client, paired with a privacy-focused or community-run email provider such as Riseup , Esiliati , or Autistici .\nThunderbird also supports automated email encryption: by linking a PGP key from OpenKeychain, it will automatically encrypt outgoing messages to recipients who have published their public PGP keys.\nOnce you have installed your preferred applications, proceed to configure their permissions using the instructions below. Apply these same practices to any apps you install in the future.\nManaging App Permissions To secure your apps, navigate to Settings → Apps → Permission Manager (exact paths may vary slightly depending on your ROM) and revoke any unnecessary permissions.\nFor example, while an instant messenger like WhatsApp needs access to your contacts to find users, it does not need access to your SMS messages after the initial setup. Leaving SMS access enabled allows the app to read all incoming text messages.\nLocation, Camera, and Microphone: Pay extra attention to these. Only grant access when strictly necessary. One-Time Permissions: When an app requests a sensitive permission that you only need occasionally, select \u0026ldquo;Only this time\u0026rdquo; to prevent it from accessing that sensor in the background later. Restrict Network Access: Disable internet access for apps that do not require online features (e.g., keyboards, calculators, file managers, notes apps). Go to App Info → Mobile Data \u0026amp; Wi-Fi and toggle off network access. Firewall Blocking: To guarantee that offline apps cannot access the internet, use NetGuard or Invizible Pro to block them behind a local firewall. Many offline apps silently send usage telemetry and user data when network access is left enabled. Cloud Storage The most secure cloud storage solution is self-hosting Nextcloud . If self-hosting is not feasible, Proton Drive is a mature, end-to-end encrypted alternative that serves as an excellent hosted solution. While services like Mega.nz offer convenient free tiers, they are not ideal for a strict privacy setup.\nIf you must use a mainstream provider (like Google Drive or OneDrive) due to work or school requirements, you can protect your files using Cryptomator . This open-source utility encrypts your files locally on your device before they are uploaded to the cloud, ensuring the provider cannot read your data.\nVPN Services Using a VPN encrypts your traffic and routes it through a secure tunnel, hiding your browsing activity from your Internet Service Provider (ISP). However, this shifts trust from your ISP to the VPN provider.\nWhile almost every VPN provider claims a \u0026ldquo;no-logs\u0026rdquo; policy, these claims are difficult to verify independently. Based on their transparency, track record, and technical implementation, the most recommended providers are:\nMullvad VPN: Renowned for not requiring an email address or personal information to sign up, and accepting cash or cryptocurrency. Proton VPN: Integrates well with the Proton ecosystem and has open-source, audited clients. IVPN: A security-focused provider with excellent privacy standards and multi-hop capabilities. Self-Hosting Your VPN : Building your own WireGuard server to secure your connection on public networks. Final Thoughts Following this guide will drastically reduce your personal data footprint. While it does not guarantee absolute anonymity, it significantly increases your everyday mobile privacy and security.\nTo stay updated on privacy, security, and de-Googling trends, consider visiting the following communities:\nr/degoogle r/privacytoolsIO r/privacy \u0026ldquo;Arguing that you don\u0026rsquo;t care about the right to privacy because you have nothing to hide is no different than saying you don\u0026rsquo;t care about free speech because you have nothing to say.\u0026rdquo; — Edward Snowden\nRelated Guides The Definitive Guide to GrapheneOS — The most secure operating system for mobile privacy, analyzed in full detail. How to Build a Threat Model — The first step in protecting your privacy: defining your threats and objectives. Self-Hosted VPN with Ad Blocking — Build your own personal VPN with WireGuard and Pi-hole to block ads and trackers. Tor Node Tutorial — How to set up a Tor relay to support free communication and browse anonymously. ","permalink":"https://b4.lol/android/","summary":"Set up a de-googled Android phone with maximum privacy and security without giving up usability. Step-by-step guide with recommended apps.","title":"De-Google Android: The Complete Privacy Guide"},{"content":" TL;DR — In this guide, you will learn:\nWhy GrapheneOS is the gold standard for mobile privacy and how to choose the right Pixel. How to install and configure GrapheneOS from scratch. How to leverage user profiles, sandboxed Google Play Services, and advanced security settings. Troubleshooting: resolving common app compatibility and geolocation issues. What is GrapheneOS and who is it for? GrapheneOS is a secure, open-source Android operating system focused on privacy and security. It is designed for individuals who want to minimize data collection, enhance application isolation, and maintain compatibility with standard Android apps. This compatibility is achieved by running Google Play Services inside an unprivileged sandbox.\nQuestion Short Answer Which phones does it work on? Only officially supported Google Pixel devices. Do I have to give up Google apps? No; Google Play Services can be installed as unprivileged, sandboxed apps. Is it suitable for beginners? Yes, provided you follow a guided setup and learn to navigate user profiles. Is it anonymous by default? No. It improves privacy and security, but anonymity depends on your operational habits. Primary Sources: Official GrapheneOS documentation, project FAQs, the Android Open Source Project (AOSP), and hands-on testing on supported Pixel hardware.\nYour smartphone is your most intimate device, tracking your location, communications, and daily habits. Stock Android and iOS operating systems constantly transmit telemetry to Google and Apple. GrapheneOS is the premier open-source alternative that offers enterprise-grade security without compromising user privacy. This guide covers everything from hardware selection to advanced configuration.\nGrapheneOS is a Free and Open Source Software (FOSS) operating system based on the Android Open Source Project (AOSP) , built to enhance privacy and security. It represents the current gold standard for custom mobile operating systems.\nThis guide compiles technical knowledge regarding mobile privacy and security as implemented by the GrapheneOS project, drawing inspiration from security researchers like PatrickD .\nThis resource is entirely free, non-profit, and does not track users or serve ads. If you find this guide helpful, please share it on Telegram channels, X (Twitter), or other communities to support privacy awareness.\nChoosing a Device The most common question for newcomers is: why does GrapheneOS support so few devices, and why are they all Google Pixel phones?\nWhy only Pixel devices? According to GrapheneOS, Pixel devices are currently the only viable option. This is not due to an exclusive contract with Google, nor because Pixels are inherently flawless, but rather because all other OEM alternatives fail to meet GrapheneOS\u0026rsquo;s hardware security requirements. The project maintains a list of requirements for supported devices; currently, only Pixels meet these standards.\nPixel devices provide robust support for custom operating systems because they serve as the reference platform for Android development. They receive regular firmware updates and offer advanced hardware security features, such as Memory Tagging (MTE) and custom key installation for verified boot, which remain functional even when running custom ROMs.\nMost other OEM manufacturers treat alternative operating system support as a non-professional hobby feature. They frequently omit basic hardware security measures, delay critical firmware updates, and expand the device\u0026rsquo;s attack surface through invasive proprietary system modifications.\nExtended device support would force GrapheneOS to compromise on its security baseline by supporting devices that lack verified boot or hardware isolation. Developing hardware-specific security features for insecure devices would divert critical development resources away from hardening the core OS.\nAre there alternatives? While there are various alternative operating systems for Android devices, none match GrapheneOS\u0026rsquo;s security hardening.\nA primary criticism leveled by the GrapheneOS team against other custom ROM projects is their delay in implementing upstream Android security patches.\nLineageOS : Focuses on device longevity and broad compatibility rather than strict security. It typically lacks verified boot, leaving devices vulnerable to physical tampering. /e/OS : market-positioned as a \u0026ldquo;de-Googled\u0026rdquo; mobile ecosystem, but it is built on top of LineageOS and includes custom applications that introduce additional security risks. CalyxOS : Frequently falls behind on security patches and has historically faced criticism for reporting incorrect patch levels. It also has had implementation bugs in core security features, such as emergency data-wipe routines. Note: For a detailed comparison of Android-based operating systems, consult this third-party Android Comparison Table .\nCopperheadOS : The commercial entity under which GrapheneOS was originally developed. Following a hostile internal split, GrapheneOS transitioned into an independent, fully open-source project. CopperheadOS is now a closed-source commercial fork, which is generally not recommended. Purism (Librem 5) : Promises hardware privacy via physical kill switches. However, GrapheneOS criticizes the Librem 5\u0026rsquo;s hardware components, firmware update mechanisms, and dependency on closed-source blobs. GrapheneOS argues that a locked-down iOS device in Lockdown Mode provides a superior security posture compared to boutique Linux phones. GrapheneOS focuses on substantive, verifiable security rather than marketing buzzwords, making it an openly technical project.\nCan Google hardware be trusted? It may seem counterintuitive to use Google-manufactured hardware for a privacy-focused setup. However, because Pixels are the reference devices for Android security, they receive intense scrutiny from external security researchers. Under these circumstances, hiding intentional hardware backdoors without detection would be extremely difficult.\nIt is also easier for adversaries to compromise the supply chain of niche, boutique hardware manufacturers than to intercept the global logistics network of a major manufacturer like Google. Furthermore, leaks from forensic extraction firms (such as Cellebrite) show no evidence of hardware-level backdoors in modern Pixel chips. If you wish to avoid Google entirely, the next best alternative is an Apple iPhone configured in Lockdown Mode.\nWhich Pixel should you choose? For maximum security, select a recently released Pixel model. In 2026, this means choosing a model from the Pixel 9 or Pixel 10 family. These newer devices feature advanced hardware security mitigations like Memory Tagging (MTE), faster secure elements, and modern cellular modems. If you plan to use multiple concurrent user profiles, the Pro models equipped with 16 GB of RAM are highly recommended.\nIf you are looking for the best budget option, the Pixel 9a is a practical choice. The Pixel 8 series also remains a solid baseline if you already own one. Always check the official Device Lifetime Table before purchasing a device.\nOnce a device reaches its End-of-Life (EOL) date, it stops receiving critical proprietary firmware and driver patches from the chip manufacturers (like Google or Broadcom). Even if GrapheneOS continues to provide legacy OS updates, the device remains vulnerable to hardware-level exploits.\nModel RAM Storage (GB) Processor Concurrent User Profiles Pixel 10 Pro XL 16 GB 128-1024 Tensor G5 14 Pixel 10 Pro 16 GB 128-1024 Tensor G5 14 Pixel 10 12 GB 128-256 Tensor G5 10 Pixel 9 Pro XL 16 GB 128-1024 Tensor G4 14 Pixel 9 Pro 16 GB 128-1024 Tensor G4 14 Pixel 9 12 GB 128-256 Tensor G4 10 Pixel 8 Pro 12 GB 128-1024 Tensor G3 10 Pixel 8 8 GB 128-256 Tensor G3 6 Pixel 8a 8 GB 128-256 Tensor G3 6 Installation GrapheneOS can be installed securely using the official WebUSB Installer from a compatible browser (like Chromium-based browsers on Linux, macOS, or Windows). The installer handles unlocking the bootloader, flashing the firmware, and re-locking the bootloader automatically.\nProtection Against Tampering Verified Boot Key Hash When your device boots with GrapheneOS, a warning screen will inform you that it is running a custom operating system. This screen displays a cryptographic fingerprint (hash) representing the public signing key used to sign the custom OS. You should match this hash against the official values to confirm the system\u0026rsquo;s integrity:\nDevice Verified Boot Key Fingerprint Pixel 10 Pro Fold 55a2d44103e56d5ec65496399c417987ba77730e6488fc60ba058d09fc3caee3 Pixel 10 Pro XL 141d7fc32af7958a416f2661b37cf6f27bfb376fb5ce616aeaa27a82c7a04f74 Pixel 10 Pro 4e8ee8f717754052198ca6d2d3aaa232e2461b4293c0d6f297e519cc778de093 Pixel 10 3f7415ea26f5df5b14ea6d153256071a7a1af9ce7b0970b7311cc463c7ea02c7 Pixel 9a 0508de44ee00bfb49ece32c418af1896391abde0f05b64f41bc9a2dfb589445b Pixel 9 Pro Fold af4d2c6e62be0fec54f0271b9776ff061dd8392d9f51cf6ab1551d346679e24c Pixel 9 Pro XL 55d3c2323db91bb91f20d38d015e85112d038f6b6b5738fe352c1a80dba57023 Pixel 9 Pro f729cab861da1b83fdfab402fc9480758f2ae78ee0b61c1f2137dd1ab7076e86 Pixel 9 9e6a8f3e0d761a780179f93acd5721ba1ab7c8c537c7761073c0a754b0e932de Pixel 8a 096b8bd6d44527a24ac1564b308839f67e78202185cbff9cfdcb10e63250bc5e Pixel 8 Pro 896db2d09d84e1d6bb747002b8a114950b946e5825772a9d48ba7eb01d118c1c Pixel 8 cd7479653aa88208f9f03034810ef9b7b0af8a9d41e2000e458ac403a2acb233 Compare the hash displayed on your boot screen with the Official Web Installer Reference Hash to ensure your system firmware has not been modified.\nAuditor App \u0026amp; Attestation GrapheneOS includes a pre-installed Auditor app. This utility uses hardware-based attestation to cryptographically verify the integrity of the operating system. You can verify your device locally using a second phone, or automate the verification process using the official attestation.app service. This service will notify you via email if your device fails to perform a scheduled remote attestation check, signaling potential tampering.\nHardening Through Settings GrapheneOS provides extensive local controls to harden your system, minimize your attack surface, and sandbox applications.\nSecure Lock Screen GrapheneOS encrypts user data with keys derived from your lock screen passcode. The hardware secure element (Titan M2) enforces escalating delays between incorrect attempts, making brute-force attacks infeasible.\nPasscode Strength: Use a strong PIN (at least 6 digits) or an alphanumeric passphrase. GrapheneOS disables weak unlock patterns by default. PIN Scrambling: Enable PIN scrambling to randomize the layout of the entry pad, preventing adversaries from guessing your code via fingerprint smudges or shoulder surfing. Biometrics: Biometric unlock (fingerprint) can be enabled, but for high-security threat models, limit fingerprint access to in-app authentication and require a PIN/password to unlock the device. GrapheneOS also supports two-factor unlock (requiring both fingerprint and passcode). Panic Trigger: You can define a \u0026ldquo;Panic PIN/Password\u0026rdquo; under the lock screen settings. Entering this specific passcode at the lock screen will trigger a hardware factory reset, purging all decryption keys and shutting down the device. Auto Reboot When a device is unlocked, its decryption keys remain in memory. If the device is stolen in this state (After First Unlock or AFU), forensic tools can extract data from the device RAM.\nTo mitigate this, GrapheneOS features an Auto Reboot timer. If the device remains locked without being opened for a specified duration (adjustable from 10 minutes to several hours), it will restart automatically. Restarting returns the device to the Before First Unlock (BFU) state, fully encrypting the filesystem.\nUSB Port Restrictions Forensic extraction tools often exploit vulnerabilities in USB interface drivers to bypass lock screens. GrapheneOS offers hardware-level control over the USB-C interface.\nBy default, the system rejects new USB data connections while the screen is locked. You can configure the USB port to be completely disabled at the data level while the OS is running, allowing only charging.\nWireless Attack Surface To minimize the wireless attack surface:\nWi-Fi and Bluetooth Timers: Configure Wi-Fi and Bluetooth to turn off automatically when disconnected for a set period. LTE-Only Mode: Set your cellular preferences to LTE-only. This disables legacy 2G/3G protocols (which are vulnerable to fake cell tower IMSI-catcher attacks) and avoids the complex codebase of early 5G implementations. Cellular Privacy Limitations Cellular networks require your SIM card to authenticate using a unique hardware identifier (IMSI) linked to your real identity. To prevent tracking:\nAvoid Cellular Calls and SMS: Use end-to-end encrypted internet protocols (like Signal or SimpleX) instead of standard carrier routing. Cellular Hotspots: Routing your traffic through a secondary Wi-Fi hotspot does not hide your location; it simply shifts the cellular tracking signature to the hotspot hardware, which is often less secure than your Pixel\u0026rsquo;s isolated baseband processor. Airplane Mode: Airplane mode completely disables the baseband transmitter. You can safely toggle Wi-Fi back on while cellular functions remain disabled. App Exploit Protection Under Settings » Security, GrapheneOS offers advanced exploit mitigations:\nMemory Allocator Hardening: Enforces strict memory protections for user applications, making buffer overflows harder to exploit. Disable JIT Compilation: Forces Ahead-Of-Time (AOT) app compilation. This improves security by removing the Just-In-Time compiler attack surface, though it increases app installation and update times. Granular App Permissions GrapheneOS enhances the standard Android permission model:\nSensors Permission: Android allows apps to read the accelerometer, gyroscope, and compass without permission. GrapheneOS lets you toggle off sensor access globally or per-app to prevent device fingerprinting. Network Permission: You can revoke network access for local apps (like calculators or keyboards) during installation, preventing them from transmitting data. Storage Scoping: Instead of granting an app access to your entire storage directory, you can enable Storage Scopes to allow access only to specific files or folders. Contact Scopes: Allows you to share a curated list of contacts with an app rather than exposing your entire address book. Backups GrapheneOS includes Seedvault, an encrypted backup utility that can save system configurations and application data to a local USB drive or self-hosted Nextcloud server. For files, it is recommended to perform manual backups directly to a laptop via USB file transfer.\nSecondary User Profiles User profiles offer strict data compartmentalization. Each profile functions like a separate physical device, encrypting its data with its own unique keys.\nBackground Profile Control: You can disable \u0026ldquo;Allow running in background\u0026rdquo; for secondary profiles. When you switch away, the profile\u0026rsquo;s user session ends, and its decryption keys are purged from memory. App Sharing: You can clone application binaries between profiles to save disk space, but the application databases and user data remain isolated. Private Space: A nested user profile inside the primary \u0026ldquo;Owner\u0026rdquo; profile. It integrates notifications and apps with the Owner profile while unlocked, but stops the user session and locks data when closed. Work Profiles: Ideal for separating work apps using local management utilities like Shelter without requiring a corporate MDM server. Recommended Applications GrapheneOS includes only a minimal set of secure, open-source default applications to limit the pre-installed attack surface.\nCamera: GrapheneOS\u0026rsquo;s default camera app is secure, offline, and automatically strips EXIF metadata from captured images. Pixel Camera: If you prefer Google\u0026rsquo;s proprietary camera features, you can install the Pixel Camera app from the Play Store and revoke its network permissions. Enable the \u0026ldquo;Special access to hardware accelerators for Google apps\u0026rdquo; toggle to ensure full image processing capability. Keyboard: GrapheneOS\u0026rsquo;s default keyboard is a legacy offline client. For a modern, open-source alternative with glide typing, install HeliBoard . Vanadium Browser: Based on Chromium, Vanadium is hardened against web exploits and is the recommended browser for GrapheneOS. Revoke its sensor permissions to prevent browser-based tracking. App Compatibility Almost all Android apps run on GrapheneOS. The primary exceptions are apps requiring Google\u0026rsquo;s Play Integrity API (formerly SafetyNet) with hardware-enforced certification. This may prevent some mobile banking apps and competitive multiplayer games (like Pokémon GO) from running. NFC payments via Google Pay are also unsupported.\nSandboxed Google Play Services If an app requires Google Play Services, you can install them directly from the GrapheneOS App Store. On GrapheneOS, Google Play Services run as standard, unprivileged apps inside the normal application sandbox. They cannot access your hardware identifiers (IMEI, serial numbers) or override system permissions.\nYou can configure Play Services\u0026rsquo; background network access under Settings » Apps » Sandboxed Google Play to balance notification reliability (via Firebase Cloud Messaging) with battery consumption.\nApplication Stores Accrescent : A security-focused app store designed for GrapheneOS, supporting developer-signed metadata and modern verification. Obtainium : Tracks and downloads app updates directly from official developer source repositories (like GitHub releases). Pair it with AppVerifier to confirm package integrity. Droid-ify : A modern, fast client for the F-Droid open-source repository. Aurora Store: A private client for the Google Play Store, useful for downloading proprietary apps without logging into a Google account. Troubleshooting Common Issues Geolocation Issues By default, GrapheneOS routes location requests to GNSS (satellite) receivers, which can be slow indoors. To improve speed:\nEnable A-GNSS assistance under Settings » Location. If Sandboxed Google Play is installed, you can enable Google Location Accuracy under the Sandboxed Google Play settings (this requires granting Play Services background location and network permissions). App Crashes If an app crashes, check its permissions (such as network access) or temporarily disable exploit mitigations (like hardened memory allocation) for that specific app under its settings page.\nSupport the Project The GrapheneOS project relies entirely on community support and donations. If you find this guide valuable, consider supporting their development directly at grapheneos.org/donate .\nRelated Guides De-Google Android: Complete Privacy Guide — Complete configuration for secure Android platforms. How to Build a Threat Model — Define your assets and threat boundaries. Self-Hosted VPN with Ad Blocking — Secure your mobile traffic using WireGuard and Pi-hole. Tor Relay Tutorial — Set up a Tor node to support anonymous communication. ","permalink":"https://b4.lol/graphene/","summary":"Everything about GrapheneOS: installation, configuration, user profiles, sandboxed Play Services and troubleshooting. The most complete guide available.","title":"GrapheneOS: The Complete Guide to the Best Privacy OS"},{"content":" TL;DR — In this guide, you will learn:\nHow to choose the right Linux distribution for your security and privacy objectives. How to configure disk encryption, firewalls, and kernel hardening from initial installation. How to isolate applications using Flatpak, Firejail, and advanced sandboxing techniques. How to verify and audit your security posture using system verification tools. Summary Linux hardening reduces your system\u0026rsquo;s attack surface and limits the blast radius of a potential compromise. Achieving a secure desktop requires an up-to-date distribution, full-disk encryption, a restrictive firewall, secure DNS resolution, kernel hardening, application sandboxing, Secure Boot verification, service management, and periodic audits. Linux is not secure by default; it becomes secure only through consistent and intentional configuration.\nThe Linux ecosystem is often portrayed as a security paradise: just install any distribution and you are magically protected from all threats. The reality is far more nuanced. A desktop Linux installation left in its default configuration can be surprisingly vulnerable. Fortunately, with the right knowledge and a little patience, you can transform your setup into a secure digital fortress.\nThis guide walks you through the hardening process step-by-step, covering everything from distribution selection to local filesystem overrides.\nSecurity is a continuous process, not a static state. There is no single \u0026ldquo;perfect\u0026rdquo; configuration; there is only the configuration that meets your specific threat model. Every section in this guide weighs the trade-offs of each mitigation so you can make informed decisions.\nThis guide is open to improvements and suggestions. If you want to contribute, report errors, or propose additions, feel free to open a pull request on GitHub .\nWhy use Linux for security? Using Linux provides concrete advantages for security and privacy, though it comes with limitations you must understand.\nTransparency and Control Linux is open source. The codebase is transparent and verifiable by anyone. When proprietary operating systems claim they do not collect telemetry or access your data, you must trust their claims blindly. On Linux, you can verify this behavior. While no single developer audits millions of lines of code daily, the public nature of the code makes backdoors difficult to hide.\nFurthermore, control is absolute: you decide exactly what runs on your system, which ports are open, and what telemetry is allowed. There are no forced updates, hidden background services, or pre-installed bloatware.\nInherent Desktop Security Gaps Out-of-the-box, desktop Linux installations often lack modern endpoint security mitigations present in macOS or Windows 11:\nApplication Sandboxing: By default on a standard Linux desktop, user-installed applications have read/write access to your entire home directory and system sockets. Sandboxing is not enforced natively at the OS level. Secure Boot Integration: While Linux supports Secure Boot, the default configuration relies on Microsoft\u0026rsquo;s third-party keys rather than local, user-managed cryptographic signatures. Wayland vs. X11: The historical X11 graphics protocol is insecure; any running graphical application can capture keystrokes, inject input, and record screen activity from other windows. Upgrading to Wayland is essential to enforce graphical app isolation. The strength of Linux is that it provides the raw tools to resolve these gaps. The responsibility for configuring these protections rests with you.\nChoosing a Secure Linux Distribution Selecting your distribution is the foundation of your security architecture. An incorrect choice here can undermine all subsequent hardening efforts.\nRelease Models: Rolling vs. Fixed A common misconception is that \u0026ldquo;stable\u0026rdquo; distributions (like Debian Stable) are more secure because their packages change less frequently. In practice, the opposite is often true for security patches.\nFixed-release distributions freeze package versions and backport security patches. The problem is that many security fixes are merged upstream without receiving an official CVE identifier, meaning they are rarely backported to legacy packages. Additionally, backporting complex patches can introduce regression vulnerabilities.\nRolling-release or rapid-release distributions (like Fedora, Arch, or openSUSE Tumbleweed) pull directly from upstream releases, ensuring you receive security fixes immediately as written by the original developers.\n[!TIP] If you are concerned about stability on a rolling-release system, select a distribution that supports transactional file systems (like openSUSE Aeon) or configure system rollbacks using Btrfs snapshots. This gives you the latest security updates with the ability to revert changes if an update causes issues.\nDesktop Environments: The Wayland Requirement The primary security requirement for your desktop environment is native support for the Wayland graphics protocol. The two recommended desktop environments are GNOME and KDE Plasma.\nWayland isolates graphical applications from one another. Under Wayland, applications cannot record the screen, capture keystrokes from other windows, or inject inputs without explicit user consent mediated by the desktop compositor.\nGNOME: A minimal, opinionated environment that integrates tightly with core security APIs. It is the default on Fedora Workstation and Ubuntu. KDE Plasma: Highly customizable and feature-rich. Wayland support in modern KDE Plasma is stable and serves as the default on openSUSE and Fedora KDE Spin. Verify your active display protocol by running:\necho $XDG_SESSION_TYPE The output must return wayland. If it returns x11, application sandboxing cannot be enforced securely.\nRecommended Distributions 1. Fedora Workstation (Recommended) Fedora offers a rapid-release cycle with up-to-date kernels, SELinux enabled in enforcing mode by default, and quick adoption of modern security technologies (Wayland, PipeWire). It is the most balanced choice for everyday development.\n2. Debian Stable Debian provides an incredibly stable, low-maintenance base. While packages are older, the Debian Security Team is highly responsive. To mitigate the lag on upstream package updates, run user-facing applications (like browsers) via Flatpak to keep them updated independently of the core OS.\n3. Fedora Atomic Desktops (Silverblue/Kinoite) An immutable operating system variant where the root filesystem is mounted read-only. Updates are applied atomically as system images, ensuring you can roll back the entire OS to a prior state on boot if a failure occurs. Applications are isolated using containerization and Flatpak.\n4. SecureBlue A hardened downstream variant of Fedora Atomic. It integrates hardened_malloc globally, enforces restrictive kernel configurations, blacklists unnecessary kernel modules, and packages security-hardened browsers (like Trivalent, featuring Vanadium patches). This is the best choice if you want pre-applied hardening out-of-the-box.\n5. Qubes OS (Advanced) Qubes OS achieves security through virtualization-based compartmentalization using the Xen hypervisor. Instead of securing a single operating system, Qubes isolates activities (e.g., banking, work, untrusted downloads) into separate virtual machines (\u0026ldquo;qubes\u0026rdquo;). If an application in a specific qube is compromised, the malware cannot access other qubes or the host system.\n6. Whonix Whonix is a specialized distribution focused on anonymity. It consists of two virtual machines: a Gateway that routes all traffic through Tor, and an isolated Workstation. Even if a local exploit compromises the Workstation, the malware cannot leak your public IP address because the Workstation has no direct access to the host network interface.\nDistributions to Avoid Pentesting OS (Kali, Parrot, BlackArch): These are offensive security distributions designed to run tools as root from a live environment. They are not hardened for daily desktop use. Libre Kernels (Guix, Parabola): Removing proprietary microcode updates prevents your CPU from receiving hardware-level security mitigations (such as patches for Spectre or Meltdown), leaving your physical hardware vulnerable. Manjaro: Artificially holds back packages compared to Arch Linux, creating unnecessary windows of vulnerability for disclosed exploits. Secure Installation with Disk Encryption Several critical security configurations must be applied during the initial installation process.\n1. Full Disk Encryption (LUKS) Always encrypt your disk using LUKS (Linux Unified Key Setup) during installation. If your laptop is lost or stolen, your data remains unreadable without your decryption passphrase.\nSelect the encryption option in your installer\u0026rsquo;s partitioning manager. Configure a long, cryptographically strong passphrase. If partitioning manually via the CLI, use the --integrity flag with cryptsetup to enable authenticated encryption, protecting against physical sector tampering. 2. Swap Space Security Swap space can leak sensitive memory contents (including plaintext credentials and decryption keys) to your physical disk.\nEnsure swap partitions are encrypted under the same LUKS volume. Alternatively, disable disk swap entirely and use ZRAM (compressed swap inside RAM), which is the default on Fedora. 3. Restrictive Partition Mount Options If configuring custom partition mounts, apply security flags in /etc/fstab to limit execution privileges:\nPartition Mount Flags Objective /boot nodev,noexec,nosuid Prevents binary execution on the boot volume. /boot/efi nodev,noexec,nosuid Prevents execution on the EFI partition. /var nodev,nosuid Limits device creation and SUID execution on variable data. [!WARNING] Do not apply noexec to /home or /root, as this will break Flatpak runtimes, local compilers, and virtual environments.\n4. Generic Hostname and Usernames Your username and hostname are transmitted in network requests and logs, which can be used to track you across networks.\nSet a generic username (e.g., user). Set your hostname to localhost using: sudo hostnamectl hostname \u0026#34;localhost\u0026#34; Post-Installation Hardening: Firmware \u0026amp; Updates Update Firmware \u0026amp; Microcode Ensure your CPU microcode is up-to-date to patch processor-level hardware vulnerabilities.\n# Verify microcode on Fedora dnf list installed | grep microcode # Install microcode on Debian sudo apt install intel-microcode # Intel CPUs sudo apt install amd64-microcode # AMD CPUs # Install microcode on Arch sudo pacman -S intel-ucode # Intel CPUs sudo pacman -S amd-ucode # AMD CPUs Update system peripheral firmware (e.g., UEFI, SSD, controllers) using fwupd:\nsudo fwupdmgr refresh sudo fwupdmgr update Telemetry Deprecation Disable analytics and tracking identifiers implemented by your distribution:\n# Disable DNF install counting on Fedora echo \u0026#34;countme=false\u0026#34; | sudo tee -a /etc/dnf/dnf.conf # Reset unique client ID on openSUSE sudo truncate -s 0 /var/lib/zypp/AnonymousUniqueId Restrictive Global Permissions (Umask) Set a default umask of 077 so that files created by your user are not readable by other local accounts:\n# Append to /etc/profile or /etc/bash.bashrc umask 077 Network Hardening 1. MAC Address Randomization Prevent physical tracking across Wi-Fi networks by randomizing your MAC address. Create /etc/NetworkManager/conf.d/00-macrandomize.conf:\n[device] wifi.scan-rand-mac-address=yes [connection] wifi.cloned-mac-address=random ethernet.cloned-mac-address=random Restart NetworkManager to apply:\nsudo systemctl restart NetworkManager 2. Restrictive Firewall Configure your firewall to drop all incoming connections by default.\nUsing firewalld (Fedora/openSUSE): # Route incoming traffic to drop zone sudo firewall-cmd --set-default-zone=drop # Permit essential IPv6 handshake protocols sudo firewall-cmd --add-protocol=ipv6-icmp --permanent sudo firewall-cmd --add-service=dhcpv6-client --permanent sudo firewall-cmd --reload # Enable lockdown to block unauthorized polkit updates sudo firewall-cmd --lockdown-on Using ufw (Debian/Ubuntu): sudo apt install ufw sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw enable 3. DNSSEC and DNS-over-TLS (DoT) Secure your DNS queries against spoofing and interception. If using systemd-resolved, configure /etc/systemd/resolved.conf:\n[Resolve] DNS=1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net DNSSEC=yes DNSOverTLS=yes Restart systemd-resolved:\nsudo systemctl restart systemd-resolved 4. Network Time Security (NTS) Standard NTP queries are unauthenticated, allowing attackers to perform time-spoofing attacks to invalidate TLS certificates. Secure your synchronization using Chrony with NTS enabled.\nEdit /etc/chrony.conf:\nserver time.cloudflare.com iburst nts server ntppool1.time.nl iburst nts server nts.netnod.se iburst nts server ptbtime1.ptb.de iburst nts minsources 2 Enable the seccomp system call filter for the Chrony daemon:\n# Add to /etc/sysconfig/chronyd (Fedora/Arch) OPTIONS=\u0026#34;-F 1\u0026#34; Restart chronyd:\nsudo systemctl restart chronyd Kernel Hardening 1. Runtime sysctl Hardening Configure /etc/sysctl.d/99-hardening.conf to restrict system calls, protect memory, and mitigate network attacks:\n# Network Security net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv6.conf.all.accept_redirects = 0 net.ipv6.conf.default.accept_redirects = 0 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.default.accept_source_route = 0 net.ipv6.conf.all.accept_source_route = 0 net.ipv6.conf.default.accept_source_route = 0 net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.icmp_echo_ignore_all = 1 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_timestamps = 0 # Kernel Protections kernel.sysrq = 0 kernel.core_uses_pid = 1 kernel.kptr_restrict = 2 kernel.dmesg_restrict = 1 kernel.perf_event_paranoid = 3 kernel.yama.ptrace_scope = 2 kernel.unprivileged_bpf_disabled = 1 net.core.bpf_jit_harden = 2 # Memory \u0026amp; ASLR Enhancements vm.mmap_rnd_bits = 32 vm.mmap_rnd_compat_bits = 16 vm.swappiness = 1 kernel.randomize_va_space = 2 Apply the configurations:\nsudo sysctl --system 2. Kernel Boot Parameters Add these flags to your bootloader configuration (e.g., /etc/default/grub under GRUB_CMDLINE_LINUX or via rpm-ostree kargs):\nCPU Mitigations: mitigations=auto,nosmt spectre_v2=on spectre_bhi=on spec_store_bypass_disable=on tsx=off kvm.nx_huge_pages=force nosmt=force l1d_flush=on spec_rstack_overflow=safe-ret gather_data_sampling=force reg_file_data_sampling=on Note: Disabling Simultaneous Multi-Threading (nosmt=force) provides protection against side-channel exploits but reduces CPU performance on multi-core workloads.\nMemory Protection Parameters: slab_nomerge init_on_alloc=1 init_on_free=1 pti=on vsyscall=none page_alloc.shuffle=1 randomize_kstack_offset=on debugfs=off oops=panic quiet loglevel=0 init_on_alloc=1 / init_on_free=1: Overwrites allocated and freed memory pages with zeroes, preventing data reuse leaks. slab_nomerge: Blocks slab cache merging, reducing the exploitability of heap vulnerabilities. Direct Memory Access (DMA) Mitigations: intel_iommu=on amd_iommu=force_isolation efi=disable_early_pci_dma iommu=force iommu.passthrough=0 iommu.strict=1 Protects against physical DMA attacks via external ports (like Thunderbolt).\nUpdate your bootloader config:\n# Update GRUB configuration sudo grub2-mkconfig -o /boot/grub2/grub.cfg # Or if using Fedora Atomic rpm-ostree kargs --append=\u0026#34;slab_nomerge\u0026#34; --append=\u0026#34;init_on_alloc=1\u0026#34; --append=\u0026#34;init_on_free=1\u0026#34; --append=\u0026#34;pti=on\u0026#34; 3. Kernel Module Blacklist Prevent the loading of unused legacy filesystems and network protocols to reduce kernel attack surface. Create /etc/modprobe.d/blacklist.conf:\n# Unused Filesystems install cramfs /bin/false install freevxfs /bin/false install hfs /bin/false install hfsplus /bin/false install jffs2 /bin/false install udf /bin/false # Unused Protocols install dccp /bin/false install sctp /bin/false install rds /bin/false install tipc /bin/false # Bluetooth (comment out if required) install bluetooth /bin/false install btusb /bin/false # Hardware Sensors \u0026amp; Accessories install thunderbolt /bin/false install uvcvideo /bin/false 4. Hardened Memory Allocator Replace the standard glibc memory allocator with GrapheneOS\u0026rsquo;s hardened_malloc to mitigate memory-corruption vulnerabilities.\n# Install on Fedora sudo dnf copr enable secureblue/hardened_malloc sudo dnf install hardened_malloc # Install on Arch yay -S hardened_malloc-git Enable it globally by appending it to /etc/ld.so.preload:\n/usr/lib64/libhardened_malloc.so Application Sandboxing Flatpak Permission Hardening Flatpak runs applications inside sandbox namespaces. However, many desktop packages request permissive defaults. Use flatpak override to strip dangerous defaults globally:\n# Harden system installations sudo flatpak override --system \\ --nosocket=x11 --nosocket=fallback-x11 \\ --nosocket=pulseaudio --nosocket=session-bus \\ --nosocket=system-bus --unshare=network \\ --unshare=ipc --nofilesystem=host:reset \\ --nodevice=input --nodevice=shm --nodevice=all \\ --no-talk-name=org.freedesktop.Flatpak \\ --no-talk-name=org.freedesktop.systemd1 \\ --no-talk-name=ca.desrt.dconf \\ --no-talk-name=org.gnome.Shell.Extensions # Harden user space overrides flatpak override --user \\ --nosocket=x11 --nosocket=fallback-x11 \\ --nosocket=pulseaudio --nosocket=session-bus \\ --nosocket=system-bus --unshare=network \\ --unshare=ipc --nofilesystem=host:reset \\ --nodevice=input --nodevice=shm --nodevice=all \\ --no-talk-name=org.freedesktop.Flatpak \\ --no-talk-name=org.freedesktop.systemd1 \\ --no-talk-name=ca.desrt.dconf \\ --no-talk-name=org.gnome.Shell.Extensions Manage Sandbox Overrides Visually (Flatseal) Install Flatseal to configure individual overrides via a graphical interface:\nflatpak install flathub com.github.tchx84.Flatseal Dangerous Flatpak Permissions to Revoke: --socket=session-bus / --socket=system-bus: Allows D-Bus communication, which can be exploited to escape the sandbox. --filesystem=host: Grants full read/write access to the host file system. --device=all: Grants raw hardware access, including camera and microphone. Firejail Sandbox (Fallback) For traditional applications that are not containerized via Flatpak, use Firejail to restrict their runtime access:\nsudo dnf install firejail # Fedora sudo apt install firejail # Debian sudo pacman -S firejail # Arch # Enable globally for supported CLI/GUI tools sudo firecfg Secure Boot \u0026amp; Physical Protection Custom Secure Boot Signing (sbctl) Instead of relying on Microsoft\u0026rsquo;s third-party keys, generate and enroll your own Secure Boot keys to sign your kernel and bootloader.\nOn Arch Linux:\nEnter your BIOS/UEFI configuration page and toggle Secure Boot to Setup Mode (this clears Microsoft keys). Boot into Linux and generate your signature databases: sudo pacman -S sbctl sudo sbctl create-keys sudo sbctl enroll-keys Sign your boot files: sudo sbctl sign -s /boot/vmlinuz-linux sudo sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI Re-enable Secure Boot in the UEFI settings. The system will now boot only packages signed by your personal keys. BadUSB Protection (USBGuard) Configure USBGuard to prevent unauthorized USB devices (such as malicious keystroke injection tools) from executing code when connected.\nsudo dnf install usbguard # Fedora sudo apt install usbguard # Debian # Generate a policy containing currently connected devices sudo usbguard generate-policy \u0026gt; /etc/usbguard/rules.conf # Start and enable the service sudo systemctl enable --now usbguard Disabling Media Auto-Mount Ensure your desktop environment does not automatically execute files or parse directory contents upon USB connection.\nOn GNOME:\necho \u0026#39;[org/gnome/desktop/media-handling] automount=false automount-open=false\u0026#39; | sudo tee /etc/dconf/db/local.d/automount-disable echo \u0026#39;org/gnome/desktop/media-handling/automount org/gnome/desktop/media-handling/automount-open\u0026#39; | sudo tee /etc/dconf/db/local.d/locks/automount-disable sudo dconf update Access \u0026amp; SSH Hardening SSH Configuration Security If running an SSH daemon, edit /etc/ssh/sshd_config to secure remote entry:\nPermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes MaxAuthTries 3 X11Forwarding no AllowTcpForwarding no AllowAgentForwarding no ClientAliveInterval 300 ClientAliveCountMax 2 AllowUsers your_username Restart the SSH daemon:\nsudo systemctl restart sshd Generate secure, modern keys using Ed25519:\nssh-keygen -t ed25519 -a 100 Hardware Authentication (pam-u2f) Integrate FIDO2 hardware keys into your PAM stack to require physical verification for sudo commands and local logins.\nsudo dnf install pam-u2f # Fedora sudo apt install libpam-u2f # Debian # Bind your physical key mkdir -p ~/.config/Yubico pamu2fcfg \u0026gt; ~/.config/Yubico/u2f_keys Configure PAM files under /etc/pam.d/ (such as system-auth or sudo) to require the pam_u2f.so module for successful authentication.\nDisabling Unnecessary Services Minimize your local listening ports. Review active services:\nsystemctl list-units --type=service --state=running Disable services that are not required for your system:\nsudo systemctl disable --now cups # Printing daemon sudo systemctl disable --now avahi-daemon # Multicast DNS (mDNS) discovery sudo systemctl disable --now sshd # Remote access SSH daemon Verify active listening sockets:\nsudo ss -tulnp Display Server Security: XWayland Isolation While Wayland is secure, legacy applications running via the XWayland compatibility layer are not isolated from one another. A compromised XWayland application can monitor keystrokes or scrape screen buffers from other legacy applications.\nTo audit if XWayland is active:\nxlsclients 2\u0026gt;/dev/null If it returns output, applications are executing inside XWayland.\nFor maximum security on native Wayland desktops, completely disable X11 fallback support in GNOME. Create /etc/systemd/user/org.gnome.Shell@wayland.service.d/override.conf:\n[Service] ExecStart= ExecStart=/usr/bin/gnome-shell --no-x11 For Electron applications (VS Code, Slack, Discord), force native Wayland execution by appending these arguments:\n--ozone-platform=wayland Auditing and System Audits Manual Audits Encryption Verification: sudo cryptsetup status /dev/mapper/volume_name Firewall Verification: sudo firewall-cmd --list-all # firewalld sudo ufw status verbose # ufw Kernel Settings Verification: cat /proc/cmdline sysctl kernel.yama.ptrace_scope # Must return 2 Automated Audits (Lynis) Run a comprehensive security audit using Lynis to inspect configurations, directory permissions, and system services:\nsudo dnf install lynis # Fedora sudo apt install lynis # Debian sudo lynis audit system Review the output warnings and recommendations to further harden your system.\nConclusions Your Linux workstation is now hardened with:\nFull Disk Encryption to secure data at rest. Strict Local Firewall Rules to block inbound connection vectors. Hardened Sysctls and Boot Parameters to mitigate kernel exploits. Granular Flatpak Permissions to run desktop apps securely. Hardware-based U2F Keys to secure logins and sudo access. Audit Logging (auditd) to monitor filesystem tampering. Keep your system updated, monitor logs, and regularly audit application permissions to maintain your security posture. 🛡️\nRelated Guides Self-Hosted VPN: WireGuard + Pi-hole + Unbound — Secure your internet connection on public networks. How to Build a Threat Model — Identify assets and potential vulnerabilities. macOS Security Guide — Hardening steps for macOS development. GrapheneOS: The Definitive Guide — Secure your mobile operating system. ","permalink":"https://b4.lol/linux-hardening/","summary":"A complete Linux hardening guide: choosing a secure distro, LUKS disk encryption, firewall, kernel hardening, Flatpak sandboxing, and Secure Boot.","title":"Linux Hardening: The Complete Security Guide"},{"content":" TL;DR — In this guide, you will learn:\nHow to configure an Apple Silicon Mac for maximum security and privacy from the first boot. How to secure network traffic using firewalls, encrypted DNS, VPNs, and Tor. How to secure your browser, manage credentials, and encrypt files using FileVault and GPG. How to audit system processes, purge metadata, and protect against tracking and malware. Summary Securing macOS begins with establishing a threat model, followed by configuring FileVault disk encryption, enabling automatic security updates, activating the system firewall, implementing encrypted DNS, utilizing a hardened browser, and enforcing application download restrictions. Advanced mitigations—such as macOS Lockdown Mode or virtual machine compartmentalization—should be deployed selectively depending on your threat level.\nYour Mac is not an impenetrable fortress straight out of the box. macOS is a robust operating system, sure, but without the right configuration it leaves more doors open than you\u0026rsquo;d think\u0026hellip; and every open door is an invitation for anyone who wants to poke their nose into your business.\nThis guide is for you turtles who want to take your Mac\u0026rsquo;s privacy and security seriously. You don\u0026rsquo;t need to be a computer engineer: just a willingness to learn and a bit of patience. We\u0026rsquo;ll go step by step, from choosing your hardware all the way to advanced system monitoring.\nWARNING!! This guide is provided as-is, with no warranty of any kind. You alone are responsible for any changes you make to your system. Proceed with caution and, when in doubt, always make a backup first.\nThreat Modeling: Where to Start The first and most critical step in securing any workstation is establishing a threat model. You must identify what assets you are trying to protect, who you are protecting them from, and what mitigations are necessary. Security is a trade-off with usability; your model should address realistic threats without introducing unnecessary friction.\nIdentify the assets you want to protect List the data and systems you need to protect: your physical device, passwords, browsing history, financial documents, private cryptographic keys, or personal photos. Categorize them as Public, Sensitive, or Secret.\nIdentify your adversaries Define who wants your data: a curious family member, a physical opportunistic thief, advertising networks, corporate data brokers, or targeted state actors.\nIdentify their capabilities Assess what your adversaries can do. An opportunistic thief can be stopped by full-disk encryption and a strong login password. A state actor or APT might employ firmware-level exploits or cold-boot attacks, requiring you to fully power down the device when not in use to clear decryption keys from RAM.\nDetermine mitigations Decide on proportional countermeasures:\nTarget Asset Adversary Capability Countermeasure / Mitigation Communications \u0026amp; History Local Observers Physical access to unlocked device Autolock, biometric authentication, privacy screen filters Local Files \u0026amp; Accounts Physical Thieves Drive extraction, shoulder-surfing FileVault 2, strong alphanumeric passwords, Find My Mac System Integrity Remote Cybercriminals Social engineering, malware, credential stuffing Application sandboxing, auto-updates, hardware security keys, password manager Browsing Privacy Advertisers / Data Brokers Tracker injection, browser fingerprinting Hardened browsers, DNS filtering, local firewalls High-Value Secrets Targeted State Actors (APTs) Zero-day exploits, hardware tampering End-to-end encrypted FOSS, hardware security tokens, air-gapped backups Hardware: Selecting a Secure Platform For the highest security baseline, run macOS exclusively on Apple Silicon hardware (M1/M2/M3/M4 and later). Intel-based Macs contain hardware vulnerabilities (such as bootrom exploits on T2 security chips) that cannot be fully resolved via software patches.\nAvoid \u0026ldquo;Hackintosh\u0026rdquo; custom builds or legacy Macs that do not support the latest macOS releases, as Apple backports security patches selectively to older versions.\nDepending on your threat model, purchase hardware in-person using cash to prevent linking your physical machine identifier to your personal financial records.\nFor peripherals (keyboards, mice, headphones), use Apple\u0026rsquo;s native accessories. They receive firmware updates directly through the OS and support BLE (Bluetooth Low Energy) Privacy, which randomizes the Bluetooth hardware address to prevent location tracking.\nInstalling and Activating macOS Always install the latest major release of macOS.\nSystem Activation Apple Silicon Macs must activate with Apple\u0026rsquo;s servers during the initial setup phase. This verification step confirms the device is not flagged as stolen or locked via iCloud.\nApple Account (Apple ID) An Apple Account is not required to use macOS. If you register one, be aware that the system syncs local data to iCloud by default. If you require iCloud features, enable Advanced Data Protection to enforce end-to-end encryption for synced files, backups, and photos.\nVirtualization Compartmentalization On Apple Silicon, virtualization runs with high performance using Apple\u0026rsquo;s native Virtualization framework. Use these tools to isolate untrusted software:\nUTM: A free, open-source frontend for QEMU supporting macOS and Windows on ARM. VirtualBuddy: An open-source wizard designed specifically for running macOS VMs on Apple Silicon. VMware Fusion: Free for personal use, providing high-performance virtualization. Tart: A command-line utility for managing macOS and Linux VMs, installable via Homebrew. Use a local virtual machine to test scripts and run untrusted binaries without exposing your host system.\nFirst Boot and Account Setup During the initial boot setup, create your primary user account with a strong passphrase. Leave the password hint field empty, as this hint is visible to anyone at the lock screen.\nBy default, the installer uses your real name to define your network hostname. Clean your local network footprint using the Terminal:\nsudo scutil --set ComputerName \u0026#34;localhost\u0026#34; sudo scutil --set LocalHostName \u0026#34;localhost\u0026#34; Enforcing a Standard User Account The default account created during installation is an Administrator account with root execution privileges via sudo. Running daily tasks as an administrator increases your vulnerability to malware.\nConfigure a Standard User account for daily work:\nNavigate to System Settings → Users \u0026amp; Groups. Create a secondary Administrator account with a secure passphrase. Log out, then log into the new Administrator account. Demote your original daily account to a Standard User by running: sudo dscl . -delete /Groups/admin GroupMembership your_username Log back into your daily Standard User account. When system modifications require administrative rights, macOS will prompt you to enter the credentials of your secondary Administrator account.\nBoot Security and FileVault Secure Boot Baseline Verify that your system\u0026rsquo;s boot security is configured to Full Security in macOS Recovery. This validates the cryptographic signatures of the bootloader, kernel, and firmware before boot.\nFileVault 2 (Full-Disk Encryption) While Apple Silicon devices encrypt data at rest natively, FileVault requires your user password to load the decryption key on boot (Before First Unlock). Enabling FileVault also locks down the boot firmware, preventing unauthorized users from booting from external media or accessing macOS Recovery.\nTo enable FileVault: Go to System Settings → Privacy \u0026amp; Security → FileVault and select Turn On.\n[!WARNING] Store your FileVault recovery key securely in physical print or in an offline database. Do not store the recovery key in your iCloud account, as compromising your iCloud account would expose your disk decryption keys.\nmacOS Lockdown Mode Lockdown Mode is an extreme security configuration that reduces the macOS attack surface by disabling common execution vectors. It disables complex web technologies (such as JIT compilation in browsers), blocks incoming connection requests (like FaceTime calls from unknown accounts), and restricts access to local physical ports when the device is locked.\nTo activate: Go to System Settings → Privacy \u0026amp; Security → Lockdown Mode and select Turn On.\nFirewall Hardening Application-Level Firewall Configure the native macOS Application Firewall to block incoming network requests:\n# Enable the application firewall sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate on # Enable Stealth Mode to ignore ICMP pings and scan probes sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setstealthmode on # Revoke automatic rules for signed applications sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setallowsigned off sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setallowsignedapp off Outbound Connection Firewalls The native firewall only monitors inbound connections. To control outbound traffic and prevent apps from transmitting telemetry, install an outbound firewall helper:\nLuLu: A free, open-source outbound firewall developed by Objective-See. Little Snitch: A highly granular, commercial outbound monitoring application. Outbound firewalls alert you whenever an application attempts to establish a connection, allowing you to create rules to block telemetry or unauthorized updates.\nPacket Filter (pf) Configuration For kernel-level packet filtering, use the native Unix pf tool. Create a basic rule set in /etc/pf.conf (or custom rule path /etc/pf.rules):\n# Define interface wifi = \u0026#34;en0\u0026#34; # Default drop rules block in all block out all # Allow essential loopback pass quick on lo0 # Allow outbound DNS and HTTPS over Wi-Fi pass out quick on $wifi proto udp to any port 53 pass out quick on $wifi proto tcp to any port { 80, 443 } Load the rule set:\nsudo pfctl -e -f /etc/pf.rules Check active rules:\nsudo pfctl -s info Services, Daemons, and Package Management Managing Launch Daemons macOS manages background tasks using launchd. You can inspect active system services:\n# List all running launchd tasks launchctl list Background service configurations are located in the following directories:\n/System/Library/LaunchDaemons/: Native OS services. /System/Library/LaunchAgents/: Native OS user-space helpers. /Library/LaunchDaemons/: Global third-party services. ~/Library/LaunchAgents/: User-specific third-party helpers. Note: Do not disable System Integrity Protection (SIP) to modify system-level plists; keep your customizations restricted to user-level directories.\nPackage Manager Security (Homebrew) Homebrew requires administrative permissions to manage libraries under /opt/homebrew (on Apple Silicon).\nAlways opt out of Homebrew\u0026rsquo;s telemetry analytics. Add this environment variable to your shell configuration (~/.zshrc):\nexport HOMEBREW_NO_ANALYTICS=1 Securing DNS Resolution Unencrypted DNS queries expose your browsing activity to local network monitors and ISPs. Secure your resolution path:\nEncrypted DNS Configuration Profiles macOS natively supports DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) via system-level configuration profiles. You can generate or download profiles from secure providers:\nQuad9: Non-profit resolver that blocks malicious domains. NextDNS: Allows custom blocklists, tracker blocking, and parental controls. Local Hosts Blocklist You can block tracking domains locally by modifying /etc/hosts:\n# Redirect tracking domains to null interface echo \u0026#34;0.0.0.0 telemetry-server.com\u0026#34; | sudo tee -a /etc/hosts # Flush the local DNS cache to apply changes sudo dscacheutil -flushcache Use community-maintained blocklists (like StevenBlack/hosts ) to automate domain blocking.\nDNSCrypt and Local Caching To encrypt DNS traffic and verify signatures using DNSSEC, run a local proxy:\n# Install DNSCrypt Proxy brew install dnscrypt-proxy Pair it with dnsmasq to cache records locally and point your system DNS server to localhost (127.0.0.1).\nCertificate Trust and Browser Hardening Certificate Authorities (CAs) macOS ships with a pre-installed trust store containing over 100 root certificates. If a certificate authority is compromised or coerced, it can issue fraudulent certificates to perform Man-in-the-Middle (MitM) attacks.\nTo audit or revoke trust from a CA:\nOpen the Keychain Access utility. Locate the CA under the System Roots tab. Double-click the certificate, expand Trust, and change the setting to Never Trust. Selecting and Hardening Your Browser Your web browser is the largest attack surface on your workstation.\n1. Firefox (Recommended for Privacy) Firefox is open source and features advanced privacy controls.\nHardening: Implement the arkenfox/user.js profile to enforce strict anti-fingerprinting configurations. Extensions: Install uBlock Origin (to block scripts and trackers) and NoScript (to selectively manage JavaScript execution). 2. Safari (Recommended for System Integration) Safari features strong sandboxing and native hardware integration.\nSupports Lockdown Mode, which disables complex web engines (like compiler optimization) to block exploitation. Includes Intelligent Tracking Prevention to scramble fingerprinting attempts. 3. Chromium / Google Chrome While Chrome features robust sandboxing, it is built to collect telemetry. If you must use Chrome:\nDisable experimental JavaScript APIs: Set #disable-javascript-harmony-shipping to active under chrome://flags. Install uBlock Origin Lite to block tracking within the boundaries of Manifest V3. Anonymity and Transit Security (Tor \u0026amp; VPN) Tor Browser Tor Browser routes your traffic through three encrypted hops in the Tor network, preventing sites from identifying your IP address.\nInstallation Verification Always verify the cryptographic signature of the downloaded DMG archive using GPG:\n# Import the Tor Project developer key (check official Tor site for active fingerprint) gpg --keyserver hkps://keys.openpgp.org --recv-keys \u0026lt;TOR_SIGNING_KEY\u0026gt; # Verify DMG integrity gpg --verify TorBrowser-*.asc TorBrowser-*.dmg Verify macOS notarization and code signature:\ncodesign -dvv /Applications/Tor\\ Browser.app [!IMPORTANT] Tor provides Anonymity (hiding your identity), not Privacy (securing what you do). If you log into your personal accounts while using Tor, your identity is exposed to that service.\nVPN Services Using a VPN routes your network traffic through an encrypted tunnel to a provider\u0026rsquo;s server.\nAvoid legacy, insecure protocols like PPTP. Use modern protocols like WireGuard or OpenVPN. Kill Switch: Ensure your VPN client blocks network connections if the tunnel drops to prevent data leaks. To force all outbound traffic through your VPN interface (utun0) at the firewall level, define these rules in /etc/pf.conf:\nblock all pass on lo0 pass out on utun0 all pass out on en0 proto udp to \u0026lt;VPN_SERVER_IP\u0026gt; port \u0026lt;VPN_PORT\u0026gt; Cryptographic Tools and File Security PGP/GPG File Encryption Use GNU Privacy Guard (GPG) to encrypt files and communications locally:\n# Install GPG suite brew install gnupg # Generate a strong key pair (Ed25519) gpg --full-generate-key # Export public key gpg --armor --export your_email@example.com Note: For high-security environments, store your private key on a hardware token like a YubiKey, ensuring the key material cannot be extracted by local malware.\nSecure Messaging Clients Signal: The recommended end-to-end encrypted messaging client. It utilizes the Double Ratchet cryptographic protocol for forward secrecy. iMessage: If using iMessage, go to your Apple Account settings and enable Contact Key Verification to authenticate recipient keys. Enable Advanced Data Protection to ensure your messaging database is encrypted using keys that Apple does not hold. Malware Protections macOS contains built-in defenses against malware, but they must be configured correctly.\nApp Sandboxing \u0026amp; Notarization Ensure that user-installed applications run inside a sandbox, limiting their access to core OS folders. Verify application sandboxing entitlements using codesign:\ncodesign --entitlements - /Applications/AppName.app Verify if the application implements Apple\u0026rsquo;s Hardened Runtime (required for notarization):\ncodesign --display --verbose /Applications/AppName.app Look for runtime flags in the output.\nLocal Detection (Objective-See Utilities) Rather than resource-intensive commercial antivirus software (which frequently transmits telemetry), use free, open-source security helpers:\nBlockBlock: Alerts you if a program attempts to install a persistent startup daemon. LuLu: Monitors outbound connections. KnockKnock: Scans your system for existing persistence components. System Integrity Protection (SIP) SIP blocks modifications to system binaries and directories, preventing malware from compromising root folders. Ensure SIP is active:\ncsrutil status Never disable SIP in production environments.\nPurging Metadata and Digital Traces 1. File Quarantine Extended Attributes macOS tags downloaded files with extended attributes detailing download origins. Strip these attributes using xattr:\n# View metadata tags xattr -l ~/Downloads/file.zip # Delete quarantine and provenance attributes xattr -d com.apple.metadata:kMDItemWhereFroms ~/Downloads/file.zip xattr -d com.apple.quarantine ~/Downloads/file.zip 2. Clear QuickLook Previews QuickLook caches document and image previews locally. Purge this cache regularly:\nqlmanage -r cache 3. Disable Typing Telemetry macOS records typing profiles, spelling corrections, and keyboard predictions. Clear these folders and restrict access:\nrm -rf ~/Library/LanguageModeling ~/Library/Spelling ~/Library/Suggestions mkdir ~/Library/LanguageModeling ~/Library/Spelling ~/Library/Suggestions chmod -R 000 ~/Library/LanguageModeling ~/Library/Spelling ~/Library/Suggestions 4. Saved Application States Disable the caching of window locations and document state:\nrm -rf ~/Library/Saved\\ Application\\ State/* chmod -R 000 ~/Library/Saved\\ Application\\ State Passwords and Multi-Factor Authentication Password Managers: Use the native macOS Passwords app (which supports Passkeys) or a cross-platform manager (like Bitwarden) with database files encrypted locally. Hardware Authentication: Secure your primary accounts using FIDO2 WebAuthn keys (such as YubiKeys). Avoid insecure SMS or email-based 2FA. Backup Strategy and Local Networking 1. Encrypted Backups (Time Machine) Ensure backups are encrypted before writing to external storage: Go to System Settings → General → Time Machine → Add Backup Disk and select Encrypt Backup.\n2. Manual Archive Encryption If writing backups manually, encrypt directories using GPG:\n# Create encrypted archive tar czf - ~/Documents | gpg --encrypt --recipient your_email@example.com \u0026gt; backup.tar.gz.gpg # Decrypt archive gpg --decrypt backup.tar.gz.gpg | tar xzf - 3. Local Wi-Fi Configuration Avoid Hidden Networks: Hidden networks force your Mac to constantly broadcast probes searching for the network SSID, exposing your network history. Private Wi-Fi Address: Enable private MAC address generation for each network under Wi-Fi Settings → Network Details → Private Wi-Fi Address. 4. Hardening Outbound SSH Connections In your ~/.ssh/config file, hash hostnames and restrict identification keys:\nHost * HashKnownHosts yes IdentitiesOnly yes Physical Security Mitigations USB Intrusion Protection: Never leave your Mac unlocked in public. Use utilities like BusKill to trigger a system shutdown or lock if your physical USB connection is severed. Privacy Screen Filters: Use physical polarization filters to prevent shoulder-surfing in public environments. Tamper-Evident Seals: Apply custom seals or specialized nail polish over the chassis screws to detect physical access attempts. System Monitoring Audit system resource usage and open ports periodically:\n# List active network connections lsof -Pni # List listening TCP/UDP sockets netstat -atln Monitor process execution using the native Activity Monitor or SQL-based endpoint monitoring tools like osquery.\nPost-Installation Hardening Tweaks Run these commands in Terminal to restrict diagnostics, enforce screensaver locks, and configure system preferences:\n# Disable diagnostic report submission to Apple sudo defaults write /Library/Application\\ Support/CrashReporter/DiagnosticMessagesHistory.plist AutoSubmit -bool false # Enforce immediate password lock on screensaver activation defaults write com.apple.screensaver askForPassword -int 1 defaults write com.apple.screensaver askForPasswordDelay -int 0 # Show hidden files in Finder defaults write com.apple.finder AppleShowAllFiles -bool true # Display all file extensions in Finder defaults write NSGlobalDomain AppleShowAllExtensions -bool true # Disable default saving to iCloud drive defaults write NSGlobalDomain NSDocumentSaveNewDocumentsToCloud -bool false # Enable Secure Keyboard Entry in Terminal to prevent keystroke sniffing defaults write com.apple.terminal SecureKeyboardEntry -bool true # Disable the visual crash reporter dialog defaults write com.apple.CrashReporter DialogType -string \u0026#34;none\u0026#34; # Disable Bonjour multicast advertisements sudo defaults write /Library/Preferences/com.apple.mDNSResponder.plist NoMulticastAdvertisements -bool true # Restrict default launchd user umask permissions to 077 sudo launchctl config user umask 077 Recommended Security Software osquery : Open-source utility that exposes system metrics as SQL tables. Pareto Security : A lightweight menu bar application that audits macOS configuration settings. LuLu : Free open-source outbound firewall. You have successfully hardened your macOS workstation. Maintain operational vigilance: update software regularly, verify permissions, and monitor outbound connection requests. 🛡️\nRelated Guides How to Build a Threat Model — Define your assets and adversarial boundaries. Self-Hosted VPN with Ad Blocking — Secure your traffic using WireGuard and Pi-hole. Email Security Guide — Configure secure email authentication. De-Google Android: Complete Privacy Guide — Hardening guidelines for mobile devices. ","permalink":"https://b4.lol/macos-security/","summary":"A detailed guide to locking down your Mac: from initial setup to firewall, DNS, browser, Tor, VPN, encryption, and system monitoring.","title":"Complete Guide to macOS Security and Privacy"},{"content":" TL;DR — In this guide, you will learn:\nHow email encryption works and why STARTTLS is insufficient. How SPF, DKIM, and DMARC prevent spoofing. Why email is the single point of failure (weakest link) for account security. Future developments: native end-to-end encryption, DKIM2, and the deprecation of plaintext email. Summary Email is not secure by design. It fails to protect metadata, relies on hop-by-hop encryption rather than end-to-end security, and acts as the master password-recovery key for almost all online accounts. To mitigate these risks, you should enable hardware-based multi-factor authentication (MFA), choose a secure provider, disable HTML and remote images in your email client, configure offline backup codes for third-party accounts, and secure your email domains using SPF, DKIM, and DMARC.\nEmail is the invisible backbone of your digital life. Every account you create, every password you reset, every important communication\u0026hellip; almost always passes through email. But have you ever wondered how secure it actually is?\nThe answer, unfortunately, is: less than you think. Email is a protocol born in the 1980s, when cybersecurity was not exactly a priority. Layer after layer of protections has been added since then, but the result is a complex, fragmented, and often misconfigured system.\nIn this guide we\u0026rsquo;ll go through the current state of email security together, from encryption to authentication, and take a look at what the future holds. Keep your eyes open, because there are quite a few surprises.\nEmail Encryption How are your emails protected in transit and at rest? The current standards are complex and often fall short of modern security expectations.\nSTARTTLS: The Removable Lock STARTTLS is the most common protocol for securing email in transit. It commands a plaintext SMTP connection to upgrade to a secure TLS tunnel.\nThe vulnerability is that the upgrade negotiation occurs in plaintext. An attacker positioned on your local network or path (MitM) can strip the STARTTLS command from the handshake, forcing the servers to fallback to unencrypted communication. This is known as a downgrade attack, and most clients will fail to warn you.\nFurthermore, even when negotiation succeeds, STARTTLS only secures the connection hop-by-hop (from your client to your provider\u0026rsquo;s server, then from server to server). Because the email is decrypted and re-encrypted at each hop, it is not end-to-end encrypted; any server in the transit path can access its contents.\nSMTPS (Implicit TLS) SMTPS (Implicit TLS) fixes the downgrade vulnerability. Instead of starting in plaintext and upgrading, SMTPS establishes an encrypted TLS session immediately at connection startup, similar to HTTPS.\nBy default, SMTPS operates on port 465, whereas STARTTLS uses port 587. Despite being a superior security standard, legacy configurations and historic confusion over ports have slowed its universal adoption.\nPOP3S and IMAPS The retrieval protocols used to download mail from servers also support transport encryption:\nPOP3S enforces TLS on port 995. IMAPS enforces TLS on port 993. These protocols ensure that your mail client downloads messages over a secure channel, but they do not secure the emails themselves on the servers or in transit across third-party relays.\nOpenPGP: Secure but Complex Pretty Good Privacy (PGP), created in 1991, remains the standard for true end-to-end email encryption. Using asymmetric cryptography, the sender encrypts the message using the recipient\u0026rsquo;s public key, and the recipient decrypts it using their private key. No intermediate relay can read the message body.\nHowever, PGP has major usability and design issues:\nKey Management Complexity: Generating, distributing, and verifying public keys remains difficult for non-technical users. Lack of Forward Secrecy: If your private key is compromised, an adversary who has recorded your network traffic can decrypt all historical messages encrypted with that key. Plaintext Metadata: OpenPGP does not encrypt headers. The sender, recipient, date, and subject line remain visible to network observers. S/MIME: Corporate Verification S/MIME uses X.509 digital certificates (similar to TLS web certificates) to sign and encrypt emails. It is integrated natively into many corporate email clients, making certificate handling automated.\nHowever, S/MIME certificates are expensive, expire annually, and rely on centralized Certificate Authorities (CAs). Like OpenPGP, S/MIME does not support forward secrecy.\nWeb Key Directory (WKD) WKD is a decentralized standard for PGP public key discovery. Instead of searching key servers, your email client queries the recipient\u0026rsquo;s domain directly (e.g., https://example.com/.well-known/openpgpkey/...) to fetch their public key automatically. While convenient, it requires domain-level configuration, and adoption remains low.\nEmail Authentication If encryption secures your content, authentication verifies your identity. How can you verify that an email claiming to be from bank@example.com is legitimate?\nSPF: The Sender Guest List Sender Policy Framework (SPF) is a DNS record where the domain owner lists all IP addresses and servers authorized to send emails on their behalf.\nWhen a server receives an email, it looks up the SPF record of the sender\u0026rsquo;s domain. If the sending IP is not on the list, the email fails authentication.\nLimitations:\nSPF does not verify the individual sender, only the sending server\u0026rsquo;s IP address. It breaks when emails are forwarded, as the forwarding server\u0026rsquo;s IP will not match the original sender\u0026rsquo;s domain SPF record. Domain owners can configure varying enforcement flags: ~all (soft fail, warning only) or -all (hard fail, reject). Many domains use soft fail, reducing the security benefit. DKIM: Cryptographic Signature DomainKeys Identified Mail (DKIM) adds a cryptographic signature to the headers of outgoing emails. The domain owner publishes a public key in their DNS record and signs emails with a private key.\nThe receiving server fetches the public key and verifies the signature. If any part of the email body or headers was altered in transit, the signature validation fails.\nNote: DKIM signatures are applied by your mail provider, not by your client. While it guarantees domain integrity, it does not encrypt your message content.\nDMARC: The Policy Enforcer Domain-based Message Authentication, Reporting, and Conformance (DMARC) coordinates SPF and DKIM. It tells receiving mail servers how to handle emails that fail SPF and DKIM checks.\nDMARC policy options include:\np=none: Monitor and log failed delivery reports only. p=quarantine: Route failed emails to the spam folder. p=reject: Block delivery of failed emails entirely. A secure DMARC configuration looks like this:\nv=DMARC1; p=reject; adkim=s; aspf=s; Here, p=reject blocks unauthenticated mail, and adkim=s / aspf=s enforce strict domain alignment for DKIM and SPF checks.\nDNSSEC: Securing the DNS Chain Because SPF, DKIM, and DMARC query DNS, their security relies on the integrity of DNS records. If an attacker performs a DNS cache poisoning attack, they can spoof the DNS records and bypass authentication.\nDNSSEC (Domain Name System Security Extensions) solves this by digitally signing DNS records. This creates a cryptographic chain of trust up to the root zone managed by IANA, ensuring your DNS queries are tamper-proof.\nDANE and MTA-STS: Enforcing Transit Security These protocols prevent attackers from stripping transport security:\nDANE (DNS-based Authentication of Named Entities): Relies on DNSSEC to bind TLS certificates to mail servers, ensuring clients reject unencrypted or self-signed connections. MTA-STS (Mail Transfer Agent Strict Transport Security): Uses HTTPS and web PKI to declare that a mail server requires TLS. It is simpler to implement than DANE but relies on traditional Certificate Authorities.\u0026quot; Email: The Weakest Link in Account Security Because email is the default fallback for password resets and multi-factor authentication (MFA) recovery, the security of almost all your online accounts depends entirely on the security of your inbox. If an attacker gains access to your email account, they can reset the passwords of your banking, social media, and cloud hosting accounts.\nRecommendations to Secure Your Inbox: Hardware Multi-Factor Authentication (MFA): Enable 2FA on your email account using a FIDO2 hardware key (like a YubiKey) rather than insecure SMS or authenticator apps. Use Backup Codes: For critical accounts, replace email-based recovery options with offline, physical backup codes stored in a secure location. Use Email Solely for Communication: Do not use your primary inbox as a master recovery vault. Client Attack Surfaces Using desktop email clients (e.g., Thunderbird, Apple Mail) increases your local attack surface. Because email clients process HTML, CSS, and occasionally JavaScript, they function like web browsers but without equivalent sandboxing.\nSince anyone can send an email to your address at any time, a vulnerability in your mail client\u0026rsquo;s parsing engine can lead to local code execution.\nBest Practice: Configure your mail client to display emails in plaintext by default and disable the automatic loading of remote images. This prevents tracking pixels and blocks client exploits.\u0026quot;\nThe Future of Email Security Several protocols are in development to address email\u0026rsquo;s historical design flaws:\nOpenPGP Modernization The IETF is developing updates to the OpenPGP standard:\nPost-Quantum Cryptography: Upgrading encryption algorithms to resist future quantum attacks. Forward Secrecy: Implementing ephemeral key exchanges so compromising a master key does not compromise historical traffic. Key Transparency: Using public, append-only logs (similar to WhatsApp\u0026rsquo;s cryptographic verification) to verify public keys automatically without manual key exchanges. S/MIME Updates The LAMPS working group is standardizing hybrid signature systems, combining classical and post-quantum cryptography to ensure long-term message integrity.\nDKIM2: Mitigating Reply Attacks Under the current DKIM standard, a malicious actor can take a signed message and resend it at scale (a reply attack) to damage the sender\u0026rsquo;s reputation. DKIM2 will require every intermediate transit hop to sign the message, making mail routing fully auditable.\nDMARCbis: Eliminating Loopholes DMARCbis clarifies policy ambiguities in the original DMARC specification, addressing subdomain spoofing and improving alignment verification to reduce deliverability bypasses.\nDeprecating Plaintext Transport Major mail providers are moving toward completely deprecating unencrypted email transport. Encrypted TLS transit will eventually become a hard requirement rather than an optional negotiation.\nPasskeys: Decoupling Recovery The adoption of WebAuthn passkeys allows users to register accounts without passwords. This reduces the need for email-based password resets, decoupling account recovery from your inbox.\nSMTP Native End-to-End Encryption Currently, providers like Proton Mail encrypt emails natively only when both the sender and recipient use their service. The long-term goal is integrating native end-to-end encryption directly into the SMTP protocol itself, allowing cross-provider E2EE by default.\nConclusion Securing email requires managing a complex stack of legacy protocols. However, the adoption of modern authentication standards and the transition toward native E2EE are positive developments.\nQuick Action Items: Verify that your email provider enforces SPF, DKIM, and DMARC. Secure your mail account with a hardware FIDO2 key. Configure your client to block remote images and render plaintext. Remove email recovery methods from critical accounts, using offline backup codes instead. Use end-to-end encrypted mail services (like Proton Mail) for sensitive exchanges. You are now equipped with the knowledge to protect your inbox and secure your digital identity. 🐢\nRelated Guides How to Build a Threat Model — Define your assets, threats, and security boundaries. Self-Hosted VPN with Ad Blocking — Build your own VPN with WireGuard and Pi-hole. The Definitive Guide to GrapheneOS — Secure your mobile operating system. ","permalink":"https://b4.lol/email-security/","summary":"Discover how email security really works: from STARTTLS to PGP, from SPF and DKIM to DMARC. A complete guide with practical tips to protect your email.","title":"Email Security: Encryption, SPF, DKIM and DMARC"},{"content":" TL;DR — In this guide, you will learn:\nHow to correctly define a threat (moving beyond the vague \u0026quot;Big Tech\u0026quot; label). The four primary threat vectors: service providers, mass surveillance, application developers, and malicious actors. How to build defenses using end-to-end encryption, identity separation, and compartmentalization. Common pitfalls and bad practices to avoid when constructing your threat model. Summary A threat model is a structured methodology to identify what assets you need to protect, who your adversaries are, what their capabilities are, and what realistic mitigations you can deploy. Without a threat model, you risk purchasing unnecessary tools, neglecting actual threats, and making your digital life inconvenient without increasing your security.\nInstalling a VPN or switching to an encrypted messaging client is ineffective if you do not understand your threat vector. Many beginners spend time and money on security software without a clear plan, leaving them vulnerable to standard exploits. Developing a threat model is the essential first step: it clarifies your actual vulnerabilities and guides you toward the correct solutions.\nThe first step anyone should take to protect their privacy and security is to create a Threat model.\nDefining a Threat To construct a threat model, you must first define what a threat actually is. A common mistake for beginners is to define the adversary simply as \u0026quot;Big Tech.\u0026quot; This approach has a fundamental flaw:\nWhy should we distrust a large technology company only to shift our absolute trust toward a smaller startup? What happens if that smaller provider is compromised, sold to a data broker, or scales up and changes its data collection policies?\nDistrusting specific brands is ineffective. The correct approach is to define the threat as the \u0026quot;Service Provider\u0026quot; as a general category.\nThere are four primary threat vectors that most users should consider:\nService Providers: Providers monitoring, analyzing, or storing user communications and data on their servers. Mass Surveillance: Advertising networks and data brokers tracking user activity across multiple websites and platforms. Invasive Application Developers: Software developers harvesting device data or injecting tracker libraries into local applications. Malicious Actors (Hackers): Attackers seeking unauthorized access to your physical devices or online accounts. Most users will address several of these threats simultaneously, prioritizing them based on their personal context. For example, a software engineer might focus on preventing unauthorized device access (protecting code signing keys and system credentials), while a standard user might prioritize blocking mass tracking and commercial profiling.\nFor whistleblowers, journalists, or activists, the requirements are more severe: they require true anonymity (hiding their identity) in addition to confidentiality (hiding their data), which demands a much more rigorous operational security posture.\nMitigating Service Provider Exposure Most communication platforms store messages, emails, and attachments on centralized databases. A service provider (or an attacker who compromises their servers) can access this unencrypted data at will. This is the default status for SMS, standard email, Telegram channels, and Discord servers.\nThe Role of End-to-End Encryption (E2EE) End-to-end encryption secures communications locally on your device before transmission. The service provider acts merely as a blind transit relay; they cannot decrypt the content because they do not hold your private keys.\nHowever, the implementation details of E2EE matter:\nNative Applications: Clients like Signal compile code that runs locally on your device. This code can be audited and reverse-engineered to verify that key management is secure. Web Applications: Web-based E2EE tools (such as webmail interfaces or browser vaults) receive their cryptographic code dynamically from the provider\u0026rsquo;s server during every session. A compromised server can push malicious JavaScript to a targeted user to extract their local decryption keys, making web-based E2EE harder to audit. Best Practice: For sensitive communications and password management, prefer native, audited applications over web-based browser clients.\nMetadata Exposure While E2EE protects the body of your messages, it rarely conceals metadata. Service providers can still record:\nWhom you communicate with. The timestamp and frequency of your connections. Your IP address and device fingerprint. If metadata leakage is a concern under your threat model, look for platforms that implement metadata minimization or route traffic through decentralized networks (such as SimpleX or onion routing).\nDefending Against Mass Tracking Advertising networks correlate your activities across the web using several persistent tracking signals:\nYour public IP address. Persistent browser cookies and local storage tokens. Unique browser canvas and hardware fingerprints. Consistent telemetry shared during account creation. Credit card transactions and payment records. To prevent tracking networks from aggregating your data:\nCompartmentalize Identities: Use distinct, separated browser profiles or virtual machines for different tasks (e.g., separate personal browsing from online shopping). Blend in with the Crowd: Avoid custom browser extensions or configurations that make your device signature unique. Enforce anti-fingerprinting configurations (like Firefox\u0026rsquo;s arkenfox setup or Tor). Minimize Information Disclosure: Obfuscate personal data using temporary email aliases (e.g., SimpleLogin) and virtual credit cards. Encrypt Files Locally: Use tools like Cryptomator to encrypt files locally before uploading them to commercial cloud providers (like Google Drive or OneDrive). Secure Your Network Footprint: Route traffic through a trusted VPN or the Tor network to hide your public IP address. [!IMPORTANT] A privacy policy is merely a legal promise, not a technical control. It should be treated as your last line of defense. Focus your efforts on deploying technical controls (like encryption and tracker blocking) rather than trusting corporate policies.\nLimiting Public Information The most effective way to protect your data is to never disclose it.\nAudit Privacy Settings: Go through your social media and email accounts and set permissions to the most restrictive options (e.g., hide profiles from search indexers). Opt-Out from Data Brokers: Submit removal requests to data brokers and public record indexers to remove your phone numbers, physical addresses, and email associations from search results. Obfuscate Real Data: If a platform requires information but does not verify it (such as a username or date of birth), use fake identifiers or randomized details to pollute their databases. Security Against Malware and Device Compromise Privacy is impossible without security. If an attacker compromises your device at the operating system level, they can bypass E2EE and capture your keystrokes.\nBecause you cannot guarantee that any third-party application is entirely secure or free of vulnerabilities, implement security through compartmentalization:\nDedicated Hardware: Use separate physical devices for work and personal activities. Virtualization: Run untrusted software inside disposable virtual machines. Hardened Operating Systems: Run platforms that enforce strict sandboxing at the OS level (like Qubes OS for desktops or GrapheneOS for mobile devices). Sandbox Models across Platforms Mobile OS (iOS, Android): Enforce a strong sandboxing model by default. Applications run as unprivileged users and cannot access other apps\u0026rsquo; data directories without permission. Desktop OS (macOS, Windows 11): macOS provides robust application controls, runtime notarization, and opt-in sandboxing. Windows 11 implements virtualization-based security (VBS) and smart app control. Both, however, collect telemetry by default. Linux Desktop: Traditional Linux distributions provide limited native app sandboxing. A compromised application can easily read your entire home directory. You must configure sandboxing yourself using Flatpak overrides, virtualization, or MAC policies (SELinux/AppArmor). Physical Security Considerations If your threat model includes physical theft or device seizure:\nEnsure Full-Disk Encryption is active. Use a hardware TPM, Secure Enclave, or Secure Element to enforce decryption delays, blocking automated passphrase cracking. Require a strong alphanumeric passcode instead of a simple 4-digit PIN. Common Threat Modeling Pitfalls Avoid these common mistakes when designing your security model:\n1. Brand-Level Distrust vs. Technical Mitigation Distrusting a specific brand (e.g., Google) without addressing the technical reason for your distrust is a pitfall. Simply migrating your files from Google Drive to another unencrypted hosting provider does not improve your security; it merely shifts trust to a different company. The correct mitigation is adopting client-side encryption (e.g., using Cryptomator or Proton Drive\u0026rsquo;s native E2EE), making the hosting provider\u0026rsquo;s identity irrelevant.\n2. Over-Reliance on Privacy Policies Privacy policies do not prevent data collection. Focus on implementing technical boundaries (like firewalls, local encryption, and Tor) that make compliance monitoring unnecessary.\n3. \u0026quot;Badness Enumeration\u0026quot; Do not focus on building infinite blacklists of \u0026quot;bad actors\u0026quot; or malicious tracking servers. Blocking specific domains is a losing battle because tracking servers change hostnames daily. Instead, configure systemic blocks (e.g., disable network access globally for local tools, block all unencrypted DNS, and enforce strict canvas scrambling).\n4. Blind Trust in Open Source While open-source software is transparent, it is not automatically secure. Project repositories can be compromised, developers can be coerced, and dependencies can introduce vulnerabilities. Furthermore, desktop Linux distributions (which are open source) often have a weaker hardware security and sandboxing baseline compared to commercial, closed-source operating systems like macOS. Always evaluate software based on its active security architecture and features, rather than its license alone.\nConclusion Developing a threat model is a fundamental step toward securing your digital identity. By defining your assets, identifying realistic adversaries, and implementing technical controls, you can protect your privacy without making your daily workflows unusable.\nStay informed, critically analyze new tools, and prioritize technical mitigations over marketing promises.\nThanks for reading this guide! If you found it helpful, please share it to promote digital security awareness.\nRelated Guides De-Google Android: The Complete Privacy Guide — Implement your threat model on a secure mobile device. GrapheneOS: The Definitive Guide — Deep-dive into mobile OS hardening and profile isolation. Self-Hosted VPN with Ad Blocking — Secure your network traffic on public systems. ","permalink":"https://b4.lol/threat-model/","summary":"Learn how to build an effective threat model to protect your privacy and digital security. Avoid the common mistakes beginners make.","title":"Threat Model: How to Define Your Threats"},{"content":" TL;DR — In this guide, you will learn:\nHow to select a privacy-conscious VPS hosting provider. How to install and configure WireGuard as a lightweight VPN server. How to integrate Pi-hole to block ads, telemetry, and trackers at the DNS level. How to configure Unbound as a recursive, local DNS resolver to eliminate third-party DNS dependencies. Summary A self-hosted VPN combining WireGuard, Pi-hole, and Unbound encrypts the traffic between your local devices and your remote Virtual Private Server (VPS), blocks a significant portion of ads and tracking telemetry at the DNS level, and processes domain name resolution locally without relying on commercial third-party DNS providers. Note that a self-hosted VPN does not grant complete anonymity; it shifts your trust from a commercial VPN provider to your VPS host.\nCommercial VPN services frequently monetize user metadata and logs. The alternative is hosting your own personal VPN tunnel. By deploying WireGuard, Pi-hole, and Unbound, you establish a secure connection with integrated ad blocking and independent recursive DNS resolution under your control.\nThis guide provides a comprehensive walkthrough for deploying this integrated stack on a Debian-based system.\nThis is meant to be a complete guide for setting up your own VPN using WireGuard, with ad and tracker filtering provided by an AdBlocking filter built with Pi-hole.\nThis guide is open to improvements and suggestions. I\u0026rsquo;ll describe the configuration that I find offers the best balance between usability and privacy; I\u0026rsquo;m not a networking expert, and following this guide won\u0026rsquo;t magically make you anonymous and untraceable.\nIf you\u0026rsquo;d like to give me suggestions, contribute to the guide, or help with translations, you can open a pull request on GitHub .\nObjective The objective of this deployment is to run a self-hosted VPN with DNS-level ad and tracker filtering. Consider these architectural trade-offs compared to commercial VPN solutions:\nPros Data Sovereignty: You eliminate the risk of a commercial VPN provider logging your browsing metadata or selling your profile. Custom Filtering: You control the exact blocklists deployed on your DNS firewall. Administrative Control: You can share access with family members, configure routing tables, and choose the server\u0026rsquo;s physical hosting location. Jurisdiction Selection: You can deploy the server in countries with strong legal protections for digital privacy (e.g., Iceland or Switzerland). Cons Unique IP Footprint: Unlike commercial VPNs that pool thousands of users under a single public IP, a self-hosted VPN assigns you a dedicated public IP address. Because you are the sole user of that IP, tracking networks can easily correlate your activity back to your physical device. Shifting Trust: You shift your trust from the VPN provider to your VPS hosting provider, who can monitor inbound traffic logs. To mitigate this, select a hosting provider that requires minimal personal data and supports anonymous payment methods. Choosing a Hosting Provider Select a VPS provider operating in a favorable legal jurisdiction (such as countries outside the Five Eyes alliance with robust data retention policies). Look for hosts that support anonymous registration (no phone verification) and cryptocurrency payments.\nRecommended providers for personal VPN hosting:\nVPSbg : A Bulgarian-based host with a strong reputation for privacy and support for Bitcoin payments. 1984 Hosting : Located in Iceland, utilizing green energy and operating under strict Icelandic data protection laws. Njalla : A privacy-focused domain and hosting provider that acts as a proxy registration layer, requiring no personal identification. Before purchasing, verify current pricing, monthly egress bandwidth limits, and confirm the provider\u0026rsquo;s policies allow running personal VPN tunnels.\nRecommendation: Purchase a Virtual Private Server (VPS) running a Debian-based distribution (Debian Stable or Ubuntu LTS).\nEstablishing an SSH Connection To configure your server, connect over SSH from your local terminal:\nssh root@\u0026lt;YOUR_VPS_IP\u0026gt; Enter your administrative password. Once connected, update the system package database:\nsudo apt update \u0026amp;\u0026amp; sudo apt upgrade -y Basic Security Hardening To mitigate automated brute-force attacks on your SSH port, install fail2ban:\nsudo apt install fail2ban -y Note: For production environments, configure key-based SSH authentication and disable password login entirely inside /etc/ssh/sshd_config.\nSystem Configuration 1. WireGuard Installation Use an open-source installer script to automate the initial WireGuard network interface configuration and IP forwarding rules:\ncurl -O https://raw.githubusercontent.com/angristan/wireguard-install/master/wireguard-install.sh chmod +x wireguard-install.sh sudo ./wireguard-install.sh Follow the prompts to configure your public IP, interface name, and port.\n2. Pi-hole DNS Firewall Installation Run the official Pi-hole installation script:\ncurl -sSL https://install.pi-hole.net | bash During the wizard configuration:\nSet the active interface to wg0 (the WireGuard interface). Choose a temporary upstream DNS provider (e.g., Cloudflare). We will configure our local recursive resolver next. Once the setup completes, set a password for the web administrative dashboard:\npihole setpassword 3. Unbound Recursive Resolver Installation Install Unbound to handle DNS resolution recursively directly from root name servers, eliminating dependencies on third-party resolvers:\nsudo apt install unbound -y Create a new configuration file /etc/unbound/unbound.conf.d/pi-hole.conf:\nsudo nano /etc/unbound/unbound.conf.d/pi-hole.conf Paste the following configuration:\nserver: verbosity: 0 interface: 127.0.0.1 port: 5335 do-ip4: yes do-udp: yes do-tcp: yes do-ip6: yes prefer-ip6: no harden-glue: yes harden-dnssec-stripped: yes use-caps-for-id: no edns-buffer-size: 1472 prefetch: yes prefetch-key: yes minimal-responses: yes cache-min-ttl: 300 cache-max-ttl: 86400 serve-expired: yes msg-cache-size: 50m rrset-cache-size: 100m num-threads: 1 so-reuseport: yes so-rcvbuf: 4m so-sndbuf: 4m private-address: 192.168.0.0/16 private-address: 169.254.0.0/16 private-address: 172.16.0.0/12 private-address: 10.0.0.0/8 private-address: fd00::/8 private-address: fe80::/10 Restart Unbound to apply:\nsudo systemctl restart unbound Configure Pi-hole to route all upstream requests to Unbound locally on port 5335:\nsudo pihole-FTL --config dns.upstreams \u0026#39;[\u0026#34;127.0.0.1#5335\u0026#34;]\u0026#39; sudo pihole-FTL --config dns.listeningMode \u0026#39;local\u0026#39; sudo pihole-FTL --config dns.dnssec \u0026#39;false\u0026#39; Configuring Pi-hole and Adlists Log into your administrative dashboard by navigating to:\nhttp://\u0026lt;YOUR_VPS_IP\u0026gt;/admin Enter your administrative password.\nAdding Blocklists Navigate to Adlists in the dashboard settings. Add lists containing known tracking and advertising domains. The following lists are recommended for a balanced configuration: https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts https://adaway.org/hosts.txt https://v.firebog.net/hosts/AdguardDNS.txt https://v.firebog.net/hosts/Easyprivacy.txt https://winhelp2002.mvps.org/hosts.txt Apply the lists by running the update command under Tools → Gravity. Connecting Client Devices 1. Mobile Devices (Android \u0026amp; iOS) Install the official WireGuard app from your store. On the VPS terminal, run the installer script to create a client profile: sudo ./wireguard-install.sh Choose Add new client and name the profile. The terminal will output a QR code. Scan the QR code using your mobile WireGuard application. Edit the client tunnel in your app: set the DNS server to the internal IP address of your VPS (e.g., 10.0.0.1 or the default gateway assigned by the script). 2. Desktop Clients (Windows \u0026amp; Linux) Generate a new client profile via the installer script. Copy the resulting .conf profile file to your desktop client. On Linux systems, save the configuration file under /etc/wireguard/vpn.conf and control the tunnel using wg-quick: # Enable the tunnel connection sudo wg-quick up vpn # Disable the tunnel connection sudo wg-quick down vpn Verification and Testing Once connected, run the following verification checks:\nIP Leak Audit: Visit vpntesting.com to verify that your visible public IP matches your remote VPS server rather than your physical network location. Ad-Blocker Audit: Visit d3ward.github.io/toolz/adblock.html with local browser ad-blockers disabled. A success rate above 70-80% confirms that the DNS firewall is blocking advertising hosts correctly. Conclusions This configuration provides a balanced baseline for secure, self-hosted web transit. You can add or modify DNS blocks and firewall rules to tailor the environment to your operational needs.\nRelated Guides Tor Node: Setup Guide — Host a Tor relay to support the anonymous routing network. How to Build a Threat Model — Define your privacy parameters. GrapheneOS Guide — Deep-dive into secure mobile environments. De-Google Android: Complete Privacy Guide — Set up a secure mobile platform. ","permalink":"https://b4.lol/vpn/","summary":"Build your own private VPN with WireGuard, Pi-hole and Unbound DNS. Block ads and trackers without trusting commercial providers. Full guide.","title":"Self-Hosted VPN: WireGuard + Pi-hole + Unbound"},{"content":" TL;DR — In this guide, you will learn:\nHow the Tor network and onion routing function to protect user privacy. The trade-offs and risks of running a Tor node on your home network versus a rented Virtual Private Server (VPS). How to install and configure a Tor node (as a middle or exit relay) using an automated bash script or the official Tor Project repository. How to monitor, maintain, and verify your active node. Summary A Tor node is a volunteer-run relay that routes encrypted traffic within the Tor network. To host a relay responsibly, start by deploying a middle relay on a virtual private server (VPS) or a dedicated system, configure realistic bandwidth accounting limits, enable automated security updates, and verify your configuration using Nyx, system logs, and Tor Metrics.\nThe Tor network is a cornerstone of digital privacy, relied upon by journalists, human rights defenders, and everyday internet users. The network operates entirely on volunteer-run nodes. Increasing the number of active nodes directly enhances network speed, safety, and censorship resistance. This guide outlines how to deploy your own Tor relay node to support the network.\nThis is meant to be a complete guide to launching a node that supports the Tor network. Before we start, let\u0026rsquo;s briefly explain what this protocol is:\nThe Tor network, short for \u0026quot;The Onion Router,\u0026quot; is an anonymous communication network designed to increase the privacy and security of users on the Internet. Its name comes from the concept of an \u0026quot;onion,\u0026quot; since it works by relying on several layers of encryption, similar to the layers of an onion.\nTor\u0026rsquo;s main goal is to make it difficult to track users\u0026rsquo; online activity, protecting their identity and location. The network works by routing Internet traffic through a series of volunteer-run servers, known as \u0026quot;Tor nodes,\u0026quot; operated by volunteers distributed all over the world. Each Tor node strips away one layer of encryption, revealing only the IP address of the previous node, which makes it difficult to trace the traffic back to its origin.\nThanks to this layered approach, Tor provides a significant degree of anonymity to its users, but it\u0026rsquo;s important to note that it doesn\u0026rsquo;t offer total security and can be vulnerable to attacks in certain scenarios. Despite this, the Tor network is widely used by journalists, human rights activists, and users seeking to preserve their online privacy.\nFor more information, I highly recommend listening to this episode:\nObjective The goal of this guide is to configure and run a Tor node (locally or on a VPS) while managing the associated operational risks. By hosting a relay, you contribute directly to the speed and robustness of the Tor network.\nWe cover two setup methods:\nAutomated Script (Recommended): Utilizes a custom Bash script to automate installation and security parameters. Manual Installation: Outlines manual repository registration and configuration file overrides. Before installing, review the security and privacy implications of hosting a node on your home network versus renting a remote server.\nRisk Assessment Running a Tor node requires matching your hardware configuration to your personal privacy objectives.\nHosting on a Home Network Pros: You retain complete physical control over the server hardware and cryptographic keys, preventing third-party access. It is also cost-effective if you reuse existing home hardware (such as a Raspberry Pi). Cons: Home ISPs often enforce strict monthly bandwidth limits and asymmetric speeds (slower upload rates), limiting the node\u0026rsquo;s throughput. Dynamic IP changes assigned by residential ISPs can also reduce relay stability. Privacy Caveat: Because Tor relays are public, running a node at home exposes your public residential IP address as associated with the Tor network. Some services or web shops actively block residential IPs that run Tor relays. Hosting on a Virtual Private Server (VPS) Pros: Rented servers offer static IP addresses, high bandwidth, and symmetric speeds. They run in highly reliable data centers with excellent uptime. Cons: VPS hosting introduces ongoing monthly costs and requires you to trust a third-party host with your data transit. Legal/Policy Compliance: Managing a rented server requires complying with the Terms of Service (ToS) of your provider and the local jurisdiction of the data center hosting your VPS. In summary, hosting a home node increases network decentralization and security but leaks the association between your home IP and Tor. Renting a VPS simplifies setup and protects your home IP address, but requires ongoing subscription costs.\nSelecting a Hosting Provider If you choose to run your node on a VPS, evaluate these factors:\nBandwidth Allocation: Relays require substantial monthly egress limits. Look for providers offering unmetered ports or high bandwidth caps (5 TB or more). Server Location \u0026amp; Jurisdiction: Choose jurisdictions with strong data protection policies and digital civil liberties, as server monitoring laws vary by country. Tor Compatibility Policies: Not all VPS providers allow Tor nodes. Verify that your provider explicitly permits running middle or exit relays. Recommended hosting providers for Tor relays:\nVPSbg : Sofia-based provider with a strong privacy record. They support both middle and exit nodes (provided they are configured with a strict exit policy). They accept anonymous registration and cryptocurrency payments. Trabia : Located in Moldova, offering affordable, unmetered bandwidth plans. Useful for hosting middle relays that consume high volumes of traffic. UDN (Ukrainian Data Network) : A highly privacy-focused hosting service. Registration does not require web forms; configuration and sales are handled manually via encrypted communication channels. System Requirements Middle Relay: 1 CPU core, 512 MB RAM (1 GB RAM recommended for relay speeds exceeding 40 Mbps), and at least 2 TB (ideally 5 TB+) of monthly bandwidth. Exit Node: 1 CPU core, 1 GB RAM (2 GB RAM recommended for high-throughput exits), and 5 TB+ of monthly egress traffic. Setup via Automated Script (Recommended) This script automates repository configuration, package verification, and baseline hardening for Debian and Ubuntu systems.\nLog into your target server via SSH. If you are logged in directly as root, omit the sudo command:\nsudo apt-get update \u0026amp;\u0026amp; sudo apt-get upgrade -y sudo apt install git -y git clone https://github.com/b4lol/Tor-node-script.git cd Tor-node-script chmod +x tor.sh sudo ./tor.sh The script will fetch the official Tor repositories, check signatures, install dependencies, and prompt you for configuration details:\nNode Type: Choose between a Middle Relay (recommended for most users) or an Exit Node (advanced users only, requires managing abuse complaints). Nickname: A unique name for your relay. Use only letters, numbers, and underscores (no spaces). Contact Info: An email address so the Tor Project team can reach you if your node goes offline or exhibits routing errors. To avoid spam, obfuscate the email (e.g., yourname[at]example[dot]com). Bandwidth Accounting: Set a weekly bandwidth limit. For example, if your VPS cap is 1 TB per month, input 250 GB (weekly) to ensure you do not exceed the limit. Once complete, the service will start automatically. You can skip to the Post-Installation Checks section.\nManual Configuration (Alternative) If you prefer configuring the packages manually, use the official Tor Project repositories to receive timely security updates.\n1. Enable Automated Security Updates On any public-facing server, install unattended-upgrades to apply kernel patches and security fixes automatically:\nsudo apt install unattended-upgrades apt-listchanges -y 2. Configure Repository Sources Install transit dependencies:\nsudo apt install apt-transport-https lsb-release -y Identify your Debian/Ubuntu distribution codename:\nlsb_release -c Create a new sources list file /etc/apt/sources.list.d/tor.list:\nsudo nano /etc/apt/sources.list.d/tor.list Insert the following lines, replacing \u0026lt;distribution\u0026gt; with your active distribution codename (e.g., bookworm or jammy):\ndeb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] https://deb.torproject.org/torproject.org \u0026lt;distribution\u0026gt; main deb-src [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] https://deb.torproject.org/torproject.org \u0026lt;distribution\u0026gt; main 3. Import Tor Project GPG Key wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/tor-archive-keyring.gpg \u0026gt;/dev/null 4. Install Tor Update your package index and install the signing keyring along with the Tor daemon:\nsudo apt update sudo apt install tor deb.torproject.org-keyring -y 5. Configure torrc Options Open the main configuration file:\nsudo nano /etc/tor/torrc Clear the contents or append one of the configurations below, replacing variables ($nickname, $contact_info, $bandwidth) with your values:\nConfiguration for a Middle Relay: Nickname $nickname ContactInfo $contact_info AccountingRule sum AccountingStart week 1 10:00 AccountingMax $bandwidth ORPort 443 ExitRelay 0 SocksPort 0 Configuration for an Exit Node (Strict Policy): Nickname $nickname ContactInfo $contact_info AccountingRule sum AccountingStart week 1 10:00 AccountingMax $bandwidth ORPort 443 ExitRelay 1 SocksPort 0 ExitPolicy accept *:22 # SSH ExitPolicy accept *:23 # Telnet ExitPolicy accept *:43 # WHOIS ExitPolicy accept *:53 # DNS ExitPolicy accept *:79 # Finger ExitPolicy accept *:80-81 # HTTP ExitPolicy accept *:88 # Kerberos ExitPolicy accept *:110 # POP3 ExitPolicy accept *:143 # IMAP ExitPolicy accept *:194 # IRC ExitPolicy accept *:220 # IMAP3 ExitPolicy accept *:389 # LDAP ExitPolicy accept *:443 # HTTPS ExitPolicy accept *:464 # Kpasswd ExitPolicy accept *:465 # SMTPS ExitPolicy accept *:531 # IRC/AIM ExitPolicy accept *:543-544 # Kerberos ExitPolicy accept *:554 # RTSP ExitPolicy accept *:563 # NNTP over SSL ExitPolicy accept *:587 # SMTP submission ExitPolicy accept *:636 # LDAP over SSL ExitPolicy accept *:706 # SILC ExitPolicy accept *:749 # Kerberos ExitPolicy accept *:853 # DNS over TLS ExitPolicy accept *:873 # Rsync ExitPolicy accept *:902-904 # VMware ExitPolicy accept *:981 # Firewall HTTPS management ExitPolicy accept *:989-990 # FTP over SSL ExitPolicy accept *:991 # Netnews ExitPolicy accept *:992 # Telnet over SSL ExitPolicy accept *:993 # IMAP over SSL ExitPolicy accept *:994 # IRC over SSL ExitPolicy accept *:995 # POP3 over SSL ExitPolicy accept *:1194 # OpenVPN ExitPolicy accept *:1220 # QuickTime Admin ExitPolicy accept *:1293 # IPSec ExitPolicy accept *:1500 # VLSI ExitPolicy accept *:1533 # Sametime ExitPolicy accept *:1677 # GroupWise ExitPolicy accept *:1723 # PPTP ExitPolicy accept *:1755 # RTSP ExitPolicy accept *:1863 # MSNP ExitPolicy accept *:2082 # Infowave ExitPolicy accept *:2083 # RadSec ExitPolicy accept *:2086-2087 # GNUnet ExitPolicy accept *:2095-2096 # Webmail ExitPolicy accept *:2102-2104 # Zephyr ExitPolicy accept *:3128 # Squid ExitPolicy accept *:3389 # RDP ExitPolicy accept *:3690 # SVN ExitPolicy accept *:4321 # RWHOIS ExitPolicy accept *:4643 # Plesk ExitPolicy accept *:5050 # Yahoo Messenger ExitPolicy accept *:5190 # AOL ExitPolicy accept *:5222-5223 # XMPP ExitPolicy accept *:5228 # Google Play Store ExitPolicy accept *:5900 # VNC ExitPolicy accept *:6660-6669 # IRC ExitPolicy accept *:6679 # IRC over SSL ExitPolicy accept *:6697 # IRC over SSL ExitPolicy accept *:8000 # SHOUTcast ExitPolicy accept *:8008 # Alternative HTTP ExitPolicy accept *:8074 # Gadu-Gadu ExitPolicy accept *:8080 # Alternative HTTP ExitPolicy accept *:8082 # Electrum HTTPS ExitPolicy accept *:8087-8088 # Media servers ExitPolicy accept *:8332-8333 # Bitcoin ExitPolicy accept *:8443 # PCsync HTTPS ExitPolicy accept *:8888 # Alternative HTTP ExitPolicy accept *:9418 # Git ExitPolicy accept *:9999 # Urchin ExitPolicy accept *:10000 # Webmin ExitPolicy accept *:11371 # OpenPGP HKP ExitPolicy accept *:19294 # Google Voice ExitPolicy accept *:19638 # Ensim ExitPolicy accept *:50001-50002 # Electrum SSL ExitPolicy accept *:64738 # Mumble ExitPolicy reject *:* Post-Installation Management After editing torrc, restart the Tor service to apply the configuration:\nsudo systemctl restart tor@default 1. Troubleshooting Logs Check the system daemon logs to verify the initialization sequence and identify parsing errors:\nsudo journalctl -xeu tor@default 2. Live Status Monitoring (Nyx) Nyx is a command-line interface monitor that displays active connections, bandwidth usage, and node status. Install it using your package manager:\nsudo apt install nyx -y Launch the monitor:\nsudo -u debian-tor nyx Verifying Network Visibility Within 2 to 4 hours of starting, your relay should be indexed on the Tor Project metrics server. Search for your node nickname or public IP address on: Tor Metrics Relay Search If your node appears in the search index, it is routing traffic on the network.\nConclusion Your Tor relay is now active and routing encrypted traffic. Keep the host OS updated, check Nyx occasionally, and monitor your monthly egress limits to ensure you remain within your hosting bandwidth caps. 🐢\nRelated Guides Self-Hosted VPN with WireGuard — Build your own VPN with integrated DNS ad-blocking. How to Build a Threat Model — Define your assets and adversarial boundaries. GrapheneOS: The Definitive Guide — Harden your mobile device. ","permalink":"https://b4.lol/tor/","summary":"Learn how to set up a Tor node (middle relay or exit) on a VPS or locally. Automated script included. Complete guide.","title":"Tor Node: Complete Setup to Support the Network"},{"content":"Hi, I\u0026rsquo;m Hüseyin (b4lol) I\u0026rsquo;ve never accepted a ready-made life handed to me. Instead of consuming whatever packaged system is put in front of me, I\u0026rsquo;d rather build my own from the ground up if I have to — because if you\u0026rsquo;re not the architect of a structure, you can\u0026rsquo;t truly be free inside it. This site is a natural extension of that conviction: I\u0026rsquo;m a digital privacy advocate and cybersecurity researcher, and for years I\u0026rsquo;ve been creating free, accessible guides to help people take back control of their digital lives.\nI firmly believe privacy is not about having something to hide—it is a fundamental right to be exercised every day. I hold the same conviction regarding free expression, resistance to censorship, and the inviolability of individual rights. My work stems from the belief that everyone should have the tools and knowledge to protect themselves, without depending on paid services or companies that profit from personal data.\nMy technical pursuits reflect the same philosophy: from the depths of the Linux kernel to network protocol optimization, and from Rust\u0026rsquo;s memory safety to the cutting edge of Android modding—it all serves one goal: building pure, fast systems free of bloat. I have zero tolerance for code that serves no purpose or runs quietly in the background without reason. I apply this same discipline at Coresoft Studio, where I build brand identity and corporate vision.\nThe Mission The goal of this site is simple: offer free, high-quality education on privacy and digital security, with no compromises.\nEvery guide here is the result of hours of research, testing, and hands-on experimentation. You won\u0026rsquo;t find sponsored content, hidden affiliations, or advice driven by financial interests. What you read is what I believe in and personally use.\nAreas of Expertise Over the years, I have researched and written detailed guides on:\nGrapheneOS — The privacy-focused Android operating system. I cover everything from choosing a device to advanced configuration, including complete de-Googling. Self-Hosting — Setting up personal VPNs with WireGuard, Pi-hole, and Unbound for tracker- and ad-free browsing. The Tor Network — Configuring Tor relays to contribute to the network and protect free communication. Threat Modeling — How to build a personalized threat model, which is the essential first step in any privacy journey. Android Security — De-Googling, app management, permissions, and best practices to reduce the attack surface of mobile devices. What This Site Offers Free Guides All guides are completely free, written to be accessible to both beginners and advanced users. The site\u0026rsquo;s source code is available on GitHub for anyone who wants to contribute, fix, or translate the content.\nThe Philosophy Behind This Site This site reflects the values it promotes:\nNo analytics — I don\u0026rsquo;t track visitors, collect data, or use profiling cookies. No advertising — No ads, banners, or sponsored content. No registration required — I don\u0026rsquo;t ask for email addresses, accounts, or personal data. Open source — The site is open source; anyone can review, contribute to, or fork the project. Get Involved and Stay in Touch The best way to support this project is to share it: on Telegram, on X, and with friends and family. The more people we reach, the stronger the privacy culture becomes.\nYou can find and contact me here:\nGitHub: b4lol — source code, contributions, and projects Telegram: @b4lolx — for questions, suggestions, and direct support X/Twitter: @b4lolx — updates and discussions Instagram: @b4ioi Email: admin@b4.lol — for private communications Thanks to everyone who chooses to share or contribute. This site exists because of you.\n","permalink":"https://b4.lol/about/","summary":"\u003ch2 id=\"hi-im-hüseyin-b4lol\"\u003eHi, I\u0026rsquo;m Hüseyin (b4lol)\u003c/h2\u003e\n\u003cp\u003eI\u0026rsquo;ve never accepted a ready-made life handed to me. Instead of consuming whatever packaged system is put in front of me, I\u0026rsquo;d rather build my own from the ground up if I have to — because if you\u0026rsquo;re not the architect of a structure, you can\u0026rsquo;t truly be free inside it. This site is a natural extension of that conviction: I\u0026rsquo;m a digital privacy advocate and cybersecurity researcher, and for years I\u0026rsquo;ve been creating free, accessible guides to help people take back control of their digital lives.\u003c/p\u003e","title":"About"}]