4
RPC over HTTPS sicher auch ohne ISA
Hallo,
ich lese im Zusammenhang mit RPC nun mehrmals das Exchange nicht 'so ins Netz' gestellt werden sollte.
Hier läuft nur der SBS03 std (kein ISA o.ä.) an einem Netgear proSafe VPN Router.
Auf was sollte ich Eurer Meinung achten oder besser auf RPC verzichten?
Grüße
loc
ich lese im Zusammenhang mit RPC nun mehrmals das Exchange nicht 'so ins Netz' gestellt werden sollte.
Hier läuft nur der SBS03 std (kein ISA o.ä.) an einem Netgear proSafe VPN Router.
Auf was sollte ich Eurer Meinung achten oder besser auf RPC verzichten?
Grüße
loc
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 108384
Url: https://administrator.de/contentid/108384
Ausgedruckt am: 22.11.2024 um 17:11 Uhr
4 Kommentare
Neuester Kommentar
Hallo.
Welche Gründe werden hier angeführt, warum es nicht so sein sollte?
kein Problem
Nein.
LG Günther
ich lese im Zusammenhang mit RPC nun mehrmals das Exchange nicht 'so ins Netz' gestellt werden sollte.
Welche Gründe werden hier angeführt, warum es nicht so sein sollte?
Hier läuft nur der SBS03 std (kein ISA o.ä.) an einem Netgear proSafe VPN Router.
kein Problem
oder besser auf RPC verzichten?
Nein.
LG Günther
Tag Günther,
na Sicherheit... .
Aplication Firewall oder ISA wird immer wieder wieder von den Autoren angeraten.
Das Du RPC Verfechter bist weiß ich schon, wenn gleich ich Deine Aussage 'geht ganz leicht' nicht zu 100% teilen mag
. Ich bin schon am internen FQDN beim Zertifikat hängengeblieben...
loc
na Sicherheit... .
Aplication Firewall oder ISA wird immer wieder wieder von den Autoren angeraten.
Das Du RPC Verfechter bist weiß ich schon, wenn gleich ich Deine Aussage 'geht ganz leicht' nicht zu 100% teilen mag
. Ich bin schon am internen FQDN beim Zertifikat hängengeblieben...loc
Hallo.
Gut, das sind natürliche zusätzliche Sicherheiten die nicht von der Hand zu weisen sind. Trotzdem kann RPC over HTTPs als sehr sicher angesehen werden, wenn die allgemeinen Richtlinien wie z.B. sichere Passwörter, Kontosperrung nach einer Anzahl von Fehlversuche usw. eingehalten werden.
Ich weiß nicht, wieso es immer daran hapert . Wenn ein Server über das Internet über die Adresse webmail.firma.de erreichbar sein soll, dann ist es eigentlich logisch, dass das Zertifikat auf den gleichen Namen ausgestellt werden muss.
LG Günther
Aplication Firewall oder ISA wird immer wieder wieder von den Autoren angeraten.
Gut, das sind natürliche zusätzliche Sicherheiten die nicht von der Hand zu weisen sind. Trotzdem kann RPC over HTTPs als sehr sicher angesehen werden, wenn die allgemeinen Richtlinien wie z.B. sichere Passwörter, Kontosperrung nach einer Anzahl von Fehlversuche usw. eingehalten werden.
Ich bin schon am internen FQDN beim Zertifikat hängengeblieben...
Ich weiß nicht, wieso es immer daran hapert
. Wenn ein Server über das Internet über die Adresse webmail.firma.de erreichbar sein soll, dann ist es eigentlich logisch, dass das Zertifikat auf den gleichen Namen ausgestellt werden muss.LG Günther
> Aplication Firewall oder ISA wird immer wieder wieder von den
Autoren angeraten.
Gut, das sind natürliche zusätzliche Sicherheiten die nicht
von der Hand zu weisen sind. Trotzdem kann RPC over HTTPs als sehr
sicher angesehen werden, wenn die allgemeinen Richtlinien wie z.B.
sichere Passwörter, Kontosperrung nach einer Anzahl von
Fehlversuche usw. eingehalten werden.
Autoren angeraten.
Gut, das sind natürliche zusätzliche Sicherheiten die nicht
von der Hand zu weisen sind. Trotzdem kann RPC over HTTPs als sehr
sicher angesehen werden, wenn die allgemeinen Richtlinien wie z.B.
sichere Passwörter, Kontosperrung nach einer Anzahl von
Fehlversuche usw. eingehalten werden.
das war es was nach Deiner Meinung an Basissicherheiten notwendig ist? - Wie gesagt ich lese immer wieder: 'Man sollte unbedingt genau wissen was man tut' ' Vorsicht Vorsicht' 'Das ganze System steht frei im Netz' etc etc...
> Ich bin schon am internen FQDN beim Zertifikat
hängengeblieben...
Ich weiß nicht, wieso es immer daran hapert
. Wenn einServer über das Internet über die Adresse webmail.firma.de
erreichbar sein soll, dann ist es eigentlich logisch, dass das
Zertifikat auf den gleichen Namen ausgestellt werden muss.
Stimmt eigentlich unklar
- was ich nicht kapiere ist, wie der öffentliche DNS Server weiß das es webmail.firma.de gibt. Ich hatte dazu auch schon mal was gepostet, bin damit aber nicht ganz ans fröhlich Ende gelangt, vielleicht magst Du mir da was zu sagen? RPC over HTTPS, einige Verständnisfragengrüße
loc
