Exploring Web Hosting Security: Principles, Layers, and Monitoring
Dive into the world of web hosting security with a focus on key principles, overlapping layers of defense, and the importance of continual monitoring and auditing. Explore visuals like the Swiss cheese model and Castle model, and understand the balance between security, usability, and maleability. Discover the outermost layer of security – physical security measures – and enjoy recommendations for fun security-related films to watch for entertainment and inspiration.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Web hosting security Some thoughts on web-security within the ZID @ UIBK Otheus 2021-12-07
First Principles First Principles 1. Security negatively correlates to Usability and system Maleability. Changing one often adversely affects the other. 2. Security is implemented by overlapping multiple layers. The Swiss- cheese model, the Ring model, and the metaphorical Castle are all visualizations of layers. 3. Without continual Monitoring and periodic Auditing of your layers, your security is potentially worthless.
First principles: Monitoring and Auditing Having these . Does not remove the need for these
Fun security-related films to watch The Good War Games (possibly, the best film ever on cybersecurity) Mr Robot (Amazon series, amazingly accurate and up-to-date) Duplicity (corporate espionage at its best) Not Bad Sneakers (good stuff, except a universal decryption device) Catch Me if You Can (pre-computer, old school) Johnny Mnemonic, Oceans 13, Matrix II, Spy Game Ugly, Worthless trash(security POV) The Matrix, Mission Impossible (all), Oceans 11 & 12 Hackers, The Net, NetForce, Swordfish, Firewall
Layers: The outermost layer: Physical Physical Narrow definition: prevention of physical access to a computer or server or data. Examples & Mediations: Gaining physical access to the server room. Locks, alarms, security guards, keycodes. Tapping / intercepting the communications on a phone line. Fiber, encryption. Installing your own wireless access point. WPA2 Digging through trash or someone s desk notes for passwords. Shredders, Password managers. 2FA Expanded definition: Protection of any kind of access to a computer s operating system, raw data, or physical components outside of the context of its normal, operational system. Examples / Mediations: Stealing the laptop of a system-administrator. Biometrics, Password managers, separate Keypairs for each device Gaining access to the hypervisor of a VM server. Accessing the virtual console of a VM. Accessing the iLO of a phyical host. Disable power source (Denial-of-Service) or network Rowhammer : an attack which exploits hardware design flaws to retrieve secret data of another VM.
Physical Security Layers Historically, physical access to a server meant you could completely control that server. Mitigatations: disk encryption, UFI boot, password-protected BIOS Physical security is concerned with not only access, but denial of access. Physical security also involves multiplelayers and multiple domains Power, Fire, Electromagnetic radiation Physical security is often handled by the organization s building / property security, and thus easily overlooked by IT. Your laptop, your tablet, your smartphone may be an extension of a computer server, and thus, good physical security practices apply!
Layers in the Linux operating System 1. Hardware rings: Userland vs Kernel 2. UNIX permissions Model: root vs everyone else 3. POSIX ACLs on files (skipping this because almost never used) 4. Linux extensions such as SELinux (Security-Enhanced Linux) and Debian AppArmor
Linux layer: usermode vs kernel The Operating system runs in either of these two states . On Intel derived processors, the kernel runs in ring 0 and has complete access to all hardware resources. Everything else, including all processes* run in usermode . (*If you look at a full process table, processes which are shown as [something] are actually kernel-mode threads.) Loadable device-drivers can be loaded after boot-time, and is code run directly in kernel mode. Processes owned by root (uid=0) can load these drivers at run-time with modload .
Linux User-permissions Model summary -1 In UNIX and Linux, there are only* Files and Processes. Each file and process has an owner and a group identity. A directory is merely a special kind of a file. Nearly all devices are actually interfaced through special entries in the filesystem. * and Network interfaces and sockets Processes inherit the ownership of its parent ie, the process that spawned it New files always belong to the effective user ID of the process that created it. Only a root-owned process can change ownership of a file or process.
Linux User-permissions Model summary 2 Each file has a mode attribute, which is a bit-vector-tuple controlling: Read, Write, or Execute permissions for each of: User, Group, World / Other These are modified using the chmod command, and often represented in Octal notation But sometimes also with ugo and rwx . A fouth set of 3 bits is used as special bits depending on the context and setting of the other bits. In order to allow processes owned by a non-root user to spawn processes which are owned by root, an executable file may have the special attribute set-uid bit . When such a program is executed, the ownership of the process will be the ownership of the file and not the calling process. In Linux, it is not possible to use the setuid bit to execute a script (any executable interpreted by a shell or starting with #!). To get around the above limitation, we often use the handy program su or the more configurable sudo .
How users interact with devices in Linux Socket file (or network listener) Device File Your program not owned by root Owned by root inside the Kernel Owned by root owner-writable only owned by root world-writable User process Service (daemon) Device Driver
How users interact with services in Linux Socket file (or network listener) Your program not owned by root Owned by service owned by service world-writable Service (daemon) User process
How users interact with Apache in Linux Network Listener Inter-process pipe Your program not owned by root Spawns a new process and changes owner to Apache Communicates back to Apache for logging etc owned by root Service (daemon) User process
Linux Layers: SELinux 3 Modes: Disabled Permissive Enforcing If permissive or enforcing, violations are logged via the auditd and typically sent to /var/log/audit/audit.log. Special programs are needed to intepret these. Each file and process has one or more labels which describe a security context. Policy files are rules which dictate which operations a process in one context may perform on a file or process with another context. Special programs are needed to modify policies, rules, options within rules, label files. Opinion: Only the most stable systems should use enforcing. Otherwise, you need to invest significant time in learning how to adapt the rules and policies to your system. Opinion: Policies that are too open will be easier to maintain, but may give a false sense of security.
Network Layers Organization Border Firewall Datacenter Firewall Proxy Server's Firewall (iptables) Proxy Server Rules (rewrite, modsecurity) Application server's Firewall Application server's Rules (rewrite, modsecurity, <location>) Application
Networking Control: The Basics We are mostly concerned about TCP, UDP and ICMP connections. Every TCP and UDP network packet contains a 2x2 tuple: Source-address and source-port Destination-address and destination-port TCP is a stateful protocol. A connection exists on of several discreet states. Each packet should either conform to the current state or set a flag indicating the beginning of a transition to a new state. There are 3 main flags: SYN, ACK, and FIN. Others are RST, URG, PSH. TCP and UDP packets may arrive out of order, and thus each packet has a number in a sequence, and each direction has its own sequence ICMP comprises a source address, destination address, a request-type, and a request payload.
Networking Control Thus, a process may listen to a particular IP address (or 0.0.0.0 for all ), on a particular port number and service-type (UDP or TCP). We can control and observe which processes are listening to which tuple. If a process is listening only on the localhost interface (127.0.0.1 or ::::1), then only processes on that host may connect to it. However, special rules within iptables may redirect network activity from the outside to the internal port For TCP, we can also control which packets to accept by the state the connection is in
Monitoring and Auditing Monitoring and Auditing: security is nearly pointless unless you also do this . Bare minimum: monitor operational items Server uptime Service reachability Application readiness Application logging ! Access-denied Program exceptions Periodic auditing A yearly (at least!) review if the layers are all intact and function as intended New features, temporary exceptions , environmental changes lead to rotten layers Periodic security scanning and pen-testing Storage usage CPU usage Network usage System events Cron/Job events
Practical Intro for Web-Service Systems Managing the file/process layer: Unix ownership and permissions Managing the network layer: IPTables / FirewallD Dynamically managing the network layer in response to attacks: Fail2ban modsecurity (Apache) How-to SE-Linux Intrusion-detection tools and scanners
Managing the networking layer : IPTables Layer / Slice #1: Reduce Surface-Attack area Create holes and exceptions judiciously Close *outbound* connections whenever possible Use IPsets for flexibility Log non-conforming packets We do all of the above with Puppet, but could do more.
