Hi!
We have started to use Jive Messenger and it is really nice.
But due to security reasons we dont want to open port 5222 in the firewall to our intranet.
So we thought about putting a proxy or some similar software in a DMZ. The proxy is the allowed to communicate on port 5222 with the Messenger.
Is this possible, could I use some proxy to do this or is there some better suited software which tunnels the request to the real server.
thx, Christoph
What platform are you using? Linux/Windows/Solaris?
You could use iptables to route the packets to your backend server.
Internet -> proxy:5222 -> backend:5222
The only advantage is that you can “harden” your proxy if you feel the backend server is to difficult to secure.
Noah
Hi!
Our network is composed of Solaris 10 and Solaris 10x86 servers.
Since the backend server can access a lot of resources, we don’'t want to allow access to it directly. I fear iptables is not an option.
Some background: Sun has also a IM server, but I don’'t want to use it. In the package is a so called multiplexor which plays the proxy as described. Now, if I could find some proxy software which does the same for Jive, we would have a much more powerful package and I could “sell” it the management easier!
I hope you understand my position.
thx,
Christoph
Okay, with Solaris I believe the equivalent to iptables is called SunScreen and I believe that url http://docs.sun.com/app/docs/doc/816-4554/6maoq020k?q=ipfilter#hicipfilter[/url] is also available.
Also tell management that when it comes to XMPP servers, Jive Messenger is one of the top compliant Jabber servers.
Not exactly what I want, but I think I can do it this way.
I would have prefered a real proxy component, but if it works, it doesnt matter!
And yes, Jive is very good!
Project Pampero is intended to provide a connection manager which will act like a proxy. What are components of a “real proxy?” I’‘ve seen proxy that don’'t do much more than a switch or router.
Noah
Yes, I already saw Project Pampero! Seems to be exactly what I want!
What I expect/hope to get from a “real proxy”?
No server from the internet should be able to directly connect to a server in the intranet.
Incoming requests should be checked for validy, e.g a DoS attack should not affect the real server, if it crashes the proxy, so be it.
Since Jive has in our case access to LDAP(even if only to a readonly replication) and the Oracle Server, it has a lot access in the end. So, it should not be compromised.
Using a “real” application proxy might help me with these issues, a switch not.
I agree with you 100%. I’‘m very conscious of security and realize that having a “service” exposed externally requires more than just open a port in the firewall. However, if you’‘re opening up the server externally, so you must be interested in offering some value that you have on your intranet. If you really want to make sure that no one unauthorized is using you’‘re next work, than I suggest that you look at VPN or SSL communication using 2-way certs (hmmm…I’'m not sure if that is support in XMPP, an exercise for another day).
So if you’‘re still interested in letting users connect to your intranet without a strong means of authenticating the users (vpn or 2-way cert), then it’‘s a matter of defense in depth. If when Pampero comes around, I would still recommend a firewall between the open ports in the CM and the wild, wild net. For two reasons, one is load balancing (since you’‘ll need a round robin mechanism, assuming that DNS RR is not good enough, and basic DoS and TCP SYN attacks. Snort and it’‘s kind offer some interesting options when it comes to detecting (and potentially resolving) those types of attacks. This should be running on a server in front of your DMZ. Second, the CM’‘s will most likely being checking authentication (at least if they’‘re terminating the SSL connection…in fact they’‘ll have to…since they need to process the payload) and an optional flag to verify the integrity of the request. The CM will live in your DMZ. Since most DMZ servers have at least two network interfaces, usually translating the DMZ ip address (incoming on one NIC) to another internal subnet (outgoing on the second NIC). Finally you get to your “service.” Typically at this level, you’'re more interested in fault tolerance and scalability. JM has been tested with 7-8k connections. Definitely plenty of room for any small to medium sized community.
As for LDAP and Oracle server…make sure that the accounts that are used are limited to only the data they should have access to. LDAP users can be constrainted (I’‘m not sure which LDAP server you’‘re using, but OpenLdap, iPlanet and AD can all limit the visibility of a particular user). Oracle is the same way and even goes a step further and allows you to put resource constraints on users so they don’'t use up all the memory, connections, processing power, etc. You need to choose your values correctly.
So, after saying all that…finding a proxy that does all that is going to be difficult. Each layer needs to uphold it’‘s end of the bargain and do it’'s job. In the scenario I described above, the only piece that is exposed to the internet is a computer that sits in front of the DMZ. I would strongly recommend that you leverage your sun infrastructure and look at SunScreen to provide that front level of support. CM will provide additional integrity checks, but JM already provides these and more.
I hope this helps,
Noah
Thank you for your answer.
Firewalls, Loadbalancers and such are all there.
I didn’'t want to imply that Oracle and Ldap are in danger, I mentioned them to emphasize that most servers are connected to other services. A server which is reachable directly is the weakest spot in a network.
Scalability will be an issue for later, the number of concurrent connections cannot raise higher than about 2.000 in the next few months, because we will have this number of testusers. Afterwards we will have a feeling how many percent use IM, how it scales, …
Shortly said, how powerful the machine(s) have to be to fit our needs. But as I said before, this will not be an issue this year.
Back to the point:
The structure
Firewall/Loadbalancer - Proxy in DMZ - Firewall/Loadbalancer - Server in restricted subnet
is something of a standard setup here. In the end this is what we want to have with Instant Messaging too. Doing it differently leads to some organisatorical difficulties. These difficulties I tried to avoid.
At the moment we will simply allow “direct” access to port 5222 on server. In the long term the CM of Project Pampero will probably the finer solution!
thx,
Chris