Hallöchen zusammen,
ich möchte unsere Securepoint Firewall ablösen. Dort sind als Mail Relays:
CONNECT 192.xxx.xxx.021 RELAY
TO domain.de RELAY
TO domain.com RELAY
192.xxx.xxx.021 ist der Exchange.
SMTP Routen sind:
xx.xxx.xxx.xxx -> 192.xxx.xxx.021
domain.de -> 192.xxx.xxx.021
domain.com -> 192.xxx.xxx.021
xx.xxx.xxx.xxx ist unsere feste IP. Der MX Record verweist auf diese.
Nun mächte ich mit einer virtuellen Maschine mit Apache2 das Relay/SMTP realisieren. Habe nach der Anleitung hier den Apache aufgesetzt und konfiguriert. Er hat die IP 192.xxx.xx.250
Was muss ich noch machen? NAT Ports 80(443 auf die 250 legen? WO kann ich die SMTP's hinterlegen. Sie die domains alle notwendig oder reicht die feste IP?
Der Router ist ein LANCOM 1793xxx
Ich stelle mir das so vor:
INTERNET <--> Router mit DW <---NAT 80/443--> 192.xxx.xxx.250 (Apache) <---> 192.xxx.xxx.21 (Exchange)
Auf den Exchange soll per VPN auf die Dienste wie OWA/ActiveSync, etc. zugegriffen werden. Die Clients haben Outlook.
Muss ich da für den Exchange zwei Netzwerkkarten nehmen? Eine für den Apache, eine für das Client Netzwerk?
DANKE SCHON EINMAL
Frank
Apache kann smtp? Dachte, der kann nur http/https.
Auf den Exchange soll per VPN auf die Dienste wie OWA/ActiveSync, etc. zugegriffen werden. Die Clients haben Outlook.
Wozu denn dann den Apache mit https? Der ist doch dann mehr oder weniger überflüssig, oder versteh ich was falsch?
Muss ich da für den Exchange zwei Netzwerkkarten nehmen? Eine für den Apache, eine für das Client Netzwerk?
Eher nein, ich würd jedenfalls keine zwei nics im exchange verwenden. Wozu auch? Aber evtl. Versteh ich dein Konstrukt auch nur nicht.
Ah, ausgeklügelte Konstruktion, du willst direkten Zugriff auf den Exchange verhindern und es "gefiltert" über den Apache laufen lassen in der Hoffnung, der leitet keinen Mist weiter, was Microsoft/Exchange eventuell zukünftig wieder verbocken würde.
Hmm. Würde das funktionieren? Dafür gibts doch irgendwas anderes, das den Traffic zuerst empfängt und dann an den Exchange weiterleitet. Dass der Traffic dann aber "wirklich gefiltert" wird, wäre mir neu?
Mir käme aktuell nur noch ein anderer Ansatz, den ich aktuell dabei bin, bei einigen zu überlegen:
AD-Server, File-Server, xxx-Server und Exchange-Server alles im selben Netzwerk. Kommt ein Hack, ist alles auf einmal bedroht.
Mein Ansatz: AD-Server+Exchange-Server in ein eigenes isoliertes Netzwerk geben und mittels eigener öffentlicher IP betreiben. Die Clients, die dann in einem anderen Netzwerk hängen können sich dann auch nur mehr übers Internet bzw. mit der öffentlichen IP verbinden. So hast du zwar AD-Benutzer für deine Clients und AD-Benutzer für den Exchange, aber im Falle des Falles kannst du vermutlich den Exchange+AD einfacher wiederherstellen, als das plus alles andere das infiziert wurde. Es würde vielleicht nur eine Windows-Lizenz rechtlich mehr bedeuten, aber mal ehrlich....
Bei einem Kunden habe ich den Exchange mit 2 NICs: 1 NIC für internes Netzwerk für AD-Topology ist aber ohne default-gateway und ein NIC mit einem default-gateway, wo dahinter aber keine Clients/Kundeninfrastruktur hängt. Das trennt im Endeffekt aber nur, dass die Clients die IP1 im Internet haben und der Exchange die IP2.
Somit wüsste jemand im Internet nicht dass ein Client, der Firma xxx mit der IP, die öffentlich im DNS mit Mailserver gelistet sind im Internet surft. Mittlerweile weiß ich nicht mehr genau, ob es das bringt, aber ja, manche Kunden möchten nicht, dass Ihre IP-Adresse mittels Reverse-IP (PTR) herausgefunden werden kann und daher die Trennung von Client-Internetsurfern und Exchange-Server, der im öffentlich im DNS zu erkennen ist.
Oder was wäre dabei dein eigentliches Ziel bei der ganzen Überlegung?
manche Kunden möchten nicht, dass Ihre IP-Adresse mittels Reverse-IP (PTR) herausgefunden werden kann und daher die Trennung von Client-Internetsurfern und Exchange-Server, der im öffentlich im DNS zu erkennen ist.
Der Grund dürfte eher sein, dass man so ganz gut verhindern kann, dass ein Client welcher per smtp senden kann/darf dafür sorgt, dass die ip des Servers (Exchange) auf den blacklists landet.
Somit wüsste jemand im Internet nicht dass ein Client, der Firma xxx mit der IP, die öffentlich im DNS mit Mailserver gelistet sind im Internet surft.
Häh? Jede normale Firewall sollte sowas per source nat oder masquerading hinbekommen. Jedenfalls kaum ein sinnvoller Grund dem exchange deswegen zwei nics zu geben. ;)
Hmm. Würde das funktionieren? Dafür gibts doch irgendwas anderes, das den Traffic zuerst empfängt und dann an den Exchange weiterleitet. Dass der Traffic dann aber "wirklich gefiltert" wird, wäre mir neu?
Da gibts jede Menge. Quasi jeder Reverse Proxy. Wie gut oder schlecht der das macht hängt halt vom Produkt und dem Admin ab. Und ja natürlich „kann“ der auch filtern. Das wäre jetzt nicht so neu.
deine Securepoint Firewall kann auch Reverse Proxy, siehe folgende URL:
https://wiki.securepoint.de/UTM/APP/Reverse_Proxy-Exchange
deine Securepoint Firewall kann auch Reverse Proxy, siehe folgende URL:
Die möchte er doch aber ablösen. ;)