Nach dem Start eines neu installierten Redhat-Desktops ({Fedora, CentOS}) gibt es im Gnome-Panel ein nerviges Redhat-Icon, dass eigentlich warnen soll, wenn nicht alle verfügbaren Updates installiert wurden. Allerdings funktionierte dieses Icon bei mir nicht richtig und ließ sich per GUI auch nicht deaktivieren.
Wenn man darüberhinaus auch nur yum (statt up2date) zur Systemaktualisierung verwendet, kann man das ganze Icon direkt entfernen. Dafür genügt der Befehl yum remove rhnlib.
Kürzlich habe ich fünf Compaq Deskpro EN SFF P733 (Small Form Factor) günstig erstanden. Hierbei handelt es sich um besonders kleine Rechner (etwa halb so groß wie ein Midi-Tower), die auch halbwegs leise sind. Leider sind Compaq-Biose schon eine Geschichte für sich: Früher wurde das Compaq-Bios z.B. auf einer Festplatten-Partition gespeichert. Austausch der Festplatte hieß Neu-Installation des BIOS.
Meine Rechner wollte ich jetzt "headless" laufen lassen, d.h. ohne Tastatur, Maus oder Monitor. Problem hierbei ist nur, dass die Rechner nicht starten wollen, wenn keine Tastatur angeschlossen ist. Und der Workaround gestaltet sich wieder einmal echt Compaq-like:
Prinzipiell gibt es im Bios eine Option "Netzwerk-Boot", deren Aktivierung bewirkt, dass der Rechner auch ohne angeschlossene Tastatur startet. Allerdings wird diese Option nur angezeigt, wenn das Passwort beim Systemstart aktiviert ist...
Daher gibt es folgendes Vorgehen:
Regelmäßige und vollständige Backups sind der einzige wirkungsvolle Schutz gegen Datenverlust. Für Firmen und Selbstständige ist Datensicherung überlebensnotwendig. Ein Festplatten-Crash kann hier binnen Sekunden eine mühsam aufgebaute Existenz zerstören. Was aber, wenn das Vorhandensein von Backups selbst zum Problem wird?
In einer Datensicherung sind eigentlich immer viele eigentlich geheime bzw. private Daten enthalten: Rechnungen, Bilanzen, Mails, Passwörter. Entsprechend muss man auch die Sicherungsmedien (z.B. Magnetbänder, Festplatten usw.) mindestens genauso schützen wie die eigentlichen Systeme, auf denen die Daten im Normalbetrieb aufbewahrt werden.
Da aber Backupmedien häufiger transportiert bzw. oft auch schlecht geschützt werden, werden Backups zum Ziel von Datendieben. Zwei Vorfälle aus jüngster Zeit demonstrieren die Risiken, denen Backups ausgesetzt sind:
Ein interessanter Ansatz, um Backups zu schützen, ist Verschlüsselung: Die gesicherten Daten werden mit erprobten Verfahren verschlüsselt (z.B. AES, RSA, ...). Ein Diebstahl des Backups ist nicht weiter dramatisch, weil es keine Möglichkeit gibt, an die eigentlichen Daten heranzukommen, ohne den Schlüssel zu besitzen. Bei asymmetrischer Verschlüsselung (z.B. RSA) kann der geheime Schlüssel auch nur auf einem externen Medium wie z.B. USB-Stick oder SmartCard gespeichert werden, was die Sicherheit weiter erhöht.
Bacula (www.bacula.org) ist eine Sammlung von Open Source-Programmen, um Datensicherung und -wiederherstellung in einem möglicherweise heterogenen Netzwerk zu verwalten. Natürlich werden die üblichen Backup-Medien wie Bandlaufwerke und Festplatten sowie Bandroboter unterstützt.
Durch das modulare Design skaliert das System von einzelnen Rechnern bis zu großen Netzwerken mit hunderten Systemen. Im Unterschied zu anderen Programmen wird bei Bacula auf jedem zu sichernden System eine Clientsoftware installiert. Dadurch können mehr Metadaten gesichert werden (ACLs, Streams bzw. Ressource Forks auf Windows/MacOS X) als z.B. bei einer SMB- oder NFS-Freigabe (obwohl auch das natürlich möglich ist). Außerdem können auch plattformspezifische Erweiterungen wie z.B. Volume Shadow Copy (ab Windows XP) verwendet werden. Über Bacula gab es auch im Linux-Magazin kürzlich einen ausführlichen Artikel.
Bislang gibt es in Bacula noch nicht die Möglichkeit, Backups zu verschlüsseln. Landon Fuller hat sich bereit erklärt, dieses Feature in Bacula zu implementieren, allerdings unter der Vorbedingung, dass 3000 US-$ an die Electronic Frontier Foundation (www.eff.org) gespendet werden. Bislang sind 2970 $ zusammengekommen. Der aktuelle Stand der Spendensammlung ist natürlich auch online dokumentiert.
Landon Fuller hat bereits die TLS-Verschlüsselung der Kommunikation zwischen den Bacula-Daemons implementiert. Einige Design-Überlegungen für das Data Encryption Project finden sich auf der Bacula-Users-Mailingliste. Weiterhin gibt es bereits erste Patches von ihm, obwohl die 3000 $ noch nicht zusammengekommen sind.
Ich möchte daher dazu aufrufen, das Projekt (und die EFF) zu unterstützen. Wie das genau geht, ist bei Sourceforge dokumentiert.
Leider ist für die Spende eine Kreditkarte bzw. Paypal notwendig. Wer spenden möchte, aber keine Kreditkarte besitzt, sollte sich auf jeden Fall trotzdem erst mal bemerkbar machen (bacula-users Mailingliste oder bei mir unter Felix.Schwarz@web.de), dann findet sich bestimmt eine Möglichkeit.
Bacula is a set of computer programs that permits you (or the system administrator) to manage backup, recovery, and verification of computer data across a network of computers of different kinds. Bacula can also run entirely upon a single computer, and can backup to various types of media, including tape and disk.
In technical terms, it is a network Client/Server based backup program. Bacula is relatively easy to use and efficient, while offering many advanced storage management features that make it easy to find and recover lost or damaged files. Due to its modular design, Bacula is scalable from small single computer systems to systems consisting of hundreds of computers located over a large network.
Quelle: http://www.bacula.org/dev-manual/What_is_Bacula.html
Imagine a world where technology can empower us all to share knowledge, ideas, thoughts, humor, music, words and art with friends, strangers and future generations.
That world is here and now, made possible with the electronic network -- the Internet -- with the power to connect us all. And future developments in technology will enable us to access information and communicate with others in even more powerful ways.
But governments and corporate interests worldwide are trying to prevent us from communicating freely through new technologies, just as when those in positions of power controlled the production and distribution of -- or even burned -- books they did not want people to read in the Middle Ages. But only by fighting for our rights to speak freely whatever the medium -- whether books, telephones, or computers -- can we protect and enhance the human condition.
The Electronic Frontier Foundation (EFF) was created to defend our rights to think, speak, and share our ideas, thoughts, and needs using new technologies, such as the Internet and the World Wide Web. EFF is the first to identify threats to our basic rights online and to advocate on behalf of free expression in the digital age.
Quelle: http://www.eff.org/about/
Derzeit nutze ich TheBat!, allerdings würde ich gerne auf ein Open-Source-Programm wechseln, dass auch problemlos unter Linux läuft.
Essentielle Anforderungen:
Nice-to-have:
Derzeit ist Thunderbird mein Favorit in der Hinsicht, allerdings wird erst Enigmail 1.0 meine PGP-Anforderungen erfüllen.
XAMS ist ein System, um Mailaccounts auf einem Mailserver zu verwalten. Eigentlich ein ganz nettes System, insbesondere mit der Site-Funktionalität.
XAMS teilt sich in mehrere Teile:
Exim ist toll. Courier konnte ich bereits durch dovecot ersetzen. Die MySQL-Datenbank ist okay, auch wenn PostGreSQL ein paar nette Features hätte. Die Perl-Skripte sind recht schmerzfrei und werden selten gebraucht.
Mein Problem ist das Webinterface und zwar insbesondere:
Ich würde gerne das Webinterface mit ordentlicher Technologie neu schreiben, damit die o.g. Mängel der Vergangenheit angehören.
Prinzipielles Vorgehen:
Templates und i18n gehören natürlich zum Pflichtprogramm. Schön wäre auch eine prinzipielle DB-Unabhängigkeit.
Prinzipiell geht es hier nicht um das Einrichten einer selbsterstellten Pseudo-CA, sondern nur um das Generieren eines Zertifikats bzw. genauer um das Generieren eines certificate signing requests.
Mittels
/usr/share/ssl/misc/CA -newreq (Fedora < 8) bzw. /etc/pki/tls/misc/CA -newreq (ab Fedora 8)
wird ein neuer geheimer Key und ein signing request erstellt. Standardmäßig ist beides zusammen in der Datei newreq.pem. Daraus kopiert man den signing request in eine neue Datei. Diese wird dann an eine CA zur Signierung übergeben (z.B. CAcert oder für allgemein anerkannte Zertifikate auch PSW). Den Key kopiere ich auch immer in eine eigene Datei. Aus Sicherheitsgründen sollte man diese Datei natürlich nur für root lesbar machen ("chown root.root <datei>", "chmod 0400 <datei>}").
Wenn man diesen Schlüssel jetzt aber auf einem Server installiert, hat man das Problem, dass bei jedem Start das Passwort eingegeben werden muss. Ist natürlich etwas sicherer, aber letztlich für einen Internetserver unpraktikabel. Daher kann man das Passwort mittels
/usr/bin/openssl rsa -in server.bak -out server.key
deaktivieren.
Alternativ zur obigen Vorgehensweise kann man auch zuerst mit folgendem Befehl nur den geheimen Schlüssel generieren:
/usr/bin/openssl genrsa 2048 > server.key
und dann anschließend die CSR-Datei wie unten dargestellt berechnen lassen.
Die CSR-Datei kann man jederzeit aus dem privaten Schlüssel neu erstellen, z.B. wenn ein Zertifikat verlängert werden soll und man die ursprüngliche CSR-Datei nicht mehr hat.
-sha1 führt bei einigen CAs dazu, dass sie ein mit SHA1 signiertes Zertifikat ausstellen. Solche Zertifikate werden veraussichtlich ab 2016 von den Browsern nur noch eingeschränkt als "sicher" angesehen. Daher empfiehlt sich die Verwendung eines moderneren Hashing-Verfahrens (z.B. mittels -sha256.
openssl req -new -sha1 -key server.key -out server.csr
Allerdings ist es durchaus zu empfehlen, den private Key auch mal neu zu generieren, wenn eh ein neues Zertifikat ausgestellt werden muss.
Ab und an braucht man auf einem Rechner mehrere IP-Adressen, z.B. um verschiedene Domains mit jeweils einem eigenen SSL-Zertifikat zu sichern. Die Einrichtung weiterer IP-Adressen ist eigentlich ganz einfach:
Alle nötigen Konfigurationen finden sich (zumindest unter Fedora Core) in /etc/sysconfig/network-scripts. Interessant ist hier v.a. die ifcfg-eth0. Diese wird in eine neue Datei kopiert (z.B. ifcfg-eth0:1). In dieser Datei ersetzt man dann anschließend IP-Adresse und netmask.
Um die Konfiguration zu aktivieren, reicht ein "ifup eth0:1". Natürlich sollte man nicht vergessen, anschließend noch den Paketfilter anzupassen.
Eine Vorlage für diesen Text war Binding Multiple IP Address on RedHat Linux....
Mittels su können normale Benutzer root-Rechte erhalten, wenn sie das root-Passwort kennen. Nachdem bereits ein root-Login per SSH deaktiviert wurde, ist eine weitere Sicherheitsmaßnahme, ein su nur für bestimmte Benutzer zu erlauben. Alle anderen Benutzer können su nicht benutzen (selbst wenn sie das korrekte root-Passwort kennen).
Diese Maßnahme führt nicht prinzipiell zu mehr Sicherheit, sondern ist als zusätzliche line of defense gedacht. Angenommen, ein Angreifer erhält über eine fahrlässig programmierte Webanwendung shell-Zugriff unter der User-ID eines Webkunden, hat er trotzdem keine Möglichkeit, dass root-Passwort zu erraten und für ein su zu benutzen, weil der Webkunde keine su-Berechtigung hat. Natürlich bietet ein Shell-Zugang für einen Angreifer immer noch genügend Möglichkeiten (lokal ausnutzbare Sicherheitslücken im Linux-Kernel), aber immerhin ist ein einfacher Weg dem Angreifer verwehrt.
Ich habe folgenden Weg gewählt:
Es gibt eine spezielle Gruppe admins, in die alle Benutzer aufgenommen werden, die su benutzen können sollen (Anlegen der Gruppe mit "groupadd admins", Hinzufügen von Benutzern mit "usermod -G admins <benutzername>").
Anschließend muss die Datei /etc/pam.d/su um die beiden folgenden Zeilen erweitert werden:
auth sufficient /lib/security/$ISA/pam_stack.so service=su-admins auth required /lib/security/$ISA/pam_deny.so
Bei mir sieht sie dann etwa so aus:
#%PAM-1.0 auth sufficient /lib/security/$ISA/pam_rootok.so # Uncomment the following line to implicitly trust users in the "wheel" group. #auth sufficient /lib/security/$ISA/pam_wheel.so trust use_uid # Uncomment the following line to require a user to be in the "wheel" group. #auth required /lib/security/$ISA/pam_wheel.so use_uid auth required /lib/security/$ISA/pam_stack.so service=system-auth auth sufficient /lib/security/$ISA/pam_stack.so service=su-admins auth required /lib/security/$ISA/pam_deny.so (...)
Anschließend wird die Datei /etc/pam.d/su-admins angelegt (Dateirechte 0600!), die nur die folgende Zeile beinhaltet:
auth sufficient /lib/security/pam_wheel.so group=admins trust
Jetzt dürfte kein Benutzer, der nicht in der Gruppe admins eingetragen ist, mehr in der Lage sein, mittels su root-Rechte zu bekommen.
Hinweis: Bei dieser Konfiguration hat mir Securing Linux Production Systems - A Practical Guide to Basic Security in Linux Production Environments von Werner Puschitz sehr geholfen.
Nach der Erst-Installation von Fedora miste ich das System erst mal aus.
Gerade Server werden nur selten gebootet und wenn man dann nach drei Monaten wegen eines kritischen Kernel-Updates mitten in der Mittagszeit schnell einen Neustart machen muss, die Maschine aber anschließend wegen des fscks noch eine Stunde offline bleibt, ist das sehr ärgerlich. Daher mittels "tune2fs -c 0 -i 0 <device>" alle checks abschalten. Natürlich muss man jetzt ab und an mal manuell prüfen, aber das kann man dann wenigstens einplanen und so gestalten, dass es niemanden stört.
Zum sicheren System gehören die Updates, daher kommen die jetzt dran.
Die devel- und updates-testing-Versionen haben auf einem Produktivsystem keinen Platz, daher werden sie sofort gelöscht (fedora-devel.repo und fedora-updates-testing.repo in /etc/yum.repos.d/).
Wenn interne Fedora-Mirrors verfügbar sind, setze ich die baseurl in fedora.repo und fedora-updates.repo entsprechend.
Dummerweise ist GPG-Überprüfung der Pakete zwar standardmäßig aktiviert, der entsprechende GPG-Key
fehlt jedoch. Er ist u.a. auf der Fedora-CD enthalten (RPM-GPG-KEY-fedora) und auch online verfügbar. Mittels rpm --import <GPG-file> kann man den Schlüssel jedoch hinzufügen.
Einige interessante Pakete sind über das Fedora Extras Projekt verfügbar, daher nehme ich deren repository in der Datei fedora-extras.repo mit auf:
[extras] name=Fedora Extras $releasever - $basearch baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/$releasever/$basearch/ enabled=1 gpgcheck=1 gpgkey=http://download.fedora.redhat.com/pub/fedora/linux/extras/RPM-GPG-KEY-Fedora-Extras
Hierunter fallen Pakete, die ich aus verschiedenen Gründen auf meinen Server nicht brauche oder haben will.
yum remove ppp nfs-utils rp-pppoe wvdial irda-utils pcmcia-cs isdn4k-utils gpm finger ypbind yp-tools autofs jwhois desktop-file-utils rsh redhat-menus htmlview pinfo portmap wireless-tools xorg-x11-libs xorg-x11-Mesa-libGL
Portmap kann auf Fedora Core 2 wegen eines Fehlers im RPM nur gewaltsam entfernt werden (bug 125663), in diesem Fall muss dann ein rpm -e --noscripts portmap her.
Für Server deinstalliere ich auch cups, rein formal geht damit aber die LSB-Konformität flöten. yum remove cups cups-libs
Der xinetd ist zwar ganz nett, wenn man einige Dienste nur sehr selten braucht, aber auf einem Server sollten ja eigentlich ohnehin nur ständig benötigte Dienste laufen, daher schmeiße ich den meist auch runter.
Sendmail finde ich auch doof (da installiere ich später eh Exim): yum remove mdadm sendmail
Da ich mein System über yum aktuell halte, können auch zwei weitere Pakete weg, nämlich rhnlib und up2date.
Alles zusammen sieht dann so aus:
yum remove ppp nfs-utils rp-pppoe wvdial irda-utils pcmcia-cs isdn4k-utils gpm finger ypbind yp-tools autofs jwhois desktop-file-utils rsh redhat-menus htmlview pinfo portmap wireless-tools xorg-x11-libs xorg-x11-Mesa-libGL cups cups-libs mdadm sendmail xinetd rhnlib rhnlib
Ein yum update bringt das System auf den neuesten Stand. Da vermutlich ein Kernel-Update nötig ist, steht jetzt vermutlich ein reboot an.
Die Service-Partition (z.B. für reibungslose Upgrades etc., bei mir meist hda2 und genauso groß wie hda1) sollte noch in die /etc/fstab eingetragen werden:
LABEL=/root/service /root/service ext3 defaults,noauto 1 2
Falls noch nicht geschehen, muss die Partition natürlich auch noch dieses Label bekommen (tune2fs -L /root/service <device>) und das Verzeichnis /root/service sollte noch angelegt werden. Mittels /sbin/e2label kann man sich auch bestehende Partitionslabels anzeigen lassen.
Nur damit es später nicht vergessen wird: Es sollte noch ein normaler Benutzer angelegt werden (/usr/sbin/useradd), ein Passwort für diesen festgelegt werden (passw <username>) und ggf. auch Einstellungen für das Einloggen mittels SSH vorgenommen werden (~username/.ssh/authorized_keys).
Um die meisten einfachen Attacken abzuwehren, sollte der SSH-Zugang für root schon mal gesperrt werden. Daher wird "PermitRootLogin no" in die /etc/ssh/sshd_config eingetragen und der sshd neu gestartet. Vorher sollte man allerdings testen, dass man sich als normaler Benutzer mittels SSH einloggen und mittels su zu root werden kann, sonst hat man u.U. ein Problem!
Fedora Core und CentOS sind ganz nette Distributionen. Wenn man allerdings Fedora oder CentOS auf einem Rechner installieren will, zu dem man keinen physischen Zugriff hat (z.B. Server in einem Rechenzentrum), ist es ganz nett, das ganze per VNC über das Netzwerk zu installieren.
Auch wenn ich im späteren Text vornehmlich von Fedora spreche, ist der Ablauf für CentOS absolut identisch, da die VNC-Installation ein Merkmal des Anaconda-Installers ist, der von beiden Distributionen verwendet wird. Ich habe diese Methode halt zuerst mit Fedora ausprobiert.
Die Grundidee der hier vorgestellten Vorgehensweise ist, dass man den speziellen Installer-Kernel und die initrd für Fedora auf das System lädt und im Bootmanager (grub, lilo) diesen Kernel als Standard-Eintrag festlegt und dem Kernel gleichzeitig noch ein paar Parameter übergibt. Dadurch startet nach dem nächsten Neustart automatisch der Anaconda-Installer, der anhand der übergebenen Parameter das Netzwerk automatisch konfiguriert und einen VNC-Server startet. Nun kann die Installation über ein VNC-Programm durchgeführt werden als ob es eine lokale Installation wäre.
Die benötigten Dateien (vmlinuz und initrd.img) liegen in den "isolinux"-Verzeichnissen (z.B. wftp.tu-chemnitz.de). Dabei muss natürlich die genaue URL angepasst werden, hier würde CentOS 5 in der 32-Bit-Version installiert.
Diese Dateien müssen unterhalb von /boot kopiert werden. Hintergedanke hierbei ist, dass /boot beim Starten immer verfügbar sein muss. Dadurch sollte der Installer-Kernel eigentlich immer geladen werden können. Das Wurzelverzeichnis '/' könnte hingegen schon wieder Probleme bereiten, wenn es auf einem LVM-Volume liegt, da grub zumindest derzeit (August 2007) nicht von LVM-Volumes booten kann. Prinzipiell ist aber jedes Verzeichnis in Ordnung, auf das grub zugreifen kann.
Nun muss der neue Kernel auch in den Bootmanager eingetragen werden. Das genaue Vorgehen unterscheidet sich natürlich je nach verwendeter Software. Ich stelle hier nur Beispiele für grub und lilo vor.
title f7install
root (hd0,1)
kernel /boot/isolinux/vmlinuz [parameter]
initrd /boot/isolinux/initrd.img
image=/boot/vmlinuz
label=f7install
read-only
initrd=/boot/initrd.img
append="parameter"
Nicht vergessen: lilo muss nach dieser Änderung in den Bootsektor geschrieben werden, daher nach dem Speichern 'lilo' aufrufen.
Außerdem müssen noch zusätzliche Parameter übergeben werden, damit auch wirklich eine VNC-Installation gestartet wird. Grob kann man sagen, dass alle Installationsfragen beantwortet werden müssen, die sonst Fedora im Textmodus anzeigen würde bevor der graphische Anaconda-Installer gestartet wird.
Ich verwende meist folgende Parameter:
vnc vncpassword=geheim lang=de_DE keymap=de resolution=800x600 \ ip=<deine_ip> netmask=<deine_netmask> gateway=<dein_gateway> dns=141.1.1.1 \ method=http://wftp.tu-chemnitz.de/pub/linux/fedora/linux/releases/7/Fedora/i386/os/
Natürlich müssen die Netzwerkdaten an das jeweilige System angepasst werden, ebenso wie 'method' und das VNC-Passwort. Außerdem sollten alle Parameter ohne Zeilenumbruch in einer Zeile geschrieben werden. Ich habe sie hier nur der Lesbarkeit wegen umgebrochen.
Prinzipiell kann der Anaconda-Installer auch mit Hilfe von sog. kickstart-Skripten teilweise oder vollständig automatisiert werden. In diesem Fall wird die Konfiguration nicht mehr über Kernel-Parameter sondern eine Datei vorgenommen, in der auch wesentlich mehr Optionen möglich sind (z.B. Festlegung der Partitionierung).
Nun muss das System eigentlich nur noch neu gestartet werden und die Installation kann beginnen. Dabei kann es eine Weile (5-10 Minuten) dauern, bis der VNC-Server auch wirklich gestartet wurde. Zudem sollte man beachten, dass der VNC-Server auf dem Display mit der Nummer 1 startet. Entsprechend muss der Aufruf also lauten: vncviewer 127.0.0.1:1
Wenn der VNC-Server nicht startet, kann man leider ohne physischen Zugriff wenig machen, weil auch keine logs auf die Festplatte geschrieben werden<ref>Woher sollte der Installer auch wissen, auf welche Partition er schreiben sollte? Fedora ist im allgemeinen sehr vorsichtig, was Schreibzugriffe angeht - immerhin könnte dadurch auch erheblicher Schaden entstehen, wenn z.B. gelöschte, aber noch nicht überschriebene Daten dadurch endgültig verloren gehen.</ref> Hier hilft letztlich nur scharfes Hinsehen und ggf. das Ausprobieren der VNC-Installation auf Rechnern, auf die man physischen Zugriff hat.
Unter Fedora Core 4 gab es einen Bug, so dass keine Passwörter länger als 11 Zeichen möglich sind. Wenn das Passwort länger war, war keine VNC-Verbindung möglich! Der Fehler ist natürlich in neueren Fedora-Versionen längst behoben.
Im Hetzner-Wiki wird berichtet, dass Rechner mit zwei Netzwerkkarten problematisch seien. Ich habe dies noch nicht ausprobiert, gegebenenfalls also auch auf solche Probleme achten.
Wenn es sich um einen Rechner mit einer völlig blanken Festplatte handelt (z.B. der neu gekaufte und super-schnelle Server, der nur leider so laut ist, dass man keine Minute neben ihm im Rechenzentrum stehen will), muss zunächst ein minimales Linux aufgespielt werden, das einen Bootmanager installiert.