[cisco-voip] CUCM - separating management traffic

Thu Jan 19 17:49:27 EST 2012

proxy vs reverse proxy are apples vs oranges.  two different animals.

Scott

On Thu, Jan 19, 2012 at 2:00 PM, Lelio Fulgenzi <lelio at uoguelph.ca> wrote:

> i _think_ there's a difference between a proxy and a reverse proxy
>
> a proxy is something that you program your browser with and all requests
> go through that proxy and there's no special programming required on the
> proxy side. much more canned i believe.
>
> a reverse proxy allows you to contact a website without having to make
> changes on the client side, but the proxy has to be configured to do all
> the re-writing.
>
> honestly, i'm a newbie to this. so i could be off my rocker.
>
> ---
> Lelio Fulgenzi, B.A.
> Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
> (519) 824-4120 x56354 (519) 767-1060 FAX (ANNU)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Cooking with unix is easy. You just sed it and forget it.
>                               - LFJ (with apologies to Mr. Popeil)
>
>
> ------------------------------
> *From: *"Wes Sisk" <wsisk at cisco.com>
> *To: *"Lelio Fulgenzi" <lelio at uoguelph.ca>
> *Cc: *"FrogOnDSCP46EF" <ciscoboy2006 at gmail.com>, "cisco-voip voyp list" <
> cisco-voip at puck.nether.net>, "Matthew Saskin" <msaskin at gmail.com>
> *Sent: *Thursday, January 19, 2012 4:43:00 PM
>
> *Subject: *Re: [cisco-voip] CUCM - separating management traffic
>
> I'll plead ignorance - why is a special proxy required?  A standard https
> proxy will not work?
>
> /wes
>
> On Jan 19, 2012, at 3:08 PM, Lelio Fulgenzi wrote:
>
> while the reverse proxy has served us well, we did have to find someone to
> build and maintain this for us. also, not everything will work with a
> reverse proxy, especially any protocol that builds the IP address into the
> code and/or requires direct access to the host client. media master bar
> comes to mind.
>
> ---
> Lelio Fulgenzi, B.A.
> Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
> (519) 824-4120 x56354 (519) 767-1060 FAX (ANNU)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Cooking with unix is easy. You just sed it and forget it.
>                               - LFJ (with apologies to Mr. Popeil)
>
>
> ------------------------------
> *From: *"Wes Sisk" <wsisk at cisco.com>
> *To: *"Matthew Saskin" <msaskin at gmail.com>
> *Cc: *"FrogOnDSCP46EF" <ciscoboy2006 at gmail.com>, "cisco-voip voyp list" <
> cisco-voip at puck.nether.net>
> *Sent: *Thursday, January 19, 2012 3:00:52 PM
> *Subject: *Re: [cisco-voip] CUCM - separating management traffic
>
> out of band management is usually delivered via IPKVM either as external
> hardware or utilizing iLO or the IBM equivalent which escapes me at the
> moment.
>
> To protect the administrative interfaces (web and ssh) block traffic from
> hostile environments to these on a per port basis.
>
> The only overlap is access to ccmuser vs.
> (ccmadmin/ccmservice/iptplatform) as all are web services.  Because they
> utilize https now Lelio is spot on that a front end proxy is required.
>
> The general response is that there are devices that do this and very
> commonly do it better than any possible internal implementation.  With that
> precondition why add the additional complexity to the core product?
>
> We've seen several times, even here on cisco-voip, where an ASA or
> external box is required for true policing.  Security folks present a very
> sound case for this.
>
> Regards,
> Wes
>
> On Jan 19, 2012, at 9:54 AM, Matthew Saskin wrote:
>
> I knew Lelio was going to chime in ;)
>
> It's an interesting note that while none of my financial customers have
> done this, or use features like secure voice, I have one Edu whose policy
> is "everything on the network must be encrypted, end of story".  The net of
> this is vastly more time spent troubleshooting security/encryption issues,
> and a significant extra workload in terms of additional servers/development
> work to "Secure" things that aren't secured by their nature (eg; ODBC
> access to UCCX via informix drivers.  While ODBC can be secured/encrypted,
> the informix connectivity to UCCX can't be encrypted)
>
> I digress.  While I agree with Lelio that it's not a difficult thing for
> Cisco to implement, I've yet to see the real-world call for it barring very
> specific circumstances...and we all know the reality, until it's clamored
> for by a collective of customers spending 10's of millions of dollars, it's
> not likely to happen.
>
> -matthew
>
> On Thu, Jan 19, 2012 at 9:48 AM, Scott Voll <svoll.voip at gmail.com> wrote:
>
>> except Lelio ;-)
>>
>> Scott
>>
>>
>> On Thu, Jan 19, 2012 at 6:11 AM, Matthew Saskin <msaskin at gmail.com>
>> wrote:
>>
>>> Who knows?  It's not something that I've ever heard of on the roadmap
>>> from CIsco.  Technically speaking, I can't imagine it would be terribly
>>> difficult to have the various CCM services operate on one interface/IP and
>>> the management (HTTP/HTTPS) on another address, but that's just me thinking
>>> about it.
>>>
>>> Speaking realistically, I've never seen anyone care enough to implement
>>> ACL's or application layer filtering to "protect" the admin interface in
>>> the real world.
>>>
>>> -matthew
>>>
>>>
>>>
>>> On Thu, Jan 19, 2012 at 6:21 AM, FrogOnDSCP46EF <ciscoboy2006 at gmail.com>
>>>  wrote:
>>>
>>>> Thanks Mathew. Would this be difficult to do? Given Cisco has inhouse
>>>> UC developers.
>>>>
>>>>
>>>>
>>>> On Thu, Jan 19, 2012 at 5:52 AM, Matthew Saskin <msaskin at gmail.com>
>>>> wrote:
>>>>
>>>>> You can't.  Virtual or physical, CUCM only operates using a single
>>>>> interface and single IP address.  Closest you're going to get is firewall
>>>>> rules to disallow certain access based on source, and that may not even
>>>>> work as things like authentication URL's are on the same IP/port on the
>>>>> CUCM - you'd have to do some application layer filtering of URL's.
>>>>>
>>>>>
>>>>> On Wed, Jan 18, 2012 at 11:21 AM, FrogOnDSCP46EF <
>>>>> ciscoboy2006 at gmail.com> wrote:
>>>>>
>>>>>> Have anyone figured out yet how to separate CUCM management  in
>>>>>> VMware or physical deployment?
>>>>>>
>>>>>> It's kind of weird, Cisco's all deployment templates are still
>>>>>> putting mgmt and traffic packets on the same eth0 interface.
>>>>>>
>>>>>> I bet this is in Cisco's todo list.
>>>>>>
>>>>>> thanks
>>>>>>
>>>>>> _______________________________________________
>>>>>> cisco-voip mailing list
>>>>>> cisco-voip at puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Smile, you'll save someone else's day!
>>>> Frog
>>>>
>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20120119/791525e9/attachment.html>