<div dir="ltr">In the past, many switches, when confronted with enough traffic, have fallen back to acting like hubs.  Nefarious people have generated large amounts of traffic in order to trigger that condition and allow sniffing.  This specific problem is an example of a larger issue: When securing networks, only security in depth is practical.<div><br></div><div>Bugs (and designed behavior that is problematic) can always cause one or more layers to stop enforcing expected security guarantees.  That's why people get so excited about, e.g., the end-to-end encryption of something like Signal.  Even if something goes wrong (like sniffing inside the cloud service provider's network) you still have some guarantees.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 11, 2021 at 10:01 AM Neal Rhodes via Ale <<a href="mailto:ale@ale.org">ale@ale.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">Ok, maybe slightly OT BUT there is a linux server involved...<br>
<br>
Again looking at what security is really needed, but going deeper.   <br>
What assets need protection?  Turns out, everything is in the cloud.<br>
<br>
The question is: if we make a downstairs Wifi router be an access point <br>
instead, do we really expose anything?<br>
<br>
<br>
Primary EdgeRouter-X Router: (has 5 ports; Eth1-5 are all on <br>
192.168.1.x)<br>
     - Eth0 - WAN port goes to Comcast Router;<br>
     - Eth1 - NetGear jgs524pe Switch in office<br>
              - Office Win10 Desktop<br>
                      - https access to Banking, Financials, Roster   <== <br>
Primary Security Concern<br>
              - Polycon phone-set<br>
                      - Office Win10 Desktop<br>
                            - https access to Banking, Financials, Roster <br>
  <== Primary Security Concern<br>
              - Linksys Wifi Access Point<br>
                      - Office Notebooks<br>
<br>
     - Eth2 - NetGear jgs524pe Switch downstairs<br>
              - ASUS Wifi in Hall downstairs, configured as Access Point<br>
                      - Ubuntu Desktop on Wired port, running Jamulus on <br>
forwarded UDP port 22124  <== Can this be a Threat?<br>
                      - Children in Community Schools doing Distance <br>
Learning with personal notebooks <== Can this be a Threat?<br>
<br>
My understanding is that due to the nature of how a switch works, so <br>
long as office staff always use wired connections to do HTTPS cloud <br>
work, there is simply no way for anything downstairs, on a different <br>
switch, do sniff the HTTPS traffic.   Even other desktops on the same <br>
switch in the office could not sniff the HTTPS traffic of the other <br>
desktops.    So long as those computers leave the windows firewall <br>
running, don't allow RDP, etc, I don't see an exposure.<br>
<br>
It would seem dubious for Office computers to use Wifi connections for <br>
banking, and we should make that a taboo.<br>
<br>
BUT, I can't see how an exploit could piggyback in on a child's notebook <br>
and gain any sniffing access upstairs?   Nor could a flaw in the Jamulus <br>
server which ultimately provided a linux command line result in getting <br>
access to financial computers.<br>
<br>
I was debating about firing up Samba on the Linux box to make it easy to <br>
grab multi-track audio recordings, but... maybe we'd best not, and use <br>
winScp instead.<br>
<br>
Thoughts?<br>
<br>
Neal<br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
<a href="https://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">https://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">  Ed Cashin <<a href="mailto:ecashin@noserose.net" target="_blank">ecashin@noserose.net</a>></div></div>