Lee H. Marzke on 7 Jul 2017 17:47:57 -0700 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: [PLUG] Fios Quantum Gateway Router / Cabling type |
From: "Rich Mingin (PLUG)" <plug@frags.us>
To: "Philadelphia Linux User's Group Discussion List" <plug@lists.phillylinux.org>
Sent: Friday, July 7, 2017 7:55:23 PM
Subject: Re: [PLUG] Fios Quantum Gateway Router / Cabling type
Using the provided router or your own equipment (RG6 or ethernet into the premises) is a consumer choice and can be setup either way remotely. Only one connection will be "hot" at any time, though.While you must have a Verizon router to get their VOD services and program guide, it is not otherwise requried. In my case, I like the 802.11ac access point built into the Quantum gateway, but I don't like that Verizon retains remote root access, which is denied to the end user, and they control firmware updates. When I had a set-top box, I compromised by having the FIOS gear connected just behind my router, without local network access. The RG6 MoCA is bidirectional, so if the FIOS gateway has internet access via the ethernet WAN connection, the RG6 is "hot" for the set top boxes.
Now my internet comes out of the ONT on CAT5E outdoor rated plenum, into the basement, into a dual port NIC that's passed through to a PfSense VM. The output on the other port goes to my big switch, so my cabling topology is pretty flat, which I like.Now that I no longer have any set top boxes in house, I've been keeping the FIOS gateway on it's own VLAN. If I pick up another refurb AC-87R at Microcenter, I'll probably unplug the FIOS gateway entirely. I don't trust it.
On Fri, Jul 7, 2017 at 9:35 AM, Lee H. Marzke <lee@marzke.net> wrote:
----- Original Message -----
> From: "Rich Freeman" <r-plug@thefreemanclan.net>
> To: "Philadelphia Linux User's Group Discussion List" <plug@lists.phillylinux.org>
> Sent: Friday, July 7, 2017 7:19:50 AM
> Subject: Re: [PLUG] Fios Quantum Gateway Router / Cabling type
> On Thu, Jul 6, 2017 at 10:37 PM, Lee H. Marzke <lee@marzke.net> wrote:
>>
>> I believe VMware has government certification that verify that. The old days
>> of requiring an air-gap between
>> different security levels is long gone - and VMware NSX provides much more
>> security than air gap.
>
> I wouldn't call a firewall an "air gap." When you have an air gap
> between different security levels there is simply no way for them to
> communicate at all.
Sorry, the old method of separating workloads was to put them on separate hypervisor clusters
with no network connections between them - or an air-gap. This is in-efficient as you have
to break up clusters by security zone, and resources are wasted in each new cluster.
VMware has been advocating putting different security workloads together on the same hypervisor
with a virtual firewall around each VM that follows it wherever it moves.
>
> In any case, how can anything provide "much more security" than either
> a firewall or an air gap, especially at that level of abstraction?
Because manually written firewall rules get horribly complex, and as a rule they
are added, but never removed, so all this old cruft gets left behind. So writing
rules for each VM, each tier of a application, and separating each multi-tier app
from another ( together called micro-segmentation ) cant possibly be kept up to data
manually. However when the rules are written at a higher level, and the actual
firewall rules are auto-generated dynamically the firewall is essentially always
up to date ( to the second ). It's like the difference in programming in assembly language
or writing in Python.- the higher level abstraction is much easier for humans to understand
and the grunt work of the actual IP based firewall rules is done for you.
It isn't magic - just automating the complicated parts that people don't do well by
moving to a higher level of abstraction. A 'Blue print' graphical design documents each
3-tier application including VM's , networks, and security rules, and the design can then
be pushed out to VMware cloud on prem, VMware cloud partners, VMware on AWS, Plain AWS, or other
clouds in the future.
Then NSX uses these 4M virtual-wires over vxlan for micro-segmentation - and never needs
to touch or change any physical switch, because all the decisions are done by the firewall and router
in each hypervisor. ( NSX consists of hypervisor modules, API's and VM's to virtualize
and entire data-center, including routers, load balancer, VPN, DHCP, FW, etc )
Note that this software-defined network model is different than Cisco's Application Centric Infrastructure (ACI)
which uses split data/control plane in each switch. Cisco requires new switches, and new
SDN manager components ( that sell's more Cisco equipment ) , while the VMware
version realizes SDN in software-only using an overlay network of tunnels through existing switches. Instead
of the switch needing to make a decision on each packet, the hypervisor essentially makes the decision and sends traffic down
the correct pre-defined vxlan virtual wire. This functionality comes from VMware's purchase of Nicira a few years ago.
Kind of makes sense that SDN should be defined fully in software instead of required all new switches as in the Cisco method.
Not to say everything is perfect yet - if you have physical boxes needing access, then you need special
vxlan to Vlan gateways - Arista and others have these built into their switches.
>
> I'm not arguing that NSX isn't secure. The statement above just
> seemed to go a bit far with the claim.
The whole world of SDN and Software defined storage is rapidly changing everything. I'm sure new issues will
show up - but in general this solves the human complexity problem of managing so many firewall rules , so I think
it is quite a bit better and more secure than the old model. I believe VMware has gotten PCI certifications
with PCI / not PCI complient VM's on the same hypervisor, but not government Secret / TS VM next to unclassified.
>
> I could see the argument that an implementation of a
> firewall/network/etc that provides a more clearly defined
> infrastructure would be more secure than an implementation that does
> not, because it reduces the risk of a configuration error. Tools for
> orchestration and software-defined infrastructure can help provide
> security to ensure that every host only talks to exactly the hosts it
> needs to, for example.
OK, you just said what I was explaining above.
The security is actually much more fine-grained at the VM virtal Nic level.
and continues to work even during vMotion of the VM across hosts and/or clusters.
Lately each Virtual Nic has 'insertion points' in the data flow so it can have traffic redirected
for instance to a hardware based Palo Alto Next gen firewall , or redirected
for Anti-virus scanning by Trend Micro, or to a F5 load balancer, so it's not just
limited to VMware anymore. This all all OS agnostic - as long as you have vmxnet3 virtual Nics
so Linux has full support.
Much of the NSX design is also to reduce hair-pinning of micro-segmented traffic ( where two adjacent
VM's would need their traffic to flow out through several switches, and firewall just to get back to
the adjacent VM ). With NSX the hypervisor does the firewall functions, and the inter-VM traffic never
leaves the host.
>
> --
> Rich
> ___________________________________________________________________________
> Philadelphia Linux Users Group -- http://www.phillylinux.org
> Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
> General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
--
"Between subtle shading and the absence of light lies the nuance of iqlusion..." - Kryptos
Lee Marzke, lee@marzke.net http://marzke.net/lee/
IT Consultant, VMware, VCenter, SAN storage, infrastructure, SW CM
___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug