Hay,
nativ sprich rein http://hostingNNNNN.aHHHH.netcup.net bzw.
mailNNNNN.mxHHHH.netcup.net als Maildomain hätte auch funktioniert?
http geht (habe ich probiert), mail geht (jetzt probiert). Hin und zurück.
[...]
Received: from xxxxx.netcup.net (xxxxx.netcup.net [188.68.xx.xx])
by pkleemann.de (Postfix) with ESMTPS id 586C33F9D4
for <peter.kleemann@pkleemann.de>; Sun, 25 Nov 2018 20:53:03 +0100 (CET)
[...]CU, Peter
Hat jemand ein Webhosting ohne einer expliziten Domain in Verwendung?
(sprich auch bei der Bestellung obwohl eine dabei wäre auch keine angegeben)
Jop, hab das Webhosting Mini BF ohne Domain bestellt und ohne Domain in Nutzung. Hab eine meiner Domains dann einfach mit dem Paket verbunden, DNS Records setzt der automatisch, wenn du den entsprechenden Haken setzt. Interessanterweise wurde der Netcup MX Record als Prio 50 angeführt und mein eigener MX record auf 10 belassen. Sehr löblich!
Du kannst das Webhosting aber natürlich auch mit der netcup subdomain nutzen 
Ja genau das war mein Fehler, daß ich eine Domain angegeben habe die es nicht gebraucht hat 
Ich sagte die Erstbeste nicht die Nullstbeste
Hay,
Real Programmers Count From Zero
CU, Peter
Ich will das Thema nebenan nicht zweckentfremden, darum lieber hier, bevor es ausartet: Ich persönlich hätte trotzdem keine Freude daran, wenn die MySQL-Verbindung unverschlüsselt quer durch das ganze Internet läuft. Was bringt die ganze HTTPS-Absicherung, wenn der Admin über eine ungesicherte Verbindung auf die DB zugreift? Ich sehe dieses Beispiel nämlich so oft bei geschäftlich genutzten DBs mit schützenswerten personenbezogenen Daten und fast nie bemängelt daran jemand, dass der Zugriff nicht verschlüsselt ist.
KB19 : Der netcup-Support schlägt das aber genau so selbst vor, wenn man einen mananged private Server hat. Die bitte nach einem MySQL-Zugriff über einen SSH-Tunnel wird abgewiesen. Es wird stattdessen vorgeschlagen, man könne den MySQL-Port in der Firewall freischalten und dann ist der Kunde für alles verantwortlich. Anders sei ein externe Zugriff mit anderer Software auf die Datenbank hier halt nicht vorgesehen.
Hay,
Es wird stattdessen vorgeschlagen, man könne den MySQL-Port in der Firewall freischalten und dann ist der Kunde für alles verantwortlich. Anders sei ein externe Zugriff mit anderer Software auf die Datenbank hier halt nicht vorgesehen
Wow. Lässt er wenigstens VPN zu? Dann wäre es ja kein wirkliches Problem, dann braucht man nicht zu tunneln.
Und meine Lösung wie im thread mit dem Hackscript erscheint immerhin über https plötzlich sogar Mittel der Wahl 
CU, Peter
Ich wußte nur, welche Zugangsdaten er intern benutze und dass PHP lief. Also habe ich ihm ein PHP-Script geschrieben, mit dem ich von außen beliebige SQL-Kommandos reinschießen konnte und das Ergebnis zurückbekam. War ein häßlicher Hack, aber nur so konnte ich seine Telefonnummern aus seinem gehosteten CRM mit dem Telefonbuch meiner Telefonanlage synchronisieren...
Dunkle Erinnerungen werden wach Sowas hab ich auch schonmal gebaut. War am Ende des Tages einfacher / unkomplizierter als die anderen Möglichkeiten
Der netcup-Support schlägt das aber genau so selbst vor, wenn man einen mananged private Server hat. Die bitte nach einem MySQL-Zugriff über einen SSH-Tunnel wird abgewiesen.
Das wundert mich aber doch sehr... Ich dachte bei einem managed (v)Server hätte man einen (eingeschränkten) Shell-Zugriff? Und MySQL läuft doch lokal auf der selben Maschine, dann sollte das doch eigentlich kein großes Problem sein über SSH einen Tunnel auf localhost herzustellen, ein SSH-Tunnel mit Ziel auf localhost und Port 3306 sollte doch nie ein Problem sein... 
Das es einen SSH-Zugang (standardmäßig?) gibt wurde hier bereits erwähnt und ist auf jeden Fall wohl im Preis inkludiert:
Dienste die nur einen normalen SSH Zugriff benötigen kann der Kunde auch selber starten (liegt dann aber außerhalb unseres Managements und muss vom Kunden eigenständig gepflegt werden)
Weil wir gerade bei Verschlüsselung, VPN und Privacy angekommen sind - darf ich einmal bitte das Thema eben einmal kurz hijacken und die Frage in den Raum stellen, wie Ihr das so mit etwaigen IP-Cams handhaben würdet? Gefühlte 7/8 der Kameras auf Amazon haben irgendeine China-Cloud, -freilich möchte ich keiner davon unterstellen DSGVO-inkompatibel zu sein, wo ja schon die VÜ selbst zu Lasten derer, die sie zu ihrem Schutz verwenden wollten, streng reguliert ist. Wenn man ein Audit selbst der Nicht-Cloud-Kameras macht, wird einem teilweise übel - hier ein oberflächliches Audit in englischer Sprache für eine WLAN-Türklingel, die ich mir kürzlich angeschaut habe - https://technicalexperiments.w…-video-doorbell-analysis/
Das reiht sich gleich einmal in frühere Berichte ein, etwa: https://www.heise.de/security/…heitsrisiken-3739735.html
Ich suche eigentlich nur möglichst billige, „dämliche“ WLAN-IP-Cams, mit SOAP-Alarmfunktion, die ich selber einstellen kann. Der Plan ist der, sie mittels Firewall abzuschotten, die MJPEG-Streams und snapshots über einen mittels HTTPS gesicherten Proxy zu jagen und allenfalls per SMS einen Alarm an ein Mobile abzugeben, wenn die Bewegungserkennung losgeht.
Auch liebäugle ich mit einer OpenSource Firmware wie Openipcam, könnte aber da etwas Starthilfe brauchen. Mit ein Eingeweiden von OpenWRT kenne ich mich ja soweit mittlerweile aus, dass ich Custom Firmwares bauen kann.
Gerade in Zeiten von Mirai und Co möchte ich eigentlich kein Gerät ungefiltert ins Netz lassen...
Und was die diversen Onvif-Kameras angeht, die als solche beworben werden, ohne Onvif Core zu beherrschen, das steht auf einem anderen Blatt.
Ist DSGVO-konforme und sicherheitsaffine VÜ mit den Geräten, die heute auf dem Markt sind überhaupt noch möglich?
Alles anzeigenWeil wir gerade bei Verschlüsselung, VPN und Privacy angekommen sind - darf ich einmal bitte das Thema eben einmal kurz hijacken und die Frage in den Raum stellen, wie Ihr das so mit etwaigen IP-Cams handhaben würdet? Gefühlte 7/8 der Kameras auf Amazon haben irgendeine China-Cloud, -freilich möchte ich keiner davon unterstellen DSGVO-inkompatibel zu sein, wo ja schon die VÜ selbst zu Lasten derer, die sie zu ihrem Schutz verwenden wollten, streng reguliert ist. Wenn man ein Audit selbst der Nicht-Cloud-Kameras macht, wird einem teilweise übel - hier ein oberflächliches Audit in englischer Sprache für eine WLAN-Türklingel, die ich mir kürzlich angeschaut habe - https://technicalexperiments.w…-video-doorbell-analysis/
Das reiht sich gleich einmal in frühere Berichte ein, etwa: https://www.heise.de/security/…heitsrisiken-3739735.html
Ich suche eigentlich nur möglichst billige, „dämliche“ WLAN-IP-Cams, mit SOAP-Alarmfunktion, die ich selber einstellen kann. Der Plan ist der, sie mittels Firewall abzuschotten, die MJPEG-Streams und snapshots über einen mittels HTTPS gesicherten Proxy zu jagen und allenfalls per SMS einen Alarm an ein Mobile abzugeben, wenn die Bewegungserkennung losgeht.
Auch liebäugle ich mit einer OpenSource Firmware wie Openipcam, könnte aber da etwas Starthilfe brauchen. Mit ein Eingeweiden von OpenWRT kenne ich mich ja soweit mittlerweile aus, dass ich Custom Firmwares bauen kann.
Gerade in Zeiten von Mirai und Co möchte ich eigentlich kein Gerät ungefiltert ins Netz lassen...
Und was die diversen Onvif-Kameras angeht, die als solche beworben werden, ohne Onvif Core zu beherrschen, das steht auf einem anderen Blatt.
Ist DSGVO-konforme und sicherheitsaffine VÜ mit den Geräten, die heute auf dem Markt sind überhaupt noch möglich?
Hab aktuell IPCams von TP-Link daheim.. Die sind zwar nicht unbedingt billig aber ich traue dem Unternehmen mehr, als den ganzen Billiganbietern. Hab an einer im Innenraum auch ne WLAN Steckdose dran, schalte die quasi nur bei Bedarf an um zu gucken was der Hund treibt. 24/7 Kameraüberwachung in den Wohnräumen halte ich für übertrieben.
Das wundert mich aber doch sehr... Ich dachte bei einem managed (v)Server hätte man einen (eingeschränkten) Shell-Zugriff? Und MySQL läuft doch lokal auf der selben Maschine, dann sollte das doch eigentlich kein großes Problem sein über SSH einen Tunnel auf localhost herzustellen, ein SSH-Tunnel mit Ziel auf localhost und Port 3306 sollte doch nie ein Problem sein...
[...]
Frage: Auf welcher Seite soll der MySQL-Server laufen - auf dem managed (v) Server oder auf dem Remotehost.
Ich kann zu dem Thema nur drei Hinweise geben: 1. mysqlproxy verwenden, um den Zugriff zu beschränken. 2. ssh (reverse) Port Forwarding - was ja ohnehin schon erwähnt wurde. 3. SSL-Wrapper verwenden.
ad 2.) https://blog.devolutions.net/2…verse-ssh-port-forwarding
Wenn ich das Problem nicht verstanden haben sollte, mich bitte an der Hand nehmen und es ganz langsam nocheinmal erklären.
Hab aktuell IPCams von TP-Link daheim.. Die sind zwar nicht unbedingt billig aber ich traue dem Unternehmen mehr, als den ganzen Billiganbietern. Hab an einer im Innenraum auch ne WLAN Steckdose dran, schalte die quasi nur bei Bedarf an um zu gucken was der Hund treibt. 24/7 Kameraüberwachung in den Wohnräumen halte ich für übertrieben.
Danke geekmonkey, aber: Autsch... Soweit ich weiss - und ich bin schon ein TP-Link Fanboy der ersten Stunde - nehmen die das jeweilige SDK und tauschen eigentlich nur den Bootloader und das Webinterface. Für meine fernschaltbare Steckdose gab es zwar mit Verzögerung nach der KRACK-Attacke ein Firmware-Update. für den TL-WA850RE warte ich bis heute darauf... Bei meinem WLAN-AC-fähigen VDSL-Modem konnte man einen Root Shell-Exploit ausführen, indem man eine der beiden ESSIDs in $(befehl) Notation eingab und darüber telnetd startete. Bugfix steht bis heute aus... Meine Meinung: Nur ein TP-Link mit OpenWRT ist ein braver und guter TP-Link. Und ja, bei TP-Link gibt es im Gegensatz zu anderen Marken sowas wie guten Support.
WLAN-Steckdosen sind auch so ein Thema für sich: Für die Einrichtung brauchen sie auch eine App, die Smartlink oder ähnliches spricht und z.T. UPNP für den Tunnel zum Cloudserver. Dafür bin ich teils auch zu paranoid - aber das Pairing mit der App geht erst einmal gar nicht ohne Uplink. Und wohin speichert die App dann meine WLAN-Passphrase? Ich würde ja Enterprise-Radius-Auth für jedes Gerät machen, aber das können die vorsorglich erst gar nicht. Dann lieber FHEM oder eigene Skripte, die Kommandos über ein Gateway ins lokale Netz broadcasten. Die Steuerungscodes sowohl der TP-Link Steckdosen als auch der billigen sind im Grunde ident. Eine HEX-codierte Nachricht aus Header mit Herstellercode, Ziel-MAC-Adresse, Suffix, mit AES gegen die Passphrase 0123456789 codierter Steuerbefehl, Prüfsumme.
Schaut Euch dazu die Posts von SebiM im FHEM-Forum an, wenn Ihr mehr wissen wollt - wenn man das weiss, wird einem schlecht.
Das Produkt Cloud vLAN Medium BF ist aktuell ausverkauft(Edit: Um Punkt 13 Uhr hat es dann geklappt.
Dafür gab es vor 10 Minuten noch einen RS500. Und ich konnte mich doch nicht zurückhalten. Ich brauche einen ordentlichen Jumphost fürs VLAN. Ein ungenutzter VPS 20 taugt da eher nicht dazu...
So Kunden wie Dich wünscht man sich als Hoster 
BTW@all: Wenn nach dem freitäglichen Kaufrausch die man bis auf den schwarzen Grund der Geldbörse sehen kann, und jetzt die Ernüchterung ihren Tribut fordert, dann wäre es Zeit für's voradventliche Hosting-Fasten. Spätestens beim Öffnen der Adventkalender-Türchen sind die Vorsätze eh wieder dahin und dann kommt auch schon der Neujahrskracher.
Zeit für einen Tauschkreis...
Apropos Cloud VLAN... hat netcup eigentlich auch einen Usecase, wo Kunden, die miteinander kooperieren, ein gemeinsames VLAN buchen können?
Apropos Cloud VLAN... hat netcup eigentlich auch einen Usecase, wo Kunden, die miteinander kooperieren, ein gemeinsames VLAN buchen können?
Wäre in der Tat genial. (Persönlich habe ich derzeit allerdings keinen Bedarf daran.)
So Kunden wie Dich wünscht man sich als Hoster
Man gönnt sich ja sonst nichts
Kein Tschick, kein Alkohol, kein supermodernes und teures Smartphone, ...
(Und ein paar Euro vom Partnerprogramm standen auch noch auf der Auszahlungsliste.)
voradventliche Hosting-Fasten
Begriff des Jahres 2018
Und MySQL läuft doch lokal auf der selben Maschine, dann sollte das doch eigentlich kein großes Problem sein über SSH einen Tunnel auf localhost herzustellen, ein SSH-Tunnel mit Ziel auf localhost und Port 3306 sollte doch nie ein Problem sein...
welchen Sinn hat derartiges?
sollen damit Pakete auf der lokalen Maschine im Kreis geschickt werden?
wie Ihr das so mit etwaigen IP-Cams handhaben würdet?
Man kann den Dingern nicht vertrauen. Wenn man also sowas einsetzen will/muss, sollte man zumindest die Umgebung entsprechend absichern.
Einzige wirklich praktikable Lösung ist IMHO, die Kameras in ein eigenes VLAN stecken, das VLAN komplett abzuschirmen (inkl Internetzugriff sperren), vor das VLAN einen Reverse Proxy schalten welcher für den Zugriff eine Authentifizierung via Client Zertifikat anfordert und natürlich auch HTTPS macht.
UPnP im Router deaktivieren sollte ja Standard sein.
Geräte mit Cloud Feature würde ich erst gar nicht kaufen.
[..} Wir bieten standardmäßig Backup Lösungen auf Basis von BackupPC an: https://www.netcup.de/professi…iterungen.php#backupspace [..]
Da ich das ursprüngliche Thema nicht zumüllen möchte und Kai ja hoffentlich für dieses Zitat auch eine Notification bekommt, schreibe ich es mal in diesem Thread. Der Deeplink (Anker auf "backupspace") funktioniert bei mir nicht. Generell funktioniert das Verlinken auf spezifische Tabs der netcup Website nicht, auch bei den vServern o.Ä. Ist meiner Erinnerung nach schon immer kaputt gewesen.
Alles anzeigenMan kann den Dingern nicht vertrauen. Wenn man also sowas einsetzen will/muss, sollte man zumindest die Umgebung entsprechend absichern.
Einzige wirklich praktikable Lösung ist IMHO, die Kameras in ein eigenes VLAN stecken, das VLAN komplett abzuschirmen (inkl Internetzugriff sperren), vor das VLAN einen Reverse Proxy schalten welcher für den Zugriff eine Authentifizierung via Client Zertifikat anfordert und natürlich auch HTTPS macht.
UPnP im Router deaktivieren sollte ja Standard sein.
Geräte mit Cloud Feature würde ich erst gar nicht kaufen.
Genau deswegen habe ich etwas tiefer in die Tasche gegriffen und eine Kamera gekauft, die die Daten zwar in die Cloud schieben kann (deutscher Anbieter, Server in DE), die es aber wahlweise auch via FTP auf einen beliebigen FTP-Server hochladen kann.
Desweiteren hat das Ding eine App, welche nur direkt auf diese Cam zugreift, dazu brauchts dann auch keine Port-Freigabe im Router. Zugang über User/Kennwort ist natürlich selbstverständlich.
Einziges Manko: SFTP geht nicht, sondern nur normales FTP oder FTP-S
