Monats Archiv: Oktober 2016

  • -

VNC Zugang über SSH Tunnel

Kategorie : News

Da VNC Sitzungen bei uns per Policy als unsicher eingestuft sind, $KUNDE allerdings ohne GUI auf seinem Ubuntu Server nicht klargekommen ist und der Kunde ja bekanntlich König ist musste ich mir überlegen wie ich $KUNDE dies ermögliche ohne unnötige Löcher in die Firewalls zu reißen und unsere Policys nicht zu verletzen. In meinem Büro hängen zudem 3 Monitore mit 3 RaspberryPi 3 die lediglich als „Fenster“ auf diverse Monitoring Systeme fungieren. Damit ich jetzt nicht sobald ich dort irgendwas ändern möchte jedes Mal Maus und Tastatur wo anders stibitzen muss oder einen KVM Switch zweckentfremden muss, dachte ich mir, wäre VNC doch auch hier das Mittel zum Zweck. Die Pis hängen allerdings in einem anderen Netz als meine Workstation und auf Grund von restriktiven Firewall Policys (die ich ja nun mal selbst gesetzt habe) ist auch zwischen diesen beiden Netzen kein VNC im Solo Betrieb erlaubt.  Da SSH ja ein Allheilmittel ist dachte ich mir, wieso nicht die VNC Verbindung durch einen SSH Tunnel schieben. Gesagt getan, verschiedenes ausprobiert und am Ende beim x11vnc Server gelandet.

Wieso x11vnc? Ganz einfach, die Konfiguration ist wenig aufwendig und der x11vnc hängt sich direkt an eine bestehende X11 Sitzung an so dass ich Zugriff per VNC auf die lokale Konsole bekomme und er nicht wie bei tightvnc Beispielsweise eine neue X11 Sitzung aufbaut sobald sich ein User per VNC verbindet. Das ist zwar auch eine Super Idee wenn man mit mehreren Usern auf einem Multiuser System arbeitet (á la Terminal Server), ist aber für den anvisierten Zweck eher hinderlich da ich die lokale Konsolen Sitzung steuern muss um den Inhalt zu bearbeiten, der auf meinen Bildschirmen  erscheint.

Die Pis laufen mit Ubuntu 16.04 und dem MATE Desktop (das Image gibt es hier https://ubuntu-mate.org/raspberry-pi/) und zeigen entweder eine RDP Sitzung auf unseren VEEAM One Server an oder eine Website (bloonix, AlienVault, VEEAM One Reporter).

Der x11vnc Server ist in den Ubuntu Paketquellen verfügbar und lässt sich ganz einfach per

sudo apt install x11vnc (ja mein apt hat Super Kuh kräfte)

Installieren.

Der SSH Server lässt sich ebenfalls per apt install mit

sudo apt openssh-server

installieren wenn dieser nicht sowieso schon installiert ist.

Danach sollte ein Passwort für den x11vnc Server erstellt werden, dies erfolgt mit dem Befehl

sudo x11vnc -storepasswd irgendeinkennwort /etc/x11vnc.pass

etwaige Sonderzeichen müssen natürlich escaped werden.

Da wir uns hier auf Ubuntu 16.04 bewegen und den Dienst möglichst beim Booten automatisch mit starten wollen, müssen wir nun noch eine Systemd unit anlegen. Da ich bekennender VIMthusiast bin erstellen und bearbeiten wir dazu mit dem Befehl

sudo vim /lib/systemd/system/x11vnc.service

eine neue systemd unit und fügen dort folgenden Inhalt ein (in den Insert Mode wechseln mit i oder a):

 

[Unit]

Description=Start x11vnc at startup.

After=multi-user.target

 

[Service]

Type=simple

ExecStart=/usr/bin/x11vnc -auth guess -forever -loop -noxdamage -repeat -no6 -localhost -rfbauth /etc/x11vnc.pass -rfbport 5900 -shared

 

[Install]

WantedBy=multi-user.target

Wir verlassen den Insert Mode mit Druck auf die Taste „ESC“.

Danach Sichern wird die Datei und schließen den Editor mit der Tastenfolge

:wq

Nun ist es nötig dem systemd noch zu sagen, dass wir die gerade erstellte x11vnc unit beim Booten mit starten wollen.

Dies erfolgt über den Befehl

 sudo systemctl enable x11vnc.service

danach ist noch ein reload des systemd Services notwendig, dieser erfolgt durch den Befehl

sudo systemctl daemon-reload

nach einem Neustart des Systems steht nun der x11vnc Server bereit und kann über einen SSH Tunnel verwendet werden.

An dieser Stelle kurz einmal zum Programmaufruf in der eben Erstellten Systemd Unit.

ExecStart=/usr/bin/x11vnc -auth guess -forever -loop -noxdamage -repeat -no6 -localhost -rfbauth /etc/x11vnc.pass -rfbport 5900 –shared

ExecStart= ist der Parameter der dem Systemd sagt wie der Gewünschte Dienst gestartet werden soll.

/usr/bin/x11vnc ist das durch den Systemd auszuführende Programm, in unserem Fall jetzt eben der X11VNC Server.

Interessant wird es bei den angehängten Optionen.

-auth guess sagt dem x11vnc Server dass dieser sich die X authority file selbst suchen soll, die X authority File beinhaltet Zugangsdaten in Cookies die vom xauth Prozess benutzt werden um sich an einer X Session anzumelden.

-forever verhindert das der x11vnc Server sich selbst beendet nach dem sich der letzte User abgemeldet hat.

-loop sorgt dafür dass der x11vnc Server neu gestartet wird wenn er aus irgendeinem Grund Terminiert.

-noxdamage X DAMAGE ist eine Methode um changes im framebuffer zu detektieren, es soll die Last auf dem System durch das ansonsten verwendete scanline polling des x11vnc dienst minimieren und die VNC Sitzung schneller reagieren lassen, allerdings ist das Feature laut manpage noch nicht ganz gar.

-repeat erlaubt dem VNC Client bei gedrückt halten einer Taste das Zeichen zu weiderholen.

-no6 deaktiviert die IPv6 Unterstützung, andernfalls wäre der x11vnc Dienst über IPv6 Adresse erreichbar. Viele Consumer Router bieten mittlerweile die Möglichkeit IPv6 zu routen und automatisch zu adressieren. (jeder Anschlussinhaber erhält von seinem Provider ein /64 Netz, daraus verteilt der Router dann an die angeschlossenen Clients IPv6 Adressen die aus dem Internet erreichbar sind) Da allerdings viele dieser Router gar keine bis maximal dürftige Möglichkeiten bieten IPv6 Traffic zu filtern wäre unser x11vnc Server hier von außen also erreichbar. Das folgende Argument hat nämlich nur Auswirkungen auf den IPv4 Traffic. Wir wollen ja aber bloß das wir uns über den SSH Tunnel verbinden können, deshalb würd hier IPv6 bloß einen unnötigen zusätzlichen Agriffsvektor darstellen.

-localhost erlaubt dem x11vnc Server nur auf 127.0.0.1 zu horchen.

-rfbauth /etc/x11vnc.pass spezifiziert den Pfad zur Anfangs erstellten Password Datei.

-rfbport 5900 spezifiziert den Port auf dem der x11vnc Server hören soll.

-shared Normalerweise erlaubt auch der x11vnc Server nicht das ein screen geshared werden kann, dies wird hiermit ermöglicht.

Der VNC Server kann jetzt (nur) durch einen SSH Tunnel verwendet werden.

Die Vorgehensweise ist abhängig vom System.

Bei Ubuntu kann man dem vncviewer über die Option -via den SSH Host direkt mit angeben.

Der Befehl lautet dann in etwa:

vncviewer -via user@host localhost:0

wobei user der Username des SSH Benutzers ist und host der Hostname oder die IP des SSH Hosts darstellt.

Den weg mit Putty und VNC auf Windows Systemen könnt Ihr hier nachlesen.

http://www.cs.uni-potsdam.de/ti/lehre/05-ALuP-I/anleitung_vncssh.html

Beim Mac würde der SSH Tunnel mit dem Kommando

ssh -NfL 5900:127.0.0.1:5900 user@remote.host

aufgebaut werden. Sobald die Verbindung steht kann man dann mittels eingebautem VNC Client (seit OS X 10.4) auf die Verbindung zugreifen. Eine Anleitung dazu findet ihr hier http://remotepairprogramming.com/post/77905116436/screen-sharingapp-its-built-in-to-your-mac-use.

Wenn euch was Auffällt oder ihr Verbesserungsvorschläge habt  schickt mir diese doch gerne an jst[at]phi.de

Share

  • -

pfSense Hostnamen auflösen

Kategorie : News

Wenn man bei der pfsense nicht nach IP Adressen sondern nach Hostnamen auflösen will, muss man bloß den Hostnamen in ein Alias packen und das Alias in der Regel verwenden.

Der interne DNS-Resolver der Firewall löst dann alle 5 Minuten die FQDNs in den Aliases neu zu den IP-Adressen auf. Kommt dabei mehr als eine IP zurück, werden auch alle IP-Adressen für den Filter verwendet.

Praktisch bei Microsoft Update Services oder beim Canonical Livepatch Service, weil sich hier die IP täglich ändert oder ggf. bei erhöhter Arbeitslast auf einem Server ein anderer aus deren Pool unter dem angefragten FQDN antwortet.

Share

  • -

Update bei pfSense schlägt fehl

Bei dem Update der pfSense z. B. auf die Version 2.3.2 kann es derzeit zu Problemen des Updates kommen.
Dabei wird das Update zwar ausgeführt jedoch fährt die pfSense dann nicht mehr richtig hoch.

Grund dafür ist die Fehlermeldung can’t load ‚kernel‘.

Das Problem bei dem Update über die GUI ist im eigentlichen also kein Problem von der pfSense Software sondern von dem Linux Kernel der darunter läuft.

Damit wir das Update erfolgreich durchgeführt bekommen machen wir die Prozedur per Hand.

Dabei sollte der Proxy und die Carp Verbindung um Fehler zu vermeiden getrennt sein für die Dauer der Prozedur.

Dazu Loggen wir uns per SSH auf der pfSense als admin ein und gehen mit der 8 in die Konsole.
pfsense

Dort starten wir mit dem Befehl pkg update –f das Updaten der Repositories.

pfsense
Wenn dies ausgeführt wurde starten wir mit pkg upgrade –f das Upgrade auf das aktuelle System.
Dabei werden auch die Pakete wie php, curl, mcrypt etc. mit aktualisiert.

pfsense-update_5

Dies dauert dann einige Minuten je nach Internetverbindung.

Der Parameter –f versucht die Fehler direkt zu beheben.
Manche Sachen müssen mit y oder j bestätigt werden für die Installation. Dies einfach mit „y und der Eingabetaste“ bestätigen.

Damit der Kernel direkt auch installiert wird führen wir nun das Update der pfSense aus.
Das update wird mit pfSense-upgrade –d ausgeführt und updatet das komplette System.
Nach Beendigung von dem Upgrade Vorgang wird das System neu gestartet.

pfsense-update_4

Ab jetzt läuft auf der pfSense das aktuellste System in dem Fall dann die Version 2.3.2_r1

pfsense-update_7

Wir wünschen viel Erfolg

Share

Share