Das Tor Netzwerk ist eine Möglichkeit für Anonymität im Internet zu sorgen, indem die eigene IP versteckt wird. Tor sorgt dabei dafür, dass der Traffic über drei verschiedene und ständig wechselnde Tor-Server läuft. Damit kann zwischendrin und auch am Ende nicht nachvollzogen werden, woher bestimmte Anfragen kamen.
Zu Zeiten des Bundestrojaners, der eine Online-Durchsuchung ermöglichen soll, ist es sicherlich hilfreich dem vorzubeugen. Also: zuerstmal den Tor-Client installiert.

Das Ganze habe ich aus den Quellen übersetzt. Somit zuerst die Tor Quellen downloaden (Source tarballs) und entpacken (tar -xzf tor-x.x.x.x.tar.gz).

Anschliessend ein ./configure ausführen. Möglicherweise gibt es da Fehlermeldungen, weil die passenden Pakete nicht verfügbar sind. Es werden folgenden libraries benötigt: libevent und libssl.
Es müssen auf jeden Fall auch die dev-Pakete installiert sein, sonst gibt es Fehlermeldungen! (Could not find a linkable libevent bzw. Could not find a linkable libssl) Also: apt-get install libevent-dev und apt-get install libssl-dev.

Nachdem das erledigt ist, läuft das ./configure und das ./make gut durch. Tor liegt jetzt im Verzeichnis ../src/or/tor Von dort aus kann es gestartet werden. ( mit: ../src/or/tor & )

Weiterhin wird privoxy benötigt. Den habe ich als debian-Paket installiert.
apt-get install privoxy
Die Standard-Config /etc/privoxy/config muss nur an einer Stelle geaendert werden:
forward-socks4a / 127.0.0.1:9050 .
Wenn der privoxy und tor laufen, ist nur noch der Browser entsprechend zu konfigurieren:
Im Iceweasel wird das folgendermassen gemacht:
Edit –> Preferences –> Connection –> Settings…
Dann Manual proxy Configuration aktivieren und für den HTTP Proxy localhost Port 8118 einstellen und Use this proxy server for all protocols aktivieren. Fertig.

Nun wird es Zeit zu schauen, ob die Verbindung über Tor läuft. Dazu kann eine Testsite aufgerufen werden, die die scheinbar eigene IP gegen die Tor-Exits checkt. Ist man mit einer Tor-Exit IP unterwegs, so ist man logischerweise im Tor-Netz angemeldet. Testen kann man das auf dieser Seite

Dann sollte es etwa so aussehen:

Dann wird man sofort feststellen, dass die Internetverbindung wesentlich langsamer geworden ist. Und das ist auch der Grund, warum ich ungern ständig mit Tor serven möchte. Also: Was tun? Ich lege einen weiteren User an, bei dem die Internetverbindungen so konfiguriert sind, dass man ausschließlich über Tor surft. Und, wie bereits geschrieben, besteht auch die Möglichkeit beide User unter KDE mit einer eigenen Session anzumelden. Dem Tor_User werden dann die entsprechenden Scripte zum Starten bzw. killen des Tor-Clients in die ~/.kde/Autostart bzw. in die ~/.kde/shutdown gelegt.

Fazit: Die Einrichtung einer Internetverbindung über das Tor-Netzwerk ist völlig unproblematisch möglich. Die Surfgeschwindigkeit ist nicht der Hammer, dafür ist die Anonymität und damit auch die Sicherheit (Stichwort Phishing) wesentlich erhöht!

Neulich habe ich aus Zufall etwas über fork bombs gelesen. Ein wenig googlen hat mich zu diesem genialen Konstrukt geführt:

:() { :|:& }; :

Zuerst mal zur Erklärung dieser (scheinbar wirren) Zusammenstellung von Zeichen:
Die Bash erstellt eine Funktion “:” ohne Argumente ( -> :() <- ).
Die Funktionsdefinition liegt in den geschweiften Klammern. Und zwar wird das Ergebnis der Funktion ":" an die selbe Funktion gepiped. Die neue Funktion wird dabei im Hintergrund ausgeführt (&). Somit wird also die fork-bomb losgetreten. Mit dem ";" ist die Definition beendet. Der abschließende Doppelpunkt ruft die Funktion gleich auf.

Das ganze habe ich von der Bash meines Testrechners ausgeführt. Und: innerhalb weniger Augenblicke war der ganze Rechner funktionsunfähig. Alle verfügbaren Threads waren ausgefüllt. Keine Chance den Rechner wieder gangbar zu machen (mal abgesehen vom Reset-Knopf). Der Kernel hebt einfach die Hände und denkt bei sich: Whatever dude.

Da stellt sich natürlich die Frage, ob Linux keine Möglichkeit bietet lokale DoS-Attacken zu unterbinden. Gibt es natürlich (wundersamerweise ist das nicht defaultmäßig aktiviert). Die Datei /etc/security/limits.conf limitiert für User die möglichen Prozesse (und vieles andere kann dort auch eingeschränkt werden). Weitere Informationen findet man im Header dieser Datei.

Zur Umgehung meines Problems, habe ich folgende Einstellung gewählt:

* hard nproc 100

Damit wird die Anzahl der zulässigen Prozesse je Benutzer auf 100 eingeschränkt. Aber Achtung, die neue Einstellung wird erst bei jedem neuem Login gültig. Weiterhin ist zu probieren, wie sich KDE oder Gnome verhalten. Schließlich wird für eine GUI mit Internetbrowser und was sonst noch alles, einiges an Prozessen gestartet.

Nach einem neuen Login reagiert die bash auf eine Fork-Bomb so:

-bash: fork: Resource temporarily unavailable

Ein < Enter > bringt die Kommandozeile wieder. Also: die Gefahr einer lokalen DoS-Attack ist reduziert. (Ab jetzt auch auf allen meinen Rechnern.)

Ob die Einstellung funktioniert hat, kann man sich mit einem ulimit -a anschauen.
Bringt bei mir jetzt diese Ausgabe für die Prozesse:

max user processes (-u) 100

Quellen im Web dazu:
Pinguin-soft
linux.com

keywords: local DoS-Attack, limits.conf, fork-bomb

keywords: gnupg kmail debian bad passphrase

Da ich privat gern verschlüsselte bzw. signierte emails versenden möchte, habe ich mir das Paket gnupg installiert.

apt-get install gnupg2

Damit wurden gleichzeitig alle weiteren erforderlichen Pakete mitinstalliert.
Anschließend habe ich mir damit meine private und public keys erstellt.

gpg –gen-key

Den so erstellten Schlüssel muss man exportieren, da einem sonst keiner verschlüsselte emails senden kann. Diese Schlüssel kann man auf keyservern unterbringen, auf seiner Website, …

gpg –export –armor

Bekommt man öffentliche Schlüssel, so kann man sie mit

gpg –import

zu seinem Schlüsselbund hinzufügen.
Weiterhin sollte man dringend ein Rückrufzertifikat erstellen. Könnte ja sein, man muß seinen Schlüssel irgendwann zurückrufen!

gpg –gen-revoke

Wenn man kmail nutzt sind die Verschlüsselungsoptionen im kmail noch einzustellen.
Settings — Configure kmail — Security — Crypto Backends

Settings — Configure kmail — Identities — Modfiy

An dieser Stelle war es schonmal möglich, verschlüsselte emails zu versenden. Leider funktionierte bei mir das entschlüsseln nicht. Beim Empfang einer verschlüsselten email, wurde statt dem Inhalt der mail eine “Beschwerde” angezeigt, dass kgpg das ganze nicht entschlüsseln konnte, wegen “bad passphrase”. Und dabei wurde vorher nichtmal nach einem Passwort gefragt

Also Tante google nutzen und schon waren die erforderlichen Einstellungen gefunden.

1. Die ~/.gnupg/gpg-agent.conf sieht bei mir so aus:

pinentry-program /usr/bin/pinentry-qt
no-grab
default-cache-ttl 1800
debug-level basic
log-file socket:///home/mrre/.gnupg/log-socket

2. Ich habe eine gpg.conf erstellt:

utf8-strings
keyserver subkeys.pgp.net

3. kgpg muß automatisch beim Start von kmail gestartet werden. Und zwar aus der gleichen Konsole heraus, da sonst Variablen fehlen.
Die Reihenfolge sollte so aussehen:

1. gpg-agent –daemon
2. kgpg
3. kmail

Das kann auch automatisiert werden, indem man folgende Datei erstellt: ~/.kde/env/gpg-agent.sh
Diese muss den Inhalt haben:

eval “$(gpg-agent –daemon)”

Und mit dieser Konfiguration funktioniert es, ent- und verschlüsselte emails zu empfangen.

Wer es selber mal probieren möchte, kann mir gern eine verschlüsslte mail schicken. Kontaktdaten und public key findet man hier.

Naja, ganz so einfach ist es doch nicht in mein System einzudringen. Eine gewisse Menge an Hürden habe ich aufgestellt. Und dank der LogFiles sehe ich auch, ob sie funktionieren:

Apr 12 16:06:59 belisama proftpd[7917] belisama.lstr8 (74-129-175-44.dhcp.insightbb.com[74.129.175.44]): no such user ‘Administrator’
.
.
.
Apr 12 16:07:00 belisama proftpd[7917] belisama.lstr8 (74-129-175-44.dhcp.insightbb.com[74.129.175.44]): Maximum login attempts (3) exceeded
Apr 12 16:07:00 belisama proftpd[7917] belisama.lstr8 (74-129-175-44.dhcp.insightbb.com[74.129.175.44]): FTP session closed.

Dank proftpd kann ich hiermit einen lieben Gruß senden:

*lach*@74-129-175-44.dhcp.insightbb.com

Mich begeistert die Möglichkeit mit CGI-Skripts Code auf dem Web-Server auszuführen. Beim Nachlesen im Internet bin ich allerdings auf die Gefahr, die von den CGI-Skripten ausgehen kann, aufmerksam geworden.

Wenn so ein Skript zum Beispiel von einem html-Formular aus gefüttert wird, und die übergebenen Parameter auswertet, dann kann ein Angreifer die volle Kontrolle über das Web-Server-System erhalten.

Beispiel: Man hat ein html-Formular, das mit der get-Methode Parameter an das CGI-Skript übergibt. Wenn der Angreifer dann einfach die URL mit beliebigem Code verlängert, dann könnte es (je nach Art der Programmierung) dazu kommen, dass der Server Aufgaben durchführt, die gar nicht vorgesehen waren.

eval $(echo $QUERY_STRING | sed ’s/%20/ /’) | while read; do echo $REPLY “< / br>“; done

Das wäre ein hübsches Beispiel dafür (ok, es ist sehr konstruiert, aber ok.) Wenn man an die Internet-URL ein ?ls -l anhängt, dann macht der Browser daraus: ?ls%20-l . Das Skript filtert das %20 wieder raus, und generiert ein Leerzeichen daraus. Anschließend wertet eval diesen Befehl aus. Die while-Schleife erzeugt die html-Zeilenumbrüche.

Der Angreifer könnte hier genauso gut weitere Befehle senden. Also, ich für meine Person werde in den CGI-Scripts ab sofort genau überprüfen, ob die gesendeten Parameter zulässig sind!