Tutorial Mirror

BM-2cTtex5vCnBtQvdRH1F9peeQ1TDaduPdSk
Dec 4 18:33 [raw]

stellt hier alle Tutorials rein, die ihr findet. Und die hier noch nicht sind. Viel Spaß beim Lesen und Schreiben.

BM-2cXUgVh1Fbde26Cr5agSNWENytcRdJrGtw
Dec 4 20:15 [raw]

geil

BM-2cTaRF4nbj4ByCTH13SUMouK8nHXBLaLmS
Dec 6 06:24 [raw]

  fuck you bastards !   ------------------------------------------------------ stellt hier alle Tutorials rein, die ihr findet. Und die hier noch nicht sind. Viel Spaß beim Lesen und Schreiben.

BM-2cTtex5vCnBtQvdRH1F9peeQ1TDaduPdSk
Jan 1 02:30 [raw]

Heute lernen wir die Grundlagen, wie man einen Hidden Service betreibt. Nach Abschluss dieses Tuts, werdet Ihr eine Site mit statischem Inhalt im DW hosten können. Ich werde Euch zeigen, wie Ihr den Server grundlegend einrichtet und absichert, und versuche dabei dieses Tutorial so einfach wie möglich zu halten, und werde deshalb keine Themen ansprechen, die eine längere Einarbeitungszeit benötigen. Insgesamt sollte das erreichte Sicherheitslevel jedoch ausreichen, so lange Ihr keinen ISP gewählt habt, der Euch hinterherschnueffelt, und auch kein allzu großes Fadenkreuz seitens der Behörden auf den Rücken gepinselt bekamt. Folgendes wird vorausgesetzt: - Ihr habt bereits einen Server mit Rootzugriff und Internetanbindung zur Verfügung, der irgendwo in einem Rechenzentrum steht, und bei dessen Anmietung Ihr Euch nicht deanonymisiert habt. - Ihr wisst, wie Ihr Euren Traffic über Tor und eine VPN routet. - Auf diesem Server ist Debian Jessie als Minimalinstallation installiert, und Ihr greift als Root darauf zu. Andere Distributionen werden in diesem Tutorial nicht behandelt. - Ihr arbeitet an einer Linux Workstation. Wenn Ihr plant Euch an einem Windows-Rechner mit Putty durchzumogeln, dann vergesst es. - Ihr verfügt über die grundlegenden Fähigkeiten, die notwendig sind, um Linux in der Konsole zu bedienen. Ich setze voraus, dass Ihr einen Konsoleneditor, wie zum Beispiel vim, beherrscht, wisst, wie man SSH Verbindungen aufbaut und beendet, wie man mit su und sudo den aktiven Benutzer wechselt, und so weiter. - Ebenfalls empfehle ich Euch dringend, zu wissen wie Netzwerke und Netzwerkadministration an einem Linux-Rechner funktioniert. Andernfalls könnt Ihr das Tut zwar abarbeiten, habt aber keine Ahnung, was Ihr da gemacht habt, und bemerkt es nicht, wenn Ihr einen Fehler gemacht habt. Die Konfiguration, die ich hier vorstelle, soll nur eine Grundlage sein, auf der Ihr weiter aufbaut. Ich lasse viele Themen aus, die auch eine Rolle spielen (z.B. Kernelparameter, MACs wie SELinux, die Security Optionen von systemd, Container, eine komplexere Firewall Konfiguration, Einbruchserkennung, Audits, etc.). Wie Ihr sehen werdet, macht es Sinn, den Arbeitsplatzrechner, an dem man arbeitet, und den Server, der den Hidden Service bereitstellen soll, gleichzeitig zu konfigurieren. Ich werde bei den einzelnen Schritten dazu schreiben, auf welchem der beiden Rechner sie ausgeführt werden sollen. Ich habe den Hostnamen meines eigenen Servers in der /etc/hosts einfach als "darkserver" benannt, was Ihr entweder auch tun könnt, oder Ihr erspart Euch den Schritt, und ersetzt "darkserver" durch die IP Eures Servers. Fangen wir an: # Grundlegende SSH Host Konfiguration: Um die Sicherheit des SSH Clients auf dem Arbeitsrechner zu erhöhen, ist etwas Arbeit n tig. Zuerst generieren wir mit dem Programm ssh-keygen einige asymmetrische Schlüsselpaare, die später f r die Verschlüsselung und Authentifizierung genutzt werden: $ ssh-keygen -t ed25519 -o -a 100 $ ssh-keygen -t rsa -b 4096 -o -a 100 Nun werden Passwörter abgefragt, mit denen Eure Private Keys verschlüsselt werden sollen. Man kann diese Passwörter weglassen, und die Keys unverschlüsselt zu speichern, sollte aus Sicherheitsgründen aber davon absehen, und gute Passwörter nach den blichen Kriterien erstellen. Nachdem die zwei Befehle fertig sind, hat man einige neue Dateien im Verzeichnis ~/.ssh/, die die privaten und öffentlichen Schlüssel enthalten, die später verwendet werden. öffentlichen Schlüssel erkennt man an der Dateiendung *.pub*. ##### Achtung: Den Public Keys wird ein username@host mit den Daten des auf dem Arbeitsrechner eingeloggten Benutzers angehangen. Dies ist nicht tragisch, wenn dort user@debian steht, könnte aber auch ins Auge gehen, wenn Ihr besonders kreativ und individualistisch bei der Benennung Eures Benutzernamens und Hosts wart, und zurück verfolgbare Namen verwendet. Nun erstellen wir noch die Datei ~/.ssh/config und schreiben dort folgenden Inhalt hinein: Host github.com KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1 Host * KexAlgorithms curve25519-sha256@libssh.org HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com PubkeyAuthentication yes # PasswordAuthentication no ChallengeResponseAuthentication no Die Option PasswordAuthentification no ist auskommentiert, kann aber, sobald der SSH Deamon serverseitig eingerichtet ist und neue Schlüssel generiert wurden, aktiviert werden. Dies erhöht die Sicherheit, ist aber nicht unbedingt nötig. # Grundlegende SSH Server Konfiguration: Wahrscheinlich habt Ihr den SSH Deamon auf dem Server bereits installiert, um Euch darauf einzuloggen. Ist dies nicht der Fall, so wird er mit folgendem Befehl nachinstalliert: $ apt-get install openssh-server $ systemctl enable sshd.service $ systemctl start sshd.service Nachdem der Server läuft, könnt Ihr Euch mit Euren Root-Credentials einloggen. Als erstes erstellen wir einen Benutzeraccount auf dem Server, damit wir den Root-Login in einem der nächsten Schritte deaktivieren können: $ adduser blab Jetzt wurde auf dem Server der Benutzer "blab" angelegt. Im vorigen Kapitel haben wir bereits SSH Keys auf unserem Arbeitsrechner generiert, die nun auf den Server übertragen werden müssen. Nun kann man entweder den Inhalt der ~/.ssh/id_rsa.pub auf dem Arbeitsplatzrechner an den Inhalt der ~/.ssh/authorized_keys auf dem Server anhängen, oder man benutzt das von der SSH Suite mitgebrachte Hilfsmittel ssh-copy-id. remote-host ist im folgenden Befehl natürlich die IP oder der Hostname des Servers: $ ssh-copy-id -i ~/.ssh/id_rsa.pub *remote-host* Anschließend wird mit dem Befehl ssh blab@darkserver auf dem Server einloggen, sofern man einen Benutzer namens "blab" angelegt hat, und der Server in der /etc/hosts als "darkserver" konfiguriert wurde. Andernfalls nehmt Ihr die Credentials, die Ihr eingerichtet habt. Mit dem Befehl su werdet Ihr anschließend zu root, und arbeitet weiter. Wer will, kann dies natürlich auch mittels sudo -i erledigen, aber da sudo nicht bei Debians Minimalinstallation installiert wird, bleibt es Euch überlassen, dies umzusetzen. Nun können wir uns daran machen, den SSH Server zu konfigurieren. Die Konfigurations des *sshd* befindet sich in der Datei /etc/ssh/sshd_config - hier ist meine Beispielkonfiguration: StrictModes yes Protocol 2 Port 22 LoginGraceTime 60 PermitRootLogin no IgnoreRhosts yes AddressFamily inet ServerKeyBits 4096 KeyRegenerationInterval 3600 AuthenticationMethods publickey PubKeyAuthentication yes PasswordAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no GSSAPIAuthentication no UsePAM no UseDNS no UseLogin no UsePrivilegeSeparation sandbox PermitUserEnvironment no PrintLastLog yes IgnoreRhosts yes KerberosAuthentication no HostbasedAuthentication no X11Forwarding no SyslogFacility AUTH LogLevel INFO ClientAliveCountMax 3 ClientAliveInterval 15 # Secure Ciphers and MACs KexAlgorithms curve25519-sha256@libssh.org Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_ed25519_key HostKey /etc/ssh/ssh_host_rsa_key AllowUsers blab Sollte man nicht den Benutzernamen blab gewählt haben, muss man die letzte Zeile natürlich anpassen. Diese Einstellungen verbieten Passwort Logins, die man bruteforcen könnte, erlauben ausschließlich sichere kryptographische Methoden, und deaktivieren alles, was man f r einen Hidden Service nicht braucht. Anschließend generiert man noch neue Server-Keys: cd /etc/ssh rm ssh_host_*key* ssh-keygen -t ed25519 -f ssh_host_ed25519_key < /dev/null ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key < /dev/null Jetzt ist der SSH Deamon grundlegend konfiguriert. Folgender Befehl startet ihn neu, und aktiviert die Konfiguration: $ systemctl restart sshd.service Fertig. Ab sofort sollte es nur noch m glich sein, sich per Public Key Authentifizierung einzuloggen. Man könnte jetzt die Option PasswordAuthentication no in der ~/.ssh/config auf dem Arbeitsrechner aktivieren. Sollte es Probleme geben, befindet sich das Log in der Datei /var/log/auth.log. Darin wird jeder Verbindungsaufbau protokolliert, und darin sollte ebenfalls ein Grund angegeben sein, falls der Start des SSH Deamons gescheitert ist. # Tor Installation Es ist nun an der Zeit, den ersten Hidden Service einzurichten, welcher den SSH Server ins Tor Netzwerk bereitstellt, um so ein Administrationsinterface bereitzustellen, das komplett über Tor funktioniert, ohne, dass unsere IPs geloggt werden könnten. Es stehen mehrere Möglichkeiten zur Auswahl, woher man die Tor Software beziehen kann. Hier [https://www.torproject.org/docs/debian.html.en] steht beschrieben, wie man das Repository vom Tor Projekt in die Quellen einbinden kann. Alternativ dazu, befindet sich im Debian Repository ebenfalls eine Version der Tor Software, welche zwar etwas älter ist, die aber mit Sicherheitsaktualisierungen versorgt wird, und die ich der Einfachheit halber hier verwenden werde. $ apt-get install tor Nun kann man die /etc/tor/torrc konfigurieren. Hier meine Beispielkonfiguration: AvoidDiskWrites 1 HardwareAccel 1 ClientOnly 1 FascistFirewall 1 ExitPolicy reject *:* SocksPort 9050 SocksPolicy accept 127.0.0.1 SocksPolicy reject * Log notice file /var/log/tor/notices.log DataDirectory /var/lib/tor Der Socks-Proxy ist nach dieser Konfiguration auf Port 9050 erreichbar, und zwar nur vom localhost aus, und nicht vom Netzwerk. Daten werden ins Verzeichnis /var/lib/tor/ geschrieben. Datenverbindungen ins Tor Netzwerk werden über die Ports 80 und 443 abgewickelt. Nachdem dies gespeichert ist, kann man Tor neu starten: $ systemctl restart tor.service und mit tail -f /var/log/tor/notices.log die Statusmeldungen des Tor Clients beobachten. Wenn alles okay ist, sieht ein erfolgreicher Verbindungsaufbau in den Logs wie Folgt im Log aus: Sep 23 14:14:58.000 [notice] Interrupt: exiting cleanly. Sep 23 14:14:59.000 [notice] Tor 0.2.5.12 (git-3731dd5c3071dcba) opening log file. Sep 23 14:14:59.000 [notice] Caching new entry debian-tor for debian-tor Sep 23 14:14:59.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. Sep 23 14:15:00.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Sep 23 14:15:02.000 [notice] Bootstrapped 0%: Starting Sep 23 14:15:04.000 [notice] We now have enough directory information to build circuits. Sep 23 14:15:04.000 [notice] Bootstrapped 80%: Connecting to the Tor network Sep 23 14:15:09.000 [notice] Bootstrapped 85%: Finishing handshake with first hop Sep 23 14:15:10.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Sep 23 14:15:10.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Sep 23 14:15:10.000 [notice] Bootstrapped 100%: Done # SSH über Tor - Der erste Hidden Service Um einerseits eine über das Tor Netzwerk erreichbare Shell zur Administration des Servers zu haben, und den Server andererseits zu einem späteren Zeitpunkt wasserdicht zu machen, richten wir uns nun einen Hidden Service ein, der uns den Zugriff per SSH erlaubt. Wir haengen folgende Zeilen an die /etc/tor/torrc an: HiddenServiceDir /var/lib/tor/hidden_service/ssh HiddenServicePort 22 127.0.0.1:22 und erstellen das genannte Verzeichnis mitsamt passender Rechte: $ mkdir -p /var/lib/tor/hidden_service/ssh $ chown debian-tor:debian-tor /var/lib/tor/hidden_service $ chmod o-rwx /var/lib/tor/hidden_service $ chown debian-tor:debian-tor /var/lib/tor/hidden_service/ssh $ chmod o-rwx /var/lib/tor/hidden_service/ssh Nun ist unser erster Hidden Service konfiguriert. Wir starten Tor neu: $ systemctl restart tor.service Und stellen anhand der Logs sicher, dass der Neustart erfolgreich war. Nun befinden sich unter /var/lib/tor/hidden_service/ssh zwei Dateien: hostname und private_key. Beide Dateien sichert man, und findet in der Datei hostname die .onion url, unter welcher unser SSH Server fortan erreichbar ist. Es dauert eine Weile, bis unser Hidden Service im Tor Netz registriert wurde. Deshalb legt man nun eine Pause ein, und bittet zum Beispiel die Miezeee darum, uns Genitalbilder zu schicken. Nach spätestens zehn Minuten sollte unser Hidden Service erreichbar sein. Wir notieren uns nun also die .onion Url unseres Servers, und greifen ab sofort folgendermaßen darauf zu: $ torify ssh blab@unsereonionurl.onion Das Programm torify ist ein Wrapper, der die Netzwerkkommunikation eines Programms über Tor leitet, wodurch es auch außerhalb von Tails und Whonix moeglich ist, Programme zu torifizieren. Die .onion Url aus dem Beispiel funktioniert natürlich nicht, und sollte auch geheim gehalten werden, da sie unser Administrationsinterface ist, das niemand zu kennen braucht. über diese Tor-Shell erledigen wir fortan alles Weitere, und verbinden uns nach Möglichkeit nicht mehr mit der CW-Adresse den Servers. # APT ber Tor - Systemupdates vom Hidden Service: Als Nächstes installieren wir das Paket apt-transport-tor, welches es uns erm glichen wird, weitere Softwarepakete und Systemupdates direkt ber das Tor Netzwerk zu beziehen. Dies wird den Updateprozess zwar verlangsamen, erleichtert es aber zu einem sp teren Zeitpunkt die Paketfilter-Firewall abzudichten. $ apt-get install apt-transport-tor Nun m sst Ihr die Datei /etc/apt/sources.list anpassen. Ihr kommentiert einfach alles aus, was darin steht, und schreibt folgenden Inhalt hinein: deb tor+http://httpredir.debian.org/debian jessie main contrib non-free deb tor+http://httpredir.debian.org/debian jessie-updates main contrib non-free deb tor+http://httpredir.debian.org/debian jessie-proposed-updates main contrib non-free deb tor+http://security.debian.org/ jessie/updates main contrib non-free Um sicherzustellen, dass apt-get wie gew nscht funktioniert, probiert man einfach ein update && safe-upgrade aus: $ apt-get update && apt-get safe-upgrade # Automatische Sicherheitsaktualisierungen: Da wir mit aktuellen Sicherheitsaktualisierungen automatisch versorgt werden m chten, richten wir nun das Paket unattended-upgrades ein, welches uns diese Aufgabe abnimmt. Sicherheitskritische Aktualisierungen werden damit automatisch vorgenommen, w hrend Versionsupdates nicht eingespielt werden und ein Eingreifen des Administrators erfordern. Folgender Befehl installiert unattended-upgrades: $ apt-get install unattended-upgrades Nun muss man das System noch soweit konfigurieren, dass es die Updates automatisch herunterl d und einspielt. Einfach macht es folgender Befehl: $ dpkg-reconfigure -plow unattended-upgrades Im nun folgenden Curses Bildschirm w hlt Ihr aus, dass Ihr automatische Updates und upgrades haben wollt, und sie Sache ist geritzt. # der NGINX Webserver: Nun haben wir das System soweit vorkonfiguriert, dass wir einen Webserver installieren k nnen. Im DW etabliert sich der NGINX (sprich Engine X) mehr und mehr als Standard, da er sehr schnell ist, einfach konfigurierbar ist, und als relativ sicher gilt. Wir nehmen auch hier der Einfachheit halber die Version, die das Debian Repository bereitstellt, die zwar schon recht alt ist, daf r aber gut auf m gliche Sicherheitsl cken abgeklopft wurde. $ apt-get install nginx-light Die Konfigurationsdatei ist die /etc/nginx/nginx.conf. Hier ist meine Beispielkonfiguration: user www-data; worker_processes 4; pid /run/nginx.pid; timer_resolution 10ms; events { worker_connections 768; # multi_accept on; http { sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; server_tokens off; server_names_hash_bucket_size 128; server_name_in_redirect off; include /etc/nginx/mime.types; default_type application/octet-stream; access_log /dev/null; error_log /dev/null crit; autoindex off; gzip on; gzip_disable "msie6"; gzip_vary on; gzip_proxied off; gzip_comp_level 6; gzip_buffers 16 8k; gzip_http_version 1.1; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; server { listen 127.0.0.1:8080; server_name localhost; add_header X-Frame-Options SAMEORIGIN; add_header Content-Security-Policy "default-src https: data: 'unsafe-inline' 'unsafe-eval'"; add_header X-Content-Type-Options "nosniff"; add_header X-Xss-Protection "1; mode=block"; client_body_buffer_size 1K; client_header_buffer_size 1k; client_max_body_size 1k; large_client_header_buffers 2 2k; client_body_timeout 10; client_header_timeout 10; send_timeout 10; if ($request_method !~ ^(GET|HEAD)$ ) { return 444; } root /usr/share/nginx/www; index index.html index.htm; location / { allow 127.0.0.1; deny all; } } } Mit dieser Beispielkonfiguration liefert NGINX alle unter /usr/share/var/www/ gespeicherten Dokumente aus, und lauscht selber an localhost auf Port 8080. W rde man vom Arbeitsrechner versuchen Server anzusprechen, w rde der Verbindungsaufbau abgelehnt, w hrend lokale Verbindungen akzeptiert werden. Logs werden nicht auf die Platte geschrieben. Nun kann man seine Konfiguration testen: $ nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful und den Server im Erfolgsfall neu starten: $ systemctl restart nginx.service Nun ist man so weit, dass man vom Server aus den Zugriff testen kann: $ curl localhost:8080 <html> <head><title>404 Not Found</title></head> <body bgcolor="white"> <center><h1>404 Not Found</h1></center> <hr><center>nginx</center> </body> </html> Wie man sieht, gibt es einen HTTP 404 Fehler, weil keine Seite gefunden wurde. Dies behebt man nun, indem man seine statischen Seiten im Verzeichnis /usr/share/var/www/ ablegt, und daf r sorgt, dass es eine index.html gibt, die aufgerufen wird, wenn in einem Request einfach nur / als URI spezifiziert wurde. Falls es noch keine Homepage gibt, die man anlegen k nnte, legen wir die Datei index.html im Verzeichnis /usr/share/var/www/ an, und schreiben Folgenden Inhalt hinein: <h1>Hidden Service l uft</h1> # Der NGINX Webserver als Hidden Service: Nun machen wir das Selbe, was wir mit der SSH bereits taten, als wir sie als Hidden Service konfigurierten. Wie h ngen Folgendes an die /etc/tor/torrc an: HiddenServiceDir /var/lib/tor/hidden_service/nginx HiddenServicePort 80 127.0.0.1:8080 und erstellen das genannte Verzeichnis mitsamt passender Rechte: $ mkdir -p /var/lib/tor/hidden_service/nginx $ chown debian-tor:debian-tor /var/lib/tor/hidden_service/nginx $ chmod o-rwx /var/lib/tor/hidden_service/nginx Nun ist auch NGINX als Hidden Service konfiguriert. Wir starten Tor neu: $ systemctl restart tor.service und schauen in der /var/lib/tor/hidden_service/nginx/hostname nach, wie die .onion Addresse unseres Hosts hei t. W hrend wir warten, bis der Hidden Service im Tor-Netz registriert ist, hauen wir erneut die Miezeee nach Pussy-Pics an, und testen dann am Arbeitsrechner, ob wir uns verbinden k nnen: torify curl unsereweitereonionurl.onion <h1>Hidden Service l uft</h1> Fertig. # Firewass Regeln mit UFW erstellen: Nun gehts daran den Netzwerkverkehr dahingehend einzuschr nken, dass alle Ein- und Ausgehenden Netzwerkzugriffe geblockt werden, die nicht zur Funktion unseres Hidden Services notwendig sind. Da die Konfiguration von Iptables f r dieses Tutorial zu kompliziert w re, bedienen wir uns des Programmes ufw, aka. Uncomplicated FireWall, das uns die Konfiguration erleichtert. Wir installieren es mit: apt-get install ufw und kopieren den folgenden inhalt in die /etc/default/ufw: IPV6=no DEFAULT_INPUT_POLICY="DROP" DEFAULT_OUTPUT_POLICY="ACCEPT" DEFAULT_FORWARD_POLICY="DROP" DEFAULT_APPLICATION_POLICY="SKIP" MANAGE_BUILTINS=no IPT_SYSCTL=/etc/ufw/sysctl.conf IPT_MODULES="" IPv6 wird dadurch deaktiviert, eingehende und weiterzuleitende Pakete werden fallen gelasen, und es werden einige Kerneloptionen gesetzt, die Sinn machen. Gibt man nun folgenden Befehl ein: $ ufw enable werden mit einem Schlag alle eingehenden Verbindungen geblockt. Es ist nun nicht mehr m glich, den SSH Server oder sonst einen Dienst von au en anzusprechen. Es werden zwar noch einige Systemprotokolle wie ICMP durchgelassen, ansonsten ist der Server f r eingehende Verbindungen aber dicht, und es sind nur noch Verbindungen ber die von uns eingerichteten Hidden Services m glich. Viel Spa . Vergesst nicht zu spenden. Tutorials schreiben sich nicht von alleine. Und ich mache Auftragsarbeiten. I <3 Julias dead ( . )Y( . ) AND Helenas Ultrabrutality PGP-Fingerprint: 7F39 6881 EC31 5729 68F1 378C 127C FCBD 85F2 ECD7 Spendenwallet: 17EixcBEM1LUL3cNyn9fMCWcX8xJytTdRb

BM-2cTtex5vCnBtQvdRH1F9peeQ1TDaduPdSk
Jan 3 22:57 [raw]

Hauptsächlich geht es darum, dass wir uns jetzt über Retroshare neu vernetzen. Eine dezentrale, standartmäßig PGP verschlüsselte Kommunikationsmöglichkeit, die über Tor und/oder I2P funktioniert. Wir haben dort Foren, Kanäle, private und öffentliche Chats und einige Sachen mehr die uns Möglichkeiten bieten. Ich hänge dir das Tutorial zur Einrichtung über Tor mit an. Bis bald. Wir hören uns über RS. :) Anleitung zur Konfiguration von TOR und Retroshare Nachfolgend wird ein TOR-Server eingerichtet, der einen hidden service, also einen Dienst, der nur im TOR Netzwerk erreichbar ist, bereitstellt. Dessen Adresse ist bei der Installation von Retroshare erforderlich. Ausgegangen wird von einem installierten TOR-Browser. - navigieren Sie zu /tor-browser_de/Browser/TorBrowser/Data/Tor/ - öffnen Sie die Datei torrc mit einem Texteditor - fügen Sie in Windows die nachfolgenden beiden Zeilen ein: HiddenServiceDir C:\hidden_service HiddenServicePort 1488 127.0.0.1:1488 - entsprechend in Linux, (Beispiel) HiddenServiceDir /home/user/Programme/tor-browser_de/Browser/TorBrowser/Data/Tor/hidden_service HiddenServicePort 1488 127.0.0.1:1488 - speichern Sie die Datei (aber noch nicht schliessen, die Ports müssen später noch geändert werden). - starten Sie den TOR-Browser ==> es wird automatisch der Folder hidden_service im obigen Pfad angelegt - navigieren Sie zu hidden_service und öffnen mit einem Texteditor die Datei hostname welche die onion-Adresse Ihres "hidden Service“ beinhaltet. Retroshare einrichten: ( Download: http://retroshare.net/ ) Beim Erststart von Retroshare muss ein Profil angelegt werden: In das Feld „versteckte Adresse“ kopieren sie die onion-Adresse aus der Datei hostname. Nach dem Start von Retroshare navigieren Sie zu den Menüpunkten Preferences und Netzwerk. Unter dem Reiter Versteckte Dienstekonfiguration ändern Sie den Tor Socks Proxy Port auf 9150 Die Datei torrc sollten Sie noch geöffnet haben. Ändern Sie die Konfigurationsangaben wie sie von Retroshare erwartet werden. - speichern und schliessen Sie torrc. - schliessen Sie den TOR-Browser Nach dem Neustart des TOR-Browsers und Retroshares gehen Sie wieder zu den Menüpunkten Preferences und Netzwerk. In der Versteckte Dienstekonfiguration testen Sie Eingehende Dienstverbindungen. Retroshare ist jetzt für TOR konfiguriert. von: BM-2cSr9GJxE8TQJRruZHHWvP1KHxiyjyrdXp

BM-2cTtex5vCnBtQvdRH1F9peeQ1TDaduPdSk
Jan 3 23:03 [raw]

Mehr schlecht, als recht: Da ich selbst Neuling bin, ist dieses Tutorial nur halbwegs professionell. Windoof: Ich benutze Pidgin (download unter pidgin.im - CW). Ausserdem braucht ihr noch pidgin otr. wenn ihr beides installiert habt, könnte euch folgendes Tutorial weiterhelfen: https://www.uwetrottmann.com/software/pidgin-jabber-icq (CW) Stattdessen gebt ihr aber bei Konto hinzufügen folgendes an: Protokoll: XMPP Benutzer: euren Lieblingsnick Domain: germanyt366sirdc.onion Ressource: Webchat Passwort: Lokaler Alias könnt ihr freilassen Der Rest bleibt gleich Ihr drückt auf hinzufügen und müsst nun euer Passwort eingeben. Jetzt drückt auf Kontakte - Chat hinzufügen und gebt in den Raum #germanyhusicaysx ein (mit dem #) Den Rest füllt ihr aus, wie ihr es schon davor getan habt. Gruppe kann erstmal leer bleiben. Drückt auf Hinzufügen und Doppelklickt #germanyhusicaysx. Fertig.

BM-2cTtex5vCnBtQvdRH1F9peeQ1TDaduPdSk
Jan 3 23:06 [raw]

Retroshare Tutorial stammt hier von Balu. Ob das der Autor ist, kann ich nicht sagen.

[chan] cyberguerrilla
BM-2cTtex5vCnBtQvdRH1F9peeQ1TDaduPdSk

Subject Last Count