Git-Mirrors
/
into-the-crypt
mirror of https://0xacab.org/optout/into-the-crypt.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Slight reorganization / Fixed MD header

This commit is contained in:
arcanedev 2021-10-23 17:34:07 +00:00
parent 974556be58
commit 00a56ee7f9
No known key found for this signature in database
GPG Key ID: 13BA4BD4C14170C0
1 changed files with 16 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
README.md
View File

@ -7,14 +7,14 @@
- [Hardware Selection](#hardware-selection)
- [Operating System](#operating-system)
- [Disable Logging](#disable-logging)
- [Clear Caches](#clear-caches)
- [Secure Deletion](#secure-deletion)
- [MAC Randomization](#mac-randomization)
- [Traffic Manipulation](#traffic-manipulation)
- [Packet Filter](#packet-filter)
- [Proxy](#proxy)
- [Leak Prevention](#leak-prevention)
- [Routing](#routing)
- [Cache Clearing](#cache-clearing)
- [Secure Deletion](#secure-deletion)
- [Browsing](#browsing)
- [Browser Configuration](#browser-configuration)
- [Search Engine](#search-engine)
@ -125,7 +125,7 @@ For Android, the best operating system to date is GrapheneOS.[^11] This operatin
GNU/Linux based phones, such as Pine64's Pine Phone[^12] or Purism's Librem 5,[^13] are now hitting the market. These devices are inherently insecure in early conception. One could consider these devices private but not secure. If an injection could reach the device, then all privacy is lost.
## Disable Logging
Disable logging at the source is the best solution to ensure excess logs are not being stored. Daemons or processes can automate the process of log collection. This has its useful functions for both debugging and security (auditing), however it is detrimental to the idea of information retention. It is strongly advised to periodically shred the log files if not disabling the logging daemons entirely.
Disabling logs at the source is the best solution to ensure excess logs are not being stored. Daemons or processes can automate the process of log collection. This has its useful functions for both debugging and security (auditing), however it is detrimental to the idea of information retention. It is strongly advised to periodically shred the log files if not disabling the logging daemons entirely.
On GNU/Linux with SystemD, logging can be disabled through the use of the following commands:
```
systemctl disable syslog.service
@ -137,6 +137,19 @@ systemctl disable systemd-journald.service
While it is wise to reduce your logging footprint locally on your device, full disk encryption (FDE) is a sufficient anti-forensic mitigation for logging. If the attacker obtains access to your device as it is running (either physical or remote via a security compromise), logging is most likely the least of your concerns.
## Clear Caches
There are various caches containing sensitive information on both mobile devices and GNU/Linux systems. Linux systems have the tendency to push most logs to the /var/log/ directory. This is a simple deletion process.
Due to Android sandbox implementations, caches can no longer be centrally erased; caches must be cleared on individual applications. System logging is also sprawled across various directories. Reducing locally generated logs on Android is comparable to removing telemetry from Windows OS variants. Clearing caches on Android provides no serious benefit, but it does remove the amount of data present on the device. For proper privacy, only trusted applications should be used - preferably Free and Open-Source (FOSS).
## Secure Deletion
Deletion of files in most operating systems today is a loose version of the term. Deletion implies the eradication of the selected file. Rather, this is deletion of the file's reference. To truly delete a file from the drive, one must completely overwrite the data. This can be done over time by passive dumb luck or it could be a conscious effort. There are existing tools for secure deletion (wiping over the file) on most platforms. On GNU/Linux systems, there is a tool in the "secure-delete" package called shred that will zero over the file. This performs deletion using the Gutmann method. Another tool called Bleachbit is known to clean the caches of the system. Built into the tool is an option to overwrite all free space on the disk. This could be a routine cleanup procedure for the concerned. On Windows, there is a tool included in the SysInternals package called SDelete that will provide a similar function to GNU/Linux's shred.
A simple shred command in a Linux bash shell: `shred -n 32 -z -u <FILE>`
This command would use GNU coreutils shred function to wipe over the designated file with 32 iterations. The -z adds a final overwrite to hide the shredding process, and the -u unlinks the file completely.
Note: This is an example command; I am not recommending 32 overwrites.
The NSA has in the past developed malicious firmware for HDDs that can create secret copies of user-written data. SSDs which make use of wear-leveling cannot have information securely erased by the user. However, SSDs with wear leveling also pose a significant annoyance, and even create difficulty for, forensic investigators. Such annoyance cannot be considered a security guarantee. In short, wear-leveling, garbage collection, and trim operations are largely outside of the user's control, therefore "secure" deletion should not be assumed to be possible. Regarding SSDs, trim operations should always be enabled as it stands to make files unreadable using "Deterministic Read After Trim" or "Deterministic Zeroes After Trim." Consider trim as an unreliable backup mitigation to FDE.
## MAC Randomization
Media access control (MAC) addresses are unique identifiers for network interface controllers/cards (NIC). These identifiers exist at Layer 2 of the OSI model.[^14] As one could expect, unique identifiers can be problematic. Proprietary router firmware such as Netgear and other vendors can attempt to correlate static MACs to individuals. Your MAC could also be correlated between different routers and subsequently different router SSIDs. Wardriving is a method by which organizations will scan for SSIDs around different areas to collect MAC addresses and SSIDs.
@ -178,20 +191,6 @@ In regards to implementation, there are a variety of options. Host-based virtual
As previously stated in the Traffic Leakage section, software-based routing should not be relied on. If it is to be implemented, it should be viewed as adding an additional layer of security. There are applications such as Orbot[^17] which allows the use of the TOR network, a variety of VPN applications (which are primarily wrappers for OpenVPN), and there are scripts that configure local packet filters to "torrify" all traffic. While I have no basis in saying all software-based leak prevention mechanisms are prone to failure, historically leak prevention has been inadequate. Even Whonix reports that they "cannot do the impossible and magically prevent every kind of protocol leak and identifier disclosure." [^18] Hardware routing adds more architecture into the mix, but it provides the bulletproof assurance that there is no leakage of traffic. For critical operations, consider hardware mechanisms. For the privacy-centric individual, software-based kill switches should be more than sufficient.
## Clean Caches
There are various caches containing sensitive information on both mobile devices and GNU/Linux systems. Linux systems have the tendency to push most logs to the /var/log/ directory. This is a simple deletion process.
Due to Android sandbox implementations, caches can no longer be centrally erased; caches must be cleared on individual applications. System logging is also sprawled across various directories. Reducing locally generated logs on Android is comparable to removing telemetry from Windows OS variants. Clearing caches on Android provides no serious benefit, but it does remove the amount of data present on the device. For proper privacy, only trusted applications should be used - preferably Free and Open-Source (FOSS).
## Secure Deletion
Deletion of files in most operating systems today is a loose version of the term. Deletion implies the eradication of the selected file. Rather, this is deletion of the file's reference. To truly delete a file from the drive, one must completely overwrite the data. This can be done over time by passive dumb luck or it could be a conscious effort. There are existing tools for secure deletion (wiping over the file) on most platforms. On GNU/Linux systems, there is a tool in the "secure-delete" package called shred that will zero over the file. This performs deletion using the Gutmann method. Another tool called Bleachbit is known to clean the caches of the system. Built into the tool is an option to overwrite all free space on the disk. This could be a routine cleanup procedure for the concerned. On Windows, there is a tool included in the SysInternals package called SDelete that will provide a similar function to GNU/Linux's shred.
A simple shred command in a Linux bash shell: `shred -n 32 -z -u <FILE>`
This command would use GNU coreutils shred function to wipe over the designated file with 32 iterations. The -z adds a final overwrite to hide the shredding process, and the -u unlinks the file completely.
Note: This is an example command; I am not recommending 32 overwrites.
The NSA has in the past developed malicious firmware for HDDs that can create secret copies of user-written data. SSDs which make use of wear-leveling cannot have information securely erased by the user. However, SSDs with wear leveling also pose a significant annoyance, and even create difficulty for, forensic investigators. Such annoyance cannot be considered a security guarantee. In short, wear-leveling, garbage collection, and trim operations are largely outside of the user's control, therefore "secure" deletion should not be assumed to be possible. Regarding SSDs, trim operations should always be enabled as it stands to make files unreadable using "Deterministic Read After Trim" or "Deterministic Zeroes After Trim." Consider trim as an unreliable backup mitigation to FDE.
## Browsing
### Browser Configuration
It is no secret that governments deliver malware based on anomalous internet activity, alternately put, flagged activity. While the common forms of investigations are typically conducted via physical device seizure, security mechanisms should be taken into account to stunt "passive" investigations. Browsers can be configured to disable the installation of extensions, device storage usage, setting alterations, theme changes, cookie restrictions, and cache deletions. The most important facets of private internet browsing include the browser security model, fingerprinting mitigations, and reliance on JavaScript.