Installiert man Ubuntu auf einem Rechner, der seine IP-Adresse nicht von einem DHCP-Server bekommt, so gibt es anfangs natürlich Verbindungsprobleme. Der Fall tritt z.B. immer dann auf, wenn man eine Installation für einen Server durchführt.

In diesem Fall muss man die Daten von Hand angeben, eventuell schon während der Installation (mit Strg+Alt+F2 auf eine Konsole wechseln und dort mit sudo nano /etc/network/interfaces bearbeiten). Zuständig ist die Datei /etc/network/interfaces.

Normalerweise ist hier nur das Loopback-Device zu finden.

auto lo
iface lo inet loopback

Diese Datei muss man nun um die gewünschten Einstellungen erweitern:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.1.1
netmask 255.255.255.0
gateway 192.168.1.254

Danach kann man dann auch den Network-Manager abschalten, er wird ja bei einer statischen Verbindung auch nicht benötigt.

Deaktivieren kann man ihn über das Menü Einstellungen -> Sitzungen.  In dem erscheinenden Fenster einfach das Häkchen vor Network Manager entfernen, dann startet er zukünftig nicht mehr.

Auf dem Rechner ist ja auch noch keine Namensauflösung aktiviert, auch das macht sonst der Networkmanager,  insofern muss man auch noch die Datei /etc/resolv.conf anlegen, die angibt wo Nameserver zu finden sind:

domain xyz.de
search xyz.de
nameserver 192.168.1.254

In diesem Fall ist auch der Router als Nameserver eingetragen, was bei vielen Hardwareroutern, wie der Fritz!Box, gut funktioniert. Im Bedarfsfall kann man mehrere Zeilen mit Nameservern eintragen.

Nun muss der Rechner auch noch seinen eigenen namen wissen. Dazu trägt man in die Datei /etc/hostname den Rechnernamen ein und in die Datei /etc/hosts entsprechend den Rechnernamen und den vollen Rechnernamen.

beim Erstellen von Webseiten hat man immer mal das Problem, dass ein Besucher sich darüber beklagt, dass die Seiten im IE oder in Safari nicht richtig funktionieren. Wo soll man dann diese Browser herbekommen?

Eine gute Möglichkeit bietet die Seite http://browsershots.org, hier kann man die URL der eigenen Seite angeben und dann aus einer Vielzahl von Browsern auswählen. Innerhalb einer überschaubaren Zeil liefert http://browsershots.org dann Screenshots der Seite im jeweiligen Browser und es lässt sich überprüfen, welche Fehler in welcher Browser-Version auftreten.

Es gibt einen Fehler in allen Typo3-Versionen, die älter sind als eine Woche (siehe http://www.heise.de/security/news/meldung/132475). Der Fehler ist so billig auszunutzen, dass dringend alle Seiten aktualisiert werden müssen. Der Mechanismus ist so blöd wie einfach.

Man übergibt einem Typo3-System eine URL der Art:

http://meine-typo3domain.de/?jumpurl=typo3conf/localconf.php&juSecure=1&type=0&locationData=1:

Im Prinzip dfordert man hier die Datei localconf.php zum Download an.  Typo3 beschwert sich

jumpurl Secure: Calculated juHash, d29a901ee3, did not match the submitted juHash.

gibt dabei den Hash an, den es erwartet. Dann erweitert man die URL eben entsprechend:

http://meine-typo3domain.de/?jumpurl=typo3conf/localconf.php&juSecure=1&type=0&locationData=1:&juHash=d29a901ee3

Schon startet der Download der localconf.php. In der Datei findet man dann die Zugangsdaten für die Datenbank und den Hash vom Passwort für das Install-Tool.

Damit kann man dann schon etwas anfangen, den Hash kann man an einige Hacker-Seiten übergeben, die solche Hashes sammeln und ggf. das Passwort liefern können:

Konsequenzen:

  • Install-Tool unbedingt disabeln
  • sichere Passwörter setzen (den Hash testen s.o.)
  • immer neueste Typo3-Version nutzen
  • Zugriffe auf die Datenbank nur lokal erlauben

Bei OpenSUSE gibt es ein interessantes Problem, wenn man Samba-Laufwerke per cifs mounten möchte.  Ich nutze eine Buffalo Linkstation Live Netzwerkplatte, die dortigen Laufwerke sind per Samba freigegeben.

Die Zeile

//192.168.1.147/Musik /home/debacher/mp3   cifs user=debacher,password=geheim,users,noperm,noauto  0 0

in der fstab sollte eigentlich einem normalen Benutzer das Mounten dieses Laufwerkes erlauben. Leider klappt das nicht, beim Mounten gibt es nur eine nichtssagende Fehlermeldung mit einem Verweis auf die Manpage von mount.cifs. Ein umount ist da hilfreicher:

Trying to unmount when /sbin/umount.cifs not installed suid

Dem könnte man jetzt folgen. Die einfachste Lösung besteht darin das Paket cifs-mount zu deinstallieren oder die Anwendungen/sbin/mount.cifs und umount.cifs zu entfernen. Ohne diese Anwendungen klappt der Zugriff problemlos.

In der Linux-Shell kann man sehr schön die Ergebnisse eines Befehls als Eingabe für einen weiteren Befehl benutzen. Oft zu brauchen ist z.B.

# Suchen und weiterbearbeiten
find /home -name prefs.js -exec ls -la {} ;

Hier wird beginnend mit /home nach Dateien mit dem Namen prefs.js gesucht. Die gefundenen Dateien kann man dann weiter bearbeiten, im Beispiel wird nur ihr Eintrag im Inhaltsverzeichnis ausführlich gezeigt.

Man könnte sie aber auch nach einer Zeichenkette durchsuchen.

# Suchen und durchsuchen
find /home -name prefs.js -exec grep geheim {} ;

Man kann auch sehr mutig sein und z.B. alle Dateien oder Ordner mit einem bestimmten Namen löschen:

# Löschen aller Cache-Ordner 
find /home -name cache -type d -exec rm -rv {} ;

Mit dem rekursiven Löschen sollte man immer sehr vorsichtig sein.

Die Logdateien aller Server quellen über mit Anmeldeversuchen auf den SSH-Dämon. Ich habe schon immer die Zahl der Zugriffe beschränkt auf ca. einen Zugriff pro Sekunde mittels

iptables -A INPUT -p tcp --dport 22  -m limit --limit 1/sec -m state --state NEW  -j ACCEPTiptables -A

Geschickter ist wohl die neuere Alternative:

INPUT -p tcp --dport 22 -m state --state NEW -m recent --set
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j LOG --log-prefix "SSH. Mehrfach-Versuch "
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

Bei diesem System wird nach vier Anmeldeversuchen die IP-Adresse für 60 Sekunden blockiert. Das scheint deutlich besser zu blocken, da dann wohl die Scripten der Angreifer ihre Versuche abbrechen.

Spamassassin kann man beibringen, welche Mails Spam sind und welche Ham (kein Spam). Dazu dient

sa-learn --spam mail.txt

bzw.

sa-learn --ham mail.txt

wobei die Mail in der angegebenen Datei abgelegt ist.

Man kann auch abfragen, was bisher gelernt wurde, dazu dient

sudo -u vscan -H sa-learn --dump magic

Der Spam-Assassin kann dazu gebracht werden neue Regeln zu laden. Dazu dient das Kommando

sa-update -D

sollte es hier Fehlermeldungen hinsichtlich der Schlüssel geben, so kann man auch aufrufen:

sa-update -D --nogpg

In diesem Fall können die Schlüssel natürlich nicht überprüft werden.

Bei den aktuellen OpenSUSE-Versionen ist als Algorithmus für die Passwort-Verschlüsselung  md5 voreingestellt. Bei den älteren Versionen war es des.

Bei manchen Installationen spielt der Sicherheitsgewinn durch md5 keine große Rolle, dann kann man die Konfiguration wieder auf des einstellen.

Dazu dient ein Eintrag in der Datei /etc/default/passwd

# Define default crypt hash. This hash will be
# used, if there is no hash for a special service
# the user is stored in.
# CRYPT={des,md5,blowfish}
CRYPT=des

Unter OpenSUSE 11.1 (64 Bit-Version) ließ sich die aktuelle WMware Workstation problemlos installieren, wollte dann aber einfach nicht laufen. Es gab leider auch keine brauchbare Fehlermeldung. Man bekommt nur die Meldung, dass die Module nicht gefunden wurden bzw. nicht geladen werden konnten.

Man muss VMware dazu bringen die Module neu zu compilieren, dazu löscht man die vorhandenen Module, oder man verschiebt sie einfach:

mv /usr/lib/vmware/modules/binary /usr/lib/vmware/modules/binary.weg

Startet man VMware nun, so werden zuerst die fehlenden Module erstellt, danach sollte es dann laufen. Weitere Informationen unter http://communities.vmware.com/thread/185900.