Hallo! Ich habe mir überlegt, ob es sinnvoll wäre, einen kleinen stromsparenden pc als Firewall und NAS einzusetzen. Als Betriebssystem würde mir am ehesten IP Fire in den Sinn kommen. Bin auf die Idee gekommen, weil ich mir früher oder später sowohl eine NAS zulegen möchte, als auch meinen Router austauschen möchte, da er noch kein WLAN-n kann. Dann könnte man beide Funktionen mit einem Gerät erledigen. Zusätzlich hat man mit einem PC natürlich viel mehr Möglichkeiten, als mit einem reinen NAS und einem reinen Router. Man könnte z.B. auch mit TV-Headend bestimmte Sendungen aufnehmen und diese dann auf dem TV oder PC ansehen. Archivieren wär auch einfacher, als mit dem TV, da verschlüsselungsfrei. Was mir allerdings Sorgen macht, ist der Gedanke, dass meine Daten dann direkt am ersten Gerät nach dem Internet sind. Man müsste sich also nur in ein Gerät hineinhacken, um an meine Daten zu kommen. Seh ich das richtig? Wäre das als Kombination tatsächlich unsicherer, als wenn man einen extra Router mit Firewall und eine extra NAS hat? Danke im Voraus! Gruß
Guest schrieb: > Seh ich das richtig? Wäre das als Kombination tatsächlich unsicherer, > als wenn man einen extra Router mit Firewall und eine extra NAS hat? ja und nein. > Was mir allerdings Sorgen macht, ist der Gedanke, dass meine Daten dann > direkt am ersten Gerät nach dem Internet sind. Man müsste sich also nur > in ein Gerät hineinhacken, um an meine Daten zu kommen. > ja und nein. wenn jemand sich aber z.b. auf deinem PC einhackt, dann kommt er auch auf deinen Daten drauf. Da braucht er nicht den Umweg über die Firewall zu gehen. Angriffe auf Firewalls (egal ob billig oder nicht) sind heute kaum erfolgreich. Man erreicht viel mehr mit Angriffen auf Browser und die Addons (Java, Flash). Und da bringen 2 Geräte keine zusätzliche Sicherheit.
Peter II schrieb: > Angriffe auf Firewalls (egal ob billig oder nicht) sind heute kaum > erfolgreich. Ich tät es andersrum formulieren: Andere Attacken sind einfacher. Ausser es handelt sich dabei um bekannte Backdoors, oder sowas in der Art. Da sind ja über die Jahre einige aufgeflogen. Manche wurden gefixed, manche nicht. Vor ein paar Monaten war auch Juniper dabei.
:
Bearbeitet durch User
Ich würde IP Fire installieren. Das ist ja ein Linux. Linux ist zwar sicherer, als Windows, aber es ist kein Router in dem Sinn, es fungiert halt als Router. Gilt es trotzdem, dass es schwieriger zu Hacken ist, als einen PC? Spricht also wirklich nichts für eine extra NAS von der Sicherheit her? (Ich meine damit neben der Sicherheit gegen Datenklau auch die Sicherheit gegen Datenverlust)
Trenne Router und Serverdienste. Welchen Vorteil versprichst Du Dir davon, beide zusammenzufassen?
Rufus Τ. F. schrieb: > Trenne Router und Serverdienste. Welchen Vorteil versprichst Du Dir > davon, beide zusammenzufassen? Ich stimme zu, das dies nicht viel sinn macht, wenn man nur einen NAS Dienst hat. Dennoch gibt es gründe, die für eine Firewall als Router auf einem Server sprechen: 1) Ein PC Hat in der Regel sehr viel mehr RAM, und dies ist bei Komplexen Firewalls die Contentfilter etc. enthalten durchaus relevant. 2) Praktisch jede Firewall kann mit qemu als Emulation gestartet werden. Wenn man spezielle hardware für die Firewall/Router nimmt kann es passieren, das man einige Treiber erst nachinstallieren muss, etc. 3) Geld Sparen. Ich habe alle meine Services (HTTP, DNS, Druckserver, Samba, Mailserver, etc.) in unterschiedliche LXC Container gepackt, aus Sicherheitsgründen und um diese schnell ersetzen, löschen und wiederherstellen zu können. Ich habe momentan 9 LXC Container und eine Vollvirtualisierung (die Firewall, pfSense), verteilt auf 4 Netzwerke, von welchen 2 nur virtuell existieren. Ich hätte weder genug Geräte noch genug Netzwerkanschlüsse um wenigstens einen PC pro Netzwerk aufzustellen. (aber ich habe einen Separaten für das Backup aufgestellt, denn wen jemand auf das Hostsystem kommt wäre sonst alles verloren). Als Nachteile sehe ich folgendes: 1) Wenn das Hostsystem gehackt wird sind alle sich darauf befindenden Daten, Services, Container, VMs, etc. auch betroffen. 2) PCs haben für gewöhnlich nicht besonders viele Netzwerkanschlüsse. 3) Der administrative Aufwand steigt, und wenn das Hostsystem versagt sind alle Services betroffen. Tipp: Ich empfehle einen PC mit VT-D oder IOMMU zu nehmen, weil man dann die Netzwerkkarten direkt der Firewall VM übergeben kann und der Kernel des Hostsystems dann vollständig von diesen abgeschirmt ist.
Daniel A. schrieb: > und dies ist bei Komplexen Firewalls die Contentfilter etc. enthalten > durchaus relevant. Welche komplexen Anforderungen, die den typischen 08/15-Haushaltsrouter überfordern, hast Du denn? Wie fett ist die Anbindung ans Internet, die da durch muss?
Rufus Τ. F. schrieb: > Daniel A. schrieb: >> und dies ist bei Komplexen Firewalls die Contentfilter etc. enthalten >> durchaus relevant. > > Welche komplexen Anforderungen, die den typischen 08/15-Haushaltsrouter > überfordern, hast Du denn? Wie fett ist die Anbindung ans Internet, die > da durch muss? Ein ganz simples IDS + IPS.
Guest schrieb: > Spricht also wirklich nichts für eine extra NAS von der Sicherheit her? Eigentlich spricht alles dafür. Erstens die Sache mit dem Firewalling. Um die Angriffsoberfläche möglichst gering zu halten, sollte ein Firewall so restriktiv und so klein wie nur irgend möglich konfiguriert sein. Das heißt: ein Firewall ist ein Firewall und nur ein Firewall. Jeder zusätzliche Dienst auf dem Firewall erhöht die Komplexität des Gesamtsystems, und damit die Angriffsoberfläche sowie die Fehlerwahrscheinlichkeit. Idealerweise läuft ein Firewall daher von einem ReadOnly-Medium mit einem gehärteten, genau auf die Hardware abgestimmten Kernel, der keine Module laden kann, sowie einem gehärteten und zusätzlich auf das absolut nötige Minimum beschränkten Minimalsystem. So macht es ja auch IP Fire -- wobei dort die Konfigurationssoftware sowie ausgewählte Module etwa für Proxy, VPN etc. installiert sind. Das ist zwar ein Widerspruch zur reinen Lehre, aaaber: das Ziel des Projekts ist ja ein möglichst einfach konfigurierbares und auch für einen Anfänger benutzbares System, und, ehrlich gesagt: das ist immer noch viel, viel besser als kein oder gar ein flashc konfigurierter Firewall. Wenn Du also nicht gerade ein erfahrener Linux-Admin mit fortgeschrittenen Kenntnissen und viel Übung im Erstellen von Firewall-Konfigurationen bist, solltest Du lieber IP Fire auf einer dedizierten Hardware benutzen, als zu versuchen, selbst etwas von Hand zu stricken. Zweitens hat Benutzerinteraktion jeder Art auf einem Firewall prinzipiell nichts zu suchen, ebenso NAS-Dienste, Tvheadend, Owncloud und Ähnliches. Auf meinen Firewalls läuft nicht einmal der SSH-Server. Denn bereits ein kleiner Konfigurations- oder Softwarefehler kann dazu führen, daß Dein ganzes schönes Firewallkonzept umgangen wird. Nun verstehe ich zwar Dein Anliegen, daß Du Strom sparen und daher viele Funktionen auf einem Gerät vereinen möchtest. Das kannst Du machen, kein Problem, aber wenn Du besonderen Wert auf Sicherheit legst, gehört Dein Firewall auf dedizierte Hardware und die anderen Dienste auf eine zweite. Ich persönlich würde einen Firewall auch nicht in einer Virtualisierung betreiben wollen, sondern immer nur auf dedizierter Hardware. Diese Hardware muß natürlich leistungsfähig genug sein, um den Durchsatz des Netzwerks nicht zu beeinträchtigen. Als Faustregel gilt: für einen Paketfilter reichen etwa 10 MHz pro MBit Netzwerkbandbreite, für einen Proxy je nach Umfang der Filterregeln etwa 100 MHz pro MBit. Ok, soviel zur "Reinen Lehre" (tm). Nein, Paranoia ist bei Admins keine Berufskrankheit, sondern Einstellungsvoraussetzung. ;-) Wie dem auch sei: im Prinzip würde ich Dir empfehlen, IP Fire auf einer dedizierten Hardware aufzusetzen und NAS und Tvheadend auf einem anderen System. Das zu dimensionieren, ist allerdings eine Kunst und hängt davon ab, was Du damit machen willst. NAS braucht meist nicht viel Leistung, Tvheadend schon ein bisschen mehr, aber wenn Du eventuell auch einmal Zoneminder oder motion nutzen willst, solltest Du in eine entsprechend leistungsfähige Hardware investieren.
Peter II schrieb: > john schrieb: >> Ein ganz simples IDS + IPS. > > und was soll das heute bei https noch bringen? SSL ist doch kein Problem. Die Firewall muss einfach als Certificate Authority arbeiten, und die muss man bei den restlichen Geräten eintragen. Schon kann die Firewall alles Entschlüsseln, ein Zertifikat ausstellen, und damit wieder verschlüsseln.
Daniel A. schrieb: > SSL ist doch kein Problem. Die Firewall muss einfach als Certificate > Authority arbeiten, und die muss man bei den restlichen Geräten > eintragen. Schon kann die Firewall alles Entschlüsseln, ein Zertifikat > ausstellen, und damit wieder verschlüsseln. genau und damit holt man sich mehr Probleme als Lösungen: http://www.heise.de/security/meldung/Studie-TLS-Proxies-bringen-Sicherheitsprobleme-3197932.html Sheeva P. schrieb: > Erstens die Sache mit dem Firewalling. Um die Angriffsoberfläche > möglichst gering zu halten, sollte ein Firewall so restriktiv und so > klein wie nur irgend möglich konfiguriert sein. Das heißt: ein Firewall > ist ein Firewall und nur ein Firewall. Jeder zusätzliche Dienst auf dem > Firewall erhöht die Komplexität des Gesamtsystems, und damit die > Angriffsoberfläche sowie die Fehlerwahrscheinlichkeit. Idealerweise > läuft ein Firewall daher von einem ReadOnly-Medium mit einem gehärteten, > genau auf die Hardware abgestimmten Kernel, der keine Module laden kann, > sowie einem gehärteten und zusätzlich auf das absolut nötige Minimum > beschränkten Minimalsystem. ja, die Theorie ist gut. Aber die Praxis sieht leider so aus, das niemand versucht eine Firewall anzugreifen. man schickt den Benutzer eine email mit einer exe/SCR/PDF/jar und schon ist man auf dem PC. Das spielt es überhaupt keine Rolle wie sicher deine Firewall ist. Oder man legt einen Manipulierten USB stick vor die Tür, es gibt genug Möglichkeiten. Wenn die Firewall alles von außen blockt, was soll es dann für ein Sicherheits-Problem sein, wenn ein SSL läuft? Klar wenn die Firewall ein Bug hat dann kommt man auf den SSH Server, aber auch auf jeden Anderen SSH Server im Netzt.
Peter II schrieb: > [...] die Praxis sieht leider so aus, das > niemand versucht eine Firewall anzugreifen. man schickt den Benutzer > eine email mit einer exe/SCR/PDF/jar und schon ist man auf dem PC. Das > spielt es überhaupt keine Rolle wie sicher deine Firewall ist. > > Oder man legt einen Manipulierten USB stick vor die Tür, es gibt genug > Möglichkeiten. Danke für die Hinweise. Aber glaubst Du, daß jemand so einen Abschnitt über Firewalls und Firewall-Setups schreiben kann, der das nicht weiß? > Wenn die Firewall alles von außen blockt, Wenn der Firewall alles von außen blockt, kommt nicht einmal ein TCP Handshake zustande. Möchtest Du über stateful packet inspection reden? > was soll es dann für ein Sicherheits-Problem sein, wenn ein SSL läuft? Was haben die Filterregeln des Firewall mit TLS zu tun? Oder gar mit SSL? > Klar wenn die Firewall ein Bug hat dann kommt man auf den SSH Server, > aber auch auf jeden Anderen SSH Server im Netzt. Es ist im besten Falle leichtsinnig, sich nur auf eine Sicherheitsschicht zu verlassen.
Sheeva P. schrieb: > Danke für die Hinweise. Aber glaubst Du, daß jemand so einen Abschnitt > über Firewalls und Firewall-Setups schreiben kann, der das nicht weiß? ja, teilweise. Es gibt viele Dokumente im Netz die einfach nicht mit der Zeit angepasst wurden. Da steht auch gleich mal etwas über Host Umgebungen mit Großrechnern. Die ganze Thema mit angriffen aus dem Netz hat sich doch in den letzten Jahre geändert. Schau doch mal die Meldungen über Hacks bei Firmen an, das geht der Angriff fast immer von einen Abeitsplatz-PC aus der übernommen wurde.
Peter II schrieb: > Die ganze Thema mit angriffen aus dem Netz hat sich doch in den letzten > Jahre geändert. Gewiss, aber das bedeutet nicht, daß man bei den grundlegenden Selbstverständlichkeiten darauf verzichten kann, sie sicher zu halten. Die geänderten Angriffe machen nur zusätzliche Sicherheitsmechanismen erforderlich, sie erlauben keinen Ersatz.
Rufus Τ. F. schrieb: >> Die ganze Thema mit angriffen aus dem Netz hat sich doch in den letzten >> Jahre geändert. > > Gewiss, aber das bedeutet nicht, daß man bei den grundlegenden > Selbstverständlichkeiten darauf verzichten kann, sie sicher zu halten. > Die geänderten Angriffe machen nur zusätzliche Sicherheitsmechanismen > erforderlich, sie erlauben keinen Ersatz. ja, damit hast du recht. Aber es bringt am ende nichts an eine Tür noch das 10. gehärte Schloss anzubringen wenn daneben das Holztor unverschlossen ist. Ich kenne auch Dokumente wie fordern 2 Firewalls, eine vor der DMZ und eine nach der DMZ. Diese sollen auch mit 2 verschieden Betriebssystem laufen. Warum wird das nicht gleich für zu hause empfohlen, wenn es doch so viel sicherer ist.
Peter II schrieb: > Ich kenne auch Dokumente wie fordern 2 Firewalls, eine vor der DMZ und > eine nach der DMZ. Diese sollen auch mit 2 verschieden Betriebssystem > laufen. Vorausgesetzt man hat eine komplexe interne Netzstruktur ... > Warum wird das nicht gleich für zu hause empfohlen, wenn es doch so viel > sicherer ist. ... was allerdings beim Heimanwender üblicherweise nicht der Fall ist. Es kann allerdings auch für Heimanwender sicherer sein, den ausgehenden Traffic nicht wie üblich pauschal zuzulassen. Einerseits, um sich um Spionagewanzen wie moderne Fernseher zu kümmern. Andererseits um den C&C Traffic mancher Botnetze und Trojaner zu blockieren.
:
Bearbeitet durch User
Peter II schrieb: > Ich kenne auch Dokumente wie fordern 2 Firewalls, eine vor der DMZ und > eine nach der DMZ. Diese sollen auch mit 2 verschieden Betriebssystem > laufen. > Warum wird das nicht gleich für zu hause empfohlen, wenn es doch so viel > sicherer ist. Weil es zu teuer ist. Weil der durchschnittliche Heimanwender mit dem Konzept überfordert ist. Dazu gehört, dass vom durchschnittliche Heimanwender geliebte Anwendungen nicht ohne zusätzlichen Aufwand funktionieren und das geht ja mal gar nicht ... Bequemlichkeit geht ueber Sicherheit. Was dem durchschnittliche Heimanwender heute bei den üblichen Plastik-Routern den Popo rettet ist für eingehenden Traffic nicht die Firewall(simulation) des Plastik-Routers. Es ist das bei Experten so furchtbar verhasste NAT. Die ganzen offenen Ports der Spielzeuge im LAN sind dank verhasstem NAT erst einmal nicht im Internet zu finden. Mit IPv6 wird sich das ändern und der direkte Angriff auf Geräte im LAN wird neuer Volkssport werden. Nicht das es die Angriffe heute nicht gibt. Jeder der einen offenen Port im Internet hängen hat sieht ein paar tausend Angriffe pro Tag. Die meisten mittels gängiger Exploit-Kits und nicht sehr geschickt. So, und jetzt sind wir beim NAS. Ein NAS vom öffentlichen Internet zugängig zu machen heißt man stellt ein oder mehrere Server ins Internet. NAS von der Stange sind normalerweise nicht gehärtet. Die taugen nichts um aus dem öffentlichen Internet zugängig zu sein. Da laufen veraltete Betriebssysteme mit veralteten Versionen von Serversoftware drauf, mit Fehlern, nach denen fertige Exploit-Kits suchen. Da lohnt es sich wirklich über vernünftige Serverssoftware nachzudenken, die man absichert und das Ganze so zu gestalten, dass der Schaden beim Hack eines Servers minimiert wird. Stellt man zur Absicherung die Server in ein separates Subnetz hat man allerdings das Problem, dass im Heimnetz beliebter Mist wie DLNA nicht routebar ist. Also muss man wieder tricksen, oder man kommt zu dem Punkt separate Server für das Internet (warum nicht irgendwo bei einem Hoster?) und das LAN zu betrieben. Es ist alles nicht schön.
Jay schrieb: > Mit IPv6 wird sich das ändern > und der direkte Angriff auf Geräte im LAN wird neuer Volkssport werden. nein, weil in dem Zuge die Billigen Router auch keine eingehenden Verbindungen von Außen akzeptieren. Das ist bei dem meisten heute schon der Fall, denn auch dort muss man Ports freischalten die von außen erreichbar sein sollen. > So, und jetzt sind wir beim NAS. Ein NAS vom öffentlichen Internet > zugängig zu machen heißt man stellt ein oder mehrere Server ins > Internet. NAS von der Stange sind normalerweise nicht gehärtet. Die > taugen nichts um aus dem öffentlichen Internet zugängig zu sein. Da > laufen veraltete Betriebssysteme mit veralteten Versionen von > Serversoftware drauf, mit Fehlern, nach denen fertige Exploit-Kits > suchen. niemand hat geschrieben, das sein NAS von außen erreichbar sein soll.
Jay schrieb: > Es ist das bei Experten so furchtbar verhasste NAT. > > Die ganzen offenen Ports der Spielzeuge im LAN sind dank verhasstem NAT > erst einmal nicht im Internet zu finden. Mit IPv6 wird sich das ändern > und der direkte Angriff auf Geräte im LAN wird neuer Volkssport werden. Eine Firewall, auch das was in Home-Routern drin steckt (*), sollte ohne anderslautende Konfiguration keinen Traffic von draussen nach drinnen durchlassen, der von draussen ausgelöst wird. Der Unterschied zwischen IPv4 mit NAT und IPv6 ohne NAT ist so gesehen nur die Art, wie interne Services vom Router für externe Zugriffe geöffnet werden. Ob Portforwarding in IPv4 oder Adresse/Port-Freischaltung in IPv6. Ist auch nicht so, dass IPv6 erst in der Zukunft käme. Mindesten die Kunden von Internet per TV-Kabel kriegen schon eine Weile IPv6 DSlite, d.h. haben selbst nur IPv6 und einen Tunnel zum Carrier-Grade-NAT für IPv4. Mit den Nebeneffekten, dass man (1) selbst keine IPv4 Dienste anbieten kann, ohne über externe Dienstleister zu gehen und man (2) die gleiche IPv4 Adresse wie tausend andere Kunden hat und diese Adresse deshalb ab und zu auf einer schwarzen Liste landet. *: Da in diesen Tierchen üblicherweise ein Linux drin steckt, wird da wohl genauso die übliche Linux-Technik für Firewalls genutzt, wie in Firewall-Distros/Appliances auf Linux Basis. Und zwar nicht erst seit IPv6. Riskant sind ab Werk hauptsächlich offene Ports des Routers selbst, für Fernkonfiguration, NAS-Dienste etc.
:
Bearbeitet durch User
Peter II schrieb: > genau und damit holt man sich mehr Probleme als Lösungen: > > http://www.heise.de/security/meldung/Studie-TLS-Pr... Nichts für ungut, aber lern erstmal Lesen. In Deinem Link geht es um lokale Software-Proxies, die auf dem PC laufen. Dass die unsicher sind, ist schon seit Jahren bekannt. Hier geht es aber um eine externe Firewall, die den SSL-Verkehr durchleuchtet. Und damit besteht kein Unterschied mehr zwischen HTTP und HTTPS.
john schrieb: > Peter II schrieb: >> genau und damit holt man sich mehr Probleme als Lösungen: >> >> http://www.heise.de/security/meldung/Studie-TLS-Pr... > > Nichts für ungut, aber lern erstmal Lesen. > In Deinem Link geht es um lokale Software-Proxies, die auf dem PC > laufen. Dass die unsicher sind, ist schon seit Jahren bekannt. scheinbar hast du das Problem überhaupt nicht verstanden. Der Browser kann dann keine Zertifikate mehr prüfen, CA-Pinning funktioniert nicht mehr. Es können keine Fingerprints mehr von Anwender geprüft werden. Es kann nicht mehr geprüft werden welche Verschlüsselung zum Einsatz kommt. Und dabei spielt es keine Rolle ob der Proxy auf dem PC oder extern ist. scheinbar kann ich doch lesen...
A. K. schrieb: > Ist auch nicht so, dass IPv6 erst in der Zukunft käme. Mindesten die > Kunden von Internet per TV-Kabel kriegen schon eine Weile IPv6 DSlite, > d.h. haben selbst nur IPv6 und einen Tunnel zum Carrier-Grade-NAT für > IPv4. Mit den Nebeneffekten, dass man (1) selbst keine IPv4 Dienste > anbieten kann, ohne über externe Dienstleister zu gehen und man (2) die > gleiche IPv4 Adresse wie tausend andere Kunden hat und diese Adresse > deshalb ab und zu auf einer schwarzen Liste landet. Jeder Telekom-Full-IP-Kunde hat das, und zwar Dual-Stack (/56 bei v6), und das sind sicherlich nicht wenige - auch ich gehöre dazu. Fing 2012 an.
Peter II schrieb: > Der Browser kann dann keine Zertifikate mehr prüfen, CA-Pinning > funktioniert nicht mehr. In gewisser Weise funktioniert das wie es soll. Keine Verbindung, weil falsch identifizierte Gegenstelle. Folglich muss man diese Verbindungen vom Verfahren ausschliessen. In gepflegter Umgebung machbar, als Teil einer Homeumgebung eher nicht.
A. K. schrieb: >> Der Browser kann dann keine Zertifikate mehr prüfen, CA-Pinning >> funktioniert nicht mehr. > > In gewisser Weise funktioniert das wie es soll. Keine Verbindung, weil > falsch identifizierte Gegenstelle. Folglich muss man diese Verbindungen > vom Verfahren ausschliessen. In gepflegter Umgebung machbar, als Teil > einer Homeumgebung eher nicht. Auch in gepflegter Umgebung dürften die meisten Google Tools Alarm schlagen, weil das Zertifikat von Google nicht genutzt wird. Und spätesten wenn jemand client-Zertifikate einsetzt geht es nicht mehr mit dem Proxy.
john schrieb: > Jeder Telekom-Full-IP-Kunde hat das, und zwar Dual-Stack Klar, bei Dual Stack gehts. Nur eben nicht bei Dual Stack lite, wie das die Kabler nach Hause liefern. Hängt wohl davon ab, wie die Situation bei den IPv4 Adressen ist. Die Telekom ist schon länger im Geschäft und dürfte davon recht viele haben. Zumeist dürfte in deren Umgebung ein alter IPv4 durch einen neuen DS Anschluss ersetzt werden, d.h. die Anzahl ändert sich nicht gross. Die Kabler wie Unitmedia sind dagegen vergleichsweise neu im Geschäft und die entfallenden IPv4 Adressen der durch sie abgelösten DSL Provider gehören ihnen nicht. Folglich sind die Kabler etwas knapp an IPv4 Adressen. Bei einem aktuellen Business-Anschluss von Unitmedia kosten 5 statt 1 IPv4 stolze 30€/Monat und für Privat gibts auch gegen Geld keine. Ist halt mitunter eine Frage der Priorität. Beispielsweise 6Mb/s mit dynamischer IPv4 oder 120Mb/s ganz ohne eigene IPv4 (und 3€/Jahr pro Proxy-Port beim Dienstleister).
:
Bearbeitet durch User
Peter II schrieb: > Auch in gepflegter Umgebung dürften die meisten Google Tools Alarm > schlagen, weil das Zertifikat von Google nicht genutzt wird. Deshalb ja "gepflegt". Denn da sitzt dann ein Admin und pflegt. ;-)
Hallo! Das habe ich schon befürchtet, dass mein Plan des universal-Servers nicht aufgehen wird. Trotzdem danke für alle Tipps! Gruß
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.