Hi, to increase the security for remote extensions I would like to limit a sip-peer to a specific MAC address. Is it possible to "hook into" the authentication mechanism in asterisk and allow/deny incoming registrations? cheers urban
> to increase the security for remote extensions I would like to limit a > sip-peer to a specific MAC address. Is it possible to "hook into" the > authentication mechanism in asterisk and allow/deny incoming > registrations?This would be only mildly useful on the same subnet and completely useless over the internet. -HJC
Henry J. Cobb wrote:>> to increase the security for remote extensions I would like to limit a >> sip-peer to a specific MAC address. Is it possible to "hook into" the >> authentication mechanism in asterisk and allow/deny incoming >> registrations? >> > > This would be only mildly useful on the same subnet and completely useless > over the internet. > > -HJC > >I think it would work just fine over the internet using a bridged VPN. Thanks, Steve Totaro
On Sun, 2006-05-28 at 23:41 -0400, Steve Totaro wrote:> Henry J. Cobb wrote: > >> to increase the security for remote extensions I would like to limit a > >> sip-peer to a specific MAC address. Is it possible to "hook into" the > >> authentication mechanism in asterisk and allow/deny incoming > >> registrations? > >> > > > > This would be only mildly useful on the same subnet and completely useless > > over the internet. > > > > -HJC > > > > > I think it would work just fine over the internet using a bridged VPN.even on a local network this can be forged. If you cant control the device that sends this information it is user supplied data, even over a vpn (which uses a virtual interface not the physical one). It has the same value as any user supplied data - other than perhaps its additional data which makes guessing slightly harder. TLS might be a better way to go since it would require a certificate that you can control the issuance of, but that certificate can be stolen and the remote end point would need to support the same scheme that you use (fortunately there are standards that make this easier with some devices but most dont implement this). A vpn would provide security in that it would make it harder for someone to eavesdrop on the auth and attempt to derrive the password, however there is overhead associated with that. At least 1 IP packet per real packet (sometimes more) on the network side, and the crypto parts on the cpu side. For the server you would want to have a hardware based crypto card to deal with the VPN connections... -- Trixter http://www.0xdecafbad.com Bret McDanel Belfast IE +44 28 9099 6461 DE +49 801 777 555 3402 Utrecht NL +31 306 553058 US WA +1 360 207 0479 US NY +1 516 687 5200 FreeWorldDialup: 635378 http://www.sacaug.org/ Sacramento Asterisk Users Group -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20060528/e2d2d1f6/attachment.pgp
On Sun, May 28, 2006 at 11:41:00PM -0400, Steve Totaro wrote:> Henry J. Cobb wrote: > >>to increase the security for remote extensions I would like to limit a > >>sip-peer to a specific MAC address. Is it possible to "hook into" the > >>authentication mechanism in asterisk and allow/deny incoming > >>registrations? > >> > > > >This would be only mildly useful on the same subnet and completely useless > >over the internet. > > > >-HJC > > > > > I think it would work just fine over the internet using a bridged VPN.Anyway, Asterisk does not get this information. This is something you have to set up at the firewall level (e.g.: iptables/netfilter on Linux). At most the firewall can "color" the packets of some SIP connections to allow another component to filter by that (e.j: iptables -j MARK) Not to mention the well-known fact that mac addresses can also be faked. -- Tzafrir
trixter aka Bret McDanel wrote:> On Sun, 2006-05-28 at 23:41 -0400, Steve Totaro wrote: > >> Henry J. Cobb wrote: >> >>>> to increase the security for remote extensions I would like to limit a >>>> sip-peer to a specific MAC address. Is it possible to "hook into" the >>>> authentication mechanism in asterisk and allow/deny incoming >>>> registrations? >>>> >>>> >>> This would be only mildly useful on the same subnet and completely useless >>> over the internet. >>> >>> -HJC >>> >>> >>> >> I think it would work just fine over the internet using a bridged VPN. >> > > even on a local network this can be forged. If you cant control the > device that sends this information it is user supplied data, even over a > vpn (which uses a virtual interface not the physical one). It has the > same value as any user supplied data - other than perhaps its additional > data which makes guessing slightly harder. > > TLS might be a better way to go since it would require a certificate > that you can control the issuance of, but that certificate can be stolen > and the remote end point would need to support the same scheme that you > use (fortunately there are standards that make this easier with some > devices but most dont implement this). > > A vpn would provide security in that it would make it harder for someone > to eavesdrop on the auth and attempt to derrive the password, however > there is overhead associated with that. At least 1 IP packet per real > packet (sometimes more) on the network side, and the crypto parts on the > cpu side. For the server you would want to have a hardware based crypto > card to deal with the VPN connections... >I have had great luck with OpenVPN, any reason why you like hardware? I find OpenVPN to be just as reliable and stable as any hardware VPN such as Cisco. VPN will also make it very difficult to sniff or snoop on RTP streams if eavsdropping is a concern. I even have OpenVPN running on a Linksys running OpenWRT and have rock solid connectivity unless there is a carrier issue out of my control. Forging a MAC address is trivial on most devices. Forge a MAC address on a LAN (or bridged VPN) and you will quickly find that the conflict will cripple or cutoff your connectivity since switches will become confused where to send the packets and have funky arp entries. Thanks, Steve Totaro