Gerade in Intranets oder bei Tests ist es auch oft gebräuchlich, nur bestimmte IP-Bereiche mit Allow und Deny zu erlauben oder zu verbieten. So kann man schnell bestimmte Störer einfach sperren.  Oder bei Tests mit dem neuen Design mal kurz nur den eigenen PC oder das Büro freischalten.

Genauso einfach jedoch weniger bekannt ist die Kombination aus beidem: Man gibt bestimmte Bereiche (z.B. das Entwicklerbüro) anhand der IP-Adresse frei und erlaubt allen anderen den Zugang nur per Passwort. So läßt sich die Entwicklung ohne Klimmzüge wie im Live-Betrieb testen, eingeladene Tester von unbekannten IP-Adressen können die Seite mit einem Passwort vorab sehen und alle anderen bleiben aussen vor.

# HTTP Basic Access Authentication
AuthType Basic
AuthName "Dieser Bereich ist passwortgeschuetzt. [www.butschek.de]"
AuthUserFile /path/to/your/.htpasswd
require valid-user

# Erlaube einige IP-Bereichen (10.1.75.x sowie 192.168.x.x)
# und verbiete alle anderen Anfragen
Order deny,allow
Deny from all
Allow from 10.1.75.
Allow from 192.168.

# Nur EINE der Bedingungen oben muss erfuellt sein.
Satisfy ANY

Der Aufbau der .htaccess Datei ist einfach: Zuerst kommt die übliche Sperre für den Passwortschutz. Danach folgt die IP-Sperre. Zuletzt legt die Satisfy-Regel fest, dass nicht alle (=ALL) sondern nur irgendeine (=ANY) der obenstehenden Regeln zutreffen muss, um den Zugriff zu erlauben.

Empfohlene Themen:

• GnuPG Mini Referenz
• Passwort erzeugen
• Sichere Passwörter
• Partition verschlüsseln mit LUKS
• OpenVPN einrichten

#!/bin/bash
echo -n Starting firewall.

while true; do
sleep 1
echo -n .
if [ $(($RANDOM%13)) -eq 2 ]; then break; fi
done

echo
echo "Your system is now secure\!"

while true; do
sleep $(($RANDOM%53))
HOST="$(($RANDOM%256)).$(($RANDOM%256)).$((RANDOM%256)).$(($RANDOM%256))"
PORT="$(($RANDOM%65535+1))"
echo "Blocked attack from host $HOST on port $PORT!!!"
done

Kommentare

• Am 30. Juni 2009 schrieb Markus Frosch: Da fehlt "$((" in der Zeile HOST=... ;-) Hab das Ding schon getestet - schaut doch gut aus :-D
• Am 30. Juni 2009 schrieb Zonealarm für Linux - LinuxadminBlog.de: [...] [via Butschek.de] [...]
• Am 30. Juni 2009 schrieb Mike: Danke für den Hinweis - hab den Code-Block im Artikel überarbeitet.
• Am 30. Juni 2009 schrieb Bernd: Endlich einen Einblick in die Arbeitsweise von ZoneAlarm.... Danke dafür!

Empfohlene Themen:

• Barack Obama – Yes he can!
• Linux Shell Tipps
• Zufallszahlen mit Modulo auf der Shell erzeugen
• Russisches Roulette auf Root-Shell Art…
• SSH-Tunnel: Proxy über SSH

Die Website www.fakenamegenerator.com ermöglicht das Erstellen einer falschen Identität. Und dabei wurde scheinbar an alles gedacht: Name, Adresse, Telefon, Geburtstag, Beruf, Geburtsname der Mutter, ja sogar die Kreditkartennummer ist dabei.

Das tolle daran: Die Daten sind in sich schlüssig. Die Straße existiert in der angegebenen Stadt, die Stadt paßt zur Postleitzahl und die wiederrum zur Vorwahl. Zur Auswahl stehen übrigens mehrere Länder und auch Namens-Sets aus mehreren ländern, damit wäre also auch ein in Finnland lebender Schwede machbar.

Ob diese Daten nun zur pseudonymisierung im Internet oder per Massen-Job für als Testdaten für die Software-Entwicklung genutzt werden, bleibt dem Benutzer überlassen.

Kommentare

• Am 29. Juni 2010 schrieb Dominik Kaufmann: Auch wieder bloß abgeschrieben ohne es zu überprüfen. Die Daten sind überhaupt nicht schlüssig und die Straßen existieren in den Städten nicht!
• Am 6. Juli 2010 schrieb Mike: Ähm, sorry aber ich schreibe nicht ab, ich denke der Inhalt des Blogs spricht da für dich. Ich hab's bei 10 Fällen mit Google Maps kontrolliert und hatte keine Fehler entdeckt. Falls es jetzt wirklich so ist habe ich entweder nicht gründlich genug geprüft oder der Dienst hat seine Qualität zwischenzeitlich runtergeschraubt. Der Artikel ist ja immerhin auch schon 1 Jahr alt. Die im Artikel genannte Kantstraße aus Nürnberg gibt es übrigens wirklich und die hat mir der Fake-Name-Generator vorgeschlagen.

Wir gehen von einer normalen Debian Lenny installation aus. Ich habe sda in 3 Partitionen unterteilt: Swap (2 GB), Root-FS (10 GB) und /home (Rest). Die dritte Partition werde ich verschlüsseln.

Zuerst installieren wir die Software und laden das nötige Kernel-Modul. Dies ist beim Einrichten einmalig manuell nötig, beim späteren Öffnen des Containers wird das Modul automatisch geladen:

apt-get install cryptsetup
modprobe dm_crypt

Nun starten wir die Einrichtung:

cryptsetup luksFormat /dev/sda3

Mit luksOpen öffnen wir den verschlüsselten Bereich. Dadurch entsteht ein neues Gerät namens /dev/mapper/{name} welches das “geöffnete” /dev/sda3 repräsentiert, jedoch in nichtverschlüsselter Form. Wir benutzen also künftig /dev/mapper/{name}, wobei alles, was wir dorthin speichern transparant verschlüsselt und nach /dev/sda3 geschrieben wird.

cryptsetup luksOpen /dev/sda3 private

Wir haben der Partition also nun den Gerätenamen ‘privat’ gegeben, daher finden wir unsere lesbare “Partition” nun unter /dev/mapper/private. Nun formatieren wir die Partition:

mkfs.xfs -L sda3-priv /dev/mapper/private

Fertig, schon kann die Partition gemountet und genutzt werden:

mount /dev/mapper/private /home

Was ich an dieser Stelle gerne empfehle ist das vollständige Überschreiben der Festplatte. Beim luksFormat wird der Bereich nämlich nicht überschrieben, es wird nur der leere Index angelegt. Die zuvor unverschlüsselt gespeicherten Daten sind also noch rekonstruierbar.

Das “Ausnullen” (Überschreiben mit lauter 0×00 Bytes) vermeide ich hier, da ein Angreifer sonst verschlüsselte und unverschlüsselte Daten großer Teile der Platte kennen könnte und somit gezielt nach dem Schlüssel suchen könnte. Daher benutze ich hier /dev/urandom:

dd if=/dev/urandom of=/home/fillup.dat bs=1M
rm /home/fillup.dat

Eine interessante Sache übrigens: Das Füllen mit Zufallsdaten könnte theoretisch auch vor dem luksFormat direkt auf /dev/sda3 erfolgen, man könnte sogar annehmen, dass dies schneller geht, weil die Zufalldaten dann nicht verschlüsselt geschrieben werden müßten. Da die Verschlüsselung jedoch die Entropie der Zufallszahlen ganz vewaltig in die Höhe treibt, geht das Erzeugen von Zufallszahlen beim Überschreiben des gecrypteten Bereiches in der Tat schneller als beim Überschreiben der Platte sda3.

Meine Messwerte:

So, um die Partition nach dem Entmounten wieder zu “schließen”, also das Mapper Device wieder zu entfernen, damit nicht mehr auf die Daten zugegriffen werden kann, wird das Kommando luksClose genutzt:

umount /dev/mapper/private
cryptsetup luksClose private

Durch einen Reboot ist das Laufwerk übrigens auch geschlossen, wenn also jemand mit lokalen Zugang zum PC kein Passwort hat, wird er künftig keine Daten aus /home mehr auf dem Rechner finden, denn selbst ein Reboot mit init=/bin/bash ist nun wirkungslos.

Fertig ist das streng geheime Home-Verzeichnis – was übrigend auch mit jedem anderen Verzeichnis klappt – zumindest solange es kein System-Verzeichnis ist, welches zum Booten schon benötigt wird.

TIPP: Ein Blick ins Manual von cryptsetup ist übrigens sehr zu empfehlen. Hier wied auch verraten, wie man mit den luks*Key Kommandos mehrere Passwörter anlegen (z.B. für mehrere Leute, jeder hat SEIN Passwort) oder wie man mit Key-Files (z.B. auf dem USB-Stick) arbeiten kann. Auch Scripting ist dank isLuks und luksUUID problemlos möglich…

Empfohlene Themen:

• Loop Device Setup
• kpartx: Partition im Loop Device
• Dateien sicher löschen mit shred
• Virtuelle Maschinen mit KVM

Die Notfall-Lösung beherrscht keine Online-Updates oder sonstige Features einer Desktop-Suite. Die 140 MB große Datei wird heruntergeladen und doppelgeklickt. Nach dem Entpacken startet der Scanner und untersucht den kompletten PC. Dabei geht er wirklich sehr gründlich vor, geprüft wird Boot-Bereich, laufende Prozess, Festplatte (inkl. des Bereichs für die Systemwiederherstellung) sowie die Registry.

Testlauf:

Beim Scannen gab das Programm unsinnigerweise seitenweise Dateinamen von geprüfen Dateien aus, dabei sah ich in roter Farbe auch meine Mainboard-Treiber vorbeilaufen. Diese werden aufgrund einer Download-Routine von vielen Scannern fälschlicherweise als Virus eingestuft. Warum man nicht einfach nur die wichtigen Informationen ausgibt, die man dann vielleicht auch lesen könnte, wurde mir nicht klar. Immerhin zeigt dieser False-Positive, dass Vipre aktuelle Pattern einsetzt – lobenswert!

Nach etwa etwa einer halben Stunde war mein Rechner dann komplett gescannt, die Abschlußmeldung auf der Konsole ist nur leider wenig aussagekräftig:

Scan completed.
Scan time: 00:31:08
Rootkits: **** scanned, 0 found
Processes: ** scanned, 0 found
Modules: **** scanned, 0 found
Folders: **** scanned, 0 found
Files: **** scanned, 7 found
Registry: **** scanned, 0 found
Total: **** scanned, 7 found
7 threat traces were detected.
Starting clean.
Quarantine {5b456ca4-42f2-8456-629d-f96b1854c0cf} completed.
Quarantine {b657c909-0d8b-29ca-fe3d-377447d960d6} completed.

Clean completed.
Clean time: 00:00:01
2 threats were cleaned.

Im Quarantäne-Verzeichnis fand ich 7 Dateien benannt in Hexadezimal-Ziffern und ohne Dateiendung (scheinbar die o.g. 7 Files) sowie 2 XML-Dateien benannt nach der Ausgabe oben “Quarantine {…} completed”.

Die 7 Dateien waren wirklich meine Mainboard-Treiber, die 2 XML-Dateien protokollierten Originalname, Quarantäne-Name, Prüfsumme und den Grund der Sicherstellung. Ob ich diese Dateien überhaupt in Quarantäne schieben will, wurde ich nicht gefragt.

Fazit:

Als Versuch der letzten Rettung bei einem halbtoten Windows-System ist der Scanner wirklich gut zu gebrauchen. Er entsorgt zumindest alles virenverdächtige und erlaubt daher das sichere Übernehmen der restlichen Daten.

Für ein noch genutztes System ist der Scanner absolut nicht zu gebrauchen, da er ohne Rücksicht auf Verluste und ohne Rückfrage Dateien umbenennt und in Quarantäne nimmt, die man ohne gute Kenntnisse in XML kaum wieder zurückbekommt. In meinem Fall waren es Mainboard-Treiber (bzw. dessen Installer) und hätte ich nicht genauer hingeschaut, wäre mir das wohl nie aufgefallen, dass hier plötzlich 7 Dateien fehlen. Doch bei der nächsten Neuinstallation hätte ich wohl geflucht und die Welt nicht mehr verstanden.

Sorry, Sunbelt Software, setzen 6!

Plus-Punkte:

• Einfache Bedienung
• Keine Installation nötig
• Läuft auch in der Rettungskonsole (DOS)

Minus-Punkte:

• Ausgabe unübersichtlich
• Absolut keine Rückfrage
• Protokoll nur in XML-Datei (keine für Nicht-Programmierer lesbare Text-Fassung)

Schade, denn die negativen Punkte ließen sich von den Entwicklern wohl in 30 Minuten beheben. Zumindest für den Notfall, wenn Windows gar nicht mehr startet, ist die Software wirklich gut zu gebrauchen:

VIPRE Rescue Program Download:
http://live.sunbeltsoftware.com/

Kommentare

• Am 18. Mai 2009 schrieb Hans: Das klingt schon gut.Hoffentlich klappt es schon mit dieser neuen Viren-Entwicklung.Danke für diese Infos.Bin mal gespannt.
• Am 19. Mai 2009 schrieb Torsten: Da vertraue ich doch lieber auf Boot-CDs (egal ob auf Windows- oder Linuxbasis) die sich auch ohne Probleme die neuesten Viren-Signaturen laden oder Software wie AVZlog, Combofix, etc.
• Am 19. Mai 2009 schrieb Mike: Der Artikel entstand, weil ich das Programm mal getestet habe und das Ergebnis mal weitergeben wollte. Ich selbst nutze das Programm nicht mehr, die Nachteile waren mir zu groß.

Empfohlene Themen:

• Albtraum eines Linux-Sysadmins…
• Virtuelle Maschinen mit KVM