Hallo zusammen,
in letzter Zeit finde ich öfter diese Einträge in meinem Log
WEB_35.198.143.132_40697
2018.09.05 12:26:09 3: Login denied by allowed_WEB for MGR via WEB_35.198.143.132_40697
2018.09.05 12:26:09 3: Login denied by allowed_WEB for MAIL via WEB_35.198.143.132_40697
2018.09.05 12:26:09 3: Login denied by allowed_WEB for storwatch via WEB_35.198.143.132_40697
2018.09.05 12:26:09 3: Login denied by allowed_WEB for admin via WEB_35.198.143.132_40697
2018.09.05 12:26:09 3: Login denied by allowed_WEB for user via WEB_35.198.143.132_40697
2018.09.05 12:26:09 3: Login denied by allowed_WEB for MGR via WEB_35.198.143.132_40697
2018.09.05 12:26:09 3: Login denied by allowed_WEB for at4400 via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for FIELD via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for root via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for HELLO via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for mtch via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for User via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for device via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for cisco via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for Administrator via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for MANAGER via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for MAIL via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for admin via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for patrol via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for MAIL via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for admin via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for admin via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for dhs3pms via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for root via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for login via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for PFCUser via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for Administrator via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for davox via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for debug via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for MANAGER via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for FIELD via WEB_35.198.143.132_40697
2018.09.05 12:26:10 3: Login denied by allowed_WEB for sa via WEB_35.198.143.132_40697
2018.09.05 12:26:11 3: Login denied by allowed_WEB for Cisco via WEB_35.198.143.132_40697
2018.09.05 12:26:11 3: Login denied by allowed_WEB for root via WEB_35.198.143.132_40697
2018.09.05 12:26:11 3: Login denied by allowed_WEB for guest via WEB_35.198.143.132_40697
2018.09.05 12:26:11 3: Login denied by allowed_WEB for MGR via WEB_35.198.143.132_40697
2018.09.05 12:26:11 3: Login denied by allowed_WEB for MANAGER via WEB_35.198.143.132_40697
2018.09.05 12:26:11 3: Login denied by allowed_WEB for volition via WEB_35.198.143.132_40697
2018.09.05 12:26:11 3: Login denied by allowed_WEB for administrator via WEB_35.198.143.132_40697
2018.09.05 12:26:11 3: Login denied by allowed_WEB for FIELD via WEB_35.198.143.132_40697
2018.09.05 12:26:11 3: Login denied by allowed_WEB for public via WEB_35.198.143.132_40697
2018.09.05 12:26:11 3: Login denied by allowed_WEB for cmaker via WEB_35.198.143.132_40697
2018.09.05 12:26:11 3: Login denied by allowed_WEB for OPERATOR via WEB_35.198.143.132_40697
2018.09.05 12:26:11 3: Login denied by allowed_WEB for OPERATOR via WEB_35.198.143.132_40697
2018.09.05 12:26:11 3: Login denied by allowed_WEB for admin via WEB_35.198.143.132_40697
2018.09.05 12:26:11 3: Login denied by allowed_WEB for SYSDBA via WEB_35.198.143.132_40697
2018.09.05 12:26:11 3: Login denied by allowed_WEB for PBX via WEB_35.198.143.132_40697
2018.09.05 12:26:11 3: Login denied by allowed_WEB for apc via WEB_35.198.143.132_40697
2018.09.05 12:26:11 3: Login denied by allowed_WEB for acc via WEB_35.198.143.132_40697
2018.09.05 12:26:11 3: Login denied by allowed_WEB for root via WEB_35.198.143.132_40697
2018.09.05 12:26:11 3: Login denied by allowed_WEB for tech via WEB_35.198.143.132_40697
2018.09.05 12:26:11 3: Login denied by allowed_WEB for root via WEB_35.198.143.132_40697
Sieht aus wie ein Versuch bei mir und system zu kommen. Woran kann das liegen? Wie kommt jemand darauf?
Für Tipps bin ich dankbar.
Ja, sieht so aus, dass da jemand mal alle möglichen Passwort/Login Kombinationen "abklappert".
Schau mal hier: https://forum.fhem.de/index.php/topic,89645.0.html
Warum ist Deine FHEM Weboberfläche überhaupt ungeschützt von außen aus dem Internet erreichbar?
NetRange 35.192.0.0 - 35.207.255.255
CIDR 35.192.0.0/12
NetName GOOGLE-CLOUD
NetHandle NET-35-192-0-0-1
Parent NET35 (NET-35-0-0-0-0)
NetType Direct Allocation
OriginAS:
Organization Google LLC (GOOGL-2)
RegDate 2017-03-21
Updated 2018-01-24
Comment *** The IP addresses under this Org-ID are in use by Google Cloud customers ***
Scheinbar nutzt jemand Google Cloud Services (Proxy?), um seine Aktionen durchzuführen.
Mein FHEM ist von außen erreichbar weil ich auch unterwegs oder im Büro drauf zugreifen will. Sonst ist doch der Sinn nicht wirklich erfüllt....?
Oder wie machst du das?
Danke
Zitat von: pillepalle12 am 05 September 2018, 14:21:53
Mein FHEM ist von außen erreichbar weil ich auch unterwegs oder im Büro drauf zugreifen will. Sonst ist doch der Sinn nicht wirklich erfüllt....?
Oder wie machst du das?
Danke
Welchen Sinn soll es denn haben ein SmartHome (Automatisierung) von aussen zu steuern? Es passiert doch alles automatisch.
Und wenn würde ich das mit VPN machen oder Reverse Proxy mit Client Zertifikat.
(*facepalm*)
https://wiki.fhem.de/wiki/VPN-Zugang_f%C3%BCr_FHEM
Ciao, -MN
Ich hatte früher auch solche Gäste bei mir, mein FHEM war auch von außen aufrufbar.
Habe nun auch auf VPN umgestellt, dank einiger Tipps ist es auch super easy, lies am besten mal hier: https://forum.fhem.de/index.php/topic,89832.0.html (https://forum.fhem.de/index.php/topic,89832.0.html)
Gruß
Mathze
Zitat von: pillepalle12 am 05 September 2018, 14:21:53
Sonst ist doch der Sinn nicht wirklich erfüllt....?
Der Sinn eines "Smart"home ist ein anderer.
Zitat von: pillepalle12 am 05 September 2018, 14:21:53
Mein FHEM ist von außen erreichbar weil ich auch unterwegs oder im Büro drauf zugreifen will. Sonst ist doch der Sinn nicht wirklich erfüllt....?
Oder wie machst du das?
Mit Popcorn.
Zitat von: pillepalle12 am 05 September 2018, 14:21:53
Mein FHEM ist von außen erreichbar weil ich auch unterwegs oder im Büro drauf zugreifen will. Sonst ist doch der Sinn nicht wirklich erfüllt....?
Oder wie machst du das?
Danke
Mit msgDialog und Telegram. Das Ganze nur für zugelassene User.
Grüße Schnitzelbrain
Vielleicht sollte man diesen Thread anpinnen für die Leute, die nicht wissen, wie die SuFu funktioniert?
Irgendwie ist das viele Popcorn alle 3 Monate ungesund ;D .
Inhaltlich gibt es ja wenig neues unter der Sonne, auch wenn wir dahingehend Fortschritte machen, dass wenigstens "allowed" zwischenzeitlich einigermaßen verbreitet zu sein scheint...
Zitat von: schnitzelbrain am 05 September 2018, 14:56:31
Mit msgDialog und Telegram. Das Ganze nur für zugelassene User.
per email und OTP aus einem Google Authenticator :)
Zitat von: pillepalle12 am 05 September 2018, 14:21:53
Mein FHEM ist von außen erreichbar weil ich auch unterwegs oder im Büro drauf zugreifen will. Sonst ist doch der Sinn nicht wirklich erfüllt....?
Oder wie machst du das?
Danke
Erreichbar und "sicher erreichbar nur für Dich und nicht jeden auf der Welt" sind zwei paar Stiefel. Dein FHEM hängt direkt erreichbar im Internet und hat wohl keinerlei Sicherheitsmaßnahmen. Am Ende noch unverschlüsselte Kommunikation, so dass jeder, der das Passwort mitliest sich einloggen kann...
Am Ende loggt sich der Angreifer in FHEM ein, bricht daraus aus und übernimmt deine gesamte Haus-IT!
Es gibt eine Vielzahl an Maßnahmen, wie man das sicher umsetzen kann. Wenn man überhaupt keine Ahnung und Fähigkeiten hat, geht man wohl am ehesten über eine Fritzbox, die einem ein VPN aufbauen kann. Ansonsten setzt man sich selbst ein VPN oder vergleichbares auf.
Ich persönlich habe auf den Overhead keine Lust und benutze ein verschlüsseltes Port-Forwarding über SSH an einen vServer im Internet, von dem ich dann wiederum per Port-Forwarding SSH die Verbindung an mein Handy usw. share. Damit habe ich die Dual Stack Lite Probleme von Unitymedia abgefrühstückt und kann sowohl per IPv4 als auch IPv6 Verbindungen aufbauen.
Ohne Einarbeitung und von jetzt auf gleich wird das alles aber nichts. Das muss zum persönlichen Setup passen und alle Anwendungszenarien wollen durchdacht und abgedeckt sein...
Vielen Dank für die vielen Hinweise. Ich werde mich tiefer in die Materie einarbeiten und mein fhem sicherer machen.
Danke
Vielleicht solltest Du als allererstes tatsächlich mal den Zugang von außen abschalten.
Denn wie @CoolTux schon gesagt hat: Warum sollte man es überhaupt ermöglichen, wenn doch eh alles automatisch läuft?
Wenn Du eine sichere Lösung gefunden hast (es wurden ja hier einige genannt), dann kannst Du den Zugriff ja wieder ermöglichen.
Zu Deiner Frage wie ich es mache: Per Mail mit verschlüsselten Nachrichten (ähnlich OTP) und einem eingeschränkten Nutzerkreis und Funktionsumfang (Nicht jeder Mail-Versender kann nicht alle FHEM Funktionen per Mail steuern).
Frage zum Abschalten, wie schaltet man denn zuverlässig und mit leichten mitteln den Zugang FHEM-Seitig ab ohne jetzt tausend Sachen umzustellen?
Kann man da evtl. einen Dummy dazu setzen?
Zitat von: accessburn am 05 September 2018, 18:00:00
Frage zum Abschalten, wie schaltet man denn zuverlässig und mit leichten mitteln den Zugang FHEM-Seitig ab ohne jetzt tausend Sachen umzustellen?
Kann man da evtl. einen Dummy dazu setzen?
Eventuell über allowed
allowed scheint er (der TE) ja zu nutzen, oder woher kommen die Einträge im log?
Zitat2018.09.05 12:26:09 3: Login denied by allowed_WEB for MGR via WEB_35.198.143.132_40697
Ansonsten: Im Router den Port schließen! Und wenn es unbedingt sein muß, mit einem ReverseProxy arbeiten und dann für den wieder einen Port öffnen...
Und wenn der Reverse-Proxy mit einem Passwort geschützt ist (und am besten gleich https macht), ist man "fast" so gut wie VPN ....
Gibt genug Hinweise per SuFu im Forum
Mein FHEM wird auch hin und wieder angegriffen. Als Sofortmaßnahme habe ich FHEM direkt mit fail2ban abgesichert.
https://forum.fhem.de/index.php/topic,84576.0.html (https://forum.fhem.de/index.php/topic,84576.0.html)
Mittlerweile läuft der Zugriff extern ausschließlich über apache2 als Reverse-Proxy und fail2ban.
https://haus-automatisierung.com/hardware/fhem/2016/12/30/fhem-tutorial-reihe-part-21-zugriff-auf-fhem-ueber-das-internet.html (https://haus-automatisierung.com/hardware/fhem/2016/12/30/fhem-tutorial-reihe-part-21-zugriff-auf-fhem-ueber-das-internet.html)
Vielleicht hilft es dir weiter.
Gruß Jens
attr WEB allowfrom ^(192.168.1.*|127.*)$
wäre zb mal ein anfang
Das ist aber das gleiche, wie (besser) den externen Port am Router dichtmachen ...
Edit:
Problem "To-many-Finger-on-Keybord" im Beitrag gelöst
Sorry ... (Wie konnte jemand das lesen/verstehen?)
Prinzipiell: Ja
Aber: accessburn wollte wissen, wie man das Ganze FHEM-seitig umsetzen kann
Zitat von: r00t2 am 06 September 2018, 17:54:29
Prinzipiell: Ja
Aber: accessburn wollte wissen, wie man das Ganze FHEM-seitig umsetzen kann
Die Antwort wäre gewesen: kann man nicht (direkt).
Zitat von: CoolTux am 05 September 2018, 14:23:51
Welchen Sinn soll es denn haben ein SmartHome (Automatisierung) von aussen zu steuern? Es passiert doch alles automatisch.
Ich bin ja auch ein Fan davon das Heimnetz möglichst gut abzusichern.
Aber überhaupt kein Zugriff aufs SmartHome von außen mit der Begründung weil man das nicht braucht (und nicht etwa weil man es aus Sicherheitsgründen vermeiden will)n
Würde mich mal interessieren ob du und die Danksager das wirklich so betreibem bei sich. ;)
Mir geht es gar nicht darum, den einfachen Zugriff von außen zu rechtfertigen.
Aber wenn der Sinn eines Zugriffs von außen in Frage gestellt wird können wie FileLog, DBLog, SVG Charts gleich mal aus dem SVN kicken.
Visualisierung und Diagramme scheinen dann ja nicht mehr smart zu sein und braucht man entsprechend auch im Heimnetz nicht.
Mich interessieren Messwerte von Zuhause jedenfalls meist gerade dann, wenn ich längere Zeit nicht daheim bin ...
Steuerung von außen sollte bei einer HausAUTOMATION nur in Ausnahmefällen nötig sein. Visualisierungen kann man sich zusenden lassen. Zugriff per VPN oder Reverse Proxy ist relativ sicher.
Zitat von: Thyraz am 06 September 2018, 23:18:35
Ich bin ja auch ein Fan davon das Heimnetz möglichst gut abzusichern.
Aber überhaupt kein Zugriff aufs SmartHome von außen mit der Begründung weil man das nicht braucht (und nicht etwa weil man es aus Sicherheitsgründen vermeiden will)n
Würde mich mal interessieren ob du und die Danksager das wirklich so betreibem bei sich. ;)
Mir geht es gar nicht darum, den einfachen Zugriff von außen zu rechtfertigen.
Aber wenn der Sinn eines Zugriffs von außen in Frage gestellt wird können wie FileLog, DBLog, SVG Charts gleich mal aus dem SVN kicken.
Visualisierung und Diagramme scheinen dann ja nicht mehr smart zu sein und braucht man entsprechend auch im Heimnetz nicht.
Mich interessieren Messwerte von Zuhause jedenfalls meist gerade dann, wenn ich längere Zeit nicht daheim bin ...
Wie Marvin bereits schrieb sollten sich externe Aufrufe sehr sehr in Grenzen halten und wenn dann mit VPN oder Reverse Proxy mit Client Zertifikat.
Ich mache so gut wie alles über Pushover. Wenn irgendwelche Grenzen welche ich definiert habe überschritten werden, so bekomme ich eine Nachricht. Natürlich ist es schwer wenn man im Urlaub ist zu reagieren.
Aber wie willst Du reagieren bei einem Feueralarm, oder bei zu hoher Luftfeuchte. Und wenn sollte das die Automatik machen. Zu mindest bei zu hoher Luftfeuchte z.B.
Ich habe die Möglichkeit über reverse Proxy und Client Zertifikat bedingt mein FHEM zu schalten. Ansonsten macht sehr sehr vieles die Automatik.
Grüße
Zitat von: CoolTux am 07 September 2018, 09:16:11... Natürlich ist es schwer wenn man im Urlaub ist zu reagieren.
Aber wie willst Du reagieren bei einem Feueralarm, oder bei zu hoher Luftfeuchte....
Deshalb - und weil sie keine lebenswichtigen Funktionen steuert - fahre ich FHEM auch herunter, wenn ich im Urlaub bin. Denn ich möchte nicht am Strand liegen und eine Meldung bekommen, dass der Rauchmelder XYZ gerade angeschlagen hat oder die Temperatur der CPU soeben das Durchschmelzen ebenjener verursacht :)
Zitat von: CoolTux am 07 September 2018, 09:16:11... Ich habe die Möglichkeit über reverse Proxy und Client Zertifikat bedingt mein FHEM zu schalten. Ansonsten macht sehr sehr vieles die Automatik...
Ich hatte meine FHEM auch so eingerichtet, dass man sie ziemlich komplett per Mail steuern konnte. Jedoch war mir auch das zu heikel und ich habe die Steuerung letztendlich nur auf ein paar Kommandos eingeschränkt. So kann ich z. B. einen kurzen "Statusbericht" des Systems auf diese Weise anfordern, der einem dann per Mail zugeschickt wird, etc. aber Aktoren steuern ist nicht mehr möglich.
Nur mal als interesse ... wie hast Du das eingerichtet?
Ein FHEM Mailcheck Modul triggert bei Empfang ein NOTIFY, das die empfangene Nachricht anhand ein paar Eigenschaften auf "Erlaubnis" prüft und führt dann eine Aktion aus, die mir z. B. per sendEmail eine Nachricht mit ein paar Werten aus einem SYSMON Modul zusammenstellt und sendet.
Ganz grob ähnlich wie hier: https://www.computerhilfen.de/info/fhem-mailcheck-emails-an-das-smart-home-schicken-und-darauf-reagieren.html
Nur dass ich keine Klartext-Nachrichten versende, sondern verschlüsselt und die Nachrichten ein paar Eigenschaften haben müssen, auf die geprüft wird, ehe eine Aktion ausgeführt wird.
Grundsätzlich kann man das Ganze aber auch so generisch bauen, dass man jeden beliebigen Befehl senden und mit fhem("tu dies und das"); ausführen kann. Das wäre mir per Mail aber zu gefährlich, deshalb gibt es das bei mir nicht mehr, sondern nur den ganz eingeschränkten Satz an Befehlen, der tatsächlich dann in FHEM weiter verarbeitet wird.
Guten Tag,
Ich verwende den CT-Test um zu testen, ob Geräte von Aussen erreichbar sind:
https://www.heise.de/security/dienste/Netzwerkcheck-2114.html (https://www.heise.de/security/dienste/Netzwerkcheck-2114.html)
Und dann zusätzlich die FHEM-Ports: 8083,8084,8085
LG, erwe
Zitat von: marvin78 am 07 September 2018, 08:45:14
Steuerung von außen sollte bei einer HausAUTOMATION nur in Ausnahmefällen nötig sein. Visualisierungen kann man sich zusenden lassen. Zugriff per VPN oder Reverse Proxy ist relativ sicher.
Klar, mir ging es ja wie gesagt auch nicht darum zu Verteidigen einfach die Ports für FHEM aufzumachen.
Bei mir ist außer über VPN von außen auch nichts erreichbar.
Ich hab mich nur gefragt, ob das die Mehrheit hier auch schon als zuviel ansieht.
Und dann zusätzlich die FHEM-Ports: 8083,8084,8085
Und genau das ist das Problem. Gibt genug spezialisierte Suchmaschinen, um so etwas zu finden ....
Ich finde FHEM gut, aber ich würde es ohne Schutz nicht "in der Freien Wildbahn installieren". Dazu ist dort zu viel los ...
OT:
Nur mal um ein gewisses Problembewustsein zu schärfen:
Installiere beruflich häufiger Linux-Server, die "frei" im Netz hängen. Mit dem erste "ernstzunehmende" Angriffsversuch auf einen neuen Server, nach der Erstinstallation, ist spätestens nach 10 Minuten zu rechnen. In der Zeit hat meistens fail2ban schon die ersten 10 Brute Force Angriffe auf SSH abgewehrt ... diese also nicht mit gerechnet.
Zitat von: connormcl am 05 September 2018, 15:05:08Ich persönlich habe auf den Overhead keine Lust und benutze ein verschlüsseltes Port-Forwarding über SSH an einen vServer im Internet, von dem ich dann wiederum per Port-Forwarding SSH die Verbindung an mein Handy usw. share. Damit habe ich die Dual Stack Lite Probleme von Unitymedia abgefrühstückt und kann sowohl per IPv4 als auch IPv6 Verbindungen aufbauen.
Ohne Einarbeitung und von jetzt auf gleich wird das alles aber nichts. Das muss zum persönlichen Setup passen und alle Anwendungszenarien wollen durchdacht und abgedeckt sein...
Hallo connormcl,
dein Ansatz gefällt mir sehr gut, da er das leidige Thema VPN bei einem DS-Lite-Anschluss bei Unitymedia löst.
Du hast deine Lösung grob skizziert. Könntest du für einen Laien ein detaillierte Anleitung zum Nachbauen aufsetzen?
Viele Grüße Gisbert
Wobei ein Portforwarding über ssh schon ein "VPN-light" ist ...
Zitat von: WerniemanUnd wenn der Reverse-Proxy mit einem Passwort geschützt ist (und am besten gleich https macht), ist man "fast" so gut wie VPN ....
Zitat von: Wernieman am 07 September 2018, 18:53:49
Mit dem erste "ernstzunehmende" Angriffsversuch auf einen neuen Server, nach der Erstinstallation, ist spätestens nach 10 Minuten zu rechnen. In der Zeit hat meistens fail2ban schon die ersten 10 Brute Force Angriffe auf SSH abgewehrt ... diese also nicht mit gerechnet.
Bei mir ist das so gemacht wie in deinem obigen Zitat, also NGINX mit starkem PW und SSL. Dann hängt auch noch fail2ban dahinter und ich fühle mich recht sicher damit. Was gibt es den in der Praxis so an "ernstzunehmenden Angriffsversuchen"? Das läuft doch dann eher über frei zugängliche (nicht PW- geschützte) Webseiten, oder geht an "meiner" Absicherung auch noch was vorbei außer ggf. social engineering?
Gruß
Frank
NGINX/Apach sind relativ gut geprüft gegen Hackversuchen bei der Authentifizierung. Deshalb wird (normalerweise) nicht mehr weiterprobiert vom Angreifer, wenn Authentifizierung von diesen Produkten gefordert wird.
Bei anderen Produkten, wie z.B. fhem, sieht es bei Angreifern anders aus.
In meinem Beispiel sind "ernstzunehmende Angriffe" meistens Protokollangriffe auf ssh. Der Server ist häufig dann noch so "nackt", das keine "höheren Dienste" wie z.B. Webserver laufen.
Allgemeiner Hinweis:
Gegen "richtige" gezielte Angreifer (Wie die berühmten 3 Buchstaben aus der USA, aber auch Russland, Israel, China ..... etc.) kann man sich fast gar nicht schützen. Das sollte aber für Normalbürger auch nicht das Problem sein. Die Absicherung gegen Automatisierte Angriffe ist damit aber schon mal gut (bis sehr gut).
Zitat von: Wernieman am 09 September 2018, 09:42:59
Allgemeiner Hinweis:
Gegen "richtige" gezielte Angreifer (Wie die berühmten 3 Buchstaben aus der USA, aber auch Russland, Israel, China ..... etc.) kann man sich fast gar nicht schützen. Das sollte aber für Normalbürger auch nicht das Problem sein. Die Absicherung gegen Automatisierte Angriffe ist damit aber schon mal gut (bis sehr gut).
Aus diesem Grund bauen ja immer mehr Leute zwei getrennte Netze zu Hause auf: Eins fürs Internet und eins für die Unterhaltung, Heimautomatisierung usw.
Schwierig, aber nicht unlösbar wird es dann, wenn man doch sicheren Datenaustausch zwischen den Netzen haben möchte. Aber man kann z.B. im Fall von FHEM die Datenübertragung über ein Funkinterface lösen, das nicht IP-basiert ist und direkt Schaltvorgänge usw. übergeben.
Auch ist mindestens der Einsatz eines Open-Source Betriebssystems notwendig, um keine Blackbox zu haben, die selbst alle Daten rausschickt und wo jeder zu Besuch kommen kann, wie er gerade Laune hat. (Leider halt komplex, das Ganze richtig zu konfigurieren und auch noch Aktuell zu halten).
Also ernsthaft:
Wenn ich im Zuge der ESP8266 Konfiguration lese, das Leute mit Ihrem Handy ESP-Dosen (ohne FHEM) direkt schalten wollen, befinden sich die Geräte im gleichen WLAN ... deshalb gehe ich davon aus, das praktisch 99% der User KEINE Netztrennung durchführen.