Sziasztok!
Próbálgatnánk a Sangoma Connect-et, de kb ugyanebbe futunk bele: https://community.freepbx.org/t/sangoma-connect-keeps-trying-to-register/70884
Ha jól értem, akkor a mobil klienseknek el kell érnie a PBX SIP portját. Ezt ugye vagy VPNen keresztül, ami macerás (plusz egy app, figyelni kell hogy leszakadt-e, stb), vagy direktben, ami szerintem elég veszélyes. Mármint az, hogy kb bárhonnan jöhet az a telefon, elég szélesre kell nyitni a tűzfalat.
Elméletben megoldható, hogy a PBX és a mobil kliens is kezdeményezzen egy-egy kapcsolatot a Sangoma szerverei felé, majd a Sangoma valahogy csináljon egy kapcsolatot a mobil kliens és a PBX közé, ami a tűzfalak szempontjából RELATED csomag? Vagy a RELATED feltétele, hogy meg kell egyeznie a forrás IPnek?
Egy csávó magyarázza az említett fórumban, hogy no para, hiszen az SMTP portot is ki kell nyitni a vakvilág felé, de email számlát még sosem fizettem szolgáltatónak emailenként, de hívásonként már fizettem elégszer ahhoz, hogy ilyet ne csináljak :)
Ha átállítanám TLSre, az adhat némi hamis biztonságérzetet, de attól még sérülékenységek kihasználásával ugyanúgy törhető marad a szolgáltatás, ha kiteszem publicba. Vagy tévedek?
Hozzászólások
Hát, én mindig azt mondom az Ügyfeleknek, hogyha nekik kényelmes a bejutás - akkor a "rabolónak" is...
így több opciót szoktam javasolni:
1) vpn
2) port knock
3) tűzfal nyitása meghatározott hálózatokra
igény esetén a nem kívánt forgalmat ellenőrizni is hasznos.
Nem mondom, h nem biztonsági rés adott mobil szolgáltató IP poolját megnyitni UDP-n keresztül - de legrosszabb esetben is csak telefonálni tudnak majd, a CLI-be v GUI-ba nem tudnak belépni attól, h nyitva van az UDP 5060-5069,10000-19999 port.
Bár SIP TLS-t (még) nem használok, de erős a gyanúm, hogy sikertelen próbálkozásokat egészen könnyen ki tudod szűrni fail2ban-al.
Végül, de nem utolsó sorban érdemes periodikusan visszanézni a CDR-t, h keletkezik-e olyan forgalom ami nem kívánt - valamint olyan szolgáltatók választani aki használ pénzügyi limitet is, minimalizálva ezzel az esetleges káresemény mértékét.
Köszi az építő jellegű hozzászólást, de azt hiszem a kérdéseimre nem kaptam választ.
Elméletben megoldható, hogy a PBX és a mobil kliens is kezdeményezzen egy-egy kapcsolatot a Sangoma szerverei felé, majd a Sangoma valahogy csináljon egy kapcsolatot a mobil kliens és a PBX közé, ami a tűzfalak szempontjából RELATED csomag? Vagy a RELATED feltétele, hogy meg kell egyeznie a forrás IPnek?
Ha átállítanám TLSre, az adhat némi hamis biztonságérzetet, de attól még sérülékenységek kihasználásával ugyanúgy törhető marad a szolgáltatás, ha kiteszem publicba. Vagy tévedek? <- értem, hogy a sikertelen próbálkozásokat ki lehet szűrni, de manapság már 0-day sebezhetőségekkel próbálkoznak, vagy talán már az is a múlté!?
RELATED akkor lesz egy kapcsolat, ha a kernel conntrack modul az eredeti forgalmat figyelve és értelmezve tudja, hogy új kapcsolat fog nyílni. Erre klasszikus példa az ftp, ahol a 21/tcp port mint NEW jön be, majd annak a forgalmát elemezve egyfelől a tűzfal lecseréli a válaszban a PORT parancs paramétereként átadott ftp szerver belső IP címét a saját, külső IP címére (ha szükséges, mert az ftp szerver már konfigurálható úgy, hogy NAT mögött van és akkor nem kell), majd a bejövő ADAT kapcsolatról így már tudja, hogy az egy létező kapcsolathoz tartozó új kapcsolat és hogy azt hova fkell tovább tolni.
Esetedben a SIP csatorna felelne meg az ftp parancs csatornájának, a hang kommunikációhoz használatos RDP portok meg az ftp data csatornájának. Viszont ha a SIP kommunikáció a Sangoma szervere felé kerül kihúzásra, akkor nem lesz meg az a csatorna, amelyiknek a forgalmát elemezni kellene, így viszont nem is lehet RELATED egy kapcsolat. Ennek opcionális megkerülése lehet az, hogy a mobil kliens kommunikációjában az RDP port tartományt jelentősen szűkíted, azt viszont stabilan a kliens felé tolod tovább. (Több kliens esetén több tartomány kell.)
Elküldés előtt átolvastam és oda jutottam, hogy ha a PBX is húz csatornát, akkor végül is van elemezhető forgalom - de az akkor is necces, hogy a kliens bár azon a porton jön, ami egyeztetve lett - de nem arról az IP-ről jön, ahova az alap kapcsolat nyílik. (Feltételezve azt, hogy az általad leírt eset, hogy a PBX is és a kliens is tud kapcsolatot húzni a Sangoma szerver felé, az meg össze tudja kötni őket direktben.)
Ha TLS felé nézelődsz, akkor azt érdemes lehet megnézni, hogy tud-e olyat a fogadó oldal, hogy ellenőrzi a kliens tanúsítványát. Ha igen, akkor az azért d egy komolyabb biztonsági réteget, mert csak érvényes tanúsítvánnyal rendelkező kliens jöhet be, illetve a támadó kapcsolata már akkor záródik, amikor (érvényes) kliens tanúsítvány hiányában nem épül fel a titkosított csatorna, hanem kirúgásra kerül a kliens. Persze, SSL implementációban lévő bug-ot ez nem fog meg - de ha azon bejönnek, akkor bármin bejönnek, ami TLS alapokon elérhető a netről.
A Sangoma-t nem ismerem, csak a tünetek alapján kibicelek. ;-)