Archive for the ‘howtos’ Category
Tim schlug hier vor, im Vorpost etwas anderes zur Authentifizierung als $USER zu nutzen: id. Auch das ist unsicher, wenn man es falsch macht. Ich benutze hier einfach mal die UIDs statt der Usernamen. Der folgende Code wäre dann die id-Variante, wer findet das Sicherheitsproblem? 
#!/bin/bash
if [ "$(id -u)" != "1001" ] && [ "$(id -u)" != "1002" ]
then
echo "Zugriff verweigert."
else
echo OK
[...]
echo "$(date) Domain $1 gelöscht durch $USER" >> /var/log/domainlog
fi
Umgehen kann man es jedoch wieder trivial, man erstelle ~/id:
[stefan@srv2342 ~]$ sh authme.sh
Zugriff verweigert.
[stefan@srv2342 ~]$ echo "echo 1001" > ~/id
[stefan@srv2342 ~]$ chmod +x ~/id
[stefan@srv2342 ~]$ PATH=".:$PATH" sh authme.sh
OK
[stefan@srv2342 ~]$
Wir haben hier PATH so geändert, dass zuerst im aktuellen Pfad nach id Datei gesucht wird – die Datei haben wir grade angelegt und sie gibt aus, was das Script als Antwort sehen möchte. Whoops! ;D
Um die Security awareness etwas zu erhöhen, habe ich überlegt, noch ein paar witzige Schnippsel zu posten! Vielleicht entdeckt ja jemand auch etwas, das er selbst mal gemacht hat!
Hier folgt nun ein sinngemäßer Auszug aus einem Script, das bei einem ISP sehr kritische Aktionen für Domains ausführt:
#!/bin/bash
if [ "$USER" != "franz" ] && [ "$USER" != "karl" ]
then
echo "Zugriff verweigert."
else
[...]
echo "$(date) Domain $1 gelöscht durch $USER" >> /var/log/domainlog
fi
Wichtig ist hier vor allem das Audit Log. Umgehen kann man es jedoch trivial:
USER=franz ./domain-delete.sh [domain]
Leider bedachte der Programmierer nicht, dass $USER natürlich trivial von jedem Shelluser geändert werden kann. Das Audit-Log würde ggfs. sehr unerfreuliche Folgen haben.
Bessere Lösung: sudo benutzen und nur den zwei Usern, die es wirklich benötigen, Rechte auf das Script gewähren.
Hier eine Kurzanleitung für all diejenigen, die ein FreeBSD unter kvm mit Point-to-Point benutzen wollen und daran verzweifelt sind, ins Netz zu kommen (dies ist ein kleiner Reminder für mich selbst *g):
Lokal ist hier die IP 192.168.0.220, Remote ist 192.168.0.210.
/etc/rc.conf:
ifconfig_em0="inet 192.168.0.220 192.168.0.210"
static_routes="default"
route_default="-net 0.0.0.0 -iface -interface em0"
Ist auf der anderen Seite Linux im Einsatz, so macht man dort:
ip addr add 192.168.0.210 peer 192.168.0.220/32 dev tunX
Natürlich erst, nachdem das neue tun-Interface oben ist (also z.B. im eigenen up-Script).
Live CDs sind tod – es lebe der Live USB-Stick! Dank UNetbootin wird die Erstellung eines solchen bootfähigen USB-Sticks zum Kinderspiel. Alle bekannten Linux Distributionen, verschiedene BSD Derivate sowie spezielle Live CDs (z.B. Antivir- und Systemrettungsdisks) können mittels UNetbootin mit wenigen Klicks auf einen USB Stick gebracht werden.
Nach der Auswahl der gewünschten Distribution und des zu nutzenden USB-Sticks lädt UNetbootin alle benötigten Dateien automatisch herunter und erstellt den bootfähigen USB-Stick. Auch eigene ISO-Dateien – z.B. von anderen Linux Distributionen – kann man auswählen und auf den Stick speichern. Möglich ist auch die Auswahl eines benutzerdefinierten Kernels.
UNetbootin ist bei den meisten Linux Distributionen bereits als Paket vorhanden. Auch für Windows ist das Programm verfügbar.
Weitere Informationen zu Linux auf dem USB-Stick:
Pendrivelinux.com
Live USB Stick mit Ubuntu Boardmitteln
Ich frage mich, wie ihr eure Firewallregeln in Firmenfirewalls verwaltet und sichert – wer iptables oder eine darauf basierende Lösung besitzt, wird wohl einfach automatisch oder eventbasiert Backups machen oder die Regeln in ein Repo einchecken – doch was machen die armen Admins, die mit proprietärer Hardware zu tun haben? Mir fallen spontan folgende 5 Punkte ein:
- Programmieren einer Schnittstelle, die die Regeln ausliest und in ein Repo eincheckt
- Automatische Backups durch die Firewall erzeugen lassen (oftmals per Mail möglich) und einchecken in ein Repo
- Eingeben der Firewallregeln in ein Dokumentationssystem
- Eingeben der Firewallregeln in ein System, welches die Regeln dann auf der Firewall anlegt
- Keine Dokumentation
Mich würde interessieren, wie ihr hier vorgeht? Z.B. für eine Zertifizierung nach dem IT-Grundschutzhandbuch sind solche organisatorischen Dinge nicht ganz unwichtig.
Bei PdfMod handelt es sich um eine einfache Applikation zum Bearbeiten von PDF Dateien. Mit der Gnome Applikation können beispielsweise einzelne PDF Seiten exportiert, entfernt oder rotiert werden. Weitere Funktionen finden sich auf der offiziellen Homepage.
Da es derzeit kein offizielles Ubuntu Paket für Ubuntu Jaunty gibt, müssen wir PdfMod aus den Quellen kompilieren. Zuerst benötigen wir einige Abhängigkeiten und bereiten das System vor:
sudo aptitude install build-essential intltool mono-gmcs
sudo ln -s /usr/bin/gmcs2 /usr/bin/gmcs
PdfMod hat als Abhängigkeit die C# Library Hyena, die wie folgt heruntergeladen und nach /usr/local installiert werden kann:
wget http://ftp.gnome.org/pub/GNOME/sources/hyena/0.1/hyena-0.1.tar.gz
tar xzvf hyena-0.1.tar.gz
cd hyena-0.1/
./configure --prefix=/usr/local
make && sudo make install
PdfMod wird ebenfalls heruntergeladen und konfiguriert:
wget http://ftp.gnome.org/pub/GNOME/sources/pdfmod/0.6/pdfmod-0.6.tar.gz
tar xzvf pdfmod-0.6.tar.gz
cd pdfmod-0.6/
./configure --prefix=/usr/local
Leider gibt es bei der aktuellen Version noch einen Bug, der folgenden Fehler beim make Aufruf erzeugt:
cp: cannot stat `@expanded_libdir@/hyena/Hyena.dll': No such file or directory
cp: cannot stat `@expanded_libdir@/hyena/Hyena.Gui.dll': No such file or directory
Hierbei hilf folgender sed Aufruf, der die fehlerhaften Zeilen ersetzt:
sed -i 's/@expanded_libdir@/${expanded_libdir}/g' config.status
Danach wird PdfMod wie folgt kompiliert und installiert:
make && sudo make install
Nun ist PdfMod installiert und kann mittels pdfmod aufgerufen werden. Ubuntu 9.10/Karmic Benutzer können sich die Kompilierorgie übrigens sparen – es gibt fertige Pakete im PPA.
In Zeiten wie diesen, kann man dem DNS Server seines Providers leider nicht mehr trauen. Höchste Zeit also, einen eigenen DNS Server einzurichten, der die DNS Informationen unabhängig vom Provider direkt vom zuständigen Nameserver abfragen kann.
Auf dem DNS Server Markt tummeln sich viele verschiedene Implementierungen – für einen einfachen rekursiven DNS Server eignet sich der PowerDNS Recursor. Bei den meisten Distributionen sollte ein Paket pdns-recursor über die jeweilige Paketverwaltung installierbar sein. Unter Ubuntu oder Debian lässt sich der Recursor wie folgt installieren:
aptitude install pdns-recursor
Generell sollte nun bereits lokal ein DNS Server laufen, den man nun mit einer einfachen Anfrage prüfen kann:
dig @localhost www.adminlife.net
Kommt hier eine Antwort, ist der Nameserver funktionsbereit. Nun sollte er noch in die /etc/resolv.conf eingetragen werden. Folgende Zeile wird an den Anfang der Datei eingefügt:
nameserver 127.0.0.1
Fertig ist der eigene Nameserver, der nicht mehr durch den Provider zensiert werden kann. Weitere Einstellungen, wie z.B. die IP-basierte Zugriffskontrolle, lassen sich in der gut kommentierten Datei /etc/powerdns/recursor.conf einstellen.
Die Abfrage läuft nun wie folgt:
Lokal stellt der Resolver eine rekursive DNS Anfrage an den ebenfalls lokal installierten caching-only Nameserver. Dieser stellt Anfragen an die zuständigen Nameserver im Netz, nachdem er diese von den root DNS Servern durch iterative Anfragen ermittelt hat.
Mehr zum Thema DNS:
Infos zur Namensauflösung @Wikipedia
DNS @Wikipedia
Anleitung zum Umstellen auf freie DNS Server
PowerDNS Recursor Dokumentation
Ein Upgrade von Perl unter FreeBSD kann sehr aufwendig werden, da die von Perl abhängigen Ports bestimmte Module nicht mehr finden können. Um den Aufwand minimal zu halten, gibt es das Script perl-after-upgrade.
Zuerst empfiehlt sich das Update von Perl und davon abhängiger Ports mittels portupgrade:
portupgrade -rR perl
Danach starten wir das Upgrade Script:
perl-after-upgrade
Dieses Script zeigt uns an, wie viele Ports von Perl abhängen. Um die Änderungen an den Ports auch durchzuführen, muss das Script mit dem Parameter -f ausgeführt werden:
perl-after-upgrade -f
Nun sollten alle Perl Programme auf dem System einwandfrei mit der neu installierten Perl Version laufen. Weitere Infos hat Dru Lavigne bei O’Reilly veröffentlicht.
