Beiträge von m_ueberall

Hallo Herr Preuß,

Bereits bei der letzten VPS-Generation ist mir aufgefallen, daß sich die Angebote je nach Sprache von der Leistungsbeschreibung her bisweilen unterscheiden (wer das Produkt über https://www.netcup.de/vserver/vps.php auswählt, kommt i.d.R. auch günstiger weg als über https://www.netcup.eu/vserver/vps.php -- wobei mir natürlich ein paar naheliegende Gründe einfallen, warum dem so sein könnte (Stichwort "Kunden aus dem Ausland", ...)).

Aktuell ist es jedoch so, daß die englischsprachige Seite für "VPS 4000 G7" (und auch "VPS 6000 G7") den Einsatz von DDR4-RAM ausweist, während die deutschsprachige Seite DDR3-RAM auflistet; klickt man auf den jeweiligen Bestell-Link, landet man bei unterschiedlichen Produktnummern (getestet beim VPS 4000 G7 (dt. -> #1414, engl. -> #1430 ("VPS 4000 G7 iv", hier jetzt auch mit DDR3-RAM!)).
Ist die Nennung von DDR4 in der Übersicht ein Tippfehler oder sind das unterschiedliche Rechner-Kontingente (und der Tippfehler steckt auf der Bestellungsseite)?

IMHO wäre es auch besser, bei abweichenden Produktnummern auch abweichende Produktbezeichnungen bereits auf der (engl.) VPS-Übersichtsseite zu verwenden.

Zitat von [netcup] Felix

Zitat
Uns liegt sehr viel daran verständliche Produkte zu haben.

Mit freundlichen Grüßen
Markus Ueberall

Hallo margau,

Ist die im Heise-Artikel zitierte Beschränkung "Angenommen werden nur noch Mails, bei denen Absenderadresse und tatsächliche Versand-Domain übereinstimmen." tatsächlich so zu lesen, daß es nicht ausreicht, den SPF-Eintrag der Domäne "example.org" um die IPv4/IPv6-Adressen Deines VHosts zu ergänzen? Das hast Du schon (erfolglos) ausprobiert?

Zitat von .A.

Es gibt [...] einen Webservice mit allen Produkten, ein Web-Scraper ist somit überflüssig. Als kleine Fingerübung kannst Du ja mal ein Script schreiben, dass daraus eine PDF generiert.

Vielen Dank für den Hinweis auf den o.g. Webservice, den ich noch nicht kannte. Dieser würde zumindest schon einmal die "Nachverfolgung" von Produkten und ihren Preisen anhand ihrer ID und/oder ihres Namens erlauben (Wandlung von XML in gewünschtes Ausgabeformat ist in der Tat eine Fingerübung), ist aber wohl eher nicht für den "typischen" Kunden gedacht, welcher eine tabellarische Übersicht sucht.
Zur Info: Die XML-Datei enthält keine vollständigen Beschreibungen (bei (v)Servern möchte ich gerne die Eckdaten auf einen Blick vergleichen) und listet auch einige nicht mehr verfügbare Aktionsprodukte auf (die automatisierte Überprüfung, ob der Link zum Produkt auf eine Fehlermeldung führt und dieses ggf. markiert/maskiert werden soll, ist definitiv keine praktikable Option; Netcup würde sich wohl zurecht "bedanken", wenn jetzt mehrere Kunden damit anfangen).

mfg Markus

Hallo,

Auf Nachfrage konnte man mir heute telefonisch leider nicht direkt Auskunft darüber geben, wie hoch die in der Produktbeschreibung erwähnte "einmalige Bearbeitungsgebühr" für den Umzug von gerouteten, "Nicht-FailOver"-IPv4-Adressen ausfällt (und ob diese pro IPv4 oder pro Auftrag/Ticket fällig wird, sofern man bereits einen oder mehrere vServer mit mehreren zusätzlichen IPv4s betreibt und letztere "en bloc" auf neue vServer umziehen möchte). Da dies unter Umständen von allgemeinem Interesse ist, wollte ich auf diesem Wege einmal nachfragen.

In diesem Zusammenhang: So ansprechend das netcup-Webdesign auch ist -- wäre es mittelfristig möglich, wenn auch nicht für Jedermann, dann zumindest als Kunde (ggf. via tabellarischer Produktübersicht im ccp?) an ein PDF mit aktuellen Preisen aller regulärer Produkte inkl. Vertragslaufzeiten, Einrichtungs- und Bearbeitungsgebühren zu kommen? (Ich gehe einmal davon aus, daß bösartige Mitbewerber, welche es nötig haben, diese Informationen heutzutage sowieso mittels Web Scraper im Auge behalten.)

mfg Markus

Hallo,

Wird es kurz- bis mittelfristig auch möglich sein, TLSA RRs zu editieren (Stichwort DANE), ohne auf eigene Nameserver zurückgreifen zu müssen?
Dies bräuchte -- zumindest für erste "Gehversuche" -- ja nicht zwangsläufig zusammen mit DNSSEC eingeführt zu werden (Nicht, daß ich etwas gegen die Kombination hätte, aber ggf. ist zunächst die isolierte Unterstützung dieses resource records schneller/einfacher machbar... :D).

mfg Markus

Zitat von [netcup] Felix

Liebe Kundinnen und Kunden,
[...]
Dieser Beitrag dient dazu ggf. vorhandene Bugs zu melden und um uns weitere Anregungen und Wünsche zukommen zu lassen.

Hallo,

Zitat von nem3sis;16535

[...]kann man das nicht irgendwie ändern da[ß] da anstatt static.IP.clients.your-server.de meine Domain steht?

Man kann -- was Du hierzu benötigst ist ein sogenannter PTR-Eintrag für RDNS (Reverse DNS); eine englische Beschreibung findet sich beispielsweise hier. Dieser Eintrag taucht bisher nicht im Netcup Customer Control Panel auf, aber der Support hat mir das seinerzeit auf Anfrage schnell eingestellt.

Allerdings ist es nicht immer sinnvoll, die eigene IP-Adresse überhaupt zu verraten; ich würde vorschlagen, daß Du unabhängig von der obigen Einstellung auch über die Beantragung einer IRC-"Tarnkappe" (cloak) nachdenkst, sofern das unterstützt wird...

Ad astra, Markus

Zitat von Mo3;14130

• SSH Port ist verlegt auf einen fünfstelligen Port
• Root-Login ist verboten, Einloggen nur mittels normalem User
• Dieser normale User hat ein Passwort mit 18 Zeichen, bestehend aus Zahlen, Ziffern und Sonderzeichen

Zitat von Artimis;14192

Apropos: phpmyadmin und solcher Kram gehört zum einen auf ein anderes Alias (wegen Brute-Scripts), auf jeden Fall nur per https erreichbar und am besten auch .htaccess-geschützt.

Hallo,

Ich würde empfehlen, in beiden Fällen noch einen Schritt weiterzugehen: Grundsätzlich keinen SSH-Zugang ohne die Verwendung von Schlüsseldateien erlauben (die Verlegung des Ports reduziert die Größe der Logdateien und schadet natürlich nicht, bietet aber keinen Schutz gegen Portscans). Dasselbe gilt für alle Dienste, welche nicht direkt öffentlich verfügbar sein müssen (phpMyAdmin, IRC-Bouncer, Datenbanken für Wordpress o.ä.): Bindet diese an ein privates Loopback-Interface (eine 192.168.x.y-Adresse o.ä. ist über den Support erhältlich, wenn sie nicht bereits vorkonfiguriert war) und tunnelt diese über eine SSL-Verbindung nach außen (entweder temporär mittels OpenSSH oder dauerhaft mittels Stunnel).

Ad astra, Markus

Wie diese Einstellung menügeführt einzugeben ist, habe ich nicht probiert, für die Konfigurationsdatei "httpd.conf" würde ich aber folgende Lösung empfehlen (diese verwende ich selbst): Jeweils eine "VirtualHost"-Definition pro (Sub-)Domain (Vorteil: "Sauberere" Kapselung, man erspart sich ein explizites Redirect, weitere Konfigurationen wie verschiedene SSL-Zertifikate lassen sich nur durch u.g. Formulierung (einfach) realisieren).
Unter dem Schlüsselwort "NameVirtualHost" sollten sich online einige Tutorials/Beispieldefinitionen finden...

Listen $IP1:80
#Listen $IP2:80 ... (ggf. auch für Port 443)




NameVirtualHost $IP1:80
#dito für weitere IPs, Ports




<VirtualHost $IP1:80>
  ServerName abc.de
  ServerAdmin webmaster@abc.de
  DocumentRoot /var/www/vhosts/abc/main/
  #eigene Namenskonvention .../vhosts/domain/subdomain/...




  #NB alles, was hier steht, gilt nur für diesen Container/Namensraum!
</VirtualHost>




#ggf. IP, Port anpassen, duplizieren:
<VirtualHost $IP1:80>
  ServerName xyz.de
  ServerAdmin webmaster@xyz.de
  DocumentRoot /var/www/vhosts/xyz/main/
</VirtualHost>

Hallo,

Nur der Vollständigkeit halber: Ich gehe davon aus, daß Du entsprechende "VirtualHost"-Definitionen angelegt hast, ja? Innerhalb dieser Blöcke läßt sich dann für jeden "ServerName" schonmal mit "DocumentRoot /var/www/..." das Hauptverzeichnis vorgeben.

Ein häufiger Fehler ist übrigens, daß man einfach vergißt, diese Regeln mittels einer vorangestellten Zeile "RewriteEngine on" zu aktivieren

Ad astra, Markus

Hallo,

Zitat von SiGa;11264

Stell dir mal vor, ein Scriptkiddie macht es mit seinem Webhosting Account, und ein anderer Kunde, der auf dem selben Server ist, will dir z.B. eine E-Mail schicken. Seine IP Adresse wäre durch die Firewall geblockt, nur weil ein Scriptkiddie auf dem selben Server unfug treibt.

Gerade dadurch wird aber erreicht, daß man sich "vor Ort" um das Problem kümmert.

Zitat von SiGa;11264

Außerdem kann es auch sein, das der Server/die IP Adresse irgendwann von jemand anderem betrieben wird, der kein unfug treibt, sondern aus anderen gründen deinen server kontaktieren will.

denyhosts und andere Lösungen sehen durchaus vor, daß man IP-Adressen nach einer gewissen Zeit wieder freigibt (sofern sie nicht x-mal auffallen).

Zitat von SiGa;11264

Was ich dir aber empfehlen würde: phpMyAdmin mit htaccess schützen, weil diese software in vergangenheit oft sicherheitslücken hatte.

Entweder das, oder man bindet diese Administrationsdienste allesamt an eine interne Schnittstelle, über welche man selbst via SSH-Tunnel o.ä. zugreift (wie angemerkt, mittels Schlüssel und nicht durch Passworte geschützt) -- damit hat man dann auch die Anzahl der "Einfallstore" reduziert.

Zitat von SiGa;11264

Perfekt wäre es, wenn man iptables bei den vServern verwenden könnte, weil man dann anwendungen wie fail2ban laufen lassen könnte.

Im Forum wurde unlängst ein fail2ban-Lösungsansatz vorgestellt: vServer fail2ban Alternative fuer OpenVCP

Ad astra, Markus

Zitat von hannes.b;9948

Das erste Problem ist das ich die 2 wichtigsten Logs nicht öffnen kann (timeout beim download oder öffnen).
[...]
Bin im Moment eher unsicher was Lenny angeht, ich will der Sache auf den Grund gehen komme aber ohen die 2 Logs nicht weiter und bin wohl gewzungen einfahc alles zu überbügeln (am besten mit Etch oder einer guten Alternative) und dann gleich alles auf den neusten Stand zubringen inkl Script Firewall etc

Vier kurze Anmerkungen:
- Was hindert Dich daran, den Support mit Angabe des obigen Fehlers darum zu bitten, die Logdateien zu komprimieren und sie Dir anderweitig (via E-Mail an eine Ersatzadresse, ...) zukommen zu lassen?
- Du willst allen Ernstes anstelle der aktuellen "stable"-Version (Lenny -- in einigen Bereichen "alt genug") eine Vorgängerversion (Etch) einsetzen?
- Weil immer wieder der Tip gegeben wird, man solle doch die Standardports meiden: Im vorliegenden Fall wurde doch wohl ein Portscanner verwendet, also kann man das getrost vergessen (besser ggf. Dienste ganz oder zumindest zeitweise deaktivieren und nach Möglichkeit an ein "lo"-(Ersatz-)Interface binden, um sie nicht zu exponieren)
- Wenn ein externer Rechner zur Verfügung steht: Dort einen cronjob einrichten, welcher regelmäßig die Konfiguration des vServers in ihren Ausgangszustand zurücksetzt und alle unerwarteten Zugriffe protokolliert (ggf. läßt sich im Falle eines Falls sogar der vServer automatisch stoppen, vgl. Ansatz für fail2ban für die Webschnittstelle der Firewall)...

Ad astra, Markus

Zitat von koweto;8963

Hier gibt es für den Einstieg eine nett *zensiert*.

Schöner Vergleich, allerdings fehlt hier IMHO noch ein wichtiger Mitbewerber: *zensiert* (da habe ich mir vorgestern ein kostenloses einjähriges SSL-Zertifikat für eines der demnächst einzurichtenden Blogs geholt...)

Ad astra, Markus