Hi zusammen, ich kann auf meinen Raspi (welch Wunder) per ssh zugreifen. Dank Portweiterleitung und no-ip.org kann ich meinen "Server" auch von außerhalb des Heimnetzes erreichen. Nun ist mir beim Studieren der /var/log/auth.log aufgefallen, dass ich viele Angriffe mit IPs aus China, Korea etc. abkriege. Vermutung: das ist normal, sobald man ein Gerät im Netz hat, richtig? Was macht ihr um eure Geräte zu sichern? Bisher hab ich nur Passwort-Login abgeschalten, sodass man nur noch mit RSA-Key draufkommt, wobei ich zusätzlich noch eine Passphrase verwende. Was ich noch vorhabe: Username ändern. Der Standarduser "pi" ist wohl recht bekannt. Port von 22 auf einen selbst gewählten ändern fail2ban? Gibt es sonst noch etwas, auf das ich achten sollte? Grüße
login nur mit key ist schonmal sehr gut. den Port verschieben ist unsinn, das ist so kilfrech wie der Haustürschlüssel statt unter der Fussmatte unter dem Blumentopf aufzubewahren :) Fail2ban ist auf jeden fall hilfreich, das ist ja auch schon gut vorkonfiguriert. Wenn ssh dein einziger Zugang zu der Kiste ist bist du damit auch schon gut dabei.
Benji schrieb: > Vermutung: das ist normal, sobald man ein Gerät im Netz hat, richtig? Richtig. > Port von 22 auf einen selbst gewählten ändern Kann helfen, zumindest um das Logfile deutlich kürzer zu halten. Der 22er ist einer der ersten beim Scan. > Gibt es sonst noch etwas, auf das ich achten sollte? News lesen und den openssh-server aktuell halten. Da sind in den letzten Jahren immer mal Löcher aufgetaucht.
IPv6 verwenden. Seit dem ich das habe sind die Zugriffe nahezu 0.
Allenfalls ein blockfeature ? Nach 3(n..) falschen Logins wir die betreffende IP fuer 3(n..immer) Minuten gesperrt...
Oliver S. schrieb: > IPv6 verwenden. Seit dem ich das habe sind die Zugriffe nahezu 0. Muss er am anderen Ende aber auch können. Die hiesigen Mobilnetze sind jedenfalls noch nicht so weit.
Benji schrieb: > Dank Portweiterleitung und no-ip.org kann ich meinen "Server" auch von > außerhalb des Heimnetzes erreichen. Wenn auch häufig praktiziert, weil einfach, ist es niemals eine gute Idee, Geräte mittels Portforwarding direkt ans Internet zu hängen. Außer man möchte explizit, daß die ganze Welt drauf zugreifen kann. > Was macht ihr um eure Geräte zu sichern? Router mit IPSec VPN.
Benji schrieb: > Gibt es sonst noch etwas, auf das ich achten sollte? Veraltete SSL Verfahren deaktivieren. Also alles vor TLS 1.2.
A. K. schrieb: > Icke ®. schrieb: >> Router mit IPSec VPN. > > Und was ist daran sicherer als SSH mit RSA? Ich hab ja schon von Leuten gehört die ihr VPN durch ssh tunneln weil sie ihren vpnd nicht trauen, aber ssh durch nen vpn aus dem selben Grund ist mir neu...
Servernetz und Heimnetz trennen. Falls der Raspi doch kompromittiert wird, bleibt der private Bereich geschützt. Entweder über einen zweiten alten Router, der noch irgendwo rumliegt oder ein VLAN. Router mit echter DMZ für den Privatbereich sind ja leider Mangelware.
Ich habe alle meine Server (NAS, Rspberry Pi & co.) nur noch im Heimnetz verfügbar gemacht -> Keine Portweiterleitung! Von außen komme ich dann ganz einfach per VPN ran. Funktioniert mit dem Android handy genauso wie mit dem MacBook. Per FritzBox ist das sehr einfach eingerichtet...
A. K. schrieb: > Icke ®. schrieb: >> Router mit IPSec VPN. > > Und was ist daran sicherer als SSH mit RSA? Vom Protokoll her nichts. Es geht darum, den Angriff frühestmöglich abzublocken. Und die erste Tür zum Netzwerk ist nun mal der Router. Die Zugriffe zu den Geräten extra abzusichern, schafft zusätzliche Sicherheit, dann müssen schon zwei Hürden überwunden werden.
Icke ®. schrieb: > A. K. schrieb: >> Icke ®. schrieb: >>> Router mit IPSec VPN. >> >> Und was ist daran sicherer als SSH mit RSA? > > Vom Protokoll her nichts. Es geht darum, den Angriff frühestmöglich > abzublocken. Und die erste Tür zum Netzwerk ist nun mal der Router. Die > Zugriffe zu den Geräten extra abzusichern, schafft zusätzliche > Sicherheit, dann müssen schon zwei Hürden überwunden werden. Naja, wenn ich im vpn bin, bin ich im Sicheren Netz, das war eine Hürde bis ins sichere Netz. Ich kann da keine weitere Hürde erkennen.
:
Bearbeitet durch User
Dirk D. schrieb: > Naja, wenn ich im vpn bin, bin ich im Sicheren Netz, das war eine Hürde > bis ins sichere Netz. Zum Vergleich, du stehst jetzt im Hausflur. Das nützt allein noch nicht viel, wenn die Türen innen zusätzlich abgeschlossen sind. Zum Beispiel so: Benji schrieb: > Bisher hab ich nur Passwort-Login abgeschalten, sodass man nur noch mit > RSA-Key draufkommt, wobei ich zusätzlich noch eine Passphrase verwende.
Icke ®. schrieb: > Dirk D. schrieb: >> Naja, wenn ich im vpn bin, bin ich im Sicheren Netz, das war eine Hürde >> bis ins sichere Netz. > > Zum Vergleich, du stehst jetzt im Hausflur. Das nützt allein noch nicht > viel, wenn die Türen innen zusätzlich abgeschlossen sind. Zum Beispiel > so: > > Benji schrieb: >> Bisher hab ich nur Passwort-Login abgeschalten, sodass man nur noch mit >> RSA-Key draufkommt, wobei ich zusätzlich noch eine Passphrase verwende. Na ist der Hausflur jetzt ne Interne oder ne Externe Zone? Ist es für dich okay, wenn jemand in dein Internes Netz kommt? Sind alle Geräte und alle Dienste auf diesen Geräten darin abgesichert? Dein Fernseher zum Beispiel oder das Webinterface deines Router, ist das mit einem Sicheren Passwort gesichert? Üblicherweise betrachtet man das nicht so, kann aber sein das du da eine Andere Ansicht hast. Aber wenn das so ist, warum dann überhaupt vpn? Lass doch einfach deine Haustür offen, du hast ja noch Wohnungtüren, ist doch egal...
Ich weiss ja nicht, ob ihr es impliziet zum fail2ban zugehörend seht, und es deshalb nicht genannt wird. iptables konfigurieren. Denn mit fail2ban allein, werden zwar gewisse Ports überwacht und gesperrt, wenn ein Angriff festgestellt wird. Aber eigentlich ist der Rechner noch offen wie ein Scheunentor ohne Firewall.
Eine vorgeschaltete VPN ist genau und nur dann eine effektive zusätzliche Hürde, wenn (auf diesen Fall bezogen) ausschliesslich der SSH-Zugang zum adressierten System von der VPN freigegeben wird. Und nicht das gesamte Zielsystem oder gar dessen gesamtes lokale Netz. Einfach gestaltete VPN-Techniken wie in den Fritzboxen geben das m.W. nicht her, sondern öffnen das lokale Netz. Dann ist es egal wie sicher das SSH des Zielsystems ist, wenn der Rest dieses Netzes nicht den gleichen Sicherheitsstandard wie das SSH hat. Was bei 08/15 Heimnetzen wohl kaum der Fall ist. Da findet man dann, um in deinem Bild zu bleiben, genau eine verschlossene Tür in Form des SSH, und sonst allenfalls Vorhänge (*). Sicherheit entsteht bei der VPN also nur, wenn diese erste Hürde nur den Zugang zur zweiten Hürde öffnet. Und nicht das Netz. *: Ein Netzwerkdrucker kann ein solcher Vorhang sein. Kein Witz. An solche Mistviecher denkt kaum einer, aber da ist heute oft auch ein Linux drauf, aber sperrangelweit offen und nie updated. Gibt einen prima Brückenkopf ab.
:
Bearbeitet durch User
Dirk D. schrieb: > Ist es für dich okay, wenn jemand in dein Internes Netz kommt? Keinesfalls. Was verstehst du nicht an: Icke ®. schrieb: > Router mit IPSec VPN. Zu einfache Schlüssel ausgenommen, gilt IPSec (noch) als sicher. > Dein Fernseher zum Beispiel oder das Webinterface deines Router, ist das > mit einem Sicheren Passwort gesichert? Wo das möglich ist, selbstverständlich. > Üblicherweise betrachtet man das nicht so, kann aber sein das du da eine > Andere Ansicht hast. Die Frage war nicht, was der Durchschnittsuser als üblich betrachtet, sondern wie das Netzwerk sicherer wird.
A. K. schrieb: > Eine vorgeschaltete VPN ist genau und nur dann eine effektive > zusätzliche Hürde, wenn (auf diesen Fall bezogen) ausschliesslich der > SSH-Zugang zum adressierten System von der VPN freigegeben wird. Und > nicht das gesamte Zielsystem oder gar dessen gesamtes lokale Netz. Absolut richtig. Genau deswegen definiere ich per Firewallregeln, was die einzelnen VPN-Zugänge dürfen und was nicht. Als Admin benötige ich natürlich netzweiten Zugriff, für einen ASP-User muß es bspw. nicht mehr sein als Port 3389 auf den Terminalserver. > Einfach gestaltete VPN-Techniken wie in den Fritzboxen geben das m.W. > nicht her, sondern öffnen das lokale Netz. Ich habe nicht behauptet, daß jede Consumerkiste geeignet ist. Für gute Sicherheit muß man eben etwas mehr Geld ausgeben.
Icke ®. schrieb: > Ich habe nicht behauptet, daß jede Consumerkiste geeignet ist. Für gute > Sicherheit muß man eben etwas mehr Geld ausgeben. Wir drehen uns im Kreis, was genau ist an deiner vorgeschlagenen Lösung jetzt in der Praxis besser als nen ssh nach draussen weiter zu reichen?
Dirk D. schrieb: > Wir drehen uns im Kreis, was genau ist an deiner vorgeschlagenen Lösung > jetzt in der Praxis besser als nen ssh nach draussen weiter zu reichen? Was hält Einbrecher länger auf, Haus- UND Wohnungstür abzusperren oder nur die Wohnungstür?
Bevor der Thread komplett abdriftet: Ich bedanke mich für die konstruktiven Antworten und halte fest, dass ich grundsätzlich auf dem richtigen Weg bin. Ich hatte da gerade so einen Gedankengang: Gegeben sei ein Raspberry Pi mit jungfräulichem Raspbian. Der Standard-Login pi//raspberry ist ja bekannt. Weltweit dürften viele Geräte mit diesem Setup herumstehen, weswegen auszugehen ist dass Botnetze diese Zugangsdaten recht weit oben in ihrem Wörterbuch stehen haben. Wenn ich so einen Pi mittels Portweiterleitung ans offene Netz hänge dann dürfte er ja relativ schnell gekapert und vom Botnetz assimiliert sein, richtig?
Icke ®. schrieb: > Dirk D. schrieb: >> Wir drehen uns im Kreis, was genau ist an deiner vorgeschlagenen Lösung >> jetzt in der Praxis besser als nen ssh nach draussen weiter zu reichen? > > Was hält Einbrecher länger auf, Haus- UND Wohnungstür abzusperren oder > nur die Wohnungstür? wenn er genau auf den pi will wohl beides, wenn du genau das schützen willst hast du recht. wenn du deine komplette Infrastruktur zuhause als schützenswert betrachtest ist es egal ob der einbrecher durchs ssh-Fenster direkt ins pi-Zimmer einbricht, oder durch die vpn-haustür zum unverschlossenen keller kommt und fahrräder klaut.
Decius schrieb: > Ich weiss ja nicht, ob ihr es impliziet zum fail2ban zugehörend seht, > und es deshalb nicht genannt wird. iptables konfigurieren. Denn mit > fail2ban allein, werden zwar gewisse Ports überwacht und gesperrt, wenn > ein Angriff festgestellt wird. Aber eigentlich ist der Rechner noch > offen wie ein Scheunentor ohne Firewall. Es ist ohnehin nur der SSH-Port exponiert -- und "offen wie ein Scheunentor" wäre der Rechner nur, wenn dort ungesicherte Server laufen würden.
A. K. schrieb: > Einfach gestaltete VPN-Techniken wie in den Fritzboxen geben das m.W. > nicht her, sondern öffnen das lokale Netz. Das gilt mittelbar auch für SSH (man ssh /-L).
@Sheeva Plug: >"Es ist ohnehin nur der SSH-Port exponiert -- und "offen wie ein >Scheunentor" wäre der Rechner nur, wenn dort ungesicherte Server laufen >würden." Ok, ich kenn den Raspy und daher dort die Defaulteinrichtung jetzt nicht. Bei mir war es letztenz beim Aufsetzen eines dedicated Linux-Servers einfach so. Das bei diesem per Default keine Firewall aktiv war. Fail2ban verschliesst in so einem Fall allein nicht die offenen Ports, es überwacht lediglich die in /etc/fail2ban/jail.local freigegebenen Ports, und sperrt diese gegebenenfalls. 1. Was meinst du mit "exponiert"? 2. Was meinst du mit "ungesicherte Server laufen würden"? Stichwort Login? Würde dann dennoch sagen, das es besser ist, offene ungenutzte Ports mit einer Firewall zu verschliessen.
Sheeva P. schrieb: > Das gilt mittelbar auch für SSH (man ssh /-L). Ja, ist hier aber nicht der Punkt. Es ging darum, ob es sich bei einer nicht speziell auf Zieladresse und Port konfigurierten VPN um zwei nacheinander zu überwindende effektive Hürden handelt. Und das ist nicht der Fall. Bist du in einer solchen Konfiguration durch die VPN durch, ist das Netz offen und SSH als Hürde wahrscheinlich irrelevant. Gibt es Portforwarding auf SSH ohne solche VPN und du bist im SSH drin, dann ist das Netz ebenfalls offen. Es handelt sich also in beiden Fällen um lediglich eine effektive Hürde. Diese Art unspezifischer VPN bringt folglich keine wesentliche zusätzliche Sicherheit gegenüber Portforwarding auf ein sauber konfiguriertes SSH. Wenn eine VPN eine echte zweite Hürde bringen soll, dann reicht eine solche einfache VPN Definition nicht aus, und eine feiner konfigurierbare Firewall wird erforderlich.
:
Bearbeitet durch User
>..., es überwacht lediglich die in /etc/fail2ban/jail.local >freigegebenen Ports, und sperrt diese gegebenenfalls. ungünstig geschrieben. ..., es überwacht lediglich die in /etc/fail2ban/jail.local freigegebenen Jails, und sperrt diese gegebenenfalls. wäre sicher korrekter.
Decius schrieb: > @Sheeva Plug: >>"Es ist ohnehin nur der SSH-Port exponiert -- und "offen wie ein >>Scheunentor" wäre der Rechner nur, wenn dort ungesicherte Server laufen >>würden." > > Ok, ich kenn den Raspy und daher dort die Defaulteinrichtung jetzt > nicht. Bei mir war es letztenz beim Aufsetzen eines dedicated > Linux-Servers einfach so. Das bei diesem per Default keine Firewall > aktiv war. Fail2ban verschliesst in so einem Fall allein nicht die > offenen Ports, es überwacht lediglich die in /etc/fail2ban/jail.local > freigegebenen Ports, und sperrt diese gegebenenfalls. > > 1. Was meinst du mit "exponiert"? > 2. Was meinst du mit "ungesicherte Server laufen würden"? Stichwort > Login? Würde dann dennoch sagen, das es besser ist, offene ungenutzte > Ports mit einer Firewall zu verschliessen. Ich würde sagen das die Dienste die offene ungenutzte Ports anbieten einfach Runtergefahren werden. Wenn die Dienste zwar gebraucht aber nur intern genutzt werden sollten sie auch nur auf dem Loopback-device lauschen.
Dirk D. schrieb: > Ich würde sagen das die Dienste die offene ungenutzte Ports anbieten > einfach Runtergefahren werden. Das ist selbstredend sinnvoll. Aber nicht immer möglich, weil man manche Dienste netzintern benötigt, die man nicht nach aussen freigeben will. Dann ist eine Filterung innerhalb des Servers schon sinnvoll. Ob das per OS-Firewall oder im Dienst selbst erfolgt ist ein enderes Thema. Allerdings hast du nicht viel davon, wenn das völlig dicht vernagelte Serverlein im gleichen Netz sitzt, wie dein ganzes übriges tendentiell sperrangelweit offenes Inventar im Heimnetz. Im professionellen Umfeld werden nicht zufällig separate Netzsegmente als DMZ für solche Geräte eingerichtet.
Decius schrieb: > 1. Was meinst du mit "exponiert"? Etwa "für einen Angreifer erreichbar". > 2. Was meinst du mit "ungesicherte Server laufen würden"? Stichwort > Login? Ja. > Würde dann dennoch sagen, das es besser ist, offene ungenutzte > Ports mit einer Firewall zu verschliessen. Wozu? Es gibt dafür keinen Grund.
A. K. schrieb: > Bist du in einer solchen Konfiguration durch die VPN durch, ist das Netz > offen und SSH als Hürde wahrscheinlich irrelevant. Gibt es > Portforwarding auf SSH ohne solche VPN und du bist im SSH drin, dann ist > das Netz ebenfalls offen. Das hatte ich gemeint. Wobei ich SSH bei einer Kombination aus VPN + SSH durchaus für eine relevante zweite Hürde halte. Aber wenn nur VPN oder nur SSH benutzt werden, gibt es effektiv nur eine Hürde.
Dirk D. schrieb: > Ich würde sagen das die Dienste die offene ungenutzte Ports anbieten > einfach Runtergefahren werden. > Wenn die Dienste zwar gebraucht aber nur intern genutzt werden sollten > sie auch nur auf dem Loopback-device lauschen. Absolut korrekt. Nicht benötigte Server sollten aber nicht nur gestoppt, sondern komplett deinstalliert werden.
Sheeva P. schrieb: > Das hatte ich gemeint. Wobei ich SSH bei einer Kombination aus VPN + SSH > durchaus für eine relevante zweite Hürde halte. Wenn die Definition der VPN ausschliesslich die gewünschte Kombination aus Zielsystem und Port enthält. Weniger wenn die VPN mangels spezifischer Konfigurationsmöglichkeit das gesamte Netz mit allen Ports öffnet. Einen Vorteil hat eine VPN allerdings: Sie gibt sich nicht als SSH zu erkennen. SSH zieht aufgrund der historischen Löcher die Gauner regelrecht an. Die SSH Signatur abzuschalten gehört zwar zu den gängigen Security Tips, aber solange das im Quellcode hardcoded ist und mindestens die Linux Distris das nicht beherzigen ist dieser Ansatz nur begrenzt praktikabel.
So als 'Security by obscurity' gibt es noch Port Knocking: https://wiki.archlinux.org/index.php/Port_Knocking
A. K. schrieb: > Muss er am anderen Ende aber auch können. Die hiesigen Mobilnetze sind Telekom kann das seit einiger Zeit. Leider nicht im Tethering (oder man muß noch was einstellen). Ansonsten Androiccu und sixxs verwenden.
Das die Telekom im Mobilnetz technisch IPv6 kann glaube ich gern. Aktiviert ist es aber bei mir nicht. Ich vermute auch, dass es einigen Ärger gäbe, wenn es heute queerbeet aktiviert würde. Es gibt mindestens bei einigen Samsungs ein Problem, an denen Hintergrunddienste wie das Google Cloud Messaging und damit WhatsApp scheitern können, wenn sie im IPv6 laufen. Zumindest ist das bei IPv6 im WLAN so.
:
Bearbeitet durch User
Zu IPv6 auf Android Mobilgeräten allgemein: http://www.techrepublic.com/article/androids-lack-of-dhcpv6-support-poses-security-and-ipv6-deployment-issues/ und Samsung im Besonderen: http://developer.samsung.com/forum/board/thread/view.do?boardName=General&messageId=239890 Ein Google-Entwickler erwähnt einen Zusammenhang mit Tethering. Es gäbe einen Konflikt zwischen DHCPv6 und Tethering, weshalb Android auf DHCPv6 verzichtet - und damit anderen Ärger verursacht.
:
Bearbeitet durch User
A. K. schrieb: > Zu IPv6 auf Android Mobilgeräten allgemein: > http://www.techrepublic.com/article/androids-lack-of-dhcpv6-support-poses-security-and-ipv6-deployment-issues/ > und Samsung im Besonderen: > http://developer.samsung.com/forum/board/thread/view.do?boardName=General&messageId=239890 > > Ein Google-Entwickler erwähnt einen Zusammenhang mit Tethering. Es gäbe > einen Konflikt zwischen DHCPv6 und Tethering, weshalb Android auf DHCPv6 > verzichtet - und damit anderen Ärger verursacht. Das heißt aber nicht das es generell ein Problem mit Androiden und ipv6 geben würde. Bis auf einige Gäste mit Samsung-geräten und stock-rom klappt das hier wunderbar mit ipv6 und Android-geräten...
Dirk D. schrieb: > Das heißt aber nicht das es generell ein Problem mit Androiden und ipv6 > geben würde. Bis auf einige Gäste mit Samsung-geräten und stock-rom > klappt das hier wunderbar mit ipv6 und Android-geräten... Es gibt Standards und es gibt Unternehmen wie Google, die sich gross genug wähnen, um ungestraft tricksen zu dürfen. Denn es "geht doch" - zumindest meistens und was kümmert sie der Rest. Kollege Samsung setzt dann auf einen Schelmen anderthalbe und nutzt das aus um konsequent Strom zu sparen. Was kein Thema wär, wenn sie einen LMAA-Knopf zum dauerhaften Abschalten von IPv6 drankleben würden. Aber das trauen sie dann wohl doch nicht, wär ein Bisschen zu symbolisch. Ist ja nicht so, dass nur Samsung-Kunden Ärger mit manchen Android-Hintergrunddiensten haben. Es gibt genug Whatsapper ohne Samsung, die rumfluchen.
:
Bearbeitet durch User
A. K. schrieb: > Dirk D. schrieb: >> Das heißt aber nicht das es generell ein Problem mit Androiden und ipv6 >> geben würde. Bis auf einige Gäste mit Samsung-geräten und stock-rom >> klappt das hier wunderbar mit ipv6 und Android-geräten... > > Es gibt Standards und es gibt Unternehmen wie Google, die sich gross > genug wähnen, um ungestraft tricksen zu dürfen. Denn es "geht doch" - > zumindest meistens und was kümmert sie der Rest. Kollege Samsung setzt > dann auf einen Schelmen anderthalbe und nutzt das aus um konsequent > Strom zu sparen. Was kein Thema wär, wenn sie einen LMAA-Knopf zum > dauerhaften Abschalten von IPv6 drankleben würden. Aber das trauen sie > dann wohl doch nicht, wär ein Bisschen zu symbolisch. > > Ist ja nicht so, dass nur Samsung-Kunden Ärger mit manchen > Android-Hintergrunddiensten haben. Es gibt genug Whatsapper ohne > Samsung, die rumfluchen. Wenn ich das richtig verstehe ist ja nicht so als tricksen sie (google) weil sie kein bock haben oder weil es ihnen vorteile bringt. Die Sache ist ja die: wenn's nen gemischtes Netzwerk ist gibt's keine Probleme, weil dns ja via dhcpv4 übergeben wird. Die Entscheidung ist ja aktuell dhcpv6 nutzen und dafür tethering mit v6 gefährden oder kein dhcpv6 unterstützen und tethering mit v6 lassen. In wie viel gemischten Netzwerken treibst du dich im Alltag rum und in wie vielen v6-only Netzen? Natürlich ist es nicht das Gelbe vom Ei wie es aktuell ist, aber Probleme machen sollte das für ein verschwindend kleinen Teil der Nutzer, und das ist ja auch umschiffbar. Gibts eigentlich auch Nutzer anderer Dienste die über schlechte Konnektivität mit v6 klagen? Ich weiß, ne Sample-Größe im kleinen EInstelligen Bereich sagt nicht viel aus, aber die Hand Voll Dienste ich ich auch über v6 anbiete, jabber z.B. scheinen keine Probleme zu haben, ausser im Samsung-Fall.
Dirk D. schrieb: > Gibts eigentlich auch Nutzer anderer Dienste die über schlechte > Konnektivität mit v6 klagen? > Ich weiß, ne Sample-Größe im kleinen EInstelligen Bereich sagt nicht > viel aus, aber die Hand Voll Dienste ich ich auch über v6 anbiete, > jabber z.B. scheinen keine Probleme zu haben, ausser im Samsung-Fall. Entscheidend ist die Arbeitsweise als Push-Dienst, also Events ausgehend vom Server und nicht vom Client, und dass IPv6 überhaupt verwendet wird. Wenn der Client im Standby permanent darauf wartet, dass der Server sich meldet, ohne dass der Client immer wieder mal aktiv nachfragt. Die üblichen IMAP-Mailclients verbinden sich direkt mit dem Server des Providers und bleiben permanent drin, sofern sie auf Push konfiguriert sind. Solange der Server keine IPv6 Adresse hat, oder das Phone sie mangels lokalem IPv6 Netz nicht nutzt, wird IPv4 verwendet. Wenn Apps keine dauerhafte TCP-Verbindung halten und in grösseren Abständen auch mal im Standby ausgehend vom Server nutzen, ist es ebenso egal. Bei Whatsapp und Threema wird jedoch Google Cloud Messaging verwendet, um die App aufzuwecken. Das spart sowohl den Anbietern als auch im Gerät Resourcen und wär dem Prinzip nach auch mit zunehmend aggressiveren Sparstrategien der Android-Versionen zukunftsträchtig. Diese Apps verbinden sich also nicht permanent mit dem Server, sondern werden vom GCM aufgeweckt. Die GCM-Server haben bereits IPv6 und werden wenn technisch möglich auch so genutzt. Es wird wohl auch andere Apps geben, die GCM in ähnlicher Weise verwenden. Immerhin ist das Googles Standardverfahren. Verzörgerte Syncs oder Updates merkt freilich kaum jemand. Verzögertes Instant Messaging hingegen schon. Es gibt allerdings etliche verschiedene Ursachen für solche Probleme, darunter auch welche, die mit IPv6 nichts zu tun haben.
:
Bearbeitet durch User
Ah okay, das klingt verständlich. Geht den GCM tatsächlich davon aus das der Server den Client direkt erreicht, verstehe ich das richtig? Oder wird da ne Verbindung offen gehalten die im Standby verschütt geht? Das Erstere klingt ja nicht wirklich sinnvoll, nur weil mein Gerät eine eigene IP-Adresse hat heißt es ja nicht das es von draußen erreichbar sein muss.
Dirk D. schrieb: > Die Sache ist ja die: wenn's nen gemischtes Netzwerk ist gibt's keine > Probleme, weil dns ja via dhcpv4 übergeben wird. DHCPv4 übergibt dem Client die Adresse von DNS Servern als IPv4 Adresse. Das hindert den Client aber mitnichten daran, einen solchen DNS Server per IPv4 nach einer IPv6 Adresse zu fragen. Trägerprotokoll und Inhalt sind zwei Paar Stiefel. Auch ein DNS Server ohne eigene IPv6 Adresse kann einem anfragenden System die IPv6 Adresse des abgefragten Systems mitteilen. Das Problem tritt also nicht nur in reinen IPv6 Netzen auf, sondern auch in den üblichen gemischten Netzen. In denen üblicherweise IPv6 Vorrang vor IPv4 hat, wenn die Client-Anwendung beides kann.
:
Bearbeitet durch User
A. K. schrieb: > Dirk D. schrieb: >> Die Sache ist ja die: wenn's nen gemischtes Netzwerk ist gibt's keine >> Probleme, weil dns ja via dhcpv4 übergeben wird. > > DHCPv4 übergibt dem Client die Adresse von DNS Servern als IPv4 Adresse. > Das hindert den Client aber mitnichten daran, einen solchen DNS Server > per IPv4 nach einer IPv6 Adresse zu fragen. Trägerprotokoll und Inhalt > sind zwei Paar Stiefel. Auch ein DNS Server ohne eigene IPv6 Adresse > kann einem anfragenden System die IPv6 Adresse des abgefragten Systems > mitteilen. > > Das Problem tritt also nicht nur in reinen IPv6 Netzen auf, sondern auch > in den üblichen gemischten Netzen. In denen üblicherweise IPv6 Vorrang > vor IPv4 hat, wenn die Client-Anwendung beides kann. Daß ein dns-server unabhänig von protokoll über das mit ihm gesprochen wird einen A oder AAAA Record zurückgibt ist mir klar. Im verlinkten Beitrag ist aber die Rede davon das android in ipv6 Netzen (und nur da) ein Problem hat weil es dhcpv6 nicht unterstützt, und deshalb kein dns-server gesetzt bekommt, was nur ein Problem ist wenn man auch keinen dns-server per dhcpv4 gesetzt bekommt.
Dirk D. schrieb: > Geht den GCM tatsächlich davon aus das der Server den Client direkt > erreicht, verstehe ich das richtig? Ich kenne GCM nicht im Detail, aber das wird nicht viel anders laufen als beim IMAP. Nur eben als globaler Dispacher für alle Anwendungen auf dem Phone, kein Kleinklein für jede App extra. Darf man sich wohl ungefähr so vorstellen: Der Threema-Server hält Kontakt zum GCM-Server. Der Threema-Client meldet sich bei seinem GCM-Service auf dem Phone und teilt mit, dass er sich für das eindeutige Token <X> interessiert. Der GCM-Service auf dem Phone hält eine permanente Verbindung zum GCM-Server ähnlich wie IMAP. Wenn er vom Server das Token kriegt, dann weckt er den schlafenden Threema-Client auf. Der weiss nun, dass er Kontakt zum Threema-Server aufbauen und man nachfragen sollte. > Oder wird da ne Verbindung offen gehalten die im Standby verschütt geht? Ebendies, seitens des GCM. Aber eben nur der GCM, nicht jeder Instant Messenger auf dem Phone eine eigene. Ein weiteres nicht mit IPv6 in Verbindung stehende Problem ergibt sich daraus ganz zwanglos. Sowohl lokale Netze als auch Mobilnetze haben bei IPv4 irgendwo zwischendrin NAT sitzen. Carrier Grade NAT Systeme (DS-lite und Mobilfunk) und Firewalls haben ein gewisses Interesse daran, scheintote Verbindungen irgendwann abzuschiessen, weil die Ressourcen fressen. Wenn dieser Timeout kürzer ist als der Keepalive des Clients, dann klemmt es nicht sofort, aber nach einer Weile. Weshalb es im Play Store und auch im Threema selbst einen "Push Fixer" gibt, der das Intervall verkürzt. Wie das genau mit dem GCM zusammenwirkt weiss ich nicht.
Dirk D. schrieb: > Im verlinkten Beitrag ist aber die Rede davon das android in ipv6 Netzen > (und nur da) ein Problem hat weil es dhcpv6 nicht unterstützt, und > deshalb kein dns-server gesetzt bekommt, was nur ein Problem ist wenn > man auch keinen dns-server per dhcpv4 gesetzt bekommt. Ich steckte da nicht tief genug drin, um wirklich genau antworten zu können.
:
Bearbeitet durch User
Wieder was gelernt, Danke! Ja von dem NAT-Timeout kann ich dir ein Liedchen singen, Im Büro gehen Verbindungen nach draussen durch 2 NAT, das führt zu ganz vielen schlimmen Problemen, insbesondere dann wenn Protokolle Keepalive auf TCP-Ebene machen, weil das ja der Technisch richtige weg ist. Das Funktionier ja auch wunderbar bei einem NAT wenn beide Komunikations-Partner dem NAT mitteilen das die Verbindung nicht tot ist. Wenn man jetzt aber nen Doppeltes NAT hat und man macht TCP-Keepalive stirbt die Verbindung zwischen den beiden NAT-Stellen, die wird ja von niemandem am Leben gehalten :(
Du warst zu schnell für meinen Edit. ;-) Android verwendet kein DHCPv6, kriegt aber trotzdem DNS Server mitgeteilt. Wie das genau erfolgt weiss ich nicht, es ist aber herzlich unwichtig. Vielleicht reichen die Informationen aus dem ja vorhandenen DHCPv4 und in einem reinen IPv6 wirds dann erst recht lustig. Klar ist, er kennt DNS Server und nutzt sie. Die Verbindungen kann man beispielsweise im "OS Monitor" auch ohne Root ansehen. Da sind in einem solche DS-lite Mischnetz eine kunterbunte Mischung aus IPv4 und IPv6 zu finden. Da Information über DNS und der DNS-Lookup eines Zielsystems im aktiven Zustand erfolgen und dann für viele Stunden ausreichen, ist die DNS Technik im Standby ohnehin unwichtig.
:
Bearbeitet durch User
Nochmal zurück zum Ausgangsthema: Wir haben zuhause auch einen kleinen Server. Anfangs war es ein PI den ich aber inzwischen u.a. aus Geschwindigkeitsgründen durch einen mehr oder minder "ausgeschlachteten" Laptop ersetzt habe. Anfangs habe ich auch Port 22 weitergeleitet, da kamen (vorwiegend aus China/Honkong) regelmäßige Login-Versuche. Ich nehme an, das waren automatisierte Scripts, denn es wurden nur Standard-User und -Passwörter verwendet. Inzwischen habe ich den Port gesperrt und logge ich mich nur noch über das eh schon vorhandene VPN über SSH ein. Das geht aber nur über einen eher "unüblichen" Nutzer ohne weitere Rechte von wo aus ich dann über su Rootrechte bekomme. Also gibt es letztendlich 3 wesentliche Hürden für einen Eindringling: - VPN (OpenVPN mit 2048 Bits RSA) - SSH Login als User mit entsprechendem Passwort - su mit separatem Root-Passwort 100% ige Sicherheit gibt das auch nicht, aber für den "Hausgebrauch" sollte es eigentlich ausreichen. Jörg
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.