Benutzer sipijedy schrieb:
Ja das ist das vorgehen eines jeden debian systems. Trivial wenn man die Kenntnis bereits erarbeitet hat. Meine Mutter mancher (Fachfremde) Absolvent/Professor ohne Interesse wäre damit überfordert, wenn sie das selbst herausfinden müssten.
Heute ist das aber eher ein gewusst wo, als gewusst wie - ich gebe zu, ein passendes HowTo zu finden, das man ohne Vorkenntnisse abarbeiten kann, ist nicht einfach. Auch das Schreiben nicht, ich habe in einem anderem Forum (ippf) da mal ziemlich lange eine Schritt für Schritt Anleitung verfasst.
Configs sind auch sehr einfach, es gibt eigentlich für alles fertige Muster, die man nur anpassen muß.
Das anpassen erfordert nunmal nachvollziehen und verstehen.
Oder umfangreiche Kommentare, um zu wissen, wo was passiert. Leider in der Tat meist suboptimal. Die Beispielkonfigs, die ich entworfen habe, haben alleine für die Kommentierung 3 Tage gedauert (ich lag mit Nebenhölenentzündung im Bett, da war das das einzige, was ich als Beschäftigung hatte). Die eigentlichen Configs zu entwerfen hatte weniger als einen Tag gedauert (bei Vorkenntnissen).
Meine Configs beschränken sich aber auf die Teilaspekte Parallelcall, und Callback, weil mich das Problem, mehrere Rufnummern zu übermitteln, noch nicht trifft.
Er hängt nur nicht zwangsläufig hinter einer NAT. Ob der asterisk wirklich vom Nat geschützt ist ist nicht so trivial zu ermitteln, Weils auf die Umgebung ankommt und bei IPv6 ist es ein neues Szenario. Kommen Angriffe von innen...?
IPv6 ist leider bei quasi allen VoIP-Providern noch kein Thema, man kommt (noch) nicht umhin, komplett bei IP4 zu bleiben (für SIP). Aber auch bei IPv6 müsste die Adresse des Asterisk bekannt sein - und das einzige Sicherheitsrisiko besteht bei Asterisk seit Beginn "nur" in unsicheren Passwörtern und Zulassen von reinvite.
Wie gesagt, ich nutze zur Sicherheit eh nur prepaid (pfeiff was auf Festnetzflat, wenn man alle Netze für 0,5 Cent/Min erreicht und die häufigsten Ziele via SIP-Uri kostenfrei). Allerdings kann man z.B. bei 1&1 im Kundencenter sehr detailliert einstellen, was ausgehend erlaubt ist, und ausgehend nur Gespräche zulassen, die unter die Festnetzflat fallen. Damit wäre der Asterisk zwar nicht gegen Mißbrauch, wohl aber gegen Folgekosten aus Mißbrauch geschützt.
Und dann muss man sich für neue Sicherheitsaspekte informieren und per Hand reagieren. Also doch lieber eine managed Voip-TK anlage?
Die nicht wirklich sicherer sein muß und - wie man an den FBF gesehen hat - auch arge Lücken aufweisen kann. Dabei sind die FBF noch die Geräte mit dem besten Service, was Sicherheitsupdates angeht.
Wie gesagt, prepaid und ggf. Zielbeschränkung beim Provider sind der einzige wirklich effektive Schutz gegen die Folgen eines nie ganz auszuschließenden Hacks.
Fritzbox updated sich daher Mittlerweile von selbst.
Was aber auch ganz andere Probleme hervorrufen kann - wie z.B. der ssh-Bug, plötzlich gehen Weiterleitungen zu sip-uris nicht mehr usw. Bei mir gibts automatische Updates auf jeden Fall nicht...
Jo, trivial und billig, wenn man viel Zeit hat bzw. der Stundenlohn bei <10€ liegt.
... oder eine Woche Krank im Bett effektiv nutzt ...
Anschaffungskosten sind nunmal nicht alles, auch wenn die Mehrheit nur auf die Anschaffungskosten schaut, weil die trivial zu ermitteln sind.
Weshalb ich auf die Betriebskosten (eine Box, die man als Fan von Bakelittelefonen eh laufen hat) hingewiesen habe. Wenn man nicht impulswahlfähige oder mehr Analogports braucht, als die Haupt-FBF hat, eine auchvon den Betriebskosten praktische Sache. Aber auch ein Rasperry Pi b+ schluckt nur 5-10€ an Strom je Jahr im Dauerbetrieb.
Nicht vernachlässigen sollte man auch die Einarbeitung in die entsprechenden Funktionen, wenn die FBF sie besäße. Ich nehme als Vergleich gern den in uk und usa verbreiteten obi202. Sehr leitungsfähiger konfigurierbarer Wählplan. Die zweite Woche mit der Nebenhöhlenentzündung war mit dem Versuch, den wunschgemäß einzurichten, jedoch vergeblich.
Was die übrige Kosten/Nutzenanalyse angeht: Die Telefoniekosten vom Handy sinken extrem, wenn man im Zusammenspiel von FBF, Asterisk und BoxtoGo pro einen bequem zu nutzenden Callbackdienst einrichtet. Bei meinem Dualsimhandy auf 0 Cent ins Festnetz, 0,5 Cent ins Mobilnetz (1. Karte Simquadrat, 2. Karte Alditalk). Nur Internet muss man auf dem Androiden haben.
Damit spart man so deutlich, dass eine AllNetFlat überflüssig wird (es sei denn, man ist Extremtelefonierer). Mit einem System kann man mal eben die Kosten aller (Android)Smartphones der Familie so drücken, also Sparpotential von 10€ und mehr je Nutzer und Monat.
Allerdings bekommen es die meisten Nutzer ja nicht mal hin, die seit Ewigkeiten vorhandene Callthrough-Funktion zu nutzen, um auf dem Smartphone/Handy die Kosten zu anderen Hands auf 0,5 Cent/Min zu senken - was immerhin bedeutet, dass man meist mit einer Festnetzflat auf dem Handy auskäme. Die Leute kaufen trotzdem lieber All-Net-Flats...
Und beim nächsten aufgedeckten Sicherheitsloch muss man dann wieder kompilieren.
Nicht wirklich, selbst mit der alten Firmware hätte es keine Probleme gegeben - abweichende Porteinstellungen, 10 Min nach dem Booten beenderter Webdienst usw. machen einen automatischen Angriff praktisch unmöglich.
Gerade deshalb drängt sich eine EOS-FBF auf. Hier kommen nur ganz selten, also in absoluten Ausnahmesituationen, Sicherheitsupdates. Selbst dann wäre einmal alle 2-3 Jahre neu kompillieren - weil die Konfig des Asterisk sich dadurch nicht ändert - "verschmerzbar".
Die rechtliche Lage ist mir zu komplex. Warum cyanogenmod das darf/kann und freetz nicht? Evtl. müsste man die gemoddeten freez-images übers Ausland teilen generieren?
Ob cyganogenmod das darf, ist auch fraglich. Grundproblem ist, dass die Firmwares zum einen OpenSource enthalten, zum anderen aber markenrechtlich/
gebrauchsmusterrechtlich und ggf. in Einzelfällen auch urheberrechtlich geschützte closed source. Ein fertiges Firmwareimage enthält also Elemente, die nicht frei weiter gegeben werden dürfen.
Praktisch wird bei freetz der OpenSource Teil neu generiert, eweitert und ausgetauscht. Das muss der Hersteller erlauben, weil dies ein Recht des Besitzers nach der GPL ist. Für die Umsetzung kann man dann auch ein Image generieren, was beides enthält (weil zur Einhaltung der GPL der bestimmungsgemäßen Verwendung erforderlich) - aber dies eben nicht weiter geben.
Sicherheitstechnisch ist eine modifizierte Firmware wie eine irgendwo gesaugte windows exe. Man weiß weder wer der Anbieter wirklich ist und wenn, dann weiß man nicht welche Sicherheitsmaßnamen er für seine Buildumgebung Sourcen-verwaltung hat.
Da bei freetz allerdings eine bekannte Entwicklungsumgebung zum Einsatz kommt, ist eine auf einem anderen Rechner mit den gleichen Menueinstellungen erzeugte Imagedatei identisch - damit ist ein Image verifizierbar. Insofern könnte man, wenn Firmwaredateien weitergegeben werden, durchaus in Foren verifizieren, ob es eine abweichend vom vorhandenen open source generierte Datei ist oder nicht.
Rein praktisch ist aber, da Images eh nicht weiter gegeben werden dürfen, nichts anderes erforderlich, als die genauen Menueinstellungen in der Freetz-VM zu beschreiben (wieder Schritt für Schritt), mit der das Image generiert wird. Auch hier eher das Problem, die Anleitung zu formulieren, als sie anschließend zu befolgen.