From L1Wiki
Jump to: navigation, search
Work in progress, expect frequent changes. Help and feedback is welcome. See discussion page.

****Not even a draft, this is a draft of a template****
**A ton of more tweaks and guides to be added, chime in!**
*I pity the fool who follows this wiki at this stage*

*Security and privacy are two different things, this wiki provides steps for hardening*

-OSX (iOS seperate?)
-Software (security software and how to secure software (encryption before uploading to cloud, PGP, VPN, etc)

****Not even a draft, this is a draft of a template****


-BIOS password, startup password -Password-protect the bootloader, or install it on a flashdrive
-Why: Prevent rogue software or people from editing boot parameters or booting to runlevel 1
***Warning: If misconfigured your system may be unable to boot***

First, a superuser is required:
Add a priviledged user by editing /etc/grub.d/00_header or /etc/grub.d/01_users
the *00_header config isn’t recommended to change by hand, so add a new superuser to the *01_users config:
set superusers=”bob”
password bob bobspassword
Then, the grub config needs to be edited so that grub knows which entries should have limited access:
Because editing /boot/grub2/grub.cfg isn’t recommended, just check it for the proper menuetry, and add it to the
/etc/grub.d/40_custom config, update grub.
if not present, add the --unrestricted parameter after the menuentry (or leave empty)
menuentry 'Ubuntu, with Linux 3.2.0-24-generic' --class ubuntu -class os --unrestricted { --unrestricted allows only bob to edit the GRUB2 entry, whereas if no parameter is set only bob is allowed to boot into the entry in question.
Update grub.


-Full disk encryption -Prevent access to files if computer is lost or stolen
-File encryption -Prevent access to sensitive files on a live system ---


-Why: See which files has been altered in the future
Initialize the current system

$ sudo aide –init 



-Why: Strive for minimum user permissions
-Set the user policies; sudo user as staff_u or, and the basic user as user_u
Check the currently assigned role by

 $ id -Z 

The default role for all new users is unconfined_u, which means there’s only a few restrictions. This grants ease of use but leaves a huge surface open for exploits.
Luckily we don’t need to harden the policies individually, we just assign the proper predefined roles for each user:

  • staff_r role for the account with sudo priviledges
  • user_r for the user account that is only allowed for basic use

To assign these roles for the users, run as root

# usermod -Z staff_u adminusername
# usermod -Z user_u username 

Log out and back in for changes to take effect
For administrative tasks ’su’ or ’sudo’ no longer works for the admin account, one needs to jump into the sys admin role first by running

 $ sudo -i -r sysadm_r 

Basic users assigned to the user_r role aren't allowed to su to root or run sudo, however one can first ’su adminuser’ and then ’sudo -i -r sysadm_r’, not needing to log out from an active session to perform administrative tasks.
Some applications will not run in restricted roles unless changes to the policies are made, for example chromium is blocked because it requires the sys_admin capability in order to run.
Capabilities can be thought of as root privileges split into targeted chunks; some applications need to run processes with escalated privileges in order to work, but to prevent full root access only the required capability is assigned and allowed. For example to set the current time the settings application needs basically higher rights to change the settings, so in order to prevent the application to be needed to be run as root or sudo, if it’s assigned the sys_time capability, it is allowed to change time without needing to be run as root.
- No idea how it works
Grsec RBAC


-Disable automount to prevent rogue drives from running potentially bad scripts ---


-docker for server?


-qemu, kvm


-Keepass 2/X, unlock with password and key file, store the keyfile on a separate thumbdrive
-And alternatives
2FA and OTP


-Because passwords are weak -VPN & SSH ---


-fail2ban / sshguard -Autoban IP addresses after multiple failed login attemps (IPs are spoofable, someone could lock you out)
So the better practise is to:
-Disable password login (key login only)


-rkhunter / chkrootkit




-Change that damn password
-IPS (running in IPS mode, not IDS) Snort / Suricata
-DNS cache and blacklist
-Squid clamscan


--Noscript, allow first party scripts for convinience, strict https mode
--clean cache on exit (cache poisoning)
--uBlock origin
--Block 3rd party cookies
--Requestpolicy continued, but requires alot of tweaking

-Chromium and the like
--uMatrix, allow first party scripts
--uBlock origin
-- Those 3rd party cookies and cache
-- HTTPS by default / HTTPS everywhere