[arm-allstar] Update issue...
Doug Crompton
wa3dsp at gmail.com
Thu Nov 15 14:42:48 EST 2018
Jim and et al.
The answer is to add the line to turn it back on in rpt.conf. There is no
way to distinguish local or remote. However I think you need to understand
the implications of allowing this. This means if I connect to a node,
yours or anybody else’s I can control that node like I was issuing the
command exactly as you would at your end. So I could connect to your hub,
issue a remote *76 and disconnect everyone from your hub. I could issue any
command that you could unless you had changed the command mapping in the
functions stanza which is generally not a good idea. You also cannot just
change the *4 mapping in the functions stanza as that mapping is only
recognized locally. It would just prevent you from doing remote access but
not someone else on the outside from doing it to your node.
We have not said much about this before this update because of the security
risks it presents. I purposely did not discuss it but we have talked about
restricting it privately for a long time now. Now that it is widely
advertised and known it becomes even more of a security risk.
Users notoriously do not pay attention to things like this and often don't
understand the impact. You may activate it locally but if the node you are
controlling, where you activated it, has outside IAX access it is
vulnerable.
I realize this is a big change for some users but ultimately a good thing
to do. As I pointed out using remote management with Supermon is a way
around it. This is the way I do it here and it works very well. Manage all
of your nodes from one application with multiple user password access. We
also have on our list of things to do a possible pin code added to the
remote command. This would make it much more secure when commands were not
issued over RF DTMF.
I am sorry for the inconvenience but if anyone wants to see how totally
destructive this could be just let me know you have it turned on and I will
connect to your node and cause some havoc! Kidding of course but it shows
you how vulnerable things have been and could be without limiting this by
default.
*73 Doug*
*WA3DSP*
*http://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*
On Thu, Nov 15, 2018 at 2:12 PM "James R. Pilgram via ARM-allstar" <
arm-allstar at hamvoip.org> wrote:
> Aloha Doug,
> With all due respect, I did read the blurb but as far as understanding
> the full ramifications of the update, that is a whole different issue. The
> only thing that was noted was the *4 command. Nothing was noted that dtmf
> commands behind your own firewall won't work. If I understand it correctly,
> *4 is across the network.
>
> I spent a number of hours beating my head on the desk last night trying to
> figure out what was happening. I use the IaxRpt client a lot to do
> connects and disconnects, node reboots etc on my own system.
>
> I understand your frustration of all the repeat questions on the same
> issues over and over. A lot of us don't think as deep as you do on this
> stuff.
>
> In the below explanation the *4 command was the focus. Supermon was touted
> but nowhere did it say dtmf commands wouldn't work from the IaxRpt client
> from this point on.
>
> The thing that kept throwing me was that dtmf tones did work from my HT to
> my repeater but not from my desktop and the repeater is also behind my
> firewall.
>
> What are we missing here?
>
> Aloha and Mahalo to you and David for your patience
>
> Jim NH6HI
>
>
>
>
>
>
>
> Original Message
>
>
>
> From: arm-allstar at hamvoip.org
> Sent: November 15, 2018 07:35
> To: arm-allstar at hamvoip.org
> Reply-to: arm-allstar at hamvoip.org
> Cc: wa3dsp at gmail.com
> Subject: Re: [arm-allstar] Update issue...
>
>
> I really wish users would actually read and understand the update
> announcements we send out. This was clearly described in the update
> announcement of November 12. I will repeat again here. There is a way
> around this security fix but you use it at your own risk and understanding
> of the possible consequences.
>
> Prior message -
>
> Allstar has a often little known and used command *4 mapped to ilink,4
> which can be used to send DTMF commands to OTHER nodes just like you would
> to your own. The node you would control needs to be connected for the
> control to work.
>
> While this is in some cases a useful command it also has enormous security
> risks if used in a nefarious way. To eliminate this problem we have turned
> off this feature by default in the hamvoip code with this update. Users
> who
> need to use it can turn it on with this added command in the node stanza
> of
> each node requiring it in rpt.conf. Leaving the command out or setting it
> to 0 has the same effect of restricting its use. Few users will have a
> need
> to turn this on -
>
> remote_dtmf_allowed=1
>
> This command is only needed at the node you want to control and on any
> nodes in between if it is not a direct connect. It is not required on the
> source node unless you also want it to be controlled from somewhere else.
> Keep in mind that it is a general security issue to turn this on and you
> should only to do so if it is needed. This is the classic "back door"
> which
> probably made sense when Allstar was a small group with trust between
> users. We will be introducing a pin number security feature for this in a
> future update which will make it more secure to leave it on.
>
> And I might also add that Supermon is an excellent alternative to control
> remote nodes. It has the capability to send DTMF directly, is independent
> of in-between nodes, You do not have to be connected to send the commands,
> is secure, and useable on any device that has a web browser.
>
>
> *73 Doug*
>
> *WA3DSP*
>
> *http://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*
>
> On Thu, Nov 15, 2018 at 11:34 AM "David McGough via ARM-allstar" <
> arm-allstar at hamvoip.org> wrote:
>
> >
> > Hi Vendel,
> >
> > This is a security feature added in the latest release. Remote DTMF
> > commands are disabled by default. To re-enable, in the rpt.conf
> > node stanza which you want to remote control, add the statement:
> >
> > remote_dtmf_allowed=1
> >
> >
> > 73, David KB4FXC
> >
> >
> > On Thu, 15 Nov 2018, "Vendel via ARM-allstar" wrote:
> >
> > > Hello all, I just updated my Controller/ Node software and I noticed
> > the DTMF commands issued by IAXRPT on my PC no longer work. The Android
> > version of IAXRPT works fine as does my HT. Here is what CLI shows when
> I
> > issue the commands,
> >
> > [Nov 15 11:15:45] WARNING[408]: app_rpt.c:11779 handle_link_data: DTMF
> > commands disabled! link string: D 42883 0 1 *
> > [Nov 15 11:15:45] WARNING[408]: app_rpt.c:11779 handle_link_data: DTMF
> > commands disabled! link string: D 42883 0 1 7
> > [Nov 15 11:15:46] WARNING[408]: app_rpt.c:11779 handle_link_data: DTMF
> > commands disabled! link string: D 42883 0 1 0
> > K2DSI*CLI>
> >
> > Any idea what’s happening? Thanks as always, Vendel/ K2DSI.
> >
> >
> > ---
> > This email has been checked for viruses by Avast antivirus software.
> > https://www.avast.com/antivirus
> > _______________________________________________
> >
> > ARM-allstar mailing list
> > ARM-allstar at hamvoip.org
> > http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
> >
> > Visit the BBB and RPi2/3 web page - http://hamvoip.org
> >
> > _______________________________________________
> >
> > ARM-allstar mailing list
> > ARM-allstar at hamvoip.org
> > http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
> >
> > Visit the BBB and RPi2/3 web page - http://hamvoip.org
> >
> _______________________________________________
>
> ARM-allstar mailing list
> ARM-allstar at hamvoip.org
> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>
> Visit the BBB and RPi2/3 web page - http://hamvoip.org
> _______________________________________________
>
> ARM-allstar mailing list
> ARM-allstar at hamvoip.org
> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>
> Visit the BBB and RPi2/3 web page - http://hamvoip.org
More information about the ARM-allstar
mailing list