<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hmm, let's see:<br>
<ol>
<li>If you happen to get root access on any of my Linux boxes and
do "rm -rf /" or "rm -rf /bin" or "rm -rf /sbin" or "rm -rf
/sys" or "rm -rf /usr" or "rm -rf /lib" (or any other
modifications to those directories), nothing will happen.
Depending upon what I've been doing recently, "rm -rf /etc" (or
other directories) may or may not work. When I used SCSI hard
drives (which back then typically had a jumper to force
read-only access), that was enforced by hardware in addition to
a software configuration. Whether I make similar mods to the
MikroTik OS configuration, remains to be seen.</li>
<li>I run bind (named), ntpd, and postfix in a chroot environment.</li>
<li>SSH does not run on port 22 (nor does it run on a port # >
1024). PostgreSQL is not available on port 5432. Postfix does
not allow submissions on port 25. I don't use self-signed
keys. I don't type root passwords. Etc.<br>
</li>
<li>I've run externally-available DNS servers for 15 years, and
I've <b>never</b> allowed recursive queries outside my LAN.</li>
<li>Before I installed FiOS, I asked the (then) Verizon rep
whether if could support idiot customers with had back-door
access to the provided modem, and when the answer was yes, I set
up a DMZ. When people visit my house and need WiFi or wired
access, they're in the DMZ.<br>
</li>
</ol>
I have run various versions of Windows for decades, and until
recently without anti-virus software (some of it is just soothing or
alarming junk), without ever getting a virus. However, before I
made the above modifications (except the last) to my Linux boxes
over a decade ago, I did have an otherwise-secure Linux box
compromised by a vulnerability in ISC bind: my server was #3 in a
five-stage leapfrog attack on a bank. This was before the above
modifications over a decade ago. Since then, I've been paranoid.
You too can be paranoid, with only a little effort (or experience).<br>
<br>
Oh, and when I was run running a public NTP server (my one serious
mistake; see: <a class="moz-txt-link-freetext" href="http://www.ultimeth.com/Abandon.html">http://www.ultimeth.com/Abandon.html</a> ), I had people
accessing my NTP hostname without getting permission, so I changed
the hostname (and let authorized users know), and then pointed the
old hostname to 127.0.0.1 (I have other "useful" but unsupported
services similarly configured). Boy, did that make one person mad;
he complained to the NTP mailing list (which was somehow
unsympathetic). I guess entitlement is alive and well on the
Internet ...<br>
<br>
So yes, I'll take the risk that a change to the HamWAN network will
render my link temporarily unusable.<br>
<br>
-- Dean<br>
<br>
<div class="moz-cite-prefix">On 2014-03-11 17:11, Jeff Francis(tm)
wrote:<br>
</div>
<blockquote
cite="mid:CA+3iGtCUhNWHRjz8Q1Gz6jxQeZ4kWk4ZfNtyWtQKOCZcPm96Uw@mail.gmail.com"
type="cite">
<div dir="ltr">If you put your modem outside of your firewall
(which is where mine is, in spite of the fact that I haven't
successfully connected yet), your exposure is no worse than
being attacked from another host connected to the HamWAN
network*. You *do* have a firewall on your network, right? ;^)
<div>
<br>
</div>
<div>* Well, ok, speaking as a professional security geek (which
is what I do for a living), it *is* in fact very slightly
worse. Assuming the firmware of the modem could be
compromised to launch attacks, it's a higher-bandwidth
lower-latency connection to pound on your network from, which,
in theory, is less secure. But given the speed of the HamWAN
network, the delta is pretty small, and given that the modems
run a semi-proprietary (and fairly uncommon) OS, the odds of
the modem itself becoming a leapfrog platform for staging
attacks are pretty insignificant. And again, assuming you've
got a halfway decent firewall in the middle (ie, not just a
cheap consumer device that does NAT, but an actual firewall),
I wouldn't worry about it.</div>
<div><br>
</div>
<div>Jeff N0GQ</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Mar 11, 2014 at 4:27 PM,
Nigel Vander Houwen <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:nigel@k7nvh.com"
target="_blank">nigel@k7nvh.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">To add
to what Cory said,<br>
<br>
The goal is not to remove control or access from the user.
It's simply for network management. It's very much an
experimental network, so if you choose not to allow admin
accounts on your modem, the network may change and you
will be responsible for maintaining it yourself.<br>
<br>
I'd also like to bring up a parallel with other commercial
ISPs. You end up in the same situation. For example, with
comcast, you can either rent a modem from them, which they
have full admin control of, and may not give you any
access at all, or you buy a modem yourself, and configure
it to work with them, and any issues or changes are your
own responsibility.<br>
<br>
For us the problem is far more significant. The HamWAN
network is changing and evolving all the time, unlike a
network like comcast's which is relatively stable. The
methods of connecting / authenticating to the network will
change, and you should be prepared for that if you decide
that allowing a few trusted users on your modem is an
unacceptable risk, despite these users having full
administrative access to ALL of the rest of the HamWAN
network routing your packets.<br>
<br>
In any case, as Cory said, it is your choice, but the
recommended one is what's documented on the wiki
instructions.<br>
<br>
Nigel K7NVH<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>