firewall-wizards@listserv.icsalabs.com
To subscribe or unsubscribe via the World Wide Web, visit
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
or, via email, send a message with subject or body 'help' to
firewall-wizards-request@listserv.icsalabs.com
You can reach the person managing the list at
firewall-wizards-owner@listserv.icsalabs.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of firewall-wizards digest..."
Today's Topics:
1. Firewall Best Practice regarding XMPP traffic? (paddy joesoap)
2. Re: Firewall Best Practice regarding XMPP traffic? (K K)
----------------------------------------------------------------------
Message: 1
Date: Tue, 15 Jun 2010 12:10:10 +0100
From: paddy joesoap <paddyjoesoap@gmail.com>
Subject: [fw-wiz] Firewall Best Practice regarding XMPP traffic?
To: firewall-wizards@listserv.icsalabs.com
Message-ID:
<AANLkTilMuhilS8oekrQnKljVyhNkOtOYwkZnlKhQs_ms@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi all,
In securing XMPP (Jabber, IM) servers, what best practice in your
opinion should be used.
Having consulted with the XMPP community, they tend to think of TLS
communication channels only and thus a firewall becomes somewhat
redundant from an XMPP perspective.
That is, the XMPP server should handle authentication, deep packet
inspection, IP address filtering and so forth. (Of course this is a
simplistic view given a
firewall helps prevent unprotected services hosted by the XMPP server
from being exploited and it helps control DoS etc)
However, are XMPP servers deployed in practice like this, where all
that is required of the firewall is opening port 5222 for
client-to-server communication and port 5269 for server-to-server
communication where all traffic is over TLS.
I'd imagine that some enterprises want to inspect at the firewall (or
even by IDS) layer-7 packet payloads. For example, ensure a user with
a JID of xyz@jabber.org cannot send packets through the firewall or a
particular malware signature or malicious Web URL that is embedded
with IM conversations is blocked. In such scenarios, is it best
practice to remove the TLS option and thereby loosing some proof of
identify (certificates) in favour of deep packet inspection?
Are there scenarios where an enterprise that is geographically spread
who use VPN's such that they do not require TLS encryption on the XMPP
servers? Rather, they are content that their VPN tunnel is providing
adequate security coupled with DPI (Deep Packet Inspection) of the
XMPP packets and layer 3 and 4 filter also at the firewall?
While XMPP servers such as Openfire have TLS functionality end-to-end,
are these used in practice by security administrators or is some of
the communication desired in the clear for DPI. Presumably, by not
fully considering a firewall chokepoint means that each XMPP service
needs to be updated individually for new threats and there is also a
certificate management issue.
Presumably two XMPP servers that belong to two different enterprises
would not share a VPN channel but use TLS enabled on the XMPP servers
instead. Again, a firewall is not the silver bullet for every scenario
;-)
Would there be scenarios where xmpp clients are not allowed to connect
to the XMPP server except through a HTTP proxy (Perhaps the XMPP
server ports are not externally accessible).
For example, Linux iptables could be used to inspect the XMPP traffic
not just at layers 3 and 4 but some rudimentary l-7 filtering.
Any feedback on personal experiences/scenarios, is greatly welcomed.
regards,
Paddy.
------------------------------
Message: 2
Date: Thu, 17 Jun 2010 01:44:10 -0500
From: K K <kkadow@gmail.com>
Subject: Re: [fw-wiz] Firewall Best Practice regarding XMPP traffic?
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID:
<AANLkTilFc0eNXZgbMgUgGzP8cGWzu5oA9Mk4SLUxHyur@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
In my experience, yes -- XMPP servers are generally deployed in the
DMZ with TLS enabled (required) for all connections.
Theoretically you could load a copy of your XMPP server's private key
onto a content inspection device, granting it visibility inside the
encrypted session. I've never known anybody to do this in practice.
What I have seen done for a corporate XMPP deployment is to have the
clients connect to an edge device using the legacy SSL-only port
(TCP/5223), and then use a generic SSL appliance pass-through to
decrypt the traffic at the edge, so it enters the DMZ in the clear,
where the TCP stream can be inspected as needed This still leaves
any server-to-server traffic non-inspectable, but ensures all traffic
to/from directly connected clients is available for IPS scanning and
L-7 inspection/filtering.
Speaking of firewalls, I'm still disappointed that none of the "Chat
aware" content filtering products are offering support for XMPP.
Blue Coat, Websense, Vontu, etc all go to great lengths to attempt to
see inside AIM and Yahoo chat, but totally ignore the one fully open
protocol in the inspection engines.
Kevin Kadow
------------------------------
_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
End of firewall-wizards Digest, Vol 50, Issue 3
***********************************************
No comments:
Post a Comment