Kategorien
IPTables Linux security

Wie verheimliche ich zusätzliche Router

Internetanbieter können feststellen wie viele Router Du betreibst, nicht das das irgend jemanden außer dich selbst etwas angehen würde.

Wie stellen Internetanbieter einen Router fest? an dem TTL (Time to Live) der TCP-Pakete Die du an sie weiter gibst.

Die TTL Kannst Du in einem vernünftigen* Router jedoch ändern.

Setze in der Firewall für das POSTROUTING einfach eine neue TTL.:

iptables -t mangle -I POSTROUTING 1 -j TTL --ttl-set 64

Die TTL von 64 wird von Unix Geräten, wie zum Beispiel Android Telefonen verwendet. Wenn Alle Pakete als direkt von einem Windows Gerät stammend wirken sollen wäre der richtige Wert 128.

Kategorien
Linux Postfix

EMail Datenschutz – Mail Header filtern

Vor einigen Tagen fiel mir bei der Untersuchung  des, auch an dieser Stelle behandelten, TLS-Fehlers auf, das die E-Mail Header aller über meinen Server vesandten EMails die folgenden beiden Header-Zeilen enthalten.:

Received: from [192.168.*.*] (ip********.dynamic.kabel-deutschland.de [95.91.*.*])
by server.angststalt.de (Postfix) with ESMTPSA id A64D13FCE1
for <*****@*****.de>; Mon, 26 Mar 2018 21:46:44 +0200 (CEST)
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.6.0

Ich bin mir, mit Blick auf den 25. Mai 2018 nicht sicher ob eine EMail diese zusätzlichen, nicht für die Erfüllung des Dienstes erforderlichen, Metadaten weiterhin beinhalten darf.
(Lieber Leser, liebe Leserin, wenn Du eine Online-Rechtsberatung erteilen darfst und dich mit der EU-Datenschutz-Grundverordnung auskennst, würde ich mich über einen Kommentar ↓ von Dir sehr freuen!)

Da ich es persönlich nicht mag wenn Daten versteckt vorliegen (in diesem Fall im EMail-Header) die nicht benötigt werden aber dritten unter bestimmten Umstenden helfen können mir zu schaden habe ich mich für die Entfernung der Header-Zeilen entschieden. Auch ein Blick in die RFC5321, und einige eigene Tests, zeigen das diese beiden Header-Zeilen nicht für die Zustellung verwendet werden und somit die Entfernung nicht schadet.

Vorgehen:

1.) Den EMail-Server Prüfen

Mit dem Postfix-Konfigurationsparameter header_checks kann ich die EMails am einen PCRE Filter weitergeben und verändern lassen.
Mit dem Postfix-Konfigurationsparameter smtpd_sasl_authenticated_header Erweitere ich den EMail-Header um einen Eintrag über den zur Authentifizierung am EMail-Server genutzten Benutzernamen.

postconf -n header_checks 2>/dev/null
postconf -n smtpd_sasl_authenticated_header 2>/dev/null

Ich bekomme für beide Konfigurationen eine leere Antwort, daher schaue ich nach den Defaultwerten.:

postconf -d header_checks 2>/dev/null
header_checks =
postconf -d smtpd_sasl_authenticated_header 2>/dev/null
smtpd_sasl_authenticated_header = no

2.) EMail-Server Konfiguration anpassen

Da ich vor habe den Filter über PCRE umzusetzen benötige ich das Debian Paket postfix-pcre, welches die Unterstützung dür die gewünschten Perl Regular Expressions für Postfix mitbringt.:

sudo apt install postfix-pcre
The following NEW packages will be installed:
postfix-pcre
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 320 kB of archives.
After this operation, 373 kB of additional disk space will be used.

Nach dem das Paket installiert ist lege ich auf dem Server eine Datei mit dem Namen „header_checks“, im Postfix Verzeichnis, an. In dieser Datei werden die Filterregeln hinterlegt.:
sudo vi /etc/postfix/header_checks

/^Received: .*\(Authenticated sender:.*/ IGNORE
/^Received: by server\.angststalt\.de .*from userid [0-9]+\)/ IGNORE
/^User-Agent:/ IGNORE

Im Anchluss verlange ich vom Postfix dem Benutzernamen, der zur Anmeldung am EMail-Server verwendet wurde in die Header einzufügen und die Mail Header über meinen Filter zu leiten.:

postconf -e smtpd_sasl_authenticated_header=yes
postconf -e header_checks=pcre:/etc/postfix/header_checks

Nach dem folgenden neustart von Postfix kann ich mir eine Testnachricht senden und die Header prüfen.

service postfix restart

Bei meinem Vergleich des neuen EMail-Headers mit dem EMail-Header einer älteren EMail, die ich mir vor der Einrichtung des Filters gesandt habe, fehlen die von mir zu begin beanstandeten Header Zeilen.

Kategorien
Linux Postfix

Korrektur für Postfix TLS-Fehler „untrusted issuer“

Ich konnte mal wieder, beim EMail-Versand von meinem EMail-Server (Postfix) zu GMX einmal wieder keine EMails zustellen. Aus der aktuellen Fehlermeldung, welche in der Mail Delivery Notification erwähnt wird, geht hervor das es einen Zertifikatsfehler gab.

In den Postfix Logfiles erscheint die TLS-Fehlermeldung „untrusted issuer“.:

Mar 27 16:05:12 server postfix/smtp[6752]: certificate verification failed for mx01.emig.gmx.net[212.227.17.5]:25: untrusted issuer /C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2
Mar 27 16:05:12 server postfix/smtp[6752]: A602E3FF5C: Server certificate not trusted
Mar 27 16:05:12 server postfix/smtp[6752]: certificate verification failed for mx00.emig.gmx.net[212.227.15.9]:25: untrusted issuer /C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2
Mar 27 16:05:12 server postfix/smtp[6752]: A602E3FF5C: to=<********@gmx.de>, relay=mx00.emig.gmx.net[212.227.15.9]:25, delay=1.2, delays=0.12/0.03/1/0, dsn=4.7.5, status=deferred (Server certificate not trusted)

Der Aussteller des Zertzifikats des GMX-EMail Servers war meinem Postfix nicht bekannt.
Das SSL-Zertifikat des GMX EMail Server ist mit dem von der „Deutsche Telekom Root CA 2“ signiert. War über eine Suche im Internet schnell gefunden. Die erste Zeile des Zertifikats ist in der Datei /etc/ssl/certs/ca-certificates.crt enthalten.

Die erste Zeile des Zertifikats der Telekom lautet.: MIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQGEwJERTEc

In meiner Suche konnte ich einfach feststellen das das CA-Zertifikat der Telekom ab der Zeile 1110 in der Datei ca-certificates.crt enthalten ist.:

~]> grep -n MIIDnzCCAoeg /etc/ssl/certs/ca-certificates.crt
1111:MIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQGEwJERTEc

Da in der CA-Datei auf meinem Server das Zertifikat enthalten ist prüfe ich gegen welche CA-Zertifikate Datei mein Postix die Zertifikate der Kommunikationspartner auf Gültigkeit zu prüfen:

postconf -n smtp_tls_CAfile 2>/dev/null
smtp_tls_CAfile =

Ich hatte also versäumt meinem Postfix die aktuell CA Zertifikate Datei bekanntzugeben.
Ich habe mit postconf den CAfile bekannt gegeben.

postconf -e smtp_tls_CAfile=/etc/ssl/certs/ca-certificates.crt

Und anschließend meinen MTA neu gestartet.

service postfix restart

Abschließend werden meine EMails endlich wieder ohne Fehlermeldung auch an den Mailserver von GMX zugestellt.

Mar 27 16:17:44 server spamd[1256]: prefork: child states: II
Mar 27 16:17:45 server postfix/smtp[7300]: 9ACD13FF62: to=<********@gmx.de>, relay=mx01.emig.gmx.net[212.227.17.5]:25, delay=1.2, delays=0.12/0.03/0.79/0.29, dsn=2.0.0, status=sent (250 Requested mail action okay, completed: id=1MvIfx-1ejZeK2V9d-00qsAg)
Mar 27 16:17:45 server postfix/qmgr[7226]: 9ACD13FF62: removed
Kategorien
CL-35B2 Linux

howto – Shellshock auf der NAS

Leider ist auch die Bash-Shell der NAS CL-35B2 vom shellshock betroffen.

Hier meine Anleitung, wie die Bash auf der NAS durch eine neue, selbst compilierte ersetzt werden kann

1.) Bash auf Shelshock Verwundbarkeit testen

curl -k https://shellshocker.net/shellshock_test.sh 2> /dev/null| bash 2> /dev/null

Sollte bei einem der Tests die Meldung „VULNERABLE“ erscheinen, sollte die „Bash“ mit dieser Anleitung aktualisiert werden.
Sollten alle Tests „not vulnerable“ ausgeben ist diese Anleitung nicht interessant für Sie.
Ein Mirror des Scriptes ist unter der URL http://dl.loteks.de/shellshock_test.sh zu finden.

1.) Build Umgebung erstellen

Leider enthält die NAS CL-35B2 keine installierte Build-Umgebung. Von den 195MB Speicherplatz sind nur noch ca 40 frei, der Speicherplatz auf der NAS ist einfach zu klein um GCC und make zu installieren.

Ich habe einen USB stick angeschlossen, der sich als /dev/sdc meldet. (herauszufinden via dmesg)
via cfdisk habe ich auf diesem USB Stick zwei Partitionen angelegt, zuerst eine ein Gigabyte Swap Partition und im Anschluss den Rest als Linux Partition.

Im Anschluss den swap Speicher Partitionieren und aktivieren:

mkswap /dev/sdc1
swapon /dev/sdc1

Das Dateisystem auf /dev/sdc2 erstellen und Das Laufwerk Mounten:

mkfs.ext2 /dev/sdc2
mount /dev/sdc2 /mnt

Anschließend die RPM Pakete der Verwendeten Linux Distribution herunterladen. Bei der Fantec CL-35B2 ist es leider noch Fedora ARM 12, welches ein wenig betagt ist. Ich habe unter http://dl.loteks.de/fedora12arm_rpms.tar.gz (größe 119 MB) ein Paket mit den, für das Compilieren der Bash notwendigen rpm-Paketen abgelegt.

mkdir -pv /mnt/{chroot,rpm}
cd /mnt/
wget http://dl.loteks.de/fedora12arm_rpms.tar.gz
tar xzf fedora12arm_rpms.tar.gz
rpm --install --nodeps --root=/mnt/chroot/ rpm/*.rpm

Nach dieser, sehr sehr lange dauernden Installation (dies dauert auf der NAS mehrere Stunden!) befindet sich die chroot umgebung im Order /mnt/chroot

2.) Bash Quellen bereitstellen

Jetzt brauchen wir die Bash Quellen und Patches in der chroot-Ubgebung:

mkdir -pv /mnt/chroot/usr/src/bash
cd /mnt/chroot/usr/src/bash
wget ftp://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
tar xzf bash-4.3.tar.gz
wget ftp://ftp.gnu.org/gnu/bash/bash-4.3-patches/ -m -nd
chroot /mnt/chroot/
cd /usr/src/bash/bash-4.3 
for file in ../bash43-0[0-9][0-9] ; do patch -p0 < $file; done

Ab diesem Punkt liegen die Quellen der Bash gepatched im Verzeichnis /mnt/chroot/usr/src/bash-4.3. Das herunter geladene sstrip.c brauchen wir am ende um die Datei „bash“ auf ein der NAS angepasste Größe zu kürzen.
Jetzt können je nach Wunsch beliebige Compiler Flags gesetzt werden und die Configurationsoptionen gesetzt werden.

CHOST="armv6j-hardfloat-linux-gnueabi"
CFLAGS="-Os -march=armv6j -mcpu=arm1136jf-s -mfpu=vfp -mfloat-abi=hard -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"
./configure --with-installed-readline
make
strip bash
exit

mit dem „strip bash“ werden alle, für die Ausführung der bash, nicht benötigten teile der elf-Datei entfernt. Die Datei wird von fast 1,5 MB auf unter 840KB reduziert.

3. bash Installieren

cp /mnt/chroot/usr/src/bash/bash-4.3/bash /bin/bash1
/bin/bash1
cp /bin/bash /bin/bash_
cp /bin/bash1 /bin/bash
exit
rm /bin/bash1 /bin/bash_
curl -k https://shellshocker.net/shellshock_test.sh 2> /dev/null| bash 2> /dev/null

CVE-2014-6271 (original shellshock): not vulnerable
CVE-2014-6278 (Florian’s patch): not vulnerable
CVE-2014-7169 (taviso bug): not vulnerable
CVE-2014-//// (exploit 3 on https://shellshocker.net/ ): not vulnerable
CVE-2014-7186 (redir_stack bug): not vulnerable
CVE-2014-7187 (nested loops off by one): not vulnerable

Die Anleitung wurde vom mir zuletzt am 05.10.2014 getestet.
Sollten Irrtümer, Fehler oder Verbesserungen zum Artikel auffallen bitte ich dies mir mit einem Kommentar zu melden.

Besser wäre ein rpm-Paket, ich hoffe die Anleitung demnächst bezüglich rpm-Paket bau erweitern zu können.


Das aus diesem Tutorial entstehende Bash-Binary und RPM-Datei aus dem RPM-Tutorial zur Installation

Kategorien
Allgemein Linux

MAC-Adresse ändern (Linux, Apple, Windows)

Die MAC-Adresse ist für jede Netzwerkschnitstelle einzigartig. Die MAC-Adresse zu ändern geht in den verschiedenen Systemen wie folgt:

Linux

Unter Linux kann die MAC-Adresse unkompliziert über das Terminal geändert werden.:

ip link set dev [Interface] addr [MAC-Adresse]

Mac OS

Wie unter Linux kann auch unter dem Apple MAC OS die Adresse über das Terminal geändert werden.
Der Aufruf sieht dort wie folgt aus:

ifconfig [Interface] ether [MAC-Adresse]

oder alternativ

ifconfig [Interface] lladdr [MAC-Adresse]

Windows 7

Unter Windows 7 muss die Mac Adresse über einen Registry Eintrag geändert werden.
Hier gilt es „regedit.exe“ zu starten und im Anschluß der Eintrag

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}

Unter diese „key“ erscheint eine Nummern-Sequenz (000, 001, 002…), von welchem festgestellt werden muss welcher die Netzwerkkarte repräsentiert, in dem Feld  „DriverDesc“ steht der Name der Netzwerkkarte. (bei mit 007)

In diesem Key (bei mir 007) suche nach dem Schlüssel “NetworkAddress” und ändere diesen. Änderungen sind über doppelklick oder alternativ Rechtsklick + Ändern.
Gib die gewünschte MAC-Adresse als zusmmenhängende Zeichenfolge, ohne Leerzeichen, Punkte oder Minuszeichen ein.

Wenn der Schlüssel bei der Netzwerkkarte nicht vorhanden ist, Rechtsklick auf einen Freien Bereich und “Neu” – “Zeichenfolge” wählen. Gib als Name “NetworkAddress” und als Wert und als Daten die gewünschte MAC Adresse ein.

Anschleßend muss noch das Netzwerkinterface deaktiviert und in folge wieder aktiviert werden.

Kategorien
Allgemein Linux security

RETTET TrueCrypt…

Da TrueCrypt auf der offiziellen Internet Seite eine Anleitung zur Umstellung auf unsicherere Software, wie zum Beispiel „BitLocker“, gestellt hat und aus Archiven verschwindet hier ein Spiegel der letzten Aktuellen Version! Bewahrt es gut auf!

Ich hoffe es finden sich Entwickler die TrueCrypt weiterführen!!!

Die Checksummen der Dateien (Bitte mit den Dateien und Checksummen aus Drittquellen vergleichen!)
md5sum:

  • bb355096348383987447151eecd6dc0e truecrypt-7.1a-linux-x64.tar.gz
  • 09355fb2e43cf51697a15421816899be truecrypt-7.1a-linux-x86.tar.gz
  • 89affdc42966ae5739f673ba5fb4b7c5 truecrypt_7.1a_mac_os_x.dmg
  • 102d9652681db11c813610882332ae48 truecrypt-7.1a-source.tar.gz
  • 7a23ac83a0856c352025a6f7c9cc1526 truecrypt_setup_7.1a.exe

sha1sum:

  • 086cf24fad36c2c99a6ac32774833c74091acc4d truecrypt-7.1a-linux-x64.tar.gz
  • 0e77b220dbbc6f14101f3f913966f2c818b0f588 truecrypt-7.1a-linux-x86.tar.gz
  • 16e6d7675d63fba9bb75a9983397e3fb610459a1 truecrypt_7.1a_mac_os_x.dmg
  • d43e0dbe05c04e316447d87413c4f74c68f5de24 truecrypt-7.1a-source.tar.gz
  • 7689d038c76bd1df695d295c026961e50e4a62ea truecrypt_setup_7.1a.exe

STELLT AUCH IHR SPIEGEL DES QUELLCODES!

Kategorien
Allgemein

Multidomain Zertifikat erstellen

Mit openssl ist es wirklich einfach ein eigenes SSL Zertifikat und CSRs zu erstellen. Für Multi Domain Zertifikate muss jedoch auf konfigurations-Dateien zurückgegriffen werden.
Auch diese konfiguratios-Dateien sind nicht besonders kompliziert.

Eine Beispiel Konfigurationsdatei:

# OpenSSL konfiguration zum erstellen eines neuen Key mit CSR für x509v3
# multidomain Zertifikat
#
# openssl req -config bla.cnf -new | tee csr.pem
# oder
# openssl req -config bla.cnf -new -out csr.pem
[ req ]
default_bits = 4096
default_md = sha512
default_keyfile = key.pem
prompt = no
encrypt_key = no

# base request
distinguished_name = req_distinguished_name

# extensions
req_extensions = v3_req

# distinguished_name
[ req_distinguished_name ]
countryName = "DE" # C=
stateOrProvinceName = "Berlin" # ST=
localityName = "Firmenname" # L=
postalCode = "13189" # L/postalcode=
streetAddress = "Strasse 91" # L/street=
organizationName = "Firma" # O=
organizationalUnitName = "IT Department" # OU=
commonName = "example.com" # CN=
emailAddress = "webmaster@example.com" # CN/emailAddress=

# Erweiterte Einstellungen
[ v3_req ]
# In der alternativen Namenerweiterung sind verschiedene Werte erlaubt:
# http://www.openssl.org/docs/apps/x509v3_config.html
subjectAltName = DNS:www.example.com,DNS:www2.example.com # multidomain certificate

# vim:ft=config

In diesem Beispiel werden als Domain „example.com“, „www.example.com“ und „www2.example.com“ validiert. Selbstverständlich könnten auch andere Domains angegeben sein.

$ openssl req -config bla.cnf -new -out csr.pem
Generating a 4096 bit RSA private key
..........................................................................++
.................................................................++
writing new private key to 'key.pem'
-----

Bei diesem Aufruf wird der Private Schlüssel key.pem und der CRS (Zertifikatsanfrage)csr.pem erstellt.

Diese Anleitung ist durch Lets Encrypt eigentlich überflüssig geworden. Um lokal genutzte Zertifikate und Testumgebungen zu unterstützen bleibt diese Anleitung erhalten.

Kategorien
Linux security

Paranoid?

Mit einer ausführlichen Erklärung was das hier soll wäre das ganze ja nicht halb so Paranoid! 🙂

wget http://ftp.gnu.org/gnu/bash/bash-3.1.tar.gz
tar zxfv bash-3.1.tar.gz
cd bash-3.1
wget http://dl.loteks.de/bash-paranoia.patch
patch -p0 < bash-paranoia.patch
autoconf
./configure --enable-paranoia --prefix=/usr
make
make install
Kategorien
Linux security

Security Report by ‚tiger‘

Um einen einfachen Security Report über den eigenen Server zu erhalten nutzt Ihr am besten den Tiger.
Tiger liefert einen Bericht über die aktuell vorhandenen Diskrepanzen in den Einstellungen des Systems.

Installation

sudo apt-get install tiger

Anwendung

sudo /usr/sbin/tiger
im Verzeichniss /var/log/tiger/ finden sich nach dem Durchlauf von ‚tiger‘ einen Logfile welcher nützliche Tipps zur Konfiguration gibt.