-=Kernel-Error=-

Datenhaufen zu IT und Elektronik.

Kategorie: IT-Security (Seite 7 von 15)

Notizen & Praxis zur IT-Sicherheit – von Responsible Disclosure bis Härtung.

TLS 1.0 nur noch bis 30. Juni 2018 im PCI-Support: Was du wissen musst

15. Mai 2018 / / Keine Kommentare

Hallo zusammen,

sicher ist das schon bekannt aber damit ich es auch einmal geschrieben habe. Das PCI hat eine Deadline zum 30 Juni 2018 für den Support von TLS 1.0 gesetzt.

TLS 1.0 ist ab dem Moment „noch“ so gut wie vorher und es sollte kein Problem für uns alle sein aber alles was PCI konform sein möchte darf ab dann kein TLS 1.0 mehr einsetzten.

https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls

Nicht das ich PCI konform wäre *lach* aber es ist bei mir deaktiviert:

https://www.ssllabs.com/ssltest/analyze.html?d=www.kernel%2derror.de&latest

https://www.htbridge.com/ssl/?id=Cq6PBF3g

So long….

IT Trends Sicherheit 2018 in Bochum

21. März 2018 / / Keine Kommentare

Ich bin heute der Einladung von TMR zu den IT Trends Sicherheit 2018 ins Stadion nach Bochum gefolgt.

Nach der Begrüßung und den Keynotes sitze ich nun im zweiten Vortrag meiner Wahl. Bisher alles ok, was mir aber wieder im direkten Vergleich zu einem Vortrag in Club oder einer OpenSource Messe auffällt ist dieser doch starke Eindruck einer Verkaufsveranstaltung. Ok das ist zu erwarten und auch in Ordnung. Auf vielen OpenSource Messe wandert es ebenfalls immer mehr in diese Richtung, es fällt mir nur gerade sehr auf.

Viele Informationen sind dennoch wertvoll und neue Kontakte können ebenfalls nicht schaden.

SSD Secure Erase mit FreeBSD: So löschst du deine SSD sicher

20. März 2018 / / Ein Kommentar

Um alle Daten einer SSD möglichst sicher zu löschen gibt es im ATA die Funktion: „ATA Secure Erase“. Möchte man nun seine SSD schnell und einfach von allen Daten befreien (dd mit Nullen ist ja eher eine schlechte und nicht funktionsfähige Möglichkeit bei SSDs), nutzt man einfach diese Funktion.

Bei einem FreeBSD sieht dieses unter optimalen Bedingungen wie folgt aus:

root@sun-wks:/usr/home/kernel # camcontrol security ada4 -s Erase -e Erase
pass7: <OCZ-AGILITY3 2.15> ATA8-ACS SATA 3.x device
pass7: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)

You are about to ERASE ALL DATA from the following device:
pass7,ada4: <OCZ-AGILITY3 2.15> ATA8-ACS SATA 3.x device

Are you SURE you want to ERASE ALL DATA? (yes/no) yes
Issuing SECURITY_SET_PASSWORD password='Erase', user='master', mode='high'
Issuing SECURITY_ERASE_PREPARE
Issuing SECURITY_ERASE_UNIT password='Erase', user='master'

Erase Complete

Optimale Bedingungen?

Das eine oder andere BIOS „schützt“ die Festplatten vor dieser Funktion und sorgt dafür das sie nicht genutzt werden kann. Hier hilft es die Platte erst nach dem Boot anzuschließen. Um die Funktion nutzen zu können muss der SSD ebenfalls erst ein Kennwort gegeben werden. Ohne gesetztes Kennwort kann die Funktion ebenfalls nicht genutzt werden. Ich habe dieses in einem Abwasch erledigt indem ich erst das Kennwort und dann direkt die Funktion mit dem gesetzten Kennwort aufrufe (-s Erase -e Erase) Erase ist also in meinem Beispiel das gesetzte Kennwort.

Da wir gerade dabei sind… Viele SSDs habe eine Art „Selbstheilungsmodus“… Ist diese aktiviert prüft sich die SSD selbst und repariert sich, soweit möglich. Dieser Modus wird aktiviert wenn die SSD am Strom aber nicht am Datenbus angeschlossen ist. Bedeutet. SATA/SAS Kabel abziehen. Strom anschließen/einschalten und warten. In der Regel sollten SSDs nach knapp 4 Stunden mit ihrer „Selbstheilung“ fertig sein. Dieses lässt sich natürlich im Anschluss noch einmal wiederholen. Funktioniert die SSD nach zwei Durchläufen noch nicht wie gewünscht, wird sie wohl wirklich kaputt sein.

Fragen? Dann Fragen 😀

DNS über TLS mit Stunnel und BIND9 einrichten: Anleitung für mehr Sicherheit

22. Dezember 2017 / / Keine Kommentare

Ihr erinnert euch an meine Ankündigung über TLS an meinem DNS vor ein paar Tagen? RFC 7858 – DNS over Transport Layer Security

Bei mir ist inzwischen recht oft die Frage nach dem „Wie“ angekommen. Nun ich habe dafür stunnel benutzt. stunnel ist nicht speziell für DNS sondern ist ein Stück Software welches sich vor Dienste schalten lässt die keine oder eine schlechte Implementierung für SSL/TLS haben. Eine komplett stumpfe Konfiguration um zu testen würde zum Beispiel auf einem FreeBSD wie folgt aussehen:

/usr/local/etc/stunnel/conf.d/dnstls.conf

[dns4]
accept = 853
connect = 5.9.24.235:53
cert = /usr/local/etc/stunnel/ssl/dns.crt
key = /usr/local/etc/stunnel/ssl/dns.key
CAfile = /usr/local/etc/stunnel/ssl/ca.crt



[dns6]
accept = :::853 connect = 5.9.24.235:53
cert = /usr/local/etc/stunnel/ssl/dns.crt
key = /usr/local/etc/stunnel/ssl/dns.key
CAfile = /usr/local/etc/stunnel/ssl/ca.crt

So gestartet lässt sich eine TLS Verbinung zu Port 853 aufbauen und stunnel schiebt dann alles einfach weiter an den Bind auf Port 53. Ob eine SSL/TLS Verbindung aufgebaut werden kann testet man am besten mit openSSL: openssl s_client -connect ns1.kernel-error.de:853 -showcerts Ich werfe weiter unten mal den kompletten Output in den Post…

Um eine komplette DNS Abfrage über TLS zu prüfen nutze ich gerne getdns_query. Dieses ist bereits in den FreeBSD Ports. Ein Test würde wie folgt aussehen: getdns_query @5.9.24.235 -s -a -A -l L www.kernel-error.de AAAA die Option „-l L“ weißt getdns_query dabei an es per TLS zu probieren. Auch hier werde ich den kompletten Output weiter untem im Post zeigen.

Der versprochene openSSL Output

kernel@s-meer-bsd ~> openssl s_client -connect ns1.kernel-error.de:853 -showcerts
CONNECTED(00000003)
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = AlphaSSL CA - SHA256 - G2
verify return:1
depth=0 OU = Domain Control Validated, CN = *.kernel-error.de
verify return:1
---
Certificate chain
 0 s:/OU=Domain Control Validated/CN=*.kernel-error.de
   i:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
-----BEGIN CERTIFICATE-----
MIIIVjCCBz6gAwIBAgIMKHSoWgqp4f0QDMWoMA0GCSqGSIb3DQEBCwUAMEwxCzAJ
BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIwIAYDVQQDExlB
bHBoYVNTTCBDQSAtIFNIQTI1NiAtIEcyMB4XDTE3MDMxMDEwNTI1MloXDTE4MDMx
MTEwNTI1MlowPzEhMB8GA1UECxMYRG9tYWluIENvbnRyb2wgVmFsaWRhdGVkMRow
GAYDVQQDDBEqLmtlcm5lbC1lcnJvci5kZTCCAiIwDQYJKoZIhvcNAQEBBQADggIP
ADCCAgoCggIBAMtVm/TykTvxvwZN0h6H2YeIeu4G+scVCb+kxxa8Jrua7DuLchjm
05wj6zPTe+2opDNNeZ6T5/ISSKczUQO4p+ttxFzl8OGA8FaZe4Qc9FNYdzY35w2d
oMgpTpsO+xTEdLHbXcNvEdFXg/8vyKS5y9Ddp8mSvz/Mt04rj2sjXGWwV00ImDQ1
DHBEuNuvFsnyaXQkDXeC3bA+2EkuVIcFcviQT5At88CDLkP8ygJsD3iDudnVeEJZ
N1AFnjN/qQksjKvT5V75R7GcIhA0a6lC56iBmEykht8YdPy63940hYmO4Ug17p68
7uiPZKUsFkGmYchbkiw5KLTck6VVv9b5Z+lFfIQcfBf5blmaUkQQ8CP3yXXajmfP
3KqJu5c+M3OW9evFiE+z7ihtKVtOHQS86z0ijvSNaCfj9OWQKXhBzBzdEGTogC7n
Iq8YYjveRQ+ExffM+RY3xaqMc1368tUx6ir+0LdGiqgzDC5OcWPqRTNobeTfcETz
VCxqgTfVr4tDNTk1+LmRsWKVDuBtG3p/lJEwCU1z6ZP6xmNTBZc1iOuNOJN+CmYW
ZpKaI3F6JPRK4G2Hu4fa0GWjRHSSZYFkyBl520a8fTMGIY8JlfHfx9HVK2fFJ4yP
NxKligKSydphqEG8cyEU/V3oRlgZ7en1HmrWRrIRiWcmWk3qKl/AZk97AgMBAAGj
ggRDMIIEPzAOBgNVHQ8BAf8EBAMCBaAwgYkGCCsGAQUFBwEBBH0wezBCBggrBgEF
BQcwAoY2aHR0cDovL3NlY3VyZTIuYWxwaGFzc2wuY29tL2NhY2VydC9nc2FscGhh
c2hhMmcycjEuY3J0MDUGCCsGAQUFBzABhilodHRwOi8vb2NzcDIuZ2xvYmFsc2ln
bi5jb20vZ3NhbHBoYXNoYTJnMjBXBgNVHSAEUDBOMEIGCisGAQQBoDIBCgowNDAy
BggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9y
eS8wCAYGZ4EMAQIBMAkGA1UdEwQCMAAwPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDov
L2NybDIuYWxwaGFzc2wuY29tL2dzL2dzYWxwaGFzaGEyZzIuY3JsMC0GA1UdEQQm
MCSCESoua2VybmVsLWVycm9yLmRlgg9rZXJuZWwtZXJyb3IuZGUwHQYDVR0lBBYw
FAYIKwYBBQUHAwEGCCsGAQUFBwMCMB0GA1UdDgQWBBSL6GOdfjNSVXP7NNrKRfN/
ZEGEJTAfBgNVHSMEGDAWgBT1zdU8CFD5ak86t5faVoPmadJo9zCCAm0GCisGAQQB
1nkCBAIEggJdBIICWQJXAHUAu9nfvB+KcbWTlCOXqpJ7RzhXlQqrUugakJZkNo4e
0YUAAAFat9mThAAABAMARjBEAiBA/XALdgdBZzdvL20DwfeGUAKVhFAueJG6hIWF
eooeSwIgBAMtgDdRxtSkDbKZdkuT9pul6HlZgGSKBLwHjt08rSAAdgDd6x0reg1P
piCLga2BaHB+Lo6dAdVciI09EcTNtuy+zAAAAVq32ZOaAAAEAwBHMEUCIAwdq+Ma
WZ+v8TuKuwIT9oTHT6mlOuov2brZHNa53o5MAiEAq1ZFktpd5XzJQixebUuaCNKW
dZWUF58tKuB4l7xvGOUAdgCkuQmQtBhYFIe7E6LMZ3AKPDWYBPkb37jjd80OyA3c
EAAAAVq32ZZ1AAAEAwBHMEUCIAUVh0ZRcb/+WRb9F+nn/Jmzvgs/bnLQNwEjBUT1
/t2aAiEAmZWAnrB3RnsCbedw8SOvJk6HsZG67T0fdI96M/Pc47kAdgBWFAaaL9fC
7NP14b1Esj7HRna5vJkRXMDvlJhV1onQ3QAAAVq32Za/AAAEAwBHMEUCIQD92ZOc
1xqff1TJ7gsw/ZGtkvzrjIW6uu/Hu7ZxBKkOgQIgRC0TkK19+m8nUN7KDCqyKsZT
DqUrKE01MuPhx1RnIPMAdgDuS723dc5guuFCaR+r4Z5mow9+X7By2IMAxHuJeqj9
ywAAAVq32ZllAAAEAwBHMEUCIQCPAWIduEfXjVVq+qKHEtoy84Nqm+PsibSk8uXq
ziMziQIgJp3NRvIM8bFtzQe/ZQYBnNv2H3MwZmldaIbV5VcbMOQwDQYJKoZIhvcN
AQELBQADggEBAKmQsE/CjF2nRuqaPZht7EFsQpHzihm+VBA48HDN0Uj9JpObHadg
kxNunKd3K+KNsZP4gwg8Z+LfNAU2smK//Ptq7S/y3ECZTniwLMNx4ogekIuQ9i6a
5zgdN3TpWMV/pu2PEguG/FhDIeIEoC5L7qYAKsSq/4VMexUeVfg3IDbdFH0FGlF7
NRAvfY8KfkvkM6c0VhkAuisnYpt+N3RoXOUlQEbv2qRPikiRnLW4hyms0Y73W5v2
GBA6H66lPIqWTzalY9d1kUVY0N+qz/ZgZhdY0LkeTHG4l+XAyKwa241LHGtDHz7m
7c9LBqS3mXSFvfCL9eU2vzDHkU6cMixjf94=
-----END CERTIFICATE-----
 1 s:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
-----BEGIN CERTIFICATE-----
MIIETTCCAzWgAwIBAgILBAAAAAABRE7wNjEwDQYJKoZIhvcNAQELBQAwVzELMAkG
A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jv
b3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw0xNDAyMjAxMDAw
MDBaFw0yNDAyMjAxMDAwMDBaMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i
YWxTaWduIG52LXNhMSIwIAYDVQQDExlBbHBoYVNTTCBDQSAtIFNIQTI1NiAtIEcy
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2gHs5OxzYPt+j2q3xhfj
kmQy1KwA2aIPue3ua4qGypJn2XTXXUcCPI9A1p5tFM3D2ik5pw8FCmiiZhoexLKL
dljlq10dj0CzOYvvHoN9ItDjqQAu7FPPYhmFRChMwCfLew7sEGQAEKQFzKByvkFs
MVtI5LHsuSPrVU3QfWJKpbSlpFmFxSWRpv6mCZ8GEG2PgQxkQF5zAJrgLmWYVBAA
cJjI4e00X9icxw3A1iNZRfz+VXqG7pRgIvGu0eZVRvaZxRsIdF+ssGSEj4k4HKGn
kCFPAm694GFn1PhChw8K98kEbSqpL+9Cpd/do1PbmB6B+Zpye1reTz5/olig4het
ZwIDAQABo4IBIzCCAR8wDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C
AQAwHQYDVR0OBBYEFPXN1TwIUPlqTzq3l9pWg+Zp0mj3MEUGA1UdIAQ+MDwwOgYE
VR0gADAyMDAGCCsGAQUFBwIBFiRodHRwczovL3d3dy5hbHBoYXNzbC5jb20vcmVw
b3NpdG9yeS8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWdu
Lm5ldC9yb290LmNybDA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAGGIWh0dHA6
Ly9vY3NwLmdsb2JhbHNpZ24uY29tL3Jvb3RyMTAfBgNVHSMEGDAWgBRge2YaRQ2X
yolQL30EzTSo//z9SzANBgkqhkiG9w0BAQsFAAOCAQEAYEBoFkfnFo3bXKFWKsv0
XJuwHqJL9csCP/gLofKnQtS3TOvjZoDzJUN4LhsXVgdSGMvRqOzm+3M+pGKMgLTS
xRJzo9P6Aji+Yz2EuJnB8br3n8NA0VgYU8Fi3a8YQn80TsVD1XGwMADH45CuP1eG
l87qDBKOInDjZqdUfy4oy9RU0LMeYmcI+Sfhy+NmuCQbiWqJRGXy2UzSWByMTsCV
odTvZy84IOgu/5ZR8LrYPZJwR2UcnnNytGAMXOLRc3bgr07i5TelRS+KIz6HxzDm
MTh89N1SyvNTBCVXVmaU6Avu5gMUTu79bZRknl7OedSyps9AsUSoPocZXun4IRZZ
Uw==
-----END CERTIFICATE-----
---
Server certificate
subject=/OU=Domain Control Validated/CN=*.kernel-error.de
issuer=/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4014 bytes and written 433 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: B1956B432DABE228C78E756329A796FA56C9646BE64326F8F96782BD946CCA82
    Session-ID-ctx: 
    Master-Key: 10329FBAE32471FC56D45E0AA0971CF5EB7977F7569AE4079219D9438E7A0F9DA8EC4150D9A074FC0AD8E63E00849047
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1513937385
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

Der versprochene getdns_query Output:

kernel@s-meer-bsd ~> getdns_query @5.9.24.235 -s -a -A -l L www.kernel-error.de AAAA
{
  "answer_type": GETDNS_NAMETYPE_DNS,
  "canonical_name": <bindata for www.kernel-error.de.>,
  "just_address_answers":
  [
    {
      "address_data": <bindata for 2a01:4f8:161:3ec::443>,
      "address_type": <bindata of "IPv6">
    },
    {
      "address_data": <bindata for 5.9.24.250>,
      "address_type": <bindata of "IPv4">
    }
  ],
  "replies_full":
  [
     <bindata of 0xd3578500000100010003000703777777...>,
     <bindata of 0xe9288500000100010003000703777777...>
  ],
  "replies_tree":
  [
    {
      "additional":
      [
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns1.kernel-error.de.>,
          "rdata":
          {
            "ipv4_address": <bindata for 5.9.24.235>,
            "rdata_raw": <bindata of 0x050918eb>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_A
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns2.kernel-error.org.>,
          "rdata":
          {
            "ipv4_address": <bindata for 176.9.109.53>,
            "rdata_raw": <bindata of 0xb0096d35>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_A
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns3.kernel-error.com.>,
          "rdata":
          {
            "ipv4_address": <bindata for 203.137.119.119>,
            "rdata_raw": <bindata of 0xcb897777>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_A
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns1.kernel-error.de.>,
          "rdata":
          {
            "ipv6_address": <bindata for 2a01:4f8:161:3ec::53>,
            "rdata_raw": <bindata of 0x2a0104f8016103ec0000000000000053>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_AAAA
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns2.kernel-error.org.>,
          "rdata":
          {
            "ipv6_address": <bindata for 2a01:4f8:150:1095::53>,
            "rdata_raw": <bindata of 0x2a0104f8015010950000000000000053>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_AAAA
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns3.kernel-error.com.>,
          "rdata":
          {
            "ipv6_address": <bindata for 2001:310:6000:f::1fc7:1>,
            "rdata_raw": <bindata of 0x200103106000000f000000001fc70001>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_AAAA
        },
        {
          "do": 0,
          "extended_rcode": 0,
          "rdata":
          {
            "rdata_raw": <bindata of 0x>
          },
          "type": GETDNS_RRTYPE_OPT,
          "udp_payload_size": 4096,
          "version": 0,
          "z": 0
        }
      ],
      "answer":
      [
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for www.kernel-error.de.>,
          "rdata":
          {
            "ipv6_address": <bindata for 2a01:4f8:161:3ec::443>,
            "rdata_raw": <bindata of 0x2a0104f8016103ec0000000000000443>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_AAAA
        }
      ],
      "answer_type": GETDNS_NAMETYPE_DNS,
      "authority":
      [
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for kernel-error.de.>,
          "rdata":
          {
            "nsdname": <bindata for ns2.kernel-error.org.>,
            "rdata_raw": <bindata for ns2.kernel-error.org.>
          },
          "ttl": 86400,
          "type": GETDNS_RRTYPE_NS
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for kernel-error.de.>,
          "rdata":
          {
            "nsdname": <bindata for ns1.kernel-error.de.>,
            "rdata_raw": <bindata of 0x036e7331c010>
          },
          "ttl": 86400,
          "type": GETDNS_RRTYPE_NS
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for kernel-error.de.>,
          "rdata":
          {
            "nsdname": <bindata for ns3.kernel-error.com.>,
            "rdata_raw": <bindata for ns3.kernel-error.com.>
          },
          "ttl": 86400,
          "type": GETDNS_RRTYPE_NS
        }
      ],
      "canonical_name": <bindata for www.kernel-error.de.>,
      "header":
      {
        "aa": 1,
        "ad": 0,
        "ancount": 1,
        "arcount": 7,
        "cd": 0,
        "id": 54103,
        "nscount": 3,
        "opcode": GETDNS_OPCODE_QUERY,
        "qdcount": 1,
        "qr": 1,
        "ra": 0,
        "rcode": GETDNS_RCODE_NOERROR,
        "rd": 1,
        "tc": 0,
        "z": 0
      },
      "question":
      {
        "qclass": GETDNS_RRCLASS_IN,
        "qname": <bindata for www.kernel-error.de.>,
        "qtype": GETDNS_RRTYPE_AAAA
      }
    },
    {
      "additional":
      [
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns1.kernel-error.de.>,
          "rdata":
          {
            "ipv4_address": <bindata for 5.9.24.235>,
            "rdata_raw": <bindata of 0x050918eb>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_A
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns2.kernel-error.org.>,
          "rdata":
          {
            "ipv4_address": <bindata for 176.9.109.53>,
            "rdata_raw": <bindata of 0xb0096d35>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_A
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns3.kernel-error.com.>,
          "rdata":
          {
            "ipv4_address": <bindata for 203.137.119.119>,
            "rdata_raw": <bindata of 0xcb897777>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_A
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns1.kernel-error.de.>,
          "rdata":
          {
            "ipv6_address": <bindata for 2a01:4f8:161:3ec::53>,
            "rdata_raw": <bindata of 0x2a0104f8016103ec0000000000000053>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_AAAA
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns2.kernel-error.org.>,
          "rdata":
          {
            "ipv6_address": <bindata for 2a01:4f8:150:1095::53>,
            "rdata_raw": <bindata of 0x2a0104f8015010950000000000000053>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_AAAA
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns3.kernel-error.com.>,
          "rdata":
          {
            "ipv6_address": <bindata for 2001:310:6000:f::1fc7:1>,
            "rdata_raw": <bindata of 0x200103106000000f000000001fc70001>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_AAAA
        },
        {
          "do": 0,
          "extended_rcode": 0,
          "rdata":
          {
            "rdata_raw": <bindata of 0x>
          },
          "type": GETDNS_RRTYPE_OPT,
          "udp_payload_size": 4096,
          "version": 0,
          "z": 0
        }
      ],
      "answer":
      [
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for www.kernel-error.de.>,
          "rdata":
          {
            "ipv4_address": <bindata for 5.9.24.250>,
            "rdata_raw": <bindata of 0x050918fa>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_A
        }
      ],
      "answer_type": GETDNS_NAMETYPE_DNS,
      "authority":
      [
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for kernel-error.de.>,
          "rdata":
          {
            "nsdname": <bindata for ns2.kernel-error.org.>,
            "rdata_raw": <bindata for ns2.kernel-error.org.>
          },
          "ttl": 86400,
          "type": GETDNS_RRTYPE_NS
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for kernel-error.de.>,
          "rdata":
          {
            "nsdname": <bindata for ns1.kernel-error.de.>,
            "rdata_raw": <bindata of 0x036e7331c010>
          },
          "ttl": 86400,
          "type": GETDNS_RRTYPE_NS
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for kernel-error.de.>,
          "rdata":
          {
            "nsdname": <bindata for ns3.kernel-error.com.>,
            "rdata_raw": <bindata for ns3.kernel-error.com.>
          },
          "ttl": 86400,
          "type": GETDNS_RRTYPE_NS
        }
      ],
      "canonical_name": <bindata for www.kernel-error.de.>,
      "header":
      {
        "aa": 1,
        "ad": 0,
        "ancount": 1,
        "arcount": 7,
        "cd": 0,
        "id": 59688,
        "nscount": 3,
        "opcode": GETDNS_OPCODE_QUERY,
        "qdcount": 1,
        "qr": 1,
        "ra": 0,
        "rcode": GETDNS_RCODE_NOERROR,
        "rd": 1,
        "tc": 0,
        "z": 0
      },
      "question":
      {
        "qclass": GETDNS_RRCLASS_IN,
        "qname": <bindata for www.kernel-error.de.>,
        "qtype": GETDNS_RRTYPE_A
      }
    }
  ],
  "status": GETDNS_RESPSTATUS_GOOD
}

Oh und weil ich gerade dabei war… Ich habe direkt ns2.kernel-error.org mit einem gültigen Zertifikat ausgestattet.

Fragen? Dann fragen 🙂

DNSSEC, EDNS und PMTU-Size Fehler beim BIND beheben

5. Juli 2017 / / Keine Kommentare

Mir ist in der letzten Zeit an ein paar Systemen ein kleines „Problem“ im Zusammenhang mit DNSSEC, IPv6 und UDP Paketgrößen aufgefallen. Wobei aufgefallen hier nicht ganz korrekt ist, ich bin durch http://dnsviz.net darauf gestoßen worden. Die Jungs kommen mir nämlich mit der folgenden Warnung entgegen:

domain.tld/A: No response was received until the UDP payload size was decreased, indicating that the server might be attempting to send a payload that exceeds the path maximum transmission unit (PMTU) size. (2001:210:5000:bbbb::aaaa:1, UDP_0_EDNS0_32768_4096)

Diese Meldung besagt das es vom jeweiligen DNS Server erst eine Antwort gegeben hat, nachdem die UDP Größe verringert wurde. Dieses fällt einem im normalen Tests mit dig / drill oder ähnlichem nicht wirklich auf. Denn hier wird absolut automatisch die Paketgröße weiter verringert bis es klappt. Es „dauert“ nur etwas länger….

Der DNS-Server, in diesem Fall ein bind9.11, versucht auf die Frage mit einem IPv6 UDP Paket zu Antworten und schickt dieses mit 4096 Byte raus. Aus irgendeinem Grund (Firewall, Einstellungen im OS, Filter auf dem Netzwerk….) wird dieses Paket auf seinem Weg aber verworfen und erreicht sein Ziel nicht. Da wir hier über UDP sprechen merkt das der Server nicht und glaubt er habe seinen Job gut gemacht. Woher soll bind auch wissen das sein Paket nicht angekommen ist oder irgendwas auf dem Weg sein Pakete mit dieser Größe nicht mag?

Um als Admins herauszufinden wie groß die Pakete von seinem System denn werden können kann man folgenden einfachen Test nutzen:

$ dig +short rs.dns-oarc.net txt
rst.x490.rs.dns-oarc.net.
rst.x499.x490.rs.dns-oarc.net.
rst.x457.x499.x490.rs.dns-oarc.net.
"2001:310:6000:f::1fc7:1 sent EDNS buffer size 512"
"Tested at 2017-07-05 08:23:52 UTC"
"2001:310:6000:f::1fc7:1 DNS reply size limit is at least 499"

Wie zu erkennen ist endet es auf diesem System bei 512 Byte. Wenn wir uns jetzt nicht weiter um den Grund kümmern wollen oder können, müssten wir also unserem bind sagen das er bitte immer nur mit maximal 512 Byte arbeitet, wenn er UDP nutzt. Dieses geht wie folgt im Options Block:

options {
	[....]
	edns-udp-size 512;
	max-udp-size 512;
	[....]
};

edns-upd-size ist hier für das Empfangen und max-udp-size für das Senden von Paketen. Ab dem Moment probiert es bind nur noch mit 512 Byte und die Clients werde auf ihre erste Frage hin direkt eine Antwort bekommen, ohne die Frage so oft wiederholen zu müssen, bis sie schrittweise zurück auf 512 Byte sind.

So long…

Brute-Force Angriffe auf Joomla

10. April 2017 / / Keine Kommentare

Sobald man einen standard Dienst im Netz stehen hat wird dieser auch von verschiedenen Bots abgegrabbelt. Diese testen nach ungepatchten Versionen mit nutzbaren Sicherheitslöchern oder gehen Rainbow Tables durch. Gegen Sicherheitslöcher hilft ein Patchmanagement gegen Rainbow Tables helfen gute Kennwörter und ein Schutz gegen Brute-Force…. Einfach ist hier zum Beispiel der fail2ban Ansatz. Einfach mit zählen wie viele Fehlerhafte Logins in einem gewissen Zeitraum von einer IP-Adresse kommen und dann direkt die IP-Adresse für einen gewissen Zeitraum sperren.

Jetzt sind die Entwickler der Bots nicht dumm… Zuerst haben diese Bots genau so angefangen. Erstmal alle möglichen Kennwörter durchprobieren. Als ersten Schutz natürlich fail2ban, dann haben die Bots angefangen nicht mehr als genau drei Anfragen von einer IP Adresse zu stellen, etwas warten und dann wieder drei Anfragen. Man musste also im fail2ban „nachstellen“. Nun sind wir schon beim Punkt das diese Anfragen nicht mehr gebündelt als Dreierblock kommen sondern immer nur eine Anfrage von einer Adresse und 2 – 3 Stunden später erst wieder von dieser Adresse. Der einzelne Bot würde also Jahrzehnte brauchen um einige Versuche durch zugehen! Wenn er sich mit vielen anderen Abspricht, werden in kurzer Zeit noch immer sehr viele Kombinationen durchprobiert. Also wieder nachrüsten… Zwei Faktor, „Lebenderkennung“, Zertifikatslogin usw… Damit hat man sicher erst mal etwas Ruhe. OK, hier gibt es ebenfalls Möglichkeiten nur gibt es sicher genug schlechter gesicherte Ziele die zuerst angegangen werden können!

Neues S/MIME Zertifikat

31. März 2017 / / Keine Kommentare

Wie angekündigt habe ich nun ein neues S/MIME Zertifikat. 

SHA1: 0C B9 00 A9 C7 C9 EF B0 15 57 4F E0 1F D8 57 BD B6 31 CC BD

Ganz brav habe ich direkt SMIMEA mit dem Zertifikat zusammen in Aktion versetzt. Es ist zwar noch ein draft aber man kann es ja mal probieren:

https://tools.ietf.org/wg/dane/draft-ietf-dane-smime/

Jetzt könnte ich also auch mal Dinge wie smilla: https://github.com/sys4/smilla oder https://github.com/letoams/openpgpkey-milter angehen, oder?

In diesem Sinne!

GlobalSign S/MIME und so…

31. März 2017 / / Keine Kommentare

Nach dem „tot“ von StartSSL brauche ich ja auch mal ein neues S/MIME Zertifikat. Class 2 bei GlobalSign sollte für mich privat reichen (auch wenn ich schon auf Class 3 geschielt habe, mal sehen ob ich das noch nachziehe). Als erstes habe ich da trocken angerufen und gefragt ob ich auf sie bauen kann oder mich am Ende so ärgere wie über StartSSL / Symantec usw… Klar es ist eine große CA die zu viel Geld für Mist bekommen und der Anruf war total nutzlos. Er hat dennoch für Spaß bei mir und da bin ich mir sicher, ebenfalls bei GlobalSign geführt 🙂

Nun klicke ich mich also gerade durch die Anmeldung und muss alle möglichen Daten eingeben sowie Vereinbarungen zustimmen usw. an einer Stelle soll ich dann schon mal mein Kennwort für die Zertifikatsverwaltung festlegen. Ich überzeuge also wie immer pwgen mir eines zu würfeln werfe es rein. Die Info unter dem Kennwortformular lese ich natürlich nicht und bekomme direkt die Quittung. Ich habe unerlaubte Sonderzeichen in meinem Passwort für die Zertifikatsverwaltung angegeben. Unerlaubte Sonderzeichen?!?!? Stimmt… Die Kennwörter dürfen nur aus Zahlen und Buchstaben (groß/klein) bestehen. O_o

Das Kennwort für die Zertifikatsverwaltung darf also keine Sonderzeichen enthalten. Den Satz habe ich jetzt schon ein paar mal gesagt aber öhm ich begreife ihn irgendwie noch nicht. *kopfschüttel* Kann mir das bitte mal jemand verständlich machen? Am besten ich ruf da noch mal an, oder?

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑