-=Kernel-Error=-

IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Seite 38 von 47

IPv6 / Default Route / DNS /DHCP

18. Oktober 2012 / / Keine Kommentare
Nun arbeite ich schon seit einigen Jahren, privat wie im Berufsleben, mit IPv6. Was mir bei vielen Schulungen, Einführungen, Netzumstellungen usw… auffällt ist dass es vielen Admins schwer fällt zu verstehen wie der Client nun an seine Netzwerkkonfiguration kommt. Da in der letzten Zeit immer mehr Fragen zu dem Thema bei mir landen (scheinbar müssen viele jetzt noch „auf den letzten Drücker“ IPv6 lernen), versuche ich es hier mal grob aufzuschlüsseln. Im Grunde ist es ganz einfach: –    Bei IPv6 verteilt der DHCPv6 Server keine Default Route, das macht der Router! –    Der DHCPv6 kann DNS Server, NTP-Server usw. verteilen und für eine automatische Eintragung des Clients am DNS Server sorgen. Er kann natürlich auch zusätzliche IPv6 Adressen verteilen. –    Der Router verteilt sein Präfix per RA (Router Advertisment).       o    Der Client kümmert sich um die Generierung einer IP-Adresse.       o    Im RA kann der Client aufgefordert werden einen DHCPv6 Server nach weiteren Informationen zu fragen.       o    Im RA kann ein DNS Server an den Client übergeben werden (RDNSS) Erst einmal ist also für eine vollständige Autokonfiguration des Clients kein DHCPv6 Server mehr nötig. Denn der Client hat immer und direkt eine IPv6 Adresse vom scope link (fe80:….). Diese Adresse hat der Client sobald er einen Netzwerklink hat und wird aus der eigenen MAC-Adresse per EUI (Extended Unique Identifier) erstellt. Nun sendet der Client im einfachsten Fall ein RS (Router Solicitation) an die Multicast Adresse, auf welche ALLE Router hören, ins Netzwerk (ff02::2). Der Router antwortet dann mit einem RA und übermittelt dem Client das IPv6-Präfix. Der Client baut dann aus diesem Präfix und EUI wieder eine Adresse vom scope global. Sowie bei aktivierten Privacy Extensions eine gewürfelte Adresse. Der Client hat nun mindestens zwei IPv6 Adressen bei aktivierten Privacy Extensions sogar bereits drei IPv6 Adressen, sowie eine Default Route über den Router welcher uns den RA verpasst hat. Ist am Router die Option RDNSS gesetzt wird dem Client zum Präfix auch noch ein DNS Server übergeben. Dieses ~verstehen~ leider noch nicht alle Clients. Damit wäre der Client schon in der Lage vollständig am „Internetleben“ teil zu nehmen. Ist am Router das Other Config Flag gesetzt, wird der Client angewiesen einen DHCPv6 Server nach weiteren Einstellungen/Informationen zu fragen. Nun kommt der DHCPv6 Server ins Spiel. Wird dieser vom Client nach weiteren Einstellungen/Informationen gefragt wird er die gewünschten Informationen an den Client übermitteln. Was nicht bedeutet dass der Client damit eine weitere IPv6 Adresse bekommen muss. Es ist auch möglich nur wins, ntp, dns usw.. an die Client zu übermitteln. Der Client muss dazu über einen DHCPv6-Client verfügen. Dieser ist bisher noch nicht bei allen Clientsystemen per Default vorhanden bzw. aktiviert! Natürlich kann man seinen DHCPv6 Server auch so konfigurieren dass er zusätzlich noch eine dritte bzw. vierte (oder mehr) IPv6 Adresse an den Client übermittelt. Damit wäre der DHCPv6-Server zusätzlich in der Lage diese IPv6 Adressen einem DNS Server bekannt zu machen. Wie auch beim Thema NAT bei IPv6 gibt es Vorschläge dem DHCPv6 Server wieder die Option Route zu spendieren, ich denke es ist nicht nötig / sinnvoll… Hier kann man sich streiten! Die Idee bei IPv6 möglichst viel Arbeit auf den Client zu verlagern ergibt meist erst auf den zweiten Blick Sinn. Bei IPv4 war es bisher so dass der Client als erstes ins Netzwerk herumbrüllt ob den ein DHCP Server da ist, dann gab es einen regen Austausch zwischen diesen Systemen und am Ende hatte der Client alle seine Informationen. Denkt man aber nun daran dass im größten IPv4 Netzausbei maximal (24^2)-2 Hostadressen herausspringen und beim IPv6 im kleinsten Netzausbau minimal (64^2)-2 Hostadressen herausspringen… Ja dann ahnt man schon, wenn sich hier ein Router noch ums Popo abwischen kümmern muss, dann ist nicht mehr viel mit Netzwerk. Noch Fragen? Dann fragen….

Siehe auch: IPv6 Grundlagen

Fragen? Einfach melden.

Legal Obst „klauen“

17. Oktober 2012 / / Keine Kommentare

Ich habe da vor kurzem etwas interessantes gefunden…..


Nimmt man einem Landwirt einfach seine Produkte vom Feld, mag es für einen Selbst ein Kavaliersdelikt sein. Man nimmt ja auch nur einen Apfel mit…. Aber wenn sich 100 Leute dieses denken, dann ist mehr als nur ein Baum leer und der Landwirt kann nichts verkaufen.

Nun zu meinem Fund… Es gibt da eine Webseite in welcher jeder seinen oder öffentliche „Bäume“ eintragen kann. Hier kann nun jeder suchen welche Sorte es bei ihm in der Nähe gibt und dort hinflitzen und sich sein Eimerchen voll machen. Genau beschrieben ist dieses alles direkt auf der Seite und diese nennt sich Mundraub.org und hier ist zu finden:
http://www.mundraub.org/


So long….

 

Fragen? Einfach melden.

Windows Server Backup mit Nagios überwachen

16. Oktober 2012 / / Keine Kommentare

Die Windows Server-Sicherung (ab Server 2008) lässt sich über die Management Console bequem einsehen. Aber wer schaut da täglich rein? Ich wollte das über Nagios überwachen und habe dafür ein PowerShell-Script geschrieben.

Die Idee

Auf den zu überwachenden Systemen ist jeweils eine Vollsicherung (Bare Metal) eingerichtet, die ein- bis mehrmals am Tag startet. Mich interessiert nur eine Frage: Wann war die letzte erfolgreiche Sicherung, und ist diese älter als drei Tage? Warum, weshalb, wo, wie, was — ist mir im ersten Schritt egal. Ich will nur informiert sein, wenn es keine aktuelle Datensicherung gibt.

Windows Server-Sicherung in der Management Console

Das Script

Das PowerShell-SnapIn Windows.ServerBackup liefert über Get-WBSummary eine Zusammenfassung der Sicherungen. Unter LastSuccessfulBackupTime steht das Datum der letzten erfolgreichen Sicherung.

Das Script vergleicht dieses Datum mit dem aktuellen: Ist die Sicherung von heute oder gestern, gibt es OK zurück. Bei zwei bis drei Tagen eine Warnung. Älter als drei Tage bedeutet CRITICAL. Zusätzlich erkennt es, ob die Befehlszeilentools nicht installiert sind und ob eine Sicherung über einen Tageswechsel hinweg noch läuft.

Download: backuptest.ps1 (aktuelle Version 0.3)

Voraussetzungen

Über den Server-Manager muss unter Windows Server-Sicherungsfeatures das Feature Befehlszeilentools installiert sein. Ohne das SnapIn gibt es beim Start des Scripts eine Fehlermeldung. Außerdem muss die Execution Policy angepasst werden:

Set-ExecutionPolicy RemoteSigned
Server-Manager: Windows Server-Sicherungsfeatures mit Befehlszeilentools

NSClient++ einrichten

Das Script nach C:\scripte\ legen. Im NSClient++ die NRPE-Konfiguration erweitern. Der Aufruf eines PowerShell-Scripts über NSClient++ sieht beim ersten Hinschauen etwas seltsam aus:

[NRPE Handlers]
command[check_windowsbackup]=cmd /c echo C:\scripte\backuptest.ps1 | powershell.exe -command -

Dazu muss NSClient++ natürlich als NRPE-Server konfiguriert sein:

[modules]
NRPEListener.dll
NRPEClient.dll

[NRPE]
port=5666
command_timeout=120
allowed_hosts=1.2.3.4
socket_timeout=120

Testen

Nach einem Neustart des NSClient++-Dienstes kann man vom Nagios-System aus testen:

$ check_nrpe -H 4.3.2.1 -p 5666 -t 120 -c check_windowsbackup
OK: Backup von gestern
Nagios-Webinterface: Windows Server Backup Check zeigt OK

Die restliche Einrichtung in Nagios (Service, Host, Command) ist Standard.

Fragen? Einfach melden.

MOTDstat

5. Oktober 2012 / / Keine Kommentare

Habe ich überhaupt schon von meinem neusten Lieblingsgimmik berichtet? Nein? Nö nö nö….. Es nennt sich MOTDstat und „ersetzt“ die bekannte Message of the Day.

Im Grunde ist es ein kleines bash Script welches einem ausgewählte Systeminformationen beim Login anzeigt. Es hat sogar die Möglichkeit einem im Fall der Fälle eine E-Mail zu schicken, dieses überlasse ich dann aber doch lieber Nagios.

Nach dem Download installiert sich alles fast von allein.

$ make install

Damit alles regelmässig aktualisiert wird folgt man am besten dem Vorschlag der README und wird den folgenden Aufruf in seine crontab.

$ crontab -e
*/5 * * * * root /usr/bin/motdstat --generate 1>/dev/null 2>/dev/null

Damit wird der Zustand alle 5 Minuten aktualisiert und alle Infos zum CronJob landen im Nirwana!

Bei einem motdstat -g schiebt MOTDstat die eigentliche Datei /etc/motd in /etc/motd.ori und wirft den generierten Systemzustand in /etc/motd. Bei einem neuen Login wird diese nun gefolgt von der /etc/motd.ori augegeben. Testen lässt sich dieses mit einem:

$ motdstat -s

Einstellungen zum Script lassen sich unter /etc/motdstat vorneheme. Da ich meine Message of the Day so oder so immer anfasse um dort möglichst auffällig den Systemnamen erscheinen zu lassen (ich komme sonst mal schnell durcheinander), passt es ganz gut dazu. Es kann natürlich keine echte Überwachung ersetzten,ist aus meiner Sicht denn noch ein ganz nettes „Programm“.

So long…..

 

 

Fragen? Einfach melden.

Die vergessenen abuse und postmaster Adressen

29. September 2012 / / Keine Kommentare

Für jede Domain, die E-Mail empfängt, muss es eine postmaster@ und eine abuse@ Adresse geben. E-Mails an diese Adressen müssen angenommen werden, und jemand sollte sie auch lesen. Geregelt ist das in RFC 5321 und RFC 2142.

Wofür die Adressen da sind

postmaster@domain.tld ist für technische Fragen zum Mailsystem. Wenn jemand Probleme hat, E-Mails an eine Domain zu schicken, wendet er sich an den Postmaster. Im schlechtesten Fall sitzt dort ein Mensch, der die Nachricht an den richtigen Admin weiterleiten kann.

abuse@domain.tld ist für Missbrauchsmeldungen. Wird die Domain zum Spam-Versand missbraucht, schreibt man an abuse. Eine Abuse-Adresse findet sich auch im WHOIS der meisten IP-Netze.

Warum das in der Praxis scheitert

Immer wieder kommen Beschwerden bei mir an, weil E-Mails an gehostete Domains abgewiesen werden. Also sucht man den Grund, findet ihn im Reject (Blockliste, fehlender Reverse-DNS, dynamische IP) und schreibt dem Postmaster der Absenderdomain. Vier Sekunden später kommt die Antwort: „Postfach nicht gefunden“ oder „Mailbox voll“.

Die Adressen existieren nicht, oder niemand liest sie. Das ist nicht nur ein Verstoß gegen die RFCs. Es macht die Fehlersuche für alle Beteiligten unmöglich.

Das eigentliche Problem: Filter

Selbst wenn die Adressen existieren, reicht das nicht. Wenn jemand Probleme hat, E-Mails an unsere Domain zu schicken, versucht er es über postmaster@. Wird diese E-Mail ebenfalls gefiltert, hat der Absender verloren. Ein Hinweis auf ein echtes Problem mit dem Mailsystem erreicht uns nicht.

Die Lösung: postmaster@ und abuse@ müssen an allen Filtern vorbei. Sowohl in Postfix als auch im Content-Filter.

Postfix: Empfänger whitelisten

In /etc/postfix/recipient-access die beiden Adressen mit OK eintragen:

# /etc/postfix/recipient-access
postmaster@kernel-error.de    OK
abuse@kernel-error.de         OK

Danach die Hash-Datei erzeugen:

postmap /etc/postfix/recipient-access

In /etc/postfix/main.cf muss check_recipient_access vor den Restrictions stehen. Die Reihenfolge ist entscheidend: Postfix arbeitet die Regeln von oben nach unten ab, die erste passende greift.

smtpd_recipient_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        check_recipient_access hash:/etc/postfix/recipient-access,
        reject_rbl_client zen.spamhaus.org,
        ...

Alle nachfolgenden HELO-Checks und RBL-Prüfungen greifen jetzt nicht mehr auf E-Mails an postmaster@ und abuse@.

Wo im SMTP-Dialog prüfen?

Postfix bietet mehrere Stellen für Restrictions:

smtpd_client_restrictions — nach connect
smtpd_helo_restrictions — nach HELO/EHLO
smtpd_sender_restrictions — nach MAIL FROM
smtpd_recipient_restrictions — nach RCPT TO
smtpd_data_restrictions — nach DATA
smtpd_end_of_data_restrictions — nach der Übertragung

Je früher man ablehnt, desto weniger Ressourcen verbraucht man. Wer im HELO prüft, nimmt erst gar keinen Empfänger entgegen. Wer erst nach DATA prüft, hat die komplette E-Mail schon angenommen. Für die meisten Setups ist smtpd_recipient_restrictions der sinnvolle Kompromiss.

Content-Filter: Spam durchlassen

Postfix lässt die E-Mails an postmaster@ und abuse@ jetzt durch. Aber der Content-Filter dahinter wird sie trotzdem filtern, wenn man ihm nicht sagt, dass er sie in Ruhe lassen soll.

In rspamd geht das über eine settings.conf Regel, die bestimmte Empfänger vom Spam-Filtering ausnimmt. In AMaViS (falls noch im Einsatz) über @spam_lovers_maps in /etc/amavis/conf.d/50-user:

# AMaViS: /etc/amavis/conf.d/50-user
@spam_lovers_maps = (
  [
    "postmaster\@kernel-error.de",
    "abuse\@kernel-error.de",
  ]
);

Das bedeutet nicht, dass die E-Mail nicht geprüft wird. AMaViS testet weiterhin, lässt die Nachricht aber durch. Viren und verdächtige Anhänge filtere ich an dieser Stelle weiterhin. Nur Spam darf passieren. Denn wenn mir jemand über eine dynamische IP per Telnet eine Nachricht an postmaster@ schickt, soll sie ankommen.

Wer sich grundsätzlich gegen Spoofing absichern will: SPF hilft dabei, festzulegen, welche Server für eine Domain senden dürfen.

Fragen? Einfach melden.

Postfix für sichere E-Mail-Auslieferung: Nur noch per TLS konfigurieren

25. September 2012 / / Keine Kommentare

Verschlüsselte E-Mail-Übertragungen sind meist ganz gut. Zumindest hält sie einem lästige Lauscher vom Hals. Besonders wichtig ist dabei der verschlüsselte Austausch zwischen Mail-Server und Mail-Client. Denn die User sitzen mit ihren Mail-Clients sehr schnell in einem „unsicheren“ Netzwerk. Daher wird inzwischen sehr oft und gut darauf geachtet diese Verbindungen zu sichern.

Die Verbindungen zwischen den Servern werden oft als nicht SO wichtig empfunden. Denn die Kisten stehen ja meist in gesicherten Bereichen (Serverraum, DMZ, Rechenzentrum) und dort zu lauschen ist schon aufwendiger – nicht unmöglich.
Es macht also Sinn seinem Postfix zu ermöglichen seine Server zu Server Verbindungen kryptisch zu gestalten.

Mit folgender Änderung sagt man seinem Postfix dass bei ausgehenden Verbindungen TLS benutzt werden kann, wenn möglich.

$ postconf -e smtp_tls_security_level=may

Wird Postfix nun ein Zertifikat gereicht, welches von Postfix mangels der Root-Zertifikate nicht geprüft werden kann… Ja, dann ist hier schon wieder Ende.

Sep 25 10:38:07 rootserver postfix/qmgr[2069]: D69471A2026: from=<kernel-error@kernel-error.com>;, size=38273, nrcpt=1 (queue active)
Sep 25 10:38:07 rootserver postfix/smtp[9454]: certificate verification failed for gmail-smtp-in.l.google.com[2a00:1450:400c:c05::1b]:25: untrusted issuer /C=US/O=Equifax/OU=Equifax Secure Certificate Authority

Auf Debian Systemen finden sich eine recht gepflegte Ansammlung im Paket: ca-certificates. Nachdem dieses installiert ist:

$ apt-get install ca-certificates

Sagt man Postfix noch wie er es findet:

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

Schon sollte Postfix in der Lage sein, ausgehende Serververbindungen zu prüfen und zu verschlüsseln.

Siehe auch: Client-Initiated Renegotiation deaktivieren

Fragen? Einfach melden.

Mailserver – früher war alles besser…

24. September 2012 / / Keine Kommentare

Nein, nicht ganz. Früher war es nur noch nicht so wichtig, ob man sich nun an die RFCs oder Empfehlungen hält noch nicht. Solange man nur smtp spricht….
In den letzten Jahren hat sich dieses etwas geändert. Da immer mehr Benutzer und Server in Fluten von Viren- und SPAMMAILS ertranken. Wurden die Ansprüche an Filter, welche diesem Herr werden sollten, immer höher.

Eine Idee ist nun zu schauen ob der einliefernde E-Mail-Server überhaupt sauber konfiguriert ist. Denn jemand der keine genaue Ahnung hat was er da genau konfiguriert, der konfiguriert mal schnell Lücken für Spammer oder ist sogar selbst einer. Lässt ein Admin seine Konfiguration schleifen, dann schleift auch meist die Sicherheit des Systems. Möchte man als Mailserver ernst genommen werden, sollte man zumindest korrekt konfiguriert sein. Im normalen Leben erwarte ich ja von meinem Arzt auch eine gewissen Hygiene, sonst lasse ich mich nicht anfassen!

Jetzt testen diese Spamfilter also in gewissem Maße die korrekte Konfiguration des einliefernden Mailservers. Passt diese nicht zu den gängigen RFCs und/oder Empfehlungen, werden die E-Mails halt abgewiesen. Man glaubt überhaupt nicht, wie viele Spammails man damit schon erschlägt. Leider betrifft dieses nun auch die E-Mails der Mailserver, welche von „faulen“ Admins oder…. –interessierten Laien- betrieben werden.
Diese stöhnen nun natürlich, denn der -faule- Admin muss sich kümmern und der interessierte Laie versteht überhaupt nicht was los ist. Für diese war es früher „einfacher“.

Es wird leider sehr schnell unterschätzt was zum korrekten Betrieb eines E-Mail Servers alles nötig und zu beachten ist. Nur zu dumm dass man Mittlerweile sogar damit auffällt *lach*!

Ich habe selbst eine gewissen Zeit mal die RBL von https://web.archive.org/web/20171023192347/http://www.rfc-ignorant.org/ eingebunden. Dieses trifft leider nur die Benutzer. Die wollen und können dieses Problem nicht verstehen. Es kann denn noch sehr spannend sein, zu sehen wer dort hin und wieder gelistet ist.
Denkt also immer brav an RFC5321 https://web.archive.org/web/20171023192347/http://www.rfc-ignorant.org/policy-postmaster.php sowie an RFC2142 https://web.archive.org/web/20171023192347/http://www.rfc-ignorant.org/policy-abuse.php Was wird noch gleich oft vergessen? Ja genau…. PRT, A/AAAA-RECORD und HELO!

 

 

Siehe auch: MTA-STS einrichten

Fragen? Einfach melden.

Postfix

22. September 2012 / / Keine Kommentare

Zu beginn habe ich diese Seite nur mit dem Text: „Zeugs zu Postfix“ gefüllt!

Dieses erfüllt auch jetzt noch fast alles was es als Beschreibung zu sagen gibt. Aber auch nur fast! Postfix ist einer der besten und flexiebelsten MTAs die ich kenne. Hier werfe ich nun immer mal wieder Zeugs hin, welches vielleicht hilfreich sein könnte.

 

 

Fragen? Einfach melden.

AMaViS Performance-Tuning

22. September 2012 / / Keine Kommentare

Ich beobachte in der letzten Zeit immer mal wieder dass E-Mails im AMaViS lange hängen bleiben…. Viel Zeit scheint dabei für die Festplatte bzw. die Schreib-/Lesezugriffe drauf zu gehen. Die E-Mail wird von AMaViS angenommen, in dessen tmp Verzeichnis geschrieben. Dann noch ein paar mal gelesen um alle Tests zu machen, ausgepackt usw. usw… Um dieses etwas einzugrenzen habe ich mich gedacht, warum nicht eine RAM Disk für AMaViS oder besser für dessen Temp?

Auf einer gängigen Debian Kiste findet sich dieses Verzeichnis hier:

/var/lib/amavis/tmp

 Damit dieses Verzeichnis nicht mehr auf der Festplatte herum-gewürfelt wird, sondern sich nur noch im Arbeitsspeicher des Servers befinden (der ist ja viel schneller als so ne olle HDD) trägt man folgendes in seine /etc/fstab ein:

/dev/shm    /var/lib/amavis/tmp    tmpfs    defaults,size=256m,mode=750,uid=109,gid=113    0 0

 Man sollte nur darauf achten, dass uid und gid die des lokalen amavis sind. Sonst darf am Ende AMaViS nicht mehr in ein eigenes Temp schreiben. Es soll bessere Wege die ID zu finden, ich mache es schnell und einfach mit:

$ cat /etc/passwd|grep amavis
amavis:x:109:113:AMaViS system user,,,:/var/lib/amavis:/bin/sh

109 ist dabei die User-ID
113 ist die Group-ID

 Das neue AMaViS-tmp ist damit 256MB gross. Für die Grösse gibt es eine „Faustformel“… Diese macht nicht für jeden Sinn! Man würde mit dieser Formel zwar _fast_ nie in die Gefahr eines zu kleinen AMaViS-temps laufen, nur verbrennt man so seinen RAM. Try and Error ist hier eher mein Vorschlag. Denn sollte AMaViS wirklich mal keinen Platz mehr haben, wird die E-Mail mit einem temporären Fehler abgewiesen. Der einliefernde Mailserver wird daher versuchen die E-Mail ein paar Minuten später noch einmal zuzustellen. Damit sollte keine E-Mail verloren gehen. Als Admin behält man nach so einer Änderung einfach seinen Server im Auge und erhöht bzw. reduziert den Wert/die Grösse… Fertig.

Die RAM-Disk gibt AMaViS einen extremen Boost und steigert so dessen Performance enorm. Ich finde es kommt selten vor dass man so einfach ein so krasses Performance-Tuning hin bekommt. Nun laufen die E-Mails also schneller durch AMaViS und mein Postfix muss nicht mehr so lange auf die Filterung warten. WOOOOHOOOOO

Siehe auch: rspamd mit IMAPSieve

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑