TenTec Omni VII — a great idea, but not too secure

More ham stuff. Sorry gang. I’ll get off this kick sooner or later, but this is what I’m obsessing about these days.

Today’s rant is about a radio that I’d love to buy, but which has some pretty big security holes for a device that’s intended to be hung out on the public Internet.

I’ve been enchanted with the idea of the TenTec Omni VII and was very close to buying one, mostly because of how easy it is to put it on the Internet and it’s “software controlled” architecture. I still think it’s a neat radio but pretty bugged by the complacency implicit in it’s current design, so I dunno whether this is really the radio for me.

Here’s the scoop. I’ll lay it out in three different “cases” — Case One where you’re using the Omni VII on your own local network and not punching a hole in your firewall, Case Two where you’re letting people get at the Omni VII from the Internet (the usual config I would think — certainly the one I want to use) and Case Three which is a kludge where you insert a PC between your firewall and the Tentec.

Case One



Omni VII is configured with an “inside the firewall” IP address (eg and an arbitrary port (eg 5432). Firewall is configured to block traffic from the Internet (the usual configuration of a home firewall). The PC accesses the radio on the chosen port, entirely within the local network.


  • The radio isn’t visible from the Internet (unless you’re being attacked by a really heavy-duty hacker)
  • The radio’s 2-byte (0-65k, all numbers, I think pretty weak) password is not a big issue, as the machine is only being accessed from inside the local network.
  • There is no user-account “ring-fencing” on the radio, so if an intruder (say a child or guest) gets to the radio on the local network, they have complete control, but presumably you can stop them fairly easily by hitting them with a stick or something.
  • Denial of service attacks can only be directed to the firewall, not the radio so even if you’re getting pounded on you’re probably ok.


  • This is pretty secure. You’re running a server (the radio), but you’re not exposing it to the Internet, so fishing expeditions to find the radio will fail (with all the caveats about nothing being totally secure).
  • It’s also not too useful — you can only get to the radio from your local network, so the whole point of an Internet-accessed remote-controlled radio is lost.

Case Two



  • Omni VII is configured with a non-routable “inside the firewall” IP address (eg and an arbitrary port (eg 5432). Firewall is configured to address-translate and forward traffic from a public-routable IP address to that address/port combination.


  • The Omni VII is a public server that is visible to anybody on the Internet (with all the attendant security concerns that any public server has)
  • The IP-address/port/password combination is visible for port-scanning attacks (the radio does not respond to a query unless all three of those are correct, however)
  • There is no user-account “ring-fencing”, so once the address/port/password have been cracked, all capabilities of the radio (receive, transmit, reconfiguration) are available to the intruder ““ with profound implications for the radio’s license-holder, who will be held accountable for any malicious behavior.
  • The radio is visible for denial-of-service attacks without the need to hack into the radio


  • The radio is available to anybody on the Internet, there’s no capability to distinguish between allowed (white-listed) IP addresses and all others
  • The radio has no limit on the number of failed logon attempts, nor is there any time-delay between attempts, so address/port/password combinations can be presented very quickly
  • The radio doesn’t log failed logon attempts, nor does it have notification capability to alert the owner that their server (radio) is being attacked
  • The full capabilities of the radio are available once it’s been penetrated, there’s no “account” structure, nor is there the concept of granting user-rights in the software
  • The software to access (and exploit) the capabilities of the radio is publicly available on the Internet
  • The source-code of the software is publicly available on the Internet, so a cracker can read the code to understand the handshaking protocol


I spoke with folks at TenTec about this. Here are some of the concepts they presented to calm me down.

  • The radio doesn’t respond unless you get the address/port/password combination correct which makes it pretty stealthy
  • That address/port/password combination represents a lot of combinations for a hacker to try

Those are Good Things. But that defense presumes that the cracker doesn’t have a lot of brute force available for their attack — which makes me nervous in this day of zombie-pools that number as high as 1.5 million computers (here’s an article about that).

The kids who develop and trade hacking scripts could easily develop a module that looks for these radios and simply add it to the port-scanning scripts that they’re already running. Screaming through 65000 possible passwords per address/port sounds a little extreme, but suppose the Bad Guys are terrorists instead of script-kiddies and they’re looking for these radios as part of a broader attack. Combining the script with a zombie-net of a few hundred thousand computers could flush out a lot of radios.

Suggested Changes

The bad news is that this radio is pretty wide open. The good news is that some relatively simple changes could make it a lot better.

  • Increase the size of the password from its current two-byte (65k possibilities) size. Tacking on another byte would get you 16 million possibilities, two more bytes would get you to up to almost 5 billion. A couple bytes of storage seems like cheap insurance.
  • Introduce the concept of authentication failure — after N attempts the radio won’t accept any more attempts for some period of time, after M cycles of that the radio locks out all external log-in attempts until it has been reset from the front panel.
  • Introduce the concept of “accounts” so that the radio’s owner could grant varying levels of authority to different users (while at the same time adding another layer of cracking difficulty). I’d like to see at least 4 levels of access;
    • “Eavesdropping” — for those folks that you just want to let listen to whatever the radio is doing, but not grant any control
    • “Receive only” — for folks who you’d like to grant SWL rights
    • “Transceive” — for hams who can use the radio to transmit and receive
    • “Administrator” — for super-users who can also reconfigure the radio
  • IP-address white-listing and blacklisting as a way to screen out known black-hats and grant rights to your club or friends
  • Some kind of security logging and alert capability, so that if you’re getting pounded by a black hat you can figure out what’s going on.

“Why all this crud?? After all, this is just a radio for crying out loud” you ask. Well, it’s not just a radio any more. It’s a server, on the Internet — a place filled with great folks and other folks who aren’t so great. Since we’re responsible for what our stations do, I’d like to see some tools to help us protect those resources from being attacked.

Here’s one solution, if TenTec leaves the radio the way it is…

Case Three



Omni VII is configured with an “inside the firewall” IP address (eg and an arbitrary port (eg 5432). Firewall is configured to address-translate and forward traffic from a public-routable IP address to a PC running remote-access software. The PC in turn accesses the radio on the chosen port.


  • The Omni VII is no longer directly visible to the Internet, the PC is
  • The “signature” of the radio is no longer visible, so intruders won’t be able to find a radio just by port/password scanning, only the PC (which has a firewall, logging and account-structures in addition to passwords)
  • The 2-byte password is now masked behind the PC’s much stronger username/password authentication, plus any authentication provided by the remote-access software — thus adding two layers of much stronger authentication
  • There is still no user-account “ring-fencing” on the radio, so if an intruder gets to the radio they still have complete control
  • The radio is no longer visible for denial-of-service attacks but the PC is
  • The “connect this radio directly to the Internet” feature is lost, since this approach requires a PC

That last sentence is a killer. As I said at the top of this post, the simplicity of dropping this radio right on the ‘net without an intervening PC is one of the two things that drew me to this radio in the first place. Putting a PC in the chain makes me sad — but I’m really uncomfortable just hanging this device out there on the big bad Internet with the sketchy security that’s on it right now.

Marcie says it’s time for a walk so I’ll stop obsessing about this and go get some fresh air on this beautiful spring day.

I’ll give the TenTec folks a heads up and invite them to comment. You’re invited to comment as well.


Some months have passed.  I wound up buying a Kenwood TS-2000 and marrying it up with TRX-Manager in the “Case Three” configuration up above.  I’m really close to testing the over-the-Internet configuration.

But I realized that I need to be able to dump the radio if the computer or software locks up.  Otherwise I could envision the following (bad) scenario…  I’m logged on to the radio.  I key the mic while it’s keyed the computer or software crashes.  Now the radio is keyed on and I can’t get to it to key it off.

The solution to this problem (remote-controlled power switch) is also a solution to the security problem, hence the update to this post.  Putting the TenTec on one of these switches would make me a lot more comfortable with Case Two because, unlike the TenTec, the switches have more robust username/password security built in.  In that configuration, one could power up the radio when it is needed and leave it powered off the rest of the time.  And, if anybody ever captured the radio, you could power it off.

Here are a couple links to switches that I’m looking at;

Synaccess NP-02 

DataProbe iBoot 

Right now, I’m leaning toward the (geekier, cheaper) Synaccess…