[cisco-voip] [EXT] Re: Expressway E Firewall Rule Activation

Tue Apr 30 14:23:49 EDT 2019

@Anthony Holloway<mailto:avholloway+cisco-voip at gmail.com> You are correct. Whether Expressway Control crosses a network boundary or not to talk to Expressway Edge (LAN1), its still communicating; it just doesn't have the additional network boundary (that it traverses) for protection (where the ACLs live). In essence, if someone compromised the Expressway Edge, they could also in theory, get to the Expressway Control server since edge LAN2 inherently talks to edge LAN1. Since many customers put the Expressway Control server on the same network as the rest of the UC servers... yikes.

The LAN1 DMZ (or at least a separate network with ACLs if you can't do a true security context) is very important in the dual NIC design. On the occasions where I've found customers with Expressway Control and Edge (LAN1) in the same network, I have advised them to change that to a DMZ or just separate network with ACLs (which is usually sufficient) ... anything to get some type of barrier between Expressway Control and Edge (LAN1).

That said, "Expressway on a Stick" works just fine barring limitations to "hairpinning" in whatever the firewall is; though it is not the Cisco recommended deployment model in the documentation. Every Expressway deployment should try to achieve two security contexts on the edge (or isolated networks with ACLs).

-Ryan

________________________________
From: Jeffrey McHugh <jmchugh at fidelus.com>
Sent: Tuesday, April 30, 2019 1:29 PM
To: Ryan Huff; Anthony Holloway
Cc: cisco-voip at puck.nether.net; Pawlowski, Adam
Subject: RE: [EXT] Re: [cisco-voip] Expressway E Firewall Rule Activation

I see a mixture of both and insist on the dual, even it means pushing back an implementation.

TAC recommends the dual and the advanced networking guide calls that out, along with “not all firewalls support the singe NIC type of NAT”,  it uses about triple the bandwidth per call and I don’t think you can cluster them w only single NIC

Jeffrey McHugh | Sr. Collaboration Consulting Engineer

[Company_Logo_Image]<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.fidelus.com%2F&data=02%7C01%7C%7Cf85c7280f60040476fa308d6cd918314%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636922422183579759&sdata=12L445HKngUMa7KgEKAHcJ1Q8B2juxp0QnlgqCel9%2FY%3D&reserved=0>
Fidelus Technologies, LLC
Named Best UC Provider in the USA<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.fidelus.com%2Ffidelus-technologies-named-best-unified-communications-provider-in-the-usa%2F&data=02%7C01%7C%7Cf85c7280f60040476fa308d6cd918314%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636922422183589770&sdata=dX1CbaWKZbL5%2F3gTq2nHG%2BF9GA01Y%2BzZmtxBJ7WbnVs%3D&reserved=0>
240 West 35th Street, 6th Floor, New York, NY 10001
+1-212-616-7801 office | +1-212-616-7850 fax | www.fidelus.com<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.fidelus.com%2F&data=02%7C01%7C%7Cf85c7280f60040476fa308d6cd918314%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636922422183599775&sdata=la9a%2F2nGCB%2BUBT6JxxSuLZodhixLK2qY4bVW9ws1PtU%3D&reserved=0>
[LinkedIn]<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fcompany%2Ffidelus-technologies%2Fproducts&data=02%7C01%7C%7Cf85c7280f60040476fa308d6cd918314%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636922422183609786&sdata=Ho6IAzCFVh4UkBZdoMw8%2Bd0I5K0SavdgAZ7MuxwnI4I%3D&reserved=0>[Twitter]<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitter.com%2FFidelusUCC&data=02%7C01%7C%7Cf85c7280f60040476fa308d6cd918314%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636922422183619791&sdata=WJ3mKlMcZ3QwuiiJ%2B4pt6wK6Exmw4JCKwNRNpmrqacU%3D&reserved=0>[Facebook]<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.facebook.com%2FFidelusUCC&data=02%7C01%7C%7Cf85c7280f60040476fa308d6cd918314%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636922422183629802&sdata=I%2FnjBEdwRJKy3zsEI41fW%2BZAQeOkiLcbWffpF%2BlQYP8%3D&reserved=0>[YouTube]<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.youtube.com%2FFidelusTraining&data=02%7C01%7C%7Cf85c7280f60040476fa308d6cd918314%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636922422183639807&sdata=Vckk3PrVKllvNCL8ol%2Bs9O%2BGF%2FjneLYtPe6wcJyUSow%3D&reserved=0>

Disclaimer - This email and any files transmitted with it are confidential and intended solely for the person(s) addressed to. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Fidelus Technologies, LLC. Warning: Although Fidelus Technologies, LLC has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.

From: cisco-voip <cisco-voip-bounces at puck.nether.net> On Behalf Of Ryan Huff
Sent: Tuesday, April 30, 2019 12:33 PM
To: Anthony Holloway <avholloway+cisco-voip at gmail.com>
Cc: cisco-voip at puck.nether.net; Pawlowski, Adam <ajp26 at buffalo.edu>
Subject: [EXT] Re: [cisco-voip] Expressway E Firewall Rule Activation

Not generally, no. A couple of my larger customer’s that have fully fleshed out IT departments did though.

For a few of my customers I’ve had to walk them through setting a 2nd one up. In some cases, not even a true DMZ and just a new network and lock it down with ACLs.

I’ve also had customer’s which do the DMZ on “LAN2” (outside), and then keeps LAN1 in the same network as Expressway-C. This particular method doesn’t offer a lot of advantages (from a infosec perspective) over a “Single NIC”, but still makes the traffic flow more logical, easier to support and troubleshoot and keeps you from having to “hairpin” in the firewall (ewww, like gag me with a spoon man lol), which I have never been a fan of from a design perspective.

-Ryan

On Apr 30, 2019, at 12:12, Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway+cisco-voip at gmail.com>> wrote:

Ryan,

Do you have any insight as to whether or not it's common for Firewalls in the field to already have more than one DMZ defined?  In my limited experience, I have never seen it done, and I am having to have that second DMZ created to support Expressway.  For that reason, I actually tend to think the single NIC approach is better, although, the NAT reflection could be a limitation of some firewalls.

On Tue, Apr 30, 2019 at 11:09 AM Ryan Huff <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>> wrote:

Adam,

I certainly didn't mean to imply the, "Expressway Edge on a Stick" method doesn't work, though out of pure technical curiosity, I would be curious as to what exists in your environment that would make a " single NIC" Expressway Edge deployment more preferred than "dual NICs" (not that I expect you would or could say). I can think of very few reasons that a single NIC edge would be more ideal than a dual NIC edge (outside of the infosec team just not wanting to screw with the firewall, or production not being able to sustain a maintenance window); its easier to troubleshoot, easier to install, easier to support and easier to secure.

Though, I suspect I'm, "preaching to the choir", lol 😉. All good my friend.

Thanks,

Ryan

________________________________

From: Pawlowski, Adam <ajp26 at buffalo.edu<mailto:ajp26 at buffalo.edu>>
Sent: Tuesday, April 30, 2019 11:36 AM
To: 'Ryan Huff'
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: RE: [cisco-voip] Expressway E Firewall Rule Activation

Ryan,

The “tl;dr” is that we were sort of given the recommendation by Cisco to just run it with the single interface given our environment and requirements, and hasn’t given us any trouble that I can recall.

Long story is …

Our environment ends up being the driver for a lot of this, as it is sort of a historic design from the early internet, with just about everything on public address space, and various services and networks secured behind firewalls as needed from internal and external alike.

In the dual interface design, the outside interface sits in a “DMZ” with a firewall, which we don’t have available explicitly. There is a border firewall but that isn’t really its function. The inside leg has to sit somewhere as well, which is a place that doesn’t exist.

We did have a competitor’s border proxy become compromised in the past due to a software update, and this model where the inside wasn’t properly secured – and given our current VMWare topology, creating another zone to hairpin traffic around to separate that inside interface wasn’t in the cards. Not to mention the annoyance of trying to setup split routes on this device to allow some traffic to go in, some to go out, in an environment that is MRA only.

If you trust the E enough never to be a bad actor, then you could put that interface in the same zone as your other collaboration appliances, like the Expressway C, but, we didn’t want to do that either really.

Given that, we did have a call with Cisco to discuss this, and with representation from the Expressway group they recommended that we stick with the single interface design.  That was based on the public addressing (so we could avoid NAT reflection) and that despite the pipe dream of everyone wanting HD video calling and mobile client access, we didn’t see that we’d be pushing that much traffic.

As it is, the E clusters sit in a collaboration DMZ, where they are independent from any of our other appliances and treated like any other host on our network. Our application firewalls do not allow anything in from the Expressway E since the C tunnels to it, so really the only thing lacking from a security standpoint there could be containment of that host, but, we chose to guard from it instead.

Since we installed it back on X8.8 or whatever, I’d noted that rebooting the appliance does not reapply the internal rules, which can easily be forgotten, and would need to be remembered if you run a VMWare HA policy that restarts the guest.

That all being said the worst that we have seen are various SSH attempts (on any port, the zone tunnel, administrative SSH, doesn’t matter) until the rules are put back up. We could tighten them on the border once that becomes available to do so.

The B2BUA is invoked on calls within the appliances sometimes which can cause some confusion with attempting to read logging if need be, but it hasn’t otherwise caused us any trouble.

Adam

From: Ryan Huff <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>>
Sent: Tuesday, April 30, 2019 10:13 AM
To: Pawlowski, Adam <ajp26 at buffalo.edu<mailto:ajp26 at buffalo.edu>>
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Expressway E Firewall Rule Activation

That seems odd and not been my experience. Let me ask; why are you using the application firewall rather than the actual firewall (another reason all our edge’s should be using dual interfaces with LAN1 and LAN2 in their own separate security zones)? Is there a reason you have to, in other words?

Thanks,

Ryan

On Apr 30, 2019, at 08:49, Pawlowski, Adam <ajp26 at buffalo.edu<mailto:ajp26 at buffalo.edu>> wrote:

Figured I’d also ask this question

I note that it seems like any time I reboot an Expressway E, I have to go and re-activate all the firewall rules. They don’t seem to activate automatically.

Is there something I missed or is this really what’s necessary?

Adam

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C3fcc9eb351fe41b70dfc08d6cd6a4a65%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636922253726465693&sdata=72kYzwChhoFD14H6a6mRTn4TdHUcMDcFWrMSXpRo%2Btw%3D&reserved=0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7Cf85c7280f60040476fa308d6cd918314%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636922422183649818&sdata=rfseED4dMSZymuoVW%2BrtbugOj4FoZ9pKooPwyF3Fafc%3D&reserved=0>

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7Cf85c7280f60040476fa308d6cd918314%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636922422183669827&sdata=tkhF0mIVJuNq6B%2BZkgFeyn%2Bf81X5cqG%2F9OeXFfUDpN4%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20190430/4e6435fd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-Company_Lo.png
Type: image/png
Size: 1063 bytes
Desc: Outlook-Company_Lo.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20190430/4e6435fd/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-LinkedIn.png
Type: image/png
Size: 734 bytes
Desc: Outlook-LinkedIn.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20190430/4e6435fd/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-Twitter.png
Type: image/png
Size: 749 bytes
Desc: Outlook-Twitter.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20190430/4e6435fd/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-Facebook.png
Type: image/png
Size: 659 bytes
Desc: Outlook-Facebook.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20190430/4e6435fd/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-YouTube.png
Type: image/png
Size: 1017 bytes
Desc: Outlook-YouTube.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20190430/4e6435fd/attachment-0004.png>