Wellicht gaat het om deze pagina voip wiki freedom
Bedankt. Niet dé “Freedom website” www.freedom.nl waar ik zocht dus… ![]()
Ik neem aan dat de voip-wiki.freedom.nl website niet bedoeld is voor de argeloze gebruiker met zijn FRITZ!Box en Freedom Bellen abonnementje zoals ik ![]()
Een simpele nslookup (Windows) van sip.freedom.nl en sip-tls.freedom.nl laat zien dat er geen IPv6 connectiviteit is.
Hoi
Je kunt niet uitsluiten dat als je de Fritz op sipproxy.voipgrid.nl zet,
deze ook IPv6 gebruikt.
Anyway, ik kom er dus niet achter dat de naam bij nummer niet meer werkt.
Ik krijg op alles ‘unknown’. Ik heb het toch echt aanstaan.
Vr.Gr,
Rob
Voor wat betreft IPv6 staat op de voip-wiki:
De IPv6 range wordt momenteel alleen gebruikt voor webhooks.
Zie:
https://voip-wiki.freedom.nl/index.php?title=Algemene_firewall_instellingen
Als ik het zo lees lijkt telefonie via Freedom me toch de beste optie. De aanbieders die SIPS/SRTP doen zijn veelal op (klein)zakelijk of resellers gericht. Freedom lijkt het ook bij zo’n partij af te nemen, iets wat je privé niet voor elkaar krijgt.
Ik weet dat dit een out topic is, hopelijk is het goed om hier weer op verder te gaan.
Inmiddels heb ik een voip account bij freedom en daarmee ben ik nu aan het testen met een asterisk server. Er gaat inmiddels een hoop goed: register gaat goed, sip gaat goed, bellen werkt, sip-tls werkt zelfs.
Alleen SRTP wil maar niet. Zodra ik onder het endpoint
media_encryption=sdes
configureer krijg ik dit bij een inkomend gesprek:
[Apr 27 16:57:19] ERROR[10415]: res_pjsip_session.c:937 handle_incoming_sdp: freedom_endpoint: Couldn't negotiate stream 0:audio-0:audio:sendrecv (nothing)
Als ik de pjsip logging aan zet dan zie ik dit:
v=0
o=- 1081060687 1081060687 IN IP4 195.35.115.109
s=VGUA-18vg32~d10
c=IN IP4 195.35.115.109
t=0 0
m=audio 10720 RTP/AVP 8 9 97 18 101
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:97 iLBC/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=maxptime:140
a=sendrecv
Als er daadwerkelijk media encryption beschikbaar is zouden hier “a=crypto …” regels bij moeten staan.
Heeft iemand enig idee wat ik hieraan kan doen?
Voordat we ons nou al te veel voorstelling maken van beveiliging van telefoongesprekken, het volgende: het SIP protocol staat toe dat als persoon A met persoon B belt gebruik makend van centrale C, de SIP datapackets van A direct naar B gaan, en niet via telefooncentrale C.
Maar de Nederlandse overheid is hier niet blij mee vanwege “tappen”. Maarten van een niet nader te noemen Nederlanse ex-ISP heeft me eens uitgelegd dat toen zij met telefonie begonnen, packets van A naar C gaan en van C naar B. Dat was gedeeltelijk om QoS (Quality of Service) te kunnen doen - “voorrang voor spraak packets op het netwerk” maar ook vanwege de tap-plicht.
Dus als je je veel zorgen maakt over “afluisteren” realiseer je dan dat dit dit afluisteren op een andere plek alsnog gebeurt en dat je daar weinig tegen kunt doen.
Dan nog iets anders. Tenzij je echt, echt wil, zou ik voorzichtig zijn met het draaien van een SIP server zoals asterisk. Die dingen trekken abuse aan op een manier die je niet voor mogelijk houdt. Net zoals met SSH is er allerlei gespuis wat probeert via SIP te registreren, en met SIP gaat dat veel gemakkelijker en sneller als met SSH. En de reden dat ze het doen: er is geld mee te verdienen. Jaren geleden heb ik voor de lol eens zo’n ding opgezet om te zien wat ermee gebeurt en het blijkt dat men vooral zoekt naar manieren om dure belminuten te vinden om die gestolen airtime to kunnen verkopen. Ik had het ding ingericht om te zien “wat er gebeurt” en zag allerlei verre en vooral dure telefoonnummers voorbij komen. Als je met SIP gaat experimenteren, doe dat dan vooral via een prepay SIP account zodat als je gehacked wordt de schade beperkt is tot een paar tientjes voordat uitbellen geblokkeerd wordt.
Destijds is er gedoe geweest met Fritz met SIP en als je wilt snappen dat de SIP server van en Fritz tegenwoordig allerlei dingen heeft om random verkeer vanaf het internet te voorkomen, welnu, dit was de reden.
Ik ben niet gehacked, had wel spectaculaire logfiles en ben maar gestopt met het experimenteren met SIP.
De aparte routes voor controlplane en dataplane is heel normaal in telecommunicatie systemen. Voor legitieme taps ben ik niet zo bang, daar ontkom je toch niet aan als je je in de telecomwereld begeeft. Wat ik vooral wil voorkomen is dat de 4 miljard IPv4 adressen die niets met mijn verbinding te maken hebben er narigheid mee uit kunnen halen.
Eens dat een open SIP server meer een honeypot is dan wat anders
. Daarom wordt m’n server zowel inkomend als uitgaand beperkt tot alleen de IPv4 reeksen van de VoIP provider. Mits voorzien van de juiste beveiligingsmaatregelen als TLS en SRTP kan daarmee een hoop narigheid voorkomen worden. Nog beter was geweest als dit over apart vlan was geleverd ipv. over internet, maar die keuze is er helaas niet.
Been there, done that, no t-shirt… Vooral vanuit het midden oosten kwam veel verkeer.
Niet alleen klassieke Telecom, ook VPN providers etc. (zijn ook een soort van telecom).
Een goed ingesteld firewall is van belang…
En nee NAT is GEEN BESCHERMING… (je laat immers SIP verkeer door om gebeld te kunnen worden, filters, filters, end nog eens f…).
Hoi
Ik heb jaren een semi open Asterisk gehad als honey pot. Logs omzetten naar een fake http logs en dat dan weer voeren aan Analog; Vooral veel 44 (UK). Je kunt daar heel makkelijk dure nummers scoren.
Beveiliging, net als een ui, in meerdere lagen. Dus naast firewall ook Asterisk config. In sip.conf ‘allowguest=no’ dan wel in pjsip.conf geen annonymous endpoint. Binnenkomende gesprekken kunnen dan alleen vanaf bepaalde IP adressen.
De derde laag is natuurlijk je dialplan.
Met vrienden met Asterisk doe je natuurlijk het bellen direct. En dat kan natuurlijk gecrypt.
Vr.Gr,
Rob
Precies, of in mijn situatie:
- Firewall beperkt het externe netwerk verkeer (ingaand en uitgaand) tot alleen de VoIP provider
- In asterisk zelf staat een soortgelijke ACL, middels een typo heb ik ook gemerkt dat die werkt

- Op de uitgaande TLS verbinding wordt het certificaat gecontroleerd (gek genoeg is dat niet default)
- De asterisk server heeft aparte IP adressen voor communicatie naar binnen en naar buiten, interne clients kunnen alleen verbinden met het interne adres (en met authenticatie uiteraard), de externe verbinding kan alleen maar via het externe adres
- In het dialplan kan een externe beller niets doen waar kosten voor mij aan zitten (interne clients wel uiteraard, dat is een beetje het doel
).
Volgens mij zijn daarmee de meeste risico’s wel afgedekt.
Dat brengt me wel terug bij mijn vraag: Kan iemand iets zegen over het aanslingeren van SRTP? Volgens de documentatie op Encrypted bellen - Help zou het moeten kunnen.
Hoi
Ik, was het eigenlijk alweer vergeten, totdat ik het hier weer terug las; Ik heb het ooit deels draaiend gekregen: Uitgaand wel, ingaand niet.
Ik maak me er verder niet zo druk om. Eea is tapbaar en als ‘password’ heb je dat nonce gebeuren;
Er gaan dus geen plain text ‘logins’ oid via SIP.
Vr.Gr,
Rob
Klopt, de credentials gaan over SIP en dat is nu met TLS beschermd. Een audio stream over internet zonder beveiliging vind ik wel een (groot) ding. Denk aan persoonlijke gesprekken die ineens af te luisteren zijn (door een veel grotere groep dan toen die door een dedicated lijntje ging).
Het voelt voor mij alsof we het ineens ook weer prima zouden vinden dat alle websites alleen nog maar http doen (geen https dus), dat is wel erg back to the 00’s
. En dat terwijl srtp aanzetten veel simpeler is dan sip-tls, wat dan weer wel gebruikt wordt.
Kan ik hier bij de voip provider zelf een ticket over maken of moet dat via Freedom?
Altijd bij Freedom, daar ben je klant. De VoIP provider kent jou niet en kan je dan ook niet helpen.
Mogelijk was ik niet duidelijk, als wij op een Fritz!box telefonie aanzetten en die Fritz!box kan SIP-over-TLS dan kan die ook SRTP en dat zetten we dan ook aan. Ik kan dan ook geen chocola meer maken de RTP-stream in een packet capture.
De (inmiddels hele) oude Fritz!boxen kunnen dat niet. Daar moeten we het wel onversleuteld aanzetten.
Heb je dat getest met een inkomend of een uitgaand gesprek? Uitgaand heb ik zelf nog niet getest (daar hoop ik dit weekend aan toe te komen), inkomend zie ik wat ik eerder gepost heb en ook @sput deelt een soortgelijke ervaring.
Hoi
Ik heb het ooit met een hairpin getest. Dwz, via Freedom mezelf
bellen. Uitgaand is dan gecrypt, ingaand niet.
Wellicht aardig als iemand een werkende config post.
Vr.Gr,
Rob
Inmiddels heb ik ook uitgaande gesprekken aan de praat gekregen vanuit asterisk.
Met SRTP aan werken uitgaande gesprekken, inkomende gesprekken gaan meteen door naar voicemail (asterisk wijst ze af vanwege het ontbreken van crypto). Middels wireshark heb ik bevestigd dat de stream dan inderdaad gecrypt is.
Zonder SRTP werken zowel inkomende als uitgaande gesprekken.
Is het een idee om de configs zoals we die nu hebben te delen?
Hoi
Wat algemene instellingen van mijn huidige Asterisk setup;
http://www.sput.nl/software/asterisk/asterisk.html
Stukjes die nu in sip.conf outgecomment staan;
In [general] section;
; RvdP, Freedom TLS
;register => tls://Account_Id:PassWord@sip-tls.freedom.nl:5061/Account_Id
Elders;
[voipgrid-in](!)
;transport=tls
; Exp Encription
;encryption=yes
; Fallback
;media_encryption_optimistic=yes
;media_encryption=sdes
[freedom](voipgrid-in)
;host=sip-tls.freedom.nl
Als je perse eist dat binnenkomend encrypted is, word dat dus geweigerd.
Bij Voipgrid kan je op de website instellen dat de audio gecrypt moet zijn. Bij Freedom niet. Ik denk dat binnenkomend daarom niet gecrypt is.
Maar als iemand binnenkomend toch werkend heeft, hoor ik dat graag.
Iets anders:
Er zit dus geen Asterisk in Debian 12 of 13, wel in 11 / Bullseye en
Unstable.
Ik heb nu op Debian 12 / Bookworm dus de Asterisk 16 uit Debian 11 draaien.
Weet iemand of dat ook met 13 / Unstable werkt? Of dat je voor 13 een backport uit Unstable moet bouwen?
Vr.Gr,
Rob
