Kurs2: Projekt IT-Security Top-Page
2.x Sichere Kommunikation per SSL

Apache als Secure-Server (Sequenzdoku 10.x)
2.1
  • Spreche den Host "Server" über eine SSL-Verbindung an.
    Die Voraussetzungen und der (dann mögliche) https-Verbindungsaufbau siehe folgende Grafik:
    - https://www.softed.de/blog/wie-funktioniert-https/
    Informationen über X509-V3 Zertifikate -> https://httpd.apache.org/docs/2.4/ssl/ssl_intro.html#table1.
    - Welche Informationen enthält das gelieferte Zertifikat (über den angesprochenen Host)?
       Achte auf den doppelt vorhandenen "Distinguished-Name" Eintrag,
       im Subject(Gegenstand) und Issuer(Aussteller) Bereich.
    - Welche "Distinguished Name" Informationen können von Browser überprüft werden?
    - Gibt es Gründe dem vorgelegtem Zertifikat nicht zu vertrauen?
    - Über welche Zertifikatsmängel kann/muss der Browser informieren?
    - Wie sicher ist die Kommunikation bei einem "Brute-Force-Angriff"?
       http://www.tcp-ip-info.de/security/key_length.htm (Aufwand für einen "Brute-Force-Angriff")
       http://www.heise.de/-3221002 (Kryptographie in der IT - Empfehlungen zu Verschlüsselung)
  • Erzeuge ein X.509-V3 Server-Zertifikat
    - Die Zertifikate können über Scripte (wie gensslcert) erzeugt werden.
      Kontrolliere zuvor, ob der FQDN ihres Systems als CN-Eintrag dienen kann (hostname -f).
  • Lade eine ssl-Vorlagendateien (mit VirtualHost Container für Port 443) in deine Konfiguration (z.B. /etc/apache2/vhosts.d/vhost-ssl.template).
    - Kontrolliere ob die SSLCertificate*File-Angaben auf die erzeugten Dateien verweisen.
    Der Apache kann SSL-Verbindungen mittels GnuTLS oder OpenSSL (mehr Features) realisieren.
    LoadModule ssl_module /usr/lib64/apache2-prefork/mod_ssl.so
    Listen 443
    <VirtualHost _default_:443>
            SSLEngine on
            SSLCertificateFile /etc/apache2/ssl.crt/FQDN-server.crt
            SSLCertificateKeyFile /etc/apache2/ssl.key/FQDN-server.key  
    </VirtualHost>
    - Wo erwartet der Apache die Zertifikatsdateien?
    - Aktiviere <IfDefine SSL> über APACHE_SERVER_FLAGS="-D SSL" in der /etc/sysconfig/apache2
    - Falls der eigenen http://localhost/FQDN-CA.crt vertraut wird sollte ein https-Zugriff (ohne Warnung) möglich sein.
  • Mit Besitz einer CertificateSigningRequest-Datei kann nun ein vertrauenswürdiges Zertifikat beantragt werden. Vertrauenswürdige Signaturen kosten (klassenabhängig) z.B. 180€/Jahr.
    Die Zertifikatsklassen unterscheiden sich nach der Stärke der Identitätsprüfung
    Klasse 1: Hier wird nur die email Adresse (z.B. webmaster@domain.de) geprüft.
    Klasse 2: Hier wird außer email noch Telefonnummer, Ort und Straße auf Existenz geprüft.
    Klasse 3: Hier ist ein persönliches erscheinen (Ausweiskontrolle) oder ein glaubwürdiger Vertreter (z.B. Notar) nötig.
    Oder mit reduzierter Gültigkeitsdauer (WISeKey, Comodo, Secorio, GlobalSign, Symantec/Verisign)
    - http://de.wikipedia.org/wiki/S/MIME#Kostenlose_Zertifikate
    - https://www.psw.net/ssl-zertifikate.cfm (Übersicht verschiedener Anbieter)
    - https://letsencrypt.org/ (bietet automatisierten Prozess für kostenlose X.509-Zertifikate)
    Das Let's-Encrypt-Tool "certbot" kontaktiert die CA, fordert ein Zertifikat an, beweist den Domainbesitzt, holt das (90 Tage gültige) Zertifikat und konfiguriert den Server für SSL. Die lokale Dokumentation (aus dem Paket certbot-doc) ist über file:///usr/share/doc/packages/certbot-doc/html/certbot/index.html erreichbar.
  • Die beglaubigten Zertifikate werden in einer LDAP/OCSP-Datenbank veröffentlicht
    - https://www.globaltrustpoint.com/ (TC unabhängige Metasuche für X.509 Zertifikatsketten)
    - https://www.certbox.org/

  • Kontrolliere die lokalen Zertifikatsdateien mit "openssl ... " (siehe README im Zertifikats-Verzeichnis), gcr-viewer oder kleopatra bzw. remote über -> openssl s_client -connect localhost:443 -showcerts -ign_eof -crlf (oder sslscan, gnutls-cli )


Zertifikatserstellung (Die eigene Certificate Authority)
2.2
  • Erzeuge nun über deine eigene CA die benötigten Server-Zertifikate (PKI).
    - unter Verwendung von openssl (xca oder dem Yast2-CA-Management)
    - Unter welchen Bedingungen akzeptiert ein Browser, Mailclient usw. die erzeugten Zertifikate?
    #---> CA-Zertifikats Erzeugung
    
    openssl genrsa -aes256 -out ca.key 4096
    ODER: openssl ecparam -genkey -name prime256v1 -out ca.key #openssl ecparam -list_curves
          openssl ec -aes-128-cbc -in ca.key -out ca.key       #ca.key mit Passphrase versehen
    
    openssl req -new -x509 -days 3650 -key ca.key -out ca.crt -extensions v3_ca #[-extfile ca.ext] [-config ca.config]
    #---> Server-Zertifikats Erzeugung
    openssl genrsa -out server.key 2048
    
    openssl req -new -key server.key -out server.csr -extensions v3_req \ [ -subj "/C=DE/ST=NRW/O=Siemens-AG/CN=www.example.com" \ -reqexts SAN \ -config <(cat /etc/ssl/openssl.cnf; \ printf "\n[SAN]\nsubjectAltName=DNS:example.com,DNS:www.example.com") ]
    openssl x509 -req -in server.csr -out server.crt -CA ca.crt \ -CAkey ca.key -days 730 -extensions server_cert #Beim 1. Aufruf erzeugt -CAcreateserial die Seriennummerndatei ca.srl #[-extfile server.ext] anstelle der -extensions ... Angaben (Beispiel folgt)
      Beispiel einer server.ext Datei
    extensions = x509v3
    [ x509v3 ]
    basicConstraints = CA:false
    nsCertType       = server
    keyUsage         = digitalSignature,nonRepudiation,keyEncipherment
    extendedKeyUsage = msSGC,nsSGC,serverAuth
    subjectAltName   = DNS:example.com,IP:1.2.3.4,DNS:www.example.com


Zwei-Faktor-Authentisierung (mit x509-V3 Clientzertifikat)
2.3
  • Nun soll "auch" der Server für den Zugriff auf https://localhost/~skurs/sub4/ die Vorlage eines Client(Mail)-Zertifikates verlangen (Direktiven siehe: https://httpd.apache.org/docs/2.4/ssl/ssl_howto.html#allclients)
    - https://httpd.apache.org/docs/2.4/ssl/ssl_intro.html#session (Verbindungsaufbau mit Clientzertifikatsauthentifikation)
    - http://upload.wikimedia.org/wikipedia/commons/a/ae/SSL_handshake_with_two_way_authentication_with_certificates.svg
    #---> Client-Zertifikats Erzeugung
    # Wiederhole die Befehle der "Zertifikats Erzeugung" für die client.key, .csr und .crt-Datei
    
    openssl genrsa -out client.key 2048
    
    openssl req -new -key client.key -out client.csr -extensions v3_req #[-config .client.config]
    openssl x509 -req -in client.csr -out client.crt -CA ca.crt -CAkey ca.key \ -days 365 -extensions client_cert -addtrust clientAuth -addtrust emailProtection # [-extfile client.ext]
    cat client.key client.crt | openssl pkcs12 -export -out client.p12
      Beispiel: client.ext Datei siehe [client_ext|cliserv_ext|email_ext|emailcli_ext] in http://www.vectorcomms.com/additional-files/openssl.cnf.txt
    extensions = x509v3
    [ x509v3 ]
    nsCertType = client, email, objsign
    keyUsage   = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
    extendedKeyUsage = emailProtection, clientAuth
    Importiere die client.p12 (nicht client.crt) Datei in deinen verwendeten Browser/Mailclient

  • Akzeptiere (beim Zugriff auf den sub4-Ordner) mit SSLVerifyClient zunächst alle Client-Zertifikate des eigenen Trustcenters. Verwende dazu die Direktive SSLCACertificateFile oder SSLCACertificatePath im Port-443-Vhost-Container. Optional darf die Signatur auch von anderen vertrauenswürdigen Trustcentern stammen. Eine Trustcenter Sammlung befindet sich unter /etc/ssl/ (in der Datei ca-bundle.pem oder im Unterordner certs/)
    Teste den Zugriff mit (oder wie folgt ohne) Browser:
    printf 'GET /~skurs/sub4/ HTTP/1.0\r\n\r\n' | \
     openssl s_client -connect localhost:443 -cert client.crt -key client.key -ign_eof 
    - Warum sollte zusätzlich eine zwangsweise Umschaltung auf https stattfinden?
    Hinweise: SSLRequireSSL, mod_rewrite, https://wiki.apache.org/httpd/RewriteHTTPToHTTPS
  • Erlaube mit der Direktive SSLRequire/Require expr (durch Auswertung der SSL_Umgebungsvarialen) den Zugriff nur mit bestimmten CN-Einträgen
    - Die Umgebungsvariable SSL_CLIENT_S_DN_CN wird dazu mit "Vor- Nachname" verglichen.
    - https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#envvars (eine Liste der SSL_Umgebungsvarialen)

    Da Trustcenter (auch Siemens) die signierten Client/Mail-Zertifikate in einer LDAP-Datenbank (ldap://al.siemens.net/ oder ldap://dir.bridge-ca.de/) veröffentlichen, kann ein Zertifikat dagegen validiert oder zuvor geladen und eingesehen werden.
    Optionale auch über folgende Webformulare
    - http://ebca.de/, https://www.certbox.org/search/basic/
    - https://www.globaltrustpoint.com/ (mit Zertifikatskette)

  • Falls sich die PKCS12-Datei auf einer Smartcard o. einem USB-Token befindet?
    1. Der Client verfügt über ein Lesegerät und einen aktiven PC/SC-Smart-Card-Daemon (pcscd)
       Hinweis: "pcscd -d -f" zeigt bei eingelegtem Ausweis eine "Card ATR: ..." Zeile
    2. Der Browser hat ein (zur verwendeten Smart-Card kompatibles) PKCS11-Modul geladen
       (onepin-opensc-pkcs11.so oder opensc-pkcs11.so)
       Im Firefox über die Kryptographie-Modul-Verwaltung ladbar und
       für den GoogleChrome in der Datei ~/.pki/nssdb/pkcs11.txt (library=... name=cardos)
    3. Der Browser hat das Trustcenter in seiner (vertrauenswürdigen) CA-Liste
       Hinweis: Im Client-Zertifikat wird häufig eine CA-Aussteller:URI angegeben (ca.crt)
    4. Auch der Webserver findet den public-CA-Key in seinem SSLCACertificateFile ...
    5. Die Authentifikationskonfiguration im Apache bleibt wie zuvor (SSLVerifyClient require)

(sicherer) Schreibender Zugriff auf Websites
2.4
  • Richte für die Kunden1-4 zusätzlich namens-basierte virtuellen-Hosts für Port 443 (https://www.kunde1.de) ein.
    <VirtualHost *:443>
     DocumentRoot /srv/www/user1
     ServerName www.kunde1.de
      SSLEngine on
      SSLCertificateFile /etc/apache2/ssl.crt/www.kunde1.de-server.crt
      SSLCertificateKeyFile /etc/apache2/ssl.key/www.kunde1.de-server.key
    </VirtualHost>
    - Optional kann dazu die Vorlage ftp://server/kurs/vhost-ssl-muster/ verwendet werden
    - Kontrolliere die Websites auf Server Name Indication Kompatibilität
  • Optional:
    Realisiere für die Kunden einen verschlüsselten Schreib-Zugang durch webdavs oder ftps.
    - Teste den Webdav[s]-Zugriff mit "mount -t davfs http[s]://localhost/davfs/ /mnt" (oder im konqueror, IExplorer ...)
    - Ein erstes Manual-Webdav-Konfigurations Beispiel (https://httpd.apache.org/docs/2.4/mod/mod_dav.html#example)
      PS: Die Dav und AuthDigestProvider-Direktiven benötigen zusätzliche Module
      PS: Stören Homepages, sollten diese (für Webdav-Zugriffe) abgeschaltet werden
    DavLockDB /usr/local/apache2/var/DavLock
    <Directory /usr/local/apache2/htdocs/foo>
    #---Require all granted #deaktivierte die folgende Passwortabfrage
        Dav On
        AuthType Basic
        AuthName DAV
        AuthUserFile user.passwd
        <LimitExcept GET POST OPTIONS>
            Require user admin
        </LimitExcept>
    </Directory>
    - Ein Beispiel aus der Doku (/usr/share/doc/packages/apache2/original/extra/httpd-dav.conf)
    DavLockDB "/srv/www/var/DavLock"
    Alias /uploads "/srv/www/uploads"
    <Directory "/srv/www/uploads">
        Dav On
        AuthType Digest
        AuthName DAV-upload
        AuthUserFile "/srv/www/user.passwd"
        AuthDigestProvider file
        <RequireAny>
            Require method GET POST OPTIONS
            Require user admin
        </RequireAny>
    </Directory>
    - Teste den ftps-Zugriff vom Linux/Windows Client aus (filezilla, fireftp)
      Es folgt eine mögliche Ergänzung der /etc/vsftpd.conf
    ssl_enable=YES
    #---> vsftps.pem mit key/crt-Daten ODER: 2 Einzelzertifikatsdateien
    #rsa_cert_file=/etc/apache2/ssl.key/vsftps.pem
    rsa_cert_file=/etc/apache2/ssl.crt/server.crt
    rsa_private_key_file=/etc/apache2/ssl.key/server.key
    ssl_sslv2=NO
    ssl_sslv3=NO
    ssl_tlsv1=YES
    ssl_ciphers=HIGH
    #---> Folgezeile für FireFTP
    require_ssl_reuse=NO
    #---------Folgezeilen für Zugriff auch ohne SSL
    force_local_data_ssl=NO
    force_local_logins_ssl=NO
    

Meinlf Mühlenjost 2022