Messages

151

German - Deutsch / Re: Geräte hinter TP-Link Switch nicht Pingbar

« on: May 20, 2017, 03:38:26 pm »

hm dacht ich mir. Bei mir gibt es keine PVID untagged Option oder ähnliches.
Ich hatte meine Umsetzung so wie hier beschrieben durchgeführt: http://www.tp-link.com/us/faq-328.html
Ich sehe da auch keinen Unterschied zu meinem..
Mein Switch Model ist folgendes: TL-SG3210

Bin echt am Verzweifeln. Keine Ahnung was ich da übersehe.

EDIT:
Hab die Ports die vorher auf "General" waren mal auf "Access" gestellt, weil die ja kein Teil von dem Default VLAN sein müssen. Aber das brachte auch keine Besserung.
Gerade geupdated auf 17.1.7 ohne Änderung/Besserung

152

German - Deutsch / Re: Geräte hinter TP-Link Switch nicht Pingbar

« on: May 19, 2017, 11:12:42 pm »

Hallo tcmax und Domi741,

danke erstmal für die vielen Ratschläge.

@tcmax
Die Allow Any Any Regel hat nichts gebracht (hatte ich aber auch vermutet, weil zum Pingen sollte ICMP ja reichen), aber man weiß ja nie. :-(

Entsprechende Routen in der OPNSense für die Subnetze sind angelegt?

Das ist halt die große Preisfrage. Das hab ich nicht, wenn du von den statischen Routen ausgehst, aber das ist auch gar nicht möglich, bzw. nötig, da alle Netze ja direkt an der OPNsense angeschlossen sind ohne einen zusätzlichen Router der das Netz trennen würde. Zusätzliche Routen müssten daher doch eigentlich nicht nötig sein oder? Die OPNsense kennt doch alle Subnetze die direkt angeschlossen sind.

@Domi741
Die VLANS 1 und 2 waren nur Beispielhaft genauso wie die IPs. Ich hab eigentlich gedacht und auch gehofft dass es was einfaches ist, was ich übersehe und wollte da nicht die richtigen IPs nutzen.
Die VLANs/PVIDs aus den Bildern sind auch die die ich in Echt nutze.
Die sind so hoch gewählt um gleich beim ersten Blick auf die VLANs und IP Adressen zu wissen um welches Netz es sich handelt. Da keine weiteren VLANs hinzu kommen werden passt das für mich. Man hat da ja die freie Wahl.

sondern die PVID effektiv das untagged VLAN sein muss. was ich bei untagged einstelle interessiert den kein Stück -,-

ookaay?? Das klingt ja schonmal nach ner Idee Wo meinst du kann man das umsetzen? Finde dazu nichts in der GUI. Wär schön wenn du mir da kurz den Weg zur Einstellung sagen kannst.

153

German - Deutsch / Re: Geräte hinter TP-Link Switch nicht Pingbar

« on: May 19, 2017, 08:28:44 pm »

Hallo tcmax und faunsen,

hier die Anhänge.
Geht das so überhaupt oder verrenne ich mich in irgendwas?

Wie gesagt, Ziel sollte es am Ende sein Firewallfreischaltungen von einem VLan Subnetz zu einem anderen zu erlauben und auch zu Routen, damit ich zum Beispiel aus dem Admin VLAN auf die Fritzbox AP GUI komme und andersrum irgendwann mal ein Client aus VLAN Nutzer 1 auf eine NAS zugreifen kann usw.
Sieht nach Routingfehler aus oder?
Was aber auch nicht ganz einleuchtet, weil ich keine Router zwischen den Netzen habe und die OPNsense eigentlich alle Netze kennen müsste ohne zusätzlich konfigurierte statische Routen.

154

German - Deutsch / Re: Geräte hinter TP-Link Switch nicht Pingbar

« on: May 19, 2017, 08:13:15 pm »

Hey Faunsen,

Access Ports/General Ports = untagged
Trunk Port = Tagged

Ich versuch mal zu erklären was ich bis jetzt umgesetzt hab, vielleicht hab ich auch nen echt harten Fehler gemacht.

Ein Trunk Port war für mich immer der Port der mit dem Switch, über ein Patchkabel verbunden, die getaggten Pakete überträgt. Heißt bei der OPNsense habe ich mehrere VLAN Interfaces erstellt die auf dem physischen LAN Port der Firewall liegen. Weil ich nich wollte, dass man sich an den LAN Port der Firewall anschließen kann und sofort die GUI öffnen kann, habe ich das klassische LAN Interface gelöscht und administriere die Firewall nur noch aus dem Admin VLAN.

Ergo habe ich jetzt 3 Kabel an der Firewall:
Das erste Interface geht an das Modem ins WAN
Das Zweite ist mit dem Trunk Port des Switches verbunden und hat mehrere VLANs
Das dritte Interface ist mit dem AP verbunden.

Beim Switch sieht es so aus:
1. Port (Trunk) ist mit der LAN Schnittstelle an der Firewall verbunden.
2. Port an einen Client
3., 4. und 5. ebenso

An Jedem Port an welchem ein Client hängt wurde auf dem Switch eine untagged VlanID zugeordnet.
Dem Trunk Port wurden alle VLANs zugeordnet. Die restlichen VLANs wurden immer demjenigen Port zugeordnet, an welchen der richtige Client sitzt + dem Trunk Port. Wenn also Switchport 2 im VLAN 5 sitzt, dann wurde VLAN 5 Switchport 2 und Switchport 1 (Trunk) zugeordnet.

Link Aggregation hab ich nicht umgesetzt. Es soll erst mal so funktionieren

Ja, der Switch kann die 192.168.1.7 erreichen

Wenn ich vom Client zum anderen Client im anderen Netz ein Tracert hinmache, wird der Switch nicht erreicht.
Also um beim Beispiel zu bleiben:
192.168.1.7 macht einen Tracert auf 192.168.2.7
Der erste Hop ist 192.168.1.1 und danach kommt nichts mehr.

EDIT:
Hab irgendwie die Befürchtung nen Groben Fehler gemacht zu haben....
Was ich auch noch sagen möchte ist, dass ich das Default VLAN garnicht genutzt habe, also weder bei der Firewall ein VLAN Interface angelegt, noch beim Switch dieses VLAN verwendet habe.

Ich häng hier mal meine 802.1Q Konfiguration vom TP Link Switch mit ran. Vielleicht wird daraus jemand schlau. :-/

155

German - Deutsch / [GELÖST] Geräte hinter TP-Link Switch nicht Pingbar

« on: May 19, 2017, 05:59:57 pm »

Hallo Leute,

ich stell mich mal wieder glatt, deswegen schon mal vorher ein großes dickes Sorry!
Bestimmt übersehe ich auch einfach nur wieder irgendwas und irgendwer sieht für mich den Wald bei all den Bäumen.

Überlegung:
Mein Problem ist, dass ich keine Geräte hinter meinem VLAN Switch per Ping erreichen kann.
Ich habe einen Switch per Trunk Port an den LAN Port der Firewall angeschlossen und mehrere VLANs mit eigenen Subnetzen definiert. Soweit so gut. Diese können auch alle ins Internet und sollen sich untereinander nicht ansprechen dürfen. Beim Einrichten des Fritzbox WLAN AP, habe ich nun das merkwürdige Verhalten, dass die Konfigurationsoberfläche falsch dargestellt wird wenn ich die IP aus meinem Admin VLAN versuche zu erreichen. Öffne ich die Fritzbox GUI direkt aus dem WLAN Subnetz wird die richtige Oberfläche angezeigt, wo man sich mit Passwort einloggen kann. Also hatte ich die Vermutung, dass irgendwas mit den Routen nicht stimmt, also habe ich mit der OPNsense GUI angefangen Pings und Traceroutes zu machen (vorher natürlich die ICMP Regel dafür erstellt)

Problem:
Jetzt steh ich vor dem Problem das ich generell, also ganz egal ob jetzt nun Fritzbox oder normaler Laptop Client, ich nicht zwischen den Geräten innerhalb verschiedener VLANs pingen kann.

Beispiel:
>> Firewall Freischaltung für ICMP von any nach any auf dem VLAN 1 Interface bereits eingestellt <<
VLAN 1 (Admin) Subnetz: 192.168.1.0/24
VLAN 2 (Nutzer) Subnetz: 192.168.2.0/24
Switch IP: 192.168.1.2
Switch Gateway: 192.168.1.1 (also die IP der OPNsense Schnittstelle in VLAN 1)

Ping von 192.168.1.2 (Switch) auf 192.168.2.1 (OPNsense) funktioniert
Ping von 192.168.1.2 (Switch) auf 192.168.2.7 (Client) funktioniert nicht
Ping von 192.168.2.1 (OPNsense) auf 192.168.1.1 (OPNsense) funktioniert
Ping von 192.168.2.1 (OPNsense) auf 192.168.1.2 (Switch) funktioniert
Ping von 192.168.2.1 (OPNsense) auf 192.168.1.7 (Client) funktioniert nicht

Folgender Aufbau (ungefähr):

[ O P N s e n s e ]
              |
    Trunk | (VLAN 1 &2)
              |
[    TP   -Link   Switch     ]
   |                                   |
General Port              General Port
VLAN 1                           VLAN 2
   |                                    |
[Client 192.168.1.7]         [Client 192.168.2.7]   

_____________________________

Das sieht für mich nach ner 0815 VLAN Aufgabe aus, weshalb ich halt auch grade echt von den Socken bin, dass das einfach beim besten Willen nicht klappen will. Hat irgendwer Erfahrung mit TP-Link Switchen und der Umsetzung mit OPNsense? Kann jemand vielleicht erahnen welchen Denkfehler ich hier habe?
Richtig peinlich... wie gesagt .. Sorry!

BTW: VLANs und IPs sind in diesem Post nur Beispielhaft, das Problem bleibt aber natürlich das gleiche.

Schöne Grüße und ein erholsames Wochenende gewünscht,
Oxy

EDIT: Ich bin mir mittlerweile ziemlich sicher, dass es am Switch liegt. Bei allen Ping und Tracert Verbindungen erreiche ich das andere Subnetz bis hin zum Switch und NUR bis zum Switch.
Das verwirrt mich noch viel mehr als vorher...
Grade der Switch müsste doch die wenigsten Probleme mit dem getaggten Paket haben?
Ich meine der muss doch nur noch zuordnen an welchen Access/General Port er das Paket dann schicken soll...
uhh...

156

German - Deutsch / Re: Reihenfolge der DNS Server von Bedeutung!?

« on: May 18, 2017, 02:59:29 pm »

Huhu Leute,

Beim DNS Forwarder wird Dnsmasq genutzt als Service. Dieser unterscheidet nicht in der Priorität, sondern überprüft lediglich (selbstständig) welcher DNS Eintrag für ihn gerade der Beste ist und nutzt dann diesen.

Hier kann man das nochmal richtig schön nachlesen:
http://tomatousb.org/forum/t-370474/dns-priority

Da wurde auch ein schöner Vergleich beschrieben, wenn man einmal den ISP DNS nutzt und als zweites den OpenDNS DNS und diesen aber mit selbst erstellten Filter Listen einsetzt (konfiguriert bei der Webseite NICHT in OPNsense). Durch das Wechseln der DNS Server, je nach Performance würden diese Filter regeln dann halt nicht immer funktionieren, weshalb Unbound (OPNsense DNS Resolver) OHNE aktiviertem Forwarder Mode MIT DNSSEC aktiviert die bessere Alternative ist. Da kannst du dir dann durch DNSSEC auch wenigstens (relativ) sicher sein die richtigen DNS Server angesprochen zu haben um die richtigen DNS Antworten zu erhalten.

Vertraulichkeit (Verschlüsselung - DNScrypt) würde ich mir auch gern wünschen, aber da gibt es ja bei OPNsense keine Lösung für oder?

Schöne Grüße
Oxy

157

German - Deutsch / Re: Traffic Shaper - IP-Bereich

« on: May 15, 2017, 08:20:52 am »

Hey Leute,

nach langem probieren, hab ich herausgefunden woran es lag.
Ich hab alles so gelassen wie beim aller ersten Post bei diesem Beitrag.
Das Interface also auf WAN gestellt (Richtung Internet) und NICHT WLAN.

Der Grund warum anscheinend nicht limitiert wird ist folgender: "Captive Portal"
Mit aktiviertem Captive Portal wird der Traffic Shaper ignoriert. Schalte ich das Captive Portal aus und mache den Test, wird auf 4,8 Mbit/s limitiert (5 Mbit/s wurde eingestellt), was also dann passen würde.

@Franco eine Idee was man da machen könnte?

Schöne Grüße
Oxy

158

German - Deutsch / Re: Traffic Shaper - IP-Bereich

« on: May 13, 2017, 02:45:21 am »

Hey hey,

ja das ist schon ziemlich merkwürdig. 
Theoretisch sollte, dass ja keinen Unterschied machen, weil ich im richtigen Subnetz bin, aber man weiß ja nie.
Werde das dann am Montag mal ausprobieren und berichten.
Ich werde auch zusätzlich Zuhause mal Privat auf meiner Büchse morgen früh das Traffic Shaping konfigurieren und mal schauen, ob das Problem nicht doch etwas tiefgreifender ist, falls es bei mir Zuhause klappen sollte, aber auf Arbeit weiterhin nicht.

Trotzdem danke erst einmal für den Tipp. Was mich halt echt am meisten nervt ist, dass es damals zu 16.x Zeiten mal klappte und ich einfach nich mehr drauf geachtet hatte. Jetzt plötzlich fällt mir auf, dass es nicht mehr geht. Komisch komisch

Schöne Grüße,
Oxy

159

German - Deutsch / Re: Traffic Shaper - IP-Bereich

« on: May 12, 2017, 08:17:03 am »

Hallo zusammen,

- also folgendes, ich nutze:
OPNsense 17.1.6-amd64
FreeBSD 11.0-RELEASE-p8
OpenSSL 1.0.2k 26 Jan 2017

- Policy Based routing nutze ich nicht
- Es ist auch keine Multi WAN Umgebung an der Firewall angeschlossen
- Shared Forwarding Feature ob angeschaltet oder ausgeschaltet kein Unterschied

Grade auch testweise mal die Umsetzung wie bei @netranger ausprobiert aber auch ohne Erfolg.
(Weder mit dem Interface WLAN noch WAN).. Maske hatte ich auch frei gelassen dieses mal.
Weiterhin habe ich dazwischen "Reset" genutzt und auch den "ipfw" Traffic Shaper Service immer neugestartet.

Noch eine Idee? :/
Ich hab mal die beiden Fenster angehangen an den Post.

160

German - Deutsch / Re: Traffic Shaper - IP-Bereich

« on: May 11, 2017, 08:46:06 am »

Traffic Shaper funktioniert bei mir nicht mehr, egal ob als Interface WAN oder WLAN eingestellt wird.
Folgendes hab ich eingestellt und das ging mal früher:

Pipe:
_____
Enabled[yes]       5     Mbit/s   source   5 Mbps Limit Download   
Enabled[yes]       5     Mbit/s   source   5 Mbps Limit Upload

Rules:
_____
11   WAN   ip   any                           <privates WLAN Netz>/24   5 Mbps Limit Download   Download Rule   
21   WAN   ip   <privates WLAN Netz>/24   any                           5 Mbps Limit Upload        Upload Rule

Irgendwer eine Idee was ich übersehe? Beim Speedtest auf diversen Seiten komme ich auf über 32 Mbit/s.

EDIT:
Hab Testweise auch mal versucht über "advanced" die Directions näher zu definieren:
Für Download: Direction: "in" vom Interface 1 (WAN) zu Interface 2 (WLAN)
Für Upload: Direction: "out" vom Interface 1 (WLAN) zu Interface 2 (WAN)
Source und Destination Adressen auch mal testweise auf "any" gesetzt.

--> KEIN Erfolg. Da klappt irgendwas grundsätzlich nicht mehr. :-/

EDIT 2:
Hab mir nochmal den Beitrag in der OPNsense Wiki angeschaut und da steht ganz eindeutig um das LAN zu Traffic shapen:
interface   WAN    (Select the interface connected to the internet)

--> Nochmal alles laut Anleitung neu gemacht und immernoch KEIN Erfolg.

161

German - Deutsch / Re: Traffic Shaper - IP-Bereich

« on: May 11, 2017, 08:19:18 am »

Hey netranger,

ganz sicher, dass mit dem Interface nicht das Interface zum Upstream Gateway gemeint ist, also das WAN Interface?
Es wurmt mich grade nämlich ziemlich, dass es bei mir funktioniert obwohl ich anscheinend das Interface falsch ausgewählt habe. Komisch... Gibt zu der Option auch keine Beschreibung, was schade ist. (Das "i" ist grau)

Ich habs jetzt bei mir auch auf das richtige Interface gewechselt, aber ganz nachvollziehen kann ichs nicht.

EDIT: Okay zu früh gefreut... Jetzt geht es weder mit WAN noch mit WLAN.. zu Zeiten mit OPNsense Version 16.x ging es aber mal.. hmm.. ich restarte grade die Büchse.

Schöne Grüße,
Oxy

162

German - Deutsch / Re: Sicherheit von Smart Home / IoT-Devices

« on: April 10, 2017, 03:10:50 pm »

Hey hey,

Aber selbst jetzt, kommt bei jedem Problem dass Sie mit dem Phone sofort wieder die Frage nach der Firewall auf!

oh ja das kenne ich auch
Und dann heißt es immer "Früher hatte alles einfach so funktioniert".
Was mir aber dabei aufgefallen ist, ist das man alles langsam Schritt für Schritt angehen muss.
Man muss Verwandtschaften, Eltern, Freunde oder wen auch immer man "administriert" einfach nur genug Zeit geben sich damit vertraut zu machen. Menschen sind halt nun mal Gewohnheitstiere und schwerfällig

Sicherheit ist egal, weil ich habe ja eh nichts zu verbergen.

Oh ja das höre ich zu Genüge. Bei der Aussage möchte ich mich einfach nur noch überge....
Ich muss echt Anfangen das Zitat von Edward Snowden auswendig zu lernen.

"Some might say „I don’t care if they violate my privacy; I’ve got nothing to hide.“ Help them understand that they are misunderstanding the fundamental nature of human rights. [...]
But even if they could, help them think for a moment about what they’re saying. Arguing that you don’t care about the right to privacy because you have nothing to hide is no different than saying you don’t care about free speech because you have nothing to say.[...]"

Zugegebener Maßen richtet sich das an die Thematik der Privacy. Jedoch darf man Privacy und Security heutzutage nicht mehr von einander trennen. Meine Daten sind dann nicht länger mehr geschützt, wenn nicht genug für die Security getan wurde.
Am Ende bleibt das Problem bestehen:
Ich möchte nicht, dass jemand bei mir einbricht, ganz gleich ob Digital oder "Analog" in meine Haustür.

Ich verlinke mal da drauf: https://blog.fefe.de/?ts=a61464b3

Sehr sehr interessant. Aber vieles wusste man ja sowieso schon.

> Alexa schnorchelt nicht nur Bewohner der Wohnung ab,
> die möglicherweise zugestimmt haben können, sondern auch Gäste und Besucher.

Darüber hatte ich letztens auch diskutiert. Alexa kann in dem Sinne ja nicht ausgeschaltet werden, weil es ja jederzeit erkennen muss, wann jemand "Alexa" ruft. Demnach könnte man jetzt weiter spinnen, besonders im Hinblick auf die Apple Mikrofon Geschichte, die man zwar ausschalten konnte, jedoch intern noch weiter lief.
Wer sagt mir, dass Alexa nicht alles was aufgenommen wird nach "Schlüsselwörtern" filtert (wir wissen alle welche Key words gemeint sind) und im Falle von "Auffälligkeiten" die letzten Minuten des Gespräches an die zugehörigen Stellen verschickt?
Ich bin mir ziemlich sicher, dass das Teil in Zukunft in unser Leben integriert werden wird. Die Frage ist dann, wieviele der Menschen sich dieses Ding dann ins Netz stellen und den Zugriff zum Internet eben nicht vorher noch ausschalten per ACL?

> Überraschend (für mich jedenfalls) viele Leute machen sich Sorgen aus dem Medizin-Umfeld,
> denken über Dinge wie Insulinpumpen und Herzinfarkt-Warnwesten nach.
> Völlig zu Recht, versteht mich nicht falsch!

Deswegen nutze ich z.B. auch keine Insulinpumpen.
Die Teile sind zum Teil App gesteuert, per Bluetooth erreichbar und was weiß ich noch.
Da diskutier ich auch nicht mit irgendwelchen Ärzten.
Wie oft wollte man mir schon ein per Bluetooth gesteuertes Blutzucker Messgerät andrehen...
Oder das neuste vom Neusten bei den Insulinpumpen.

Aber das ist glaube ein anderes Thema...

Schöne Grüße
Oxy

163

German - Deutsch / Re: Sicherheit von Smart Home / IoT-Devices

« on: April 07, 2017, 06:25:09 pm »

Beispiel: Mit der App wird ein QR-Code fotografiert, der das Passwort enthält. Das PW kann dabei problemlos auch 30 Stellen haben.

Lösungsmöglichkeiten gibt es sicher genug, die auch einfach sind und funktionieren würden.
Die Frage liegt mehr im "wollen" als im "können". Man versucht halt die größtmögliche Zielgruppe an Kunden anzusprechen die es gibt. Dann muss man sich aber danach fragen, ob selbst die QR-Code Lösung nicht vielleicht schon wieder "zu schwer" wär für diese immens Große Zielgruppe an potentiellen Käufern.

Wenn der Hersteller haftet, wird keine Security bald so teuer sein, dass diese Firmen vom Markt verschwinden, weil sie die Strafzahlungen nicht stemmen könnten.

So sollte es sein, aber wer weiß schon in welcher Härte solch eine Strafzahlung dann wirklich am Ende umgesetzt wird.

Ja, das ist auch eine Lösungsmethode für das Problem, aber nicht legal. Der Vorteil ist hier, dass wenn das Problem recht schnell auftritt, die Gewährleistung ins Spiel kommt -> Produkt wird für schlechte Hersteller schnell teuer, weil die defekten Geräte ersetzt werden müssen. In dem Fall hat ja der Mangel (unsichere Software), der die Ursache des Problems ist, schon beim Kauf bestanden.

Schon richtig, aber diese Angriffe sind ja (zumindestens für mich) eher als "Trotzreaktionen" gegen die IoT Geräte zu verstehen und werden nicht dauerhaft anhalten und daher am Ende auch hier wieder nicht viel ausrichten (um tatsächlich das große Problem der unsicheren Geräte zu ändern)
Aber man kann ja träumen.
Gut wär natürlich, dass Firmen die fahrlässig unsichere Produkte auf den Markt werfen, dafür bestraft werden.

164

German - Deutsch / Re: Sicherheit von Smart Home / IoT-Devices

« on: April 07, 2017, 03:50:40 pm »

Naja... man müsste meinen die Hersteller dieser Geräte wüssten nicht was sie tun, aber wenn ich dann lese wie raffiniert die Funksteckdose sich in das Passwort geschützte WLAN einklingt, indem sie die Paketlänge der übertragenen Daten als Morsecode interpretiert ohne große Nutzerkonfigurationen... einfach herrlich
Wer sich die Zeit nimmt so ein Gerät raus zu bringen wird es doch wohl auch schaffen, das ordentlich zu machen oder?

Grundlegend haben wir aber folgendes Problem:
Der normale Nutzer interessiert sich nicht ob die eigene IP Kamera gehackt wurde und Amok läuft, sie funktioniert ja noch, bzw. der Nutzer kriegt das ja nicht mit und denkt: "Mir passiert sowas schon nicht".
Andererseits haben die Hersteller mit dem Verlangen nach Komfort mit den Nutzern zu kämpfen.
Wie der Herr aus dem Video schon sagte, es wird Sicherheit zu Gunsten der Einfachheit weggelassen, damit keine Kundenbeschwerden eingehen.

Industrie 4.0 ist ja alles gut und schön. Mein Kühlschrank darf ruhig von sich aus merken, dass Eier und Brot fehlen und dann (Kommunikation startet im eigenen Netz) Dinge nachbestellen, wenn sowas denn dann mal entwickelt wird. (Vielleicht gibt es sowas schon? )

[...] denn kein Hersteller will jetzt nicht mehr "smart" sein. Und daraus nun die Perlen zu ziehen, die sich wirklich ordentlich mit dem Thema beschäftigt haben wird schwer...

Ich glaube auch, dass dort einfach der Druck bei den Firmen hängt nicht "abgehängt" zu werden von der Konkurrenz. Wenn man da nicht anfängt sein Zeuch hinter VLANs und Firewall einzuschließen kommt man auf keinen grünen Zweig. :/

Das Einzige was es braucht ist eine Haftung für kommerzielle Hersteller, die fahrlässig handeln.

Genau das braucht die Industrie 4.0
Aber wer setzt das durch? Ihr habt ja auch sicher den Beitrag über das Samsung Betriebssystem "Tizen" gelesen mit über 40 Zero Day Lücken, was zwar erst nur in Russland eingesetzt wird, aber wohl auch hier dann für Smart TV und Handys als Betriebssystem in Einsatz kommen soll.
Da wird mir einfach nur noch schlecht bei.

Quelle: https://www.heise.de/security/meldung/Betriebssystem-Tizen-fuer-Samsung-Geraete-von-Sicherheitsluecken-durchsiebt-3674713.html
Zitat: "Darüber hinaus will Samsung das Betriebssystem künftig in smarten Kühlschränken und Waschmaschinen einsetzen. "

Irgendwer bei Heise c't meinte mal: "Es würde mir schon ausreichen, wenn man einfach gängige Sicherheitsstandards die sich über die Jahre bewert haben tatsächlich wieder nutzen würde."

Mal schauen wo uns das alles noch hinführt....
"Achtung Achtung 10.000 Waschmaschinen greifen die sozialen Netzwerke an...." 

EDIT:
Ich musste mich fast totlachen als ich das hier grade gelesen hatte:
https://www.golem.de/news/brickerbot-hacker-zerstoeren-das-internet-of-insecure-things-1704-127198.html
Das ist zwar keine "gute" Lösung, ABER es ist eine Lösung 
Ganz nach dem Motto "Wer nicht hören will muss leiden".

165

German - Deutsch / Re: [Gelöst] Captive Portal erlaubte IP oder MAC Adresse funktionslos

« on: April 06, 2017, 09:10:08 pm »

Hey hey,

mit dem Problem hatte ich auch schon zu kämpfen. (Komisch das das noch nicht gefixt wurde bis jetzt?)
Genauso gut kann man die Trennung oder Eintragung der Adressen auch mit dem ";" Zeichen umsetzen.
Ich hoffe das ändert sich von der Usability noch ein wenig.

Schöne Grüße
Oxy