New Methods of Forensic Memory Analysis and Acquisition

Total Page:16

File Type:pdf, Size:1020Kb

New Methods of Forensic Memory Analysis and Acquisition All your System Memory are belong to us: From Low-Level Memory Acquisition to High-Level Forensic Event Reconstruction Von Hauptspeicherakquise auf niedriger Systemebene zu forensischer Ereignisrekonstruktion auf hoher Abstraktionsebene Der Technischen Fakultät der Friedrich-Alexander-Universität Erlangen-Nürnberg zur Erlangung des Doktorgrades Dr.-Ing. vorgelegt von Tobias Latzo aus Forchheim Als Dissertation genehmigt von der Technischen Fakultät der Friedrich-Alexander-Universität Erlangen-Nürnberg Tag der mündlichen Prüfung: 09.07.2021 Vorsitzender des Promotionsorgans: Prof. Dr.-Ing. habil. Andreas P. Fröba Gutachter: Prof. Dr.-Ing. Felix Freiling Prof. Dr. rer. nat. Hans P. Reiser Abstract This thesis comprises two parts. In the first part, we unveil the limitations of forensic event reconstruction with log files. To enhance forensic event reconstruction, we use system call traces treated as log files. System call traces are gained via virtual machine introspection, which analyzes the target system’s memory. System memory analysis, in general, has evolved into an essential part of today’s forensic investigations. For this, memory needs to be acquired first, becoming more difficult with upcoming system security features. Hence, the second part of this thesis is dedicated to memory acquisition techniques. First, we survey the landscape of forensic memory acquisition techniques. Then we introduce new low-layer memory acquisition techniques and tools. In the first part of this thesis, we calculate characteristic fingerprints for various typical Linux administration-related events. We use different standard log files, and additionally, we make use of system call traces. While these turn out to be beneficial for event detection, they have a significant impact on performance. Hence, we research which system callsare discriminative and improve performance by only tracing relevant ones. The second part of this thesis is dedicated to low-level memory acquisition techniques starting with a universal taxonomy and survey. On the one side, the survey reveals, the lower the memory acquisition technique’s layer, the better. On the other side, only a few tools do run “below” the operating system. In the further course of the thesis, four techniques are introduced that do operate on low layers. All techniques come with pros and cons and have their particular use cases. Our first two techniques are integrated into the computer’s firmware. UEberForensIcs acquires memory from the UEFI Shell. To acquire memory, one needs to restart the system and open the UEFI Shell. System memory is exfiltrated over the network. Another approach is to hook UEFI’s Runtime Services that are called by the target’s operating system. The third technique we introduce makes use of Direct Memory Access (DMA). We leverage the high capabilities of Baseboard Management Controllers (BMCs), which are standard in remote administration servers. With BMCLeech we introduce stealthy memory acquisition from the BMC via Direct Memory Access (DMA) that is compatible with the memory forensic tool PCILeech. Eventually, we use the little-known Intel Direct Connect Interface (DCI) to acquire system memory via JTAG debugging. This approach is beneficial in terms of atomicity and integrity of the resulting memory image. DCILeech is also compatible with PCILeech and so benefits from all its features. Additionally, we show how to read the secured memoryof Intel SGX enclaves. i Zusammenfassung Diese Arbeit besteht aus zwei Teilen. Im ersten Teil zeigen wir die Grenzen der forensischen Ereignisrekonstruktion mit Logdateien auf. Um die forensische Ereignisrekonstruktion zu verbessern, verwenden wir Systemaufrufspuren, die als Logs behandelt werden. System- aufrufspuren werden über Virtual Machine Introspection gewonnen, eine Technik, die den Speicher des Zielsystems analysiert. Generell hat sich die Analyse des Systemspeichers zu einem wesentlichen Bestandteil der heutigen forensischen Untersuchungen entwickelt. Hierfür muss zunächst der Speicher akquiriert werden, was durch zunehmende Systemsicher- heitsfeatures schwieriger geworden ist. Daher ist der zweite Teil dieser Arbeit den Techniken zur Hauptspeicherakquise gewidmet. Zunächst geben wir einen Überblick über existie- rende Techniken. Anschließend stellen wir neue Speicherakquisetechniken auf niedriger Systemebene vor. Im ersten Teil dieser Arbeit berechnen wir charakteristische Fingerabdrücke für verschiede- ne typische Ereignisse im Zusammenhang mit der Linux-Administration. Wir verwenden verschiedene Standard-Logdateien. Zusätzlich machen wir Gebrauch von Systemaufruf- spuren. Diese erweisen sich zwar als hilfreich für die forensische Ereignisrekonstruktion, haben aber einen erheblichen Einfluss auf die Performance. Daher untersuchen wir, welche Systemaufrufe diskriminierend sind und verbessern die Performance, indem wir nur die relevanten tracen. Der zweite Teil dieser Arbeit widmet sich den Low-Level-Speicherakquisetechniken, be- ginnend mit einer universellen Taxonomie und einem Survey. Auf der einen Seite zeigt das Survey, dass die Speicherakquisetechniken umso besser sind, je tiefer die Ebene ist, auf der sie ausgeführt werden. Andererseits gibt es nur wenige Tools, die “unterhalb” des Betriebssystems ausgeführt werden. Im weiteren Verlauf der Arbeit werden vier Techniken vorgestellt, die auf niedrigen Schichten arbeiten. Alle Techniken haben ihre Vor- und Nachteile und ihre speziellen Anwendungsfälle. Unsere ersten beiden Techniken werden in die Firmware des Computers integriert. UE- berForensIcs sichert Speicher von der UEFI Shell. Um Speicher zu sichern, muss man das System neu starten und die UEFI Shell öffnen. Der Systemspeicher wird über das Netzwerk exfiltriert. Ein anderer Ansatz ist das Hooking der UEFI Runtime Services, die vom Betriebssystem des Zielsystems aufgerufen werden. Die dritte Technik nutzt direkten Speicherzugriff (DMA). Wir nutzen die hoch-privilegierte Anbindung von Baseboard Management Controllern (BMCs), die es für Fernwartung für Server gibt. Mit BMCLeech führen wir eine verdeckte Speicherakquise vom BMC über DMA ein, die mit dem Speicherforensik-Tool PCILeech kompatibel ist. Schließlich nutzen wir das wenig bekannte Intel Direct Connect Interface (DCI), um Systemspeicher über JTAG-Debugging zu sichern. Dieser Ansatz ist vorteilhaft in Bezug auf Atomarität und Integrität des Speicherabbilds. DCILeech ist auch mit PCILeech kompatibel und profitiert so von allen seinen Funktionen. Zusätzlich zeigen wir, wieman den gesicherten Speicher von Intel SGX- Enklaven auslesen kann. ii Acknowledgments I would like to thank my doctoral advisor Felix Freiling for offering me to work with him at his Chair for IT-Security Infrastructures at the Department of Computer Science at the FAU Erlangen-Nuremberg, his time for various project meetings, and his continuous support. I also want to thank all my colleagues at the Chair for a friendly and casual working atmosphere, especially Ralph Palutke for discussing countless research ideas and nonsense. I also have to thank my friends and especially my girlfriend Sarah for being the precious “life” in my work-life balance. Last but not least, I want to thank my parents for their encouragement and incessant support of my dissertation project as well as my entire studies. iii Contents 1 Introduction 1 1.1 Outline ...................................... 2 1.2 Contribution ................................... 4 1.3 Publications.................................... 7 2 Background 9 2.1 Calculating Characteristic Fingerprints..................... 9 2.1.1 System Call Tracing........................... 9 2.1.2 Forensic Fingerprint Calculation .................... 9 2.2 Methods for Privilege Separation........................ 10 2.2.1 Privilege Rings.............................. 10 2.2.2 Virtual Memory ............................. 11 2.2.3 Virtualizable Architectures and Virtualization Extensions . 12 2.2.4 Unified Extensible Firmware Interface................. 12 2.2.5 System Management Mode ....................... 13 2.2.6 PCI Express and DMA ......................... 13 2.2.7 Hardware Memory Encryption and Intel SGX............. 14 2.2.8 Out-Of-Band Management ....................... 15 2.2.9 JTAG Debugging............................. 15 2.3 Memory Forensics ................................ 16 3 Limitations of Forensic Event Reconstruction based on Log Files 19 3.1 Experimental Setup ............................... 20 3.1.1 Scenario and Attacker Model ...................... 20 3.1.2 Log Source Classification ........................ 21 3.1.3 Experimental Architecture........................ 22 3.1.4 Feature Sets................................ 23 3.1.5 Events and Event Classification..................... 25 3.2 Forensic Fingerprints............................... 25 3.2.1 Handling Background Noise....................... 27 3.2.2 Non-Characteristic Fingerprints..................... 28 3.2.3 Characteristic Fingerprints ....................... 29 3.3 Matching ..................................... 32 3.3.1 Methodology ............................... 33 3.3.2 Matching Results............................. 33 v Contents 3.3.3 Stability against Unknown Events ................... 35 3.4 System Calls for Forensic Event Reconstruction................ 36 3.4.1 System Call Distribution in System Activity and Characteristic Fingerprints................................ 37 3.4.2 The Cost Function............................ 38 3.4.3 Greedy Elimination of Expensive System Calls ...........
Recommended publications
  • 2015 Open Source Yearbook
    Opensource.com/yearbook . ........ OPENSOURCE.COM ................... Opensource.com publishes stories about creating, adopting, and sharing open source solutions. Visit Opensource.com to learn more about how the open source way is improving technologies, education, business, government, health, law, entertainment, humanitarian efforts, and more. Submit a story idea: https://opensource.com/story Email us: [email protected] Chat with us in Freenode IRC: #opensource.com Twitter @opensourceway: https://twitter.com/opensourceway Google+: https://plus.google.com/+opensourceway Facebook: https://www.facebook.com/opensourceway Instagram: https://www.instagram.com/opensourceway FROM THE EDITOR ............................. Dear Open Source Yearbook reader, The “open source” label was created back in 1998, not long after I got my start in tech publishing [1]. Fast forward to late 2014, when I was thinking about how much open source technologies, commu- nities, and business models have changed since 1998. I realized that there was no easy way—like a yearbook—to thumb through tech history to get a feel for open source. Sure, you can flip through the virtual pages of a Google search and read the “Best of” lists collected by a variety of technical publications and writers, much like you can thumb through newspapers from the 1980s to see the how big we wore our shoulder pads, neon clothing, and hair back then. But neither research method is particularly efficient, nor do they provide snapshots that show diversity within communities and moments of time. The idea behind the Open Source Yearbook is to collaborate with open source communities to collect a diverse range of stories from the year.
    [Show full text]
  • Practical Migration to Linux on System Z
    Front cover Practical Migration to Linux on System z Overview and migration methodology Migration analysis Hands-on migration case study Lydia Parziale Joseph Apuzzo Saulo Augusto M Martins da Silva Louis Henderson Manoj Srinivasan Pattabhiraman Richard Sewell ibm.com/redbooks International Technical Support Organization Practical Migration to Linux on System z October 2009 SG24-7727-00 Note: Before using this information and the product it supports, read the information in “Notices” on page xi. First Edition (October 2009) This edition applies to z/VM Version 5.3 and Version 5.4, Novell SUSE Linux Enterprise Server Version 10 and Version 11, and Red Hat Enterprise Linux Version 5.3. © Copyright International Business Machines Corporation 2009. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . xi Trademarks . xii Preface . xv The team who wrote this book . xv Become a published author . xviii Comments welcome. xviii Part 1. Overview and migration methodology . 1 Chapter 1. Migration considerations . 3 1.1 Reason to migrate systems. 4 1.1.1 How green is your data center . 4 1.1.2 The IBM Big Green server consolidation . 7 1.2 Benefits of migrating to Linux on System z . 7 1.3 Reasons to select Linux on System z . 9 1.3.1 System z strengths . 10 1.3.2 Value of Linux on System z. 12 1.3.3 Choosing workloads to migrate to IBM System z . 13 1.4 z/VM virtualization for Linux on IBM System z .
    [Show full text]
  • Pipenightdreams Osgcal-Doc Mumudvb Mpg123-Alsa Tbb
    pipenightdreams osgcal-doc mumudvb mpg123-alsa tbb-examples libgammu4-dbg gcc-4.1-doc snort-rules-default davical cutmp3 libevolution5.0-cil aspell-am python-gobject-doc openoffice.org-l10n-mn libc6-xen xserver-xorg trophy-data t38modem pioneers-console libnb-platform10-java libgtkglext1-ruby libboost-wave1.39-dev drgenius bfbtester libchromexvmcpro1 isdnutils-xtools ubuntuone-client openoffice.org2-math openoffice.org-l10n-lt lsb-cxx-ia32 kdeartwork-emoticons-kde4 wmpuzzle trafshow python-plplot lx-gdb link-monitor-applet libscm-dev liblog-agent-logger-perl libccrtp-doc libclass-throwable-perl kde-i18n-csb jack-jconv hamradio-menus coinor-libvol-doc msx-emulator bitbake nabi language-pack-gnome-zh libpaperg popularity-contest xracer-tools xfont-nexus opendrim-lmp-baseserver libvorbisfile-ruby liblinebreak-doc libgfcui-2.0-0c2a-dbg libblacs-mpi-dev dict-freedict-spa-eng blender-ogrexml aspell-da x11-apps openoffice.org-l10n-lv openoffice.org-l10n-nl pnmtopng libodbcinstq1 libhsqldb-java-doc libmono-addins-gui0.2-cil sg3-utils linux-backports-modules-alsa-2.6.31-19-generic yorick-yeti-gsl python-pymssql plasma-widget-cpuload mcpp gpsim-lcd cl-csv libhtml-clean-perl asterisk-dbg apt-dater-dbg libgnome-mag1-dev language-pack-gnome-yo python-crypto svn-autoreleasedeb sugar-terminal-activity mii-diag maria-doc libplexus-component-api-java-doc libhugs-hgl-bundled libchipcard-libgwenhywfar47-plugins libghc6-random-dev freefem3d ezmlm cakephp-scripts aspell-ar ara-byte not+sparc openoffice.org-l10n-nn linux-backports-modules-karmic-generic-pae
    [Show full text]
  • Security Features of VOLTTRON™ Distributed Sensing and Control Platform (2017)
    PNNL-26560 Security Features of VOLTTRON™ Distributed Sensing and Control Platform (2017) June 2017 BA Akyol JN Haack CH Allwardt KE Monson MC Roup PNNL-SA-26560 Security Features of VOLTTRON™ Distributed Sensing and Control Platform (2017) BA Akyol JN Haack CH Allwardt KE Monson MC Roup June 2017 Prepared for the U.S. Department of Energy under Contract DE-AC05-76RL01830 This document updates PNNL-SA-106580. Pacific Northwest National Laboratory Richland, Washington 99352 Contents 1.0 Introduction ....................................................................................................................................... 1.1 2.0 VOLTTRON Security Philosophy .................................................................................................... 2.2 3.0 Threat Model ..................................................................................................................................... 3.5 4.0 Summary of VOLTTRON Security Features .................................................................................. 4.15 i Introduction VOLTTRON™1 enables rapid authoring and secure deployment of autonomous software agents for distributed sensing and controls. It is designed to be as secure as possible to meet desired security objectives; however, no software can be 100 percent secure and useful at the same time. Therefore, VOLTTRON uses a threat model approach for determining threats and vulnerabilities of the software and to reasonably reduce the attack surface and/or harm endured after a compromise. VOLTTRON
    [Show full text]
  • List of TCP and UDP Port Numbers - Wikipedia, the Free Encyclopedia List of TCP and UDP Port Numbers from Wikipedia, the Free Encyclopedia
    8/21/2014 List of TCP and UDP port numbers - Wikipedia, the free encyclopedia List of TCP and UDP port numbers From Wikipedia, the free encyclopedia This is a list of Internet socket port numbers used by protocols of the Transport Layer of the Internet Protocol Suite for the establishment of host-to-host connectivity. Originally, port numbers were used by the Network Control Program (NCP) which needed two ports for half duplex transmission. Later, the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) needed only one port for bidirectional traffic. The even numbered ports were not used, and this resulted in some even numbers in the well-known port number range being unassigned. The Stream Control Transmission Protocol (SCTP) and the Datagram Congestion Control Protocol (DCCP) also use port numbers. They usually use port numbers that match the services of the corresponding TCP or UDP implementation, if they exist. The Internet Assigned Numbers Authority (IANA) is responsible for maintaining the official assignments of port numbers for specific uses.[1] However, many unofficial uses of both well-known and registered port numbers occur in practice. Contents 1 Table legend 2 Well-known ports 3 Registered ports 4 Dynamic, private or ephemeral ports 5 See also 6 References 7 External links Table legend Use Description Color Official Port is registered with IANA for the application[1] White Unofficial Port is not registered with IANA for the application Blue Multiple use Multiple applications are known to use this port. Yellow Well-known ports The port numbers in the range from 0 to 1023 are the well-known ports or system ports.[2] They are used by system processes that provide widely used types of network services.
    [Show full text]
  • VOLTTRON Documentation Release 5.0.2
    VOLTTRON Documentation Release 5.0.2 The VOLTTRON Developer Team Apr 20, 2018 Contents 1 Features 3 2 Background 5 3 Installation 7 4 Next Steps 9 5 Acquiring Third Party Agent Code 11 6 Contribute 13 7 Support 15 7.1 License.................................................. 15 Python Module Index 437 i ii VOLTTRON Documentation, Release 5.0.2 VOLTTRONTM is an open-source platform for distributed sensing and control. The platform provides services for collecting and storing data from buildings and devices and provides an environment for developing applications that interact with that data. Contents 1 VOLTTRON Documentation, Release 5.0.2 2 Contents CHAPTER 1 Features Out of the box VOLTTRON provides: • a secure message bus allowing agents to subcribe to data sources and publish results and messages. • secure connectivity between multiple instances. • BACnet, ModBus and other device/system protocol connectivity through our driver framework for collecting data from and sending control actions to buildings and devices. • automatic data capture and retrieval through our historian framework. • platform based agent lifecycle managment. •a web based management tool for managing several instances from a central instance. • the ability to easily extend the functionality of existing agents or create new ones for your specific purposes. 3 VOLTTRON Documentation, Release 5.0.2 4 Chapter 1. Features CHAPTER 2 Background VOLTTRONTM is written in Python 2.7 and runs on Linux Operating Systems. For users unfamiliar with those technologies, the following resources are recommended: • https://docs.python.org/2.7/tutorial/ • http://ryanstutorials.net/linuxtutorial/ 5 VOLTTRON Documentation, Release 5.0.2 6 Chapter 2.
    [Show full text]
  • VOLTTRON Documentation Release 3.5RC1
    VOLTTRON Documentation Release 3.5RC1 The VOLTTRON Developer Team June 30, 2016 Contents 1 Installation 3 1.1 Source Code...............................................3 1.2 Bootstrap.................................................3 1.3 Activate..................................................3 1.4 Testing..................................................4 1.5 Execution.................................................4 1.6 Next Steps................................................4 2 License 5 3 Community Resources 7 3.1 Community Resources..........................................7 4 Overview 9 4.1 Definition of Terms............................................9 4.2 Platform Background...........................................9 4.3 Platform Components.......................................... 10 4.4 Agents in the Platform.......................................... 10 4.5 VOLTTRON Version History...................................... 11 5 VOLTTRON Core Services 13 5.1 Base Platform Functionality....................................... 13 5.2 VOLTTRON Historian Framework................................... 19 5.3 VOLTTRON Driver Framework..................................... 25 5.4 VOLTTRON Message Bus........................................ 43 5.5 Service Agents.............................................. 61 5.6 VOLTTRON Security.......................................... 85 5.7 VOLTTRON PNNL Licensed Code................................... 86 6 Developer Resources 91 6.1 Getting Started.............................................. 91
    [Show full text]
  • Nikolai Lifanov 919.348.0211 [email protected]
    Nikolai Lifanov 919.348.0211 [email protected] Summary: Linux/Unix engineer familiar with development, with over a decade of experience building and ​ ​ supporting automated and reliable infrastructures for the web with focus on security, virtualization, data, and storage and strong affinity for open source Skills: Unix Operating Systems: FreeBSD, NetBSD, DragonFly ​ ​ Linux Distributions: Amazon Linux, CentOS, Debian, Gentoo, Arch Linux ​ ​ Microsoft: used Active Directory, IIS 7, Windows XP, Windows 7, Windows 10, Windows Server 2003 ​ ​ RedHat: Katello, Satellite, kickstart (Cobbler), yum, RPM packaging and deployment ​ ​ Systems Programming: expert shell programming (sh, csh, bash, ksh); understand awk, C ​ ​ Software Programming: PHP, Perl, used Common Lisp, Clojure; used Qt with C++; understand Java ​ ​ DevOps: Jenkins, Terraform, Packer, Vagrant, Vault, Consul, Fastlane ​ ​ Virtualization: strong Xen, Citrix XenServer, VMWare vSphere, Jails, bhyve, Docker, VirtualBox, KVM, Zones ​ ​ Cloud: Amazon Web Services; some Google App Engine, familiar with OpenStack ​ ​ Configuration Management: Ansible, Salt Stack, CFengine 3, CFEngine 2 ​ ​ Firewalls: prefer pf; used iptables, ipfw ​ ​ Monitoring: Netdata, Prometheus, Xymon, Nagios (Icinga), Graylog ​ ​ Web: Apache httpd, nginx, Tomcat, Squid, Varnish, Solr ​ ​ Mail: Postfix, Sendmail, Dovecot, Procmail, deliverability, spam management ​ ​ Database: MySQL (MariaDB, Percona and tools), Galera Cluster, PostgreSQL, Redis, and some exposure to Oracle ​ ​ Storage: NetApp, S3, Amazon EFS,
    [Show full text]
  • VOLTTRON Documentation Release 5.0-Rc2
    VOLTTRON Documentation Release 5.0-rc2 The VOLTTRON Developer Team Jan 03, 2018 Contents 1 Features 3 2 Background 5 3 Installation 7 4 Next Steps 9 5 Acquiring Third Party Agent Code 11 6 Contribute 13 7 Support 15 7.1 License.................................................. 15 Python Module Index 423 i ii VOLTTRON Documentation, Release 5.0-rc2 VOLTTRONTM is an open-source platform for distributed sensing and control. The platform provides services for collecting and storing data from buildings and devices and provides an environment for developing applications that interact with that data. Contents 1 VOLTTRON Documentation, Release 5.0-rc2 2 Contents CHAPTER 1 Features Out of the box VOLTTRON provides: • a secure message bus allowing agents to subcribe to data sources and publish results and messages. • secure connectivity between multiple instances. • BACnet, ModBus and other device/system protocol connectivity through our driver framework for collecting data from and sending control actions to buildings and devices. • automatic data capture and retrieval through our historian framework. • platform based agent lifecycle managment. •a web based management tool for managing several instances from a central instance. • the ability to easily extend the functionality of existing agents or create new ones for your specific purposes. 3 VOLTTRON Documentation, Release 5.0-rc2 4 Chapter 1. Features CHAPTER 2 Background VOLTTRONTM is written in Python 2.7 and runs on Linux Operating Systems. For users unfamiliar with those technologies, the following resources are recommended: • https://docs.python.org/2.7/tutorial/ • http://ryanstutorials.net/linuxtutorial/ 5 VOLTTRON Documentation, Release 5.0-rc2 6 Chapter 2.
    [Show full text]
  • Administración Avanzada Del Sistema Operativo GNU Linux Módulo5 Sintonización, Optimización Y Alta Disponibilidad.Pdf
    Sintonización, optimización y alta disponibilidad Remo Suppi Boldrito PID_00238613 GNUFDL • PID_00238613 Sintonización, optimización y alta disponibilidad Índice Introducción .......................................................... 5 Objetivos ............................................................... 7 1. Sintonización, optimización y alta disponibilidad .......... 9 1.1. Aspectos básicos .............................................. 9 1.1.1. Monitorización sobre UNIX System V ................ 10 1.2. Test de rendimiento (Benchmark) .............................. 17 1.2.1. Optimización del sistema ............................. 19 1.2.2. Optimizaciones de carácter general ................... 22 1.2.3. Configuraciones complementarias ................... 24 1.2.4. Resumen de acciones para mejorar un sistema ....... 28 1.3. Monitorización ............................................... 30 1.3.1. Munin ................................................ 31 1.3.2. Monit ................................................ 33 1.3.3. SNMP + MRTG ....................................... 34 1.3.4. Nagios ................................................ 38 1.3.5. Ganglia ............................................... 42 1.3.6. Cacti.................................................. 44 1.3.7. Otras herramientas ................................... 45 1.4. Alta disponibilidad en Linux (High-Availability Linux) ......... 46 1.4.1. Guía simple clúster con Heartbeat para HA con Apache 47 1.4.2. Clúster HA con Corosync+Pacemaker y Nginx ....... 49 1.4.3.
    [Show full text]
  • Debian-Paketmanagement
    Debian-Paketmanagement Axel Beckert und Frank Hofmann Onyx Neon Debian-Paketmanagement ii Copyright © 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021 Axel Beckert, Frank Hofmann Das Buch "Debian-Paketmanagement" von Frank Hofmann und Axel Beckert ist lizenziert unter einer Creative Commons Na- mensnennung - Weitergabe unter gleichen Bedingungen 4.0 International Lizenz. Debian-Paketmanagement iii VERSIONSGESCHICHTE NUMMER DATUM BESCHREIBUNG NAME debian/0_2021.03.01- 2021-09- 42-g5ca0d33 17T23:18:06+00:00 Debian-Paketmanagement iv Inhaltsverzeichnis I Konzepte 1 1 Willkommen im Linux-Dschungel! 2 1.1 Was ist Debian?....................................................2 1.2 Debian-Architekturen.................................................3 1.2.1 Debian-Ports-Projekt.............................................3 1.2.2 Pakete für alle Architekturen.........................................4 1.2.3 Multiarch: Mehrere Architekturen gleichzeitig auf einem System......................4 1.2.4 Bevor es Multiarch gab............................................5 1.3 Vom tar.gz zur Linux-Distribution........................................5 1.4 Debians Paketsystem.................................................5 1.5 Welche UNIX-artigen Betriebssysteme verwenden das Paketformat und das APT-Paketmanagement.......6 2 Software in Paketen organisieren 7 2.1 Was ist Paketmanagement...............................................7 2.2 Varianten und Formate für Softwarepakete......................................8 2.3 Softwarestapel und Ebenen..............................................9
    [Show full text]
  • Local Service Monitoring Status of Linux Operating Systems
    MASARYK UNIVERSITY FACULTY OF INFORMATICS Local service monitoring status of Linux operating systems BACHELOR THESIS Jakub Svoboda Brno, Spring 2012 Declaration Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Jakub Svoboda Advisor: Mgr. Pavel Tuˇcek ii Acknowledgement I’d like to thank to my advisor Mgr. Pavel Tuˇcekfor patiency, guidance, invaluable assistance and encouragement. I’d also like to thank to Jan Koneˇcnýfor programming advices in the course of designing the application. iii Abstract Theoretical part of the thesis analyzes methods of monitoring Linux operating system and monitoring requirements of the Institute of Computer Science. In the practical part of the thesis, Linux monitoring application is designed and implemented. The application is developed as a part of ICS’ Large Enterprise Monitoring (Lemon) project. iv Keywords Linux, monitoring, Mono, Lemon, LinMon v Contents 1 Introduction ....................................... 1 2 Operating system monitoring in general ...................... 2 2.1 Operating system purpose ............................ 2 2.2 Reliability of operating system ......................... 2 2.3 Reasons for monitoring .............................. 3 2.4 Existing GNU/Linux-compatible solutions .................. 3 2.4.1 SYSSTAT . 4 2.4.2 Dstat . 4 2.4.3 vmstat . 4 2.4.4 Collectd . 4 2.4.5 Munin . 5 2.4.6 Nagios, Shinken and Icinga . 5 2.4.7 PCP . 5 2.4.8 Xymon . 5 3 System monitoring at the Institute of Computer Science ............. 7 3.1 Lemon project ..................................
    [Show full text]