Exim: höhere Quota durch Hardlinks

Was man üblicherweise auf einem Mailserver nicht sieht, sind Hardlinks in einem IMAP Postfach. Neulich hatten wir einen Fall, bei dem ein Postfach nicht mehr mit Emails bestückt werden konnte, da angeblich die Quota überschritten war. Der Quota Befehl bzw. die Diskusage zeigten aber noch mehr als genug Platz an um Emails zu speichern. Eine lange Debugsession mit dem Mailserver später zeigte sich dies Bild:

# ls -la
insgesamt 41284
drwx------  2 51703 exim    53248 25. Nov 13:57 .
drwx------ 33 51703 exim     4096 26. Nov 22:38 ..
-rw-------  2 51703 exim     4688 28. Jul 14:27 1406550448.H508202P31298.testmailsystem.de:2,STac
-rw-------  1 51703 exim     6228 28. Jul 14:29 1406550593.H760899P1075.testmailsystem.de:2,STac
-rw-------  2 51703 exim     7124 28. Jul 14:30 1406550644.H440184P3285.testmailsystem.de:2,STac
-rw-------  1 51703 exim    23883 28. Jul 23:57 1406584630.H262931P23098.testmailsystem.de:2,STac
-rw-------  1 51703 exim    38557 28. Jul 23:57 1406584630.H262971P23108.testmailsystem.de:2,STac
-rw-------  1 51703 exim    10399 31. Jul 21:16 1406834208.H555417P7976.testmailsystem.de:2,STac
-rw-------  1 51703 exim     4753  6. Aug 14:00 1407326454.H100216P15143.testmailsystem.de:2,STac
-rw-------  1 51703 exim     8542  6. Aug 17:05 1407337554.H866124P23519.testmailsystem.de:2,ST
-rw-------  1 51703 exim     5139  7. Aug 03:19 1407374382.H660749P16291.testmailsystem.de:2,ST
-rw-------  2 51703 exim  7709636  7. Aug 09:17 1407395874.H306908P12145.testmailsystem.de:2,ST
-rw-------  1 51703 exim    19706  7. Aug 17:20 1407424830.H721569P4216.testmailsystem.de:2,ST
-rw-------  2 51703 exim    28758  8. Aug 03:16 1407460589.H96348P29141.testmailsystem.de:2,ST
-rw-------  1 51703 exim    19287  8. Aug 05:09 1407467371.H994402P28663.testmailsystem.de:2,ST
-rw-------  2 51703 exim   163906 10. Aug 11:59 1407664747.H312607P5781.testmailsystem.de:2,ST
-rw-------  1 51703 exim   145859 12. Aug 08:32 1407825143.H875343P15843.testmailsystem.de:2,ST
-rw-------  1 51703 exim     2883 12. Aug 17:52 1407858759.H268291P26980.testmailsystem.de:2,ST
-rw-------  1 51703 exim    15142 12. Aug 23:31 1407879079.H54240P1692.testmailsystem.de:2,ST
-rw-------  1 51703 exim   169634 13. Aug 12:33 1407926019.H343973P20662.testmailsystem.de:2,ST
-rw-------  1 51703 exim  1811494 13. Aug 12:33 1407926030.H129470P20750.testmailsystem.de:2,ST
-rw-------  1 51703 exim    14314  1. Sep 16:43 1409582634.H655301P27301.testmailsystem.de:2,STac
-rw-------  2 51703 exim     6615  1. Sep 16:48 1409582889.H200965P32252.testmailsystem.de:2,STac
-rw-------  1 51703 exim    81891  1. Sep 16:59 1409583555.H494207P11319.testmailsystem.de:2,RSTac
-rw-------  1 51703 exim     5922  2. Sep 09:59 1409644784.H204618P17282.testmailsystem.de:2,STac
-rw-------  1 51703 exim     3205  2. Sep 10:29 1409646565.H14176P17846.testmailsystem.de:2,STac
-rw-------  2 51703 exim    69525  2. Sep 14:13 1409659986.H860359P18194.testmailsystem.de:2,STac
-rw-------  2 51703 exim  2797748  2. Sep 14:22 1409660562.H502395P27754.testmailsystem.de:2,STac
-rw-------  1 51703 exim     3469  2. Sep 16:03 1409666611.H110966P30774.testmailsystem.de:2,STac
-rw-------  1 51703 exim     6171  2. Sep 17:17 1409671020.H386583P8312.testmailsystem.de:2,STac
-rw-------  2 51703 exim   249270  2. Sep 18:04 1409673850.H25221P18140.testmailsystem.de:2,STac
-rw-------  2 51703 exim   249310  2. Sep 18:27 1409675249.H305576P6080.testmailsystem.de:2,STac
-rw-------  2 51703 exim     2879  3. Sep 16:56 1409756208.H521320P17256.testmailsystem.de:2,STac
-rw-------  1 51703 exim   716982  5. Sep 10:51 1409907100.H303636P30461.testmailsystem.de:2,STac
-rw-------  1 51703 exim    24992  5. Sep 10:52 1409907143.H139290P30872.testmailsystem.de:2,STac
-rw-------  1 51703 exim    28603  5. Sep 22:07 1409947669.H441637P29243.testmailsystem.de:2,STac
-rw-------  2 51703 exim    35686  5. Sep 22:07 1409947672.H347460P29280.testmailsystem.de:2,STac
-rw-------  1 51703 exim    38421  7. Sep 15:03 1410094984.H95975P6942.testmailsystem.de:2,STac
-rw-------  1 51703 exim    35049  7. Sep 17:30 1410103800.H638453P11898.testmailsystem.de:2,STac
-rw-------  1 51703 exim    25767  8. Sep 04:56 1410144975.H59307P22155.testmailsystem.de:2,STac
-rw-------  1 51703 exim    24440  8. Sep 19:16 1410196570.H600494P20981.testmailsystem.de:2,STac
-rw-------  2 51703 exim   269397  9. Sep 09:46 1410248803.H891098P16172.testmailsystem.de:2,ST
-rw-------  1 51703 exim     3102  9. Sep 13:27 1410262028.H932995P19527.testmailsystem.de:2,ST
-rw-------  1 51703 exim    18995  9. Sep 18:37 1410280675.H406778P10307.testmailsystem.de:2,ST
-rw-------  1 51703 exim    85418 10. Sep 04:02 1410314549.H547715P6092.testmailsystem.de:2,ST
-rw-------  1 51703 exim     5174 10. Sep 16:00 1410357617.H134775P24247.testmailsystem.de:2,STac
-rw-------  2 51703 exim    13042 11. Sep 13:11 1410433911.H351692P31331.testmailsystem.de:2,STac
-rw-------  1 51703 exim    26742 17. Okt 00:20 1413498059.H680439P25291.testmailsystem.de:2,Sac
-rw-------  2 51703 exim   557174 30. Okt 10:16 1414660560.H183389P11356.testmailsystem.de:2,STac
-rw-------  1 51703 exim    23529 11. Nov 20:21 1415733677.H442593P8240.testmailsystem.de:2,STac
-rw-------  1 51703 exim    29774 11. Nov 20:34 1415734451.H994279P18947.testmailsystem.de:2,STac

Die erste Überraschung war die farbliche Hervorhebung der Files, was normalerweise nur für Executeables gemacht wird. Zum Glück muß man sagen, wurde das farblich markiert, denn sonst wäre die 2 vor der Userid nicht aufgefallen.

Beim ls Befehl steht in der Spalte üblicherweise die Anzahl der Verzeichnisse in diesem Directoryeintrag, da es sich aber um Files handelt, mußte es etwas anderes sein: Hardlinks.

Ein Hardlink ist nichts weiter als ein zweiter Eintrag auf die gleiche Inode (Block im Filesystem) und durchaus eine normale Sache in einem Linuxfilesystem, also kein Bug. Es bedeutet, daß es (in unserem Fall) zwei Einträge gibt, welche die gleiche Inode referenzieren, also quasi eine Datei die es doppelt gibt.

Der Exim zählt die Dateien aber einzeln, was dann zur Abweichung mit der eingestellten Quota führt.

Um sich die Inodes anzeigen zu lassen, muß man ls mit dem Argument -i aufrufen. Beispiel: ls -ila

 5913370 -rw------- 1 51703 exim 5174 10. Sep 16:00 1410357617.H134775P24247.testmailsystem.de:2,STac
 5904472 -rw------- 2 51703 exim 13042 11. Sep 13:11 1410433911.H351692P31331.testmailsystem.de:2,STacDie erste Zeile ist ok, vorne ist die INODE der Datei.

Wenn man jetzt mit find die Inode sucht, erhält man diese zwei Files :

# find /mailacct/mailbenutzer/ -inum 5904472 -print
/mailacct/mailbenutzer/Maildir/cur/1410433911.H351692P31331.testmailsystem.de:2,STac
/mailacct/mailbenutzer/Maildir/.privat 2014/cur/1415952178.M141844P8647.testmailsystem.de,S=13042,W=13341:2,Sab

Da das Filesystem auf den Hardlink achtet, bekommt man die korrekte Quota angezeigt, weil die nach benutzten Inodes geht. Der Exim dagegen zählt die Dateigrößen, egal ob es sich um Links handelt oder nicht.

Was man jetzt tun muß ist, eine von beiden Dateien löschen. Keine Panik, daß stört die andere Datei kein bisschen, die wird nicht gelöscht oder beeinträchtigt.

Danach stimmt die Quota wieder.

18 Jahre alte Sicherheitslücke in Windows entdeckt

Einer Meldung von heise.de können wir entnehmen, daß seit 18 Jahren im IE von Windows eine Lücke klafft, die sehr leicht ausnutzbar ist:

Lücke ist 18 Jahre alt
Entdeckt haben die Lücke die Sicherheitsforscher von IBMs X-Force-Team. Die Forscher geben an, die Lücke bereits im Mai 2014 an Microsoft gemeldet zu haben, einschließlich eines funktionsfähigen Proof-of-Concept. Microsoft hat sich mit dem Patchen also ein halbes Jahr Zeit gelassen. Die Lücke klafft offenbar bereits seit 18 Jahren in Windows: Windows 95 mit dem Internet Explorer 3 ist die erste anfällige Konstellation. Mit dem IE3 hat Microsoft die VBScript-Unterstützung eingeführt.
Quelle: http://www.heise.de/newsticker/meldung/Exploit-bringt-Nutzer-aller-Windows-Versionen-in-Gefahr-2457372.html
 

Das alleine wäre aber kein Grund hier aufzutauchen 🙂 Solche Lücken gibt es dutzendweise in allen möglichen Betriebssystemen und Komponenten. Was Sie an der Meldung stören sollte ist das hier:

Microsoft hat sich mit dem Patchen also ein halbes Jahr Zeit gelassen.

Wenn ich von Linux spreche, bringe ich immer wieder den Patchday von Microsoft als Grund, wieso man Windows nicht einsetzen sollte, da es mit unter 30 Tage dauern kann, bis eine Sicherheitslücke gestopft wird. Microsoft patcht nur sehr ungern Lücken außerhalb des Patchdays, obwohl die Benutzer nach bekanntwerden einer Lücke sofort Opfer eines Angriffs werden können. Im Gleichklang mit Microsoft, finden die Kriminellen daß richtig gut.

Auf Linux gibt es keine Patchdays, außer Sie als Anwender spielen Updates immer manuell ein. Davon kann ich allerdings nur dringend abraten. Sobald ein Fix bekannt ist, sollte der Patch eingespielt werden. Dabei sollte es unerheblich sein, ob irgendetwas anderes, unwichtiges daran kurzfristig zerbricht, denn die Systemsicherheit sollte Vorrang haben.  Bei Serversystemen die Webshops u.ä. laufen haben, liegt der Fall etwas anders, wobei auch hier die Sicherheit Vorrang haben sollte. Solche Server werden i.d.R. anders mit Updates versehen, da sich die Systemumgebung nicht ändern darf. Beispiel CentOS oder Redhat Enterprise Linux.

Aber für Linux Desktops gilt:  Alle zwei Stunden sollte das automatische Update laufen um asap. mit Updates versorgt zu sein.

 

 

Dümmer als die Polizei erlaubt

Aus der Serie „Wären Verbrecher clever, müßten wir Angst haben“ heute die Telekom RechnungOnline:

Dieser Textblock, der in der Spam als Mine-Type text/plain markiert ist:

sehr geehrter Kunde<BR>
<BR>
Im Anhang finden Sie die gewünschten Dokumente und Daten zu Ihrer Telekom Mobilfunk RechnungOnline für Geschäftskunden vom Monat November,<BR>
<a href="http://truyenratngan.com/MVs52QmpI">Download (Ihre Telekom Mobilfunk RechnungOnline für Geschäftskunden 6542265421925 vom 07.11.2014 des Kundenkontos 1925654222).</a>
Mit freundlichen Grüßen,<BR>
Geschäftskundenservice<BR>

fällt definitiv in unsere Reihe „Dümmer, gehts nümmer“. Warum ?

Der Text ist gut kopiert, das Datum im Text aktuelle, die Rechtschreibung ok und einen vietnamesischen Webdienst als Downloadquelle für den lokalen Exploit zu benutzen ist, aus Sicht des Angreifers optimal,
dummerweise muß diese Email so derbe failen, weil die Autoren Ihre Filterfunktionen nicht im Griff haben.
In einem text/plain Textblock, kommt kein HTML vor und mit was sind die Zeilenumbrüche gemacht worden ? 🙂

Dazu noch der immernoch vorhandene HTML Link zum Exploit, der im Klartext sicher gleich aufgefallen wäre, also komplett gefailed 🙂

1+1: „Sie haben das Internet kaputt gemacht.“

Störung des Mailversands bei 1+1

Wie aus diversen Berichten von Betroffenen hervorgeht, hat 1+1 derzeit massive Probleme Emails eigener Kunden zu versenden und Emails an Kunden zu empfangen.

Seit 10:30 Uhr heute früh hat 1+1 eine Störungsmeldung auf ihrer Seite http://status.1und1.de

Die Ursache dafür, daß man 1und1 keine Emails mehr schicken kann, liegt darin begründet, daß viele Netze eine sogenannte CNAME-Delegation haben. Damit vermeiden große Anbieter, daß jeder kleine Kunde bei RIPE ein Netz bekommt. Stattdessen werden kleine Teile des eigenen Netzes an die Nameserver des Kunden delegiert. Dadurch kann der Kunde dann eigene PTR-Records für seine IPs setzen.

Nachforschungen zu folge, funktioniert genau dieser Mechanismus bei 1+1 Mailservern derzeit nicht mehr.

1+1 selber spricht nur von Emailproblemen seiner eigenen Kunden.

Die Störung bei 1+1 fing unseren Recherchen zufolge am 3.11. gegen 14.20 Uhr an.Eine typische Meldung sieht im Log so aus : host mx-ha02.web.de [213.165.67.120]: 554-web.de (mxweb101) Nemesis ESMTP Service not available\n554-No SMTP service\n554 invalid DNS PTR resource record, IP=1.2.3.4
Daran können Sie erkennen, ob Sie betroffen sind oder nicht.Der Support von 1und1 hat dies Problem bestätigt und verweist darauf, daß es mit Nachdruck gelöst wird. Wie lange auch immer das dauern mag 🙂