<html theme="default-light"><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head><body style="font-family: tt;" text="#000000"><div
style="font-family: tt;">The recommendation is to segregate the devices.
Not just stick them in another subnet, and not to put them in another
segment with what needs to talk to them being dual-homed with routing
preference. There should be a device which can handle ACLs between the
IoT devices and the remainder of the networks. Most prosumer routers are
not capable of this. The irony is that the SOHO routers with a "guest"
network do actually create a segment behind a different NAT and no
devices on the inside network can talk to the gust network without
passing through a gateway and vice versa.<br><br>In order to do the
segment properly, you need a router with ACLs, you know, a firewall. You
can easily turn an old PC into a gigabit firewall using PFSense or
something similar. And if you don't have the luxury of running separate
fiber/copper for each network, VLANs work great. You can pick up a used
Cisco 3560G for ~$100. Ubiquity gear will let you run multiple SSIDs
each with their own VLAN. Once trunked back to the switch and firewall,
you have the segmentation. You can quickly write the rules that
trustedNet -> IoTNet allowed, and IoTNet -> trustedNet allowed w/
related established. The crappy part is that most of these IoT devices
rely on protocols like Bonjour to play nicely with all of your other
devices. Without running avahi or something similar, those packets will
stay in the IoT network. That is actually preferable for security's
sake, but makes things less user friendly. So you either run avahi or
put anything that you want to be able to communicate and sync via
service discovery protocols in the IoT net.<br><br>The actual
segmentation is easy. The making the devices work the way they were
intended once segmented, well that is a real pain.<br><br>As for Apple
devices not belonging in the enterprise - I disagree. As do many of the
Fortune 500. Apple TV's have made it incredibly easy and affordable for
companies to set up collaboration suites and use screen casting to
rapidly share data on commodity screens among people without having to
snake cables all over the room. There are multiple ways that
organizations choose to secure this, but generally if patching is done
in a timely fashion, and the device is appropriately limited in
communication, they pose about as much risk as a network connected
printer. As for their computers, well you can't really get any worse
than the current choice for enterprise desktops.<br><br>I was part of a
national infraguard committee a couple of years ago where we wrote about
this and made real suggestions including examples on how to do this in
response to rise in IoT malware like Mirai. Unfortunately, through
bureaucracy and watering down to not show disdain for this company or
that - the world got this recent recommendation which was terribly
unclear and not terribly helpful.<br><br>That is a long winded post to
not answer the original question, but I wanted to provide some
background and intent as one of the committee members tasked with making
recommendations to the InfraGuard powers that be on securing IoT in the
wild. If you have never experienced an InfraGuard national level
committee, well, I am not sure how to describe it as anything other than
"an experience." If you are not a part of InfraGuard, consider joining.
Sure they put out some "intelligence" this is not always that
intelligent. They put out some IoCs that vendors published months ago as
well. They also publish reports that are non-specific compilations of
general trends and threats to specific industries and sectors that are
quite good when used as data points in a mature CTI program. It is also a
great way to establish contact and relationships within DHS and the
FBI. Knowing them before the breach is important. Also, they know which
companies are worth working for, what the average entrance pay is, and
who is hiring because they interface and talk with both cyber and
physical security teams regularly.<br><br>Mac<br><br><span>Thomas Scott
wrote on 12/9/19 8:48 PM:</span><br><blockquote type="cite"
cite="mid:CALHr=U6oi0Wk291C8mPCtTMDtDG5SjetHx6QfXE9t09oEHg67Q@mail.gmail.com"><meta
http-equiv="content-type" content="text/html; charset=utf-8"><div
dir="ltr"><div class="gmail_default"
style="font-family:arial,sans-serif">@Michael - to remedy this, I've
seen customers deploy things like super flat topologies with VPLSs to
tie it all together. It's always fun to have to increase someones's mac
table size as their apple TVs were edging out their DHCP servers. I know
you're paying me to do this, but an obligatory "Your network is bad,
and you should feel bad" is always on the tip of my tongue. <br
clear="all"></div><div><div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><a
href="http://about.me/thomas.scott"
style="margin:0px;padding:0px;border:0px;outline:0px;font-size:14px;font-family:proxima-nova-1,proxima-nova-2,Tahoma,Helvetica,Verdana,sans-serif;vertical-align:baseline;color:rgb(43,130,173);text-decoration:none;line-height:18.2px"
target="_blank" moz-do-not-send="true"><div><table border="0"
cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td
style="line-height:0;vertical-align:bottom;padding-right:10px;padding-top:20px;padding-bottom:20px"
width="107" valign="bottom" align="left">
<a
href="https://about.me/thomas.scott?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=edit_panel&utm_content=thumb"
target="_blank" moz-do-not-send="true">
<img
src="https://thumbs.about.me/thumbnail/users/t/h/o/thomas.scott_emailsig.jpg?_1558409754_403"
alt="" style="margin:0px;padding:0px;display:block;border:1px solid
rgb(238,238,238)" moz-do-not-send="true" width="105" height="70">
</a>
</td>
<td
style="line-height:1.1;vertical-align:bottom;padding-top:20px;padding-bottom:20px"
valign="bottom" align="left">
<img src="https://about.me/t/sig?u=thomas.scott"
style="border:0px;margin:0px;padding:0px;overflow:hidden"
moz-do-not-send="true" width="1" height="1">
<div
style="font-size:18px;font-weight:bold;color:rgb(51,51,51);font-family:"Proxima
Nova",Helvetica,Arial,sans-serif">Thomas Scott</div>
<a
href="https://about.me/thomas.scott?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=edit_panel&utm_content=thumb"
style="font-size:12px;color:rgb(43,130,173);font-family:"Proxima
Nova",Helvetica,Arial,sans-serif" target="_blank"
moz-do-not-send="true">about.me/thomas.scott
</a>
</td>
</tr>
</tbody>
</table></div></a></div></div></div></div></div><br></div><br><div
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 9,
2019 at 10:14 PM Matt Graham <<a href="mailto:mhgraham@crow202.org"
moz-do-not-send="true">mhgraham@crow202.org</a>> wrote:<br></div><blockquote
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px
solid rgb(204,204,204);padding-left:1ex">On 2019-12-09 19:39, Michael
Butash wrote:<br>
> Linux networkmanager will assign a higher metric on non-ethernet<br>
> interfaces (ideally) to de-preference wireless over wired, but they<br>
> still both get an address. In the same subnet, the metric is what<br>
> determines preference. You can tweak metrics, but usually depend
on<br>
> the network interface and system preferences.<br>
<br>
This makes sense. The machine where I had 2 NICs on the same subnet, 1 <br>
wired, 1 wireless, had the wired NIC with metric 203 and the wireless <br>
one with metric 304 in the output from "route -n". Network Manager was <br>
not involved; just dhcpcd. OTOH, dhcpcd probably understands what <br>
"wired" and "wireless" are and sets up the routes and metrics <br>
accordingly. I think that if I set the metrics for enp1s0 and wlp3s0 to
<br>
the same number, I'd get the terrible network problems I described <br>
earlier.<br>
<br>
> This has been a problem for decades, but generally managed by<br>
> networking stack setting metric preference on routes. Wired ==
best,<br>
> wireless, vpn, others, less. [...] This is standard networking.<br>
<br>
This is actually the first time I've heard of the "metric" thing in the <br>
kernel routing table. This is probably because almost all of the <br>
machines I've dealt with over the last 20 years have had pretty simple <br>
networking configurations.<br>
<br>
-- <br>
Crow202 Blog: <a href="http://crow202.org/wordpress" rel="noreferrer"
target="_blank" moz-do-not-send="true">http://crow202.org/wordpress</a><br>
There is no Darkness in Eternity<br>
But only Light too dim for us to see.<br>
---------------------------------------------------<br>
PLUG-discuss mailing list - <a
href="mailto:PLUG-discuss@lists.phxlinux.org" target="_blank"
moz-do-not-send="true">PLUG-discuss@lists.phxlinux.org</a><br>
To subscribe, unsubscribe, or to change your mail settings:<br>
<a href="https://lists.phxlinux.org/mailman/listinfo/plug-discuss"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.phxlinux.org/mailman/listinfo/plug-discuss</a></blockquote></div>
<br><fieldset class="mimeAttachmentHeader"></fieldset><br><pre wrap="">---------------------------------------------------
PLUG-discuss mailing list - <a class="moz-txt-link-abbreviated" href="mailto:PLUG-discuss@lists.phxlinux.org">PLUG-discuss@lists.phxlinux.org</a>
To subscribe, unsubscribe, or to change your mail settings:
<a class="moz-txt-link-freetext" href="https://lists.phxlinux.org/mailman/listinfo/plug-discuss">https://lists.phxlinux.org/mailman/listinfo/plug-discuss</a></pre></blockquote><br><div
class="moz-signature">-- <br>Donald "Mac" McCarthy<br>
Director, Field Operations<br>
Open Source Context<br>
+1.602.584.4445<br>
<a class="moz-txt-link-abbreviated" href="mailto:mac@oscontext.com">mac@oscontext.com</a><br>
<a class="moz-txt-link-freetext" href="https://oscontext.com">https://oscontext.com</a><br>
</div></div></body></html>