Beiträge von CmdrXay

    Hay,

    da ich mich mit dem Thema schon länger beschäftige, würde ich zum Geschäftsmodell noch die Abwicklung von den "anderen" Online-Präsenzen hinzufügen, insbesondere soziale Medien.

    Mir ist es selbst schon passiert, dass ein bereits zwei Jahre verstorbener Freund bei Xing einen neuen Kontakt gewonnen hat. Das ist seltsam, aber der andere hat die Kontaktanfrage halt erst jetzt angenommen. Oder ein anderer Verstorbener "empfiehlt" mir bei Facebook bestimmte Seiten. Gruselig. Ich könnte ja auch Verwandschaft sein (Kinder z.B.).

    "Was passiert mit Deinem Facebook-/Instagramm-/Xing-/Pinterest-/(hahaha Google+)- Account?" ist nämlich die andere Frage. Es gibt z.B. die Situation, dass Eltern nicht auf die Facebook-Präsenz ihrer (volljährigen) Kinder im Todesfall zugreifen können, um Beiträge zu entfernen (z.B. Selbstmordankündigung). Das ist ein sehr komplizierter Vorgang - vor allem, da es auch Medien gibt, die erst mal keine Löschung vorsehen und Expertise gefragt ist.

    Und ich weiß selbst aus meiner Bekanntschaft, dass dies ein Thema ist.

    CU, Peter

    Hay,

    Ich möchte mir nur ungern einen anderen Hoster suchen, da netcup sehr sehr gut ist.

    :D

    Es liegt nicht am Hoster, wenn mobile Geräte keine aktuellen Zertifikate benutzen können.

    Das wird Dir mit derselben Seite genauso woanders passieren - sofern Du auf kostenlose Lets Encrypt zurückgreifst. Du könntest allerdings den Versuch unternehmen, Dir ein Zertifikat einer anderen CA zu kaufen, idealerweise eine, die es so lange gibt, dass sie in diesen mobilen Geräten noch bekannt ist.

    Um das festzustellen müsstest Du im ersten Schritt nur auf die Webseiten der CAs gehen, schauen, ob das Handy meckert und wenn nicht, hast Du einen Kandidaten gefunden. Dann schauen, wo ein entsprechendes Zert eingesetzt wird, das nicht gerade 500 EUR im Jahr kostet und et voilà...

    Ich würde mit denen anfangen: https://www.netcup.de/ssl-zertifikate/ ;)

    CU, Peter

    Hay,

    wenn das andere läuft, hervorragend. Reserveplan:

    nicht praktikabel VPN einzusetzen.

    ansonsten habe ich unter android https://play.google.com/store/apps/det…openvpn.openvpn auf einem Samsung Tablet laufen. Es spricht nichts dagagen, dass es auch auf Telefonen läuft. iphone nicht getestet, aber auch im App Store gefunden: https://itunes.apple.com/de/app/openvpn…d590379981?mt=8.

    Passende .ovpn-Datei schreiben (darauf achten, dass die config mit dem Server abgeglichen ist), importieren, Schlüssel hochladen und verbinden :)

    CU, Peter

    Hay,

    Was fehlt dir da?

    das Konzept. Ein (gutes) Buch hat immer ein übergreifendes Konzept und ist in sich abgeschlossen. Abgesehen vom didaktischen Ansatz. Ein gutes Buch hat so viel mehr als ein Blog mit hunderten von Quellenangaben. Ein Buch hat etwas meditatives, ein Blog fördert wildes rumgeklicke und das sich-verlieren in Referenzen, weil ein Thema nicht besprochen wird, sondern woanders hin verwiesen wird und man wird im Verweis mit einem komplett anderen Schreibstil, Ansatz oder anderer Qualität konfrontiert. Ein anderer Aspekt ist, dass man beim Online-Lesen von Quellenmaterial auch immer (mindestens in den Kommentaren) mit hating und trolling bezüglich systemd konfrontiert wird, was äußerst störend und ablenkend wirkt, weil es nicht zielführend ist. Das kann man nicht einfach so ausblenden.

    Hier aber einen Aufsatz "über den Vorteil eines Buches" zu schreiben wäre der falscher Ort :) Ich will halt eins und das hat seinen Grund.

    CU, Peter

    Hay,

    unter systemd

    klingt rückständig, aber ich suche nach einem guten Buch zu systemd. Die online-Dokus mag ich nicht, die sind in meinem Augen nicht zum Lernen geschrieben, damit löse ich nur anlaßbezogen Unannehmlichkeiten, auf die ich gerade stoße. Oder einen echten Online-Kurs, das wäre noch eine Alternative.

    CU, Peter

    Hay,

    will das Zertifikat nur ungerne raus nehmen...

    würde ich auch nicht. Du bist in dem Fall nicht für die Probleme anderer Leute zuständig. Ich habe Kunden, die mit ihrem "T-Online"-Starterkit noch einen Netscape (glaube 42.x) installiert haben, der sich bis heute nicht geupdatet hat. Alternativ können diese einen ssl-Proxy nutzen, der noch die alten Verschlüsselungen akzeptiert. Aber auch das ist nicht die Lösung für alte angreifbare Technik.

    Nachtrag: Wenn Du Webseiten ohne Verschlüsselung anbietest und nicht zu 100% privat damit bist, kannst Du sogar abgemahnt werden, wenn z.B. irgendwo ein Online-Formular darauf läuft.

    CU, Peter

    Hay,

    es soll ein Port des Windows Servers ins Internet exposed werden. Die entsprechenden Clients befinden sich nicht im VPN.

    Habe ich vor 7 Stunden schon verstanden, weil ihr eine solche Lösung verfolgt habt 8o

    Er hat nicht geschrieben, dass die Clients nicht im VPN sein sollen / dürfen. Er hat nicht geschrieben, dass dies seine Lösung sein muss, sondern nur, welchen Ansatz er anscheinend gewählt hat. Für mich auch nicht so eindeutig, da es auch nur ein Mißverständnis bezüglich Konfiguration eines VPN sein kann und seine Formulierungen scheinen bei dem Thema auch nicht so "firm" zu sein.

    Er hat ein Problem geschildert, seinen Lösungsversuch und dass er es so nicht hinbekommen hat. Ich habe nicht seine Frage beantwortet, sondern, eine einfachere Alternative angeboten ;)weils mir persönlich SO viel zu kompliziert ist. Abgesehen davon, dass man mit VPN-Clients noch ein paar nützliche Sachen mehr gewinnt: Schlüssel zurückziehen (liefert einen zusätzlichen Sicherheitslayer für den dahinter stehen Server), gesteuerten Zugriff auf ggf. mehrere andere interne Server UND die geschlossene Verschlüsselung vom Client zum internen Server und nicht erst ab dem OpenVPN-Server ...

    Kann man nutzen, muss man aber nicht, muss der Thread-Ersteller entscheiden.

    CU, Peter

    Hay,

    Die Route die der VPN-Client am Windows-Server automatisch konfiguriert ist lediglich eine für das 10.8.0.0/24 Netz.

    mehr braucht es doch nicht.

    Wenn auf der externen Arbeitsstation ein VPN-Client läuft und sich mit dem Server verbindet, bekommt er eine IP aus demselben Netz.

    Jetzt nur noch die passenden Ports (nehmen wir mal an, Port 80) auf dem Windows-Server (nehmen wir mal an 10.8.0.8) für den Zugriff aus diesem Netz freischalten und man kann voll transparent von der Arbeitsstation aus direkt auf 10.8.0.8:80 zugreifen.

    In die server.conf für openvpn muss natürlich die option "client-to-client" rein, wenn man keine Netz zu Netz-Verbindung realisiert (*) und sowohl Windows-Server wie auch der externe Desktop nur einfache clients sind.

    (*) Die meisten meiner Configs verbinden transparent zwei lokale Netze. Für einen externen Arbeitsplatz und mein Tablet habe ich ausnahmsweise auch mal echte Clients konfiguriert, die hängen sich dann als interne Stationen rein und ich habe an diesen Geräten Zugriff auf das gesamte Netz.

    CU, Peter

    Hay,

    sorry, dass ich da reinquatsche - aber ich sehe die Komplexität nicht?

    (Station im Netz: VPN-Client) -> (VPN Server) <- (Server im lokalen Netz: VPN-Client) ist doch ein Netz, zB 10.8.0.1/24... fertig.

    ifpush, ifroute richtig, bissl Routing, bissl Firewall... warum braucht man da NAT? Ich brauche jedenfalls keines, ich habe IP-Forward aktiviert, erlaube iptables zwischen den Netzen zu routen und setze einfache statische Routen und kann von meinen Tablet aus z.B. via RDP in mein internes Netz auf eine VM zugreifen oder auch vom NAS ein Video abspielen. Was ist da anders? Ich lerne gerne dazu :)

    Ich brauche noch nicht mal ein Portforward, wenn ich auf meinem VPN-Server eingeloggt bin.

    CU, Peter

    Hay,

    Denn Du müsstest auch auf dem Windows-Server dafür sorgen, dass IP-Pakete diese Verbindungen betreffend über das VPN zurück geroutet werden. Ich weiß jetzt ad-hoc nicht, wie ich das unter Windows geschickt realisieren würde.

    vielleicht denke ich zu einfach... sobald der Windows-Rechner sich mit dem Access-Server verbunden hat, hat der Windows-Rechner doch das passende Netz und routing, sofern der Access-Server das passende ifroute schickt?

    Im anderen Fall gab es bislang nichts, was ich nicht mit einer statischen Route auf dem Windows-Rechner gelöst hätte ... freilich muss man auch noch daran denken, in der Windows-Firewall die passenden Ports zum VPN-Server zu öffnen.

    CU, Peter

    Hay,

    Korrigiere mich gerne, wenn es vernünftige Gründe gibt, das nicht mehr zu nutzen

    ich bleibe doch mal kurz off-topic, einen der Gründe habe ich vor einer Woche life erlebt.

    "Früher" hatte man openvpn mit /etc/init.d/openvpn start gestartet. Dieses Script (also "damals" (tm)) hat alle .config-Dateien im /etc/openvpn automatisch geladen, dadurch waren sofort alle configs aktiv. Das openvpn, was in meiner Distribution auf dem Server zuhause verwendet wird (opensuse), läuft natürlich über systemd und einem wrapper-Script in /etc/init.d/. Openvpn läuft auf meinem Heimserver seit Jahren wunderbar als client (also mit einer klassischen /etc/openvpn/client.conf). Letzte Woche hatte ich außer Haus zu tun und brauchte Zugriff auf eine VM zuhause.

    Also "schnell" mal eine server.conf erstellt und wie seit Ewigkeiten /etc/init.d/openvpn restart getippt.

    Client war da, Openvpn Server nicht. Noch nichtmal Logeinträge. Hä?

    Ich war zuerst nicht darauf gekommen und habe alles andere überprüft - Keys (da erstelle ich aus Versehen gerne mal Server-Keys für clients...), Port, MTU, ciphers und der ganze Quatsch. Aber dann müsste es doch Logeinträge geben!

    Schließlich habe ich nach 10 wütenden Minuten entdeckt, dass der systemd mit dem init.d-Script einfach nur die client.conf startet (und zwar explizit nur genau diese config). Schnelle Lösung hier war, einfach das systemd-Objekt mit der client.config zu kopieren, das File zu editieren, dass es die server.config geladen wird und dann mit einem eigenen Namen zu aktivieren und zu starten. Et voila: ging dann sofort und ich hatte meine Logfile-Einträge.

    Und das ist extrem unerwartetes Verhalten, wenn man sich noch nicht an das Handling von systemd gewöhnt hat und mir persönlich war es eine Lehre.

    CU, Peter

    Hay,

    ist ein guter Anfang.

    Hier die Fragen, die Du als nächstes für Dich lösen solltest - und übers Lösen lernt man ganz gut:

    1) ssh schon auf public key authentification umgestellt?

    2) root-Access für ssh verweigert?

    -> damit ist Dein ssh schon ganz schön abgesichert

    3) mit fail2ban beschäftigt?

    -> sperrt lästige Hackversuche nach einer (von Dir einstellbaren) Anzahl von Versuchen aus

    4) Port 443 geöffnet?

    -> Könnte in WWW Full drin sein (netstat -tulpen gibt Dir eine Übersicht, was wirkich alles offen ist ("LISTEN")),z.B.

    Code
    tcp   0   0   123.456.789.010:443   0.0.0.0:*    LISTEN   0     16620    2432/nginx
    tcp6  0   0   :::443                :::*         LISTEN   0  26584956    24190/dovecot

    5) Lets Encrypt auf der Webseite installiert?

    -> damit der Webseiten-Verkehr verschlüsselt erfolgt

    6) Permanente Weiterleitung "301" von Port 80 auf Port 443?

    -> (idR per .htaccess-Datei) sorgt dafür, dass man auch immer die verschlüsselte Seite bekommt, auch wenn man nur per http: die URL eingibt.

    Eher dann erst den Rest angehen. Sicherheit geht vor :)

    CU, Peter

    Hay,

    erneuten Aufruf der Seite ist plötzlich der Serverinhalt wieder da

    Werde ich jetzt jeden Morgen erneut auf "DNS records übernehmen" klicken müssen, bevor die Seite erreichbar ist?

    das ist manchmal auch ein besonderes Problem zusammen mit a) Telekom oder b) Fritzbox.

    a) wenn die Verbindung ab- und wieder aufgebaut wird, wird häufig der DNS-Server, den Dein Heimnetzwerk z.B. von der Telekom bezieht, ausgetauscht. Ich habe es öfters erlebt, dass die die neue IP noch nicht hatten, obwohl der vorher sie schon kannte. Aus- / Einschalten und der nächste konnte es wieder nicht. Aus-/Einschalten und plötzlich hatte ich wieder einen DNS, der die korrekte Adresse lieferte. 48h Stunden stehen als Wartezeit nicht ohne Hintergedanken, auch wenn es manchmal in 5 Minuten so aussieht, als ob es gelaufen ist.

    b) die Fritzbox cached DNS-Anfragen teilweise SEHR lange. Aus-/Einschalten sollte reichen. Für ganz hartnäckiges Caching, kurz in die Netzwerkeinstellen, etwas verändern (z.B. DHCP an- und wieder abschalten) und dann werden die kompletten Netzwerkcaches gelöscht.

    CU, Peter