SSH tunneling is amazing with accessing sip phones inside a network for a voip
technician but VPN is native to all OS now a days and it's sort of known to
some of the end users.
If SSH tunneling was an easy and secure solution (by secure I mean if it was
easy to train end users to use it properly in a timely manner) for END USERS
then it would have been common place with current voip providers to secure
their networks. Or maybe got into ATA boxes. Or Vonage and the like would have
forced their users to use it. All I am saying is that it's not a user friendly
way of doing things. You can't sell a soft phone service saying turn on SSH
access first and then run the soft-phone in order for my service to work. I
hope you see that I am looking at this from the business perspective of things
which is usually the case for mobile users (e.g. hosted solutions, etc...)
Also, if a system comes under DDoS by SSH then sshd stops accepting even legit
users. Check out "MaxStartups" in sshd_config man pages.
Oh, there is a solution that would make things easier for end user. A custom
softphone that supports and automates SSH tunneling all in one program. An
Asterisk solution which can put customer on hold in case their is a drop in
call for one party due to SSH disconnect.
"Dear customer, please wait and we will shortly connect the other party. Their
connection was dropped due to a disconnect in their SSH connection" :)
-Bruce
> Date: Tue, 2 Feb 2010 23:24:49 -0500
> From: [email protected]
> CC: [email protected]
> Subject: Re: [on-asterisk] Secure Asterisk
>
> Bruce N wrote:
> > SSH and tunneling has it's own problems. SSH is not stable and it can
> > disconnect due to minor delays in network or idles. Putty doesn't have any
> > option for re-connect. Even if a program did then you still probably had to
> > genera[te] keys for auto-login which in itself is very time consuming. On
> > top that, SSH will be yet another application opened up in the OS. Also,
> > what about those hard SIP phones? No SSH possible from those unless you
> > bridge them to a PC. So things are complicated with SSH...I don't think
> > it's worth the try.
> >
> >
> SSH is pretty stable when everything is configured reasonably (i.e., I
> use it from about 15 locations and
> only one of them causes the disconnects you mention, I think it runs a
> windows firewall though).
>
> Time consuming to generate keys?
>
> $ time ssh-keygen
> ...
> 0m6.70s real
> $
>
> Six seconds per user doesn't seem a lot, unless you're dealing with
> hundreds or thousands of users.
>
> Sure, hard SIP phones can't do SSH. Who walks around with an Aastra hard
> phone in their back pocket? :-)
> If people are using those, like I said, they're probably at a fixed
> location, with a static (or reasonably
> so) IP, and you may find it simpler let in SIP from that location.
> >
> >
> > Duane's prposal is a less problematic solution. But [it] does introduce
> > overhead. Higher bandwidth needed.
> >
> Every purchase has its price. VPNs can also be problematic behind firewalls.
> >
> >
> > Probably a better solution would be to install Fail2Ban and set really high
> > ban time for IPs that violate proper password rules and set low tolerance
> > for number of tries (e.g. ban if the user gets the password wrong even
> > once). Fail2ban takes care of attacks on SIP, apache, ssh, you name it
> > network services... that can run on linux.
> >
> Banning by IP is yet another technique. There are many software packages
> that implement it,
> some OSes have some of this capability built in.
>
> Security is hard. There is no single "one size fits all" solution. Some
> of these techniques will
> be more useful than others.
>
> Your mileage *will* vary.
>
> Oh, and good luck to all. I notice there was another security release of
> Asterisk itself quite recently:
>
> > SECURITY update to 1.6.0.22, fixing CVE-2010-0441, an unauthenticated
> > crash in SIP (and only this, thanks to Asterisk developers for pushing
> > security fixes separately from other changes).
>
> Cheers
> Ian
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
_________________________________________________________________
