Webfonts in CDN ablegen (Access-Control-Allow-Origin)

Ich verwende gern die Webfonts Font Awesome um meine Projekte ein wenig zu verschönern. Das Projekt bietet neben einem CDN auch die Möglichkeit die Projektdateien herunterzuladen. Kurz den Pfad zu den Fonts anpassen und schon kann es losgehen.

Bei Absoluten Pfaden hat man aber schnell das Problem, das beim Ablegen der Fonts im CDN (oder unter einer Subdomain für statische Inhalte) der Browser das Laden aufgrund des fehlenden Access-Control-Allow-Origin Header blockt.

Um den Zugriff nun auch von anderen Domains aus zu erlauben, z.B. einer lokalen Testumgebung, kann bei einem Apache die Site-Konfiguration oder eine .htaccess Datei genutzt werden.

Ich habe dazu einfach die folgende Zeilen in die .htaccess geschrieben.

<IfModule mod_headers.c>
    <FilesMatch "\.(ttf|ttc|otf|eot|svg|woff)$">
       Header set Access-Control-Allow-Origin "*"
    </FilesMatch>
</IfModule>

Hinweis: Beim Apache muss das Modul headers aktiviert sein. Unter Ubuntu funktioniert das wie folgt.

$ sudo a2enmod headers
$ sudo service apache2 restart

Bei der Verwendung eines NGINX einfach die folgenden Zeilen in die Konfigurationsdatei einfügen.

if ($filename ~* ^.*?\.(ttf)|(ttc)|(otf)|(eot)|(svg)|(woff)$){
	add_header Access-Control-Allow-Origin *;
}

Gruppieren und zählen von IP Adressen in der access.log

Manchmal will man als Administrator/Webmaster wissen, von welchen IP Adressen auf den Webserver zugegriffen wird. Ein sehr schneller weg um das herauszufinden geht über die access.log.

Der folgende Befehl liefert die Anzahl aller IP Adressen in der access.log.

$ pcregrep -o ‚^[0-9.]+(?=\s)‘ /var/log/apache2/access.log | sort | uniq -c | sort -bg

Das Egebnis sieht in etwa so aus. (Die Anzahl der Einträge gefolgt von der IP)

   5 84.159.***.***
  39 216.67.***.***
  41 81.16.***.***
  90 10.100.100.123
 919 10.100.100.36
1880 10.100.100.56
2613 10.100.100.56

Hinweis: Die öffentlichen IP Adressen dieses Beispiels eines Testservers wurden mit Sternchen unkenntlich gemacht.

Sollte pcregrep nicht installiert sein, kann man es wie folgt installieren.

$ sudo apt-get install pcregrep

CSR für Zertifikatsanfrage erstellen

Damin man ein SSL Zertifikat bei einer CA (Certification Authority) beantragen kann, benötigt man einen CSR (Certificate Signing Request). Diesen erstelle ich immer auf der Maschine auf der später das SSL Zertifikat eingesetzt werden soll.

Ausgangspunkt für einen CSR ist ein privater Schlüssel. Sollte dieser nicht vorhanden sein, kann er mit folgendem Befehl erstellt werden.

$ openssl genrsa -out domainname.de.key 4096

Jetzt kann mit Hilfe des privaten Schlüssels der CSR erzeugt werden.

$ openssl req -new -key domainname.de.key -out domainname.de.csr

Im folgenden werden ein paar informationen abgefragt:

Country Name (2 letter code) [AU]: DE
State or Province Name (full name) [Some-State]: Berlin
Locality Name (eg, city) []: Berlin
Organization Name (eg, company) [Internet Widgits Pty Ltd]: Firmenname GmbH
Organizational Unit Name (eg, section) []:  
Common Name (eg, YOUR name) []: www.domainname.de
Email Address []: webmaster@domainname.de

Bei Bedarf kann man den CSR noch einmal testen:

$ openssl req -noout -text -in domainname.de.csr

Der erstellte CSR kann jetzt beim Zertifikatsausteller eingereicht werden.

Poodle Angriff – SSLv3 im Apache deaktivieren

Vor der kürzlich aufgetauchten „Poodle Attacke“ kann man sich relativ einfach schützen. Denn dieser Angriff auf die Internet-Verschlüsselung kommt über die veraltete Protokollversion SSLv3.

Um den Apache gegen Poodle fit zu machen, muss die SSL Konfiguration verändert werden. Im Beispiel in der Site default-ssl.

$ sudo nano /etc/apache2/sites-available/default-ssl

Die folgende Zeile hinzufügen bzw. auf folgendes ändern.

SSLProtocol All -SSLv2 -SSLv3

Im Anschluß den Server neu starten.

$ sudo service apache2 restart

Testen kann man das Ergebnis auf der Seite von Qualys SSL Labs

Server Signatur des Apache Webserver deaktivieren

Bei einer unveränderten Standardinstallation des Apache2 Webserver wird bei der Ausgabe einer Apache Fehlerseite immer auch eine Signatur angezeigt. Die in der Signatur enthaltenen Informationen können einem potentiellen Angreifer nützliche Informationen zur eingesetzten Webserver Version und dem OS preisgeben.
403 Fehlerseite mit Signatur
Diese Informationen sollte möglichst auch deaktiviert werden. Hierzu muss die Datei apache2.conf bearbeitet werden.

$ sudo nano /etc/apache2/apache2.conf

Folgende Werte hinzufügen bzw. ändern:

ServerSignature Off
ServerTokens Prod

Im Anschluss den Server neu starten, damit die Änderungen aktiv werden.

$ sudo service apache restart

Jetzt sollte auf den Fehlerseiten des Apache keine Signatur mehr angezeigt werden.
403 Fehlerseite ohne Signatur

Weitere Informationen zu den Parametern:
Informationen zur ServerSignature.
Informationen zur ServerTokens.