Looking at the questions and setup notes, using the Vyatta and OpenSBC
solution would be a good start. Run that server as the firewall, SBC and
OpenVPN solution all in one, this would encrypt traffic over the network
as long as each building had its own Media server (also behind the above
setup) Running it all as an HA system within the VPN would mean it is
all encrypted over IP.
The only problem I see could be a slightly higher ping time and the
setup would have to be forced routes through openSBC. This would work
for Internal calls between buildings, but once the signal enters the
PSTN it would require the other end to run encrypted lines to stop
eavesdropping.
If this case were to be set up correctly then the only thing that could
cause eavesdropping would be internal breaks in the network, so access
to the VPN would have to be limited to Admins only. Setting the VPN up
on a different subnet would also go towards making it more secure.
This is a possible solution that I have not tried, but I have had to run
end to end security for other things like internal messaging and calling
through desktop programs. This was not easy as the end user is basically
not security concious as it "isn't My job" mentality continues to function.
Regards
Alan
Online Systems wrote:
Hello,
You may be better off just tacking up site to site VPN's via appropriate
endpoint hardware between your locations and compartmentalizing your
traffic. This should take care of your site to site calling and will
flatten your voice network a bit which should make it easier to manage
centrally.
You might also want to do a quick analysis of how much it will cost to
purchase a few switches (10/100 stackable managed should be fine for
most, after all you are talking about 90k per call worst case), PoE
midspans (optional), network cable if you don't happen to have existing
extra jacks at the desks, etc. and physically separate the networks if
concerned about security. It also makes monitoring / troubleshooting on
the voice network much easier. Buy some patch cord locks to install on
the cabling so the patch cables cant be removed from the phones or the
wall to prevent unauthorized devices from being installed on the network.
Being occasionally involved in higher security installs where the
customer is concerned about these sort of issues, it always helps to
step back and take a look at the problem from a different perspective.
Sometimes there are lower tech, affordable solutions to your obstacles
that end up working better than choosing the more complicated solution.
Honestly you have a greater chance of someone overhearing your
conversation in the next office than listening to your telephone
conversation via more sophisticated means, (that is unless you happen to
go to work in a heavily armored Faraday cage ever day).
I would be very surprised if using such a solution above would even
approach the capital or recurring costs of something like a Cisco
solution, and am confident that the administration load would be less
with a best of breed SipECS solution.
Josh
[email protected] wrote:
Hi Michael,
I don't think you'll get all parties (pbx, phone, gateways) to encrypt traffic.
that´s really a pitty
There's also two different types of traffic that need to be considered for
encrypting also... the signaling and the voice traffic.
SIPS/SIP over SSL and SRTP...
At this point in SIP history if this is a "got to have", you might be better
off with a proprietary solution that encrypts end to end.
I had to convince my boss not to buy a cisco solution and now you suggest this.
The other thing you really need to do is ask yourself, why do I need to encrypt
voice on my local network?
We have ~ 30 buildings connected via WAN, which doesn´t belong to us. The lines
are rented.
How much valuable information is being transmitted via voice through a point at which it might be >captured on your local network?
Getting access to our LAN is too easy, sadly
In general there is much less valuable information transmitted via voice than
via data.
Well, not in our case
If you look at my mentioned cases, where can I encrypt the paths with SIPxecs?
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
