sastre
08.10.06, 14:46
Moin,
bis vor zwei Wochen hatte ich ein wundervolles Intranet, inzwschen läuft mir auf einer SUSE 9.1.-Installation unter Postfix die Deferred-Queue zu, weil gültige interne Adressen von SPAMmern mißbraucht werden. Von den Lesern dieses Forums erhoffe ich mir einen guten Tipp für eine Umkonfiguration.
Mit der Demut des stetig lernenden will ich nicht behaupten, dass wir über ein gutes Setup verfügen, aber sie hat sich jahrelang gegen alle denkbaren Angriffe, SPAM eingeschlossen, trotz sehr komplexer interner Anforderungen gut geschlagen. Wir müssen intern verschiedene Netze betreiben (DMZ, ein ganz sicheres Netz, ein unsicheres für Besucher und Vorführungen) und managen das mit einer Firewall-Appliance, für die - ohne dass ich die Möglichkeit hätte, den Sinn und Zweck noch zu diskutieren - nun einmal die Entscheidung gefallen ist. Die Firewall beherrscht u.a. auch Failover, weshalb sie hinter zwei Routern gleichzeitig steht. Intern stellt sie mehrere Netze zur Verfügung und ist dort jeweils Standardgateway mit der IP-Nummer .1 - wir haben also:
192.168.a.2
192.168.b.2
192.168.c.1
192.168.d.1
192.168...1
a und b sind extern, c uind ff. hinter der FW. Netz d sei die DMZ, Netz e das sichere Netz. Im sicheren Netz steht der Groupware-Server (sagen wir e.2) und in der DMZ die Linux-Maschine (sagen d.2). In der Umgebung, sowohl in der DMZ wie auch anderswo, gibt es mehrere andere Maschinen, die per POP, SMTP oder IMAP wechselseitig aufeinander zugreifen können. Für unser Szenario ist wichtig, dass SMTP-Verbindungen bei der Linux-Maschine d.2 SMTP grundsätzlich über den Standardgateway 192.168.d.1 eingehen und zwar unabhängig davon, ob sie aus dem Groupware-Server 192.168.e.2 oder aus der großen weiten Welt kommen.
Der Virenscanner auf der FW und Spamassassin / Procmail / Postfix mit virtuellen Domains auf e.2 arbeiten hervorragend so zusammen, dass a) Mails nicht relayed werden, b) in der Groupware so gut wie keine UCE ankommt und wir c) doch ein jeder unter jeder Adresse.sld.tld senden können, die uns zusteht.
Dummerweise sind aber genügend gültige Adressen von uns bekannt, um SPAM als vermeintlich von einem existierenden Benutzer kommend hier abzuwerfen und zuzustellen. Traditionelle Lösungen, etwa basierend auf Authentifizierung des Senders bei oder unmittelbar vor der Eröffnung der SMTP-Verbindung helfen uns wegen der Heterogenität des Umfeldes nicht. Damit grabe ich einigen automatisierten Prozessen das Wasser ab, die das einfach nicht unterstützen und denen das - mangels Eingriffsmöglichkeit durch Scripts o.ae. - auch nicht beizubringen ist. Was ich im Gegenzug allerdings nicht beachten muss, sind POP-/IMAP-Nutzer von draussen. Alle unsere Road Warrior gehen entweder über ein Web-Interface, bauen ein VPN auf oder erhalten pushed Services.
Was ich bräuchte, ist "schlicht", eine Lösung, die dazu führt, dass was extern angenommen worden ist, anders behandelt wird (keine Permissions), als Mails aus den internen Netzen.
Mir selbst ist dazu bisher nur eine Headerauswertung eingefallen, die prüft, ob 192.168.a/b.2 einen Stempel hinterlassen hat und dann restriktiv arbeitet (oder umgekehrt, ob sich ein Stempel von 192.168.d.1 findet). Allerdings habe ich das Gefühl, dass mir die Ressourcen der Maschine dadurch mächtig in den Keller gezogen würden; ausserdem möchte ich meine 6 GB deferred Mail gerne loswerden, ohne damit weltweit noch zahlreiche Empfänger zu nerven und in Kürze NDRs an lokale Benutzer loszutreten.
Besten Dank im Voraus für jede Hilfe, insbesondere sofort praktisch umsetzbare.
s.
bis vor zwei Wochen hatte ich ein wundervolles Intranet, inzwschen läuft mir auf einer SUSE 9.1.-Installation unter Postfix die Deferred-Queue zu, weil gültige interne Adressen von SPAMmern mißbraucht werden. Von den Lesern dieses Forums erhoffe ich mir einen guten Tipp für eine Umkonfiguration.
Mit der Demut des stetig lernenden will ich nicht behaupten, dass wir über ein gutes Setup verfügen, aber sie hat sich jahrelang gegen alle denkbaren Angriffe, SPAM eingeschlossen, trotz sehr komplexer interner Anforderungen gut geschlagen. Wir müssen intern verschiedene Netze betreiben (DMZ, ein ganz sicheres Netz, ein unsicheres für Besucher und Vorführungen) und managen das mit einer Firewall-Appliance, für die - ohne dass ich die Möglichkeit hätte, den Sinn und Zweck noch zu diskutieren - nun einmal die Entscheidung gefallen ist. Die Firewall beherrscht u.a. auch Failover, weshalb sie hinter zwei Routern gleichzeitig steht. Intern stellt sie mehrere Netze zur Verfügung und ist dort jeweils Standardgateway mit der IP-Nummer .1 - wir haben also:
192.168.a.2
192.168.b.2
192.168.c.1
192.168.d.1
192.168...1
a und b sind extern, c uind ff. hinter der FW. Netz d sei die DMZ, Netz e das sichere Netz. Im sicheren Netz steht der Groupware-Server (sagen wir e.2) und in der DMZ die Linux-Maschine (sagen d.2). In der Umgebung, sowohl in der DMZ wie auch anderswo, gibt es mehrere andere Maschinen, die per POP, SMTP oder IMAP wechselseitig aufeinander zugreifen können. Für unser Szenario ist wichtig, dass SMTP-Verbindungen bei der Linux-Maschine d.2 SMTP grundsätzlich über den Standardgateway 192.168.d.1 eingehen und zwar unabhängig davon, ob sie aus dem Groupware-Server 192.168.e.2 oder aus der großen weiten Welt kommen.
Der Virenscanner auf der FW und Spamassassin / Procmail / Postfix mit virtuellen Domains auf e.2 arbeiten hervorragend so zusammen, dass a) Mails nicht relayed werden, b) in der Groupware so gut wie keine UCE ankommt und wir c) doch ein jeder unter jeder Adresse.sld.tld senden können, die uns zusteht.
Dummerweise sind aber genügend gültige Adressen von uns bekannt, um SPAM als vermeintlich von einem existierenden Benutzer kommend hier abzuwerfen und zuzustellen. Traditionelle Lösungen, etwa basierend auf Authentifizierung des Senders bei oder unmittelbar vor der Eröffnung der SMTP-Verbindung helfen uns wegen der Heterogenität des Umfeldes nicht. Damit grabe ich einigen automatisierten Prozessen das Wasser ab, die das einfach nicht unterstützen und denen das - mangels Eingriffsmöglichkeit durch Scripts o.ae. - auch nicht beizubringen ist. Was ich im Gegenzug allerdings nicht beachten muss, sind POP-/IMAP-Nutzer von draussen. Alle unsere Road Warrior gehen entweder über ein Web-Interface, bauen ein VPN auf oder erhalten pushed Services.
Was ich bräuchte, ist "schlicht", eine Lösung, die dazu führt, dass was extern angenommen worden ist, anders behandelt wird (keine Permissions), als Mails aus den internen Netzen.
Mir selbst ist dazu bisher nur eine Headerauswertung eingefallen, die prüft, ob 192.168.a/b.2 einen Stempel hinterlassen hat und dann restriktiv arbeitet (oder umgekehrt, ob sich ein Stempel von 192.168.d.1 findet). Allerdings habe ich das Gefühl, dass mir die Ressourcen der Maschine dadurch mächtig in den Keller gezogen würden; ausserdem möchte ich meine 6 GB deferred Mail gerne loswerden, ohne damit weltweit noch zahlreiche Empfänger zu nerven und in Kürze NDRs an lokale Benutzer loszutreten.
Besten Dank im Voraus für jede Hilfe, insbesondere sofort praktisch umsetzbare.
s.