Since I work for a major insurance company as their senior security engineer, let me add a few free words of advice.
Rule 1: Nothing comes in on the network layer from the Internet to the core without stopping at the DMZ. This stops buffer overflows. I know Messenger is a Java app, but network attacks can hit your machine before they even get to your application. The perfect example is the recent Microsoft IP validation vulnerability. This allowed specially crafted IP packets to either kill or take over the target machine on any port with any IP protocol. Nothing but a proxy can stop that sort of problem. For fun reading check out Microsoft Security Bulletin MS05-009.
Rule 2: If you need to share communcations with remote workers out on the Internet, make sure the communcations are going over SSL. No need to broadcast confidential information out onto the Internet.
Rule 3: If you need to get at resources on your corporate LAN/Intranet/Core (whatever you call it), you need to stop off at the DMZ with an application proxy. In this case you could probably use another Messenger server as a proxy. I don’‘t know how you set inter-Messenger server communications up, but I assume it’‘s possible. XMPP servers loose a lot of value of they can’‘t talk to other XMPP servers. The DMZ Messenger would simply route your XMPP messages into the core XMPP Messenger. Simple. The DMZ Messenger is a “limited hangout”. It’‘s purpose is relay communcations in securely on a good day and to gracefully withstand attack on a bad day. In the worst case the DMZ Messenger should give up a minimum of information and when it does finally loose it, the core Messenger should be able to figure it out and drop communications with it. That way, all you have to do is re-install the DMZ Messenger, shore up your failed security and you’'re back online.
Rule 4: Setup the Messenger proxy to only accept connections via SSL so your comms are secure. Setup the Messenger proxy server to authenticate against an internal LDAP database and secure that via LDAP/SSL so that the authentication traffic can’‘t be sniffed if someone cracks one of your DMZ machines. (I wouldn’‘t do auth against Active Directory because it requires you to open a boatload of ports into your internal network. That would be bad.) I also wouldn’‘t do local authentication on the proxy itself. There is too much chance that userID’'s and passwords could be stolen from the machine. It would also be a pain-in-the-ass to sync the DMZ auth database with the internal one.
There you have it. The clean security solution from someone who does it fulltime.
If you turn on a fixed width (monospace) font, the following ASCII diagram should serve as a rough outline:
— cut here —
(incoming Internet connection) *----
! firewall !----
SSL ----------+ (internal connect)
!
!
*----
dmz XMPP ! (proxy messenger)
*----
*----
! SSL
! V
!LDAP/SSL *----
! core XMPP !
*----
V (internal messenger)
*----
! LDAP serv
*----
– cut here —
BTW: If for some reason you can’'t use Messenger in the DMZ as a proxy for the one in your core network you could always run a plug proxy on the DMZ. Not nearly as clean, but better than nothing. You can download and compile the TIS fwtk plug proxy (called plug-gw) for free. Just search google for ‘‘fwtk’’.
Good Luck,
Jim Burnes