Wie verwaltet Ihr mehrere Server parallel? Allmählich fängt es mich nämlich an zu Nerven jeden Server einzeln per Konsole updaten zu müssen oder Konfigurationen, die auf mehreren Servern identisch sind, anzupassen. […]
Am besten wäre so etwas wie sudo tool <servergruppe> <auszuführender Befehl> + Rückgabewerte der einzelnen Server.
Siehe dsh-Artikel und Debian-Paketbeschreibung.
ToolTip: Wer noch auf der Suche nach Aufgaben/Tests rund um die Filterung/Abweisung von E-Mails ist, wird unter Umständen hier fündig: emailspooftest.com
FYI: Bluetooth-Sicherheitslücke unter Linux (primär relevant für Desktop-Installationen, versteht sich)
"BleedingTooth" – zero-click RCE in Linux Bluetooth:
https://twitter.com/theflow0/status/1316071793707364353
https://www.intel.com/content/www/us…l-sa-00435.html
– According to Intel, all Linux kernels with BlueZ support prior to 5.9 are affected.
– Intel recommends updating the Linux kernel to version 5.9 or newer.
– BlueZ is the canonical implementation of the Bluetooth protocol stack.
– CVE-2020-12351, CVE-2020-12352, CVE-2020-24490.
#BlueZ #BleedingTooth #Bluetooth #Linux #Vulnerability #Security #InfoSec #CyberSecurity
Eine Unterdomäne lässt sich unter Verwendung von CNAME weiterleiten (vgl. diesen Diskussionsstrang), eine Domäne normalerweise nicht (siehe hier). Dazu bedarf es entsprechender Mechanismen seitens des Betreibers; Netcup unterstützt dies nicht, ergo bliebe nur ein Anbieterwechsel (Umzug der Domäne). Hierzu gab es vor wenigen Wochen einmal dieselbe Frage im Forum.
Sind hier eventuell Vodafone Kunden anwesend die mit extremen Paketverlust zu ihrem Server zu kämpfen haben ?
Leider habe ich diese nur behoben bekommen indem ich die Paketbeschleunigung der FritzBox deaktiviert habe, wodurch die Geschwindigkeit meiner Leitung von 1Gbit auf maximal 300Mbit gefallen ist.
Welches Fritz!Box-Modell (gekauft/gemietet)? (Wird die Paketbeschleunigung seitens VF für das genannte Profil defaultmäßig immer aktiviert?)
Liefert eine Gegenprobe mit Nicht-Netcup-betriebenen Hosts dasselbe Ergebnis?
Wie findet man bei netcup heraus ob ein CPU steal passiert? Ich denke ich werde die Statistiken vom SCP mal besser im Auge behalten.
Wie an anderer Stelle ausgeführt: Besser als die SCP-Statistiken im Auge zu behalten, ist es, mit eigenen Programmen direkt im VServer zu messen.
Das Dienstprogramm top zeigt das in der dritten Zeile (letzter Wert) live an:
top - 12:48:06 up 45 days, 4:25, 38 users, load average: 1,35, 1,60, 2,37
Tasks: 793 total, 2 running, 685 sleeping, 1 stopped, 1 zombie
%Cpu(s): 16,5 us, 6,5 sy, 0,0 ni, 75,8 id, 0,1 wa, 0,0 hi, 1,1 si, 0,0 stFür eine Überwachung empfiehlt sich natürlich die Installation von munin o. ä. – Beispielausgabe zur Prozessorauslastung findet sich hier.
FYI: Wer das APT-Repository ppa:ondrej/php verwendet, sollte vor dem/beim nächsten Update auf die Installation zusätzlicher Pakete verzichten und eine manuelle Ersetzung einiger zuvor unversionierter durch versionierte Pakete vornehmen (ansonsten kann es Probleme mit Nextcloud o. ä. geben), siehe Issue #1465: "Unversioned PECL (apcu, msgpack, memcached, ...) extension packages install all PHP versions".
Nachtrag: Nicht zu vergessen ist der Einwurf von mainziman, nach dem – sofern der Aufruf von preg_replace nicht aus dem Kontext gerissen ist – der Wert des URL-Parameters "var" überhaupt nicht verändert wird (siehe dieses Beispiel, bei dem man sich den Wert von $zeichenkette ausgeben lassen kann).
PHPpreg_replace('/[^a-zA-Z0-9\-]/', '', $_GET["var"]);Könnte ich jetzt noch auf irgendeine Weiße trotzdem Schadcode in ?var einschleusen oder ist dies nicht mehr möglich?
das da prüft aber nix
Codepreg_replace('/[^a-zA-Z0-9\-]/', '', $_GET["var"]);sondern vielmehr
Code$value = preg_replace('/[^a-zA-Z0-9\-]/', '', $_GET["var"]);
PHPpreg_replace('/[^a-zA-Z0-9\-]/', '', $_GET["var"]);Könnte ich jetzt noch auf irgendeine Weiße trotzdem Schadcode in ?var einschleusen oder ist dies nicht mehr möglich?
Ich habe kein Zugriff auf das Script. Ich weiß nur das die GET-Parameter auf diese Weise geprüft werden. Deshalb wäre es interessant zu wissen welche Möglichkeiten zum Umgehen der Eingaben zur Verfügung stehen.
Ähm, '^' ist das Metazeichen für "Anfang der Zeile" und nicht invertieren oder?
Nein, innerhalb einer Klasse ([]) ist es das, wenn es an erster Stelle steht.
Da sagt es Folgendes aus: Alles, außer die angegebenen Zeichen.
Linktip: Das kann man sich auch schnell online erklären lassen: https://regex101.com (das leere Eingabefeld "Substitution" entspricht genau dem zweiten Parameter in der Quellcodezeile; man beachte hier ggf. auch die fehlende "Escape-Sequenz" \- ? -) :
Optionaler Optimierungsvorschlag: Wer die vorgenannten Zertifikate nicht für den Mail- sondern auch für den Webserver einsetzt, kann mit Wildcards für Portangaben der Form "*._tcp[[.subsubdomain].subdomain]" arbeiten (das ist das Format, wie es in der ersten Spalte im CCP verwendet werden muss, da hier die ".domain." automatisch ergänzt wird – Angaben in eckigen Klammern sind wie üblich als optional zu lesen).
Sollen mehrere Unterdomänen und evtl. noch verschiedene Hashes (SHA-256 wie oben gezeigt oder etwa SHA-512) abgedeckt werden, empfiehlt sich ggf. zwecks Minimierung der DNS-Einträge, alle individuellen "3 1 n"-Zertifikatshashes (1≤n≤2) zusammen mit den teilweise bereits obengenannten "2 1 n"-CA-Hashes bspw. unter "_tcp"-Einträgen abzulegen, und betreffende Unterdomänen via "*._tcp[.subdomain] CNAME _tcp.domain.tld" (wiederum CCP-Notation) zu verknüpfen.
Die Meldung auf dane.sys4.de für die anderen Intermediates ist immer "certificate not trusted: (27) - certificate not trusted: (27)"
Es empfiehlt sich grundsätzlich, mehr als einen unabhängigen Test durchzuführen. Eine (ggf. im Fehlerfall aussagekräftigere) Alternative ist bspw. https://www.hardenize.com/
Sagt mal, werden ungelesene Beiträge und Benachrichtigungen im Forum nach ca. 2 Wochen plötzlich als gelesen markiert?
Hier tun sich ja Abgründe auf, was die Wertschätzung wertvoller Beiträge von Mitforennutzern anbelangt… könnte man sich als Nicht-Erleuchteter wohl kaum leisten! 
Über den RSS-Feed bekommt man zumindest eine Benachrichtigung über neue Themen (hier habe ich rss2email schätzen gelernt), allerdings nicht über Antworten hierzu – vielleicht gibt es hier alternative Feeds? (Gegebenenfalls wäre das eine Anregung für Netcup, (einen) solche(n) zusätzlich einzurichten?)
AMD Ryzen 5000er - die Katze ist aus dem Sack ...
https://www.pcgameshardware.de/AMD-Zen-Archit…hmarks-1359540/
sind hier der 16 Kerner eigtl. 2mal ein 8 Kerner on Die
und der 12 Kerner eigtl. 2mal ein 6 Kerner on Die?
[…] Ryzen 5 and Ryzen 7 will have one chiplet, while Ryzen 9 will have two chiplets – the easy way to identify this is through the amount of L3 cache each processor has. […]
Hat sich hier schon jemand mit URI-RRs (RFC 7553) zu diesem Zweck (https-Umleitung) gespielt? Respektieren Browser das überhaupt?
Oder verstehe ich den Zweck gänzlich falsch?
The purpose of RFC 7553
URIrecords is not to replace HTTP redirection, but to complement S-NAPTR (5.2), replace U-NAPTR (5.3) and replaceSRV(5.4) record types.[…] Web browsers aren't following URI records […] Nobody uses this record type […]
So einfach kommst du aus dieser Diskussion nicht raus, Don Quijote.
/me reicht noch einen Link nach für den letzten Satz im letzten Posting (https://github.com/Lochnair/xt_tls – "xt_tls is an extension for netfilter/IPtables that allows you to filter traffic based on TLS hostnames") und schließt panisch die Browser-Reiter mit https://forum.netcup.de auf allen Geräten…
Alles anzeigenm_ueberall Du hast was übersehen;
darum formulier ich meine Aussage etwas anders ...
alle im DNS existierenden Records, welche zu einer definierten IP(v6) Adresse führen müssen auf diesem Host bei entsprechenden
Abfragen des entsprechenden Protokolls zu einem definierten Verhalten führen;
[...]
aber auf jeden Fall alle welche im DNS auf die IP-Adresse des Hosts verweisen;
also hättest bei Deinem Zertifikat mit folgendem auf jedem Fall ein Problem
curl -4|-6 http[s]://0123456789.myfritz.net:port
Um diese Diskussion abzuschließen – Das ist überhaupt kein Problem. Um das Beispiel wieder aufzugreifen: entweder man entschließt sich dazu, ein passendes Zertifikat zu installieren oder eben nicht:
[…] Nur genau dann, wenn direkt auf http[s]://0123456789.myfritz.net[:port] zugegriffen werden soll, brauche ich entweder ein separates oder kombiniertes (SAN-)TLS-Zertifikat.
Fehlermeldungen sind ein definiertes Verhalten(!!!111einself), denn niemand ist gezwungen, auf Anfragen "sinnvoll in den Augen des Anfragenden" zu reagieren (analog zu "Pings" oder klassisch bei Telefonanrufen); die einfachst-mögliche Lösung hierfür ist es, das Standardverhalten auszunutzen, auf welcher Protokoll-Ebene auch immer (denn der Anfragende ist dafür verantwortlich, was er mit jedwedem Ergebnis, welches er erhält, umgeht). Im Nachfolgenden sind aaa,bbb,ccc,ddd,nnnnn wie üblich numerisch:
% curl --resolve gibt.es.gar.nicht:nnnn:aaa.bbb.ccc.ddd -4 https://gibt.es.gar.nicht:nnnn
curl: (51) SSL: no alternative certificate subject name matches target host name 'gibt.es.gar.nicht'
% curl -4 https://aaa.bbb.ccc.ddd:nnnn
curl: (51) SSL: no alternative certificate subject name matches target host name 'aaa.bbb.ccc.ddd'
(Es steht dem Anfragenden hierbei frei, das abrufbare passende Zertifikat zu verwenden oder von der Nutzung abzusehen.)
Analog lassen sich selbst-signierte TLS-Zertifikate einsetzen, welche alles abdecken (auch IP-Adressen), wobei es wiederum dem Nutzer überlassen ist, ob er das akzeptiert, oder – etwas aufwendiger – man lässt alle Aufrufe ins Leere laufen (Timeout als definierte Fehlersituation auf der Seite des Anfragers).
(War zu langsam für eine Ergänzung des Postings.)
jedenfalls müssen alle möglichen Hostnamen serverseitig abgefangen werden¹,
und es darf nicht zu einem undefiniertem Verhalten bei Verwendung von z.B. hostk.domaink.tld (mit 1 < k <= n) kommen;
Es gibt in diesem Zusammenhang kein undefiniertes Verhalten. Entweder die DNS-Auflösung liefert eine/mehrere IPs zurück, dann wird/werden diese kontaktiert, oder es gibt keine IP, dann wird eine Fehlermeldung erzeugt (anwendungs-/protokollabhängig). Wird die IP-Adresse kontaktiert und tritt dabei ein Fehler auf, ist auch das vollständig definiert. Alles durch entsprechende RFCs geregelt (auch, was "Brüche" in "CNAME-Ketten" anbelangt).
Es stimmt doch; f. den Browser ist es unerheblich ob die IP-Adresse direkt von einem A/AAAA Record kommt od. von einem mit einer mehrfachen Indirektion referenzierten CNAME Eintrag;
Ja, das steht so in meinem vorherigen Posting.
veranstaltet jemand sowas ...
Codehost1.domain1.tld CNAME host2.domain2.tld host2.domain2.tld CNAME host3.domain3.tld ... hostm.domainm.tld CNAME hostn.domainn.tld ; n = m + 1 hostn.domainn.tld A 46.57.17.161 hostn.domainn.tld AAAA 2001:2345:abcd:ef00::1dann braucht es auch entsprechendes im bzw. in den SSL-Zertifikat/-en;
Nein, braucht man nicht. Wäre das der Fall, würde sich curl ja in meinem vorherigen Beispiel bitterlich beschweren! Da gibt es keine Fehlermeldung, wenn nur "http[s]://host1.domain1.tld[:port]" angesprochen wird; hier der anonymisierte Mitschnitt (aaa.bbb.ccc.ddd stammt vom DNS-A-Eintrag für 0123456789abcdef.myfritz.net):
% curl --verbose https://server.vpn.example.org:12345
* Rebuilt URL to: https://server.vpn.example.org:12345/
* Trying aaa.bbb.ccc.ddd...
* TCP_NODELAY set
* Connected to server.vpn.example.org (aaa.bbb.ccc.ddd) port 12345 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS Unknown, Certificate Status (22):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS Unknown, Certificate Status (22):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS Unknown, Certificate Status (22):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS Unknown, Certificate Status (22):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS change cipher, Client hello (1):
* (304) (OUT), TLS Unknown, Certificate Status (22):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using unknown / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=*.vpn.example.org
* start date: Oct 4 09:18:28 2020 GMT
* expire date: Jan 2 09:18:28 2021 GMT
* subjectAltName: host "server.vpn.example.org" matched cert's "*.vpn.example.org"
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
* (304) (OUT), TLS Unknown, Unknown (23):
> GET / HTTP/1.1
> Host: server.vpn.example.org:12345
> User-Agent: curl/7.60.0
> Accept: */*
[...]Einfach einmal selbst ausprobieren.
Alternativ zur Weiterleitung unter Verwendung des HTTP(S)-Protokolls siehe hier: https://www.freecodecamp.org/news/why-cant-…c/#the-solution oder hier: https://serverfault.com/a/613830/346625 (Kurzgefasst: Netcup-Mitbewerber bieten hierfür Lösungen an, dies erfordert aber einen Umzug der Ausgangsdomäne, welche auf eine Zieldomäne verweisen soll.)
(Das wurde vor einiger Zeit schon (mindestens) einmal hier diskutiert, aber unter Verwendung des Suchbegriffs "CNAME" habe ich auf die Schnelle keinen Diskussionsfaden gefunden.)
Natürlich kann man Port 80 und 443 auf der FritzBox forwarden, denn das Admin Interface ist ja im Normalfall nur intern erreichbar.
forum.netcup.de/system/attachment/6008/
forum.netcup.de/system/attachment/6005/
Die Bilder sehe ich leider nicht?
Und Port 80/443 habe ich bislang bei der gemieteten Fritz!Box 6490C auch dann nicht weiterleiten können, wenn ich mich auf den Kopf stelle (fördert lediglich die Durchblutung); inwieweit das an einer Firmware-Modifikation des Internet-Service-Providers liegen könnte, habe ich noch nicht eruiert. Beide Ports durchzuleiten ist für meine Zwecke bislang nicht wirklich erforderlich, weil ich primär mehrere Instanzen eines tang-Diensts hinter der Fritz!Box betreibe.
