[Voip] neue VOIP Datenbank in Betrieb, entkoppelt vom redeemer

Fri Aug 15 13:07:54 CEST 2014

Hallo!
Am 2014-08-15 um 12:25 schrieb David Oppermann:
> On Fri, 2014-08-15 at 11:51 +0200, Erich N. Pekarek wrote:
>> Hallo!
>>
>> Am 2014-08-14 um 22:22 schrieb Matthias Šubik
>>> On 14.08.2014, at 18:59, Erich N. Pekarek wrote:
>>>
>>>> Am 2014-08-14 um 18:27 schrieb Christoph Loesch:
>>>>> On 08/14/2014 01:30 PM, Erich N. Pekarek wrote:
>>>>>> Hallo!
>>>>>>
>>>>>> Am 2014-08-14 um 12:16 schrieb Matthias Šubik:
>>>>>>> Hallo,
>>>>>>> On 13.08.2014, at 21:45, Erich N. Pekarek wrote:
>>>>>>> ...
>>>>>>>>      Automatische generiere Passwörter sind wertlos, wenn sie im Klartext übertragen werden.
>>>>>>> +1
>>>>>> Was sagt das Voip-Team dazu?
>>>>> vom user gesetzte "einfache" passwörter sind wertvoller oder wie?
>>> Nein, aber für reine interne Verwendung komplett ausreichend.
>> Was bedeutet für Dich "reine [rein] interne Verwendung" - die Nutzung im
>> lokalen Netz oder doch eher die Nutzung über unverschlüsselte
>> open-for-all-Funkstrecken und Omni-Bestrahlungsgebiete?
>>>    Natürlich sind alle unzureichend, wenn damit Guthabenskonten geschützt werden müssen.
>> In der Tat. Quod exempla demonstrant.
> Es ist nicht ganz so, dass Passowerter im Klartext uebertragen werden.
Nicht werden, werden können.
> Immerhin wird MD5 verwendet (ja, ich weiss das man das inzwischen als
> klartext betrachten kann.)
> Problem ist hier leider die unterstuetzung durch VoIP clients, die oft
> nur cleartext & MD5 koennen.
Das ist des Pudels Kern!
Beispiel: CSipSimple: "Klartext"  ist Standard. "Datenauszug" steht 
allerdings zur Verfügung.
Und ich will nicht wissen, was ein altes BT-100/102 so alles macht. Den 
beliebten PAP2T kann man wenigstens ein bisschen mehr konfigurieren.
>    
> Ein autogenerietes Passwort bietet aber doch gegen Scenarian wie
> Brute-Force und Dicrionary Attacks eine hoehere Sichereit als selbet
> erstellte Passwoeter wie 12345678. Ein Dump der alten VoIP DB beweist
> auch das dies ein sehr beliebtes PW ist.
Die Tatsache, dass man sie erstellen kann, impliziert nicht, das man es 
auch tut.

>
> Da es sich um ein Passwoert handelt, das man im besten Fall nur zum
> einrichten des clients einmal kopieren/aptippen muss, sehe ich den
> Aufwand fuer den user hier als zumtbar und gerechtfertigt an.
Es gibt eigentlich Tools, die die Qualität eines Passwortes bewerten können.
Afaik: John
http://www.openwall.com/john/
libpwquality, debian/Ubuntu: pwquality-tools
http://www.openwall.com/passwdqc/
Javascript-Beispiel: 
http://www.dotnetspider.com/resources/40901-Password-Strength-Check-with-Javascript.aspx

Man kann auch pseudozufällige Passwörter generieren, die man sich merken 
kann und die trotzdem nicht unsicherer sind, als rein zufällige 
Passwörter, die wiederum von der Entropie in /dev/*random abhängig 
sind... (ein wiederkehrendes, leidiges Thema - auch bei der 
Schlüsselerzeugung.)
Genug geulkt ;-)

>
>
>
>
>
>>> ...
>>>> Eine Umgehung könnte ein optionales Tunnel-Setup für das VoIP-System sein, der uns das NAT erspart.
>>> SIP+TLS, SRTP, es gibt Mittel VoIP zu schützen, aber das ist eine eigene Baustelle befürchte ich.
>> Eine Baustelle, die ehebaldigst eröffnet werden sollte - IMO.
>>> ...
> Baustele ist schon offen ;)
:-)
> SIP+TLS koennen wir grundsaetzlich schon.
> SRTP ist geplant.
Was kann/darf man beitragen - und wie?
>>>>> enum ist bei uns eh aktiv, also z.b. sil-funkfeuer und funkfeuer-sil anrufe funktionieren via enum problemlos, somit sollte es überallhin bzw von überall funktionieren wo auch enum aktiv ist.
>>>> - wie gerade tel. besprochen -
>>>> Wobei es mir nicht klar war, dass 0720 ebenso wie 0780 über enum läuft. Man lernt nie aus.
>>> Das ist so nicht ganz korrekt, ENUM könnte jede Nummer unterstützen, und manche Provider haben Ihre Nummern über ENUM erreichbar gemacht.
>>> Siehe
>>> dig +trace NAPTR 0.1.0.2.4.4.9.9.5.3.4.e164.arpa
>>> oder
>>> dig +trace NAPTR 6.5.2.3.3.9.4.1.3.4.e164.arpa
>>>
>>> D.h. nicht alle 0720er Nummern sind via ENUM erreichbar, nur die von SIL, 0780 hingegen ist NUR via ENUM erreichbar, allerdings betreibt die A1-Telekom als Universaldienstleister ein Gateway für die ganzen IP Verweigerer und ausländische Telefonanbieter, die einfach die 0780 zur A1TA routen.
>>>
>>> Ich hoffe diesen Status von 0780 auch über 2014 hinaus zu erhalten, so dass es eine Verpflichtung zur Erreichbarkeit von 0780 zumindest für die A1TA erhalten bleibt.
>> Ich wusste, dass Du antworten würdest ;-) Danke!
>> Bezüglich ENUM-Erhaltung: Wenn Du für Dein Meeting Rückhalt benötigst,
>> bin ich mir sicher, dass wir das eine oder andere dazu beitragen können.
>>> ...
>>>>>> Abrechnung würde der Fairness dienen, wenn man mit einem Pool arbeitet. Bei Individualaccounts hätte man am Endpunkt einen weiteren Account einzurichten und kann womöglich keine Nummer mitschicken. Daher die Überlegung, den Account - wie bei diversen Messengern und Maildiensten üblich - gleichsam über einen (individuellen) Proxy laufen zu lassen. Kann man das?
>>> Ja kann man, allerdings zahlen wir in der Firma für einen allgemeinen Zugang zum Telefonnetz meistens mehr, weil die meisten Provider den eingehenden Teil der Verbindung (Stichwort Terminierungsentgelte) mit in die Preise einrechnen. Wenn ich die abgehende Nummer frei setzen kann, fallen sie ja um den Teil der Gebühren um.
>>>
>>> D.h. wer billig telefonieren will, geht einen anderen Weg. Wer eigene Infrastruktur will, muss z.Zt. für die "Interconnection" zu anderen Providern einfach mehr zahlen, dann steht allerdings Dingen wie beliebiger Absendernummer nichts im Weg.
>> D.h. vorerst wäre ein (individuelles) Proxying sinnlos und mit zuviel
>> Aufwand verbunden, aber ein "anonymer" Minutenpool über einen
>> Prepaid-Account wäre denkbar.
>>
>> Ein Überblick über ein paar Prepaid-Dienste (AFAIK allesamt
>> Dellmont-Brands/vormals Betamax) findet sich hier:
>> http://truvoipbuzz.com/2009/09/complete-voip-sip-settings-for-all-betamax-providers-tools/
>> Darunter sind auch Brands, die Accessnummern unterstützen und Freecalls
>> in Österreichische Festnetz anbieten.
>> Sollte man darüber -ggfls in Vervbindung mit einem Outbound-Filter nach
>> Destination- nachdenken?
>> Ich denke, der Aufwand ist geringer als mit etwaigen GSM-Gateways.
>>
>> BTW:
>> Eingehend ist die 0720 / 550933 Tele2/Sil gehörig.
>> Unsere 0780 ist hingegen bei der
>> https://www.rtr.at/index.php?S=0780700888&id=4506&L=&submit_TK=Suchen
>> als "nicht zugeteilt" geführt?!
>> Gemäß obigem Vorschlag bekämen wir ohnedies eine weitere Inbound-Nummer
>> dazu.
>>> bG
>>> Matthias
>>>
> Outbound  geht alles was Enum-Registriert ist.
> Die Idee Free-Call Provider noch zu integrieren gefaellt mir gut. Werd
> ich mich am WE mal mit beschaeftigen :)
Sollten Fragen aufkommen - Thomas Mutschlechner hat mich auf diese Idee 
gebracht. Allerdings konkret auf Voipyo, was allerdings proprietär 
funktioniert.
Man könnte auch je nach Destination andere Provider nehmen, solange das 
Guthaben reicht.

>
>
>> Aber das Problem der internen Verrechnung ist noch nicht gelöst. Wie
>> einfach sind per-user Minutenkontingente auf den Outbound-Channel bei
>> unserem neuen Voip-Server möglich? Kann man da einmal hineinschnuppern?
> Der Aufwad fuer eine verechnug haelt sich in Grenzen. CDRs werden in die
> DB geschrieben. Also sind alle Daten die wir fuer die Verechnug brauchen
> vorhanden. Es fehlt eigentlich nur die Logik, die das Auswertet und
> entscheided ein Call erlaub ist oder nicht und aktive Calls trennt wenn
> Sie das Guthaben ueberschreiten.
> Aber ist kein grosser Ausfwand.
Trotzdem sollte man im Sinne der Fairness die Kostenaufteilung 
diskutieren. Wir reden von ca 0,5 Cent netto/min zzgl. 
Transaktionsgebühren pro Aufladung iHv ca. € 2 je nach 
Zahlungsinstrument (die meines Erachtes der Zahlungsdienste-RL 
widersprechen... aber was solls...).
Irgendjemand muss allerdings mit seinen 12 Euro in Vorkasse gehen, wenn 
das Guthaben erstmals gebraucht wird oder verbraucht ist.

Ad "sharing": Mit den Geschäftsbedingungen von Dellmont habe ich mich in 
diesem Zusammenhang noch nicht befasst, aber je nach Brand scheint es 
zulässig zu sein, da sie ja generell auch Trunks anbieten. Man wird das 
am konkreten Beispiel erörtern.
>
>> LG
>> _______________________________________________
>> Voip mailing list
>> (spam-protected)
>> https://lists.funkfeuer.at/mailman/listinfo/voip
>
LG
Erich