[nginx] ssl Zertifikat einrichten

Für die sichere Kommunikation zwischen nginx Server und Browser empfiehlt es sich wie beim Apache ein SSL Zertifikat zu verwenden.

Damit nach der erfolgreichen Einrichtung ein Aufruf per https erfolgen kann, muss zunächst der Port 443 in der firewall freigeschaltet werden.
firewall-cmd --permanent --zone=public --add-service=https
firewall-cmd --reload

Hier die benötigten Schritte um ein SSL Zertifikat zu erstellen:
yum install mod_ssl openssl
cd /etc/ssl
openssl genrsa -out seite2.key 2048
openssl req -new -key seite2.key -out seite2.csr
openssl x509 -req -days 365 -in seite2.csr -signkey seite2.key -out seite2.crt

Für den SSL Server block wurde die Datei /etc/nginx/conf.d/seite2.conf nach /etc/nginx/conf.d/ssl-seite2.conf kopiert.

Aufbau ssl-seite2.conf
server {
listen 443;
ssl on;
ssl_certificate /etc/ssl/seite2.crt;
ssl_certificate_key /etc/ssl/seite2.key;

index index.html;

server_name www.seite2.de;
access_log /var/vhosts/seite2/logs/ssl-seite2.access.log main;
error_log /var/vhosts/seite2/logs/ssl-seite2.error.log;

root /var/vhosts/seite2/www;
}

Damit der Besucher der Seite beim http Aufruf auf https weitergeleitet wird, wurden folgende Zeilen in der /etc/nginx/conf.d/seite2.conf hinterlegt:

if ($scheme = http) {
return 301 https://$server_name$request_uri;
}

Flattr this!

Outlook und smime – Der Name Ihrer digitalen ID kann im zugrunde liegenden Sicherheitssystem nicht gefunden werden.

Ein Kollege arbeitet in einem größeren metallverarbeitendem Betrieb und dort werden zum Teil interne sowie ausgehende E-Mails über SMIME verschlüsselt. Anfangs wurden selbst erstellte Zertifikate verwendet, was jedoch bei ausgehenden E-Mails bei externen Empfängern für Probleme sorgte. Gelegentlich kam es zu Problemen wenn intern verschlüsselte E-Mails versendet wurden.
Beim öffnen einer verschlüsselten E-Mail erhielt man die Fehlermeldung:
Der Name Ihrer digitalen ID kann im zugrunde liegenden Sicherheitssystem nicht gefunden werden.

Zunächst wurde vermutet das der Fehler in der Outlook SMIME Konfiguration lag, jedoch war auf Sender und Empfängerseite alles in Ordnung. Auch in den angelegten Outlookkontakten konnte kein Fehler gefunden werden.

Um festzustellen über welche Zertifikate die E-Mail verschlüsselt wurde wird das Programm MFCMAPI benötigt, welches hier heruntergeladen werden kann.
Nach dem herunterladen und starten des Programms muss das Postfach ausgewählt werden in dem sich die E-Mail befindet. Im Anschluss die E-Mail auswählen und im Kontextmenü(rechte Maustaste) das „Display Attachement Table“ öffnen. Die unter den Anhängen aufgeführte Datei smime.p7m auf zum Beispiel dem Desktop speichern.

Im letzten Schritt wird über die Kommandozeile das Programm certutil.exe (certutil.exe Pfad zur Datei) ausgeführt. Die für diesen Fall benötigten Informationen stehen in den letzten Zeilen der Ausgabe.
Recipient Info[0]:
CMSG_KEY_TRANS_RECIPIENT(1)
CERT_ID_ISSUER_SERIAL_NUMBER(1)
Serial Number: 028382882299292
Recipient Info[1]:
CMSG_KEY_TRANS_RECIPIENT(1)
CERT_ID_ISSUER_SERIAL_NUMBER(1)
Serial Number: 17363636181919

Für die Verschlüsselung der E-Mails wird ein Zertifikat des Senders und Eins des Empfängers benötigt. Eines der Zertifkate konnte anhand der Seriennummer beim Versender gefunden werden, jedoch befand sich das weitere Zertifkat nicht im Zertifikatsspeicher der Empfängers.

Ein Kollege gab den Hinweis das im Active Directory Zertifikate veröffentlicht werden konnten. Nachdem im Active Directory MMC die erweiterten Features aktiviert wurden, war ein Zugriff auf die veröffentlichten Zertifkate möglich. Unter den veröffentlichen Zertifikaten des Empfängers befand sich ein Zertifikat mit der zweiten Seriennnummer.

Nachdem das Zertifikat entfernt wurde, war ein empfangen von intern verschlüsselten E -Mails wieder möglich.

Flattr this!

Rechner langsam durch conhost.exe, cmd.exe und misexec.exe

Neulich rief mich ein Kollege an das sein Rechner sehr langsam und träge reagierte. Telefonisch erklärte ich ihm das er in den Taskmanager schauen soll, ob evtl ein Prozess die Hohe Last verursacht. Er sagte einen Prozess gibt es nicht jedoch mehrere conhost.exe, misexec.exe und vereinzelt notepad.exe und auch cmd.exe. Er brachte mir den Rechner vorbei und zuvor fand ich im Internet einen passenden Beitrag im Trojaner Board Forum. Ich lies auf dem betroffenem Rechner den adwCleaner und das Junkware Removal Tool laufen, diese fanden verwaiste Registry Einträge das Problem wurde dadurch nicht gelöst. Letztendlich fand das Programm Malwarebytes Anti-Malware die Verursacher des Problems. Die Software entfernte den Trojan.Bedep und Trojan.Clicker.PMS im Anschluss nach einem Neustart sind die Probleme nicht mehr aufgetreten.

Flattr this!

[nginx] und php

Für viele Webseiten oder Anwendungen wie WordPress, Joomla sowie Contao wird php benötigt. Von Haus aus kann nginx nur html oder Bilddateien ausgeben, damit php Seiten dargestellt werden wird php-fpm benötigt.

Zunächst wird php-fpm unter dem root Benutzer installiert:
yum install php-fpm

Nach der Installation habe ich in der /etc/php.ini folgende Anpassung vorgenommen:
cgi.fix_pathinfo=0

Für die php Konfiguration der www.seite1.de wurde die Datei /etc/php-fpm.d/seite1.conf angelegt.

[seite1]
listen = /var/run/php-fpm/seite1.sock
listen.owner = nginx
listen.group = nginx
listen.mode = 0660
user = seite1
group = seite1
pm = dynamic
pm.max_children = 10
pm.start_servers = 1
pm.min_spare_servers = 1
pm.max_spare_servers = 3
pm.max_requests = 500
chdir = /var/vhost/seite1/www/
php_admin_value[open_basedir] = /var/vhosts/seite1/www:/var/vhosts/seite1/temp
php_admin_value[upload_tmp_dir] = /var/vhosts/seite1/temp

Zum Schluss die folgenden Zeilen dem Server-Block in der Datei /etc/nginx/conf.d/seite1.conf hinzufügen.
location ~ \.php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_index index.php;
fastcgi_pass unix:/var/run/php-fpm/seite1.sock;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
include fastcgi_params;
}

Gestartet wird php-fpm über systemctl start php-fpm.service bzw über systemctl stop php-fpm.service gestoppt.

Flattr this!

[nginx] einrichten von vhosts

Wie beim Apache Webserver ist es auch unter nginx möglich verschiedene virtuelle hosts einzurichten. Bei nginx werden diese jedoch nicht als virtuelle hosts bezeichnet sondern als server blocks.

Damit die Seiten unter verschiedenen Benutzern bearbeitet werden können, habe ich zunächst einen Benutzer angelegt adduser seite1 /var/vhosts/seite1. Unter dem Benutzer seite1 wurden die Verzeichnisse logs und www angelegt, im Anschluss müssen noch die Rechte der Verzeichnisse angepasst werden.

chmod 755 /var/vhosts/seite1
chmod 755 /var/vhosts/seite1/www
chmod 760 /var/vhosts/seite1/logs

Damit der nginx die log Dateien in dem angegeben Verzeichnis erstellen kann muss der nginx Benutzer der Gruppe seite1 hinzugefügt werden.

Die Konfiguration des Vhosts wurde in der Datei /etc/nginx/conf.d/seite1.conf erstellt.

server {
index index.html;

server_name www.seite1.de;
access_log /var/vhosts/seite1/logs/seite1.access.log main;
error_log /var/vhosts/seite1/logs/seite1.error.log;

root /var/vhosts/seite1/www;
}

Wenn bei auftretenden Fehlern zum Beispiel die eigene 404 Seite angezeigt werden soll, reicht der folgende Eintrag in der Konfiguration.

error_page 404 errors/404.html;

Flattr this!