Nach der abgeschlossenen Installation wollen wir auch direkt ein paar Einstellungen ändern, wie zum Beispiel, dass Shutter beim Systemstart minimiert gestartet wird.
Dafür müssen in den Einstellungen unter „Verhalten“ folgende zwei Haken unter „Verhalten beim ersten Start“ gesetzt werden:
„Shutter beim Anmelden automatisch ausführen“
und
„Fenster beim ersten Start nicht anzeigen“

Einstellungsmöglichkeiten für Tastaturkürzel suchen wir in den Einstellungen von Shutter vergeblich. Das liegt daran, dass Tastaturshortcuts von Linux Mint verwaltet werden.
Dafür gehen wir in die Linux Mint Einstellungen, dann weiter zu „Tastatur“. Alternativ in die Suche des Startmenüs „Tastatur“ eingeben. Hier lassen sich vorhandene Tastaturkürzel nachschauen und ändern, aber auch neue hinzufügen.
Dafür klicken wir aus „Eigene Tastaturkombination erstellen“.
Um mit Shutter per Tastendruck ein Screenshot einer Auswahl zu machen, nutzen wir den Befehl
shutter -s

Das „-s“ steht dabei für „Selection“, also Englisch für „Auswahl“. Als Name für die Tastaturkombination können wir beispielsweise „Shutter Auswahl“ nutzen.
Damit wurde bereits der Befehl und der Name für die Aktion festgelegt.

Um der Aktion nun noch eine Tastenkombination zuzuweisen, klickt man doppelt unter „Tastenkombinationen“ auf den ersten der 3 Einträgen „nicht zugeordnet“. Dann drückt man die gewünschte Tastenkombination. Ich habe mich für die „Druck“-Taste entschieden. Die Warnung, das damit die vorhandene Aktion für die Druck-Taste ersetzt wird, bestätigen wir mit „Ja“.

Um Shutter auch mit einer Tastenkombination für Vollbild-Screenshots zu verwenden, muss eine weitere Tastenkombination angelegt werden. Der Befehl dafür lautet
shutter -f

Der Beitrag Linux Mint: Shutter Shortcut bearbeiten erschien zuerst auf jybee.com.

Einzeiler, um alte Kernel zu entfernen (das gibt auch Speicherplatz frei). Hat bei Linux Mint schon häufig geholfen.

dpkg --list | grep linux-image | awk '{ print $2 }' | sort -V | sed -n '/'`uname -r`'/q;p' | xargs sudo apt-get -y purge

Erklärung

( | verwendet die Ausgabe des vorherigen Befehls als Eingabe zum nächsten)

• dpkg --list listet alle installierten Pakete auf
• grep linux-image sucht nach den installierten Linux-Images
• awk '{ print $2 }' gibt nur die 2. Spalte aus (das ist der Paketname)
• sort -V sortiert die Artikel nach Versionsnummer
• sed -n '/'`uname -r`'/q;p' gibt die Zeilen vor dem aktuellen Kernel aus
• xargs sudo apt-get -y purge reinigt die gefundenen Kernel

sed :

• -n sagte sed es soll still sein
• `uname -r`gibt das aktuell installierte Kernel-Release aus – wir binden es in Backticks ein, so dass die Ausgabe als Teil des Befehls eingebunden wird (Sie könnten dies auch mit  $(uname -r) sehen).
• /something/q sagt stop, wenn Sie ’something‘ (in diesem Fall wird etwas von uname -rausgegeben) – das / umgibt einen regulären Ausdruck.
• p ist Drucken
• das ; ist der Befehl separtor, also /something/q;p sagt quit, wenn du etwas abgleichst, sonst print

Insgesamt wird sed -n '/'`uname -r`'/q;p' die Zeilen ausgeben, bis sie mit dem aktuellen Kernelnamen übereinstimmen.

Wenn du paranoid bist (wie ich), kannst du den letzten Teil xargs echo sudo apt-get -y purge machen, so dass der Befehl zum Bereinigen der alten Kernel gedruckt wird, dann kannst du überprüfen, ob nichts Unerwartetes enthalten ist, bevor du ihn ausführst.

deepl.com Translator

askubuntu.com

Der Beitrag Wenig Speicherplatz verfügbar auf boot – Alte Kernel löschen! erschien zuerst auf jybee.com.

Basis dieses Tutorials für einen sicheren SSH-Zugriff mittels RSA-Schlüsselpaar ist eine neue Debian 8 – 64bit Net-Install ohne grafische Oberfläche.

Der SSH-Server auf Debian ist standardmäßig so eingestellt, dass sich root nicht über SSH einloggen kann. Dies ist schon das erste Sicherheitsmaßnahme, die wir auch nicht abändern sollten. So muss ein Angreifer nicht nur das Passwort erraten, sondern auch den Benutzernamen. Dies sind somit schon zwei Unbekannte.

1. Portfreigabe

Um überhaupt von außerhalb mittels SSH auf unseren Debian-Server zugreifen zu können, müssen wir einen Port im Router freigeben.
Hier bietet es sich an, einen x-beliebigen Port (zB.:12345) zu verwenden und diesen an unseren Server Port weiterzuleiten. Dies ist unser 1. Sicherheitsfeature, da Bots auf der Suche nach Schwachstellen oftmals zufällige IP-Adressen und die gängigsten Ports testet, ob etwas antwortet. Alle 65535 Ports abfragen dauert relativ lange und ist daher nicht sehr geläufig.

Nun erfolgt der erste Zugriff mittels SSH auf unseren Debian-Server.

Beim Klick auf Open sollte folgende Warnung erscheinen. Die ist beim ersten Verbindungsversuch mittels SSH normal. Sollte diese Meldung bei unveränderter Konfiguration erneut erscheinen, dann könnte das System kompromittiert sein. In unserem Fall können wir beruhigt auf „Ja“ klicken.

Nun können wir uns mit unserem Benutzer einloggen.

Nach erfolgtem Login holen wir uns Superuser-Rechte mittels des Befehls su.
Nun möchten wir auch noch den SSH-Port auf unserem Server in einen beliebigen Port ändern. Dafür öffnen wir mit folgendem Befehl mit nano die Konfigurationsdatei von SSHD.

nano /etc/ssh/sshd_config

Da Port 22 der gängige SSH-Port ist, werden wir diesen auch auf einen schwer zu erratenen ändern.
Nun muss die geänderte Konfigurationsdatei gespeichert werden. Danach müssen wir den SSH-Dienst neustarten.

/etc/init.d/ssh restart

Die aktive Verbindung wird dadurch nicht getrennt, da bestehende SSH-Verbindungen von der Änderung nicht betroffen sind. Wir sollten den SSH-Zugriff über den neuen Port erst mit einer neuen Terminal-Session ausprobieren, bevor wir unser aktuellen Terminal schließen.

Bevor wir uns jedoch wieder verbinden, müssen wir unsere Portfreigabe im Router noch auf den neuen Port abändern, da die Portfreigabe ja nun nicht mehr an den Standardport 22 sondern in meinem Beispiel an 41235 weitergeleitet muss.

2. Mailversand bei erfolgten SSH-Login

Eine weitere Sicherheitsmaßnahme ist, dass man sich bei einem erfolgtem SSH-Login per Email informieren lässt. Dafür benutzen wir das Programm sendEmail, was uns ermöglicht, Mails mittels Shell-Script zu versenden. SendEmail (nicht zu verwechseln mit sendmail) ist ein in Perl geschriebener SMTP-Client und kann mit folgendem Befehl installiert werden.

apt-get install sendemail

Um Emails versenden zu können, brauchen wir noch einen SMTP-Server. In der Regel bietet das jeder Freemail-Anbieter an. Da ich meine Webseiten auf all-inkl.com hoste, habe ich dort die Möglichkeit mir dafür extra ein Mailpostfach einzurichten.

Damit bei erfolgreichem Login eine Mail verschickt wird, bearbeiten wir mit dem Editor nano die /etc/ssh/sshrc.

nano /etc/ssh/sshrc

Dort fügen wir unten folgende Zeilen ein:

ip=`echo $SSH_CONNECTION | cut -d “ “ -f 1`
logger -t ssh-wrapper $USER login von $ip
echo „Benutzer $USER hat sich von IP $ip eingeloggt.“ | sendEmail -q -f Absender@server.com -s Servername:Port -xu Benutzername -xp Passwort -t Empfänger@server.com -o tls=yes -u „SSH-Login auf Debian Testmaschine“

Folgende Angabe müssen für den Mailversand angepasst werden:
-q = quiet (Es erfolgt keine Textausgabe im Terminal, wenn die Mail versandt wurde)
-f = from (hier die Absendemailadresse eingeben)
-s = Server (Die Adresse der SMTP-Servers mit nachstehender Portangabe)
-xu = User (Loginname für SMTP-Server)
-xp = Passwort (Passwort für SMTP-Server)
-t = to (Empfängeradresse)
tls sollte auf yes stehen, damit eine verschlüsselte Verbindung mit dem SMTP Server aufgebaut wird.
– u = Subject (Betreff der Email)

Nach dem Speichern der /etc/ssh/sshrc können wir durch das Öffnen einen neuen Terminals den Mailversand testen.

3. Login-Versuche begrenzen mit Fail2Ban

Damit BruteForce-Attacken nicht unendlich viele Loginversuche vornehmen können, begrenzen wir die Anzahl der möglichen Versuche mittels des Programms Fail2Ban. Dieses installieren wir mit folgendem Befehl:

apt-get install fail2ban

4. Unbenutze Ports schließen

Da jeder geöffnete Port ein potenziellen Sicherheitsrisiko darstellt, sollten wir alle Ports schließen, die wir nicht benötigen. Dafür müssen wir erstmal wissen, welche Ports durch welche Programme geöffnet sind. Port sind nicht einfach offen, sondern werden von Programmen geöffnet, welche dann an diesem Port lauschen. Mit folgendem Befehl kontrollieren wir die geöffneten Ports:

netstat -tulpen | grep -v ‚127.0.0.1‘ | grep -v ‚::1:‘

Das Resultat:

Wir sehen direkt unseren Port 41235 mit der Info sshd. Jedoch können wir auch die Dienste rpc.statd, rpcbind und dhclient erkennen. Dhclient ist für den reibungslosen Betrieb mit einem DHCP-Server im Netzwerk zuständig und akzeptiert auch nur entsprechende Pakete. Alle anderen Pakete werden verworfen. Rpc.statd und rpcbind sind jedoch für NFS-Freigaben notwendig. Da ich diese nicht benötige, werde ich diese schließen.

Um die Dienste zu stoppen verwenden wir folgenden Befehle:

service rpcbind stop

service nfs-common stop

Natürlich könnten wir NFS mit folgendem Befehl auch komplett deinstallieren, was ich jedoch nicht getan habe:

apt-get –purge remove nfs-kernel-server nfs-common portmap

Nun sollte die Liste unserer offenen Ports in etwa so aussehen:

5. IPv6 deaktivieren

Solange IPv6 noch nicht produktiv genutzt wird, sollte bzw kann man es ruhigen Gewissens abschalten.
Mit

ip addr show | grep inet6

können wir gucken, ob wir eine IPv6 adresse erhalten haben:

Mit folgendem Befehl können wir IPv6 deaktivieren:

echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6

Nach einem Neustart mit dem Befehl reboot sollten wir keine IPv6-Adresse mehr erhalten:

6. SSH-Login mit RSA-Schlüsselpaar

Ein RSA-Schlüsselpaar ist ein sicherer Weg, sich an seinem SSH-Server zu authentifizieren. Während ein Passwort erraten  oder mittels BruteForce-Attacke durchprobiert werden kann, ist es nahezu unmöglich einen RSA-Schlüssel zu entschlüsseln. Beim Generieren des RSA-Schlüsselpaares werden zwei Schlüssel erstellt: Ein öffentlicher und ein privater. Der öffentliche wird auf dem Server abgelegt und ab dann kann man sich nur noch eingeloggen, wenn man über den privaten Schlüssel verfügt. Vereinfacht vorstellen kann man sich das so, als ob der öffentliche Schlüssel ein Türschloss ist und der private Schlüssel der dazugehörige Schlüssel. Wenn jemand den privaten Schlüssel in die Hände bekommt, muss er auch erstmal wissen, zu welchem Türschloss dieser gehört. Noch dazu kann man seinen geheimen Schlüssel auch noch mit einem Passwort sichern. In der PuTTY-Standardkonfiguration muss man beim Verbindungsaufbau auch den Benutzernamen angeben, mit dem man sich einloggen möchte. Dieser lässt sich aber auch vordefinieren. Dazu später mehr.

Zuerst erstellen wir uns ein Schlüsselpaar. Dies erledigen wir nicht auf dem Server. Ich werde die Erstellung des Schlüsselpaares auf einem Linux-Client als auch auf einem Windows Client erklären.

6.1 RSA Schlüsselpaar unter Linux einrichten

Wir öffnen in unserem Linux ein Terminal und geben folgenden Befehl ein:

ssh-keygen -t rsa

Beim bestätigen mit Enter werden wir „Enter file in which to save the key (/home/demo/.ssh/id_rsa):“ gefragt. Diese Frage können wir einfach mit Enter bestätigen. Wenn wir unseren Schlüssel mit einem Passwort verschlüsseln wollen, müssen wir bei der Frage „Enter passphrase (empty for no passphrase):“ unser Passwort eingeben und nach dem Drücken von Enter dieses noch einmal bestätigen. Nun wird das Schlüsselpaar erzeugt. Dies sollte in etwa so ausehen:

Zu finden ist unser Schlüsselpaar unter dem angegebenen Ordner ~/.ssh:

Nach dem Erstellen des RSA Schlüsselpaares wollen wir die Schlüssel mit folgendem Befehl auf unseren Server kopieren:

ssh-copy-id benutzer@server -p Port

(Falls der Port wie oben beschrieben geändert wurde müssen wir ein „-p“ und nach einem Leerzeichen gefolgt die Portnummer angeben)

Nach der Eingabe von Yes und Bestätigen mit Enter sollten wir unseren Schlüssel auf unserem Server mit

nano ~/.ssh/authorized_keys

aufrufen können.

Machen wir nun ein neues Terminal auf und verbinden uns mit unserem Server, dann wird automatisch der Login mittels des RSA-schlüsselpaares durchgeführt. Jedoch können wir uns immernoch von einem anderen Computer, der den privaten Schlüssel nicht besitzt, immer noch mit Benutzername und Passwort anmelden. Um dies zu verhindern müssen wir auf dem Server in der SSH-Config die Passwortauthentifizierung auf „no“ setzen:

nano /etc/ssh/sshd_config

PasswordAuthentication no

Nun ist ein Login nur noch möglich, wenn man über den privaten RSA-Schlüssel verfügt. Ist für diesen ein Passwort gesetzt, dann benötigt man dieses natürlich auch, um den privaten Schlüssel zu entsperren. Der Login sieht dann in etwa so aus:

Nachdem man den Schlüssel entsperrt hat, ist man sofort eingeloggt:

6.1.1 RSA-Schlüsselpaar in PuTTY-ppk-Schlüssel umwandeln

Wenn wir uns jetzt jedoch zB auch von einer Windows Maschine mittels PuTTY einloggen wollen, brauchen wir dort natürlich auch noch den privaten Schlüssel. PuTTY benötigt den Private Key jedoch im .ppk-Format. Mittels des Programms PuTTYgen lässt sich diese jedoch aus unserem vorhandenen Schlüssel erzeugen:

Nachdem wir nun auf „Save private key“ geklickt haben, können wir den gespeicherten Schlüssel in PuTTY unter Connection >> SSH >> Auth >> Browse einfügen.

6.2 RSA-Schlüsselpaar unter Windows erstellen

Der Beitrag Sicherer SSH-Zugriff mit RSA-Schlüsselpaar auf Debian Server erschien zuerst auf jybee.com.

1.) KeePass2 installieren

KeePass2 ist direkt aus dem LinuxMint Repository, also über die Anwendungsverwaltung, installierbar.

2.) KeeFox installieren

Nun installieren wir das KeeFox Addon über die Mozilla Firefox Addon Webseite .

3.) KeeFox konfigurieren

Wenn wir Firefox nun neustarten bekommen wir schon den Hinweis, dass KeeFox noch installiert werden muss.

Dafür müssen wir die Laufzeitumgebung Mono installieren. Hier ist wichtig, dass man mono-complete auswählt.

4.) KeeFox und KeePass konfigurieren

Damit wären alle notwendigen Programme installiert. Nun bedarf es noch einiger Anpassungen. Zuerst erstellen wir im KeePass2-Programmordner den Ordner „plugins“. Dies macht man am Besten über das Terminal mit dem Befehl sudo mkdir /usr/lib/keepass2/plugins

Nun muss die Datei KeePassRPC.plgx aus dem KeeFox-Ordner in den KeePass2-Ordner kopiert werden. Dafür verwende ich wieder das Terminal mit dem Befehl sudo cp /home/tt/.mozilla/firefox/isnf5ex7.default/extensions/keefox@chris.tomlinson/deps/KeePassRPC.plgx /usr/lib/keepass2/plugins

Nun muss dem KeeFox Addon noch gesagt werden, an welchem Ort sich die KeePass-Installation befindet. Dafür klickt man auf das KeeFox-Plugin, wodurch sich das Menü öffnet und wählt dann den Punkt Einstellungen. In den KeeFox-Optionen müssen wir im Reiter „KeePass“ den genauen Pfad angeben. Dieser lautet in meinem Falle (Linux Mint und KeePass-Installation über die Linux-eigene Anwendungsverwaltung) /usr/lib/keepass2. Der Pfad zur Mono-Installation sollte bereits eingetragen sein.

5.) KeeFox autorisieren

Nun muss Firefox neugestartet werden. Nach dem Neustart muss die Verbindung zwischen KeeFox und KeePass autorisiert werden. Dafür blendet KeePass ein Passwort ein und KeeFox öffnet eine Eingabemaske.

Ist dies geschehen, bietet uns KeePass an eine vorhandene Datenbank zu öffnen oder eine neue zu erstellen. Geschafft!

Der Beitrag KeePass mit KeeFox unter Linux Mint installieren erschien zuerst auf jybee.com.

AirVPN

Um alle Geräte mit dem VPN zu verbinden, macht es Sinn, den Router als VPN-Client laufen zu lassen, sodass alle mit dem Router verbundene Geräte automatisch getunnelt werden. Jedoch habe ich mit einem alten TP-Link TL-WR1043ND nur maximal 8Mb/s und mit einem neueren Asus RT-N65U nur 14Mb/s geschafft. Das ist nicht gerade viel, was dann von einer 100Mbit-Leitung übrig bleibt. Das liegt zum größten Teil an den kleinen Prozessoren in den Routern, immerhin kostet das Ver- und Entschlüsseln einer openVPN-Verbindung Rechenleistung. Die Lösung: Ein alten Computer oder eine Virtuelle Maschine als Gateway.

Debian Server in einer Virtuellen Maschine aufsetzen

Wie man einen Debian-Server aufsetzt, möchte ich hier nicht ausführlich erklären, da das Thema ein anderes ist. Ich werde die Installation aber kurz durchgehen. Zuerst benötigt man ein Debian-Image. Dies kann man sich kostenlos bei debian.de herunterladen. Für unser Vorhaben reicht eine kleine netinst-Iso.  In den meisten Fällen wird die amd64-Version richtig sein.

Wir wählen „Install“, da wir unser VPN-Gateway so ressourcenschonend wie möglich aufsetzen möchten. Eine grafische Oberfläche brauchen wir dazu nicht. Nun werde ich nur die Debian Installation nur in Stichpunkten durchgehen, da diese auch nicht das Hauptthema dieses Artikels ist. Ausserdem ist sie nicht schwer.

Zuerst wählen wir die Sprache, unser Land und das Tastaturlayout. Als Rechnernamen vergeben wir was aussagekräftiges wie zum Beispiel „Gateway“. Das ist natürlich jedem selber überlassen. Den Domainnamen lassen wir leer. Nun müssen wir das root-Passwort festlegen. Danach einen Benutzernamen und auch für diesen ein Passwort. Zeitzone sollte auch für jeden einleuchtend sein. Als Partitionierungsmethode wählen wir „Geführt – vollständige Festplatte verwenden“. Bei mir läuft das Debian als VM auf einem Hypervisor. Eine 5GB Festplatte reicht völlig aus. Im nächsten Schritt müssen wir die zu partitionierende Festplatte wählen. Dann „Alle Dateien auf eine Partition, für Anfänger empfohlen“. „Partitionierung beenden und Änderungen übernehmen“ wählen. Nachdem wir mit Ja bestätigt haben, dass die Änderungen auf die Festplatte geschrieben werden sollen, installiert sich nun das Grundsystem.

Ist diese abgeschlossen, müssen wir ein Land des Debian-Archiv-Spiegelservers und danach den Spiegelserver selber wählen. Hier sollten man etwas in seiner Nähe wählen. HTTP-Proxy kann in der Regel leer gelassen werden. Dann sollte sich Debian aktuelle Updates holen. Keine Sorge, das dauert nicht so lange wie bei Microsoft!

Nun werden wir gefragt, ob wir an der Paketverwendungserfassung teilnehmen wollen. Da kann man wählen was man möchte, man hat keinen Nachteil wenn man es (nicht) macht.

Bei der zu installierenden Software wählen wir die Debian Desktop Enviroment mittels Leertaste ab. Diese brauchen wir nicht, Druckserver ebenfalls entfernen, dafür aber SSH anhaken, damit wir uns später mittels Putty raufschalten können.

Die Frage, ob der Grub-Bootloader in den Master Boot Record installiert werden soll bejahen wir und wählen im nächsten Schritt das Gerät aus. In der Regel /dev/sda. Nun das Installationsmedium entfernen und neustarten. Nach dem Neustart sollten wir folgendes sehen:

Damit ist die Grundinstallation unseres Debian-Servers abgeschlossen. Nun können wir alles weitere über PuTTY machen, sprich für können den Server von Monitor und Tastatur erlösen und ihn nach ganz hinten in die Rumpelkammer verbannen.

openVPN-Client als Gateway auf Debian-Server einrichten

Es lohnt sich, die IP unseres Gateway-Servers als Saved Session in PuTTY abzuspeichern. Die IP bekommt ihr über den Router heraus. Wenn kein Zugriff auf den Router besteht, dann einmal auf dem Server einloggen und sich mittels „ifconfig“ die Netzwerkkonfigurationen anzeigen zu lassen. Dies erfordert Root-Rechte. Beim erstmaligen Verbinden mit PuTTY erscheint eine Warnmeldung, die mit „Ja“ bestätigt werden muss. Nach Eingabe des Benutzers und des Passworts sollte es in etwa so ausehen:

Mit dem Befehl su bekommen wir nach erfolgreicher Eingabe des root-Passwortes Administratorrechte. Nun müssen wir das openVPN-Paket installieren. Das machen wir mit dem Befehl

apt-get install openvpn

Nun benötigen wir noch unsere OpenVPN-Konfig-Datei. Diese erkennt man an der Dateiendung .ovpn. Die ovpn-Datei bekommen wir bei unserem VPN-Anbieter.

Jetzt müssen wir diese oVPN-Datei auf unseren Server kopieren. Ich verwende dazu WinSCP. Falls wir in Putty unseren Server als Verbindungsziel gespeichert haben, können wir uns dieses in WinSCP einfach von Putty importieren.

Als Benutzernamen verwenden wir unseren Debian-Benutzer. Aus Sicherheitsgründen ist der Zugriff mit dem Root-User standardmäßig bei Debian nicht aktiviert.

Wir kopieren nun erstmal unsere OVPN-Datei in unser Home-Verzeichnis des Benutzers und führen den Befehl openvpn Dateiname.opvn aus, um zu testen, ob sich unser Gateway-Server sauber mit dem VPN-Server verbindet. Dafür müssen wir uns im richtigen Verzeichnis befinden, also dort, wo wir unsere ovpn-Datei hinkopiert haben.

Nun sollte sich unser Debian-Server mit dem VPN-Server verbunden haben. Das sehen wir daran, wenn folgendes angezeigt wird:

Wir wollen jetzt jedoch nochmal auf Nummer sicher gehen, dass dem wirklich so ist. Dazu machen wir uns ein zweites Putty-Fenster auf, loggen uns ein und können zum Beispiel folgenden Befehl verwenden, um unsere öffentliche IP-Adresse herauszufinden:

wget http://ipinfo.io/ip -qO –

Für mehr Details sollte man sich wieder mittels su und dem root-Passwort Administratorrechte holen und mittels des Befehls

ifconfig

sehen wir auch, dass ein weiteres Netzwerk-Interface (tun0) angelegt wurde.

Die OpenVPN-Verbindung trennen wir wieder indem wir im PuTTY-Fenster mit dem laufenden openVPN-Prozess Strg + C drücken. Damit wird die Verbindung sauber getrennt.

Debain VPN-Client als Gateway einrichten

Nun müssen wir noch bewerkstellingen, dass wir sämtlichen Traffic unserer Clients über den Gateway-Server durch den VPN-Tunnel nach draußen schicken können. Dazu müssen wir unserem Debian Server sagen, dass sämtlicher Datenverkehr von eth0 über tun0 wieder rausgeleitet wird. Dazu benutzen wir iptables.

Einen sehr ausführlichen Artikel darüber findet man hier: Ubuntu Help

Um die ganze Sache jedoch abzukürzen, hier der leichtere Weg:

Stellt sicher, dass ihr als root eingeloggt seid. Dann gebt ihr folgende Befehle ein. Nicht wundern, bei der Eingabe bekommt man kein Feedback, also einfach einen nach dem anderen so eingeben. Spätestens jetzt lernt ihr es zu schätzen, dass ihr PuTTY nutzt und copy-pasten könnt!

sh -c ‚echo 1 > /proc/sys/net/ipv4/ip_forward‘

iptables -A FORWARD -o tun0 -i eth0 -s 192.168.1.0/24 -m conntrack –ctstate NEW -j ACCEPT

iptables -A FORWARD -m conntrack –ctstate ESTABLISHED,RELATED -j ACCEPT

iptables -A POSTROUTING -t nat -j MASQUERADE

iptables-save | tee /etc/iptables.sav

Das war es auch schon. Nun müssen wir noch in der Konfigurationdatei /etc/sysctl.conf eine kleine Einstellung vornehmen. Öffnet die Datei mit dem Befehl

nano /etc/sysctl.conf

Sucht den Punkt #net.ipv4.ip_forward=1 und entfernt die Raute (#) davor.

Mittels Strg + X, J und Enter speichern wir die Datei und schließen Nano. Nun wird es Zeit unser VPN-Gateway mit einem Client zu testen!

Client-Konfiguration für Debian VPN-Gateway

Unter Windows gehen wir dafür in die Systemsteuerungen unter Systemsteuerung\Netzwerk und Internet\Netzwerkverbindungen und wählen auf unserer aktiven Netzwerkschnittstelle mittels Rechtsklick „Eigenschaften“ aus.

Dann klicken wir einmal auf Internetprotokoll Version 4 (TCP/IPv4) aus und klicken auf Eigenschaften.

Nun müssen wir die IP-Adressen manuell eintragen. Unter IP-Adresse sollte man die eintragen, die man auch schon vorher vom DHCP-Server zugewiesen bekommen hat. Subnetzmaske bleibt in den meisten Fällen 255.255.255.0 und unter Standardgateway wählen wir die IP unseres Debian-VPN-Gateway-Servers. In meinem Falle 192.168.178.6.

Unter DNS habe ich noch Adressen vom opennicproject eingetragen.

Die meisten VPN-Anbieter stellen auch eigene DNS-Server bereit, natürlich kann man auch die bekannten von Google (8.8.8.8 oder 8.8.4.4) nehmen. Mir ist nur der von der Telekom auf die Nerven gegangen, als ich jedes mal bei einem Tippfehler auf der T-Online-Seite gelandet bin.

Damit wir nun nicht ständig die Netzwerkeinstellungen auf sämtlichen Geräten ändern müssen, sobald wir mal ein einem anderen Netzwerk sind, bietet es sich an, einen zweiten Router oder AccessPoint als Zugangspunkt für alle möglichen Clients, wie Smartphones, Notebooks, Tablets, etc. etc zu nutzen. In dem zweiten Router, welcher auch ein alter ausrangierter sein kann, müssen wir nur bei den WAN Einstellungen unseren GatewayServer als Gateway eintragen. Schon kümmert sich unser zweiter Router darum, dass sämtlicher Traffic von sämtlichen Geräten durch den VPN-Tunnel geschleust wird. In meinem Falle nutze ich den Asus RT-N65U. Falls ihr euch über WLAN verbindet, sollte ihr sicher gehen, dass dieses nicht euer neuer Flaschenhals ist!

Nun zum Resultat der ganzen Geschichte:

Von meiner 100Mbit-Leitung von der Telekom bekomme ich annähernd alles über den Tunnel!

Auch der Ping hat sich nicht groß verschlechtert. Dafür das der Datenverkehr jetzt durch 2 Router, ein Gateway und einen VPN-Server muss hat er sich nur um rund 5 Millisekunden verschlechtert. Die Download und Upload-Raten werden bei wiederholten Tests bestimmt auch noch ein bisschen höher sein. Aber mit 5% Verlust im Vergleich zu direkten VDSL-Leitung kann ich gut leben.

Damit schafft man es so manches Mal unter die Top 10-User-Speed-Listen von AirVPN.

Der Beitrag Debian VM als VPN-Gateway nutzen erschien zuerst auf jybee.com.

Googles PageSpeed-Tools

BILDER OPTIMIEREN!

Wenn man unzählige Bilder schon mehrfach hochgeladen hat, weil man kurz mal nicht dran gedacht hat, sie zu komprimieren, ist es wirklich nervig. Ich möchte kurz verraten, welche Tools ich dafür nehme, damit Google aufhört zu meckern. Bedenkt: Sollten eure Bilder zu groß sein, kann das Folgen für das Ranking haben. Das muss nicht sein. Genauso wenig, wie unoptimierte Bilder zu verwenden. Klar, wegen ein paar Byte wird Google niemanden abstrafen und heutige Internetanschlüsse sind mittlerweile so schnell, dass man kaum bemerkt, ob ein Bild mal 100KB größer ist, als es eigentlich sein müsste, aber man denke, ab die Leute mit schmaler Internetleitung oder mal Edge auf dem Smartphone. Kennt jeder.

Hier also diese Tools, die ich dafür verwende. Ich muss dazu sagen, dass ich bei einer Bearbeitung in Photoshop schon immer „Für Web speichern“ nutze, aber es kommt auch vor, dass Google die Bilder trotzdem noch beanstandet. Wer also auch nicht die XXX€ für Photoshop ausgeben möchte um ein paar Bilder zu komprimieren, kann ich diese Software empfehlen:

Als Windows Programm: RIOT (Radical Image Optimization Tool) von dem Rumänen Lucian Sabo. Das Tolle an RIOT ist, dass man Einstellungen wählen kann oder, wenn gewünscht, das Tool vollautomatisch arbeiten lassen kann. Man hat auch einen Live-Vergleich. Beim Ranzoomen erkennt man dann oftmals die kleinen Unterschiede.

Das zweite Tool, was ich oft benutzt ist das Online-Tool zur Bildoptimierung von Kraken.io Das lässt in der Free-Version wenig einstellen, erfüllt aber seinen Zweck der Bild-Komprimierung mehr als gut!Ich hoffe, ich konnte euch weiterhelfen, bzw. hoffe, dass Ihr noch einen tollen Tipp habt bzgl. Bilder optimieren! Lasst mir gerne einen Kommentar da, was ihr für Tools benutzt!

Der Beitrag Bilder komprimieren fürs Web! erschien zuerst auf jybee.com.

Heute bekam ich plötzlich eine Mail von meinem AntiVirus-Plugin mit dem Hinweis auf einen Virus-Verdacht. Ich loggte mich also ein und machte nochmal eine manuelle Prüfung und siehe da:

In der Theme-Datei /themes/flat/class-tgm-plugin-activation.php beanstandete das Plugin folgenden Code:

if ( ! WP_Filesystem( $creds ) ) {

Doch was tun als Programmier- und PHP-Laie? Auf jeden Fall die Ruhe bewahren und einmal ein anderes Theme aktiviert. Da lief der der AntiVirenScanner auch sauber durch. Also das Theme Flat einmal gelöscht und neu installiert. Doch auch dann erschien die Meldung wieder.

Googlen half relativ wenig weiter, ich landete nur auf irgendeinem WordPress-Hacker-Forum, was meiner inneren Ruhe nicht gerade gut tat. Also beschloß ich mich die Leute zu kontaktieren, die es wissen sollten. Ich kontaktierte Themeisle.com über das Support-Formular und WOW! Genau 7 Minuten später hatte ich eine Antwort in der Mailbox!

Resultat: Der Support ging von einem Fehlalarm aus. Er hatte die Webseite einmal von virustotal.com durchsuchen lassen mit dem Ergebniss, dass die Seite sauber sein. Darauf war ich in dem Schreck garnicht gekommen. Außerdem hatte er mir mal geraten einen anderen WordPress-VirenScanner zu testen und siehe da: mit Wordfence war alles sauber! Obwohl ich von den Plugins von Sergej Müller sehr begeistert bin, werde ich jetzt wohl Wordfence statt sein wpAntiVirus behalten. Es bietet genaue Einblicke, wo es genau einen Verdacht gefunden hat. Die Webseite von Wordfence bietet übrigens interessante Live-Statistiken. Also KEIN Virus in irgendwelchen WordPress-Dateien! Jetzt kann ich beruhigt wieder Kaffee trinken!

Der Beitrag Virus Warnung bei WordPress Theme Flat erschien zuerst auf jybee.com.

https://ssl-account.com/owncloud.meineDomain.de

Die funktioniert nach ein paar Einstellungen auch ganz gut, sieht aber nicht sehr schön aus. Schöner wäre ganz klar:

https://owncloud.meineDomain.de

Doch auch dies lässt sich bei All-inkl.com einfach und kostenlos bewerkstelligen. Ein gebuchtes Paket ist natürlich Voraussetzung. Bei all-inkl.com kann man sich selbst kostenlose SSL-Zertifkate ausstellen. Der Haken: Da die Zertifikate nicht von einer offiziellen CA (certificate authority oder certification authority, engl. für Zertifizierungsstelle) wie zB VeriSign sondern von euch selber validiert sind, warnen Browser vor einer angeblichen unsicheren Verbindung. Der Datentransfer erfolgt aber verschlüsselt. dazu später mehr.

Das Tolle an der ganzen Sache mit der eigenen Cloud bei All-Inkl.com ist nicht nur, dass eure eigene Cloud auf eurem eigenen Webspace auf deutschen Servern bei einem deutschen Anbieter liegt, sondern auch der Preis ist mehr als interessant: Während ihr bei Dropbox für 10€ pro Monat 100GB extra bekommt, habt ihr bei All-inkl.com für 10€ im Monat 250GB, 10 Inklusiv-Domains und jede Menge Dinge zum ausprobieren, rumprobieren und spielen. (Was ihr natürlich nicht mit eurer laufenden Owncloud machen solltet, dafür könnt ihr Unteraccounts anlegen!)

Nun zur Erklärung wie ihr euch eure OwnCloud bei All-Inkl.com mit eigenem SSL-Zertifikat installiert und einrichtet:

Schritt 1

Da wir unsere Owncloud von unseren anderen Dingen in unserem All-Inkl.com-Account ein wenig abgeschottet haben wollen, legen wir uns unseren Unteraccount als Subdomain an. Unsere Owncloud wir dann später unter owncloud.domain.tld oder oc.domain.tld oder was auch immer wir möchten erreichbar sein. Wir füllen alle Felder mit den nötigen Angaben. Ausserdem sollte man bei Datenbanken mindestens eine 1 eintragen. Hier können wir auch den Speicherplatz begrenzen, wenn wir in dem Feld eine 0 lassen ist er unbegrenzt. (Also nur begrenzt durch die Größe unseres All-Inkl.com-Paketes natürlich)

Nach dem Klick auf Speichern sollten wir einen Moment Geduld haben bis All-Inkl den Unteraccount eingerichtet hat -> Tasse Kaffee holen!

Weiter geht’s! Nun loggen wir uns in unserem Unteraccount ein. Dafür rufen wir entweder kas.all-inkl.com auf und geben da unsere Login-Daten ein oder drücken im Hauptaccount, in dem wir ja noch eingeloggt sind, rechts auf den kleinen Login-Button, sofern diese nicht deaktiviert wurden.

Schritt 2

Nun wollen wir unser SSL-Zertifikat erstellen. Dazu gehen wir im Unteraccount im Hauptmenü auf Subdomain und klicken den Button „bearbeiten“

Danach unter SSL-Schutz auf „bearbeiten“

Nun tragen wir unsere Inhaltsdaten ein und setzen die Gültigkeit auf 999 Tage, damit wir das Zertifikat nicht ständig erneuern müssen.

Nun können wir unser SSL-Zertifikat erzeugen. Dies dauert einen Moment.

Schritt 3

Nun gehen wir im Hauptmenü auf der linken Seite auf Tools -> Software-Installation und wählen Owncloud aus. Als Domain wählen wir unsere gewählte Subdomain aus. Das bei den Pfadangaben der Pfad immer noch ohne https:// angegeben ist, macht nichts. Wir sollten aber einen Benutzernamen und eine Email-Adresse angeben. Mit einem Klick auf weiter kommen wir zu Schritt 2 der Owncloud-Installation. Dort wählen wi aus, dass wir eine neue Datenbank anlegen wollen. Nun müssen wir noch die Lizenz und den Haftungsausschluss akzeptieren und „Installation starten“ klicken damit Owncloud auf unserem Webspace bei All-Inkl.com installiert wird. Auch das dauert wieder einen Moment. Während im Hintergrund Owncloud installiert wird bekommen wir schon das automatisch generierte Passwort zu unserem gewählten Benutzernamen.

Schritt 4 – Der erste Besuch

Nun geben wir den Link zu unserer Owncloud an und achten darauf, dass wir https://… verwenden.

Sobald wir auf Enter drücken werden wir vom Browser eine Warnung bekommen, dass es sich angeblich um eine unsichere Verbindung handelt. Dies liegt daran, das die gängigen Zertifizierungsstellen, die sonst SSL-Zertifikate ausstellen bzw. validieren in Browsern gespeichert sind. Da wir unser SSL-Zertifikat jedoch selber ausgestellt haben, aber dem Browser nicht als Zertifizierungsstelle bekannt sind, zeigt er eine Warnung. Technisch ist unser Zertifikat jedoch nicht schlechter als andere und verschlüsselt genauso die Verbindung zu unserer Owncloud, wie ein gekauftes SSL-Zertifikat.

Wir wählen in unserem Browser bei der Warnung also das wir die Seite trotzdem besuchen möchten. Bei Google Chrome müssen wir dazu auf „Erweitert“ klicken und sehen auch den Grund für die Warnung:

„Dieser Server konnte nicht beweisen, dass er owncloud.meineDomain.de ist. Sein Sicherheitszertifikat wird vom Betriebssystem Ihres Computers als nicht vertrauenswürdig eingestuft. Mögliche Gründe sind eine fehlerhafte Konfiguration oder ein Angreifer, der Ihre Verbindung abfängt.“

Wir wählen „Weiter zu owncloud.meineDomain.de (unsicher)“

Jetz sehen wir die Login-Maske unserer Owncloud. Wenn wir nun einmal in der Adresszeile links auf das kleine Schloß klicken bekommen wir weitere Infos. Unter anderem auch, dass die Verbindung verschlüsselt ist.

Bei Firefox bekommen wir die Meldung „Dieser Verbindung wird nicht getraut.“ wählen dann aber „Ich kenne das Risiko“ und klicken auf „Ausnahme hinzufügen“

Dann auf „Sicherheits-Ausnahmeregel bestätigen“

Auch bei Firefox können wir einsehen, dass die Verbindung verschlüsselt ist. Dazu klicken wir in der Adressleiste vor der Adresse auf das Schloßsymbol und danach auf den Button „Weitere Informationen“. Dort können wir die Informationen zu unserem Zertifikat betrachten und sehen unter technische Details auch die Info „Hochgradige Verschlüsselung“

(Bei der Einrichtung von OwnCloud bei All-Inkl über den Service ssl-Account.com, für das es unzählige Anleitungen im Internet gibt, hat übrigens die selbe Verschlüsselung, nur, dass das Zertifikat von der COMODO CA Inc validiert ist und da diese Zertifizierungsstelle (kurz CA, für engl. certificate authority oder certification authority) den Browsern bekannt ist, bekommen wir dann keine Warnung angezeigt.

Mal zum Vergleich https://www.google.de:
(Das Zertifikat ist übrigens auch von Google Inc selber validiert, nur kennt jeder Browser google und akzeptiert Google auch als Validiereungsstelle für SSL-Zertifikate.

Schritt 5

Nun gehen wir rechts oben auf unseren Benutzernamen und klicken auf Administration

In den Einstellungen setzen wir unter Sicherheit den Haken unter HTTPS erzwingen.

Außerdem sollten wir unter Persönliches noch das Passwort ändern und eine Email-Adresse für den Passwort-Reset hinterlegen.

Schritt 6 – Besitzrechte der Ordner ändern für Update

Wir sollten nun noch die Besitzrechte der Ordner ändern, damit es bei einem Update von Owncloud nicht zu Fehlermeldungen kommt. Dafür kehren wir zurück ins KAS von All-Inkl.com und wählen links im Hauptmenü Tools -> Besitzrechte. Nun wählen wir beim Pfad das Wurzelverzeichnis von owncloud also owncloud.meineDomain.de aus und machen ein Haken bei rekursiv, damit auch die Unterordner und Dateien bearbeitet werden.

Als Benutzer wählen wir PHP-User aus. Speichern. Die Umstellung der Besitzrechte dauert einen Moment,läuft aber im Hintergrund. Sollt es bei einem Update von Owncloud doch zu einer Fehlermeldung kommen, Cookies löschen und die Seite aktualisieren.

Schritt 7 – Clients

Nun können wir unsere Owncloud benutzen und uns an die Installation der Clients machen.

Bei der Einrichtun des Windows-Clients bekommen wir die Warnung: „Das Zertifikat ist selbstsigniert und daher nicht vertrauenswürdig.“ Hier müssen wir ein Häkchen machen bei „Diesem Zertifikat trotzdem vertrauen“ und auf Okay klicken. Schon synct der Windows Desktop Client über eine verschlüsselte SSL-Verbindung.

Bei Android bekommen wir eine ähnliche Warnung, die Verbindung ist aber auch hier selbstverständlich verschlüsselt.

Fazit:

Wenn man viel anderen Leuten freigeben will, sollte man sich überlegen ein eigenes Zertifikat zu benutzen, da die Leute natürlich immer die Browser-Warnung bekommen, dass der Besuch der Seite unsicher wäre.

Da man ja möglichst wenig unter einem Administrator arbeiten soll, kann man sich nun noch einen Standardbenutzer anlegen unter dem man seine Dateisyncronisation betreibt.
Zusammengefasst: Die Verbindung  ist mit unserem Zertifikat genauso verschlüsselt wie mit einem Zertifikat von VeriSign & Co, da aber Browser uns als Vergabestelle von Zertifikaten logischerweise nicht kennen, gibt es eine Warnung.

Das selbst erstellte Zertifikat kann natürlich im Nachhinein von einer offiziellen Zertifizierungsstelle validiert werden. Dafür ist aber wichtig, dass die Adressangaben, die man bei der Erstellung des Zertifikates gemacht hat mit den Whois-Angaben eurer Webseite übereinstimmt.

Der Beitrag OwnCloud mit SSL-Zertifikat bei All-inkl.com ohne SSL-Account.com erschien zuerst auf jybee.com.

Um den Hostnamen des Raspberry Pis zu ändern, loggen wir uns erst einmal mit unserem Benutzernamen und dem dazugehörigen Passwort ein.

Dann öffnen wir mittels nano die Datei /etc/hostname mit SuperUser-Rechten:

sudo nano /etc/hostname

In dieser Datei steht nur der Hostname und keine weiteren Infos. Einfach nur „raspberrypi“ mit dem gewünschten Hostnamen ersetzen. Beim Hostnamen sind keine Leerzeichen zu verwenden.

Danach speichern wir mittels Strg + X, y und Enter.

Als nächstes ändern wir die Hosts-Datei mit:

sudo nano /etc/hosts

Auch die hosts-Datei wieder mit Strg + X, y und Enter speichern und schließen.

Nun ist der Raspberry nach einem Reboot mittels

sudo shutdown -r 0

auf seinen neuen Namen „getauft“ und sollte unter diesem im Netzwerk erkennbar sein. Das können wir, wenn wir wieder im Raspberry Pi eingeloggt sind, mit dem einfachen Befehl

hostname

auch nochmal überprüfen.

Der Beitrag Raspberry Pi’s Hostname ändern im Raspbian erschien zuerst auf jybee.com.

lirc_rpi: gpio chip not found!

Nun habe ich ein bisschen gegoogelt und bin darauf gestoßen, dass es Änderungen im Kernel gab und man solle sich damit befassen: Raspberry Pi Configuration Device Tree..

Auch das getan aber als Laie war ich damit etwas überfordert.

Nun bin ich darauf gestoßen, dass man

dtoverlay=lirc-rpi

in die config.txt unter /flash eintragen soll. Siehe hier und hier. ACHTUNG! Damit habe ich mir 4 mal die Installation zerschossen, sodass der Raspberry Pi 2 mit OpenELEC nicht mehr hochfuhr.

Zur meiner Lösung:

Als erstes habe ich /flash mit Schreibrechten gemountet:

mount /flash -o remount,rw

Dann in des besagte Verzeichnis gewechselt:

cd /flash

Dann mit nano die config.txt geöffnet:

nano config.txt

Und dann der entscheidende Unterschied:

device_tree_overlay=lirc-rpi

unten in die config.txt eingetragen

Mit Strg-X, Y und Enter die Datei speichern und schließen.

Nun mittels

reboot

den Raspberry neustarten und siehe da: es funktioniert. OpenELEC startet normal durch.

Wir loggen uns wieder mit putty über SSH ein und checken das ganze nochmal:

dmesg |grep lirc

sollte nun folgendes zutage fördern:

Der Beitrag RPi2 openELEC gpio chip not found! IR-Receiver erschien zuerst auf jybee.com.