Linux
Linux Befehle und Grundlagen
Linux Befehle und Grundlagen
-
- 1 / 64
-
Flashcards
POSIX ACL Filesystem Permissions
▪ Grund: Die klassischen Unixrechte erlauben nur Unterscheidung der Zugriffsrechte für den Besitzer, die besitzende Gruppe und Anderen ("other"). Will man genau einer weiteren Person Rechte auf eine Datei erteilen, muss man eine Gruppe anlegen, in der genau die Benutzer enthalten sind, die die Rechte bekommen sollen. Für jede gewünschte Kombination von Benutzern benötigt man also eine eigene Gruppe, was unpraktikabel ist. ▪ ACLs erlauben die Rechtevergabe an folgende Parteien: ▪ genau ein Besitzer ▪ benannte Benutzer ▪ genau eine besitzende Gruppe ▪ benannte Gruppe ▪ Andere ▪ ACL’s werden via Extended Attributes im Filesystem gespeichert (xattr). Es wird von den meisten Linux Filesystemen unterstützt (Ext, JFS, ReiserFS, XFS..) ▪ setfacl und getfacl werden benutzt um ACL zu setzen und zu lesen ▪ Es gibt Default (auf neue Kinderobjekte, statt umask) und Access (auf Files/Directories) ACLs ▪ Das + Zeichen bei einem ls deutet an, dass ACL Permissions gesetzt sind: drwxrwx--x+ 2 mimsand mimsand 4096 2010-06-01 13:43 daten/
setfacl (Setzen von ACLs
getfacl (anzeigen von ACLs)
Lesen von ACL Berechtigungen:
▪ Die mask sagt welche permissions maximal gesetzt sind. Die mask beeinflusst alle ACL’s ausser die standard user und standard other Berechtigungen. Die entgültigen Permissions werden mit einer AND Kombination aus den standard user permissions und der mask berechnet:
▪ Beispiel: ▪ drwxr-x--x 2 mimsand mimsand 4096 2010-06-01 13:43 daten/
▪ setfacl -m user:testuser:rwx daten
▪ setfacl -m group:testgroup:rwx daten
Zugriffsrechte Linux: Wie sind die verschiedenen Dateien gekennzeichnet?
- Reguläre (normale) Datei
d Verzeichnis (directory)
l Symbolischer Link (symlink)
b Blockorientierte Gerätedatei (block device)
c Zeichenorientierte Gerätedatei (character device)
p Feste Programmverbindung (named pipe)
s Netzwerk Kommunikationsendpunkt (socket)
Disk - Einbindung
▪ Einbinden von Filesystemen
▪ mount: Einbinden von Filesystemen mount /dev/vdb1 /mnt/mydata mount UUID="a23f21-48adc-23da318-92712-saf3a" /mnt/mydata
▪ umount: Aushängen von Filesystemen
▪ UUID (Universally Unique Identifier ) ▪ Blkid: Anzeigen der Diskliste inklusive unique identifier
Disk - Partitionierung ▪ MBR
Der Master Boot Record ist ein Startprogramm mit Partitionstabelle für BIOS-basierte Computer. Er befindet sich im ersten Sektor einer Partitionen. Kann Festplatten bis 2TB adressieren. Das Startprogram Master Boot Code (LILO, GRUB), sucht in der Partitionstabelle nach „sichtbaren“ und „aktiven“ Partitionen und lädt anschließend den Bootsektor der ersten aktiven Partition und führt diesen aus.
▪ fdisk: Wird für die Partitionierung nach MBR Standard verwendet
Disk - Partitionierung GPT
GUID Partition Table (GPT), ist wie MBR ein Standard für das Format von Partitionstabellen. Die Spezifikation ist Teil des UEFI-Standards, der zunehmend das BIOS ersetzt. GPT ist dabei der Nachfolger der Master-Boot-Record-Partitionstabellen. ▪ gdisk: Wird für die Partitionierung nach GPT Standard verwendet ▪ fdisk: Kann ebenfalls verwendet werden, jedoch ist hier GPT nur experimentell unterstütz
Filesysteme ▪ Filesystem anlegen
▪ mkfs –t <type> <partition> • ext3 • ntfs • vfat • xf
Logical Volume Management
LVM legt sich als logische Schicht zwischen die physischen Datenträger oder Partitionen und das Dateisystem.
Vorteile von LVM ▪ Flexible Kapazitäten ▪ Änderung der Grösse ▪ Reallokierung von Daten im laufenden Betrieb ▪ Disk Striping / Mirroring ▪ Volume Snapshots ▪
Nachteile von LVM ▪ Alte Grub-Versionen können nicht auf LVM’s zugreifen (Nicht LVM Boot Partition notwendig). Grub2 hat diese Einschränkung nicht mehr ▪ Grösserer Overhead.und höhere Komplexität
▪ Das LVM-System basiert auf drei Schichten:
▪ Physical Volume (PV)
• Block Devices
• Initialisierung notwendig damit LVM das PV nutzen kann, d.h.
- • Metadaten
- • Einteilung in Physical Extents (PE)
▪ Volume Group (VG)
• Bestehend aus einem oder mehreren PV’s
• Einteilung in Logical Extents (LE)
▪ Logical Volume (LV)
• VG werden in ein oder mehrere LVs aufgeteilt
• LV können auf 3 Arten angelegt werden
- • Linear Volumes
- • Stripped Volumes (vgl. Raid 0)
- • Mirrored Volumes (vgl. Raid 1)
Um ein LV zu generieren sind folgende Schritte notwendig:
▪ Initialisierung der physikalischen Disk damit sie vom LVM System erkannt wird
- • fdisk: Id muss 8e sein.
- • pvcreate /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1
- Preparieren der Partition für LVM (Chunks (PE), Metadaten)
▪ Generierung einer Volume Group
- • vgcreate fileserver /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1
- Anlegen einer VG über physikalische Devices
▪ Generierung eines Logischen Volumes basierend aus einer VG
- • lvcreate --name share --size 40G fileserver
- lvcreate --name backup --size 5G fileserver
- lvcreate --name media --size 1G fileserver
Anlegen eines LV über einer VG
▪ Filesystem anlegen
- • mkfs.ext3 /dev/fileserver/share
- Ein Filesystem auf das Logische Volume legen
▪ Mounten vom LV
- • mount /dev/fileserver/share /var/share
NFS
NFS (Network File System) ist ein Internet Stardard Protokoll welches von *nix Systemen verwendet wird um Filesysteme über das Netzwerk zugänglich zu machen.
Es gibt verschiedene Arten wie NFS shares eingebunden werden können
▪ Manuell via mount Befehl
▪ Automatisch via /etc/fstab
▪ On demand via automounting
SMB
SMB (Server Message Block) oder CIFS (Common Internet File System) wurde ursprünglich von Windows Betriebssystem genutzt und ist wie NFS ein Protokoll um auf entfernte Dateisysteme (und Print Services) zuzugreifen.
RPM (Redhat Package Manager)
▪ RPMs werden in vielen Linux-Distributionen benutzt, z.B.
▪ Red Hat
▪ Fedora Core
▪ Scientific Linux
▪ SuSE
▪ Mandriv
Der Name eines Paketes setzt sich aus dem eigentlichen Namen, der Version und dem Release zusammen: <name>-<version>-<release>.<architecture> ▪ bash-3.0-19.2.i386.rpm
Es gibt zwei RPM Typen
▪ Binary (plattformgebunden und enthalten direkt ausführbare Programme)
▪ Source (Sourcecode, der erst noch compiliert werden muss. Inkl SPEC File => Bauanleitung
YUM (yellowdog updater, modified)
Yum bietet:
▪ Infos über installierte und verfügbare RPM-Pakete
▪ Installation von RPM-Paketen inkl. abhängiger Paket
▪ Deinstallation inkl. abhängiger Pakete
▪ automatisches Paket-Update (inkl. abhängiger Pakete)
▪ Upgrade des Systems von Minor-Release auf nächst höheres Minor-Release
Redhat Subscription Manager / Repos
RHEL benutzt den subscription-manager Command um RH eigene Repositories zu verwalten.
▪ Das Nutzen von RH Channels setzt eine gültige Subscription / Lizenz voraus
subscription-manager register --username <username> --password <password> --auto-attach
Package Manager Repository
subscription-manager repos --list Liste alle verfügbaren RH-Repositories auf
subscription-manager repos --enable <repoid> Aktiviert ein spezifisches RH-Repository (Channel)
Monitoring und Logging
Systemparameter überwachen
▪ Prozesse
▪ ps
▪ kill
▪ Memory
▪ free
▪ Network
▪ ip –s link show eth0
▪ Netstat, ss
▪ CPU
▪ top
▪ IO
▪ Vmstat
▪ Allgemein
▪ /proc Filesystem
Logging Services können auf 3 verschiedene Arten Logs schreiben:
Direkt Eigene log-engine (z.B.: apache / samba) (meist nach /var/log)
▪ Rsyslogd Nachfolger von syslogd. Service für zentrale Log-Ablage
▪ Journald Integration via systemd.
Die beiden standard Logging System von RHEL
▪ rsyslogd ▪ Konfiguration via /etc/rsyslog.conf ▪ Meldungen werden kategorisiert • Facility (Kategorie, nicht erweiterbar) • Priority (severity, gelogged werden alle Nachrichten mit gleicher oder höherer Prio) • Destination (Zieldatei für das Logging) ▪ Gespeichert in /var/log/* ▪ Manuelle Syslog Nachrichten können via logger generiert werden. (zum Testen) ▪ systemd-journald ▪ Verbesserter Log Management Service um Nachrichten vom Kernel (auch während Boot) entgegegen zu nehmen ▪ Kein Erstatz für rsyslogd (nur eine andere Implementation mit anderen Fähigkeiten) ▪ Benutzt ein strukturiertes Journal (Binary) um Nachrichten zu speichern ▪ Normale Syslog Meldungen werden an den rsyslogd weitergeschickt. ▪ journalctl um system journal anzuzeigen ▪ Standardmässig nach /run/log/journal (flüchtig) Wenn vorhanden nach /var/log/journal (permanent)
Logfiles Analysieren
Nagios ▪ OpenSource Monitoring System um Host Resouces via Web Interface zu monitoren. Via Nagios Remote Plugin Executor (NRPE) stehen Agents (Targets) zu Verfügung um Remote Hosts zu überwachen. Es können Alarme integriert werden welche bei gewissen Bedingungen generiert werden sollen ▪ Nagios setzt auf einem LAMP (Linux, Apache, MySQL/MariaDB, PHP) Stack auf. ▪ Die Installation von Nagios kann mit YUM (RPM) oder "from Source" gemacht werden.
Iptables
▪ Kann mit dem Kommando iptables auf der Kommandozeile administriert werden ▪ Implementiert das komplette Set von Firewall Rules und Funktionalitäten die notwendig sind ▪ Die Schwächen sind: ▪ Z.T. komplexe CLI Befehle und Syntax ▪ Die Reihenfolge von Rules kann sehr komplex und fehleranfällig sein ▪ Ist auf RHEL7 noch verfügbar sollte aber nicht mehr verwendet werden
Firewalld
▪ Setzt ebenfalls auf netfilter auf ▪ Hat verschiede Konfigurationsinterfaces ▪ Via CLI ▪ Applikationen können via DBUS Rules hinzufügen • Automatisierung • Keine Aufwände für SysAdmin ▪ Tipp: Verwende systemctl mask iptables um iptables permenent zu deaktivieren damit nicht versehentlich trotzdem verwendet wird.
Firewalld im Detai
▪ Zones: ▪ Eine Zone ist eine Sammlung von Rules welche auf incoming Packets angewendet werden (angewendet auf Source oder NIC). ▪ Wichtig für Servers welche mehrere NIC haben ▪ Bei nur einem Interface kann meist die default Zone verwendet werden ▪ Jedes incoming Packet wird analysiert und einer spezifischen Zone zugewiesen. Falls keine spezielle Zone passt, wird die default Zone verwendet. Es gibt folgende default Zonen: • Block • DMZ • Drop • External • Home • Internal • Public • Trusted • Work
Services ▪ Nicht wie ein normaler systemd Server ▪ Firewalld besteht aus mehreren Services (es gibt einige Default Services). Dies ermöglicht dem SysAdmin schnell gewisse Rules zu aktivieren. ▪ Hinter jedem Service steckt ein Config File.
DAC Sicherheitskonzept
▪ Mit File Permissions oder ACL kann nur DAC (Discretionary Access Control ) gemacht werden ▪ Das Problem: DAC schränkt nur den File Zugriff von Benutzern ein. User / Programme / Prozesse usw. können nicht kontrolliert werden. Z.B: ▪ Ein User setzt world readable permissions auf sensitive Daten (z.b. ssh Keys). Der Administrator hat keine Möglichkeit dies zu verbieten. ▪ Prozesse können Sicherheitseinstellungen ändern. Mail Client Software hat die Möglichkeit auf Systemweiter Ressoucen und Files zuzugreifen. ▪ Ein Prozess erbt User-Rechte. Wenn z.B. firefox-bin kompromitiert wird hat er die Möglichkeit Private ssh keys des jeweiligen Users zu lese
MAC Sicherheitskonzept
▪ SELinux verfolgt das Least-privilege Prinzip. => Strict Policy Enforcment ▪ Stanardmässig ist alles denied ▪ Mit speziellen Exception-Policies werden gewissen Elementen (Service, Program oder User) Zugriff auf das System erlaubt. ▪ Denies werden gelogged. ▪ Applikationen müssen nicht speziell geschrieben werden um mit SELinux zu funktionieren. Sie benötigen nur entsprechende Policies
SELinux Modes
▪ Es gibt 3 Betriebsmodi:
▪ Enforcing Default Modus.
SELinux ist aktiviert.
▪ Permissive SELinux ist aktiviert, verstösse werden aber nur gelogged und nicht geblocked.
▪ Disabled SELinux ist deaktiviert.
▪ Befehle: ▪ Setenforce, getenforce
▪ Config File: ▪ /etc/selinux/confi
SELinux Policy
▪ SELinux kann mit verschiedenen Policies arbeiten. ▪ Die default Policy ist targeted (it targets and confines selected system processes) Alle Services welche nicht targeted sind laufen unter der unconfined domain und sind nicht von SELinux geschützt ▪ Das Ziel ist es, das jeder Prozess in einer confined domain läuft.
SELinux Access Control
▪ SELinux hat 3 Formen von Access Control ▪ Type Enforcement (TE): Ist der primäre Mechanismus für Access Control und wird von der targeted Policy genutzt
▪ Role-Based Access Control (RBAC): Basiert auf SELinux user (nicht unbedingt die gleichen wie Linux Benutzer), wird aber nicht von der targeted Policy genutzt
▪ Multi-Level Security (MLS): Nicht oft verwendet (auch nicht in der targeted Policy