Grundlegende Systemadministration

Transkript

1 Grundlegende Systemadministration unter Linux, bei RPM-basierten Systemen (SUSE, RedHat, CentOS, Mandriva): Installation, Netzwerkeinrichtung, Sicherheit Tom Rüger 1

2 Installation von Linux Warum Beschränkung auf RPM-basierte Systeme? Es gibt zu viele unterschiedliche Distributionen mit zu vielen unterschiedlichen Konzepten, um auf alle eingehen zu können. RPM-basierend (SUSE, RedHat, Fedora, CentOS, Mandriva, Ark-Linux, Turbolinux ) Debian-basierend (Debian GNU/Linux, Corel Linux, Knoppix, Ubuntu ) Gentoo-basierend (Gentoo, Knopperdisk, Calculate Linux ) Pacman-basierend (ArchLinux, DeLi-Linux ) Tom Rüger 2

3 Installation von Linux Die Installation wird im Folgenden ausführlich an zwei Beispielen gezeigt: CentOS 5 (das RedHat Enterprise Linux entspricht) und SUSE Enterprise Linux 11-SP Tom Rüger 3

4 Installation von Linux Prinzipiell gibt es die Möglichkeit, von lokaler Installations-DVD oder über das Netzwerk (Network-boot CD) zu installieren. Im Folgenden beschränken wir uns auf die lokale Installation Tom Rüger 4

5 Installation von CentOS-Linux Tom Rüger 5

12 Installation von CentOS-Linux Sinnvollerweise partitioniert man: / root Filesystem 2GB (6GB*) swap swap space phys. Mem. /var variable files 4GB /usr universal system resources 20 GB optional: /tmp temporary files 4GB* /home user files Tom Rüger 12

13 Installation von CentOS-Linux Wenn Fremdzugriff auf die Konsole besteht, sollte man ein Bootloader-Passwort verwenden! Tom Rüger 13

29 Installation von CentOS-Linux SELinux sollte nur bei erhöhten Sicherheitsanforderungen aktiviert werden, da dadurch viele normale Operationen verhindert werden Tom Rüger 29

38 Installation von SUSE-Linux Enterprise Server Tom Rüger 38

49 Installation von SUSE-Linux Enterprise Server Bei der Standardpartitionierung wird alles in die / -Partition installiert, das ist nicht sehr sinnvoll Wenn die Konsole des Systems Fremden zugänglich ist, dann sollte ein Bootloader- Passwort gesetzt werden Tom Rüger 49

90 Installation von SUSE-Linux Enterprise Server An der Eingabeaufforderung (als root ) müssen zum Beziehen der Updates nun folgende Befehle eingegeben werden: # wget no-check-certificate # chmod u+x clientsetup.sh #./clientsetup11.sh # suse_register Nach diesem Schritt sollte der Erlanger Update-Server eingetragen sein: # zypper sl # Alias Name Aktiviert Aktualisierung Typ SMT-https_smt_rrze_uni-erlange_de SMT-https_smt_rrze_uni-erlangen_de Ja Nein ris 2 SUSE-Linux-Enterprise-Server-11-SP1 SUSE-Linux-Enterprise-Server-11-SP1 Ja Nein yast Tom Rüger 90

91 Installation von SUSE-Linux Enterprise Server Im Anschluss werden die passenden Repos ermittelt: # zypper refs Dienst SMT-https_smt_rrze_uni-erlangen_de wird aktualisiert. Alle Dienste wurden aktualisiert. Überprüfen, ob die Repos korrekt eingetragen sind: # zypper ca # Alias Name Aktiviert Aktualisierung SMT-https_smt_rrze_uni-erlangen_de:SLE11-SP1-Debuginfo-Pool SLE11-SP1-Debuginfo-Pool Nein Ja 2 SMT-https_smt_rrze_uni-erlangen_de:SLE11-SP1-Debuginfo-Updates SLE11-SP1-Debuginfo-Updates Nein Ja 3 SMT-https_smt_rrze_uni-erlangen_de:SLE11-WebYaST-SP1-Pool SLE11-WebYaST-SP1-Pool Nein Ja 4 SMT-https_smt_rrze_uni-erlangen_de:SLE11-WebYaST-SP1-Updates SLE11-WebYaST-SP1-Updates Nein Ja 5 SMT-https_smt_rrze_uni-erlangen_de:SLES11-Extras SLES11-Extras Nein Ja 6 SMT-https_smt_rrze_uni-erlangen_de:SLES11-SP1-Pool SLES11-SP1-Pool Ja Ja 7 SMT-https_smt_rrze_uni-erlangen_de:SLES11-SP1-Updates SLES11-SP1-Updates Ja Ja 8 SUSE-Linux-Enterprise-Server-11-SP SUSE-Linux-Enterprise-Server-11-SP1 Ja Nein Danach können die ersten Updates installiert werden: # zypper update Danach befindet sich das System auf dem aktuellen Stand Tom Rüger 91

92 Installation von Linux Die Installation der anderen RPM-basierten Linux Distributionen: Fedora Core, RedHat Enterprise Linux, Mandriva, OpenSUSE läuft analog ab Tom Rüger 92

93 Sofern noch nicht bei der Installation geschehen, muss jetzt die Netzwerkkarte und Firewall konfiguriert werden. Hierbei muss für die Netzwerkkarte die zugeteilte statische IP-Adresse, sowie Netzmaske, default Router und DNS-Nameserver eingetragen werden. Einrichten des Netzwerks Tom Rüger 93

94 Einrichten des Netzwerks Dies geschieht bei CentOS, Fedora, RHEL im KDE unter Administration -> Netzwerk bzw. Administration -> Sicherheitsstufe und Firewall (Aussehen der Menüs kann sich von Version zu Version leicht unterscheiden) Tom Rüger 94

95 Einrichten des Netzwerks RHEL, CentOS, Fedora Tom Rüger 95

98 Einrichten des Netzwerks Bei OpenSUSE und SLES erfolgt die Konfiguration über YAST: Tom Rüger 98

99 Einrichten des Netzwerks OpenSUSE und SLES Tom Rüger 99

101 Sicherheit durch regelmäßige Aktualisierungen des Systems Eine gute Angriffsfläche bieten lange laufende, schlecht gewartete Systeme, auf denen keine Updates eingespielt werden! Sicherheitslücken unter LINUX sind in der gesamten einschlägigen Szene bekannt. => Regelmäßige Sicherheitsupdates minimieren das Risiko, Ziel eines erfolgreichen Angriffs zu werden und machen Hacker und Cracker unglücklich! SuSE, Fedora, RHEL und CentOS-Systeme sind standardmäßig für automatische Updates konfiguriert Tom Rüger 101

102 Aktualisierungen des Systems Für Updates werden folgende Programme verwendet: CentOs und RHEL: yum, pirut, pup (Package Updater, graph. Frontend zu yum) Fedora: yum, PackageKit SLES, OpenSUSE: yum, zypper, YaST Die Package Updater lassen sich über die Kommandozeile starten (yum), aber auch das grafische Interface (Gnome oder KDE) aufrufen Kommandozeile: # yum update Tom Rüger 102

103 Aktualisierungen des Systems - yum [root@btr0x71 root]# yum update Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * addons: mirror.atrpms.net * base: mirror.atrpms.net * extras: mirror.atrpms.net * updates: mirror.atrpms.net Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package glibc.i686 0: el5_5.2 set to be updated : ---> Package strace.i386 0: el5_5.5 set to be updated ---> Package sudo.i386 0:1.7.2p1-7.el5_5 set to be updated --> Running transaction check ---> Package tzdata-java.i386 0:2010i-1.el5 set to be updated --> Finished Dependency Resolution Dependencies Resolved ================================================================ ==== Package Arch Version Repository Size ================================================================ ==== Updating: glibc i el5_5.2 updates 5.3 M : strace i el5_5.5 updates 172 k sudo i p1-7.el5_5 updates 230 k Installing for dependencies: tzdata-java i i-1.el5 updates 176 k Transaction Summary =============================================================== Install 1 Package(s) Upgrade 20 Package(s) Total download size: 230 M Is this ok [y/n]: y Downloading Packages: (1/21 glibc-common el5_5.2.i386.rpm 16 MB 00:01 : (20/21): strace el5_5.5.i386.rpm 172 kb 00:00 (21/21): sudo-1.7.2p1-7.el5_5.i386.rpm 230 kb 00: Total 7.0 MB/s 230 MB 00:33 Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Updating : glibc-common 1/41 : Updating : glibc-devel 20/41 Cleanup : perl 21/41 : Cleanup : glibc 41/41 Dependency Installed: tzdata-java.i386 0:2010i-1.el5 Updated: glibc.i686 0: el5_5.2 : strace.i386 0: el5_5.5 sudo.i386 0:1.7.2p1-7.el5_5 Complete! Tom Rüger 103

104 Aktualisierungen des Systems Fedora: KPackageKit Tom Rüger 104

105 Aktualisierungen des Systems CentOS und RHEL: Package Updater Tom Rüger 105

106 Aktualisierungen des Systems SuSE: YaST Tom Rüger 106

107 Absichern des Systems gegen Angriffe von außen - Paketinstallation Die meisten Distributionen bieten Standardinstallationen an, die die entsprechend auf die gewünschte Systemart (Workstation, Server,...) abgestimmten Pakete installieren. Grundsätzlich nur benötigte Pakete installieren. Officesystem ohne Netzwerktools Workstation ohne zusätzliche Netzwerkdienste (apache, BIND- Server, FTP-Server...) Server ohne Entwicklungsumgebung Nötigenfalls manuelle Nachbearbeitung der Paketauswahl, um Abhängigkeiten von Paketen zu erfüllen Tom Rüger 107

108 Absichern des Systems gegen Angriffe von außen - Dienste Werden Serverdienste installiert, müssen sie auch konfiguriert werden. Unkonfigurierte Dienste stellen oft eine Sicherheitslücke dar! Keine unnötigen Dienste installieren, d.h. die Installation von www-, ftp-, telnet-, mail-, lpd-serverdiensten sollte nur dann erfolgen, wenn sie auch benötigt werden. Verwenden der "moderneren" Dienste und Pakete Ersetzen der "r"-dienste durch "s"-dienste für interaktiven Remotezugang: ssh statt rsh, rlogin, telnet zum Filetransfer: sftp bzw. scp statt ftp bzw. rcp Benutzen von cups oder LPRng statt lpr/lpd Einsatz von exim oder postfix oder qmail statt sendmail Wurden unnötige Dienste (Daemonen) installiert, so sollten sie deaktiviert werden Tom Rüger 108

109 Absichern des Systems gegen Angriffe von außen Konfiguration von Diensten CentOS 5.5: Administration Servereinstellungen Dienste Tom Rüger 109

110 Absichern des Systems gegen Angriffe von außen Konfiguration von Diensten Fedora 13: Administration Dienste Tom Rüger 110

111 Absichern des Systems gegen Angriffe von außen Konfiguration von Diensten SLES 11 und OpenSUSE: YaST Tom Rüger 111

112 Absichern des Systems gegen Angriffe von außen - Konfiguration Früher hat man Systeme über Einträge in /etc/hosts.allow und /etc/hosts.deny gegen Zugriffe geschützt. Dies ist mit der Verwendung der viel mächtigeren Firewall eigentlich nicht mehr nötig. Die Konfiguration der Firewall erfolgt entweder über das graphische Interface, das Kommandozeilen-interface (system-config-securitylevel (nur SLES, CentOS, Fedora)) oder direkt in der Datei /etc/sysconfig/iptables Tom Rüger 112

113 Einrichten des Netzwerks Die Firewall sollte aus Sicherheitsgründen aktiviert sein und nur die Ports freigegeben werden, die benötigt werden. Beispiele: SSH Erreichbarkeit des Rechners von außen für interaktive Sitzungen und sicheren Filetransfer (Sicheres) WWW für Web-Server Samba für Dateiserver für Windows-Rechner Tom Rüger 113

114 Absichern des Systems gegen Angriffe von außen - Konfiguration # Firewall configuration written by system-config-securitylevel # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :RH-Firewall-1-INPUT - [0:0] -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p 50 -j ACCEPT -A RH-Firewall-1-INPUT -p 51 -j ACCEPT -A RH-Firewall-1-INPUT -p udp --dport d j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT Tom Rüger 114

115 Absichern des Systems gegen Angriffe von außen Konfiguration der Firewall unter CentOS Tom Rüger 115

117 Absichern des Systems gegen Angriffe von außen Firewallkonfiguration unter SuSE: YaST Tom Rüger 117

118 Absichern des Systems - Passwörter Es sollten grundsätzlich sichere Passwörter verwendet werden Keine Namen von Freund/in oder Haustieren Ein Mix aus Groß- und Kleinbuchstaben, sowie Zahlen und Sonderzeichen Hilfreich kann es sein, sich Passwörter aus Sätzen zu bauen: Beispiel: Nehmen wir den Satz: Ich habe bei meiner Doktorarbeit nicht abgeschrieben Davon die ersten Buchstaben der Wörter: IhbmDna Zusätzlich tauschen wir das i gegen eine 1 und das a aus: Wir erhalten: 1hbmDn@ So ein Passwort ist durch Probieren nicht zu knacken, wenn man den ursprünglichen Satz, aus dem es entstanden ist, nicht kennt. Selbst kann man es sich aber leicht jederzeit wieder herleiten Tom Rüger 118

119 Absichern des Systems - Passwörter Das Passwort für root sollte nur den Leuten bekannt sein, die es unbedingt benötigen und wissen, was sie tun. Wenn Benutzer nur einzelne privilegierte Kommandos ausführen müssen, so können sie das über das Kommando # sudo <Befehl> Berechtigte Benutzer und die Kommandos, die sie als root ausführen dürfen, können über die Datei /etc/sudoers konfiguriert werden An der Grafikkonsole sollte man sich immer als normaler Benutzer einloggen, niemals als root Tom Rüger 119

120 Absichern des Systems - Passwörter Im /etc/password alle non-login-accounts sichern kein Account ohne Password alle mit ungültiger login-shell, z.b. /bin/false, /sbin/nologin als Shell Shadow-Passwords verwenden (pwconv) (sollte mittlerweile Standard sein!) # cat /etc/passwd root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin adm:x:3:4:adm:/var/adm:/sbin/nologin lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/var/spool/mail:/sbin/nologin news:x:9:13:news:/etc/news:/bin/false ftp:x:14:50:ftp User:/var/ftp:/sbin/nologin nobody:x:99:99:nobody:/:/bin/false apache:x:48:48:apache:/var/www:/sbin/nologin xfs:x:43:43:x Font Server:/etc/X11/fs:/sbin/nologin amanda:x:33:6:amanda user:/var/lib/amanda:/bin/bash btr011:x:911:109:t. Rueger,,,:/home/btr0/btr011:/bin/tcsh btr019:x:919:109:b. Winkler,,,:/home/btr0/btr019:/bin/tcsh btr029:x:929:109:h. Kolinsky,,,:/home/btr0/btr029:/bin/tcsh Tom Rüger 120

121 Absichern des Systems - Zugriffsrechte Setuid-Bits von Programmen entfernen, die nie gebraucht werden oder normale Benutzer nicht ausführen können sollen Beispiele: /bin/ping /bin/mount /usr/bin/suidperl /usr/sbin/traceroute root-account sollte aktuelles Verzeichnis aus Sicherheitsgründen nie im Pfad haben! Sichere Defaultwerte umask in den Loginskripten für Benutzer setzen (umask 022 <-> u:rwx, g:rx, o:rx) für root umask 077 (Keine Rechte für group oder others) Tom Rüger 121

122 Absichern des Systems - Zugriffsrechte Schreibrechte für Benutzer, nur wo diese nötig sind: $HOME $MAIL /tmp ( sticky -bit!: chmod 1777 /tmp) Keine Schreibrechte für Benutzer, wo diese unnötig sind: Systemverzeichnisse (/, /bin, /etc, /usr/bin...) Systemdateien (/etc/passwd, /etc/shadow, /etc/group...) /dev (außer tty) Jedes Zugriffsbit birgt potentielle Risiken: Bit read write exec suid sgid sticky mögliche Probleme Lesen sensitiver Daten Verändern sensitiver Daten Ausführen von unerlaubtem Code Rechteübername (z.b. von root) Rechteübername einer Gruppe (z.b. mem) Möglicher Schreibzugriff auf Daten anderer, Symlinkattacken Tom Rüger 122

123 Absichern des Systems - Zugriffsrechte Empfehlung zum Umgang mit Zugriffsrechten: Keine SUID-root-Skripte Möglichst wenige SUID-Binaries (insb. root) Möglichst wenige SGID-Binaries SUID möglichst auf einen anderen User als root Binaries in den Systemordnern gehören im Zweifelsfall root/root Regelmäßige Kontrolle von Zugriffsrechten: Suche nach Dateien mit SUID-Bit: # find / -perm print Suche nach Dateien mit SGID-Bit: # find / -perm print Abgleich der Liste mit gespeicherter Liste, u.u. über cron Tom Rüger 123

124 Absichern des Systems Suche nach Ungereimtheiten Einen zusätzlichen Schutz gegen Angriffe auf das System erreicht man mit Tools, die einen vor Veränderungen warnen: Programme wie tripwire, scanlogd, logcheck lassen frühzeitig Angriffe erkennen. Programmpakete wie OpenVAS (OpenSource Vulnerability Assessment Scanner, früher GNessUs, (letzte Version: 4.0 vom ) und SARA (Security Auditor's Research Assistant, (letzte Version: 7.9.2a vom ) helfen, Sicherheitslücken nach außen zu erkennen Tom Rüger 124

125 Absichern des Systems Suche nach Ungereimtheiten Hat man den Verdacht, dass sich bereits Unberechtigte Zugang verschafft haben, kann man mit chkrootkit ( sein System auf etwaige rootkits überprüfen und backdoors finden. Sollte man hier ein Sicherheitsproblem feststellen, muss man im Anschluss an die Reinigung auf jeden Fall die Passwörter (zumindest das root-passwort ändern. Sicherer (aber leider nicht immer machbar) ist in diesem Fall allerdings eine Neuinstallation Tom Rüger 125

126 Absichern des Systems Keinen wirklichen Schutz gibt es aber gegen Angriffe von Leuten, denen root -Rechte gegeben worden sind! Tom Rüger 126