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.
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)
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.htmlSheeva 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.
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.
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).
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. ;-)
