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.
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.
The actual segmentation is easy. The making the devices work the way
they were intended once segmented, well that is a real pain.
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.
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.
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.
Mac
Thomas Scott wrote on 12/9/19 8:48 PM:
> @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.
> <https://about.me/thomas.scott?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=edit_panel&utm_content=thumb>
>
> Thomas Scott
> about.me/thomas.scott
> <https://about.me/thomas.scott?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=edit_panel&utm_content=thumb>
>
>
>
>
> On Mon, Dec 9, 2019 at 10:14 PM Matt Graham <mhgraham@crow202.org
> <mailto:mhgraham@crow202.org>> wrote:
>
> On 2019-12-09 19:39, Michael Butash wrote:
> > Linux networkmanager will assign a higher metric on non-ethernet
> > interfaces (ideally) to de-preference wireless over wired, but they
> > still both get an address. In the same subnet, the metric is what
> > determines preference. You can tweak metrics, but usually depend on
> > the network interface and system preferences.
>
> This makes sense. The machine where I had 2 NICs on the same
> subnet, 1
> wired, 1 wireless, had the wired NIC with metric 203 and the wireless
> one with metric 304 in the output from "route -n". Network
> Manager was
> not involved; just dhcpcd. OTOH, dhcpcd probably understands what
> "wired" and "wireless" are and sets up the routes and metrics
> accordingly. I think that if I set the metrics for enp1s0 and
> wlp3s0 to
> the same number, I'd get the terrible network problems I described
> earlier.
>
> > This has been a problem for decades, but generally managed by
> > networking stack setting metric preference on routes. Wired ==
> best,
> > wireless, vpn, others, less. [...] This is standard networking.
>
> This is actually the first time I've heard of the "metric" thing
> in the
> kernel routing table. This is probably because almost all of the
> machines I've dealt with over the last 20 years have had pretty
> simple
> networking configurations.
>
> --
> Crow202 Blog: http://crow202.org/wordpress
> There is no Darkness in Eternity
> But only Light too dim for us to see.
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
> <mailto:PLUG-discuss@lists.phxlinux.org>
> To subscribe, unsubscribe, or to change your mail settings:
> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
--
Donald "Mac" McCarthy
Director, Field Operations
Open Source Context
+1.602.584.4445
mac@oscontext.com
https://oscontext.com
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss
(text/plain)