Beiträge von gunnarh

Muss gestehen, meine CipherSuite beinhaltete keinen WinXP/IE Support mehr.

Wenn Dir das wirklich wichtig ist, dann folgender Vorschlag: '-ALL:kEECDH+aRSA+AES:kEDH+aRSA+AES:-SHA1:DES-CBC3-SHA'

Das ergibt:

> openssl ciphers -v -tls1 '-ALL:kEECDH+aRSA+AES:kEDH+aRSA+AES:-SHA1:DES-CBC3-SHA'

ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1

Ich verwende: '-ALL:kEECDH+aRSA+AES:kEDH+aRSA+AES:+SHA1:aRSA+kRSA+AES+SHA1'

Das ergibt:

> openssl ciphers -v -tls1 '-ALL:kEECDH+aRSA+AES:kEDH+aRSA+AES:+SHA1:aRSA+kRSA+AES+SHA1'

ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1

Alternativ (wenn man sich damit nicht zu intensiv beschäftigen möchte) ist der Mozilla Generator einen Blick wert:

https://mozilla.github.io/server-side-tl…le=intermediate

Die /var/log/apache2/error.log ist das Error-Log des Apache-Dämon.

Den einzelnen vHosts spendiert man ja in der Regel separate Logs (ErrorLog-Direktive).

Was steht denn im Error-Log Deines vHosts? Ein 500er wird von Apache jedenfalls geloggt (ansonsten die LogLevel-Direktive prüfen).

Zitat von martin\

Die Domain ist aber bei he.net eingetragen.

Die he.net Nameserver (ns2.he.net, ns3.he.net, ...) sind für gcal.ch nicht autoritativ, die Fehlermeldung erscheint mir daher korrekt.

Ich war nun mit meinem Root-Server ebenfalls betroffen, konnte nichts mehr an hotmail.com, outlook.com, outlook.at mailen.

Die Meldung betreffen geblocktem AS3150 habe ich auch erhalten:

host outlook-com.olc.protection.outlook.com[104.47.44.33] said: 550 5.7.1    Unfortunately, messages from [37.120.174.149] weren't sent. Please contact    your Internet service provider since part of their network is on our block    list (AS3150). You can also refer your provider to    http://mail.live.com/mail/troubleshooting.aspx#errors.    [SN1NAM04FT049.eop-NAM04.prod.protection.outlook.com] (in reply to MAIL    FROM command)

Ich habe beim Microsoft Support meine Server-IP 37.120.174.149 nun deblockieren lassen und ihnen außerdem mitgeteilt, dass AS3150 falsch ist. Das betreffende ASN von Netcup ist AS197540. Da ist bei Microsoft also irgendwo der Wurm drinnen, die Zuordnung IP-Adresse des Servers zu ASN scheint falsch zu sein, und das falsche ASN wird geblockt.

Heute morgen wurde mein Case von Microsoft abgeschlossen:

Zitat

We have investigated your IP address and have applied required mitigation for your deliverability problem.

Testmails an outlook.com Adressen funktionieren von meinem Server aus nun wieder korrekt.

Eventuell wurde die Problematik nun gelöst (auch für euch?) -> Ansonsten sollte sich NetCup denke ich der Sache annehmen und diese falsche ASN-Zuordnung bei Microsoft reklamieren.

Die Microcode-Updates für aktuellere CPUs sind eigentlich bereits seit 08.01.2018 verfügbar:

https://downloadcenter.intel.com/download/27431…ocode-Data-File

Ob die OEM-Lieferanten (Server/Mainboad-Hersteller) diese bereits in Form von UEFI/BIOS-Updates verfügbar gemacht haben, hängt von der konkret eingesetzten Hardware ab. Im Fall von Linux können Microcode-Updates aber alternativ auch über das Software-Repository aktualisiert werden, z.B. Ubuntu: https://usn.ubuntu.com/usn/usn-3531-1/ (seit 11.01.2018 verfügbar).

Welche Tools/Scripts verwendet ihr, um den Status eurer Maschinen in Bezug auf Absicherungsmaßnahmen gegen Meltdown & Spectre zu prüfen?

Bei mir im Einsatz:

Linux: https://github.com/speed47/spectre-meltdown-checker

Windows: Get-SpeculationControlSettings (PowerShell Script, siehe https://support.microsoft.com/en-za/help/407…ings-powershell)

Gibt es andere Empfehlungen, wenn ja welche und warum?

Eine meiner Debian 8 VMs hatte übrigens den gepatchten Kernel 3.16.0-5-amd64 korrekt installiert, die Maschine wurde nach dem Kernel-Update auch korrekt neu gebootet - allerdings war das PAGE_TABLE_ISOLATION Feature (wie mir der spectre-meltdown-checker verriet) nicht aktiv. Config in /boot/config-3.16.0-5-amd64 war jedoch korrekt, und nach einem abermaligen Start nutzte der Kernel das PTI-Feature dann auch.

Ich war eigentlich der Meinung, dass seitens Netcup die nötigen Microcode CPU-Updates auf den Hostnodes bereits vorsorglich aufgebracht wurden (Kernel die diese nutzen stehen zumindest für Debian und Ubuntu meines Wissens nach noch nicht bereit). Der Checker bestätigt das allerdings nicht:

Spectre and Meltdown mitigation detection tool v0.29

Checking for vulnerabilities against running kernel Linux 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64
CPU is Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  NO
> STATUS:  VULNERABLE  (only 33 opcodes found, should be >= 70, heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  NO
*   Kernel support for IBRS:  NO
*   IBRS enabled for Kernel space:  NO
*   IBRS enabled for User space:  NO
* Mitigation 2
*   Kernel compiled with retpoline option:  NO
*   Kernel compiled with a retpoline-aware compiler:  NO
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  YES
* PTI enabled and active:  YES
> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

Ich verstehe die Frage bzw. das hier diskutierte Problem nicht. Was haben Slave-Server mit DNSSec zu tun? Die Vorgabe zwei Nameserver zu benötigen ist eine Vorgabe der meisten TLD-Registries, völlig unabhängig davon ob DNSSec genutzt wird oder nicht. Die Slave-Server müssen technisch gesehen kein DNSSec beherrschen, die DNSSec-spezifischen Records werden allesamt am Master generiert und landen per Zone-Transfer auf den Slaves, die davon wiederum gar nichts wissen müssen.

According to https://github.com/virtio-win/kvm-guest-drivers-windows there are no free WHQL-signed (required for Win10) Drivers available.

Danke mainziman für den Hinweis auf RFC 2317 - Classless IN-ADDR.ARPA delegation

Muss gestehen das kannte ich bislang nicht und habe ich "in the wild" auch noch nie gesehen.

Interessanter Ansatz, wenngleich das streng genommen keine Delegation ist, denn man ist ja für jede einzelne IP-Adresse vom gesetzten CNAME in der Zone des betreffenden /24er Subnetzes abhängig. Aber interessante Lösung - vielleicht möchte Netcup das ja anbieten

Zitat von anco

Das wird Facebook auch wissen und ich denke auch technisch differenzieren. Desweiteren sieht ein Proxy meistens nach aussen auch anders aus als ein normaler Client.

Die von mir zitierten Nutzungs-Szenarien sind Carrier Grade NAT oder haushaltsübliches NAT des SOHO-Routers, da ist also kein Proxy im Spiel, der einen Forwarded-For-Header setzen könnte.

Und in Unternehmen mit Proxy wird heutzutage üblicherweise auch kein Forwarded-For-Header mehr gesetzt, da dies zu viel Netzwerk-Internas nach außen preisgibt.

Die Handhabe von über WHOIS veröffentlichten Daten und die zugrunde liegenden ICANN Regeln könnten sich mit Wirksamwerden der EU-DSGV durchaus etwas ändern, hier etwas Lesestoff:

https://www.heise.de/newsticker/mel…en-3875628.html

https://www.heise.de/newsticker/mel…he-3877085.html

Zitat von Skinnygirl

Meinst Du damit, dass das mit "mehrere Accounts über eine IP-Adresse ansteuern", nicht problematisch ist?

Warum sollte dies problematisch sein? Bei jedem Haushaltsanschluss (der in der Regel nur eine IPv4 besitzt) sind heute typischerweise 3-5 Personen mit ihren unterschiedlichen Konten gleichzeitig online und nutzen SocialMedia. Bei CarrierGradeNat-Teilnehmeranschlüssen teilen sich dutzende Kunden die gleiche IPv4 und größere Unternehmen oder Unis mit mehreren tausend Concurrent-Usern haben meist auch nur eine 1-stellige Anzahl an IP-Adressen über die sie ihre ausgehenden Web-Zugriffe abwickeln.

RainLoop ist aber nur für Personal / Non-Commercial Use kostenfrei. https://www.rainloop.net/purchase/

Drei Mailserver sind vermutlich nicht "Personal Use", Mailserver betreibt man - selbst wenn nicht kommerziell betrieben - doch in der Regel mit mehreren (fremden) Postfächern.

=> EDIT: Sorry, ziehe diesen Aspekt zurück, es gibt auch eine unter AGPLv3 stehende Community Edition!

Ich würde RoundCube für jeden Mailserver getrennt installieren. Der Wartungsaufwand beim gelegentlichen Versions-Upgrade ist überschaubar, die Fummelei mit der Multi-Domain-Konfiguration wäre mir zu nervig.

Die Antwort auf diese Frage sollte denke ich dieser Post hier liefern:

https://forum.netcup.de/anwendung/imap…ikat/#post85311

eIDAS führt kein neues Signatur- oder Verschlüsselungsverfahren ein, es regelt lediglich die Anforderungen hinsichtlich Zertifikatsdiensteanbieter und wechselweise Anerkennung qualifizierter elektronischer Signaturen. De-Fakto bleibt zur Nutzung dann nur SMIME. Ob ich mir von meiner Gegenstelle nun das SMIME-Zertifikat besorgen muss, es per LDAP aus einem der Verzeichnisdienste rausklaube oder einen GPG/PGP-Key auf einem Keyserver raussuche kommt vom Aufwand her aufs gleiche raus. Das leidige Thema der E-Mail-Verschlüsselung wird durch eIDAS auch nicht handhabbarer.

Der netcup-Mailserver ist zwar leider nicht mit DANE abgesichert, verwendet aber immerhin ein gültiges TLS-Zertifikat für den STARTTLS-SMTP-Transportschutz und bietet zeitgemäße Cipher-Suiten an. Für meinen Geschmack ist das nicht "unverschlüsselt" sofern Dein Mailserver passend konfiguriert ist.

gunnar@nc:~$ posttls-finger -f -l dane -P /etc/ssl/certs/ -L summary netcup.net
posttls-finger: Connected to smtp.netcup.net[2a03:4000:0:1::e1aa]:25
posttls-finger: < 220 smtp.netcup.net ESMTP Postfix (Debian/GNU)
posttls-finger: > EHLO nc.hitco.at
posttls-finger: < 250-smtp.netcup.net
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-SIZE 52428800
posttls-finger: < 250-VRFY
posttls-finger: < 250-ETRN
posttls-finger: < 250-STARTTLS
posttls-finger: < 250-AUTH PLAIN LOGIN
posttls-finger: < 250-AUTH=PLAIN LOGIN
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-8BITMIME
posttls-finger: < 250 DSN
posttls-finger: > STARTTLS
posttls-finger: < 220 2.0.0 Ready to start TLS
posttls-finger: Verified TLS connection established to smtp.netcup.net[2a03:4000:0:1::e1aa]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
posttls-finger: > EHLO nc.hitco.at
posttls-finger: < 250-smtp.netcup.net
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-SIZE 52428800
posttls-finger: < 250-VRFY
posttls-finger: < 250-ETRN
posttls-finger: < 250-AUTH PLAIN LOGIN
posttls-finger: < 250-AUTH=PLAIN LOGIN
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-8BITMIME
posttls-finger: < 250 DSN
posttls-finger: > QUIT
posttls-finger: < 221 2.0.0 Bye

Die Ziel-IP ist Dein (Cloud-)Storage-Provider? Sicher?

Mir kommt das etwas merkwürdig vor. Ich schiebe z.B. jeweils am Monatsletzten eine Vollsicherung mit ca. 50-60GB auf einen anderen Server, der nicht im NetCup-Rechenzentrum steht. Das ist somit deutlich mehr als Du hier verbraucht hast. Und ich tue das in ca. 3 Stunden. Eine Abuse-Meldung habe ich noch nie erhalten. Allerdings muss ich zugeben, dass ich dabei offenkundig nicht so flott unterwegs bin wie du.

Wer hat Dir das geschickt? NetCup im eigenen Namen, oder jemand anderer und NetCup hat es Dir nur aufbereitet und weitergeleitet?

Zur Frage des "maximalen Speed": Die Abuse-Meldung spricht von "Treshold Packets: 30000 packets/s" und weiters von "74445 packets/s" sowie "724.8 MBit/s". Wenn ich 724,8MBit durch 74445 Pakete/s dividiere komme ich somit auf eine durchschnittliche Paketgröße von 1217 Bytes -> OK, das klingt plausibel. Dass Dein Server mit 725MBit gesendet hat klingt jetzt auch nicht unplausibel.

Um demnach den Treshold von 30.000 Paketen/sek nicht zu überschreiten, dürftest Du bei einer Paketgröße von eben ca. 1217 Bytes demnach nicht mehr als mit 290MBit/Sek bzw. 36MByte/Sek senden.

chrko: DNSKEY Hash versus vollen Public-Key: Danke für den Hinweis, Du hast recht. DENIC nimmt tatsächlich den vollen Key auf, NIC.at nur den Hash. Somit ist der von mir bemängelte Screenshot im Wiki doch nicht falsch, er trifft nur nicht auf .at Domains zu.

Ich rege hier an beim Eingabefeld doch den Begriff "Hash" nebst "Öffentlicher Schlüssel" zu ergänzen und im Wiki vielleicht einen Hinweis zu Unterschieden je nach Domain-Endung aufzunehmen.

Was die Pflege der im Whois hinterlegten Daten angeht: Ich bin der Meinung, dass der Status-Quo nicht mit den nic.at Registrierungsrichtlinien im Einklang ist. Konkret hat der Admin-C auch eine E-Mail Adresse verpflichtend zu beinhalten, diese fehlt jedoch in meinem Handle und ich habe keine Möglichkeit sie zu ergänzen. Weiters ist als Tech-C der technisch für die Zone Verantwortliche zu führen. Das ist nur dann Netcup, wenn Netcup die authoritativ antwortenden Nameserver für die betreffende Domain hostet. Da ich jedoch meine eigenen Nameserver verwende ist ein auf Netcup lautender Tech-C nicht korrekt.

Feedback meinerseits:

• Habe heute die Domain hitco.at erfolgreich zu NetCup transferiert
• Da während des Transfers keine eigenen Nameserver setzbar sind, muss man zwischenzeitlich in Kauf nehmen, dass die NetCup-Nameserver gesetzt werden und kann diese dann aber bereits wenige Sekunden nachdem der Transfer vollzogen war im CCP auch gleich wieder entfernen und seine eigenen Nameserver eintragen. Ich habe den Transfer um ca. 13:30 vorgenommen - die nic.at Nameserver reloaden um 1:00, 3:00, 5:00, 7:00, 9:00, 11:00, 13:00, 15:00, 17:00, 19:00, 21:00 und 23:00 Uhr (MEZ), somit hatte ich ausreichend Zeit bis die Änderungen um 15:00 überhaupt nach außen hin sichtbar geworden sind, um meine eigenen Nameserver wieder einzutragen.
• Der Roboter arbeitet wirklich "live" - da gibt es nichts zu bemängeln. Nameserver-Änderungen sind wenige Sekunden später bereits am whois.nic.at sichtbar, die tatsächlichen Nameserver-Reload-Zeiten von nic.at habe ich ja bereits genannt, zu diesen Zeiten werden die Änderungen auch tatsächlich auf den nic.at-Root-Nameservern aktiv.

Leider gibt es aus meiner Sicht auch etwas weniger erfreuliches zu berichten:

• Der Tech-C Kontakt ist nicht durch mich beeinflussbar, da trägt sich fix [netcup] Felix P. als "Felix Preuss" mit seinen Daten ein. Ich bevorzuge selbst mit meinem Handle aufzuscheinen, gemäß Support wurde mir nur mitgeteilt das wäre nicht möglich. War bisher bei allen Registraren bei denen ich war problemlos möglich. Das ist somit sehr überraschend und unerfreulich.
• Im Whois fehlt bei meinem Handle meine E-Mail-Adresse und Telefonnummer. Mag sein, dass andere Kunden bevorzugen diese Daten nicht zu veröffentlichen, ich möchte aber das diese Daten aufscheinen. Auch das ist gemäß Support (Ticket [NC#2017082310003211]) nicht anpassbar, auch nicht vom Support manuell. Das ist somit ebenfalls sehr überraschend und unerfreulich.
• Was außerdem noch aufgefallen ist, der Screenshot zur DNSSec-Konfiguration im Wiki ist veraltet bzw. nicht mehr zutreffend. Im Wiki wird suggeriert man müsse für DNSSec den PublicKey (Base64-kodierte, lange Form) einfügen. Das ist jedoch falsch - korrekt ist den z.B. mittels dnssec-dsfromkey ermittelten SHA256-Hash seines DNSSec-PublicKeys in das Formular einzutragen, also z.B. NICHT AwEAAfkizZhZ9JIJae1HfRkcTFohfZJTNaagAcK+FiapxTlXV3hUaS5j zrDG3pq6tcD10dCCFhW5ottpaS/3udxAxU0szo+V/FQm/qUkoZ/Er5h2 JT/s44OXuqyqyQqqZJbokMs3zuZV4CAe4+nm0aYl7AEwgS+A1Kafb1BL XIkxxfIulhFJEJYiFxzeNpdG/DWmSisUHb2msyTsMqwM/0+JVnnxEmGD 8Tya99DnQssX40mQpE4BNoMq37/iA94ZVcGPv11dMb5NGfOd8blKvF5v Rv1cPTrn/cQVZp7NKqW6KcrVFixN38pAdlgVMA3/CVzkkUbkLLNTrCkS /n1Ki+tRf40=sondern korrekt 368431C5B526955803D14E4448D146BB99F3C5EE723CDD9E2B4C82C335C37284