<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 6/16/2017 8:56 AM, DuaneVT . wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CABhxdJ==PhKxPn3yjfiU=G5q2zm0BGDQwtiJo_SbD069uTWmqQ@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_default" style="font-family:comic sans
          ms,sans-serif;font-size:small">Good to know about RC1. I had
          months ago disabled access to root via ssh. Even I have to ssh
          in as SU with a password. I was wondering if this exploit hack
          was seen by others, just a heads-up.</div>
        <div class="gmail_default" style="font-family:comic sans
          ms,sans-serif;font-size:small">Duane KA1LM</div>
      </div>
    </blockquote>
    <br>
    ANY port that you have open to the outside world is going to add to
    the risk you enjoy (!) from being connected to the network.  There
    are well-known ports; in the U/Lin-UX world, the goldmine ports (ie
    those which are reserved to the root group, are those port #s <
    1024...and once you have root, all bets are off as to what you can
    do.<br>
    <br>
    That many people have their routers set up to automagically
    establish persistent connections when any outbound traffic port is
    opened, this means that if your machine is pwned and a rogue daemon
    sets up a channel to a command and control system, YOUR machine is
    part of a botnet...doing who knows what.<br>
    <br>
    In 7 years of running an asterisk box, I have NEVER had a reason,
    while away from the site, of having to log in to do something.  Now,
    it may be different if your box is on a mountain top and
    inaccessible for 4 months of the year...but, my rule is, if you can
    drive there, then I don't enable shell access from the outside.  I
    turn off, on my router, PnP.  I deny ANY to ANY inbound connections
    as the default ACL.  My boxes have static IPs on the inside of a
    NAT, and ports are routed to specific host/ports.  Fail2ban is
    running, and, as a luxury, my logs are NOT stored on the machines
    that ARE accessible; the first thing that a miscreant is going to do
    is try and erase system log entries of what they've done.  <br>
    <br>
    So...how to do those things that you have to do administratively? 
    Think belt and suspenders.  <br>
    <br>
    One of the nice things about asterisk is that you can script almost
    anything both inside the application as well as the operating system
    to respond to DTMF.  Now, I realize that not everyone has this
    ability, but, being all my boxes are accessible via the net in some
    manner...I have a receive-only node on an oddball frequency in a
    second location locally, which also has an echolink node
    assigned...and have scripted the admin functions *I* use on a
    regular basis.  Things like reboot the box...restart asterisk...even
    down to connect and disconnect nodes (ie command *node#3 or *node#1
    to connect or disconnect node#), etc.<br>
    <br>
    Add in the fact that you can have control over the GPIO pins on the
    DMK and RIM URIs, and you can even do relay-driven (I like
    electromechanical stuff) things: turn on fans, turn off fans, turn
    on power, turn off power...the possibilities are endless, if you
    think through just what it is that you need to when you supposedly
    have to log in via a shell.  Haven't quite worked out how to mount a
    cdrom that has a clonezilla image of a fresh box to restore a system
    from a DTMF command...but, I'm sure with some hacking, even that
    could be done to remotely restore a system that HAS been trashed.  <br>
    <br>
    In my opinion, we have to get away from thinking that we need to
    have terminal access to what is (or should be) essentially an
    appliance that controls radios.  And, no, I'm not thinking that a
    web interface is necessarily the way to go either.  <br>
    <br>
     <br>
  </body>
</html>