Schlagwort-Archive: Proxy

VMWare vCenter Server Appliance mit Proxy aktualisieren

Die Aktualisierung einer VCSA ist eigentlich ja recht einfach: Man geht über den Port 5480 auf das Appliance-Management (aka MUI, VAMI), klickt auf Update und das drunterliegende Linux wird samt aller Programme auf den aktuellen Release aktualisiert. Die Programme kommen dabei direkt von den Updateservern – zumindest wenn man eine direkte Internetverbindung hat. Steht das System in einem Netz, welches keinen direkten Zugang bietet und nicht über einen transparenten Proxy verfügt, lässt die UI die nötige Konfiguration einfach erscheinen: Unter Netzwerk -> Verwalten findet sich ein Menüpunkt „Proxy-Einstellungen“, welcher die direkte Eingabe ermöglicht. Theoretisch.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2018/01/vcsa.png

Die Praxis sieht leider anders aus: Dieses GUI-Element setzt lediglich die Umgebungsvariable http_proxy, welche ausschließlich für unverschlüsselte Verbindungen gültig ist. Da der Update-Download inzwischen per HTTPS läuft wird der Proxy praktisch ignoriert und der Download-Versuch läuft ins Leere. Dieses Problem tritt mindestens zwischen der Version 6.0 und der aktuellen 6.5U1 auf.

Zur Abhilfe muss man selbst Hand anlegen: In der Datei /etc/sysconfig/proxy findet sich neben der, von der GUI bereits gesetzten, Variable HTTP_PROXY auch ein passendes HTTPS_PROXY. Füllt man dies manuell aus ist der Update-Download fehlerfrei möglich. Wer vSAN einsetzt, sollte hier auch gleich noch die lokalen Server als Ausnahme definieren um den VMWare-Bug #2150523 zu umgehen.

Es zeigt sich wie so oft: Der Texteditor ist mächter als die Maus.

Danke an Andrew Richardson/VirtualSlices für das Aufklären des ursprünglichen Fehlers.

Squid als Proxy-Server

„Mein Internet ist kaputt“ – ich denke jeder 1st-Leveler kennt diese Aussagen. Bauchschmerzen bereiten sie spätestens dann, wenn auch man selbst nicht mehr ins Netz kommt. Proxy weg. In solchen Situationen muss schnelle Hilfe her. Mein erster Blick: Da steht noch ne Testkiste – zwar ist Arch Linux nicht unbedingt die erste Wahl für Produktivserver, welche möglichst wartungsarm sein sollen, aber besser als nichts. Bauen wir mal einen Proxy.

1. Squid installieren

Die Platzhirsch unter den Proxys dürfte ohne Frage Squid sein. Die GPL-Software kann sowohl als Caching als auch Reverse Proxy eingesetzt werden. Ich nutze nur die erste Funktion – Zugriffe der Benutzer sollen zwischengespeichert werden. Die Installation ist unter nahezu allen Distributionen mit wenigen Schritten über den Paketmanager möglich. In meinem Fall reicht ein „pacman -S squid“.

2. Zugriffs- und Speicherkonfiguration

Neben der Software wird auch eine Standardkonfiguration installiert, welche unter /etc/squid/squid.conf zu finden ist. Standardmäßig wird den privaten IPv4-Bereichen erlaubt auf die üblichen Ports für HTTP, FTP, Gopher, Wais und HTTPs zu verbinden. Sofern man keine restriktive Webzugriffslinie besitzt können diese Beispiele also übernommen werden. Einige Änderungen und Ergänzungen können allerdings Hilfreich sein:

# Keine Verbindung zu localhost - schuetzt ggf. falsch eingerichtete Webanwendungen auf dem Server
http_access deny to_localhost

#E-Mail-Adresse des Admins - so kommen die Beschwerden der Nutzer an die richtige Stelle
cache_mgr info@ad....fo

#Beim Stoppen des Dienstes 10 Sekunden darauf warten laufende Uebertragungen abzuschliessen
shutdown_lifetime 10 seconds

#Im RAM werden bis zu 4 GB als Cache genutzt
cache_mem 4096 MB

#Objekte mit mehr als 50MB werden nicht gecached
maximum_object_size 50 MB

# Bis 95% Fuellstand des Caches werden keine Objekte ersetzt
cache_swap_low 95

# Je naeher wir an 98% kommen desto aggressiver werden alte Objekte ersetzt
cache_swap_high 98

#Alles ueber 512kb wird nicht im RAM sondern nur auf HDD gespeichert
maximum_object_size_in_memory 512 KB

# HDD-Cache Typ aufs (async), Ordnerangabe, 32GB, Ordner erste Ebene, Ordner zweite Ebene
cache_dir aufs /var/cache/squid 32768 32 256

#Eyecandy
visible_hostname proxy.lan.adlerweb.info

#Boese Seiten
acl bad_url dstdomain "/etc/squid/bad-sites.acl"
http_access deny bad_url

#Interne IP des Clients nicht nach draussen senden
forwarded_for off

In meinem Fall musste auch der Standardport dran glauben, stattdessen wird nun 8080 verwendet, welches dem Altsystem entspricht und lästiges Umkonfigurieren erspart:

http_port 8080

3. Diktator-Modus

In der Konfiguration schimmert es schon etwas durch: I aim to misbehave. Da es sich um mein Netz handelt greifen auch meine Zensurrichtlinien. Unter /etc/squid/bad-sites.acl liegt eine Liste mit Domains, welche vom Proxy gesperrt werden. Dies kann z.B. sinnvoll sein um Werbung oder die Ziele quasselfreudiger Programme auszusperren. Dabei solltet ihr natürlich das alte Credo beherzigen: With great power comes great responsibility.

.facebook.com
.facebook.de
.google-analytics.com
.googleadservices.com
[...]

4 Minuten Später
…ist der Proxy installiert und das Internet läuft wieder. Job erledigt, wenden wir uns wieder den Katzenvideos zu.

Und sonst?
Wer es etwas weiter treiben möchte: SquidGuard oder Dansguardian können Webseiten nach Themenbereichen sperren. SquidClamav kann die aufgerufenen Webseiten auf Viren prüfen. Sarg verwandelt das Log in einen praktischen HTML-Report mit Top-Usern und den Beliebtesten Webseiten. Ansonsten hat auch sicher die Suchmaschine der Wahl noch genügend Ideen zur Freizeitvernichtung.

BitBastelei #146 – SSH unter Linux

BitBastelei #146 - SSH unter Linux

(41 MB) 00:30:06

2015-04-26 10:00 🛈

Vom Verbinden bis zum Tunneln
Alle Angaben beziehen sich auf OpenSSH

Befehle:

Verbinden zum Rechner:
ssh evil.server

Verbinden zum Rechner mit Nutzerangabe
ssh anderernutzer@evil.server

Host-Keys anzeigen
ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key
(bzw. passender Key)

Host-Key aus „Adressbuch“ löschen
ssh-keygen -R evil.server

Neues Schlüsselpaar erzeugen
ssh-keygen

Key auf Server kopieren
ssh-copy-id username@evil.server

Passwort eines Keys ändern
ssh-keygen -f ~/.ssh/id_rsa -p

Argumente
-p 1234 – Port 1234 statt Port 22 nutzen
-C – Kompression einschalten
-v – verbose – zusätzliche Ausgaben zur Fehlersuche

Lokale Weiterleitung
ssh -L 127.0.0.1:1234:192.168.0.2:80 evil.server
Lokale Verbindungen an Port 1234 werden über evil.server an 192.168.0.2 Port 80 weitergeleitet

Remote Weiterleitung
ssh -R 0.0.0.0:1235:127.0.0.1:80 evil.server
Verbindungen auf eine beliebige IP von evil.server auf Port 1235 werden an Port 80 des lokalen PCs weitergeleitet

SOCKS-Proxy
ssh -D 3128 evil.server
Es wird ein SOCKS-Proxy auf Port 3128 gestartet. Dieser kann z.B. mit Firefox genutzt werden

X11-Forwarding
ssh -XY evil.server
Nun können in der Sitzung grafische Programme gestartet werden. Die Anzeige erfolgt auf dem lokalen PC

Config-Files
Alle Argumente und weitere Optionen können global oder pro Ziel in den Konfigurationen hinterlegt werden. Die Benutzerkonfiguration ist unter ~/.ssh/config zu finden, die Systemweite üblicherweise unter /etc/ssh/ssh_config

Escape-Sequenz
In einer SSH-Sitzung kann man üblicherweise mit der Tilde-Taste (~) ein internes Menü aufrufen. Die Wichtigsten Befehle:
~? Hilfe anzeigen
~. SSH-Verbindung beenden (auch wenn Gegenseite nicht mehr reagiert)
~# Liste der Verbindungen (incl. Tunnel) anzeigen
~C Interne Konsole aufrufen – hier kann man nachträglich Tunnel (-L, -R, -D) aufbauen

Weitere Ideen:
– ssh-agent: Kennwörter für SSH-Keys mussen nur alle X Minuten eingegeben werden
– autossh: SSH-Verbindung bei Abbrüchen neu Aufbauen
– SSH mit Pipes: Pipes lassen sich über SSH auch an entfernte Rechner senden
2-Faktor-Anmeldung, z.B. mit Google Authenticator
Host-Keys in DNS hinterlegen

LUG-MYK