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.
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.
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.
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.
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.
>..., 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.
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.
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.
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.
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.
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.
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.
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
